Re: SOLVED Re: [gentoo-user] ATLAS@home and VirtualBox

2016-05-04 Thread Peter Humphrey
On Tuesday 03 May 2016 18:47:39 Andrew Savchenko wrote:
> On Tue, 03 May 2016 09:56:29 +0100 Peter Humphrey wrote:

--->8

> > What is the approved method of reading change-logs nowadays?
> 
> If you are using git sync, just go to /usr/portage/sci-misc/boinc
> and run `git log .` there.
> 
> If you are using rsync sync, read end of the ChangeLog file, tail
> -n 50 should do the job. 'equery c boinc' should work too.

Okay, thanks.

> Looks like your problem comes from broken rsync mirror with outdated
> ChangeLog files.

No, I see it now: 'equery c boinc' returns the ChangeLog section that refers 
to the currently installed version, not to any earlier or later ones. If I 
know what later versions are available I can do something like "equery c 
=sci-misc/boinc-7.6.31" but I hadn't done so until just now.

What's happened, I think, is that the init script change introduced into the 
latest version has been silently back-ported to the previous version. That's 
why I didn't see it in the ChangeLog, and it explains why I didn't get it 
during routine updates - only when I uninstalled the package and reinstalled 
it.

A learning point has emerged here: it's dangerous to specify a version in 
package.keywords.

I can't say I'm delighted to have spent three weeks in fruitless bug 
chasing, just because of an undocumented change that had already fixed my 
problem behind my back. At least I understand what's going on now. Thanks 
for your help, Andrew.

-- 
Rgds
Peter



Re: SOLVED Re: [gentoo-user] ATLAS@home and VirtualBox

2016-05-03 Thread Andrew Savchenko
Hi,

On Tue, 03 May 2016 09:56:29 +0100 Peter Humphrey wrote:
> On Monday 02 May 2016 11:16:28 I wrote:
> 
> > The fix has already been done, silently - no outward evidence other than
> > the dates on a couple of files. I only found out when I compared a new
> > installation with what I'd backed up a few hours earlier.
> 
> It seems there was a change-log entry, but I didn't see it. This is what I
> saw:
> 
> $ equery c boinc
> *boinc-7.4.42-r1 (09 Sep 2015)
> 
>   09 Sep 2015; Marius Brehler  -boinc-7.4.42.ebuild,
>   +boinc-7.4.42-r1.ebuild:
>   Switch to wxGTK 3.0, fixes bug #556670
> 
>   Package-Manager: portage-2.2.20.1
> 
>   24 Jan 2016; Michał Górny  metadata.xml:
>   Replace all herds with appropriate projects (GLEP 67)
> 
>   Replace all uses of herd with appropriate project maintainers, or no
>   maintainers in case of herds requested to be disbanded.
> 
>   24 Jan 2016; Michał Górny  metadata.xml:
>   Set appropriate maintainer types in metadata.xml (GLEP 67)
> 
> What is the approved method of reading change-logs nowadays?

If you are using git sync, just go to /usr/portage/sci-misc/boinc
and run `git log .` there.

If you are using rsync sync, read end of the ChangeLog file, tail
-n 50 should do the job. 'equery c boinc' should work too.

Looks like your problem comes from broken rsync mirror with outdated
ChangeLog files. Also take into account that ChangeLogs are now
generated from git logs and this takes time, usually something
about an hour (maybe half an hour, I'm not sure).

Just tested on one of my systems using rsync, 'equery c boinc'
works fine. Make sure your app-portage/gentoolkit is up to date.

Best regards,
Andrew Savchenko


pgpx7BR6DTaAm.pgp
Description: PGP signature


Re: SOLVED Re: [gentoo-user] ATLAS@home and VirtualBox

2016-05-03 Thread Peter Humphrey
On Monday 02 May 2016 11:16:28 I wrote:

> The fix has already been done, silently - no outward evidence other than
> the dates on a couple of files. I only found out when I compared a new
> installation with what I'd backed up a few hours earlier.

It seems there was a change-log entry, but I didn't see it. This is what I
saw:

$ equery c boinc
*boinc-7.4.42-r1 (09 Sep 2015)

  09 Sep 2015; Marius Brehler  -boinc-7.4.42.ebuild,
  +boinc-7.4.42-r1.ebuild:
  Switch to wxGTK 3.0, fixes bug #556670

  Package-Manager: portage-2.2.20.1

  24 Jan 2016; Michał Górny  metadata.xml:
  Replace all herds with appropriate projects (GLEP 67)

  Replace all uses of herd with appropriate project maintainers, or no
  maintainers in case of herds requested to be disbanded.

  24 Jan 2016; Michał Górny  metadata.xml:
  Set appropriate maintainer types in metadata.xml (GLEP 67)

What is the approved method of reading change-logs nowadays?

-- 
Rgds
Peter