No… I did not like your suggestions…
Author Archives: Allan
God Like
Tweet
Having someone tell you that it will “bless him” if you stop to talk about a product does not mean he has recognized your God-like powers…
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…
Never Grab A Snake By…
Classic Gaming – Part 1: Duke Nukem
The recent release of Duke Nukem Forever got me thinking back to the original game and how many hours I sunk into as a child. (If you are thinking I mean Duke Nukem 3D, I shake my fist at you and yell “Get of my lawn”!) As with many games at the time, I only had the shareware version and not the complete game. So I decided it was time to relive my youth and obtain a copy of the complete game. Time to crank up DOSBox and get playing!
The original Duke Nukem had three “episodes”; Sharpnel City, Mission: Moonbase and Trapped in the Future. The first episode was the shareware game many people would have played. Set in the futuristic time of 1997, Dr. Proton was brain damaged in some sort of nasty radiation accident (not ironic despite his name, as there apparently was a name change there…) and developed an army of evil robots to protect his base. The military have failed to overcome such evil so the C.I.A. have stepped in and hired our hero!
Given how many times I had played through the first episode in my youth, it took me about a hour to race through and finish it. I still took some time out to explore some levels and relive the excitement of going to those very easy to find secret rooms. I still do not understand how Duke decides how often he can pull the trigger. It is not a function of reload time as if you hit something close range, you can immediately fire again. But miss and you will need to wait until the bullet goes out of the screen… Strange they had not sorted such things out in the future that is 1997, but you eventually upgrade your pistol and are allowed to fire four shots at once which is more than enough. Another thing that concerned me is the shooting of a turkey leg turns it into an entire turkey which Duke then eats for double health recovery. I would have thought eating food shoot with a nuclear pistol was not recommended…
Anyway, moving on to Episodes 2 and 3 that I had not played before. There is nothing new in game play in these episodes, only slightly different scenery. In Episode Two: “Mission: Moonbase” (yes, multiple colons in the title), Duke follows Dr. Proton to his moonbase using his time transport machine. That is right… time transport to get to the moon. The second episode was rather non-challenging – I died once for the entire game. You get pistol upgrades all over the place so enemies are readily defeated. I found more than the three you need to fully upgrade your pistol and I hardly explored everywhere. I was also slightly surprised the “Super Jump Boots” were not given in an early level given we are on the moon. The only real challenge was the level designer was obviously bored with having nothing new to work with, so just made larger mazes and put more bad guys everywhere. That does not so much increase the difficulty but rather just makes the game longer. Only on one level was the path to take in the maze not particularly obvious. A little more than two hours of game play and I had beaten Dr. Proton again. That boss battle was also poorly programmed as I noticed Dr. Proton flies up and down in the room in front of you and you can just stand back and shoot without going near him. I was far too manly to do that and attacked the good old fashioned way and just ran in guns blazing.
Episode Three: “Trapped in the Future!” sees Dr. Proton escape to the future in his time machine. Duke immediately follows without so much as a short rest even though he would much rather watch Opera. He is obviously not the brightest guy… he could assumably still watch Opera and then go to the point in the future where he was needed at his leisure. Again, nothing much changed in the third episode. The mazes got more annoying (when you start right beside a keycard access point, you know you are going to have to walk all the way back once you collect the key…). The main difference was that in the future there seems to be some horrid green colour to everything and so some levels are hard to look at. Also, random spikes are put everywhere on the ground so when you jump or drop down blindly to the next platform, you are going to take damage. No way to avoid that either as you can not take a look around slightly off screen before jumping there. This episode also appeared to be much shorter to me. I did try exploring most places, but obviously I was not very thorough as when I (very unexpectedly) arrived at the final fight with Dr. Proton, I did not have a fully powered up pistol. I did die a couple of times on the final fight, so there was some increase of difficulty. Although both of those were due to shear surprise that as soon as you drop into the final room you are being blasted by some flame and the boss is right above you and there are spikes everywhere you look to hide. As soon as I realized I just needed to get to the other side of the room, turn and shoot, Dr. Proton was soundly defeated.
Overall, I enjoyed coming back to play Duke. I do not think it is just nostalgia talking when I say the first episode was still the most enjoyable. I think the younger me would have been disappointed if after playing the first episode for free, I had then purchased the next two episodes. They just did not seem to have the same polish. I imagine the game developers being told “Great game. We are going to give it away for free. Make us two more quickly so we can sell them and actually make some money.” and them looking at each other and thinking “You could have mentioned this earlier…”.
But this has not put me off playing the rest of games that I only had the shareware version years ago. Next up is the three episodes of “Commander Keen: Invasion of the Vorticons”. Yay pogo sticks!
Hospital Bathroom
Tweet
I did not expect high quality bathroom fittings in a hospital, but this is really just not trying.
Global Warming
Tweet
FACT (according to my hospital room cleaner): The increased number of earthquakes and volcanic eruptions lately is due to global warming…
The [allanbrokeit] Repo (That Might Really Break Your System…)
I often package pre-releases of software that various developers post for testing before making a final release. I thought it would be good to put these in a repo where others can easily test them out too, as finding bugs before the main release saves me time later… Note that this software is pre-release and so you should expect it to have bugs, but I will generally stick to releases that the upstream developers consider ready for widespread testing and not alpha quality code. However, if you want to use this repo, you should be prepared to rescue your system from a bad package upgrade and to report your issues to the upstream developers (and not me…).
To use this repo, add this to your pacman.conf:
[allanbrokeit]
Server = http://allanmcrae.com/$repo/$arch
The packages are built on top of [testing], so you should have that enabled too.
Note the repo is fully signed with my GPG key (get the full fingerprint from my About page), so when something breaks, you can be guaranteed that it is my package that caused the issue! More importantly, this serves as a bit of a test for the signature checking in the developmental version of pacman.
Currently, the only package in the repo is the beta of gawk-4.0.0. I will tend to only add packages that I deal with for Arch Linux (which is mainly packages in [core]), but if someone has a particular package that would be of interest then let me know and I will consider it.
Email Tabs
Tweet
I used to think that tabs in a email client would be a killer feature, but I have just realized that I almost never actually use them.
Rapture
Tweet
Was not taken in the rapture so I need to organize something to eat. I guess the Indian takeaway owners will not have been taken either…