A Week of Arch Linux Development

I thought I would record what I contributed towards Arch Linux for a week so people can have an idea of what goes on “behind the scenes” in the development of the distribution. While there is no such thing as a typical week for me in Arch Linux development, this week will almost certainly be atypical given I am off work on sick leave for the week. So there is probably going to be more time for some coding than usual. Saying that, I am not intending to spend all that additional time doing Arch stuff (or even the majority of it), so we will see…

Monday

  • Starting the week with a fairly clean slate – no package updates or items on the developer TODO lists for me to deal with. Although the glibc-2.14 toolchain did move to [core] yesterday so that may result in looking for bug fixes…
  • Daily dealing with email. Typically I receive ~200 emails over night between the Arch mailing lists and the various software development lists I am subscribed to. A few emails to pacman-dev I will deal with later but the rest just get marked as read after skimming the subject line. This is of course ongoing during the day.
  • Nothing relevant to my packages reported on the forums or bugtracker overnight. Yay!
  • Quick patch review and follow-up on pacman-dev (makepkg: ln -sf and POSIX and makepkg: warning messages for missing VCS tools).
  • Investigated FS#24884 – a claim of a glibc memory leak. The bug report is wrong about the cause and the testcase is an entire piece of software which does not work out of the box. My bet is not a bug, so leave it for the user to prove me wrong.
  • Test out some software prereleases – sudo-1.8.2rc4 and alpha releases of wget (1.12.2504) and patch (2.6.1.136). All added to the [allanbrokeit] repo.
  • Updated the toolchain testsuite wiki page now that the glibc-2.14 toolchain build is in [core]. Should really investigate that x86_64 only failure in glibc… (Debian sees it too so probably not urgent.)
  • FS#24571 – “file -i” gives incorrect output on zip files. Annoying, because makepkg uses this to detect how to extract files (although it should fall back to the same method anyway…). It was not due to our patching (which all comes from upstream) so bisected the issue and reported upstream.
  • FS#23989 – readline does not update infodir. This is actually trickier than it sounds to deal with. We can not run a post_install script as readline will be installed before bash. Required double checking what pacman does when there is an install script but the function is not defined, but it looks fine to have post_upgrade only.
  • More patch review for pacman. This time a couple of patches from Dan making sync DB reading more flexible and a really interesting bug fix for our fgets function for reading from archives.
  • Binutils-2.21.1 is released. Not much of an update given we use CVS snapshots from the 2.21 branch anyway and only a small number of bugfixes landed since the last one. Package updated and pushed to [testing].

Tuesday

  • Check emails. A few comments on my patches on pacman-dev and new patches to review. Also a push to pacman git master to rebase my work upon. And gcc-4.6.1 is released so I will be updating that today.
  • Rebase my pacman git working branch. Revert a patch that got pushed incorrectly (and one claiming I broke something at that!).
  • Update to gcc-4.6.1. Takes about two to three hours to build and run the testsuite per architecture on my computer… Also do the required libtool rebuild.
  • Review new patches from Dan on pacman-dev. The package signing work is really starting to take shape.
  • Discussed lots of pacman development on IRC… Decide to continue with lots more API breakage for pacman-4.0!
  • Made a large patchset renaming a lot of structs in the libalpm codebase: 62 files changed, 1048 insertions(+), 1048 deletions(-). It is not as big as it sounds…
  • Fixed a small bug introduced into makepkg by a recent commit.
  • First pass review of patches for adding PGP signature checks for source files in makepkg. Need to think on the implementation more before commenting.

