On So, 07 Jun 2009, Steve Langasek wrote:
> this occuring, but it's still a legitimate case (from dpkg's POV) where the
> package's deps will not be satisfied when 'postrm remove' is called.
Ah ok thanks.
Anyway I have added code to protect this problem and next upload of
tex-common will fix that
On Sun, Jun 07, 2009 at 11:36:25PM +0200, Norbert Preining wrote:
> On So, 07 Jun 2009, Josselin Mouette wrote:
> > Le vendredi 05 juin 2009 à 21:15 +0200, Frank Küster a écrit :
> > > texlive-base's postrm, upon REMOVE, uses a command from tex-common, on
> > > which it already DEPENDS. This is all
On So, 07 Jun 2009, Josselin Mouette wrote:
> Le vendredi 05 juin 2009 à 21:15 +0200, Frank Küster a écrit :
> > texlive-base's postrm, upon REMOVE, uses a command from tex-common, on
> > which it already DEPENDS. This is allowed by policy.
>
> I’m not sure about the policy, but I’m certain that w
Le vendredi 05 juin 2009 à 21:15 +0200, Frank Küster a écrit :
> texlive-base's postrm, upon REMOVE, uses a command from tex-common, on
> which it already DEPENDS. This is allowed by policy.
I’m not sure about the policy, but I’m certain that with the current
dpkg version this will fail miserably
Hi guys,
let's calm down, its now worth discussing this even further. Policy is
buggy, we try to work around it.
> We'll have to make an upload of texlive-2007.
First we need a fixed tex-common that creates "proper" (for buggy
policy) postrm code.
Then we can bump build-dep of texlive to that v
Luk Claes wrote:
> Frank Küster wrote:
>> Luk Claes wrote:
>>
>>> Norbert Preining wrote:
On Do, 04 Jun 2009, Luk Claes wrote:
> Except for arguing, mixing (non?) bugs and resisting to upload an easy
> workaround might have made things worse btw...
And that easy workaround wou
Frank Küster wrote:
> retitle 530832 maintainer scripts created by tex-common may not assume
> tex-common to be present in "postrm remove"
> thanks
>
> ia64, I assume that you have moved the broken remains of texlive-base
> away manually?
He's called Lamont btw... oh right, that's the bugsubmitt
Frank Küster wrote:
> Luk Claes wrote:
>
>> Norbert Preining wrote:
>>> On Do, 04 Jun 2009, Luk Claes wrote:
Except for arguing, mixing (non?) bugs and resisting to upload an easy
workaround might have made things worse btw...
>>> And that easy workaround would be???
>> To only conditio
retitle 530832 maintainer scripts created by tex-common may not assume
tex-common to be present in "postrm remove"
thanks
ia64, I assume that you have moved the broken remains of texlive-base
away manually?
Agustin Martin wrote:
> Frank, your package honours current Debian policy about that, b
Luk Claes wrote:
> Norbert Preining wrote:
>> On Do, 04 Jun 2009, Luk Claes wrote:
>>> Except for arguing, mixing (non?) bugs and resisting to upload an easy
>>> workaround might have made things worse btw...
>>
>> And that easy workaround would be???
>
> To only conditionaly use a command that
[Resending, seems to be delivery problems, sorry if finally gets duplicated]
On Thu, Jun 04, 2009 at 09:34:40PM +0200, Frank Küster wrote:
> Luk Claes wrote:
>
> > Frank Küster wrote:
> >> Luk Claes wrote:
> >>
> >>> Fine, though taking the trouble to talk to the porters might still be
> >>> w
On Fri, 05 Jun 2009, Luk Claes wrote:
> The thing is that it is not a bug in the buildd chroot or buildd
> setup, it's a porter issue...
I haven't really analyzed the bug (and only read this thread in the
most superficial manner imaginable), so what I said previously (and
say below) shouldn't be c
Don Armstrong wrote:
> On Thu, 04 Jun 2009, Manoj Srivastava wrote:
>> If it is not a bug in the package (in other words, no change made
>> in the package would fix the issue), I see no point in keeping it
>> open. It would be nice, however, is a psuedo-package were created
>> for the buildds (
On Thu, 04 Jun 2009, Manoj Srivastava wrote:
> If it is not a bug in the package (in other words, no change made
> in the package would fix the issue), I see no point in keeping it
> open. It would be nice, however, is a psuedo-package were created
> for the buildds (or one per buildd, though t
Norbert Preining wrote:
> On Do, 04 Jun 2009, Luk Claes wrote:
>> Except for arguing, mixing (non?) bugs and resisting to upload an easy
>> workaround might have made things worse btw...
>
> And that easy workaround would be???
To only conditionaly use a command that seems to not always be availa
Luk Claes wrote:
> Frank Küster wrote:
>> Luk Claes wrote:
>>
>>> Fine, though taking the trouble to talk to the porters might still be
>>> worthwile.
>>
>> Yes, but definitely not after I've spend hours of my little Debian
>> arguing about non-bugs with people who don't read what I say and in
On Do, 04 Jun 2009, Luk Claes wrote:
> Except for arguing, mixing (non?) bugs and resisting to upload an easy
> workaround might have made things worse btw...
And that easy workaround would be???
Best wishes
Norbert
---
Frank Küster wrote:
> Frank Küster wrote:
>
>> Luk Claes wrote:
>>
>>> Fine, though taking the trouble to talk to the porters might still be
>>> worthwile.
>> Yes, but definitely not after I've spend hours of my little Debian
>
Frank Küster wrote:
> Luk Claes wrote:
>
>> Fine, though taking the trouble to talk to the porters might still be
>> worthwile.
>
> Yes, but definitely not after I've spend hours of my little Debian
> arguing about non-bugs with people who don't read what I say and instead
> insist on blaming ou
Frank Küster wrote:
> Luk Claes wrote:
>
>> Fine, though taking the trouble to talk to the porters might still be
>> worthwile.
>
> Yes, but definitely not after I've spend hours of my little Debian
^time
> arguing about non-bu
Philipp Kern wrote:
> On 2009-06-04, Frank Küster wrote:
>> And what would be the criterion for "solved"? After an analysis of
>> N build logs of random packages on that buildd show no segfaults any
>> more? I am not going to do that.
>>
>> It's not a bug in my package; I am not going to take
Luk Claes wrote:
> Fine, though taking the trouble to talk to the porters might still be
> worthwile.
Yes, but definitely not after I've spend hours of my little Debian
arguing about non-bugs with people who don't read what I say and instead
insist on blaming our packages without explaining why.
Frank Küster wrote:
> Luk Claes wrote:
>
>>> That doesn't solve my problem: Should I
>>> - make sure that the porters, buildd admins etc. are aware of the
>>> problem and simply close the bug?
>> You might want to downgrade the bug and only close it when it is realy
>> solved?
>
> And what wo
On 2009-06-04, Frank Küster wrote:
> And what would be the criterion for "solved"? After an analysis of
> N build logs of random packages on that buildd show no segfaults any
> more? I am not going to do that.
>
> It's not a bug in my package; I am not going to take responsibility for
> it.
Th
Luk Claes wrote:
>> That doesn't solve my problem: Should I
>
>> - make sure that the porters, buildd admins etc. are aware of the
>> problem and simply close the bug?
>
> You might want to downgrade the bug and only close it when it is realy
> solved?
And what would be the criterion for "sol
On Wed, Jun 03 2009, Luk Claes wrote:
> Frank Küster wrote:
>> Luk Claes wrote:
>>
And what should one do with a bug like this? At the moment it's quite
irrelevant whether one of our packages has a bogus RC bug. But what if
that happens when I'm hoping for a transition to testin
Frank Küster wrote:
> Luk Claes wrote:
>
>>> And what should one do with a bug like this? At the moment it's quite
>>> irrelevant whether one of our packages has a bogus RC bug. But what if
>>> that happens when I'm hoping for a transition to testing?
>> Are you now talking about the failure on
Luk Claes wrote:
>> And what should one do with a bug like this? At the moment it's quite
>> irrelevant whether one of our packages has a bogus RC bug. But what if
>> that happens when I'm hoping for a transition to testing?
>
> Are you now talking about the failure on hppa or the one on ia64 (
Frank Küster wrote:
> [a failed build was wrongly assigned as a RC bug of texlive-base, and
> since the reason was a problem on the buildd, I assigned it to
> buildd.debian.org]
>
> Luk Claes wrote:
>
>> buildd.d.o is not the place to reassign bugs for particular buildds to.
>> If it's just for
[a failed build was wrongly assigned as a RC bug of texlive-base, and
since the reason was a problem on the buildd, I assigned it to
buildd.debian.org]
Luk Claes wrote:
> buildd.d.o is not the place to reassign bugs for particular buildds to.
> If it's just for particular buildds, you'd better
30 matches
Mail list logo
