mailbase-0.00-r8 breaks things again.

[Antek Grzymala]

Hi,

I just upgraded to mailbase-0.00-r8 (having to remove /etc/pam.d/{imap,pop}), and again got into problems with running programs that access /var/spool/mail/<whatever> directly.

Can't the devs agree on a sensible set of permissions for mailbase and make other programs adhere to it? I'm using (and I'm not alone) mutt and evolution, and they both break with the new mailbase perms:

mutt: "Folder readonly" -> (Recompliing mutt fixes that)
evolution: "Could not lock folder /var/spool/whatever..." -> (Still got to see whether recompiling evolution will fix this)

There should be some loud einfo in the ebuild telling people what to do after upgrading to this version (like rebuilding your mutt), and I consider the lack of it a major s*up.

Apart from that -- thanks to the devs for all the great work.

Antoni

Update: Recompiling evolution helped as far as I'm concerned. Don't know about any other mail clients, as I'm not using them.

[j-m]

Ehmm....

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

And, basically, 1777 or 0777 is insecure, see http://bugs.gentoo.org/show_bug.cgi?id=16749 for reasons.

[Antek Grzymala]

Ehmm....

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

This is about -r6 (and I've already been through the -r5 -r6 mess), guess something could have been done, at least warning users.

[a]

[j-m]

This is about -r6 (and I've already been through the -r5 -r6 mess), guess something could have been done, at least warning users.

No, this is not about -r6, this is the explanation of your problems and applies to -r8 likewise. Please post you comments and suggestions there, it won´t help at all if you rant here.

[Dave_Lindquist]

OK, this is the first time I've come away without any helpful advice from searching the forums

I've read the bugs mentioned, and they don't seem to have any helpful advice, just a lot of commentary that I'm not following very well...

I'm stuck with a mailbase update I can't emerge because it collides with qpopper on /etc/pam.d/pop3.

So, one of the following must be true:
1) mailbase is broken
2) qpopper is broken
3) I'm an idiot for having both mailbase and qpopper installed

Can someone explain what the issues are?

It seems to me that qpopper (being the one that does the authentication) is the logical candidate to hold the pam.d file.... Which then begs the question of why mailbase is suddenly trying to do it?

Anyone have any solutions yet?

[j-m]

OK, this is the first time I've come away without any helpful advice from searching the forums

I've read the bugs mentioned, and they don't seem to have any helpful advice, just a lot of commentary that I'm not following very well...

I'm stuck with a mailbase update I can't emerge because it collides with qpopper on /etc/pam.d/pop3.

So, one of the following must be true:
1) mailbase is broken
2) qpopper is broken
3) I'm an idiot for having both mailbase and qpopper installed

OMG. Can´t you read plain English instructions provided by the ebuild?

- move the colliding files somewhere else
- emerge mailbase
- if needed, put your customizations back to those files now emerged by mailbase
- done

This all is written plain and clear in the error message. I don´t understand what is your problem.

[stolen]

The problem is, why do we have multiple packages supplying the same files, when we need those packages to be installed at the same time?

[j-m]

The problem is, why do we have multiple packages supplying the same files, when we need those packages to be installed at the same time?

The whole purpose of mailbase´s existence is to remove the behaviour you have just discribed...

[Dave_Lindquist]

OMG. Can´t you read plain English instructions provided by the ebuild?

- move the colliding files somewhere else
- emerge mailbase
- if needed, put your customizations back to those files now emerged by mailbase
- done

This all is written plain and clear in the error message. I don´t understand what is your problem.

...and then if I need to rebuild qpopper for some reason, boom, there goes the mailbase version of the file....

The point is not that I *could* do this, the point is that this isn't a solution.

From your last post, it sounds like the intention is to migrate this file *out* of qpopper (or whatever other package provides it), and *into* mailbase, and only half the job is done?

After all the whole point of ebuilds is to remove the manual labor necessary to install, upgrade, and maintain things

(I apologize for the nerve I seem to have stepped on... )

