Re: Anyone using stretch/buster/sid on ARMv4t ?

[Rick Thomas]

> On Nov 7, 2017, at 3:27 AM, Christian Seiler <christ...@iwakd.de> wrote:
> 
> Hi,
> 
> Am 2017-11-07 11:49, schrieb Rick Thomas:
>> How do I know if a machine is ARMv4t?  I have a sheevaplug and a
>> couple of openrd machines (one “client”, the other “ultimate”) that
>> are still doing useful work.  Are they v4t?
> 
> cat /proc/cpuinfo should do the trick. It might not show the 't'
> after the 4, but it should definitely show whether it's an ARMv4
> or not. (And Debian's armel doesn't support any non-'t' ARMv4
> CPUs, so if it's ARMv4 and running Debian's armel port, it's
> ARMv4t.)

Thanks!  It looks like my machines are all 5TE — or maybe v5l ??  In any case, 
not v4t.

> rbthomas@client:~$ cat /proc/cpuinfo
> processor : 0
> model name: Feroceon 88FR131 rev 1 (v5l)
> BogoMIPS  : 1191.93
> Features  : swp half thumb fastmult edsp 
> CPU implementer   : 0x56
> CPU architecture: 5TE
> CPU variant   : 0x2
> CPU part  : 0x131
> CPU revision  : 1
> 
> Hardware  : Marvell Kirkwood (Flattened Device Tree)
> Revision  : 
> Serial: 

All three show the same output.

Enjoy!
Rick

Re: Anyone using stretch/buster/sid on ARMv4t ?

[Rick Thomas]

How do I know if a machine is ARMv4t?  I have a sheevaplug and a couple of 
openrd machines (one “client”, the other “ultimate”) that are still doing 
useful work.  Are they v4t?

Thanks,
Rick

> On Nov 5, 2017, at 1:32 PM, Adrian Bunk  wrote:
> 
> Hi,
> 
> for the armel port in buster the question of raising the baseline came up.
> 
> 20 years ago you could go into a shop and buy a mobile phone
> with a CPU supported by the armel port in stretch.
> 
> Roger Shimizu is doing a great job on ARMv5 hardware and I've seen bug 
> reports from users on ARMv5 hardware in stretch, so it is clear that
> ARMv5 should stay supported (and of course also ARMv6 and ARMv7).
> 
> But while it was mentioned that there exists ARMv4t hardware that works 
> with current mainline kernels [1], it is not clear whether there are any 
> actual users left - and without users we might not even notice if the 
> port is broken on the baseline.
> 
> If anyone is running stretch, buster or sid on ARMv4t hardware,
> then please let us know what device and kernel you are using
> and whether you intend to use buster.
> 
> cu
> Adrian
> 
> [1] https://lists.debian.org/debian-arm/2017/08/msg00046.html
> 
> -- 
> 
>   "Is there not promise of rain?" Ling Tan asked suddenly out
>of the darkness. There had been need of rain for many days.
>   "Only a promise," Lao Er said.
>   Pearl S. Buck - Dragon Seed
> 

Re: IMPORTANT: Do live Debian images have a future?

[Rick Thomas]

On Jul 3, 2017, at 8:53 AM, Steve McIntyre  wrote:

> arm64
> live images are on my todo list already for the buster cycle.

Great!  Will they work with RaspberryPi-3?

Rick

Re: IMPORTANT: Do live Debian images have a future?

[Rick Thomas]

I'm a user and a tester, not a dev, and I know nothing (and don't want to
know anything)
about the personal politics between Debian developers.  So that's all I'll
say on that subject.

To Steve's original point:

First, a big THANK YOU! to Steve for taking this job on.  I, for one, an
grateful.

I use Debian a lot, but I'm only an occasional user of the Debian Live
images.
 But when I need them, I need them. And when I need them, I want them to
just work.
If having them there and working when I need them means I have to add them
to my
list of things to test and report on, I'm willing to make that investment.

Please add me to your "testers" list.

Thank you,
Rick


