Re: [Freedombox-discuss] Debian plan to drop support for Raspberry Pi and Dreamplug?
[Jonas Smedegaard] I believe proposal is not to drop the armel port entirely, but trim it to no longer support _smallest_ devices. That might be better, unless Dreamplug is one of those. The - jessie supported: - [proposed dropping] comment was not too clear for me, but it indicated that all armel archs supported in wheezy was planned to be dropped in Jessie. I guess I overlooked the link. You are correct that Neither Raspberry Pi nor Dreamplug can run on Debian armhf port (Dreamplug is ARMv5 that has no support for hardfloat, whereas Raspberry Pi is ARMv6 specifically supporting hardfloat but the Debian port has other features enabled too that are only supported in ARMv7 onwards). Right. -- Happy hacking Petter Reinholdtsen ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] Debian plan to drop support for Raspberry Pi and Dreamplug?
Quoting Petter Reinholdtsen (2013-12-04 13:31:30) [Jonas Smedegaard] I believe proposal is not to drop the armel port entirely, but trim it to no longer support _smallest_ devices. That might be better, unless Dreamplug is one of those. The - jessie supported: - [proposed dropping] comment was not too clear for me, but it indicated that all armel archs supported in wheezy was planned to be dropped in Jessie. I guess I overlooked the link. You quoted a lng text containing several links. I guess you mean the link in the section you emphasized: https://lists.debian.org/debian-arm/2013/06/msg00206.html No, I did not overlook that link - and in fact I thought you did, because it points to a mail with the title Dropping support for the smallest armel machines which discusses specifically the iop32x, ixp4xx and orion5x kernel flavors. Dreamplug uses kernel flavor kirkwood. I don't know which kernel flavor Raspberry Pi uses - if any flavor supported by Debian at all. Do anyone actually use Debian (instead of the unofficial fork optimized for ARMv6) for Raspberry Pi? Anyone has some measurements on running either system on Raspberry Pi? - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] Debian plan to drop support for Raspberry Pi and Dreamplug?
Jonas Smedegaard d...@jones.dk writes: Dreamplug uses kernel flavor kirkwood. Correct. I don't know which kernel flavor Raspberry Pi uses - if any flavor supported by Debian at all. Supposedly it can run one of the currently-stock Debian armel kernels, but it won't make best use of the floating point hardware. Do anyone actually use Debian (instead of the unofficial fork optimized for ARMv6) for Raspberry Pi? I haven't tried it yet, but I intend to soon. https://wiki.debian.org/RaspberryPi I've also seen quite a bit of discussion at various times about what it would take to properly support Raspberry Pi in Debian. The persistent need for a binary blob to boot seems problematic to me, but it's likely something that could be finessed in the installer similarly to how we currently handle user-supplied binary driver modules? Bdale pgp40MpAYLy7W.pgp Description: PGP signature ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] LDAP
Jonas Smedegaard d...@jones.dk writes: Ok. Makes good sense to mandate use of shared auth mechanism. Not convinced LDAP is the ideal for that, though. It probably isn't, but I don't know of anything better. Note that I traded emails in Feb with Howard Chu about using LDAP in this local-only way, and he strongly suggested we create an optimized build of openldap with a smaller footprint than the Debian standard build. Clearly not critical path, but this is another possible task for someone out there reading who would like a modest project that could help us out in the long term. It is of *big* importance to me that we do *not* move storage from /etc to a database: It may seem tempting to use that approach when needing a setup different from what the corresponding package maintainer offers, but since we have *no* administrator on our systems, our setup *must* be supported by package maintainers. I agree. What I think we can effectively use LDAP for is to manage the information associated with identities. Users, what access rights they should have, etc, in an application-neutral way that we can potentially wrap some plinth UI goodness around eventually. Bdale pgpGUezg64yP4.pgp Description: PGP signature ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] Dev: New FreedomBox-Setup Dependency: NTP
Petter Reinholdtsen p...@hungry.com writes: I am very found of NTP and correct clocks. And in an earlier version (a few weeks ago) of freedombox-setup, ntp was part of the installation set. But I decided to take it out until it was properly discussed, as it will create a regular beakon out of any freedombox machine. I think it's important to include. A UI switch to disable it if the user really wants to seems reasonable to include. Managing the set of peers / servers the box trades time information with when turned on seems like the right place to focus most of our configuration attention? At our meeting in Eben's offices in Feb, dkg came up with really cute hack for setting the system time in an initial set-up script by acquiring the client system's sense of time from I think an SSL session initiation packet. I'm not aware of that ever being publicly documented or implemented in our stack, but it seemed like a really neat hands off way to handle the set-the-time-on-first-boot problem without relying on centralized infrastructure. Bdale pgp_a8obxLRub.pgp Description: PGP signature ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
Re: [Freedombox-discuss] Debian plan to drop support for Raspberry Pi and Dreamplug?
The persistent need for a binary blob to boot seems problematic to me, I happened to learn recently that full open-sourcing of the GPU blob for the Pi seems very likely to happen soon, so this may not be an issue for much longer :-) hth hamish Hamish Cunningham http://pi.gate.ac.uk/ http://gate.ac.uk/hamish/ Professor of Computer Science, University of Sheffield, UK ___ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
