Re: [gentoo-user] Re: All sorts of digest verification failures

[Alan Mackenzie]

On Thu, Nov 12, 2015 at 06:45:44PM +0200, Alan McKinnon wrote:
> On 12/11/2015 18:42, Grant Edwards wrote:
> > On 2015-11-12,   wrote:
> >> Grant Edwards  wrote:

> >>> After an emerge --sync that appeared to work with no problems, my
> >>> "emerge -auvND world" command is reporting that the Changelong files
> >>> are broken for about 2/3 of the packages it wants to update:

[  ]

> The dev are doing some $MAGIC to reinstate ChangeLogs and the first run
> is expected to take a while (i.e. several hours). I suppose you can
> expect some breakage till it finishes.

> It's being discussed and tracked on gentoo-dev, you can drop a mail
> there with specifics to let the devs know what's happening.

Three days later.  I'm still getting this error message, but with a nasty
twist in the tail.  emerge -puND @world reports (amongst others) the
following update:

[ebuild   R] sys-apps/busybox-1.23.1-r1  USE="-pam*"

, and the error message I get on actually trying to start the update is

!!! Digest verification failed:
!!! /usr/portage/sys-apps/busybox/busybox-.ebuild
!!! Reason: Filesize does not match recorded size
!!! Got: 8493
!!! Expected: 8580

.  Why is the build system looking at the digest for version  when it
should be rebuilding version 1.23.1-r1?

> -- 
> Alan McKinnon
> alan.mckin...@gmail.com

-- 
Alan Mackenzie (Nuremberg, Germany).

[gentoo-user] Re: All sorts of digest verification failures

[Martin Vaeth]

Alan Mackenzie  wrote:
>!!! /usr/portage/sys-apps/busybox/busybox-.ebuild
>!!! Got: 8493
>!!! Expected: 8580

Do you use the default (rsync) for syncing, or have you changed
the method?

I have the above claimed filesize (8493), but the Manifest
I obtained from rsync is correct.

The timestamp of the Manifest file in that folder is
Nov 13, 08:17:31 (UTC)
(do not forget to export TZ=UTC when you check the date).
Exactly the same date has the ChangeLog file in that folder
(which is not surprsing).

If in your case ChangeLog and Manifest *both* have an older date,
you got the data perhaps from an outdated mirror.

If ChangeLog has the same date, but Manifest is older (or newer
and still wrong), something strange is going on. In such a case,
one should also consider reasons like local filesystem errors.

Re: [gentoo-user] Akonadi database errors

[Mick]

On Thursday 12 Nov 2015 08:05:52 J. Roeleveld wrote:
> On Thursday, November 12, 2015 07:30:49 AM Mick wrote:
> > On Thursday 12 Nov 2015 04:48:49 J. Roeleveld wrote:
> > > On 11 November 2015 23:07:41 CET, Mick  
wrote:
> > > >On Wednesday 11 Nov 2015 20:28:07 Marc Joliet wrote:
> > > >> On Wednesday 11 November 2015 20:37:24 J. Roeleveld wrote:
> > > >> >I saw plenty of errors with mysql.
> > > >> >
> > > >> >After switching to Postgresql, they seem to have disappeared.
> > > >> 
> > > >> FWIW, I use mariadb myself, which is also the virtual/mysql default
> > > >> provider, last I checked.
> > > >> 
> > > >> Greetings
> > > >
> > > >@Mark: Yes, same here, but the errors are produced by mariadb too.
> > > >
> > > >@Joost: Is postgresql starting as a process by akonadi, or are you
> > > >running it
> > > >independently and pointing akonadi to it?
> > > >
> > > >PS. I read somewhere that if mysql is running independently of
> > > >akonadi, then
> > > >the akonadi errors/corruptions are fewer, or not happen at all.
> > > 
> > > As I use Postgresql also for other stuff, it's started seperately.
> > > 
> > > I also found this performs better, having it run "embedded" only had a
> > > slightly better performance when compared to mysql (or mariadb, don't
> > > remember) "embedded".
> > > 
> > > A framework like akonadi should, IMO, also be able to be run on a
> > > server with clients connecting to there to allow different machines to
> > > all use the same data.
> > > 
> > > The current solution makes running with a shared home and logged in
> > > from different clients simultaneously problematic  (to say the least)
> > > 
> > > --
> > > Joost
> > 
> > Can you please explain how you have akonadi configured to use an existing
> > db instance?  Did you have to set up an akonadi db user and passwd?
> 
> Yes.
> You need to create a user with password on the database where akonadi can
> create the tables.
> 
> Here is my akonadi-config:
> ***
> % cat .config/akonadi/akonadiserverrc
> [%General]
> Driver=QPSQL
> 
> [QPSQL]
> Name=joost-akonadi
> Host=localhost
> Options=
> ServerPath=/usr/bin/pg_ctl
> InitDbPath=/usr/bin/initdb
> StartServer=false
> User=
> Password=
> Port=5432
> 
> [Debug]
> Tracer=null
> 
> ***
> 
> It also works with the database running on a different machine.
> 
> --
> Joost

Thank you Joost.  Did you export/import akonadi databases when you moved over 
from MySQL, or was it not necessary?

One of the databases contains calendar data and I do not want to cause loss of 
it.
-- 
Regards,
Mick


signature.asc
Description: This is a digitally signed message part.

[gentoo-user] Re: Emerge order not deterministic !?

[Hans]

On 12/11/15 19:51, Neil Bothwick wrote:

On Thu, 12 Nov 2015 10:35:14 +0100, Jörg Schaible wrote:


Then use emerge --keep-going and portage will take care of skipping
failing merges for you.


Ah, no, that's not an option. It breaks for a reason. Sometimes I can
ignore that and look for it later and in this case I skip it, but
normally I fix the problem first. However, you have to take care, which
package you're actually skipping. Especially if the build order is
different with resume.


--keep-going will emerge all unaffected packages, meaning you are then
working with a much smaller list when you try to fix the problem. At
least, that's the approach that normally works for me.

--keep-going is intelligent enough to skip any packages that depend on
the failed package. That means you often end up with a package list that
is a single branch dependency tree, so the order is unlikely to change.



I use the following commands to upgrade my Gentoo boxes:
emerge --sync
emerge --update --deep --with-bdeps=y --newuse --backtrack=300 
--changed-deps=y --keep-going=y @world -va


When necessary adding, deleting or changing use flags, keywords, masks.

