Re: a review of your bumblebee-status package

2022-06-06 Thread Ben Westover
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

--
Ben Westover


OpenPGP_signature
Description: OpenPGP digital signature


Re: a review of your bumblebee-status package

2022-06-06 Thread Ben Westover

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.


Thanks again,
--
Ben Westover


OpenPGP_signature
Description: OpenPGP digital signature


Re: a review of your bumblebee-status package

2022-06-06 Thread Antoine Beaupré
On 2022-06-06 21:10:31, Ben Westover wrote:
> 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.

Does the package *work* at all in 3.10? We might not want to silence
real errors here...

> _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? :)

let me know when / if you need me to look at it again, and thanks again!

a.
-- 
Every time I see an adult on a bicycle I no longer despair for the
future of the human race.
 - H. G. Wells



Re: a review of your bumblebee-status package

2022-06-06 Thread Ben Westover

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.



As far as Debian is concerned, MIT and Expat are the same license > (although 
in reality MIT is a term used to describe two slightly
different licenses).
I was corrected by pabs on IRC; Debian does in fact prefer the use of 
the terms Expat and X11 to be separate and not to use the term MIT.

I was used to the way the Rust team does things, which uses MIT.

--
Ben Westover


OpenPGP_signature
Description: OpenPGP digital signature


Re: Updating pytest

2022-06-06 Thread Sandro Tosi
> > I think this page includes debci results for experimental:
> >
> > https://release.debian.org/britney/pseudo-excuses-experimental.html
> >
> > It shows what would happen when migrating experimental to unstable.
>
> Oh wow, thanks!  That's perfect.  So we can upload the new pytest to
> experimental and see what happens...

please be aware that that is a very partial view, in particular only
showing reverse dependencies with (meaningful) autopkgtests, which
means there could be hidden gigantic breakages not detected by that
page which will wreak havoc in unstable.

I would consider pytest a "core" python package, and so a complete
rdeps rebuild is appropriate, i suggest having a look at
https://salsa.debian.org/lucas/collab-qa-tools/-/blob/master/modes/numpy-exp
and then contacting Lucas to get access to the AWS rebuild machinery.

> Anyone willing to go for it?

I thought you were volunteering for it? :) jokes aside, i think
preparing the new pytest upstream release for experimental may be the
"easiest" part of this ordeal.

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Re: a review of your bumblebee-status package

2022-06-06 Thread Ben Westover

Bonjour Antoine,

I already discussed this topic with you in IRC, but I'm documenting the 
details here for the sake of the mailing list.



  * i wonder if bumblebee-status/_version.py belongs there. it's a copy
of the python3-versioneer package that's already in the
archive... could you remove it from the source and make sure we use
the Debian copy instead? at the very least the debian/copyright file
should refer to it...


_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 also attach the output of `decopy` which finds a few more things
than you in debian/copyright

  * 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.. you also seem to rebuild it in
debian/rules, but i don't see where it gets installed


I'm just following what was done upstream (except removing a prebuilt 
binary in the source that I then rebuild).


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.

One flaw I did find is that my package is marked for architecture all, 
while in reality it should be marked as any because of this C binary.



  * i did a quick read of most of the code in commit
30853fd19110c6e53be35c4bb846ab3a133b51ac and it seems sane. i haven't
reviewed the contrib modules

  * 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.




I attach a full build log.

Thanks for working on this package!

a.



anarcat@curie:bumblebee-status$ decopy
Building tree: 56dir [00:00, 2629.63dir/s]
Queueing: 739file [00:00, 1586.90file/s]
Processing: 100%|██| 683/683 [00:10<00:00, 
63.52file/s]
Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Upstream-Name: bumblebee-status
Upstream-Contact: tobi-wan-kenobi
Source: https://github.com/tobi-wan-kenobi/bumblebee-status
Files-Excluded: bin/get-kbd-layout
Comment: Removed x86_64 Linux binary with source available in the same repo

Files: *
Copyright: 2015, Marc Herndon and GPL2
2017, Oscar Svensson
2017, Oscar Svensson (wogscpar) under MIT licence from upower-python
Public Domain
License: Expat or MIT

Files: LICENSE
Copyright: 2016, tobi-wan-kenobi
License: Expat

Files: bumblebee_status/_version.py
License: public-domain

Files: debian/*
Copyright: 2022, Ben Westover 
License: MIT

License: Expat
Comment: Add the corresponding license text here

License: MIT
  Permission is hereby granted, free of charge, to any person obtaining a copy
  of this software and associated documentation files (the "Software"), to deal
  in the Software without restriction, including without limitation the rights
  to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
  copies of the Software, and to permit persons to whom the Software is
  furnished to do so, subject to the following conditions:
  .
  The above copyright notice and this permission notice shall be included in all
  copies or substantial portions of the Software.
  .
  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
  IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
  FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL THE
  AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
  LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
  OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
  SOFTWARE.

License: public-domain
Comment: Add the corresponding license text here



This autogenerated copyright file has some problems. First of all, 
LICENSE shouldn't be considered separate from the rest of the source, 
since it describes the entire source. Also, as far as Debian is 
concerned, MIT and Expat are the same license (although in reality MIT 
is a term used to describe two slightly different licenses). The 
copyright holder for * is incorrect, I don't know where it got that info 
from. It did catch _version.py, which I didn't, so I'll add that.


Merci d'avoir examiné mon paquet,
--
Ben Westover


OpenPGP_signature
Description: OpenPGP digital signature


Re: Updating pytest

2022-06-06 Thread Julian Gilbey
On Sat, Jun 04, 2022 at 10:29:53AM +0800, Paul Wise wrote:
> On Fri, 2022-06-03 at 19:08 +0100, Julian Gilbey wrote:
> 
> > I believe that ci.debian.net checks packages against packages in
> > experimental (see
> > https://ci.debian.net/packages/s/spyder/unstable/amd64/ for example),
> > so it may be that the work is already done for us; what I don't know,
> > though, is how to extract this information for the package in
> > experimental.  Perhaps worth asking the debian-ci people.
> 
> I think this page includes debci results for experimental:
> 
> https://release.debian.org/britney/pseudo-excuses-experimental.html
> 
> It shows what would happen when migrating experimental to unstable.

Oh wow, thanks!  That's perfect.  So we can upload the new pytest to
experimental and see what happens...

Anyone willing to go for it?

Best wishes,

   Julian



Bug#1012388: RFP: jupytext -- a plugin for Jupyter that can convert Jupyter notebook formats

2022-06-06 Thread Drew Parsons
Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-python@lists.debian.org

* Package name: jupytext
  Version : 1.13.8
  Upstream Author : Marc Wouts 
* URL : https://github.com/mwouts/jupytext
* License : MIT
  Programming Lang: Python
  Description : a plugin for Jupyter that can convert Jupyter notebook 
formats

Have you always wished Jupyter notebooks were plain text documents?
Wished you could edit them in your favorite IDE? And get clear and
meaningful diffs when doing version control? Then... Jupytext may well
be the tool you're looking for!

Jupytext is a plugin for Jupyter that can save Jupyter notebooks as either
- Markdown files (or MyST Markdown files, or R Markdown or Quarto text 
notebooks)
- Scripts in many languages.

The conversion goes both ways, jupytext can convert python scripts or
markdown files into .ipynb Jupyter scripts.


jupytext can help generate docs for python modules, and has started
being used in the doc workflow for some packages (e.g. dolfinx).

Best suited for team maintenance under the Python Packaging Team.