Re: [gentoo-amd64] Gnupg doesn't build

Re: [gentoo-amd64] Gnupg doesn't build

[Daniel Gryniewicz]

[-- Attachment #1: Type: text/plain, Size: 754 bytes --]

On Mon, 2006-11-06 at 11:56 -0500, Mark Haney wrote:
> I've tried everything over the last couple of days to upgrade gnupg and 
> I get the same thing:
> 
> octavian ~ # emerge -u gnupg
> Calculating dependencies... done!
>  >>> Auto-cleaning packages...
> 
>  >>> No outdated packages were found on your system.
> 
> 
>  * GNU info directory index is up-to-date.
> 
> And it never gets upgraded.  Has anyone else seen this?
> 

That indicates that portage thinks you have the newest version already.
Which version do you have?  Which do you want?  Is the newer version
masked by either package.mask (/usr/portage/profiles/package.mask
or /etc/portage/package.mask)?  Is the newer version keyworded higher
than you accept?

Daniel

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-amd64] Gnupg doesn't build

[Mark Haney]

I've tried everything over the last couple of days to upgrade gnupg and 
I get the same thing:

octavian ~ # emerge -u gnupg
Calculating dependencies... done!
 >>> Auto-cleaning packages...

 >>> No outdated packages were found on your system.


 * GNU info directory index is up-to-date.

And it never gets upgraded.  Has anyone else seen this?

-- 
Ceterum censeo, Carthago delenda est.

Mark Haney
Sr. Systems Administrator
ERC Broadband
(828) 350-2415

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Gnupg doesn't build

[Mark Haney]

Christoph Mende wrote:
> On Mon, 2006-11-06 at 11:56 -0500, Mark Haney wrote:
>   
>> I've tried everything over the last couple of days to upgrade gnupg and 
>> I get the same thing:
>>
>> octavian ~ # emerge -u gnupg
>> Calculating dependencies... done!
>>  >>> Auto-cleaning packages...
>>
>>  >>> No outdated packages were found on your system.
>>
>>
>>  * GNU info directory index is up-to-date.
>>
>> And it never gets upgraded.  Has anyone else seen this?
>>     
>
> Yeah, I get this on every package that's already up-to-date ;)
>
>   
Yeah well that's not what portage says. (And I probably should have 
explained a bit deeper.  It was a LONG weekend.)

[ebuild     U ] app-crypt/gnupg-1.4.5-r2 [1.4.5] USE="-X* -bindist% -usb*"

That's what I have showing up in portage.



-- 
Ceterum censeo, Carthago delenda est.

Mark Haney
Sr. Systems Administrator
ERC Broadband
(828) 350-2415

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Gnupg doesn't build

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 932 bytes --]

On Mon, 06 Nov 2006 12:06:56 -0500, Mark Haney wrote:

> >> octavian ~ # emerge -u gnupg
> >> Calculating dependencies... done!  
> >>  >>> Auto-cleaning packages...  
> >>  
> >>  >>> No outdated packages were found on your system.  
> >>
> >>
> >>  * GNU info directory index is up-to-date.
> >>
> >> And it never gets upgraded.  Has anyone else seen this?
> >>       
> >
> > Yeah, I get this on every package that's already up-to-date ;)
> >
> >     
> Yeah well that's not what portage says. (And I probably should have 
> explained a bit deeper.  It was a LONG weekend.)
> 
> [ebuild     U ]  [1.4.5] USE="-X* -bindist%
> -usb*"
> 
> That's what I have showing up in portage.

gnupg is slotted, and the highest version slot is up to date. try 

emerge --oneshot =app-crypt/gnupg-1.4.5-r2


-- 
Neil Bothwick

"There's more to life than sex, beer and computers.
Not a lot more admittedly..."

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-amd64] Gnupg doesn't build

[Christoph Mende]

On Mon, 2006-11-06 at 11:56 -0500, Mark Haney wrote:
> I've tried everything over the last couple of days to upgrade gnupg and 
> I get the same thing:
> 
> octavian ~ # emerge -u gnupg
> Calculating dependencies... done!
>  >>> Auto-cleaning packages...
> 
>  >>> No outdated packages were found on your system.
> 
> 
>  * GNU info directory index is up-to-date.
> 
> And it never gets upgraded.  Has anyone else seen this?

Yeah, I get this on every package that's already up-to-date ;)

-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] coreutils-6.4 - cannot install

[Mauro Maroni]

-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] coreutils-6.4 - cannot compile

[Mauro Maroni]

Hello:

