Forum Debian Users Gang

Jak dla mnie to całkiem fajny pomysł, ja dopiero ucze się "paczkować" i fajnie by było gdybym swoje dzieła mógł umieszczać w takim repo :D
Prawie jak deweloper :P

tak wogole to jakie paczki bysmy chcieli tam umieszczac? bo cos czuje ze wielu zechce kadu, beryla i moze jakies bzdury ktore jeszcze nie trafily lub pozno trafiaja do oficjalnych, czyli moze najswiezsze buildy fluxa czy takie tam kiba docki i inne avant window managery? mam chyba nawet gdzies jeszcze z czasow kiedy kochalem fluxa taki skrypt ktory co tydzien ssa trunka z svn i kompiluje z flagami od debug, to moze by go wrzucic do repo co by co tydzien byl update wszystkich ulubionego WMa? :D

i moze jakies paczki z theme'ami do kde, gnome, fluxa, e, fvwm, tapetami, itp?

Jakby ktoś nie wiedział to już od dawna jest repo na dugu. :)
http://czadman.dug.net.pl/debian/dists/
Jak znajdę odrobinę ochoty to je uaktualnię, wypadało by przebudować to psi po ostatnich wydaniach.

Było i na amd64, ale pewnego razu była amba u mnie na kompie, a repo leżało na jakimś uniwerkowym serwerze, który się wysypał. Ostała mi się kopia tylko jednoarchitekturowego. :)

Edit:
Jednak się ostało. :)
http://panoramix.ift.uni.wroc.pl/~jazon/debian/

P.S.: Co do strony to mogę jakąś prostą przygotować, ale wolałbym, aby jakiś ochotnik zabrał się za to, bo ja to dopiero tydzień temu zacząłem naukę php+mysql.

Proponuję pythona, zamiast php. :)

800 MB starczy tylko na małe repo, jeśli nie będzie dużo pakietów to wystarczy. Psi dla architektury 386 i dla 4 wersji zajmuje ok 12 MB, dla amd64 jakieś by było 12 MB.
Ale sądzę, że mogło by być takie repo na dugu. Bodzio dał pełne poparcie. :)

napisać skrypt który będzie dodawał do Packages.gz Packages.gz z repo KADU

I did some research, wygląda na to że format tego pliku jest zajedwabiście prosty:

wpis
wpis
wpis

czyli wget, cat i po sprawie.

Co do samego funkcjonowania, to pomysł jest taki, że ktoś zrobi stronę (php+mysql - wiecie takie bajery jak logowanie przydział do danego pakietu) i na tej stronie będzie spis pakietów i przy każdym pakiecie wersja + link do profilu paczkującego.

eej, bracie :< Debian to przecież Unix, nie lepiej aby każdy paczker dostał swoje konto shellowe w grupie mającej prawa zapisu do repo, i na przykład katalog z repo na sticky? a listę paczek możnaby ograniczyć do czegoś na kształt odpowiednio przefiltrowanego ls -l updatowanego po każdym commicie, i wrzuconego jako statyczny plik html w odpowiednim miejscu... po prostu, nie ma sensu wyciągać piły łańcuchowej na gałązkę, którą można uciąć sekatorem ;] chyba że masz tylko konto, a nie maszynę.

jak nie to ja się mogę zająć stronką, to znaczy spróbować zrobić te takie tam bzdury (logowanie, upload, itd), tylko będziecie musieli mnie zaganiać do roboty co jakiś czas, sami wiecie ile projektów zacząłem i nie skończyłem ;] no i niech ktoś inny pisze zapytania sql bo ja tego zczaić nie mogę.

Jeżeli chodzi o domene

IMHO repo.dug.net.pl to byłoby coś w sam raz. w końcu jest to repozytorium, i jest to dugowe.

Co do architektur

myślę że 386 możemy sobie darować i kompilować wszystko pod 686 i amd64 (no dalej, kto umiałby odpalić beryla na pentium? są jacyś mistrzowie?). najwyżej rzeczy typowo lajtowe (np 'op', zastępca sudo... nie wiem czy jest w oficjalnym repo) na 486 lub 386.

wiele paczek może być noarch, zwłaszcza moich, coś mi mówi, bo coraz mniej lubię C++ (na korzyść pythona).

TAK POZA TYM, PEWNA KWESTIA PRAWNA.

czy ktoś czytał GNU GPL? jeśli dystrybuujesz zmienione/binarne (/samorobnie kompilowane) programy to musisz też dostarczyć pełen kod źródłowy. mało tego, musisz zapewnić możliwość dostarczenia tego kodu przez 3 latka od wydania. tak więc liczcie nie tylko buildy na poszczególne architektury, ale też src. nie chcemy kłopotów ze strony FSF, no nie? ;]

jak coś to odsyłam do GPL FAQ, być może źle zinterpretowałem ten akurat zapis ale wydaje mi się że źródła też musielibyśmy wrzucać.



aha, jeśli sobie skołuję jakiegoś starszego maca lub suna to się nie zdziwcie jak zaczną się pojawiać buildy na sparc i ppc >:P

Tak jak napisałem wcześniej, nie ważne w czym napisana była by strona. Ważne, aby spełniała swoje zadanie:)
harry666t ogólnie twoja propozycja co do kont shellowych jest oczywista.
Wyjście z repo.dug.net.pl jest wyjściem raczej dobrym. Raczej na pewno.
Co do architektur to ja nie jestem ekspertem, więc niech wypowiedzią się ludzie mądrzejsi ode mnie.
Co do dostępu do kodu źródłowego

Czy GPL wymaga, by kod źródłowy zmodyfikowanej wersji został udostępniony publicznie?
    GPL nie wymaga rozpowszechniania zmodyfikowanego przez Ciebie programu. Wolno Ci wprowadzać zmiany i korzystać z nich prywatnie, w ogóle bez ich wydawania. Odnosi się to także do organizacji (łącznie z firmami); organizacja może utworzyć zmienioną wersję i używać jej wewnętrznie nigdy nie wydając tej wersji na zewnątrz.

    Ale jeśli w jakiś sposób publicznie wypuszczasz zmienioną wersję, GPL wymaga byś udostępnił użytkownikom programu zmodyfikowany kod źródłowy, na warunkach GPL.

    Tak więc, GPL zezwala na pewne sposoby rozpowszechniania zmienionego programu, a na inne nie, ale decyzja o samym wypuszczeniu należy do Ciebie.

No więc, jeżeli zmienisz kod źródłowy to musisz go umieścić, jeżeli tylko paczkujesz to nie (bo jest już dostępny na stronie producenta). Ja tak to rozumiem (ale jak wiadomo człowiek jest omylny).

W sumie to pewnie znaczna większość pakietów to będą po prostu skomilowane kody źródłowe

Utrzymywanie repo to nie jest banalna sprawa, pomimo tego, że może się tak wydawać. Zakładam oczywiście, że repo ma być wysokiej jakości.
Polecam zacząć od zbudowania dobrego pakietu, żeby liznąć co nieco. :)

TAK POZA TYM, PEWNA KWESTIA PRAWNA.

czy ktoś czytał GNU GPL? jeśli dystrybuujesz zmienione/binarne (/samorobnie kompilowane) programy to musisz też dostarczyć pełen kod źródłowy. mało tego, musisz zapewnić możliwość dostarczenia tego kodu przez 3 latka od wydania. tak więc liczcie nie tylko buildy na poszczególne architektury, ale też src. nie chcemy kłopotów ze strony FSF, no nie? ;]

mi się zdaje że ten zapis nalezy rozumiec następująco: źródła nie muszą być dołączone do każdej binarnej dystrybucji, ale muszą byc wydane na żądanie

Tak więc źródła też.

aha ;)

czyli cały ten krzyk wynika z mojej niewiedzy i braku doświadczenia.
alrite. po 16 maja będę miał dość czasu by wszystko nadrobić. może nawet przepiszę jądro linuksa :D

tymczasem pozwólcie panowie że przeproszę, jutro matura z angielskiego więc muszę się wyspać ;]