Search Results: "ed"

1 November 2015

Thorsten Alteholz: My Debian Activities in October 2015

FTP assistant This month I marked 492 packages for accept and rejected 50 of them. I had to send only 11 emails to maintainers. Up to now I accepted about 6000 packages, my first one was pexpect_3.0-1 on 20131211.
date package
1 20131211 pexpect_3.0-1
1111 20140506 dochelp_0.1
2121 20140825 cl-parse-number_1.3-1
2222 20140903 node-websocket-driver_0.3.5-1
3333 20150303 libparse-keyword-perl_0.08-1
4242 20150625 python-monotonic_0.2-1
4444 20150708 libmusicbrainz5_5.1.0+git20150707-1
5555 20150928 golang-github-yosssi-ace_0.0.4+git20150515.41.78e48a2-3
So, when do you expect accepted package number 6666, 7777, 8888 and 9999? Squeeze LTS This was my sixteenth month that I did some work for the Squeeze LTS initiative, started by Raphael Hertzog at Freexian. This month I only got a workload of 13.25h. Altogether I uploaded those DLAs: While preparing the libxml2 upload, I mixed up things for the i386 build and so [DLA 334-2] had to follow shortly after [DLA 334-1].
I also prepared a new upload of PHP5 with nine CVEs fixed. I put the i386 and amd64 versions at people.d.o and invite everybody to test them and give positive or negative feedback. The real upload to the archive will happen next week. This month I also had another term of doing frontdesk work and looked for CVEs that are important for Squeeze LTS or could be ignored. Other stuff This month I only polished some packages and uploaded: I also manually closed #711329 and #352421. After adopting package chktex I inherited #352421, which was one of my oldest bugs. It was about emacs longlines-mode support and I could close it without actually fixing something. The longlines-mode vanished from emacs. So, sorry for that

31 October 2015

Dirk Eddelbuettel: RcppArmadillo 0.6.200.2.0

armadillo image Yet another monthly upstream Armadillo update gets us the first changes to the new the 6.* series. This was preceded by two uploads of test released to GitHub-only. These two were tested both against all reverse-dependencies as usual. A matching upload to Debian will follow shortly. Armadillo is a powerful and expressive C++ template library for linear algebra aiming towards a good balance between speed and ease of use with a syntax deliberately close to a Matlab. This release is fairly straightforward with few changes:
Changes in RcppArmadillo version 0.6.200.2.0 (2015-10-31)
  • Upgraded to Armadillo 6.200.0 ("Midnight Blue Deluxe")
    • expanded diagmat() to handle non-square matrices and arbitrary diagonals
    • expanded trace() to handle non-square matrices
Courtesy of CRANberries, there is also a diffstat report for the most recent CRAN 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.

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

Chris Lamb: Free software activities in October 2015

Here is my monthly update covering a large part of what I have been doing in the free software world (previously):
Debian My work in the Reproducible Builds project was also covered in more depth in Lunar's weekly reports (#23, #24, #25, #26).
LTS

This month I have been paid to work 11 hours on Debian Long Term Support (LTS). In that time I did the following:
  • DLA 326-1 for zendframework fixing an SQL injection vulnerability.
  • DLA 332-1 for optipng correcting a use-after-free issue.
  • DLA 333-1 for cakephp preventing a remote Denial of Service attack.
  • DLA 337-1 for busybox fixing a vulnerability when unzipping a specially crafted zip file/
  • DLA 338-1 for xscreensaver preventing a crash when hot-swapping monitors.
Uploads
  • redis New upstream release as well as changing the default UNIX socket location and correctly supporting "cluster" mode config file hardening and redis-sentinel's runtime directory handling under systemd. An update for jessie was also uploaded.
  • python-redis Attempting to get the autopkgtest tests to finally pass.
  • debian-timeline Making the build reproducible.
  • gunicorn New upstream release.

Russ Allbery: Vacation book haul

