Planet Debian

Subscribe to Planet Debian feed
Planet Debian - http://planet.debian.org/
Updated: 1 hour 1 min ago

Daniel Pocock: Silent data loss exposed

14 January, 2015 - 03:06

I was moving a large number of image files around and decided to compare checksums after putting them in their new home.

Ouf of several thousand files, about 80GB of data, I found that seventeen of them had a checksum mismatch.

Running md5sum manually on each of those was showing a correct checksum, well, up until the sixth file and then I found this:

$ md5sum DSC_2624.NEF
94fc8d3cdea3b0f3479fa255f7634b5b  DSC_2624.NEF
$ md5sum DSC_2624.NEF
25cf4469f44ae5e5d6a13c8e2fb220bf  DSC_2624.NEF
$ md5sum DSC_2624.NEF
03a68230b2c6d29a9888d2358ed8e225  DSC_2624.NEF

Yes, each time I run md5sum on the same file it gives a different result. Out of the seventeen files, I found one other displaying the same problem and the others gave correct checksums when I ran md5sum manually. Definitely not a healthy disk, or is it?

This is the reason why checksumming filesystems like Btrfs are so important.

There are no errors or warnings in the logs on the system with this disk. Silent data loss at its best.

Is the disk to blame though?

It may be tempting to think this is a disk fault, most people have seen faulty disks at some time or another. In the old days you could often hear them too. There is another possible explanation though: memory corruption. The data read from disk is normally cached in RAM and if the RAM is corrupt, the cache would return bad data.

I dropped the read cache:

# echo 3 > /proc/sys/vm/drop_caches 

and tried md5sum again and observed the file checksum is now correct.

It would appear the md5sum command had been operating on data in the page cache and the root cause of the problem is memory corruption. Time to run a memory test and then replace the RAM in the machine.

Jonathan McDowell: Tracking a ship around the world

13 January, 2015 - 23:07

I moved back from the California Bay Area to Belfast a while back and for various reasons it looks like I'm going to be here a while, so it made sense to have my belongings shipped over here. They haven't quite arrived yet, and I'll do another post about that process once they have, but I've been doing various tweets prefixed with "[shipping]" during the process. Various people I've spoken to (some who should know me better) thought this was happening manually. It wasn't. If you care about how it was done, read on.

I'd been given details of the ship carrying my container, and searching for that turned up the excellent MarineTraffic which let me see the current location of the ship. Turns out ships broadcast their location using AIS and anyone with a receiver can see the info. Very cool, and I spent some time having a look at various bits of shipping around the UK out of interest. I also found the ship's itinerary which give me some idea of where it would be calling and when. Step one was to start recording this data; it was time sensitive and I wanted to be able to see historical data. I took the easy route and set up a cron job to poll the location and itinerary on an hourly basis, and store the results. That meant I had the data over time, if my parsing turned out to miss something I could easily correct it, and that I wasn't hammering Marine Traffic while writing the parsing code.

Next I wanted to parse the results, store them in a more manageable format than the HTML, and alert me when the ship docked somewhere or set off again. I've been trying to learn more Python rather than doing my default action of turning to Perl for these things, and this seemed like a simple enough project to try out. Beautiful Soup seemed to turn up top for HTML parsing in Python, so that formed the basis. Throwing the info into a database so I could do queries felt like the right move so I used SQLite - if this had been more than a one off I'd have considered looking at PostgreSQL and its GIS support. Finally Tweepy made it very easy to tweet from Python in about 4 lines of code. The whole thing weighed in at only 175 lines of code, mostly around pulling the info out of the HTML and then a little to deal with checking for state changes against the current status and the last piece of info in the database.

The pieces of information I chose to store were the time of the update (i.e. when the ship sent it, not when my script ran), reported area, reported state, the position + course, reported origin, reported destination and eta. The fact this is all in a database makes it very easy to do a few queries on the data.

How fast did the ship go?

sqlite> SELECT MAX(speed) FROM status;
MAX(speed)
21.9

What areas did it report?

sqlite> SELECT area FROM status GROUP BY area;
area
-
Atlantic North
California
Caribbean Sea
Celtic Sea
English Channel
Hudson River
Pacific North
Panama Canal

What statuses did we see?

sqlite> SELECT status FROM status GROUP BY status;
status
At Anchor
Moored
Stopped
Underway
Underway using Engine

