Re: Zmienione linkowanie /usr/bin/python - nie działa pyzor
On Fri, Jun 14, 2024 at 04:40:11PM +0200, Maciej Kędzierski wrote: > Zmiana linkowania /usr/bin/python z python2 na python3 spowodowała, że > przestał się uruchamiać 'pyzor' z pakietu pyzor-1.0.0-1 > > # pyzor > Traceback (most recent call last): > File "/usr/bin/pyzor", line 24, in > import pyzor.digest > ModuleNotFoundError: No module named 'pyzor' > > Brakuje modułów, które w pyzorze są tylko dla wersji python2. > > Tak na szybko można to naprawić zmieniając interpreter w pliku pyzor z: > #!/usr/bin/python > na > #!/usr/bin/python2 > > No chyba, że są jakieś nowe wersje pyzora, które działają z python3? Obstawiam, że zdecydowana większość pakietów wymagających /usr/bin/python nie działa poprawnie z pythonem 3. W miarę wolnych zasobów czasowych można przeglądać listę `search -r /usr/bin/python` z poldka i poprawiać (takiego shebanga być nie powinno w żadnym pakiecie - tylko explicite python2 lub python3). -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: [packages/kf5-attica] - updated to 5.249.0; rel 0.1
On Sun, Feb 04, 2024 at 03:04:21PM +0100, Witold Filipczyk via pld-devel-en wrote: > Dnia Sat, Feb 03, 2024 at 08:56:25PM +0100, Jakub Bogusz napisał(a): > > On Sat, Feb 03, 2024 at 08:39:39PM +0100, witekfl wrote: > > > commit 3b3013be1262989c7a7df78ffab6d797766b6486 > > > Author: Witold Filipczyk > > > Date: Sat Feb 3 20:24:04 2024 +0100 > > > > > > - updated to 5.249.0; rel 0.1 > > > > > > kf5-attica.spec | 41 - > > > 1 file changed, 20 insertions(+), 21 deletions(-) > > > > Shouldn't these (kf5-* 5.249.0) be kf6-*.spec now? > > OK. What to do with plasma (now kp5-*) and KDE Gear (now ka5-*) ? No idea about starting prefix (should "kp" and "ka" be preserved or changed), but AFAICS files/dirs are getting "6" suffix now, so IMO number should be updated (or dropped, if KDE 6 is going to instantly replace KDE 5). -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: [packages/kf5-attica] - updated to 5.249.0; rel 0.1
On Sat, Feb 03, 2024 at 08:39:39PM +0100, witekfl wrote: > commit 3b3013be1262989c7a7df78ffab6d797766b6486 > Author: Witold Filipczyk > Date: Sat Feb 3 20:24:04 2024 +0100 > > - updated to 5.249.0; rel 0.1 > > kf5-attica.spec | 41 - > 1 file changed, 20 insertions(+), 21 deletions(-) Shouldn't these (kf5-* 5.249.0) be kf6-*.spec now? -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: pldcpan.pl - potrzebna poprawka
On Thu, Jul 20, 2023 at 08:53:50AM +0200, Arkadiusz Miśkiewicz via pld-devel-pl wrote: > Mógłby fan perla zerknąć na nasz pldcpan i poprawić mu regułki parsujące > nazwę by działał także z takimi przypadkami jak: > > ./pldcpan/pldcpan.pl IP::Country::DB_File > > ? Fanem nie jestem, ale poprawione w 1.66. Kosztem obsługi "_" jako separatora członów nazwy modułu, ale takich przypadków nie znalazłem w przyrodzie. Teraz obsługiwany jest tylko separator "-"; "_" jest teraz znakiem dozwolonym w nazwie (poza pierwszym znakiem członu, analogicznie do cyfr). -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: kp5-drkonqi i systemd
On Wed, Oct 27, 2021 at 05:31:56PM +0100, Krzysztof Mrozowicz via pld-devel-pl wrote: > Cześć, > widzę, że kp5-drkonqi-5.23.2 dostarcza komponenty do systemd, dokładnie: > > /usr/lib/systemd/system/drkonqi-coredump-processor@.service > > Jednak nic nie dostarcza katalogu /usr/lib/systemd/system, za to jest > już /lib/systemd/system dostarczony przez systemd-units. > > No i teraz pytanie - dodać katalog /usr/lib/systemd/system do > systemd-units, czy zmienić kp5-drkonqi tak aby używał > /lib/systemd/system? > > Osobiście uważam, że lepiej zmienić kp5-drkonqi, ale może ktoś kto zna > systemd lepiej ode mnie, ma inne zdanie? Poprawić kp5-drkonqi. /usr/lib/systemd/system to ścieżka przy konfiguracjach ze złączonym /usr (w których gdzie /lib jest dowiązaniem do /usr/lib). PLD przynajmniej na razie używa rozdzielonego /usr. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: czy wykonywanie make check jest ważne?
On Fri, Oct 22, 2021 at 11:19:06AM +0100, Krzysztof Mrozowicz via pld-devel-pl wrote: > Czołem, > kolejne pytanie od żółtodzioba. W instrukcji budowania programu cone > napisane jest żeby przed make install wykonać make check. Jest to > uwzględnione w specu poprzez: > > %bcond_without tests # "make check" > > No i o ile w starszej wersji, zdaje się że było OK, o tyle w wersji 1.2 > make check się wywala. Sprawdziłem jak to wygląda w specu przygotowanym > przez opensuse i tam nie robią tego wcale, nawet jako opcję dla > chętnych. > W PLD cone-1.2 buduje się z parametrem --without tests > > No i teraz pytanie - czy za wszelką cenę trzeba zrobić aby make check > kończyło się sukcesem? Czy można to zignorować, ewentualnie zmienić w > specu aby make check było domyślnie wyłączone i zbudować pakiet z > pominięciem tego kroku? Podstawowe pytanie - dlaczego testy nie przechodzą? Ogólnie, powinniśmy wiedzieć, czy budowany pakiet działa. Więc jeśli są sensowne testy (powtarzalne na builderach, łatwe do uruchomienia, nie wymagające sieci czy jakichś wyśrubowanych zasobów, nie trwające godzinami), to lepiej je uruchamiać - żeby niepowodzenie testów blokowało opublikowanie nie działającego pakietu. Jeżeli są sensowne testy i przestają przechodzić - trzeba zobaczyć, dlaczego. Może to świadczyć o niezgodności z jakąś biblioteką (np. pakiet nie działa dobrze z nową wersją biblioteki, albo nie działa ze starą, a nie sprawdza dobrze jej wersji w trakcie konfiguracji). -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: ipv6calc - Empty debugsourcefiles.list
On Wed, Oct 20, 2021 at 11:51:56AM +0100, Krzysztof Mrozowicz via pld-devel-pl
wrote:
> Hej,
> podbiłem wersję ipv6calc to 4.0.0, kompatybilnego z OpenSSL 3.0, ale
> niestety wyszedł problem tworzenia pakietu debug.
> Próbowałem dodać do speca:
>
> %build
> CFLAGS="%{rpmcflags}"
> CXXFLAGS="%{rpmcxxflags}"
>
> ...ale nie pomogło.
>
> Ktoś ma pomysł?
Tam ręcznie pisane pliki Makefile nie przejmują CFLAGS z configure,
w tym przypadku trzeba przekazać przez export (albo połatać Makefile).
--
Jakub Boguszhttp://qboosh.pl/
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: brak libLTO.so.12
On Thu, Sep 23, 2021 at 10:22:57AM +0100, Krzysztof Mrozowicz via pld-devel-pl
wrote:
> Cześć,
> próbuję skompilować nową wersję darktable i wywala mi się z błędem, że
> nie ma pliku libLTO.so.12. Sprawdziłem, że w llvm.spec wygląda to tak:
>
> %files libs
> [..]
> %attr(755,root,root) %ghost %{_libdir}/libLTO.so.12
> [..]
>
> Jest to jedyna zghostowana biblioteka w podpakiecie llvm-libs.
>
> Dodam, że /usr/lib64/libLTO.so w systemie plików jest symlinkiem do
> nieistniejącego pliku libLTO.so.12.
>
> Czy tak powinno być, a ja robię coś źle, czy może to jakaś pomyłka w
> specu od llvm?
Od czasu kiedy to przestał być symlink (w llvm 7), nie powinno być %ghost.
Będzie poprawione w 12.0.1-3.
--
Jakub Boguszhttp://qboosh.pl/
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: qt4 broken on i686
On Sun, Sep 19, 2021 at 08:17:47PM +0200, Jan Rękorajski wrote:
> On Thu, 19 Aug 2021, Jakub Bogusz wrote:
>
> > On Wed, Aug 18, 2021 at 10:34:48PM +0200, Jan Rękorajski wrote:
> > > New builds of qt4 on i686 exhibit crashes (ex. linguist in avogadro), or
> > > infinite looping (ex. meinproc4 in kde4-kig).
> > >
> > > I'm running out of ideas[1] and time to troubleshoot this and would
> > > appreciate if anyone would be willing to try and figure out WTF is
> > > broken there.
> > >
> > > [1] neither -O0, nor -std=gnu98 seem to do the trick, it could be a
> > > glibc 2.34 issue, but I don't have resources at hand to validate it.
> >
> > I don't know yet if it's related to glibc, gcc or binutils, but simple
> > testcase is searching in empty QMap:
> >
> > ```
> > #include
> >
> > int main()
> > {
> > QMap mm;
> > mm.constFind(999);
> > }
> > ```
> >
> > It hangs even on carme-x86_64.
> >
> > Issue is probably related to shared_null static field (SIOF?)
>
> My take is on gcc 11. I downgraded everything but gcc and it still crashed.
>
> To verify that it's indeed gcc I need to rebuild it (gcc) locally due to
> intertwined deps preventing simple package downgrade.
I tried to investigate the issue deeper - and the last I found was:
The symbol _ZN8QMapData11shared_nullE (demangled: QMapData::shared_null)
resides both in executable (objdump -T from i686):
0804c040 gDO .bss 0048 Base_ZN8QMapData11shared_nullE
and libQtCore.so.4:
002fa460 gDO .data 0048 Base_ZN8QMapData11shared_nullE
When compiled in current Th, the code in executable sees symbol mapped
from executable and the library sees symbol mapped from library.
IIRC when compiled on slightly older system (qt4 built with gcc 7 or 8,
glibc 2.33 etc.) in both cases symbol address was the same.
But in my current system (i686, glibc-2.34, binutils-2.37, gcc-8.4.0, qt4
rebuilt in this environment) the result is the same as in Th: there are
two instances of this symbol and testcase hangs.
--
Jakub Boguszhttp://qboosh.pl/
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Niespełnione zależności dla pakietu python3-pytest
On Fri, Sep 10, 2021 at 02:03:36PM +0200, Maciej Kędzierski wrote: > > Witam, > Chciałem skompilować sobie nowego clamav-0.104.0, ale okazało się, że od > tej wersji operacja ta wymaga CMake. > Zacząłem sobie doinstalowywać co tam jest potrzebne. Praktycznie > wszystko poszło OK, z jednym wyjątkiem. > > Po odpaleniu "cmake ..." wyskakuje informacja, że nie jest zainstalowany > pakiet 'pytest'. Najprościej dodać pakiet systemowy. > Próba jego normalnej instalacji kończy się jednak problem z > niespełnionymi zależnościami. > > poldek:/all-avail> install python3-pytest-6.2.2-1.noarch [...] > błąd: Niespełnione zależności: > (python3.9dist(pluggy) < 1~a1 with python3.9dist(pluggy) >= > 0.12) jest wymagane przez python3-pytest-6.2.2-1.noarch > Wystąpiły błędy podczas instalacji > > > Można oczywiście wymusić instalację tego pakietu, ale pytest nie działa > wtedy. Brakuje python3-pluggy (pytest go wymaga, ale poldek nie rozumie zapisu zależności). -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: qt4 broken on i686
On Wed, Aug 18, 2021 at 10:34:48PM +0200, Jan Rękorajski wrote:
> New builds of qt4 on i686 exhibit crashes (ex. linguist in avogadro), or
> infinite looping (ex. meinproc4 in kde4-kig).
>
> I'm running out of ideas[1] and time to troubleshoot this and would
> appreciate if anyone would be willing to try and figure out WTF is
> broken there.
>
> [1] neither -O0, nor -std=gnu98 seem to do the trick, it could be a
> glibc 2.34 issue, but I don't have resources at hand to validate it.
I don't know yet if it's related to glibc, gcc or binutils, but simple
testcase is searching in empty QMap:
```
#include
int main()
{
QMap mm;
mm.constFind(999);
}
```
It hangs even on carme-x86_64.
Issue is probably related to shared_null static field (SIOF?)
--
Jakub Boguszhttp://qboosh.pl/
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Czy glibc 2.32-8 to wypadek przy pracy?
On Sun, Feb 14, 2021 at 12:26:07AM +0100, Peri Noid wrote: > Dnia sobota, 13 lutego 2021 18:42:01 CET Jan Rękorajski pisze: > [...] > > Spróbuj 'install ldconfig-*.x86_64 glibc' > > Chyba zmiana nazwy pakietu nie wyszła na dobre: Ja tu widzę przynajmniej jeden, a raczej dwa problemy z poldkiem... > > poldek:/all-avail> install ldconfig-2.33-2.x86_64 glibc [...] > uwaga: niejednoznaczna nazwa glibc > glibc-2.32-7.i686: newer version installed, skipped > glibc-2.32-7.x86_64: newer version installed, skipped > Przetwarzanie zależności... > Jest 1 pakiet do instalacji: > A ldconfig-2.33-2.x86_64 > This operation will use 968.8KB of disk space. > Potrzeba pobrać 333.4KB archiwów. > Uruchamianie sudo /usr/lib/poldek/pm-command.sh --upgrade -vh --root / -- > define _check_dirname_deps 1... > Przygotowywanie... ### [100%] > error: Problemy z instalacją/usuwaniem: > plik /sbin/ldconfig z instalacji ldconfig-2.33-2.x86_64 jest w > konflikcie z plikiem z pakietu glibc-ld-2.32-8.x86_64 > Installing set #2 Czemu tu nie przerwał instalacji, jeśli ldconfig jest wymagany w Requires(post) następnie instalowanego pakietu... > Przetwarzanie zależności... > glibc-ld-2.32-8.i686 zostanie zastąpiony przez glibc-2.33-2.i686 > glibc-2.32-8.i686 zostanie zastąpiony przez glibc-2.33-2.i686 > glibc-2.33-2.i686 zaznaczył ldconfig-2.33-2.i686 (wł. ldconfig = 6:2.33-2) > glibc-ld-2.32-8.x86_64 zostanie zastąpiony przez glibc-2.33-2.x86_64 > glibc-2.32-8.x86_64 zostanie zastąpiony przez glibc-2.33-2.x86_64 > Something wrong, something not quite right with 0.42.2 (stable) > Assertion 'i_best >= 0' failed, misc.c:412 > Please report this bug to: https://github.com/poldek-pm/poldek/issues/new A to już błąd wewnętrzny, zresztą zgłoszony (#15). Spróbujmy trochę więcej poldkowi podpowiedzieć co do zależności (w rel 3). -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
przejście na boost 1.73
Większość przebudowałem, ale jeszcze nie wszystko. Jeśli są chętni, mogą kontynuować pod moją nieobecność. Ja wrócę do tego po powrocie, od 16 sierpnia. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: [PATCH] freerdp2 version update and disabling kerberos5 support
On Thu, Jan 23, 2020 at 01:37:47PM +, Krzysztof Mrozowicz wrote:
> Czesc,
> probujac rozwiazac problem z niemoznoscia uruchomienia wiecej niz
> jednego polaczenia RDP, podnioslem wersje freerdp2 do wersji z GITa z
> dnia 15.01.2020. Jednak ostatecznie to wylaczenie wsparcia dla
> kerberos5 rozwiazalo problem.
Uwzględniłem uaktualnienie i domyślne wyłączenie Kerberosa.
Co do pozostałych zmian:
> %if %{with x11}
> +BuildRequires: cairo-devel
cairo akurat jest opcjonalne i domyślnie nie używane, a z komentarzy
wynika, że dla tej samej funkcjonalności jest preferowane swscale.
> +BuildRequires: xorg-lib-libxkbcommon-devel
To akurat jest dla waylanda, nie x11.
--
Jakub Boguszhttp://qboosh.pl/
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: udisks2-2.8.4-1 nie montuje dysków
On Tue, Nov 12, 2019 at 06:50:24PM +0100, Łukasz Maśko wrote: > Dnia wtorek, 12 listopada 2019 16:07:05 Jakub Bogusz pisze: > [...] > > rpm -q libblockdev-fs ? > > $ rpm -q libblockdev-fs > libblockdev-fs-2.21-2.x86_64 A coś w logach/journalu widać? Jakaś starsza wersja potrafiła odmawiać współpracy, jeśli nie znalazła narzędzi do NTFS-a. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: udisks2-2.8.4-1 nie montuje dysków
On Sun, Nov 10, 2019 at 06:52:17PM +0100, Łukasz Maśko wrote: > Objaw jest taki: > > $ udisksctl mount -b /dev/sdf1 > Error mounting /dev/sdf1: GDBus.Error:org.freedesktop.UDisks2.Error.Failed: > Error mounting /dev/sdf1 at /run/media/ed/NETUSBEE: The function > 'bd_fs_mount' > called, but not implemented! > > Paczki z Th/ready (wszystkie możliwe). Ktoś? Coś? rpm -q libblockdev-fs ? -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Odzyskanie dostępu do dropin
On Mon, Nov 11, 2019 at 08:03:12PM +0100, Łukasz Maśko wrote: > Dnia poniedziałek, 11 listopada 2019 20:01:11 Łukasz Maśko pisze: > [...] > > O widzisz... Tego dropin@... mi zabrakło. Zbyt rzadko coś uploaduję, > > wyleciało z głowy. > > Przy okazji - jakiś marginalny błąd (wyjątek się wyrzuca)? > > $ git push origin master > Enumerating objects: 5, done. > Counting objects: 100% (5/5), done. > Delta compression using up to 4 threads > Compressing objects: 100% (3/3), done. > Writing objects: 100% (3/3), 402 bytes | 402.00 KiB/s, done. > Total 3 (delta 2), reused 0 (delta 0) > remote: Updated 1 path from 6cebe1c > remote: Exception TypeError: "'NoneType' object is not callable" in method Socket.__del__ of > > ignored > remote: Emitting a message to the fedmsg bus. > remote: * Publishing information for 1 commits > To ssh://git.pld-linux.org/packages/calibre >6be3ae0..fe8c5b5 master -> master Wygląda na to, że synchronizacja z githubem przestała działać. Albo coś się pozmieniało po stronie githuba, albo skrypt/używane moduły wymagają dostosowania po uaktualnieniu Pythona (to jest 2 czy 3?). -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Odzyskanie dostępu do dropin
On Sun, Nov 10, 2019 at 01:29:22PM +0100, Łukasz Maśko wrote: > Prośba do admina. > Zapomniałem hasła do dropin. Chciałbym wrzucić nową wersję Calibry, a ona > wymaga załączenia przerobionego tarball-a. Czy mogę poprosić o pomoc? Nie potrzeba hasła, można użyć scp ... dro...@dropin.pld-linux.org: z tym samym kluczem SSH, co do gita. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: opensmtpd-6.0.3p1-1 i backend "db"
On Thu, Oct 03, 2019 at 11:53:27AM +0200, stacho wrote:
> Witam,
>
> Sprawdziłem kolejną zmianę:
[...]
> Nie wiem czy prawidłowo, ale zrobiłem taką zmianę:
>
> diff --git a/opensmtpd.spec b/opensmtpd.spec
> index 1361fba..c4bce2e 100644
> --- a/opensmtpd.spec
> +++ b/opensmtpd.spec
> @@ -9,7 +9,7 @@ Summary:Free implementation of the server-side
> SMTP protocol as defined by RFC
> Summary(pl.UTF-8): Wolnodostępna implementacja strony serwerowej
> protokołu SMTP wg RFC 5321
> Name: opensmtpd
> Version: 6.4.2p1
> -Release: 2
> +Release: 3
> License: ISC
> Group: Daemons
> Source0:
> https://www.opensmtpd.org/archives/%{name}-%{version}.tar.gz
> @@ -196,7 +196,7 @@ fi
> %attr(755,root,root) %{_libexecdir}/%{name}/mail.mda
>
> %dir %attr(711,root,root) %{spooldir}
> -%dir %attr(1777,root,root) %{spooldir}/offline
> +%dir %attr(770,root,smtpq) %{spooldir}/offline
> %dir %attr(700,smtpq,root) %{spooldir}/corrupt
> %dir %attr(700,smtpq,root) %{spooldir}/incoming
> %dir %attr(700,smtpq,root) %{spooldir}/purge
> ===
> Zbudowałem, uruchomił się i na domyślnej konfiguracji działa.
> Teraz czas na nowy config. :(
Dzięki.
Gdyby podczas konfiguracji wyszło, że coś jeszcze trzeba zmienić, to daj
znać, poprawię hurtem.
--
Jakub Boguszhttp://qboosh.pl/
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: [packages/boost] - updated to 1.70.0
On Sat, Apr 13, 2019 at 09:27:35AM +0200, Jan Rękorajski wrote: > On Sat, 13 Apr 2019, Jakub Bogusz wrote: > > > On Fri, Apr 12, 2019 at 04:51:26PM +0200, adamg wrote: > > > commit ace10b5bf9b381123bdcfd9fd768164870cb8955 > > > Author: Adam Gołębiowski > > > Date: Fri Apr 12 16:51:18 2019 +0200 > > > > > > - updated to 1.70.0 > > > > Poprawiłem budowanie na x32, ale proponuję puścić najpierw aktualne icu > > (wersja obecnie w PLD ma już prawie 2 lata), żeby boost już był > > zbudowany z tą nową wersją. > > A ogarniesz potem to co trzeba przebudować? Z icu tak, kwestia czasu (dzisiaj mam chwilę, potem wyjeżdżam na dwa dni, potem będę miał dwa dni luźniejsze - powinno wystarczyć na zdecydowaną większość, żeby ew. pozostałości uzupełnić w kilka kolejnych wieczorów). adamg, pomożesz z zależnościami boosta, skoro ruszyłeś tę piramidę? ;) -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: [packages/boost] - updated to 1.70.0
On Fri, Apr 12, 2019 at 04:51:26PM +0200, adamg wrote: > commit ace10b5bf9b381123bdcfd9fd768164870cb8955 > Author: Adam Gołębiowski > Date: Fri Apr 12 16:51:18 2019 +0200 > > - updated to 1.70.0 Poprawiłem budowanie na x32, ale proponuję puścić najpierw aktualne icu (wersja obecnie w PLD ma już prawie 2 lata), żeby boost już był zbudowany z tą nową wersją. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: iso-codes 4.1-1
On Mon, Oct 29, 2018 at 01:30:39PM +0100, Łukasz Maśko wrote: > poldek:/all-avail> upgrade iso-codes-4.1-1.noarch > Przetwarzanie zależności... > iso-codes-3.74-1.noarch zostanie zastąpiony przez iso-codes-4.1-1.noarch > błąd: iso-codes-4.1-1.noarch: nie znaleziono wymaganego > /usr/share/locale/ce/LC_MESSAGES > błąd: iso-codes-4.1-1.noarch: nie znaleziono wymaganego > /usr/share/locale/chr/LC_MESSAGES > błąd: iso-codes-4.1-1.noarch: nie znaleziono wymaganego > /usr/share/locale/ht/LC_MESSAGES New glibc release (2.28-8) contains these directories. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: mupdf-1.14.0 a curl-libs-devel - po co?
On Sun, Oct 21, 2018 at 02:32:13PM +0200, Łukasz Maśko wrote: > poldek:/all-avail> upgrade mupdf-1.14.0-2.x86_64 > Przetwarzanie zależności... > mupdf-1.13.0-2.x86_64 zostanie zastąpiony przez mupdf-1.14.0-2.x86_64 > błąd: mupdf-1.14.0-2.x86_64: nie znaleziono wymaganego curl-libs-devel >= > 7.51.0 [...] > Po co ten -devel? Miało być curl-libs? Tak, literówka. Poprawione w -3. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: W jaki sposób rpm weryfikuje podpisy pakietów?
On Thu, Oct 18, 2018 at 04:05:25PM +0200, Adam Osuchowski wrote: > Tomasz Pala wrote: [...] > > Właśnie rpmrebuild miałem na myśli, oglądałem go kiedyś i o ile mnie > > pamięć nie myli, wyglądało to dość rozsądnie (łącznie z podpisywaniem > > powstałych pakietów), przy czym raczej podpiąć by to trzeba na poziomie > > poldka, więc w razie ręcznego operowania rpmem trzeba także ręcznie > > sobie zadbać o 'cofkę'. > > Z ciekawości odpaliłem: > > $ rpmrebuild bash > error: line 31: Only "noarch" sub-packages are supported: BuildArch: > x86_64 > error: Package has no %description: .x86_64 > /usr/lib/rpmrebuild/rpmrebuild.sh: ERROR: package 'bash' build failed > > Jak na początek to słabo... Nie wiem dlaczego subpakiety mogą być tylko > noarch. Czyli jak jest cośtam i cośtam-libs to już koniec, bo zapewne > -libs nie jest noarch. Tym błędem sypnął /usr/bin/rpmbuild czyli część > samego rpma. W kodzie źródłowym rpm4 i rpm5 ten fragment wygląda podobnie > więc jest spora szansa, że czwórka też się w ten sposób wysypie. Nie powinno być w ogóle znacznika "BuildArch: ..." innego niż noarch - nie nie jest noarch, jest w architekturze głównego pakietu. ".x86_64" też nie powinno się znaleźć w nazwie (pod)pakietu. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: W jaki sposób rpm weryfikuje podpisy pakietów?
On Tue, Oct 16, 2018 at 05:20:42PM +0200, Tomasz Pala wrote: > On Tue, Oct 16, 2018 at 16:09:39 +0200, Jakub Bogusz wrote: > > > Najboleśniejsza - poza portowaniem naszych łatek (tych, które mamy > > w rpm.spec, ale też tych, które weszły do źródeł rpm5) - może być > > migracja istniejących systemów. Format bazy może nie być zgodny... > > Trzeba wręcz przyjąć, że tak będzie. Nie znam ani db ani rpma na tyle, > żeby nawet oszacować stopień złożoności konwertera, ale równie ważne > pytanie brzmi, czy pod rpm.org będzie się dało zainstalować obecne nasze > pakiety z FTP-a? Osobiście mam jeszcze serwery z rpm-4.5-44.x86_64, ale > w URL widnieje tam rpm5.org, które być może miało celowo dorobioną > kompatybilność 'wstecz'. Obecny rpm.org wywodzi się z wersji 4.4.2 - RH nie uznawał linii 4.5. Formatu binarnego db nie znam, ale jak się użyje db_dump, to dostajemy zrzut szesnastkowy danych binarnych, jeden rekord per pakiet - format jest zdefiniowany w źródłach rpm-a i pytanie, na ile tu się rozjechało - w rpm.org na pewno doszły nowe pola, w rpm5 chyba też coś doszło. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: W jaki sposób rpm weryfikuje podpisy pakietów?
On Tue, Oct 16, 2018 at 01:23:41PM +0200, Jacek Konieczny wrote: [...] > > Ok, tylko musi być jakaś alternatywa. Jeżeli jesteśmy w stanie aktualne > > ficzery rpma 5 (albo przynajmniej te istotne, jak repackage) > > Mnie się nie wydaje, żeby akurat repackage było takie istotne. Już > ważniejsze jest to sprawdzanie podpisów, czy kompatybilność z pakietami > z innych źródeł. Oraz zgodność z zewnętrznymi narzędziami korzystającymi z librpm* - większość jest zgodna tylko z rpm.org; część daje się w miarę łatwo sportować, część używa jakichś nowszych API i szkoda czasu. Najboleśniejsza - poza portowaniem naszych łatek (tych, które mamy w rpm.spec, ale też tych, które weszły do źródeł rpm5) - może być migracja istniejących systemów. Format bazy może nie być zgodny... -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: [packages/gtef] - new (and the last release undef gtef name)
On Sun, Jul 16, 2017 at 09:24:13AM +0900, Jan Rękorajski wrote: > What's the point of adding this? It looks like waste of effort and > resources, especially that you also added package under new name. gtef has stable releases and is used by latexila from GNOME 3.24. tepl has only development prerelease (2.99.x) and will be used in the future. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: [packages/FHS] introduce /usr/{,local/}libexec directories
On Mon, Jul 10, 2017 at 04:57:30PM +0200, Tomasz Pala wrote: > On Mon, Jul 10, 2017 at 20:02:48 +0900, Jan Rękorajski wrote: > > > If you want me to keep this commit and directory then follow up by: > > > > a) updating rpm macros > > Yes, I was considering this point. Just wondering, what would break (in > theory: nothing should) and how to perform the validation. Didn't want > to do such change without more feedback, so now - if you already > summoned this subject, I'll wait a few days for any comments. > > I've already reviewed these and only one (re)definition needs to be > adjusted (in /usr/lib/rpm/macros.d/pld), remaining macros seem to be > cascading properly. Note that there are some inter-package consistency requirements. And just like some packages having hardcoded /usr/libexec, and "require hackery" to use libdir subdirectory, the others have hardcoded /usr/lib** for this purpose and would "require hackery" to use libexec. Without using libexec consequently, I don't see any profits (single place for internal binaries). > > b) cleaning up packages that have libexec redefined directly in specs > > > FHS states this directory is optional, and I do not care at all what GNU > > shamans think. This is not GNU/PLD, just PLD. > > I don't care about all this GNU/crap either, but using some Fedora > systems this directory was really convenient. My personal rationale is > 'follow the world', just to avoid being different than all the rest. On the other side, the "second half of the world" (Debian/Ubuntu) doesn't use libexec. >From minorities, e.g. Gentoo uses, Arch doesn't. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: 64-bitowe binarki w /usr/lib
On Mon, Jul 03, 2017 at 11:21:23PM +0200, Tomasz Pala wrote:
> On Mon, Jul 03, 2017 at 09:42:02 +0200, Adam Osuchowski wrote:
[...]
> > to zależy, a nie coś zmieniać. Ale ok, niech będzie, że jest w porządku,
> > nie będę kolejny raz tłumaczył o co mi chodzi. Przyjmuję do wiadomości
> > odpowiedź ,,bo tak'' i niech każdy pakiet ma to gdzie bądź.
>
> I znowu nie wiem skąd jakiś foch - już na samym początku wskazałem
> przecież, że właściwym miejscem dla tego typu plików jest libexec, więc
> jeżeli JUŻ ten temat porządkować, bo jak rozumiem o to Ci chodzi, to
> należy użyć tej właśnie lokalizacji.
>
> Jak dla mnie - po prostu wypierasz prawidłowe rozwiązanie problemu (libexec),
> bo nie przystaje do wizji, jaką miałeś na początku, przez co teraz
> całkiem ignorujesz udzieloną odpowiedź. Wcale nie brzmiała ona "bo tak",
> lecz "bo nie mamy libexec, w związku z czym jest jak jest". Bo żadna
> specyfikacja nie wskazuje, czy odpowiedniEJSZY jest /usr/lib czy
> /usr/lib64 - JEŻELI zadajesz takie pytanie, to odpowiedniejszy jest
> /usr/libexec. Chcesz porządku?
>
> 1. Na początek wprowadzić katalog do FHS.
> 2. Później poprawić pakiety, gdzie lokalizacja modułów określana jest
> wszelką ręczną rzeźbą (poprawki pewnie polegać będą na usuwaniu tej
> łataniny).
>
> 3. Na koniec przedyskutować przedefiniowanie w rpmie:
>
> -14: _libdir%{_exec_prefix}/%{_lib}
> -14: _libexecdir%{_exec_prefix}/%{_lib}
>
> - ale to już byłaby gruba zmiana, potencjalnie psująca rzeczy.
>
> Tutaj masz też odpowiedź, dlaczego raz jest tak, a raz inaczej - te
> pakiety, a raczej ich build systemy, które używają _libexecdir, lądują w
> /usr/lib64 (i one płynnie przeniosą się do libexec), natomiast te, gdzie
> lokalizację wskazujemy ręcznie (postaci "%{_prefix}/lib", gdy chcemy być
> arch-independent - zwracam uwagę, że właśnie BEZ używania makra %_lib),
> naturalnie się przestawią na ścieżkę arch-independent (bo libexec nie ma
> żadnych cyferek).
O ile pamiętam - wg FHS 3.0, jeżeli jest używane /usr/libexec, to ma być
używane konsekwentnie.
Jak dla mnie - przy multilibie jest to trzeci, dodatkowy katalog,
nadmiarowy.
Jak jest jakaś binarka wywoływana z poziomu biblioteki, to zwykle
i binarki przychodzą dwie wersje, więc trzeba je rozdzielić (/usr/lib
i /usr/lib64, jak wersje biblioteki).
/usr/libexec nadawałoby się dla prywatnych binarek uruchamianych
z ogólnodostępnych binarek, ale równie dobrze można skorzystać
z istniejących już lokalizacji i nie tworzyć nowego katalogu.
--
Jakub Boguszhttp://qboosh.pl/
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: dnssec-tools package broken by glibc
On Sat, Jul 01, 2017 at 11:51:46AM +0200, Jan Rękorajski wrote: > dnssec-tools does not build because the code it relies on was removed > from glibc. Build fixed, thanks to Arch Linux. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: libmozsandbox.so w firefoksie
On Wed, May 17, 2017 at 01:15:30PM +0200, Adam Osuchowski wrote:
> Czemu firefox ze źródeł wymaga binarnego mozilla-firefox-bin skoro
> oba zawierają libmozsandbox.so, a co więcej, firefox używa swojego,
> a nie tego z mozilla-firefox-bin?
>
>
> firefox-53.0-2.x86_64: required "libmozsandbox.so()(64bit)" is provided by
> the following packages:
> a) mozilla-firefox-bin-53.0-1.x86_64
> b) thunderbird-52.0.1-3.x86_64
> Which one do you want to install ('Q' to abort)?
> [mozilla-firefox-bin-53.0-1.x86_64]
Powinno być poprawione w 53.0.2.
Swoją drogą mozilla-firefox-bin i thunderbird nie powinny mieć własnej
prywatnej wersji w Provides.
--
Jakub Boguszhttp://qboosh.pl/
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: [packages/glm-devel] new package
On Tue, Feb 23, 2016 at 03:35:19PM +0100, Jacek Konieczny wrote: > On 2016-02-23 15:22, Jakub Bogusz wrote: > >On Tue, Feb 23, 2016 at 03:10:56PM +0100, jajcus wrote: > >>commit 91cfbb18080f8b7f88dbf6609f78c25f9dde85ef > >>Author: Jacek Konieczny <j.koniec...@eggsoft.pl> > >>Date: Tue Feb 23 15:10:20 2016 +0100 > >> > >> new package > >> > >> glm-devel.spec | 66 > >> ++ > > > >GLM.spec ? > > Źródłowa paczka jest glm-*, używane jest przez '#include ', w > innych dystrybucjach też małymi literami (libglm-dev w Ubuntu)??? Jeszcze > jakby nam zostało w repozytorium stare 'glm', do niczego nie używane, to > by było jeszcze większe zamieszanie. > > Najchętniej bym to jako 'glm' spakował, ale najwyraźniej, nawet po > 'odsunięciu' starego pakietu o takiej nazwie, to się u nas nie da. Chodzi mi o to, że GLM.spec już jest, i to od dłuższego czasu. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: dbus-libs-1.10.6-1.i686 + multilib = problem z libgcrypt
On Sun, Jan 17, 2016 at 07:02:13PM +0100, Łukasz Maśko wrote: > W chwili obecnej nie ma możliwości poprawnej instalacji dbus-libs-1.10.6-1 w > systemie z multilib-em (wersja dla x86-64 już jest zainstalowana, problemem > jest wyrównanie wersji dla i686): > > poldek:/all-avail> upgrade dbus-libs-1.10.6-1.i686 > Przetwarzanie zależności... > dbus-libs-1.8.20-2.i686 zostanie zastąpiony przez dbus-libs-1.10.6-1.i686 > dbus-libs-1.10.6-1.i686 zaznaczył systemd-libs-221-11.i686 (wł. > libsystemd.so.0) > systemd-libs-221-11.i686 zaznaczył attr-2.4.47-2.i686 (wł. libattr.so.1) > systemd-libs-221-11.i686 zaznaczył libgcrypt-1.6.4-1.i686 (wł. > libgcrypt.so.20) > libgcrypt-1.6.4-1.i686 zaznaczył libgpg-error-1.21-1.i686 (wł. libgpg- > error.so.0) > systemd-libs-221-11.i686 zaznaczył lz4-libs-r131-4.i686 (wł. liblz4.so.1) > Jest 6 pakietów do instalacji (5 zaznaczonych pośrednio), 1 do usunięcia: > I dbus-libs-1.10.6-1.i686 > D attr-2.4.47-2.i686 libgcrypt-1.6.4-1.i686 libgpg-error-1.21-1.i686 lz4- > libs-r131-4.i686 systemd-libs-221-11.i686 > R dbus-libs-1.8.20-2.i686 > This operation will use 2.7MB of disk space. > Potrzeba pobrać 1.0MB archiwów (485.6KB do pobrania). > > Pobieranie [1/2] th-i686::systemd-libs-221-11.i686.rpm... > .. 100.0% [326.0K (326.0K/s)] > Pobieranie [2/2] th-i686::dbus-libs-1.10.6-1.i686.rpm... > .. 100.0% [159.6K (135.8K/s)] > Uruchamianie sudo /usr/lib/poldek/pm-command.sh --upgrade -vh --root / -- > define _check_dirname_deps 1... > Przygotowywanie... ### [100%] > error: Problemy z instalacją/usuwaniem: > plik /usr/share/man/man1/hmac256.1.gz z instalacji > libgcrypt-1.6.4-1.i686 jest w konflikcie z plikiem z pakietu > libgcrypt-1.6.4-1.x86_64 > Wystąpiły błędy podczas instalacji > > Czy dopuszczamy podział libgcrypt na podpakiety tak, żeby liby były > rzeczywiście osobno, a dodatkowe binarki plus rzeczy mogące przeszkadzać (jak > manual w tym przypadku) osobno? A może jest na to jakiś inny sposób? Można by wydzielić -tools, ale jeśli jedynym problemem jest ten plik - to czemu on się różni między architekturami? Pliki w /usr/share nie powinny się różnić. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: dbus-1.10.6-1.x86_64 się wywala, downgrade do 1.8.20-2.x86_64 pomaga. (version LIBDBUS_PRIVATE_1.10.6 not defined in file libdbus-1.so.3 with link time reference)
On Sun, Jan 17, 2016 at 11:37:43AM +0100, Mateusz Korniak wrote: > dbus-1.10.6-1.x86_64 się wywala: > > > Jan 17 11:20:39 host7 systemd[1]: Started D-Bus System Message Bus. > Jan 17 11:20:39 host7 systemd[1]: Failed to register Manager vtable: File > exists > Jan 17 11:20:39 host7 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 > ses=4294967295 msg='unit=dbus comm="systemd" exe="/lib/systemd/systemd" > hostname=? addr=? terminal=? res=success' > Jan 17 11:20:39 host7 systemd[1]: Failed to set up API bus: File exists > Jan 17 11:20:39 host7 dbus-daemon[849]: /usr/bin/dbus-daemon: > /lib64/libdbus-1.so.3: no version information available (required by > /usr/bin/dbus-daemon) "/lib64/libdbus-1.so.3"? A nie /usr/lib64, jak w pakiecie? Masz tam jakąś starszą kopię biblioteki? -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: [packages/glibc] - rel 1.1; glibc-locale_fixes.patch causes asserts in apps (our locale crap patches are pure evil!)
On Thu, Aug 06, 2015 at 10:23:49AM +0200, arekm wrote: commit 2395b6fc1fbde35a7f66da5530f99af15968d94f Author: Arkadiusz Miśkiewicz ar...@maven.pl Date: Thu Aug 6 10:23:43 2015 +0200 - rel 1.1; glibc-locale_fixes.patch causes asserts in apps (our locale crap patches are pure evil!) Could you provide more information about these asserts? -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: i486 removal from Th
On Sat, Feb 21, 2015 at 11:17:47AM +0100, Jan Rękorajski wrote: Hi, I will remove i486 from Th on 28 February 2015. From pld-linux.org: Growing number of packages that either do not build for i486 or are severly crippled (like IcedTea or programs requiring atomic operations) with loss of users of this architecture caused us to finally abandon it. To be fair it should be said explicitly, that for Th this also means drop of support for i586 class CPUs and some degraded i686 chips lacking cmov instructions support (there were such VIA chips in mid 200x years, probably rare to find now). -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: cmake
On Sun, Feb 15, 2015 at 10:12:25AM +0100, Bartek Szady wrote:
Cześć
Pliki z %{_datadir}/cmake/Help są używane przez konsolowe cmake oraz
przez kdevelop.
Przerzucić je do głównego pakietu czy zrobić nowy podpakiet help?
IMO do głównego.
--
Jakub Boguszhttp://qboosh.pl/
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: netatalk - ktoś to w ogóle testował?
On Tue, Dec 23, 2014 at 11:33:24AM +0100, Jacek Osiecki wrote: Witam, Zachciało mi się dla makówki time machine zrobić... Jeden z obowiązkowych punktów to netatalk. Zainstalowałem... i to by było na tyle ;) Czy ktoś kto wypuszczał paczkę - sprawdzał czy w ogóle cokolwiek się uruchamia? Mam wrażenie, że skrypt pochodzi z wcześniejszej wersji netatalk i nie ma wiele wspólnego z tym co jest teraz... Na to wygląda. [root@serwer ~]# /etc/rc.d/init.d/atalk start Starting atalkd service .. [ FAIL ] execvp: No such file or directory Registering serwer:Workstation: .. [ FAIL ] execvp: No such file or directory Registering serwer:netatalk: .. [ FAIL ] execvp: No such file or directory Starting papd service .. [ FAIL ] execvp: No such file or directory Starting timelord service .. [ FAIL ] execvp: No such file or directory Starting afpd service .. [ FAIL ] afpd: invalid option -- 'U' afpd: invalid option -- 'g' afpd: invalid option -- 'c' afpd: invalid option -- 'n' Usage:afpd [-d] [-F configfile] afpd -h|-v|-V [root@serwer ~]# W init.d/atalk widzę odwołania do binarek atalkd, timelord, papd - których nie ma w żadnym pakiecie... To było w netatalk 3, obsługującym stary protokół AppleTalk. W netatalk = 3.0 jest zupełnie inaczej. Sprawdź 3.1.7-2. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Zepsuty bind 9.10.x ?
On Thu, Oct 09, 2014 at 04:42:08PM +0200, Pepe wrote: Witam. Wczoraj odkryłem że nasz bind w wersji 9.10.x nie potrafi rozwiązać nazwy download.adobe.com, konkretnie zwracany jest błąd NXDOMAIN. Google nie pomogły, dopiero downgrade do 9.9.5-1 rozwiązał problem. Uhm... $ host -t any download.adobe.com download.adobe.com is an alias for download.wip4.adobe.com. $ host -t ns wip4.adobe.com wip4.adobe.com name server sj1gtm001.adobe.com. wip4.adobe.com name server du1gtm001.adobe.com. wip4.adobe.com name server da1gtm001.adobe.com. $ host -t any download.wip4.adobe.com. sj1gtm001.adobe.com. Using domain server: Name: sj1gtm001.adobe.com. Address: 192.150.19.247#53 Aliases: Host download.wip4.adobe.com. not found: 3(NXDOMAIN) $ host -t any download.wip4.adobe.com. du1gtm001.adobe.com. Using domain server: Name: du1gtm001.adobe.com. Address: 193.104.215.247#53 Aliases: Host download.wip4.adobe.com. not found: 3(NXDOMAIN) $ host -t any download.wip4.adobe.com. da1gtm001.adobe.com. Using domain server: Name: da1gtm001.adobe.com. Address: 192.150.16.247#53 Aliases: Host download.wip4.adobe.com. not found: 3(NXDOMAIN) Czyli tak jakby coś zepsuli. host jest w wersji bind-utils-9.8.5.P2-1. Przy użyciu niektórych zewnętrznych DNS-ów działa - kwestia cache? -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: v4l-utils-qt wymaga QtCore-devel?!
On Mon, Jan 20, 2014 at 01:58:46PM +0100, Łukasz Maśko wrote: poldek:/all-avail install v4l-utils-qt-1.0.0-1.i686 Przetwarzanie zależności... v4l-utils-qt-1.0.0-1.i686 zaznaczył QtCore-devel-4.8.5-5.i686 (wł. QtCore- devel = 4.4) [...] Poprawione w 1.0.1-1. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Czy cmake zostawia po sobie jakiś log?
On Tue, Dec 17, 2013 at 04:16:51PM +0100, Łukasz Maśko wrote: Próbuję dojść, dlaczego kde4-kdepim dla wersji 4.11.4 nie chce mi zbudować bibliotek opartych na strigi. Konkretnie chodzi mi o pliki, które były w 4.10.x, a teraz nie ma: /usr/lib/strigi/strigiea_ctg.so /usr/lib/strigi/strigiea_ics.so /usr/lib/strigi/strigiea_vcf.so /usr/lib/strigi/strigiea_mail.so W źródłach odpowiedni podkatalog jest (strigi-analyzer), ale na pierwszy rzut oka wygląda to tak, jakby przy samej konfiguracji na początku coś nie grało z wykrywaniem strigi i potem po prostu nie buduje tego kawałka. Jak można to zweryfikować? Samo strigi (+devel) mam. Czasami czegoś można się doszukać w katalogu CMakeFiles, ale ogólnie słabo z tym. Autoconf jest pod tym względem przyjemniejszy i bardziej przewidywalny. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Problem z libvirt
On Wed, Jul 17, 2013 at 10:34:58AM +0200, Grzegorz Pietrzak wrote: Dnia 2013-07-10, śro o godzinie 13:51 +0200, Grzegorz Pietrzak pisze: Widzę, że jest kolejna wersja libvirt: libvirt-1.0.6-1.x86_64, ale niestety jest to kolejna wersja która nie chce ze mną współpracować... odinstaluj libnl1 i powinno zadziałać No faktycznie zadziała, ale to działanie mnie nie do końca interesuje... poldek:/all-avail uninstall libnl1-1.1-3.x86_64 -t zazn. libnl1-1.1-3.x86_64 Przetwarzanie zależności... libnl1-1.1-3.x86_64 zaznacza libpcap-1.3.0-1.x86_64 (wymaga libnl.so.1()(64bit)) libpcap-1.3.0-1.x86_64 zaznacza libvirt-1.0.6-1.x86_64 (wymaga libpcap = 1.0.0) libpcap-1.3.0-1.x86_64 zaznacza libvirt-daemon-1.0.6-1.x86_64 (wymaga libpcap.so.1()(64bit)) libvirt-daemon-1.0.6-1.x86_64 zaznacza libvirt-daemon-qemu-1.0.6-1.x86_64 (wymaga libvirt-daemon = 1.0.6-1) libvirt-1.0.6-1.x86_64 zaznacza libvirt-client-1.0.6-1.x86_64 (wymaga libvirt-lxc.so.0()(64bit)) libvirt-1.0.6-1.x86_64 zaznacza python-libvirt-1.0.6-1.x86_64 (wymaga libvirt = 1.0.6-1) Jest 7 pakietów do usunięcia (6 zaznaczonych pośrednio): R libnl1-1.1-3.x86_64 D libpcap-1.3.0-1.x86_64 libvirt-1.0.6-1.x86_64 libvirt-client-1.0.6-1.x86_64 libvirt-daemon-1.0.6-1.x86_64 libvirt-daemon-qemu-1.0.6-1.x86_64 D python-libvirt-1.0.6-1.x86_64 This operation will free 25.8MB of disk space. To rozwiązaniem może być uaktualnienie libpcap do wersji 1.4.0 zbudowanej z libnl 3. Problem mógł wynikać z konfliktu wersji libnl. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Problem z libvirt
On Wed, Jul 10, 2013 at 01:51:24PM +0200, Grzegorz Pietrzak wrote: Widzę, że jest kolejna wersja libvirt: libvirt-1.0.6-1.x86_64, ale niestety jest to kolejna wersja która nie chce ze mną współpracować... :/ O co tu chodzi?!?... Która wersja libnl? Czy nie jest uszkodzona (rpm -V libnl)? Wygląda na jakiś lewy moduł w /usr/lib*/libnl - czy masz w tym drzewie jakieś moduły spoza pakietu libnl? -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: libjpeg i zależności
On Wed, May 22, 2013 at 08:19:38AM +0200, Tomasz Pala wrote: On Tue, May 21, 2013 at 13:58:48 +0200, Jan Rękorajski wrote: error: libjpeg-turbo-1.2.1-1.i686 conflicts with libjpeg-9-1.i686 Zainstaluj libjpeg-turbo, libjpeg zmienił soname a my i tak wolimy turbo. A jak ktoś nie ma SSE? A jak ktoś potrzebuje libjpeg.so.9? libjpeg-turbo powinien działać bez SSE; co najwyżej może być kwestia obsługi nowego formatu - powinno być dostępne libjpeg.so.8 z IJG jako libjpeg8. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: [packages/libprelude] - updated to 1.0.1 - fix building with recent libc - fix building of python binding
On Fri, May 17, 2013 at 03:48:14PM +0200, hawk wrote:
License: GPL v2 or commercial
Group: Libraries
-#Source0Download:
http://www.prelude-ids.com/developpement/telechargement/index.html
-Source0:
http://www.prelude-ids.com/download/releases/libprelude/%{name}-%{version}.tar.gz
-# Source0-md5: a5bb76538d240e5fac5f6ab0b7fabfe5
+# https://www.prelude-ids.org/projects/prelude/files
+Source0:
https://www.prelude-ids.org/attachments/download/241/%{name}-%{version}.tar.gz
+# Source0-md5: dce1ea9f82cf436830567894e7ee622f
Patch0: %{name}-libtool.patch
Patch1: %{name}-ruby.patch
+Patch2: %{name}-gnutls.patch
+Patch3: %{name}-gets.patch
+Patch4: %{name}-python.patch
URL: http://www.prelude-ids.com/
BuildRequires: autoconf = 2.59
BuildRequires: automake
Error: some source, patch or icon files not stored in PLD repo.
(libprelude-gnutls.patch)
@@ -37,6 +40,7 @@ BuildRequires: rpm-pythonprov
BuildRequires: rpmbuild(macros) = 1.219
%{?with_ruby:BuildRequires: ruby-devel = 1.9}
BuildRequires: sed = 4.0
+BuildRequires: trousers-devel
%{?with_perl:BuildRequires: swig-perl}
%{?with_python:BuildRequires: swig-python}
%{?with_ruby:BuildRequires: swig-ruby}
A to pewnie zależność gnutls. W źródłach libprelude nie ma nic
o trousers ani tspi.
--
Jakub Boguszhttp://qboosh.pl/
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: perl packages duplicating main functionality
On Thu, May 09, 2013 at 01:54:31PM +0200, Jan Rękorajski wrote: Hi, Is there any real reason why we have a lot of perl packages that duplicate modules/functionality of main perl distribution? With perl 5.16 they are probably not needed. But some packages require newer versions than exist in base perl 5.12 distribution. I'm asking because I'm going to remove all of those from Th, because they cause build problems and incompatibilities (vim vs perl-ExtUtils-ParseXS, apache-mod_perl vs perl-Module-CoreList). Problematic modules could be removed after checking BR list for versioned dependencies with versions newer than in perl provided in Th. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Na co pokazuje /bin/sh na builderach? (czyli o co chodzi rpm-owi)
On Sun, Apr 07, 2013 at 03:50:17PM +0200, Łukasz Maśko wrote: Dnia niedziela, 7 kwietnia 2013 11:12:49 Jan Rękorajski pisze: [...] Wynika ono z faktu, że u mnie pokazuje na ksh i (chyba) przez to nie mogę zbudować lokalnie żadnego pakietu (chociaż na builderze się buduje). Pewnie masz jeszcze pdksh i stąd problem. Dokładnie tak. Czy nie należałoby jakoś (nie wiem jak) wymusić przez powiedzmy rpm-build-macros, żeby /bin/sh pokazywało na ten a nie inny shell (tudzież może łatwiej wykluczyć)? Tak tylko pytam :-) Obecna wersja makr (git master) działa też z pdksh. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Patch dla mfs.spec
On Thu, Mar 28, 2013 at 01:00:38PM +0100, Paweł Kośka wrote: W załączniku dla kolejne patche dla mfs.spec Ten pierwszy to nie wiem jaki plan miał developer. Wspomina że wydał wersję 1.6.27 a plik wyjątkowo (w porównaniu do poprzednich wersji) zwie się 1.6.27-1 Nie wiem. Wcześniej jako -1 były wersje z małymi (lecz istotnymi) poprawkami, ale teraz to chyba pierwsza opublikowana. python-modules OK, ale pydoc do czego? Dodałem jeszcze parę poprawek od siebie i skrypt startowy mfscgiserv (do przetestowania). Potestuj - jeśli skrypty init z pakietu działają, to puszczę jako release 1. Aha - poprawki na operacje na pliku usuniętym (ala poldek) w tej wersji jeszcze nie ma. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: STBR z poziomu git-a ?
On Thu, Mar 28, 2013 at 03:10:47PM +0100, Paweł Gołaszewski wrote: On Thu, 28 Mar 2013, Jacek Konieczny wrote: Myślałem o osobnym repo, które po commitnięciu jakiejśtam linijki hookami odpala stary make-request.sh. A czemu nie normalnie, przez gitolite Admin Defined Commands? Byłoby: ssh g...@git.pld-linux.org stbr pakiet Bo na prostsze rozwiązanie trudniej wpaść? ;-) No to został jeszcze problem jak informować o błędnym zleceniu. Bo buildery wysyłają informację na maila. Wysyłają też to na publiczną listę pld-logs..., więc jak ktoś będzie chciał, to dostanie informacje. No bez przesady. Chciałbym mieć powiadomienie o swoim zleceniu, ale żeby już dostawać z tej okazji _wszystkie_ to lekka perwersja... Ano. Ale adresy są (w CVSROOT/users czy jakoś tak) - najwyżej powiadomienie przyjdzie na ten adres, a nie podany w zleceniu. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Patch dla mfs.spec
On Thu, Mar 14, 2013 at 12:22:18AM +0100, Bartlomiej Zimon wrote: Dnia 12 marca 2013 17:09 Jakub Bogusz qbo...@pld-linux.org napisał(a): On Mon, Mar 11, 2013 at 08:33:17PM +0100, Paweł Kośka wrote: W dniu 11 marca 2013 18:10 użytkownik Bartlomiej Zimon uz...@o2.pl napisał: No to fajnie, poldek naprawiony w th-test lezy, a my czekamy na feedback, czy juz jest ok :) Na pewno jest inaczej ;) upgrade zrobiony [root@pavetta services]# poldek --version poldek 0.30.0 (rc) Copyright (C) 2000-2007 Pawel A. Gajda m...@pld-linux.org This program may be freely redistributed under the terms of the GNU GPL v2 [root@pavetta services]# rpm -qa | grep poldek poldek-libs-0.30.0-1.rc7.1.x86_64 poldek-0.30.0-1.rc7.1.x86_64 No i teraz jeszcze raz testujemy: [root@pavetta services]# mfsmount /home/services/PLD/ -d -o mfsdebug -H 172.16.20.164 -S / http://pastebin.com/XFgXWpyq [root@pavetta services]# strace -o /tmp/test9.log poldek -v --noask -s PLD/mfstest/RPMS/ --mkidxz http://pastebin.com/CY3FVMTA I drugi test, montowanie podkatalogu [root@pavetta services]# mfsmount /home/services/PLD/ -d -o mfsdebug -H 172.16.20.164 -S /mfstest http://pastebin.com/y2rjPytr [root@pavetta services]# strace -o /tmp/test10.log poldek -v --noask -s PLD/RPMS/ --mkidxz http://pastebin.com/WWBUWfBa No to dalej coś źle z poldkiem, bo w logu jest dwa razy EPERM, a błąd zignorowany - brak(?) informacji na stderr, kod wyjścia 0. Błąd trudny do powtórzenia w normalnych warunkach (niepowodzenie odczytu po wcześniejszym udanym zapisie), ale jednak. Dziwna sprawa, pomijam fakt ze nigdzie w kodzie poldka nie sprawdzane jest czy zamykanie bazy tndb skonczylo sie sukcesem poza funkcjami test_xxx.c ;) Wydaje sie ze jest jednak jakis problem z tym systemem plikow. Nie jest to jakis bug w systemie plikow zwiazany z userem/grupa/itd.? Problem po stronie MFS-a udało się zidentyfikować (kluczowe w tym było, że plik zaraz po utworzeniu i otwarciu jest usuwany, dalsze operacje są już na pliku trzymanym tylko przez deskryptor - nie działało to, jeśli zamontowana była tylko część drzewa systemu plików). Ma być poprawione w którejś następnej wersji. Natomiast nie sprawdzanie statusu odczytu, nawet jeśli możliwość niepowodzenia jest mało prawdopodobna, jest błędem w poldku. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Patch dla mfs.spec
On Mon, Mar 11, 2013 at 08:33:17PM +0100, Paweł Kośka wrote: W dniu 11 marca 2013 18:10 użytkownik Bartlomiej Zimon uz...@o2.pl napisał: No to fajnie, poldek naprawiony w th-test lezy, a my czekamy na feedback, czy juz jest ok :) Na pewno jest inaczej ;) upgrade zrobiony [root@pavetta services]# poldek --version poldek 0.30.0 (rc) Copyright (C) 2000-2007 Pawel A. Gajda m...@pld-linux.org This program may be freely redistributed under the terms of the GNU GPL v2 [root@pavetta services]# rpm -qa | grep poldek poldek-libs-0.30.0-1.rc7.1.x86_64 poldek-0.30.0-1.rc7.1.x86_64 No i teraz jeszcze raz testujemy: [root@pavetta services]# mfsmount /home/services/PLD/ -d -o mfsdebug -H 172.16.20.164 -S / http://pastebin.com/XFgXWpyq [root@pavetta services]# strace -o /tmp/test9.log poldek -v --noask -s PLD/mfstest/RPMS/ --mkidxz http://pastebin.com/CY3FVMTA I drugi test, montowanie podkatalogu [root@pavetta services]# mfsmount /home/services/PLD/ -d -o mfsdebug -H 172.16.20.164 -S /mfstest http://pastebin.com/y2rjPytr [root@pavetta services]# strace -o /tmp/test10.log poldek -v --noask -s PLD/RPMS/ --mkidxz http://pastebin.com/WWBUWfBa No to dalej coś źle z poldkiem, bo w logu jest dwa razy EPERM, a błąd zignorowany - brak(?) informacji na stderr, kod wyjścia 0. Błąd trudny do powtórzenia w normalnych warunkach (niepowodzenie odczytu po wcześniejszym udanym zapisie), ale jednak. Co do samego problemu z MFS-em - nie udało mi się powtórzyć. Może trochę różnią się warunki... Mógłbyś dać dostęp do tego swojego systemu (master + mount)? Kontakt na maila. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Patch dla mfs.spec
On Wed, Mar 06, 2013 at 10:38:06PM +0100, Bartlomiej Zimon wrote: Dnia 5 marca 2013 10:01 Paweł Kośka pa...@viop.pl napisał(a): W dniu 5 marca 2013 07:02 użytkownik Jakub Bogusz qbo...@pld-linux.org napisał: On Mon, Mar 04, 2013 at 02:14:45PM +0100, Paweł Kośka wrote: wiesza się na: [root@pavetta pld]# LANG=C poldek -v --noask -s packages/RPMS/ --mkidxz Creating pndir index of /home/services/PLD/pld/packages/RPMS/ (type=dir)... Loading [dir]/home/services/PLD/pld/packages/RPMS/... Writing /home/services/PLD/pld/packages/RPMS/packages.ndir.gz... Jak to wiesza? Co pokazuje strace? Przy EPERM/EACCESS poldek nie powinien się wieszać, tylko zakończyć działanie. Jeśli jest inaczej, to błąd. Mozna to jakos zreprodukowac bez zabawy w mfs ? W strace wygląda to tak: [...] 935. write(1, Writing /home/services/PLD/RPMS/..., 52) = 52 936. stat(/home/services/PLD/RPMS/packages.ndir.gz, 0x7fff804cb1a0) = -1 ENOENT (No such file or directory) 937. open(/home/services/PLD/RPMS/packages.ndir.gz.tmpTaxCCA, O_RDWR|O_CREAT|O_EXCL, 0600) = 3 938. fchmod(3, 0600) = 0 939. rmdir(/home/services/PLD/RPMS/packages.ndir.gz.tmpTaxCCA) = -1 ENOTDIR (Not a directory) ^ po co to BTW??? później też powtarza się kilka razy 940. unlink(/home/services/PLD/RPMS/packages.ndir.gz.tmpTaxCCA) = 0 [...] 1198. dup(3) = 6 [...] 1208. open(/home/services/PLD/RPMS/packages.ndir.gz, O_RDWR|O_CREAT|O_TRUNC, 0666) = 3 [...] 1213. dup(3) = 7 [...] 1219. lseek(6, 0, SEEK_SET) = 0 1220. lseek(7, 0, SEEK_END) = 68 1221. read(6, 0x7fff804c70c0, 16384) = -1 EPERM (Operation not permitted) 1222. write(7, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 4294967295) = -1 EFAULT (Bad address) 1223. read(6, 0x7fff804c70c0, 16384) = -1 EPERM (Operation not permitted) 1224. write(7, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 4294967295) = -1 EFAULT (Bad address) [...i tak do ...] Czyli dwa błędy, albo nawet trzy błędy: - brak sprawdzenia statusu read() - użycie informacji o błędzie (-1) jako liczby bajtów do zapisu - brak sprawdzenia statusu write() -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Patch dla mfs.spec
On Tue, Mar 05, 2013 at 10:01:12AM +0100, Paweł Kośka wrote: W dniu 5 marca 2013 07:02 użytkownik Jakub Bogusz qbo...@pld-linux.org napisał: On Mon, Mar 04, 2013 at 02:14:45PM +0100, Paweł Kośka wrote: wiesza się na: [root@pavetta pld]# LANG=C poldek -v --noask -s packages/RPMS/ --mkidxz Creating pndir index of /home/services/PLD/pld/packages/RPMS/ (type=dir)... Loading [dir]/home/services/PLD/pld/packages/RPMS/... Writing /home/services/PLD/pld/packages/RPMS/packages.ndir.gz... Jak to wiesza? Co pokazuje strace? Przy EPERM/EACCESS poldek nie powinien się wieszać, tylko zakończyć działanie. Jeśli jest inaczej, to błąd. To spróbuje jeszcze raz opisać, bardziej szczegółowo. mfsmaster jest Arch Linux Która wersja mfsmastera? klient i chunkservery na PLD. Klient 1.6.26? /etc/mfs/mfsexports.cfg * / rw,alldirs,maproot=0 * . rw OK, z alldirs powinno obejmować też podkatalogi. Mój zestaw testowych RPMów [root@pavetta services]# ls -lah RPMS/ total 1.8M drwxr-xr-x 2 root root 360 Mar 5 09:24 . drwxr-xr-x 4 root root 96 Mar 3 12:59 .. -rw-r--r-- 1 root root 40K Mar 3 12:24 mfs-cgi-1.6.26-0.4.x86_64.rpm -rw-r--r-- 1 root root 109K Mar 3 12:24 mfs-chunkserver-1.6.26-0.4.x86_64.rpm -rw-r--r-- 1 root root 119K Mar 3 12:24 mfs-client-1.6.26-0.4.x86_64.rpm -rw-r--r-- 1 root root 1.2M Mar 3 12:24 mfs-debuginfo-1.6.26-0.4.x86_64.rpm -rw-r--r-- 1 root root 228K Mar 3 12:24 mfs-master-1.6.26-0.4.x86_64.rpm -rw-r--r-- 1 root root 42K Mar 3 12:24 mfs-metalogger-1.6.26-0.4.x86_64.rpm montuje zasób mfsmount /home/services/PLD/ -d -H 172.16.20.164 -S / wrzuciłem te rpmy [root@pavetta services]# cp -a RPMS/ PLD/ no i poldek [root@pavetta services]# strace -o /tmp/test1.log poldek -v --noask -s PLD/RPMS/ --mkidxz Creating pndir index of /home/services/PLD/RPMS/ (type=dir)... Loading [dir]/home/services/PLD/RPMS/... Writing /home/services/PLD/RPMS/packages.ndir.gz... [root@pavetta services]# Wszystko przebiegło OK, więc druga próba: Tworze testowy katalog: [root@pavetta services]# mkdir PLD/mfstest [root@pavetta services]# ls -lah PLD/ total 2.5K drwxr-xr-x 10 root root 34 Mar 5 09:34 . drwxr-xr-x 4 root root 96 Mar 3 12:59 .. drwxr-xr-x 2 root root 0 Mar 5 09:31 RPMS drwxr-xr-x 2 root root 0 Mar 5 09:34 mfstest drwxr-xr-x 5 1000 users 9 Oct 31 14:22 pawelk-test drwxrwxr-x 3 1000 users 0 Oct 30 12:26 tescik drwxr-xr-x 2 root root 4 Oct 30 16:22 test drwxr-xr-x 2 root root 12 Feb 3 21:52 test2 drwxr-xr-x 2 root root 8 Feb 2 18:32 test3 drwxr-xr-x 4 root root 0 Mar 5 09:28 ttest4 odmontowuje zasób i montuje do tego testowego katalogu [root@pavetta ~]# mfsmount /home/services/PLD/ -d -H 172.16.20.164 -S /mfstest/ i od początku: [root@pavetta services]# cp -a RPMS/ PLD/ [root@pavetta services]# strace -o /tmp/test2.log poldek -v --noask -s PLD/RPMS/ --mkidxz Creating pndir index of /home/services/PLD/RPMS/ (type=dir)... Loading [dir]/home/services/PLD/RPMS/... Writing /home/services/PLD/RPMS/packages.ndir.gz... ^C^C [root@pavetta services]# Log z mfsmount: http://pastebin.com/g4Ngsgdm Dodaj jeszcze -o mfsdebug do opcji mfsmounta. Sprawdź jeszcze z -S /mfstest zamiast -S /mfstest/ (ale to raczej nie powinno robić różnicy). strace z tego niedziałającego poldka: http://pastebin.com/TJATYtXc [...] Jakieś sugestie? To wina PLD, poldka, czy mfs? Wieszanie się poldka jest winą poldka (powinien się zakończyć z komunikatem o błędzie). Co do samego EPERM, to coś dziwnego. Nie udało mi się powtórzyć (mfsmaster 1.6.26, mfsmount 1.6.26 lub 1.6.27, program powtarzający operacje analogiczne do poldka). -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Patch dla mfs.spec
On Mon, Mar 04, 2013 at 02:14:45PM +0100, Paweł Kośka wrote: W dniu 3 marca 2013 14:31 użytkownik Jakub Bogusz qbo...@pld-linux.org napisał: Przygotowałem wstępne skrypty - nie testowane, więc mogą być jakieś błędy. Jeżeli masz przygotowaną instalację to sprawdź. Dzięki, przetestuję jak będę robił reinstalację mojego testowego środowiska. Na razie mi nie współpracuje z poldkiem ;) Tylko nie wiem, czy to nie nie wina moich prób, testów. Nie mogę zrobić poldek -v --noask -s packages/RPMS/ --mkidxz wiesza się na: [root@pavetta pld]# LANG=C poldek -v --noask -s packages/RPMS/ --mkidxz Creating pndir index of /home/services/PLD/pld/packages/RPMS/ (type=dir)... Loading [dir]/home/services/PLD/pld/packages/RPMS/... Writing /home/services/PLD/pld/packages/RPMS/packages.ndir.gz... Jak to wiesza? Co pokazuje strace? Przy EPERM/EACCESS poldek nie powinien się wieszać, tylko zakończyć działanie. Jeśli jest inaczej, to błąd. a mfsmount pokazuje: unique: 12028, opcode: GETATTR (3), nodeid: 467, insize: 56 unique: 12028, error: -1 (Operation not permitted), outsize: 16 unique: 12029, opcode: GETATTR (3), nodeid: 467, insize: 56 unique: 12029, error: -1 (Operation not permitted), outsize: 16 unique: 12030, opcode: GETATTR (3), nodeid: 467, insize: 56 unique: 12030, error: -1 (Operation not permitted), outsize: 16 Co ciekawe jak zamontuje: # mfsmount /home/services/PLD/ -f -n -H 172.16.20.164 -S / to jest OK Ale jak już jako: # mfsmount /home/services/PLD/ -f -n -H 172.16.20.164 -S /PLD/ to nie działa ;) W tym drugim przypadku możesz normalnie zapisywać pliki w zamontowanym katalogu (w szczególności w /home/services/PLD/pld/packages/RPMS/)? Czy mfsexports dopuszcza zapis dla /PLD? (nie pamiętam, czy wpis dla / działa implicite na podkatalogi, czy nie) Czy bez opcji -n działa? -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Patch dla mfs.spec
On Sun, Mar 03, 2013 at 11:56:24AM +0100, Paweł Kośka wrote: I jeszcze jeden malutki. BR dopisane. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Patch dla mfs.spec
On Thu, Feb 21, 2013 at 01:21:08PM +0100, Paweł Kośka wrote: Hej, Czy mógłby ktoś spojrzeć na ten patch? Czy mniej więcej o taki skrypt startowy chodzi? Lepiej używać funkcji wbudowanych w te programy (start/stop/reload itp.). Przygotowałem wstępne skrypty - nie testowane, więc mogą być jakieś błędy. Jeżeli masz przygotowaną instalację to sprawdź. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: [packages/libvirt] + BR:leveldb-devel, libnl1-devel, libatomic_ops - BR:libnl-devel moved file cpu_map.xml to daemon
On Sat, Dec 08, 2012 at 11:58:13AM +0100, gzohop wrote: commit 29b6137ec4289c04d9bbf64a82aa53f3596f5ab9 Author: Grzegorz Pycia / PLD gzo...@carme-pld-i686.pld-linux.org Date: Sat Dec 8 11:56:05 2012 +0100 + BR:leveldb-devel,libnl1-devel,libatomic_ops - BR:libnl-devel leveldb and libatomic_ops are ceph (RDB) dependencies, not libvirt's. $ rpm -qR ceph-devel | grep -E 'leveldb|libatomic_ops' leveldb-devel libatomic_ops libvirt 1.0.0 builds with libnl 3.2+ just fine, doesn't need libnl 1.1 fallback. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: qemu-kvm-common-1.2.0-2.x86_64 jest w konflikcie z libcacard-0.1.2-1.x86_64
On Tue, Nov 06, 2012 at 10:29:05PM +0100, Artur Frysiak wrote: Podczas aktualizacji qemu dostałem komunikat jak niżej: Uruchamianie sudo /bin/rpm --upgrade -vh --root /... Przygotowywanie... ### [100%] error: Problemy z instalacją/usuwaniem: plik /usr/bin/vscclient z instalacji qemu-kvm-common-1.2.0-2.x86_64 jest w konflikcie z plikiem z pakietu libcacard-0.1.2-1.x86_64 Wystąpiły błędy podczas instalacji W takim razie qemu-common też. Jakieś propozycje rozwiązania? Ten w libcacard jest zgodny? Jeśli tak, to można zostawić tylko libcacard. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: ffmpeg-libs-1.0-2 vs. libilbc.
On Tue, Nov 06, 2012 at 06:57:54PM +0100, Paweł Sikora wrote: witam, najnowszy updejt ffmpeg wymaga doinstalowania kodeka ilbc. ktory jest koszerny? webrtc-libilbc, czy libilbc? ffmpeg wymaga webrtc-libilbc. SONAME jest takie samo? Jeśli tak, trzeba w którymś zmienić. Nie są binarnie zgodne. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: [RFD] wersja rpm
On Wed, Oct 24, 2012 at 01:16:18PM +0200, Tomasz Pala wrote: On Wed, Oct 24, 2012 at 11:40:54 +0200, Marcin Banasiak wrote: Dodatkowo do tej listy można dodać obsługę Suggests, której również nie ma w rpm.org. http://en.opensuse.org/openSUSE:RPM_sucks * Starting with rpm 4.7 (perhaps earlier? or is it an openSUSE patch?) soft dependencies like Recommends and Suggests are possible with RPM too. A dokładniej weakdeps.diff z https://build.opensuse.org/package/files?package=rpmproject=openSUSE%3AFactory Która to łata wg opisu zależy od kolejnej... Swoją drogą jeżeli drugi z kolei duży gracz trzyma u siebie ~80 łat, to jaki priorytet w rpm.org mają nasze łaty? -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: [RFD] wersja rpm
On Tue, Oct 23, 2012 at 01:37:29PM +0200, Karol Krenski wrote:
W dniu 23.10.2012 09:20, Tomasz Pala pisze:
której wersji rpma oczekujesz w PLD?
[ ] rpm5 rozwijanego w archaicznym środowisku i masochistycznych warunkach
[ ] rpm4 rozwijanego pod patronatem RH (a niech zaryzykuję -
community-driven)
Zdecydowanie rpm4.
Jakoś nie widzę wyższości rpm5 nad rpm4 - wręcz przeciwnie.
Na dwóch maszynach wróciłem do czwórki, na trzeciej na szczęście w ogóle
nie aktualizowałem.
Z bolączek, które nie zostały wymienione to także:
1. jest koszmarnie wolny i zżera całe zasoby (odczuwalne szczególnie przy
większej ilości paczek do instalacji/deinstalacji).
2. rpm5 w obecnej postaci psuje m.in nasz skrypt builder, np.:
rpm -q --whatprovides $DEPS 21 |
awk '/^(error:|no package provides)/ { print }'
nie działa, bo rpm5 milczy.
3. Od samego początku w naszym specu rpm5 jest tona patchy i ich liczba
rośnie - tu również nie widzę przewagi nad rpm4.
4. Jakoś nie widzę zastosowania (w naszej dystrybucji) rozdymania rpmów
ciekawostkami typu Provides: elf(buildid) = ...
Itd., itd.
Powtórzę to jeszcze raz - ja jestem za rpm4.
rpm4 jest określeniem mocno rozmytym.
To głos za powrotem do rpm 4.5 by PLD czy aktualną linią rpm.org?
--
Jakub Boguszhttp://qboosh.pl/
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: [RFD] wersja rpm
On Tue, Oct 23, 2012 at 09:20:41AM +0200, Tomasz Pala wrote: Jak pokazują ostatnie tygodnie, rpm5 - w wersji co prawda rozwojowej, ale generuje sporo problemów. Błędy wykryte oczywiście można naprawić, jednak pozostaje faktem, iż: 1. błędy wykrywamy tutaj, co znaczy, że nikt inny tej wersji nie używa (a zatem poprawki będą dopiero, jak komuś 'z naszych' coś się uwali), 2. rpm5 jest rozwijany we wrogim środowisku (słaby warsztat techniczny oraz problemy komunikacyjno-mentalne dyktat^Wautora), 3. pakiety rpm5 są niekompatybilne z resztą świata (bo nazwijmy to wprost, reszta świata używa rpm4, jedynie Mandriva się wyłamuje, ale to bardziej z przyczyn wydaje mi się politycznych niż technicznych). Zresztą Mandriva AFAIK aktywnie uczestniczy w rozwoju rpm5, więc jeżeli nie zamierzamy ponownie (jak już było z rpm4 - z tego samego źródła) utrzymywać własnej wersji rpma (co już sugerują ostatnie maile z hmacs), to chciałbym poznać wasze zdanie na temat: czy powinniśmy zakończyć eksperyment pt. rpm5? Daliśmy mu szansę - w porządku, były jakieś argumenty natury technicznej. Życie jednak boleśnie zweryfikowało, że rpm5 skupia się na rocket-science, pomijając codzienną niezawodność oraz zaufanie do systemu. Osobiście nie zaryzykuję, że któregoś dnia poznikają mi np. konfiguracje (bo rpm uzna, że nie zmieniły się w stosunku do oryginałów w pakiecie), albo że usunie cały katalog (nie zwracając uwagi na to, że w środku były pliki spoza pakietu) lub wykona inną nieprzewidywalną(!) rzecz, a później będę musiał tydzień tłumaczyć autorowi, w czym jest problem (na co i tak usłyszę odpowiedź, aby odtworzyć z backupu, a jeśli go nie mam, to tam leży błąd i jego naprawienie leży poza zakresem rpma - ten koleś tak już ma i tak mniej więcej się upierał przy bugu, po którym w końcu wyleciał z RH - ale to wie każdy, kto tego człowieka zna i nawet nie próbuje merytorycznie z nim rozmawiać). W tej chwili nie jest jeszcze zbyt późno, aby wycofać się z tej samobójczej zmiany (obok i tak sugestia przebudowania 8,5k pakietów) i iść z głównym nurtem, który jest wspierany przez szeroko rozumiany biznes (a co za tym idzie mocno testowany i bardziej niezawodny). Prosiłbym o krótkie odpowiedzi, bez przekonywania mnie do przewagi technicznej (w kosmos nie polecisz nawet z najlepszym silnikiem, jeśli nie domykają się drzwi) - niestety argument ad personam w tym przypadku jest dominujący (poziom uspołecznienia grubo poniżej akceptowalnego oraz jakiś lazy-english w piśmie czynią go wręcz odrażającym do jakiejkolwiek dyskusji, skutkiem czego KAŻDY odkrywca błędu debuguje na własną rękę we własnym czasie i później jeszcze prosi, aby autor łaskawie pobłogosławił poprawkę - albo robimy rpm-pld) na pytanie: której wersji rpma oczekujesz w PLD? [ ] rpm5 rozwijanego w archaicznym środowisku i masochistycznych warunkach [ ] rpm4 rozwijanego pod patronatem RH (a niech zaryzykuję - community-driven) (no dobra, trochę te pytania wskazują na odpowiedź - przepraszam) Ewentualnym biznesofobom przypomnę, że większość kodu kernela jest sponsorowana. Pytanie co jest tańsze - utrzymywanie własnego forka rpm5 czy rpm.org? Upstream w przypadku rpm.org powinien być stabilniejszy, ale nie wiemy, czy bardziej otwarty (bez sprawdzenia - jestem sceptyczny). Poziom community-driven można przetestować próbując nakarmić łatkami z PLD (choćby tymi, które w rpm5 już są - można zidentyfikować śledząc historię począwszy od 4.4.2, kiedy nastąpiło rozgałęzienie). Z czysto technicznych różnic, które wychwyciłem przeglądając listę zmian, mających IMO większe znaczenie: - zaletą rpm.org jest obsługa file capabilities, nowy atrybut plików %caps() - dużą wadą brak repackage (cała obsługa wycięta na samym początku tworzenia wersji 4.6) Zanim zaczniesz dyskutować, przeczytaj http://lwn.net/Articles/441085/ i obejrzyj aktywność: http://rpm.org/gitweb?p=rpm.git;a=summary http://rpm5.org/cvs/timeline?d=300e=2012-Oct-23c=2px=rpms=0dm=1x=1w=0 Szału nie ma ani tu, ani tu. Zaskoczyło mnie, że rpm5 nadal jest w CVS-ie... -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: [RFD] wersja rpm
On Tue, Oct 23, 2012 at 04:54:49PM +0200, Tomasz Pala wrote: On Tue, Oct 23, 2012 at 16:47:48 +0200, Jacek Osiecki wrote: A tu mi zabiłeś ćwieka... W takim razie zmieniam zdanie i jednak wolałbym pozostać przy 4.5. No to dla mnie też dyskwalifikacja dla 4.6 - repackage, zwłaszcza przy dystrybucji obfitującej w nowalijki (nie zawsze do końca przetestowane) jest wręcz niezbędny. Pozostaje jeszcze do wyboru 5.3 - z tymi samymi problemami personalnymi, ale przynajmniej ktoś tego używa (Mandriva - 5.3.12). Cooker ma 5.4.x (zresztą stamtąd chyba jest część łatek w naszym 5.4 - nb. część wygląda na zbędne, bo my np. wycinamy obsługę http via neon). -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: spec dla MooseFS
On Mon, Oct 15, 2012 at 03:37:03PM +0200, Paweł Kośka wrote: W dniu 15 października 2012 12:47 użytkownik Paweł Kośka pa...@viop.pl napisał: O widzę że się zbudowało, czyli to ja jak zwykle sobie coś poprawiłem ;) Już znalazłem czemu mi się nie budowało... W załączniku kolejny zestaw poprawek. +BuildRequires: gcc-c++ %undefine __cxx (albo przegenerowanie configure) powinno wystarczyć. Tam nie ma kodu w C++. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: spec dla MooseFS
On Fri, Oct 12, 2012 at 02:16:23PM +0200, Paweł Kośka wrote: Zrobiłem małego patcha nie pakuję już 2x tych samych manuali. Chyba lepiej by na masterze były te manuale. Jeśli w jednym, to raczej w kliencie (tam, gdzie używa się tych systemów plików). Albo wydzielić -doc (man7 + ogólne pliki z dokumentacją). Jest też drugi patch. Metalloger i chunkserver też powinien pracować jako użytkownik mfs. Czy tak należało to zrobić? Nie będzie się sypać gdy będę instalować jeden pakiet, a odinstaluje drugi? Trzeba dodać Provides: user(mfs) i to samo z grupą. No i chyba dobrze by było dodać zależność, ew. sugestie dla metalogger. Wydaje mi się że instalując metalogger powinien też być zainstalowany master, ale nie uruchamiany. Może być zainstalowany, nie może być jednocześnie uruchomiony. Jak dobrze rozumiem opis programu, w przypadku awarii mastera to metalogger powinien przejmować jego zadanie. Ściślej to maszyna z metaloggerem (tzn. z zapisanymi przez niego danymi) - po zatrzymaniu metaloggera, mfsmetarestore i uruchomieniu mastera. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: spec dla MooseFS
On Sat, Oct 06, 2012 at 09:17:50PM +0200, Jan Rękorajski wrote:
On Wed, 03 Oct 2012, Paweł Kośka wrote:
Zmodyfikowałem lekko tego speca
Teraz przy instalacji dodaje użytkownika i grupe mfs
UID/GID wziąłem pierwszy wolny z
http://cvs.pld-linux.org/cgi-bin/viewvc.cgi/cvs/PLD-doc/uid_gid.db.txt
Czy taki spec może być? Co w nim jest jeszcze źle?
Wygląda nieźle, wrzuciłem do repo.
Uwagi:
- czy na pewno między podpakietami nie ma żadnych zależności?
Nie ma, każdy może działać na innej maszynie.
- /var/mfs to nie jest właściwe miejsce, powinno być
/var/{lib,cahce,spool}/mfs w zależności od przeznaczenia tego katalogu
/var/lib IMO
--
Jakub Boguszhttp://qboosh.pl/
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: [packages/postgresql: 2/3] - initial support for full pg_upgrade - exmaple: pg_upgrade -b /usr/lib64/postgresql-9.1/bin/ -B /us
On Tue, Sep 25, 2012 at 12:29:38PM +0200, zawadaa wrote:
commit 9214a4d4c6913380a9e02edb10cf81acca08ee45
Author: Andrzej Zawadzki zawa...@pld-linux.org
Date: Tue Sep 25 12:22:51 2012 +0200
- initial support for full pg_upgrade
- exmaple:
pg_upgrade -b /usr/lib64/postgresql-9.1/bin/ -B /usr/bin/ -d
/var/lib/pgsql/data -D /var/lib/pgsql/data_new
- I don't know is this propoer packaging - looks ugly - please review
- NOTE: this can upgrade from 9.1 to 9.2 only!
Parę pytań.
Co dokładnie jest potrzebne pg_upgrade ze starej wersji postgresql-a?
Czy obsługuje tylko poprzednią wersję, czy także wcześniejsze?
Mi też się nie podoba ten sposób budowania. Z tego co widzę - pg_upgrade
do zbudowania nie potrzebuje niczego ze starszej wersji postgresql-a
- więc nie ma powodu, żeby budować ją jednocześnie.
Widziałbym raczej postgresql9.1.spec (ew. też postgresql9.0.spec itd.,
w ramach wersji obsługiwanych przez pg_upgrade) - i stamtąd budowany
pakiet np. %{name}-upgradesource czy %{name}-dump (w zależności od tego,
co to naprawdę robi), ew. jakieś inne podpakiety, jeśli ktoś potrzebuje.
--
Jakub Boguszhttp://qboosh.pl/
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: gnutls-3.1.0 - sigsegv @ trousers-libs.
On Sun, Sep 02, 2012 at 01:09:04PM +0200, Paweł Sikora wrote: witam, aktualizacja gnutls z 3.0.22 do 3.1.0 powoduje wylot przy starcie np. mplayera. A z nowym trousers (0.3.9)? Program received signal SIGSEGV, Segmentation fault. host_table_init () at rpc/hosttable.c:27 (gdb) bt #0 host_table_init () at rpc/hosttable.c:27 #1 0x7fffe61c43ab in my_init () at rpc/hosttable.c:45 #2 0x77de9a26 in call_init (env=0x7fffdf68, argv=0x7fffdf58, argc=1, l=optimized out) at dl-init.c:84 #3 call_init (l=optimized out, argc=1, argv=0x7fffdf58, env=0x7fffdf68) at dl-init.c:34 #4 0x77de9b0a in _dl_init (main_map=0x77ffe188, argc=1, argv=0x7fffdf58, env=0x7fffdf68) at dl-init.c:133 #5 0x77ddc66a in _dl_start_user () from /lib64/ld-linux-x86-64.so.2 $ valgrind --leak-check=full /usr/bin/mplayer ==11453== Memcheck, a memory error detector ==11453== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==11453== Using Valgrind-3.8.0 and LibVEX; rerun with -h for copyright info ==11453== Command: /usr/bin/mplayer ==11453== ==11453== ==11453== Process terminating with default action of signal 11 (SIGSEGV) ==11453== Bad permissions for mapped region at address 0xDA439A0 ==11453==at 0x1678937D: host_table_init (hosttable.c:27) ==11453==by 0x167893AA: my_init (hosttable.c:45) ==11453==by 0x400EA25: call_init (in /lib64/ld-2.16.so) ==11453==by 0x400EB09: _dl_init (in /lib64/ld-2.16.so) ==11453==by 0x4001669: ??? (in /lib64/ld-2.16.so) Tam jest zwykłe calloc() wywołane w konstruktorze biblioteki. Jakiś problem z zależnościami przy wczytywaniu bibliotek? Może przebudowanie trousers coś pomoże... -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Problem z licencja
On Thu, Aug 23, 2012 at 08:00:51PM +0200, Paweł Sikora wrote: On Thursday 23 of August 2012 19:20:00 Kacper Kornet wrote: On Thu, Aug 23, 2012 at 07:07:03PM +0200, Paweł Sikora wrote: On Thursday 23 of August 2012 18:07:46 Kacper Kornet wrote: Jak należy postępować gdy razem ze źródłem programu nie ma żadnego pliku COPYING, LICENSE itp., natomiast w jednym z plików źródłowych jest coś takiego: * Audacious playlist format plugin Copyright 2011 John Lindgren * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions are * met: * * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions, and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions, and the following disclaimer in the * documentation provided with the distribution. * * This software is provided as is and without any warranty, express or * implied. In no event shall the authors be liable for any damages * arising from the use of this software. wyglada jak BSD-like, w szczegolnosci: http://en.wikipedia.org/wiki/BSD_licenses#2-clause_license_.28.22Simplified_BSD_License.22_or_.22FreeBSD_License.22.29 Bardziej mi chodziło jaka jest praktyka spełnienie warunku must reproduce the above copyright notice. Wydzielać ten tekst do osobnego pliku COPYING i go pakować, czy jakieś inne podejście. oidp, to nie pakujemy plikow ze standardowym tekstem licencji, tylko wpisujemy odpowiednie wartosci w .specu w polu license. W przypadku BSD/MIT treść licencji zawiera informację o właścicielu praw autorskich, często też są drobne różnice w treści - dlatego w tym przypadku te krótkie pliki z treścią dołączamy do pakietów. Jeśli nie ma osobnego pliku, to można zrobić head -n X plik.c LICENSE i dodać taki plik do %doc. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: DISTFILES: ERROR fetching sources for bash-completion (refs/heads/bash-completion-2)
On Thu, Aug 02, 2012 at 06:15:54PM +0200, qboosh wrote: cannot git fetch bash-completion from branch refs/heads/bash-completion-2; fatal: Couldn't find remote ref refs/heads/bash-completion-2 exited with code 128 df nie obsługują kropek w nazwach gałęzi? -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: [TH-main] pand/NAP
On Sat, Jul 07, 2012 at 08:39:03PM +0200, Łukasz Maśko wrote: Dnia sobota, 7 lipca 2012, Bartlomiej Zimon napisał: [...] Wczesniej hcid -s go tworzyl, teraz bluetoothd powinien, moze na nim strace powies. Przy obecnym bluez (4.101-1) bluetoothd nie jest startowany bez systemd. Na SysVinit ostatni który pracuje bez problemu to 4.99-6, bo jeszcze jest w nim /lib/udev/rules.d/97-bluetooth.rules i udev go podnosi. Przytoczę tu z wcześniejszej prywatnej korespondencji, co wyśledziłem: http://git.kernel.org/?p=bluetooth/bluez.git;a=commitdiff;h=2ea98a6a043710ad4958355b62c682b4767f292e Czyli: nowe wersje udev nie pozwalają już na takie uruchamianie długotrwałych procesów. Nie wiem, czy wzmiankowane tu uruchamianie przez systemd jest już w domyślnej konfiguracji. W przypadku bez systemd należałoby zapewne przywrócić bezudevową (czysto SysV) wersję skryptu init. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Git migration
On Fri, Jun 29, 2012 at 09:59:42PM +0200, Jacek Konieczny wrote: On Fri, Jun 29, 2012 at 06:57:55PM +0200, Paweł Sikora wrote: no to jak panowie, jaki w koncu model odgalezien przyjmujemy dla glownego nurtu pld-th? 1). dzialamy na 2 galeziach master/devel ze wzajemnym scalaniem (tak jak pokazalem wyzej) i nie nadpisujemy/kasujemy devel. Czemu się tak ograniczać? Można rozwijać pakiet w różnych kierunkach przecież. 'devel' nic nie mówi i nawet nie wiadomo co tam miałoby być. 2). dla kazdej kolejnej developerskiej wersji softu odgaleziamy od master do jakiegos next-X.Y (czy jak to tam nazwiemy), potem merge do master i koniec uzywania galezi (kasacja?). Wybieram tę opcję. Topic branch. W tym przypadku 'topikiem' jest jakieś developerskie wydanie softu. Bo mergowaniu takiego brancha do master, gdy wersja staje się aktualną lub przestarzałą, to IMHO można go skasować ??? znaczy usunąć nazwę z repo, bo w historii odgałęzienie zostanie. I nie będzie problemów jak z resetem 'uniwersalnego' brancha 'devel', że po jakimś czasie ktoś robi 'git pull' i bzdury wychodzą. chodzi o to, zeby nie bylo pozniej w kazdym pakiecie wedle lokalnych upodoban, bo jakikolwiek nowy developer zglupieje, albo wprowadzi swoj odmienny tok dzialania. Dla częstych przypadków, jak pakiet z developerską/testową wersją softu dobrze jest ustalić jakieś reguły. IMHO wystarczy numer wersji jako nazwa brancha. IMO lepszy byłby schemat nazw pozwalający od razu odróżnić charakter gałęzi (wersje rozwojowe, wersje stabilne starsze niż master itp.), bez oglądania historii gałęzi/wersji przed i po odgałęzieniu. O ile w danej chwili może być oczywiste, co jest wersją rozwojową, a co starą stabilną - to po paru latach już nie. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Libreoffice+libicu calc wywraca się (100% powtarzalności)
On Tue, Jun 19, 2012 at 10:31:28PM +0200, Łukasz Maśko wrote: Dnia wtorek, 19 czerwca 2012, Bartosz Świątek napisał: 2012/6/19 Łukasz Maśko e...@yen.ipipan.waw.pl: Zbudowałem icu-4.8.1.1 po poprawieniu speca i teraz działa (tylko chwilowo tego patcha nie mogę wrzucić do CVS-a bo sticky tag `auto-th-icu-4_8_1-1' for file `icu.spec' is not a branch a ja z CVS-a dalej tak samo zielony jak dawniej). Skopiuj sobie swoja zmianę, usuń oryginał, pobierz z HEAD, nadpisz swoim plikiem, skomituj. Phi, tak prosto ;-) Oczekiwałem jakiejś większej magii. Zrobione. I źle, bo na HEAD była już nowa wersja. Dla starej powinien być branch ICU_4_8 albo coś w tym rodzaju. BTW, czy LO działa poprawnie z icu 49? -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: xmlrpc-c.spec - xmlrpc-c-c++ Requires: libstdc++-devel
On Tue, Jun 05, 2012 at 03:23:52PM +0200, Szymon Siwek wrote: Witam! W specu xmlrpc-c pakiet xmlrpc-c-c++ ma Requires: libstdc++-devel Nie bardzo widzę sens takiego czegoś, w odpowiednim commit logu mamy tylko: Miało być w xmlrpc-c-c++-devel. Poprawione. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: packages: unixbench/unixbench.spec - removed BR: glibc-devel
On Tue, Jun 05, 2012 at 06:30:13PM +0200, sls wrote: Author: sls Date: Tue Jun 5 16:30:13 2012 GMT Module: packages Tag: HEAD Log message: - removed BR: glibc-devel --- packages/unixbench/unixbench.spec:1.17Tue Jun 5 18:20:45 2012 +++ packages/unixbench/unixbench.spec Tue Jun 5 18:30:08 2012 @@ -17,7 +17,6 @@ Requires:file Requires:fileutils Requires:gcc -Requires:glibc-devel Requires:make Requires:mawk Requires:mktemp To nie było BR. On już nie kompiluje nic w trakcie działania? -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: packages: elinks/elinks.spec - the archives createad automatically for a br...
On Tue, Jun 05, 2012 at 09:17:06AM +0200, jajcus wrote:
Author: jajcus Date: Tue Jun 5 07:17:06 2012 GMT
Module: packages Tag: HEAD
Log message:
- the archives createad automatically for a branch on github are different
on each download, use distfiles instead
Files affected:
packages/elinks:
elinks.spec (1.179 - 1.180)
Diffs:
Index: packages/elinks/elinks.spec
diff -u packages/elinks/elinks.spec:1.179 packages/elinks/elinks.spec:1.180
--- packages/elinks/elinks.spec:1.179 Tue Jun 5 08:40:23 2012
+++ packages/elinks/elinks.spec Tue Jun 5 09:17:01 2012
@@ -38,7 +38,9 @@
Epoch: 1
License: GPL v2
Group: Applications/Networking
-Source0: http://www.elinks.cz/download/%{name}-current-%{version}.tar.bz2
A to nie jest codzienny snapshot, który należałoby oznaczyć w Release?
--
Jakub Boguszhttp://qboosh.pl/
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: upgrade GNOME - braki nowszych wersji, zamienników lub Obsoletes
On Fri, May 25, 2012 at 08:46:50PM +0200, Marcin Banasiak wrote: W dniu 25 maja 2012 20:36 użytkownik Jakub Bogusz napisał: Czy glade w wersji 3.x nie powinien mieć Obsoletes: glade3-*? Nie. One mogą być zainstalowane obok siebie tyle, że glade3 musi być w wersji = 3.8.0. W glade3 jest wersja dla GTK+2, a w glade dla GTK+3. W takim razie glade 3.x powinno mieć Conflicts na glade3 3.8.0. C.d. prawdopodobnie nie uwzględnionych przy migracji pakietów GNOME 2.x: gnome-applet-hamster i gnome-applet-colorblind wymagają python-gnome-desktop-applet, który jest teraz w Obsoletes python-gnome-desktop. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
upgrade GNOME - braki nowszych wersji, zamienników lub Obsoletes
Próbuję uaktualnić stary system, gdzie GNOME było zainstalowane poprzez metapackage-gnome. Nie da się z powodu istniejących kiedyś pakietów GNOME 2.x, które nie mają dostępnych na ftp nowych wersji i najwyraźniej nie zostały uwzględnione w żadnych Obsoletes: gnome-applet-deskbar gnome-applet-seahorse gnome-pilot planner rhythmbox BTW - istniejący metapackage-gnome jest nieaktualny: metapackage-gnome-desktop-3.0.1-4.noarch: nie znaleziono wymaganego totem-youtube = 3.0.1 metapackage-gnome-desktop-3.0.1-4.noarch: nie znaleziono wymaganego gnome-utils-dictionary = 1:3.0.1 metapackage-gnome-desktop-3.0.1-4.noarch: nie znaleziono wymaganego grilo-plugins metapackage-gnome-games-3.0.1-4.noarch: nie znaleziono wymaganego gnome-games-extra-data-glines = 3.0.0 metapackage-gnome-games-3.0.1-4.noarch: nie znaleziono wymaganego gnome-games-extra-data-gnobots2 = 3.0.0 metapackage-gnome-games-3.0.1-4.noarch: nie znaleziono wymaganego gnome-games-extra-data-iagno = 3.0.0 metapackage-gnome-games-3.0.1-4.noarch: nie znaleziono wymaganego gnome-games-extra-data-mahjongg = 3.0.0 metapackage-gnome-office-3.0.1-4.noarch: nie znaleziono wymaganego planner = 0.14.2 -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: upgrade GNOME - braki nowszych wersji, zamienników lub Obsoletes
i jeszcze: plik /usr/share/gnome/help/glade/de/figures/main-window.png z instalacji glade-3.12.1-1.i686 jest w konflikcie z plikiem z pakietu glade3-3.6.7-8.i686 plik /usr/share/gnome/help/glade/de/glade.xml z instalacji glade-3.12.1-1.i686 jest w konflikcie z plikiem z pakietu glade3-3.6.7-8.i686 plik /usr/share/gnome/help/glade/el/figures/main-window.png z instalacji glade-3.12.1-1.i686 jest w konflikcie z plikiem z pakietu glade3-3.6.7-8.i686 plik /usr/share/gnome/help/glade/en_GB/figures/main-window.png z instalacji glade-3.12.1-1.i686 jest w konflikcie z plikiem z pakietu glade3-3.6.7-8.i686 plik /usr/share/gnome/help/glade/hi/figures/main-window.png z instalacji glade-3.12.1-1.i686 jest w konflikcie z plikiem z pakietu glade3-3.6.7-8.i686 plik /usr/share/gnome/help/glade/it/glade.xml z instalacji glade-3.12.1-1.i686 jest w konflikcie z plikiem z pakietu glade3-3.6.7-8.i686 plik /usr/share/gnome/help/glade/pt_BR/figures/main-window.png z instalacji glade-3.12.1-1.i686 jest w konflikcie z plikiem z pakietu glade3-3.6.7-8.i686 Czy glade w wersji 3.x nie powinien mieć Obsoletes: glade3-*? -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: gcc: error: unrecognized option '-V'
On Tue, Mar 27, 2012 at 04:22:31PM +0200, Jacek Osiecki wrote: Witam, Przy kompilacji paru rzeczy opluty zostałem błędami przy configure. Sprawdzenie config.log pokazało w czym rzecz: gcc: error: unrecognized option '-V' Czy to jest urok wersji gcc w PLD, czy też wynika to z braku jakichś pakietów o których nawet nie wiem że istnieją? A czy _to_ faktycznie jest przyczyna niepowodzenia, nie ma dalej innych błędów? configure z autoconfa próbuje sprawdzić wersję kompilatora na kilka różnych sposobów; jeśli -V się nie powiedzie, próbuje innych opcji. No chyba że został użyty jakoś prehistoryczny autoconf. Jeśli gcc kiedyś obsługiwał -V jako sprawdzenie wersji, to było to bardzo dawno (na pewnie 4, chyba też 3). -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: packages: fox/fox.spec, fox/fox-Xlib.patch (REMOVED) - up to 1.7.32
On Wed, Feb 15, 2012 at 08:38:50PM +0100, arekm wrote: -Version: 1.7.26 -Release: 4 +# 1.7 is devel, we should try to keep stable line +Version: 1.7.32 To przy 1.8, skoro już ktoś dużo wcześniej wrzucił 1.7.x. Stabilny fox 1.6 jest w fox16.spec. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: packages: nagios/nagios.spec - bcond embeded perl chsanged. [OOC] Glen nauc...
On Tue, Feb 07, 2012 at 05:04:05PM +0100, Marcin Rybak wrote: 2012/2/7 Patryk Zawadzki pat...@pld-linux.org W dniu 7 lutego 2012 14:26 użytkownik Bartosz Taudul wolf@gmail.com napisał: 2012/2/7 Arkadiusz Miśkiewicz ar...@maven.pl: Please stop this personal crap. Better share with us about what is the actuall problem with this bcond? I cannot tell that from reading your commit logs. Jakbyś nie odpierdalał personal crapu z abw, to by sobie glen mógł przeczytać o co chodzi. IRC to nie bugtracker. o tak - nasz bugtracker aż kipi od ticketów... a może dlatego ich brak, że to idealna dystrybucja w której wszystko działa po upgrade. Cieciwa znalazł błąd, więc go naprawił, podobnie było ostatnio z błędem związanym z logrotate, nikt nikogo nie pytał o to czy to naprawiać I'm replying to several messages now, not just yours one. First, when speaking (first) on English list and (second) about subject involving non-Polish speaker, use English. (I'm CCing -pl now, so all people interested will see this - but please follow just on -en) Second - to state what this thread is about: http://nagios.sourceforge.net/docs/3_0/embeddedperl.html This is official Nagios feature. Using it has some advantages and disadvantages. When enabled at build time, it can be disabled at runtime in several ways (either globally in Nagios configuration, or per-script) - there stays only some (small for modern systems) memory footprint. When disabled at build time, it can't be enabled at runtime. Globally disabling some feature, which - if problematic - can be disabled locally is hardly fixing a bug. And finally - if cieciwa would just tell, WHICH script is incompatible with ePN, then the bug could be fixed at its source or at least identified. If many scripts are problematic, we could ship Nagios with epn configured in such way, that it requires +epn marker in ePN-compatible scripts and then mark with it all shipped scripts which are compatible. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: kde4-kdeadmin-kprinter - brakujace zaleznosci w runtime.
On Wed, Jan 25, 2012 at 07:34:08PM +0100, Bartlomiej Zimon wrote: Dnia 25 stycznia 2012 18:55 Bartlomiej Zimon uz...@o2.pl napisał(a): Dnia 25 stycznia 2012 18:43 Łukasz Maśko e...@yen.ipipan.waw.pl napisał(a): Dnia środa, 25 stycznia 2012, Łukasz Maśko napisał: [...] Niestety, na pythonie się zupełnie nie znam i chociaż widzę błąd, to nie wiem, jak go interpretować i jak zwalczyć. Znalazłem swój stary post w tym samym temacie dokładnie sprzed 2 lat. Efekt był identyczny. Wtedy pomogło doinstalowanie python-devel. Teraz _też_! Po jaką cholerę apletowi potrzebny developerski pakiet pythona?! fakt u mnie to samo po odinstalowaniu tego pakietu musze poszukac czemu tak sie dzieje, wyglada na brak symbolu: undefined symbol: PyExc_ValueError wystarcza te 2 pliki aby sie uruchomil bez bledu # ls -l /usr/lib/libpython2.7.so /usr/lib/python2.7/config/ lrwxrwxrwx 1 root root 19 01-25 19:30 /usr/lib/libpython2.7.so - libpython2.7.so.1.0 Czyli pewnie jest jakiś dlopen() po złej nazwie. /usr/lib/python2.7/config/: razem 48 -rw-r--r-- 1 root root 46450 01-25 19:26 Makefile Chyba nie powinno byc problemow z przeniesieniem ich do paczki glownej python-a ? Makefile już jest w python-libs (któryś z modułów analizuje ten plik - niezbyt mądry pomysł IMO, ale cóż...) -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: Migracja serwisów SysV - systemd
On Tue, Jan 24, 2012 at 07:59:41PM +0100, Tomasz Pala wrote: On Tue, Jan 24, 2012 at 19:46:48 +0100, Pawel Golaszewski wrote: [...] 1. Requires(post,preun): systemd-units. To jest najczystsze rozwiązanie - 300 KB dzisiaj nie stanowi problemu na większości maszyn. A nie będzie problemów i sypania błędami dotyczących komunikacji z dbusem? Sprawdziliście jak to się zachowa przy jego całkowitym braku? Nie dam sobie teraz nic uciąć, ale enable/disable z tego co pamiętam (bo CHYBA kiedyś sprawdzałem) nie wymaga dbusa ani nic - przecież ta funkcja powinna działać nawet z poziomu emergency.target. A jak się w przyszłości zmieni i bez dbusa czy udeva przestanie działać? systemd w założeniach wymaga obu, więc autor może uznać, że na ich istnieniu może polegać. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: packages: okular/okular.spec - suggests cups-clients for printing support (...
On Sat, Jan 21, 2012 at 01:54:28PM +0100, pluto wrote: Author: plutoDate: Sat Jan 21 12:54:28 2012 GMT Module: packages Tag: HEAD Log message: - suggests cups-clients for printing support (okular uses a 'lpr' binary). lpr to nie cups-clients - może być dowolna implementacja klienta w stylu BSD, np. LPRng. Nie pamiętam, czy jest do tego jakaś wirtualna własność; jak nie, to może być Suggests: /usr/bin/lpr. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: kde4-kdeadmin-kprinter - brakujace zaleznosci w runtime.
On Sat, Jan 21, 2012 at 10:26:39AM +0100, Paweł Sikora wrote: witam, probuje wlasnie podpiac do kde4 drukareczke laserowa i cos mi ten modul konfiguracyjny nie chce ruszyc. zauwazylem, ze na poczaktu brakowalo python-PyKDE4, nastepnie wysledzilem, ze brakuje w systemie uic: $ python /usr/share/apps/system-config-printer-kde/system-config-printer-kde.py Traceback (most recent call last): File /usr/share/apps/system-config-printer-kde/system-config-printer-kde.py, line 43, in module from PyQt4 import uic czyli kolejny brak w postaci python-PyQt4-devel-tools, ale mimo doinstalowania obu tych pakietow nadal konfiguracja nie dziala. ktos podpowie czego jeszcz brakuje zeby to raz na zawsze dopisac do R: ? swoja droga, jesli pakiet uzytkowy wymaga cos -devel-tools, to troche dziwnie to zostalo spakietowane... Dziwny trochę ten pakiet, że do działania wymaga kompilatora interfejsów Qt... Zwykle kompiluje się w trakcie budowania pakietu (vide inne pakiety korzystające z PyQt/PyKDE). -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: packages: eeze/eeze.spec - force mount, umount, eject paths - eeze_scanner...
On Sat, Jan 21, 2012 at 09:07:12PM +0100, zbyniu wrote:
- eeze_scanner is needed by efm
@@ -127,8 +130,7 @@
%attr(755,root,root) %{_bindir}/eeze_umount
%attr(755,root,root) %{_libdir}/libeeze.so.*.*.*
%attr(755,root,root) %ghost %{_libdir}/libeeze.so.1
-# some enlightenment package?
-#%attr(755,root,root) %{_libdir}/enlightenment/utils/eeze_scanner
+%attr(755,root,root) %{_libdir}/enlightenment/utils/eeze_scanner
^^^
A co z tymi katalogami?
Być może należą do enlightenmenta, ale eeze to tylko biblioteka
niższego poziomu, nie wymagająca E.
--
Jakub Boguszhttp://qboosh.pl/
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: mksh exec bug.
On Sun, Jan 15, 2012 at 08:04:47PM +0100, Bartosz Taudul wrote: 2012/1/15 Pawel Golaszewski bl...@pld-linux.org: alternatives - może i tak, ale NIE dla /bin/sh W debianie afaik jest możliwość wybrania sobie /bin/sh. bash lub dash. Przy czym sugestia domyślnego dasha przy instalacji pojawiła się niedawno (tak a propos zastanawiania się, czy nadal jest sens używania jako /bin/sh lżejszej powłoki). -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: mksh exec bug.
On Sat, Jan 14, 2012 at 09:32:28PM +0100, Tomasz Pala wrote:
On Sat, Jan 14, 2012 at 19:12:39 +0100, Paweł Sikora wrote:
mmm, i co teraz? bedziemy przegladac wszystkie skrypty w dystrybucji i
dopisywac
tu i tam 'set -o posix' bo jakis nowy shell z bsd zachowuje sie w tej
kwestii
i naczej niz dotychczasowe pdksh/zsh/bash?
Nie, bo z definicji /bin/sh ma być shellem POSIX-owym (i ten cały mksh
sam powinien przyjmować -o posix wołany z takiej nazwy).
-o posix niekoniecznie (np. pdksh nie ustawia -o posix; nb. przy -o posix
nie działa np. rozwijanie { , } nagminnie używanych w specach).
Ale -o sh powinno być ustawiane dla /bin/sh i w pdksh jest - na samym
początku padło, że -o sh w mksh też powinno przywracać posiksowe zachowanie
przekierowywania deskryptorów.
--
Jakub Boguszhttp://qboosh.pl/
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: packages: gpm/gpm.spec, gpm/gpm-ncursesw.patch (REMOVED) - no more separate...
On Tue, Jan 10, 2012 at 05:21:16PM +0100, lisu wrote:
Author: lisu Date: Tue Jan 10 16:21:16 2012 GMT
Module: packages Tag: HEAD
Log message:
- no more separated libtinfo(w)
Files affected:
packages/gpm:
gpm.spec (1.173 - 1.174) , gpm-ncursesw.patch (1.1 - NONE) (REMOVED)
-Patch5: %{name}-ncursesw.patch
A widział co ta łatka przede wszystkim (poza dodaniem sprawdzenia
libtinfow) robi?
--
Jakub Boguszhttp://qboosh.pl/
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: systemd (Re: syslog-ng startowany po bindzie)
On Mon, Nov 28, 2011 at 09:33:01PM +0100, Tomasz Pala wrote: On Mon, Nov 28, 2011 at 20:57:38 +0100, Paweł Sikora wrote: czy systemd posiada jakies eleganckie rozwiazanie na cyle w zaleznosciach? W zasadzie tylko 'start na żądanie'. np. startuje maszyna (z lokalnego dysku, badz pxe, flash) bedaca czescia klastra, montuje sobie jakies lokalne systemy plikow, potem odpala siec, nastepnie oczekuje na inne elementy sieci (np. nfs, AoE, iscsi, itp) by dalej zamontowac kolejne systemy plikow (na nowo powstalych urzadzeniach) i przejsc dalej do kolejnych etapow. Tutaj w systemd w ogóle nie ma pętli - domyślnie nawet masz local-fs.target i remote-fs.target, do tego remote-fs-pre.target, czyli nie ograniczasz się do mount -a, lecz masz: - montowanie lokalnych fsów, - sieć, - *NFS czyli dokładnie tak to idzie, jak opisałeś. jak dotad tego typu ukladanki, to byl horror w rc.sysinit i reczne rzezbienie w rc.local. systemd cos usprawnia w tej kwestii? (glownie rozchodzi sie o wielokrotne nawrotki do motnowania elementow z /etc/fstab). Takie problemy to zjada na śniadanie właśnie dlatego, że nie tylko każdy service jest osobno (jak w SysV), ale także mount(point) i czeka grzecznie, aż się może wykonać. Dwa kroki (lokalne i _netdev) to i przy initscripts/rc-scripts nie problem. Rzeźba zaczyna się, jeżeli dopiero po zamontowaniu pierwszej porcji sieciowych systemów plików można uzyskać dostęp do jakiegoś dalszego elementu, który też ma być zamontowany. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: packages: glib2/glib2.spec - up to 2.31.0
On Sat, Nov 19, 2011 at 04:18:51PM +0100, rotom wrote: Author: rotomDate: Sat Nov 19 15:18:51 2011 GMT Module: packages Tag: HEAD Log message: - up to 2.31.0 ^^^ To nie powinno być na DEVEL? -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: packages: bind/bind.spec - updated ac, openssl versions (openssl 0.9.8d+ or ...
On Fri, Nov 18, 2011 at 08:09:52PM +0100, Marcin Rybak wrote: 2011/11/17 qboosh qbo...@pld-linux.org Author: qboosh Date: Thu Nov 17 15:54:10 2011 GMT Module: packages Tag: HEAD Log message: - updated ac,openssl versions (openssl 0.9.8d+ or 0.9.7l+ required) 0.9.7l+ required this isn't true :) - package does not build at carme-ac-i686 Maybe. It's a quote from configure script, I haven't verified each version of openssl. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: packages: colord/colord.spec - BR: resmgr-devel
On Tue, Oct 18, 2011 at 10:18:43AM +0200, lisu wrote: Author: lisu Date: Tue Oct 18 08:18:43 2011 GMT Module: packages Tag: HEAD Log message: - BR: resmgr-devel Gdzie widzisz odwołanie do resmgr w colord? To zależność sane-backends[-devel]. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
LIBCHAMPLAIN_0_8
Sprawca proszony jest o usunięcie zbędnego tagu/brancha LIBCHAMPLAIN_0_8 z pakietów nie związanych z libchamplain, czyli chyba wszystkich poniższych: cairo cheese clutter erlang gdal gdl gdm glade3 gnome-disk-utility gnome-keyring gnome-packagekit graphviz gtksourceview2 gtkspell gtk-vnc libbonoboui libcanberra libglade2 libgnomecanvas libgnome libgnomeui libnotify libpst libunique libwnck nautilus nspr nss PackageKit php-dirs php polkit-gnome polkit-kde-1 polkit python-django python-PyYAML scribus sqlite3 tomboy transmission unixODBC-GUI-Qt vino vte0 vte wireless-tools xorg-driver-video-s3virge xulrunner zenity -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: grub2 i niespełnione zależności
On Wed, Oct 12, 2011 at 08:55:19AM +0200, Arkadiusz Miśkiewicz wrote: On Wednesday 12 of October 2011, Tomasz Witek wrote: nie potrafie zmusic gruba 0.97 do pracy z raidem a grub2 ma niespełniną zależność do ncurses a wlasciwie do libtinfo.so.5 czy ktoś mógłby rzucuć okiem na to ?? Niestety - jeszcze nikt nie wpadł na to dlaczego grub2 budowany z gcc 4.6 nie pracuje poprawnie (nawet menu nie pokazuje). Może -fno-reorder-functions? (nie testowałem) -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: packages: binutils/binutils.spec - static R: zlib-static
On Wed, Sep 21, 2011 at 01:49:02PM +0200, baggins wrote:
Author: baggins Date: Wed Sep 21 11:49:02 2011 GMT
Module: packages Tag: HEAD
Log message:
- static R: zlib-static
Files affected:
packages/binutils:
binutils.spec (1.349 - 1.350)
Diffs:
Index: packages/binutils/binutils.spec
diff -u packages/binutils/binutils.spec:1.349
packages/binutils/binutils.spec:1.350
--- packages/binutils/binutils.spec:1.349 Sat Aug 6 08:15:17 2011
+++ packages/binutils/binutils.spec Wed Sep 21 13:48:57 2011
@@ -122,6 +122,7 @@
Summary(pl.UTF-8): Biblioteki statyczne do GNU binutils
Group: Development/Libraries
Requires:%{name}-devel = %{epoch}:%{version}-%{release}
+Requires:zlib-static
Statyczne linkowanie z libbfd (czy innymi) nie wymusza statycznego
linkowania ze zlibem czy glibc.
Czyli zależność R: zlib-devel w zupełności wystarcza.
Podobnie w gdb-lib powinno wystarczyć R: python-devel.
--
Jakub Boguszhttp://qboosh.pl/
___
pld-devel-pl mailing list
pld-devel-pl@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: packages: prewikka/prewikka.spec - updated to 1.0.0
On Wed, Aug 03, 2011 at 01:28:08PM +0200, paszczus wrote: Author: paszczus Date: Wed Aug 3 11:28:08 2011 GMT Module: packages Tag: HEAD Log message: - updated to 1.0.0 +BuildRequires: python-bpdb A to skąd? $ grep -i bpdb -r ../BUILD/prewikka-1.0.0/ $ -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: [TH] udev-170-1.x86_64 vs. kernel-2.6.38.8-1.x86_64 vs. DVD na IDE
On Fri, Jul 08, 2011 at 09:48:39AM +0200, Daniel Dawid Majewski wrote: W odpowiedzi na wiadomość z dnia 08.07.2011 08:08, od Daniel Dawid Majewski: Mam z udev w tej konfiguracji problem przy starcie systemu: Starting udev.[ZAJĘTY ] udevadm settle - timeout of 120 seconds reached, the event queue contains: /sys/devices/pci:00/:00:1f.1/ide0/0.0/block/hda (5657) /sys/devices/pci:00/:00:1f.1/ide0/0.0/block/hda (5658) [ PROBLEMY ] Próbowałem tymczasowo wywalić (#) wszystkie reguły od ide i niczego to nie zmieniło... Ten sam udev z kernel-2.6.38.6-8.x86_64 działa bezproblemowo. W jaki sposób mogę rozwiązać ten problem ? Dodam jeszcze, że htop pokazuje ponad 50% CPU na udevd --daemon, a monitor po odpaleniu sypie na potęgę: # udevadm monitor monitor will print the received events for: UDEV - the event which udev sends out after rule processing KERNEL - the kernel uevent UDEV [1310109317.438767] change /devices/pci:00/:00:1f.1/ide0/0.0/block/hda (block) KERNEL[1310109317.442446] change /devices/pci:00/:00:1f.1/ide0/0.0/block/hda (block) KERNEL[1310109317.480314] change A to na hda to może czytnik/nagrywarka Optiarc? Podobno problem rozwiązuje uaktualnienie firmware'u tegoż urządzenia - do wygooglania wiele przypadków. Jako workaround w zaobserwowanym przypadku (Optiarc DVD RW AD-7540A) podziałało puszczenie go przez libata (czyli np. ata_piix zamiast piix). -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: dfu-util.spec
On Sun, Jul 24, 2011 at 10:37:24PM +0200, Daniel Dawid Majewski wrote: W odpowiedzi na wiadomość z dnia 24.07.2011 14:18, od Tomasz Pala: Drobna kosmetyka, wrzucone - dzięki. Tak się zastanawiam, grupę skopiowałem z avrdude, spełnia identyczną funkcję (ładowanie binariów do procesora, niekoniecznie stricte Linuksowych), co z nią było nie tak, że qboosh przemianował ? O ile dobrze rozumiem funkcje: dfu-util służy przede wszystkim do uaktualniania firmware'u w urządzeniach podłączanych przez USB - w tym gotowych urządzeniach podłączanych przez docelowy interfejs - co jest funkcją systemową, bardziej dla użytkowników/administratorów niż programistów. avrdude do programowania mikrokontrolerów zwykle podłączanych przez interfejs deweloperski - raczej dla programistów. -- Jakub Boguszhttp://qboosh.pl/ ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