Did anyone get a segmentation fault when installing coreutils-6.4?
See build error below

Regards,
Mauro

....
config.status: creating po/POTFILES
config.status: creating po/Makefile
/usr/portage/sys-apps/coreutils/coreutils-6.4.ebuild: line 79: 12677 
Segmentation fault      emake

!!! ERROR: sys-apps/coreutils-6.4 failed.
Call stack:
  ebuild.sh, line 1546:   Called dyn_compile
  ebuild.sh, line 937:   Called src_compile
  coreutils-6.4.ebuild, line 101:   Called die

-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: coreutils-6.4 - cannot compile

[Duncan]

Mauro Maroni <mmaroni@fi.uba.ar> posted
200611062236.11240.mmaroni@fi.uba.ar, excerpted below, on  Mon, 06 Nov
2006 22:36:11 -0300:

> References: <454F6945.1090704@ercbroadband.org>

> Did anyone get a segmentation fault when installing coreutils-6.4? See
> build error below

See that references header I quoted above?  That means you replied to a
previous post (which was on a totally different topic, gnupg, as it
happens), instead of starting a new thread. That's called hijacking a
thread, and is considered a violation of netiquette, as many people's
clients actually display threaded replies under the original post. If you
are replying, reply on topic. If you are starting a new topic, please do
it with a new post to a new thread, not a reply to an existing thread.

Briefly answering your question anyway... I have it merged here, which
means it must have merged just fine.  According to the date on one of the
package files, I merged it Oct. 24th.

I'm not an i18n/l10n (internationalization/localization) expert by far, as
I do only English and thus turn most of that stuff off where I can. 
However, if I'm not mistaken, po files are l10n related.  A quick google
says the .ar in your email address is Argentina, so it's relatively likely
you are localized to something other than the en-us I use and that tends
to be the default unlocalized version.  I'd do a bugsearch on
bugs.gentoo.org (don't forget to search on closed bugs too as it may have
just been fixed), and if there's nothing filed on the package that looks
like what you are seeing, file a bug report.  

In the mean time, you /might/ be able to merge it USE=-nls if you don't
mind giving up the l10n stuff. That is how I have it merged and would be
my guess as to what controls the po file stuff.

