[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: State of tcl/tk for woody ?



On Wed, Feb 28, 2001 at 04:14:04PM +0100, Gregor Hoffleit <gregor@mediasupervision.de> spake forth:
> Just a quick request for comments: What's the status of tcl/tk in woody ?

Basically, upstream introduced yet another major change in a revision (i.e.
8.3.1->8.3.2), and I'm still dealing with the fallout, this having occured
not long after I adopted the packages. A fix is building on my dev box right
now and will be tested/uploaded probably within an hour.

> I guess in the end my question boils down to a question if the combination
> of package pools and our current autobuild daemons in fact do work reliably
> and fast enough.

Since this is a very serious bug, I've set the priority to high. This will
influence the move to testing...

> I have a few packages (python, python2, sketch) that depend and build-depend
> on tcl/tk.
> 
> I noticed that the tcl8.3/tk8.3 packages still have not yet made their way
> from unstable into testing. update_execuses seems to imply that it's a
> problem with the tcl8.3 source at the moment ('tcl8.3 (alpha arm i386 m68k
> powerpc sparc source) is buggy (1 > 0)', 'not considered').
> 
> This 'buggy' seems to be triggered by Bug#87708 'sharedlibextension
> incorrect, breaks pkg_mkIndex', which in fact is a grave bug in 8.3.2-6.

As mentioned above, fixed.

> Now how does this go together with freezing testing ? python2 sits in
> unstables since ages (well, since a few weeks), but has no chance to get
> into testing unless I reupload the package recompiled with tcl/tk8.0.

There's also 8.2, but that shouldn't be necessary...

> python fixes a few important things, too, but is stuck in unstables unless
> tk8.3 gets moved, since only then the autobuilders will start to work on it.
> 
> 
> Perhaps I miss something in the picture, but I have the impression that the
> package pool and the condition (a package must be compiled on all
> architectures) on the migration of packages to testing makes adoption of new
> libraries very, very slow.

-- 
Mike Markley <mike@markley.org>
GPG: 0x3B047084 7FC7 0DC0 EF31 DF83 7313  FE2B 77A8 F36A 3B04 7084

Madness has no purpose.  Or reason.  But it may have a goal.
- Spock, "The Alternative Factor", stardate 3088.7



Reply to: