Update-excuses: Makes N non-depending packages uninstallable on ...

2004-08-30 Thread Frank Küster
Hi,

I'm wondering how to interpret, especially the last part.

http://bjorn.haxx.se/debian/testing.pl?package=tetex-bin

First it says:

* Updating tetex-bin makes 3 depending packages uninstallable on alpha: 
jbibtex-bin, jmpost, ptex-bin

This seems to be bogus, because ptex-bin (source package of the three)
has a versioned depends on tetex-bin that cannot be fullfilled with the
version in sarge. 

But then:

* Updating tetex-bin makes 35 non-depending packages uninstallable on
  alpha: acl2-infix, advi, cdcover, cjk-latex, dvidvi, dvifb, dvilib2,
  dvilib2-dev, dvilx, dvipdfm-cjk, dvipdfmx, dvipsk-ja, ipe, jtex-bin,
  latex2rtf, lgrind, libkpathsea-perl, lilypond, lprfax, multex-bin,
  musixtex, opustex, pdfjam, pmx, sgf2tex, sgmltexi, spawg, spawx11,
  tetex-bin, tex-guy, tex4ht, texmacs, therion, xdvik-ja, xgdvi

What does that mean? For the first, acl2-infix, I cannot find any
connection to tetex-bin; for cdcover, e.g., there is one:

Depends: libc6 (>= 2.3.2.ds1-4), libgcc1 (>= 1:3.3.3-1), libstdc++5 (>= 
1:3.3.3-1), tetex-bin, tetex-base, tetex-extra

But how can that cause a problem? According to
http://buildd.debian.org/build.php?arch=&pkg=tetex-bin
tetex-bin has been built "maybe-successful"ly on all arches.

TIA, Frank
-- 
Frank Küster, Biozentrum der Univ. Basel
Abt. Biophysikalische Chemie



Re: Update-excuses: Makes N non-depending packages uninstallable on ...

2004-08-30 Thread Adeodato Simó
* Frank Küster [Mon, 30 Aug 2004 12:55:56 +0200]:

> * Updating tetex-bin makes 3 depending packages uninstallable on
> alpha: jbibtex-bin, jmpost, ptex-bin

  I think you need to ask -release for a hint of tetex-bin/2.0.2-20 and
  ptex-bin/3.1.3+0.04a-3.

> This seems to be bogus, because ptex-bin (source package of the three)
> has a versioned depends on tetex-bin that cannot be fullfilled with the
> version in sarge. 

  so that's the message: "if tetex-bin -20 gets installed in testing,
  I'll have to remove ptex-bin, and I'm not going to do that". herein
  the hint.

> * Updating tetex-bin makes 35 non-depending packages uninstallable on
>   alpha: acl2-infix, advi, cdcover, cjk-latex, dvidvi, dvifb, dvilib2,
>   dvilib2-dev, dvilx, dvipdfm-cjk, dvipdfmx, dvipsk-ja, ipe, jtex-bin,
>   latex2rtf, lgrind, libkpathsea-perl, lilypond, lprfax, multex-bin,
>   musixtex, opustex, pdfjam, pmx, sgf2tex, sgmltexi, spawg, spawx11,
>   tetex-bin, tex-guy, tex4ht, texmacs, therion, xdvik-ja, xgdvi

  I think this will solve too with the hint.

> But how can that cause a problem? According to
> http://buildd.debian.org/build.php?arch=&pkg=tetex-bin
> tetex-bin has been built "maybe-successful"ly on all arches.

  it's not the case, but as you may know, "maybe-successful" does not
  mean the package is in the archive for that arch. you want "Installed"
  in .

> TIA, Frank

  hth,

-- 
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
 
Man is certainly stark mad; he cannot make a flea, yet he makes gods by the
dozens.
-- Michel de Montaigne



Re: Update-excuses: Makes N non-depending packages uninstallable on ...

2004-08-30 Thread Andreas Metzler
On 2004-08-30 Frank Küster <[EMAIL PROTECTED]> wrote:
> I'm wondering how to interpret, especially the last part.

> http://bjorn.haxx.se/debian/testing.pl?package=tetex-bin

> First it says:

> * Updating tetex-bin makes 3 depending packages uninstallable on alpha: 
> jbibtex-bin, jmpost, ptex-bin

> This seems to be bogus, because ptex-bin (source package of the three)
> has a versioned depends on tetex-bin that cannot be fullfilled with the
> version in sarge. 

Britney tries one package at a time, unless told otherwise (with a
"hint"). It does not try to update *both* ptex-bin and tetex-bin
together, and the version of ptex-bin in sarge does not "depends on
tetex-bin that cannot be fullfilled with the version in sarge".

> But then:

> * Updating tetex-bin makes 35 non-depending packages uninstallable on
>   alpha: acl2-infix, advi, cdcover, cjk-latex, dvidvi, dvifb, dvilib2,
[...]
> What does that mean? For the first, acl2-infix, I cannot find any
> connection to tetex-bin; for cdcover, e.g., there is one:

> Depends: libc6 (>= 2.3.2.ds1-4), libgcc1 (>= 1:3.3.3-1), libstdc++5 (>= 
> 1:3.3.3-1), tetex-bin, tetex-base, tetex-extra
[...]

tetex-bin in sid "Conflicts: tetex-base (<= 2.0.2b-2)", therefore
upgrading tetex-bin on its own makes tetex-bin itself uninstallable,
therefore everything related would be, too.

We had already talked about this on IRC today, because Steve Langasek
had already hinted tetex-base and tetex-bin together but it had not
worked out, Steve traced it to:

| The following arch: all packages are broken by trying to update
| tetex: alcovebook-sgml docbook-utils jadetex sgml2x
| translate-docformat
   cu andreas
-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"



Re: Update-excuses: Makes N non-depending packages uninstallable on ...

2004-08-30 Thread Frank Küster
Adeodato Simó <[EMAIL PROTECTED]> schrieb:

> * Frank Küster [Mon, 30 Aug 2004 12:55:56 +0200]:
>
>> * Updating tetex-bin makes 3 depending packages uninstallable on
>> alpha: jbibtex-bin, jmpost, ptex-bin
>
>   I think you need to ask -release for a hint of tetex-bin/2.0.2-20 and
>   ptex-bin/3.1.3+0.04a-3.

Thank you, I'll do that.

>> But how can that cause a problem? According to
>> http://buildd.debian.org/build.php?arch=&pkg=tetex-bin
>> tetex-bin has been built "maybe-successful"ly on all arches.
>
>   it's not the case, but as you may know, "maybe-successful" does not
>   mean the package is in the archive for that arch. you want "Installed"
>   in .

Thanks very much, I didn't know that. By the way, the output is strange
for tetex-base which is Architecture: all:

http://people.debian.org/~igloo/status.php

Which says that it is installed on amd64, with 

,
| amd64
| 
| main/tetex-base_2.0.2b-3: Installed by Frederik Schüler <[EMAIL PROTECTED]> 
[:]
|   Previous state was lost on 2004-08-26.16:23:30
`

Besides that amd64 formally is not part of Debian yet, what does that
indicate? 

Regards, Frank
-- 
Frank Küster, Biozentrum der Univ. Basel
Abt. Biophysikalische Chemie



I need sponsors contract

2004-08-30 Thread Giperez005
i am writing to you to find out if you have some samples of sponsorship so i could have an idea on how to send a sponsors contract and what it entails .


Re: Bug#268774: digikam depends on libtiff3g in testing, kdelibs4 3.3 in unstable: t-p-u upload needed

2004-08-30 Thread Paul Telford
On Sat, 28 Aug 2004, Steve Langasek wrote:

> digikam has been removed from testing, because it depended on libexif9.
> The version of digikam in unstable will almost certainly depend on
> kdelibs4 3.3 once it's been successfully built on mipsel.  This means
> the version in unstable will almost certainly not make it into sarge
> because of KDE 3.3 not being ready in time.
>
> If you want digikam to be included in sarge, please upload it to
> testing-proposed-updates.


One of my packages just got removed from testing as you can see above.
Having never dealt with t-p-u before, I want to make sure I get it right.
The current version in unstable is 0.6.2-3.  I have built 0.6.2-4 for
sarge (simply bumped the version #) and 0.6.2-3sarge1 for t-p-u.  I plan
to upload the unstable version first so that sarge < unstable.  Does that
sound correct?  i don't beleieve any other changes are necessary.

Thanks,



 Paul.





--
Paul Telford | 1024D/431B38BA | [EMAIL PROTECTED] | [EMAIL PROTECTED]
   C903 0E85 9AF5 1B80 6A5F  F169 D7E9 4363 431B 38BA




Re: Bug#268774: digikam depends on libtiff3g in testing, kdelibs4 3.3 in unstable: t-p-u upload needed

2004-08-30 Thread Paul Telford
On Mon, 30 Aug 2004, Paul Telford wrote:

> One of my packages just got removed from testing as you can see above.
> Having never dealt with t-p-u before, I want to make sure I get it right.
> The current version in unstable is 0.6.2-3.  I have built 0.6.2-4 for
> sarge
  ^  oops... that should read "unstable" of course.



Thanks,



--
Paul Telford | 1024D/431B38BA | [EMAIL PROTECTED] | [EMAIL PROTECTED]
   C903 0E85 9AF5 1B80 6A5F  F169 D7E9 4363 431B 38BA



richard

2004-08-30 Thread richard . autoresponder
This is an AUTOMATIC RESPONSE.
Thank you for your mail. 
If you mail requires a reply I will endeavor to reply within 24 hours. 
If your email requires an urgent reply, please do not hesitate to contact me. 
 Office Hours 9.00 am - 6.00 pm Monday to Friday.
 Office phone number is +66 76 290 214
 Office fax number is +66 76 290 217
 Mobile number is +66 (0) 95871001 
 Yahoo ID richard_patrick01
 www.qvcphuket.com
 www.qvcsamui.com
Telephone number for my assistant Koy is +66 76 341 420
 Main switch board is Tel +66 76 341 474.
Thank you.
Richard 



Re: Bug#268774: digikam depends on libtiff3g in testing, kdelibs4 3.3 in unstable: t-p-u upload needed

2004-08-30 Thread Andreas Metzler
On Mon, Aug 30, 2004 at 09:06:01AM -0700, Paul Telford wrote:
> On Sat, 28 Aug 2004, Steve Langasek wrote:
> > digikam has been removed from testing, because it depended on libexif9.
> > The version of digikam in unstable will almost certainly depend on
> > kdelibs4 3.3 once it's been successfully built on mipsel.  This means
> > the version in unstable will almost certainly not make it into sarge
> > because of KDE 3.3 not being ready in time.

> > If you want digikam to be included in sarge, please upload it to
> > testing-proposed-updates.
[...]
> The current version in unstable is 0.6.2-3.  I have built 0.6.2-4 for
> sarge (simply bumped the version #) and 0.6.2-3sarge1 for t-p-u.  I plan
> to upload the unstable version first so that sarge < unstable.

Why do you need to upload to unstable at all? Is there something wrong
with the version in unstable? Can't you simply upload 0.6.2-3
unchanged (except for debian/changelog) as 0.6.2-2sarge1 to testing?
 cu andreas



Re: Bug#268774: digikam depends on libtiff3g in testing, kdelibs4 3.3 in unstable: t-p-u upload needed

2004-08-30 Thread Paul Telford
On Mon, 30 Aug 2004, Andreas Metzler wrote:

> Why do you need to upload to unstable at all? Is there something wrong
> with the version in unstable? Can't you simply upload 0.6.2-3
> unchanged (except for debian/changelog) as 0.6.2-2sarge1 to testing?


Good point... I guess I wasn't sure that I could use an arbitrary low
version number.  Testing has no "memory" of 0.6.2-3 at this point I guess.

Thanks,



--
Paul Telford | 1024D/431B38BA | [EMAIL PROTECTED] | [EMAIL PROTECTED]
   C903 0E85 9AF5 1B80 6A5F  F169 D7E9 4363 431B 38BA



Re: Bug#268774: digikam depends on libtiff3g in testing, kdelibs4 3.3 in unstable: t-p-u upload needed

2004-08-30 Thread Andreas Metzler
On Mon, Aug 30, 2004 at 09:45:26AM -0700, Paul Telford wrote:
> On Mon, 30 Aug 2004, Andreas Metzler wrote:
> > Why do you need to upload to unstable at all? Is there something wrong
> > with the version in unstable? Can't you simply upload 0.6.2-3
> > unchanged (except for debian/changelog) as 0.6.2-2sarge1 to testing?
 
> Good point... I guess I wasn't sure that I could use an arbitrary low
> version number.  Testing has no "memory" of 0.6.2-3 at this point I guess.

Afaiu 0.6.2-3 was never part of sarge.
   cu andreas



Re: How to get rid of an epoch?

2004-08-30 Thread Ken Bloom
On Fri, 27 Aug 2004 22:38:15 +0200, Amaya wrote:

> I'm doing a little houskeeping before sarge releases.
> Then I stumble upon this:
> 
>  Rejected: jail_1.6-2_i386.deb: old version (1:1.6-1) in stable >= new
>version (1.6-2) targeted at unstable.
>  Rejected: jail_1.6-2_i386.deb: old version (1:1.6-1) in unstable >= new
>version (1.6-2) targeted at unstable.
>  Rejected: jail_1.6-2_i386.deb: old version (1:1.6-1) in testing >= new
>version (1.6-2) targeted at unstable.
> 
> For some reason (the changelog doesn't help much), the previous
> maintainer used an epoch at some point and I would like to get rid of
> it. What's the best way to do it?

One cannot remove an epoch, and you shouldn't consider it "cleaning up" to
remove one. Adding an epoch is a tool that is frequently used to clean up
screwy version numbers, because adding/incrementing an epoch always
overrides any other part of the version number.

-- 
I usually have a GPG digital signature included as an attachment.
See http://www.gnupg.org/ for info about these digital signatures.
My key was last signed 08/18/2004. If you use GPG *please* see me about 
signing the key. * My computer can't give you viruses by email. ***




Re: How to get rid of an epoch?

2004-08-30 Thread Ken Bloom
On Fri, 27 Aug 2004 22:38:15 +0200, Amaya wrote:

> I'm doing a little houskeeping before sarge releases.
> Then I stumble upon this:
> 
>  Rejected: jail_1.6-2_i386.deb: old version (1:1.6-1) in stable >= new
>version (1.6-2) targeted at unstable.
>  Rejected: jail_1.6-2_i386.deb: old version (1:1.6-1) in unstable >= new
>version (1.6-2) targeted at unstable.
>  Rejected: jail_1.6-2_i386.deb: old version (1:1.6-1) in testing >= new
>version (1.6-2) targeted at unstable.
> 
> For some reason (the changelog doesn't help much), the previous
> maintainer used an epoch at some point and I would like to get rid of
> it. What's the best way to do it?

One cannot remove an epoch, and you shouldn't consider it "cleaning up" to
remove one. Adding an epoch is a tool that is frequently used to clean up
screwy version numbers, because adding/incrementing an epoch always
overrides any other part of the version number.

-- 
I usually have a GPG digital signature included as an attachment.
See http://www.gnupg.org/ for info about these digital signatures.
My key was last signed 08/18/2004. If you use GPG *please* see me about 
signing the key. * My computer can't give you viruses by email. ***



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]