# Help me resurrect an old port



## Phishfry (Jun 13, 2019)

I am trying to resurrect an old port for my personal use. multimedia/kino is the deleted port name.
From my web search I should be able to checkout an old port with this directive:
`svnlite co -r 341905 svn://svn.freebsd.org/ports/head/multimedia/kino /usr/ports/multimedia`
But when I do it appears to be trying to use a new revision instead of what I directed.

```
svn: E160013: File not found: revision 504127, path '/head/multimedia/kino'
```

What am I doing wrong? Obviously kino is not in r504127
Why is it not using the revision I want?


----------



## malavon (Jun 13, 2019)

https://svnweb.freebsd.org/ports?view=revision&revision=338190
That one contains the last change in the Makefile before the removal.


----------



## malavon (Jun 13, 2019)

Btw. it's been long since I've used svn, but if you have a ports tree checked out with Git you can also do this:
`git log -- multimedia/kino`
Mind the double dash though, it's important in this case.


----------



## Phishfry (Jun 13, 2019)

Could this be because I have an existing ports tree?

`svnlite co -r 338190 svn://svn.freebsd.org/ports/head/multimedia/kino /usr/ports/multimedia`
svn: E160013: File not found: revision 504127, path '/head/multimedia/kino

Thanks anyway, I will manually build the files from svnweb


----------



## Phishfry (Jun 13, 2019)

The more I think about it I will be chasing old dependencies so this whole exercise is futile.


----------



## malavon (Jun 13, 2019)

I don't dare say, it's been so long since I've used subversion that I barely remember the syntax.
But testing the same command without /kino in the url does work apparently.


----------



## malavon (Jun 13, 2019)

I had considered that as well, it all depends whether or not that piece of software still builds with current versions of libs.
I don't know it, so can't say much about that.


----------



## Phishfry (Jun 13, 2019)

KDEnlive yanked Firewire capture support with QT5
I would like to have a preview window for capture.
That was my whole reasoning here.


----------



## Phishfry (Jun 13, 2019)

I see what you are saying, I can grab the whole /multimedia ports category but not the individual port.


----------



## SirDice (Jun 14, 2019)

If you already have an existing ports tree (that's up to date), just `cd /usr/ports/multimedia`. Then `mkdir kino` and `cd kino && svn update -r 338190 .`. That should restore it. There's probably a better way to this but this has worked for me in the past.


----------



## Phishfry (Jun 14, 2019)

I tried to resurrect a relativity recently deleted port of multimedia/kdenlive-kde4 and I feel like print/texinfo was created by the devil himself.
Alas I am not the first to run into this steaming hunk of a port. Posts littered all over.


			make install for print/texinfo fails on -CURRENT
		


I ran `make config-recursive` and made sure no docs were selected yet texinfo is pulled in.
How can I blast past this plumbing cloggage.
It seems to be related to the version. I found the checksum wrong and tried to manually place in distfiles/texinfo/ yet failure.


----------



## SirDice (Jun 14, 2019)

Phishfry said:


> I found the checksum wrong and tried to manually place in distfiles/texinfo/ yet failure.


`make makesum` is useful. It downloads the distfile and creates an appropriate distfile for it. Another one I found to be quite useful is `make makeplist > pkg-plist` to generate a pkg-plist file. Make sure to review that file though.


----------



## Phishfry (Jun 14, 2019)

I tried that with no feedback.
The versions of htmlxref.cnf and texi2dvi have the wrong file size. (For ver. 6.5 of texinfo)
When I fished through distcache.freebsd.org I found that the 6.4 version of texinfo file sizes were correct or what was stopping `make`.
So like `make` advised I manually put the files it was looking for in /usr/ports//distfiles/texinfo/ and restarted make.
That did not seem to work.


----------



## Phishfry (Jun 14, 2019)

How can I ramrod this through without texinfo. I will never ever need it.
When I do FreeBSD source work we have a NO_DOCS flag. Can I use that with ports?


----------



## malavon (Jun 14, 2019)

Phishfry said:


> When I do FreeBSD source work we have a NO_DOCS flag. Can I use that with ports?


From what I can see on FreshPorts:


> DOCS=on: Build and/or install documentation
> DVDWIZARD=on: DVD authoring via DVDAuthor and cdrtools
> FREI0R=on: Frei0r video plugins support
> LADSPA=on: LADSPA audio plugins support
> ...


But I expect you probably already tried `make config`.
You could try removing any dependency from the makefile entirely and see if you can get it to run w ithout?


----------



## Phishfry (Jun 14, 2019)

No luck with `make -DNODOCS install`
It wants to build texinfo.

Yes I have ran `make config-recursive`
`make rmconfig`
make make unmake

I seem to lost the config sheets for the leaf ports. It don't seem to delete them with rmconfig.
That is probably my issue.
Where exactly are the config settings anyway? I assumed in the ports work directory.
Edit:  The proper approach was `make rmconfig-recursive`


----------



## Phishfry (Jun 25, 2019)

Well I have to say, all it took was reading /usr/ports/Mk/bsd.port.mk source and now I have old print/texinfo building.
I had to force through the older versions as something was amiss with the file sizes of versions.
`make build DISABLE_SIZE=yes`
I know this is not good but when resurrecting an old port sometimes you have to improvise.
Tomorrow I can try again with some forward momentum.


----------



## PMc (Jun 25, 2019)

```
$ svn co -r 341905 svn://svn.freebsd.org/ports/head/multimedia/kino .
svn: E160013: File not found: revision 505080, path '/head/multimedia/kino'
$ svn co -r 341905 svn://svn.freebsd.org/ports/head/multimedia/kino@341905 .
A    files
A    files/patch-Makefile.in
A    files/patch-am
...
```

The SVN docs give only short explanation about the @NNN notation - it is used to look at a repository at an earlier time. So I would understand this behaviour as follows:
In the first command, SVN looks at the repo for the kino object, doesn't find it (because deleted) and give up. (If it weren't deleted, SVN would grab the kino object, then go back to rev 341905 and deliver it in that state.)
With @341905 SVN looks at the repo as it were in rev 341905, finds the kino object and delivers it in the requested rev.
The differentiation is important as soon as one starts to move files around in the tree.


----------

