With all the recent talk about running on Planet Debian I am proud to announce that I did a 10K run today. It took me just about an hour a pace which for Bubulle, Noel etc. is approximately equivalent to standing still but I managed to finish without collapsing in a puddle of sweat and shame, so I consider it an achievement.
It feels like I'm sitting in a roller-coaster wagon. There's probably
too much change going on for me to assimilate naturally. In
particular:
I just wrapped up (well, mostly) one of the toughest Uni semestres. I had
to deal with lots of very time consuming assignments, and then the usual
round of final exams. Even if this semester I got the best marks in my
journey (or shall we say Via Crucis) through University, I still
managed to fail one exam, for the Advanced Networks subject, which is
quite annoying, given I got high marks (even the highest in one case) in
other subjects I really don't master at all. In any case, this is the end
of the pain. The only thing that's left is just one exam and a project
based on GNU/Linux technologies which will basically mean formatting for
prettyness the sysadmin docs we've been collecting at the office during
the last few years. This effort will be nothing to what I've been doing
during the past 18 months, so I'm really relieved to have it past me
already.
Getting rid of studies comes just two weeks before a big change in my
professional career. Friday was my last day at the
Institut Tecnol gic d'Inform tica, after
five and a half fantastic years working with awesome people in a very
friendly atmosphere. I've learned a great deal, and taking this decision
wasn't easy at all. I leave lots of good friends behind, people I really
love, and tomorrow will be difficult to not have them around me. I wish my
ITI ex-workmates the best of luck in these difficult times for everyone in
Spain and specially in the Valencian Country with the massive cuts going
on. I feel the timing for this jump couldn't be better.
Tomorrow, when I get ready to go for work, I won't be leaving home at
all, instead I will just sit where I am right now, at home, and log into some
corporate IRC server. Tomorrow I'll be joining
Collabora, and I'm a mix
of excited, curious and happy about this incredible opportunity. Thanks to
Sjoerd for nags, I might not be
writing this if it wasn't for you!
When I was first approached about this, I thought Collabora was a small
company. But as I looked more into it, I discovered that's not longer the
case, there's many more people than I imagined working there (here!), and
was delighted to see I knew many of them, and many other are well known
members of the major Free Sofware communities. I'll be joining the
sysadmin team to work closely with
Jo Shields. See you tomorrow,
folks. :)
This opportunity to work from home is godsend, given the third bit of
change that'll be happening soon: sometime in late September, Maria and I
should join the ranks of first-time parents, following the baby boom wave
surrounding us. While you can imagine we're really happy about this, we're
also freaking out because this is going to happen in just two months
and a half, and weeks go by really fast lately. So yeah, being able to be at
home with this really small baby will be a big bonus for the incredible
experience we're about to enjoy. We've been both busy with other stuff,
but during the summer we should be focusing on preparing the baby's
arrival. There's a whole lot to do!
Expect my Debian and other Free Software activities to get a hit, of
course. :) If I am normally sleep-deprived, this is going to be the next
level.
porter-* groups, so
that I can fulfill installation requests in various chroots on
Debian porterboxes; this means real DSA members can concentrate on
more important things while still keeping the turnaround quick for
developers who want to debug stuff on exotic architectures.
Reminder for that procedure:
Chroot Install Request Guidelines.kfreebsd-* buildds for a while, I m
still in the wanna-build team, meaning I can take care of give
backs, one of the most common requests on debian-wb-team@. It s
been a while since it s been split up from debian-release@, and
instructions are still available in
wanna-build.txt.
Basically: anything buildd-related goes to
$arch@buildd.debian.org or debian-wb-team@lists.debian.org,
with the sole exception of binNMUs, which are handled by the
release team.testing, and more recently, dealing with unblock
requests during the freeze. While the Debian world is usually
driven by the just do motto, there s one area where one has to
learn to say no, sorry . Hopefully people won t hate us for that,
and we ll find alternative ways (like backporting specific fixes,
or postponing new features until wheezy-backports is open).debian-boot@ stepped up to prepare new
debian-installer releases, I figured I would give a hand there
until somebody more involved with d-i would manage that on the
long run. That s
a
lot
of
heavy
work,
trying to get all involved packages into shape at a given moment,
and getting people to fix their stuff when anything
breaks. Hopefully that ll work out and once CD images are ready, we
should be able to run some more tests on those before officially
publishing d-i beta 1.pettersson (the very nice machine on which images
are built), using the debian-cd account. The intent was to make
sure debian-installer could safely migrate from unstable to
testing. That has happened lately, so images are being prepared.debian-cd. I m also pretty sure having
more people involved in the d-i team would be very nice, especially
if one could find out how to make the whole release process less
insane than it is currently. I guess we could try out new ideas right
after the release; it feels to me that right now is just not the time
to fight the current release process.
Sitting in the airport during a layover on my way back from DebConf is one of
the few times of year that time and motivation come together and routinely
lead me to blog.
Each year's DebConf has been special in its own way. This year at
DebConf 12, in addition to the usual
routine of catching up with all my far-away Debian friends, and of
making new Debian friends in a country I've never been before, I got a
special treat: my first opportunity to experience the practice of
medicine in a foreign country.
Last Saturday after arriving in Managua, I discovered that the very pretty
paving stones making up the hotel walkway were also very slippery when wet,
and the thin rubber strips that had been helpfully put in place to make them
less slippery did not measurably succeed in doing so. So as it was raining
that afternoon (as it does nearly every afternoon this time of year in
Nicaragua), I slipped, and made the critical error of not falling.
Instead, I stopped my slide - as it happens, by using the big toe of my
left foot as if it were a roller skate brake.
I don't recommend this, particularly if, as in my case, you already had it on
your todo list to consult a podiatrist after DebConf regarding an ongoing
feeling of weakness in precisely that part of precisely that foot.
So while everything seemed fine the next day, Monday I woke up early
with excruciating pain in my foot which, having forgotten about the
incident two days prior, seemed to come from nowhere. After favoring
the foot for another day and trying to keep the pain at bay using just
OTC drugs, by Tuesday my foot was quite swollen and a source of concern. So
I visited the clinic on the university campus, where the doctor diagnosed me
with a dropped arch plus cellulitis due to bacteria entering through some
invisible cut.
Conclusion: university campus clinics are equally useless the world over.
But at least in addition to pointlessly prescribing antibiotics, the doctor
also prescribed some anti-inflammatory drugs to help bring the swelling
down.
Nevertheless, my questionable mobility kept both me and Patty from attending
the day trip on Wednesday, which was a real shame as I had been keen to
climb a volcano that day with
my fellow Debian Developers (which in the end didn't happen for anyone, but
that's a story for someone else's blog). Instead I took it easy for the
day at the hotel, together with a few others who had opted not to attend
the day trip, catching up on email and other work and hoping matters would
improve. But by the end of the day the swelling was as bad as ever, if not
worse, and I had no idea what was going on. Was it broken? Was something
dislocated? And so I decided that the following day I would go to the
hospital.
The nearest hospital, as given in the DebConf local information page, is
the
Hospital Militar.
It's a strange sort of thing as an American who remembers the 1980s to be
seeking medical care from a facility operated by the Nicaraguan military; but
accompanied by Fitoria, my native escort from the local
team I had nothing to worry about; and besides, as a frequent international
traveler I long ago learned the secret truth that people are people
everywhere, no matter what flag they were born under. The highlight of the
hospital visit was definitely when a member of the hospital staff, in full
military uniform, shooed me towards a chair instead of standing to talk to
her because "every patient has the right to sit, no matter what country
they're in".
After six x-rays and a doctor's consult, the conclusion was that it's
probably not a broken bone and that it will probably clear up in just a
couple of days with an even-better anti-inflammatory prescription and
taking care of it by not walking on it. And indeed, my foot was already
feeling better by Friday and aside from a little tenderness is now just
about 100%.
There are plenty of other entries on Planet Debian
talking about the conference itself, and I don't think I have much to add to
what's already been said there. But as for Nicaragua, I can conclude that it
must be one of the best countries in the world to break your foot in - between
the help of the hotel staff, the top-notch medical professionals, and above
all the support of the DebConf local team (with a very big thank you again to
Fitoria!), this is one brand of socialized medicine I can appreciate.
Not sure if that will work as I expect, but here as my runs in the
city of Managua, combined in one single map, thanks to OpenRunner:
<script src="http://www.openrunner.com/orservice/inorser-script.php?key=mykey&ser=S03&id=1802807&w=500&h=350&hp=128&k=5&m=0&pa=0&c=0&ts=1342329989" type="text/javascript"></script>
This morning, I ran again with No l, my longstanding Debian running
friend.
The goal was, this time, to explore the South-East heights of
Managua. I noticed a road that seemed to be quiet enough and not
requiring a too long transit through busy, noisy and bad smelling
highways.
So, at 06:00 we headed from the Seminole hotel to the road to Masaya
(the very large highway that goes in front ofMetrocentro). We had to
run along it for a bit less than 2km. Not the best thing but the road
was not very busy at that time.
Then, we turned right into a road heading towards a quite "classy"
neighbourhood where roads are well paved, there are sidewalks, etc, etc.
It was going up ALL TIME LONG, which is interesting as a start. This
placed is named "Lomas de Santo Domingo" in Google Maps.
We even found there the embassy of the Islamic Republic of Iran. I can
tell you, the Iran ambassador is quite living in a neat place and
probably very happy to be there..:-)
Fromthere, a very good concrete road starts to go up and up and up and
up. many many very high standard villas, with fences, guards, etc.
Strangely, there were several "For Sale" signs instead of "Se Vende".
So, I guess this is a sign that this place is mostly inhabited by
(very rich) foreigners, diplomats, etc.
This very nice road was also....climbing a lot: 180m in 3.5km, so 5.1%
average, but sometimes closer to 10%!
At the very end of the road, we however ended....on a fence. It's
apparently guarding the final part of the road where even more fancier
villas seem to be, according to the satellite view..:-).
We tried to use a small path up, but had to stop quite quickly.
(OK, No l is definitely blurry there....blame the tired eyes after
8.7km climbing all the way)
And then, all we had to do was....going down..:-). Being both in a
fairly good shape, that went quite fast. But we both agreed that the
final part, above 12km/h along the highway, with the sun hitting hard,
was quite a challenge.
I really admire those people who happen to run long distance in places
like Managua. I can't even imagine running a marathon here....
GPS trace of what
finally turns out to be my longest run here as of now with 17.5km in
about 1h40.
| Title | La mochila viajera The travelling backpack |
| Publication Type | Broadcast |
| Year of Publication | 2012 |
| Authors | Wolf, G, Bello L, Ram n E, Taleno A, Ortega J |
| Refereed Designation | Non-Refereed |
| Full Text | During DebConf12, and thanks to Fito's kind invitation, a bunch of us were part of a radio program that's transmitted in Managua and Chinandega, La mochila viajera . This program talks about different viewpoints and problematics about migration, seen from the eyes of Nicaraguans, which share quite a bit with us in Mexico But at the same time, are very different. I was invited as part of a research group in UNAM on the topic Communication, trasmigration and emergent systems . To be honest, I'm way behind schedule with the part of the research I should be doing, but here I very roughly describe (part of) the topic I'm interested in. The session was quite interesting. Of course, the reason I'm sending this to the blog is mainly that I want to keep it at hand, but I think some of you might find it interesting. Of course, it is in Spanish, so YMMV ;-) |
| Attachment | Size |
|---|---|
| La mochila viajera, 13 de julio del 2012: Migrantes y software libre | 84.19 MB |
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
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
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'.
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?
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
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.
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.
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:
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..:-)
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:
l10n-tagged BTS bugs at any rate.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.$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.editor=.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.
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.
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
$ mkfs.msdos /dev/sdX1Note: 'X' is to be replaced by the exact name of your USB key. An hint: call 'tail -f /var/log/syslog" and unplug / replug your USB key. You will see some entries like "...sdb Attached SCSI removable disk". So, there, it's "sdb".
$ qemu -boot a -fda balder10.img -hda /dev/sdX A:\> sys c: A:\> xcopy /E /N a: c:Note that you will need "root" privileges.
$ qemu -hda /dev/sdX
$ unzip Bcom_LAN_14.2.x_DOSUtilities_A03.exe
c:\ uxdiag -t abcd mfw 1
One week. One long week. One beautiful week. One of the two major weeks of the year has passed since my previous post. Surely, we are in the middle of the two Major Weeks of the year, in the yearly schedule I have upheld for almost(!) ten years: DebConf+DebCamp.
Yesterday, DebConf officially started. For the first time ever, we had a DebConf track targetted at the local (for a wide definition of local: All of the Central American countries) communities, which I chaired.
We had the following talk lineup during this track:
After a series of organizational hiccups I hope nobody notices (oops, was I supposed not to say this?), today we had a beautiful, fun and most successful cheese and wine party, as we have had year after year since 2005.
As many other people, we did our humble contribution for this party to be the success it deserves.
There is lots of great cheeses, great wines, and much other great stuff we have to thank to each of the individuals who made this C&W party the success it was. Yes, it might be among the least-academic parts of our conference, but at the same time, it's one of its most cherished -and successful- traditions. And above all else, we have to thank our Great Leader^W^WCheeseMaster (who we still need to convince to play by our Great Leader's mandates - And no, I don't mean Zack here!)
Hugs and thanks to my good and dear friend Christian Perrier for giving form to one of DebConf's social traditions that makes it so unique, so different from every other academic or communitary conference I have ever been part of.
We still have most of the week to go. And if you are not in Managua (and are not coming soon), you can follow our activities following our video streams.
Remember, debian/rules, now more than ever! And even given the (perpetual) heat in Managua: Wheezy is frozen, whee!
[ all photos here taken by regina ]
| Attachment | Size |
|---|---|
| 100_2110.JPG | 1.53 MB |
| 100_2119.JPG | 1.49 MB |
| 100_2121.JPG | 1.52 MB |
| 100_2135.JPG | 1.49 MB |
| 100_2144.JPG | 1.11 MB |
| 100_2146.JPG | 1.53 MB |
| 100_2145.JPG | 1.08 MB |
| 100_2122.JPG | 1.51 MB |
It's almost seven years now since I wrote/published Mermaids. It was an important step in my life, confessing publicly what I've found out about myself, how I feel and identify myself. It definitely has been a certain turning point in my life.
A year later, there was the Debconf6 in Mexico, which was just as important. I was wearing a skirt for the first time, and that for the whole duration of the two weeks. It was an enormous feeling of freedom, and I knew I was feeling at home. That was also the time I shaved off my beard.
And since? Well, I sort of limited myself to these two weeks every year. Debconf is my haven, Debconf is my home. Here I allow myself to be myself. Debian is my family. And like in every family, there are people who won't understand, but that doesn't matter. I feel comfortable to express myself in this crowd in the way I feel.
Being abroad seems to help with the confidence, and it seems like it also shines through. I haven't had lots of strange looks. To the contrary, when I went with a skirt to a homosexual acceptance event at home in Vienna, there was a group of gays who were pointing and laughing. Quite an interesting experience, one would assume that people who are wanting more acceptance would be more acceptable and tolerant themselves...
But, I don't think I will ever take the step toward actually turning my body into a female one. It was an important step for me to find out about my inner self, and it actually managed to make me accept my male body; even though I can totally relate to people not being able to understand this both people not in the situation and people being in the situation and needing the physical adjustment to be able to be happy again. But this is what and how I am: Contents may vary from packaging.
This though has an inherited problem: as I am not (usually) heading for a female appearance (besides my skirt during Debconf), people keep addressing me with a male pronoun, even, or rather especially when using my nick Rhonda. This is something that I consider a fair bit disturbing, especially when it comes from people that I consider to address with the term friends. One would assume that people who you share a fair bit of private life with would be the ones who can understand and relate better than others. But that's where we are, and I also can understand the troubles: I'm not giving them much visual help for fixing their thoughts.
I found the confidence in my body, and like most of you know, I have a son I dearly love (and miss like hell these two weeks), so I know how to use the toolsit comes with, frankly spoken. But I won't go the road to
adjustmy body to be a female one instead, just to convince people that I really am the female person that I identify as. It might be hard for you to understand that, it might be hard for you to accept it it is also hard for me, to fight for the acceptance that I thought are an inherent part of the term friendship. I have deepest respect for the people who feel the requirement and have the strength to adjust their body to their mind. It though just isn't the road for me. I already have enough uncertainties in my life to cope with, and I don't need another one to deal with, related to that I might not be able to accept my body after the transition than I am able to accept it now. It's just not important enough for me to find my place. My place is here, my home is Debconf.
Next.