After yesterday's sync I found mythtv's overlay not able to build
anymore due to missing dependency: media-tv/linuxtv-dvb-headers is no
longer present in the tree. A quick search shows that it has now become
virtual/linuxtv-dvb-headers [1].

I suppose that my only options for rebuilding mythtv are to wait for
upstream to update the ebuild or to update it myself. How difficult
would the latter be?

raf

[1] https://bugs.gentoo.org/show_bug.cgi?id=403929

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 16.02.2012 08:58, Raffaele BELARDI wrote:
> After yesterday's sync I found mythtv's overlay not able to build
> anymore due to missing dependency: media-tv/linuxtv-dvb-headers is
> no longer present in the tree. A quick search shows that it has now
> become virtual/linuxtv-dvb-headers [1].
>
> I suppose that my only options for rebuilding mythtv are to wait
> for upstream to update the ebuild or to update it myself. How
> difficult would the latter be?
>
> raf
>
> [1] https://bugs.gentoo.org/show_bug.cgi?id=403929

If the package just moved from media-tv to virtual it's easy:

You should make a private overlay and copy the ebuild with the
dependency there:

mkdir /var/lib/layman/myoverlay/
mkdir /var/lib/layman/myoverlay/profile
echo "myoverlay" > /var/lib/layman/myoverlay/profile/repo_name
# Overlay is ready
# add /var/lib/layman/myoverlay/ to /var/lib/layman/make.conf (using
you favorite editor. If you make it the last entry it'll override
other overlays.

mkdir /var/lib/layman/myoverlay/<package-category>
#e.g. media-video for package-category
cp -r <upstream-overlay/<package-category>/<package>
/var/lib/layman/myoverlay/<package-category>
# e.g. cp -r /var/lib/layman/mythtv/media-video/mythtv
/var/lib/layman/myoverlay/media-video

Afterwards edit the ebuild with your favourite editor an replace the
media-tv/linuxtv-dvb-headers with virtual/linuxtv-dvb-headers

Then do (inside the directory of the package inside you own overlay):
ebuild <package-name> manifest

then emerge and you're ready.
You could send your modified ebuild to the mythtv-overlay
maintainer/owner.


Some explanations: I would recommend creating an own overlay so you
don't get problems on sync. If multiple packages are concerned you'll
have to repeat the procedure (except the overlay creation) for each of
them.
If the package was'nt moved, but really changed, it may not be enough
to get everything working...

Hope that helps!

Kind regards,

Hinnerk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPPLtqAAoJEJwwOFaNFkYcSxMIAIB+pxzrSV ubsdZ9teXH8BZ6
hzLYGAWxtDmvBTPMkb58xdjTkR33t1prQ+fnDbFHZ2BuGKCZfK nTknfhAxEoFA7n
HQ/gR8Ad633P/A6wIsy3yWWEVac6GxzUfATVq1GPEJVlVbSItUASEEeq8wRgplW q
A7jIDiveIhkQuGkSsZ0NuC0+V+YEeulWWNQLz/zZsfAqX9YyidALZYQLWE2n6GhM
XJZiyF+QnOfPzwSyobdjwQD7W1QpmTshH1mvEF6QeA+HSk9a7H D5ElJVx+AKoFYs
p3TE56IHgwuyQioApCl7YBQxFixYxrdo0EIbg00JOpU2vohv3G 7/E5HHMimp7Ns=
=1cAv
-----END PGP SIGNATURE-----


