Re: Safest way to set python3 as default for `python`
On 16 July 2018 at 08:44, Bastian Venthur wrote: > Hi, > > sorry if this question has been asked before. What is the currently > recommended way to make `python` point to `python3`? I'd like to have it set > on a system default level if possible. > To answer your question. Create a brand new virtualenv, enter said virtualenv, make python point at whatever you want. Use said virtualenv for one thing / one service / strongly coupled things only. Create as many virtualenvs as needed. Above is safe to do, and should not conflict with system python / system packages / OS. -- Regards, Dimitri.
Re: Moving off of git-dpm
On 16 February 2017 at 11:31, Piotr Ożarowski wrote: > Are you guys seriously considering dgit to replace anything other than > dput in DPMT? I'd rather go back to svn-buildpackage than use something > that will not allow me (f.e. as sponsor) to review before uploading! One can totally review before uploading with dgit. dgit takes ownership/syncing of your dgit/* heads. One can totally push master; review it; fix it up; push more; and then as a sponsor if you are happy to publish master one invokes dgit push to update the dgit/* branches & execute dput with a source matching the git tree. Is this the workflow you want? dgit doesn't impose anything what one does with master branch, or any other branch names you want. -- Regards, Dimitri.
Re: pybuild sphinxdoc and extensions
i knew it! there are three identical twins of Piotr. No wonder they
get so much done!
On 23 October 2015 at 15:22, Piotr Ożarowski wrote:
> [Piotr Ożarowski, 2015-10-23]
>> [Piotr Ożarowski, 2015-10-23]
>> > override_dh_auto_build:
>> > dh_auto_build
>> > PYTHONPATH=$(CURDIR)/.pybuild/build_cpython3/ $(MAKE) -C doc html
>> >
>> > no matter which Python 3.X version is the default one
>> > (it still hardcodes ".pybuild" which I don't like, though)
>>
>> which leads back to `pybuild --interpreter python3 --echo {build_dir}`
>> (i.e. new --echo parameter which I suggested last year)
>
> - LOL, you fool, you implemented it already!
>
> override_dh_auto_build:
> dh_auto_build
> PYTHONPATH=`pybuild --build -i python3 -s custom --build-args 'echo
> {build_dir}'`\
> $(MAKE) -C doc html
>
> - oh, you're right, Piotr
> - yeah I'm right! You should listed to me more!
> - bite me!
> --
> evil schizophrenic general Piotr
>
--
Regards,
Dimitri.
Re: admins elections
On 1 October 2015 at 19:44, Piotr Ożarowski wrote: > > [Barry Warsaw, 2015-10-01] > > Team members can have more of a say --and more confidence in-- how the team > > is > > run. If you elect someone to a leadership role, you're giving your support > > to > > them to make the tough decisions. And you have the option of voting them > > out > > at the next election. > > +1 I do not believe in popular vote, I believe in meritocracy =) -- Regards, Dimitri.
Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental
On 30 September 2015 at 10:26, Thomas Kluyver wrote: > On Wed, Sep 30, 2015, at 01:53 AM, Thomas Goirand wrote: >> This has driven >> some contributors away in the past, thinking we don't have team spirit. >> IMO, that's truth, and this kind of thread is hurting again. > > Just to back this up: watching threads like this go past makes working > on/with Debian look very uninviting. At times it seems like DPMT is more > interested in quoting sections of policy at one another than in actually > making stuff work. It looks absolutely like there's no team spirit, > unless you all keep it carefully hidden from the mailing list. If this > is what you're like even to other people with @debian.org email > addresses, I don't want to try doing anything within Debian. > > Thomas K > I see nothing wrong with Goirand's upload. I believe Sandro Tosi is still using the pre-binNMU, pre-NMU, pre-LowNMU, pre-Team packaging maintenance mentality which is not the commonly accepted behaviour and mentality in Debian anymore. Sando, if you don't like something in particular about a particular upload you should fix those points and re-upload and e.g. send an email with a diff to the last uploader with code review and comments. Complaining about the maintainer vs uploader policy does not improve the package in question. As all uploads - good and bad - are always done with only best intentions in mind, do take that into account. Nobody is trying to attack you, your packages, or somehow sabotage Debian. -- Regards, Dimitri.
Re: pybuild and proxies -- could we make "prohibition" optional?
On 27 July 2015 at 21:31, Piotr Ożarowski wrote:
>> > I already followed Dimitri's suggestion to add no_proxy=localhost and
>> > will add your PYBUILD_FAKE_PROXY later today
>>
>> awesome! feel free to tune the name to whatever you feel more appropriate.
>
> I simply do not forward empty http{,s}_proxy, is that good enough?
>
> https://anonscm.debian.org/cgit/dh-python/dh-python.git/commit/?id=052138369f866d5c09b44433f0023950dae28a74
way too pythonic, proceed to go, collect 200.
--
Regards,
Dimitri.
--
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/canbhluhtu7ciizgahtyom1t_yfca_h6fpk6leadswsgyz7z...@mail.gmail.com
Re: pybuild and proxies -- could we make "prohibition" optional?
On 21 July 2015 at 20:17, Yaroslav Halchenko wrote:
> talking about this ;-) :
>
> $> grep -A3 http_proxy pybuild
> if 'http_proxy' not in env:
> env['http_proxy'] = 'http://127.0.0.1:9/'
> if 'https_proxy' not in env:
> env['https_proxy'] = 'https://127.0.0.1:9/'
>
> which is overall GREAT since now I can drop off all those manual http*_proxy
> exports in debian/rules where I know that the application has nothing to do
> with the network. BUT such settings forbid e.g. running any tests even if
> those start/use local server specifically initiated for testing. This is not
> forbidden AFAIK by the policy and the only concern is our buildd farm which
> says that even local interface might not be available. Some
> tools/libraries are smart enough to not try accessing proxy if http_proxy is
> set but empty, but some don't.
>
> So, long story short... would it be ok if I propose/commit a change like
>
> diff --git a/pybuild b/pybuild
> index d7bd35a..4edc175 100755
> --- a/pybuild
> +++ b/pybuild
> @@ -50,10 +50,12 @@ def main(cfg):
> env = environ.copy()
> if 'LC_ALL' not in env:
> env['LC_ALL'] = 'C.UTF-8'
> -if 'http_proxy' not in env:
> -env['http_proxy'] = 'http://127.0.0.1:9/'
> -if 'https_proxy' not in env:
> -env['https_proxy'] = 'https://127.0.0.1:9/'
> +
> +if environ.get('PYBUILD_FAKE_PROXY', '1') == '1':
> +if 'http_proxy' not in env:
> +env['http_proxy'] = 'http://127.0.0.1:9/'
> +if 'https_proxy' not in env:
> +env['https_proxy'] = 'https://127.0.0.1:9/'
>
> if cfg.system:
> certainty = 99
>
> to enable testing when it is feasible to do it without external interactions
> etc?
In practice however we do allow accessing debian ftp archive and
localhost services, thus:
no_proxy=localhost,*.debian.org
would probably be better imho for the balance of "don't allow general
network access", "yet allow sensible networking test-suites to run".
--
Regards,
Dimitri.
--
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/canbhlugfezfqrw4zjndr5rrqysdbye2epv1kkou85xnavwo...@mail.gmail.com
Re: -nspkg.pth and .pth files - should we get rid of them?
On 20 July 2015 at 13:04, Julien Cristau wrote: > On Mon, Jul 20, 2015 at 07:58:13 -0400, Barry Warsaw wrote: > >> On Jul 20, 2015, at 01:12 PM, Julien Cristau wrote: >> >> >Is that a serious question? Why should debian-python, for no good >> >reason, break things that work just fine? >> >> Because it doesn't really work well when you are supporting both Python 2 and >> Python 3. For example, if you have the 'foo' namespace with submodules 'bar' >> and 'baz', you can't write a foo/__init__.py that supports old-style >> namespaces for Python 2 and PEP 420 style namespaces for Python 3 because in >> the latter *you can't have an __init__.py at all*. >> > That's exactly why Debian shouldn't mess with it. If upstream is > python3-only, they can remove __init__.py and go PEP420. If not, they > can use old-style namespaces on both python versions, and there's no > reason for Debian to break that IMO. Would it be fair to have a goal to only have PEP420 style namespaces in python3 world? And if there are upstreams that don't do that now, work with them to achieve this and/or cpython/setuptools/distutils upstream. -- Regards, Dimitri. -- 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/CANBHLUjb4+KtnEDAKDTg=kbxnc-hjffeu3suekgq9uzmxwp...@mail.gmail.com
Re: -nspkg.pth and .pth files - should we get rid of them?
On 20 July 2015 at 09:00, Julien Cristau wrote: > On Mon, Jul 20, 2015 at 09:56:55 +0200, Piotr Ożarowski wrote: > >> [Julien Cristau, 2015-07-20] >> > On Sun, Jul 19, 2015 at 21:28:32 +0200, Piotr Ożarowski wrote: >> > >> > > Should we patch distutils/setuptools to not generate them? It generates >> > > them even for Python 3.X (which has PEP420 implemented) >> > >> > Please don't. Using an pkg_resources-style vs PEP420 namespace should >> > be an upstream decision made individually for each namespace. >> >> dh_py* tools then > > No, since that would break sharing a namespace with parts installed > as a debian package and parts using the normal python tools. And why should debian-python support that? If one wants to mix things, one is better of using virtualenv. I can see the point of re-using system things for compiled extensions and the interpreter itself, but not for the namespace jungles. -- Regards, Dimitri. -- 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/CANBHLUh_=lwj_dgwfaulrxyt_nrfx3se8jedmx_e6ez_0qa...@mail.gmail.com
Re: /usr/bin/python in Python 2 and 3
#!/usr/bin/python32 For bilingual scripts. On 17 Apr 2015 2:30 pm, "Geoffrey Thomas" wrote: > I've written up the proposal I made a few days ago for a /usr/bin/python > launcher that keeps the API of being Python 2, but lets scripts opt in to > running on Python 3: > > https://ldpreload.com/blog/usr-bin-python-23 > > I share the desire for /usr/bin/python to maintain its API of being Python > 2, but I also want to be able to write polyglot Python 2/3 scripts that run > everyhwere -- including on Debian machines with just Python 3. So this is a > way of "doing something else with /usr/bin/python" that's > backwards-compatible for us and all the other distros. It even happens to > be be kind of backwards-compatible for Arch, and Barry's point about > aligning the desires of the distros is a very good one. > > Let me know if you think this is a good or bad idea: I'll submit this as a > PEP as soon as we have rough consensus that this is a good idea. (We can > bikeshed the details once the idea itself is a draft PEP.) > > -- > Geoffrey Thomas > https://ldpreload.com > geo...@ldpreload.com > > > -- > 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/alpine.deb.2.10.1504171655000.18...@cactuar.ldpreload.com > >
Re: Python 2 d-d-a proposal
I am happy to help porting things. I did it for a number of non trivial packages and happy to do more. It's very soothing experience and better than knitting & sudoku. On 15 Apr 2015 2:29 pm, "Paul Tagliamonte" wrote: > Heyya d-p, > > I'd like to send an email to d-d-a asking that project to consider no > longer creating new Debian tools in Python 2. > > I'd like this to have the endorsement of the team, so, does anyone object > to > me asking people to not write new tools in Python 2 only (prefer > alternative > deps or porting), and only use Python 2 in very special curcumstances or > for legacy codebases (perhaps a pitch to move to Python 3), along with a > note that we plan to deprecate Python 2 when upstream support is gone > (2020), which puts us on track for two cycles (Buster) > > > I'll make note of a team which should exist to help with such porting, > (I'm up to help with this) that was one of the items that came out of > the PyCon chit-chat. I got the sense from the room that this would be > OK, but just checking if anyone here has a substantive objection. > > If not, I'll send that out later on today/tomorow. > > > Thanks! > Paul > > -- > .''`. Paul Tagliamonte | Proud Debian Developer > : :' : 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 > `. `'` http://people.debian.org/~paultag > `- http://people.debian.org/~paultag/conduct-statement.txt >
Re: multiprocessing.queues.Queue does not work in pbuilder?
Hello, On 29 January 2015 at 09:01, Ole Streicher wrote: > Hi, > > I am trying to get the release candidate for python-astropy > packaged. The packaging includes a number of tests, where many fail in > pbuilder, which can be traced back to: > > $ sudo pbuilder login > # apt-get install python > # python > Python 2.7.9 (default, Dec 11 2014, 08:58:12) > [GCC 4.9.2] on linux2 > Type "help", "copyright", "credits" or "license" for more information. from multiprocessing.queues import Queue q = Queue(8) > Traceback (most recent call last): > File "", line 1, in > File "/usr/lib/python2.7/multiprocessing/queues.py", line 63, in __init__ > self._rlock = Lock() > File "/usr/lib/python2.7/multiprocessing/synchronize.py", line 147, in > __init__ > SemLock.__init__(self, SEMAPHORE, 1, 1) > File "/usr/lib/python2.7/multiprocessing/synchronize.py", line 75, in > __init__ > sl = self._semlock = _multiprocessing.SemLock(kind, value, maxvalue) > OSError: [Errno 38] Function not implemented > > The cause for this seems to be that /run/user is not mounted; if I mount > manually, it works fine: > > # mkdir /run/user > # mount none /run/user -t tmpfs > # python > Python 2.7.9 (default, Dec 11 2014, 08:58:12) > [GCC 4.9.2] on linux2 > Type "help", "copyright", "credits" or "license" for more information. from multiprocessing.queues import Queue q = Queue(8) > > However, how can/should I do this in debian/rules? /run/user is XDG_RUNTIME_DIR type of stuff, which shouldn't be needed during normal builds. In your case i think you need /dev/shm. I'm not quite sure why pbuilder is not providing it, but the Debian standard build environment - sbuild, does provide it out of the box: $ mk-sbuild sid $ sbuild -A -d sid *.dsc I have tested your example as: $ schroot -u root -c sid-amd64 And it works fine without /run/user, with /dev/shm available (the default chroot had it). (mk-sbuild is available from Debian package ubuntu-dev-tools and may install additional things on first chroot setup) Another alternative is to do source only upload, and it should build fine on the distribution buildd network. -- Regards, Dimitri. -- 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/CANBHLUj7quBCj5nw-zB1K6yk5XWEycPWOS5tcbE=0Zx=o3f...@mail.gmail.com
Re: Age of built packages to be part of the jessie release?
Following on this conversation. I did some simple stats. There are 6361 binary packages that have the same name in stable and testing on (all, amd64) architecture. This translates into 4821 source packages. Skimming through the list of them, I've poked some that for sure will generate a diff if rebuilt. I'm attaching a diff of a no-change rebuild of python-amqplib_1.0.2-1.dsc. As you can see - it gains * multi-arch compatible generated dependencies * the py3compile call correctly specifies compatible version numbers * corrected prerm script that can work even if py3clean is not available * the install size is reduced on python2 package * python2 dependencies are simplified * usr/share/pyshared files are no longer shipped * python2.6 files are no longer shipped Overall, I'm inclined to rebuild all 4821 unrebuild packages, generate diffs, and if there are substantial changes discuss with maintainers / release team to either upload no-change rebuild (arch:all packages) and/or schedule binNMUs (for arch:any packages) Regards, Dimitri. diff -ru old/python3-amqplib/DEBIAN/control new/python3-amqplib/DEBIAN/control --- old/python3-amqplib/DEBIAN/control 2012-03-19 18:54:29.0 + +++ new/python3-amqplib/DEBIAN/control 2014-12-06 21:15:06.0 + @@ -4,7 +4,7 @@ Architecture: all Maintainer: Mikhail Gusarov Installed-Size: 202 -Depends: python3 (>= 3.1.3-13~) +Depends: python3:any (>= 3.3.2-2~) Suggests: python-amqplib-doc Section: python Priority: optional diff -ru old/python3-amqplib/DEBIAN/postinst new/python3-amqplib/DEBIAN/postinst --- old/python3-amqplib/DEBIAN/postinst 2012-03-19 18:54:28.0 + +++ new/python3-amqplib/DEBIAN/postinst 2014-12-06 21:15:06.0 + @@ -1,9 +1,9 @@ #!/bin/sh set -e -# Automatically added by dh_python3: +# Automatically added by dhpython: if which py3compile >/dev/null 2>&1; then - py3compile -p python3-amqplib + py3compile -p python3-amqplib -V 3.0- fi # End automatically added section diff -ru old/python3-amqplib/DEBIAN/prerm new/python3-amqplib/DEBIAN/prerm --- old/python3-amqplib/DEBIAN/prerm2012-03-19 18:54:28.0 + +++ new/python3-amqplib/DEBIAN/prerm2014-12-06 21:15:06.0 + @@ -1,9 +1,12 @@ #!/bin/sh set -e -# Automatically added by dh_python3: +# Automatically added by dhpython: if which py3clean >/dev/null 2>&1; then py3clean -p python3-amqplib +else + dpkg -L python3-amqplib | perl -ne 's,/([^/]*)\.py$,/__pycache__/\1.*, or next; unlink $_ or die $! foreach glob($_)' + find /usr/lib/python3/dist-packages/ -type d -name __pycache__ -empty -print0 | xargs --null --no-run-if-empty rmdir fi # End automatically added section diff -ru old/python-amqplib/DEBIAN/control new/python-amqplib/DEBIAN/control --- old/python-amqplib/DEBIAN/control 2012-03-19 18:54:28.0 + +++ new/python-amqplib/DEBIAN/control 2014-12-06 21:15:06.0 + @@ -2,8 +2,8 @@ Version: 1.0.2-1 Architecture: all Maintainer: Mikhail Gusarov -Installed-Size: 232 -Depends: python2.7 | python2.6, python (>= 2.6.6-7~), python (<< 2.8) +Installed-Size: 202 +Depends: python (>= 2.7), python (<< 2.8) Suggests: python-amqplib-doc Section: python Priority: optional diff -ru old/python-amqplib/DEBIAN/md5sums new/python-amqplib/DEBIAN/md5sums --- old/python-amqplib/DEBIAN/md5sums 2012-03-19 18:54:29.0 + +++ new/python-amqplib/DEBIAN/md5sums 2014-12-06 21:15:07.0 + @@ -1,15 +1,14 @@ -9fed561782d5bce6f687d42ef04af21a usr/lib/python2.6/dist-packages/amqplib-1.0.2.egg-info afb73ab22334ace27595f5e3cedc48f1 usr/lib/python2.7/dist-packages/amqplib-1.0.2.egg-info +68b329da9893e34099c7d8ad5cb9c940 usr/lib/python2.7/dist-packages/amqplib/__init__.py +eb85c7e6645ad0f1a1d1614dcdcdc401 usr/lib/python2.7/dist-packages/amqplib/client_0_8/__init__.py +bb0de492a3f7cc004d8df03b9cd15167 usr/lib/python2.7/dist-packages/amqplib/client_0_8/abstract_channel.py +a874737ad52ff100de75c06709672507 usr/lib/python2.7/dist-packages/amqplib/client_0_8/basic_message.py +dd1e6575f39ef75714a272c87fb19624 usr/lib/python2.7/dist-packages/amqplib/client_0_8/channel.py +fb3276dd7c6a066bdb34132ca1c65b82 usr/lib/python2.7/dist-packages/amqplib/client_0_8/connection.py +1530aceb856fb58758fdce0bcef5db54 usr/lib/python2.7/dist-packages/amqplib/client_0_8/exceptions.py +405b4a8d1c9ab8727e5fe0985f999258 usr/lib/python2.7/dist-packages/amqplib/client_0_8/method_framing.py +ef416a18e00a9f1d6eee3d906f61b017 usr/lib/python2.7/dist-packages/amqplib/client_0_8/serialization.py +5dd509f0277b65108deccad28db16520 usr/lib/python2.7/dist-packages/amqplib/client_0_8/transport.py ca8f4e104236cba255448e0ffeff3974 usr/share/doc/python-amqplib/changelog.Debian.gz bbef86b4d1e1a8e71599e7ff052453ce usr/share/doc/python-amqplib/changelog.gz ceeced913e7cb70ab3d83e1db9764543 usr/share/doc/python-amqplib/copyright -68b329da9893e34099c7d8ad5cb9c940 usr/share/pyshared/a
Re: Keeping upstream commits separate from Debian packaging commits
On 17 October 2014 16:57, Tristan Seligmann wrote: > On 17 October 2014 17:19, Dimitri John Ledkov wrote: >> There are different tag types in git. "Soft" are just named commit >> references and indeed can be renamed at will / point to new commits, >> however signed tags encode: >> object SHA1id >> type type-of-above >> tag tag-name >> tagger normal user name, email, timestamp >> >> tag-message >> >> All signed with gpg. Thus any change to that metadata of a signed tag >> will invalidate signature, or be treated as conflicting tag and thus >> require --force push. > > I stand corrected, tag objects do indeed include a name. However, this > name does not have to be the same as the name of the ref to that tag! > For example, in a package I recently helped sponsor[1]: > LOLz!!! was my initial reaction. But honestly, this does sounds a bit broken =) I was not aware of this property. It does make sense that a signed tag object has unique sha1 and thus one can create multiple tags named "foo" with different sha1 IDs and thus store them in a single git object store without ref names and/or different ref names. However the implications of this are rather severe - what if I copy/rename v1.0.3 tag as a v1.0.5 tag in my mirror and thus trick people into an older version... I'm concerned by this, I'll checkout git mailing list and/or raise this issue there. For some time now I have switched to providing people with sha1id of a GPG signed commit, instead pushing signed tags and providing a signed tag name only. That was only for the sake of minimising amount of refs i publish/pollute. I guess this is for the best. Regards, Dimitri. > mithrandi@lorien ~/d/p/armory> git tag -l | grep 0.92.3 > debian/0.92.3-1 > upstream/v0.92.3 > mithrandi@lorien ~/d/p/armory> git tag -v upstream/v0.92.3 > object 268db0f3fa20c989057bd43343a43b2edbe89aeb > type commit > tag v0.92.3 > tagger Armory Technologies, Inc 1412648447 -0400 > > Tor privacy fixes and msg signing RNG fix > gpg: Signature made Tue 07 Oct 2014 04:20:47 SAST using RSA key ID 98832223 > gpg: Good signature from "Alan C. Reiner (Offline Signing Key) > " > gpg: aka "Alan C. Reiner (Armory Signing Key) > " > gpg: aka "Alan C. Reiner (Armory Signing Key) > " > gpg: WARNING: This key is not certified with a trusted signature! > gpg: There is no indication that the signature belongs to the owner. > Primary key fingerprint: 821F 1229 36BD D565 366A C36A 4AB1 6AEA 9883 2223 > > You'll notice that I've prefixed the upstream refs with upstream/ in > order to organise them; it is possible to do this automatically with a > configuration like: > > git config remote.upstream.tagopt --no-tags > git config --add remote.upstream.fetch '+refs/tags/*:refs/tags/upstream/*' > > However, the name does not match the standard git-buildpackage naming > scheme exactly (prefixed with 'v'), so setting --git-upstream-tag is > necessary. You could avoid this at the cost of having to fetch each > tag manually, with something like: > > mithrandi@lorien ~/d/p/armory> git fetch upstream > +refs/tags/v0.92.3:refs/tags/upstream/this-is-nonsense > From github.com:etotheipi/BitcoinArmory > * [new tag] v0.92.3-> upstream/this-is-nonsense > mithrandi@lorien ~/d/p/armory> git tag -v upstream/this-is-nonsense > object 268db0f3fa20c989057bd43343a43b2edbe89aeb > type commit > tag v0.92.3 > tagger Armory Technologies, Inc 1412648447 -0400 > > Tor privacy fixes and msg signing RNG fix > gpg: Signature made Tue 07 Oct 2014 04:20:47 SAST using RSA key ID 98832223 > gpg: Good signature from "Alan C. Reiner (Offline Signing Key) > " > gpg: aka "Alan C. Reiner (Armory Signing Key) > " > gpg: aka "Alan C. Reiner (Armory Signing Key) > " > gpg: WARNING: This key is not certified with a trusted signature! > gpg: There is no indication that the signature belongs to the owner. > Primary key fingerprint: 821F 1229 36BD D565 366A C36A 4AB1 6AEA 9883 2223 > > And thus name the ref whatever you like locally, regardless of what > upstream's name is. Since all of the commands that operate on a > revision take the ref name as an argument, not the actual name given > in the tag object, this is all that matters for things like > pristine-tar (which just records the commit id regardless of how you > identify the commit to use) and git-buildpackage. > > The value of this is questionable if the upstream tags are unsigned, > especially if the released source tarballs *are* signed (in which case > t
Re: Keeping upstream commits separate from Debian packaging commits
On 17 October 2014 07:39, Tristan Seligmann wrote: > On 16 October 2014 20:12, Hans-Christoph Steiner wrote: >> >> >> Tristan Seligmann wrote: >>> If you are fetching the upstream revisions / tags into your packaging >>> repository, you can use the upstream tag exactly as-is, no need to >>> re-tag (and indeed re-tagging would generally be a bad idea). >> >> I think there is a lot of value to always including the Debian upstream/v1.0 >> tag. It provides a standard way to access the upstream version across all >> repos. There is no such standard out there "in the wild". There are tags >> like v1.0, 1.0, release-1.0, the-real-1.0, etc. etc. > > Renaming the tag does not require retagging, git tag objects (perhaps > unfortunately) do not include their name. There are different tag types in git. "Soft" are just named commit references and indeed can be renamed at will / point to new commits, however signed tags encode: object SHA1id type type-of-above tag tag-name tagger normal user name, email, timestamp tag-message All signed with gpg. Thus any change to that metadata of a signed tag will invalidate signature, or be treated as conflicting tag and thus require --force push. Unsigned tags should not be publically used for e.g. release identification. -- Regards, Dimitri. -- 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/CANBHLUgEnJ0P=s47lxsxu1hoefxo-_eishw+msvznpn9oh1...@mail.gmail.com
Re: Fighting commit storm madness (was: [Python-modules-commits] [python-mplexporter] 135/135: Merge pull request #30 from rainwoodman/patch-1)
On 9 October 2014 20:57, Scott Kitterman wrote: > On October 9, 2014 10:43:38 AM EDT, Barry Warsaw wrote: >>On Oct 09, 2014, at 10:19 AM, Scott Kitterman wrote: >> >>>Upstream commits are off topic. >> >>Agreed. There's no reason why we need notifications of upstream >>commits, >>though I don't know if it's possible to filter them out. >> >>>I'm probably going to give up on hanging out on #debian-python once we >>get >>>more packages in git. The commits are way too much and don't add >>value. >> >>Have you seen #debian-openstack-commits? Maybe we should just create a >>#debian-python-commits channel and send the notifications, and only the >>notifications, there. That way, it doesn't clutter up the discussion >>channel, >>and people can choose to join the -commits or not. > > If there's no way to avoid the upstream stuff, I guess that's what we'll have > to do. I would prefer not though. I sometimes find the existing commits > valuable. > > Scott K > Given that notifications operate as git server hooks (I presume), one should have full facility to filterdiff the commit emails and discard notifications for commits that do not change anything under "debian/*" paths. Or don't have debian/ subdir to begin with. -- Regards, Dimitri. -- 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/canbhlui3kobhyl_ney8xkdunktp35ny-3vfoxtxq5pq88eb...@mail.gmail.com
Re: Two django packages for Debian?
On 6 August 2014 14:18, Barry Warsaw wrote: > On Aug 06, 2014, at 08:47 AM, Raphael Hertzog wrote: > >>(That said I'm also rather annoyed by the fact that the team hasn't switched >>to git yet.) > > We've had these discussions on this mailing list before, but I think we should > discuss it at Debconf. While obviously we won't have full representation > (whatever that means ;) from team members, we should take advantage of the > high bandwidth setting to discuss the future vcs for the Python teams. > > In the past we've all had the important and worthy goal of using a consistent > packaging and workflow for team maintained projects. However, if folks are > abandoning the team in order to use git, then we already have fragmentation, > and it will only increase. I'm not particularly a git fan, but it's clear > where this is heading. :) > > I don't think the question is if, but when and how. There are at least two > git-based packaging tools and workflows: gbp and git-dpm. In my limited > exposure, I've had problems with the former but have been pretty happy with > the latter. There's also this interesting thread: > I am on the edge. I prefer dgit, as it's the only one the guarantees round-trip save with the archive even when someone NMUs things without using dgit. However, it does not integrate with git-dpm at the moment and there is no clear conversion / vcs history import available. Do we care about preserving vcs history for our packages? Do we want synthetic history (e.g. per upload granularity)? -- Regards, Dimitri. -- 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/CANBHLUia+dHSdA_-T5wAy_=z1r-m1btwcdjer4bkykdh4hh...@mail.gmail.com
Re: Setting DPMT as maintainer for python-repoze.what
On 22 May 2014 02:15, Thomas Goirand wrote: > Hi Dimitri (and the rest of the DPMT), > > I'm uploading a new version of python-repoze.what with some maintenance > work. I've set DPMT as maintainer, and you and I as uploaders. I don't > really care about this particular package, but thought it was a good > thing to fix stuff in it (it doesn't feel good to see such a package > with reverse dependencies left in the QA group). If you don't want to be > listed as uploader, let me know, and I'll remove you. > > Also, if anyone wants to switch it to use pybuild, I'd welcome such a > move (but I still don't feel confident enough yet to do it myself: > please point me to the correct documentation as I'm still not sure what > I must read first). > > Last thing, it was my understanding that the pht file should just be > removed to fix #746023. If I'm wrong, please let me know as well. > Yes, I believe that's correct. And the rest of changes in your upload are wonderful. Thank you for contributing to Debian. -- Regards, Dimitri. -- 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/canbhlujp2-tjyk00eeox_btwfi54nhvhassooc1dtmnp9jw...@mail.gmail.com
Bug#746741: release.debian.org: dh-python2 transition
Package: release.debian.org Severity: normal Dear release team, Debian python teams would find useful to evaluate on continuous basis removal of python-support from the archive and thus migrating to dh-python2. We are uncertain of the scope, and the pace at which this transition can be completed. But it would be extremely useful to have a transition tracker setup (permanent-type ?!). The following tracker was used in Ubuntu to remove python-support/python-central from main suite: Affected: .build-depends ~ /(^| )(python|python-dev|python-all|python-all-dev|python-support|python-central|dh-python)\s*([,(]|$)/ | .build-depends-indep ~ /(^| )(python|python-dev|python-all|python-all-dev|python-support|python-central|dh-python)\s*([,(]|$)/ Good: true Bad: .depends ~ /python-central/ | .depends ~ /python-support/ Can such a tracker be setup please? More details about the steps required to transition are documented at: https://wiki.debian.org/Python/TransitionToDHPython2 If possible include that URL in the tracker description. Regards, Dimitri. -- 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/8761lnwe70@debian.org
Re: Getting rid of python-support?
On 30 April 2014 18:27, Jakub Wilk wrote:
> * Dimitri John Ledkov , 2014-04-30, 16:43:
>
>>> python-central is gone (\o/) and python-support usage is slowly
>>> decreasing in the archive:
>>> http://lintian.debian.org/tags/dh_pysupport-is-obsolete.html
>>>
>>> Do you think it would be the right time to prepare a mass bug filing
>>> asking to convert to dh_python{2,3}?
>>
>>
>> Given it's like less than 200 packages left, let's do it now. This is
>> smaller than e.g. a boost transition.
>
>
> This tag doesn't catch indirect use of python-support, via dh or cdbs. The
> actual number of affect packages is much higher.
>
Quite. On ubuntu, there are at least 537 packages build-depending on
python-support which suggests indeed that above lintian tag is by far
not catching everything.
--
Regards,
Dimitri.
--
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/CANBHLUh5Uti1Bgwp+X0a=zya-jt8gw+1ccpxoqwkbskn-tw...@mail.gmail.com
Re: Getting rid of python-support?
On 30 April 2014 18:01, Matthias Klose wrote:
> Am 30.04.2014 17:31, schrieb Luca Falavigna:
>> Hi,
>>
>> python-central is gone (\o/) and python-support usage is slowly
>> decreasing in the archive:
>> http://lintian.debian.org/tags/dh_pysupport-is-obsolete.html
>>
>> Do you think it would be the right time to prepare a mass bug filing
>> asking to convert to dh_python{2,3}?
>
> that would be good. However before we start this, I'd like to make sure that
> we
> get rid of /usr/share/pyshared as well. With PEP 404 [1] reconfirmed this
> year
> at PyCon we can safely remove the symlink farm.
>
If PEP 404 is ever update to actually release, then it would be
reasonable to expect/demand for PEP 3147 to be implemented / included.
--
Regards,
Dimitri.
--
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/canbhlugs_dhraz3taehxm3f_rchmu83xdxhu3zjkdod9xak...@mail.gmail.com
Re: Getting rid of python-support?
On 30 April 2014 16:31, Luca Falavigna wrote:
> Hi,
>
> python-central is gone (\o/) and python-support usage is slowly
> decreasing in the archive:
> http://lintian.debian.org/tags/dh_pysupport-is-obsolete.html
>
> Do you think it would be the right time to prepare a mass bug filing
> asking to convert to dh_python{2,3}?
Given it's like less than 200 packages left, let's do it now. This is
smaller than e.g. a boost transition.
Are python-apps/modules all converted now? Might be easy to just do
mass-commit & upload of those first.
--
Regards,
Dimitri.
--
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/CANBHLUi-=jitmymc_nj6nrhbbe4uetwfczca82-2cw0tpad...@mail.gmail.com
Re: Some thoughts about py{support,central} -> dh_python2 conversion
On 12 November 2013 15:08, Jakub Wilk wrote: > * Jakub Wilk , 2012-05-03, 21:41: > >>> 2) Do not skip the "Before you begin"[0] step. This is very important: if >>> two packages share a namespace, either both or none of them must use >>> python-support. Also, it's not enough just to convert them all to >>> dh_python2: you must make sure (using Breaks or Depends relationships) that >>> you cannot co-install an older python-support-based versions together with >>> dh_python2-based ones. >> >> repoze: >> pymodules: [python-repoze.who, python-repoze.what-plugins, >> python-repoze.who-plugins, python-repoze.what, >> python-repoze.sphinx.autointerface] >> site-pkgs: [python-repoze.lru, python-repoze.tm2] > > > True positive. If you install one package from the "pymodules" set and one > from the "site-pkgs" set, the former package doesn't work. > > "python-repoze.who-plugins" is in the worst situation, as it transitively > depends on "python-repoze.lru". > I've now converted all repoze packages in the pymodules set to use dh_python2. I think it should be sufficient to resolve this set, but i will verify this again in clean chroot with packages from sid. -- Regards, Dimitri. -- 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/CANBHLUgg=t09zdehffxtss+ck67kjxfuz8hdy+wme6mdhqn...@mail.gmail.com
Re: RFS: Pyspread 0.2.6-1
On 19 February 2014 15:45, Barry Warsaw wrote: > On Feb 18, 2014, at 09:10 PM, Vincent Cheng wrote: > >>I don't really know how autopkgtests work, but if they're run >>automatically during the build process like dh_auto_test, then that >>would cause your package to FTBFS. Can you modify the tests so that >>they work with other fonts, or disable the offending tests entirely? > > They don't run automatically during package build for either pbuilder or > sbuild afaik, although that would be really nice. Ubuntu's buildd's do run > them during the publishing phase, and you can run them locally, which isn't a > bad idea. Here's Ubuntu's documentation on autopkgtest, which seems the best > so far. I haven't tried this on Debian yet. > > http://packaging.ubuntu.com/html/auto-pkg-test.html > For debian: http://ci.debian.net/ (execution results) http://dep.debian.net/deps/dep8/ (spec) -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANBHLUiv5Gxa1d+EVPRMDZw_6BasrZfHz=0qWE2UCL-jp6A1=a...@mail.gmail.com
Re: Indeed, python-concurrent.futures is the same
On 25 January 2014 17:21, Sandro Tosi wrote: >> Huh? Thomas seemed to be doing the right thing per the DPMT standards >> etc; > > if you change the python helper, you HAVE TO contact who's maintaining > the package and have they ack the change, that's the team standard. > No, one does not within python apps/module teams. It's not the first time when you are over-reacting to team changes in a very aggressive/abusive manner. Honestly, nobody is trying to purposely cause harm to debian packages. >> if you don't want the package to be team maintained, perhaps take >> it out of team maintenance? > > lecturing is not required, thanks > This is not a lecture. You clearly have "maintainer - team" balance swayed way to the maintainer-mandated side of things, which is not shared with anyone else in the debian apps/modules team. I do not share your view that "Thomas Goirand is not welcomed here." on the contrary, the Debian Project welcomes and encourages participation by everyone. We welcome contributions from everyone as long as they interact constructively. When packages that you declared are maintained within the team are touched, at times (and this is not the first time), you demand post-factum that you should have been exclusively consulted first and you demand or threaten for all changes to be reverted. This is not constructive interaction within python apps/modules teams, nor wider Debian Project. Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANBHLUhGR=jkplvio8njsa0r_acekkukvg7bmwrjjkdyg6q...@mail.gmail.com
Re: Using git-svn and gbp for DPMT - Was: Re: Joining the DPMT and git.debian.org access
On 15 January 2014 02:29, Chow Loong Jin wrote: > On Tue, Jan 14, 2014 at 04:51:20PM +0100, Olivier Berger wrote: >> Now, if you both want to track upstream sources from origin/master on >> local upstream/ branch and svn's trunk on local master branch, then, >> yes, a debian/gbp.conf comes handy, and you'll have to do nasty merges >> now and then. > > git import-orig --filter=debian helps to avoid nasty merges, as long as you > don't make changes to the upstream sources directly inside your packaging > branch > -- there shall be no conflicts if upstream does not touch debian and you do > not > touch the upstream sources. > > gbp-pq is also wonderful for maintaining quilt patch series. My preference lately is strongly with: dgit + git-dpm (for patch management). git-dpm does not polute repository with branches of any sort, it simply maintains a round-trip-safe conversion from debian/patches to a branch and back again. (Something very similar to Mercurial Queues but done nicer and more specific to debian packaging) I haven't yet found a way to use dgit/git-dpm against svn repository. I'm thinking to simply do dsc-import on the svn side, after I generate an upload with dgit/git-dpm. Once the kinks are worked out, and some sort of "forest" (mr or repo) management is in place we can start opening up an outstanding git powered workflow. -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhlugki6ptvmhd6qihm80hhgr0mbgypc2aa+cvpmjr9gp...@mail.gmail.com
Re: Fw: [Debian Wiki] Update of "Python/LibraryStyleGuide" by FedericoCeratto
On 28 December 2013 06:27, Thomas Goirand wrote: > On 12/28/2013 01:00 AM, Dimitri John Ledkov wrote: >> OK, I'm sorry. >> >> What does it mean a "clean backport" vs other type of backports? >> dh-python is in backports, so no changes are required to backport >> packages build-depending on dh-python. Is that not clean enough? > > I think you somehow misunderstood me. Let me try to expand in a longer > message then. > > python3 depends on dh-python. As much as I can see, that's the only > package with a direct dependency on dh-python. Therefore, for Jessie, it > is perfectly valid to omit dh-python in build-depends, as long as your > package build-depends on python3. > >2 However, if we want to backport a package to Wheezy, and that package is > using pybuild, then it needs an explicit build-depends on dh-python, > because in Wheezy, there's no dh-python, and python3 doesn't depend on > it. Therefore, to facilitate backports to Wheezy, I think it is nice to > just leave the dh-python as explicit dependency in new packages, at > least for until we have released Jessie. > > What I called "clean backports" was just a backport to Wheezy with > unmodified source package (just a rebuild without modification). I think > it is a good thing to make it possible for ourselves to do easy > backports this way. It is also a good thing to make it possible for our > users to backport packages to Wheezy themselves without too much hassle, > even if the package isn't officially in backports. > > So, yes, we don't explicitly need dh-python for Jessie if we have > python3 as build-depends, but IMO it is nice to do so. > Well, my understanding is that an explicit build-dependency on dh-python is required if one uses pybuild. As per policy, one shouldn't rely on transitive dependencies, especially when it's well known that pybuild is only provided by the dh-python package and no other. If one merely uses dh_python2 one doesn't need any additional build-dependencies apart from default python interpreters. Since in wheezy/jessie, dh_python2 are provided by the packages generated from python-defaults. Would you agree that python/python-all dependencies are sufficient here? If there are packages that use pybuild, and do not build-depend on dh-python in jessie, imho that should be an important bug. I'll try to do an archive scan to detect how widespread the issue is. > On 12/27/2013 11:18 PM, Dimitri John Ledkov wrote: >> I don't understand why are you insisting on blocking migrations to >> dh-python. Is there some non-Debian requirement that you are omitting >> / not-telling here? > > I absolutely don't want to block any migration to dh-python. Quite the > opposite, I think it's great that we don't have to manually do stuff to > support python3, and I am very happy that this part has been automated > by pybuild. I do not know enough pybuild (which is very new, so I think > that's normal), but working on a few package maintained by Piotr, I like > what I saw about it. Packages supporting both Python 2.x and Python 3 > have a very short debian/rules, which is a very good thing. > > As for the "omitting / not-telling" part here, I'm not sure what you are > referring to. Maybe the fact that I do maintain unofficial backports of > a lot of python modules in order to have OpenStack to work in Wheezy? > Well, if that's what you are thinking about, my opinion is that it is a > good thing if someone cares about doing easy backports, and even do some > work in Sid to make them more easy. I would love to make this happen > through the official backports of Debian, however because of the amount > of packages, and the difficulty to have them all migrated to testing, I > don't think this is technically possible in good conditions. Like many > others, I am hoping for the Debian PPAMAIN repositories to be available > to start doing that. That's the only way, or we'd have to change the > backports policy, which I don't see happening anytime soon. Thoughts on > this would be very much welcome! > Well that part was mostly based on the request to support "python-support" in addition to "dh_python2" in a package I maintain. And thanks Piotr for clarify the transient python3 -> dh-python dependency. -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhlugbdf2uhdc_k_5_508gkhaq-+4kdirdcebzaz5n1cg...@mail.gmail.com
Re: Fw: [Debian Wiki] Update of "Python/LibraryStyleGuide" by FedericoCeratto
On 27 December 2013 16:08, Clint Byrum wrote: > Excerpts from Dimitri John Ledkov's message of 2013-12-27 07:18:05 -0800: >> On 27 December 2013 15:00, Thomas Goirand wrote: >> > On 12/17/2013 01:02 AM, Barry Warsaw wrote: >> >> [...] >> >> You'll want to have at least the following build dependencies: >> >> >> >>* debhelper (>= 8) >> >> - * dh-python >> >>* python-all (>= 2.6.6-3~) >> >>* python-setuptools >> >>* python3-all >> >>* python3-setuptools >> > >> > Hi, >> > >> > Just reacting on the above change. It's my understanding that we do need >> > to add dh-python explicitly if we want clean backports (eg: unchanged >> > from Sid). Am I right? If that's the case, shouldn't we advise to write >> > dh-python explicitly for until Jessie is released? >> > >> >> Why should back-ports dictate how Jessie is developed? This is not the >> same requirements as e.g. dpkg where last one must be able to process >> all packages from the immediately next release. >> > > I don't think this is dictation, just pragmatic cooperation with a fairly > popular service. > >> And dh-python is available from backports - stable-bpo 1.20131021-1~bpo70+1 >> >> I don't understand why are you insisting on blocking migrations to >> dh-python. Is there some non-Debian requirement that you are omitting >> / not-telling here? >> > > I can't tell if you're being suspicious or leading. Either way, can we > just trust each-other and use clear language? I don't see any ulterior > motive there, just a desire to keep things simple. > OK, I'm sorry. What does it mean a "clean backport" vs other type of backports? dh-python is in backports, so no changes are required to backport packages build-depending on dh-python. Is that not clean enough? -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhluj1khkx7q+39-p-9hmvyysvruaxegoeem38hwz3hhg...@mail.gmail.com
Re: Fw: [Debian Wiki] Update of "Python/LibraryStyleGuide" by FedericoCeratto
On 27 December 2013 15:00, Thomas Goirand wrote: > On 12/17/2013 01:02 AM, Barry Warsaw wrote: >> [...] >> You'll want to have at least the following build dependencies: >> >>* debhelper (>= 8) >> - * dh-python >>* python-all (>= 2.6.6-3~) >>* python-setuptools >>* python3-all >>* python3-setuptools > > Hi, > > Just reacting on the above change. It's my understanding that we do need > to add dh-python explicitly if we want clean backports (eg: unchanged > from Sid). Am I right? If that's the case, shouldn't we advise to write > dh-python explicitly for until Jessie is released? > Why should back-ports dictate how Jessie is developed? This is not the same requirements as e.g. dpkg where last one must be able to process all packages from the immediately next release. And dh-python is available from backports - stable-bpo 1.20131021-1~bpo70+1 I don't understand why are you insisting on blocking migrations to dh-python. Is there some non-Debian requirement that you are omitting / not-telling here? -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANBHLUhJG8ai=nkd71ao3d3w2fcgfhxw_ojxumvp3gngdmo...@mail.gmail.com
Re: pybuild and not always preventing network connection in auto tests
On 11 December 2013 15:33, Dimitri John Ledkov wrote: > On 11 December 2013 15:24, Olivier Berger > wrote: >> Hi. >> >> AFAIU, pybuild prevents accesses to the network. >> >> But this can be problematic during auto_tests that will perform HTTP >> connections on a local HTTP server (I have such an example in rdflib's >> auto tests [0]). >> >> Is there a way to avoid such a protection, possibly on a selective >> number of tests ? >> > > unexport http_proxy > unexport https_proxy > override_dh_auto_test: > dh_auto_test --buildsystem=pybuild > actually you probably need to set them to empty value; e.g. http_proxy="" https_proxy="" dh_auto_test, or export http_proxy\n export https_proxy -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANBHLUi3hYLfjYwQ98T=iGTTjxKbwRnQsmnyfH+F-yEa=mp...@mail.gmail.com
Re: pybuild and not always preventing network connection in auto tests
On 11 December 2013 15:24, Olivier Berger wrote: > Hi. > > AFAIU, pybuild prevents accesses to the network. > > But this can be problematic during auto_tests that will perform HTTP > connections on a local HTTP server (I have such an example in rdflib's > auto tests [0]). > > Is there a way to avoid such a protection, possibly on a selective > number of tests ? > unexport http_proxy unexport https_proxy override_dh_auto_test: dh_auto_test --buildsystem=pybuild -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhluhs_pasj6fwd1zqoaimca29vhg7wg1m4af-xtfbxq8...@mail.gmail.com
