Re: [Rawhide] Build system with updated systemd weird message

[Luya Tshimbalanga]

I confirm about the guessing about missing "include " which 
possibly came from the mass build.
After applying the patch, the build was successful. Patch submitted upstream on 
https://developer.blender.org/D17151

Thanks Mamoru!

Luya
___
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: -fno-omit-frame-pointer does not work as advertised

[Florian Weimer]

* Demi Marie Obenour:

> What about the new SFrame unwind info?

It has the same limitation as DWARF: there's no mainline kernel
implementation for profiling or bpftrace.

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

Re: Proposal: dnf should offer to update all of the dependencies of any package installed or updated

[Florian Weimer]

* Gordon Messmer:

> On 2023-01-28 13:03, Zbigniew Jędrzejewski-Szmek wrote:
>>> ...or "(libfoo.so.2()(64bit) with foo-libs >= x.y.z)", where x.y.z is the
>>> version of the package that provides libfoo.so.2 in the build root, which is
>>> an idea that's growing on me.
>> This is indeed a shortcoming in the rpm symbol dependency generation scheme.
>> But there's a problem with the proposed approach: versioning as 
>> major.minor.micro
>> is just a convention, and not all upstream follow it.
>
>
> The version doesn't have to be major.minor.micro, though.  The
> dependency generator only needs to get the version of the package that
> provides the .so, and use that version.  As long as changes within a
> so version are always backward compatible, and the so version is
> bumped when breaking changes are made (which are already constraints
> on the existing system), then the proposed solution is reliable.  It's
> sometimes too strict -- it might require 1.4.3 when 1.4.0 is
> compatible -- but it's reliable.

We already do this for glibc in rawhide, for the symbol version under
development.

# Auto-generating dependencies for glibc development snapshots.
#
# A glibc development snapshot (say version 2.33.9000) may define
# symbols in its under-development symbol version (GLIBC_2.34).  RPM
# automatically derives RPM dependencies such as
# libc.so.6(GLIBC_2.34)(64bit) from that.  While the GLIBC_2.34
# version is under development, these dependencies may be inaccurate
# and could be satisfied by glibc RPM package versions that lack the
# symbols because they were created from an earlier development
# snapshot that had some other GLIBC_2.34 symbols.  Therefore, if the
# latest, under-development ELF symbol version is detected, this
# dependency generator adds an explicit RPM dependencies on the glibc
# packaging version against which an RPM package is built.



This is an example build:

  util-linux-2.38.1-1.fc37
  

(util-linux-core in particular.)

Right now, this isn't used much, but it when it is, it causes issues for
developers who use the rawhide compose in chroots and newer builds leak
into the chroot from the buildroot without a full chroot update.
Manually ELN tagging can cause similar issues, so we no longer embed the
dist tag in the auto-generated versions.

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

Re: updating cmark to 0.30

[Jens Petersen]

Thanks for this feedback.

Not sure what happened :-( but I am rebuilding them now (mkvtoolnix was 
expected).

Cheers, Jens
___
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-01-25

[Dusty Mabe]

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


#fedora-meeting-1: fedora_coreos_meeting



Meeting started by dustymabe at 16:31:56 UTC. The full logs are
available at
https://meetbot.fedoraproject.org/fedora-meeting-1/2023-01-25/fedora_coreos_meeting.2023-01-25-16.31.log.html
.



Meeting summary
---
* roll call  (dustymabe, 16:32:00)

* Action items from last meeting  (dustymabe, 16:36:51)
  * there were no action items from last meeting! 👏  (dustymabe,
16:36:56)

* Fedora CoreOS download page re-design  (dustymabe, 16:37:35)
  * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1387
(dustymabe, 16:37:40)
  * LINK: https://stg.fedoraproject.org/coreos/download   (jlebon,
16:45:16)
  * LINK: https://stg.fedoraproject.org/coreos/   (travier, 16:55:26)
  * LINK: https://hackmd.io/BqKhPwwRRXGUqAtUc07_ig?edit   (dustymabe,
17:02:52)

* Boot partition can easily run out of space on upgrade  (dustymabe,
  17:18:49)
  * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1247
(dustymabe, 17:18:53)
  * LINK:

https://github.com/coreos/fedora-coreos-tracker/issues/1247#issuecomment-1357996167
(dustymabe, 17:19:48)
  * ACTION: jmarrero to discuss option 2. (oportunistically pruning
older deployments if low on space) with his team and get back to us
(dustymabe, 17:24:58)
  * ACTION: dustymabe to verify that booting a compressed kernel on
ppc64le works   (dustymabe, 17:28:48)

* open floor   (dustymabe, 17:29:51)

Meeting ended at 17:32:17 UTC.




Action Items

* jmarrero to discuss option 2. (oportunistically pruning older
  deployments if low on space) with his team and get back to us
* dustymabe to verify that booting a compressed kernel on ppc64le works




Action Items, by person
---
* dustymabe
  * dustymabe to verify that booting a compressed kernel on ppc64le
