Follow up for bash-completion pkgconfig file packaging change

[Mamoru TASAKA]

Hello, all:

After investigating the recent Fedora-Security-Live livespin compose failure
on F-41, it is found that this is caused because:

- Recently on F-41, bash-completion packaging changed so that pkgconfig file
  is moved into -devel subpackage: (bash-completion-2.11-15.fc41)
  
https://src.fedoraproject.org/rpms/bash-completion/c/d1f5dc48c0440cc68efdd519b78fccca416cad94?branch=rawhide

- A package (lynis) installing bash-completion file into the directory
  $(pkg-config --variable=completionsdir bash-completion), had "BuildRequires: 
bash-completion",
  but did not have "BuildRequires: pkgconfig(bash-completion)".
  
- So after the above bash-completion side packaging change, the above command line was

  expanded to the empty string, so the completion file was installed into the 
wrong directory,
  which caused conflict with filesystem rpm.


So on F-41(rawhide), the packages

* trying to install bash-completion file using $(pkg-config 
--variable=completionsdir bash-completion)
* which have "BuildRequires: bash-completion", but do NOT have "BuildRequires: 
pkgconfig(bash-completion)"

may be installing completion file into wrong directories after rebuild.
(At least, I tried rebuilding cowsay and actually it installs completion file 
into the wrong
 directory).

The possible packages which may need fixing are:

 1  cowsay/rawhide/cowsay.spec  %global compdir %(pkg-config 
--variable=completionsdir bash-completion)
 2  creds/rawhide/creds.spec%global bashcompdir %(pkg-config 
--variable=completionsdir bash-completion)
 3  datamash/rawhide/datamash.spec  pkg-config --variable=completionsdir 
bash-completion ||
 4  dracut/rawhide/dracut.spec  
--bashcompletiondir=$(pkg-config --variable=completionsdir bash-completion) \
 5  eg/rawhide/eg.spec  bashcompdir=$(pkg-config 
--variable=completionsdir bash-completion || :)
 6  fedpkg/rawhide/fedpkg.spec  %define compdir %(pkg-config 
--variable=completionsdir bash-completion)
 7  git-annex/rawhide/git-annex.spec
bash_completion_dir=%{buildroot}$(pkg-config --variable=completionsdir 
bash-completion)
 8  gromacs/rawhide/gromacs.spec%define compdir %(pkg-config 
--variable=completionsdir bash-completion)
 9  kim-api/rawhide/kim-api.spec%global b_compdir %(pkg-config 
--variable=completionsdir bash-completion)
10  mpc/rawhide/mpc.spec%global compdir %(pkg-config 
--variable=completionsdir bash-completion)
11  mt-st/rawhide/mt-st.specCOMPLETIONDIR=%{buildroot}$(pkg-config 
--variable=completionsdir bash-completion)
12  pybugz/rawhide/pybugz.spec  %global bash_cmpl_dir %(pkg-config 
--variable=completionsdir bash-completion)
13  python-django/rawhide/python-django.spec
bashcompdir=$(pkg-config --variable=completionsdir bash-completion)
14  python-vitrageclient/rawhide/python-vitrageclient.spec  
bashcompdir=$(pkg-config --variable=completionsdir bash-completion)
15  tig/rawhide/tig.spec%global bash_completion_dir %(pkg-config 
--variable=completionsdir bash-completion || echo /etc/bash_completion.d)/

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

Re: help needed with failing eccodes build for f40

[Mamoru TASAKA]

Petr Pisar wrote on 2024/02/29 18:35:

V Thu, Feb 29, 2024 at 10:02:32AM +0100, Jos de Kloe napsal(a):

Dear all,

while doing koji builds for the latest eccodes version 2.34.1 I ran in to an
issue that is puzzling to me, and I have no idea to solve this.

The build runs just fine for f38, f39 and f41/rawhide, but for f40 I get a
number of g++ errors like this:

  error: ‘opj_destroy_decompress’ was not declared in this scope; did you
mean ‘opj_end_decompress’?
   209 | opj_destroy_decompress(dinfo);
   | ^~
   | opj_end_decompress

see: https://koji.fedoraproject.org/koji/buildinfo?buildID=2412368

Does anyone have an idea what is happening here and how this can be solved?


The function is supposed to be declared in openjpeg.h header file which is
supposed to be packaged in openjpeg2-devel.

Checking root.log files of eccodes builds, F40 used
openjpeg2-devel-2.5.1-1.fc40, while F41 used openjpeg2-devel-2.5.2-1.fc41.

It's quite possible that opj_destroy_decompress was added in 2.5.2 and does
not exist in 2.5.1. If it is so, you should specify the minimal version among
BuildRequires: openjpeg2-devel >= 2.5.2.

Why is openjpeg2-devel-2.5.2-1.fc40 not available in F40 build root? It is
because that build has not been submitted to Bodhi and has not passed into
updates repository.

I recommend creating a side tag for F40, tag openjpeg2-devel-2.5.2-1.fc40
there, build eccodes there, and both builds push into a single Bodhi update.

-- Petr



openjpeg2 header file is broken in 2.5.1:
https://github.com/uclouvain/openjpeg/issues/1514
due to this commit:
https://github.com/uclouvain/openjpeg/commit/c4b3a91ede1d0301f7f5f50287c0bda35aa7ca7e

and fixed in 2.5.2:
https://github.com/uclouvain/openjpeg/pull/1515
https://github.com/uclouvain/openjpeg/commit/e521a5094be3be4f8657a2253958b0d752616479

So F39 and F38 buildroot openjpeg2  (2.5.0) is okay, F41 buildroot openjpeg2 
(2.5.2) is
also okay, really current F40 buildroot openjpeg2 (2.5.1) is broken.

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

Re: List of long term FTBFS packages to be retired in February

[Mamoru TASAKA]

Miro Hrončok wrote on 2024/02/04 2:17:

Dear maintainers.

Based on the current fail to build from source policy, the following packages
should be retired from Fedora 40 approximately one week before branching.

5 weekly reminders are required, hence the retirement will happen
approximately in 4 weeks, i.e. around 2024-02-28.
Since this is unfortunately after the branching,
packages will be retired on rawhide and f40.

I apologize for starting this process a bit later than required again.
Unfortunately, I had other work obligations.
Volunteers to take over this are always welcome.

Policy: 
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/

The packages in rawhide were not successfully built at least since Fedora 37.

This report is based on dist tags.

Packages collected via:
https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb

If you see a package that was built, please let me know.
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.

If you see a package that can be rebuilt, please do so.

     Package  (co)maintainers

telepathy-gabble    aperezbios

The following packages require above mentioned packages:

Depending on: telepathy-gabble (31)
 sugar (maintained by: aperezbios, chimosky)
     sugar-0.120-6.fc40.noarch requires telepathy-gabble

 sugar-abacus (maintained by: chimosky)
     sugar-abacus-61-9.fc39.noarch requires sugar


 Too many dependencies for telepathy-gabble, not all listed here



Fixed telepathy-gabble .
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

Re: Failure on fedora default backgrounds

[Mamoru TASAKA]

Luya Tshimbalanga wrote on 2024/02/02 10:25:

Hello team,

It appears a change within %{_kde4_datadir} macro caused failures on Rawhide 
affecting default Fedora backgrounds starting from 21.
Could someone from KDE SIG address that issue? Thanks.


Here is an extract of failure[1]  on for f35-backgrounds built on Rawhide:



RPM build errors:
error: File must begin with "/": %{_kde4_datadir}/wallpapers/F35/
     File must begin with "/": %{_kde4_datadir}/wallpapers/F35/