Still, that bug report is worthwhile, as the segfault points to an issue
that needs resolved.  (Be glad you aren't Estonian, "et" IIRC.  From a few
bug reports I've read, that l10n is one of the worst, as the letters are
in a different order resulting in all sorts of unanticipated stuff
happening when the normal ordering assumptions prove incorrect.  There's
an Estonian guy that has unfortunately had to become quite familiar with
bugzilla due to all the bugs he files as a result, but the devs appreciate
it as it points out bugs due to invalid assumptions, that nobody else
runs into.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: coreutils-6.4 - cannot compile

[Mauro Maroni]

On Tuesday 07 November 2006 05:39, Duncan wrote:
> Mauro Maroni <mmaroni@fi.uba.ar> posted
> 200611062236.11240.mmaroni@fi.uba.ar, excerpted below, on  Mon, 06 Nov
>
> 2006 22:36:11 -0300:
> > References: <454F6945.1090704@ercbroadband.org>
> >
> > Did anyone get a segmentation fault when installing coreutils-6.4? See
> > build error below
>
> See that references header I quoted above?  That means you replied to a
> previous post (which was on a totally different topic, gnupg, as it
> happens), instead of starting a new thread. 

Sorry about that, I believe I was going to reply something but suddenly had 
that coreutils issue and ended re-writting on the same email somehow

>
> Briefly answering your question anyway... I have it merged here, which
> means it must have merged just fine.  According to the date on one of the
> package files, I merged it Oct. 24th.

Well, then I got segfaults compiling other packages, and a couple of times the 
machine freezed doing trivial things like browsing the web. Could this be a 
hardware issue? RAM seems to be OK as I ran memtest during the night and did 
not show any error after 9 hours.


-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: coreutils-6.4 - cannot compile

[Duncan]

Mauro Maroni <mmaroni@fi.uba.ar> posted
200611082025.25462.mmaroni@fi.uba.ar, excerpted below, on  Wed, 08 Nov
2006 20:25:25 -0300:

> Well, then I got segfaults compiling other packages, and a couple of
> times the machine freezed doing trivial things like browsing the web.
> Could this be a hardware issue? RAM seems to be OK as I ran memtest
> during the night and did not show any error after 9 hours.

That's a classic hardware issue, yes.  The cause can be one of several
things.  Note that there are at least two ways RAM can be bad and memtest
checks only one -- memory actually corrupting in storage.  From hard
experience, I know the other one all too well -- AND know that memtest
doesn't catch it AT ALL.  That one is memory timing issues, and as
memory speeds increase, it's becoming more and more common.  Taking my
case as an example, the RAM was rated PC3200, but simply wasn't stable at
that.  Unfortunately, my mobo was new enough at the time, and using the
then new AMD64 memory-controller-on-CPU technology, that the BIOS didn't
have the usual memory speed tweaking options.  After fighting with it for
some time, a BIOS upgrade was eventually made available that added these
options, and a very simple (with the right BIOS option) tweak to reduce
memory clocking from the rated PC3200 (200 MHz DDRed to 400, times 8 bit
bus width, equals 3200) to ~PC3000 (183 MHz DDred to 366, times 8, rounds
to 3000) eliminated the issue entirely.  The system was then rock-stable,
even after tweaking some of the detailed individual wait-state settings
back up to increase the performance a bit from the defaults.

So, before you eliminate memory as a possibility, check your BIOS and try
declocking it a notch or two.

Actually, all the hardware possibilities trace to the same root, what
should be a binary one becoming at times a binary zero, very often due to
undervolting.  This can be due to speed issues, as with the above or if
you overclock your memory or CPU, or power issues, which may occur
anywhere in your "power train", from the stuff coming to you from your
electricity supplier, to an underpowered computer power supply, to an
underpowered single voltage rail on that supply, to an underpowered UPS,
to a faulty power regulator on your mobo, to a bad connection somewhere,
to simply having to many things connected to the computer at once.  Or it
can be both power and speed issues, since higher speeds commonly require
more power in ordered to remain stable.  (This makes perfect sense given
that higher speeds mean there's less time to actually bring the transistor
to the high voltage "1" state before actually seeing if it is a 1 or a 0,
and boosting the supply voltage -- to a point -- can often make it reach
that state faster.)

So, it should go without saying, but cut the overclocking if you were
doing it (and note that overclocking can cause permanent damage even after
returning to normal clocking)  Next, check your power supply, both at the
wall plug and that you are using a good PSU in the computer, sufficiently
highly rated and UL Listed (if in the US, substitute the appropriate
authority if elsewhere), since it's common knowledge that the rating of
many power supplies lacking this listing aren't worth the cost of ink used
to print the rating.  If you are using a UPS, check that too.

Finally, check for overheating.

Those are the most common hardware causes of instability.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: coreutils-6.4 - cannot compile

[Mauro Maroni]

On Thursday 09 November 2006 07:51, Duncan wrote:
> Mauro Maroni <mmaroni@fi.uba.ar> posted
> 200611082025.25462.mmaroni@fi.uba.ar, excerpted below, on  Wed, 08 Nov
>
> 2006 20:25:25 -0300:
> > Well, then I got segfaults compiling other packages, and a couple of
> > times the machine freezed doing trivial things like browsing the web.
> > Could this be a hardware issue? RAM seems to be OK as I ran memtest
> > during the night and did not show any error after 9 hours.
>
> That's a classic hardware issue, yes.  The cause can be one of several
> things.  Note that there are at least two ways RAM can be bad and memtest
> checks only one -- memory actually corrupting in storage.  From hard
> experience, I know the other one all too well -- AND know that memtest
> doesn't catch it AT ALL.  That one is memory timing issues, and as
> memory speeds increase, it's becoming more and more common.  Taking my
> case as an example, the RAM was rated PC3200, but simply wasn't stable at
> that.  Unfortunately, my mobo was new enough at the time, and using the
> then new AMD64 memory-controller-on-CPU technology, that the BIOS didn't
> have the usual memory speed tweaking options.  After fighting with it for
> some time, a BIOS upgrade was eventually made available that added these
> options, and a very simple (with the right BIOS option) tweak to reduce
> memory clocking from the rated PC3200 (200 MHz DDRed to 400, times 8 bit
> bus width, equals 3200) to ~PC3000 (183 MHz DDred to 366, times 8, rounds
> to 3000) eliminated the issue entirely.  The system was then rock-stable,
> even after tweaking some of the detailed individual wait-state settings
> back up to increase the performance a bit from the defaults.
>
> So, before you eliminate memory as a possibility, check your BIOS and try
> declocking it a notch or two.

It has been very stable during the last days.  But I will give this a try if 
the problem comes back. Thanks a lot for your answer.

Mauro

-- 
gentoo-amd64@gentoo.org mailing list