Seneca breaks silence on Fedora Remix

Better late than never I guess. I think I downloaded this somewhere, now i've got my pi perhaps i'll load it up and see how broken it is.

If it is badly broken, how did it get released ? Or is that a silly question ?

Steve,

  That isn't a silly question.  Fedora is supposedly the primary OS for this device,

so care should have been taken by all parties involved, to ensure that it worked

reasonably well.

  Apparently from what I can gather, the foundation isn't putting much funding into

development of Fedora.  Seneca lists their sponsors, but doesn't include the

foundation.  The foundation has apparently provided one alpha board, but no

beta boards.  I don't know about production boards.

  The development at Seneca was apparently done in connection with a class,

SBR600 taught by Chris Tyler:

http://zenit.senecac.on.ca/wiki/index.php/SBR600

The problems with the Remix were found immediately upon release, and

included problems with login, and problems setting timezone.  The login

problem apparently happens if the RPi is booted without being connected

to the network to set its time/date.  So it appears that no beta testing was done

by anyone in a different timezone than Seneca, or by anyone without a network

connection at boot time.

Other problems, such as general slowness and needing frequent reboots

may have been known at time of release, but may have been deferred in order

to meet the launch schedule.  These problems may be more difficult to fix.

I believe the login and timezone problems involved simple scripting errors

involving lifetime of environment variables.

I think much of the RPi work at Seneca was piggybacking on work for OLPC,

but I think OLPC is moving to ARM version 7,  at least for its newer machines.

We have yet to be told if Fedora will continue to be the primary OS,

and if so, what level of support will be provided, particularly in the way of

security updates and bugfix updates.  The lack of any support or updates

so far is not encouraging.

RaspberryPi org's downloads page no longer even lists Fedora 14 Remix - until recently it had noted that it was buggy and recommended Debian Squeeze instead, so from the Downloads page at least Debian Squeeze is the defacto standard.  Chris Tyler's CDOT group at Seneca do seem to be gearing up for two imminent releases, a new build of Fedora 17 due May 24, and some fixes and updates for 14 - source is this meeting from their wiki: http://zenit.senecac.on.ca/wiki/index.php/Fedora_ARM_Meeting_2012_May_02

RaspberryPi org's downloads page no longer even lists Fedora 14 Remix - until recently it had noted that it was buggy and recommended Debian Squeeze instead, so from the Downloads page at least Debian Squeeze is the defacto standard.  Chris Tyler's CDOT group at Seneca do seem to be gearing up for two imminent releases, a new build of Fedora 17 due May 24, and some fixes and updates for 14 - source is this meeting from their wiki: http://zenit.senecac.on.ca/wiki/index.php/Fedora_ARM_Meeting_2012_May_02

RorschachUK,  

That's very observant that the foundation has simply removed mention of Fedora.

I would have expected some sort of announcement if they are switching allegiance to Debian.     

The Seneca minutes you found from 2 May indicate plans for a F14 Remix update by EOW,

which I presume means the end of last week.  But that short schedule woudn't allow much

time for performance and/or stability improvements.  If those issues aren't solved soon,

then I think it will be difficult to overcome the lead that Debian currently has.

I'm a bit surprised that their plans make no mention of any issues from their bug-tracking system,

nor any mention of beta-testing the Remix update.  Normally I would expect an OS update plan

to be focused almost entirely on the status of issues from the bug-tracking system, and preparations

for internal and external testing.

some more details on the Fedora Remix login and timezone bugs.

On March 16, user jojopi proposed a solution to both bugs:

http://www.raspberrypi.org/forum/general-discussion/issues-with-fedora-mix-distro-element-14-have-withdrawn-download-from-site/page-2

"The reboot was intended not to be necessary.  The firstboot script goes through all the motions of making the user's runlevel choice effective immediately.  Unfortunately, all the motions fail because the script uses the shell variable RUNLEVEL internally.  /etc/init/rc.conf exports RUNLEVEL and runlevel(8) trusts RUNLEVEL over utmp(5).  So the script always thinks it is in the runlevel it wants to be in, whether it is or not.

It is difficult not to conclude that they must not have tested that.  Even more obviously the timezone selection, which goes through all the motions of finding the correct zonefile but then forgets to copy it to /etc/localtime, so you are left in EST no matter what you choose."

But these solutions, even if incomplete, weren't captured in the bug reports, because no bug reports

were created for any of the issues causing the Remix to be withdrawn.

On March 13, Seneca student developer challahar wrote:

http://challahar.wordpress.com/2012/03/13/firstboot-time-zone-module-release-0-1/

"I had some difficulties getting my timezone module to run during firstboot. For some reason it wouldn’t run and I would get a Class Module error. Took me a week to try and figure out that error. I end up deciding to redo what I wrote and for some odd reason it worked. Who knew….. That would of saved me a lot of time. I’m sure it was some typo or some small error I accidentally made. Anyway I finally got the the timezone module to work and was able to get the graphical look to my module. However, when I select a timezone it doesn’t store the selected data and implement it. I’ve been trying a number or different things but it doesn’t seem to make any improvement on what I already have."

A month later, on April 12, challahar wrote:

http://challahar.wordpress.com/2012/04/12/firstboot-time-zone-module-release-0-2/

"I have tried to troubleshoot the problem that I am still currently battling from Release 0.1. For some unknown reason my timezone module hasn’t been able to hold the selected information and implement it within the timezone."

On May 10, Jordan Cwang made some progress on the timezone issue:

http://roottothehead.blogspot.com/2012/05/diving-into-firstboot.html

"When setting the time, it makes sense to set the timezone the system is in first, otherwise the clock gets set incorrectly.   As such, the timezone module will create the proper file at /etc/localtime.  However, later on the date and time module gets called, which uses it's own information and overwrites the newly created /etc/localtime with one matching that of the original timezone.

Now I have to start mucking about in system-config-date to find a way to bypass this bug.  Well, I did say I wanted to learn python..."

p.s.

the May 9 Fedora ARM meeting minutes are available at

http://zenit.senecac.on.ca/wiki/index.php/Category:Fedora_ARM_Meeting