Package Details: python-coloredlogs 15.0.1-3

Git Clone URL: https://aur.archlinux.org/python-coloredlogs.git (read-only, click to copy)
Package Base: python-coloredlogs
Description: Colored terminal output for Python's logging module
Upstream URL: https://github.com/xolox/python-coloredlogs
Licenses: MIT
Submitter: maikoool
Maintainer: Alfred456654
Last Packager: djmattyg007
Votes: 24
Popularity: 0.23
First Submitted: 2016-09-16 14:16 (UTC)
Last Updated: 2022-01-23 10:43 (UTC)

Latest Comments

1 2 Next › Last »

eclairevoyant commented on 2023-05-24 14:30 (UTC)

@martin-de namcap output is not always to be trusted, you have to actually read the code to make sure. In this case it seems it is not needed at all.

martin-de commented on 2023-05-24 14:00 (UTC) (edited on 2023-05-24 14:04 (UTC) by martin-de)

Please move python-setuptools dependency from the makedepends- to the depends-array since it's needed on runtime:

python-coloredlogs E: Dependency python-setuptools detected and not included (python modules ['pkg_resources.load_entry_point'] needed in files ['usr/bin/coloredlogs'])

eclairevoyant commented on 2023-05-21 18:17 (UTC)

Please update the source to follow guidelines as per https://wiki.archlinux.org/title/PKGBUILD#source:

Warning: The downloaded source filename must be unique because the SRCDEST directory can be the same for all packages. For instance, using the version number of the project as a filename potentially conflicts with other projects with the same version number. In this case, the alternative unique filename to be used is provided with the syntax source=('unique_package_name::file_uri'); e.g. source=("$pkgname-$pkgver.tar.gz::https://github.com/coder/program/archive/v$pkgver.tar.gz").

rosenberg commented on 2023-01-23 16:26 (UTC)

It doesn't build anymore:

==> Starting build()...
Traceback (most recent call last):
  File "/home/[USERNAME]/.cache/yay/python-coloredlogs/src/python-coloredlogs-15.0.1/setup.py", line 30, in <module>
    from setuptools import find_packages, setup
  File "/usr/lib/python3.10/site-packages/setuptools/__init__.py", line 36, in <module>
    __version__ = setuptools.version.__version__
AttributeError: partially initialized module 'setuptools' has no attribute 'version' (most likely due to a circular import)
==> ERROR: A failure occurred in build().
    Aborting...
error: target not found: python-coloredlogs
 -> error making: python-coloredlogs

marco.righi commented on 2022-04-06 07:35 (UTC) (edited on 2022-04-06 07:37 (UTC) by marco.righi)

Error upgrading ocrmypdf:


Extension error:
Could not import extension sphinx.builders.linkcheck (exception: cannot import name 'Mapping' from 'collections' (/usr/lib/python3.10/collections/__init__.py))
==> ERROR: A failure occurred in build().
    Aborting...
 -> errore nella creazione: python-coloredlogs
->


LSB Version:    n/a
Distributor ID: ManjaroLinux
Description:    Manjaro Linux
Release:    21.2.5
Codename:   Qonos

Solutions?

djmattyg007 commented on 2020-12-14 12:59 (UTC)

If it really is that much of a burden to do it once a year (python releases absolutely will be coming in annually now), I'm happy to take over maintainership of these packages.

djmattyg007 commented on 2020-12-14 12:58 (UTC)

At the end of the day it only takes a minute of your time and really isn't that big of a deal given you likely need to rebuild the package too. A lot of people would appreciate it if it was done.

djmattyg007 commented on 2020-12-14 12:57 (UTC)

A lot of people these days are using AUR helpers such as aurutils, which help you run a proper package repository. In these cases it isn't as straightforward as just rebuilding locally. I run a repository for all the machines in my house. If the pkgrel isn't bumped, there is no update and therefore aurutils doesn't try to rebuild the package. Even if I forcibly replace the package in my repository, there would still be nothing to indicate to all machines using that repository that there is an update available.

I think you only have to look at the sheer number of python packages in the AUR where the pkgrel was bumped in the first 24 hours after python3.9 hit the official repos to see that it's the right thing to do.

This should link to a list of AUR packages that have "python-" in the name, sorted by last updated time:

https://aur.archlinux.org/packages/?O=0&SeB=n&K=python-&outdated=&SB=l&SO=d&PP=50&do_Search=Go

Check out how many of them have bumped the pkgrel recently with commit messages that explicitly mention Python 3.9. Some examples from the top 50 results when I ran the search, all by different maintainers:

https://aur.archlinux.org/cgit/aur.git/log/?h=python-adafruit-gpio
https://aur.archlinux.org/cgit/aur.git/log/?h=python-mathlibtools
https://aur.archlinux.org/cgit/aur.git/log/?h=python-captcha
https://aur.archlinux.org/cgit/aur.git/log/?h=python-yfinance
https://aur.archlinux.org/cgit/aur.git/log/?h=python-pysdl2
https://aur.archlinux.org/cgit/aur.git/log/?h=python-flask-apscheduler

Even if you think it isn't common practice, I'd also argue it's not common practice for people to keep sources around for AUR packages they build just in case they need to manually rebuild it themselves for some reason. That means that even to just rebuild it, they'd need to re-download the sources anyway, at which point it's neither here nor there regarding bumping the pkgrel.

maikoool commented on 2020-12-10 16:55 (UTC)

Hi, I will not bump it because of the python version update.

While it's very annoying that python updates break everything, "fixing" it by bumping the pkgrel of all packages does not make sense, especially when the PKGBUILD doesn't provide any guarantees about which python version it should be built against.

In my mind it's up to the users of AUR packages to rebuild their packages in these cases, and afaik there's no guidelines on this, so I choose to not bump the pkgrel.

djmattyg007 commented on 2020-12-10 11:41 (UTC)

Please could you bump the pkgrel?

1 2 Next › Last »