Nyomtatás javítva a magyar linuxos OOo 2.0.2-ben

Ma kiadtam az OpenOffice.org 2.0.2 magyar változatának (FSF.hu build) javított linuxos verzióit (Slack, RPM, DEB). Letölthető az FSF.hu FTP-jéről-ról, megismerhető a névjegypanelen szereplő "Build 4" verziószámról.

- Miért volt szükség a javított verzió kiadására?

- A fejlesztés egy késői szakában a configure scriptbe bekerült egy logikai hiba. A szándék ellenére alapértelmezett esetben kikonfigurálódott a buildből a /share/psprint könyvtár tartalma. Ennek következtében egyes felhasználók arról számoltak be, hogy nem tudnak nyomtatni, és az spadmin programmal sem tudnak nyomtatót hozzáadni a rendszerhez.

- Hogyhogy nem vetted észre kiadás előtt ezt a súlyos hibát?

- Olvastam róla, a release listára beírta valaki, hogy találta ezt a hibát a Mac OS X verzió tesztelésekor. Sajnos azonban nem tulajdonítottam ennek nagy jelentőséget, mert:

  1. Azt hittem, hogy csak a Mac OS X-re jellemző a probléma.
  2. Azt hittem, hogy bekerült a javítás a forrásba, amiből buildeltem.
  3. Nekem nyomtatott az a verzió is, ami másoknak nem, tehát nem minden esetben jön elő a hiba.

- Hogyhogy nem került bele a javítás a forrásba, nem a végleges forrásból buildeltél? Ugye-ugye, minek kapkodni!

- A végleges tarball-ból buildeltem, amiben ez a javítás nincs benne. Kézzel kell lehúzni a javítást a CVS-ből, ami kijavítja a configure fájlt.

- Akkor hogy létezik, hogy a Sun által kiadott binárisokban nincs ez a hiba? Talán nem abból a forrásból buildeltek, amit véglegesként kiadtak?

- A Sun hamburgi release engineering csoportja nem használja a configure-t. Az ő build környezetük eltér a közösségitől, így nekik ez a hiba fel sem tűnhetett, és semmilyen problémát nem is okozott. Az már más kérdés, hogy az úgynevezett master fix után miért nem adtak ki új tarball-t. Valószínűleg ugyanezért: nekik nem volt fontos.

( vmiklos | 2006. 03. 17., p – 15:23 )

"- A Sun hamburgi release engineering csoportja nem használja a configure-t. Az ő build környezetük eltér a közösségitől,"

cmiiw, de az ooo-build se hasznalja, es a disztrok nagyresze hasznalja az ooo-build wrappert a csomagolashoz

Én csak annyit tennék hozzá, hogy elég furcsa a sok rpm csomag. Mégha az az eredeti is. Hiába adom meg neki az egész könyvtárat mint repository, mégis pampog.
Mivel úgyis majdnem mindegyikre szükség van, lehet célszerűbb lenne 3 fő csomagot alkalmazni. Egyik a binárisokat tartalmazná ami függ a libes csomagtól, és kész. A végén meg lehetne választani a nyelvi csomagokból. Esetleg jöhetnek a pluszok, mint hunspell, galéria, kde, gnome integráció, gyorsindító.
Bár ennyire szétbontani lehet hogy nagy feladat. De mégis átláthatóbb lenne mint a jelenlegi helyzet. Ugyanis gőzöm nincs melyik csomagnak kell a core03 vagy a core03u csomag. Azzal sem igazán vagyok tisztában hogy miket tartalmazhatnak. De felrakom, mert fogalmam sincs hogy melyik alkalmazásnak volna rá szüksége.

Válogatás nélkül fel kell rakni mindet. Minek válogatni? Gyorsabb nem lesz tőle, a megtakarított pár megabyte lemezhely meg nem számít manapság. Én biztos nem fogok új csomagstruktúrát kitalálni és megvalósítani. Rengeteg egyéb feladat van az OOo körül, szelektálnom kell.

( Polesz v | 2006. 03. 17., p – 16:31 )

Sok mindent nem lehet mondani, danke sün.

Egy technikai megjegyzés: ha a slackware csomag újra lesz csomagolva akkor az utolsó számot ami az i686 után áll jelen esetben (1) növelni szoktuk mindig, hogy látszódjék új kiadásról van szó. Még akkor is, ha csak technikai jellegű újracsomagolásról van szó. Ebben az esetben mivel kis célközönségről van szó és gyors bugfix elhanyagolható.

--
Az élet harc. Délelőtt az éhséggel, délután az álmossággal.

( pepo v | 2006. 03. 19., v – 14:54 )

Nem tudodm, tudjátok-e, de nem megy az fsf oldlala...