Posts tagged ‘debian’
epilicious.dev repo now has changes adding support for ma.gnolia. The configuration dialogue is modified to allow changing between the two supported backends.
Furthermore my APT repo holds an updated version of
epiphany-extension-epilicious-pre that can be installed alongside the GNOME version of epilicious that comes in
epiphany-extensions. That is, it can be used with Epiphany 2.18 from Debian experimental.
As always, comments and bug report are more than welcome.
I couldn’t find any information on how to set up darcsweb on lighttpd in general. I was a little disappointed to see that the darcsweb package on Debian only comes with apache and apache2 configurations, nothing for lighttpd. Since Debian is a little special sometimes when it comes to web servers—they like to add convenient configuration “frameworks”—I was afraid that using a “non-supported web server” might be a lot of work. How wrong I was
First enable the CGI module for lighttpd:
# cd /etc/lightttpd/conf-enabled # ln -s ../conf-evailable/10-cgi.conf
Then create a very short configuration file to enable darcsweb to find its images:
# cd # echo 'alias.url += ( "/darcsweb/" => "/usr/share/darcsweb/" )' > \ /etc/lighttpd/conf-available/50-darcsweb.conf
Then enable that “module” as well:
# cd /etc/lightttpd/conf-enabled # ln -s ../conf-evailable/50-darcsweb.conf
Create your darcs repositories in
/var/www/darcs/. I created a repo I called
The Debian default configuration of darcsweb will expose all repositories in
/var/www/darcs/. This is quite probably not what I wanted so I commented out the
auto class and added the following:
class test: reponame = 'test' repodesc = 'Silly little test repo' repodir = '/var/www/darcs/test' repourl = 'http://denobula/darcs/test/' repoencoding = 'latin1'
I received a note about the new Firefox vulnerability yesterday. I ran the proof-of-concept on my Debian machine, using first Epiphany and then Iceweasel. Didn’t work on either. Then I fired up a VMWare image running Windows, with a stock Firefox from mozilla. The proof-of-concept worked just as advertised. So, are the reports missing something (not exploitable on all OSs), or am I just lucky that Debian decided to move to Iceweasel?
It’s been hard to avoid the whole Dunc-Tank debacle that’s been going on in Debian for a while now. I can’t say I care a whole lot, but after reading the position statement posted by a few DDs I got to thinking.
At about the time of Warty Warthog I jumped on the Ubuntu band wagon. I had been using Debian for a few years already. Becoming a DD was something I thought was worth persuing, but it was hard work. I didn’t even find anyone to upload my packages. Disappointment struck and I jumped ship. In Ubuntu I found a new community, a community that was growing and actively supported people who were interested in contributing. Due to circumstances I couldn’t put in as much work as I wanted and I still had that nagging feeling that to really contribute, even to Ubuntu, I needed to contribute to Debian. After all Ubuntu is a fork of Debian. There was also a kind of built-in inequality in Ubuntu. There were first-rate citizens and second-rate citizens. First-rate citizens were employed by Canonical. In the end my Ubuntu days ended during Breezy and I went back to Debian. There were several reasons for my switch back, but one was that in Debian everyone is equal. You can go as far as you want in Debian, you just have to put in the work. It is a meritocracy.
So, where do my thoughts on DT come? Well, here it is; DT threatens that equality. Debian runs the risk of becoming a project with tiered membership. Luckily the members are vocal, opinionated, and not afraid of using their MUAs. I still have trust in Debian. We live and we learn.
The basic idea of DT (paying people to work on Debian) isn’t all bad but maybe they should have let the DDs elect who gets paid to work on Debian? Or maybe it should be run similar to Google’s summer of code, with project proposals and DDs electing projects worth investing in?
In the end, what do I know? I’m not even a DD.
This wasn’t a serious mistake and the only reason it took a while to sort out was my amazing thickness.
I had removed
pciutils (and thereby
lspci) from the system thinking that “now everything works, so I won’t ever need it again”. Just to show me the error of my ways the benevolent Debian decided to punish me by not giving me network. It turned out that Linux’ excellent support for a multitude of network cards worked against me on this one—which one to insert? After several uninspired thoughts I had an inspired one. Brute force! Insert them all!
# cd /lib/modules/2.6.17-2-686/kernel/drivers/net # for f in *.ko; do insmod $f; done
A few error messages later I tried
ifup eth0, and it worked Quick download of
pciutils. Now I know the machine in question requires
eepro100 to get network. I recorded that in
At the moment I’m having a hard time resisting removing
pciutils. I mean, now everything works, I won’t ever need it again, right?
I just noticed that epilicious doesn’t work for me It seems the recent work done by the Python group in Debian Sid has resulted in the following line throwing an exception:
from elementtree.ElementTree import parse
Yes, I’ve double checked that python-elementtree is installed (python-celementtree is also installed). At the moment I’m too lazy to look into it myself and I’ve sent off an email to the Debian user list.