Re: Interest in taking ownership of unison package

[Richard W.M. Jones]

On Thu, Apr 25, 2024 at 02:19:36AM -, Matthew Krupcale wrote:
> Hello all,
>
> I am interested in taking ownership of the unison package [1]. The
> most recent discussion on this topic of which I'm aware is from
> 2018-05 [2], which was attempting to bring all of the various unison
> versions [3-5] packaged in Fedora into a single spec file. That
> never happened, and those packages were retired in 2020-09.

This is the latest email I think:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/DIGCQ5ON6DAGUJVHIS3RDRU3C6QGXIFM/

But yes, looks like you've got most of the important references
already.

If you do re-add Unison, please let me & Jerry James know because
we'll have to add it to the list of OCaml packages that get rebuilt
whenever OCaml is updated.

> Since then, as of version 2.52 (2022-03), unison has become
> considerably more forward and backward version-compatible, not only
> between clients and servers of different unison versions but also
> when compiled with different OCaml compiler versions, as explained
> in the manual [6].

About time!

Rich.

> I have already done some test builds of this new package version on F38-F41 
> [7] and EPEL 9 [8] COPR and tested it on the latter. Debian stable already 
> appears to have unison v2.52, and testing has v2.53, so this should also work 
> well with Debian [9].
> 
> Thoughts?
> 
> Matthew
> 
> [1] https://src.fedoraproject.org/rpms/unison
> [2] 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/RBOQEJY4QHNPDUTUU7GCNVJLNEH6JYKN/#RBOQEJY4QHNPDUTUU7GCNVJLNEH6JYKN
> [3] https://src.fedoraproject.org/rpms/unison213
> [4] https://src.fedoraproject.org/rpms/unison227
> [5] https://src.fedoraproject.org/rpms/unison240
> [6] 
> https://github.com/bcpierce00/unison/blob/5f07978c23d113b3ec8dbbd59d00e1e1632823f6/doc/unison-manual.tex#L215
> [7] https://copr.fedorainfracloud.org/coprs/mkrupcale/unison/build/7331891/
> [8] 
> https://copr.fedorainfracloud.org/coprs/mkrupcale/rhel-9-unison/build/7332237/
> [9] https://packages.debian.org/search?keywords=unison
> --
> ___
> 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
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: Fedora RISC-V port needs to put shared objects into /usr/lib64/lp64d

[Richard W.M. Jones]

On Mon, Apr 22, 2024 at 12:07:38PM +0200, Florian Weimer wrote:
> * Daniel P. Berrangé:
> 
> > On Fri, Apr 19, 2024 at 02:21:57PM +0200, Florian Weimer wrote:
> >> There are multiple PRs and patches floating around that make RISC-V use
> >> the /usr/lib64 directory, like other 64-bit ports.  However, RISC-V
> >> recommends to use /usr/lib64/lp64d for the Fedora ABI variant, and
> >> various upstream projects follow that.
> >> 
> >> I think we should follow upstream, so that it's possible to use Fedora
> >> to do upstream development without patching the sources, or elaborate
> >> Fedora-specific configure invocations.
> >
> > I'm not convinced that using /usr/lib64/lp64d would lead to
> > *less* patching.
> >
> > Apps targetting Fedora are long used to having to adapt from
> > using /usr/lib to /usr/lib64.
> 
> But that's largely baked into the upstream defaults by now (unlike the
> Debian multi-arch paths).
> 
> > Introducing the use of /usr/lib64/lp64d instead, just for RiscV, feels
> > likely to break expectations resulting in apps which build fine on all
> > Fedora arches except for RiscV
> 
> I don't want us to have RPM spec file hacks just to get RISC-V to
> install in the correct locations.  The symbolic link evidently does not
> cover all cases.

What cases aren't covered by the symlink?  We have a full, working
Fedora/RISC-V distro using it at the moment.

Rich.

> Whatever we do, it should be upstream.  Maybe convince RISC-V to adopt
> /usr/lib64.  Or have the RISC-V folks implement automated detection of
> path layout in autotools, Meson etc., so that out of the box, both paths
> work.
> 
> Thanks,
> Florian
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue

-- 
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: Fedora RISC-V port needs to put shared objects into /usr/lib64/lp64d

[Richard W.M. Jones]

On Sun, Apr 21, 2024 at 06:51:02AM +0300, David Abdurachmanov wrote:
> On Sun, Apr 21, 2024 at 2:19 AM Kevin Kofler via devel
>  wrote:
> >
> > David Abdurachmanov wrote:
> > > We currently use a symlink (as Richard) mentioned, but it's not ideal
> > > and causes problems (e.g. meson generates wrong paths breaking some
> > > packages [one example: libplacebo]).
> >
> > Which I would say is a bug in Meson and should be fixed there.
> >
> > I do not think having /usr/lib64/lp64d be a symlink to /usr/lib64 is in
> > violation of any standard.
> >
> 
> Correct.
> 
> If you are interested in more details we have a PR/discussion here:
> https://github.com/mesonbuild/meson/pull/12808

Whether or not this particular PR is correct, the attitude of the
Meson author displayed there made me not want to port any projects to it.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
--
___
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 RISC-V port needs to put shared objects into /usr/lib64/lp64d

[Richard W.M. Jones]

On Fri, Apr 19, 2024 at 02:21:57PM +0200, Florian Weimer wrote:
> There are multiple PRs and patches floating around that make RISC-V use
> the /usr/lib64 directory, like other 64-bit ports.  However, RISC-V
> recommends to use /usr/lib64/lp64d for the Fedora ABI variant, and
> various upstream projects follow that.
> 
> I think we should follow upstream, so that it's possible to use Fedora
> to do upstream development without patching the sources, or elaborate
> Fedora-specific configure invocations.  The other reasons is to
> future-proof the Fedora port against the arrival of an alternative ABI
> that is not fully backwards-compatible (the same reason why the official
> RISC-V documentation requires use of these paths).

Currently /usr/lib64/lp64d is a symlink to /usr/lib64:

$ ls -ld /usr/lib64/lp64d
lrwxrwxrwx 1 root root 1 Jan 16 00:00 /usr/lib64/lp64d -> .

(link is created in the glibc package).

Seems to be the best of both worlds?

TBH I'm not convinced that /usr/lib64/lp64d is a good idea, or any
major difference like this from other architectures, or that there
will be other ABIs that will have to be parallel installable.  (We
might, I suppose, change the ABI in future, but then we'd have to
recompile everything, same as we'd do on any other architecture.)

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
--
___
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: clang: error: unsupported argument 'gnu2' to option '-mtls-dialect=' for target 'x86_64-redhat-linux-gnu'

[Richard W.M. Jones]

On Mon, Apr 15, 2024 at 06:49:54AM -0700, Tom Stellard wrote:
> On 4/15/24 02:55, Richard W.M. Jones wrote:
> >
> >Anyone got any idea about this build failure?
> >
> >https://koji.fedoraproject.org/koji/taskinfo?taskID=116395331
> >
> >[+] All set and ready to build.
> >clang: warning: -Wl,-z,relro: 'linker' input unused 
> >[-Wunused-command-line-argument]
> >clang: warning: -Wl,--as-needed: 'linker' input unused 
> >[-Wunused-command-line-argument]
> >clang: warning: -Wl,-z,pack-relative-relocs: 'linker' input unused 
> >[-Wunused-command-line-argument]
> >clang: warning: -Wl,-z,now: 'linker' input unused 
> >[-Wunused-command-line-argument]
> >clang: warning: -Wl,--build-id=sha1: 'linker' input unused 
> >[-Wunused-command-line-argument]
> >clang: warning: -ldl: 'linker' input unused [-Wunused-command-line-argument]
> >clang: warning: -lrt: 'linker' input unused [-Wunused-command-line-argument]
> >clang: warning: -lm: 'linker' input unused [-Wunused-command-line-argument]
> >clang: error: unsupported argument 'gnu2' to option '-mtls-dialect=' for 
> >target 'x86_64-redhat-linux-gnu'
> >
> >AFAICT -mtls-dialect=gnu2 is not added by anything in the spec file or
> >in AFL++ sources, so it must be coming from RPM macros?
> >
> 
> Are you building with both gcc and clang?  If you are only building with 
> clang, you
> should use the toolchain macro which will ensure you get the correct flags;
> 
> %global toolchain clang

Unfortunately the AFL "build system" (which would be more accurately
described as "big pile of semi-documented Makefiles") is rather
obtuse.  However it does need to build for both GCC and Clang so I
don't think this will work.

Also builds differently on x86_64 and !x86_64, although I disabled
!x86_64 for now as it was too much trouble.  And it doesn't work
upstream with LLVM18, so I am having to use LLVM17 in Rawhide.

If you want to take a look and suggest improvements please be my guest:

https://src.fedoraproject.org/rpms/american-fuzzy-lop/tree/rawhide

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
--
___
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 aarapov

[Richard W.M. Jones]

(Adding Eugene for increased visibility)

On Mon, Apr 15, 2024 at 02:38:01PM +0200, Anton Arapov wrote:
> Hello Lichen,
> 
> I commented on the issue. Apologies, I didn’t spot it earlier;
> https://pagure.io/find-inactive-packagers/issue/1695
> 
> https://pagure.io/user/esyr Eugene Syromiatnikov, should be looking after 
> dmidecode; He should be with Red Hat still.

About dmidecode, it's currently shown with just Anton as packager:

https://src.fedoraproject.org/rpms/dmidecode

If Eugene wishes to co-maintain we should add him.

Lichen Liu and Coiby Xu are Red Hat associates & kernel devs who are
maintaining this package in RHEL, and they have expressed a wish to
co-maintain it also:

https://pagure.io/packager-sponsors/issue/644

Note this is not either-or, you can all co-maintain it together if you
want, but the package currently seems unmaintained.

Rich.

> Anton.
> 
> > On 15. 4. 2024, at 4:28, Lichen Liu  wrote:
> > 
> > Hello devel-list!
> > 
> > Does anyone know how to contact @aarapov, the maintainer of dmidecode?
> > 
> > Bug: https://bugzilla.redhat.com/show_bug.cgi?id=2275034
> > 
> > I haven't seen any activity recently, and there is a 
> > find-inactive-packagers ticket:
> > 
> > https://pagure.io/find-inactive-packagers/issue/1695
> > 
> > Dmidecode is a very important package, I want to keep it updated.
> > 
> > Thanks
> > 
> > Lichen
> > 

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
--
___
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: clang: error: unsupported argument 'gnu2' to option '-mtls-dialect=' for target 'x86_64-redhat-linux-gnu'

[Richard W.M. Jones]

On Mon, Apr 15, 2024 at 10:55:34AM +0100, Richard W.M. Jones wrote:
> 
> Anyone got any idea about this build failure?
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=116395331
> 
> [+] All set and ready to build.
> clang: warning: -Wl,-z,relro: 'linker' input unused 
> [-Wunused-command-line-argument]
> clang: warning: -Wl,--as-needed: 'linker' input unused 
> [-Wunused-command-line-argument]
> clang: warning: -Wl,-z,pack-relative-relocs: 'linker' input unused 
> [-Wunused-command-line-argument]
> clang: warning: -Wl,-z,now: 'linker' input unused 
> [-Wunused-command-line-argument]
> clang: warning: -Wl,--build-id=sha1: 'linker' input unused 
> [-Wunused-command-line-argument]
> clang: warning: -ldl: 'linker' input unused [-Wunused-command-line-argument]
> clang: warning: -lrt: 'linker' input unused [-Wunused-command-line-argument]
> clang: warning: -lm: 'linker' input unused [-Wunused-command-line-argument]
> clang: error: unsupported argument 'gnu2' to option '-mtls-dialect=' for 
> target 'x86_64-redhat-linux-gnu'
> 
> AFAICT -mtls-dialect=gnu2 is not added by anything in the spec file or
> in AFL++ sources, so it must be coming from RPM macros?

Never mind, I see what it is, it's from redhat-rpm-config-288-1.fc41.noarch:

$ rpm --eval '%{optflags}'
... -mtls-dialect=gnu2 ...

which clang 18 doesn't understand.

Rich.

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

clang: error: unsupported argument 'gnu2' to option '-mtls-dialect=' for target 'x86_64-redhat-linux-gnu'

[Richard W.M. Jones]

Anyone got any idea about this build failure?

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

[+] All set and ready to build.
clang: warning: -Wl,-z,relro: 'linker' input unused 
[-Wunused-command-line-argument]
clang: warning: -Wl,--as-needed: 'linker' input unused 
[-Wunused-command-line-argument]
clang: warning: -Wl,-z,pack-relative-relocs: 'linker' input unused 
[-Wunused-command-line-argument]
clang: warning: -Wl,-z,now: 'linker' input unused 
[-Wunused-command-line-argument]
clang: warning: -Wl,--build-id=sha1: 'linker' input unused 
[-Wunused-command-line-argument]
clang: warning: -ldl: 'linker' input unused [-Wunused-command-line-argument]
clang: warning: -lrt: 'linker' input unused [-Wunused-command-line-argument]
clang: warning: -lm: 'linker' input unused [-Wunused-command-line-argument]
clang: error: unsupported argument 'gnu2' to option '-mtls-dialect=' for target 
'x86_64-redhat-linux-gnu'

AFAICT -mtls-dialect=gnu2 is not added by anything in the spec file or
in AFL++ sources, so it must be coming from RPM macros?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
--
___
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: F41 Change Proposal - Reproducible Package Builds (System-Wide)

[Richard W.M. Jones]

On Fri, Apr 12, 2024 at 10:41:43PM +0100, Aoife Moloney wrote:
> [https://github.com/keszybz/add-determinism add-determinism] is a Rust
> program which, as its name suggests, adds determinism to files that
> are given as input by attempting to standardize metadata contained in
> binary or source files to ensure consistency and clamping to
> $SOURCE_DATE_EPOCH in all instances. `add-determinism` is the "Fedora
> version" of [https://salsa.debian.org/reproducible-builds/strip-nondeterminism
> strip-nondeterminism] from the Debian project. Since
> strip-nondeterminism is written in perl, it is undesirable for use in
> Fedora, as we don't want to pull perl in the buildroot for every
> package.

https://github.com/keszybz/add-determinism looks like a package with a
lot of Rust dependencies just to make some small changes to four
different file types.  Isn't there an easier way to do this?  I would
have thought a Python library would be more suitable as the most
complicated bit is the *.pyc change which is done using Python code.

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: F41 Change Proposal - Python Built with gcc -03 (self-contained)

[Richard W.M. Jones]

On Sat, Apr 13, 2024 at 10:18:03AM +0200, Miro Hrončok wrote:
> On 13. 04. 24 10:04, Miro Hrončok wrote:
> >On 13. 04. 24 2:33, Kevin Kofler via devel wrote:
> >>How much larger is Python at -O3 compared to -O2? And other packages?
> >
> >That is a good question, will measure.
> 
> -O2 RPM size:
> python3-3.12.2-3.fc41.x86_6432638
> python3-libs-3.12.2-3.fc41.x86_644246
> 
> -O3 RPM size:
> python3-3.12.2-3.O3.fc41.x86_64 32638
> python3-libs-3.12.2-3.O3.fc41.x86_64 43389702
> 
> Difference of python3-libs:
> 
> 500856 == 489 kB = 1.1678 % increase in size of pytohn3-libs itself
> or 1.1669 % of python3-libs+python3 combined size.
> 
> (I added this to the change proposal.)

Is it possible you could add compilation time too?  It seems like -O3
will take longer, but it'd be interesting to know how much longer.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
--
___
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: F41 Change Proposal - Python Built with gcc -03 (self-contained)

[Richard W.M. Jones]

On Fri, Apr 12, 2024 at 07:08:36PM -0500, Neal Gompa wrote:
> I would like for us to consider evaluating a global change to -O3. I
> am not convinced that there's a good reason anymore to remain at -O2.

FYI here are the optimizations added by gcc -O3 (over -O2), from
https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html

  -fgcse-after-reload
  -fipa-cp-clone
  -floop-interchange
  -floop-unroll-and-jam
  -fpeel-loops
  -fpredictive-commoning
  -fsplit-loops
  -fsplit-paths
  -ftree-loop-distribution
  -ftree-partial-pre
  -funswitch-loops
  -fvect-cost-model=dynamic
  -fversion-loops-for-strides

Mainly lots of loop optimizations :-)

For clang, -O3 is simply described as this, I can't immediately find
any more detail:

  -O3 Like -O2, except that it enables optimizations that take longer
  to perform or that may generate larger code (in an attempt to make
  the program run faster).

As gcc -Os was mentioned too, that is -O2 with the following
optimizations disabled:

  -falign-functions  -falign-jumps
  -falign-labels  -falign-loops
  -fprefetch-loop-arrays  -freorder-blocks-algorithm=stc

Clang just says:

  -Os Like -O2 with extra optimizations to reduce code size.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

[Richard W.M. Jones]

On Fri, Apr 12, 2024 at 04:50:13PM -0500, Chris Adams wrote:
> Once upon a time, Richard W.M. Jones  said:
> > So the problem with github is they don't allow you to have 2FA on a
> > backup device (or rather, it *is* possible, but the process is
> > ludicrous[1]).  If you have your phone as second FA and lose it then
> > you have to immediately fall back to the piece of paper.
> 
> I haven't seen a site with TOTP 2FA allow multiple TOTP codes, they all
> just store one.  It's trivial to scan the TOTP code into multiple
> devices (depending on the software used, you can sometimes "export" a
> TOTP code from one device to another by showing a QR code on the first
> device), so that's hardly a "ludicrous" method.

I sometimes think how hard it would be to explain all of this to my
mother.  I don't understand why 2FA needs to be so obscure and clumsy
to use.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
--
___
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: Three steps we could take to make supply chain attacks a bit harder

[Richard W.M. Jones]

