OCaml 5 rebuild and i686

2023-07-04 Thread Richard W.M. Jones
We're planning to rebuild all the OCaml packages + dependencies with
the new OCaml 5 compiler (https://ocaml.org/releases/5.0.0).  This has
a rewritten runtime system, and Jerry James has been doing amazing
work rebuilding everything in a COPR and fixing lots of issues
(https://copr.fedorainfracloud.org/coprs/jjames/OCaml5/).

There are however three issues with i686.  Firstly there are some
issues with LTO, possibly solvable.  Secondly there no native code
backend for i686.  It has been dropped upstream and apparently they
have no plans to re-add it.

(Native code backends for s390x, riscv64 and ppc64le are also dropped
in 5.0, but with plans to add those back in 5.1.  They're just taking
their time to port these ones across to the new architecture.)

For i686, my view is we should drop the architecture for OCaml
packages entirely, rather than build only bytecode bindings and try to
fix the LTO problem.

There's a third, very long time problem with OCaml & i686.  It has
existed since the beginning.  Because of the size of a field in the 32
bit header used to store information about objects, only up to
4 M-word (16 Mbyte) arrays are supported.  This is in practice very
restrictive on the type of software you can build with OCaml & i686,
and so I'm sure it never had much serious use.

Note this affects packages such as graphviz, libguestfs, nbdkit,
plplot and brlapi which provide OCaml bindings.  We would need to
patch those bindings out with %ifnarch.

Also it affects programs like haxe, z3, coccinelle, coq, hevea,
frama-c and virt-top which would no longer be available for i686 (but
I guess no one is able to run Fedora i686 machines any more, so this
doesn't matter).

Any other objections ...?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
nbdkit - Flexible, fast NBD server with plugins
https://gitlab.com/nbdkit/nbdkit
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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


OCaml rebuild after or while Python 3 is rebuilding?

2023-07-04 Thread Richard W.M. Jones
We'd like to rebuild OCaml packages for OCaml 5 before the mass
rebuild starts, that is before 19th July (about 2 weeks):

https://fedorapeople.org/groups/schedule/f-39/f-39-key-tasks.html

The OCaml rebuild itself could take up to a week, but more likely 3-4
days.

However it seems as if Python 3.12 is still being rebuilt.  Some
packages have both Python and OCaml bindings so there may be conflicts
there.

Should we wait or should we start the rebuild soon?  Is there a good
way to resolve these kinds of conflicts?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
nbdkit - Flexible, fast NBD server with plugins
https://gitlab.com/nbdkit/nbdkit
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: OCaml rebuild after or while Python 3 is rebuilding?

2023-07-04 Thread Miro Hrončok

On 04. 07. 23 10:11, Richard W.M. Jones wrote:

We'd like to rebuild OCaml packages for OCaml 5 before the mass
rebuild starts, that is before 19th July (about 2 weeks):

https://fedorapeople.org/groups/schedule/f-39/f-39-key-tasks.html

The OCaml rebuild itself could take up to a week, but more likely 3-4
days.

However it seems as if Python 3.12 is still being rebuilt.  Some
packages have both Python and OCaml bindings so there may be conflicts
there.

Should we wait or should we start the rebuild soon?  Is there a good
way to resolve these kinds of conflicts?


Hey Rich,
please wait, we will merge this week.

AFAIK there is no good way to resolve a conflict like this. It's possible to do 
the OCaml rebuild while Python is in progress and we would rebuild the impacted 
packages again later, but it's not possible to start Python, start OCaml, end 
Python, end OCaml in this order :(


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


Re: OCaml rebuild after or while Python 3 is rebuilding?

2023-07-04 Thread Richard W.M. Jones
On Tue, Jul 04, 2023 at 10:15:40AM +0200, Miro Hrončok wrote:
> On 04. 07. 23 10:11, Richard W.M. Jones wrote:
> >We'd like to rebuild OCaml packages for OCaml 5 before the mass
> >rebuild starts, that is before 19th July (about 2 weeks):
> >
> >https://fedorapeople.org/groups/schedule/f-39/f-39-key-tasks.html
> >
> >The OCaml rebuild itself could take up to a week, but more likely 3-4
> >days.
> >
> >However it seems as if Python 3.12 is still being rebuilt.  Some
> >packages have both Python and OCaml bindings so there may be conflicts
> >there.
> >
> >Should we wait or should we start the rebuild soon?  Is there a good
> >way to resolve these kinds of conflicts?
> 
> Hey Rich,
> please wait, we will merge this week.
> 
> AFAIK there is no good way to resolve a conflict like this. It's
> possible to do the OCaml rebuild while Python is in progress and we
> would rebuild the impacted packages again later, but it's not
> possible to start Python, start OCaml, end Python, end OCaml in this
> order :(

Sure thing.  Please let us know when Python is merged.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Fedora rawhide compose report: 20230704.n.0 changes

2023-07-04 Thread Fedora Rawhide Report
OLD: Fedora-Rawhide-20230703.n.0
NEW: Fedora-Rawhide-20230704.n.0

= SUMMARY =
Added images:1
Dropped images:  5
Added packages:  6
Dropped packages:1
Upgraded packages:   49
Downgraded packages: 0

Size of added packages:  237.53 MiB
Size of dropped packages:30.49 KiB
Size of upgraded packages:   1.39 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Container_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Base-Rawhide-20230704.n.0.s390x.tar.xz

= DROPPED IMAGES =
Image: Cloud_Base tar-gz x86_64
Path: 
Cloud/x86_64/images/Fedora-Cloud-Base-GCP-Rawhide-20230703.n.0.x86_64.tar.gz
Image: Silverblue dvd-ostree x86_64
Path: 
Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-Rawhide-20230703.n.0.iso
Image: Kinoite dvd-ostree ppc64le
Path: Kinoite/ppc64le/iso/Fedora-Kinoite-ostree-ppc64le-Rawhide-20230703.n.0.iso
Image: Sericea dvd-ostree x86_64
Path: Sericea/x86_64/iso/Fedora-Sericea-ostree-x86_64-Rawhide-20230703.n.0.iso
Image: Phosh raw-xz aarch64
Path: Spins/aarch64/images/Fedora-Phosh-Rawhide-20230703.n.0.aarch64.raw.xz

= ADDED PACKAGES =
Package: galera-26.4.14-1.module_f39+17152+339dee66
Summary: Synchronous multi-master wsrep provider (replication engine)
RPMs:galera
Size:4.63 MiB

Package: mariadb-3:10.6.14-1.module_f39+17152+339dee66
Summary: A very fast and robust SQL database server
RPMs:mariadb mariadb-backup mariadb-common mariadb-connect-engine 
mariadb-cracklib-password-check mariadb-devel mariadb-embedded 
mariadb-embedded-devel mariadb-errmsg mariadb-gssapi-server 
mariadb-oqgraph-engine mariadb-pam mariadb-rocksdb-engine mariadb-s3-engine 
mariadb-server mariadb-server-galera mariadb-server-utils mariadb-sphinx-engine 
mariadb-test
Size:232.49 MiB

Package: normalize-0.7.7-28.fc39
Summary: Adjust the volume of audio files to a standard level
RPMs:normalize
Size:271.82 KiB

Package: rust-aes-siv-0.7.0-1.fc39
Summary: AES-SIV Misuse-Resistant Authenticated Encryption Cipher
RPMs:rust-aes-siv+alloc-devel rust-aes-siv+default-devel 
rust-aes-siv+getrandom-devel rust-aes-siv+heapless-devel 
rust-aes-siv+pmac-devel rust-aes-siv+std-devel rust-aes-siv+stream-devel 
rust-aes-siv-devel
Size:84.37 KiB

Package: rust-gix-trace-0.1.2-1.fc39
Summary: Minimal tracing support for gitoxide that can be turned off to zero 
cost
RPMs:rust-gix-trace+default-devel rust-gix-trace+tracing-detail-devel 
rust-gix-trace+tracing-devel rust-gix-trace-devel
Size:41.13 KiB

Package: rust-shellexpand2-2.1.2-1.fc39
Summary: Shell-like expansions in strings
RPMs:rust-shellexpand2+default-devel rust-shellexpand2-devel
Size:28.92 KiB


= DROPPED PACKAGES =
Package: maildirproc-1.0.1-22.fc39
Summary: Sort mail from mail boxes in the maildir format
RPMs:maildirproc
Size:30.49 KiB


= UPGRADED PACKAGES =
Package:  ansible-8.1.0-1.fc39
Old package:  ansible-8.0.0-1.fc39
Summary:  Curated set of Ansible collections included in addition to 
ansible-core
RPMs: ansible
Size: 45.95 MiB
Size change:  1.46 MiB
Changelog:
  * Fri Jun 16 2023 Python Maint  - 8.0.0-2
  - Rebuilt for Python 3.12

  * Thu Jun 22 2023 Maxwell G  - 8.1.0-1
  - Update to 8.1.0.


Package:  ansible-core-2.15.1-1.fc39
Old package:  ansible-core-2.15.0-1.fc39
Summary:  A radically simple IT automation system
RPMs: ansible-core ansible-core-doc
Size: 5.16 MiB
Size change:  5.45 KiB
Changelog:
  * Tue May 23 2023 Yaakov Selkowitz  - 2.15.0-2
  - Disable tests in RHEL builds

  * Tue Jun 13 2023 Maxwell G  - 2.15.0-3
  - Add support for Python 3.12. Fixes rhbz#2196539.
  - Remove conditional Requires on ansible-packaging.

  * Fri Jun 16 2023 Python Maint  - 2.15.0-4
  - Rebuilt for Python 3.12

  * Sat Jun 17 2023 Maxwell G  - 2.15.0-5
  - Add patch to avoid importlib.abc.TraversableResources DeprecationWarning

  * Thu Jun 22 2023 Maxwell G  - 2.15.1-1
  - Update to 2.15.1. Fixes rhbz#2204492.
  - Add Recommends on python3-libdnf5 for Fedora 39


Package:  cppzmq-4.10.0-1.fc39
Old package:  cppzmq-4.9.0-2.fc38
Summary:  Header-only C++ binding for libzmq
RPMs: cppzmq-devel
Size: 168.03 KiB
Size change:  511 B
Changelog:
  * Tue Jul 04 2023 Elliott Sales de Andrade  - 
4.10.0-1
  - Update to latest version (#2216273)


Package:  elfutils-0.189-3.fc39
Old package:  elfutils-0.189-2.fc39
Summary:  A collection of utilities and DSOs to handle ELF files and DWARF 
data
RPMs: elfutils elfutils-debuginfod elfutils-debuginfod-client 
elfutils-debuginfod-client-devel elfutils-default-yama-scope elfutils-devel 
elfutils-libelf elfutils-libelf-devel elfutils-libs
Size: 5.57 MiB
Size change:  -43.47 KiB
Changelog:
  * Thu Jun 22 2023 Mark Wielaard  - 0.189-3
  - Add elfutils-0.189-elf_getdata_rawchunk.patch
  - Add elfutils-0.189

Re: How to deal with sysusers files inside the package

2023-07-04 Thread Ewoud Kohl van Wijngaarden

On Fri, Jun 30, 2023 at 10:15:35PM +0200, Björn Persson wrote:

Ewoud Kohl van Wijngaarden wrote:

I'm looking at converting my package (where I'm also the upstream) to
use sysusers.d but I'd prefer shipping the sysusers.d file inside the
source tarball rather than in packaging. This allows me to use the same
definition on Debian, which I think is a huge benefit of systemd
standardizing these kinds of things.


Yes, of course you'd want to do it that way, but Fedora isn't ready.


I got the same impression.


The documentation[1] only mentions shipping it as a separate source, not
inside the tarball. Should I simply replace %{SOURCE3} in the docs with
the path from the extracted tarball?


My experience is that sysusers_create_compat can't be made to work with
a file extracted from the tarball. It requires a separate source file.
As long as user and group accounts must be added in the packaging, it's
more convenient to do it in the spec file than in a separate sysusers
file. Thus sysusers_create_compat seems rather useless to me.


I wouldn't say completely useless, but useless in the ideal case.


If your program needs its user account only at run time (such as a
daemon that runs as non-root), then it's enough to drop the sysusers
file into /usr/lib/sysusers.d. The account will then be created at the
end of the RPM transaction, after all the packages have been installed.
In that case shipping the sysusers file inside the tarball should work,
and you don't need sysusers_create_compat.

If your package contains any files owned by the account it creates,
then installing the sysusers file is not sufficient. In that case the
account must be created in %pre before the files are installed, either
with sysusers_create_compat (which requires a separate source file) or
with plain old useradd or groupadd.


Sadly, this is the case (owning /var/lib/%{name}).


I've seen some discussion recently about integrating sysusers support
into RPM. That should allow an upstream sysusers file to work in all
cases, if I understand correctly. If your package currently works, then
I suggest waiting until the RPM integration is done before you change
how user accounts are created.


Thanks for the advice.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: OCaml 5 rebuild and i686

2023-07-04 Thread Stephen Smoogen
On Tue, 4 Jul 2023 at 03:39, Richard W.M. Jones  wrote:

> We're planning to rebuild all the OCaml packages + dependencies with
> the new OCaml 5 compiler (https://ocaml.org/releases/5.0.0).  This has
> a rewritten runtime system, and Jerry James has been doing amazing
> work rebuilding everything in a COPR and fixing lots of issues
> (https://copr.fedorainfracloud.org/coprs/jjames/OCaml5/).
>
> There are however three issues with i686.  Firstly there are some
> issues with LTO, possibly solvable.  Secondly there no native code
> backend for i686.  It has been dropped upstream and apparently they
> have no plans to re-add it.
>
> (Native code backends for s390x, riscv64 and ppc64le are also dropped
> in 5.0, but with plans to add those back in 5.1.  They're just taking
> their time to port these ones across to the new architecture.)
>
>
I am not too worried about i686, but the above seems more concerning. What
happens with the tooling for this on these platforms? I believe that
currently the Fedora builders for Power use Fedora as the KVM server using
various virt tools which I believe are Ocaml based.


-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)

2023-07-04 Thread Jiří Konečný


4. července 2023 0:44:41 SELČ, Neal Gompa  napsal:
>On Mon, Jul 3, 2023 at 6:36 PM Jiří Konečný  wrote:
>>
>> Hi, see my replies below.
>>
>> 2. července 2023 23:56:59 SELČ, Demi Marie Obenour  
>> napsal:
>> >On 6/27/23 05:00, Simon de Vlieger wrote:
>> >> On 6/27/23 10:40, Hans de Goede wrote:
>> >>
>> >>  > Ok, so can you provide some instructions for how to make this work ?
>> >> I guess it would be something like add the cmdline option + then start
>> >> some systemd unit ?  Can you please put some instructions for this in
>> >> the testing section of:
>> >> https://fedoraproject.org/wiki/Changes/AnacondaWebUIforFedoraWorkstation
>> >>   (with a note that this is currently not supported / recommended).
>> >>  >
>> >>  >> About the improvements on the Live ISO, that should be a question on
>> >> Fedora Workstation SIG. Anaconda team is not in charge of the
>> >> environment on the Live ISO.
>> >>  >
>> >>  > Well you are suggesting a change that is likely going to
>> >> significantly increase the amount of memory needed to do a livecd
>> >> workstation install and as mentioned above pushing the requirements
>> >> above 2G would basically block this change since 2G RAM is currently the
>> >> advertised minimum RAM requirement for Fedora workstation installs.
>> >>  >
>> >>  > So although I realize this is not entirely fair IMHO if you want to
>> >> push forward with this feature then you may also be on the hook to look
>> >> into reducing the memory footprint elsewhere so that the end result
>> >> still fits in 2G RAM. I have some experience with tweaking the livecd to
>> >> work with less RAM and I'm happy to share my experience in this, but I
>> >> do not have time to actually implement needed changes for this.
>> >> Hi Hans,
>> >>
>> >> it would indeed involve adding the `inst.webui` and `inst.webui.remote`
>> >> kernel command line options and a systemd unit to start the relevant
>> >> services (I *think* that'd only be `cockpit.service`).
>> >
>> >Remote installation is not a solution to the memory bloat.  It only
>> >pushes the problem to whatever machine the browser runs on, and it
>> >has significant and negative security implications.  A solution
>> >here would be ensuring that the web UI uses no more RAM than the
>> >GTK UI that preceded it.
>>
>> Please, take into account that we are not an application which stays open on 
>> background for hours (usually), so you can't put this to the same level as 
>> music player or similar apps.
>> Anyway, I'm pretty sure that every usable machine as desktop PC, is able to 
>> open one web page for the installation process.
>>
>> From the other point, I wonder how much memory the VNC client (solution 
>> right now) is taking. And security point with VNC is (based on my 
>> understanding) maybe worse than HTTPS browsers.
>>
>>
>> Hard to say what technology has the same memory footprint as GTK3. I think, 
>> there are not many options. From the other point, using this logic in the 
>> past, we would still be using ncurses based installations. Don't take me 
>> wrong, I see your point and memory footprint is important. Just saying it is 
>> not the only point you should take into account.
>
>I would also note that the work being done here does not obviate the
>future return of a community-developed graphical frontend for
>Anaconda. For example, the previous architecture made it impossible
>for anyone to consider developing a Qt based frontend for Anaconda.
>That option is now open for the first time in Anaconda's history.
>
>And the GUI could run unprivileged while the Anaconda services run
>privileged in the background, which is required for a Wayland-based
>application anyway.

Good point Neal.

That is correct, if anyone would like to have the ncourses frontend again, you 
can create it yourself. 😃

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


Re: Proposal: drop delta rpms (for real this time)

2023-07-04 Thread Fabio Valentini
On Thu, Jun 22, 2023 at 10:32 AM Matthew Miller
 wrote:
>
> On Mon, Jun 12, 2023 at 09:46:26AM -0700, Kevin Fenzi wrote:
> > I don't think there's a formal change filed yet.
> >
> > Matthew: Did you want to do that? Or would you like me or someone else
> > to do so?
>
> I would love someone else to do so, but if no one else wants to, I can. :)

Well ... has anybody filed a change proposal yet, or should I do that?

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


Re: [HEADS UP] Python 3.12 side tag merging today (and what to do)

2023-07-04 Thread Adam Williamson
On Tue, 2023-07-04 at 16:51 +0200, Tomáš Hrnčiar wrote:
> We have verified the following comps groups are insatllable from the 
> side tag:
> 
> @core
> @critical-path-anaconda
> @critical-path-apps
> @critical-path-base
> @critical-path-build
> @critical-path-deepin-desktop
> @critical-path-gnome
> @critical-path-lxde
> @critical-path-lxqt
> @critical-path-server
> @critical-path-standard
> @critical-path-xfce
> @admin-tools
> @anaconda-tools
> @cloud-server
> @container-management
> @dogtag
> @domain-client
> @fedora-packager
> @freeipa-server
> @headless-management
> @network-server
> @rpm-development-tools
> @smb-server
> @standard
> @system-tools
> @workstation-product
> 
> (That is, all critical-path groups + some more.)

It is missing critical-path-kde at least. Is this a typo, or was it not
checked? KDE is release-blocking, it needs to work.
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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] Python 3.12 side tag merging today (and what to do)

2023-07-04 Thread Adam Williamson
On Tue, 2023-07-04 at 16:51 +0200, Tomáš Hrnčiar wrote:
> Hello.
> 
> As you might already know, we have recently conducted a Python 3.12mass 
> rebuild in aside tag. We plan to ask releng to merge it today, despite 
> several builds not succeeding.

Also, it may be too late for this cycle now, but at least for the
future, I would prefer if we could work in a step in the process where
we ensure the openQA update tests pass against the tag before it is
merged, especially now Rawhide gating is enabled.

If the tag is merged and it turns out to cause failures in the openQA
tests, all other Rawhide updates will fail gating until the failures
are resolved.

I would have to do some degree of work on the scheduler to let it test
an arbitrary tag - right now it can only test by update ID or Koji task
ID - but I could probably do that in a few hours.
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



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


Re: Proposal: drop delta rpms (for real this time)

2023-07-04 Thread Demi Marie Obenour
On 7/4/23 11:49, Fabio Valentini wrote:
> On Thu, Jun 22, 2023 at 10:32 AM Matthew Miller
>  wrote:
>>
>> On Mon, Jun 12, 2023 at 09:46:26AM -0700, Kevin Fenzi wrote:
>>> I don't think there's a formal change filed yet.
>>>
>>> Matthew: Did you want to do that? Or would you like me or someone else
>>> to do so?
>>
>> I would love someone else to do so, but if no one else wants to, I can. :)
> 
> Well ... has anybody filed a change proposal yet, or should I do that?
> 
> Fabio

Do it!  Also include deltarpm=False by default for attack surface reduction.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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] Python 3.12 side tag merging today (and what to do)

2023-07-04 Thread Miro Hrončok

On 04. 07. 23 18:11, Adam Williamson wrote:

On Tue, 2023-07-04 at 16:51 +0200, Tomáš Hrnčiar wrote:

Hello.

As you might already know, we have recently conducted a Python 3.12mass
rebuild in aside tag. We plan to ask releng to merge it today, despite
several builds not succeeding.


Also, it may be too late for this cycle now, but at least for the
future, I would prefer if we could work in a step in the process where
we ensure the openQA update tests pass against the tag before it is
merged, especially now Rawhide gating is enabled.

If the tag is merged and it turns out to cause failures in the openQA
tests, all other Rawhide updates will fail gating until the failures
are resolved.

I would have to do some degree of work on the scheduler to let it test
an arbitrary tag - right now it can only test by update ID or Koji task
ID - but I could probably do that in a few hours.


The side tag is not yet merged, so feel free to do that.

I agree running tests (and runnign the compose) against this would be good.

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


Re: [HEADS UP] Python 3.12 side tag merging today (and what to do)

2023-07-04 Thread Miro Hrončok

On 04. 07. 23 18:08, Adam Williamson wrote:

On Tue, 2023-07-04 at 16:51 +0200, Tomáš Hrnčiar wrote:

We have verified the following comps groups are insatllable from the
side tag:

@core
@critical-path-anaconda
@critical-path-apps
@critical-path-base
@critical-path-build
@critical-path-deepin-desktop
@critical-path-gnome
@critical-path-lxde
@critical-path-lxqt
@critical-path-server
@critical-path-standard
@critical-path-xfce
...

(That is, all critical-path groups + some more.)


It is missing critical-path-kde at least. Is this a typo, or was it not
checked? KDE is release-blocking, it needs to work.


Not sure why it is missing in the list, probably a copy-paste error. It is 
installable as well.


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


Re: OCaml 5 rebuild and i686

2023-07-04 Thread Richard W.M. Jones
On Tue, Jul 04, 2023 at 09:16:52AM -0400, Stephen Smoogen wrote:
> 
> 
> On Tue, 4 Jul 2023 at 03:39, Richard W.M. Jones  wrote:
> 
> We're planning to rebuild all the OCaml packages + dependencies with
> the new OCaml 5 compiler (https://ocaml.org/releases/5.0.0).  This has
> a rewritten runtime system, and Jerry James has been doing amazing
> work rebuilding everything in a COPR and fixing lots of issues
> (https://copr.fedorainfracloud.org/coprs/jjames/OCaml5/).
> 
> There are however three issues with i686.  Firstly there are some
> issues with LTO, possibly solvable.  Secondly there no native code
> backend for i686.  It has been dropped upstream and apparently they
> have no plans to re-add it.
> 
> (Native code backends for s390x, riscv64 and ppc64le are also dropped
> in 5.0, but with plans to add those back in 5.1.  They're just taking
> their time to port these ones across to the new architecture.)
> 
> 
> 
> I am not too worried about i686, but the above seems more concerning. What
> happens with the tooling for this on these platforms? I believe that currently
> the Fedora builders for Power use Fedora as the KVM server using various virt
> tools which I believe are Ocaml based. 

Hopefully nothing!  It'll run the bytecode version which is slower,
but should otherwise work.

We could do this for i686 too, but the issue is there's *never* going
to be a fast version again for i686.

Rich.

> 
> --
> Stephen Smoogen, Red Hat Automotive
> Let us be kind to one another, for most of us are fighting a hard battle. --
> Ian MacClaren

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


-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: [HEADS UP] Python 3.12 side tag merging today (and what to do)

2023-07-04 Thread Steven A. Falco

On 7/4/23 10:51 AM, Tomáš Hrnčiar wrote:

## How to run things locally?

You can use mock. Make sure to:
     1. Clear all caches first: $ mock -r fedora-rawhide-x86_64--scrub=all
     2. Use the Koji repo: $ mock -r fedora-rawhide-x86_64 --enablerepo=local 
...


That doesn't appear correct.  At least I still get 3.11 when I try.  I assume I 
need to refer to the side tag instead.

Also there is a typo - there needs to be a space between fedora-rawhide-x86_64 
and --scrub=all :-)

Steve
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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] Python 3.12 side tag merging today (and what to do)

2023-07-04 Thread Miro Hrončok

On 04. 07. 23 20:11, Steven A. Falco wrote:

On 7/4/23 10:51 AM, Tomáš Hrnčiar wrote:

## How to run things locally?

You can use mock. Make sure to:
 1. Clear all caches first: $ mock -r fedora-rawhide-x86_64--scrub=all
 2. Use the Koji repo: $ mock -r fedora-rawhide-x86_64 --enablerepo=local 
...


That doesn't appear correct.  At least I still get 3.11 when I try.  I assume I 
need to refer to the side tag instead.


This will only work once the side tag is actually merged. I have requested the 
merge from releng but I cannot do it myself.


Also there is a typo - there needs to be a space between fedora-rawhide-x86_64 
and --scrub=all :-)


Indeed. Thanks for spotting this and sorry about that.

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


Re: [HEADS UP] Python 3.12 side tag merging today (and what to do)

2023-07-04 Thread Mattia Verga via devel
Il 04/07/23 16:51, Tomáš Hrnčiar ha scritto:

> Many packages only fail to build because their dependencies were not yet 
> rebuilt. Chances are, you will get an automated F39FailsToInstall bugzilla 
> soon, indicating your package fails to install. It would be really helpful if 
> you could find the missing dependency and mark the bugzilla for your package 
> depending on the bugzilla for the missing dep. We plan to do that as well, 
> but your help is crucial here.

Well, python-robosignatory build fails because tests are failing due to a 
broken python-crochet: the latter has been marked to have been built fine, 
however due to a really old version available in Fedora repositories, it will 
not work. Not sure why python-crochet tests have not failed, but the current 
version still has 'import imp' which were removed in python 3.12.

Maybe there are other packages depending on crochet affected as well.

Mattia___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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] Python 3.12 side tag merging today (and what to do)

2023-07-04 Thread Adam Williamson
On Tue, 2023-07-04 at 18:29 +0200, Miro Hrončok wrote:
> On 04. 07. 23 18:11, Adam Williamson wrote:
> > On Tue, 2023-07-04 at 16:51 +0200, Tomáš Hrnčiar wrote:
> > > Hello.
> > > 
> > > As you might already know, we have recently conducted a Python 3.12mass
> > > rebuild in aside tag. We plan to ask releng to merge it today, despite
> > > several builds not succeeding.
> > 
> > Also, it may be too late for this cycle now, but at least for the
> > future, I would prefer if we could work in a step in the process where
> > we ensure the openQA update tests pass against the tag before it is
> > merged, especially now Rawhide gating is enabled.
> > 
> > If the tag is merged and it turns out to cause failures in the openQA
> > tests, all other Rawhide updates will fail gating until the failures
> > are resolved.
> > 
> > I would have to do some degree of work on the scheduler to let it test
> > an arbitrary tag - right now it can only test by update ID or Koji task
> > ID - but I could probably do that in a few hours.
> 
> The side tag is not yet merged, so feel free to do that.

I will do this after I'm done with something else (lorax builds for the
linux-firmware rename issue), but it's a bit of a "race against time" -
I have to implement testing of a tag in the openQA scheduler and tests,
which I haven't done before, and if the merge gets done while I'm
working on it, it'll be wasted work to a degree. :D
> 
> I agree running tests (and runnign the compose) against this would be good.