Thu Feb 16 10:30:01 2012
Return-path: <kubuntu-devel-bounces@lists.ubuntu.com>
Envelope-to: tom@linux-archive.org
Delivery-date: Thu, 16 Feb 2012 10:20:44 +0200
Received: from chlorine.canonical.com ([91.189.94.204]:52860)
by s2.java-tips.org with esmtp (Exim 4.69)
(envelope-from <kubuntu-devel-bounces@lists.ubuntu.com>)
id 1Rxwa4-0007ae-ER
for tom@linux-archive.org; Thu, 16 Feb 2012 10:20:44 +0200
Received: from localhost ([127.0.0.1] helo=chlorine.canonical.com)
by chlorine.canonical.com with esmtp (Exim 4.71)
(envelope-from <kubuntu-devel-bounces@lists.ubuntu.com>)
id 1RxwZv-0001BE-TH; Thu, 16 Feb 2012 08:20:35 +0000
Received: from youngberry.canonical.com ([91.189.89.112])
by chlorine.canonical.com with esmtp (Exim 4.71)
(envelope-from <aurelien.gateau@canonical.com>) id 1RxwZu-0001B9-D2
for kubuntu-devel@lists.ubuntu.com; Thu, 16 Feb 2012 08:20:34 +0000
Received: from amontsouris-157-1-125-3.w90-46.abo.wanadoo.fr ([90.46.212.3]
helo=[192.168.1.12]) by youngberry.canonical.com with esmtpsa
(TLS1.0HE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71)
(envelope-from <aurelien.gateau@canonical.com>)
id 1RxwZt-0007zQ-62; Thu, 16 Feb 2012 08:20:33 +0000
Message-ID: <4F3CBC50.60507@canonical.com>
Date: Thu, 16 Feb 2012 09:20:32 +0100
From: =?ISO-8859-1?Q?Aur=E9lien_G=E2teau?=
<aurelien.gateau@canonical.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:11.0) Gecko/20120203 Thunderbird/11.0
MIME-Version: 1.0
To: Kubuntu Developer Discussion <kubuntu-devel@lists.ubuntu.com>
Subject: Re: kde telepathy?
References: <20120213174031.GZ21668@starsky.19inch.net>
<CAEc+18EO1hZ0kXJV=0_3uSg8k-9OLYOftzs0v74eeVXqT-w2NQ@mail.gmail.com>
<CAGeFrHAhTLRt7c2vUyhUTiZEtfNxJrProC5a9ZREj=hy=Ja+ Ow@mail.gmail.com>
<5683520.79cYca5x9B@scott-latitude-e6320>
In-Reply-To: <5683520.79cYca5x9B@scott-latitude-e6320>
Cc: Scott Kitterman <ubuntu@kitterman.com>
X-BeenThere: kubuntu-devel@lists.ubuntu.com
X-Mailman-Version: 2.1.13
Precedence: list
Reply-To: Kubuntu Developer Discussion <kubuntu-devel@lists.ubuntu.com>
List-Id: Kubuntu Developer Discussion <kubuntu-devel.lists.ubuntu.com>
List-Unsubscribe: <https://lists.ubuntu.com/mailman/options/kubuntu-devel>,
<mailto:kubuntu-devel-request@lists.ubuntu.com?subject=unsubscribe>
List-Archive: <https://lists.ubuntu.com/archives/kubuntu-devel>
List-Post: <mailto:kubuntu-devel@lists.ubuntu.com>
List-Help: <mailto:kubuntu-devel-request@lists.ubuntu.com?subject=help>
List-Subscribe: <https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel>,
<mailto:kubuntu-devel-request@lists.ubuntu.com?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Sender: kubuntu-devel-bounces@lists.ubuntu.com
Errors-To: kubuntu-devel-bounces@lists.ubuntu.com

Le 16/02/2012 00:46, Scott Kitterman a =E9crit :
> On Wednesday, February 15, 2012 09:47:06 PM David Edmundson wrote:
>> Shipping both would be confusing. Especially as it really makes sense
>> to have the presence applet load by default in the sys-tray.
>
> We already have a messaging indicator that supports email, IRC, and IM in=
the
> systray. Not having KDE Telepathy integrated with this would be confusin=
g, so
> we only want one widget in the systray, the question is how best to prese=
nt
> it.
>
> Scott K
>
I happen to have some knowledge about messaging indicators . I am very =

happy to provide support for implementing one or even (gasp) do it =

myself. What would be the deadline for such a patch? Can we consider it =

a regression fix?

While I am at it, might as well give my opinion on whether we should =

ship KDE Telepathy or not. My position would be to ship Kopete by =

default in Main, and ship KDE Telepathy in Universe. That gives more =

users the occasion to test it, report bugs and make it solid. It also =

avoids disrupting Kubuntu software selection too much for LTS.

I don't think the fact KDE Telepathy has a KCM is an issue: if it is not =

shipped by default the KCM will only be present for those who =

consciously installed it.

Aur=E9lien

-- =

kubuntu-devel mailing list
kubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinf=
o/kubuntu-devel

On 02/16/2012 09:16 AM, Hinnerk van Bruinehsen wrote:
> On 16.02.2012 08:58, Raffaele BELARDI wrote:
>> I suppose that my only options for rebuilding mythtv are to wait
>> for upstream to update the ebuild or to update it myself. How
>> difficult would the latter be?
>
> If the package just moved from media-tv to virtual it's easy:
>
> You should make a private overlay and copy the ebuild with the
> dependency there:
>
> mkdir /var/lib/layman/myoverlay/ mkdir
> /var/lib/layman/myoverlay/profile echo "myoverlay" >
> /var/lib/layman/myoverlay/profile/repo_name # Overlay is ready #
> add /var/lib/layman/myoverlay/ to /var/lib/layman/make.conf (using
> you favorite editor. If you make it the last entry it'll override
> other overlays.

Thanks, looks easy but I need to look into layman and overlays, I've
never approached that before.

In the meantime I found that another option is to auto-generate
ebuilds from the mythtv overlay:

http://www.mythtv.org/pipermail/mythtv-users/2011-February/309883.html

raf

On Thu, 16 Feb 2012 09:16:42 +0100, Hinnerk van Bruinehsen wrote:

> Some explanations: I would recommend creating an own overlay so you
> don't get problems on sync. If multiple packages are concerned you'll
> have to repeat the procedure (except the overlay creation) for each of
> them.
> If the package was'nt moved, but really changed, it may not be enough
> to get everything working...

Adding it to package.provided also works, although I went the overlay
route as I only had to do that once to fix several boxes.


--
Neil Bothwick

Master of all I survey (at the moment, empty pizza boxes)

On 02/16/2012 09:16 AM, Hinnerk van Bruinehsen wrote:
> On 16.02.2012 08:58, Raffaele BELARDI wrote:
>> I suppose that my only options for rebuilding mythtv are to wait
>> for upstream to update the ebuild or to update it myself. How
>> difficult would the latter be?
>
> If the package just moved from media-tv to virtual it's easy:
>
> You should make a private overlay and copy the ebuild with the
> dependency there:

I went for a simpler route to just edit the ebuild and rebuild the
manifest.

raf

On Fri, 17 Feb 2012 08:19:33 +0100
Raffaele BELARDI <raffaele.belardi@st.com> wrote:

> On 02/16/2012 09:16 AM, Hinnerk van Bruinehsen wrote:
> > On 16.02.2012 08:58, Raffaele BELARDI wrote:
> >> I suppose that my only options for rebuilding mythtv are to wait
> >> for upstream to update the ebuild or to update it myself. How
> >> difficult would the latter be?
> >
> > If the package just moved from media-tv to virtual it's easy:
> >
> > You should make a private overlay and copy the ebuild with the
> > dependency there:
>
> I went for a simpler route to just edit the ebuild and rebuild the
> manifest.
>
> raf

Your changes will be overwritten and reverted next time you resync the
portage tree and every time thereafter.

Editing the ebuild is not the simplest route, it is a vastly more
complex route. Instead, put the ebuild in the local overlay where
portage knows not to touch it. A local overlay does not require layman.

--
Alan McKinnnon
alan.mckinnon@gmail.com

On 02/17/2012 08:48 AM, Alan McKinnon wrote:
> On Fri, 17 Feb 2012 08:19:33 +0100
> Your changes will be overwritten and reverted next time you resync the
> portage tree and every time thereafter.
>
> Editing the ebuild is not the simplest route, it is a vastly more
> complex route. Instead, put the ebuild in the local overlay where
> portage knows not to touch it. A local overlay does not require layman.

The change was done in the mythtv overlay (/usr/local/mythtv_portage/),
would that be overwritten by a resync? I understood that overlay gets
updated only when there is a mythtv update upstream.

raf

On Fri, 17 Feb 2012 09:01:36 +0100
Raffaele BELARDI <raffaele.belardi@st.com> wrote:

> On 02/17/2012 08:48 AM, Alan McKinnon wrote:
> > On Fri, 17 Feb 2012 08:19:33 +0100
> > Your changes will be overwritten and reverted next time you resync
> > the portage tree and every time thereafter.
> >
> > Editing the ebuild is not the simplest route, it is a vastly more
> > complex route. Instead, put the ebuild in the local overlay where
> > portage knows not to touch it. A local overlay does not require
> > layman.
>
> The change was done in the mythtv overlay
> (/usr/local/mythtv_portage/), would that be overwritten by a resync?
> I understood that overlay gets updated only when there is a mythtv
> update upstream.


It will be overwritten with every layman update/resync

layman will notice that you have a file that is different from the repo
and will revert it, and you cannot stop this happening. It does not
depend on whether the remote file has changed, it only depends on you
locally having a file that is different to the repo.

Seriously, the gentoo docs are full or warning to not do what you did.
Use the local overlay, it was designed for exactly this purpose.


--
Alan McKinnnon
alan.mckinnon@gmail.com

On 02/17/2012 11:18 AM, Alan McKinnon wrote:
> On Fri, 17 Feb 2012 09:01:36 +0100
> Raffaele BELARDI <raffaele.belardi@st.com> wrote:
>> The change was done in the mythtv overlay
>> (/usr/local/mythtv_portage/), would that be overwritten by a resync?
>> I understood that overlay gets updated only when there is a mythtv
>> update upstream.
>
> It will be overwritten with every layman update/resync
>
> layman will notice that you have a file that is different from the repo
> and will revert it, and you cannot stop this happening. It does not
> depend on whether the remote file has changed, it only depends on you
> locally having a file that is different to the repo.
>
> Seriously, the gentoo docs are full or warning to not do what you did.
> Use the local overlay, it was designed for exactly this purpose.

I'm probably oversimplifying because I don't know much about overlays.

I'm not using layman at all but I am using a local overlay for mythtv.
From what I understand the 'overlayed' mythtv ebuild is responsible for
the overlay update though a script installed in /etc/portage/postsync.d/
which basically performs a 'git pull'. So unless there is a new git
snapshot upstream the modified ebuild will not get overwritten, correct?

raf

On Fri, 17 Feb 2012 11:39:24 +0100
Raffaele BELARDI <raffaele.belardi@st.com> wrote:

> On 02/17/2012 11:18 AM, Alan McKinnon wrote:
> > On Fri, 17 Feb 2012 09:01:36 +0100
> > Raffaele BELARDI <raffaele.belardi@st.com> wrote:
> >> The change was done in the mythtv overlay
> >> (/usr/local/mythtv_portage/), would that be overwritten by a
> >> resync? I understood that overlay gets updated only when there is
> >> a mythtv update upstream.
> >
> > It will be overwritten with every layman update/resync
> >
> > layman will notice that you have a file that is different from the
> > repo and will revert it, and you cannot stop this happening. It
> > does not depend on whether the remote file has changed, it only
> > depends on you locally having a file that is different to the repo.
> >
> > Seriously, the gentoo docs are full or warning to not do what you
> > did. Use the local overlay, it was designed for exactly this
> > purpose.
>
> I'm probably oversimplifying because I don't know much about overlays.
>
> I'm not using layman at all but I am using a local overlay for mythtv.
> From what I understand the 'overlayed' mythtv ebuild is responsible
> for the overlay update though a script installed
> in /etc/portage/postsync.d/ which basically performs a 'git pull'. So
> unless there is a new git snapshot upstream the modified ebuild will
> not get overwritten, correct?

I have no idea what you are talking about actually.

ebuilds do not update themselves, something else does.

All an overlay is, is an alternate bunch of ebuilds laid out in the
same format as the portage tree. Layman is nothing more than a nice
bunch of scripts that automate the install, update and resync aspect of
using them. The process you just described makes no sense to me at all
unless it is some customization you did yourself.

But step back and look at this logically. You have a copy of a file
that gets updated from a repo somewhere. But you are also fiddling
around with the same file and expecting it to all magically just work
without collisions despite having two agents fooling around with it.

Does that strike you as a good idea?

The sane way to do this is to leave the remote repo alone and let it do
it's thing when and how it wants to using layman. You will then always
have an ebuild synced to upstream. Copy the ebuild you feel you need to
modify to PORTDIR_OVERLAY and make your changes there. Portage will use
your customized ebuild in preference to the one from the overlay
(due to priority rules) so all is good. When the ebuild in the git repo
is updated, the version number will be bumped and portage will then use
that one in preference to your local copy (due to version number being
higher). If that ebuild doesn't quite work for you yet, copy it to
PORTDIR_OVERLAY and make your custom changes there. keep doing this,
rinse and repeat, until the upstream repo gets their act together.


--
Alan McKinnnon
alan.mckinnon@gmail.com