Re: input into perl 6 packaging required
Hi Robert! On Sat, May 05, 2018 at 09:21:28PM +0200, Robert Lemmen wrote: > hi folks, > > we are currently thinking about how to package perl 6 modules, some > background and information at https://wiki.debian.org/Perl6PreCompProposal > > Perl 6 does pre-compile modules on loading, a bit like the .pyc files. > So I would be very glad if you could have a quick look at the wiki page > above, perhaps you experience could help us. I am also specifically > interested in your decision to create the .pyc files at package > installation time, rather than at package build time. What was the > reason for that? Do you still think it was the right decision? In the > case of perl 6 the precompiled files depend on a fairly specific version > of the runtime, so we would need to re-build them quite often... I think the main reasons for generating .pyc files at install time were: - Ability to ship “Architecture: all” packages, which reduces load on build daemons, mirrors, etc. - Ability to regenerate all .pyc files for new Python version on users’ side (it does not take a long time), without need to do binNMUs or re-uploads. And I think it was the right decision, as these reasons still apply. -- Dmitry Shachnev signature.asc Description: PGP signature
How to make sure PATH is set correctly (Was: foo FTBFS with dh-python >= 3.20180313)
Hi again,
sorry for nagging again but what else than I did in
https://salsa.debian.org/med-team/snakemake/blob/master/debian/rules
can I do to set PATH in pbuilder. Possibly I've understand all your
hints incorrectly - the PATH is just not set inside pbuilder chroot. :-(
Kind regards
Andreas.
On Mon, Apr 30, 2018 at 11:13:44PM +0200, Andreas Tille wrote:
> On Mon, Apr 30, 2018 at 08:29:13PM +0200, Piotr Ożarowski wrote:
> > [Andreas Tille, 2018-04-30]
> > > Hmmm, inside pbuilder chroot the files are installed to
> > >
> > >
> > > /build/snakemake-4.8.0/.pybuild/cpython3_3.6_snakemake/build/bin/snakemake
> > >
> > > while
> > >
> > > # pybuild --print build_dir --interpreter python3
> > > /build/snakemake-4.8.0/.pybuild/cpython3_3.6/build
> >
> > you invoked it outside debian/rules, without --name or PYBUILD_NAME set,
> > right?
>
> Yes, that's right.
>
> > > I have no idea why since some dh-python version things are different
> > > than before but wouldn't it be the best idea to let pybuild set PATH and
> > > PYTHONPATH instead of setting it manually by some manual command?
> >
> > I meant to fix also debian/rules line 11 (you fixed line 21 only)
>
> I commited my last attemt to Git fixing PATH on both lines.
>
> I get with this d/rules:
>
>
> ...
> raise Exception("snakemake not in PATH. For testing, install snakemake
> with "
> Exception: snakemake not in PATH. For testing, install snakemake with 'pip
> install -e .'. You should do this in a separate environment (via conda or
> virtualenv).
>
> --
> Ran 4 tests in 0.187s
>
> FAILED (errors=1)
> E: pybuild pybuild:336: test: plugin distutils failed with: exit code=1: cd
> /build/snakemake-4.8.0/.pybuild/cpython3_3.6_snakemake/build; python3.6 -m
> nose tests
> dh_auto_test: pybuild --test --test-nose -i python{version} -p 3.6 returned
> exit code 13
> make: *** [debian/rules:17: build] Error 25
> dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
> I: copying local configuration
> E: Failed autobuilding of package
> I: user script /var/cache/pbuilder/build/cow.11501/tmp/hooks/C99_failed_build
> starting
> root:/# echo $PATH
> /usr/sbin:/usr/bin:/sbin:/bin
>
>
> I have no idea why but the PATH does not make it through.
>
> I confirm if I set
>
>root:/build/snakemake-4.8.0# export PYBUILD_NAME=snakemake
>root:/build/snakemake-4.8.0# pybuild --print build_dir --interpreter
> python3
>/build/snakemake-4.8.0/.pybuild/cpython3_3.6_snakemake/build
>
> But why does these variables not end up in the chroot?
>
> Kind regards
>
>Andreas.
>
> --
> http://fam-tille.de
>
>
--
http://fam-tille.de
Re: Removal of easy_install
On 05/07/2018 04:19 AM, Ben Finney wrote: > Scott Talbert writes: > >> About a month ago, Matthias removed easy_install from setuptools. I >> have sent him a few mails and bugs asking about it, but I haven't >> heard anything back. Anyone know why he did it? I have a package >> that currently FTBFS because of it. :( > > Why does a source package *build* need to use ‘easy_install’? The source > package should not need any network access to build, all the source > should be in Debian source packages that are fetched before the build > begins. > > Which package is the one that's failing to build now? I agree with the above. Never the less, I don't see why we wouldn't ship easy_install anymore, it's still useful (outside of packaging). Cheers, Thomas Goirand (zigo)
Re: Removal of easy_install
On Mon, 7 May 2018, Ben Finney wrote: About a month ago, Matthias removed easy_install from setuptools. I have sent him a few mails and bugs asking about it, but I haven't heard anything back. Anyone know why he did it? I have a package that currently FTBFS because of it. :( Why does a source package *build* need to use ‘easy_install’? The source package should not need any network access to build, all the source should be in Debian source packages that are fetched before the build begins. Which package is the one that's failing to build now? I guess I should have included that information. :) The source package in question is wxpython4.0. The reason I use easy_install is for installing the python2 version of the module as an egg. The reason I do this is because wxpython3.0 occupies the 'namespace' for the wx module for python2. In other words, both wxpython3.0 and wxpython4.0 have a 'wx' module for python2. In order to avoid a conflict, I install the wxpython4.0 version as an egg. The wxpython3.0 and wxpython4.0 modules are not drop-in compatible, so an update-alternatives solution doesn't make sense. Scott
Request for acces to salsa project
Hello everybody, I resend this mail. I was maintaining pygtihub project ( https://salsa.debian.org/python-team/modules/pygithub/) But, I lost my privileges when the project was migrate to salsa. Could you give me access to pygithub? I have some commits. My salsa user is: eamanu-guest Thanks very much! Regards! -- Arias Emmanuel https://www.linkedin.com/in/emmanuel-arias-437a6a8a http://eamanu.com
Re: Removal of easy_install
Scott Talbert writes: > The source package in question is wxpython4.0. The reason I use > easy_install is for installing the python2 version of the module as an > egg. Okay, so from that I understand that the Debian package is not invoking ‘easy_install’ to fetch files from the network. >From what I remember, it is surprisingly difficult to convince ‘easy_install’ that it should never access the network, even when you think you're only performing local operations. Probably it's best to test this in a virtual machine isolated from the network, to be sure it succeeds. > The reason I do this is because wxpython3.0 occupies the 'namespace' > for the wx module for python2. In other words, both wxpython3.0 and > wxpython4.0 have a 'wx' module for python2. In order to avoid a > conflict, I install the wxpython4.0 version as an egg. How does that avoid the conflict — that is, what is the effect of installing the egg such that a namespace conflict is avoided? I ask because it is likely that today's Python has a better way of achieving the effect you're wanting, so that ‘easy_install’ is not needed. -- \“If we ruin the Earth, there is no place else to go. This is | `\not a disposable world, and we are not yet able to re-engineer | _o__) other planets.” —Carl Sagan, _Cosmos_, 1980 | Ben Finney
Re: Removal of easy_install
On Tue, 8 May 2018, Ben Finney wrote: The source package in question is wxpython4.0. The reason I use easy_install is for installing the python2 version of the module as an egg. Okay, so from that I understand that the Debian package is not invoking ‘easy_install’ to fetch files from the network. From what I remember, it is surprisingly difficult to convince ‘easy_install’ that it should never access the network, even when you think you're only performing local operations. Probably it's best to test this in a virtual machine isolated from the network, to be sure it succeeds. Correct - using easy_install to install the egg doesn't fetch files from the network. I haven't tried this in a virtual machine, but it definitely works fine on the Fedora builders which are pretty well hardened to have no network access. The reason I do this is because wxpython3.0 occupies the 'namespace' for the wx module for python2. In other words, both wxpython3.0 and wxpython4.0 have a 'wx' module for python2. In order to avoid a conflict, I install the wxpython4.0 version as an egg. How does that avoid the conflict — that is, what is the effect of installing the egg such that a namespace conflict is avoided? I ask because it is likely that today's Python has a better way of achieving the effect you're wanting, so that ‘easy_install’ is not needed. Installing the egg means that all the wxpython4.0 files are installed under: /usr/lib/python2.7/dist-packages/wxPython-4.0.1-py2.7-linux-amd64.egg Thus, any program or user who does an 'import wx' will get the wxpython3.0 module and if instead the wxpython4.0 module is desired, the user must manually insert the above path into sys.path or PYTHONPATH. Scott
Re: Removal of easy_install
Scott Talbert writes: > Installing the egg means that all the wxpython4.0 files are installed > under: > /usr/lib/python2.7/dist-packages/wxPython-4.0.1-py2.7-linux-amd64.egg > > Thus, any program or user who does an 'import wx' will get the > wxpython3.0 module and if instead the wxpython4.0 module is desired, > the user must manually insert the above path into sys.path or > PYTHONPATH. That seems, based on the above description, to just arbitrarily declare one version to be the default, and the other needs manual override by the user. If that's an accurate description of the effect you want, then you don't need to do a special ‘easy_install’ usage, nor an Egg install. You can instead install to a different location using the normal tools. See the ‘pybuild(1)’ manual page on how to specify installation locations when installing the Python library. That would not need anything different from the Debian package tools, and you are then left in the same situation: the user needs to specify a different import search path to choose the different library. -- \ “By instructing students how to learn, unlearn, and relearn, a | `\ powerful new dimension can be added to education.” —Alvin | _o__)Toffler, _Future Shock_, 1970 | Ben Finney
