New default behaviour at %prep section spec-file

[Vascom]

Hi all.

As I noticed Fedora change default behaviour at %prep section of spec-file.

Now by default executed %{set_build_flags} and added "-p1" parameter
to %autosetup for applying patches.

Is it really?
Are there other changes?
When will these changes be included in the Packaging Guidelines?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: New default behaviour at %prep section spec-file

[Sérgio Basto]

On Wed, 2023-03-01 at 12:22 +0300, Vascom wrote:
> Hi all.
> 
> As I noticed Fedora change default behaviour at %prep section of
> spec-file.
> 
> Now by default executed %{set_build_flags} and added "-p1" parameter
> to %autosetup for applying patches.
> 
> Is it really?
> Are there other changes?
> When will these changes be included in the Packaging Guidelines?

I think is this that you are looking for 
https://fedoraproject.org/wiki/Changes/SetBuildFlagsBuildCheck

> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/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

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: New default behaviour at %prep section spec-file

[Vascom]

Thanks.

About %autosetup - my mistake too.

Thread closed.

ср, 1 мар. 2023 г. в 13:48, Sérgio Basto :
>
> On Wed, 2023-03-01 at 12:22 +0300, Vascom wrote:
> > Hi all.
> >
> > As I noticed Fedora change default behaviour at %prep section of
> > spec-file.
> >
> > Now by default executed %{set_build_flags} and added "-p1" parameter
> > to %autosetup for applying patches.
> >
> > Is it really?
> > Are there other changes?
> > When will these changes be included in the Packaging Guidelines?
>
> I think is this that you are looking for
> https://fedoraproject.org/wiki/Changes/SetBuildFlagsBuildCheck
>
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/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
>
> --
> Sérgio M. B.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Update of catch to Catch2 v3

[Vitaly Zaitsev via devel]

On 28/02/2023 17:05, Vitaly Zaitsev wrote:
The tests passed on GitHub CI, but not on Fedora Koji. Maybe 
FORTIFY_SOURCE=3 or GLIB assertions strikes again.


Found issue. Current Fedora catch v3 build uses Debug configuration and 
fails on assertions (src/catch2/catch_test_case_info.cpp:147).


Please add -DCMAKE_BUILD_TYPE=Release or 
-DCMAKE_BUILD_TYPE=RelWithDebInfo to %cmake and rebuild all catch 
packages for F38+.


--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.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

Fedora 38 compose report: 20230301.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-38-20230228.n.0
NEW: Fedora-38-20230301.n.0

= SUMMARY =
Added images:0
Dropped images:  2
Added packages:  3
Dropped packages:0
Upgraded packages:   10
Downgraded packages: 0

Size of added packages:  6.97 MiB
Size of dropped packages:0 B
Size of upgraded packages:   13.77 MiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   81.23 KiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Kinoite dvd-ostree ppc64le
Path: Kinoite/ppc64le/iso/Fedora-Kinoite-ostree-ppc64le-38-20230228.n.0.iso
Image: Silverblue dvd-ostree x86_64
Path: Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-38-20230228.n.0.iso

= ADDED PACKAGES =
Package: python-rapidfuzz-2.13.7-1.fc38
Summary: Rapid fuzzy string matching in Python and C++ using the Levenshtein 
Distance
RPMs:python3-rapidfuzz python3-rapidfuzz+full python3-rapidfuzz-devel
Size:6.79 MiB

Package: python-scikit-build-0.16.7-1.fc38
Summary: Improved build system generator for Python C/C++/Fortran/Cython 
extensions
RPMs:python3-scikit-build
Size:151.66 KiB

Package: python-trove-classifiers-2023.2.20-1.fc38
Summary: Canonical source for classifiers on PyPI (pypi.org)
RPMs:python3-trove-classifiers
Size:25.34 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  gnome-software-44~beta-2.fc38
Old package:  gnome-software-44~beta-1.fc38
Summary:  A software center for GNOME
RPMs: gnome-software gnome-software-devel gnome-software-rpm-ostree
Size: 10.36 MiB
Size change:  334 B
Changelog:
  * Thu Feb 23 2023 Adam Williamson  - 44~beta-2
  - Backport MR #1635 to fix update notifications


Package:  kf5-kidletime-5.103.0-2.fc38
Old package:  kf5-kidletime-5.103.0-1.fc38
Summary:  KDE Frameworks 5 Tier 1 integration module for idle time detection
RPMs: kf5-kidletime kf5-kidletime-devel
Size: 442.01 KiB
Size change:  57.10 KiB
Changelog:
  * Thu Feb 23 2023 Marc Deop i Argem??  - 5.103.0-2
  - Add missing BuildRequires.
  - Add KF5IdleTimeWaylandPlugin.so file.


Package:  pkgconf-1.8.0-6.fc38
Old package:  pkgconf-1.8.0-5.fc38
Summary:  Package compiler and linker metadata toolkit
RPMs: libpkgconf libpkgconf-devel pkgconf pkgconf-m4 pkgconf-pkg-config
Size: 521.22 KiB
Size change:  -1.11 KiB
Changelog:
  * Wed Feb 22 2023 Neal Gompa  - 1.8.0-6
  - Drop dependency on system-rpm-config (#2172406)


Package:  poetry-1.3.2-2.fc38
Old package:  poetry-1.2.2-4.fc38
Summary:  Python dependency management and packaging made easy
RPMs: poetry python3-poetry
Size: 603.47 KiB
Size change:  13.44 KiB
Changelog:
  * Mon Feb 20 2023 Tom Hrn??iar  - 1.3.2-1
  - Update to 1.3.2

  * Mon Feb 20 2023 Tom Hrn??iar  - 1.3.2-2
  - Update to 1.3.2 - disable bootstrap


Package:  python-cleo-2.0.1-1.fc38
Old package:  python-cleo-1.0.0~a5-2.fc38
Summary:  Create beautiful and testable command-line interfaces
RPMs: python3-cleo
Size: 235.26 KiB
Size change:  -409 B
Changelog:
  * Tue Feb 21 2023 Tom Hrn??iar  - 2.0.1-1
  - Update to 2.0.1


Package:  python-crashtest-0.4.1-1.fc38
Old package:  python-crashtest-0.3.1-9.fc38
Summary:  Manage Python errors with ease
RPMs: python3-crashtest
Size: 33.08 KiB
Size change:  274 B
Changelog:
  * Tue Feb 21 2023 Tom Hrn??iar  - 0.4.1-1
  - Update to 0.4.1


Package:  python-poetry-core-1.4.0-1.fc38
Old package:  python-poetry-core-1.3.2-2.fc38
Summary:  Poetry PEP 517 Build Backend
RPMs: python3-poetry-core
Size: 1.21 MiB
Size change:  25.80 KiB
Changelog:
  * Mon Feb 20 2023 Tom Hrn??iar  - 1.4.0-1
  - Update to 1.4.0


Package:  python-poetry-plugin-export-1.3.0-2.fc38
Old package:  python-poetry-plugin-export-1.1.2-2.fc38
Summary:  Poetry plugin to export the dependencies to various formats
RPMs: python3-poetry-plugin-export
Size: 34.74 KiB
Size change:  -41 B
Changelog:
  * Mon Feb 20 2023 Tom Hrn??iar  - 1.3.0-1
  - Update to 1.3.0

  * Mon Feb 20 2023 Tom Hrn??iar  - 1.3.0-2
  - Update to 1.3.0 - without bootstrap


Package:  rust-gio-0.16.7-2.fc38
Old package:  rust-gio-0.16.7-1.fc38
Summary:  Rust bindings for the Gio library
RPMs: rust-gio+default-devel rust-gio+dox-devel rust-gio+v2_58-devel 
rust-gio+v2_60-devel rust-gio+v2_62-devel rust-gio+v2_64-devel 
rust-gio+v2_66-devel rust-gio+v2_68-devel rust-gio+v2_70-devel 
rust-gio+v2_72-devel rust-gio+v2_74-devel rust-gio-devel
Size: 312.34 KiB
Size change:  1.14 KiB
Changelog:
  * Tue Feb 21 2023 Fabio Valentini  - 0.16.7-2
  - Bump serial_test dev-dependency from 0.9 to 1


Package:  rust-serial_test-1.0.0-2.fc38
Old package:  rust-serial_test-1.0.0-1.fc38
Summary:  Allows for the creation of serialised Rust tests
RPMs: rust-serial_test+async-devel rust-serial_test+default

Re: SPDX Statistics - University of Constantinople edition

[Otto Liljalaakso]

Omair Majid kirjoitti 1.3.2023 klo 5.13:

Hi,

Miroslav Suchý  writes:


The list of packages needed to be converted is again here:

 
https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx-final.txt

List by package maintainers is here


https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx-final-maintainers.txt


One package that I care about (`dotnet7.0`) was added to Fedora after
the Let's-move-Fedora-to-SPDX decision was finalized. So the package has
been using SPDX identifiers since the original package review.

How do I make sure such a package is recognized as converted-to-SPDX?


I have the same issue with iir1, also it has been SPDX from the birth, 
but now flagged as needing conversion.


I think Miroslav and company are doing an amazing job with the follow up 
and trying to ensure that everything gets converted eventually. However, 
please try to avoid creating busy work for packagers. We also have 
actual packaging tasks to handle.


The solution for new packages should be such that packagers do not need 
to do anything special. Could you just check package age and exclude 
anything added after SPDX went live? Any problems in such packages are 
just regular guidelines violations. They are important to fix of course, 
but strictly speaking not related to the migration effort.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Update of catch to Catch2 v3

[Vitaly Zaitsev via devel]

On 01/03/2023 12:26, Vitaly Zaitsev wrote:
Found issue. Current Fedora catch v3 build uses Debug configuration and 
fails on assertions (src/catch2/catch_test_case_info.cpp:147).


Fixed this issue in upstream. But switching Fedora package to the 
Release configuration will be great too.


--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.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: c++ packaging of contour terminal and libunicode

[Kevin Kofler via devel]

Dan Horák wrote:
> another option is to build the internal libs as static, then they won't
> have to be installed. Try appending
> -DBUILD_SHARED_LIBS:BOOL=OFF
> to the cmake flags

I guess this is also why the OP ran into the error with the non-PIC code in 
the static library in the RPM build and not elsewhere. Shared libraries need 
to contain all-PIC code, so both the shared libraries themselves and any 
static libraries linked into them need to be PIC. This is not the case if 
the static libraries are linked only into executables. So if the build has 
only ever been tested with BUILD_SHARED_LIBS off (the upstream CMake 
default), this will not have been caught.

Generally, for an upstream project, it is a better idea to explicitly mark 
the library as STATIC in the CMakeLists.txt files if upstream does not 
support building it as a shared library.

By the way, if upstream is not going to install the static library, they can 
also declare the library as OBJECT instead of STATIC (a CMake-specific 
feature). That creates a kind of virtual static library, where CMake will 
link the object files directly into the target and skip the generation of 
the unnecessary .a file.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Modernize Thread Building Blocks for Fedora 39 (System-Wide Change proposal)

[Kevin Kofler via devel]

Zbigniew Jędrzejewski-Szmek wrote:
> Parallel runtime installation is obviously required.
> But is it necessary to have parallel installation of devel headers?
> It might be less work to have conflicting -devel packages and just
> BuildRequire one or the other.

Conflicting -devel packages are an annoyance when you want a system set up 
for local (including non-mock and especially non-RPM) builds.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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]

[Daniel P . Berrangé]

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: Proposed integrated mingw packaging guidelines [Re: Planning to start unifying native and mingw packages]

[Richard Shaw]

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

Re: Proposed integrated mingw packaging guidelines [Re: Planning to start unifying native and mingw packages]

[Richard W.M. Jones]

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]

[Daniel P . Berrangé]

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: c++ packaging of contour terminal and libunicode

[Felix Wang]

I open an issue of the upstream repo and reported the maintainer, It was fixed 
by explicitly setting the libs as static. And thanks for your clear 
clarification.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

Packit service not submitting builds or updates for branched / F38

[Fabio Valentini]

Hi all,

$SUBJECT is now happening for (at least) the second time with F38. It
looks like the packit service is mis-configured and does not submit
any builds updates for "branched":

https://bodhi.fedoraproject.org/updates/?user=packit

Having updates in Fedora 37 (stable branch) and Rawhide (development
branch), and in some cases even Fedora 36 (oldstable branch), but
*not* in the branch for the next release is really bad.

Can we get this fixed please? Errors like these really do make me not
trust packit with any of my packages.

It would be great if $PACKIT_ADMIN would go through the updates that
were filed by packit since the F38 branch point and submit missing
builds and updates? Preferably before the F38 final freeze? ...

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: Proposal: drop delta rpms (for real this time)

[Kevin Kofler via devel]

Petr Pisar wrote:
> Would that affect all clients? No. updateinfo.xml can only be downloaded
> by clients requesting that data. People doing "dnf upgrade" can safely
> skip it.

Keep in mind that updateinfo.xml is also used by GUI updaters such as 
dnfdragora or plasma-pk-updates to display details about the updates, not 
just for CLI filtering purposes (dnf --security, dnf --advisory=…).

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Changes to Bugzilla API key requirements

[Kevin Kofler via devel]

Kevin P. Fleming wrote:
> Not O365, but Google Workspace... that ship sailed some time ago (I'm
> sending this using Thunderbird going through Google Workspace, so at
> least I don't have to *see* GMail...)

#facepalm# 🤦

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Packit service not submitting builds or updates for branched / F38

[Matej Focko]

Hi,

we have already been informed about the issue and fix for the issue is 
ready (will be deployed to production next Tuesday, unless we hit any 
issues in the staging instance)


https://github.com/packit/packit/pull/1863

This issue has been hit after a change in the Bodhi API that introduced 
a new state for releases that are in a “frozen” state (see the release 
schedule for Fedora 38, we have entered the Beta Freeze on February 20; 
also last F38 Bodhi update from Packit has been created on February 22, 
which is 15 days after branching and 2 days after the Beta Freeze, 
therefore there was no reason to suspect any issues being present).


On the other hand, if I didn't know about the merged PR, I wouldn't be 
able to provide you help in any way, since you haven't provided any 
additional details that would allow me to assess your issue 
appropriately (no exceptions have been caught and furthermore I don't 
know what package we are talking about).


In case you hit any issue in the future, feel free to reach out for help 
on any of the following platforms:


* #packit:fedora.im on Matrix
* #packit on libera.chat
* he...@packit.dev

You can also file an issue with details (project, trigger, steps to 
reproduce, etc.) at https://github.com/packit/packit-service/issues/new 
if you hit a bug.
We do not consider this mailing list as a way to submit bug reports as 
it would create too much noise and also spam other people, thanks for 
understanding.


Thanks for using Packit :)

On behalf of Packit Team
Matej

On 3/1/23 15:31, Fabio Valentini wrote:
> Hi all,
>
> $SUBJECT is now happening for (at least) the second time with F38. It
> looks like the packit service is mis-configured and does not submit
> any builds updates for "branched":
>
> https://bodhi.fedoraproject.org/updates/?user=packit
>
> Having updates in Fedora 37 (stable branch) and Rawhide (development
> branch), and in some cases even Fedora 36 (oldstable branch), but
> *not* in the branch for the next release is really bad.
>
> Can we get this fixed please? Errors like these really do make me not
> trust packit with any of my packages.
>
> It would be great if $PACKIT_ADMIN would go through the updates that
> were filed by packit since the F38 branch point and submit missing
> builds and updates? Preferably before the F38 final freeze? ...
>
> 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


OpenPGP_0x7C47D46246790496.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Changes to Bugzilla API key requirements

[Ben Cotton]

Based on feedback, the 30-day auto-revocation is being dropped[1]. The
12-month key lifetime will still apply.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=2174291

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Packit service not submitting builds or updates for branched / F38

[Fabio Valentini]

On Wed, Mar 1, 2023 at 5:34 PM Matej Focko  wrote:
>
> Hi,
>
> we have already been informed about the issue and fix for the issue is
> ready (will be deployed to production next Tuesday, unless we hit any
> issues in the staging instance)
>
>  https://github.com/packit/packit/pull/1863
>
> This issue has been hit after a change in the Bodhi API that introduced
> a new state for releases that are in a “frozen” state (see the release
> schedule for Fedora 38, we have entered the Beta Freeze on February 20;
> also last F38 Bodhi update from Packit has been created on February 22,
> which is 15 days after branching and 2 days after the Beta Freeze,
> therefore there was no reason to suspect any issues being present).

Sorry about that, I assumed it was the same problem as during the F37
development cycle, and not a new bug :)

> On the other hand, if I didn't know about the merged PR, I wouldn't be
> able to provide you help in any way, since you haven't provided any
> additional details that would allow me to assess your issue
> appropriately (no exceptions have been caught and furthermore I don't
> know what package we are talking about).

I included a link to the updates that have been submitted by packit,
where you can see that for the last 1-2 weeks, F38 updates have been
missing, but I can list them manually, if it helps ...

- linux-system-roles v1.35.1: submitted to F39, F37, F36, but not F38
- osbuild-composer v75: submitted to F39, F37, F36, but not F38
- cockpit-composer v44: submitted to F39, F37, F36, but not F38
- gpxsee v12.1: submitted to F39, F37, F36, but not F38
- osbuild v81: submitted to F37, F36, but not F39 or F38 (?)
- mrack v1.13.3: submitted to F39, F37, F36, EPEL9, EPEL8, but not F38
- osbuild-composer v76: submitted to F39, F37, F36, but not F38

It appears that some packages are more badly affected than others, so
it might have to do with how they configure packit (listing branches
manually or just saying "all fedora branches"?) ..

> You can also file an issue with details (project, trigger, steps to
> reproduce, etc.) at https://github.com/packit/packit-service/issues/new
> if you hit a bug.
> We do not consider this mailing list as a way to submit bug reports as
> it would create too much noise and also spam other people, thanks for
> understanding.

I understand. I did not want to report a bug with packit. I wanted to
point out that there are updates missing from Fedora 38, which will
impact upgrade path from Fedora 37, which is why I thought the devel
list was appropriate.

Whatever the reason, what should be done about the missing updates?
I'll be publishing my "builds + updates missing from Fedora Branched
report" soon anyway, so the packages will show up there either way ...

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

Fedora CoreOS Meeting Minutes 2023-03-01

[Jonathan Lebon]

Minutes: 
https://meetbot.fedoraproject.org/fedora-meeting-1/2023-03-01/fedora_coreos_meeting.2023-03-01-16.30.html
Minutes (text):
https://meetbot.fedoraproject.org/fedora-meeting-1/2023-03-01/fedora_coreos_meeting.2023-03-01-16.30.txt
Log: 
https://meetbot.fedoraproject.org/fedora-meeting-1/2023-03-01/fedora_coreos_meeting.2023-03-01-16.30.log.html


#fedora-meeting-1: fedora_coreos_meeting



Meeting started by jlebon at 16:30:08 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting-1/2023-03-01/fedora_coreos_meeting.2023-03-01-16.30.log.html
.



Meeting summary
---
* roll call  (jlebon, 16:30:12)

* Action items from last meeting  (jlebon, 16:36:20)

* tracker: Fedora 38 changes considerations  (jlebon, 16:36:58)
  * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1357
(jlebon, 16:37:03)
  * we don't ship cups, shouldn't affect us  (dustymabe, 16:39:20)
  * this is specific to Fedora IoT  (dustymabe, 16:39:42)
  * we don't ship python  (dustymabe, 16:39:57)

* rawhide: upgrades fail with new openssh-9.0p1-10.fc38.1  (jlebon,
  16:42:39)
  * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1394
(jlebon, 16:42:43)
  * AGREED: we will go with option 2, where we will rely on an updated
migration service shipped by sshd that works on OSTree-based systems
and give a heads up on coreos-status  (jlebon, 16:58:26)

* F38 Change: Shorter Shutdown Timer  (jlebon, 17:00:02)
  * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1404
(jlebon, 17:00:05)
  * AGREED: we will get the fedora-release MR merged which currently
only affects FCOS for now so that we can include it and verify it
(jlebon, 17:08:41)

* evaluate inclusion of GPU firmware  (jlebon, 17:11:02)
  * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1350
(jlebon, 17:11:05)
  * AGREED: we will keep the firmwares for now as users currently rely