Followed by:
emerge --depclean
revdep-rebuild

No more problems since using this sequence unless there is a bug in a 
ebuild, like the one last one in busybox ebuild.

Re: [gentoo-user] Re: All sorts of digest verification failures

[Matti Nykyri]

> On Nov 15, 2015, at 12:43, Peter Humphrey  wrote:
> 
> On Sunday 15 Nov 2015 12:22:39 Matti Nykyri wrote:
>>> On Nov 15, 2015, at 11:59, Alan Mackenzie  wrote:
> --->8
>>> Three days later.  I'm still getting this error message, but with a
>>> nasty
>>> twist in the tail.  emerge -puND @world reports (amongst others) the
>>> 
>>> following update:
>>>   [ebuild   R] sys-apps/busybox-1.23.1-r1  USE="-pam*"
>>> 
>>> , and the error message I get on actually trying to start the update is
>>> 
>>>   !!! Digest verification failed:
>>>   !!! /usr/portage/sys-apps/busybox/busybox-.ebuild
>>>   !!! Reason: Filesize does not match recorded size
>>>   !!! Got: 8493
>>>   !!! Expected: 8580
>>> 
>>> .  Why is the build system looking at the digest for version  when
>>> it
>>> should be rebuilding version 1.23.1-r1?
>> 
>> Well it's not. It just checks all the manifests and complains about
>> errors. It doesn't affect the building of 1.23.1-r1.
> 
> I'm getting the same thing as Alan, and have been for several days.
> 
>> If I were you I'ld download the latest portage snapshot. That should take
>> care of any remaining issues. Is your portage upto date?
> 
> My portage is sync'd daily, so it shouldn't need a whole new snapshot.

Sunc doesn't necessarily sync everything and if some random files are out of 
sync you either need to update them manually or get a new snapshot. I doubt the 
server/mirror is messed up, but you could try changing that. Downloading a new 
snapshot isn't that big a deal and that should definitely fix everything, so 
why not try that first?

You may also inspect each package and remanifest those that have problems 
(ebuild manifest). If you are certain that nobody has been fingering your 
ebuilds.

-- 
-M

Re: [gentoo-user] Re: All sorts of digest verification failures

[Alan Mackenzie]

Hello, Matti

On Sun, Nov 15, 2015 at 12:22:39PM +0200, Matti Nykyri wrote:
> > On Nov 15, 2015, at 11:59, Alan Mackenzie  wrote:

> >> On Thu, Nov 12, 2015 at 06:45:44PM +0200, Alan McKinnon wrote:
> >>> On 12/11/2015 18:42, Grant Edwards wrote:
>  On 2015-11-12,   wrote:
>  Grant Edwards  wrote:

> > After an emerge --sync that appeared to work with no problems, my
> > "emerge -auvND world" command is reporting that the Changelong files
> > are broken for about 2/3 of the packages it wants to update:

> > [  ]

> >> The dev are doing some $MAGIC to reinstate ChangeLogs and the first run
> >> is expected to take a while (i.e. several hours). I suppose you can
> >> expect some breakage till it finishes.

> >> It's being discussed and tracked on gentoo-dev, you can drop a mail
> >> there with specifics to let the devs know what's happening.

> > Three days later.  I'm still getting this error message, but with a nasty
> > twist in the tail.  emerge -puND @world reports (amongst others) the
> > following update:

> >[ebuild   R] sys-apps/busybox-1.23.1-r1  USE="-pam*"

> > , and the error message I get on actually trying to start the update is

> >!!! Digest verification failed:
> >!!! /usr/portage/sys-apps/busybox/busybox-.ebuild
> >!!! Reason: Filesize does not match recorded size
> >!!! Got: 8493
> >!!! Expected: 8580

> > .  Why is the build system looking at the digest for version  when it
> > should be rebuilding version 1.23.1-r1?

> Well it's not. It just checks all the manifests and complains about
> errors. It doesn't affect the building of 1.23.1-r1.

Ah, OK.  But it causes emerge to bail out, so never gets round to
building 1.23.1-r1.

> If I were you I'ld download the latest portage snapshot. That should
> take care of any remaining issues. Is your portage upto date?

I'd just synched my portage tree immediately before attempting the build.
I'll try again tomorrow, in the hope everything will have been sorted out
by then.

> -- 
> -M

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] Re: All sorts of digest verification failures

[Matti Nykyri]

> On Nov 15, 2015, at 11:59, Alan Mackenzie  wrote:
> 
>> On Thu, Nov 12, 2015 at 06:45:44PM +0200, Alan McKinnon wrote:
>>> On 12/11/2015 18:42, Grant Edwards wrote:
 On 2015-11-12,   wrote:
 Grant Edwards  wrote:
> 
> After an emerge --sync that appeared to work with no problems, my
> "emerge -auvND world" command is reporting that the Changelong files
> are broken for about 2/3 of the packages it wants to update:
> 
> [  ]
> 
>> The dev are doing some $MAGIC to reinstate ChangeLogs and the first run
>> is expected to take a while (i.e. several hours). I suppose you can
>> expect some breakage till it finishes.
> 
>> It's being discussed and tracked on gentoo-dev, you can drop a mail
>> there with specifics to let the devs know what's happening.
> 
> Three days later.  I'm still getting this error message, but with a nasty
> twist in the tail.  emerge -puND @world reports (amongst others) the
> following update:
> 
>[ebuild   R] sys-apps/busybox-1.23.1-r1  USE="-pam*"
> 
> , and the error message I get on actually trying to start the update is
> 
>!!! Digest verification failed:
>!!! /usr/portage/sys-apps/busybox/busybox-.ebuild
>!!! Reason: Filesize does not match recorded size
>!!! Got: 8493
>!!! Expected: 8580
> 
> .  Why is the build system looking at the digest for version  when it
> should be rebuilding version 1.23.1-r1?

Well it's not. It just checks all the manifests and complains about errors. It 
doesn't affect the building of 1.23.1-r1.

If I were you I'ld download the latest portage snapshot. That should take care 
of any remaining issues. Is your portage upto date?

-- 
-M

Re: [gentoo-user] Re: All sorts of digest verification failures

[Matti Nykyri]

> On Nov 15, 2015, at 13:01, Alan Mackenzie  wrote:
> 
>> Well it's not. It just checks all the manifests and complains about
>> errors. It doesn't affect the building of 1.23.1-r1.

Ok. I must be using some different switch then.

> Ah, OK.  But it causes emerge to bail out, so never gets round to
> building 1.23.1-r1.
> 
>> If I were you I'ld download the latest portage snapshot. That should
>> take care of any remaining issues. Is your portage upto date?
> 
> I'd just synched my portage tree immediately before attempting the build.
> I'll try again tomorrow, in the hope everything will have been sorted out
> by then.

Syncing and getting a new snapshot is a bit different. With a snapshot you get 
a new clean start. Download it and unpack.

After that check that your portage package is upto date (emerge -av portage).

-- 
-Matti

Re: [gentoo-user] openssh-7.1_p1-r2 won't allow "nxserver" to connect

[Neil Bothwick]

On Sat, 14 Nov 2015 16:27:27 -0700, the...@sys-concept.com wrote:

> >> > Testing your nxserver connection ...
> >> Permission denied (publickey,password,keyboard-interactive).
> >> Fatal error: Could not connect to NX Server.  
> > 
> > That doesn't look like the error you get from an unsupported key,
> > which is something like
> > 
> > Unable to negotiate with x.x.x.x: no matching host key type found.
> > Their offer: ssh-dss
> > 
> > Is nxserver trying to connect as root? It looks more like the
> > disabling of passworded root logins in OpenSSH.  
> 
> Here is my sshd_config: (nxserver works with openssh-6.9_p1-r2)
> As soon as I upgrade to openssh-7, enable:
> PubkeyAcceptedKeyTypes=+ssh-dss
> 
> restart: sshd
> and nxserver gives me an error message (like above).

Which has nothing to do with keys
 
> Yes, I'm running "nxsetup --test" as root.

and everything to do with this. While the use of DSS keys may cause a
problem, you haven't reached that point yet because the default config
not blocks root logins. Add "PermitRootLogin without-password" to your
config.


-- 
Neil Bothwick

The computer revolution is over. The computers won.


pgpoCtT22Sdvl.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Re: All sorts of digest verification failures

[Neil Bothwick]

On Sun, 15 Nov 2015 09:59:28 +, Alan Mackenzie wrote:

> [ebuild   R] sys-apps/busybox-1.23.1-r1  USE="-pam*"
> 
> , and the error message I get on actually trying to start the update is
> 
> !!! Digest verification failed:
> !!! /usr/portage/sys-apps/busybox/busybox-.ebuild
> !!! Reason: Filesize does not match recorded size
> !!! Got: 8493
> !!! Expected: 8580
> 
> .  Why is the build system looking at the digest for version  when
> it should be rebuilding version 1.23.1-r1?

The manifest covers all files in the ebuild's directory. If one fails the
test, the entire directory is considered suspect so the ebuild has to be
skipped.

This has been going on a for a few days, there is an open bug but no
apparent solution. The manifests are now generated automatically when a
git commit is made, but there appears to be something going wrong with
the process in this instance.


-- 
Neil Bothwick

Megabyte: (n.) more than you can comprehend and less than you'll need.


pgp0FOXOSlOL6.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Re: All sorts of digest verification failures

[Peter Humphrey]

On Sunday 15 Nov 2015 12:22:39 Matti Nykyri wrote:
> > On Nov 15, 2015, at 11:59, Alan Mackenzie  wrote:
--->8
> > Three days later.  I'm still getting this error message, but with a
> > nasty
> > twist in the tail.  emerge -puND @world reports (amongst others) the
> > 
> > following update:
> >[ebuild   R] sys-apps/busybox-1.23.1-r1  USE="-pam*"
> > 
> > , and the error message I get on actually trying to start the update is
> > 
> >!!! Digest verification failed:
> >!!! /usr/portage/sys-apps/busybox/busybox-.ebuild
> >!!! Reason: Filesize does not match recorded size
> >!!! Got: 8493
> >!!! Expected: 8580
> > 
> > .  Why is the build system looking at the digest for version  when
> > it
> > should be rebuilding version 1.23.1-r1?
> 
> Well it's not. It just checks all the manifests and complains about
> errors. It doesn't affect the building of 1.23.1-r1.

I'm getting the same thing as Alan, and have been for several days.

> If I were you I'ld download the latest portage snapshot. That should take
> care of any remaining issues. Is your portage upto date?

My portage is sync'd daily, so it shouldn't need a whole new snapshot.

-- 
Rgds
Peter

Re: [gentoo-user] Re: All sorts of digest verification failures

[Peter Humphrey]

On Sunday 15 Nov 2015 12:56:16 Matti Nykyri wrote:
> > On Nov 15, 2015, at 12:43, Peter Humphrey  
wrote:
> > I'm getting the same thing as Alan, and have been for several days.
> > 
> >> If I were you I'ld download the latest portage snapshot. That should
> >> take care of any remaining issues. Is your portage upto date?
> > 
> > My portage is sync'd daily, so it shouldn't need a whole new snapshot.
> 
> Sunc doesn't necessarily sync everything

Eh? How can --sync not sync?

> ... and if some random files are out of sync you either need to update
> them manually or get a new snapshot. I doubt the server/mirror is messed
> up, but you could try changing that. Downloading a new snapshot isn't that
> big a deal and that should definitely fix everything, so why not try that
> first?

I may do so, but not today.

-- 
Rgds
Peter

Re: [gentoo-user] Re: All sorts of digest verification failures

[Alan Mackenzie]

Hello, Martin.

On Sun, Nov 15, 2015 at 02:56:42PM +, Martin Vaeth wrote:
> Alan Mackenzie  wrote:
> >!!! /usr/portage/sys-apps/busybox/busybox-.ebuild
> >!!! Got: 8493
> >!!! Expected: 8580

> Do you use the default (rsync) for syncing, or have you changed
> the method?

rsync all the time.

> I have the above claimed filesize (8493), but the Manifest
> I obtained from rsync is correct.

> The timestamp of the Manifest file in that folder is
> Nov 13, 08:17:31 (UTC)

I have 07:17:31 + for Manifest and ChangeLog.  Are you sure your
08:17:31 isn't central European time?

> (do not forget to export TZ=UTC when you check the date).
> Exactly the same date has the ChangeLog file in that folder
> (which is not surprsing).

It does indeed.

> If in your case ChangeLog and Manifest *both* have an older date,
> you got the data perhaps from an outdated mirror.

> If ChangeLog has the same date, but Manifest is older (or newer
> and still wrong), something strange is going on. In such a case,
> one should also consider reasons like local filesystem errors.

