Re: libdc1394 soname bump
Le lun. 12 juin 2023 à 18:46, Till Hofmann a écrit : > > Hi all, > > On 6/5/23 23:13, Till Hofmann wrote: > > Hi all, > > > > I have updated libdc1394 to 2.2.7, which bumps the soname to > > libdc1394.so.26. I created the side tag f39-build-side-68587 and built > > the updated libdc1394 in the side tag. > > > > If my query was correct, the following packages need to be rebuilt: > > ffmpeg > > libdc1394 > > mrpt > > opencv > > player > > vxl > > ffmpeg and vxl have already been rebuilt. I can rebuild player and mrpt, > but they both require opencv, which has not been rebuilt yet. > > Could a proven packager rebuild opencv in side tag f39-build-side-68587? opencv Build submitted in the side tag... It should take about 1 hour. We will have to rebuild the rpmfusion side of things. Just warn when everything is ready on the fedora side, we can only get the updates when the side tag will be submitted as an update in repos. Thanks ___ 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: [reviewing akmod] request for reviewing intel-ipu6 akmod package
Le ven. 10 févr. 2023 à 10:24, Kate Hsuan a écrit : > > Hi, > > Recently, we are working on getting IPU6 MIPI camera to work for the > laptops. We also made a akmod package for Intel opensource drivers and > the package will live in RPM fusion. The details can be found here. > https://bugzilla.rpmfusion.org/show_bug.cgi?id=6469 > > Could a reviewer who is familiar with akmod package take a look into it? Hello Kate, I can do the review, but I will be on vacation next monday for the next 2 weeks. Hopefully the userspace part can be sorted out by Hans... Thanks for working on this. ___ 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: EPEL-9 terrible updates (dav1d, libavif...)
Le jeu. 17 nov. 2022 à 15:45, Michel Alexandre Salim a écrit : > - I can package a dav1d092 compatibility package to provide > libdav1d.so.5 > - I can also package a compatibility libavif package, but against which > dav1d? > - rebuild rpmfusion dependents against dav1d 1.0 and libavif 0.11 As RPM Fusion is concerned, the rebuild is done and is scheduled on the next push. (currently occurring). > ## How do we better address (Fedora, EPEL) <=> RPM Fusion dependencies? > > On the Fedora side there is nothing currently that officially considers > RPM Fusion (beyond the few allowlisted subsets like the Nvidia drivers). > Amending the incompatible update policy to mention RPM Fusion is > probably a no-go, but maybe mentioning "consider testing against > well-known and popular third party repos" is doable? While there might be a fedora project wide policy not to assume any 3rd party complement (but still the official documentation mentions the project explicitly these days, with a dedicated notice). I would still expect an appropriate communication level to be held at the individual package maintainers level. Not more, not less than any friendly communication that is expected to be held to any external projects from Fedora. Now of course one can't expect to contact any single maintained project at scale (like copr projects or else), but there I draw the difference between a single maintained project and a well known community based one. Thanks for raising this point. I hope this problem will be behind us soon. ___ 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: Mesa in F37- vaapi support disabled for h264/h265/vc1
Le mar. 27 sept. 2022 à 20:57, David Airlie a écrit : > > On Wed, Sep 28, 2022 at 4:02 AM Frantisek Zatloukal > wrote: > > > > Hi, > > > > since this mesa change ( > > https://src.fedoraproject.org/rpms/mesa/c/94ef544b3f2125912dfbff4c6ef373fe49806b52?branch=rawhide > > ) in F37 and rawhide, the mesa package lost support for vaapi accelerated > > encoding and decoding of h264, h265 and decoding of vc1 ( > > https://bugzilla.redhat.com/show_bug.cgi?id=2123998 ). > > > > It seems like a big regression from F36 for users with GPUs with open > > source drivers (mainly AMD, maybe nVidia/other non x86...), that affects > > common use-cases of Fedora Workstation, like watching videos, in-house game > > streaming, attending online meetings and many more. > > This was an oversight being enabled prior to this, and I think we have > to remove it from older Fedora as well. Fedora cannot ship anything > that causes the OS to provide an API which exposes patent algorithms. > > The patent licensing around H264/H265 is such that providing this > could leave Red Hat and other Fedora distributors exposed to legal > problems. > Dave. > > > I'd like to ask: > > - Can somebody elaborate on reasons to change something that was working in > > Fedora for some time already? > > - Is there any short/mid/long term plan to improve the situation? > > - Would it be possible to provide vaapi support at least as an rpmfusion > > addon to alleviate the fallout in the short term? > > The last might be possible, but I'm not sure how to go about it. At least I've asked in https://bugzilla.redhat.com/show_bug.cgi?id=2123998#c8 That the fedora mesa package completely drops the vaapi backend, so a complementary package can just drop the missing files instead of rebuilding a whole mesa package. It would assume the fedora mesa package to have everything needed in order to cope with vaapi backend enabled in the core libraries and that the vaapi backend only provide the implementation. ___ 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: Enabling ffmpeg on Blender June edition
Le ven. 10 juin 2022 à 03:32, Luya Tshimbalanga a écrit : > [...] > Thanks Neal. That resolved the issue. About the use of pkgconfig insude > FindFFmpeg.cmake filr from upstream Blender, patch is welcome. > @Luya Please remind that you have now a larger issue that is about testing that blender might assume the availability of certain internals codec that are not available in fedora's ffmpeg-free (specially thoses provided in the blender scripts/presets/ffmpeg). (specially some very dedicated H264 option might not be available with openh264 implementation) That might need to be gracefully handled in the blender code. I wish a guideline about using this disabled ffmpeg build in other apps to be made... Thanks. ___ 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: Orphaned packages looking for new maintainers
Le mar. 12 avr. 2022 à 10:04, Miro Hrončok a écrit : > > The following packages are orphaned and will be retired when they > are orphaned for six weeks, unless someone adopts them. If you know for sure > that the package should be retired, please do so now with a proper reason: > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life > > Note: If you received this mail directly you (co)maintain one of the affected > packages or a package that depends on one. Please adopt the affected package > or > retire your depending package to avoid broken dependencies, otherwise your > package will fail to install and/or build when the affected package gets > retired. > > Request package ownership via the *Take* button in he left column on > https://src.fedoraproject.org/rpms/ > > Full report available at: > https://churchyard.fedorapeople.org/orphans-2022-04-12.txt > grep it for your FAS username and follow the dependency chain. > > For human readable dependency chains, > see https://packager-dashboard.fedoraproject.org/ > For all orphaned packages, > see https://packager-dashboard.fedoraproject.org/orphan > >Package (co)maintainersStatus > Change > === > beanstalk-client orphan 5 weeks ago > gnome-shell-extension-material-shell atim, orphan 0 weeks ago > golang-github-astaxie-beegogo-sig, orphan 0 weeks ago > golang-github-influxdata-influxdb go-sig, orphan 2 weeks ago > golang-github-mdlayher-wifigo-sig, orphan 4 weeks ago > hd-idleatim, orphan 1 weeks ago > lua-ldap orphan 5 weeks ago > mcrcon orphan 1 weeks ago > python-aiohttp-corsorphan, python-sig 5 weeks ago > python-aiohttp-negotiate orphan 5 weeks ago I'm taking python3-aiohttp-cors and python3-aiohttp-negociate co-maintainers welcomed... ___ 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: jpegxl soname bump
Le ven. 3 déc. 2021 à 17:17, Sérgio Basto a écrit : > > On Fri, 2021-12-03 at 15:36 +, Michael J Gruber wrote: > > F35 updates has libaom-3.2.0-2 and libjxl-0.6.1-6 already - so did > > the buildroot go through? > > (This conflicts with heif from rpmfusion, which I can't complain > > about here, of course.) > > yes , buildroot go through , rpmfusion packages are fixed just need to > be published in repos Problem was not only about rpmfusion packages rebuilt, but also a lot of missing fedora rebuilt. To this date, there are still missing rebuilds, so was my -1 for this update. @besser Can you clarify why you have pushed this update to stable despite my notice ? This is not the first time this problem occurs with aom and some fedora rebuilds are not done. Someone will have to fix the missing piece... ___ 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: RFC: Reduce number of packages that are built for i686
Le jeu. 18 nov. 2021 à 03:33, Fabio Valentini a écrit :
>
> Additionally, the steam RPM (as provided by the opt-in third-party
> repository that comes installed by default with Fedora Workstation) is
> a i686-only package (sad face), and hence also pulls in i686
The RPM Fusion package is built as a i686 library despite been
"mainly" noarch scripts (bash, python3).
The "mainly" is because there is a 32bit bootstrap client that really
is about to download the fuller stream client from upstream.
Not having any 32bit runtime capability is going to break here (but
it's certainly fixable if upstream would also bundle a 64bit bootstrap
client).
Then most processes from stream {before} running any program show
steamwebhelper are using a 64bit ubuntu 12.04 userspace.
But we likely assume some program are 32bit only and because of that
the our package assume the 32bit capabilities {can} be needed, it
justs assume to install the needed libraries (specially the system
libGL.i686 and others)
It seems to me that assuming 64bit only userspace with steam is wrong
and will lead some users to crash.
If any additional question, please report an issue to
https://bugzilla.rpmfusion.org. Simone will be able to answer or
forward/ask upstream.
Thanks in advance.
> libraries:
> $ sudo dnf repoquery --requires steam --resolve --recursive | grep i686 | wc
> -l
> 221
___
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
Le lun. 15 nov. 2021 à 17:25, Aleksei Bavshin a écrit : > ... > 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. True. Still I have raised the concern at https://gitlab.freedesktop.org/vdpau/libvdpau/-/issues/2 > * 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. Well, technically it's NVDEC support for aarch64 tegra SOC, but it's different than desktop NVDEC (using nouveau) https://github.com/cyndis/vaapi-tegra-driver See also https://bugzilla.redhat.com/show_bug.cgi?id=2023429 Anyway, a more relevant goal is Vulkan Video API. ___ 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
Le lun. 15 nov. 2021 à 16:06, Steve Grubb a écrit : ... > I use the negativio repository only because I need the whole cuda stack > including cudnn. Totally undeeded, you can get rpmfusion+nvidia-cuda repository directly and avoid incompatible repository. https://rpmfusion.org/Howto/CUDA ___ 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
Le ven. 12 nov. 2021 à 09:37, Martin Stransky a écrit : > > 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 Thanks for the documentation Martin. Few notes: - Only ffmpeg, libva-intel-driver (and intel-media-driver for newer hw) are provided via rpmfusion (in nonfree section for the latter), the other components are in fedora - We might have a special issue for f35 as the introduction of crocus DRI driver broke the X11 DRI/VAAPI mapping. (Fix pending: https://bodhi.fedoraproject.org/updates/FEDORA-2021-83cbfc7e32 - rhbz#2017059) ___ 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: I think we should stop building i686 packages we're not shipping
Le mar. 31 août 2021 à 19:22, Justin Forbes a écrit : > > On Tue, Aug 31, 2021 at 12:14 PM Florian Weimer wrote: .. > While it might take a good bit of time to sit down and figure out > exactly what is *useful* from a multilib standpoint, I don't think > that is necessary at this time. It really could be simplified to "do I > build a library or not?". if the package ships a library, keep > building it for i686, if not, you can disable it. It isn't an optimal > solution, but it would probably cut down considerably on build time, > and resource usage. Unfortunately, some binaries (i686) are sometimes needed when building a library, especially as we don't "cross-compile", so the first binary needed will be gcc (which also has few libraries). Because of that, drawing the line between what is needed for multilibs and what's not is a moving target. As some dependencies might "change" for a given library. We are currently experiencing that in "3rd part" as we are only building a limited set of packages for i686. (because the way i686 repository is only provided in koji vs normal repositories). Maintaining an i686 buildroot synchronized from koji adds some dependencies for the same set of i686 packages to build. - Nicolas ___ 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: Wrong FTBFS in F35?
Le mar. 17 août 2021 à 17:21, Евгений Пивнев a écrit : > > As I found my package qpdfview cannot be build in F35. > Package marked as FTBFS: > https://bugzilla.redhat.com/show_bug.cgi?id=1987904 > > Koji build says: > > DEBUG util.py:444: Error: > DEBUG util.py:444: Problem: package qt5-qttools-devel-5.15.2-6.fc35.x86_64 > requires qt5-doctools = 5.15.2-6.fc35, but none of the providers can be > installed > DEBUG util.py:444:- conflicting requests > DEBUG util.py:444:- nothing provides libclang.so.12()(64bit) needed by > qt5-doctools-5.15.2-6.fc35.x86_64 > DEBUG util.py:444:- nothing provides libclang.so.12(LLVM_12)(64bit) > needed by qt5-doctools-5.15.2-6.fc35.x86_64 > > https://koji.fedoraproject.org/koji/taskinfo?taskID=74013269 > > What to do? I've experienced the same issue with my build (onednn) on f35 (only, not rawhide). It was related to an indirect dependency on clang (needed by doxygen). Seems like the clang12 compatibility package isn't in the buildroot yet. I've used fedpkg build --target f35-build-side-43964 Now I wonder if doxygen (and many other packages) shouldn't be rebuilt for clang-13 instead. I'm especially worried that some packages will be rebuilt with clang/llvm 13 and others kept as 12. There might be symbol versioning with clang/llvm ?... but still it's annoying as a dependency mix... So what's the plan ? ___ 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: RPM name collisions
Le jeu. 29 avr. 2021 à 22:04, przemek klosowski via devel a écrit : >... > For completness, here are the remaining strange cases: > > openhantek.x86_64 2.06-1.fc31rpmfusion-nonfree > openhantek.x86_64 3.2-1.fc34 fedora I've fixed this one on f35+ for rpmfusion-nonfree. Package moved to fedora in 2019 but wasn't properly untagged from repo. Thanks for the notice. ___ 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: Rebuilding packages that use std::call_once from libstdc++
Le mar. 30 mars 2021 à 18:13, Jonathan Wakely a écrit : > > Due to an unplanned ABI break that I caused in libstdc++, I will soon > start to rebuild the packages listed below. This rebuild will remove > references to some symbols in libstdc++.so which do not work as > intended, and so will not be present in the final gcc-11.1.0 release. > > See https://bugzilla.redhat.com/show_bug.cgi?id=1937698 for reference. Can you explain why only the f34 branch would be affected ? Also this is a problem if you only bump the f34 branch and not the rawhide one, as package EVR will be lower on rawhide... Thanks. ___ 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: PackageKit-gtk3-module i686 (x86_32) is missing in Fedora 33 repositories
Le lun. 25 janv. 2021 à 12:29, Kamil Paral a écrit :
>
> On Mon, Jan 25, 2021 at 11:17 AM Graham White
> wrote:
>>
>> Hi,
>>
>> I'm trying to get to the bottom of bug #1901065 -
>> https://bugzilla.redhat.com/show_bug.cgi?id=1901065
>>
>> Anyone know why PackageKit-gtk3-module.i686 has been removed from the Fedora
>> 33 repositories? This package was there for Fedora 32 and checking Koji it
>> looks like the 32-bit version is still being built. However, for some
>> reason it's not appearing in the F33 repositories for the x86_64
>> architecture. We have some packages that rely on the 32-bit version so it
>> would be good to have it re-included in the repo.
>
>
> Multilib detection (which i686 packages should end up in x86_64 repos) is
> done in Pungi. There is some heuristics which I haven't found documented
> anywhere (one would think it should be in the packaging docs). A whitelisting
> of some package can be requested here:
> https://pagure.io/pungi-fedora/issues
>
> However, as you can see, the maintainers don't respond much to such requests
> :-( Perhaps Mohan, Kevin or others could shed a light here how to best make
> sure those requests are noticed? Thanks.
The logical is about, any -devel sub-packages are copied for both
multilibs arches, then only the additional "arched" dependencies (with
%{?_isa}) are computed from the -devel.i686 one.
I can suggest a fix that will add theses dependencies in the
glib-devel sub-package (1), but maybe it will be more relevant to
restore an empty PackageKit-devel and add these here.
I expect it's valuable to have the logic for multilibs, "self
contained" in the package instead of to rely on any infra tweaks.
(1) https://src.fedoraproject.org/rpms/PackageKit/pull-request/7
___
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: HEADS UP: OpenEXR + ilmbase = (new) openexr
Le jeu. 10 déc. 2020 à 13:41, Richard Shaw a écrit : > > OpenEXR and ilmbase are several releases behind in Fedora and the main reason > is that they combined OpenEXR & ilmbase and changed build systems to CMake. > > In digging into this, it makes sense. OpenEXR doesn't even provide a library > named OpenEXR, instead: > > $ dnf repoquery --provides OpenEXR-libs > ... > libIlmImf-2_3.so.24 > libIlmImf-2_3.so.24()(64bit) > libIlmImfUtil-2_3.so.24 > libIlmImfUtil-2_3.so.24()(64bit) > > And strangely ilmbase provides mostly libraries that don't contain ilm! > > $ dnf repoquery --provides ilmbase > ... > libHalf.so.24 > libHalf.so.24()(64bit) > libIex-2_3.so.24 > libIex-2_3.so.24()(64bit) > libIexMath-2_3.so.24 > libIexMath-2_3.so.24()(64bit) > libIlmThread-2_3.so.24 > libIlmThread-2_3.so.24()(64bit) > libImath-2_3.so.24 > libImath-2_3.so.24()(64bit) > > And ALL of the headers for both packages get installed into > /usr/include/OpenEXR! > > So here's my plan: > > 1. Repackage openexr from scratch including review request (Rex?) > 1a. Include appropriate Provides/Obsoletes for current OpenEXR and ilmbase > packages > 2. Perform all testing and dependent rebuilds in a COPR first. > 3. Build openexr and dependencies in a side-tag > 4. Merge the side tag and retire OpenEXR and ilmbase I'm not quite following why you want to retire ilmbase ? Is the openexr package enough ? I don't get the reason why you mention that library names are unrelated to the package name ? That's two separate things. Thanks for taking care of that. ___ 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: VirtualBox pkgs for F33?
Le mer. 2 déc. 2020 à 17:18, PGNet Dev a écrit : > > On 12/2/20 8:13 AM, Artem Tim wrote: > > Vbox also available in RPM Fusion repo > > https://admin.rpmfusion.org/pkgdb/package/free/VirtualBox/ > > Works OK in f33. > > Didn't know about those -- thx. > > Visit to the rpmfusion site returns: > > "Firefox does not trust koji.rpmfusion.org because its certificate > issuer is unknown, the certificate is self-signed, or the server is not > sending the correct intermediate certificates." This is normal as we are "stil" using our own CA for koji, but I plan to migrate to a well known CA soon. That been said, you are not expected to use this interface directly, only the public mirrors... ___ 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: libfilezilla soname bump
Le lun. 9 nov. 2020 à 17:16, Gwyn Ciesla via devel a écrit : > > We're updating libfilezilla and filezilla in Fedora 33 to their latest > versions. This will bump the soname for libfilezilla, but filezilla is the > only consumer. Thanks for this update. This looks appropriate. ___ 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: youtube-dl Copyright Violations
Le lun. 26 oct. 2020 à 12:10, Vitaly Zaitsev via devel a écrit : > > On 26.10.2020 11:29, Daniel Pocock wrote: > > I've recently made some suggestions about using IPFS as part of the > > packaging workflow[1] > > Censorship is evil. If the copyright holders complain about any > packages, they should be moved to RPM Fusion repository. As the RPM Fusion project coordinator, I wouldn't assume such a solution as a given. This can be eventually discussed. But I, as someone already stated, please don't assume legal discussion to be headed here in the fedora devel list. Also please remember that rpmfusion is respectful for copyrights in "european right acceptance". ___ 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
OpenCV update to 4.5 in rawhide
There is a need to fix OpenCV FTBFS and update it to the current version which will require to rebuild opencv dependencies. This rebuilt went fine in copr: https://copr.fedorainfracloud.org/coprs/kwizart/opencv4/packages/ So the plan is to use a side-tag. Because few packages are affected by the "timeb" removal in glibc, we will wait a little for things to settle and probably start the upgrade by tomorrow. Nothing is needed from maintainers. Thanks -- - Nicolas (kwizart) ___ 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: Conflicting build-ids in chromium and chromium-freeworld
Le lun. 21 sept. 2020 à 12:08, Mark Wielaard a écrit : > > Hi, > > On Mon, 2020-09-21 at 08:55 +0300, Panu Matilainen wrote: > > On 9/21/20 12:25 AM, Marcin Zajączkowski wrote: > > > Hi. There is an ongoing problem with conflicting build-ids in chromium > > > and chromium-freeworld [1][2]: > > > > Error: Transaction test error: > > > >file /usr/lib/.build-id/61/91aba223f60784c4a2fb95cdedcedc97217e5b > > > > from install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 > > > > conflicts with file from package chromium-85.0.4183.102-1.fc32.x86_64 > > > >file /usr/lib/.build-id/82/5827dc3adff19282b7b337b044b381e2f226ee > > > > from install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 > > > > conflicts with file from package chromium-85.0.4183.102-1.fc32.x86_64 > > > >file /usr/lib/.build-id/c1/a0a2a071572e46f4b3800bbb0f7ba217b42df7 > > > > from install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 > > > > conflicts with file from package chromium-85.0.4183.102-1.fc32.x86_64 > > > >file /usr/lib/.build-id/cc/2a382a1ab1ec74354adf012ad958a17f880f88 > > > > from install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 > > > > conflicts with file from package chromium-85.0.4183.102-1.fc32.x86_64 > > > >file /usr/lib/.build-id/d9/1c0feec7526201e135457e3a7f4ff4e4aebfea > > > > from install of chromium-freeworld-85.0.4183.102-1.fc32.x86_64 > > > > conflicts with file from package chromium-85.0.4183.102-1.fc32.x86_64 > > > > > > There is no clear idea why it happens, but my assumption is that due to > > > the fact of building with the same source code (with similar patches), > > > some generated shared libraries are the same which generates conflict(s). > > The error message could probably be improved. > You might want to look at where the /usr/lib/.build-id/xx/ symlinks > are pointing at to get a better idea which binaries are identical > between the packages. > > > > The quick look at the algorithm for build-id generation [3] doesn't > > > answer my question what exactly is taken into account for their > > > generation and more precisely is there is way to add some "fuzz" (having > > > different buildroots doesn't help) to distinguish those libraries. > > The build-id is calculated over all relevant build environment bits (by > the linker, not rpm). This includes the debuginfo in the original (not > split) ELF file. The debuginfo contains the build paths (which should > be different for different NVRs and include the compiler version and > flags). This really should prevent identical build-ids whenever > something is really build from source. Normally you only get identical > build-ids when building the same source code in the same package with > the same compiler flags. Identical build-ids between packages are > really very rare and are often caused by some binary blob simply being > copied between packages (is there a blob in the upstream tar ball that > isn't build from source?) or if debuginfo (-g) is missing. Hello Mark, thanks for confirming that case. (buildID conflict might be caused by binaries not built from sources) The suspected files are the following: (same for the fedora version). lrwxrwxrwx. 1 root root 55 11 sept. 18:54 /usr/lib/.build-id/61/91aba223f60784c4a2fb95cdedcedc97217e5b -> ../../../../usr/lib64/chromium-freeworld/chrome-sandbox lrwxrwxrwx. 1 root root 65 11 sept. 18:54 /usr/lib/.build-id/82/5827dc3adff19282b7b337b044b381e2f226ee -> ../../../../usr/lib64/chromium-freeworld/swiftshader/libGLESv2.so lrwxrwxrwx. 1 root root 53 11 sept. 18:54 /usr/lib/.build-id/c1/a0a2a071572e46f4b3800bbb0f7ba217b42df7 -> ../../../../usr/lib64/chromium-freeworld/libGLESv2.so lrwxrwxrwx. 1 root root 62 11 sept. 18:54 /usr/lib/.build-id/cc/2a382a1ab1ec74354adf012ad958a17f880f88 -> ../../../../usr/lib64/chromium-freeworld/swiftshader/libEGL.so lrwxrwxrwx. 1 root root 50 11 sept. 18:54 /usr/lib/.build-id/d9/1c0feec7526201e135457e3a7f4ff4e4aebfea -> ../../../../usr/lib64/chromium-freeworld/libEGL.so There is indeed a need to fix this on both sides. Thanks for your input. ___ 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 33 Mass Rebuild
Le lun. 3 août 2020 à 23:18, Neal Gompa a écrit : > > On Mon, Aug 3, 2020 at 3:59 PM Nicolas Chauvet wrote: > > > > Le lun. 3 août 2020 à 19:37, Neal Gompa a écrit : > > > > > > On Mon, Aug 3, 2020 at 12:32 PM Gary Buhrmaster > > > wrote: > > > > > > > > On Mon, Aug 3, 2020 at 3:15 PM Richard Hughes > > > > wrote: > > > > > > > > > Most of those are the libcroco->gettext breakage, no? > > > > > > > > From a very cursory scan (not at all scientific), > > > > some percentage are the cmake macro changes. > > > > > > CMake macros are documented in the packaging guidelines: > > > https://docs.fedoraproject.org/en-US/packaging-guidelines/CMake/ > > > > > > Here's an example of how to adjust it: > > > https://src.fedoraproject.org/rpms/alembic/c/83812e6c762c28c7e2141860711a3598c101256f > > > > Can you show an example that work across all maintained releases ? > > (aka inclusing epel7). > > > > I don't have a package off-hand that is maintained across EPEL7, > EPEL8, and Fedora, but the macros are all implemented, provided you > are using cmake3 for EPEL7. > > If you don't care whether it's in-source or out-of-source build, then > you only need to concern yourself with %cmake, %cmake_build, and > %cmake_install (for EPEL7, %cmake3 is the prefix instead of %cmake). The problem is that I care and usually use out of source build (manually creating build dir and etc), but having to define __cmake_in_source_build 1 looks miss-named if already using a dedicated build sub-directory. If I'm using %cmake macros without a build sub-directory, then I'm losing the source tree versus build tree there. This is possible, but a little backward. Or did I miss something ? ___ 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 33 Mass Rebuild
Le lun. 3 août 2020 à 19:37, Neal Gompa a écrit : > > On Mon, Aug 3, 2020 at 12:32 PM Gary Buhrmaster > wrote: > > > > On Mon, Aug 3, 2020 at 3:15 PM Richard Hughes wrote: > > > > > Most of those are the libcroco->gettext breakage, no? > > > > From a very cursory scan (not at all scientific), > > some percentage are the cmake macro changes. > > CMake macros are documented in the packaging guidelines: > https://docs.fedoraproject.org/en-US/packaging-guidelines/CMake/ > > Here's an example of how to adjust it: > https://src.fedoraproject.org/rpms/alembic/c/83812e6c762c28c7e2141860711a3598c101256f Can you show an example that work across all maintained releases ? (aka inclusing epel7). Thanks in advance. ___ 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: Rebuilt for OpenCV 4.3.0 in rawhide
Le ven. 5 juin 2020 à 08:52, Igor Raits a écrit : > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On Fri, 2020-05-29 at 14:02 +0200, Nicolas Chauvet wrote: > > Hello there, > > > > There is an update to opencv 4.3.0 in preparation for rawhide. > > This will be handled in a side tag along with the rebuild of the all > > dependencies. > > (fedpkg build --target=f33-build-side-24026) > > > > This was evaluated ahead,so it should lead to issue. > > https://copr.fedorainfracloud.org/coprs/kwizart/opencv4/builds/ > > (failures are random issue on copr builders, should be all green on > > koji). > > > > We will merge the side tag next week and once everything have been > > rebuilt. > > Seems that some packages are broken in rawhide now: > > * os-autoinst > * qimgv Both are now fixed, thanks for the report. ___ 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
Rebuilt for OpenCV 4.3.0 in rawhide
Hello there, There is an update to opencv 4.3.0 in preparation for rawhide. This will be handled in a side tag along with the rebuild of the all dependencies. (fedpkg build --target=f33-build-side-24026) This was evaluated ahead,so it should lead to issue. https://copr.fedorainfracloud.org/coprs/kwizart/opencv4/builds/ (failures are random issue on copr builders, should be all green on koji). We will merge the side tag next week and once everything have been rebuilt. Thanks -- - Nicolas (kwizart) ___ 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: Cross-arch dependencies for plugins (NSS and others)
Le lun. 24 févr. 2020 à 19:12, Florian Weimer a écrit : > > Sometimes, users run into problems because they install nss_nis on > x86_64 and want to use 32-bit applications, but those do not work > correctly because nss_nis.i686 is not installed. I think we have an > opportunity here to improve the system administrator experience with > reasonable effort. > > If we add this to nss_nis.spec: > > %ifarch x86_64 > Recommends: (nss_nis(x86-32) if glibc(x86-32)) > %endif I'm using a similar boolean dependency for a 3rd part provided binary driver and the libGL.i686 counterpart. Althought I've experienced better success with Requires instead of Recommends because the former is more deterministic. -- - Nicolas (kwizart) ___ 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: HELP: FreeCAD is still very broken on Fedora 30/31
Le mer. 15 janv. 2020 à 15:52, Richard Shaw a écrit : > > On Wed, Jan 15, 2020 at 8:50 AM Nicolas Chauvet wrote: >> >> Le mer. 15 janv. 2020 à 15:36, Richard Shaw a écrit : >> > >> > >> > There is a mess between Coin3 and Coin4 (and their dependencies) which I >> > believe is causing most of the problems. >> > >> > Some background here: >> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/RMWY7KZIPWNOYPZE7ZOHEZGCN334T2BW/#RMWY7KZIPWNOYPZE7ZOHEZGCN334T2BW >> > >> > The main Coin3D stack (Coin, soqt, SIMVoleon, privy) are still Coin3 based >> > for Fedora 30/31 but FreeCAD needs Coin4. FreeCAD doesn't actually use >> > SoQt (but Quarter instead) but also requires Pivy at runtime which pulls >> > in the rest of the Coin3 stack. >> > >> > I have avoided modules, but would that be a solution to the dependency >> > problem? At least on Fedora 31? I don't need them for Rawhide so I would >> > want to make sure they were obsoleted once f32 is released. >> > >> > Is there anything I can do or just leave it broken until f32 is released? >> > >> > I'm getting pretty worn out with bugzilla tickets related to FreeCAD and >> > don't know how to "fix" it at this point, other than t >> You can downgrade freecad to the appropriate version that still uses >> Coin3, then keep the Coin4 version for f32. > > > Well the bug is actually in Coin3. SVG imports/exports cause a segfault, not > really FreeCAD version specific I'm afraid, but I may have to live with a > "lesser problem" as this point. Well, at this step the error is located in your FreeCAD compilation since, as I understand, you cannot have a process to load two differents versions of the same library (unless using symbol version which Coin3/4 doesn't use). So there is no bug analysis beyond that. (side note, your older FreeCAD RPM has Coin.so.60 as DTNEEDED, so you actually directly links to Coin3. not via a 3rd part dependency). Is this Coin3 issue a regression or has the problem always existed in the f30/f31 livetime ? -- - Nicolas (kwizart) ___ 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: HELP: FreeCAD is still very broken on Fedora 30/31
Le mer. 15 janv. 2020 à 15:36, Richard Shaw a écrit : > > > There is a mess between Coin3 and Coin4 (and their dependencies) which I > believe is causing most of the problems. > > Some background here: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/RMWY7KZIPWNOYPZE7ZOHEZGCN334T2BW/#RMWY7KZIPWNOYPZE7ZOHEZGCN334T2BW > > The main Coin3D stack (Coin, soqt, SIMVoleon, privy) are still Coin3 based > for Fedora 30/31 but FreeCAD needs Coin4. FreeCAD doesn't actually use SoQt > (but Quarter instead) but also requires Pivy at runtime which pulls in the > rest of the Coin3 stack. > > I have avoided modules, but would that be a solution to the dependency > problem? At least on Fedora 31? I don't need them for Rawhide so I would want > to make sure they were obsoleted once f32 is released. > > Is there anything I can do or just leave it broken until f32 is released? > > I'm getting pretty worn out with bugzilla tickets related to FreeCAD and > don't know how to "fix" it at this point, other than t You can downgrade freecad to the appropriate version that still uses Coin3, then keep the Coin4 version for f32. Thx -- - Nicolas (kwizart) ___ 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 32 Self-Contained Change proposal: Additional buildroot to test x86-64 micro-architecture update
Le ven. 10 janv. 2020 à 10:29, Florian Weimer a écrit : > > * Neal Gompa: > > > 1. Our builder resources are squeezed enough as it is. In doing this, > > are we going to get more machines so that we can have more builders? > > Between modules and this, I worry our resources will get squeezed far > > too tightly for my comfort. > > Please send me the required hardware specs and number of machines. > > > 2. This feature does not describe what the new microarchitecture > > baseline will be. I *could* assume it's the crazy new > > microarchitecture that was proposed in the rejected Change, but I > > don't want to make that assumption. Please specify. > > It's going the be AVX2 with or without VZEROUPPER. We'll try without > VZEROUPPER first, but if that has too poor performance for legacy > software, we need to build with VZEROUPPER. > > > 3. Why is this in the main Koji and require a new disttag? Why not > > just do a shadow Koji and build in an alternate path? > > It was the best approach we came up with. If there better ways to > implement this, that's fine too. Why not to use a copr repo for this ? I don't think you will rebuild the whole distro there, but a selected set of packages will be a relevant step to provide some numbers. -- - Nicolas (kwizart) ___ 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 32 System-Wide Change proposal: Use update-alternatives for /usr/bin/cc and /usr/bin/c++
Le jeu. 9 janv. 2020 à 17:42, Tom Stellard a écrit : > > On 01/08/2020 11:40 PM, Igor Gnatenko wrote: > > So this just means that packages do not respect the environment. What about > > fixing them instead of trying to hack the environment? > > > > Do you mean that packages should be updated to respect the __cc and __cxx > macros? At least build systems must obey to CC and others environment variables. So anything not compliant is an upstream bug (or an issue in the RPM macro ?). Theses are extremely high numbers, but unlikely to provide anything meaningful until one can dive into the root cause, at least for for few of them. There are probably few error patterns that can be fixed. -- - Nicolas (kwizart) ___ 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: Orphaned packages looking for new maintainers
Le lun. 23 déc. 2019 à 11:03, Miro Hrončok a écrit : > > The following packages are orphaned and will be retired when they > are orphaned for six weeks, unless someone adopts them. If you know for sure > that the package should be retired, please do so now with a proper reason: > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life > > Note: If you received this mail directly you (co)maintain one of the affected > packages or a package that depends on one. Please adopt the affected package > or > retire your depending package to avoid broken dependencies, otherwise your > package will be retired when the affected package gets retired. > > Request package ownership via the *Take* button in he left column on > https://src.fedoraproject.org/rpms/ > > Full report available at: > https://churchyard.fedorapeople.org/orphans-2019-12-23.txt ... > gns3-gui orphan 5 weeks ago > gns3-net-converterorphan 5 weeks ago > gns3-server orphan 5 weeks ago I'd like to pick theses gns3* packages. https://pagure.io/releng/issue/9149 Thx -- - Nicolas (kwizart) ___ 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: opencv 4.1.2 soname bump
Le dim. 29 déc. 2019 à 00:50, Sérgio Basto a écrit : > > > The "Rebuild (tesseract)" , pushed opencv-4.1.2-3.fc32 to rawhide > which is one soname bump , the build should failed on i686 but don't . > I have to review the latest commits ... I've fixed the i686 build for opencv4 (but not have built it). I've submitted the rebuild of all opencv dependencies, and I will disable opencv support for those that are known not to build with this opencv4 yet. -- - Nicolas (kwizart) ___ 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 32 System-Wide Change proposal: Use update-alternatives for /usr/bin/cc and /usr/bin/c++
Le jeu. 19 déc. 2019 à 22:44, Ben Cotton a écrit :
>
> https://fedoraproject.org/wiki/Changes/Use-Update-Alternatives-For-usr-bin-cc
>
> == Summary ==
> Modify the gcc package so that the /usr/bin/cc and /usr/bin/c++
> symlinks are managed by update-alternatives.
>
> == Owner ==
> * Name: [[User:tstellar| Tom Stellard]]
> * Email:
>
> == Detailed Description ==
> The gcc package currently installs symlinks to /usr/bin/cc and
> /usr/bin/c++ which point to /usr/bin/gcc and /usr/bin/g++
> respectively. For this change, the gcc package will be modified so
> that update-alternatives creates and manages these symlinks.
>
> In addition to modifying the gcc package, the clang package will be
> modified so that /usr/bin/clang and /usr/bin/clang++ can be used as
> alternatives for /usr/bin/cc and /usr/bin/c++. The clang alternatives
> will have a lower priority than the gcc alternatives, so that by
> default, gcc will provide the /usr/bin/cc and /usr/bin/c++
> implementations.
>
> The clang package currently has a run-time dependency on gcc, so this
> ensures that gcc will always provide the default implementation,
> because it's impossible to install clang without gcc.
>
> The only way users will be able to change the /usr/bin/cc or
> /usr/bin/c++ implementations will be by explicitly using the
> update-alternatives tool.
>
> == Benefit to Fedora ==
> Many build systems default to using /usr/bin/cc and /usr/bin/c++ as
> the default C/C++ compilers. Being able to easily swap out these
> implementation will provide a lot of flexibility within Fedora for
> doing things like:
>
> * Setting up alternative buildroots for testing.
> * Installing a gcc wrapper script to /usr/bin/cc to help migrate
> packages to new compiler flags or to capture statistics about compiler
> usage.
> * Letting users experiment easily with alternate compilers.
> * Easily switch between system gcc and a development version of gcc.
>
> == Scope ==
> * Proposal owners: The proposal owner will implement the necessary
> changes in the gcc and clang packages.
>
> * Other developers: The gcc maintainers will be responsible for
> reviewing and approving changes to the gcc package.
>
> * Release engineering: (a check of an impact with Release Engineering is
> needed)
> * Policies and guidelines: No policies or guidelines will need to be
> updated as a result of this change.
> * Trademark approval: N/A (not needed for this Change)
>
>
> == Upgrade/compatibility impact ==
> This change should not impact upgradeability.
>
> == How To Test ==
> CI tests will be added to the gcc package to ensure that /usr/bin/cc
> and /usr/bin/c++ still point to /usr/bin/gcc and /usr/bin/g++ when
> installed. There will also be a CI test added to the clang package to
> ensure that /usr/bin/gcc and /usr/bin/g++ remain the default when
> clang is installed.
>
> == User Experience ==
> This change will give users a much better way to experiment using
> other compilers for their own development. They will be able to
> easily switch between different compilers without having to modify
> their projects build system or make non-standard changes to their
> Fedora system.
>
> == Dependencies ==
> This change has no other dependencies besides the changes to the gcc
> and clang packages.
>
> == Contingency Plan ==
> * Contingency mechanism: (What to do? Who will do it?) Proposal Owner
> will revert changes made to gcc and clang packages and rebuild.
> * Contingency deadline: If the changes are not complete by 2 weeks
> before the mass rebuild, then we will consider postponing to the next
> Fedora release and back out any changes that were made.
> * Blocks release? No
> * Blocks product? None
>
> == Documentation ==
> Release notes will be added for this change.
>
> == Release Notes ==
> The user /usr/bin/cc and /usr/bin/c++ symlinks are now managed by
> update-alternatives. If you would like to change these symlinks to
> point to another compiler, like clang, for example, you can use these
> commands:
>
> `update-alternatives --set cc /usr/bin/clang`
>
> `update-alternatives --set c++ /usr/bin/clang++`
Does this process even works in RPM context ? given rpm -E %{__cc}
outputs gcc, I don't think /usr/bin/cc is ever used anywhere. (same
for __cxx, __cpp)
If that's only supposed to work in a local compilation context (not
with RPM), what is the benefit from using alternatives rather than
export CC=clang ?
What about ccache ? (does it need to also be registered with alternatives) ?
As I imagine, setting clang for a given package with such alternatives
would requires to add a BR of some clang-default that will call
alternatives in %post.
At first sight, I would dramatically prefer to have a RPM macro that
would set __cc, __cpp,__cxx and the relevant cflags ldflgas in %prep.
(and eventually another macro that would set then back to default).
--
-
Nicolas (kwizart)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscrib
Re: Blender for Fedora 31 does not support multimedia?
Le ven. 1 nov. 2019 à 16:40, Martin Kolman a écrit : > > On Fri, 2019-11-01 at 15:33 +, Leigh Scott wrote: > > Rpmfusion can't ship blender due to our non-replacement policy, fedora > > should consider dropping their crippled > > package. > While it is certainly missing some functionality, I would not call it cripled > - it is for example perfectly usable for > 3D model creation for 3D printing (STL file output) & often advertised as > such. > > Dropping the Blender package from Fedora repositories would break this > usecase and require people to enable Rpmfsion > to get Blender even if they just need it for printable model creation. Indeed, so the way forward for Fedora is to have a blender with ffmpeg builtin that has disabled codecs. (with the same script than what is available in Fedora chromium). As I understand, blender use ffmpeg as the engine for the video rendering scene, but then one can re-encode to a target codec at a later point. So I don't see any issue to miss few codecs for the feature. Of course if one still want all codecs, the RPM Fusion project would welcome any volunteer to maintain any blender-freeworld package that will use the full featured ffmpeg with a separate build of blender. One could still even maintain a blender-cuda package with Nvidia CUDA kernel enabled. I would not personally see the point as it's possible to compile the CUDA kernel using the fedora package last time I've looked into... -- - Nicolas (kwizart) ___ 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: libdav1d SONAME bump
Le ven. 18 oct. 2019 à 22:44, Robert-André Mauchin a écrit : > > On Friday, 11 October 2019 16:10:55 CEST you wrote: > > Hello, > > > > Dav1d 0.5.0 was published today and brings a SONAME bump from libdav1d.so. > > 2.0.0 to libdav1d.so.3.0.0. > > I will be updating it next week on F31/32, consumers of these libraries > > (ffmpeg, xine-lib, vlc) will need to rebuild their packages. > > > > Best regards, > > > > Robert-André > > libdav1d SONAME bumped in F32 and EPEL8. Consumers of this library (ffmpeg, > xine-lib, vlc), please rebuild your packages. NAK -- - Nicolas (kwizart) ___ 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: OpenCV 4.1.x update in rawhide
Hi there, There is a plan to update opencv to 4.1.x in rawhide. At this stage there are few packages that will need fixing as shown in the copr project: https://copr.fedorainfracloud.org/coprs/kwizart/opencv4/builds/ (resubmit might still be in progress). Any help is welcomed in the process.The plan is to push and rebuild dependency once every build failures will be fixed in copr (or if the dependency can be built with opencv disabled until fixed). Please apply for the copr project acl if you want to submit any build attempt yourself. (please don't use koji scratch build as opencv 4 is in master but isn't built). Tracked in ticket: https://bugzilla.redhat.com/show_bug.cgi?id=1697254 -- - Nicolas (kwizart) ___ 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: libdav1d SONAME bump
Le ven. 11 oct. 2019 à 16:33, Xavier Bachelot a écrit : > > Le 11/10/2019 à 16:10, Robert-André Mauchin a écrit : > > Hello, > > > > Dav1d 0.5.0 was published today and brings a SONAME bump from libdav1d.so. > > 2.0.0 to libdav1d.so.3.0.0. > > I will be updating it next week on F31/32, consumers of these libraries > > (ffmpeg, xine-lib, vlc) will need to rebuild their packages. > > > > This is too late for F31, we're past beta. > thttps://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#beta-to-pre-release. > > Are there any other consumers than RPM Fusion packages ? > If not, shall we make an exception ? I'm neither +1 nor -1 on this, I > don't even know if xine-lib would rebuild. > Leigh, Nicolas, what do you think ? This kind of situation is very difficult to deal with when in a fedora freeze period. For me it's impossible to update on the fedora side. Also I haven't any feedback on what will break or not, so this really has to be f32 only material unfortunately (or upstream has to learn not to break ABI). One workaround to have Dav1d in f31 would be to have a snapshot, so we could use the new ABI before freeze. (at least). On a side note, we already provides docker images of ffmpeg, so if one wants newer components based on rawhide it's a matter to pull the images. See also https://hub.docker.com/r/rpmfusion/ffmpeg -- - Nicolas (kwizart) ___ 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: Don't add default contents in `fedpkg request-branch` tickets Was: Re: can we merge package.cfg into master
Le jeu. 3 oct. 2019 à 21:40, Pavel Raiskup a écrit : > > On Friday, September 27, 2019 6:29:54 PM CEST Sérgio Basto wrote: > > On Fri, 2019-09-27 at 12:06 -0400, Neal Gompa wrote: > > > On Fri, Sep 27, 2019 at 12:03 PM Sérgio Basto > > > wrote: > > > > Hi, > > > > epel 8 brings a new file called package.cfg, I strongly prefer to > > > > keep > > > > branches mergeable with fast forward , may we merge this into > > > > master ? > > > > like I did in pngquant [1] > > > > > > > > > > It disables the normal build behavior for all non-master branches, so > > > you don't want to do that. > > > > Well , I want keep my branches mergeable ! > > Same problem. I came across several epel8 branch requests ... and there > always is some default 'package.cfg' file I don't really mind as I > observed (the builds against epel8 just succeed without that). More, > sometimes the README.md is added. I've tried to report the issue here: (although it's for another use-case). https://pagure.io/fedpkg/issue/354 Allowing to have the same package.cfg to describe the appropriate behaviour for all branches would be nice. But there is probably a need to improve the package.cfg format and associated behavior. > Could we stop doing that? Unless it is really reasonable, I don't plan to > make differences in maintained branches, and to achieve that with the > current approach -- I have to go the ugly way (merge epel8 to master and > vice versa, so histories in all branches are ugly forever). I don't get why people use that, it doesn't solve the problem but make it worse. Best is to merge newer branches into olders and avoid any merge commit in master. (some projects forbid that). ___ 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: Which arch should we add to Copr?
Le mar. 17 sept. 2019 à 15:51, Dan Horák a écrit : > > On Tue, 17 Sep 2019 15:01:48 +0200 > Miroslav Suchý wrote: > > > Dne 17. 09. 19 v 13:12 Dan Horák napsal(a): > > > sounds great, but are they using a real hw or are they emulated (and > > > how)? > > > > It will be emulated using --forcearch > > https://github.com/rpm-software-management/mock/wiki/Feature-forcearch > > hm, as much as I would like to have more arches in Copr, I don't think > the emulation is production quality. Recent changes in glibc exposed > hard-to-find bugs in the s390x TCG in qemu and I saw at least one > emulation related bug for armv7 as well. > > What blocks you from using armv7 VMs on aarch64 hosts? Or even using armv7hl "chroot" on aarch64 host ? As we are not supposed to be emulated once the hw support it and the kernel is built with COMPAT (which in the case in Fedora). ___ 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 31 System-Wide Change proposal (late): No i686 Repositories
Le ven. 13 sept. 2019 à 11:44, Dridi Boukelmoune a écrit : > > > Maybe in other distros, people interested in i686 support actually do > > something about it instead of talking and talking and talking about it > > on mailing lists? > > Maybe someone with so much free time on their hands could maintain > such a kernel in Fedora by applying downstream packages of such a > distro. Well... I don't qualify as a person with much free time but... I'm toying with kernel-longterm in a copr for .4.19 branch, and I've enabled i686 there. The rebuilt is a semi-automated way. This i686 build is totally untested, please send patch along to report any issue (or report upstream if relevant). https://copr.fedorainfracloud.org/coprs/kwizart/kernel-longterm-4.19/ Best regards. -- - Nicolas (kwizart) ___ 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 32 System-Wide Change proposal: x86-64 micro-architecture update
Le mar. 23 juil. 2019 à 09:38, Nicolas Chauvet a écrit : > > Le mar. 23 juil. 2019 à 08:30, Igor Gnatenko > a écrit : > > > > On Tue, Jul 23, 2019 at 4:31 AM Igor Gnatenko > > wrote: > > > > > > Hi Florian, > > > > > > On Mon, Jul 22, 2019 at 9:28 PM Ben Cotton wrote: > > > > > > > > https://fedoraproject.org/wiki/Changes/x86-64_micro-architecture_update > > > > > > > > == Summary == > > > > Fedora currently uses the original K8 micro-architecture (without > > > > 3DNow! and other AMD-specific parts) as the baseline for its > > > > x86_64 architecture. This baseline dates back to 2003 > > > > and has not been updated since. As a result, performance of Fedora is > > > > not as good as it could be on current CPUs. > > > > > > > > This change to update the micro-architecture level for the > > > > architecture to something more recent. > > > > > > > > == Owner == > > > > * Name: [[User:fweimer| Florian Weimer]] > > > > * Email: [mailto:fwei...@redhat.com fwei...@redhat.com] > > > > > > > > == Detailed Description == > > > > > > > > After preliminary discussions with CPU vendors, we propose AVX2 as the > > > > new baseline. AVX2 support was introduced into CPUs from 2013 to > > > > 2015. See > > > > [https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#CPUs_with_AVX2 > > > > CPUs with AVX2]. > > > > > > > > Along with AVX2, it makes sense to enable certain other CPU features > > > > which are not strictly implied by AVX2, such as CMPXCHG16B, FMA, and > > > > earlier vector extensions such as SSE 4.2. Details are still being > > > > worked out. > > > > > > It seems that Intel is still manufacturing CPUs without AVX support > > > (not even talking about AVX2) in 2019. So this is clearly no-go for > > > me. > > > > > > But I do want to see some refreshments in this area! There are > > > multiple options how to proceed I think: > > > > > > 1. Lower requirement to something like SSE4 and select other CPU > > > features which are available in most of CPUs for last decade. > > > 2. Build every package on x86_64 twice (one for compatible set and one > > > for this new-features set), possibly by introducting sub-architecture > > > in koji or using koji-shadow (that's just implementation detail. > > > Produce an official spin which is built from these packages. > > > > Thinking about this even more, it should not be very hard thing to do: > > > > * Define new architecture in RPM/libsolv (let's call it "haswell" or > > "x86_64modern") > x86_64avx2 ? or even avx2 ? > > > * Define set of capabilities it should have, write appropriate check > > in RPM/libdnf > > * Add new architecture in Fedora Koji > Do we really need a whole separate architecture ? I expect that > enabling few selected packages to have a second (a third) optimized > build will be enough. > koji already support this. Is this the sub-architecture the proposal > is referring to ? (using koji add-pkg f31 glibc > --extra-arches=EXTRA_ARCHES ... ). > The list of packages having a second optimized build can be as large > as the packages provided by the server spin and any additional > packages that would opt-in. > > Personally, I would like to see some "numbers" of the performance with > avx optimized build (using copr repo on few key packages ). > And I expect optimizing some packages would have low impact, so maybe a ... benchmark need to be done in order to enable an alternate build on a selected set of packages. (previous email sent too early). -- - Nicolas (kwizart) ___ 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 32 System-Wide Change proposal: x86-64 micro-architecture update
Le mar. 23 juil. 2019 à 08:30, Igor Gnatenko a écrit : > > On Tue, Jul 23, 2019 at 4:31 AM Igor Gnatenko > wrote: > > > > Hi Florian, > > > > On Mon, Jul 22, 2019 at 9:28 PM Ben Cotton wrote: > > > > > > https://fedoraproject.org/wiki/Changes/x86-64_micro-architecture_update > > > > > > == Summary == > > > Fedora currently uses the original K8 micro-architecture (without > > > 3DNow! and other AMD-specific parts) as the baseline for its > > > x86_64 architecture. This baseline dates back to 2003 > > > and has not been updated since. As a result, performance of Fedora is > > > not as good as it could be on current CPUs. > > > > > > This change to update the micro-architecture level for the > > > architecture to something more recent. > > > > > > == Owner == > > > * Name: [[User:fweimer| Florian Weimer]] > > > * Email: [mailto:fwei...@redhat.com fwei...@redhat.com] > > > > > > == Detailed Description == > > > > > > After preliminary discussions with CPU vendors, we propose AVX2 as the > > > new baseline. AVX2 support was introduced into CPUs from 2013 to > > > 2015. See > > > [https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#CPUs_with_AVX2 > > > CPUs with AVX2]. > > > > > > Along with AVX2, it makes sense to enable certain other CPU features > > > which are not strictly implied by AVX2, such as CMPXCHG16B, FMA, and > > > earlier vector extensions such as SSE 4.2. Details are still being > > > worked out. > > > > It seems that Intel is still manufacturing CPUs without AVX support > > (not even talking about AVX2) in 2019. So this is clearly no-go for > > me. > > > > But I do want to see some refreshments in this area! There are > > multiple options how to proceed I think: > > > > 1. Lower requirement to something like SSE4 and select other CPU > > features which are available in most of CPUs for last decade. > > 2. Build every package on x86_64 twice (one for compatible set and one > > for this new-features set), possibly by introducting sub-architecture > > in koji or using koji-shadow (that's just implementation detail. > > Produce an official spin which is built from these packages. > > Thinking about this even more, it should not be very hard thing to do: > > * Define new architecture in RPM/libsolv (let's call it "haswell" or > "x86_64modern") x86_64avx2 ? or even avx2 ? > * Define set of capabilities it should have, write appropriate check > in RPM/libdnf > * Add new architecture in Fedora Koji Do we really need a whole separate architecture ? I expect that enabling few selected packages to have a second (a third) optimized build will be enough. koji already support this. Is this the sub-architecture the proposal is referring to ? (using koji add-pkg f31 glibc --extra-arches=EXTRA_ARCHES ... ). The list of packages having a second optimized build can be as large as the packages provided by the server spin and any additional packages that would opt-in. Personally, I would like to see some "numbers" of the performance with avx optimized build (using copr repo on few key packages ). And I expect optimizing some packages would have low impact, so maybe a Nicolas (kwizart) ___ 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: true or false: pkgconfig(foo) vs foo-devel
Le ven. 19 juil. 2019 à 10:33, Nicolas Mailhot via devel a écrit : > > Le vendredi 19 juillet 2019 à 08:48 +0200, Remi Collet a écrit : > > Le 18/07/2019 à 18:26, Nicolas Chauvet a écrit : > > > > "Build dependencies on Fedora packages which provide pkg-config > > > > files SHOULD be expressed > > > > as pkgconfig(foo) and not foo-devel, whether the dependent > > > > package uses pkg-config or not." > > > > > > This is true for the fast majority of cases. Specially where there > > > is > > > only one provider of pkgconfig(foo). > > > > > > But sometime there is a need for a compat library and then I don't > > > know if my package may uses the main library of the compat one. > > > pkgconfig(foo) will pick one or the other, but using the package > > > name > > > is more deterministic to me. > > > > > > > Indeed, pkgconfig(foo) start to raise issues when multiple providers > > exists. > > > > One example is pkgconfig(openssl) > > In quite a lot of cases versionned requires can disambiguate Enforcing a higher version than what the project really support doesn't seem appropriate. You will have to deal with some fedora specific macros to enforce the version in related branches. It defeats the point to use a clean and agnostic method to determine the dependencies based on the project needs and instead relies on any "state" of the repository. A way to solve this is to enforce a policy where compat libraries must disable pkgconfig automatic provide to dis-allow such unexpected behavior. Looking at compat-openssl10, it doesn't seem to be done. Assuming the right library will be picked because the compat- prefix will weight negatively on the build requirements seems fragile. One build dependency can switch to compat, such packages dependency could then end making the switch silently in the same time. -- - Nicolas (kwizart) ___ 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: true or false: pkgconfig(foo) vs foo-devel
Le jeu. 18 juil. 2019 à 17:12, Philip Kovacs via devel a écrit : > > > It does not matter if the config process uses pkgconfig or not. > > Depending on the package name is not a way to state you're not using > > pkgconfig, it's a way to get broken builds when the package you depend > > on gets restructured. > > Then the docs should be strengthened to state the case from the perspective > of the provider > of the .pc and not the consumer of it: > > Current: > > "Fedora packages which use pkg-config to build against a library (e.g. 'foo') > on which they depend, > SHOULD express their build dependency correctly as pkgconfig(foo)." > > becomes: > > "Build dependencies on Fedora packages which provide pkg-config files SHOULD > be expressed > as pkgconfig(foo) and not foo-devel, whether the dependent package uses > pkg-config or not." This is true for the fast majority of cases. Specially where there is only one provider of pkgconfig(foo). But sometime there is a need for a compat library and then I don't know if my package may uses the main library of the compat one. pkgconfig(foo) will pick one or the other, but using the package name is more deterministic to me. -- - Nicolas (kwizart) ___ 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: Orphaned python2-django1.11
Le mer. 19 juin 2019 à 15:16, Petr Viktorin a écrit : > > Hello, > Back when [Django 2.0] was released in Fedora 28, I took over Django > 1.11 LTS as some important (to me) packages depended on it. I'm no > longer interested in maintaining it, so I've orphaned it. > Let me know if you want to take it. If no one does, it may be removed > from Rawhide in 6 weeks. > > Depending packages and their maintainers are: > - fts-monitoring (andreamanzi, simonm) > - python-oauth2client (mbaldessari, ralph) > - cobbler-web (jimi, kwizart, orion, shenson) > > Let me know if you need help with these packages. I will take-over the python2-django1.11 as cobbler_web uses it (until moved to python3 soon). Thx -- - Nicolas (kwizart) ___ 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: Nvidia GPU overclocking in Fedora Silverblue 30 is currently broken
Le mar. 9 juil. 2019 à 09:42, Ty Young a écrit : For more clarity, please answer in bugzilla (either as new RFE or the current report). > > With that said, the appropriate doc is here: > > https://rpmfusion.org/Howto/NVIDIA > > It is only mentioned to install akmod-nvidia and xorg-x11-drv-nvidia > > that's the interface we rely on. (Everything else should be > > auto-detected on purpose). > > Also to wait a few for the module to build and install and reboot > > (it's explicitly required). > > > That gets you a working driver but not OpenGL or any of the core Nvidia > driver utils/libs such as nvidia-smi, nvidia-settings, nvidia-xconfig, > etc. If you try to install Steam for example it will blow up real bad. If you install steam from flatpak, we cannot know which tools are needed on the "host" side, so this become a documentation issue. The "no OpenGL driver" is a situation that cannot arise with the nvidia packaged driver because we rely default to install it. So it's more probably a delay between the availability of the nvidia-gl overlay ? I'm not sure to understand what you mean here. Unless you mean the OpenGL.so over the "legacy" libGL.so ? > >> -nvidia-settings is the Linux alternative to Window's control panel and if > >> not included by default, *should* be included via a "meta" package for > >> desktop users. > > It's a separate package, but it is required by the drivers as it's > > mandatory indeed. So I don't understand the metapackage thing, it's a > > solution for others distros, the Fedora ways is different. (virtual > > provides , booleans dependencies, etc). > > > If memory serves me correctly nvidia-settings *is* silently installed > but not explicitly. In other words, you can see and launch the > application in Gnome 3 without explicitly installing it but doing: > > > rpm-ostree install nvidia-settings > > > Will still work and "install" the package despite it already been > installed. I'll have to do another reinstall and install just the driver > to make sure. Could be smoking shrooms here but I remember it being there... > > > I'd like to pose the question though, is this really a good thing? > People don't like it when you silently install things behind their back. > A meta package(at least in the form I'm thinking of) is different as it > points to other packages and says to install those packages. If you want > more information on what those packages contain you should be able to > lookup what each package provides. A meta package is yet-another-package that do not provide any content. It's totally spurious in Fedora packaging land. (over boolean deps, virtual provides, etc). The other point is that usually, you should enable the nvidia driver from the "software" application. On regular fedora the rpmfusion-nonfree-nvidia-driver is selectable from the interface (don't know about silverblue, but it was intended). You just have to install the driver by selecting it, so you don't even have to worry about the gory details of the packaging name. > >> -it isn't clear if the command I posted(above) installs the 32-bit > >> libraries or not. Really, meta packages would go a long way in simplifying > >> GPU driver installs! > > In regular Fedora, it will install the 32bit libraries on purpose with > > the nvidia driver if you have at least a package that requires 32bit > > libGL. (same for cuda-libs). > > > That doesn't work for 32-bit games though since they don't use the > package manager and Steam does need 32-bit libs if not installed via > Flatpak. Yes, Steam provides many 32-bit libs but as they have said > during the whole Ubuntu 32-bit support mess, they still use system libs. > Which libs? I don't know, they'd probably have a good idea. Theses libs are know as soon as the support > It isn't possible to play Proton games using Fedora Steam but is > possible with Flatpak Steam for example which I can only assume is > because of missing 32-bit libs. Installing Wine would probably pull in > the requires 32-bit libs since Proton is Wine... No, this is wrong, I have proton support in regular Fedora. with the steam package from RPM Fusion. > >> Neither Windows nor even other Linux distros fragment the driver this > >> much. You'd have to add 32-bit libraries alongside the 64 bit driver and > >> 64 bit libraries to equal Fedora's fragmented driver packaging in some > >> distros. Why? > > Well, It could be worst. You could have sub-packages depending on the > > need to run headless or without Xorg or without wayland dependencies > > etc. > > That's constraints you might not have, but a good packaging should > > works everywhere. > > > I've never heard of a situation where you would *just* want the driver > and *not* (at the very least) OpenGL support. Are there any examples? > Can CUDA be used without OpenGL? Yes, only few cuda functions requires OpenGL interrop, > > > > With that said the rpm-ostree line you have used is silly with respect > > to the need to llst all sub-pa
Re: Nvidia GPU overclocking in Fedora Silverblue 30 is currently broken
Le lun. 8 juil. 2019 à 21:29, Ty Young a écrit : > > Bug filed: https://bugzilla.rpmfusion.org/show_bug.cgi?id=5307 > > The driver itself seems perfectly fine in that the system boots and OpenGL > works perfectly fine. Games are playable. > > How do I output strace to a file directly? It spits out way too much info. > > The bug is reproducible by doing a fresh install on a new downloaded ISO but > really the likelihood that this is a bug caused by Nvidia is slim to none. > Arch Linux(what I primarily use) has the same driver version and everything > works perfectly fine. > > Regardless of whether or not this specific bug was by a packaging issue or > Nvidia, the way Fedora packages the Nvidia drivers is bad: > > -nvidia-smi isn't specific to CUDA and is a core Nvidia library interface > that should come with the base driver as it does in Windows. That's moot, but the comparison with nvidia on Windows is not relevant. if you want nvidia-smi, please install xorg-x11-drv-nvidia-cuda Previously nvidia-smi relied on any cuda lib, so it was moved on the cuda side, but we can re-evaluate this, I take take a RFE. With that said, the appropriate doc is here: https://rpmfusion.org/Howto/NVIDIA It is only mentioned to install akmod-nvidia and xorg-x11-drv-nvidia that's the interface we rely on. (Everything else should be auto-detected on purpose). Also to wait a few for the module to build and install and reboot (it's explicitly required). > -nvidia-settings is the Linux alternative to Window's control panel and if > not included by default, *should* be included via a "meta" package for > desktop users. It's a separate package, but it is required by the drivers as it's mandatory indeed. So I don't understand the metapackage thing, it's a solution for others distros, the Fedora ways is different. (virtual provides , booleans dependencies, etc). > -OpenGL not packaged with the driver(or again, install-able via a meta > package)? Who wants a graphics driver without OpenGL/Vulkan support? Well, some people want to have selectables sub-packages as appropriate, and the split made by RPM Fusion is carefully minded. But we still welcome improvements. > -it isn't clear if the command I posted(above) installs the 32-bit libraries > or not. Really, meta packages would go a long way in simplifying GPU driver > installs! In regular Fedora, it will install the 32bit libraries on purpose with the nvidia driver if you have at least a package that requires 32bit libGL. (same for cuda-libs). > Neither Windows nor even other Linux distros fragment the driver this much. > You'd have to add 32-bit libraries alongside the 64 bit driver and 64 bit > libraries to equal Fedora's fragmented driver packaging in some distros. Why? Well, It could be worst. You could have sub-packages depending on the need to run headless or without Xorg or without wayland dependencies etc. That's constraints you might not have, but a good packaging should works everywhere. With that said the rpm-ostree line you have used is silly with respect to the need to llst all sub-packages. Can you point me to the documentation you have used ? Thx -- - Nicolas (kwizart) ___ 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: Nvidia GPU overclocking in Fedora Silverblue 30 is currently broken
Le lun. 8 juil. 2019 à 16:30, Ty Young a écrit : > > Hi, > > > To whoever is packaging the Nvidia GPU driver in Fedora / RPM Fusion, > overclocking support is currently broken. Not even nvidia-settings is > able to set a GPU core offset value via GUI despite a correct coolbits > value being set. This use to work some updates ago. Wayland is not being > used. > > > Command used to install the driver and related utils: > > > rpm-ostree install kmod-nvidia xorg-x11-drv-nvidia > xorg-x11-drv-nvidia-libs nvidia-settings nvidia-xconfig > xorg-x11-drv-nvidia-cuda xorg-x11-drv-nvidia-cuda-libs > > > Attempting to set an overclocking value via command line just results in > an "unknown error" message. nvidia-settings doesn't even know what's > going on in Fedora Silverblue 30. > > > Can this please be looked into & fixed? Not yet, you need to provide more useful info as stated in the RPM Fusion wiki https://rpmfusion.org/Howto/NVIDIA#Bug_Report Once we can determine the driver is in good state, a strace log of nvidia-settings would be useful. Please report to bugzilla.rpmfusion.org for now, but if it's reproducible and not related to packaging, you will have to forward to nvidia directly. Thx -- - Nicolas (kwizart) ___ 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: glibc-headers troubles with rawhide on ARM
Le mer. 3 juil. 2019 à 04:35, David Airlie a écrit : > > On Tue, Jul 2, 2019 at 10:57 PM Olivier Fourdan wrote: > > > > Hi, > > > > On Tue, Jul 2, 2019 at 2:22 PM Peter Robinson wrote: > > > On Mon, Jul 1, 2019 at 12:02 PM Florian Weimer wrote: > > > > [...] > > > > > > > > on Arm hasn't worked for a long, long time, so we've removed > > > > it from glibc. Sorry it broke the build. > > > > > > It seems xorg-x11-server was also using this in it's builds: > > > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=35892190 > > > > Precisely, that's why I raised the issue here :) > > > > FWIW, I managed to get the Xserver to build by removing the `#include > > ` and references to outb/outw/outl : > > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=35981723 > > > > But I don;t think it'll fly with the Xorg drivers, as those are most > > likely the consumers of outb/outw/outl. > > > > So I filed https://gitlab.freedesktop.org/xorg/xserver/issues/840 > > upstream to gauge the water and see what we can do. > > Any driver that does port io. should probably not be built on ARM, > unless the port io can be disabled anyways. The opentegra DDX driver uses xorg/compiler.h (that you didn't touched in the freedesktop PR) but doesn't seems to rely on outb/outw/outl, so I will see if this driver can be built without it. For the opentegra case, here an info about why it can still be considered relevant over the modesetting driver https://bugzilla.redhat.com/show_bug.cgi?id=1606757#c5 Basically, it still relies on "WIP" libdrm until the kernel tegra driver abi is reworked... Thx Thx -- - Nicolas (kwizart) ___ 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: GCC / annobin changes in F30
Le ven. 28 juin 2019 à 06:03, Michael Cronenworth a écrit : > > Hi, > > I was attempting to package the Kodi 18.3 update for RPMFusion but ran into a > compiler > error very early in the build. GCC outputs the following type of messages: > > cc: error: .annobin-Wl,-wrap,_IO_getc.end: No such file or directory > cc: error: .annobin-Wl,-wrap,_IO_getc.start: No such file or directory > ...snip... > cc: error: .text.-Wl,-wrap,_IO_getc.group: No such file or directory > cc: error: .text.-Wl,-wrap,_IO_getc_unlocked.group: No such file or directory > ...snip... IIRC, the problem we had with kodi buildsys is that every compiler option that isn't known isn't wrapped as appropriate. So if a new annobin option is used, it has to be declared to an exception list. Please have a look (and update) kodi-18-annobin-aarch64-workaround.patch as appropriate. Thx -- - Nicolas (kwizart) ___ 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: glibc-arm-linux-gnu help
Le mer. 12 juin 2019 à 10:50, Elliott Sales de Andrade a écrit : > > On Mon, 10 Jun 2019 at 16:46, Tom Callaway wrote: > > > > Reviving this. I do not have the time nor the energy to attempt to keep > > this going, so I am going to disable the shared bits in cross-gcc and kill > > off glibc-arm-linux-gnu. It's been broken for a while, so I doubt anyone > > will be seriously impacted by this. > > Ah that's unfortunate. I've been working on something that could > possibly make use of this, but I haven't quite reached the stage of > testing this out with it, and since it wasn't in Rawhide, I hadn't > taken much look into it. > > I see that Debian has pretty much every cross version of libc6: > https://packages.debian.org/search?keywords=libc6&searchon=names&suite=all§ion=all > > What makes it so easy for them? / What makes it difficult for us? How > can we make cross toolchains easier? Probably time/human ressources. I would be interested in having a working cross compilation toolchain also (specially for case where 32bit linking is an issue like chromium or else). I have tried to work on some patches (including kernel-headers), but not had time to fully qualify the changes. FYI, I've tried to contact the maintainer of the copr repo pointed by Tom, so far no answer. Looking at some of his copr contributions, he haven't found the right step to contribute to fedora main repository yet (also others topics). This is unfortunate and I fear this situation is going to increase with users kept in their copr projects... -- - Nicolas (kwizart) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: /etc/yum.repos.d -> /etc/distro.repos.d
Le mer. 13 mars 2019 à 13:39, Miroslav Suchý a écrit : > > Hi, > I am curious whether we can move our repo files from > /etc/yum.repos.d > to > /etc/distro.repos.d I don't see the point to "change" this directory for "pleasure" if it doesn't come with more features. Right now yum.repos.d should be understood by "yum or compatible" repository definitions. I'm totally against using /etc/distro.repos.d as such. Now if we can have a way to distribute default distro repos in /usr/lib/distro.repos.d/fedora.repo and to be able to override some options in /etc/distro.repos.d/fedora.repo such as (1). Then it might be interresting behavior change. (1) [fedora] enabled=0/1 baseurl=myinternalmirror.example.net etc. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Donate 1 minute of your time to test upgrades from F29 to F30
Le jeu. 28 févr. 2019 à 10:23, Miroslav Suchý a écrit : > > Do you want to make Fedora 30 better? Please spend 1 minute of your time and > try to run: > > sudo dnf --releasever=30 --setopt=module_platform_id=platform:f30 > --enablerepo=updates-testing distro-sync As the issue was raised already, please remind that RPM Fusion (free/nonfree) users can use the following command: sudo dnf --releasever=30 --setopt=module_platform_id=platform:f30 --enablerepo=updates-testing distro-sync --enablerepo=rpmfusion-free-rawhide,rpmfusion-nonfree-rawhide This until fedora 30 is branched on our side (which should be done in the next weeks, once the mass rebuild is done). Then please remind to forward any issue to the related https://bugzilla.rpmfusion.org Thx in advances. -- - Nicolas (kwizart) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fixing Wireguard spec file
Le mar. 29 janv. 2019 à 16:33, Germano Massullo a écrit : > > This [1] is the Wireguard spec file from upstream Copr repo [2]. > Wireguard will be included in kernel 5.0, but meanwhile we are using it as > dkms. There is a wireguard package maintained by Robert-André Mauchin on RPM Fusion that at least... works. -- - Nicolas (kwizart) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: RFC: make fedora-release archful and add some provides
Le ven. 14 déc. 2018 à 20:34, Igor Gnatenko
a écrit :
>
> Hello folks,
>
> for long time we have problem if you have some arch-specific
> BuildRequires, you still get one src.rpm from one of arches (not sure
> how koji chooses that one) which might not work for your architecture.
>
> For example if you have following in spec:
> %ifarch %{ldc_arches}
> BuildRequires: ldc
> %endif
>
> And the src.rpm is taken by koji from x86_64 (included in
> %{ldc_arches}), then you won't be able to run `dnf builddep foo`,
> because it will complain that ldc package is missing.
>
> PROPOSAL:
> 1. make fedora-release archful
> 2. add Provides: system-architecture($arch) to fedora-release, where
> $arch is architecture name
> 3. use Requires: (foo if (system-architecture(x86_64) or
There is already the filesystem(x86_64) arched provide from the
filesystem package
(no need to turn a legitimate noarch package into an arched one for this).
I think the general idea is good.
--
-
Nicolas (kwizart)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fwd: Soname break for glew
I'm preparing an update for glew to 2.1.0 (with soname bump) (pushed in rawhide but not built yet). https://koji.fedoraproject.org/koji/taskinfo?taskID=29087244 Given that the freeze break is next week, I will push the update in rawhide, then in f29 next. Here are the dependencies: FlightGear-Atlas-0.5.0-0.46.cvs20141002.fc29.src.rpm OpenColorIO-1.1.0-7.fc29.src.rpm amanith-0.3-39.fc29.src.rpm avogadro-1.2.0-20.fc29.src.rpm avogadro2-libs-1.91.0-0.2.20180612gitda6ebb9.fc29.src.rpm blender-2.79b-6.fc29.src.rpm camotics-1.1.1-13.fc29.src.rpm cegui-0.8.7-11.fc29.src.rpm cegui06-0.6.2-29.fc29.src.rpm compat-SFML16-1.6-18.fc29.src.rpm dreamchess-0.3.0-0.3.20180601git.fc29.src.rpm endless-sky-0.9.8-6.fc29.src.rpm freeorion-0.4.7.1-11.fc29.src.rpm gambas3-3.11.4-1.fc29.src.rpm gimp-normalmap-1.2.3-17.fc28.src.rpm gource-0.48-1.fc28.src.rpm hugin-2018.0.0-2.fc28.src.rpm hyperrogue-10.0-5.d.fc29.src.rpm k3d-0.8.0.6-16.fc29.src.rpm kalzium-18.04.3-1.fc29.src.rpm kicad-5.0.0-2.fc29.src.rpm libprojectM-2.1.0-8.fc29.src.rpm linphone-3.6.1-27.fc29.src.rpm logstalgia-1.1.2-2.fc29.src.rpm megaglest-3.12.0-7.fc29.src.rpm mesa-demos-8.3.0-11.fc29.src.rpm meshlab-2016.12-6.fc29.src.rpm openclonk-8.1-4.20180321git570ba7a.fc29.src.rpm opencsg-1.4.2-7.fc29.src.rpm openmsx-0.14.0-7.fc29.src.rpm openscad-2015.03.3-17.fc29.src.rpm paraview-5.5.2-16.fc29.src.rpm pymol-2.1.0-3.20180321svn4187.fc29.src.rpm quesoglc-0.7.2-21.fc29.src.rpm root-6.14.02-1.fc29.src.rpm rss-glx-0.9.1.p-35.fc29.src.rpm scorched3d-44-16.fc29.src.rpm sdljava-0.9.1-41.fc29.src.rpm slop-7.4-3.fc29.src.rpm spring-100.0-13.fc28.src.rpm supertux-0.5.1-12.fc29.src.rpm supertuxkart-0.9.3-2.fc29.4.src.rpm toped-0.9.81-18.svn2211.fc28.src.rpm warzone2100-3.2.3-7.fc29.src.rpm widelands-0-0.66.build19.fc29.src.rpm wt-4.0.3-1.fc29.src.rpm wxmacmolplt-7.7-9.fc29.src.rpm -- - Nicolas (kwizart) -- - Nicolas (kwizart) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/HLD22BK5FUPBTTZTT4BDL7RXQZZARER7/
Re: Unannounced SONAME bump for libssh
Le ven. 17 août 2018 à 16:05, Michael Cronenworth a écrit : > > The libssh package uses wildcards on SONAME version. The package was upgraded > from > 0.7.5 to 0.8.1 in Fedora 27+ that included a SONAME bump. I don't see any SONAME bump libssh.so.4 is still used in both packages version in f28 at least. That been said, there are some unusual things with libssh_threads.so.4 merged with libssh.so.4 Some packages that are failing still uses libssh_threads.so.4 (1) The failure seems caused by a missing symlink from libssh_threads.so.4 to the real library (using libssh.so.4 SONAME) That was with libssh-0.8.1-3.fc28.x86_64. According to rpm -V libssh, seems like the symlink is correctly present in the package and was corrupted on the filesystem. Using dnf reinstall libssh solved the failure for me. There was probably an issue with the transition to the new library from the package history. I would recommends packages still using libssh_threads.so.4 to switch to libssh.so.4 despite the compat layer present in libssh that is broken for some reason... (1) Failing packages according to dnf repoquery: remmina-0:1.2.0-0.51.20180408.git.6b62986.fc28.x86_64 remmina-plugins-nx-0:1.2.0-0.51.20180408.git.6b62986.fc28.x86_64 x2goclient-0:4.1.1.1-1.fc28.x86_64 x2goplugin-0:4.1.1.1-1.fc28.x86_64 -- - Nicolas (kwizart) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OQ5YPY5YX7BALWXADTNCPVBJO5JMYCNJ/
Re: Fedora crda To wireless-regdb Upgrade
2018-07-20 20:47 GMT+02:00 John W. Linville : [...] > QUESTIONS > > Are there reasons to oppose the Obsolete/Provides upgrade path from > crda to wireless-regdb? Would it be desirable to require users to > manually intervene by installing wireless-regdb by hand? FWIW, I do not > see any benefit from requiring any manual steps. The main issue with Obsoletes/Provides of crda is that if any user want to maintain a self compiled kernel < 4.15. Then this kernel will suddenly loose wireless support whereas it was previously working. This is also a problem if using various kernel version to bissect a wireless regression. What I would recommend instead is to : - have everything set for wireless-regdb to be installed by default in f29+ (comps,ks,package dependency). - eventually obsoletes/provides crda only on f29+ - for fedora < 29 have crda to require wireless-regdb, so current users will migrate to the new method. (that way they can even manually remove crda and keep wireless-regdb if they like to). This doesn't seem that complicated to handle as a transition that way. -- - Nicolas (kwizart) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ZSJEE4E6RRPA2WTT5BXMY3Y5BCCCF7UV/
libupnp ABI change notice
Hi, I plan to update libupnp to 1.8.3 which comes with an ABI bump. The libthreadutil library is also dropped in this new release. I will rebuild the dependent applications f29 scratch build https://koji.fedoraproject.org/koji/taskinfo?taskID=26339066 On a side note, I've also updated the current branches to the latest 1.6.25 bugfix release. Please report any issue in the related bodhi tickets -- - Nicolas (kwizart) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
"libcryptopp update to 6.1.0 with ABI change"
Hi, I plan to update cryptopp to 6.1.0 release for f28+ later today. This will not change the ABI number, because our package was previously patched with a forged SONAME to only use the one number convention (aka libcryptopp.so.6 instead of libcryptopp.so.6.0). The good news, is that upstream accepted my patch to freeze the ABI with .6, with this lts version. So for more safety, there is a need to rebuild the few packages using this library: clementine libndn-cxx pycryptopp tegrarcm (I will handle this one) Thx -- - Nicolas (kwizart) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F28 Self Contained Change: VA-API 1.0.0
2018-02-16 14:35 GMT+01:00 Zbigniew Jędrzejewski-Szmek : > On Fri, Feb 09, 2018 at 08:07:20AM +, Zbigniew Jędrzejewski-Szmek wrote: >> On Mon, Jan 29, 2018 at 11:06:05PM +0100, Jan Kurik wrote: >> > = Proposed Self Contained Change: VA-API 1.0.0 = >> > https://fedoraproject.org/wiki/Changes/VA-API_1.0.0 >> > >> > Change owner(s): >> > * Nicolas Chauvet >> > >> > This change is about upgrading libva and others to version 2.0. This >> > change affects several multimedia players as there are both API and >> > ABI changes. This will allow some VA-API backends to be updated, >> > improving support for recent hardware. >> > >> > == Detailed Description == >> > >> > Updating to VA-API 1.0.0 will allow to fix and clean-up issues with >> > the API as sum-up in this upstream topic VA-API 1.0.0: >> > https://github.com/intel/libva/issues/72 >> > >> > * fix errors in API/data structure definition, e.g. 01org#32 >> > * add new features, e.g. 01org#69, >> I guess those are tickets in a bugtracker... Can you add hyperlinks? >> >> > * deprecate some useless API/data structures, e.g. libva-tpi, libva-egl. >> > * provide other improvement, e.g. use portable type to define data >> > structure. >> > >> > All packages using libva will be rebuilt to take into account the new >> > API/ABI. Futhermore, the intel backend will be updated along (not >> > provided by Fedora). Others VA-API backend such the AMD and NVIDIA >> > backend provided by Fedora within mesa-dri-drivers will work as >> > appropriate. Bridges between VA-API and VDPAU will continue to be >> > supported , this is: >> >> > Upgrade/compatibility impact >> > Users should update to the more recent version provided in repositories. >> >> Hmm, isn't the biggest compatibility impact that the library .so >> version will be bumped and all users will have to be rebuilt? >> Do we know how much software outside of the distro itself is linked >> to those libraries? >> I think it'd be good to make this explicit in the change page. >> >> Zbyszek > > Ping. Sorry for the lack of answer, was editing the wiki. Thx for rising the point of packages outside fedora. At least I can enumerate the packages that are into a well known repository (that are already dealt with), but I don't know if there are other projects using it that are not packaged, or outside a well known repository. Do you want me to add a list of packages that will support the new libva ? Thx -- - Nicolas (kwizart) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: libcdio soname bump in rawhide
2018-01-19 9:15 GMT+01:00 Adrian Reber : > On Fri, Jan 19, 2018 at 06:50:16AM +0100, Nicolas Chauvet wrote: >> 2018-01-18 22:25 GMT+01:00 Adrian Reber : >> > libcdio upstream released the 2.0 version a few weeks ago and I will >> > updated rawhide to the latest libcdio version. It comes with a new >> > soname and I will also rebuild all dependencies. >> >> Can you wait a week at least ? We are in the middle of a rebuild in >> third part side that might need more time to land. >> We won't be able to rebuild the packages in time there. > > Sure, I was planning to do it late next week, but I can wait a bit > longer if it helps. Let me know when you are ready. Hi Adrian, I think we are ready enough for libcdio update. thx -- - Nicolas (kwizart) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: libcdio soname bump in rawhide
2018-01-18 22:25 GMT+01:00 Adrian Reber : > libcdio upstream released the 2.0 version a few weeks ago and I will > updated rawhide to the latest libcdio version. It comes with a new > soname and I will also rebuild all dependencies. Hi Adrian, Can you wait a week at least ? We are in the middle of a rebuild in third part side that might need more time to land. We won't be able to rebuild the packages in time there. Thx -- - Nicolas (kwizart) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Pulling in rpmfusion appstream data with weak dependencies?
2018-01-18 20:21 GMT+01:00 Neal Gompa : > On Thu, Jan 18, 2018 at 2:19 PM, Matthew Miller > wrote: >> On Thu, Jan 18, 2018 at 01:02:49PM -0600, Dennis Gilmore wrote: >>> The only way to really do this would be to make rpmfusion-release >>> require it. However that will mean users have to download and install >>> two packages to make it all work. That may break things for people who >>> intentionally remove gnome-software and PackageKit >> >> Does DNF process new Recommends? The -release package could Recommend >> it rather than Require it. In fact, couldn't it even do: >> >> Recommends: (other-repo-appstream if (PackageKit or gnome-software)) I wondered that too at one point. But It would lead to a race. The dnf .repo files would not be installed yet, and then the rpmfusion-*appdata couldn't be found. Maybe it will work on the next dnf transaction ? If someone could test ? -- - Nicolas (kwizart) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Pulling in rpmfusion appstream data with weak dependencies?
2018-01-18 20:02 GMT+01:00 Dennis Gilmore : > The only way to really do this would be to make rpmfusion-release > require it. However that will mean users have to download and install > two packages to make it all work. That may break things for people who > intentionally remove gnome-software and PackageKit That would indeed not scale for cases where appdata are not relevant (others spins, server, headless multimedia, etc). I would like to avoid such miss-design where we would need to split into rpmfusion-*-release-workstation or other products. It would just move the problem without fixing it. At which point it would be just easier to add the complementary appdata packages to install along the rpmfusion-*-release packages from our "Configuration" page. One other method is to use Groups. The rpmfusion*-appdata files could be added to the appropriate comps group. That way it will be a matter to update the group after the releases packages are installed. This is similar than what can be done for multimedia with a "dnf groupupdate Multimedia". It would need to be updated manually (which I beleive was done automatically with earlier release but it's not the point anymore). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Update to VA-API 1.0.0 (libva-2.0.0 with SONAME bump)
Hi, I plan to update libva to 2.0.0. It comes with a SONAME bump. (and libva-egl and libva-tpi library removed, but it's not used anywhere) Because of the SONAME, this is fedora 28 only material. Here is the full list of dependencies to be rebuilt: dnf repoquery --whatrequires libva.so.1\* --source avidemux-2.7.0-3.fc27.src.rpm cmrt-1.0.6-4.fc27.src.rpm ffmpeg-3.3.5-4.fc27.src.rpm freshplayerplugin-0.3.7-3.fc27.src.rpm gstreamer1-vaapi-1.12.4-1.fc27.src.rpm kodi-17.6-1.fc27.src.rpm libmfx-1.21-3.fc27.src.rpm libva-1.8.3-3.fc27.src.rpm libva-intel-hybrid-driver-1.0.2-4.fc27.src.rpm libva-utils-1.8.3-4.fc27.src.rpm libvdpau-va-gl-0.4.2-6.fc27.src.rpm mpv-0.27.0-1.fc27.src.rpm mythtv-29.0-4.fc27.src.rpm qmplay2-17.12.11-1.fc27.src.rpm qtav-1.12.0-2.gitcbab79e.fc27.src.rpm vdr-softhddevice-0.6.1-11.20151103git6dfa88a.fc27.src.rpm vdr-softhddevice-openglosd-0.6.1-11.20160717git569fde5.fc27.src.rpm vlc-3.0.0-0.44.git20171215rc2.fc27.src.rpm weston-3.0.0-1.fc27.src.rpm xine-lib-1.2.8-4.fc27.src.rpm I plan to do the update later tonight (CET). I might need provenpackager help for libmfx,cmrt, libva-intel-hybrid-driver and weston from the fedora side. I will handle "the others". FYI, I've tested the rebuild using copr (kwizart/vaapi1). Thx -- - Nicolas (kwizart) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Django 2.0 released, and what it means to you
2017-12-12 16:17 GMT+01:00 Miro Hrončok : > On 7.12.2017 10:56, Matthias Runge wrote: >> >> To follow-up on this, I'm drafting a change[1]. Since my >> responsibilities changed, this has a quite low priority for me. >> Any help is greatly appreciated! >> >> Best, >> Matthias >> [1] https://fedoraproject.org/wiki/User:Mrunge/Django20 It would be more simple to introduce a separate python2-django given this package namespace is free. It would just need to be bump at version-release: 1.11.5-2.fc28 because python(2)-django sub-package in f27 is currently at 1.11.5-1 This could even be introduced in epel7 (if python is recent enought there, but then this is a separate issue). Thx -- - Nicolas (kwizart) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Django 2.0 released, and what it means to you
2017-12-06 10:26 GMT+01:00 Matthias Runge : > On Wed, Dec 06, 2017 at 09:56:28AM +0100, Lumir Balhar wrote: >> On 12/05/2017 04:27 PM, Miro Hrončok wrote: >> > Maybe a Fedora Change coordinating this would be nice? > > probably a good idea. > >> > Those are packages that require python(2)-django and are themselves not >> > prefixed with python(2)-django: >> > >> > cobbler-web >> > fts-monitoring >> > gramps-webapp >> > graphite-web >> > kobo-admin >> > kobo-django >> > kobo-hub >> > pony >> > pulp-server >> > >> > I suggest we go trough them and see. At least the kobo thing is probably >> > being ported to 3 by Lumír (CC'ed) > > graphite-web requires Django <= 1.11.99, but has been ported to python3. > >> Kobo is currently tested with Django 1.6 and 1.8. The codebase is ported to >> Python 3 but it needs to be modified to support Django >= 1.11. There are >> some issues but I don't know Django well enough to fix them. >> >> I am not a maintainer nor a user of Kobo but I think that Kobo will need >> python2-django in Fedora. >> > >> > Even if we and up having python2-django, I suggest we remove all the >> > unneeded python2-django-wahtnots anyway and only keep the ones used by >> > the apps. > Yes, this makes sense. > > Going the safe route, we should add the python2 package based on > django-1.11.x and current apps would continue to work. > > Thoughts? cobbler-web would benefit from using such python2-django. (I have a pending PR upstream to support current django-1.xx). Thx -- - Nicolas (kwizart) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora 27 is here
2017-11-15 23:02 GMT+01:00 Nicolas Chauvet : > Hi, > > Just want to say welcome to Fedora 27 ! > > The RPM Fusion repository is ready to server f27 content in time for > the release. However, there are few packages that were broken in the > process. The ones I'm aware are currently fixed and been pushed in the > updates repos. I plan to fixup the GA repo before this week-end to > avoid any issue. > > Thx for the work done. Oops, sorry, was meant for our own devel list. -- - Nicolas (kwizart) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora 27 is here
Hi, Just want to say welcome to Fedora 27 ! The RPM Fusion repository is ready to server f27 content in time for the release. However, there are few packages that were broken in the process. The ones I'm aware are currently fixed and been pushed in the updates repos. I plan to fixup the GA repo before this week-end to avoid any issue. Thx for the work done. -- - Nicolas (kwizart) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Kernel 4.13 rebase plans
2017-09-22 20:46 GMT+02:00 : > Oh boy. :) > > Does anyone know if the fallback is working properly? Because if so, then Just restoring the fact here, because despite the fallback idea is hans/WG the implementation is "RPM Fusion Community" original works. (1) So yet as soon as you are using "RPM Fusion", it works as expected. And furthermore, if you want to switch from nvidia to nouveau while the nvidia driver remains installed, you just need to unblacklist nouveau from cmdline (remove rd.driver.blacklist=nouveau modprobe.blacklist=nouveau). This is only implemented by the RPM Fusion "clean design". And could even be improved: https://bugzilla.redhat.com/show_bug.cgi?id=1489317 if anyone cares... (1) https://bugzilla.rpmfusion.org/show_bug.cgi?id=4498 -- - Nicolas (kwizart) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: getting kernel-devel added
2017-09-12 17:35 GMT+02:00 Ben Williams : > hello > > This is an issue i am seeing with new users: > > I was at a University installfest this weekend and this was the major issues > for Endusers. > > case A) Students are using Fedora on windows in a VM (Vbox in this case) for > a class. they are required for said class to install the guest additions. > they are constantly running into errors that the guest addidions will not > build (there install does not have kernel-devel install. They used the F26 > release so now have the release kernel and so they install sudo dnf install > kernel-devel and still have issues (kernel and kernel-devel versions do not > match). For this very specific issue (where kernel and kernel-devel version does not match, but the appropriate variant is installed), I have a suggested a patch from the kernel. But this patch depends on the ability to allow Boolean dependencies on Requires (it wouldn't work with Suggests/Recommends) https://lists.fedoraproject.org/archives/list/ker...@lists.fedoraproject.org/thread/6KCGSOP77VEGRC5UNC2FMRFEPEY2WSQ5/ https://bugzilla.redhat.com/1450577 > Case B) third party video or wireless driver same issue no kernel-devel, no > wireless no internet == fix by sneakernet So, as I understand this issue, you are suggesting to have the kernel-devel on the install media ? But then it would probably requires gcc and others dependencies if not already there. -- - Nicolas (kwizart) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Splitting AppStream data into Workstation/Server
2017-09-04 19:20 GMT+02:00 Richard Hughes : > On 4 September 2017 at 17:56, Neal Gompa wrote: >> It sounds like it would make more sense for createrepo_c to link to >> the AppStream builder library to handle AppStream metadata processing >> as part of the createrepo_c repodata generation, wouldn't it? > > 100% agree. This does take some time currently (as we have to > decompress some files from the lzma archives) but this is currently > done using my AMD Athlon Neo Microserver with spinning rust drives. > Using something XEONy and SSDy it'd be orders of magnitude faster. Are > we sure that we're using createrepo_c for composes? I know we *used* > to be the old python one for some reason. As I understand, the problem with the decompression is that it fetches the payload. And if a rpm weight 100MB, it will downloads (RPMs are often stored on nfs, so network is involved) and decompress the whole 100MB (including the header, although this last might be uncompressed). On the opposite, storing information on the RPM header means grabbing only the first KB out of the whole RPM. As one can see, this might work for few RPMs, but this doesn't scale at all on a big whole repository with many arches, specially if the work from a previous appdata-builder run cannot be cached for a later updates. So I wonder if it would be possible to have a "second payload" with only the appdata (xml, imgs) that it would be possible to fetch along the header without having to get the rest of the RPM ? On the second tough, with the effort needed to extract this information out of the rpm, is it really worth to store them there in the first step ? Over storing an URL (for xml and/or imgs) in the RPM header ? Thx for correcting me where I'm wrong. -- - Nicolas (kwizart) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Can't upgrade to Fedora 27 via dnf system-upgrade
2017-08-30 19:01 GMT+02:00 Heiko Adams : > Hi, > it seems the upgrade path to Fedora 27 via dnf system-upgrade is > currently broken. Everytime I try to upgrade I get the following > errors: There are lot of different errors, but for what rpmfusion is concerned, you should probably manually upgrade the rpmfusion-*-release package to 27 (looking at the Configuration page). This is because system-upgrade assume the repository path for 27 can be derived from the 26 repos which is sometime not true. -- - Nicolas (kwizart) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: ENOTIME
2017-07-20 17:04 GMT+02:00 Orion Poplawski : > My workload at $dayjob$ has increased significantly so I'm afraid I have much > less time to devote to packaging work. Now more than ever I could use help > maintaining my packages (listed below). If you are interested, please add > yourself as co-maintainers in pkgdb. Thanks! I can handle cobbler since I've several patches sent upstream and others are pending. Thx for your work on this. -- - Nicolas (kwizart) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fixing kmodtool / dropping kmodtool from redhat-rpm-config
2017-02-13 9:29 GMT+01:00 Hans de Goede : > Hi all, > > redhat-rpm-config in Fedora still contains an ancient copy of kmodtool > back from the days when Fedora allowed kmods directly into the main > Fedora repo, rather then only allowing them in 3th party repositories. > > Currently 3th party repositories like rpmfusion (I've put Nicolas > and Leigh from rpmfusion in the Cc) and negativo17 (Simone in the Cc) > maintain and use their own fork. > > There are 2 forks actually one maintained by rpmfusion which seems > the most complete / recent but does not support building kabi > packages for EL and various EL repos embed a different copy in > the src.rpm for their kmod packages so that they can build kabi > packages. > > As part of the work I've been doing to make it easier to install the > nvidia binary drivers for users who want that, I want to clean up > the situation around kmodtool and aim for one kmodtool version > which does everything needed. > > I've been discussing how to do this with Nicolas and Simone and > the plan is: > > 1) Create a pagure.io repo for kmodtool put the rpmfusion version > there > > 2) Package the kmodtool from pagure.io in its own kmodtool > package in a way which does not conflict with the ancient copy > from redhat-rpm-config. > > 3) Once the new packaged version is available, drop the old > kmodtool from newer redhat-rpm-config versions. > > 4) Extend the new kmodtool to also support creating kabi compliant > packages. > > I started with sending this mail to Dan Horák to ask if he was > ok with dropping kmodtool from redhat-rpm-config, but he indicated > that redhat-rpm-config is maintained by the rpm/dnf team, so > hence I'm sending this mail to rpm-software-management now, > with fedora-devel in the Cc to make sure I'm not leaving anyone > out of the loop. > > So a few questions for the rpm/dnf team: > > 1) What do you think of the above plan ? > > 2) Do you see any issues with dropping kmodtool from redhat-rpm-config > for Fedora ? > > 3) Would you be willing to drop the old kmodtool for F26+ ? @Hans I've took a quick look at kmodtool from redhat-rpm-config and I think It's only available on EL, not Fedora. Also the kmodtool support is implemented as a script in /usr/bin, whereas for EL it's implemented as rpm macros. So as such there is no conflict. The current "upstream" version is located in the rpmfusion distgit repo itself. Anyone can fork from our github mirror and start hacking: https://github.com/rpmfusion/kmodtool So right now the location of the upstream git doesn't really matter, In the long run I don't see any issue to move it to pague at some point. But my hope as that it can be picked by rpm itslef instead. Specially as nvidia has started to use it in the CUDA repository for Fedora (where they use akmod-nvidia based on our design). So we aren't the only users of that kmodtool support. I think the point of using kabi is just a matter to have a post/postun snipet in a given kmod-foo that test the availalbility of /usr/sbin/weak-module and add the weak module support. This can be easily added after the depmod call either or not the distro support kABI.(Fedora does not have the weak-module script anyway). The symbol extraction feature doesn't seem to be implemented in recent kmod (tested on oracleasm from centos at least). As for the design. I think the "template engine" should be better implemented in RPM macros instead of running a script. Also I'd like to have some common features used by the kernel implemented in the default rpm (or redhat-rpm-config), such as signing and compressing modules: https://src.fedoraproject.org/cgit/rpms/kernel.git/tree/kernel.spec?h=f23#n1768 https://src.fedoraproject.org/cgit/rpms/kernel.git/tree/kernel.spec?h=f23#n1726 That way, we could re-use the same code for kmod packages. Is this work worth a f26 feature? (that could be backported in earlier release at some point anyway). -- - Nicolas (kwizart) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: libglvnd review request, reviewer needed
2017-01-13 16:56 GMT+01:00 Hans de Goede : > Hi, > > On 01/12/2017 11:24 PM, Nicolas Chauvet wrote: >> >> 2017-01-12 19:04 GMT+01:00 Hans de Goede : >>> >>> Hi All, >>> >>> I've just submitted a pkg review request for libglvnd: >>> >>> https://bugzilla.redhat.com/show_bug.cgi?id=1412764 >>> >>> This is the last building block needed to allow full >>> parallel installation of the nvidia binary driver and >>> nouveau / mesa, without needing various *.conf.d to >>> select the right libGL.so / Xserver glx module, etc. >>> >>> With this in place the entire Xorg / GL stack will >>> automatically do the right thing depending on which >>> kernel driver (nouveau or nvidia) is loaded, which >>> means that things will no longer break if the kernel / >>> userspace config do not match (as there is no more >>> userspace config), also see: >> >> This is already in fedora since few months already. > > > Ah, I did not know that, that is great. > > I plan to do a Fedora 25 update enabling > glvnd in mesa coming monday. I will also update > libglvnd to match and make it be the provider > of libGL.so.1, etc. Sure, can you please open a bug so we can coordinate which changes exactly you want to push.( there are additional patches needed for pure mesa cases and glvnd - see https://bugs.freedesktop.org/show_bug.cgi?id=98428 ). Also f25 seems a quite disruptive change for switching the libGL provider. I'm all in favor about that, as It will settle the situation on optimus and drop custom repos, but let's at least have a step in f26. Thx -- - Nicolas (kwizart) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: libglvnd review request, reviewer needed
2017-01-12 19:04 GMT+01:00 Hans de Goede : > Hi All, > > I've just submitted a pkg review request for libglvnd: > > https://bugzilla.redhat.com/show_bug.cgi?id=1412764 > > This is the last building block needed to allow full > parallel installation of the nvidia binary driver and > nouveau / mesa, without needing various *.conf.d to > select the right libGL.so / Xserver glx module, etc. > > With this in place the entire Xorg / GL stack will > automatically do the right thing depending on which > kernel driver (nouveau or nvidia) is loaded, which > means that things will no longer break if the kernel / > userspace config do not match (as there is no more > userspace config), also see: This is already in fedora since few months already. Also you can note this is supported by the RPM Fusion community, based on your work: http://rpmfusion.org/Howto/nVidia_Optimus BTW, I've haven't received any answear back about modsetting conflicts with nvidia. I think modesetting should disable any accel (glamor,exa) as soon a the nvidia glx is loaded. And not to rely on any specific configuration file about that (that will need to be enaled/disabled back and forth if the driver switch is implemented between FOSS/proprietary driver). Thx -- - Nicolas (kwizart) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: crypto-policies not very useful, FUTURE too strict?
2016-12-17 16:19 GMT+01:00 Tomasz Torcz : > Hi, > > Since few release we have nifty, consolidated way to select system-wide > crypto > policy. It's great, but granularity of selection is little lacking. We have > basically two sensible choices: > - DEFAULT, which is, well, default > - FUTURE, which is said to be more secure; if the admin wants to change the > policy, > (s)he will have to switch to FUTURE > > So let's imagine Joe Sysadmins who in the face of LogJam and other > vulnerabilites, > wants to tighten security a bit. He switches to FUTURE and now GitHub doesn't > work: > > $ update-crypto-policies --set FUTURE > Setting system policy to FUTURE > > $ wget https://github.com > Resolving github.com (github.com)... 192.30.253.112, 192.30.253.113 > >Connecting to github.com > (github.com)|192.30.253.112|:443... connected. > ERROR: The certificate of 'github.com' is not trusted. > ERROR: The certificate of 'github.com' was signed using an insecure algorithm. > > Not only github: > > Connecting to getfedora.org (getfedora.org)|2001:4178:2:1269::fed2|:443... > connected. > ERROR: The certificate of 'getfedora.org' is not trusted. > ERROR: The certificate of 'getfedora.org' was signed using an insecure > algorithm. > > Switching back to DEFAULT make those working again. But it buys us nothing, > we have one setting which is default and the other is unusable. Why have this > setting at all, then? Maybe we need to rename FUTURE by QUITE_SOON instead, because the error you have pointed is about sha-1 been deprecated: According to this blog, chrome will remove support for sha-1 certificates on 1 January 2017 (it's an old post, so I don't know if it's still current). https://security.googleblog.com/2015/12/an-update-on-sha-1-certificates-in.html the getfedora certificates is signed with sha-256, but the root CA has signed the intermediate certificate with sha-1. That the issue. Thx for rising the point, I will check which certificates are still sha-1 in my own cert usage. -- - Nicolas (kwizart) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: samba client broken in rawhide?
2016-12-06 12:39 GMT+01:00 James Hogarth : > I'm trying to build the owncloud 9.1.1 update but in rawhide mock is > failing with: > > Error: nothing provides libldb.so.1(LDB_0.9.10)(64bit) needed by > samba-client-libs-2:4.5.1-1.fc26.x86_64 > > Was there a SO bump that missed a rebuild? It's not a SONAME bump, but the new update doesn't have version ed symbol anymore. https://bugzilla.redhat.com/show_bug.cgi?id=1400738 If any provenpackager can rebuild theses dependencies ? openchange samba sssd Thx -- - Nicolas (kwizart) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: what happened with rawhide/i386
2016-09-27 14:33 GMT+02:00 Sérgio Basto : > Hi, > I'm getting errors when build in i386 of rawhide and check that master > and mirror haven't i386 [1] had I missing something ? , this is a bug > or a feature ? > > [1] https://mirrors.kernel.org/fedora/development/rawhide/Everything/ i386 was moved to fedora-secondary, is there updated mock config files ? https://mirrors.kernel.org/fedora-secondary/development/rawhide/Everything/ @sergio I will update our config, thx for the reminder. -- - Nicolas (kwizart) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: kmods and Fedora
2016-01-14 18:05 GMT+01:00 Neal Gompa : > On Thu, Jan 14, 2016 at 11:01 AM, Reindl Harald > wrote: > > > > Am 14.01.2016 um 16:56 schrieb Neal Gompa: > >> > >> I've recently been wondering why we haven't allowed kernel module > >> packages in Fedora since Fedora 8. I've tried searching through our > >> wiki and the mailing list, but I haven't come up with any concrete > >> reasons for why we disallow them. > >> > >> If it is perhaps the issue of keeping things in sync with kernels we > >> provide (that is, maintainers didn't/couldn't keep up with new kernels > >> being pushed during a release cycle), then I think the situation has > >> changed. > >> > >> We have two tools that can help us in this regard: akmod and Koschei, > >> both came after our policy change to disallow kernel modules. > > > > > > akmod is a dirty hack and fails often enough for rpmfusion stuff > > > > additionally you should *never* need GCC and devel packages installed on > a > > normal enduser system for a ton of reasons > > The most common reason that akmod fails is the same reason dkms often > fails: the correct kernel-devel isn't installed. For whatever reason, > there's no logic in DNF to handle this case properly. Of course, to be > fair, this problem happens in Yum too, but since Yum isn't actively > supported in Fedora anymore, it's not as much of a concern. > Maybe this particular concern can be addressed in DNF with a plugin ? The way I've previously worded a possible solution is to have a yum/dnf plugin for akmod. This plugin will select the appropriate kernel-devel based on the kernel that is currently installed. ( https://bugzilla.rpmfusion.org/show_bug.cgi?id=3386 ). But this dnf plugin can be useful by default in fedora, since the kernel-devel issue can rise when one user install a particular development group where kernel-devel is needed. (user typically ends with kernel-debug-devel instead of the one for their kernel variant that can also be kernel-lpae or else). - Nicolas -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Heads Up: New pugixml coming to rawhide
2015-10-19 20:46 GMT+02:00 Richard Shaw :
> In the next couple of days I'll be doing an update of pugixml in rawhide.
> The affected packages seem to be:
>
> # repoquery --qf=%{name} --repoid=rawhide --whatrequires --source
> "libpugixml.so.1()(64bit)"
> OpenImageIO-1.5.20-1.fc24.src.rpm
> OpenImageIO-1.5.20-1.fc24.src.rpm
> OpenImageIO-1.5.20-1.fc24.src.rpm
> fts-3.3.1-3.fc24.src.rpm
> fts-3.3.1-3.fc24.src.rpm
> fts-3.3.1-3.fc24.src.rpm
> gfal2-2.9.3-1.fc23.src.rpm
> mkvtoolnix-8.4.0-1.fc24.src.rpm
> mkvtoolnix-8.4.0-1.fc24.src.rpm
> orthanc-0.8.6-6.fc24.src.rpm
> orthanc-0.8.6-6.fc24.src.rpm
> paraview-4.4.0-1.fc24.src.rpm
> paraview-4.4.0-1.fc24.src.rpm
> paraview-4.4.0-1.fc24.src.rpm
> pugixml-1.6-2.fc23.src.rpm
>
> I'm not sure why --qf isn't working..
>
> I'll take care of OpenImageIO.
>
> Thanks,
> Richard
>
Thx for the update.
Can you verify that "long long" is enabled by default in the fedora build
(as it should per this https://github.com/zeux/pugixml/issues/53 report)
This will help me to switch filezilla to pugixml.
thx
--
-
Nicolas (kwizart)
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Remove gcc, gcc-c++ and make from minimal build root
2015-01-15 20:18 GMT+01:00 Orion Poplawski : > On 01/15/2015 04:20 AM, Ralf Corsepius wrote: > > On 01/14/2015 03:10 AM, Orion Poplawski wrote: > >> On 01/12/2015 06:08 AM, Vít Ondruch wrote: > >>> Dear Fedora developers, > >>> > >>> I'd like to collect some feedback about the $SUBJECT, i.e. making > >>> minimal build root really minimal, explicitly specifying build > >>> dependencies, etc. > >>> > >> > >> Would it be technically feasible to have a different buildroot for arch > >> and noarch packages? > > What would this be useful for? > > The thought would be that (almost all) noarch packages don't need gcc, so > the > noarch buildroot could exclude gcc without impacting existing packages. I was going to say the same about noarch/arched packages and gcc assumption, also that I don't see any "simplification" in hardcoding the default compiler everywhere, specially as It probably depends on the build target . I remember other distros were using cross-compiler in buildroot and that was working pretty fine if the default "compiler" wasn't needlessly assumed. Another case about the default buildroot is compiler version, one could rely on a newer gcc (such as with a gcc5 package) and rebuild any packages with this new buildroot environment without tweaking any sources packages. -- - Nicolas (kwizart) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Best way to use zram in Fedora 21?
2014-11-26 22:27 GMT+01:00 Corey Sheldon : > Juan no needinst.zram=on on install on first boot modprobe zram ; > systemctl start zramvoila I use the default one in f21b no issues > Corey, Why this service is part of anaconda-core ? and not with the base systemd or else ? On my installed workstation system, I can remove anaconda that is now undeeded but I would like to keep zram.service installed. Thx for your answear. Nicolas Chauvet -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [HEADS UP] Bump mesa to 10.3.2 for F20
Le 29 oct. 2014 09:39, "Igor Gnatenko" a écrit : > > Hi, > > I'm planning update mesa in F20 to 10.3.2. > Probably I'll broke some packages, let's rebuild ... This is a good idea by itself. But this might have a dependency on a newer llvm and there is a libxatracker soname bump ( needed by freedreno and wvmare). I was heading the 10.3 rebuilt on my testing repository at rpms.kwizart.net That was all the dependencies that I recall. I've only tested the freedreno ddx update, not the VMware.. ( Unfortunately I'm not in the ACL for freedreno anymore for untold reason) I would still request for others advices given the soname change involved. Nicolas (kwizart) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Fwd: Ophaning lcms(1)
Hello, I'm orphaning lcms, this package has seen few security issue and upstream claim it's deprecated over lcms2 rhel 7 doesn't depends on it for the few package, so it might be an option not to build lcms support for certain package # repoquery --whatrequires liblcms.so.1 --source DevIL-1.7.8-16.fc20.src.rpm cinepaint-1.4-5.fc20.src.rpm cmyktool-0.1.6-0.6.pre1.fc20.src.rpm entangle-0.5.3-2.fc20.src.rpm f-spot-0.8.2-11.fc20.src.rpm geeqie-1.1-13.fc20.src.rpm gimp-separate+-0.5.8-10.fc20.src.rpm hylafax+-5.5.4-1.fc20.src.rpm libmng-1.0.10-12.fc20.src.rpm rawstudio-2.0-12.fc20.src.rpm mate-image-viewer-1.6.2-2.fc20.src.rpm oyranos-0.4.0-12.fc20.src.rpm photoprint-0.4.2-0.12.pre2.fc20.src.rpm python-pillow-2.2.1-4.fc20.src.rpm rawstudio-2.0-12.fc20.src.rpm sK1-0.9.1-0.8.pre_rev730.fc20.src.rpm Thx -- - Nicolas (kwizart) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: What is support status of PowerVR GPUs in Fedora? (Intel D2500 and gma500_gfx)
2013/11/15 valent.turko...@gmail.com > Thank you all for great feedback, I found these awesome online > resources for gma500_gfx - > https://gist.github.com/Aissen/2925633 > https://wiki.archlinux.org/index.php/Poulsbo > https://wiki.ubuntu.com/HardwareSupportComponentsVideoCardsPoulsbo > > You might have a look on enabling CONFIG_DRM_GMA600 in the fedora kernel it it works for your device But it will probably not lead to expected performances as already advised. So, you can also have a look on this http://edc.intel.com/Software/Downloads/EMGD/. This is the proprietary Intel/imgtech GPU driver. But it may rely on having support for the chipset that might or might not be fully upstream. In this case, try to look at the related tizen/meego kernel trees. This driver will enforce you to have one or another Xorg server or kernel version. Nicolas (kwizart) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New maintainer for lirc/Jarod Wilson's packages
2013/10/1 Bastien Nocera > - Original Message - > > Hi, > > > > Jarod Wilson, the current lirc maintainer, announced that he wants > > someone else to maintain lirc due to lack of time/interest[0]. Probably > > his other four packages need a new maintainer as, well[1]: > > > > https://admin.fedoraproject.org/pkgdb/users/packages/jwilson?acls=owner > > > > cx18-firmware -- Firmware for Conexant cx23418-based video capture > > devices > > libcrystalhd -- Broadcom Crystal HD device interface library > > Fabiano Fidencio should be interested, he got one of the 2 Broadcom cards > that Jarod sent me all that time ago. > I'm also interested in the libcrystalhd package, as I was the most active maintainer despite not having any commit right. I also have the hardware (the recent one) Nicolas (kwizart) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Release Ownership for oyranos
Hi, I've released ownership for oyranos which currently FTBFS in f20. I will not have time to fix in the f20 time frame, so it might be blocked or even retired if none volunteer to maintain it. There will be a need to update elektra first, then if one in interested in this package, libXcm and xcm are also of interested. I can keep theses for the moment. Thx Nicolas (kwizart) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [ACTION REQUIRED] Packages depending on retired packages
2013/8/29 Till Maas > On Wed, Aug 28, 2013 at 10:53:53PM +0200, Till Maas wrote: > > > Package(co)maintainers > > > === > > directfb orphan, kwizart > > > tslib orphan > > These seem to be retired by accident: > https://lists.fedoraproject.org/pipermail/devel/2013-June/183702.html > > Nicolas, can you please comment on this? > Yep I've retired this package. At that time the directfb project was more and more relying on an external kernel module to be full featured. I've probably missed to block this package at that time. Nicolas (kwizart) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [SDL/f19] (2 commits) ...Add NAS support
2013/7/26 Daniel P. Berrange
> On Fri, Jul 26, 2013 at 02:45:06PM +0200, Nicolas Chauvet wrote:
> > 2013/7/26 Petr Pisar
> >
> > > Summary of changes:
> > >
> > > 63275df... Add esound and arts BRs (*)
> > > 43ee9b2... Add NAS support (*)
> > >
> >
> > Do we really need to re-enable thoses deprecated sound server ?
> > I guess no
>
...
> NB I don't care if esound / arts remain in Fedora or not, but if we
> want to kill them off, lets be consistent and kill them everywhere,
> not just disable them in SDL
>
I'm more concerned about not installing arts/nas/esound by default when I
only want to use SDL.
But looking at the commit, this is when %if 0%{?rhel}.
Nicolas (kwizart)
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [SDL/f19] (2 commits) ...Add NAS support
2013/7/26 Petr Pisar > Summary of changes: > > 63275df... Add esound and arts BRs (*) > 43ee9b2... Add NAS support (*) > Do we really need to re-enable thoses deprecated sound server ? I guess no Nicolas (kwizart) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing proxy support in Fedora (was Re: Orphaning few packages)
2013/7/18 David Woodhouse > On Fri, 2013-06-07 at 01:19 +0800, Christopher Meng wrote: > > On Thu, Jun 6, 2013 at 6:55 PM, David Woodhouse > wrote: > > > On Wed, 2013-06-05 at 12:08 +0800, Christopher Meng wrote: > > >> libproxy taken. > > > > > > I'm also very interested in libproxy. Would you mind if I comaintain > it? > > > > Please request the commit privilege if you want to maintain it. That's > all... > > I've just pushed a 0.4.11-5 build to rawhide with support for PacRunner > (which is also now in Fedora now). > > So there's a libproxy-pacrunner subpackage, like all the other > subpackages, that will do nothing but query PacRunner. > > I'm separately working on fixing NetworkManager to actually *tell* > PacRunner the current proxy configuration, as derived from the network > connection (either automatically or via manual per-connection settings). > > But it's actually relatively simple to hack around that for now with a > NM dispatcher script. Having libproxy-pacrunner available is the > important missing piece of the puzzle for now. > Should the dispatcher script be provided by the libproxy-pacrunner sub-package ? Or NM ? There is probably a need to have theses sub-packages properly installed by default ? (with the appropriate plugins). Does having particular package set by default should be a feature ? Nicolas (kwizart) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [coreutils] require glibc-devel to prevent broken links in coreutils info manual (#959697)
2013/5/17 Ondrej Vasik > - Original Message - > > 2013/5/17 Ondrej Vasik < ova...@fedoraproject.org > > > > > > > commit ed5396d91e0032fa7cbfd6cb0bde3d7850aba790 > > Author: Ondřej Vašík < ova...@redhat.com > > > Date: Fri May 17 09:21:51 2013 +0200 > > > > require glibc-devel to prevent broken links in coreutils info manual > > (#959697) > > > > I don't think having glibc-devel installed by default will make it. > > Also you bugzilla number is wrong. (unrelated). > > Thanks, fixed the typo in changelog... > Why do you think it will not make it work? Glibc info manuals are there, > so the broken links should be prevented by this. > The general idea of splitting packages is that you can install one that is required and not another that is optional. As coreutils is required by default, that's defeat the point to even have this split made. Because both will be required. My understanding is that libc*.info should be moved to the main glibc instead as most info file belong to the main package. One that doesn't want to install the documentation can still install with rpm nodocs Nicolas (kwizart) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [coreutils] require glibc-devel to prevent broken links in coreutils info manual (#959697)
2013/5/17 Ondrej Vasik > commit ed5396d91e0032fa7cbfd6cb0bde3d7850aba790 > Author: Ondřej Vašík > Date: Fri May 17 09:21:51 2013 +0200 > > require glibc-devel to prevent broken links in coreutils info manual > (#959697) > I don't think having glibc-devel installed by default will make it. Also you bugzilla number is wrong. (unrelated). Nicolas (kwizart) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: audacity
audacity is unmaintained in both fedora and RPM Fusion. I'm about to kick it out of the later repository. Nicolas (kwizart) 2013/4/28 Richard Vickery > For F18, it appears that the Audacity mp3 build is broken - it won't > install - and mp3 support is rather important to me; is it possible to get > this particular build working? > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mission Impossible #1: qt without gtk
2013/4/29 Eugene Pivnev > As pcmafm developer said - gvfm use gobject - but not gtk or gnome libs. > I showed only packages that I was surprised. > E.g. "ffmpeg requires gtk". > Very nice. It's probably because of opencv, It can probably be spitted carefully at runtime, but opencv-devel cannot be splitted yet. (so patch welcomed). Nicolas (kwizart) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning em8300 related stuff
2013/2/14 Felix Kaechele > Hi there, > > I'm orphaning > > em8300 in Fedora and > em8300-kmod in RPMFusion > This package was already orphaned in RPM Fusion actually. (do not build with current v4l2 only kernel IIRC). Thx Nicolas (kwizart) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
