r/bin/gcc, etc. are always symlinks to the real interpreter on Debian,
not wrapper scripts - other distributions have tried to do this as a wrapper
script and the result wasn't pretty.
Avoiding the performance hit would require that any changes to the banner
be made in the python source itself.
FTR, UbuntuStudio is an official Ubuntu flavor, not a derivative ;)
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.or
On Sat, May 16, 2020 at 11:09:33AM +0800, Paul Wise wrote:
> On Fri, 2020-05-15 at 19:56 -0700, Steve Langasek wrote:
> > FTR, UbuntuStudio is an official Ubuntu flavor, not a derivative ;)
> Woops. Did that change at some point or did I mix them up with another
> distro or jus
17 Dec 2023 at 18:15, Andreas Tille wrote:
> > > Is there
> > > any better way than editing debian/obitools.substvars in d/rules by
> > > adding some override_dh_gencontrol?
> >
> > Remove the line:
> >
> > Cython>=0.24
> >
> > fro
e, alpha, arm, hppa, i386,
> ia64, m68k, mips, mipsel, powerpc, s390, sparc
>gimp1.2 |1.2.5-3 | unstable | all
Yes, testing copes with this just fine; since gimp1.2 now comes from the
gimp source package, when gimp makes it into testing the old
source/binary packages will be removed
On Mon, Sep 29, 2003 at 10:47:09PM +0200, Matthias Klose wrote:
> > Missing builds
> > ==
> > * libapache2-mod-python: powerpc
> already asked for rebuild ... no reaction.
I could take a look at this in the next day or two, if no one else
bites.
--
Stev
though debootstrap has a 'fake' s-s-d implementation, the buildds
don't use it, and I'm given to understand that there's no plan to make
them start using it. (Ran into this when someone decided *on the buildd
side* that php4 should similarly build-depend on apache... feh...)
Cheers,
--
Steve Langasek
postmodern programmer
pgp3KTENFdOek.pgp
Description: PGP signature
of packages out
of testing. libedit at least will move into testing on its own, and we
may be able to get krb4 and heimdal (and therefore coreutils) in with a
minimum of hinting whether or not cyrus-sasl2 is ready.
> The remaining buggy packages are cyrus-sasl2, heimdal, and pyddr. I
t's
Essential, given that no packages from Ubuntu are going to be depending on
it (being Essential)?
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
signature.asc
Description: Digital signature
ssential packages (e.g., in
this case python-minimal Depends: python2.4-minimal).
I guess you could want an Essential python in order to write debconf config
scripts or postrm scripts in python. Is anyone doing this?
--
Steve Langasek Give me a lever long enough and a Free OS
De
lib/python2.3/site-packages/foo between two separate packages...)
Also, if you really put all of these files in
/usr/lib/python2.3/site-packages, doesn't that make it unnecessarily
difficult to distinguish between symlinks managed by python-support, and
symlinks managed by the packaging system?
On Fri, Jan 20, 2006 at 10:47:19AM +0100, Matthias Klose wrote:
> Steve Langasek writes:
> > On Wed, Jan 18, 2006 at 01:06:39PM +0100, Matthias Klose wrote:
> > > the design decision of putting the binary-all python packages in a
> > > separate directory into /var/lib/
language than shell.
I asked this question earlier, and no one answered. Are there .config
scripts being written in python today in Ubuntu? (Hmm, where are the python
bindings for debconf, and what ensures that they're installed?)
--
Steve Langasek Give me a lever lo
On Fri, Jan 20, 2006 at 09:52:09AM -0800, Matt Zimmerman wrote:
> On Fri, Jan 20, 2006 at 09:40:55AM -0800, Steve Langasek wrote:
> > I asked this question earlier, and no one answered. Are there .config
> > scripts being written in python today in Ubuntu? (Hmm, where are the pyth
d worth writing in a higher-level language than shell.
> > This is surely true; Steve Langasek asked if this was a real issue in
> > Ubuntu or merely a potential issue.
> > Granted if it is a real issue, then why not use perl? Yes, I hate
> > perl too, but really, the a
I guess this is largely equivalent to what I suggested
above (allowing both the existing approach to binary extensions, and your
enhanced automation).
> Can we neglect the dependency issues for modules available for
> non-default python versions, seeing these just as an aid for doing a
> tr
e, which makes that another month we could've used to start on
this the hard way. :/ It would certainly be easier to do the transition
using the new infrastructure, but that still blocks on having that
infrastructure in place.
--
Steve Langasek Give me a lever
the package which
can't be built from source, because removing such a file would break
idempotency of the build->clean->build cycle; but that could only happen
with non-free packages.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
ed trap handling in order to
catch programming errors that *can* be fixed up in the kernel, but only at a
high cost.
> other test failures:
> - test_bz2 on alpha (decoding error)
Have you reproduced this failure outside the buildds, or do you need someone
to give it a try?
--
Steve Langase
n on python
(>= 2.3), python (<< 2.4) to enforce this...
> Also, to make python-gtk2 support more than one version, we could only
> achieve that by providing the extensions in a single package or building
> them on install time. Has anyone thought about this?
Sure, this has been d
On Sat, Apr 29, 2006 at 10:40:50PM -0600, Bruce Sass wrote:
> On Sat April 29 2006 16:01, Steve Langasek wrote:
> > On Sat, Apr 29, 2006 at 06:28:32PM -0300, Gustavo Noronha Silva wrote:
> > > Also, to make python-gtk2 support more than one version, we could
> > > onl
On Mon, May 01, 2006 at 08:57:17PM +0200, Marc Dequènes wrote:
> Steve Langasek <[EMAIL PROTECTED]> writes:
> >> Any summaries, partial specs, top level descriptions, particularly good
> >> explanations of the stumbling blocks, etc., available for reading?
, then
whichever package implements python2.4-ontopofsoya should take care of the
rest. If python-ontopofsoya does not have the proper dependencies to make
its module usable with python2.4, then it should not be declaring that it
Provides: python2.4-ontopofsoya.
--
Steve Langasek
7;s the point in keeping /usr/lib/python2.3/site-packages/foo.so
> around?
Nothing in policy will require that you do this. We discussed specifically
in the BoF whether it was appropriate to allow building binary modules only
for the current version of python, and the agreement was that yes, thi
endency on the versions of python
that it is compatible with.
That means that if python-ctypes only supports python (<< 2.5), and python
is at Version: 2.5.0-1, python-ctypes will not be installable (and will need
to be updated).
--
Steve Langasek
kage.
Yes, this was also discussed in the BoF, with the same conclusion: because
providing python2.x-foo can only be done safely if the package depends on
the python2.x versions of all other modules it requires, making transitions
more brittle as a result, these virtual packages
versions included in the same package was the selected solution to avoid
> dependency nightmares.
Unfortunately, I don't know that anyone was taking notes at the python BoF,
we were a bit busy running around and discussing; I was hoping that the
videos would be on-line sooner than they apparently will be.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
signature.asc
Description: Digital signature
case of an overlap between a removal of one python version and an
addition of another.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED]
ges/foo/foo.so must not claim to be compatible
with python (>= 2.5).
However, it *should* be possible to provide a toolchain such that this
python-foo can be binNMUed when python-2.5 becomes available and
automatically pick up support for it.
--
Steve Langasek Give me a lever l
ils. With proper debhelper integration it would be even
> simpler.
At this point, with no small portion of the blame on my shoulders, we're way
behind the agreed-upon deadline to have a working dh_python / python-central
solution in unstable, and we do need to get the python2.4 transition sta
andle doing the multiple
binary builds (if required).
- binNMUing such a package becomes possible to change either $minver or
$maxver as needed without any requirement of source edits.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
really start updating modules to the new policy tomorrow.
> Build-Depends will have to require:
> - python (>= 2.3.5-7) (for pyversions script)
Are packages expected to call pyversions directly, or is this something that
should be a versioned dep from one of the other build-dependencies?
stallations for different python
> versions CAN'T coexist without breaking each other.
Can you expand on this? As Joe commented, it sounds fairly broken for these
packages to not be coinstallable.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Devel
to *build*
a package against unstable which depends on python (>= 2.4), but such a
package is not installable in unstable right now and therefore unsuitable
for upload.
You can build a python2.4-flup package, but a python-flup package is not
currently usable in Debian if it depends on python 2.4.
--
On Mon, Jun 19, 2006 at 10:22:17AM +0200, Piotr Ozarowski wrote:
> Steve Langasek ([EMAIL PROTECTED]):
> > On Mon, Jun 19, 2006 at 04:49:10PM +0900, Kai Hendry wrote:
> > > On 2006-06-19T09:45+0200 Matthias Klose wrote:
> > > > flup was probably built with p
aintainers are ok with supporting that interface.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
--
To UNSUBSCRIBE, email to
usly be fixed to not use /usr/bin/pythonX.Y
at all.
For the former, no, it's not the business of end-user packages in general to
attempt to force obsolete versions of dependencies off the system when
they're functionally compatible.
--
Steve Langasek Give
101 - 137 of 137 matches
Mail list logo
