Re: [gentoo-soc] Week 1 Report for Musl support expansion to support GNOME desktop

[Anthony G. Basile]

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 <sys/wait.h>  The reason its working in 
glibc and not musl is because the .h files stack differently  So on a 
glibc system <sys/wait.h> 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 `<net/ppp_defs.h>` however
> this header file in not present in musl but glibc seems to provide it.
> Hence I decided to use the `<linux/ppp_defs.h>` 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. <net/ppp_defs.h> and <linux/ppp_defs.h> 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 <net/ppp_defs.h> and <linux/ppp_defs.h> 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@g.o
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA