Re: [fedora-arm] ExcludeArch tracker doesn't appear to be effective
Of the ones I know about ...
avgtime
Written in the 'D' language which doesn't have support for ARM upstream.
grub2
ARM (32 bit) boots using u-boot. Aarch64 machines will boot using
grub2 (or is that grub2-efi? - you know better than I do :-)
hfsplus-tools
As discussed in this thread.
ocaml-cil
ocaml-gsl
There are mature 32 bit and 64 bit ARM native backends for the OCaml
compiler. I've worked on fixing some problems in both.
As for these two packages, CIL is actually fixed upstream, it just
needs to go into the Fedora package (see RHBZ#994968). GSL depends on
a C library that contains lots of x86 assembler, and so basically
won't work without a lot of porting which no one has done yet. There
is no BZ for this one, which there obviously should be.
root
Discussed on this thread already.
zfs-fuse
This is interesting because it's another package where libguestfs has
to %ifnarch %{arm} because the package is missing on ARM.
The reason it doesn't build is because this package uses an internal
library to provide atomic ops, and this library hasn't been ported to
ARM assembler (although there is a fallback path that uses
pthread_mutex(!)).
There is a BZ (RHBZ#996728) but it is not listed in the spec file.
So, two conclusions from this:
1) People are very bad at following policy here. The majority of the
packages that are marked ExcludeArch: arm are not in the tracker bug,
and most of those don't appear to have a bug filed at all.
2) The rate at which things are being fixed appears to be uninfluenced
by (1) - the number of bugs on the tracker may have increased, but the
number of packages actually excluded on ARM hasn't. This means that I
was grossly overestimating how many packages were broken. I made an
assertion without collecting accurate data first, and came to the wrong
conclusion. I apologise for that.
But also:
(3) Out of 15000 packages, only about 100 don't build on ARM, and
there are at most 50 missing bugs to fully comply with policy.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [fedora-arm] ExcludeArch tracker doesn't appear to be effective
I pulled git and have the following for ExclusiveArch: %{arm}:
joystick-support
While ARM doesn't have traditional joystick ports there have been some
people hook them up via GPIO and the like, enabled.
mcollective-qpid-plugin
perl-qpid
These were both legacy hangover from before qpid-gcc was fixed which
it has been for some time, now built on rawhide.
Both would likely not have been missed if there was appropriate BZ :-)
Peter
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [fedora-arm] ExcludeArch tracker doesn't appear to be effective
On Thu, Jun 12, 2014 at 11:58:55 +0100,
Peter Robinson pbrobin...@gmail.com wrote:
I pulled git and have the following for ExclusiveArch: %{arm}:
joystick-support
While ARM doesn't have traditional joystick ports there have been some
people hook them up via GPIO and the like, enabled.
Would these likely end up in joydev.ko or analog.ko? If there is some other
module that would be used, I'd like to add it to the list.
joystick-support just makes sure the modules used for joysticks and
gamepads are included (kernel-modules-extra is pulled in if needed) and
loaded during boot by default. In theory people could do this manually
without too much work, but the idea was to make it dead simple.
floppy-support works the same way, though currently floppy.ko is in
kernel-modules. (But I expect it to move to kernel-modules-extra
eventually.)
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [fedora-arm] ExcludeArch tracker doesn't appear to be effective
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 12 Jun 2014 11:39:00 +0100 Richard W.M. Jones rjo...@redhat.com wrote: Of the ones I know about ... avgtime Written in the 'D' language which doesn't have support for ARM upstream. grub2 ARM (32 bit) boots using u-boot. Aarch64 machines will boot using grub2 (or is that grub2-efi? - you know better than I do :-) its using grub2-efi the grub2 binary is grubaa64.efi -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTmbW5AAoJEH7ltONmPFDRv7cP/R9/+ch7QZsmO78q+V995dlI Ftjduje5c3ZC3QYstMIns18wkvkrNmI5pSuQHMVVpajC2aRFAxuoXYXP8WLnjC2S fU++TrFz+n3j81Hed0dZ5w1KOjHHqaR8fpPOuo1zX8JVBLTF9JQkP8Oe54SCSIZz 1la/eF4TepQ+7QzYBjTqEsUySKL8UoNMcb3m4ZMSYq+s3Wi+MksVy30TDh+Dd+hK limHase5HTgjSA0pma8WjcS6NKYOrP9fmH45e5xl2wcTJodwxrop3IESW7QMdDZN ZqSOl0V3zRGDWGoVZt4CdhOB7RNK0jdpIL0SbNVHlr6k7m9+zmSNScwvEbv1oZ8N 41ZPtC4C2bjZwWJL3fgPLCWKZN2UqaFZZyDtWNt5b5UOM9K6FMlqMRTC4IIFDAV0 plO8TnnTcUmHhCHz8EXjG5EpSrjXLL0o0rSrxIRx2k3a1LS01Tq/IDWkbdivzpWK aR/MgjEjMXEzj1w1AnYekM+9lLWUKtKSrzrjlREvQTJObc8xcp7vKpX0oPT+MMu1 hjK03AVw+cp+NDzrCcRYbd75YPqqDOUa333XMC6oyw15rzqv4SCa5kGXVM0wkjAP 4aWSqYgm4IB2NM1jCjY90qs2N7SktaenDD/EMhbgRkKQ9903wXYOa2yqijWdaEK5 Y/eH465VG+fsCwoSuXVN =Sleu -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [fedora-arm] ExcludeArch tracker doesn't appear to be effective
On Thu, Jun 12, 2014 at 11:39:00AM +0100, Richard W.M. Jones wrote: grub2 ARM (32 bit) boots using u-boot. Aarch64 machines will boot using grub2 (or is that grub2-efi? - you know better than I do :-) This one's purely excluded from 32-bit ARM. The source package is grub2 regardless of the firmware interface used. (3) Out of 15000 packages, only about 100 don't build on ARM, and there are at most 50 missing bugs to fully comply with policy. I didn't go through the list of FTBFS to figure out whether there are other cases, but yeah, the situation certainly isn't dreadful. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [fedora-arm] ExcludeArch tracker doesn't appear to be effective
On Tue, Jun 10, 2014 at 09:32:54PM +0100, Matthew Garrett wrote: I don't think the current state of the ARM port is good enough. Are you actually using the ARM ports? I'm using the 32 bit ARM primary on two machines and the aarch64 secondary on a third, and they work well. If there are specific packages which don't work for you, then please let us know. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [fedora-arm] ExcludeArch tracker doesn't appear to be effective
On Wed, Jun 11, 2014 at 12:07:23AM +0200, drago01 wrote: On Tue, Jun 10, 2014 at 11:52 PM, Peter Robinson pbrobin...@gmail.com wrote: [...] So moving on from that why don't you feel comfortable pointing to the ARM port? The question wasn't really directed at me but adding my 2 cents ... basically on x86(_64) hardware I can point people at fedora and most of the time it will work. As for ARM if you get a random arm hardware chances are that it is simply not supported or needs some manual hacks to get used. That's not really a fedora specific problem but it makes ARM more of a gimmick to me ... until hardware vendors catch up. As you say, mostly this is the nature of the platform. 32 bit ARM hardware is not self-describing, and not at all uniform (unlike PCs). There is no BIOS. There's no standard text display or serial port. This ought to improve greatly with 64 bit ARM, where Red Hat are pushing for everything to support UEFI booting and ACPI for hardware description. A single upstream open source kernel should [eventually] be able to boot on every aarch64 machine, even ones that have not been seen before. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [fedora-arm] ExcludeArch tracker doesn't appear to be effective
On Wed, Jun 11, 2014 at 09:14:24AM +0100, Richard W.M. Jones wrote: This ought to improve greatly with 64 bit ARM, where Red Hat are pushing for everything to support UEFI booting and ACPI for hardware description. A single upstream open source kernel should [eventually] be able to boot on every aarch64 machine, even ones that have not been seen before. UEFI should be an improvement in this respect, but there's really no fundamental benefit to using ACPI rather than DTB for hardware description. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [fedora-arm] ExcludeArch tracker doesn't appear to be effective
On Wed, Jun 11, 2014 at 10:14 AM, Richard W.M. Jones rjo...@redhat.com wrote: On Wed, Jun 11, 2014 at 12:07:23AM +0200, drago01 wrote: On Tue, Jun 10, 2014 at 11:52 PM, Peter Robinson pbrobin...@gmail.com wrote: [...] So moving on from that why don't you feel comfortable pointing to the ARM port? The question wasn't really directed at me but adding my 2 cents ... basically on x86(_64) hardware I can point people at fedora and most of the time it will work. As for ARM if you get a random arm hardware chances are that it is simply not supported or needs some manual hacks to get used. That's not really a fedora specific problem but it makes ARM more of a gimmick to me ... until hardware vendors catch up. As you say, mostly this is the nature of the platform. 32 bit ARM hardware is not self-describing, and not at all uniform (unlike PCs). There is no BIOS. There's no standard text display or serial port. Yeah I know but it still makes it inferior to x86_64 ... debian seems to be in a better shape simply because it supported ARM for a long time (i.e there builds for a larger set of boards). I have never bough an ARM board (just got them through various ways) the two that I still have do not work on fedora. One can be made to work with some effort while the I don't know what the state of the other one is. This ought to improve greatly with 64 bit ARM, where Red Hat are pushing for everything to support UEFI booting and ACPI for hardware description. A single upstream open source kernel should [eventually] be able to boot on every aarch64 machine, even ones that have not been seen before. Yeah looking forward to that. The current system does not scale for a general purpose distribution. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [fedora-arm] ExcludeArch tracker doesn't appear to be effective
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 11 Jun 2014 18:03:35 +0200 drago01 drag...@gmail.com wrote: On Wed, Jun 11, 2014 at 10:14 AM, Richard W.M. Jones rjo...@redhat.com wrote: On Wed, Jun 11, 2014 at 12:07:23AM +0200, drago01 wrote: On Tue, Jun 10, 2014 at 11:52 PM, Peter Robinson pbrobin...@gmail.com wrote: [...] So moving on from that why don't you feel comfortable pointing to the ARM port? The question wasn't really directed at me but adding my 2 cents ... basically on x86(_64) hardware I can point people at fedora and most of the time it will work. As for ARM if you get a random arm hardware chances are that it is simply not supported or needs some manual hacks to get used. That's not really a fedora specific problem but it makes ARM more of a gimmick to me ... until hardware vendors catch up. As you say, mostly this is the nature of the platform. 32 bit ARM hardware is not self-describing, and not at all uniform (unlike PCs). There is no BIOS. There's no standard text display or serial port. Yeah I know but it still makes it inferior to x86_64 ... debian seems to be in a better shape simply because it supported ARM for a long time (i.e there builds for a larger set of boards). Debian is in the state its in because they build a bunch of different kernels from different sources, we have chosen not to do that but take the longer better road to use a unified kernel and support systems in a unified manner. We have been working upstream in u-boot to make things more standardised and make supporting new arm systems much much simpler. its starting to pay off with much more supportable hardware and systems that will just work in a standard fashion. debian chose to hack in support for each different system in their installer and setup/management tools. which is something we chose not to do as its really not a supportable path. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTmJoXAAoJEH7ltONmPFDRrBsQAKPZWL/5BoQLHe3jigTZtwml N/sM0n6OgSKb28pA8d1nV1hHrKYKfTL/wFW29OL10MQAAZaTyOuQxznWzOh7yxKc NJUpbF3MVnNkX6DvJ4/HSzzF0Tb1C7BGX2vccM1+0ZFZtdTb2s6+GZ0tOKNVFD20 jT67t/DATnY8WtwL5HvuStgO5f6G0cpQerpDyCgbfBWKDQT270VxzFL/AIGHYhPx byvuOiROPqJAoHuJ9csPSKF+l5/b5S38bCYi6a2BTS06kfHmof0ct+NfIqrk11+3 ACTolPnN0Hcy2BRXglD+v4XC/KB1fCFfpb99muup7OE2fSqG0/u6yYwVEDdxWw1a j7c7YeNFSnJ1UGt+v5iUpGp97gdThuc727qb15YNhLd4nniBdShn63NxOuEk68yA wgfSd0x+dvj1aZRnYo4SMhXQOErUjNtFQYTASrkp/Qs2R6Zsza0+wYwqhFG2FZDQ ybLcwVAJthDkhAcz0Bu0xak9BQmb8z7hgggsbZWwxP04qmnG3msoTw7icVLni6UI yeaJOiKBS/7t1F9JmKdBE5susryFMYm0ESVSrOAVbKVS190IzcCxfOKGHRsPM3b/ xE8FG0wZAWgwFSgU7EZPGWQnQH1ABNlBkuTcO7Gt6+BHYo0+X+gI/LuQwAikon4g dN3tQNAohUs9kHhYheOE =33Vh -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [fedora-arm] ExcludeArch tracker doesn't appear to be effective--- how to improve ARM Fedora
On 06/10/2014 04:12 PM, Peter Robinson wrote: So at the moment there's around 15,000 source packages in Fedora mainline and you're getting depressed over exactly 24 of them? I'm not sure how 24 packages is providing a inconsistent experience. Fedora simply must support ARM because it ensures future viability. The progress in ARM hardware platforms is amazing---ARM device sales overtook x86 in 2010 [1] and of course the total number of ARM processors in the wild exceeds x86 by orders of magnitude. Even if we limit ourselves to 'computer' devices, ARM is significant and the numbers can only change further in ARM's favor. Limiting Fedora to x86 would condemn it to a relative or maybe even absolute gradual decline. ARM/x86 parity in Fedora was an important and correct decision, and the ARM team did great work fixing the remaining problems. ARM support came from behind, so of course there are problems remaining. My primary interest is the embedded domain---Beaglebone [2] and other tiny ARM platforms, which will arguably form the basis for the new interconnected infrastructure awkwardly called the Internet of Things (IoT). Fedora is my favorite environment, so I would like it to flourish in this space, but I have to say that Debian is a strong contender---specifically, BBB community seems to have switched to it when the original Angstrom-based software load ran out of steam. Fedora is available, but is a little bit of a work in progress [3] I think Fedora community should be aware of that and should support ARM effort even more. It seems to me that ARM platform fragmentation is a problem, due to the lack of standards in peripherals as well as boot environment. Even the Fedora build infrastructure is tricky and, as Kevin pointed out, it lags in performance---which reminds me that Linaro recently chose stripped Chromebooks 2 as its compile farm [4]. I appreciate this discussion because it focuses the need to collect and address the issues that hold ARM Fedora back. I can think of these: - fixing packages that FTBFS on ARM: - engaging packagers so that everyone cares about the issue - giving them tools to test-build with reasonable speed - keeping track of problems and working solutions - boot environment - work on a truly unified booting scheme that's as easy as x86 'stick the CD/USB in, press the button' - or at least collect enough platform-specific recipes - build environment - making sure the build environment is comprehensive and high-performance - include the most popular platforms (chromebooks, beaglebone, olimex) [1] http://www.wired.com/2012/08/ff_intel/all/ [2] BeagleBone Black (BBB) is a mint-can sized 1GHz, 512MB RAM, 4GB flash, USB/Ethernet/HDMI fully functional computer platform for the grand total of $50. It has excellent I/O interfacing capabilities, and is used for remote sensing, 3D printing and other CNC systems, etc: http://beagleboard.org/Products/BeagleBone+Black [3] http://beagleboard.org/fedora http://fedoraproject.org/wiki/Architectures/ARM/F20/Installation#For_the_BeagleBone_Black [4] http://www.systemcall.org/blog/2014/06/trashing-chromebooks/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [fedora-arm] ExcludeArch tracker doesn't appear to be effective--- how to improve ARM Fedora
Once upon a time, Przemek Klosowski przemek.klosow...@nist.gov said: Fedora simply must support ARM because it ensures future viability. The progress in ARM hardware platforms is amazing---ARM device sales overtook x86 in 2010 [1] and of course the total number of ARM processors in the wild exceeds x86 by orders of magnitude. Even if we limit ourselves to 'computer' devices, ARM is significant and the numbers can only change further in ARM's favor. Limiting Fedora to x86 would condemn it to a relative or maybe even absolute gradual decline. As has been pointed out before, sheer cores sold is a meaningless thing. MIPS and PPC outsold x86 before, and that obviously didn't condemn Fedora to irrelevance. How many ARM devices are supported by Fedora 20, as compared to the number of x86 devices supported by Fedora 20? The ARM market targeted by Fedora is very small compared to the number of x86 machines that can run F20. -- Chris Adams li...@cmadams.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [fedora-arm] ExcludeArch tracker doesn't appear to be effective--- how to improve ARM Fedora
On 06/11/2014 03:09 PM, Chris Adams wrote: Once upon a time, Przemek Klosowski przemek.klosow...@nist.gov said: Fedora simply must support ARM because it ensures future viability. The progress in ARM hardware platforms is amazing---ARM device sales overtook x86 in 2010 [1] and of course the total number of ARM processors in the wild exceeds x86 by orders of magnitude. Even if we limit ourselves to 'computer' devices, ARM is significant and the numbers can only change further in ARM's favor. Limiting Fedora to x86 would condemn it to a relative or maybe even absolute gradual decline. As has been pointed out before, sheer cores sold is a meaningless thing. MIPS and PPC outsold x86 before, and that obviously didn't condemn Fedora to irrelevance. Right, of course, and I tried to convey that it's only computers or devices that count. MIPS and PPC was never that successful for those, and ARM seems to be. I installed Linux on Android tablets, and it's useful, and will be even more useful when such devices start showing up in appliances. Android is great for a phone but not so great when you want a heavily customized system. By the way, I installed Debian because I had no idea how to start with Fedora, even though I know Fedora better and prefer it. My next project is a 7, $40 Aztek tablet: I will try to put Fedora on it! How many ARM devices are supported by Fedora 20, as compared to the number of x86 devices supported by Fedora 20? The ARM market targeted by Fedora is very small compared to the number of x86 machines that can run F20. That's a circular argument: few devices are supported because the support is weak. I believe that ARM is worth supporting in the long run and Fedora ARM should at least catch up to and then exceed Debian. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [fedora-arm] ExcludeArch tracker doesn't appear to be effective
On Tue, Jun 10, 2014 at 11:29:41PM +0100, Matthew Garrett wrote:
Ok, I was entirely unaware of that, and it does change things. Thanks
for letting me know. I'll look into whether it's practical to generate a
list of all the existing ExcludeArch packages and automatically check
whether they have tracker bugs filed - does that seem helpful? It
*would* be good to have meaningful metrics on this, but I don't want
there to be excessive process overhead.
I pulled git and have the following for ExclusiveArch: %{arm}:
gda
Agda-stdlib
amplab-tachyon
avgtime
avogadro
avro
clpeak
compat-gcc-32
compat-gcc-34
cqrlog
derelict
dustmite
dyninst
elk
floppy-support
ghc-ForSyDe
gl3n
glusterfs-hadoop
grub2
grub-customizer
gtkd
hadoop
hbase
hfsplus-tools
hive
hledger
jogl
joystick-support
keepass
ldc
liveusb-creator
Macaulay2
mcollective-qpid-plugin
numactl
numad
numatop
nwchem
ocaml-cil
ocaml-gsl
patchelf
perftest
perl-Alien-ROOT
perl-qpid
perl-SOOT
pig
pure
pure-glpk
pyode
qt-creator
root
rootplot
sbt
scilab
seamonkey
solr
sparkleshare
sys_basher
tango
urjtag
wine-mono
zfs-fuse
That's 60. In addition, the following packages are ExclusiveArch: in
such a way that ARM is left out but PPC support is claimed:
gprolog
mono-bouncycastle
nant
pvs-sbcl
xsupplicant
for a total of 65. Of those:
compat-gcc32
compat-gcc34
floppy-support
grub
grub-customizer
joystick-support
liveusb-creator
numactl
numad
numatop
seem entirely legitimate. That's 55 packages, several of which can be
blamed on a small number of missing dependencies.
That's git master. In F20 the number is about the same, which I'm going
to assume means that there were some fixes and around the same number of
excludes added.
(This ignores packages that are ExclusiveArch: %ix86 x86_64 because
that's probably unfair - if the maintainer genuinely believes that it
makes sense for the package to be x86 only then that's fair)
So, two conclusions from this:
1) People are very bad at following policy here. The majority of the
packages that are marked ExcludeArch: arm are not in the tracker bug,
and most of those don't appear to have a bug filed at all.
2) The rate at which things are being fixed appears to be uninfluenced
by (1) - the number of bugs on the tracker may have increased, but the
number of packages actually excluded on ARM hasn't. This means that I
was grossly overestimating how many packages were broken. I made an
assertion without collecting accurate data first, and came to the wrong
conclusion. I apologise for that.
I'll look at filing bugs against packages that don't appear to have bugs
filed, and I'll attempt to add them to the tracker where they exist but
aren't listed.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [fedora-arm] ExcludeArch tracker doesn't appear to be effective
On Wed, Jun 11, 2014 at 5:03 PM, Matthew Garrett mj...@srcf.ucam.org wrote: That's 60. In addition, the following packages are ExclusiveArch: in such a way that ARM is left out but PPC support is claimed: gprolog mono-bouncycastle nant pvs-sbcl xsupplicant Oh, sbcl grew ARM support yesterday. Nice! I will try to get pvs-sbcl built and tested for ARM soon. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [fedora-arm] ExcludeArch tracker doesn't appear to be effective
On Tue, Jun 10, 2014 at 7:28 PM, Matthew Garrett mj...@srcf.ucam.org wrote: https://bugzilla.redhat.com/show_bug.cgi?id=485251 is depressing. Nine bugs have been closed - of these, one is a review request that was dropped, two were incorrectly closed after an ExcludeArch was added and one was closed as a duplicate. Further, one bug was just unsubscribed from the tracker after tests were disabled. We've correctly fixed *five* packages that have been flagged as FTBFS on ARM. At this rate of fixing, and given the rate at which new bugs are added, ARM will never build the entire archive. Fedora is supposed to provide a consistent experience across primary architectures. Having a subset of our packages fail to build on ARM means that's not true, and the current state of affairs clearly violates point 8 of the architecture promotion requirements. How can we fix this? So at the moment there's around 15,000 source packages in Fedora mainline and you're getting depressed over exactly 24 of them? I'm not sure how 24 packages is providing a inconsistent experience. In some cases the maintainer of the package hasn't bothered to close the bug when support was added, in some cases ARM was added incorrectly. For example just before mass rebuild we added Ada support which closed out around 2 dozen other packages we didn't build prior. We actively fix bugs that come up but there's some there that just currently don't make sense such as the ovirt-node package because oVirt manager doesn't support ARM virtualisation (it's just added PPC, it's first non x86 architecture, support as of the 3.4 release). Some of these are because the upstream projects either refuse to support ARM or it's using languages that aren't supported on ARM. In the case of the mono packages in that it would be supported if the mono stack was actively maintained in Fedora mainline in general. There was a proposal for F-21 to update mono to the latest 3.x release but while I've been watching it awaiting for it to land so we can test it on ARM it's failed to materialise to date in mainline. Ultimately I fail to see how missing 20 odd packages out of 15,000 odd fails to provide a consistent experience across primary architectures so if there's something more specific and constructive you'd like to provide it would be useful or is this just a random rant because your bored? Ultimately we've been working hard to provide as consistent environment on ARM as possible and improving all the time and all you seem to do is randomly come in Magpie style and shit on something without any other visible involvement in the ARM process or community or any context and pick on something of random like a bully. If you've got constructive criticism feel free to engage properly to assist us in improving and coming up to your exacting standards but this means of bullying tactics isn't the way to do it. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [fedora-arm] ExcludeArch tracker doesn't appear to be effective
On Tue, Jun 10, 2014 at 09:12:35PM +0100, Peter Robinson wrote: So at the moment there's around 15,000 source packages in Fedora mainline and you're getting depressed over exactly 24 of them? I'm not sure how 24 packages is providing a inconsistent experience. In some cases the maintainer of the package hasn't bothered to close the bug when support was added, in some cases ARM was added incorrectly. For example just before mass rebuild we added Ada support which closed out around 2 dozen other packages we didn't build prior. What's depressing is the trend, not the absolute count. I'd expected it to head rapidly towards zero after the first release, but instead it's still growing. Ultimately I fail to see how missing 20 odd packages out of 15,000 odd fails to provide a consistent experience across primary architectures so if there's something more specific and constructive you'd like to provide it would be useful or is this just a random rant because your bored? Anyone who has a usecase that relies on one of those packages will have an inconsistent experience if they attempt to reproduce it on ARM. That's harmful. It makes us look bad. It gives the appearance that we're willing to release a worse product simply in order to claim ARM support. Ultimately we've been working hard to provide as consistent environment on ARM as possible and improving all the time and all you seem to do is randomly come in Magpie style and shit on something without any other visible involvement in the ARM process or community or any context and pick on something of random like a bully. If you've got constructive criticism feel free to engage properly to assist us in improving and coming up to your exacting standards but this means of bullying tactics isn't the way to do it. I don't think the current state of the ARM port is good enough. That's not a reflection on the people involved. That's not a criticism of the amount of effort that's been made. I just want to know how we can get from where we currently are to where we want to be. Individual package maintainers seem happy to just add an ExcludeArch, maybe file a bug against upstream and then forget about the issue. Given a lack of direct incentive for them to care about ARM, that's not terribly surprising. What can we do about that? Is the only realistic answer to find the resources to have a team to hunt down and fix portability issues that are sufficiently far from the core that the existing ARM community can't justify the time? And if so, is there any way we can make that happen? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [fedora-arm] ExcludeArch tracker doesn't appear to be effective
So at the moment there's around 15,000 source packages in Fedora mainline and you're getting depressed over exactly 24 of them? I'm not sure how 24 packages is providing a inconsistent experience. In some cases the maintainer of the package hasn't bothered to close the bug when support was added, in some cases ARM was added incorrectly. For example just before mass rebuild we added Ada support which closed out around 2 dozen other packages we didn't build prior. What's depressing is the trend, not the absolute count. I'd expected it to head rapidly towards zero after the first release, but instead it's still growing. Is it? Where's your proof? From the patches and dealings with it personally that's not my understanding and if it is the case it's not due to the ARM team but because packagers aren't following the packaging process and in this case we actively fix them when we're made aware of the incident. Ultimately I fail to see how missing 20 odd packages out of 15,000 odd fails to provide a consistent experience across primary architectures so if there's something more specific and constructive you'd like to provide it would be useful or is this just a random rant because your bored? Anyone who has a usecase that relies on one of those packages will have an inconsistent experience if they attempt to reproduce it on ARM. That's harmful. It makes us look bad. It gives the appearance that we're willing to release a worse product simply in order to claim ARM support. And if they engage with us about that experience we do our best to deal with them where possible. There's a few cases where I'm aware of that we don't package because the HW is actively not supported on ARM or similar style cases. In those cases I would argue that it's better not to build the packages as arguably no experience is better experience than a bad experience especially if there's potential of issues that offer a worse experience, hardware breakage or data corruption. The fact is that the x86 and ARM use cases don't match up 100% and I don't see the point in trying to glue those together 100% for the sake of a check box. Ultimately we've been working hard to provide as consistent environment on ARM as possible and improving all the time and all you seem to do is randomly come in Magpie style and shit on something without any other visible involvement in the ARM process or community or any context and pick on something of random like a bully. If you've got constructive criticism feel free to engage properly to assist us in improving and coming up to your exacting standards but this means of bullying tactics isn't the way to do it. I don't think the current state of the ARM port is good enough. That's not a reflection on the people involved. That's not a criticism of the amount of effort that's been made. I just want to know how we can get from where we currently are to where we want to be. Well why didn't you say that from the start rather than coming in and bullying the people actively involved and make them feel like the massive effort myself and many others have been putting in is useless and a waste of time. Don't be a Magpie Board Member and fly in and shit over everything and than fly awau with no concept of what's happening below. Every time you've had any attempt at opinion that's the way you've done it and all you do is get all our backs up and make the problem worse rather than better. Individual package maintainers seem happy to just add an ExcludeArch, maybe file a bug against upstream and then forget about the issue. Given a lack of direct incentive for them to care about ARM, that's not terribly surprising. What can we do about that? Is the only realistic answer to find the resources to have a team to hunt down and fix portability issues that are sufficiently far from the core that the existing ARM community can't justify the time? And if so, is there any way we can make that happen? I'm not sure I agree with your outline here, you've given no real concrete examples here. I agree there's no real incentive but there's over 15,000 source packages in Fedora and there's less than 100 (last time I looked, unfortunately there's no easy way off checking this without downloading the entire src.rpms or checking out all 15K git repos) or so excluded from ARM and the vast majority of those are due to HW support. There's some like D where upstream has yet to port the stack. I'm sure there's others I'm unaware of but it's not because of the ARM team but rather the packager following procedures or engaging us for assistance. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [fedora-arm] ExcludeArch tracker doesn't appear to be effective
On Tue, Jun 10, 2014 at 09:49:58PM +0100, Peter Robinson wrote: What's depressing is the trend, not the absolute count. I'd expected it to head rapidly towards zero after the first release, but instead it's still growing. Is it? Where's your proof? From the patches and dealings with it personally that's not my understanding and if it is the case it's not due to the ARM team but because packagers aren't following the packaging process and in this case we actively fix them when we're made aware of the incident. In the past 6 months, 6 bugs added, 2 bugs closed - https://bugzilla.redhat.com/show_activity.cgi?id=485251 . Anyone who has a usecase that relies on one of those packages will have an inconsistent experience if they attempt to reproduce it on ARM. That's harmful. It makes us look bad. It gives the appearance that we're willing to release a worse product simply in order to claim ARM support. And if they engage with us about that experience we do our best to deal with them where possible. There's a few cases where I'm aware of that we don't package because the HW is actively not supported on ARM or similar style cases. In those cases I would argue that it's better not to build the packages as arguably no experience is better experience than a bad experience especially if there's potential of issues that offer a worse experience, hardware breakage or data corruption. The fact is that the x86 and ARM use cases don't match up 100% and I don't see the point in trying to glue those together 100% for the sake of a check box. Where there's reliance on specific hardware functionality that's absent then yes, absolutely, there's no benefit in building the packages. Figuring out how to communicate that to users isn't an entirely solved problem, but with luck nobody's actually buying ARM hardware with unrealistic expectations of its functionality. But I can't find any examples of those in the tracker. They all seem to be cases where packages are either missing dependencies, take too long to build or are just missing support. They're code. We can fix them. I don't think the current state of the ARM port is good enough. That's not a reflection on the people involved. That's not a criticism of the amount of effort that's been made. I just want to know how we can get from where we currently are to where we want to be. Well why didn't you say that from the start rather than coming in and bullying the people actively involved and make them feel like the massive effort myself and many others have been putting in is useless and a waste of time. Don't be a Magpie Board Member and fly in and shit over everything and than fly awau with no concept of what's happening below. Every time you've had any attempt at opinion that's the way you've done it and all you do is get all our backs up and make the problem worse rather than better. I'm genuinely sorry if I gave the impression of bullying here. I want to feel comfortable pointing at the ARM port as an equal to the x86_64 one. I don't feel entirely comfortable doing so at the moment, and the current process doesn't seem to be getting us to the point where I would be. Individual package maintainers seem happy to just add an ExcludeArch, maybe file a bug against upstream and then forget about the issue. Given a lack of direct incentive for them to care about ARM, that's not terribly surprising. What can we do about that? Is the only realistic answer to find the resources to have a team to hunt down and fix portability issues that are sufficiently far from the core that the existing ARM community can't justify the time? And if so, is there any way we can make that happen? I'm not sure I agree with your outline here, you've given no real concrete examples here. I agree there's no real incentive but there's over 15,000 source packages in Fedora and there's less than 100 (last time I looked, unfortunately there's no easy way off checking this without downloading the entire src.rpms or checking out all 15K git repos) or so excluded from ARM and the vast majority of those are due to HW support. There's some like D where upstream has yet to port the stack. I'm sure there's others I'm unaware of but it's not because of the ARM team but rather the packager following procedures or engaging us for assistance. The quantity of the archive that's built and working on ARM so far is a testament to the amount of effort that the ARM community have put into this port. The question is how to finish that. All I'm saying here is that the current approach of filing bugs doesn't appear to be resulting in people actually fixing their packages. It's unreasonable to expect you to do all of it. So what do we do? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct:
Re: [fedora-arm] ExcludeArch tracker doesn't appear to be effective
On Tue, Jun 10, 2014 at 10:20 PM, Matthew Garrett mj...@srcf.ucam.org wrote: On Tue, Jun 10, 2014 at 09:49:58PM +0100, Peter Robinson wrote: What's depressing is the trend, not the absolute count. I'd expected it to head rapidly towards zero after the first release, but instead it's still growing. Is it? Where's your proof? From the patches and dealings with it personally that's not my understanding and if it is the case it's not due to the ARM team but because packagers aren't following the packaging process and in this case we actively fix them when we're made aware of the incident. In the past 6 months, 6 bugs added, 2 bugs closed - https://bugzilla.redhat.com/show_activity.cgi?id=485251 . If you're going on just the bug tracker possibly but there's a lot of stuff we fix and enhance that doesn't even make the that tracker, the Ada stuff I mentioned earlier is but one example. Rightly or wrongly it's not the canonical source of information. For example if I discover an exclude arch I'll generally just go and fix it rather than spending the time to open a bug, fix it myself and then close it myself. Just go and read the rawhide reports. If that's what you want us to do to give a warm fuzzy feeling of progress I don't see it as a time effective agile way of necessarily dealing with it. Feel free to suggest alternatives :-) Anyone who has a usecase that relies on one of those packages will have an inconsistent experience if they attempt to reproduce it on ARM. That's harmful. It makes us look bad. It gives the appearance that we're willing to release a worse product simply in order to claim ARM support. And if they engage with us about that experience we do our best to deal with them where possible. There's a few cases where I'm aware of that we don't package because the HW is actively not supported on ARM or similar style cases. In those cases I would argue that it's better not to build the packages as arguably no experience is better experience than a bad experience especially if there's potential of issues that offer a worse experience, hardware breakage or data corruption. The fact is that the x86 and ARM use cases don't match up 100% and I don't see the point in trying to glue those together 100% for the sake of a check box. Where there's reliance on specific hardware functionality that's absent then yes, absolutely, there's no benefit in building the packages. Figuring out how to communicate that to users isn't an entirely solved problem, but with luck nobody's actually buying ARM hardware with unrealistic expectations of its functionality. But I can't find any examples of those in the tracker. They all seem to be cases where packages are either missing dependencies, take too long to build or are just missing support. They're code. We can fix them. Are you offering to do so? For example some time ago I approached one of the root maintainers (comes out of CERN I believe) and they said they didn't see the point nor have the time to maintain anything other than x86 at this time. Should we fork it and support it just to say we're feature complete with x86 just because it's code? Well maybe, but I'm not sure in that case it would add value to the distro for the expenditure of time and we've had exactly zero enquires about it (and it's 3 dependencies in the tracker). In the case of Hadoop there might possibly be value (and in later releases the issues might even have been fixed) but again we've had no queries and so we've focused on things people want. In the case of Ada we had some requests for support since F-20 was released so we've added that for F-21. I don't think the current state of the ARM port is good enough. That's not a reflection on the people involved. That's not a criticism of the amount of effort that's been made. I just want to know how we can get from where we currently are to where we want to be. Well why didn't you say that from the start rather than coming in and bullying the people actively involved and make them feel like the massive effort myself and many others have been putting in is useless and a waste of time. Don't be a Magpie Board Member and fly in and shit over everything and than fly awau with no concept of what's happening below. Every time you've had any attempt at opinion that's the way you've done it and all you do is get all our backs up and make the problem worse rather than better. I'm genuinely sorry if I gave the impression of bullying here. I want to feel comfortable pointing at the ARM port as an equal to the x86_64 one. I don't feel entirely comfortable doing so at the moment, and the current process doesn't seem to be getting us to the point where I would be. Well you need to engage with us better. Every time you make an appearance it appears to us all it's just to bully us. People genuinely shudder when your nick appears on on the channel and I've had 3 people thank me for
Re: [fedora-arm] ExcludeArch tracker doesn't appear to be effective
On Tue, Jun 10, 2014 at 10:37 PM, Adam Goode a...@spicenitz.org wrote: I seem to remember some kind of koji diff report that would come out periodically. Is there an automated run of this? I would love a dashboard or NxN matrix of diffs between all the arches. A timeseries would be perfect (to see the trends Matthew is referring to). Aha, found what I was thinking of: https://lists.fedoraproject.org/pipermail/arm/2013-February/005336.html That was a diff between primarily and a secondary arch koji, not actually a diff between x86 and ARM but rather an indication of how far the secondary was behind primary in terms of pure package builds. It was also generally quite inaccurate due to bugs in the script and sometimes a single build failure of a core dependency could causes bottle necks that could block builds due to dep chains and the fix to that is always reactionary (get bug fixed, tested, pushed upstream, generally manually build package to unblock bottle neck). Can this be rolled into automation in a more official way? Not that I'm aware on a primary - primary diff with the current tools. At the moment we basically ask rel-eng to use their mass check out to to comparisons and that's generally on just Exclude/Exclusive Arch and doesn't cover arch subsets of features of packages. Even something per-package like what Debian does is a start: https://packages.debian.org/wheezy/mlton-compiler vs. https://apps.fedoraproject.org/packages/mlton The mention of PPC builds is presumably to to messages on the fedmsg bus coming from the secondary arch PPC koji, the first in that list covers all 3 mainline arches due to being a single koji instance. Presumably koji/fedmsg could be enhanced to emit the arch builds (arm/noarch/ix86/x86_64 too if it doesn't already and then pkgdb display that info. I'll file a RFE, thanks for the suggestion. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [fedora-arm] ExcludeArch tracker doesn't appear to be effective
On Tue, Jun 10, 2014 at 11:52 PM, Peter Robinson pbrobin...@gmail.com wrote: [...] So moving on from that why don't you feel comfortable pointing to the ARM port? The question wasn't really directed at me but adding my 2 cents ... basically on x86(_64) hardware I can point people at fedora and most of the time it will work. As for ARM if you get a random arm hardware chances are that it is simply not supported or needs some manual hacks to get used. That's not really a fedora specific problem but it makes ARM more of a gimmick to me ... until hardware vendors catch up. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [fedora-arm] ExcludeArch tracker doesn't appear to be effective
On Tue, Jun 10, 2014 at 10:52:19PM +0100, Peter Robinson wrote: On Tue, Jun 10, 2014 at 10:20 PM, Matthew Garrett mj...@srcf.ucam.org wrote: In the past 6 months, 6 bugs added, 2 bugs closed - https://bugzilla.redhat.com/show_activity.cgi?id=485251 . If you're going on just the bug tracker possibly but there's a lot of stuff we fix and enhance that doesn't even make the that tracker, the Ada stuff I mentioned earlier is but one example. Rightly or wrongly it's not the canonical source of information. For example if I discover an exclude arch I'll generally just go and fix it rather than spending the time to open a bug, fix it myself and then close it myself. Just go and read the rawhide reports. If that's what you want us to do to give a warm fuzzy feeling of progress I don't see it as a time effective agile way of necessarily dealing with it. Feel free to suggest alternatives :-) Ok, I was entirely unaware of that, and it does change things. Thanks for letting me know. I'll look into whether it's practical to generate a list of all the existing ExcludeArch packages and automatically check whether they have tracker bugs filed - does that seem helpful? It *would* be good to have meaningful metrics on this, but I don't want there to be excessive process overhead. Where there's reliance on specific hardware functionality that's absent then yes, absolutely, there's no benefit in building the packages. Figuring out how to communicate that to users isn't an entirely solved problem, but with luck nobody's actually buying ARM hardware with unrealistic expectations of its functionality. But I can't find any examples of those in the tracker. They all seem to be cases where packages are either missing dependencies, take too long to build or are just missing support. They're code. We can fix them. Are you offering to do so? For example some time ago I approached one of the root maintainers (comes out of CERN I believe) and they said they didn't see the point nor have the time to maintain anything other than x86 at this time. Should we fork it and support it just to say we're feature complete with x86 just because it's code? Well maybe, but I'm not sure in that case it would add value to the distro for the expenditure of time and we've had exactly zero enquires about it (and it's 3 dependencies in the tracker). In the case of Hadoop there might possibly be value (and in later releases the issues might even have been fixed) but again we've had no queries and so we've focused on things people want. In the case of Ada we had some requests for support since F-20 was released so we've added that for F-21. Yeah, I think where it's practical for us to maintain feature compatibility we should do so even if upstream disagree. We make modifications to upstream code all the time in order to meet Fedora policy. As for who should be doing that work - well, yeah. That's kind of my point. Responsibility for this kind of thing is really something we should have figured out prior to promotion, and I'm sorry that I didn't think about it in a more timely manner. I'm looking for answers here, not insisting that anyone take on more work. I'm genuinely sorry if I gave the impression of bullying here. I want to feel comfortable pointing at the ARM port as an equal to the x86_64 one. I don't feel entirely comfortable doing so at the moment, and the current process doesn't seem to be getting us to the point where I would be. Well you need to engage with us better. Every time you make an appearance it appears to us all it's just to bully us. People genuinely shudder when your nick appears on on the channel and I've had 3 people thank me for replying so they don't have to. That's unfortunate. I'm sorry. I'll try to ensure that I'm interacting in a more productive way. So moving on from that why don't you feel comfortable pointing to the ARM port? I'm aware we're still not perfect but it was always going to be a road to improvement. Basically that you're still not perfect, to the extent that anything in Fedora is. I'd have been significantly happier if more time had been spent on, for instance, Anaconda before ARM was promoted. But realistically there's obviously a tension between perfectionism and maintaining enthusiasm - especially with the longer F21 cycle, I suspect the right decisions were made at the time. We're supporting massively more hardware now than we were at F-20 release time and the types of HW are getting better with the likes of the Tegra K1 supporting full desktop equivalent graphics and we might even have the support for that upstream in time for F-21 release, the open graphics drivers are improving that they might be usable in that timeframe too. Those were problems that were well known when we went to primary and the path is basically what was agreed and mapped out in that regards. The work that's been done on the
Re: [fedora-arm] ExcludeArch tracker doesn't appear to be effective
On Tue, Jun 10, 2014 at 11:07 PM, drago01 drag...@gmail.com wrote: On Tue, Jun 10, 2014 at 11:52 PM, Peter Robinson pbrobin...@gmail.com wrote: [...] So moving on from that why don't you feel comfortable pointing to the ARM port? The question wasn't really directed at me but adding my 2 cents ... basically on x86(_64) hardware I can point people at fedora and most of the time it will work. As for ARM if you get a random arm hardware chances are that it is simply not supported or needs some manual hacks to get used. That's not really a fedora specific problem but it makes ARM more of a gimmick to me ... until hardware vendors catch up. And the firmware side of things too, this is going to much better for a lot of devices in F-21 where the process will be much more straight forward and more robust. The amount of devices that should be supportable will be expanded by an order of magnitude too, as it stands at the moment the devices have over quadrupled since F-20 GA. In some cases this has been a case of chicken and egg and we've seen active engagement from a number of angles here since F-20 has gone GA and we'll see these improvements in new HW, in some cases already HW that is available on the market. For me at least given the fragmentation of the ARM market up until recently it's not particularly surprising and we've been some what on the bleeding edge of that. We were the first distro to adopt the multiplatform kernel and keep with the upstream first that has served the project well but this has often cost in HW support but saved us in that we've not had to juggle 100s of crappy vendor patches in dozens of kernels in a means that's not really scalable without a paid kernel team to support it. I'm hoping that we're finally on the downhill, and the level of devices that are being added easily and just work, seems to back up that hope and while there's always a long way to go the experience will be better in the F-21 timeframe. Again would love feedback and constructive suggestions to how we can improve this. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [fedora-arm] ExcludeArch tracker doesn't appear to be effective
If you're going on just the bug tracker possibly but there's a lot of stuff we fix and enhance that doesn't even make the that tracker, the Ada stuff I mentioned earlier is but one example. Rightly or wrongly it's not the canonical source of information. For example if I discover an exclude arch I'll generally just go and fix it rather than spending the time to open a bug, fix it myself and then close it myself. Just go and read the rawhide reports. If that's what you want us to do to give a warm fuzzy feeling of progress I don't see it as a time effective agile way of necessarily dealing with it. Feel free to suggest alternatives :-) Ok, I was entirely unaware of that, and it does change things. Thanks for letting me know. I'll look into whether it's practical to generate a list of all the existing ExcludeArch packages and automatically check whether they have tracker bugs filed - does that seem helpful? It *would* be good to have meaningful metrics on this, but I don't want there to be excessive process overhead. I agree metrics would be useful for all involved. Where there's reliance on specific hardware functionality that's absent then yes, absolutely, there's no benefit in building the packages. Figuring out how to communicate that to users isn't an entirely solved problem, but with luck nobody's actually buying ARM hardware with unrealistic expectations of its functionality. But I can't find any examples of those in the tracker. They all seem to be cases where packages are either missing dependencies, take too long to build or are just missing support. They're code. We can fix them. Are you offering to do so? For example some time ago I approached one of the root maintainers (comes out of CERN I believe) and they said they didn't see the point nor have the time to maintain anything other than x86 at this time. Should we fork it and support it just to say we're feature complete with x86 just because it's code? Well maybe, but I'm not sure in that case it would add value to the distro for the expenditure of time and we've had exactly zero enquires about it (and it's 3 dependencies in the tracker). In the case of Hadoop there might possibly be value (and in later releases the issues might even have been fixed) but again we've had no queries and so we've focused on things people want. In the case of Ada we had some requests for support since F-20 was released so we've added that for F-21. Yeah, I think where it's practical for us to maintain feature compatibility we should do so even if upstream disagree. We make modifications to upstream code all the time in order to meet Fedora policy. I agree it's worth the effort where there's the demand for it, we already do this for some packages on ARM where upstream don't support it because people want to use it. I don't really see the point in expending limited resources where there's no demand. As for who should be doing that work - well, yeah. That's kind of my point. Responsibility for this kind of thing is really something we should have figured out prior to promotion, and I'm sorry that I didn't think about it in a more timely manner. I'm looking for answers here, not insisting that anyone take on more work. I'm genuinely sorry if I gave the impression of bullying here. I want to feel comfortable pointing at the ARM port as an equal to the x86_64 one. I don't feel entirely comfortable doing so at the moment, and the current process doesn't seem to be getting us to the point where I would be. Well you need to engage with us better. Every time you make an appearance it appears to us all it's just to bully us. People genuinely shudder when your nick appears on on the channel and I've had 3 people thank me for replying so they don't have to. That's unfortunate. I'm sorry. I'll try to ensure that I'm interacting in a more productive way. So moving on from that why don't you feel comfortable pointing to the ARM port? I'm aware we're still not perfect but it was always going to be a road to improvement. Basically that you're still not perfect, to the extent that anything in Fedora is. I'd have been significantly happier if more time had been spent on, for instance, Anaconda before ARM was promoted. But realistically there's obviously a tension between perfectionism and maintaining enthusiasm - especially with the longer F21 cycle, I suspect the right decisions were made at the time. We're supporting massively more hardware now than we were at F-20 release time and the types of HW are getting better with the likes of the Tegra K1 supporting full desktop equivalent graphics and we might even have the support for that upstream in time for F-21 release, the open graphics drivers are improving that they might be usable in that timeframe too. Those were problems that were well known when we went to primary and the path is basically what was agreed and mapped out
