28/9/2018

Git voorbeeld: SourceForge

Filed under: — cybrarian @ 10:24 am

(Reeks Githandboek (nl)commando’s vbbranch, mergeGitLab vbSourceForge vbgit en gambas)

SourceForge (https://sourceforge.net/) was in de open source en free softwarewereld zowat de eerste, grootste en bekendste website voor het online houden van een open source of free software project. Je kon de broncode gewoon uploaden als .tar.gz bestanden, of het Code Versioning System gebruiken (cvs), naast de vele project-tools voor opvolging van bugs, communicatie enz. (zie 2009)

SourceForge heeft achtergrond in VA Software (denk ook aan VA Linux, Geeknet, enz), ondertussen horen ze bij Slashdot media.
Het traject van de zoektocht naar rendabiliteit en de overnames deed Sourceforge geen goed en zaaide twijfel bij developers.
Heel wat nieuwe projecten gingen naar GitHub, (en meer recent GitLab), die specifiek gericht waren op het ondertussen in de FOSS wereld populaire geworden git-broncodebeheersysteem.

Maar ondertussen biedt SourceForge ook Git aan. Sinds januari 2018 promoten ze het aktief met een importeer-tool om GitHub projecten over te zetten naar SourceForge.
https://sourceforge.net/blog/introducing-the-new-sourceforge/

Wie al op Sourceforge zit kan zijn project beginnen beheren met git: https://sourceforge.net/p/forge/documentation/Git/

Om gemakkelijk te communiceren met de sourceforge repository is het best om een public key/private key communicatie op te zetten. Daarvoor moet je een “key” hebben, die je maakt met ssh-keygen.
Daarna moet je de projectdirectory initialiseren voor gebruik met git. En dan moet je je startcode “uploaden”, in git-terminologie comit-en en push-en.

1. Keys

1.1 keys maken:

De handleiding van sourceforge zegt:

ssh-keygen -t ed25519 -C “gebruikersnaam@shell.sf.net”

De plaats waar je dit doet is eender (bv kan je al in de projectdirectory staan).
De gebruikersnaam is die van je login, niet de weergegeven naam!
Na het commando krijg je de vraag in welk bestand de key bewaard mag worden, je kan het voorstel gewoon bevestigen.
Daarna kan je een wachtwoord ingeven (veiliger), wat je moet heringeven om te bevestigen.
Het eindigt met de plaatsen waar je identificatie en je public key bewaard werden*, en met je fingerprint.
Daaronder komt een beetje “ascii-art” met je randomart image.
* Je kan je instellingen checken in de bestanden:
private key: /home/usernaam/.ssh/id_ed25519 (deze moet je geheim houden!)
public key: /home/usernaam/.ssh/id_ed25519.pub (deze moet je meedelen)

1.2 keys registreren

Log in op SF en ga naar:
https://sourceforge.net/auth/shell_services
Daar plak je de inhoud van je .pub bestand.

2. Projectdirectory

De directory die je wil opnemen in het git beheer moet je initialiseren voor git gebruik.
Ga in de directory staan (cd projectdir), en check git:

git status
Als je … krijgt is er al een git repository van gemaakt!
Als er nog geen git initialisatie gebeurd is op deze directory krijg je een melding als:

fatal: Not a git repository

…(enz)

Tik het initialisatiecommando dat de nodige subdirectories en bestanden maakt:
init git

Initialised empty Git repository in …

Opgelet! Nu zijn er een aantal (onzichtbare) directories/bestanden bijgekomen voor git, gebruik deze projectdirectory niet meer om op een andere manier te kopiëren als project sourcecode, want hij is “vervuild” met git.

3. Stel de bron in

Als de broncode nog niet in de directory staat, kopieer je die ernaartoe. Ze vormen de verzameling van alle onderdelen die je nodig hebt om een programma te kunnen compileren.
Met git status toont git wat het daar ziet.

Je stelt ook de bestanden in die NIET naar de git-server moeten, omdat ze enkel lokaal nut of belang hebben (bv lokale instellingen van de programmeeromgeving), of omdat ze prive-informatie bevatten.
Maak daarvoor een bestand .gitignore in de projectdirectory.

git rm --chached (file) om iets wat er per vergissing toch is terechtgekomen; check met git status.

git commit -am ‘initial commit at version 0.1.5’

Je krijgt de melding dat een ‘standaard’ e-mail adres gebruikt is; je kan het instellen met:

git config --global --edit

pas aan, bewaar (standaard met ESC :w en :q), en daarna fix de identiteit die gebruikt werd met:

git commit --amend --reset-author

Je krijgt dan een tekst te zien (waarin je bv het e-mail adres kan verbeteren, dacht ik, maar dat blijkt achteraf niet met git log**); ook weer ESC :wq om te bewaren en verlaten.

4. Stel de server in

Nu moet je een verbinding instellen met de server, waar de broncode naartoe moet.

git remote add origin ssh://login@git.code.sf.net/p/gitin/code

(met je eigen login natuurlijk; de username).

En dan de eigenlijke “upload”:

git push -u origin master
Er wordt een bevestiging gevraagd van de git.code.sf.net server (met ip)
Die wordt dan toegevoegd aan de “known hosts”.
Daarna moet je je wachtwoord ingeven (dat van de ssh key).

Met wat geluk eindigt alles met:

Branch master set up to track remote branch master from origin.

Nu kan je via de website het resultaat zien onder het tabblad “code”:
https://sourceforge.net/p/projectname/code/

De projectdirectory is volledig te “browsen”!
Onderaan verschijnt de inhoud van het readme.txt bestand.

Zeer handig is de kolom “Commit”, want daar verschijnt de commit message, en je kan daarmee snel zien wat de laatste verandering is in een directory of bestand.


**)
Je moet eerst expliciet de gegevens instellen, bv het e-mail adres wordt afgeleid uit je username en je hostname, dus je krijgt username@host, en dat kan bv de lokale hostname van je pc zijn.

Je moet dan eerst expliciet de username of het e-mail adres instellen:

git config --global user.name "gebruikersnaam"
git config --global user.email "user@domein.abc"


5. Gebruik.

– Code

git commit -am 'initial commit at v.0.1.3'

Nadat van een project de originele code naar de server geladen is, wordt ze zichtbaar in de “code” tab van de Sourceforge website, bv als:

Tree[987456] master/

Op die pagina krijg je ook de commando’s aangeboden die je nodig hebt om ssh/https/RO (read-only) toegang te krijgen.

– Clone

RO is genoeg om het project af te halen:

git clone git://git.code.sf.net/p/projectnaam/code projectnaam-code

Dit maakt een lokale directory projectnaam-code, verwijzend naar de structuur op de server (beetje verschillend van GitLab).

Om ook schrijftoegang te hebben moeten eventueel de rechten aangepast worden door de admin van het project, en moet je één van de voorgestelde read/write commando’s geven.

git branch --list toont: “* master”

fatal: remote error: access denied or repository not exported…

Als je oorspronkelijk enkel read-access hebt gevraagd (bij project clone), kan je nadien de instellingen aanpassen in het .git/config bestand. Volgens de documentatie:

git://PROJECTNAME.git.sourceforge.net/gitroot/PROJECTNAME/REPONAME (read-only)
ssh://USERNAME@PROJECTNAME.git.sourceforge.net/gitroot/PROJECTNAME/REPONAME (read/write)

Bij mij zag het er iets anders uit:

url = git://git.code.sf.net/p/projectnaam/code

url = ssh://USERNAME@git.code.sf.net/p/projectnaam/code

Zoek de regel die begint met git:// en verander hem naar ssh:// waarbij je “USERNAME@” toevoegt (maar dan je echte loginnaam natuurlijk).

9/9/2018

Teamviewer gebruiken

Filed under: — cybrarian @ 11:07 pm

Na installatie van Teamviewer op openSUSE Leap 42.3 komt het programma voor in het Kde menu onder systeem of hulpmiddelen? Nee, onder “Internet”.

Bij het starten geeft het een aantal gegevens die je kan gebruiken om een koppeling te maken met een andere computer.

user id

password

Op de “andere computer” start je ook het programma.

De id invullen, het wachtwoord invullen…

(Eerste keer blijft hij altijd het wachtwoord vragen, alsof het fout is. In beide richtingen trouwens, als ik omgekeerd probeer ook dus. Ik moet afsluiten wegens tijdgebrek en beslis morgen verder te proberen).

Volgende dag lukt het wel: open het programma op beide computers, neem het nummer van de ene mee, alsook het wachtwoord; en je krijgt het scherm te zien.

De verbinding is niet razendsnel; je moet echt wel rekening houden met de vertraging bij bv het typen van een tekst, het verplaatsen vergroten/kleinen van vensters, enz.

Maar het werkt dus wel, je kan op afstand iemand helpen.

Teamviewer installeren

Filed under: — cybrarian @ 10:23 pm

Teamviewer op openSuse Leap 42.3

1. download 32 of 64 bit versie? Suse 64bit. (kies “Save File” (Bewaren) in de browser)
www.teamviewer.com/nl/download/linux/

2. ga naar de download map (klik op download pijl rechtsboven in Firefox, kies “open containing folder”)
Open een terminal (rechtsklik actions, open terminal here) en installeer met de commandolijn:

sudo zypper install teamviewer-suse_13.2.13582.x86_64.rpm

Loading repository data…
Reading installed packages…
Resolving package dependencies…

The following NEW package is going to be installed:
teamviewer-suse

1 new package to install.
Overall download size: 12.2 MiB. Already cached: 0 B. After the operation, additional
59.3 MiB will be used.
Continue? [y/n/…? shows all options] (y):

y

Retrieving package teamviewer-suse-13.2.13582-0.x86_64
(1/1), 12.2 MiB ( 59.3 MiB unpacked)
teamviewer-suse_13.2.13582.x86_64.rpm:
Header V4 RSA/SHA1 Signature, key ID 0c1289c0: NOKEY
V4 RSA/SHA1 Signature, key ID 0c1289c0: NOKEY

teamviewer-suse-13.2.13582-0.x86_64 (Plain RPM files cache): Signature verification failed [4-Signatures public key is not available]
Abort, retry, ignore? [a/r/i] (a):

Er wordt een vraag gesteld over signing; blijkbaar deden ze dat nooit, de packages signen voor Linux, dus ik ignore de waarschuwing met i.

i

Checking for file conflicts: ……………………………………………..[done]
(1/1) Installing: teamviewer-suse-13.2.13582-0.x86_64 ……………………….[done]
Additional rpm output:
warning: /var/cache/zypper/RPMS/teamviewer-suse_13.2.13582.x86_64.rpm: Header V4 RSA/SHA1 Signature, key ID 0c1289c0: NOKEY
gtk-update-icon-cache: Cache file created successfully.

3. Start de daemon (kan al gestart zijn door de installatie)
Check eerst of hij al loopt, zo ja, geen probleem.

systemctl status teamviewerd

systemctl status teamviewerd
● teamviewerd.service – TeamViewer remote control daemon
Loaded: loaded (/etc/systemd/system/teamviewerd.service; enabled; vendor preset: disabled)
Active: active (running) since Sun 2018-09-09 23:22:12 CEST; 3min 9s ago
Process: 5628 ExecStart=/opt/teamviewer/tv_bin/teamviewerd -d (code=exited, status=0/SUCCESS)
Main PID: 5633 (teamviewerd)
Tasks: 16 (limit: 512)
CGroup: /system.slice/teamviewerd.service
└─5633 /opt/teamviewer/tv_bin/teamviewerd -d

Sep 09 23:22:12 TCM-S4VCR72 systemd[1]: Starting TeamViewer remote control daemon…
Sep 09 23:22:12 TCM-S4VCR72 systemd[1]: teamviewerd.service: PID file /var/run/team…ry
Sep 09 23:22:12 TCM-S4VCR72 systemd[1]: Started TeamViewer remote control daemon.
Hint: Some lines were ellipsized, use -l to show in full.

Zo nee, start hem manueel.
sudo systemctl start teamviewerd

4. Voeg toe aan de opstartfase als je dat wil.

sudo systemctl enable teamviewered

Het desktopprogramma is opgenomen in het menu Internet als Teamviewer 13.

Geraadpleegde bron: www.linuxbabe.com

Zie verder: Wacht om te zien of het werkt … Teamviewer gebruiken op Linux

4/9/2018

Git gebruik organiseren: branches, comit, merge

Filed under: — cybrarian @ 8:59 pm

(Reeks Githandboek (nl)commando’s vbbranch, mergeGitLab vbSourceForge vbgit en gambas)
Zie ook artikel over branches in git, (Engelstalig, 2015)

Branch commando’s

git branch (--list)= toon branches; git branch -a = toon alle (ook remote)
git branch -v = toon laatste commit messages
git branch Testing = maak nieuwe branch met naam “Testing”
git checkout Testing = overschakelen naar branch
git checkout -b Testing2 = maken en overschakelen naar nieuwe branch (die op het moment wordt gemaakt; combinatie van branch en checkout)
git merge bugfix = merge bugfix in huidige branch (vorige checkout branch, hier dus Testing)
git branch -d bugfix = verwijder branch (gaat niet? checked out?)

Branch, merge
Veelgebruikte struktuur van vertakkingen:

Master branch (-> production server)
Develop branch (-> staging server)

  • Feature branch
  • Hotfix branch
  • Release branch
  • Support branch

Git Branching and merging strategies beschrijft het zo:

Master – Test – Develop

Uit Master wordt initieel test gemaakt, uit test develop, en uit develop de feature branches.

Master - Test - Develop -- Feature-1
                        -- Feature-2

(

De Develop stage krijgt updates uit de feature branch die gewijzigd is;

.. Develop <-- Feature-1
           <-- Feature-2

De feature branches houden zich up to date door de wijzigingen uit de develop regelmatig af te halen (rebase). Hoe beter ze onderling op de hoogte blijven van de ontwikkeling, hoe minder conflicten later.

.. Develop --> Feature-1
           --> Feature-2

En alles van develop gaat uiteindelijk naar boven naar test, dan naar Master.

Vanuit Master wordt een Release 1.0 branch gemaakt.
Later vanuit Master een Release 2.0 branch.

De bugs die ontdekt worden in de Release branches, kunnen gepatcht worden (éérst op eerste versie waar die voorkomt)
bv comit op Release 1 –
van daaruit Merge naar Release 2
van daaruit Merge naar Develop (waarna het met rebase bij de feature branches komt, en waar het klaar zit voor de volgende release naar boven)

Overzicht van bestaande branches:

git branch --list

bugfix
* master
testing

Verschillende commits:

  • Merge
  • Fast-Forward
  • Rebase

Branch namen

Vb van een prefix die onderscheidend werkt:

feat-shortname bv: feat-stocklist
fix-shortname bv: fix-bugitem1234
hot-shortname bv: hot-fixCrashStartWithoutDb
rel-shortname bv: rel-v1-2
try-shortname bv: try-stocklistlocalcache

Branch lokaal-remote

Een lokaal gemaakte branch kan nadien gewoon naar de server gestuurd worden:

git push origin feat-1

of ook:

git push --set-upstream origin test
korte versie:
git push -u origin test

Voorbeeld 1 merge (recursive):

master: bestand 1 veranderd; commit
develop: bestand 2 veranderd; commit

git checkout master
git merge testing

Merge made by the ‘recursive’ strategy.
TweedeBestand.txt | 1 +
1 file changed, 1 insertion(+)

Voorbeeld 2 merge (fast-forward):

git checkout master
git checkout -b bugfix

Switched to a new branch ‘bugfix’

Wijzig bestand 2, en …

git commit -a -m "voeg commentaar toe"

[bugfix 02aa0b3] voeg commentaar toe
1 file changed, 1 insertion(+)

git checkout master

Switched to branch ‘master’
Your branch is ahead of ‘origin/master’ by 3 commits.
(use “git push” to publish your local commits)

git merge bugfix

Updating feb4282..02aa0b3
Fast-forward
TweedeBestand.txt | 1 +
1 file changed, 1 insertion(+)


Voorbeeld 3: opkuisen na merge

Daarna mag de tak van de bugfix weg:

git branch -d bugfix

Deleted branch bugfix (was 02aa0b3).

Als hij nog aktief staat krijg je een fout:

error: Cannot delete branch ‘bugfix’ checked out at ‘/home/..

Voorbeeld 4 merge (rebase)

branch master, test, feat-1, feat-2

wijzigingen feat-1, commit
wijzigingen feat-2, commit

git checkout test
git status

git merge feat-1

Updating f276191..804f3c6
Fast-forward
Project/.src/Filename.class | 12 +++++++++++-
… (bestanden en wijzigingen)
12 files changed, 291 insertions(+), 37 deletions(-)
create mode 100644 Project/.src/FGetText.class
create mode 100644 Project/.src/FGetText.form

git merge feat-2

Auto-merging Project/Changes.txt
Auto-merging Project/.src/MForm.module
Auto-merging Project/.src/FMain.class
Merge made by the ‘recursive’ strategy.
Project/.src/FMain.class | 2 +-
Project/.src/MForm.module | 1 +
… (bestanden en wijzigingen)
7 files changed, 646 insertions(+), 1 deletion(-)
create mode 100644 Project/.src/Class/CIntWeek.class
create mode 100644 Project/.src/Forms/FInterim.class

Om in mijn feat-1 alle wijzigingen van test al mee te krijgen:

git checkout feat-1
git rebase test

Opm:
– alhoewel niet iedereen voorstander is van rebase gebruik, zie ook fetch/merge, pull
– “never force push to a shared branch”, “don’t rebase on shared branches”, zegt Julia Evans

Voorbeeld 5 merge (diverged/rebase)

Zie hier…
http://linuxuser.copyleft.be/liglog/?p=7490

Merge Error 1

Fout op 1 bestand dat lokaal veranderd is, maar enkel een .settings bestand is dat mag overschreven worden:

git reset --hard
Daarna terug de merge.

Merge Error 2

git checkout test
git merge feat-1

Auto-merging Proj/Changes.txt
CONFLICT (content): Merge conflict in Proj/Changes.txt
Automatic merge failed; fix conflicts and then commit the result.

git status

On branch test
You have unmerged paths.
(fix conflicts and run “git commit”)
(use “git merge –abort” to abort the merge)

Changes to be committed:

modified: Proj/.src/ProjForms/FInterim.class
modified: Proj/.src/ProjForms/FInterim.form

Unmerged paths:
(use “git add …” to mark resolution)

both modified: Proj/Changes.txt

Inderdaad, de Changes.txt file is gewijzigd in beide takken. Als je het bestand in de huidig aktieve branch (de merge branch Test in dit geval) opent, zal je aanduidingen zien van de overlapping:

0.1.2 
...
< <<<<<< HEAD

FFactoring:
0.1.2 
=======
>>>>>>> feat-interim

HEAD : geeft de “hoofd”-branch aan, waar naartoe gemerged wordt, waarna die tekstversie
====== : geeft de scheiding aan naar het begin van de ingevoegde (feature-,..) branch en de bijhorende tekstversie
Ook de ingevoegde branch naam staat er achter.

Maak van de tekst de versie die het uiteindelijk moet worden, combineer beide stukken of gooi wat weg.
Stage de veranderingen met git add .
Commit de veranderingen met git commit -m "Resolve merge conflict by combining and ordening changes.txt"

Probeer daarna opnieuw een merge.

3/9/2018

Docker hierarchie enz

Filed under: — cybrarian @ 1:09 pm

Hierarchie

concept:

Stack
Services
Container

container directory/files:

directory/dockerfile
directory/app.py
directory/requirements.txt

Woordenlijst

dockerfile : definiëert de container

Python

Docker lijkt sterk gebruik te maken van Python (zie ook installatie)

Docker in Yast

Filed under: — cybrarian @ 12:46 pm

Installeren:
– Yast, Softwarebeheer, zoek docker
– docker, docker-bash-completion, docker-libnetwork, docker-runc, docker-zhs-completion, ruby2.1-rubygem-docker-api, yast2-docker, zypper-docker (docker-compose)
– installeer.

Controleren:

Yast Control Center, Virtualisatie, Docker.

Start de module met venster YaST2 – docker @ host.loc

Twee tabbladen: Images en Containers.

Containers toont de “running docker containers”

Na het starten van het “Hello World” voorbeeld (zie commando’s), wordt in tabblad [Images] zichtbaar:

hello-world latest sh256:2cb0d 2018-07-11T00:32:08+00:00 1.80 KiB

Docker commando’s

Filed under: — cybrarian @ 12:38 pm

Docker
(voorbeelden op OpenSUSE, volg de gids op docs.docker.com)

Docker installeren:
zypper install docker docker-compose

Docker starten
systemctl start docker

Docker stoppen
systemctl stop docker

Docker automatisch laten starten:
sudo systemctl enable docker

Docker groep vervoegen:
sudo usermod -G docker -a GEBRUIKERSNAAM

Versie van Docker:
host:/home/gebruikersnaam # docker --version

Docker version 17.09.1-ce, build f4ffd2511ce9

Aktieve containers:
host:/home/gebruikersnaam # docker ps

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

(niets in gebruik hier)

Meer info:
host:/home/gebruikersnaam # docker info

Containers: 0
Running: 0
Paused: 0
Stopped: 0
Images: 0
Server Version: 17.09.1-ce
Storage Driver: btrfs
Build Version: Btrfs v4.5.3+20160729
Library Version: 101
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge host macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: runc oci
Default Runtime: runc
….

Hallo Wereld!
docker run hello-world

Unable to find image ‘hello-world:latest’ locally
latest: Pulling from library/hello-world
9db2ca6ccae0: Pull complete
Digest: sha256:4b8ff392a12ed9ea17784bd3c9a8b1fa3299cac44aca35a85c90c5e3c7afacdc
Status: Downloaded newer image for hello-world:latest

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
1. The Docker client contacted the Docker daemon.
2. The Docker daemon pulled the “hello-world” image from the Docker Hub.
(amd64)
3. The Docker daemon created a new container from that image which runs the
executable that produces the output you are currently reading.
4. The Docker daemon streamed that output to the Docker client, which sent it
to your terminal.

# docker image ls

REPOSITORY TAG IMAGE ID CREATED SIZE
hello-world latest 2cb0d9787c4d 7 weeks ago 1.85kB

# docker container ls

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

# docker image ls --all

REPOSITORY TAG IMAGE ID CREATED SIZE
hello-world latest 2cb0d9787c4d 7 weeks ago 1.85kB

# docker image ls -aq

2cb0d9787c4d

(q = quite mode)

Powered by WordPress