TODO

[xhebox]

common list:

• upload all packages(20-07-04)
• new package manager in rust
• bash completion

special list(most are patches):

• keep trying at wine, it is fixed
  • (https://bugs.winehq.org/show_bug.cgi?id=41703, https://bugs.alpinelinux.org/issues/6451)
  • some sounds went to silence in qq.exe, pulseaudio has something wrong?(i did nothing wrong, seems it's also the same reason)
  • no graphic in most 3D games, seems same reason
  • split gui from libwine, make it a standalone toolkit?
• if musl's intl is reliable?
  • bug1: http://www.openwall.com/lists/musl/2017/01/20/6
  • bug2: http://www.openwall.com/lists/musl/2017/01/29/1
  • libstdc++: generic locale blocked support for nls, patch: https://raw.githubusercontent.com/xhebox/noname/master/ports/gcc/locale.patch
  • bug3 - rewriting and stripping: http://www.openwall.com/lists/musl/2017/02/11/2, http://www.openwall.com/lists/musl/2017/02/13/3
  • _nl_msg_cat_cntr & _nl_domain_bindings: widely used to detect gnugettext, block the use of native intl, impossible to fix all tests in 600+ packages, hack it in libc(in ext(), add them in dcngettext.c): https://raw.githubusercontent.com/xhebox/noname/master/ports/musl/Pkgfile it's now implemented in gettext-tiny
  • bug4: http://www.openwall.com/lists/musl/2017/03/23/1
    #2 0x00007ffff7d82a6f in dcngettext (domainname=0x6737a0 "tar", msgid1=0x0, msgid2=0x0, n=1, category=5) at src/locale/dcngettext.c:211
    check https://github.com/xhebox/libuargp
  • bug5: msgfmt does not transform charset which is wrong for musl: some improvements to make it a real alternative to gnu msgfmt sabotage-linux/gettext-tiny#10
  • related commits from these:
    • https://git.musl-libc.org/cgit/musl/commit/?id=01e6bbece2bdcac243cdb8dff6916f2bb80a19e1
    • https://git.musl-libc.org/cgit/musl/commit/?id=dbbb3734d8c0176feabd6c46e2e85bbc3b8a60af
    • https://git.musl-libc.org/cgit/musl/commit/?id=16319a5df9d50cfc642ffc8db76bc36562d4b3dd
    • https://git.musl-libc.org/cgit/musl/commit/?id=e4fc9ad780e36c84e1ed6b0fc01b3c53ae65ff9d
    • https://git.musl-libc.org/cgit/musl/commit/?id=e6917eced2cc841fe3dfd9c04deec9202f9e34f3
    • https://git.musl-libc.org/cgit/musl/commit/?id=d6601f0af0452b218d247cb47513fc9cd6bbf2e2
    • some improvements to make it a real alternative to gnu msgfmt sabotage-linux/gettext-tiny#10
    • TODO: fuzzing sabotage-linux/gettext-tiny#11
• linux-tools: perf, tmon broken(https://github.com/xhebox/noname/blob/master/ports/linux-tools/portable.patch)
• clear chromium'gn: https://github.com/xhebox/noname/blob/master/ports/chromium/gn_fix_for_noname.patch
• clear isystem:

  so i think that's all, one for pkgconf, one for cmake, one for qmake, and one for those uncleaned packages.
  

• fix blender segfaults when using cycles(thread stack size up to 512k, tested with http://tf3dm.com/3d-model/45-acp-smith-and-wesson-13999.html)
• dwm with EWMH(https://github.com/xhebox/noname/blob/master/ports/dwm/dwm-ewmh.patch)
• chromium: failed to lauch gpu process, need to configure shared-memory-dir when building xorg-server, libxshmfence(-32)
• chromium: chromium build issues lluixhi/musl-extras#10 (comment), a hard debug
• golang: increase cgo stack size as SEGV_ACCERR when testing go tox binding, not always appear, accidentally.

  -O2 asm
        0x00007ffff711ddcc <+44>:	xor    %eax,%eax
  => 0x00007ffff711ddce <+46>:	callq  0x7ffff7118f80 <host_to_lendian32@plt>
  

  -O0 asm
     0x00007ffff71148ea <+0>:	55	push   %rbp
     0x00007ffff71148eb <+1>:	48 89 e5	mov    %rsp,%rbp
     0x00007ffff71148ee <+4>:	48 81 ec 30 08 02 00	sub    $0x20830,%rsp
  => 0x00007ffff71148f5 <+11>:	48 89 bd d8 f7 fd ff	mov    %rdi,-0x20828(%rbp)
     0x00007ffff71148fc <+18>:	48 89 b5 d0 f7 fd ff	mov    %rsi,-0x20830(%rbp)
  

  nothing wrong looking from asm. 20+ times no segv after set a large stack size, while 3~6 times i met a segv without patches.
  actually, it follows that, qtox may have a too small stack.
• https://github.com/mesa3d/mesa/commit/2cde8ff54598bac2d1e0900186a5b4bbfc4d3809, mesa gl configs selection, wrong on musl, did know why, add --opengl es2 to qt5 fixed the issue
• https://gitlab.com/graphviz/graphviz/-/issues/1757, graphviz musl problem

[xplshn]

Could an installation guide be added to the repo in the form of a INSTALL.md doc?

[xhebox]

Could an installation guide be added to the repo in the form of a INSTALL.md doc?

Oh.. Thanks, but I haven't released new rootfs for years, it is really a personal distro.

I do have binary management(with some bugs though). But I lost most of my binary tarballs about one year ago. I'd need to build about 100 packages for your installation...

If you are really interested, I could build one rootfs that you can chroot(probably one month later). And you need to build your own bootloader.

[xplshn]

Hmm, would such a setup be updateable? I was more interested in the package management and templates/recipes. I am also researching how to create my own Linux distro, I've tried with Alpine as a base before but I'd like something more hands-on. Thanks.

(if the rootfs is complete, making it bootable with syslinux or oslo is not a problem, thanks for replying)

:)

[xhebox]

Hmm, would such a setup be updateable? I was more interested in the package management and templates/recipes.

Yes, of course.

It mainly depends on your package manager: if it can uninstall/install packages. I made a very simple manager that stores a list of installed files, so it can uninstall/install packages. But my own package manager can't remove empty dir correctly.

I am also researching how to create my own Linux distro, I've tried with Alpine as a base before but I'd like something more hands-on. Thanks.

If that is your goal, I don't recommend that you use my linux. My package manager sucks, haha.

I would recommend that use apk/pacman or whatever package manager you like to build a complete different distro by writing recipes from scratch.

You see, things really matter are recipes/templates. I use MUSL as base libc, so I need a lot of patches for lots of packages.

And package management is, in fact, highly similar: add/del/query with hooks/chroot/build system, blah blah.

I started my distro by chroot into alpine(or arch?) rootfs, then pkg -M gcc/xxx, i.e. build toolchains first like LFS, then base packages... Then make a working rootfs out of your built packages, and build toolchains again... Then other packages you like.

This process did not rely on any specific package manager, try follow LFS but with a package manager, you'll get what you want.

Check eweOS, which is based on pacman obviously. But it is also highly customized.

[xplshn]

Thanks for the insight and consideration, I've already written a sort of "package manager", its called dbin and its available at https://github.com/xplshn/dbin, I did check EweOS and I think it is amazing, I'll probably fork it at some point and make it more like Alpine (I love suckless stuff).

[xhebox]

I've already written a sort of "package manager".

Cool.

For linux distro, it usually comes with a handy build system that resolve depedencies and release tarballs. For pacman it is makepkg, for apk it is abuild, and void-linux xbps-src, and sabotage-linux pure shell scripts.

As for me, I wrote them into one binary because I really don't want to maintain two programs. Once you got such a working system, you can start building your ports(slackware/bsd call the repo of recipes ports).

[xplshn]

Would you mind adding an MIT license or 3BSD? So that I can feel confident in borrowing your code..? I really like the way the build recipes for your distro work

[xhebox]

Would you mind adding an MIT license or 3BSD? So that I can feel confident in borrowing your code..? I really like the way the build recipes for your distro work

It is MIT. Just borrow it. In fact, I did borrowed scripts/patches from arch/alpine/void/yocto/gentoo sometimes, and even clear-linux from intel(they have some highperf patches).