Finally having hourly data lets me draw a map of where the ship went. The data isn't complete, because the free AIS info depends on the ship being close enough to a receiving station. That means there were a few days in the North Atlantic without updates, for example. However there's enough to give a good idea of just how well traveled my belongings are, and it gave me an excuse to play with OpenLayers.

(Apologies if the zoom buttons aren't working for you here; I think I need to kick the CSS in some manner I haven't quite figured out yet.)

Erich Schubert: Big data predictions for 2015

13 January, 2015 - 22:01
My big data predictions for 2015:
  1. Big data will continue to fail to deliver for most companies.
    This has several reasons, including in particular: 1: lack of data to analyze that actually benefits from big data tools and approaches (and which is not better analyzed with traditional tools). 2: lack of talent, and failure to attract analytics talent. 3: stuck in old IT, and too inflexible to allow using modern tools (if you want to use big data, you will need a flexible "in-house development" type of IT that can install tools, try them, abandon them, without going up and down the management chains) 4: too much marketing. As long as big data is being run by the marketing department, not by developers, it will fail.
  2. Project consolidation: we have seen hundreds of big data software projects the last years. Plenty of them on Apache, too. But the current state is a mess, there is massive redundancy, and lots and lots of projects are more-or-less abandoned. Cloudera ML, for example, is dead: superseded by Oryx and Oryx 2. More projects will be abandoned, because we have way too many (including much too many NoSQL databases, that fail to outperform SQL solutions like PostgreSQL). As is, we have dozens of competing NoSQL databases, dozens of competing ML tools, dozens of everything.
  3. Hype: the hype will continue, but eventually (when there is too much negative press on the term "big data" due to failed projects and inflated expectations) move on to other terms. The same is also happening to "data science", so I guess the next will be "big analytics", "big intelligence" or something like that.
  4. Less openness: we have seen lots of open-source projects. However, many decided to go with Apache-style licensing - always ready to close down their sharing, and no longer share their development. In 2015, we'll see this happen more often, as companies try to make money off their reputation. At some point, copyleft licenses like GPL may return to popularity due to this.

Dirk Eddelbuettel: RcppGSL 0.2.3

13 January, 2015 - 09:33

A new version of RcppGSL is now on CRAN today. This package provides an interface from R to the GNU GSL using our Rcpp.

Similar to the recent RcppClassic release, this update was triggered by the CRAN maintainers desire to keep the Makefile free of GNU make extensions. At the same time we simplified the configure file a little, and refreshed the look and feel of the vignette.

No user-facing changes were made.

The NEWS file entries follows below:

Changes in version 0.2.3 (2015-01-10)
  • The src/Makevars.in was pruned of GNU make features at the request of the CRAN Maintainers

  • configure.ac and configure were updated, and shortened

  • The RcppGSL-intro.Rnw vignette was updated for its look and feel.

Courtesy of CRANberries, a summary of changes to the most recent release is available.

More information is on the RcppGSL 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.

Daniel Pocock: Lumicall: big steps forward, help needed

13 January, 2015 - 03:02

I've recently made more updates to Lumicall, the free, open source and secure alternative to Viber and Skype.

Here are some of the highlights:

  • The dialing popup is now optional, so if you want to call your friends with Lumicall / SIP but they don't want to see the popup when making calls themselves, you can disable the popup on their phone.
  • The dialer popup now shows results asynchronously so you can dial more quickly
  • SIP SIMPLE messaging is now supported, Lumicall is now taking on WhatsApp
  • Various bugs in the preferences/settings have been fixed and adding SIP accounts is now easier
  • Dialing with a TURN relay is now much more reliable
  • It is now possible to redial SIP calls in the call history without seeing the nasty Android bug / popup telling you that you don't have Internet calling configured
F-Droid not updated yet

F-Droid is not yet carrying the latest version. The F-Droid team may need assistance as they appear to be reviewing a lot of the third-party dependencies used by apps they distribute to make sure the full stack is 100% free software. If people want to continue having the option to get Lumicall and other free software through F-Droid instead of Google Play then helping the F-Droid community is the number one way you can help Lumicall.

Other ways you can help, even without coding

You don't have to be a developer to help with Lumicall.

Taking on Viber, Skype and now WhatsApp as well may not sound easy. It isn't. Your help could make the difference though.

