Search Results: "tar"

23 September 2010

Michal Čihař: Documentation translation

Some weeks ago, I've started to change documentation structure of Gammu to move from separate documents here and there into one comprehensive documentation which would cover it all. As a tool to do this I've chosen Sphinx, simply because I felt most convenient with the format and outputs it provides. So far the SMSD documentation has been converted from various places and formats, but it also opened up a question - how to deal with translations? So far we used po4a to translate man pages, however using it for generated man pages is slightly complicated (there are some macros which po4a does not understand and it seems to break encoding on the way). Translating whole new documentation is something what is unlikely to be finished, especially considering fact, that the only real existing translation so far is Czech which was done by me. For now I decided to keep old translated man pages and postpone the decision, but considering current situation, I will most likely just drop the translations for man pages unless I find some good solution how to translate Sphinx documents (po4a should be able to do that, but it will probably need some tuning).

Filed under: Coding Gammu Wammu 1 comments

Julien Danjou: Gnus news is good news!

As I already wrote too many times, I've started to use Gnus 6 months ago, and never looked back. At that time, I joined the ding mailing list in order to ask some dumb questions and, once, send a patch. There were very low activity on that list. Until Lars, the original Gnus author, came back. Three weeks ago, he started to wrote a new wash function to render HTML mails properly, with pictures. It's named gnus-html', and is (for now) based on w3m (but not on emacs-w3m, which is not part of Emacs). Last week, I've sent a set of patches to replace the usage of curl by the standard url-retrieve' function to fetch images, plus various enhancement. It seems that my work was good enough that Lars offered me write access to the git repository. I can therefore mess up the Gnus entirely. Hurrah! I've continued to work on gnus-html' and recently merged a set of patches improving image retrieval (which is now done in parallel) and starting to use url-cache' to cache image for a defined period of time. Of course, I found a bunch of tiny bug and special case while reading RSS feeds and various HTML mails, and fixed them all along. Lars added a libxml binding for Emacs 24, providing the html-parse-string' function. His future plan seems to be the abandon of w3m in favor of a native parsing via libxml to render HTML, and therefore, HTML mails. I should also mention the new nnimap' back-end; Gnus has been designed to read NNTP newsgroups, and not mails. Consequently, it had a very poor behaviour when used with a back-end such has IMAP. Lars took a week to rewrite entirely our dear nnimap' back-end, and make it act in a more expected way. There's still a bunch of bug and code to write, but it is at least usable and seems faster than the old code. Last thing I did was to rewrite the icon support in the group buffer. When I started to use Gnus, I was curious and tried to configure this. I never managed to make it work, and now know and understand why it was broken. So I ended rewriting entirely, and now it works. I never though I would understand, fix, and commit this code when reading the Gnus documentation this winter, but hell yeah, I did. Now I've still several little project to improve things in all sort of area. We'll see what I'll do next. :-)

22 September 2010

Vincent Sanders: I like driving in my car. It is not quite a Jaguar

I work from home, this is a good thing. I benefit from a 20 metre commute, comfortable working environment and generally low carbon lifestyle.

Except on Wednesdays, on Wednesday I have to get up early and go to the office, this is not usually too much of a chore and takes around 90 minutes each way.

Today was different, I made a small five minute diversion to collect a colleague to whom I was giving a lift and then due to a little problem near the M6/M61 junction spent a fun filled three hours sitting in traffic crawling along the M56. At least I had company instead of being on my own.

Before I did the return journey I decided to check the traffic news sites. Oh dear now the M60 was stuffed, I altered the route and only had to queue on the M56 for twenty minutes or so. I dropped my colleague off at his place (avoiding the worst bits of the M62/M66 junctions by use of a rather convoluted back route) and proceeded to queue on the M62 for a while for no apparent reason.

Basically I have spent almost seven hours in the car today to do a 150 miles or a little over 20 miles per hour average. I was just going to rant about the dreadful lack of any redundancy or resilience in the UK road system which often grinds to a complete and utter halt if there is a single failure.

However a different thought has wandered across my travel weary mind. It has occurred to me that this average speed is faster than anyone could reasonably expect to do this trip for the majority of human existence.

In 1810 and indeed for all time before, your best possible speed by good horse, for 150 miles, would have been two days (and your horse would have probably been very poorly afterwards) This assumes your horse could do the 75miles (120km) each way in times consistent with modern world endurance trials... across a mountain range! Yes the Pennines are only tiny but even so!

A hundred years later, in 1910, the British railway network was nearing its zenith in most measurable terms. The influence across the north of England was profound and pushed the industrial revolution ever faster towards its climax before the first world war. Even at this point in time my best reading of the available timetables says I would have needed to change trains four times each way, purchased eight separate tickets from six different companies and taken around nine hours to make the journey allowing for hanging around on platforms.

Another fifty years on, in 1960, the trans-pennine car journey would have been on poorly maintained trunk routes through the decaying cores of the declining post-industrial northern cities. The route would probably have involved the A646, A59 or the A58 which at this time were not the well maintained (if slightly shabby) roads of today but instead were dangerous twisty and, from the looks of the archive photographs, positively heaving with traffic. On these pre-motorway strips of tarmac the 150 mile round trip would have taken in excess of seven hours (even today's mapping systems suggest over four and a half hours would be needed)

So instead of being frustrated that my commute took an extended period today I have instead decided that I shall enjoy the fact it was faster and certainly more comfortable than at any time in the past. Well that and I need to get the cars air-conditioning fixed ;-)

Gunnar Wolf: Damage control: Cleaning up compromised SSH keys

This morning, my laptop was stolen from my parked car while I was jogging. I do not want to make a big deal out of it. Still, even though I am sure it was not targetted at my data (three other people at least were reporting similar facts in the same area), and the laptop's disk will probably just be reformatted, I am trying to limit the possible impact of my cryptographic identification being in somebody else's hands. GPG makes it easy: I had on that machine just my old 1024D key, so it is just matter of generating a revocation certificate. I have done that, and uploaded it to the SKS keyservers - Anyway, here is my revocation certificate:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: A revocation certificate should follow
iHIEIBEIADIFAkyaOZwrHQJBIGNvbXB1dGVyIGNvbnRhaW5pbmcgdGhpcyBrZXkg
d2FzIHN0b2xlbgAKCRDYDvNai7UnrzWAAKC34eF76JQjxrZqSjNwcC0dU/5VbACg
gMIMmYg91Sl3y8KsZXdGj/rV7UE=
=rdlT
-----END PGP PUBLIC KEY BLOCK-----

But What worries me more is access to the computers my ssh key works for. Yes, the ssh key uses a nontrivial passphrase, but still SSH keys cannot be revoked (and this makes sense, as SSH should not add the delay, or potential impossibility, to check with a remote infrastructure whenever you want to start a session). So, I generated a new key (and stored it at ~/.ssh/id_rsa.new / ~/.ssh/id_rsa.new.pub) and came up with this snippet:

$ OLDKEY=xyHywJuHD3nsfLh03G1TqUEBKSj6NlzMfB1T759haoAQ
$ for host in $(cat .ssh/known_hosts   cut -f 1 -d \  cut -f 1 -d ,  
                sort   uniq); do 
    echo == $host
    ssh-copy-id -i .ssh/id_rsa.new.pub $host && 
    ssh $host "perl -n -i -e 'next if /$OLDKEY/;print' .ssh/authorized_keys"
done

Points about it you might scratch your head about:

.ssh/known_hosts' lines start with the server's name (or names, if more than one, comma-separated), followed by the key algorithm and the key fingerprint (space-separated). That's the reason for the double cut It could probably be better using a regex-enabled thingy understanding /[, ]/, but... I didn't think of that. Besides, the savings would be just for academic purposes ;-)
I thought about not having the ssh line conditionally depend on ssh-copy-id. But OTOH, this makes sure I only try to remove the old key from the servers it is present on, and that I don't start sending my new key everywhere just for the sake of it.
my $OLDKEY (declared in Shell, and only literally interpolated in the Perl one-liner below) contains the final bits of my old key. It is long enough for me not to think I'm risking collision with any other key. Why did I choose that particular length? Oh, it was a mouse motion.
perl -n -i -e is one of my favorite ways to invoke perl. -i means in-line editing, it allows me to modify a file on the fly. This line just skips (removes) any keys containing $OLDKEY; -n tells it to loop all the lines over the provided program (and very similarly, -p would add a print at the end Which in this particular ocassion, I prefer not to have). It is a sed lookalike, if you wish, but with a full Perl behind.

Caveats:

This assumes you have set HashKnownHosts: no in your .ssh/config. It is a tradeoff, after all I use a lot tab-expansion (via bash_completion) for hostnames, so I do have the fully parseable list of hosts I have used on each of my computers.
I have always requested my account names to be gwolf. If you use more than one username... well, you will have to probably do more than one run of it connecting to foo@$host instead.
Although most multiuser servers stick to the usual port 22, many people change the ports (me included) either because they perceive concealing them gives extra security, or (as in my case) because they are fed up with random connection attempts. Those hosts are stored as [hostname]:port (i.e. [foo.gwolf.org]:22000). Of course, a little refinement takes care of it all.,/li>
Oh, I am not storing results... I should, so for successive runs I won't try to connect to a system I already did, or that already denied me access. Why would I want to? Because some computers are not currently turned on. So I'll run this script at least a couple of times.

Oh, by the way: If you noticed me knocking on your SSH ports... please disregard. Possibly at some point I connected to that machine to do something, or it landed in my .ssh/known_hosts for some reason. I currently have 144 hosts registered. I am sure I triggered at least one raised eyebrow. And I will do it from a couple of different computers, to make it less probable that I miss some I have never connected from while at the particular computer I am sitting at right now. So... Any ideas on how to make this better?

Luca Bruno: Report from the Debian/Ubuntu Community Conference, ITA 2010

From the 17th to the 19th of September in Perugia, Italy, it took place the 5th edition of the Italian Debian Community Conference, which has been attended by many contributors and users. For the first time, the event has been organized in collaboration with the Italian Ubuntu community, as to create a new joint conference in order to foster shared contributions and emphasizing the large common ground of our projects. This new experimental kind of mini-conference was then labeled DUCC-IT, to reflect both the local profile and the mutual collaboration. After the initial social night, spent discussing of several ongoing free software efforts and having dinner all together, the conference official opening started on Saturday, temporarily housed at University of Perugia, with a series of talks and hands-on session aimed at recruiting new contributors to work on development, translations, documentation writing and marketing. It has been a good opportunity to celebrate the Software Freedom Day too, in collaboration with FSUG Italia and the participation of some local schools.

The event been also attended by some members of the Debian Women and Ubuntu Women teams (whose goal is to promote women participation in both projects), who organized a round-table debate taking the Italian panorama as a study case. The discussion embraced different topics, ranging from the wide difference in numbers, to the deep causes of this phenomenon and how to improve the situation. With the help of the hacklab staff (hosting the debate), an audio/video streaming has been made available in real-time, and many remote participants joined us with comments and questions. This new kind of collaboration between our communities was found to be really positive and more events has already been drafted for the next year, including a translation sprint and a contributors meeting. We encourage worldwide local communities to try and engage in a similar experiment: organizing and joining a DUCC event will be pure fun. A detailed report of the conference will be soon available, completed by photos, participants comments, video records and slides for the talks.
We d really like to thank the Math Department of University of Perugia, the Projectz On Island hacklab, FSUG Italia, the Ubuntu-it community and everyone who contribute to this event.

Michal Čihař: Fixing phpMyAdmin bugs in Launchpad

Once in a time when looking at my Debian Developer's Packages Overview, I just start to think there is way too much bug reports for phpMyAdmin package in Launchpad. Today the threshold was 30 :-). Managing them is usually not that hard, because vast majority of them are just duplicates of same issue. Basically all problems come with the fact that dbconfig-common really does not behave nicely when database server is not configured and user tries to configure it. I know people should just answer no to first question, whether to use dbconfig-common, but they don't and it then horribly fails. Today I finally decided to ignore all errors from dbconfig-common in our packaging scripts, so you will get an error, but the package will be installed. As it seems that this is what most Ubuntu users expect after all. This also shows huge difference between Debian and Ubuntu users - such bug has never appeared in Debian bug tracker, but has zillions of duplicates in Launchpad in various incarnations (LP#618852, LP#621569 and the most favorite LP#456674).

21 September 2010

Richard Darst: The DebConf travel sponsorship process

This is a guest post by Michael Schultheiss, DebConf10 travel sponsorship team lead.DebConf doesn't just provide sponsored food and accommodation to attendees, it can also provide travel reimbursement to 20-30 attendees each year, from all over the world.The travel sponsorship team has historically been formed by a call to debian-devel-announce for developers to review sponsorship requests. This has resulted in one of the most transparent review teams of DebConf, which is by design since this is one of the hardest decisions to make. A team of about ten people will review applications. The travel sponsorship team is typically comprised of both people with past travel sponsorship team experience as well as new members to help make the process as fair as possible. The team will consider the listed workplans, the answer to the question "what do you do for Debian", their general knowledge of Debian contributors, and web searches of Debian lists, debian.org, and the web in general, looking for Debian and free software related activities.Applicants are rated on a 1-5 scale of contributor level and amount requested. These are averaged and sorted, and this is used as the basis of travel sponsorship - but is subject to human review for special cases. The team will then decide the cutoffs for the different queues - for example, DebConf10 used queue A which had money released first, queue B which was released after more fundraising, and queue C which was told "no". After these queues are decided, most of the selection team doesn't need to be as active, but anyone from that team can work with the organizers to decide percentages of funding of the queues and when to commit money to them, based on our budget.Attendees submit documentation for actual flight costs after the conference, and can be reimbursed for min(actual_costs, amount_requested).There are various problems with this system, which are pretty well known but not so easy to fix:

Attendees are supposed to put the amounts they can't afford to pay themselves, but we have no way of checking this (and probably wouldn't want to pry so much to be able to...)
Historically, money has been budgeted for travel sponsorship last, thus travel sponsorship usually isn't confirmed until late in the process. This means that flight prices have constantly gone up, and some people may be unable to attend DebConf due to uncertainty over travel sponsorship.
Attendees have a dilemma: They are supposed to enter only the amount they cannot fund themselves. But if there is a chance of fares being reimbursed at less the requested amount, then entering the amount absolutely required to attend results in a disadvantage.
Invariably, people get confuse "amount I am unable to afford" as "amount I am able to afford"
For some years, entering too high a requested sponsorship amount could result in a lower priority - instead of the selection team adjusting the amount downward. Thus, attendees have another dilemma about what to request.

These questions are hard to answer. I'm encouraged that there are some discussions on debconf-team which are working towards a better system. Most importantly, these people want to start early, which is almost guaranteed to result in a better outcome for everyone. If you are interested in working to improve the travel sponsorship process, I encourage you to get involved in the team and start early.Tags: debconf

Joey Hess: solar charge controller adventure

Xantrex controller, temporarily badly installed

As planned I have installed the Xantrex C-35 charge controller in the offgrid house. This was a bit of an adventure.. First I had to wait around in town all day for the UPS man to deliver the thing. Of course he didn't until 4, so by the time I got over to the house it was almost dusk. Further delayed by necessary visiting with the nearest neighbor (a country thing), who claims there are "panthers" up this holler.. So by the time I was ready to work, it was nearly too dark. First I checked the battery bank which I had left charging for a week without a controller or backflow diode. It had gained only half a volt (to 10.5v), so now I knew I really did need the controller in order for the sun to work for me while I am away. Then, barely able to see, I swapped that bank to provide house power. By 10 pm, using just my laptop, I'd drained 1.5 volts from it and it was as low as it should go. I had 4 hours of laptop battery. This was a bit of a problem since I tend to stay up until 3 am on it. Instead, I spent 2 hours, by kerosine lantern light, exposing, tracing, and testing wiring. I was able to find 2 wires that were clearly going to the battery bank and had current, and 2 others that were labeled as going to the panels, and, in the dead of night, had no current. Great, I thought, that's the wires I need, let's hook up the controller.. And I did, although only to the battery, since after all I couldn't be certain the other two wires were for the panels, without seeing voltage on them in the daytime. (This turned out to be probably wise, because in the morning, when I tried it, the controller reported no PV voltage. They turned out to be mislabled, and actually connected the battery to the breaker box.)

The problem with doing all that stuff at midnight is it took me quite a long time to wind down. I normally start winding down at 10 am and get to sleep at 3. Last night I got to sleep at 5. My four hours of battery for my laptop were nursed all hours through the night. Mostly thanks to powertop and the improved power saving of the kernel these days. And to not having wifi or anything enabled. I do wonder if my recent use of redshift to redden the screen causes the it to use less power at night, as I have never gotten five hours out of this laptop before.

Anyway, to get the controller hooked up to the PV array and actually charging the batteries, I ended up having to rip lots of wiring out of the wall, until I simplified the mess to something I could understand. And at the moment I've bypassed the PV array's breaker, which is certainly a safety hazard. So more wiring to do, but I did get it working. Finally, I hooked the house wiring up to the same battery bank that is being charged from the panel. This house had been using a 2 battery bank setup, because without a charge controller to moderate the PV voltage (17-25 volts), you can't also connect a load that expects 12 volts. The charge controller fixes that problem. The other battery bank is sitting unused for now. Later, I will equalize and connect the two, in order to get one large(ish) battery bank. Now, during the sunny fall daytime, I can use all the power I want; it's free from the sun. Battery bank shouldn't drain at all when I use power during the day, and the controller should charge them up and keep them topped off, so they'll be there for me at night. Now to verify that it's working like it's supposed to!

(I posted some documents and more thoughts from this here).

Daniel Kahn Gillmor: hotmail thinks powerpc means mobile

Apparently, live.com thinks that any browser coming from a ppc architecture is a mobile device. This sucks for the users of the hundreds of thousands of powerpc desktops still in service. I don't use hotmail myself, but i do support people who use it. I set one of my clients up with debian squeeze on their PPC machine because all the proprietary vendors have basically given up on that architecture -- debian represents the best way to get modern tools on these machines (and other machines too, but that's a different argument). However, this client couldn't get to their hotmail account, despite using the latest version of iceweasel (3.5.12). They were directed to a crippled interface that didn't include the ability to attach files, and was a gross waste of the desktop screen space. It appears to be the "mobile" version of live.com's services. However, the same version of iceweasel on an i686 test machine could access the standard version of hotmail with no trouble. My friend jeremyb helpfully suggested fiddling with the User Agent string exported by the browser. Some experimentation shows that the presence of the string "ppc" within any parenthetical expression in the UA makes live.com show the crappy interface. You can try it yourself (if you have a hotmail account) on your x86 or amd64 machine by adding (ppc) to the default valule of general.useragent.extra.firefoxComment in about:config. Stupid stupid stupid. I'd like to have fixed this by overriding the browser's reported architecture (or simply by removing it -- why does a web server need to know the hardware architecture of my client?). But there doesn't appear to be a way to do that with the way that mozilla constructs the UA. Instead, i needed to add a new string key named general.useragent.override which is not exposed by default in about:config. This raises some questions:

Why are we publishing our hardware architectures from our browsers anyway? This seems like unncessary leakage, and not all browsers do it. For example, Arora doesn't leak this info (despite a poorly-argued request to do so). Browsers are already too identifiable by servers. This information should not be leaked by default.
Why does live.com insist on sending ppc users to the crappy "mobile" version? Are they trying to encourage the treadmill of hardware upgrades that proprietary vendors benefit from? Is there some less insidious explanation? Are there actually more powerpc-based mobile devices than desktops?
why is there no simple way to tell Firefox/Iceweasel to override or suppress the architecture information? Having to override the useragent string entirely means that when iceweasel does eventually get upgraded, it's going to report the wrong version unless i can remember to update the override myself (i can't reasonably expect a non-techie client who never heard of user agents before today to remember how to do this correctly).

Any ideas?Tags: browser, hotmail, powerpc, ppc, useragent, wtf

Raphaël Hertzog: Everything you need to know about conffiles: configuration files managed by dpkg

The Debian policy dictates that package upgrades must take care of preserving user changes to configuration files. This article will explain you how most packages ensure this. This is important knowledge for anyone who has to manage upgrades: knowing how it works lets you easily automate most of it and deal correctly with the fallout. How dpkg manages configuration files Most packages rely on dpkg to properly install configuration files. Dpkg keeps a checksum of the last installed version of configuration file. When it must install a new version, it calculates the checksum of the currently installed file and if it doesn t match anymore, it knows that the user has edited the file. In that case, instead of overwriting the configuration file, it asks the user what to do. You probably already have seen those questions, they look like this:

Configuration file  /etc/bash.bashrc'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** bash.bashrc (Y/I/N/O/D/Z) [default=N] ?

In this specific example, if you answer Y or I (for yes or install ), dpkg will install the new version of /etc/bash.bashrc but it will also backup the current version in /etc/bash.bashrc.dpkg-old. If you answer N or O (for no or old ), dpkg will install the new version in /etc/bash.bashrc.dpkg-dist and /etc/bash.bashrc is left untouched. The two other answers allow you to examine the differences before taking a decision. Note that if you choose to start a shell, the new version is currently available as /etc/bash.bashrc.dpkg-new (and since Squeeze there are convenient environment variables $DPKG_CONFFILE_OLD and $DPKG_CONFFILE_NEW in case you want to create a custom review script). All configurations files managed by dpkg are called conffiles because that s the name of the field where they are recorded in the dpkg database. You can display the list of conffiles for any package:

$ dpkg --status bash
[...]
Conffiles:
 /etc/skel/.profile ecb6d3479ac3823f1da7f314d871989b
 /etc/skel/.bashrc 2afdd6c53990f2387a7ef9989af0bc07
 /etc/skel/.bash_logout 22bfb8c1dd94b5f3813a2b25da67463f
 /etc/bash.bashrc 5b3c3bc73d236e4e1b6f9b6c1ed5964e
[...]

The command dpkg-query --showformat='$ Conffiles \n' --show bash can give you the same information if you need to retrieve only that field. The 32 characters after the filename are the MD5 checksum of the original configuration file provided by the package. Avoiding the conffile prompt Every time that dpkg must install a new conffile that you have modified (and a removed file is only a particular case of a modified file in dpkg s eyes), it will stop the upgrade and wait your answer. This can be particularly annoying for major upgrades. That s why you can give predefined answers to dpkg with the help of multiple --force-conf* options:

--force-confold: do not modify the current configuration file, the new version is installed with a .dpkg-dist suffix. With this option alone, even configuration files that you have not modified are left untouched. You need to combine it with --force-confdef to let dpkg overwrite configuration files that you have not modified.
--force-confnew: always install the new version of the configuration file, the current version is kept in a file with the .dpkg-old suffix.
--force-confdef: ask dpkg to decide alone when it can and prompt otherwise. This is the default behavior of dpkg and this option is mainly useful in combination with --force-confold.
--force-confmiss: ask dpkg to install the configuration file if it s currently missing (for example because you have removed the file by mistake).

If you use Apt, you can pass options to dpkg with a command-line like this:

$ apt-get -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" dist-upgrade

You can also make those options permanent by creating /etc/apt/apt.conf.d/local:

Dpkg::Options  
   "--force-confdef";
   "--force-confold";

Bringing up the conffile prompt at any time The conffile prompt is only displayed when dpkg detects that the package provides an new version of the conffile. Thus reinstalling the same package will not bring up the prompt. But you can instruct dpkg to ask nevertheless with the --force-confask option. This is a new feature in Debian Squeeze. It will only ask for files that are locally modified.

If you want to read more articles like this one, click here to subscribe to my free newsletter. You can also follow me on Identi.ca, Twitter and Facebook.

4 comments Support my work

Michal Čihař: Spam protection for Django

Okay, adding comments lead exactly to the expected situation of spam comments, so I just added fccv and started using typepad to help me in fighting with spam. I hope it will catch most of it (it would catch all I've had to delete manually so far) and will avoid false positives.

Yves-Alexis Perez: Note for later: pbuilder, chroot and grsec

Another one, just not to forget it, since I'm just starting to play with grsecurity. When building package under pbuilder/cowbuilder and using a grsec kernel, you have some stuff to tune. I built my grsec kernel with the sysctl options enabled, so it's easier to fix. The first thing I needed, not directly related to building packages, is the permission for my user to execute stuff in untrusted folder (since I really need to be able to run stuff from my home). I've configured Trusted Path Execution with:

corsac@hidalgo: sudo sysctl -a grep kernel.grsecurity.tpe
kernel.grsecurity.tpe = 1
kernel.grsecurity.tpe_gid = 500
kernel.grsecurity.tpe_invert = 1
kernel.grsecurity.tpe_restrict_all = 1 So what I need from there is to add my user to that group:

corsac@hidalgo: sudo addgroup --gid 500 grsec-tpe
Adding group grsec-tpe' (GID 500) ...
Done.
corsac@hidalgo: sudo adduser corsac grsec-tpe
Adding user corsac' to group grsec-tpe' ...
Adding user corsac to group grsec-tpe
Done. That works fine for general usage (at the cost of less protection for my user). When trying to build stuff in pbuilder, the first problem I hit was during dependencies installation:

[81903.221359] grsec: From 127.0.0.6: denied chmod +s
of /home/corsac/debian/pbuilder/build/cow.8616/usr/local/share/sgml/stylesheet
by /home/corsac/debian/pbuilder/build/cow.8616/bin/chmod[chmod:10424] uid/euid:0/0 gid/egid:0/0,
parent /home/corsac/debian/pbuilder/build/cow.8616/var/lib/dpkg/info/sgml-base.postinst[sgml-base.posti:10421] uid/euid:0/0 gid/egid:0/0 grsec enforces some more protection when in a chroot, and especially forbids some operations in there. So I add an exception, using sysctl. For that, a convenient /etc/sysctl.conf.d/grsec.conf will help:

# we need to do stuff in chroots for package building
kernel.grsecurity.chroot_deny_chmod=0

# lock grsec sysctl
# kernel.grsecurity.grsec_lock=1 The last one is still in comment since I know I'll have to tune further the sysctl. With this, the build-deps install fine, but when starting the build itself, it fails because I can't execute stuff inside chroot, and especially not debian/rules:

Sep 20 19:43:24 hidalgo kernel: [87339.510137] grsec: From 127.0.0.6: denied untrusted exec of
/home/corsac/debian/pbuilder/build/cow.26657/tmp/buildd/evolution-data-server-2.30.3/debian/rules by
/home/corsac/debian/pbuilder/build/cow.26657/usr/bin/fakeroot-sysv[fakeroot:10916] uid/euid:1234/1234 gid/egid:1234/1234,
parent /home/corsac/debian/pbuilder/build/cow.26657/usr/bin/fakeroot-sysv[fakeroot:10895] uid/euid:1234/1234 gid/egid:1234/1234 That's again because of TPE. Because, inside the chroot, the pbuilder user (uid 1234) doesn't belong to the grsec-tpe group (which doesn't even exist). So the correct fix here is to create a 500 group inside the chroot, and add the pbuilder user:

corsac@hidalgo: sudo cowbuilder --login --save-after-login
-> Copying COW directory
[ ]
root@hidalgo:/# sudo addgroup --gid 500 grsec-tpe
Adding group grsec-tpe' (GID 500) ...
Done.
root@hidalgo:/# sudo adduser pbuilder grsec-tpe
Adding user pbuilder' to group grsec-tpe' ...
Adding user pbuilder to group grsec-tpe
Done. Et voil !

20 September 2010

Michal Čihař: German-Czech dictionary for StarDict

As there was started project for German-Czech dictionary, I've quickly added it to my conversion scripts and these dictionaries are now available in StarDict format as well. Don't expect much right now, the project has just started and contains only few words :-). PS: Authors are aware of dicts.info and other free dictionaries and want to cooperate somehow.

Marco Silva: Handling spam with SpamAssassin + Bogofilter + Procmail + Sup

This is mostly inspired on this article. The main difference is that I talk about sup instead of mutt, and use SpamAssassin together with bogofilter. Having all these utilities installed and the sources for sup configured, you only need to touch procmail and sup configuration files. My ~/.procmailrc contains a lot of comments, but what it does is basicly the following: If the message is smaller than 250 KiB, it calls SpamAssassin with it. This will create the headers X-Spam-Level and X-Spam-Status in this message. Only messages smaller than 250KiB are considered because most spam isn't bigger than that, and considering big messages would overload SpamAssassin. Then, if SpamAssassin consider this message as spam, tell bogofilter about it. Next, call bogofilter, which will add the X-Bogosity header to the message. Now we have to configure sup. We need to tell it to update bogofilter when we manually mark a message as spam. For this we can use ~/.sup/hooks/mark-as-spam.rb. We must consider two cases: the case where bogofilter thought it was not spam, and the case where bogofilter was not sure about its status. In the first case, we must tell it to forget that the message was not spam and to register it as spam now. In the second, just register it as spam. Also, we don't want spam on inbox. So we can edit ~/.sup/hooks/before-add-message.rb to look for the headers generated by SpamAssassin and Bogofilter and remove the :inbox label. It's important to mark unsure messages with a label so that we don't forget to mark it as spam if it is, and as not spam if it's not. So we need a way to mark messages as not spam. I included a new keybinding in ~/.sup/hooks/startup.rb. Unfortunatelly, I don't know how to include a new keybinding in sup without repeating all the keybindings for the mode I'm dealing with, so that's how I've made it. The command removes the :unsure label and mark it as non-spam. It also sets the undo command, unregistering the message in bogofilter. The case where the message was previously marked as spam, and not unsure, is also handled. I'm sure there's a lot of room for improvement, specially in the Ruby part, but it seems to be working.

Richard Darst: How DebCamp relates to DebConf

The week before DebConf has been traditionally been DebCamp. This has been advertised as a time for core teams to come early to work on their projects together, and this post will talk more about what that means.At DebCamp, there is not much infrastructure set up yet. We have (unfurnished) hacklabs, accommodations, and usually food from the very beginning. We'll have Internet access, but the network and power distribution isn't set up yet. People find what they can and make their own space to work. The DebConf team works on setting up hacklabs starting on day 0 or 1, and the DebCampers serve as the test subjects to make sure that everything works.There intentionally aren't many scheduled activities during DebCamp. The organizers have too much else to do, and events aren't the main purpose of DebCamp. If some people wanted a place to meet, they could probably find a place, though. Some years, there have been one or two workshop type events on the DebCamp schedule.DebCamp has frequently been explained by "Development teams like debian-installer and debian-edu also have the possibility of meeting beforehand for undisturbed collaborative work. ... Interested teams should contact the organizers upfront to make special arrangements." (From the DC10 website) Also included in DebCamp are the DebConf organizers - we desperately need that time to pull organizers from over the world together to get us on the same page locally. Furthermore, anyone without a workplan can attend DebCamp by paying their actual costs.However, saying that DebCamp is limited to these groups of people doesn't reflect reality: Anyone can attend. Thus the DebCamp description doesn't necessarily reflect the actual limits for attending. This has the appearance of resulting in (and some people believe it has) a DebCamp which is biased towards those who well-connected with organizers, since they know that basically anyone can go and get a free extended holiday with Debian people. In fact, getting anyone to review the submitted workplans has met resistance in the last few years.For DebConf10, we did manage to reach agreement to filter out possible tourist-like people, but it was a similar (or only slightly more strict) criteria than DebConf itself. This was done very late, too late to be fair to force adjustments in travel plans of too many people. The difference between the DebCamp listed criteria and who has gotten sponsored for DebCamp in the past caused contention among some new organizers this year. Why didn't they know that they would have qualified for DebCamp past years? The moral of the story is that we need to be more clear on the purpose of DebCamp and make the actual qualifications for attending concrete and well-known so that it remains fair.Of course, it's also true that non-core developers and other interested people to attending DebCamp is a good thing, since it is a strong motivator to get more involved in Debian. Local people are encouraged to attend and learn/hack/volunteer. DebCamp isn't meant to be exclusive, just to reflect the realities of a limited budget.
DebCamp is a very important part of DebConf, both for Debian development purposes and for DebConf set-up purposes. However, since it is a week of limited attendance with mostly the same people attending year after year, we need to ensure that it remains transparent to the rest of Debian.Tags: debconf

19 September 2010

Gregor Herrmann: RC bugs 2010/37

thanks to Lucas' recent archive rebuild & bug filing we have new stuff to work on :) my activities in the last week:

#567241 libbuffy-perl: "fails after binnmu"
apply patches from ntyni and upload to DELAYED/2
#578458 src:libcoro-perl: "libcoro-perl: FTBFS: E: Caught signal 'Terminated': terminating immediately"
send a mail to -close after it finally builds again (pkg-perl)
#592620 time: "time: FTBFS in ubuntu due to nonexistent build dependency"
upload NMU prepared by carnil to DELAYED/5
#594503 liblunar-1-0-dbg: "liblunar-1-0-dbg: empty package"
tell dh_strip about the -dbg package and upload to DELAYED/2
#595473 gobby-0.5: "does not depend on dbus"
close the bug as #595480 is fixed
#595836 enscribe: "enscribe: FTBFS in squeeze: Nonexistent build-dependency: 'libgd-dev'"
switch order of real/virtual package in Build-Depends and uploaded to DELAYED/2
#595837 libproxy: "libproxy: FTBFS in squeeze: pacrunner_mozjs.c:33:19: error: jsapi.h: No such file or directory"
tag unreproducible, close later
#595845 namazu2: "namazu2: FTBFS in squeeze: Nonexistent build-dependency: 'tk8.3'"
fix build-dep and upload to DELAYED/2
#595850 gjs: "gjs: FTBFS in squeeze: modules/console.c:53:18: error: glib.h: No such file or directory"
tag unreproducible, close later
#595871 freej: "freej: FTBFS in squeeze: make[5]: *** No rule to make target ./Makefile'. Stop."
tag unreproducible, close later
#595876 multiboot: "multiboot: FTBFS in squeeze: rm: cannot remove debian/multiboot/usr/share/info/dir': No such file or directory"
tag unreproducible

Gunnar Wolf: Unambiguous name for Free Software without ideological dillution

Asheesh posted When "free software" got a new name, which mentions about the transition period where the Free Software movement started its quest towards being understood by non-geeks, and when people started finding terms better suited for general (and specifically, business-minded) audiences. We are talking about facts that reached concretion 12 years ago, when the term Open Source was coined and divulgated. That is already far in the past to try and change it Still, during DebConf I was talking with several friends about it. In my opinion, there was never really the need to choose such an ambiguous name In English, the word Liberty unambiguously refers to free as in freedom, with no conceptual links to gratuity. Liberty is also a concept held dear by the values of the USA society (which is the birthplace of our ideological movement, so it's specially important). Jimmy Kaplowitz pointed out a reason: Liberty is an incomplete word. You could translate what Asheesh's post mentions, Freed Software Liberated Software, but libertydoes not exist as an adjective by itself, only when used as contrasting with an earlier more restricted situation. We can say some piece of software was liberated if it was born unfree, but what about things that were libre since the beginning? So, yes, as beautiful as Liberty is, and as advantageous as such a concept would have been for us... Liberty seems to be too imperfect to be able to represent our movement.

Lars Wirzenius: No orange dents

I am currently relying on netcafes and Orange prepaid to get online. Orange does not let me access identi.ca without jumping through hoops.

Them dastardly free software developers, always corrupting minds of children.

Andreas Metzler: What I hated about my sqeeeze upgrade experience - udev

Rant follows. I have upgraded my PC to squeeze this weekend. While this generally worked fine, udev (version 160-1) made my day. As usual I had not read the release notes previously and was hit by

Please upgrade your kernel before or while upgrading udev.

AT YOUR OWN RISK, you can force the installation of this version of udev WHICH DOES NOT WORK WITH YOUR RUNNING KERNEL AND WILL BREAK YOUR SYSTEM

dpkg to the rescue:

dpkg -i /var/cache/apt/archives/linux-base_2.6.32-21_all.deb 
dpkg -i /var/cache/apt/archives/linux-image-2.6.32-5-amd64_2.6.32-21_i386.deb  /var/cache/apt/archives/linux-image-2.6-amd64_2.6.32+28_i386.deb 
reboot

Afterwards the upgrade succeded. (For reference: The correct solution would probably have been to run apt-get install linux-image-2.6-amd64 and rebooting, before starting the dist-upgrade.) udev was not finished with me, though, the syntax for udev rules has changed again. ("NAME="%k" is ignored, because it breaks kernel supplied names", "SYSFS = will be removed in a future udev version, please use ATTR =", "BUS= will be removed in a future udev version, please use SUBSYSTEM=", etc.) So I started googling and rewriting my custom rules for USB-sticks and USB cardreader. After many reboots (the only way to test these rules nowadays), thing were still not working. My cardreader is not an exotic but a common one, i.e. it does not report media changes. (The guide for writing udev rules shares this opinion.) Previously I had:

BUS=="scsi", KERNEL=="sd*", SYSFS model =="Compact Flash",SYSFS vendor =="Generic-",NAME all_partitions ="cardreader/cf"

which caused udev to generate /dev/cardreader/cf1, /dev/cardreader/cf2, etc. on bootup (without media present), enabling me to configure /etc/fstab to allow mounting of /dev/cardreader/cf1 without superuser privileges. After googling I ended up with this new rule:

SUBSYSTEMS=="scsi", KERNEL=="sd*", DRIVERS=="sd", ATTRS vendor =="Generic-", ATTRS model =="SD/MMC          ", SYMLINK+="cardreader/sd%n", OPTIONS+="all_partitions"

and while I get ...

argenau:~# ls -l /dev/cardreader/sd
lrwxrwxrwx 1 root root 6 Sep 19 14:42 /dev/cardreader/sd -> ../sdd

... there is still no /dev/cardreader/sd1 (unless I insert a card and run fdisk -l /dev/cardreader/sd as superuser). Looks like OPTIONS+="all_partitions" is ignored. And indeed I find this in udev's changelog:

udev 152
[...]
The option "all_partitions" was removed from udev. This should not be needed for usual hardware. Udev can not safely make assumptions about non-existing partition major/minor numbers, and therefore no longer provide this unreliable and unsafe option.

Joy. Thanks udev for telling me consumer devices have been fixed overnight, USB cardreaders have suddenly started reporting media change events.

Obey Arthur Liu: Google Summer of Code 2010 Debian Report

Hello fellow developers, The summer is over

but I m happy to announce that this year s Summer of Code at Debian has been better than ever!

This is indeed the 4th time we had the privilege of participating in the Google Summer of Code and each year has been a little different. This year, 8 of our 10 students succeeded in our (very strict!) final evaluations, but we have reasons to believe that they will translate into more long-term developers than ever, all thank to you.

The highlight this year has been getting almost all of our students at DebConf10. Thanks again this year to generous Travel Grants from the Google Open Source Team, we managed to fly in 7 of our students (up from 3!). You certainly saw them, presenting during DebianDay, hacking on the grass of Columbia, hacking^Wcheering our Debian Project Leader throwing the inaugural pitch of a professional baseball game or hacking^Wsun-tanning on the tr s kitsch Coney Island beach. Before I give the keyboard to our Students, I d like to tell you that it will be the pleasure and honor of Obey Arthur Liu (yours truly, as Administrator) and Bastian Venthur (as Mentor) to represent Debian at the Summer of Code 2010 Mentors Summit on 23-24 October 2010, at the Google Headquarters in Mountain View. Like last year, we expect many other DDs to be present under other hats. We will be having 2 days of unconference on GSoC and free software related topics. We all look forward to reporting from California on Planet and soc-coordination@l.a.d.o! All of our students had a wonderful experience, even if they couldn t come to DebConf, that is best shared in their own voice, so without further ado, our successful projects: Multi-Arch support in APT by David Kalnischkies, mentored by Michael Vogt apt-get install MultiArch does mostly work now as most code is already merged in squeeze, but if not complain about us at deity@l.d.o! Still, a lot left on the todo list not only in APT so let us all add MultiArch again to the Release Goals and work hard on squeezing it into wheezy.

Debbugs Bug Reporting and Manipulation API by David Wendt Jr., mentored by Bastian Venthur Hello, I m David Wendt, and I went to Debconf10 to learn more about the development side of Debian. Having used it since the 9th grade, I ve been intimately familiar with many of Debian s internals. However, I wanted to see the developers and other Debian users. At DebConf, I was able to see a variety of talks from Debian and Ubuntu developers. I also got to meet with my mentor as well as the maintainer of Debbugs. Content-aware Config Files Upgrading by Krzysztof Tyszecki, mentored by Dominique Dumont Config::Model is now capable of manipulating files using shorter and easier to write models. Thanks to that, packagers may start experiment with creating upgrade models. Further work is needed to support more complicated config files Dominique Dumont is working on DEP-5 parser, I ll shortly start working on a cupsd config file parser.
The best thing about DebConf10 is that every person I talked with knew what I was doing. I had a mission to get some feedback on my project. Everybody liked the idea of making upgrades less cumbersome. On the other side, it was my first visit to United States, so I decided to go on a daytrip on my own (instead of staying inside the building, despite heat warnings). I had a chance to visit many interesting places like Ground Zero, the UN headquarters, Grand Central Terminal, Times square and Rockefeller Center that was a great experience. Hurd port and de-Linux-ization of Debian-Installer by J r mie Koenig, mentored by Samuel Thibault Debconf10 was great! Among other people working on the installer, I met Aur lien Jarno from the Debian/kFreeBSD team and we worked together on a cross-platform busybox package. Besides, the talks were very interesting and I ve filled my TODO-list for the year.
For instance I learned about the Jigsaw project of OpenJDK, and how Debian would be the ideal platform to experiment with it. More generally, some people think Debian could push Java 7 forward and I d like to see this happen. Smart Upload Server for FTP Master by Petr Jasek, mentored by Joerg Jaspert I must say that it was great time for me in NY, I ve met and talked and coded with people from ftp-master team like Torsten Werner who helped me to push the project a bit further and with some other people who were looking forward to release of the tool which I hope they will use quite soon. Everybody interested, everybody excited, really cool place and time. And I can t forget the Coney Island beach and stuff, lot of fun, lot of sun;) Aptitude Qt by Piotr Galiszewski, mentored by Sune Vuorela Currently, development branches support full features searching, viewing extended package s informations, performing cache and packages operations. Code and GUI still require a lot of work which will be continued. Informations about further progress could be found on aptitude mailing list and repository rss channel. Debian-Installer on Neo FreeRunner and Handheld Devices by Thibaut Girka, mentored by Gaudenz Steinlin For me, DebConf 10 started at the airport, where Sylvestre Ledru (whom I didn t know of before) was wearing a GSoC 2007 t-shirt, that is, given the circumstances, almost equivalent to say I m a hacker, I m going to DebConf 10 .
I ve spent my time at the conference attending various talks, hacking, meeting DDs and other hackers (amongst others, my co-mentor Per Andersson, Paul Wise, Julien Cristau, Christian Perrier, Cyril Brulebois, Martin Michlmayr, Colin Watson and Otavio Salvadores who I have to thank for his patience while dealing with my questions), chatting, cross-signing keys, rushing to finish eating before 7pm, getting sunburnt, sightseeing (thanks, Arthur, for the lightning-fast tour of Manhattan!), and so on. Debian Developers and community, we count on you. See you next year! (cross-posted to debian-devel-announce@l.d.o and soc-coordination@l.a.d.o)

Next.

Previous.