In order to get familiar with the portage codebase, we decided that I\u2019d fix a few bugs. This blog post talks about the second half of the community bonding period (weeks 3 and 4) where I try to do that.<\/p>\n
When it comes to bugs, the paradox of choice is real. To choose from, there is a heap of them (1439 at the moment of writing). Most of the bugs are quality of life improvements as the portage team\u00a0 has put in a lot of effort to make sure portage does it\u2019s jobs without many errors. After searching, we decided to work on bug 634576<\/a>.<\/p>\n Portage uses backtracking to calculate the dependencies of a package and it is a computationally\u00a0 intensive and time consuming process. If a person were to issue a command The bug was confirmed and so that means the portage team was able to reproduce it. So we tried<\/p>\n and to our surprise, emerge failed fast. We can\u2019t just close the bug without giving context and so we had to find the commit that fixed it.<\/p>\n One of the mentors, Sam James suggested we use git bisect. It is a clever feature of git. I was very\u00a0 glad when I read about git bisect. It was very cool to see binary search being used in real world. Git bisect has an option for automated testing. We write an application (or script), based on which\u2019s\u00a0 exit code, git bisect can find \u201cgood\u201d and \u201cbad\u201d commits. We noticed that if portage fails faster, it fails within 1.8 seconds. So we wrote the following script.<\/p>\n We need the The output of the run can be found here<\/a>.<\/p>\n Due to EAPI differences and the portage status being inconsistent between commits, we could not identify the exact commit that fixed it but it was somewhere around commit \u201c0f3070198c56a8bc3b23e3965ab61136d3de76ae\u201d, which was around 2021 when caching\u00a0 capabilities are added to portage. With this information, the bug was closed successfully.<\/p>\n To summarize, we looked at a few bugs and closed one using git bisect and a small python script. I\u00a0 am also getting familiar with the codebase and I have been looking at places to work on. Bonding Period 2 – Modernization of Portage Context In order to get familiar with the portage codebase, we decided that I\u2019d fix a few bugs. This blog post talks about the second half of the community bonding period (weeks 3 … Continue reading 634576<\/h2>\n
emerge<\/code> 10 packages,\u00a0 portage calculates the dependencies one by one and if he\/she were to misspell a single package,\u00a0 portage would calculate the dependencies of other packages before recognizing that the name of a\u00a0 package is wrong. It fails, but only after calculating dependencies of other packages. At this point,\u00a0 all the computation done is also being wasted. At the time of filing of this bug, portage did not\u00a0 cache it\u2019s calculations and so in the next run, all the dependencies are calculated again. Ideally, portage should have recognized the package does not exist and it should \u201cfail faster\u201d.<\/p>\nReproducing the bug<\/h3>\n
# emerge www-client\/chromium \"<cython-3\" libreoffice dev-lang\/ghc\r\n dev-haskell\/doctest dev-ruby\/actionpack firefox tensorflow idonotexist<\/code><\/pre>\nGit bisect<\/h2>\n
#!\/usr\/bin\/env python<\/span><\/span>\r\n<\/span>\r\nimport<\/span> subprocess<\/span>\r\nimport<\/span> time<\/span>\r\n<\/span>\r\na =<\/span> time.time()<\/span>\r\nsubprocess.run(<\/span>\r\n [<\/span>\r\n \"emerge\"<\/span>,<\/span>\r\n \"www-client\/chromium\"<\/span>,<\/span>\r\n \"libreoffice-dev\"<\/span>,<\/span>\r\n \"dev-lang\/ghc\"<\/span>,<\/span>\r\n \"dev-haskell\/doctest\"<\/span>,<\/span>\r\n \"dev-ruby\/actionpack\"<\/span>,<\/span>\r\n \"firefox\"<\/span>,<\/span>\r\n \"tensorflow\"<\/span>,<\/span>\r\n \"idonotexist\"<\/span><\/span>\r\n ]<\/span>\r\n )<\/span>\r\nb =<\/span> time.time()<\/span>\r\nt =<\/span> b -<\/span> a<\/span>\r\n<\/span>\r\nif<\/span> t ><\/span> 1.8<\/span>: # If t goes above 1.8, it means dependencies are being calculated<\/span><\/span>\r\n exit(0<\/span>) # Says to git bisect this is good (we want to find the bad commit)<\/span><\/span>\r\nelif<\/span> t <<\/span> 0.2<\/span>:<\/span>\r\n exit(127<\/span>) # Says to git bisect to check nearby commit.<\/span><\/span>\r\nelse<\/span>:<\/span>\r\n exit(1<\/span>) # Bad commit (we want to find this)<\/span><\/span><\/code><\/pre>\n<\/div>\nexit(127)<\/code> line because some of the commits leave portage repo at an inconsistent\u00a0 state. When the program exits with an exit code of 127, it tells git bisect to ignore the current\u00a0 commit and check nearby commits. We ran the script with the following command.<\/p>\ngit bisect .\/script<\/code><\/pre>\nSummary<\/h2>\n
emerge --version<\/code> seems like a nice and simple corner to start. That marks the end of the \u201ccommunity\u00a0 bonding period\u201d. The \u201cofficial coding period\u201d starts next week and I can barely contain my excitement!!<\/p>\n","protected":false},"excerpt":{"rendered":"