# schnell mal ein Programm modifizieren

## JKRock

hi,

 wollte schnell mal ein Programm modifizieren und dachte mir ich mache es per overlay...

also overlay unter

```
/usr/local/portage
```

gebildet

ebuilds samt Kategory und co aus dem orig-Portage reinkopiert

```

/usr/local/portage/app-category/app

/usr/local/portage/app-category/app/ebuild

...

```

dann auspacken

```
ebuild /usr/local/portage/app-category/app/ebuild unpack
```

rein ins tmp-Verzeichnis

```
/var/tmp/portage/app-category/app/work/app
```

*hier irgendwas am source ändern*

und dann kompilieren

```
ebuild /usr/local/portage/app-category/app/ebuild compile
```

und

```
ebuild /usr/local/portage/app-category/app/ebuild install
```

und dann prog emergen -> emerge gibt dann an dass es vom overlay emergen möchte.

Ist das insoweit richtig??   :Rolling Eyes:   Konnte nämlich meine eigenen Änderungen im Prog nicht feststellen...

----------

## nilres

Zu dem vorgehen kann ich nichts sagen aber du könntest ja einfach mal am anfang des programms eine test ausgabe machen.

mfg nils

----------

## Necoro

wenn du direkt emerge paket machst, löscht er vorher das alte working-dir im temp (und damit ist deine Änderung natürlich weg). Wenn du schon direkt mit dem ebuild programm arbeitest, solltest du auch damit abschließen:

```
ebuild /usr/local/portage/app-category/app/ebuild merge
```

Da du direkt im tmp Verzeichnis rumwerkelst, ist es übrigens unnötig, das Ebuild vorher ins Overlay zu verschieben  :Smile: 

Sinnvoller wäre folgende Vorgehensweise:

Overlay anlegen

Ebuild kopieren

```
ebuild /usr/portage/local/app-category/app/ebuild unpack
```

im tmp-dir die Änderungen machen

diff zum Original speichern (in /usr/portage/local/app-category/app/files)

ebuild im Overlay so abändern, dass es den gerade erstellen Patch immer anwendet

normal emerge verwenden

----------

## c_m

vor dem emergen aber bitte den digest neu machen, sonst könnts fehler geben  :Wink: 

----------

## JKRock

 *Necoro wrote:*   

> wenn du direkt emerge paket machst, löscht er vorher das alte working-dir im temp (und damit ist deine Änderung natürlich weg). Wenn du schon direkt mit dem ebuild programm arbeitest, solltest du auch damit abschließen:
> 
> ```
> ebuild /usr/local/portage/app-category/app/ebuild merge
> ```
> ...

 

Danke für die ausführliche Beschreibung, aber ich glaub ich habe nicht alles verstanden...

Zumindest hat es jetzt geklappt, wenn ich mit 

```
ebuild /usr/local/portage/app-category/app/ebuild merge
```

 abschließe.

diese Aussage verstehe ich zum Beispiel nicht:

 *Quote:*   

> Da du direkt im tmp Verzeichnis rumwerkelst, ist es übrigens unnötig, das Ebuild vorher ins Overlay zu verschieben 

 

```
ebuild /adresse/ebuild_prog unpack
```

  packt doch immer alles im tmp aus - nur da sind die sourcen geöffnet, oder?

Auch weiss ich nicht wie ich denn bei deiner vorgehensweise die diffs zum Orginal speichern soll

 *Quote:*   

> diff zum Original speichern (in /usr/portage/local/app-category/app/files)

 

Ebenso so Fragezeichen bei:

 *Quote:*   

> ebuild im Overlay so abändern, dass es den gerade erstellen Patch immer anwendet

 

- Oder ist dafür das Manifest zuständig?

gruß JKRock

----------

## JKRock

 *c_m wrote:*   

> vor dem emergen aber bitte den digest neu machen, sonst könnts fehler geben 

 

mmh, auch Bahnhof....

----------

## Necoro

 *JKRock wrote:*   

> diese Aussage verstehe ich zum Beispiel nicht:
> 
>  *Quote:*   Da du direkt im tmp Verzeichnis rumwerkelst, ist es übrigens unnötig, das Ebuild vorher ins Overlay zu verschieben  
> 
> ```
> ...

 

Ich meinte damit: Da du das Ebuild ja nicht änderst - welchen Sinn macht es denn, es extra in ein Overlay zu kopieren? - Kannst doch auch direkt aus dem normalen Tree entpacken  :Smile: 

 *Quote:*   

> Auch weiss ich nicht wie ich denn bei deiner vorgehensweise die diffs zum Orginal speichern soll

 

z.B:

```
> cd /var/tmp/portage/.../

> bzr init

> bzr add

> bzr ci -m "Init"

> # ändern der sachen

> bzr diff > the.patch

> cp the.patch /usr/local/portage/app-cat/app/files/
```

(Statt bzr kann man natürlich auch git, hg, monotone, darcs, tla, ... nehmen.  :Wink: )

 *Quote:*   

> Ebenso so Fragezeichen bei:
> 
>  *Quote:*   ebuild im Overlay so abändern, dass es den gerade erstellen Patch immer anwendet 

 

Stichwort: epatch -- Schau einfach mal in einen Stapel ebuilds (möglichst nicht die hochkomplizierten) wie das verwendet wird ... oder schau ins devmanual (hab leider gerade keinen Link zur Hand)

Zum digest (bzw: manifest -- digest ist veraltet): 

```
ebuild /path/to/ebuild manifest
```

  :Smile: 

----------

## c_m

 *JKRock wrote:*   

>  *c_m wrote:*   vor dem emergen aber bitte den digest neu machen, sonst könnts fehler geben  
> 
> mmh, auch Bahnhof....

 

schau mal hier: http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1

Da steht alles wichtige übers ebuild system (Wofür die ganzen Funktionen sind usw)

Und das hier: http://gentoo-wiki.com/HOWTO_Create_an_Updated_Ebuild

wäre wohl die richtige Anleitung für dein Vorhaben.

Punkt 3.2.2 ist das wovon ich sprach. Quasi die interne verifizierung, dass die Datenpakete vertrauenswürdig sind.

----------

## mattes

 *Quote:*   

>  *Quote:*   Auch weiss ich nicht wie ich denn bei deiner vorgehensweise die diffs zum Orginal speichern soll 
> 
> z.B: Code:
> 
> > cd /var/tmp/portage/.../ 
> ...

 

Hallo,

geht auch einfacher ohne VC: 

$cp orig.file neu.file

Ändern neu.file

$diff orig.file neu.file >> Patch

Wenn dann der Patch per

$ patch orig.file Patch 

angewendt wird -> orig.file == neu.file

----------

## Necoro

 *mattes wrote:*   

> $cp orig.file neu.file
> 
> Ändern neu.file
> 
> $diff orig.file neu.file >> Patch

 

Stimmt schon ... aber das wird mühsam wenn man mehr als eine Datei ändern will  :Smile: . Bei kleinen Änderungen, wo man auch die zu ändernde Datei im Voraus kennt, ist dein Ansatz aber schneller  :Smile: 

/edit:

 *Quote:*   

> Und das hier: http://gentoo-wiki.com/HOWTO_Create_an_Updated_Ebuild
> 
> wäre wohl die richtige Anleitung für dein Vorhaben. 

 

Hinweis: ebuild $EBUILD digest aber durch ebuild $EBUILD manifest ersetzen ... die Digest-Files sind veraltet  :Smile: 

----------

## JKRock

hi,

 wieder danke an alle für die zahlreichen antworten,

...leider klappt es bei mir nicht mittels Patch

wie vorgeschlagen benutze ich bzr um differenzen zu erfassen:

 *Quote:*   

> 
> 
> z.B: Code:
> 
> > cd /var/tmp/portage/.../
> ...

 

und diesen gewonnen patch liste ich bei der src_unpack funtion auf:

src_unpack(){

unpack ${A}

..

epatch "${FILESDIR}"/newpatch

dann führe ich diese Komandos aus

ebuild ebuild-app manifest

ebuild ebuild-app compile

ebuild ebuild-app install

ebuild ebuild-app qmerge

(ich weiss dass es kürzer geht..)

Aber meine patches werden irgendwie nicht bearbeitet...

gruß JKRock

----------

## Necoro

Führe mal vor dem "compile" noch ein "clean" aus, so dass er das Working Directory neu erstellt... und dabei mal darauf achten, ob er beim Auspacken was von wegen patchen schreibt  :Smile: 

----------

## JKRock

 *Necoro wrote:*   

> Führe mal vor dem "compile" noch ein "clean" aus, so dass er das Working Directory neu erstellt... und dabei mal darauf achten, ob er beim Auspacken was von wegen patchen schreibt 

 

Das kompilieren schlägt jetzt fehl.

Jetzt sieht es so aus als wenn er meine Patches irgendwie nicht ausführen kann...

Aussagekräftig ist der log ja aber nicht:

```

[32;01m*[0m Applying proFormPatch ...

[0m Failed Patch: proFormPatch !

...

 [31;01m*[0m 

 [31;01m*[0m ERROR: net-im/twinkle-1.0.1-r1 failed.

 [31;01m*[0m Call stack:

 [31;01m*[0m               ebuild.sh, line   49:  Called src_unpack

 [31;01m*[0m             environment, line 4047:  Called epatch 'src_unpack'

 [31;01m*[0m             environment, line 2090:  Called die

 [31;01m*[0m The specific snippet of code:

 [31;01m*[0m                   die "Failed Patch: ${patchname}!";

 [31;01m*[0m  The die message:

 [31;01m*[0m   Failed Patch: proFormPatch!

...

 
```

Vom Inhalt kann ich keine Unterschiede zu anderen Patches ausmachen...

Was kann ich nur machen?

gruß JKRock

----------

## Necoro

Normalerweise sollte er auch ein log anlegen in der steht, was genau schief gelaufen ist ...

ansonsten poste mal den patch  :Smile:  (bzw verlinke ihn)

----------

## JKRock

 *Necoro wrote:*   

> Normalerweise sollte er auch ein log anlegen in der steht, was genau schief gelaufen ist ...
> 
> ansonsten poste mal den patch  (bzw verlinke ihn)

 

hier sind log, patch und ebuild

----------

## Necoro

1.) Bitte NIE wieder RapidShare ... von der Firma aus kommt man da net drauf  :Wink: 

2.) Bitte Fehlermeldungen aufmerksam lesen: "Include in your bugreport the contents of:  /var/tmp/portage/net-im/twinkle-1.0.1-r1/temp/twinkle.proform-13396.out"

3.) Patches haben die Dateiendung "patch" oder "diff" und nicht "proform"

4.) Das "bzr init" (oder äquivalent) immer im working directory machen -- die pfade für die patches starten von hier ... für deinen Fall wäre es zB "/var/tmp/portage/net-im/twinkle-1.2-r1/work/twinkle-1.2" und nicht "/var/tmp/portage/net-im/twinkle-1.2-r1/work/twinkle-1.2/src"

Punkt 4 sollte denn auch deinen Fehler beheben  :Wink: 

----------

## JKRock

 *Necoro wrote:*   

> 1.) Bitte NIE wieder RapidShare ... von der Firma aus kommt man da net drauf 
> 
> 2.) Bitte Fehlermeldungen aufmerksam lesen: "Include in your bugreport the contents of:  /var/tmp/portage/net-im/twinkle-1.0.1-r1/temp/twinkle.proform-13396.out"
> 
> 3.) Patches haben die Dateiendung "patch" oder "diff" und nicht "proform"
> ...

 

super - danke, Punkt 4 war es wirklich!

zu 3) sorry, dachte ich hätte wirklich irgendwo gelesen, dass nur die offiziellen Gentoo-Patches die Endung .patch haben dürften... naja

zu 1) welcher Filehoster ist denn hier üblich?

zu 2) sorry, hatte das überlesen...

gruß JKrock

----------

## Necoro

 *JKRock wrote:*   

> zu 3) sorry, dachte ich hätte wirklich irgendwo gelesen, dass nur die offiziellen Gentoo-Patches die Endung .patch haben dürften... naja

 

Wenn es in deinem lokalen Overlay liegt, kann dir sowas egal sein  :Wink: . Eigentlich kann dir auch die Benennung allg. denn egal sein - aber wenn man die Patches denn weiterschickt, sorgen andere Endungen für Verwirrung  :Wink: 

 *Quote:*   

> zu 1) welcher Filehoster ist denn hier üblich?

 

Entweder eigener Webspace - oder auf pastebin.ca o.ä.

----------