The openQA tests include building a network install image, two live
images and a Silverblue installer image, so they do catch *most* things
that can go wrong with a compose (though not everything). Running a
test compose would be great if releng can do that.
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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] Python 3.12 side tag merging today (and what to do)

2023-07-04 Thread Sandro

On 04-07-2023 16:51, Tomáš Hrnčiar wrote:
As you might already know, we have recently conducted a Python 3.12mass 
rebuild in aside tag. We plan to ask releng to merge it today, despite 
several builds not succeeding. We always aim for some compromise between 
having the side tag open for too long and having too many failures.We 
belive this time it was open logn enough and the remaining failures can 
be fixed after the merge. ~3370 out of ~4040 source packages were 
successfully built.


First of all, thanks for all the work you did introducing Python 3.12.

How did you determine which packages to build in the side tag?

I see one of my packages, python-fvs, in the list of failed builds. I'm 
also one of the maintainers of Bottles, which requires python-fvs. 
Bottles itself is mostly Python code. I would have expected Bottles to 
be rebuild as well. With python-fvs failing, Bottles should fail to install.


But bottles never received the 'Rebuilt for Python 3.12' commit. Most 
interestingly, neither did python-fvs. But it is on the list of failed 
builds.


For both packages I don't see a build by any of the Python folks with 
'koji list-builds --package $PACKAGE --pattern \*fc39'


