Linux

I have a Raspberry Pi running Raspbian (wheezy) with a UVC camera available as /dev/video0. I've been trying for three weeks to live-stream the picture from the camera onto the local network. I have tried crtmpserver and vlc, read several dozens of how-tos, but so far I have not been able to get a streaming setup working, no matter what I tried. Hence my plea to the lazy web: does anyone have such a setup running on top of Debian? Would you please let me know how you did it? Thanks a lot! NP: Eels: End Times

All recent articles on packaging using a version control system should really appear over at Planet vcs-pkg. Feel free to just ping me with a feed URL that is vcs-pkg-specific.

I've written an article as monthly one, "Debian Hot Topics", and  this time, teaching steps and ways that how to put packages to Debian official repository. Japanese readers, have fun :)

PyBit is a distributed build system able to build packages in response to VCS commits or other triggers, across multiple architectures, multiple clients and multiple build environments with automated uploads to a nominated repository. Support is included in 1.0.0 for building Debian packages using sbuild in response to subversion commits or changes in debian-devel-changes@lists.debian.org (by using apt as a version control handler) for any architecture and build environment which sbuild can support. There is also an example git commit template. Pybit has been designed to be fully extensible, so support for RPM or other package formats can be added as well as other version control handlers, other build environments and other architectures. Pybit is also scalable, when one type of client is struggling with the workload, another machine of the same architecture can be added to the pool to share the load. Pybit can also build a package for any number of architectures and build environments at the same time. The Pybit web interface provides an at-a-glance summary of all current builds as well as options to blacklist certain combinations, cancel and retry specific jobs and add monitor each pybit client. Current use cases include: Rapidly changing VCS - one or more subversion repositories with lots of Debian packages, built automatically for any number of build environments and architectures every time the debian/changelog is modified. Clean chroot builds provide continuous integration testing of the every package. Rebuilding the archive with different compilers or flags - a dedicated email account subscribed to debian-devel-changes@lists.debian.org feeding messages through procmail to the changes-debian hook, passing build requests to the apt handler to rebuild each package in your own sbuild chroots, using whatever environments, suites and build options can be configured within those chroots. something else we haven't thought of yet ... there is scope for a lot more hooks, package formats, chroot tools and handler plugins. Pybit 1.0.0 has arrived in Debian unstable as a direct result of the efforts put in by the pybit team during a sprint on 18th May 2013. Thanks to everyone involved in Pybit. https://freecode.com/projects/pybit http://nicholasdavidson.github.io/pybit/ https://github.com/nicholasdavidson/pybit

Most UNIX users have heard of the nice utility used to run a command with a lower priority to make sure that it only runs when nothing more important is trying to get a hold of the CPU: nice long_running_script.sh That's only dealing with part of the problem though because the CPU is not all there is. A low priority command could still be interfering with other tasks by stealing valuable I/O cycles (e.g. accessing the hard drive). Prioritizing I/O Another Linux command, ionice, allows users to set the I/O priority to be lower than all other processes. Here's how to make sure that a script doesn't get to do any I/O unless the resource it wants to use is idle: sudo ionice -c3 hammer_disk.sh The above only works as root, but the following is a pretty good approximation that works for non-root users as well: ionice -n7 hammer_disk.sh You may think that running a command with both nice and ionice would have absolutely no impact on other tasks running on the same machine, but there is one more aspect to consider, at least on machines with limited memory: the disk cache. Polluting the disk cache If you run a command (for example a program that goes through the entire file system checking various things, you will find that the kernel will start pulling more files into its cache and expunge cache entries used by other processes. This can have a very significant impact on a system as useful portions of memory are swapped out. For example, on my laptop, the nightly debsums, rkhunter and tiger cron jobs essentially clear my disk cache of useful entries and force the system to slowly page everything back into memory as I unlock my screen saver in the morning. Thankfully, there is now a solution for this in Debian: the nocache package. This is what my long-running cron jobs now look like: nocache ionice -c3 nice long_running.sh Turning off disk syncs Another relatively unknown tool, which I would certainly not recommend for all cron jobs but is nevertheless related to I/O, is eatmydata. If you wrap it around a command, it will run without bothering to periodically make sure that it flushes any changes to disk. This can speed things up significantly but it should obviously not be used for anything that has important side effects or that cannot be re-run in case of failure. After all, its name is very appropriate. It will eat your data!

Thanks to DoctorMo for the hilarious photo. It’s just so good. We’ve got Classes working, the usual fixes from the ‘crew, and native macros. Huzzah!  I’ve had to take the site down for now (well, stop updating it) because of a vulnerability I introduced (macros allow arbitrary code to run), which means, if anyone’s keen, they should add the sandboxing code to the Hy Site as well! More coming soon!

(Posted 17 May 2013 by gg234)

