Hello again,
Some corrections to my previous message:
As for how it's installed, I believe that's handled by the upstream setup.py:
   data_files=[
       ("share/bumblebee-status/themes", glob.glob("themes/*.json")),
       ("share/bumblebee-status/themes/icons", glob.glob("themes/icons/*.json")),
       ("share/bumblebee-status/utility", glob.glob("bin/*")),
   ]
Looks like it's put into /something/share/bumblebee-status/utility.
Confirmed that it's /usr/share/bumblebee-status/utility.
 * the build fails here, in a fresh Debian unstable qemu image, with:
       ERROR tests/core/test_output.py - RuntimeError: unable to find
theme default
I am aware of this failure and have reported it upstream. For now, I'll
disable the offending test.
After doing that, I discovered that almost all of the tests are faulty
(at least on Python 3.10), so I've disabled tests altogether for now.
_version.py is not a copy of versioneer, it's *generated* by versioneer. However, there is versioneer.py in the root directory, which is. I'll exclude that from the source and repack.
* i'm really not sure I like that C binary to fetch the keyboard
layout... surely there must be a more pythonic way of doing this? i
guess there's another layout-xkb module that does the right thing,
but it seems odd to have both there..
_version.py is not a copy of versioneer, it's *generated* by versioneer. However, there is versioneer.py in the root directory, which is. I'll exclude that from the source and repack.
hmm... how about that generated file though? shouldn't it be ... well, generated at build time instead? :)
As far as I understand it, this file is used by the author of the program, not end users. I don't understand it well, though, because I haven't put
much time into researching what versioneer even does.
If my hunch is correct, I may be able to just remove the file from the
source altogether, but I haven't tried that yet.
This is a really bad idea IMO.Does the package *work* at all in 3.10? We might not want to silence
real errors here...
Upstream says 3.4-3.9 is supported, but I don't know if that's because 3.10 doesn't work or because they haven't bothered to add it. Searching their bug tracker, I wasn't able to find any 3.10-related issues yet.
I also haven't tried to use the program with Python 3.10, because I don't
use it myself at all (packaging this for a friend).
Here's another note:
On 6/6/22 10:49 AM, Antoine Beaupré wrote:
* i'm really not sure I like that C binary to fetch the keyboard
layout... surely there must be a more pythonic way of doing this? i
guess there's another layout-xkb module that does the right thing,
but it seems odd to have both there..
This is apparently an issue that upstream already knows about (https://github.com/tobi-wan-kenobi/bumblebee-status/issues/790)
but hasn't done anything about for a year.
The fact that there shouldn't be a C binary here at all has just now
been reported by me: https://github.com/tobi-wan-kenobi/bumblebee-status/issues/883
Hi Ben,
On Mon, Jun 06, 2022 at 10:42:53PM -0400, Ben Westover wrote:
_version.py is not a copy of versioneer, it's *generated* by versioneer. >> > > However, there is versioneer.py in the root directory, which is. I'll
exclude that from the source and repack.
hmm... how about that generated file though? shouldn't it be ... well,
generated at build time instead? :)
As far as I understand it, this file is used by the author of the program, >> not end users. I don't understand it well, though, because I haven't put
much time into researching what versioneer even does.
If my hunch is correct, I may be able to just remove the file from the
source altogether, but I haven't tried that yet.
As far as I understand, versioneer (or the _version.py generated by
it) uses a whole bunch of heuristics to determine the version number
of the package, for example by looking at git tags and so on. Several
times, I have found that _version.py in the PyPI release of a package
is a very small file (just a few lines long) stating the version
number of the package, while the _version.py in GitHub is huge and
doesn't work on a standalone packaged version. If I recall correctly,
In more than one package I (co-)maintain, I've gone for the PyPI
version of this file.
Hello Antoine,
I am aware of this failure and have reported it upstream. For now, I'll >>>> disable the offending test.
After doing that, I discovered that almost all of the tests are faulty
(at least on Python 3.10), so I've disabled tests altogether for now.
Does the package *work* at all in 3.10? We might not want to silence
real errors here...
Upstream says 3.4-3.9 is supported, but I don't know if that's because
3.10 doesn't work or because they haven't bothered to add it. Searching
their bug tracker, I wasn't able to find any 3.10-related issues yet.
I also haven't tried to use the program with Python 3.10, because I
don't use it myself at all (packaging this for a friend).
_version.py is not a copy of versioneer, it's *generated* by versioneer. >>> However, there is versioneer.py in the root directory, which is. I'll
exclude that from the source and repack.
hmm... how about that generated file though? shouldn't it be ... well,
generated at build time instead? :)
As far as I understand it, this file is used by the author of the
program, not end users. I don't understand it well, though, because I
haven't put much time into researching what versioneer even does.
If my hunch is correct, I may be able to just remove the file from the
source altogether, but I haven't tried that yet.
let me know when / if you need me to look at it again, and thanks again!
It should be ready for review now, as long as I haven't messed anything
up majorly in my attempts to fix the issues you brought to my attention.
On Tue, Jun 07, 2022 at 09:47:33AM -0400, Antoine Beaupré wrote:
On 2022-06-07 07:11:15, Julian Gilbey wrote:
[...]
As far as I understand, versioneer (or the _version.py generated by
it) uses a whole bunch of heuristics to determine the version number
of the package, for example by looking at git tags and so on. Several
times, I have found that _version.py in the PyPI release of a package
is a very small file (just a few lines long) stating the version
number of the package, while the _version.py in GitHub is huge and
doesn't work on a standalone packaged version. If I recall correctly,
In more than one package I (co-)maintain, I've gone for the PyPI
version of this file.
Uh! So you just keep the file around altogether? That seems like a break
of policy...
Maybe I wasn't clear: we pack the GitHub as the .orig.tar.gz and then
apply a patch (in debian/patches) to replace _version.py with the
version found in the PyPI package. (There are often good reasons to
prefer the GitHub version over the PyPI version.) I just looked
through my local packages and the only examples I could find were the now-removed python-language-server and python-jsonrpc-server.
I'm not sure how this would break policy.
On 2022-06-07 07:11:15, Julian Gilbey wrote:
[...]
As far as I understand, versioneer (or the _version.py generated by
it) uses a whole bunch of heuristics to determine the version number
of the package, for example by looking at git tags and so on. Several times, I have found that _version.py in the PyPI release of a package
is a very small file (just a few lines long) stating the version
number of the package, while the _version.py in GitHub is huge and
doesn't work on a standalone packaged version. If I recall correctly,
In more than one package I (co-)maintain, I've gone for the PyPI
version of this file.
Uh! So you just keep the file around altogether? That seems like a break
of policy...
It seems to me that generated files shouldn't be shipped as part of the source we distributed to users. Those files should be (re)generated at
build time.
As far as I understand it, this file is used by the author of the program, not end users. I don't understand it well, though, because I haven't put much time into researching what versioneer even does.
If my hunch is correct, I may be able to just remove the file from the source altogether, but I haven't tried that yet.
Well, it's used by the program to show the version info, so it's *eventually* used by users for sure.
I think just removing the file is a good first guess.
Removing the file is a bad idea! Replacing it with the PyPI version
(through debian/patches) is a much better approach. (And possibly
excluding the file in debian/copyright as well.)
Hello,
I've read more into versioneer, and it turns out with the way it works
you can't simply remove versioneer.py from the source, much less
_version.py. Therefore, I'm excluding _version.py in d/copyright, then replacing it with the much smaller PyPI version in d/patches, and not touching versioneer.py at all, since with the way versioneer works it's technically not vendoring.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 349 |
| Nodes: | 16 (3 / 13) |
| Uptime: | 107:08:50 |
| Calls: | 7,612 |
| Calls today: | 3 |
| Files: | 12,786 |
| Messages: | 5,682,995 |
| Posted today: | 2 |