-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Somebody in the thread at some point said: | On Saturday, 2. August 2008 21:37:57 Andy Green wrote: |> If you missed the boat on installing the packages before reboot into new |> kernel, you can shutdown, pop the SD Card, insert to host and put the |> packages on SD Card, reinsert and then reboot and install (and run depmod). |> |> Subsequently kernel updates will also pull in the necessary matching |> modules, so this is a one-off hassle. | | That means we have no way of connecting to a running Neo via USB (if wifi does | not work) ?? Pretty strange ...
Yeah. Until now we took a shortcut and elevated Ethernet gadget above any other, now we levelled the playing field so Freerunner can appear as Mass Storage device for example. That is progress. | The kernel image and the rootfs image are seperate - we have to tell users: | Install this kernel and that rootfs or your Ethernet over USB does not | work ?! Packaging issues are out of my scope, or control. If nobody decided to add REQUIRES to the kernel package for the previously monolithic Ethernet over USB modules, then we end up like this. I issued an RFC about it on the kernel list before it was done, so this isn't some switch I threw in the dark while snickering. http://lists.openmoko.org/pipermail/openmoko-kernel/2008-July/004135.html Why does our packaging fragment the module binaries into a zillion individual packages anyway and allow this issue? Why are the modules, intimately tied to the monolithic kernel of the same version, not in the same package to guarantee consistency? We have the space and it will be a rare customer who micromanages his package set to the extent of adding and removing module packages. - -Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiUbhMACgkQOjLpvpq7dMrkpACeJI8c7FKIFCG3UKtQb0P8MW+N 7AAAn0GnjhUIvu49gr8X698nRGg54QIO =ZbJE -----END PGP SIGNATURE----- _______________________________________________ support mailing list [email protected] https://lists.openmoko.org/mailman/listinfo/support
