![[Photo gallery]](/staff/tp/icons/ico_gallery.png){kind=icon}
Gpsbabel does not work at all in brand new fedora 15.
I have followed
suggestions from
https://bugzilla.redhat.com/show_bug.cgi?id=713483
and rebuild it from the source .rpm. I have also
fixed udev rules, as described
here:
![[Zdjęcie T. Przechlewskiego]](/personal/rysunki/home-icon.jpg){kind=icon}
## /etc/udev/rules.d/51-garmin.rules
SYSFS{idVendor}=="091e", SYSFS{idProduct}=="0003", MODE="0666"
Now (sometimes) I was able to fetch GPX trace but only as a root.
Inspecting /var/log/messages I noticed suspicious
messages from
gpsd daemon, ie:
Aug 14 16:50:09 darkstar gpsd.hotplug: gpsd_control(action=add,arg=/dev/ttyUSB0)
Moreover the deamon starts/stops in some tricky way as it is down
if one looks in Programs →Administration→Services, but
ps uax | grep gpsd indicates something contrary:
nobody 2530 0.0 0.0 12652 1412 ? S<s 13:31 0:00 gpsd -n -F /var/run/gpsd.sock
As gpsbabel works flawlessly
in my fc11 w/o gpsd I have decided to remove it:
yum erase gpsd ## removes also following dependencies: kdeutils-libs-4.6.5-2.fc15.i686 kdeutils-4.6.5-2.fc15.i686 kde-settings-kdm-4.6-10.fc15.noarch kdm-4.6.5-2.fc15.i686 digikam-1.9.0-2.fc15.i686 digikam-libs-1.9.0-2.fc15.i686 kdeedu-marble-4.6.5-1.fc15.i686 kdeedu-marble-libs-4.6.5-1.fc15.i686 kdeplasma-addons-4.6.5-1.fc15.i686 kdeplasma-addons-libs-4.6.5-1.fc15.i686 ktorrent-4.1.1-1.fc15.i686 ktorrent-libs-4.1.1-1.fc15.i686 kpackagekit-0.6.3.3-2.fc15.i686 kde-plasma-networkmanagement-vpnc-0.9-0.53.20110616git.nm09.fc15.i686 kde-plasma-networkmanagement-openvpn-0.9-0.53.20110616git.nm09.fc15.i686 plasma-scriptengine-python-4.6.5-2.fc15.i686 kdenetwork-4.6.5-1.fc15.i686 kdenetwork-libs-4.6.5-1.fc15.i686 kde-plasma-networkmanagement-pptp-0.9-0.53.20110616git.nm09.fc15.i686 kde-plasma-networkmanagement-0.9-0.53.20110616git.nm09.fc15.i686 kde-plasma-networkmanagement-libs-0.9-0.53.20110616git.nm09.fc15.i686 kdebase-workspace-4.6.5-2.fc15.i686 kdebase-workspace-libs-4.6.5-2.fc15.i686 gpsd-2.95-6.fc15.i686 ## and disables the following udev rules: ostrzeżenie: /etc/udev/rules.d/99-gpsd.rules zapisano jako /etc/udev/rules.d/99-gpsd.rules.rpmsave
Pretty surprising that so many KDE packages depends on gpsd!
Now I have access to gpsbabel as normal user.
(It needs 10--20 second to plug
the device in fc15 while in fc11 it was instantaneously.)
Moreover my Gnome3 desktop once unusable looks much better (I still intend to use Xfce however). It seems KDE in FC15 interfere in a nasty way...
Added 24 august 2011:
Xine error while playing .avi file resolved.
$ rpm -qa '*ffmpeg*' ffmpeg-devel-0.7-0.3.20110612git.fc15.i686 ffmpeg-libs-0.7-0.3.20110612git.fc15.i686 $ rpm remove ffmpeg-devel $ yum downgrade ffmpeg-libs Removed: ffmpeg-libs.i686 0:0.7-0.3.20110612git.fc15 Installed: ffmpeg-libs.i686 0:0.6.90-0.2.rc0.fc15
xine now works with .avi. Btw:
$ rpm -qa '*git*' emacs-git-el-1.7.6-1.fc15.noarch emacs-git-1.7.6-1.fc15.noarch git-1.7.6-1.fc15.i686
It appears ffmpeg-libs-0.7-0.3.20110612git
and ffmpeg-devel-0.7-0.3.20110612git
were the only compiled from git shapshots
packages installed in my system
(providing gip snapshots are always marked
by adding git to package name).
It is convenient to add exclude=ffmpeg-libs
to /etc/yum.conf to prevent
yum to update
ffmpeg libs with yum update command.
Added 31 august 2011:
According to man xine one can specify
``additional command line arguments'' using ~/.xine/xinerc where
each line specifies an additional command line argument. However
--geometry 990x650 does not work, as well as
-G 990x650.
By trial and error I have figure out the only(?) working
syntax:
##vi ~/.xine/xinerc -G990x650
Note no space after -G.
Od ręki nie działa. Próbowałem rozwiązać problem instalując następujące pakiety:
yum install gphoto2 gvfs-gphoto2 gtkam digikam gthumb geeqie
Geeqie to zamiennik gqview,
które używałem do tej pory.
DigiKam nie działa (gryzie się z XFce).
Wydaje mi się, że większość tego
co zainstalowałem
nie jest potrzebna -- istotne jest geeqie,
dzięki któremu mogę wygodnie
zaimportować zdjęcia
z aparatu na komputer (lądują w katalogu ~/Pictures).
Prawie działa. Problem stanowią słowa kluczowe zawierające
polskie znaczki. Trzeba nieco zmodyfikować skrypty generujące
bazę słów kluczowych tj. flickr_getalltags, i inne.
Cała procedura odświeżania tagów i innych metadanych jest
uruchamiana skryptem flickr_update_kb, który
w uproszczeniu wygląda następująco:
#!/bin/bash # Get list of public photos with 'flickr.people.getPublicPhotos flickr_getphotolist.pl -u hr.icio # Refreshing information on tags/sets/geolocs" # Get information on sets defined by the user: flickr_getsets && \ # Get tags from flickr for current user flickr_getalltags && \ # Get information on groups to which one can add photos flickr_getgroups && \ ## For flickr_xml2el we need _special treatment_ otherwise UTF is spoiled PERL_UNICODE=S flickr_xml2el > ~/.flickr/hr.icio.el cd ~/.knows && make 2flicker && \ cd ~/.flickr && make check
Z nieustalonych powodów cześć komunikatu zwracana przez flickra
jest teraz kompresowana (a nie była -- nowsza wersja pakietu Perla?).
Z tego też powodu konstrukcja (ze
skryptu flickr_getalltags.pl -- w innych skryptach
podobnie):
my $xm = $xmlp->XMLin($response->{_content}, forcearray=>[raw]);
została zamieniona na:
## zmienione 15.08.2011 (gzip as content-encoding)
## ustalenie w jakim `content_encoding' jest _content
my $content_encoding = $response->{_headers}->{'content-encoding'} ;
my $plain_content;
if ($content_encoding =~ /gzip/ ) {## jeżeli gzip to odpakować:
$plain_content = Compress::Zlib::memGunzip( $response->{_content});
} else { $plain_content = $response->{_content}; }
Powyższe załatwia problem z (nie) działaniem skryptów
flickr_getphotolist.pl,
flickr_getsets,
flickr_getalltags,
flickr_getgroups.
Konwersja plików XML do formatu Emacsa
za pomocą skryptu flickr_xml2el daje w rezultacie las
komunikatów Wide character in print at... a plik wynikowy jest
błędnie kodowany. Problem ciągle wraca a ja ciągle nie wiem czemu.
Zaślepkowo pomogło
dodanie PERL_UNICODE=S (zaklęcie to należy wstawić
w odpowiednie miejsce
także do pliku Make w katalogu ~/.knows).
Po tych wszystkich ww. zabiegach (które zajęły mi pół dnia) jestem w stanie odświeżyć bazę metadanych z mojego konta na flickr.com. Sukces:-)
Przejście z FC8 na FC15 rozpoczęło się od wymiany starego dysku (250Gb) na WDC EADS 1Tb (Green Power). Już na początku się zdarzył falstart, bo zarówno BIOS jak i Linux utrzymywał uparcie, iż dysk ma pojemność ok. 33Mb. Nie wchodząc w szczegóły problem powoduje błąd w BIOSie (starych) płyt Gibabyte (cf. WD10 EADS problem ..from 1TB to 31MB). The reason the drive is reporting 33MB is that Gigabyte's BIOS has a bug that incorrectly adjusts the drive's capacity after creating the HPA. 1TB drives are reduced to 33MB, 1.5TB become 500GB, and 2TB become 1TB. (cf. Lost Partition on Hitachi...).
Więcej na temat można się dowiedzieć wpisując w Google
HDA+Gigabyte i/lub ze strony Wikipedii.
Aby przywrócić ,,fabryczną'' pojemność postąpiłem wg. zalecenia:
The solution is to use a tool such as HDAT2 or the HDD Capacity Restore Tool
to remove the HPA (Host Protected Area),
tyle że zamiast HDAT2/HDDCRT użyłem poczciwego hdparm.
## Potrzebny jest hdparm > 8.0 cf http://en.wikipedia.org/wiki/Host_protected_area ## w zapisie p1953525168 litera `p' jest OK i oznacza `permanent' [root@darkstar]#hdparm -N p1953525168 /dev/sdb /dev/sdb: setting max visible sectors to 1953525168 (permanent) max sectors = 1953525168/1953525168, HPA is disabled [root@darkstar]#hdparm -N /dev/sdb /dev/sdb: max sectors = 1953525168/1953525168, HPA is disabled
Teraz podzieliłem dysk na partycje używając gparted:
/ (ok. 50Gb),
/swap (ok. 2Gb),
/boot (ok. 500Mb),
/home (ok. 750Gb). Zainstalowałem FC15 używając do tego
obrazu Fedora-15-i686-Live-Desktop
ze strony http://torrent.fedoraproject.org/. Instalacja zakończyła się dziwnym
błędem, objawiającym się tym,
że partycja / miała 50Gb według np. fdiska,
a 2,5Gb tak w ogóle i na prawdę.
W drugiej próbie podział na partycje został wykonany przez instalator i wtedy było dobrze.
Czemu było źle za pierwszym razem nie wiadomo...
Z jakiś powodów Fedora gadała do mnie po angielsku (Założyłbym się, że w czasie instalacji
nikt mnie się nie pytał czy chcę po angielsku czy nie...) Zmieniłem to wpisując do
/etc/sysconfig/i18n:
##LANG="en_US.UTF-8" ## tak było po instalacji LANG="pl_PL.UTF-8" SYSFONT="latarcyrheb-sun16"
Jednym słowem zamierzam przejść na Unicode (do tej pory używałem ISO-8859-2). Kompatybilność
wstecz gwarantuje mi Emacs, w którym redaguję moje dokumenty/pliku tekstowe.
Dla przypomnienia następujące zaklęcia
gwarantują, że Emacs przełączy się na właściwe kodowanie:
% -*- coding: iso-8859-2 -*- tra-ta-tata % Local Variables: % coding: iso-8859-2 % ispell-local-dictionary: "polish" % End:
Zaklęcie % -*- coding: iso-8859-2 -*- musi być w pierwszym wierszu. Wpisy
Local Variables: ... End: na końcu pliku.
Do przestawienia kodowania wystarczy albo wpis w pierwszym wierszu albo
Local Variables:. Można zastosować też oba na raz -- nie będzie błędu.
Po kilkugodzinnej walce z Gnome 3 zmieniłem go na Xfce. Szkoda czasu na deliberowanie, w jaki sposób zdefiniować tak elementarne rzeczy, jak przykładowo skrót do programu (Nb. sposoby podane np. tu albo tu u mnie nie działają.)
Fundamentalna dla mnie aplikacja, a mianowicie gpsbabel nie działa. Na szczęście,
ktoś już z tym walczył przede mną
(cf. libusb-config missing from libusb-devel):
## Gpsbabel w fc15 jest `broken' trzeba go skompilować: wget http://mirrors.xmission.com/fedora/updates/15/SRPMS/gpsbabel-1.4.2-6.fc15.src.rpm ## bo nie bo w http://download.fedoraproject.org/pub/fedora/linux/releases/15/ rpm -ivh gpsbabel-1.4.2-6.fc15.src.rpm ## się rozpakował w /root/rpmbuild/ yum install rpm-build rpm-build-libs rpmbuild -ba /root/rpmbuild/SPECS/gpsbabel.spec # tam się rozpakował SPEC rpm -Uvh /root/rpmbuild/RPMS/i386/gpsbabel-* ## zgłaszany jest konflikt zatem rpm -e gpsbabel rpm -Uvh /root/rpmbuild/RPMS/i386/gpsbabel-* ## ## Poniższe jest potrzebne do moich skryptów obsługujących ściąganie śladu z Legenda: wget http://search.cpan.org/CPAN/authors/id/B/BL/BLUEFEET/Geo-Distance-0.17.tar.gz tar -zxvf Geo-Distance-0.17.tar.gz && cd Geo-Distance-0.17 perl Makefile.PL && make && make install
Niestety coś się zmieniło
i magiczne zaklęcie (wpisane do /etc/udev/rules.d/51-garmin.rules)
działające w poprzednich fedorach:
SYSFS{idVendor}=="091e", SYSFS{idProduct}=="0003", MODE="0666"
przestało działać. Na razie odpuszczam i będę ściągał ślady jako root; z czasem się dowiem jak problem pokonać.
Instalowanie Googleearth też nie okazało się oczywiste:
wget http://dl.google.com/earth/client/current/GoogleEarthLinux.bin sh ./GoogleEarthLinux.bin ## się wysypało z błędem, przy czym ## skrypt pyszczył, że mu brakuje LSB yum install redhat-lsb redhat-lsb-graphics ## dalej się wysypuje. Ale znalazłem via google co robić: ./GoogleEarthLinux.bin --target /tmp/ge ## kończy się błędem ale idziemy dalej:-) cd /tmp/ge/setup.data/bin/Linux/x86/ mv setup.gtk setup.gtk2 cd /tmp/ge ## poniższe polecenie jako `root' oczywiście: ./setup.sh
Na razie tyle... Da się tego używać, ale z ostateczną oceną się na razie wstrzymuję -- zobaczymy co jeszcze zostało spartolone...
Dopisane 15 sierpnia 2011:
Dopisałem do .emacs polecenia, które mają powodować, że
pliki TeXa oraz pliki w formacie Blosxoma są domyślnie redagowane
w Emacsie w kodowaniu jednobajtowym:
(modify-coding-system-alist 'file "\\.blx\\'" 'iso-8859-2) (modify-coding-system-alist 'file "\\.tex\\'" 'iso-8859-2)
Zastanawiam się też nad dodaniem czegoś takiego (najpierw wypróbuję czy na pewno działa):
(modify-coding-system-alist 'process "svn" 'iso-8859-2)
Dopisane 18 sierpnia 2011:
Pobieranie zrzutu ekranu. W gnome
jest do tego gnome-screenshot a w Xfce
-- xfce4-screenshooter (cf. http://goodies.xfce.org/projects/applications/xfmpc).
Program gnome-screenshot
(uruchamiany jako gnome-screenshot --interactive)
działa ,,nieintuicyjnie'' przy wybraniu zrzutu z okna, xfce4-screenshooter działa lepiej
Dopisane 21 sierpnia 2011:
Avatary w ekranie logowania (gdm).
W internecie są sprzeczne
informacje na ten temat.
Niektórzy twierdzą, że się nie da. W rzeczy samej sposób
najprostszy, a polegający na umieszczeniu stosownej ikony w postaci pliku o nazwie
.face w katalogu domowym użytkownika nie działa, ale działa
umieszczenie tegoż pliku (niekoniecznie nazywającego się .face tym razem)
do katalogu /var/lib/AccountsService/icons/ oraz dodanie
do każdego pliku z katalogu /var/lib/AccountsService/users/
wpisu:
Icon=/var/lib/AccountsService/icons/nazwa_pliku_zaw_avatara
Por. https://bugzilla.redhat.com/show_bug.cgi?id=705240.
Dopisane 26 sierpnia 2011:
Konfigurowanie drukarki (system-config-printer). Zalecany
sterownik
pn. HP LaserJet 6P Cups+ Gutenprint v.5.2.7 simplified [en]
czasami nie działa (np. plik .ps generowany przez
pstops
drukuje ohydnymi fontami bitmapowymi o niskiej rozdzielczości).
Pomaga przestawienie na sterownik
pn. HP LaserJet 6P Foomatic/ljet4.
Dodałem też syntax off do ~/.vimrc ponieważ
kolorowane pliki były skrajnie nieczytelne.
Prywatne pakiety R, takie jak Rcmdr
będę instalował w katalogu R_LIBS=$HOME/R. Odpowiedni
wpis dodałem zatem do ~/.bash_profile.