So, I'm a bit confused.

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


Re: [HEADS UP] Python 3.12 side tag merging today (and what to do)

2023-07-04 Thread Adam Williamson
On Tue, 2023-07-04 at 12:21 -0700, Adam Williamson wrote:
> On Tue, 2023-07-04 at 18:29 +0200, Miro Hrončok wrote:
> > On 04. 07. 23 18:11, Adam Williamson wrote:
> > > On Tue, 2023-07-04 at 16:51 +0200, Tomáš Hrnčiar wrote:
> > > > Hello.
> > > > 
> > > > As you might already know, we have recently conducted a Python 3.12mass
> > > > rebuild in aside tag. We plan to ask releng to merge it today, despite
> > > > several builds not succeeding.
> > > 
> > > Also, it may be too late for this cycle now, but at least for the
> > > future, I would prefer if we could work in a step in the process where
> > > we ensure the openQA update tests pass against the tag before it is
> > > merged, especially now Rawhide gating is enabled.
> > > 
> > > If the tag is merged and it turns out to cause failures in the openQA
> > > tests, all other Rawhide updates will fail gating until the failures
> > > are resolved.
> > > 
> > > I would have to do some degree of work on the scheduler to let it test
> > > an arbitrary tag - right now it can only test by update ID or Koji task
> > > ID - but I could probably do that in a few hours.
> > 
> > The side tag is not yet merged, so feel free to do that.
> 
> I will do this after I'm done with something else (lorax builds for the
> linux-firmware rename issue), but it's a bit of a "race against time" -
> I have to implement testing of a tag in the openQA scheduler and tests,
> which I haven't done before, and if the merge gets done while I'm
> working on it, it'll be wasted work to a degree. :D
> > 
> > I agree running tests (and runnign the compose) against this would be good.
> 
> The openQA tests include building a network install image, two live
> images and a Silverblue installer image, so they do catch *most* things
> that can go wrong with a compose (though not everything). Running a
> test compose would be great if releng can do that.