Reading on vacation always puts me in the mood to buy more books, including a couple that I picked up while on vacation. (I only read one, but that one, Ancillary Mercy, was certainly worth it.) Ta-Nehisi Coates Between the World and Me (non-fiction)
Kameron Hurley Empire Ascendant (sff)
Kameron Hurley Rapture (sff)
Jenny Lawson Furiously Happy (non-fiction)
Ann Leckie Ancillary Mercy (sff)
Kaori Mori Bride's Story: Volume 2 (graphic novel)
Kaori Mori Bride's Story: Volume 3 (graphic novel)
Randall Munroe xkcd: Volume 0 (strip collection)
Jo Walton The Philosopher Kings (sff)
Fumi Yoshinaga oku: Volume 3 (graphic novel) Infidel, the middle book of the Bel Dame Apocrypha trilogy by Kameron Hurley, was out of stock, so I'll have to re-order. I might put in another book order shortly to get that plus a few other things, although really I could just take that time to go read more books. Back from vacation now, so fell out of the reading habit a bit. I've been doing other stuff on the train, but shortly I'll get back into it.

Andrew Cater

Ken Starks (Helios) of Reglue could use your help

I'm not normally one to respond to online appeals for money: there are often far too many of them. Ken Starks is a well known Linux personality who set up a charity to provide needy local people with Linux and recycled machines. He's also a good guy who works hard for this as something he believes in: this is no scam. The Helios Project (from before his own charity merged with another known as Reglue) is also still an SPI project as far as I know

Ken is currently holding a fund raising drive to replace his vehicle used for the Reglue project on Indiegogo. This is probably most of interest to US readers who may be able to treat this as charitable donation - the things he's offering in return for donations are most readily shipped within the US and Canada.

Any and all help would be greatly appreciated.


Jonathan McDowell: Thoughts on the LG G Watch R Android smartwatch

Back in March I was given an LG G Watch R, the first Android Wear smartwatch to have a full round display (the Moto 360 was earlier, but has a bit cut off the bottom of the actual display). I d promised I d get round to making some comments about it once I d had it for a while and have failed to do so until now. Note that this is very much comments on the watch from a user point of view; I haven t got to the point of trying to do any development or other hacking of it. Firstly, it s important to note I already was wearing a watch and have been doing so for all of my adult life. Just a basic, unobtrusive analogue watch (I ve had a couple since I was 18, before that it was pretty much every type of calculator watch available at some point), but I can t remember a period where I didn t. The G Watch R is bulkier than what I was previously wearing, but I haven t found it obtrusive. And I love the way it looks; if you don t look closely it doesn t look like a smart watch (and really it s only the screen that gives it away). Secondly, I already would have taken my watch off at night and when I was showering. So while the fact that the battery on the G Watch R will really only last a day and a half is by far and away its most annoying problem, it s not as bad as it could be for me. The supplied charging dock is magnetic, so it lives on my beside table and I just drop the watch in it when I go to bed. With those details out of the way, what have I thought of it? It s certainly a neat gadget. Being able to see my notifications without having to take my phone out of my pocket is more convenient than I expected - especially when it s something like an unimportant email that I can then easily dismiss by swiping the watch face. My agenda being just a flick away, very convenient, particularly when I m still at the stage of trying to remember where my next lecture is. Having walking directions from Google Maps show up on the watch (and be accompanied by a gentle vibration when I need to change direction) is pretty handy too. The ability to take pictures via the phone camera, not so much. Perhaps if it showed me roughly what I was about to photograph, but without that it s no easier than using the phone interface. It s mostly an interface for consuming information - I ve tried the text to SMS interface a few times, but it s just not reliable enough that I d choose to use it. I ve also been pleased to see it get several updates from LG in the time I ve had it. First the upgrade from Wear 4.4 to Wear 5.1 (probably via 5.0 but I forget), but also the enabling of wifi support. The hardware could always support this, but initially Android Wear didn t and then there was some uncertainty about the FCC certification for the G Watch R. I can t say I use it much (mostly the phone is within range) but it s nice to see the improvements in support when they re available. What about the downsides? Battery life, as mentioned above, is definitely the major one. Mostly a day is fine, but the problem comes if I m ever away. There s no way to charge without the charging dock, so that becomes another things I have to pack. And it s really annoying to have your watch go dead on you midday when you forget to do so. I also had a period where I d frequently (at least once a week) find an Android Wear isn t responding. Wait/Restart? error on the watch screen. Not cool, but thankfully seems to have stopped happening. Finally there s the additional resource requirements it puts on the phone. I have a fairly basic Moto G 4G that already struggles with Ingress and Chrome at the same time, so adding yet another thing running all the time doesn t help. I m sure I could make use of a few more apps if I was more comfortable with loading the phone. The notable point for me with the watch was DebConf. I d decided not to bring it, not wanting the hassle of dealing with the daily charging. I switched back to my old analogue watch (a Timex, if you care). And proceeded to spend 3 days looking at it every time my phone vibrated before realising that I couldn t do that. That marked the point where I accepted that I was definitely seeing benefits from having a smart watch. So when I was away for a week at the start of September, I brought the charger with me (at some point I ll get round to a second base for travel). I was glad I d done so. I m not sure I m yet at the point I d replace it in the event it died, but on the whole I m more of a convert that I was expecting to be.

