Last week we released Wheezy, roughly two years after our last release Squeeze.
I’d like to thank all the contributors in- and outside of Debian for your fine work! Every single contribution — no matter how big or small — summed up to the wonderful release we finished last week. Without you this release would not have been possible. Keep up the good work guys and make Jessie rock even harder!
PS: It is very nice to see once again fresh packages rolling into unstable and spending some time fixing broken dependencies
So I got an iPod Nano (6th generation) for Christmas this year, just in time since my trusty old iPod Mini started beg for retirement after almost 8 years of usage.
Since my old iPod was working like a charm all those years I expected a smooth sailing when I plugged in my new iPod Nano. Gnome recognized it correctly and mounted the device. The iPod showed up in Rhythmbox as I was used to and I started to fill it with some music. Everything worked as expected: Rhythmbox copied the music to the iPod without complaining and after unmounting the iPod and starting it — it was emtpy. Whait, what? Why is it empty? Didn’t I just… So I tried again, and again with the same result.
Half an hour later I found out that libgpod (the iPod “driver” for Linux) supports all iPods except the iPod Nano 6G. Bummer. Apparently Apple changed the algorithm to calculate the checksums of the files on the device and since that algorithm is unknown you cannot successfully write on it with free software.
That means technically this device is unusable for Linux users since iTunes doesn’t run on Linux. However, there seems to be a way to use the iPod Nano with libgpod if you are trusting this guy and willing to use his binary (only!) file with libgpod (which I am not). And somehow the guys over at Spotify managed to get the iPod Nano running in their Linux client but they don’t provide the code either.
Being already more than two years old, I don’t have much hope that the iPod Nano will work on Linux with libgpod in the foreseeable future. On the bright side I can say the device is not totally useless as it comes with FM radio…
19 Years and still rocking! Huge thanks to all contributors for making this happen and a happy birthday Debian!
I’m looking for a good graphics tablet. I’ll mainly use it for post processing DSLR photos with Raw Therapee, Bibble, and Gimp. It should be cheaper than 200 EUR and must work with Debian/Sid (of course). I’d rather not have to install any fancy drivers, it should work out of the box.
A few days ago I found this blog explaining how to improve the tab completion by tinkering with your .inputrc.
The magic lines are:
set show-all-if-ambiguous on
set completion-ignore-case on
set completion-map-case on
Last two lines make tab-completion ignore case, hyphens, underscores, the first one spares you one tab when more than one match was found. Very neat! I would have never found out, since there wasn’t even an .inputrc in my home directory.
Do you know any other cool .inputrc-tricks?
is it possible to tell aptitude to show older versions of a package next to the currently available one if it is still present in
/var/cache/apt/archives? Like it does when you use unstable and experimental side by side? I know that aptitude does not really support downgrades of packages, but showing those packages directly in aptitude if available in the cache is a lot easier than searching them in the file system and installing them manually, especially if you don’t know where they hide.
Note to self:
when configuring awstats using lighttpd logfiles, you have to use the following log format:
LogFormat="%host %virtualname %logname %time1 %methodurl %code %bytesd %refererquot %uaquot"
neighter 1 nor 4 will work correctly.
Every other year or so I feel the need to clean up my Debian system and remove the installed packages I’m not interested in anymore. I remember there was a nice aptitude pattern to search for packages which I have manually installed (i.e. which were not installed to satisfy a dependency). Ideally I would then go through the (presumably short) list of packages and remove the ones I don’t need any more.
Since I always forget the aptitude pattern to search for those packages, I google for something like “list of manually installed packages” and find a solution like:
aptitude search ‘~i !~M’. Although this solution is not wrong, it is not quite what I was looking for. Sure, it will find you all packages which are installed and not installed to satisfy a dependency, but it also contains packages of priorities: required, important and standard which you usually don’t want to deinstall. So the actual solution should also exclude those packages.
aptitude search '~i !~M !~pstandard !~pimportant !~prequired'
The above line will do the trick and present you a list of packages which are: installed and not dragged in to satisfy a dependency and not of priority standard, important or required.
If you where only interested in the solution of the quest of getting a list of all manually installed packages you can stop reading here.
If you’re running your system for longer than, say, a few weeks you will probably notice that the list is very long and contains much more packages than you actually installed manually. You will probably notice a lot of libs and other packages in this list and wonder why they aren’t marked
auto as they should since you didn’t install them on purpose. Unfortunately I don’t have an answer for that question. I’m using aptitude exclusively to install packages and rely on the fact that aptitude does install the dependencies automatically and more importantly: also removes them if not needed any more. But it seems like something is broken in aptitude (or somewhere else) and packages simply lose their
auto status instead of being removed and thus stay on your system forever if you don’t manually clean your system.
To solve that issue I started aptitude and filtered the package tree with the above pattern (press
l in aptitude and enter
~i !~M !~pstandard !~pimportant !~prequired). Now the package view shows only packages which are safe to remove since they are not of of priority standard or higher and manually installed by you. Now I navigate with the cursor to the list of installed packages an mark all of them as
auto by pressing
M. For each package in this list, aptitude will try to find an installed package which depends on that package and mark that package
auto. The remaining packages which no other packages depend on, aptitude will mark for deletion. If you now press
g one time, aptitude will show you which packages will be removed. I then go through that list and mark every single of the remaining packages I really want on my system with
+ as manually installed. After I’m done I proceed by pressing
g again which will remove all remaining packages. In my case nearly 600 packages (1GB) where removed.
I assume there is a bug in aptitude or some related package which sometimes(!) removes a packages
auto status instead of removing it. Unfortunately I did not find a way to reproduce that (except that it obviously does happen). If someone could find a way to reproduce that problem, one could fill a bugreport and help to get that bug fixed. Right now, a Debian system suffers (like many other operating systems) from a slow but steadily growing bloat of installed software. In my case 600 packages with 1GB accumulated over one or two years.
I recently switched from KDE to Gnome 3 and I am so far very happy with the decision. One thing that bothers me since then is that the sound does not work when restarting the computer or waking it up from suspend. After a while I figured that a simple
sudo killall pulseaudio fixes the problem — but only until the next reboot. Has anyone a hint what the problem could be/ I found quite a few similar problem descriptions on the internet but with no satisfying solutions so far.
since KDE4 is in unstable, the taskbar behaves very annoyingly when working with two monitors with different resolutions. I have a laptop. When I’m at work, I put it into a docking station which is connected to a huge monitor. I’m not working with dualhead or something, I’m just using the huge monitor at work and the laptop’s screen at home.
I always want the taskbar to be maximized. The problem is, that KDE’s taskbar fails to adjust the size of the taskbar correctly: Starting KDE at work, the taskbar is always too small (as wide as the laptop’s monitor) and my first task is to maximize the taskbar. Starting KDE when I’m back home, the taskbar is too wide (as wide as the external monitor’s size) for the smaller monitor and I have to (ironically) maximize it again to fit on the now smaller monitor.
Note that I’m not using suspend or something. I’m booting the laptop with the big screen connected or not.
I also had that problem with KDE3, but that was fixed upstream long time ago. Has anyone a solution how to avoid this problem?