March 2013 - openSUSE ARM - openSUSE Mailing Lists

[opensuse-arm] libportaudio
by gary 10 Mar '13

10 Mar '13

I loaded libportaudio2 and got a link libportaudio.so -> /usr/lib/x86_64-linux- Damn, the text got chopped off from my terminal window. But basically link goes to the wrong place. The library does exist in opensuse arm. I created this link: libportaudio.so -> /usr/lib/libportaudio.so.2 I'm a bit prone to "pilot error" not being a programmer, so perhaps someone can check this out. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

2 2

[opensuse-arm] U-boot from factory is KO
by Guillaume Gardet 08 Mar '13

08 Mar '13

Hi, I wanted to test latest u-boot for beagleboard (we currently use an old linaro u-boot for beagleboard). And I found some problems about ext2 to ext4 transition (due to u-boot update I guess). First error is in mlo-ext2.patch in spl/Makefile: +LIBS-$(CONFIG_SPL_FAT_SUPPORT) += fs/ext2/libext2fs.o should be replaced with: +LIBS-$(CONFIG_SPL_FAT_SUPPORT) += fs/ext4/libext4fs.o otherwise, we have a build error since ext2 does not exist! Once fixed, boot from MMC hangs early because "ext4fs_set_blk_dev" function is misused. We are using: err = ext4fs_set_blk_dev(&mmc->block_dev, CONFIG_SYS_MMC_SD_FAT_BOOT_PARTITION); But arg number 2 must be "disk_partition_t *info" and not "int" as it was the case for ext2fs_set_blk_dev! Alex, could you have a look at it? According to the *.changes files, you are the best to fix it! ;) Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

2 3

Re: [opensuse-arm] Beagleboard XM freezes; suspect USB issue
by Guillaume Gardet 06 Mar '13

06 Mar '13

