About a year ago I migrated all my workstations, laptops and netbooks to Arch Linux. Since then, I've setup Arch Linux on a Raspberry Pi and this server was also recently migrated to Arch Linux.
I've had no major issues issues during the last year and have upgraded through five major Linux kernels, transistioned to systemd and upgraded from Gnome 3.2 to 3.8.
Although I have been disciplined about merging .pacnew files frequently, during the upgrades and my many experimentations I have packages installed that I no longer require and obsolete files kicking about.
After the upgrade to Gnome 3.8 I decided to clean up a little. I rarely dip into the AUR, but when I do I always use packer to clearly seperate what is official from what is not.
Finding what is installedThe following commands are useful for identifying installed packages based on where they were installed from. The package lists generated from the commands below can be quite big but often highlight packages that I know I'm no longer using nor require.
Listing installed packagesList packages installed from the official repositories.
pacman -Qq | grep -Fv -f <(pacman -Qqm)List packages installed from the AUR.
pacman -Qqm Listing installed packages by sizeUse pacsysclean to list installed packages sorted by size, it helps identify large packages that are no longer required which can the be manually uninstalled.
Listing orphaned packagesList ophaned packages install from the official repositories.
pacman -Qqtd | grep -Fv -f <(pacman -Qqtdm)List ophaned packages from the AUR.
pacman -Qqmtd Getting package informationGet package information for a package in the official repositories.
pacman -Si <package>Get package information for a package in the AUR.
packer -Si <package> Removing orphaned packagesRemoving ophaned packages manaully can be very time consuming, but is by far the safer option. However, I decided to take a brave pill a uninstall all orphaned packages automatically.
Remove all ophaned packages installed from the official respositories.
sudo pacman -Rs `pacman -Qqtd | grep -Fv -f <(pacman -Qqtdm)`Remove all ophanced packages install from the AUR.
sudo pacman -Rs $(pacman -Qqtdm) Re-installing what you do needWhen you do something scary like removing all the obsolete packages automatically, then you should really make sure you do have everything install that you require.
Re-install 64-bit base sudo pacman -S --needed `pacman -Sqg base multilib-devel | grep -v gcc-libs | tr '\n' ' '` Re-install 32-bit base sudo pacman -S --needed `pacman -Sqg base base-devel | tr '\n' ' '`Reinstall the groups required for a Gnome 3 desktop.
sudo pacman -S --needed `pacman -Sqg gnome gnome-extra telepathy | tr '\n' ' '`Install all missing dependencies for packages in the official repositories.
sudo pacman -S --needed `pacman -Si $@ 2>/dev/null | awk -F ": " -v filter="^Depends" \ '$0 ~ filter {gsub(/[>=<][^ ]*/,"",$2) ; gsub(/ +/,"\n",$2) ; print $2}' | grep -v smtp- | sort -u`Install all missing dependencies for packages in the AUR. This will re-install even if the package is already installed. I can't be arsed to filter it out for a one liner.
sudo packer -S --noedit --noconfirm `packer -Si $(pacman -Qqm) 2>/dev/null | awk -F ": " -v filter="^Depends" \ '$0 ~ filter {gsub(/[>=<][^ ]*/,"",$2) ; gsub(/ +/,"\n",$2) ; print $2}' | grep -v java- | sort -u` Find files not associated with a packageWhen packages are removed they may leave some files behind. The following will find all files not associated with a package. These files can not be automatically deleted, each entry requires assessment.
pacman -Qlq | sort -u > /tmp/db sudo find /bin /etc /sbin /usr ! -name lost+found \( -type d -printf '%p/\n' -o -print \) | sort > /tmp/fs comm -23 /tmp/fs /tmp/dbAs with all sping cleaning chores, I got bored by this stage as my workstation was looking pretty tidy. Much of what is presented in this blog post is a rehash of what others have already contributed to the Arch Linux Wiki. I've just organised what "Works For Me ™" so I know what to do next year.
Referenceslibguestfs has high quality Python bindings. Using rpyc you can make a remote libguestfs server with almost no effort at all.
Firstly start an rpyc server:
$ /usr/lib/python2.7/site-packages/rpyc/servers/classic_server.py [SLAVE INFO 13:21:17 tid=140019939981120] server started on 0.0.0.0:18812 [SLAVE INFO 13:21:17 tid=140019784894208] started background auto-register thread (interval = 60) [REGCLNT INFO 13:21:17] registering on 255.255.255.255:18811 [REGCLNT WARNING 13:21:19] no registry acknowledgedNow, possibly from the same machine or some other machine, you can connect to this server and use Python objects remotely as if they were local:
$ python Python 2.7.3 (default, Aug 9 2012, 17:23:57) [GCC 4.7.1 20120720 (Red Hat 4.7.1-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import rpyc >>> c = rpyc.classic.connect('localhost')You can now create a libguestfs handle, following the example here.
>>> g = c.modules.guestfs.GuestFS() >>> g.version() {'release': 36L, 'major': 1L, 'minor': 21L, 'extra': 'fedora=20,release=1.fc20,libvirt'} >>> g.add_drive('/dev/fedora/f18x64', readonly=True) >>> g.launch() >>> roots = g.inspect_os() >>> g.inspect_get_product_name(roots[0]) 'Fedora release 18 (Spherical Cow)' >>> g.inspect_get_mountpoints(roots[0]) [('/', '/dev/mapper/fedora-root'), ('/boot', '/dev/sda1')]As you can see, the g object is transparently remoted without you needing to do anything.
Hand and Spear, Old Heath Road, Weybridge KT13 8TX
http://www.handandspear.co.uk/
It has good parking and is right next to Weybridge Station.
The meet starts at 7.30pm on Wednesday 15th May. Just to encourage you
I will buy the first five arrivals a beer.
It is a big pub and the landlord has promised us a quiet corner away from the TV and that night there is no bingo, quiz etc.
The story chosen to represent the Peter Davison era of Doctor Who at the BFI’s 50th anniversary screenings was Caves of Androzani. It’s an odd choice, as it is unlike other stories being produced at the time. It’s a excellent story, an excellent script and very well directed. But it’s not fun. The few quips and jokes in the script raised only muted laughter from the audience and, apart from the two leads, every character is flawed. There are no heroes in the story and almost every character dies, an ignominious end awaiting each of them. There are no blazes of glory here. The Doctor doesn’t influence events particularly, he doesn’t right any wrongs. He just wants to cure Peri and get out of there alive. Even then, he only half manages it.
The story was introduced by Mark Gatiss. Half way through. composer Roger Limb talked about his time at the Radiophonic Workshop. By a happy coincidence, the music from Caves of Androzani has just been released on CD.
The discussion panel afterwards was lively. To say the least. After his brief appearance at last month’s screening, I hadn’t expected to see Matthew Waterhouse this month, but there he was. The BFI even showed Adric’s death scene while the panel was on the stage. There was a fair bit of good natured ribbing between Peter and Janet, and some less good natured ribbing of Matthew. But things settled down and Matthew raised some interesting points. A refreshing number of questions from the audience were directed at Graeme Harper, and a fair few people who thanked Peter for being “their Doctor”.
Afterwards a small group of podcasters gathered in the by-now-traditional car park stairwell to review the story and the panel. It will be available from The Doctor Who Podcast Facebook page very soon. You can still download our review of “Robots of Death”, the 4th Doctor BFI screening.
Pin ItLast week I traveled to Oakland to spend a week with my colleagues at Canonical for the Client Sprint. The aim of the sprint was to ensure the many different teams working on Ubuntu Touch at Canonical are in sync and working as efficiently as possible. This largely involves ensuring that the management teams are planning their work effectively, and that everyone is singing from the same hymn sheet.
To provide a little context, at Canonical we are working consistently to deliver a 1.0 Ubuntu Touch platform that is ready for October so it can then be delivered to customers for deployment on handsets in Q1/Q2 2014. This involves a wide variety of design, engineering, and service-delivery projects that currently involves 15 engineering teams, 5 design teams, and 5 services teams, totaling 150+ people. The aim of the sprint was to ensure these 150+ folks are aligned.
Now, some cynical people (who I suspect may need more hugs) think that the sprint is merely a Canonical-only UDS where we make a bunch of private decisions by explicitly excluding the community. Sorry, drama fans, this is not true. We spend our time discussing and managing Canonical staff and resources, talking about product review documents, staff assignments, hardware/IS requirements, reporting structures, stakeholder and customer requirements, and wading through endless spreadsheets to track all of this. We don’t do this at UDS as UDS is not a good event for this kind of team alignment work as we are all spread across multiple tracks (and most of our community would have little interest in these team discussions anyway), hence we have always had sprints to do this.
The sprint had a very definitive format. Every team has a defined set of responsibilities and projects and each team lead prepared a summary of their work, achievements, and blockers. As an example, one project my team has been working on is the skunkworks and core apps projects, and wider app development community growth. I gave a presentation that summarized this work and it provided an opportunity to update the wider team and identify areas in which we can work more efficiently (e.g. one outcome was opening up a more regular communication between myself and the head of the SDK team).
The good news is that things are running really well. The teams were well prepared, great progress is being made on the road to October, and any inter-team and inter-project issues that we did find were quickly and efficiently resolved. For such a large project with so many inter-connecting parts I was pleasantly surprised with just how coordinated everyone seems to be, and I want to thank the many engineering, design, and services managers and leads for their (often understated) leadership and planning. It is complex to coordinate so many moving parts when everyone works in the same office, let alone for such a widely distributed company working from home with so many different timezones.
Of course, there were many topics and projects discussed at the sprint, but there was one topic that resonated throughout the week: getting Ubuntu Touch into a form in which our community can start dog-fooding as soon as possible. In other words, right now you can download the daily Ubuntu Touch images, but you can’t really use it as your main phone; it still comes with a bunch of dummy data, some radio functions don’t work, and there is no way of saving data when you re-flash the device. In the next few months the teams agreed to expedite their work to make the Ubuntu Touch images ready so we can use them as our daily devices, thus opening more opportunities for testing, feedback, functionality edge cases, and more.
I have another sprint coming up this week (the Cloud sprint), but I have asked a number of people who joined the sprint to blog about their progress and updates. Keep your eyes peeled for more.
The new stable version of Debian, codenamed Wheezy, is finally here.
Main features of Debian 7.0 Wheezy are multiarch support,
specific tools to deploy private clouds, a greatly improved
installer and a complete set of multimedia codecs and front-ends which remove the need for third-party
repositories.
For a complete list of new features and updated software, take a look at the
official announcement.
Want to give it a try?
Check out the live images!
Want to install it?
Choose your favourite installation media among Blu-ray Discs, DVDs,
CDs and USB sticks.
Already a happy Debian user and you only want to upgrade?
You are just an apt-get dist-upgrade away from Wheezy!
Find how, reading the installation guide
and the release notes.
Some useful links:
Arbitrary tweets made by TheGingerDog (i.e. David Goodwin) up to 01 May 2013
To recap: given the absence of other credible alternatives I had two options:
I think there is room for a new console client, because mutt is showing its age and does feel like it should have a real extension language - be it guile, lisp, javascript(!), Lua, or something else.
So I distilled what I thought I wanted into three sections:
So how did I do? I wrote a ncurses-based client which has Lua backed into it. You can fully explore the sidebar-mode - which lets you select multiple folders.
From there you can view the messages in a list.
What you can't do is anything "real":
For a two-day hack it is remarkably robust, and allowing scripting shows awesomeness. Consider this:
-- -- show all folders in the Maildir-list. -- function all() -- ensure that the sidebar displays all folders sidebar_mode = "all"; -- we're going to be in "maildir browsing mode" cmail_mode = "sidebar"; reset_sidebar(); refresh_screen(); end -- -- Test code, show that the pattern-searching works. -- -- To use this press ":" to enter the prompt, then enter "livejournal". -- -- OR press "l" when in the sidebar-mode. -- function livejournal() sidebar_pattern = "/.livejournal.2"; sidebar_mode = "pattern"; reset_sidebar(); refresh_screen(); end -- -- There is a different table for each mode. -- keymap = {} keymap['sidebar'] = {} keymap['index'] = {} keymap['message'] = {} -- -- In the sidebar-mode "b" toggles the sidebar <-> index. -- -- ":" invokes the evaluator. -- "q" quits the browser and goes to the index-mode. -- "Q" quits the program entirely. -- keymap['sidebar'][':'] = "prompt-eval" keymap['sidebar']['b'] = "toggle" keymap['sidebar']['q'] = "toggle" keymap['sidebar']['Q'] = "exit" -- show all/unread/livejournal folders keymap['sidebar']['a'] = "all" keymap['sidebar']['u'] = "unread" keymap['sidebar']['l'] = "livejournal"Neat, huh? See the cmail.lua file on github for more details.
My decision hasn't really progressed any further, though I can see that if this client were complete I'd love to use it. Its just that the remaining parts are the fiddly ones.
I guess I'll re-hack mutt, and keep this on the back-burner.
The code is ropey in places, but should you wish to view:
And damn C is kicking my ass.