Le 26/11/2013 12:01, Andrew Wafaa a écrit : > On 26 November 2013 09:09, Guillaume Gardet <[email protected]> wrote: >> Le 26/11/2013 09:59, Michal Hrusecky a écrit : >>> Guillaume Gardet - 16:44 25.11.13 wrote: >>>> Le 25/11/2013 15:32, Michal Hrusecky a écrit : >>>>> Guillaume Gardet - 11:33 25.11.13 wrote: >>>>>> Le 25/11/2013 11:14, Guillaume Gardet a écrit : >>>>>>> Le 24/11/2013 21:12, Michal Hrusecky a écrit : >>>>>>>> Guillaume Gardet - 11:57 22.11.13 wrote: >>>>>>>>> Le 22/11/2013 11:47, Michal Hrusecky a écrit : >>>>>>>>>> Guillaume Gardet - 10:13 22.11.13 wrote: >>>>>>>>>>> Le 22/11/2013 09:55, Guillaume Gardet a écrit : >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> Le 22/11/2013 09:12, Michal Hrusecky a écrit : >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> today I tried upgrading openSUSE on my tablet (Tegra2) from 12.3 >>>>>>>>>>>>> to 13.1 and I >>>>>>>>>>>>> ended up with invalid instruction errors just after update of >>>>>>>>>>>>> glibc. My guess >>>>>>>>>>>>> is that glibc was compiled with neon support enabled. Was there >>>>>>>>>>>>> any decision to >>>>>>>>>>>>> drop non-neon devices or is it simply a bug? Is it just glibc >>>>>>>>>>>>> that has neon >>>>>>>>>>>>> enabled or everything? I know that for 32bits we have two glibc >>>>>>>>>>>>> packages, maybe >>>>>>>>>>>>> something similar would be possible for armv7? >>>>>>>>>>>>> >>>>>>>>>>>> AFAIK, neon should not be enabled by default, so this is a big >>>>>>>>>>>> bug. Someone else noticed this bug few days ago, on a Mirabox >>>>>>>>>>>> (Marvel SoC). >>>>>>>>>>>> >>>>>>>>>>>> All my ARM boards are neon capable so I cannot test. :( >>>>>>>>>>>> >>>>>>>>>>>> Maybe Alex, or Dirk, could help here? >>>>>>>>>>> Apparently, glibc is now capable of multiarch for armv7. Which mean >>>>>>>>>>> that it can auto-detect if hardware is neon capable, or not. For >>>>>>>>>>> that, we need to build glibc with multi-arch option enabled, which >>>>>>>>>>> is not the case right now. Without multiarch enabled, no tests are >>>>>>>>>>> performed and assume that neon is present. >>>>>>>>>>> >>>>>>>>>>> I am building glibc with multi-arch enabled. >>>>>>>>>>> Once built, could you test if it fix your problem? >>>>>>>>>>> >>>>>>>>>> Sure! >>>>>>>>>> >>>>>>>>> Here is the glibc RPM to test: >>>>>>>>> http://guillaume.gardet.free.fr/openSUSE/glibc-2.18-4.6.1.armv7hl.rpm >>>>>>>>> >>>>>>>>> Not sure it will fix the problem because build log seems to tell >>>>>>>>> multiarch was auto-detected before. But let's try it. >>>>>>>>> >>>>>>>>> If rpm, yast or zypper cannot install it, extract it on the SD card. >>>>>>>> hmmm, tried it, didn't helped, tried 12.3 glibc, that one helped :-/ >>>>>>>> >>>>>>> Will ask upstream. >>>>>>> >>>>>>> But could you try a 13.1 JeOS rootfs, please? Just to be sure that >>>>>>> things are not working with updated glibc and software built with this >>>>>>> one. >>>>>> Upstream seems to know this problem. See this resolved bug: >>>>>> https://sourceware.org/bugzilla/show_bug.cgi?id=15905 >>>>>> >>>>>> Will try to apply this patch on a locally built glibc and I will send >>>>>> you so that you can test. >>>>>> >>>>> Cool, thanks! >>>>> >>>> Could you try this one, please: >>>> http://guillaume.gardet.free.fr/openSUSE/glibc-2.18-312.1.armv7hl.rpm >>>> >>> This one works! Great! Thanks! >>> >> Ok, perfect! >> I submitted my glibc patch to Base:System project, see: >> https://build.opensuse.org/request/show/208445 >> >> Dirk, Alex, what would be the best way to handle this update? copypac to >> 13.1:Ports, 13.1:Update or something else? >> >> > I forget exactly how, but you should be able to submit it to > 13.1:Update as an update (which this is). It then goes through review > and then gets pushed out. >
Yes, Andreas declined my request to Base:System because he prepares an update which will obsolete my patch. But this will be for Factory only. :( I would need to get it in 13.1:Update as you said it. Will try to submit it to 13.1:Update later today. Guillaume -- To unsubscribe, e-mail: [email protected] To contact the owner, e-mail: [email protected]