On Fri, Apr 12, 2024 at 09:47:04AM -0700, Adam Williamson wrote:
> On Thu, 2024-04-11 at 19:52 -0700, Carlos Rodriguez-Fernandez wrote:
> > I was hesitant to have MFA for a while. Imagine losing a phone with tons 
> > of tokens. What a hassle to recover from that. I found it less than 
> > ideal for practical reasons.
> 
> This is one reason most systems provide a sheet of one-time backup
> codes that you're meant to print out and keep in a safe place, for
> recovery from exactly that scenario.
> 
> Alternatively, if you have an old phone or tablet lying around, just
> install an MFA app on that and enrol it too, lock it in a cabinet, then
> if you ever lose your primary phone, use it to recover.

So the problem with github is they don't allow you to have 2FA on a
backup device (or rather, it *is* possible, but the process is
ludicrous[1]).  If you have your phone as second FA and lose it then
you have to immediately fall back to the piece of paper.

[1] https://github.com/orgs/community/discussions/78027

I really hope we can avoid that mistake.

Rich.

> Also, these days, most authenticator apps support some kind of backup
> mechanism. FreeOTP lets you back up to a file (which you should, of
> course, keep somewhere safe and ideally encrypted). Google
> Authenticator can backup To The Cloud.
> -- 
> 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

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
--
___
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" builds fail for rust packages

[Richard W.M. Jones]

On Fri, Apr 05, 2024 at 03:33:35PM +0200, Fabio Valentini wrote:
> On Fri, Apr 5, 2024 at 9:51 AM Michael J Gruber  
> wrote:
> >
> > So you're saying that those packages are in the repos for everyone but
> > not meant to be installed by anyone (besides mock chroots), and that is
> > how and why they are packaged.
> 
> Yes. That is the best we can do given how cargo + Rust work.
> 
> > `This package contains library source intended for building other packages 
> > which
> > use the "xyz" crate.`
> 
> So the description matches what I said?
> 
> > Unless you `fedpkg local` build it. Or maybe only if you `fedpkg
> > mockbuild` it. Does a rebuild from `fedpkg srpm` even work?
> >
> > Wow!
> 
> Sorry to burst your bubble, but "fedpkg local" is an ugly hack
> (independent of Rust peculiarities).

fedpkg local works fine for almost all cases.

> And I am not interested in adding workarounds to the Rust packaging
> toolchain to support it.
> 
> "fedpkg mockbuild" and "fedpkg srpm" all work as expected ...
> 
> > Is there any other set of packages which we package like that?
> 
> Probably golang ... maybe Haskell, OCaml?

OCaml is definitely _not_ packaged like this.  ocaml-* and
ocaml-*-devel packages are normal packages that can be installed by
end users if they want, although usually only if they're developing
OCaml software.

Rich.

> > If that is how you do things for the rust eco-system, those "devel"
> > packages should be clearly distinguished from real development packages,
> > come with a huge boiler plate "do not install" - or, really, be in a
> > separate repo if installing them is both worthless and misleading for
> > any "real" user. CRB for Fedora material.
> 
> You just pasted the package description above. What more do you want?
> It clearly states that the purpose of the packages is to build other packages.
> 
> Also, Fedora won't do split repos (been there, done that), and stuff
> like it doesn't even work that well in RHEL (and causes all sorts of
> issues).
> 
> While I agree that the situation is not ideal, I still think this is
> the best that we can do:
> 
> 1. We don't want Rust applications to vendor their dependencies
> 2. Rust can only do static linking (for now)
> -> Dependencies can only be shipped as source code, not as compiled artifacts.
> 
> And while you *can* use packaged Rust crates for local development if
> you really want, it's not really a supported use case.
> 
> 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

-- 
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: convert everything to rpmautospec?

[Richard W.M. Jones]

On Mon, Apr 08, 2024 at 12:22:35AM +0200, Kevin Kofler via devel wrote:
> Emmanuel Seyman wrote:
> > I've noticed a trend in proposed changes in the way Fedora works.
> 
> I am fed up of this salami tactic as well. When we complain about the new 
> stuff, we invariably get told "don't worry, you don't have to use it, it's 
> all optional", but the plan is always to make it mandatory later. See also 
> 2FA that they are now trying to force on us, taking as an excuse an incident 
> that was demonstrably NOT stopped by 2FA.
> 
> > They start off as as things packagers will not have to use if they do
> > not want to and, over time, become default/forced (Matrix vs IRC,
> 
> To be fair, part of the blame there is to be put on Libera.Chat that 
> unilaterally turned off their Matrix bridge. (Yes, they did give Matrix some 
> time to address the demands they had, but when Matrix told them it was not 
> feasible in such a short time frame, they just first suspended, then 
> permanently blocked the Matrix bridge.) But, and here is where I blame 
> Fedora, instead of just letting the chans on Libera.Chat die and moving 
> everything to Matrix, they should have moved the IRC chans to a network with 
> a working Matrix bridge, such as OFTC (or pretty much anything other than 
> Libera.Chat – I guess even Freenode under its new owners might be an 
> option), then we could still be happily using both technologies 
> interoperably. Instead, we get told to just use Matrix and shut up, which I 
> do not consider acceptable.
> 
> > Discourse, ...).
> 
> There too, I do not see why some discussions are now being directed to 
> Discourse instead of the mailing list. And it is not even working. Most of 
> the pertinent feedback for new Changes still comes on this list, not on 
> Discourse. The developers use this list, Discourse is only for users who do 
> not know how to use a mailing list.

The massive & central problem with discourse (and it's amazing that it
still has not been fixed) is that there's no way to reliably get it to
send me an email when there's a new topic, or even when there's a new
message on an existing topic.  As a result it's completely useless and
invisible to me.

Rich.

> > Perhaps it's time to discuss imposing financial and/or legal penalties
> > when the opt-in nature of the change goes away.
> 
> Who would impose those? And from whom to whom would the money flow? I do not 
> think this can work.
> 
> Kevin Kofler
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
--
___
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: Switching XZ for ZSTD?

[Richard W.M. Jones]

On Thu, Apr 04, 2024 at 02:40:08PM +, Arnie T via devel wrote:
> Hello Rich,
> 
> > There's also the issue that liblzma is widely used and offers specific
> > features which zstd does not[1].
> > 
> > [1] https://github.com/facebook/zstd/issues/395#issuecomment-535875379
> 
> Is that about this?
> 
> https://github.com/facebook/zstd/tree/dev/contrib/seekable_format

If that was part of zstd or even actively being looked at, then yes.

> From a Distro decision viewpoint does an alternative like ZSTD have
> to solve all the problems XZ does to be considered?

There's no such thing as a "distro decision" on this one, as was
explained in the thread already.

Rich.

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

Re: Switching XZ for ZSTD?

[Richard W.M. Jones]

On Thu, Apr 04, 2024 at 01:45:45PM -, Daniel Alley wrote:
> As long as there are existing xz-compressed files in the wild,
> Fedora will need to support consuming them - as long as there is
> software that expects xz compression, Fedora will need to support
> creating them.  It's not going to disappear any time soon, and until
> then we're stuck with xz

There's also the issue that liblzma is widely used and offers specific
features which zstd does not[1].

Rich.

[1] https://github.com/facebook/zstd/issues/395#issuecomment-535875379

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

[Richard W.M. Jones]

On Tue, Apr 02, 2024 at 08:59:32PM +0200, Kevin Kofler via devel wrote:
> Matthew Miller wrote:
> > I sometimes see unit test failures. The developer ran the tests, but not
> > on S390.
> 
> Why would I want a test failure on such an exotic architecture to fail my 
> build?

The architecture is weird enough (big endian!) that it may show your
code has various incorrect assumptions.  We found one the other day
actually:

https://sourceware.org/pipermail/binutils/2024-January/132096.html

Rich.

> The only reason Fedora supports that architecture at all is pressure 
> from IBM. Basically nobody uses it.
> 
> Kevin Kofler
> 
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

[Richard W.M. Jones]

On Tue, Apr 02, 2024 at 12:45:18AM -0700, Gordon Messmer wrote:
> On 2024-04-01 23:59, Gordon Messmer wrote:
> >Now gdb can print the GOT with the paths providing the memory
> >section containing a function.  For example, on a Debian 12 system
> >with liblzma 5.6:
> 
> 
> Purely as trivia, and as I haven't seen it discussed elsewhere, the
> malware steals a different set of symbols on Fedora, where
> RSA_public_decrypt doesn't seem to appear in the GOT at all.  On
> Fedora 40:
> 
> gef➤  got RSA
> 
> GOT protection: Full RelRO | GOT functions: 503
> 
> [0x556ac0b94ff8] RSA_set0_key@OPENSSL_3.0.0  →  0x7f4e95dafce0 :
> /usr/lib64/libcrypto.so.3.2.1
> [0x556ac0b951c0] RSA_bits@OPENSSL_3.0.0  →  0x7f4e95daf0a0 :
> /usr/lib64/libcrypto.so.3.2.1
> [0x556ac0b951e0] EVP_PKEY_set1_RSA@OPENSSL_3.0.0  → 0x7f4e960e23b0 :
> /usr/lib64/liblzma.so.5.6.1
> [0x556ac0b95310] RSA_set0_crt_params@OPENSSL_3.0.0  → 0x7f4e95dafea0
> : /usr/lib64/libcrypto.so.3.2.1
> [0x556ac0b953c8] RSA_size@OPENSSL_3.0.0  →  0x7f4e95daf0b0 :
> /usr/lib64/libcrypto.so.3.2.1
> [0x556ac0b95518] RSA_new@OPENSSL_3.0.0  →  0x7f4e95db3330 :
> /usr/lib64/libcrypto.so.3.2.1
> [0x556ac0b95778] RSA_get0_crt_params@OPENSSL_3.0.0  → 0x7f4e95dae490
> : /usr/lib64/libcrypto.so.3.2.1
> [0x556ac0b95870] RSA_free@OPENSSL_3.0.0  →  0x7f4e95db2f00 :
> /usr/lib64/libcrypto.so.3.2.1
> [0x556ac0b95b90] RSA_get0_key@OPENSSL_3.0.0  →  0x7f4e960e1ac0 :
> /usr/lib64/liblzma.so.5.6.1
> [0x556ac0b95c00] RSA_get0_factors@OPENSSL_3.0.0  →  0x7f4e95dae470 :
> /usr/lib64/libcrypto.so.3.2.1
> [0x556ac0b95c88] EVP_PKEY_get1_RSA@OPENSSL_3.0.0  → 0x7f4e95d59710 :
> /usr/lib64/libcrypto.so.3.2.1
> [0x556ac0b95da0] RSA_get_ex_data@OPENSSL_3.0.0  →  0x7f4e95db3440 :
> /usr/lib64/libcrypto.so.3.2.1
> [0x556ac0b95e50] RSA_set0_factors@OPENSSL_3.0.0  →  0x7f4e95dafdc0 :
> /usr/lib64/libcrypto.so.3.2.1
> [0x556ac0b95f00] RSA_blinding_on@OPENSSL_3.0.0  →  0x7f4e95db17f0 :
> /usr/lib64/libcrypto.so.3.2.1

Since no one else replied yet, this is a nice bit of analysis.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
--
___
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: Three steps we could take to make supply chain attacks a bit harder

[Richard W.M. Jones]

On Tue, Apr 02, 2024 at 05:09:18PM +0200, Kilian Hanich via devel wrote:
> Am 02.04.24 um 10:22 schrieb Florian Weimer:
> >>  - Can some wrappers be developed to make it both easier and safer?
> >GCC already provides function multi-versioning/target clones as a
> >higher-level interface.
> 
> 
> Also, upstreams should by default properly mark their stuffs with
> restrictive visibilities.
> 
> While we are a few decades to change the defaults, that doesn't mean
> that one can't choose the better option. So, by default one should
> choose -fvisibility=hidden and mark the public API with
> __attribute__((visibility("protected"))) or, if they really want a
> function to be interpositionable (by e.g. LD_PRELOAD) as
> __attribute__((visibility("default"))).

ISTR this also makes the library faster (faster loading I think?)

Anyway we've done it for all the virt libraries for years.

Rich.

> As a side effect, if you ever want your library be usable on Windows,
> you need to do that anyway since hidden is the default there and your
> public API must be marked explicitly. (Also, Windows doesn't support
> interposition and also doesn't support cyclic library dependencies
> without complicated hacks. So yeah, Windows kinda has the better
> defaults here.)
> 
> Some newer languages do that anyway already, but we obviously can't just
> change it for C and C++ projects.
> 
> But depending on the architecture this may not necessarily be possible.
> So yeah, only upstream can do that, not us.
> 
> 
> Regards
> 
> Kilian Hanich
> --
> ___
> 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
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
--
___
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: Three steps we could take to make supply chain attacks a bit harder

[Richard W.M. Jones]

On Tue, Apr 02, 2024 at 10:59:10AM +0200, Florian Weimer wrote:
> * Richard W. M. Jones:
> > In the xz case this wouldn't have been enough, it turns out we would
> > also have to delete m4/build-to-host.m4, which then autoreconf
> > regenerates.  I don't fully understand why that is.
> 
> I would expect that's what the serial number is for?  But that's just a
> guess.

Yes, in this case the attacker had set the serial number to 30, but
the latest upstream serial number was 3.  autoreconf won't replace the
file in this case unless it is deleted.  There really should be an
"always replace if you can" option in autoreconf.

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

Re: Three steps we could take to make supply chain attacks a bit harder

[Richard W.M. Jones]

On Tue, Apr 02, 2024 at 07:40:33AM +0200, Andreas Schneider wrote:
> On Saturday, 30 March 2024 10:37:44 CEST Richard W.M. Jones wrote:
> > These are just my thoughts on a Saturday morning.  Feedback welcome of
> > course.
> 
> I find the use of the ifunc attribute is really uncommon at this place. I 
> would expect it in ffmpeg or some media codecs. In xz it looks like it is 
> only 
> there to hook in the payload. The software I know normally uses target 
> cloning.

In hindsight it's suspicious, but it's not generally suspicious for a
project that needs to generate optimal code for different
sub-architectures (eg. something that does fast decompression) to use
the mechanism for that purpose, ifunc.

That said, ifunc is a very complicated, fragile  but powerful mechanism
and I'd like to know from the glibc developers what we should
look out for.  For example:

 - Is it ever valid for ifunc to take control of functions in another
   library?  Can this be detected by ld.so?

 - Can some wrappers be developed to make it both easier and safer?

> I think the use of the ifunc attribute should be a red flag. Can't we check 
> for it with rpmlint and let the security team verify it?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

[Richard W.M. Jones]

On Sun, Mar 31, 2024 at 09:39:43AM -0700, Kevin Fenzi wrote:
> On Sun, Mar 31, 2024 at 09:12:30AM -0700, Adam Williamson wrote:
> > Thanks Arthur, yes, that was *exactly* the point.
> > 
> > I would argue there's a danger of getting too tied up in very specific
> > technical details of this attack. Yes, it's reasonable to think of ways
> > to mitigate those specific mechanisms, at least at the appropriate
> > levels (arguably, most of this is really directly an issue upstream of
> > us). But it has been - for me - persuasively argued that the specific
> > technical details were decided based on the wider goals of the attack.
> > 
> > I buy the scenario where the starting point was "how can we poison the
> > major distributions?" and everything from there derived from that
> > starting point. xz was picked as the target because of all the specific
> > technical stuff about systemd and ssh links which people are keen to
> > dive deep into the details of, but *if that vector hadn't existed the
> > attacker would just have chosen the next best one*. The specific form
> > of the attack was then customized to the specific properties of xz,
> > very cunningly - the whole thing about hiding the payload in binary
> > test files. But if the attacker had chosen to attack a different
> > project with different properties, they would have customized their
> > attack to *that* environment with equal cunning, and it would probably
> > look quite different.
> 
> I think even stepping further back from the technical details is worth
> considering. I think xz was picked because it had one maintainer who had
> personal issues and low time/desire to continue work, and they were a
> good target to be bullied into adding another maintainer. Are there
> other critical packages we ship in similar situations? 

I can imagine the attacker had some sort of scoring system for projects:

 - No upstream patch review process (+10)
 - Complicated codebase (+20)
 - Small group of maintainers (+5)
 - Single, vulnerable maintainer (+50)
 - Linked to sshd (+1000)

There's something to be said for us doing a similar sort of analysis.

> > Worrying *only* about binary blobs in source repos or the specific
> > details of how systemd opens compression libraries feels a bit narrow,
> > to me - and especially so when we do it down at the distribution level
> > where it's not necessarily primarily our responsibility, and I would
> > argue is definitely not the *lowest* hanging fruit if we take a broader
> > view of "what should we as a project be doing to raise the difficulty
> > of supply chain attacks?"
> 
> Agreed. I think theres lots of places we should improve, and focusing on
> our own backyard first might be wise. But we can also work on the other
> parts too!
> 
> There are lots of things we _could_ do... we should discuss and consider
> what ones make sense in what order. We should just do something because
> we can. ;)
> 
> Also, a reminder... nothing is ever 'secure'. security is a process. We
> consider likelt threats, we try and mitigate them, and we keep doing it.
> Things change and we should too.
> 
> kevin

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

[Richard W.M. Jones]