PS: On a related topic:  What I think would be really cool, would be Debian
Live images
for some of the ARM architectures.  Something I could dd to a USB stick and
boot
right away when I get a new box in for testing.  Even cooler would be the
ability
to use that self-same live image to install Debian after the testing phase
was over.



> On 27 June 2017 at 00:08, Steve McIntyre  wrote:
>
>> [ Note the cross-posting... ]
>>
>>
>> If our live images are going to be good enough to meet the standards
>> that Debian users deserve and expect, we need *consistent*,
>> *sustained* involvement from a lot more people. Please tell me if
>> you're going to help. If we don't see a radical improvement soon, I'll
>> simply disable building live images altogether to remove the false
>> promises they're making.
>>
>> [1] https://get.debian.org/images/release/current-live/amd64/iso
>> -hybrid/#issues
>>
>> --
>> Steve McIntyre, Cambridge, UK.
>> st...@einval.com
>> "...In the UNIX world, people tend to interpret `non-technical user'
>>  as meaning someone who's only ever written one device driver." -- Daniel
>> Pead
>>
>
>

A modest proposal [Re: CD1 without a network mirror isn't sufficient to install a full desktop environment]

[Rick Thomas]

On Sep 10, 2012, at 11:08 AM, Karsten Merker wrote:


I do not think that making the default desktop environment
dependent on the type of the installation medium would be a good
idea; that would cause much confusion IMHO.


This was discussed years ago, but (with some trepidation) I'd like to  
bring it up again...


Why can't the user be allowed to choose the desktop environment she  
prefers (if any) at tasksel time?


If there is not any preferred DE, there's no need to clutter up CD-1  
with packages that apply to only a single DE -- CD-1 would only need  
to provide a basic environment and could be kept small; maybe almost  
as small as the netinst CD.


If it makes sense to provide a separate CD for Gnome, KDE, xfce/ 
lxde... then let that be CD-2a (Gnome), CD-2b (KDE), CD-2c (xfce/ 
lxde)... but without the basic install stuff (it's already on CD-1),  
leaving more space for the DEs to grow into...



Just a thought...

Rick


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/97d3e332-ff53-4e7d-98f4-5b6ab60d2...@pobox.com

Proposal for stage-1 boot loader for use with SecureBoot [Re: [Long] UEFI support]

[Rick Thomas]

The fundamental problem we must solve is allowing the *user* to  
securely choose which OS she wants to install.  Whether that OS  
follows thru and verifies all its parts is between the user and the  
person or group who provided the OS (could be the user, herself, of  
course!)


We need a stage-1 boot loader, signed by somebody trusted (FSF?  
SFLC?) with a key that will be recognized by the SecureBoot BIOS.   
This is an un-changable binary blob, so it can't be GPL (is this a  
problem?) but at least we can publish the source code, and anybody who  
wants to can verify that the blob is the result of compiling that  
source code.  Whoever did the original signing can publish signed  
updated blobs in the future if changes become necessary or desirable.   
Hopefully, the limited functionality in the original version will be  
enough to get the job done so changes will be infrequent to non- 
existent.


The stage-1 boot loader blob has the following functionality:

1) It can ask the user to enter a password, which it hashes into a the  
private half of a cryptographic signing key.  Without the user's  
password, the private half of the key is unknowable.  The public half  
of the key is, of course, freely available and should be cached in  
some kind of write-once/read-many memory if such is available (You can  
buy USB keys with a physical write-enable switch.  Would something  
like that be good for this application? Does the UEFI API have a way  
of stashing such a thing along with its keys?)


2) It can keep a cache of (location, description, signature) triplets  
for stage-2 bootloaders in some place where it can be retrieved  
without further user intervention.  Would the boot block be a good  
place?  The cache will be publicly readable -- and writable -- so it  
needs to be signed by the private part of the user's key, and  
verifiable with the public part of that key.


