On Tue, 05 Aug 2003 07:32:57 +0200, Matthias Urlichs wrote:
> Hi, Peter Mathiasson wrote:
>
>> "[...] distcc sends the complete preprocessed source code across the
>> network for each job."
>
> Hmm, OK, but that would just speedup the actual compilation. Granted,
> that's the largest chunk, but
Richard Braakman wrote:
> On Mon, Aug 04, 2003 at 10:08:04AM +0200, Jérôme Marant wrote:
> > > Hence the need for policy to dictate to the maintainer not to allow the
> > > package to be removed before all other packages have transitioned. It
> > > usually doesn't take much more work as long as the
> On Tue, Aug 05, 2003 at 01:07:42AM +0400, Nikita V. Youshchenko wrote:
> > So buidd + distcc on a slow m68k/arm/whatever, and distccd on a fast
> > P4 or Athlon, or even on several of those. This is expected to reduce
> > the compile time to almost the same as it is on x86 :).
>
> I'm not sure t
On Tue, Aug 05, 2003 at 01:07:42AM +0400, Nikita V. Youshchenko wrote:
> So buidd + distcc on a slow m68k/arm/whatever, and distccd on a fast P4 or
> Athlon, or even on several of those. This is expected to reduce the compile
> time to almost the same as it is on x86 :).
I'm not sure that's true;
Hi, Peter Mathiasson wrote:
> "[...] distcc sends the complete preprocessed source code across
> the network for each job."
Hmm, OK, but that would just speedup the actual compilation. Granted,
that's the largest chunk, but cpp/asm/ld could do with a speed-up too.
Anyway, thanks for the pointer
At Mon, 04 Aug 2003 15:54:56 +0200,
Matthias Urlichs wrote:
>
> Hi, Nikita V. Youshchenko wrote:
>
> >> Guess how many hours it takes for the m68k buildd to rebuild
> >> kdegraphics. OVER 38 HOURS!
> >
> > By the way, isn't it a good time to rise up a discussion about package
> > cross-compi
At Mon, 04 Aug 2003 15:54:56 +0200,
Matthias Urlichs wrote:
>
> Hi, Nikita V. Youshchenko wrote:
>
> >> Guess how many hours it takes for the m68k buildd to rebuild
> >> kdegraphics. OVER 38 HOURS!
> >
> > By the way, isn't it a good time to rise up a discussion about package
> > cross-compi
On Tue, Aug 05, 2003 at 01:07:42AM +0400, Nikita V. Youshchenko wrote:
> I'm not sure that current distcc in unstable can support such configuration,
> but it should be really easy to add this support. In fact, as far as I can
> remember, it is mentioned in distcc documentation that machines that r
> > If you want to be productive, how about setting a buildd and trying to
> > crosscompile the distribution and then post statsistics of
> > failed/succeeded crosscompilings?
> This is a good idea. Maybe I will try after my vacation. Is
> documentation/hints abould how to do it available anywhe
On Sun, 2003-08-03 at 03:32, Chris Cheney wrote:
> Today I was reminded of something that causes apps not to migrate into
> sarge. When maintainers remove old libraries from the archive! Today
> for example libexif8 was removed by Christophe Barbe and replaced by
> libexif9. Guess what that doe
> On Mon, Aug 04, 2003 at 03:54:56PM +0200, Matthias Urlichs wrote:
>> Surprise, I was thinking about the same thing, yesterday. Basic idea:
>> mount the slow system's build chroot from the fast server, replace
>> gcc/g++/ld with scripts that call the server's version remotely. The
>> biggest pro
On 04-Aug-03, 12:42 (CDT), Adam Heath <[EMAIL PROTECTED]> wrote:
> On Mon, 4 Aug 2003, Richard Braakman wrote:
> > Uh, no. Changing the binary package name the way we've always
> > handled soname changes, except with a small number of very popular
> > libraries. It's a lot less work, and it does
On Mon, Aug 04, 2003 at 12:42:27PM -0500, Adam Heath wrote:
> And of the users? Please read the social contract.
I read it every day, just before bedtime.
Richard Braakman
On Mon, 4 Aug 2003, Richard Braakman wrote:
> On Mon, Aug 04, 2003 at 10:53:00AM -0500, Adam Heath wrote:
> > In this case, libexif8 -> libexif9, this is a major soname bump, so should
> > have required a new source package. The maintainer was probably derelict in
> > this case.
>
> Uh, no. Chan
On Mon, Aug 04, 2003 at 08:07:56PM +0300, Richard Braakman wrote:
> On Mon, Aug 04, 2003 at 10:53:00AM -0500, Adam Heath wrote:
> > In this case, libexif8 -> libexif9, this is a major soname bump, so should
> > have required a new source package. The maintainer was probably derelict in
> > this ca
On Mon, Aug 04, 2003 at 10:53:00AM -0500, Adam Heath wrote:
> In this case, libexif8 -> libexif9, this is a major soname bump, so should
> have required a new source package. The maintainer was probably derelict in
> this case.
Uh, no. Changing the binary package name the way we've always
handle
On Mon, Aug 04, 2003 at 10:53:00AM -0500, Adam Heath wrote:
> In this case, libexif8 -> libexif9, this is a major soname bump, so should
> have required a new source package. The maintainer was probably derelict in
> this case.
The source package is libexif independently of the soname.
Are you su
Adam Heath wrote:
> Perhaps someone should write a script to detect these uninstallable issues,
> and notify the maintainers of the dependant packages when they occur.
Like [0]? (Not my work, but such a script certainly seems to exist.)
If done at all, probably a two (or something) day grace period
Chris Cheney <[EMAIL PROTECTED]> writes:
> On Sun, Aug 03, 2003 at 03:55:41PM -0400, David Z Maze wrote:
>> Chris Cheney <[EMAIL PROTECTED]> writes:
>>
>> > IMHO we need to make an addition to policy stating that an old lib can
>> > not be removed from the archive until no other packages still de
On Sun, 3 Aug 2003, Chris Cheney wrote:
> Seriously, if we want to ever release sarge we are going to need to stop
> making libraries disappear, every time we rebuild something it takes
> another 10 days for it to migrate into testing and everything that
> depends on it is also pushed back another
On Sun, 3 Aug 2003, Eduard Bloch wrote:
> #include
> * LapTop006 [Sun, Aug 03 2003, 03:13:57PM]:
>
> > > IMHO we need to make an addition to policy stating that an old lib can
> > > not be removed from the archive until no other packages still depend on
> > > it.
> > How about old libraries can n
On Mon, Aug 04, 2003 at 03:54:56PM +0200, Matthias Urlichs wrote:
> Surprise, I was thinking about the same thing, yesterday. Basic idea:
> mount the slow system's build chroot from the fast server, replace
> gcc/g++/ld with scripts that call the server's version remotely. The
> biggest problem wil
On Mon, Aug 04, 2003 at 10:18:37AM +0200, J?r?me Marant wrote:
> Usually, you can use apt-cache showpkg libexif8 and send a message to
> every maintainer whose package depends on it, asking to rebuild against
> the new libexif9. When everyone has rebuilt against the new lib,
> then you can ask for
Hi, Nikita V. Youshchenko wrote:
>> Guess how many hours it takes for the m68k buildd to rebuild
>> kdegraphics. OVER 38 HOURS!
>
> By the way, isn't it a good time to rise up a discussion about package
> cross-compiling infrastructure?
Surprise, I was thinking about the same thing, yesterda
> On Mon, Aug 04, 2003 at 04:28:49PM +0400, Nikita V. Youshchenko wrote:
> > > Guess how many hours it takes for the m68k
> > > buildd to rebuild kdegraphics. OVER 38 HOURS!
> >
> > By the way, isn't it a good time to rise up a discussion about package
> > cross-compiling infrastructure?
>
> I
On Mon, Aug 04, 2003 at 04:28:49PM +0400, Nikita V. Youshchenko wrote:
> Chris Cheney wrote:
> > Guess how many hours it takes for the m68k buildd to rebuild
> > kdegraphics. OVER 38 HOURS!
>
> By the way, isn't it a good time to rise up a discussion about package
> cross-compiling infrastruct
On Mon, Aug 04, 2003 at 04:28:49PM +0400, Nikita V. Youshchenko wrote:
> > Guess how many hours it takes for the m68k
> > buildd to rebuild kdegraphics. OVER 38 HOURS!
> By the way, isn't it a good time to rise up a discussion about package
> cross-compiling infrastructure?
Isn't it good ide
> Today I was reminded of something that causes apps not to migrate into
> sarge. When maintainers remove old libraries from the archive! Today
> for example libexif8 was removed by Christophe Barbe and replaced by
> libexif9. Guess what that does... any package which depends on libexif8
> now b
> Guess how many hours it takes for the m68k
> buildd to rebuild kdegraphics. OVER 38 HOURS!
By the way, isn't it a good time to rise up a discussion about package
cross-compiling infrastructure?
On Mon, Aug 04, 2003 at 08:33:31AM +0200, Thomas Viehmann wrote:
> Steve Langasek wrote:
> > I think a better approach would simply be to regard application
> > uninstallable-in-sid bugs as non-RC for testing purposes. Since the
> > testing scripts will already refuse to process new libs that rend
On Mon, Aug 04, 2003 at 12:49:51PM +0300, Richard Braakman wrote:
> Common sense says otherwise :) You see, before we had katie and the
> testing scripts, such removal of orphan libraries was done manually.
> ("orphan" because they no longer had a source package that built them).
> Our experience
On Mon, Aug 04, 2003 at 10:08:04AM +0200, Jérôme Marant wrote:
> > Hence the need for policy to dictate to the maintainer not to allow the
> > package to be removed before all other packages have transitioned. It
> > usually doesn't take much more work as long as the maintainer is even
> > aware of
Quoting christophe barbe <[EMAIL PROTECTED]>:
> Ok, sorry for being rude in my previous mail.
>
> I understand the general problem that you are facing with KDE and
> will try in the future to announce upcomming soname changes.
>
> Concerning the removal, I don't really see the point of not remo
Quoting Chris Cheney <[EMAIL PROTECTED]>:
> > Old libraries are removed since only one version can exist in the same
> > distro branch to the same time. If the library maintainer decided not to
> > fork the source package but change the binary package name inside of
> > existing three then he does
Steve Langasek wrote:
> I think a better approach would simply be to regard application
> uninstallable-in-sid bugs as non-RC for testing purposes. Since the
> testing scripts will already refuse to process new libs that render
> applications uninstallable, the only impact here will be that certai
On Mon, Aug 04, 2003 at 01:37:43AM +0200, Thomas Viehmann wrote:
> Chris Cheney wrote:
> ...
> > for example libexif8 was removed by Christophe Barbe and replaced by
> > libexif9. Guess what that does... any package which depends on libexif8
> ...
> > not be removed from the archive until no other
Chris Cheney wrote:
...
> for example libexif8 was removed by Christophe Barbe and replaced by
> libexif9. Guess what that does... any package which depends on libexif8
...
> not be removed from the archive until no other packages still depend on
> it.
Well, if it's uninstallable for a couple of
Ok, sorry for being rude in my previous mail.
I understand the general problem that you are facing with KDE and
will try in the future to announce upcomming soname changes.
Concerning the removal, I don't really see the point of not removing
older libraries from unstable. Most of the time, rebui
On Sun, Aug 03, 2003 at 05:31:37PM -0400, christophe barbe wrote:
> You are kidding right?
>
> I have not removed an old library, I have uploaded a newer upstream with
> a different soname. That's the way it works, a new library is uploaded,
> then packages using it are rebuilt and when they are a
You are kidding right?
I have not removed an old library, I have uploaded a newer upstream with
a different soname. That's the way it works, a new library is uploaded,
then packages using it are rebuilt and when they are all ready they
migrate in testing.
As the gphoto2 maintainer, I don't remem
On Sun, Aug 03, 2003 at 03:55:41PM -0400, David Z Maze wrote:
> Chris Cheney <[EMAIL PROTECTED]> writes:
>
> > IMHO we need to make an addition to policy stating that an old lib can
> > not be removed from the archive until no other packages still depend on
> > it.
>
> So say I maintain foo. The
Chris Cheney <[EMAIL PROTECTED]> writes:
> IMHO we need to make an addition to policy stating that an old lib can
> not be removed from the archive until no other packages still depend on
> it.
So say I maintain foo. The source package produces two binary
packages, foo and libfoo1. Now, there's
On Sun, Aug 03, 2003 at 08:55:48AM +0200, Eduard Bloch wrote:
> #include
> * LapTop006 [Sun, Aug 03 2003, 03:13:57PM]:
>
> > > IMHO we need to make an addition to policy stating that an old lib can
> > > not be removed from the archive until no other packages still depend on
> > > it.
> > How abo
#include
* LapTop006 [Sun, Aug 03 2003, 03:13:57PM]:
> > IMHO we need to make an addition to policy stating that an old lib can
> > not be removed from the archive until no other packages still depend on
> > it.
> How about old libraries can not be removed until either no packages
> depend on it
On Sat, Aug 02, 2003 at 09:32:37PM -0500, Chris Cheney arranged a set of bits
into the following:
> Today I was reminded of something that causes apps not to migrate into
> sarge. When maintainers remove old libraries from the archive! Today
> for example libexif8 was removed by Christophe Barbe
Today I was reminded of something that causes apps not to migrate into
sarge. When maintainers remove old libraries from the archive! Today
for example libexif8 was removed by Christophe Barbe and replaced by
libexif9. Guess what that does... any package which depends on libexif8
now becomes...
46 matches
Mail list logo