Le 06/03/2013 10:53, gary a écrit : > This is from fbset. > > mode "1024x768" > geometry 1024 768 1024 768 32 > timings 0 0 0 0 0 0 0 > accel true > rgba 8/16,8/8,8/0,8/24 > endmode > > Of course I'm using SSH, so I don't see the HDMI output. > > So the question here is how does the patch kill the use of the HDMI. It does not. As I said before, current factory kernel has a broken DVI output. Guillaume > > Is there some clever way for me to see if the keyboard is being received by the SBC. [I'm going to use SBC from now on to save me from typing out Beagleboard XM.] > > My setup uses a KVM, so I can easily push the button to use the keyboard or mouse for that matter on the SBC rather than using SSH via "terraterm". [I have opensuse on a notebook, but not on the KVM. My desktop linux motherboard blew out the power supply caps.] > > -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

3 6

[opensuse-arm] Re: AArch64 status and Debian/Ubuntu announcement
by Alexander Graf 06 Mar '13

06 Mar '13

On 27.02.2013, at 09:49, Guillaume Gardet wrote: > > Le 27/02/2013 09:33, Dirk Mueller a écrit : >> Hi Guillaume, >> >> Look at devel:ARM:AArch64:12.3, we have around 1500 packages as well. No image yet though. > > Oh, 2113 packages in succeeded state! Awesome! Too bad that we have no image yet. > I guess kiwi need some hack to get AArch64 image? > >> >> The plan was to do an announcement about the state today. Too bad that Debian was faster :-( > > Indeed but if we say: 2113 packages built, it is not so bad. :) > >> >> Any help with the announcement for s greatly appreciated. > > Not too much time today but I will try to give some help about that. Any etherpad or wiki page for collaboration? Email should be fine. Let's take the text below as a starting point. We really need to get this out this week or on Monday. Jos, I would greatly appreciate any help you could provide. openSUSE on AArch64 openSUSE is joining the crowd of 64 bit enabled ARM distributions. Within the past few months, the openSUSE team has worked very hard to get openSUSE up and rolling on ARM's new 64 bit capable architecture. By now, about 2400 packages built successfully. This is more than one third of the whole distribution. From all we know it's also more successful package builds than any other Linux distribution has on AArch64! If you'd like to see the status yourself, please check out the OBS repository we created for this [0]. As an open distribution, we also worked really hard to enable contributors to easily participate in the effort. For this, we extended osc (the OBS command line client) to automatically spawn a Foundation Model [1] virtual machine when you want to build for aarch64. More information on this is available on the respective wiki page [2]. Our next big milestone is going to he a working JeOS image - complete with YaST, openssh and everything you need for a simple and small system. We will create that using our standard image building tool kiwi and provide a ready-made image for the Foundation Model. Stay tuned! If all of the above got you curious and / or you would like to participate in this awesome effort, please join us on the openSUSE-ARM mailing list [3]. There is a lot of fun work to do and and you like open open source work, you are guaranteed to feel right at home. Your openSUSE ARM team [0] https://build.opensuse.org/project/show?project=devel%3AARM%3AAArch64%3A12.3 [1] http://www.arm.com/products/tools/models/fast-models/foundation-model.php [2] http://en.opensuse.org/Portal:ARM/AArch64 [3] http://lists.opensuse.org/opensuse-arm/-- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

8 28

[opensuse-arm] Native ARM build fails with an unknown error
by Guillaume Gardet 06 Mar '13

06 Mar '13

Hi, I am trying a native build for JeOS-beagle from openSUSE:Factory:ARM on my Beagleboard xM (using a 12.2 image) but I get this error: ****************************************************************************************** Verifying integrity of cached packages using keys from openSUSE:Factory:ARM Writing build configuration Running build [Errno 2] No such file or directory ****************************************************************************************** Any idea why? strace give me: ****************************************************************************************** write(1, "Running build\n", 14Running build ) = 14 pipe([7, 8]) = 0 fcntl64(7, F_GETFD) = 0 fcntl64(7, F_SETFD, FD_CLOEXEC) = 0 fcntl64(8, F_GETFD) = 0 fcntl64(8, F_SETFD, FD_CLOEXEC) = 0 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb6bc5328) = 2522 close(8) = 0 mmap2(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb5bb3000 read(7, "cexceptions\nOSError\np0\n(I2\nS'No "..., 1048576) = 462 mremap(0xb5bb3000, 1052672, 4096, MREMAP_MAYMOVE) = 0xb5bb3000 close(7) = 0 wait4(2522, [{WIFEXITED(s) && WEXITSTATUS(s) == 255}], 0, NULL) = 2522 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=2522, si_status=255, si_utime=2, si_stime=3} --- stat64("/usr/lib/python2.7/encodings/string_escape", 0xbeb12ce0) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.7/encodings/string_escape.so", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.7/encodings/string_escapemodule.so", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/lib/python2.7/encodings/string_escape.py", O_RDONLY|O_LARGEFILE) = 7 fstat64(7, {st_mode=S_IFREG|0644, st_size=953, ...}) = 0 open("/usr/lib/python2.7/encodings/string_escape.pyc", O_RDONLY|O_LARGEFILE) = 8 fstat64(8, {st_mode=S_IFREG|0644, st_size=2069, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb5cb3000 read(8, "\3\363\r\n\4!OPc\0\0\0\0\0\0\0\0\3\0\0\0@\0\0\0s\242\0\0\0d\0"..., 4096) = 2069 fstat64(8, {st_mode=S_IFREG|0644, st_size=2069, ...}) = 0 read(8, "", 4096) = 0 close(8) = 0 munmap(0xb5cb3000, 4096) = 0 close(7) = 0 write(2, "[Errno 2] No such file or direct"..., 35[Errno 2] No such file or directory) = 35 write(2, "\n", 1 ) = 1 munmap(0xb5bb3000, 4096) = 0 wait4(2522, 0xbeb17af4, WNOHANG, NULL) = -1 ECHILD (No child processes) close(4) = 0 munmap(0xb6f5c000, 4096) = 0 close(5) = 0 munmap(0xb6f5b000, 4096) = 0 close(6) = 0 munmap(0xb5cb4000, 4096) = 0 unlink("/tmp/rpmlist.OmXPfK") = 0 rt_sigaction(SIGINT, {SIG_DFL, [], 0x4000000 /* SA_??? */}, {0xb6e4fe38, [], 0x4000000 /* SA_??? */}, 8) = 0 rt_sigaction(SIGHUP, {SIG_DFL, [], 0x4000000 /* SA_??? */}, {0xb6e4fe38, [], 0x4000000 /* SA_??? */}, 8) = 0 rt_sigaction(SIGTERM, {SIG_DFL, [], 0x4000000 /* SA_??? */}, {0xb6e4fe38, [], 0x4000000 /* SA_??? */}, 8) = 0 rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], [], 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 exit_group(1) = ? +++ exited with 1 +++ ****************************************************************************************** Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

