środa, 23 grudnia 2015

Otter-Browser wydanie tygodniowe #103

Powoli, bo powoli ale Otter-Browser zbliża się do swego pierwszego wydania stabilnego. Dzisiejsza wersja tygodniowa #103 przypomina, że mijają już dwa lata od początku tego projektu. Od dłuższego czasu kibicuję mu na tyle na ile potrafię, czyli prezentuję skrypty umożliwiające budowę  wersji tygodniowych dla Archa (i pochodnych). Wersje PKGBUILDu mamy dwie: jedna umożliwia budowę z wykorzystaniem QtWebKit, druga na QtWebEngine. Pewnie ta druga stanie się  wyłączną, albowiem i tak umożliwia pracę z QtWebKit, jeśli jest ona zainstalowana w systemie.
W celu instalacji trzeba wybrać jeden z PKGBUILDów prezentowanych poniżej oraz plik otter-browser.install. Dalsza procedura jest standardowa.
PKGBUILD umożliwiający budowę z wykorzystaniem QtWebKit:
# Maintainer: boenki <boenki at gmx dot de>
# Maintainer: pavbaranov
# Contributor: sir_lucjan
# Full pkgname # Do no edit below this line unless you know what you're doing
_pkgver=0.9.09
_weekver=103
_pkgname=otter-browser-webkit-weekly
################################################
pkgname=$_pkgname
__pkgname=otter-browser
pkgver=$_pkgver.$_weekver
pkgrel=1
pkgdesc="Browser aiming to recreate classic Opera (12.x) UI using Qt5 - qtwebkit version."
arch=('i686' 'x86_64')
url="http://$pkgname.org"
license=('GPL3')
depends=('qt5-webkit' 'qt5-script' 'qt5-multimedia' 'hicolor-icon-theme' 'desktop-file-utils')
makedepends=('cmake' 'qt5-tools')
conflicts=('otter-browser-git' 'otter-browser' 'otter-browser-0.9.*' 'otter-browser-beta*')
provides=('otter-browser*')
install=otter-browser.install
source=("http://sourceforge.net/projects/otter-browser/files/otter-browser-weekly${_weekver}/otter-browser-${_pkgver}-dev${_weekver}.tar.bz2")
md5sums=('6b7a2ff7b1608338853f77da7c3ba88a')
build() {
  cd ${__pkgname}-${_pkgver}-dev${_weekver}
  lrelease resources/translations/*.ts
  cmake -DCMAKE_INSTALL_PREFIX="/usr"
  make
}
package() {
  cd ${__pkgname}-${_pkgver}-dev${_weekver}
  make DESTDIR=$pkgdir install
}
PKGBUILD dla wersji opartej o QtWebEngine:
# Maintainer: boenki <boenki at gmx dot de>
# Maintainer: pavbaranov
# Contributor: sir_lucjan

# Full pkgname # Do no edit below this line unless you know what you're doing

_pkgver=0.9.09
_weekver=103
_pkgname=otter-browser-webengine-weekly

################################################

pkgname=$_pkgname
__pkgname=otter-browser
pkgver=$_pkgver.$_weekver
weekver=$_weekver
pkgrel=1
pkgdesc="Browser aiming to recreate classic Opera (12.x) UI using Qt5 - qtwebengine version."
arch=('i686' 'x86_64')
url="http://$pkgname.org"
license=('GPL3')
depends=('qt5-webengine>=5.5' 'qt5-script>=5.5' 'qt5-multimedia>=5.5' 'hicolor-icon-theme' 'desktop-file-utils')
makedepends=('cmake' 'qt5-tools>=5.5')
conflicts=('otter-browser-git' 'otter-browser' 'otter-browser*' 'otter-browser-beta*')
install=otter-browser.install
source=("http://sourceforge.net/projects/otter-browser/files/otter-browser-weekly${_weekver}/otter-browser-${_pkgver}-dev${_weekver}.tar.bz2") 
md5sums=('6b7a2ff7b1608338853f77da7c3ba88a')

build() {
  cd ${__pkgname}-${_pkgver}-dev${_weekver}
  lrelease resources/translations/*.ts
  cmake -DCMAKE_INSTALL_PREFIX="/usr" \
-DEnableQtwebengine=ON
  make
}

package() {
  cd ${__pkgname}-${_pkgver}-dev${_weekver}
  make DESTDIR=$pkgdir install
}
Plik otter-browser.install:
post_install() {
  update-desktop-database -q
  update-mime-database usr/share/mime > /dev/null
  gtk-update-icon-cache -q -t -f /usr/share/icons/hicolor
}

post_upgrade() {
  post_install
}

post_remove() {
  post_install
}
 Cała reszta opisu instalacji i konfiguracji dostępna jest już na moim blogu.

ClamAV-GUI - nakładka na clamav i freshclam w Qt

Od jakiegoś czasu udostępniam skrypty umożliwiające budowę aplikacji ClamAV-GUI, która jest dość wygodną w obsłudze nakładką na clamav oraz freshclam. Obecna wersja 0.4 doczekała się właśnie niewielkiej poprawki znalezionych błędów. Dodano również nowe tłumaczenia. A propos tłumaczeń - od pewnego czasu próbuję przetłumaczyć interfejs programu, ale przyznam, że idzie mi to jak po grudzie - cóż, pewnie jak nie czuję potrzeby (rzadko używam programu a wersja angielska wystarcza mi w zupełności), to nie ma jakiegoś wewnętrznego przymusu. Obecnie przetłumaczone jest ok. 60% menu. Jeśli zatem ktoś chciałby się przyłączyć i pomóc w tym tłumaczeniu, to zapraszam.
Kod programu umożliwia kompilację z wykorzystaniem zarówno Qt4 jak i Qt5. Tak też przygotowany jest PKGBUILD, który tworzy obie wersje aplikacji. Oczywiście nie można ich obu mieć zainstalowanych w tym samym czasie, że o potrzebie takiego rozwiązania nie wspomnę. Dlatego też albo budujemy je w "tradycyjny" dla Archa sposób, potem zaś instalujemy wybrany pakiet za pomocą pacman -U nazwa_pakietu, albo już podczas budowy dokonujemy odpowiedniego wyboru i zbudowana (ewentualnie również zainstalowana) zostanie wyłącznie ta paczka, którą chcemy. Aplikacje, które są budowane na podstawie poniższych skryptów nazywają się clamav-gui-qt4 oraz clamav-gui-qt5, zatem łatwo domyślić się, która z nich używa której wersji Qt. Jeśli zatem podczas budowania zdecydowalibyście się na jeden z nich, to należy użyć komendy:
makepkg -sirc --pkg clamav-gui-qt4
lub
makepkg -sirc --pkg clamav-gui-qt5
odpowiednio dla qt4 lub qt5.
makepkg -sirc --pkg clamav-gui-qt4
PKGBUILD
# Maintainer: pavbaranov
# Contributor: marcin82

pkgbase=clamav-gui
pkgname=('clamav-gui-qt5' 'clamav-gui-qt4')
pkgver=0.4.1
pkgrel=1
pkgdesc="Qt GUI for ClamAV"
arch=("i686" "x86_64")
url="http://kde-apps.org/content/show.php/ClamAV-GUI?content=170782"
license=('GPL3')
depends=("clamav")
makedepends=("qt4" "qt5-base")
conflicts=("clamav-gui")
install=("${pkgbase}.install")
source=("http://kde-apps.org/CONTENT/content-files/170782-ClamAV-GUI-${pkgver}.tgz"
"${pkgbase}.install"
)

md5sums=('5d6989cd6847a75b7a4540ce9c19723a'
         '8be0cd5bbfd11da70b83fc63af8c81e7')

prepare() {
    mkdir -p build{-qt4,-qt5}
    }
    
build() {
    cd build-qt4
    qmake-qt4 ../ClamAV-GUI
    make 
    
    cd ../build-qt5
    qmake-qt5 ../ClamAV-GUI
    make
    }
   
package_clamav-gui-qt4() {
    depends=('clamav' 'qt4')
    conflicts=('clamav-gui-qt5')
    
    cd build-qt4
    install -Dm755 ${pkgbase} ${pkgdir}/usr/bin/${pkgbase}
    make DESTDIR="$pkgdir/" install
    }

package_clamav-gui-qt5() {
    depends=('clamav' 'qt5-base')
    conflicts=('clamav-gui-qt4')
    
    cd build-qt5
    install -Dm755 ${pkgbase} ${pkgdir}/usr/bin/${pkgbase}    
    make DESTDIR="$pkgdir/" install
    }
clamav-gui.install
post_install() {
  gtk-update-icon-cache -q -t -f usr/share/icons/hicolor
  update-desktop-database -q
}

post_upgrade() {
  post_install $1
}


post_remove() {
  post_install $1
}
 Przy okazji zwracam się do Was z pytaniem. Kod programu umożliwia jego kompilację z użyciem zarówno Qt4, jak i Qt5. Ostatnio w Archu porzucone zostało wsparcie dla KDE4, a zatem odeszło chyba ostatnie środowisko budowane z użyciem Qt4. Jest zatem jeszcze sens utrzymywania PKGBUILDu, który umożliwia budowę obu wersji?

poniedziałek, 21 grudnia 2015

Nomacs wersja rozwojowa 3.0 oparta o Qt5

Qt4 odchodzi powolutku w historię. Większość aktywnie rozwijanych programów coraz częściej opiera się o Qt5. Używanie programów opartych o Qt5 w środowiskach takich jak Plasma 5, czy LXQt ma to jeszcze tę zaletę, że niepotrzebnie nie obciąża zasobów systemowych komputera innymi, oprócz najczęściej i tak już wprowadzonych do pamięci bibliotekami. Generalnie też lepiej się integruje jeśli chodzi o wygląd.
Przeglądarka (?) graficzna [b]nomacs[/b] w Archu dostępna jest w swojej stabilnej wersji 2.4.6. Niemniej jednak od jakiegoś czasu trwają prace związane z przeniesieniem jej do Qt5. W GIT dostępna jest wersja rozwojowa 3.0. Postanowiłem przedstawić Wam możliwość jej instalacji w systemie. Oczywiście Arch Linux i pochodne (w tym Manjaro i Netrunner Rolling). Przyznam, że PKGBUILD wymaga jeszcze dopracowania, niemniej jednak aplikacja działa. Spodziewajcie się zatem erraty, która przede wszystkim bardziej prawidłowo określi numer wersji.
Obecnie proponowane skrypty budują wersję z branch 3.0.
Nie będę powtarzać jak zbudować paczkę. Wszystko jest świetnie opisane w wiki Archa. Podaję jedynie kod niezbędnych plików.
Przy budowie skryptów wykorzystałem oryginalne prace spepsa
PKGBUILD
# Maintainer: pavbaranov

pkgname=nomacs-git
_pkgname=nomacs
pkgver=r2241.1a0c4b9
pkgrel=1
pkgdesc="A Qt image viewer"
arch=(i686 x86_64)
url="http://www.nomacs.org/"
license=('GPL3')
depends=('qt5-base' 'libwebp' 'exiv2' 'libraw' 'libtiff' 'opencv')
makedepends=('cmake')
conflicts=('nomacs')
provides=('nomacs')
install="$pkgname.install"
source=("git+https://github.com/nomacs/nomacs#branch=3.0")
md5sums=('SKIP')

_pkgver() {
  cd nomacs
  printf "r%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)"
}

prepare() {
  cd $_pkgname
  [ -d b ] || mkdir build
}

build() {
  cd $_pkgname/build
  cmake ../ImageLounge -DCMAKE_INSTALL_PREFIX=/usr
  make
}

package() {
  cd $_pkgname/build
  make DESTDIR="$pkgdir/" install
}

nomacs-git.install
post_install() {
  update-desktop-database -q
}

post_upgrade() {
  post_install
}

post_remove() {
  post_install
}

czwartek, 17 grudnia 2015

LibreOffice 5.1 rc1 dla Arch Linux (Manjaro)

Właśnie na serwerach deweloperskich zagościła pierwsza wersja kandydująca popularnego pakietu LibreOffice z serii 5.1. Poniżej przedstawiam PKGBUILD umożliwiający budowę i instalację paczki dla Arch Linux (oraz dystrybucji pochodnych, w tym Manjaro). O nowościach tej wersji tej wersji można przeczytać m.in. w artykule na portalu dobreprogramy.pl, nie będę się zatem i rozpisywał i powielał te informacje, które są łatwo dostępne również na stronach związanych z pakietem.
Kilka uwag natomiast o przedstawionym PKGBUILDzie.
Po pierwsze wyszedłem z założenia, że samodzielna kompilacja pakietu ze źródeł, który ma wielkość  ok. 0,5GB to gruba przesada. Nawet na dość szybkich komputerach będzie trwać to bardzo długo. Document Foundation tworzy natomiast paczki w formatach rpm oraz deb, które dość łatwo dają się przekonwertować na format znany pacmanowi, który potrafi go zainstalować i nim zarządzać. Stąd też PKGBUILD po prostu przebudowuje istniejącą paczkę rpm. Zaletą takiego rozwiązania jest stosunkowo krótkie budowanie paczki dla Archa. Po drugie PKGBUILD umożliwia wyłącznie zbudowanie LO 5.1 rc1 w wersji dla systemów 64 bitowych (choć łatwo go można przerobić na wersję dla systemów 32 bitowych). Po trzecie zaś oferuję wyłącznie budowę polskiej wersji językowej (znów - łatwo jest zbudować paczkę w wersji oryginalnej, bądź w innym, dostępnym języku).
Paczka instaluje się w katalogu /opt umożliwiając koegzystencję na jednym komputerze z LibreOffice Fresh bądź Still.
Nie będę powtarzać, że program jest w wersji testowej, że wobec powyższego nie nadaje się do używania "produkcyjnego" itp. Udostępniam dla tych wszystkich, którzy chcą się wdrożyć w rozwój pakietu, choćby poprzez zgłaszanie dostrzeżonych błędów.
Pakiet nie jest moim autorskim rozwiązaniem, a jedynie zmienionym skryptem libreoffice-fresh-rpm udostępnionym na AUR.

PKGBUILD
pkgname=libreoffice-rpm-pl
pkgver=5.1.0.rc1
_pkgver=5.1.0.1
pkgrel=1
pkgdesc="LGPL Office Suite installed from rpms"
arch=('any')
url='http://www.libreoffice.org'
license=('LGPL')
conflicts=('libreoffice-fresh-rpm' 'libreoffice-rpm-rc-pl' 'libreofficedev-rpm-pl')
depends=('glibc>=2.5' 'gtk2>=2.10.4' 'xorg-server')
makedepends=('curl' 'awk')
optdepends=('jre7-openjdk' 'gtk3' 'gst-plugins-base' 'gst-plugins-good' 'gst-plugins-bad' 'gst-plugins-ugly')
source=(
"http://dev-builds.libreoffice.org/pre-releases/rpm/x86_64/LibreOffice_${_pkgver}_Linux_x86-64_rpm.tar.gz"
"http://dev-builds.libreoffice.org/pre-releases/rpm/x86_64/LibreOffice_5.1.0.1_Linux_x86-64_rpm_helppack_pl.tar.gz"
"http://dev-builds.libreoffice.org/pre-releases/rpm/x86_64/LibreOffice_5.1.0.1_Linux_x86-64_rpm_langpack_pl.tar.gz"
)

package() {   ## package function

## check kernel version to allow arbitrarily patched kernels
min_kernMajor=2;
min_kernMinor=6;
min_kernRelease=18;
## in bash, we need to split kernVer assigning into 2 steps
tmp_kernVer=$(uname -r);
new_kernVer=${tmp_kernVer%%-*}
kernVer=(${new_kernVer//./ });
## remove temporary variables
unset new_kernVer tmp_kernVer;

if [ ${kernVer[0]} -le $min_kernMajor ]; then
   if [ ${kernVer[1]} -le $min_kernMinor ]; then
      if [ ${kernVer[2]} -lt $min_kernRelease ]; then
         msg "The kernel version needs to be at least 2.6.18. The current kernel version is $(uname -r). Please update your linux kernel";
         exit;
      fi;
   fi;
fi;

cd ${srcdir};  ## enter the package source directory
## extract rpms and install them
for a in $(ls -d */); do  ## loop for all directories found
  cd "${srcdir}/${a}/RPMS";  ## enter the RPMS directory
  for b in *.rpm; do  ## loop for all rpm files found
    bsdtar -xf $b;  ## extract the rpm files
  done;
  
  cp -rf */ ${pkgdir}/;  ## copy and merge all found directories to the package directory

  ## change the permissions for files that shouldn't be executable
  declare -a wrongexec=("opt/libreoffice$(echo $pkgver | awk -F'.' 'OFS="." {print $1,$2}')/CREDITS.fodt" "opt/libreoffice$(echo $pkgver | awk -F'.' 'OFS="." {print $1,$2}')/LICENSE.fodt" "opt/libreoffice$(echo $pkgver | awk -F'.' 'OFS="." {print $1,$2}')/NOTICE");  ## set the array to change permissions
  for a in ${wrongexec[@]}; do
  chmod 644 ${pkgdir}/$a; ## change permissions to read/write for root, read only for users
  done;
done;
}
md5sums=('41a23a79bf4ceecf18286234a48fed17'
         '483d02dd34ce7620ed04caa07c9950e0'
         'ff99b1cd930a7bcbc124b7ca63219319')

środa, 16 grudnia 2015

Dla chcącego nic trudnego, czyli patchwork

W Arch Linuksie kerneli moc. Maksymalnie zbliżony do upstreamowego, LTS, grsec i zen -to w repozytoriach, są jeszcze przecież kernele, które są w nieoficjalnych repozytoriach, a nadto które  budujemy na podstawie skryptów z AUR bądź tworzonych we własnym zakresie.
Ostatnio sir_lucjan pożegnał się z kilkoma kernelami, których skryptami opiekował się w AUR. W ten sposób niektórzy mogą poszukiwać kerneli, które oparte są o rozwiązania, które proponował. Nie mam zamiaru tutaj pisać jak tworzyć PKGBUILD dla kerneli w Archu, jak nakładać patche itp. Jeśli ktoś z Was nie wie, to prościej i łatwiej skorzystać z gotowych czy to kerneli, czy to skryptów w AUR. Dla tych, którzy jednak wiedzą o co chodzi, czują się na siłach, czy to zrobić sobie PKGBUILD, czy też zbudować kernel w sposób tradycyjny po prostu garść linków, które być może ułatwią Wam znalezienie odpowiednich patchy. Pomijam te patche, które są dość łatwe do odnalezienia w gotowych kernelach, czy skryptach. Proszę również nie traktować tego wpisu jako zupełnego katalogu istniejących patchy. Podaję też jedynie patche ogólne, które nie są związane z konkretnym rozwiązaniem hardware'owym. Będę natomiast starał się na bieżąco podawać Wam, gdzie znaleźć można patche dla poszczególnych wersji kerneli począwszy od 4.3.3.

1. Patche BFS i CK
Właśnie ukazała się nowa wersja popularnych patchy Cona Kolivasa. Znajdziecie je tu:
BFS
wersja 467
CK
wersja CK3 dla kerneli 4.3
CK od BFS odróżnia istnienie w tym kernelu pewnych dodatkowych patchy, które - zdaniem Cona Kolivasa - powodują lepszą pracę BFS. Niemniej jednak jeśli ktoś chce użyć samego BFS i dostosować sobie kernel według własnych potrzeb, nic nie stoi na przeszkodzie w użyciu BFS.

2. Patch BFQ
Wszystkie 3 patche znajdziemy w repozytorium prowadzonym przez autora - Paolo Valente. Lucek wprawdzie się opiekuje cały czas linux-bfq, jednakże dość często BFQ używany jest we współpracy z BFS/CK/BLD dlatego też podaję.

3. Patch BLD
Patche dla różnych wersji kerneli dostępne są na GitHubie autora - Rahula Mullicka.

4. Patch graysky'ego rozszerzający możliwości użycia flag gcc dla większej ilości typów procesorów
Również i ten patch bardzo często występuje w PKGBUILDach. W zasadzie wykorzystywany jest obecnie wyłącznie przez autora dla tworzonych przez niego kerneli linux-ck oraz w kompilacjach własnych. Patch dostępny jest w repozytorium autora w kilku wersjach dostosowanych do wersji gcc oraz procesora.

5. Patch UKSM
Niestety od pewnego czasu autor zaniedbał rozwój tego patcha. Gdyby nie to, to powinien on być dostępny ze strony autorskiej projektu.
Wiadomo jednak, że np. Oleksandr Natalenko (twórca linux-pf) dostosowuje jego kod do używanych przez siebie patchy pf. Dla kernela w wersji 4.3 możemy pobrać ten patch z repozytorium mazdlc. Niestety nie wiem czy sam opiekun tego repozytorium jest jego twórcą, czy też pobrany został kod od Oleksandra Natalenki bądź Alfreda Chena, czy też z innych jeszcze źródeł. Sprawdziłem - działa, nie zauważyłem też w nim jakichś "pułapek" (tu jednak pamiętajcie: nie jestem informatykiem i używacie tego patcha w tej wersji na własne ryzyko).

6. Patch GC
To jedno z dwu autorskich rozwiązań Alfreda Chena, które zawiera m.in. BFS. Stąd też często, gdy Con Kolivas nie wypuszcza swoich patchy, można pobrać chenową wersję tego patcha. Więcej o tych kernelach znajdziecie na blogu Alfreda Chena.
Aktualna wersja patcha dla kernela 4.3, to 4.3.1, który wymaga nałożenia dwu patchy: gc_v4.3_0463_1 oraz 4.3_gc3_fix jeśli spotkaliście się z błędem wybudzania w przypadku użycia wyłącznie pierwszego.

7. Patch VRQ
To drugi z kerneli Alfreda Chena. O nim możecie się również dowiedzieć coś z blogu autora. Obecna weresja - podobnie jak w przypadku GC to 4.3.1, która wymaga nałożenia dwu patchy (na takich samych warunkach jak w GC):
vrq_v4.3_0465_2 oraz 4.3_vrq1_fix

Otter-Browser wersje tygodniowe dla Archa; wersja #102

Przez jakiś czas zamieszczałem na Arch-Like tygodniowe migawki nowej przeglądarki internetowej otter-browser, umożliwiające budowę pakietów dla Arch Linuksa, a także dystrybucji takich jak Antergos, Bridge Linux itp. Skrypty powinny budować również prawidłowe paczki dla systemu Manjaro.
Sam Otter-Browser jest dalekim spadkobiercą Opery 12.x. Idea pozostaje podobna, zmianie uległ framework, na którym jest budowana (jest to Qt5) oraz silnik w oparciu, o który działa. Co do zasady, Otter-Browser został tak zaprojektowany, że użyć można dowolnego silnika. Obecnie jest możliwe jej budowa zarówno w wersji opartej o QtWebKit, jak i o QtWebEngine. Ten pierwszy silnik od dłuższego czasu nie jest aktywnie rozwijany i w Qt zastąpić ma drugi, który niestety również nie jest jeszcze w 100% gotowy. Niemniej jednak oba działają, choć prawdopodobnie nie jest to jeszcze ostatnie słowo ich twórców, zwłaszcza jeśli chodzi o QtWebEngine.
Przedstawione niżej skrypty umożliwiają budowę Otter-Browsera działającego zarówno w oparciu o QtWebKit, jak i QtWebEngine.
W celu budowy paczki i instalacji aplikacji w systemie musimy skopiować kod wybranego przez siebie PKGBUILDu oraz plik otter-browser.install i umieścić go w jakimś katalogu. Następnie w tym katalogu należy wydać polecenie:
makepkg -sirc
Oczywiście samo makepkg również wystarczy, ale obecnie paczka buduje się prawidłowo zatem spokojnie możemy usunąć pozostałości po jej budowie (-rc), jak i ją zainstalować z poziomu makepkg (-i); opcja -s służy pobraniu zależności, jeśli nie zostaną one znalezione w systemie.

