|
Home > Archive > Debian Developers > August 2004 > libtiff status: only 21 to go
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
libtiff status: only 21 to go
|
|
| Jay Berkenbilt 2004-08-05, 9:14 am |
|
Executive summary: enlightenment is the last package that is blocking
some other package. guikachu's maintainer specifically requested
NMU. Here's the rest of the details.
It's possible that some of these have been uploaded but not processed
far enough for the RC bug to have been closed. My apologies if your
package is in this list.
--
Not counting gtksee, which I already know is being handled, there are
only 21 packages left that still have open tiff-related RC bugs filed
against them. Of these, only one package (epplets) is being blocked
by only one other package (enlightenment). The 21 remaining packages
are:
autotrace
devil
endeavour
enlightenment
epplets
fbi
gnobog
guikachu
k3d
libimager-perl
libtk-img
lightspeed
mountapp
paul
php4-imagick
pixieplus
povray-3.5
qvwm
sear
vrweb
vtk
Of these, only epplets can't yet be rebuilt because it depends upon
enlightenment. (Other packages may still be waiting on things that
have been uploaded but have not yet appeared in unstable. I have not
checked that case.)
That means enlightenment should be the highest priority package for
NMU, and guikachu can also be NMUed immediately without going through
any kind of delayed upload or maintainer approval (since the
maintainer has already specifically requested an NMU).
--
Jay Berkenbilt <ejb@ql.org>
http://www.ql.org/q/
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Michael Koch 2004-08-05, 9:14 am |
| Am Mittwoch, 4. August 2004 17:59 schrieb Jay Berkenbilt:
> Executive summary: enlightenment is the last package that is
> blocking some other package. guikachu's maintainer specifically
> requested NMU. Here's the rest of the details.
>
> It's possible that some of these have been uploaded but not
> processed far enough for the RC bug to have been closed. My
> apologies if your package is in this list.
>
> --
>
> Not counting gtksee, which I already know is being handled, there
> are only 21 packages left that still have open tiff-related RC bugs
> filed against them. Of these, only one package (epplets) is being
> blocked by only one other package (enlightenment). The 21
> remaining packages are:
....
> sear
Don't wait for sear. It's not included in testing/sarge and don
compiles currently. I wait for a lib currently in NEW queue. When it
gets accepted a new version of sear will be uploaded. This upload
will then use the new libtiff4-dev too but currently just rebuilding
doesnt work.
Michael
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Jérôme Marant 2004-08-05, 9:14 am |
| Jay Berkenbilt <ejb@ql.org> writes:
> Executive summary: enlightenment is the last package that is blocking
> some other package. guikachu's maintainer specifically requested
> NMU. Here's the rest of the details.
>
> It's possible that some of these have been uploaded but not processed
> far enough for the RC bug to have been closed. My apologies if your
> package is in this list.
BTW, is rebuilding against libtiff-dev (provided by libtiff4-dev) enough,
or is build-depending on libtiff4-dev really necessary and why?
TIA.
--=20
J=E9r=F4me Marant
http://marant.org
| |
| Jay Berkenbilt 2004-08-05, 9:14 am |
|
> Jay Berkenbilt <ejb@ql.org> writes:
>
>
> BTW, is rebuilding against libtiff-dev (provided by libtiff4-dev) enough,
> or is build-depending on libtiff4-dev really necessary and why?
I'll give my opinion, but someone with more experience with Debian
library issues may contradict me.
My opinion is that if your application uses libtiff directly and does
not use any libraries that use libtiff, then there's no reason for you
to not just use libtiff-dev. At present, libtiff-dev is provided only
by libtiff4-dev (in sid) because libtiff3g-dev no longer exists (in
sid).
It is possible in the future that more than one package will provide
libtiff-dev. If I have anything to do with it, should this happen,
any additional packages that provide libtiff-dev would have versioned
symbols. I think this means that it would be safe for you to use
libtiff-dev instead of libtiff4-dev now even if your application uses
other libraries that also use libtiff, but I'm not 100% sure about
this because I have not yet learned all the subtitles of versioned
symbols. (This situation will soon be corrected.)
I'm sure someone will correct this if I am wrong.
--
Jay Berkenbilt <ejb@ql.org>
http://www.ql.org/q/
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Nico Golde 2004-08-05, 5:56 pm |
| Hello Justin,
* Justin Pryzby <justinpryzby@users.sourceforge.net> [2004-08-05 11:22]:
> Hi again, found your problem.
>
> util.c:fsize() has static char result[20];, which it returns. It appearsthat
> this used to be dynamically allocated - note the indentation.
>
> gtksee.c:file_selected_internal calls fsize() and saves the result to
> gchar *text. Then it sprintf's it, and calls g_free(text);
>
> It should suffice to remove that call to g_free(text) (line 332 in the
> upstream source).
thanks very much for your time and you engagement, i think the new
gtksee package will be up in the next days.
regards nico
--
Nico Golde - 310777820@ICQ
nico@ngolde.de | nion@gmx.net | http://www.ngolde.de
GPG: FF46 E565 5CC1 E2E5 3F69 C739 1D87 E549 7364 7CFF
Is there life after /sbin/halt -p?
| |
| Sebastien Bacher 2004-08-05, 5:56 pm |
| Le jeudi 05 ao=FBt 2004 =E0 11:32 +0200, Nico Golde a =E9crit :
>=20
> thanks very much for your time and you engagement, i think the new
> gtksee package will be up in the next days.
This is getting long for a such small package, in the next days will
probably mean that's one of the last package to be updated. I don't see
a point to delay the transition because of it. I can sponsor your
package today if you're ok with that.
Cheers,
Sebastien Bacher
| |
| Jérôme Marant 2004-08-05, 5:56 pm |
| Quoting Steve Langasek <vorlon@debian.org>:
> Depending on the order in which the libraries are loaded, having one lib
> with versioned symbols and one without loaded into memory can still be a
> problem.
>
> But I don't think that's much of an issue when looking at the build
> dependencies, here. I seem to recall, though, that pure-virtual
> build-deps (as libtiff-dev is) are usually considered bad form?
It works fine when a virtual package is provided by one only
real package, which is the case with libtiff-dev.
--
Jérôme Marant
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
|
|
|
|
|