Petter Reinholdtsen: New book, "Fri kultur" by @lessig, a Norwegian Bokm l translation of "Free Culture" from 2004

People keep asking me where to get the various forms of the book I published last week, the Norwegian Bokm l edition of Lawrence Lessigs book Free Culture. It was published on paper via lulu.com, and is also available in PDF, ePub and MOBI format. I currently sell the paper edition for self cost from lulu.com, but might extend the distribution to book stores like Amazon and Barnes & Noble later. This will double the price and force me to make a profit from selling the book. Anyway, here are links to get the book in different formats: Note that the MOBI version have problems with the table of content, at least with the viewers I have been able to test. And the ePub file have several problems according to epubcheck, but seem to display fine in the viewers I have tested. All the files needed to create the book in various forms are available from the github project page. The project got press coverage from the Norwegian IT news site digi.no. Check out the article "Vil pne politikernes yne for Creative Commons". I've blogged about the project as it moved along. The blogs document the translation progress and insights I had along the way.

Joey Hess: a tiling region manager for the console

Building on top of concurrent-output, and some related work Joachim Breitner did earlier, I now have a kind of equivilant to a tiling window manager, except it's managing regions of the console for different parts of a single program. Here's a really silly demo, in an animated gif: demo2.gif Not bad for 23 lines of code, is that? Seems much less tedious to do things this way than using ncurses. Even with its panels, ncurses requires you to think about layout of various things on the screen, and many low-level details. This, by contrast, is compositional, just add another region and a thread to update it, and away it goes. So, here's an apt-like download progress display, in 30 lines of code. aptdemo.gif Not only does it have regions which are individual lines of the screen, but those can have sub-regions within them as seen here (and so on). And, log-type messages automatically scroll up above the regions. External programs run by createProcessConcurrent will automatically get their output/errors displayed there, too. What I'm working on now is support for multiline regions, which automatically grow/shrink to fit what's placed in them. The hard part, which I'm putting the finishing touches on, is to accurately work out how large a region is before displaying it, in order to lay it out. Requires parsing ANSI codes amoung other things. STM rules There's so much concurrency, with complicated interrelated data being updated by different threads, that I couldn't have possibly built this without Software Transactional Memory. Rather than a nightmare of locks behind locks behind locks, the result is so well behaved that I'm confident that anyone who needs more control over the region layout, or wants to do funky things can dive into to the STM interface and update the data structures, and nothing will ever deadlock or be inconsistent, and as soon as an update completes, it'll display on-screen. An example of how powerful and beuatiful STM is, here's how the main display thread determines when it needs to refresh the display: 
data DisplayChange
        = BufferChange [(StdHandle, OutputBuffer)]
          RegionChange RegionSnapshot
          TerminalResize (Maybe Width)
          EndSignal ()
    ...
                change <- atomically $
                        (RegionChange <$> regionWaiter origsnapshot)
                                 orElse 
                        (RegionChange <$> regionListWaiter origsnapshot)
                                 orElse 
                        (BufferChange <$> outputBufferWaiterSTM waitCompleteLines)
                                 orElse 
                        (TerminalResize <$> waitwidthchange)
                                 orElse 
                        (EndSignal <$> waitTSem endsignal)
                case change of
                        RegionChange snapshot -> do
                ...
                        BufferChange buffers -> do
                ...
                        TerminalResize width -> do
                ...
