Search Results: "ed"

15 December 2013

Alessandro Ghedini: Building Debian packages using Linux namespaces

In the past few days I have been messing around with Linux namespaces, and developed a little tool (pflask) that automates the creation of simple Linux containers based on them (a sort of chroot(8) on steroids if you will). While the whole raison d' tre behind this project was "just because", and many more mature solutions exist, I decided that it'd be nice to find an actual use case for this (otherwise I tend to lose interest pretty quickly) so I wrote a lil (and rather dumb) pbuilder clone that uses pflask instead of chroot. The nice thing about pflask is that, differently from e.g. LXC, it doesn't need any pre-configuration and can be used directly on a vanilla debootstrap(8)ed Debian system:
$ sudo mkdir -p /var/cache/pflask
$ sudo debootstrap --variant=buildd $DIST /var/cache/pflask/base-$DIST-$ARCH
Where $DIST and $ARCH are e.g. unstable and amd64. Once that's done just run pflask-debuild on the package sources:
$ apt-get source somepackage
$ cd somepackage-XYX
$ pflask-debuild
The script will take care of creating a new container, chroot(2)ing into it, installing all the required dependencies, building and signing the package (it also runs lintian!). The main difference from pbuilder is that pflask will mount a copy-on-write filesystem (using AuFS) on the / of the container so that any modification (e.g. installation of packages) can be easily discarded once the container terminates (similarly to what cowbuilder(8) does, modulo the hardlinks hack). Additionally, thanks to the mount namespace created inside the container, all of this will be isolated from the host system and other containers, so that multiple packages can be built simultaneously on the same base debootstrapped directory. Another possibility would be that of disabling the network inside the container using a network namespace, in order to prevent the package build system from downloading stuff from Internet while at the same time maintaining the network active on the host system, but I haven't done any experiment in this direction yet. Note though that all of this is rather crude and experimental, but as a little hack it seems to work rather well (YMMV).

Chris Lamb: Developing responsive websites using the Awesome window manager

Responsive web design is a techinique for offering the optimal user experience across different browser devices without the overhead of separate "mobile" sites or native applications. Whilst there are hundreds of browser plugins that can make it easier to test responsive websites by resizing your browser window, this can also be achieved with a scriptable window manager such as Awesome:
resize = function(width, height, text)
  return function(c)
    local w = capi.screen[c.screen].workarea
    local geo = c:geometry()
    awful.client.floating.set(c, true)
    -- Float before raising
    c:raise()
    naughty.notify(  text = text, timeout = 0.5  )
    c:geometry( 
      x = geo.x,
      -- Constrain Y to workspace or it can start too high
      y = (w.y > geo["y"]) and w.y or geo["y"],
      width = width,
      height = height,
     )
  end
end
resize_reset = function (c)
  awful.client.floating.set(c, false)
end
clientkeys = awful.util.table.join(
  -- [..]
  awful.key(  modkey  , "1", resize( 460, 650, "Extra small")),
  awful.key(  modkey  , "2", resize( 780, 750, "Small")),
  awful.key(  modkey  , "3", resize(1024, 800, "Medium")),
  awful.key(  modkey  , "4", resize(1250, 850, "Large")),
  awful.key(  modkey  , "5", resize_reset)
)
Alt+ 1,2,3,4 will then float and resize the current window to various common device sizes (mine are based on the Bootstrap 3 breakpoints) and Alt+5 will reset it. Not being a plugin has many advantages: not only is it a browser-agnostic solution and one can use keyboard shortcuts not available to plugin developers, it also feels more aesthetically pleasing to solve a problem at the correct abstraction layer.

Daniel Pocock: A bias against Bitcoin?

A statement from the European Banking Authority is warning people about the risks of using Bitcoin for payment and investment/speculation. The press notes that the EBA paper stops short of telling people not to use the digital currency. Many of the points made in the warning appear to be well founded on the facts: however, exactly the same points could be made about everything from gift vouchers to bullion. It is not clear why Bitcoin should be singled out for special attention like this. Yes, gold and silver bullion are not issued by any central authority. Bullion values rise and fall many times in each day. When bullion values dipped earlier in 2013, some short term speculators sold at a loss: but for every scared seller, there was also somebody else willing to buy. Has anybody seen any stories of disgruntled investors throwing their gold out with the rubbish when the market moved? A more interesting example is that of the gift vouchers offered by many chains of retail stores. With many stores going through restructuring and liquidation in recent years, customers holding the vouchers have been left high and dry. Unlike temporary dips in bullion or Bitcoin values, the vouchers have often become truly worthless. The story has been repeated again and again around the world, including HMV in the UK and Mothercare in Australia. Community sense When retailers enter bankruptcy, it is usually at the instigation of a single person such as a prominent shareholder or the lender. Bitcoin and bullion, on the other hand, are arguably much harder for any single person or small group to pull the plug on so dramatically. Their value depends on their widespread acceptance around the globe rather than any single point of failure. Bitcoin's future I'm yet to see any evidence that Bitcoin is a long term store of value. Even the most knowledgeable proponents of Bitcoin agree that it is not technically perfect, due to the lack of true anonymity. When a truly anonymous solution is found, it will be interesting to see if the industry migrates away from Bitcoin. On the other hand, the threat of a truly anonymous community cryptocurrency is a scary thing for governments in the surveillance age. It could be argued that governments may become active players in the Bitcoin market in order to keep more anonymous solutions from gaining market share. For example, if a government was to accept remittence of taxes by Bitcoin or if smaller countries were to use Bitcoin to facilitate foreign exchange (bypassing the use of US dollars) this would make the currency far more credible for other mainstream purposes.

Russell Coker: Dell PowerEdge T110

In June 2008 I received a Dell PowerEdge T105 server to run in my home for a client [1]. That system has run well for over 5 years for the purposes of my client and also as my own home fileserver and as a workstation. But now it s getting a bit old, while it was still basically working the cooling fans were getting noisy, faster systems are available, and it was crashing occasionally which could have been due to hardware or software. On the 7th of November I got a new Dell PowerEdge T110. It s got a i3-3220 CPU (speed of 4218 according to cpubenchmark.net) which is a lot better than the AMD 1212 (speed of 982). It takes up to 4*3.5 SATA disks (as opposed to 2 disks) and has more options for memory expansion. Next time I run out of disk space I ll add another RAID-1 pair of disks instead of buying new disks. Generally this system is much the same as the one it replaces. It s a cheap server which unfortunately lacks sound hardware and usable video hardware. Sound is a problem I already solved with USB speakers but for the new system I bought a PCIe video card. Fortunately the system has PCIe*16 sockets (which apparently only have PCIe*8 wires) which avoids the problem I had in the past trying to obtain a suitable video card. The crashes turned out to be due to BTRFS and now that I ve made some tweaks everything is running well. I ll probably buy another Dell PowerEdge in about 5 years time.

Hideki Yamane: my Desktop Environment broken - any help?


Recently, my GNOME environment was broken suddenly. Startup GNOME Shell cause segfault and die. I cannot use GDM3 at all.

henrich@hp:~ $ grep gnome-shell /var/log/syslog
Dec 15 10:51:12 hp kernel: [34944.969581] gnome-shell[10054]: segfault at 84 ip 00007f6c6186a7b9 sp 00007fff59f1dbc0 error 4 in libcogl.so.12.1.1[7f6c61821000+97000]
Dec 15 10:51:12 hp gnome-session[9565]: WARNING: Application 'gnome-shell.desktop' killed by signal 11
Dec 15 10:51:14 hp kernel: [34946.429046] gnome-shell[10202]: segfault at 84 ip 00007ffa2ae877b9 sp 00007fff2bc5c7d0 error 4 in libcogl.so.12.1.1[7ffa2ae3e000+97000]
Dec 15 10:51:14 hp gnome-session[9565]: WARNING: Application 'gnome-shell.desktop' killed by signal 11
Dec 15 10:51:14 hp gnome-session[9565]: WARNING: App 'gnome-shell.desktop' respawning too quickly
So, I've switched to KDM, and install xfce4. However, I faced to another problem - it cannot show any icons (desktop and panel).


Odd Chromium window (why red?).


