Search Results: "ed"

My terminal emulator of choice is xterm: it's fast, light, and (since it's pretty much the reference implementation) it has excellent support for everything a console user could desire... except for one thing that would be very, very convenient: making URLs clickable. Other terminal emulators have this feature, but they also have problems that make them inferior to xterm in different ways. Over the years people have come up with various workarounds for this situation, like screen scraping utilities (urlview, urlscan) that can be hooked up to other console programs to extract and browse URLs, but they're still not as convenient as just using the mouse, and often require the program to run on the same machine as the browser. Fortunately, xterm #277 (released in January 2012) added a new feature that provides almost exactly what I had been looking for: it can now spawn programs using the exec-formatted action and give them as argument the contents of the current selection or clipboard. So you can add the following to your ~/.Xresources: *VT100*translations: #override Meta <Btn1Up>: exec-formatted("x-www-browser '%t'", PRIMARY) which makes xterm run x-www-browser on the selection when it receives Alt + left click. (Adjust for whatever your Meta key is.) This is advantageously combined with a charClass setting to make xterm treat URLs as a single word, so that you can just double-click on them to select them: XTerm*charClass: 33:48,36-47:48,58-59:48,61:48,63-64:48,95:48,126:48 With both of these enabled, opening URLs is now just a matter of:

Double-clicking the URL to select it
Doing Alt + click anywhere on the xterm window to run the browser

which, while more involved than a single click, it still much faster than having to copy the URL manually to the browser.

Not few times I ve come upon the situation where I m working over a Subversion working copy locally and I wanted to commit bits of what I ve already baked and ready to go. Odds are that there s only one file not belonging to such changeset but mostly there are many files scattered around. This situation, I learned, can be managed with a lot more flexibility and fun.
svn changelist is a nice tool for such situation. svn changelist allows you to create a list of files I want to do something with meaning that you can use the changelist on your usual svn operations, read commit, remove, etc. Let s suppose you start with a project myapp, then you start creating three files A, B and C.



dragon% touch A B C

dragon% ls -lh

total 0

-rw-r--r-- 1 rudy rudy 0 Jul 13 20:16 A

-rw-r--r-- 1 rudy rudy 0 Jul 13 20:16 B

-rw-r--r-- 1 rudy rudy 0 Jul 13 20:16 C

dragon% svn add A B C

A         A

A         B

A         C

dragon% svn ci "first commit of A, B and C" .

Adding         A

Adding         B

Adding         C

Transmitting file data ...

Committed revision 1.

Now we want to edit A and add few pieces of text. Then edit B also.



dragon% echo "This file looks empty, so let's put some text inside it" > A

dragon%

dragon% echo "I'm afraid this one also is empty. Just in case" >> B

Now, I need to work on this C file and that implies touching B also. I don t want to commit the changes I ve already made since I haven t made up my mind about them.



dragon% echo "C is a nice name for a source file, but this one doesn't look like one does it?" > C

dragon% echo "I'm going to add few lines to B too" >> B



dragon% svn st

M       A

M       B

M       C

So, let s suppose I m ready to hit the key and commit the 2nd revision. But I m not done on A, so I want to commit just B and C the way they are now. Here svn changelist enters the arena. I can create a changelist for the two files and do several tasks related to them. Let s see.



dragon% svn changelist mylist B C

Path 'B' is now a member of changelist 'mylist'.

Path 'C' is now a member of changelist 'mylist'.

Now I have a changelist named mylist that I can do operations with. For instance,



dragon% svn st

M       A

--- Changelist 'mylist':

M       B

M       C



dragon% svn diff --changelist mylist

Index: B

===================================================================

--- B   (revision 1)

+++ B   (working copy)

@@ -0,0 +1,2 @@

+I'm afraid this one also is empty. Just in case

+I'm going to add few lines to B too

Index: C

===================================================================

--- C   (revision 1)

+++ C   (working copy)

@@ -0,0 +1 @@

+C is a nice name for a source file, but this one doesn't look like one does it?

Now let s commit the list.



dragon% svn ci -m "Comitting files from the mylist changelist" --changelist mylist

Sending        B

Sending        C

Transmitting file data ..

Committed revision 2.



dragon% svn st

M       A

Now that I ve committed the files, the changelist mylist vanishes from our working copy. I cannot do any new operations with it. Few things you have to consider when using svn changelist.
changelist s are created in a one-time list, that means you cannot add another file to an existing list. If I type svn changelist mylist A it will define the changelist mylist to have just one member, A. It will not add A to the existing member files, B and C. Now, you are free to remove any file from an existing changelist using svn changelist mylist --remove B, for our previous example. That will make the changelist shrink to just have one element, C. You can also have as many changelists as you want, and member files can be associated to each one of them. Use case for that could be a diff over specific files. For this test project it almost makes no difference using this feature, but when you have lots of file sitting modified on your working copy, this feature will keep your hair on it s place, and maybe save the day. svn changelist is available since Subversion 1.5.

I should also sketch out the physical and virtual circuits at and between each PoP as well as the vast array of Virtual Machines provisioned on the hypervisors.

Paolo Bonzini noticed something a little awkward in the Linux kernel support code for Microsoft's HyperV virtualisation environment - specifically, that the magic constant passed through to the hypervisor was "0xB16B00B5", or, in English, "BIG BOOBS". It turns out that this isn't an exception - when the code was originally submitted it also contained "0x0B00B135". That one got removed when the Xen support code was ripped out.

At the most basic level it's just straightforward childish humour, and the use of vaguely-English strings in magic hex constants is hardly uncommon. But it's also specifically male childish humour. Puerile sniggering at breasts contributes to the continuing impression that software development is a boys club where girls aren't welcome. It's especially irritating in this case because Azure may depend on this constant, so changing it will break things.

So, full marks, Microsoft. You've managed to make the kernel more offensive to half the population and you've made it awkward for us to rectify it.

comments

drive #1 To add to the fun of being in Nicaragua, my laptop's solid state drive died the second day here. Seems this is the failure mode for a SSD, get a little slow, and then a switch flips and it stops accepting any writes, at all, becoming a read-only media. Never was there an indication of a problem in SMART etc. Did you know that Nicaragua has neither names for most roads, nor addresses? Rather than trying to shoehorn the directions to my hotel into the address fields of Amazon.com, I shipped the replacement SSD to home, and thought I'd limp along. drive #2 I destroyed my second drive one hour after getting it working. A borrowed USB flash drive, which seems to have melted under the unusual load while I was away at lunch. Perhaps putting an ext3 filesystem on it was a very bad idea, although I have successfully run other USB flash drives that way for years. Perhaps it was a cheap drive that only pretended to hold 32 gb. drive #3 For several days I happily used the third drive, a USB hard drive, as my temporary root filesystem. Until I destroyed it by knocking it off my bed. drive #4, #5 Now my netbook is running from a Debian Live USB key, with a second USB key for my customisations. So far I have not managed to destroy these, but there's still a day left in my trip..

A new neighbourhood to explore today: the South-West/West area. Indeed, my original plan was going towards Lagunas de Nejapa and Asososca. However, I now understood that such non urban areas in Managua are almost inaccessible. It sound like walking and hiking in the nature is not something that urban inhabitants of Managua do often. So, in short, these places are....just impossible to go to. Anyway, I wanted to see this, just in case. As a consequence, I ended heading westward from Hotel Seminole through Avenida Miguel Obando Y Bravo (the busy highway close to the hotel, where we boarded the Day Trip buses). Running along this one is not a bad thing as it is not that busy, particularly at 05:45..:-) After crossinb Pista de la Unan that goes north towards the lake, I went 200m east then headed north up to reach the very busy Pista Juan Pablo II (or Pista de la Resistencia). For those who went to the day trip, this is the highway we went through at the beginning of the journey to Leon. It sounds crazy to run along a busy highway but:

it was not that busy at that time
this is the only way to not get lost in the barrios as we'll see later on..:-)

I followed that one during about 4km until it ends facing a cone-style mountain, about 150m high (former volcano crater?) After that long run straight, I ended at a big crossing, where the highways go either north or south....but a small street continues westward and is apparently going around the Laguna de Nejapa, at least according to Google Maps. However, there is indeed, as too often here, a barrier (which OSM would have told me, indeed). Hence, disappointed, I only could go back to the busy streets. I however decided that I would NOT come through the same way but rather try to run in smaller streets. This is where the problem lies. Indeed, Managua "barrios" are not always connected by streets to the large and busy streets that surround them. This is mostly because several rivers run south to north, towards the lake. And these are canalyzed to avoid floodings, which means there are not that many bridges to cross them. So, it often ends that a barrio is only connected on one or two of its sides, which makes travelling through them particularly difficult and puzzling (especially going in the east-west directions). So, I happened to search my way many times in these places, particularly in Barrio Pablo Sexto where the rivers directions are really confusing..:-) I finally had no other choice than going down to the big Pista Juan Pablo II and come back the same way to the hotel. The final result is a 15km run in 1h20. Not that a bad pace in these weather conditions. GPS trace

Android vs iPad I m currently in discussions with a client about a potential future project which involves a tablet computer talking to some electronic equipment. The options are an Android tablet and an iPad. One advantage of Android is that it runs on devices of all shapes and sizes, so we can choose a device that fits the need rather than designing everything around the iPad. But the real problem with iPad is Apple. To run an app on an iPad you need to submit it to Apple, hopefully get it accepted into the App Market, then install it. This process causes some delay, a minor fee, and has the potential to derail the project if Apple doesn t accept the app on the first try. With Android there is no need to even deal with Google, the app can be installed directly without the Google Play store. I may end up working with an iPad (which admittedly is really nice hardware), but it seems most likely that the project in question will run on Android only. Windows vs Linux and Apple OS/X One of my clients recently paid a web development company to redevelop his web site. I turned out that the web developers in question only knew how to develop for Windows and my client didn t discover this until too late. Now a site that s currently using a small fraction of the resources on a $80 per month Linode instance will run on a Windows virtual server costing $300 per month (which includes SQL server license). The Windows virtual server will probably be managed (because my client uses only Apple and Linux systems and doesn t employ anyone with Windows skills) which adds an extra $100 per month. If the server isn t managed then they will have to hire someone to apply patches and that won t necessarily be cheaper. So using Windows is going to cost my client an extra $400 per month when compared to the possibility of running a Linux system on the existing virtual server. Even if my client had someone with Windows skills to run the server it would still be an extra $300 per month. If the NBN was available then my client could run a Windows server in their office, but it s not yet available in their area. Even for a company that employs people with more Windows skills than Linux skills there are still economic factors in favor of Linux due to smaller hardware requirements and the lack of license fees for all the core software (OS, database server, web server, etc). Summary These anecdotes aren t unusual, it s the sort of thing that happens all the time. Sometimes the result is good (EG avoiding the iPad), sometimes it isn t (being stuck with a proprietary web service). I think I ll have to suggest to my clients that every contract have a no proprietary software clause. Contracts can be amended if there is a reason, but it seems best to make a preemptive strike against companies that sneak proprietary software in and cause significant unexpected expense and difficulty. Related posts:

The Lenovo U1 Hybrid an example of how Proprietary OSs Suck Lenovo have announced their innovative new U1 Hybrid laptop [1]....
My Prediction for the iPhone I have previously written about how I refused an offer...
Liberty and Mobile Phones I own two mobile phones at the moment, I use...

For quite some time, I've suffered slow boot - it had useless 10 seconds delay while initializing SATA with SSD disk:

[    2.761669] ata1: SATA max UDMA/133 abar m2048@0xf2528000 port 0xf2528100 irq 44
[    8.118202] ata1: link is slow to respond, please be patient (ready=0)
[   12.764701] ata1: COMRESET failed (errno=-16)
[   13.084612] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)

After some googling, I came to conclusion it is bug in SSD firmware and looked for update. Release notes documented some fixes to slow boot, what seemed to be related. The only issue was that the firmware update is available only as ISO image. And guess what I have no CDROM (actually I have no clue for what I would have used it). Fortunately the update is doable with just grub and syslinux. First, download ISO provided by Intel and extract eltorito boot image from it using geteltorito script and copy it to /boot/. Then get yourself syslinux and copy memdisk to /boot/. Now you just need to edit grub configuration to include following lines (you might need to adjust it according to your partition setup):

menuentry "SSD Update"  
        insmod part_msdos
        insmod ext2
        set root='(hd0,msdos1)'
        linux16 /memdisk
        initrd16 /ssd-fw.img

Now you can reboot and choose SSD Update from the grub menu and perform update! After update the slowest part of boot process is me entering LUKS password, but I'm afraid this is not easily fixable :-). PS: The difference you can see after update:

[    2.797551] ata1: SATA max UDMA/133 abar m2048@0xf2528000 port 0xf2528100 irq 44
[    3.115694] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)

Filed under: English Linux 0 comments Flattr this!

In the past I used to argue that accurate desktop DPI was important, since after all otherwise you could print out a 12 point font and hold up the sheet of paper to your monitor and it would be different. I later gave up on the idea that accurate DPI measurement was generally useful to the desktop, but there's still something seductively attractive about the idea that a 12 point font should be the same everywhere, and someone recently wrote about that. Like many seductively attractive ideas it's actually just trying to drug you and steal your kidneys, so here's why it's a bad plan.

Solutions solve problems. Before we judge whether a solution is worthwhile or not, we need to examine the problem that it's solving. "My 12pt font looks different depending on the DPI of my display" isn't a statement of a problem, it's a statement of fact. How do we turn it into a problem? "My 12pt font looks different depending on which display I'm using and so it's hard to judge what it'll look like on paper" is a problem. Way back in prehistory when Apple launched the original Mac, they defined 72dpi as their desktop standard because the original screen was approximately 72dpi. Write something on a Mac, print it and hold the paper up to the monitor and the text would be the same size. This sounds great! Except that (1) this is informative only if your monitor is the same distance away as your reader will be from the paper, and (2) even in the classic Mac period of the late 80s and early 90s, Mac monitors varied between 66 and 80dpi and so this was already untrue. It turns out that this isn't a real problem. It's arguably useful for designers to be able to scale their screen contents to match a sheet of paper the same distance away, but that's still not how they'll do most of their work. And it's certainly not an argument for enforcing this on the rest of the UI.

So "It'll look different on the screen and paper" isn't really a problem, and so that's not what this is a solution for. Let's find a different problem. Here's one - "I designed a UI that works fine on 100DPI displays but is almost unusable on 200DPI displays". This problem is a much better one to solve, because it actually affects real people rather than the dying breed who have to care about what things look like when turned into ink pasted onto bits of dead tree. And it sounds kind of like designing UIs to be resolution independent would be a great solution to this. Instead of drawing a rectangle that's 100 pixels wide, let me draw one that's one inch wide. That way it'll look identical on 100dpi and 200dpi systems, and now I can celebrate with three lines of coke and wake up with $5,000 of coffee table made out of recycled cinema posters or whatever it is that designers do these days. A huge pile of money from Google will be turning up any day now.

Stop. Do not believe this.