Wednesday

  • Checked emails/bug tracker/forums. Nothing new for me to deal with this morning!
  • Replied to patches for adding PGP signature checks to source files in makepkg. Still some areas to figure out, but I think the approach I proposed is fairly solid without adding too much complexity to makepkg. Then replied again with more thoughts after investigating what gpg does with its –signal-files option.
  • Dan tells me my code to determine whether makepkg signs a package or not is not working… It is all lies and we find an unexpected behavior in makepkg with respect to config file overrides instead.
  • Reviewed a patch to have makepkg automatically add packages to a repo after they are created. The patch needs work, but a good start for a first time contributor to any code base.
  • Move my packages (readline, binutils, gcc, libtool) from [testing] to [core]. Then look at what other packages I have installed from [testing] that need a sign-off.
  • Fix all packages in [core] that run “make check” but do not use a check() function. This will make the following run much faster with --nocheck
  • Rebuild the entire [core] repo to check for any failures due to recent toolchain updates. Without running testsuites, this takes about three hours on our build server.
  • More API breakage for pacman-4.0! This time rename functions using “grp” to “group” as it is much clearer for the cost of two letters…
  • Review patch from Dan on pacman-dev improving the reading of the local package database.
  • Hmm… a lot more build failures in [core] than I expected… or believe. Manually checking a few packages shows they should not have failed. And there goes the bad assumption in my rebuild script. Fix that and rerun the failures and we are back to only grub failing to build with the latest binutils.
  • Looked into the grub build issue. Did not solve. It is probably just time to drop this package with the number of patches required to have it being functional.

Thursday

  • Daily email/bug/forum reading. A new sudo RC and a follow-up to the makepkg source signature work is all of interest.
  • Subscribed to a bunch of mailing lists that I really should skim read (bug-autoconf, bug-automake, bug-findutils, bug-gawk, bug-libtool and bug-m4).
  • Tested out the sudo RC (1.8.2rc5) and an alpha of findutils (4.5.10). Added to the [allanbrokeit] repo.
  • Quick review of some patches sent to pacman-dev.
  • Fix the “pure 64bit” patch to work with the latest gcc developmental snapshots.
  • Researched and decided not to implement the changes to the gcc “pure 64bit” patch requested in FS#24271. In fact, the 32bit linker should go in /lib32 with a symlink in /lib and that would avoid any adjustments needing made.

Friday

  • What happened over night… A couple of pushes to the pacman git repo, a major mkinitcpio release and a new bug report for me (FS#24970).
  • Look at FS#24970. Definitely not a binutils bug as I can replicate using only sed.
  • Spent a lot of time trying to make a sed build from git complete… Failed, but as a bonus I did learn a lot about gnulib.
  • Made a package for gnulib and uploaded it to the AUR.
  • Looked at why we need a /lib64 folder in our x86_64 install. Probably only issues with binary blobs… Call for testing some real world usage without the folder to see what issues are run into.
  • More investigation of FS#24970. Valgrind finds memory issues only with the hu_HU.UTF8 locale. Interesting…
  • Prepare script to generate patches for one final large API breakage in libalpm: PM_* to ALPM_*

Saturday

  • Another morning with not much new to deal with. Some new patches from Dave on pacman-dev for improving the download code, but they look complex so I think I’ll leave those to others (i.e. Dan) to review.
  • Clean up SVN entries for some perl packages that were converted to arch=('any').
  • Discussion about including more information about installed files in the local pacman database and where that information should be calculated (during packaging or install). This will allow for more stringent system checking with pacman -Qk.
  • Review and merge some of Matt’s (our new ABS developer) patch queue. Rather big job (57 patches!), but is all my fault for dropping the ball for so long there. Got to the point where an abs-2.4.3 release should be made. Impressed with the progress towards ABS-3.0 and the new features there.
  • Updated my bigpkg script to work with pacman-3.5

Sunday

  • Read emails, etc… The db-5.2 rebuild has hit [testing] so that will be a big update to test. Also a new bug reported against bash.
  • Addressed comments on my patch for a memory usage optimization when removing packages with pacman. Revised patches posted.
  • Closed FS#24992 as “Won’t Implement”. I’m not adjusting man pages in our packages.
  • Spent lots of time looking at the alpm_list_t implementation. I really want to change it a whole lot…
  • Initial look at adjusting the option parsing code currently only used by makepkg. Started implementing a couple of new features to it so that it can be used in the new pacman keyring management script (pacman-key) too.

And that wraps up my Arch Linux contributions for this week. Looking back at the week, the amount done on Monday to Wednesday was more than what I would consider usual on account of me being off work, but the rest of the week is probably not too far off what I normally do. I definitely got more coding and patch review done for the week, but I also had only two minor package updates to do which was atypically low. And I still did not get to finishing the patch merge for pacman-key, which was one of my primary development goals at the start of the week. Oh, well… there is always next week…

8 thoughts on “A Week of Arch Linux Development

  1. Great post.

    And thank you for your work developing Arch Linux 🙂

  2. Good to see there was plenty of time leftover for housework, or do you have a maid??