Also eog says "Could not load image" "Unrecognized image file format" - Well, why? It's just a .png file. (screenshot on KDE4)
Shotwell cause segfault, too :-( (and some other GTK applications)

I cannot point out broken component. Dear lazyweb, could you tell me how to fix this situation, please?


14 December 2013

Dirk Eddelbuettel: RcppDE 0.1.2

A maintenance release (now at version 0.1.2) of my RcppDE package (previously described in these two posts) is now CRAN. More details about the package are available in the vignette also included in the RcppDE R package. Changes were minimal and driven mostly by some CRAN Policy changes which now prefer vignette sources files in (top-level) directory vignettes/ Courtesy of CRANberries, there is also a diffstat report for the most recent release. Current and previous releases are available here as well as on CRAN.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Dirk Eddelbuettel: random 0.2.2

A maintenance release of my random package for truly (hardware-based) random numbers (pulled from random.org) is now on CRAN. It's been a while since previous releases. The package is described in a detailed vignette as well as in a essay by Mads Haahr. Changes were minimal and driven mostly by some CRAN Policy changes which now prefer vignette sources files in (top-level) directory vignettes/ Courtesy of CRANberries, there is also a diffstat report for the most recent release. Current and previous releases are available here as well as on CRAN.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Dirk Eddelbuettel: gcbd 0.2.5

A maintenance release (now at version 0.2.5) of my gcbd package (described only in these two posts) is now CRAN. More details about the package are available in the paper which is also included in the gcbd R package. Changes were minimal and driven mostly by some CRAN Policy changes which now prefer vignette sources files in (top-level) directory vignettes/ Courtesy of CRANberries, there is also a diffstat report for the most recent release.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Richard Hartmann: SteamOS

So SteamOS has been released. While that's marginally interesting in and as of itself, there are two observations to be made:
  1. Microsoft, Nintendo, and Sony will feel an impact. More functionality on cheaper hardware which can easily by upgraded; I bet quite a few managers are not happy, at the moment.
  2. While the stand-alone Linux Steam client was initially targeted at Ubuntu, SteamOS is based on Debian Wheezy.
Actual Linux (not Android) for the end user The first one means more Linux installations. In the living room. On a machine that children are really focussed on and will want to play with, quite literally. The next logical step is for people who play games to install SteamOS on their other machines; desktops, laptops, everywhere they want to game. This could really be the tipping point where the average adolescent computer enthusiast does not need to reboot into Linux to fool around with, but the other way round: To need to boot to Windows for a few select legacy applications which don't run on the FLOSS variant of Wine like Office or Photoshop. And once this momentum starts to shift, other software vendors will follow the money trail. Could 2014 finally be.... the year of Linux on the desktop...? Debian vs Debian-based The latter one is also really interesting... Obviously, I don't know why Valve decided to go down this road, but there are several reasons which come to mind: What we are left with is a major player entering the ring of Linux for end-users and choosing Debian over Ubuntu. Hopefully, improvements to the base system will be fed back upstream, enabling all Debian-based distributions to profit easily, not only Ubuntu-based ones. I am willing to bet that two years ago, SteamOS would have been based on Ubuntu, not Debian. Recently, there's been a lot of backlash over various decisions which Canonical forced onto Ubuntu and it will be interesting to see how this plays out in the long run... I will be interesting to see how much pain Linux Mint and Kubuntu will endure. Forecast Users All in all, we are looking at a massive influx of new users into the Debian ecosystem. How massive? 65 million registered users massive. 7 million concurrent users at once, 1.2 million users actively playing the top 100 games at the same time massive. This is huge. Contributors In time, a substantial part of that userbase will switch over one or more of their machines over to SteamOS. The tinkerers among them will realize they can install plain Debian and install Steam as a package. The hackers among those will start to improve upon their systems; and what better way to do that then to go upstream? If even a tiny fraction of users makes it this far, the count of actively involved contributors with Debian will skyrocket if we let them join. Raspbian and some other not-quite-ideal decisions come to mind. Vendors Commercial software vendors need to stay profitable. Thus, they are forced to support distributions which promise enough paying users. In the past, this meant mainly SuSE and Red Hat; they had commercial backers, went through certifications, etc. In the recent past, this also meant Ubuntu. All of a sudden, Debian stable has a potential market of tens of millions of average computer users and computer enthusiasts. A lot of whom will want to continue to use their OS of choice at work, as well. Oh boy...

NOKUBI Takatsugu: The 1st Debian mokumoku meeting

I attended the 1st Debian mokumoku meeting. mokumoku ( ) means silently and concentrativeness in Japan. There were about 6 people in a room. I tried to prepare release of Namazu and KAKASI. debmoku

Charles Plessy: Tired

This morning when preparing the update of a package, and I saw a PNG file in its documentation. Even before opening it, I felt old, tired, distressed and unable to escape the situation. Inspecting the file confirmed that the image was not hand made. The source file is missing. The proof: anther image in the same directory has the same style and a SVG source. To make things worse, there are no instructions on how to generate the PNG from the SVG. More and more in these cases, I give up and abandon the package. I lost time and energy make Upstream some requirements for which I personally have no concrete interest. SVG in addition to PNG is better, but PNG alone for the documentation of a Free software is Free enough for me. However, the points of view expressed on debian-devel give me the impression that it is not good enough for Debian, so I just give up

13 December 2013

Gerfried Fuchs: [dunkelbunt]

Tuesday was a really nice evening. A few weeks ago I found a poster about the concert of [dunkelbunt], and got my ticket only on monday. I was told by the ticket sellers that they still have plenty left. In the end when I turned up at the event at tuesday though the concert hall was fully packed with people and I was told that it actually was sold out. There wasn't much place inside the hall left, so I mostly stood in the doorway to the bar area and enjoyed the music from there. If you listen to their songs you might get an idea why the music catched me and I started to let the music move my body, literally. It's a great feeling after a tough day, and there were some other nice people around which let the same happen to them so it did feel less awkward for me. Anyway, if you want to find out if their music can do the same to you, here are some songs to listen to: Enjoy!

/music permanent link Comments: 1 Flattr this

Keith Packard: xserver-warnings

Cleaning up X server warnings So I was sitting in the Narita airport with a couple of other free software developers merging X server patches. One of the developers was looking over my shoulder while the X server was building and casually commented on the number of warnings generated by the compiler. I felt like I had invited someone into my house without cleaning for months embarrassed and ashamed that we d let the code devolve into this state. Of course, we ve got excuses the X server code base is one of the oldest pieces of regularly used free software in existence. It was started before ANSI-C was codified. No function prototypes, no const , no void * , no enums or stdint.h. There may be a few developers out there who remember those days (fondly, of course), but I think most of us are glad that our favorite systems language has gained a lot of compile-time checking in the last 25 years. We ve spent time in the past adding function prototypes and cleaning up other warnings, but there was never a point at which the X server compiled without any warnings. More recently, we ve added a pile of new warning flags when compiling the X server which only served to increase the number of warnings dramatically. The current situation With the master branch of the X server and released versions of the dependencies, we generate 1047 warnings in the default build. -Wcast-qual considered chatty The GCC flag, -Wcast-qual, complains when you cast a pointer and change the const qualifier status. A very common thing for the X server to do is declare pointers as const to mark them as immutable once assigned. Often, the relevant data is actually constructed once at startup in allocated memory and stored to the data structure. During server reset, that needs to be freed, but free doesn t take a const pointer, so we cast to (void *), which -Wcast-qual then complains about. Loudly. Of the 1047 warnings, 380 of them are generated by this one warning flag. I ve gone ahead and just disabled it in util/macros for now. String constants are a pain The X server uses string constants to initialize defaults for font paths, configuration options, font names along with a host of other things. These end up getting stored in variables that can also take allocated storage. I ve gone ahead and declared the relevant objects as const and then fixed the code to suit. I don t have a count of the number of warnings these changes fixed; they were scattered across dozens of X server directories, and I was fixing one directory at a time, but probably more than half of the remaining warnings were of this form. And a host of other warnings Fixing the rest of the warnings was mostly a matter of stepping through them one at a time and actually adjusting the code. Shadowed declarations, unused values, redundant declarations and missing printf attributes were probably the bulk of them though. Changes to external modules Instead of just hacking the X server code, I ve created patches for other modules where necessary to fix the problems in the right place. Getting the bits In case it wasn t clear, the X server build now generates zero warnings on my machine. I m hoping that this will also be true for other people. Patches are available at:
xserver - git://people.freedesktop.org/~keithp/xserver warning-fixes
fontsproto - git://people.freedesktop.org/~keithp/fontsproto fontsproto-next
mesa/drm - git://people.freedesktop.org/~keithp/drm warning-fixes
util/macros - already upstream on master
Keeping our house clean Of course, these patches are all waiting until 1.15 ships so that we don t accidentally break something important. However, once they re merged, I ll be bouncing any patches which generate warnings on my system, and if other people find warnings when they build, I ll expect them to send patches as well. Now to go collect the tea cups in my office and get them washed along with the breakfast dishes so I won t be embarrassed if some free software developers show up for lunch today.

Daniel Kahn Gillmor: OpenPGP Key IDs are not useful

Fingerprints and Key IDsOpenPGPv4 fingerprints are made from an SHA-1 digest over the key's public key material, creation date, and some boilerplate. SHA-1 digests are 160 bits in length. The "long key ID" of a key is the last 64 bits of the key's fingerprint. The "short key ID" of a key is the last 32 bits of the key's fingerprint. You can see both of the key IDs as a hash in and of themselves, as "32-bit truncated SHA-1" is a sort of hash (albeit not a cryptographically secure one). I'm arguing here that short Key IDs and long Key IDs are actually useless, and we should stop using them entirely where we can do so. We certainly should not be exposing normal human users to them. (Note that I am not arguing that OpenPGP v4 fingerprints themselves are cryptographically insecure. I do not believe that there are any serious cryptographic risks currently associated with OpenPGP v4 fingerprints. This post is about Key IDs specifically, not fingerprints.)Key IDs have serious problemsAsheesh pointed out two years ago that OpenPGP short key IDs are bad because they are trivial to replicate. This is called a preimage attack against the short key ID (which is just a truncated fingerprint). Today, David Leon Gil demonstrated that a collision attack against the long key ID is also trivial. A collision attack differs from a preimage attack in that the attacker gets to generate two different things that both have the same digest. Collision attacks are easier than preimage attacks because of the birthday paradox. dlg's colliding keys are not a surprise, but hopefully the explicit demonstration can serve as a wakeup call to help us improve our infrastructure. So this is not a way to spoof a specific target's long key ID on its own. But it indicates that it's more of a worry than most people tend to think about or plan for. And remember that for a search space as small as 64-bits (the long key ID), if you want to find a pre-image against any one of 2k keys, your search is actually only in a (64-k)-bit space to find a single pre-image. The particularly bad news: gpg doesn't cope well with the two keys that have the same long key ID:
0 dkg@alice:~$ gpg --import x
gpg: key B8EBE1AF: public key "9E669861368BCA0BE42DAF7DDDA252EBB8EBE1AF" imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)
0 dkg@alice:~$ gpg --import y
gpg: key B8EBE1AF: doesn't match our copy
gpg: Total number processed: 1
2 dkg@alice:~$ 
This probably also means that caff (from the signing-party package) will also choke when trying to deal with these two keys. I'm sure there are other OpenPGP-related tools that will fail in the face of two keys with matching 64-bit key IDs. We should not use Key IDs I am more convinced than ever that key IDs (both short and long) are actively problematic to real-world use of OpenPGP. We want two things from a key management framework: unforgability, and human-intelligible handles. Key IDs fail at both. So reasonable tools should not expose either short or long key IDs to users, or use them internally if they can avoid them. They do not have any properties we want, and in the worst case, they actively mislead people or lead them into harm. What reasonable tool should do that? How to replace Key IDs If we're not going to use Key IDs, what should we do instead? For anything human-facing, we should be using human-intelligible things like user IDs and creation dates. These are trivial to forge, but people can relate to them. This is better than offering the user something that is also trivial to forge, but that people cannot relate to. The job of any key management UI should be to interpret the cryptographic assurances provided by the certifications and present that to the user in a comprehensible way. For anything not human-facing (e.g. key management data storage, etc), we should be using the full key itself. We'll also want to store the full fingerprint as an index, since that is used for communication and key exchange (e.g. on calling cards). There remain parts of the spec (e.g. PK-ESK, Issuer subpackets) that make some use of the long key ID in ways that provide some measure of convenience but no real cryptographic security. We should fix the spec to stop using those, and either remove them entirely, or replace them with the full fingerprints. These fixes are not as urgent as the user-facing changes or the critical internal indexing fixes, though. Key IDs are not useful. We should stop using them.Tags: collision, crypto, gpg, openpgp, pgp, security

Tanguy Ortolo: Pure Sensia digital and Internet radio receiver: good idea, bad design

Thanks to a corporate reward program, I just got a Pure Sensia digital and Internet radio receiver: basically, it is a device able to play streams from FM, DAB, HTTP and USB sticks. In overall, it works fine, and it has a remote controller, so it makes a nice addition to my home equipment, but it has what I consider a major flaw, which I suspect to have been designed on purpose.For playing streams from FM or DAB, the process is rather simple: you select a frequency and it plays, nothing else is involved. I did not try USB yet but it should be similar: you select a file or a playlist and it plays it. But for HTTP streams, it is quite different: you select a stream from a the Pure Connect directory which is a list of HTTP streaming services maintained by the manufacturer Pure. This raises three concerns:
  1. If all HTTP stream access is made from that remote directory, it probably means Pure knows, and possibly logs, every stream you listen to. That is not acceptable.
  2. What will happen when that service is shut down? Not if it is shut down, mind you, but when it is, because it will, since I never heard of any company keeping a service forever, or any company lasting forever itself actually. Well, here is what will happen: all these digital and Internet radio receivers will become digital but not Internet radio receiver. That is not acceptable: when you buy a radio receiver, you buy a device, not a service of indefinite term.
  3. What do you do if you want to listen to an HTTP stream which is not listed on Pure's directory? Answer of Pure's support: you can add custom streams by URL to your Pure account's favourites. Well, good try, but that is not enough or rather, that is too much: requiring a Pure account to do that, is an artificial restriction, which suffers from exactly the same flaw as the Pure directory. And letting a single company know every Internet stream you listen to is not acceptable either.
Considering that flaw, here is my overall comment about that radio receiver: it is based on a good idea, and it has a good overall design, but it implements it in a precarious way. If you buy one of these things, you should know that you are not buying a complete digital and Internet radio receiver but only a digital radio receiver with some Internet features with privacy concerns, which will work for a time and one day stop working on Pure's decision.

Sylvain Le Gall: Release of OASIS 0.4.0

I am happy to announce that OASIS v0.4.0 has just been released. Logo OASIS small OASIS is a tool to help OCaml developers to integrate configure, build and install systems in their projects. It should help to create standard entry points in the source code build system, allowing external tools to analyse projects easily. This tool is freely inspired by Cabal which is the same kind of tool for Haskell. You can find the new release here and the changelog here. More information about OASIS in general on the OASIS website. I have recently resumed my work on OASIS and this will be hopefully the new version that will lead to quicker iteration in the development of OASIS. The development process was slowdown by the fact, that I feared introducing new fields in _oasis or regression. This was a pain and I decided to change my development model. Features The most important step is the introduction of AlphaFeatures and BetaFeatures fields. They allow to introduce pieces of code that will only be activated if certain features are listed in those fields. It should help to be always ready to release. The features also cover other aspect like flag_tests and flag_docs which has been introduced in OASIS v0.3.0. In fact the features API is now used to introduce all enhancement while keeping backward compatibility with regard to OASISFormat. Rather than defining a ~since_version:0.3 for fields we use a feature that handle the maturity level of the feature. When I feel a specific feature is ready to ship, I just change the InDev Alpha to InDev Beta and then SinceVersion 0.4. On the long term, when we won't support anymore a version of OASIS that existed before the SinceVersion, the feature will always be true and I will fully integrate it in the code. The only constraint around features is: if you use AlphaFeatures or BetaFeatures field, you must use the latest OASISFormat... Features section in the manual. Example of features available: Automate Another topic is automation of testing releases. For OASIS v0.3.0, I ran tests on all platforms manually, late in the development of v0.3.0 and it was painful to fix. So I have decided to setup a Jenkins instance that automate testing on Linux. On the long term, I plan to also setup a Mac OS X builder and start looking at Windows as well. This should help me catch errors early and be able to fix them quickly. However, for v0.4.0 I have decided to just release what I have and which has mainly be tested on Linux. The point here is to quickly release and iterate, rather than wait for perfection. Hopefully end user testing will allow to quickly discover new bugs. Time boxed release In the coming months, I will try to do time boxed releases. I will try to release version of OASIS every 15th of the month. The point here is to try to iterate faster and avoid long delay between release. See you in 1 month for the next release.

Jonathan McCrohan: Linux Kernel Contributor

Having used GNU/Linux systems for some time now, and having submitted patches to a fair number of open source projects, it is nice to finally get a patch accepted into the biggest open source project of them all, the Linux kernel. While I did submit a kernel patch to OpenWrt back in 2011, it is maintained as a rebased patchset, and was never upstreamed to Linus' tree. That changed today though, when a small patch I (had forgotten I had) sent to the linux-media mailinglist back in October 2013, was just pulled by Linus Torvalds into his tree for the Linux 3.13-rc4 release; so I'm now proud to be able to call myself a contributor to the Linux Kernel. :-)

Daniel Pocock: xWiki: 10 years and a WebRTC success story

Six months ago, I wrote to the leaders of several open source web frameworks and asked them about their vision for WebRTC and if they would come to the WebRTC Conference in Paris this week (now finished). The most promising response was from Ludovic Dubost, founder of the xWiki project. Ludovic successfully demonstrated their shiny new WebRTC capabilities today in front of an audience including many far more experienced telephony operators who are still only getting to terms with this technology. What is xWiki? Don't let the wiki name limit your perception of this project. xWiki is a lot more than just another wiki hosting framework. As a bare minimum, you can certainly use it in the same way as other wikis, doing lightweight markup that is easier than HTML. On the other hand, xWiki really shines when it comes to extensibility. The xWiki team are Java developers and so xWiki appeals most to other Java developers who may want to leverage some library code from their web portal from time to time, without even having to compile anything. Here are some examples and here is one of the most trivial ones:
 velocity 
