[fedora-arm] smartbook test resource
Greetings. I got my smartbook up on f17 (with old kernel, thanks devos). I've added it to my test machine resources for package maintainers. If you are a fedora package maintainer, you should have access. See: http://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers for more info and access details. If you need to test build or otherwise look at something on an arm machine, please do use it for this. As soon as there's a newer kernel that works I will be happy to update to it. ;) kevin signature.asc Description: PGP signature ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] smartbook test resource
On Wed, 14 Mar 2012 17:53:17 +0100 Niels de Vos wrote: > For all I know there is no kernel yet, but the one you currently have > on your SmartBook does not allow me to run mock on mine... :( I've not tried. > Not sure if that is related to SWAP on the internal pata disk or not > though. ok. > Have you had or did anyone using it report any unexpected hangs? Nope... but I am not sure anyone has used the machine. ;) Don't know if thats due to me setting it up wrong or just lack of interest. ;( > Thanks, > Niels kevin signature.asc Description: PGP signature ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Smolt or Census for Fedora ARM (Was: Who's using Kirkwood?)
On Wed, 10 Oct 2012 13:39:06 -0400 Scott Sullivan wrote: > So, I've noted on smolt[1] that the have stop generating reports. At > the time there was also only one armv7hl report. Yeah, smolt is being retired. http://lists.fedoraproject.org/pipermail/announce/2012-October/003107.html > Does anyone have a clear idea how far along the new "Census" is and > if it's going to be intergrated into F18? There is prelim code in the git repo, but not sure how far along it is. Best to ask on the census list how to help out. kevin signature.asc Description: PGP signature ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Fedora 17 v6hl First Compose Image
On Wed, 5 Dec 2012 18:20:20 + Jon Chiappetta wrote: > Hey everyone, > > I was finally able to create an initial image for the rasp pi v6hl. > It's by no means ready but I'm trying to release early and release > often so I'm sending this out now. I was wondering if anyone out > there who had two Raspberry Pi's (with the same RAM count) could do a > side-by-side comparison of our two Fedora 17 images (v5 vs v6)? Any > feedback would greatly help us out. I installed this on my pi here... seems to work. ;) I've not done much pounding on it however, just light xfce running... kevin signature.asc Description: PGP signature ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Hosting needed for a Fedora Remix image
On Thu, 2 May 2013 08:26:43 +0200 Niels de Vos wrote: > Hi all, > > last weekend I have been looking at creating a Fedora 18 Remix for > the Genesi Smartbook. My image seems to be working fine and I'd like > to share it with others. The only thing that currently blocks me is > the hosting the image somewhere. If there is someone that can put the > image on a public http/ftp server, I'd much appreciate that. You should be able to use your fedorapeople.org space for this. See: https://fedoraproject.org/wiki/Infrastructure/fedorapeople.org If you need more quota, just file a infrastructure ticket and explain why and how much you need. > The image is not final. It works with a very minimal kernel (non RPM) > and drivers, I hope to find time in the near future to improve it and > get closer to reach the full Fedora experience. Which basically > means, that the hosting will get updated images from time to time > (hopefully). > > Any takers? See above. ;) Also, I have a smartbook, would love to try and get it up and running on a more recent fedora soon. kevin signature.asc Description: PGP signature ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Include prelink in fedora arm?
On Tue, 6 Sep 2011 19:01:57 +0200 Jan Kratochvil wrote: > On Tue, 06 Sep 2011 17:39:55 +0200, Gordan Bobic wrote: > > Can you elaborate as to why? My experience and measurements show > > that prelink does more harm than good more offten than not. I can > > think of a lot of reasons to not use it, and very few reasons to > > use it. > > It speeds up the program startup up to 50% (you can Google out various > benchmarks). As almost any performance feature it sure comes with > more complexity of the ELF files handling. The most easy ELF files > processing would be with -O0 code - so why do we build the programs > with -O2? Citation needed? ;) All the benchmarks I have seen have been in the 10-15% range, and that only for packages that load a large number of libraries at startup time. (openoffice, konqueror, etc). > Nowadays some people do not consider performance as anything to care > about so in such case it is understandable they do not see a need for > prelink. > > It is true that if program is written in C it is usually fast enough. > But specifically ARM may be the only popoular platform where I do not > find the C programs fast enough, though. Personally, I would consider prelink a 'ok, we have everything working now, and we want to look at making it faster' instead of enabling it before everything is working or building. kevin signature.asc Description: PGP signature ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] smartbook queries
Greetings. Finally got f13 running (from sd) on my smartbook. ;) Some additional questions for those out there with one: * How do you install to the internal flash? dd and resizefs? I don't see a liveinst on the root image. * I see there's a f14 rc rootfs. Would this work on the smartbook with a newer kernel? * Are there any testing/alpha f15 rootfs/kernels out there yet? Thanks, kevin signature.asc Description: PGP signature ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] smartbook queries
On Tue, 6 Sep 2011 18:46:12 +0100 Peter Robinson wrote: > On Tue, Sep 6, 2011 at 6:17 PM, Kevin Fenzi wrote: > > Greetings. > > > > Finally got f13 running (from sd) on my smartbook. ;) > > > > Some additional questions for those out there with one: > > > > * How do you install to the internal flash? dd and resizefs? I don't > > see a liveinst on the root image. > > Or create a new file system and extract a rootfs onto it. ok. > > * I see there's a f14 rc rootfs. Would this work on the smartbook > > with a newer kernel? > > Yes, if your kernel is 2.6.32 or later. I'm planning on cutting a F-14 > beta smartbook image this week. Excellent. ;) > > * Are there any testing/alpha f15 rootfs/kernels out there yet? > > Not really, there's a rootfs for building of hardfp but its not really > designed with a UX but for building packages. On the XO 1.75 we're > seeing good improvements in performance on F-14 over F-13. Cool. Look forward to trying it out. kevin signature.asc Description: PGP signature ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] Re: aarch64 copr?
On 03/15/2018 09:12 AM, Avi Kivity wrote: > Hello, > > What are the prospects for getting aarch64 copr? Copr is very useful for > bringing bleeding edge Fedora packages to CentOS/RHEL users. 100% We have hardware, we just need to finish setting up a new OpenStack and transfer copr over to it. So it will happen, hopefully before too long. kevin signature.asc Description: OpenPGP digital signature ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@lists.fedoraproject.org
[fedora-arm](Re)Announcing the Mobility SIG!
Greetings everyone. I'd like to announce the revival of the Mobility SIG. Current efforts are focusing on the pine64 pinephone, but of course other mobile devices welcome. We are planning an initial meeting: 2020-10-06 at 16UTC in #fedora-meeting on freenode. There is a bridged chat room available: * Telegram: https://t.me/fedoraphone * IRC: #fedora-phone on Freenode * Matrix: #freenode_#fedora-phone:matrix.org More information at: https://fedoraproject.org/wiki/Mobility https://fedoraproject.org/wiki/Architectures/ARM/PinePhone Lets ramp up our pinephone efforts! kevin signature.asc Description: PGP signature ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@lists.fedoraproject.org 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/arm@lists.fedoraproject.org
[fedora-arm] Re: Any update on suggested devices?
On Tue, Nov 10, 2020 at 11:28:49AM -0500, Matthew Miller wrote: > In the meeting right after the F33 release, we talked about identifying a > handful of key devices and making sure anyone with a serious interest in > testing or enablement work has what they need. I've talked with Marie, and > while we're not overflowing with cash, Fedora does have unspent budget which > would normally have gone to travel sponsorships and this seems to be a > reasonable thing to use some of it on. IoT is a Fedora Edition, after all, > and worth investing in. > > At that meeting, we talked about y'all coming up with a list of specific > hardware we can order for people. Because reimbursements are a mess right > now for unrelated reasons, it's easiest when it's something Marie can > actually go to a web store, click some buttons, and have shipped direct. Can > y'all (IoT WG and ARM SIG) come up with a formal list with prices and URLs? > (Also, if other things like microsd cards need to be included?) > > Of course, once we have a list of hardware, I'd also like to send it to > people. I know there's some worry about people volunteering, getting stuff, > and not actually doing anything. We want to make sure the devices are going > to people who will actually be able to make use of them. But I also don't > want that to be a blocker, so, if you're new but serious I am willing to > consider including you too. (Perhaps with the promise that if your best > intentions don't work out, you find someone else to pass the hardware on > to.) > > Rather than people emailing me at random, which is easy for me to drop, can > the WG and/or SIG come up with a list of people? I'm thinking something like > a dozen people and 1-3 devices each depending on commitment level. I have some very old pine64 boards and a beagleboneblack here... I'd be happy to test some more up to date hardware. kevin signature.asc Description: PGP signature ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@lists.fedoraproject.org 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/arm@lists.fedoraproject.org
[fedora-arm] Mobility SIG meeting - 2020-12-14 16:30UTC
Greetings everyone. I'd like to announce the next Mobility SIG meeting for next monday (2020-12-14) at 16:30UTC in #fedora-meeting. A tenative agenda: * introductions * status / plans on current remix * status / plans for next step remix with fedora kernel + patches and images built on copr * status / plans for official kickstart/images * All other business Our current efforts are focused on the pine64 pinephone, but other devices welcome. Please add / suggest topics at: https://pagure.io/fedora-mobility/issue/1 We plan to meet monthly on the second monday of the month moving foward. Please join us! More information at: https://fedoraproject.org/wiki/Mobility https://fedoraproject.org/wiki/Architectures/ARM/PinePhone Lets ramp up our pinephone efforts! kevin signature.asc Description: PGP signature ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@lists.fedoraproject.org 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/arm@lists.fedoraproject.org
[fedora-arm] pinephone remix meeting and recent boot issue
Just thought I would send a quick heads up here: There were some updates to the pinephone fedora remix ( https://github.com/nikhiljha/pp-fedora-sdsetup ) late last week that caused it to stop booting. ;( To fix you can simply copy a new current image or mount your sd card on a desktop and copy the boot* files from the zip file in https://download.copr.fedorainfracloud.org/results/njha/mobile/fedora-rawhide-aarch64/02120809-pp-uboot/pp-uboot-2021.01-rc5.fc35.src.rpm to /boot Also, we just had our monthly mobility sig meeting: https://pagure.io/fedora-mobility/issue/7 Interested parties are encouraged to join us next time or find us on #fedora-phone on irc, matrix and telegram. Thanks, kevin signature.asc Description: PGP signature ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@lists.fedoraproject.org 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/arm@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[fedora-arm] Re: arm 32 bit fedora quit booting
On Wed, Dec 29, 2021 at 07:08:19PM -0500, Jeffrey Walton wrote: > On Wed, Dec 29, 2021 at 2:34 PM Timothy Krantz > wrote: > > > > I have several 32 bit arm machines running fedora 35. I update them via > > dnf on an almost daily basis. > > > > Yesterday afternoon I had a brief power failure and now none of them will > > boot or boot into an unusable state. At first I suspected the power blip > > was the culprit but now I am not so sure. I am getting similar behavior on > > all of them. > > > > Here is a capture of my wandboard quad : > > > > https://pastebin.com/fVQYCXML > > > > The first thing that I see that looks bad is about 26 seconds in : > > > > [ 26.070965] systemd-journald[234]: Received SIGTERM from PID 1 (systemd). > > > > But maybe that is a red herring. Things do go south from there. > > > > Similar issues on a lime2 and a ras pi running 32 bit code. > > > > Any suggestions would be appreciated. > > It sounds like a hardware problem due to the earlier power problems. > There's no way a software update could be interrupted at the same > point on several machines, and produce the same exact error during > boot on those machines. > > Check the power warts. They are cheap and go bad on their own. They > don't need a power surge or brownout to smoke them. That you had a > [significant enough] power event was probably more than enough to > break them. > > Or, check your power distribution strip if the machines are plugged > into the same strip. Might be: https://bugzilla.redhat.com/show_bug.cgi?id=2035802 (ie, libzstd breaking things, try downgrade/upgrading?) kevin signature.asc Description: PGP signature ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@lists.fedoraproject.org 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/arm@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[fedora-arm] Re: Fedora on Pinephone Pro & path to upstreaming
On Mon, Jan 31, 2022 at 05:49:14AM -, Be wrote: > Hello, > I've been using Fedora on my Pinephone for like 9 months or so and my > Pinephone Pro Explorer Edition just arrived the other day. The original > Pinephone's boot order had the microSD card before the eMMC which made it > really easy to try different OSes. By contrast, on the Pinephone Pro, the > boot order in hardware is: > > 1. SPI flash > 2. eMMC > 3. microSD > > From the factory, there is a u-boot image on the eMMC drive which will boot > an OS from the SD card before the eMMC and there is nothing on the SPI flash. > This is problematic because it's really easy to accidentally get the device > into an unbootable state when installing an OS to the eMMC drive if the > factory uboot build is erased. There is a way to temporarily disable the eMMC > drive in hardware to make it boot from SD, but that's not obvious or > convenient. So, currently, the Pine wiki > (https://wiki.pine64.org/wiki/PinePhone_Pro) advises against replacing the > stock Manjaro OS on the eMMC drive and few distros are providing prebuilt > images. > > People working on different distros have been coordinating how to deal with > this. The plan is to use a fairly new project, Tow Boot, and flash it to the > SPI flash: > https://samuel.dionne-riel.com/blog/2021/05/10/unveiling-tow-boot.html > Putting the platform firmware on the SPI flash chip separate from the eMMC > drive will make the process of installing OSes easier and more foolproof. > Support for the Pinephone Pro in Tow Boot is almost ready with support for > the Pinephone Pro's SPI flash just added today, albeit it needs a little > polishing. Tow Boot on the SPI flash will make the process of installing an > OS similar to x86; distros just need to create a UEFI bootable system and do > not need to worry about shipping platform firmware. Tow Boot also obviates > the need for JumpDrive. Simply pressing the volume up button on boot will > expose the eMMC drive as a USB mass storage device, refer to > https://github.com/Tow-Boot/Tow-Boot/pull/67 for details about the UX design. > Hopefully future Pinephon > e Pro batches will ship with Tow Boot on the SPI flash from the factory, but > for now users will need to install it by booting a Linux system from an SD > card. A Tow Boot installer image like that has already been made for the > Pinebook Pro, so I think one for the Pinephone Pro will be ready to test soon. So, sadly, I still don't quite understand the boot process on arm devices, but why is tow-boot suggested here instead of just using uboot? ie, whats the advantage of tow-boot here? > This is great new for Fedora because I think it means we can use the normal > Fedora tools for building ARM images to create UEFI bootable images without > needing the scripts in https://github.com/nikhiljha/pp-fedora-sdsetup that > were made for the Pinephone. Using Fedora tooling to build the Pinephone Pro > images opens up the path to smartphone support in upstream Fedora. I've been > digging around in scattered documentation and talking to Conan Kudo on Matrix > and IIUC, the way the upstream images are built is that Punji calls `koji > image-build` which calls livemedia-creator. Please correct me if I've > misunderstood this. I've tried to figure out how to build aarch64 images > locally on my x86-64 laptop and made a bit of progress using Mock with > livemedia-creator as documented at > https://weldr.io/lorax/livemedia-creator.html#using-mock-and-no-virt-to-create-images > arm images are made via imagefactory/oz, depending on what image you are talking about here? There is also work to move imagefactory/oz built images over to ImageBuilder (a image as a service type thing run by Red Hat). > Thanks to the efforts getting Fedora on the original Pinephone, good progress > has been made getting Plasma Mobile and Phosh packaged in upstream Fedora. > There are still a handful of packages in the > https://copr.fedorainfracloud.org/coprs/njha/mobile/ COPR repository that > aren't upstream. I think enough has been upstreamed at this point that we can > start working on base Plasma Mobile and Phosh Kickstart files to use with > livemedia-creator that could eventually make it upstream. For now, we'll > still need device-specific Kickstarts for the downstream kernel packages > which could %include the base Plasma Mobile or Phosh Kickstart. Fortunately > for the Pinephone Pro, distros are coordinating to avoid the fragmentation > that has happened with kernels for the original Pinephone and development > effort is being coordinated on the > https://gitlab.com/pine64-org/linux/-/tree/pine64-kernel-ppp-5.16.y/ > repository. Right. I would think next think we want is to upstream uboot support, then get kernel support in. I have no idea if Fedora kernel maintainers would be willing to carry some/any/all of the patches there, but I think that has a much better chance than the pin
[fedora-arm] Re: Fedora on Pinephone Pro & path to upstreaming
On Fri, Feb 11, 2022 at 01:42:39AM -, Be wrote: > Whether Tow Boot or uboot is on the SPI flash isn't really relevant to > distros. The point is that distros shouldn't have to worry about shipping > uboot, just like Fedora doesn't ship UEFI firmware for x86-64. Tow Boot has > some UX advantages for mobile devices that may or may not be wanted in > upstream uboot. Please read Samuel's blog post if you haven't already: > https://samuel.dionne-riel.com/blog/2021/05/10/unveiling-tow-boot.html Sure. Although if we are asking them to ship with something perhaps our pleas will influence what they decide to do. > Regarding imagefactory and oz, it looks like those are for cloud images? I'm > confused what that has to do with mobile phones. I'm talking about the > Workstation/Plasma/XFCE images on https://alt.fedoraproject.org/alt/ So, yeah, fedora makes tons of different kinds of images. We have dvd isos, we make live images that expect to be booted to a live env (which you can then later install from), qcow2's for virt/cloud, raw disk images (where you expect to dd or use arm-image-installer to transfer to a usd card and run it), etc. We use a bunch of different tools for this currently, depending on the image: If it's a install dvd (like the server install dvd), it's made by pungi. If it's a live media (expecting to copy to a usb or the like and run live, later optional install) it's made by livemedia-creator. If it's a raw image (like current single board arm things we support) it's made by imagefactory. Our existing arm supported devices have followed the 'run arm-image-installer' to install a raw image to a usd and run from there. It might make sense to do something different for the pp and ppp... > > As for encryption, we could encrypt the filesystem in a loopback image or > with Tow Boot's USB Mass Storage mode if Plymouth could show an on screen > keyboard to decrypt it. Yeah. Lots to work out. kevin signature.asc Description: PGP signature ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@lists.fedoraproject.org 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/arm@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[fedora-arm] Re: Fedora on Pinephone Pro & path to upstreaming
On Sat, Feb 12, 2022 at 11:28:08PM +, Peter Robinson wrote: > On Sat, Feb 12, 2022 at 11:19 PM Be wrote: ...snip... > > > > Unless you mean something else by "USB recovery". > > Yes, I do, the rockchip recovery doesn't expose mass storage, that > must be a tow-boot thing, hence why I discounted that. The rockchip > recovery isn't dependent on software. There is a way to bypass the eMMC if something goes wrong: https://wiki.pine64.org/wiki/PinePhone_Pro#Boot_order kevin signature.asc Description: PGP signature ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@lists.fedoraproject.org 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/arm@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[fedora-arm] Re: F36 buildroot broken on armv7hl
On Tue, Mar 15, 2022 at 01:21:09PM +0100, Dominik 'Rathann' Mierzejewski wrote: > On Tuesday, 15 March 2022 at 11:39, Dominik 'Rathann' Mierzejewski wrote: > > Hello! > > Has anyone else seen this? > > https://koji.fedoraproject.org/koji/taskinfo?taskID=84213778 > > failed on armv7hl: > > > > Error: > > Problem 1: conflicting requests > > - nothing provides /bin/sh needed by dnf-4.10.0-2.fc36.noarch > > Problem 2: package dnf-plugins-core-4.0.24-2.fc36.noarch requires > > python3-dnf-plugins-core = 4.0.24-2.fc36, but none of the providers can be > > installed > > - conflicting requests > > - nothing provides python3-dbus needed by > > python3-dnf-plugins-core-4.0.24-2.fc36.noarch > > - nothing provides python(abi) = 3.10 needed by > > python3-dnf-plugins-core-4.0.24-2.fc36.noarch > > - nothing provides python3-hawkey >= 0.46.1 needed by > > python3-dnf-plugins-core-4.0.24-2.fc36.noarch > > (try to add '--skip-broken' to skip uninstallable packages) > > > > https://pagure.io/releng/issue/10696 filed. Fixed. It was a misconfigured builder you happened to hit. > > The above task has also failed on aarch64 with what looks like a crash, > > but I'm unable to reproduce it either on aarch64-test01.fedorainfracloud.org > > or locally on a Pinebook Pro in mock with the same golang package in > > buildroot. > > Strangely enough, a resubmitted task succeeded: > https://koji.fedoraproject.org/koji/taskinfo?taskID=84217961 > > I had to resubmit it a couple of times, though. Two attempts failed: > https://koji.fedoraproject.org/koji/taskinfo?taskID=84217283 > https://koji.fedoraproject.org/koji/taskinfo?taskID=84217961 It looks like the tests for this package are flaky/have race conditions? Both those failed in random tests... kevin signature.asc Description: PGP signature ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@lists.fedoraproject.org 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/arm@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[fedora-arm] State of the mibility SIG, dec 2023
Greetings. This will be a bit long, but I hope it will explain the current unfortunate state of the mobility sig. First a bit of history. The mobility sig was originally formed back in 2010. The goal then was “… a group of Fedora contributors that are interested in Fedora on small devices. Initially aimed at supporting NetBooks, Mobile Internet devices” A good deal of progress on small devices like netbooks and tablets was made, but then the members of the SIG moved on to other concerns. Then, in 2020 the most recent version of the SIG formed. The goal was focused on getting Fedora working well on the new pine64 pinephone, and then later when announced the new pine64 pinephone pro. In the last 3 years we have accomplished a lot: The phosh stack has been packaged up We have been producing Fedora Remixes with 3rd party kernels to provide support for pinephone and pinephone pro. a Phosh spin has been created and officially produced There was a effort to get a remix working for the oneplus 6, but still requiring a lot of manual tweaking. Unfortunately, the active members of the sig are not able to move things forward right now. The pinephone and pinephone pro are both old devices at this point. They were slow when released, and thats not improved. Worse, upstreaming of patches to get either of them working with a Fedora/Mainline kernel seems unlikely to us for a lot of reasons, including that many of the 3rd party patches aren’t in a state that upstream would accept and many authors of them have no particular desire to upstream them. The phosh spin is largely not useful in the current situation as the Fedora mainline kernel barely boots on the pinephone pro (not at all on the pinephone) and has no wireless or display. The image could be of use to other aarch64 single board style devices, but since they usually don’t have displays or modems, the phosh interface isn’t of particular insterest. Until the advent of some performant mobile device to target or more contributors who wish to drive things forward, I think we should just mark the Mobility sig inactive at this point, including: Retire the Phosh spin in f40 Hopefully find new maintainers for the phosh stack if there’s folks that want to keep them alive. Mark the sig inactive on wiki and matrix. respins will move to against a stable fedora release once a week or so, instead of against rawhide and more often. Hopefully there is someday a brighter day for Fedora mobile devices. Folks that want to try and revive the SIG and/or are able to see a good path forward are invited to join #mobility:fedoraproject.org. kevin signature.asc Description: PGP signature -- ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@lists.fedoraproject.org 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/arm@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: State of the mibility SIG, dec 2023
On Thu, Dec 14, 2023 at 08:00:50AM +0100, Dan Čermák wrote: > Hi Kevin, > > I'm sorry to hear that you bumped into so many issues with upstreaming > patches and hence have to put the SIG into a dormant state. > > Nevertheless, I would like to thank you and all the contributors for > your amazing work and congratulate you for what you accomplished! Let us > hope for better days for a Linux powered cell phone :) Yeah. I mostly did coordination work... the harder stuff was all Yoda/torbuntu. Many kudos to them. Lots of hours of work. ;) kevin signature.asc Description: PGP signature -- ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@lists.fedoraproject.org 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/arm@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: State of the mibility SIG, dec 2023
On Thu, Dec 14, 2023 at 08:47:10AM +, Peter Robinson wrote: > Hi Kevin, > > Thanks for the update. Comments inline. > > Firstly I'd like to apologise for my lack of public participation in > the SIG, the last year or two has proven quite problematic for me > personally, I've had a lot of "higher priorities" which has reduced my > available hacking time, and that seems to quickly get gobbled up with > things like RPi regressions and release blocker bugs. Throw in a whole > bunch of mental health issues and something had to give. yeah, I hear ya. This last few years have been difficult here too. ;( > That being said, in the last few weeks I have been actually back to > some hacking projects... more on that below. > ...snip... > So I have been booting the original Pinephone on Fedora 39, display > works so I'd be interested in the issues you're seeing there. I'm > booting the original PP because of the Wireless, I've been looking at > some of the realtek modules for another project but hoping the side > effect is actually the rtl8723 series devices should be upstream > soon(ish). This should also resolve the issue on the original PineTab > although I don't remember who has that as I don't (the people that do > please reach out if you want to help testing). I've not looked too much at the pp recently... it's just so... slow. I suppose if wifi and display works it could be of some use now. > The PPP is also on my list to look at again soon, initially it'll be > around U-Boot due to the F-39 blocker issues as I'm working to resolve > that upstream for once so I'll be testing that on my PPP, I thought we > had the wireless and screen there, I do need to circle back more to > this one though TBH. We did have screen at one point. wifi we had also at one point if you copied a blob over that wasn't in linux-firmware. But I don't think either are currently working. :( > > Until the advent of some performant mobile device to target or more > > contributors who wish to drive things forward, I think we should just > > mark the Mobility sig inactive at this point, including: > > I think marking the SIG as inactive probably makes sense. > > > Retire the Phosh spin in f40 > > What's currently produced here? We have a Phosh aarch64 raw image. But... without much if any hardware it actually boots on. > > Hopefully find new maintainers for the phosh stack if there’s folks > > that want to keep them alive. > > How much work is this? How many packages? tor posted about them here: https://discussion.fedoraproject.org/t/needing-to-handoff-mobile-sig-packages/89303 This is the phosh stack and a few other things. > > Mark the sig inactive on wiki and matrix. > > Just as I actually get the energy to setup matrix :-P although I am > yet to find the SIG there Should be #mobility:fedoraproject.org room > > respins will move to against a stable fedora release once a week or so, > > instead of against rawhide and more often. > > What's in the respins? Is that basically Fedora and custom kernel? Yep. Fedora userspace/packages, but heavily patched kernel with all the stuff to make pp/ppp work. kevin signature.asc Description: PGP signature -- ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@lists.fedoraproject.org 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/arm@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: State of the mibility SIG, dec 2023
On Thu, Dec 14, 2023 at 09:16:02AM +, Peter Robinson wrote: > One other thing I had meant to bring up to mobility meetings, which I > had been missing which I think I now realise is probably because they > moved to matrix. > > Is handheld gaming consoles a possible focus or interest for mobility SIG? > > I've seen a bunch of devices, in particular the Anbernic RGXX3 ones, > landing upstream so it's possible they could be a much easier target > but TBH I have not looked extremely closely here. > > https://anbernic.com/collections/handheld-game-console Sure, it's possible. I don't think I have time to work on it, but if there's enough interested folks, that could be a way forward. kevin signature.asc Description: PGP signature -- ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@lists.fedoraproject.org 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/arm@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