Here are some of the things that need assistance:

  • Helping to get it on Wikipedia, they keep deleting the page while happily hosting pages about similar products like Sipdroid and CSipSimple
  • Helping get the latest dependencies and Lumicall version into F-Droid
  • UI design ideas
  • Web site assistance
  • Documentation and screenshots, e.g. for use with Asterisk and FreeSWITCH and various SIP proxies
  • Translation
  • Messaging: to be the default SMS app on an Android device, Lumicall would need a full messaging UI and the ability to replace all functions of the default SMS app. Can anybody identify any other free software that does this and is modular enough to share the relevant code with Lumicall?
  • ZRTP: can you help improve the ZRTP stack used by Lumicall?
Try SIP SIMPLE messaging

When composing a message to a Lumicall user, the SIP address is written sip:number @sip5060.net. E.g. if the number is +442071234567 then the SIP address to use when calling or composing a message is sip:+442071234567 @sip5060.net

Debian Developers should be able to interact with Lumicall users from rtc.debian.org using the SIP over WebSocket messaging.

Getting the latest Lumicall

It is available from:

Petter Reinholdtsen: Norwegian Bokmål subtitles for the FSF video User Liberation

13 January, 2015 - 03:00

A few days ago, the Free Software Foundation announced a new video explaining Free software in simple terms. The video named User Liberation is 3 minutes long, and I recommend showing it to everyone you know as a way to explain what Free Software is all about. Unfortunately several of the people I know do not understand English and Spanish, so it did not make sense to show it to them.

But today I was told that English subtitles were available and set out to provide Norwegian Bokmål subtitles based on these. The result has been sent to FSF and made available in a git repository provided by Github. Please let me know if you find errors or have improvements to the subtitles.

Ritesh Raj Sarraf: What firmware

13 January, 2015 - 02:04

Dear Lazy Web,

I have  an HP Envy J104TS laptop. Recently I saw an interesting message in the kernel log.

[99360.969652] [Firmware Bug]: battery: (dis)charge rate invalid.

Does anybody know what firmware is it referring to here ? I don't think the current set of firmwares shiped by linux are involved in battery related information. Is it the BIOS ?

[95474.561491] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[95474.803578] r8169 0000:0f:00.0 eth0: link down
[95474.803627] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[95474.933797] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[95477.111599] wlan0: authenticate with 00:03:7f:fe:00:02
[95477.127389] wlan0: send auth to 00:03:7f:fe:00:02 (try 1/3)
[95477.129315] wlan0: authenticated
[95477.131352] wlan0: associate with 00:03:7f:fe:00:02 (try 1/3)
[95477.133605] wlan0: RX AssocResp from 00:03:7f:fe:00:02 (capab=0x411 status=0 aid=3)
[95477.133686] wlan0: associated
[95477.133703] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[99125.123138] device vethNLAABF entered promiscuous mode
[99125.123377] IPv6: ADDRCONF(NETDEV_UP): vethNLAABF: link is not ready
[99125.188568] IPv6: ADDRCONF(NETDEV_CHANGE): vethNLAABF: link becomes ready
[99125.188615] lxcbr0: port 1(vethNLAABF) entered forwarding state
[99125.188631] lxcbr0: port 1(vethNLAABF) entered forwarding state
[99140.239301] lxcbr0: port 1(vethNLAABF) entered forwarding state
[99360.969652] [Firmware Bug]: battery: (dis)charge rate invalid.
[99361.729291] NMI watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter.
[99361.864205] EXT4-fs (dm-2): re-mounted. Opts: errors=remount-ro,data=writeback,commit=0
[99361.905210] EXT4-fs (sda6): re-mounted. Opts: data=ordered,commit=0
[102236.267648] lxcbr0: port 1(vethNLAABF) entered disabled state
[102236.556452] lxcbr0: port 1(vethNLAABF) entered disabled state
[102236.557476] device vethNLAABF left promiscuous mode
[102236.557483] lxcbr0: port 1(vethNLAABF) entered disabled state
Categories: Keywords: 

Russell Coker: Systemd Notes

13 January, 2015 - 01:07

A few months ago I gave a lecture about systemd for the Linux Users of Victoria. Here are some of my notes reformatted as a blog post:

Scripts in /etc/init.d can still be used, they work the same way as they do under sysvinit for the user. You type the same commands to start and stop daemons.

To get a result similar to changing runlevel use the “systemctl isolate” command. Runlevels were never really supported in Debian (unlike Red Hat where they were used for starting and stopping the X server) so for Debian users there’s no change here.