Websites have been the new hotness for a while now, so let's apply this to them. Let's imagine a world in which the New York Times produced an electronic version in the form of a website, and let's imagine that people viewed this website on both desktops and phones. In this world the website indicates that content should be displayed in a 12pt font, and that both the desktop and phone software stacks render this to an identical size, and as such the site would look identical if the desktop's monitor and the phone were the same distance away from me.

The flaw in this should be obvious. If I'm reading something on my phone then the screen is a great deal closer to me than my desktop's monitor usually is. If the fonts are rendered identically on both then the text on my phone will seem unnecessarily large and I won't get to see as much content. I'll end up zooming out and now your UI is smaller than you expected it to be, and if your design philosophy was based on the assumption that the UI would be identical on all displays then there's probably now a bunch of interface that's too small for me to interact with. Congratulations. I hate you.

So "Let's make our fonts the same size everywhere" doesn't solve the problem, because you still need to be aware of how different devices types are used differently and ensure that your UI works on all of them. But hey, we could special case that - let's have different device classes and provide different default font sizes for each of them. We'll render in 12pt on desktops and 7pt on phones. Happy now?

Not really, because it still makes this basic assumption that people want their UI to look identical across different machines with different DPI. Some people do buy high-DPI devices because they want their fonts to look nicer, and the approach Apple have taken with the Retina Macbook Pro is clearly designed to cater to that group. But other people buy high-DPI devices because they want to be able to use smaller fonts and still have them be legible, and they'll get annoyed if all their applications just make the UI larger to compensate for their increased DPI. And let's not forget the problem of wildly differing displays on the same hardware. If I have a window displaying a 12pt font on my internal display and then drag that window to an attached projector, what size should that font be? If you say 12pt then I really hope that this is an accurate representation of your life, because I suspect most people have trouble reading a screen of 12pt text from the back of an auditorium.

That covers why I think this approach is wrong. But how about why it's dangerous? Once you start designing with the knowledge that your UI will look the same everywhere, you start enforcing that assumption in your design. 12pt text will look the same everywhere, so there's no need to support other font sizes. And just like that you've set us even further back in terms of accessibility support, because anyone who actually needs to make the text bigger only gets to do so if they also make all of your other UI elements bigger. Full marks. Dismissed.

The only problem "A 12pt font should be the same everywhere" solves is "A 12pt font isn't always the same size". The problem people assume it solves is "It's difficult to design a UI that is appropriate regardless of display DPI", and it really doesn't. Computers aren't sheets of paper, and a real solution to the DPI problem needs to be based on concepts more advanced than one dating back to the invention of the printing press. Address the problem, not your assumption of what the problem is.

comments

I generated 0x94FA372B2DA8B985 (my 4096R GPG key) back in 2008, and revoked my old 1024R v3 key around the same time. However I left my main 1024D key alone, figuring I'd get round to revoking it at some point once the new one was sufficiently trusted. This probably happened some time ago, so today I have finally revoked this key:

pub   1024D/0xF1BD4BE45B430367 1999-10-26 [revoked: 2012-07-13]
uid                            Jonathan McDowell <noodles@earth.li>

If you're not in the habit of refreshing your GPG keyring regularly now might be a good time to (gpg --refresh-keys) or at the very least pull my updated key (gpg --recv-key 0xF1BD4BE45B430367) to make sure you don't accidentally continue to use it. (If I haven't signed your key with my stronger one please do wave a fingerprint/ID at me next time we meet, and ask me for the same in return.)

Conrad released version 3.2.4 of Armadillo yesterday. It contains a workaround for g++ 4.7.0 and 4.7.1 which have a regression triggered by the Armadillo codebase for small fixed-sized matrices. The corresponding RcppArmadillo package 0.3.2.4 arrived on CRAN earlier today. The short NEWS entry follows below.

0.3.2.4  2012-07-11
    o   Upgraded to Armadillo release 3.2.4
          * workaround for a regression (bug) in GCC 4.7.0 and 4.7.1

Courtesy of CRANberries, there is also a diffstat report for 0.3.2.4 relative to 0.3.2.3 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.

I m leaving myself some room for bug fixes. It works for us in house. I would love to help others to give it a try. especially those who could benefit from making nearly immediately answered queries to the NIST s NVD database. The code in this release cannot by itself track the feed from the feds in real time. The nvd entry loader needs a little bit of love in the area of record merging before this starts working. It s on my TODO list. I m sorry for the outage of git.colliertech.org. I ll get that back up here shortly. In the meantime, feel free to grab it from this location while the CPAN indexes and processes my submission. http://www.colliertech.org/federal/NIST/NIST-NVD-1.00.00.tar.bz2 don t forget to check the cryptographic signature: http://www.colliertech.org/federal/NIST/NIST-NVD-1.00.00.tar.bz2.crc

I read an interesting question about mutt on IRC some days ago, which was: how do I find out which threads I have trolled^Wtaken part in. Obviously, there s ~P to filter the mails I have sent (which uses addresses declared through the alternates config directives to know who I am). But how do I find about the whole thread? Easily enough, one can wrap a given search through ~( ) so that the whole threads containing the matching mails are selected. In this case: ~(~P). Given the amount of outstanding requests on debian-release@, one can use the following to only see the threads with unread mails: ~(~N), which helps spotting the threads where attention is needed. Thinking of it, that probably should become the default when opening a given Maildir Gotta love people with interesting questions.

And I still get into arguments about why I prefer apt-get over aptitude... Sometimes, stupid is good.

# apt-get update
[...get Debian sid package list...]
# aptitude install libdbd-csv-perl
The following NEW packages will be installed:
  libdbd-csv-perl libparams-util-perl a  libsql-statement-perl a  libtext-csv-xs-perl a 
The following packages will be upgraded:
  libdbi-perl perl perl-base perl-modules
4 packages upgraded, 4 newly installed, 0 to remove and 1459 not upgraded.
Need to get 9,845 kB of archives. After unpacking 1,069 kB will be used.
The following packages have unmet dependencies:
  libperl5.14: Depends: perl-base (= 5.14.2-7) but 5.14.2-12 is to be installed.
The following actions will resolve these dependencies:
      Remove the following packages:
1)      elinks
2)      irssi
3)      irssi-scripts
4)      libperl5.14
5)      perlmagick
6)      vim-gtk
7)      xchat
      Leave the following dependencies unresolved:
8)      elinks-data recommends elinks (= 0.12~pre5-7)
9)      vim-gui-common recommends vim-gnome   vim-gtk   vim-athena
10)     xchat-common recommends xchat
11)     inkscape recommends perlmagick
Accept this solution? [Y/n/q/?] ^C
# apt-get install libdbd-csv-perl
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
  libdbi-perl libparams-util-perl libperl5.14 libsql-statement-perl libtext-csv-xs-perl perl perl-base perl-modules
The following NEW packages will be installed:
  libdbd-csv-perl libparams-util-perl libsql-statement-perl libtext-csv-xs-perl
The following packages will be upgraded:
  libdbi-perl libperl5.14 perl perl-base perl-modules