As many of you will know, our goal is to get the Ubuntu phone in a state where it can be used on a daily basis for testing, and importantly, finding bugs, UI issues, and other details that help us to refine the overall Ubuntu Touch experience. Progress is on-track for the end of May. I decided to start dogfooding a little early (please remember, we are shooting for the beginning of July to be broadly in shape for dogfooding, so if you try, don’t expect things to be ready right now), so today I put my SIM card in my Galaxy Nexus with Ubuntu Touch and things are working pretty well so far. It seems that my data is no longer getting wiped on image updates, which helps testing significantly, so I am regularly upgrading with the daily images. As ever, if you decide to test, you are doing so at your own risk…don’t be surprised to see bugs, crashes, and potential data loss (although I have not seen any data loss so far). Some notes about my experience dogfooding: Making and recieving phone calls works well. I am using T-Mobile as my network. Sending and recieving texts works well too. Messages appear chronologically. Contact syncing is not in place but Sergio blogged about how to sync your contacts from Google. This has made my phone infinately more useful and rather nicely, it pulls in the avatars too so I can see who is calling me. Browsing and connecting to wireless networks works well. The browser works well overall, although currently requires wifi (3G browsing coming soon). Camera works well (for still photos, video not implemented yet) and I can browse my pictures in the gallery. Many of the community-written core apps are present and working. Calendar lets me save and browse calendar events (although syncing with a calendar service is not there yet). Weather showes me the weather for my area right now and a week long forcast. Calculator is working and largely feature-complete. Other core apps are on their way to the daily image soon. Overall the core Unity UI is working well. I can search for apps, load them, quit them, multi-tasting works well, and the indicators work (for adjusting volume etc). The primary blockers in my way right now for normal use out and about are: The screen does not auto shut-off. This means if the screen gets turned on in my pocket it never turns off and the battery dies. Speakerphone not wired into the UI yet. Can’t set the time on the phone yet. Also, the alarm feature in the clock doesn’t work; I need this to get me up in the morning. Not so much a blocker, but the phone is still filled with example material and contacts. They need to be removed. All of these are on the TODO list for complettion by the end of the month. I have been filing bugs for a bunch of the issues I am seeing on a day to day basis and the team are working hard to hit the end of May goal. Overall progress is looking good. Although I have been using the daily images for quite some time on a phone without a SIM card, using as an actual phone is even more motivating than before. I can feel the phone coming together and when we get many of these issues fixed, it is going to deliver a far superior experience than the Android phone I was using before.

New submitter Anand Radhakrishnan writes "The release candidate for the much-anticipated Linux Mint 15 'Olivia' is available for user testing. Its many new features include Cinnamon Control center, an improved login manager with HTML 5 support, a driver manager, and a lot of under-the-hood improvements. 'A new tool called MintSources, aka "Software Sources," was developed from scratch with derivative distributions in mind (primarily Linux Mint, but also LMDE, Netrunner and Snow Linux). It replaces software-properties-gtk and is perfectly adapted to managing software sources in Linux Mint. From the main screen you can easily enable or disable optional components and gain access to backports, unstable packages and source code.' This release with Cinnamon looks really tempting." Read more of this story at Slashdot.

If I did everything right, this post will not appear on any RSS feed yet still make it to my blog to maintain history. The UDD bugs interface currently knows about the following release critical bugs: In Total: 1088 Affecting Jessie: 214 That's the number we need to get down to zero before the release. They can be split in two big categories: Affecting Jessie and unstable: 183 Those need someone to find a fix, or to finish the work to upload a fix to unstable: 43 bugs are tagged 'patch'. Please help by reviewing the patches, and (if you are a DD) by uploading them. 15 bugs are marked as done, but still affect unstable. This can happen due to missing builds on some architectures, for example. Help investigate! 125 bugs are neither tagged patch, nor marked done. Help make a first step towards resolution! Affecting Jessie only: 31 Those are already fixed in unstable, but the fix still needs to migrate to Jessie. You can help by submitting unblock requests for fixed packages, by investigating why packages do not migrate, or by reviewing submitted unblock requests. 0 bugs are in packages that are unblocked by the release team. 31 bugs are in packages that are not unblocked. How do we compare to the Squeeze release cycle? Week Squeeze Wheezy Diff 43 284 (213+71) 468 (332+136) +184 (+119/+65) 44 261 (201+60) 408 (265+143) +147 (+64/+83) 45 261 (205+56) 425 (291+134) +164 (+86/+78) 46 271 (200+71) 401 (258+143) +130 (+58/+72) 47 283 (209+74) 366 (221+145) +83 (+12/+71) 48 256 (177+79) 378 (230+148) +122 (+53/+69) 49 256 (180+76) 360 (216+155) +104 (+36/+79) 50 204 (148+56) 339 (195+144) +135 (+47/+90) 51 178 (124+54) 323 (190+133) +145 (+66/+79) 52 115 (78+37) 289 (190+99) +174 (+112/+62) 1 93 (60+33) 287 (171+116) +194 (+111/+83) 2 82 (46+36) 271 (162+109) +189 (+116/+73) 3 25 (15+10) 249 (165+84) +224 (+150/+74) 4 14 (8+6) 244 (176+68) +230 (+168/+62) 5 2 (0+2) 224 (132+92) +222 (+132/+90) 6 release! 212 (129+83) +212 (+129/+83) 7 release+1 194 (128+66) +194 (+128/+66) 8 release+2 206 (144+62) +206 (+144/+62) 9 release+3 174 (105+69) +174 (+105/+69) 10 release+4 120 (72+48) +120 (+72/+48) 11 release+5 115 (74+41) +115 (+74/+41) 12 release+6 93 (47+46) +93 (+47/+46) 13 release+7 50 (24+26) +50 (+24/+26) 14 release+8 51 (32+19) +51 (+32/+19) 15 release+9 39 (32+7) +39 (+32/+7) 16 release+10 20 (12+8) +20 (+12/+8) 17 release+11 24 (19+5) +24 (+19/+5) 18 release+12 2 (2+0) +2 (+2/+0) Graphical overview of bug stats thanks to azhag: