Re: Sponsorship backlog

2020-02-11 Thread Jonathan Carter
Hi Utkarsh

On 2020/02/12 00:59, Utkarsh Gupta wrote:
> pyparsing: uploaded!
> python-progress: uploaded!
> python-urllib3: uploaded!
> python-nest-asyncio: uploaded!
> djangorestframework-api-key: sent reviews; had autopkgtest failure.
> 
> python-marshmallow-polyfield: was already uploaded.
> python-mongoengine: was already uploaded.
> 
> 
> Hope that helps in reducing some work.
> Also, could someone remove these from the channel list?

Thanks! I removed them from the topic.

-Jonathan
-- 
  ⢀⣴⠾⠻⢶⣦⠀  Jonathan Carter (highvoltage) 
  ⣾⠁⢠⠒⠀⣿⡁  Debian Developer - https://wiki.debian.org/highvoltage
  ⢿⡄⠘⠷⠚⠋   https://debian.org | https://jonathancarter.org
  ⠈⠳⣄  Be Bold. Be brave. Debian has got your back.



Re: python-babel

2020-02-11 Thread Håvard Flaget Aasen




On 11.02.2020 16:55, Håvard Flaget Aasen wrote:



On 11.02.2020 15:44, Thomas Goirand wrote:

On 2/11/20 11:16 AM, Håvard Flaget Aasen wrote:




I tried to build python-babel to sponsor the upload from what's in the
Git in the DPMT, and it failed to build for me:

# Generate the localedata folder data out of the xml files
# downloaded in debian/repack
scripts/import_cldr.py common
Processing root.xml (Language = root; Territory = 001)

root: Unsupported number system "adlm" in 

[... lots of lines like this one ...]


I'm also getting these lines. I tested with the current 2.6.0 which also
gives the same messages, the build log for 2.6.0 in Ubuntu prints the
same messages.

Now for the files actually being processed
It is 719 in version 2.4.0
745 in version 2.6.0 and
764 in version 2.8.0

Not that it is supposed to be this way of course. Though I do believe
the actual content in the package is correct.
I can have a look at what we are actually importing in d/repack and see
if anything has changed from version 2.4.0 to 2.8.0




root: Unsupported number system "vaii" in 

Traceback (most recent call last):
    File "scripts/import_cldr.py", line 968, in 
  main()
    File "scripts/import_cldr.py", line 193, in main
  dump_json=bool(options.dump_json)
    File "scripts/import_cldr.py", line 207, in process_data
  _process_local_datas(sup, srcdir, destdir, force=force,
dump_json=dump_json)
    File "scripts/import_cldr.py", line 435, in _process_local_datas
  write_datafile(data_filename, data, dump_json=dump_json)
    File "scripts/import_cldr.py", line 167, in write_datafile
  with open(path, 'wb') as outfile:
IOError: [Errno 2] No such file or directory:
'/<>/babel/locale-data/root.dat'


I can't replicate this. I tried with cowbuilder/pbuilder and sbuild and
the build completes fine on my systems.

Håvard



In such case, could you provide me with the source package, rather than
just letting me try with Git? Maybe this is going to work then...


Thats ok, how do you want it? the orig.tar.gz is just over 25 MB

When i try I only use git, with these commands:
$ gbp clone
$ gbp buildpackage

Håvard



I'm sorry to have wasted your time yesterday. It is indeed my system 
that does something it shouldn't.

I created a CI in salsa which duplicated your error.
I believe the repository with the pristine-tar and upstream branch is 
correct


I will fix the package today and readd it on IRC when it's done.

I was able to reproduce the error on my own system with
$ dpkg-buildpackage -us -ui

Håvard



Re: How to find DD member to perform reviews and uploads

2020-02-11 Thread Adam Cecile
Hello Utkarsh,

I fixed the changelog issue, sadly salsa is unresponsive atm so I it's not 
pushed yet.

For the autodep8 issue I know what is going on:
For some reasons Django packages, especially Django REST Fmwrk does not follow 
standard naming scheme so expected package import name is not correct.

Can you help me understanding how to fix this properly ?

Regards, Adam.