Child return code was: 1
'''

Reference:
[1]https://koji.fedoraproject.org/koji/taskinfo?taskID=112257075



I am not KDE sig member, but the above failure is most likely due to
the following change:

https://src.fedoraproject.org/rpms/kde-filesystem/c/3cc17949d085bef5476638f2fbade0f19dbcea32

/usr/lib/rpm/macros.d/macros.kde4 (which provides %{_kde4_datadir} macro 
definition)
was moved from kde-filesystem.rpm to kde4-filesystem.rpm .

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

Re: poppler soname bump in Rawhide soon

[Mamoru TASAKA]

Sandro wrote on 2024/01/30 22:02:

On 30-01-2024 12:15, Michael J Gruber wrote:

Marek Kasik venit, vidit, dixit 2024-01-30 12:02:34:

Hi,

I plan to rebase poppler to 24.02.0 once it is released. It will be
probably released this week and I would like to get it to rawhide before
the branching together with rebuilds of dependent packages.

I'll prepare the build in a side tag and will message relevant
maintainers to rebuild their packages there.

The packages which will need rebuilds:
   calligra
   gambas3
   gdal
   gdcm
   inkscape
   kf5-kitinerary
   libreoffice
   pdf2djvu
   scribus


That list is surprisingly short. For example, poppler-glib requires a
specific poppler version, and via poppler-glib-devel that affects more
packages (zathura-pdf-poppler comes to my mind).


How about:

$ fedrq wrsrc -s poppler -F name
LabPlot
OpenSceneGraph
R-pdftools
abiword
apvlv
atril
booksorg
bookworm
boomaga
calibre
calligra
cantor
claws-mail
deepin-api
deepin-file-manager
diff-pdf
diffoscope
diffpdf
docparser
efl
engauge-digitizer
evince
extractpdfmark
fbida
gambas3
gdal
gdcm
geeqie
gimagereader
gimp
gle
gnome-commander
graphviz
gscan2pdf
gsequencer
gummi
inkscape
kbibtex
kf5-kfilemetadata
kf5-kitinerary
kf6-kfilemetadata
kile
kitinerary
krita
ktikz
latex2html
libcupsfilters
libppd
libreoffice
mat2
okular
pdf2djvu
pdf2svg
pdfgrep
pdfpc
pg_auto_failover
photoqt
poppler-sharp
python-img2pdf
python-paperwork-backend
python-pdf2image
python-pikepdf
python3-poppler-qt5
qcomicbook
qpdfview
qt5-qtwebengine
qt6-qtwebengine
rubygem-activestorage
rubygem-asciidoctor-pdf
rubygem-poppler
scribus
setzer
tellico
texmaker
texstudio
texworks
tikzit
tracker-miners
tumbler
vfrnav
vips
weston
xournal
xournalpp
xreader
yacreader
zathura-pdf-poppler

-- Sandro



I guess this is explained before:
https://lists.pagure.io/archives/list/devel@lists.fedoraproject.org/message/U6YPJU77TTOH2VNMZP3CQIV5QHH5FXCY/

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

Re: List of long term FTBFS packages to be retired in February

[Mamoru TASAKA]

Miro Hrončok wrote on 2024/01/25 1:38:

Dear maintainers.

Based on the current fail to build from source policy, the following packages
should be retired from Fedora 40 approximately one week before branching.

5 weekly reminders are required, hence the retirement will happen
approximately in 5 weeks, i.e. around 2024-02-28.
Since this is unfortunately after the branching,
packages will be retired on rawhide and f40.

I apologize for starting this process a bit later than required again.
Unfortunately, I had other work obligations.
Volunteers to take over this are always welcome.

Policy: 
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/

The packages in rawhide were not successfully built at least since Fedora 37.

This report is based on dist tags.

Packages collected via:
https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb

If you see a package that was built, please let me know.
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.

If you see a package that can be rebuilt, please do so.

     Package  (co)maintainers




telepathy-gabble aperezbios

Depending on: telepathy-gabble (31)
 sugar (maintained by: aperezbios, chimosky)
     sugar-0.120-5.fc39.noarch requires telepathy-gabble

 sugar-abacus (maintained by: chimosky)
     sugar-abacus-61-9.fc39.noarch requires sugar





 Too many dependencies for telepathy-gabble, not all listed here



PR submitted to rescue SoaS spin:
https://src.fedoraproject.org/rpms/telepathy-gabble/pull-request/2

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

Re: HELP! What's up with OpenVDB?

[Mamoru TASAKA]

Richard Shaw wrote on 2024/01/25 12:43:

So with the tbb[1] update OpenVDB is one of the stragglers having issues
that need to be addressed before I can build OpenImageIO.

Looking at the releng rebuilt attempt it failed on ppc64le. I kicked off
the build again[2] and this time it failed on s390x:
https://kojipkgs.fedoraproject.org//work/tasks/3860/112313860/build.log

Just to check I did a local build for x86_64 and it completed, though I
noted it only seemed to use about 3 cores of my 8 core / 12 thread
processor. It had this on the cmake line:

%cmake_build %limit_build -m 8192

But I haven been unable to decipher its exact purpose since google cannot
find where `%limit_build` is documented.

Thanks,
Richard

[1] https://bugzilla.redhat.com/show_bug.cgi?id=2036372
[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=112313794




See:
https://src.fedoraproject.org/rpms/build-constraints-rpm-macros/blob/rawhide/f/macros.build-constraints

The macro attemps to reduce parallel make jobs when the build needs
more memory than usual.

Your [2] ppc64le build log actually says:

g++: fatal error: Killed signal terminated program cc1plus
compilation terminated.
gmake[2]: *** [openvdb/openvdb/CMakeFiles/openvdb_shared.dir/build.make:625: 
openvdb/openvdb/CMakeFiles/openvdb_shared.dir/instantiations/GridOperators.cc.o]
 Error 1
gmake[2]: *** Deleting file 
'openvdb/openvdb/CMakeFiles/openvdb_shared.dir/instantiations/GridOperators.cc.o'
gmake[2]: Leaving directory 
'/builddir/build/BUILD/openvdb-11.0.0/redhat-linux-build'
gmake[1]: *** [CMakeFiles/Makefile2:261: 
openvdb/openvdb/CMakeFiles/openvdb_shared.dir/all] Error 2
gmake[1]: *** Waiting for unfinished jobs

So perhaps g++ process was killed by OOM.

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

Re: [Fedora-packaging] BuildrootError: could not init mock buildroot ... see root.log ...

[Mamoru TASAKA]

Brad Bell wrote on 2024/01/18 14:00:

I got the Result in the subject above for the following build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=111912575

Looking at the corresponding root.log
https://kojipkgs.fedoraproject.org//work/tasks/2575/111912575/root.log
does not indicate to me what went wrong or how I should proceed ?
--
___


Looking at root.log:

x86_64 (successful)
https://kojipkgs.fedoraproject.org//work/tasks/2577/111912577/root.log

DEBUG util.py:558:  Executing command: ['/bin/mount', '-n', '-o', 
'remount,private,rbind', '--target', 
'/var/lib/mock/f40-build-48240062-5748626-bootstrap/root/var/lib/mock/f40-build-48240062-5748626/root']
 with env {'TERM': 'vt100', 'SHELL': '/bin/sh', 'HOME': '/builddir', 
'HOSTNAME': 'mock', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'LANG': 'C.UTF-8'} 
and shell False
DEBUG util.py:610:  Child return code was: 0
DEBUG file_util.py:18:  ensuring that dir exists: 
/var/lib/mock/f40-build-48240062-5748626/root/installation-homedir
DEBUG file_util.py:21:  created dir: 
/var/lib/mock/f40-build-48240062-5748626/root/installation-homedir
DEBUG package_manager.py:289:  ['/usr/bin/dnf5', '--installroot', 
'/var/lib/mock/f40-build-48240062-5748626/root/', 'group', 'install', 'build', 
'--setopt=deltarpm=False', '--setopt=allow_vendor_change=yes']
DEBUG util.py:636:  child environment: None
DEBUG util.py:553:  Using nspawn with args ['--capability=cap_ipc_lock', 
'--bind=/tmp/mock-resolv.fdt5pbne:/etc/resolv.conf']
DEBUG util.py:558:  Executing command: ['/usr/bin/systemd-nspawn', '-q', '-M', '69286198251d4cbebe3bbba5ac862e76', '-D', 
'/var/lib/mock/f40-build-48240062-5748626-bootstrap/root', '-a', '--capability=cap_ipc_lock', 
'--bind=/tmp/mock-resolv.fdt5pbne:/etc/resolv.conf', '--console=pipe', '--setenv=TERM=vt100', '--setenv=SHELL=/bin/bash', 
'--setenv=HOME=/var/lib/mock/f40-build-48240062-5748626/root/installation-homedir', '--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', 
'--setenv=LC_MESSAGES=C.UTF-8', '--resolv-conf=off', '/usr/bin/dnf5', '--installroot', 
'/var/lib/mock/f40-build-48240062-5748626/root/', 'group', 'install', 'build', '--setopt=deltarpm=False', 
'--setopt=allow_vendor_change=yes', '--setopt=tsflags=nocontexts'] with env {'TERM': 'vt100', 'SHELL': '/bin/bash', 'HOME': 
'/var/lib/mock/f40-build-48240062-5748626/root/installation-homedir', 'HOSTNAME': 'mock', 'PATH': 
'/usr/bin:/bin:/usr/sbin:/sbin', 'PROMPT_COMMAND': 'printf "\\033]0;\\007"', 'PS1': 
' \\s-\\v\\$ ', 'LANG': 'C.UTF-8', 'LC_MESSAGES': 'C.UTF-8', 'SYSTEMD_NSPAWN_TMPFS_TMP': '0', 
'SYSTEMD_SECCOMP': '0'} and shell False
DEBUG util.py:463:  Updating and loading repositories:
DEBUG util.py:463:   build  100% |  97.2 MiB/s 
|  17.6 MiB |  00m00s

i686 (failing)
https://kojipkgs.fedoraproject.org//work/tasks/2575/111912575/root.log

DEBUG util.py:558:  Executing command: ['/bin/mount', '-n', '-o', 
'remount,private,rbind', '--target', 
'/var/lib/mock/f40-build-48240060-5748626-bootstrap/root/var/lib/mock/f40-build-48240060-5748626/root']
 with env {'TERM': 'vt100', 'SHELL': '/bin/sh', 'HOME': '/builddir', 
'HOSTNAME': 'mock', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'LANG': 'C.UTF-8'} 
and shell False
DEBUG util.py:610:  Child return code was: 0
DEBUG file_util.py:18:  ensuring that dir exists: 
/var/lib/mock/f40-build-48240060-5748626/root/installation-homedir
DEBUG file_util.py:21:  created dir: 
/var/lib/mock/f40-build-48240060-5748626/root/installation-homedir
DEBUG package_manager.py:289:  ['/usr/bin/dnf5', '--installroot', 
'/var/lib/mock/f40-build-48240060-5748626/root/', 'group', 'install', 'build', 
'--setopt=deltarpm=False', '--setopt=allow_vendor_change=yes', '--allowerasing'] 
<=
DEBUG util.py:636:  child environment: None
DEBUG util.py:553:  Using nspawn with args ['--capability=cap_ipc_lock', 
'--bind=/tmp/mock-resolv.4fqzpd1k:/etc/resolv.conf']
DEBUG util.py:558:  Executing command: ['/usr/bin/systemd-nspawn', '-q', '-M', '41961b9ee3b140eda2ee2c91559a676a', '-D', 
'/var/lib/mock/f40-build-48240060-5748626-bootstrap/root', '-a', '--capability=cap_ipc_lock', 
'--bind=/tmp/mock-resolv.4fqzpd1k:/etc/resolv.conf', '--console=pipe', '--setenv=TERM=vt100', '--setenv=SHELL=/bin/bash', 
'--setenv=HOME=/var/lib/mock/f40-build-48240060-5748626/root/installation-homedir', '--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', 
'--setenv=LC_MESSAGES=C.UTF-8', '--resolv-conf=off', '/usr/bin/dnf5', '--installroot', 
'/var/lib/mock/f40-build-48240060-5748626/root/', 'group', 'install', 'build', '--setopt=deltarpm=False', 
'--setopt=allow_vendor_change=yes', '--allowerasing', 

Re: Are package-owner mail addresses working?

[Mamoru TASAKA]

Sergio Pascual wrote on 2024/01/01 21:36:

Hello and happy new year.

Are package-owner mail addresses working? I have send mails to several
and they return a 550 error message, for example:

550 5.1.1 : Recipient address
rejected: User unknown in local recipient table

Best, Sergio
--


Currently it is -maintain...@fedoraproject.org :

https://fedoraproject.org/wiki/EmailAliases

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

Re: Proven to be sickened

[Mamoru TASAKA]

Sérgio Basto wrote on 2023/12/02 0:49:

On Fri, 2023-12-01 at 16:26 +0100, Michael J Gruber wrote:

So, due to me following my package (notmuch) upstream and testing
early against upstream's git, reporting and working with upstream, I
noticed a FTBFS and helped fixing it. Nothing urgent since it was
basically just a test failing for the wrong reasons.

Within a few days, upstream releases a patch release. Within hours,
I'm testing (again, since it's basically what was on git already) on
copr and koji, writing a nice commit message, push to rawhide ...

... and get a reject because someone thought that pushing directly
without asking or at least notifying the maintainer would be in
order:

https://src.fedoraproject.org/rpms/notmuch/c/f0d84b417694430874a150293ffdb1fdc35c7b31?branch=rawhide




Why? For a FTBFS due to a test? No bugzilla, no FTI, no security
issue whatsoever?



You may kindly ask to mtasaka why did it ? , and also alert him that
package is well maintain and have a quick response and kindly ask to do
PR instead , he is one provenpackager and I sure that he did that in
hope of improve the package, I'm sure that he will understand.

Best regards,


So to explain, notmuch was FTBFS.
And we are going to rebuild packages which depends on libruby.so.3.2 as
announced as:

https://fedoraproject.org/wiki/Changes/Ruby_3.3

We are testing beforehand whether packages can rebuild against new ruby
beforehand, and trying to fix **just** FTBFS beforehand because if the package
has FTBFS anyway (regardless of whether the reason is related to ruby or
not, such package will have broken deps after mass rebuild).

notmuch is this target.

Regards,
Mamoru






I am sick of this. Really. I am so sick of this way of stomping on
each others' feet.

It's made worse by failing automated notifications, of course. Not
from pagure about the push nor from koji about the build nor from
bodhi about the update.

Dunno whether it's the new fmn or what. That works for *my* actions
with pagure/bodhi/koji but fails to report copr actions to me, and
apparently also actions by others.

Thanks for listening ...

Michael
--

--
___
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: libxml2 2.12.0 (and 2.12.1) in rawhide, with some API breaks

[Mamoru TASAKA]

Frederic Berat wrote on 2023/11/27 22:23:

On Fri, Nov 24, 2023 at 12:07 PM David King  wrote:


The latest released versions of libxml2 have a couple of important
changes in header files that have unintentionally caused some packages
to fail to build without modification, including:

* several functions now accept or return a const xmlError struct
* cyclic dependencies in header files were fixed (by dropping some
includes)

Most failures that have been witnessed so far by davidlt while
rebuilding RISCV packages, and have been related to the xmlError const
change, but xmlsec1 was hit by the include changes:

https://github.com/lsh123/xmlsec/pull/729
https://src.fedoraproject.org/rpms/xmlsec1/pull-request/4

As libxml2 is used rather widely, I expect more changes to come up over
time, so please feel free to ask me for help (amigadave on IRC, or Cc
 on bugs) and I will be happy to submit patches
upstream and do builds; I am a provenpackager, so happy to help.

Thanks to davidlt for spotting the breakages!



Hello,

I made a mass rebuild of the packages that directly depend on libxml2, and
found 115 packages (out of 621) with build failure correlated to the
libxml2 update.
Out of these 115 packages, 102 so far are highly related (i.e. they show
xml related errors in the build logs).

Few notes:
- Since the new version of libxml2 is already in rawhide I made the mass
rebuild on F39 with it instead of a rawhide build. That implies that some
of the packages may already have been fixed but that still gives a rough
idea on potential problems. I threfore started a mass-rebuild on rawhide to
cross-check, but I don't have a report to give yet.
- Out of the 13 packages that seem correlated but don't show obvious errors
directly related to libxml2, there are still some quite suspicious ones,
like cinnamon which fails due to a missing xml file.

When you plan to do such an update, I can only recommend you to do a mass
prebuild [1][2].

Full report can be found attached. I also added a log file listing the
obvious failures.

I hope that helps a bit.

Fred.

[1] https://copr.fedorainfracloud.org/coprs/fberat/mass-prebuild/
[2] https://gitlab.com/fedora/packager-tools/mass-prebuild



Note that looking at build log, I've noticed that 
"-Werror=implicit-function-declaration" is
not in effect there. Actually (as Frederic said) this mass rebuild is on Fedora 
39,
and the above compilation flag change is on Fedora 40:

https://fedoraproject.org/wiki/Changes/PortingToModernC

Actually with libxml2 2.12.0, for example mlt (7.20.0) succees to compile with 
the message:
```
/builddir/build/BUILD/mlt-7.20.0/src/modules/jackrack/jack_rack.c:343:9:
warning: implicit declaration of function `xmlParseFile`; did you mean 
`xmlSaveFile` ? [-Wimplicit-function-declaration]
```

This becomes error on Fedora 40. i.e. There will be more errors than
that you provided.

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

Re: [HEADS UP] Jasper update with .so name update

[Mamoru TASAKA]

Orion Poplawski wrote on 2023/11/28 11:26:

On 11/27/23 13:31, Adam Williamson wrote:

On Tue, 2023-11-21 at 10:55 +0100, Josef Řídký wrote:

Hi,

there is a new jasper version (4.1.0) that will be available in Fedora 40+.
As this version is bumping it's .so name, the rebuild of the dependent
package will be necessary.

There is a side tag created for safe rebuild of those packages
(f40-build-side-77302) with a new jasper version available.

I would like to ask maintainers of affected packages to rebuild their
packages using this tag, so I will be able to push the update to f40 once
all is done.

List of affected packages is:
- eccodes-devel
- g2clib-devel
- grib_api-devel


Somehow your list is far too short:

[adamw@xps13a tmp]$ sudo dnf repoquery --whatrequires
"libjasper.so.6()(64bit)"
DevIL-0:1.7.8-42.fc39.x86_64
DevIL-ILUT-0:1.7.8-42.fc39.x86_64
GraphicsMagick-0:1.3.40-3.fc39.x86_64
LibRaw-0:0.21.1-6.fc40.x86_64
OpenSceneGraph-libs-0:3.6.5-19.fc40.x86_64
dcraw-0:9.28.0-20.fc39.x86_64
digikam-libs-0:8.1.0-3.fc39.x86_64
eccodes-0:2.32.1-1.fc40.x86_64
gegl04-0:0.4.46-1.fc40.x86_64
grib_api-0:1.27.0-19.fc39.x86_64
jasper-0:3.0.6-4.fc39.x86_64
jasper-devel-0:3.0.6-4.fc39.x86_64
jasper-utils-0:3.0.6-4.fc39.x86_64
kdelibs-6:4.14.38-40.fc40.x86_64
kdelibs3-0:3.5.10-123.fc40.x86_64
libicns-0:0.8.1-27.fc39.x86_64
ncl-0:6.6.2-38.fc40.x86_64
netpbm-progs-0:11.02.00-2.fc39.x86_64
qt5-qtimageformats-0:5.15.11-1.fc40.x86_64
qt6-qtimageformats-0:6.6.0-1.fc40.x86_64
wgrib2-0:3.1.3-1.fc40.x86_64

the update failed gating because of qt5-qtimageformats, but all the
others also ought to be rebuilt onto the side tag before this is
pushed.


I've built most of these and working on the rest - but I think we're bumping 
into a qt6 update at the same time.  Pinging maintainers here.


qt6-qtimageformats rebuilt for f40-build-side-78512 .
(new jasper-4.1.0-1.fc40 already in buildroot)



Other issues:
kdelibs/kdelibs3 are FTBFS



I've fixed these FTBFS (actually was libxml2-2.12.0 issue).

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

Re: libxml2 2.12.0 (and 2.12.1) in rawhide, with some API breaks

[Mamoru TASAKA]

Frederic Berat wrote on 2023/11/27 22:23:

On Fri, Nov 24, 2023 at 12:07 PM David King  wrote:


The latest released versions of libxml2 have a couple of important
changes in header files that have unintentionally caused some packages
to fail to build without modification, including:

* several functions now accept or return a const xmlError struct
* cyclic dependencies in header files were fixed (by dropping some
includes)

Most failures that have been witnessed so far by davidlt while
rebuilding RISCV packages, and have been related to the xmlError const
change, but xmlsec1 was hit by the include changes:

https://github.com/lsh123/xmlsec/pull/729
https://src.fedoraproject.org/rpms/xmlsec1/pull-request/4

As libxml2 is used rather widely, I expect more changes to come up over
time, so please feel free to ask me for help (amigadave on IRC, or Cc
  on bugs) and I will be happy to submit patches
upstream and do builds; I am a provenpackager, so happy to help.

Thanks to davidlt for spotting the breakages!


Hello,

I made a mass rebuild of the packages that directly depend on libxml2, and
found 115 packages (out of 621) with build failure correlated to the
libxml2 update.
Out of these 115 packages, 102 so far are highly related (i.e. they show
xml related errors in the build logs).

Few notes:
- Since the new version of libxml2 is already in rawhide I made the mass
rebuild on F39 with it instead of a rawhide build. That implies that some
of the packages may already have been fixed but that still gives a rough
idea on potential problems. I threfore started a mass-rebuild on rawhide to
cross-check, but I don't have a report to give yet.
- Out of the 13 packages that seem correlated but don't show obvious errors
directly related to libxml2, there are still some quite suspicious ones,
like cinnamon which fails due to a missing xml file.

When you plan to do such an update, I can only recommend you to do a mass
prebuild [1][2].

Full report can be found attached. I also added a log file listing the
obvious failures.

I hope that helps a bit.

Fred.

[1]https://copr.fedorainfracloud.org/coprs/fberat/mass-prebuild/
[2]https://gitlab.com/fedora/packager-tools/mass-prebuild


 lxappearance-obconf:
 Source: (distgit) fedora
 NVR: lxappearance-obconf-0.2.3^20230918git63c5dc1b-1.fc39
 Commit/branch: 7219a560762102a88b77331424ef536d7183581a



 rubygem-nokogiri:
 Source: (distgit) fedora
 NVR: rubygem-nokogiri-1.15.4-1.fc39
 Commit/branch: 8820fad4b3e368c60c5cd255ce92b244133446ba



 yaz:
 Source: (distgit) fedora
 NVR: yaz-5.34.0-4.fc39
 Commit/branch: cff7180eae835591dc5d64930e75082a593243a1


I've fixed these 3 packages. (koschei was complaining.)

Note that we are planning to do mass rebuild for upcoming ruby3.3:

https://fedoraproject.org/wiki/Changes/Ruby_3.3 ,

but some packages which need rebuilding for ruby3.3 are listed in
this "fails to build with libxml2 2.12.0" list (i.e. rebuild of some
packages will fail due to the reason unrelated to ruby).
So when we do mass rebuild for ruby3.3 on side-tag and that side-tag
gets merged, some dependency breakage is perhaps going to happen.

I appreciated it if libxml2 2.12.0 related build failure will be addressed
by the corresponding maintainers.

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

rawhide buildroot seems weird state, Child return code was: 255

[Mamoru TASAKA]

Hello, all:

Looks like currently rawhide buildroot seems weird state, mainly
on ppc64le, but sometimes also on other arches:

e.g.
https://koji.fedoraproject.org/koji/taskinfo?taskID=105650426
https://koji.fedoraproject.org/koji/taskinfo?taskID=105642860
https://koji.fedoraproject.org/koji/taskinfo?taskID=105653203
https://koji.fedoraproject.org/koji/taskinfo?taskID=105626199

task result says:
mock exited with status 30;

root.log says something like:

DEBUG util.py:539:  Executing command: ['/usr/bin/systemd-nspawn', '-q', '-M', 'f0f2c583a3dc478b9a6fa5bc92ca54b5', '-D', 
'/var/lib/mock/f40-build-45240825-5393892-bootstrap/root', '-a', '--capability=cap_ipc_lock', 
'--bind=/tmp/mock-resolv.4xyubvar:/etc/resolv.conf', '--console=pipe', '--setenv=TERM=vt100', '--setenv=SHELL=/bin/bash', 
'--setenv=HOME=/var/lib/mock/f40-build-45240825-5393892/root/installation-homedir', '--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', 
'--setenv=LC_MESSAGES=C.UTF-8', '--resolv-conf=off', '/usr/bin/dnf-3', 'builddep', '--installroot', 
'/var/lib/mock/f40-build-45240825-5393892/root/', '--setopt=install_weak_deps=0', '--disableplugin=local', 
'--disableplugin=spacewalk', '--disableplugin=versionlock', 
'/var/lib/mock/f40-build-45240825-5393892/root//builddir/build/SRPMS/powerdevil-5.27.7-3.fc40.src.rpm', 
'--setopt=tsflags=nocontexts'] with env {'TERM': 'vt100', 'SHELL': '/bin/bash', 'HOME': 
'/var/lib/mock/f40-build-45240825-5393892/root/installation-homedir', 'HOSTNAME': 'mock', 'PATH': 
'/usr/bin:/bin:/usr/sbin:/sbin', 'PROMPT_COMMAND': 'printf "\\033]0;\\007"', 'PS1': 
' \\s-\\v\\$ ', 'LANG': 'C.UTF-8', 'LC_MESSAGES': 'C.UTF-8', 'SYSTEMD_NSPAWN_TMPFS_TMP': '0', 
'SYSTEMD_SECCOMP': '0'} and shell False

Then:

DEBUG util.py:444:  Running transaction check
DEBUG util.py:444:  Transaction check succeeded.
DEBUG util.py:444:  Running transaction test
DEBUG util.py:444:  Transaction test succeeded.
DEBUG util.py:444:  Running transaction
DEBUG util.py:595:  Child return code was: 255

This does not look like BuildRequires dependency resolution failure, but some
other "generic" issue.

Is this phenomenon being tracked on?

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

Re: List of long term FTBFS packages to be retired this week

[Mamoru TASAKA]

Dominik 'Rathann' Mierzejewski wrote on 2023/08/01 0:19:

On Monday, 31 July 2023 at 12:13, Miro Hrončok wrote:

Dear maintainers.

Based on the current fail to build from source policy, the following packages
should be retired from Fedora 39 approximately one week before branching.

5 weekly reminders are required, hence the retirement will happen
this week.

Policy: 
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/

The packages in rawhide were not successfully built at least since Fedora 36.

This report is based on dist tags.

Packages collected via:
https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb

If you see a package that was built, please let me know.
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.


Could you not retire binaryen and cp2k? I thought I would have time to get
to them, but haven't so far. I'm planning to tackle them over Flock.



These 2 pkgs (binaryen, cp2k) won't be retired right now. Although these 2 
FTBFS on F-39,
they have F38 successful builds.

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

Re: List of long term FTBFS packages to be retired in August

[Mamoru TASAKA]

Miro Hrončok wrote on 2023/07/25 21:24:

Dear maintainers.

Based on the current fail to build from source policy, the following packages
should be retired from Fedora 39 approximately one week before branching.

5 weekly reminders are required, hence the retirement will happen
approximately in 2 weeks, i.e. around 2023-08-01.

Policy: 
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/

The packages in rawhide were not successfully built at least since Fedora 36.

This report is based on dist tags.

Packages collected via:
https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb

If you see a package that was built, please let me know.
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.

If you see a package that can be rebuilt, please do so.

     Package   (co)maintainers

nom-tam-fits  gil, lupinix, zbyszek
telepathy-qt  jgrulich, jreznik, kde-sig, rdieter


Rescued these 2 packages (fixed FTBFS).

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

Re: RFC: Roadmap for DNF5 in Fedora 39 / invoking the Contingency Mechanism

[Mamoru TASAKA]

DJ Delorie wrote on 2023/07/14 9:13:

Fabio Valentini  writes:

in Fedora 39 - whether the switch still looks doable for this release,
or whether it should be reverted for F39 and postponed to F40.


I spent most of yesterday repairing a rawhide VM that had a bad upgrade,
resulting in dnf segfaulting and making the machine difficult to fix.
Had to build a second rawhide VM as a baseline to guide a manual
download and install of affected RPMs.  Very not happy, and I would
advise more testing before making it official.

#0  __strlen_sse2 () at ../sysdeps/x86_64/multiarch/strlen-sse2.S:142
Downloading 0.00 MB source file 
/usr/src/debug/glibc-2.37.9000-16.fc39.x86_64/string/../sysdeps/x86_64/multiarch/strlen-sse2.S
142 movdqu  (%rax), %xmm4
(gdb) where
#0  __strlen_sse2 () at ../sysdeps/x86_64/multiarch/strlen-sse2.S:142
#1  0x7fc9d36614e8 in __printf_buffer (buf=buf@entry=0x7ffe8ca81350, 
format=0x7fc9c5160293 "%s: %s: %s\n", ap=0x7ffe8ca81460, mode_flags=2) at 
/usr/src/debug/glibc-2.37.9000-16.fc39.x86_64/stdio-common/vfprintf-process-arg.c:435
#2  0x7fc9d3682106 in __vsnprintf_internal (string=string@entry=0x0, 
maxlen=maxlen@entry=0, format=format@entry=0x7fc9c5160293 "%s: %s: %s\n", 
args=args@entry=0x7ffe8ca81460, mode_flags=mode_flags@entry=2) at vsnprintf.c:96
#3  0x7fc9d3724922 in ___vsnprintf_chk (s=s@entry=0x0, maxlen=maxlen@entry=0, 
flag=flag@entry=2, slen=slen@entry=18446744073709551615, 
format=format@entry=0x7fc9c5160293 "%s: %s: %s\n", ap=ap@entry=0x7ffe8ca81460) 
at vsnprintf_chk.c:34
#4  0x7fc9c50d66ae in vsnprintf (__ap=0x7ffe8ca81460, __fmt=0x7fc9c5160293 "%s: 
%s: %s\n", __n=0, __s=0x0) at /usr/include/bits/stdio2.h:68
#5  rpmlog (code=4, fmt=0x7fc9c5160293 "%s: %s: %s\n") at 
/usr/src/debug/rpm-4.18.0-11.fc39.x86_64/rpmio/rpmlog.c:446
#6  0x7fc9c4f811b1 in renderLogMsg (iErrCode=283, zFormat=, 
ap=ap@entry=0x7ffe8ca816a0) at 
/usr/src/debug/sqlite-3.42.0-1.fc39.x86_64/sqlite3.c:31531
#7  0x7fc9c4f81294 in sqlite3_log (iErrCode=, 
zFormat=) at /usr/src/debug/sqlite-3.42.0-1.fc39.x86_64/sqlite3.c:31542




Just note that sqlite was downgraded from sqlite-3.42.0-1.fc39 to 
sqlite-3.41.2-3.fc39 on 2023/Jun/23
due to this issue (without bumping epoch).
https://koji.fedoraproject.org/koji/buildinfo?buildID=2219084

(I have not tried dnf5 myself yet as currently I am using Fedora 38.)

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

Re: [rawhide] ICU upgrade to 73.2

[Mamoru TASAKA]

Frantisek Zatloukal wrote on 2023/07/12 17:18:

On Wed, Jul 12, 2023 at 8:36 AM Mamoru TASAKA 
wrote:


I am not the maintainer of brltty, but just adding "BR: gcc" makes
brltty compile on all arches (against f39):
https://koji.fedoraproject.org/koji/taskinfo?taskID=103255038

I am not sure to what side-tag I should build brltty for now...
(ocaml rebuild first, or ICU rebuild first)



Mhm, I can add BR: gcc there, but I'd love to know the reason it wasn't
there in the first place/why other architectures don't need that. Thanks
for finding that out!


Because "BR: ocaml" pulls in gcc (ocaml explicitly has Requires: gcc),
which is excluded on i686 just now due to ocaml being no longer supporting
i686 on f39.



I'll go ahead and merge the icu side as soon as gating tests allow, this
can be solved via dist-git push separately/pulled into the ocaml rebuild if
Richard would want.



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

Re: [rawhide] ICU upgrade to 73.2

[Mamoru TASAKA]

Frantisek Zatloukal wrote on 2023/07/12 7:35:

On Tue, Jul 11, 2023 at 11:06 PM Richard W.M. Jones 
wrote:


Yes I think it's better if you could proceed with brltty.

Note I pushed a commit earlier today which excludes %{ix86} from the
OCaml subpackage.  In OCaml 5 / Fedora 39 we are going to drop support
for this architecture entirely.


- build bumped icu in your side-tag too, so brlapi rebuilt there
would be built both against new icu and new ocaml?


I'm not sure whether or not this is necessary, but in any case don't
worry as I will sort it out when doing the OCaml rebuild.

Rich.



FYI, it seems brltty is failing anyway on i686, with:
configure: error: C compiler cannot create executables

( https://koji.fedoraproject.org/koji/taskinfo?taskID=103241186 )

Adding limb to CC.



I am not the maintainer of brltty, but just adding "BR: gcc" makes
brltty compile on all arches (against f39):
https://koji.fedoraproject.org/koji/taskinfo?taskID=103255038

I am not sure to what side-tag I should build brltty for now...
(ocaml rebuild first, or ICU rebuild first)

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

Re: Fedora rawhide compose report: 20230706.n.0 changes

[Mamoru TASAKA]

Fedora Rawhide Report wrote on 2023/07/06 20:45:

OLD: Fedora-Rawhide-20230705.n.0
NEW: Fedora-Rawhide-20230706.n.0

= SUMMARY =
Added images:0
Dropped images:  25
Added packages:  17
Dropped packages:2
Upgraded packages:   3465
Downgraded packages: 0

Size of added packages:  1.22 MiB
Size of dropped packages:424.71 KiB
Size of upgraded packages:   21.15 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Comp_Neuro live x86_64
Path: Labs/x86_64/iso/Fedora-Comp_Neuro-Live-x86_64-Rawhide-20230705.n.0.iso
Image: KDE live aarch64
Path: Spins/aarch64/iso/Fedora-KDE-Live-aarch64-Rawhide-20230705.n.0.iso
Image: LXQt raw-xz aarch64
Path: Spins/aarch64/images/Fedora-LXQt-Rawhide-20230705.n.0.aarch64.raw.xz
Image: Onyx dvd-ostree x86_64
Path: Onyx/x86_64/iso/Fedora-Onyx-ostree-x86_64-Rawhide-20230705.n.0.iso
Image: Kinoite dvd-ostree x86_64
Path: Kinoite/x86_64/iso/Fedora-Kinoite-ostree-x86_64-Rawhide-20230705.n.0.iso
Image: Design_suite live x86_64
Path: Labs/x86_64/iso/Fedora-Design_suite-Live-x86_64-Rawhide-20230705.n.0.iso
Image: Security live x86_64
Path: Labs/x86_64/iso/Fedora-Security-Live-x86_64-Rawhide-20230705.n.0.iso
Image: Workstation live aarch64
Path: 
Workstation/aarch64/iso/Fedora-Workstation-Live-aarch64-Rawhide-20230705.n.0.iso
Image: SoaS live x86_64
Path: Spins/x86_64/iso/Fedora-SoaS-Live-x86_64-Rawhide-20230705.n.0.iso
Image: Python_Classroom live x86_64
Path: 
Labs/x86_64/iso/Fedora-Python-Classroom-Live-x86_64-Rawhide-20230705.n.0.iso
Image: Python_Classroom vagrant-libvirt x86_64
Path: 
Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-Rawhide-20230705.n.0.x86_64.vagrant-libvirt.box
Image: SoaS raw-xz aarch64
Path: Spins/aarch64/images/Fedora-SoaS-Rawhide-20230705.n.0.aarch64.raw.xz
Image: Games live x86_64
Path: Labs/x86_64/iso/Fedora-Games-Live-x86_64-Rawhide-20230705.n.0.iso
Image: i3 live aarch64
Path: Spins/aarch64/iso/Fedora-i3-Live-aarch64-Rawhide-20230705.n.0.iso
Image: Silverblue dvd-ostree aarch64
Path: 
Silverblue/aarch64/iso/Fedora-Silverblue-ostree-aarch64-Rawhide-20230705.n.0.iso
Image: Python_Classroom raw-xz aarch64
Path: 
Labs/aarch64/images/Fedora-Python-Classroom-Rawhide-20230705.n.0.aarch64.raw.xz
Image: Jam_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Jam_KDE-Live-x86_64-Rawhide-20230705.n.0.iso
Image: Scientific vagrant-libvirt x86_64
Path: 
Labs/x86_64/images/Fedora-Scientific-Vagrant-Rawhide-20230705.n.0.x86_64.vagrant-libvirt.box
Image: Python_Classroom vagrant-virtualbox x86_64
Path: 
Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-Rawhide-20230705.n.0.x86_64.vagrant-virtualbox.box
Image: Astronomy_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Astronomy_KDE-Live-x86_64-Rawhide-20230705.n.0.iso
Image: Robotics live x86_64
Path: Labs/x86_64/iso/Fedora-Robotics-Live-x86_64-Rawhide-20230705.n.0.iso
Image: Scientific vagrant-virtualbox x86_64
Path: 
Labs/x86_64/images/Fedora-Scientific-Vagrant-Rawhide-20230705.n.0.x86_64.vagrant-virtualbox.box
Image: Sericea dvd-ostree x86_64
Path: Sericea/x86_64/iso/Fedora-Sericea-ostree-x86_64-Rawhide-20230705.n.0.iso
Image: LXQt live x86_64
Path: Spins/x86_64/iso/Fedora-LXQt-Live-x86_64-Rawhide-20230705.n.0.iso
Image: Scientific_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Scientific_KDE-Live-x86_64-Rawhide-20230705.n.0.iso



So lots of spins got broken... I may investigate these just for interest
(I am not the maintainer of any spins above),
however from just a quick glance at this, now fixing these spin breakage seems 
rather
tough work than former breakage

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

Re: rubygem-rdiscount license correction

[Mamoru TASAKA]

Vít Ondruch wrote on 2023/06/30 21:14:

Since its review, rubygem-rdiscount was clasified as ASL 1.1, but as far as I 
can tell, it was always BSD licensed. Therefore I have changed the license tag 
to BSD-3-Clause which should be in line with upstream:

https://github.com/davidfstr/rdiscount/blob/8c890c56cecaa85cebe671d12f4724215876062c/rdiscount.gemspec#L8

https://github.com/davidfstr/rdiscount/blob/8c890c56cecaa85cebe671d12f4724215876062c/COPYING


Vít



Well, actually the initial import of rubygem-rdiscount seems
version 1.6.3.2, and it seems its COPYING was actually more
Apache-1.1-like than BSD-4-Clause, so I can understand that
the initial packager labeled this as ASL-1.1, ref:

https://github.com/davidfstr/rdiscount/blob/5efa97de9fc4874635a59d3f7835b831749da1e1/COPYING
https://www.apache.org/licenses/LICENSE-1.1

Anyway I agree that current license is under BSD-3-Clause, license changed with
2.1.6:
https://github.com/davidfstr/rdiscount/commit/78de75c515bb8c93d1842e6448868a8ff087d5a2

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

Re: Announcing fmt library soversion bump

[Mamoru TASAKA]

Richard Shaw wrote on 2023/06/28 23:40:

On Wed, Jun 28, 2023 at 6:37 AM Richard Shaw  wrote:


On Wed, Jun 28, 2023 at 6:12 AM Vitaly Zaitsev via devel <
devel@lists.fedoraproject.org> wrote:


Results: 37 builds succeeded, 19 failed.

gnuradio



Issue filed upstream:
https://github.com/gnuradio/gnuradio/issues/6735



I'm currently at work but if a proven packager wants to try the solution
proposed in the above that would be helpful.

Thanks,
Richard



Fixed (build ongoing)
https://koji.fedoraproject.org/koji/buildinfo?buildID=2223120

So with fmt10, it seems fmt::format no longer accepts (unscoped) enum by
default, just casting into int fixes the issue.

dolphin-emu can perhaps be fixed similarly, ref:
https://github.com/dolphin-emu/dolphin/commit/cc5640245cf4316f9bafcb11141d8868881ddffb
If someone can apply the above change, I will appreciate it (because
now I want to take a rest)

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

Re: Fw: [Bug 2203836] New: F39FailsToInstall: slim

[Mamoru TASAKA]

Globe Trotter via devel wrote on 2023/05/15 23:36:

During unretirement of the package, I changed the dependency of slim from 
desktop-backgrounds to f??-backgrounds-base in order to have a uniform 
F-specific background for the slim login manager. However, the rawhide 
installation can not find it. Any suggestions on what to do?

Thanks!


I don't think f39-backgrounds srpm is not packaged yet:
https://koji.fedoraproject.org/koji/search?match=glob=package=f*backgrounds*

BTW I am not sure if slim itself should have such dependency for f*backgrounds -
Usually such dependency is written on kickstart or comps file, I guess.

Regards,
Mamoru




- Forwarded Message -

From: bugzi...@redhat.com 
To: "itsme_...@yahoo.com" 
Sent: Monday, May 15, 2023 at 06:41:54 AM CDT
Subject: [Bug 2203836] New: F39FailsToInstall: slim


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

             Bug ID: 2203836
           Summary: F39FailsToInstall: slim
           Product: Fedora
           Version: rawhide
             Status: NEW
         Component: slim
           Assignee: itsme_...@yahoo.com
           Reporter: fti-b...@fedoraproject.org
         QA Contact: extras...@fedoraproject.org
                 CC: itsme_...@yahoo.com, pa...@hubbitus.info
             Blocks: 2168845 (F39FailsToInstall,RAWHIDEFailsToInstall)
   Target Milestone: ---
     Classification: Fedora



Hello,

Please note that this comment was generated automatically by
https://pagure.io/releng/blob/main/f/scripts/ftbfs-fti/follow-policy.py
If you feel that this output has mistakes, please open an issue at
https://pagure.io/releng/

Your package (slim) Fails To Install in Fedora 39:

can't install slim:
   - nothing provides f39-backgrounds-base needed by slim-1.4.0-6.fc39.x86_64

If you know about this problem and are planning on fixing it, please
acknowledge so by setting the bug status to ASSIGNED. If you don't have time to
maintain this package, consider orphaning it, so maintainers of dependent
packages realize the problem.


If you don't react accordingly to the policy for FTBFS/FTI bugs
(https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/),
your package may be orphaned in 8+ weeks.


P.S. The data was generated solely from koji buildroot, so it might be newer
than the latest compose or the content on mirrors. To reproduce, use the
koji/local repo only, e.g. in mock:

     $ mock -r fedora-39-x86_64 --config-opts mirrored=False install slim


P.P.S. If this bug has been reported in the middle of upgrading multiple
dependent packages, please consider using side tags:
https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#updating-inter-dependent-packages

Thanks!



Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=2168845
[Bug 2168845] Fedora 39 Fails To install Tracker

___
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: Changing the License tag of python-rpm-generators from GPLv2+ to a monstrosity

[Mamoru TASAKA]

Chris Kelley wrote on 2023/05/05 22:55:

As a purely logical expression, this simplifies to "GPL-2.0-or-later AND
LGPL-2.1-or-later". Is that sort of simplification not allowed?



This is no longer allowed:
https://docs.fedoraproject.org/en-US/legal/license-field/#_no_effective_license_analysis

Yes, so I am also re-checking the whole sources in the srpm I maintain...

Regards,
Mamoru



On Fri, 5 May 2023, 13:20 Miro Hrončok,  wrote:


python-rpm-generators License tag changes from GPLv2+ to:

GPL-2.0-or-later AND LGPL-2.1-or-later AND
(LicenseRef-Fedora-Public-Domain OR
LGPL-2.1-or-later OR GPL-2.0-or-later)

https://src.fedoraproject.org/rpms/python-rpm-generators/pull-request/67

Funny thing is that the "(LicenseRef-Fedora-Public-Domain OR
LGPL-2.1-or-later
OR GPL-2.0-or-later)" thing was originally chosen to keep the License tag
of
the package simple while allowing others to grab the code from it without
obligations :/

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




___
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: redhat-lsb-core

[Mamoru TASAKA]

Steven A. Falco wrote on 2023/04/04 5:13:

I'm confused by the Requires for redhat-lsb-core.

According to "dnf repoquery --requires redhat-lsb-core" there is no requirement for 
esmtp.  But according to "dnf repoquery --whatrequires esmtp", redhat-lsb-core does 
require esmtp.


Well, somebody may have answered this, however:

redhat-lsb-core has "Requires: /usr/sbin/sendmail" (according to repoquery).
esmtp is one of /usr/sbin/sendmail providers.

# dnf repoquery -q --repo=koji-39 --whatprovides /usr/sbin/sendmail
esmtp-0:1.2-21.fc38.x86_64
exim-0:4.96-8.fc38.x86_64
msmtp-0:1.8.23-2.fc39.x86_64
opensmtpd-0:6.8.0p2-11.fc38.x86_64
postfix-2:3.7.4-1.fc38.x86_64
sendmail-0:8.17.1-8.fc38.x86_64
ssmtp-0:2.64-32.fc38.x86_64

So to satisfy "/usr/sbin/sendmail" Requires, esmtp can be chosen (and some 
other candidate may be chosen).


I don't understand that.  Why are some users getting esmtp when they install 
KiCad, yet I didn't get esmtp when I installed KiCad?


Perhaps "dnf install KiCad" will choose esmtp when searching for 
"/usr/sbin/sendmail" provider, on the other hand
if you have already installed some other packages which provides 
"/usr/sbin/sendmail", installing KiCad won't install
esmtp additionally.



A bigger question would be how to restructure OS information gathering, since 
redhat-lsb-core does pull in a lot of stuff, but that is a question for another 
day...

 Steve


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

Re: Need help to build Blender 3.5.0

[Mamoru TASAKA]

Luya Tshimbalanga wrote on 2023/03/30 13:04:

Hello team,
Blender 3.5.0 got released today at this time of writing. Unfortunately, 
failure occurred with the following link possibly related to cycles:

https://koji.fedoraproject.org/koji/taskinfo?taskID=99301805

Can someone investigate the problem?

Thanks


gcc is ICEing. Reported against gcc for now:
https://bugzilla.redhat.com/show_bug.cgi?id=2183692

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

Re: compiling guayadeque on rawhide and f38 - error: ambiguous overload for 'operator!='

[Mamoru TASAKA]

Martin Gansser wrote on 2023/02/24 18:23:

Hi,

when i compile guayadeque-0.4.7 [1] on rawhide and f38 i get the following 
error messages [2]:

/builddir/build/BUILD/guayadeque-0.4.7/src/taginfo/TagInfo.cpp: In member function 
'virtual bool Guayadeque::guGStreamerTagInfo::ReadGStreamerTags(const 
wxString&)':
/usr/include/glib-2.0/glib/gstrfuncs.h:209:22: error: ambiguous overload for 
'operator!=' (operand types are 'wxCStrData' and 'long int')
   209 | (G_LIKELY ((STR) != NULL) ?
   \
   |  ^

[1] https://src.fedoraproject.org/rpms/guayadeque/tree/master
[2] https://kojipkgs.fedoraproject.org//work/tasks/1757/97931757/build.log

How can i solve this ?


Perhaps
2533 | uri = g_strdup( filename.c_str() );
needs explicit cast like

uri = g_strdup ( (const gchar*)filename.c_str() );



Regards
Martin


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

Re: [HEADS UP] Fedora 39 Boost 1.81 rebuilds starting Monday 2022-02-20

[Mamoru TASAKA]

Thomas Rodgers wrote on 2023/02/23 5:51:

The f39-boost side tag builds have finished.

The following packages are new FTBFS likely due to the Boost update -

The following packages FTBFS but the build logs provide no useful
information -
- blender [[
https://kojipkgs.fedoraproject.org//work/tasks/1240/97841240/build.log][build.log
]]


This is because of fail_fast = True. Actually other arch shows this build 
failed due
to unresolved dependency:
https://koji.fedoraproject.org/koji/taskinfo?taskID=97841240
https://kojipkgs.fedoraproject.org//work/tasks/1240/97841240/root.log


- luxcorerender [[
https://kojipkgs.fedoraproject.org//work/tasks/3851/97843851/build.log][build.log
]]
- openshadinglanguage [[
https://kojipkgs.fedoraproject.org//work/tasks/4938/97844938/build.log][build.log
]]
- OpenImageIO  [[
https://kojipkgs.fedoraproject.org//work/tasks/3952/97793952/build.log][build.log
]]
- usd [[
https://kojipkgs.fedoraproject.org//work/tasks/5975/97845975/build.log][build.log
]]



The above 4 are all related to blender (I think), perhaps these all failed due 
to
unresolved dependency, and perhaps these all needs some chainbuild (for new 
boost).

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

Re: Orphaned packages looking for new maintainers

[Mamoru TASAKA]

Raphael Groner wrote on 2023/02/23 6:11:

Hi,

why are those packages orphan? lxsession-edit, lxpolkit and parcellite? Is LXDE 
spin officially dead, what's current maintainer or do we still need mentioned 
packages as additional option?



lxsession-edit, lxpolkit is now built from lxsession.src.rpm, so no need for 
these
anymore.
parcellite is not in LXDE spin, LXDE spin uses clipit, so I did not take this.

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

Re: Strange RPM "recognition of file" error in f38 and f39 build

[Mamoru TASAKA]

Eike Rathke wrote on 2023/02/09 22:02:

Hi,

Building Thunderbird for f38 and f39 now bails out with an RPM build
error

Recognition of file 
"/builddir/build/BUILDROOT/thunderbird-102.7.2-1.fc39.aarch64/usr/lib64/thunderbird/libxul.so"
 failed: mode 100755 , dynamically linked, 
BuildID[sha1]=633a0656d9de96c14d0960117d1029f4846c34ae Note section size too big (121835212 
> 67108864) (Invalid argument)

See build.log of
https://koji.fedoraproject.org/koji/taskinfo?taskID=97288572
https://koji.fedoraproject.org/koji/taskinfo?taskID=97303047

Builds for f36 and f37 are fine, as was an earlier build of the previous
release for f38 last week.

Assumption is, something changed in libmagic.

   Eike




Looks like due to this change:
https://github.com/file/file/commit/e1233247bbe4d2d66b891224336a23384a93cce1

and the above change seems related to:
https://bugs.astron.com/view.php?id=372

which seems to avoid some ASAN errors, however maybe this issue should not be
handed in the way in the commit.

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

Re: Unannounced ABI breakage in shaderc

[Mamoru TASAKA]

Mamoru TASAKA wrote on 2023/02/02 0:24:

Vitaly Zaitsev wrote on 2023/02/01 23:47:

Hello.

shaderc-2022.2-5.fc38 includes an unannounced ABI breakage.

$ mpv --version
mpv: symbol lookup error: /lib64/libshaderc_shared.so.1: undefined symbol: 
_ZN8spvtools23CreateAggressiveDCEPassEv

RHBZ issue: https://bugzilla.redhat.com/show_bug.cgi?id=2166218



Not correct: the missing symbol was in shaderc-2022.2-4.fc38, -5 is the "fixed" 
version.


The missing symbol was actually in -3.fc38, -4.fc38 was not built (FTBFS), -5 
fixed the issue.



And the real cause is not in shaderc but in spirv-tools-2022.2-6.fc38 which 
removed the
above symbol silently.

Actually blender build was failing due to this issue, see:
https://koji.fedoraproject.org/koji/taskinfo?taskID=96899857 ,
so I analyzed the cause, then modified shaderc, then rebuilt blender.

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

Re: Unannounced ABI breakage in shaderc

[Mamoru TASAKA]

Vitaly Zaitsev wrote on 2023/02/01 23:47:

Hello.

shaderc-2022.2-5.fc38 includes an unannounced ABI breakage.

$ mpv --version
mpv: symbol lookup error: /lib64/libshaderc_shared.so.1: undefined symbol: 
_ZN8spvtools23CreateAggressiveDCEPassEv

RHBZ issue: https://bugzilla.redhat.com/show_bug.cgi?id=2166218



Not correct: the missing symbol was in shaderc-2022.2-4.fc38, -5 is the "fixed" 
version.

And the real cause is not in shaderc but in spirv-tools-2022.2-6.fc38 which 
removed the
above symbol silently.

Actually blender build was failing due to this issue, see:
https://koji.fedoraproject.org/koji/taskinfo?taskID=96899857 ,
so I analyzed the cause, then modified shaderc, then rebuilt blender.

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

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

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

Re: [Fedora Update] [CRITPATH] [comment] alt-ergo-2.3.3-5.fc38, apron-0.9.13-16.fc38, and 182 more

[Mamoru TASAKA]

Richard W.M. Jones wrote on 2023/01/25 22:12:

On Wed, Jan 25, 2023 at 11:22:18AM +, Richard W.M. Jones wrote:

On Wed, Jan 25, 2023 at 10:43:50AM +, upda...@fedoraproject.org wrote:

The following comment has been added to the alt-ergo-2.3.3-5.fc38 
apron-0.9.13-16.fc38 [...] update:

bodhi - 2023-01-25 10:43:50.440400 (karma: 0)
This update cannot be pushed to stable. These builds graphviz-7.0.6-4.fc38 have 
a more recent build in koji's f38 tag.


Jaroslav, could you do a build into the f38-build-side-62208
side tag please, ie:

   fedpkg build --target=f38-build-side-62208

Alternately, I could drop the graphviz package from this update and
then you'll have to do a build afterwards (or the OCaml part will be
broken).

Rich.


To reply to this comment, please visit the URL at the bottom of this mail


  FEDORA-2023-7bd037f981

 Release: Fedora 38
  Status: testing
Type: unspecified
Severity: unspecified
   Karma: 0
Critpath: True
   Notes: Rebuild all OCaml packages after the F38 mass rebuild
   Submitter: rjones
   Submitted: 2023-01-25 09:41:44.872273
Comments: bodhi - 2023-01-25 10:43:50.440400 (karma 0)
  This update cannot be pushed to stable. These builds
  graphviz-7.0.6-4.fc38 have a more recent build in
  koji's f38 tag.
  bodhi - 2023-01-25 10:39:35.011437 (karma 0)
  This update's test gating status has been changed to
  'ignored'.
  bodhi - 2023-01-25 09:41:45.003272 (karma 0)
  This update's test gating status has been changed to
  'waiting'.

   https://bodhi.fedoraproject.org/updates/FEDORA-2023-7bd037f981


And I could do with some help here too...

How do you edit the list of builds (to remove a build)?  I cannot see
any way to do this in the UI.

Alternately, why does an older build block a push to stable?  Won't
the old build simply be ignored if there's a higher NVR version
around?

Rich.



For now I removed graphviz-7.0.6-4.fc38 from the above bodhi request, and
the rest 183 pkgs now went to f38 buildroot.

Just note: side-tag can be untagged:
$ koji untag f38-build-side-62208  graphviz-7.0.6-4.fc38

Then again go to the bodhi request and push "edit", and push "reload" side-tag
build, then actually untagged builds are removed from update request.

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

Re: gcc: RPM_ARCH not defined

[Mamoru TASAKA]

Mamoru TASAKA wrote on 2023/01/23 21:54:

Lukas Javorsky wrote on 2023/01/23 21:39:

Hi,

I've been looking at our upstreamed test [1] for libarchive package and it
started to fail since Fedora 37.

The error is: "gcc: fatal error: environment variable 'RPM_ARCH' not defined
"

Prior to the Fedora 37 the test was passing without any issue.

Did anyone here had a similar problem?
Or could anyone help me find out what has changed so it's causing this
issue?

[1]
https://src.fedoraproject.org/tests/libarchive/blob/main/f/Sanity/Basic-sanity-test-for-libarchive

Thank you so much for your help


Most possibly due to "package note".

`rpmbuild -bc` defines  %{_package_note_flags}, embeds 
"-specs=/usr/lib/rpm/redhat/redhat-package-notes"
to LDFLAGS, which needs "RPM_ARCH" environment. During rpmbuild process, this 
environment is provided,
but then later "make" process does not define this automatically (because this 
process is not under
"rpmbuild"), so embedded "-specs=/usr/lib/rpm/redhat/redhat-package-notes" 
LDFLAGS complains about
missing environment.

(Yes, I think this is annoying - sometimes rpmbuild fails with some reason, I 
try to fix compilation error
  then try executing "make" locally, then I see linker complains about "'RPM_ARCH' 
not defined"...)

I usually write "%_package_note_flags %nil" to ~/.rpmmacros, not sure if 
rpmbuild command line can
undefine macros.



Or maybe changing to "rpmbuild --define '_package_note_flags %nil' -bc 
libarchive.spec" can fix the
issue you see.

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

Re: gcc: RPM_ARCH not defined

[Mamoru TASAKA]

Lukas Javorsky wrote on 2023/01/23 21:39:

Hi,

I've been looking at our upstreamed test [1] for libarchive package and it
started to fail since Fedora 37.

The error is: "gcc: fatal error: environment variable 'RPM_ARCH' not defined
"

Prior to the Fedora 37 the test was passing without any issue.

Did anyone here had a similar problem?
Or could anyone help me find out what has changed so it's causing this
issue?

[1]
https://src.fedoraproject.org/tests/libarchive/blob/main/f/Sanity/Basic-sanity-test-for-libarchive

Thank you so much for your help


Most possibly due to "package note".

`rpmbuild -bc` defines  %{_package_note_flags}, embeds 
"-specs=/usr/lib/rpm/redhat/redhat-package-notes"
to LDFLAGS, which needs "RPM_ARCH" environment. During rpmbuild process, this 
environment is provided,
but then later "make" process does not define this automatically (because this 
process is not under
"rpmbuild"), so embedded "-specs=/usr/lib/rpm/redhat/redhat-package-notes" 
LDFLAGS complains about
missing environment.

(Yes, I think this is annoying - sometimes rpmbuild fails with some reason, I 
try to fix compilation error
 then try executing "make" locally, then I see linker complains about "'RPM_ARCH' 
not defined"...)

I usually write "%_package_note_flags %nil" to ~/.rpmmacros, not sure if 
rpmbuild command line can
undefine macros.

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

Re: fedpkg local - do not clean build directory

[Mamoru TASAKA]

Petr Pisar wrote on 2023/01/17 18:29:

V Tue, Jan 17, 2023 at 10:11:48AM +0100, Dan Horák napsal(a):

On Mon, 16 Jan 2023 21:21:39 -0700
Orion Poplawski  wrote:


How the #$@! do I get fedpkg local to not cleanup the local build
directory after a successful build?  This is the most annoying change to
come around in a long time IMHO.


hmm, it doesn't clean the build directory here (fedpkg-1.43-2.fc36)


rpmbuild does that:

Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.oNsT7U
 

 From rpm-4.18.0-beta1 changelog:

commit 6f945960affc7a2a2b49337458457273d8a4faf5
Author: Panu Matilainen 
Date:   Wed May 25 15:08:30 2022 +0300

 Remove build tree automatically on successfull binary package creation


It think "fedpkg local" needs a new "--noclean" option.

-- Petr



Currently I do "$ fedpkg local -- --noclean" .

$ fedpkg local --help
positional arguments:
  extra_argsCustom arguments that are passed to the 'rpmbuild'. Use 
'--' to separate them from other arguments.


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

Re: List of long term FTBFS packages to be retired in February

[Mamoru TASAKA]

Kalev Lember wrote on 2023/01/12 0:03:

On Wed, Jan 11, 2023 at 3:51 PM Mamoru TASAKA 
wrote:


Miro Hrončok wrote on 2023/01/11 21:58:

libgnome alexl, caolanm,

gnome-sig,

   mbarnes, rhughes,

rstrode,

I've just fixed now:
https://koji.fedoraproject.org/koji/buildinfo?buildID=2109750



Hi Mamoru,

Out of curiosity, why? Do you actually need libgnome? I was hoping it would
get removed this cycle so we can finally stop shipping the old gnome 2
library stack.



For example, a (rather old) package "fantasdic" I maintain depends on libgnome
as:
fantasdic <- ruby-gnome2 <- libgnome
Other example is cbrpager <- libgnomeui <- libgnome

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

Re: List of long term FTBFS packages to be retired in February

[Mamoru TASAKA]

Miro Hrončok wrote on 2023/01/11 21:58:

Dear maintainers.

Based on the current fail to build from source policy, the following packages
should be retired from Fedora 38 approximately one week before branching.

5 weekly reminders are required, hence the retirement will happen
approximately in 5 weeks, i.e. around 2023-02-08.
Since this is unfortunately after the branching,
packages will be retired on rawhide and f38.

I apologize for starting this process a bit later than required.

Policy: 
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/

The packages in rawhide were not successfully built at least since Fedora 35.

This report is based on dist tags.

Packages collected via:
https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb

If you see a package that was built, please let me know.
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.

If you see a package that can be rebuilt, please do so.

     Package  (co)maintainers




libgnome alexl, caolanm, gnome-sig,
  mbarnes, rhughes, rstrode,


I've just fixed now:
https://koji.fedoraproject.org/koji/buildinfo?buildID=2109750

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

Re: Malicious communication (was: Re: Schedule for Tuesday's FESCo Meeting (2023-01-03))

[Mamoru TASAKA]

Neal Gompa wrote on 2023/01/09 11:58:


I'm extremely tired of how you communicate on this mailing list. I've
been quiet about it for years and years. But people leave Fedora
because of you. Once again, I'm having discussions with people trying
to convince them Fedora isn't a bad place because of you.


I don't think this message is appropriate, as other people already said.



Too many people give you leeway because you're not considered a native
English speaker. You know what? I've met far too many better
communicators who have English as a second, third, or even fourth
language.


Honestly saying, I cannot understand this context, why native English
speaker or not is relevant here, especially because I am also
non-native.

I don't think Fedora committers change their attitude against
between native or non-native English speakers.

Even if someone takes uncomfortable attitude against you, you also
have to refrain from attacking the person like this way.

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

Re: ispc fails to build with llvm 15

[Mamoru TASAKA]

Luya Tshimbalanga wrote on 2023/01/07 15:57:

Hello team,
Could someone investigate the failure to build ispc [1] with the recent LLVM[2] 
?


References:
[1] https://src.fedoraproject.org/rpms/ispc
[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=95826442


In file included from /builddir/build/BUILD/ispc-1.18.1/src/ispc.h:40,
 from src/parse.yy:88:
/builddir/build/BUILD/ispc-1.18.1/src/ispc_version.h:66:2: error: #error "Only LLVM 
11.0 - 14.0 are supported"
   66 | #error "Only LLVM 11.0 - 14.0 are supported"
  |  ^

https://github.com/ispc/ispc/blob/222aa0a8628965f2ce5c53e922a7334be75f8c9b/src/ispc_version.h#L65-L67

Looks like ispc 1.19 develpment branch is needed:
https://github.com/ispc/ispc/commit/6a1b2ffae0cc12467838bc671e3b089924de90a6

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

Re: HEADS UP: icu 72 coming to rawhide

[Mamoru TASAKA]

Pete Walter wrote on 2022/12/31 22:30:

28.12.2022, 15:09, "Pete Walter" :

 Hi,

 I am in the process of updating icu from 71.1 to 72.1 in rawhide. This 
comes
 with a soname bump, but as usual, I'm including a compat package providing
 the old soname to not break the world while the rebuilds are in progress, 
so
 no rawhide breakage is expected. I'll work on the rebuilds over the 
weekend.

This is now done. The following 4 packages failed to rebuild. The rest of 102
packages built fine and are all rebuilt in rawhide.

mozjs78: https://koji.fedoraproject.org/koji/taskinfo?taskID=95691022

mozjs91: https://koji.fedoraproject.org/koji/taskinfo?taskID=95691025

mozjs102: https://koji.fedoraproject.org/koji/taskinfo?taskID=95691005

postfix: https://koji.fedoraproject.org/koji/taskinfo?taskID=95695828



I've fixed postfix build, backporting upstream 3.8-20221006 fix as 
postfix-3.7.3-3.fc38:
https://koji.fedoraproject.org/koji/taskinfo?taskID=95696895



mozjs* failed in self tests which I bet need updating for new icu. postfix
failed due to an unrelated failure and was already FTBFS before the icu update.
Pete



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

Re: Strange FTBS

[Mamoru TASAKA]

Ralf Corsépius wrote on 2022/12/09 19:01:

Hi,

I am facing a FTBS when trying to rebuild povray due to SPDX-changes:

- In local mock environments, building suddenly waits for keyboard input.
- In koji, building seemingly hangs and never times out (I killed a build job 
after 48h hours.

Surprising to me is, this package had built flawlessly and not seen major 
changes for years.

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

Ralf
___


$ make check , expecially
$ ./unix/povray +i./scenes/advanced/biscuit.pov -f +d +p +v +w320 +h240 +a0.3 
+L./include

is hanging. When entering mock buildroot and manually executing the above 
command,
it is hanging with the message:

 [Paused] ==
Press a key or click the display to continue...

This is UnixSDLDisplay::PauseWhenDoneNotifyStart() in unix/disp_sdl.cpp.
So I guess this is related with sdl side change.

Actually with SDL2-2.24.0-1.fc38.x86_64 the above does not hang, but
with SDL2-2.26.0-1.fc38.x86_64 this does hang.
The last successful real build on koji was using SDL2-2.0.22-3.fc37,
I've comfirmed that with SDL2-2.0.22-3.fc37 the above does not hang.

Not sure this is povray side bug or SDL2 side bug.

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

Re: [HEADS UP] Rebuild of wxGTK wxGLCanvas-using packages

[Mamoru TASAKA]

Scott Talbert wrote on 2022/11/24 2:23:

Hi all,

In order to fix some incompatibilities with wxWidgets wxGLCanvas (which is 
currently built with OpenGL EGL support) and several package users which are 
expecting OpenGL GLX support, I need to rebuild wxWidgets with a different 
configuration option.  Unfortunately, this results in an ABI change, so all 
packages that link with libwx_gtk3u_gl-3.2.so.0 need to be rebuilt.  
Unfortunately #2, this also needs to be done in F37.  I've opened two side tags 
to do the rebuilds for F37 and F38.

F37: f37-build-side-60200
F38: f38-build-side-60198

The following packages need to be rebuilt in the above side tags (note, I've 
already taken care of python-wxpython4 and CubicSDR, which are also affected):

0ad
OpenSceneGraph
erlang
hugin
kicad
mrpt
panoglview
visualboyadvance-m
wxmacmolplt

If the maintainers of those packages could rebuild their packages in both of 
the above side tags, it would be creatly appreciated.  After a week, I'll flag 
down a provenpackager to assist with the rest.

Thanks,
Scott


All the requested packages have been successfully rebuilt:
https://koji.fedoraproject.org/koji/builds?inherited=0=60198=-build_id=1
https://koji.fedoraproject.org/koji/builds?inherited=0=60200=-build_id=1

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

Re: zdohnal pushed to tests/vim (main). "upstream-unittests: Apply RPM workaround for package notes from Ruby (..more)"

[Mamoru TASAKA]

notificati...@fedoraproject.org wrote on 2022/11/23 20:34:

Notification time stamped 2022-11-23 11:34:19 UTC

 From 1f016e5dedbb5bc7293c1638e1238989d6fabaa5 Mon Sep 17 00:00:00 2001
From: Zdenek Dohnal 
Date: Nov 23 2022 11:30:01 +
Subject: upstream-unittests: Apply RPM workaround for package notes from Ruby


Vim adds Ruby LDFLAGS during configuration, which (due Ruby's decision
to embed flags from the building time) contains flags from buildsystem
environment, especially package notes. This flag expects additional
environment variables to be set and they aren't set in normal
environment.

I've reported it to Vim upstream with PR which removes Ruby LDFLAGS from
configure script https://github.com/vim/vim/pull/11592 .



And ruby (on rawhide for now) removed package_notes again because
currently non-rpmbuild build is broken with embedded package_notes flag:

https://src.fedoraproject.org/rpms/ruby/c/1d0c071aebd50621eb049a2ab8d20da3133f9f16
https://bugzilla.redhat.com/show_bug.cgi?id=2142119
https://bugzilla.redhat.com/show_bug.cgi?id=2043092

Regards,
Mamoru



---

diff --git a/Sanity/upstream-unittests/runtest.sh 
b/Sanity/upstream-unittests/runtest.sh
index 1919bd4..6f22812 100755
--- a/Sanity/upstream-unittests/runtest.sh
+++ b/Sanity/upstream-unittests/runtest.sh
@@ -70,6 +70,10 @@ rlJournalStart
  rlRun "RUBY_CFLAGS='`ruby -r rbconfig -e "puts RbConfig::CONFIG['CFLAGS']"`'" 0 
"Get ruby CFLAGS"
  rlRun "export CFLAGS='$RUBY_CFLAGS'"  0 
"Set ruby CFLAGS"
  
+# newer redhat-rpm-config brings in packager-notes script, which breaks LDFLAGS we get from Ruby

+# we need to set several env variable randomly to get configure 
working again...
+rlRun "RPM_WORKAROUND='RPM_ARCH=\"x86_64\" RPM_PACKAGE_RELEASE=\"1\" 
RPM_PACKAGE_VERSION=\"1\" RPM_PACKAGE_NAME=\"vim\"'"
+
  # show relevant info & ENV variables
  rlLog "TEST:   $TEST"
  rlLog "CONFOPT:$CONFOPT"
@@ -85,8 +89,8 @@ rlJournalStart
  rlRun "TERM=$TERM_type"
  
  # following block of code is taken from upstream travis.yml

-rlRun "su $TESTER -c './configure ${CONFOPT} CFLAGS=\"${CFLAGS} $RUBY_FLAGS\"'" 
0 "Configure Vim"
-rlRun "su $TESTER -c 'make'" 0 "Build the binary which we substitute"
+rlRun "su $TESTER -c './configure ${CONFOPT} CFLAGS=\"${CFLAGS} $RUBY_FLAGS\" 
$RPM_WORKAROUND'" 0 "Configure Vim"
+rlRun "su $TESTER -c '$RPM_WORKAROUND make'" 0 "Build the binary which we 
substitute"
  rlRun "su $TESTER -c 'ln -sf /usr/bin/vim  src/vim'"0   "Create 
symlink to installed vim for testing"
  rlRun "su $TESTER -c 'make ${TEST} |& tee output'" 0,2 "Run tests (skip 
builtin terminal errors)"
  _res_=$?



https://src.fedoraproject.org/tests/vim/c/1f016e5dedbb5bc7293c1638e1238989d6fabaa5?branch=main
___
scm-commits mailing list -- scm-comm...@lists.fedoraproject.org
To unsubscribe send an email to scm-commits-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/scm-comm...@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: yaml-cpp 0.7.0 soname bump for Rawhide is complete

[Mamoru TASAKA]

Richard Shaw wrote on 2022/11/16 1:10:

I had to back off updating OpenColorIO as it needed a newer version of
minizip-ng than what's available.

https://bodhi.fedoraproject.org/updates/FEDORA-2022-518f2de934

The only fallout is supercollider which failed to build for other reasons:

https://koji.fedoraproject.org/koji/buildinfo?buildID=2085987


supercollider is fixed in -7, backporting upstream fix for libsndfile 1.1.x .
https://koji.fedoraproject.org/koji/buildinfo?buildID=2089036

repoquery says cantera also needs rebuilding for new yaml-cpp, so it's done.


Thanks,
Richard



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

Re: Help needed with build failing in Koji for rawhide i686

[Mamoru TASAKA]

Sandro wrote on 2022/11/13 6:37:

On 12-11-2022 22:21, Vitaly Zaitsev via devel wrote:

On 12/11/2022 22:09, Sandro wrote:

I did an 'rpm -qf /lib/libsndfile.so.1' and that pointed me to the
libsndfile package, which wasn't updated recently.


It looks like --disable-largefile flag changed ABI and all dependent
packages must be rebuilt.


I'm taking that as an indirect answer. ;)

I should have looked at what libsndfile depends on with ldd, which lists 
libmpg123 among others.



For now I've reverted --disable-largefile configure option on
rawhide mpg123. F-37/36 mpg123 were unpushed due to negative karmas.

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

Re: libxml2-2.10.3-1.fc36 breaks (part of) GraphicsMagick

[Mamoru TASAKA]

Michael J Gruber wrote on 2022/10/29 5:19:

With this libxml2 update:
```
gm convert -list format
...
gm convert: Unable to load module 
("/usr/lib64/GraphicsMagick-1.3.38/modules-Q16/coders/url.la: file not found")
```
In fact, `url.so` is there but cannot be dlopen'ed. This works after 
downgrading libxml2 to 2.9.
I noticed because my scribus failed to start today, and this was somehow tough 
to track down.
I still don't know whether libxml2 had an abi change without soname bump and 
whether a simple rebuild of GM would solve this (in particular, which one to 
file a big against). But since it was diificult to spot and more packages could 
be broken (without a clear FTI/FTBFS) I wanted to give a heads up here.



Confirmed, as I've noticed that now rubygem-rmagick is now FTBFS.
So I tried narrowing the issue and the minimum reproducer is:

$ ldd -r /usr/lib64/ImageMagick-6.9.12/modules-Q16/coders/url.so  | grep 
undefined
undefined symbol: xmlNanoFTPInit, version LIBXML2_2.4.30
(/usr/lib64/ImageMagick-6.9.12/modules-Q16/coders/url.so)
undefined symbol: xmlNanoFTPClose, version LIBXML2_2.4.30   
(/usr/lib64/ImageMagick-6.9.12/modules-Q16/coders/url.so)
undefined symbol: xmlNanoFTPGet, version LIBXML2_2.4.30 
(/usr/lib64/ImageMagick-6.9.12/modules-Q16/coders/url.so)
undefined symbol: xmlNanoFTPNewCtxt, version LIBXML2_2.4.30 
(/usr/lib64/ImageMagick-6.9.12/modules-Q16/coders/url.so)
undefined symbol: xmlNanoFTPConnect, version LIBXML2_2.4.30 
(/usr/lib64/ImageMagick-6.9.12/modules-Q16/coders/url.so)

(i.e. ImageMagick is now broken)

This is perhaps due to the following change:
https://gitlab.gnome.org/GNOME/libxml2/-/commit/a0a0f3be93753e387e31e7de95904a24b3c876dd

... and in fact lots of other symbols are also removed...

$ rpmsodiff libxml2-2.9.14-3.fc37.x86_64.rpm libxml2-2.10.3-1.fc37.x86_64.rpm | grep 
"^-"
--- libxml2-2.9.14-3.fc37/libxml2.so.2  2022-07-22 05:06:27.0 +0900
-__docbDefaultSAXHandlerT
-attribute@@LIBXML2_2.4.30  T
-attributeDecl@@LIBXML2_2.4.30  T
-cdataBlock@@LIBXML2_2.4.30 T
-characters@@LIBXML2_2.4.30 T
-checkNamespace@@LIBXML2_2.4.30 T
-comment@@LIBXML2_2.4.30T
-docbDefaultSAXHandler@@LIBXML2_2.4.30  D
-docbDefaultSAXHandlerInit@@LIBXML2_2.4.30  T
-elementDecl@@LIBXML2_2.4.30T
-endDocument@@LIBXML2_2.4.30T
-endElement@@LIBXML2_2.4.30 T
-entityDecl@@LIBXML2_2.4.30 T
-externalSubset@@LIBXML2_2.4.30 T
-getColumnNumber@@LIBXML2_2.4.30T
-getEntity@@LIBXML2_2.4.30  T
-getLineNumber@@LIBXML2_2.4.30  T
-getNamespace@@LIBXML2_2.4.30   T
-getParameterEntity@@LIBXML2_2.4.30 T
-getPublicId@@LIBXML2_2.4.30T
-getSystemId@@LIBXML2_2.4.30T
-globalNamespace@@LIBXML2_2.4.30T
-hasExternalSubset@@LIBXML2_2.4.30  T
-hasInternalSubset@@LIBXML2_2.4.30  T
-htmlDecodeEntities T
-ignorableWhitespace@@LIBXML2_2.4.30T
-initdocbDefaultSAXHandler@@LIBXML2_2.4.30  T
-inithtmlDefaultSAXHandler@@LIBXML2_2.4.30  T
-initxmlDefaultSAXHandler@@LIBXML2_2.4.30   T
-internalSubset@@LIBXML2_2.4.30 T
-isStandalone@@LIBXML2_2.4.30   T
-namespaceDecl@@LIBXML2_2.4.30  T
-notationDecl@@LIBXML2_2.4.30   T
-processingInstruction@@LIBXML2_2.4.30  T
-reference@@LIBXML2_2.4.30  T
-resolveEntity@@LIBXML2_2.4.30  T
-setDocumentLocator@@LIBXML2_2.4.30 T
-setNamespace@@LIBXML2_2.4.30   T
-startDocument@@LIBXML2_2.4.30  T
-startElement@@LIBXML2_2.4.30   T
-unparsedEntityDecl@@LIBXML2_2.4.30 T
-xmlBufAddHead  T
-xmlBufEraseT
-xmlBufInflate  T
-xmlBufWriteCHART
-xmlBufWriteCharT
-xmlCleanupPredefinedEntities@@LIBXML2_2.4.30   T
-xmlDecodeEntities@@LIBXML2_2.4.30  T
-xmlEncodeEntities@@LIBXML2_2.4.30  T
-xmlGetFeature@@LIBXML2_2.4.30  T
-xmlGetFeaturesList@@LIBXML2_2.4.30 T
-xmlHandleEntity@@LIBXML2_2.4.30T
-xmlIOFTPClose@@LIBXML2_2.4.30  T
-xmlIOFTPMatch@@LIBXML2_2.4.30  T
-xmlIOFTPOpen@@LIBXML2_2.4.30   T
-xmlIOFTPRead@@LIBXML2_2.4.30   T
-xmlInitializePredefinedEntities@@LIBXML2_2.4.30T
-xmlNamespaceParseNCName@@LIBXML2_2.4.30T
-xmlNamespaceParseNSDef@@LIBXML2_2.4.30 T
-xmlNamespaceParseQName@@LIBXML2_2.4.30 T
-xmlNanoFTPCheckResponse@@LIBXML2_2.4.30T
-xmlNanoFTPCleanup@@LIBXML2_2.4.30  T
-xmlNanoFTPClose@@LIBXML2_2.4.30T
-xmlNanoFTPCloseConnection@@LIBXML2_2.4.30  T
-xmlNanoFTPConnect@@LIBXML2_2.4.30  T
-xmlNanoFTPConnectTo@@LIBXML2_2.4.30T
-xmlNanoFTPCwd@@LIBXML2_2.4.30  T
-xmlNanoFTPDele@@LIBXML2_2.5.5  T
-xmlNanoFTPFreeCtxt@@LIBXML2_2.4.30 T
-xmlNanoFTPGet@@LIBXML2_2.4.30  T
-xmlNanoFTPGetConnection@@LIBXML2_2.4.30T
-xmlNanoFTPGetResponse@@LIBXML2_2.4.30  T
-xmlNanoFTPGetSocket@@LIBXML2_2.4.30T
-xmlNanoFTPInit@@LIBXML2_2.4.30 T
-xmlNanoFTPList@@LIBXML2_2.4.30 T
-xmlNanoFTPNewCtxt@@LIBXML2_2.4.30  T
-xmlNanoFTPOpen@@LIBXML2_2.4.30 T
-xmlNanoFTPProxy@@LIBXML2_2.4.30T
-xmlNanoFTPQuit@@LIBXML2_2.4.30 T
-xmlNanoFTPRead@@LIBXML2_2.4.30 T
-xmlNanoFTPScanProxy@@LIBXML2_2.4.30

Re: [side tags] Undesired automatic side-tag removal happened - how to deal with it in the future?

[Mamoru TASAKA]

Zdenek Dohnal wrote on 2022/10/10 17:17:

Hi all,

I maintain qpdf in Fedora, which recently got a new major release version, 
which breaks compatibility with other packages, so I created a side tag for 
other maintainers to use for building, and then releasing it altogether in 
rawhide.

However the side tag:

f38-build-side-58658

got automatically deleted, even when it had builds connected to it already. 
Documentation [1] does not mention any automatic side-tags cleanup and its 
deadlines.

Although packagers can create a new side tag easily, I found it inconvenient 
for maintainers, because the synchronization among the maintainers can take 
weeks to finish the rebuild and release the update and automatic removal 
without notice (do excuse me if I missed a notification email about this - I 
have many filters and it could end up somewhere where I wasn't able to find it) 
prolongs this process.

What I would like to propose are the following options:

A) don't do side-tag cleanups after a specific time frame, but only when the 
specific event happens - branching, GA, EOL - it can be consuming to our 
resources, but maintainer are still able to remove the side tags manually in 
case it contains a big set of packages and AFAIK the process itself is not such 
spread in usage...

or

B) do a side-tags cleanup and mention it in the documentation together with 
specification what the removal's time frame is, so maintainers can act 
accordingly

or

C) (my preferred) Koji or releng (depends on whether the cleanup happened 
automatically or manually) will send an email to a side tag creator with 'Hi, 
your side tag is going to expire - do you need it?' Or with automaton - 'use 
this command to prolong it.' And if there is no response or if the creator 
approves, remove the side tag.



IMO basically side-tag is not expected to exist for such a long time, side-tag 
requester should
take effort to merge it into main buildroot within, say, one week at most.

Even when side-tag buildroot exists, of source main buildroot evolves at the 
same time,
and as soname bump on another library can happen for example, when side-tag 
merge gets delayed,
confusion is going to happen, e.g. R side-tag v.s. icu side-tag confusion which 
happened
about two months ago.

So if side-tag cannot be merged into main buildroot within some "reasonable" 
period
(I would expect within two weeks at most), I want side-tag requester to once 
dispose it.

If rebuilding depdening packages are not ready, please create copr repository 
first,
check if depending packages are ready, and if not file a ticket on bugzilla or 
so,
and when it is ready to rebuild, then create side-tag.

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

Re: openshadinglanguage failure on non x86_64

[Mamoru TASAKA]

Mamoru TASAKA wrote on 2022/10/10 10:09:

Luya Tshimbalanga wrote on 2022/10/10 2:46:

Hello team,

openshadinglanguage 1.12.6.2 only successfully built on x86_64 architecture but 
failed on others due to the following errors:

In file included from 
/builddir/build/BUILD/OpenShadingLanguage-1.12.6.2/src/liboslexec/oslexec_pvt.h:42,
  from 
/builddir/build/BUILD/OpenShadingLanguage-1.12.6.2/src/liboslexec/oslexec.cpp:12:
/builddir/build/BUILD/OpenShadingLanguage-1.12.6.2/src/include/OSL/mask.h:7:10: 
fatal error: immintrin.h: No such file or directory
 7 | #include 
   |  ^
compilation terminated.


That "immintrin.h" is provided by both gcc and clang according to "dnf -C repoquery 
--whatprovides */immintrin.h". Could someone investigate the cause and provide a patch?

See https://koji.fedoraproject.org/koji/taskinfo?taskID=92833862

Thanks in advance



Well, gcc immintrin.h is "/usr/lib/gcc/x86_64-redhat-linux/12/include/immintrin.h" (note 
that "x86_64-" path).

And clang immintrin.h "/usr/lib64/clang/15.0.0/include/immintrin.h" says:
--
#if !defined(__i386__) && !defined(__x86_64__)
#error "This header is only meant to be used on x86 and x64 architecture"
#endif
--

AFAIK immintrin.h is available only on x86 / x86_64.

Then as far as I looked at src/include/OSL/mask.h, it looks like actually this 
supports non-x86 architectures
(as I see #elif defined(__GNUC__) || defined(__clang__) or so),
so just try to guard the inclusion like

#if defined(__i386__) || defined(__x86_64__)
#include 
#endif

and see how it goes. Maybe some additional modification is needed, but for now 
I expect that
most things may go well.


Actually this guard makes build successful:
https://koji.fedoraproject.org/koji/taskinfo?taskID=92870693

Dan has proposed another fix in this thread, I think it should work well 
similarly.

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

Re: openshadinglanguage failure on non x86_64

[Mamoru TASAKA]

Luya Tshimbalanga wrote on 2022/10/10 2:46:

Hello team,

openshadinglanguage 1.12.6.2 only successfully built on x86_64 architecture but 
failed on others due to the following errors:

In file included from 
/builddir/build/BUILD/OpenShadingLanguage-1.12.6.2/src/liboslexec/oslexec_pvt.h:42,
  from 
/builddir/build/BUILD/OpenShadingLanguage-1.12.6.2/src/liboslexec/oslexec.cpp:12:
/builddir/build/BUILD/OpenShadingLanguage-1.12.6.2/src/include/OSL/mask.h:7:10: 
fatal error: immintrin.h: No such file or directory
     7 | #include 
   |  ^
compilation terminated.


That "immintrin.h" is provided by both gcc and clang according to "dnf -C repoquery 
--whatprovides */immintrin.h". Could someone investigate the cause and provide a patch?

See https://koji.fedoraproject.org/koji/taskinfo?taskID=92833862

Thanks in advance



Well, gcc immintrin.h is "/usr/lib/gcc/x86_64-redhat-linux/12/include/immintrin.h" (note 
that "x86_64-" path).

And clang immintrin.h "/usr/lib64/clang/15.0.0/include/immintrin.h" says:
--
#if !defined(__i386__) && !defined(__x86_64__)
#error "This header is only meant to be used on x86 and x64 architecture"
#endif
--

AFAIK immintrin.h is available only on x86 / x86_64.

Then as far as I looked at src/include/OSL/mask.h, it looks like actually this 
supports non-x86 architectures
(as I see #elif defined(__GNUC__) || defined(__clang__) or so),
so just try to guard the inclusion like

#if defined(__i386__) || defined(__x86_64__)
#include 
#endif

and see how it goes. Maybe some additional modification is needed, but for now 
I expect that
most things may go well.

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

Re: libharu soname bump for rawhide

[Mamoru TASAKA]

Orion Poplawski wrote on 2022/10/05 22:25:

On 10/5/22 07:11, Mamoru TASAKA wrote:

Dmitrij S. Kryzhevich wrote on 2022/10/05 18:02:

I understand the necessity of time to react, may be should handle it in a more 
proper way.
I was triggered by maintainer of only dependent package (directly dependent) so 
I strongly believe it's OK in this case.


Seems not actually:

dnf repoquery --repo=koji-38  --qf '%{sourcerpm}' --whatrequires 
"libhpdf.so.2.3*" | cat -n
  1    EMBOSS-6.6.0-22.fc38.src.rpm
  2    blender-3.3.0-4.fc38.src.rpm
  3    mathgl-2.4.4-18.fc38.src.rpm
  4    perl-PDF-Haru-1.00-38.fc37.src.rpm
  5    plplot-5.15.0-45.fc38.src.rpm
  6    saga-7.6.1-16.fc38.src.rpm
  7    vtk-9.1.0-17.fc37.src.rpm

Perhaps I am going to request untag for libharu-2.4.2-1.fc38.

Regards,
Mamoru



That works for me (maintainer of vtk and plplot) as I'm not quite ready to push 
vtk 9.2.2 out yet.  I didn't expect libharu to get built right away.

Orion



Now releng untagged this.
https://pagure.io/releng/issue/11070

(Just note that new libharu-2.4.2 has API changes compared with libharu-2.3.x)

Mamoru





On Wed, 5 Oct 2022 10:51:20 +0200
Fabio Valentini  wrote:


On Wed, Oct 5, 2022 at 9:24 AM Dmitrij S. Kryzhevich  wrote:


New version of libharu is building for rawhide with coresponding soname bump.
Only vtk should be affected right now.


I see that you have already built libharu-2.4.2-1.fc38.

Did you also handle rebuilding dependent packages, or should their
maintainers handle that themselves?
Usually there should be one week between such heads-up emails and
pushing the actual build, especially when you don't rebuild dependent
packages.

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

___
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




___
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: libharu soname bump for rawhide

[Mamoru TASAKA]

Dmitrij S. Kryzhevich wrote on 2022/10/05 18:02:

I understand the necessity of time to react, may be should handle it in a more 
proper way.
I was triggered by maintainer of only dependent package (directly dependent) so 
I strongly believe it's OK in this case.


Seems not actually:

dnf repoquery --repo=koji-38  --qf '%{sourcerpm}' --whatrequires 
"libhpdf.so.2.3*" | cat -n
 1  EMBOSS-6.6.0-22.fc38.src.rpm
 2  blender-3.3.0-4.fc38.src.rpm
 3  mathgl-2.4.4-18.fc38.src.rpm
 4  perl-PDF-Haru-1.00-38.fc37.src.rpm
 5  plplot-5.15.0-45.fc38.src.rpm
 6  saga-7.6.1-16.fc38.src.rpm
 7  vtk-9.1.0-17.fc37.src.rpm

Perhaps I am going to request untag for libharu-2.4.2-1.fc38.

Regards,
Mamoru




On Wed, 5 Oct 2022 10:51:20 +0200
Fabio Valentini  wrote:


On Wed, Oct 5, 2022 at 9:24 AM Dmitrij S. Kryzhevich  wrote:


New version of libharu is building for rawhide with coresponding soname bump.
Only vtk should be affected right now.


I see that you have already built libharu-2.4.2-1.fc38.

Did you also handle rebuilding dependent packages, or should their
maintainers handle that themselves?
Usually there should be one week between such heads-up emails and
pushing the actual build, especially when you don't rebuild dependent
packages.

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

___
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: libFLAC soname bump

[Mamoru TASAKA]

Miroslav Lichvar wrote on 2022/09/15 16:14:

On Wed, Sep 14, 2022 at 06:09:16PM -0500, Michel Alexandre Salim wrote:

I tried to rebuild them all except chromium which I suspect would take
too much space and time. Only ardour6, audacity, and xmms2 failed, for
unrelated reasons.


All the packages on your list except the 4 you listed in the paragraph
above should be built now, please check if anything is missing:

https://koji.fedoraproject.org/koji/builds?inherited=0=58420=-build_id=1


Thanks! It looks good to me.

I see that Mamoru rebuilt the three packages that failed for me
locally and also vlfrx-tools which I missed somehow. The only missing
package now seems to be chromium, which failed to build after last
update and it takes almost whole day to build, so I think we'll leave
that to its maintainer.


xmms2 was rebuilt with new flac without changes.

ardour6, audacity actually needed modification - due to that lv2 was
updated from 1.18.4 to 1.18.8 and with this update build method was
changed from waf to meson then some "compat" headers are removed.
I've added patches to detect new lv2 header paths (i.e. not related to
flac changes)



I submitted an update for the side tag:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-918429c97a



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

Re: Build failure on f37-x86_64, stdlib.h: No such file or directory

[Mamoru TASAKA]

Mamoru TASAKA wrote on 2022/09/05 8:40:

Bruno Postle wrote on 2022/09/04 17:44:

Can someone give me hint as to what I'm doing wrong here, I have a C++
package that builds fine for f35 & f36 with x86_64 & aarch64, but
which fails on f37-x86_64 (the build is ok on f37-aarch64):

https://copr.fedorainfracloud.org/coprs/bpostle/IfcOpenShell/build/4771106/

[  0%] Building CXX object
CMakeFiles/IfcParse.dir/builddir/build/BUILD/IfcOpenShell-0.7.0/src/ifcparse/IfcCharacterDecoder.cpp.o
/usr/bin/g++ -DBOOST_ALL_NO_LIB -DBOOST_DATE_TIME_DYN_LINK
-DBOOST_DATE_TIME_NO_LIB -DBOOST_IOSTREAMS_DYN_LINK
-DBOOST_IOSTREAMS_NO_LIB -DBOOST_PROGRAM_OPTIONS_DYN_LINK
-DBOOST_PROGRAM_OPTIONS_NO_LIB -DBOOST_REGEX_DYN_LINK
-DBOOST_REGEX_NO_LIB -DBOOST_SYSTEM_DYN_LINK -DBOOST_SYSTEM_NO_LIB
-DBOOST_THREAD_DYN_LINK -DBOOST_THREAD_NO_LIB -DHAS_SCHEMA_2x3
-DHAS_SCHEMA_4 -DHAS_SCHEMA_4x1 -DHAS_SCHEMA_4x2 -DHAS_SCHEMA_4x3
-DHAS_SCHEMA_4x3_rc1 -DHAS_SCHEMA_4x3_rc2 -DHAS_SCHEMA_4x3_rc3
-DHAS_SCHEMA_4x3_rc4 -DIFC_SHARED_BUILD -DIfcParse_EXPORTS
-DSCHEMA_SEQ="(2x3)(4)(4x1)(4x2)(4x3_rc1)(4x3_rc2)(4x3_rc3)(4x3_rc4)(4x3)"
-DUSE_MMAP -DWITH_GLTF -DWITH_HDF5 -DWITH_IFCXML -DWITH_OPENCOLLADA
-I/usr/include/opencascade -I/usr/include/COLLADABaseUtils
-I/usr/include/COLLADAStreamWriter -I/usr/include/libxml2 -isystem
/usr/include -lxml2 -DNDEBUG -O3 -fPIC   -Wall -Wextra
-Wno-maybe-uninitialized -Wno-deprecated-copy -fPIC
-DIFC_PARSE_EXPORTS -std=gnu++14 -MD -MT
CMakeFiles/IfcParse.dir/builddir/build/BUILD/IfcOpenShell-0.7.0/src/ifcparse/IfcCharacterDecoder.cpp.o
-MF 
CMakeFiles/IfcParse.dir/builddir/build/BUILD/IfcOpenShell-0.7.0/src/ifcparse/IfcCharacterDecoder.cpp.o.d
-o 
CMakeFiles/IfcParse.dir/builddir/build/BUILD/IfcOpenShell-0.7.0/src/ifcparse/IfcCharacterDecoder.cpp.o
-c /builddir/build/BUILD/IfcOpenShell-0.7.0/src/ifcparse/IfcCharacterDecoder.cpp
In file included from /usr/include/c++/12/ext/string_conversions.h:41,
  from /usr/include/c++/12/bits/basic_string.h:3960,
  from /usr/include/c++/12/string:53,
  from
/builddir/build/BUILD/IfcOpenShell-0.7.0/src/ifcparse/IfcCharacterDecoder.cpp:27:
/usr/include/c++/12/cstdlib:75:15: fatal error: stdlib.h: No such file
or directory
    75 | #include_next 
   |   ^~




This command line contains "-isystem /usr/include", on other architectures this 
is not included,
this is the difference. But currently I cannot figure out where this "-isystem 
/usr/include" came from.



So now I managed to get build successful:
https://copr.fedorainfracloud.org/coprs/mtasaka/IfcOpenShell-test/build/4812428/

Short answer:
In your IfcOpenShell.spec on %cmake line, ```-DCMAKE_CXX_FLAGS=-lxml2``` is 
wrong.
At least this should be changed to ```-DCMAKE_CXX_FLAGS="-lxml2 
%build_cxxflags"``` or so.
( but actually "-lxml2" should not be written in CMAKE_CXX_FLAGS, because this 
is for
  "compilation" flag, not for "linkage" option ).

Some long story trying to explain:

First of all f36 buildroot uses cmake-3.22.2, while f37 buildroot uses 
cmake-3.24.1, so
cmake behavior can differ between f36 and f37.

Then looking at build-live.log.gz, on aarch64:
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done

, while on x86_64 (this is both f37 and f36):
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - failed

and looking at redhat-linux-build/CMakeFiles/CMakeError.log (on x86_64), it 
says:

  1 Detecting CXX compiler ABI info failed to compile with the following 
output:
  6 Building CXX object CMakeFiles/cmTC_ce4df.dir/CMakeCXXCompilerABI.cpp.o
  7 /usr/bin/g++   -lxml2-v -o 
CMakeFiles/cmTC_ce4df.dir/CMakeCXXCompilerABI.cpp.o -c 
/usr/share/cmake/Modules/CMakeCXXCompilerABI.cpp
 45 Linking CXX executable cmTC_ce4df
 46 /usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_ce4df.dir/link.txt 
--verbose=1
 47 /usr/bin/g++ -lxml2  -Wl,-z,relro -Wl,--as-needed  -Wl,-z,now 
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -Wl,--build-id=sha1 
-specs=/usr/lib/rpm/redhat/redhat-package-notes -v -rdynamic 
CMakeFiles/cmTC_ce4df.dir/CMakeCXXCompilerABI.cpp.o -o cmTC_ce4df
 65 /usr/bin/ld: CMakeFiles/cmTC_ce4df.dir/CMakeCXXCompilerABI.cpp.o: 
relocation R_X86_64_32S against `.rodata' can not be used when making a PIE 
object; recompile with -fPIE
 66 /usr/bin/ld: failed to set dynamic section sizes: bad value
 67 collect2: error: ld returned 1 exit status

So here on linkage "-spec=/usr/lib/rpm/redhat/redhat-hardened-ld" is specified 
which uses -pie, while on compilation
the "correspoinding" option (-fpie or so, which is usually passed with 
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1

Re: Orphaned various packages (GNOME / GObject libraries)

[Mamoru TASAKA]

Fabio Valentini wrote on 2022/09/06 18:45:

Hi all,

Since the Pantheon desktop will not be available on Fedora 37+ for the
foreseeable future (libsoup3pocalypse etc.), I am no longer interested
in maintaining some of its dependencies or "shared" components that
are still used by existing applications and some other GObject
libraries, and have hence orphaned them:

- zeitgeist (Required-By: cairo-dock, gnome-activity-journal, synapse)



Taken.

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

Re: Build failure on f37-x86_64, stdlib.h: No such file or directory

[Mamoru TASAKA]

Bruno Postle wrote on 2022/09/04 17:44:

Can someone give me hint as to what I'm doing wrong here, I have a C++
package that builds fine for f35 & f36 with x86_64 & aarch64, but
which fails on f37-x86_64 (the build is ok on f37-aarch64):

https://copr.fedorainfracloud.org/coprs/bpostle/IfcOpenShell/build/4771106/

[  0%] Building CXX object
CMakeFiles/IfcParse.dir/builddir/build/BUILD/IfcOpenShell-0.7.0/src/ifcparse/IfcCharacterDecoder.cpp.o
/usr/bin/g++ -DBOOST_ALL_NO_LIB -DBOOST_DATE_TIME_DYN_LINK
-DBOOST_DATE_TIME_NO_LIB -DBOOST_IOSTREAMS_DYN_LINK
-DBOOST_IOSTREAMS_NO_LIB -DBOOST_PROGRAM_OPTIONS_DYN_LINK
-DBOOST_PROGRAM_OPTIONS_NO_LIB -DBOOST_REGEX_DYN_LINK
-DBOOST_REGEX_NO_LIB -DBOOST_SYSTEM_DYN_LINK -DBOOST_SYSTEM_NO_LIB
-DBOOST_THREAD_DYN_LINK -DBOOST_THREAD_NO_LIB -DHAS_SCHEMA_2x3
-DHAS_SCHEMA_4 -DHAS_SCHEMA_4x1 -DHAS_SCHEMA_4x2 -DHAS_SCHEMA_4x3
-DHAS_SCHEMA_4x3_rc1 -DHAS_SCHEMA_4x3_rc2 -DHAS_SCHEMA_4x3_rc3
-DHAS_SCHEMA_4x3_rc4 -DIFC_SHARED_BUILD -DIfcParse_EXPORTS
-DSCHEMA_SEQ="(2x3)(4)(4x1)(4x2)(4x3_rc1)(4x3_rc2)(4x3_rc3)(4x3_rc4)(4x3)"
-DUSE_MMAP -DWITH_GLTF -DWITH_HDF5 -DWITH_IFCXML -DWITH_OPENCOLLADA
-I/usr/include/opencascade -I/usr/include/COLLADABaseUtils
-I/usr/include/COLLADAStreamWriter -I/usr/include/libxml2 -isystem
/usr/include -lxml2 -DNDEBUG -O3 -fPIC   -Wall -Wextra
-Wno-maybe-uninitialized -Wno-deprecated-copy -fPIC
-DIFC_PARSE_EXPORTS -std=gnu++14 -MD -MT
CMakeFiles/IfcParse.dir/builddir/build/BUILD/IfcOpenShell-0.7.0/src/ifcparse/IfcCharacterDecoder.cpp.o
-MF 
CMakeFiles/IfcParse.dir/builddir/build/BUILD/IfcOpenShell-0.7.0/src/ifcparse/IfcCharacterDecoder.cpp.o.d
-o 
CMakeFiles/IfcParse.dir/builddir/build/BUILD/IfcOpenShell-0.7.0/src/ifcparse/IfcCharacterDecoder.cpp.o
-c /builddir/build/BUILD/IfcOpenShell-0.7.0/src/ifcparse/IfcCharacterDecoder.cpp
In file included from /usr/include/c++/12/ext/string_conversions.h:41,
  from /usr/include/c++/12/bits/basic_string.h:3960,
  from /usr/include/c++/12/string:53,
  from
/builddir/build/BUILD/IfcOpenShell-0.7.0/src/ifcparse/IfcCharacterDecoder.cpp:27:
/usr/include/c++/12/cstdlib:75:15: fatal error: stdlib.h: No such file
or directory
75 | #include_next 
   |   ^~




This command line contains "-isystem /usr/include", on other architectures this 
is not included,
this is the difference. But currently I cannot figure out where this "-isystem 
/usr/include" came from.

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

Re: gsl soversion bump

[Mamoru TASAKA]

Mamoru TASAKA wrote on 2022/08/23 16:58:

Kevin Fenzi wrote on 2022/08/23 10:12:

On Tue, Aug 23, 2022 at 09:23:51AM +0900, Mamoru TASAKA wrote:

Elliott Sales de Andrade wrote on 2022/08/23 5:54:

On Thu, Aug 11, 2022 at 12:08 PM Susi Lehtola
 wrote:


Hello,


gsl will be updated from version 2.6 to 2.7.1 which changes the
soversion from .25 to .27 in one week. List of dependent packages

$ for rpm in $(repoquery --disablerepo=* --enablerepo=rawhide
--whatrequires "libgsl.so.25()(64bit)"); do repoquery --disablerepo=*
--enablerepo=rawhide --source $rpm;done|sort|uniq



Did you just build directly in Rawhide after listing *61* packages
that would break from the update?
Please please use a side tag next time.



Untagging requested.
https://pagure.io/releng/issue/10984


Untagged. You can make a side tag and tag it into there...

kevin


Thank you for untagging.

Side tag created: f38-build-side-57264
https://koji.fedoraproject.org/koji/builds?inherited=0=57264=-build_id=1

Now I am trying to rebuild all depending packages mechanically..



Rebuilt with 1 pkg build failure, side tag is now goint to be merged into f38 
tree.
https://bodhi.fedoraproject.org/updates/FEDORA-2022-87a33f4948

Rebuilt:
 1  3Depict-0.0.22-13.fc38.src.rpm
 2  GoldenCheetah-3.6-0.21.RC2.fc38.src.rpm
 3  LabPlot-2.8.1-9.fc38.src.rpm
 4  R-gsl-2.1.7.1-2.fc38.src.rpm
 5  algol68g-3.0.3-4.fc38.src.rpm
 6  astrometry-0.89-4.fc38.src.rpm
 7  bcftools-1.15.1-2.fc38.src.rpm
 8  bogofilter-1.2.5-10.fc38.src.rpm
 9  calligra-3.2.1-20.fc38.src.rpm
10  cocoalib-0.99800-4.fc38.src.rpm
11  dieharder-3.31.1-33.fc38.src.rpm
12  enblend-4.2-24.fc38.src.rpm
13  espresso-4.2.0-4.fc38.src.rpm
14  freefem++-4.11-4.fc38.src.rpm
15  gambas3-3.17.3-3.fc38.src.rpm
16  gdl-1.0.1-9.fc38.src.rpm
17  getdp-3.5.0-4.fc38.src.rpm
18  giac-1.9.0.19-2.fc38.src.rpm
19  gnuradio-3.10.3.0-5.fc38.src.rpm
20  igt-gpu-tools-1.26-3.20220508gitcffa5ff.fc38.src.rpm
21  inkscape-1.2.1-4.fc38.src.rpm
22  ipe-7.2.26-3.fc38.src.rpm
23  krita-5.0.8-5.fc38.src.rpm
24  kst-2.0.8-39.fc38.src.rpm
25  kstars-3.5.9-4.fc38.src.rpm
26  libindi-1.9.7-2.fc38.src.rpm
27  luminance-hdr-2.6.1.1-48.fc38.src.rpm
28  mathgl-2.4.4-18.fc38.src.rpm
29  milia-1.0.0-35.fc38.src.rpm
30  mmseq-1.0.11-13.fc38.src.rpm
31  moose-3.1.5-15.fc38.src.rpm
32  morse2txt-1.0.0-35.fc38.src.rpm
33  mp-3.1.0-40.20200303git7fd4828.fc38.src.rpm
34  ncl-6.6.2-30.fc38.src.rpm
35  nco-5.1.0-4.fc38.src.rpm
36  nest-3.2-7.fc38.src.rpm
37  nip2-8.7.1-13.fc38.src.rpm
38  ocaml-gsl-1.19.1-43.fc38.src.rpm
39  octave-gsl-2.1.1-8.fc38.src.rpm
40  opengrm-ngram-1.3.14-4.fc38.src.rpm
41  orsa-0.7.0-58.fc38.src.rpm
42  perl-PDL-2.80.0-4.fc38.src.rpm
43  pfstools-2.2.0-6.fc38.src.rpm
44  player-3.1.0-43.fc38.src.rpm
45  pspp-1.6.2-3.fc38.src.rpm
46  pygsl-2.3.0-19.fc38.src.rpm
47  python-cvxopt-1.3.0-4.fc38.src.rpm
48  python-pynn-0.10.0-5.fc38.src.rpm
49  qgis-3.26.2-2.fc38.src.rpm
50  root-6.26.06-4.fc38.src.rpm
51  sagemath-9.6-5.fc38.src.rpm
52  scidavis-2.9.0-5.fc38.src.rpm
53  siril-1.0.3-3.fc38.src.rpm
54  sourcextractor++-0.18-3.fc38.src.rpm
55  stellarsolver-2.4-3.fc38.src.rpm
56  step-22.08.0-2.fc38.src.rpm
57  vfrnav-20201231-32.fc38.src.rpm
58  xaos-3.6-18.fc38.src.rpm
59  xsnow-3.5.1-2.fc38.src.rpm

With some modification for the below:

* nco  - Restrict BR: antlr and result binary ncap2 to %%java_arches
* nip2 - Avoid using bool keyword (was FTBFS since nip2-8.7.1-10.fc36)
* player - Change to BR: libphidget22-devel
   
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/43PW2O6ASEWBV4YN5ARGPAD33JUMQ4EY/
* vfrnav - Restrict BR: antlr to %%java_arches

Also, to rebuild sourcextractor++ , due to another reason not related to gsl,
rebuild of elements , elements-alexandria was needed.

Remainder : 1 package
1  asymptote-2.81-2.fc37.src.rpm
   https://koji.fedoraproject.org/koji/buildinfo?buildID=2050712
  - Previous asymptote build was successful, but now build fails also for f38.
Looks like pdfetex is segfaulting.

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

Re: gsl soversion bump

[Mamoru TASAKA]

Kevin Fenzi wrote on 2022/08/23 10:12:

On Tue, Aug 23, 2022 at 09:23:51AM +0900, Mamoru TASAKA wrote:

Elliott Sales de Andrade wrote on 2022/08/23 5:54:

On Thu, Aug 11, 2022 at 12:08 PM Susi Lehtola
 wrote:


Hello,


gsl will be updated from version 2.6 to 2.7.1 which changes the
soversion from .25 to .27 in one week. List of dependent packages

$ for rpm in $(repoquery --disablerepo=* --enablerepo=rawhide
--whatrequires "libgsl.so.25()(64bit)"); do repoquery --disablerepo=*
--enablerepo=rawhide --source $rpm;done|sort|uniq



Did you just build directly in Rawhide after listing *61* packages
that would break from the update?
Please please use a side tag next time.



Untagging requested.
https://pagure.io/releng/issue/10984


Untagged. You can make a side tag and tag it into there...

kevin


Thank you for untagging.

Side tag created: f38-build-side-57264
https://koji.fedoraproject.org/koji/builds?inherited=0=57264=-build_id=1

Now I am trying to rebuild all depending packages mechanically..

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

___
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: gsl soversion bump

[Mamoru TASAKA]

Elliott Sales de Andrade wrote on 2022/08/23 5:54:

On Thu, Aug 11, 2022 at 12:08 PM Susi Lehtola
 wrote:


Hello,


gsl will be updated from version 2.6 to 2.7.1 which changes the
soversion from .25 to .27 in one week. List of dependent packages

$ for rpm in $(repoquery --disablerepo=* --enablerepo=rawhide
--whatrequires "libgsl.so.25()(64bit)"); do repoquery --disablerepo=*
--enablerepo=rawhide --source $rpm;done|sort|uniq



Did you just build directly in Rawhide after listing *61* packages
that would break from the update?
Please please use a side tag next time.



Untagging requested.
https://pagure.io/releng/issue/10984

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

Re: Updating asio in rawhide (and possibly F37) to 1.24.0

[Mamoru TASAKA]

Julian Sikorski wrote on 2022/08/14 19:06:

Am 14.08.22 um 11:24 schrieb Julian Sikorski:

Dear maintainers,

I have updated Fedora asio package from the current 1.16.1 to 1.24.0. I have 
rebuilt the seven current dependencies and with the exception of 
OpenSceneGraph, all build fine against the updated asio package. While 
OpenSceneGraph failed to build, the failure does not seem to have to do 
anything with asio.
I have created a side tag so that the rebuilds can be coordinated: 
f38-build-side-56604. I do not have provenpacker privileges which means you 
have to request the rebuilds yourself. You can start once the asio build [1] 
finishes. Thank you for your cooperation in advance.

Best regards,
Julian

[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=90781633


asio-1.24.0-1.fc38 has now been built and is available in the side tag.



Well, asio{-devel} seems header (template) collection, no library, so
actually even without any rebuild, no dependency breakage will happen.

Nevertheless is it better that we rebuild all depending src.rpm?
( src.rpms with BuildRequires: asio-devel are only 7, so rebuilding them is
  not hard anyway.)

 1  OpenSceneGraph-0:3.6.5-10.fc37.src
 2  abiword-1:3.0.5-4.fc37.src
 3  freefem++-0:4.11-2.fc37.src
 4  galera-0:26.4.11-3.fc37.src
 5  hidviz-0:0.1.5-19.fc37.src
 6  hpx-0:1.8.1-1.fc37.src
 7  vdrift-0:20141020-27.git5ae309f.fc37.src



Best regards,
Julian


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

Re: [rawhide] ICU upgrade to 71.1

[Mamoru TASAKA]

Frantisek Zatloukal wrote on 2022/08/02 23:17:

Hmm,

I am really sorry for this, I'd messed up a lot somehow.

I'll take a deeper look tomorrow morning, but from a quick look:
- webkit is now being built against the new icu, passed on i686 of> 
architectures, it'll hopefully be done before the next compose.


So looks like the rebuild of webkit2gtk3 won't finish on s390x -
even after 51 hours:

https://koji.fedoraproject.org/koji/taskinfo?taskID=90394095

The above link says there are multiple buildroots. What does it mean?
s390x build is killed and repeated due to some specific issue on
s390x server?

Regards,
Mamoru



On Tue, Aug 2, 2022 at 4:04 PM Stephen Gallagher 
wrote:


On Mon, Aug 1, 2022 at 6:04 PM Frantisek Zatloukal 
wrote:




On Mon, Aug 1, 2022 at 7:46 PM Stephen Gallagher 

wrote:


On Mon, Aug 1, 2022 at 5:20 AM Frantisek Zatloukal 

wrote:


Hi,

Later today, I'll be starting with rebuilds of packages depending on

icu. The rebuilds will take place in f37-build-side-55935 for all packages
returned by sudo repoquery --whatrequires 'libicu*.so.69()(64bit)' (list
attached at the end of the message).


Please, if you're going to make changes in affected packages before

the side tag gets merged, make the build in the said side tag. I expect to
merge the side tag with most of the affected packages built and then
continue building things that take longer to build (webkit/libreoffice)
later.


For stuff that may fail to build, either due to newer icu or

unrelated issues, there is a libicu69 compat package already available in
rawhide, so that should take care of FTI issues that'd arise by merging the
side tag. I'll try to help the maintainers with fixing the issues.


I'll post updates to this thread as I progress with the bump.

[0]

...

v8



Yeah, I did a bunch of manual editing/checking up in the list, this

should actually be v8-314.


Apparently this side-tag has been merged and it broke a lot of stuff
in Rawhide/ELN:

2022-08-02 13:20:21 [ERROR   ] Dependency check failed:
2022-08-02 13:20:21 [ERROR   ]  Problem 1: package
anaconda-install-img-deps-37.11-2.eln120.ppc64le requires brltty, but
none of the providers can be installed
2022-08-02 13:20:21 [ERROR   ]   - conflicting requests
2022-08-02 13:20:21 [ERROR   ]   - nothing provides
libicuuc.so.69()(64bit) needed by brltty-6.5-4.eln120.ppc64le
2022-08-02 13:20:21 [ERROR   ]  Problem 2: package
anaconda-widgets-37.11-2.eln120.ppc64le requires
libgdk-3.so.0()(64bit), but none of the providers can be installed
2022-08-02 13:20:21 [ERROR   ]   - package
anaconda-widgets-37.11-2.eln120.ppc64le requires
libgtk-3.so.0()(64bit), but none of the providers can be installed
2022-08-02 13:20:21 [ERROR   ]   - package
gtk3-3.24.34-2.eln120.ppc64le requires
libtracker-sparql-3.0.so.0()(64bit), but none of the providers can be
installed
2022-08-02 13:20:21 [ERROR   ]   - conflicting requests
2022-08-02 13:20:21 [ERROR   ]   - nothing provides
libicui18n.so.69()(64bit) needed by
libtracker-sparql-3.4.0~alpha-3.eln121.ppc64le
2022-08-02 13:20:21 [ERROR   ]   - nothing provides
libicuuc.so.69()(64bit) needed by
libtracker-sparql-3.4.0~alpha-3.eln121.ppc64le
2022-08-02 13:20:21 [ERROR   ]  Problem 3: package
nm-connection-editor-1.28.0-2.eln120.ppc64le requires
libgdk-3.so.0()(64bit), but none of the providers can be installed
2022-08-02 13:20:21 [ERROR   ]   - package
nm-connection-editor-1.28.0-2.eln120.ppc64le requires
libgtk-3.so.0()(64bit), but none of the providers can be installed
2022-08-02 13:20:21 [ERROR   ]   - package
gtk3-3.24.34-2.eln120.ppc64le requires
libtracker-sparql-3.0.so.0()(64bit), but none of the providers can be
installed
2022-08-02 13:20:21 [ERROR   ]   - conflicting requests
2022-08-02 13:20:21 [ERROR   ]   - nothing provides
libicui18n.so.69()(64bit) needed by
libtracker-sparql-3.4.0~alpha-3.eln121.ppc64le
2022-08-02 13:20:21 [ERROR   ]   - nothing provides
libicuuc.so.69()(64bit) needed by
libtracker-sparql-3.4.0~alpha-3.eln121.ppc64le
2022-08-02 13:20:21 [ERROR   ]  Problem 4: package
anaconda-gui-37.11-2.eln120.ppc64le requires yelp, but none of the
providers can be installed
2022-08-02 13:20:21 [ERROR   ]   - package
anaconda-37.11-2.eln120.ppc64le requires anaconda-gui =
37.11-2.eln120, but none of the providers can be installed
2022-08-02 13:20:21 [ERROR   ]   - package
yelp-2:42.1-4.eln120.ppc64le requires libwebkit2gtk-4.1.so.0()(64bit),
but none of the providers can be installed
2022-08-02 13:20:21 [ERROR   ]   - conflicting requests
2022-08-02 13:20:21 [ERROR   ]   - nothing provides
libicui18n.so.69()(64bit) needed by
webkit2gtk4.1-2.37.1-11.fc37.ppc64le
2022-08-02 13:20:21 [ERROR   ]   - nothing provides
libicuuc.so.69()(64bit) needed by webkit2gtk4.1-2.37.1-11.fc37.ppc64le
2022-08-02 13:20:21 [ERROR   ]  Problem 5: package
mutter-43~alpha-2.eln120.ppc64le requires gtk3(ppc-64) >= 3.19.8, but
none of the providers can be installed
2022-08-02 13:20:21 [ERROR   ]   - package
mutter-43~alpha-2.eln120.ppc64le 

Re: List of long term FTBFS packages to be retired in August

[Mamoru TASAKA]

Miro Hrončok wrote on 2022/07/26 22:40:

On 26. 07. 22 15:07, Mamoru TASAKA wrote:

Miro Hrončok wrote on 2022/07/26 21:28:

Dear maintainers.

Based on the current fail to build from source policy, the following packages
will be retired from Fedora 37 approximately one week before branching (August 
2022).

Policy: 
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/

The packages in rawhide were not successfully built at least since Fedora 35.

This report is based on dist tags.

Packages collected via:
https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb

If you see a package that was built, please let me know.
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.

If you see a package that can be rebuilt, please do so.

  Package   (co)maintainers
=
rubygem-sprockets-rails  jaruga, pvalena, ruby-packagers-sig

Depending on: rubygem-sprockets-rails (22)
 rubygem-actionmailbox (maintained by: pvalena)
 rubygem-actionmailbox-7.0.2.3-2.fc37.src requires 
rubygem(sprockets-rails) = 3.2.2

 rubygem-activestorage (maintained by: ruby-packagers-sig, vondruch)
 rubygem-activestorage-7.0.2.3-1.fc37.src requires 
rubygem(sprockets-rails) = 3.2.2

 rubygem-railties (maintained by: mmorsi, pvalena, tdawson, vondruch)
 rubygem-railties-7.0.2.3-2.fc37.src requires rubygem(sprockets-rails) 
= 3.2.2

 rubygem-sassc-rails (maintained by: pvalena)
 rubygem-sassc-rails-2.1.2-4.fc36.noarch requires 
rubygem(sprockets-rails) = 3.2.2
 rubygem-sassc-rails-2.1.2-4.fc36.src requires rubygem(sprockets-rails) 
= 3.2.2
...



Can you show what changed for rubygem-sprockets-rails compared with
the previous report one week ago?

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/BEYCREMETV6DDVFMLKOE5HR2XWEWBPFE/

The above report seems to be saying that no package depends on 
rubygem-sprockets-rails,
but this time many packages depend on rubygem-sprockets-rails.


Only 4 packages directly require rubygem(sprockets-rails):

rubygem-actionmailbox
     rubygem-actionmailbox-7.0.2.3-2.fc37.src

rubygem-activestorage
     rubygem-activestorage-7.0.2.3-1.fc37.src

rubygem-railties
     rubygem-railties-7.0.2.3-2.fc37.src

rubygem-sassc-rails
     rubygem-sassc-rails-2.1.2-4.fc36.noarch
     rubygem-sassc-rails-2.1.2-4.fc36.src


I've checked and from the spec files, it seems that they always did.

I've repoqueried this compose 
https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20220719.n.0/ 
and it seems that the requirements were there.

The only difference, it seems, is that rubygem-image_processing was part of the 
FTBFS packages set before and its dep tree already included those packages, so 
the script decided not to report them twice :(

https://pagure.io/releng/blob/c9a08daa74/f/scripts/find_unblocked_orphans.py#_419

When I remove this thing, and re-add rubygem-image_processing to the list of 
FTBFS packages, I see rubygem-sprockets-rails's dependencies reported.

I guess we should fix the script, this is dangerous.

And if you think this justifies not retiring rubygem-sprockets-rails this 
round, I am OK with that.

Thanks for spotting this. No other remaining packages here seem to be affected 
by this now.



Okay, thank you for confirmation.

Anyway now I checked the upstream repo and the upstream already fixed build 
issue.
So I've backported the upstream fix and now build was successful as
rubygem-sprockets-rails-3.2.2-6.fc37 .

https://koji.fedoraproject.org/koji/buildinfo?buildID=2036386

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: List of long term FTBFS packages to be retired in August

[Mamoru TASAKA]

Miro Hrončok wrote on 2022/07/26 21:28:

Dear maintainers.

Based on the current fail to build from source policy, the following packages
will be retired from Fedora 37 approximately one week before branching (August 
2022).

Policy: 
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/

The packages in rawhide were not successfully built at least since Fedora 35.

This report is based on dist tags.

Packages collected via:
https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb

If you see a package that was built, please let me know.
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.

If you see a package that can be rebuilt, please do so.

  Package   (co)maintainers
=
rubygem-sprockets-rails  jaruga, pvalena, ruby-packagers-sig

Depending on: rubygem-sprockets-rails (22)
 rubygem-actionmailbox (maintained by: pvalena)
     rubygem-actionmailbox-7.0.2.3-2.fc37.src requires 
rubygem(sprockets-rails) = 3.2.2

 rubygem-activestorage (maintained by: ruby-packagers-sig, vondruch)
     rubygem-activestorage-7.0.2.3-1.fc37.src requires 
rubygem(sprockets-rails) = 3.2.2

 rubygem-railties (maintained by: mmorsi, pvalena, tdawson, vondruch)
     rubygem-railties-7.0.2.3-2.fc37.src requires rubygem(sprockets-rails) 
= 3.2.2

 rubygem-sassc-rails (maintained by: pvalena)
     rubygem-sassc-rails-2.1.2-4.fc36.noarch requires 
rubygem(sprockets-rails) = 3.2.2
     rubygem-sassc-rails-2.1.2-4.fc36.src requires rubygem(sprockets-rails) 
= 3.2.2

 rubygem-rails (maintained by: jstribny, kanarip, mmorsi, mtasaka, pvalena, 
ruby-packagers-sig, sseago, tdawson, vondruch)
     rubygem-rails-1:7.0.2.3-2.fc37.noarch requires rubygem(actionmailbox) 
= 7.0.2.3

 rubygem-rspec-rails (maintained by: clalance, vondruch)
     rubygem-rspec-rails-5.1.1-2.fc37.src requires rubygem(actionmailbox) = 
7.0.2.3

 rubygem-actiontext (maintained by: pvalena)
     rubygem-actiontext-7.0.2.3-2.fc37.noarch requires 
rubygem(activestorage) = 7.0.2.3
     rubygem-actiontext-7.0.2.3-2.fc37.src requires rubygem(activestorage) 
= 7.0.2.3

 rubygem-actionpack (maintained by: jaruga, jstribny, kanarip, mmorsi, 
pvalena, ruby-packagers-sig, sseago, vondruch)
     rubygem-actionpack-1:7.0.2.3-1.fc37.src requires rubygem(railties) = 
7.0.2.3

 rubygem-actionview (maintained by: jaruga, pvalena, ruby-packagers-sig)
     rubygem-actionview-7.0.2.3-1.fc37.src requires rubygem(railties) = 
7.0.2.3

 rubygem-activemodel (maintained by: jstribny, mmorsi, pvalena, tdawson, 
vondruch)
     rubygem-activemodel-7.0.2.3-2.fc37.src requires rubygem(railties) = 
7.0.2.3

 rubygem-ammeter (maintained by: jstribny, ruby-packagers-sig, vondruch)
     rubygem-ammeter-1.1.5-3.fc37.noarch requires rubygem(railties) = 
7.0.2.3
     rubygem-ammeter-1.1.5-3.fc37.src requires rubygem(railties) = 7.0.2.3

 rubygem-font-awesome-rails (maintained by: abradshaw, ckyriakidou, evgeni, 
fale, snecker)
     rubygem-font-awesome-rails-4.7.0.8-2.fc37.noarch requires 
rubygem(railties) = 7.0.2.3
     rubygem-font-awesome-rails-4.7.0.8-2.fc37.src requires 
rubygem(railties) = 7.0.2.3

 rubygem-generator_spec (maintained by: ilgrad)
     rubygem-generator_spec-0.9.4-12.fc37.noarch requires rubygem(railties) 
= 7.0.2.3
     rubygem-generator_spec-0.9.4-12.fc37.src requires rubygem(railties) = 
7.0.2.3

 rubygem-globalid (maintained by: jaruga, pvalena, ruby-packagers-sig)
     rubygem-globalid-1.0.0-3.fc37.src requires rubygem(railties) = 7.0.2.3

 rubygem-haml (maintained by: kanarip, pvalena)
     rubygem-haml-5.2.2-3.fc37.src requires rubygem(railties) = 7.0.2.3

 rubygem-importmap-rails (maintained by: pvalena)
     rubygem-importmap-rails-1.0.3-2.fc37.noarch requires rubygem(railties) 
= 7.0.2.3

 rubygem-jbuilder (maintained by: pvalena, vondruch)
     rubygem-jbuilder-2.11.5-2.fc37.src requires rubygem(railties) = 7.0.2.3

 rubygem-jquery-rails (maintained by: jstribny, tdawson, vondruch)
     rubygem-jquery-rails-4.4.0-3.fc37.noarch requires rubygem(railties) = 
7.0.2.3

 rubygem-rails-controller-testing (maintained by: valtri)
     rubygem-rails-controller-testing-1.0.5-6.fc37.src requires 
rubygem(railties) = 7.0.2.3

 rubygem-sass-twitter-bootstrap (maintained by: tdawson)
     rubygem-sass-twitter-bootstrap-2.3.0-16.fc37.noarch requires 
rubygem(railties) = 7.0.2.3

 rubygem-slim (maintained by: vondruch)
     rubygem-slim-4.1.0-6.fc37.src requires rubygem(railties) = 7.0.2.3

 rubygem-web-console (maintained by: jaruga, ruby-packagers-sig, vondruch)
     rubygem-web-console-4.1.0-4.fc36.noarch requires 

Re: Retiring the pcre package from Fedora

[Mamoru TASAKA]

Kalev Lember wrote on 2022/07/25 0:45:

On Sun, Jul 24, 2022 at 4:45 PM Mamoru TASAKA 
wrote:


Kalev Lember wrote on 2022/07/24 22:42:

glib2 switched to pcre2 in rawhide recently. Can you check if qemu needs

to

be updated for that now so that it BuildRequires pcre2-static instead?



https://src.fedoraproject.org/rpms/glib2/c/34b203d5499b579c68b4f923a29fd417efdd9637?branch=rawhide




Ah... maybe due to this?

A.
On mass-rebuid, rubygem-glib2 (which is a wrapper to glib2 for ruby
language) sees
test failure with regards to "g_regex_match_all" - note that this is s390x
only.

https://koji.fedoraproject.org/koji/taskinfo?taskID=89955927

B.
I got lxrandr behavior regression on rawhide:
https://bugzilla.redhat.com/show_bug.cgi?id=2109187

- what lxrandr does here is lxrander gets the result of "xrandr" and
passes it to "g_regex_match".
On F-36 actually "g_regex_match" matches but (while I have not tried
yet)
what bug reporter says must be that "g_regex_match" now fails with
rawhide glib2 (this is happening on x86_64).

I will recheck this tomorrow.



Those both sound a lot like regressions in g_regex_match() to me. If you
have time, any chance you could create smaller reproducers and file issues
for these upstream at https://gitlab.gnome.org/GNOME/glib ?
 
For issue A: reported (with smallest reproducer): https://gitlab.gnome.org/GNOME/glib/-/issues/2699


Now I will recheck issue B (maybe tomorrow...)

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Retiring the pcre package from Fedora

[Mamoru TASAKA]

Kalev Lember wrote on 2022/07/24 22:42:

On Sun, Jul 24, 2022 at 8:58 AM Paolo Bonzini  wrote:





glib2 switched to pcre2 in rawhide recently. Can you check if qemu needs to
be updated for that now so that it BuildRequires pcre2-static instead?

https://src.fedoraproject.org/rpms/glib2/c/34b203d5499b579c68b4f923a29fd417efdd9637?branch=rawhide



Ah... maybe due to this?

A.
On mass-rebuid, rubygem-glib2 (which is a wrapper to glib2 for ruby language) 
sees
test failure with regards to "g_regex_match_all" - note that this is s390x only.

https://koji.fedoraproject.org/koji/taskinfo?taskID=89955927

B.
I got lxrandr behavior regression on rawhide:
https://bugzilla.redhat.com/show_bug.cgi?id=2109187

- what lxrandr does here is lxrander gets the result of "xrandr" and
  passes it to "g_regex_match".
  On F-36 actually "g_regex_match" matches but (while I have not tried yet)
  what bug reporter says must be that "g_regex_match" now fails with
  rawhide glib2 (this is happening on x86_64).

I will recheck this tomorrow.

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora 37 mass rebuild started

[Mamoru TASAKA]

Richard Shaw wrote on 2022/07/21 10:52:

Looking at brasero I can build "fine" doing a fedpkg mockbuild but adding
"--enablerepo=local" replicates the failure seen in koji[1].

I tried comparing the root logs between the two to see what's different but
I don't find the results particularly helpful:

lua-libs-5.4.4-3.fc37.x86_64 vs lua-libs-5.4.4-2.fc37.x86_64
setup-2.14.1-1.fc37.noarch vs setup-2.13.10-1.fc37.noarch
python-srpm-macros-3.11-3.fc37.noarch vs
python-srpm-macros-3.11-1.fc37.noarch

The error messages themselves seem like something that should have been
caught some time ago (not just newer gcc error checking).

Any ideas?

Thanks,
Richard
[1] https://kojipkgs.fedoraproject.org//work/tasks/7772/89767772/build.log




Would you check what "nautilus" is used when build of brasero gets fine?
koji says "nautilus" goes 42.2 -> 43~alpha, with switching gtk3 -> gtk4.

And brasero seems to be compiling with gtk3, but when compiling 
nautilus-burn-extension.c
in brasero, it tries to include gtk4 header, while successful build
(on eln: https://koji.fedoraproject.org/koji/buildinfo?buildID=1992598)
tries to include gtk3 header when compiling nautilus-burn-extension.c .

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Announcing fmt library soversion bump

[Mamoru TASAKA]

Vitaly Zaitsev via devel wrote on 2022/07/11 2:43:

Hello.

fmt 9.0.x update will include a soversion bump from .8 to .9. It has both API 
and ABI changes.

Changelog: https://github.com/fmtlib/fmt/releases/tag/9.0.0

The list of affected packages in Rawhide:
0ad
OpenImageIO
cantera
ceph
dolphin-emu
domoticz
folly
libsonata
mkvtoolnix
sdrpp
spdlog
vcpkg
zswap-cli

I can rebuild only spdlog, vcpkg and zswap-cli. For others, I will need 
proven-packagers assistance.

Please use the f37-build-side-54844 side tag. I will merge it into Rawhide 
later.



So current status update for fmt-9 change on rawhide tree:

33 pkgs are now using fmt-9 (built successfully with some modification) on 
rawhide tree
(cryfs is still building, however it will succeed as scratch build was already 
okay).

Only 1 package still uses fmt8 - 0ad .
0ad FTBFS on f37 due to different issue from fmt change - scratch build for 
F-37 shows virtualenv related
issue - perhaps due to python3.11 changes, and scratch build for F-36 shows 
some rust(?) related error,
which is beyond my knowledge currently.
Note that rawhide 0ad currently linked against boost1.76 - while rawhide boost 
is already 1.78,
so 0ad is FTI even if fmt8 package is introduced anyway currently.

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Announcing fmt library soversion bump

[Mamoru TASAKA]

Vitaly Zaitsev via devel wrote on 2022/07/19 18:31:

On 19/07/2022 01:28, Miro Hrončok wrote:

I see https://bodhi.fedoraproject.org/updates/FEDORA-2022-ee990d1f61 was pushed 
with just a handful of builds, while many others are broken. What happened here?


Maintainers had 1 week to rebuild all their packages. Most did nothing. Blame 
them, not me.

I did my best: announced it in ML, waited 1 week, asked for the provenpackager 
assistance multiple times both in ML and IRC/Matrix. No one volunteered to help 
me.



So far I am doing my best to fix this breakage. Now I've fixed 5 of these.
Currently as far as I am correct 15 pkgs are still broken - I am slowly looking 
at these.

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: List of long term FTBFS packages to be retired in August

[Mamoru TASAKA]

Ewoud Kohl van Wijngaarden wrote on 2022/07/19 16:58:

On Tue, Jul 19, 2022 at 09:48:33AM +0200, Vít Ondruch wrote:

Dear Ewoud,


Dne 12. 07. 22 v 15:16 Ewoud Kohl van Wijngaarden napsal(a):

On Tue, Jul 12, 2022 at 01:03:59PM +0200, Miro Hrončok wrote:

rubygem-bundler_ext    jaruga, ruby-packagers-sig, vondruch


I have an interest in this package so I started to look into this. It mostly 
comes down to porting to rspec 3 which I have passing.

https://github.com/bundlerext/bundler_ext/pull/23 is the upstream PR, I'll look 
into a packaging PR too.



Would you mind to take over the package from me? I inherited the package from 
previous maintainer together with other packages and I was never doing the 
right job maintaining it, mainly because I am not user of the package.


I'd be happy to take it over.


BTW are you working on this FTBFS? For now I've added minimum patches to make 
rubygem-bundler_ext rpm
build (with porting to rspec3) and I can commit these changes myself.

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Announcing fmt library soversion bump

[Mamoru TASAKA]

Ben Beasley wrote on 2022/07/12 1:50:

Two of the three packages I tried to rebuild (bear and fmidi) failed with 
errors like:

/usr/include/fmt/core.h:1733:7: error: static assertion failed: Cannot format an 
argument. To make type T formattable provide a formatter 
specialization:https://fmt.dev/latest/api.html#udt
  1733 |   formattable,
   |   ^~~

Links to failing scratch builds in the side tag:

    https://koji.fedoraproject.org/koji/taskinfo?taskID=89380682

    https://koji.fedoraproject.org/koji/taskinfo?taskID=89380736

I found that there was already a bug report open upstream for Bear: 
https://github.com/rizsotto/Bear/issues/471

If that FTBFS rate is typical of the full set of affected packages, then 
merging the side tag without resolving the API incompatibilities in dependent 
packages will be pretty disruptive to Rawhide as a whole.

Would you consider setting up a COPR to figure out how many packages are 
affected by the API changes, and filing Bugzillas on the affected dependent 
packages? It might take a while for affected package maintainers to become 
aware of the problem, investigate, and perhaps work with upstreams to prepare 
the necessary patches.

Link to fmt 9.0.0 release notes: 
https://github.com/fmtlib/fmt/releases/tag/9.0.0



So instead I tried copr build: currently as far as I am correct
currently 29 packages needs rebuilding:

 1  0ad-0.0.25b-2.fc36.src.rpm
 2  cachelib-16^20220314gitbd22b0e-1.fc37.src.rpm
 3  cantera-2.6.0-26.fc37.src.rpm
 4  ceph-17.2.1-4.fc37.src.rpm
 5  coeurl-0.2.0-2.fc37.src.rpm
 6  cryfs-0.11.2-3.fc37.src.rpm
 7  dolphin-emu-5.0.16380-2.fc37.src.rpm
 8  easyeffects-6.2.6-1.fc37.src.rpm
 9  easyrpg-player-0.7.0-2.fc36.src.rpm
10  fb303-2022.03.14.00-1.fc37.src.rpm
11  fbthrift-2022.03.14.00-1.fc37.src.rpm
12  fizz-2022.03.14.00-1.fc37.src.rpm
13  folly-2022.03.14.00-1.fc37.src.rpm
14  freeopcua-0-0.23.20200131.da2b76f.fc37.src.rpm
15  gerbera-1.11.0-1.fc37.src.rpm
16  gnuradio-3.10.3.0-1.fc37.src.rpm
17  gr-funcube-1.0.0-14.20220130gitbf71b979.fc37.src.rpm
18  libsemigroups-2.2.0-1.fc37.src.rpm
19  luxcorerender-2.6-1.fc37.src.rpm
20  mangohud-0.6.7.1-2.fc37.src.rpm
21  mcrouter-0.41.0.20220314-1.fc37.src.rpm
22  nheko-0.9.3-2.fc37.src.rpm
23  proxygen-2022.03.14.00-2.fc37.src.rpm
24  rstudio-2022.07.0+548-1.fc37.src.rpm
25  sdrpp-1.0.4-6.fc37.src.rpm
26  vcpkg-2022.06.15-1.fc37.src.rpm
27  wangle-2022.03.14.00-1.fc37.src.rpm
28  watchman-2021.05.10.00-13.fc37.src.rpm
29  waybar-0.9.13-1.fc37.src.rpm

and the first try for rebuilding theese pkgs for fmt-9 is 
rather sad: only 7 pkgs succeeded.
(Note that I have not checked the reason of rebuild failure
 for each pkg yet.)

https://copr.fedorainfracloud.org/coprs/mtasaka/fmt9-test/builds/

So what should we do? Now the timing is rather critical because
mass rebuild for F37 is planned at 2022-07-20, which will rebuild fmt-9
on rawhide tree anyway, which will cause rawhide tree breakage.

To avoid this, should fmt rawhide branch be reverted for now, or
"noautobuild" file should be added to avoid rebuild for fmt
(if noautobuild file still works)?


Note: some pkgs depends on folly, which cannot be even installed on rawhide,
and FTBFS even for rawhide, and now I am looking at this first.

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Archive value is out of time_t range

[Mamoru TASAKA]

Antonio T. sagitter wrote on 2022/06/02 23:33:

Hi all.

rpmuncompress is failing in Rawhide i686 architecture only with:

/usr/bin/tar: Archive value 4027676192 is out of time_t range 
-2147483648..2147483647
/usr/bin/tar: 
icecat-91.10.0/extensions/gnu/jid1-KtlZuoiikVfFew@jetpack/bundle.js: 
implausibly old time stamp 1969-12-31 23:59:59
...
(https://kojipkgs.fedoraproject.org//work/tasks/1685/87811685/build.log)

If it was an archive issue, it should happen in all architectures.
Anyone know why this occurs?

Best,



Perhaps it is 32 bit architecture. Actually:

[tasaka1@localhost icecat-91.10.0]$ ls -al 
extensions/gnu/jid1-KtlZuoiikVfFew@jetpack/bundle.js
-rw-r--r--. 1 tasaka1 tasaka1 433208 Jul 29  2114 
extensions/gnu/jid1-KtlZuoiikVfFew@jetpack/bundle.js

This is above year 2038. (Anyway the timestamp on this file seems strange.)

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Heads up: openjpeg2-2.5.0 and gdal-3.5.0 coming to rawhide

[Mamoru TASAKA]

Sandro Mani wrote on 2022/05/23 3:39:

Hi

- gazebo fails to build due to "cannot convert 'ALCdevice*' to 'ALCdevice_struct*' 
in assignment", which looks like an openal-soft-1.21 incompatibility. Possibly 
updating gazebo from the currently packaged v10.1.0 to current upstream version 11.10.2 
might help.


Fixed by backporting upstream patch:
https://src.fedoraproject.org/rpms/gazebo/c/9b045b25a1c310648bc3158cadc4dab967bf4c6a

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Static library linking error

[Mamoru TASAKA]

Richard Shaw wrote on 2022/05/10 12:07:

I'm working on some IIoT related packages in my COPR where I have a dynamic
library linking to a static library and getting the following error:



/usr/bin/ld:
/usr/lib/gcc/x86_64-redhat-linux/12/../../../../lib64/libmqttc.a(mqtt.c.o):
warning: relocation against `mqtt_fixed_header_rules' in read-only section
`.text'
/usr/bin/ld:
/usr/lib/gcc/x86_64-redhat-linux/12/../../../../lib64/libmqttc.a(mqtt.c.o):
relocation R_X86_64_PC32 against symbol `mqtt_fixed_header_rules' can not
be used when making a shared object; recompile with -fPIC

I added the following to the libmqttc library and verified -fPIC -pie is in
the build flags[1] per the recommendation from the hardening page[2] but
the error remains.

Any ideas?

Thanks,
Richard

[1]
https://download.copr.fedorainfracloud.org/results/hobbes1069/IIoT/fedora-rawhide-x86_64/04386803-mqtt-c/builder-live.log.gz


This log no longer seems to exist.


[2] https://fedoraproject.org/wiki/Changes/Harden_All_Packages



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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: libgps soname bump (gpsd-3.24)

[Mamoru TASAKA]

Miroslav Lichvar wrote on 2022/05/05 0:46:

libgps from the gpsd package had an API and ABI break. As usual, the
following packages need to be rebuilt:

collectd
direwolf
foxtrotgps
marble
plasma-workspace
vfrnav
viking

I tried to rebuild them locally. It seems only direwolf needs a new
patch. The direwolf-gpsapi12 patch needs to be replaced with
https://fedorapeople.org/~mlichvar/tmp/gpsd/direwolf-gpsapi14.patch

The new gpsd package has been built in f37-build-side-53409.

Could a proven packager please replace the patch and rebuild the
dependant packages in this side tag?


All rebuilt (direwolf rebuild was by Richard).
https://koji.fedoraproject.org/koji/builds?inherited=0=53409=-build_id=1

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: boinc-client build failure on non x86 architectures F>35

[Mamoru TASAKA]

Germano Massullo wrote on 2022/04/10 22:37:

Thank you very much Mamoru! Why don't you submit your patch to upstream 
repository, so you get the credit? We will need to patch such thing upstream 
anyways!


Now submitted:
https://github.com/BOINC/boinc/pull/4737

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: boinc-client build failure on non x86 architectures F>35

[Mamoru TASAKA]

Germano Massullo wrote on 2022/04/10 7:38:

Hello, on Fedora > 35 I am experiencing build failures on boinc-client on non 
x86 architectures. I do not understand the reason
https://koji.fedoraproject.org/koji/taskinfo?taskID=85413241

F35 instead builds correctly
https://koji.fedoraproject.org/koji/taskinfo?taskID=85413347

Thank you


https://github.com/BOINC/boinc/blame/b49adfb118211e11c719766c0d71e7bdfe7f3363/configure.ac#L697
https://github.com/BOINC/boinc/blame/b49adfb118211e11c719766c0d71e7bdfe7f3363/configure.ac#L700

F-35 uses autoconf 2.69, F-36 uses autoconf 2.71.

Now autoconf 2.71 [AC_CHECK_DECL] macro calls new internal macro 
[_AC_UNDECLARED_BUILTIN]
which now raises error with "-mavx" on non-x86 arches.
From config.log on s390x:

configure:35618: checking for gcc options needed to detect all undeclared 
functions
configure:35640: gcc -c -O2 -flto=auto -ffat-lto-objects -fexceptions -g 
-grecord-gcc-switches -pipe -Wall -Werror=format-security 
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -spe
cs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 -march=zEC12 -mtune=z13 
-fasynchronous-unwind-tables -fstack-clas
h-protection -Wall-mavx conftest.c >&5
cc1: error: unrecognized command-line option '-mavx'
configure:35640: $? = 1
.
.
configure:35684: result: cannot detect
configure:35688: error: in 
`/builddir/build/BUILD/boinc-client_release-7.18-7.18.1':
configure:35690: error: cannot make gcc report undeclared builtins
See `config.log' for more details

Possible solution is to check if compiler (target) supports -msse3 and -mavx 
first, and
it they are not supported, don't pass them to CPPFLAGS on AC_CHECK_DECL, 
something like:

==
--- boinc-client_release-7.18-7.18.1/configure.ac.link  2021-08-04 
00:52:19.0 +0900
+++ boinc-client_release-7.18-7.18.1/configure.ac   2022-04-10 
12:35:30.403301691 +0900
@@ -690,11 +690,19 @@ AC_CHECK_HEADERS([sys/types.h sys/un.h a
 
 save_cxxflags="${CXXFLAGS}"

 save_cppflags="${CPPFLAGS}"
-CXXFLAGS="${CXXFLAGS} -msse3"
-CPPFLAGS="${CPPFLAGS} -msse3"
+sse3_flags="-msse3"
+avx_flags="-mavx"
+CXXFLAGS="${save_cxxflags} ${sse3_flags}"
+CPPFLAGS="${save_cppflags} ${sse3_flags}"
+AC_LINK_IFELSE([AC_LANG_PROGRAM([],)], [], [sse_flags=""])
+CXXFLAGS="${save_cxxflags} ${avx_flags}"
+CPPFLAGS="${save_cppflags} ${avx_flags}"
+AC_LINK_IFELSE([AC_LANG_PROGRAM([],)], [], [avx_flags=""])
+CXXFLAGS="${save_cxxflags} ${sse3_flags}"
+CXXFLAGS="${save_cxxflags} ${sse3_flags}"
 AC_CHECK_HEADERS([intrin.h x86intrin.h pmmintrin.h xmmintrin.h emmintrin.h])
-CXXFLAGS="${save_cxxflags} -mavx"
-CPPFLAGS="${save_cppflags} -mavx"
+CXXFLAGS="${save_cxxflags} ${avx_flags}"
+CPPFLAGS="${save_cppflags} ${avx_flags}"
 AC_CHECK_HEADERS([immintrin.h avxintrin.h])
 
 AC_CHECK_DECLS([_xgetbv, xgetbv, __xgetbv, cpuid, _cpuid, __cpuid],

==

With the above patch:
https://koji.fedoraproject.org/koji/taskinfo?taskID=85422586

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Dropping wine from ARM

[Mamoru TASAKA]

Michael Cronenworth wrote on 2022/03/31 20:56:

On 3/30/22 11:04 PM, Tom Stellard wrote:

$ x86_64-w64-mingw32-gcc -c test.c -v
.. snip ..
#include <...> search starts here:
  /usr/lib/gcc/x86_64-w64-mingw32/11.2.1/include
  /usr/lib/gcc/x86_64-w64-mingw32/11.2.1/include-fixed


This path is the Fedora MinGW path:

  /usr/x86_64-w64-mingw32/sys-root/mingw/include



End of search list.

Clang apparently has no idea where MinGW files in Fedora live. :(

$ clang -c test.c -target x86_64-windows -v


Try using -target x86_64-w64-mingw32 to match gcc. 


Doesn't help.

$ clang -target x86_64-w64-mingw32 test.c -v
.. snip ..
#include <...> search starts here:
  /usr/lib64/clang/13.0.0/include
  /usr/include
End of search list.

The "/usr/include" path is a terrible choice. Time to open a bug report?


Actually it seems --target=foo, not -target foo

$ echo | clang --sysroot=/usr --target=x86_64-w64-mingw32 -v -E -
clang version 13.0.1 (Fedora 13.0.1-1.fc36)
Target: x86_64-w64-windows-gnu
Thread model: posix
InstalledDir: /bin
 (in-process)

clang -cc1 version 13.0.1 based upon LLVM 13.0.1 default target 
x86_64-redhat-linux-gnu
ignoring nonexistent directory "/usr/x86_64-w64-mingw32/sys-root/mingw/include"
ignoring nonexistent directory "/usr/x86_64-w64-mingw32/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib64/clang/13.0.1/include
 /usr/include
End of search list.
# 1 ""
# 1 "" 1
# 1 "" 3
# 361 "" 3
# 1 "" 1
# 1 "" 2
# 1 "" 2
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Dropping wine from ARM

[Mamoru TASAKA]

Michael Cronenworth wrote on 2022/03/31 1:25:

On 3/30/22 8:51 AM, Michael Cronenworth wrote:

On 3/30/22 8:42 AM, Neal Gompa wrote:

That sounds like a bug in the package, because our LLVM build has all
targets enabled on Fedora:
https://src.fedoraproject.org/rpms/llvm/blob/rawhide/f/llvm.spec#_51-52


OK, bug filed.

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


After finding out I'm LLVM-ignorant I added a BR for the LLVM linker to wine to 
resolve the configure test issue.

The build[1] now fails in a post-compile LLVM rpm script.

/usr/lib/rpm/redhat/brp-llvm-compile-lto-elf -O2 -fexceptions -g 
-grecord-gcc-switches -pipe -Wall -Werror=format-security 
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -mbranch-protection=standard 
-fasynchronous-unwind-tables -Wl,-z,relro -Wl,--as-needed -Wl,--build-id=sha1 
-Wl,-dT,/builddir/build/BUILD/wine-7.5/.package_note-wine-7.5-1.fc37.aarch64.ld
Checking for LLVM bitcode artifacts
Unpacking ar archive 
/builddir/build/BUILDROOT/wine-7.5-1.fc37.aarch64/usr/lib64/wine/aarch64-windows/libdbghelp.a
 to check for LLVM bitcode components.
/tmp/tmp.HfhQjpRaux ~/build/BUILD/wine-7.5
Repacking ./dbghelp.dll into 
/builddir/build/BUILDROOT/wine-7.5-1.fc37.aarch64/usr/lib64/wine/aarch64-windows/libdbghelp.a.
/usr/lib/rpm/redhat/brp-llvm-compile-lto-elf: line 34: 569514 Segmentation 
fault  (core dumped) ar r ${archive} ${archived_file}

Who is at fault? Binutils? LLVM?

[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=84939948


ar is failing so the fault is in binutils at the first look.

By the way:
- First of all, should /usr/lib64/wine/aarch64-windows/libdbghelp.a (or any 
other static archive) be packed
  (i.e. are static archives needed in wine binary rpm)?
  If not, just remove static archives.
- If needed, AFAIK brp-llvm-compile-lto-elf is needed when compiled by clang 
with -flto, so
  as a workaround, I think
  - adding "%global _lto_cflags %nil"
  - and adding "%global __brp_llvm_compile_lto_elf %nil"
  should work here.

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Problem compiling tellico in F37 (linker stage)

[Mamoru TASAKA]

Vitaly Zaitsev via devel wrote on 2022/03/24 17:52:

On 23/03/2022 20:10, José Abílio Matos wrote:

This fails in x86* and arm64 and succeeds in ppc64le and x390x:



I have the same issue with ghostwriter package (Koschei scratch build):
https://koji.fedoraproject.org/koji/taskinfo?taskID=8462258

Previous build on F37 was successful:
https://koji.fedoraproject.org/koji/taskinfo?taskID=84152850


This uses binutils 2.37-24.fc36





At least for both tellico and ghostwriter cases, I tried mockbuild and
just downgrading binutils / binutils-gold to 2.37-24.fc36.x86_64 makes linkage
succeed, so for now I filed against binutils:

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

(Currently rawhide uses binutils-2.38-6.fc37)

I have not tried luminance-hdr case yet.

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Package downgrades on upgrade from F35 to F36 + categorized list

[Mamoru TASAKA]

Fabio Valentini wrote on 2022/03/18 22:32:
 


Probably caused by F36FTBFS issues:
===

- cantor-0:21.12.2-1.fc35 > cantor-0:21.12.1-2.fc36
Version 21.12.2 seems to have failed to build on f36+, but was submitted to f35.

- julia-0:1.7.2-1.fc35 > julia-0:1.7.0.0-1.fc36
This package seems to be FTBFS on F36+.



julia is difficult.
https://bugzilla.redhat.com/show_bug.cgi?id=2045732

(Although I am not the maintainer of julia, out of curiosity I tried
 debugging this)
julia compiles on F35. With F36 and above, perhaps due to some changes on gcc12
wrt how to handle float16, julia test suite fails on F36 wrt float16 related.
The maintainer says that upstream is working on this, however for now
I would say it is unlikely that FTBFS will be fixed by the time
F36 final is released.
(Can gcc guru take a look at this...??? However for me it is too difficult
 to narrow down where to debug)

cantor has BR: julia, julia cannot be installed on F-36, so cantor
FTBFS. Note that it seems that using julia for cantor is optional, so
to rescue cantor, for now it may be better that cantor kills julia support
on F-36.

BTW for julia: Fedora-Astronomy_KDE-Live and Fedora-Scientific_KDE-Live
both live spin have Requires for julia, so these two live spins are
broken for a long time. If the current status doesn't change,
these two live spins won't be pushed on F-36 (at least for beta).

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Blender failed to build with ffmpeg enabled

[Mamoru TASAKA]

Luya Tshimbalanga wrote on 2022/03/01 15:11:

Hello team,

Blender failed to build with enabled FFMPEG support using ffmpeg-free-devel at 
the following line:

'''

