Re: python-mkdocs new version coordination
Otto Kekäläinen writes: > Are you OK that I upload a new python-mkdocs version together with > Ahmed (CCd)? Fine with me, I haven't had a lot of time for Debian lately. -- Brian May @ Debian
Re: Wiki: Setup the environment, e.g. "salsa" script / Request to review modified docs
Andreas Tille writes: > As someone who touched a lot of packages (>2000) I've always used quilt > successfully and have seen quilt patches used by the majority of all > those packages. This is not only true for DPT than generally in Debian. > Considering quilt as not recommended is definitely not matching the > reality and should not be written in Wiki. gbp pq is just another way of quilt patches. The debian/patches written by gbp pq are compatable with quilt. The patches written to by quilt can be read using gbp pq import. While gbp pq has a patch queue stored in git, you probably don't want to push this to a shared repo. But: If you create patches with quilt, and then import and export them using gbp pq you might find that gbp pq wants to make minor/trivial changes to the unchanged patch files. Which can be irritating when making security patches, etc. Maybe this is why the practise is not recommended? -- Brian May @ Debian
Re: Enabling salsa-ci on all Debian Python Team repos
Emanuele Rocca writes: > What's wrong with pushing your work before uploading to ftp-master > instead? :-) I am learning to do this with my packages. Because otherwise, when I push to get, I often find I forgot to do a pull beforehand, and there are changes in salsa that are not reflected in my upload I just did, and as I result I have a bit of a mess to try and resolve. But still, I need to remember to do it in this order. Normal solution would be to get the CI to upload the new changes automatically, but I imagine there are going to be problems here regarding control of the GPG key required to sign that changes file. -- Brian May https://linuxpenguins.xyz/brian/
Re: Re: Challenges packaging Python for a Linux distro - at Python Language Summit
Jeremy Stanley writes: > For software development work, I compile my own Python interpreters > and libraries, because I need to develop against a variety of > different versions of these, sometimes in chroots, to be able to > target other distros and releases thereof. I keep all these in my > homedir or otherwise outside of normal system-wide installation > paths. Bear in mind that this isn't just a Debian problem, for > decades Red Hat has also advised programmers not to rely on their > /usr/bin/python for custom development because it is patched and > tuned specifically for running system applications packaged for > their distro and not intended as a general-purpose Python > distribution. There are tools that will help you do this. e.g. pyenv, asdf, etc. But, yes, for my own software development, I gave up trying to use Debian python packages years ago, because I found I was spending way more time trying to package the required dependencies (and dependencies of dependencies of dependencies) then I spending developing my application. This gets even worse if you want to support rpm based distributions. Plus the fact that I was becoming increasingly concerned that if I upgraded library python3-L for application A, I might accidentally break applications B, C, and D also, and testing/fixing everything at the same time not really feasible. So now I use asdf + poetry/virtualenvs now, plus Docker for distribution. As a result, I can upgrade the dependencies in each application one application at a time. If an application breaks, I just need to fix that one application, without breaking everything else at the same time. I can upgrade the OS distribution, and not be concerned (mostly anyway) that it will break my applications in weird and wonderful ways that I could not predict. This isn't so useful for distribution of Python based desktop applications, but I don't do a lot of that (and probably would be looking for a good off-the-shelf solution if I did). -- Brian May
Re: Challenges packaging Python for a Linux distro - at Python Language Summit
Thomas Goirand writes: > All the horrors that you are painting after this paragraph, are due to > the fact that you aren't doing "apt-get dist-upgrade". I'm having a hard > time understanding why you're both: > - not doing "apt-get dist-upgrade" > - complaining that it's breaking your system > > Could you care to explain? This makes absolutely no sense. A rolling type update might be convenient, but it is not supported by Debian, and has not been supported by Debian in sometime. There are complexities in such an arrangement, and it is difficult to test such arrangements will work as expected. Such an arrangement is not guaranteed or tested to work. In short, if you want to upgrade to Debian version n, you really should be running entirely Debian n-1 before you start the upgrade. This is important. And you probably should upgrade everything in one go. As this is the only tested upgrade procedure. -- Brian May
Re: Python package situation
Andrey Rahmatullin writes: > On Tue, Feb 16, 2021 at 09:48:05PM +0100, Martin wrote: > Are you asking about testing or stable? Because for stable the "packages > are either outdated or do not exist" situation is somewhat expected and > testing is not that interesting case, though even in testing we may have a > lot of outdated packages. I believe there are a number of Python packages in Debian unstable that are out of date in respect to latest upstream. e.g. https://qa.debian.org/developer.php?login=bam%40debian.org&comaint=yes Somebody needs to do the work to update them. But maybe the fact that nobody is doing so, might mean that nobody is using them? The packages which are up-to-date have not been updated by upstream in a long time, and this isn't necessarily a good thing either. I personally found a while back that keeping these packages up-to-date was draining far too much of my time. Time I don't actually have. So I now use Docker+pip for my applications. Plus upgrading system packages to fix dependencies always made me worried I might break something unrelated that I couldn't or wasn't ready to fix. So most of the time I don't use these packages anymore. Yes, the idea of the packages being stable in Debian stable, and hence, won't break anything until you do a release upgrade is a good one. But if you encounter a bug/missing feature in such a package that breaks your application, often the only real alternative is to use the latest version. Often only the latest version is supported by upstream also. -- Brian May
Re: Joining the team
Thomas Goirand writes: > Because joining a team, putting packages in them, and enforcing strong > ownership, is not logic at all. I know you like to do this way, but this > shouldn't be what we advise for new comers. Agreed. In my opinion what the policy allows and what is best practise are two different things. If you want strong ownership, you can get that already by not having the package part of the team. To invite people to do so as part of the Debian policy just makes the policy more complicated (and confusing) then it needs to be. And creates needless conflicts within our team. Depending on what you want, You are also free to follow the packaging guidelines, policies, etc, even if the package isn't formally part of the team. You could even join this group https://wiki.debian.org/LowThresholdNmu and allow others to make changes to your packages without going through the slow NMU process. -- Brian May
Re: sshuttle / python3.8
Emmanuel Arias writes: > Hello I am available to help. > > Let me take a look. Thanks! Any luck so far? -- Brian May
sshuttle / python3.8
Hello, I have been informed that the sshuttle package, in Debian is most likely completely broken under Python 3.8 https://github.com/sshuttle/sshuttle/issues/381 To me this looks like a regression in Python 3.8. but at the same time sshuttle is possibly misusing(?) sockets in ways that were never intended(?). Unfortunately, even though I am upstream and Debian maintainer, I don't have any time to look at this. Help appreciated. Thanks -- Brian May
Re: Bug#943666: python3: Update Python Policy for removal of the Python 2 stack
Stéphane Blondon writes: > Perhaps there is a doubt how to read it? > - do not (remove python-foo-doc or rename it to python3-foo-doc) > - (do not remove python-foo-doc) or (rename it to python3-foo-doc) > > Would it be better if we remove the indentation and use this sentence(?): > if documentation is in python-foo-doc, do not move it Myself, I read it as the first option. I would personally use: - Do not remove python-foo-doc and do not rename it to python3-foo-doc. Or maybe even expand as two bullet points: - Do not remove python-foo-doc. - Do not rename it to python3-foo-doc. I think this makes it very explicit what was intended. -- Brian May
Re: Help needed with celery/kombu
Emmanuel Arias writes: > I am trying to update celery to 4.3.0. First a warning: Might be hard to justify getting a new release of celery into Buster at thiss point in time... > But when I run ```gbp import-orig --uscan``` > > I have the next error: > > gpgv: Signature made Sun 31 Mar 2019 03:56:37 PM UTC > gpgv: using RSA key 246C61675A0FB0E16A3E219C29C4F24992EDDC6D > gpgv: Can't check signature: No public key > uscan die: OpenPGP signature did not verify. at > /usr/share/perl5/Devscripts/Uscan/Output.pm line 58. > gbp:error: Uscan failed: OpenPGP signature did not verify. It looks like don't have the public key that the package was signed with. I see there in stretch that there is a key in debian/upstream-signing-key.pgp, maybe upstream changed their key? $ gpg < debian/upstream-signing-key.pgp gpg: WARNING: no command supplied. Trying to guess what you mean ... pub rsa2048/0xE02B14E5030A2708 2013-10-24 [SC] Key fingerprint = F11D EE52 6472 1B58 8D5A DE93 E02B 14E5 030A 2708 uid Celery Security Team sub rsa2048/0x71F0610B99741E57 2013-10-24 [E] -- Brian May
[Struan Bartlett] [Python-modules-team] Debian Multiarch package issue: virtualenv and python3-virtualenv
Forwarding to debian-python mailing list from the Debian Python Modules Team which most people don't look at. Actually a bug report probably would be the best of of reporting this, as it looks like it could be a bug. --- Begin Message --- Hello We have been unable to install virtualenv and python3-virtualenv on Debian stretch/i386 with python3:amd64, without customising the former two packages, due to what appear to be minor package configuration issues. We have resolved the issues in custom-built packages by: - Adding a 'Multi-Arch: allowed' header to each of these two packages - Removing the apparently surplus python3 dependency in python3-virtualenv, leaving only the python3:any dependency - Modifying the python3 dependency in virtualenv, to make it python3:any too. (please see example diffs below). Please would you advise what additional action, if any, we need to take to raise these issue formally and see them fixed in future package releases? Kind regards Struan Bartlett diff -ubw DEBIAN/control* --- DEBIAN/control 2016-12-01 23:08:39.0 + +++ DEBIAN/control2 2019-03-06 22:40:00.0 + @@ -1,10 +1,11 @@ Package: python3-virtualenv Source: python-virtualenv Version: 15.1.0+ds-1 Architecture: all +Multi-Arch: allowed Maintainer: Debian Python Modules Team Installed-Size: 137 -Depends: python-pip-whl (>= 8.1.1-2), python3, python3-pkg-resources, python3:any (>= 3.3.2-2~) +Depends: python-pip-whl (>= 8.1.1-2), python3-pkg-resources, python3:any (>= 3.3.2-2~) Section: python Priority: optional Homepage: https://pypi.python.org/pypi/virtualenv``` (edited) # diff -ubw DEBIAN/control* --- DEBIAN/control 2016-12-01 23:08:39.0 + +++ DEBIAN/control2 2019-03-06 22:45:13.0 + @@ -1,10 +1,11 @@ Package: virtualenv Source: python-virtualenv Version: 15.1.0+ds-1 Architecture: all +Multi-Arch: allowed Maintainer: Debian Python Modules Team Installed-Size: 30 -Depends: python3, python3-virtualenv +Depends: python3:any, python3-virtualenv Breaks: python-virtualenv (<< 1.11.6) Replaces: python-virtualenv (<< 1.11.6) Section: python -- Struan Bartlett Founder & CEO NewsNow.co.uk The UK's #1 News Portal: > www.NewsNow.co.uk <http://www.NewsNow.co.uk> (est. 1998) Tel:+44 (0)845 838 8890 Fax:+44 (0)845 838 8898 NewsNow Publishing Limited, trading also as NewsNow.co.uk, is a company registered in England and Wales under company no. 3435857 with registered office Northdown House, 11-21 Northdown Street, London N1 9BN ___ Python-modules-team mailing list python-modules-t...@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team--- End Message --- -- Brian May https://linuxpenguins.xyz/brian/
Re: upstream release of unreleased package
Andrey Rahmatullin writes: > No, you should not add the new upstream version as a patch. Especially as > you already have the tarball imported. What is the repo missing is merging > upstream/0.3.8 into the master branch. If you imported the tarball with > gbp import-orig it would have happened automatically. That would probably explain why I had problems. I didn't check that the latest upstream branch correctly matched the source without patches, and generated the orig.tar.gz file based on the lastest upstream branch (which wasn't tagged correctly either). It is possible in this case no patches are required. Not sure I entirely understand the situation however. "for a new upstream release of the unreleased" - has it been released upstream or not? -- Brian May
Re: upstream release of unreleased package
llu...@autistici.org writes: > lluvia@technoethical:~/debian/visualequation$ git commit -m "modifying > d/changelog for new upstream release" > [patch-queue/debian/master 70ae5b1] modifying d/changelog for new > upstream release > 1 file changed, 3 insertions(+), 2 deletions(-) This is your first error. Changes to debian/* files belong to the debian/master branch, not the patch-queue/debian/master branch. So you should be finalise the changes to the patch-queue first, then run something like "gbp pq export" which will switch back the the debian/master branch, then you can make changes to the debian/* files. Sorry, I don't have time to try to explain how to fix this right now :-( -- Brian May
Re: upstream release of unreleased package
llu...@autistici.org writes: > Then, I did git push. It was correct? What should I do next? The output > (see below) suggest to create a merge request. > Thanks in advance. Ignore that. That is just the git server providing helpful information that isn't really appropriate here. -- Brian May
Re: git-dpm -> gbp conversion (mass-change)
Thomas Goirand writes: > Let's say a patch has been applied upstream. In such case, I just do a > few "quilt push" to check, then I see one is already applied (by running > "patch --dry-run -P1 patch from the series file, and I'm done. In case of using git with the > rebase thing, then I get into useless trouble. This case is easy. When rebase comes up with a conflict, you can tell it to skip/drop that entire change. This tends to be my default choice when I don't understand why something conflicts during such a rebase. > Another case is if upstream moved sources from one directory to another. > In such case, I just edit the patch directly to fix the path. With a git > rebase, you'd probably have to rewrite all the patch by hand. Here > again, that's useless trouble. Yes, that case is harder to deal with. -- Brian May
Re: git-dpm -> gbp conversion (mass-change)
Ruben Undheim writes: > There is no nightmare unless there are patch conflicts. The one case where you could have a "nightmare" is: 1. Maintainer A updates package to latest upstream version. 2. Maintainer A uploads packages to Debian, and it is accepted. 3. Maintainer A forgets to push changes to git. Or doesn't push all branches/tags as required. 4. Maintainer B finds package, and updates to latest upstream version (which could be later then what maintainer A saw). 5. Maintainer B pushes changes to git. 6. Somebody complains that fixes that where included in the first version have now gone missing. 7. Maintainer A pushes his changes, find they are rejected, and wrongly does a "push -f", loosing the changes from maintainer B. OR 7. Maintainer A realizes what has happened, has two sets of patches against two different upstream versions, and somehow needs to reconcile them. etc, etc. However, I don't know of any workflow that would make the issues here any easier. Moral of the story, always make sure you pull changes (from all branches) before starting to work, just to make sure nobody else has made changes. Plus always make sure you push changes (all required branches, e.g. "git push origin : --tags") after you finish work. Easy to forget however. -- Brian May
Re: git-dpm -> gbp conversion (mass-change)
Nikolaus Rath writes: > The problems with git-dpm are the implementation and lack of > maintenance, not the way the Debian changes are managed. git-dpm requires that you always use its tools. If another maintainer got confused and used another toolset to upgrade the upstream version, things could get messy. I did see it happen from time to time that the previous maintainer would leave the repository in a weird state that could only be fixed (unfortunately) with a git rebase. -- Brian May
Re: Safest way to set python3 as default for `python`
Stuart Prescott writes: > There's a reasonable number of things in /usr/bin with "#!/usr/bin/env > python" that would be unhappy with this configuration. I don't think binaries in /usr/bin should be using "#!/usr/bin/env python". These will also break with virtualenvs. Packaged programs in Debian should be using /usr/bin/python*. Having said that, I can confirm you are correct, this does appear to be common. -- Brian May
Re: django-celery
Thomas Goirand writes: > I agree as well. Please file a bug for its removal. See Bug#897257. -- Brian May
Bug#897257: RM: django-celery -- ROM; Deprecated package
Package: ftp.debian.org Severity: normal Hello, django-celery is broken, deprecated upstream, and has been replaced by other packages that are already in Debian, such as django-celery-results and django-celery-beat. This was discussed on debian-python, see: https://lists.debian.org/debian-python/2018/04/msg00120.html Please remove this package and all binaries from testing and unstable. I don't believe anything depends on django-celery. Thanks
django-celery
Hello, Beginning to think we should seriously think about dropping this package. It is badly neglected by upstream, and there are now better alternatives. Such as django-celery-results (not sure if this is in Debian). I attempted to fix it by upgrading to the latest upstream version (see git repository), but there are a number of python errors running tests, and I lack the interest in attempting to fix them (although at quick glance some of these errors look trivial to fix...) As far as I am aware, nothing in Debian depends on django-celery. Any thoughts? -- Brian May https://linuxpenguins.xyz/brian/
Re: [Python-modules-team] Bug#896429: python3-django-tables2: django_tables2 fails to import
Thomas Goirand writes: > Feel free to raise this on a Django upstream message. I very much agree > this isn't best. I believe there is (or at least was, and probably still is) general agreement that the Django settings mechanism is horrible for numerous reasons. IIRC this has been discussed at past PyCON AU conferences. Unfortunately, this has been labelled as a "hard problem". As in coming up with a replacement that the Django core developers can agree to is non-trivial (which also means dealing with existing applications in a sensible manner). e.g. do a google search for "django settings class" and you will see that there are a number of projects to get class based settings for Django. A feature I really wish Django supported out of the box. Unfortunately most of these projects (I might have missed something) appear to have been abandoned. Maybe this is an isssue that needs to be pushed at PyCon or PyConAU. If there isn't an existing upstream bug report already, somebody should definitely file one. Or add details as to how the problem affects testing, if not already given. I don't believe the bug report by itself will solve this problem, but I think it is a necessarily prerequisite for a solution. -- Brian May
Re: Backport of Python 3.6 for Debian Stretch?
Nguyễn Hồng Quân writes: > Sorry? As I told, just leave the python3-xxx packages to be used with > python3.5 (default Python3 of Debian 9). > I don't need those to be used with Python3.6. > For whatever I need to use with Python3.6, I just install via "pip3.6". > For Python3.6, you just need to provide python3.6 (+ its standard lib), > python3.6-dev. If using pip to install packages is fine (which can result in compiling from source although increasing use of wheels helps), then I personally fail to see the problem with using something like pyenv. -- Brian May
Re: [Python-modules-team] Bug#896429: python3-django-tables2: django_tables2 fails to import
Helmut Grohne writes: > django.core.exceptions.ImproperlyConfigured: Requested setting > DEFAULT_INDEX_TABLESPACE, but settings are not configured. You must > either define the environment variable DJANGO_SETTINGS_MODULE or call > settings.configure() before accessing settings. I believe this bug report, and several others you filled recently that contain this same text are false. Like it or not, it is just not possible to import Django libraries without providing a valid django settings file. This is not a sign that something is broken. -- Brian May
Re: Questions about salsa and Git
Simon McVittie writes: > Is this now official policy for new/updated/converted Python modules > maintained by DPMT? > > Is it official policy for new/updated/converted Python applications > maintained by PAPT? I am not exactly an authoritive figure, but I believe the answer to both of these is yes. It is possible that there are a number of packages that still need to be converted. I had a script on aloth to do this, it might need updating for salsa. Especially as it relied on direct access to the git directory to change the default branch. > At the moment each of those pages says that the Python teams have chosen > the relevant packaging system and that the other packaging system is > forbidden, which is confusing at best. Both pages do need updating. -- Brian May
Re: setup.py sdist permissions
Robert Collins writes: > Yah, packaging permissions are an installation problem, and setup.py > is (no longer) intended for installation. Thanks, that is what I thought too. Have followed up in the bug report. -- Brian May
Re: setup.py sdist permissions
Robert Collins writes: > Replied on the bug :) Thanks. He responded, he is not using pip, but creating a "Void package" from source. I am inclined respond, as he is not using pip, he needs to ensure the permissions are correct. -- Brian May
Re: setup.py sdist permissions
Yaroslav Halchenko writes: > just anecdotal support: my umask is 077 as well, have been doing uploads > to pypi for a while, never had report from the users about any problem. > The reasons could be either it indeed doesn't matter or nobody uses my > projects ;-) Same here. I just got a bug report :-( https://github.com/sshuttle/sshuttle/issues/217 Not really sure what circumstances this causes problems, or what I should do about it. -- Brian May
setup.py sdist permissions
Hello, As an upstream maintainer of certain packages on pypi, it has come to my attention that my packages have files in the source package with permission 600 or 700 (and my owner and group). This is most likely because my umask is set to 077, because in general I prefer not having all my private files world/group readable. * Is this actually a problem for users? * Shouldn't sdist be ignoring my umask considering it is generating packages for public consumption? It seems like the only known solution is to manually set umask to 022 before calling sdist, something I am likely to forgot to do on a continued basis. Any ideas? -- Brian May
[alioth lists migration team] [Python-modules-team] Notice of mailing list closure: python-modules-team
A lot of our packages currently have this list in the maintainer field. Maybe we want to keep this list for now??? --- Begin Message --- Dear list subscribers, As per the announcement on debian-devel-announce[1] and as part of the shutdown of the alioth service, the migration of lists.alioth.debian.org mailing lists to alioth-lists.debian.net is now underway. We tried to contact the designated list owner via python-modules-team-ow...@lists.alioth.debian.org but got either no reply, or a bounce message. Accordingly, this list will not be migrated to the new system and will stop working on 14th April. Information about alternatives to this service which may be more suitable for the list can be found at <https://wiki.debian.org/Salsa/AliothMigration#Import_mailing_list>. In the event that this list should be migrated to the new system, please first appoint a Debian developer as a list owner, then let us know by replying to this email, copying in the list. More information about the new service can be found here: <https://wiki.debian.org/Alioth/MailingListContinuation> Thanks, the alioth-lists migration team. [1] <https://lists.debian.org/debian-devel-announce/2018/01/msg3.html> ___ Python-modules-team mailing list python-modules-t...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team --- End Message --- -- Brian May https://linuxpenguins.xyz/brian/
mkdocs
Hello, I am thinking now (with the migration to Salsa) is a good time to move all the packages directly related to mkdocs to PAPT: mkdocs-bootstrap - bootstrap themes for MkDocs mkdocs-bootswatch - bootswatch themes for MkDocs mkdocs - Static site generator geared towards building project documentation Currently the first two packages are in CollabMaint, and the last in DPMT. Does this sound like the right approach? Regards -- Brian May
Re: python logo.
Peter Green writes: > I am looking into cleaning up some software so it can be uploaded to > Debian. Inside the documentation folder is a copy of the python > logo. I found the python.org page for the logo more confusing than > helpful. > > 1. Is the python logo under a license acceptable for including in a Debian > package? or does it need to be stripped out? > 2. If it is acceptable for inclusion how should it be documented in > debian/copyright? Probably questions for debian-legal, not debian-python... -- Brian May
Re: snap in debian
Michael Hudson-Doyle writes: > Yay unreproducible bugs. If you manage to reproduce, please have a look in > syslog or systemd's journal for anything that looks related. Not sure this helps me, maybe it might help somebody else? "Failed to load configuration" might be relevant. What configuration? This is a grep for hello in journalctl, after trying to remove the hello snap. I couldn't see anything else relevant. Oct 15 13:15:45 prune sudo[17326]:brian : TTY=pts/1 ; PWD=[removed] ; USER=root ; COMMAND=/usr/bin/snap remove hello Oct 15 13:15:46 prune systemd[1]: snap-hello-20.mount: Changed mounted -> dead Oct 15 13:15:46 prune systemd[1843]: snap-hello-20.mount: Changed mounted -> dead Oct 15 13:15:46 prune systemd[1843]: snap-hello-20.mount: Collecting. Oct 15 13:15:46 prune systemd[1]: Sent message type=signal sender=n/a destination=n/a object=/org/freedesktop/systemd1/unit/snap_2dhello_2d20_2emount interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=2105 reply_cookie=0 error=n/a Oct 15 13:15:46 prune systemd[1]: Sent message type=signal sender=n/a destination=n/a object=/org/freedesktop/systemd1/unit/snap_2dhello_2d20_2emount interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=2106 reply_cookie=0 error=n/a Oct 15 13:15:46 prune systemd-logind[632]: Got message type=signal sender=:1.0 destination=n/a object=/org/freedesktop/systemd1/unit/snap_2dhello_2d20_2emount interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=2105 reply_cookie=0 error=n/a Oct 15 13:15:46 prune systemd[1413]: snap-hello-20.mount: Changed mounted -> dead Oct 15 13:15:46 prune systemd[1413]: snap-hello-20.mount: Collecting. Oct 15 13:15:46 prune systemd-logind[632]: Got message type=signal sender=:1.0 destination=n/a object=/org/freedesktop/systemd1/unit/snap_2dhello_2d20_2emount interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=2106 reply_cookie=0 error=n/a Oct 15 13:15:46 prune systemd[1]: snap-hello-20.mount: Trying to enqueue job snap-hello-20.mount/stop/replace Oct 15 13:15:46 prune systemd[1]: snap-hello-20.mount: Installed new job snap-hello-20.mount/stop as 3721 Oct 15 13:15:46 prune systemd[1]: snap-hello-20.mount: Enqueued job snap-hello-20.mount/stop as 3721 Oct 15 13:15:46 prune systemd[1]: snap-hello-20.mount: Job snap-hello-20.mount/stop finished, result=done Oct 15 13:15:46 prune systemd[1]: Got message type=method_call sender=n/a destination=org.freedesktop.systemd1 object=/org/freedesktop/systemd1/unit/snap_2dhello_2d20_2emount interface=org.freedesktop.DBus.Properties member=Get cookie=3 reply_cookie=0 error=n/a Oct 15 13:15:46 prune systemd[1]: Got message type=method_call sender=n/a destination=org.freedesktop.systemd1 object=/org/freedesktop/systemd1/unit/snap_2dhello_2d20_2emount interface=org.freedesktop.DBus.Properties member=Get cookie=4 reply_cookie=0 error=n/a Oct 15 13:15:46 prune systemd[1]: Got message type=method_call sender=n/a destination=org.freedesktop.systemd1 object=/org/freedesktop/systemd1/unit/snap_2dhello_2d20_2emount interface=org.freedesktop.DBus.Properties member=Get cookie=5 reply_cookie=0 error=n/a Oct 15 13:15:46 prune systemd[1]: Got message type=method_call sender=n/a destination=org.freedesktop.systemd1 object=/org/freedesktop/systemd1/unit/snap_2dhello_2d20_2emount interface=org.freedesktop.DBus.Properties member=GetAll cookie=1 reply_cookie=0 error=n/a Oct 15 13:15:46 prune systemd[1]: Preset files don't specify rule for snap-hello-20.mount. Enabling. Oct 15 13:15:46 prune systemd[1]: Got message type=method_call sender=n/a destination=org.freedesktop.systemd1 object=/org/freedesktop/systemd1/unit/snap_2dhello_2d20_2emount interface=org.freedesktop.DBus.Properties member=GetAll cookie=1 reply_cookie=0 error=n/a Oct 15 13:15:46 prune systemd[1]: Got message type=method_call sender=n/a destination=org.freedesktop.systemd1 object=/org/freedesktop/systemd1/unit/snap_2dhello_2d20_2emount interface=org.freedesktop.DBus.Properties member=GetAll cookie=1 reply_cookie=0 error=n/a Oct 15 13:18:47 prune systemd[1]: snap-hello-20.mount: Failed to load configuration: No such file or directory Oct 15 13:18:47 prune systemd[1]: snap-hello-20.mount: Collecting. -- Brian May
Re: pyasn1
Vincent Bernat writes: > pyasn1 is currently at version 0.1.9. The current version is > 0.3.7. There is a bug report asking for a new version: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872724 > > Should a transition be opened for such a packet (this is not usual to > have transition for Python packages, but there are many reverse > dependencies to this one)? Is the new version likely to break dependencies? If so, a transition might be good. Might be worth creating a test version for experimental and rebuilding all dependancies against it to see if any fail. Although I think I may have just described a transition anyway :-). -- Brian May
Re: snap in debian
Michael Hudson-Doyle writes: > Yes. Let's see if I can find some better answers... Thanks! -- Brian May
Re: snap in debian
Michael Hudson-Doyle writes: > Can you elaborate? Do you have apparmor enabled? I am aware that there are > problems on stable currently but being explicit reduces guessing. See the stack overflow question. The major issue was the error when trying to remove an existing container. 2017-09-09T15:08:29+10:00 ERROR cannot remove snap file "robotica", will retry in 3 mins: snap-robotica-x1.mount failed to stop: timeout I also had problems with incorrect permissions randomly appearing, even though I used exactly the same process every time. > Can you try just installing the package from unstable rather than > rebuilding it? (sometimes static linking does solve problems :-p) I was guessing it won't be possible to install the package straight from unstable onto a stable system, and am not interested in upgrading at this point to unstable. However I might be wrong here. In any case, my research led me to believe the first error *might* be a kernel issue... I believe my packages to be fine. The only response I got however was an implied "don't use snap" and "I personally don't like the concept of snap". which wasn't really helpful. -- Brian May
snap in debian
Ghislain Vaillant writes: > May I ask what would be the benefit for pycharm to be in Debian, when we > already have the official Jetbrains Toolbox App or the snap package as > means to install and update the application? For what its worth, last time I tried snap on Debian stable I found it didn't work reliably. I asked in Stack Overflow, and managed to backport the version of snap from unstable. Where I encountered exactly the same problems as before: https://stackoverflow.com/questions/46127373/snap-packages-on-debian-stable So possibly at least one of my problems is a Kernel issue in Debian stable (at least my current theory), however this seems to indicate to me that snap is still somewhat bleeding edge and cannot be relied on. -- Brian May
Re: git-dpm (was Re: Bug#729956: Forwarded upstream)
On 2017-09-07 14:54, Scott Kitterman wrote: > It's a wiki. The resolution of your annoyance is within your grasp. I had already fixed it. Sorry if I didn't make this clear.
Re: git-dpm (was Re: Bug#729956: Forwarded upstream)
On 2017-09-07 08:42, Scott Kitterman wrote: > Conveniently, we already decided to switch: > > https://wiki.debian.org/Python/GitPackagingPQ It was annoying me that these instructions were missing the last steps on how to switch the default branch to debian/master and delete the old branch. These steps are very important to: (a) prevent confusion on which branch to use. (b) prevent confusion on qa.debian.org, which uses the default branch to check that the git version. === cut === ssh git.debian.org cd "/git/python-modules/packages/$1.git" git symbolic-ref HEAD refs/heads/debian/master exit cd "$TMP" git push origin :master === cut === I also have a script to automate the entire conversion, and assuming the git repository is up-to-date and nobody is withholding pushes, it seems to work well. /srv/home/users/bam/convert on git.debian.org
Re: git-dpm (was Re: Bug#729956: Forwarded upstream)
On 2017-09-07 08:42, Scott Kitterman wrote: > Conveniently, we already decided to switch: > > https://wiki.debian.org/Python/GitPackagingPQ Worth noting, while there are some big gotchas with git-dpm, there are also some big gotchas with GPB PQ. GPB PQ isn't a magical solution that will solve all our problems. e.g. forgetting to import the PQ (if not already done) *before* updating to a new upstream version. Or forgetting to import the PQ after a git pull makes modifications to the upstream patch files. In general, however, when something does go badly wrong I think it will be a lot easier to diagnose, understand, and fix with GPB PQ then with git-dpm. git-dpm can get very messy very quickly, particularly if you forget to pull before making changes (personally I make this mistake too frequently) or update to a new upstream version without using the correct git-dpm workflow - I have seen both of these situations happen.
Re: a few quick questions on gbp pq workflow
Allison Randal writes: > - Will DPMT be following DEP-14 and using the branch name debian/master > instead of master? I believe so. Although from memory the conversion instructions are incomplete on how to change the default branch to debian/master, which is required before you can delete the old master branch. Having a master branch that is no longer useful may have confused me with some packages that other people have converted, but haven't had time to check. > - The gbp pq workflow page still points at the general Debian git-dpm > instructions in the links for "import an existing .dsc file" and "start > from scratch". Are there alternate versions of those pages for gbp pq > somewhere? > > https://wiki.debian.org/PackagingWithGit/GitDpm/ImportDsc > https://wiki.debian.org/PackagingWithGit/GitDpm/Initialize Whoops. Possibly these links should be removed, all the information required should be on this page. If not, feel free to add it... > - Does DPMT prefer signed tags or unsigned tags, the wiki page is pretty > agnostic on the topic. Personally I use signed tags. gbp has a --git-sign-tags option. > - Are there other lingering workflow questions for gbp pq not yet > recorded on the wiki page? The only major issue is the lack of proper procedure on how do the master --> debian/master branch rename. As in I think the procedures leaves behind a master branch, and keeps it as the default. I have a script on git.debian.org - hopefully everyone should be able to read this: /srv/home/users/bam/convert Which will handle the entire conversion. Must be run on git.debian.org, and for best results git should have your username and email setup on git.debian.org. Works for me for every case, except for the one package where I hadn't pushed upstream changes correctly beforehand. The script also includes the correct procedure for converting from master to debian/master. -- Brian May
Re: updating packages
Christopher Hoskin writes: > What's the plan for moving them to unstable? Are they still using git > pq rather than git-dpm? I have updated celery to use git pq. Not done kombu or python-amqp yet however. -- Brian May
Re: updating packages
Christopher Hoskin writes: > As sphinx is used for documentation, even if you're building a python2 > package, you can use the python3 sphinx. Build-depends on > python3-sphinx and Build-Conflicts on python-sphinx. Yes, was wondering that. > I was going to look at updating vine, kombu and python-ampq this > weekend, but the upstream tarballs have been signed by a different key > pair than the one advertised at: :-( Please keep me up-to-date on developments. Thanks! -- Brian May
Re: updating packages
Christopher Hoskin writes:
> sphinx_celery is already packaged as sphinx-celery:
>
> https://packages.qa.debian.org/s/sphinx-celery.html
Only has a Python 3 version. Not sure if this matters.
At the moment, when I try to build djangorestframework I get the
following error. Maybe jinja2 is too old or too new?
# Build the HTML documentation.
mkdir /<>/docs.debian
LC_ALL=C.UTF-8 PYTHONPATH=/usr/share/mkdocs/themes mkdocs build && mv site
docs.debian/html
INFO- Building documentation to directory: /<>/site
Traceback (most recent call last):
File "/usr/bin/mkdocs", line 9, in
load_entry_point('mkdocs==0.15.3', 'console_scripts', 'mkdocs')()
File "/usr/lib/python3/dist-packages/click/core.py", line 722, in __call__
return self.main(*args, **kwargs)
File "/usr/lib/python3/dist-packages/click/core.py", line 697, in main
rv = self.invoke(ctx)
File "/usr/lib/python3/dist-packages/click/core.py", line 1066, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
File "/usr/lib/python3/dist-packages/click/core.py", line 895, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "/usr/lib/python3/dist-packages/click/core.py", line 535, in invoke
return callback(*args, **kwargs)
File "/usr/lib/python3/dist-packages/mkdocs/__main__.py", line 137, in
build_command
), clean_site_dir=clean)
File "/usr/lib/python3/dist-packages/mkdocs/commands/build.py", line 290, in
build
build_pages(config)
File "/usr/lib/python3/dist-packages/mkdocs/commands/build.py", line 234, in
build_pages
build_template('404.html', env, config, site_navigation)
File "/usr/lib/python3/dist-packages/mkdocs/commands/build.py", line 149, in
build_template
output_content = template.render(context)
File "/usr/lib/python3/dist-packages/jinja2/environment.py", line 1008, in
render
return self.environment.handle_exception(exc_info, True)
File "/usr/lib/python3/dist-packages/jinja2/environment.py", line 780, in
handle_exception
reraise(exc_type, exc_value, tb)
File "/usr/lib/python3/dist-packages/jinja2/_compat.py", line 37, in reraise
raise value.with_traceback(tb)
File "/<>/docs_theme/404.html", line 1, in top-level template
code
{% extends "main.html" %}
File "/<>/docs_theme/main.html", line 7, in top-level template
code
{% if page.title %}{{ page.title }} - {% endif %}{{ config.site_name
}}
File "/usr/lib/python3/dist-packages/jinja2/environment.py", line 430, in
getattr
return getattr(obj, attribute)
jinja2.exceptions.UndefinedError: 'page' is undefined
debian/rules:12: recipe for target 'override_dh_auto_build' failed
make[1]: *** [override_dh_auto_build] Error 1
make[1]: Leaving directory '/<>'
debian/rules:9: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
--
Brian May
Re: updating packages
fladischermich...@fladi.at writes: > I made some changes to the django-filter package in git. Could you check > if it fixes your issues? Right now 1.0.4-1 builds fine for me with the > current version of DRF in unstable. Looks fine to me, uploaded. Thanks -- Brian May
python-modules-commits-ow...@lists.alioth.debian.org bounces
Hello, I am getting a constant stream of bounces from emails generated by the commit hooks. I tried sending an email to that address, but not got any response yet. Yes, message really does say "throughg". Regards. --- cut --- Sorry we reject non-member mails due to spam but we have filters to allow commit notifications to go throughg. If you believe that your message should be auto-approved for this list, please get in touch with python-modules-commits-ow...@lists.alioth.debian.org. --- cut --- -- Brian May
Re: git-dpm: remove a patch
Vincent Bernat writes: > git-dpm: Calling merge-patched-into-debian first... > git-dpm: ERROR: cowardly refusing to update patched to already merged > version!. Use --allow-revert to override! Have you tried doing what it suggests, using the --allow-revert parameter? I believe git-dpm sees you removing a patch and assumes you might be doing something wrong - so it stops you. However as you know what you are doing, you should override it. -- Brian May
updating packages
Hello, I have started updating packages, trying to fix Django 1.11 issues where applicable, but seem to be running into road blocks for everything I try. Have updated git. Help appreciated: * django-filter, requires djangorestframework. * djangorestframework, tests fail, not yet investigated in detail why. * celery: requires cyanide (including docs) and sphinx_celery to be packaged in Debian. Thanks. -- Brian May https://linuxpenguins.xyz/brian/
Re: gbp pq conversion
The one mistake I seem to often make with gbp pq is import the new sources and then discover I forgot to one "gbp pq import". The "gbp pq import" needs to happen first (if not already done), before importing new sources. Otherwise "gbp pq rebase" and "gbp pq export" can end up deleting all patches. The solution I have found is 1. Create a temporary branch at the current commit git branch tmp 2. Take the debian/master branch to the previous "good" commit: git reset --hard version origin/debian/master change the origin/debian/master as appropriate. 3. Import the patch queue (possibly might need to delete any existing patches branch first): gbp pq import 4. Go back to the latest version: git reset --hard tmp git branch -d tmp Note that "gbp pq import" must be done in the correct branch, as the name of the patch branch is based on the current branch. Also note that the "gbp pq import" must be done on patches unapplied format, so don't go too far back in the history. -- Brian May
gbp pq conversion
I have a script in git.debian.org that will hopefully help. I am still testing it on packages, one at a time. I am not yet 100% confident in its correct operation - although it appeared to work for Django tables. /srv/home/users/bam/convert django-tables I imagine this will need some refinement. In particular, it has some paranoid checks at the top, which possibly could be relaxed. I overwrite gbp.conf instead of trying to do something sensible if it exists (hence the check to ensure it doesn't exist). I have commented out the code to the the patch queue import and export, partly because gbp is not installed on git.debian.org, and partly because this part probably should be done manually in order to check information is not lost. Hopefully the permmissions are correct, so that anyone can access the file. After the conversion the master branch will be deleted, this needs to be considered for local checked out copies - making a new clean checkout might be the easiest solution. -- Brian May https://linuxpenguins.xyz/brian/
Re: [Python-modules-team] python-pip ancient version 1.5 for Debian 8
CCing to correct mailing list. debian-python@lists.debian.org I don't actually understand the issue. Clark Knøsen writes: > python-pip is no longer compatible with newer installations/repos like > > # pip install pyvirtualdisplay selenium > > python-pip installs 1.5 and the current version i 9.0 -- Brian May https://linuxpenguins.xyz/brian/
Re: PAPT git migration
On 2017-06-01 09:16, Simon McVittie wrote: > but this style (which is a DEP3 invention, and not used outside Debian and its > derivatives) is not: > > Author: ... > Description: First line of description > More description > more description > yet more description > Bug-Debian: ... Might be good to know how many of our packages have patches that use this format too.
Re: PAPT git migration
On 2017-06-01 09:16, Simon McVittie wrote: > From: ... > Date: ... > Subject: First line of description > > More description > more description > yet more description > > Bug-Debian: ... > Applied-upstream: ... > More-DEP3-fields-in-pseudo-header: ... > --- > optional diffstat here > > diff --git ... > ... > > but this style (which is a DEP3 invention, and not used outside Debian and its > derivatives) is not: > > Author: ... > Description: First line of description > More description > more description > yet more description > Bug-Debian: ... So to me it looks like the required changes are: * Rename Author field to From. Ensure it is first field. * Add Date field. Set to what? * Rename Description to Subject. * Ensure blank line before description. * Remove space at start of every line in description. * Ensure blank line after description. The Applied-upstream field looks nice to have, but maybe not essential. Is this correct? Did I miss anything? A tool to automate some, if not all of this, would be good.
Re: PAPT git migration
On 2017-06-01 07:32, Barry Warsaw wrote: > Let's assume not (which is fine with me; i.e. why adopt git-dpm for PAPT when > we know we just want to get rid of it later?). Then i tried to import a new > upstream as described here https://wiki.debian.org/Python/GitPackagingPQ Another problem I have noticed with that document - but not had time to come up with a solution yet. There are several places where "git push --all" (or variant) is recommended. But this will also push the gbp pq branch(es), which should never get pushed.
Re: avoiding regressions with python3-all-dev in between transitions?
Steve Langasek writes: > As with every recent transition, we are finding a number of packages that > have wrong build-dependencies on python3-all-dev despite having no support > in the packaging for multiple versions. Some of these packages just > continue to build for the default version, and some of them fail to build. I suspect a related issue is packages that build fine, but the tests don't actually run tests against all python versions. For example, python-django-jsonfield has in debian/rules: override_dh_auto_test: python2 debian/run_tests.py python3 debian/run_tests.py Wonder how many other packages are similar. This particular case looks like it was my fault :-( - from a change made in 2014. It is possible I used the same pattern in other packages, although I can't find anything else right now (not counting a package not in Debian) - from a quick scan of all my */debian/rules files on my system - which I think includes all packages I have ever touched. -- Brian May
pytest-bdd tests
Hello, Concerning pytest-bdd - which is in git and dependant packages now in unstable: I suspect that the tests require the package to be installed first. As they require pytest be able to find the hooks that pytest-bdd has installed. Unfortunately, tests by default happen on the working tree, before installation. I vaguely recall asking something similar before. If somebody could assist and/or give a me a reference to the previous thread, that would be appreciated. Thanks -- Brian May https://linuxpenguins.xyz/brian/
Re: python-parse-type
Nicolas CANIART writes: > But there exists a Python 2.7 backport: the enum34 package (there are > others but I think this one is the most used and standard). See > https://pypi.python.org/pypi/enum34/1.1.6 Wondering why I thought otherwise. I tested this by running "python" and then "import enum". Hmmm. I wonder if I had a Python3 virtualenv active at the time... Oh well, thanks for the correction. -- Brian May
Re: python-parse-type
Piotr Ożarowski writes: > packaged as python-enum34 (correct name is python-enum, that's why you > didn't find it most probably) I see the following packages: python-enum - robust enumerated type support in Python python3-enum34 - backport of Python 3.4's enum package The first is wheezy and jessie only, and the later looks like Python3 only. Oh, I see, there is a python-enum34 package too... Will try that. Thanks for your help. -- Brian May
python-parse-type
Hello, Trying to build the python-parse-type package on Sid (source is in git for DPMT), required by python-pytest-bdd, I get the following error repeated a number of times: Traceback: tests/test_parse_util.py:7: in from .parse_type_test import TestCase, unittest tests/parse_type_test.py:3: in from parse_type import TypeBuilder parse_type/__init__.py:3: in from parse_type.cardinality import Cardinality parse_type/cardinality.py:8: in from enum import Enum E ImportError: No module named enum Huh? I thought enum is a standed python feature for both versions (2.7 and 3.5) of python in Sid. Any ideas? -- Brian May https://linuxpenguins.xyz/brian/
Re: Fwd: next version of csvkit
On 2017-04-04 08:21, Brian May wrote: > I would suggest that Buster have Python 2.7, however we only support 3rd > party libraries where it is practical to do so. Any library that has > dropped Python 2.7 support upstream, is not practical for us to support > in Python2. Anything that depends on such a package (directly or > indirectly) also is not practical for us to support. I just noticed that Ubuntu plan to drop Python 2.7 completely - from default installs at least - for the 18.04 release: "Plans for 18.04 LTS Overarching goals include: Python 3 only on the default installs for desktop, server, touch, snappy images. (Some may already be there.) Python 3.6 transition" https://wiki.ubuntu.com/Python Trying to find out what the situation will be for the 17.04 release, not finding much yet however.
Re: Fwd: next version of csvkit
Vincent Bernat writes: > On the current subject, I also agree we should not drop prematurely > packages targeted to Python 2. It is likely the support will be extended > past 2020, at least by distributions with a 10-year support. RHEL 7 will be supported until 2024. https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#RHEL_7 I seem to recall RH had a commitment to support Python 2.7 until 2030, but I can't find that now. However, just because some random distribution is supporting Python 2 past 2020, doesn't mean we have any obligation to do so. Also "we support Python 2.7" doesn't mean "support Python 2.7 in unstable." It is possible that we will continue supporting Stretch, post 2020 as a LTS release. https://wiki.debian.org/LTS Providing *full* Python 2.7 support in unstable is likely to prove to be harder and harder when various upstreams start dropping Python 2.7 support, starting with Django this December. e.g. When Django drops support, and we upload that version to unstable, suddenly everything that depends on Django will also fail to work under Python 2.7. https://docs.djangoproject.com/en/dev/releases/2.0/ If Django 2.0 is released on schedule, I would like to see it in Buster - assuming our release cycle remains every 2 years, that will make it early 2019. I would suggest that Buster have Python 2.7, however we only support 3rd party libraries where it is practical to do so. Any library that has dropped Python 2.7 support upstream, is not practical for us to support in Python2. Anything that depends on such a package (directly or indirectly) also is not practical for us to support. -- Brian May
Re: What should Debian do about Python 2? (was Re: next version of csvkit)
Barry Warsaw writes: > For libraries that already support 2 and 3, I don't think we necessarily need > to actively drop Python 2 yet. We have great tools, so it's usually just as > easy to continue supporting both. I'm on the fence for new library packages, > but I suppose if it's also just as easy to support both, we might as well go > through NEW for both, since it's easier to drop binary packages than add them. It is perhaps worth noting that Django 2.0 is due to be released in December: https://www.djangoproject.com/weblog/2015/jun/25/roadmap/ It will require Python >= 3.5 - that is no support for Python 2.x. https://docs.djangoproject.com/en/dev/releases/2.0/ -- Brian May
Re: Updating Celery, Kombu, python-amqp
Michael Fladischer writes: > This seems to be the best way to deal with this. I don't think that > python-amqp 2.x should be uploaded to unstable as it would potentially > break a lot of things in OpenStack. I will wait a little bit in case there is a response to https://bugs.debian.org/858586, however I tend to think this might be the best way forward. -- Brian May
Re: Updating Celery, Kombu, python-amqp
Christopher Hoskin writes: > I've filed a bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858586 > > Very sorry about this mess. This is what comes of trying to do > something complex and precise late at night after a long day's work :( I can't complain. I have also accidentally uploaded to unstable instead of experimental for the same reason. IIRC I didn't understand how the sbuild options worked. I have now put a check in my build scripts to prevent this type of mistake happening. I strongly recommend to use dput-ng, it will stop this kind of mistake. I just checked this to make sure: % dput -s ftp-master python-mkdocs_0.16.1-1_i386.changes Not uploading for real - dry run Uploading python-mkdocs using ftp to ftp-master (host: ftp.upload.debian.org; directory: /pub/UploadQueue/) running allowed-distribution: check whether a local profile permits uploads to the target distribution running protected-distribution: warn before uploading to distributions where a special policy applies running checksum: verify checksums before uploading running suite-mismatch: check the target distribution for common errors Upload is targeting experimental but the changes will hit unstable Upload is targeting `experimental', but the changes will hit `unstable'. Looks like you forgot -d experimental when invoking sbuild. Although I used the -s option (I don't won't to risk making the same error!), I believe if I didn't, it wouldn't let me upload this package anyway. -- Brian May
Re: Updating Celery, Kombu, python-amqp
Christopher Hoskin writes: > What worries me is: > > apt-rdepends -r python-amqp I wasn't aware of this command. Thanks for this. If I understand this command correctly, it is showing everything that depends directly and indirectly on python-amqp? Hmm. Looks like a large number of these are due to python-oslo.messaging. So can't use the argument that the update to python-kombu has already broken these. So if we upgrade python-amqp *and* that (worse case) requires python-oslo.messaging be upgraded too, that is a lot of packages (listed below) that *directly* depend on python-oslo.messaging. Eventually we will have to deal with this, maybe during the freeze isn't a good time? > python-oslo.messaging > Reverse Depends: oslo-messaging-zmq-receiver (= 5.10.0-2) > Reverse Depends: python-aodh (>= 3.0.0-2) > Reverse Depends: python-barbican (>= 1:3.0.0-1) > Reverse Depends: python-ceilometer (>= 1:7.0.1-1) > Reverse Depends: python-ceilometermiddleware (>= 0.5.0-3) > Reverse Depends: python-cinder (>= 2:9.0.0-3) > Reverse Depends: python-congress (>= 4.0.0+dfsg1-3) > Reverse Depends: python-designate (>= 1:3.0.0-2) > Reverse Depends: python-glance (>= 2:13.0.0-2) > Reverse Depends: python-glare (>= 0.1.0-3) > Reverse Depends: python-heat (>= 1:7.0.0-3) > Reverse Depends: python-ironic (>= 1:6.2.0-2) > Reverse Depends: python-keystone (>= 2:10.0.0-6) > Reverse Depends: python-magnum (>= 3.1.1-2) > Reverse Depends: python-manila (>= 1:3.0.0-2) > Reverse Depends: python-mistral (>= 3.0.0-1) > Reverse Depends: python-murano (>= 1:3.0.0-2) > Reverse Depends: python-networking-sfc (>= 2.0.1~git20160926.27f311e-1) > Reverse Depends: python-neutron (>= 2:9.1.1-1) > Reverse Depends: python-neutron-dynamic-routing (>= 2:9.0.0-1.2) > Reverse Depends: python-neutron-fwaas (>= 1:9.0.0-3) > Reverse Depends: python-neutron-lbaas (>= 1:9.1.0-2) > Reverse Depends: python-neutron-lib (>= 0.4.0-3) > Reverse Depends: python-neutron-vpnaas (>= 2:9.0.0-3) > Reverse Depends: python-nova (>= 2:14.0.0-3) > Reverse Depends: python-oslo.versionedobjects (>= 1.17.0-2) > Reverse Depends: python-osprofiler (>= 1.4.0-2) > Reverse Depends: python-sahara (>= 1:5.0.0-2) > Reverse Depends: python-senlin (>= 2.0.0-2) > Reverse Depends: python-trove (>= 1:6.0.0-2) > Reverse Depends: python-watcher (>= 0.30.0-4) Alternative: maybe I should go to the other plan of uploading the old version of kombu with an increased epoch? -- Brian May
Re: Updating Celery, Kombu, python-amqp
Brian May writes: > * Upload python-amqp 2.1.4 to unstable (plus anything that this > breaks??). I an inclined to think this might be the best option. There are only two packages that depend on python-amqp - that I can see anyway, and one of them is python-kombu. # apt-cache rdepends python-amqp python-amqp Reverse Depends: python-oslo.messaging python-kombu python-kombu python-kombu python-kombu python-oslo.messaging Any objections to uploading the experimental version of python-amqp into unstable? -- Brian May
Re: Updating Celery, Kombu, python-amqp
On 2017-03-24 08:33, Christopher Hoskin wrote: > Presumably it will also run into trouble as python-amqp is at 1.4.9 in > unstable, but 2.1.4 from experimental is required. Yuck. I guess the options we have available are (without any evaluation or filtering of bad or stupid options): * Try to get Kombu working with older 2.1.4. * Ignore breakage until after freeze. * Upload python-amqp 2.1.4 to unstable (plus anything that this breaks??). * Upload previous Kombu to unstable, using an epoch for the version (and all subsequent uploads). * Upload previous Kombu to unstable, without adjusting version, and watch for automatic rejection email. Take legal action against DAK for the improper rejection. * Hope aliens invade Earth within the next several days, and they can deal with this, while the human race is subject to become slaves for eternity. Any other options?
Re: Updating Celery, Kombu, python-amqp
Brian May writes:
> Looks like this change has problems, see #858540. Suspect a missing
> depends on the vine package.
Trying to fix this, I notice it also depends on python{,3}-amqp that
only exists in experimental :-(
--
Brian May
Re: Updating Celery, Kombu, python-amqp
Christopher Hoskin writes: > I've made a mistake, and kombu has got uploaded to unstable instead of > experimental. (I had experimental in the changelog, but didn't pass > "-d experimental" to sbuild on the final build). I'm very sorry about > this. What is the best way to resolve this? Should I file a bug > against the ftp.debian.org pseudo-package? I see your changes in the debian/experimental branch. Wondering if it is probably best to include them now in master (or debian/master?), considering they are now in debian/unstable. Looks like this change has problems, see #858540. Suspect a missing depends on the vine package. -- Brian May
Re: Updating Celery, Kombu, python-amqp
Christopher Hoskin writes: > I've made a mistake, and kombu has got uploaded to unstable instead of > experimental. (I had experimental in the changelog, but didn't pass > "-d experimental" to sbuild on the final build). I'm very sorry about > this. What is the best way to resolve this? Should I file a bug > against the ftp.debian.org pseudo-package? Is this upload likely to break anything in unstable? If not, I wouldn't worry too much about it. Might make things a little bit harder in the unlikely case a update is required for testing, but not impossible. (am assuming it has already entered the archive, or is going to very soon) -- Brian May
Re: Updating Celery, Kombu, python-amqp
Christopher Hoskin writes: > python-amqp depends on vine, but when I previously packaged vine[0], I > only built the python3 package. Is it too soon to start dropping > python2 packages from uploads intended for Buster? I am hardly any authoritative source for this team, but I don't see any problems. Just need to be mindful of anything that depends or build depends on the python-* on the package you are removing - if you break a large number of packages (including cascading breakages), maybe not worth it. Just yet anyway. Or maybe if one of the packages is a highly popular package, might want to exercise a bit more caution. I don't think the packages mentioned so far count. -- Brian May
Re: PyPI source or github source?
Thomas Goirand writes: > IMO, upstream are right that the PyPi releases should be minimal. They > are, from my view point, a binary release, not a source release. To go against this, often PyPI releases contain *.pyc files. Looking at django-filter 0.13.0 right now. -- Brian May
Re: Updating Celery, Kombu, python-amqp
Christopher Hoskin writes: > Thanks. I'm new to gbp pq, but beginning to get the hang of it. Your changes looks good to me, I have now made them. FYI, I believe anybody can create an account and make changes to the wiki. > Thanks for your help! Thanks for your help! -- Brian May
Re: PyPI source or github source?
Ghislain Vaillant writes: > Do you get rid of the useless dotfiles (gitignore, ci settings, tox...) > or leave them alone then? So far .. they have never caused any problems. So leave them as is. Think you can leave tox, that can still be useful. -- Brian May
Re: Updating Celery, Kombu, python-amqp
On 2017-03-14 14:48, Christopher Hoskin wrote: > For reasons of my own, I need to create a Celery 4.0.2 Debian package. This > means also updating the Kombu and AMQP packages. As I'm doing this work > anyway, > my preference would be to share it with the World through DPMT. > > However, I notice that python-amqp has a lot of other reverse dependancies, > including OpenStack, and that we're currently in a release freeze. I've also > seen there's been some discussion about using the DEP14 branch/tag convention > and switching to gbp pq. > > Would people be happy for me to start updating Celery and its dependancies, > uploading the results to experimental, or should I keep my work to myself for > the time being? As an uploader for celery, kombu, and python-amqp, I see no problem myself. I can't speak for other packages, and definitely I can't speak for packages not under DPMT. For now, I would suggest creating a debian/experimental branch, switching to gbp pq (as using non-standard branch names is easier with gbp pq), and then continuing. I have done this already for the python-mkdocs package. If you need any help, let me know.
Re: PyPI source or github source?
Scott Kitterman writes: > Like Barry, I've never had an issue with upstreams fixing their MANIFEST.in > so > that the sdist is complete when I point out the issue. I have had some people who do argue that sdist is an installation format, not a source format - if you want the source use github. I think most of them eventually do change, however it makes me a bit uneasy that maybe they might be right. As a result, some of my recent packages I have used github, rather then try to "fix" things on PyPI. That way I can be sure that the build will always be consistant, and not suddenly and unexpectedly drop files. -- Brian May
Re: PyPI source or github source?
Barry Warsaw writes: > I've so far only encountered one package that releases on GitHub and not PyPI: > pyparted. And I've filed an upstream bug about that. I just found another one: python-ledger. Unfortunately in this case, Python packages are also bundled with the C code (libraries and client). This will make it hard to fix #857335 (python3 support) as upstream only provide python3 support at the moment in an experimental branch, and don't appear to be in any hurry to merge the experimental branch. So I don't expect it to appear in PyPI anytime soon. -- Brian May
Re: GnuPG signatures on PyPI: why so few?
Donald Stufft writes: > https://mail.python.org/pipermail/distutils-sig/2016-May/028933.html > <https://mail.python.org/pipermail/distutils-sig/2016-May/028933.html> "I am aware of a single tool anywhere that actively supports verifying the signatures that people upload to PyPI, and that is Debian's uscan program. Even in that case the people writing the Debian watch file have to hardcode in a signing key into it and in my experience, when faced with a validation error it's not unusual for Debian to simply disable signature checking for that project and/or just blindly update the key to whatever the new key is." I would never just blindly disable signature checking or update the key without carefully checking that this is legitimate first (and/or carefully checking the diff). For example, if releases were signed by person A, but now signed by person B, there should be some sort of public record of this fact. If not, ask on a public forum. If you remove signatures (or don't supply them in the first place), then we - as Debian packagers - have no way of validating the upload. So you only need to compromise the package the maintainer downloads, and subsequently everyone who uses the (signed) Debian packaging is affected. If however PyPI were to remove signatures, this would make the decision whether to use PyPI or github as the source somewhat easier. -- Brian May
Re: GnuPG signatures on PyPI: why so few?
Ben Finney writes: > However, this only works if upstream releases are actually accompanied > by a valid GnuPG signature each time. The PyPI infrastructure supports > this; why isn't it more widely encouraged? One reason I have found for myself: I can forget to sign the package when uploading to PyPI, and PyPI doesn't let you make any changes after the package is uploaded without changing the version (including adding signature file). There is a long running bug report on this, it is not going to get fixed (TLDR it is not a bug, it is a design feature to allow for caching). Maybe there is some way of turning signatures on by default, so I don't have to remember for every upload, if so, I haven't been able to work it out yet however. -- Brian May
PyPI source or github source?
Ben Finney writes: > Debian's UScan has the ability to find, download, and verify the GnuPG > signature for a package source release. Lintian will remind the > maintainer if a Debian source package is not taking advantage of this. A related issue is: Should we be using PyPI as our source of packages? Or github? You mention a very good reason why PyPI should be the preferred form, packages *can* be signed by the author. However, often packages in PyPI are not the complete source package you would get from github. They may be sufficient for installations, but often not for Debian packaging - which really should have the complete source package. e.g. they can be missing tests, license files, documentation that doesn't get installed, etc. Sure, you could argue that PyPI source packages should contain everything the github package does. In fact there is a PyPI tool to help get the MANIFEST.in correct for such purposes - https://pypi.python.org/pypi/check-manifest; however a counter argument could also be made that upstrems generally don't care about such issues - probably won't notice any regressions - if it installs from PyPI that is all that really matters - and the only way we can be sure we are getting the complete source iis from github. Unfortunately, github releases cannot (AFAIK) easily be signed, unless you retrieve signed git tags directly from git (which is not supported by uscan AFAIK). Would be good if gbp buildpackage supported signing git tags, I don't think it does either. I started off thinking github was the best source, then slowly swayed towards PyPI, now I am thinking maybe github again. Comments? Some related issues: * Do we consider signed git tags / commits secure, considering they are based on SHA1? * Is there any point having signed PyPI releases when (very likely) the underlying upstream git repository has no signatures? * Is there any point having signed PyPI releases when (very likely) the public key is stored in an insecure DPMT respository on git.debian.org? -- Brian May
Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)
Brian May writes: > git read-tree --reset -u upstream > git reset -- debian > git checkout debian > git rm debian/.git-dpm I have tried these steps on python-mkdocs in the debian/experimental branch, and then upgraded to the latest upstream (using instructions on wiki). Works perfectly[1]. The only unexpected problem I had is that "gbp import-orig --uscan", by default, switches to the master branch and attempts to merge the new upstream there. Which wasn't going to work, because master still is the patches-applied git-dpm version. I had assumed that it would work on the current branch; it doesn't. The wiki should be ammended with instructions on how to edit debian/gbp.conf at the appropriate steps. Writing a new default to debian/gbp.conf does fix this. The above also assumes that upstream==origin/upstream==latest upstream. Which means you need to have done a git pull recently on the upstream branch. Depending on the circumstances, using origin/upstream might be a better choice rather then upstream. Notes: [1] Well apart from a new "source-is-missing" lintian warning, probably from the new upstream. So probably not ready for upload just yet. -- Brian May
Re: Adopting OpenStack packages
Simon McVittie writes: > Here's a maybe-stupid idea: use http://dep.debian.net/deps/dep14/ branch > naming (debian/master, debian/experimental) for that branch, and switch to > it as the default branch (edit foo.git/HEAD on alioth) when unfreezing > and "officially" switching to gbp-pq? One thing we could do right now, for selected packages, is create a debian/experimental branch, switch to gbp-pq, update to latest upstream, and upload to experimental. This will not interfere in any way to do updates to unstable/testing - which still use the master branch, and similarly won't cause any confusion which branch to use. These packages that we do this to probably should be excluded from any post-freeze automatic bulk switch to gbp-pq however. As the procedure is likely to different (unless there are changes in the master branch, this probably just involve creating a new debian/master branch from debian/experimental and deleting the old master branch). It might pay to have a list somewhere of packages that have already been converted to gbp-pq, and what branches. Of course it is easy to autodetect this too, just look for the presence of a debian/.git-dpm file in that selected branches. Before doing any automated conversion, we should make the following checks on the following branches: * master: exists and has debian/.git-dpm file * debian/master: this branch should not exist - no DPMT package should be using this branch name yet. * debian/experimental: if this exists it should have a debian/.git-dpm If any of these checks fails, the respository should be converted manually. Or it might be an indication that the repository is already in the required format. Any other branches are probably not that important for the initial conversion and can be done manually as required. Assuming at the moment, that only few packages would require manual processing, otherwise this may require a rethink. -- Brian May
Re: Transition away from git-dpm was: Re: Adopting OpenStack packages
Thomas Goirand writes: >> Why debian/unstable, and not debian/sid? > > Because "unstable" is what we write in debian/changelog, so that's > consistent, and also consistent if we upload to experimental. But I'm > fine either ways anyway, if others would like to use debian/sid because > it's faster to type. At the moment - since there were no objections yet - I have revised the wiki documentation (link already provided) to include DEP-14 and debian/master (as per DEP-14). -- Brian May
Re: Transition away from git-dpm was: Re: Adopting OpenStack packages
On 2017-03-07 08:43, Thomas Goirand wrote: > I prefer if we use debian/unstable rather than debian/master though, so > it is more explicit where we upload that branch. My reading of DEP-14 is that is says we should use debian/master. Not that I care much myself, either is fine with me. Why debian/unstable, and not debian/sid? > Also, it'd be wise to > set that branch as default when cloning the repository. ie we shall ran > on Alioth: > > git symbolic-ref HEAD refs/heads/debian/unstable > > so that debian/unstable becomes the default branch. This has a good > chance to avoid confusion between the old "master" (ie: git-dpm) branch > and the new DEP14 style that we would adopt. I didn't know you could do this. Good to know. > When doing this, we should also make sure to clearly self-document this > using: > > # cat debian/gbp.conf > [DEFAULT] > debian-branch = debian/unstable > > Last, I would consider it a nice improvement. Not a critical one. So if > others feel like we should keep the git-dpm old layout to avoid > confusing people, I wouldn't mind so much. I would also suggest making the same change (maybe with an appropriate comment) on the old branch. It should result in people checking out the wrong branch being unable to build with gbp, and hopefully this should also serve as a reference to the correct branch.
Re: Transition away from git-dpm was: Re: Adopting OpenStack packages
Scott Kitterman writes: > Personally, I don't know enough to have an opinion. I'm interested in the > views of DPMT members with gbp pq experience. What's the consensus about > branch naming (all I know is for git-dpm, it was pretty hard wired)? I tend to think that branching will easier with git pq. I seem to remember some maintainers having problems with non-standard branch names under git dpm. So one valid reason for not adopting different branches will no longer apply. I personally think that DEP14 would be a good idea. I think the only difference people would notice is that master is renamed to debian/master. We would need to be careful though, having both a master and a debian/master - even during transition planning - could be confusing. Which one do I update? Probably no way to mark a branch read only on alioth either (?). After the transition, what happens to the master branch? Do we delete it? -- Brian May
Re: Adopting OpenStack packages
Vincent Bernat writes: > I think you mean git-dpm. Whoops. Yes, of course. -- Brian May
Re: Adopting OpenStack packages
On 2017-03-06 10:15, Barry Warsaw wrote: > On Mar 05, 2017, at 01:47 AM, Thomas Goirand wrote: > >> Why waiting? The freeze is typically a time of very low activity and low >> disturbance. That's a perfect moment for doing the switch. > > I think it's generally been the consensus, even outside of this team, that > doing vcs or other disruptive switches are bad ideas during times of release > freezes. For example, upstream CPython recently switched to git + github, but > while an enormous amount of work went into making that as smooth as possible > beforehand, the actual switch wasn't done until after the 3.6 release. More importantly, from my perspective, I am unlikely to be making any significant changes (in fact maybe no changes) to any of my packages until after the freeze. So there doesn't seem to be much point in trying to rush this through, right now. After the freeze, some of my packages will no doubt require updating the the latest upstream version. This will be a good test for gbp pq. If people wanted to, now would be a good time to document/implement/test the procedure for doing the conversion (without actually doing it for real).
Re: Adopting OpenStack packages
On 2017-03-06 10:54, Thomas Goirand wrote: > I'm hereby volunteering for such a sprint (if I hopefully make it to > Montreal). Hopefully, migrating from git-dpm to git-pq wont be as hard > as from SVN to Git. Great! The sooner (after the freeze) we can do this, the better IMHO. git-dpm looked good at the time, however the more I think about it, the more I think gbp is the superior solution - especially for a team effort. It is very easy to break gbp pq unless you are careful to follow correct procedures. Once a broken repository is pushed (e.g. manual changes to debian/patches/*), it is not easy to fix without liberal use of pushing a rebased repository. Or starting git-dpm from scratch. If there was a conflict with debian patches (fortunately this hasn't happened to me yet), I think it would be very challenging to resolve the conflict with git-dpm (not that gbp pq is going to be great in this situation either, however I think it would be easier to understand what is going on, and hence find a good solution). The concept to convert from git-dpm to gbp pq is very very easy: 1. Delete debian/.git-dpm 2. Unapply all patches. 3. Commit and push. (repeat for all branches on all repositories) Step 2 is easier said then done. I can do it easy enough on my own packages. I think we need a documented process anyone can follow. Plus dealing with errors as required (e.g. if unapplying patches causes conflicts due to non-compliant git-dpm package) - if anything like this happens - hopefully on not many packages, these packages might require manual processing. The obvious way "quilt pop -a" doesn't work, because the quilt .pc directory does not exist, and quilt thinks the patches are already unapplied. I sent an email previously with some (untested) suggestions I had.
Re: Adopting OpenStack packages
Thomas Goirand writes: > And I'm not even addressing yet the horrible git-dpm troubles, how > many more years the team is forcibly burying every contributor into. There is discussion on changing this. The consensus seems to be we should wait until after the next release however. > Plus Alioth is a security nightmare, and it's loaded so much that even > a simple git push can take hours (real life experience). I have not noticed this. Maybe the repositories I have dealt with are small and simple. (I don't have any opinions on what should happen with the open stack packages however). -- Brian May
Re: PAPT and git
Barry Warsaw writes: > Yes! Stefano has a bunch of scripts that he used to convert DPMT svn to git, > so there's a great starting place. Probably the main thing to change there > would be to forego conversion to git-dpm and work on conversion to > gbp-pq. I would suggest waiting until after the freeze. This is a bigger and much more invasive change then simply converting git-dpm to gbp-pq. > Or, let's be expedient and use the existing scripts to go to git-dpm for now, > taking up gbp-pq transition along with DPMT after Stretch. I haven't looked at the scripts so I don't know what state they are in, however I think it would be far simpler to go straight to gbp-pq. Converting to git-dpm is, I think, a complicated task compared with going straight to gbp-pq. -- Brian May
Pending broken links
Hello, I have noticed that the automatically generated links sent to the BTS on git changes that close bugs are broken. e.g. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855510#10 has the following link: http://git.debian.org/?p=python-modules/packages/slimit.git;a=commitdiff;h=d20c791 Which generates the following error: 404 - No such project Regards -- Brian May https://linuxpenguins.xyz/brian/
Re: How to split modules in multiple deb packages
Dominik George writes: > This is not a Python package. > > (Hint: no __init__.py…) Not required for Python3. https://www.python.org/dev/peps/pep-0420/ -- Brian May
Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)
Scott Kitterman writes: > We know in the DPMT context what debcheckout will produce, so for our > purposes they don't matter. > > How does dgit avoid maintainer forgot to push problems without being limited > to the granularity of one commit per upload? When you upload a package, you upload the *.debs and push to git a the same time. With the one dgit command that checks everything is consistant, and tags things appropriately. I not sure of the exact details of how the push is done yet. I think dgit would really help with the problem I occasionally get: Does this git source really correspond with the package that was uploaded. Mistakes can happen in git that can result in you looking at one git version that is very different to what was uploaded. Yes, this does happen. Mostly however, I think the prime benefit of using dgit would be that it helps other non-team members maintain the package - as does happen from time to time in the form on NMUs. We can help these people by sticking to a standard that others can use. It would not directly help DPMT workflow, as that mostly remains as is. Hence my first priority would be to change to GBP PQ for work flow, and then worry about dgit after I have had a chance to play with dgit a bit more. -- Brian May
Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)
Brian May writes: > git read-tree --reset -u upstream > git reset -- debian > git checkout debian > git rm debian/.git-dpm git commit Of course... -- Brian May
Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)
Barry Warsaw writes: > One section I think we should add at some point is instructions on how to > manually convert to gbp-pq, at least until we do a mass conversion. Yes agreed. Not sure how to unapply all patches. "quilt pop -a" won't work, quilt doesn't realize the patches are applied. "git checkout upstream -- ." would work, but won't delete any files that were created by the patch. Maybe something like the following? git read-tree --reset -u upstream git reset -- debian git checkout debian git rm debian/.git-dpm The first line sets the tree as per the latest upstream (assuming this is uptodate) and then restores the debian directory that got deleted. Then we just have to delete the debian/.git-dpm file and are finished. -- Brian May
Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)
Brian May writes: > https://wiki.debian.org/Python/GitPackagingPQ > > So far it is just a clone, I haven't tried making any changes. I have gone through and made numerous updates. There might be errors, as I was going from memory for some of this stuff. I didn't specify anything for dgit. The only sections that would require changing would be the building and uploading sections, everything else documented here would be unchanged. -- Brian May
Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)
kuLa writes: > dgit indeed is using it's own repos: > https://browse.dgit.debian.org/ > git.dgit.debian.org The way I understand it is that dgit is simply a replacement for the upload operation. To implement this with the required checks, it is recommended (but not required) that you use its build operation. Instead of using "dput" or similar, you use "dgit push". This checks the most recent build and makes sure it was built correctly from git HEAD, and then uploads the build to debian *and* the source to git.dgit.debian.org Apart from build and upload there are no other changes to standard git-dpm or gbp pq procedures. This provides one key benefit for us, we can be reasonably confident that the upload corresponds with a published git source. As an example of an existing dgit package with multiple patches, have a look at Samba: https://browse.dgit.debian.org/samba.git/tree/debian/patches Having said that, it looks like the server might be having problems at the moment, I can't clone any packages. [brian:/tmp] % dgit clone samba canonical suite name for unstable is sid fetching existing git history remote: fatal: Out of memory, calloc failed remote: aborting due to possible repository corruption on the remote side. fatal: protocol error: bad pack header dgit: failed command: git fetch -p -n -q https://git.dgit.debian.org/samba '+refs/tags/archive/debian/*:refs/dgit-fetch/debian/tags/archive/debian/*' '+refs/tags/debian/*:refs/dgit-fetch/debian/tags/debian/*' '+refs/dgit/sid:refs/dgit-fetch/debian/dgit/sid' dgit: subprocess failed with error exit status 128 -- Brian May
Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)
Brian May writes: > [brian:~/tree … modules/factory-boy] master 255 ± dgit --gbp --clean=git > sbuild --verbose > Format `3.0 (quilt)', need to check/update patch stack > examining quilt state (multiple patches, gbp mode) > dgit: split brain (separate dgit view) may be needed (--quilt=gbp). > dgit: base trees orig=3b9eaf2cb2a9245a1c10 o+d/p=6f1d04c157a8cd0a7eea > dgit: quilt differences: src: ## orig ## gitignores: == orig == > dgit: quilt differences: HEAD ## o+d/p HEAD == o+d/p > dgit: --quilt=gbp specified, implying patches-unapplied git tree > dgit: but git tree differs from orig in upstream files. > > This error puzzles me, to me it seems to be saying there is a mismatch > between git with patches unapplied and the *.orig.tar.gz file - however > I don't think this is the case. Ok, so there really was a difference: the git archive was missing the "docs/_static/.keep_dir" file that is included in the upstream file. Probably good that dgit detects discrepancies such as these, however not so good that it took me sometime to work out the problem based on the given message. If it told me what was different, it would be much be helpful. (also leads to the question why this file was missing from my import last month - but I can't remember what I did now) When I did build the package I can confirm that the generated source package had multiple patch files (as expected). -- Brian May
Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)
Scott Kitterman writes: > How is that different/better than debcheckout? I am still learning dgit, however I think that dgit uses its own git repositories. dgit-repos. I am not sure where these are located or how access is controlled. >From the man page for push "This will push your git history to the dgit-repos, but you probably want to follow it up with a push to alioth." -- Brian May
