Package Details: python-can 4.0.0-1

Git Clone URL: https://aur.archlinux.org/python-can.git (read-only, click to copy)
Package Base: python-can
Description: Python library to access CAN bus via SocketCAN, Kvaser's CANLIB, or CAN over Serial
Upstream URL: https://pypi.python.org/pypi/python-can
Keywords: can
Licenses: LGPLv3
Submitter: 2bluesc
Maintainer: 2bluesc
Last Packager: 2bluesc
Votes: 3
Popularity: 0.000017
First Submitted: 2016-05-12 01:14 (UTC)
Last Updated: 2022-03-23 00:55 (UTC)

Latest Comments

louson commented on 2022-04-14 12:16 (UTC)

I missed a dependency to python-typing-extensions

2bluesc commented on 2021-12-25 02:44 (UTC)

@wlhlm I cleaned-up the build a bit since this PKGBUILD dropped python2-can stuff nearly a year ago after Python2 was sunset and had some old package stuff lingering.

I won't add the conflicts config though as it's unnecessary. Python2 is officially sunset and packages have been migrating away from it for years. That said, the best way to handle python2-can and python-can is to ask the now separate python2-can maintainer to not install the files in to /usr/bin or to rename them so they don't conflict. The rest of the python module can co-exist with python2 and python3 perfectly fine, so they actually don't conflict.

This package aims to be future looking as python2 is no longer a ongoing concern for development efforts and hence why python2-can was dropped by this PKGBUILD nearly a year ago.

wlhlm commented on 2021-12-24 23:15 (UTC) (edited on 2021-12-24 23:21 (UTC) by wlhlm)

This packages is not compatible with python2-can, installation aborts with the following:

loading packages...
resolving dependencies...
looking for conflicting packages...

Packages (1) python-can-3.3.4-2

Total Installed Size:  1.22 MiB

:: Proceed with installation? [Y/n] y
(1/1) checking keys in keyring                                                                         [############################################################] 100%
(1/1) checking package integrity                                                                       [############################################################] 100%
(1/1) loading package files                                                                            [############################################################] 100%
(1/1) checking for file conflicts                                                                      [############################################################] 100%
error: failed to commit transaction (conflicting files)
python-can: /usr/bin/can_logger.py exists in filesystem (owned by python2-can)
python-can: /usr/bin/can_player.py exists in filesystem (owned by python2-can)
python-can: /usr/bin/can_viewer.py exists in filesystem (owned by python2-can)
Errors occurred, no packages were upgraded.

I recommend adding conflicts=(python2-can) to the PKGBUILD.

Also, in package_python-can(), in the line where the cruft left over by setup.py is removed (rm -rf ${pkgdir}/usr/lib/pyton...), the ${pkgdir} should be wrapped in quotes to harden for the case where pkgdir includes spaces for example.

rumpelsepp commented on 2021-03-04 08:52 (UTC)

This packagen seems to depend on python-wrapt as well.

eschwartz commented on 2020-07-19 03:37 (UTC)

Filing an orphan request is nothing special.

It does, however, still produce more work for the TUs. So we'd prefer it if people didn't rush into orphan requests.

rumpelsepp commented on 2020-06-05 14:06 (UTC)

Filing an orphan request is nothing special. An automated e-mail is posted to the mailing list and to the maintainer. As we see here, the process worked fine and proved that I was wrong. I took this way as I had the opinion that you might have dropped arch (and I was wrong!). As I posted in my comment of the orphan request, I indented to add you back as a maintainer, so I don't get the point where I lack cooperation. I might have been lazy, as I clicked the button instead of writing an e-mail in the first place.

I already apologized for this on the mailing list.

2bluesc commented on 2020-06-05 13:43 (UTC)

@rumpelsepp More cooperation would be appreciated instead of filing for maintainer orphan requests when I don't instantaneously update a patch level release in less then a 3 days since this package was flagged out-of-date then.

Sending along a patch in the comments would show that the new update works as-is and requires minimal attention to update.

Thanks

rumpelsepp commented on 2019-11-25 10:13 (UTC)

Please bump the version to trigger a python rebuild. :-)