5 upgraded, 4 newly installed, 0 to remove and 1458 not upgraded.
Need to get 10.6 MB of archives.
After this operation, 1,081 kB of additional disk space will be used.
Do you want to continue [Y/n]?
Get:1 http://ftp5.gwdg.de/pub/linux/debian/debian/ unstable/main perl i386 5.14.2-12 [3,701 kB]
Get:2 http://ftp5.gwdg.de/pub/linux/debian/debian/ unstable/main libperl5.14 i386 5.14.2-12 [731 kB]
Get:3 http://ftp5.gwdg.de/pub/linux/debian/debian/ unstable/main perl-base i386 5.14.2-12 [1,494 kB]
Get:4 http://ftp5.gwdg.de/pub/linux/debian/debian/ unstable/main perl-modules all 5.14.2-12 [3,438 kB]
Get:5 http://ftp5.gwdg.de/pub/linux/debian/debian/ unstable/main libtext-csv-xs-perl i386 0.90-1 [73.1 kB]
Get:6 http://ftp5.gwdg.de/pub/linux/debian/debian/ unstable/main libdbi-perl i386 1.622-1 [897 kB]
Get:7 http://ftp5.gwdg.de/pub/linux/debian/debian/ unstable/main libparams-util-perl i386 1.07-1 [25.4 kB]
Get:8 http://ftp5.gwdg.de/pub/linux/debian/debian/ unstable/main libsql-statement-perl all 1.33-1 [179 kB]
Get:9 http://ftp5.gwdg.de/pub/linux/debian/debian/ unstable/main libdbd-csv-perl all 0.3500-1 [36.4 kB]
Fetched 10.6 MB in 10s (980 kB/s)
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
Reading changelogs... Done
(Reading database ... 278465 files and directories currently installed.)
Preparing to replace perl 5.14.2-7 (using .../perl_5.14.2-12_i386.deb) ...
Unpacking replacement perl ...
Preparing to replace libperl5.14 5.14.2-7 (using .../libperl5.14_5.14.2-12_i386.deb) ...
Unpacking replacement libperl5.14 ...
Preparing to replace perl-base 5.14.2-7 (using .../perl-base_5.14.2-12_i386.deb) ...
Unpacking replacement perl-base ...
Processing triggers for man-db ...
Setting up perl-base (5.14.2-12) ...
(Reading database ... 278465 files and directories currently installed.)
Preparing to replace perl-modules 5.14.2-7 (using .../perl-modules_5.14.2-12_all.deb) ...
Unpacking replacement perl-modules ...
Selecting previously unselected package libtext-csv-xs-perl.
Unpacking libtext-csv-xs-perl (from .../libtext-csv-xs-perl_0.90-1_i386.deb) ...
Preparing to replace libdbi-perl 1.617-1 (using .../libdbi-perl_1.622-1_i386.deb) ...
Unpacking replacement libdbi-perl ...
Selecting previously unselected package libparams-util-perl.
Unpacking libparams-util-perl (from .../libparams-util-perl_1.07-1_i386.deb) ...
Selecting previously unselected package libsql-statement-perl.
Unpacking libsql-statement-perl (from .../libsql-statement-perl_1.33-1_all.deb) ...
Selecting previously unselected package libdbd-csv-perl.
Unpacking libdbd-csv-perl (from .../libdbd-csv-perl_0.3500-1_all.deb) ...
Processing triggers for man-db ...
Setting up libperl5.14 (5.14.2-12) ...
Setting up perl-modules (5.14.2-12) ...
Setting up perl (5.14.2-12) ...
Setting up libtext-csv-xs-perl (0.90-1) ...
Setting up libdbi-perl (1.622-1) ...
Setting up libparams-util-perl (1.07-1) ...
Setting up libsql-statement-perl (1.33-1) ...
Setting up libdbd-csv-perl (0.3500-1) ...
#

And don't get me started about waiting for

aptitude
*upgrade

to resolve its dependency graph...

I failed. I didn't go running the day after the Cheese and Wine party (tuesday). I wonder why...:-) Indeed, I was feeling well, but slightly tired and I woke up at 8am, which means that I would have to go out quite late, in the heat...and run while feeling tired. And something I have learnt in all my running activities is that when one feels not in shape, better not insist. This is where injuries can come. Moreover, the next day was meant to be the Day Trip, with a goal for me: climb the Cerro negro volcano as fast as I can, training with my sticks for difficult climbs, in the heat...in the perspective of future races I would like to do in French Alps, in the upcoming years (such as La Montagn'hard : I recommend watching the video). Sadly, a landslide has cut the road 2km away from the starting point and, despite my desperate attempts to still form a group of "strong people" to go there and do the extra 4km walk anyway....we later learned that the entire road to Cerro Negro is closed and we'd have no chance to go on it. That infortunate, though I hopefully have another chance in the upcoming two weeks, where I'm supposed to come back and climb the volcano with Elizabeth (but, I of course will not leave my beloved one alone on a volcano!). So, I ended up staying on the beach at Las Pe itas. And, as I explained to No l, on days where I *decided* to run, I *need* to run. It's like a drug as you'd guess. So, I went running on the beach..:-). In the early afternoon, during a very hot day (probably the best weather we ever had, which makes me even more regret "my" volcano), about 34 C, no shade...and some wind, and sand...:-) Running on the beach is not as hard as one would imagine as long as you stay at the limit of the water, where the sand is compact. Indeed, this is even good for articulations as the sand soil is of course soft and absorbs impacts. The only drawback is that this beach is quite not so flat and this is sometimes like running across a hill all time long. Anyway, I went north up to Poneloya, up to the point where a river blocks the path along the beach, then I headed back. I had originally the intent to continue south-east, past the place where we were, up to the start of Juan Venaco island. However, the face wind when comign back, as well as the very hot sun, really achieved me....and I decided it would be wiser to stop. I however couldn't resist running IN the waves, which means I now have very humid shoes (but I have two pairs of those...:-)) Today (Thursday), was a more standard run in Managua, with No l and Ralf. We once again went to the South suburbs hills. All three of us were suite tired as it seems, so we chose a quite slow pace and, still, the climb was not that easy. We went the same way I went with Ralf a few days ago, but we didn't enter the "dogs path" this time, but rather tried to continue the road south. After 4.5 km, we had however to stop because the path didn't go further and, anyway, I think it was enough for all of us..:-) The way back, we tried another way, which was not particularly touristic (close to the National Soccer Stadium....a not so impressive stadium, but soccer is not the national sport here in Nicaragua, where people are more in base-ball or boxing). Both GPS traces:

See you tomorrow for yet another GPS trace..:-)

More diversity in Debian skills This blog post has been co-authored with Francesca Ciceri. In his Debconf talk, zack said:

We need to understand how to invite people with different backgrounds than packaging to join the Debian project [...] I don't know what exactly, but we need to do more to attract those kinds of people.

Francesca and I know what we could do: make other kinds of contributions visible. Basically, we should track and acknowledge the contributions of webmasters, translators, programmers, sysadmins, event organisers, and so on, at the same level as what we do for packagers: DDPO, minechangelogs, Portfolio... For any non-packaging activity that we can make visible and credited, we get:

to acknowledge the people who do it, and show that they are active contributors in the project;
to acknowledge the work that gets done, and show the actual amount of non-packaging work that gets done in Debian every day;
to allow non-packagers to have a reputation, too: first of all, they deserve it, and among other things, it would make nm processing trivial.

Here's an example: who's the lead translator for German? And if you are German, who's the lead translator for Spanish? Czech? Thai? I (Enrico) don't know the answers, not even for Italian, but we all should! Or at least it should be trivial to find out. To start to change this, is just a matter of programming. Francesca already worked on a list of trackable data sources, at least for translators. Here are some more details, related to translation:

Translations can be tracked via the i18n robot (and relative statistics). This works only with teams who activated the robot and actively use the pseudo-urls in their messages on localisation mailing lists. Some translators don't bother to do it but it's ok to only support the main workflow. It beats extracting .po files from l10n-tagged BTS bugs at any rate.
DPN and website translations: for wml pages there's a specific field to be extracted for each translated page: grep for maintainer="name" on normal wml pages, while for DPN translations we have a specific translator="name" field. The problem is that this field is not mandatory, so sometimes there's no indication of the maintainer. Again, it's ok to only support the main workflow. Anyway, this is preferable to the cvs log: often the commit is done by the coordinator of the team and not by the actual translator. See above for the alternative solution of using the statistics provided by the i18n bot.
DDTSS: since the new release of DDTSS-Django, done by Martijn van Oosterhout about a year ago, the contributions are by default non-anonymous. This should be easy to track.
: it is more complicated because in the wiki we do not have a proper l10n translation workflow, so the only thing that can be tracked are changelogs $LANG/* pages. A nice idea would be to have translated pages list the version of the page that was translated and who did the translation.
translation of debian manuals and release notes: usually in the translation of manuals and long documentation there is a specific translator field.

And here are some notes about other fields:

DPN editors: for each issue there's a list of editors at the bottom of the page. In the wml: grep for editor=.
Artwork: artwork submitted via debianart are easy to track on the portal. Anyway usually you can find the author in the license and copyright file.
Programming: the only thing we have is the list of services which can be expanded if needed.
Press and publicity: there seems to be not much besides svn logs.
l10n-english: The Smith Review Project page has some tracking links. Other activities can probably only be tracked, at the moment, via mailing list activity.
Events: we can use the "main coordinator" field on www.debian.org/events/$year/$date-$eventname.wml: grep for <define-tag coord>; for events not published on the http://www.debian.org, but only on http://wiki.debian.org, the coordinator or the contact for the event is usually present on the page itself.
Sysadmins: we haven't asked DSA.

And finally, if you are still wondering who those translation coordinators are, they are listed here, although not all teams keep that page up to date. Of course, when a data source is too hard to mine, it can make sense to see if the workflow could be improved, rather than spending months writing compicated mining code. This is a fun project for people at Debconf to get together and try. If by the end of the conference we had a way to credit some group of non-packaging contributors, even if just one like translators or website contributors, at least we would finally have started having official trackers for the activities of non-packagers.

So yet another bug reporting tool. :-)When I prepared Apport for Debian, I wasn't sure how it will look going forward. If you look at the current one lying in experimental, it just detects your crashes and pops up in your systray. It doesn't have the mechanism to interact with BTS.So, like the title of this post says, this is the first worthy feature for Apport in the context of Debian. Apport Detail Report

Nothing special here. You would have seen a similar window before if you have installed apport. What changes with this release is, that now, when you check the Send an error report to help fix this problem, it will really file a bug report on the BTS.Here's what the emailed bug report will look like:

Package: leafnode
Version: 2.0.0.alpha20090406a-1
=============================
ProblemType: Crash
Architecture: amd64
Date: Tue Jul  3 00:08:02 2012
Dependencies:
 adduser 3.113+nmu3
 base-passwd 3.5.24
 cron 3.0pl1-123
 debconf 1.5.44
 debianutils 4.3.1
 dpkg 1.16.4.3
 gcc-4.7-base 4.7.1-2
 libbz2-1.0 1.0.6-3
 libc-bin 2.13-33
 libc6 2.13-33
 libclass-isa-perl 0.36-3
 libdb5.1 5.1.29-4
 libfile-copy-recursive-perl 0.38-1
 libgcc1 1:4.7.1-2
 libgdbm3 1.8.3-11
 liblzma5 5.1.1alpha+20120614-1
 libpam-modules 1.1.3-7.1
 libpam-modules-bin 1.1.3-7.1
 libpam-runtime 1.1.3-7.1
 libpam0g 1.1.3-7.1
 libpcre3 1:8.30-5
 libpopt0 1.16-7
 libselinux1 2.1.9-5
 libsemanage-common 2.1.6-6
 libsemanage1 2.1.6-6
 libsepol1 2.1.4-3
 libswitch-perl 2.16-2
 libustr-1.0-1 1.0.4-3
 libwrap0 7.6.q-23
 logrotate 3.8.1-4
 lsb-base 4.1+Debian7 [modified: lib/lsb/init-functions]
 multiarch-support 2.13-33
 netbase 5.0
 openbsd-inetd 0.20091229-2
 passwd 1:4.1.5.1-1
 perl 5.14.2-12
 perl-base 5.14.2-12
 perl-modules 5.14.2-12
 sensible-utils 0.0.7
 tar 1.26-4
 tcpd 7.6.q-23
 update-inetd 4.43
 zlib1g 1:1.2.7.dfsg-13
Disassembly:
 => 0x7f8e69738475 <*__GI_raise+53>:	cmp    $0xfffffffffffff000,%rax
    0x7f8e6973847b <*__GI_raise+59>:	ja     0x7f8e69738492 <*__GI_raise+82>
    0x7f8e6973847d <*__GI_raise+61>:	repz retq 
    0x7f8e6973847f <*__GI_raise+63>:	nop
    0x7f8e69738480 <*__GI_raise+64>:	test   %eax,%eax
    0x7f8e69738482 <*__GI_raise+66>:	jg     0x7f8e69738465 <*__GI_raise+37>
    0x7f8e69738484 <*__GI_raise+68>:	test   $0x7fffffff,%eax
    0x7f8e69738489 <*__GI_raise+73>:	jne    0x7f8e697384a2 <*__GI_raise+98>
    0x7f8e6973848b <*__GI_raise+75>:	mov    %esi,%eax
    0x7f8e6973848d <*__GI_raise+77>:	nopl   (%rax)
    0x7f8e69738490 <*__GI_raise+80>:	jmp    0x7f8e69738465 <*__GI_raise+37>
    0x7f8e69738492 <*__GI_raise+82>:	mov    0x34e97f(%rip),%rdx        # 0x7f8e69a86e18
    0x7f8e69738499 <*__GI_raise+89>:	neg    %eax
    0x7f8e6973849b <*__GI_raise+91>:	mov    %eax,%fs:(%rdx)
    0x7f8e6973849e <*__GI_raise+94>:	or     $0xffffffff,%eax
    0x7f8e697384a1 <*__GI_raise+97>:	retq
DistroRelease: Debian 7.0
ExecutablePath: /usr/sbin/fetchnews
ExecutableTimestamp: 1265584779
Package: leafnode 2.0.0.alpha20090406a-1
PackageArchitecture: amd64
ProcCmdline: /usr/sbin/fetchnews
ProcCwd: /
ProcEnviron:
 LANGUAGE=en_US:en
 LC_TIME=en_IN.UTF-8
 LC_MONETARY=en_IN.UTF-8
 PATH=(custom, no user)
 LC_ADDRESS=en_IN.UTF-8
 LANG=en_US.UTF-8
 LC_TELEPHONE=en_IN.UTF-8
 LC_NAME=en_IN.UTF-8
 SHELL=/bin/sh
 LC_MEASUREMENT=en_IN.UTF-8
 LC_NUMERIC=en_IN.UTF-8
 LC_PAPER=en_IN.UTF-8
ProcMaps:
 00400000-00421000 r-xp 00000000 08:06 4464934                            /usr/sbin/fetchnews
 00621000-00622000 rw-p 00021000 08:06 4464934                            /usr/sbin/fetchnews
 00622000-00623000 rw-p 00000000 00:00 0 
 00be4000-00c05000 rw-p 00000000 00:00 0                                  [heap]
 7f8e68edc000-7f8e68eef000 r-xp 00000000 08:06 1179776                    /lib/x86_64-linux-gnu/libresolv-2.13.so
 7f8e68eef000-7f8e690ee000 ---p 00013000 08:06 1179776                    /lib/x86_64-linux-gnu/libresolv-2.13.so
 7f8e690ee000-7f8e690ef000 r--p 00012000 08:06 1179776                    /lib/x86_64-linux-gnu/libresolv-2.13.so
 7f8e690ef000-7f8e690f0000 rw-p 00013000 08:06 1179776                    /lib/x86_64-linux-gnu/libresolv-2.13.so
 7f8e690f0000-7f8e690f2000 rw-p 00000000 00:00 0 
 7f8e690f2000-7f8e690f7000 r-xp 00000000 08:06 1180036                    /lib/x86_64-linux-gnu/libnss_dns-2.13.so
 7f8e690f7000-7f8e692f6000 ---p 00005000 08:06 1180036                    /lib/x86_64-linux-gnu/libnss_dns-2.13.so
 7f8e692f6000-7f8e692f7000 r--p 00004000 08:06 1180036                    /lib/x86_64-linux-gnu/libnss_dns-2.13.so
 7f8e692f7000-7f8e692f8000 rw-p 00005000 08:06 1180036                    /lib/x86_64-linux-gnu/libnss_dns-2.13.so
 7f8e692f8000-7f8e692fa000 r-xp 00000000 08:06 1183392                    /lib/libnss_mdns4_minimal.so.2
 7f8e692fa000-7f8e694f9000 ---p 00002000 08:06 1183392                    /lib/libnss_mdns4_minimal.so.2
 7f8e694f9000-7f8e694fa000 rw-p 00001000 08:06 1183392                    /lib/libnss_mdns4_minimal.so.2
 7f8e694fa000-7f8e69505000 r-xp 00000000 08:06 1180055                    /lib/x86_64-linux-gnu/libnss_files-2.13.so
 7f8e69505000-7f8e69704000 ---p 0000b000 08:06 1180055                    /lib/x86_64-linux-gnu/libnss_files-2.13.so
 7f8e69704000-7f8e69705000 r--p 0000a000 08:06 1180055                    /lib/x86_64-linux-gnu/libnss_files-2.13.so
 7f8e69705000-7f8e69706000 rw-p 0000b000 08:06 1180055                    /lib/x86_64-linux-gnu/libnss_files-2.13.so
 7f8e69706000-7f8e69883000 r-xp 00000000 08:06 1179700                    /lib/x86_64-linux-gnu/libc-2.13.so
 7f8e69883000-7f8e69a83000 ---p 0017d000 08:06 1179700                    /lib/x86_64-linux-gnu/libc-2.13.so
 7f8e69a83000-7f8e69a87000 r--p 0017d000 08:06 1179700                    /lib/x86_64-linux-gnu/libc-2.13.so
 7f8e69a87000-7f8e69a88000 rw-p 00181000 08:06 1179700                    /lib/x86_64-linux-gnu/libc-2.13.so
 7f8e69a88000-7f8e69a8d000 rw-p 00000000 00:00 0 
 7f8e69a8d000-7f8e69a95000 r-xp 00000000 08:06 1180031                    /lib/x86_64-linux-gnu/libcrypt-2.13.so
 7f8e69a95000-7f8e69c94000 ---p 00008000 08:06 1180031                    /lib/x86_64-linux-gnu/libcrypt-2.13.so
 7f8e69c94000-7f8e69c95000 r--p 00007000 08:06 1180031                    /lib/x86_64-linux-gnu/libcrypt-2.13.so
 7f8e69c95000-7f8e69c96000 rw-p 00008000 08:06 1180031                    /lib/x86_64-linux-gnu/libcrypt-2.13.so
 7f8e69c96000-7f8e69cc4000 rw-p 00000000 00:00 0 
 7f8e69cc4000-7f8e69cc6000 r-xp 00000000 08:06 1180047                    /lib/x86_64-linux-gnu/libdl-2.13.so
 7f8e69cc6000-7f8e69ec6000 ---p 00002000 08:06 1180047                    /lib/x86_64-linux-gnu/libdl-2.13.so
 7f8e69ec6000-7f8e69ec7000 r--p 00002000 08:06 1180047                    /lib/x86_64-linux-gnu/libdl-2.13.so
 7f8e69ec7000-7f8e69ec8000 rw-p 00003000 08:06 1180047                    /lib/x86_64-linux-gnu/libdl-2.13.so
 7f8e69ec8000-7f8e69ed5000 r-xp 00000000 08:06 1179893                    /lib/x86_64-linux-gnu/libpam.so.0.83.0
 7f8e69ed5000-7f8e6a0d4000 ---p 0000d000 08:06 1179893                    /lib/x86_64-linux-gnu/libpam.so.0.83.0
 7f8e6a0d4000-7f8e6a0d5000 r--p 0000c000 08:06 1179893                    /lib/x86_64-linux-gnu/libpam.so.0.83.0
 7f8e6a0d5000-7f8e6a0d6000 rw-p 0000d000 08:06 1179893                    /lib/x86_64-linux-gnu/libpam.so.0.83.0
 7f8e6a0d6000-7f8e6a112000 r-xp 00000000 08:06 1182916                    /lib/x86_64-linux-gnu/libpcre.so.3.13.1
 7f8e6a112000-7f8e6a312000 ---p 0003c000 08:06 1182916                    /lib/x86_64-linux-gnu/libpcre.so.3.13.1
 7f8e6a312000-7f8e6a313000 rw-p 0003c000 08:06 1182916                    /lib/x86_64-linux-gnu/libpcre.so.3.13.1
 7f8e6a313000-7f8e6a333000 r-xp 00000000 08:06 1180134                    /lib/x86_64-linux-gnu/ld-2.13.so
 7f8e6a503000-7f8e6a507000 rw-p 00000000 00:00 0 
 7f8e6a530000-7f8e6a532000 rw-p 00000000 00:00 0 
 7f8e6a532000-7f8e6a533000 r--p 0001f000 08:06 1180134                    /lib/x86_64-linux-gnu/ld-2.13.so
 7f8e6a533000-7f8e6a534000 rw-p 00020000 08:06 1180134                    /lib/x86_64-linux-gnu/ld-2.13.so
 7f8e6a534000-7f8e6a535000 rw-p 00000000 00:00 0 
 7fffbc06e000-7fffbc08f000 rw-p 00000000 00:00 0                          [stack]
 7fffbc1ff000-7fffbc200000 r-xp 00000000 00:00 0                          [vdso]
 ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]
ProcStatus:
 Name:	fetchnews
 State:	S (sleeping)
 Tgid:	6872
 Pid:	6872
 PPid:	6871
 TracerPid:	0
 Uid:	9	9	9	9
 Gid:	9	9	9	9
 FDSize:	64
 Groups:	9 
 VmPeak:	   21440 kB
 VmSize:	   21276 kB
 VmLck:	       0 kB
 VmPin:	       0 kB
 VmHWM:	     984 kB
 VmRSS:	     984 kB
 VmData:	     380 kB
 VmStk:	     136 kB
 VmExe:	     132 kB
 VmLib:	    2132 kB
 VmPTE:	      64 kB
 VmSwap:	       0 kB
 Threads:	1
 SigQ:	0/23227
 SigPnd:	0000000000000000
 ShdPnd:	0000000000000000
 SigBlk:	0000000000000000
 SigIgn:	0000000000000000
 SigCgt:	0000000000000000
 CapInh:	0000000000000000
 CapPrm:	0000000000000000
 CapEff:	0000000000000000
 CapBnd:	ffffffffffffffff
 Cpus_allowed:	f
 Cpus_allowed_list:	0-3
 Mems_allowed:	00000000,00000001
 Mems_allowed_list:	0
 voluntary_ctxt_switches:	6
 nonvoluntary_ctxt_switches:	1
Registers:
 rax            0x0	0
 rbx            0x0	0
 rcx            0xffffffffffffffff	-1
 rdx            0x6	6
 rsi            0x1ad8	6872
 rdi            0x1ad8	6872
 rbp            0x0	0x0
 rsp            0x7fffbc08d4f8	0x7fffbc08d4f8
 r8             0x7f8e6a504700	140249645729536
 r9             0x6d6f642064656966	7885631562835126630
 r10            0x8	8
 r11            0x246	582
 r12            0x0	0
 r13            0x7fffbc08d920	140736348084512
 r14            0x0	0
 r15            0x0	0
 rip            0x7f8e69738475	0x7f8e69738475 <*__GI_raise+53>
 eflags         0x246	[ PF ZF IF ]
 cs             0x33	51
 ss             0x2b	43
 ds             0x0	0
 es             0x0	0
 fs             0x0	0
 gs             0x0	0
Signal: 6
SourcePackage: leafnode
Stacktrace:
 #0  0x00007f8e69738475 in *__GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
         pid = <optimized out>
         selftid = <optimized out>
 #1  0x00007f8e6973b6f0 in *__GI_abort () at abort.c:92
         act =  __sigaction_handler =  sa_handler = 0x7f8e69850d3d, sa_sigaction = 0x7f8e69850d3d , sa_mask =  __val =  140736348083740, 140249634747968, 0, 0, 140736348084512, 140249631083424, 140249645738440, 0, 4294967295, 206158430232, 1, 6427272, 0, 0, 0, 0 , sa_flags = 1781664242, sa_restorer = 0x1 
         sigs =  __val =  32, 0 <repeats 15 times> 
 #2  0x0000000000416292 in ?? ()
 No symbol table info available.
 #3  0x0000000000411c80 in ?? ()
 No symbol table info available.
 #4  0x0000000000406952 in ?? ()
 No symbol table info available.
 #5  0x00007f8e69724ead in __libc_start_main (main=<optimized out>, argc=<optimized out>, ubp_av=<optimized out>, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffbc08d918) at libc-start.c:228
         result = <optimized out>
         unwind_buf =  cancel_jmp_buf =  jmp_buf =  0, 498162418289285118, 4206480, 140736348084512, 0, 0, -498021567843461122, -435434157313288194 , mask_was_saved = 0 , priv =  pad =  0x0, 0x0, 0x418360, 0x7fffbc08d928 , data =  prev = 0x0, cleanup = 0x0, canceltype = 4293472 
         not_first_call = <optimized out>
 #6  0x0000000000402fb9 in ?? ()
 No symbol table info available.
 #7  0x00007fffbc08d918 in ?? ()
 No symbol table info available.
 #8  0x000000000000001c in ?? ()
 No symbol table info available.
 #9  0x0000000000000001 in ?? ()
 No symbol table info available.
 #10 0x00007fffbc08ee96 in ?? ()
 No symbol table info available.
 #11 0x0000000000000000 in ?? ()
 No symbol table info available.
StacktraceTop:
 ?? ()
 ?? ()
 ?? ()
 __libc_start_main (main=<optimized out>, argc=<optimized out>, ubp_av=<optimized out>, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffbc08d918) at libc-start.c:228
 ?? ()
ThreadStacktrace:
 .
 Thread 1 (LWP 6872):
 #0  0x00007f8e69738475 in *__GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
         pid = <optimized out>
         selftid = <optimized out>
 #1  0x00007f8e6973b6f0 in *__GI_abort () at abort.c:92
         act =  __sigaction_handler =  sa_handler = 0x7f8e69850d3d, sa_sigaction = 0x7f8e69850d3d , sa_mask =  __val =  140736348083740, 140249634747968, 0, 0, 140736348084512, 140249631083424, 140249645738440, 0, 4294967295, 206158430232, 1, 6427272, 0, 0, 0, 0 , sa_flags = 1781664242, sa_restorer = 0x1 
         sigs =  __val =  32, 0 <repeats 15 times> 
 #2  0x0000000000416292 in ?? ()
 No symbol table info available.
 #3  0x0000000000411c80 in ?? ()
 No symbol table info available.
 #4  0x0000000000406952 in ?? ()
 No symbol table info available.
 #5  0x00007f8e69724ead in __libc_start_main (main=<optimized out>, argc=<optimized out>, ubp_av=<optimized out>, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffbc08d918) at libc-start.c:228
         result = <optimized out>
         unwind_buf =  cancel_jmp_buf =  jmp_buf =  0, 498162418289285118, 4206480, 140736348084512, 0, 0, -498021567843461122, -435434157313288194 , mask_was_saved = 0 , priv =  pad =  0x0, 0x0, 0x418360, 0x7fffbc08d928 , data =  prev = 0x0, cleanup = 0x0, canceltype = 4293472 
         not_first_call = <optimized out>
 #6  0x0000000000402fb9 in ?? ()
 No symbol table info available.
 #7  0x00007fffbc08d918 in ?? ()
 No symbol table info available.
 #8  0x000000000000001c in ?? ()
 No symbol table info available.
 #9  0x0000000000000001 in ?? ()
 No symbol table info available.
 #10 0x00007fffbc08ee96 in ?? ()
 No symbol table info available.
 #11 0x0000000000000000 in ?? ()
 No symbol table info available.
Title: fetchnews crashed with SIGABRT in __libc_start_main()
Uname: Linux 3.4-trunk-amd64 x86_64
UserGroups:

The first 2 lines should be enough for the BTS server to file the bug report to the correct package and against the correct version.If you paid attention in the screen shot and the email report, you will notice that the email report does not include the CoreDump section. This was knocked off intentionally as we currently might not need it. If there is a need, the data is always available on the user's apport database, and the dev/user and seek it on a need basis. But in case, if a day comes when we really want it, that too is possible. The same email report will have the CoreDump seciton with a section like the following:

CoreDump: base64

H4sICAAAAAAC/0NvcmVEdW1wAOx9C0AU1f7/7LLAggirouF7VDQ0xcVXWGqLoq4Kur6KMmV5CoqwwqJYVquggYqhlVm3B3mt7OWlbnXtZeubHtfobc9Lb6xUemiU5f7PmfkcmBl3VMzbvff3Px89fPb7nfOeM2fOOfOdMzeNT5pgNBgEBpMwRmiRBMEmnA6bEC8MbfYvI6eN4BePBfvX0zQC6Q9RJyULY6NKpuGC6A8rO56uE07wH44lI7YynINlc6cmnFE3n1L5nNB7j+Ssv8lPelbDaeEkuBCu8ag6HENjz9PCmZTh6sNz/aanVz4PS6+V4aoQTohQhxM1rK2XGoQTI/yn5xD814sX4VyacGerFxbOObh15atj6Z17OKl89Qjn0Qkn6pSvEeGqB59z+YKU4aqmtS6fQgDS0wlXo5NPC8I5HK07DyyczdW68yCy9FytK58V4Zw64eou8l8+G8JZy/2Xj51Abfmaw21Th7Np+LTrD+Fc21p5/SGcRxPOoX8dye0T4ep00vPotU92Hh5u3Xln4Wwvt6587A7jaGU4C8I5X/afz3qd/pqFs73WuutWZOm91rr20hzuu9aVz4pwru9adz3YEM6jE65Op3wOdh6OtO68s3C2tgtaVT4nS+/cw0nlc7H61AnnDfBfPg/Cie0WnOv5C1KFi2tdPqsQzqoTTtAZ91SzcI4Frepf6tlIbeaCc71PyyECcXxm686fBeGsrQwnIpytleGsCFcX9IJPVT6jmrXnwRHM2q863NnOn5MNbJ0+irOFo2EcBjn8uGkzxgvN/ZuMID8t7lAXQXiPuHfhLjTE983qMmswAVVmhpydm5UpZhYsEiaq254PCFLkW8nfQF9cViT1HUM18Te9LefjEhahJv6zgV3DtI7LMaJhdSzMwMFo+cIIgdPWbXaWOyMnP2tpEbwPLi4qHFyUnps/uPmI+EfqOhBD/SBF3nq19J1S+VmT8Z389iVVm8CBdhAzwQHNl 7xNNReLV6SpPH/NUzH0OWZNHkPAVYPl+Npo9GEaua1GDtfIF2ni7wz+5QP5fOOOIXxxTJYjWPgP/bfLQHSLRkUd3hTgv749PWm7FP7r0FcDP15U/cmO9fL4jLFNgzkaiBr4zwWL//QaYtey3vH/NtBrxEbbBHFJk6bOTuFt4v9cmwj4N/vn4ODg4ODg4ODg4OD4/wE3aZ7/G/H8n60B2aDfFmVs9kOf/5vJ325CV2n+HSgol59tKvYiasZmxRzNJCeIhG0q7gY1Y4OCA1UlsKl4b5hRxWxhu2Vdmq0Dp6vYi8UxS5SgCmdEuBiEi4F

Now, Is this going to be useful? Will we get flooded with bug reports?

Usefulness: I think this will uncover many bugs that might be getting unnoticed today. Take this example itself. This bug was detect against the leafnode package's fetchnews binary. That binary does a quiet job in the background, fetching news. I never was aware that it had been crashing. As a system-wide monitoring tool, apport was able to detect, trap and inform the user of the crash. So I think this will be useful and improve the overall quality.

Abuse/Flood: This is something I can't predict. Perhaps it will bring in challenges if people just blindly click on the Send Report button. One option can be to have the "Send Report" checkbox unchecked by default. That'll hopefully lower down the possibilities.

What do you think? Let me know your comments.

This change will soon be pushed to apport in experimental. Hopefully this weekend.

I want to wrap up this post with a Thank You note to Martin Pitt and his team who created Apport, and with such simplicity. It took me 30 lines of code to adapt it to Debian. My intent with Apport is to keep the changes to the minimum so that we can always leverage new features and fixes that Apport brings in. So, as far as I'll try, there will be no drift from its original shape.

Categories:

Keywords:

After reading Jakub s pet peeve about debhelper build-dependencies I decided to check my own and sponsored packages to see how they fare.

find debian/ -type f -name control   xargs grep -h -o 'debhelper (&gt;= 9[^)]*)'   sort   uniq -c
      2 debhelper (&gt;= 9)
      2 debhelper (&gt;= 9.0)
      3 debhelper (&gt;= 9.0.0)
      1 debhelper (&gt;= 9.20120115)

Oops! Something to fix in all subsequent releases.

Continuing in my better running through technology phase that I'm currently going through, I got all excited when I discovered that Polar make a Bluetooth-enabled heart rate monitor chest strap. Prior to this, I'd be lamenting how there wasn't a large choice of ANT+ enabled Android phones (to my knowledge there's just something Sony makes) So I got all excited and ordered a strap and it arrived today. This is my initial review (I haven't gone running with it yet, I've just had a tinker) I'll start with the bad first

the battery cover is a bit dicky: I took the battery cover off to confirm it came with a battery and then had a whale of a time getting it back on. I haven't managed to get it on as flush with the back as before I took it off. This appears to be a common complaint in the Amazon product reviews also.
hard to tell what its auto off timeout is, whether it's on, etc: Basically there's a large lack of feedback as to what's going on. Is it on or off? Is it wet enough to turn itself on? Is it reading a heart rate, or is the Bluetooth pairing just not working? The most accurate way I've found to determine if it's "working" or not is to unpair it and then repair it again. If you get a PIN prompt it's talking. By accident, I've found indications that it will turn itself off after not reading a heart rate for 10 minutes, and to reset it, you detach it and wait 30 seconds and reattach it. This would have been good information to include in the manual

Now for the good

reasonable Android app support: Heart Rate Monitor for Polar claims to support it, but I haven't managed to get it to do anything useful yet. I was pleasantly surprised to discover that My Tracks has support for it. Noom CardioTrainer is one that I was already trying out alongside Strava Run (which doesn't have support for it). There's also Sports Tracker and Endomondo. The UI for both of these also show the battery level. I've found that trying to have multiple apps reading the heart rate monitor simultaneously seems to be an exercise in fail, and that the Sports Tracker app seems to start a background service which subsequently causes all sorts of problems for any of the other apps started after it has started.

And the ugly Looking back at all the Amazon product reviews, they're pretty much split equally between 5 stars and 1 stars. The product seems to either work flawlessly or absolutely dreadfully. I was beginning to think I was in the latter group and that I'd bought a white elephant, but now that I've gotten to the bottom of the idiosyncrasies of talking to it from Android, it seems to be behaving fairly reliably. Talking to it from Linux, and the reason behind the title of this post One of the first things I tried doing after Android was being initially flaky for me, was to try and talk to it from a Linux laptop. This proved fairly straightforward using rfcomm. I didn't get anything human readable out of it though. Being curious as to how these Android apps were able to decode the data, I went looking for some API documentation, and a Google search led me to this sad forum discussion. So the API information is not freely available, and their CEO personally signs off on who gets access to it. How ludicrous. Do they want to sell product or not? That said, I did also find this blog post which, courtesy of the aforementioned Open Source My Tracks Android app, lays it all out for you. So them being all anti-development with their information is kind of pointless. Polar's website doesn't mention anything about their management, so I have no idea who their CEO even is. Wikipedia is also none the wiser. I'm looking forward to going for a run tomorrow and seeing how this thing pans out.

Even though I've planned to do this on Monday, it somehow slipped to Wednesday, but I've finally filled in GSoC 2012 evaluations for all students I mentor at phpMyAdmin. Generally all of them perform quite well, but there is always room for improvements :-). The greatest pain every year is filling up evaluations for more students - every each of them starts with same questions for mentor (eg. how many GSoC did you participate in or how much time you spend on GSoC). I know I can copy and paste answers, but still this looks like something not necessary. Also some information is probably already known to Google (eg. in which years I did participate in GSoC).

Filed under: English Phpmyadmin 0 comments Flattr this!

Search Results: "ed"

14 July 2012

Romain Francoise: Getting clickable URLs in xterm (sort of)

Rudy Godoy: svn changelist

13 July 2012

C.J. Adams-Collier: New whiteboarding

Matthew Garrett: Microsoft's ill-chosen magic constants

Joey Hess: I am become Joey, destroyer of drives

Christian Perrier: DebConf running: stage 10

Russell Coker: Some Proprietary Platform Issues

Michal Čihař: Intel SSD firmware update on Linux

Matthew Garrett: A 12pt font should look useful everywhere

Jonathan McDowell: Revoked: 0xF1BD4BE45B430367 (1024D key)

Dirk Eddelbuettel: RcppArmadillo 0.3.2.4

C.J. Adams-Collier: NIST::NVD 1.00.00

12 July 2012

Cyril Brulebois: Thread filtering in mutt

Richard Hartmann: Do what I mean

Christian Perrier: DebConf running: stages 8 and 9

Enrico Zini: More diversity in Debian skills

Ritesh Raj Sarraf: Reporting bugs with Apport

Craig Small: debhelper versions Guilty!

11 July 2012

Andrew Pollock: [tech] Polar epically anti-developer? A product review of the Polar WearLink + transmitter with Bluetooth

Michal Čihař: GSoC evaluations submitted