The command systemctl with no params shows a list of loaded services and highlights failed units.

The command “journalctl -u UNIT-PATTERN” shows journal entries for the unit(s) in question. The pattern uses wildcards not regexs.

The systemd journal includes the stdout and stderr of all daemons. This solves the problem of daemons that don’t log all errors to syslog and leave the sysadmin wondering why they don’t work.

The command “systemctl status UNIT” gives the status and last log entries for the unit in question.

A program can use ioctl(fd, TIOCSTI, …) to push characters into a tty buffer. If the sysadmin runs an untrusted program with the same controlling tty then it can cause the sysadmin shell to run hostile commands. The system call setsid() to create a new terminal session is one solution but managing which daemons can be started with it is difficult. The way that systemd manages start/stop of all daemons solves this. I am glad to be rid of the run_init program we used to use on SE Linux systems to deal with this.

Systemd has a mechanism to ask for passwords for SSL keys and encrypted filesystems etc. There have been problems with that in the past but I think they are all fixed now. While there is some difficulty during development the end result of having one consistent way of managing this will be better than having multiple daemons doing it in different ways.

The commands “systemctl enable” and “systemctl disable” enable/disable daemon start at boot which is easier than the SysVinit alternative of update-rc.d in Debian.

Systemd has built in seat management, which is not more complex than consolekit which it replaces. Consolekit was installed automatically without controversy so I don’t think there should be controversy about systemd replacing consolekit.

Systemd improves performance by parallel start and autofs style fsck.

The command systemd-cgtop shows resource use for cgroups it creates.

The command “systemd-analyze blame” shows what delayed the boot process and
systemd-analyze critical-chain” shows the critical path in boot delays.

Sysremd also has security features such as service private /tmp and restricting service access to directory trees.

Conclusion

For basic use things just work, you don’t need to learn anything new to use systemd.

It provides significant benefits for boot speed and potentially security.

It doesn’t seem more complex than other alternative solutions to the same problems.

https://wiki.debian.org/systemd

http://freedesktop.org/wiki/Software/systemd/Optimizations/

http://0pointer.de/blog/projects/security.html

Related posts:

  1. systemd – a Replacement for init etc The systemd projecct is an interesting concept for replacing init...
  2. Some Notes on DRBD DRBD is a system for replicating a block device across...
  3. licence for lecture notes While attending LCA it occurred to me that the lecture...

Chris Lamb: Giant's Causeway puzzle

12 January, 2015 - 17:34

Over Christmas I found the above puzzle at my parent's house. I don't know if it has a name but it seemed apt to name it after The Giant's Causeway.

The idea is that you swap and/or rotate the outer tiles until the colours at the edges match. The center tile is fixed, or at least I assume it is as the wooden edges are deliberately less rounded.

Of course, solving it manually would be boring so here's a dumb brute force solution. I actually admire how inefficient and stupid it is...

import itertools

class Tile(list):
    def __getitem__(self, x):
        return super(Tile, self).__getitem__(x % len(self))

    def rotate(self, x):
        return Tile(self[x:] + self[:x])

COLOURS = ('YELLOW', 'WHITE', 'BLACK', 'RED', 'GREEN', 'BLUE')
YELLOW, WHITE, BLACK, RED, GREEN, BLUE = range(len(COLOURS))

TILES = (
    Tile((WHITE, YELLOW, RED, BLUE, BLACK, GREEN)),
    Tile((RED, BLUE, BLACK, YELLOW, GREEN, WHITE)),
    Tile((WHITE, BLACK, YELLOW, GREEN, BLUE, RED)),
    Tile((WHITE, BLUE, GREEN, YELLOW, BLACK, RED)),
    Tile((GREEN, BLUE, BLACK, YELLOW, RED, WHITE)),
    Tile((RED, YELLOW, GREEN, BLACK, BLUE, WHITE)),
)

CENTER = Tile((WHITE, BLACK, RED, GREEN, BLUE, YELLOW))

def pairwise(it):
    a, b = itertools.tee(it)

    next(b, None)

    return itertools.izip(a, b)

def validate(xs):
    for idx, x in enumerate(xs):
        if x[idx + 3] != CENTER[idx]:
            raise ValueError("Tile does not match center")

    for idx, (a, b) in enumerate(pairwise(xs)):
        if a[idx + 2] != b[idx + 5]:
            raise ValueError("Tile does not match previous anticlockwise tile")

    return xs