/builddir/build/BUILD/blender-3.0.1/extern/audaspace/plugins/ffmpeg/FFMPEGReader.cpp:
 In member function 'void aud::FFMPEGReader::init(int)':
/builddir/build/BUILD/blender-3.0.1/extern/audaspace/plugins/ffmpeg/FFMPEGReader.cpp:180:47:
 error: invalid conversion from 'const AVCodec*' to 'AVCodec*' [-fpermissive]
   180 | AVCodec* aCodec = 
avcodec_find_decoder(m_formatCtx->streams[m_stream]->codecpar->codec_id);
   |   
^~~~
   |   |
   |   const AVCodec*
gmake[2]: *** [extern/audaspace/CMakeFiles/audaspace.dir/build.make:1549: 
extern/audaspace/CMakeFiles/audaspace.dir/plugins/ffmpeg/FFMPEGReader.cpp.o] 
Error 1

'''

Could someone handle the AVCodec issue please?
Available scratch-build result:
https://koji.fedoraproject.org/koji/taskinfo?taskID=83496011


Thanks in advance.



Change to const AVCodec* aCodec = avcodec_find_decoder(
ref:
https://github.com/blender/blender/commit/af6a1b08e3f0d0070ac9423868d2d3f81057717a

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Possibly unexpcted soname change: liblept.so.5 -> libleptonica.so.5.4.0

[Mamoru TASAKA]

Petr Pisar wrote on 2022/02/25 19:10:

V Fri, Feb 25, 2022 at 10:46:15AM +0900, Mamoru TASAKA napsal(a):

On f37 / f36 leptonica made some packaging change:
https://src.fedoraproject.org/rpms/leptonica/c/e2486ca5bc2578ee629457b854c5e13bb94c1dde?branch=rawhide

This caused soname change: liblept.so.5 -> libleptonica.so.5.4.0 , which I 
guess is unexpected.


There was no soname change:

leptonica-1.81.1-2.fc35.aarch64.rpm provides liblept.so.5()(64bit).
"dnf repoquery --whatrequires 'liblept.so.5.4.0()(64bit)'" returns
no results in F36 and F37. Where can you see libleptonica.so.5.4.0?

-- Petr




leptonica-1.82.0-6.fc37
https://koji.fedoraproject.org/koji/buildinfo?buildID=1924153

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Possibly unexpcted soname change: liblept.so.5 -> libleptonica.so.5.4.0

[Mamoru TASAKA]

Hello, all:

On f37 / f36 leptonica made some packaging change:
https://src.fedoraproject.org/rpms/leptonica/c/e2486ca5bc2578ee629457b854c5e13bb94c1dde?branch=rawhide

This caused soname change: liblept.so.5 -> libleptonica.so.5.4.0 , which I 
guess is unexpected.

$ dnf repoquery --quiet --repo=koji-36 --qf '%{sourcerpm}' --whatrequires 
"liblept.so.5()(64bit)" | cat -n
 1  leptonica-1.82.0-2.fc36.src.rpm
 2  mupdf-1.19.0-5.fc36.src.rpm
 3  python-PyMuPDF-1.19.4-2.fc36.src.rpm
 4  tesseract-5.0.1-2.fc36.src.rpm
 5  zathura-pdf-mupdf-0.3.7-5.fc36.src.rpm

$ dnf repoquery --quiet --repo=koji-37 --qf '%{sourcerpm}' --whatrequires 
"liblept.so.5()(64bit)" | cat -n
 1  mupdf-1.19.0-5.fc36.src.rpm
 2  python-PyMuPDF-1.19.5-1.fc37.src.rpm
 3  zathura-pdf-mupdf-0.3.7-5.fc36.src.rpm

(Some of the package were rebuilt on f37 due to another reason, so depending 
packages' number
 differs here)

Currently I am not sure if we can just revert the above change.

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Unannounced soname bump: libwebsockets.so.18 -> libwebsockets.so.19

[Mamoru TASAKA]

Hello, all:

On f37 / f36 two days ago libwebsockets was updated from 4.2.2 to 4.3.1
which causes unannounced soname bump from libwebsockets.so.18 to 
libwebsockets.so.19

What is strange here is that the committer seems aware of this change:
https://src.fedoraproject.org/rpms/libwebsockets/c/ad122ba347b290d1221fe6fee1c4194ac74c2719?branch=rawhide

Affected packages:

$ dnf repoquery --quiet --repo=koji-36 --qf '%{sourcerpm}' --whatrequires 
"libwebsockets.so.18()(64bit)"  | cat -n
 1  kismet-0.0.2022.01.R3-1.fc36.src.rpm
 2  qpid-dispatch-1.18.0-2.fc36.src.rpm

Note that kismet broken deps now causes Fedora-Security-Live live spin breakage:
https://koji.fedoraproject.org/koji/packageinfo?packageID=22098
https://koji.fedoraproject.org/koji/taskinfo?taskID=83148899

(Yes, Fedora-Security-Live began to be broken on f36 from 36-20220221.n.0)
And now we are under F36 beta freeze.

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Unannounced soname bump: libjasper.so.4 -> libjasper.so.6

[Mamoru TASAKA]

Miro Hrončok wrote on 2022/02/13 22:26:

On 13. 02. 22 13:32, Josef Řídký wrote:

Hi,

first of all, I would like to apologize for the mess I've caused by the jasper .so name 
bump in Rawhide. I entirely forgot the side-tag option and had the old mindset of having 
rawhide as a "sandbox for new features". I wrote to Miro already as I am not 
part of the proven packager group to assist me with the update - specifically with 
package rebuild.

On the other hand, I have to partially agree with Kevin Koffler in the way that 
making library upgrade in the rawhide from a regular maintainer point of view 
is still quite painful and from discussion with my colleagues it seems that I 
am not the only one who feels it that way.

Mostly, simple rebuild of dependent packages is all that is needed, but to 
achieve it, I have to either communicate with all other maintainers (where 
their number might be quite huge and not all of them are able to react in 
meningul timeframe - agree it's not applicable with handful of dependent 
packages, where it is easy to get it done) or bother some proven packager to do 
the rebuilds on my behalf (which is something I don't like, as the workload is 
transferred to someone, who has enough of his/her own tasks already).

It would be awesome to have some bot available for all Fedora maintainers, which 
would have proven packagers rights and it's only function would be -> bump spec 
file and build (e.g. in specific side-tag). In that way, for most library updates 
this would be the easiest way, how to get them into Fedora and bother other 
maintainers/proven packagers as little as possible.


Considering most of the dependent packages failed to rebuild in this case, I am 
not sure how a robot would be supposed to deal with this :(

Successful rebuilds (jasper+5):

https://koji.fedoraproject.org/koji/builds?inherited=0=50649=-build_id=1

Still in progress:
gdal (already succeeded on some architectures)

Failed twice (13):
LibRaw

  - fixed by jasper header fix

OpenSceneGraph

  - fixed by jasper header fix

digikam

  - fixed by jasper header fix

eccodes

  - fixed by replacing jpc_encode with jas_image_encode and other similar change

gegl04

  - fixed by jasper header fix

grads

  - fixed by g2clib side fix similar to eccodes

grib_api

  - uses same code as eccodes, fixed likewise

kdelibs

   - fixed by similar ways with eccodes + jas_stream_ops_t API change fix 
(perhaps)
 now building...
 https://koji.fedoraproject.org/koji/taskinfo?taskID=82817310


kdelibs3

  - fixed by jasper header fix

ncl

  - fixed by g2clib side

qt5-qtimageformats

  - fixed by jasper header fix

qt6-qtimageformats

  - fixed by jasper header fix

wgrib2

  - fixed by similar way with eccodes


If somebody wants to help, build in f37-build-side-50649 please.



I am going to bed. Good night.

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Unannounced soname bump: libjasper.so.4 -> libjasper.so.6

[Mamoru TASAKA]

Jos de Kloe wrote on 2022/02/14 15:56:

Hi,

eccodes will need to be adapted upstream. I filed an issue there and they will 
try to fix this a.s.a.p. Untill then, if needed, I could remove use of 
libjasper since it is an optional feature.


For now, I've pushed:
https://src.fedoraproject.org/rpms/eccodes/c/a086e5e7b27c579a9fd0afbc4b7be1ab80956766?branch=rawhide

scratch build was okay:
https://koji.fedoraproject.org/koji/taskinfo?taskID=82812510

Now doing real build.

Mamoru



grib_api is no longer maintained upstream, so not much can be done there.

Jos.

On 2/13/22 21:51, Orion Poplawski wrote:

On 2/13/22 13:19, devel@lists.fedoraproject.org wrote:

On 2/13/22 06:26, Miro Hrončok wrote:

Still in progress:
gdal (already succeeded on some architectures)

Failed twice (13):
LibRaw
OpenSceneGraph
digikam
eccodes
gegl04
grads
grib_api
kdelibs
kdelibs3
ncl
qt5-qtimageformats
qt6-qtimageformats
wgrib2

If somebody wants to help, build in f37-build-side-50649 please.


Some of these are due to the need to rebuild g2clib (which is a static 
library).  I've submitted that:

https://koji.fedoraproject.org/koji/taskinfo?taskID=82783644


Or not.  I'll see what I can figure out.



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

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

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

Re: Unannounced soname bump: libjasper.so.4 -> libjasper.so.6

[Mamoru TASAKA]

Mamoru TASAKA wrote on 2022/02/14 17:47:

Miro Hrončok wrote on 2022/02/13 22:26:

On 13. 02. 22 13:32, Josef Řídký wrote:

Hi,

first of all, I would like to apologize for the mess I've caused by the jasper .so name 
bump in Rawhide. I entirely forgot the side-tag option and had the old mindset of having 
rawhide as a "sandbox for new features". I wrote to Miro already as I am not 
part of the proven packager group to assist me with the update - specifically with 
package rebuild.

On the other hand, I have to partially agree with Kevin Koffler in the way that 
making library upgrade in the rawhide from a regular maintainer point of view 
is still quite painful and from discussion with my colleagues it seems that I 
am not the only one who feels it that way.

Mostly, simple rebuild of dependent packages is all that is needed, but to 
achieve it, I have to either communicate with all other maintainers (where 
their number might be quite huge and not all of them are able to react in 
meningul timeframe - agree it's not applicable with handful of dependent 
packages, where it is easy to get it done) or bother some proven packager to do 
the rebuilds on my behalf (which is something I don't like, as the workload is 
transferred to someone, who has enough of his/her own tasks already).

It would be awesome to have some bot available for all Fedora maintainers, which 
would have proven packagers rights and it's only function would be -> bump spec 
file and build (e.g. in specific side-tag). In that way, for most library updates 
this would be the easiest way, how to get them into Fedora and bother other 
maintainers/proven packagers as little as possible.


Considering most of the dependent packages failed to rebuild in this case, I am 
not sure how a robot would be supposed to deal with this :(

Successful rebuilds (jasper+5):

https://koji.fedoraproject.org/koji/builds?inherited=0=50649=-build_id=1

Still in progress:
gdal (already succeeded on some architectures)

Failed twice (13):
LibRaw
OpenSceneGraph
digikam
eccodes
gegl04
grads
grib_api
kdelibs
kdelibs3
ncl
qt5-qtimageformats
qt6-qtimageformats
wgrib2

If somebody wants to help, build in f37-build-side-50649 please.



A
One issue as Kevin pointed out should be fixed in
https://src.fedoraproject.org/rpms/jasper/c/810e315ae32ec99e569361e680308fd14974bb20?branch=rawhide

LibRaw, gegl04, OpenSceneGraph, digikam was okay with the above change.

kdelibs3 also seems to be okay with above, but ppc64le build only failed:
https://koji.fedoraproject.org/koji/taskinfo?taskID=82799185
Looking at build.log , it looks like parallel make issue.

B
Other issue like missing symbol on jpc_encode / jpc_decode is that now jasper 3 
hides
these internal decoder / encoder symbols:
https://github.com/jasper-software/jasper/commit/5fe57ac5829ec31396e7eaab59a688da014660af

(While I am testing now) I believe that the usage
     image=jpc_decode(jpcstream,opts);
can simply replaced with
     image=jas_image_decode (jpcstream, -1, 0);

and
     ier=jpc_encode(,jpcstream,opts);
can be
     fmt = jas_image_strtofmt("jpc");
     ier=jas_image_encode(,jpcstream,fmt,opts);

Now I am trying to fix g2clib -> grads chain dependency first.



Unfortunately eccodes testsuite now fails with the above changes
( calling jas_stream_memopen() just aborts, gdb shows like below (*))
and it seems now calling jasper function like jas_stream_memopen() now always 
have to call
some initialization functions like:

jas_conf_clear(); jas_conf_set_max_mem_usage(jas_get_total_mem_size()); 
jas_init_library(); jas_init_thread();

beforehand, and after that some shutdown functions have to be called:

jas_cleanup_thread(); jas_cleanup_library();

(and thanks to eccodes testsuite for pointing this out). With the above 
additional changes,
eccodes test suite now all passes (on x86_64, I verified only on this arch for 
now)


So simple rebuilding seems not enough and it seems all jasper consumers may 
have to
adjust internal code to jasper 3...

Is it okay for me to commit these changes? I really appreciate it if jasper 
maintainer
confirms the above changes. Or we should investigat jasper changes more 
carefully?

Regards,
Mamoru

(*) For example, one of eccodes testsuite aborts like:

Program received signal SIGABRT, Aborted.
0x77b8cedc in __pthread_kill_implementation () from /lib64/libc.so.6
Missing separate debuginfos, use: dnf debuginfo-install 
glibc-2.35-2.fc37.x86_64 libgomp-12.0.1-0.7.fc37.x86_64 
libjpeg-turbo-2.1.2-2.fc36.x86_64 libpng-1.6.37-12.fc36.x86_64 
openjpeg2-2.4.0-5.fc36.x86_64 zlib-1.2.11-31.fc36.x86_64
(gdb) bt
#0  0x77b8cedc in __pthread_kill_implementation () from /lib64/libc.so.6
#1  0x77b3ca36 in raise () from /lib64/libc.so.6
#2  0x77b2682f in abort () from /lib64/libc.so.6
#3  0x77b2675b in __assert_fail_base.cold () from /lib64/libc.so.6
#4  0x77b35596 in __assert_fail () from /lib64/libc.s

Re: Unannounced soname bump: libjasper.so.4 -> libjasper.so.6

[Mamoru TASAKA]

Miro Hrončok wrote on 2022/02/13 22:26:

On 13. 02. 22 13:32, Josef Řídký wrote:

Hi,

first of all, I would like to apologize for the mess I've caused by the jasper .so name 
bump in Rawhide. I entirely forgot the side-tag option and had the old mindset of having 
rawhide as a "sandbox for new features". I wrote to Miro already as I am not 
part of the proven packager group to assist me with the update - specifically with 
package rebuild.

On the other hand, I have to partially agree with Kevin Koffler in the way that 
making library upgrade in the rawhide from a regular maintainer point of view 
is still quite painful and from discussion with my colleagues it seems that I 
am not the only one who feels it that way.

Mostly, simple rebuild of dependent packages is all that is needed, but to 
achieve it, I have to either communicate with all other maintainers (where 
their number might be quite huge and not all of them are able to react in 
meningul timeframe - agree it's not applicable with handful of dependent 
packages, where it is easy to get it done) or bother some proven packager to do 
the rebuilds on my behalf (which is something I don't like, as the workload is 
transferred to someone, who has enough of his/her own tasks already).

It would be awesome to have some bot available for all Fedora maintainers, which 
would have proven packagers rights and it's only function would be -> bump spec 
file and build (e.g. in specific side-tag). In that way, for most library updates 
this would be the easiest way, how to get them into Fedora and bother other 
maintainers/proven packagers as little as possible.


Considering most of the dependent packages failed to rebuild in this case, I am 
not sure how a robot would be supposed to deal with this :(

Successful rebuilds (jasper+5):

https://koji.fedoraproject.org/koji/builds?inherited=0=50649=-build_id=1

Still in progress:
gdal (already succeeded on some architectures)

Failed twice (13):
LibRaw
OpenSceneGraph
digikam
eccodes
gegl04
grads
grib_api
kdelibs
kdelibs3
ncl
qt5-qtimageformats
qt6-qtimageformats
wgrib2

If somebody wants to help, build in f37-build-side-50649 please.



A
One issue as Kevin pointed out should be fixed in
https://src.fedoraproject.org/rpms/jasper/c/810e315ae32ec99e569361e680308fd14974bb20?branch=rawhide

LibRaw, gegl04, OpenSceneGraph, digikam was okay with the above change.

kdelibs3 also seems to be okay with above, but ppc64le build only failed:
https://koji.fedoraproject.org/koji/taskinfo?taskID=82799185
Looking at build.log , it looks like parallel make issue.

B
Other issue like missing symbol on jpc_encode / jpc_decode is that now jasper 3 
hides
these internal decoder / encoder symbols:
https://github.com/jasper-software/jasper/commit/5fe57ac5829ec31396e7eaab59a688da014660af

(While I am testing now) I believe that the usage
image=jpc_decode(jpcstream,opts);
can simply replaced with
image=jas_image_decode (jpcstream, -1, 0);

and
ier=jpc_encode(,jpcstream,opts);
can be
fmt = jas_image_strtofmt("jpc");
ier=jas_image_encode(,jpcstream,fmt,opts);

Now I am trying to fix g2clib -> grads chain dependency first.

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Unannounced soname bump: libjasper.so.4 -> libjasper.so.6

[Mamoru TASAKA]

Mamoru TASAKA wrote on 2022/02/11 23:41:

Miro Hrončok wrote on 2022/02/11 23:29:

On 11. 02. 22 15:20, Mamoru TASAKA wrote:

Hello, all:

On rawhide (f37) jasper is updated from 2.0.33-2 to 3.0.0-1,
which causes unannounced soname bump from  libjasper.so.4 to libjasper.so.6.

What is strange here is that the committer seems aware of this change:
https://src.fedoraproject.org/rpms/jasper/c/13f23ce40bfeafccd96ecc8872f965e6229e76cb?branch=rawhide

Affected packages:
$ dnf --quiet repoquery --repo=koji-37 --qf '%{sourcerpm}' --whatrequires 
"libjasper.so.4()(64bit)" | cat -n
  1    DevIL-1.7.8-38.fc36.src.rpm
  2    GraphicsMagick-1.3.36-6.fc36.src.rpm
  3    LibRaw-0.20.2-5.fc36.src.rpm
  4    OpenSceneGraph-3.6.5-2.fc36.src.rpm
  5    dcraw-9.28.0-13.fc36.src.rpm
  6    digikam-7.5.0-2.fc36.src.rpm
  7    eccodes-2.24.0-2.fc36.src.rpm
  8    gdal-3.4.1-4.fc36.src.rpm
  9    gegl04-0.4.34-2.fc36.src.rpm
 10    grads-2.0.2-39.fc36.src.rpm
 11    grib_api-1.27.0-13.fc36.src.rpm
 12    kdelibs-4.14.38-31.fc37.src.rpm
 13    kdelibs3-3.5.10-114.fc36.src.rpm
 14    libicns-0.8.1-23.fc36.src.rpm
 15    ncl-6.6.2-25.fc36.src.rpm
 16    netpbm-10.97.00-2.fc36.src.rpm
 17    qt5-qtimageformats-5.15.2-5.fc36.src.rpm
 18    qt6-qtimageformats-6.2.3-1.fc36.src.rpm
 19    wgrib2-2.0.8-9.fc36.src.rpm

jasper-3.0.0-1.fc37 was build just one hours ago, so maybe untagging this build 
is
better.


It was actually announced:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/FV53ADNJB5STFN3YAEEXEVHMIA6DMXCN/

But for reasons I don't understand, it was pushed to rawhide without using a 
side tag and without doing rebuilds :(

I agree that untagging this is the best option now, it breaks hundreds of 
packages both on runtime and buildtime.



Requested untagging
https://pagure.io/fedora-infrastructure/issue/10552

Regards,
Mamoru



Just note that I am going to bed now.
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Unannounced soname bump: libjasper.so.4 -> libjasper.so.6

[Mamoru TASAKA]

Miro Hrončok wrote on 2022/02/11 23:29:

On 11. 02. 22 15:20, Mamoru TASAKA wrote:

Hello, all:

On rawhide (f37) jasper is updated from 2.0.33-2 to 3.0.0-1,
which causes unannounced soname bump from  libjasper.so.4 to libjasper.so.6.

What is strange here is that the committer seems aware of this change:
https://src.fedoraproject.org/rpms/jasper/c/13f23ce40bfeafccd96ecc8872f965e6229e76cb?branch=rawhide

Affected packages:
$ dnf --quiet repoquery --repo=koji-37 --qf '%{sourcerpm}' --whatrequires 
"libjasper.so.4()(64bit)" | cat -n
  1    DevIL-1.7.8-38.fc36.src.rpm
  2    GraphicsMagick-1.3.36-6.fc36.src.rpm
  3    LibRaw-0.20.2-5.fc36.src.rpm
  4    OpenSceneGraph-3.6.5-2.fc36.src.rpm
  5    dcraw-9.28.0-13.fc36.src.rpm
  6    digikam-7.5.0-2.fc36.src.rpm
  7    eccodes-2.24.0-2.fc36.src.rpm
  8    gdal-3.4.1-4.fc36.src.rpm
  9    gegl04-0.4.34-2.fc36.src.rpm
 10    grads-2.0.2-39.fc36.src.rpm
 11    grib_api-1.27.0-13.fc36.src.rpm
 12    kdelibs-4.14.38-31.fc37.src.rpm
 13    kdelibs3-3.5.10-114.fc36.src.rpm
 14    libicns-0.8.1-23.fc36.src.rpm
 15    ncl-6.6.2-25.fc36.src.rpm
 16    netpbm-10.97.00-2.fc36.src.rpm
 17    qt5-qtimageformats-5.15.2-5.fc36.src.rpm
 18    qt6-qtimageformats-6.2.3-1.fc36.src.rpm
 19    wgrib2-2.0.8-9.fc36.src.rpm

jasper-3.0.0-1.fc37 was build just one hours ago, so maybe untagging this build 
is
better.


It was actually announced:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/FV53ADNJB5STFN3YAEEXEVHMIA6DMXCN/

But for reasons I don't understand, it was pushed to rawhide without using a 
side tag and without doing rebuilds :(

I agree that untagging this is the best option now, it breaks hundreds of 
packages both on runtime and buildtime.



Requested untagging
https://pagure.io/fedora-infrastructure/issue/10552

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: JasPer 3.0.0 update in Rawhide and F36

[Mamoru TASAKA]

Josef Řídký wrote on 2022/02/11 22:55:

Hi,

just reminder - a new jasper version is now available in Rawhide.

All packages that require jasper, should be rebuilt - in most cases it is
all that is needed.
In rare occasions more work would be needed - this is valid for packages,
which didn't use jasper library in the standard way.

Best regards



Please use side-tag and rebuild all dependent packages there (or ask dependent
packages' maintainer to rebuild there), not directly push into f36 or f37
buildtree.

Regards,
Mamoru




On Wed, Feb 9, 2022 at 5:03 PM Josef Řídký  wrote:


Hi,

upstream authors of JasPer library have released a new major version. This
rebase will introduce .so name bump from version 4 to version 6.

I am going to rebase the library in rawhide on Friday February 11th.

For testing purposes, you may use the copr build available at [1].
List of dependent packages and their build results with the new jasper
library might be found at [2].

All comments are welcome.

[1] https://copr.fedorainfracloud.org/coprs/jridky/jasper/
[2] https://copr.fedorainfracloud.org/coprs/jridky/jasperDepend/

Best regards

Josef Ridky
Senior Software Engineer
Core Services Team
Red Hat Czech, s.r.o.




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


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

Unannounced soname bump: libjasper.so.4 -> libjasper.so.6

[Mamoru TASAKA]

Hello, all:

On rawhide (f37) jasper is updated from 2.0.33-2 to 3.0.0-1,
which causes unannounced soname bump from  libjasper.so.4 to libjasper.so.6.

What is strange here is that the committer seems aware of this change:
https://src.fedoraproject.org/rpms/jasper/c/13f23ce40bfeafccd96ecc8872f965e6229e76cb?branch=rawhide

Affected packages:
$ dnf --quiet repoquery --repo=koji-37 --qf '%{sourcerpm}' --whatrequires 
"libjasper.so.4()(64bit)" | cat -n
 1  DevIL-1.7.8-38.fc36.src.rpm
 2  GraphicsMagick-1.3.36-6.fc36.src.rpm
 3  LibRaw-0.20.2-5.fc36.src.rpm
 4  OpenSceneGraph-3.6.5-2.fc36.src.rpm
 5  dcraw-9.28.0-13.fc36.src.rpm
 6  digikam-7.5.0-2.fc36.src.rpm
 7  eccodes-2.24.0-2.fc36.src.rpm
 8  gdal-3.4.1-4.fc36.src.rpm
 9  gegl04-0.4.34-2.fc36.src.rpm
10  grads-2.0.2-39.fc36.src.rpm
11  grib_api-1.27.0-13.fc36.src.rpm
12  kdelibs-4.14.38-31.fc37.src.rpm
13  kdelibs3-3.5.10-114.fc36.src.rpm
14  libicns-0.8.1-23.fc36.src.rpm
15  ncl-6.6.2-25.fc36.src.rpm
16  netpbm-10.97.00-2.fc36.src.rpm
17  qt5-qtimageformats-5.15.2-5.fc36.src.rpm
18  qt6-qtimageformats-6.2.3-1.fc36.src.rpm
19  wgrib2-2.0.8-9.fc36.src.rpm

jasper-3.0.0-1.fc37 was build just one hours ago, so maybe untagging this build 
is
better.

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: emacs uninstallable in Rawhide at the moment

[Mamoru TASAKA]

Richard W.M. Jones wrote on 2022/02/04 21:21:

https://koji.fedoraproject.org/koji/taskinfo?taskID=82370784

DEBUG util.py:444:   Problem: package emacs-1:27.2-9.fc35.x86_64 requires 
libwebkit2gtk-4.0.so.37()(64bit), but none of the providers can be installed
DEBUG util.py:444:- conflicting requests
DEBUG util.py:444:- nothing provides gstreamer1-plugins-bad-freeworld 
needed by webkit2gtk3-2.35.2-2.fc36.x86_64

Having said that, why on earth is ocaml-dune (a command line build
tool) depending on emacs?!  There's an emacs subpackage, but maybe
emacs-nox would be a better BR for that.

Rich.



Well, by the way, another strange issue here is that
webkit2gtk3 now has Requires: gstreamer1-plugins-bad-*freeworld* , which is 
rpmfusion package.

Looks like the following change caused this:
https://src.fedoraproject.org/rpms/webkit2gtk3/c/b2bf422ca3438763a55a3e9096ef4cc0b17adce5

At least Requires for gstreamer1-plugins-bad-freeworld must be reverted.

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: hdf5 fortran build failure with gcc 12

[Mamoru TASAKA]

Dave Love wrote on 2022/02/01 19:20:

Orion Poplawski  writes:


On 1/29/22 19:40, Mamoru TASAKA wrote:



Looks like "minusone" variable looking like constant value defined
in
fortran/test/tH5A_1_8.F90 needs PARAMETER attribute. Tried this diff:
```
diff --git a/hdf5.spec b/hdf5.spec
index 3b1d27b..2bac44d 100644
--- a/hdf5.spec
+++ b/hdf5.spec
@@ -187,6 +187,8 @@ autoreconf -f -i
   # Modify low optimization level for gnu compilers
   sed -e 's|-O -finline-functions|-O3 -finline-functions|g' -i
config/gnu-flags
+sed -i fortran/test/tH5A_1_8.F90 -e 's|INTEGER :: minusone|INTEGER,
PARAMETER :: minusone|'
+
   %build
   #Do out of tree builds
   %global _configure ../configure
```
https://koji.fedoraproject.org/koji/taskinfo?taskID=82124997
Unfortunately ppc64le %check fails, looking like long double
related,
which I believe is related to recent gcc default change to
-mabi=ieeelongdouble on ppc64le,
however I don't know how to fix this.


Thank you!  I've passed that on to upstream.


I'm no longer a language lawyer, but it looks to me as if it should be
reported as a GCC bug.  Is there something in the standard which says
the code is invalid?


Well, the problem here is that the code itself now compiles, but the result 
after
execution of the binary seems wrong, so we have to narrow the code.

Then, out of curiosity, I tried debugging this, and indeed something seems wrong
with gcc here. Reporeted:

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

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: hdf5 fortran build failure with gcc 12

[Mamoru TASAKA]

Orion Poplawski wrote on 2022/01/30 3:48:

hdf5 is starting to fail to build with gcc 12 in rawhide with:

make[2]: Entering directory 
'/builddir/build/BUILD/hdf5-1.12.1/build/fortran/test'
/bin/sh ../../libtool  --tag=FC   --mode=link gfortran -std=f2008 -Waliasing -Wall -Wcharacter-truncation -Wextra -Wimplicit-interface -Wsurprising -Wunderflow -pedantic -Warray-temporaries -Wintrinsics-std -Wimplicit-procedure -Wreal-q-constant -Wfunction-elimination -Wrealloc-lhs -Wrealloc-lhs-all -Wno-c-binding-type -Wuse-without-only -Winteger-division -Wfrontend-loop-interchange  -fdiagnostics-urls=never -fno-diagnostics-color -s -O3 -I../../fortran/src -I../../fortran/src -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64  -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -I/usr/lib64/gfortran/modules -Wl,-z,relro -Wl,--as-needed  -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -Wl,--build-id=sha1 -Wl,-dT,/builddir/build/BUILD/hdf5-1.12.1/.package_note-hdf5-1.12.1-2.fc36.x86_64.ld -fPIC -Wl,-z,now -Wl,--as-needed -o fortranlib_test_1_8 tH5O.o tH5A_1_8.o tH5G_1_8.o tH5MISC_1_8.o tHDF5_1_8.o fortranlib_test_1_8.o libh5test_fortran.la ../../test/libh5test.la ../../fortran/src/libhdf5_fortran.la ../../src/libhdf5.la -lsz -lz -ldl -lm
libtool: link: gfortran -std=f2008 -Waliasing -Wall -Wcharacter-truncation -Wextra -Wimplicit-interface -Wsurprising -Wunderflow -pedantic -Warray-temporaries -Wintrinsics-std -Wimplicit-procedure -Wreal-q-constant -Wfunction-elimination -Wrealloc-lhs -Wrealloc-lhs-all -Wno-c-binding-type -Wuse-without-only -Winteger-division -Wfrontend-loop-interchange -fdiagnostics-urls=never -fno-diagnostics-color -s -O3 -I../../fortran/src -I../../fortran/src -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -I/usr/lib64/gfortran/modules -Wl,-z -Wl,relro -Wl,--as-needed -Wl,-z -Wl,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 
-Wl,--build-id=sha1 -Wl,-dT -Wl,/builddir/build/BUILD/hdf5-1.12.1/.package_note-hdf5-1.12.1-2.fc36.x86_64.ld -fPIC -Wl,-z -Wl,now -Wl,--as-needed -o .libs/fortranlib_test_1_8 tH5O.o tH5A_1_8.o tH5G_1_8.o tH5MISC_1_8.o tHDF5_1_8.o fortranlib_test_1_8.o ./.libs/libh5test_fortran.a ../../test/.libs/libh5test.a ../../fortran/src/.libs/libhdf5_fortran.so /builddir/build/BUILD/hdf5-1.12.1/build/src/.libs/libhdf5.so ../../src/.libs/libhdf5.so -lsz -lz -ldl -lm

../../../fortran/test/tf.F90:169:33: warning: type of 'h5_fixname_c' does not 
match original declaration [-Wlto-type-mismatch]
   169 |  full_name, full_namelen)
   | ^
../../../fortran/test/t.c:43:1: note: type mismatch in parameter 6
    43 | nh5_fixname_c(_fcd base_name, size_t_f *base_namelen, hid_t_f *fapl, 
_fcd full_name, size_t_f *full_namelen)
   | ^
../../../fortran/test/t.c:43:1: note: type 'void' should match type 'long int'
../../../fortran/test/t.c:43:1: note: 'h5_fixname_c_' was previously declared 
here
../../../fortran/test/tf.F90:220:56: warning: type of 'h5_cleanup_c' does not 
match original declaration [-Wlto-type-mismatch]
   220 | hdferr = h5_cleanup_c(base_name, base_namelen, fapl)
   |    ^
../../../fortran/test/t.c:85:1: note: type mismatch in parameter 4
    85 | nh5_cleanup_c(_fcd base_name, size_t_f *base_namelen, hid_t_f *fapl)
   | ^
../../../fortran/test/t.c:85:1: note: type 'void' should match type 'long int'
../../../fortran/test/t.c:85:1: note: 'h5_cleanup_c_' was previously declared 
here
/usr/bin/ld: /tmp/ccYpA0p7.ltrans1.ltrans.o: warning: relocation against 
`minusone.31' in read-only section `.text'
/usr/bin/ld: /tmp/ccYpA0p7.ltrans0.ltrans.o: in function 
`__th5a_1_8_MOD_attribute_test_1_8.constprop.0':
/builddir/build/BUILD/hdf5-1.12.1/build/fortran/test/tf_gen.F90:84: undefined 
reference to `minusone.46'
/usr/bin/ld: /tmp/ccYpA0p7.ltrans1.ltrans.o: in function 
`__th5a_1_8_MOD_test_attr_info_by_idx.constprop.0':
/builddir/build/BUILD/hdf5-1.12.1/build/fortran/test/tf_gen.F90:84: undefined 
reference to `minusone.18'
/usr/bin/ld: 
/builddir/build/BUILD/hdf5-1.12.1/build/fortran/test/tf_gen.F90:84: undefined 
reference to `minusone.18'
/usr/bin/ld: 
/builddir/build/BUILD/hdf5-1.12.1/build/fortran/test/tf_gen.F90:84: undefined 
reference to `minusone.18'
/usr/bin/ld: 

Re: Carla: FTBFS in Fedora rawhide/f36 - error: aggregate 'std::array sizes' has incomplete type and cannot be defined

[Mamoru TASAKA]

Martin Gansser wrote on 2022/01/29 23:02:

Hi,

when building Carla on rawhide the compilation fails with the following error 
message [1]:

Compiling juce_gui_basics.cpp
In file included from juce_gui_basics.cpp:265:
native/x11/juce_linux_XWindowSystem.cpp: In member function 
'juce::BorderSize juce::XWindowSystem::getBorderSize(Window) const':
native/x11/juce_linux_XWindowSystem.cpp:1599:42: error: aggregate 'std::array sizes' has incomplete type and cannot be defined
  1599 | std::array sizes;
   |  ^
native/x11/juce_linux_XWindowSystem.cpp:1607:85: error: could not convert '{, 
, , }' from '' to 'juce::BorderSize'
  1607 | return { (int) sizes[2], (int) sizes[0], (int) sizes[3], 
(int) sizes[1] };
   |
 ^
   |
 |
   |  
   
native/x11/juce_linux_XWindowSystem.cpp: In function 'juce::Rectangle 
juce::getWorkArea(const XWindowSystemUtilities::GetXProperty&)':
native/x11/juce_linux_XWindowSystem.cpp:2181:29: error: aggregate 'std::array position' has incomplete type and cannot be defined
  2181 | std::array position;
   | ^~~~
native/x11/juce_linux_XWindowSystem.cpp:2190:55: error: could not convert '{, 
, , }' from '' to 'juce::Rectangle'
  2190 |  (int) position[2], (int) position[3] };
   |   ^
   |   |
   |   


[1] https://kojipkgs.fedoraproject.org//work/tasks/4698/82104698/build.log

how can solve this ?

Regards
Martin


#include  is missing in juce_linux_XWindowSystem.cpp

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: FC35: undefined symbol: PyObject_Repr

[Mamoru TASAKA]

Mamoru TASAKA wrote on 2022/01/29 8:00:

Martin Gansser wrote on 2022/01/28 22:05:

but building [1] on rawhide it fails with this error [2]:

/usr/bin/ld: cannot open linker script file 
/builddir/build/BUILD/vdr-2.6.0/.package_note-vdr-2.6.0-3.fc36.x86_64.ld: No 
such file or directory
collect2: error: ld returned 1 exit status
make: *** [Makefile:167: libvdr-epg2vdr.so] Error 1

[1] https://martinkg.fedorapeople.org/ErrorReports/vdr-epg2vdr.spec
[2] https://kojipkgs.fedoraproject.org//work/tasks/4542/82064542/build.log

Regards
Martin


This is that /usr/lib64/vdr/plugins.mk or /usr/lib64/vdr/Make.config in 
vdr-config
being embedding ldflags generated from package_notes .


Not vdr-config but vdr-devel rpm
Mamoru



This is very annoying... Now I think package_notes side has to reconsider this.
For now, you can add

%undefine _package_note_flags

in vdr.spec and rebuild vdr first, then build vdr-epg2vdr again.

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: FC35: undefined symbol: PyObject_Repr

[Mamoru TASAKA]

Martin Gansser wrote on 2022/01/28 22:05:

but building [1] on rawhide it fails with this error [2]:

/usr/bin/ld: cannot open linker script file 
/builddir/build/BUILD/vdr-2.6.0/.package_note-vdr-2.6.0-3.fc36.x86_64.ld: No 
such file or directory
collect2: error: ld returned 1 exit status
make: *** [Makefile:167: libvdr-epg2vdr.so] Error 1

[1] https://martinkg.fedorapeople.org/ErrorReports/vdr-epg2vdr.spec
[2] https://kojipkgs.fedoraproject.org//work/tasks/4542/82064542/build.log

Regards
Martin


This is that /usr/lib64/vdr/plugins.mk or /usr/lib64/vdr/Make.config in 
vdr-config
being embedding ldflags generated from package_notes .

This is very annoying... Now I think package_notes side has to reconsider this.
For now, you can add

%undefine _package_note_flags

in vdr.spec and rebuild vdr first, then build vdr-epg2vdr again.

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 on the list, report it: 
https://pagure.io/fedora-infrastructure