So, it composes all these STM actions that can wait on various kinds of changes, to get one big action, that waits for all of the above, and builds up a nice sum type to represent what's changed. Another example is that the whole support for sub-regions only involved adding 30 lines of code, all of it using STM, and it worked 100% the first time.
Available in concurrent-output 1.1.0.

30 October 2015

Mike Gabriel: New plugin for GOsa: gosa-plugin-pwreset

For a school customer here in Nothern Germany, I developed another GOsa Add-On this week, the Add-On's name is: Password Management Add-On for GOsa (gosa-plugin-pwreset). This password management and reset tool allows one to administratively mass-reset user passwords in GOsa based on various approaches.
  1. A CSV file can be uploaded containing user IDs and new passwords. The CSV file format for this is: comma-separated, no quotes, two columns (<uid>, <userPassword>).
  2. An organizational unit of the LDAP tree can be selected and for all user accounts in that section of the LDAP tree (i.e., the selected OU and all sub-OUs), new passwords can be set. The passwords will get auto-generated when using this approach.
  3. Other approach needed? Please get in touch and provide me with a description of your potential use case.
Before passwords are actually changed, the site admin has various options: The source code of this new GOsa Add-On is available on Github [1] and has also been uploaded to Debian's NEW queue already. light+love
Mike [1] https://github.com/gosa-project/gosa-plugin-pwreset

Ritesh Raj Sarraf: Fixing broken videos

Post iPhone launch, in this new age, it is common to carry a device capable of capturing high definition images and videos. Most people today carry a high end device capable of capturing video/audio, in the form of a Mobile Phone. This has made us raise our expectation that we should capture most moments, if not all. But as is with everything, sometimes things ditch you right at the moment when you did not want it to. In new age phones, scenarios usually are: you capturing a video and the actual data not written to the disk (battery drain, cpu overheat, software bug: Whatever). Such was my case from the year 2012, where one of the videos was corrupt. Corrupt as in, A/V not in sync. Now everytime I solve a real world problem using Free Software tools, I feel the need to express my gratitude. It also serves as a note for me (and maybe others too), for future, if I run into similar problems. ;-) So as it turns out (in layman terms), a video clip is nothing but 2 streams: Video and Audio. Now most video run at 30 frames per second. And the audio stream synchronizes with the video frames. Sorry, I did not read up beyond that, as I was able to fix my problem. cheekywink So, my thought was that the video stream is not corrupt. It just is rendering at a slower frame rate. So, there were 2 problems. 1: Video rendering slower than the usual 30 fps rate. 2: As a result of 1, audio not being in sync with video. Thanks to gpac tools, even a novice, I was able to quickly separate the streams. And then re-encode the video stream into 30 fps. And then merge the audio + video stream together. And the result: Just awesome. In below steps, Strip the video which results in a raw H264 data file. Similar for audio. And then just re-encode the streams, specifying the framerate. 
MP4Box -add 20121002_164608.mp4#video -raw 1 -new test1
test1_track1.h264
MP4Box -add 20121002_164608.mp4#audio -raw 2 -new test1_audio
test1_audio_track2.aac
MP4Box -add test1_track1.h264:fps=30 -add test1_audio_track2.aac -new test1_audio_30fps.mp4

