schmitz dixit:
> Uploads are authorized by way of a signed .changes file. Who uploads once
> signed does not matter.
Yes, but…
> You're right there - logfiles are unsigned so there needs to be some
> authentication perhaps.
… right.
> Upload a detached signature alongside the logfile?
Mhm. I
Thorsten,
Doesn't seem to specify the protocol clearly. Yes, I know FTP sucks. But what's
the simple alternative for anonymous uploads?
That’s the point – WHY should these uploads be anonymous? In my opinion,
they must NOT be anonymous. (Not that we’d need the name of the uploader
but the
On Sun, May 27, 2012 at 04:47:08PM +1000, Finn Thain wrote:
> >
> > As Geert has mentioned, X lacks support for the Atari abd Amiga frame
> > buffer data formats. While I think X could be built (sorting out the
> > correct build order of all pieces up front) I doubt it will be useful
> > before
On Tue, May 29, 2012 at 2:07 PM, Thorsten Glaser wrote:
>>Unfortunately I was forgetting about the 68851 MMU, for which I can find
>>no soft-core implementation. One would need to be written before Linux
>>could be ported to a custom SoC on FPGA.
>
> Or sun3-style, I’d guess. But yes.
Or Coldfire
Finn Thain dixit:
>Unfortunately I was forgetting about the 68851 MMU, for which I can find
>no soft-core implementation. One would need to be written before Linux
>could be ported to a custom SoC on FPGA.
Or sun3-style, I’d guess. But yes.
NatAmi sounds nice, with LAN onboard (ugh, RTL though
On Sun, 27 May 2012, Brad Boyer wrote:
>
> The best I can find on OpenCores is a 68000.
That's the best I could find also. Some 68020 or better cores are
supposedly being worked on by various people involved in natami, fpga
arcade etc though there's no actual VHDL or Verilog code that I could
On Sun, 27 May 2012, I wrote:
>
> Yet you can buy new FPGA hardware and run a soft-core 68020! That kind
> of new hardware is easy to find.
Unfortunately I was forgetting about the 68851 MMU, for which I can find
no soft-core implementation. One would need to be written before Linux
could be
Thorsten Glaser writes:
> Andreas Schwab dixit:
>
>>schmitz writes:
>>
>>> I begin to understand the nightmare. X will have to be built then.
>>
>>But only the client libraries, which don't depend on the X server.
>
> Well, X is X and I don’t care about whether it’s one package less
> for the se
Andreas Schwab dixit:
>schmitz writes:
>
>> I begin to understand the nightmare. X will have to be built then.
>
>But only the client libraries, which don't depend on the X server.
Well, X is X and I don’t care about whether it’s one package less
for the server… the server’s not the dependency n
On 28.05.2012 13:32, Geert Uytterhoeven wrote:
Reviving Hades PCI support is possible (of course, just like adding
Amiga Mediator
PCI support). Who has the hardware?
Hmmm. I am not sure how many Hades owners are still around, respectively
how many machines in working order there are. I see the
schmitz writes:
> I begin to understand the nightmare. X will have to be built then.
But only the client libraries, which don't depend on the X server.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for somet
On Sun, 27 May 2012, Thorsten Glaser wrote:
> Finn Thain dixit:
>
> >Yet you can buy new FPGA hardware and run a soft-core 68020! That kind
> >of new hardware is easy to find.
>
> How fast would that be?
If I recall correctly, the minimig core is faster than a Motorola part
(i.e. it retires
On Mon, May 28, 2012 at 6:50 AM, schmitz
wrote:
>> Oh, and the kernel lacks support for radeonfb on the Atari ;-)
>> In fact, when booting on an Atari with a PCI Radeon it doesn’t
>> display anything at all. ;-)
>
> That's possible - I don't think I paid much attention to the atafb
> 'external' fr
(As a general note, putting empty lines in between quotes
and your own text, as well as removing empty quoted lines,
i.e. those only consisting of '>>> ', at the beginning and
end of quoted text, makes it much more legible, I’ve had a
hard time digging through your mail. The same goes for
disabling
Thorsten,
But CF was touted as the way out in relation to the 'you can still buy the
hardware' rule. Efforts were underway to unify the CF user space and Debian. I
might have misunderstood though.
I understood the same, but I’ve yet to see those efforts.
Or realise I’ve seen them if I did
On Sun, May 27, 2012 at 02:29:28PM +, Thorsten Glaser wrote:
> Michael Schmitz dixit:
> >Even then - I have maxed out my Falcon with 512 MB RAM
> >and that won't nearly be enough for a modern desktop system.
>
> My laptop’s not got much more. (But then, my modern desktop
> system usually comp
On Sun, May 27, 2012 at 8:47 AM, Finn Thain wrote:
>> As Geert has mentioned, X lacks support for the Atari abd Amiga frame
>> buffer data formats. While I think X could be built (sorting out the
>> correct build order of all pieces up front) I doubt it will be useful
>> before the frame buffer su
Michael Schmitz dixit:
>> There is no Debian/m68k on CF ;-)
>
>But CF was touted as the way out in relation to the 'you can still buy the
>hardware' rule. Efforts were underway to unify the CF user space and Debian. I
>might have misunderstood though.
I understood the same, but I’ve yet to see
On Sun, 27 May 2012, Michael Schmitz wrote:
>
> But CF was touted as the way out in relation to the 'you can still buy
> the hardware' rule. Efforts were underway to unify the CF user space and
> Debian. I might have misunderstood though.
All that work designing and maintaining a hybrid ABI,
Thorsten,
> It would be perfect if the buildds could run stock kernels from
> unstable, of course. Many (release!) architectures can’t do that,
> but we could. All ARAnyM buildds already can.
>
> For those who need Geert’s patches (e.g. EtherNEC/EtherNAT):
> https://www.freewrt.org/~tg/debs68k/di
Thorsten,
> >> Packages like emile that build for all architectures, so you can build
> >> e.g. bootable Mac CDs on i386. But maybe LP can do that for us.
> >
> >I still don't get it - such packages should be submitted to Debian as
> >wishlist
> >packages for inclusion, from there it's all take
> > Yuck - that sounds bad. But sometimes you can end up with very little actual
> > damage after a session of keeping the 'y' key pressed for as long as it
> > takes to complete a manual fsck. Might be worth a try.
>
> >From e2fsck(8):
>
>-y Assume an answer of `yes' to all questio
Geert Uytterhoeven dixit:
>On Fri, May 25, 2012 at 1:31 PM, Thorsten Glaser wrote:
>>>Creating a sub-list of important stuff that is holding back major portions
>>>would
>>>be preferred (IIRC Stephen did use to provide that).
>>
>> Right now, that’s one thing: X.org (and subsequently, the whole
On Fri, May 25, 2012 at 1:31 PM, Thorsten Glaser wrote:
>>Creating a sub-list of important stuff that is holding back major portions
>>would
>>be preferred (IIRC Stephen did use to provide that).
>
> Right now, that’s one thing: X.org (and subsequently, the whole shit
> fd.org/gnome stack). I’ve
Michael Schmitz dixit:
>> Packages like emile that build for all architectures, so you can build
>> e.g. bootable Mac CDs on i386. But maybe LP can do that for us.
>
>I still don't get it - such packages should be submitted to Debian as wishlist
>packages for inclusion, from there it's all taken
On Fri, May 25, 2012 at 11:02 AM, schmitz
wrote:
>> I
>> need to instruct my parents to boot into rescue system and fsck the
>> filesystem manually or restore the backup. But apart from that it could be
>> used as well.
>>
>
> Yuck - that sounds bad. But sometimes you can end up with very little a
Ingo,
Not many of us left I fear.
*sigh* Well, yes... sort of, maybe... ;-/
I'm not volunteering anybody :-)
Some time ago (last year or so?) I converted vivaldi and arrakis to use the
newer kernels. Maybe I should do some upgrade again, but basically these
machines are running for so
On 2012-05-24 04:11, Michael Schmitz wrote:
>>> But these autobuilders need somebody to inspect build logs, sign
>>> package uploads and such.
>> I *think* Wouter *may* have volunteered for that. Maybe whoever else
>> used to do that.
> Not many of us left I fear.
*sigh* Well, yes... sort of,
Thorsten,
> > I fear I don't get your point about arch: any packages and automated builds.
> > What exactly is the problem?
>
> Packages like emile that build for all architectures, so you can build
> e.g. bootable Mac CDs on i386. But maybe LP can do that for us.
I still don't get it - such pac
schmitz dixit:
> Regarding bug tracking, I fully support your proposal to ask LP for help with
> a
> solution.
OK.
> I fear I don't get your point about arch: any packages and automated builds.
> What exactly is the problem?
Packages like emile that build for all architectures, so you can buil
Thorsten,
Geert Uytterhoeven dixit:
I second that. In general, I would say that bootloaders don't matter that much
(to have in the official Debian archives).
Even then, bugtracking is an issue. And, for arch:any packages,
automated builds for e.g. amd64.
Launchpad could provide the f
Geert Uytterhoeven dixit:
>I second that. In general, I would say that bootloaders don't matter that much
>(to have in the official Debian archives).
Even then, bugtracking is an issue. And, for arch:any packages,
automated builds for e.g. amd64.
Launchpad could provide the former. Maybe even th
On Wed, May 16, 2012 at 4:57 AM, Finn Thain wrote:
> On Tue, 15 May 2012, Thorsten Glaser wrote:
>> The emile removal was (save me sort of forgetting about it?) mostly
>> that: a decision between the small and important things. It turns out
>> that Debian wants you to fix the small things and leav
On Tue, 15 May 2012, Thorsten Glaser wrote:
>
> The emile removal was (save me sort of forgetting about it?) mostly
> that: a decision between the small and important things. It turns out
> that Debian wants you to fix the small things and leave the important
> things broken for longer becaus
I'm willing to help, and I might be finding myself with a LOT of time on my
hands in about four months, so let me know what you'd like me to work on
and I'll see what I can do.
Jason
On Tue, May 15, 2012 at 6:23 PM, Kurt wrote:
> I've finally got some time and am looking at getting started on h
I've finally got some time and am looking at getting started on helping
with Coldfire V4 and M68K.
Up until 3 years ago I worked for Freescale as the engineer that did the
Coldfire V4 Linux work (547x/548x/5445x). After Freescale closed our
facility here in Utah I moved to a different company
Jonathan Nieder dixit:
>In the far long term, I wonder if something like [1] will be needed to
>bring the port back to the mainstream.
The ColdFire MMU port, yes (especially when they can share
binaries). That would be nice, too.
But let’s do one step at a time, I guess.
bye,
//mirabilos
--
Hi Thorsten,
Thorsten Glaser wrote:
> what are we going to do now? The Debian Project has apparently
> given up on m68k citing lack of progress
I don't think it's safe to assume Steve was speaking for the
project as a whole in the message you quoted.
> (
38 matches
Mail list logo
