While for most people this may be completely useless. This is a gold for linux developers. I find myself constantly having to patch the kernel sources and pull in patches from lkml for review and testing. Would it be possible to get such package ? I would be willing to create such package myself tho i would need some help on things as linux-next is mainly git based and does not have zip files. Even if it did they would change daily.
While I'm not a member of kernel@, I suspect there'd be no objection _if_ you'd be willing to help out with keeping the ebuild working and handle maintenance where possible. You should be able to do this using the git-r3 eclass (look at any of the '9999' ebuilds in tree, and a lot of them will be suitable for you to base it on).
(In reply to Sam James from comment #1) > While I'm not a member of kernel@, I suspect there'd be no objection _if_ > you'd be willing to help out with keeping the ebuild working and handle > maintenance where possible. > > You should be able to do this using the git-r3 eclass (look at any of the > '9999' ebuilds in tree, and a lot of them will be suitable for you to base > it on). (Also, feel free to come to the #gentoo-dev-help IRC channel on Libera if you want assistance.)
Will do so. Also Ty for the very quick response :)
Created attachment 742026 [details] sys-kernel/linux-next Something like this? I installed in linux-next-9999 because there are tags like: next-20210929 Not sure if they will ever make sense to ever have separate ebuild for that, but then we could install that one into /usr/src/linux-next-20210929 Thoughts?
(In reply to Mike Pagano from comment #4) > Created attachment 742026 [details] > sys-kernel/linux-next > > Something like this? > > I installed in linux-next-9999 because there are tags like: > > next-20210929 > > Not sure if they will ever make sense to ever have separate ebuild for that, > but then we could install that one into /usr/src/linux-next-20210929 > > Thoughts? linux-next-9999 should be fine as its indeed a live source updated daily. I dont think having always a new folder for each next update would be smart. I will give this a test soon.
(In reply to haxk612 from comment #5) > (In reply to Mike Pagano from comment #4) > > Created attachment 742026 [details] > > sys-kernel/linux-next > > > > Something like this? > > > > I installed in linux-next-9999 because there are tags like: > > > > next-20210929 > > > > Not sure if they will ever make sense to ever have separate ebuild for that, > > but then we could install that one into /usr/src/linux-next-20210929 > > > > Thoughts? > > linux-next-9999 should be fine as its indeed a live source updated daily. > I dont think having always a new folder for each next update would be smart. > > I will give this a test soon. Thanks for testing. It's not so much a matter of "smart" or "dumb". It's more of , will a user request tagged linux-next versions as upstream names them? And if so, can we account for that here, which we have.
(In reply to Mike Pagano from comment #6) > (In reply to haxk612 from comment #5) > > (In reply to Mike Pagano from comment #4) > > > Created attachment 742026 [details] > > > sys-kernel/linux-next > > > > > > Something like this? > > > > > > I installed in linux-next-9999 because there are tags like: > > > > > > next-20210929 > > > > > > Not sure if they will ever make sense to ever have separate ebuild for that, > > > but then we could install that one into /usr/src/linux-next-20210929 > > > > > > Thoughts? > > > > linux-next-9999 should be fine as its indeed a live source updated daily. > > I dont think having always a new folder for each next update would be smart. > > > > I will give this a test soon. > > > Thanks for testing. > > It's not so much a matter of "smart" or "dumb". It's more of , will a user > request tagged linux-next versions as upstream names them? And if so, can > we account for that here, which we have. Good point. And since users are always recommended to do a depclean after each update i think having it versioned would be OK. BUT that would require either an automatic tool to change the ebuild name to account for when the -next tree is updated. Which is usually every day except weekends. But it sometimes changes and sometimes there isnt a new version. IDK how we could account for that. Lets join the IRC so we dont have to spam the bug tracker :)
I don't think creating another package is a good idea. Why do you such a package at all and don't just `git clone ...` in /usr/src for example? But if we do something like that, I would suggest to change existing sys-kernel/git-sources package. Make it dynamic. Use patches we do at the moment but add -9999.ebuild which uses git. People can now override EGIT_ variables to change repository, branch and stuff like that...
The plan for now is to add linux-next as its own package for now. And when we get to it have it transition over to git-sources as a live package. This was talked about in IRC. Will mark it resolved once its done :)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e059f7de3c4a4282a9ca7d9dc23b82e67c5b57b2 commit e059f7de3c4a4282a9ca7d9dc23b82e67c5b57b2 Author: Mike Pagano <mpagano@gentoo.org> AuthorDate: 2021-09-29 22:49:05 +0000 Commit: Mike Pagano <mpagano@gentoo.org> CommitDate: 2021-09-29 22:49:05 +0000 sys-kernel/linux-next: Support linux-next kernel Closes: https://bugs.gentoo.org/815199 Package-Manager: Portage-3.0.20, Repoman-3.0.3 Signed-off-by: Mike Pagano <mpagano@gentoo.org> sys-kernel/linux-next/linux-next-9999.ebuild | 33 ++++++++++++++++++++++++++++ sys-kernel/linux-next/metadata.xml | 11 ++++++++++ 2 files changed, 44 insertions(+)