on them. we may in the future remove them as part of a larger
space-savings initiative.  (jlebon, 17:21:49)

* Open Floor  (jlebon, 17:22:06)
  * LINK: https://hackmd.io/T3F32w5aSiywOd_ekB8HKw?view   (dustymabe,
17:26:00)

Meeting ended at 17:32:44 UTC.




Action Items






Action Items, by person
---
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* dustymabe (92)
* jlebon (70)
* zodbot (16)
* bgilbert (10)
* pboy (4)
* walters (2)
* ravanelli (1)
* c4rt0 (1)
* gursewak (1)
* spresti[m] (1)
* spresti (0)




Generated by `MeetBot`_ 0.4

.. _`MeetBot`: https://fedoraproject.org/wiki/Zodbot#Meeting_Functions
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: SPDX Statistics - University of Constantinople edition

[Miroslav Suchý]

Dne 01. 03. 23 v 4:13 Omair Majid napsal(a):

One package that I care about (`dotnet7.0`) was added to Fedora after
the Let's-move-Fedora-to-SPDX decision was finalized. So the package has
been using SPDX identifiers since the original package review.

How do I make sure such a package is recognized as converted-to-SPDX?


Hmm, there will be more such packages. I should somehow automate this. Give me 
few days please. I will try to do something.

Miroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: SPDX Statistics - University of Constantinople edition

[Maxwell G]

On Wed Mar 1, 2023 at 20:57 +0100, Miroslav Suchý wrote:
> Dne 01. 03. 23 v 4:13 Omair Majid napsal(a):
> > One package that I care about (`dotnet7.0`) was added to Fedora after
> > the Let's-move-Fedora-to-SPDX decision was finalized. So the package has
> > been using SPDX identifiers since the original package review.
> >
> > How do I make sure such a package is recognized as converted-to-SPDX?
>
> Hmm, there will be more such packages. I should somehow automate this. Give 
> me few days please. I will try to do something.

If you don't want to clone every distgit repository and use the git log,
you can query the rawhide-source repositories and find the date of the
first changelog entry for each package. I don't think you'll be able to
use the repoquery CLI here, but take a look at the reproducer code in
[1] for inspiration on how to use the dnf API for this.

[1] https://github.com/rpm-software-management/dnf5/issues/320

--
Maxwell G (@gotmax23)
Pronouns: He/They
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

Package Tutorial bug - missing BuildRequires gcc

[Kenneth Goldman]

https://docs.fedoraproject.org/en-US/package-maintainers/Packaging_Tutorial_
GNU_Hello/

The tutorial says:

Lines which are not needed (e.g. BuildRequires and Requires) can be
commented out with the hash # for now.

However, I believe that this line is needed.  I'm new so perhaps I'm missing
something.

BuildRequires: gcc

--
Work 1-914-945-2415



smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Package Tutorial bug - missing BuildRequires gcc

[Elliott Sales de Andrade]

On Wed, Mar 1, 2023 at 3:35 PM Kenneth Goldman  wrote:

>
> https://docs.fedoraproject.org/en-US/package-maintainers/Packaging_Tutorial_
> GNU_Hello/
> 
>
> The tutorial says:
>
> Lines which are not needed (e.g. BuildRequires and Requires) can be
> commented out with the hash # for now.
>
> However, I believe that this line is needed.  I'm new so perhaps I'm
> missing
> something.
>
> BuildRequires: gcc
>

This is mentioned in the next step, is it not?
https://docs.fedoraproject.org/en-US/package-maintainers/Packaging_Tutorial_GNU_Hello/#_building_the_package

--
Elliott
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: SPDX Statistics - University of Constantinople edition

[Jason Tibbitts]

> Maxwell G  writes:

> If you don't want to clone every distgit repository and use the git
> log, [...]

Even if you did, there is full copy of the git data tarred up nightly at
https://src.fedoraproject.org/repo/git-seed-latest.tar.xz which would
probably save a big load of time.

 - J<
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Modernize Thread Building Blocks for Fedora 39 (System-Wide Change proposal)

[Zbigniew Jędrzejewski-Szmek]

On Wed, Mar 01, 2023 at 02:36:18PM +0100, Kevin Kofler via devel wrote:
> Zbigniew Jędrzejewski-Szmek wrote:
> > Parallel runtime installation is obviously required.
> > But is it necessary to have parallel installation of devel headers?
> > It might be less work to have conflicting -devel packages and just
> > BuildRequire one or the other.
> 
> Conflicting -devel packages are an annoyance when you want a system set up 
> for local (including non-mock and especially non-RPM) builds.

True. But is this annoyance bigger than updating dependent packages
to load headers from a different location? Apparently many (most?) packages
will need to use the compat headers at least for now, so that cost
would be pretty high.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Modernize Thread Building Blocks for Fedora 39 (System-Wide Change proposal)

[Zbigniew Jędrzejewski-Szmek]