def find_solution():
    # For all possible tile permutations..
    for xs in itertools.permutations(TILES):

        # ... try all possible rotations
        for ys in itertools.product(range(len(COLOURS)), repeat=len(COLOURS)):
            try:
                return validate([x.rotate(y) for x, y in zip(xs, ys)])
            except ValueError:
                pass

    raise ValueError("Could not find a solution.")

for x in find_solution():
    print ', '.join(COLOURS[y] for y in x)

This prints (after 5 minutes!):

$ python giants.py
GREEN, BLUE, RED, WHITE, BLACK, YELLOW
WHITE, BLUE, GREEN, YELLOW, BLACK, RED
YELLOW, GREEN, BLACK, BLUE, WHITE, RED
GREEN, WHITE, YELLOW, RED, BLUE, BLACK
RED, BLUE, BLACK, YELLOW, GREEN, WHITE
BLUE, BLACK, YELLOW, RED, WHITE, GREEN
python giants.py  269.08s user 0.02s system 99% cpu 4:29.36 total

UPDATE: Seems like this puzzle is called "Circus Seven". Now to dust off my Prolog...

Dirk Eddelbuettel: rfoaas 0.1.1

12 January, 2015 - 06:24

A brand new and shiny 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 f$#@ off.

There are two (internal) changes of merit in this version. First off, as FOAAS was refactored upstream, we are now forced to supply an accept: text/plain http request header. Which, sadly enough, is not something the url() function in R can do---so we brought in more cavalry and now depend on the httr package by Hadley, and use its GET() method. A second change is that we added a (simple but effective enough) regression test which simply calls all foaas entry points available throug rfoaas, and compares this to the anticipated result. To run it, you need to set an environment variable RunFOAASTests=yes as eg out Travis script does. Finally, we aligned the version number with upstream to signal that we cover all available entry points of that version.

As usual, CRANberries provides a diff to the previous release. Questions, comments etc should go to the GitHub issue tracker.

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

Enrico Zini: halmerweg

12 January, 2015 - 04:20
<3 Bremen

Greedy people exploit our cultural differences to justify fighting wars to seize wealth for themselves, when sharing and enjoying cultural diversity makes us far richer than if we possess material wealth!

From a recursive murales in Bremen Halmerweg.

Diego Escalante Urrelo: Practical contentment and art

12 January, 2015 - 03:55

I was browsing Eric Kim’s street photography blog, when I stumbled across one article about the well-known “Gear Acquisition Syndrome” that plagues enthusiast photographers.

Gear Acquisition Syndrome is the obsession that enthusiasts tend to have for new gear, new gadgets, new stuff, as an excuse for not developing their skills or taking action. You can recognize it by phrases like: If only I had that new gear, I would be better at what I do… I can’t do that project until I buy this gear… My super expensive camera is not good for that, I need an even more expensive one… (etc).

The article, “How to Be Grateful For What You Have” is a funny and well argued look on why photographers, or artists in general, can get lost in what they don’t have, instead of what they have.

The article is a recommended read in itself and delivers the point whether you are into photography or not. That said, inside the article I found three nice links worth noting:

The Tiny Collective
A group of photographers that use only their phones as their camera. It’s inspiring to see a specific, curated, selection of images made with phones. It definitely makes you wonder why would you need anything but a phone to make great images (answer: phones work great, even old ones).

A Guide to Practical Contentment
One of the most simple and effective messages about contentment that I have read. It’s not about “not wanting things” or settling for “whatever”. It’s all about taking a step back and realizing that life is not about absolutes. If you are not a billionaire, that doesn’t mean you have failed in life. Perhaps you are just a millionaire, and that’s fine :).

(…) if you start in this place of fixing what’s wrong with you, you keep looking for what else is wrong with you, what else you need to improve. So maybe now feel like you don’t have enough muscles, or six pack abs, or you think your calves don’t look good, or if it’s not about your body, you’ll find something else.

So it’s this never-ending cycle for your entire life. You never reach it. If you start with a place of wanting to improve yourself and feeling stuck, even if you’re constantly successful and improving, you’re always looking for happiness from external sources. You don’t find the happiness from within, so you look to other things.

If you’re externally looking for happiness, it’s easy to get too into food, or shopping, or partying, or overwork, to try to be happy.

If instead, you can find contentment within and not need external sources of happiness, then you’ll have a reliable source of happiness.

