Re: Bug#758013: s3ql autopkg test regression
On 08/20/2014 03:14 AM, Matthias Klose wrote: > Am 20.08.2014 um 06:52 schrieb Nikolaus Rath: >> If someone cares deeply about this, the necessary patch is at >> https://bitbucket.org/nikratio/s3ql/commits/9a8c0ebbff390555e63b7e203b999b89aabbb86e/raw/. >> >> >> I did not add it to the debian package yet because I considered it a >> minor issue that I did not want to bug my sponsor with. But if some DD >> wants to sponsor a new upload right away to get this fixed, I'm happy to >> update the package in SVN. > > sure, I can do this. SVN is updated. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53f5469d.3020...@rath.org
Re: python-openssl unavailable in sid
On 21 August 2014 10:42, Cyril Brulebois wrote: > Brian May (2014-08-21): > > Can somebody please tell me why python-openssl and python3-openssl isn't > > available in sid? > […] > > It appears that the packages produced have changed to architecture > > dependant packages, seriously wondering if maybe this got DAK confused. > Obviously I meant to say "... changed to architecture *IN*dependant packages". :-) Adding ftpmasters in the loop to make sure they see your report. > Thanks for this. dak sees: > python-openssl | 0.14-1 | sid | all > > while the amd64 Packages file only lists: > python-openssl-dbg (amd64) > python-openssl-doc (all) > python3-openssl-dbg (amd64) > > https://ftp-master.debian.org/removals.txt reports that the following > packages were indeed removed from sid: > python-openssl | 0.13.1-2+b1 | amd64, armel, armhf, hurd-i386, i386, > kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390x, sparc > python3-openssl | 0.13.1-2+b1 | amd64, armel, armhf, hurd-i386, i386, > kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390x, sparc > > So it looks to me it might “just” be about getting arch:all packages > listed again in Packages files. > -- Brian May
Re: python-openssl unavailable in sid
Brian May (2014-08-21): > Can somebody please tell me why python-openssl and python3-openssl isn't > available in sid? […] > It appears that the packages produced have changed to architecture > dependant packages, seriously wondering if maybe this got DAK confused. > > > (this problem is preventing me from uploading a fix for an RC bug) Adding ftpmasters in the loop to make sure they see your report. dak sees: python-openssl | 0.14-1 | sid | all while the amd64 Packages file only lists: python-openssl-dbg (amd64) python-openssl-doc (all) python3-openssl-dbg (amd64) https://ftp-master.debian.org/removals.txt reports that the following packages were indeed removed from sid: python-openssl | 0.13.1-2+b1 | amd64, armel, armhf, hurd-i386, i386, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390x, sparc python3-openssl | 0.13.1-2+b1 | amd64, armel, armhf, hurd-i386, i386, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390x, sparc So it looks to me it might “just” be about getting arch:all packages listed again in Packages files. Mraw, KiBi. signature.asc Description: Digital signature
python-openssl unavailable in sid
Hello, Can somebody please tell me why python-openssl and python3-openssl isn't available in sid? (sid-amd64)root@aquitard:/home/brian/tree/debian/unstable/celery/celery# apt-get update Get:1 http://ftp.au.debian.org sid InRelease [231 kB] Get:2 http://ftp.au.debian.org sid/main Translation-en [4673 kB] Get:3 http://ftp.au.debian.org sid/main amd64 Packages [6887 kB] Fetched 11.8 MB in 6s (1882 kB/s) Reading package lists... Done (sid-amd64)root@aquitard:/home/brian/tree/debian/unstable/celery/celery# apt-get install python-openssl python3-openssl Reading package lists... Done Building dependency tree Reading state information... Done Package python-openssl is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source Package python3-openssl is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source E: Package 'python-openssl' has no installation candidate E: Package 'python3-openssl' has no installation candidate (sid-amd64)root@aquitard:/home/brian/tree/debian/unstable/celery/celery# apt-cache policy python-openssl-doc python-openssl-doc: Installed: 0.13.1-2 Candidate: 0.13.1-2 Version table: *** 0.13.1-2 0 500 http://ftp.us.debian.org/debian/ sid/main amd64 Packages 100 /var/lib/dpkg/status Note that this version of python-openssl-doc is old, should have been updated two days ago. The following look fine to me: https://packages.qa.debian.org/p/pyopenssl.html https://packages.debian.org/sid/python-openssl Is my local mirror bad? I tried random other mirrors, and get the same problem. Alternatively, is something wrong with my local chroot? It appears that the packages produced have changed to architecture dependant packages, seriously wondering if maybe this got DAK confused. (this problem is preventing me from uploading a fix for an RC bug) Thanks -- Brian May
Re: Playing with git-dpm
On Wed, 20 Aug 2014, Barry Warsaw wrote: > So, because of the way I've named the branches, the full invocation is: > > $ git-buildpackage -S --git-export-dir=../build-area/ > --git-debian-branch=lazr.smtptest --git-upstream-tree=upstream-lazr.smtptest So --git-export-dir is usally best set in ~/.gbp.conf: $ cat ~/.gbp.conf [DEFAULT] pristine-tar = True cleaner = /bin/true [git-buildpackage] sign-tags = True export-dir = ../build-area/ For the other two options, the recommended practice is to put them in debian/gbp.conf but I generally don't do that and just use standard branch names (master / upstream). > Thanks for both the recommendation and the fix! Once the team decides on a > workflow, will it be feasible to write the equivalent of svn-inject? Since > shell access to g.d.o is required it seems like this won't be completely > self-services, but teammates who are DDs could do it for other folks. git-import-dsc is your svn-inject, it will put upstream sources in the upstream branch and will create the master branch based on that with the packaging changes. But the quilt patches won't be applied after this operation. I managed to start using git-dpm on a pre-existing repository but it required an initial "git-dpm init .../mypkg_1.orig.tar.gz" IIRC. Note that all members of the team automatically have shell access to git.debian.org (it's just alioth itself). Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140820201709.gc2...@x230-buxy.home.ouaza.com
Re: Playing with git-dpm
Oh, and I'm assuming that whatever we decide for DPMT would also apply to PAPT, but that may not be a correct assumption? In any case, once we decide, I volunteer to update the wiki documentation (and policy as appropriate) with best practices. Cheers, -Barry signature.asc Description: PGP signature
Re: Playing with git-dpm
Hi Raphael, On Aug 20, 2014, at 09:21 PM, Raphael Hertzog wrote: >Or you can build the package in another directory, like svn-buildpackage >does. I'm not sure if git-dpm has something for this but you can >probably use "git-buildpackage --git-export-dir=../build-area/" in >combination with git-dpm. So, because of the way I've named the branches, the full invocation is: $ git-buildpackage -S --git-export-dir=../build-area/ --git-debian-branch=lazr.smtptest --git-upstream-tree=upstream-lazr.smtptest I really like gbp (and svn-buildpackage) default of using ../build-area/ and this works nicely enough that it might be worth adding to git-dpm (or at least creating another script/alias/config-setting/kludge) to make this work. It's a much better solution - thanks! >I believe that git-dpm can handle any quilt series as input but it will >always rename it based on the commit after a "checkout-patched". I think that's right. >Please do something like this to create new git repositories for >python-modules: >$ ssh git.debian.org >$ cd /git/python-modules >$ ./setup-repository lazr.smtptest "lazr.smtptest packaging" >$ exit > >It will setup some default hooks to to forward the commit notices where >appropriate. > >(I just did the required configuration for you.) Thanks for both the recommendation and the fix! Once the team decides on a workflow, will it be feasible to write the equivalent of svn-inject? Since shell access to g.d.o is required it seems like this won't be completely self-services, but teammates who are DDs could do it for other folks. >It's there now. The repository listing is not updated in real time (too >much I/O involved). I was afraid of that. ;) Cheers, -Barry signature.asc Description: PGP signature
Re: archivemail: joining the team?
[Jonathan Dowland, 2014-08-20] > I have a vested in interested in the "archivemail" package. The maintainer > appears to be MIA so I uploaded an NMU today; the package has had a FTBFS (due > to a bad test) for nearly a year. > > I didn't really notice until afterwards that the package was in team > maintenance. > > Anyway, I was going to look into taking over the package before I realised > that, so instead perhaps I should join the team? I've clicked the 'join' > button > on alioth. thanks for updating archivemail and welcome on board :) -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140820192945.gf4...@sts0.p1otr.com
Re: Playing with git-dpm
On Aug 19, 2014, at 09:44 PM, Barry Warsaw wrote: >Anyway, I think that's it for now. Feel free to muck about in this package, >but please do let me know if you want to push any permanent changes. Tomorrow >I'll probably try to do a new upstream release to fix the typo in the setup.py >so I'll do a new package version and see how well that process works. Done. A few more thoughts: d/patches are handled very nicely. The thing I had to quilt patch in 2.0.1-1, I fixed in the new upstream version. When I updated to the new upstream, git-dpm did the right thing by deleting the entire d/patches directory. I.e. because the specific patch was no longer necessary, it got deleted, but then there were no other patches in the quilt stack, so the whole directory could just be dropped. This was handled completely seamlessly. Be sure you `git push --all --tags` or your upstream-* and pristine-tar branches don't get pushed. --tags of course pushes the tags, and `git-dpm tag` works nicely[*]. I really wish `git-dpm import-new-upstream` would optionally take no arguments, in which case it would call uscan to get the orig.tar.gz before importing. It would just save a little typing. Even cooler would be `git-dpm -vX.Y.Z` in which case it would add the d/changelog entry, uscan to download the new orig.tar.gz, then call import-new-upstream. git-dpm is "just" a shell script so I might try to submit a patch for that. It's a little inconvenient to test out a new upstream tarball. I think this is a corner case, but I'll describe the situation for posterity. I'm both upstream for lazr.smtptest and maintainer, and the bug I hit was in the setup.py so for 2.0.1-1 I just added a quilt patch to work around the problem. Now, I go back to upstream and fix the typo there, but before I release the new upstream, I'd like to test it in the context of a provisional package build. So I `python setup.py sdist` to create the tarball, copy it to blah.orig.tar.gz and then import it into my local git-dpm repo. I do a test build and notice that the upstream patch is not quite right. So I go back to the upstream branch, fix the bug again, generate a new orig.tar.gz and head back to the git-dpm repo. The problem is that I've already imported the 2.0.2 orig.tar.gz. The import had been committed on all three branches, otherwise I wouldn't have been able to test the new potential upstream release. To back out of this and import the newly generated 2.0.2 tarball, I have to checkout all three branches (i.e. upstream-lazr.smtptest, pristine-tar, and lazr.smtptest) and "uncommit" (`git reset --hard HEAD^`) the effects of the import. Now I'm back to a known good place and can replay the import. The other option would have been to do all this in a separate clone until I was happy, but that's kind of icky. I'm not sure what else would work better, and as I say it's a corner case so probably not worth spending much effort on. One last thing: I'm not sure I recommend going with the package name as the branch name. I'm tired of typing `upstream-lazr.smtptest`. The default git-dpm branch names are starting to make more sense. :) Cheers, -Barry signature.asc Description: PGP signature
Re: Playing with git-dpm
Hi Barry, On Tue, 19 Aug 2014, Barry Warsaw wrote: > * The egg-info directory is a PITA. > > The upstream tarball has a lazr.smtptest.egg-info directory. debuild -S blows > this away, and then git thinks I want to delete it. It doesn't get staged, so > it's easy to `git checkout -- lazr.smtptest.egg-info`[3], but it gets annoying > *very* quickly after just a few debuilds. I'm not sure what the best way to > handle this is, if there is one. You can commit the removal, but it will regularly cause merge conflicts. Or you can build the package in another directory, like svn-buildpackage does. I'm not sure if git-dpm has something for this but you can probably use "git-buildpackage --git-export-dir=../build-area/" in combination with git-dpm. > * debian/patches/* get named automatically > > `git-dpm checkout-patched` creates a temporary patch branch. I had to patch > the setup.py, so I just edited it as normal. Note though that you *must* > commit this file while on the patch branch or it doesn't get quilt-ified, but > it will still show up as modified on your packaging branch if you switch to > it. Oh, and the first line of your commit message gets turned into patch > name. I like that it handles quilt-ifying the patch automatically when you > `git-dpm update-patches` but watch out with your commit messages or you may be > left with a patch file that has an odd name. I didn't try to change that and > see if git-dpm could still grok the patch. I believe that git-dpm can handle any quilt series as input but it will always rename it based on the commit after a "checkout-patched". > * Where to push the repo? > > I'm not sure that we have a definitive path on git.debian.org for team > maintained packages under git, but there is a python-modules directory > containing a few packages. So I pushed my branches to > git+ssh://git.debian.org/git/python-modules/packages/lazr.smtptest.git > > It takes a bit of work to create this directory initially, but I found that > gbp has a nice command you can corrupt into doing the right thing for > you, e.g.: Please do something like this to create new git repositories for python-modules: $ ssh git.debian.org $ cd /git/python-modules $ ./setup-repository lazr.smtptest "lazr.smtptest packaging" $ exit It will setup some default hooks to to forward the commit notices where appropriate. (I just did the required configuration for you.) > Oddly, I don't see the repo here: http://anonscm.debian.org/cgit/ but I have > no idea why. It's there now. The repository listing is not updated in real time (too much I/O involved). Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140820192111.gb2...@x230-buxy.home.ouaza.com
archivemail: joining the team?
Hi all, I have a vested in interested in the "archivemail" package. The maintainer appears to be MIA so I uploaded an NMU today; the package has had a FTBFS (due to a bad test) for nearly a year. I didn't really notice until afterwards that the package was in team maintenance. Anyway, I was going to look into taking over the package before I realised that, so instead perhaps I should join the team? I've clicked the 'join' button on alioth. Thanks -- Jonathan Dowland -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140820190731.ga25...@bryant.redmars.org
Re: Playing with git-dpm
On Aug 20, 2014, at 08:26 AM, Vincent Bernat wrote: >This makes auto revert automatic but don't lose the previous content >by keeping the undo history. It also keeps your current position in the >file. Thanks! I'll have to think about whether I want to enable this globally, but it does seem like it would come in handy with git-dpm. Cheers, -Barry signature.asc Description: PGP signature
Bug#758720: ITP: python-astropy-helpers -- Utilities to build and install Astropy affiliated packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: wnpp Severity: wishlist Owner: Ole Streicher X-Debbugs-Cc: debian-de...@lists.debian.org, debian-as...@lists.debian.org, debian-python@lists.debian.org * Package name: python-astropy-helpers Version : 0.4.1 Upstream Author : The Astropy Developers * URL : http://astropy.org * License : BSD Programming Lang: Python Description : Utilities to build and install Astropy affiliated packages This project provides a Python package, astropy_helpers, which includes many build, installation, and documentation-related tools used by the Astropy project, but packaged separately for use by other projects that wish to leverage this work. The motivation behind this package and details of its implementation are in the accepted Astropy Proposal for Enhancement (APE) 4. I am still not sure whether this will be built from a separated source package, of as an additional package of the python-astropy source. Best Ole -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJT9LR/AAoJEHEVr9B3ENz3xj0QAIPexnVRkMemUs0dS/CNfD9c 5zSigmAdEBKLfgsAosbUBgBDl6JrWDFgBnOMArb/w1PIp1oe+8gpsh+TjngJg/yq DSGeADlwGu25oCeDmtiNA8AVHlirV13VbchFTFREkEey0U9w4Wahq2abfBQhXjC9 sMbNJH8cNvDG3ai+/IpYXRxrF3uN/KipUJSGBftfeNuPvunkNWkIt2I82EhezqR9 PAjOIdEAovIizafStyZTlNirmS8F5bSVG7XXTyA6jhx1T53FWagq6y1MP8B33L4S 3EH3eVVjcttD9XlMdsIqLxlsEVPZd3SzjKKQNP1eeLHBUpMOfED7Ao49vay4Pab4 /N4H0uP0DS9yl5hFF9Qg5dA9TsC558x5ufWeNh3PtJH9qKakna8noqIzTDh6dNuy HowvzltCQquqh1fPDCvfR8SF/EKEziP+/gDzwx4XP0iDE/ZBDry/Bjy6bjiklM1L eRhVPu4HC+z0JyBSkUL21W/5M5cjgVsID49bcrKFSuf6NyG88St0yFAYc1B36VWh 0Lgddb+vt6AOO1B4h7ftF6JAYGz24/4M5znHTYN08ISoqChfYbVxZ80JmFQQ6Yau g77gzN/2pPVnghyyaT1z3j31BAGaCbr4Sixny/T8Y3hg+rsQmoE1OamJz55iZ3tL 9L5nWkTlrpYfpdr4hq9L =6naU -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53f4b47f.1030...@liska.ath.cx
Re: Playing with git-dpm
❦ 19 août 2014 21:44 -0400, Barry Warsaw : > * Switching branches makes my editor unhappy. > > Why is this a PITA? Because Emacs will notice that a file you're visiting in > a buffer is changed and will prompt you reload it. I guess because > checkout-patched deletes the debian directory and update-patches restores it, > it makes Emacs unhappy. I suppose you also have to be careful not to write a > buffer to the debian/ directory when in the patched- branch. I am using this snippet: #+begin_src elisp (defun vbe:revert-buffer-keep-history (&rest -) "Revert buffer but keep undo history" (clear-visited-file-modtime) (widen) (let ((inhibit-read-only t) (current-point (point))) (delete-region (point-min) (point-max)) (insert-file-contents (buffer-file-name)) (not-modified) (goto-char current-point) (set-visited-file-modtime))) (setq revert-buffer-function 'vbe:revert-buffer-keep-history) (global-auto-revert-mode 1) ; Auto revert (when no pending changes) #+end_src This makes auto revert automatic but don't lose the previous content by keeping the undo history. It also keeps your current position in the file. -- Write and test a big program in small pieces. - The Elements of Programming Style (Kernighan & Plauger) signature.asc Description: PGP signature
Re: guardian and django1.7
On 19 Aug 2014 18:37, "Brian May" wrote: > > On 19 Aug 2014 18:04, "Raphael Hertzog" wrote: > > Did you fill that new directory with an initial migration generated with > > ./manage.py makemigrations? > > Yes, did that, but than I realized I needed to do testapp. > > So I did just testapp by itself, but suspect both django apps need to be done. > > At which point I ran out of time :-) If this works, my concern, if not obvious: to rename the migrations directories to south_migrations in a debian/patch file will require a patch to delete every file and another patch to recreate it in the new release. This will have to be done/rechecked for every release. Yuck.
Re: Bug#758013: s3ql autopkg test regression
Am 20.08.2014 um 06:52 schrieb Nikolaus Rath: > If someone cares deeply about this, the necessary patch is at > https://bitbucket.org/nikratio/s3ql/commits/9a8c0ebbff390555e63b7e203b999b89aabbb86e/raw/. > > > I did not add it to the debian package yet because I considered it a > minor issue that I did not want to bug my sponsor with. But if some DD > wants to sponsor a new upload right away to get this fixed, I'm happy to > update the package in SVN. sure, I can do this. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53f47510.7000...@debian.org
