Re: rawhide report: 20120728 changes
On Saturday 28 July 2012 14:47:28 you wrote: > On Sat, 28 Jul 2012 12:36:26 + > Fedora Rawhide Report wrote: > > [...] > > > --- > > * Fri Jul 27 2012 - Andreas Schneider - > > 2:4.0.0-132.beta4 > > - Don't define an Epoch in RHEL releases. > > May I ask why? > > This makes it harder to compare versions between Fedora and RHEL. I > know it is not a 1:1 mapping anyway, but it is useful to see branching > points etc. > > Differing Epoch will be confusing later down the road, I think. It's > not like it's in the way? [reply to the list] The Epoch in the Fedora samba4 package has been added to be able to correctly conflict with samba packages. The samba packages bumped the epoch some time ago for a special update path. The RHEL samba package doesn't have any epoch set, so Epoch is 0. There is no reason why the samba4 packages in RHEL should have an Epoch of 2. Dealing with an Epoch > 0 and Requires, Conflicts, Obsoletes etc. makes your live a lot harder. If RHEL doesn't have any Epoch set, I don't see a reason why it should be set to 2 and make our life harder packaging for RHEL. Better readability of a diff between RHEL and Fedora isn't an argument. Having to spend days to get different Epoch numbers in Conflicts: Requires: and Obsoletes: correctly and testing them with different installations is an argument. It is valueable time I can spent on other things. Cheers, -- andreas -- Andreas Schneider GPG-ID: 8B7EB4B8 Red Hat a...@redhat.com Samba Team a...@samba.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Samba and Samba4 changes for F18/rawhide
Hello, I wanted to let you know that the samba package in f18 and rawhide has been updated to version 4.0.0rc1. The samba4 package will retire in these distro versions. Cheers, -- andreas -- Andreas Schneider GPG-ID: 8B7EB4B8 Red Hat a...@redhat.com Samba Team a...@samba.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SWAT will be removed from the Samba package
On Monday 25 February 2013 17:33:09 Andreas Schneider wrote: > On Monday 25 February 2013 10:09:50 Nico Kadel-Garcia wrote: > > On Mon, Feb 25, 2013 at 9:08 AM, Andreas Schneider wrote: > > > Hello, > > > > > > the Samba Team has announced [1] that it will remove SWAT from the Samba > > > Suite. SWAT is unmaintained and has the most security bugs. > > > > Andrew, I'm in that thread on the Samba mailing list at > > http://lists.samba.org/archive/samba/2013-February/171643.html. I > > don't see an actual decision there, just a call for discussion. Also, > > if you decide to remove the samba-swat package from the samba suite, > > should it be obsoleted or merely reported as conflicting with new > > samba-common releases, to make sure people delete it before doing > > upgrades and getting in dependency trouble? It might even be better > > pulled as part of the next Samba 4.0.4 package. > > That's why I stated below that I will remove it when it gets removed in the > Samba development tree upstream. > > I will handle the correct deinstallation of samba-swat when it gets removed > but thanks for the idea with handling it in samba-common. > > I'm sure it will take some time till it gets removed. The time has come. SWAT has been removed from Samba and I will remove it in F19 and newer now. -- andreas -- Andreas Schneider GPG-ID: 8B7EB4B8 Red Hat a...@redhat.com Samba Team a...@samba.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Samba DC NT4 Style is Gone. It may be time to enable AD-DC for default into Fedora Samba4 packages?
On Monday, 29 August 2016 18:16:26 CEST Dario Lesca wrote: > This recent Microsoft's Patch > https://lists.samba.org/archive/samba/2016-August/202197.html > > disable password change for Domain Controller NT4 Style. It is not knew that Microsoft dropped support for NT4 style domain controllers. Windows 7 was the last version which supported it. For newer versions there existed just some hacks. > IMHO, It may be time to enable support to AD-DC mode, or release > another renamed packages with AD-DC support enable. As Fedora and RHEL are using MIT Kerberos as its Kerberos infrastructure of choice, the Samba Active Directory Domain Controller implementation is not available with MIT Kerberos at the moment. Since several years I'm working on the migration to MIT Kerberos, but it is a huge task. See the talks Günther and I have given at the SambaXP conferences during the last years. For example: https://sambaxp.org/archive_data/SambaXP2014-DATA/wed/track2/ Andreas_Schneider-TheroadtoMITKerberossupport.pdf > The samba.src is ready for this: > > I have try to download the samba.src rpm, modify the spec file like > > this: > > sed \ > > -e 's/%global with_mitkrb5 1/%global with_mitkrb5 0/' \ > > -e 's/%global with_dc 0/%global with_dc 1/' \ > > ~/rpmbuild/SPECS/samba.spec > > rebuild the package, install it on a test server and configure it in > AC-DC mode. > > It seems work fine. But this uses Heimdal Kerberos and not MIT Kerberos which can lead to issues in the system. > > My question is: > > There is some hope that in the short this flags are enable by default? > > Many thanks for your reply Yes, we will enable Samba AD as soon as I'm done with porting it to MIT Kerberos. This will hopefully be the case next year. Best regards, -- andreas -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
SWAT will be removed from the Samba package
Hello, the Samba Team has announced [1] that it will remove SWAT from the Samba Suite. SWAT is unmaintained and has the most security bugs. I plan to remove the samba-swat subpackage in Fedora 18, 19 and rawhide as soon as it gets removed from the current Samba development tree. Cheers, -- andreas -- Andreas Schneider GPG-ID: 8B7EB4B8 Red Hat a...@redhat.com Samba Team a...@samba.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SWAT will be removed from the Samba package
On Monday 25 February 2013 10:09:50 Nico Kadel-Garcia wrote: > On Mon, Feb 25, 2013 at 9:08 AM, Andreas Schneider wrote: > > Hello, > > > > the Samba Team has announced [1] that it will remove SWAT from the Samba > > Suite. SWAT is unmaintained and has the most security bugs. > > Andrew, I'm in that thread on the Samba mailing list at > http://lists.samba.org/archive/samba/2013-February/171643.html. I > don't see an actual decision there, just a call for discussion. Also, > if you decide to remove the samba-swat package from the samba suite, > should it be obsoleted or merely reported as conflicting with new > samba-common releases, to make sure people delete it before doing > upgrades and getting in dependency trouble? It might even be better > pulled as part of the next Samba 4.0.4 package. That's why I stated below that I will remove it when it gets removed in the Samba development tree upstream. I will handle the correct deinstallation of samba-swat when it gets removed but thanks for the idea with handling it in samba-common. I'm sure it will take some time till it gets removed. > And while you're in that package: I've got rewrite of the .spec file > and the other dependencies for RHEL compatibility of 4.0.3. It's up at > https://github.com/nkadel/samba-4.0.3-srpm/, along with RPM building > tools for all the other dependencies below: > > iniparser # not in RHEL > krb5 # Version 1.10 in RHEL 6.4 is good enough > > libtalloc > libtdb > libldb > libtevent I've removed everything for older version on purpose to have a clean spec file. We decided not to support RHEL6 with this. -- Andreas Schneider GPG-ID: 8B7EB4B8 Red Hat a...@redhat.com Samba Team a...@samba.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SPDX Statistics - stilus annunciationis edition
On Sunday, 26 March 2023 01:56:32 CEST Miroslav Suchý wrote: > Two weeks ago we had: > > * 23107 spec files in Fedora > > > > * 29503license tags in all spec files > > > > * 20302 tags have not been converted to SPDX yet > > > > * 8096 tags can be trivially converted using `license-fedora2spdx` > > Today we have: > > * 22882 spec files in Fedora > > * 29366license tags in all spec files > > * 19784 tags have not been converted to SPDX yet(huray, we are under 20k) > > * 7912tags can be trivially converted using `license-fedora2spdx` > > The list of packages needed to be converted is again here: > > https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx-fi > nal.txt > > List by package maintainers is here > > https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx-fi > nal-maintainers.txt Looking into this it lists for example: libtermkey asn salimma The spec file of libtermkey has: License:MIT Now going to https://spdx.org/licenses/ and looking for the SPDX Identifier shows: MIT License MIT What am I supposed to do as a maintainer of libtermkey? Best regards Andreas ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Willing to unretire package: rust-starship
On Wednesday, 30 November 2022 18:43:50 CET Mauricio Teixeira wrote: > Fabio, Hi Fabio, > What is so bad about the COPR package that can't be used in the main repo? It downloads packages from the internet and doesn't use system rust packages. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Upcoming libcmocka 1.1.6 update requires fixing packages using cmake
Hi, I would like to update libcmocka [1] to version 1.1.6. This autogenerates the find_package() files for CONFIG mode now. This means the projects which don't have their on FindCMocka.cmake module but rely on the CONFIG mode, need 3 lines of code to still compile with 1.1.6. You need to add the following code after find_package(cmocka): if (TARGET cmocka::cmocka) set(CMOCKA_LIBRARY cmocka::cmocka) endif() I did some repoquery and the following packages which use cmake and libcmocka might need fixing: drpm freecell-solver libavtp libssh (maintained by me) libyang netdata nss_wrapper (maintained by me) openscap pam_wrapper (maintained by me) priv_wrapper (maintained by me) resolv_wrapper (maintained by me) socket_wrapper (maintained by me) sysrepo termy-server uid_wrapper (maintained by me) I will try to look into them in the next weeks, but if you're the maintainer of the package and read this I would appreciate if you could fix it. Thanks! Best regards Andreas [1] https://cmocka.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: argyllcms orphaned
On Thursday, 19 October 2023 10:20:52 CEST Richard Hughes wrote: > Hi all, Hi, > I've orphaned argyllcms -- I'm no longer using the package, and > haven't worked on color management for some time. If anyone wants to > take on the package the upstream source is chucked over the wall (no > source control) every few months, and it sometimes needs patches to > fix the Linux support. Ohh and it uses jam as the build system > upstream, which in honesty is going to be easier to rewrite with > automake or meson before building. I'm happy to give advice to the new > maintainer. Apologies, we don't have displaycal in the distribution anymore? :-( https://github.com/eoyilmaz/displaycal-py3 This required it, it sounds like nobody uses Fedora for color work anymore. That would be sad. Best regards Andreas ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Help packaging a "C" library written in Rust
On Wednesday, 7 September 2022 11:35:54 CEST Richard W.M. Jones wrote:
> On Wed, Sep 07, 2022 at 10:05:55AM +0100, Richard W.M. Jones wrote:
>
> >
> > https://gitlab.com/libblkio/libblkio
> >
> > This is a library that offers a C API. It happens to be implemented
> > in Rust, but it's not a "Crate" or anything like that.
> >
> > I wrote a spec file for it assuming it's a C library and it works fine
> > when building locally:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=2124697
> >
> > However it turns out that it downloads stuff during the build and
> > therefore won't build in Koji. Apart from reading the Rust packaging
> > guidelines which don't seem applicable here (as this is not a Rust
> > Crate), that's as far as I've got on this one.
> >
> > Has anyone packaged anything like this for Fedora?
>
>
> It was pointed out on the bug that librsvg2 is in a similar situation.
> The answer there was to bundle ("vendor") all the Rust dependencies
> into the tarball. The command "cargo vendor" does this.
I think rav1e is a good example. I provides a C library and is packaged well.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Mailman3 on Fedora 36
On Tuesday, 25 October 2022 19:16:32 CEST Sjoerd Mullender wrote: > > The issue with installing mailman3 might be due to sqlalchemy, though: > > There is a 1.3 compat package but it conflicts with the update. If you > > want to "rescue" mailman3 in f36 even though it is retired in rawhide > > this might be an option. > > In my version, I indeed require sqlalchemy1.3. The patch to support sqlalchem 1.4 is pretty simple. See https://build.opensuse.org/package/view_file/ devel:languages:python:mailman:backports/python-mailman/mailman-support- sqlalchemy-1-4.patch?expand=1 I'm using this in production while waiting for a better fix from upstream. https://gitlab.com/mailman/mailman/-/merge_requests/1034 FYI: mailman 3.3.6 has been released yesterday. Cheers Andreas ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Non-responsive maintainer check for dagostinelli
Hi, I'm trying to reach the maintainer of fswatch [1]. fswatch will be a dependency of neovim 0.10 and I would like to get it updated to be prepared for the release. It looks like the maintainer is unresponsive. I've open the bugs [2] and [3]. [3] is the bug for this non-responsive maintainer check for dagostinelli. I can also (co-)maintain the package as it is a dependency of neovim soon. Best regards Andreas [1] https://src.fedoraproject.org/rpms/fswatch [2] https://bugzilla.redhat.com/show_bug.cgi?id=2270266 [3] https://bugzilla.redhat.com/show_bug.cgi?id=2271832 -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Three steps we could take to make supply chain attacks a bit harder
On Saturday, 30 March 2024 10:37:44 CEST Richard W.M. Jones wrote: > These are just my thoughts on a Saturday morning. Feedback welcome of > course. I find the use of the ifunc attribute is really uncommon at this place. I would expect it in ffmpeg or some media codecs. In xz it looks like it is only there to hook in the payload. The software I know normally uses target cloning. I think the use of the ifunc attribute should be a red flag. Can't we check for it with rpmlint and let the security team verify it? Best regards Andreas -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Three steps we could take to make supply chain attacks a bit harder
On Tuesday, 2 April 2024 09:52:38 CEST Richard W.M. Jones wrote: > On Tue, Apr 02, 2024 at 07:40:33AM +0200, Andreas Schneider wrote: > > On Saturday, 30 March 2024 10:37:44 CEST Richard W.M. Jones wrote: > > > These are just my thoughts on a Saturday morning. Feedback welcome of > > > course. > > > > I find the use of the ifunc attribute is really uncommon at this place. I > > would expect it in ffmpeg or some media codecs. In xz it looks like it is > > only there to hook in the payload. The software I know normally uses > > target cloning. > > In hindsight it's suspicious, but it's not generally suspicious for a > project that needs to generate optimal code for different > sub-architectures (eg. something that does fast decompression) to use > the mechanism for that purpose, ifunc. > > That said, ifunc is a very complicated, fragile but powerful mechanism > and I'd like to know from the glibc developers what we should > look out for. For example: > > - Is it ever valid for ifunc to take control of functions in another >library? Can this be detected by ld.so? > > - Can some wrappers be developed to make it both easier and safer? Well, if it would do that. I took a quick look at xz and didn't see any specific code for an architecture flavor like x86_64-v3 or avx related. It lacks the implementation for that. All it did was adding the infrastructure without using it. I guess that the use of ifunc would is still be very rare. Target clones is what you normally see. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Three steps we could take to make supply chain attacks a bit harder
On Wednesday, 3 April 2024 01:34:00 CEST Gordon Messmer wrote: > On 2024-03-30 11:52, Dmitry Belyavskiy wrote: > > We have an upstream-adjusted version of this patch, see > > https://bugzilla.mindrot.org/show_bug.cgi?id=2641 > > I'm OK to bring the updated version of this script to Fedora as soon > > as it is finalized. > > I proposed https://src.fedoraproject.org/rpms/openssh/pull-request/72 , > which uses the implementation from > https://www.freedesktop.org/software/systemd/man/devel/sd_notify.html#Notes Thanks for the contribution, but please use https://bugzilla.mindrot.org/ show_bug.cgi?id=2641#c13 instead. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Installing ffmeg-free degrades firefox video support
On Sunday, June 5, 2022 10:02:21 AM CEST Mattia Verga via devel wrote: > **Rant mode on** > so, the whole purpose of Fedora is to have a fully free software linux > distribution... but we can't accomplish that in a working way, then we > came out with all sort of workarounds to get things working (COPR, > rpmfusion, flathub...). > > We should really start thinking about this. Don't buy hardware which uses patented codecs or tell the manufacturers that you want royalty free codecs. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Installing ffmeg-free degrades firefox video support
On Sunday, June 5, 2022 10:36:19 AM CEST Neal Gompa wrote: > H.264 is supported through OpenH264, and H.265 is not a popular codec. > Aside from Apple services (which are not available to Linux users > anyway), nobody uses H.265 because of the patent situation with HEVC. Sadly HEVC patent holders put put H.265 in their hardware. Like Sony and Canon record HEVC videos in their latest camera versions. Sadly they do not offer AV1 :-( ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Packaging pgAdmin4
On Thursday, December 9, 2021 6:59:17 PM CET Ben Beasley wrote: > I haven’t looked at pgAdmin4, but I’m the current maintainer of > nodejs-svgo and several other Fedora packages that use the new NodeJS > packaging guidelines. I’m not the original packager for nodejs-svgo, and > I wasn’t the first to convert it to the new NodeJS guidelines. I welcome > further community discussion on this topic. Hi, if the packages is using yarn, you can simply use its caching mechanism for bundling the needed node modules. You will have an offline cache where you can install the modules from! Example: https://src.fedoraproject.org/rpms/nodejs-bash-language-server Take a look at prepare_vendor.sh which creates a tarball with the yarn cache for you. Best regards Andreas ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Any interest in ROCm packaging?
On Thursday, December 16, 2021 6:07:10 PM CET Jeremy Newton wrote: > Full disclosure, I am both a Fedora packager and an employee at AMD. > To be clear, the following is not at all endorsed by my employer; my > interest and use of Fedora is purely a personal hobby and I would like to > keep it that way. > There has been a recent effort to step up Debian packaging of ROCm, and > would like to see if anyone has some interest in expanding the Fedora ROCm > packages. > I see there's a few packages already, and I'm hoping to help with some > internal processes to make ROCm more distro friendly, such as better FHS > compliance, clearer licensing, etc. Anyone interested? I would be happy to > try to help or review package requests :) Hi Jeremy, some time ago I tried to start this. The first step would be to cleanup cmake to actually install them correctly and find the dependencies in the system. I've started with this but for some libraries it worked for other it took ages. See e.g. my PRs here: https://github.com/RadeonOpenCompute/ROCT-Thunk-Interface/pulls? q=is%3Apr+is%3Aclosed With every new release there are other strange defaults like building libraries as static by default: https://github.com/RadeonOpenCompute/ROCT-Thunk-Interface/blob/master/ CMakeLists.txt#L37 So before starting with packaging, cmake should be cleaned up: https://cliutils.gitlab.io/modern-cmake/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Packaging pgAdmin4
On Thursday, 16 December 2021 23:59:23 CET Demi Marie Obenour wrote: > On 12/10/21 6:56 AM, Sandro Mani wrote: > > On 10.12.21 01:54, Demi Marie Obenour wrote: > >> On 12/9/21 1:05 PM, Sandro Mani wrote: > >>> On 09.12.21 17:31, Vitaly Zaitsev via devel wrote: > On 09/12/2021 16:56, Sandro Mani wrote: > > This does not appear to be accurate for nodejs packages - take i.e. > > node-svgo, which compliant with the guidelines bundles node_modules > > dir in svgo-2.8.0-nm-dev.tgz resp svgo-2.8.0-nm-prod.tgz. > > You can vendor only sources. No prebuilt assets are allowed. > >>> > >>> Which would basically mean bundling the node_modules folder? > >> > >> No, it would mean bundling the source from which the stuff in > >> node_modules is generated. > > > > Well this isn't what is the current nodejs packaging guidelines state > > and as noted by Ben elsewhere in this thread would make it prohibitive > > to package anything but the most trivial nodejs library. > > If some of the dependencies are unnecessary, the package maintainers > could patch the code to not use them, and send the patches upstream. > That said, this really needs to be solved at the NPM level, by having > NPM packages include machine-extractable source code. > > In any case, node_modules is not source code, since it is not “the > preferred form of the work for making modifications to it.” (quoting > LGPLv2.1 here, but I believe Fedora uses an equivalent definition). > The question then becomes whether it is more like bundling a prebuilt > binary, which is not acceptable, or like the bundling of the output > of lex, yacc, or pandoc in autotools-generated tarballs, which I > consider fine. One distinction might be whether the output files are > portable and can be automatically regenerated, which is invariably > true in the latter case. I don't see a problem if the node modules don't ship prebuilt libraries or binaries. If you look at my scripts they remove all of this. https://src.fedoraproject.org/rpms/nodejs-bash-language-server/blob/rawhide/f/ prepare_vendor.sh#_55 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: GNU Toolchain Update (gcc 12, glibc 2.35) (late System-Wide Change proposal)
On Tuesday, January 11, 2022 7:00:22 PM CET Steve Grubb wrote: > Hello, > > On Wednesday, January 5, 2022 5:05:26 PM EST Ben Cotton wrote: > > > https://fedoraproject.org/wiki/Changes/GNUToolchainF36 > > > > == Summary == > > Update the Fedora 36 GNU Toolchain to gcc 12 and glibc 2.35. > > > > The gcc 12 is currently under development and will be included in > > Fedora 36 upon release. The glibc 2.35 change will be tracked in this > > top-level GNU Toolchain system-wide update. > > > Reading through the GCC 12 changes, there is a significant new feature to > GCC that would appear to be useful for security. There is a new: > > -ftrivial-auto-var-init=zero > > flag that initializes all stack variables to zero. Zero being a nice safe > value that makes programs crash instead of being exploitable. > > Are there plans to enable this flag so that all applications, but more > importantly the kernel, are hardened against uninitialized stack variables? > > This is one of the major classes of security bugs that could potentially > be eliminated during this mass rebuild. I don't know if it is still the case, but OpenSSL used uninitialized stack variables on purpose! If you initialize them to zero might end up with the same disaster as Debian had some years ago! https://www.debian.org/security/2008/dsa-1571 There be dragons! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Selinux slow / How to disable selinux labeling from SPEC Was: mv is massively slower on the host rather than in a nspawn chroot, regression somewhere?
On Friday, 28 January 2022 00:43:07 CET Robert-André Mauchin wrote:
> On 1/24/22 01:30, Robert-André Mauchin wrote:
>
> > Hi,
> >
> > So I have an annoying bug that started near the beginnings of F35.
> > My papirus-icon-theme became very slow to install:
> > https://bugzilla.redhat.com/show_bug.cgi?id=2029709#c18
> >
> > During the installation, all the files are copied, then renamed by rpm
> > (no idea why it works like this).
> >
> > It works fast in a Mock chroot but incredibly slow on bare metal.
> >
> > I've done a small test of moving files:
> >
> > [root@cassini icons]# mkdir test
> > [root@cassini icons]# for (( i = 0; i < 1; i++ )) do > test/file_$i;
> > done
> > [root@cassini icons]# cd test
> >
> > On host:
> >
> > time $(for f in *; do mv "$f" "${f%}.txt"; done)
> > real2m3,500s
> > user0m3,966s
> > sys 2m0,431s
> >
> > In nspawn container:
> >
> > sh-5.1# time $(for f in *; do mv "$f" "${f%}.txt";
> > done)
> > real0m6.702s
> > user0m4.237s
> > sys 0m3.344s
> >
> > Since papirus-icon-theme contains more than 100,000 (small) files, it is
> > a problem. One minute of waiting is ok, 20 mn is not.
> >
> > What can cause this? I read that nspawn virtualizes the file system,
> > could it be file system related on the host? (I use btrfs btw)
> >
> > Any input welcome!
> >
> > Best regards,
> >
> > Robert-André
>
>
>
> Thanks to Panu, it has been determined that the install process of
> papirus-icon-theme spends most of its time labeling the 100,000 files.
> Installing the rpm with rpm -i --nocontexts makes it happen in a
> reasonable time.
> Is there a way to bypass this step from within the SPEC itself?
> It started to happen around F35, do you think I should try to raise a
> bug with SELinux? I don't know how to diagnose this better.
>
> Any input appreciated.
Did you log a bug? Updating texlive is horribly slow ...
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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
RPM spec feedback directly in your editor
Hi,
I'm a big fan of neovim (emacs users jump to 'emacs:' ;-). neovim has support
for the Language Server Protocol and there is a nice plugin called 'null-ls'
[1] which allows you to hook linters and formatters into neovim.
I've added support for rpmspec in 'null-ls' so you can get feedback directly
while editing a spec file. See the attached screenshot.
How to configure it:
```
local ok, null_ls = pcall(require, 'null-ls')
if not ok then
return
end
local sources = {}
if vim.fn.executable('rpmspec') == 1 then
table.insert(sources, null_ls.builtins.diagnostics.rpmspec)
end
null_ls.setup({
debug = false,
sources = sources,
})
```
What is currently missing in rpmspec is support to parse the input form stdin
instead of a file [2]. But there is already a PR to support it [3].
Best regards
Andreas
[1] https://github.com/jose-elias-alvarez/null-ls.nvim/
[2] https://github.com/rpm-software-management/rpm/issues/1926
[3] https://github.com/rpm-software-management/rpm/pull/1928
emacs:
There is a general purpose LSP called diagnostic-language-server [4]
you can use to achieve the same with emacs-lsp.
`dnf install nodejs-diagnostic-languageserver`
[4] https://github.com/iamcco/diagnostic-languageserver___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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 spec feedback directly in your editor
On Tuesday, February 22, 2022 9:29:49 AM CET Ondrej Mosnacek wrote: > > What is currently missing in rpmspec is support to parse the input form > > stdin instead of a file [2]. But there is already a PR to support it > > [3]. > > `rpmspec -P /dev/stdin` seems to work already now. I use this "trick" > all the time with programs that don't support stdin/stdout natively. > (Sometimes even that doesn't work, e.g. if the program tries to seek > or mmap it, but often it does.) I think it only works if a shell is involved. If I try it rpmspec reports: error: Unable to open /dev/stdin: No such device or address as lua does execv() on rpmspec. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
RPM spec feedback directly in your editor
Hi,
I'm a big fan of neovim (emacs users jump to 'emacs:' ;-). neovim has support
for the Language Server Protocol and there is a nice plugin called 'null-ls'
[1] which allows you to hook linters and formatters into neovim.
I've added support for rpmspec in 'null-ls' so you can get feedback directly
while editing a spec file. See the attached screenshot.
How to configure it:
```
local ok, null_ls = pcall(require, 'null-ls')
if not ok then
return
end
local sources = {}
if vim.fn.executable('rpmspec') == 1 then
table.insert(sources, null_ls.builtins.diagnostics.rpmspec)
end
null_ls.setup({
debug = false,
sources = sources,
})
```
What is currently missing in rpmspec is support to parse the input form stdin
instead of a file [2]. But there is already a PR to support it [3].
Best regards
Andreas
[1] https://github.com/jose-elias-alvarez/null-ls.nvim/
[2] https://github.com/rpm-software-management/rpm/issues/1926
[3] https://github.com/rpm-software-management/rpm/pull/1928
emacs:
There is a general purpose LSP called diagnostic-language-server [4]
you can use to achieve the same with emacs-lsp.
`dnf install nodejs-diagnostic-languageserver`
[4] https://github.com/iamcco/diagnostic-languageserver___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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 spec feedback directly in your editor
On Tuesday, February 22, 2022 7:41:16 PM CET Artur Frenszek-Iwicki wrote: > > error: Unable to open /dev/stdin: No such device or address > > How about "/proc/self/fd/0"? Nope doesn't work ... /dev/stdin is a symlink to /proc/self/fd/0. I wonder if this is only available with a shell ... ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
nodejs-electron
Hello! Over the past 8 month, I've been working on getting Electron [1] built on Fedora. Yesterday I was finally able to do the first working build for Fedora Rawhide [2]. This was possible because we finally have ffmpeg [3] in Fedora. My use for Electron is that I want to run signal-desktop [4] on Fedora. You can get electron and signal-packages packages for it at [5]. Is there interest to bring nodejs-electron into Fedora and if yes, would someone be interested to maintain it? I don't have the time to maintain it but I'm happy to help as a co-maintainer. Best regards Andreas [1] https://www.electronjs.org/ [2] https://build.opensuse.org/package/show/network:im:signal/nodejs-electron [3] https://src.fedoraproject.org/rpms/ffmpeg/ [4] https://build.opensuse.org/package/show/network:im:signal/signal-desktop [5] https://download.opensuse.org/repositories/network:/im:/signal/ Fedora_Rawhide/x86_64/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: nodejs-electron
On Friday, 25 February 2022 14:02:11 CET Neal Gompa wrote: > I think this is probably one of those things that would be worth > forming a SIG on. An Electron SIG could help with Electron and all > Electron-based applications that come into Fedora. That would be fine by me. The most obvious application would be Element (Matrix). https://element.io/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG, OPUS, SPEEX, ...) for Fedora
Hi, there are several packages in the distribution which require FFMPEG (libavformat, libavcodec, etc.), one of them being chromium. The package could be created in a way that you can easily replace it with a version from rpmfusion to get to the full encoder/decoder set including H264 etc. This is working fine with openSUSE and packages from Packman. https://build.opensuse.org/package/show/multimedia:libs/ffmpeg-4 https://pmbs.links2linux.org/package/show/Essentials/A_tw-ffmpeg The Packman version always has a higher release version than the one in the distribution. I'm interested in this, as I try to package electron for Fedora. The big problem is the included ffmpeg. With openSUSE I can just use the system ffmpeg, with Fedora I have to do some source code voodoo which I really would like to avoid. Thanks for considering! Best regards Andreas ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG, OPUS, SPEEX, ...) for Fedora
On Monday, November 8, 2021 10:55:32 AM CET Dominik 'Rathann' Mierzejewski wrote: > On Monday, 08 November 2021 at 10:12, Andreas Schneider wrote: > > > Hi, > > > > there are several packages in the distribution which require FFMPEG > > (libavformat, libavcodec, etc.), one of them being chromium. The package > > could be created in a way that you can easily replace it with a version > > from rpmfusion to get to the full encoder/decoder set including H264 etc. > > > > This is working fine with openSUSE and packages from Packman. > > > > https://build.opensuse.org/package/show/multimedia:libs/ffmpeg-4 > > https://pmbs.links2linux.org/package/show/Essentials/A_tw-ffmpeg > > > > The Packman version always has a higher release version than the one in > > the distribution. > > > > I'm interested in this, as I try to package electron for Fedora. The big > > problem is the included ffmpeg. With openSUSE I can just use the system > > ffmpeg, with Fedora I have to do some source code voodoo which I really > > would like to avoid. > > > Maintaining such package would require keeping watch for any new files > you'd need to include and going through legal review each time you do. Did you take a look how they solved it at SUSE? You have list for encoder and decoders which are allowed to be built. So if a new encoder or decoder would be added, it would just not be built. You will just always end up with the same set of encoders/decoders with every update. Packman uses the exact same package as openSUSE and all it does it to enable all encoders and decoders. All packages requiring ffmpeg can just always be built against the system version. It should be less legal work, as you have to check just one package and not several which might include it as third_party source code. > IMO it's much less work to just maintain everything that depends on > FFmpeg in RPM Fusion. > > If you're determined, however, you could start with what Chromium does: > https://src.fedoraproject.org/rpms/chromium/blob/rawhide/f/clean_ffmpeg.sh How is it less work if you need to clean ffmpeg source codes in several projects which include it instead of just linking the system one? It is more prone to errors to remove sources and you have to track it instead of just having a fixed decoder/encoder set you build. > Feel free to flag me for package review. I Best regards Andreas ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG, OPUS, SPEEX, ...) for Fedora
On Monday, November 8, 2021 3:43:37 PM CET Vitaly Zaitsev via devel wrote: > On 08/11/2021 15:35, Neal Gompa wrote: > > > I've done an offline build with some prep work upfront, yes. > > > Fully offline with rebuilding all JS dependencies from sources? > > All minified JS blobs must be rebuild from sources on Fedora infra > instead of downloading them from npm with direct links. > > > > It's not automatically a thing, but it is possible. > > > Can you show the SPEC please? I have electron building offline for Fedora, you can find it here: https://build.opensuse.org/package/show/network:im:signal/nodejs-electron ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG, OPUS, SPEEX, ...) for Fedora
On Tuesday, November 9, 2021 10:28:12 AM CET Vitaly Zaitsev via devel wrote: > On 08/11/2021 16:47, Andreas Schneider wrote: > > > I have electron building offline for Fedora, you can find it here: > > https://build.opensuse.org/package/show/network:im:signal/nodejs-electron > > > Electron core packaging is a quite trivial task (Arch Linux and Debian > have already done this), but what about Electron applications (VS Code > for example)? As I've done the packaging, I strongly disagree! > Most of them download tons of bundled JS blobs from npm during the > build. I don't think it will be easy (or even possible) to build > everything from sources. Can you point me to those tons of bundled JS blobs in the source tarball from the above link please? I don't see them. Thanks for your help! Andreas ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG, OPUS, SPEEX, ...) for Fedora
On Monday, November 8, 2021 6:04:12 PM CET Kevin Kofler via devel wrote: > Andreas Schneider wrote: > > > I have electron building offline for Fedora, you can find it here: > > > > https://build.opensuse.org/package/show/network:im:signal/nodejs-electron > > > I see from the presence of electron-13-openh264-format-security.patch that > you are building the bundled OpenH264. Oh, good catch. I've removed it from the source tarball and disabled it. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG, OPUS, SPEEX, ...) for Fedora
On Wednesday, November 10, 2021 8:55:53 AM CET Vitaly Zaitsev via devel wrote: > On 10/11/2021 08:01, Andreas Schneider wrote: > > > Can you point me to those tons of bundled JS blobs in the source tarball > > from the above link please? I don't see them. > > > https://github.com/microsoft/vscode/blob/main/yarn.lock - 11K lines of > external dependencies. I'm sorry, but didn't we talk about electron and you're pointing to vscode? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG, OPUS, SPEEX, ...) for Fedora
On Wednesday, November 10, 2021 11:27:32 AM CET Vitaly Zaitsev via devel wrote: > On 10/11/2021 09:44, Andreas Schneider wrote: > > > I'm sorry, but didn't we talk about electron and you're pointing to > > vscode? > > My previous message was: > > > > Electron core packaging is a quite trivial task (Arch Linux and > > Debian have already done this), but what about Electron applications > > (VS Code for example)? > > By the way, which Electron app do you want to package? I'm packaging Signal-Desktop completely built from source. https://build.opensuse.org/package/show/network:im:signal/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG, OPUS, SPEEX, ...) for Fedora
On Wednesday, November 10, 2021 3:39:42 PM CET Vitaly Zaitsev via devel wrote: > > Keep mislead people and twisting things if this helps you with packaging > > electron apps on Fedora. > > I think it will be very difficult or even impossible to build Electron > apps completely from sources without using pre-built assets from npm (or > parsing and downloading content from yarn.lock). It is a pain, but doable. I have it working for Signal-Desktop. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG, OPUS, SPEEX, ...) for Fedora
On Thursday, November 11, 2021 11:28:42 AM CET Vitaly Zaitsev via devel wrote: > On 11/11/2021 11:08, Andreas Schneider wrote: > > > I'm packaging Signal-Desktop completely built from source. > > > https://build.opensuse.org/package/view_file/network:im:signal/signal-deskto > p/prepare_vendor.sh?expand=1 > Does this script simply download assets from npm using the "yarn > install" command? Does it look like it only calls 'yarn install' and does nothing else? Maybe look through the "echo" commands to see what it does. Are you looking for the `echo ">>>>>> Cleanup object files"` section? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
rust: Request for packaging rust-html-escape and rust-smallbitvec
Hello, I would like to compile the tree-sitter parser generating tool. For this rust- html-escape and rust-smallbitvec is missing in the distro. It would allow that you can add additional languages for highlighting in neovim. If someone who is familiar with rust could packages those two small extensions, that would be really great! Thanks Andreas ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: rust: Request for packaging rust-html-escape and rust-smallbitvec
On Thursday, December 2, 2021 9:07:06 PM CET Aleksei Bavshin wrote: > `smallbitvec` deps are only needed for benchmark, so the test suite is > actually passing without these. Should be safe to drop with metadata patch. > > rust-tiny_http 0.8.2 also has a benchmark-only dependency `fdlimit` > which we can drop. > > The situation with tree-sitter-cli testsuite is complicated: it requires > a few other github repos with a grammar definitions and who knows what > else. I haven't succeeded in running it so far, so we can keep it turned > off. And that would make `rust-spin` update unnecessary. > > The draft packages are available from > https://copr.fedorainfracloud.org/coprs/alebastr/rust-tree-sitter-cli/; > seems working with available grammar files (with exception of > `build-wasm` and `playground` subcommands which require emscripten). This is great work, thank you very much. I didn't know that the tree-sitter- cli needs it own package and can't be built in the current tree-sitter package. So I will just continue to take care of tree-sitter and just build the lib. So having tree-sitter-cli in the next fedora version would be awesome. Best regards Andreas ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: rust: Request for packaging rust-html-escape and rust-smallbitvec
On Friday, 3 December 2021 18:40:12 CET Aleksei Bavshin wrote: > On 12/3/21 03:15, Andreas Schneider wrote: > > > On Thursday, December 2, 2021 9:07:06 PM CET Aleksei Bavshin wrote: > > > >> `smallbitvec` deps are only needed for benchmark, so the test suite is > >> actually passing without these. Should be safe to drop with metadata > >> patch. >> > >> > >> > >> rust-tiny_http 0.8.2 also has a benchmark-only dependency `fdlimit` > >> which we can drop. > >> > >> > >> > >> The situation with tree-sitter-cli testsuite is complicated: it requires > >> a few other github repos with a grammar definitions and who knows what > >> else. I haven't succeeded in running it so far, so we can keep it turned > >> off. And that would make `rust-spin` update unnecessary. > >> > >> > >> > >> The draft packages are available from > >> https://copr.fedorainfracloud.org/coprs/alebastr/rust-tree-sitter-cli/; > >> seems working with available grammar files (with exception of > >> `build-wasm` and `playground` subcommands which require emscripten). > > > > > > This is great work, thank you very much. I didn't know that the > > tree-sitter- cli needs it own package and can't be built in the current > > tree-sitter package. So I will just continue to take care of tree-sitter > > and just build the lib. > > > > So having tree-sitter-cli in the next fedora version would be awesome. > > > Reviews (and PR for rust-tiny_http update) are sent. > > Upstream issue for missing license file: > https://github.com/tree-sitter/tree-sitter/issues/1520 > > Andreas, do you want to have comaintainer access to the tree-sitter-cli > packages? I can do the co-maintainer if you're interested :-) Andreas ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: nodejs-electron
On Sunday, 27 February 2022 01:37:08 CET Demi Marie Obenour wrote: > On 2/26/22 02:21, Andreas Schneider wrote: > > On Friday, 25 February 2022 14:02:11 CET Neal Gompa wrote: > >> I think this is probably one of those things that would be worth > >> forming a SIG on. An Electron SIG could help with Electron and all > >> Electron-based applications that come into Fedora. > > > > That would be fine by me. The most obvious application would be Element > > (Matrix). https://element.io/ > > How do you plan to rebuild all of the NPM dependencies? “Just use > what is in node_modules” runs into the problem that what is in > node_modules often isn’t actually source code. Yes, I know that most > other packagers are likely using this approach, but it doesn’t meet > Fedora’s “everything must be built from source” requirement. With signal I replaced the binary node modules with source ones. I also make sure that there are no shared libraries or prebuild .node file around. Most of the time a `node-gyp rebuild` is what you need to rebuild the binaries. nodejs-signal-ringrtc was not that easy as it requires webrtc. This also uses ffmpeg and I need a system ffmpeg for that. Also webrtc only offers a static library. So you need to use that to then build ringrtc (rust) and node glue code. It took me a long long time to figure several things out as there is no documentation how to cleanly build for distributions. I'm making it better in small steps whenever I learn something. Andreas ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: nodejs-electron
On Saturday, 26 February 2022 14:19:40 CET Sérgio Basto wrote: > On Fri, 2022-02-25 at 08:02 -0500, Neal Gompa wrote: > > > On Fri, Feb 25, 2022 at 4:54 AM Andreas Schneider > > wrote: > > > > > > > > Hello! > > > > > > Over the past 8 month, I've been working on getting Electron [1] > > > built on > > > Fedora. Yesterday I was finally able to do the first working build > > > for Fedora > > > Rawhide [2]. This was possible because we finally have ffmpeg [3] in > > > Fedora. > > > My use for Electron is that I want to run signal-desktop [4] on > > > Fedora. You > > > can get electron and signal-packages packages for it at [5]. > > > > > > Is there interest to bring nodejs-electron into Fedora and if yes, > > > would > > > someone be interested to maintain it? I don't have the time to > > > maintain it but > > > I'm happy to help as a co-maintainer. > > > > > > > > > I think this is probably one of those things that would be worth > > forming a SIG on. An Electron SIG could help with Electron and all > > Electron-based applications that come into Fedora. > > > > > I built and use element-desktop ( > https://github.com/vector-im/element-desktop#readme ) on my desktop , I > spent 2 or 3 days on hacking the build , at the end I build an rpm with > electon-builder ... conclusion we may need also pack electon-builder. You don't have to. You can point electron builder to your system electron and it will use that. Then you just do not package the electron files. All you need is the resources directory. What you need to do is to identify if element uses binary npm modules and you need to replace them with the sources. Andreas ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: nodejs-electron
On Sunday, 27 February 2022 10:06:17 CET Vitaly Zaitsev via devel wrote:
> On 27/02/2022 08:23, Andreas Schneider wrote:
>
> > You don't have to. You can point electron builder to your system electron
> > and
it will use that. Then you just do not package the electron files.
> > All you need is the resources directory.
>
>
> You must run electron-builder on Fedora Koji. Pre-built packages are not
> allowed.
You should not package electron at all with your package! You should use the
nodejs-electron in the distribution and just point it to the sources to load:
cat <%{buildroot}%{_bindir}/signal-desktop
#!/bin/sh
export NODE_ENV=production
exec %{_bindir}/electron %{_libdir}/%{name}/resources/app.asar "\$@"
EOF
chmod +x %{buildroot}%{_bindir}/signal-desktop
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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: Questions about new free-only FFMPEG in Fedora repos
On Monday, February 28, 2022 3:45:55 AM CET Ian McInerney via devel wrote: > I noticed in the electron thread that we now have FFMPEG 5.0 in the > official Fedora repos, but this will of course mean that certain codecs are > removed due to legal concerns. This prompts a few questions though: > > 1) How are these removed codecs handled in the library? Can we link an > upstream application against FFMPEG in Fedora now and have it gracefully > fail when it tries to access a non-free codec that was removed, or does the > removal of these codecs create a different API that upstream applications > would have to code around? e.g. does it mean they have to add conditional > compilation for the specific codecs they need to use from FFMPEG instead of > just around FFMPEG itself? FFMPEG has an API to query if support for a codec is compiled in or not. Applications should check if the codec they want to use is available. If an application just crashes, bugs should be reported that they should make correct use of the FFMPEG API. > 2) Is there an easily accessible list of the enabled codecs we can point > upstreams to when talking about this? Applications should not care about our lists as it might change in future. They should use the API of ffmpeg to check if a codec is available or not. I hope that helps :-) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: nodejs-electron
On Saturday, March 19, 2022 7:01:46 AM CET Sérgio Basto wrote: > On Sun, 2022-02-27 at 17:15 +0100, Andreas Schneider wrote: > > > On Sunday, 27 February 2022 10:06:17 CET Vitaly Zaitsev via devel > > wrote: > > > > > On 27/02/2022 08:23, Andreas Schneider wrote: > > > > > > > > > > You don't have to. You can point electron builder to your system > > > > electron > > > > and > > > > it will use that. Then you just do not package the electron files. > > > > > > All you need is the resources directory. > > > > > > > > > > > > You must run electron-builder on Fedora Koji. Pre-built packages are > > > not > > > allowed. > > > > > > You should not package electron at all with your package! You should > > use the > > nodejs-electron in the distribution and just point it to the sources to > > load > > > OK, we may not need electron-builder :D, I also mention electron- > builder more to explain how my element-desktop rpm was generated . > > so lets pack element-desktop , I found this > > https://build.opensuse.org/package/view_file/openSUSE:Factory/element-deskto > p/element-desktop.spec > have we nodejs-electron available on copr ? if not, may I put it there > or have we legal constraints ? > > Thanks. I'm building nodejs-electron for rawhide here: https://build.opensuse.org/package/show/network:im:signal/nodejs-electron ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: nodejs-electron
On Tuesday, March 22, 2022 2:11:08 AM CET Sérgio Basto wrote: > On Mon, 2022-03-21 at 15:56 +0100, Andreas Schneider wrote: > > On Saturday, March 19, 2022 7:01:46 AM CET Sérgio Basto wrote: > > > On Sun, 2022-02-27 at 17:15 +0100, Andreas Schneider wrote: > > > > On Sunday, 27 February 2022 10:06:17 CET Vitaly Zaitsev via devel > > > > > > > > wrote: > > > > > On 27/02/2022 08:23, Andreas Schneider wrote: > > > > > > You don't have to. You can point electron builder to your > > > > > > system > > > > > > electron > > > > > > and > > > > > > > > it will use that. Then you just do not package the electron files. > > > > > > > > > > All you need is the resources directory. > > > > > > > > > > You must run electron-builder on Fedora Koji. Pre-built packages > > > > > are > > > > > not > > > > > allowed. > > > > > > > > You should not package electron at all with your package! You > > > > should > > > > use the > > > > nodejs-electron in the distribution and just point it to the > > > > sources to > > > > load > > > > > > OK, we may not need electron-builder :D, I also mention electron- > > > builder more to explain how my element-desktop rpm was generated . > > > > > > so lets pack element-desktop , I found this > > > > > > https://build.opensuse.org/package/view_file/openSUSE:Factory/element-de > > > skto p/element-desktop.spec > > > > > > > > > have we nodejs-electron available on copr ? if not, may I put it > > > there > > > or have we legal constraints ? > > > > > > Thanks. > > > > I'm building nodejs-electron for rawhide here: > > > > https://build.opensuse.org/package/show/network:im:signal/nodejs-electron > > may I put nodejs-electron on copr or have we any legal constraints ? I asked for help to bring it to Fedora! I said I would co-maintain it. So if you want to help feel free too. Currently you can only build for f36+ ... If you do changes, please contribute back! 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
Retire nodejs-diagnostic-language-server
Hi, I would like to retire nodejs-diagnostic-language-server. In case someone is using it and want to maintain it, please speak up :-) Cheers Andreas -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Syntax highlighting with tree-sitter-rpmspec
Hi, I'm working on tree-sitter-rpmspec [1] for syntax highlighting using tree- sitter e.g. in neovim. In the meantime it is working quite well. I don't cover 100% of the spec file specification yet and there are still issues with macros (especially macro nesting). I'm slowly getting there. Below is a screenshot which shows the current state. Left is tree-sitter- rpmspec and right is the vim-regex highlighting. https://xor.cryptomilk.org/neovim/syntax-highlight-neovim.png Try it out, give feedback or create MRs in case you want to contribute code. Neovim: https://github.com/nvim-treesitter/nvim-treesitter?tab=readme-ov-file#adding-parsers Best regards Andreas [1] https://gitlab.com/cryptomilk/tree-sitter-rpmspec -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: tree-sitter build broke Emacs
On Wednesday, 15 January 2025 01:06:19 CET Jerry James wrote: > Emacs is uninstallable in Rawhide due to a tree-sitter soname bump. > Are the tree-sitter maintainers planning to rebuild (quickly!) the > broken dependencies soon? The mass rebuild is about to start... emacs and neovim already have been rebuilt. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: tree-sitter build broke Emacs
On Wednesday, 15 January 2025 22:31:22 CET Jerry James wrote: > On Wed, Jan 15, 2025 at 2:34 AM Andreas Schneider wrote: > > On Wednesday, 15 January 2025 01:06:19 CET Jerry James wrote: > > > Emacs is uninstallable in Rawhide due to a tree-sitter soname bump. > > > Are the tree-sitter maintainers planning to rebuild (quickly!) the > > > broken dependencies soon? The mass rebuild is about to start... > > > > emacs and neovim already have been rebuilt. > > Thank you. Would you please update tree-sitter, emacs, etc. in a side > tag next time? I just followed orders ... https://src.fedoraproject.org/rpms/tree-sitter/pull-request/2 See also https://src.fedoraproject.org/rpms/tree-sitter/pull-request/3 -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Getting rid of GLEW (migrate to GLAD)
On Monday, 14 April 2025 09:53:30 CEST Marián Konček wrote: > Hi, I do not have much experience with other projects, but when I was > doing my OpenGL project at uni, I chose libepoxy. It seemed like a very > simple, zero-configuration drop-in replacement. I just had to #include > its GL headers and link the library. > > Afaik with GLAD you have to do some build steps like generating headers. Yes, either GLAD or libepoxy. Thanks for the pointer. I used GLAD for PrusaSlicer as it was already used. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
Getting rid of GLEW (migrate to GLAD)
Hi, if we want e.g. to build wxWidgets with EGL instead of GLX support, we need to get rid of GLEW. The solution is to use GLAD [2]. GLEW is unmaintained and dead. The replacement is GLAD [2]. In case you're a developer of an application which uses GLEW, migrating to GLAD is pretty straight forward [3]. A lot of applications already migrated to GLAD, but still have GLEW in their BuildRequires. For example mangohud uses GLAD [4]. Please help checking packages if they still use GLEW. If yes, open bug reports upstream to move to GLAD. Packages depending on glew: OpenCTM OpenColorIO amanith asymptote avogadro2-libs bzflag cegui06 colobot ddnet dreamchess endless-sky f3d freedroidrpg gambas3 gource hugin kicad# https://gitlab.com/kicad/code/kicad/-/issues/20647 logstalgia mangohud # Already uses GLAD megaglest meshlab openhmd openmsx openriichi openscad # Has GLAD support in master opentoonz openvr openxr-explorer osgearth paraview prusa-slicer # See [3] pymol quesoglc root rss-glx scorched3d sdljava slop supertux vtk widelands wxmacmolplt Thanks and best regards Andreas [1] https://github.com/Dav1dde/glad [2] https://github.com/Dav1dde/glad [3] https://github.com/prusa3d/PrusaSlicer/pull/14440 [4] https://github.com/flightlessmango/MangoHud/blob/ d416a8314f87910f3c37f15347ebfa5918bac9c2/src/meson.build#L107 -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
Non-responsive maintainer check for ret2libc
Hi, we are trying to get a rebuild of rizin [1] but the maintainer doesn't react. Same applies to the co-maintainer. I've created a non-responsive maintainer bugzilla ticket at [2]. Best regards Andreas [1] https://bugzilla.redhat.com/show_bug.cgi?id=2346253 [2] https://src.fedoraproject.org/rpms/rizin/pull-request/5 -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: tree-sitter build broke Emacs
On Thursday, 20 February 2025 17:15:20 CET Jerry James wrote: > On Wed, Jan 15, 2025 at 2:31 PM Jerry James wrote: > > Thank you. Would you please update tree-sitter, emacs, etc. in a side > > tag next time? > > Except you didn't. Emacs is again broken in Rawhide due to a > tree-sitter update. Meaning I can't do the work I was planning to do > this morning because the build I am working on BuildRequires emacs. > Do you not understand why using a side tag is a good idea? Do you not > understand how to use a side tag? I'm happy to walk you through the > answers to either question if lack of education is the issue here. It was built in a side tag, but the emacs and neovim builds were triggered to early so the packages got built against the old libtree-sitter version in the side tag. See also the comments at https://bodhi.fedoraproject.org/updates/FEDORA-2025-b594b1ea02 We wouldn't have that problem if the Fedora build service would detect a new version and rebuild the dependencies. SUSE solved that problem **more than a decade ago**: https://en.wikipedia.org/wiki/Open_Build_Service Cheers Andreas -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: tree-sitter build broke Emacs
On Thursday, 20 February 2025 17:15:20 CET Jerry James wrote: > On Wed, Jan 15, 2025 at 2:31 PM Jerry James wrote: > > Thank you. Would you please update tree-sitter, emacs, etc. in a side > > tag next time? > > Except you didn't. https://koji.fedoraproject.org/koji/buildinfo?buildID=2662558 Taskbuild (f43-build-side-106186, /rpms/ emacs.git:efc6d1cc8f4378f13f8872716922e5c0071090de) That clearly shows that it got built in a side tag, just the build service doesn't block new builds till dependencies are built to start the job, you have to wait manually. This rocket science has been solved more than a decade ago by SUSE. Try the Open Build Service, it will just work there. Packages are blocked till the dependency is built. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Proposal: Allow all packagers to push empty commits to any package
On Thursday, 20 February 2025 13:17:02 CET Miro Hrončok wrote: > Hello. Hey, > With the recent discussions about provenpackagers in Fedora, I recently got > an idea. I also got an idea, what if the build service detects that a dependency changed and rebuilds the package automatically? Sounds like rocket science? Don't worry it already has been resolved more than a decade ago: https://openbuildservice.org/ Or we just continue having broken packages ever now and then. It is so much fun, right? Andreas -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Is there interest in Text to Speech?
Hi, is there any interest in text to speech? On my desktop system I needed text to speech output to get calendar reminders read to me that I don't miss any meetings or appointments. However most of what is available sounds like it is from the year 2000. I've then found PiperTTS [1] which is really great especially in combination with speech-dispatcher. For example Firefox has support for speech dispatcher and you can use the reader mode to let it read text to you which works great. It isn't a robotic voice like you get from pure espeak-ng. If you want to hear how it sounds you can try at [2]. If someone is interested in maintaining it, I could bring it to fedora and would be co-maintainer. The patches for espeak-ng are all upstream in the meantime, just not in a release yet. It would require adding [7]. It would require speech-dispatcher 0.12 which will be in Fedora 42 [3]. The following packages are needed to be packages: piper-phonemize [4] piper-tts [5] piper-voices [6] The last one might be tricky in Fedora. The build service allows you to do multi package builds. You can do a single piper-voices package but that would be ~2GB in size. Best regards Andreas [1] https://github.com/rhasspy/piper [2] https://piper.ttstool.com/ [3] https://bugzilla.redhat.com/show_bug.cgi?id=2242345 [4] https://build.opensuse.org/package/show/home:gladiac/piper-phonemize [5] https://build.opensuse.org/package/show/home:gladiac/piper-tts [6] https://build.opensuse.org/package/show/home:gladiac/piper-voices [7] https://github.com/espeak-ng/espeak-ng/pull/2127 -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Reducing reliance on "legacy" user-group store(s) like /etc/{passwd,group}
On Wednesday, 28 May 2025 15:51:27 CEST Alexander Bokovoy wrote:
> On Срд, 28 мая 2025, Lennart Poettering wrote:
>
> >On Mi, 28.05.25 12:34, Alexander Bokovoy (aboko...@redhat.com) wrote:
> >
> >
> >> > a group record it will combine a specific userdb group record from one
> >> > backend with the results of a matching GetMemberships() of *all*
> >> > backends and return that as one "struct group" NSS record. Or in other
> >> > words: .gr_name, .gr_passwd, .gr_gid are initialized from the group
> >> > record JSON object, but .gr_mem is initialized from the combination of
> >> > the results of all GetMemberships() IPC calls.
> >>
> >>
> >>
> >> That was my expectation as well, but the result you see in my email is
> >> what I get on Fedora enrolled into IPA.
> >>
> >>
> >>
> >> In addition to that, `getent -s systemd initgroups abokovoy` does not
> >> return
any group membership at all:
> >>
> >>
> >>
> >> $ strace -f -s 1024 -e trace=%net getent -s systemd initgroups abokovoy
> >> ...
> >> socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 4
> >> connect(4, {sa_family=AF_UNIX,
> >> sun_path="/run/systemd/userdb/io.systemd.DynamicUser"}, 45) = 0
> >> socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 7
> >> connect(7, {sa_family=AF_UNIX,
> >> sun_path="/run/systemd/userdb/io.systemd.NamespaceResource"}, 51) = 0
> >> socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 8
> >> connect(8, {sa_family=AF_UNIX,
> >> sun_path="/run/systemd/userdb/io.systemd.DropIn"}, 40) = 0
> >> socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 9
> >> connect(9, {sa_family=AF_UNIX,
> >> sun_path="/run/systemd/userdb/io.systemd.Home"}, 38) = 0
> >> socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 10
> >> connect(10, {sa_family=AF_UNIX,
> >> sun_path="/run/systemd/userdb/io.systemd.Machine"}, 41) = 0
>
> >
> >Note sure I follow? This trace shows only systemd's own five userdb
> >implementations, none provided by sssd? And you used "-s systemd" on
> >the getent cmdline, hence you prohibit NSS to ever query anything else
> >but systemd's userdb.
>
>
> I limited communication to what is not working.
>
>
> >
> >hence of course you are not getting any sssd records, because you
> >don't have the userdb socket for it around, and you don't want the NSS
> >logic to talk to anything but userbd either?
>
>
> I think you are missing my point, indeed. What I am trying to say is that
>
> $ userdbctl groups-of-user --with-dropin=yes --multiplexer=yes
> --with-nss=yes abokovoy
No memberships.
>
> is not expected behavior.
>
> Regardless what I try, userdbctl cannot see groups that I otherwise a
> member of via user lookup. This makes userdb API useless in the context
> I have and I want to understand what is not working here. Are you
> implying that something is incorrect in my usage of userdb API?
I think for this to be working correctly, sssd would need to provide a varlink
interface.
Did you try with winbind (with varlink support) and /etc/userdb files? Either
there is a bug or only available with varlink interfaces and not legacy groups
via nsswitch.
> On the other hand,
>
> $ userdbctl users-in-group admins
> USER GROUP
> abokovoy admins
> adminadmins
>
> 2 memberships listed.
>
> --
> / Alexander Bokovoy
> Sr. Principal Software Engineer
> Security / Identity Management Engineering
> Red Hat Limited, Finland
>
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Reducing reliance on "legacy" user-group store(s) like /etc/{passwd,group}
On Tuesday, 27 May 2025 20:32:45 CEST Neal Gompa wrote: > The usage of the systemd user management suite has been discussed many > times over the past several years. Unfortunately, it has been designed > in such a way that it is impossible to square with central login > services (like AD/IPA/krb5 logins). > > Without a way to handle centralized login, we cannot consider any of > it. On both Fedora KDE and Fedora Workstation, there are requirements > to support GWS/Entra ID and AD/FreeIPA-based logins with local user > storage. We discussed this in the Workstation WG several years ago[1] > and it was even discussed here in devel@ last year[2] (with an LWN > article to summarize it[3]). Samba already has a basic varlink interface [1]. It will be released with Samba 4.23 in autumn. We are currently working on improving it. There is also a plan to implement it for sssd [2]. I'm also working on a C/Rust client library to be able to make use of userdb [3]. We also plan to use the systemd userdb with the localkdc in future [4]. [1] https://gitlab.com/samba-team/samba/-/merge_requests/2928 [2] https://github.com/SSSD/sssd/issues/5104 [3] https://gitlab.com/kirmes/kirmes/ [4] https://blog.cryptomilk.org/2025/02/09/local-authentication-hub/ -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