works
* jmarrero
  * jmarrero to discuss option 2. (oportunistically pruning older
deployments if low on space) with his team and get back to us
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* dustymabe (96)
* bgilbert (46)
* jlebon (40)
* zodbot (19)
* travier (18)
* davdunc (11)
* jmarrero (3)
* aaradhak[m] (2)
* davdunc[m (2)
* ravanelli (1)




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: List of long term FTBFS packages to be retired in February​

[Jens-Ulrik Petersen]

On Mon, Jan 30, 2023 at 4:09 AM Miro Hrončok  wrote:

> On 29. 01. 23 18:15, Jens-Ulrik Petersen wrote:
> > I would like to request exemptions for:
> >
> > llvm11   jistone, petersen,
> sergesanspaille, tstellar
> > llvm12   petersen,
> sergesanspaille,tstellar
> >
> > which are still needed by various packages, the latter also including
> > ghc8.10-compiler.aarch64, ghc9.0-compiler.aarch64,
> ghc9.2-compiler.s390x, and
> > ghc9.4-compiler.s390x
>
> Could you please open a ticket at https://pagure.io/fesco/issues


Sure, I just opened https://pagure.io/fesco/issue/2947


> Do you happen to know why the llvm versions haven't been built/buildable
> since F35?


Various tedious build errors on different archs, which don't look fun to
fix.
If someone has ideas and even better time to help, that would be really
great.

Jens
___
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: 20230129.n.1 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20230128.n.0
NEW: Fedora-Rawhide-20230129.n.1

= SUMMARY =
Added images:1
Dropped images:  0
Added packages:  11
Dropped packages:1
Upgraded packages:   103
Downgraded packages: 0

Size of added packages:  26.49 MiB
Size of dropped packages:22.90 KiB
Size of upgraded packages:   3.80 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   5.16 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Kinoite dvd-ostree x86_64
Path: Kinoite/x86_64/iso/Fedora-Kinoite-ostree-x86_64-Rawhide-20230129.n.1.iso

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: bind9-next-32:9.19.9-1.fc38
Summary: The Berkeley Internet Name Domain (BIND) DNS (Domain Name System) 
server
RPMs:bind9-next bind9-next-chroot bind9-next-devel 
bind9-next-dlz-filesystem bind9-next-dlz-ldap bind9-next-dlz-mysql 
bind9-next-dlz-sqlite3 bind9-next-dnssec-utils bind9-next-doc bind9-next-libs 
bind9-next-license bind9-next-utils
Size:17.92 MiB

Package: fapolicy-analyzer-0.6.8-1.fc38
Summary: File Access Policy Analyzer
RPMs:fapolicy-analyzer
Size:2.04 MiB

Package: libopenshot-audio-0.3.0-2.fc38
Summary: Audio library used by OpenShot
RPMs:libopenshot-audio libopenshot-audio-demo libopenshot-audio-devel
Size:5.55 MiB

Package: python-ffmpeg-python-0.2.0-1.fc38
Summary: Python bindings for FFmpeg - with complex filtering support
RPMs:python3-ffmpeg-python
Size:62.26 KiB

Package: python-ypy-websocket-0.8.2-1.fc38
Summary: WebSocket connector for Ypy
RPMs:python3-ypy-websocket
Size:38.79 KiB

Package: rust-inventory0.2-0.2.3-1.fc38
Summary: Typed distributed plugin registration
RPMs:rust-inventory0.2+default-devel rust-inventory0.2-devel
Size:27.85 KiB

Package: rust-pyo3-build-config0.16-0.16.6-1.fc38
Summary: Build configuration for the PyO3 ecosystem
RPMs:rust-pyo3-build-config0.16+abi3-devel 
rust-pyo3-build-config0.16+abi3-py310-devel 
rust-pyo3-build-config0.16+abi3-py37-devel 
rust-pyo3-build-config0.16+abi3-py38-devel 
rust-pyo3-build-config0.16+abi3-py39-devel 
rust-pyo3-build-config0.16+default-devel 
rust-pyo3-build-config0.16+extension-module-devel 
rust-pyo3-build-config0.16+resolve-config-devel rust-pyo3-build-config0.16-devel
Size:92.07 KiB

Package: rust-pyo3-ffi0.16-0.16.6-1.fc38
Summary: Python-API bindings for the PyO3 ecosystem
RPMs:rust-pyo3-ffi0.16+abi3-devel rust-pyo3-ffi0.16+abi3-py310-devel 
rust-pyo3-ffi0.16+abi3-py37-devel rust-pyo3-ffi0.16+abi3-py38-devel 
rust-pyo3-ffi0.16+abi3-py39-devel rust-pyo3-ffi0.16+default-devel 
rust-pyo3-ffi0.16+extension-module-devel rust-pyo3-ffi0.16-devel
Size:133.46 KiB

Package: rust-pyo3-macros-backend0.16-0.16.6-1.fc38
Summary: Code generation for PyO3 package
RPMs:rust-pyo3-macros-backend0.16+abi3-devel 
rust-pyo3-macros-backend0.16+default-devel 
rust-pyo3-macros-backend0.16+pyproto-devel rust-pyo3-macros-backend0.16-devel
Size:77.57 KiB

Package: rust-pyo3-macros0.16-0.16.6-1.fc38
Summary: Proc macros for PyO3 package
RPMs:rust-pyo3-macros0.16+abi3-devel rust-pyo3-macros0.16+default-devel 
rust-pyo3-macros0.16+multiple-pymethods-devel 
rust-pyo3-macros0.16+pyproto-devel rust-pyo3-macros0.16-devel
Size:45.09 KiB

Package: rust-pyo3_0.16-0.16.6-1.fc38
Summary: Bindings to Python interpreter
RPMs:rust-pyo3_0.16+abi3-devel rust-pyo3_0.16+abi3-py310-devel 
rust-pyo3_0.16+abi3-py37-devel rust-pyo3_0.16+abi3-py38-devel 
rust-pyo3_0.16+abi3-py39-devel rust-pyo3_0.16+anyhow-devel 
rust-pyo3_0.16+auto-initialize-devel rust-pyo3_0.16+default-devel 
rust-pyo3_0.16+extension-module-devel rust-pyo3_0.16+eyre-devel 
rust-pyo3_0.16+full-devel rust-pyo3_0.16+hashbrown-devel 
rust-pyo3_0.16+indexmap-devel rust-pyo3_0.16+indoc-devel 
rust-pyo3_0.16+inventory-devel rust-pyo3_0.16+macros-devel 
rust-pyo3_0.16+multiple-pymethods-devel rust-pyo3_0.16+nightly-devel 
rust-pyo3_0.16+num-bigint-devel rust-pyo3_0.16+num-complex-devel 
rust-pyo3_0.16+pyo3-macros-devel rust-pyo3_0.16+pyproto-devel 
rust-pyo3_0.16+serde-devel rust-pyo3_0.16+unindent-devel rust-pyo3_0.16-devel
Size:524.05 KiB


= DROPPED PACKAGES =
Package: rust-iptables-0.5.0-2.fc38
Summary: Rust bindings for iptables
RPMs:rust-iptables+default-devel rust-iptables-devel
Size:22.90 KiB


= UPGRADED PACKAGES =
Package:  AusweisApp2-1.26.2-2.fc38
Old package:  AusweisApp2-1.26.2-1.fc38
Summary:  Online identification with German ID card (Personalausweis)
RPMs: AusweisApp2 AusweisApp2-data AusweisApp2-doc
Size: 20.76 MiB
Size change:  -1.36 KiB
Changelog:
  * Sat Jan 28 2023 Bj??rn Esser  - 1.26.2-2
  - Drop Qt6 version lock, as this is already ensured by symbol versioning


Package:  COPASI-4.38.268-3.fc38
Old package:  COPASI-4.38.268-2.fc38
Summary:  Biochemical network simulator
RPMs: COPASI COPASI-data COPASI-doc COPASI-gui python3-COPASI
Size: 57.87 MiB
Size change:  1.59 MiB

Re: [Rawhide] Build system with updated systemd weird message

[Mamoru TASAKA]

Luya Tshimbalanga wrote on 2023/01/30 5:05:


Thanks for the info. That setup impact some subcommand on both make and ninja 
accordingly, hence the last line:

ninja: build stopped: subcommand failed.

See build.log for details:
https://kojipkgs.fedoraproject.org//work/tasks/79/96810079/build.log




The actual error for the above is:

/builddir/build/BUILD/blender-3.4.1/intern/cycles/util/thread.cpp: In member 
function 'bool ccl::thread::join()':
/builddir/build/BUILD/blender-3.4.1/intern/cycles/util/thread.cpp:50:34: error: 
expected unqualified-id before '&' token
   50 |   catch (const std::system_error &) {
  |  ^
/builddir/build/BUILD/blender-3.4.1/intern/cycles/util/thread.cpp:50:33: error: 
expected ')' before '&' token
   50 |   catch (const std::system_error &) {
  | ~   ^~
  | )
/builddir/build/BUILD/blender-3.4.1/intern/cycles/util/thread.cpp:50:34: error: 
expected '{' before '&' token
   50 |   catch (const std::system_error &) {
  |  ^
/builddir/build/BUILD/blender-3.4.1/intern/cycles/util/thread.cpp:50:35: error: 
expected primary-expression before ')' token
   50 |   catch (const std::system_error &) {
  |   ^

I guess intern/cycles/util/thread.cpp needs "include " .

Regards,
Mamoru
___
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

Looking for co-maintainer on EPEL Blender

[Luya Tshimbalanga]

Hello team,

As some EPEL users wish to get Blender on that repository, we are 
looking for a co-maintainer for that branch.


The starting point will be f36 spec[1] file with minimal dependencies 
possible [2] for future increments using Blender 3.3 LTS as reference.



Thanks for the help

References:

-

[1] https://src.fedoraproject.org/rpms/blender/tree/f36

[2] 
https://developer.blender.org/diffusion/B/browse/master/build_files/cmake/config/blender_lite.cmake


--
Luya Tshimbalanga
Fedora Design Team
Fedora Design Suite maintainer
___
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: List of long term FTBFS packages to be retired in February​

[Miro Hrončok]

On 29. 01. 23 18:15, Jens-Ulrik Petersen wrote:
On Tue, Jan 24, 2023 at 10:56 PM Miro Hrončok > wrote:


If you see a package that should be exempted from the process,
please let me know and we can work together to get a FESCo approval for 
that.


I would like to request exemptions for:

llvm11                                           jistone, petersen,
sergesanspaille, tstellar
llvm12                                           petersen,
sergesanspaille,tstellar


which are still needed by various packages, the latter also including 
ghc8.10-compiler.aarch64, ghc9.0-compiler.aarch64, ghc9.2-compiler.s390x, and 
ghc9.4-compiler.s390x


Could you please open a ticket at https://pagure.io/fesco/issues

Do you happen to know why the llvm versions haven't been built/buildable since 
F35?

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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: Orphaning lizardfs

[Jonathan Dieter]

That's wonderful news!  I've moved roles since adding it to Fedora and
no longer use it in my day job, so I'm more than happy to let you have
it!

Thanks,

Jonathan

On Sat, 2023-01-28 at 21:25 -0500, JT wrote:
> I can pick this package up if you're stepping back.  The lizards devs
> are planning on a new release sometime this year, but there's still a
> few things they're trying to finish up first before releasing v3.13.
> Last I heard they wanted it to be out before summer.
> JT
> 
> On January 28, 2023 10:14:14 AM Jonathan Dieter 
> wrote:
> 
> > I've just orphaned lizardfs.  Lizardfs is a clustered network
> > filesystem that has very efficient small file / metadata
> > performance,
> > but hasn't seen any upstream point releases since the end of 2017
> > and
> > now FTBFS in the latest mass rebuild.
> > 
> > Jonathan
> > ___
> > 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.fedorapro
> > ject.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: [Rawhide] Build system with updated systemd weird message

[Luya Tshimbalanga]

On 2023-01-29 07:24, Zbigniew Jędrzejewski-Szmek wrote:

On Sun, Jan 29, 2023 at 01:50:21AM -0800, Luya Tshimbalanga wrote:

Hello team,

When building a package i.e. Blender as an exampleon Rawhide repository, the
following message displayed:

DEBUG util.py:445:  /proc/ is not mounted, but required for successful 
operation of systemd-tmpfiles. Please mount /proc/. Alternatively, consider 
using the --root= or --image= switches.
DEBUG util.py:445:  ⚠️ /proc/ is not mounted. This is not a supported mode of 
operation. Please fix
DEBUG util.py:445:  your invocation environment to mount /proc/ and /sys/ 
properly. Proceeding anyway.
DEBUG util.py:445:  Your mileage may vary.
DEBUG util.py:445:  ⚠️ /proc/ is not mounted. This is not a supported mode of 
operation. Please fix
DEBUG util.py:445:  your invocation environment to mount /proc/ and /sys/ 
properly. Proceeding anyway.
DEBUG util.py:445:  Your mileage may vary.
DEBUG util.py:445:  /usr/lib/sysusers.d/basic.conf:9: Conflict with earlier 
configuration for user 'root', ignoring line.


It seems like a bug related to the new systemd 253rc which can lead to
failure. Here is the link of root.log:

https://kojipkgs.fedoraproject.org//work/tasks/79/96810079/root.log

And the affected build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=96810014

The issue as in the message. It seems that some commands are called in
a partial chroot where /proc is not mounted. procfs is an "api filesystem" that 
is
effectively part of the linux userspace api and is not optional. For example,
/proc/self/fd/ for a program to get information about its own file descriptors.
Thus, this is a problem with how the caller has set up the chroot.

Thanks for the info. That setup impact some subcommand on both make and 
ninja accordingly, hence the last line:


ninja: build stopped: subcommand failed.

See build.log for details:
https://kojipkgs.fedoraproject.org//work/tasks/79/96810079/build.log

--
Luya Tshimbalanga
Fedora Design Team
Fedora Design Suite maintainer
___
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

datamash long term FTBFS - how to apply for maintainership before it's retired

[Georg Sauthoff]

Hello,

Datamash was mentioned in the last long term FTBFS announcement mail.

I know how to fix the datamash build [1], however, its maintainer is
currently inactive. [2]

I think I could manage to maintain just another Fedora package (my fas
handle is: gsauthof) - so, what is the best way to request
maintainership of the datamash package?

The announcement stated that it's going to be retired 'around
2023-02-08'.

So I'm not 100 % sure if that retirement is instant or if it's going to
be orphaned first, as part of that retirement process.

Should I just wait for datamash being orphaned and then take it over via
some button on the package's src.fedoraproject.org project page?

Or is it better do apply for maintainer somehow now to avoid the orphaned stage?


Best regards,
Georg

[1]: https://bugzilla.redhat.com/show_bug.cgi?id=2056736#c10
[2]: cf. ftbfs bug: https://bugzilla.redhat.com/show_bug.cgi?id=2045298

-- 
"Don't let two mirrors 'see' each other, this causes problems."
(Allen H. Blum III, Duke Nukem 3D, Sector Tags Reference Guide,
 12. Tips from the Levelord, 1996)
___
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: List of long term FTBFS packages to be retired in February​

[Jens-Ulrik Petersen]

On Tue, Jan 24, 2023 at 10:56 PM Miro Hrončok  wrote:

> If you see a package that should be exempted from the process,
> please let me know and we can work together to get a FESCo approval for
> that.


I would like to request exemptions for:

llvm11   jistone, petersen,
> sergesanspaille, tstellar
> llvm12   petersen, sergesanspaille,
> tstellar
>

which are still needed by various packages, the latter also including
ghc8.10-compiler.aarch64, ghc9.0-compiler.aarch64, ghc9.2-compiler.s390x,
and ghc9.4-compiler.s390x

Jens
___
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 - Pavel edition

[Richard Fontana]

On Sun, Jan 29, 2023 at 11:41 AM Miroslav Suchý  wrote:
>
> Tip: do you want to audit licenses in your tarball? Unpack the tarball and 
> try:
>
>   dnf install askalono-cli
>
>   askalono crawl /path/to/directory

Regarding askalono: I had not heard of it prior to getting involved in
this whole Fedora initiative around the Callaway->SPDX migration and
the revamped legal documentation. Since then I've used it quite a bit,
mostly for some non-Fedora-related work.

askalono is a easy-to-use tool which is good to reach for in some
situations, but one should be aware of its limitations and
primitiveness. It can't recognize or understand:
* license notices/license texts that are comments in source files (it
specifically looks only for files that are named LICENSE or COPYING or
some obvious variant on those)
* license notices/license texts in README files
* license files that contain multiple license texts (or it will only
recognize the first of them)
* nonstandard/archaic/legacy licenses (which covers most of the
licenses being reviewed in issues in fedora-license-data)

I've found it useful for quick analysis of packages coming out of
ecosystems featuring projects known to have (1) highly standardized
approaches to layout of license information, (2) generally simple
license makeup, and (3) cultural preferences for a highly limited set
of licenses (for example, Rust crates that don't bundle legacy C code,
Golang modules, Node.js npm packages). For things that don't have such
simple characteristics (such as a lot of relatively old, historically
complex Fedora packages) it is probably not going to be too useful for
its "crawl" functionality. And for the task of trying to identify
previously-overlooked or abstracted-away licenses in Fedora packages
it is basically not useful at all.

So: a good tool to have in the toolbox, but its limitations should be
understood, and I don't think it can really be recommended as an audit
tool by itself, given its limitations, even for the kinds of packages
it is relatively useful for.

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

SPDX Statistics - Pavel edition

[Miroslav Suchý]

Two weeks ago we had:


* 23030 spec files in Fedora

* 29390 license tags in all spec files

* 22766 tags have not been converted to SPDX yet

* 8986 tags can be trivially converted using `license-fedora2spdx`



Today we have:

* 23036 spec files in Fedora

* 29407 license tags in all spec files

* 22611 tags have not been converted to SPDX yet

* 8885 tags can be trivially converted using `license-fedora2spdx`

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

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

New version of fedora-license-data has been released.

Legal docs and especially

https://docs.fedoraproject.org/en-US/legal/allowed-licenses/

has been updated too.

I updated the progress in this spreadsheet:

https://docs.google.com/spreadsheets/d/1QVMEzXWML-6_Mrlln02axFAaRKCQ8zE807rpCjus-8s/edit?usp=sharing

You converted 155 license tags in 16 days.

New projection when we will be finished is 2024-08-14. Pure linear 
approximation.

Tip: do you want to audit licenses in your tarball? Unpack the tarball and try:

  dnf install askalono-cli

askalono crawl /path/to/directory


Why Pavel edition? Because yesterday we had and presidential election in Czechia and Petr Pavel is our new president 
https://en.wikipedia.org/wiki/Petr_Pavel


Do you hesitate how to proceed with the migration? Please follow

https://docs.fedoraproject.org/en-US/legal/update-existing-packages/

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: systemd-resolved package overwrite /etc/resolv.conf again

[Zbigniew Jędrzejewski-Szmek]

On Sat, Jan 21, 2023 at 09:36:26AM -0800, Adam Williamson wrote:
> On Sat, 2023-01-21 at 10:06 -0600, Michael Catanzaro wrote:
> > This is only supposed to happen if (a) upgrading from systemd < 
> > 246.1-1, which you're not doing, or (b) installing systemd for the 
> > first time, which you're not doing. Must be a bug in the package 
> > scriptlets.
> 
> I think you're looking at the Rawhide version of the spec, Michael, not
> the F36 one. In the Rawhide spec, the block in %posttrans is set to run
> only on initial installation:
> 
> https://src.fedoraproject.org/rpms/systemd/blob/rawhide/f/systemd.spec#_949
> 
> but on the f36 branch, it isn't:
> 
> https://src.fedoraproject.org/rpms/systemd/blob/f36/f/systemd.spec#_946
> 
> so, I suppose backporting that change -
> 4047e4fb7bb76f2578989e98de276e9ceb4e94b9 and then
> bab6dfc23a915a4daee2dc6b215df8171a66f2a5 - to F36 would probably help
> Casper's case. I don't know if there's any competing reason *not* to do
> it.

I didn't backport it because it's all so fragile. I was hoping that
we can just leave F36 untouched. But if you think it's better, I'll pull
those two patches into the next update.

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: [Rawhide] Build system with updated systemd weird message

[Zbigniew Jędrzejewski-Szmek]

On Sun, Jan 29, 2023 at 01:50:21AM -0800, Luya Tshimbalanga wrote:
> Hello team,
> 
> When building a package i.e. Blender as an exampleon Rawhide repository, the
> following message displayed:
> 
> DEBUG util.py:445:  /proc/ is not mounted, but required for successful 
> operation of systemd-tmpfiles. Please mount /proc/. Alternatively, consider 
> using the --root= or --image= switches.
> DEBUG util.py:445:  ⚠️ /proc/ is not mounted. This is not a supported mode of 
> operation. Please fix
> DEBUG util.py:445:  your invocation environment to mount /proc/ and /sys/ 
> properly. Proceeding anyway.
> DEBUG util.py:445:  Your mileage may vary.
> DEBUG util.py:445:  ⚠️ /proc/ is not mounted. This is not a supported mode of 
> operation. Please fix
> DEBUG util.py:445:  your invocation environment to mount /proc/ and /sys/ 
> properly. Proceeding anyway.
> DEBUG util.py:445:  Your mileage may vary.
> DEBUG util.py:445:  /usr/lib/sysusers.d/basic.conf:9: Conflict with earlier 
> configuration for user 'root', ignoring line.
> 
> 
> It seems like a bug related to the new systemd 253rc which can lead to
> failure. Here is the link of root.log:
> 
> https://kojipkgs.fedoraproject.org//work/tasks/79/96810079/root.log
> 
> And the affected build:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=96810014

The issue as in the message. It seems that some commands are called in
a partial chroot where /proc is not mounted. procfs is an "api filesystem" that 
is
effectively part of the linux userspace api and is not optional. For example,
/proc/self/fd/ for a program to get information about its own file descriptors.
Thus, this is a problem with how the caller has set up the chroot.

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

Review request: perl-String-License, perl-Test2-Tools-Command

[Sandro Mani]

Hi

licensecheck-3.3.8 once again grew some new dependencies, reviews here:

perl-Test2-Tools-Command - 
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2165335
perl-String-License - 
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2165336


Happy to review in exchange.

Thanks
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: Non-responsive maintainer check for rmattes / update libQGLViewer to 2.9.1

[Mamoru TASAKA]

Susi Lehtola wrote on 2023/01/29 17:13:

Hi,

does anyone know how to contact Rich Mattes? They maintain libQGLViewer, which
was last updated five years ago

* Sun Aug 12 2018 Rich Mattes  - 2.6.4-1
- Update to release 2.6.4, with upstream fix for qreal on armv7 (rhbz#1556028)
- Remove upstream patch and update library names

and there has been no other activity in the package other than automated 
rebuilds.


At least this is some activity from rmattes on koji on 2022/Dec:
https://koji.fedoraproject.org/koji/userinfo?userID=1186



I urgently need an update of libQGLViewer to a more modern version, since the
old version of libQGLViewer is causing IQmol builds to fail, and IQmol is at
threat of being removed in a week or so from now due to long-time FTBFS issues
originally caused by the update of OpenBabel to version 3.

https://bugzilla.redhat.com/show_bug.cgi?id=2164341

I have since done the work to update the package to version 2.6.4 myself, and
filed a pull request against libQGLViewer to update it to the newest release in

https://src.fedoraproject.org/rpms/libQGLViewer/pull-request/1


Maybe slightly off-topic, but:

This PR removes qt4 version libQGLViewer, which skyviewer depends on:

$ dnf -q repoquery --repo=koji-38  --qf 
'%{name}-%{epoch}:%{version}-%{release}\t%{sourcerpm}' --whatrequires 
libQGLViewer
libQGLViewer-devel-0:2.6.4-10.fc38  libQGLViewer-2.6.4-10.fc38.src.rpm
libQGLViewer-doc-0:2.6.4-10.fc38libQGLViewer-2.6.4-10.fc38.src.rpm
skyviewer-0:1.0.1-29.fc38   skyviewer-1.0.1-29.fc38.src.rpm

, and qt5 version does soname bump, which octomap depends on:

$ dnf -q repoquery --repo=koji-38  --qf 
'%{name}-%{epoch}:%{version}-%{release}\t%{sourcerpm}' --whatrequires 
libQGLViewer-qt5
libQGLViewer-qt5-devel-0:2.6.4-10.fc38  libQGLViewer-2.6.4-10.fc38.src.rpm
octomap-octovis-0:1.9.7-5.fc38  octomap-1.9.7-5.fc38.src.rpm
$ dnf -q repoquery --repo=koji-38  --qf 
'%{name}-%{epoch}:%{version}-%{release}\t%{sourcerpm}' --requires 
octomap-octovis | grep QGL
libQGLViewer-qt5.so.2.6.4()(64bit)

This means this PR is going to break all packages which currently depends on 
libQGLViewer
unless properly handled.

So my question is that what is the exact reason that IQmol
"need an update of libQGLViewer to a more modern version, since the old version 
of
libQGLViewer is causing IQmol builds to fail".
If this means that IQmol needs new API of libQGLViewer, this may mean that
other packages which libQGLViewer depends on are going to FTBFS, then
we may have to be more careful for updating libQGLViewer.


In addition to these two, I have also tried to reach Rich through
libqglviewer-ow...@fedoraproject.org, however, I have not received any replies
so far. (Granted, this all happened starting on Wednesday, but February is right
around the corner!)


Currently this is -maintain...@fedoraproject.org , not -owner.
https://fedoraproject.org/wiki/EmailAliases


I would like to get commit rights to libQGLViewer so I can update the package. I
do have provenpackager rights, but this would go over their purview..

The only packages that appear to depend on libQGLViewer, in addition to IQmol,
appear to be skyviewer and octomap, whose maintainers have been copied into this
messages.

Susi


Mamoru
___
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 review needed - swap welcome

[Mattia Verga via devel]

Hi,

to update Celestia package I need to add a new dependency celestia-data.
The package review [1] was stuck waiting for a new license to be
approved by SPDX upstream, which is happened recently [2].
The new license ("JPL-image") has not yet been added to the Fedora
accepted list [3], but I think it will be as soon as upstream closes the
ticket (after all, upstream agreed to the license because Fedora already
approved it years ago - the licensed content is already available in the
outdated celestia package currently in repos).

Therefore I'd like to ask for a review and I'd be happy to provide
another one in exchange.

BTW, I have a few other low priority requests waiting in the queue [4]
[5] [6], if anyone needs some more swaps.

Thanks
Mattia

[1] https://bugzilla.redhat.com/show_bug.cgi?id=2150240
[2] https://github.com/spdx/license-list-XML/issues/1734
[3] https://gitlab.com/fedora/legal/fedora-license-data/-/issues/107

[4] https://bugzilla.redhat.com/show_bug.cgi?id=2156932
[5] https://bugzilla.redhat.com/show_bug.cgi?id=2156937
[6] https://bugzilla.redhat.com/show_bug.cgi?id=2163430

___
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: Orphaning lizardfs

[Artur Frenszek-Iwicki]

Fixing the FTBFS is rather trivial (yet another victim of GCC13 header 
shenanigans)
and I've already created a patch for this, but I didn't want to pick up the 
package since
upstream activity since rather low. If you're saying that the project isn't 
dead yet,
then I'd be willing to pick this up either as main maintainer or as 
co-maintainer.

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://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

[Rawhide] Build system with updated systemd weird message

[Luya Tshimbalanga]

Hello team,

When building a package i.e. Blender as an exampleon Rawhide repository, 
the following message displayed:


DEBUG util.py:445:  /proc/ is not mounted, but required for successful 
operation of systemd-tmpfiles. Please mount /proc/. Alternatively, consider 
using the --root= or --image= switches.
DEBUG util.py:445:  ⚠️ /proc/ is not mounted. This is not a supported mode of 
operation. Please fix
DEBUG util.py:445:  your invocation environment to mount /proc/ and /sys/ 
properly. Proceeding anyway.
DEBUG util.py:445:  Your mileage may vary.
DEBUG util.py:445:  ⚠️ /proc/ is not mounted. This is not a supported mode of 
operation. Please fix
DEBUG util.py:445:  your invocation environment to mount /proc/ and /sys/ 
properly. Proceeding anyway.
DEBUG util.py:445:  Your mileage may vary.
DEBUG util.py:445:  /usr/lib/sysusers.d/basic.conf:9: Conflict with earlier 
configuration for user 'root', ignoring line.


It seems like a bug related to the new systemd 253rc which can lead to 
failure. Here is the link of root.log:


https://kojipkgs.fedoraproject.org//work/tasks/79/96810079/root.log

And the affected build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=96810014


Can someone investigate? Thanks.

--
Luya Tshimbalanga
Fedora Design Team
Fedora Design Suite maintainer
___
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: dnf should offer to update all of the dependencies of any package installed or updated

[Gordon Messmer]

On 2023-01-29 00:00, Zbigniew Jędrzejewski-Szmek wrote:

The version doesn't have to be major.minor.micro, though.  The dependency
generator only needs to get the version of the package that provides the
.so, and use that version.  As long as changes within a so version are
always backward compatible, and the so version is bumped when breaking
changes are made (which are already constraints on the existing system),
then the proposed solution is reliable.  It's sometimes too strict -- it
might require 1.4.3 when 1.4.0 is compatible -- but it's reliable.

OK, it sounds like something worth doing.



OK.  For discussion, I opened 
https://github.com/rpm-software-management/rpm/pull/2372


I tested it by rebuilding libsoup3 in a mock build root that included a 
version of rpm with (basically) that patch, and then installing the 
resulting package.  It looks like it functions correctly, so this seems 
like a sensible place to start.


$ podman run --rm -it fedora:37
[root@ae5c590fa03a /]# rpm -qp --requires 
/var/tmp/libsoup3-3.2.2-3.fc37.x86_64.rpm

(libnghttp2.so.14()(64bit) with libnghttp2 >= 1.51.0)
...
[root@ae5c590fa03a /]# dnf install 
/var/tmp/libsoup3-3.2.2-3.fc37.x86_64.rpm

Dependencies resolved.
===
 Package Architecture Version 
Repository  Size

===
Installing:
 libsoup3 x86_64 3.2.2-3.fc37 
@commandline   373 k

Upgrading:
 libnghttp2 x86_64 1.51.0-1.fc37 
updates 74 k

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

Non-responsive maintainer check for rmattes / update libQGLViewer to 2.9.1

[Susi Lehtola]

Hi,


does anyone know how to contact Rich Mattes? They maintain libQGLViewer, which
was last updated five years ago

* Sun Aug 12 2018 Rich Mattes  - 2.6.4-1
- Update to release 2.6.4, with upstream fix for qreal on armv7 (rhbz#1556028)
- Remove upstream patch and update library names

and there has been no other activity in the package other than automated 
rebuilds.

I urgently need an update of libQGLViewer to a more modern version, since the
old version of libQGLViewer is causing IQmol builds to fail, and IQmol is at
threat of being removed in a week or so from now due to long-time FTBFS issues
originally caused by the update of OpenBabel to version 3.

https://bugzilla.redhat.com/show_bug.cgi?id=2164341

I have since done the work to update the package to version 2.6.4 myself, and
filed a pull request against libQGLViewer to update it to the newest release in

https://src.fedoraproject.org/rpms/libQGLViewer/pull-request/1

In addition to these two, I have also tried to reach Rich through
libqglviewer-ow...@fedoraproject.org, however, I have not received any replies
so far. (Granted, this all happened starting on Wednesday, but February is right
around the corner!)

I would like to get commit rights to libQGLViewer so I can update the package. I
do have provenpackager rights, but this would go over their purview..

The only packages that appear to depend on libQGLViewer, in addition to IQmol,
appear to be skyviewer and octomap, whose maintainers have been copied into this
messages.

Susi
-- 
Susi Lehtola
Fedora Project Contributor
jussileht...@fedoraproject.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: updating cmark to 0.30

[Miro Hrončok]

On 17. 01. 23 6:55, Jens-Ulrik Petersen wrote:

Currently we have an old version of cmark in Fedora: version 0.29.

I had several requests to update it to the latest release 0.30.2 from 2021.
https://bugzilla.redhat.com/show_bug.cgi?id=1974335 



I created a copr repo for testing: 
https://copr.fedorainfracloud.org/coprs/petersen/cmark/ 



 From my repoquerying I think the following fedora packages depend on cmark:

evolution-3.47.1-1.fc38.src.rpm
gnome-builder-43.4-3.fc38.src.rpm
mkvtoolnix-73.0.0-1.fc38.src.rpm
neochat-22.11-2.fc38.src.rpm
nheko-0.11.0-1.fc38.src.rpm
perl-Clownfish-CFC-0.6.3-17.fc37.src.rpm
perl-CommonMark-0.29-13.fc37.src.rpm
So I plan to go ahead with this rebase and rebuilding these packages after the 
mass rebuild if that's okay. We can consider whether to backport to F37 and 
possibly F36 if needed afterwards.


Hello Jens. It looks this update has landed in rawhide, but packages still 
depend on the old version:


$ repoquery -q --repo=rawhide --whatrequires 'libcmark.so.0.29.0()(64bit)'
evolution-0:3.47.1-3.fc38.x86_64
gnome-builder-0:43.4-7.fc38.x86_64
mkvtoolnix-gui-0:73.0.0-1.fc38.x86_64
neochat-0:22.11-4.fc38.x86_64
nheko-0:0.11.1-3.fc38.x86_64
perl-Clownfish-CFC-0:0.6.3-19.fc38.x86_64
perl-CommonMark-0:0.29-15.fc38.x86_64

$ repoquery -q --repo=rawhide --provides cmark-lib
...
libcmark.so.0.30.3
libcmark.so.0.30.3()(64bit)


Looking at https://bodhi.fedoraproject.org/updates/FEDORA-2023-e5f26e9386
it seems the packages were actually in the update, so problem might be 
elsewhere?

There seem to have been side tag rebuilds, but in the root log, they have:

cmark-devel   x86_64  0.29.0-8.fc38build   23 k


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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: dnf should offer to update all of the dependencies of any package installed or updated

[Zbigniew Jędrzejewski-Szmek]

On Sat, Jan 28, 2023 at 06:12:11PM -0800, Gordon Messmer wrote:
> On 2023-01-28 13:03, Zbigniew Jędrzejewski-Szmek wrote:
> > > ...or "(libfoo.so.2()(64bit) with foo-libs >= x.y.z)", where x.y.z is the
> > > version of the package that provides libfoo.so.2 in the build root, which 
> > > is
> > > an idea that's growing on me.
> > This is indeed a shortcoming in the rpm symbol dependency generation scheme.
> > But there's a problem with the proposed approach: versioning as 
> > major.minor.micro
> > is just a convention, and not all upstream follow it.
> 
> 
> The version doesn't have to be major.minor.micro, though.  The dependency
> generator only needs to get the version of the package that provides the
> .so, and use that version.  As long as changes within a so version are
> always backward compatible, and the so version is bumped when breaking
> changes are made (which are already constraints on the existing system),
> then the proposed solution is reliable.  It's sometimes too strict -- it
> might require 1.4.3 when 1.4.0 is compatible -- but it's reliable.

OK, it sounds like something worth doing.

(One issue that I expect that there'll be some libraries which do "strange
things" and may need different handling, so some opt-out mechanism would need
to be provided.)

> > There is an alternative scheme that is supported by our rpm tooling already:
> > symbol versioning.
> 
> 
> Yes, the enhanced rpm dependencies would only be necessary for libraries
> that don't provide versioned symbols (which seems to be the vast majority of
> them).
> 
> I don't think convincing hundreds or thousands of developers to add symbol
> versioning to their libraries is a viable solution. I'd love to see it
> happen, but rpm/dnf should be more reliable in the meantime.

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