[j-m]

...and then if I need to rebuild qpopper for some reason, boom, there goes the mailbase version of the file....

Try the latest unstable version of qpopper. If you have this problem with that one, file a bug for qpopper. Mailbase aims to emerge files common to all MTA packages itself and remove that files from all other MTA ebuilds. I really can´t see why it this so hard to understand. The only problem is that you have to do the transition - this horrible trouble consists of following the instructions and moving one or two files somewhere else. Duh!

Code: Select all

# ChangeLog for net-mail/qpopper
# Copyright 2000-2005 Gentoo Foundation; Distributed under the GPL v2
# $Header: /var/cvsroot/gentoo-x86/net-mail/qpopper/ChangeLog,v 1.19 2005/02/14 13:49:32 plasmaroo Exp $

  14 Feb 2005; <plasmaroo@gentoo.org> qpopper-4.0.5-r1.ebuild,
  qpopper-4.0.5-r2.ebuild:
  Add sys-libs/db DEPEND if we're not using gdbm.

*qpopper-4.0.5-r2 (13 Feb 2005)

  13 Feb 2005; Fernando J. Pereda <ferdy@gentoo.org>
  +qpopper-4.0.5-r2.ebuild:
  Remove pam.d stuff and make it depend on at least mailbase-0.00-r8 (#79240)

[]DL[JimmyJazz]

OMG. Can´t you read plain English instructions provided by the ebuild?

- move the colliding files somewhere else
- emerge mailbase
- if needed, put your customizations back to those files now emerged by mailbase
- done

This all is written plain and clear in the error message. I don´t understand what is your problem.

I can read plain English, but I don't see a damned word about why this collision exists.

Code: Select all

>>> emerge (1 of 1) net-mail/mailbase-0.00-r8 to /
 * Checking for possible file collisions...
 * //etc/pam.d/pop3 exists and wasn't provided by mailbase
 * //etc/pam.d/imap exists and wasn't provided by mailbase

 * Those files listed above have to be removed in order to
 *  install this version of mailbase.

 * If you edited them, remember to backup and when restoring make
 *  sure the first line in each file is:
 * # Provided by mailbase (dont remove this line!)

!!! ERROR: net-mail/mailbase-0.00-r8 failed.
!!! Function pkg_setup, Line 50, Exitcode 0
!!! Can't be installed, files will collide
!!! If you need support, post the topmost build error, NOT this status message.


Messages from build:

 === 2005-03-04 17:13 ==== mailbase-0.00-r8 ===
 * Checking for possible file collisions...
 * //etc/pam.d/pop3 exists and wasn't provided by mailbase
 * //etc/pam.d/imap exists and wasn't provided by mailbase
 * Those files listed above have to be removed in order to
 *  install this version of mailbase.
 * If you edited them, remember to backup and when restoring make
 *  sure the first line in each file is:
 * # Provided by mailbase (dont remove this line!)
!!! ERROR: net-mail/mailbase-0.00-r8 failed.
!!! Function pkg_setup, Line 50, Exitcode 0
!!! Can't be installed, files will collide
!!! If you need support, post the topmost build error, NOT this status message.

(These messages can be seen in /tmp/emerge-watched.log)

The problem, my nearsighted friend, is that in world of real production servers, sysadmins are not button-pushing monkeys, but are actually responsible for the health of the systems under their care. Real sysadmins need to know the why as well as the what in the ebuild info. We can't be satisfied with watching our feet, but need to see a ways down the road, as well. The job's half-baked? Not good enough. Unstable versions on production servers? Not in this lifetime. As much as I like Gentoo for the most part, it's crap like this that prevents it from being taken seriously in the corporate world. And it's self-righteous buttheads like yourself that keep Linux from becoming more mainstream than it should be. Try to see the world from eyes that aren't nose-deep in MTA lore, buddy.

[Carlo]

The problem, my nearsighted friend, is that in world of real production servers, sysadmins are not button-pushing monkeys, but are actually responsible for the health of the systems under their care. Real sysadmins need to know the why as well as the what in the ebuild info. We can't be satisfied with watching our feet, but need to see a ways down the road, as well. The job's half-baked? Not good enough. Unstable versions on production servers? Not in this lifetime. As much as I like Gentoo for the most part, it's crap like this that prevents it from being taken seriously in the corporate world. And it's self-righteous buttheads like yourself that keep Linux from becoming more mainstream than it should be. Try to see the world from eyes that aren't nose-deep in MTA lore, buddy.

It shows indeed that Gentoo isn't as matured as e.g. Debian. If you consider the growth rate of Gentoo and the amount of work compared to the number of developers, it'd maybe a good idea to ask yourself what you can do - hey, it's still a community distro - to improve the situation, instead ranting.

Staffing Needs

[j-m]

OMG. Can´t you read plain English instructions provided by the ebuild?

- move the colliding files somewhere else
- emerge mailbase
- if needed, put your customizations back to those files now emerged by mailbase
- done

This all is written plain and clear in the error message. I don´t understand what is your problem.

I can read plain English, but I don't see a damned word about why this collision exists.

This collision exists b/c two or more packages provide the same files. You need to apply common sense, that´s enough. If it does not help, then sorry. The mailbase ebuild was made exactly to get rid of this, duh!

The only "problem" is that you have to do the transition at some point of time, what on earth is so difficult to understand? That you need move the damned two plaintext files out of the way? If you are unable to do this, then find someone who can. Also if you would be so kind and did search the bugzilla, you would find the answers there.

[Buzz]

OMG. Can´t you read plain English instructions provided by the ebuild?

This collision exists b/c two or more packages provide the same files. You need to apply common sense, that´s enough. If it does not help, then sorry. The mailbase ebuild was made exactly to get rid of this, duh!

The only "problem" is that you have to do the transition at some point of time, what on earth is so difficult to understand? That you need move the damned two plaintext files out of the way? If you are unable to do this, then find someone who can. Also if you would be so kind and did search the bugzilla, you would find the answers there.

This kind of arrogant, condescending language is totally unnecessary and baffles me as to the motive you have in using it. This is the first forum I encounter about this problem, and while your posts seem to be helpful, it looks like a requirement for getting the help is to be subjected to "It is so ridiculously, insanely, obvious!! Try to overcome your inferior intellect and spontaneously 'know' what you came here to find out." Duh! Everybody has different backgrounds and levels of competency with regards to different packages, what they do, and how doing different things within the gentoo system affect their lives.

For what it's worth, it is much clearer to me what is going on after sifting through your above posts...

Thanks for your answers,

Buzz

[j-m]

I´ve been trying to explain several times what is mailbase and what to do with this issue. After all of this, the comment comes:

Real sysadmins need to know the why as well as the what in the ebuild info. We can't be satisfied with watching our feet, but need to see a ways down the road, as well. The job's half-baked? Not good enough.

Sorry, you won´t get the "why" sort of information in RPMs, you won´t get them in DEBs, you won´t get them in TGZs. You have changelogs, you have forums, documentation, you have http://gentoo-portage.com/, you have bugzilla... So please don´t complain "why oh why I don´t get any information about that evil mailbase package which broke my Gentoo". It´s really just a pathetic attempt.

[mciann]

j-m -

I am also one of the people who are trying to actually use the system for something other than watching glxgears. We can read the error and understand how to blindly resolve it, if that is what we want to do. Those of us responsible for maintaining these systems have a few pertinent questions before we go moving files around and restoring them.

If we move the files away, emerge -u mailbase, then move them back, we will obviously arrive at a final configuration other than what was intended by mailbase. The contents of certain VERY important files will be changed from the configuration that mailbase intends. The location of symlinks will be different. Permissions will be different. Bugs referenced in this very thread indicate that this has caused problems with mail clients in the past. It is not very difficult to see how a disruption of permissions and/or files can result in the disruption of an e-mail system which transacts thousands of messages per day via postfix and courier-imap. I can either move the files, let mailbase do what it wants, and let my mail system get screwed up because I've pissed off courier-imap, postfix, maildrop, and God knows what else, or I can copy the files back afterward, and get my mail system screwed up because I've pissed off mailbase. These options are not acceptable. We need to understand exactly why these file collisions are taking place so that we can resolve them intelligently for our systems.

Why does mailbase want to overwrite these files? If someone has built a mail system that does something slightly more complicated than the occaisonal script-generated sendmail command, what is the best way to make sure critically important system functions such as imap pam authentication (!) still work after all these file moving gymnastics?

The WHY is the critical question here, and that question has been addressed by exactly no one so far.

[Carlo]

The WHY is the critical question here, and that question has been addressed by exactly no one so far.

Bug 79240

[mciann]

Okay, in summary (and because I hate googling threads that end in RTFM), the problem is that the intended final configuration is that mailbase should provide the /etc/pam.d files, and that courier-imap should depend upon mailbase to do so. The courier-imap package, as of this time, inappropriately provides the same files and should be changed so that it uses the files provided by mailbase. Therefore, users of courier-imap should await a new release of courier-imap which fixes this problem. Until then, updates should be emerged indvidually. Mailbase should NOT be emerged until a compliant version of courier-imap becomes available.

Thanks.

[riksta]

Okay, in summary (and because I hate googling threads that end in RTFM), the problem is that the intended final configuration is that mailbase should provide the /etc/pam.d files, and that courier-imap should depend upon mailbase to do so. The courier-imap package, as of this time, inappropriately provides the same files and should be changed so that it uses the files provided by mailbase. Therefore, users of courier-imap should await a new release of courier-imap which fixes this problem. Until then, updates should be emerged indvidually. Mailbase should NOT be emerged until a compliant version of courier-imap becomes available.

Rubbish! just do as portage asks, and move the files out, then replace them, making sure the 1st line is as stated, I followed this procedure, and it works perfectly

[mciann]

Wow, OK, so TFM wasn't quite enough to sort this out. Thanks for pitching in, riksta.

[riksta]

Thanks for pitching in, riksta.

Pleasure, hope you are sorted out?

[autarkeia]

If you search for other posts by j-m you'll see he has a you-are-an-idiot-for-not-undertsanding-what-I-understand tone in nearly all of his posts, and when people call him on it he continues to act like they are stupid and that their questions have immediately obvious answers, basically belittling them for asking a question in the first place. I really don't understand why someone needs to be a jerk when attempting to help other people (and I do mean attempting, because most of his posts are insults rather than help). Maybe I will make it a pet project to find posts by j-m and belittle all of his questions.

"j-m can't you read/write English? Why are you even asking this question? Why are you even using Linux? You should be using Microsoft products and then calling their tech supportand dealing with spyware and viruses and leave this code stuff to the real nerds. Why don't you read the ebuild files? Screw ebu ilds, why don't you drill down and read the source code? Who cares if Portage isn't working how it's supposed to, you should figure it out and not ask any questions, and if you do I will belittle you even more! Okay, you're just an idiot, let's face it. In fact, life is looking pretty bleak for you, why don't you just end it?"

j-m take a clue from people and inject some measured maturity into your responses. Some people just do not have your knowledge, and likewise you do not have theirs. Share yours without being pedantic and everyone will be better off for it.

[Carlo]

If you search for other posts by j-m you'll see he has a you-are-an-idiot-for-not-undertsanding-what-I-understand tone in nearly all of his posts

Could you please just ignore him, if you think so? Picking on each other doesn't resolve problems and your tone isn't the one I'm used to read here either.

[Earthwings]

Calm down everyone, please.

[mciann]

Rubbish! just do as portage asks, and move the files out, then replace them, making sure the 1st line is as stated, I followed this procedure, and it works perfectly

Hi, there, just a little follow up. I just recently got around to emerging the new packages following the procedure you described, and now none of my users can get their e-mail.

Thanks.