On Tue, Feb 28, 2023 at 11:06:21AM -0800, Thomas Rodgers wrote:
> On Tue, Feb 28, 2023 at 7:46 AM Zbigniew Jędrzejewski-Szmek <
> zbys...@in.waw.pl> wrote:
> 
> > On Thu, Feb 16, 2023 at 01:46:24PM +, Ian McInerney via devel wrote:
> > > On Wed, Feb 15, 2023 at 6:42 PM Ben Cotton  wrote:
> > >
> > > > https://fedoraproject.org/wiki/Changes/F39ModernizeTBB
> > > >
> > > > This document represents a proposed Change. As part of the Changes
> > > > process, proposals are publicly announced in order to receive
> > > > community feedback. This proposal will only be implemented if approved
> > > > by the Fedora Engineering Steering Committee.
> > > >
> > > > == Summary ==
> > > > Fedora is currently shipping version 2020.3 (released July 10, 2020)
> > > > of the Thread Building Blocks library. The current upstream version is
> > > > 2021.8 (released December 22, 2022). The Fedora community has
> > > > expressed [https://bugzilla.redhat.com/show_bug.cgi?id=2036372
> > > > interest] in moving the TBB package to track a more modern version of
> > > > the upstream.
> > > >
> > > > == Owner ==
> > > > * Name: [[User:trodgers| Thomas Rodgers]]
> > > > * Email: trodg...@redhat.com
> > > >
> > > >
> > > > == Detailed Description ==
> > > > Fedora has shipped with version 2020.3 of the Thread Building Blocks
> > > > library since Fedora 33. The
> > > > upstream project made a decision to break backward compatibility after
> > > > that version was released.
> > > > As packages move to match the upstream's changes it becomes more
> > > > difficult to defer updating the
> > > > Fedora packaging for TBB. The situation is further complicated as
> > > > there are currently a majority
> > > > of TBB dependent packages which have not been updated to track a new
> > > > upstream release, as detailed in this
> > > > [https://bugzilla.redhat.com/show_bug.cgi?id=2036372#c1 analysis] on
> > > > the tracking issue.
> > > >
> >
> > Hi,
> >
> > sorry for picking up this thread so late…
> >
> > > > ** A compat package based on the current 2020.3 version of the
> > > > existing TBB package will be created.
> >
> > A reminder: you don't need a new review, a compat package can be
> > created without any fuss [1].
> >
> > [1]
> > https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#_package_review_process
> >
> >
> True, but changing rpms/tbb is a system wide change, yes? And I can't
> really execute that change without
> also having the compat package, which most of the existing TBB dependent
> packages will need to move to, with
> a small subset able to remain on the packaging for a newer oneTBB.

Yes, yes. I think the Change proposal is the right thing to do.
I just wanted to clarify, in case you didn't know or wasn't sure, that
the compat package can be created without review. Just less work.

> The change proposal seemed at the time to be a place to capture all of that.
> 
> > > This proposal aims to provide a way to modernize the TBB packge
> > > > version for Fedora while providing stability for those packages which
> > > > continue to depend on the older TBB library version.
> > > >
> > > > It will be possible to install both devel and runtime versions of both
> > > > TBB packages, however the devel compat package for version 2020.3 will
> > > > require clients to point to a new include path where the legacy
> > > > headers will be found.
> >
> > Parallel runtime installation is obviously required.
> > But is it necessary to have parallel installation of devel headers?
> > It might be less work to have conflicting -devel packages and just
> > BuildRequire one or the other.
> >
> 
> It might not be necessary. I don't expect to start the actual work on this
> for another 3-4 weeks, we have time to work
> through that discussion before committing to it.

Ack.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

packaging tutorial error - /usr/bin/systemd-nspawn mock-chroot debug advice

[Kenneth Goldman]

https://docs.fedoraproject.org/en-US/package-maintainers/Packaging_Tutorial_
GNU_Hello/

~~~

when running that tutorial (Fedora 37, x86), I get this error:

ERROR: Exception(/home/kgold/hello/hello-2.10-1.fc37.src.rpm)
Config(fedora-37-x86_64) 0 minutes 18 seconds
INFO: Results and/or logs in: /home/kgold/hello/results_hello/2.10/1.fc37

~~~

The log has at the end:, but I suspect that the python issue is a reporting
issue, not the actual failure.

RPM build errors:
Child return code was: 1
EXCEPTION: [Error('Command failed: \n # /usr/bin/systemd-nspawn -q -M
d0156a2d35ca46a0ba55a993d05852c1 -D /var/lib/mock/fedora-37-x86_64/root -a
-u mockbuild --capability=cap_ipc_lock
--bind=/tmp/mock-resolv.lphffv1r:/etc/resolv.conf --bind=/dev/btrfs-control
--bind=/dev/mapper/control --bind=/dev/loop-control --bind=/dev/loop0
--bind=/dev/loop1 --bind=/dev/loop2 --bind=/dev/loop3 --bind=/dev/loop4
--bind=/dev/loop5 --bind=/dev/loop6 --bind=/dev/loop7 --bind=/dev/loop8
--bind=/dev/loop9 --bind=/dev/loop10 --bind=/dev/loop11 --console=pipe
--setenv=TERM=vt100 --setenv=SHELL=/bin/bash --setenv=HOME=/builddir
--setenv=HOSTNAME=mock --setenv=PATH=/usr/bin:/bin:/usr/sbin:/sbin
--setenv=PROMPT_COMMAND=printf "\\033]0;\\007"
--setenv=PS1= \\s-\\v\\$  --setenv=LANG=C.UTF-8
--resolv-conf=off bash --login -c /usr/bin/rpmbuild -bb  --target x86_64
--nodeps /builddir/build/SPECS/hello.spec\n', 1)]
Traceback (most recent call last):
  File "/usr/lib/python3.11/site-packages/mockbuild/trace_decorator.py",
line 93, in trace
result = func(*args, **kw)
 ^
  File "/usr/lib/python3.11/site-packages/mockbuild/util.py", line 598, in
do_with_status
raise exception.Error("Command failed: \n # %s\n%s" % (command, output),
child.returncode)
mockbuild.exception.Error: Command failed:

~

When I try /usr/bin/systemd-nspawn directly, I get this.  What directory is
it looking for? /var/lib/mock/fedora-37-x86_64/root exists.  I don't run as
root, right?

mock-chroot: No such file or directory.

--
Work 1-914-945-2415



smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Fedora rawhide compose report: 20230301.n.1 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20230228.n.0
NEW: Fedora-Rawhide-20230301.n.1

= SUMMARY =
Added images:4
Dropped images:  1
Added packages:  3
Dropped packages:0
Upgraded packages:   278
Downgraded packages: 0

Size of added packages:  7.54 MiB
Size of dropped packages:0 B
Size of upgraded packages:   3.17 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   -27.27 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Container_Minimal_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Minimal-Base-Rawhide-20230301.n.1.s390x.tar.xz
Image: Server_KVM qcow2 s390x
Path: Server/s390x/images/Fedora-Server-KVM-Rawhide-20230301.n.1.s390x.qcow2
Image: Silverblue dvd-ostree ppc64le
Path: 
Silverblue/ppc64le/iso/Fedora-Silverblue-ostree-ppc64le-Rawhide-20230301.n.1.iso
Image: Phosh raw-xz aarch64
Path: Spins/aarch64/images/Fedora-Phosh-Rawhide-20230301.n.1.aarch64.raw.xz

= DROPPED IMAGES =
Image: Kinoite dvd-ostree ppc64le
Path: Kinoite/ppc64le/iso/Fedora-Kinoite-ostree-ppc64le-Rawhide-20230228.n.0.iso

= ADDED PACKAGES =
Package: embree3-3.13.5-2.fc39
Summary: Collection of high-performance ray tracing kernels
RPMs:embree3 embree3-devel
Size:6.93 MiB

Package: parlaylib-2.1.5^20230215git137076b-1.fc39
Summary: A toolkit for programming parallel shared memory algorithms
RPMs:parlaylib-devel parlaylib-examples
Size:239.24 KiB

Package: selint-1.4.0-1.fc39
Summary: Static code analysis tool for SELinux policy source files
RPMs:selint
Size:391.00 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  389-ds-base-2.3.2-2.fc39
Old package:  389-ds-base-2.3.2-1.fc38
Summary:  389 Directory Server (base)
RPMs: 389-ds-base 389-ds-base-devel 389-ds-base-libs 389-ds-base-snmp 
cockpit-389-ds python3-lib389
Size: 21.02 MiB
Size change:  239.64 KiB
Changelog:
  * Tue Feb 28 2023 Simon Pichugin  - 2.3.2-2
  - Use systemd-sysusers for dirsrv user and group (#2173834)


Package:  CGAL-5.5.2-2.fc39
Old package:  CGAL-5.5.1-2.fc38
Summary:  Computational Geometry Algorithms Library
RPMs: CGAL-demos-source CGAL-devel CGAL-qt5-devel
Size: 34.37 MiB
Size change:  -15.75 MiB
Changelog:
  * Tue Feb 28 2023 Laurent Rineau  - 5.5.2-2
  - Update to 5.5.2 (#2174148)
  - CGAL-demos-source is now noarch


Package:  CUnit-2.1.3-28.fc39
Old package:  CUnit-2.1.3-27.fc38
Summary:  Unit testing framework for C
RPMs: CUnit CUnit-devel
Size: 596.68 KiB
Size change:  -692 B
Changelog:
  * Wed Mar 01 2023 Gwyn Ciesla  - 2.1.3-28
  - migrated to SPDX license


Package:  PySolFC-2.20.0-1.fc39
Old package:  PySolFC-2.18.0-2.fc38
Summary:  A collection of solitaire card games
RPMs: PySolFC
Size: 36.06 MiB
Size change:  60.84 KiB
Changelog:
  * Tue Feb 28 2023 Shlomi Fish  2.20.0-1
  - Update PySolFC to 2.20.0.


Package:  Thunar-4.18.4-2.fc39
Old package:  Thunar-4.18.3-1.fc38
Summary:  Thunar File Manager
RPMs: Thunar Thunar-devel Thunar-docs
Size: 10.28 MiB
Size change:  -123.77 KiB
Changelog:
  * Wed Mar 01 2023 Mukundan Ragavan  - 4.18.4-1
  - Update to v4.18.4

  * Wed Mar 01 2023 Mukundan Ragavan  - 4.18.4-2
  - upload source tarball


Package:  anaconda-39.3-1.fc39
Old package:  anaconda-39.2-1.fc39
Summary:  Graphical system installer
RPMs: anaconda anaconda-core anaconda-dracut anaconda-gui 
anaconda-install-env-deps anaconda-install-img-deps anaconda-live anaconda-tui 
anaconda-webui anaconda-widgets anaconda-widgets-devel
Size: 19.27 MiB
Size change:  807 B
Changelog:
  * Tue Feb 28 2023 Packit  - 39.3-1
  - Add config for Fedora Designsuite (luya)
  - docs: Update contrib guide for current branching (vslavik)
  - efi: deal with verbose by default output from efibootmgr (marmarek)
  - Update translations from Weblate


Package:  annobin-11.11-1.fc39
Old package:  annobin-11.10-1.fc39
Summary:  Annotate and examine compiled binary files
RPMs: annobin-annocheck annobin-docs annobin-libannocheck 
annobin-plugin-clang annobin-plugin-gcc annobin-plugin-llvm
Size: 4.96 MiB
Size change:  -3.66 KiB
Changelog:
  * Tue Feb 28 2023 Nick Clifton   - 11.11-1
  - GCC Plugin: Do not run if other plugins are active.  (#2162746)


Package:  archlinux-keyring-20230225-1.fc39
Old package:  archlinux-keyring-20230130-1.fc39
Summary:  GPG keys used by Arch distribution to sign packages
RPMs: archlinux-keyring
Size: 1.14 MiB
Size change:  6.60 KiB
Changelog:
  * Tue Feb 28 2023 Frantisek Sumsal  - 20230225-1
  - Version 20230225 (#2172640)


Package:  autogen-5.18.16-15.fc39
Old package:  autogen-5.18.16-14.fc39
Summary:  Automated text file generator
RPMs: autogen autogen-libopts autogen-libopts-devel
Size: 3.02 MiB
Size change:  6.23 KiB
Changelog:
  * Tue Feb 28 2023 Tomas Korbar  - 5.18.16-15
  - Raise

FontAwesome 6.x inches closer

[Jerry James]

The maintainers of the packages I am about to mention are BCCed on this email.

A couple of months ago, I talked about updating the fontawesome-fonts
package to version 6.x.  I want to give an update on where things
stand.  See https://copr.fedorainfracloud.org/coprs/jjames/FontAwesome6/
for builds of affected packages.  All changes have been checked into
my forks of the affected packages (username "jjames").  Here's a quick
rundown of the changes.

New packages:
- fontawesome4-fonts (a near-identical copy of the current
fontawesome-fonts package)
- python-accessible-pygments (needed for new python-pydata-sphinx-theme version)

Packages with significant changes, including version updates to get
upstream changes to the use of FontAwesome fonts:
- fontawesome-fonts (update to version 6.3.0)
- cantata (update to version 2.5.0)
- dogtag-pki
- python-f5-sdk
- python-nbclassic
- python-networkx
- python-pydata-sphinx-theme (update to version 0.13.0)
- python-QtAwesome (update to version 1.2.2)
- python-sphinx_ansible_theme (update to version 0.10.1)
- python-XStatic-Font-Awesome (update to version 6.2.1.1)
- R-fontawesome
- sympa

Packages where the only change is to replace this:
Requires: fontawesome-fonts
with this:
Requires: font(fontawesome)
- freeipa
- ipsilon
- python-acme
- python-streamlink
I did not build these packages in the COPR because the change is so
trivial.  This makes the dependency get version 4.x both before and
after the other changes.

Packages that do not need any changes because they already require
font(fontawesome):
- coq
- libgpuarray
- libsemigroups
- python-BTrees
- python-primecountpy
- python-sphinx_rtd_theme

In addition, texlive is changed by removing these lines from the
texlive-fontawesome subpackage:
# This is a bit of a lie, but I don't want someone who installs
texlive-fontawesome to wonder where their
# system fonts are.
Requires: fontawesome-fonts

I don't see any reason why we should spare people from learning the
difference between system and TeX fonts.  And anyway, there are lots
of other such system/TeX font pairs, and this wasn't done for them.
It wasn't even done for the texlive-fontawesome5 subpackage.

What remains to be done
--
The way the FontAwesome 6.x subpackages are split up seems to be
suboptimal.  First, nothing in Fedora wants just one of
fontawesome-6-brands-font, fontawesome-6-free-fonts, and
fontawesome-6-free-solid-fonts.  Every user wants all 3.  I only split
them up this way because I thought the Font Packaging Guidelines
indicated that must be done.  (See below.)  Now that I'm looking back
through them again, I'm not sure that is true.  I would like to merge
these 3 into a single package if the guidelines permit doing so.

Second, nothing in Fedora wants just one of fontawesome-fonts and
fontawesome-fonts-web.  Every user wants both.  I split them up this
way thinking the split would be helpful.  Now I don't think it is, so
I will probably throw away the fontawesome-fonts package and move its
contents into fontawesome-fonts-web.  Comments welcome.

Should we run this through the Change process?  At first I didn't
think so, because I was dealing with a small number of packages.
However, the more I have looked, the more cases of bundling I have
discovered, so this is turning into a bigger deal.  I'm starting to
lean towards making this a Change.  Opinions?

Finally, very few of the packages mentioned above comply with the Font
Packaging Guidelines, or at least my reading of them.  I have not
attempted to fix them, as that would blow this project up by at least
an order of magnitude.  The current guidelines
(https://docs.fedoraproject.org/en-US/packaging-guidelines/FontsPolicy/)
are, I am sure, a big improvement over the previous iteration.
However, in my opinion, they are not very accessible to people who are
not font experts.  They are long, complex, and (for me, at least)
difficult to understand.  It also doesn't appear that either packagers
or reviewers are, in general, very familiar with them.  We should do
something to make them more widely understood, for some definition of
"something".

I will be away from my Fedora computer for the rest of this week, so I
won't be able to actually do anything until next week.  However, I
should be able to read and respond to email on a mobile device with a
depressingly small screen.  It also tries to force me to top-post and
send HTML email.  Sorry about that in advance if it happens.

Regards,
--
Jerry James
http://www.jamezone.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: 

Re: SPDX Statistics - University of Constantinople edition

[Jerry James]

On Tue, Feb 28, 2023 at 4:33 PM Miro Hrončok  wrote:
> However, in both cases at least I notice the unrelated change in the diff. In
> my worldview, both are chaotic (read: they violate my imaginary commit-purity
> O.C.D. rules), but they are not evil (nothing is "hidden"). In the MIT SPDX
> license case, the "mixed in" change is a no-change, so when looking at the 
> diff
> we don't notice it, hence I called it "evil".
>
> Hope that makes sense. No judgement intended, I know people have different
> expectations and habits when it comes to commits (and dist-git commits in
> particular).

I get your point.  However, I think what I did is clearly chaotic
good.  Chaotic neutral would be releasing a new version of a software
package that contains both security fixes and new features.  Chaotic
evil would be releasing a new version of a software package that
claims to contain both security fixes and new features, but in fact
contains changes that make security worse, and all of the new features
are either broken or break old features. :-)

Have a good week.  Regards,
-- 
Jerry James
http://www.jamezone.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: fedpkg: Failed to get repository name from Git url or pushurl

[Kenneth Goldman]

There's Source, Source0, and sources.  What are the definitions?

The tutorial doesn't have a 'sources' tag.  Is that documented?  What should
it be?

The hello tutorial has the URL to the tarball in Source: but it also says to 
use
wget to download the tarball.

The Source: tag doesn't have a list of files, just a pointer to the tarball.

Maybe I'm way off and the source files should be in a local directory?

When I run the tutorial, it seems to ignore the .spec URLs and uses the local
tarball.  How does it even know what the name is?  Does it default to the
file name of the URL?

How does it know what to build.  Does it default to configure;make
or something similar?

> -Original Message-
> From: Artur Frenszek-Iwicki 
> Sent: Wednesday, February 15, 2023 11:43 AM
> To: devel@lists.fedoraproject.org
> Subject: [EXTERNAL] RE: fedpkg: Failed to get repository name from Git url 
> or
> pushurl
>
> > Should that tutorial work?  Is it perhaps obsolete?
> I'd say the opposite of obsolete - it's been updated to suggest using fedpkg 
> all
> along the way, instead of the old rpmbuild tools. But it looks like it 
> wasn't tested
> enough to make sure everything works.
>
> > My newbie understanding is that fedpkg should get the source from the
> > Source0 location and then follow the build instructions.
> > Is that even close?
> This is a bit complicated. When the package is being built, the list of 
> files is taken
> from the Source: tags in the spec file. However, fedpkg keeps a separate 
> file,
> "sources" (no extension), where it lists files uploaded to the Fedora build 
> cache.
> The justification is that keeping source tarballs in the repository is a bad 
> idea,
> since these files can be really large (1GiB+ for game packages), so they're 
> stored
> in a cache instead, and the repository contains only this "sources" file 
> with
> references to said cache. (That being said, you totally can store source 
> files in
> the repo - this is often done with stuff like non-standard Fedora configs.)
>
> As for the "get the source from the Source0 location" bit - no.
> fedpkg will not download stuff from Source: tags for you, only the files 
> listed in
> the "sources" file.
>
> Since my impression is that you want to start experimenting with RPM 
> packaging
> in general, and not specifically fedpkg - I'll do a bit shameless 
> self-promotion
> and link to an article on RPM packaging that I wrote some time ago:
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__blog.svgames.pl_article_basics-2Dof-2Drpm-
> 2Dpackaging&d=DwIGaQ&c=jf_iaSHvJObTbx-
> siA1ZOg&r=DZCVG43VcL8GTneMZb8k8lEwb-O1GZktFfre1-mlmiA&m=9Zy9a03p-
> GrtnAWrzttvmFX417X-C_WOqiZaQjuiv1_bUC_4VaDdANM4Cv-
> tBucE&s=ASsrhv8V4Ny-ujgsugfcpVLuPxEn578dICLLMx2eCYw&e=
>
> In this article, I show how to build RPM packages using the traditional 
> rpmbuild
> workflow. If you're just starting out with writing specs and such, it should 
> get
> you started enough to make switching to fedpkg later down the road a no-
> brainer.
>
> A.FI.
> ___
> devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an 
> email
> to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__docs.fedoraproject.org_en-2DUS_project_code-2Dof-
> 2Dconduct_&d=DwIGaQ&c=jf_iaSHvJObTbx-
> siA1ZOg&r=DZCVG43VcL8GTneMZb8k8lEwb-O1GZktFfre1-mlmiA&m=9Zy9a03p-
> GrtnAWrzttvmFX417X-C_WOqiZaQjuiv1_bUC_4VaDdANM4Cv-
> tBucE&s=wgOj27qGmhxD4UEHTA9tqeAxCZr1ny0rPQPs7_SL2sQ&e=
> List Guidelines: https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__fedoraproject.org_wiki_Mailing-5Flist-
> 5Fguidelines&d=DwIGaQ&c=jf_iaSHvJObTbx-
> siA1ZOg&r=DZCVG43VcL8GTneMZb8k8lEwb-O1GZktFfre1-mlmiA&m=9Zy9a03p-
> GrtnAWrzttvmFX417X-C_WOqiZaQjuiv1_bUC_4VaDdANM4Cv-
> tBucE&s=cUh77057QE1qCKOAD2SsxFWibxM8aVJOWgvcuUM-1gI&e=
> List Archives: https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__lists.fedoraproject.org_archives_list_devel-
> 40lists.fedoraproject.org&d=DwIGaQ&c=jf_iaSHvJObTbx-
> siA1ZOg&r=DZCVG43VcL8GTneMZb8k8lEwb-O1GZktFfre1-mlmiA&m=9Zy9a03p-
> GrtnAWrzttvmFX417X-C_WOqiZaQjuiv1_bUC_4VaDdANM4Cv-
> tBucE&s=WiPTKb0_GaJvkLzQAdKMxWSDV8qxvKguXGSvM8rqGgs&e=
> Do not reply to spam, report it:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__pagure.io_fedora-
> 2Dinfrastructure_new-5Fissue&d=DwIGaQ&c=jf_iaSHvJObTbx-
> siA1ZOg&r=DZCVG43VcL8GTneMZb8k8lEwb-O1GZktFfre1-mlmiA&m=9Zy9a03p-
> GrtnAWrzttvmFX417X-C_WOqiZaQjuiv1_bUC_4VaDdANM4Cv-
> tBucE&s=FMdlaadJWvp1hsOPTPqy9TFB3w7W_bTTIYBf553Savs&e=


smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives

RE: Package Tutorial bug - missing BuildRequires gcc

[Kenneth Goldman]

Yes, but … if the tutorial has a sample .spec file, I think

it would help the new user if it was 100% complete.

 

From: Elliott Sales de Andrade  
Sent: Wednesday, March 1, 2023 3:38 PM
To: Development discussions related to Fedora 
Subject: [EXTERNAL] Re: Package Tutorial bug - missing BuildRequires gcc

 

On Wed, Mar 1, 2023 at 3: 35 PM Kenneth Goldman  wrote: 
https: //docs. fedoraproject. org/en-US/package-maintainers/Packaging_Tutorial_ 
GNU_Hello/ The tutorial says: Lines which are not needed (e. g. BuildRequires 
and 

ZjQcmQRYFpfptBannerStart




This Message Is From an Untrusted Sender 


You have not previously corresponded with this sender. 

ZjQcmQRYFpfptBannerEnd

 

On Wed, Mar 1, 2023 at 3:35 PM Kenneth Goldman mailto:kgold...@us.ibm.com> > wrote:

https://docs.fedoraproject.org/en-US/package-maintainers/Packaging_Tutorial_ 

 
GNU_Hello/

The tutorial says:

Lines which are not needed (e.g. BuildRequires and Requires) can be
commented out with the hash # for now.

However, I believe that this line is needed.  I'm new so perhaps I'm missing
something.

BuildRequires: gcc

 

This is mentioned in the next step, is it not?

https://docs.fedoraproject.org/en-US/package-maintainers/Packaging_Tutorial_GNU_Hello/#_building_the_package
 

 

 

--

Elliott



smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: packaging tutorial error - /usr/bin/systemd-nspawn mock-chroot debug advice

[Todd Zullinger]

Kenneth Goldman wrote:
> https://docs.fedoraproject.org/en-US/package-maintainers/Packaging_Tutorial_
> GNU_Hello/
> 
> ~~~
> 
> when running that tutorial (Fedora 37, x86), I get this error:
> 
> ERROR: Exception(/home/kgold/hello/hello-2.10-1.fc37.src.rpm)
> Config(fedora-37-x86_64) 0 minutes 18 seconds
> INFO: Results and/or logs in: /home/kgold/hello/results_hello/2.10/1.fc37
> 
> ~~~
> 
> The log has at the end:, but I suspect that the python issue is a reporting
> issue, not the actual failure.
> 
> RPM build errors:
> Child return code was: 1
> EXCEPTION: [Error('Command failed: \n # /usr/bin/systemd-nspawn -q -M
> d0156a2d35ca46a0ba55a993d05852c1 -D /var/lib/mock/fedora-37-x86_64/root -a
> -u mockbuild --capability=cap_ipc_lock
> --bind=/tmp/mock-resolv.lphffv1r:/etc/resolv.conf --bind=/dev/btrfs-control
> --bind=/dev/mapper/control --bind=/dev/loop-control --bind=/dev/loop0
> --bind=/dev/loop1 --bind=/dev/loop2 --bind=/dev/loop3 --bind=/dev/loop4
> --bind=/dev/loop5 --bind=/dev/loop6 --bind=/dev/loop7 --bind=/dev/loop8
> --bind=/dev/loop9 --bind=/dev/loop10 --bind=/dev/loop11 --console=pipe
> --setenv=TERM=vt100 --setenv=SHELL=/bin/bash --setenv=HOME=/builddir
> --setenv=HOSTNAME=mock --setenv=PATH=/usr/bin:/bin:/usr/sbin:/sbin
> --setenv=PROMPT_COMMAND=printf "\\033]0;\\007"
> --setenv=PS1= \\s-\\v\\$  --setenv=LANG=C.UTF-8
> --resolv-conf=off bash --login -c /usr/bin/rpmbuild -bb  --target x86_64
> --nodeps /builddir/build/SPECS/hello.spec\n', 1)]
> Traceback (most recent call last):
>   File "/usr/lib/python3.11/site-packages/mockbuild/trace_decorator.py",
> line 93, in trace
> result = func(*args, **kw)
>  ^
>   File "/usr/lib/python3.11/site-packages/mockbuild/util.py", line 598, in
> do_with_status
> raise exception.Error("Command failed: \n # %s\n%s" % (command, output),
> child.returncode)
> mockbuild.exception.Error: Command failed:
> 
> ~
> 
> When I try /usr/bin/systemd-nspawn directly, I get this.  What directory is
> it looking for? /var/lib/mock/fedora-37-x86_64/root exists.  I don't run as
> root, right?
> 
> mock-chroot: No such file or directory.

If you're running that command directly, it looks like you
need to quote some things.  Particularly:

--setenv=PS1=  \\s-\\v\\$

should be quoted:

--setenv=PS1='  \\s-\\v\\$'

(I don't know offhand if the backslashes still need to be
escaped or not.)

As for the real issue, the mock build log may have more
details above the EXCEPTION.  That's probably worth
exploring before you spend too much time on how to reproduce
the systemd-nspawn command.

-- 
Todd


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Package Tutorial bug - missing BuildRequires gcc

[Jason Tibbitts]

> Kenneth Goldman  writes:

> but … if the tutorial has a sample .spec file, I think it would
> help the new user if it was 100% complete.

I believe that the section "A Complete hello.spec File" at
https://docs.fedoraproject.org/en-US/package-maintainers/Packaging_Tutorial_GNU_Hello/#_a_complete_hello_spec_file
is, as indicated, complete.  It does contain the necessary build
dependency on gcc, as well as the others.  If I'm missing something,
please feel free to enlighten me.

I do see that the license tag should probably have an SPDX identifier
"GPL-3.0-or-later" instead of "GPLv3+" but that's somewhat minor.

 - J<
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Package Tutorial bug - missing BuildRequires gcc

[Vitaly Zaitsev via devel]

On 01/03/2023 21:35, Kenneth Goldman wrote:

However, I believe that this line is needed.  I'm new so perhaps I'm missing
something.

BuildRequires: gcc


See the next step:


Additional build tools are defined by adding BuildRequires: rows to the 
specfile. In Fedora, GCC is the standard compiler, so we need to add a row for 
gcc. GNU Hello also uses make, so a row should be added for it, too. Add these 
lines after Source:


This is part of the educational process.

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.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