Le 11 février 2020 23:09:43 GMT+01:00, Utkarsh Gupta  a 
écrit :
>Hi Adam,
>
>On Sun, Feb 9, 2020 at 9:13 AM Adam Cecile  wrote:
>>
>https://salsa.debian.org/python-team/modules/djangorestframework-api-key
>
>Could you quickly update d/ch entry date?
>timewarp-standards-version (2020-01-06 < 2020-01-20) -> 4.5.0 was
>released afterwards :)
>
>Also, there's an autopkgtest failure :(
>Here's how you can reproduce:
>autopkgtest -B ../*.deb -- schroot unstable-amd64-sbuild
>
>Relevant logs:
>Testing with python3.8:
>Traceback (most recent call last):
>  File "", line 1, in 
>ModuleNotFoundError: No module named 'djangorestframework_api_key'
>
>Let me know once you fix them, I'll be happy to upload! :)
>
>
>Best,
>Utkarsh


Re: Sponsorship backlog

2020-02-11 Thread Utkarsh Gupta
Hi all,

On Mon, Feb 10, 2020 at 4:23 AM Jonathan Carter  wrote:
> The sponsorship request queue in the IRC topic is getting a bit long
> again, I'll try to make time for as many of these as possible this week,
> but if anyone can help reviewing these packages from the IRC topic (and
> then removing them) then that would be great:
>
> python-babel, gpxpy, pyparsing, python-progress, python-urllib3,
> geoalchemy2, python-marshmallow-polyfield, python-mongoengine,
> python-nest-asyncio, djangorestframework-api-key, aionotify,
> python-fastjsonschema, python-cassandra-driver

>From my end, I've processed some of these:

pyparsing: uploaded!
python-progress: uploaded!
python-urllib3: uploaded!
python-nest-asyncio: uploaded!
djangorestframework-api-key: sent reviews; had autopkgtest failure.

python-marshmallow-polyfield: was already uploaded.
python-mongoengine: was already uploaded.


Hope that helps in reducing some work.
Also, could someone remove these from the channel list?


Best,
Utkarsh



Re: How to find DD member to perform reviews and uploads

2020-02-11 Thread Utkarsh Gupta
Hi Adam,

On Sun, Feb 9, 2020 at 9:13 AM Adam Cecile  wrote:
> https://salsa.debian.org/python-team/modules/djangorestframework-api-key

Could you quickly update d/ch entry date?
timewarp-standards-version (2020-01-06 < 2020-01-20) -> 4.5.0 was
released afterwards :)

Also, there's an autopkgtest failure :(
Here's how you can reproduce:
autopkgtest -B ../*.deb -- schroot unstable-amd64-sbuild

Relevant logs:
Testing with python3.8:
Traceback (most recent call last):
  File "", line 1, in 
ModuleNotFoundError: No module named 'djangorestframework_api_key'

Let me know once you fix them, I'll be happy to upload! :)


Best,
Utkarsh



Re: python-babel

2020-02-11 Thread Thomas Goirand
On 2/11/20 4:45 PM, Sandro Tosi wrote:
>> In such case, could you provide me with the source package, rather than
>> just letting me try with Git? Maybe this is going to work then...
> 
> whatever turns out to be, please ensure the package is buildable from
> the git repo. and matches what's going to be uploaded. We have already
> enough packages with missing pristine-tar deltas, with orig tarballs
> that dont match what's in the upstream+pristine-tar output, let's not
> increase that number.
> 
> Thanks,

Sure, we're on the same page. The purpose is just to diagnose what's
going on, and fix it the Git repo!

Cheers,

Thomas



Re: How to find DD member to perform reviews and uploads

2020-02-11 Thread Adam Cecile

On 2/11/20 9:45 PM, Thomas Goirand wrote:

On 2/11/20 12:12 PM, Ondrej Novy wrote:

Hi,

út 11. 2. 2020 v 11:02 odesílatel Adam Cecile mailto:acec...@le-vert.net>> napsal:

 Bringing the package into the archive would be doable, if someone get
 legal contacts at LSI and asked for official statement authorizing
 Debian to redistribute their binary. I did this in the past for another
 package but I cannot guarantee any success.


be careful with this. See DFSG 8 :)

This is irrelevant. We're discussing uploading something into non-free,
and as you know, non-free is not part of Debian, and the DFSG doesn't
apply there.

Cheers,

Thomas Goirand (zigo)


Btw Thomas, python-cassandra has been fixed and ready for uploading if 
you're still interested in.


Adam.



Re: How to find DD member to perform reviews and uploads

2020-02-11 Thread Thomas Goirand
On 2/11/20 12:12 PM, Ondrej Novy wrote:
> Hi,
> 
> út 11. 2. 2020 v 11:02 odesílatel Adam Cecile  > napsal:
> 
> Bringing the package into the archive would be doable, if someone get
> legal contacts at LSI and asked for official statement authorizing
> Debian to redistribute their binary. I did this in the past for another
> package but I cannot guarantee any success.
> 
> 
> be careful with this. See DFSG 8 :)

This is irrelevant. We're discussing uploading something into non-free,
and as you know, non-free is not part of Debian, and the DFSG doesn't
apply there.

Cheers,

Thomas Goirand (zigo)



Re: Force pushing on salsa?

2020-02-11 Thread Mattia Rizzolo
On Tue, Feb 11, 2020 at 11:34:23AM -0500, Louis-Philippe Véronneau wrote:
> Looking at a package recently, I saw some important mistakes and I was
> wondering: would it be ok to force push to fix them?
> 
> More explicitly, the import of the new upstream version with
> pristine-tar contains a bunch of errors due to a wrong manipulation. It
> seems to me it would be "more clean" to start again and force push.
> 
> I know force pushing is normally frowned upon when working in a team
> environment, but I haven't seen any mention of it in the Python Team's
> policy.

Let me keep frowing deeply.

If pristine-tar data is corrupted, just use
% pristine-tar commit ../foo_1.2.3.orig.tar.xz upstream/1.2.3
to update the data, without force-pushing.  It's just one extra commit,
so why would that be "less clean"?!


The only thing I could *very frowingly* accept, is force-pushing a tag
because you are doing it again.  Having said that, I usually just append
a number if I need to re-repack again an upstream tarball (+dfsg1,
+dfsg2, etc).  But you mentioned only pristine-tar, so I suppose that's
not your case.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature


Force pushing on salsa?

2020-02-11 Thread Louis-Philippe Véronneau
Hey folks,

Looking at a package recently, I saw some important mistakes and I was
wondering: would it be ok to force push to fix them?

More explicitly, the import of the new upstream version with
pristine-tar contains a bunch of errors due to a wrong manipulation. It
seems to me it would be "more clean" to start again and force push.

I know force pushing is normally frowned upon when working in a team
environment, but I haven't seen any mention of it in the Python Team's
policy.

Happy to know what folks think of this. If there is a strong consensus,
maybe we should add something to the policy.

Cheers,

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature


Re: python-babel

2020-02-11 Thread Håvard Flaget Aasen




On 11.02.2020 15:44, Thomas Goirand wrote:

On 2/11/20 11:16 AM, Håvard Flaget Aasen wrote:




I tried to build python-babel to sponsor the upload from what's in the
Git in the DPMT, and it failed to build for me:

# Generate the localedata folder data out of the xml files
# downloaded in debian/repack
scripts/import_cldr.py common
Processing root.xml (Language = root; Territory = 001)

root: Unsupported number system "adlm" in 

[... lots of lines like this one ...]


I'm also getting these lines. I tested with the current 2.6.0 which also
gives the same messages, the build log for 2.6.0 in Ubuntu prints the
same messages.

Now for the files actually being processed
It is 719 in version 2.4.0
745 in version 2.6.0 and
764 in version 2.8.0

Not that it is supposed to be this way of course. Though I do believe
the actual content in the package is correct.
I can have a look at what we are actually importing in d/repack and see
if anything has changed from version 2.4.0 to 2.8.0




root: Unsupported number system "vaii" in 

Traceback (most recent call last):
    File "scripts/import_cldr.py", line 968, in 
  main()
    File "scripts/import_cldr.py", line 193, in main
  dump_json=bool(options.dump_json)
    File "scripts/import_cldr.py", line 207, in process_data
  _process_local_datas(sup, srcdir, destdir, force=force,
dump_json=dump_json)
    File "scripts/import_cldr.py", line 435, in _process_local_datas
  write_datafile(data_filename, data, dump_json=dump_json)
    File "scripts/import_cldr.py", line 167, in write_datafile
  with open(path, 'wb') as outfile:
IOError: [Errno 2] No such file or directory:
'/<>/babel/locale-data/root.dat'


I can't replicate this. I tried with cowbuilder/pbuilder and sbuild and
the build completes fine on my systems.

Håvard



In such case, could you provide me with the source package, rather than
just letting me try with Git? Maybe this is going to work then...


Thats ok, how do you want it? the orig.tar.gz is just over 25 MB

When i try I only use git, with these commands:
$ gbp clone
$ gbp buildpackage

Håvard



Re: python-babel

2020-02-11 Thread Sandro Tosi
> In such case, could you provide me with the source package, rather than
> just letting me try with Git? Maybe this is going to work then...

whatever turns out to be, please ensure the package is buildable from
the git repo. and matches what's going to be uploaded. We have already
enough packages with missing pristine-tar deltas, with orig tarballs
that dont match what's in the upstream+pristine-tar output, let's not
increase that number.

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



Re: python-babel

2020-02-11 Thread Thomas Goirand
On 2/11/20 11:16 AM, Håvard Flaget Aasen wrote:
> 
>>
>> I tried to build python-babel to sponsor the upload from what's in the
>> Git in the DPMT, and it failed to build for me:
>>
>> # Generate the localedata folder data out of the xml files
>> # downloaded in debian/repack
>> scripts/import_cldr.py common
>> Processing root.xml (Language = root; Territory = 001)
>>
>> root: Unsupported number system "adlm" in 
>>
>> [... lots of lines like this one ...]
> 
> I'm also getting these lines. I tested with the current 2.6.0 which also
> gives the same messages, the build log for 2.6.0 in Ubuntu prints the
> same messages.
> 
> Now for the files actually being processed
> It is 719 in version 2.4.0
> 745 in version 2.6.0 and
> 764 in version 2.8.0
> 
> Not that it is supposed to be this way of course. Though I do believe
> the actual content in the package is correct.
> I can have a look at what we are actually importing in d/repack and see
> if anything has changed from version 2.4.0 to 2.8.0
> 
> 
>>
>> root: Unsupported number system "vaii" in > numberSystem="vaii">
>>
>> Traceback (most recent call last):
>>    File "scripts/import_cldr.py", line 968, in 
>>  main()
>>    File "scripts/import_cldr.py", line 193, in main
>>  dump_json=bool(options.dump_json)
>>    File "scripts/import_cldr.py", line 207, in process_data
>>  _process_local_datas(sup, srcdir, destdir, force=force,
>> dump_json=dump_json)
>>    File "scripts/import_cldr.py", line 435, in _process_local_datas
>>  write_datafile(data_filename, data, dump_json=dump_json)
>>    File "scripts/import_cldr.py", line 167, in write_datafile
>>  with open(path, 'wb') as outfile:
>> IOError: [Errno 2] No such file or directory:
>> '/<>/babel/locale-data/root.dat'
>>
> I can't replicate this. I tried with cowbuilder/pbuilder and sbuild and
> the build completes fine on my systems.
> 
> Håvard


In such case, could you provide me with the source package, rather than
just letting me try with Git? Maybe this is going to work then...

FYI, I'm just using plain sbuild with git-buildpackage.

Cheers,

Thomas Goirand (zigo)



I'd like to Join the DPMT

2020-02-11 Thread Sam Hartman

Hi.
I've read the DPMT policy and accept it.

I find I end up packaging python modules regularly for work and  I could
just as easily upload the results to Debian when they are of sufficient
quality.
In this instance, I want a newer version of hvac (which is stuck in
new).
since I'm starting with the salsa repo, I wanted to be able to
contribute the results back, and  doing an upstream change based on
merge requests sounded messy.


signature.asc
Description: PGP signature


Re: python-babel

2020-02-11 Thread Håvard Flaget Aasen





I tried to build python-babel to sponsor the upload from what's in the
Git in the DPMT, and it failed to build for me:

# Generate the localedata folder data out of the xml files
# downloaded in debian/repack
scripts/import_cldr.py common
Processing root.xml (Language = root; Territory = 001)

root: Unsupported number system "adlm" in 

[... lots of lines like this one ...]


I'm also getting these lines. I tested with the current 2.6.0 which also 
gives the same messages, the build log for 2.6.0 in Ubuntu prints the 
same messages.


Now for the files actually being processed
It is 719 in version 2.4.0
745 in version 2.6.0 and
764 in version 2.8.0

Not that it is supposed to be this way of course. Though I do believe 
the actual content in the package is correct.

I can have a look at what we are actually importing in d/repack and see
if anything has changed from version 2.4.0 to 2.8.0


I believe this is the upstream change. [1]
If it indeed are files were supposed to have in the package i guess it 
need some more work, if not we could either leave it as is, or comment 
out the log line.


Håvard

[1] 
https://github.com/python-babel/babel/commit/77dc9d4024b78c2339f7cf3bff1a2e8be8e2d0f7#diff-106585574531c31ab48c6bf45e566e40




Re: python-babel

2020-02-11 Thread Jonathan Carter
On 2020/02/11 12:16, Håvard Flaget Aasen wrote:
> I can't replicate this. I tried with cowbuilder/pbuilder and sbuild and
> the build completes fine on my systems.

Ok, thanks. I'll check on a chroot on my system later too to try to see
what's going on, but swamped at the moment so can't check right now.

-Jonathan

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Jonathan Carter (highvoltage) 
  ⣾⠁⢠⠒⠀⣿⡁  Debian Developer - https://wiki.debian.org/highvoltage
  ⢿⡄⠘⠷⠚⠋   https://debian.org | https://jonathancarter.org
  ⠈⠳⣄  Be Bold. Be brave. Debian has got your back.



Re: python-babel

2020-02-11 Thread Håvard Flaget Aasen





I tried to build python-babel to sponsor the upload from what's in the
Git in the DPMT, and it failed to build for me:

# Generate the localedata folder data out of the xml files
# downloaded in debian/repack
scripts/import_cldr.py common
Processing root.xml (Language = root; Territory = 001)

root: Unsupported number system "adlm" in 

[... lots of lines like this one ...]


I'm also getting these lines. I tested with the current 2.6.0 which also 
gives the same messages, the build log for 2.6.0 in Ubuntu prints the 
same messages.


Now for the files actually being processed
It is 719 in version 2.4.0
745 in version 2.6.0 and
764 in version 2.8.0

Not that it is supposed to be this way of course. Though I do believe 
the actual content in the package is correct.

I can have a look at what we are actually importing in d/repack and see
if anything has changed from version 2.4.0 to 2.8.0




root: Unsupported number system "vaii" in 

Traceback (most recent call last):
   File "scripts/import_cldr.py", line 968, in 
 main()
   File "scripts/import_cldr.py", line 193, in main
 dump_json=bool(options.dump_json)
   File "scripts/import_cldr.py", line 207, in process_data
 _process_local_datas(sup, srcdir, destdir, force=force,
dump_json=dump_json)
   File "scripts/import_cldr.py", line 435, in _process_local_datas
 write_datafile(data_filename, data, dump_json=dump_json)
   File "scripts/import_cldr.py", line 167, in write_datafile
 with open(path, 'wb') as outfile:
IOError: [Errno 2] No such file or directory:
'/<>/babel/locale-data/root.dat'

I can't replicate this. I tried with cowbuilder/pbuilder and sbuild and 
the build completes fine on my systems.


Håvard



Re: How to find DD member to perform reviews and uploads

2020-02-11 Thread Adam Cecile

On 2/11/20 9:51 AM, Thomas Goirand wrote:

On 2/9/20 3:12 PM, Adam Cecile wrote:

Hello Debian-Python,


I have a couple of package ready on Salsa but my RFS sent here remained
unanswered.

So I'm asking again for your help again ! Here is a list of package
waiting for uploads:


https://salsa.debian.org/python-team/modules/djangorestframework-api-key

https://salsa.debian.org/python-team/modules/aionotify

https://salsa.debian.org/python-team/modules/python-fastjsonschema

https://salsa.debian.org/python-team/modules/python-cassandra-driver

https://salsa.debian.org/python-team/modules/python-sunrise


Thanks in advance,


Regards, Adam.

Hi Adam,

I've built and uploaded python-cassandra-driver. Thanks for your
contribution to Debian. Do you still need sponsoring for the above?

Also, thanks a lot for your work on megacli packaging, it's very useful.
However, I haven't found the matching source packages. Do you also think
it'd be possible to push these into the non-free repository of Debian?
Do you even have some sources from upstream, or only binaries? I very
much need this for my work (we use Dell LSI hardware RAID a lot), and my
colleagues would love to have this through the official channel, rather
than from your unofficial repository. Your thoughts?

Cheers,

Thomas Goirand (zigo)


Hello Thomas,

It seems the package got rejected because I'm building an additional 
package (doc one). Anyway, please wait a bit I'll fix a couple of minor 
issues spotted by Onovy and we'll ask for an uploaded again.


I'll also need sponsorship for others package but just like cassandra, 
I'll fix a few things first.



Regarding megacli, no sources it's 100% proprietary tool from LSI and 
the license clearly state it's forbidden to redistribute by 3rd parties. 
But the hwraid repo is kinda popular and I never got any complaint by 
LSI because I think they understood it's useful and needed by their users.


Bringing the package into the archive would be doable, if someone get 
legal contacts at LSI and asked for official statement authorizing 
Debian to redistribute their binary. I did this in the past for another 
package but I cannot guarantee any success.


I got a few contacts with LSI people and they have been helpful, in an 
unofficial way but I'm not sure it'll be the same for a public statement.



Regards, Adam.



Re: Separate lib and executable packages?

2020-02-11 Thread Gordon Ball
On Sat, Feb 08, 2020 at 08:54:27PM +0100, Ondrej Novy wrote:
> Hi,
> 
> so 8. 2. 2020 v 20:51 odesílatel Gordon Ball  napsal:
> 
> > Perhaps this is worth making an explicit recommendation for new packages
> > of this type, given that anything new _should_ be python3-only and we
> >
> 
> and what about pypy- prefix?

That's a good point.

Probably not many packages are likely to provide pypy{,3} invoking binaries
(ipython is probably actually a good candidate here) and so it probably
counts as an exceptional case which can reasonably bypass a recommendation.

I suppose you could:

 * Not ship any executables which invoke pypy. For pypy3, that appears
   to be the case today (nothing in /usr/bin using pypy3 except the
   interpreter itself).
 * Ship the library and python3 executable together (possibly with a
   Provides: for the executable), and the pypy3 executable in a
   separate package (since the library itself presumably
   doesn't want to depend on pypy3, and might need to depend on
   pypy-specific library packages). This saves 1 binary package but
   seems inconsistent. The actual implementation could be picked with
   update-alternatives.
 * Ship library, python3 executable and pypy3 executable separately.
   This seems more consistent but generates an extra binary package.

This is probably a good case to consider in this thread because ipython
and ipykernel are probably reasonable cases where a pypy-specialised
executable might make sense, and ipython at least depends only on
pure-python modules which work out-of-the-box with pypy.

> 
> -- 
> Best regards
>  Ondřej Nový



Re: python-babel

2020-02-11 Thread Jonathan Carter
Hi Håvard

On 2020/02/11 10:33, Thomas Goirand wrote:
> I tried to build python-babel to sponsor the upload from what's in the
> Git in the DPMT, and it failed to build for me:

I'm removing it from the channel topic in the meantime, please re-add
when the building is resolved, thanks for your contribution!

-Jonathan

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Jonathan Carter (highvoltage) 
  ⣾⠁⢠⠒⠀⣿⡁  Debian Developer - https://wiki.debian.org/highvoltage
  ⢿⡄⠘⠷⠚⠋   https://debian.org | https://jonathancarter.org
  ⠈⠳⣄  Be Bold. Be brave. Debian has got your back.



Re: How to find DD member to perform reviews and uploads

2020-02-11 Thread Thomas Goirand
On 2/9/20 3:12 PM, Adam Cecile wrote:
> Hello Debian-Python,
> 
> 
> I have a couple of package ready on Salsa but my RFS sent here remained
> unanswered.
> 
> So I'm asking again for your help again ! Here is a list of package
> waiting for uploads:
> 
> 
> https://salsa.debian.org/python-team/modules/djangorestframework-api-key
> 
> https://salsa.debian.org/python-team/modules/aionotify
> 
> https://salsa.debian.org/python-team/modules/python-fastjsonschema
> 
> https://salsa.debian.org/python-team/modules/python-cassandra-driver
> 
> https://salsa.debian.org/python-team/modules/python-sunrise
> 
> 
> Thanks in advance,
> 
> 
> Regards, Adam.

Hi Adam,

I've built and uploaded python-cassandra-driver. Thanks for your
contribution to Debian. Do you still need sponsoring for the above?

Also, thanks a lot for your work on megacli packaging, it's very useful.
However, I haven't found the matching source packages. Do you also think
it'd be possible to push these into the non-free repository of Debian?
Do you even have some sources from upstream, or only binaries? I very
much need this for my work (we use Dell LSI hardware RAID a lot), and my
colleagues would love to have this through the official channel, rather
than from your unofficial repository. Your thoughts?

Cheers,

Thomas Goirand (zigo)



Re: python-babel

2020-02-11 Thread Thomas Goirand
On 1/10/20 8:50 PM, Håvard Flaget Aasen wrote:
> Hello,
> 
> The python-babel [1] package is currently broken, there isn't any bugs
> reported yet, but after the transit to
> python3.8 it failed the testsuite. New upstream version 2.7.0 and above
> fixes these issues.
> To update the package there is a 'repack' script which i believe is
> broken, I at least did most of the work
> manually. For that reason I haven't dared push it to the official repo
> yet, if anyone have time, it will be nice
> with a second opinion. It's still some work left, but it builds and
> tests fine. The version I updated is currently here [2]
> 
> The script might only require a minor fix but i noticed that the files
> being downloaded already exist
> within Debian. The package unicode-cldr-core [3].
> Is it possible to have this as a build-dependency, have a Files-Excluded
> in d/copyright file and
> drop the repack script altogether? If there still is a reason to change
> the files in the first place.
> If this makes it any easier/better of course.
> 
> I'll appreciate all kinds of feedback.
> 
> 
> Håvard
> 
> 
> [1] https://tracker.debian.org/pkg/python-babel
> [2] https://salsa.debian.org/haava-guest/python-babel
> [3] https://tracker.debian.org/pkg/unicode-cldr-core
> 

Hi,

I tried to build python-babel to sponsor the upload from what's in the
Git in the DPMT, and it failed to build for me:

# Generate the localedata folder data out of the xml files
# downloaded in debian/repack
scripts/import_cldr.py common
Processing root.xml (Language = root; Territory = 001)

root: Unsupported number system "adlm" in 

[... lots of lines like this one ...]

root: Unsupported number system "vaii" in 

Traceback (most recent call last):
  File "scripts/import_cldr.py", line 968, in 
main()
  File "scripts/import_cldr.py", line 193, in main
dump_json=bool(options.dump_json)
  File "scripts/import_cldr.py", line 207, in process_data
_process_local_datas(sup, srcdir, destdir, force=force,
dump_json=dump_json)
  File "scripts/import_cldr.py", line 435, in _process_local_datas
write_datafile(data_filename, data, dump_json=dump_json)
  File "scripts/import_cldr.py", line 167, in write_datafile
with open(path, 'wb') as outfile:
IOError: [Errno 2] No such file or directory:
'/<>/babel/locale-data/root.dat'

Can you fix this?

Cheers,

Thomas Goirand (zigo)