I don't think I've got a filesystem error: ext3 is tried and tested.
After downloading /etc/portage via rsync again, I still get the same
error.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] Re: All sorts of digest verification failures

[Alan Mackenzie]

Hello, Matti.

On Sun, Nov 15, 2015 at 01:15:16PM +0200, Matti Nykyri wrote:
> > On Nov 15, 2015, at 13:01, Alan Mackenzie  wrote:

> >> Well it's not. It just checks all the manifests and complains about
> >> errors. It doesn't affect the building of 1.23.1-r1.

> Ok. I must be using some different switch then.

> > Ah, OK.  But it causes emerge to bail out, so never gets round to
> > building 1.23.1-r1.

> >> If I were you I'ld download the latest portage snapshot. That should
> >> take care of any remaining issues. Is your portage upto date?

I deleted my /usr/portage (with the exception of
/usr/portage/distfiles), and ran emerge --sync again.  I get precisely
the same error message, still.

> > I'd just synched my portage tree immediately before attempting the build.
> > I'll try again tomorrow, in the hope everything will have been sorted out
> > by then.

> Syncing and getting a new snapshot is a bit different. With a snapshot you 
> get a new clean start. Download it and unpack.

> After that check that your portage package is upto date (emerge -av portage).

Yes, my portage is fully up to date.

I think the Gentoo maintainers haven't fixed this problem, yet.

> -- 
> -Matti

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [gentoo-user] Akonadi database errors

[Mick]

On Sunday 15 Nov 2015 17:55:08 J. Roeleveld wrote:

> To migrate calendar data, I would export to an ical file and then reimport
> it.
> 
> For contacts, use vcf.
> 
> Both of these are mostly human readable and allow for simple editing if
> necessary.
> 
> I am not certain this will work. I would suggest testing with a temporary
> user first.
> 
> --
> Joost

Thank you for your advice.  I'll try it out when a get a spare moment.  Last 
question:

akonadi seems to run a mysql_upgrade command whenever the mysql application is 
updated by portage.  Will it also run the equivalent command with postgres?  
If not, dumping and reloading all the akonadi databases will be a pain for a 
desktop.
 
-- 
Regards,
Mick


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] Akonadi database errors

[J. Roeleveld]

On 15 November 2015 17:32:07 CET, Mick  wrote:
>On Thursday 12 Nov 2015 08:05:52 J. Roeleveld wrote:
>> On Thursday, November 12, 2015 07:30:49 AM Mick wrote:
>> > On Thursday 12 Nov 2015 04:48:49 J. Roeleveld wrote:
>> > > On 11 November 2015 23:07:41 CET, Mick
> 
>wrote:
>> > > >On Wednesday 11 Nov 2015 20:28:07 Marc Joliet wrote:
>> > > >> On Wednesday 11 November 2015 20:37:24 J. Roeleveld wrote:
>> > > >> >I saw plenty of errors with mysql.
>> > > >> >
>> > > >> >After switching to Postgresql, they seem to have disappeared.
>> > > >> 
>> > > >> FWIW, I use mariadb myself, which is also the virtual/mysql
>default
>> > > >> provider, last I checked.
>> > > >> 
>> > > >> Greetings
>> > > >
>> > > >@Mark: Yes, same here, but the errors are produced by mariadb
>too.
>> > > >
>> > > >@Joost: Is postgresql starting as a process by akonadi, or are
>you
>> > > >running it
>> > > >independently and pointing akonadi to it?
>> > > >
>> > > >PS. I read somewhere that if mysql is running independently of
>> > > >akonadi, then
>> > > >the akonadi errors/corruptions are fewer, or not happen at all.
>> > > 
>> > > As I use Postgresql also for other stuff, it's started
>seperately.
>> > > 
>> > > I also found this performs better, having it run "embedded" only
>had a
>> > > slightly better performance when compared to mysql (or mariadb,
>don't
>> > > remember) "embedded".
>> > > 
>> > > A framework like akonadi should, IMO, also be able to be run on a
>> > > server with clients connecting to there to allow different
>machines to
>> > > all use the same data.
>> > > 
>> > > The current solution makes running with a shared home and logged
>in
>> > > from different clients simultaneously problematic  (to say the
>least)
>> > > 
>> > > --
>> > > Joost
>> > 
>> > Can you please explain how you have akonadi configured to use an
>existing
>> > db instance?  Did you have to set up an akonadi db user and passwd?
>> 
>> Yes.
>> You need to create a user with password on the database where akonadi
>can
>> create the tables.
>> 
>> Here is my akonadi-config:
>> ***
>> % cat .config/akonadi/akonadiserverrc
>> [%General]
>> Driver=QPSQL
>> 
>> [QPSQL]
>> Name=joost-akonadi
>> Host=localhost
>> Options=
>> ServerPath=/usr/bin/pg_ctl
>> InitDbPath=/usr/bin/initdb
>> StartServer=false
>> User=
>> Password=
>> Port=5432
>> 
>> [Debug]
>> Tracer=null
>> 
>> ***
>> 
>> It also works with the database running on a different machine.
>> 
>> --
>> Joost
>
>Thank you Joost.  Did you export/import akonadi databases when you
>moved over 
>from MySQL, or was it not necessary?
>
>One of the databases contains calendar data and I do not want to cause
>loss of 
>it.

I store my emails in IMAP (Cyrus) and my contacts and calendar are stored in 
Egroupware.

IOW, I treat akonadi as a local cache and the server is the master copy being 
used by all other devices.

--
Joost
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [gentoo-user] Akonadi database errors

[J. Roeleveld]

