On Mon, 2020-12-07 at 17:45 +0100, Fabio Valentini wrote: > On Fri, Dec 4, 2020 at 4:12 PM Marius Schwarz <fedoradev@xxxxxxxxxxxx> wrote: > > > > Hi, > > > > as you may have heared, Fedora is now running on Pinephone and other devices, that need bleeding edge versions to > > function. > > > > Status of Fedora Pine as of 15:15 CET > > > > Cams now working, but app needs rework > > Mobile INET working > > WIFI working > > Touch working > > SMS working > > GPS working > > Calls partly, "calls app" does not connect to pulseaudio. > > Headphones ( sort of ) > > Mali400 GPU support working ( MPV rulez ) > > > > and with Gnome(38) instead of Phosh.. no window problems! Big Thanks to nikhiljha and his copr repo. > > > > O== my request > > > > In the last 3 days alone several updates ( i.e. bind-libs, gnome-shell 40~alpha ) caused a lot of bugs and needed to > > be downgraded directly from koji, > > by first finding & downloading them with wget ( because of the slow wifi and dependency checks, direct http links > > work ofcourse ), and later downgraded with > > dnf, which is so to speak, a pain in the ass. Of course, the best way to handle it would be, if the os compenents > > came from stable repos, so that these problems do not happen. But as i said, bleeding edge is needed atm. > > > > Is it possible to keep at least the last version of a package around in rawhide repo, to make dnf downgrade work? > > That would ease a lot of this pain. > > > > I know that there is a native koji tool to handle rawhide, but i must say, that won't work in most cases. Let me > > explain: > > > > Pine has announced to open stores in the US and Canada, because of the huge amount of requests for a pinephone. As > > it looks, this phone, as cheap as it compontants are, fills a gap of some kind. Therefor we will have much more user > > using it, and (i hope i can help with it) will use Fedora with Gnome-Shell. > > Phosh is more like Android, it has it charm, but tbh I, and people I showned it to, love they way gnome-shell > > handles stuff. > > > > We "may" get them to downgrade stuff with dnf, but that needs to be as simple as it could. > > I'm wondering, wouldn't this scenario be a prime application of an > OSTree based system like Silverblue? > It would give you exactly what you want, being able to revert to the > previous (working) version if the new one breaks something. Even > Android does something like this nowadays. Yeah, it really seems to me that OSTree managed system with apps in Flatpaks on top could work very well on an Linux mobile device. It could actually be much better than what's used in Android at the moment as I'm not sure they really do diff updates or how very well & you usually replace one system image by another one. So there is no way easy way to revert the update & the device might need a reflash if the update process is interrupted while the new system image is being created (due to a crash or running out of battery). With OSTree one could easily have multiple update states available (sable, cutting edge, last 3 updates, etc.) and as the new OSTree is created "in the background" without destroiong the current one/s it would be really hard to get the device into such a bad state with OSTree to need a reflash. > > Fabio > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
