Help me resurrect an old port

Phishfry

Son of Beastie

Reaction score: 1,305
Messages: 3,820

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.
Code:
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

Active Member

Reaction score: 96
Messages: 169

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.
 
OP
OP
Phishfry

Phishfry

Son of Beastie

Reaction score: 1,305
Messages: 3,820

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
 
OP
OP
Phishfry

Phishfry

Son of Beastie

Reaction score: 1,305
Messages: 3,820

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

malavon

Active Member

Reaction score: 96
Messages: 169

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

Active Member

Reaction score: 96
Messages: 169

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.
 
OP
OP
Phishfry

Phishfry

Son of Beastie

Reaction score: 1,305
Messages: 3,820

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

Phishfry

Son of Beastie

Reaction score: 1,305
Messages: 3,820

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

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 7,412
Messages: 30,001

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.
 
OP
OP
Phishfry

Phishfry

Son of Beastie

Reaction score: 1,305
Messages: 3,820

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.

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

Administrator
Staff member
Administrator
Moderator

Reaction score: 7,412
Messages: 30,001

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.
 
OP
OP
Phishfry

Phishfry

Son of Beastie

Reaction score: 1,305
Messages: 3,820

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.
 
OP
OP
Phishfry

Phishfry

Son of Beastie

Reaction score: 1,305
Messages: 3,820

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

Active Member

Reaction score: 96
Messages: 169

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
NLS=on: Native Language Support
SCREENCAST=on: Screen capture support via recordMyDesktop
V4L=on: Webcam support via Video4Linux
XINE=on: DVD preview support via xine
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?
 
OP
OP
Phishfry

Phishfry

Son of Beastie

Reaction score: 1,305
Messages: 3,820

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
 
Last edited:
OP
OP
Phishfry

Phishfry

Son of Beastie

Reaction score: 1,305
Messages: 3,820

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

Well-Known Member

Reaction score: 105
Messages: 346

Code:
$ 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.
 
Top