Hi debian-python (2023.09.10_05:23:12_+)
> We have scheduled a Python BoF at DebConf23:
> https://debconf23.debconf.org/talks/27-python-bof/
> It will be on Sep 16 (Sat): at 10:30 local time (05:00 - 05:45 UTC)
We had the BoF, notes:
https://salsa.debian.org/debconf-team/public/
On Sunday, September 10, 2023 1:23:12 AM EDT Stefano Rivera wrote:
> We have scheduled a Python BoF at DebConf23:
> https://debconf23.debconf.org/talks/27-python-bof/
> It will be on Sep 16 (Sat): at 10:30 local time (05:00 - 05:45 UTC)
>
> I started getting together an agenda in:
> https://pad.dc
We have scheduled a Python BoF at DebConf23:
https://debconf23.debconf.org/talks/27-python-bof/
It will be on Sep 16 (Sat): at 10:30 local time (05:00 - 05:45 UTC)
I started getting together an agenda in:
https://pad.dc23.debconf.org/p/27-python-bof
Please help me to build it out.
Stefano
--
St
On 08/14/2010 03:41 PM, Bastian Venthur wrote:
> Am 14.08.2010 15:34, schrieb Guy Hulbert:
>> On Sat, 2010-14-08 at 15:14 +0200, Bastian Venthur wrote:
>>> The minutes are currently polished by the participants of the BoF and
>>> will be published afterwards.
>>
>> Why do minutes need to be "polish
Am 14.08.2010 15:34, schrieb Guy Hulbert:
> On Sat, 2010-14-08 at 15:14 +0200, Bastian Venthur wrote:
>> The minutes are currently polished by the participants of the BoF and
>> will be published afterwards.
>
> Why do minutes need to be "polished" ... ?
Maybe polished isn't the correct term. Wha
On Sat, 2010-14-08 at 15:14 +0200, Bastian Venthur wrote:
> The minutes are currently polished by the participants of the BoF and
> will be published afterwards.
Why do minutes need to be "polished" ... ?
--
--gh
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subje
Hi,
The minutes are currently polished by the participants of the BoF and
will be published afterwards.
Cheers,
Bastian
Am 14.08.2010 09:09, schrieb Sandro Tosi:
> Hello,
> there was a BoF[1] about the plans for python in squeeze+1 but no
> minutes was sent to the list: 8 days are passed, so w
On Saturday, August 14, 2010 03:09:35 am Sandro Tosi wrote:
> Hello,
> there was a BoF[1] about the plans for python in squeeze+1 but no
> minutes was sent to the list: 8 days are passed, so we have waited
> (while others, like perl team, sent it moments after the bof).
>
> [1] http://penta.debcon
Hello,
there was a BoF[1] about the plans for python in squeeze+1 but no
minutes was sent to the list: 8 days are passed, so we have waited
(while others, like perl team, sent it moments after the bof).
[1] http://penta.debconf.org/dc10_schedule/events/696.en.html
I think it's important to have s
I know I'm a broken record on this, and I (currently ;) have very little power
to do much about it other than *talk*, but...
On May 11, 2010, at 10:18 PM, Piotr Ożarowski wrote:
>Why am I mentioning Ubuntu at all? Because all decisions about Python in
>Debian are made there.
My own personal hope
On May 18, 2010, at 11:42 PM, anatoly techtonik wrote:
>On Mon, May 10, 2010 at 2:23 PM, Piotr Ożarowski wrote:
>>
>> Why I think derivatives should not add new versions?
>> * because it's mostly chasing numbers - I'm pretty sure there are not
>> more than 10 packages that require Python >= 2.6
On May 10, 2010, at 01:23 PM, Piotr Ożarowski wrote:
>Why I think derivatives should not add new versions?
>* because it's mostly chasing numbers - I'm pretty sure there are not
> more than 10 packages that require Python >= 2.6 and are not easy to
> port to 2.5 in Ubuntu 10.04,
>* because when
Hello
>> The premise of your implication is false.
> Please translate to simple English.
premise: something you base your reasoning on
implication: something you present as true as a result of a reasoning
In other words: Your argument says something that is based on an inexact
thought.
If I un
anatoly techtonik (18/05/2010):
> Please translate to simple English.
This was simple English, even French guys understood it…
Mraw,
KiBi.
signature.asc
Description: Digital signature
2010/5/11 Piotr Ożarowski :
>
> Why am I mentioning Ubuntu at all? Because all decisions about Python in
> Debian are made there.
>
> Do you still want me to answer your questions or is it clear already why
> I am acting as an asshole?
I can't see an asshole action so fat. The thing that troubles
On Tue, May 18, 2010 at 23:01, anatoly techtonik wrote:
> On Tue, May 11, 2010 at 9:57 PM, Sandro Tosi wrote:
>>
>> Indeed, that's what we expect from the python maintainer:
>>
>> - understand what changes between to major release
>> - prepare a draft for the transition, checking packages that br
On Tue, May 11, 2010 at 9:57 PM, Sandro Tosi wrote:
>
> Indeed, that's what we expect from the python maintainer:
>
> - understand what changes between to major release
> - prepare a draft for the transition, checking packages that brake
> (reporting bugs and hopefully patches)
> - get consensus f
Hello anatoly,
I'm quite tired of your emails where you're only capable of attacking
without being able to provide valuable contributions to Debian. from
my POV, if you don't like know we do things, then help us fix them and
STOP complaining; otherwise, simply choose another distribution and
leave
2010/5/10 Piotr Ożarowski :
>
> I had to explain many times (mostly to Pylons users) why packages not
> touched by Ubuntu developers are not working on Ubuntu, I know the pain.
Why...?
--
anatoly t.
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscri
On Mon, May 10, 2010 at 2:23 PM, Piotr Ożarowski wrote:
>
> Why I think derivatives should not add new versions?
> * because it's mostly chasing numbers - I'm pretty sure there are not
> more than 10 packages that require Python >= 2.6 and are not easy to
> port to 2.5 in Ubuntu 10.04,
Backport
On Sat, May 8, 2010 at 11:51 AM, Emilio Pozuelo Monfort
wrote:
\>> 80kb of duplicated
>> code (even 8Mb) doesn't worth wasted time for troubleshooting in 2010.
>> It may be a reason for security, but why not just let packages
>> register their used version in Debian registry and track it there?
>
On Sat, May 8, 2010 at 1:58 PM, Jakub Wilk wrote:
> * anatoly techtonik , 2010-05-08, 07:16:
>>
>> Cover stdeb (anything else?), the reasons (if any) political and
>> technical, why it (or anything else) can not be used instead
>> unpythonic and unfamiliar make/debhelper stuff. It is not really
>>
Lino,
I started using Debian because I love to see a long list of packages
with new upstream releases available on my hard drive every single
morning. Not just 100 best known applications but every niche
app./library I use. I know they are prepared by either upstream authors
or people who simply u
On Tue, May 11, 2010 at 19:51, Lino Mastrodomenico
wrote:
> Disclaimer: I'm a Python developer, not a package maintainer, so take
> what I write with a grain of salt.
>
> 2010/5/10 Piotr Ożarowski :
>> Why I think derivatives should not add new versions?
>> * because it's mostly chasing numbers -
Disclaimer: I'm a Python developer, not a package maintainer, so take
what I write with a grain of salt.
2010/5/10 Piotr Ożarowski :
> Why I think derivatives should not add new versions?
> * because it's mostly chasing numbers - I'm pretty sure there are not
> more than 10 packages that require
On Tue, 11.05.2010 at 00:23:55 +0200, Piotr O??arowski wrote:
> [Toni Mueller, 2010-05-10]
> > PS: The address "www.griffith.cc" that you mention in your .sig, does
> > not resolve, and afair, Berlios is not a good project host.
>
> To which IP your DNS points you to?
Yesterday, it didn't r
[Toni Mueller, 2010-05-10]
> It's still only a problem in Ubuntu until Debian makes a possibly
> similar transition, right?
The problem is it's out of our hands.
> > I want to give Ubuntu CDs to my friends telling them that there are
> > few bits of my work there. I don't want to explain to them
On Mon, 10.05.2010 at 21:17:40 +0200, Piotr O??arowski wrote:
> [Toni Mueller, 2010-05-10]
> > problem. It's their choice to deviate from Debian packaging, so why
> > shouldn't it be also their problem (not ours) if they break stuff, too?
> changes in Python interpreter or python-central are late
[Toni Mueller, 2010-05-10]
> On Mon, 10.05.2010 at 13:23:01 +0200, Piotr O??arowski
> wrote:
> > derivatives what to do, though. I'd never complain in public and would
> > let you do whatever you want (that's derivative's right after all)... if
> > Ubuntu's decisions would not have so strong impa
Hi Piotr,
On Mon, 10.05.2010 at 13:23:01 +0200, Piotr O??arowski wrote:
> derivatives what to do, though. I'd never complain in public and would
> let you do whatever you want (that's derivative's right after all)... if
> Ubuntu's decisions would not have so strong impact on us - when I'm
than
[Barry Warsaw, 2010-05-10]
> Note that today is the first day of the Ubuntu Developer Summit for Ubuntu
> 10.10. On Thursday we are going to have a session to discuss the roadmap for
> Python on Ubuntu and what version(s) we will ship by default in 10.10. I
> invite your constructive input in thi
On May 08, 2010, at 10:55 AM, Piotr Ożarowski wrote:
>The only reason I got from Ubuntu for doing transitions outside Debian
>and allowing Debian to do it later (and forcing us to fix after them)
>is... "because you are slow". All technical reasons (like relative
>imports in 2.6) were easy to prov
Jakub Wilk writes:
> * Piotr Ożarowski , 2010-05-08, 10:55:
>>The only reason I got from Ubuntu for doing transitions outside Debian
>>and allowing Debian to do it later (and forcing us to fix after them)
>>is... "because you are slow".
>
> That's quite ironic given the fact that the major inhibi
On 05/08/2010 10:55 AM, Piotr Ożarowski wrote:
> The only reason I got from Ubuntu for doing transitions outside Debian
> and allowing Debian to do it later (and forcing us to fix after them)
> is... "because you are slow".
Of course Ubuntu is faster, they fixed all the python2.6 bug by disabling
Hi anatoly,
On Sat, 08.05.2010 at 07:41:05 +0300, anatoly techtonik
wrote:
> three are used even though only one is default. But there is no
> Python2.6 even in backports on Lenny and I need it for python-expect,
> to automate my stuff. This also requires explanation to refer people
> when they
* Piotr Ożarowski , 2010-05-08, 10:55:
The only reason I got from Ubuntu for doing transitions outside Debian
and allowing Debian to do it later (and forcing us to fix after them)
is... "because you are slow".
That's quite ironic given the fact that the major inhibitor of the
Python 2.6 transi
Hi Piotr,
On Sat, 08.05.2010 at 14:33:39 +0200, Piotr O??arowski wrote:
> [Toni Mueller, 2010-05-08]
> > On Sat, 08.05.2010 at 10:55:40 +0200, Piotr O??arowski
> > wrote:
> > > [anatoly techtonik, 2010-05-08]
> > > > Why not use virtualenv for Packaging applications?
> > >
> > > Every single
[Toni Mueller, 2010-05-08]
> On Sat, 08.05.2010 at 10:55:40 +0200, Piotr O??arowski
> wrote:
> > [anatoly techtonik, 2010-05-08]
> > > Why not use virtualenv for Packaging applications?
> >
> > Every single DD understands that shipping two copies of the same file is
> > one too many.
>
> actual
Hi,
On Sat, 08.05.2010 at 10:55:40 +0200, Piotr O??arowski wrote:
> [anatoly techtonik, 2010-05-08]
> > Why not use virtualenv for Packaging applications?
>
> Every single DD understands that shipping two copies of the same file is
> one too many.
actually, I don't.
Virtualenv has been a lif
* anatoly techtonik , 2010-05-08, 07:16:
Cover stdeb (anything else?), the reasons (if any) political and
technical, why it (or anything else) can not be used instead
unpythonic and unfamiliar make/debhelper stuff. It is not really
helper if no one understands how it works, and it is confusing fo
On 08/05/10 06:41, anatoly techtonik wrote:
> 80kb of duplicated
> code (even 8Mb) doesn't worth wasted time for troubleshooting in 2010.
> It may be a reason for security, but why not just let packages
> register their used version in Debian registry and track it there?
Because if there's a secur
[anatoly techtonik, 2010-05-08]
> Only ideas.
> "Using Python toolchain for Python modules/apps in Debian?"
> Cover stdeb (anything else?), the reasons (if any) political and
> technical, why it (or anything else) can not be used instead
> unpythonic and unfamiliar make/debhelper stuff. It is not r
One more thing for "Python Policy 2010." Status quo with examples.
Trac comes with jQuery suitable for this version of application. But
Debian policy dictates to remove duplicated code, so jQuery is
replaced with some other version rather than required. This creates
problems with plugins and Debia
On Tue, May 4, 2010 at 11:20 PM, Richard Darst wrote:
>
> I was looking through the talks submitted to DebConf, and noticed
> there weren't very many Python related talks. Given the amount there
> is to discuss related to Python in Debian, it would be great to see
> s
On May 04, 2010, at 04:20 PM, Richard Darst wrote:
>I was looking through the talks submitted to DebConf, and noticed
>there weren't very many Python related talks. Given the amount there
>is to discuss related to Python in Debian, it would be great to see
>some more submissions
Hello,
I was looking through the talks submitted to DebConf, and noticed
there weren't very many Python related talks. Given the amount there
is to discuss related to Python in Debian, it would be great to see
some more submissions.
Perhaps the list can suggest some talks and we can nom
On Fri, 14 Nov 2003, Luca - De Whiskey's - De Vitis wrote:
> Actually my proposed sentence is not accurate, but something more might be
> added to that paragraph.
> zope-* .postinst and only those files expect a shared question to be available
> at configuration time. zope package is the only one
On Fri, Nov 14, 2003 at 11:36:33AM -0500, Joey Hess wrote:
> That's not at all accurate. Every package that has a config script that
> expects to use a template must include a copy of the template in the
> package. Dependencies will not be honored at preconfigure time.
Thanks for replying.
Actuall
Luca - De Whiskey's - De Vitis wrote:
> On Fri, Nov 14, 2003 at 01:28:21PM +0100, Andreas Tille wrote:
> [...]
> > Hmmm, are you sure that this paragraph in the manual makes sense
> > I guess if a zope package depends from zope all relevant debconf information
> >
drop templates,
> > and everyone was happy... but this never happened ;)
I'm not familiar with zope's packaging, but I hope you all realize that
dependencies are not guaranteed to be satisfied at debconf preconfigure
time. That is the reason you sometimes need shared templates.
--
On Fri, Nov 14, 2003 at 01:28:21PM +0100, Andreas Tille wrote:
[...]
> Hmmm, are you sure that this paragraph in the manual makes sense
> I guess if a zope package depends from zope all relevant debconf information
> is available and copying the same stuff over and over makes no sen
onfig and templates files have to be dropped, and
> packages do no more have to call dh_installdebconf (but of course they
> still depends on debconf). And postinst might indeed be automatically
> created by dh_zope. This is very easy, customize the attached postinst-zope
> script and put
ope-cmfcore.postinst.
> > And that's all!
> I indeed proposed that solution, but as far as i can read from
> debconf-devel(7):
>
> SHARED TEMPLATES
>It's actually possible to have a template and a question that are
>shared among a set of packag
stinst file, e.g. zope-cmfcore.postinst.
> > And that's all!
>
> I indeed proposed that solution, but as far as i can read from
> debconf-devel(7):
>
> SHARED TEMPLATES
>It's actually possible to have a template and a question that are
>sha
Le Thu, Nov 13, 2003 at 02:45:34AM -0600, Luca - De Whiskey's - De Vitis a
écrit :
> I good improvement would have been to create dh_zope command (as part of a
> zope-dev) package, which would have been responsible of installing/updating
> those files (like code snippets). I meant zopectl for othe
d dependency on zope if needed (the shared/zope/restart question
> was finalized in 2.5.1-2.7 according to its changelog) and get a recent
> postinst file, e.g. zope-cmfcore.postinst.
> And that's all!
I indeed proposed that solution, but as far as i can read from
debconf-devel(7):
SHARE
[Cc me on reply, I am not subscribed to this list]
Hi there,
it looks like the solution proposed by Luca in
http://lists.debian.org/debian-python/2002/debian-python-200211/msg00025.html
has never been implemented, most (if not all?) Zope packages still ship
their own templates files.
The right
Le sam 13/09/2003 à 07:24, Terry Hancock a écrit :
> Is there a python binding for debconf? The debconf-doc
> package mentions bash and perl bindings and communicating
> by pipes, but not python.
Yes, it is in the debconf package. Just try "import debconf".
> It would s
Hi All,
I've been lurking for a long time, but just thought of a
question:
Is there a python binding for debconf? The debconf-doc
package mentions bash and perl bindings and communicating
by pipes, but not python. It would seem the natural choice
for config scripts for python packages at
t's .py's for every installed and supported version of python
> > in it's postinst, then doing a 'dpkg-reconfigure -p critical '
> > should re-compile the package. There must be ways to use this in scripts
> > to ensure correct installation-removal of package
Donovan Baarda wrote:
1) moving /usr/lib/python* into /usr/share/python*. I consider this low
priority, but something that should be done one day. There are possibly
some issues with separating binary extension modules from .py python
modules that would to be resolved.
This doesn't work. /usr/lib/p
e correct installation-removal of packages.
[...]
hmm, how does this work for packages like mailman and zope, where more
than recompilation is done in the scripts (debconf configs ...)?
I don't want be asked these questions when I upgrade python.
> The problem of dpkg-reconfigure is
Donovan Baarda writes:
> On Fri, 2003-04-18 at 19:54, Matthias Klose wrote:
> [...]
> > And/or take a look at dh_python, which does all this for "free"...
>
> BTW, where can we find this? I'd like to take a look.
Included in debhelper.
On Sat, 2003-04-19 at 08:09, Matthias Klose wrote:
> Bastian Kleineidam writes:
> > On Fri, Apr 18, 2003 at 12:25:08PM +0200, Tim Dijkstra wrote:
> > > On Fri, 18 Apr 2003 11:22:11 +0200
> > > Luca - De Whiskey's - De Vitis <[EMAIL PROTECTED]> wrote:
> > > > file:///usr/share/doc/python/python-poli
On Fri, 2003-04-18 at 19:54, Matthias Klose wrote:
[...]
> And/or take a look at dh_python, which does all this for "free"...
BTW, where can we find this? I'd like to take a look.
--
Donovan Baardahttp://minkirri.ap
Bastian Kleineidam writes:
> On Fri, Apr 18, 2003 at 12:25:08PM +0200, Tim Dijkstra wrote:
> > On Fri, 18 Apr 2003 11:22:11 +0200
> > Luca - De Whiskey's - De Vitis <[EMAIL PROTECTED]> wrote:
> > > file:///usr/share/doc/python/python-policy.txt.gz (that is shipped
> > > with the "python" package).
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, Apr 18, 2003 at 12:25:08PM +0200, Tim Dijkstra wrote:
> On Fri, 18 Apr 2003 11:22:11 +0200
> Luca - De Whiskey's - De Vitis <[EMAIL PROTECTED]> wrote:
> > file:///usr/share/doc/python/python-policy.txt.gz (that is shipped
> > with the "python"
On Fri, 18 Apr 2003 11:22:11 +0200
Luca - De Whiskey's - De Vitis <[EMAIL PROTECTED]> wrote:
> > 2) I would like to use the debconf-module, but it seems there is no
> > python priority:required, so is this module worthless?
>
> Please, be careful using debconf
Luca - De Whiskey's - De Vitis writes:
> On Fri, Apr 18, 2003 at 10:02:39AM +0200, Tim Dijkstra wrote:
> > 1) Should I ship .py or .pyc or both in the package. Byte-compile at
> > install time? Ask user what to do?
> > Ok, just saw a few other messages on this, my conclusion:
> > Byte-compile at
me. Take a look to other python package: most of them
use this behaviour.
> 2) I would like to use the debconf-module, but it seems there is no
> python priority:required, so is this module worthless?
Please, be careful using debconf: you'd better read the "best packaging
prac
ed when a newer python
becomes the default? With a depends python < X.Y? Seems a waste of band
with, to download a new package only for its postinst run...
2) I would like to use the debconf-module, but it seems there is no
python priority:required, so is this module worthless?
3) The program is pu
Le ven 31/01/2003 à 16:19, Bernhard Kuemel a écrit :
> Secondly I am still confused why the installation of python2.2 made
> the 'compileall.py -q' bug disappear when in any case
> /usr/local/bin/python would have been called.
Because debhelper uses an explicit path to
/usr/lib/python2.2/compileal
Joey Hess wrote:
>
> Bernhard Kuemel wrote:
> > Thank you very much. I had python 2.1 installed and with 2.2 the
> > problem disappeared. Seems python2.2 should be a dependency for
> > debconf and mailman.
>
> Why? They only run python2.2 if it can be foun
On Fri, Jan 31, 2003 at 02:46:00PM +1100, Donovan Baarda wrote:
> On Fri, 2003-01-31 at 09:59, Josselin Mouette wrote:
> > Le jeu 30/01/2003 ? 22:42, Bernhard Kuemel a ?crit :
> [...]
> > > ImportError: /usr/local/lib/python2.2/lib-dynload/math.so: undefined
> >^
Bernhard Kuemel wrote:
> Thank you very much. I had python 2.1 installed and with 2.2 the
> problem disappeared. Seems python2.2 should be a dependency for
> debconf and mailman.
Why? They only run python2.2 if it can be found in the path. I dont
really understand how you could possibly
Josselin Mouette wrote:
> Your python installation is screwed. The compileall.py module in Debian
> does support -q in all versions. It's not possible to be mistaken about
> that, as the error message included in Debian's compileall.py is not
> exactly this one.
Ok so it is a local install of an o
nstead of "#!/usr/bin/env python" to avoid exactly this problem.
If Mailman or debconf or whatever is running python scripts with
"#!/usr/bin/env python" then this is arguably a minor bug that should be
reported against it.
--
On Thu, Jan 30, 2003 at 10:42:11PM +0100, Bernhard Kuemel wrote:
> Josselin Mouette wrote:
> > Le jeu 30/01/2003 à 19:44, Joey Hess a écrit :
> > > > Setting up debconf (1.2.21) ...
> > > > option -q not recognized
> > > > usage: python co
Josselin Mouette wrote:
>
[unable to configure mailman]
> > ImportError: /usr/local/lib/python2.2/lib-dynload/math.so: undefined
>
> > symbol: PyFPE_jbuf
>
> The issue isn't in mailman. You have some python2.2 binaries in your
> /usr/local tree, that's why
Le jeu 30/01/2003 à 22:42, Bernhard Kuemel a écrit :
> Thank you very much. I had python 2.1 installed and with 2.2 the
> problem disappeared. Seems python2.2 should be a dependency for
> debconf and mailman.
> Traceback (most recent call last):
> File "/usr/lib/mailman/bin/
Josselin Mouette wrote:
>
> Le jeu 30/01/2003 à 19:44, Joey Hess a écrit :
> > > Setting up debconf (1.2.21) ...
> > > option -q not recognized
> > > usage: python compileall.py [-l] [-f] [-d destdir] [-s regexp]
> >
> > What version of python2.2 do
Le jeu 30/01/2003 à 19:44, Joey Hess a écrit :
> > Setting up debconf (1.2.21) ...
> > option -q not recognized
> > usage: python compileall.py [-l] [-f] [-d destdir] [-s regexp]
>
> What version of python2.2 do you have installed?
> What does it say when you run --
>
Bernhard Kuemel wrote:
> apt-get dist-upgrade now won't install even a single package. At first I
> chose severity normal because mailman depends on debconf, but now
> totally unrelated packages don't get installed. Unfortunately it seems
> reportbug won't set the sever
Gregor Hoffleit <[EMAIL PROTECTED]> writes:
> Hi,
>
> currently, our Python packages mostly ship .py files and compile them into
> .pyc files at run time in order to save space in the debs.
The way you do it currently is fine. If people don't want pyc, they
can freely delete them.
I don't
Roland Mas <[EMAIL PROTECTED]> writes:
> Maybe we could reuse the Emacs way? Ask Joey to add a dh_python,
> write up a /usr/lib/pythonen-common/python-install, and byte-compile
> at install-time for all the present flavours?
>
> Just an idea, of course.
We have already talked about using
Gregor Hoffleit (2001-03-23 21:39:07 +0100) :
> currently, our Python packages mostly ship .py files and compile
> them into .pyc files at run time in order to save space in the debs.
The Python situation sounds remarkably like the Emacs one, don't you
think? We have several (okay, two) flavours
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 debs.
> >
> > There's no reaso
On Sat, 24 Mar 2001, Bruce Sass <[EMAIL PROTECTED]> wrote:
> > I do think we need somewhere where all the .pyc's are "registered",
>
> "locate .pyc"; or maybe locate .py, .pyc, and .pyo files, then
> reconcile the three lists.
I didn't say the file system isn't a good such place. I just said
we
On Sat, 24 Mar 2001, Moshe Zadka wrote:
<...>
> I do think we need somewhere where all the .pyc's are "registered",
"locate .pyc"; or maybe locate .py, .pyc, and .pyo files, then
reconcile the three lists.
> so when
> a new version of Python comes along, it can recompile them, since pycs
> are no
On Fri, Mar 23, 2001 at 09:39:07PM +0100, Gregor Hoffleit wrote:
> I wonder if I should debconf-ify python-base and add an debconf option that
> sets a system-wide policy about how to deal with .py/.pyc files. That could
> be one of:
>
> * install both .py and .pyc files
> *
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 debs.
>
> There's no reason, though, to keep the .py files on machines that only
> deploy software[
nd compile them into
| .pyc files at run time in order to save space in the debs.
|
| There's no reason, though, to keep the .py files on machines that only
| deploy software[1]
|
| I wonder if I should debconf-ify python-base and add an debconf option that
| sets a system-wide policy about h
Hi,
currently, our Python packages mostly ship .py files and compile them into
.pyc files at run time in order to save space in the debs.
There's no reason, though, to keep the .py files on machines that only
deploy software[1]
I wonder if I should debconf-ify python-base and add an de
93 matches
Mail list logo
