From Gentoo Wiki
Jump 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
  • 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)

Improving upgrades

  • 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:
root # 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/", line 1289, in emerge_main
    return run_action(emerge_config)
  File "/usr/lib64/python3.6/site-packages/_emerge/", line 3330, in run_action
    retval = action_build(emerge_config, spinner=spinner)
  File "/usr/lib64/python3.6/site-packages/_emerge/", line 340, in action_build
    settings, trees, myopts, myparams, myaction, myfiles, spinner)
  File "/usr/lib64/python3.6/site-packages/_emerge/", line 9767, in backtrack_depgraph
    myaction, myfiles, spinner)
  File "/usr/lib64/python3.6/site-packages/_emerge/", line 9804, in _backtrack_depgraph
    success, favorites = mydepgraph.select_files(myfiles)
  File "/usr/lib64/python3.6/site-packages/_emerge/", line 3955, in select_files
    return self._select_files(args)
  File "/usr/lib64/python3.6/site-packages/_emerge/", line 3964, in _select_files
  File "/usr/lib64/python3.6/site-packages/_emerge/", line 670, in _load_vdb
  File "/usr/lib64/python3.6/site-packages/_emerge/", line 30, in start
  File "/usr/lib64/python3.6/site-packages/portage/util/_async/", line 90, in _start
  File "/usr/lib64/python3.6/site-packages/_emerge/", line 154, in _schedule
  File "/usr/lib64/python3.6/site-packages/portage/util/_async/", line 66, in _schedule_tasks
  File "/usr/lib64/python3.6/site-packages/_emerge/", line 30, in start
  File "/usr/lib64/python3.6/site-packages/_emerge/", line 59, in _start
  File "/usr/lib64/python3.6/site-packages/_emerge/", line 99, in _async_wait
  File "/usr/lib64/python3.6/site-packages/_emerge/", line 147, in _unregister
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


Packages which were on my list but are packaged now (not necessarily by me):