On Wed, 1 Nov 2006 23:56:17 +0100, Christian T Steigies [EMAIL PROTECTED]
said:
On Tue, Oct 31, 2006 at 06:01:57PM -0800, Steve Langasek wrote:
On Mon, Oct 23, 2006 at 01:09:13AM -0500, Manoj Srivastava wrote:
On Sun, 22 Oct 2006 00:52:59 +0200 (CEST), Michael Schmitz
[EMAIL PROTECTED]
On Tue, Oct 31, 2006 at 06:01:57PM -0800, Steve Langasek wrote:
On Mon, Oct 23, 2006 at 01:09:13AM -0500, Manoj Srivastava wrote:
On Sun, 22 Oct 2006 00:52:59 +0200 (CEST), Michael Schmitz [EMAIL
PROTECTED] said:
On Fri, Oct 20, 2006 at 02:05:37PM -0700, Steve Langasek wrote:
On
On Mon, Oct 23, 2006 at 01:09:13AM -0500, Manoj Srivastava wrote:
On Sun, 22 Oct 2006 00:52:59 +0200 (CEST), Michael Schmitz [EMAIL
PROTECTED] said:
On Fri, Oct 20, 2006 at 02:05:37PM -0700, Steve Langasek wrote:
On Fri, Oct 20, 2006 at 10:58:25PM +0200, Bill Allombert wrote:
IIRC,
This was fixed in 2.6.17.
First I've ever heard about it. The kernel cross-builds just fine.
kernel-package might hiccup, though.
Do you have examples of such hiccups?
No. Please note the 'might' above :-).
I do not use kernel-package. No offense meant, but I never got my head
Roman Zippel [EMAIL PROTECTED] writes:
Hi,
On Sat, 21 Oct 2006, Anthony Towns wrote:
On Wed, Oct 18, 2006 at 06:11:38PM +0200, Geert Uytterhoeven wrote:
Assumed m68k would be able to kill (most of) the backlog in time, what
would
prevent m68k from becoming releasable?
- It didn't
On Sun, 22 Oct 2006 00:52:59 +0200 (CEST), Michael Schmitz [EMAIL PROTECTED]
said:
On Fri, Oct 20, 2006 at 02:05:37PM -0700, Steve Langasek wrote:
On Fri, Oct 20, 2006 at 10:58:25PM +0200, Bill Allombert wrote:
IIRC, the m68k kernels are already cross-compiled.
Yes, which has repeatedly
Hi,
On Sat, 21 Oct 2006, Anthony Towns wrote:
On Wed, Oct 18, 2006 at 06:11:38PM +0200, Geert Uytterhoeven wrote:
Assumed m68k would be able to kill (most of) the backlog in time, what would
prevent m68k from becoming releasable?
- It didn't sustain the `95%' rate during the last x
On Fri, Oct 20, 2006 at 02:05:37PM -0700, Steve Langasek wrote:
On Fri, Oct 20, 2006 at 10:58:25PM +0200, Bill Allombert wrote:
IIRC, the m68k kernels are already cross-compiled.
Yes, which has repeatedly caused problems due to assumptions in the kernel
packaging that host arch == build
Hi,
On Fri, 20 Oct 2006, Thomas Bushnell BSG wrote:
Roman Zippel [EMAIL PROTECTED] writes:
I do care about it. But I see no particular reason for urgency about
the particular bug, and obviously, the m68k team doesn't either.
Obviously?
They ignored it for a long time, and as far
Hi,
On Fri, 20 Oct 2006, Steve Langasek wrote:
The m68k porters have been firmly against cross-compiling in the past,
it's their call on whether this sort of approach is suitable.
FWIW, it's my understanding he intends to run aranym on these systems,
thereby making this native building
Is the stuff at http://ftp-master.debian.org/testing/update_out_code/
still current? It seems to be lacking stuff, according to the README.
Err, it's a symlink to the code that's actually being used. What's missing?
The contents of the testing/ subdirectory in there, according to the
README
The question is to know if it is ok to use emulators to build and upload
packages?
The m68k porters have been firmly against cross-compiling in the past,
it's their call on whether this sort of approach is suitable.
Well, using an emulator as a buildd is generally not called
On Fri, Oct 20, 2006 at 02:05:37PM -0700, Steve Langasek wrote:
On Fri, Oct 20, 2006 at 10:58:25PM +0200, Bill Allombert wrote:
IIRC, the m68k kernels are already cross-compiled.
Yes, which has repeatedly caused problems due to assumptions in the kernel
packaging that host arch == build
[-68k readded]
On Thu, Oct 19, 2006 at 06:04:49PM +0200, Aurelien Jarno wrote:
Bill Allombert a ?crit :
My personnal plan is to set up one or two fast amd64 octocore as a m68k
buildd.
That would lift most of the objection with the port.
The question is to know if it is ok to use emulators
On Wed, Oct 18, 2006 at 06:11:38PM +0200, Geert Uytterhoeven wrote:
Assumed m68k would be able to kill (most of) the backlog in time, what would
prevent m68k from becoming releasable?
- It didn't sustain the `95%' rate during the last x months?
x=3, yes.
The sustainability issue is
On Wed, Oct 18, 2006 at 09:45:04PM +0200, Roman Zippel wrote:
On Thu, 19 Oct 2006, Anthony Towns wrote:
The reason we keep all architectures in sync is so that you end
up running the same thing if you install Debian on any supported
architecture. Otherwise you'd install Debian on i386 and
On Thu, Oct 19, 2006 at 05:25:41PM +0200, Michael Schmitz wrote:
Is the stuff at http://ftp-master.debian.org/testing/update_out_code/
still current? It seems to be lacking stuff, according to the README.
Err, it's a symlink to the code that's actually being used. What's missing?
Cheers,
aj
On Sat, Oct 21, 2006 at 06:40:12AM +1000, Anthony Towns wrote:
[-68k readded]
On Thu, Oct 19, 2006 at 06:04:49PM +0200, Aurelien Jarno wrote:
Bill Allombert a ?crit :
My personnal plan is to set up one or two fast amd64 octocore as a m68k
buildd.
That would lift most of the objection
On Sat, Oct 21, 2006 at 06:40:12AM +1000, Anthony Towns wrote:
On Thu, Oct 19, 2006 at 06:04:49PM +0200, Aurelien Jarno wrote:
Bill Allombert a ?crit :
My personnal plan is to set up one or two fast amd64 octocore as a m68k
buildd.
That would lift most of the objection with the port.
On Fri, Oct 20, 2006 at 10:58:25PM +0200, Bill Allombert wrote:
IIRC, the m68k kernels are already cross-compiled.
Yes, which has repeatedly caused problems due to assumptions in the kernel
packaging that host arch == build arch...
--
Steve Langasek Give me a lever long
On Fri, Oct 20, 2006 at 02:02:10PM -0700, Steve Langasek wrote:
On Sat, Oct 21, 2006 at 06:40:12AM +1000, Anthony Towns wrote:
On Thu, Oct 19, 2006 at 06:04:49PM +0200, Aurelien Jarno wrote:
Bill Allombert a ?crit :
My personnal plan is to set up one or two fast amd64 octocore as a m68k
Roman Zippel [EMAIL PROTECTED] writes:
PS: 4 days and still no response to guile-1.6 patch...
Maybe you should ask the guile-1.6 maintainer? I'm not responsible
for the package.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Roman Zippel [EMAIL PROTECTED] writes:
Then m68k would be a suitable release candidate for etch+1.
As usual you're avoiding the issue. The answer is not _that_ simple.
Really? What are the great mysterious complexities in it?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
Roman Zippel [EMAIL PROTECTED] writes:
The point is that these release criteria have practically enforced a black
and white scheme - either you're with us or you're on your own.
Actually, Anthony Towns described about a half-dozen distinct
possibilities, and outlined the advantages and
Roman Zippel [EMAIL PROTECTED] writes:
Hmm and here I thought you would care about this package, the way you
constantly asked about its status...
I do care about it. But I see no particular reason for urgency about
the particular bug, and obviously, the m68k team doesn't either.
Thomas
--
On Fri, Oct 20, 2006 at 02:45:55PM -0700, Thomas Bushnell BSG wrote:
Roman Zippel [EMAIL PROTECTED] writes:
The point is that these release criteria have practically enforced a black
and white scheme - either you're with us or you're on your own.
Actually, Anthony Towns described about
On Thu, Oct 19, 2006 at 02:41:59PM -0400, Mark Duckworth wrote:
I have a Falcon/CT60 with EtherNAT (MII driver support for linux may or
may not work easily), several compaq P3 xeon servers that could run
aranym instances (all with very large 80+GB drives) and a M5484LITE
board that could run
Roman Zippel [EMAIL PROTECTED] writes:
I do care about it. But I see no particular reason for urgency about
the particular bug, and obviously, the m68k team doesn't either.
Obviously?
They ignored it for a long time, and as far as I know, haven't
requested the maintainer to treat it with
Hi,
On Sat, 21 Oct 2006, Anthony Towns wrote:
Well, that's what we want as well and if m68k could provide this, what's
the reason this couldn't be released as Debian?
It won't be Debian etch or Debian stable, if it's different to
etch/stable on other architectures.
That wasn't my
Hi,
On Fri, 20 Oct 2006, Thomas Bushnell BSG wrote:
PS: 4 days and still no response to guile-1.6 patch...
Maybe you should ask the guile-1.6 maintainer? I'm not responsible
for the package.
Hmm and here I thought you would care about this package, the way you
constantly asked about its
Hi,
On Fri, 20 Oct 2006, Thomas Bushnell BSG wrote:
Hmm and here I thought you would care about this package, the way you
constantly asked about its status...
I do care about it. But I see no particular reason for urgency about
the particular bug, and obviously, the m68k team doesn't
On Thu, Oct 19, 2006, Anthony Towns wrote:
The reason we keep all architectures in sync is so that you end
up running the same thing if you install Debian on any supported
architecture. Otherwise you'd install Debian on i386 and have the
latest features, but install Debian on alpha and have an
So, if someone could give me a brief intro as to how testing migration of
I really ought to have dropped the 'brief' there :-)
packages works, and what would be needed to modify britney, I'd welcome
it.
The idea, presumably, would be to have a separate britney instance just
for
arm 11:44:41
m68k 26:39:13
m68k is an order of a magnitude slower and that's not acceptable.
I do not doubt m68k is a lot slower. We'll need to find a way to more
intelligently schedule packages that require a lot of space or RAM to
build. The Falcon/CT60 could help a lot there, even
On Wed, Oct 18, 2006 at 03:43:03AM +0200, Roman Zippel wrote:
The point is that m68k gets kicked out _before_ any alternative has been
implemented.
Well, yeah, but it's not because we weren't given a fair chance. I'm not
happy about this any more than you are, but this doesn't help. Sorry.
On Wed, Oct 18, 2006 at 07:00:21PM +1000, Anthony Towns wrote:
On Wed, Oct 18, 2006 at 09:49:50AM +0200, Ingo Juergensmann wrote:
Oh well...
It doesn't meet the release criteria because of the toolchain problems, that
have now been solved.
No, it hasn't. You need to be reliably abouve
On Thursday 19 October 2006 11:14, Michael Schmitz wrote:
That's the point where I'll need a more elaborate introduction to
britney. The 'hints' is some file where you define preferred solutions
for these conflict situations, did I get that right?
[...]
Much appreciated. Maybe you can give me
On Thu, 19 Oct 2006, Michael Schmitz wrote:
Another buildd for stable-security seems a good idea, but the problem of
peak times remains.
And that's where both improved scheduling and closer coordination would
help. Meaning I'd appreciate some advance warning if something big comes
down
Much appreciated. Maybe you can give me some help to get started.
Maybe just looking here will give you an idea:
http://ftp-master.debian.org/testing/hints/
There's even a README :-)
That's what I absolutely _love_ about Debian. Just about anybody is real
helpful.
/sarcasm
It does give
Geert Uytterhoeven wrote:
Are there stats about memory, disk, and CPU usage for the previous
build, upon which you can base decisions about which buildd to use?
Not really.
Of course there are some lines about build times and disk usage in every
(successful) build log on buildd.debian.org.
And that's where both improved scheduling and closer coordination would
help. Meaning I'd appreciate some advance warning if something big comes
down the pipeline, so we can shunt it to the right machine to deal with
it.
Are there stats about memory, disk, and CPU usage for the previous
The suite itself? ftpmaster would make it, and a britney script would
be cronned to handle it. That shouldn't require any particular attention
though.
+ keeps the arch alive
- some work to keep m68k-testing in sync with real testing
needed
Who's doing
Maybe just looking here will give you an idea:
http://ftp-master.debian.org/testing/hints/
There's even a README :-)
That's what I absolutely _love_ about Debian. Just about anybody is real
helpful.
/sarcasm
I'll take that back. Frans was actually being helpful here.
Is the stuff at
Bill Allombert a écrit :
On Tue, Oct 17, 2006 at 01:42:07PM +1000, Anthony Towns wrote:
On Sun, Sep 17, 2006 at 11:55:02PM -0700, Steve Langasek wrote:
It's with some regret that I have to confirm that m68k is not going to be a
release architecture for etch.
We have also asked about removing
On Thu, 2006-10-19 at 12:01 +0200, Frans Pop wrote:
On Thursday 19 October 2006 11:14, Michael Schmitz wrote:
That's the point where I'll need a more elaborate introduction to
britney. The 'hints' is some file where you define preferred solutions
for these conflict situations, did I get
Hi,
On Wed, 18 Oct 2006, Steve Langasek wrote:
Insisting that m68k could never meet the architecture release requirements
doesn't make me think we're being unfair to m68k, it reinforces my belief
that cutting m68k from the full release was the correct decision. The
arch criteria weren't
Hi,
On Wed, 18 Oct 2006, Thomas Bushnell BSG wrote:
Roman Zippel [EMAIL PROTECTED] writes:
On Wed, 18 Oct 2006, Thomas Bushnell BSG wrote:
Roman Zippel [EMAIL PROTECTED] writes:
Well, that's what we want as well and if m68k could provide this, what's
the reason this couldn't
On Wednesday 18 October 2006 03:43, Roman Zippel wrote:
No, releasing with etch is out of the question -- m68k doesn't meet
the release criteria.
Well, this means the release criteria have been designed in a way that
m68k never could have met them anyway, m68k was practically fucked
either
On Wed, Oct 18, 2006, Anthony Towns wrote:
* have m68k be in unstable, and have it have its own testing-like
suite of some description
+ keeps the arch alive
- some work to keep m68k-testing in sync with real testing needed
- doesn't have real
Hello,
On Wednesday, October 18, 2006, at 03:43 AM, Roman Zippel wrote:
Outside of the m68k team I have unfortunately not seen any serious
effort
to actually accommodate the needs the smaller ports. Debian has been
the
home for a wide range of users, but that's unfortunately not true any
On Wed, Oct 18, 2006 at 09:30:00AM +1000, Anthony Towns wrote:
On Tue, Oct 17, 2006 at 09:12:52AM +0200, Ingo Juergensmann wrote:
What are the porters wanted to say? We want to release with Etch?
No, releasing with etch is out of the question -- m68k doesn't meet the
release criteria.
Oh
On Wednesday 18 October 2006 10:43, Ingo Juergensmann wrote:
And I have not seen any serious work or proposals from m68k porters
in this direction either.
Not?
Especially Roman has put great effort into fixing bugs and making the
toolchain stable again during the last weeks.
That is about
On Wed, Oct 18, 2006 at 09:49:50AM +0200, Ingo Juergensmann wrote:
Oh well...
It doesn't meet the release criteria because of the toolchain problems, that
have now been solved.
No, it hasn't. You need to be reliably abouve 95% for the entirety of:
On Wed, Oct 18, 2006 at 09:37:59AM +0200, Riccardo wrote:
Debian has always been also one of the linux distributions which
supported more architectures, I have used it a bit as netbsd of
linux. Just think of the long-standing efforts in 68k, hurd or sparc.
We shouldn't loose our roots.
So
On Wed, Oct 18, 2006 at 10:08:35AM +0200, Frans Pop wrote:
On Wednesday 18 October 2006 03:43, Roman Zippel wrote:
The question is what to do _instead_.
The point is that m68k gets kicked out _before_ any alternative has
been implemented. _Any_ m68k work has been in vain from the very
On Wed, Oct 18, 2006 at 10:10:10AM +0200, Loïc Minier wrote:
On Wed, Oct 18, 2006, Anthony Towns wrote:
* have m68k be in unstable, and have it have its own testing-like
suite of some description
+ keeps the arch alive
- some work to keep m68k-testing in sync
On Wed, 18 Oct 2006, Ingo Juergensmann wrote:
On Wed, Oct 18, 2006 at 10:10:10AM +0200, Loïc Minier wrote:
On Wed, Oct 18, 2006, Anthony Towns wrote:
* have m68k be in unstable, and have it have its own testing-like
suite of some description
+ keeps the arch alive
On Wed, Oct 18, 2006 at 11:44:52AM +0200, Raphael Hertzog wrote:
On Wed, 18 Oct 2006, Ingo Juergensmann wrote:
On Wed, Oct 18, 2006 at 10:10:10AM +0200, Loïc Minier wrote:
On Wed, Oct 18, 2006, Anthony Towns wrote:
* have m68k be in unstable, and have it have its own
I *have* asked about the possibility to maintain our own
slightly-different m68k distribution (similar to how amd64 works for
sarge) on debian.org servers, but have not heard anything about that.
I recall hearing a response much along the lines 'we could do that, but
that would require changes
Well, we have offers for ftp-master roles out of Debian. Still, I think it
is better for everyone to have a (maybe) reduced set of packages being
released with etch.
It's not the ftpmaster stuff that needs to be done, it's the RM and
security stuff. Security stuff for *sarge* is already a
On Wed, Oct 18, 2006, Raphael Hertzog wrote:
I believe there are some problems because we don't want to have too many
versions of the same source package, that's why this is not generalized
and why we try to keep all arches in sync.
It would be nice to know whether these problems are show
(dropping all individual CCs; please don't CC me)
On Wednesday 18 October 2006 14:55, Loïc Minier wrote:
In other words, it would be nice if the switch could be transparent
to m68k users so that they do not have to change setups or tweak an
unstable snapshot.
Note that a separate archive
Hi,
On Wed, 18 Oct 2006, Anthony Towns wrote:
On Wed, Oct 18, 2006 at 03:43:03AM +0200, Roman Zippel wrote:
The question is what to do _instead_.
The point is that m68k gets kicked out _before_ any alternative has been
implemented.
m68k has not been kicked out -- it's still in etch
Hi,
On Wed, 18 Oct 2006, Frans Pop wrote:
The point is that m68k gets kicked out _before_ any alternative has
been implemented. _Any_ m68k work has been in vain from the very
beginning and the question is now only how some of it can be
salvaged...
Come on. This attitude is not going
Hi,
On Wed, 18 Oct 2006, Steve Langasek wrote:
On Wed, Oct 18, 2006 at 09:37:59AM +0200, Riccardo wrote:
Debian has always been also one of the linux distributions which
supported more architectures, I have used it a bit as netbsd of
linux. Just think of the long-standing efforts in
Hello Roman,
On Wednesday, October 18, 2006, at 05:18 PM, Roman Zippel wrote:
This build attempt is from before gcj was fixed and once the buildd
gets
to it, it will build fine.
What's the point of this? arm fails to build this currently, do they
get
kicked out now because of this?
You
On Wed, 18 Oct 2006, Riccardo wrote:
On Wednesday, October 18, 2006, at 05:18 PM, Roman Zippel wrote:
This build attempt is from before gcj was fixed and once the buildd gets
to it, it will build fine.
What's the point of this? arm fails to build this currently, do they get
kicked out
Michael Schmitz wrote:
It's not the ftpmaster stuff that needs to be done, it's the RM and
security stuff. Security stuff for *sarge* is already a problem, with
the xfree86 update currently blocking the release of r4, due to lack of
an m68k build, eg.
Build times for kdebase_4:3.3.2-1sarge3:
On Wed, Oct 18, 2006 at 02:55:32PM +0200, Lo?c Minier wrote:
On Wed, Oct 18, 2006, Raphael Hertzog wrote:
I believe there are some problems because we don't want to have too many
versions of the same source package, that's why this is not generalized
and why we try to keep all arches in
On Wed, Oct 18, 2006 at 12:59:20PM +0200, Michael Schmitz wrote:
Regarding a solution for m68k beyond etch - I'd prefer to keep m68k
snapshots on a basis like you mentioned:
* have m68k be in unstable, and have it have its own testing-like
suite of some description
Anthony Towns schrieb am Donnerstag, den 19. Oktober 2006:
On Wed, Oct 18, 2006 at 12:59:20PM +0200, Michael Schmitz wrote:
Regarding a solution for m68k beyond etch - I'd prefer to keep m68k
snapshots on a basis like you mentioned:
* have m68k be in unstable, and have it have its
On Tue, Oct 17, 2006 at 01:42:07PM +1000, Anthony Towns wrote:
On Sun, Sep 17, 2006 at 11:55:02PM -0700, Steve Langasek wrote:
It's with some regret that I have to confirm that m68k is not going to be a
release architecture for etch.
We have also asked about removing m68k from testing
Hi,
On Thu, 19 Oct 2006, Anthony Towns wrote:
The reason we keep all architectures in sync is so that you end
up running the same thing if you install Debian on any supported
architecture. Otherwise you'd install Debian on i386 and have the
latest features, but install Debian on alpha and
Roman Zippel [EMAIL PROTECTED] writes:
Well, that's what we want as well and if m68k could provide this, what's
the reason this couldn't be released as Debian?
So far, m68k *can't* provide it. That's the problem.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe.
Hi,
On Wed, 18 Oct 2006, Thomas Bushnell BSG wrote:
Roman Zippel [EMAIL PROTECTED] writes:
Well, that's what we want as well and if m68k could provide this, what's
the reason this couldn't be released as Debian?
So far, m68k *can't* provide it. That's the problem.
Which we are
Roman Zippel [EMAIL PROTECTED] writes:
On Wed, 18 Oct 2006, Thomas Bushnell BSG wrote:
Roman Zippel [EMAIL PROTECTED] writes:
Well, that's what we want as well and if m68k could provide this, what's
the reason this couldn't be released as Debian?
So far, m68k *can't* provide it.
On Wed, Oct 18, 2006 at 05:12:40PM +0200, Roman Zippel wrote:
I can understand you are disappointed, but please try to be constructive
and help create the best support for m68k possible given the decision
that was made and work to get m68k to be a fully supported arch again for
etch+1.
On Mon, Oct 16, 2006 at 10:53:39PM -0700, Thomas Bushnell BSG wrote:
Bill Allombert [EMAIL PROTECTED] writes:
You did not ask Roman to provide examples of fixes are just stuck in the
BTS, you picked your own bug and then complains it is not a good example
? Is not that non-sense ?
No, what
Ingo Juergensmann [EMAIL PROTECTED] writes:
| Does this explain why guile-1.6 is still not compiled for m68k?
Maybe you just wanted to know if the bug is solved in the meanwhile, but
your way to ask is very, uhm, bad, because it includes some sort of attack.
Your question can be understood
On Tue, Oct 17, 2006 at 12:28:55AM -0700, Thomas Bushnell BSG wrote:
It's not like I hunted around for problems, I simply looked at the
cases closest to the packages I maintain, asking why don't they work
on m68k?
I expected you would have realised by that time that you maintain some
of the
On Tue, Oct 17, 2006 at 01:42:07PM +1000, Anthony Towns wrote:
On Sun, Sep 17, 2006 at 11:55:02PM -0700, Steve Langasek wrote:
It's with some regret that I have to confirm that m68k is not going to be a
release architecture for etch.
We have also asked about removing m68k from testing
Bill Allombert [EMAIL PROTECTED] writes:
On Tue, Oct 17, 2006 at 12:28:55AM -0700, Thomas Bushnell BSG wrote:
It's not like I hunted around for problems, I simply looked at the
cases closest to the packages I maintain, asking why don't they work
on m68k?
I expected you would have realised
Ingo Juergensmann [EMAIL PROTECTED] writes:
What are the porters wanted to say? We want to release with Etch? I think
that's obvious and the porters are doing their best to keep the port going
and keeping up as much as possible.
Why is the most recent g-wrap still not compiled for m68k?
I
On Tue, Oct 17, 2006 at 12:28:55AM -0700, Thomas Bushnell BSG wrote:
Um, You'll note that g-wrap also has not been built, another
dependency of gnucash. Version 1.9.6-3.1 was uploaded on September 7,
and gnucash depends on that version.
It's not like I hunted around for problems, I simply
Ingo Juergensmann [EMAIL PROTECTED] writes:
Oh well... you already know that m68k suffered from serious toolchain
problems, which are fixed now thanks to Roman, Stephen Marenka and others,
and that the w-b queueing algorithm is not known to be very intelligent,
i.e. it doesn't queue in order
Ingo Juergensmann [EMAIL PROTECTED] writes:
Oh well... you already know that m68k suffered from serious toolchain
problems, which are fixed now thanks to Roman, Stephen Marenka and others,
and that the w-b queueing algorithm is not known to be very intelligent,
i.e. it doesn't queue in order
On Tue, Oct 17, 2006 at 01:42:07PM +1000, Anthony Towns wrote:
On Sun, Sep 17, 2006 at 11:55:02PM -0700, Steve Langasek wrote:
It's with some regret that I have to confirm that m68k is not going to be a
release architecture for etch.
We have also asked about removing m68k from testing
On Tue, Oct 17, 2006 at 01:02:28AM -0700, Thomas Bushnell BSG wrote:
And that's why g-wrap hasn't been built, or is it irrelevant?
Yes, this is irrelevant for this thread as the topic of this thread is m68k
not a release arch for etch; status in testing, future plans? and not
Thomas Bushnell
On Tue, Oct 17, 2006 at 12:42:30AM -0700, Thomas Bushnell BSG wrote:
Bill Allombert [EMAIL PROTECTED] writes:
On Tue, Oct 17, 2006 at 12:28:55AM -0700, Thomas Bushnell BSG wrote:
It's not like I hunted around for problems, I simply looked at the
cases closest to the packages I
Hi,
On Tue, 17 Oct 2006, Thomas Bushnell BSG wrote:
Why is the most recent g-wrap still not compiled for m68k?
Because it's waiting for guile-1.6? How about instead of only complaining
you contact the maintainer and ask him to check out the patch and release
a fixed package?
bye, Roman
--
On Tue, Oct 17, 2006 at 01:42:07PM +1000, Anthony Towns wrote:
On Sun, Sep 17, 2006 at 11:55:02PM -0700, Steve Langasek wrote:
It's with some regret that I have to confirm that m68k is not going to be a
release architecture for etch.
We have also asked about removing m68k from testing
* Wouter Verhelst ([EMAIL PROTECTED]) [061017 14:19]:
On Tue, Oct 17, 2006 at 01:42:07PM +1000, Anthony Towns wrote:
On Sun, Sep 17, 2006 at 11:55:02PM -0700, Steve Langasek wrote:
It's with some regret that I have to confirm that m68k is not going to be
a
release architecture for
Hi,
On Tue, 17 Oct 2006, Ingo Juergensmann wrote:
- m68k can live without gcj-4.1 for some time, I think, so omit those from
the release
Actually gcj-4.1 is not an issue anymore (besides current build
dependencies), according to the test results it works for us now even
better than for arm
* Roman Zippel [EMAIL PROTECTED] [2006-10-17 14:18]:
The toolchain looks to be in pretty good shape right now and with
the next gcc update every reported problem will be fixed
This is slightly off-topic here, but I have not seen any of your m68k
GCC fixes been submitted and incorporated
Hi,
On Tue, 17 Oct 2006, Martin Michlmayr wrote:
* Roman Zippel [EMAIL PROTECTED] [2006-10-17 14:18]:
The toolchain looks to be in pretty good shape right now and with
the next gcc update every reported problem will be fixed
This is slightly off-topic here, but I have not seen any of
Ingo Juergensmann a écrit :
On Tue, Oct 17, 2006 at 01:42:07PM +1000, Anthony Towns wrote:
On Sun, Sep 17, 2006 at 11:55:02PM -0700, Steve Langasek wrote:
It's with some regret that I have to confirm that m68k is not going to be a
release architecture for etch.
We have also asked
Ingo Juergensmann [EMAIL PROTECTED] writes:
Yes, this is irrelevant for this thread as the topic of this thread is m68k
not a release arch for etch; status in testing, future plans? and not
Thomas Bushnell would like to see his packages being built on m68k. Maybe
that's disappointing for you
On Tue, Oct 17, 2006 at 01:24:26PM +0200, Wouter Verhelst wrote:
I've seen, no concrete suggestions on what the m68k porters want to do
about this.
I *have* asked about the possibility to maintain our own
slightly-different m68k distribution (similar to how amd64 works for
sarge) on
Hi,
On Sun, 17 Sep 2006, Steve Langasek wrote:
buildds: 19
There are 19 buildds actively uploading packages for m68k (Aug 20 to
present). This indicates that individual buildds are roughly an order of
magnitude slower than those for other architectures, which makes m68k a
limiting
On Mon, Oct 16, 2006 at 09:48:32PM +0200, Roman Zippel wrote:
As a result, the bts is already ignoring m68k in calculating a bug's
applicability for the testing distribution, at the release team's request.
As someone who has recently looked at and fixed many problems, I must say
the
1 - 100 of 144 matches
Mail list logo
