Am Wed, Oct 09, 2024 at 03:52:58PM +0200 schrieb Étienne Mollier:
> > I would, however, still be interested in what lintian says.
> >
> > I may have missed a dependency ;-)
>
> You can lookup lintian flags affecting your software on UDD's
> lintian form[1]. Regarding the use of deprecated Python
Am Sun, Oct 06, 2024 at 08:20:23PM +0200 schrieb Karsten Hilbert:
> Am Sun, Oct 06, 2024 at 11:51:39AM -0400 schrieb Louis-Philippe Véronneau:
>
> > The `uses-deprecated-python-stdlib` lintian tag finally seems to be ready.
> > \0/
...
> >gnumed-client (U)
> >
Am Sun, Oct 06, 2024 at 11:51:39AM -0400 schrieb Louis-Philippe Véronneau:
> The `uses-deprecated-python-stdlib` lintian tag finally seems to be ready. \0/
>
> I'm hereby proposing to do a mass bug filing for all the packages that are
> currently
> using libraries that will be deprecated in Pytho
Am Wed, Oct 26, 2022 at 02:47:31PM -0400 schrieb Sandro Tosi:
> > Python 3.11 marks "mailcap" for removal in 3.13. The
> > documentation speaks about "mimetypes" being a replacement,
> > of sorts.
> >
> > However, I can't really see how "mimetypes" helps in
> > replacing the functionality of "mail
Dear list,
Python 3.11 marks "mailcap" for removal in 3.13. The
documentation speaks about "mimetypes" being a replacement,
of sorts.
However, I can't really see how "mimetypes" helps in
replacing the functionality of "mailcap".
Put another way: what is the suggested way of replacing that
module
Am Thu, Mar 17, 2022 at 01:00:40PM -0400 schrieb Sandro Tosi:
> since it's not the first time you write to this list with a traceback
> or error, asking for help, and the answer from here is generally
> pretty straight-forward, i'm wondering why you were not able to find
> the solution directly? s
On Mon, Oct 15, 2018 at 09:40:27AM +, PICCA Frederic-Emmanuel wrote:
> I found in the code a string with a ur''
>
> This is the problematic line.
>
> I do not know if this is a valid string construction.
Under Python 2 it is.
Under Python 3 it is not.
u'test' is valid but extraneo
Hi,
I have filed an RFP
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=823141
(I would rather name those WFP - Wish For Packaging, but, oh
well) for a Python based timeline application
http://thetimelineproj.sourceforge.net
Contrary to the report it would need to be named, s
On Wed, Sep 02, 2015 at 09:06:01PM +1200, Robert Collins wrote:
> > Ben Finney writes:
>
> > According to Robert's earlier message, that means the Distutils
> > metadata file needs to be not in the application's private directory,
> > but in a directory on the Python module search path. Th
> Also, if I implement new features I am not necessarily going to test
> them on python3 unless it somehow happens automatically. Running the
> test suite twice is not much of an option, though, because it already
> takes a lot of time to run, and doubling the time it takes just means
> that code i
With all this desire to drop Python 2 eventually -- there are
packages, say gnumed-client, which simply cannot be ported to
Python 3 ATM because important dependencies don't exist for
Py 3, say pythonX-wxgtk.
Karsten
--
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD 45
On Wed, Apr 15, 2015 at 04:27:51PM -0400, Paul Tagliamonte wrote:
> 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
On Mon, Jul 21, 2014 at 10:17:20AM +1000, Brian May wrote:
> Not sure I understand it (that space in ' ''' seems to be important?),
I would guess it creates a 3-quotes Python string embedded into a single-quote
one:
test = ' single-quotes string with: '''3-quotes-string''' embedded into it'
Wr
filed against wxwidgets3.0 and python-wxgtk2.8 asking
for python3-wxgtkXX and/or python-wxgtk3.0. Let's see what
happens.
> On Mon, Jul 07, 2014 at 10:47:28PM +0200, Karsten Hilbert wrote:
> > GNUmed (an Electronic Medical Record System) runs under
> > Python 2 with wxPython 2.8
Hi all,
I am upstream for a Python application:
http://wiki.gnumed.de
which is packaged in Debian:
https://packages.debian.org/search?keywords=gnumed-client
and maintained:
http://blends.debian.org/med/tasks/practice
by the Debian Med Team:
https://www.debian
On Mon, Mar 30, 2009 at 03:27:55PM +0200, Josselin Mouette wrote:
> I also tend to prefer solutions that look more robust, for example
> against existing PYTHONPATH variables. The rest is a matter of taste.
This is (now) the relevant part in /usr/bin/gnumed:
# packages which install the GNUmed
On Mon, Mar 30, 2009 at 02:18:31PM +0200, Josselin Mouette wrote:
> > - modify sys.path inside gnumed.py appropriately
> > (which I disapprove of as it means moving
> > platform specific code from platform specific
> > layers into platform-agnostic Python code)
>
> This one is my fa
On Mon, Mar 30, 2009 at 07:27:59AM +0200, RKI Andreas wrote:
>> While it is tempting to "slip in" not strictly needed improvements into
>> a bugfix it is usually - as is quite evident here - a road down which
>> dragons live.
>>
>> Don't.
>
> Well, I didn't in the first place (look at 0.3.12 packa
On Mon, Mar 30, 2009 at 10:54:31AM +0200, Josselin Mouette wrote:
> However the document you read makes it clear that it is better,
> for python applications, to put the (private) modules in a private
> location. Both installation schemes have been available for a long time,
> and this issue is or
> >> That is, you're now shipping some modules in a private location
> >
> > This is what I understood as recommendation in #516037.
>
> Yes, that's recommended, but it's not a requirement.
>
> Anyway, you almost got it!
>
> >> (usr/share is
> >> not in PYTHONPATH), so they are not found when y
For what it's worth here is my concluding suggestion in that bug thread:
-
My suggestion would be:
- call gnumed.py with the python -m ... option if that works
- this would rid us of that hardcoded path - a great thing
- leave modules where they are and GNUmed finds them by default
> > That is, you're now shipping some modules in a private location
>
> This is what I understood as recommendation in #516037.
Well, you are trying to solve two things at once:
1) make the "python -m" calling convention work
2) move GNUmed modules to a private location
While, yes, this WAS rec
Just to add some information directly from a GNUmed developer:
> In prinzipe the wrapper script /usr/bin/gnumed does the following
>
> python /var/lib/python-support/python2.3/Gnumed/wxpython/gnumed.py
>
> This exits with the error message
>
>CRITICAL ERROR: Cannot load GNUmed Python modu
23 matches
Mail list logo