So, instead of looking at sources of external happiness, why don’t you look into sources of internal happiness? It’s one of the hardest things to learn how to do, but I’m personally slowly getting there. It’s life changing.

Bonus points: quotes on simplification and minimalism
For extra credit, here are some interesting quotes on the above topics, note that as every internet quote page it might be filled with false quotes. I happen to like the one attributed to Donald Horban, who apparently doesn’t exist outside quote pages in the internet. Maybe that’s the biggest minimalism? Not existing?

“We don’t need to increase our goods nearly as much as we need to scale down our wants. Not wanting something is as good as possessing it.”

Anyway, take these with a grain of salt, and just read them as interesting phrases. Just take it easy :).

Russ Allbery: Short catch-up haul

11 January, 2015 - 09:51

First weekend back home after being away for the holidays. That was a lot of fun, but it's also nice to be back home with all my stuff and my normal schedule. Apparently nice enough that today I went on a productivity binge and did lots of random chores that had been building up. Quite satisfying.

This is a catch-up haul post for a few random things that popped up over the past few months apart from a full book order.

Ibraheem Abbas and Yasser Bahjatt — HWJN (sff)
Ibraheem Abbas and Yasser Bahjatt — Somewhere! (Hunaak!) (sff)
Shannon Appelcline — Designers & Dragons: The '70s (non-fiction)
Shannon Appelcline — Designers & Dragons: The '80s (non-fiction)
Shannon Appelcline — Designers & Dragons: The '90s (non-fiction)
Shannon Appelcline — Designers & Dragons: The '00s (non-fiction)
Tor.com — Some of the Best from Tor.com: 2014 (sff anthology)

The Appelcline four-volume history of RPGs was a gift from a friend, and a lovely set of books. The first two were available for free on the Kindle (as was the last) as part of an effort to publicize Arab SF, and I always like to broaden my cultural reading horizons.

Steve McIntyre: UEFI Debian installer work for Jessie, part 5

11 January, 2015 - 08:49

Time for another update on my work for UEFI improvements in Jessie!