Categories:

Keywords:

Like:

Dirk Eddelbuettel: littler 0.3.0 -- on CRAN !!

max-heap image A new major release of littler is now available. And for the first time in the nine years since 2006 when Jeff started the effort (which I joined not long after) we are now a CRAN package. This required a rewrite of the build system, foregoing the calls to aclocal, autoheader, automake and leaving just a simpler autoconf layer creating a configure script and a simple src/Makevars.in. Not only does R provide such a robust and well-understood build system (which I got to understand reasonably well given all my R packages, but being on CRAN and leveraging its mechanism for installation and upgrades is clearly worth the change. There may be a moment or two of transition. While we can create a binary in an R package, we cannot (generally) copy to /usr/bin or /usr/local/bin as part of the build process (for lack of write-rights to those directories). So if you do not have r in the $PATH and load the package, it makes a suggestion (which needs a linebreak which I added here): 
R> library(littler)
The littler package provides 'r' as a binary.
You could link to the 'r' binary installed in
'/usr/local/lib/R/site-library/littler/bin/r' from
'/usr/local/bin' in order to use 'r' for scripting.
R>
Similarly, you could copy (or softlink) r to ~/bin if that is in your $PATH. The Debian (and Ubuntu) packages will continue to provide /usr/bin/r as before. Note thah these packages will now be called r-cran-littler to match all other CRAN packages. The NEWS file entry is below.
Changes in littler version 0.3.0 (2015-10-29)
  • Changes in build system
    • First CRAN Release as R package following nine years of source releases
    • Script configure, src/Makevars.in and remainder of build system rewritten to take advantage of the R package build infrastructure
    • Reproducible builds are better supported as the (changing) compilation timestamps etc are only inserted for 'verbose builds' directly off the git repo, but not for Debian (or CRAN) builds off the release tarballs
  • Changes in littler functionality
    • Also source $R_HOME/etc/Rprofile.site and ~/.Rprofile if present
  • Changes in littler documentation
    • Added new vignette with examples
Full details for the littler release are provided as usual at the ChangeLog page. The code is available via the GitHub repo, from tarballs off my littler page and the local directory here -- and now of course all from its CRAN page and via install.packages("littler"). A fresh package has gone to the incoming queue at Debian where it will a few days as the binary packages was renamed from littler to r-cran-littler matching all other CRAN packages. Michael Rutter will probably have new Ubuntu binaries at CRAN once the source package gets into Debian proper. Comments and suggestions are welcome at 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.

Laura Arjona: Look at that nice looking FreedomBox!

This is a guest post by Alberto Fuentes, Debian contributor. Thanks!! I m rebuilding one my home server and decided to take a look at the FreedomBox project as the base for it. The 0.6 version was recently released and I wasn t aware of how advanced the project is already! They have a virtualbox image ready for some quick test. It took me longer to download it than to start using it. Here s is a pic of what it looks like to entice you to try it :) Selection_175
All this is already on debian right now and you can turn any debian sid installation into a FreedomBox just by installing a package. The setup generates everything private on the first run, so even the virtualbox image can be used as the final thing They use Plinth (Django) to integrate the applications into the web interface. More info on how to help integrate more Debian packages here. A live demo is going to be streamed this Friday 30 Oct 2015 and a hackaton is scheduled for this saturday 31 Oct 2015. Cheers!
Filed under: My experiences and opinion Tagged: Debian, English, Freedom, FreedomBox, selfhosting

29 October 2015

B lint R czey: FFmpeg and Kodi arrived to jessie-backports!

FFmpeg Kodi Debian JessieDebian has switched to FFmpeg in testing in July but the work on the package did not stop at that point. After careful testing we can now provide official packages for Jessie users through jessie-backports. See installation instructions here. FFmpeg becoming available in jessie-backports also enabled us to provide Kodi from Debian in the same official repository. Thanks to everyone in the Debian Multimedia Maintainers team, especially Andreas Cadhalpun who is also upstream developer at the FFmpeg project, Reinhard Tartler who maintained FFmpeg then Libav then FFmpeg again in Debian for long years and everyone else I could not name here but helped making this possible!

Mart n Ferrari: Tales from the SRE trenches: SREs are not firefighters

This is the third part in a series of articles about SRE, based on the talk I gave in the Romanian Association for Better Software. If you haven't already, you might want to read part 1 and part 2 first. In this post, I talk about some strategies to avoid drowning SRE people in operational work.

SREs are not firefighters As I said before, it is very important that there is trust and respect between Dev and Ops. If Ops is seen as just an army of firefighters that will gladly put away fires at any time of the night, there are less incentives to make good software. Conversely, if Dev is shielded from the realities of the production environment, Ops will tend to think of them as delusional and untrustworthy.

Common staffing pool for SRE and SWE The first tool to combat this at Google -and possibly a difficult one to implement in small organisations- is to have single headcount budgets for Dev and Ops. That means that the more SREs you need to support your service, the less developers you have to write it. Combined with this, Google offers the possibility to SREs to move freely between teams, or even to transfer out to SWE. Because of this, a service that is painful to support will see the most senior SREs leaving and will only be able to afford less experienced hires. All this is a strong incentive to write good quality software, to work closely and to listen to the Ops people.

Share 5% of operational work with the SWE team On the other hand, it is necessary that developers see first hand how the service works in production, understand the problems, and share the pain of things failing. To this end, SWEs are expected to take on a small fraction of the operational work from SRE: handling tickets, being on-call, performing deployments, or managing capacity. This results in better communication among the teams and a common understanding of priorities.

Cap operational load at 50% One very uncommon rule from SRE at Google, is that SREs are not supposed to spend more than half of their time on "operational work". SREs are supposed to be spending their time on automation, monitoring, forecasting growth... Not on repeatedly fixing manually issues that stem from bad systems.

Excess operational work overflows to SWE If an SRE team is found to be spending too much time on operational work, that extra load is automatically reassigned to the development team, so SRE can keep doing their non-operational duties. On extreme cases, a service might be deemed too unstable to maintain, and SRE support is completely removed: it means the development team now has to carry pagers and do all the operational work themselves. It is a nuclear option, but the threat of it happening is a strong incentive to keep things sane.
The next post will be less about how to avoid unwanted work and more about the things that SRE actually do, and how these make things better. Comment

Daniel Pocock: Lumicall rapid provisioning, Opus support and other enhancements

Thanks to feedback from many people at DebConf15, Lumicall has had a range of improvements over the last couple of months and it is now easier to use and more reliable than ever. Rapid provisioning for Debian.org, FedRTC.org and other SIP accounts 1. Setup your SIP password in the Debian LDAP or the FedRTC account setup (using Fedora OpenID) or any other SIP service that supports rapid provisioning (see the FAQ). 2. Install the Lumicall app from F-Droid, Google Play or by direct download. 3. When the app starts the first time, you can verify your phone number (so other users can call you using the number they know) or just click the "Manual account setup" link underneath the verification button. If you do verify your number, the "Add account" link is also available in the menu from the main screen. Test calls If a friend installs Lumicall too and you dial their number, the Lumicall popup should appear and give you the option to make the call over SIP. You can also make test calls using this link for a recorded announcement. Many other improvements
  • Support for the OPUS codec, which brings us one step closer to direct WebRTC interoperability
  • Fixing a bug in ice4j that caused NAT traversal to fail intermittently
  • Tweaks to make it more tolerant of IPv6 networks
  • The rapid account setup form (described above) for existing SIP accounts
  • Conversion to the Gradle build system (for Android Studio)
  • Breaking out embedded library code from the Lumicall repository into standalone projects so they can be maintained independently
  • Use of the compatibility library to display the ActionBar, consistent with the current design guidelines, while still maintaining compatibility with older devices
  • Use of Spongy Castle instead of Bouncy Castle crypto library for more consistent behavior across different Android devices
Share your experiences with Lumicall All feedback is welcome. If you can come in person to the workshop in Manchester (2 November) or the mini-DebConf in Cambridge (I'll be there Saturday, 7 November) then we can look at any problems in person and access logs with the Android tools if necessary. Discussion is also welcome on the Lumicall users mailing list or the Free RTC mailing list.

Daniel Pocock: reSIProcate 1.10 release

reSIProcate 1.10.0 was released a few weeks ago and after going through the various QA cycles has become available in packages for Debian jessie-backports, EPEL6 and EPEL7 and the latest releases of Fedora and Ubuntu. Key features of the 1.10.x branch: A 1.10.1 release was tagged yesterday and is not yet widely available in packages. This release is only significant for people using RADIUS authentication and keen to change from the FreeRADIUS-client library to radcli.

Joey Hess: concurrent output library

concurrent-output is a Haskell library I've developed this week, to make it easier to write console programs that do a lot of different things concurrently, and want to serialize concurrent outputs sanely. It's increasingly easy to write concurrent programs, but all their status reporting has to feed back through the good old console, which is still obstinately serial. Haskell illustrates problem this well with this "Linus's first kernel" equivilant interleaving the output of 2 threads: 
> import System.IO
> import Control.Concurrent.Async
> putStrLn (repeat 'A')  concurrently  putStrLn (repeat 'B')
BABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABA
BABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABABA
...
That's fun, but also horrible if you wanted to display some messages to the user: 
> putStrLn "washed the car"  concurrently  putStrLn "walked the dog"
walwkaesdh etdh et hdeo gc
ar
To add to the problem, we often want to run separate programs concurrently, which have output of their own to display. And, just to keep things interesting, sometimes a unix program will behave differently when stdout is not connected to a terminal (eg, ls cat). To tame simple concurrent programs like these so they generate readable output involves a lot of plumbing. Something like, run the actions concurrently, taking care to capture the output of any commands, and then feed the output that the user should see though some sort of serializing channel to the display. Dealing with that when you just wanted a simple concurrent program risks ending up with a not-so-simple program. So, I wanted an library with basically 2 functions: 
outputConcurrent :: String -> IO ()
    
createProcessConcurrent :: CreateProcess -> IO whatever
The idea is, you make your program use outputConcurrent to display all its output, and each String you pass to that will be displayed serially, without getting mixed up with any other concurrent output. And, you make your program use createProcessConcurrent everywhere it starts a process that might output to stdout or stderr, and it'll likewise make sure its output is displayed serially. Oh, and createProcessConcurrent should avoid redirecting stdout and stderr away from the console, when no other concurrent output is happening. So, if programs are mostly run sequentially, they behave as they normally would at the console; any behavior changes should only occur when there is concurrency. (It might also be nice for it to allocate ttys and run programs there to avoid any behavior changes at all, although I have not tried to do that.) And that should be pretty much the whole API, although it's ok if it needs some function called by main to set it up: 
import Control.Concurrent.Async
import System.Console.Concurrent
import System.Process
main = withConcurrentOutput $
    outputConcurrent "washed the car\n"
         concurrently 
    createProcessConcurrent (proc "ls" [])
         concurrently 
    outputConcurrent "walked the dog\n"

$ ./demo
washed the car
walked the dog
Maildir/  bin/  doc/  html/  lib/  mail/  mnt/  src/  tmp/
I think that's a pretty good API to deal with this concurrent output problem. Anyone know of any other attempts at this I could learn from? I implemented this over the past 3 days and 320 lines of code. It got rather hairy: It seems to work pretty great though. I got Propellor using it, and Propellor can now run actions concurrently!

28 October 2015

Simon Richter: CEC remote control with Onkyo Receivers

For future reference: if you have an Onkyo AV receiver, these are picky about the CEC logical address of the player. If you have a default installation of Kodi, the default type is "recording device", and the logical address is 14 -- this is rejected. If you change the CEC device configuration, which can be found in .kodi/userdata/peripheral_data/ to use a device_type of 4 (which maps to a logical address of 4), then the receiver will start sending key events to Kodi. You may also need to set your remote control mode to 32910, by pressing the Display button in combination with the input source selector your Pi is connected to for three seconds, and then entering the code. This setting is not available from the GUI, so you really have to change the XML file. Next step: finding out why Kodi ignores these key presses. :(

Daniel Pocock: Free Real-Time Communications workshop in Manchester, 2 November

Manchester Free Software and MadLab are hosting a workshop on Free and Federated Real-Time Communications with Free Software next Monday night, 2 November from 7pm. Add this to your calendar (iCalendar link) Users and developers are invited to come and discover the opportunities for truly free and secure chat, voice and video with WebRTC, mobile VoIP and the free desktop. This is an interactive workshop with practical, hands-on opportunities to explore this topic, see what works and what doesn't and learn about troubleshooting techniques to help developers like myself improve the software. This is also a great opportunity for any Java developers who would like to get some exposure to the Android platform. People wishing to fully participate in all the activities are encouraged to bring a laptop with the Wireshark software and Android tools (especially adb, the command line utility) or if you prefer to focus on WebRTC, have the latest version of Firefox and Chrome installed. If you are keen to run the DruCall module for WebRTC or your own SIP or XMPP server, you can try setting it up as described in the RTC Quick Start Guide and come along to the workshop with any questions you have. A workshop near you? Manchester has a history of great technological innovation, including the first stored program computer and it is a real thrill for me to offer this workshop there. FSFE Manchester ran a workshop evaluating the performance of free software softphones back in 2012. Over the coming months, I would like to be able to hold further workshops in other locations to get feedback from people who are trying this technology, including the Lumicall app, JSCommunicator and DruCall. If you are interested in helping organize such an event or you have any other feedback about this topic, please come and discuss it on the Free RTC mailing list.

Martin-&#201;ric Racine: xf86-video-geode: Last call, dernier s vice

I guess that the time has finally come to admit that, as far as upstream development is concerned, the Geode X.Org driver is reaching retirement age:
While there have indeed been recent contributions by a number of developers to keep it compilable against recent X releases, the Geode driver has accumulated too much cruft from the Cyrix and NSC days, and it hasn't seen any active contribution from AMD in a long time. Besides, nowadays, Xserver pretty much assumes that its runs on an X driver that leverages its matching kernel driver and thus won't require root priviledges to launch. This isn't the case with the Geode driver, since it directly probes FBDEV and MSR, both of which reside in /dev and require root priviledges to access.
On Debian, as a stopgap measure, the package now Recommends a legacy wrapper that enforces operation as root. Meanwhile, other distributions are mercilessly droping all X drivers that don't leverage KMS. Basically, unless a miracle happens really quick, Geode will soon become unusable on X.
Back when AMD was still involved, a concensus had been reached that, since the Geode series doesn't offer any sort of advanced graphic capabilities, the most sensible option would indeed be to make a KMS driver and let Xserver use its generic modeline driver on top of that, then drop the Geode X driver entirely. Amazingly enough, someone did start working on a KMS driver for Geode LX, but it never made it as far as the Linux kernel tree (additionally, Gitorious seems to be down, but I have a copy of the driver's Git tree on hand, if anyone is interested). While I'll still be accepting and merging patches to the Geode X driver, our best long-term option would be to finalize the KMS driver and have it merged into Linux ASAP.

Next.

Previous.