cept it.
Kind regards
[0] https://github.com/akaihola/darker
[1] salsa.debian.org/gdstr
[2]
https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst
--
Gregor
you!
[1]http://pypedal.sourceforge.net/
--
Lep pozdrav / With regards,
Gregor Gorjanc
--
University of Ljubljana PhD student
Biotechnical Facultywww: http://www.bfro.uni-lj.si/MR/ggorjan
Zootechnical Department
n "3.2 Alternate installation: Unix (the prefix
> scheme)"
> http://docs.python.org/inst/alt-install-windows.html#SECTION00032
> which recommends the command Sam suggested (e.g. "/usr/bin/python setup.py
> install --prefix=/usr/local").
Than
since I am not a Python person
> and delving into python policy will not be very productive.
Same here :)
Cheers,
gregor
--
.''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
: :' : Debian GNU/Linux user, admin, and developer - http://www.
On Thu, 08 Sep 2016 10:32:45 +0300, Martín Ferrari wrote:
> >> please move KGB bot from #debian-python channel to
> >> #debian-python-changes
> > Done for KGB-0.
> Done!
Done as well.
Cheers,
gregor
--
.''`. Homepage https://info.comodo.priv
o the reason why I included a Python 2 package build - Ansible has
not been fully converted to Python 3 yet.
Thank for your consideration,
Gregor
signature.asc
Description: OpenPGP digital signature
Hi,
I'd like to request sponsorship for the hvac Python module.
Source package: hvac
Packages: python-hvac, python3-hvac
Version 0.5.0-1
Upstream: https://github.com/ianunruh/hvac
Salsa: https://salsa.debian.org/python-team/modules/hvac
Mentors: https://mentors.debian.net/package/hvac
This packa
> In case I've misunderstood you, and you're referring to unit tests
> shipped debian/tests/*, than yes, I agree. :)
As far as I understand, these tests are executed by the package builder after
the upstream build script has finished. They're meant as a sort of integration
test, i.e. "does this pa
> autopkgtest (debian/tests/) is a form of as-installed testing, which takes
> the packages that were built, installs them in a relatively complete and
> realistic environment (typically a lxc container or a qemu/kvm virtual
> machine) and runs further tests there. Sometimes these tests just repeat
Package: wnpp
Severity: wishlist
Owner: Gregor Riepl
* Package name: python-hvac
Version : 0.6.2
Upstream Author : Ian Unruh
* URL : https://github.com/ianunruh/hvac
* License : Apache-2.0
Programming Lang: Python
Description : Python 2/3 client for
> Para poder instalar py3.7 por default, tendrías que descargarlo desde
> https://www.python.org/downloads/
> y ejecutar ```./configure && make && make install```
Alternatively, if you are patient, buster will become stable very soon.
It comes with Python 3.7 by default.
> I am not a fan of pointing to a moving target with the "include" statement:
>
> include:
> - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml
> -
> https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml
>
> "master" will change, and that can br
> As of now, calibre is not of sufficient quality to be part of a Debian release
> and until it drops all Python2 requirements, it must be considered RC buggy.
Is your quality argument based on the Calibre author's shenanigans?
https://www.reddit.com/r/linux/comments/9wodtq/calibre_wont_migrate_to
Oh, and by the way, I just saw this:
https://github.com/kovidgoyal/calibre/blob/master/README.python3
Perhaps a working Py3 port is not so far off after all.
talls python3.7 for the test dependency?
Regards,
Gregor
> If fixing those FTBFS is not on the table, I think you could just let it
> be, and have it go out and then back in. Tricks like pinging the bug to
> delay the autorm will likely backfire since it might very well be that
> very same bug that is also removing calibre. At the same time,
> botherin
> so my question is how can I solve this error.
> I thought about adding rpath to these libraries in order to move then
> under a private location /usr/lib/. But for this I need to add
> an rpath to all the extensions which use these libraries.
You should consider /usr/lib// if you want to make y
>> You should consider /usr/lib// if you want to make your
>> package multiarch-safe.
>
> And what about ?
>
> /usr/lib//
>
> whcih one is better ?
Have a look at the Debian policy at
https://www.debian.org/doc/debian-policy/ch-opersys.html#s-fhs
It explicitly mentions:
> Applications may also
>> I'm packaging a c++ program (horizon-eda) which also contains a
>> python module written in c++. Upstream's Makefile has a target 'pymodule'
>> and 'make pymodule' creates horizon.so in the build directory.
>> According to upstream this has to be copied іnto python's sys.path
>
> The preferred m
> File "/usr/lib/python3.8/mailbox.py", line 781, in get_message
> msg.set_from(from_line[5:].decode('ascii'))
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 37:
> ordinal not in range(128)
> Exit code: 1
>
> IMHO it is a bug if those mailboxes can't be read. Am
> It has a setup.py and uses SetupTools and DistUtils so I was hoping to
> add --with Python3 and hope that a lot of magic would be done by pybuild.
> However as I'm already using cmake as the build system I can't stick
> pybuild in there.
We use both pybuild and cmake for a couple of SIP packages
On Sun, 19 Jul 2020 03:46:12 +0200, gregor herrmann wrote:
> Control: tag 835340 + patch
> Control: tag 938076 + patch
>
> On Fri, 30 Aug 2019 07:45:06 +, Matthias Klose wrote:
>
> > Your package either build-depends, depends on Python2, or uses Python2
> > in
ld take over?
> I'll keep a tab open to review and sponsor the nmu (but anybody feel
> free to beat me).
Thanks, much appreciated.
Cheers,
gregor
--
.''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
: :' : OpenPGP fingerprint
> autopkgtest [19:46:36]: test autodep8-python3: set -e ; for py in
> $(py3versions -r 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo "Testing with
> $py:" ; $py -c "import cython_blis; print(cython_blis)" ; done
> autopkgtest [19:46:36]: test autodep8-python3: [---
> Testing
> Please also advise: where could I have such repositories like such
> huge oracle java object and code repository?
I think what most people use as a source for Python packages is PyPi:
https://pypi.org/
And there is excellent tooling around it. Personally, I prefer pipenv
for application depende
> Did you look into the source package? isal is written in assembly
> language...
That doesn't seem quite right.
The readme states:
> other:
>
> Compiler: Portable base functions are available that build with most C
> compilers.
And it does look like there are corresponding .c implementations, a
> Ignoring the autopkgtest for now Lintian is complaining about empty
> binary packages for python3-twisted-{bin,dbg}. Are they needed anymore?
> OTOH it's looking not that bad and a lot of the messages should be easy
> to fix.
> X: python3-twisted: library-package-name-for-application usr/bin/c
> I realise now that this "nice" solution won't work, as the standard
> library code says:
>
> import socketserver
>
> so modifying sys.path will just change the value of
> sys.modules["socketserver"]. However, the vendored code instead loads
> this module to sys.modules["_pydev_imps._pydev_Sock
> So the solution I'm currently in the process of trying is to copy the
> version from the oldest supported Python version at Debian package
> build time. We'll see how this goes
>
>> Perhaps they have a maintenance script for updating the vendored
>> dependencies? You could use that to find
I: python3-pyxdameraulevenshtein: hardening-no-bindnow
[usr/lib/python3/dist-packages/pyxdameraulevenshtein.cpython-310-x86_64-linux-gnu.so]
and there is nothing about CFLAGS or the like in the setup.py file.
So if having this hardening flag enabled is a good thing, it should
probably be enabled
your package fails the autopkgtest with the new pytest 7.3 because
python/test/unit/function/test_function_space.py uses a bytes object
(b""" literal) as module docstring, and pytest crashes while looking for
the "PYTEST_DONT_REWRITE" marker.
This does sound like a serious bug in pytest, though.
5) Not really 100% Debian related, but in the Python sdist,... should
that contain the debian/*?
No, and the upstream source shouldn't contain debian/ anyway, as the life
cycles of packaging and upstream sources should be separate even if the
person doing both is the same.
This would then b
s
wrong with the script in the first place and only showed up now?
Can someone help with sorting this issue out?
Thanks,
Gregor
[1] https://cmake.org/cmake/help/v3.26/module/FindPython.html
[2] https://cmake.org/cmake/help/v3.27/module/FindPython.html
How can I teach pybuild that I really want xraylarch[larix] ?
I don't know if there's a mechanism that can add optional dependencies
automatically, but the easiest way would be to just add them to the
Depends: ...
or the
Recommends: ...
list of the respective package in debian/control.
As far as how to do this within an existing cmake project,
unfortunately, there doesn't seem to be a clear/easy way. The only
cmake example I can think off of the top of my head is cvc5. It still
uses setup.py though, so not a great future-looking example (and I had
to patch it to build the P
m has already done the work to fix Python
3.12 compatibility: https://github.com/getsentry/sentry-python/issues/2480
So, it should suffice to upgrade to at least 1.34.0 (or better yet, the
latest 1.x release).
Regards,
Gregor
Someone has asked us to merge one of your Launchpad
accounts with another.
If you go ahead, this will merge the account called
'Debian Python Modules Team (debian-python)' into the account 'johnfrandes12'.
To confirm you want to do this, please follow
this link:
This looks extremely fishy - an
om
www.python.org.
I hope I'll manage to post a first mail with a longer proposal to the
list within the next few days.
Gregor
ot to include JPython in main ?
Consequently, if we intended to switch over to this new directory layout,
quite a few packages needed to be changed. Still, the changes would be
mostly trivial.
I really would like to introduce these changes with slink.
Glad to hear any comments,
Gregor
who writes to this list.
I wonder if we are the only ones reading this list. Is it possible to
see who is subscribed to the list ?
Gregor
On Thu, Sep 17, 1998 at 04:34:02PM +0200, Lorenzo M. Catucci wrote:
>
>
> On Thu, 17 Sep 1998, Gregor Hoffleit [...]
> >
> > I wonder if we are the only ones reading this list. Is it possible to
> > see who is subscribed to the list ?
> >
> `An interested u
On Mon, Oct 12, 1998 at 08:34:19PM +0200, Matthias Klose wrote:
> Gregor Hoffleit writes:
> > Hi,
> >
> > I placed new experimental packages of python and jpython on my private
> > web page, http://www.mathi.uni-heidelberg.de/~flight/debian-private/.
> >
&g
7;s more recent!
Therefore, /b/module.py will never be compiled.]
It's not reasonable to give anybody but root write-access to
/var/cache/python, it would be a security hole. The "cache" would have
to be maintained by some sort of root script.
Therefore, either we had to be sure that the files in
/var/cache/python are always up to date wrt to the sources in
/usr/share/python, or we had to tweak Python/import.c to consider both
directories at once, which is no good idea IMHO.
Gregor
luded; there will be
no structural changes compared with the current 1.5.1-3.1, i.e. for
slink we will stick with /usr/lib/python1.5 etc.
Gregor
python-tk".
Gregor
ython1.5/site-packages
resp. DESTSHARED in debian/rules before running the "make install
prefix=`pwd`/debian/tmp/usr".
The upcoming Python package 1.5.1-6 contains a README.maintainers with
a few hints for Python package maintainers.
Gregor
ttpd is ZopeHTTPServer, readily configured to run via
/etc/init.d (is this really a good idea ?). Expect to find a zserver
package in the future as well.
I'll announce when there is a real release to the greater public.
Gregor
on package.
Gregor
--
| Gregor Hoffleit Mathematisches Institut, Uni HD|
| [EMAIL PROTECTED] INF 288, 69120 Heidelberg, Germany |
| (NeXTmail, MIME) (49)6221 54-5771fax 54-8312 |
| "We will make windows invisible" |
python-bin resp. jpython-bin providing
python-vm).
Gregor
into contrib at first. Nevertheless, this will make it necessary to have
a common python library package (python-lib ?).
Again, any
Gregor
ug in kaffe, so that JPython can be in main ?
Gregor
On Tue, Apr 13, 1999 at 09:05:36AM -0700, Mike Orr wrote:
> On Tue, Apr 13, 1999 at 01:35:02PM +0200, Gregor Hoffleit wrote:
> > I have put together a set of experimental Python 1.5.2c1 packages. To use
> > them with apt, try the following line:
> >
> > deb http:
in separate packages ?
Then, is there also a need for postscript resp. pdf packages ?
Gregor
), so that's an argument to use the new format.
But then, the bsddb module had to be changed anyway to support the new
API, therefore one could argue that it's better to work on a bsddb2
module anyway.
Any opinions ?
Gregor
ile the info files are only 500kB.
So I think the only valid case would be installing the info files
without the html ones.
Gregor
I tend to split python-lib in a
small package with essentials (python-base ?), so that we have a
small, minimal Python system (heading to move Python into base ;-)).
Then, we are prepared for a jpython package, with dependencies on
python-lib. As you see, this is not yet decided upon.
Gregor
pe
1.10.3 or we won't get it in potato.
Gregor
hat employ authentification mechanisms, such as mailman and zope,
might be interested to try and add PAM support to their programs.
Gregor
been
merged back into python-base.
It's certainly up for discussion if we really should include things like
python-gtk, python-gdk-imlib, python-glade and python-gnome, since they
introduce dependencies on non-usual libraries: I'd love to have them, but
then task-python will force any u
bugging
it, please tell me.
I'm afraid I'll have to orphan the package otherwise.
Gregor
pgpK9ZGo64zVl.pgp
Description: PGP signature
David,
are you still working on these task-python* packages ? It would be nice if
we could get them into potato.
Gregor
On Tue, Oct 26, 1999 at 06:03:10AM +, David Coe wrote:
> I'm building the task-python packages, have a few questions, and would
> like your sugg
odule and the Python thread support, but I'm lost where to look for the
bug.
Gregor
pgpnCW6zGZjvj.pgp
Description: PGP signature
Sorry, no. I didn't work on the documentation.
Gregor
On Tue, Sep 05, 2000 at 09:40:19AM +0200, Matthias Klose wrote:
> Milan Zamazal writes:
> > >>>>> "CHC" == Choi He Chul <[EMAIL PROTECTED]> writes:
> >
> > CHC> dp
.
Or does somebody think it's worthwhile to provide python2-tk8.x packages ?
Since the tk8.0-dev and tk8.3-dev still seem to conflict, the building of
the packages would be the biggest problem.
Gregor
yet in testing, but Roman has
> promised an account on kullervo to try to figure it out.
are you making any progress on this thing ? I should upload a new revision
of the Python packages, and I'm wondering what to do about this.
Gregor
ackages (e.g. remove python-zlib and depend on python-base (>= 1.5.2-13)).
Thanks,
Gregor
ee.
Yep, please go ahead. I remember that some time ago somebody else
volunteered, but appearently, it didn't get off.
Gregor
PS: How about the various XML tools by Lars Marius Garshol
(http://www.garshol.priv.no/download/), e.g. xmlproc, pysp, XSA etc. ? And
the stuff by Geir O. Grønmo (http:
lobal debconf option. Packages could also provide
private debconf options to override this.
Any comments ?
Gregor
[1] The iPAC Python packages contain a completely stripped-down version of
the Python packages.
On Sat, Mar 24, 2001 at 08:25:57AM +0200, Moshe Zadka wrote:
> On Fri, 23 Mar 2001, Gregor Hoffleit <[EMAIL PROTECTED]> wrote:
>
> > currently, our Python packages mostly ship .py files and compile them into
> > ..pyc files at run time in order to save space in the d
paragraph (7) of the new PSF license.
I'll send a mail to RMS and ask for his comment.
Gregor
> and code-breakage features like nested scopes are disabled by default.
>
> am I right?
> what do you think?
On Wed, Apr 18, 2001 at 08:26:00AM -0700, Sean 'Shaleh' Perry wrote:
>
> On 18-Apr-2001 Gregor Hoffleit wrote:
> > On Tue, Apr 17, 2001 at 03:33:45PM +0200, Vasko Miroslav wrote:
> >> as Python 2.1 is out, there is no need to keep Python2 and Python152
> >>
t warnings regarding code that will not work as
> > expected in future versions?
>
> Yes, I think so. But that doesn't make them less annoying. ;-)
Could you mail an example of such a message ?
Gregor
ose wrote:
>
> > I really would like to see 2.1 in the next Debian release. I'd like to
> > ask Gregor (the maintainer) for an upload schedule, so that other
> > maintainers can rely on this to get their packages ready for the next
> > release as well. Are there still li
On Thu, May 24, 2001 at 01:02:29PM +0200, Florian Weimer wrote:
> Gregor Hoffleit <[EMAIL PROTECTED]> writes:
>
> > I talked to RMS, Eben Moglen and GvR. The bad news: According to RMS+Moglen,
> > the license used in Python 2.1 still is not yet compatible with the GPL. Th
.1 anytime soon, I'll hold
off on 2.1.1 a bit longer."
Do you think 2.0.1 might be out before July 1 ? IMHO this is the last date
at which we could start a migration of the python2-* packages to the name
python-* (the python-* 1.5.2 packages would be renamed python1.5-*, just for
completeness).
Gregor
ages that don't have a
correct, explicit versioned dependency on python-base like
Depends: python-base (>= 1.5), python-base (<< 1.6)
or
Depends: python2-base (>= 2.0), python2-base (<< 2.1)
Gregor
On Sun, Jun 03, 2001 at 07:06:09PM +0200, Florian Weimer wrote:
> Gregor Hoffleit <[EMAIL PROTECTED]> writes:
>
>>> This is probably correct, but it is completely irrelevant in our case.
>>> Some parts of Python 2.1 are still covered by the GPL-incompatible
>&g
On Thu, Jul 05, 2001 at 07:13:54AM -0700, Neil Schemenauer wrote:
> Gregor Hoffleit wrote:
> > Until now I had the impression that in general it's not necessary to
> > have more than one Python version on your machine at the same time
> > (except perhaps you're a P
On Thu, Jul 05, 2001 at 07:56:57AM -0700, Neil Schemenauer wrote:
> Gregor Hoffleit wrote:
> > Sorry ? What problems do you have installing Python 2.1 in /usr/local on
> > a Debian system ?
>
> Sometimes /usr/local/bin/python is used instead of /usr/bin/python. For
> ex
On Thu, Jul 05, 2001 at 05:33:37PM +0200, Gregor Hoffleit wrote:
> On Thu, Jul 05, 2001 at 07:56:57AM -0700, Neil Schemenauer wrote:
> > > That's our current setup (well-behaved packages should have a dependency
> > > on "python-base >= 1.5, python-base &l
ase << X.(Y+1)
Thanks,
Gregor
about python packages based on this branch? I has
> the advantage of a recent version which can go into woody.
I guess this answers that question:
On Wed, Jul 04, 2001 at 01:31:21PM +0200, Gregor Hoffleit wrote:
> First of all the good news: You have managed to talk me into making the
> big ste
ned, we have to make up a solution for
the existing potato packages that have incomplete dependencies (like
"python-base (>= 1.5.2-1)") for the case where a user just tries
"apt-get install python-base" with woody. If Python 2.1.1 would include
a python-base package, these (buggy) potato packages wouldn't get
upgraded. OTOH, I don't want to include a long list of conflicts with
a python-base 2.1.1 package.
Gregor
bust system that makes it
possible to provide python-* packages that work for all installed Python
versions. Maybe like the emacsen system.
Gregor
Cyrille, I's sure you don't mind quoting your mail in debian-python:
* Cyrille Chepelov <[EMAIL PROTECTED]> [010726 21:10]:
> Le jeu, jui 26, 2001, à 05:24:04 +0200, Gregor Hoffleit a écrit:
> > It's been much too long since I posted the last status report. I'm
* Radovan Garabik <[EMAIL PROTECTED]> [010726 18:49]:
> On Thu, Jul 26, 2001 at 05:24:04PM +0200, Gregor Hoffleit wrote:
> > Then, we still have to agree on a strategy how to set up the
> > dependencies, in order to make the upgrade work in an intuitive way.
> >
&g
a
dependency on that specific Python version (something like
"python-base (>= 1.5), python-base (<= 1.6)" in that case). Most
packages in potato, though, only have "python-base (>= 1.5)".
Therefore, we have to drop the python-base package for future Python
revisions.
Gregor
opinion since he maintains a lot of these packages.
Have you looked at my experimental Python packages, at
http://people.debian.org/~flight/python/snapshot/ ? I haven't yet tried
your packages, but it sounds like you started from scratch ?
Gregor
ointing at http://people.debian.org/~flight/python/snapshot.
Gregor
* Neil Schemenauer <[EMAIL PROTECTED]> [010906 16:27]:
> Gregor Hoffleit wrote:
> > Have you looked at my experimental Python packages, at
> > http://people.debian.org/~flight/python/snapshot/ ? I haven't yet tried
> > your packages, but it sounds like you started
"Replaces: python-net, ..." and/or
"Provides: python-net, ..." and/or "Conflicts: python-net, ..." ?
I'm a little bit lost in the actual consequences of those.
Gregor
rrors were encountered while processing:
python-base_1.5.2-4_i386.deb
For the sake of completeness, this is dpkg -s python-{bsddb,curses}:
Package: python-bsddb
Status: install ok installed
Priority: optional
Section: interpreters
Installed-Size: 28
Maintainer: Gregor Hoffleit <[EMAIL PROTECT
g fails to upgrade: Whatever package is mentioned second in the
fields, dpkg won't remove, while the first is no problem.
I guess this is one of dpkg's thousand unfixed bugs, but is there any
workaround to this problem ?
Gregor
bar, we'll call it foo-bar-python. Therefore, pygtk would
become libgtk-python (just like libgtk-perl). If the extension is a
genuine Python module, call it python-foo-bar.
(3) The current perl scheme: Call the package libfoo-bar-python.
I guess the preferences of the Python maintainers are at (1). Still,
perhaps we can discuss this and come to a more general solution that
satisfies most concerns.
Gregor
I have a quite urgent problem while polishing the new Python packages:
Do we prefer our packages to use tk8.2 or on tk8.0 ?
Python's Tkinter extension module (package python-tk) needs to be linked to
libtk. I wonder if I should stay with libtk8.0 or switch to libtk8.2 for the
final potato package
t a typical Python
installation. Experienced users can strip down the system by using
"python-base".
I'm not sure about python-tk and idle, though, since they depend on X11 at
last. As well arguable are the packages that are now in Suggests (elisp
depends on an emacsen), shou
ependencies possible: Something like "python (>=1.5.2)" currently
simple doesn't work, and you have to simulate it with e.g. "python-base
(>=1.5.2), python-gdbm (>=1.5.2)".
Please do the task-python* packages anyway!
Gregor
pgpHbrSuQDyde.pgp
Description: PGP signature
e a generic package format for Zope products--if there
was a decent solution for this, I'd certainly prefer this about manually
packaging each single product.
Then, somebody from zope.org/Members wrote a script to package a big number
of Zope products in a single .deb file.
Gregor
n
(clearly not perfect!) is to use a per-case judgement--if there's GPL code
in a package, ask the author if it's okay to use it with Python2 code. If he
says alright, go on with packaging. If he says nogo (as the FSF did for
readline), do away with the package (therefore python2-base d
On Fri, Feb 16, 2001 at 01:51:14PM +0100, M.-A. Lemburg wrote:
> Gregor Hoffleit wrote:
> >
> > If somebody could give me a legal advice that the Python license is in fact
> > compatible with the GPL, and if this was accepted by the guys at
> > debian-legal@lists.debian
1 - 100 of 131 matches
Mail list logo
