Hello.
I have fully upgraded Fedora 33 on my laptop and when I try to use
podman and install httpd package into container, I get the following
error message:
Error unpacking rpm package httpd-2.4.46-1.fc32.x86_64
error: unpacking of archive failed on file /usr/sbin/suexec;5f76fa6a:
cpio:
Hello.
After an update to F33 beta, I had troubles with my BT audio devices. I
know Fedora maintainers cannot do anything about it and I've already
sent a bug report to rpmfusion
https://bugzilla.rpmfusion.org/show_bug.cgi?id=5786
So, just in case somebody will have the same problem as I
On 10/5/20 2:32 PM, Miro Hrončok wrote:
On 05. 10. 20 14:23, Miro Hrončok wrote:
On 05. 10. 20 14:08, Daniel Walsh wrote:
Please try this out and set the karma if it fixes the problem.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-15e7ef1dcc
Hi.
The update is unpushed and there is
On 10/2/20 9:52 PM, Daniel Walsh wrote:
On 10/2/20 06:09, Lumír Balhar wrote:
Hello.
I have fully upgraded Fedora 33 on my laptop and when I try to use
podman and install httpd package into container, I get the following
error message:
Error unpacking rpm package httpd-2.4.46-1.fc32.x86_64
ZE
The issue is already reported to the service desk.
Lumír
On 10/1/20 7:50 AM, Lumír Balhar wrote:
Hello.
I've upgraded to Fedora 33 beta and I've discovered a problem with
Thunderbird. All email accounts work well except the Red Hat one with
mail.corp.redhat.com as an IMAP server (I use Z
Hello.
I've upgraded to Fedora 33 beta and I've discovered a problem with
Thunderbird. All email accounts work well except the Red Hat one with
mail.corp.redhat.com as an IMAP server (I use Zimbra servers not Gmail).
The problem is that Thunderbird does not show any error message but it's
I'm a maintainer of micropipenv so I can co-maintain flexmock, if you want.
Have a nice day.
Lumír
On 1/13/21 9:30 AM, Hunor Csomortáni wrote:
I will take it over.
On Wed, Jan 13, 2021 at 1:38 AM Miro Hrončok wrote:
I've orphaned python-flexmock.
It is essentially dead/complete upstream
Hello.
From my point of view and from the networkx perespective, we can brake
this chain and don't install python3-gdal. python3-gdal brings support
for special GIS Shapefile which I think we don't need by default in the
classroom.
Have a nice day.
Lumír
On 1/27/21 3:17 PM, Miro Hrončok
Hello.
I've created my first Perl package and I need somebody who can review
it: https://bugzilla.redhat.com/show_bug.cgi?id=1974666
The git-autofixup is very useful plugin for git.
I can take a review in exchange - most of my experience is with Python
packages.
Have a nice day.
Lumír
One of the mentioned packages already has a fix upstream:
https://github.com/microsoft/vscode/pull/116105
Thanks for help.
Lumír
On 2/11/21 10:32 AM, Miro Hrončok wrote:
On 11. 02. 21 8:39, Lumír Balhar wrote:
Hello.
I'm facing a problem with a conflict between two packages from
non
Hello.
I'm facing a problem with a conflict between two packages from
non-fedora repositories. I'm using vscodium and rememberthemilk apps for
a long time but now I cannot update both because there is a conflict in
/usr/lib/.build-id/.
Error: Transaction test error:
file
Hello.
I'm trying to update zeal package to the latest master because the
latest released version doesn't work anymore.
My WIP specfile is here:
https://src.fedoraproject.org/fork/lbalhar/rpms/zeal/blob/rawhide/f/zeal.spec
When I try to build it in mock for rawhide or f34, I get this
Thank you. It works!
Could you please briefly explain the difference?
Thanks a lot.
Lumír
On 8/23/21 3:33 PM, Vitaly Zaitsev via devel wrote:
On 23/08/2021 11:37, Lumír Balhar wrote:
but the LIB_INSTALL_DIR is defined in the %cmake macro:
You should use %cmake_kf5 macro instead.
Don't
Hello.
I plan to orphan 4 Python packages: python-first, python-pipreqs,
python-plette, and python-yarg.
They were unbundled from pipenv but because we've decided to keep them
bundled there, they are leaf and nothing depends on them in rawhide.
Only yarg is required by plette so it makes
Hello.
My name is Lumír and I maintain a few layered container images in
Fedora/RHEL/upstream related to Python and S2I (source to image)
platform - namely python3, s2i-core, and s2i-base.
TL;DR: We (maintainers of layered container images for languages,
runtimes and databases) are
Hi.
Feel free to asing me as a maintainer of
python-repoze-sphinx-autointerface. The package has dead upstream so I
hope nothing will break soon.
Have a nice day.
Lumír
On 2/10/22 19:17, Miro Hrončok wrote:
On 09. 02. 22 16:38, Jerry James wrote:
On Tue, Feb 8, 2022 at 1:20 PM Miro
Hello.
I've just orphaned package hatch - Python project management tool.
The current version fails to build from source in rawhide - one test
fails, not a big deal. There is also new version 1.0.0rc11 but it
depends on it's own Python build system which I don't want to package
for Fedora.
Hi!
Thanks Mukundan for all the hard work you put into these packages!
I'm interested how this affects my packages so I run a simple script to
see the list of provides and whatrequires them and the result is below.
Because I maintain some parts of ipython and Jupyter stack, I'm going to
Hello.
Because we had a lot of troubles with Fedora infra for container images
(I can provide more details, if you want), we have decided to move our
containers to https://quay.io/organization/fedora.
With quay.io, we are able to produce new container images directly from
Github CI and
Hi.
I'm working on packaging new version of Juyter Notebook and Lab into
Fedora and I have a problem with one Rust/Python package - y-py.
The problem is that when I'm building python-y-py in COPR
https://copr.fedorainfracloud.org/coprs/lbalhar/notebook/builds/ I'm getting
error: no
Thanks Miro! %cargo_prep solved the problem and now I have a different
one I have to tackle :D
Thanks a lot!
Lumír
On 1/9/23 11:23, Miro Hrončok wrote:
On 07. 01. 23 23:41, Lumír Balhar wrote:
Hi.
I'm working on packaging new version of Juyter Notebook and Lab into
Fedora and I have
Hi.
I'm working on an update of pytest to 7.2.0 for rawhide. This version
contains some breaking changes.
* pytest no longer depends on py - it bundles a small subset of py's
functionalities instead. py is kinda deprecated so if a project
depends on it it'd be better to drop that
Hi.
There were some attempts to package JupyterLab (the first one in 2018)
but none of them were successful. But now, after packaging 20 new Python
and Rust packages, JupyterLab finally landed into rawhide. The main
motivation for this effort is the ongoing plan to base the next version
of
On 3/5/23 16:19, Miro Hrončok wrote:
On 05. 03. 23 12:32, Lumír Balhar wrote:
Hi.
There were some attempts to package JupyterLab (the first one in
2018) but none of them were successful. But now, after packaging 20
new Python and Rust packages, JupyterLab finally landed into rawhide
Hi.
I got a bugzilla [0] that because of the retired python3-stomper
python3-moksha-hub fails to install in rawhide.
I'm no longer interested in this package but somebody should take it
together with the python-stomper because important packages like fedmsg
and module-build-service depend
Hello.
I'm going to orphan python-represent. I updated it to the latest version
so if you take it, there is nothing to be done now. It's a leaf package
and I don't have any use for it.
Have a nice day.
Lumír
--
___
devel mailing list --
Hello.
Today I found out an interesting difference between Koji and COPR.
autowrap package has this in its specfile:
Requires: python%{python3_pkgversion}-Cython%{?_isa}
Which is incorrect for noarch package but hold on. The resulting package
from Koji requires:
python3-Cython
but in
Hello.
I plan to orphan the following independent set of packages:
python-jupyter-collaboration
python-jupyter-server-fileid
python-jupyter-ydoc
python-ypy-websocket
python-y-py
rust-yrs
rust-lib0
I've packaged python-jupyter-collaboration to bring the real-time
collaboration feature into
Packages are now orphaned and ready to take over.
Have a nice day.
Lumír
On 1/10/24 14:21, Lumír Balhar wrote:
Hello.
I plan to orphan the following independent set of packages:
python-jupyter-collaboration
python-jupyter-server-fileid
python-jupyter-ydoc
python-ypy-websocket
python-y-py
Hi.
I might have an idea how to make building Perl packages faster and their
buildroot a little bit smaller.
perl-devel depends on systemtap-sdt-devel and that package contains a
single script written in Python and using pycparser. The single script
bring python3-pycparser and therefore the
Hello.
I'm getting HTTP/404 for
https://download.copr.fedorainfracloud.org/results/nonamedotc/nbconvert-6.0.7/fedora-rawhide-x86_64/01795156-python-nbconvert/
Could you please try to rebuild the package?
Have a nice day.
Lumír
On 12/4/20 12:03 AM, Mukundan Ragavan wrote:
Hi,
I am hoping
Hi Victor.
On 12/14/20 11:23 AM, Victor Stinner wrote:
On Mon, Dec 7, 2020 at 4:08 PM Victor Stinner wrote:
Oh, GCC 11 already landed on the Fedora Python buildbots running
Rawhide. I created an issue to track the bugs on Python upstream:
test_buffer fails on Python built with GCC 11
Hello, Michael.
On 11/14/20 1:50 AM, mabinm wrote:
Hi Peter.
You can build the kind of dependency-aware rpm you're looking for in
two ways.
Do a pip download of the python package with or without dependencies
and have the %post scriptlet in the RPM spec file do a pip install of
the wheel,
s [required: >=19.2.0, installed: 20.3.0]
- fonttools [required: >=4.0.0, installed: 4.17.0]
Some packages are already in Fedora (six, pillow, fonttools, lxml …) but
if you want to package nanoemoji, packaging its missing dependencies
will be unavoidable.
Lumír
On 11/16/20 12:10 AM, Peter
Hello.
From my point of view and from the networkx perespective, we can brake
this chain and don't install python3-gdal. python3-gdal brings support
for special GIS Shapefile which I think we don't need by default in the
classroom.
Have a nice day.
Lumír
On 1/27/21 3:17 PM, Miro Hrončok
Hi.
On 3/16/21 8:22 PM, Jos de Kloe wrote:
Hi Miro,
in general I think explicit is better than implicit
(and since I am Dutch, this seems obvious to me).
I agree with Jos here. From my recent experience with onbording a new
packager it seems that our macros (old and new ones) are just enough
Hi.
Have you managed to fix the issue? The error is produce by the configure
script and the check is implemented there somewhere around line 4293 but
I don't understand it well enough to tell you what causing it to detect
the cross compilation.
Lumír
On 9/6/23 14:54, Mattia Verga wrote:
Hi!
Thanks Mukundan for all the hard work you put into these packages!
I'm interested how this affects my packages so I run a simple script to
see the list of provides and whatrequires them and the result is below.
Because I maintain some parts of ipython and Jupyter stack, I'm going to
On 8/23/23 18:34, Miro Hrončok wrote:
On 23. 08. 23 13:17, Sandro wrote:> This might be out of scope, but
would it also be possible to have it fail or
issue a warning if %pyproject_save_files -l marks a license, but the
packager also uses an explicit %license in %files. That would prevent
On 6/25/22 16:22, Ben Beasley wrote:
It appears that requests switched purely because the Apache Software
Foundation doesn’t allow LGPL dependencies[1]. Is there another
rationale that the various Python upstreams that use chardet would
find convincing? Both projects appear to be actively
Hi.
It seems that only one package depends on python3-markdown2 - glogg -
and it seems to be a leaf package. 19 packages depend on python3-markdown_2.
The packages don't conflict.
If I understand it correctly, glogg needs `markdown` executable only to
build documentation. python3-markdown2
Hi Sandro.
Make sure that the build does not use the pyx file from upstream. It
seems to me that the file generated by Cython is in the source tarball
(skmisc/loess/src/_loess.pyx) and I did not find any mention of use of
Cython in the build log. The file is probably generated by an older
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
I vote for 2B combination. Someone else might need that script too so
it's a good idea to have it somewhere publicly available even it might
make the maintenance a little bit harder.
Have a nice day.
Lumír
On 10/11/22 11:47, Miro Hrončok wrote:
Hello Pythonistas,
The pathfix.py script has
Hi Sandro.
You are right that without information from git repository (git tags),
we cannot really use the full potential of setuptools_scm during the RPM
build process. AFAIK the most popular way how to bypass the
setuptools_scm mechanism is to use SETUPTOOLS_SCM_PRETEND_VERSION env
Hi Antonio.
The problem is in the project metadata. When I open the SRPM this
package is built from and the take a look at the source tarball, I find
this in the src/future/__init__.py:
__ver_major__ = 0
__ver_minor__ = 18
__ver_patch__ = 2
So it seems that they released version 0.18.3 with
Hi Sérgio.
On 1/14/23 21:11, Sérgio Basto wrote:
On Thu, 2022-10-27 at 11:57 +0200, Miro Hrončok wrote:
On 27. 10. 22 11:51, Miro Hrončok wrote:
micropython churchyard
https://src.fedoraproject.org/rpms/micropython/pull-request/14
Hi,
Hi Mikel.
The way upstream manages the dependencies of the project seems to be
weird to me. They use setuptools as a build backend and have runtime
dependencies in pyproject.toml but at the same time, they have Pipfile
and Pipfile.lock with runtime and test dependencies.
The best would be
Hi.
There were some attempts to package JupyterLab (the first one in 2018)
but none of them were successful. But now, after packaging 20 new Python
and Rust packages, JupyterLab finally landed into rawhide. The main
motivation for this effort is the ongoing plan to base the next version
of
On 3/5/23 16:19, Miro Hrončok wrote:
On 05. 03. 23 12:32, Lumír Balhar wrote:
Hi.
There were some attempts to package JupyterLab (the first one in
2018) but none of them were successful. But now, after packaging 20
new Python and Rust packages, JupyterLab finally landed into rawhide
I agree with the proposal to include -devel packages when python3-devel
is installed. I think it makes sense, solves the problem with the
missing headers and won't affect most of the users.
Have a nice day.
Lumír
On 2/17/23 15:38, Miro Hrončok wrote:
Hello Pythonistats and packaging folks.
Hi.
This sounds like an interesting idea for one more reason. We are
currently working on the update of pytest to version 8 and that version
no longer runs nose setup/teardown functions/methods which, as far as we
know now, is a change that breaks a lot of packages we previously
migrated
Hi Mikel.
It might look like simple bump but you are upgrading from 4.1.1 to 6.0.0
and there are some breaking changes between those releases.
The error message looks like the plugin is loaded twice for some reason
and the second try to register the same CLI option fails. %pytest macro
sets
53 matches
Mail list logo
