Week 9: Evaluate me please

Last week was as mentioned midterm evaluation, so my mentor is required to judge me and I am required to judge my mentor. I still remember last time so I was actually a bit surprised to see just a handful of questions and my "favorite" wasn't one of them anymore. The freeform answers even had a sizelimit of 2000 characters. Basically the same question topics through: How is the mentor & how are you doing. Most interesting perhaps is that most of the answers as I understood it aren't shared with the Orgas the students work for. Just the mentor judging is. Still, the form claims to be fillable in 10 minutes, I took considerably more time constantly rewriting and hunting for better words.

Not unlike what I did the rest of the week to the EIPP code, brushing over it, reordering and merging commits into potentially more logic units and finally testing and also fixing the bugs I ended up (re)introducing with my constant code shuffling – but enough is enough, I just pushed that stuff into master for everyone to see and work with (it was available last week in my wip branch as said, so that is just the more public-public. Still, master is always a big deal as it suddenly becomes "code which is supported" instead of "code I can freely change at will as nobody cares").

So, with the next upload of apt to experimental you will have funky stuff to play with, which you already know all about from the last weeks, but lets summarize how to opt into becoming my testlab monkey:

Individual apt(-get) calls [simulation or not] can be performed externally with the commandline switch --planner. The only available one at the moment is 'apt' which does the same as the internal one, just externally (okay, I am lying, there are two as there is also 'dump', but that isn't really a good planner…). Externally planed or not the EIPP scenario of the last request is stored (xz-compressed) in /var/log/apt/eipp.log.xz, so if you end up running into a ordering bug, you can now attach this file for perfect reproducibility which was considerably harder in the past with directing the user to grab a backup of the dpkg/status file from before the failure and hope that the mirrors are still in a state to reproduce it. Now, this file can be piped into the planner: /usr/lib/apt/apt-helper cat-file eipp.log.xz | /usr/lib/apt/planners/apt and out comes hopefully a bunch of progress messages (which in case of apt aren't displayed yet as I haven't really found a good place were it would also make sense & not sure if there is much point after all) and various actions to be performed via a protocol described in all its glory details in the documentation.

(That isn't all I did, but its the only thing you can play with … the rest is playing with you my little monkeys 😛 )

That should keep you busy for a week allowing me to continue investing some time into how dpkg itself is called by apt (with the plan in hand). There are 'old' ideas of how to change/improve it, some implemented but disabled, some not and some blocked by dpkg bugs. EOE will need some of these to work at all but that will be explained later… see you next week!

P.S.: It was also very hot & sometimes very rainy this week, a small british majority made me, themselves and the rest of the world feel sad and the french have strange number formats, but I can't and don't want to talk about everything in a little status update, can/should I…