Re: [fedora-arm] System time
On Tue, Sep 01, 2015 at 01:38:21PM -0500, Dennis Gilmore wrote: > Without a battery backed RTC its really not that useful. Picture 6 or 10 > months after a release, does it matter if the time is half a year to a year > off or 35 years off? If a system needs to use something TLS-protected, then the system clock must not be too much off because a certificate might not be valid otherwise. At least in debian there is also a fake hwclock package that reduces the offset to the time that passed since the system was last booted: https://packages.debian.org/sid/fake-hwclock Regards Till ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Who's using Kirkwood?
Hi, On Sat, Oct 06, 2012 at 05:43:33AM -0400, Jon Masters wrote: > I'm interested to know who is using Kirkwood, and who would miss it if > it went away. For now, we won't kill off ARMv5 because it is used in the > official rPi builds but that doesn't mean I'm not interested to know > whether we should put testing effort into Kirkwood for F18. > > My thought is that the latest plugs are moving to ARMv7, and so as the > cutting edge Linux distro, we should make plans for deprecating support > over the coming releases. This is not a call to drop support today. If I > can get numbers on how many people care, that will help. I bought several Kirkwood devices with the expectation to run Fedora on them and would like to test it at least on a Seagate Dockstar, but the little instructions and installer support always scared me away. For example for Debian there are really good instructions to get the installer running: http://www.cyrius.com/debian/kirkwood/sheevaplug/index.html It also includes instructions to update the boot loader and supports installing on USB, SD card and eSATA. The Fedora instructions only mention to dd an image on a SD card on the other hand.A Maybe Fedora ARM could reuse some of the information provided for Debian to ease installation of Fedora ARM as well. Regards Till ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Who's using Kirkwood?
On Mon, Oct 08, 2012 at 02:53:45PM -0400, Scott Sullivan wrote: > On 10/08/2012 02:35 PM, Till Maas wrote: > >Hi, > > > >On Sat, Oct 06, 2012 at 05:43:33AM -0400, Jon Masters wrote: > > > >>I'm interested to know who is using Kirkwood, and who would miss it if > >>it went away. For now, we won't kill off ARMv5 because it is used in the > >>official rPi builds but that doesn't mean I'm not interested to know > >>whether we should put testing effort into Kirkwood for F18. > >> > >>My thought is that the latest plugs are moving to ARMv7, and so as the > >>cutting edge Linux distro, we should make plans for deprecating support > >>over the coming releases. This is not a call to drop support today. If I > >>can get numbers on how many people care, that will help. > > > >I bought several Kirkwood devices with the expectation to run Fedora on > >them and would like to test it at least on a Seagate Dockstar, but the > >little instructions and installer support always scared me away. > > Till, > > I've recently updated the Fedora install instructions for the > Pogoplug with is in the same family of devices and leverages the > same uboot update process that dockstar does. > > https://fedoraproject.org/wiki/Architectures/ARM/PogoplugUSBDisk > > As long as uboot is configured correctly, the process is as simple > as dd the image to a USB drive. > > > > >It also includes instructions to update the boot loader and supports > >installing on USB, SD card and eSATA. The Fedora instructions only > >mention to dd an image on a SD card on the other hand. > > You'll note that it's not Debian directly providing that support or > information. It's the Debian community and specifically one user. It is at least the documentation that is directly linked at http://www.debian.org/ports/arm/ > The same goes for Fedora, because of the man power requirements it > is up to the community to support re-used consumer appliances like > the Dockstar/Pogoplug. If you are successful in getting Fedora on > your Dockstar, we would greatly appreciate a contribution of your > experience and instructions on the wiki. It seems that the disk image boots on the dockstar, but a first "yum update" got oom-killed and there seems to be no swap and not LVM on the image to easily change this. IMHO a problem with the Fedora ARM documentation is, that it is only a collection of reports from people how they did it. It is lacking information about why something was done as described or how it should be done. For example the Debian documentation clearly states which uboot version is required and how to update it. The Kirkwood documentation in the Fedora ARM wiki only says that the proper uboot config depends on the uboot version and gives an example that is supposed to work on a Guru Plug Server Plus. Comparing it with the Debian documentation it also shows that different hex values (addresses?) are used in the uboot config for the kernel and initramfs. But why do they need to be different? Or do they not need to be different? Also as far as I can see there are no instructions about how the images are created and why they have been chosen the way they are (no LVM, no swap, device dependent names for kernel and initramfs, vfat for /boot). From my outsider POV the ARM SIG looks not very organised which makes it also hard to help now and then. For example I would more or less reduce the wiki install contents to the difference to the shown Debian documentation to avoid duplicate content and trust that they chose sane values, for example for the uboot version and the uboot config. But then it is unclear whether Fedora needs a different uboot config. Regards Till ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Who's using Kirkwood?
On Tue, Oct 09, 2012 at 08:54:26AM +0100, Peter Robinson wrote: > On Mon, Oct 8, 2012 at 10:56 PM, Till Maas wrote: > > On Mon, Oct 08, 2012 at 02:53:45PM -0400, Scott Sullivan wrote: > >> On 10/08/2012 02:35 PM, Till Maas wrote: > Well you could always step up to help improve that documentation > rather than complain ;-) I already started after I wrote the email. But it is hard to enhance it, if I do not know why certain decisions have been made or why the images are the way they are. > > From my outsider POV the ARM SIG looks not very organised which makes it > > also hard to help now and then. For example I would more or less reduce > > the wiki install contents to the difference to the shown Debian > > documentation to avoid duplicate content and trust that they chose sane > > values, for example for the uboot version and the uboot config. But then > > it is unclear whether Fedora needs a different uboot config. > > It's not so much a lack of organisation but rather a lack of people to > do things. There's about 6 of us that do things regularly and between > us we might make up the equivalent of 1.5 full time people. > > Those of us that are actively working on it are having a hard time > just keeping up with core tasks of building a some what working distro > let alone producing a lovely working polished wiki with step by step > howtos for the 100s of devices out there. The debian docs showed, that not so much different documentation is needed for the different devices. For example the Guru Plug documentation seems to mostly cover the dockstar or other kirkwood devices already. But the way it was written it implied at least for me, that it contains special steps only required/working on a Guru Plug. For example the page said the image needs to be dumped on a SD card. But a USB stick works as well and I guess an eSATA device, too. > We are well aware that there are issues with documentation and a whole > lot of other things. We're working through things as time and > materials are available. All help is welcome including improving the > howtos and documentation on supporting each device. I would absolutely > love someone with ideas on improving the way the wiki is laid out for > things like device support howto to step up and implement the general > layout framework with some place holders for various devices so > interested people with those devices can add appropriate information. Imho an easy step would be to for example just use the debian docs as reference and only hightlight differences. For the example that Fedora does not support using an installer on ARM but only pre compiled disk images and that they use VFAT for /boot to support proprietary uboot systems. This is less work than to re-write everything that is already in the debian docs. Regards Till ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Who's using Kirkwood?
On Tue, Oct 09, 2012 at 04:30:24AM -0500, Dennis Gilmore wrote: > El Tue, 9 Oct 2012 08:54:26 +0100 > Peter Robinson escribió: > > On Mon, Oct 8, 2012 at 10:56 PM, Till Maas > > wrote: > > > It seems that the disk image boots on the dockstar, but a first "yum > > > update" got oom-killed and there seems to be no swap and not LVM on > > > the image to easily change this. IMHO a problem with the Fedora ARM > > > documentation is, that it is only a collection of reports from > > > people how they did it. It is lacking information about why > > > something was done as described or how it should be done. For > > > example the Debian documentation clearly states which uboot version > > > is required and how to update it. The Kirkwood documentation in the > > > Fedora ARM wiki only says that the proper uboot config depends on > > > the uboot version and gives an example that is supposed to work on > > > a Guru Plug Server Plus. Comparing it with the Debian documentation > > > it also shows that different hex values (addresses?) are used in > > > the uboot config for the kernel and initramfs. But why do they need > > > to be different? Or do they not need to be different? Also as far > > > as I can see there are no instructions about how the images are > > > created and why they have been chosen the way they are (no LVM, no > > > swap, device dependent names for kernel and initramfs, vfat > > > for /boot). > > not that it will explain everything but Debian ships uboot for the > kirkwood devices and add features not found in the stock uboot. ext2 > support being one of them which is why /boot is vfat we support the > stock uboot and only ship uboot where we have to preferring instead that > the vendors be responsible for supporting and supplying uboot binaries. > we are still evolving the image creation process. in f17 it was a shell > script that used yum. we are moving to use kickstarts and anaconda via > livemedia-creator Thank you for the vfat history. Are the image creation scripts available somewhere? Is there a bug tracker for them? Regards Till ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Who's using Kirkwood?
On Wed, Oct 10, 2012 at 09:46:37PM +0100, Peter Robinson wrote: > Marvell? Asking who in particular? And what configuration. There's a > lot of kirkwood chips with 128Mb or less RAM which makes it a little > pointless for a Fedora image and hence IMO not relevant. A Seagate dockstar has only 128Mb RAM and boots Fedora without a problem. Why should it not be used with Fedora? Debian supports it without problems as well. Regards Till ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Who's using Kirkwood?
On Fri, Oct 12, 2012 at 01:37:51PM -0400, Derek Atkins wrote: > Brendan Conoboy writes: > Personally I'd be fine if we consider Kirkwood to be "server only" > (i.e. "headless"). So to me that implies that a lack of Libreoffice is > "okay". Granted, I don't know if that's okay from a Fedora standpoint. I would not miss Libreoffice as well. As far as I know many Kirkwood devices do no have any connector for a display, e.g. the Guru plug, Sheeva plug or Dockstar. Regards Till ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] livemedia-modifier (linked in wiki) missing
Hi, on http://fedoraproject.org/wiki/Architectures/ARM/Fedora_18_Beta/GuruPlug there is a link to http://142.204.133.82/tmp/livemedia-modifier which is supposed to be a script to change /boot from ext to vfat. But the link does not work. Can the script maybe added properly to Fedora? Regards Till ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] slow loading of initrd/kernel from ext file system on kirkwood/dockstar
Hi, I noticed that loading the kernel/initrd from an ext4 file system as it is the default on F18 Beta is very slow compared to vfat. It takes several minutes instead of seconds. Is this only the case on my dockstar? I already updated the uboot to the latest release I found on http://people.debian.org/~tbm/u-boot/ but it did not help. Regards Till ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] arm software floating point support going forward
Hi, On Thu, Jan 31, 2013 at 04:30:32PM +0100, Dan Horák wrote: > Fedora provides all tools to run armv5tel as say tertiary architecture, > just needs a volunteer with some hardware. what is going to happen with the hardware used to build packages now for kirkwood? Regards Till ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] F18 for the Pogoplug e02
On Mon, Apr 15, 2013 at 11:28:12PM -0400, Robert Moskowitz wrote: > which talks about F18-beta. So what do I have to do to build a F18 > production image and is there anything else I need to do? > > Oh, the primary use of this system will be as a backup/archive server. AFAIK it will not be supported anymore starting with Fedora 19, therefore you might consider setting up a different distribution. Regards Till ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] Fedora 12 updates still rsyncing?
Hiyas, I noticed that there seem to be no Fedora 12 updates for ARM. The mirror linked on the wiki page does not show any packages: http://ftp.linux.org.uk/pub/linux/arm/fedora/pub/fedora/linux/updates/12/arm/ And the wiki als says that the updates are still rsyncing. Are the updates distributed somehow else? Regards Till ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Fedora 12 updates still rsyncing?
On Mon, May 10, 2010 at 09:49:18PM -0400, Chris Tyler wrote: > The Fedora-ARM builds from around F8 though F12 were built on Lennert's > koji farm in Europe. That was recently decommissioned, and there's a new > koji farm being built here at Seneca by Paul Whalen. The plan is to use > Dennis Gilmore's koji-shadow tool to follow updates on the main archs, > so as updates are built for PCs they will also be built for ARM. Thus, > F13 should have consistent updates. Is there some public place, where this is documented? How many machines are used to build the build farm? Are these all Sheeva-style systems? Btw. afaics the problem was not that no updates were built for F12, but they were never synced to the mirrors. Regards Till pgpZytKKnCEYA.pgp Description: PGP signature ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Fedora 12 updates still rsyncing?
On Wed, May 12, 2010 at 06:06:04PM +0200, Lorenzo Villani wrote: > On Mon, 2010-05-10 at 21:49 -0400, Chris Tyler wrote: > > The Fedora-ARM builds from around F8 though F12 were built on Lennert's > > koji farm in Europe. That was recently decommissioned, and there's a new > > koji farm being built here at Seneca by Paul Whalen. The plan is to use > > Dennis Gilmore's koji-shadow tool to follow updates on the main archs, > > so as updates are built for PCs they will also be built for ARM. Thus, > > F13 should have consistent updates. > > > > -Chris > > Any ETA? It seems to be targeted for May-June: http://blog.chris.tylers.info/index.php?/archives/232-Seneca-and-the-Fedora-ARM-Secondary-Architecture.html Regards Till pgpkKRkItg1mi.pgp Description: PGP signature ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Guru Plug Sever Plus and Rootfs
On Sat, May 29, 2010 at 03:22:21PM +0200, Bernhard Schuster wrote: > So what should I do? How can I fix it? Can I just put a script in > /etc/init.d creating the device Nodes? And if so, which mode has console to > be (mknod has a bunch of options :> )? I am just guessing, that maybe you can just use MAKEDEV /dev/console etc. Regards Till pgpHcPF3Dpt1X.pgp Description: PGP signature ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Guru Plug Server [Plus] Kernel
On Sun, Jul 04, 2010 at 02:01:18AM +0200, Bernhard Schuster wrote: > Failed... it seems I was even to supid to patch the kernel properly. Afaik > the first file to be patch doesn't even exist... > > Help appreciated... I suppose you get help faster if you write what you tried and how it failed. Regards Till pgp5cEk8EotbQ.pgp Description: PGP signature ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Guru Plug Server [Plus] Kernel
On Tue, Jul 06, 2010 at 11:51:57PM +0200, Bernhard Schuster wrote: > I finally got kernel 2.6.35-rc4 built for armv5 using the provided cross > compile tool chain, but without additional patches (yet). This means wlan > only works as client and NOT as host (due to libertas_sdio not being > included in 2.6.35-rc4 as far as I can say). Everything else is supposed to > work pretty well. Atm I try to find a proper way to generate a rpm package, > but "make rpm-pkg" fails with the following error(s): > > /bin/sh /sandbox/linux-2.6.35-rc4/scripts/setlocalversion --scm-only > > /sandbox/linux-2.6.35-rc4/.scmversion > cat: .scmversion: input file is output file > make[1]: *** [rpm-pkg] Error 1 > make: *** [rpm-pkg] Error 2 > > Appendix: auto generated .spec file > > Help appreciated! > > Once I understand that process and why it keeps failing, I am going to > create a patched kernel so GuruPlugServerPlus is usable as AccessPoint Are the patches maybe included in this git repo? http://git.marvell.com/?p=orion.git Also the wireless modules can maybe be built alone according to: http://www.plugcomputer.org/plugwiki/index.php/Re-building_the_kernel_and_U-Boot Regards Till pgppoPdlPxIer.pgp Description: PGP signature ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] bad link on http://fedoraproject.org/wiki/Architectures/ARM page
On Thu, Aug 19, 2010 at 02:15:06PM -0400, Paul W. Frields wrote: > On Sun, Aug 15, 2010 at 12:54:47PM -0700, rihowa...@gmail.com wrote: > > If you go to http://fedoraproject.org/wiki/Architectures/ARM and then > > scroll down to > > > > Latest Release: Fedora 12 > > > > The following is available for F12: > > > > A set of patches necessary to make Fedora packages build for ARM. > > A set of source RPMs from the base F12 repository which also includes > > packages that have been modified to build for ARM. (still being rsyned...). > > > > > > If you then click on the base F12 repository link it goes to > > http://fedora-arm.wantstofly.org/pub/fedora/linux/releases/12/Everything/source/SRPMS/ > > and this results in a 404. > > Fixed: > https://fedoraproject.org/w/index.php?title=Architectures%2FARM&diff=193398&oldid=189864 Actually this is not a proper fix, because the linked SRPMS contained ARM specific patches, that are probably now gone. I updated the wiki to reflect this. Unluckily most of the ARM SIG communication happens in the IRC or private channels, therefore I do not really know what is going on. But the RPMs were generated by a previous setup of the SIG. I CC'ed the ARM list, so someone with more knowledge can update this even better. Regards Till pgpd1oxr6ftUq.pgp Description: PGP signature ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Support for ARMv7, hardware math
On Wed, Dec 01, 2010 at 11:20:28PM +0100, Henrik Nordström wrote: > ons 2010-12-01 klockan 14:37 -0500 skrev omall...@msu.edu: > > > I was looking at today. Today the project has a handful of builders. > > How does the project get on track to appear to be a viable solution, > > rather then a secondary arch that is 2 releases behind to someone > > unfamiliar with the project? What is the easiest way to get there > > today? > > First step is to massage the builders until F13, F14 and finally rawhide > can be shadowed automatically and we can focus on actual arm issues more > than stupid build issues. > > This is doing very good progress, and should from what I understand > settle in a couple months. At the moment the build farm is working hard > on catching up. AFAICS there are already lots of high level packages sucessfully built in koji[0] for F13, therefore I assume he base comps packages are probably all built already, too. So it should already be possible to install F13 on a arm box or is there some necessary package missing? It seems that the major problem is, that there is no Fedora 13 arm repo, e.g. the wiki [1] suggests that the packages are available at http://ftp.linux.org.uk/pub/linux/arm/fedora/ but I cannot find F13 packages there: http://ftp.linux.org.uk/pub/linux/arm/fedora/pub/fedora/linux/releases/ Regards Till [0] http://arm.koji.fedoraproject.org/koji/builds [1] http://fedoraproject.org/wiki/Architectures/ARM/Using pgp9ECeJFcqo6.pgp Description: PGP signature ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] What is the best way to fix build issues with Fedora 13 RPMs?
On Tue, Mar 08, 2011 at 10:01:02AM +, Gordan Bobic wrote: > Niels de Vos wrote: > > Hello all, > > > > it looks like not all Fedora 13 packages can be build on ARM yet. For > > some packages there have been tickets opened at the Trac instance: > > - https://fedorahosted.org/arm/report/1 > > > > I'd like to help out with building these packages, but am not a > > 'proven packager' [1], so I can not fix the issues completely and rely > > on the package maintainer or other proven packagers. What I am doing > > right now is filing bugs against the packages that can not be build on > > ARM. I'm including pointers to the issue and propose fixes, like: > > - Bug 682515 - libgda-4.1.4-1.fc13.src.rpm does not rebuild on Fedora 13 > > for ARM > > - Bug 682538 - geos-3.2.1-1.fc13.src.rpm does not build on Fedora-13 for ARM > > > > These bugs are blockers for the ARMTracker which make them easily findable: > > - > > https://bugzilla.redhat.com/showdependencytree.cgi?id=245418&hide_resolved=1 > > We're tracking build failures as bugs now? Really?? Tracking build failures is probably overkill as long as not all packages are expected to build on ARM. Tracking patches in Bugzilla that fix build failures is a good idea, though. This allows maintainers to inspect patches and apply them. I guess once Fedora-ARM is completely working, all non-working packages should be tracked as mentioned in the wiki: http://fedoraproject.org/wiki/Architectures#Tracker_Bugs Regards Till pgppm11pMW9du.pgp Description: PGP signature ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] What is the best way to fix build issues with Fedora 13 RPMs?
On Tue, Mar 08, 2011 at 12:20:10PM +, Niels de Vos wrote: > I don's know what the best way would be to mark FTBFS bugs as ARM > specific. But we sure rely on the packagers for fixing the > build-issues for their package. > > Maybe there should be a FTBFS-ARM tracker-bug? Actually package maintainers are not expected to fix bugs for build-issues on secondary archs, except for accepting patches that fix them. Regards Till pgpZhbJLc1r4E.pgp Description: PGP signature ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] What is the best way to fix build issues with Fedora 13 RPMs?
On Sun, Mar 06, 2011 at 02:45:15PM +, Niels de Vos wrote: > it looks like not all Fedora 13 packages can be build on ARM yet. For > some packages there have been tickets opened at the Trac instance: > - https://fedorahosted.org/arm/report/1 > > I'd like to help out with building these packages, but am not a > 'proven packager' [1], so I can not fix the issues completely and rely > I'd like some advise on the best/efficient way forward. Any other > thoughts are also more than welcome! Submitting patches to Bugzilla is the recommended way for this. > Possibly I could request to become a proven packager [2], but I do not > know if fixing building ARM-packages is enough to get FESCo approve my > request. Even if you are a proven packager you should still ask the maintainer for approval of patches to avoid unwanted side-effects, but you can do the work to update the package. I do not know how much you already have contributed to Fedora to prove that you are a experienced packager. If you think it is not enough, you submit more patches using bugzilla for now and ask for provenpackager membership once you got more feedback from packagers or more patches accepted. In general helping to fix secondary arch build issues is a proper reason to become a proven packager. Btw. if there are packagers that agree to a patch you submitted but lack the time to update the package, you can ping me and I will help. Maybe this helps to speed up the patch approval. You might want to mention this possibility on the bug reports to get the packagers faster to agree. There are probably also other proven packagers here on the ARM list that will help with this. Regards Till pgpYcIRZfFqQf.pgp Description: PGP signature ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] What is the best way to fix build issues with Fedora 13 RPMs?
On Tue, Mar 08, 2011 at 10:07:46PM +, Gordan Bobic wrote: > On 03/08/2011 09:04 PM, Till Maas wrote: > > On Tue, Mar 08, 2011 at 10:01:02AM +, Gordan Bobic wrote: > >> Niels de Vos wrote: > >>> Hello all, > >>> > >>> it looks like not all Fedora 13 packages can be build on ARM yet. For > >>> some packages there have been tickets opened at the Trac instance: > >>> - https://fedorahosted.org/arm/report/1 > >>> > >>> I'd like to help out with building these packages, but am not a > >>> 'proven packager' [1], so I can not fix the issues completely and rely > >>> on the package maintainer or other proven packagers. What I am doing > >>> right now is filing bugs against the packages that can not be build on > >>> ARM. I'm including pointers to the issue and propose fixes, like: > >>> - Bug 682515 - libgda-4.1.4-1.fc13.src.rpm does not rebuild on Fedora 13 > >>> for ARM > >>> - Bug 682538 - geos-3.2.1-1.fc13.src.rpm does not build on Fedora-13 for > >>> ARM > >>> > >>> These bugs are blockers for the ARMTracker which make them easily > >>> findable: > >>> - > >>> https://bugzilla.redhat.com/showdependencytree.cgi?id=245418&hide_resolved=1 > >> > >> We're tracking build failures as bugs now? Really?? > > > > Tracking build failures is probably overkill as long as not all packages > > are expected to build on ARM. > > Aren't all the packages expected to build on ARM? Which ones aren't > expected to build? I do not have a list but as far as I understand the whole ARM infrastructure is not yet completed and not all packages have been tried to be build. There are packages that have e.g. circular dependencies and therefore do not build currently and need some manual intervention. Also for packages that have missing dependencies in ARM it is expected that they do not build currently, but they might once the dependencies are in the ARM repo. There is not much a packager can do about, therefore a bug report does not help to track anything. > > Tracking patches in Bugzilla that fix > > build failures is a good idea, though. This allows maintainers to > > inspect patches and apply them. > > > > I guess once Fedora-ARM is completely working, all non-working packages > > should be tracked as mentioned in the wiki: > > http://fedoraproject.org/wiki/Architectures#Tracker_Bugs > > That seems contradictory. Once it is completely working, that implies > all packages are working, in which case there's nothing to fix/track. I meant the time when Fedora-ARM provides a stable release or is ready to provide one including the infrastructure to provide updates and all packages that build are in sync with the primary archs or in other words: the only missing thing is to get all packages from the primary archs to build on Fedora-ARM. Regards Till pgpezxNeWAcVl.pgp Description: PGP signature ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Failure with Fedora21 and Cubieboard (the A10 one)
On Mon, Jan 26, 2015 at 01:20:25AM +0800, Daniel Veillard wrote: > I tried over and over following the instructions at > > https://fedoraproject.org/wiki/Architectures/ARM/F21/Installation#For_the_CubieBoard_v1_.28Allwinner_A10.29 The instructions worked for my CubieBoard without any problems in the week after Christmas. > Starts to worries me a lot since F19 is EOL'ed soon, I won't > have updates on my devices. Fedora 19 is already EOL. > What am I missing ? Maybe we can spot the error if you write exactly which commands you ran. Regards Till ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] Re: Fedora LiveUSB station - brainstorming
Hi, this is awesome. I also started to think about something similar myself - just a device to be able to let people write their USB device with. My main criteria for a system that can be used by visitors was that it supports USB3 to make flashing at as fast as possible. I found the ODROID-XU4 which is super expensive but has two USB3 ports. However last time I checked it required a binary blog from ODROID to operate and I heard that the fan might be a bit loud. However other problems with Fedora events prevented me from finishing build this and eventually I just a bought a new notebook with USB3 that I use on events to flash the visitors' USB devices. A cheap chromebook with USB3 might therefore be a good alternative as well. Kind regards Till ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@lists.fedoraproject.org
[fedora-arm] Re: Any update on suggested devices?
Hi, 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 this would be great. I have a few devices collecting dust because it was never clear whether they would be supported, happy to help with some testing if they are on the list or getting something that would be a key device long term. Would be great if there could be something not too expensive to setup an OpenShift cluster for demonstration purposes like https://pine64.com/product/clusterboard-with-7-sopine-compute-module-slots/?v=0446c16e2e66 Thanks Till ___ 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