On Sat, Mar 30, 2024 at 11:53:07AM -0400, Neal Gompa wrote:
> On Sat, Mar 30, 2024 at 11:36 AM Zbigniew Jędrzejewski-Szmek
>  wrote:
> >
> > On Sat, Mar 30, 2024 at 10:02:42AM -0500, Michael Catanzaro wrote:
> > > On Sat, Mar 30 2024 at 02:55:21 PM +00:00:00, Zbigniew Jędrzejewski-Szmek
> > >  wrote:
> > > > CMake for many years fought against pkgconf and pushed people towards
> > > > copying those scripts into sources. It is still very common for projects
> > > > using CMake to come with a whole directory of badly written detection
> > > > scripts that each replace a single-line pkgconf invocation.
> > > >
> > > > And of course nobody has time to look into those scripts, making it
> > > > easy to smuggle something through there.
> > >
> > > It's still better than Autotools, though. If a project doesn't want to
> > > switch to Meson for whatever reason, then CMake is a reasonable 
> > > alternative.
> > >
> > > I agree that CMake is not as good as Meson, and that CMake find modules 
> > > are
> > > inferior to pkg-config.
> >
> > But then we shouldn't describe them as equivalent alternatives ;)
> > If we say "switch to a modern build systemd, e.g. cmake or meson",
> > people will randomly choose on or the other and since the whole CMake
> > ecosystem is built around find modules, we'll end with a bazillion of
> > those.
> >
> > Instead we should say: "Use meson. If you can't for some reason, consider
> > CMake, but come talk to us first."
> >
> 
> Meson's own module instability and lack of extensibility make it
> unsuitable for a wide range of projects, especially complex ones. The
> lack of stability in Meson itself is so bad that Meson upgrades break
> GNOME, libvirt, and others. And the lack of extensibility is an
> anti-feature. It means that Meson cannot scale to the infinite world
> of project needs because everything has to be bent around it or hacks
> need to be written in the projects to work around its weaknesses.
> 
> No way would I personally recommend it. I'm not going to go as far as
> to recommend one explicitly over the other from a distribution
> perspective, but personally I would never choose Meson anymore.

Also we haven't found the meson lead developer to be very open to
fixing an obvious bug that affects Fedora/RISC-V, even after providing
and carefully testing a patch for it.  It wasn't encouraging.

Rich.


> 
> 
> 
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> --
> ___
> 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
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: Three steps we could take to make supply chain attacks a bit harder

[Richard W.M. Jones]

On Sat, Mar 30, 2024 at 02:44:32PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Sat, Mar 30, 2024 at 08:23:48AM -0400, Neal Gompa wrote:
> > On Sat, Mar 30, 2024 at 8:07 AM Kevin Kofler via devel
> >  wrote:
> > > > (At which point I'd suggest it's probably faster to convert it all to
> > > > meson or another new shiny, and saner, build system, but getting 
> > > > upstreams
> > > > to agree will be fun)
> > >
> > > CMake! :-)
> 
> Meson outclasses CMake in functionality, clarity, and brevity.
> I doesn't make sense to consider switching to CMake at this point.

Which is the better build system doesn't much matter here, as they all
let you run shell scripts so source level backdoors could be inserted
in all of them.

The big difference they all have over autoconf is that they don't
usually distribute a giant obfuscated (basically binary) shell script.

We can fix autoconf now by running autoreconf and we don't need to
boil the ocean to do so.

> > > This drags in libsystemd
> > > for sd_notify, and libsystemd is linked to way too much stuff including
> > > liblzma. Either we need a split libsdnotify that contains only sd_notify, 
> > > or
> > > we should just stop using sd_notify at all. It increases the attack 
> > > surface
> > > of daemons a lot just to allow the service to be "Type=notify" rather than
> > > one of the other available approaches. Arch Linux is also systemd-based
> > > nowadays, but still does not link OpenSSH against libsystemd.
> > >
> > 
> > This is related to philosophical differences between Arch and Fedora.
> > 
> > That said, it probably makes sense for sd_notify to be its own library
> > instead of being part of libsystemd. I'm sure systemd upstream will
> > consider it now. :)
> 
> I don't think a separate library would be particularly useful.
> sd_notify() as used by sshd just writes a static string to a unix
> socket. This can be implemented in ~10 lines of C, including error handling.
> 
> If that is the _only_ thing needed from libsystemd, then open-coding it
> is a good option. I guess it'd make sense for systemd to provide a header
> file that provides a reference documentation as an inline function.

I think systemd should do this, just so we have one implementation,
and not loads of buggy ones.

> One thing which is happening, mostly for unrelated reasons, it that
> systemd code is being changed to use dlopen() for various libraries which
> are usually not needed at runtime. The primary motivation for this is to
> omit such libraries from the initrd. But this also helps with overlinking.
> 
> In systemd git main, libsystemd is only linked to libc, libcap,
> and libgcrypt + libgpg-error. A pull request to convert that that last
> pair to dlopen is under review.

Also a good change, thanks.

Rich.

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

Re: Three steps we could take to make supply chain attacks a bit harder

[Richard W.M. Jones]

On Sat, Mar 30, 2024 at 08:22:06PM +0900, Dominique Martinet wrote:
> > the initial injection (original:
> > https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=m4/build-to-host.m4;h=f928e9ab403b3633e3d1d974abcf478e65d4b0aa;hb=HEAD).
> 
> (Honestly I did compare the backdoored script and the real one this
> morning and I would be hard pressed to say if either is backdoored just
> looking at either version... Admitedly it was 3AM when I looked at it,
> but I don't think it's just a late hour problem)

Right!  Definitely not a 3am problem :-/

> > (3) We should have a "security path", like "critical path".
...
> Before making each of these safer we should make sshd not link with so
> many things in the first place.
> On oss-security, Solar Designer made a lot of good points about it
> (around here: https://www.openwall.com/lists/oss-security/2024/03/29/27
> , but the full thread is interesting)

Agreed.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
--
___
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

Three steps we could take to make supply chain attacks a bit harder

[Richard W.M. Jones]

I'm not pretending these will solve everything, but they should make
attacks a little harder in future.


(1) We should routinely delete autoconf-generated cruft from upstream
projects and regenerate it in %prep.  It is easier to study the real
source rather than dig through the convoluted, generated shell script
in an upstream './configure' looking for back doors.

For most projects, just running "autoreconf -fiv" is enough.

Yes, there are some projects that depend on a specific or old version
of autoconf.  We should fix those.  But that doesn't need to delay us
from using autoreconf on many projects today.

In the xz case this wouldn't have been enough, it turns out we would
also have to delete m4/build-to-host.m4, which then autoreconf
regenerates.  I don't fully understand why that is.


(2) We should discourage gnulib as much as possible.

In libvirt we took the decision a few years ago to remove gnulib.
It's extremely convoluted and almost no one understands how it really
works.  It's written in obscure m4 macros and shell script.

It's also not necessary for Linux since gnulib is mainly about
porting to non-Linux platforms.  There are better ways to do this.

In the xz case it was a gnulib-derived script which was modified to do
the initial injection (original:
https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=m4/build-to-host.m4;h=f928e9ab403b3633e3d1d974abcf478e65d4b0aa;hb=HEAD).


(3) We should have a "security path", like "critical path".

sshd is linked to a lot of libraries:

/lib64/libaudit.so.1audit-libs
/lib64/libc.so.6glibc
/lib64/libcap-ng.so.0   libcap-ng
/lib64/libcap.so.2  libcap
/lib64/libcom_err.so.2  libcom_err
/lib64/libcrypt.so.2libxcrypt
/lib64/libcrypto.so.3   openssl-libs
/lib64/libeconf.so.0libeconf
/lib64/libgcc_s.so.1libgcc
/lib64/libgssapi_krb5.so.2  krb5-libs
/lib64/libk5crypto.so.3 krb5-libs
/lib64/libkeyutils.so.1 keyutils-libs
/lib64/libkrb5.so.3 krb5-libs
/lib64/libkrb5support.so.0  krb5-libs
/lib64/liblz4.so.1  lz4-libs
/lib64/liblzma.so.5 xz-libs
/lib64/libm.so.6glibc
/lib64/libpam.so.0  pam-libs
/lib64/libpcre2-8.so.0  pcre2
/lib64/libresolv.so.2   glibc
/lib64/libselinux.so.1  libselinux
/lib64/libsystemd.so.0  systemd-libs
/lib64/libz.so.1zlib / zlib-ng
/lib64/libzstd.so.1 zstd

Should we have a higher level of attention to these packages?  We
already have "critical path", but that's a broad category now.  These
seem like they are "security path" packages, an intentionally small
subset associated with very secure services which are enabled by
default.


These are just my thoughts on a Saturday morning.  Feedback welcome of
course.

Rich.

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

Re: xz backdoor

[Richard W.M. Jones]

On Fri, Mar 29, 2024 at 07:25:56PM -0500, Chris Adams wrote:
> Once upon a time, Richard W.M. Jones  said:
> > (1) We built 5.6.0 for Fedora 40 & 41.  Jia Tan was very insistent in
> > emails that we should update.
> 
> So this wasn't just a "hey, new upstream version", this was PUSHED on
> distributions by the culprit.

I have to say that this is not unusual.  I myself have even sent
messages to other maintainers encouraging them to package or update
projects that I've written.  A keen upstream maintainer wanting to
help or encourage downstream packagers is normally welcome.  This is
the one case and only case that someone turned out to be malicious
(that we know about).  They abused our trust.

> Are they a contributor to any other software in the distribution?  I
> think anything they might have touched has to be considered suspect.

Yes I agree that anything else touched by this "person" should be
considered very suspect.

> Either (a) their systems have been completely compromised or (b) they
> did this intentionally.  Neither is good.

The back door is intentional for sure.  We don't know the details of
if this is an account take-over or a "long con" and what the
background to all this is, but I'm sure people are looking into that.

> > (2) We got reports later of a valgrind test failure.  I also saw it
> > myself in my own projects that use liblzma.  We notified Jia Tan of
> > this.
> 
> Why does libsystemd pull in libzma (as well as liblz4 and libzstd,
> because we need three compression libraries in one place)?  That seems
> to be a broad amount of extra code, for a library that's in a number of
> network-listening services is just linked for socket activation.

This is a very real issue.  Got another email coming up in a bit about
this.

> Also, while it appears there's more than one developer with Github
> commit access (one other made commits since the initial "bad" commit),
> it would seem they aren't doing reviews, so not sure how much xz/liblzma
> can be trusted to be linked into a whole lot of key programs.

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

Re: xz backdoor

[Richard W.M. Jones]

On Fri, Mar 29, 2024 at 04:46:54PM -0500, Michael Catanzaro wrote:
> On Fri, Mar 29 2024 at 04:10:53 PM -05:00:00, Michael Catanzaro
>  wrote:
> >OK, I am going to ask Product Security to edit their blog post to
> >remove the incorrect information. I will CC you on that request.
> 
> Or maybe I should rephrase this as a "request for clarification,"
> because maybe they know something that we don't. E.g. the Ars
> article [1] says
> 
> "The build environment on Fedora 40, for example, contains
> incompatibilities that prevent the injection from correctly
> occurring. Fedora 40 has now reverted to the 5.4.x versions of xz
> Utils."
>
> [1] 
> https://arstechnica.com/security/2024/03/backdoor-found-in-widely-used-linux-utility-breaks-encrypted-ssh-connections/

Yeah that's just a confused report.  This is how it actually happened:

(1) We built 5.6.0 for Fedora 40 & 41.  Jia Tan was very insistent in
emails that we should update.

(2) We got reports later of a valgrind test failure.  I also saw it
myself in my own projects that use liblzma.  We notified Jia Tan of
this.

(3) Since the valgrind failure pointed to something with ifuncs, using
'./configure --disable-ifuncs' was used to fix this in F40 & F41.

(4) xz 5.6.1 was released with a fix for the valgrind failure.

(5) Fedora 40 was now in beta so we kept 5.6.0 + --disable-ifuncs.
Fedora 41 was updated to 5.6.1 (enabling ifuncs again).

And now with the benefit of hindsight ...

In step (1) we worked in good faith with upstream.  Given how
obfuscated the injection is, it's very unlikely we would have found
the problem even if we'd spent days inspecting the tarball.  (And the
initial step of injection is *not* in git, so forget about reviewing
git commits.)

The valgrind failure (2) was caused by a bug in the back door.

Disabling ifuncs in (3) disabled the back door, because I think it
relies on ifuncs to do its malware, but in any case the obfuscated
injection script explicitly skips injection if ifuncs are disabled.

Step (4) fixed the back door valgrind failure.

The Fedora 40 beta freeze in (5) meant we got lucky for F40, not so
much for F41.

Rich.

> Now, that's a secondary source, and I'm not confident if it is true,
> but perhaps Product Security had time to analyze the build logs
> before publishing and found something that we don't know about.
> Richard, what do you think?
> 

-- 
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: xz backdoor

[Richard W.M. Jones]

On Fri, Mar 29, 2024 at 07:44:12PM +0100, Mikel Olasagasti wrote:
> Hi,
> 
> I'm seeing weird things.
> 
> For whatever reason Source for xz was changed 2 months ago[1] to use
> GH releases instead of tukaani.org site.
> 
> The XZ page[2] has a note stating:
> 
> "Note: GitHub automatically includes two archives Source code (zip)
> and Source code (tar.gz) in the releases. These archives cannot be
> disabled and should be ignored."
> 
> And they wayback WayBackMachine[3] doesn't have previous versions.
> 
> Do we know if GH release tarballs are safe?
> @richard, do you remember why you had to change the source for the tarball?

Sadly the release tarballs we used *do* contain the vulnerability.
I checked myself that the payload is present in the final xz RPMs.

Rich.

> Regards,
> Mikel
> 
> [1] 
> https://src.fedoraproject.org/rpms/xz/c/0c09a6280b4a0c4fd7a9fc742c09469c95ff431f?branch=f40
> [2] https://xz.tukaani.org/
> [3] https://web.archive.org/web/20240119212251/https://xz.tukaani.org/
> 
> Hau idatzi du Kevin Kofler via devel (devel@lists.fedoraproject.org)
> erabiltzaileak (2024 mar. 29(a), or. (19:01)):
> >
> > Hi,
> >
> > wow: https://www.openwall.com/lists/oss-security/2024/
> >
> > I think at this point we clearly cannot trust xz upstream anymore and should
> > probably fork the project.
> >
> > Kevin Kofler
> > --
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > Do not reply to spam, report it: 
> > https://pagure.io/fedora-infrastructure/new_issue
> --
> ___
> 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-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
--
___
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: xz backdoor

[Richard W.M. Jones]

On Fri, Mar 29, 2024 at 03:01:34PM -0500, Michael Catanzaro wrote:
> On Fri, Mar 29 2024 at 07:56:49 PM +00:00:00, Richard W.M. Jones
>  wrote:
> >secalert are already well aware and have approved the update.  Kevin
> >Fenzi, myself and others were working on it late last night :-(
> 
> Sorry, I linked to the wrong article. I meant to link to [1] which
> says that "At this time the Fedora Linux 40 builds have not been
> shown to be compromised. We believe the malicious code injection did
> not take effect in these builds." But this statement contradicts my
> findings above, and you just replied "yes" to those, implying that
> my understanding is correct. So I guess either this blog post is
> wrong and needs to be updated, or you're wrong about me being right.
> Er, correct? :)
> 
> [1] 
> https://www.redhat.com/en/blog/urgent-security-alert-fedora-41-and-rawhide-users

These are the exact builds which were vulnerable.  Note the tags are
all empty because Kevin untagged them last night, so you'll probably
need to cross-reference these with bodhi updates.

xz-5.6.0-1.fc41
https://koji.fedoraproject.org/koji/buildinfo?buildID=2411083

xz-5.6.0-1.fc40
https://koji.fedoraproject.org/koji/buildinfo?buildID=2411092

xz-5.6.0-2.fc41
https://koji.fedoraproject.org/koji/buildinfo?buildID=2412686

xz-5.6.0-2.fc40
https://koji.fedoraproject.org/koji/buildinfo?buildID=2412698

xz-5.6.0-2.eln136
https://koji.fedoraproject.org/koji/buildinfo?buildID=2412908

xz-5.6.1-1.fc41
https://koji.fedoraproject.org/koji/buildinfo?buildID=2417414

xz-5.6.1-1.eln136
https://koji.fedoraproject.org/koji/buildinfo?buildID=2417425

NOT known to be vulnerable:

 * xz-5.6.0-3.fc41 (because --disable-ifunc)
 * xz-5.6.0-3.fc40 (because --disable-ifunc)
 * anything < 5.6.0