Your username is $xcontext.getUser(), welcome to the site.
 /velocity 
WebRTC capabilities The xWiki team chose XMPP as a chat protocol (using the Candy XMPP JavaScript chat) as the foundation for real-time communication. They have then extended this by creating a custom signalling mechanism and making it convenient for users of a chat session to upgrade the session to voice/video with a mouseclick. The whole experience works within the browser without any plugins. 10 years of xWiki It was also xWiki's 10th birthday today and this provided the perfect opportunity for a party: cjdns and enigmabox While at the xWiki office, it was interesting to see a lot of innovative work taking place, including this VoIP setup where a Grandstream phone is attached to an Enigmabox operated by Caleb from the cjdns project.

11 December 2013

C.J. Adams-Collier: I miss you. Please come back?

I_miss_you._Please_come_back
...
Creating var directory '/usr/src/git/debian/pkg-mariadb/builddir/mysql-test/var'...
Checking supported features...
MariaDB Version 5.5.32-MariaDB-1
Installing system database...
 - SSL connections supported
Collecting tests...
Using server port 42388
==============================================================================
TEST                                      RESULT   TIME (ms) or COMMENT
--------------------------------------------------------------------------
worker[1] Using MTR_BUILD_THREAD 300, with reserved ports 16000..16019
oqgraph.basic                            [ skipped ]  No OQGraph
oqgraph.binlog                           [ skipped ]  No OQGraph
sphinx.sphinx                            [ skipped ]  No Sphinx
archive.archive-big                      [ skipped ]  Test needs --big-test
binlog.binlog_multi_engine               [ skipped ]  ndbcluster disabled
binlog.binlog_spurious_ddl_errors        [ disabled ]  BUG#11761680 2013-01-18 astha Fixed on mysql-5.6 and trunk
binlog.binlog_truncate_innodb            [ disabled ]  BUG#11764459 2010-10-20 anitha Originally disabled due to BUG#42643. Product bug fixed, but test changes needed
federated.federated_server               [ skipped ]  Test needs --big-test
...

Daniel Pocock: Get WebRTC going faster

On Saturday, Lumicall began offering free calls from browser to mobile using the free and open WebRTC technology. It should be no surprise that the service has been popular. Is it really free and open? The only way to prove this technology is free is to help people implement this for themself. On Monday, I uploaded reSIProcate v1.9.0 beta7 packages to Debian. The reSIProcate SIP proxy, repro, is one of the core components of the solution behind the free Lumicall service. Simply install the repro and resiprocate-turn-server packages using apt-get and make the following changes to the configuration (use your own IP addresses of course). I've taken this diff from my own runtime environment, only hiding my passwords, so that you can see exactly how I got it working:
--- repro.config.orig	2013-12-11 17:36:27.179228324 +0100
+++ repro-ws.sip5060.net.config	2013-12-11 17:48:24.159938649 +0100
@@ -143,6 +143,41 @@
 # Transport6TlsClientVerification = None
 # Transport6RecordRouteUri = sip:h1.sipdomain.com;transport=WS
 
+Transport1Interface = 195.8.117.57:80
+Transport1Type = WS
+Transport1RecordRouteUri = auto
+
+Transport2Interface = 2001:67c:1388:1000::57:80
+Transport2Type = WS
+Transport2RecordRouteUri = auto
+
+Transport3Interface = 195.8.117.57:5060
+Transport3Type = TCP
+Transport3RecordRouteUri = auto
+
+Transport4Interface = 2001:67c:1388:1000::57:5060
+Transport4Type = TCP
+Transport4RecordRouteUri = auto
+
+Transport5Interface = 195.8.117.57:443
+Transport5Type = WSS
+#Transport5RecordRouteUri = auto
+Transport5TlsDomain = ws.sip5060.net
+Transport5TlsClientVerification = None
+Transport5RecordRouteUri = sip:ws.sip5060.net;transport=WSS
+Transport5TlsCertificate = /etc/ssl/ssl.crt/ws.sip5060.net-bundle.crt
+Transport5TlsPrivateKey = /etc/ssl/private/ws.sip5060.net-key.pem
+
+Transport6Interface = 2001:67c:1388:1000::57:443
+Transport6Type = WSS
+#Transport6RecordRouteUri = auto
+Transport6TlsDomain = ws.sip5060.net
+Transport6TlsClientVerification = None
+Transport6RecordRouteUri = sip:ws.sip5060.net;transport=WSS
+Transport6TlsCertificate = /etc/ssl/ssl.crt/ws.sip5060.net-bundle.crt
+Transport6TlsPrivateKey = /etc/ssl/private/ws.sip5060.net-key.pem
+
+
 # Comma separated list of DNS servers, overrides default OS detected list (leave blank 
 # for default)
 DNSServers =
@@ -455,7 +490,7 @@
 ForceRecordRouting = false
 
 # Assume path option
-AssumePath = false
+AssumePath = true
 
 # Disable registrar
 DisableRegistrar = false
@@ -481,7 +516,7 @@
 # WARNING: Before enabling this, ensure you have a RecordRouteUri setup, or are using
 # the alternate transport specification mechanism and defining a RecordRouteUri per
 # transport: TransportXRecordRouteUri
-DisableOutbound = true
+DisableOutbound = false
 
 # Set the draft version of outbound to support (default: RFC5626)
 # Other accepted values are the versions of the IETF drafts, before RFC5626 was issued
@@ -505,7 +540,7 @@
 # WARNING: Before enabling this, ensure you have a RecordRouteUri setup, or are using
 # the alternate transport specification mechanism and defining a RecordRouteUri per
 # transport: TransportXRecordRouteUri
-EnableFlowTokens = false
+EnableFlowTokens = true
 
 # Enable use of flow-tokens in non-outbound cases for clients detected to be behind a NAT.  
 # This a more selective flow token hack mode for clients not supporting RFC5626.  The 

This is a diff against the /etc/repro/repro.config file distributed in the Debian package version 1.9.0~beta7-1. In the example above, I've included WSS transport defintions for WebSockets over TLS. Use the standard procedure for creating webserver SSL certificates to create certificates for repro and make sure you insert the correct filenames in the TLS parameters above. I've also duplicated every transport for IPv6. If you don't want TLS/WSS or IPv6, just comment those entries out (and renumber the remaining transports). Web-based SIP proxy setup Once you have repro running, go to the web admin interface (port 5080, username: admin, password: admin) and finish the setup using the web UI. The following steps are essential:
  • Add your domain (and restart the repro daemon after adding your domain)
  • Add some users
  • Add any routes to external services (optional - in my next blog I'll demonstrate how to route WebRTC calls to Asterisk using the Debian packages and less than 20 lines of configuration)
Set up reTurn, the TURN server Just put your IP addresses in /etc/reTurnServer.config and add the following line to /etc/reTurnServer-users.txt:
test:notasecret:reTurn:authorized
IMPORTANT: the realm in the users file (reTurn in the example and default config) must be identical to the AuthenticationRealm in the /etc/reTurnServer.config file. On your own web site Simply install your own apache server and clone the webrtc.lumicall.org demo site. Modify the file js/custom.js and include the settings for your own server.
# cd /var/www
# mkdir webcall
# cd webcall
# wget -r -nH http://webrtc.lumicall.org
# vi js/custom.js
In the custom.js, make sure you use a ws:// URL if you didn't set up SSL certificates and use a wss:// URL if you did. The IP or domain of your repro server must be in the ws:// or wss:// URL. Now navigate to the URL ending with /webcall on your server. For RHEL, Fedora and other RPM users Can somebody please assist with the review of the cajun-jsonapi dependency package so I can upload this new version of reSIProcate to Fedora? I'm also planning to make v1.9.0 available in EPEL6 when it is released in January. Questions? Please come and ask questions or discuss your experiences on the Free RTC mailing list sponsored by FSF Europe.

Next.

Previous.