Re: Multiple package versions in PPA
On 2021-09-13 16:00 +, Francis Murtagh wrote: >Hi, > >I've added a python package called python3-pyarmnn to Debian >(https://tracker.debian.org/pkg/armnn) but also have it pushed to a Ubuntu >Launchpad PPA >(https://launchpad.net/~armnn/+archive/ubuntu/ppa/+packages). >When I push new versions of the packaging it seems to overwrite the >previous, I'm assuming this is by design as the archive should only have >one version of the software at a time. Correct. >However, this python3-pyarmnn package is just a wrapper for a C++ library >libarmnn26, 26 being its major version. >So from the PPA the user can apt install libarmnn26 or libarmnn25 etc, but >if they install python3-pyarmnn it's always the latest and so that drags >in the latest libarmnn i.e 26. Right. Normally in debian (and Ubuntu) we allow multiple versions of libraries so that things linked against the older library still work until everything is ugraded, and nothing is using the old library (then it can be removed, and often is automatically). But only one version of higher-level apps which use those libraries, normally linked against the latest library version available. What do users gain from being able to install a python3-pyarmnn linked against an older version of the library? You could do it by having python3-pyarmnn25 and python3-pyarmnn26 etc, but normally there is not enough benefit from this for it to be worth the effort. Do you just want to be able to do it for test purposes? If so you could just make multiple PPAs, and install python3-pyarmnn from the appropriate one? Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: python-django-js-asset_1.2.2-3_source.changes REJECTED
On Mon, Sep 20, 2021 at 11:21 AM Andrey Rahmatullin wrote: > On Mon, Sep 20, 2021 at 11:14:44AM -0400, Sandro Tosi wrote: > > > That's because gbp does not use pristine-tar by default, and > > > debian/gbp.conf was missing `pristine-tar=True`. Just pushed a commit to > > > fix that. > > I dont think this is the right approach: the default options to work > > on DPT packages should be in gbp default config file (or in another, > > global, config file), and not live in each and every package > > debian/gbp.conf file; > What's the mechanism to put these options there for everyone who works on > a DPT package? that's a great question! i dont think a technical solution currently exists. > Or do you mean just working with whatever is shipped with > gbp? that wont work, but there could be a solution if we request a new feature in gbp. According to man 5 gbp.conf, there is either a global configuration file, a per user file or a per repo/branch. In order to support different workflows (for different teams, f.e.), this is not sufficient. But it could work if gbp.conf supported something similar to gitconfig includeIf: in my ~/.gitconfig i have ``` [includeIf "gitdir:~/deb/"] path = ~/.gitconfig-deb ``` (~/deb is where i keep all my Debian work), and that means that if the CWD is part of the ~/deb/ tree, git will also include ~/.gitconfig-deb which contains Debian-specific configs, like the @d.o mail address. Now, we'd also need a single location to store the team-specific gbp.conf, and we already have a repo thta would fit: https://salsa.debian.org/python-team/tools/packages , which currently contains files useful to work on the entire team packages. This is useful in my specific workflow, which is suspect is rather unusual, but here how it goes: * i checked https://salsa.debian.org/python-team/tools/packages in ~/deb/python (this could be anywhere) * run ./checkout -a to checkout all team packages (or ./checkout ... for only a subset) * use `mr` (via .mcrconfig) to work on _m_ultiple _r_epositories (mr) this repo could also contain a team-specific gbp.conf file we could use. Admittedly, we probably only need a handful of options, pristine-tar = True is only one that comes to mind (be aware this file will need to be compatible with *all* repos currently in the team, so setting the debian branch etc, wont work, until all repos are uniform). I'm going to file a feature request for the includeIf-like feature for gbp Regards, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: python-django-js-asset_1.2.2-3_source.changes REJECTED
On 9/20/21 5:14 PM, Sandro Tosi wrote: >> That's because gbp does not use pristine-tar by default, and >> debian/gbp.conf was missing `pristine-tar=True`. Just pushed a commit to >> fix that. > > I dont think this is the right approach: the default options to work > on DPT packages should be in gbp default config file (or in another, > global, config file), and not live in each and every package > debian/gbp.conf file; it is already inconsistently maintained with > several packages having uncommon settings that will take precedence > over the default ones. +1 Plus gbp is just *one* out of *many* tools available. Some people just prefer to use sbuild only, for example, and that's perfectly fine. IMO it's up to the person that's using gbp to know what they are doing. FYI, I've rebuilt regularly packages from the team, I even have "pristine-tar = False" in my ~/.gbp.conf, and it's all fine... Cheers, Thomas Goirand (zigo)
Bug#994779: virtualenvwrapper: Consider upgrading to upstream release v5.0.0
Package: virtualenvwrapper Version: 4.8.4-4 Severity: wishlist X-Debbugs-Cc: deb...@microjoe.org, debian-python@lists.debian.org Dear Maintainer, According to upstream documentation [1], a new release 5.0.0 is available. Please consider upgrading the package to the latest version. Also, as a member of the Debian Python Team, I find it curious that this package is under your own workspace instead of the DPT workspace. Maybe you should consider a handover? [1] https://virtualenvwrapper.readthedocs.io/en/latest/history.html BR
Re: python-django-js-asset_1.2.2-3_source.changes REJECTED
On Mon, Sep 20, 2021 at 11:14:44AM -0400, Sandro Tosi wrote: > > That's because gbp does not use pristine-tar by default, and > > debian/gbp.conf was missing `pristine-tar=True`. Just pushed a commit to > > fix that. > I dont think this is the right approach: the default options to work > on DPT packages should be in gbp default config file (or in another, > global, config file), and not live in each and every package > debian/gbp.conf file; What's the mechanism to put these options there for everyone who works on a DPT package? Or do you mean just working with whatever is shipped with gbp? -- WBR, wRAR signature.asc Description: PGP signature
Re: python-django-js-asset_1.2.2-3_source.changes REJECTED
> That's because gbp does not use pristine-tar by default, and > debian/gbp.conf was missing `pristine-tar=True`. Just pushed a commit to > fix that. I dont think this is the right approach: the default options to work on DPT packages should be in gbp default config file (or in another, global, config file), and not live in each and every package debian/gbp.conf file; it is already inconsistently maintained with several packages having uncommon settings that will take precedence over the default ones. -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: python-django-js-asset_1.2.2-3_source.changes REJECTED
On Sun, Sep 19, 2021 at 10:56:33PM +0200, Carsten Schoenert wrote: > Hi Antonio, > > thanks for your quick feedback! > > Am 19.09.21 um 21:24 schrieb Antonio Terceiro: > > > Looking from my side, the tarball from the archive (apt source > > python-django-js-asset) and the one generated by pristine-tar are > > identical: > > > > 4b6a2c8625b8e96bbc4ff1588a27238d7d418b03 > > /tmp/python-django-js-asset_1.2.2.orig.tar.gz > > 4b6a2c8625b8e96bbc4ff1588a27238d7d418b03 > > /tmp/archive/python-django-js-asset_1.2.2.orig.tar.gz > > > > From reading the REJECT email, I think it implies that the .dsc/.changes > > you uploaded refer to an orig tarball with 6360 bytes. Do you still have > > the exact artifacts that you uploaded? > > No, not completely. > But I played around a bit with gbp and pristine-tar too and I was able to > recreate a tarball which has the same size and the same hashes as the > *.tar.gz in the archive and the one you've posted by using pristine-tar > manually. > > If I clean out all completely and build the package from scratch by gbp I > get again a wrong size and of course also different hashes. > > Currently I've no real clue why gbp is creating here different results, will > look again at this once Guido is around, I'm sure he can blame me that I'm > doing something wrong. :P That's because gbp does not use pristine-tar by default, and debian/gbp.conf was missing `pristine-tar=True`. Just pushed a commit to fix that. signature.asc Description: PGP signature
Re: Moving forward with more Python 2 removal, plus upgrading to markupsafe 2.0, jinja2 3.0, werkzeug 2.0 and flask 2.0
On 9/18/21 3:02 PM, Thomas Goirand wrote: > Dear Python Team, Dear Piotr, > > As I was packaging Cloudkitty (that is: OpenStack rating of resources, > typically used in a public cloud) for the next Xena release, I went into > this chain of dependency: > > cloudkitty: needs flask 2.0 > Flask 2.0: needs werkeug 2.0, jinja2 3.0 > jinja2: needs markupsafe 2.0 > > The thing is, markupsafe 2.0 looks like incompatible with Python 2 (when > I removed Python 2 support in the package, it built fine). > > I currently have updated markupsafe and jinja2 packages in my laptop, > (which IS removing Python 2 support). I'll soon have updates for the > other 2 (if I don't hit any blockers). > > During the python BoF of the last Debconf, we decided to go ahead with > full removal of Python 2, so doing this looks like a move to the right > direction. > > Is it fine for everyone (including Piotr, who's the only marked uploader > for these) if I upload these to Experimental right now (which is where I > am uploading OpenStack Xena), and in Unstable after the 8th of October > (when OpenStack Xena will be finally released)? > > I'm also aware that the packages I mentioned above are high profile (ie: > used a lot in Debian), which is why I thought announcing my plan was a > good idea (also so that Piotr can tell his opinion). > > Also Piotr, can I add myself as uploader for all of these? > > Your thoughts? > Cheers, > > Thomas Goirand (zigo) > > P.S: I do believe that uploading to Experimental is harmless (when we're > not in freeze), so I may go ahead before getting a reply, and we can > decide what to do together. > FYI, I went ahead with the above, and uploaded to Experimental (and also uploaded Falcon 3.0.1 too...). All went fine, however, I had to disable a dozen unit tests in werkzeug. Help to fix this would be very much appreciated. Cheers, Thomas Goirand (zigo)
Re: python-django-js-asset_1.2.2-3_source.changes REJECTED
On Sun, Sep 19, 2021 at 10:56:33PM +0200, Carsten Schoenert wrote: > Hi Antonio, > > thanks for your quick feedback! > > Am 19.09.21 um 21:24 schrieb Antonio Terceiro: > > > Looking from my side, the tarball from the archive (apt source > > python-django-js-asset) and the one generated by pristine-tar are > > identical: > > > > 4b6a2c8625b8e96bbc4ff1588a27238d7d418b03 > > /tmp/python-django-js-asset_1.2.2.orig.tar.gz > > 4b6a2c8625b8e96bbc4ff1588a27238d7d418b03 > > /tmp/archive/python-django-js-asset_1.2.2.orig.tar.gz > > > > From reading the REJECT email, I think it implies that the .dsc/.changes > > you uploaded refer to an orig tarball with 6360 bytes. Do you still have > > the exact artifacts that you uploaded? > > No, not completely. > But I played around a bit with gbp and pristine-tar too and I was able to > recreate a tarball which has the same size and the same hashes as the > *.tar.gz in the archive and the one you've posted by using pristine-tar > manually. > > If I clean out all completely and build the package from scratch by gbp I > get again a wrong size and of course also different hashes. As pristine-tar is not enabled in debian/gbp.conf you need to enable it explicitly with --git-pristine-tar each time you run a command that uses it. -- WBR, wRAR signature.asc Description: PGP signature
