Re: packaging of nix

[Elliott Sales de Andrade]

On Fri, Mar 1, 2024 at 12:52 PM Pratham Patel  wrote:
>
> An update on the efforts:
>
> Running nix commands like `nix run nixpkgs#hello` works. And that's all that 
> works from what I've been able to test. Installing Nix software like 
> `home-manager` fails. You can actually do a `nix run home-manager/master -- 
> init --switch` and you will get a "barebones" initialisation of home-manager 
> activated but as I will discuss later, variables related to activation don't 
> get sourced and it is rendered useless. However, I cannot build my 
> home-manager configuration.
>
> This issue stems from improper initialization of several things. What the 
> Determinate Systems' installer and the official Nix installer do is fetch a 
> tarball from [here](https://releases.nixos.org/?prefix=nix/), extract it in 
> `/nix/store` and add/modify the shell rcs (for bash, fish and zsh) in `/etc` 
> to source a few files from the nix store that contain environment variables 
> like `NIX_PATH` which is crucial for nix to build anything more than the 
> `hello` package.

As part of your package, you can achieve similar things by dropping a
script into `/etc/profile.d`. For example, conda (the
formerly-primarily Python package manager) installs a conda.{csh,sh}
script there that sets some variables for paths and shell functions to
match. Or flatpak, that installs flatpak.sh that adds XDG_DATA_DIRS.

>
> As such, I'm looking into 
> [`nix-portable`](https://github.com/DavHau/nix-portable) which seems to solve 
> this exact issue for us. Hopefully, I am able to dedicate some time and test 
> it out by the end of next week.
>
> Pratham Patel

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

Re: Need help with incompatible pointer types on i686

[Elliott Sales de Andrade]

On Thu, Feb 15, 2024 at 11:39 PM Orion Poplawski  wrote:
>
> We're hitting this with h5py on i686:
>
> /builddir/build/BUILD/h5py-3.10.0/serial/h5py/defs.c: In function
> ‘__pyx_f_4h5py_4defs_H5Dread_chunk’:
> /builddir/build/BUILD/h5py-3.10.0/serial/h5py/defs.c:14922:85: error:
> passing argument 4 of ‘H5Dread_chunk’ from incompatible pointer type
> [-Wincompatible-pointer-types]
> 14922 | __pyx_v_r = H5Dread_chunk(__pyx_v_dset_id,
> __pyx_v_dxpl_id, __pyx_v_offset, __pyx_v_filters, __pyx_v_buf);
>|
>  ^~~
>|
>  |
>|
>  __pyx_t_5numpy_uint32_t * {aka long unsigned int *}
> In file included from /usr/include/hdf5.h:25,
>   from
> /builddir/build/BUILD/h5py-3.10.0/serial/h5py/api_compat.h:27,
>   from
> /builddir/build/BUILD/h5py-3.10.0/serial/h5py/defs.c:1246:
> /usr/include/H5Dpublic.h:1003:92: note: expected ‘uint32_t *’ {aka
> ‘unsigned int *’} but argument is of type ‘__pyx_t_5numpy_uint32_t *’
> {aka ‘long unsigned int *’}
>   1003 | H5_DLL herr_t H5Dread_chunk(hid_t dset_id, hid_t dxpl_id, const
> hsize_t *offset, uint32_t *filters,
>|
>   ~~^~~
> /builddir/build/BUILD/h5py-3.10.0/serial/h5py/defs.c: In function
> ‘__pyx_f_4h5py_4defs_H5Pget_driver_info’:
> /builddir/build/BUILD/h5py-3.10.0/serial/h5py/defs.c:31935:13: warning:
> assignment discards ‘const’ qualifier from pointer target type
> [-Wdiscarded-qualifiers]
> 31935 |   __pyx_v_r = H5Pget_driver_info(__pyx_v_plist_id);
>| ^
>
>
> It seems that numpy is defining a uint32_t type as long unsigned int on
> i686, while glibc(?) is defining it as unsigned int.

Yes, looking at NumPy's header [1], it appears to check `long` first,
then `long long`, then `int`, then `short`, and assigns the first one
that matches to the matching bit-length. So it should pick unsigned
long for npy_uint32 before unsigned int if they are both 4 bytes wide.

>  Now what puzzles
> me a little is that on i686 aren't these both 4-byte integers and no not
> incompatible at all?

Yes, I think they are the same size, as demonstrated on a 32-bit mock:
```
#include 
#include 
int main(void) {
printf("npy_uint32: %u\nunsigned int: %u\nunsigned long:
%u\nunsigned long long: %u\n",
   sizeof(npy_uint32), sizeof(unsigned int), sizeof(unsigned
long), sizeof(unsigned long long));

return 0;
}
```
prints out:
```
npy_uint32: 4
unsigned int: 4
unsigned long: 4
unsigned long long: 8
```

> What should be done here?
>

I guess that depends on how glibc sets things up, but perhaps it would
work better if NumPy checked from smallest to largest as defined in C
(short -> int -> long -> long long)?

[1] 
https://github.com/numpy/numpy/blob/308273e94bcf49980be9d5ded2b0ff5b4dd3a897/numpy/_core/include/numpy/npy_common.h#L488
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Help packaging go with its dependencies

[Elliott Sales de Andrade]

On Fri, Feb 2, 2024 at 4:03 PM Priscila Gutierres  wrote:
>
> I'm trying to package kubectl for Fedora, but I'm having a bad time with some 
> dependencies.
> I created the specfile using go2rpm, and I'm using auto dependencies:
> https://pastebin.com/fmvttDBt
>
> %generate_buildrequires
> %go_generate_buildrequires
>
> But it is blaming that some dependencies are missing:
>
> Failed to resolve the transaction:
> Package "go-rpm-macros-3.3.1-3.fc40.x86_64" is already installed.
> No match for argument: golang(github.com/chai2010/gettext-go/gettext)

It appears you are attempting to package a very old version of
kubectl; this import path was removed 1.5 years ago:
https://github.com/kubernetes/kubectl/commit/4bf64b98777b846942aacf6e787cec7764c5b576

> No match for argument: golang(github.com/russross/blackfriday)
> No match for argument: golang(k8s.io/kubectl/pkg/generated)
>
> I could find, for example, golang-github-chai2010-gettext:
> https://src.fedoraproject.org/rpms/golang-github-chai2010-gettext
> But it isn't found when trying to create a mock package.
>
> Can someone please help me?
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Need assistance to package MaterialX

[Elliott Sales de Andrade]

On Sat, Jan 27, 2024 at 1:58 AM Luya Tshimbalanga
 wrote:
>
> Hello team,
>
> I attempt to build MaterialX, an optional requirement for Blender 4.x but hit 
> an interesting issue with RPATH (partially resolved).
> An example on 
> https://download.copr.fedorainfracloud.org/results/@designsuite/blender/fedora-39-x86_64/06966310-materialx/builder-live.log.gz
> shows the path on /usr/ rather than say /usr/share/materialx

This doesn't have anything to do with RPATH. Upstream's build is just
broken for FHS layout.

For example, the "root-level documents" are installed here:
https://github.com/AcademySoftwareFoundation/MaterialX/blob/2f169d152f295114efe982ab06a74bfd930bb540/CMakeLists.txt#L354-L379
This just installs documentation to ".", which is /usr.

And the same for resources:
https://github.com/AcademySoftwareFoundation/MaterialX/blob/2f169d152f295114efe982ab06a74bfd930bb540/resources/CMakeLists.txt#L3
which doesn't add datadir, but just goes to top-level "resources".

This should probably be reported upstream.

> The build is located on 
> https://copr.fedorainfracloud.org/coprs/g/designsuite/blender/build/6966310/ 
> including the spec file.
>
> Helps welcome!
>
> Luya

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

Re: Fedora Linux 40 Change Proposal Submission Deadlines have now passed

[Elliott Sales de Andrade]

On Thu, Jan 18, 2024 at 4:33 PM Aoife Moloney  wrote:

> Hi all,
>
> Please note that we are now past all change proposal submission deadlines.
> Thank you to all who have submitted changes to Fedora Linux 40. If you have
> changes accepted, please note your changes must be in a 'Testable
> '
> state by *6th Feb 2024*. Changes currently in the early feedback stage,
> i.e the part of the process where the change is announced for broad
> visibility to be discussed and iterated on where necessary before
> submission to FESCo for voting, are the following:
>
>- Changes/ArmMinimalImageOSBuild
>
>- Changes/DefaultBpfman
>
>- Changes/Fedora IoT Bootable Container
>
>- Changes/Fedora IoT Unified Core
>
>- Changes/GNUToolchainF40
>
>- Changes/IBus 1.5.30
>
>- Changes/ibus-anthy 1.5.16
>
>- Changes/Optimized Binaries for the AMD64 Architecture
>
> 
>- Changes/PytorchRelese
>
>
>
Is it possible to fix the typo in the Wiki URL?


>
>- Changes/Replace iotop with iotop-c
>
>- Changes/ROCm6Release
>
>
> View the Releases/40/ChangeSet
>  wiki page for the
> current set of accepted changes, and the Fedora Linux 40 schedule
>  for
> other key milestones and dates for this release.
>
> Kindest regards,
> Aoife
>
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Error when patching test-requirements inside pymemcache source

[Elliott Sales de Andrade]

Hi Priscila,

On Sat, Oct 14, 2023 at 6:48 PM Priscila Gutierres  wrote:
>
> Hello,
>
> I'm trying to patch pymemcache/test-requirements.txt to unpin all the build 
> requirements.
>
> I created this patch using git format-patch: 
> https://paste.centos.org/view/46800819

This patch is wrong. The file is at the top of the source directory,
not `pymemcache`/test-requirements.txt`.

> But when trying to create a mockbuild, it fails to apply: 
> https://paste.centos.org/view/b1f404c8
>
> Checking patch pymemcache/test-requirements.txt...
> error: pymemcache/test-requirements.txt: does not exist in index
>
> But it exists: https://paste.centos.org/view/a239ec34
>

It does not, at least as listed in the patch. You are checking a
different directory than the patch.

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

Re: Need help with conda package - launcher script

[Elliott Sales de Andrade]

On Sun, Oct 8, 2023 at 10:20 AM Orion Poplawski  wrote:
>
> With the update to conda 23.5.2 and using the pyproject macros, the
> conda package is no longer producing the /usr/bin/conda-env launcher
> script which is causing problems.

What problems specifically?

> I don't know how I can get that back with the current build system.  Any
> help would be greatly appreciated.

Upstream appears to have changed to hatch, and there's no entry for a
conda-env script [1], so it's up to them, and is either intentional or
an oversight.
And given [2], it doesn't appear that `conda-env` has much life left,
so it seems intentional.
But in any case, it seems like something you should confirm with upstream.

> Thanks.
>
> --
> Orion Poplawski

[1] 
https://github.com/conda/conda/commit/0a255799567ba28f421a1fe7309c5336cbcdbf0a#diff-50c86b7ed8ac2cf95bd48334961bf0530cdc77b5a56f852c5c61b89d735fd711R50-R51
[2] 
https://github.com/conda/conda/commit/da31c933fec50e7242f3ecb4b90e586bd3861a2b
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Blender 3.6.2 failure to build

[Elliott Sales de Andrade]

Hi,

On Thu, Sep 14, 2023 at 11:12 PM Luya Tshimbalanga
 wrote:
>
> Hello everyone,
>
> Blender 3.6.2 [0] failed to build on both Rawhide and incoming Fedora 39 [1] 
> but succeeded on Fedora 38 and lower. It seems the issues related to python 
> 3.12 yet again despite the applied patches. Could some investigate please?
> Thanks.

I don't see any reference to Python 3.12 there. The error is:

In file included from /usr/include/epoxy/egl.h:46,
 from
/builddir/build/BUILD/blender-3.6.2/intern/ghost/intern/GHOST_ContextEGL.hh:13,
 from
/builddir/build/BUILD/blender-3.6.2/intern/ghost/intern/GHOST_XrGraphicsBinding.cc:12:
/builddir/build/BUILD/blender-3.6.2/intern/ghost/intern/GHOST_XrGraphicsBinding.cc:
In member function ‘virtual void
GHOST_XrGraphicsBindingOpenGL::initFromGhostContext(GHOST_Context&)’:
/builddir/build/BUILD/blender-3.6.2/intern/ghost/intern/GHOST_XrGraphicsBinding.cc:154:42:
error: invalid conversion from ‘void (* (*)(const char*))()’ to
‘PFN_xrEglGetProcAddressMNDX’ {aka ‘void* (*)(const char*)’}
[-fpermissive]
  154 | oxr_binding.egl.getProcAddress = eglGetProcAddress;
  |  ^
  |  |
  |  void (* (*)(const char*))()

which looks like
https://projects.blender.org/blender/blender/issues/111820 Try
applying the linked patch in
https://projects.blender.org/blender/blender/commit/8159bd90e527552ccfe27db5f2c5a91d64855e9e

> Reference
> -
> [0] https://src.fedoraproject.org/rpms/blender
> [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=106208127

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

Re: lzma-sdk and undefined references

[Elliott Sales de Andrade]

On Sat, Aug 26, 2023 at 6:30 AM Julian Sikorski  wrote:
>
> Hello,
>
> now that lzma-sdk in Fedora rawhide is no longer ancient, I tried using
> it with mame. Unfortunately, I got a number of undefined references when
> linking:
>
> Is it a problem with lzma-sdk not shipping those? Or is mame using
> private functions? Thanks for the feedback.
>

Looking at the shared library, it has for example:

 sh-5.2# objdump -T /usr/lib64/liblzmasdk.so | grep
MtCoder_Destruct
  D  *UND*    BaseMtCoder_Destruct

The *UND* indicates that the symbol is referenced, but not defined.
This does not seem intended.

I'm not sure if this is the reason, but it appears that the lzma-sdk
build is incorrect. Looking at the log from the latest build on
x86_64, we see:

+ CFLAGS='-O2 -flto=auto -ffat-lto-objects -fexceptions -g
-grecord-gcc-switches -pipe -Wall -Werror=format-security
-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 '
+ LDFLAGS='-Wl,-z,relro -Wl,--as-needed  -Wl,-z,now
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -Wl,--build-id=sha1
-specs=/usr/lib/rpm/redhat/redhat-package-notes '
+ make -f makefile.gcc clean all 'CXXFLAGS_EXTRA=-O2 -flto=auto
-ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall
-Werror=format-security -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 ' 'CFLAGS_WARN=-O2 -flto=auto
-ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall
-Werror=format-security -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 ' 'LDFLAGS_STATIC_2=-O2 -flto=auto
-ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall
-Werror=format-security -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 '

but then the final linkage has:

g++ -o liblzmasdk.so.22.01.0 -shared -Wl,-soname=liblzmasdk.so.22
-DNDEBUG -O2 -flto=auto -ffat-lto-objects -fexceptions -g
-grecord-gcc-switches -pipe -Wall -Werror=format-security
-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_o/7zCrc.o _o/7zCrcOpt.o _o/Alloc.o
_o/Bra86.o _o/CpuArch.o _o/LzFind.o _o/LzmaDec.o _o/LzmaEnc.o
_o/Lzma2Dec.o _o/Lzma2Enc.o _o/Lzma86Dec.o _o/Lzma86Enc.o
_o/LzFindMt.o _o/LzFindOpt.o _o/Synchronization.o _o/Threads.o
_o/FileDir.o _o/FileFind.o _o/FileName.o _o/MyWindows.o _o/TimeUtils.o
 _o/CommandLineParser.o _o/CRC.o _o/CrcReg.o _o/IntToString.o
_o/LzFindPrepare.o _o/MyString.o _o/MyVector.o _o/NewHandler.o
_o/StringConvert.o _o/StringToInt.o _o/UTFConvert.o  _o/FileIO.o
_o/PropVariant.o _o/System.o _o/SystemInfo.o  _o/LzmaDecoder.o
_o/LzmaEncoder.o _o/LzmaRegister.o  _o/CreateCoder.o _o/CWrappers.o
_o/FileStreams.o _o/FilterCoder.o _o/MethodProps.o _o/StreamObjects.o
_o/StreamUtils.o  _o/BenchCon.o _o/ConsoleClose.o  _o/LzmaAlone.o
_o/Bench.o   -lpthread -ldl

As you can see, none of the LDFLAGS are passed to the linker, only the CFLAGS.

> Best regards,
> Julian

[1] https://koji.fedoraproject.org/koji/buildinfo?buildID=2278764

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

Re: Releasing package updates in multiple Fedora releases

[Elliott Sales de Andrade]

On Sun, Jun 18, 2023 at 5:17 AM Mattia Verga via devel
 wrote:
>
> For the 99% of packages I maintain I usually perform the same workflow
> when updating them:
>
> 1. Update spec and source in Rawhide
> 2. commit and push
> 3. fedpkg build
> 4. fedpkg switch-branch f*
> 5. git merge rawhide
> 6. push and fedpkg build
>
> And repeat 4-5-6 for every f*/epel* branches where I want to push the
> update.
>

With fbrnch, you can run `fbrnch parallel --all-fedora`, which will do
steps 2.5 (i.e., the push part) through 6 for all Fedora branches (in
parallel), and wait for all builds to finish, then produce updates for
all of them except rawhide.

> This is quite boring and time wasting... is there a more efficient way
> to use my packaging time? Do you think fedpkg can be enhanced to have a
> single command which makes 4-5-6 to all specified branches?
>
> Mattia
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Circular import issue in F37

[Elliott Sales de Andrade]

On Mon, Jun 5, 2023 at 6:45 AM Sandro  wrote:
>
> Hi again,
>
> I'm trying to understand why I'm getting a circular import error running
> tests only in F37 [1].
>
> It's an easy fix adding an empty __init__.py in %prep, but why are F38
> and rawhide buildroots happy not having that file, while F37 complaints?


Looking at the F37 log, you can see that only a few files were copied:

  creating build/lib/palettable
  copying palettable/utils.py -> build/lib/palettable
  copying palettable/palette.py -> build/lib/palettable
  copying palettable/__init__.py -> build/lib/palettable

with no trace of something named cmocean. And then looking at F38, you see:

  /usr/lib/python3.11/site-packages/setuptools/command/build_py.py:202:
SetuptoolsDeprecationWarning: Installing 'palettable.cmocean' as
data is deprecated, please list it in `packages`.

  
  # Package would be ignored #
  
  Python recognizes 'palettable.cmocean' as an importable package,
  but it is not listed in the `packages` configuration of setuptools.

  'palettable.cmocean' has been automatically added to the distribution only
  because it may contain data files, but this behavior is likely to change
  in future versions of setuptools (and therefore is considered deprecated).

  Please make sure that 'palettable.cmocean' is included as a
package by using
  the `packages` configuration field or the proper discovery methods
  (for example by using `find_namespace_packages(...)`/`find_namespace:`
  instead of `find_packages(...)`/`find:`).

  You can read more about "package discovery" and "data files" on setuptools
  documentation page.

So you can see that the newer versions are happily working, but only
through some bit of compatibility concerns. It may eventually break
there as well.

>
> The versions of the involved packages only differ in minor / patch
> versions between F37 and F38, if at all. With python-setuptools-wheel
> being the only package with a different major version.
>
> python3-devel 3.11.3-2.fc37 3.11.3-2.fc38
> python3-pytest 7.1.3-2.fc37 7.2.2-1.fc38
> pyproject-rpm-macros 1.8.0-1.fc37 1.8.0-1.fc38
> python-rpm-macros 3.11-5.fc37 3.11-10.fc38
> python-pip-wheel 22.2.2-3.fc37 22.3.1-2.fc38
> python-setuptools-wheel 62.6.0-3.fc37 65.5.1-2.fc38
>
>
> [1] https://copr.fedorainfracloud.org/coprs/gui1ty/neuro-sig/build/6002232/
>
> Cheers,
> --
> Sandro
> FAS: gui1ty
> IRC: Penguinpee
> Elsewhere: [Pp]enguinpee
> ___
> python-devel mailing list -- python-devel@lists.fedoraproject.org
> To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue



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

Re: Old stalled bodhi updates

[Elliott Sales de Andrade]

On Tue, May 30, 2023 at 4:16 PM Adam Williamson 
wrote:

> On Tue, 2023-05-30 at 21:52 +0200, Mikel Olasagasti wrote:
> > Hi all,
> >
> > There are currently 157 updates in testing or pending status in Bodhi
> > that were created before 2023:
> >
> >
> https://bodhi.fedoraproject.org/updates/?search=_before=2023=pending=testing=1
> >
> > There are 7 Fedora updates, 6 for Fedora-37 and one in
> > pending->testing status for Fedora-35. The rest are for EPEL-7 and
> > EPEL-8, mostly from before 2022, so I guess as those releases are
> > still active the updates are not auto-closed.
>
> Of the non-dummy F37 ones, two are stuck because they failed CI tests
> that the package has marked as gating (required):
>
> https://bodhi.fedoraproject.org/updates/FEDORA-2022-bf8feea173
> https://bodhi.fedoraproject.org/updates/FEDORA-2022-826bb5fc42
>
> in both cases, they failed the fedora-ci.koji-build.tier0.functional
> test, which is from Fedora CI. In both cases the failure is old enough
> that the logs are no longer available. We could hit the Re-Trigger
> Tests button and see if they pass on a retry, or we could waive the
> failures. CCing the maintainers (bcl and hadess).
>
> https://bodhi.fedoraproject.org/updates/FEDORA-2022-2b17e1e469 is stuck
> because it was ejected from its initial push to testing,
> which means the 7 day push to stable timer never really kicks in
> (it needs to be *in testing* for seven days). It was supposedly left
> out of the push because it didn't have the right tag. It does seem to
> have the right tag now, at least, so I resubmitted it for testing. If
> that works, it should then go stable a week later.
>
>
This failed (again) not because of missing tags, but because it appears to
be in the f37-signing-pending tag and hasn't been signed properly. Or it
was and never moved to the next stage of tags. I'm not sure of the
lifecycle of those.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Build system clocks?

[Elliott Sales de Andrade]

On Sun, May 7, 2023 at 4:59 PM Chris Adams  wrote:

> Once upon a time, Kevin Kofler  said:
> > Chris Adams wrote:
> > > I updated the source of a package of mine last night.  The upstream is
> > > on Github, and I use the %forgemeta macro for an easy spec file.  When
> I
> > > tried to run "fedpkg build" though, it failed - the build system
> > > rejected the build because it was expecting an SRPM with a release
> > > string including 20230507, but instead got one with 20230506.
> >
> > Could it be that you built the package over midnight UTC, so the SRPM
> was
> > still built with 20230506, but when the build happened, it was already
> > 20230507?
>
> It wasn't that, I tried it several times.  Also, the forge macro is
> using the timestamp of the source file, not the wall clock (so the
> system clock being wrong wouldn't have caused it either).
>
>
It uses the timestamp of the source file, but are those timestamps the
same? When you download from the forge, the timestamp on the file will be
the time that you downloaded it. When you upload to the lookaside cache,
the timestamp will be for when it was put there, but your local file has
not changed. When fedpkg or koji download from the lookaside cache, it will
copy the timestamp from it for reproducibility.

However, if the file already exists, fedpkg won't touch it. I suspect if
you delete the tarball and have fedpkg download it again, everything will
appear consistent again.

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

Re: Test upgrades from F37 to F38 - it will take you just a minute

[Elliott Sales de Andrade]

Hi Zbyszek,

On Thu, Feb 23, 2023 at 1:55 PM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> On Wed, Feb 22, 2023 at 09:34:14AM -0700, Nathanael D. Noblet wrote:
> > On Wed, 2023-02-22 at 10:30 +0100, Miroslav Suchý wrote:
> > > dnf --releasever=38 --setopt=module_platform_id=platform:f38 \
> > >  --enablerepo=updates-testing \
> > >  $(rpm -q fedora-repos-modular >/dev/null && echo --
> > > enablerepo=updates-testing-modular) \
> > >  --assumeno distro-sync
> >
> > I got
> >
> > Error:
> >  Problem: package msv-xsdlib-1:2013.6.1-19.fc33.noarch requires
> > mvn(relaxngDatatype:relaxngDatatype), but none of the providers can be
> > installed
> >   - jaxb-relaxng-datatype-2.3.5-7.fc37.noarch does not belong to a
> > distupgrade repository
>
> Once msv-xsdlib is removed, jaxb-relaxng-datatype should update.
>
> >   - problem with installed package msv-xsdlib-1:2013.6.1-19.fc33.noarch
> > (try to add '--skip-broken' to skip uninstallable packages)
>
> I'll add this one to fedora-obsolete-packages.
>
>
It looks like you've only added the main package msv [0]. However, that
package doesn't exist as a binary rpm, the srpm only produces msv-*
subpackages [1]. And obsoleting the main package won't obsolete the
subpackages, so this conflict is not fixed yet. I'm not sure if any of the
other msv-* subpackages should also be obsoleted or just msv-xsdlib.


> > I don't know why those are installed (I don't recognize the packages
> > and they aren't dependencies of anything I know I need) and just
> > removed them and everything was good after that.
>
> Zbyszek
>

[0]
https://src.fedoraproject.org/rpms/fedora-obsolete-packages/c/84990c998a074df88521ee48160fce1fd8d5cc9d?branch=rawhide
[1] https://koji.fedoraproject.org/koji/buildinfo?buildID=1558554

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

Re: Should python-mysql be retired in Fedora and EPEL?

[Elliott Sales de Andrade]

On Thu, Feb 9, 2023 at 3:40 PM Michel Alexandre Salim <
sali...@fedoraproject.org> wrote:

> Dear fellow Fedorans,
>
> It seems that python-mysqlclient will now transparently upgrade python-
> mysql since 2.1.1-2 (for Fedora):
>
> https://src.fedoraproject.org/rpms/python-mysqlclient/c/1da9400c1c9c8eb8b044f6976e1a07f06226ed3e?branch=rawhide
> and 1.4.6-6 (EPEL 8)
>
> https://src.fedoraproject.org/rpms/python-mysqlclient/c/cc24faae44f40898ba87e93f9dfefbc9a7fb09e1?branch=epel8
>
> (python-mysql was never in EPEL9)
>
> The two upstreams are the same (python-mysql points to
> https://github.com/PyMySQL/mysqlclient-python but that just redirects
> to https://github.com/PyMySQL/mysqlclient)
>
> However it seems that python-mysql itself is not retired -- should it?
> Seems like there's no release in which trying to install it won't just
> install python-mysqlclient instead anyway.
>

Yes, that was the plan. See
https://bugzilla.redhat.com/show_bug.cgi?id=1929101

>
> The maintainers don't seem to overlap:
> - python-mysql maintained by mschorm and hobbes1069
> - python-mysqlclient maintained by fab
>
> (the changes to make mysqlclient obsolete mysql are made by non-
> maintainers)
>
> Best regards,
>
> --
> Michel Alexandre Salim
> identities:
> https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2
>

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

Re: Packaging portmidi versions: devel conflicts OK?

[Elliott Sales de Andrade]

On Sat, Mar 4, 2023 at 8:13 AM Michael J Gruber 
wrote:

> > Il 03/03/23 19:00, Michael J Gruber ha scritto:
> > What about:
> >
> > - create a compat-portmidi0 package and move current portmidi there
> > (bonus: mark it as deprecated)
> > - change frescobaldi to require the compat package until a fix is
> available
> > - update current portmidi package to v2
>
> That is possible in the long term, anyway. But it takes time unless you do
> this on released Fedoras, too.
>

Compatibility packages do not get a "compat-" prefix any more; they only
get a version suffix. The old portmidi could be portmidi217 (to match the
old versioning) or possibly portmidi0 (to match the soversion). It's also
preferred (but I'm not sure that it's written down or is just a discussion
within the FPC right now) that the un-suffixed version is the latest one.
https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#multiple


> > BTW, this is not the first time such a discussion arise and I think
> > FESCo / Packaging Guidelines must provide a definitive answer for this.
>
> Thanks to Sergio I know a precedent know. I'll take another look at pm2 to
> see if can somehow avoid the conflicts without creating hardships for
> depending packages, and otherwise go for the middleground plan which will
> require a review for te "new" package in any case.
>

Compatibility packages do not need a review.
https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#_package_review_process

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

Re: Package Tutorial bug - missing BuildRequires gcc

[Elliott Sales de Andrade]

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

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

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

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

Heads-up: xeus 3.0.3 coming to Rawhide with .so version bump

[Elliott Sales de Andrade]

In one week (2022-01-15), or slightly later, I plan to build xeus 3.0.3 for
Rawhide.

This update will bump the .so version from 5 to 8, and xeus remains a leaf
package AFAIK, so there should be no impact to other packages.

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

Re: Is there convenient way to setup Fedora compilation flags outside of the RPM build?

[Elliott Sales de Andrade]

On Fri, Dec 23, 2022 at 1:21 PM Vít Ondruch  wrote:
>
> Working with upstream on one issue [1], it seems that the culprit is in
> the Fedora compiler options. Is there some convenient way to set them
> up? Of course I can copy them from log, or somehow put together from the
> RPM macros, but I'd appreciate if there was some easier way. Can we e.g.
> distribute some script, which would set them up, as part or some RPM?
>

Now that we have the `set_build_flags` macro, it's somewhat
straightforward to do:

$ rpm -E '%set_build_flags'
  CFLAGS="${CFLAGS:--O2 -flto=auto -ffat-lto-objects -fexceptions -g
-grecord-gcc-switches -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
 -m64  -mtune=generic -fasynchronous-unwind-tables
-fstack-clash-protection -fcf-protection}" ; export CFLAGS ;
  CXXFLAGS="${CXXFLAGS:--O2 -flto=auto -ffat-lto-objects -fexceptions
-g -grecord-gcc-switches -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
 -m64  -mtune=generic -fasynchronous-unwind-tables
-fstack-clash-protection -fcf-protection}" ; export CXXFLAGS ;
  FFLAGS="${FFLAGS:--O2 -flto=auto -ffat-lto-objects -fexceptions -g
-grecord-gcc-switches -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
 -m64  -mtune=generic -fasynchronous-unwind-tables
-fstack-clash-protection -fcf-protection
-I/usr/lib64/gfortran/modules}" ; export FFLAGS ;
  FCFLAGS="${FCFLAGS:--O2 -flto=auto -ffat-lto-objects -fexceptions -g
-grecord-gcc-switches -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
 -m64  -mtune=generic -fasynchronous-unwind-tables
-fstack-clash-protection -fcf-protection
-I/usr/lib64/gfortran/modules}" ; export FCFLAGS ;
  LDFLAGS="${LDFLAGS:--Wl,-z,relro -Wl,--as-needed  -Wl,-z,now
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -Wl,--build-id=sha1 }"
; export LDFLAGS ;
  LT_SYS_LIBRARY_PATH="${LT_SYS_LIBRARY_PATH:-/usr/lib64:}" ; export
LT_SYS_LIBRARY_PATH ;
  CC="${CC:-gcc}" ; export CC ;
  CXX="${CXX:-g++}" ; export CXX

So you can do
$ eval `rpm -E '%set_build_flags'`
in a script to set the flags that RPM uses.

>
> Vít
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: GSSDP and GUPnP 1.6 coming to Rawhide

[Elliott Sales de Andrade]

On Mon, Nov 21, 2022 at 2:04 PM David King  wrote:
>
> The 1.6 series of both GSSDP and GUPnP was released a while ago, and the
> 1.6.2 releases contain an important fix for Rygel (which itself depends
> on the 1.6 series in the latest version):
>
> https://discourse.gnome.org/t/important-gssdp-gupnp-1-6-2/12394
>
> As these versions bring new sonames, I have built them in a side tag for
> Rawhide, and plan to merge that in a week or so. I have already built
> Rygel and gupnp-tools in the side tag, but there are several other
> packages which depend on gupnp and gssdp, at least those below:
>

The biggest change between 1.4 and 1.6 is the port to libsoup3. Should
this be coordinated with those Changes?

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

Re: pathfix.py will be removed from Python 3.12

[Elliott Sales de Andrade]

On Thu, Oct 27, 2022 at 5:51 AM Miro Hrončok  wrote:
>
> On 26. 10. 22 23:19, Elliott Sales de Andrade wrote:
> > This list is not sorted, which makes it difficult to scan. Please also
> > provide the maintainers-by-package list that is usually sent for
> > changes that affect many packages.
>
> Packages by maintainer:

It seems I don't have anything to worry about in my packages, but
thanks for the list anyway.

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

Re: pathfix.py will be removed from Python 3.12

[Elliott Sales de Andrade]

On Wed, Oct 26, 2022 at 6:41 AM Lumír Balhar  wrote:
>
> Hello.
>
> Since Python 2.0 (1994), Python provided a useful tool pathfix.py that
> we use in Python RPM macros for fixing shebangs of Python modules and
> some RPM packages use it as well directly in their specfiles for similar
> purposes. The script will no longer be part of CPython source code and
> python3-devel RPM package. Because we think it's useful, we have decided
> to create a new upstream project for it
> (https://github.com/fedora-python/pathfix) on Github and include it in
> the python3-rpm-macros package. The change means the script will move
> from /usr/bin/pathfix.py to /usr/lib/rpm/redhat/pathfix.py.
>
> For users of %py_shebang_fix and %py3_shebang_fix no action is needed.
> The macros will soon use the new location of the tool.
>
> If you use the tool directly in your specfile a change is needed before
> Python 3.12 become the main one in Fedora 38. We have a list of affected
> packages and will open PRs for them soon.
>
> Packages requiring /usr/bin/pathfix.py:
>
> $ repoquery -q --repo=rawhide{,-source} --whatrequires /usr/bin/pathfix.py
> Mayavi-0:4.8.1-1.fc38.src
> PySolFC-0:2.18.0-1.fc38.src
> TeXmacs-0:2.1.2-2.fc38.src
> autodownloader-0:0.5.0-6.fc37.src
> cp2k-0:9.1-3.fc37.src
> dblatex-0:0.3.12-7.fc37.src
> diskimage-builder-0:3.20.1-2.fc37.src
> dnsperf-0:2.9.0-3.fc37.src
> gimp-layer-via-copy-cut-0:1.6-22.fc37.src
> gimp-resynthesizer-0:2.0.3-9.20190428gitadfa25a.fc37.src
> global-0:6.6.5-7.fc38.src
> gtkpod-0:2.1.5-22.fc38.src
> guitarix-0:0.44.1-1.fc37.src
> kernel-tools-0:6.1.0-0.rc2.git0.1.fc38.src
> koan-0:3.0.1-4.fc37.src
> mediawiki-0:1.38.2-1.fc38.src
> monsterz-0:0.7.1-31.fc37.src
> new-session-manager-0:1.3.2-7.fc37.src
> noggin-0:1.6.1-4.fc38.src
> nut-0:2.8.0-5.fc38.src
> nx-libs-0:3.5.99.26-5.fc37.src
> octave-miscellaneous-0:1.3.0-10.fc37.src
> pcsc-lite-0:1.9.9-1.fc38.src
> percona-xtrabackup-0:8.0.25_17-1.fc35.src
> pynag-0:1.1.2-11.fc37.src
> python-confluent-kafka-0:1.6.1-1.fc38.src
> python-cram-0:0.7-13.fc37.src
> python-pyside2-1:5.15.2.1-7.fc37.src
> rabbitvcs-0:0.18-8.fc37.src
> roca-detect-0:1.2.12-21.fc37.src
> scipy-0:1.8.1-6.fc37.src
> swift-lang-0:5.7-3.fc38.src
> syslog-ng-0:3.37.1-1.fc38.src
> systemtap-0:4.8~pre16650659g6a096a7d-1.fc38.src
> wine-mono-0:7.3.0-2.fc37.src
>
> specfiles containing "pathfix.py":
>
> ceph.spec
> blktrace.spec
> aws.spec
> avogadro2-libs.spec
> cobbler.spec
> crawl.spec
> partio.spec
> dblatex.spec
> dnsperf.spec
> diskimage-builder.spec
> dlib.spec
> cp2k.spec
> fio.spec
> future.spec
> fedora-review.spec
> fedora-easy-karma.spec
> GConf2.spec
> gimp-layer-via-copy-cut.spec
> gimp-resynthesizer.spec
> llvm10.spec
> global.spec
> gnome-weather.spec
> clang10.spec
> gtkpod.spec
> netbox.spec
> htop.spec
> guitarix.spec
> gtk2.spec
> kernel-tools.spec
> kernel.spec
> monsterz.spec
> intel-cm-compiler.spec
> koan.spec
> libabigail.spec
> libevdev.spec
> libevent.spec
> libinput.spec
> libsbml.spec
> libtdb.spec
> Mayavi.spec
> mesos.spec
> mftrace.spec
> micropython.spec
> mercurial.spec
> mediawiki.spec
> nodejs.spec
> llvm-test-suite.spec
> llvm11.0.spec
> nx-libs.spec
> octave-miscellaneous.spec
> offlineimap.spec
> openclonk.spec
> openscap.spec
> nut.spec
> pcsc-lite.spec
> percona-xtrabackup.spec
> clang11.spec
> petsc.spec
> noggin.spec
> policycoreutils.spec
> pyhoca-cli.spec
> pynag.spec
> python3.10.spec
> python3.8.spec
> python3.6.spec
> python3.7.spec
> python2.7.spec
> python-biopython.spec
> python-cram.spec
> python-confluent-kafka.spec
> python-bluepy.spec
> PySolFC.spec
> python3.9.spec
> pyhoca-gui.spec
> python-nbconvert.spec
> python-nb2plots.spec
> python-nitrate.spec
> python-os-testr.spec
> python-igor.spec
> python-exabgp.spec
> python-pyside2.spec
> python-reportlab.spec
> python-rpm-macros.spec
> python-scss.spec
> pytz.spec
> rocminfo.spec
> roca-detect.spec
> rabbitvcs.spec
> python-zbase32.spec
> python-mistune08.spec
> llvm9.0.spec
> llvm7.0.spec
> libtalloc.spec
> scipy.spec
> solarwolf.spec
> TeXmacs.spec
> llvm8.0.spec
> swift-lang.spec
> python3.11.spec
> llvm11.spec
> telepathy-logger.spec
> syslog-ng.spec
> systemtap.spec
> scons.spec
> tuna.spec
> vips.spec
> wavextract.spec
> xpra.spec
> andriller.spec
> tuptime.spec
> clang12.spec
> llvm12.spec
> new-session-manager.spec
> workrave.spec
> wine-mono.spec
> wabt.spec
> vdrift.spec
> inksmoto.spec
> inkscape.spec
> autojump.spec
> autodownloader.spec
> apbs.spec
>

This list is not sorted, which makes it difficult to scan. Please also
provide the maintainers-by-package list that is usually sent for
changes that affect many packages.

> Have a nice day.
>
> Lumír

-- 
Elliott
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 

Re: Help needed triaging build failures without distutils

[Elliott Sales de Andrade]

On Tue, Oct 18, 2022 at 5:28 AM Miro Hrončok  wrote:
>
> Hey Pythonistas.
>
> The Python standard library distutils module will be removed from Python 3.12+
>
> https://peps.python.org/pep-0632/
>
> As preparatory work, we build all python packages in a Copr repository with
> Python 3.11 sans distutils:
>
> https://copr.fedorainfracloud.org/coprs/g/python/python-without-distutils/
>
> I've rebuilt all the failed builds again and also in a control-group copr:
>
> https://copr.fedorainfracloud.org/coprs/g/python/python-with-distutils/
>
> 250 packages that failed to build without distuils but succeeded with 
> distutils
> need to be examined and categorized into various different groups:
>
>   - package uses distutils only if sys.version_info < (3, 12)
>   -- this is OK but still fails here
>   - package uses distutils unconditionally and the package needs to be fixed
>   - package uses another package that uses distutils unconditionally
>and the dependency needs to be fixed
>
> I suspect most of the packages will fail to build with Python 3.12 (planned 
> for
> Fedora 39, change proposal TBD). The python3-setutpools package provides a
> distutils module [^1], so sometimes "simply" adding BuildRequires:
> python3-setuptools might workaround the problem.
>
> However, upstream involvement is recommended.
>
> A few bugzillas were opened wrt this and I plan to open more:
>
> https://bugzilla.redhat.com/showdependencytree.cgi?id=PYTHON3.12_resolved=0
>
> I've also oepned some upstream Pull Requests:
>  https://github.com/pypa/pip/pull/11522
>  https://github.com/pypa/setuptools/pull/3636
>  https://pagure.io/fedora-gather-easyfix/pull-request/10
>  https://github.com/filbranden/dnf-plugins-perfmetrics/pull/1
>  https://github.com/rpm-software-management/deltarpm/pull/17
>
> Could you please help me by looking at your failed packages and talking to 
> your
> upstreams? Feel free to reply with links, questions, bugzillas...
>
> To test this locally, you can do something like:
>
> 1. fedpkg clone $PKG && cd $PKG
> 2. mock -r fedora-rawhide-x86_64 init
> 3. mock -r fedora-rawhide-x86_64 install python3-devel
> 4. sudo rm -rf
> /var/lib/mock/fedora-rawhide-x86_64/root/usr/lib64/python3.11/distutils/
> 4. fedpkg mockbuild -N
>
>
> Thanks!
>
> qulogicpython-mplcursors python-pikepdf

For python-mplcursors, it appears to have setuptools installed anyway,
but it also looks like a crash in pyproject_buildrequires.py

For python-pikepdf, it appears you built from git while it was in a
sidetag and the new dependencies were unavailable for your copr. It'll
probably build fine now.
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Heads-up / for discussion: dnf not working with 1G of RAM or less

[Elliott Sales de Andrade]

On Sun, Aug 28, 2022 at 11:24 PM Adam Williamson
 wrote:
>
> Hey folks! I apologize for the wide distribution, but this seemed like
> a bug it'd be appropriate to get a wide range of input on.
>
> There's a bug that was proposed as an F37 Beta blocker:
> https://bugzilla.redhat.com/show_bug.cgi?id=1907030
>
> it's quite an old bug, but up until recently, the summary was
> apparently accurate - dnf would run out of memory with 512M of RAM, but
> was OK with 1G. However, as of quite recently, on F36 at least (not
> sure if anyone's explicitly tested F37), dnf operations are commonly
> failing on VMs/containers with 1G of RAM due to running out of RAM and
> getting OOM-killed.
>
> There's some discussion in the bug about what might be causing this and
> potential ways to resolve it, and please do dig into/contribute to that
> if you can, but the other question here I guess is: how much do we care
> about this? How bad is it that you can't reliably run dnf operations on
> top of a minimal Fedora environment with 1G of RAM?
>

DigitalOcean's (probably most popular?) formerly-5-now-$6 droplet is
1GB of RAM, and they also added a $4 with 512MB of RAM. They also
provide Fedora as an image to provision your droplet.
Getting an install and then being unable to install anything or update
it seems... less than ideal for a somewhat-public-facing server,
assuming that's what people use it for.
I don't know how many other cloud providers have Fedora images that
you can provision with, but breaking them is not great.

> This obviously has some overlap with our stated hardware requirements,
> so here they are for the record:
>
> https://docs.fedoraproject.org/en-US/fedora/latest/release-notes/welcome/Hardware_Overview/
>
> that specifies 2GB as the minimum memory for "the default
> installation", by which I think it's referring to a default Workstation
> install, though this should be clarified.

That's "for the default installation", so about Workstation.

> But then there's a "Low
> memory installations" boxout, which suggests that "users with less than
> 768MB of system memory may have better results performing a minimal
> install and adding to it afterward", which kinda is recommending that
> people do exactly the thing that doesn't work (do a minimal install
> then use dnf on it), and implying it'll work.
>
> After some consideration I don't think it makes sense to take this bug
> as an F37 blocker, since it already affects F36, and that's what I'll
> be suggesting at the next blocker review meeting. However, it does seem
> a perfect candidate for prioritized bug status, and I've nominated it
> for that.
>
> I guess if folks can chime in with thoughts here and/or in the bug
> report, maybe a consensus will emerge on just how big of an issue this
> is (and how likely it is to get fixed). There will presumably be a
> FESCo ticket related to prioritized bug status too.
>
> Thanks folks!
> --
> Adam Williamson
> Fedora QA
> IRC: adamw | Twitter: adamw_ha
> https://www.happyassassin.net
>

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

Re: GNOME's Icon Development Kit icons potentially causing implicit conflicts

[Elliott Sales de Andrade]

On Tue, Aug 23, 2022 at 10:59 PM Maxwell G via devel
 wrote:
>
> On Tuesday, August 23, 2022 Lyes Saadi wrote:
> > Fortunately, Icon Development Kit is under CC0, so we're kinda saved
> > from a Licensing apocalypse (although, I have to admit that this is not
> > ideal).
>
> The CC0 has been banned for new packages in Fedora.
>

Banned for code, not content. Icons are not code.


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

Re: gsl soversion bump

[Elliott Sales de Andrade]

On Thu, Aug 11, 2022 at 12:08 PM Susi Lehtola
 wrote:
>
> Hello,
>
>
> gsl will be updated from version 2.6 to 2.7.1 which changes the
> soversion from .25 to .27 in one week. List of dependent packages
>
> $ for rpm in $(repoquery --disablerepo=* --enablerepo=rawhide
> --whatrequires "libgsl.so.25()(64bit)"); do repoquery --disablerepo=*
> --enablerepo=rawhide --source $rpm;done|sort|uniq
>

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

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

Retiring python-sphinx-panels in Rawhide+F37

[Elliott Sales de Andrade]

Hi,

python-sphinx-panels is currently FTBFS as it does not support Sphinx
5. It is abandoned upstream with the suggestion of sphinx-design
instead.

My package which depended on it has moved to sphinx-design, and I
believe all others have as well. According to repoquery, there should
be no BuildRequires on it:

$ repoquery --repo=rawhide{,-source} --whatrequires
python3-sphinx-panels --recursive | grep src$ | pkgname | sort | uniq
$ repoquery --repo={fedora,updates}{,-source} --releasever 37
--whatrequires python3-sphinx-panels --recursive | grep src$ | pkgname
| sort | uniq

So I intend to retire it on Rawhide+F37 within the week, unless
someone still needs it.

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

Re: F36->F37 dnf system upgrade errors

[Elliott Sales de Andrade]

On Tue, Aug 16, 2022 at 4:41 PM Chris Murphy  wrote:
>
> I'm not sure what's up with all the group package messages, I haven't 
> previously seen that before. Any ideas?
>

I've filed several issues for these in F36; those appear to be the same, mostly.
https://pagure.io/fedora-comps/issues?author=qulogic=all

The xmms and banshee ones appear new.

The qgnomeplatform one should have been fixed by
https://pagure.io/fedora-comps/pull-request/739
Is this stuff not released yet?

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

Re: gsl soversion bump

[Elliott Sales de Andrade]

On Thu, Aug 11, 2022 at 12:08 PM Susi Lehtola
 wrote:
>
> Hello,
>
>
> gsl will be updated from version 2.6 to 2.7.1 which changes the
> soversion from .25 to .27 in one week. List of dependent packages
>
> R-gsl-2.1.6-11.fc37.src.rpm

R is currently being rebuilt in a side tag, I believe, so best to skip this one.

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

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

[Elliott Sales de Andrade]

On Mon, Aug 1, 2022 at 8:56 AM Miro Hrončok  wrote:
>
> Dear maintainers.
>
> Based on the current fail to build from source policy, the following packages
> will be retired from Fedora 37 approximately one week before branching (next 
> week).
>

The F37 schedule says the retirement occurs on the same day as branching:
https://fedorapeople.org/groups/schedule/f-37/f-37-all-tasks.html
and also, the title of this email says "in 1 week", which is the same
week as branching.

> Policy:
> https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/
>
> The packages in rawhide were not successfully built at least since Fedora 35.
>
> This report is based on dist tags.
>
> Packages collected via:
> https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb
>
> If you see a package that was built, please let me know.
> If you see a package that should be exempted from the process, please let me
> know and we can work together to get a FESCo approval for that.
>
> If you see a package that can be rebuilt, please do so.
>
>   Package   (co)maintainers
> ==
> tinygo   go-sig, qulogic

It is not entirely correct that tinygo has "not successfully built at
least since Fedora 35." It has been rebuilt in stable branches
multiple times since then, and there are currently no FTBFS bugs open
for them. It *was* FTBFS in Rawhide though, and I have now fixed it.

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

Re: Important changes to software license information in Fedora packages (SPDX and more!)

[Elliott Sales de Andrade]

On Fri, Jul 29, 2022 at 11:20 AM Matthew Miller
 wrote:
>
>
> On behalf of all of the folks working on Fedora licensing improvements,
> I have a few things to announce!
>
>
> New docs site for licensing and other legal topics
> --
>
> All documentation related to Fedora licensing has moved to a new
> section in Fedora Docs, which you can find at:
>
>   https://docs.fedoraproject.org/en-US/legal/
>

All (internal) links on this front page are broken, and just point to
(non-existent) ids on the same page.

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

Re: Please use side tags for backwards-incompatible bumps of major packages, not buildroot overrides

[Elliott Sales de Andrade]

On Wed, Mar 23, 2022 at 12:16 PM Adam Williamson
 wrote:
>
> On Wed, 2022-03-23 at 08:39 +, Paul Howarth wrote:
> >
> > OK, so this is largely my fault. Whilst I didn't do the initial perl
> > 5.34.1 build and update, I did set up the buildroot override and the
> > builds of the two packages (perl-PAR-Packer and polymake) that have
> > hard dependencies on the specific perl version they were built against.
> > Unfortunately the polymake build took over 24 hours on armv7hl but
> > after that I could have and should have expired the buildroot override
> > to prevent the follow-up issues affecting other perl-related builds.
> > The issue was already known about and it was already planned to do the
> > forthcoming update for f35 to perl 5.34.1 in a side tag
> > (https://bugzilla.redhat.com/show_bug.cgi?id=2064808#c5).
>
> Oh sorry, forgot to mention a couple of other things:
>
> 1) Neat trick: I'm pretty sure the buildroot override only needs to be
> valid until all the build dependencies have been installed. For my
> polymake rebuild, I put the override back in place, fired the polymake
> build, waited till all the build tasks for the different arch had
> installed build dependencies, then expired the override again. It
> doesn't need to stay valid for the whole time the actual compilation
> stage is happening.
>

Note, this override isn't strictly needed either. You can create a
side tag, and tag in _any_ build you need to fix things. Pretty sure
you can even tag in older versions of things if necessary. You just
have to remember to untag the extra builds before creating the update
in Bodhi, if you're creating it from the side tag.

> 2) Just to note what I wound up doing here - aside from the special
> polymake case, I found (I hope) all the packages that got built against
> 5.34.1, bumped and rebuilt them against 5.34.0, and edited the
> standalone updates to have the new builds, which will work with both
> 5.34.0 and 5.34.1, so whatever order they get pushed in things should
> be OK.
> --
> Adam Williamson
> Fedora QA
> IRC: adamw | Twitter: adamw_ha
> https://www.happyassassin.net
>

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

Re: Packaging guidelines: gettext vs. gettext-devel

[Elliott Sales de Andrade]

On Fri, Mar 4, 2022 at 3:26 PM Ken Gaillot  wrote:
>
> Hi all,
>
> I have a question about the guidelines for "Handling Locale Files":
>
> https://docs.fedoraproject.org/en-US/packaging-guidelines/#_handling_locale_files
>
> The guidelines state, "If the package uses gettext for translations,
> add BuildRequires: gettext".
>
> gettext-devel seems the more logical dependency, since it has the
> autoconf macros. And of course the guidelines for "Devel Packages"
> state "-devel packages must be used to contain files which are intended
> solely for development or needed only at build-time."
>

gettext is a tool that happens to be used in development, but that is
not the same as being a "Devel Package". It is much the same as gcc or
clang, which we don't have people install gcc-devel and clang-devel
for.
gettext-devel is for development _against_ gettext, which is not the
same as using it.

For a properly released autotools-based project, the gettext autoconf
macros are not necessary as the tarball should have been generated
with configure.ac expanded into configure.

> Both gettext and gettext-devel depend on gettext-libs, which might make
> the issue unnoticeable for packages don't use autotools.
>
> Would "gettext" or "gettext-devel" be more correct for BuildRequires?

In short, gettext is, unless you have special requirements.

> --
> Ken Gaillot 

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

Re: compiling otter-browser-1.0.03 on rawhide fails with Error: /builddir/build/BUILD/otter-browser-1.0.03/redhat-linux-build is not a directory

[Elliott Sales de Andrade]

On Sat, Feb 26, 2022 at 10:20 AM Martin Gansser
 wrote:
>
> sovled by adding this to the spec file.
>
> %global __cmake_in_source_build 1
>

That's not right; the problem is you are doing

%cmake .

which forces the build into the source directory instead of doing the
default build directory that the CMake macros use. If _that_ doesn't
work, then there's probably a bug upstream that should be fixed.

> Regards
> Martin

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

Re: F36 Change: Django 4.0 (Self-Contained Change proposal)

[Elliott Sales de Andrade]

On Wed, 5 Jan 2022 at 11:26, Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/Django4.0
>
> == Summary ==
> Update Django to version 4.0.
>
> == Owner ==
> * Name: [[User:mrunge| Matthias Runge]]
> * Email: mru...@redhat.com
>
>
> == Detailed Description ==
>
> The Django project has regular releases about every 9 months. Django
> 4.0 is a major milestone, and this Change will
> bring the Fedora included version to the latest version.
>
> The immediate step is to bump the python-django package to version
> 4.0. It is expected, that dependent packages will be
> updated as well, or retired, if they haven't seen an update for long time.
>
>
> == Benefit to Fedora ==
>
> This updates to the latest Django version and allows to use the
> distribution provided version to be used both in new developments and
> also with latest Django applications.
>
> The upstream project has more info on what's new
> https://www.djangoproject.com/weblog/2021/dec/07/django-40-released/
>
> The risk of not completing this change is that the next update will be
> more disruptive, Django 4.1 is planned for about the same time as
> Fedora 37 will land.
>
> == Scope ==
> * Proposal owners: python-django will be updated to version 4.0.
> * Other developers:
> Other developers or maintainers will have to test their packages with
> Django 4.0.
> * Release engineering:
> * Policies and guidelines: N/A (not needed for this Change)
> * Trademark approval: N/A (not needed for this Change)
>
> == Upgrade/compatibility impact ==
>
>
> == How To Test ==
> The python3-django package has to be installed in order to run the test.
>
> django-admin --version
> 4.0
>
>
> == Dependencies ==
> Django (the fedora package name is python-django) has a few dependent
> packages which should get updated (or removed) as noted above. If they
> were not updated for Django 4.0, that probably means that their
> upstream is not very active anymore.
>

Which ones? I think you need to figure out what those dependent
packages are and list them in this change.

>
> == Contingency Plan ==
> * Contingency mechanism: (What to do?  Who will do it?) N/A (not a
> System Wide Change)
> * Contingency deadline: N/A (not a System Wide Change)
> * Blocks release? N/A (not a System Wide Change)
>
> == Documentation ==
>
> Extensive upstream documentation can be found at
> https://docs.djangoproject.com/en/4.0/
>
> --
> Ben Cotton
> He / Him / His
> Fedora Program Manager
> Red Hat
> TZ=America/Indiana/Indianapolis

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

Re: File collision advice

[Elliott Sales de Andrade]

On Tue, 4 Jan 2022 at 23:04, Jerry James  wrote:
>
> I would like some advice on this bug:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=2036438
>
> There are a number of packages with names of the form
> python-sphinxcontrib-foo, which install their files into
> %{python3_sitelib}/sphinxcontrib/foo/.  The issue is that at least two
> of these, python-sphinxcontrib-asyncio and
> python-sphinxcontrib-zopeext, install a file named
> %{python3_sitelib}/sphinxcontrib/__init__.py, and the files are not
> identical.
>

I think these packages are wrong upstream. The `sphinxcontrib`
directory is provided by python3-sphinx, and it specifically doesn't
have `__init__.py` there. Those extensions should not be adding one,
so as to keep the implicit namespace package nature of that directory:
https://packaging.python.org/en/latest/guides/packaging-namespace-packages/#native-namespace-packages

By the contents of the files, it appears they are trying to force it
to be a pkg_resources-style namespace package:
https://packaging.python.org/en/latest/guides/packaging-namespace-packages/#pkg-resources-style-namespace-packages

But since Sphinx didn't do that in the first place, there's no
guarantee that other packages will contain `__init__.py` (and indeed
most do not).

> Any thoughts on how this should be dealt with are welcome.  I
> suggested in the bug that we could introduce a package named simply
> python-sphinxcontrib that owns both the sphinxcontrib directory and
> the __init__.py file.  The other python-sphinxcontrib-* packages would
> depend on it, and would not install any such __init__.py file.  There
> is no such upstream package; this would be a Fedora construct simply
> to deal with the file collision.  Perhaps we could even make that a
> subpackage of python-sphinx.
>
> Other ideas are welcome, especially if they mean less work for me. :-)
> --
> Jerry James
> http://www.jamezone.org/

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

Re: Copr success but no packages?

[Elliott Sales de Andrade]

On Mon, 3 Jan 2022 at 16:25, Steven A. Falco  wrote:
>
> I ran the following build on Copr:
>
> https://copr.fedorainfracloud.org/coprs/stevenfalco/kicad/build/3123050/
>
> There are three chroots, one for F34, F35, and rawhide (all x86_64).
>
> All report "success", but there are no resulting rpm packages in the F35 
> area.  The F34 and rawhide areas look correct and have rpm packages.
>

Do you need to force-refresh the page?

> Here are direct links to the chroots:
>
> https://download.copr.fedorainfracloud.org/results/stevenfalco/kicad/fedora-34-x86_64/03123050-kicad/
>
> https://download.copr.fedorainfracloud.org/results/stevenfalco/kicad/fedora-35-x86_64/03123050-kicad/
>

I see:
kicad-6.0.0-2.fc35.src.rpm 2022-Jan-03 19:16:50 719.50M RPM File
kicad-6.0.0-2.fc35.x86_64.rpm 2022-Jan-03 19:16:52 50.74M RPM File
kicad-debuginfo-6.0.0-2.fc35.x86_64.rpm 2022-Jan-03 19:16:43 283.27M RPM File
kicad-debugsource-6.0.0-2.fc35.x86_64.rpm 2022-Jan-03 19:16:59 5.85M RPM File
kicad-doc-6.0.0-2.fc35.noarch.rpm 2022-Jan-03 19:16:58 109.90M RPM File
kicad-packages3d-6.0.0-2.fc35.noarch.rpm 2022-Jan-03 19:16:56 385.23M RPM File

> https://download.copr.fedorainfracloud.org/results/stevenfalco/kicad/fedora-rawhide-x86_64/03123050-kicad/
>
> The builder-live.log in the F35 dir shows that the rpms were written, but 
> they are missing from the dir.
>
> Can someone with root access to the copr infra please take a look?
>
> Thanks,
> Steve

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

Re: F36 Change: Hunspell Dictionary dir change (System-Wide Change proposal)

[Elliott Sales de Andrade]

On Wed, 29 Dec 2021 at 10:02, Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/Hunspell_dictionary_dir_change
>
> == Summary ==
> Update Hunspell Dictionary system directory from /usr/share/myspell/
> to /usr/share/hunspell/
>
> == Owner ==
> * Name: [[User:vishalvvr| Vishal Vijayraghavan]]
> * Email: 
>
>
> == Detailed Description ==
> In most of Linux distributions the standard Hunspell dictionary path
> is `/usr/share/hunspell/` but in Fedora still has
> `/usr/share/myspell/`. This effort is to follow default standard to
> install all Hunspell dictionary into `/usr/share/hunspell/` instead of
> `/usr/share/myspell/`.
>
>
> == Benefit to Fedora ==
> This will future proof Fedora to use the correct current location for
> hunspell spelling dictionaries.
>
> == Scope ==
> * Proposal owners:
> In total there are `135` packages which is to be updated. libreoffice
> & Firefox are the two main applications and rest are mostly language
> dictionary packages.
>
> * Other developers:
>
> * Policies and guidelines: N/A (not needed for this Change)
> * Trademark approval: N/A (not needed for this Change)
> * Alignment with Objectives:
>
>
> == Upgrade/compatibility impact ==
>
>
> == How To Test ==
> 1. Check if default installed dictionary path is
> `/usr/share/hunspell/` instead of `/usr/share/myspell/`
>
> `$ hunspell -D` or `$ ls /usr/share/hunspell/`
>
> 2. Install any language dictionary and check if it getting installed
> into '/usr/share/hunspell/'
>
> `$ dnf install hunspell-hi`
>
> `$ hunspell -D`
>

If, as mentioned above, this will possibly affect applications such as
Firefox and LibreOffice, then those should also be tested as well.

>
> == User Experience ==
> User should not notice any difference: their applications should
> continue to work as expected after this directory migration.
>
> == Dependencies ==
>
>
> == Contingency Plan ==
>
> * Contingency mechanism: revert release back to /usr/share/myspell
> * Contingency deadline: Beta
> * Blocks release? No
>
> --
> Ben Cotton
> He / Him / His
> Fedora Program Manager
> Red Hat
> TZ=America/Indiana/Indianapolis

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

Re: The great Mailman 3 / Hyperkitty upgrade: bumping flufl-lock and mistune?

[Elliott Sales de Andrade]

On Tue, 14 Dec 2021 at 17:32, Michel Alexandre Salim
 wrote:
>
> Hi all,
>
> Neal Gompa and I have been reviving the effort to get our mailing list
> server infrastructure (currently running on RHEL 7 with missing packages
> provided in an unofficial repo) hostable on RHEL 9 + EPEL.
>
> Pagure issue: https://pagure.io/fedora-infrastructure/issue/8455
> Bugzilla tracker: https://bugzilla.redhat.com/show_bug.cgi?id=2030061
> Status: https://hackmd.io/Pb9otlVGQHe1r9BIC5bi7w (not fully updated yet)
>
> We're currently stuck on the following:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=2032607
>
> Your package (python-hyperkitty) Fails To Install in Fedora 36:
>
> can't install hyperkitty:
>   - nothing provides python3.10dist(flufl-lock) >= 4 needed by 
> hyperkitty-1.3.5-1.fc36.noarch
>   - nothing provides python3.10dist(mistune) >= 2~rc1 needed by 
> hyperkitty-1.3.5-1.fc36.noarch
>
> I have PRs attached to the upgrade requests for mistune: 
> https://bugzilla.redhat.com/show_bug.cgi?id=1782288
> and flufl-lock: https://bugzilla.redhat.com/show_bug.cgi?id=1852603
>
> but both have breaking changes I detailed in the above Bz entries; if
> you're a maintainer cc:ed on this email please check the relevant bz:
>
> ❯ sudo dnf repoquery --enablerepo=fedora-source,rawhide,rawhide-source 
> --whatrequires python3-flufl-lock
> mailman3-0:3.3.4-5.fc35.noarch
> mailman3-0:3.3.4-5.fc35.src
> mailman3-0:3.3.4-5.fc36.noarch
> mailman3-0:3.3.4-5.fc36.src
> odcs-0:0.3.4-6.fc35.noarch
> odcs-0:0.3.4-6.fc35.src
> odcs-0:0.3.4-6.fc36.noarch
> odcs-0:0.3.4-6.fc36.src
> python-cartopy-0:0.20.0-1.fc35.src
> python-cartopy-0:0.20.1-2.fc36.src
>
> ❯ sudo dnf repoquery --enablerepo=fedora-source,rawhide,rawhide-source 
> --whatrequires python3-mistune
> python-m2r-0:0.2.1-5.20190604git66f4a5a.fc35.src
> python-nbconvert-0:6.1.0-2.fc35.src
> python-nbconvert-0:6.1.0-3.fc36.src
> python3-m2r-0:0.2.1-5.20190604git66f4a5a.fc35.noarch
> python3-nbconvert-0:6.1.0-2.fc35.noarch
> python3-nbconvert-0:6.1.0-3.fc36.noarch
>
> In particular, python-nbconvert specifically requires mistune < 2, and
> upstream doesn't seem to have a newer release yet. python-cartopy oddly
> only requires flufl-lock in its SRPM, not the built RPM.
>

Cartopy only needs flufl-lock to run tests. I suppose since those are
installed, it could also have a runtime dependency, but it'd be
largely unused, and anyway Cartopy won't need it at all after the next
minor release.

> PRs:
> https://src.fedoraproject.org/rpms/python-flufl-lock/pull-request/1
> https://src.fedoraproject.org/rpms/python-mistune/pull-request/5
>
> (the packages are not in side tags yet because the PRs are not merged
> yet, but if it helps I can build them in a COPR for F35)
>
> We should probably bump the packages in Rawhide anyway, but also to
> note:
> - both of these packages are not co-maintained by the Python SIG
> - most of the recent updates have been done by non-maintainers
>
> Would it make sense to get the following groups officially added to the
> package ACLs?
> - infra-sig (admin), to ease maintaining the dependencies for Mailman
>   and Hyperkitty
> - python-sig (commit or admin), for fixing issues e.g. with newer Python
>   versions
> - epel-packagers-sig (collaborator, epel* branches) for helping to
>   bootstrap on new EL releases
>
> Thanks,
>
> --
> Michel Alexandre Salim
> profile: https://keyoxide.org/mic...@michel-slm.name

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

Re: The great Mailman 3 / Hyperkitty upgrade: bumping flufl-lock and mistune?

[Elliott Sales de Andrade]

On Tue, 14 Dec 2021 at 17:32, Michel Alexandre Salim
 wrote:
>
> Hi all,
>
> Neal Gompa and I have been reviving the effort to get our mailing list
> server infrastructure (currently running on RHEL 7 with missing packages
> provided in an unofficial repo) hostable on RHEL 9 + EPEL.
>
> Pagure issue: https://pagure.io/fedora-infrastructure/issue/8455
> Bugzilla tracker: https://bugzilla.redhat.com/show_bug.cgi?id=2030061
> Status: https://hackmd.io/Pb9otlVGQHe1r9BIC5bi7w (not fully updated yet)
>
> We're currently stuck on the following:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=2032607
>
> Your package (python-hyperkitty) Fails To Install in Fedora 36:
>
> can't install hyperkitty:
>   - nothing provides python3.10dist(flufl-lock) >= 4 needed by 
> hyperkitty-1.3.5-1.fc36.noarch
>   - nothing provides python3.10dist(mistune) >= 2~rc1 needed by 
> hyperkitty-1.3.5-1.fc36.noarch
>
> I have PRs attached to the upgrade requests for mistune: 
> https://bugzilla.redhat.com/show_bug.cgi?id=1782288
> and flufl-lock: https://bugzilla.redhat.com/show_bug.cgi?id=1852603
>
> but both have breaking changes I detailed in the above Bz entries; if
> you're a maintainer cc:ed on this email please check the relevant bz:
>
> ❯ sudo dnf repoquery --enablerepo=fedora-source,rawhide,rawhide-source 
> --whatrequires python3-flufl-lock
> mailman3-0:3.3.4-5.fc35.noarch
> mailman3-0:3.3.4-5.fc35.src
> mailman3-0:3.3.4-5.fc36.noarch
> mailman3-0:3.3.4-5.fc36.src
> odcs-0:0.3.4-6.fc35.noarch
> odcs-0:0.3.4-6.fc35.src
> odcs-0:0.3.4-6.fc36.noarch
> odcs-0:0.3.4-6.fc36.src
> python-cartopy-0:0.20.0-1.fc35.src
> python-cartopy-0:0.20.1-2.fc36.src
>
> ❯ sudo dnf repoquery --enablerepo=fedora-source,rawhide,rawhide-source 
> --whatrequires python3-mistune
> python-m2r-0:0.2.1-5.20190604git66f4a5a.fc35.src
> python-nbconvert-0:6.1.0-2.fc35.src
> python-nbconvert-0:6.1.0-3.fc36.src
> python3-m2r-0:0.2.1-5.20190604git66f4a5a.fc35.noarch
> python3-nbconvert-0:6.1.0-2.fc35.noarch
> python3-nbconvert-0:6.1.0-3.fc36.noarch
>
> In particular, python-nbconvert specifically requires mistune < 2, and
> upstream doesn't seem to have a newer release yet. python-cartopy oddly
> only requires flufl-lock in its SRPM, not the built RPM.
>

Cartopy only needs flufl-lock to run tests. I suppose since those are
installed, it could also have a runtime dependency, but it'd be
largely unused, and anyway Cartopy won't need it at all after the next
minor release.

> PRs:
> https://src.fedoraproject.org/rpms/python-flufl-lock/pull-request/1
> https://src.fedoraproject.org/rpms/python-mistune/pull-request/5
>
> (the packages are not in side tags yet because the PRs are not merged
> yet, but if it helps I can build them in a COPR for F35)
>
> We should probably bump the packages in Rawhide anyway, but also to
> note:
> - both of these packages are not co-maintained by the Python SIG
> - most of the recent updates have been done by non-maintainers
>
> Would it make sense to get the following groups officially added to the
> package ACLs?
> - infra-sig (admin), to ease maintaining the dependencies for Mailman
>   and Hyperkitty
> - python-sig (commit or admin), for fixing issues e.g. with newer Python
>   versions
> - epel-packagers-sig (collaborator, epel* branches) for helping to
>   bootstrap on new EL releases
>
> Thanks,
>
> --
> Michel Alexandre Salim
> profile: https://keyoxide.org/mic...@michel-slm.name

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

Re: Automatically generated Obsoletes tags?

[Elliott Sales de Andrade]

On Mon, 29 Nov 2021 at 08:04, Tomáš Orsava  wrote:
>
> The downside is that we will have a few thousand (est. 3624 [1])
> additional Obsoletes tags in the Fedora repos that are mostly useless.
> Does anyone see a problem with this? Given the amount of tags already
> present (e.g. 336 thousand provides [2], 80 thousand requires [3] and
> 7.5 thousand obsoletes [4]), I think it won't negatively affect
> anything, but I might be mistaken.
>

That's a question for Fedora Devel, not the Python SIG specifically.

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

Review swaps for git-lfs/go-minify deps

[Elliott Sales de Andrade]

Hello,

I haven't done a review in a while, and since I need some new reviews, I
thought I'd see if anyone wanted to swap.

The latest git-lfs requires 2 new dependencies:

- https://bugzilla.redhat.com/2007909 golang-github-git-lfs-pktline - Git
pkt-line Toolkit
- https://bugzilla.redhat.com/2007920 golang-github-git-lfs-wildmatch-2 -
Pattern matching language for filepaths compatible with Git

The latest go-minify requires 1 new dependency:

- https://bugzilla.redhat.com/2003415 golang-github-djherbis-atime - Access
Times for files

I can review C, Go, Python, R packages in return.

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

License change: R-tidyselect: GPLv3 -> MIT

[Elliott Sales de Andrade]

As in title, for the 1.1.1 update, which I will send in F34 and F33 as well.

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

License correction: R-remotes: GPLv2+ -> MIT

[Elliott Sales de Andrade]

This occurred in the previous update from 2.3.0 to 2.4.0 done by
someone else, but the License tag was not updated. This applies to
Rawhide and F35, and I will also build for F34 now.

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

License correction: R-pillar: GPLv3 -> MIT

[Elliott Sales de Andrade]

The license changed between 1.4.7 and 1.6.1, but that update was made
by someone else who did not update the license tag. This only affects
Rawhide and F35, so I am only making the change there.

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

soname bump in xeus

[Elliott Sales de Andrade]

xeus 2.0.0 bumps soname from 1 to 5. I do not believe there are any
dependents at this time that need rebuilding, but I am only bringing
the change to F35 & Rawhide.

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

License change for R-roxygen2: GPLv2 -> MIT

[Elliott Sales de Andrade]

The to-be-built R-roxygen2 7.1.2 release will be MIT instead of GPLv2;
this will come to all Fedora releases.

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

Re: Package deletion notifications are unparsable

[Elliott Sales de Andrade]

On Mon, 13 Sept 2021 at 19:19, Kevin Fenzi  wrote:
>
> On Mon, Sep 13, 2021 at 09:09:39AM +0100, Richard W.M. Jones wrote:
> > On Mon, Sep 13, 2021 at 12:56:45AM -0400, Elliott Sales de Andrade wrote:
> > > I see the following in my Fedora Notifications Digest
> > >
> > > Digest Summary:
> > > 1.  qulogic's visidata-2.3-1.fc35 was deleted
> > > ...
> > > ---
> > >
> > > (2021-09-11 09:56:50 UTC) qulogic's visidata-2.3-1.fc35 was deleted
> > > - http://koji.fedoraproject.org/koji/buildinfo?buildID=1732298
> > >
> > > Unparsable message details
> > >
> > > ---
> > >
> > > I don't know what should be there, but it should probably not be 
> > > unparsable.
> >
> > On the more general point, has anyone at any time ever found these
> > notifications to be useful?  Or actionable (they happen _after_ the
> > build has been deleted, so not very helpful!)
>
> Yeah, perhaps we should drop them, I agree there's not much to do once
> something is already deleted.
>
> There should be a message much eariler when they are untagged from the
> trash tag that actually is useful (you can re-tag them to avoid the
> process continuing).
>

Yes, that message comes through directly from koji, I think? At least,
I don't recall anything on the notifications.

> kevin

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

Re: Some delay with Rawhide builds getting to the buildroot?

[Elliott Sales de Andrade]

On Mon, 13 Sept 2021 at 04:10, Richard W.M. Jones  wrote:
>
>
> The build finished last night:
>
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1830840
>
> but is still not available to build against (8+ hours later).

Isn't that because the gating tests failed to run?
https://bodhi.fedoraproject.org/updates/FEDORA-2021-2b69d61d79

>
> Rich.
>

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

Package deletion notifications are unparsable

[Elliott Sales de Andrade]

I see the following in my Fedora Notifications Digest

Digest Summary:
1.  qulogic's visidata-2.3-1.fc35 was deleted
...
---

(2021-09-11 09:56:50 UTC) qulogic's visidata-2.3-1.fc35 was deleted
- http://koji.fedoraproject.org/koji/buildinfo?buildID=1732298

Unparsable message details

---

I don't know what should be there, but it should probably not be unparsable.

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

Re: Migrating python-graphql-server to new guidelines

[Elliott Sales de Andrade]

On Sun, 22 Aug 2021 at 06:06, Mattia Verga  wrote:
>
> Hello folks,
> I'm trying to migrate graphql-server spec file to the newer Python 
> guidelines, but I'm hitting some walls.
>
> - Building the package locally went fine, while on Koji [¹] I get:
> error: line 39: Unknown tag: %pyproject_extras_subpkg -n 
> python3-graphql-server flask webob aiohttp
>

The extras macro expands to %package, %description, and %files; you
have put it in between a %package and %description, which will surely
confuse rpm somewhat.

> - The example spec file in the guidelines says to use the %tox macro, but I 
> cannot test it locally, because I get:
> tox: error: unrecognized arguments: --current-env
>

You need to ensure that tox is installed as well, if it isn't listed
in upstream's requirements to get pulled in by
%pyproject_buildrequires.

> - graphql-server has a [flask] extra, but in beta4 it requires Flask<1, while 
> in Fedora we have Flask>1... should I remove the extra by obsoleting it? How 
> to properly do so for an extra, considering that all previous Provides were 
> generated automatically?
>

I asked a similar question earlier:
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org/thread/EBTRMFHUEYW4TT5B6S5GGXP4YAWHJE3R/

But maybe you try removing the pin? Flask 2 did break things, but it
may not have broken your package.

> Thanks in advance for the help.
> Mattia
>
> [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=74321415

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

Re: Updated hdf5/netcdf/octave coming to rawhide

[Elliott Sales de Andrade]

On Mon, 9 Aug 2021 at 21:42, Orion Poplawski  wrote:
>
> I'm starting to build packages and all dependencies for an updated
> hdf5/netcdf/octave stack in a side tag.  Please use:
>
> fedpkg build --target=f35-build-side-44365
>
> to build dependent packages until the side tag is merged back.
>
> Dependent packages include:
>
> NetCDF:
> GMT
> R
> dx
> eccodes
> exodusii
> genesis-simulator
> grace
> grass
> grib_api
> nco
> ncview
> netcdf-cxx
> netcdf-fortran
> netcdf-perl
> netcdf4-python
> pymol
> qgis
> wgrib2
>

PS, it looks like you missed R-ncdf4 on this list; not sure if there are others.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Updated hdf5/netcdf/octave coming to rawhide

[Elliott Sales de Andrade]

On Mon, 9 Aug 2021 at 21:42, Orion Poplawski  wrote:
>
> I'm starting to build packages and all dependencies for an updated
> hdf5/netcdf/octave stack in a side tag.  Please use:
>
> fedpkg build --target=f35-build-side-44365
>
> to build dependent packages until the side tag is merged back.
>

Is this already in Rawhide (but not F35)? python-tables appears to be
crashing on Rawhide due to mismatched headers, but not on F35.

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

Obsoleting extras subpackages

[Elliott Sales de Andrade]

In Dask, they have some extras that have effectively been removed, but
they kept them in their config for backwards compatibility.

In Fedora, I would like to remove the meta-subpackages, as they don't
provide any additional Requires. As such, I would like to Obsolete
them from the main package, and as a direct replacement, it should
also Provides the old extra subpackage.

Is there a way to automatically create all the various Provides
aliases that %pyproject_extras_subpkg would normally do?

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

Re: Building docs of compiled extensions with new macros

[Elliott Sales de Andrade]

On Wed, 18 Aug 2021 at 19:51, Miro Hrončok  wrote:
>
> On 18. 08. 21 11:09, Elliott Sales de Andrade wrote:
> > I've been experimenting with the new macros for Python packages, and
> > ran into some issues building Sphinx docs for compiled extensions.
> >
> > When building docs, one usually has to be able to import the project.
> > When the project uses compiled extensions, it is not sufficient to
> > point to the original unpacked sources, but instead must point to the
> > built ones. However, since the new %pyprojec_wheel creates a wheel, I
> > don't know how to do this properly.
> >
> > Setting e.g., PYTHONPATH=/path/to/*.whl doesn't seem to work (it seems
> > to load everything else but the shared library):
> >
> > + pushd docs
> > ~/build/BUILD/pikepdf-2.16.1/docs ~/build/BUILD/pikepdf-2.16.1
> > ++ ls 
> > /builddir/build/BUILD/pikepdf-2.16.1/docs/../pyproject-wheeldir/pikepdf-2.16.1-cp310-cp310-linux_x86_64.whl
> > + 
> > PYTHONPATH=/builddir/build/BUILD/pikepdf-2.16.1/docs/../pyproject-wheeldir/pikepdf-2.16.1-cp310-cp310-linux_x86_64.whl
> > + sphinx-build-3 . ../html
> > Running Sphinx v4.1.2
> >
> > ...
> > ImportError: pikepdf's extension library failed to import
>
> I've run into this in the past as well. I am not yet sure if putting a whl 
> file
> with extension modules on PYTHONPATH should work or not, but it doesn't.
>
> You should be able to build the docs in %install, after installing the wheel 
> by
> putting %{buildroot}%{python3_sitearch} to PYTHONPATH. It is a bit weird, but
> it worked for me in the past.
>

It is a bit weird, at least by definition of the stages.

> If that is not desired or working, you can find the built extension in
> %{_pyproject_builddir}/pip-req-build-*/build/lib.%{python3_platform}-%{python3_version}/
>

That also does work, if a bit undocumented.

It seems that pip may be changing to in-tree builds?
https://github.com/pypa/pip/issues/7555
Are we moving towards that as well? It seems like that would make it
simpler to build the docs for cases like this.

> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
>


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

Building docs of compiled extensions with new macros

[Elliott Sales de Andrade]

I've been experimenting with the new macros for Python packages, and
ran into some issues building Sphinx docs for compiled extensions.

When building docs, one usually has to be able to import the project.
When the project uses compiled extensions, it is not sufficient to
point to the original unpacked sources, but instead must point to the
built ones. However, since the new %pyprojec_wheel creates a wheel, I
don't know how to do this properly.

Setting e.g., PYTHONPATH=/path/to/*.whl doesn't seem to work (it seems
to load everything else but the shared library):

+ pushd docs
~/build/BUILD/pikepdf-2.16.1/docs ~/build/BUILD/pikepdf-2.16.1
++ ls 
/builddir/build/BUILD/pikepdf-2.16.1/docs/../pyproject-wheeldir/pikepdf-2.16.1-cp310-cp310-linux_x86_64.whl
+ 
PYTHONPATH=/builddir/build/BUILD/pikepdf-2.16.1/docs/../pyproject-wheeldir/pikepdf-2.16.1-cp310-cp310-linux_x86_64.whl
+ sphinx-build-3 . ../html
Running Sphinx v4.1.2

Configuration error:
There is a programmable error in your configuration file:

Traceback (most recent call last):
  File 
"/builddir/build/BUILD/pikepdf-2.16.1/pyproject-wheeldir/pikepdf-2.16.1-cp310-cp310-linux_x86_64.whl/pikepdf/__init__.py",
line 13, in 
from . import _qpdf
ImportError: cannot import name '_qpdf' from partially initialized
module 'pikepdf' (most likely due to a circular import)
(/builddir/build/BUILD/pikepdf-2.16.1/pyproject-wheeldir/pikepdf-2.16.1-cp310-cp310-linux_x86_64.whl/pikepdf/__init__.py)

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/lib/python3.10/site-packages/sphinx/config.py", line 327,
in eval_config_file
exec(code, namespace)
  File "/builddir/build/BUILD/pikepdf-2.16.1/docs/conf.py", line 59, in 
import pikepdf  # isort:skip pylint: disable=unused-import
  File 
"/builddir/build/BUILD/pikepdf-2.16.1/pyproject-wheeldir/pikepdf-2.16.1-cp310-cp310-linux_x86_64.whl/pikepdf/__init__.py",
line 16, in 
raise ImportError(_msg) from _e
ImportError: pikepdf's extension library failed to import

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

Re: After branching F36, under Rawhide I can not build packages for F35 for i386 arch, instead of it mock builded packages for F36.

[Elliott Sales de Andrade]

On Mon, 16 Aug 2021 at 15:32, Mikhail Gavrilov
 wrote:
>
> Now compilation failing with error: "Error: GPG check FAILED".
> https://pastebin.com/HNGz7N8A

Rawhide should be releasever: 36 now. You'll need to update
mock-core-configs as noted in the other thread. And if you modified
your configs, check that you don't have any `.rpmsave` files in
/etc/mock.

If after upgrading, things are still a bit strange, try a `mock -r
fedora-rawhide-x86_64 --scrub=all` too.

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

Re: requesting help to update spyder

[Elliott Sales de Andrade]

On Sun, 15 Aug 2021 at 19:40, Scott Talbert  wrote:
>
> On Sun, 15 Aug 2021, Miro Hrončok wrote:
>
> >> Hi,
> >>
> >> I am trying to update spyder on rawhide and F35. The main issue I have is
> >> that pyqt requirements are strict. From the setup file,
> >>
> >> 'pyqt5<5.13',
> >> 'pyqtwebengine<5.13',
> >>
> >> Fedora has 5.15.x. If I relax QT versions, built and launch spyder, I get
> >> this error and spyder fails to launch.
> >>
> >> scaled(self, int, int, aspectRatioMode: Qt.AspectRatioMode =
> >> Qt.IgnoreAspectRatio, transformMode: Qt.TransformationMode =
> >> Qt.FastTransformation): argument 1 has unexpected type 'float'
> >>
> >> scaled(self, QSize, aspectRatioMode: Qt.AspectRatioMode =
> >> Qt.IgnoreAspectRatio, transformMode: Qt.TransformationMode =
> >> Qt.FastTransformation): argument 1 has unexpected type 'float'
> >
> > Do you know where is this error triggered? Try explicitly converting the
> > floats to integers.
>
> Yeah, that sounds more like a common Python 3.10 issue than an issue with
> newer PyQt.
>

No, this is definitely a change in PyQt, or at least sip, cf.
https://github.com/matplotlib/matplotlib/pull/17565
https://github.com/matplotlib/matplotlib/pull/17600

The fix is 'easy', but you need to find everywhere that might trigger
it. QSize takes an int now, as it does in Qt (from C++), instead of
coercing a float.

> Scott

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

Re: pypy3 renamed to pypy3.7 on Fedora 35+, also available in Fedora 33/34

[Elliott Sales de Andrade]

On Wed, 11 Aug 2021 at 08:50, Miro Hrončok  wrote:
>
> Hello PyPyistas,
>
> we have renamed the pypy3 package to pypy3.7 (both the component and the
> "binary" package) on Fedora 35+. The package no longer installs to
> /usr/lib64/pypy3-7.x/ but rather to /usr/lib64/pypy3.7/.
>
> *What is this good for?*
>
> When PyPy 3 was updated from Python 3.N to 3.N+1, traditionally we have only
> updated it in Rawhide (and Branched), not to do a backward-incompatible update
> in stable Fedoras.
> With this renaming, you can now¹ install pypy3.7 on all Fedoras, despite pypy3
> being 3.6 on Fedora 33 and 34.
>
> ¹ (The builds are still running, expect an update in Bodhi later today.)
>
> Once PyPy 3.8 is released, we can introduce it to all Fedora versions.
>
>
> *Warning to Rawhide/Fedora 35 users*
>
> If you already used the pypy3 package with PyPy 3.7, the pypy3.7 package will
> obsolete it. However, the installation paths are different, so you will need 
> to
> re-create your PyPy 3 virtual environments.
>
>
> *Details* (feel free to ignore the rest of this email)
>
> During a lifetime of one stable Fedora release, you will get:
>
> - pypy3.N that provides pypy3 and has /usr/bin/pypy3
> - pypy3.N+c introduced later in the lifetime
>
> E.g. for Fedora 35:
>
> - pypy3.7 that provides pypy3 and has /usr/bin/pypy3
> - pypy3.8 (or newer) might be introduced in the future
>
> For Fedora 33 and 34, there is a transition period:
>
> - pypy3 provides pypy3.6 and has /usr/bin/pypy3
> - pypy3.7 was just introduced
> - pypy3.8 (or newer) might be introduced in the future
>
> See for example on Fedora 33:
>
> $ rpm -qa | grep pypy3
> pypy3-libs-7.3.1-6.fc33.x86_64
> pypy3-7.3.1-6.fc33.x86_64
> pypy3-devel-7.3.1-6.fc33.x86_64
> pypy3.7-libs-7.3.4-4.fc33.x86_64
> pypy3.7-7.3.4-4.fc33.x86_64
> pypy3.7-devel-7.3.4-4.fc33.x86_64
>
> $ pypy3.6 --version
> Python 3.6.9 (831ff17f8cd1, May 26 2021, 11:41:48)
> [PyPy 7.3.1 with GCC 10.3.1 20210422 (Red Hat 10.3.1-1)]
>
> $ pypy3.7 --version
> Python 3.7.10 (8dd9fc18a6f0, Aug 11 2021, 06:30:36)
> [PyPy 7.3.4 with GCC 10.3.1 20210422 (Red Hat 10.3.1-1)]
>

Is there a reason it's not 7.3.5, which was out in May?

> $ pypy3 --version
> Python 3.6.9 (831ff17f8cd1, May 26 2021, 11:41:48)
> [PyPy 7.3.1 with GCC 10.3.1 20210422 (Red Hat 10.3.1-1)]
>
> Note that we *do not* plan to maintain old PyPy versions indefinitely, we plan
> to retire them from Rawhide/Branched as soon as new versions arrive and only
> keep them alive until stable Fedoras goes EOL.
>
> --
> Miro Hrončok

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

Retiring python-pyinsane2

[Elliott Sales de Andrade]

I have just retired python-pyinsane2; it has been archived by upstream
in favour of its replacement libinsane. I believe all users in Fedora
have also moved on to using libinsane as well. Since tests have
broken, it is also FTBFS in Rawhide, and I don't intend to invest any
time into fixing it.

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

Re: Bad checkout problem after mass rebuild?

[Elliott Sales de Andrade]

On Sun, 1 Aug 2021 at 21:12, Richard Shaw  wrote:
>
> I can see my commit in the log but it's not actually "there":
>
> commit 49efbd8bc23b44e5bdf417a96ef174c31ccca359 (HEAD -> rawhide, 
> origin/rawhide, origin/HEAD)
> Author: Richard Shaw 
> Date:   Sun Aug 1 19:57:58 2021 -0500
>
> Bump release for bad mass rebuild commit.
>
> But this does not show here even though I've pushed it:
>
> https://src.fedoraproject.org/rpms/freeimage/commits/rawhide
>
> WTF?!?!?
>

Your 'origin' remote points to your fork, which does contain the commit:

https://src.fedoraproject.org/fork/hobbes1069/rpms/freeimage/c/49efbd8bc23b44e5bdf417a96ef174c31ccca359?branch=rawhide

You've never pushed to the 'real' repo, and presumably your rawhide
branch was tracking your fork, so when you pulled, you only pulled
from your fork as well, which never would have the releng commits
without intervention.

> Here's the error during the build:
>
> $ git clone -n https://src.fedoraproject.org/rpms/freeimage.git 
> /var/lib/mock/f35-build-28911845-3916986/root/chroot_tmpdir/scmroot/freeimage
> Cloning into 
> '/var/lib/mock/f35-build-28911845-3916986/root/chroot_tmpdir/scmroot/freeimage'...
> $ git reset --hard 49efbd8bc23b44e5bdf417a96ef174c31ccca359
> fatal: Could not parse object '49efbd8bc23b44e5bdf417a96ef174c31ccca359'.
>
> Thanks,
> Richard

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

Re: ibus-setup error for typing-boster

[Elliott Sales de Andrade]

On Tue, 13 Jul 2021 at 13:29, Per Bothner  wrote:
>
> This is a follow-up to "ibus-typing-boster - testcase instruction error".
>
> Run ibus-setup in a terminal;
> select the "Input Method" tab;
> click on "Other - Typing Booster" to select it;
> click "Preferences".
>
> I get:
>
> Traceback (most recent call last):
> File "/usr/share/ibus-typing-booster/setup/main.py", line 87, in 
>   import itb_emoji
>  File "/usr/share/ibus-typing-booster/setup/../engine/itb_emoji.py", line 
> 44, in 
>   from packaging import version
> ModuleNotFoundError: No module named 'packaging'
>

There's an update in testing that should fix that:
https://bodhi.fedoraproject.org/updates/FEDORA-2021-d3ba1c0d71

Or you can directly install python3-packaging.

> (It is plausible this is related to why typing-booster is no longer working 
> for me.)
>
> This is on an up-to-date Fedora 34.  I have not tried Rawhide or fresh 
> install.
> --
> --Per Bothner
> p...@bothner.com   http://per.bothner.com/

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

Retiring python-descartes

[Elliott Sales de Andrade]

Hi,

I am retiring python-descartes in Rawhide. Upstream died when
Bitbucket dropped Mercurial support, and has no intention of reviving
it.

Downstream users have stopped using it, and I have removed the
unnecessary dependency from Fedora packages, or patched it out after
reporting upstream.

It is currently FTBFS with Python 3.10, and thus not installable after
the rebuild.

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

Orphaning python-pytest-helpers-namespace

[Elliott Sales de Andrade]

I am orphaning python-pytest-helpers-namespace, which is no longer a
dependency of my packages.

It currently has one bug report [1] for updating to the latest
version, which has grown a new dependency
(setuptools-declarative-requirements) that I do not wish to also
package.

AFAIK, nothing else depends on it in Fedora. Though it is owned by the
saltstack organization on GitHub, it is apparently not used for any of
Salt as packaged in Fedora.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1942610
-- 
Elliott
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Orphaning python-pytest-helpers-namespace

[Elliott Sales de Andrade]

I am orphaning python-pytest-helpers-namespace, which is no longer a
dependency of my packages.

It currently has one bug report [1] for updating to the latest
version, which has grown a new dependency
(setuptools-declarative-requirements) that I do not wish to also
package.

AFAIK, nothing else depends on it in Fedora. Though it is owned by the
saltstack organization on GitHub, it is apparently not used for any of
Salt as packaged in Fedora.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1942610
-- 
Elliott
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [HEADS UP] Moving to sip 5 in Rawhide

[Elliott Sales de Andrade]

On Wed, 16 Jun 2021 at 22:51, Scott Talbert  wrote:
>
> Hi,
>
> Just a heads-up, I've been working on converting packages from sip 4 to
> sip 5 in Rawhide.  (sip is the Python bindings generation system used by
> PyQt and wxPython.)
>

I see we have Qt6, but not PyQt6, in Fedora 34. Is this what's
required to make that available, or is it just that no-one has gotten
around to it?

> I'm planning on opening pull requests against the affected packages soon.
> Please DO NOT merge these PRs yet - they need to be merged and built in a
> side tag in order to build them in the correct order.  Please DO review
> and comment on the PRs though.  Kevin and Rex will be helping merge and
> build once the changes are reviewed.
>
> The sip 5 changes are planned for F35+ only.  Please let me know in the PR
> if you prefer the changes to be fast-forwardable to older releases and
> I'll %if guard them.
>
> The affected packages are:
> python-pyqt5-sip -> NEW package
> calibre
> krita
> plplot
> pyqtwebengine
> python-pyqtchart
> python-qt5
> python3-poppler-qt5
> qgis
> qhexedit2
> qscintilla
> scidavis
> sip
> veusz
>
> Thanks,
> Scott
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure



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

Re: Upcoming soname bumps

[Elliott Sales de Andrade]

On Sat, 12 Jun 2021 at 21:14, Jerry James  wrote:
>
> Hello all,
>

Hi,

> It's nearly time for another round of mathematical software updates,
> including some soname bumps.  I am going to do the following, in this
> approximate order:
>
> - cliquer: update to version 1.22
> - cocoalib: update to version 0.99713
> - ffcall: update to version 2.3
> - memtailor: update to git head for some minor improvements
> - pari: build with pthreads support
> - primecount: update to version 7.0, which entails an soname bump
> - clisp: rebuild due to the ffcall and pari updates
> - eclib: rebuild due to the pari update
> - giac: rebuild due to the cocoalib and pari updates, and add cliquer support
> - L-function: rebuild due to the pari update
> - mathic: update to git head for some minor improvements
> - normaliz: rebuild due to the cocoalib update
> - python-cysignals: update to version 1.10.3
> - mathicgb: update to git head for some minor improvements
> - python-cypari2: update to version 2.1.2
> - python-fpylll: update to version 0.5.6
> - python-pplpy: rebuild due to the python-cysignals update
> - Singular: update to version 4.2.0, which entails an soname bump
> - palp: update to version 2.11
> - polymake: update to version 4.4, which entails an soname bump
> - pynac: update to version 0.7.27
> - python-jupymake: rebuild due to the polymake soname bump
> - sagemath: update to version 9.3
> - python-jupyter-polymake: rebuild due to the polymake soname bump

This one is noarch though; does it really need a rebuild?

> - Macaulay2: update to version 1.18
>
> I'm still working through some minor issues with Macaulay2 and some
> major issues with sagemath, but I hope to have those worked out and
> builds ready to go sometime next week.  The builds will be done for
> Rawhide initially, but the sagemath fans in the Fedora audience
> *really* want version 9.3, so if all goes well, I will also update at
> least F34, and F33 as well if sufficient pressure is applied to do so.
>
> Regards,
> --
> Jerry James
> http://www.jamezone.org/
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure



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

Re: goocanvas2-cairotypes mock build fails

[Elliott Sales de Andrade]

On Thu, 10 Jun 2021 at 02:56, Martin Gansser  wrote:
>
> Hi,
>
> I'am trying to build goocanvas2-cairotypes with mock, but this fails with 
> this error message [1]:
>
> Files found in blib/arch: installing files in blib/lib into architecture 
> dependent library tree
> Installing 
> /builddir/build/BUILDROOT/goocanvas2-cairotypes-0.001-1.fc35.x86_64/usr/lib64/perl5/vendor_perl/auto/GooCanvas2/CairoTypes/CairoTypes.so
> Installing 
> /builddir/build/BUILDROOT/goocanvas2-cairotypes-0.001-1.fc35.x86_64/usr/lib64/perl5/vendor_perl/GooCanvas2/CairoTypes.pm
> Installing 
> /builddir/build/BUILDROOT/goocanvas2-cairotypes-0.001-1.fc35.x86_64/usr/share/man/man3/GooCanvas2::CairoTypes.3pm
> + chmod 0755 
> '/builddir/build/BUILDROOT/goocanvas2-cairotypes-0.001-1.fc35.x86_64%{perl_vendorarch}/auto/GooCanvas2/CairoTypes/CairoTypes.so'
> chmod: cannot access 
> '/builddir/build/BUILDROOT/goocanvas2-cairotypes-0.001-1.fc35.x86_64%{perl_vendorarch}/auto/GooCanvas2/CairoTypes/CairoTypes.so':
>  No such file or directory

It looks like %{perl_vendorarch} is not expanded; did you specify the
right Perl BuildRequires?
https://docs.fedoraproject.org/en-US/packaging-guidelines/Perl/#_build_dependencies

> RPM build errors:
> error: Bad exit status from /var/tmp/rpm-tmp.lactiy (%install)
> Bad exit status from /var/tmp/rpm-tmp.lactiy (%install)
> Child return code was: 1
>
> [1] https://martinkg.fedorapeople.org/ErrorReports/build.log
>
> Regards
> Martin

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

Re: texlive 2021 landing in Rawhide

[Elliott Sales de Andrade]

On Thu, 27 May 2021 at 19:04, Elliott Sales de Andrade
 wrote:
>
> On Thu, 27 May 2021 at 17:18, Tom Callaway  wrote:
> >
> > Hi Fedorans,
> >
> > Just a heads-up, texlive-base (where the compiled code and immediate 
> > dependencies lives) and texlive (where the thousands of other noarch 
> > components live) have been updated to TeXLive 2021 in Rawhide (and the 
> > latest available components from CTAN at the time I did the work).
> >
> > I've done local testing and everything seems to still work, but inevitably, 
> > the act of updating TeXLive breaks things, so if your packages have TeX 
> > dependencies and stop building in rawhide, let me know.
> >
>
> Koschei tells me that pdflatex and/or some font may be broken, e.g., for
> https://koschei.fedoraproject.org/package/R-tinytest?collection=f35
>
> LaTeX errors when creating PDF version.
> This typically indicates Rd problems.
> LaTeX errors found:
> !pdfTeX error: pdflatex (file ptmb8r): Font ptmb8r at 1493 not found
>
> The error is the same for an R package that builds PDF docs, and
> possibly some others:
> https://koschei.fedoraproject.org/affected-by/texlive-collection-latexrecommended?epoch1=9=svn54074=38.fc35=9=svn57862=40.fc35=f35
>

The remaining failures in this list are slightly different (but show more?):

kpathsea: Running mktexpk --mfmode / --bdpi 600 --mag 1+0/600 --dpi 600 pcrb8r
/usr/bin/mktexpk: line 160: gsftopk: command not found
mktexpk: don't know how to create bitmap font for pcrb8r.
mktexpk: perhaps pcrb8r is missing from the map file.

with some being pcrr8r, phvr8r, bchri8r.

I guess there's a missing dependency on gsftopk, or perhaps whatever
file it's trying to create should be pre-generated, and packaged?

> > Also, FWIW, I have no plans to bring this back to any stable branches. 
> > TL2020 is doing well enough there for now.
> >
> > Thanks in advance for your patience,
> > ~spot
> >
>
> --
> Elliott



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

Re: texlive 2021 landing in Rawhide

[Elliott Sales de Andrade]

On Thu, 27 May 2021 at 17:18, Tom Callaway  wrote:
>
> Hi Fedorans,
>
> Just a heads-up, texlive-base (where the compiled code and immediate 
> dependencies lives) and texlive (where the thousands of other noarch 
> components live) have been updated to TeXLive 2021 in Rawhide (and the latest 
> available components from CTAN at the time I did the work).
>
> I've done local testing and everything seems to still work, but inevitably, 
> the act of updating TeXLive breaks things, so if your packages have TeX 
> dependencies and stop building in rawhide, let me know.
>

Koschei tells me that pdflatex and/or some font may be broken, e.g., for
https://koschei.fedoraproject.org/package/R-tinytest?collection=f35

LaTeX errors when creating PDF version.
This typically indicates Rd problems.
LaTeX errors found:
!pdfTeX error: pdflatex (file ptmb8r): Font ptmb8r at 1493 not found

The error is the same for an R package that builds PDF docs, and
possibly some others:
https://koschei.fedoraproject.org/affected-by/texlive-collection-latexrecommended?epoch1=9=svn54074=38.fc35=9=svn57862=40.fc35=f35

> Also, FWIW, I have no plans to bring this back to any stable branches. TL2020 
> is doing well enough there for now.
>
> Thanks in advance for your patience,
> ~spot
>

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

Re: RPM build errors: Illegal char '@' (0x40) in: @2.15.0@

[Elliott Sales de Andrade]

On Wed, 12 May 2021 at 04:23, Sandro Mani  wrote:
>
> Hi
>
> This is a new one [1] (koji task [2]):
>
> Provides: libimagequant = 2.15.0-1.fc35 libimagequant(x86-64) = 2.15.0-1.fc35 
> libimagequant.so.0()(64bit)
> Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) 
> <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1
> Requires: libc.so.6()(64bit) libc.so.6(GLIBC_2.14)(64bit) 
> libc.so.6(GLIBC_2.2.5)(64bit) libc.so.6(GLIBC_2.3.4)(64bit) 
> libc.so.6(GLIBC_2.4)(64bit) libgcc_s.so.1()(64bit) 
> libgcc_s.so.1(GCC_3.3.1)(64bit) libgomp.so.1()(64bit) 
> libgomp.so.1(GOMP_1.0)(64bit) libgomp.so.1(GOMP_4.0)(64bit) 
> libgomp.so.1(OMP_1.0)(64bit) libm.so.6()(64bit) libm.so.6(GLIBC_2.2.5)(64bit) 
> libm.so.6(GLIBC_2.27)(64bit) libm.so.6(GLIBC_2.29)(64bit) rtld(GNU_HASH)
> Processing files: libimagequant-devel-2.15.0-1.fc35.x86_64
> error: Illegal char '@' (0x40) in: @2.15.0@
> Provides: libimagequant-devel = 2.15.0-1.fc35 libimagequant-devel(x86-64) = 
> 2.15.0-1.fc35
> Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) 
> <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1
> Requires: /usr/bin/pkg-config libimagequant.so.0()(64bit)
> RPM build errors:
> Illegal char '@' (0x40) in: @2.15.0@
> Child return code was: 1
>
> 2.15.0 is the version of the package. Any ideas where this one comes from?

In the build log, I see:
sed 's|PREFIX|/usr|;s|VERSION|2.15.0|' < imagequant.pc.in > imagequant.pc

And it says @VERSION@ to be substituted by CMake, so this ends up as @2.15.0@.

See the diff:
https://github.com/ImageOptim/libimagequant/compare/2.14.1..2.15.0

IOW, you can stop doing that manually.

> Apparently not from elfdeps:
>
> $ /usr/lib/rpm/elfdeps --provides libimagequant.so
> libimagequant.so.0()(64bit)
> $ /usr/lib/rpm/elfdeps --requires libimagequant.so
> libgcc_s.so.1(GCC_3.3.1)(64bit)
> libgomp.so.1(GOMP_4.0)(64bit)
> libgomp.so.1(GOMP_1.0)(64bit)
> libgomp.so.1(OMP_1.0)(64bit)
> libm.so.6(GLIBC_2.27)(64bit)
> libm.so.6(GLIBC_2.2.5)(64bit)
> libm.so.6(GLIBC_2.29)(64bit)
> libc.so.6(GLIBC_2.3.4)(64bit)
> libc.so.6(GLIBC_2.14)(64bit)
> libc.so.6(GLIBC_2.4)(64bit)
> libc.so.6(GLIBC_2.2.5)(64bit)
> libm.so.6()(64bit)
> libgomp.so.1()(64bit)
> libgcc_s.so.1()(64bit)
> libc.so.6()(64bit)
> rtld(GNU_HASH)
>
> Thanks
> Sandro
>
> [1] https://kojipkgs.fedoraproject.org//work/tasks/743/67740743/build.log
> [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=67740603
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure



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

License change: R-later: GPLv2+ -> MIT

[Elliott Sales de Andrade]

As in the title.

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

License change: R-rvest GPLv3 -> MIT

[Elliott Sales de Andrade]

As in subject; change will be in F34+ only due to necessary dependencies.

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

Re: Heads Up: Update to proj-8.0.0 in F35 and F34

[Elliott Sales de Andrade]

On Sat, 6 Mar 2021 at 18:53, Sandro Mani  wrote:
>
> Hi
>
> I'll be updating proj to 8.0.0, first in F35 in a side tag and then F34.
>
> I'll rebuild the following dependent packages:
>
> gdal
> gdl
> grass
> libgeotiff
> librasterlite2
> libspatialite
> mapnik
> mapserver
> merkaartor
> ncl
> osm2pgsql
> pcl
> postgis
> pyproj
> python-cartopy

Unfortunately, due to its removing the old header, Cartopy does not
support Proj 8, even in the development branch. It is unlikely to be
done before F34 (though I see from later emails you won't be updating
there), but I will try to push to get it done for F35 upstream.

> qgis
> qmapshack
> R-rgdal
> saga
> spatialite-gui
> vtk
>
> --
>
> Sandro

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

License change: golang-tinygo-x-llvm: NCSA -> ASL 2.0 and NCSA

[Elliott Sales de Andrade]

Since this package is basically a copy of some sources in LLVM, this
change is a reflection of the ongoing efforts to relicense LLVM to ASL
2.0, which are only partially complete.

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

License change: R-dtplyr GPLv2+ -> MIT

[Elliott Sales de Andrade]

Upstream has relicensed; changes coming to F34+ only due to dependencies.

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

License change: R-forcats - GPLv3 -> MIT

[Elliott Sales de Andrade]

Upstream has re-licensed to MIT.

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

License change: R-hms - GPLv3 -> MIT

[Elliott Sales de Andrade]

Upstream has relicensed, as in title. Due to requirements, this will
only be changed in F34+.

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

License correction: R-shiny GPLv3 -> GPLv3 and BSD and MIT and OFL

[Elliott Sales de Andrade]

Since jqueryui is no longer packaged, I've re-bundled it in R-shiny. I
went through the bundled JavaScript libraries and corrected the
License field, as above.

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

License change: R-withr GPLv2+ -> MIT

[Elliott Sales de Andrade]

As in title; updates will be made to all releases.

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

the-new-hotness is broken?

[Elliott Sales de Andrade]

I just received 3 notifications that

> the-new-hotness saw an update for , but pkgdb says the maintainers 
> are not interested in bugs being filed

but all packages have monitoring enabled.

Did something break with it? Maybe the branch name changes?

-- 
Elliott
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora rawhide compose report: 20210201.n.1 changes

[Elliott Sales de Andrade]

On Tue, 2 Feb 2021 at 06:34, Vít Ondruch  wrote:
>
>
> Dne 02. 02. 21 v 12:00 Elliott Sales de Andrade napsal(a):
>
> On Tue, 2 Feb 2021 at 04:45, Vít Ondruch  wrote:
>
> Dne 02. 02. 21 v 10:23 Fedora Rawhide Report napsal(a):
>
> OLD: Fedora-Rawhide-20210201.n.0
> NEW: Fedora-Rawhide-20210201.n.1
>
> = SUMMARY =
> Added images:0
> Dropped images:  2
> Added packages:  6
> Dropped packages:0
> Upgraded packages:   20573
> Downgraded packages: 0
>
> Size of added packages:  2.15 GiB
> Size of dropped packages:0 B
> Size of upgraded packages:   133.57 GiB
> Size of downgraded packages: 0 B
>
> Size change of upgraded packages:   -939.80 MiB
>
> This ^^ just caught my attention. Can somebody elaborate, where we saved
> ~1GB on rebuild? There are packages, where the savings were significant:
>
> Package:  AusweisApp2-1.20.2-11.fc34
> Old package:  AusweisApp2-1.20.2-10.fc34
> Summary:  Online identification with German ID card (Personalausweis)
> RPMs: AusweisApp2 AusweisApp2-data AusweisApp2-doc
> Size: 18.29 MiB
> Size change:  -4.63 MiB
> Changelog:
>* Mon Jan 25 2021 Fedora Release Engineering
>  - 1.20.2-11
>- Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild
>
> So I wonder what is behind?
>
> The top twenty package name prefixes (I just split at the first dash) are:
>
> In [61]: df.groupby('prefix').delta.aggregate(['count',
> 'sum']).sort_values('sum').head(20)
> Out[61]:
>  count sum
> prefix
> python2324 -327,898,137.92
> golang1408 -139,438,803.92
> origin   1  -82,627,788.80
> boost1  -35,410,411.52
> llvm7.0  1  -28,584,181.76
> pyproj   1  -28,552,724.48
> xeus 1  -28,322,037.76
> mod_wsgi 1  -24,788,336.64
> xtl  1  -23,613,931.52
> arbor1  -23,498,588.16
> libiio   1  -23,404,216.32
> mantle   1  -21,223,178.24
> kata 4  -16,488,417.28
> singularity  1  -16,169,041.92
> idris1  -15,256,780.80
> kubernetes   1  -14,449,377.28
> cross1  -12,939,427.84
> geary1   -9,898,557.44
> lazarus  1   -9,888,071.68
> deepin  34   -8,408,135.16
>
> Golang 1.16 (which includes kubernetes and origin on this list, among
> others) may have some space saving with an improved linker
> (http://golang.org/s/better-linker), which may be reflected here.
>
> Looking at two of mine, xtl and xeus (each ~-20 M), the main
> difference is in docs, which no longer include Lato, Roboto, and
> FontAwesome in multiple web formats, totalling about 4.8M per
> subpackage. These docs are generated by Sphinx and breathe.
>
> The previous build of xtl used:
> python3-breathe noarch  4.24.1-1.fc34
> build  167 k
> python3-sphinx  noarch  1:3.3.1-1.fc34
> build  2.0 M
> python3-sphinx_rtd_themenoarch  0.4.3-14.fc33
> build  3.2 M
>
> while the mass rebuild used:
> python3-breathe noarch  4.26.0-1.fc34
> build  169 k
> python3-sphinx  noarch  1:3.4.3-1.fc34
> build  2.1 M
> python3-sphinx_rtd_themenoarch  0.5.1-1.fc34
> build   61 k
>
> Could it be that Sphinx or the theme was recently changed to drop
> fonts and this is reflected as a massive change over all Python
> packages that build docs?
>
>
> Wouldn't be the change of size constant if that was the case?

What do you mean by constant? The fonts were copied into every doc
build, but not every build used that theme, or even Sphinx.

>
> Vít
>

-- 
Elliott
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora rawhide compose report: 20210201.n.1 changes

[Elliott Sales de Andrade]

On Tue, 2 Feb 2021 at 04:45, Vít Ondruch  wrote:
>
>
> Dne 02. 02. 21 v 10:23 Fedora Rawhide Report napsal(a):
> > OLD: Fedora-Rawhide-20210201.n.0
> > NEW: Fedora-Rawhide-20210201.n.1
> >
> > = SUMMARY =
> > Added images:0
> > Dropped images:  2
> > Added packages:  6
> > Dropped packages:0
> > Upgraded packages:   20573
> > Downgraded packages: 0
> >
> > Size of added packages:  2.15 GiB
> > Size of dropped packages:0 B
> > Size of upgraded packages:   133.57 GiB
> > Size of downgraded packages: 0 B
> >
> > Size change of upgraded packages:   -939.80 MiB
>
>
> This ^^ just caught my attention. Can somebody elaborate, where we saved
> ~1GB on rebuild? There are packages, where the savings were significant:
>
> Package:  AusweisApp2-1.20.2-11.fc34
> Old package:  AusweisApp2-1.20.2-10.fc34
> Summary:  Online identification with German ID card (Personalausweis)
> RPMs: AusweisApp2 AusweisApp2-data AusweisApp2-doc
> Size: 18.29 MiB
> Size change:  -4.63 MiB
> Changelog:
>* Mon Jan 25 2021 Fedora Release Engineering
>  - 1.20.2-11
>- Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild
>
> So I wonder what is behind?
>

The top twenty package name prefixes (I just split at the first dash) are:

In [61]: df.groupby('prefix').delta.aggregate(['count',
'sum']).sort_values('sum').head(20)
Out[61]:
 count sum
prefix
python2324 -327,898,137.92
golang1408 -139,438,803.92
origin   1  -82,627,788.80
boost1  -35,410,411.52
llvm7.0  1  -28,584,181.76
pyproj   1  -28,552,724.48
xeus 1  -28,322,037.76
mod_wsgi 1  -24,788,336.64
xtl  1  -23,613,931.52
arbor1  -23,498,588.16
libiio   1  -23,404,216.32
mantle   1  -21,223,178.24
kata 4  -16,488,417.28
singularity  1  -16,169,041.92
idris1  -15,256,780.80
kubernetes   1  -14,449,377.28
cross1  -12,939,427.84
geary1   -9,898,557.44
lazarus  1   -9,888,071.68
deepin  34   -8,408,135.16

Golang 1.16 (which includes kubernetes and origin on this list, among
others) may have some space saving with an improved linker
(http://golang.org/s/better-linker), which may be reflected here.

Looking at two of mine, xtl and xeus (each ~-20 M), the main
difference is in docs, which no longer include Lato, Roboto, and
FontAwesome in multiple web formats, totalling about 4.8M per
subpackage. These docs are generated by Sphinx and breathe.

The previous build of xtl used:
python3-breathe noarch  4.24.1-1.fc34
build  167 k
python3-sphinx  noarch  1:3.3.1-1.fc34
build  2.0 M
python3-sphinx_rtd_themenoarch  0.4.3-14.fc33
build  3.2 M

while the mass rebuild used:
python3-breathe noarch  4.26.0-1.fc34
build  169 k
python3-sphinx  noarch  1:3.4.3-1.fc34
build  2.1 M
python3-sphinx_rtd_themenoarch  0.5.1-1.fc34
build   61 k

Could it be that Sphinx or the theme was recently changed to drop
fonts and this is reflected as a massive change over all Python
packages that build docs?

>
> Vít
>


--
Elliott
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: merging packages - is fedora fedora guideline right?

[Elliott Sales de Andrade]

On Wed, 20 Jan 2021 at 03:48, Petr Stodulka  wrote:
>
> Hi guys,
> I am confused about the official guidelines for merging of packages in Fedora.
>  From my POV, when I merge some packages and the functionality is preserved,
> the Obsoletes and Provides should be set and kept for 2 release cycles.
> So there is not problem with dependencies, etc. However, I've just realized
> that regarding guidelines only Obsoletes should be set.
>

That link is not to the current Guidelines. The Guidelines section on
renames is here:
https://docs.fedoraproject.org/en-US/packaging-guidelines/#renaming-or-replacing-existing-packages
and it says to add both, *unless* it is not a sufficiently compatible
replacement.

> Was it changed and is it really correct? From that point, I already have
> a reported broken deps for git-remote-hg because of the missing provides
> after the merge of some packages - I will fix it, but I am curious whether
> this is really expected. Can you guys put a light on that? Or the guideline
> needs to be fixed?
>
> Thank you!
>
> [0] 
> https://fedoraproject.org/wiki/Upgrade_paths_%E2%80%94_renaming_or_splitting_packages
>
> --
> Petr Stodulka
> OS & Application Modernization
> IRC nicks: pstodulk, skytak
> Senior Software Engineer
> Red Hat Czech s.r.o.

-- 
Elliott
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 34 Change: Golang 1.16 (System-Wide Change proposal)

[Elliott Sales de Andrade]

On Wed, 6 Jan 2021 at 05:12, Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Wed, Jan 06, 2021 at 04:49:03AM -0500, Jakub Cajka wrote:
> >
> > - Original Message -
> > > From: "Josh Boyer" 
> > > To: "Development discussions related to Fedora" 
> > > 
> > > Cc: "Zbigniew Jędrzejewski-Szmek" 
> > > Sent: Tuesday, January 5, 2021 9:45:28 PM
> > > Subject: Re: Fedora 34 Change: Golang 1.16 (System-Wide Change proposal)
> > >
> > > On Tue, Jan 5, 2021 at 2:40 PM Robbie Harwood  wrote:
> > > >
> > > > Zbigniew Jędrzejewski-Szmek  writes:
> > > >
> > > > > On Tue, Dec 15, 2020 at 03:19:16PM -0500, Ben Cotton wrote:
> > > > >> https://fedoraproject.org/wiki/Changes/golang1.16
> > > > >>
> > > > >> == Summary ==
> > > > >> Rebase of Golang package to upcoming version 1.16 in Fedora 34,
> > > > >
> > > > > No complaint about the Change, but...
> > > > > can we please stop saying "rebase"?
> > > > >
> > > > > That verb made sense when packaging was about a stack of patches and
> > > > > hacks. Nowadays maybe 90% of packages are just the upstream version,
> > > > > and another 9% have patches backported from git that will be dropped
> > > > > on the update to the next upstream version. Talking about a "rebase"
> > > > > is mostly confusing.
> > > >
> > > > Not really a defense, but this is what we call it internally for RHEL.
> > > > So even if we officially change the name, most of us are likely to keep
> > > > calling it rebase out of habit.
> > >
> > > I agree with you, Robbie.  It'll hang around and we'll have to deal
> > > with it for a long time.
> > >
> > > However, even internally in RHEL we're starting to see "rebase" be
> > > really hard to understand.  One team will mean "grab a new tarball
> > > that only contains a limited set of bug fixes" and another team will
> > > mean "grab an entirely new major version release that breaks ABI and
> > > on-disk format".  We should honestly look at how to articulate these
> > > kinds of things better, both in Fedora and in RHEL.  "Rebase" is
> > > quickly becoming meaningless.
> > >
> > > josh
> >
> > I kind of agree with all that have been said and will add my point of view. 
> > First I think that any term the we will invent or choose will eventually 
> > drift in way that we might not agree with or want with little that anyone 
> > can do about it.
> >
> > I would argue that in this case it is the most that rebase can be, 
> > especially with the need to actually rebuild "all" the Go packages to pick 
> > up the changes in the compiler and standard Go library. Not much on the 
> > compiler side as all the Fedora patches doesn't really need much 
> > re-basing(mostly just setting some more saner defaults), but the other 
> > packages are rebased in a sense on top of the new version of compiler.
>
> So... the compiler is *updated** and the packages are **rebuilt**?
> """
>  The Go compiler is updated to the upcoming version 1.16 in Fedora 34,
>  and all golang packages are rebuilt. (The pre-release version of Go will
>  be used for the rebuild if released version will not be available at the
>  time of the mass rebuild).
> """
> ?
>
> > I'm open to any improvement in the wording of the change, feel free to 
> > propose something here or just edit the proposal, but please let me know as 
> > the wiki AFAIK doesn't allow continuous notification on changes(or I 
> > haven't been able to find it and enable it for myself).
>
> There's a "watch" button topright, and also when editing, you are asked
> if you want to be notified about changes. I think I always get an email
> when somebody changes a page I'm watching.
>
> > > > (And it does make sense for RHEL where backporting more patches is the
> > > > norm.  I'm uncomfortable with the assertion that ~99% of all packages
> > > > have no downstream-only packages, but that might just be my bias in the
> > > > opposite direction, since I maintain a couple that do.)
>
> Yeah, my numbers were cut from straight cloth ;) It'd be interesting to have
> some real data.

As a first order estimate, it's rather straightforward to grab the
spec tarball and count the number of Patch lines in each one (which
ignores any fanciness with Lua or conditionals, and doesn't really say
if they are downstream-only, exactly).

The top ten count percentages are:
0  71.5054
1  14.7853
2  5.6351
3  2.7172
4  1.4361
5  0.9893
6  0.6611
7  0.4468
8  0.3419
9  0.2234
10 0.1824
>10 1.0760

So at minimum 71.5% have no downstream-only patches. I _think_
packages with fewer patches are ones that will likely go upstream (as
having more patches might indicate that upstream is dead/dying/slow to
release), so the remaining ones with less than 5 are _likely_ to go
upstream. Just guessing that's about half of those would be another
~12%, so around 84%.

For anyone interested in top-patchers:
 patch_count
cc65 170
gcl  129

License change: R-usethis GPLv3 -> MIT

[Elliott Sales de Andrade]

As in subject; this will be in Rawhide only due to other breaking changes.

-- 
Elliott
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

License change: R-ggplot2 GPLv2 -> MIT

[Elliott Sales de Andrade]

As in subject.

-- 
Elliott
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

License change: R-rlang GPLv3 -> MIT

[Elliott Sales de Andrade]

As in subject. Due to other dependency changes, this will only be in Rawhide.

-- 
Elliott
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 34 Change: Enable btrfs transparent zstd compression by default (System-Wide Change proposal)

[Elliott Sales de Andrade]

On Wed, 30 Dec 2020 at 14:53, Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/BtrfsTransparentCompression
>
> == Summary ==
>
> On variants using btrfs as the default filesystem, enable transparent
> compression using zstd. Compression saves space and can significantly
> increase the lifespan of flash-based media by reducing write
> amplification. It can also increase read and write performance.
>
> == Owners ==
>
> * Name: [[User:salimma|Michel Salim]], [[User:dcavalca|Davide
> Cavalca]], [[User:josef|Josef Bacik]]
> * Email: mic...@michel-slm.name, dcava...@fb.com, jo...@toxicpanda.com
>
>
> == Detailed description ==
>
> Transparent compression is a btrfs feature that allows a btrfs
> filesystem to apply compression on a per-file basis. Of the three
> supported algorithms, zstd is the one with the best compression speed
> and ratio. Enabling compression saves space, but it also reduces write
> amplification, which is important for SSDs. Depending on the workload
> and the hardware, compression can also result in an increase in read
> and write performance.
>
> See https://pagure.io/fedora-btrfs/project/issue/5 for details. This
> was originally scoped as an optimization for
> https://fedoraproject.org/wiki/Changes/BtrfsByDefault during Fedora
> 33.
>
>
> == Benefit to Fedora ==
>
> Better disk space usage, reduction of write amplification, which in
> turn helps increase lifespan and performance on SSDs and other
> flash-based media. It can also increase read and write performance.
>
> == Scope ==
>
> * Proposal owners:
> ** Update anaconda to perform the installation using mount -o
> compress=zstd:1
> ** Set the proper option in fstab (alternatively: set the XATTR)
> ** Update disk image build tools to enable compression:
> *** lorax
> *** appliance-tools
> *** osbuild
> *** imagefactory
> ** [optional] Add support for
> [https://github.com/kdave/btrfs-progs/issues/328 setting compression
> level when defragmenting]
> ** [optional] Add support for
> [https://github.com/kdave/btrfs-progs/issues/329 setting compression
> level using `btrfs property`]
> * Other developers:
> ** anaconda: review PRs as needed
> * Release engineering: https://pagure.io/releng/issue/9920
> * Policies and guidelines: N/A
> * Trademark approval: N/A
>
> == Upgrade/compatibility impact ==
>
> This Change only applies to newly installed systems. Existing systems
> on upgrade will be unaffected, but can be converted manually with
> btrfs filesystem defrag -czstd -r, updating `/etc/fstab`
> and remounting.
>
> == How to test ==
>
> Existing systems can be converted to use compression manually with
> btrfs filesystem defrag -czstd -r, updating `/etc/fstab`

Update `/etc/fstab` how? Please be more explicit.

> and remounting.
>
> == User experience ==
>
> Compression will result in file sizes (e.g. as reported by du) not
> matching the actual space occupied on disk. The
> [https://src.fedoraproject.org/rpms/compsize compsize] utility can be
> used to examine the compression type, effective compression ration and
> actual size.
>
> == Dependencies ==
>
> Anaconda will need to be updated to perform the installation using
> mount -o compress=zstd:1
>
> == Contingency plan ==
>
> * Contingency mechanism: will not include PR patches if not merged
> upstream and will not enable
> * Contingency deadline: Final freeze
> * Blocks release? No
> * Blocks product? No
>
> == Documentation ==
>
> https://btrfs.wiki.kernel.org/index.php/Compression
>
> == Release Notes ==
>
> Transparent compression of the filesystem using zstd is now enabled by
> default. Use the compsize utility to find out the actual size on disk
> of a given file.
>
>
> --
> Ben Cotton
> He / Him / His
> Senior Program Manager, Fedora & CentOS Stream
> Red Hat
> TZ=America/Indiana/Indianapolis
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org



-- 
Elliott
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Packaging chunkfs - no debug output

[Elliott Sales de Andrade]

On Wed, 2 Dec 2020 at 17:45, Richard Shaw  wrote:
>
> On Wed, Dec 2, 2020 at 2:34 PM Elliott Sales de Andrade 
>  wrote:
>>
>>
>>
>> On Wed., Dec. 2, 2020, 11:08 a.m. Richard Shaw,  wrote:
>>>
>>> I'm working on packaging chunkfs for fun and curiosity. It should make 
>>> backing up VMs or other large files with traditional backup compression and 
>>> deduplication methods (i.e. BackupPC) easier by breaking up the file into 
>>> chunks.
>>>
>>> It has a manual Makefile which I've patched to comply with the packaging 
>>> guidelines, but I've run into an issue.
>>>
>>> The build respects the required build flags:
>>>
>>> gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches 
>>> -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
>>> -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
>>> -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  
>>> -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection 
>>> -fcf-protection -DVERSION='"0.8"' -O2 -Wall   -c -o utils.o utils.c
>>> gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches 
>>> -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
>>> -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
>>> -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  
>>> -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection 
>>> -fcf-protection -DVERSION='"0.8"' -O2 -Wall   -c -o unchunkfs.o unchunkfs.c
>>> gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches 
>>> -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
>>> -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
>>> -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  
>>> -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection 
>>> -fcf-protection -DVERSION='"0.8"' -O2 -Wall   -c -o chunkfs.o chunkfs.c
>>> gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches 
>>> -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
>>> -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
>>> -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  
>>> -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection 
>>> -fcf-protection -s -lfuse  unchunkfs.o utils.o   -o unchunkfs
>>> gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches 
>>> -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
>>> -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
>>> -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  
>>> -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection 
>>> -fcf-protection -s -lfuse  chunkfs.o utils.o   -o chunkfs
>>
>>
>>
>> This appears to be applying CFLAGS, but not LDFLAGS.
>
>
> I tried adding LDFLAGS="%{build_ldflags}" but then I get:
>
> cc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches 
> -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
> -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
> -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64 
> -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection 
> -fcf-protection --Wl,-z,relro -Wl,--as-needed  -Wl,-z,now 
> -specs=/usr/lib/rpm/redhat/redhat-hardened-ld  -s -lfuse  chunkfs.o utils.o   
> -o chunkfs
> make: *** Waiting for unfinished jobs
> cc: error: unrecognized command-line option '--Wl,-z,relro'
>

Either your substitution or the makefile has a typo. The flag is
-Wl,-z,relro, single dash, just like the other ones.

Why not use %set_build_flags instead of manually setting *FLAGS?

> Thanks,
> Richard
>

--
Elliott
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Packaging chunkfs - no debug output

[Elliott Sales de Andrade]

On Wed., Dec. 2, 2020, 11:08 a.m. Richard Shaw, 
wrote:

> I'm working on packaging chunkfs for fun and curiosity. It should make
> backing up VMs or other large files with traditional backup compression and
> deduplication methods (i.e. BackupPC) easier by breaking up the file into
> chunks.
>
> It has a manual Makefile which I've patched to comply with the
> packaging guidelines, but I've run into an issue.
>
> The build respects the required build flags:
>
> gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches
> -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
> -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
>  -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
> -fcf-protection -DVERSION='"0.8"' -O2 -Wall   -c -o utils.o utils.c
> gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches
> -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
> -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
>  -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
> -fcf-protection -DVERSION='"0.8"' -O2 -Wall   -c -o unchunkfs.o unchunkfs.c
> gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches
> -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
> -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
>  -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
> -fcf-protection -DVERSION='"0.8"' -O2 -Wall   -c -o chunkfs.o chunkfs.c
> gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches
> -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
> -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
>  -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
> -fcf-protection -s -lfuse  unchunkfs.o utils.o   -o unchunkfs
> gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches
> -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
> -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
>  -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
> -fcf-protection -s -lfuse  chunkfs.o utils.o   -o chunkfs
>


This appears to be applying CFLAGS, but not LDFLAGS.


> And debuginfo runs:
>
>  /usr/lib/rpm/find-debuginfo.sh -j12 --strict-build-id -m -i
> --build-id-seed 0.8-1.fc33 --unique-debug-suffix -0.8-1.fc33.x86_64
> --unique-debug-src-base chunkfs-0.8-1.fc33.x86_64 --run-dwz
> --dwz-low-mem-die-limit 1000 --dwz-max-die-limit 11000 -S
> debugsourcefiles.list /tmp/rpkg/chunkfs-13-igup1ez3/chunkfs-0.8
>
> But all the results are empty files:
>
> $ ll /tmp/rpkg/chunkfs-13-igup1ez3/chunkfs-0.8/*debug*
> -rw-r--r--. 1 build build 0 Dec  2 09:11
> /tmp/rpkg/chunkfs-13-igup1ez3/chunkfs-0.8/debugfiles.list
> -rw-r--r--. 1 build build 0 Dec  2 09:11
> /tmp/rpkg/chunkfs-13-igup1ez3/chunkfs-0.8/debuglinks.list
> -rw-r--r--. 1 build build 0 Dec  2 09:11
> /tmp/rpkg/chunkfs-13-igup1ez3/chunkfs-0.8/debugsourcefiles.list
> -rw-r--r--. 1 build build 0 Dec  2 09:11
> /tmp/rpkg/chunkfs-13-igup1ez3/chunkfs-0.8/debugsources.list
>
> What gives? Have it just missed something super simple?
>
> Thanks,
> Richard
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: CPE Weekly: 2020-11-22

[Elliott Sales de Andrade]

On Mon, 23 Nov 2020 at 05:54, Aoife Moloney  wrote:
>
> ### OSBS for aarch64
> * Basic OKD 3.11 working on aarm64 with F31

What is OSBS? Please don't use undefined acronyms.

> * Working on repeating that install with F33
> * Next step will be to

This sentence is incomplete.

-- 
Elliott
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages looking for new maintainers (hundreds of freshly orphaned F33FTBFS)

[Elliott Sales de Andrade]

On Mon, 23 Nov 2020 at 04:32, Miro Hrončok  wrote:
> golang-github-casbin  go-sig, orphan   0 weeks ago

I took this one before realizing it was v1, not v2, so I've orphaned it again.

> golang-github-cenkalti-backoffgo-sig, jchaloup, orphan 0 weeks ago
> golang-github-cespare-xxhash  go-sig, orphan   0 weeks ago

These two are needed by restic (maintainers cc'd). I can take xxhash
if you don't want it, but not so keen on backoff.

> gplugin   orphan   0 weeks ago

Taken

-- 
Elliott
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: video meeting to discuss Matrix/Element and IRC

[Elliott Sales de Andrade]

On Thu, 19 Nov 2020 at 14:44, Tom Hughes via devel
 wrote:
>
> On 19/11/2020 19:25, Adam Williamson wrote:
>
> > I mean, I'm an old fogey too, but at *some* point we do have to accept
> > that new things can be actively better.
>
> True.
>
> > I honestly can see exactly zero downsides to using a Matrix setup as
> > compared to using IRC, and a giant pile of upsides, starting with "I no
> > longer need to dedicate a small portion of my brain to remembering how
> > my IRC bouncer setup works and maintaining it".
>
> Well my experience when I looked at matrix desktop clients
> before was that they needed more screen real estate to be
> usable than IRC clients, which is certainly one downside and
> probably a direct consequence of rich media support.
>
> There's also the fact that unless I can get it to talk to all
> the same chat systems I have pidgin talking to I would need to
> be running two clients instead of one.
>

I don't know if it's packaged and can't speak to its quality, but
there exists a protocol plugin to use Matrix in Pidgin:
https://github.com/matrix-org/purple-matrix/#readme

> I am interested though, and did actually explore the idea of
> running my own home server and what I could bridge it to (so
> not that different to running my own bouncer now...) recently.
>
> Anyway I just looked at the three clients that were suggested
> earlier - all three are using Qt which makes them virtually
> unusable on a wayland/gnome desktop as far as I can see as the
> resize handles are so small they're impossible to use.
>
> More amusingly one of them crashed as soon as I logged in and
> a second went into a "your window is too small mode" as soon
> as I resized it to match my IRC client.
>
> The third was better, but rendered the conversation in that
> left/right style of SMS clients, which is horrible for a chat
> room.
>
> No doubt there are others I can try...
>
> Tom
>

-- 
Elliott
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

License change: R-vctrs GPLv3 -> MIT

[Elliott Sales de Andrade]

See title. I will only be updating in F33+.

-- 
Elliott
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Upstream SPEC files - was: Re: patch applied without package maintainers' approve

[Elliott Sales de Andrade]

On Mon, 16 Nov 2020 at 03:06, Miroslav Suchý  wrote:
>
> Dne 12. 11. 20 v 21:22 Adam Williamson napsal(a):
> > If you're going to have this kind of "upstream" spec file...well, I
> > wish you wouldn't. But if you do, *AT MINIMUM*, the "downstream" spec
> > files need to have a clear explanation that there is an "upstream" spec
> > file, with a justification as to why, and a link to it. At the very
> > top. Otherwise there is no chance any other Fedora packager is going to
> > find it.
>
> This is actually a good idea. I have lots of such spec files.
>
> Is it a good idea to document this in Packaging Guidelines?

It is already in the guidelines:
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_spec_maintenance_and_canonicity

> Something like:
>
>   If upstream provides SPEC files and your SPEC is a copy you should put on 
> top of SPEC
>   file:
>   # This SPEC file is a copy from upstream http://www.upstream.org/foo.spec
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

R-here license change: GPLv3 -> MIT

[Elliott Sales de Andrade]

As in title, here re-licensed from GPLv3 to MIT.

There are also some new dependencies, so likely won't be building this
in Rawhide for a little bit until they are reviewed.

-- 
Elliott
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

R-rprojroot license change: GPLv3 -> MIT

[Elliott Sales de Andrade]

As in title, rprojroot re-licensed from GPLv3 to MIT.

-- 
Elliott
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

R-generics license change: GPLv2 -> MIT

[Elliott Sales de Andrade]

As in subject. I expect little trouble as it's more permissive.

-- 
Elliott
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Problem with F32 koji build root?

[Elliott Sales de Andrade]

On Wed, 28 Oct 2020 at 19:07, Steven A. Falco  wrote:
>
> I'm getting a build failure [1] in F32 that I'm not seeing in other targets 
> (F31, F33, rawhide are all good).
>
> The error is in the tex packages:
>
> ERROR: 
> Exception(/var/tmp/koji/tasks/2028/54442028/local/work/tasks/1779/54441779/kicad-5.1.8-1.fc32.src.rpm)
>  Config(f32-build-23694835-2326598) 0 minutes 58 seconds
> INFO: Results and/or logs in: /var/lib/mock/f32-build-23694835-2326598/result
> ERROR: Command failed:
>   # /usr/bin/dnf builddep --installroot 
> /var/lib/mock/f32-build-23694835-2326598/root/ --setopt=install_weak_deps=0 
> --disableplugin=local --disableplugin=spacewalk 
> /var/lib/mock/f32-build-23694835-2326598/root//builddir/build/SRPMS/kicad-5.1.8-1.fc32.src.rpm
>  --setopt=tsflags=nocontexts
> No matches found for the following disable plugin patterns: local, spacewalk
> Last metadata expiration check: 0:00:01 ago on Wed Oct 28 22:59:10 2020.
> Error:
>   Problem: package texlive-kpathsea-7:20200327-16.fc32.x86_64 requires 
> texlive-texlive-scripts = 7:20200327-16.fc32, but none of the providers can 
> be installed
>- package texlive-texlive-scripts-7:20200327-16.fc32.noarch requires 
> /usr/bin/texlua, but none of the providers can be installed
>- package po4a-0.60-1.fc32.noarch requires texlive-kpathsea-bin, but none 
> of the providers can be installed
>- package po4a-0.60-1.fc32.noarch requires texlive-kpathsea, but none of 
> the providers can be installed
>- package texlive-luatex-7:20200327-16.fc32.x86_64 requires texlive-cm, 
> but none of the providers can be installed
>- conflicting requests
>- nothing provides tex-tetex needed by texlive-cm-9:svn49028-21.fc32.noarch
>- nothing provides texlive-tetex-bin needed by 
> texlive-cm-9:svn49028-21.fc32.noarch
> (try to add '--skip-broken' to skip uninstallable packages)
>
> I'll wait a bit before resubmitting the job, but I'd appreciate suggestions 
> if there is something I can do to work around it.
>

It's not just you:
$ mock -r fedora-32-x86_64 --enablerepo=local --install texlive-tetex-bin
...
 Error: Transaction test error:
  file /etc/texlive/web2c/updmap.cfg conflicts between attempted
installs of texlive-texlive-scripts-7:20200327-16.fc32.noarch and
texlive-tetex-7:20190410-12.fc32.noarch
  file /usr/share/man/man1/fmtutil.1.gz conflicts between attempted
installs of texlive-texlive-scripts-7:20200327-16.fc32.noarch and
texlive-tetex-7:20190410-12.fc32.noarch
  file /usr/share/man/man1/updmap.1.gz conflicts between attempted
installs of texlive-texlive-scripts-7:20200327-16.fc32.noarch and
texlive-tetex-7:20190410-12.fc32.noarch
  file /usr/share/texlive/texmf-dist/scripts/texlive/fmtutil-user.sh
conflicts between attempted installs of
texlive-texlive-scripts-7:20200327-16.fc32.noarch and
texlive-tetex-7:20190410-12.fc32.noarch
  file /usr/share/texlive/texmf-dist/scripts/texlive/fmtutil.pl
conflicts between attempted installs of
texlive-texlive-scripts-7:20200327-16.fc32.noarch and
texlive-tetex-7:20190410-12.fc32.noarch
  file /usr/share/texlive/texmf-dist/scripts/texlive/updmap-user.sh
conflicts between attempted installs of
texlive-texlive-scripts-7:20200327-16.fc32.noarch and
texlive-tetex-7:20190410-12.fc32.noarch
  file /usr/share/texlive/texmf-dist/scripts/texlive/updmap.pl
conflicts between attempted installs of
texlive-texlive-scripts-7:20200327-16.fc32.noarch and
texlive-tetex-7:20190410-12.fc32.noarch

I think this is due to this buildroot override (maintainer cc'd):
https://bodhi.fedoraproject.org/overrides/texlive-base-20200327-16.fc32
Something lower-level like this should probably use a side tag.

> [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=54441778
>
> Steve
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org