For the record, I won the race to get the tests running before the
merge happened, and so far we've found:

* mock was broken because it uses imp (removed in 3.12)
* installer image build failed because system-storage-manager rebuild
for 3.12 failed
* FreeIPA server deployment fails (I'll investigate this one next)

So, testing the side tag before merging it definitely seems like it was
a good idea. :D Let's write it into the SOP for the future. Now I've
written the support into the tests and scheduler it is trivial to run
the tests whenever desired (someone with the necessary powers just has
to run `fedora-openqa tag f39-python 39`, modify as appropriate for the
future (the first arg is the tag name, the second is the release
number).
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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] Python 3.12 side tag merging today (and what to do)

2023-07-04 Thread Maxwell G
On Tue Jul 4, 2023 at 23:45 +0200, Sandro wrote:

> I see one of my packages, python-fvs, in the list of failed builds. I'm 
> also one of the maintainers of Bottles, which requires python-fvs. 
> Bottles itself is mostly Python code. I would have expected Bottles to 
> be rebuild as well. With python-fvs failing, Bottles should fail to install.
>
> But bottles never received the 'Rebuilt for Python 3.12' commit. Most 
> interestingly, neither did python-fvs. But it is on the list of failed 
> builds.

AFAIK, the rebuild scripts only rebuild packages whose dependencies are
available. python-fvs depends on python3-orjson which fails to build
with Python 3.12. Its tests segfault. I opened [1] upstream. bottles
then depends on python3-fvs so that wasn't rebuilt either.


[1]: https://github.com/ijl/orjson/issues/400


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


Re: [HEADS UP] Python 3.12 side tag merging today (and what to do)

2023-07-04 Thread Miro Hrončok

On 05. 07. 23 0:06, Maxwell G wrote:

AFAIK, the rebuild scripts only rebuild packages whose dependencies are
available.


Exactly.

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


Re: [HEADS UP] Python 3.12 side tag merging today (and what to do)

2023-07-04 Thread Sandro

On 05-07-2023 00:06, Maxwell G wrote:

On Tue Jul 4, 2023 at 23:45 +0200, Sandro wrote:


I see one of my packages, python-fvs, in the list of failed builds. I'm
also one of the maintainers of Bottles, which requires python-fvs.
Bottles itself is mostly Python code. I would have expected Bottles to
be rebuild as well. With python-fvs failing, Bottles should fail to install.

But bottles never received the 'Rebuilt for Python 3.12' commit. Most
interestingly, neither did python-fvs. But it is on the list of failed
builds.


AFAIK, the rebuild scripts only rebuild packages whose dependencies are
available. python-fvs depends on python3-orjson which fails to build
with Python 3.12. Its tests segfault. I opened [1] upstream. bottles
then depends on python3-fvs so that wasn't rebuilt either.


So, python-fvs fails to build solely because python-orjson is not 
available. And that is determined before the package is even build. 
Smart! ;)
Albeit, it's a bit misleading, since the package wasn't really build. I 
was interested to learn why python-fvs failed to build. That's why I 
went looking for the build.


But what about Bottles? It was never built in f39-python either and 
python-fvs is not a build requirement for Bottles, only a runtime 
requirement. Does that also exclude it from being build in the side-tag?


I guess I just (have to) wait for FTBFS/FTI bug reports after the side 
tag is merged.


Sorry, if all that is obvious to experienced packagers. It's the first 
time for me that I'm going through a mass rebuild as a package maintainer.



[1]: https://github.com/ijl/orjson/issues/400


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


Re: [HEADS UP] Python 3.12 side tag merging today (and what to do)

2023-07-04 Thread Fabio Valentini
On Wed, Jul 5, 2023, 00:07 Maxwell G  wrote:

> On Tue Jul 4, 2023 at 23:45 +0200, Sandro wrote:
> 
> > I see one of my packages, python-fvs, in the list of failed builds. I'm
> > also one of the maintainers of Bottles, which requires python-fvs.
> > Bottles itself is mostly Python code. I would have expected Bottles to
> > be rebuild as well. With python-fvs failing, Bottles should fail to
> install.
> >
> > But bottles never received the 'Rebuilt for Python 3.12' commit. Most
> > interestingly, neither did python-fvs. But it is on the list of failed
> > builds.
>
> AFAIK, the rebuild scripts only rebuild packages whose dependencies are
> available. python-fvs depends on python3-orjson which fails to build
> with Python 3.12. Its tests segfault. I opened [1] upstream. bottles
> then depends on python3-fvs so that wasn't rebuilt either.
>

I suspect this will require pyo3 0.19, since only this version has the
change to adapt to PyASCIIObject struct layout changes in Python 3.12 ...

https://github.com/PyO3/pyo3/commit/88b46a702986a7c61169a777ffee8c8e8519667a

Not sure why orjson needs to muck around lowest-level things like that, but
at least I'm not surprised that this can (and will) break. 😅 At least
orjson is the only Rusty Python package that I know of which uses these
APIs, so I don't think any other users of pyo3 in Fedora should be affected.

I'll put working on updating pyo3 on my to-do list for tomorrow.

Fabio

PS: Not at my PC, sent from my phone, sorry for possibly bad html
formatting etc.


>
> [1]: https://github.com/ijl/orjson/issues/400
>
>
> --
> Maxwell G (@gotmax23)
> Pronouns: He/They
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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] Python 3.12 side tag merging today (and what to do)

2023-07-04 Thread Maxwell G
On Wed Jul 5, 2023 at 00:50 +0200, Sandro wrote:
> On 05-07-2023 00:06, Maxwell G wrote:
> > On Tue Jul 4, 2023 at 23:45 +0200, Sandro wrote:
> > 
> >> I see one of my packages, python-fvs, in the list of failed builds. I'm
> >> also one of the maintainers of Bottles, which requires python-fvs.
> >> Bottles itself is mostly Python code. I would have expected Bottles to
> >> be rebuild as well. With python-fvs failing, Bottles should fail to 
> >> install.
> >>
> >> But bottles never received the 'Rebuilt for Python 3.12' commit. Most
> >> interestingly, neither did python-fvs. But it is on the list of failed
> >> builds.
> > 
> > AFAIK, the rebuild scripts only rebuild packages whose dependencies are
> > available. python-fvs depends on python3-orjson which fails to build
> > with Python 3.12. Its tests segfault. I opened [1] upstream. bottles
> > then depends on python3-fvs so that wasn't rebuilt either.
>
> So, python-fvs fails to build solely because python-orjson is not 
> available. And that is determined before the package is even build. 
> Smart! ;)
> Albeit, it's a bit misleading, since the package wasn't really build. I 
> was interested to learn why python-fvs failed to build. That's why I 
> went looking for the build.

