Change ffmpeg branches 2 scripts and running doesn't work... about mpv-build

[kevmitch]

They're not doing the same thing. As the names suggests, one uses master for mpv one for ffmpeg. One may want the master version of only one. Of course if you .look at the contents, they're all just (self documenting) front-ends to the scripts/switch-branch. You'd need instructions or to read the code to know how to use the later, but not the former.

My bad with one for mpv and ffmpeg, not sure what I was thinking there, LOL...

BUT running this does not work, if you are suppose to run it first like this;

./use-mpv-master
./use-ffmpeg-master
./rebuild

[kevmitch]

You must run ./update afterwards for it to take effect and actually check out the master branches.

Not sure what myrebuild is, but iff it's running ./update, then that should work. Are you saying that it's checking out the releases instead? You can tell for certain that it's the mpv release if
(cd mpv && git log -1) says

commit 2da6c95208f286738cd4efc57c70f88aad457b29
Author: Alessandro Ghedini <[email protected]>
Date:   Sun Nov 23 16:52:03 2014 +0100

    Release 0.7.0

What are the contents of the files in the "config" directory after running use-*-master?

Oh myrebuild is my own rebuild, hehe, because most distros come with fribidi, so I redid it to not grab it and compile against it...

This is something I thought I mentioned before, the scripts should be made to check if any of the dependencies are installed and not grab them then. Someone might want to use what they have already installed on their box including ffmpeg, which could be installed... Anyhow, just my 2 cents, that the scripts should be changed to check...

Ok, running either one of the ffmpeg scripts works ok, but the mpv one's have a problem, I tried both and received the same messages;

./use-mpv-master                                                                                          
scripts/mpv-clean: line 3: cd: mpv: No such file or directory
scripts/mpv-clean: line 4: ./waf: No such file or directory
Run ./rebuild to update the source and to compile the selected branch.

The contents of "config" are fine; branch-ffmpeg <master> - branch-mpv <master>

[kevmitch]

fribidi is no longer built by default, so you shouldn't need that anymore. detecting dependencies is beyond the scope of mpv-build.

As the first error message says there is no "mpv" directory in the current working directory. The mpv-clean script is therefore failing because it can't change to the mpv directory. Have you somehow changed the name of the directory containing the mpv git archive, or are you running this from somewhere other than the mpv-build root?

You might want to start from scratch and clone a fresh mpv-build archive.

Yes it's being run in mpv-build root...

And I ran it for the first time from clean build scripts, but this shouldn't matter, you should be able to reuse the mpv-build over...

How can it cd to a directory that does not exist? So it makes sense it would fail since this directory is not in mpv-build script. The only two directories in the mpv-build is; debian and scripts

Runniing either ./use-ffmpeg-master or ./use-ffmpeg-release works just fine, but either of the mpv ones fails with the messages;

scripts/mpv-clean: line 3: cd: mpv: No such file or directory
scripts/mpv-clean: line 4: ./waf: No such file or directory

Seems like a script error that needs to be corrected for the mpv ones...

Ahhh, I just added; test -e mpv || exit 0 to mpv-clean, and it works now. :)

So this will be the only change needed?

I see one other problem, after adding in test -e mpv || exit 0 to mpv-clean, I ran these options;

./use-ffmpeg-master  
./use-mpv-master 
./rebuild 

And then I saw this at the terminal

+ git pull --rebase
Cannot pull with rebase: You have unstaged changes.
Please commit or stash them.

I ran git status and this is what it gave me;

# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   scripts/mpv-clean
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#   ffmpeg_options
#   mpv_options
no changes added to commit (use "git add" and/or "git commit -a")

So anytime we make changes to the files we have to commit them? I'm not a git expert, but I thought the commit happens on the server side, meaning the project developer on the actual project located on git, not a local commit?

[kevmitch]

Yes, if you make modifications, you must commit them before pulling. Even then, you may be required to manually resolve any conflicts.

With git, the commit happens first in your local archive and is then pushed to the central location.

I'm trying to strip down the scripts to the bare minimum, If I delete the hidden .git directories and then run the scripts I get this;

fatal: Not a git repository (or any parent up to mount point /tmp)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).

I'm assuming I'm getting these messages because of the update script.

Can you please help me strip down the update to the bare minimal as a stand alone script, for doing nothing but either clone or pull, without having the need to be associated to git like it is now? So if I make any changes to the script, it's not going to complain about git?

Basically all I want is to be able to just grab and compile and package the source, that's all, without much of git standing in the way, all I want the script to do is just git clone

All I want to be able to do in the simplest fashion is just download and compile source.

thank you very much...

[kevmitch]

Switching branches does not change any version controlled files, so it does not require committing anything.

Unless you plan on issuing pull requests, I would not recommend making commits because you may be required to manually reconcile them every time you pull. That said, to commit changes to all currently tracked files, you can do

git commit -a -m "<description of commit>"

For more information getting started with git:

• official git documentation (comprehensive, but not exactly a "quick start" guide)
• interactive git hub tutorial (annoyingly only let's you input exactly the commands it tells you, defeating most of the purpose of an interactive tutorial)
• Something I wrote up a few years ago (admittedly with only local usage in mind)

HI kevmitch,

I was just editing my post when you posted, please go back and read it over...

thank you...

[kevmitch]

You should not add or commit the ffmpeg_options and mpv_options files to the git archive. Since these are for esoteric per-user options, they are not tracked by the mpv-build repository and therefore will never be overwritten. As I stated above, you should not be committing stuff that you don't hope to eventually get into the central repository because it will cause you nothing but grief with no gain.

If you are only interested in pulling and building, then only do those things (i.e., follow the README.rst instructions and don't modify version controlled files) and you should not encounter any problems. No advanced git knowledge should be necessary beyond clone/pull. If you still want to avoid all contact with git, you can use the "Download Zip" button right below the clone URL.

Right now it sounds like your local repository is in a bad state. There are of course ways to fix this (i.e., git reset --hard [commit before your changes], followed by git pull). However if you are uninterested in learning git you are probably just better off re-cloning a fresh repository.

Also, please do not radically edit your posts. Your edits will often go unnoticed. Github emails only the first revision to anybody watching and even those who are simply reading on the web will not be notified or will often skip over posts that they have already read. If there is new information that you want people to read, it is better to add a new post.

Sorry about the edits...

Ahhh the zip, ok, I grabbed it, but there is still a .gitignore, so I'm assuming it's going to look at this as a git repo?

Hmm, well when I run rebuild I'm getting this;

fatal: Not a git repository (or any of the parent directories): .git

Maybe that message can be ignored, but having it say fatal to the inexperienced makes one feel like somethng is wrong, maybe there's a way you can have this silenced in the scripts?

[kevmitch]

Oh, right, well I guess the zip won't work in this instance since the scripts themselves use git. Specifically the ./update script first attempts to update the mpv-build repository itself, which therefore must actually be a repository. The "fatal" message is generated by git itself and not much can be done about it.

I suppose you could try and edit that part out, which would be OK if you were using the zip and not an actual git clone, but then you run the risk of your mpv-build becoming out of date and/or having to make that modification each time you download. The easiest thing then is probably just to follow the README.rst instructions.

And it is the .git directory, not the .gitignore file that designates something as a repository.

Yes git directory, not the .gitignore, my bad...

There is nothing different in the README;

Checkout the build repo:
    git clone https://github.com/mpv-player/mpv-build.git
    cd mpv-build

Get the ffmpeg, libass and mpv sources  and build them with:
./rebuild -j4

Can you please, when you have time strip down the update so all it's acting like is just a download script for running git clone and nothing else?

When new versions come out for mpv, I'll just clone over... I just want a simple dowload script is all, then it won't be complaining about anything to do with git.

thank you very much...

[kevmitch]

Yes follow just those steps. Your problems are stemming from the fact that you have additionally modified version controlled files or add/commit ed stuff to the repository.

I'm not exactly sure what you're asking about stripping down update. It is designed (correctly) to update mpv-build itself as it does change to keep it compatible with ffmpeg and mpv. If that step is removed, there will be many more problems. In other words, it was a mistake for me to have recommended the zip file in this case.

We're on the Zip file now... :)

Why a mistake to recommend the zip?

All I did was download the zip, open it and just ran rebuild and it spit out the message;

fatal: Not a git repository (or any of the parent directories): .git

I looked through all the scripts, so that is why I asked about making update simple just a git clone download script and nothing more...

Ok, keep the mpv/ffmpeg compatibility part, I'm not sure if this is where the problem is from, but because of the update git is looking for this to be a local repo I'm assuming, so this is what I meant by stripping it down, so it doesn't complain it's not a repo...

thank you

[kevmitch]

I know, I'm saying you shouldn't use the zip file for which that error is expected and not reasonably avoidable. If I understand what you're asking for (never running git pull) that is a radical redesign of mpv-build which breaks most of it's useful functionality (mainly not wasting time and bandwidth).

Ok I get the git pull part, I'm just trying to accomplish having a simple script that stands alone from git.

I'm using the scripts as part of a build script for my distro that packages mpv, so I don't use pull, or keep any directories lying around when I'm done compiling and packaging.

This is all I'm going to do;

1. I'll git clone and grab a new version of mpv-build when one comes available, when it's good to update.
2. I only run the scripts one time when a new version of mpv comes out
3. When I'm done compiling and packaging mpv, all directories are cleaned out and the only thing left over is my mpv build directory with my build scripts.

4.This is how the contents of my Build directory look like;

>ls
README  Requirements  mpv-0.7.0.tar.gz  mpv.SlackBuild  slack-desc

The mpv-0.7.0.tar.gz is the mpv-build scripts that gets called from my mpv.SlackBuild script.

All my script does, basically besides the typical build script, these are the cmds for mpv-build;

#./use-mpv-master
./use-mpv-release
#./use-ffmpeg-master
./use-ffmpeg-release

./rebuild -j4

cd $TMP/$PRGNAM-$VERSION/$PRGNAM
./waf install --destdir=$PKG`

/tmp is where everything I compiled gets placed from the .SlackBuild scripts, /tmp is also a tmpfs that gets cleaned out when I shut down and reboot my box at night.

So as I mentioned, ./rebuild -j4 is always going to get run for the first time on a fresh set of scripts when I new version of mpv, so all I'm always, only doing is just git clone

For my own purpose of only needing git clone, can you please strip down the updates to just only do that, a simple git clone download script?

I also don't understand what you meant by this?

It is designed (correctly) to update mpv-build itself as it does change to keep it compatible with ffmpeg 

Because if I'm always building from a clean directory doing git clone each time, all I can see from the update script is it's doing just that git clone;

do_clone()
{
    set -ex
    if ! test -e "$1" ; then
        git clone "$2" "$1"
    fi
    (
        cd "$1"
        git remote set-url origin "$2"
        git fetch
    )
}

do_clone_all()
{
    do_clone "ffmpeg"   "https://github.com/FFmpeg/FFmpeg.git"
    do_clone "fribidi"  "http://anongit.freedesktop.org/git/fribidi/fribidi.git"
    do_clone "libass"   "https://github.com/libass/libass.git"
    do_clone "mpv"      "https://github.com/mpv-player/mpv.git"

[kevmitch]

You're running into a problem here:

if [ x"$1" != x"--skip-selfupdate" ]; then
    (
        set -ex
        git pull --rebase
    )
    exec "$0" --skip-selfupdate "$@"
fi

This runs git pull on the mpv-build repository itself. Fortunately for you, this also contains your solution, which I wasn't previously aware of. Just add --skip-selfupdate (at your own peril) to the ./update command. This means you can't just use ./rebuild, you'll have to write your own version that contains something like this

./update --skip-selfupdate 
./clean
./build $@

I say at your own peril, because skipping the self update means that your version of mpv-build may become out of sync with mpv and ffmpeg. You will personally and manually have to make sure it doesn't.

Note also that the workflow you describe (cloning a fresh repository each time) means downloading about 250MB of git archives each time you build, which aside from being slightly bad etiquette towards the people hosting those archives (though I think github can handle it), takes several minutes of your time as well.

Ok, well like you, I wasn't aware that using an older mpv-build is going to have an effect on building mpv properly?

Well we all know GitHub is a Git Repo, so I guess a developer can use this in anyway they see fit for their project. But I've personally never considered to use GitHub to clone and pull from Stable Final Release versions. I've personally only considered using GitHub for clone and pull on development branches.

If we also look at it this way, then GitHub bandwidth as you mention can be reduced further. I'm sure it makes it easier to just leave the project in GitHub the way it is making changes to it and people simply pull for their updates. But is it really that hard to take a Stable Final Relase version and make it available HTTP, this way the script(s) is made to grab and download now through HTTP getting git out of the way.

Also all these other projects; ffmpeg, fribidi, libass, have their source ready through HTTP;

https://github.com/FFmpeg/FFmpeg/releases
http://fribidi.org/download/fribidi-0.19.6.tar.bz2
https://github.com/libass/libass/releases

There are certainly many approaches one can take in this situation, I'm just not sure why you've taken more the Git route for the scripts, instead of eliminating Git? I can understand the need for Git to grab the Master, but for Releases, it seems like HTTP can be substituted just fine?

But since I won't be using pull for the scripts I could just remove it;

if [ x"$1" != x"--skip-selfupdate" ]; then
    (
        set -ex
        git pull --rebase
    )
    exec "$0" --skip-selfupdate "$@"
fi

But removing the above section, the shift below it still needs to stay in the script?

[kevmitch]

But removing the above section, the shift below it still needs to stay in the script?

yes that eats the --skip-selfupdate argument during

exec "$0" --skip-selfupdate "$@"

if you don't remove it, it will eat some other argument

Hi kevmitch,

Sorry I'm not much good with Git, so this is the only section that can be removed?

if [ x"$1" != x"--skip-selfupdate" ]; then
    (
        set -ex
        git pull --rebase
    )
    exec "$0" --skip-selfupdate "$@"
fi

Everything else needs to stay?

thank you

[kevmitch]

That needs to be removed if mpv-build is not a git archive. A bunch of other stuff might also be removable, but it is not necessary.

Ok, yes as I mentioned, tried not to make this a git archive/repo thing...

kevmitch, if you get some free time could you strip it down further, as you mentioned, other stuff. I really want this to be the bare minimum of just doing a clone, and of course being able to change to master or release...

thank you very much for all your time and help!!! :)

[kevmitch]

We are not going to remove useful functionality that 99% of users want. If you have special needs, you're best off creating your own customized script.

Hi kevmitch,

Ahh sorry for the misunderstanding, I was only asking when you have time if you could hack it just for me?

That's all :)

thanks