[mythtv] ANNOUNCEMENT: MythTV is moving to Github
myrdhn at gmail.com
Sun Dec 5 08:13:28 UTC 2010
> Umm. it is the ebuild that is creating a local branch. That would
> make the output a function of your ebuild script, and not a limitation
> of git itself.
Actually this would be a limitation then of the git.eclass that is included
> > xen mythtv # git checkout 11ee9c52ab2d639fa316
> > Note: checking out '11ee9c52ab2d639fa316'.
> Why are you doing this? Why do you need to specify a precise commit
> to build at rather than just building the head of the branch? I don't
> get it.
I have a separate front and back end and I like to make sure they are always
running the same versions. I can do this by specifically identifying which
commit to pull. It also has helped in the past when trying to identify a
specific commit that introduced a bug. It also allowed me in the past to
tell users of the overlay to not go past a specific commit because of said
Since we are no longer going to have an intelligent numerical incrementation
of commits it will be harder to specify which commits need a specific patch
applied or not.
> > Notice when I went to the branch it reported fine, but once I chose to
> > a specific commit it was no longer sure of the branch.
> Correct. Once you did that, you were in a detached head state. I can
> see if there's something we can do when in this situation, but in the
> mean time, I'm not clear on why you want to anyways.
> > const MPUBLIC char *myth_source_path = "branch-fixes/0.24";
> This is incorrect. Your ebuild script is creating new branches
> always? Or what's going on?
New branches are not being created. It is apparently a function of the
> > Note the branch- in front of the fixes/0.24 for the ebuild. Also of
> > think the -dirty at the end of the ebuild version line is because of 2
> > patches that are applied to make the install step work on gentoo.
> > I'm pretty sure I could make the ebuild fake the source path instead of
> > pulling the commit if it's a big deal.
> The -dirty is because it was built from code with uncommitted changes,
> which would be your custom patches. It's fine to patch things, but
> you do realize that this will cause a support issue for any users that
> use that ebuild. We can't support your patches, we don't have them,
> and they aren't our code.
> Is there anything in those patches that might be best off being merged
> in, or is it all Gentoo-isms?
There are only 2 patches I apply and I think they are Gentoo-isms as you
One fixes a sandbox violation that was caused by
# cat files/gentoo-myth-config-fix.diff
diff -u -r mythtv.orig/configure mythtv/configure
--- mythtv.orig/configure 2010-08-28 10:46:53.000000000 -0400
+++ mythtv/configure 2010-08-28 10:48:43.000000000 -0400
@@ -4749,9 +4749,9 @@
cat >> external/FFmpeg/config.mak <<EOF
endif # FFMPEG_CONFIG_MAK
Gentoo includes the install_root for inc, bin, and data in the variables
already so the paths are wrong.
The other has been in the official gentoo ebuilds so long I've forgotten why
it is there. All it does is removes -ldconfig from setting.extra in
mythfrontend.pro in order to fix and issue with sandbox-2.0
> Also, just how many people are making separate ebuilds for MythTV in
> Gentoo-land? Why don't you all put your collective heads together and
> do it once? :)
I'm not sure how many are doing it. I have been hosting my ebuilds on github
for over a year now. Prior to that I distributed tarballs.
The repo I have been maintaining has existed in some form or other as far
back as 0.18 and maybe earlier.
mythtv-dev mailing list
mythtv-dev at mythtv.org
More information about the mythtv-dev