I've spent more time on the integration of 32-bit grub-efi with a 64-bit Debian system, and just published a new test image on pettersson. I've added:

  • a patch to the Linux kernel add a new /sys file which exposes the size of the underlying UEFI platform (32- or 64-bit). (I'd add a link, but gmane.org seems to be down atm!)
  • a patch to grub2 to read that new /sys file in grub-install to determine the right version of grub-efi to install by default
  • a patch to grub-installer to do similar

These remove the manual steps that were necessary for a 64-bit installation with the previous build. I've just used this exact image (and a network mirror) to install a fully-functional 64-bit Gnome system on the X205TA, simply by selecting "64-bit install" from the GRUB menu and following prompts. Yay! Visit http://cdimage.debian.org/cdimage/unofficial/efi-development/jessie-upload3/ to download and test the image.

Now, there's no guarantee that the kernel patch I've submitted to the linux-efi folks will be accepted in its current form, and even if it is I'll have to get it and the other code I've written accepted into the various packages and then into Jessie! But for now this image should work just fine for Bay Trail folks I hope!

WARNING: this CD is provided for testing only. Use at your own risk! If you have appropriate (U)EFI hardware, please try this image and let me know how you get on, via the debian-cd and debian-boot mailing lists.

For now, I'm going to pause development here. The core code I'm using to make these images is all in the debian-cd and d-i repos, and I'll push the other patches once I know they'll work with the kernel. But I've got a slew of other things that I need to work on in the next few weeks, in no particular order:

  • RC bugs filed against abcde
  • Sorting out Mac-only 32-bit netinst images (only EFI boot? without EFI?)
  • Regular openstack image generation for Jessie
  • Regular debian-live image generation for Jessie
  • ...

I'm currently not planning to make all of Debian's amd64 images bootable using 32-bit UEFI like this image - I'm happy to leave this as just an option for our multi-arch i386/amd64 images (netinst or DVD only). I think that's a reasonable compromise here, and it's also the easiest thing for me to do with the current debian-cd build system.

Finally, apologies if you've asked me questions about the earlier images in this series and I've not responded yet. Fixing that ASAP!

Ben Hutchings: Linux suspend/resume regression in Debian 7.8

11 January, 2015 - 07:44

There was a regression in Linux 3.2.65, which unfortunately was included in this weekend's Debian stable point release (7.8) as I didn't point out the bug reports to the stable release team. At least some systems are now failing to resume after suspending to RAM; instead they reboot.

I have tracked down the change that caused this, and it should be fixed as part of a security update soon. The change is in code specific to 64-bit x86 (i.e. the Debian amd64 architecture). If you need suspend/resume to work, you might wish to avoid upgrading the linux-image-3.2.0-4-amd64 package until that future update.

Dirk Eddelbuettel: RcppClassic 0.9.6

11 January, 2015 - 02:32

A maintenance release of RcppClassic, now at version 0.9.6, went out to CRAN today. This package provides a maintained version of the otherwise deprecated first Rcpp API; no new projects should use it.

No changes were in user-facing code. The Makevars file was change to accomodate a request by the CRAN Maintainer to keep it free of GNU Make extensions. At the same time, we overhauled the look and feel of the (very short) vignette. Build instructions were updated both in the vignette and in the included example package. Other accumulated changes since the last release were updates to the DESCRIPTION and NAMESPACE file as well two namespace-related R code updates.

Courtesy of CRANberries, there is the set of changes relative to the previous release.

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.

Mike Gabriel: Shifting my Focus in X2Go

10 January, 2015 - 18:30

Dear X2Go Community, dear friends,

as many of you may know, I have been contributing a considerable amount
of time to upstream-maintaining X2Go over the past 4 years. I provided
new X2Go components (Python X2Go, PyHoca X2Go Client, a publicly
available X2Go Session Broker, X2Go MATE Bindings, etc.) and focused on
making X2Go a wide-spread community project. For the last 2-3 years I
have been in the role of the X2Go project coordinator and various other
roles.

With the beginning of 2015, I will pass on several of those roles to
other people in the project, see the below list for already assigned and
unassigned roles:

  • project/community coordinator (continued by Stefan Baur)
  • development coordination (continued by Heinz-Markus Graesing,
    very probably introducing some sort of agile development)
  • release management (n.n.)
  • i18n team leader (n.n.)
  • package maintenance (continued by Oleksandr Shneyder)
  • Git administrator (continued by Mihai Moldovan)
  • bug tracker administrator (continued by Michael DePaulo)

The reasons for tremendously reducing my workload on X2Go are these:

  • more time for development, less involvement in organizational tasks
  • more time for paid/contracted work (also in the X2Go context)
  • spend some of my time on doing Remote Desktop Computing research
  • be more available to Debian and Ubuntu as a package maintainer
  • be more available to my family

In several internal exchanges we (Heinz, Stefan, Mihai, Mike#2,

read more

Keith Packard: Back to HP

10 January, 2015 - 09:17
Re-joining HP

Thursday was my first day back with HP. I've joined Steve Geary's group to work on Linux support for “the machine”

I had a great time at Intel and wish my old team all the best.

Diego Escalante Urrelo: Link Pack #02

10 January, 2015 - 02:59

First sequel to my Link Pack “series” (I’ll remove the quotes when it’s LP#05): Link Pack #01.

This time I’m going for fewer articles, to try to keep things less overwhelming. There’s no special theme, and I’m actually leaving out some nice things I read recently. On the plus side, that means I have good material for a Link Pack #03.

Also, I’m gonna stick with Link Pack as a name, because it’s good enough :-).

A Teenager’s View on Social Media: Written by an actual teen
A well thought and realistic take on how social media is being used nowadays by teenagers. I have seen the patterns the author describes, and actually follow many of them. Does that mean I’m still a teenager?

It’s interesting that the messaging and group-messaging part of the article is very US centric, or at least very US centric from my point of view. WhatsApp is the default messenger application south of the states, and fills the role of “somewhere you can chat with people without having to give them your full personal information”, that is, a place where you can chat with someone without running out of SMS and without adding them on Facebook (which would open them to stalk your whole profile and other friends). Some carriers in South América offer unlimited plans for specific applications like WhatsApp.

What Would Jesus Buy? (2007) — Full movie
“Reverend” Billy Talen from the Church of Stop Shopping Gospel is trying to prevent the Shopocalypse from happening. It’s an entertaining story of a group of funny guys and girls trying to share a message with comedy (that means A+ on my list). Simple and independent, a nice film.

13 Nutrition Lies That Made The World Sick And Fat
A pet peeve of mine. Nutrition is not really that complicated, but unfortunately there are a lot of myths that make people take really bad decisions. If you only read one thing in 2014 2015, read this.

Bottom Line: The low-fat, high-carb diet recommended by the mainstream nutrition organizations is a miserable failure and has been repeatedly proven to be ineffective.

(…)

Bottom Line: Low-carb diets are the easiest, healthiest and most effective way to lose weight and reverse metabolic disease. It is pretty much a scientific fact at this point.

GM’s hit and run: How a lawyer, mechanic, and engineer blew open the worst auto scandal in history
Cars are so complex nowadays, and dependent on electronics, that I’m honestly afraid of them. I have made software for many years and I know how hard, impossible, it is to get things “perfect”. I can’t imagine how hard it is for something so critical as brakes, steering wheels, etc. Even cameras can’t get focus right some times, and it’s been many many years.

Countless articles have been written about General Motors and its massive recalls earlier this year. What hasn’t been fully told is how GM might have gotten away with multiple counts of consumercide were it not for the efforts of three men: a Georgia lawyer, a Mississippi mechanic, and a Florida engineer.

(…)

Brooke Melton needn’t have died that night. She was killed by a corporation’s callous disregard for the safety of its customers, made worse by a regulatory agency reluctant to regulate.

The Long Game: Part 1 and The Long Game: Part 2
Two very short (less than 5 minutes) video essays about how notable people in the story of creativity are always celebrated without mentioning the boring years when they were nothing but losers. It’s a fun little video, worth a watch for the idea and the interesting editing. It feels like someone really wanted to create these.

Richard Hartmann: Release Critical Bug report for Week 02

10 January, 2015 - 00:09

The UDD bugs interface currently knows about the following release critical bugs:

  • In Total: 1090 (Including 177 bugs affecting key packages)
    • Affecting Jessie: 157 (key packages: 92) 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: 124 (key packages: 74) Those need someone to find a fix, or to finish the work to upload a fix to unstable:
        • 19 bugs are tagged 'patch'. (key packages: 12) Please help by reviewing the patches, and (if you are a DD) by uploading them.
        • 4 bugs are marked as done, but still affect unstable. (key packages: 0) This can happen due to missing builds on some architectures, for example. Help investigate!
        • 101 bugs are neither tagged patch, nor marked done. (key packages: 62) Help make a first step towards resolution!
      • Affecting Jessie only: 33 (key packages: 18) 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.
        • 16 bugs are in packages that are unblocked by the release team. (key packages: 7)
        • 17 bugs are in packages that are not unblocked. (key packages: 11)

How do we compare to the Squeeze and Wheezy release cycles?

Week Squeeze Wheezy Jessie 43 284 (213+71) 468 (332+136) 319 (240+79) 44 261 (201+60) 408 (265+143) 274 (224+50) 45 261 (205+56) 425 (291+134) 295 (229+66) 46 271 (200+71) 401 (258+143) 427 (313+114) 47 283 (209+74) 366 (221+145) 342 (260+82) 48 256 (177+79) 378 (230+148) 274 (189+85) 49 256 (180+76) 360 (216+155) 226 (147+79) 50 204 (148+56) 339 (195+144) ??? 51 178 (124+54) 323 (190+133) 189 (134+55) 52 115 (78+37) 289 (190+99) 147 (112+35) 1 93 (60+33) 287 (171+116) 140 (104+36) 2 82 (46+36) 271 (162+109) 157 (124+33) 3 25 (15+10) 249 (165+84) 4 14 (8+6) 244 (176+68) 5 2 (0+2) 224 (132+92) 6 release! 212 (129+83) 7 release+1 194 (128+66) 8 release+2 206 (144+62) 9 release+3 174 (105+69) 10 release+4 120 (72+48) 11 release+5 115 (74+41) 12 release+6 93 (47+46) 13 release+7 50 (24+26) 14 release+8 51 (32+19) 15 release+9 39 (32+7) 16 release+10 20 (12+8) 17 release+11 24 (19+5) 18 release+12 2 (2+0)

Graphical overview of bug stats thanks to azhag:

Pages

Creative Commons License ลิขสิทธิ์ของบทความเป็นของเจ้าของบทความแต่ละชิ้น
ผลงานนี้ ใช้สัญญาอนุญาตของครีเอทีฟคอมมอนส์แบบ แสดงที่มา-อนุญาตแบบเดียวกัน 3.0 ที่ยังไม่ได้ปรับแก้