Yeah. Technically, it does fail to build from source (if you tried to
build it, it would fail at the dnf builddep stage). It's a bit
counterintuitive, but it makes more sense that wasting koji resources to
rebuild something that you know will fail.

> But what about Bottles? It was never built in f39-python either and 
> python-fvs is not a build requirement for Bottles, only a runtime 
> requirement. Does that also exclude it from being build in the side-tag?

Ah, I was not entirely correct. Looking more closely, bottles doesn't
depend on python(abi) at runtime (i.e. it doesn't install any files into
%{python3_sitelib} and/or %{python3_sitearch}) or link to libpython, so
it isn't part of the rebuild to begin with. It just depends on
/usr/bin/python3. That package does some kooky mason stuff instead of
using standard Python packaging tools, and it isn't tied to a specific
python version. It will FTI once the side tag is merged if python-orjson
and python-fvs aren't built, though.

> Sorry, if all that is obvious to experienced packagers. It's the first 
> time for me that I'm going through a mass rebuild as a package maintainer.

Nah, Python mass rebuilds are a pretty special event :).
Tomáš and Miro gave a good talk about the process at Nest if you're
curious: https://www.youtube.com/watch?v=0ODrMrYnDYs

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


Re: How to use llvm15 for building a package

2023-07-04 Thread Luya Tshimbalanga
> On 7/3/23 19:37, Luya Tshimbalanga wrote:
> 
> When I try to build from the rawhide branch, I get:
> 
> /usr/include/OpenImageIO/detail/fmt/core.h:1691: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
> 
> This seems like a failure unrelated to clang.  Have you run into this?
> 
> -Tom
 
