From Gentoo Wiki
< User:SamJump to:navigation Jump to:search
- Tooling to make security work easier, like pinging maintainers, changing whiteboards, and so on
- Investigate if any additional gcc flags should be added to hardened profile
Test and merge CET changes(done!)
- Relevant: bug #675050
- Add useful searches / tips to wiki pages?
- Audit maintainer-needed packages, possibly dev-java too, and maybe www-apps for known vulns w/o bugs
- Add mention of circular dependencies to handbook?
- Add mention of circular dependencies page to Portage? (bug #813504)
- Work on any devmanual items in notes
- Work on any wiki items in notes
- Report bash malloc bug on HPPA upstream - bug #832946
- dev-lang/R bits on HPPA - bug #729384
- Report R unaligned access noticed during build
- ... ICE when building sometimes?
- Report original build failure too. OK with lapack.
- Revive 'notes' idea for metadata.xml
Python PGO, ideally trained on Portage unit tests
- PGO itself is now done!
- Add further examples to the musl notes
- Summarise modern-day Hardened profile, update wiki pages, etc
- Improve wiki pages on nattka / stabilisation requests
- Add warnings on dhcp client to NetworkManager page
Make sure docs on SIGNED_OFF_BY etc are on wiki(done)
- Wait a few months before using new EAPIs in tree (require stable Portage to have supported it for.. 3? months)
- News item when a new EAPI is introduced to help folks who inevitably hit issues with their Portage being too stale (see also: bug #807043)
- bug #821511
- Take longer to drop support entirely for older Pythons in the eclasses (just python-exec is the main issue here)
- In particular, makes it harder to upgrade Portage if it's too old (even with nodeps and such).
- One ends up with lots of errors like:
python-exec: Invalid impl in /etc/python-exec/python-exec.conf: python3.6
python: no python-exec wrapped executable found in /usr/lib/python-exec.
Improve the "rescue Portage" documentation(done: Project:Portage/Fixing_broken_portage)
- Of particular note is this kind of error which appears when using an older Portage with a freshly synced tree:
emerge -uDNp --backtrack=9999 world
These are the packages that would be merged, in order: Calculating dependencies ... done! Traceback (most recent call last): File "/usr/lib/python-exec/python3.6/emerge", line 53, in <module> retval = emerge_main() File "/usr/lib64/python3.6/site-packages/_emerge/main.py", line 1289, in emerge_main return run_action(emerge_config) File "/usr/lib64/python3.6/site-packages/_emerge/actions.py", line 3330, in run_action retval = action_build(emerge_config, spinner=spinner) File "/usr/lib64/python3.6/site-packages/_emerge/actions.py", line 340, in action_build settings, trees, myopts, myparams, myaction, myfiles, spinner) File "/usr/lib64/python3.6/site-packages/_emerge/depgraph.py", line 9767, in backtrack_depgraph myaction, myfiles, spinner) File "/usr/lib64/python3.6/site-packages/_emerge/depgraph.py", line 9804, in _backtrack_depgraph success, favorites = mydepgraph.select_files(myfiles) File "/usr/lib64/python3.6/site-packages/_emerge/depgraph.py", line 3955, in select_files return self._select_files(args) File "/usr/lib64/python3.6/site-packages/_emerge/depgraph.py", line 3964, in _select_files self._load_vdb() File "/usr/lib64/python3.6/site-packages/_emerge/depgraph.py", line 670, in _load_vdb scheduler.start() File "/usr/lib64/python3.6/site-packages/_emerge/AsynchronousTask.py", line 30, in start self._start() File "/usr/lib64/python3.6/site-packages/portage/util/_async/AsyncScheduler.py", line 90, in _start self._schedule() File "/usr/lib64/python3.6/site-packages/_emerge/PollScheduler.py", line 154, in _schedule self._schedule_tasks() File "/usr/lib64/python3.6/site-packages/portage/util/_async/AsyncScheduler.py", line 66, in _schedule_tasks task.start() File "/usr/lib64/python3.6/site-packages/_emerge/AsynchronousTask.py", line 30, in start self._start() File "/usr/lib64/python3.6/site-packages/_emerge/EbuildMetadataPhase.py", line 59, in _start self._async_wait() File "/usr/lib64/python3.6/site-packages/_emerge/AbstractPollTask.py", line 99, in _async_wait self._unregister() File "/usr/lib64/python3.6/site-packages/_emerge/EbuildMetadataPhase.py", line 147, in _unregister self.scheduler.remove_reader(self._files.ebuild) AttributeError: 'NoneType' object has no attribute 'ebuild' # emerge --info Portage 2.3.76 (python 3.6.9-final-0, default/linux/amd64/17.1/desktop/plasma, gcc-8.3.0, glibc-2.29-r2, 4.19.72-gentoo x86_64) [...]
[02:29:43] <sam_c> leio and others: Does much support CPU_FLAGS_ARM on arm64? [02:29:57] <sam_c> As in, actually in tree. Or is it all just arm stuff. [02:30:06] <sam_c> Just wondering if that's an avenue I should look into at some point. [02:30:36] <sam_c> Also, would there be any value in CPU_FLAGS_ARM64, or not really? I imagine all it'd do is simplify ebuilds wanting to support arm64 but who need to do something different to arm in order to do so.
Things to package
- Various IRCds
- Homeworld SDL (new link?)
- Pwntools (github)
- Srain (in GURU at the moment)
- 010 editor?
Packages which were on my list but are packaged now (not necessarily by me):
- Various IRCds
- plocate (sys-apps/plocate)
- xmrig (net-misc/xmrig)
- Ananicy (app-admin/ananicy)