2 2

Re: [opensuse-arm] Beagleboard XM freezes; suspect USB issue
by Guillaume Gardet 06 Mar '13

06 Mar '13

Le 05/03/2013 22:07, gary a écrit : > I'm keeping this reply off the list as to not clog up email for those not involved. If you think I should send the files to the list as well, let me know. > > There are three attached files. > lsmod.txt > cmdline.txt > dmesg.txt > > Not to distract focus from the problem at hand, but you may recall I mentioned that one of the bugs with opensuse versus ubuntu is the Beagleboard XM didn't reboot properly. That is, you would issue the reboot command, the display would indicate processes shutting down, but you never got a login prompt. Well it turns out that using SSH, the Beagleboard XM does shutdown and restart. To elaborate, you issue a reboot command, the lan connection goes away as the machine goes offline. But checking the router client list, I saw the board reconnect via DHCP, and could then SSH into it like normal. > > So if you can follow that lengthy story, it might be that whatever you need to "start" to make the SBC work normally might also fix the reboot issue. > > Also note Ubuntu has a more up to date driver for the GPU. I get the full 1920x1200 with ubuntu, while opensuse is less. [Exact resolution I forget.] Latest Factory JeOS-beagle image shows nothing on DVI output either, so there is a bug somewhere in factory kernel whereas omapdrm is loaded. :( CONFIG_DRM_OMAP_NUM_CRTCS var have been changed from 1 to 2. Is it related? I should try to recompile a kernel with CONFIG_DRM_OMAP_NUM_CRTCS=1 and test, but not sure I will have enough time to do it. What does fbset command return? Then, if you want to have something on your serial, add console=/dev/ttyO2 to the command line passed to kernel, from u-boot. You have not it, since your image is XFCE based. Guillaume > > > > On 3/5/2013 2:14 AM, Alexander Graf wrote: >> >> On 05.03.2013, at 11:09, Guillaume Gardet wrote: >> >>> Hi gary, >>> >>> >>> Le 04/03/2013 21:36, gary a écrit : >>>> I did a yast2 -i on the 19mbyte patch and didn't use the other two RPM files. This was on a freshly installed image of 12.2 XFCE. >>>> >>>> I can't log into the system "normally", i.e. keyboard and monitor via HDMI/usb. Nor can I log into the system via the serial port. However, I can log into the system with SSH. Thus I can run some diagnostics if you have suggestions. >>> >>> Could you give us output of thoses commands, please: >>> cat /proc/cmdline >>> lsmod >> >> dmesg would be helpful too >> >> >> Alex >> >> -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

1 0

[opensuse-arm] [Announcement] openSUSE 12.3 preview available for AArch64
by Dirk Müller 06 Mar '13

06 Mar '13

Hi cross-distro readers, the openSUSE on ARM team was quite busy the last few weeks with getting openSUSE 12.3 for AArch64 ready. At the time of this post, we have finished around 4000-4100 packages (out of ~ 6000) of the current state of the openSUSE 12.3 project for AArch64. With those successfully built packages, we’re also able to build a regular openSUSE image for you to try and run in the ARMv8 System emulator (ARMv8 Foundation Model). This is a huge achievement and milestone for us, thanks to lots of helpful hands in openSUSE. Just to put this into context: This is not a minimal system with a couple of toolchain packages. It is also not an embedded variant of a Linux environment. No, this is the full featured, standard openSUSE distribution as you’re used to, ported to AArch64, up and running. We have built it based on (slightly newer versions of) standard openSUSE 12.3 packages, and the changes are mostly already merged back into openSUSE Factory. For all we know it’s also more successful package builds than any other Linux distribution has on AArch64! If you’d like to see the status yourself, please check out the OBS repository we created for this [1]. As an open distribution, it is important to make contributions easy and we worked hard to enable others to participate in our effort. We extended OBS (the Open Build Service) to automatically spawn a Foundation Model virtual machine when you want to build for aarch64. This works remotely on the OBS server as well as locally using osc build. Building for AArch64 is therefore as easy as building for any other architecture, and it feels native to all who are familiar with the OBS. More information on this is available on the respective wiki page [2]. So, dive right into it: Get the image and start with openSUSE on AArch64 by following our wiki page: https://en.opensuse.org/Portal:ARM/AArch64. Please contact the openSUSE Team at opensuse-arm(a)opensuse.org Greetings, Dirk (openSUSE ARM Team) [1] https://build.opensuse.org/project/show?project=devel:ARM:AArch64:12.3 [2] https://en.opensuse.org/Portal:ARM/AArch64 -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

2 1

Re: [opensuse-arm] Beagleboard XM freezes; suspect USB issue
by Guillaume Gardet 05 Mar '13

05 Mar '13

Hi gary, Le 04/03/2013 21:36, gary a écrit : > I did a yast2 -i on the 19mbyte patch and didn't use the other two RPM files. This was on a freshly installed image of 12.2 XFCE. > > I can't log into the system "normally", i.e. keyboard and monitor via HDMI/usb. Nor can I log into the system via the serial port. However, I can log into the system with SSH. Thus I can run some diagnostics if you have suggestions. Could you give us output of thoses commands, please: cat /proc/cmdline lsmod Regards, Guillaume > > The following in the output on the serial port. > > >> >> >> Texas Instruments X-Loader 1.5.0 (Sep 8 2012 - 02:21:18) >> Beagle xM >> Reading boot sector >> Error: reading boot sector >> fat load failed, trying ext2 >> Loading u-boot.bin from mmc >> >> >> U-Boot 2011.09 (Sep 08 2012 - 02:13:25) >> >> OMAP36XX/37XX-GP ES1.2, CPU-OPP2, L3-165MHz, Max CPU Clock 1 Ghz >> OMAP3 Beagle board + LPDDR/NAND >> I2C: ready >> DRAM: 512 MiB >> WARNING: Caches not enabled >> NAND: 0 MiB >> MMC: OMAP SD/MMC: 0 >> *** Warning - readenv() failed, using default environment >> >> In: serial >> Out: serial >> Err: serial >> Beagle xM Rev C >> No EEPROM on expansion board >> Die ID #67dc00029ff80000016849a90401601a >> Net: No ethernet found. >> Hit any key to stop autoboot: 0 >> The user button is currently NOT pressed. >> SD/MMC found on device 0 >> Loading file "uEnv.txt" from mmc device 0:1 (xxa1) >> ** File not found uEnv.txt >> Loading file "boot.scr" from mmc device 0:1 (xxa1) >> 711 bytes read >> Loaded script from boot.scr >> Running bootscript from mmc0 ... >> ## Executing script at 80200000 >> ## Error: "kerneladdr" not defined >> ## Error: "ramdiskaddr" not defined >> Loading file "uImage" from mmc device 0:1 (xxa1) >> 4242344 bytes read >> Loading file "initrd" from mmc device 0:1 (xxa1) >> 12464100 bytes read >> ## Booting kernel from Legacy Image at 88000000 ... >> Image Name: Linux-3.7.9-0-omap2plus >> Image Type: ARM Linux Kernel Image (uncompressed) >> Data Size: 4242280 Bytes = 4 MiB >> Load Address: 80008000 >> Entry Point: 80008000 >> Verifying Checksum ... OK >> ## Loading init Ramdisk from Legacy Image at 81600000 ... >> Image Name: Initrd >> Image Type: ARM Linux RAMDisk Image (uncompressed) >> Data Size: 12464036 Bytes = 11.9 MiB >> Load Address: 00000000 >> Entry Point: 00000000 >> Verifying Checksum ... OK >> Loading Kernel Image ... OK >> OK >> >> Starting kernel ... >> >> Uncompressing Linux... done, booting the kernel. > > > > On 3/4/2013 1:03 AM, Guillaume Gardet wrote: >> >> Le 02/03/2013 01:28, gary a écrit : >>> I'm not sure if my direct replies are being caught in a spam filter. >>> There were no instructions with the patch, which is 3 RPMs. I placed >>> all three RPMs on the SD card for the Beagleboard XM. [Basically just >>> do a save as with the sd card in an intel computer running opensuse.] >>> >>> I booted the Beagleboard XM and ran all three patches, then rebooted. >>> At that point I could no longer log into the Beagleboard XM. Not >>> through the serial port or the "normally" (display driver and usb). >> >> What is the output on the serial port (I mean from u-boot and then if >> you have something then)? >> Did you try a SSH login? >> >>> >>> I have a program on the Beagleboard XM that I set up as a service that >>> provides "telemetry" over a lan. That service was running since I >>> coudl get data off the Beagleboard XM. I ran it for 3 days without a >>> crash. [At that point I went to a different SD card / OS to work on >>> other software.] The best I ever got prior to the patch is about 8 >>> hours. >>> >>> However, I think the performance of the software I was running was >>> hampered by the patch since it seemed to be putting out less data. >>> Since I couldn't log into the board, I have no way to analyze this. >>> >>> So again, I am asking for someone to either explain how to apply the >>> patch, or apply the patch to an image. >>> >> >> Install RPM kernel-omap2plus provided by Alex, using zypper and reboot. >> >>> As I stated before the JEOS wasn't booting on the Beagleboard XM. [The >>> XFCE image works.] This might be a good way to get the bug out of JEOS >>> and test the patch at the same time. >> >> Try your patch on XFCE image first. One thing at a time. ;) >> >>> >>> Since this appears to be a design flaw in the beagleboard XM, I'm sure >>> all the board have an issue with this to some degree. My board is just >>> worse than most. Thus I have a good test vehicle for the patched >>> kernel, well provided I get one. >> >> Thanks for your help in testing. >> >> >> Guillaume >> >> >>> >>> >>> >>> On 2/25/2013 4:05 PM, Alexander Graf wrote: >>>> >>>> On 25.02.2013, at 19:00, Alexander Graf wrote: >>>> >>>>> >>>>> On 25.02.2013, at 18:50, lists(a)lazygranch.com wrote: >>>>> >>>>>> Actually, I haven't tried the patch. The instructions are not >>>>>> detailed enough for me to use. The person who wrote has "issues" >>>>>> and isn't helpful. Let's leave it at that. >>>>>> >>>>>> If anyone can explain in detail how to patch a kernel, I'm willing >>>>>> to try it. >>>>> >>>>> I guess it's easiest if either Guillaume or me create a special >>>>> kernel for you to try with that patch applied. I won't get to it >>>>> before midnight today, but maybe can create one after that tonight >>>>> that you can give a whirl. My Beagleboard XM is about 2 km away with >>>>> lots and lots of snow lying in between me and it. :) >>>> >>>> http://csgraf.de/tmp/omap3/ >>>> >>>> This is the 12.3 kernel + the patch you posted. >>>> >>>> >>>> Alex >>>> >>>> >> >> > -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

2 1

Re: [opensuse-arm] openSUSE:12.3:Ports now configure for native builds
by Guillaume Gardet 05 Mar '13

05 Mar '13

Hi, Tested just now as local build on x86_64, error is still there in Factory images build. Did you pushed a fix? 12.3 native build is not yet started in OBS (scheduled status for all except JeOS which is succeeded). Guillaume Le 02/03/2013 08:22, Adrian Schröter a écrit : > > JFYI, the openSUSE:12.3:Ports project is now configured for native building > > to workaround some reported problems there. > > I think, I saw also the error why it can't work with qemu in the config > > (an added Ignore: line to qemu-linux-arm package), but since 12.3 also > > building native, it is just consequent to do the same with the ports project. > > In can not watch if this really works in the next hours unfortunatly. > > sorry > > adrian > > -- > > Adrian Schroeter > > SUSE Linux Products GmbH > > email: adrian(a)suse.de > -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

3 2

Re: [opensuse-arm] Beagleboard XM freezes; suspect USB issue
by lists＠lazygranch.com 04 Mar '13

04 Mar '13

Actually, I haven't tried the patch. The instructions are not detailed enough for me to use. The person who wrote has "issues" and isn't helpful. Let's leave it at that. If anyone can explain in detail how to patch a kernel, I'm willing to try it. Otherwise, my beagleboard XM is useless. It will crash in 5 minutes or 5 hours. They are willing to RMA the unit for the exact same flawed design. But all that means is the lockup issue might be less frequent, but still be there. That to me is a reliability issue anyone buying a Beagleboard XM will face. Maybe instead of crashing daily it would crash weekly or monthly. Given that this is a hardware bug, I believe all Beagleboard XMs have this problem. But some worse than others. FWIW, it seems Ubuntu runs longer than Opensuse. Not so with Fedora. It crashes as fast as openuse. Ubuntu 12.04 yielded diagnostics on the serial port and in fact returned control to the serial port instead of crashing. That is how it was determined that the USB chip was the problem. Ubuntu 12.10 does not return control to the serial port. It just crashes and has to be rebooted to use again. This makes me think they patched the kernel and the patch is not sufficient in totally fixing the problem. Another issue is the Beagleboard XM under openuse cannot be rebooted with init 6. It just shuts down. Ubuntu can reboot the hardware. Canonical doesn't work in the open as much as Fedora or Opensuse, so I don't know how to reach anyone working on the Arm distribution. But clearly they have fixed some bugs and these fixes have not found their way out of the company. ------Original Message------ From: Alexander Graf To: gary Cc: opensuse-arm(a)opensuse.org Subject: Re: [opensuse-arm] Beagleboard XM freezes; suspect USB issue Sent: Feb 25, 2013 5:00 AM On 21.02.2013, at 06:39, gary wrote: > In an effort to figure out this problem, I loaded some other linux distributions. It turns out Ubuntu can recover from this problem rather than lock up. It also provides some useful diagnostics. It turns out the lock up can be (in theory) cured with this patch: > >> https://github.com/RobertCNelson/stable-kernel/blob/v3.7.x/patches/omap_spr… > > Any help on how to apply this patch would be appreciated. Or has the patch already been applied and 12.3 will have the fix? Have you found any particular reason this patch hasn't gone upstream? If no, it might be a good idea to send it yourself. We should easily get it back through the normal Linux stable tree then. I'm quite reluctant to move this only into the openSUSE kernel. That's not how community work should look like :). Alex N§²æìržyéZ)z{.±æ«ë§²æìržz^Ë¬zàN(Ö¶Ø^£ ÞéZ)z{.±æ«ê0êè¥éìºÇš®

4 4