I had talk about Gammu and Wammu this weekend on LinuxAlt. Video should be online on conference website after some time, but my presentation and text is available right now. You can find it in new section talks. I will have to solve navigation later :-).
I'm using more and more version control systems and I'm more and more often mistaken which commands to use in which project. At work we still have CVS, for kernel it is git (or cogito), for phpMyAdmin we switched to subversion, for my old projects it is bazaar and for new projects I use bazaar-ng.
And not, my brain can not switch context fast enought to remember that
in this repository I need
svn up and in another one
I doubt that I'm only one with such problem and hopefully somebody already wrote some meta version control interface, which would correctly detect which beast is current directory using, and invoke appripriate command for wanted action. However Googling didn't find anything like that, but hopefully I'm only using bad query. Anybody has seen such tool?
We have two releases today - one fixes security bug in stable branch (188.8.131.52) and one to fix several bugs (2.9.1-rc2). Final 2.9.1 should follow soon if no major problem appears.
I also added MAINT_2_9_1 branch to snapshots and demo server, feel free to use them.
New month has come and thus there is new upstream release of stardict-english-czech package. While preparing upload for my sponsor, I decided to go also through rest of my packages. Wammu is for quite long waiting for my sponsor, so I pinged him. nanoblogger has some open bugs, so I fixed them and sent package to sponsor. And last but not least I sent ping to debian-mentors about sponsoring sonata, which is really cool application and I'd love to see it in next Debian release. However this target seems to be quite far away as nobody was attracted by it up to now.
It happens too often in recent program releases - I do a release and few moments after it I notice some quite important bug. Today it is deadlock in upgrading in Ukolovnik. I should have seen it before (as I fixed simmilar problem for another part of config layer), but I haven't.
I'll wait for some time if something else appears and then make another new release. You can meanwhile apply patch from the bug manually or use daily snapshot.
I just got new LCD at work - Acer AL1916W. I thought it will be much easier to setup than it actually was.
First attempt was only to add "1440x900" to modes in X.org configuration. It failed as well when I added modeline for this mode. After some Googling I found that for my stupid onboard card - i945 - I need to do some voodoo with it's BIOS to make it work.
Fortunately there is tool 915resolution which does this black magic, so it was not that complicated at the end:
# aptitude install 915resolution
It complains that it can not detect display, so I had to modify
MODE=5c XRESO=1440 YRESO=900
After starting 915resolution init script, you should be now able to start X.org server with following configuration (kept only relevant parts):
Section "Monitor" Identifier "Acer AL1916W" Option "DPMS" HorizSync 30-82 VertRefresh 56-76 DisplaySize 410 260 Modeline "1440x900" 136.0 1440 1520 1672 1904 900 903 909 934 +hsync +vsync EndSection Section "Screen" Identifier "Default Screen" Device "Intel i945" Monitor "Acer AL1916W" DefaultDepth 24 SubSection "Display" Depth 24 Virtual 1440 900 Modes "1440x900" "1400x1050" "1280x1024" "1280x960" "1152x864" "1024x768" "800x600" "640x480" EndSubSection EndSection
And finally I can use widescreen display!
As DocSQL import in phpMyAdmin was quite old and obscure code, I decided to convert it to regullar input plugin. This is now done in SVN, however there is one slight problem - I have only fuzzy idea what DocSQL actually is and I don't have any data to test it (besides those I could guess from plugin source). So I'd welcome if somebody who knows this beast, would give new plugin a bit of testing.
This has already happen yesterday, but I decided to announce it today, because now there is snapshot with all those changes.
With Subversion we can rename files without losing their histrory and
this possibility lead to huge cleanup of file names. I dropped all
_properties parts of table and database pages. As user
you should not notice anything (except for different URL), but there
might be still some problematic parts which has not been detected when I
did this change.