Re: why does python3-dulwich depend on python3-dbg?
On Sat, 17 Sep 2022 16:46:15 -0400 Marvin Renich wrote: > [I am not subscribed; Reply-To set to the list and me.] > > Can someone explain why python3-dulwich newly depends on python3-dbg? > This seems counter-intuitive to me for a package for a production > module to depend on a debug interpreter. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019278 The package has had a build-dependency on python3-all-dbg for some 5 years or more - now waiting for an upload to unstable. See also https://lists.debian.org/debian-python/2021/09/msg00004.html -- Neil Williams li...@codehelp.co.uk https://linux.codehelp.co.uk pgp_w2NRs_PqA.pgp Description: OpenPGP digital signature
Re: dxtbx pytest issue
and maxshape != ():
> raise TypeError(f"{shapetype} datasets cannot be
> extended") return h5p.create(h5p.DATASET_CREATE)
>
> def rq_tuple(tpl, name):
> """ Check if chunks/maxshape match dataset rank """
> if tpl in (None, True):
> return
> try:
> tpl = tuple(tpl)
> except TypeError:
> raise TypeError('"%s" argument must be None or a
> sequence object' % name) if len(tpl) != len(shape):
> raise ValueError('"%s" must have same rank as dataset
> shape' % name)
> rq_tuple(chunks, 'chunks')
> rq_tuple(maxshape, 'maxshape')
>
> if compression is not None:
> if isinstance(compression, FilterRefBase):
> compression_opts = compression.filter_options
> compression = compression.filter_id
>
> if compression not in encode and not
> isinstance(compression, int): raise ValueError('Compression filter
> "%s" is unavailable' % compression)
> if compression == 'gzip':
> if compression_opts is None:
> gzip_level = DEFAULT_GZIP
> elif compression_opts in range(10):
> gzip_level = compression_opts
> else:
> raise ValueError("GZIP setting must be an integer
> from 0-9, not %r" % compression_opts)
> elif compression == 'lzf':
> if compression_opts is not None:
> raise ValueError("LZF compression filter accepts
> no options")
> elif compression == 'szip':
> if compression_opts is None:
> compression_opts = DEFAULT_SZIP
>
> err = "SZIP options must be a 2-tuple ('ec'|'nn',
> even integer 0-32)" try:
> szmethod, szpix = compression_opts
> except TypeError:
> raise TypeError(err)
> if szmethod not in ('ec', 'nn'):
> raise ValueError(err)
> if not (0 raise ValueError(err)
>
> elif compression_opts is not None:
> # Can't specify just compression_opts by itself.
> raise TypeError("Compression method must be specified")
>
> if scaleoffset is not None:
> # scaleoffset must be an integer when it is not None or
> False, # except for integral data, for which scaleoffset == True is
> # permissible (will use SO_INT_MINBITS_DEFAULT)
>
> if scaleoffset < 0:
> raise ValueError('scale factor must be >= 0')
>
> if dtype.kind == 'f':
> if scaleoffset is True:
> raise ValueError('integer scaleoffset must be
> provided for ' 'floating point types')
> elif dtype.kind in ('u', 'i'):
> if scaleoffset is True:
> scaleoffset = h5z.SO_INT_MINBITS_DEFAULT
> else:
> raise TypeError('scale/offset filter only supported
> for integer ' 'and floating-point types')
>
> # Scale/offset following fletcher32 in the filter chain
> will (almost?) # always triggers a read error, as most scale/offset
> settings are # lossy. Since fletcher32 must come first (see comment
> below) we # simply prohibit the combination of fletcher32 and
> scale/offset. if fletcher32:
> raise ValueError('fletcher32 cannot be used with
> potentially lossy' ' scale/offset filter')
>
> external = _normalize_external(external)
> # End argument validation
>
> if (chunks is True) or \
> (chunks is None and any((shuffle, fletcher32, compression,
> maxshape, scaleoffset is not None))):
> chunks = guess_chunk(shape, maxshape, dtype.itemsize)
>
> if maxshape is True:
> maxshape = (None,)*len(shape)
>
> if chunks is not None:
> plist.set_chunk(chunks)
> plist.set_fill_time(h5d.FILL_TIME_ALLOC) # prevent
> resize glitch
> # scale-offset must come before shuffle and compression
> if scaleoffset is not None:
> if dtype.kind in ('u', 'i'):
> pli
Re: PYTHONPATH with cmake build
On Tue, 30 Aug 2022 19:02:24 +0200 (CEST) PICCA Frederic-Emmanuel wrote: > > /usr/share/perl5/Debian/Debhelper/Buildsystem.pm to be just > > "obj-$DEB_HOST_GNU_TYPE". > > > Thanks for the info, if I an not wrong during the build process we > can setup a new builddir. So is is possible to obtain the real > builddir during the build ? PYTHONPATH can be a relative path, there is no need to try to identify the full build path (that can introduce reproducibility issues). No need to force a change to the build dir either. So just obj-$DEB_HOST_GNU_TYPE -- Neil Williams li...@codehelp.co.uk https://linux.codehelp.co.uk pgpby3iw0Kq0m.pgp Description: OpenPGP digital signature
Re: Proposed MBF: packages still using nose
On Sun, 21 Aug 2022 16:04:36 +0300
Dmitry Shachnev wrote:
> Hi,
>
> nose [1] is a testing framework for Python, which is dead and
> unmaintained since 2015 [2][3].
>
> The former maintainer of nose recommends projects using nose to
> switch to nose2 [4], pytest [5] or unittest from Python standard
> library [6]. There is a script called nose2pytest [7] which can
> assist with migrating from nose to pytest.
xraylarch (U)
Fixed in git.
--
Neil Williams
=
https://linux.codehelp.co.uk/
pgpQG2Ls59DSX.pgp
Description: OpenPGP digital signature
Updating pytest-django
A new version of https://tracker.debian.org/pkg/python-model-bakery is available but it cannot be uploaded as the tests fail with the pytest-django 3.* series. https://github.com/model-bakers/model_bakery/issues/311 The new upstream will need pytest-django >= 4.5.2 With pytest itself updated and python3-django in bookworm now at 3.2, is it OK to update pytest-django to the v4.* series? https://salsa.debian.org/python-team/packages/pytest-django -- Neil Williams = https://linux.codehelp.co.uk/ pgp222z0eJUkR.pgp Description: OpenPGP digital signature
Re: List of packages of Python team that have no autopkgtest
On Tue, 19 Jul 2022 07:59:12 +0200 Andreas Tille wrote: > Hi Zigo, > > you asked me for a list of packages without autopkgtest sorted by > popcon value as we create it for Debian Med team also for Python > team. I've simply added it to the Debian Med dir for simplicity - > feel free to take over the code (or suggest some better place). Here > ist the list > > > https://salsa.debian.org/med-team/community/helper-scripts/-/blob/master/python-team-tests.txt > > which is created by the script I'm using for Debian Med and Debian > Science[1]. It will be refreshed by a daily cron job. It seems to be a list of source packages, yet it contains duplicates (pelican appears twice, for example, as does python-git). autopkgtest is source-package based, so can this be fixed? Maybe take the highest popcon of all binaries from each single source package? -- Neil Williams li...@codehelp.co.uk https://linux.codehelp.co.uk pgpYRfN0O26zZ.pgp Description: OpenPGP digital signature
Re: Need a hand with tiledb-python
On Tue, 10 May 2022 06:13:33 -0500 Dirk Eddelbuettel wrote: > Hi all, > > I look after the 'tiledb' (a C++ library) package and the 'tiledb-r' > package. I also effectively maintain 'tiledb-python' but I am running > into some issues there. I do know a little bit of Python and have > (co-)maintained two or three packages there for decades but this one > stumps me. > > Larger context is that that upstream is fairly heavy user of Conda > and used to a lot of explicit version pinning. First, I would strongly recommend enabling Salsa CI - helps those trying to help you by having public build logs etc.. Also, use the lintian-brush package (against a git clone in a SID chroot/vm) to trim out some of the versions listed in the build-dependencies. (Debian BD don't need to refer to versions not in the archive, so a straight copy from setup.py isn't useful.) I've now done a number of packages where upstream rely on Conda. There is no simple solution - the best option is to aggressively patch out the key conditionals which determine how Conda support interferes with Debian packaging & patch out the overly strict version handling. New support in pybuild may help your specific package but I've found it easier to patch in a setup.py as that makes it more straightforward to support a backport to buster. Depends on your needs. The specific packages tend to also use SCons which complicates things further - there isn't a direct example in my list. > This creates issues > for us here as the build wants to leave the chroot/pbuilder to match > those pins. Adam (CC'ed) who set this up initially already patched > some calls out (for example sphinx docs are now local). The > 'delicate' bit is that I actually work at TileDB ;-) and don't want > to have a fight over the upstream choice (so I didn't bug my > colleague yet). Upstream use is upstream use, but Debian packaging > also has its rules. Patches do not have to go upstream when the changes are to make the package work in Debian instead of Conda. > > The packaging is at >https://salsa.debian.org/python-team/packages/tiledb-py > (and for historical reasons I also have one at >https://salsa.debian.org/edd/tiledb-py > which it is behind) and I would *really* appreciate it if someone > could take a look. I tried patching requirements_dev.txt and > misc/requirements_wheel.txt but am apparently out of my depth here. I > reached out to Adam (CC'ed) but he is busy too. We all know how it > goes. > > Please CC me on follow-ups as I am not subscribed to debian-python. > > Thanks, Dirk > > -- > dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > -- Neil Williams = https://linux.codehelp.co.uk/ pgpvHAbmhG5rk.pgp Description: OpenPGP digital signature
Re: Reaching team consensus on usage of py3versions -r and X-Python3-Version in Lintian
On Mon, 17 Jan 2022 12:47:44 -0500 Louis-Philippe Véronneau wrote: > Hey folks, > > I'm following up on bug #1001677 [1] on the DPT's list to try to reach > consensus, as I think the Lintian tags that were created to fix this > bug are not recommending the proper thing. > > As a TL;DR for those of you who don't want to read the whole BTS > thread, jdg saw that a bunch of packages were using `py3versions -r` > in autopkgtests, and this fails when there's no X-Python3-Version > variable in d/control. > > The fix that Lintian now proposes for packages that use `py3versions > -r` in autopkgtests is to set X-Python3-Version. > > I think the proper fix would be to ask people to move away from > `py3versions -r` if there is no X-Python3-Version, and use`py3versions > -s` instead. Just as a general point, can I ask that - especially in a TL;DR - that long option names are used or the context of each option is included as the difference between -r and -s is not obvious from this email & not everyone on the list uses py3versions routinely. -- Neil Williams = https://linux.codehelp.co.uk/ pgp6eGTQw_JDx.pgp Description: OpenPGP digital signature
Re: keyman-config is marked for autoremoval from testing
On Tue, 28 Sep 2021 17:06:01 +0200 Eberhard Beilharz wrote: > Hi, > > I got the email below which I don't understand. /keyman-config/ > doesn't have any -dbg packages AFAICT. keyman-config build-depends on a package which depends on python-gevent (likely python3-gi). As the bug title describes, it is python-gevent which is affected and which has the -dbg package that needs to be removed. https://packages.debian.org/unstable/python3-gevent-dbg > So - what do I have to do? Nothing. You are being notified in case your own scripts or systems expect to install keyman-config from testing - at some point, that may fail - depending on when python-gevent is fixed. Once python-gevent is uploaded with a fix for the bug, packages which were removed from testing due to the bug will migrate back into testing automatically. > Thanks, > Eberhard > > > Forwarded Message > Subject: keyman-config is marked for autoremoval from testing > Date: Fri, 24 Sep 2021 04:39:32 + > From: Debian testing autoremoval watch > To: > keyman-con...@packages.debian.org > > > > keyman-config 14.0.280-1 is marked for autoremoval from testing on > 2021-10-29 > > It (build-)depends on packages with these RC bugs: > 994354: python-gevent: Removal of the python3-*-dbg packages in > sid/bookworm https://bugs.debian.org/994354 > > > > This mail is generated by: > https://salsa.debian.org/release-team/release-tools/-/blob/master/mailer/mail_autoremovals.pl > > Autoremoval data is generated by: > https://salsa.debian.org/qa/udd/-/blob/master/udd/testing_autoremovals_gatherer.pl -- Neil Williams = https://linux.codehelp.co.uk/ pgp8Yat8bh8Vg.pgp Description: OpenPGP digital signature
Re: xlsxwriter: How to change homepage url
On Wed, 15 Sep 2021 11:58:24 + wrote: > Hello, > > this is about the "xlsxwriter" package [1] and this one year old bug > report about defect "homepage" url [2]. > > I am new in the neighborhood and think this is a good issue to learn > something about the Debian internals. > > So where does the "homepage" url in the "link" box on the right side > of the tracker page comes from. And how can I fix it? https://tracker.debian.org/media/packages/x/xlsxwriter/control-1.1.2-0.2 The package does not seem to have a current version control repository. That would be a good start. There doesn't seem to be a project in salsa.debian.org and it would make things a lot easier when asking for help with packaging changes, to have a URL in Salsa. > Or is it extracted from the meta data of the last package and only a > new package can fix this? > > btw: I am not sure if this list is the right place. But the DPMT is > named as "uploaders" of that package. And I am confused about that the > "maintainer" is a ubuntu-list (Team?). Yes, checkbox-devel - you should at least introduce yourself there. https://lists.ubuntu.com/mailman/listinfo/Checkbox-devel See also https://mentors.debian.net/ - a lot of help and information for people who are new to packaging. -- Neil Williams = https://linux.codehelp.co.uk/ pgpyt9PtnctT5.pgp Description: OpenPGP digital signature
Re: Bug#943666: python3: Update Python Policy for removal of the Python 2 stack
On Sun, 3 Nov 2019 15:00:17 +0100 Matthias Klose wrote: > [discussing this outside the bug report on the ML] > > On 03.11.19 14:39, Neil Williams wrote: > > Actually, that's a good catch. I was mixing up the defaults package > > with the general advice on python3 migration to not remove > > python-foo-doc just to rename it to python3-foo-doc. > > where did you read that? IMO we don't want to rename the -doc > packages. https://wiki.debian.org/Python/2Removal Check list * if documentation was in python-foo - move it to python3-foo or python-foo-doc * if it was automatically placed there by dh_installdocs, it will automatically move to python-foo-doc: you don't need to do anything, unless you had links to it that need un-breaking * do not remove python-foo-doc or rename it to python3-foo-doc > > > Removing the defaults package python-doc seems right to me. I've > > updated that paragraph. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpofohEowY0B.pgp Description: OpenPGP digital signature
Bug#943666: python3: Update Python Policy for removal of the Python 2 stack
Package: python3 Version: 3.7.5-1 Severity: normal As discussed on IRC and alongside the post to debian-devel-announce, please review and include this amendment to the Debian Python Policy to cover the removal of the Python 2 stack as outlined at https://wiki.debian.org/Python/2Removal https://salsa.debian.org/codehelp/python3-defaults/commit/9b1dabbdc7105486e8a2132a100066e4c225a874 Thanks.
Re: Raising severity to serious for some Python 2 leaf packages with no Python 3 support upstream
On Mon, 14 Oct 2019 20:22:40 +0200 Gregor Riepl wrote: > Oh, and by the way, I just saw this: > https://github.com/kovidgoyal/calibre/blob/master/README.python3 > > Perhaps a working Py3 port is not so far off after all. > Then it can be introduced as a new upload when it is ready. It's not ready for release from upstream yet, so it doesn't affect the decision to raise an RC bug against calibre in current testing. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpbb7BZVbZZO.pgp Description: OpenPGP digital signature
Re: Raising severity to serious for some Python 2 leaf packages with no Python 3 support upstream
til a viable Py3 fork of > Calibre is available, or someone steps up and writes Py3 > compatibility patches without dropping Py2 support? This here seems > like a good starting to achieve what Calibre's author wants: > https://github.com/plone/Products.CMFPlone/issues/2184#issuecomment-359445243 > > Though, in the long run, somebody will have to convince Kovid that > writing Py3 code is worthwhile... Or take over maintenance. Again, nothing to do with raising the severity of the bug to RC. Calibre is nothing special - it's a Python2 leaf package like vland and tftpy and any one of far too many others. It should be removed from testing on the basis that a Python3 version is not forthcoming and there are dependencies which will be able to drop their Python2 support (or be removed from Debian entirely) once calibre is no longer considered in the rm-python2 transition due it to not being present in testing. Calibre can stay in unstable - it will go FTBFS, of course, but that isn't a problem either, IMHO. It's calibre's problem - not Debian's problem. There's always the option of users installing the old Python2 stuff from Buster to keep calibre hobbling along. Debian is the higher priority here. Calibre would be a nice to have but it does not deserve to cause delays on anybody else's voluntary effort. No package has that right. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgp4uIyKpHi9l.pgp Description: OpenPGP digital signature
Re: Raising severity to serious for some Python 2 leaf packages with no Python 3 support upstream
On Sun, Oct 13, 2019 at 11:41:38PM -0400, Nicholas D Steeves wrote: > Hi Thomas and Python Team, > > Thomas Goirand writes: > > > For example, today I looked into removing Python 2 from python-cogent. > > Running sixer on all files lead to a huge log of problems to solve by > > hand. There's no upstream support for Python 3 on that one. > > > > For this kind of package, I see no way out except: > > - Upstream works on Python 3 support > > - Someone in Debian makes the effort > > > > But in both cases, it's going to take a very long time. Do we really > > want to get stuck on these packages for like forever, or would it feel > > ok to raise the severity to serious, so that the package gets > > auto-removed and then we can work on removing Python 2 from its > > dependencies? > > It seems to me that a fair and conservative solution is to send an > announcement once a month that all Python 2 packages will have an RC bug > filed against them on 1 January 2020. I work on the Calibre package, > and depend on it for my daily work. I do not believe that its reverse > deps should be removed before 1 Jan 2020. That doesn't mean that the rest of Debian should be held up by your personal usage. It is trivial for you to arrange a local build and even a local repo to meet your local needs. The package does not need to be in the archive blocking other people's work just because you personally need it. Calibre is not a special case. If that logic was applied everywhere, nothing would ever get done. It's a shame, for me, that lava and associated packages have already been removed from testing as I used to work on those. I changed jobs, changed workspace and no longer have time to get the remaining (small) issues fixed to keep the packages in testing and the remaining team have made their own choices on how to publish new releases due to the reduced team size. I could make the same argument as you about tftpy but I've put my personal situation into the bug report and if I don't get time to fix it, then tftpy will need to be removed from testing. There have been enough conservative notifications and announcements about Python2 from every organisation with even the most remote connection to Python. I think all Python2 bugs should be escalated to RC to have automatic removal from unstable and testing at the earliest opportunity. As of now, calibre is not of sufficient quality to be part of a Debian release and until it drops all Python2 requirements, it must be considered RC buggy. Accept that there has already been enough time for announcements, put the current status - as you see it - into the bug report and raise the severity to RC yourself. That's my recommendation for Calibre and all the other leaf packages with any dependency on Python2. There has already been enough time for delay. > As far as the maximum number of announcements, how about: the first > announcement ASAP, the second one 1 Nov, then 1 Dec. Lets CC this > announcement to devel, -python, -med, and any other teams with a > significant number of Python packages. > > The issue is similar to global warming. People will hide their head in > the sand singing "nah nah nah, it's not real, I don't have to deal with > it" until a tipping point occurs. That tipping point has already been reached. The Python2 removal transition is in full flow and has been since DebConf. No more delays. > > Honestly part of me wonders if RedHat/IBM is going to maintain Python 2, > like they did with Java. > > > https://developers.redhat.com/blog/2018/09/24/the-future-of-java-and-openjdk-updates-without-oracle-support > > Barring that hypothetical possibility, I still think the right thing to > do is file RC bugs the 1 of January. What happens then? My guess is > upstreams start containerising their py2 software and someone will write > a helper script like py2-zombie-flatpack. > > > Cheers, > Nicholas
Re: py2-rm: a few leaf packages to work on
On Thu, 15 Aug 2019 14:08:41 +0200 Thomas Goirand wrote: > Hi there! > > According to the daily graph I built here: > http://py2graph.infomaniak.ch/py2.7.deps.svg > > we can work on Python 2 removal for the below packages. How is that graph turned into a list of packages? It's too large to scan manually. I'm attaching a sorted list of the packages you mentioned in the first email but I can't see how to update the list from the graph. I'm trying to work out what links to python-tftpy or whether it merely links to others (and why, because the package itself doesn't declare any dependencies except python2 and I can't find rdepends in apt-cache). It's not included in the list output, so I'm confused. https://packages.debian.org/unstable/python-tftpy Context: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784028#10 0.8.0 has Python3 support but packaging it is more work than it probably deserves, unless there is some reason to keep the package. > Note that I > have *not* checked for reverse dependencies, please do so before > working on a package. The list isn't exhaustive at all, and didn't > check if a package is just a remaining curft, though it's hopefully > still helpful as a TODO list. > > Cheers, > > Thomas Goirand (zigo) > -- Neil Williams = http://www.linux.codehelp.co.uk/ py2.yaml Description: application/yaml pgpOJQyyl6HJu.pgp Description: OpenPGP digital signature
Re: Removing python2 packages
On Wed, 24 Jul 2019 12:08:54 -0400 (EDT) Scott Talbert wrote: > On Tue, 23 Jul 2019, Ondrej Novy wrote: > > > út 23. 7. 2019 v 11:40 odesílatel Scott Talbert > > napsal: When removing leaf python2 packages for bullseye, is there > > anything > > > > > > __modules__ package :) > > > > special that needs to be done, other than removing the > > building of the > > python2 subpackage? > > > > For example, obsoleting of the old package or anything along > > those lines? > > > > > > * check reverse-depends and "reverse-depends -b" > > * remove from d/control > > * remove from d/tests > > * remove from d/rules > > * check/remove d/python-* files > > * test > > * upload > > Thanks. The reason I asked about 'obsoleting' is because I wondered > about what will happen on the upgrade case. Say, I remove python-foo > from bullseye. When a user running buster with python-foo installed > upgrades to bullseye, what will happen? Will apt try to remove > python-foo? Not unless something actually Breaks: or Conflicts: or the user runs autoremove. If a leaf package bar changes from Depends: python-foo to python3-foo, then python-foo will remain installed. There are lots of packages in Stretch that are not in Buster. Upgrading leaves them in place unless there is something which actively Conflicts: or Breaks: them. That's why autoremove is so useful after dist-upgrade. > > Scott -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpjaUC4ltKPU.pgp Description: OpenPGP digital signature
Re: Removing python2 packages
On Tue, 23 Jul 2019 10:40:29 -0400 (EDT) Scott Talbert wrote: > When removing leaf python2 packages for bullseye, is there anything > special that needs to be done, other than removing the building of > the python2 subpackage? > > For example, obsoleting of the old package or anything along those > lines? Obsoleting would infer that the Python2 version hangs around in some way. That would defeat the object somewhat. Most leaf packages will be binaries, so the binary can just change to Python3. If there's a Python2 module or other support package, just drop it. Put an entry in NEWS if you think people may have out-of-distro scripts using the Python2 module. Otherwise, a note in README.Debian or just debian/changelog is probably enough. It's fairly obvious when a Python leaf binary moves to Python3 support. As long it continues to work, most users aren't going to even notice. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpzUYLNoBm9B.pgp Description: OpenPGP digital signature
Re: Example of packaged Django web application
On Thu, 2 May 2019 12:12:47 +0200 Olivier wrote: > Hello, > > I've read this [1] document but it doesn't include any example yet. > > 1. Do you know any Django application that is already packaged for > either Stretch or Buster ? https://tracker.debian.org/pkg/lava is one. The problem is that this is much, much more than a Django application. The lava-server package contains & deploys a web UI from a set of django apps configured together. Questions about that package are best sent upstream: https://git.lavasoftware.org/lava/pkg-lava-debian You may get more examples this way: $ apt-cache rdepends python3-django|grep -v python3 Reverse Depends: freedombox lava-server graphite-web dicoweb autoradio > 2. How about adding in this Wiki page, a link to this example ? For the reasons above, the lava-server package isn't the easiest to parse. I'm not aware of a hello-world type django package. The one listed on the draft page was subsequently turned into lava-server but then has been refactored several times and expanded in multiple directions. > [1] https://wiki.debian.org/DjangoPackagingDraft The page itself is very old - 6 years with the Draft suffix and plenty of TODO items. It mentions south migrations which don't happen anymore with django from stretch or buster. The whole page is badly out of date. I don't know if any of the above packages ever looked at the draft during packaging. I know that the lava-server package no longer follows that draft in any meaningful manner. The page is still tied in with changes to Django from django 1.2 to 1.3. The best thing for this page might be that it gets deleted or at least edited to have a warning that it is horribly out of date. > Best regards -- Neil Williams = http://www.linux.codehelp.co.uk/ pgp155khBwqDc.pgp Description: OpenPGP digital signature
Re: AttributeError: module 'socket' has no attribute 'timeout'
On Thu, 25 Apr 2019 10:04:46 +0300
Artem Golubev wrote:
> Hello, I’m using python3.5, python3.7 on Debian 9 stretch
Simply rename the script and delete any socket.pyc file in the same
directory.
* Do not name your script using the name of a module that you will be
importing:
> File "/root/python/projects/test/socket.py", line 7, in
That should be .../test/socket-test.py or socket-script.py
anything except the name of the module you will be importing from
elsewhere.
> This is my code:
The code itself is fine.
>
> ———-
> import socket
>
> host = 'google.com’
The quotation marks here were mangled by your email client but once
that is fixed, the code works fine.
> port = 80
>
> try:
> sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
> sock.settimeout(0.1)
> result = sock.connect_ex((host, port))
> if result == 0:
> print('Port is UP')
> else:
> print('Port is DOWN')
> except socket.timeout as e:
> print(e)
> ——
>
>
> When I execute my code I receive this error
>
> ***
> Traceback (most recent call last):
> File "/root/python/projects/test/socket.py", line 7, in
> sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
> AttributeError: module 'socket' has no attribute 'AF_INET'
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
> File "socket.py", line 1, in
> import socket
> File "/root/python/projects/test/socket.py", line 14, in
> except socket.timeout as e:
> AttributeError: module 'socket' has no attribute 'timeout'
> **
> recently everything worked fine, but some time ago this error
> appeared. And on other OS (Ubuntu, FreeBSD), the code works without
> errors. Please help:) sorry for my English
>
> --
> С уважением,
> Артём
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpeyyBbeV99W.pgp
Description: OpenPGP digital signature
Re: packaging django-rest-framework-filters
On Thu, 29 Nov 2018 11:41:40 +0100 Thomas Goirand wrote: > On 11/28/18 5:51 PM, Neil Williams wrote: > > I'd expect at least python3-django to be in that list. Could be an > > upstream bug in their setup.py > > From my experience, it's always best to explicitly express the > dependencies manually and not rely on upstream setup.py to do things > correctly. Often, it doesn't. That does have the weakness that if there are changes in the version requirements, those won't get picked up as easily, adding to the maintenance workload. I do think it's worth reporting such issues to upstream. (I'd certainly want it reported for the projects where I am part of upstream.) -- Neil Williams h...@codehelp.co.uk pgpKUf4xiTJ08.pgp Description: OpenPGP digital signature
Re: packaging django-rest-framework-filters
On Wed, 28 Nov 2018 14:38:20 + Wookey wrote: > On 2018-11-28 08:58 +0000, Neil Williams wrote: > > On Mon, 26 Nov 2018 04:05:05 + > > Wookey wrote: > > > > > On 2018-11-22 08:59 +0100, Thomas Goirand wrote: > > > > On 11/22/18 6:02 AM, Wookey wrote: > > > > > > I guess djangorestframework-filters is > > > clearer, and closer to upstream so people can find it. I'll go > > > with that unless someone says the drf-* names are a better plan. > > > > > > OK. I've made a new package (djangorestframework-filters), which > > > seems OK. (actually I've made 2 (see below)) > > > > > > I'm not a member of the modules team, so can't follow the > > > instructions to make a salsa project under the python-team banner > > > (https://wiki.debian.org/Python/GitPackaging) > > > > > > I'll put it under wookey for now. > > > > > > Also, the latest release is 0.10.0.post0, which says it's > > > compatible with: > > > * **Python**: 2.7 or 3.3+ > > > * **Django**: 1.8, 1.9, 1.10, 1.11 > > > * **DRF**: 3.5, 3.6 > > > > djangorestframework lists "Breaking changes" in the release notes > > for 3.8, so this looks like an incompatibility with what's already > > in Debian. > > > > https://github.com/encode/django-rest-framework/releases/tag/3.8.0 > > > > It might be worth testing whether 0.10.0.post0 or another release of > > django-rest-framework-filters between that and 1.0.0dev0 is actually > > fine with djangorestframework 3.8 - at least at a unit test level. > > Milosz and I are doing just that. > > It would be great if you could check whether these packages work OK > with lava or not as that's at least one datapoint: > http://wookware.org/software/repo/pool/main/d/drf-extensions/python3-djangorestframework-extensions_0.4.0-1_all.deb A bit surprised to see that this binary only depends on: Depends: python3-djangorestframework, python3:any I'd expect at least python3-django to be in that list. Could be an upstream bug in their setup.py - relying only on the indirect dependency via python3-djangorestframework is a bit odd/lazy to me. The package does directly import modules from django, it doesn't exclusively import from django-restframework, not least in it's own settings.py. > http://wookware.org/software/repo/pool/main/d/djangorestframework-filters/python3-djangorestframework-filters_0.10.2.post0-1_all.deb For comparison: Depends: python3-django, python3-django-filters, python3-djangorestframework, python3:any So I can install both of those packages ok on buster, I can run the existing LAVA unit tests without failures and I can browse the localhost LAVA UI (including REST API) with those installed. However, that only a minimal datapoint - the REST API doesn't yet have code to use the support available from these packages. It's basically only an install test, not execution. I've successfully imported the modules into the django developer shell using lava-server manage.py shell, so that bit works too. If there are particular tests that would be useful, let me know. > > > However the version of DRF in testing is now 3.8, and python 3.6 > > > so perhaps it's better to upload the upcoming v1.0.0.dev0: > > > * **Python**: 3.4, 3.5, 3.6 > > > * **Django**: 1.11, 2.0, 2.1b1 > > > * **DRF**: 3.8 > > > * **django-filter**: 2.0 > > > > > > But the version of django-filter in debian is 1.1.0, so at first > > > glance neither of these versions will work with the components > > > available. > > > > > > I'd normally upload the last released version, i.e. 0.10.2.post0, > > > but I'm not sure how these interactions with versions of > > > djangorestframework and django-filter work. Any advice or shall I > > > work this out with upstreams? > > > > django-filters has a new upstream 2.0 but a migration guide has been > > published for that: > > > > https://django-filter.readthedocs.io/en/master/guide/migration.html#migrating-to-2-0 > > > > Cheers for that link > > > So it's likely that at least some reverse dependencies would be > > broken by django-filters version 2.0. > > As you say - if we have to go to django-filters 2.0, then things > probably get complicated (too complicated for buster). > > Wookey > -- > Principal hats: Linaro, Debian, Wookware, ARM > http://wookware.org/ -- Neil Williams h...@codehelp.co.uk pgpU0Tf_qkLds.pgp Description: OpenPGP digital signature
Re: packaging django-rest-framework-filters
On Mon, 26 Nov 2018 04:05:05 + Wookey wrote: > On 2018-11-22 08:59 +0100, Thomas Goirand wrote: > > On 11/22/18 6:02 AM, Wookey wrote: > > I guess djangorestframework-filters is > clearer, and closer to upstream so people can find it. I'll go with > that unless someone says the drf-* names are a better plan. > > OK. I've made a new package (djangorestframework-filters), which > seems OK. (actually I've made 2 (see below)) > > I'm not a member of the modules team, so can't follow the instructions > to make a salsa project under the python-team banner > (https://wiki.debian.org/Python/GitPackaging) > > I'll put it under wookey for now. > > Also, the latest release is 0.10.0.post0, which says it's compatible > with: > * **Python**: 2.7 or 3.3+ > * **Django**: 1.8, 1.9, 1.10, 1.11 > * **DRF**: 3.5, 3.6 djangorestframework lists "Breaking changes" in the release notes for 3.8, so this looks like an incompatibility with what's already in Debian. https://github.com/encode/django-rest-framework/releases/tag/3.8.0 It might be worth testing whether 0.10.0.post0 or another release of django-rest-framework-filters between that and 1.0.0dev0 is actually fine with djangorestframework 3.8 - at least at a unit test level. > However the version of DRF in testing is now 3.8, and python 3.6 so > perhaps it's better to upload the upcoming v1.0.0.dev0: > * **Python**: 3.4, 3.5, 3.6 > * **Django**: 1.11, 2.0, 2.1b1 > * **DRF**: 3.8 > * **django-filter**: 2.0 > > But the version of django-filter in debian is 1.1.0, so at first > glance neither of these versions will work with the components > available. > > I'd normally upload the last released version, i.e. 0.10.2.post0, but > I'm not sure how these interactions with versions of > djangorestframework and django-filter work. Any advice or shall I work > this out with upstreams? django-filters has a new upstream 2.0 but a migration guide has been published for that: https://django-filter.readthedocs.io/en/master/guide/migration.html#migrating-to-2-0 So it's likely that at least some reverse dependencies would be broken by django-filters version 2.0. $ apt-cache rdepends python3-django-filters python3-django-filters Reverse Depends: python3-djangorestframework python3-djangorestframework-gis python3-djangorestframework python3-djangorestframework-gis It may be too late to get things like this untangled before the buster release. Dabbling with django-filters 2.0 now could end up causing removal of packages which work just fine with the current set. Looks to me like django-filters 2.0 needs to be handled in bullseye. -- Neil Williams h...@codehelp.co.uk pgp6s2uJupV1j.pgp Description: OpenPGP digital signature
PAPT: join request
I'd like to join PAPT to maintain black. My login on salsa.debian.org is codehelp. I have read https://salsa.debian.org/python-team/tools/python-apps/blob/master/policy.rst and I accept it. Does black have to use pristine-tar for PAPT? -- Neil Williams h...@codehelp.co.uk pgptqu8rxtLyf.pgp Description: OpenPGP digital signature