Plik otter-browser.install jest wspólny dla obu PKGBUILDów:
post_install() {
  update-desktop-database -q
  update-mime-database usr/share/mime > /dev/null
  gtk-update-icon-cache -q -t -f /usr/share/icons/hicolor
}
post_upgrade() {
  post_install
}
post_remove() {
  post_install
}
PKGBUILD dla wersji opartej o QtWebKit:
# Maintainer: boenki <boenki at gmx dot de>
# Maintainer: pavbaranov
# Contributor: sir_lucjan
# Full pkgname # Do no edit below this line unless you know what you're doing
_pkgver=0.9.09
_weekver=102
_pkgname=otter-browser-webkit-weekly
################################################
pkgname=$_pkgname
__pkgname=otter-browser
pkgver=$_pkgver.$_weekver
pkgrel=1
pkgdesc="Browser aiming to recreate classic Opera (12.x) UI using Qt5 - qtwebkit version."
arch=('i686' 'x86_64')
url="http://$pkgname.org"
license=('GPL3')
depends=('qt5-webkit' 'qt5-script' 'qt5-multimedia' 'hicolor-icon-theme' 'desktop-file-utils')
makedepends=('cmake' 'qt5-tools')
conflicts=('otter-browser-git' 'otter-browser' 'otter-browser-0.9.*' 'otter-browser-beta*')
provides=('otter-browser*')
install=otter-browser.install
source=("http://sourceforge.net/projects/otter-browser/files/otter-browser-weekly${_weekver}/otter-browser-${_pkgver}-dev${_weekver}.tar.bz2")
md5sums=('b5d52d8b12998827cbb027977ce71840')
build() {
  cd ${__pkgname}-${_pkgver}-dev${_weekver}
  lrelease resources/translations/*.ts
  cmake -DCMAKE_INSTALL_PREFIX="/usr"
  make
}
package() {
  cd ${__pkgname}-${_pkgver}-dev${_weekver}
  make DESTDIR=$pkgdir install
}
PKGBUILD oparty o QtWebEngine:
# Maintainer: boenki <boenki at gmx dot de>
# Maintainer: pavbaranov
# Contributor: sir_lucjan
# Full pkgname # Do no edit below this line unless you know what you're doing
_pkgver=0.9.09
_weekver=102
_pkgname=otter-browser-webengine-weekly
################################################
pkgname=$_pkgname
__pkgname=otter-browser
pkgver=$_pkgver.$_weekver
weekver=$_weekver
pkgrel=1
pkgdesc="Browser aiming to recreate classic Opera (12.x) UI using Qt5 - qtwebengine version."
arch=('i686' 'x86_64')
url="http://$pkgname.org"
license=('GPL3')
depends=('qt5-webengine>=5.5' 'qt5-script>=5.5' 'qt5-multimedia>=5.5' 'hicolor-icon-theme' 'desktop-file-utils')
makedepends=('cmake' 'qt5-tools>=5.5')
conflicts=('otter-browser-git' 'otter-browser' 'otter-browser*' 'otter-browser-beta*')
install=otter.install
source=("http://sourceforge.net/projects/otter-browser/files/otter-browser-weekly${_weekver}/otter-browser-${_pkgver}-dev${_weekver}.tar.bz2")
md5sums=('b5d52d8b12998827cbb027977ce71840')
build() {
  cd ${__pkgname}-${_pkgver}-dev${_weekver}
  lrelease resources/translations/*.ts
  cmake -DCMAKE_INSTALL_PREFIX="/usr" \
-DEnableQtwebengine=ON
  make
}
package() {
  cd ${__pkgname}-${_pkgver}-dev${_weekver}
  make DESTDIR=$pkgdir install
}
W przypadku dokonania tego drugiego wyboru musimy nadto poinformować przeglądarkę, że chcemy używać QtWebEngine jako jej silnika (w przeciwnym przypadku będzie ona pracować na domyślnym QtWebKit). W tym celu po uruchomieniu przeglądarki wpisujemy w pasek adresu:
about:config
a następnie albo odszukujemy pozycję Backends a w niej Web zmieniamy Wartość z qtwebkit na qtwebengine oraz zatwierdzamy wprowadzone zmiany.

środa, 9 grudnia 2015

Skrypt budujący kernel z różnych patchy

Arch Linux oferuje nam obecnie cztery kernele w repozytoriach:

  • linux - odpowiadający w zasadzie ostatniemu kernelowi dostępnemu ze strony kernel.org z linii stable,
  • linux-lts - będący co do zasady ostatnim kernelem udostępnianym przez kernel.org z linii o przedłużonym wsparciu (LTS),
  • linux-zen - kernel oferujący autorski patch, który ma na celu zwiększyć użyteczność kernela w codziennych zastosowaniach desktopowych,
  • linux-grsec - kernel z patchami Grsecurity i PaX zwiększający poziom jego bezpieczeństwa.
Krótkie przeglądnięcie jednak repozytoriów nieoficjalnych oraz AUR wykaże od razu, że różnego rodzaju kerneli, które można zbudować dla Archa jest cała masa. Nakładki jak CK, BFQ, BLD, configi dla poszczególnych nawet rodzajów maszyn, to wierzchołek góry lodowej.
Przyszedł mi do głowy zatem pomysł, by zbudować jeden PKGBUILD, który zawierałby całą masę różnych patchy. Skoro jednak PKGBUILD można zbudować jako skrypt (w zasadzie to skryptem jest), to nic nie stoi na przeszkodzie (oprócz "zasad" panujących a Arch Linuksie, ale mówię tu o czymś  zewnętrznym; nawet AUR nie jest oficjalnie wspierany przez zespół deweloperów rozwijających Archa) stworzeniu go w taki sposób, by użytkownik, który decyduje się na budowę kernela otrzymał możliwość wyboru rozwiązań, które uzna za najlepsze dla swoich potrzeb. Uniknie się w ten sposób konieczności zmiany PKGBUILDów pod własne cele. Będzie jeden PKGBUILD a do użytkownika będzie należeć wybór tych patchy, które chce użyć. Być może warto byłoby się zastanowić również nad możliwością dołączenia kilku configów, właściwych dla określonych maszyn (np. dla niektóych netbooków, czy dla ThinkPadów spośród tych, które najpopularniejsze). 
W ten sposób każdy użytkownik Archa (i dystrybucji pochodnych) mógłby stworzyć dowolny (oczywiście z zaoferowanych patchy) zestaw nakładek, które chce użyć. 
To oczywiście pomysł. Chciałbym poznać Waszą opinię na temat jego użyteczności.

poniedziałek, 7 grudnia 2015

Więcej aplikacji na KF5 - mniej kompilacji

Od roku używam nowej wersji KDE, czyli czegoś, co w zasadzie nie wiadomo nawet jak się nazywa. Środowisko jest budowane m.in. w oparciu o Qt5 oraz specjalnie stworzony na potrzeby Plasmy 5, zestaw bibliotek o nazwie KDE Frameworks 5. Choć doczekaliśmy się praktycznie już ich 17 wydania  (czyli powstają od półtora roku), choć przedłużone już wsparcie dla Qt4 niebawem się skończy, to nie wszystkie jeszcze aplikacje ze świata KDE zostały przeportowane do nowych bibliotek.
Z różnych względów używam wersji przeportowanych do Qt5/KF5. Do tej pory odbywało się to poprzez ich kompilowanie z GIT. W części opierając się o AUR, w części tworząc własne PKGBUILDy. Człowiek jest jednak leniwy, a pojawiło się nowe repozytorium, w którym dość dużo jest aplikacji zbudowanych praktycznie w ten sam sposób, którego używałem dotąd. Zanim jednak przedstawię odpowiednie wpisy do pacman.conf kilka uwag ogólnych.
Aczkolwiek aplikacje, o których mowa nie zostały jeszcze uznane przez zespół tworzący oprogramowanie dla KDE, to znakomita większość spośród nich działa prawidłowo. Niekiedy nie ma wszystkich funkcjonalności znanych ze swoich odpowiedników dla KDE4, sporadycznie wprawdzie budują się, ale nie działają (tak jest od jakiegoś czasu z KGet opartym na KF5). Czy stosować, czy też nie takie aplikacje, pozostawiam oczywiście Waszemu wyborowi. To co można zwykle zauważyć w porównaniu do aplikacji opartych na KDE4/Qt4 używanych w Plasma 5, to nieco mniejsze zapotrzebowanie na zasoby komputera. Nie jest to jednak reguła, a sam zwykle nie przejmuję się ile pamięci mi jakiś program zżera, czy też jaki ma apetyt na CPU do chwili, gdy wszystko działa prawidłowo. Nie ślęczę zatem przy monitorze systemu śledząc czy lepiej jest, czy gorzej. Jeśli u Was aplikacje KDE4 w Plasma 5 działają sprawnie, to nie namawiam do eksperymentów.
Jeśli jednak ktoś by chciał...
Skąd zatem brać aplikacje dla Plasma 5? Pomijam w tej chwili AUR. Pomijam też te, które znajdują się już w repozytoriach "stabilnych" Archa. Źródła repozytoriów, co do zasady mamy dwa.
Pierwszym jest testowe repozytorium kde-unstable. Jest to królestwo Antonio Rojasa, opiekuna KDE w Archu. Tutaj pojawiają się wersje aplikacji, które udostępnione są przez zespół KDE w repozytorium unstable projektu KDE. Informacje o nich najczęściej można przeczytać na stronie projektu KDE, można też śledzić te nowości w repozytorium. W kde-unstable nigdy nie pojawią się wersje aplikacji, które nie zostały w nim udostępnione. W tym repozytorium Archa pojawiają się natomiast testowe wersje zarówno samego środowiska Plasma 5, jak i testowe wydania KDE Applications. Te ostatnie w wersjach opartych o KF5 o tyle, o ile w przeportowanej wersji zostały umieszczone we wspomnianym repozytorium KDE. Ważną informacją dla chcących uruchomić możliwość instalacji z kde-unstable jest to, że budowane są one w oparciu o repozytorium testing Archa, zatem powinniśmy udostępnić dla pacmana oba te repozytoria. Biorąc pod uwagę, że Arch nie wspiera częściowej aktualizacji, oznacza to konieczność przejścia na testową wersję oprogramowania tego systemu. Nie chcę słuchać, że to są "niestabilne" wersje. Nikt nikogo nie zmusza do pracy na paczkach testowych. Mogę powiedzieć natomiast jedno o aplikacjach w KDE umieszczanych w jego repozytorium unstable. Oprogramowanie to znajduje się tu w co najmniej wersji beta i z reguły, tak sama Plasma, jak i aplikacje (szczególnie te, które są jedynie aktualizowane z wcześniej wydanych wersji) często okazują się "lepsze" od tzw. wersji stabilnych. Reguły jednak nie ma i nie daję żadnej gwarancji, że tak za każdym razem będzie.
Jeśli zatem zdecydujecie się uruchomić programy KDE dostępne w kde-unstable musicie w pliku /etc/pacman.conf dokonać następujących wpisów:
[kde-unstable]
Include = /etc/pacman.d/mirrorlist
[testing]
Include = /etc/pacman.d/mirrorlist
Wpisy muszą znaleźć się powyżej innych repozytoriów, jak core, extra, czy community. Oczywiście, aby prawidłowo działały programy z repozytorium testing powinniśmy również dokonać odpowiednich wpisów udostępniających community-testing (a używając bibliotek multilib, również multilib-testing). Standardowy plik pacman.conf zawiera już stosowne wpisy, wystarczy jedynie usunąć znak # przed ich nazwą oraz poleceniem Include, udostępniając w ten sposób je systemowi.
Raz jeszcze: są to wpisy udostępniające systemowi testowe oprogramowanie, które co do zasady winno służyć wyłącznie do celów testowania nadchodzących rozwiązań w Archu, a nie do codziennej pracy. Nie chcesz pomagać deweloperom Archa, to otwierając te repozytoria przynajmniej nie marudź, że to nie działa, że Arch nie jest stabilny itp. Nie chcesz pomóc - to w takim razie nie są to rozwiązania dla Ciebie. Nie umiesz sobie poradzić w kłopotach, gdy skutkiem pojawienia się w testing nowej wersji jakiegoś programu system okaże się niesprawny - nie jest to rozwiązanie dla Ciebie.
Drugie repozytorium pojawiło się stosunkowo niedawno i nie jest repozytorium pochodzącym nawet od deweloperów Archa. Znajdują się tu programy, które co do zasady odpowiadają wersjom budowanym z AUR. Praktycznie jedyna różnica, to inne oznaczenia tych paczek, albowiem przyjęta w Archu dla budowy paczek z GIT reguła stanowi, by numer wersji paczki aplikacji znajdującej się w fazie rozwojowej oznaczać przez nr_rewizji.nr_commitu. Numer wersji paczek w omawianym teraz repozytorium najczęściej składa się natomiast z daty_pojawienia_się_commitu.nr_commitu. W ten sposób zawsze "wyprzedzą" one wersje budowane z AUR - dla systemu będą się prezentować jako nowsze wersje, nawet gdy takimi nie są.
Repozytorium dostępne jest po dokonaniu następującego wpisu:
[home_mazdlc_kde-frameworks-5_Arch_Extra]
SigLevel = Never
Server = http://download.opensuse.org/repositories/home:/mazdlc:/kde-frameworks-5/Arch_Extra/$arch
Niestety nie wiem, czy one również wymagają uruchomienia repozytorium testowego i kde-unstable (dla nowych wydań Plasma 5), jednakże należałoby tak przyjąć. Repozytorium powyższe jest bardzo często aktualizowane. Od pojawienia się nowych wersji aplikacji udostępnionych w GIT zwykle nie czeka się dłużej niż 2-3 dni by odpowiadająca im wersja ukazała się w repozytorium. Z reguły aktualizacje odbywają się szybciej.

Jeśli ktoś bardzo chciałby korzystać z aplikacji opartych o KF5, których nie ma jeszcze w repozytoriach stabilnych Archa, ale jednocześnie nie chce mieć testowej wersji Archa, jedna podpowiedź. Aplikacje w obu repozytoriach przedstawionych wyżej są  budowane w oparciu o KF5, Qt5 i ewentualnie inne jeszcze biblioteki. Zespół KDE nie wypuszcza obecnie KF5 w wersjach beta, czy kandydujących. Mniej więcej w comiesięcznym cyklu pojawia się nowa ich wersja. Jeśli zatem szczególnie w repozytorium kde-unstable pojawia się jakiś zestaw aplikacji, a jednocześnie w repozytorium testing nie ma paczek KF5 ani Qt5 (także pozostałych zależności konkretnej paczki), to może okazać się, że aplikacje z tego repozytorium działać będą także w przypadku nieudostępnienia systemowi repozytorium testing. Ze względu na to, że nie jest to polecana metoda w żaden sposób jej ani nie rekomenduję, ani nie namawiam do używania. Pamiętajcie - decydując się na takie rozwiązanie - gwałcicie Archa jak Syfona przez uszy.

Kilka jeszcze uwag o obu repozytoriach i aplikacjach w nich zawartych.
Jak wspomniałem, przynajmniej jedna aplikacja oparta o KF5 nie działa. Jest nią KGet. Wprawdzie uruchomi się, ale nie ściągnie niczego. Czy inne działają? Odpowiem inaczej - nie stosuję wszystkich aplikacji z KDE, ale te, które używam działają. Nie ręczę, że tak będzie w każdym przypadku.
Co do zasady repozytorium Mazdlc nie powielało jak dotąd aplikacji, które zostały już w wersji na KF5 udostępnionych w Archu i to nawet w kde-unstable. Od chwili udostępnienia DigiKam 5.0.0 beta 2 (oraz bibliotek, na których się DigiKam opiera) w repozytorium unstable KDE i z chwilą pojawienia się tej aplikacji w tej wersji w kde-unstable, mamy do czynienia z sytuacją, gdzie w kde-unstable jest  DigiKam 5.0.0beta2 (i biblioteki, na których się opiera w tej wersji bądź w wersji 15.11.90), zaś w repozytorium Mazdlc znajduje się digikam-git. DigiKam 5 w kolejnych wersjach beta będzie prawdopodobnie obecny w kde-unstable aż do chwili jego oficjalnej premiery, która nastąpić ma 30.04.2016 r. Nie wiem jak długo digikam-git będzie dostępny w repozytorium Mazdlc, ale rozsądek podpowiada, by stosować rozwiązania z kde-unstable. Tutaj pojawia się jeden problem. W obu repozytoriach istnieje biblioteka libksane. W kde-unstable w wersji 15.11.90 i niebawem prawdopodobnie ta biblioteka w wersji 15.12 trafi do repozytorium Archa (wpierw testing, potem extra), zaś w Mazdlc jest jej wersja libksane-git. W oparciu o tę ostatnią, w tym repozytorium  zbudowana jest aplikacja do obsługi skanera Skanlite (w wersji skanlite-frameworks-git). Nie istnieje zatem możliwość używania tej aplikacji z biblioteką z kde-unstable. Konieczne jest jej przebudowanie w oparciu o libksane z kde-unstable czyli zbudowanie jej z obecnego skryptu udostępnionego w AUR (aktualizacja 4.12.2015).