From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 39935158091 for ; Sun, 19 Jun 2022 16:10:54 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 37CBBE0976; Sun, 19 Jun 2022 16:10:53 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id E1C48E0976 for ; Sun, 19 Jun 2022 16:10:52 +0000 (UTC) Message-ID: <80dfa292-de8d-86c8-7cf4-a9f79226bfd5@gentoo.org> Date: Sun, 19 Jun 2022 12:10:49 -0400 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-soc@lists.gentoo.org Reply-to: gentoo-soc@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [gentoo-soc] Week 1 Report for Musl support expansion to support GNOME desktop Content-Language: en-US To: gentoo-soc@lists.gentoo.org References: <20220619142616.sa7wnenizdb6vcms@gmail.com> Cc: "dilfridge@gentoo.org >> Andreas K. Huettel" , sam@gentoo.org From: "Anthony G. Basile" In-Reply-To: <20220619142616.sa7wnenizdb6vcms@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: fc836f63-eb5f-4d3a-8a64-90a0e677d7ca X-Archives-Hash: f60458d698343f374e407ff32317d470 On 6/19/22 10:26, listout wrote: > Hi folks, > > The first week of coding period of this years Google Summer of Code has > come to an end, hence I'm sending my weekly report. For the first two > week I had planned to install the gnome-light meta package and patch any > issues that I come across. So I started with that, by installing > gnome-light meta package from gnome-base. This resulted in me coming > across four issues. The first two were rather easy to fix and I've > patched and submitted those patches. The other two have proven to be > rather difficult to debug hence with advice from my mentors I've decided > to come back to them later. 1. Feel free to add me to the list of people you bounce questions off of. I did the initial port of musl to gentoo many years ago. > > Coming to the issues itself, the first two were just missing defines > that are present in glibc but not in musl. The issues were in the > gnome-terminal and samba packages, the gnome-terminal was missing was > missing `W_EXITCODE` define while samba was missing `NETDB_INTERNAL` and > `NETDB_INTERNAL` defines. The other two issues are in ppp and lirsvg > package, however they can be avoided for now and I was able to get a > working gnome desktop on musl profile. > 2. For the NETDB issue, take a look at the samba ebuild on the musl overlay https://gitweb.gentoo.org/proj/musl.git/tree/net-fs/samba 3. W_EXITCODE is defined in The reason its working in glibc and not musl is because the .h files stack differently So on a glibc system is getting included through some other .h while on musl it is not. Just add it to gnome-terminal. I wrote some python script back in the day which parses out how the .h files stack. I'll see if I can find it and mail it. > The issue with ppp was, ppp has been using `` however > this header file in not present in musl but glibc seems to provide it. > Hence I decided to use the `` as this would be > available for both musl and glibc users and everyone could benefit from > from the patch. This however didn't seem to work and introduced a > different error. I've filed an issue upstream [1] and got a reply from > maintainer. The maintainer in their reply agrees that we should use be > using headers from Linux or whatever libc system uses, the maintainer > also has idea of including purely linux headers. There is already an > pull request for this particular issue and it's under review. To avoid > using ppp one can generally disable it using `-ppp` USE flag in > `make.conf`. 4. and are not the same and you can't replace one with the other. I don't know ppp well, but if glibc provides it and musl doesn't, you can "break it out" of glibc as a standalone library the way I did with these following packages in sys-libs/argp-standalone sys-libs/fts-standalone sys-libs/obstack-standalone sys-libs/queue-standalone sys-libs/rpmatch-standalone If you do break it out and need to add the package, try to follow those models, ie call the pacakge ppp_standaone. But I could be totally wrong about ppp, since I don't know what provides what. Also, try to figure out what and are for so you understand the difference ;) > > Comming to the librsvg issue, the problem with librsvg has proven rather > hard to debug, though I've tried my best to debug it. The issues seems > to be that, librsvg is crashing when trying to render a svg and this is > needed to get a gnome shell running. Hence when trying to run > gnome-shell or gdm we get a fail whale screen ( White screen with > message "Oh no! Something has gone wrong" with a sad face ). I, with > help from my mentors and leio, tried to debug it and found out the issue > happens the function `g_file_get_uri` tried to load a svg. Hence we > tried to find out which svg in particular was causing the issue by > selecting the frame in gdb and trying to print > `g_file_get_uri(data->gfile)`, which didn't help either, it just > resulted in a segmentation fault. After that I decided to file a bug > upstream [2], meanwhile we other various things like increasing the > stack size as there has been issues with musl's default stack size, > which happens to be small. I've got a reply on this issue from librsvg > developer, they have suggested to increase the stack size and try it, > but we've already tried it before but I'll give it another shot just to > any eliminate human errors. Coming week, we'll try further debugging > librsvg. For now, to get a running gnome desktop one can use a older > librsvg from ::gentoo (librsvg-2.40.21 from ::gentoo worked). Sorry I don't have enough context here to help right now. BTW, I did get xfce4 working in musl many years ago, I don't know if what I did there might help with this project but I mention it in passing just so you know what's out there. I do remember having to do some magic with the xorg.conf file because of the way linking works in musl compared to glibc, ie. there is no lazy linking. > > This should be comprehensive enough report for the first week, learned > new things about debugging, looking forward to learning and contributing > more. Thanks to my mentors ( sam and dilfridge ), leio ( Gentoo's GNOME > project lead ) for his time in helping me debug gnome-shell and Catcream > ( fellow GSoC student ) for testing my the librsvg issue and confirming > it on his end. > > [1]: https://github.com/ppp-project/ppp/issues/351 > [2]: https://gitlab.gnome.org/GNOME/librsvg/-/issues/874 > -- > Regards, > listout > -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail : blueness@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA