[gentoo-user] About procmail and getline

[gentoo-user] About procmail and getline

[Harry Putnam]

Trying to install procmail I hit a known bug:

   http://bugs.gentoo.org/show_bug.cgi?id=270551

And from emerge:
  [...]
  In file included from formail.c:25:
  formisc.h:20: error: conflicting types for 'getline'
  /usr/include/stdio.h:651: error: previous declaration of 'getline'
  was here
  make[1]: *** [formail.o] Error 1
  make[1]: Leaving directory
  `/var/tmp/portage/mail-filter/procmail-3.22-r10/work/procmail-3.22/src'

What I'm not understanding is why the current procmail is not flagged
in some way... or why its still not fixed and is buggy to install with
most recent OS and most recent tools.

Its not, apparently a local phenomina, if its a known bug.  Or are
there people who have been able to install procmail with no problems
using current tools?

Even downloading the tar ball and building outside of emerge I hit the
getline problem, so apparently something incompatible there.

There is a patch offered but still one would think using standard
emerge on a package that is outside the `~' daredevil stage and is not
masked, it should `just work' [tm]. 

Re: [gentoo-user] About procmail and getline

[Sebastian Günther]

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

* Harry Putnam (reader@newsguy.com) [12.06.09 16:41]:
> 
> There is a patch offered but still one would think using standard
> emerge on a package that is outside the `~' daredevil stage and is not
> masked, it should `just work' [tm]. 
> 
>

When I read the bug rightfully, procmail did not build with glibc 
2.10.1, which is *not* stable yet, especially because of a lot packages 
which don't build cleanly with it at the moment.

So if you'd use the stable glibc it would build fine. There is no need 
to mark procmail in any way. ~x86 should be able to apply patches on 
their own, or wait until the patch arrives in tree.

Sebastian

-- 
 " Religion ist das Opium des Volkes. "  |   _   ASCII ribbon campaign 
                              Karl Marx  |  ( )   against HTML e-mail  
 SEB@STI@N GÜNTHER                       |   X   against M$ attachments
      mailto:samson@guenther-roetgen.de  |  / \   www.asciiribbon.org  

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-user] Re: About procmail and getline

[Harry Putnam]

Sebastian Günther <samson@guenther-roetgen.de> writes:

> * Harry Putnam (reader@newsguy.com) [12.06.09 16:41]:
>> 
>> There is a patch offered but still one would think using standard
>> emerge on a package that is outside the `~' daredevil stage and is not
>> masked, it should `just work' [tm]. 
>> 
>>
>
> When I read the bug rightfully, procmail did not build with glibc 
> 2.10.1, which is *not* stable yet, especially because of a lot packages 
> which don't build cleanly with it at the moment.
>
> So if you'd use the stable glibc it would build fine. There is no need 
> to mark procmail in any way. ~x86 should be able to apply patches on 
> their own, or wait until the patch arrives in tree.

Having run ~x86 since starting to build this install... how big of a
problem would it be to return to stable?

Re: [gentoo-user] Re: About procmail and getline

[Alan McKinnon]

On Sunday 14 June 2009 19:38:42 Harry Putnam wrote:
> Sebastian Günther <samson@guenther-roetgen.de> writes:
> > * Harry Putnam (reader@newsguy.com) [12.06.09 16:41]:
> >> There is a patch offered but still one would think using standard
> >> emerge on a package that is outside the `~' daredevil stage and is not
> >> masked, it should `just work' [tm].
> >
> > When I read the bug rightfully, procmail did not build with glibc
> > 2.10.1, which is *not* stable yet, especially because of a lot packages
> > which don't build cleanly with it at the moment.
> >
> > So if you'd use the stable glibc it would build fine. There is no need
> > to mark procmail in any way. ~x86 should be able to apply patches on
> > their own, or wait until the patch arrives in tree.
>
> Having run ~x86 since starting to build this install... how big of a
> problem would it be to return to stable?

Much more work than it's worth. It's easier to reinstall.

You run into issues like baselayout. Latest unstable is 2.0.1, latest stable 
is 1.12.11.1. When you emerged baselayout, it either created a whole whack of 
new files and included openrc, or upgraded the existing baselayout-1 stuff to 
baselayout-2 spec.

Either way, the ebuild does not know how to go back down one version. 
baselayout affects a huge number of things, not the least of which is how to 
load lvm and soft raid modules. I've never attempted this change myself, and 
am not likely too either - it's way too easy to predict the resulting mess.

There was a recent thread on this, and the OP eventually decided to write a 
script that listed every package he had and copy this to package.mask (with 
">" in front of course), then just wait for everything in stable to catch up.

Your other option is to locate problematic packages individually and put just 
those into package.mask - pegging them at known working versions. 

-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] Re: About procmail and getline

[Stroller]

On 15 Jun 2009, at 08:34, Alan McKinnon wrote:
> ...
> Much more work than it's worth. It's easier to reinstall.
> ...
> There was a recent thread on this, and the OP eventually decided to  
> write a
> script that listed every package he had and copy this to  
> package.mask (with
> ">" in front of course), then just wait for everything in stable to  
> catch up.

I considered that to be an easy & straight-forward way to undertake  
the "downgrade".

I'm not sure if every installed package was marked in this way or  
merely every package in world?

But indeed the poster who suggested this method stated that he had  
gone from ~x86 to fully x86 in a matter of a few months.

Stroller.

Re: [gentoo-user] Re: About procmail and getline

[Alan McKinnon]

On Monday 15 June 2009 18:50:58 Stroller wrote:
> On 15 Jun 2009, at 08:34, Alan McKinnon wrote:
> > ...
> > Much more work than it's worth. It's easier to reinstall.
> > ...
> > There was a recent thread on this, and the OP eventually decided to
> > write a
> > script that listed every package he had and copy this to
> > package.mask (with
> > ">" in front of course), then just wait for everything in stable to
> > catch up.
>
> I considered that to be an easy & straight-forward way to undertake
> the "downgrade".
>
> I'm not sure if every installed package was marked in this way or
> merely every package in world?

Mark everything. Otherwise you end up with with 150 packages in world at 
stable, and the other 850 packages which are DEPs at unstable. And that's 
where all hell breaks loose.

Whether a dep is installed arch or ~arch depends only on ACCEPT_KEYWORDS and 
explicit directives in /etc/portage/*, and nothing to do with the package that 
pulled it in (exception: a package that defines a version or range of versions 
in it's DEPENDS)


-- 
alan dot mckinnon at gmail dot com

[gentoo-user] Re: About procmail and getline

[Harry Putnam]

Sebastian Günther <samson@guenther-roetgen.de> writes:

> * Harry Putnam (reader@newsguy.com) [12.06.09 16:41]:
>> 
>> There is a patch offered but still one would think using standard
>> emerge on a package that is outside the `~' daredevil stage and is not
>> masked, it should `just work' [tm]. 
>> 
>>
>
> When I read the bug rightfully, procmail did not build with glibc 
> 2.10.1, which is *not* stable yet, especially because of a lot packages 
> which don't build cleanly with it at the moment.
>
> So if you'd use the stable glibc it would build fine. There is no need 
> to mark procmail in any way. ~x86 should be able to apply patches on 
> their own, or wait until the patch arrives in tree.

Probably should use only stable but never have in over 5 yrs.
Probably much to the dismay of this list.

But even then, when a package is known in advance NOT to install with
current ~x86 tools, seems there would be some way to let user know
that.

Since you've said it is because of glibc... and this is a known bug
seems there might be a way to flag or mark procmail as incompatible
with it.

Maybe that would be way to hard to keep up with?

Re: [gentoo-user] Re: About procmail and getline

[Sebastian Günther]

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

* Harry Putnam (reader@newsguy.com) [14.06.09 19:46]:
> Sebastian Günther <samson@guenther-roetgen.de> writes:
> 
> > * Harry Putnam (reader@newsguy.com) [12.06.09 16:41]:
> >> 
> >> There is a patch offered but still one would think using standard
> >> emerge on a package that is outside the `~' daredevil stage and is not
> >> masked, it should `just work' [tm]. 
> >> 
> >>
> >
> > When I read the bug rightfully, procmail did not build with glibc 
> > 2.10.1, which is *not* stable yet, especially because of a lot packages 
> > which don't build cleanly with it at the moment.
> >
> > So if you'd use the stable glibc it would build fine. There is no need 
> > to mark procmail in any way. ~x86 should be able to apply patches on 
> > their own, or wait until the patch arrives in tree.
> 
> Probably should use only stable but never have in over 5 yrs.
> Probably much to the dismay of this list.
> 
> But even then, when a package is known in advance NOT to install with
> current ~x86 tools, seems there would be some way to let user know
> that.
> 

First of all the bug is fixed, and a working patch was there 1 day after 
the opening. I call this a fast response...

For ~x86 this is a working solution, and if you use ~x86: b.g.o *is* the 
users information system and applying patches should be no problem.

> Since you've said it is because of glibc... and this is a known bug
> seems there might be a way to flag or mark procmail as incompatible
> with it.
> 

The problem with glibc is, that you only find issues when you recompile 
your whole world, which is not needed in most cases. And most of the 
errors with glibc-2.10.1 result from wrong castings, which is only a 
compile time issue not a run issue.

And all these problems are upstream, so you can patch for yourself in 
gentoo, but the cleaner solution is to wait for upstream to include the 
patch there. And release a new version, when they do too...

Sebastian

-- 
 " Religion ist das Opium des Volkes. "  |   _   ASCII ribbon campaign 
                              Karl Marx  |  ( )   against HTML e-mail  
 SEB@STI@N GÜNTHER                       |   X   against M$ attachments
      mailto:samson@guenther-roetgen.de  |  / \   www.asciiribbon.org  

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-user] Re: About procmail and getline

[Harry Putnam]

Sebastian Günther <samson@guenther-roetgen.de> writes:

> First of all the bug is fixed, and a working patch was there 1 day after 
> the opening. I call this a fast response...
> 
> For ~x86 this is a working solution, and if you use ~x86: b.g.o *is* the 
> users information system and applying patches should be no problem.

Point taken.
 
> The problem with glibc is, that you only find issues when you recompile 
> your whole world, which is not needed in most cases. And most of the 
> errors with glibc-2.10.1 result from wrong castings, which is only a 
> compile time issue not a run issue.
>
> And all these problems are upstream, so you can patch for yourself in 
> gentoo, but the cleaner solution is to wait for upstream to include the 
> patch there. And release a new version, when they do too...

Thanks for your patience and I learned in an earlier thread one very easy
way to get things working... 

I guess you'd still call it a patch... but not requiring setting up
your own local portage and producing a patched version.

ebuild /usr/portage/<section>/<pkg>/pkg.ebuild configure

  Do necessary manipulations

ebuild /usr/portage/<section>/<pkg>/pkg.ebuild merge

I realize in some cases that would be a recurring chore but I kind of
doubt it this time.  procmail will not likely need updating for some
time and then like you've suggested portage will have it fixed.