I confirm I run the same issue once I properly set parameters for building on 
cmake (  -DLLVM_ROOT=%{_libdir}/llvm15 \
   -DLLVM_BC_GENERATOR='clang++' \).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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] Python 3.12 side tag merging today (and what to do)

2023-07-04 Thread Miro Hrončok

On 04. 07. 23 16:51, Tomáš Hrnčiar wrote:

Hello.

As you might already know, we have recently conducted a Python 3.12mass rebuild 
in aside tag. We plan to ask releng to merge it today, despite several builds 
not succeeding.


This has not happened yet, see https://pagure.io/releng/issue/11451 for 
progress update.


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


Orphaning imgbased package

2023-07-04 Thread Sandro Bonazzola
Hi, I orphaned the imgbased package. The package is part of the oVirt
project and as far as I can tell nobody is using it on Fedora.
The oVirt project has been developed by almost only Red Hat over the past
few years and starting last year Red Hat also started offboarding the
project.
Nobody stepped in to maintain it for over a year so I don't see value in
investing time keeping the package in Fedora.

-- 

Sandro Bonazzola

MANAGER, SOFTWARE ENGINEERING - Red Hat In-Vehicle Operating System

Red Hat EMEA 

sbona...@redhat.com


*Red Hat respects your work life balance. Therefore there is no need to
answer this email out of your office hours.*
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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


Flock CFP: Language SIGs discussion

2023-07-04 Thread Jens-Ulrik Petersen
I have submitted a Flock proposal to have a common discussion session for
(modern) Language SIGs. I think for this to be successful we need
representatives from various Language SIGs to be there (Rust, Haskell,
OCaml, Golang and of course Python and older ecosystems like Perl, R, TeX
come to mind immediately - surely there are more). Language packaging
experts are also welcome of course independently or affiliated to one or
more language SIGs. Of course I also hope there will be broad attendance by
interested contributors.

The idea is to talk about common and distinct problems faced, both to learn
from each other and to come up with practical ideas and plans for generally
easing Fedora's mass packaging efforts.

If you plan to be at Flock and are willing and able to represent your
Language SIG at this Flock session do please reply or reach out to me. I
think each SIG could do a brief presentation there to kick off the dialogue.

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