Hi arm SIG team,
as we are moving forward with Fedora 26 I would like to make sure we
have all the deliverables, which might or might not be blocking for
the release, identified on time. As such, I would like to ask you to
review the list of deliverables the arm SIG delivers for Fedora 26
release. The list is available on
In case you find any discrepancy in the list, feel free to correct it
or let me know and I will correct it then.
Thanks for your help and Best Regards,
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
Current rawhide fedora image is using xfs has a bit higher memory
requirements than btrfs so I've started thinking about migration of my
current image to new root fs on new card.
Looking on partition table on rawhide image served by fedora I see:
Device Boot Start End Sectors Size Id Type
/dev/mmcblk0p1 2048 61439 59392 29M c W95 FAT32 (LBA)
/dev/mmcblk0p2 * 61440 1060863 999424 488M 83 Linux
/dev/mmcblk0p3 1060864 2060287 999424 488M 82 Linux swap / Solaris
/dev/mmcblk0p4 2060288 15126527 13066240 6.2G 82 Linux swap / Solaris
Q1: for what is this fat32 first partition?
Q2: is it possible to install uboot files from /boot on btrfs? (on x86 and
grub it is no problem with this)
Q3: seems someone done porting of the grub to arm so why there is n grub2
package in fedora?
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH <http://lnkd.in/FXPWxH>*
im using fedora 25 on both a rasberrypi2 and a 3
I also have a ds1307 in the rasberrypi2 and it works fine.
however ive tried first a ds1307 in the rasberry pi 3 and now a ds3231
neither show up in i2cdetect -y 0 or 1 or 2
i get messages as follows in dmesg
dmesg | grep rtc
[ 5.730955] hctosys: unable to open rtc device (rtc0)
[ 22.881692] rtc-ds1307: probe of 2-0068 failed with error -5
[ 22.892945] rtc-ds1307: probe of 1-0068 failed with error -5
is there a problem with the pi3 and fedora25 and i2c
im also getting about 600 after being on less than 2 hours:
[ 1300.005255] i2c-bcm2835 3f805000.i2c: i2c transfer failed: 100
[ 1300.006707] i2c-bcm2835 3f805000.i2c: i2c transfer failed: 100
[ 1300.008158] i2c-bcm2835 3f805000.i2c: i2c transfer failed: 100
i2c_dev 16384 0
i2c_bcm2835 16384 0
if this is just something i need to wait for development , then thats fine, just want to be sure its not me.
I've problems with using GPIO from python. It just throws some memory
error and dumps. I'm not familiar with C/dumps and so on, so I did not
yet start to try to get details of it.
One thing I noticed is different content of /proc/cpuinfo between
Raspbian and Fedora 25.
Thus my interpretation is that if Fedora reports a bit different
hardware then some calls to some methods might fail.
Am I missing some step that should be done after install?
It could be some mutation of FAQ: about support for HATs.
But I would love clear statement, which would point that it just does
not work out-of-the-box and there is/isn't way to manually fix it for
someone who is not C/kernel developer.
As for me support for HATs and support to set GPIO pin 18 to HIGH state
are slightly different things. But maybe they have same root cause.
We have been working on a service to create notifications when people add or
remove ExcludeArch/ExclusiveArch to packages. at the moment they get sent to
pingu. We can easily send to static email addresses. but we need to know where
to send them.
Longer term I want to get the notifications put into FMN where the arch
teams will be subscribed to messages just relating to their arches. If someone
wanted to work on hat it would be awesome.
For right now we need to know where to send them. a good starting point would
be the arch lists or the overarching one at secondary(a)lists.fp.o or we could
create a new list architecture-excludes(a)lists.fp.o or perhaps there is a
better option out there? I wanted to get the discussion started. I personally
think that a dedicated list is the best option to ensure none of the lists for
Alternative Arches gets filled up with noise.