You can also use the detection script "detect.sh" written by Vegard
Nossum (https://www.openwall.com/lists/oss-security/2024/03/29/4)

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: xz backdoor

[Richard W.M. Jones]

On Fri, Mar 29, 2024 at 06:46:59PM +, Christopher Klooz wrote:
> Yes, F40 beta is affected, along with rawhide, but not F38/F39.
> 
> https://discussion.fedoraproject.org/t/warning-malicious-code-in-current-pre-release-testing-versions-variants-f40-and-rawhide-affected-users-of-f40-rawhide-need-to-respond/110683
> 
> https://www.redhat.com/en/blog/urgent-security-alert-fedora-41-and-rawhide-users
> 
> https://access.redhat.com/security/cve/CVE-2024-3094
> 
> https://www.linkedin.com/posts/fedora-project_urgent-security-alert-for-fedora-41-and-fedora-activity-7179540438494629888-EH4d?utm_source=share_medium=member_desktop
> 
> It might be noted that the header of the RH article is wrong and refers to 
> "F41 and rawhide", whereas the RH article content is correct and refers to 
> "F40 and rawhide". Other sources, including the publication of Fedora Project 
> (e.g., on linkedin), also refer to F40 and rawhide. However, the RH CVE 
> article also refers to "F41 and rawhide".
> 
> Can someone from RH check and change the RH article header and the RH CVE 
> page content to avoid confusion? I tend to assume that "F41 and rawhide" 
> makes no sense at all since the two are currently equal.

There was an F40 change that was vulnerable but it was in testing only
briefly.  After disabling ifuncs we (accidentally) were not vulnerable
in F40.  So the RH article is kind of correct.

I still recommend everyone updating to the Epoch: 1 package if they're
on F40 or F41.

Also if you're on F41 and/or think you might have installed the
vulnerable xz anywhere, note that the exploit has not been fully
analyzed and no one really knows what it could do.  I'm currently
reinstalling a couple of machines from scratch and have regenerated
my SSH keys.

Rich.

> Chris
> 
> On 29/03/2024 19.37, Barry wrote:
> >Has this shipped on f40 beta?
> >
> >Barry
> >
> >>On 29 Mar 2024, at 18:08, Richard W.M. Jones  wrote:
> >>
> >>
> >>>On Fri, Mar 29, 2024 at 07:00:37PM +0100, Kevin Kofler via devel wrote:
> >>>Hi,
> >>>
> >>>wow: https://www.openwall.com/lists/oss-security/2024/
> >>>
> >>>I think at this point we clearly cannot trust xz upstream anymore and 
> >>>should
> >>>probably fork the project.
> >>I kind of agree here, though it saddens me to say it.  Any commit or
> >>release by "Jia Tan" or "Hans Jansen" [1] is suspect until proven
> >>otherwise, and those go back 2 or more years.
> >>
> >>Rich.
> >>
> >>[1] Putting quotes here because those are almost certainly not real
> >>peoples' names.
> >>
> >>--
> >>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
> >--
> >___
> >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@list

Re: xz backdoor

[Richard W.M. Jones]

On Fri, Mar 29, 2024 at 02:40:48PM -0500, Michael Catanzaro wrote:
> On Fri, Mar 29 2024 at 06:46:59 PM +00:00:00, Christopher Klooz
>  wrote:
> >Yes, F40 beta is affected, along with rawhide, but not F38/F39.
> 
> Unless I'm misunderstanding something, it looks xz-5.6.0-1.fc40 and
> 5.6.0-2.fc40 are backdoored, yes? Then rjones unknowingly broke the
> backdoor in two different ways in 5.6.0-3.fc40, (a) by adding the
> --disable-ifunc configure flag [1],

Yes.

> and also (b) by running
> everything through autoreconf to regenerate the malicious autogoo
> files [2].

Sadly this on its own was not sufficient.  You also have to delete
m4/build-to-host.m4 first.  But (a) was sufficient to prevent the
backdoor on its own.

> So F40 stable was never affected, but F40 updates-testing
> looks like it really was backdoored for about one week, between
> February 27 [3] and March 4 [4].
> 
> Hey Richard, if you agree with my quick assessment, then we should
> ask secal...@redhat.com to update the warning article [5]. (I also
> don't like the confusing references to "Fedora 41" in that article,
> since Fedora 41 does not yet exist as something separate from
> rawhide.)

secalert are already well aware and have approved the update.  Kevin
Fenzi, myself and others were working on it late last night :-(

Rich.

> [1] 
> https://src.fedoraproject.org/rpms/xz/c/c837ae96c716c6d63da2b4a016e9034ade2a01f7?branch=f40
> [2] 
> https://src.fedoraproject.org/rpms/xz/c/d2408dde878851ca6350297a738a72496a9558c4?branch=f40
> [3] https://bodhi.fedoraproject.org/updates/FEDORA-2024-a7fba89402
> [4] https://bodhi.fedoraproject.org/updates/FEDORA-2024-f5033032b8
> [5] https://access.redhat.com/security/cve/CVE-2024-3094
> 

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: xz backdoor

[Richard W.M. Jones]

On Fri, Mar 29, 2024 at 07:00:37PM +0100, Kevin Kofler via devel wrote:
> Hi,
> 
> wow: https://www.openwall.com/lists/oss-security/2024/
> 
> I think at this point we clearly cannot trust xz upstream anymore and should 
> probably fork the project.

I kind of agree here, though it saddens me to say it.  Any commit or
release by "Jia Tan" or "Hans Jansen" [1] is suspect until proven
otherwise, and those go back 2 or more years.

Rich.

[1] Putting quotes here because those are almost certainly not real
peoples' names.

-- 
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: Redis will no longer be OSS... now what?

[Richard W.M. Jones]

On Wed, Mar 20, 2024 at 06:19:28PM -0400, Neal Gompa wrote:
> Hey everyone,
> 
> It looks like Redis, Inc. has announced that future versions of Redis
> are no longer OSS and will be dual-licensed SSPL and RSAL[1]. Absent a
> fork of Redis coming up, we will likely need to remove Redis from
> Fedora.
> 
> All I can say is... :(
> 
> [1]: https://redis.com/blog/redis-adopts-dual-source-available-licensing/

Another alternative is that someone in the community might fork it.
Can we stick with the last free version for a few months to see how
the pieces fall?

Rich.

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

Re: Look for help: how to package Rust project

[Richard W.M. Jones]

On Thu, Mar 21, 2024 at 11:04:13AM +0800, Ming Lei wrote:
> Hello Richard and Guys,
> 
> I plan to package rublk to Fedora, and it is one Rust project.

Hi, I'm on holiday at the moment, but please do look at how we
packaged libblkio in Fedora:

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

> Can you provide a little guide about how to do that? such as,
> where can I find the guide doc? And is it github or crates which
> should be used as source for Fedora packaging?

Everything has to start with a source tarball, so normally github
would be the best source.

> [1] https://github.com/ublk-org/rublk
> [2] https://crates.io/crates/rublk

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
--
___
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: Why can't I add karlowich as co-maintainer of this package?

[Richard W.M. Jones]

On Mon, Mar 18, 2024 at 01:55:14PM +0100, Fabio Valentini wrote:
> On Mon, Mar 18, 2024 at 1:51 PM Richard W.M. Jones  wrote:
> >
> > On Mon, Mar 18, 2024 at 10:14:38AM +0000, Richard W.M. Jones wrote:
> > > On Mon, Mar 18, 2024 at 10:05:42AM +, Daniel P. Berrangé wrote:
> > > > On Mon, Mar 18, 2024 at 09:57:58AM +, Richard W.M. Jones wrote:
> > > > >
> > > > > https://src.fedoraproject.org/rpms/xnvme/adduser
> > > > >
> > > > > I try to add karlowich 
> > > > > (https://accounts.fedoraproject.org/user/karlowich/)
> > > > > but his name doesn't appear in the username field even though he's
> > > > > in the packager group.  Why?
> > > >
> > > > If they were only recently granted packager status, they might need 
> > > > login
> > > > to 'src.fedoraproject.org' to (re)sync group membership perhaps ?
> > >
> > > Thanks everyone, I'll have him try this.
> >
> > No luck.  He's apparently tried logging out / in a few times and
> > doesn't appear in the list.  Is there something else he needs to try?
> 
> It appears that src.fp.o does not know about him *at all*:
> https://src.fedoraproject.org/user/karlowich
> 
> Note that the logging out / back in needs to happen on
> src.fedoraproject.org, not with any other Fedora service.
> For me, sometimes opening "src.fedoraproject.org" in an incognito
> browser window and logging in there has helped.

Yes that worked, thanks.

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: Why can't I add karlowich as co-maintainer of this package?

[Richard W.M. Jones]

On Mon, Mar 18, 2024 at 10:14:38AM +, Richard W.M. Jones wrote:
> On Mon, Mar 18, 2024 at 10:05:42AM +, Daniel P. Berrangé wrote:
> > On Mon, Mar 18, 2024 at 09:57:58AM +, Richard W.M. Jones wrote:
> > > 
> > > https://src.fedoraproject.org/rpms/xnvme/adduser
> > > 
> > > I try to add karlowich 
> > > (https://accounts.fedoraproject.org/user/karlowich/)
> > > but his name doesn't appear in the username field even though he's
> > > in the packager group.  Why?
> > 
> > If they were only recently granted packager status, they might need login
> > to 'src.fedoraproject.org' to (re)sync group membership perhaps ?
> 
> Thanks everyone, I'll have him try this.

No luck.  He's apparently tried logging out / in a few times and
doesn't appear in the list.  Is there something else he needs to try?

Rich.

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

Re: Why can't I add karlowich as co-maintainer of this package?

[Richard W.M. Jones]

On Mon, Mar 18, 2024 at 10:05:42AM +, Daniel P. Berrangé wrote:
> On Mon, Mar 18, 2024 at 09:57:58AM +0000, Richard W.M. Jones wrote:
> > 
> > https://src.fedoraproject.org/rpms/xnvme/adduser
> > 
> > I try to add karlowich (https://accounts.fedoraproject.org/user/karlowich/)
> > but his name doesn't appear in the username field even though he's
> > in the packager group.  Why?
> 
> If they were only recently granted packager status, they might need login
> to 'src.fedoraproject.org' to (re)sync group membership perhaps ?

Thanks everyone, I'll have him try this.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Why can't I add karlowich as co-maintainer of this package?

[Richard W.M. Jones]

https://src.fedoraproject.org/rpms/xnvme/adduser

I try to add karlowich (https://accounts.fedoraproject.org/user/karlowich/)
but his name doesn't appear in the username field even though he's
in the packager group.  Why?

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: Possible memory corruption in xz / liblzma in Fedora 40 & 41

[Richard W.M. Jones]

An update ...

This is fixed in xz 5.6.1.  I tested the fix and it works for me.
https://github.com/tukaani-project/xz/commit/82ecc53819

Rather than mess with Fedora 40 again, I did a build in Rawhide only:
https://bodhi.fedoraproject.org/updates/FEDORA-2024-7e9c14633a

I guess if this goes well we can try it in Fedora 40 later.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
--
___
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

So you can't just copy 'sources' from one package to another?

[Richard W.M. Jones]

For mingw-* packages we (sometimes) have a separate package from the
native package, eg. libgcrypt vs mingw-libgcrypt.  Therefore two
different packages are sometimes built with the exact same sources.

However I discovered copying 'sources' (ie the file) from libgcrypt
dist-git to mingw-libgcrypt dist-git alone isn't sufficient to get the
package to build.  You still have to download the source tarballs in
libgcrypt, copy them to mingw-libgcrypt, and 'fedpkg new-sources
' to upload them again.

Isn't the lookaside cache shared across the whole of Fedora?

(This doesn't matter, I was just wondering aloud.)

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

Re: reprodubible builds (re)introduction

[Richard W.M. Jones]

On Thu, Mar 07, 2024 at 12:39:37PM +, Zbigniew Jędrzejewski-Szmek wrote:
> Hi,
>
> The effort to make package builds in Fedora reproducible has picked
> up steam again.  We now have a new website:
> https://docs.fedoraproject.org/en-US/reproducible-builds

I read this page but it doesn't cover an important point (for me).
What's the actual threat model you have in mind?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Possible intermittent lost mail from Pagure

[Richard W.M. Jones]

On Thu, Mar 07, 2024 at 09:30:02AM -0800, Kevin Fenzi wrote:
> On Wed, Mar 06, 2024 at 11:44:51AM +0000, Richard W.M. Jones wrote:
> > I can't quite point to proper evidence, but I have a feeling that
> > email notifications are being lost from Pagure.
> 
> I'm guessing from below you mean the src.fedoraproject.org instance?
> (pagure.io is the other one, so it's best to be clear which one)

Yes, src.fedoraproject.org

> > One case where I'm about 90% sure this happened was with:
> > 
> >   https://src.fedoraproject.org/rpms/ogre/pull-request/3
> > 
> > where I did not receive the "cc @rjones" email.  I don't think it was
> > dropped by spam filters etc.
> > 
> > I've seen other people complaining about this too, today for instance:
> > 
> >   https://src.fedoraproject.org/rpms/pcp/pull-request/25#comment-187753
> 
> So, src.fedoraproject.org should output fedora-messaging messages and
> then notifications acts on those to notify people. 
> 
> What settings do you have in https://notifications.fedoraproject.org ?
> Also, does this only happen some of the time? or always?

This is definitely intermittent, and probably rare.  I don't think I
have change the notification settings.

> It might be a fmn bug, or something deeper. ;( 
> 
> Can you start by filing on fmn:
> https://github.com/fedora-infra/fmn/
> and we can try and track it down from there?
> 
> > On a related subject, pagure does not send out email when someone
> > rebases / force pushes to a pull request, which seems like a pretty
> > big problem.
> 
> I think that might be an upstream pagure issue?
> https://pagure.io/pagure

Thanks,

Rich.


> --
> ___
> 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
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Possible intermittent lost mail from Pagure

[Richard W.M. Jones]

I can't quite point to proper evidence, but I have a feeling that
email notifications are being lost from Pagure.

One case where I'm about 90% sure this happened was with:

  https://src.fedoraproject.org/rpms/ogre/pull-request/3

where I did not receive the "cc @rjones" email.  I don't think it was
dropped by spam filters etc.

I've seen other people complaining about this too, today for instance:

  https://src.fedoraproject.org/rpms/pcp/pull-request/25#comment-187753

On a related subject, pagure does not send out email when someone
rebases / force pushes to a pull request, which seems like a pretty
big problem.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
--
___
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: Possible memory corruption in xz / liblzma in Fedora 40 & 41

[Richard W.M. Jones]

On Mon, Mar 04, 2024 at 01:46:13PM +, Richard W.M. Jones wrote:
> We updated xz to new version 5.6.0 last week.  It was supposed to be a
> safe change so we backported it to F40 at the request of the xz
> author.  But there's been a report of possible memory corruption:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=2267598
> 
> I've not been able to reproduce this myself, still trying.

We're still not quite sure what is going on here, however I was able
to work around it in xz (as a temporary fix).

https://bugzilla.redhat.com/show_bug.cgi?id=2267598#c5

The versions which have the bug were:

xz-5.6.0-1.fc40
xz-5.6.0-1.fc41
xz-5.6.0-2.fc40
xz-5.6.0-2.fc41

The versions which contain the workaround are:

xz-5.6.0-3.fc40
xz-5.6.0-3.fc41

If anyone hits the bug with the -1/-2 package and is able to get a
more accurate and complete stack trace, please add it to the bug,
because that's what we're really missing at the moment.

Rich.

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

Possible memory corruption in xz / liblzma in Fedora 40 & 41

[Richard W.M. Jones]

We updated xz to new version 5.6.0 last week.  It was supposed to be a
safe change so we backported it to F40 at the request of the xz
author.  But there's been a report of possible memory corruption:

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

I've not been able to reproduce this myself, still trying.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
--
___
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: libxslxwriter (misspelled package) in zombie state

[Richard W.M. Jones]

On Sun, Mar 03, 2024 at 10:55:54AM +0100, Miro Hrončok wrote:
> On 02. 03. 24 23:28, Richard W.M. Jones wrote:
> >On Sat, Mar 02, 2024 at 10:16:02PM +0100, Miro Hrončok wrote:
> >>On 02. 03. 24 11:31, Richard W.M. Jones wrote:
> >>>On Fri, Mar 01, 2024 at 10:00:20AM -0800, Kevin Fenzi wrote:
> >>>>On Fri, Mar 01, 2024 at 11:49:06AM +, Richard W.M. Jones wrote:
> >>>>>
> >>>>>We were discussing this on IRC, so just to bring the topic up on the
> >>>>>mailing list ...
> >>>>>
> >>>>>(1) Package libxslxwriter (note: "xslx") with only automated activity
> >>>>>and no builds:
> >>>>>https://src.fedoraproject.org/rpms/libxslxwriter/commits/rawhide
> >>>>>https://koji.fedoraproject.org/koji/packageinfo?packageID=32741
> >>>>>
> >>>>>(2) Package libxlsxwriter (note: "xlsx") which is normal:
> >>>>>https://src.fedoraproject.org/rpms/libxlsxwriter/commits/rawhide
> >>>>>https://koji.fedoraproject.org/koji/packageinfo?packageID=32754
> >>>>>
> >>>>>It seems like the first package is in some sort of zombie state?
> >>>>
> >>>>Yeah, the package owner (or a provenpackager) should just be able to
> >>>>'fedpkg retire' it...
> >>>
> >>>Well I took that as a hint and I ran the retire command.  I'm not sure
> >>>if it actually worked completely.  There was an error towards the end:
> >>>
> >>>$ fedpkg retire 
> >>>"https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/X6ADYQA27WRLDQYAL3MHMGCHN3NQY47S/;
> >>>rm '.gitignore'
> >>>rm 'README.md'
> >>>rm 'libxlsxwriter.spec'
> >>>rm 'libxlsxwriter_sover.patch'
> >>>rm 'libxlsxwriter_zlib.patch'
> >>>rm 'sources'
> >>>[rawhide 922af46] 
> >>>https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/X6ADYQA27WRLDQYAL3MHMGCHN3NQY47S/
> >>>  7 files changed, 1 insertion(+), 143 deletions(-)
> >>>  delete mode 100644 .gitignore
> >>>  delete mode 100644 README.md
> >>>  create mode 100644 dead.package
> >>>  delete mode 100644 libxlsxwriter.spec
> >>>  delete mode 100644 libxlsxwriter_sover.patch
> >>>  delete mode 100644 libxlsxwriter_zlib.patch
> >>>  delete mode 100644 sources
> >>>...
> >>>Could not execute retire: The following error occurred while disabling 
> >>>monitoring: You are not allowed to modify this project
> >>
> >>This seems like https://pagure.io/fedpkg/issue/505
> >>
> >>The package is retired in dist-git:
> >>
> >>https://src.fedoraproject.org/rpms/libxslxwriter/commits/rawhide
> >
> >OK .. but is it retired?
> 
> It is now. When you asked, it might have been only partially
> retired. Package retirement is an asynchronous chain of events.
> 
> 1. It is retired in rawhide distgit bacuase it has the dead.package file ✔️
> 
> 2. It is "active: false" in rawhide PDC ✔️
> https://pdc.fedoraproject.org/rest_api/v1/component-branches/?name=rawhide_component=libxslxwriter
> 
> 3. It is blocked in f41 Koji ✔️
> $ koji list-pkgs --show-blocked --tag f41 --quiet --package libxslxwriter
> libxslxwriter   f41
> smani  [BLOCKED]
> 
> 4. It is not in the rawhide repository ✔️
> This package never was, so :/
> 
> 
> For docs, see 
> https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#_koji

Thanks!

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
--
___
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: libxslxwriter (misspelled package) in zombie state

[Richard W.M. Jones]

On Sat, Mar 02, 2024 at 10:16:02PM +0100, Miro Hrončok wrote:
> On 02. 03. 24 11:31, Richard W.M. Jones wrote:
> >On Fri, Mar 01, 2024 at 10:00:20AM -0800, Kevin Fenzi wrote:
> >>On Fri, Mar 01, 2024 at 11:49:06AM +0000, Richard W.M. Jones wrote:
> >>>
> >>>We were discussing this on IRC, so just to bring the topic up on the
> >>>mailing list ...
> >>>
> >>>(1) Package libxslxwriter (note: "xslx") with only automated activity
> >>>and no builds:
> >>>https://src.fedoraproject.org/rpms/libxslxwriter/commits/rawhide
> >>>https://koji.fedoraproject.org/koji/packageinfo?packageID=32741
> >>>
> >>>(2) Package libxlsxwriter (note: "xlsx") which is normal:
> >>>https://src.fedoraproject.org/rpms/libxlsxwriter/commits/rawhide
> >>>https://koji.fedoraproject.org/koji/packageinfo?packageID=32754
> >>>
> >>>It seems like the first package is in some sort of zombie state?
> >>
> >>Yeah, the package owner (or a provenpackager) should just be able to
> >>'fedpkg retire' it...
> >
> >Well I took that as a hint and I ran the retire command.  I'm not sure
> >if it actually worked completely.  There was an error towards the end:
> >
> >$ fedpkg retire 
> >"https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/X6ADYQA27WRLDQYAL3MHMGCHN3NQY47S/;
> >rm '.gitignore'
> >rm 'README.md'
> >rm 'libxlsxwriter.spec'
> >rm 'libxlsxwriter_sover.patch'
> >rm 'libxlsxwriter_zlib.patch'
> >rm 'sources'
> >[rawhide 922af46] 
> >https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/X6ADYQA27WRLDQYAL3MHMGCHN3NQY47S/
> >  7 files changed, 1 insertion(+), 143 deletions(-)
> >  delete mode 100644 .gitignore
> >  delete mode 100644 README.md
> >  create mode 100644 dead.package
> >  delete mode 100644 libxlsxwriter.spec
> >  delete mode 100644 libxlsxwriter_sover.patch
> >  delete mode 100644 libxlsxwriter_zlib.patch
> >  delete mode 100644 sources
> >...
> >Could not execute retire: The following error occurred while disabling 
> >monitoring: You are not allowed to modify this project
> 
> This seems like https://pagure.io/fedpkg/issue/505
> 
> The package is retired in dist-git:
> 
> https://src.fedoraproject.org/rpms/libxslxwriter/commits/rawhide

OK .. but is it retired?

The main page doesn't have the [Retired] block in the left column:

https://src.fedoraproject.org/rpms/libxslxwriter

Compare to the package linked in the bug report above which has it:

https://src.fedoraproject.org/rpms/belle-sip

Rich.

> The error is for monitoring only.
> 
> -- 
> Miro Hrončok
> -- 
> Phone: +420777974800
> IRC: mhroncok

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: libxslxwriter (misspelled package) in zombie state

[Richard W.M. Jones]

On Fri, Mar 01, 2024 at 10:00:20AM -0800, Kevin Fenzi wrote:
> On Fri, Mar 01, 2024 at 11:49:06AM +0000, Richard W.M. Jones wrote:
> > 
> > We were discussing this on IRC, so just to bring the topic up on the
> > mailing list ...
> > 
> > (1) Package libxslxwriter (note: "xslx") with only automated activity
> > and no builds:
> > https://src.fedoraproject.org/rpms/libxslxwriter/commits/rawhide
> > https://koji.fedoraproject.org/koji/packageinfo?packageID=32741
> > 
> > (2) Package libxlsxwriter (note: "xlsx") which is normal:
> > https://src.fedoraproject.org/rpms/libxlsxwriter/commits/rawhide
> > https://koji.fedoraproject.org/koji/packageinfo?packageID=32754
> > 
> > It seems like the first package is in some sort of zombie state?
> 
> Yeah, the package owner (or a provenpackager) should just be able to
> 'fedpkg retire' it... 

Well I took that as a hint and I ran the retire command.  I'm not sure
if it actually worked completely.  There was an error towards the end:

$ fedpkg retire 
"https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/X6ADYQA27WRLDQYAL3MHMGCHN3NQY47S/;
rm '.gitignore'
rm 'README.md'
rm 'libxlsxwriter.spec'
rm 'libxlsxwriter_sover.patch'
rm 'libxlsxwriter_zlib.patch'
rm 'sources'
[rawhide 922af46] 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/X6ADYQA27WRLDQYAL3MHMGCHN3NQY47S/
 7 files changed, 1 insertion(+), 143 deletions(-)
 delete mode 100644 .gitignore
 delete mode 100644 README.md
 create mode 100644 dead.package
 delete mode 100644 libxlsxwriter.spec
 delete mode 100644 libxlsxwriter_sover.patch
 delete mode 100644 libxlsxwriter_zlib.patch
 delete mode 100644 sources
Enumerating objects: 4, done.
Counting objects: 100% (4/4), done.
Delta compression using up to 12 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 417 bytes | 417.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
remote: Emitting a message to the fedora-messaging message bus.
remote: * Publishing information for 1 commits
remote: Sending to redis to log activity and send commit notification emails
remote: * Publishing information for 1 commits
remote:   - to fedora-message
remote: 2024-03-02 10:29:42,995 [WARNING] pagure.lib.notify: pagure is about to 
send a message that has no schemas: pagure.git.receive
To ssh://pkgs.fedoraproject.org/rpms/libxslxwriter
   e046198..922af46  rawhide -> rawhide
Could not execute retire: The following error occurred while disabling 
monitoring: You are not allowed to modify this project

Rich.

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

libxslxwriter (misspelled package) in zombie state

[Richard W.M. Jones]

We were discussing this on IRC, so just to bring the topic up on the
mailing list ...

(1) Package libxslxwriter (note: "xslx") with only automated activity
and no builds:
https://src.fedoraproject.org/rpms/libxslxwriter/commits/rawhide
https://koji.fedoraproject.org/koji/packageinfo?packageID=32741

(2) Package libxlsxwriter (note: "xlsx") which is normal:
https://src.fedoraproject.org/rpms/libxlsxwriter/commits/rawhide
https://koji.fedoraproject.org/koji/packageinfo?packageID=32754

It seems like the first package is in some sort of zombie state?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
--
___
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: dmesg restricted to root in Rawhide

[Richard W.M. Jones]

On Wed, Feb 28, 2024 at 11:24:41AM +0100, Karel Zak wrote:
> On Tue, Feb 27, 2024 at 08:15:49PM +0000, Richard W.M. Jones wrote:
> > 
> > https://gitlab.com/cki-project/kernel-ark/-/commit/ed5ba266c61e01a52359b5793a627e7c9aae8854
> > 
> > Why wasn't this a Fedora change proposal?
> > 
> > Also the justification given for such a major change is very thin.
> > I'm sure product security can give us some more details of precisely
> > what exploits will be mitigated, in the change proposal.
> 
> You can restore the original behavior by using:
> 
> # sysctl kernel.dmesg_restrict=0
> 
> However, be aware of the security consequences ;-)

Right ... which are what exactly?

I don't have untrusted local users, and if I wanted to host untrusted
local users I'd need to do a lot of extra lock down, so perhaps the
default here can be kernel.dmesg_restrict=0 with
kernel.dmesg_restrict=1 being used on locked down systems.

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

dmesg restricted to root in Rawhide

[Richard W.M. Jones]

https://gitlab.com/cki-project/kernel-ark/-/commit/ed5ba266c61e01a52359b5793a627e7c9aae8854

Why wasn't this a Fedora change proposal?

Also the justification given for such a major change is very thin.
I'm sure product security can give us some more details of precisely
what exploits will be mitigated, in the change proposal.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: rpmbuild problem with rust code

[Richard W.M. Jones]

On Mon, Feb 26, 2024 at 04:25:02PM -0500, Steve Grubb wrote:
> Hello,
> 
> I've run across a strange problem building a package that has some rust files 
> in it. The build goes fine until the end when it starts to check for 
> shebangs. 
> It ends like this:
> 
> /usr/src/debug/suricata-7.0.3-1.fc41.x86_64/rust/vendor/alloc-no-stdlib/src/
> lib.rs has shebang which doesn't start with '/' ([no_std])
> 
> When I check the file, I find this:
> #![no_std]
> 
> #[macro_use]
> mod allocated_memory;
> mod stack_allocator;
> mod allocated_stack_memory;
> 
> Not being a rust programmer, I have no good idea what the code is doing. I 
> can't patch this code to move it off the first line because it's vendored 
> code.

The code is correct (for Rust) as it indicates that the standard
library shouldn't be used:

https://docs.rust-embedded.org/book/intro/no-std.html

It's a bit unfortunate that Rust used the shebang syntax here,
although in practice they couldn't be confused as these files
shouldn't ever be executable.

It's also correct that RPM worries about this file since it is
installed (in debuginfo) and appears to contain a shebang.

> Is there a way to tell rpmbuild not to worry about this?

rust.spec has this in %prep, and /usr/lib/rpm/redhat/brp-mangle-shebangs
only seems to care about executable files, so this should help:

  # Sometimes Rust sources start with #![...] attributes, and "smart" editors 
think
  # it's a shebang and make them executable. Then brp-mangle-shebangs gets 
upset...
  find -name '*.rs' -type f -perm /111 -exec chmod -v -x '{}' '+'

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
--
___
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

Some mozjs102.spec weirdness

[Richard W.M. Jones]

There's a couple things about this spec file which are quite strange.

Firstly the %autosetup directory parameter is not the top level
directory:

  %prep
  %autosetup -n firefox-%{version}/js/src -N

(https://src.fedoraproject.org/rpms/mozjs102/blob/rawhide/f/mozjs102.spec#_108)

This means if you re-run 'fedpkg local' (or mock, I guess, without a
cleaning step) then it doesn't actually delete all the old files, only
the ones under js/src, and that causes build failures later on when it
tries to recreate directories that already exist:

  + mkdir third_party/python/looseversion
  mkdir: cannot create directory ‘third_party/python/looseversion’: File exists

(https://src.fedoraproject.org/rpms/mozjs102/blob/rawhide/f/mozjs102.spec#_121)

Secondly the mock /builddir path is hard-coded in a few places, eg:

  export AC_MACRODIR=/builddir/build/BUILD/firefox-%{version}/build/autoconf/
 
  sh ../../build/autoconf/autoconf.sh 
--localdir=/builddir/build/BUILD/firefox-%{version}/js/src configure.in > 
configure

(https://src.fedoraproject.org/rpms/mozjs102/blob/rawhide/f/mozjs102.spec#_150)

This breaks local builds with 'fedpkg build' or rpmbuild entirely.

Are these bugs?  Is there a reason to do things this way?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
--
___
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: Login issues to lists.* and src.*? Any outages?

[Richard W.M. Jones]

On Thu, Feb 22, 2024 at 04:26:26PM -0800, Kevin Fenzi wrote:
> On Thu, Feb 22, 2024 at 04:46:23PM -0500, Christopher wrote:
> > On Thu, Feb 22, 2024 at 4:01 PM Gary Buhrmaster
> >  wrote:
> > >
> > > On Thu, Feb 22, 2024 at 8:20 PM Christopher  
> > > wrote:
> > > >
> > > > Are there any known issues right now for logging in to 
> > > > lists.fedoraproject.org or src.fedoraproject.org?
> > > > Do we have a page for known outages?
> > >
> > > https://status.fedoraproject.org/
> > >
> > > It currently reports all systems operational
> > >
> > 
> > Yeah, I found that after asking. It also says it's updated manually,
> > so I'm not sure how reliable it is.
> 
> Well, I am not sure how to answer that... if we know about some issue
> that affects a lot of people we try and update it. If we don't know
> about an issue, we can't know to update it and if the issue is something
> that doesn't seem to affect a lot of people or is something we can
> quickly fix, we often don't update it.

So I sometimes have issues logging in.  For example it happened about
5 minutes ago, but the error isn't very interesting:

  Original URL: 
https://id.fedoraproject.org/login/gssapi/negotiate?ipsilon_transaction_id=8d11a868-b8f5-4e65-b48b-a53f592d2cfb
  Redirected URL: https://id.fedoraproject.org/login/pam

  Gateway Timeout

  The gateway did not receive a timely response from the upstream
  server or application.

Is it useful to report these?  Sometimes just retrying works, as
in fact happened when I retried it this time.

Rich.

> > > > I can log in to accounts.fedoraproject.org, so I know my password and 
> > > > 2FA token still works, but not to src.f.o or lists.f.o.
> > > > I tried to disable my 2FA in there, to see if that had an effect, but 
> > > > it wouldn't let me (I thought it was optional?)
> 
> What happens when you try and login?
> Hangs? an error? a timeout? 
> 
> We have had one of our identity provider vm's from time to time stop
> responding to requests (although it responds to liveness checks). 
> This might be a case of that if you see it timeout.
> I just checked and they are both up and working now... are you still
> seeing this?
> 
> > > Enrolling in 2FA is a one-way action
> > > (like Hotel California, you can never leave).
> 
> You can actually, but you have to mail ad...@fedoraproject.org, use some
> method to prove you are you and then your token can be removed. 
> 
> kevin



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

Re: Add risc-v to fedoraproject website?

[Richard W.M. Jones]

On Wed, Feb 21, 2024 at 10:41:22PM +, Richard W.M. Jones wrote:
> On Wed, Feb 21, 2024 at 08:38:20PM -, Ryan Bach via devel wrote:
> > Ubuntu already has a sever risc-v iso. Thoughts?
> 
> It's planned ...  Join us on #fedora-riscv.

I should say if you just want a disk image right now then they are
here:

http://fedora.riscv.rocks/koji/tasks?state=closed=flat=createAppliance=-id

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
--
___
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: Add risc-v to fedoraproject website?

[Richard W.M. Jones]

On Wed, Feb 21, 2024 at 08:38:20PM -, Ryan Bach via devel wrote:
> Ubuntu already has a sever risc-v iso. Thoughts?

It's planned ...  Join us on #fedora-riscv.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
--
___
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

%global __pytest_addopts or export PYTEST_ADDOPTS?

[Richard W.M. Jones]

For %{pytest} in Fedora there seem to be two possible ways to add
options eg for skipping tests, both working.

Either:

%global __pytest_addopts --options ...
(see attachment for example)

Or:

export PYTEST_ADDOPTS="--options ..."
(example: 
https://src.fedoraproject.org/rpms/scipy/blob/rawhide/f/scipy.spec#_228)

Is there a preferred way?

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
>From a0822f6feb94ccefd0c39797449d33eb88a2104f Mon Sep 17 00:00:00 2001
From: U2FsdGVkX1 
Date: Feb 20 2024 11:06:52 +
Subject: Add riscv64 support


---

diff --git a/python-astropy-healpix.spec b/python-astropy-healpix.spec
index 51939f0..f15e48f 100644
--- a/python-astropy-healpix.spec
+++ b/python-astropy-healpix.spec
@@ -4,7 +4,7 @@
 
 Name:   python-%{srcname}
 Version:0.7
-Release:5%{?dist}
+Release:6%{?dist}
 Summary:%{sum}
 
 License:BSD
@@ -59,6 +59,12 @@ rm -r %{modname}.egg-info
 %py3_install
 
 %check
+%ifarch riscv64
+%global __pytest_addopts \
+--deselect astropy_healpix/tests/test_healpy.py::test_pix2ang \
+--deselect astropy_healpix/tests/test_healpy.py::test_pix2vec \
+--deselect astropy_healpix/tests/test_healpy.py::test_ang2vec
+%endif
 %ifnarch s390x
 pushd %{buildroot}/%{python3_sitearch}
 %pytest %{modname}
@@ -76,6 +82,9 @@ rm -rf %{buildroot}%{python3_sitearch}/.pytest_cache
 %{python3_sitearch}/%{modname}*egg-info
 
 %changelog
+* Mon Jan 08 2024 Songsong Zhang  - 0.7-6
+- Add riscv64 support
+
 * Fri Jul 21 2023 Fedora Release Engineering  - 0.7-5
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild
 

--
___
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: temp symlink while building spec file?

[Richard W.M. Jones]

On Fri, Feb 16, 2024 at 12:22:45PM -0600, Ron Olson wrote:
> Hi all-
> 
> Since Apple released Swift 5.9 it requires a previous version of Swift to 
> build; it seems it can’t be built from scratch anymore just using the source. 
> To make it more complicated, during compiling it’s expected that certain 
> libraries are available specifically at /usr/lib/swift. In a container, I can 
> symlink the necessary directory with “ln -s 
> /usr/libexec/swift/5.8.1/lib/swift /usr/lib/swift” and Swift builds fine.
> 
> This doesn’t work with Mock and I’m trying to think of a way to build Swift 
> without introducing more patches; I’ve been able to create a patch that 
> changes the directory it’s looking for, but at the cost of compile errors 
> later on.
> 
> Might anyone have a suggestion about what can be done within mock to minimize 
> the changes needed to the source? I’m really hoping to avoid adding any more 
> patches as I feel there’s already too many (8!) just to make it build 
> successfully.

An LD_PRELOAD hack perhaps?  Ugly but it would avoid source changes.

I think the best plan is to just fix the source however ...  Can't you
persuade them to at least make $libdir configurable during the build?

Rich.

> I was wondering if I could submit a newer version of 5.8.1 with the symlink 
> as part of the rpm so that it would be available going forward. This seems 
> like the “safest” option, but before doing that I was wondering if there was 
> a specific thing that allows this in Mock that I’m just not aware of.
> 
> Thanks for any info!
> 
> Ron
> --
> ___
> 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-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

Re: Modern C failures in Haskell stack

[Richard W.M. Jones]

On Thu, Feb 15, 2024 at 12:57:21PM +0100, Florian Weimer wrote:
> For the first issue, please try this GHC patch (only compile-tested with
> the stage 0 compiler build this point):
> 
> diff --git a/compiler/GHC/HsToCore/Foreign/C.hs 
> b/compiler/GHC/HsToCore/Foreign/C.hs
> index 2164ded112..8beaa8986e 100644
> --- a/compiler/GHC/HsToCore/Foreign/C.hs
> +++ b/compiler/GHC/HsToCore/Foreign/C.hs
> @@ -560,7 +560,7 @@ mkFExportCBits dflags c_nm maybe_target arg_htys res_hty 
> is_IO_res_ty cc
>   ,   ppUnless res_hty_is_unit $
>   if libffi
>then char '*' <> parens (ffi_cResType <> char '*') <>
> -   text "resp = cret;"
> +   text "resp = " <> parens ffi_cResType <> text "cret;"
>else text "return cret;"
>   , rbrace
>   ]

Thanks, I tested this and it works.

I submitted it to GHC here:
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/12079

(Unfortunately to modify this you'll have to sign up to their gitlab
instance, which is very timeconsuming.)

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Modern C failures in Haskell stack

[Richard W.M. Jones]

I did a more thorough review of all the failed ghc-* packages by
submitting scratch builds for every one of them (starting from this
list: https://kojipkgs.fedoraproject.org/mass-rebuild/f40-failures.html).

It turns out that there is only one "class" of modern C failure,
of this form:

  /tmp/ghc167_0/ghc_8.c: In function 
‘zdreadlinezm1zi0zi3zi0zm5rmDmTTeacP6ZZL2WI5OaFEzdSystemziConsoleziReadlinezdreadlinezzm1zzi0zzi3zzi0zzm5rmDmTTeacP6L2WI5OaFEzuSystemzziConsolezziReadlinezuexportDequoter’:
  /tmp/ghc167_0/ghc_8.c:68:17: error:
   error: assignment to ‘ffi_arg’ {aka ‘long unsigned int’} from ‘HsPtr’ 
{aka ‘void *’} makes integer from pointer without a cast [-Wint-conversion]
 68 | *(ffi_arg*)resp = cret;
| ^
 |
  68 | *(ffi_arg*)resp = cret;
 | ^

I'll try Florian's suggested patch for ghc in a few minutes.

The other errors were not really related (except maybe OpenSSL ones).
They were:

* ghc-libxml-sax has non-generated code with missing headers

* ghc-th-orphans crashes ("Killed") during the build

* ghc-gi-gtk, ghc-gi-ostree seems to have a haskell code bug

* ghc-HsOpenSSL errors are significantly complex and need
  further investigation:
  https://koji.fedoraproject.org/koji/taskinfo?taskID=113537596

Several packages actually built fine so I have submitted proper builds
for those.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
--
___
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: Modern C failures in Haskell stack

[Richard W.M. Jones]

On Thu, Feb 15, 2024 at 12:24:22PM +0100, Jakub Jelinek wrote:
> On Thu, Feb 15, 2024 at 11:13:08AM +0000, Richard W.M. Jones wrote:
> > We noticed that some ghc-* packages FTBFS with Modern C failures eg
> > these two picked at random:
> > 
> >   https://koji.fedoraproject.org/koji/taskinfo?taskID=113534568
> >   https://koji.fedoraproject.org/koji/taskinfo?taskID=113534602
> > 
> > I think what's happening here is that ghc is generating C FFI code
> > which is fed to GCC 14.  The code being generated is buggy.
> > 
> > So probably the fix for this is just in ghc itself.  I looked at
> > upstream ghc and wasn't able to identify any commits which fix this
> > (except maybe
> > https://github.com/ghc/ghc/commit/b3a3534b6f75b34dc4db76e904e071485da6d5cc).
> > But I didn't look especially hard and the code is very complicated.
> > 
> > An alternative to fixing this in the compiler is to throw up our hands
> > and add:
> > 
> >   %global build_type_safety_c 0
> 
> Please don't if at all possible.
> 
> > to every affected ghc-* package.  eg This fixes ghc-readline:
> > 
> >   https://koji.fedoraproject.org/koji/taskinfo?taskID=113535426
> > 
> > Any thoughts on this?
> 
> The diagnostics is quite clear what needs to be done, in some cases
> #include , in others (uintptr_t) cast added when you want to
> assign a pointer to ffi_arg which is integral type.  Perhaps stdint.h
> include for that.

The problem isn't that we don't know how to change the code,
the problem is we need to work out where in the depths of GHC
to make the change.  Take a look for yourself:

https://github.com/ghc/ghc/blob/master/compiler/GHC/HsToCore/Foreign/C.hs

Rich.



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

Modern C failures in Haskell stack

[Richard W.M. Jones]

We noticed that some ghc-* packages FTBFS with Modern C failures eg
these two picked at random:

  https://koji.fedoraproject.org/koji/taskinfo?taskID=113534568
  https://koji.fedoraproject.org/koji/taskinfo?taskID=113534602

I think what's happening here is that ghc is generating C FFI code
which is fed to GCC 14.  The code being generated is buggy.

So probably the fix for this is just in ghc itself.  I looked at
upstream ghc and wasn't able to identify any commits which fix this
(except maybe
https://github.com/ghc/ghc/commit/b3a3534b6f75b34dc4db76e904e071485da6d5cc).
But I didn't look especially hard and the code is very complicated.

An alternative to fixing this in the compiler is to throw up our hands
and add:

  %global build_type_safety_c 0

to every affected ghc-* package.  eg This fixes ghc-readline:

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

Any thoughts on this?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Question about conditional BuildRequires lines

[Richard W.M. Jones]

On Wed, Feb 14, 2024 at 03:21:38PM +, Tom Hughes wrote:
> On 14/02/2024 14:54, Richard W.M. Jones wrote:
> 
> >https://src.fedoraproject.org/rpms/rapidjson/pull-request/7
> >
> >I don't think what Tom is saying there is correct, or is it?
> 
> The answer is that I'm wrong about it breaking things, because
> koji uses the unpacked spec file to install dependencies not the
> requires from the srpm.
> 
> However the guidelines whilst not mentioning this case do prohibit
> the use of %{_isa} in BRs because it produces incorrect dependencies
> in the srpm - the only real difference is that this case give you
> a missing dependency rather than a broken one.

I was hoping that people with more experience would comment on the
bug, and they did, so thanks.

The issue we have is that valgrind is simply not a package on RISC-V.
Valgrind requires upstream porting work which is only partially
complete (and IIRC not upstream yet).  I don't know any other way to
express this other than using:

%ifarch %{valgrind_arches}
BuildRequires: valgrind
%endif

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
--
___
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

Question about conditional BuildRequires lines

[Richard W.M. Jones]

https://src.fedoraproject.org/rpms/rapidjson/pull-request/7

I don't think what Tom is saying there is correct, or is it?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
--
___
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: A note about riscv64 changes

[Richard W.M. Jones]

On Wed, Feb 14, 2024 at 10:27:53AM +, Peter Robinson wrote:
> Hi Richard,
> 
> > A quick note that you may be seeing pull requests for riscv64 changes
> > against your packages, like these examples:
> >
> > https://src.fedoraproject.org/rpms/ghc/pull-request/7
> > https://src.fedoraproject.org/rpms/zlib-ng/pull-request/11
> > https://src.fedoraproject.org/rpms/gdal/pull-request/21
> >
> > For many years we have been building Fedora for the RISC-V
> > architecture on a separate build system at
> > http://fedora.riscv.rocks/koji/ , and maintaining downstream patches
> > against dist-git in http://fedora.riscv.rocks:3000/rpms/
> > (Most of this work was done by David Abdurachmanov, not me.)
> 
> I'm very happy to see these start to land, let me know if you need any
> assistance.
> 
> > I'm trying to get as much of this stuff back into Fedora dist-git,
> > although only (hopefully!) where it doesn't break ordinary builds and
> > isn't intrusive.  Obviously I may get this wrong sometimes so feel
> > free to make comments if you disagree with changes.
> >
> > Some time, with any luck soon, we will be creating a new Koji instance
> > with FAS authentication which will allow anyone to optionally build
> > their packages on RISC-V builders.  And then later in the year we may
> > be in a position with the availability of new hardware to discuss
> > adding RISC-V as a regular architecture.  (We're not there yet as
> > current hardware is far too slow to force it on Fedora developers.)
> 
> Will this instance run with koji-shadow to properly mirror the builds
> with all the appropriate NVR dependencies to properly mirror Fedora
> primary builds?

TBD.

Koji-shadow specifically is unmaintained.  Maybe we'll try to hack
something together with scripts, or get koji-shadow working.

At the moment David rebuilds packages from regular Koji in
fedora.riscv.rocks by hand, I think, or at least using some scripts
that he has devised.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

A note about riscv64 changes

[Richard W.M. Jones]

A quick note that you may be seeing pull requests for riscv64 changes
against your packages, like these examples:

https://src.fedoraproject.org/rpms/ghc/pull-request/7
https://src.fedoraproject.org/rpms/zlib-ng/pull-request/11
https://src.fedoraproject.org/rpms/gdal/pull-request/21

For many years we have been building Fedora for the RISC-V
architecture on a separate build system at
http://fedora.riscv.rocks/koji/ , and maintaining downstream patches
against dist-git in http://fedora.riscv.rocks:3000/rpms/
(Most of this work was done by David Abdurachmanov, not me.)

I'm trying to get as much of this stuff back into Fedora dist-git,
although only (hopefully!) where it doesn't break ordinary builds and
isn't intrusive.  Obviously I may get this wrong sometimes so feel
free to make comments if you disagree with changes.

Some time, with any luck soon, we will be creating a new Koji instance
with FAS authentication which will allow anyone to optionally build
their packages on RISC-V builders.  And then later in the year we may
be in a position with the availability of new hardware to discuss
adding RISC-V as a regular architecture.  (We're not there yet as
current hardware is far too slow to force it on Fedora developers.)

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
--
___
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: Unresponsive maintainer: petersen / Pandoc package not updated since June 2023: Security vulnerability, CVE-2023-35936 (medium)

[Richard W.M. Jones]

Re: pandoc, we managed to build it on RISC-V thanks to the changes you
merged in ghc:

  $ uname -a
  Linux vf2.home.annexia.org 5.15.0-starfive #1 SMP Sun Jun 11 07:48:39 UTC 
2023 riscv64 GNU/Linux
  $ rpm -q pandoc
  pandoc-3.1.3-27.fc41.riscv64
  $ pandoc --version
  pandoc 3.1.3
  Features: -server +lua
  Scripting engine: Lua 5.4
  User data directory: /home/rjones/.local/share/pandoc
  Copyright (C) 2006-2023 John MacFarlane. Web: https://pandoc.org
  This is free software; see the source for copying conditions. There is no
  warranty, not even for merchantability or fitness for a particular purpose.

Is it possible you could bump and rebuild the ghc package in Rawhide?
That will allow us to rebuild our downstream ghc package
(http://fedora.riscv.rocks/koji/buildinfo?buildID=281302) without the
'.0.riscv64' extension.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
--
___
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: FYI: AFL++ now builds a GCC plugin

[Richard W.M. Jones]

On Tue, Feb 06, 2024 at 01:46:28PM +0100, Florian Weimer wrote:
> * Richard W. M. Jones:
> 
> >   https://koji.fedoraproject.org/koji/taskinfo?taskID=113035034
> >   https://bugzilla.redhat.com/show_bug.cgi?id=2262539
> >
> > The new AFL++ (American Fuzzy Lop, a fuzzing tool) in Rawhide appears
> > to be building a GCC plugin, contained in one or all of these newly
> > added files:
> >
> >   %global afl_helper_path %{_libdir}/afl
> >   %{_bindir}/afl-gcc-fast
> >   %{_bindir}/afl-g++-fast
> >   %{afl_helper_path}/afl-gcc-cmplog-pass.so
> >   %{afl_helper_path}/afl-gcc-cmptrs-pass.so
> >   %{afl_helper_path}/afl-gcc-pass.so
> >   %{afl_helper_path}/afl-gcc-rt.o
> >   %{afl_helper_path}/injection-pass.so
> >
> > I'm going to guess this will introduce a dependency on the exact
> > version of GCC (major only? or major.minor? not sure).  Just like
> > annobin.  Which might require that this package is rebuilt when GCC is
> > rebuilt (only major? or all rebuilds? again, don't know).
> 
> It depends on what the plugin does.  Not all plugins are as sensitive to
> e.g. GCC options changes.  A precise NVR dependency might still make
> sense.  It's easier to pull off here because there's no cyclic
> dependency issue.

So I don't know how it works precisely, but this is my understanding
of what this all does ...

For fuzzing we want to produce an instrumented binary which, when run
on an input, traces the sequences of branches (ie. paths / basic
blocks) taken through the instrumented code.  The aim of the fuzzer is
to find new inputs which explore new paths in the code, until a crash
is found.

One way that AFL has done this traditionally is with an assembler
wrapper which munges the assembly output of the compiler, searching
and replacing branches with instrumentation code.  However this is
obviously very compiler / architecture specific.  In particular AFL
only implements this for GCC + x86_64, GCC + i686 (support dropped
recently, apparently by accident), and macOS + arm64.

AIUI the GCC (also LLVM) plugins replace this with some compiler
internal munging instead.  One advantage of this is it's not
architecture dependent any more, although we don't yet use this in
Fedora.

Also the compiler plugin is supposed to be faster.  However I have not
been troubled by the compilation speed of AFL.  And AIUI it makes no
difference to the run time speed of the binary, which is where faster
speed would really make the difference for fuzzing.

All of the above is based on my possibly faulty understanding.  Any
errors are yours to keep.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: FYI: AFL++ now builds a GCC plugin

[Richard W.M. Jones]

On Tue, Feb 06, 2024 at 01:23:48PM +0100, Jakub Jelinek wrote:
> On Tue, Feb 06, 2024 at 11:54:23AM +0000, Richard W.M. Jones wrote:
> >   https://koji.fedoraproject.org/koji/taskinfo?taskID=113035034
> >   https://bugzilla.redhat.com/show_bug.cgi?id=2262539
> > 
> > The new AFL++ (American Fuzzy Lop, a fuzzing tool) in Rawhide appears
> > to be building a GCC plugin, contained in one or all of these newly
> > added files:
> > 
> >   %global afl_helper_path %{_libdir}/afl
> >   %{_bindir}/afl-gcc-fast
> >   %{_bindir}/afl-g++-fast
> >   %{afl_helper_path}/afl-gcc-cmplog-pass.so
> >   %{afl_helper_path}/afl-gcc-cmptrs-pass.so
> >   %{afl_helper_path}/afl-gcc-pass.so
> >   %{afl_helper_path}/afl-gcc-rt.o
> >   %{afl_helper_path}/injection-pass.so
> > 
> > I'm going to guess this will introduce a dependency on the exact
> > version of GCC (major only? or major.minor? not sure).  Just like
> > annobin.  Which might require that this package is rebuilt when GCC is
> > rebuilt (only major? or all rebuilds? again, don't know).
> > 
> > If this proves to be a problem then I can drop the GCC plugin usage,
> > or we could work out a process to deal with rebuilding.
> > 
> > Anyway, let's look out for this and see if it causes trouble, and then
> > decide what to do.
> 
> Guess it depends on what exactly it uses.
> Obviously, there must be a dependency on the major version.  The plugin API
> (which is essentilly everything in the compiler) can change obviously at any
> time, but in reality on release branches (at least past the major.1 release)
> it doesn't change much very often, from the annobin experience the only
> major problematic thing are accesses to options - global_options{,_set} and
> the like, including through macros like flag_* or opt_for_fn etc.
> 
> As described in https://gcc.gnu.org/r11-5149 , annobin has some code to find
> out offsets of options in global_options{,_set} etc. even if it has been
> built against different version of gcc (same major, but from different
> date), where perhaps some options have been added or removed and that in
> turn caused reshuffling of options which were there before and are still in
> there but at different offsets.

Not sure if it helps but it seems these source files implement the
plugin:

https://github.com/AFLplusplus/AFLplusplus/blob/stable/instrumentation/afl-gcc-cmplog-pass.so.cc
https://github.com/AFLplusplus/AFLplusplus/blob/stable/instrumentation/afl-gcc-cmptrs-pass.so.cc
https://github.com/AFLplusplus/AFLplusplus/blob/stable/instrumentation/afl-gcc-pass.so.cc

and this header:

https://github.com/AFLplusplus/AFLplusplus/blob/stable/instrumentation/afl-gcc-common.h

At a glance it seems like it uses a lot of APIs ...

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
--
___
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

FYI: AFL++ now builds a GCC plugin

[Richard W.M. Jones]

  https://koji.fedoraproject.org/koji/taskinfo?taskID=113035034
  https://bugzilla.redhat.com/show_bug.cgi?id=2262539

The new AFL++ (American Fuzzy Lop, a fuzzing tool) in Rawhide appears
to be building a GCC plugin, contained in one or all of these newly
added files:

  %global afl_helper_path %{_libdir}/afl
  %{_bindir}/afl-gcc-fast
  %{_bindir}/afl-g++-fast
  %{afl_helper_path}/afl-gcc-cmplog-pass.so
  %{afl_helper_path}/afl-gcc-cmptrs-pass.so
  %{afl_helper_path}/afl-gcc-pass.so
  %{afl_helper_path}/afl-gcc-rt.o
  %{afl_helper_path}/injection-pass.so

I'm going to guess this will introduce a dependency on the exact
version of GCC (major only? or major.minor? not sure).  Just like
annobin.  Which might require that this package is rebuilt when GCC is
rebuilt (only major? or all rebuilds? again, don't know).

If this proves to be a problem then I can drop the GCC plugin usage,
or we could work out a process to deal with rebuilding.

Anyway, let's look out for this and see if it causes trouble, and then
decide what to do.

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: "noarch sysroot subpackages" commit breaks glibc compile on riscv64

[Richard W.M. Jones]

On Thu, Feb 01, 2024 at 02:24:10PM +0100, Florian Weimer wrote:
> * David Abdurachmanov:
> 
> > Hi Florian,
> >
> > I was trying to build the latest glibc [0] in Fedora 40 for riscv64,
> > but it failed. It seems to be related to your last commit.
> >
> > [..]
> > + ln -s libBrokenLocale.so.1 usr/lib64/libBrokenLocale.so
> > + for sl in `find $RPM_BUILD_ROOT/$pfx$lib -maxdepth 1 -type l`
> > + set +x
> > + ln -s . usr/lib64/lp64d
> > ln: failed to create symbolic link 'usr/lib64/lp64d/.': File exists
> > error: Bad exit status from /var/tmp/rpm-tmp.7qPZkS (%install)
> > [..]
> >
> > Full log: 
> > http://fedora.riscv.rocks/kojifiles/work/tasks/9391/1599391/build.log
> > Build info: http://fedora.riscv.rocks/koji/taskinfo?taskID=1599391
> >
> > This is probably related to this:
> > https://src.fedoraproject.org/rpms/glibc/blob/rawhide/f/glibc.spec#_1279
> >
> > Cheers,
> > david
> > - - -
> > [0] 
> > https://src.fedoraproject.org/rpms/glibc/c/0bd93c5697bc60e4f4a84f5b55c98f351883e689?branch=rawhide
> 
> That refers to:
> 
> %ifarch riscv64
> # RISC-V ABI wants to install everything in /lib64/lp64d or /usr/lib64/lp64d.
> # Make these be symlinks to /lib64 or /usr/lib64 respectively.  See:
> # 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/DRHT5YTPK4WWVGL3GIN5BF2IKX2ODHZ3/
> for d in %{glibc_sysroot}%{_libdir} %{glibc_sysroot}/%{_lib}; do
>   mkdir -p $d
>   (cd $d && ln -sf . lp64d)
> done
> %endif

Although it was me who added this in 2018, I think it looks like a
mess now.  Why do we need this .../lp64d subdir for Fedora?

> Please try this:
> 
> diff --git a/glibc.spec b/glibc.spec
> index 6116752..e4d5e44 100644
> --- a/glibc.spec
> +++ b/glibc.spec
> @@ -1571,6 +1571,10 @@ for lib in lib lib64;  do
>   set +x
>   slbase=$(basename $sl)
>   sltarget=$(basename $(readlink $sl))
> + if test "$sltarget" = . ; then
> + # This is the lp64d symbolic link on riscv64, see above.
> + continue
> + fi
>   if ! test -r usr/$lib/$sltarget; then
>   echo "$sl: inferred $sltarget ($(readlink $sl)) missing"
>   exit 1
> 
> We will have to fix this again (and wrap-find-debuginfo.sh and as well)
> once Fedora adopts the standard RISC-V paths.

Shouldn't we adopt the normal Fedora paths instead?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: "noarch sysroot subpackages" commit breaks glibc compile on riscv64

[Richard W.M. Jones]

[Adding Fedora devel]

On Thu, Feb 01, 2024 at 02:29:41PM +0200, David Abdurachmanov wrote:
> Hi Florian,
> 
> I was trying to build the latest glibc [0] in Fedora 40 for riscv64,
> but it failed. It seems to be related to your last commit.
> 
> [..]
> + ln -s libBrokenLocale.so.1 usr/lib64/libBrokenLocale.so
> + for sl in `find $RPM_BUILD_ROOT/$pfx$lib -maxdepth 1 -type l`
> + set +x
> + ln -s . usr/lib64/lp64d
> ln: failed to create symbolic link 'usr/lib64/lp64d/.': File exists
> error: Bad exit status from /var/tmp/rpm-tmp.7qPZkS (%install)
> [..]
> 
> Full log: 
> http://fedora.riscv.rocks/kojifiles/work/tasks/9391/1599391/build.log
> Build info: http://fedora.riscv.rocks/koji/taskinfo?taskID=1599391
> 
> This is probably related to this:
> https://src.fedoraproject.org/rpms/glibc/blob/rawhide/f/glibc.spec#_1279
> 
> Cheers,
> david
> - - -
> [0] 
> https://src.fedoraproject.org/rpms/glibc/c/0bd93c5697bc60e4f4a84f5b55c98f351883e689?branch=rawhide

-- 
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: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Richard W.M. Jones]

On Tue, Jan 30, 2024 at 08:38:51AM -0500, Stephen Gallagher wrote:
> 3) Fedora has a long-standing and well-communicated stance that we are
> a Wayland distribution first and foremost and that X11 support is
> intended as a migration-support tool rather than a first-class
> citizen.

Does it?  This is very much news to me, so I don't think you can call
it "well-communicated".  We also have an XFCE desktop spin and
probably others that require X11.
https://fedoraproject.org/uk/spins/xfce/

In addition Wayland doesn't actually replace all the basic
functionality of X11 even after all these years, which is why I need
to use it.

> 4) There was a comment on the FESCo ticket to the effect of '"you must
> move to Wayland because no one maintains X11!". Here are some people
> who are maintaining X11 packages, so let them do their thing.' This is
> misleading, as the move to Wayland is specifically because the
> upstream of X11 *itself* is largely unmaintained. These packages are
> not maintaining X11, they are adding new dependencies on it.

They're maintaining parts of the X11 stack.

> My proposal for consideration is this:
> "FESCo will allow these packages in the main Fedora repositories,
> however they may not be included by default on any release-blocking
> deliverable (ISO, image, etc.)"

It seems quite strong.  I'm unclear why having X11 packages and spins
for those that want to use them is a problem.  It seems like the
missing functionality of Wayland is the bigger issue that needs to be
addressed.

Rich.

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

Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Richard W.M. Jones]

On Tue, Jan 30, 2024 at 12:47:44PM +, Sérgio Basto wrote:
> Link to the FESCo ticket: https://pagure.io/fesco/issue/3165
> 
> and I'm very upset 

Assume best intent first of all.  An injunction is a temporary thing
to allow some space for a decision to be made.

(I added my personal opinion to the ticket itself)

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
--
___
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

Orphaned: ocaml-newt

[Richard W.M. Jones]

This package contains OCaml bindings for newt, which is a kind of
terminal-based windowing system (I think originally used in Anaconda
back in the day).

It doesn't build after the GCC 14 changes:

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

It's also obsolete (as is newt) and unmaintained upstream.
I have orphaned it.

Unless you have a great desire to take over maintenance, I wouldn't
recommend taking it.  Better to let it drift gracefully into
retirement IMHO.

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: [rawhide] libavif soname bump

[Richard W.M. Jones]

On Thu, Jan 25, 2024 at 11:14:04AM +0100, Frantisek Zatloukal wrote:
> In about a week (after mass rebuild before branching), I'll start
> with bumping libavif in rawhide from 0.11.x to 1.0.3
> ( https://src.fedoraproject.org/rpms/ libavif/pull-request/2 ,
> soname bump from 15 to 16).

I'm confused .. Wouldn't it be better to do this after branching?
Otherwise you're introducing an SONAME bump into the stabilising
Fedora 40.

> If I am not missing anything, it should mean ABI-only change, so all
> the dependencies that aren't FTBFS should rebuild fine. Should
> anything not build, I'll add a compat package not to cause any new
> FTIs.
>
> This would affect the following packages:
> avif-pixbuf-loader
> celestia-common
> darktable
> efl
> gd
> kf5-kimageformats
> plasma-wallpapers-dynamic
> python-imagecodecs
> webkit2gtk4.0
> webkit2gtk4.1
> webkitgtk6.0
> xpra
>
> If any of the maintainers would prefer to do the rebuild themselves,
> please do feel free to speak up, I'll send the side-tag id here
> before the rebuild starts. Otherwise, I'll handle all the rebuilds.
>
> I probably don't have to wait until the mass rebuild is finished,
> but doing so will leave me with a calmer sleep.

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

Re: Announcement: Retiring zlib and minizip-compat from Rawhide

[Richard W.M. Jones]

On Wed, Jan 24, 2024 at 11:14:06AM -0300, Tulio Magno Quites Machado Filho 
wrote:
> The zlib-ng-compat and minizip-ng-compat packages have been in Rawhide for
> more than a month.
> Considering things have been working well, we believe it's time to retire the
> zlib and minizip-compat packages.
> 
> This step should not cause any changes, because zlib-ng-compat and
> minizip-ng-compat already obsoleted them.
> However, if you find any issues, please contact us.
> 
> [1] https://fedoraproject.org/wiki/Changes/ZlibNGTransition
> [2] https://fedoraproject.org/wiki/Changes/MinizipNGTransition

Great work on this BTW.  In my tests it improves zlib uncompression
speed by something like 40%, which for a few tasks (unpacking qcow2
files was one) noticably improves overall performance.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
--
___
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: Another mass rebuild blocker: glibc qsort regression

[Richard W.M. Jones]

On Tue, Jan 23, 2024 at 01:50:30PM +0100, Florian Weimer wrote:
> There's a regression in qsort that needs to be fixed before the mass
> rebuild can be restarted:
> 
>   
> 
> I'm going to work on this with priority.
> 
> Posting this here because Fedora infrastructure is having authentication
> troubles.  Please relay as appropriate.

The authentication issue being this one:

https://pagure.io/fedora-infrastructure/issue/11733

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: side-tag with GCC 14.0.1 snapshot for Fedora 40

[Richard W.M. Jones]

On Mon, Jan 15, 2024 at 10:37:10PM +0100, Jakub Jelinek wrote:
> On Mon, Jan 15, 2024 at 09:33:34PM +0000, Richard W.M. Jones wrote:
> > On Mon, Jan 15, 2024 at 02:01:06PM +0100, Jakub Jelinek wrote:
> > > Hi!
> > > 
> > > The f40-build-side-81394 side-tag contains new
> > > gcc, annobin, libtool and redhat-rpm-config for f40, meant to be
> > > tagged into rawhide shortly before the mass rebuild.
> > > 
> > > If there is anything you'd like to rebuild against it before the mass
> > > rebuild (such as packages depending on Ada which like every year bumped
> > > sonames of its shared libraries), please do so soon.
> > 
> > I didn't build anything into the side tag, but I did download the
> > packages and rebuilt a few virt-related packages like qemu, libvirt,
> > virt tools, libguestfs, nbdkit.
> > 
> > One thing I noticed (not virt related) was this PHP bindings failure:
> 
> See https://github.com/php/php-src/pull/12821

That looks like it, thanks :-)

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: side-tag with GCC 14.0.1 snapshot for Fedora 40

[Richard W.M. Jones]

On Mon, Jan 15, 2024 at 02:01:06PM +0100, Jakub Jelinek wrote:
> Hi!
> 
> The f40-build-side-81394 side-tag contains new
> gcc, annobin, libtool and redhat-rpm-config for f40, meant to be
> tagged into rawhide shortly before the mass rebuild.
> 
> If there is anything you'd like to rebuild against it before the mass
> rebuild (such as packages depending on Ada which like every year bumped
> sonames of its shared libraries), please do so soon.

I didn't build anything into the side tag, but I did download the
packages and rebuilt a few virt-related packages like qemu, libvirt,
virt tools, libguestfs, nbdkit.

One thing I noticed (not virt related) was this PHP bindings failure:

In file included from /usr/include/php/Zend/zend_globals.h:30,
 from /usr/include/php/Zend/zend_compile.h:769,
 from /usr/include/php/Zend/zend_modules.h:24,
 from /usr/include/php/Zend/zend_API.h:25,
 from /usr/include/php/main/php.h:35,
 from /home/rjones/d/libguestfs/php/extension/guestfs_php.c:44:
/usr/include/php/Zend/zend_atomic.h: In function 'zend_atomic_bool_exchange_ex':
/usr/include/php/Zend/zend_atomic.h:88:16: error: implicit declaration of 
function '__c11_atomic_exchange'; did you mean '__atomic_exchange'? 
[-Wimplicit-function-declaration]
   88 | return __c11_atomic_exchange(>value, desired, 
__ATOMIC_SEQ_CST);
  |^
  |__atomic_exchange
/usr/include/php/Zend/zend_atomic.h: In function 'zend_atomic_bool_load_ex':
/usr/include/php/Zend/zend_atomic.h:92:16: error: implicit declaration of 
function '__c11_atomic_load'; did you mean '__atomic_load'? 
[-Wimplicit-function-declaration]
   92 | return __c11_atomic_load(>value, __ATOMIC_SEQ_CST);
  |^
  |__atomic_load
/usr/include/php/Zend/zend_atomic.h: In function 'zend_atomic_bool_store_ex':
/usr/include/php/Zend/zend_atomic.h:96:9: error: implicit declaration of 
function '__c11_atomic_store'; did you mean '__atomic_store'? 
[-Wimplicit-function-declaration]
   96 | __c11_atomic_store(>value, desired, __ATOMIC_SEQ_CST);
  | ^~
  | __atomic_store

Do you think it's OK to go with the suggestion of replacing the
__c11_atomic_* functions with __atomic_* equivalents?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: libguestfs build failure (on riscv64, but seems general)

[Richard W.M. Jones]

libguestfs-1.52.0-4.fc40 uses curl instead of wget{,2}:

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

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
--
___
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

libguestfs build failure (on riscv64, but seems general)

[Richard W.M. Jones]

David,

Thanks for notifying me about this build failure that happened while I
was on holiday last week:

  
http://fedora.riscv.rocks/koji/getfile?taskID=1594179=DEFAULT=root.log
  
http://fedora.riscv.rocks/koji/getfile?taskID=1594179=DEFAULT=build.log

I copied the relevant part from root.log & build.log at the end of the
email in case those links go away.

What's happening here is we're running this code to determine if this
is a local build with the network available or a Koji build:

  
https://src.fedoraproject.org/rpms/libguestfs/blob/rawhide/f/libguestfs.spec#_723

  if ping -c 3 -w 20 8.8.8.8 && wget http://libguestfs.org -O /dev/null; then
extra=# network is available
  else
# assume no network, ie. Koji case

As you can see from build.log we take the first branch, when we should
be taking the second (no network / Koji) branch.

The problem is that ping fails but wget succeeds, even though as you
can see from the log it should be failing.  This puzzled me for a
while since it doesn't happen when I tested with 'wget' locally.

However the problem here is we're using 'wget2' which seems to have
broken exit codes.  eg:

  $ wget --version
  GNU Wget2 2.1.0 - multithreaded metalink/file/website downloader

  $ wget http://nosuchdomainreallynodomain.abc -O /dev/null
  Failed to resolve 'nosuchdomainreallynodomain.abc' (Name or service not known)
  Failed to resolve 'nosuchdomainreallynodomain.abc' (Name or service not known)
  [...]

  $ echo $?
  0

I think this test will fail to work properly anywhere that we are
using wget2.  Apparently regular Koji is using wget2 but ping fails
there, so Koji acts slightly differently from fedora.riscv.rocks (but
this is still a bug in wget2).

I filed this bug upstream:

  https://gitlab.com/gnuwget/wget2/-/issues/652

I'll also look to see if I can adjust the test, maybe use curl instead.

Rich.

--- Snippets from root.log & build.log below ---

DEBUG util.py:446:   wget2riscv64  
2.1.0-5.fc40  build  249 k
DEBUG util.py:446:   wget2-libs   riscv64  
2.1.0-5.fc40  build  223 k

+ ping -c 3 -w 20 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=54 time=42.6 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=54 time=42.5 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=54 time=42.5 ms
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2016ms
rtt min/avg/max/mdev = 42.530/42.570/42.632/0.044 ms
+ wget http://libguestfs.org -O /dev/null
Failed to resolve 'libguestfs.org' (Temporary failure in name resolution)
Failed to resolve 'libguestfs.org' (Temporary failure in name resolution)
Failed to resolve 'libguestfs.org' (Temporary failure in name resolution)
Failed to resolve 'libguestfs.org' (Temporary failure in name resolution)
Failed to resolve 'libguestfs.org' (Temporary failure in name resolution)
Failed to resolve 'libguestfs.org' (Temporary failure in name resolution)
Failed to resolve 'libguestfs.org' (Temporary failure in name resolution)
Failed to resolve 'libguestfs.org' (Temporary failure in name resolution)
Failed to resolve 'libguestfs.org' (Temporary failure in name resolution)
Failed to resolve 'libguestfs.org' (Temporary failure in name resolution)
Failed to resolve 'libguestfs.org' (Temporary failure in name resolution)
Failed to resolve 'libguestfs.org' (Temporary failure in name resolution)
Failed to resolve 'libguestfs.org' (Temporary failure in name resolution)
Failed to resolve 'libguestfs.org' (Temporary failure in name resolution)
Failed to resolve 'libguestfs.org' (Temporary failure in name resolution)
Failed to resolve 'libguestfs.org' (Temporary failure in name resolution)
Failed to resolve 'libguestfs.org' (Temporary failure in name resolution)
Failed to resolve 'libguestfs.org' (Temporary failure in name resolution)
Failed to resolve 'libguestfs.org' (Temporary failure in name resolution)
Failed to connect: General error
Failed to connect: General error
Failed to connect: General error
Failed to connect: General error
Failed to connect: General error
Failed to connect: General error
Failed to connect: General error
Failed to connect: General error
Failed to connect: General error
Failed to connect: General error
Failed to connect: General error
Failed to connect: General error
Failed to connect: General error
Failed to connect: General error
Failed to connect: General error
Failed to connect: General error
Failed to connect: General error
Failed to connect: General error
Failed to connect: General error
Failed to connect: General error
Failed to resolve 'libguestfs.org' (Temporary failure in name resolution)
+ extra=

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. 

RISC-V ABI issue with ULEB128

[Richard W.M. Jones]

I'm not sure exactly the effect on RISC-V binaries, but I wanted to
raise it here to get the attention of the Fedora toolchain team ...

Here's the bug:

https://sourceware.org/bugzilla/show_bug.cgi?id=31179
RISC-V: The SET/ADD/SUB fix breaks ABI compatibility with 2.41 objects

It refers to this change in binutils 2.41:

https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d76f528fafbb4270a98746bc

As far as I understand the issue (which is not too far) this mainly
affects shipped *.o and *.a files (ie. static libraries and similar)
which were compiled with binutils < 2.41, which either won't link
correctly or will give a linker error when using GNU ld from binutils 2.41.

Unclear if it also affects *.so files (which would be a much more
serious ABI break), and also if it affects most binaries or just a
few.  I initially thought this only affected programs using 128 bit
ints, so didn't think it was too important, but after reading the
commit I'm not sure that is really true.

There's been discussion about adding an ELF tag, but that seems very
problematic to me:
https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/414

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

Re: Update on the Modern C initiative

[Richard W.M. Jones]

On Thu, Dec 21, 2023 at 01:59:59PM +0100, Florian Weimer wrote:
> Based on my records, all issues that can lead to silent miscompilation
> because of altered configure probes (autoconf/CMake and a few others)
> have been addressed, or there are at least Bugzilla bugs filed for them.
> There could be some gaps due to lack of architecture capture, general
> rawhide churn, or configure scripts running late during the build, which
> we do not reach due to a previous build failure.  But these gaps should
> fairly small, I hope.  It's also not a new problem—while fixing newly
> introduced errors, we encountered cases where autoconf probes had
> already been failing unexpectedly for a long time because of typos or
> missing #include directives.
> 
> I originally wanted to fix the int-conversion issues next.  That package
> set is fairly small (about 60 packages).

Do you have a list of affected packages?

Rich.

> But it's more or less a coin
> toss whether the compiler errors is due to a missing cast due to C type
> system limitations, or indicative of a real problem (typically
> manifesting as a crash at run time if the code is ever executed).  The
> latter can be quite difficult to fix and may require domain-specific
> knowledge.  Just adding the cast in both cases just obscures the crash
> or misbehavior in the second case, and robs us of an opportunity to fix
> this properly.  I see what I can do to fix packages, but it's unlikely
> that it will going to be all of them.
> 
> Looking at the calendar and the projected time when GCC 14 will land in
> the buildroot, I think we missed the window where a GCC 13 version with
> a preview of these C front end changes would have been beneficial to
> Fedora developers.  It would have also created an awkward issue where
> __GNUC__ is 13, but the compiler behaves in part like GCC 14.  This is
> relevant if it's necessary to suppress (or treat as warnings)
> -Wreturn-mismatch diagnostics, which only exist in GCC 14.
> 
> This brings me to my final point.  We still don't have a solution for
> Vala. I plan to look at valac soon and see what we can do to keep things
> at least compiling with GCC 14 (after re-running valac).
> 
> Thanks,
> Florian
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue

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

Re: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)

[Richard W.M. Jones]

On Thu, Dec 21, 2023 at 06:58:37PM +0100, Florian Weimer wrote:
> * Aoife Moloney:
> 
> > == Detailed Description ==
> > The split between `/bin` and `/sbin` is not useful, and also unused.
> 
> Programs in /usr/bin have their documentation in section 1 of the
> manual, while programs /usr/sbin are documented in section 8.  (In
> general, I deliberately used /usr/bin/ld.so although the manual page was
> already called ld.so(8), without a program of this name existing.)
> 
> When moving programs, should we move the manual pages as well?  Or at
> least add a link so that that section 1 references work?

The manual sections have historical meaning:

  https://en.wikipedia.org/wiki/Man_page#Manual_sections
  eg.
  1 = general commands
  8 = system administration

So unless the tools themselves are changing their purpose or are in
the wrong section now, the manual sections should stay the same.

Rich.

> Is there something we can do to help developers on Fedora systems to
> write portable code (not just shell scripts) after this change is rolled
> out?
> 
> Thanks,
> Florian
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
--
___
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.1.1 rebuild in Rawhide

[Richard W.M. Jones]

On Mon, Dec 18, 2023 at 10:50:11AM +, Richard W.M. Jones wrote:
> On Mon, Dec 18, 2023 at 10:48:18AM +0000, Richard W.M. Jones wrote:
> > On Thu, Dec 14, 2023 at 11:46:58AM +, Richard W.M. Jones wrote:
> > > These are done now, bar waiting for a couple of builds to complete.
> > 
> > ... or so we thought.
> > 
> > It turns out that Jerry James identified a code generation bug on s390x:
> > 
> > https://github.com/ocaml/ocaml/issues/12829
> > 
> > which is fixed upstream in:
> > 
> > https://github.com/ocaml/ocaml/pull/12831
> > 
> > We may need to rebuild either just OCaml or potentially all OCaml
> > packages (in a side tag).  I'll try to get this done today.
> 
> Actually it's all of them since this alters generated code potentially
> in any s390x package.

The second rebuild is now done.

https://bodhi.fedoraproject.org/updates/FEDORA-2023-5a1287b99c

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

Re: Orphaned packages looking for new maintainers

[Richard W.M. Jones]

On Mon, Dec 18, 2023 at 11:20:22AM +0100, Miro Hrončok wrote:
> virtmeorphan   4 weeks ago

I have no special knowledge of this package, but I did read the
article below a few weeks ago about virtme-ng.  In particular
virtme-ng uses virtiofs (instead of 9p) which is a more modern way to
export filesystems into VMs.  We (the virt team) have for a very very
long time recommended people steer clear of 9p, for security,
performance and maintainability reasons.

https://lwn.net/Articles/951313/

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 5.1.1 rebuild in Rawhide

[Richard W.M. Jones]

On Mon, Dec 18, 2023 at 10:48:18AM +, Richard W.M. Jones wrote:
> On Thu, Dec 14, 2023 at 11:46:58AM +0000, Richard W.M. Jones wrote:
> > These are done now, bar waiting for a couple of builds to complete.
> 
> ... or so we thought.
> 
> It turns out that Jerry James identified a code generation bug on s390x:
> 
> https://github.com/ocaml/ocaml/issues/12829
> 
> which is fixed upstream in:
> 
> https://github.com/ocaml/ocaml/pull/12831
> 
> We may need to rebuild either just OCaml or potentially all OCaml
> packages (in a side tag).  I'll try to get this done today.

Actually it's all of them since this alters generated code potentially
in any s390x package.

Rich.

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

Re: OCaml 5.1.1 rebuild in Rawhide

[Richard W.M. Jones]

On Thu, Dec 14, 2023 at 11:46:58AM +, Richard W.M. Jones wrote:
> These are done now, bar waiting for a couple of builds to complete.

... or so we thought.

It turns out that Jerry James identified a code generation bug on s390x:

https://github.com/ocaml/ocaml/issues/12829

which is fixed upstream in:

https://github.com/ocaml/ocaml/pull/12831

We may need to rebuild either just OCaml or potentially all OCaml
packages (in a side tag).  I'll try to get this done today.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: How to clone subpackages during koji build stage

[Richard W.M. Jones]

On Wed, Dec 13, 2023 at 01:50:44PM -0300, Julio Faracco wrote:
> Thanks Fabio!
> 
> I presume the CMakeLists.txt of the project I'm working on needs some rebase.
> But first, I would like to see what is recommended before taking any action.

The recommended action is what Fabio said.

What's the project?

Rich.

> On Wed, Dec 13, 2023 at 1:02 PM Fabio Valentini  wrote:
> >
> > On Wed, Dec 13, 2023 at 4:57 PM Julio Faracco  wrote:
> > >
> > > Hi everybody!
> > >
> > > Koji mocks does not access the internet during the build stage.
> > > What are the recommendations when my project has some content inside
> > > CMake to clone subrepos to compile my code?
> > >
> > > Do you have any guidelines for this? Honestly, I tried to google it,
> > > but I'm not finding something useful or a real example.
> >
> > This situation can be handled by either
> >
> > 1. un-bundling subprojects (i.e. packaging them as separate packages
> > and depending on them for the build), or
> > 2. providing the sources for subprojects as separate tarballs and
> > unpack them where expected during %prep step
> >
> > and usually Option 1 is preferred in Fedora, but it will depend on the
> > exact circumstances and what kinds of subprojects you're dealing with.
> >
> > 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
> 
> 
> 
> -- 
> Julio
> --
> ___
> 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
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 5.1.1 rebuild in Rawhide

[Richard W.M. Jones]

On Wed, Dec 13, 2023 at 10:18:03AM +, Richard W.M. Jones wrote:
> On Mon, Dec 11, 2023 at 10:28:29PM +0000, Richard W.M. Jones wrote:
> > 
> > .. is under way:
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=2239227
> > 
> > Shouldn't take more than a day or two, with any luck!
> > 
> > In terms of the new version, nothing much to see here.  There a three
> > important regressions that are fixed, and one breaking change that is
> > unlikely to be noticed:
> > 
> > https://discuss.ocaml.org/t/ocaml-5-1-1-released/13592
> 
> This is complete.  Some packages failed to build, because of an
> apparent bug in the OCaml toolchain:
> 
> https://github.com/ocaml/ocaml/issues/12820
> 
> These were:
> 
>  - libguestfs
>  - libnbd
> 
> and these which have the above packages as dependencies:
> 
>  - guestfs-tools
>  - nbdkit
>  - virt-v2v
> 
> I'll fix them separately once the above bug has been resolved.

These are done now, bar waiting for a couple of builds to complete.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
--
___
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.1.1 rebuild in Rawhide

[Richard W.M. Jones]

On Mon, Dec 11, 2023 at 10:28:29PM +, Richard W.M. Jones wrote:
> 
> .. is under way:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=2239227
> 
> Shouldn't take more than a day or two, with any luck!
> 
> In terms of the new version, nothing much to see here.  There a three
> important regressions that are fixed, and one breaking change that is
> unlikely to be noticed:
> 
> https://discuss.ocaml.org/t/ocaml-5-1-1-released/13592

This is complete.  Some packages failed to build, because of an
apparent bug in the OCaml toolchain:

https://github.com/ocaml/ocaml/issues/12820

These were:

 - libguestfs
 - libnbd

and these which have the above packages as dependencies:

 - guestfs-tools
 - nbdkit
 - virt-v2v

I'll fix them separately once the above bug has been resolved.

Rich.

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

OCaml 5.1.1 rebuild in Rawhide

[Richard W.M. Jones]

.. is under way:

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

Shouldn't take more than a day or two, with any luck!

In terms of the new version, nothing much to see here.  There a three
important regressions that are fixed, and one breaking change that is
unlikely to be noticed:

https://discuss.ocaml.org/t/ocaml-5-1-1-released/13592

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
--
___
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: goal: booting with an empty /etc

[Richard W.M. Jones]

On Sat, Dec 09, 2023 at 08:03:48AM +, Zbigniew Jędrzejewski-Szmek wrote:
> I'm not entirely sure if you're just doing Friday trolling or if
> you're serious. I'll reply for real, apologies if this was meant as
> a joke.

DJ has been hacking on free software since I was still at school, so
no, he's not trolling.

> On Fri, Dec 08, 2023 at 12:59:22PM -0500, DJ Delorie wrote:
> > Zbigniew Jędrzejewski-Szmek  writes:
> > > There is a long-term goal of moving packaged files out of /etc,
> > 
> > I will note that I'm opposed to this goal as a goal per-se.
> > 
> > If you want an empty directory, "mkdir /etc2" should work for you.
> > 
> > I fear this will end like the /tmp fiasco where one /tmp became many tmp
> > directories, and no consistent rule about which one to use.
> 
> /tmp is generally backed by RAM and does not survive a reboot.

And that's a really bad idea, which I always turn off in any computer
or server I manage.  Limiting /tmp to using RAM + swap and having it
erase at reboot is pointless additional complexity.  This caused us to
go through countless lines of code deciding if a temporary file is
"small" (how small? don't know!) and whether it should live in /tmp or
/var/tmp for people who have to suffer this configuration.

Filesystems already use RAM for caching when necessary, and I want
temporary directories with a controlled lifetime, not "whenever the
power happens to go off".  Plus more typing.

> > > At some point, I think we should make this an explicit goal in Fedora.
> > 
> > Please don't.
> 
> You seem to like the current scheme. But it was designed in the times where
> people did much more manual tweaking of their systems. We now care a lot
> about clean and automatic upgrades. Having to resolve three-way differences
> between a bunch of config files conflicts with that.

People use their systems in different ways.

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

Re: Proven to be sickened

[Richard W.M. Jones]

On Tue, Dec 05, 2023 at 10:35:35AM +, Daniel P. Berrangé wrote:
> On Tue, Dec 05, 2023 at 11:18:57AM +0100, Vít Ondruch wrote:
> 
> [snip]
> 
> > Granted, these are dissimilar to initial Michaels's issue. But how can I be
> > sure that if I touch some of the packages, I won't be told that they were in
> > such state for purpose?
> 
> IMHO all changes should be opened as merge requests in pagure. This gives
> the regular package maintainers a window of opportunity to review the
> change before it is merged. If there's no response from the package
> maintainer after a couple of weeks then a proven packager can go ahead
> and approve the merge request.
> 
> Essentially proven packagers can follow the same workflow as anyone else
> does for contributing to a package that they are not a (co)maintainer of.
> They just need the extra priv of being able to approve their own MR at
> their discretion. Pushing directly to git, bypassing merge requests,
> should not be required in order to achieve what provenpackagers exist
> to do.

This workflow doesn't really work for mass rebuilds / mass maintenance
of OCaml packages (I guess it's similar for other language packages).
We want to be able to rebuild or fix all packages that contain OCaml
code, and we have a bunch of scripts to do that including the push and
build in a side tag.

> At the same time I think it is good to remember that Fedora package
> maintainers should think of themselves as guardians, not owners, and
> thus should expect to receive contributions from others, including
> provenpackagers, doing cleanups to follow Fedora guidelines better.

Yes indeed.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Update on the Modern C initiative

[Richard W.M. Jones]

On Mon, Dec 04, 2023 at 02:28:03PM +0100, Florian Weimer wrote:
> * Richard W. M. Jones:
> 
> > On Sat, Dec 02, 2023 at 09:15:28PM +0000, Richard W.M. Jones wrote:
> >> On Thu, Nov 30, 2023 at 06:09:55PM +0100, Florian Weimer wrote:
> >> > nbdkit   rjones
> >> 
> >> Can you help me to understand the build error in this log?
> >> 
> >> https://gitlab.com/fweimer-rh/fedora-modernc-logs/-/raw/main/logs/n/nbdkit.log?ref_type=heads
> >> 
> >> I'm not exactly sure what / where the error is supposed to be.
> >> 
> >> Possibly it is complaining about this autoconf test, but I don't
> >> understand what's wrong with the cast, since AFAIK making a pointer
> >> "more const" should be fine:
> >> 
> >>   configure:20816: checking if environ is declared in header files
> >>   configure:20833: gcc -c -O2 -flto=auto -ffat-lto-objects -fexceptions -g 
> >> -grecord-gcc-switches -pipe -Wall -Werror=format-security 
> >> -Werror=implicit-function-declaration -Werror=implicit-int 
> >> -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -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 
> >> -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer   conftest.c >&5
> >>   conftest.c: In function 'test':
> >>   conftest.c:62:22: error: initialization of 'const char **' from 
> >> incompatible pointer type 'char **'
> >>  62 |   const char **env = environ;
> >> |  ^~~
> >> 
> >> (source: 
> >> https://gitlab.com/nbdkit/nbdkit/-/blob/380f975bb9a07063f370835c51e1cd248a799485/configure.ac#L327)
> >
> > Fixed upstream here:
> > https://gitlab.com/nbdkit/nbdkit/-/commit/32a9ee6650654469cd591a3ae26842c54f898392
> 
> Thanks.  Could you bring this into rawhide as well?

Building right now ...

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

Rich.

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

Re: Update on the Modern C initiative

[Richard W.M. Jones]

On Sat, Dec 02, 2023 at 09:15:28PM +, Richard W.M. Jones wrote:
> On Thu, Nov 30, 2023 at 06:09:55PM +0100, Florian Weimer wrote:
> > nbdkit   rjones
> 
> Can you help me to understand the build error in this log?
> 
> https://gitlab.com/fweimer-rh/fedora-modernc-logs/-/raw/main/logs/n/nbdkit.log?ref_type=heads
> 
> I'm not exactly sure what / where the error is supposed to be.
> 
> Possibly it is complaining about this autoconf test, but I don't
> understand what's wrong with the cast, since AFAIK making a pointer
> "more const" should be fine:
> 
>   configure:20816: checking if environ is declared in header files
>   configure:20833: gcc -c -O2 -flto=auto -ffat-lto-objects -fexceptions -g 
> -grecord-gcc-switches -pipe -Wall -Werror=format-security 
> -Werror=implicit-function-declaration -Werror=implicit-int 
> -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -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 
> -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer   conftest.c >&5
>   conftest.c: In function 'test':
>   conftest.c:62:22: error: initialization of 'const char **' from 
> incompatible pointer type 'char **'
>  62 |   const char **env = environ;
> |  ^~~
> 
> (source: 
> https://gitlab.com/nbdkit/nbdkit/-/blob/380f975bb9a07063f370835c51e1cd248a799485/configure.ac#L327)

Fixed upstream here:
https://gitlab.com/nbdkit/nbdkit/-/commit/32a9ee6650654469cd591a3ae26842c54f898392

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: Update on the Modern C initiative

[Richard W.M. Jones]

On Thu, Nov 30, 2023 at 06:09:55PM +0100, Florian Weimer wrote:
> nbdkit   rjones

Can you help me to understand the build error in this log?

https://gitlab.com/fweimer-rh/fedora-modernc-logs/-/raw/main/logs/n/nbdkit.log?ref_type=heads

I'm not exactly sure what / where the error is supposed to be.

Possibly it is complaining about this autoconf test, but I don't
understand what's wrong with the cast, since AFAIK making a pointer
"more const" should be fine:

  configure:20816: checking if environ is declared in header files
  configure:20833: gcc -c -O2 -flto=auto -ffat-lto-objects -fexceptions -g 
-grecord-gcc-switches -pipe -Wall -Werror=format-security 
-Werror=implicit-function-declaration -Werror=implicit-int 
-Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -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 
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer   conftest.c >&5
  conftest.c: In function 'test':
  conftest.c:62:22: error: initialization of 'const char **' from incompatible 
pointer type 'char **'
 62 |   const char **env = environ;
|  ^~~

(source: 
https://gitlab.com/nbdkit/nbdkit/-/blob/380f975bb9a07063f370835c51e1cd248a799485/configure.ac#L327)

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
--
___
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