On 15 November 2015 17:32:07 CET, Mick  wrote:
>On Thursday 12 Nov 2015 08:05:52 J. Roeleveld wrote:
>> On Thursday, November 12, 2015 07:30:49 AM Mick wrote:
>> > On Thursday 12 Nov 2015 04:48:49 J. Roeleveld wrote:
>> > > On 11 November 2015 23:07:41 CET, Mick
> 
>wrote:
>> > > >On Wednesday 11 Nov 2015 20:28:07 Marc Joliet wrote:
>> > > >> On Wednesday 11 November 2015 20:37:24 J. Roeleveld wrote:
>> > > >> >I saw plenty of errors with mysql.
>> > > >> >
>> > > >> >After switching to Postgresql, they seem to have disappeared.
>> > > >> 
>> > > >> FWIW, I use mariadb myself, which is also the virtual/mysql
>default
>> > > >> provider, last I checked.
>> > > >> 
>> > > >> Greetings
>> > > >
>> > > >@Mark: Yes, same here, but the errors are produced by mariadb
>too.
>> > > >
>> > > >@Joost: Is postgresql starting as a process by akonadi, or are
>you
>> > > >running it
>> > > >independently and pointing akonadi to it?
>> > > >
>> > > >PS. I read somewhere that if mysql is running independently of
>> > > >akonadi, then
>> > > >the akonadi errors/corruptions are fewer, or not happen at all.
>> > > 
>> > > As I use Postgresql also for other stuff, it's started
>seperately.
>> > > 
>> > > I also found this performs better, having it run "embedded" only
>had a
>> > > slightly better performance when compared to mysql (or mariadb,
>don't
>> > > remember) "embedded".
>> > > 
>> > > A framework like akonadi should, IMO, also be able to be run on a
>> > > server with clients connecting to there to allow different
>machines to
>> > > all use the same data.
>> > > 
>> > > The current solution makes running with a shared home and logged
>in
>> > > from different clients simultaneously problematic  (to say the
>least)
>> > > 
>> > > --
>> > > Joost
>> > 
>> > Can you please explain how you have akonadi configured to use an
>existing
>> > db instance?  Did you have to set up an akonadi db user and passwd?
>> 
>> Yes.
>> You need to create a user with password on the database where akonadi
>can
>> create the tables.
>> 
>> Here is my akonadi-config:
>> ***
>> % cat .config/akonadi/akonadiserverrc
>> [%General]
>> Driver=QPSQL
>> 
>> [QPSQL]
>> Name=joost-akonadi
>> Host=localhost
>> Options=
>> ServerPath=/usr/bin/pg_ctl
>> InitDbPath=/usr/bin/initdb
>> StartServer=false
>> User=
>> Password=
>> Port=5432
>> 
>> [Debug]
>> Tracer=null
>> 
>> ***
>> 
>> It also works with the database running on a different machine.
>> 
>> --
>> Joost
>
>Thank you Joost.  Did you export/import akonadi databases when you
>moved over 
>from MySQL, or was it not necessary?
>
>One of the databases contains calendar data and I do not want to cause
>loss of 
>it.

To migrate calendar data, I would export to an ical file and then reimport it.

For contacts, use vcf.

Both of these are mostly human readable and allow for simple editing if 
necessary.

I am not certain this will work. I would suggest testing with a temporary user 
first.

--
Joost
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[gentoo-user] Re: All sorts of digest verification failures

[Martin Vaeth]

Neil Bothwick  wrote:
>
> I deleted the busybox directory from the tree then ran emerge --sync.
> The error is still there

You have the same files that I have.
Unfortunately, only now I actually did:

$ grep busybox- Manifest
EBUILD busybox-.ebuild 8580 [...]

???
I have the same wrong size recorded in the Manifest!
No idea why portage didn't yell at me - there seems
to be another bug involved.

So, sorry, my previous conjecture was wrong.

The only information which I can give you currently,
is that probably all mirrors contain the same broken Manifest
in the moment.

*Perhaps* (a very wild conjecture!) the reason why this Manifest
got not updated is the same bug which caused portage not to yell
at me, despite the broken Manifest.

As a temporary hack, calling "ebuild manifest" on that file is
probably the only reasonable way to proceed, but this problem
must be fixed, of course...

Re: [gentoo-user] Re: All sorts of digest verification failures

[Dale]

Martin Vaeth wrote:
> Neil Bothwick  wrote:
>> I deleted the busybox directory from the tree then ran emerge --sync.
>> The error is still there
> You have the same files that I have.
> Unfortunately, only now I actually did:
>
> $ grep busybox- Manifest
> EBUILD busybox-.ebuild 8580 [...]
>
> ???
> I have the same wrong size recorded in the Manifest!
> No idea why portage didn't yell at me - there seems
> to be another bug involved.
>
> So, sorry, my previous conjecture was wrong.
>
> The only information which I can give you currently,
> is that probably all mirrors contain the same broken Manifest
> in the moment.
>
> *Perhaps* (a very wild conjecture!) the reason why this Manifest
> got not updated is the same bug which caused portage not to yell
> at me, despite the broken Manifest.
>
> As a temporary hack, calling "ebuild manifest" on that file is
> probably the only reasonable way to proceed, but this problem
> must be fixed, of course...
>
>
>


Wasn't there a emerge option to ignore the manifest?  I seem to recall
there used to be one but it was a LONG time ago.  Of course, if someone
has tinkered with something that would be a bad thing to do. 

Dale

:-)  :-)

Re: [gentoo-user] Re: All sorts of digest verification failures

[covici]

Dale  wrote:

> Martin Vaeth wrote:
> > Neil Bothwick  wrote:
> >> I deleted the busybox directory from the tree then ran emerge --sync.
> >> The error is still there
> > You have the same files that I have.
> > Unfortunately, only now I actually did:
> >
> > $ grep busybox- Manifest
> > EBUILD busybox-.ebuild 8580 [...]
> >
> > ???
> > I have the same wrong size recorded in the Manifest!
> > No idea why portage didn't yell at me - there seems
> > to be another bug involved.
> >
> > So, sorry, my previous conjecture was wrong.
> >
> > The only information which I can give you currently,
> > is that probably all mirrors contain the same broken Manifest
> > in the moment.
> >
> > *Perhaps* (a very wild conjecture!) the reason why this Manifest
> > got not updated is the same bug which caused portage not to yell
> > at me, despite the broken Manifest.
> >
> > As a temporary hack, calling "ebuild manifest" on that file is
> > probably the only reasonable way to proceed, but this problem
> > must be fixed, of course...
> >
> >
> >
> 
> 
> Wasn't there a emerge option to ignore the manifest?  I seem to recall
> there used to be one but it was a LONG time ago.  Of course, if someone
> has tinkered with something that would be a bad thing to do. 

I thought I remembered something where the manifest no longer checks the
ebuild, just the file in distfiles -- I thought I remembered seeing this
somewhere.  It was at a time when we got all the manifests all at once.

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

 John Covici
 cov...@ccs.covici.com

[gentoo-user] Re: All sorts of digest verification failures

[Grant Edwards]

On 2015-11-15, Dale  wrote:

> Wasn't there a emerge option to ignore the manifest?  I seem to recall
> there used to be one but it was a LONG time ago.  Of course, if someone
> has tinkered with something that would be a bad thing to do.

If the digest failures are for packages you don't have installed, just
removing the entire directory for each of the broken manifests is one
temporary work-around.

-- 
Grant

Re: [gentoo-user] Re: All sorts of digest verification failures

[Simon Thelen]

On 15-11-15 at 15:29, cov...@ccs.covici.com wrote:
> Dale  wrote:
> > Martin Vaeth wrote:
> > > Neil Bothwick  wrote:
[..]
> > > As a temporary hack, calling "ebuild manifest" on that file is
> > > probably the only reasonable way to proceed, but this problem
> > > must be fixed, of course...
> > Wasn't there a emerge option to ignore the manifest?  I seem to recall
> > there used to be one but it was a LONG time ago.  Of course, if someone
> > has tinkered with something that would be a bad thing to do. 
> I thought I remembered something where the manifest no longer checks the
> ebuild, just the file in distfiles -- I thought I remembered seeing this
> somewhere.  It was at a time when we got all the manifests all at once.
I sync from git and none of my Manifests track the ebuilds, so this
could be a thing. Note how the Manifest for busybox in the gentoo.git
tree doesn't have manifests for any of the ebuilds. [1]

[1]: https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-apps/busybox/Manifest

-- 
Simon Thelen

[gentoo-user] Re: firefox profile uses 100% CPU

[walt]

On Sun, 15 Nov 2015 19:15:34 +0100 (CET)
Peter Weilbacher  wrote:

> On Thu, 12 Nov 2015, walt wrote:
> 
> > I had a bad problem with the firefox profile manager about a year
> > ago and I decided that the devs at mozilla are not maintaining that
> > code any more, so I stopped using the profile manager.  
> 
> What made you decide that? Are you a manager at Mozilla?
> 
> > Firefox/mozilla is a very old project with limited resources.  
> 
> Yes, as a multi-million dollar company they are severely limited...

The limited resources:  skilled programmers who are available and
willing to work for the mozilla foundation.

> > The current developers are working full speed on security updates,
> > which is good, but there is a lot of bitrot in their huge
> > codebase.  
> 
> Huh? What do you call "bitrot" and what indication for that do you
> see?

Bugs that remain unfixed for years (literally).  Years ago I filed
several bug reports at bugzilla.mozilla.org.  Most of them were
confirmed by bug testers as real bugs, but most were never fixed by the
developers.

Then I got busy with other software projects (like gentoo) and stopped
filing bugs at mozilla.  The gentoo bugs I report actually get fixed
most of the time and I've learned a lot from the follow-up comments.

Re: [gentoo-user] All sorts of digest verification failures

[Dale]

Grant Edwards wrote:
> After an emerge --sync that appeared to work with no problems, my
> "emerge -auvND world" command is reporting that the Changelong files
> are broken for about 2/3 of the packages it wants to update:
>
> !!! Digest verification failed:
> !!! /usr/portage/dev-libs/libxml2/ChangeLog
> !!! Reason: Filesize does not match recorded size
> !!! Got: 5221
> !!! Expected: 5038
>
> !!! Digest verification failed:
> !!! /usr/portage/app-text/iso-codes/ChangeLog
> !!! Reason: Filesize does not match recorded size
> !!! Got: 4195
> !!! Expected: 4014
>
> [ ... and so on for another dozen or so packages ... ]
>
> I removed the emerge timestamp, sync'ed again, and got the same
> result.  Based on past experiences, I'm guessing that if I wait a day
> or two and sync again the problems will go away.
>
> But I am curious what causes these temporary breakages.  Does anybody
> know how this happens?
>


I synced just a few minutes ago and got this:




These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R] sys-apps/busybox-1.23.1-r1::gentoo  USE="ipv6 static
syslog -debug -livecd -make-symlinks -math -mdev -pam* -savedconfig
(-selinux) -sep-usr -systemd" 0 KiB
[ebuild U ~] media-libs/mesa-11.0.5::gentoo [11.0.4::gentoo]
USE="classic dri3 egl gallium gbm llvm nptl udev -bindist -d3d9 -debug
-gles1 -gles2 -opencl -openmax -osmesa -pax_kernel -pic (-selinux)
-vaapi -vdpau -wayland -xa -xvmc" ABI_X86="32 (64) (-x32)"
VIDEO_CARDS="(-freedreno) -i915 -i965 -ilo -intel -nouveau -r100 -r200
-r300 -r600 -radeon -radeonsi -vmware" 7,102 KiB
[ebuild U ~] net-analyzer/rrdtool-1.5.5::gentoo [1.5.4::gentoo]
USE="graph perl tcl tcpd -dbi -doc -lua -python -rados -rrdcgi -ruby
-static-libs" PYTHON_TARGETS="python2_7" 2,137 KiB

Total: 3 packages (2 upgrades, 1 reinstall), Size of downloads: 9,238 KiB

Would you like to merge these packages? [Yes/No] y
>>> Verifying ebuild manifests

!!! Digest verification failed:
!!! /var/cache/portage/tree/sys-apps/busybox/busybox-.ebuild
!!! Reason: Filesize does not match recorded size
!!! Got: 8493
!!! Expected: 8580
>>> Emerging (1 of 3) sys-apps/busybox-1.23.1-r1::gentoo
>>> Jobs: 0 of 3 complete, 1 runningLoad avg: 1.38,
1.81, 1.98
!!! Digest verification failed:
!!! /var/cache/portage/tree/sys-apps/busybox/busybox-.ebuild
!!! Reason: Filesize does not match recorded size
!!! Got: 8493
!!! Expected: 8580
>>> Emerging (2 of 3) media-libs/mesa-11.0.5::gentoo
>>> Failed to emerge sys-apps/busybox-1.23.1-r1
 


It would seem this is a widespread problem and not just some small fluke. 

Maybe it will sort out in a few days. 

Dale

:-)  :-) 

[gentoo-user] Re: All sorts of digest verification failures

[walt]

On Sun, 15 Nov 2015 19:05:26 + (UTC)
Martin Vaeth  wrote:

> Neil Bothwick  wrote:
> >
> > I deleted the busybox directory from the tree then ran emerge
> > --sync. The error is still there  
> 
> You have the same files that I have.
> Unfortunately, only now I actually did:
> 
> $ grep busybox- Manifest
> EBUILD busybox-.ebuild 8580 [...]
> 
> ???
> I have the same wrong size recorded in the Manifest!
> No idea why portage didn't yell at me - there seems
> to be another bug involved...

I did the same thing today (15 Nov) and it succeeded.

However, I ran the ebuild command on a non-broken ebuild.  Try
repeating the same command on busybox 1.23.x or 1.24.x

I hope the gentoo devs will fix this bug before you have a chance to
test my advice :)

Re: [gentoo-user] Re: All sorts of digest verification failures

[Matti Nykyri]

> On Nov 15, 2015, at 21:33, Alan Mackenzie  wrote:
> 
> Hello, Matti.
> 
> I deleted my /usr/portage (with the exception of
> /usr/portage/distfiles), and ran emerge --sync again.  I get precisely
> the same error message, still.

I rsync with rsync.europe.gentoo.org and with me the manifest with busybox is 
in order.  Size for .ebuild is 8493 and the Manifest has the same size. 
Also the hashes match.

I hope you get it right :)

-- 
-Matti

Re: [gentoo-user] Re: All sorts of digest verification failures

[Neil Bothwick]

On 15 November 2015 09:59:28 GMT+00:00, Alan Mackenzie  wrote:
> On Thu, Nov 12, 2015 at 06:45:44PM +0200, Alan McKinnon wrote:
> > On 12/11/2015 18:42, Grant Edwards wrote:
> > > On 2015-11-12,   wrote:
> > >> Grant Edwards  wrote:
> 
> > >>> After an emerge --sync that appeared to work with no problems,
> my
> > >>> "emerge -auvND world" command is reporting that the Changelong
> files
> > >>> are broken for about 2/3 of the packages it wants to update:
> 
> [  ]
> 
> > The dev are doing some $MAGIC to reinstate ChangeLogs and the first
> run
> > is expected to take a while (i.e. several hours). I suppose you can
> > expect some breakage till it finishes.
> 
> > It's being discussed and tracked on gentoo-dev, you can drop a mail
> > there with specifics to let the devs know what's happening.
> 
> Three days later.  I'm still getting this error message, but with a
> nasty
> twist in the tail.  emerge -puND @world reports (amongst others) the
> following update:
> 
> [ebuild   R] sys-apps/busybox-1.23.1-r1  USE="-pam*"
> 
> , and the error message I get on actually trying to start the update
> is
> 
> !!! Digest verification failed:
> !!! /usr/portage/sys-apps/busybox/busybox-.ebuild
> !!! Reason: Filesize does not match recorded size
> !!! Got: 8493
> !!! Expected: 8580
> 
> .  Why is the build system looking at the digest for version  when
> it
> should be rebuilding version 1.23.1-r1?
> 
> > -- 
> > Alan McKinnon
> > alan.mckin...@gmail.com
> 
> -- 
> Alan Mackenzie (Nuremberg, Germany).

Because the manifest covers all files in the ebuild directory, if any is 
changed the ebuilds are considered untrustworthy. This one has been around for 
a few days and there is an open bug report. 
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Re: [gentoo-user] Problems while updateing screen (tool not monitor)

[Stroller]

> On Sun, 15 November 2015, at 4:33 a.m., meino.cra...@gmx.de wrote:
> 
> screen refuses update due to an compilation error:
> 
> ...
> Is a fix for that known?

The fix is app-misc/tmux

;)

Re: [gentoo-user] Problems while updateing screen (tool not monitor)

[Meino . Cramer]

Stroller  [15-11-16 03:24]:
> 
> > On Sun, 15 November 2015, at 4:33 a.m., meino.cra...@gmx.de wrote:
> > 
> > screen refuses update due to an compilation error:
> > 
> > ...
> > Is a fix for that known?
> 
> The fix is app-misc/tmux
> 
> ;)
> 
> 

Sorry, not in my case.

How can I make screen make compile successfully?

Re: [gentoo-user] Akonadi database errors

[J. Roeleveld]

On 15 November 2015 20:49:46 CET, Mick  wrote:
>On Sunday 15 Nov 2015 17:55:08 J. Roeleveld wrote:
>
>> To migrate calendar data, I would export to an ical file and then
>reimport
>> it.
>> 
>> For contacts, use vcf.
>> 
>> Both of these are mostly human readable and allow for simple editing
>if
>> necessary.
>> 
>> I am not certain this will work. I would suggest testing with a
>temporary
>> user first.
>> 
>> --
>> Joost
>
>Thank you for your advice.  I'll try it out when a get a spare moment. 
>Last 
>question:
>
>akonadi seems to run a mysql_upgrade command whenever the mysql
>application is 
>updated by portage.  Will it also run the equivalent command with
>postgres?  
>If not, dumping and reloading all the akonadi databases will be a pain
>for a 
>desktop.
> 

It might do something similar when run 'embedded'.
I run it standalone, which means I need to handle updates myself.

Postgresql only needs extra steps for updates when changing major version. 
Which doesn't happen too often.

--
Joost 
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [gentoo-user] Problems while updateing screen (tool not monitor)

[J. Roeleveld]

On 15 November 2015 05:33:36 CET, meino.cra...@gmx.de wrote:
>Hi,
>
>screen refuses update due to an compilation error:
>
>Then type 'make' to make screen. Good luck.
>
 Source configured.
 Compiling source in
>/var/tmp/portage/app-misc/screen-4.3.1-r1/work/screen-4.3.1 ...
>make -j6 comm.h term.h 
>AWK=gawk CC="x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe -msse3
>-ggdb -D_GNU_SOURCE" srcdir=. sh ./comm.sh
>AWK=gawk srcdir=. sh ./term.sh
>make -j6 osdef.h 
>CPP="x86_64-pc-linux-gnu-gcc -E -DMAXWIN=100 -DNONETHACK
>-DETCSCREENRC='"/etc/screenrc"'
>-DSCREENENCODINGS='"/usr/share/screen/utf8encodings"'" srcdir=. sh
>./osdef.sh
>make -j6 -C doc screen.info 
>make: Entering directory
>'/var/tmp/portage/app-misc/screen-4.3.1-r1/work/screen-4.3.1/doc'
>makeinfo ./screen.texinfo -o screen.info
>./screen.texinfo:3150: `@end' expected `deffn', but saw `example'
>./screen.texinfo:3150: unmatched `@end example'
>./screen.texinfo:3152: unmatched `@end deffn'
>Makefile:30: recipe for target 'screen.info' failed
>make: *** [screen.info] Error 1
>make: Leaving directory
>'/var/tmp/portage/app-misc/screen-4.3.1-r1/work/screen-4.3.1/doc'
> * ERROR: app-misc/screen-4.3.1-r1::gentoo failed (compile phase):
> *   emake failed
> * 
>* If you need support, post the output of `emerge --info
>'=app-misc/screen-4.3.1-r1::gentoo'`,
>* the complete build log and the output of `emerge -pqv
>'=app-misc/screen-4.3.1-r1::gentoo'`.
>* The complete build log is located at
>'/var/tmp/portage/app-misc/screen-4.3.1-r1/temp/build.log'.
>* The ebuild environment file is located at
>'/var/tmp/portage/app-misc/screen-4.3.1-r1/temp/environment'.
>* Working directory:
>'/var/tmp/portage/app-misc/screen-4.3.1-r1/work/screen-4.3.1'
> * S: '/var/tmp/portage/app-misc/screen-4.3.1-r1/work/screen-4.3.1'
>
 Failed to emerge app-misc/screen-4.3.1-r1, Log file:
>
  '/var/tmp/portage/app-misc/screen-4.3.1-r1/temp/build.log'
> * 
> * The following 2 packages have failed to build, install, or execute
> * postinst:
> * 
>*  (sys-apps/busybox-1.23.1-r1:0/0::gentoo, ebuild scheduled for merge)
>*  (app-misc/screen-4.3.1-r1:0/0::gentoo, ebuild scheduled for merge),
>Log file:
> *   '/var/tmp/portage/app-misc/screen-4.3.1-r1/temp/build.log'
> * 
>
> * GNU info directory index is up-to-date.
>* After world updates, it is important to remove obsolete packages with
> * emerge --depclean. Refer to `man emerge` for more information.
>[1]13277 exit 1 emerge --update --newuse --deep --with-bdeps=y
>--tree --keep-going  --exclude
>
>This happens since some time when I update my Gentoo...
>
>Is a fix for that known?
>
>Best regards,
>Meino

The error appears to be related to creating an info-file.
You could try disabling USE flags related to documentation (usually 'doc')

--
Joost 
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[gentoo-user] Re: All sorts of digest verification failures

[Martin Vaeth]

Simon Thelen  wrote:
> I sync from git and none of my Manifests track the ebuilds, so this
> could be a thing.

No. git has (probably, I didn't check)
thin-manifests = true
in its metadata/layout.conf, but for rsync this should
not be the case for security reasons. I double-checked,
and I have indeed thin-manifests = false there, as it should be.
Nevertheless, the conflict was not reported.

Re: [gentoo-user] Re: All sorts of digest verification failures

[covici]

Martin Vaeth  wrote:

> Simon Thelen  wrote:
> > I sync from git and none of my Manifests track the ebuilds, so this
> > could be a thing.
> 
> No. git has (probably, I didn't check)
> thin-manifests = true
> in its metadata/layout.conf, but for rsync this should
> not be the case for security reasons. I double-checked,
> and I have indeed thin-manifests = false there, as it should be.
> Nevertheless, the conflict was not reported.

I have thinmanifests=true as specified in some news item or post, I
think this was a mandatory change some time ago using rsync.  They
figured the ebuilds sync anyway so no reason for the manifests to have
them.

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

 John Covici
 cov...@ccs.covici.com

Re: [gentoo-user] Re: All sorts of digest verification failures

[Neil Bothwick]

On Sun, 15 Nov 2015 14:56:42 + (UTC), Martin Vaeth wrote:

> >!!! /usr/portage/sys-apps/busybox/busybox-.ebuild
> >!!! Got: 8493
> >!!! Expected: 8580  
> 
> Do you use the default (rsync) for syncing, or have you changed
> the method?
> 
> I have the above claimed filesize (8493), but the Manifest
> I obtained from rsync is correct.
> 
> The timestamp of the Manifest file in that folder is
> Nov 13, 08:17:31 (UTC)
> (do not forget to export TZ=UTC when you check the date).
> Exactly the same date has the ChangeLog file in that folder
> (which is not surprsing).
> 
> If in your case ChangeLog and Manifest *both* have an older date,
> you got the data perhaps from an outdated mirror.
> 

I deleted the busybox directory from the tree then ran emerge --sync. The
error is still there

-rw-r--r-- 1 root root  8388 Aug  9 21:34 busybox-1.21.0.ebuild
-rw-r--r-- 1 root root  8573 Aug  9 21:34 busybox-1.23.1.ebuild
-rw-r--r-- 1 root root  8611 Aug  9 21:34 busybox-1.23.1-r1.ebuild
-rw-r--r-- 1 root root  8724 Aug  9 21:34 busybox-1.23.2.ebuild
-rw-r--r-- 1 root root  8577 Nov 13 06:01 busybox-1.24.1.ebuild
-rw-r--r-- 1 root root  8493 Nov 13 06:01 busybox-.ebuild
-rw-r--r-- 1 root root  4402 Nov 13 07:17 ChangeLog
-rw-r--r-- 1 root root 60228 Nov  9 05:01 ChangeLog-2015
drwxr-xr-x 1 root root  1528 Nov 15 17:15 files
-rw-r--r-- 1 root root 19287 Nov 13 07:17 Manifest
-rw-r--r-- 1 root root   788 Aug 24 22:01 metadata.xml

-- 
Neil Bothwick

Our bikinis are exciting. They are simply the tops.


pgpc21vIjKxJm.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Re: firefox profile uses 100% CPU

[Peter Weilbacher]

On Thu, 12 Nov 2015, walt wrote:

> On Wed, 11 Nov 2015 17:38:45 -0700 the...@sys-concept.com wrote:
>
> > When I start one of my firefox profile (even in "-save-mode")

That would be "-safe-mode" by the way, with an "f".

> I had a bad problem with the firefox profile manager about a year ago
> and I decided that the devs at mozilla are not maintaining that code
> any more, so I stopped using the profile manager.

What made you decide that? Are you a manager at Mozilla?

> Firefox/mozilla is a very old project with limited resources.

Yes, as a multi-million dollar company they are severely limited...

> The current developers are working full speed on security updates,
> which is good, but there is a lot of bitrot in their huge codebase.

Huh? What do you call "bitrot" and what indication for that do you see?
   Peter.