Right on the heels of yesterday's BH release 1.55.0-2 bringing Boost Fusion, we now have release 1.55.0-3 bringing Boost Graph. To recap, BH is our CRAN package providing (a large part of the) Boost C++ libraries as a set of template headers for use by R and of course Rcpp.
And as a small project I am working on--and which should now be so much closer to release--needed not only Boost Fusion but also Boost Graph, I had to bother the CRAN maintainers twice in two days. This new version closes issue ticket 9, and may be of interest to other packages such as the venerable RBGL formerly on CRAN and now a BioConductor package which includes its own copy of this graph library (plus depends).
A brief summary of changes from the NEWS file is below.
Changes in version 1.55.0-3 (2015-01-04)Courtesy of CRANberries, there is also a
- Added Boost Graph requested in GH ticket #9 by Dirk for RcppStreams
diffstat report for the most recent release.
Comments and suggestions are welcome via the mailing list or the issue tracker at the GitHubGitHub repo.
This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.
This was my first month working on Debian LTS. My first project
at Codethink was winding
down, so Freexian's
Debian LTS initiative was able to hire me via Codethink. I spent
all of the assigned 11.5 hours working on an update to the kernel
package (linux-2.6,
version 2.6.32-48squeeze9).
We had stopped following the upstream stable branch maintained by
Willy Tarreau after 2.6.32.60 (released October 2012). Since then, we
have only applied specific security fixes and other critical fixes.
Rapha l Hertzog and Holger Levsen started to rebase our package
on 2.6.32.64 (released November 2014), bringing in a few security
fixes we didn't yet have and a larger number of fixes for functional
and performance issues.
I spent most of my time reviewing the several hundred changes from the
upstream stable branch. I found a number of mistakes that would have
caused regressions. Those should all be fixed in the update to
linux-2.6, though I did not have nearly enough time for a thorough
regression test. I sent my fixes to Willy for inclusion in 2.6.32.65.
I also reviewed and applied fixes for several security flaws in the
kernel entry and exit paths. Andy Lutomirski identified and fixed
a number of problems upstream, the most serious of which was
CVE-2014-9322 (though this is not listed in the changelog because
the details weren't yet public). Willy found and backported the
upstream fixes for inclusion in 2.6.32.65. I checked that these make
sense (so far as I understand this code) and verified that Andy's test
cases now have the expected results when run on the new kernel version.
Updated: Added references to Codethink and Freexian.
My monthly report covers a large part of what I have been doing in the free software world. I write it for my donators (thanks to them!) but also for the wider Debian community because it can give ideas to newcomers and it s one of the best ways to find volunteers to work with me on projects that matter to me.
Debian LTS
This month I have been paid to work 20 hours on Debian LTS. I did the following tasks:
systemctl preset during package installation. I filed bug #772555 to get this fixed (in Stretch, it s too late for Jessie :-().
Saltstack
I m using salt to automate some administration task in Kali, at home and at work. I discovered recently that the project tries to collect Salt Formulas : those are ready to use instructions for as many services as possibles.
I started using this for some simple services and quickly felt the need to extend salt-formula , the set of states used to configure salt with salt. I submitted 5 pull requests (#73 and #74 to configure salt in standalone mode, #75 to enable the upstream package repositories, #76 to automatically download and enable the desired salt formulas, #77 for some bugfixes) and they have all been merged in less than 24 hours (that s the kind of thing that motivates you to contribute again in the future!).
I also submitted a bug fix for samba-formula and a bug report in salt itself (#19180).
BTW I have some salt states to setup schroot and sbuild. I will try to package those as proper salt formulas in the future
Misc stuff
Mailing list governance. In Debian, we often complain about meta-discussion on mailing lists (i.e. discussions about how we discuss together) and at the same time we need to have that kind of discussions from time to time. So I suggested to host those discussions in a new mailing list and to get this new list setup, our rules require to have other people interested in having this list. The idea had some support when we discussed it on debian-private, so I relaunched it on debian-project while filing the official request in the BTS: #772645. Unfortunately, I only got one second. So if you re interested in pursuing this idea, speak up now
Sponsorship. I sponsored another Galette plugin this month: galette-plugin-fullcard. Thanks to Fran ois-R gis Vuillemin for his work.
Publican. Following one of my bug report against Publican and with the help of the upstream author, we identified the problem and I submitted a patch.
Thanks
See you next month for a new summary of my activities.
One comment Liked this article? Click here. My blog is Flattr-enabled.
A new release of BH, our package providing (a large part of the) Boost C++ libraries as a set of template headers for use by R, is now on CRAN.
This is a relatively minor change which expands the set of Boost libraries included in the package to Boost Fusion per issue ticket 7. Boost Fusion is a very clever library providing a fusion of both compile-time meta-programming and run-time programming to provide something similar to the STL (i.e. containers, algorithms, ...) for heterogenous tuples. I also added pointers to both the mailing list and the GitHub issue tracker to the DESCRIPTION file, README and main manual page.
A brief summary of changes from the NEWS file is below.
Changes in version 1.55.0-2 (2015-01-03)Courtesy of CRANberries, there is also a
- Added Boost Fusion requested in GH ticket #7 by Dirk for RcppStreams
diffstat report for the most recent release.
Comments and suggestions are welcome via the mailing list or the issue tracker at the GitHubGitHub repo.
This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.
To work with GnuPG and smartcards you install GnuPG agent, scdaemon, pscsd and pcsc-tools. On Debian you can do it like this:
apt-get install gnupg-agent scdaemon pcscd pcsc-toolsUse the
pcsc_scan command line tool to make sure pcscd recognize the smartcard before continuing, if that doesn t recognize the smartcard nothing beyond this point will work. The next step is to make sure you have the following line in ~/.gnupg/gpg.conf:
use-agentLogging out and into GNOME should start gpg-agent for you, through the
/etc/X11/Xsession.d/90gpg-agent script. In theory, this should be all that is required. However, when you start a terminal and attempt to use the smartcard through GnuPG you would get an error like this:
jas@latte:~$ gpg --card-status gpg: selecting openpgp failed: unknown command gpg: OpenPGP card not available: general error jas@latte:~$The reason is that the GNOME Keyring hijacks the GnuPG agent s environment variables and effectively replaces
gpg-agent with gnome-keyring-daemon which does not support smartcard commands (Debian bug #773304). GnuPG uses the environment variable GPG_AGENT_INFO to find the location of the agent socket, and when the GNOME Keyring is active it will typically look like this:
jas@latte:~$ echo $GPG_AGENT_INFO /run/user/1000/keyring/gpg:0:1 jas@latte:~$If you use GnuPG with a smartcard, I recommend to disable GNOME Keyring s GnuPG and SSH agent emulation code. This used to be easy to achieve in older GNOME releases (e.g., the one included in Debian Wheezy), through the
gnome-session-properties GUI. Sadly there is no longer any GUI for disabling this functionality (Debian bug #760102). The GNOME Keyring GnuPG/SSH agent replacement functionality is invoked through the XDG autostart mechanism, and the documented way to disable system-wide services for a normal user account is to invoke the following commands.
jas@latte:~$ mkdir ~/.config/autostart jas@latte:~$ cp /etc/xdg/autostart/gnome-keyring-gpg.desktop ~/.config/autostart/ jas@latte:~$ echo 'Hidden=true' >> ~/.config/autostart/gnome-keyring-gpg.desktop jas@latte:~$ cp /etc/xdg/autostart/gnome-keyring-ssh.desktop ~/.config/autostart/ jas@latte:~$ echo 'Hidden=true' >> ~/.config/autostart/gnome-keyring-ssh.desktop jas@latte:~$You now need to logout and login again. When you start a terminal, you can look at the
GPG_AGENT_INFO environment variable again and everything should be working again.
jas@latte:~$ echo $GPG_AGENT_INFO /tmp/gpg-dqR4L7/S.gpg-agent:1890:1 jas@latte:~$ echo $SSH_AUTH_SOCK /tmp/gpg-54VfLs/S.gpg-agent.ssh jas@latte:~$ gpg --card-status Application ID ...: D2760001240102000060000000420000 ... jas@latte:~$ ssh-add -L ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDFP+UOTZJ+OXydpmbKmdGOVoJJz8se7lMs139T+TNLryk3EEWF+GqbB4VgzxzrGjwAMSjeQkAMb7Sbn+VpbJf1JDPFBHoYJQmg6CX4kFRaGZT6DHbYjgia59WkdkEYTtB7KPkbFWleo/RZT2u3f8eTedrP7dhSX0azN0lDuu/wBrwedzSV+AiPr10rQaCTp1V8sKbhz5ryOXHQW0Gcps6JraRzMW+ooKFX3lPq0pZa7qL9F6sE4sDFvtOdbRJoZS1b88aZrENGx8KSrcMzARq9UBn1plsEG4/3BRv/BgHHaF+d97by52R0VVyIXpLlkdp1Uk4D9cQptgaH4UAyI1vr cardno:006000000042 jas@latte:~$That s it. Resolving this properly involves 1) adding smartcard code to the GNOME Keyring, 2) disabling the GnuPG/SSH replacement code in GNOME Keyring completely, 3) reorder the startup so that gpg-agent supersedes gnome-keyring-daemon instead of vice versa, so that people who installed the gpg-agent really gets it instead of the GNOME default, or 4) something else. I don t have a strong opinion on how to solve this, but 3) sounds like a simple way forward.
Having seen the end of December and the beginning of January, this is the time of year where we say "Happy new year!"
But this is a very interesting new year: We have also went past our much announced deadline for the <2048 bit keys to be removed from the Debian keyrings. And yes, our highly efficient keyring-maint team managed to deliver on the promised time And, I'd say, with much success. Lets see the numbers Only before that, refer to Jonathan's mail to debian-devel-announce for further, fuller information.
So, first of all, how do overall numbers look? Just remember, the following are not the number of DDs, just the number of active keys. That is, the holders to the 252 DD and 35 DM keys we removed are still valid Debian Developers/Maintainers, but have to get a new key accepted to perform many of their tasks in the project.
The graph above shows the sharp change between tags 2014.12.31 and 2015.01.01. But my definition of success is that we managed to get the number down to just 252+35=287 from what we had back in August, when we did our DebConf presentation and started the aggressive push: 490 DD keys and 49 DM keys. Since then, 34 DDs requested their retirement, becoming emeritus, and practically all of the rest managed to get their key transition done!
So, lets go again easiest-to-hardest. First, the Non-uploading Debian Developers keyring:
As this is the newest keyring in existence, and is also the smallest one, we were already without <2048 keys since 2011. Nothing to see, move along.
Then, as for the Debian Maintainers:
We did have a sensible migration from weaker to stronger keys, but it was not as sharp as I'd have liked. That makes sense, after all, since DMs have less involvement and compromise in the project in regard to DDs. So, we only processed 15 DM keys since August, which is almost a third of the keys we needed to process to reach the ideal 100% migration.
Now, as for our biggest and oldest keyring, and the one that denotes more project involvement, here is the graph for the uploading Debian Developers:
And yes, here you can see the sharp turn we saw in the second half of this year: By DebConf time, we were happy because the red and yellow lines had just crossed. But we were still sitting at 490 DD keys needing to be migrated. Half of the DD keys (compared to almost a fourth for the DM keys).
I'm almost sure we anticipated in our presentation (I know, I should check the video) that, by January 1st, we would have to retire around 300 keys. And I'm very, very happy and proud that we managed to get the number down to 252.
And, yes, people leave things to the end: We already have some more pending requests in the Request Tracker to introduce new keys for our fellow friends who were disabled. We will be working to make keyring pushes more frequent than our usual monthly uploads until requests go back to a sane level.
So, if everything runs smoothly, this will probably be the last of my posts in this regard. This has been quite an interesting (and exhausting!) experience!
audio_output
type "pulse"
name "MPD stream"
#server "remote_server" # optional
sink "rtp" # optional
mixer_type "software"
Then in /etc/pulse/system.pa:
load-module module-null-sink sink_name=rtp format=s16be channels=2 rate=44100 sink_properties="device.description='RTP Multicast Sink'"
load-module module-rtp-send source=rtp.monitor
This tells Pulse to use multicast streaming to the LAN for the audio packets. Pulse is supposed to have latency synchronization to achieve perfect audio everywhere. In practice, this works somewhat poorly. Plus I have to install pulse everywhere, which inserts its tentacles way too deeply into the ALSA stack for my taste. (alsamixer suddenly turns useless by default, for instance.)
But I gave it a try. After much fiddling Pulse is rather poorly documented and the interactions of configuration tools with it even more so I found a working configuration. On my MythTV box, I added:
load-module module-rtp-recv
load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1;x.x.x.x
The real annoyance was getting it to set the output through the S/PDIF digital port. Finally I figured out the magic potion:
set-card-profile 0 output:iec958-stereo+input:analog-stereo
This worked reasonably well. The Raspberry Pi was a much bigger challenge, however.
I put Raspbian on it easily enough, and installed Pulse. But apparently it is well-known in the Pulse community that Pulse s RTP does not work well with wifi. Multicast itself works poorly with wifi in general, and Pulse won t do unicast RTP. However, Pulse assumes very low latency and just won t work well with wifi at all.
Morever, pulseaudio on the rpi is something of a difficult beast to tame. It has crackling audio, etc. I eventually got it working decently with:
daemon.conf:
realtime-scheduling = yes
realtime-priority = 5
resample-method = src-sinc-fastest
default-sample-rate = 44100
default-fragments = 4
default-fragment-size-msec=20
and in system.pa, commented out the module-udev-detect and module-detect, and added:
load-module module-alsa-card device_id=0 tsched=0 fragments=10 fragment_size=640 tsched_buffer_size=4194384 tsched_buffer_watermark=262144
plus the rtp-recv and tcp protocol lines as before. This got it working with decent quality, but it was always out of sync by at least a few tenths of a second, if not a whole second, with the other rooms.
Brief diversion: mplayer
Many players besides pulseaudio can play the RTP streams that pulseaudio generates. mplayer, for instance, can. I found this worked on the Raspberry Pi:
mplayer -really-quiet -cache 64 -cache-min 95 -demuxer rawaudio -rawaudio format=0x20776172 rtp://224.0.0.56:46510
But this produced even worse sync. It became clear that Ampache was not going to be the right solution.
Logitech Media Server
I have looked at this a few times over the years, but I ve somehow skipped it. But I looked at it again now. It is an open source (GPL) server, and was originally designed to work with Logitech hardware. There are now all sorts of software clients out there. There is a helpful wiki about it, although Logitech has rebranded the thing so many times, it s not even consistent internally on what the heck it s called (is it LMS? or Squeezebox Server? or Slimserver? The answer is: yes.)
LMS does no web-based streaming. At all. But I thought I d give it a try. Installation is a little weird (its .deb packages up binary perl modules for things that are already in Debian, for half a dozen architectures and many Perl versions.) I had some odd issues but eventually it worked. It scanned my media collection. I installed squeezelite on my workstation as my first player, and things worked reasonably well out of the box.
I proceeded to install squeezelite on the Raspberry Pi and MythTV server (where I had to compile libsoxr for wheezy, due to an obscure error I couldn t find the cause of until I used strace). Log in to the LMS web interface, tell it to enable synchronization, and bam! Perfect synchronization! Incredible.
But I ran into two issues: one was that it used a lot of CPU even on my workstation (50% or more, even when idle). Strangely, it used far less CPU on the pi than did pulseaudio. Secondly, I d get annoying clicks from it from time to time. Some debugging and investigation revealed that they were both somewhat related; it was getting out of sync with the pi and correcting. Initially I assumed this to be an issue with the pi, but tracked it down to something else. I told it to upsample to 48kHz and this made the problem go away. My command on PC hardware is:
squeezelite -a 200:10 -o dmix -u hLX -z
And on the Raspberry Pi:
squeezelite -a 800:10:16:0 -n kitchen -z
It is working perfectly now.
LMS even has an Android remote control app that can control all devices together, queue up playlists, etc. Very slick.
The Raspberry Pi
The Raspberry Pi, even the model B+, apparently has notoriously bad audio output. I noticed this first as very low volume on the output. I found a $11 USB DAC on Amazon that seems to do the trick, so we will see. I am also using the $10 Edimax USB Wifi and it seems to work well.
Other Options
The big-name other option here is Sonos. They have perfect sync audio already working. But they re pricy, closed, and proprietary; you have to buy Sonos speakers, transmitters, etc. for the entire house. Their receivers start at $200, and it s at least $350 to integrate an existing stereo into the system. I d be shelling out over $1000 to use Sonos for this setup. As it is, I ve bought less than $100 of equipment (a second Pi and its accessories) and getting output that, while no doubt not quite as pristine, it still quite nice and acceptable. Quite nice.
Update: LMS with Apache
It turns out that Logitech Media Server can automatically save created playlists to a spot where Ampache can find them. So an Ampache streaming player can be used to access the same collection LMS uses, with full features. Nice!
Having just blogged about today's 5k, I noticed that I did not blog at all about running in 2014. There wasn't much, but another Ragnar Relay in February, again as an Ultra team. I more-or-less live tweeted this though: Pre-race warning (and that was my route!), Team photo at start, Leg 1, Leg 2, Leg 3, Leg 4, Leg 5, Leg 6, and Chilling
I also ran the Philly Half-Marathon in November following up on the Penn R Workshop, and posted some tweets: Post race selfie, Strava result (thinking it was a 13.5 miler race--WTF), and Post-race chill.
This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.
Nice, crisp and pretty cold morning for the 2015 New Year's 5k. I had run this before with friends: 2003, 2005, 2006 and 2007.
Needless to say, I am a little slower now: A hand-stopped 23:13 for a 7:27 min/mile pace is fine by me given the weather, lack of speedwork in the last few months, and generally reduced running---but also almost a minute slower than the last time I ran this.
In case you're a fellow running geek and into this, Strava has my result nicely aggregated.
This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.
I just watched a CCC
talk
in which the speaker claims Perl is horribly broken. Watching it was
fairly annoying however, since I had to restrain myself from throwing
things at the screen.
If you're going to complain about the language, better make sure you
actually understand the language first. I won't deny that there are a
few weird constructions in there, but hey. The talk boils down to a
claim that perl is horrible, because the list "data type" is "broken".
First of all, Netanel, in Perl, lists are not arrays. Yes, that's
confusing if you haven't done more than a few hours of Perl, but hear me
out. In Perl, a list is an enumeration of values. A variable with an '@'
sigil is an array; a construct consisting of an opening bracket ('(')
followed by a number of comma- or arrow-separated values (',' or '=>'),
followed by a closing bracket, is a list. Whenever you assign more than
one value to an array or a hash, you need to use a list to enumerate the
values. Subroutines in perl also use lists as arguments or return
values. Yes, that last bit may have been a mistake.
Perl has a concept of "scalar context" and "list context". A scalar
context is what a sub is in when you assign the return value of your sub
to a scalar; a list context is when you assign the return value of your
sub to an array or a hash, or when you use the list construct (the
thing with brackets and commas) with sub calls (instead of
hardcoded values or variables) as the individual values. This works as
follows:
sub magic
if (wantarray())
print "You're asking for a list!";
return ('a', 'b', 'c');
else
print "You're asking for a scalar!";
return 'a';
print ("list: ", magic(), "\n");
print "scalar: " . magic() . "\n";
The above example will produce the following output:
You're asking for a list!
list: abc
You're asking for a scalar!
scalar: a
What happens here? The first print line creates a list (because things
are separated by commas); the second one does not (the '.' is perl's
string concatenation operator; as you can only concatenate scalars, the
result is that you call the magic() sub in scalar context).
Yes, seen as how arrays are not lists, the name of the wantarray()
sub is horribly chosen. Anyway.
It is documented that lists cannot be nested. Lists can only be
one-dimensional constructs. If you create a list, and add another list
as an element (or something that can be converted to a list, like an
array or a hash), then the result is that you get a flattened list. If
you don't want a flattened list, you need to use a reference instead.
A reference is a scalar value that, very much like a pointer in C,
contains a reference to another variable. This other variable can be an
array, a hash, or a scalar. But it cannot be a list, because it must be
a variable -- and lists cannot be variables.
If you need to create multi-dimensional constructs, you need to use
references. Taking a reference is done by prepending a backslash to
whatever it is you're trying to take a reference of; or, in the case of
arrays of hashes, one can create an anonymous array or hash with [] resp
. E.g., if you want to add a non-flattened array to a list, you
instead create a reference to an array, like so:
$arrayref = [ 'this', 'is', 'an', 'anonymous', 'array'];
you can now create a multi-dimensional construct:
@multiarray = ('elem1', $arrayref);
Or you can do that in one go:
@multiarray = ('elem1', [ 'this', 'is', 'an', 'anonymous', 'array']);
Alternatively, you can create a non-anonymous array first:
@onedimarray = ('this', 'is', 'not', 'an', 'anonymous', 'array');
@multiarray = ('elem1', \@onedimarray);
In perl, curly brackets can be used to create a reference to anonymous
hashes, whereas square brackets can be used to create a reference to
anonymous arrays. This is all a basic part of the language; if you don't
understand that, you simply don't understand Perl. In other words,
whenever you see someone doing this:
%hash = 'a' => 'b' ;
or
@array = [ '1', '2' ];
you can say that they don't understand the language. For reference, the
assignment to %hash will result in an (unusable) hash with a single
key that is a reference to an anonymous hash (which cannot be accessed
anymore) and a value of undef; the assignment to @array will result
in a two-dimensional array with one element in the first dimension, and
two elements in the second.
The CGI.pm fix which Natanel dismisses in the Q&A part of the talk as a
"warning" which won't help (because it would be too late) is actually
a proper fix, which should warn people in all cases. That is, if you do
this:
%hash = 'name' => $name, 'password' => $cgi->param('password') ;
then CGI.pm's param() sub will notice that it's being called in list
context, and issue a warning -- regardless of whether the user is
passing one or two password query-parameters. It uses the wantarray()
sub, and produces a warning if that returns true.
In short, Perl is not the horribly broken construct that Natanel claims
it to be. Yes, there are a few surprises (most of which exist for
historical reasons), and yes, those should be fixed. This is why the
Perl community has redone much of perl for Perl 6. But the fact that
there are a few surprises doesn't mean the whole language is broken.
There are surprises in most languages; that is a fact of life.
Yes, the difference between arrays and hashes on the one hand, and
lists on the other hand, is fairly confusing; it took me a while to
understand this. But once you get the hang of it, it's not all that
difficult. And then these two issues that Natanel found (which I suppose
could be described as bugs in the core modules) aren't all that
surprising anymore.
So, in short:
Release 0.6.8 of digest package is now on CRAN and will get to Debian shortly.
This release opens the door to also providing the digest functionality at the C level to other R packages. Wush Wu is going to use the murmurHash C implementation in his recently-created FeatureHashing package.
We plan to export the other hashing function as well. Another small change attempts to overcome a build limitation on that other largely-irrelevant-but-still-check-by-CRAN OS.
CRANberries provides the usual summary of changes to the previous version.
This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.
For a recent customer setup of Debian/wheezy on a IBM x3630 M4 server we used my blog entry State of the art Debian/wheezy deployments with GRUB and LVM/SW-RAID/Crypto as a base. But this time we wanted to use (U)EFI instead of BIOS legacy boot.
As usual we went for installing via Grml and grml-debootstrap. We started by dd-ing the Grml ISO to a USB stick ( dd grml64-full_2014.11.iso of=/dev/sdX bs=1M ). The IBM server couldn t boot from it though, as far as we could identify it seems to be related to a problem with the IBM server not being able to properly recognize USB sticks that are registering themselves as mass storage device instead of removable storage devices (you can check your device via the /sys/devices/ /removable setting). So we enabled Legacy Boot and USB Storage in the boot manager of the server to be able to boot Grml in BIOS/legacy mode from this specific USB stick.
To install the GRUB boot loader in (U)EFI mode you need to be able to execute modprobe efivars . But our system was booted via BIOS/legacy and in that mode the modprobe efivars doesnt work. We could have used a different USB device for booting Grml in UEFI mode but because we are lazy sysadmins and wanted to save time we went for a different route instead:
First of all we write the Grml 64bit ISO (which is (U)EFI capable out-of-the-box, also when dd-ing it) to the local RAID disk (being /dev/sdb in this example):
root@grml ~ # dd if=grml64-full_2014.11.iso of=/dev/sdb bs=1MNow we should be able to boot in (U)EFI mode from the local RAID disk. To verify this before actually physically rebooting the system (and possibly getting into trouble) we can use qemu with OVMF:
root@grml ~ # apt-get update root@grml ~ # apt-get install ovmf root@grml ~ # qemu-system-x86_64 -bios /usr/share/qemu/OVMF.fd -hda /dev/sdbThe Grml boot splash comes up as expected, perfect. Now we actually reboot the live system and boot the ISO from the local disks in (U)EFI mode. Then we put the running Grml live system into RAM to not use and block the local disks any longer since we want to install Debian there. This can be achieved not just by the toram boot option, but also by executing grml2ram on-demand as needed from user space:
root@grml ~ # grml2ramNow having the local disks available we verify that we re running in (U)EFI mode by executing:
root@grml ~ # modprobe efivars root@grml ~ # echo $? 0Great, so we can install the system in (U)EFI mode now. Starting with the according partitioning (/dev/sda being the local RAID disk here):
root@grml ~ # parted /dev/sda GNU Parted 3.2 Using /dev/sda Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) mklabel gpt (parted) mkpart primary fat16 2048s 4095s (parted) name 1 "EFI System" (parted) mkpart primary 4096s 100% (parted) name 2 "Linux LVM" (parted) print Model: IBM ServeRAID M5110 (scsi) Disk /dev/sda: 9000GB Sector size (logical/physical): 512B/4096B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 1 1049kB 2097kB 1049kB fat16 EFI System 2 2097kB 9000GB 9000GB Linux LVM (parted) quit Information: You may need to update /etc/fstab.Then setting up LVM with a logical volume for the root fs and installing Debian via grml-debootstrap on it:
root@grml ~ # pvcreate /dev/sda2 Physical volume "/dev/sda2" successfully created root@grml ~ # vgcreate vg0 /dev/sda2 Volume group "vg0" successfully created root@grml ~ # lvcreate -n rootfs -L16G vg0 Logical volume "rootfs" created root@grml ~ # grml-debootstrap --target /dev/mapper/vg0-rootfs --password secret --hostname foobar --release wheezy [...]Now finally set up the (U)EFI partition and properly install GRUB in (U)EFI mode:
root@grml ~ # mkfs.fat -F 16 /dev/sda1 mkfs.fat 3.0.26 (2014-03-07) WARNING: Not enough clusters for a 16 bit FAT! The filesystem will be misinterpreted as having a 12 bit FAT without mount option "fat=16". root@grml ~ # mount /dev/mapper/vg0-rootfs /mnt root@grml ~ # grml-chroot /mnt /bin/bash Writing /etc/debian_chroot ... (foobar)root@grml:/# mkdir -p /boot/efi (foobar)root@grml:/# mount /dev/sda1 /boot/efi (foobar)root@grml:/# apt-get install grub-efi-amd64 [...] (foobar)root@grml:/# grub-install /dev/sda Timeout: 10 seconds BootOrder: 0003,0000,0001,0002,0004,0005 Boot0000* CD/DVD Rom Boot0001* Hard Disk 0 Boot0002* PXE Network Boot0004* USB Storage Boot0005* Legacy Only Boot0003* debian Installation finished. No error reported. (foobar)root@grml:/# ls /boot/efi/EFI/debian/ grubx64.efi (foobar)root@grml:/# update-grub [...] (foobar)root@grml:/# exit root@grml ~ # umount /mnt/boot/efi root@grml ~ # umount /mnt/ root@grml ~ # vgchange -an 0 logical volume(s) in volume group "vg0" now activeThat s it. Now rebooting the system should bring you to your Debian installation running in (U)EFI mode. You can verify this before actually rebooting into the system by using the qemu/OVMF trick from above once again.
A new version of rfoaas is now on CRAN. The rfoaas package provides an interface for R to the most excellent FOAAS service--which provides a modern, scalable and RESTful web service for the frequent need to tell someone to eff off.
This version aligns the rfoaas version number with the (at long last) updated upstream version number, and brings a change suggested by Richie Cotton to set the encoding of the returned object.
As usual, CRANberries provides a diff to the previous release. Questions, comments etc should go to the GitHub issue tracker off the GitHub repo.
This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.
Conrad produced another minor release 4.600 of Armadillo. As before, I had created a GitHub-only pre-release(s) of his pre-release(s), and tested a pre-release as well as the actual release against the now over one hundred CRAN dependents of our RcppArmadillo package. The tests passed fine as usual with less than a handful of checks not passing, all for known cases -- and results are as always in the rcpp-logs repository.
Changes are summarized below based on the NEWS.Rd file.
Changes in RcppArmadillo version 0.4.600.0 (2014-12-27)Courtesy of CRANberries, there is also a diffstat report for the most recent release. As always, more detailed information is on the RcppArmadillo page. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page.
- Upgraded to Armadillo release Version 4.600 ("Off The Reservation")
- added
.head()and.tail()to submatrix views- faster matrix transposes within compound expressions
- faster
accu()andnorm()when compiling with -O3 -ffast-math -march=native (gcc and clang)- workaround for a bug in GCC 4.4
This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.
Next.