3) When it's loaded by the UEFI bios, it reads the cache and verifies  
the signature using the public part of the user's key.  Based on  
keyboard input (or lack thereof, after a short timeout) it picks one  
entry from the cache and loads that stage-2 boot loader, verifies its  
signature, and pass control to it.


4) Other things the user can do if she has access to the keyboard  
before the time-out expires:


a) Request a menu of, and choose one of, the available stage-2  
boot loaders, taken from the description part of the cached triplets.


b) Designate one from the above menu as the default for future  
boots if the timeout expires.


c) Request to add a new entry to the stage-2 boot loaders cache,  
providing the location and description.  It then requests and verifies  
the user's password and uses it to compute the signature of the new  
stage-2, then sign and write the modified cache.


d) Request deletion of a cache entry.   It then requests and  
verifies the user's password and uses it to sign and write the  
modified cache.


e) Request to change her password, providing the old password as  
verification of her right to do so.


f) Request to chain-load another stage-1 boot loader from  
removable media.  This program would need to be signed with one of the  
keys known to the SecureBoot BIOS, or, if not, have explicit  
permission to be loaded from the user at the keyboard.  This is the  
rat-hole we provide for installation of new OS's.


Would this work?  What have I missed?


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/38b1a676-40d9-4c0d-9dbb-6b50b533e...@pobox.com

Re: Needed input from Australian users and developers:; choosing timezones for Australia in D-I

[Rick Thomas]

On Mar 23, 2011, at 2:15 AM, Christian PERRIER wrote:


I'm just not fond of Australia/Sydney presented as a choice, I'd
rather have New South-Wales.



For what it's worth, the timezone database (as evidenced by, among  
other things, the output of the tzselect command) is organized  
mostly in terms of country/city rather than country/larger- 
geographical-area.


Which is not to say that the larger geographical areas get completely  
short-shrift in the timezone database.  Look at the directory  
structure under /usr/share/zoneinfo for example.


As I understand it, the choice of a large city in the affected  
geographic area is practical in two ways:


1) Individual cities are fairly unlikely to be split into two or more  
timezones.  Larger geographical units are more likely to be split than  
individual cities -- all depending on unpredictable future political  
squabbles.


2) Most people know what their nearest large city is.  They may not  
know the fine distinctions of past and present political divisions as  
applied to timezones as applied to their present location.



Just one point of view from somebody who occasionally lurks on the  
tz mailing list.


Enjoy!

Rick


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/0ef9eef7-c2e0-4767-be44-846fed53d...@pobox.com

Re: Needed input from Australian users and developers:; choosing timezones for Australia in D-I

[Rick Thomas]

On Mar 23, 2011, at 1:42 PM, Joey Hess wrote:


Rick Thomas wrote:

For what it's worth, the timezone database (as evidenced by, among
other things, the output of the tzselect command) is organized
mostly in terms of country/city rather than country/larger-
geographical-area.


This is also largely misunderstood, as often two cities with different
entries in the database observe identical time zone rules today. In  
some
cases they only differed for a week a century ago. I would not  
consider

the TZ database or tzselect anything resembling a useful UI, although
it is an interesting exercise in completism.

--
see shy jo, still in his own timezone!


In that case, whatever d-i does for UI, it needs to warn folks that it  
may be necessary to do a dpkg-reconfigure tzdata after the install,  
if they care about getting the details exactly right of that week in  
2006 when Australia hosted the Commonwealth Games.


Call us crazy if you like, but some of us do care.


Rick


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4397de66-4e61-4f91-a081-7cf296917...@pobox.com

Re: Debian Installer Lenny Beta1

[Rick Thomas]

On Mar 17, 2008, at 1:04 PM, Otavio Salvador wrote:


Please use the website
instead since there you find the documentation, errada and everything
else that you will need there:

http://www.debian.org/devel/debian-installer/


The [17 Mar 2008] Debian Installer lenny beta 1 link on that page  
leads to


===
Not Found

The requested URL /devel/debian-installer/News/2008/20080317 was not  
found on this server.




Apache Server at www.debian.org Port 80
===


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]