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 ?
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 I did was I asked how his claim relates to a particular bug
in a
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 since it is not
> currently a release candidate; Anthony Towns has i
On Mon, Oct 16, 2006 at 10:39:26PM +, Bill Allombert wrote:
> On Mon, Oct 16, 2006 at 10:57:00PM +0200, Kurt Roeckx wrote:
> > 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
Bill Allombert wrote:
> On Mon, Oct 16, 2006 at 10:57:00PM +0200, Kurt Roeckx wrote:
> > 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
Hi,
On Mon, 16 Oct 2006, Thomas Bushnell BSG wrote:
> Roman Zippel <[EMAIL PROTECTED]> writes:
>
> > was your initial phrase 'Please
> > let the release team know how we can be of assistance to you in setting
> > and meeting goals for an m68k release' just a hollow phrase...
>
> I never said
On Mon, Oct 16, 2006 at 04:20:56PM -0700, Thomas Bushnell BSG wrote:
> Roman Zippel <[EMAIL PROTECTED]> writes:
>
> > On Mon, 16 Oct 2006, Thomas Bushnell BSG wrote:
> >
> >> Roman Zippel <[EMAIL PROTECTED]> writes:
> >>
> >> > Fixes for problems are too often simply stuck in the BTS now, because
Roman Zippel <[EMAIL PROTECTED]> writes:
> was your initial phrase 'Please
> let the release team know how we can be of assistance to you in setting
> and meeting goals for an m68k release' just a hollow phrase...
I never said anything of the kind.
If the m68k team can make the port happen wit
Hi,
On Mon, 16 Oct 2006, Thomas Bushnell BSG wrote:
> But you attempted to trick people, by pretending that the patch was
> already there before my email. You wanted to make me look bad, as if
> I was bringing up an example where there was a patch in the bug-log.
> Since your claim is that m68k
On Mon, Oct 16, 2006 at 09:48:32PM +0200, Roman Zippel wrote:
> 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
> > mag
Roman Zippel <[EMAIL PROTECTED]> writes:
>> Your message was deliberately misleading, designed to suggest that
>> there had been a fix in for a while (even if "not that old yet"), when
>> in fact, the patch was posted *after* my message.
>
> What the hell is your problem? Yes, the patch is _one_ d
Hi,
On Mon, 16 Oct 2006, Thomas Bushnell BSG wrote:
> You claimed that it's a bad idea to drop m68k as a release candidate,
> because the only way bugs will get fixed is if maintainers are forced
> to include patches.
I didn't say anything about "forcing", that's your conclusion.
> In fact, the
On Mon, Oct 16, 2006 at 10:57:00PM +0200, Kurt Roeckx wrote:
> 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 someon
Roman Zippel <[EMAIL PROTECTED]> writes:
> On Mon, 16 Oct 2006, Thomas Bushnell BSG wrote:
>
>> > I'm not sure what you intent with this question. The patch is not that
>> > old yet, but it's there:
>> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=326905
>>
>> Wow, that's rich. The patch w
Hi,
On Mon, 16 Oct 2006, Thomas Bushnell BSG wrote:
> > I'm not sure what you intent with this question. The patch is not that
> > old yet, but it's there:
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=326905
>
> Wow, that's rich. The patch was posted to the bug log all of THIRTY
> MINU
Roman Zippel <[EMAIL PROTECTED]> writes:
> On Mon, 16 Oct 2006, Thomas Bushnell BSG wrote:
>
>> Roman Zippel <[EMAIL PROTECTED]> writes:
>>
>> > Fixes for problems are too often simply stuck in the BTS now, because in
>> > many cases maintainer simply don't care about m68k support. I often have
Hi,
On Mon, 16 Oct 2006, Thomas Bushnell BSG wrote:
> Roman Zippel <[EMAIL PROTECTED]> writes:
>
> > Fixes for problems are too often simply stuck in the BTS now, because in
> > many cases maintainer simply don't care about m68k support. I often have
> > to bug people to get them to release a
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
Roman Zippel <[EMAIL PROTECTED]> writes:
> Fixes for problems are too often simply stuck in the BTS now, because in
> many cases maintainer simply don't care about m68k support. I often have
> to bug people to get them to release a fixed package.
Does this explain why guile-1.6 is still not com
Hi,
On Mon, 16 Oct 2006, Kurt Roeckx wrote:
> I suggest you read section 5.10 of the developers reference, and do
> porter/non-maintainer source uploads if you think it's holding up things
> and the maintainer isn't very responsive.
I'm not a Debian developer, I'm "only" a user, who'd like to su
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
> limit
On Mon, 16 Oct 2006, Geert Uytterhoeven wrote:
> On Mon, 16 Oct 2006, Michael Schmitz wrote:
> > Geert: can you send me the kernel binary that only did a black screen for
> > you? I'd like to test it on the hardware itself...
>
> Bummer, I don't have it anymore. And my 2.6.19-rc2 tree doesn't comp
On Mon, 16 Oct 2006, Michael Schmitz wrote:
> Geert: can you send me the kernel binary that only did a black screen for
> you? I'd like to test it on the hardware itself...
Bummer, I don't have it anymore. And my 2.6.19-rc2 tree doesn't compile yet
for Atari.
I'll see whether I can get it `workin
/m68k 85
Build started at 20061016-1149
**
Checking available source versions...
Checking available source versions...
Can't find source for clamav_0.84-2.sarge.11
(only different version(s) 0.84-2.sarge.10 found)
Giving
> Michael> Current state of atafb follows inlined (vger ate the last
> Michael> BASE64 attachment, sorry). Replaces my previous patch, now
> Michael> supports monochrome, 16 and 256 bit VGA mode. Please test.
>
> "Signed-off-by: " please or it can't go upstream. If things don't
> start propaga
> > I'm not sure if it is still the case, but in the copy of the tree I
> > have handy, atari_scsi uses a local copy of NCR5380.c rather than
>
> Sure, but once upon a time, that local copy was derived from NCR5380.c and
> the business end of the logic didn't change.
>
> > the shared copy being use
Things are finally starting to come together for RC1.
- We've found a good work-around for the bug in g-i where selected lines
in multi-select lists would not be shown. We need new versions of
some gtk packages for that, but these have now been uploaded.
Thanks especially to Loïc Minier for h
> > it just throws random kernel panics from the interrupt handler,
> > and the soft lockup watchdog. Any ideas on this?
>
> No idea, doesn't happen to me. I am still using kernel 2.4.27 but I
> almost started compiling 2.4.33 with the eth patch for Bill as I can't
> believe that the gcc ICE is ara
On Mon, Oct 16, 2006 at 02:15:54PM +0200, Roman Zippel wrote:
> > It seems as if someone did just that... ;)
> Not according to this:
> http://buildd.debian.org/~jeroen/status/architecture.php?a=m68k&buildd=buildd_m68k-arrakis
I just took a look at http://unstable.buildd.net/buildd/m68k_stats.pn
Hi,
On Mon, 16 Oct 2006, Ingo Juergensmann wrote:
> > BTW could someone please take care of the packages stuck on arrakis
> > (especially apache2)?
>
> It seems as if someone did just that... ;)
Not according to this:
http://buildd.debian.org/~jeroen/status/architecture.php?a=m68k&buildd=bui
On Mon, 16 Oct 2006, Michael Schmitz wrote:
> > > we really need Petr's disk access speedups ...
> >
> > BTW, I have just tried the tar zxf test on ramdisk (to eliminate the IDE
> > bottleneck) and it finished in 43 seconds (Athlon XP 2500+ = 1833 MHz).
> > Compare with 26 seconds on crest...
>
>
Michael Schmitz wrote:
BTW: something seems utterly broken in the current testing (-3) aranym
package. I seem to recall you mentioned something went wrong there
already;
Bill found that current sid with its gcc-4.1.1-14 does not compile
anything due to ICE. But that shouldn't be related to -3
> > we really need Petr's disk access speedups ...
>
> BTW, I have just tried the tar zxf test on ramdisk (to eliminate the IDE
> bottleneck) and it finished in 43 seconds (Athlon XP 2500+ = 1833 MHz).
> Compare with 26 seconds on crest...
BTW: something seems utterly broken in the current testing
On Mon, Oct 16, 2006 at 01:02:01PM +0200, Roman Zippel wrote:
> BTW could someone please take care of the packages stuck on arrakis
> (especially apache2)?
It seems as if someone did just that... ;)
Anyway, there are still 245 packages listed as building (that was 351 just
about an hour ago, th
Hi,
On Mon, 16 Oct 2006, Michael Schmitz wrote:
> > java-gcj-compat just failed, although gcj-4.1 installs fine on my machine.
> > Could someone please check what's going on and perhaps build it manually.
> > xulrunner is waiting for it and way too much is waiting on this.
>
> Any special requir
> java-gcj-compat just failed, although gcj-4.1 installs fine on my machine.
> Could someone please check what's going on and perhaps build it manually.
> xulrunner is waiting for it and way too much is waiting on this.
Any special requirements for this (lots of RAM, fast machine)??
Micha
36 matches
Mail list logo
