fastfetch
fastfetch copied to clipboard
[Help wanted] submit fastfetch to debian unstable
Debian and Ubuntu are two of most used Linux distros but we haven't got the official packages there.
我们在deepin的打包的时候做了一些工作,包括将vendor的依赖yyjson单独打包出来,现在正在尝试向debian提交这些包 cc:https:github.com/deepin-community/fastfetch https:github.com/deepin-community/yyjson This work will be continued by @UTsweetyfish
@xzl01 @UTsweetyfish Any progress?
Ref: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053995
可以参考: https://mentors.debian.net/intro-maintainers/
你可以需要再发一个RFS:https://mentors.debian.net/accounts/register/ 在上面的链接里面有对此的介绍
https://mentors.debian.net/package/fastfetch/
Then what?
你需要关注下
这是对包质量的检查,可能需要对此进行更改
你可以使用 https://manpages.debian.org/testing/lintian/lintian.1.en.html 来检查你的包质量
https://lintian.debian.org/tags/very-long-line-length-in-source-file.html
这个链接你能打开吗?
你可以使用 https://manpages.debian.org/testing/lintian/lintian.1.en.html 来检查你的包质量
我在用ubuntu。Ubuntu的lintian不报这些错🤣
EDIT: 至少没有error了
你可以使用distrobox 运行一个debian容器来跑lintian。 链接我也打不开(可能是debian的问题?)
似乎目前的debian目录依然不符合标准,如果你愿意的话 我给你那个分支提一个pr进行修改
可以
@xzl01 and @CarterLi Thank you for the amazing work done.
I see there is a [Help wanted] tag, it seems like there is help wanted, but a lot of this issue is on chinese, sadly not everyone speaks chinese, wouldn't english be a bit a better way to communicate? That way much more people could understand the current situation and possibly help.
I see there is a [Help wanted] tag, it seems like there is help wanted, but a lot of this issue is on chinese, sadly not everyone speaks chinese, wouldn't english be a bit a better way to communicate?
I'm aware of this issue and really sorry for that
I had submit ( an old and slightly modified ) fastfetch to debian mentors and got no response. Progress stuck there.
https://mentors.debian.net/package/fastfetch/
I don't know much about debian and personally I don't use debian. I hope someone has experience of packaging for debian can take this.
Hi all, I would like to proceed with this task if possible. Is that ok?
I personally use Debian and I personally know some Debian developers and Debian maintainers that are used to contributing to Debian, I've already talked to one of them and they will help me. I will send an email to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053995.
Thank you for this nice project.
Thank you @hiagofranco! Really appreciated!
Also look at Maytham's comment at Bug #1067925. He suggests using salsa for maintaining the package. I succesfully built fastfetch
using Carter's debian/
but Debian projects prefer there is no debian/
directory in the upstream tarball. If you maintain the package in git, debian/
only lives in the debian/latest
branch, and the upstream source lives in the upstream/latest
branch, look here.
Hello @hiagofranco
Hi all, I would like to proceed with this task if possible. Is that ok?
I've marked you as the owner of the ITP bug now.
Would you be willing to add me as a co-maintainer of this package? I'm also interested in getting this piece of software into Debian :smile:.
I have a bit of experience in maintaining Debian packages, and have recently become a DM, so I can help out with packaging and uploading. I can also help with organising the creation of a repo under the debian/ group on Salsa.
Have you started work and/or created a Salsa repo yet?
Thanks, Maytham (maytham on IRC)
Hi all,
@mok0 thanks for sharing the links.
If you maintain the package in git, debian/ only lives in the debian/latest branch, and the upstream source lives in the upstream/latest branch, look here.
This would be the approach, yes. I believe I will have to ignore the /debian folder from fastfetch for now and rewrite it for the Debian package, but I will post any updates here. We can probably get rid of this folder in the folder and keep it only in the Debian repo.
@Maytha8
I've marked you as the owner of the ITP bug now.
Thank you! I will start to work on it today.
Would you be willing to add me as a co-maintainer of this package? I'm also interested in getting this piece of software into Debian 😄. I have a bit of experience in maintaining Debian packages, and have recently become a DM, so I can help out with packaging and uploading. I can also help with organising the creation of a repo under the debian/ group on Salsa.
Of course, let's do that together, it will be nice to have someone with experience to help ;-)
Have you started work and/or created a Salsa repo yet?
Not yet, I plan to start today, I will try to create it here and I will ask for help if something goes wrong...
How can I contact you? Can I use the email you've shared here?
Best Regards,
Hiago.
@hiagofranco
Not yet, I plan to start today, I will try to create it here and I will ask for help if something goes wrong...
Exciting!
How can I contact you? Can I use the email you've shared here?
Yep, or on IRC or GitHub.
@Maytha8 all right, thank you =)
I've started creating the Debian folder files and I noticed something I believe we will have to remove.
There is a LICENSE file for intel inside the src/3rdparty/igcl/
folder that is not in agreement with Debian. By removing this folder, I will have to patch the source code, and src/detection/gpu/gpu_intel.c
will not work, so any user using this GPU will not get this info. Any comments on that?
I don't know exactly how the MIT + proprietary LICENSE works as we have two licenses here, but I believe this will not be possible for the Debian package to be accepted on the mainline.
Edit: it may apply to other files under 3rdparty as well.
Hello, I am aware of the license concerns. There are several folders in 3rd party folder and they all can be removed
- ags and igcl: AMD and Intel's proprietary driver connector. Not used in Linux and can be removed directly.
src/detection/gpu/gpu_intel.c
is not used in Linux. https://github.com/fastfetch-cli/fastfetch/blob/dev/CMakeLists.txt#L695-L704 - nvml: it is Nvidia's proprietary driver connector. We support a CMake option
-DENABLE_PROPRIETARY_GPU_DRIVER_API=OFF
to disable using it. - mk_wcwidch: it is implementation of wcwidch(3) provided for Windows copatibility. It's not used in Linux since Linux support wcwidch(3) natively
- yyjson: this is core dependency of fastfetch to parse JSON files. It is licensed in MIT too. We also have CMake option
-DENABLE_SYSTEM_YYJSON=ON
to use system yyjson library if it is packaged officially (not the case for Debian). If system library is used, this folder can be removed too.
Hi @CarterLi, thank you for the detailed explanation :)
good, points 1..3 will be easy to fix then. About point 4, I have a debian contributor colleague and he will package the yyjson for Debian, as you mentioned it is not available yet but there is an ITP opened for it. Then we can make the fastfetch package dependent on the libyyjson one. I will come back with more updates once we have it. Thanks!
@hiagofranco So I guess fastfetch will be repacked to remove the 3rd-party/ directory from the Debian package?
@Maytha8 exactly, I used the gbp import-orig --filter=debian --filter=src/3rdparty fastfetch-2.11.3.tar.gz
to get the tarball and remove the debian and 3rdparty folders completely. Once I upload it to salsa repo I can share here with you.
Hello, any progress?
In order to reduce the license concerns, I have written my own nvml header from scratch by reading the official nvml document.
I found a program named nvtop which was licensed in GPLv3 did the same. Nvtop has been in Debian for long time so I believe that it should be enough to make Debian mentors happy.
There is another famous program called btop uses the same strategy, which is in Gentoo for long time. CC @ceamac
Hi @CarterLi, sorry for the absence, me, @Maytha8, and my friend @charles2910 created an IRC channel and we have been communicating there.
The fastfetch package is almost ready, it is under https://salsa.debian.org/debian/fastfetch, a repo under Debian that @Maytha8 crated.
The major issue was that fastfetch uses libraries inside the code and this is not recommended by Debian. Libraries should have their own package, and not be shipped inside the source code.
So we had to first package yyjson, which is under https://salsa.debian.org/debian/yyjson. This one will soon get to the NEW queue of Debian. Then I had to remove all the other libraries due to the license issue that we discussed.
After that, we can send fastfetch and point the fastfetch to the libyyjson package and have this ready.
In order to reduce the license concerns, I have written my own nvml header from scratch by reading the official nvml document. I found a program named nvtop which was licensed in GPLv3 did the same. Nvtop has been in Debian for long time so I believe that it should be enough to make Debian mentors happy. There is another famous program called btop uses the same strategy, which is in Gentoo for long time. CC @ceamac
Nice! =) This would be good to have the libraries available and working on Debian for sure. But this would also mean that we have to package these libraries instead of shipping them inside the fastfetch code, then we can make the fastfetch .deb as a dependency of the other libraries packages.
But this would also mean that we have to package these libraries instead of shipping them inside the fastfetch code
Why? They didn't do it for nvtop but why is it necessary for fastfetch? It's just a header file with only function and structs declarations which generates absolutely no machine code.