Nieuws:

Welkom, Gast. Alsjeblieft inloggen of registreren.
Heb je de activerings-mail niet ontvangen?

Auteur Topic: Een patch maken, hoe wat en wanneer?  (gelezen 3528 keer)

Een patch maken, hoe wat en wanneer?
« Gepost op: 2008/10/18, 15:29:55 »
Op het moment van schrijven is Ubuntu 8.04  LTS (Hardy) de meest recente versie. Nu gebruik ik een programma "FileZilla" waarbij dit programma in Hardy versie "3.0.7.1-0ubuntu3" is en in Intrepid (in development) "3.1.2-0ubuntu2" met zich meebrengt.

Nu ga ik waarschijnlijk nog een tijdje Hardy gebruiken, maar FileZilla heeft een belangrijke security advisory gekregen bij versie 3.1.0.1. Op launchpad had ik een bug-report gevonden waarbij dit aangekaart werd voor Intrepid maar niet voor Hardy. Nu heb ik daar een commentje geplaatst en de "Bug Assignee" heeft daarop geantwoord dat ik daarvoor best een ander bugje open en een patch maak voor te uploaden naar hardy-security. Respectievelijk bugje

Nu mijn vraag is, hoe maak je eigen een "goeie" patch. Welke tools heb je daarvoor nodig en hoever moet je kennis daarvoor reiken om die te kunnen gebruiken? Hoe breng je je patch's best aan de man en in welke situaties maak je best een patch en wanneer niet?

Kortom een hoop vraagjes, maar tijd is er genoeg tussen het studeren door ;)

Groetjes,
ShadowDragon.
Xubuntu 11.04 - Xfce 4.8 - SSD Vertex 2 (Extended) 60 GB

Offline ivo

  • Lid
Een patch maken, hoe wat en wanneer?
« Reactie #1 Gepost op: 2008/10/18, 17:08:07 »
There are only 10 types of people in the world; those who understand binary and those who don't.

Offline Rulus

  • Lid
Een patch maken, hoe wat en wanneer?
« Reactie #2 Gepost op: 2008/10/18, 17:46:26 »
Gewoon een linkje dumpen is natuurlijk niet zo nuttig. De bedoeling van die patch is om de fix voor het beveiligingslek in de versie van Hardy te krijgen, zonder het hele programma te moeten updaten naar de nieuwe versie. Je moet dus in de code van de nieuwe versie op zoek naar de verandering voor het lek en die code (eventueel aangepast) in de versie van Hardy gooien. Daarvan maak je een patch die je in het pakket van Hardy steekt; vervolgens maak je een nieuwe versie van dat pakket aan en maak je een debdiff tussen je nieuwe versie en de huidige Hardy versie. Het is die debdiff die ze willen en die je dus aan het bugrapport moet hangen.

Het is dus allemaal niet zo eenvoudig en vanzelfsprekend, maar de documentatie op de wiki m.b.t. patchen, debdiffs en packagen in het algemeen is heel goed. De mensen in het Freenode IRC kanaal #ubuntu-motu zijn ook altijd heel behulpzaam.

Een patch maken, hoe wat en wanneer?
« Reactie #3 Gepost op: 2008/10/19, 13:29:26 »
Citaat van: ShadowDragon
Op het moment van schrijven is Ubuntu 8.04  LTS (Hardy) de meest recente versie. Nu gebruik ik een programma "FileZilla" waarbij dit programma in Hardy versie "3.0.7.1-0ubuntu3" is en in Intrepid (in development) "3.1.2-0ubuntu2" met zich meebrengt.

Nu ga ik waarschijnlijk nog een tijdje Hardy gebruiken, maar FileZilla heeft een belangrijke security advisory gekregen bij versie 3.1.0.1. Op launchpad had ik een bug-report gevonden waarbij dit aangekaart werd voor Intrepid maar niet voor Hardy. Nu heb ik daar een commentje geplaatst en de "Bug Assignee" heeft daarop geantwoord dat ik daarvoor best een ander bugje open en een patch maak voor te uploaden naar hardy-security. Respectievelijk bugje

Nu mijn vraag is, hoe maak je eigen een "goeie" patch. Welke tools heb je daarvoor nodig en hoever moet je kennis daarvoor reiken om die te kunnen gebruiken? Hoe breng je je patch's best aan de man en in welke situaties maak je best een patch en wanneer niet?

Kortom een hoop vraagjes, maar tijd is er genoeg tussen het studeren door ;)

Groetjes,
ShadowDragon.
FileZilla zelf is al gepatched, dus je zou ook de broncode kunnen downloaden en de boel zelf kunnen compileren. Zelf een goeie patch maken vereist de nodige programmeerkennis, tools zijn al genoemd. Aan de man brengen is je ook al gelukt. De beste situatie om een patch te maken is er niet echt. Eigenlijk gewoon wanneer je een programma wilt gebruiken, blijkt dat er een bepaalde functionaliteit mist of dat er een bug inzit en je de capaciteiten hebt om dat op te lossen. Dan zou je een patch kunnen schrijven. Soms is het ook gewoon nodig dat er een patch gemaakt wordt, zoals met beveiligingslekken of bugs die het werken onmogelijk maken.