Re: Proposed integrated mingw packaging guidelines [Re: Planning to start unifying native and mingw packages]
On Wed, Mar 01, 2023 at 01:45:14PM +, Daniel P. Berrangé wrote: > On Wed, Aug 24, 2022 at 03:00:06PM +0100, Daniel P. Berrangé wrote: > > On Wed, Aug 24, 2022 at 03:57:37PM +0200, Fabio Valentini wrote: > > > On Wed, Aug 24, 2022 at 3:49 PM Daniel P. Berrangé > > > wrote: > > > > > > > > On Sun, Feb 20, 2022 at 10:13:18PM +0100, Sandro Mani wrote: > > > > > Hi > > > > > > > > > > Following recent discussions and to reduce the maintenance burden, I'm > > > > > planning to start merging native and mingw packages. Initially, I'll > > > > > be > > > > > looking at these packages where I maintain both variants: > > > > > > > > I've done the same with all the mingw packages I maintained just > > > > before Fedora 37 branched. So the following native packages now > > > > just contain mingw sub-RPMs: > > > > > > > > libvirt, libvirt-glib, libosinfo, osinfo-db, osinfo-db-tools, gtk-vnc > > > > > > > > I'm so happy to have reduced this maint burden. I see a few new mingw > > > > packages pending in package review and think it'd be nice to first ask > > > > the native maintainer to consider unified package, before we approve > > > > any new separate mingw packages. > > > > > > > > Our Mingw packaging guidelines, however, exclusively describe fully > > > > separated mingw packages. So if I suggest this to a native package > > > > maintainer who is not already familiar with mingw, they would be > > > > right to question whether this is a desirable thing. > > > > > > > > IOW, I think we need to look at getting the mingw packaging docs > > > > updated to promote unified packaging as an officially supported > > > > (and even preferred) option, alongside separate packaging. > > > > > > Sounds great. > > > The Packaging Committee is looking forward to your PR ;) > > > > I don't want to rush into doing that myself in case someone else reading > > along is very enthusiastic to do the work themselves ;-P > > Fast forward 6 months and evidentally no one else was enthusiastic about > updating the MinGW packaging guidelines, so I've taken on that task myself :-) > > I have not yet submitted to the Packaging Committee for approval. The > first draft of updated guidelines I have is here: I've now opened ticket and pull request with the packaging committee https://pagure.io/packaging-committee/issue/1259 https://pagure.io/packaging-committee/pull-request/1260 so ideally please direct any feedback to the above locations. With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Proposed integrated mingw packaging guidelines [Re: Planning to start unifying native and mingw packages]
On Wed, Mar 01, 2023 at 01:58:05PM +, Richard W.M. Jones wrote: > On Wed, Mar 01, 2023 at 01:45:11PM +, Daniel P. Berrangé wrote: > > Our goal is to strongly encourage the use of integrated mingw packaging, > > but still allow native package maintainers the discretion to opt-out of > > this if they feel strongly against handling mingw themselves. The keys > > terms of the updated guidelines are this paragraph: > > > > [quote] > > * Where the same Fedora contributors intend to maintain both the native > >and MinGW builds of a package, they **MUST** use the integrated packaging > >approach. > > > > * Where the upstream project supports the Windows platform as an official > >build target and has automated CI, contributors **SHOULD** prefer the > >integrated MinGW packaging approach. While native package maintainers are > >encouraged to accept this, they may decline this suggestion at their > >discretion. > > When I first read this, it seemed like it was saying that if the > upstream project supports Windows we (strongly) should produce a mingw > package. I understand this is not what you're saying, but perhaps it > could be clarified by adding > > "... and the Fedora packager wishes to provide a mingw library" This whole document is starting from the pov that the person reading wants to provide a mingw library, so I figured that was a given. > > > * Where the upstream project does not have automated testing of Windows > >builds, the MinGW package support **MAY** use the integrated packaging > >approach, subject to agreement of the native package maintainer. > > > > * Where the upstream project only supports Windows builds, the separate > >packaging approach **MUST** be used. There will be no corresponding > >native package in Fedora expected. This situation is rare. > > I'm actually trying to think of a case. Maybe the tools I wrote like > mingw-nsiswrapper and mingw-crossreport? The second one should > probably be removed, since it's not very relevant today. mingw-winpthreads, mingw-portablexdr (ok, not inherantly windows only, but there's libtirpc on linux, so portablexdr has no value), mingw-win-iconv, mingw-winstorecompat, mingw-headers. Not many, but wanted to acknowledge they exist > > * When a contributor proposes a new native package to Fedora that provides > >libraries that are known to support Windows, the reviewer **SHOULD** > >inquire whether the contributor would like to add MinGW builds at the > >same time. The contributor **MAY** decline this suggestion at their > >discretion. > > [/quote] With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Proposed integrated mingw packaging guidelines [Re: Planning to start unifying native and mingw packages]
On Wed, Mar 01, 2023 at 01:45:11PM +, Daniel P. Berrangé wrote: > Our goal is to strongly encourage the use of integrated mingw packaging, > but still allow native package maintainers the discretion to opt-out of > this if they feel strongly against handling mingw themselves. The keys > terms of the updated guidelines are this paragraph: > > [quote] > * Where the same Fedora contributors intend to maintain both the native >and MinGW builds of a package, they **MUST** use the integrated packaging >approach. > > * Where the upstream project supports the Windows platform as an official >build target and has automated CI, contributors **SHOULD** prefer the >integrated MinGW packaging approach. While native package maintainers are >encouraged to accept this, they may decline this suggestion at their >discretion. When I first read this, it seemed like it was saying that if the upstream project supports Windows we (strongly) should produce a mingw package. I understand this is not what you're saying, but perhaps it could be clarified by adding "... and the Fedora packager wishes to provide a mingw library" > * Where the upstream project does not have automated testing of Windows >builds, the MinGW package support **MAY** use the integrated packaging >approach, subject to agreement of the native package maintainer. > > * Where the upstream project only supports Windows builds, the separate >packaging approach **MUST** be used. There will be no corresponding >native package in Fedora expected. This situation is rare. I'm actually trying to think of a case. Maybe the tools I wrote like mingw-nsiswrapper and mingw-crossreport? The second one should probably be removed, since it's not very relevant today. > * When a contributor proposes a new native package to Fedora that provides >libraries that are known to support Windows, the reviewer **SHOULD** >inquire whether the contributor would like to add MinGW builds at the >same time. The contributor **MAY** decline this suggestion at their >discretion. > [/quote] Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Proposed integrated mingw packaging guidelines [Re: Planning to start unifying native and mingw packages]
On Wed, Mar 1, 2023 at 7:45 AM Daniel P. Berrangé wrote: > > Fast forward 6 months and evidentally no one else was enthusiastic about > updating the MinGW packaging guidelines, so I've taken on that task myself > :-) > Thanks for volunteering! I converted one of my packages but honestly I've had so little time for packaging that just keeping mine up to date has used all my spare cycles. PRs welcome! Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Proposed integrated mingw packaging guidelines [Re: Planning to start unifying native and mingw packages]
On Wed, Aug 24, 2022 at 03:00:06PM +0100, Daniel P. Berrangé wrote: > On Wed, Aug 24, 2022 at 03:57:37PM +0200, Fabio Valentini wrote: > > On Wed, Aug 24, 2022 at 3:49 PM Daniel P. Berrangé > > wrote: > > > > > > On Sun, Feb 20, 2022 at 10:13:18PM +0100, Sandro Mani wrote: > > > > Hi > > > > > > > > Following recent discussions and to reduce the maintenance burden, I'm > > > > planning to start merging native and mingw packages. Initially, I'll be > > > > looking at these packages where I maintain both variants: > > > > > > I've done the same with all the mingw packages I maintained just > > > before Fedora 37 branched. So the following native packages now > > > just contain mingw sub-RPMs: > > > > > > libvirt, libvirt-glib, libosinfo, osinfo-db, osinfo-db-tools, gtk-vnc > > > > > > I'm so happy to have reduced this maint burden. I see a few new mingw > > > packages pending in package review and think it'd be nice to first ask > > > the native maintainer to consider unified package, before we approve > > > any new separate mingw packages. > > > > > > Our Mingw packaging guidelines, however, exclusively describe fully > > > separated mingw packages. So if I suggest this to a native package > > > maintainer who is not already familiar with mingw, they would be > > > right to question whether this is a desirable thing. > > > > > > IOW, I think we need to look at getting the mingw packaging docs > > > updated to promote unified packaging as an officially supported > > > (and even preferred) option, alongside separate packaging. > > > > Sounds great. > > The Packaging Committee is looking forward to your PR ;) > > I don't want to rush into doing that myself in case someone else reading > along is very enthusiastic to do the work themselves ;-P Fast forward 6 months and evidentally no one else was enthusiastic about updating the MinGW packaging guidelines, so I've taken on that task myself :-) I have not yet submitted to the Packaging Committee for approval. The first draft of updated guidelines I have is here: https://berrange.fedorapeople.org/mingw-integrated/packaging-guidelines/MinGW/ To see the precise 'diff' of new/old guidelines https://pagure.io/fork/berrange/packaging-committee/c/286537d0905835c7931eec0c6b65d35b4d8f7beb?branch=mingw-native As noted in the commit message, this new packaging approach has already been put into practice for a large number of packages, where the same maintainer owned both the native and MinGW components. The packaging guidelines update aims to make this practice official, so that it can be promoted more widely, in cases where the native maintainer is different from the mingw maintainer. Our goal is to strongly encourage the use of integrated mingw packaging, but still allow native package maintainers the discretion to opt-out of this if they feel strongly against handling mingw themselves. The keys terms of the updated guidelines are this paragraph: [quote] * Where the same Fedora contributors intend to maintain both the native and MinGW builds of a package, they **MUST** use the integrated packaging approach. * Where the upstream project supports the Windows platform as an official build target and has automated CI, contributors **SHOULD** prefer the integrated MinGW packaging approach. While native package maintainers are encouraged to accept this, they may decline this suggestion at their discretion. * Where the upstream project does not have automated testing of Windows builds, the MinGW package support **MAY** use the integrated packaging approach, subject to agreement of the native package maintainer. * Where the upstream project only supports Windows builds, the separate packaging approach **MUST** be used. There will be no corresponding native package in Fedora expected. This situation is rare. * When a contributor proposes a new native package to Fedora that provides libraries that are known to support Windows, the reviewer **SHOULD** inquire whether the contributor would like to add MinGW builds at the same time. The contributor **MAY** decline this suggestion at their discretion. [/quote] With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Planning to start unifying native and mingw packages
On 01.01.23 21:48, Jonathan Billings wrote:
On Wed, Aug 24, 2022 at 02:49:21PM +0100, Daniel P. Berrangé wrote:
I've done the same with all the mingw packages I maintained just
before Fedora 37 branched. So the following native packages now
just contain mingw sub-RPMs:
libvirt, libvirt-glib, libosinfo, osinfo-db, osinfo-db-tools, gtk-vnc
I don't know if this is a bug in the spec or in the %find_lang RPM
macro, but I've noticed that these packages have files out of the
mingw sys-root included in the non-mingw packages:
$ find /usr/*mingw32/ -type f | xargs rpm -qf | sort -u
gvnc-1.3.0-5.fc37.x86_64
gvncpulse-1.3.0-5.fc37.x86_64
libosinfo-1.10.0-4.fc37.x86_64
libvirt-glib-4.0.0-6.fc37.x86_64
osinfo-db-tools-1.10.0-4.fc37.x86_64
All the files in those packages look like:
/usr/{arch}-w64-mingw32/sys-root/mingw/share/locale/{lang}/LC_MESSAGES/{package}.mo
There's a thread on the users list about the existence of
/usr/i686-w64-mingw32/ and /usr/x86_64-w64-mingw32/ directories on
systems without any mingw* packages installed, and it looks like on my
system it's all due to the most recent commits to these packages to
include mingw subpackages.
I suspect the %find_lang macro's shell script
(/usr/lib/rpm/find_lang.sh) needs to know not to include the mingw
sysroot, or at least filter it out as part of the spec file %install.
That is how the files are getting included in the non-mingw subpackages.
They have: %files -n ... -f %{name}.lang in the %files section.
This should be fixed as of [1] (plus [2]). Simply rebuilding the
packages against a current mingw-filesystem should fix the issue.
[1]
https://src.fedoraproject.org/rpms/mingw-filesystem/c/846156c1bda9bcff98c850714fa5da688a55e66a?branch=rawhide
[2]
https://src.fedoraproject.org/rpms/mingw-filesystem/c/d897e0bb98731e5536c551be2cf401f1ced71138?branch=rawhide
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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: Planning to start unifying native and mingw packages
On Wed, Aug 24, 2022 at 02:49:21PM +0100, Daniel P. Berrangé wrote:
> I've done the same with all the mingw packages I maintained just
> before Fedora 37 branched. So the following native packages now
> just contain mingw sub-RPMs:
>
> libvirt, libvirt-glib, libosinfo, osinfo-db, osinfo-db-tools, gtk-vnc
I don't know if this is a bug in the spec or in the %find_lang RPM
macro, but I've noticed that these packages have files out of the
mingw sys-root included in the non-mingw packages:
$ find /usr/*mingw32/ -type f | xargs rpm -qf | sort -u
gvnc-1.3.0-5.fc37.x86_64
gvncpulse-1.3.0-5.fc37.x86_64
libosinfo-1.10.0-4.fc37.x86_64
libvirt-glib-4.0.0-6.fc37.x86_64
osinfo-db-tools-1.10.0-4.fc37.x86_64
All the files in those packages look like:
/usr/{arch}-w64-mingw32/sys-root/mingw/share/locale/{lang}/LC_MESSAGES/{package}.mo
There's a thread on the users list about the existence of
/usr/i686-w64-mingw32/ and /usr/x86_64-w64-mingw32/ directories on
systems without any mingw* packages installed, and it looks like on my
system it's all due to the most recent commits to these packages to
include mingw subpackages.
I suspect the %find_lang macro's shell script
(/usr/lib/rpm/find_lang.sh) needs to know not to include the mingw
sysroot, or at least filter it out as part of the spec file %install.
That is how the files are getting included in the non-mingw subpackages.
They have: %files -n ... -f %{name}.lang in the %files section.
--
Jonathan Billings
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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: Planning to start unifying native and mingw packages
On Sat, Sep 03, 2022 at 06:13:21PM +0200, Sandro Mani wrote:
>
> On 03.09.22 18:09, Richard Shaw wrote:
> > On Sat, Sep 3, 2022 at 10:33 AM Richard Shaw wrote:
> >
> > On Sat, Sep 3, 2022 at 10:22 AM Sandro Mani
> > wrote:
> >
> >
> > On 03.09.22 17:10, Richard Shaw wrote:
> > > I'm trying to migrate fltk right now and running into an issue:
> > >
> > > Processing files: fltk-debugsource-1.3.8-4.fc38.x86_64
> > >
> > > RPM build warnings:
> > >
> > > RPM build errors:
> > > error: Could not open %files file
> > > /builddir/build/BUILD/fltk-1.3.8/debugsourcefiles.list: No
> > such file
> > > or directory
> > >
> > > Building the mingw packages seems to be interfering with the
> > native build.
> >
> >
> > I put %{?mingw_package_header} in the %{with mingw} (disabled)
> > conditional this time and the build completed, so something in there is
> > causing the issue.
>
> You actually don't need %{?mingw_package_header} anymore at all (it actually
> should just be a no-op with a current mingw-filesystem).
FYI, we discovered a minor problem with this - historically the
mingw_package_header macro has redirect strip/objdump to the mingw
versions of those binaries.
That redirection was needed historically because the native versions
only know about the native arch elf format. Not too long ago though,
the native binutils started getting built with explicit support for
x86 PE format on all arches.
Unfortunately we just learn the hard way last week that there was a
problem with this for the s390x native build - it enabled both PE
and COFF formats, as a result strip/objdump couldn't decide which
format to use and mangled the mingw DLLs by removing the index.
https://bugzilla.redhat.com/show_bug.cgi?id=2139143
This would packages with merged mingw changes if the published DLL
was created on the s390x builder. If the packages are noarch, IIUC,
it is random which arch Koji decides to publish the mingw packages
from.
Gnutls mistakenly didn't mark its mingw sub-RPMs as noarch, and so
it always published DLLs built on s390x, and this then prevented
any app using mingw DLLs on s390x. Symptom:
/bin/ld: /usr/i686-w64-mingw32/sys-root/mingw/lib/libgnutls.dll.a: error
adding symbols: archive has no index; run ranlib to add one
The binutils / s390x issue is fixed on rawhide now, requested for
F37 too.
GNUTLS also merged a PR to make its mingw sub-RPMs noarch again.
https://src.fedoraproject.org/rpms/gnutls/pull-request/64
There is a small chance that some other package might have published
DLLs that were built on s390x with the problematic binutils. So if
people see the wierd 'archive has no index' error message on a mingw
build, this is where it comes from. The affect DLLs would just need
a rebuild.
With regards,
Daniel
--
|: https://berrange.com -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Planning to start unifying native and mingw packages
On Wed, Aug 24, 2022 at 03:57:37PM +0200, Fabio Valentini wrote: > On Wed, Aug 24, 2022 at 3:49 PM Daniel P. Berrangé > wrote: > > > > On Sun, Feb 20, 2022 at 10:13:18PM +0100, Sandro Mani wrote: > > > Hi > > > > > > Following recent discussions and to reduce the maintenance burden, I'm > > > planning to start merging native and mingw packages. Initially, I'll be > > > looking at these packages where I maintain both variants: > > > > I've done the same with all the mingw packages I maintained just > > before Fedora 37 branched. So the following native packages now > > just contain mingw sub-RPMs: > > > > libvirt, libvirt-glib, libosinfo, osinfo-db, osinfo-db-tools, gtk-vnc > > > > I'm so happy to have reduced this maint burden. I see a few new mingw > > packages pending in package review and think it'd be nice to first ask > > the native maintainer to consider unified package, before we approve > > any new separate mingw packages. > > > > Our Mingw packaging guidelines, however, exclusively describe fully > > separated mingw packages. So if I suggest this to a native package > > maintainer who is not already familiar with mingw, they would be > > right to question whether this is a desirable thing. > > > > IOW, I think we need to look at getting the mingw packaging docs > > updated to promote unified packaging as an officially supported > > (and even preferred) option, alongside separate packaging. > > Sounds great. > The Packaging Committee is looking forward to your PR ;) I've not written up changes for unified specs yet, but the existing docs were kind of crufty in many ways, so I've sent a preparatory PR to clean them up. I don't think there is going to be anything especially surprising in these changes: https://pagure.io/packaging-committee/pull-request/1224 once that's out of the way I'll aim to send a PR for the unified specs changes, which will be the more interesting changes. With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Planning to start unifying native and mingw packages
On 03.09.22 17:10, Richard Shaw wrote: I'm trying to migrate fltk right now and running into an issue: Processing files: fltk-debugsource-1.3.8-4.fc38.x86_64 RPM build warnings: RPM build errors: error: Could not open %files file /builddir/build/BUILD/fltk-1.3.8/debugsourcefiles.list: No such file or directory Building the mingw packages seems to be interfering with the native build. Can you point to the SPEC? Sandro ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Planning to start unifying native and mingw packages
On 9/2/22 5:07 AM, Fabio Valentini wrote: > On Fri, Sep 2, 2022 at 1:43 PM Richard Shaw wrote: >> >>> If looking at a single package in isolation it may look wasteful, but from >>> the POV of the distro as a whole packages with potential mingw sub-RPMs >>> are a small subset of what goes through koji every day. >> >> >> Perhaps, but the engineer in me finds this very distasteful :) >> >> It would probably be too much work but it would be useful to have a >> pseudo-arch "mingw" which would just build on the first available "noarch" >> builder. > > Building noarch subpackages on multiple architectures actually > provides some benefits, even if some - or all - of the output is > thrown away: > > - architecture-specific bugs that result in generation of different > "noarch" subpackages get caught (which they wouldn't be if the > "noarch" subpackage were only ever built once) > - you can run tests for the functionality that's provided by the > "noarch" subpackages on different architectures > - etc. > > For example, all Rust library packages build only "noarch" > subpackages, but the packages themselves are built on *all* > architectures, because we want to know whether the shipped code > actually *compiles* and tests *succeed* on all supported > architectures. If we didn't do that, catching architecture-specific > bugs would be much harder, and would only result in random problems, > or build failures in leaf *application* packages instead of in the > package that actually has the problem. Well since you mention Rust, I'll also counterpoint that I do have the toolchain configured to only use x86_64 to build wasm/mingw noarch subpackages of the standard library. The reason is that they include a crate "disambiguator" hash which does end up capturing host differences as well, so each host arch would end up with different hashes in the target libs. But that doesn't actually matter when other host toolchains just *use* those libs in cross-compilation, so it's fine to ship that noarch everywhere. But the standard library is a little special in that regard, at least until the dynamic -Zbuild-std option may be stabilized. As you say, for most Rust libraries we only ship noarch sources, and it totally makes sense to still build and test those on each host individually. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Planning to start unifying native and mingw packages
On Fri, Sep 2, 2022 at 1:43 PM Richard Shaw wrote: > >> If looking at a single package in isolation it may look wasteful, but from >> the POV of the distro as a whole packages with potential mingw sub-RPMs >> are a small subset of what goes through koji every day. > > > Perhaps, but the engineer in me finds this very distasteful :) > > It would probably be too much work but it would be useful to have a > pseudo-arch "mingw" which would just build on the first available "noarch" > builder. Building noarch subpackages on multiple architectures actually provides some benefits, even if some - or all - of the output is thrown away: - architecture-specific bugs that result in generation of different "noarch" subpackages get caught (which they wouldn't be if the "noarch" subpackage were only ever built once) - you can run tests for the functionality that's provided by the "noarch" subpackages on different architectures - etc. For example, all Rust library packages build only "noarch" subpackages, but the packages themselves are built on *all* architectures, because we want to know whether the shipped code actually *compiles* and tests *succeed* on all supported architectures. If we didn't do that, catching architecture-specific bugs would be much harder, and would only result in random problems, or build failures in leaf *application* packages instead of in the package that actually has the problem. I might remember wrong, but doing the same for Python packages was thought about a few years ago to catch architecture-specific issues more consistently (and not only iff the noarch python package happens to randomly be built on the failing architecture every now and then). Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Planning to start unifying native and mingw packages
On Fri, Sep 2, 2022 at 3:45 AM Daniel P. Berrangé wrote: > On Thu, Sep 01, 2022 at 04:25:28PM -0500, Richard Shaw wrote: > > On Thu, Sep 1, 2022 at 12:38 PM Sandro Mani > wrote: > > > > > > > > On 01.09.22 17:18, Richard Shaw wrote: > > > > I'd like to unify fltk but there are a couple of things I'm still > > > > unclear about... > > > > > > > > 1. If I build the x86_64 package locally via fedpkg or mock, will it > > > > build both the linux and mingw artifacts by default? > > > Unless you have any specific %ifarch etc, yes. > > > > 2. Since mingw packages are considered "noarch" in infrastructure, I > > > > assume there's some magic to prevent arches other than x86_64 from > > > > attempting to build the mingw packages? > > > Not really, but if builders on separate arches produce different > > > artifacts for the noarch packages, the build will fail with a > > > corresponding message like "package XXX built differently on arches > YYY" > > > > > > > Let me rephrase, is the mingw package going to be built on ALL arches > with > > the expectation that they are the same (like -data packages)? If so, that > > seems like a huge waste of resources. > > If looking at a single package in isolation it may look wasteful, but from > the POV of the distro as a whole packages with potential mingw sub-RPMs > are a small subset of what goes through koji every day. > Perhaps, but the engineer in me finds this very distasteful :) It would probably be too much work but it would be useful to have a pseudo-arch "mingw" which would just build on the first available "noarch" builder. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Planning to start unifying native and mingw packages
On Thu, Sep 01, 2022 at 04:25:28PM -0500, Richard Shaw wrote: > On Thu, Sep 1, 2022 at 12:38 PM Sandro Mani wrote: > > > > > On 01.09.22 17:18, Richard Shaw wrote: > > > I'd like to unify fltk but there are a couple of things I'm still > > > unclear about... > > > > > > 1. If I build the x86_64 package locally via fedpkg or mock, will it > > > build both the linux and mingw artifacts by default? > > Unless you have any specific %ifarch etc, yes. > > > 2. Since mingw packages are considered "noarch" in infrastructure, I > > > assume there's some magic to prevent arches other than x86_64 from > > > attempting to build the mingw packages? > > Not really, but if builders on separate arches produce different > > artifacts for the noarch packages, the build will fail with a > > corresponding message like "package XXX built differently on arches YYY" > > > > Let me rephrase, is the mingw package going to be built on ALL arches with > the expectation that they are the same (like -data packages)? If so, that > seems like a huge waste of resources. If looking at a single package in isolation it may look wasteful, but from the POV of the distro as a whole packages with potential mingw sub-RPMs are a small subset of what goes through koji every day. With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Planning to start unifying native and mingw packages
On Thu, Sep 01, 2022 at 04:57:52PM -0500, Michael Cronenworth wrote: > On 9/1/22 4:25 PM, Richard Shaw wrote: > > Let me rephrase, is the mingw package going to be built on ALL arches > > with the expectation that they are the same (like -data packages)? If > > so, that seems like a huge waste of resources. > > The MinGW packages would build on all arches. I believe the original > designation of 'noarch' is due to the cross-compile aspect as you can build > these on any arch and that end users would only use them for development and > not runtime. That has changed recently now that Wine builds most of itself > as Windows PE binaries and depends on .dll files from mingw32/64 packages. The distinction 'development' vs 'runtime' is rather ill-defined, since development includes running tests which is "runtime" usage. Even before Wine was using the DLLs itself, apps could run their own tests inside Wine, or inside a real Windows virtual machine, at their choice. It is still reasonable to have the mingw packages noarch, as for example, people could be using a aarch64 host, doing windows cross-builds for compile only testing and so need the mingw packages installed. With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Planning to start unifying native and mingw packages
On 9/1/22 4:25 PM, Richard Shaw wrote: Let me rephrase, is the mingw package going to be built on ALL arches with the expectation that they are the same (like -data packages)? If so, that seems like a huge waste of resources. The MinGW packages would build on all arches. I believe the original designation of 'noarch' is due to the cross-compile aspect as you can build these on any arch and that end users would only use them for development and not runtime. That has changed recently now that Wine builds most of itself as Windows PE binaries and depends on .dll files from mingw32/64 packages. If you want this to change then you'll need to start with the Packaging Guidelines. Sandro may have his own opinion on it, too. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Planning to start unifying native and mingw packages
On 01.09.22 17:18, Richard Shaw wrote:
I'd like to unify fltk but there are a couple of things I'm still
unclear about...
1. If I build the x86_64 package locally via fedpkg or mock, will it
build both the linux and mingw artifacts by default?
Unless you have any specific %ifarch etc, yes.
2. Since mingw packages are considered "noarch" in infrastructure, I
assume there's some magic to prevent arches other than x86_64 from
attempting to build the mingw packages?
Not really, but if builders on separate arches produce different
artifacts for the noarch packages, the build will fail with a
corresponding message like "package XXX built differently on arches YYY"
I would like some clear documentation, that if I'm troubleshooting
either the x86_64 or mingw builds, that it's trivial to disable the
one I'm not working on to speed up build iterations.
You can add
%bcond_without mingw
wrap the %package, %files, and portions inside %build and %install with
%if %{with mingw}
...
%endif
and if you'd like to disable the mingw build, just change the bcond to
%bcond_with mingw
HTH
Sandro
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Planning to start unifying native and mingw packages
I'd like to unify fltk but there are a couple of things I'm still unclear about... 1. If I build the x86_64 package locally via fedpkg or mock, will it build both the linux and mingw artifacts by default? 2. Since mingw packages are considered "noarch" in infrastructure, I assume there's some magic to prevent arches other than x86_64 from attempting to build the mingw packages? I would like some clear documentation, that if I'm troubleshooting either the x86_64 or mingw builds, that it's trivial to disable the one I'm not working on to speed up build iterations. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Planning to start unifying native and mingw packages
On 26.08.22 05:30, Michael Cronenworth wrote:
On 8/25/22 11:42 AM, Sandro Mani wrote:
You might also want to add the mingw debuginfo packages to those.
Ah, thanks. I'm used to the debuginfo packages being automatically
added thanks to %{mingw_package_header}.
I wonder if we could have the install macros updated to handle this in
a native package scenario.
Would be nice, it's IMO the only "ugly" part of unification that remains.
Sandro
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Planning to start unifying native and mingw packages
On 8/25/22 11:42 AM, Sandro Mani wrote:
You might also want to add the mingw debuginfo packages to those.
Ah, thanks. I'm used to the debuginfo packages being automatically added thanks to
%{mingw_package_header}.
I wonder if we could have the install macros updated to handle this in a native
package scenario.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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: Planning to start unifying native and mingw packages
On Thu, Aug 25, 2022 at 06:42:52PM +0200, Sandro Mani wrote: > > On 25.08.22 18:40, Michael Cronenworth wrote: > > On 8/25/22 1:33 AM, Marián Konček wrote: > > > I could however open a PR to add them to the native packages. Do we > > > have some libraries where this unification is already finished so > > > that I could take inspiration? > > > > FAudio > > vkd3d > > You might also want to add the mingw debuginfo packages to those. Also if the package is used in RHEL, it may be desirable to make the mingw sub-packages conditional, so that they don't get enabled when the Fedora spec is later rebuilt in a RHEL build root. I've got an example here which is fairly simple, for an app using meson: https://src.fedoraproject.org/rpms/libosinfo/c/c567145568cb401ce5143e5829f1d60ca45f77dc?branch=rawhide If the app uses autotools still it is a little more complex, as you'll need to make the native build use builddir != srcdir before adding the mingw bits. Unfortunately %configure doesn't do this by default, while meson does (and cmake does too iirc). To adapt autotools based app native build use something approximately like this: %define _configure ../configure mkdir build_native cd build_native %configure ...args... %make_build cd .. and similar during install phase cd build_native %make_install cd .. With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Planning to start unifying native and mingw packages
On 25.08.22 18:40, Michael Cronenworth wrote: On 8/25/22 1:33 AM, Marián Konček wrote: I could however open a PR to add them to the native packages. Do we have some libraries where this unification is already finished so that I could take inspiration? FAudio vkd3d You might also want to add the mingw debuginfo packages to those. Sandro ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Planning to start unifying native and mingw packages
On 8/25/22 1:33 AM, Marián Konček wrote: I could however open a PR to add them to the native packages. Do we have some libraries where this unification is already finished so that I could take inspiration? FAudio vkd3d ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Planning to start unifying native and mingw packages
On 25.08.22 08:33, Marián Konček wrote: I noticed this thread, I develop a personal project where I use about 10 C libraries, I noticed that "glfw", "libsodium" and "libevent" do not have their corresponding mingw packages. I was considering trying to package them but unifying them with the native packages would be better. Of course, this would put more pressure on the maintainers. I could however open a PR to add them to the native packages. Do we have some libraries where this unification is already finished so that I could take inspiration? Yes, quite a few actually, to list the ones I adapted: eigen3 enchant2 freeimage gdal GeographicLib geos giflib gtkspell3 gtkspellmm30 jxrlib leptonica libgeotiff libimagequant libkml librttopo libspatialite libwebp openjpeg2 OpenSceneGraph osgearth podofo proj python-pillow qtspell shapelib svg2svgt tesseract uriparser Sandro ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Planning to start unifying native and mingw packages
I noticed this thread, I develop a personal project where I use about 10 C libraries, I noticed that "glfw", "libsodium" and "libevent" do not have their corresponding mingw packages. I was considering trying to package them but unifying them with the native packages would be better. Of course, this would put more pressure on the maintainers. I could however open a PR to add them to the native packages. Do we have some libraries where this unification is already finished so that I could take inspiration? On 24. 8. 2022 16:00, Daniel P. Berrangé wrote: On Wed, Aug 24, 2022 at 03:57:37PM +0200, Fabio Valentini wrote: On Wed, Aug 24, 2022 at 3:49 PM Daniel P. Berrangé wrote: On Sun, Feb 20, 2022 at 10:13:18PM +0100, Sandro Mani wrote: Hi Following recent discussions and to reduce the maintenance burden, I'm planning to start merging native and mingw packages. Initially, I'll be looking at these packages where I maintain both variants: I've done the same with all the mingw packages I maintained just before Fedora 37 branched. So the following native packages now just contain mingw sub-RPMs: libvirt, libvirt-glib, libosinfo, osinfo-db, osinfo-db-tools, gtk-vnc I'm so happy to have reduced this maint burden. I see a few new mingw packages pending in package review and think it'd be nice to first ask the native maintainer to consider unified package, before we approve any new separate mingw packages. Our Mingw packaging guidelines, however, exclusively describe fully separated mingw packages. So if I suggest this to a native package maintainer who is not already familiar with mingw, they would be right to question whether this is a desirable thing. IOW, I think we need to look at getting the mingw packaging docs updated to promote unified packaging as an officially supported (and even preferred) option, alongside separate packaging. Sounds great. The Packaging Committee is looking forward to your PR ;) I don't want to rush into doing that myself in case someone else reading along is very enthusiastic to do the work themselves ;-P With regards, Daniel -- Marián Konček ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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: Planning to start unifying native and mingw packages
On Wed, Aug 24, 2022 at 03:57:37PM +0200, Fabio Valentini wrote: > On Wed, Aug 24, 2022 at 3:49 PM Daniel P. Berrangé > wrote: > > > > On Sun, Feb 20, 2022 at 10:13:18PM +0100, Sandro Mani wrote: > > > Hi > > > > > > Following recent discussions and to reduce the maintenance burden, I'm > > > planning to start merging native and mingw packages. Initially, I'll be > > > looking at these packages where I maintain both variants: > > > > I've done the same with all the mingw packages I maintained just > > before Fedora 37 branched. So the following native packages now > > just contain mingw sub-RPMs: > > > > libvirt, libvirt-glib, libosinfo, osinfo-db, osinfo-db-tools, gtk-vnc > > > > I'm so happy to have reduced this maint burden. I see a few new mingw > > packages pending in package review and think it'd be nice to first ask > > the native maintainer to consider unified package, before we approve > > any new separate mingw packages. > > > > Our Mingw packaging guidelines, however, exclusively describe fully > > separated mingw packages. So if I suggest this to a native package > > maintainer who is not already familiar with mingw, they would be > > right to question whether this is a desirable thing. > > > > IOW, I think we need to look at getting the mingw packaging docs > > updated to promote unified packaging as an officially supported > > (and even preferred) option, alongside separate packaging. > > Sounds great. > The Packaging Committee is looking forward to your PR ;) I don't want to rush into doing that myself in case someone else reading along is very enthusiastic to do the work themselves ;-P With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Planning to start unifying native and mingw packages
On Wed, Aug 24, 2022 at 3:49 PM Daniel P. Berrangé wrote: > > On Sun, Feb 20, 2022 at 10:13:18PM +0100, Sandro Mani wrote: > > Hi > > > > Following recent discussions and to reduce the maintenance burden, I'm > > planning to start merging native and mingw packages. Initially, I'll be > > looking at these packages where I maintain both variants: > > I've done the same with all the mingw packages I maintained just > before Fedora 37 branched. So the following native packages now > just contain mingw sub-RPMs: > > libvirt, libvirt-glib, libosinfo, osinfo-db, osinfo-db-tools, gtk-vnc > > I'm so happy to have reduced this maint burden. I see a few new mingw > packages pending in package review and think it'd be nice to first ask > the native maintainer to consider unified package, before we approve > any new separate mingw packages. > > Our Mingw packaging guidelines, however, exclusively describe fully > separated mingw packages. So if I suggest this to a native package > maintainer who is not already familiar with mingw, they would be > right to question whether this is a desirable thing. > > IOW, I think we need to look at getting the mingw packaging docs > updated to promote unified packaging as an officially supported > (and even preferred) option, alongside separate packaging. Sounds great. The Packaging Committee is looking forward to your PR ;) Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Planning to start unifying native and mingw packages
On Sun, Feb 20, 2022 at 10:13:18PM +0100, Sandro Mani wrote: > Hi > > Following recent discussions and to reduce the maintenance burden, I'm > planning to start merging native and mingw packages. Initially, I'll be > looking at these packages where I maintain both variants: I've done the same with all the mingw packages I maintained just before Fedora 37 branched. So the following native packages now just contain mingw sub-RPMs: libvirt, libvirt-glib, libosinfo, osinfo-db, osinfo-db-tools, gtk-vnc I'm so happy to have reduced this maint burden. I see a few new mingw packages pending in package review and think it'd be nice to first ask the native maintainer to consider unified package, before we approve any new separate mingw packages. Our Mingw packaging guidelines, however, exclusively describe fully separated mingw packages. So if I suggest this to a native package maintainer who is not already familiar with mingw, they would be right to question whether this is a desirable thing. IOW, I think we need to look at getting the mingw packaging docs updated to promote unified packaging as an officially supported (and even preferred) option, alongside separate packaging. With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Planning to start unifying native and mingw packages
On 14.03.22 14:13, Daniel P. Berrangé wrote: On Mon, Mar 14, 2022 at 01:06:34PM +, Daniel P. Berrangé wrote: On Sun, Feb 20, 2022 at 10:13:18PM +0100, Sandro Mani wrote: Hi Following recent discussions and to reduce the maintenance burden, I'm planning to start merging native and mingw packages. Initially, I'll be looking at these packages where I maintain both variants: Thanks for driving this idea forward, I think it'll be very good for maintainers in the long run. I'm performing test builds here [1]. Once I've got them all building there, if there are no objections, I plan to push to F37 and retire all the corresponding mingw repos. Sandro [1] https://copr.fedorainfracloud.org/coprs/smani/mingw-unified-spec/builds/ Seems to be a 404 - is it marked private perhaps ? Never mind, I was blinded by the other response into thinking this was a new thread, where as the orignal mail was actually weeks old. Right, I already went ahead and merged the work ;) So far I've not seen any side-effects directly related to unifying the two builds. Sandro ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Planning to start unifying native and mingw packages
On 14.03.22 14:02, Michael Cronenworth wrote: On 2/20/22 3:13 PM, Sandro Mani wrote: Following recent discussions and to reduce the maintenance burden, I'm planning to start merging native and mingw packages. What do you feel about native packages depending on MinGW packages? As far as I can judge, I don't see any problem. Sandro ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Planning to start unifying native and mingw packages
On Mon, Mar 14, 2022 at 01:06:34PM +, Daniel P. Berrangé wrote: > On Sun, Feb 20, 2022 at 10:13:18PM +0100, Sandro Mani wrote: > > Hi > > > > Following recent discussions and to reduce the maintenance burden, I'm > > planning to start merging native and mingw packages. Initially, I'll be > > looking at these packages where I maintain both variants: > > Thanks for driving this idea forward, I think it'll be very good for > maintainers in the long run. > > > > > > I'm performing test builds here [1]. Once I've got them all building there, > > if there are no objections, I plan to push to F37 and retire all the > > corresponding mingw repos. > > > > Sandro > > > > [1] https://copr.fedorainfracloud.org/coprs/smani/mingw-unified-spec/builds/ > > Seems to be a 404 - is it marked private perhaps ? Never mind, I was blinded by the other response into thinking this was a new thread, where as the orignal mail was actually weeks old. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Planning to start unifying native and mingw packages
On Sun, Feb 20, 2022 at 10:13:18PM +0100, Sandro Mani wrote: > Hi > > Following recent discussions and to reduce the maintenance burden, I'm > planning to start merging native and mingw packages. Initially, I'll be > looking at these packages where I maintain both variants: Thanks for driving this idea forward, I think it'll be very good for maintainers in the long run. > > I'm performing test builds here [1]. Once I've got them all building there, > if there are no objections, I plan to push to F37 and retire all the > corresponding mingw repos. > > Sandro > > [1] https://copr.fedorainfracloud.org/coprs/smani/mingw-unified-spec/builds/ Seems to be a 404 - is it marked private perhaps ? Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Planning to start unifying native and mingw packages
On 2/20/22 3:13 PM, Sandro Mani wrote: Following recent discussions and to reduce the maintenance burden, I'm planning to start merging native and mingw packages. What do you feel about native packages depending on MinGW packages? Upstream wine has begun to depend on .dll files. Wine 7.3 bundles vkd3d[1][2], but will also look for it if provided with a location for the .dll files. Currently, Wine 7.2 and lower look for the native vkd3d files. [1] https://source.winehq.org/git/vkd3d.git/ [2] https://src.fedoraproject.org/rpms/vkd3d ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
Planning to start unifying native and mingw packages
Hi Following recent discussions and to reduce the maintenance burden, I'm planning to start merging native and mingw packages. Initially, I'll be looking at these packages where I maintain both variants: eigen3 mingw-eigen3 enchant2 mingw-enchant2 freeimage mingw-freeimage gdal mingw-gdal GeographicLib mingw-GeographicLib geos mingw-geos giflib mingw-giflib gtkspell3 mingw-gtkspell3 gtkspellmm30 mingw-gtkspellmm30 jxrlib mingw-jxrlib leptonica mingw-leptonica libgeotiff mingw-libgeotiff libimagequant mingw-libimagequant libkml mingw-libkml librttopo mingw-librttopo libspatialite mingw-libspatialite libwebp mingw-libwebp openjpeg2 mingw-openjpeg2 OpenSceneGraph mingw-OpenSceneGraph osgearth mingw-osgearth podofo mingw-podofo proj mingw-proj python-pillow mingw-python-pillow qtspell mingw-qtspell shapelib mingw-shapelib svg2svgt mingw-svg2svgt tesseract mingw-tesseract uriparser mingw-uriparser I'm performing test builds here [1]. Once I've got them all building there, if there are no objections, I plan to push to F37 and retire all the corresponding mingw repos. Sandro [1] https://copr.fedorainfracloud.org/coprs/smani/mingw-unified-spec/builds/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/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
