Re: New upstream version for python-pint

[Antonio Valentino]

forgot the link

[3] https://wiki.debian.org/DebianMaintainer#Granting_Permissions

cheers

Il 31/03/24 21:05, Antonio Valentino ha scritto:

Dear Thomas,

Il 30/03/24 22:25, Thomas Goirand ha scritto:

On 3/29/24 15:13, Antonio Valentino wrote:

Dear Thomas and Ondřej,
a couple of packages that I maintain are impacted by an RC bug in 
python-pint (#1067318).
I think that an update to the to the latest pint version 0.23 should 
be sufficient to fix the issue.


If you agree, I would like prepare the package for the new upstream 
version in the salsa.

Of course I will let to you the review and upload.

Please let me know,


kind regards


Please go ahead and feel free to add yourself as uploader.

Thomas


Thanks Thomas
The packages is now updated in salsa.
Unfortunately the reprotest job fails in CI, but I'm not able to 
reproduce on my laptop and it seems not to be a regression.
I will try to fix it in future uploads but for the moment I would prefer 
to have an upload to fix a couple of RC bugs.


Could you please review and upload?

I have also put myself as uploader.
I'm a DM so I kindly ask you to grant me upload permissions as described 
in [3].



kind regards


--
Antonio Valentino

Re: New upstream version for python-pint

[Antonio Valentino]

Dear Thomas,

Il 30/03/24 22:25, Thomas Goirand ha scritto:

On 3/29/24 15:13, Antonio Valentino wrote:

Dear Thomas and Ondřej,
a couple of packages that I maintain are impacted by an RC bug in 
python-pint (#1067318).
I think that an update to the to the latest pint version 0.23 should 
be sufficient to fix the issue.


If you agree, I would like prepare the package for the new upstream 
version in the salsa.

Of course I will let to you the review and upload.

Please let me know,


kind regards


Please go ahead and feel free to add yourself as uploader.

Thomas


Thanks Thomas
The packages is now updated in salsa.
Unfortunately the reprotest job fails in CI, but I'm not able to 
reproduce on my laptop and it seems not to be a regression.
I will try to fix it in future uploads but for the moment I would prefer 
to have an upload to fix a couple of RC bugs.


Could you please review and upload?

I have also put myself as uploader.
I'm a DM so I kindly ask you to grant me upload permissions as described 
in [3].



kind regards
--
Antonio Valentino

Re: Uscan: watch and changelog

[Paul Boddie]

On Sunday, 31 March 2024 15:31:36 CEST c.bu...@posteo.jp wrote:
> 
> Don't write and explain such things in emails. Save your time and
> resources. Write it into the wiki just one time and then you can link
> to it. You wrote it. I won't copy and paste your stuff. Ladies and
> Gentlemen please do edit your own wiki pages yourself. You are the
> experts here. I am not.

I agree broadly with these sentiments.

> This attitude is also one of the reasons why the wiki is in such a bad
> shape.

I somewhat agree with this, although it is actually why documentation is in 
such bad shape across the entire industry, not just the Debian Wiki. However, 
I sympathise with developers that there are only so many hours in the day, 
too, and that they are often tasked with getting working code out of the door, 
condemning supposedly optional activities like testing and documentation to 
perennial neglect.

I sympathise less with the school of development where everything is thrown 
over the side, redone with little benefit to everyone, and then the developers 
claim that they didn't have time to document anything, not least because they 
are about to go through the same performance all over again.

> Otherwise just delete the whole wiki. That would be an increase in
> the quality of Debians documentation. In its current state it is
> embarrassing and it harms the project called Debian.

I don't agree and I am evidently not the only one. There have been situations 
where the only usable documentation I could find was in the Debian Wiki.

> Debian is not a hobby. Doing FOSS shouldn't be an excuse for not taking
> responsibility.

Well, it should be more than a hobby, and it is indeed a job for some people. 
To upgrade it from hobby to job involves money, and that would definitely be 
an incentive for people to "take responsibility". Otherwise, nobody should 
believe that they can set people's work priorities: that is the job of the 
boss in an actual employment relationship.

> I tried. But it seems I am the only person caring for new contributors
> and how the read documentation. I am tortured with man pages and links
> to out dated documentation (e.g. "New maintainers guide").

I certainly care about it. Did you find my previous message about uscan 
helpful? I don't maintain any of these tools, but I am willing to share my 
experiences in order to evolve a reasonable consensus about how these tools 
might be used, eventually providing concise, usable documentation that would 
help newcomers quickly become productive.

> The situation is not healthy to me. So I need to stop from here with
> fixing other peoples documentation.

I think that you can make a difference, so don't stop trying to do something 
about it.

Paul

Re: Uscan: watch and changelog

[Michael Stehmann]

Hello.

Am 31.03.24 um 15:31 schrieb c.bu...@posteo.jp:


Otherwise just delete the whole wiki. That would be an increase in
the quality of Debians documentation. In its current state it is
embarrassing and it harms the project called Debian.


Do you really think, deleting for example this pages

https://wiki.debian.org/Teams
https://wiki.debian.org/Teams/PythonTeam

would be an improvement in documentation?

The quality of Debian documantion is improvable; but the Debian project 
is a do-ocracy [0]


Kind regards
Michael

[0] https://de.wikipedia.org/w/index.php?title=Do-ocracy=206673492 
(sorry, there is no english version)

Re: Uscan: watch and changelog

[c.buhtz]

Dear Soren,

my primary intention is always to improve Debian. That also involves a
better image to the public and potential new users and contributors.

On 2024-03-29 13:42 Soren Stoutner  wrote:
> Much of Debian’s documentation is not written for people
> who are new to the topic, but for people who already know the
> information and just want to be reminded about some of the tricky
> parts.

That kind of "documentation" is called a "reference". You point to one
of the problems of the Debian Wiki and other Debian documents. They are
often not focused enough to one purpose and/or target group. It is
often not clear to readers what the purpose and target group of a
specific wiki page or document is. And especially in a Wiki there are
too many authors not following any design rules except their own way of
thinking. Sometimes to much freedom is not healthy. A "head of docu"
person or institution watching the quality is missing in Debian.

I am aware of . But it seems they
don't have the power in Debian to establish rules about documentation
quality. And even there own wiki team page has much potential for
improvement.

> Anything you can do to improve the documentation would be greatly
> appreciated.

No, no, no! Sorry. I tried to give a polite hint in my previous mail
but it seems it did not reach you.

Don't write and explain such things in emails. Save your time and
resources. Write it into the wiki just one time and then you can link
to it. You wrote it. I won't copy and paste your stuff. Ladies and
Gentlemen please do edit your own wiki pages yourself. You are the
experts here. I am not.

This attitude is also one of the reasons why the wiki is in such a bad
shape.

Otherwise just delete the whole wiki. That would be an increase in
the quality of Debians documentation. In its current state it is
embarrassing and it harms the project called Debian.

Debian is not a hobby. Doing FOSS shouldn't be an excuse for not taking
responsibility.

I tried. But it seems I am the only person caring for new contributors
and how the read documentation. I am tortured with man pages and links
to out dated documentation (e.g. "New maintainers guide").

The situation is not healthy to me. So I need to stop from here with
fixing other peoples documentation.

Best,
Christian Buhtz

Re: morph's abandoned packages (list)

[Julian Gilbey]

On Sun, Mar 31, 2024 at 02:16:39PM +0200, tho...@goirand.fr wrote:
> The bug is about the --pristine-tar option of bgp...
>>   It turns out that doing pristine-tar by hand often gives different
>>   results, as I discovered:
>>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065445

Yes, indeed; the original poster was talking about using pristine-tar
by hand rather than using the --pristine-tar option of gbp.

Best wishes,

   Julian

Re: morph's abandoned packages (list)

[thomas]

The bug is about the --pristine-tar option of bgp... 


Sent from Workspace ONE Boxer 


On Mar 31, 2024 1:58 PM, Julian Gilbey  wrote:

On Sat, Mar 30, 2024 at 10:21:06PM +0100, Thomas Goirand wrote: 
> [...] 
> > [0]: https://wiki.debian.org/Python/GitPackaging#Creating_a_new_package 
> > [1]: https://wiki.debian.org/Python/GitPackaging#New_upstream_release 
> I would not do this way, but use gbp import-orig instead. I'm not sure why 
> the wiki recommends, IMO wrongly, to do things by hand. Indeed, all of this: 

It turns out that doing pristine-tar by hand often gives different 
results, as I discovered: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065445 

So I don't know what best to recommend, personally.  Anyway, once this 
bug is fixed, definitely using gbp import-orig is the way to go (and 
probably even before it is). 

Best wishes, 

   Julian 

Re: Seeking a small group to package Apache Arrow (was: Bug#970021: RFP: apache-arrow -- cross-language development platform for in-memory analytics)

[Dirk Eddelbuettel]

Julian,

Arrow is a complicated and large package. We use it at work (where there is a
fair amount of Python, also to Conda etc) and do have issues with more
complex builds especially because it is 'data infrastructure' and can come in
from different parts. I would recommend against packaging at old one -- we
also have seen issues with different (py)arrow version biting.

Have you seen https://github.com/apache/arrow-nanoarrow ?

It works via the C API to Arrow which interchanges data via two void* to the
the two structs for arrow array and schema -- and avoids linkage issue. (In
user space the pyarrow or R arrow packages can still be used also interfacing
via these.)  I have been using it for R package bindings for some time and we
plan to expand that (again, at work) -- as do others. It is already use by
duckdb, by the Arrow 'ADBC' interfaces (which are generic in the ODBC/JDBC
sense but for Arrow, and also by a python interface to snowflake.

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Re: morph's abandoned packages (list)

[Julian Gilbey]

On Sat, Mar 30, 2024 at 10:21:06PM +0100, Thomas Goirand wrote:
> [...]
> > [0]: https://wiki.debian.org/Python/GitPackaging#Creating_a_new_package
> > [1]: https://wiki.debian.org/Python/GitPackaging#New_upstream_release
> I would not do this way, but use gbp import-orig instead. I'm not sure why
> the wiki recommends, IMO wrongly, to do things by hand. Indeed, all of this:

It turns out that doing pristine-tar by hand often gives different
results, as I discovered:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065445

So I don't know what best to recommend, personally.  Anyway, once this
bug is fixed, definitely using gbp import-orig is the way to go (and
probably even before it is).

Best wishes,

   Julian

Re: Seeking a small group to package Apache Arrow (was: Bug#970021: RFP: apache-arrow -- cross-language development platform for in-memory analytics)

[Julian Gilbey]

Hi Diane,

On Sat, Mar 30, 2024 at 08:59:39PM -0700, Diane Trout wrote:
> Hi Julian,
> 
> On Sat, 2024-03-30 at 20:22 +, Julian Gilbey wrote:
> > Lovely to hear from you, and oh wow, that's amazing, thank you!
> > 
> > I can't speak for anyone else, but I suggest that pushing your
> > updates
> > to the science-team package would be very sensible; it would be silly
> > for someone else to have to redo your work.
> > 
> > What more is needed for it to be ready for unstable?
> 
> 
> The things I think are kind of broken are:
> 
> We've got 7.0.0 and upstreams current version is 15.0.2.

Yes, that does seem a little less than ideal!

> the pyarrow 7.0.0 tests fail because it depends on a python test
> library that breaks with pytest 8.0. Either I need to disable the
> python tests or upgrade to a newer version.

It may well be that newer versions would work with pytest 8.x.  I
don't think it's worth spending time trying to patch such a relatively
old version.

> My upgrade didn't go smoothly because uscan found also upstreams debian
> watch file which is too loose and matches some other tar balls on their
> distribution site.
> 
> (Though I don't know why uscan keeps looking for watch files after
> finding one in debian/watch)

Oh dear.  uscan(1) does say:

   Unless --watchfile is given, uscan looks recursively for valid source
   trees starting from the current directory (see the below section
   "Directory name checking" for details).

and then:

   For each valid source tree found, typically the following happens:
   [...]

so yes, it will look at more than one location.

> And you were probably right in that arrow needs to be a team, because I
> have no idea how to get other the other languages interfaces packaged.

I suggest that without anyone else volunteering to do those other
language interfaces (perhaps it's not a pressing need for people
working with language X), I wonder whether it's worth just packaging
the Python (and presumably C++) interfaces for now, and then if others
want to join the effort to support language X later on, a new version
of the Debian package can be uploaded with a new binary package for
language X.  It does mean more trips through the NEW queue if and when
that happens, but given that no-one's shown interest in language X for
the last several years, this is unlikely to be much of an issue.

Version 7.0 provided support (it seems) for: GLib (seems that a draft
framework for building this is already in the Debian package, and it
can then be used in lots of languages), C++ (this is the core
libraries), C# (not of interest to us), Go, Java, JavaScript, Julia,
Matlab (not of interest to us), Python, R, Ruby.

> Oh and I probably need to get the pyarrow installed somewhere, since it
> was stopping at the tests I hadn't run into dh_missing errors yet.

Oh.  Would pybuild do that automatically (perhaps specifying
PYBUILD_PACKAGE)?

Best wishes,

   Julian

Team join request

[Vivek K J]

Hey,

I would like to join debian-python team for helping in maintaining some
python packages. I've got experience in maintaining packages in ruby and
JS teams. For now, I would like to update pmbootstrap package for fixing
#1065637.

My salsa login: vivekkj

I've read python-team policy, and I'm ready to follow all the guidelines.

-- 
Regards,

Vivek K J
Debian Maintainer
---
 .''`.
Personal Website:  https://vivekkj.in   : :'  :
GPG Key: D017 9263 E202 0E40 7157  4073 A5FF 4BB3 EA53 C5DF `. `'`
  `-

OpenPGP_0xA5FF4BB3EA53C5DF.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature