| View previous topic :: View next topic |
| Author |
Message |
miroR
l33t
Joined: 05 Mar 2008
Posts: 826
|
 Posted: Tue Dec 02, 2014 4:52 pm Post subject: |
 |
|
| py-ro wrote: | You follow instructions for layman, but you are not using layman, sure this is confusing.
Your "correction" is wrong.
You ebuilds are found because you set the veriable accordingly, but it will run everyone in trouble who actualy uses layman.
Bye
Py |
All right, reverting the "correction". (Also after khayyam's further explanation above.) In a minute.
...No need. Has been done already.
Sorry for the wrong "correction". |
|
| Back to top |
|
 |
miroR
l33t
Joined: 05 Mar 2008
Posts: 826
|
| Posted: Tue Dec 02, 2014 5:31 pm Post subject: |
|
|
| steveL wrote: | | miroR wrote: | | I'm not sure my correction, or "correction", is worse than what was before. |
Yes it is.
Fix your own mistake. |
Once I figured out, I wanted to. After other work that prevented me to be back sooner; this was the first thing that I wanted to do. But it was already corrected.
But, I do think some distinction should be pointed out to the effect of the apparent confusion that others, who may not be as advanced as steveL, py-ro or khayyam, might have, either in the:
Gentoo Overlays: Users' Guide
http://www.gentoo.org/proj/en/overlays/userguide.xml
or in the:
Overlay/Local overlay
https://wiki.gentoo.org/wiki/Overlay/Local_overlay
or, best, in both regarding what is layman managed and where then to put the local ones non-layman managed overlays (both the types go by the name "overlay", hence if the distinction is not put forth clearly, there is room for confusion). I'm sure my point is clear.
I see it only now, the distinction btwn layman managed overlay and the local non-layman managed overlay, with some digree of clarity (not even complete clarity still).
| steveL wrote: | | I can't believe you've been a member here since 2008. |
And I can't believe how you can't believe it. Did I tell you once or at least a few times, personally to you that I was slow to get things sometimes.
And very often I referred to my slowliness in almost every topic that I work on...
However, what I reach at, the understanding that I can relate, is still often pretty much read, and you can not tell me that the solutions that I arrive at are uninteresting... Because I work pretty thoroughly, even though through simplicity...
And if anyone cared to tell, I'd need it for the Air-Gapped topic, which, although very imperfect, is read quite a lot (for a slow worker like me; I'm very sure Linus would call me "stupid"), if they had any idea how layman's overlays could get downloaded and copied/moved securely into air-gapped machine, I'll be greatful.
Anyway, thanks to all of you who made this now much more clearer to me.
Thanks! |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Tue Dec 02, 2014 5:57 pm Post subject: |
|
|
| steveL wrote: | | I can't believe you've been a member here since 2008. |
| miroR wrote: | And I can't believe how you can't believe it. Did I tell you once or at least a few times, personally to you that I was slow to get things sometimes.
And very often I referred to my slowliness in almost every topic that I work on... |
It's got nothing to do with "slowness" and everything to do with attitude and approach.
I was referring in that comment, to "I won't revert it. You do, if you insist." at a point where you "don't know what to do." Perhaps I should have included that, my bad.
And I couldn't believe it as I was under the impression you'd arrived here recently from debian; when I checked the dates I couldn't believe you've been here for four years more than khayyam, and are still under the delusion that when you break things, you somehow don't have to pick up the pieces, and cleanup your own mess.
I simply couldn't believe any Gentoo user is under that sort of impression, as that's what maintaining a Gentoo box is all about, let alone collaboration and pushing stuff to other users. |
|
| Back to top |
|
|
miroR
l33t
Joined: 05 Mar 2008
Posts: 826
|
| Posted: Tue Dec 02, 2014 6:54 pm Post subject: |
|
|
| steveL wrote: | ...[snip]...
under the delusion that when you break things, you somehow don't have to pick up the pieces, and cleanup your own mess.
...[snip]...
|
You first need to understand that you are wrong, to cleanup the mess you did. khayyam understood, but didn't explain properly in the first quick "you're wrong" notice.
I brought other points that should catch contributors' to this topic attention, though.
Why not add that distinction (pls. see my immediately previous post)?
---
On another direction present in this topic.
Fabian Groffen in his last comment:
https://bugs.gentoo.org/show_bug.cgi?id=527338#c10
suggests, as it appears to me, something to the effect that gnupg-1 is valueless because it can't handle (not without some aid, since those are not easily typed in, so agent, ncurses etc. "needed") passwords like:
| Code: |
B:>\j*]-/z/mdd4EyGfXe{VP^nhjHRi78(n<W8D6wAN5_p<-Y"
|
BTW, I remeber having read that topic previously, and there, IIRC (of course IIRC, _if_), there weren't any names like nlsa8z6zoz7lyih3ap... changing names like that is ugly/sad to see (IIRC). But that is not what I want to delve on. Noticed it only.
khayyam, are you still on the positions that you broght up in that topic? Positions that I admire and agree with, and because of which you brought back gnupg-1 into Gentoo (which I thanked you for).
I can't reply to Fabian easily, this is now also a moral issue. He just don't want to cater for gnupg-1... He just don't want to look up what is ruined and how of the upstream Mutt with his heavily modified Mutt, for which the upstream Mutt manual does not apply completely, and no replacement is there for it, nor can easily be provided... Along with other things, already described in some depth in this topic. |
|
| Back to top |
|
|
miroR
l33t
Joined: 05 Mar 2008
Posts: 826
|
| Posted: Tue Dec 02, 2014 8:16 pm Post subject: |
|
|
On the last note of Fabian's will-not-do-it, I'm trying to, since the layman and non-layman distinciton above is not solved), and now my ebuld work above is somewhat misleading (in the /var/lib/layman part that I suggested), I went to further study the man pages.
In man layman I found a link to:
https://www.gentoo.org/proj/en/overlays/repositories.xml
which when I try to access it from Firefox redirects to:
https://api.gentoo.org/overlays/repositories.xml
I.e. if I try to open that page in Firefox, I only see
| Quote: |
This XML file does not appear to have any style information associated with it. The document tree is shown below.
---
<repositories version="1.0"><!--
SYN
* TEMPLATE TO COPY'N'PASTE UNOFFICIAL REPOSITORIES
<repo quality="experimental" status="unofficial">
<name>XXXXXX</name>
<description lang="en">XXXXXX</description>
<homepage>XXXXXX</homepage>
<owner type="person">
...[snip]...
|
Is that supposed to be so? |
|
| Back to top |
|
|
miroR
l33t
Joined: 05 Mar 2008
Posts: 826
|
| Posted: Tue Dec 02, 2014 11:27 pm Post subject: |
|
|
[quote="miroR"]On the last note of Fabian's will-not-do-it, I'm trying to, since the layman and non-layman distinciton above is not solved), and now my ebuld work above is somewhat misleading (in the /var/lib/layman part that I suggested), I went to further study the man pages.
In man layman I found a link to:
https://www.gentoo.org/proj/en/overlays/repositories.xml
which when I try to access it from Firefox redirects to:
https://api.gentoo.org/overlays/repositories.xml
I.e. if I try to open that page in Firefox, I only see
| Quote: |
This XML file does not appear to have any style information associated with it. The document tree is shown below.
---
<repositories version="1.0"><!--
SYN
* TEMPLATE TO COPY'N'PASTE UNOFFICIAL REPOSITORIES
<repo quality="experimental" status="unofficial">
<name>XXXXXX</name>
<description lang="en">XXXXXX</description>
<homepage>XXXXXX</homepage>
<owner type="person">
...[snip]...
|
Is that supposed to be so?
Also, I can connect anywhere, but can't open:
https://overlays.gentoo.org/
Not in Firefox, not in lynx (tried http://... in lynx too). And that one certainly is fro web browsing (unless I'm certain erroneously again).
What could this be.
I have the network captures, can try and look at them.. Will be back |
|
| Back to top |
|
|
py-ro
Veteran
Joined: 24 Sep 2002
Posts: 1734
Location: Velbert
|
| Posted: Wed Dec 03, 2014 12:38 am Post subject: |
|
|
| Yes, you are wrong, it is not meant for browsing. This is the Databases Layman uses to offer Overlays. |
|
| Back to top |
|
|
miroR
l33t
Joined: 05 Mar 2008
Posts: 826
|
| Posted: Wed Dec 03, 2014 1:24 am Post subject: |
|
|
| py-ro wrote: | | Yes, you are wrong, it is not meant for browsing. This is the Databases Layman uses to offer Overlays. |
And accessing that (other one I reported about) page from some http client (Firefox and Lynx tested in these, what, two hours), gives no replies whatsoever?
And the 148.251.78.52 shows (to me) at times as host overlays.gentoo.org and at other times as oystercatcher.gentoo.org
But wait, never mind what it shows in Wireshark loaded pcap file (taken from command line with dumpcap) --at at least one time it didn't even show-- it brings to me in none of the two http clients mentioned no content in all these two or so hours.
That normal?
And if normal, that behavior, why does it show in search engine where 99+- per cent of people only use http agents to read pages?
Really, what could this be?
To prevent "your-system-b0rked" remarks. No problems with no other pages whatsoever. I can access anywhere else with Firefox. |
|
| Back to top |
|
|
miroR
l33t
Joined: 05 Mar 2008
Posts: 826
|
| Posted: Wed Dec 03, 2014 2:58 am Post subject: |
|
|
This issue of overlays.gentoo.org not showing any content is a separate issue.
I opened a separate topic about it:
No content in overlays.gentoo.org
https://forums.gentoo.org/viewtopic-t-1005576.html
---
EDIT: Wed 3 Dec 22:39:54 CET 2014
Regarding the issue below, I kindly suggest if they need to reply to my reply, to do it there:
Uninstalling dbus and *kits (to Unfacilitate Remote Seats)
https://forums.gentoo.org/viewtopic-p-7661780.html#7661780
since it's the same issue as already presemt there, and this topic should be free from that issue from now on, as also suggested by steveL below.
khayyam, thanks for the reply on gnipg-1
EDIT END
Last edited by miroR on Wed Dec 03, 2014 9:43 pm; edited 3 times in total |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Wed Dec 03, 2014 11:08 am Post subject: |
|
|
| miroR wrote: | | I brought other points that should catch contributors' to this topic attention, though. Why not add that distinction (pls. see my immediately previous post)? |
miro ... because, as has been stated on many occassions in the past, often its difficult to make any sense of your posts ... too much noise too little signal (ie, in the above you illustate how you edited/diff'ed the wiki page ... which is just noise and makes following the thread difficult). So, you can forgive steve *only* pointing to your obvious error ... and not praising you for illucidating some problem (which, for my part, I don't see ... as I simply skip over your posts given the level of noise).
| miroR wrote: | | khayyam, are you still on the positions that you broght up in that topic? Positions that I admire and agree with, and because of which you brought back gnupg-1 into Gentoo (which I thanked you for). |
You mean regarding gnupg-1? Yes. I'm not sure Fabian is saying that gnupg-1 is "useless" but that pinentry isn't a problem, which of course I disagree with.
best ... khay |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Wed Dec 03, 2014 2:48 pm Post subject: |
|
|
| steveL wrote: | | under the delusion that when you break things, you somehow don't have to pick up the pieces, and cleanup your own mess. |
There's really no need for "...[snip]..." lines before and after a quote. It's obvious that you've snipped it out, and only wastes space.
| miroR wrote: | | You first need to understand that you are wrong, to cleanup the mess you did. khayyam understood, but didn't explain properly in the first quick "you're wrong" notice. |
If you've been told you are wrong, and you "don't know" what you're doing, then no, you don't have to understand it all, in order to revert your broken edit. You just have to accept that you may be wrong, and revert it ASAP.
Thereafter you can explore your broken understanding, or perhaps show someone else how your newfangled edit is in fact correct.
The latter is rather unlikely when you're dealing with khayyam.
"I won't revert it. You do, if you insist." is exactly the wrong approach. And I will pick you up on it again if I see it happen again, same as I would with anyone on here.
Please don't go into this any further. There is no possible use in it. |
|
| Back to top |
|
|
miroR
l33t
Joined: 05 Mar 2008
Posts: 826
|
|
| Back to top |
|
|
miroR
l33t
Joined: 05 Mar 2008
Posts: 826
|
| Posted: Thu Jul 16, 2015 3:45 pm Post subject: |
|
|
This is the method that I decided I needed to apply when I can't write my own ebuild to do what I wish from a package in portage (as, in this case, it is about the common, upstream time-honored functionalities).
I'll be testing this again, as I just failed to "-r bump" (as people call it, find it in previous posts, by steveL and Navar) and modify my ebuild in such way as to get the functionalities I sorely miss.
(
There's nothing much else in that ebuild, but lots of commenting out --and some uncommenting--, along with stating the reasons for it, and asking myself, or you, what to do for this or that. Download it and see for yourself:
http://www.croatiafidelis.hr/foss/cap/cap-150714_gen_mutt/mutt-1.5.23-r22.ebuild
Again: mutt installed with that ebuild behaves like the video tells you.
)
Create a directory in /var/log:
| Code: |
# mkdir -p /var/log/no-portage
|
I think it's good to create another one, where to put previous deleted installs logs. In rare circumstances where I try installing of a program from my local overlay, then with "emerge -C" uninstall it to try the out-of-portage install of the same program, and again, uninstall that one to try the local portage overlay method once more, having the logs ( which must not anymore be in the no-portage currently installed listing and logs ), [having the logs for such there-and-back cases] still available in:
| Code: |
# mkdir -p /var/log/no-portage-DEL
|
is helpful for comparison, for double checking things and other.
I currently have these in:
| Code: |
# ls -l /var/log/no-portage-DEL/
total 88
-rw-r--r-- 1 ukrainian ukrainian 13014 2015-07-14 22:45 mutt-1.5.23-dev_150714_224500_prepare.log
-rw-r--r-- 1 root root 47652 2015-07-14 22:51 mutt-1.5.23-dev_150714_225027_make.log
-rw-r--r-- 1 root root 9159 2015-07-14 22:53 mutt-1.5.23-dev_150714_225325_make_install.log
-rw-r--r-- 1 ukrainian ukrainian 246 2015-07-15 21:24 mutt-1.5.23-dev_150714_installed.CMD
-rw-r--r-- 1 root root 4240 2015-07-14 23:06 mutt-1.5.23-dev_150714_installed.ls-1
g0n ~ #
|
As I said, I just retried the installation with mutt-1.5.23-r22.ebuild (there was also a mutt-1.5.23-r21.ebuild, but they differ in the clarity of my comments only, the 21 being less clear, so I'm not posting it anywhere).
So, sorely missing the normal browsing of emails in Mutt, and the availability of the manual in the Mutt's own window,
And I'll (soon) be venturing on reinstalling Mutt the no-portage way, and checking my method of keeping the changes in the system well documented, so nothing would harm the system (which Portage takes really fine care for!).
But just one more thing before the install. The un-install.
I'll post the prepare.log (it is some preparation plus the running of configure, in case of live Mutt mercurial repo), the make.log, and the make_install.log, for you to see why the diffing the listings found by find at the right phases of the compile/installation process, is an acceptable solution, if not, for lack of a better method, the right solution. (And the listing in the /var/db/pkg/ as was in unbecoming way suggested in the first page of this quest certainly does not feature here in any way whatsoever, as these have been installed without Portage's knowledge, and Portage has no record of them whatsoever).
The listing that I made in the previous no-portage install:
cat mutt-1.5.23-dev_150714_installed.ls-1
| Code: |
/usr/share/man/man1/smime_keys.1
/usr/share/man/man1/pgpring.1
/usr/share/man/man1/flea.1
/usr/share/man/man1/pgpewrap.1
/usr/share/man/man1/muttbug.1
/usr/share/man/man1/mutt.1
/usr/share/man/man5/muttrc.5
/usr/share/man/man5/mbox.5
/usr/share/man/man5/mmdf.5
/usr/share/doc/mutt
/usr/share/doc/mutt/applying-patches.txt
/usr/share/doc/mutt/devel-notes.txt
/usr/share/doc/mutt/security.html
/usr/share/doc/mutt/INSTALL
/usr/share/doc/mutt/README.SSL
/usr/share/doc/mutt/COPYRIGHT
/usr/share/doc/mutt/samples
/usr/share/doc/mutt/samples/Mush.rc
/usr/share/doc/mutt/samples/pgp2.rc
/usr/share/doc/mutt/samples/mutt_xtitle
/usr/share/doc/mutt/samples/sample.mailcap
/usr/share/doc/mutt/samples/smime_keys_test.pl
/usr/share/doc/mutt/samples/iconv
/usr/share/doc/mutt/samples/iconv/iconv.solaris-2.6.rc
/usr/share/doc/mutt/samples/iconv/iconv.solaris-2.6-cjk.rc
/usr/share/doc/mutt/samples/iconv/iconv.aix-4.1.5.rc
/usr/share/doc/mutt/samples/iconv/iconv.irix-6.5.rc
/usr/share/doc/mutt/samples/iconv/iconv.hpux-10.20.rc
/usr/share/doc/mutt/samples/iconv/iconv.hpux-10.01.rc
/usr/share/doc/mutt/samples/iconv/iconv.osf1-4.0d.rc
/usr/share/doc/mutt/samples/iconv/iconv.aix-3.2.5.rc
/usr/share/doc/mutt/samples/iconv/iconv.osf1-4.0a.rc
/usr/share/doc/mutt/samples/iconv/iconv.solaris-2.4.rc
/usr/share/doc/mutt/samples/iconv/iconv.solaris-2.5.1.rc
/usr/share/doc/mutt/samples/iconv/iconv.glibc-2.1.3.rc
/usr/share/doc/mutt/samples/iconv/iconv.aix-4.3.2.rc
/usr/share/doc/mutt/samples/iconv/iconv.glibc-2.1.90.rc
/usr/share/doc/mutt/samples/iconv/iconv.freebsd-3.3.rc
/usr/share/doc/mutt/samples/iconv/iconv.solaris-2.7.rc
/usr/share/doc/mutt/samples/iconv/iconv.hpux-11.00.rc
/usr/share/doc/mutt/samples/iconv/iconv.aix-4.2.0.rc
/usr/share/doc/mutt/samples/gpg.rc
/usr/share/doc/mutt/samples/colors.linux
/usr/share/doc/mutt/samples/sample.muttrc
/usr/share/doc/mutt/samples/ca-bundle.crt
/usr/share/doc/mutt/samples/pgp6.rc
/usr/share/doc/mutt/samples/smime.rc
/usr/share/doc/mutt/samples/sample.muttrc-tlr
/usr/share/doc/mutt/samples/colors.default
/usr/share/doc/mutt/samples/pgp5.rc
/usr/share/doc/mutt/samples/Tin.rc
/usr/share/doc/mutt/samples/Pine.rc
/usr/share/doc/mutt/PGP-Notes.txt
/usr/share/doc/mutt/ChangeLog
/usr/share/doc/mutt/smime-notes.txt
/usr/share/doc/mutt/tuning.html
/usr/share/doc/mutt/advancedusage.html
/usr/share/doc/mutt/reference.html
/usr/share/doc/mutt/configuration.html
/usr/share/doc/mutt/mimesupport.html
/usr/share/doc/mutt/manual.html
/usr/share/doc/mutt/miscellany.html
/usr/share/doc/mutt/README
/usr/share/doc/mutt/README.SECURITY
/usr/share/doc/mutt/GPL
/usr/share/doc/mutt/gettingstarted.html
/usr/share/doc/mutt/optionalfeatures.html
/usr/share/doc/mutt/TODO
/usr/share/doc/mutt/NEWS
/usr/share/doc/mutt/intro.html
/usr/share/doc/mutt/index.html
/usr/share/doc/mutt/patch-notes.txt
/usr/share/doc/mutt/manual.txt
/usr/share/locale/id/LC_MESSAGES/mutt.mo
/usr/share/locale/de/LC_MESSAGES/mutt.mo
/usr/share/locale/bg/LC_MESSAGES/mutt.mo
/usr/share/locale/it/LC_MESSAGES/mutt.mo
/usr/share/locale/lt/LC_MESSAGES/mutt.mo
/usr/share/locale/eu/LC_MESSAGES/mutt.mo
/usr/share/locale/cs/LC_MESSAGES/mutt.mo
/usr/share/locale/zh_TW/LC_MESSAGES/mutt.mo
/usr/share/locale/pl/LC_MESSAGES/mutt.mo
/usr/share/locale/tr/LC_MESSAGES/mutt.mo
/usr/share/locale/fr/LC_MESSAGES/mutt.mo
/usr/share/locale/nl/LC_MESSAGES/mutt.mo
/usr/share/locale/ko/LC_MESSAGES/mutt.mo
/usr/share/locale/ga/LC_MESSAGES/mutt.mo
/usr/share/locale/et/LC_MESSAGES/mutt.mo
/usr/share/locale/ca/LC_MESSAGES/mutt.mo
/usr/share/locale/zh_CN/LC_MESSAGES/mutt.mo
/usr/share/locale/gl/LC_MESSAGES/mutt.mo
/usr/share/locale/uk/LC_MESSAGES/mutt.mo
/usr/share/locale/ru/LC_MESSAGES/mutt.mo
/usr/share/locale/sv/LC_MESSAGES/mutt.mo
/usr/share/locale/hu/LC_MESSAGES/mutt.mo
/usr/share/locale/sk/LC_MESSAGES/mutt.mo
/usr/share/locale/pt_BR/LC_MESSAGES/mutt.mo
/usr/share/locale/el/LC_MESSAGES/mutt.mo
/usr/share/locale/ja/LC_MESSAGES/mutt.mo
/usr/share/locale/es/LC_MESSAGES/mutt.mo
/usr/share/locale/da/LC_MESSAGES/mutt.mo
/usr/share/locale/eo/LC_MESSAGES/mutt.mo
/usr/bin/mutt
/usr/bin/pgpring
/usr/bin/flea
/usr/bin/smime_keys
/usr/bin/muttbug
/usr/bin/pgpewrap
/usr/etc
/usr/etc/mime.types.dist
/usr/etc/mime.types
/usr/etc/Muttrc.dist
/usr/etc/Muttrc
|
Go and check, but the logs from the regular out-of-portage installation, while they do tell you all, don't just give you a simple listing of what they install, find the prepare.log, the make.log, and the make_install.log:
http://www.croatiafidelis.hr/foss/cap/cap-150714_gen_mutt/no-portage/
And now, having had such listing (this last preparation for posting is almost a day after its start), I was able to see those files:
| Code: |
for i in $(cat /var/log/no-portage/mutt-1.5.23-dev_150714_installed.ls-1) ; do
ls -l $i
done
|
and remove them:
| Code: |
for i in $(cat /var/log/no-portage/mutt-1.5.23-dev_150714_installed.ls-1) ; do
rm -v $i
done
|
(Actually I ran equery b $i on each of the files, and none belonged to any package in portage, but I thought I wouldn't bother you with my triple checking of things.)
And then I installed the portage way, with my ebuild:
# emerge mutt
| Code: |
These are the packages that would be merged, in order:
Calculating dependencies ... done!
[ebuild N ] mail-client/mutt-1.5.23-r22::ukrainian USE="berkdb crypt doc gdbm gpg imap mbox nls pop sasl smime smtp ssl -debug -gnutls -idn -kerberos -nntp -qdbm -slang -tokyocabinet" 0 KiB
Total: 1 package (1 new), Size of downloads: 0 KiB
Would you like to merge these packages? [Yes/No]
>>> Verifying ebuild manifests
>>> Emerging (1 of 1) mail-client/mutt-1.5.23-r22::ukrainian
* mutt-1.5.23.tar.gz SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ]
>>> Unpacking source...
>>> Unpacking mutt-1.5.23.tar.gz to /var/tmp/portage/mail-client/mutt-1.5.23-r22/work
...
|
And that install is surely wrecking my life, after having all this time always been seeing the unweeded headers before the content of the mail, the behavior being completely unchangeable from a user's point of view, and which unweeded headers are not the default in upstream Mutt. And I miss the manual right there in the same window, to have it all at just a few keypresses...
---
NOTE: Almost a day after the first draft of this post was prepared, but not posted yet: News: it started failing all of a sudden, the weeding of headers also on my out-of-portage Mutt install. That took me this nearly entire day to fix it. But the explanation (which is coming) is not too trivial. Just: while the not calling user's editor to display the manual in Mutt's own window is the (wrong) choice by Gentoo Mutt ebuild developers, IMO, seeing a little, just a little more clearly in all of this matter, I now admit I just don't know (and I thought it was, wasn't that the logical conclusion?, see the video again) if the toggle header weeding issue is or not due to the Gentoo ebuild straying from the upstream logic and predominantly universally accepted functionalities. Still researching.
---
So:
| Code: |
# emerge -C mut
* This action can remove important packages! In order to be safer, use
* `emerge -pv --depclean <atom>` to check for reverse dependencies before
* removing packages.
>>> These are the packages that would be unmerged:
mail-client/mutt
selected: 1.5.23-r22
protected: none
omitted: none
All selected packages: =mail-client/mutt-1.5.23-r22
>>> 'Selected' packages are slated for removal.
>>> 'Protected' and 'omitted' packages will not be removed.
Would you like to unmerge these packages? [Yes/No]
>>> Waiting 5 seconds before starting...
>>> (Control-C to abort)...
>>> Unmerging in: 5 4 3 2 1
>>> Unmerging (1 of 1) mail-client/mutt-1.5.23-r22...
No package files given... Grabbing a set.
<<< obj /usr/share/man/man5/muttrc.5.bz2
<<< obj /usr/share/man/man5/mmdf.5.bz2
<<< obj /usr/share/man/man5/mbox.5.bz2
<<< obj /usr/share/man/man1/smime_keys.1.bz2
...
|
And here I, almost a day ago, essentially embarked on the procedure that I keep in my cheat sheet in: /var/log/no-portage-keep/ directory created for such purpose:
# cat /mnt/sr0/no-portage-keep/mutt-1.5.23-dev_150716.HISTORY
| Code: |
$ cd ~/hg/mutt
$ ./prepare --prefix=/usr --enable-pop --enable-imap --with-ssl |& tee ../mutt-1.5.23-dev_$(date +%y%m%d_%H%M%S)_prepare.log
$ make |& tee ../mutt-1.5.23-dev_$(date +%y%m%d_%H%M%S)_make.log
as root:
# cd ~ukrainian/hg/mutt
# find / -xdev -name '*' > /root/FIND_mutt-1.5.23-dev_$(date +%y%m%d_%H%M)_make_AFTER.txt
# make install |& tee ../mutt-1.5.23-dev_$(date +%y%m%d_%H%M%S)_make_install.log
# find / -xdev -name '*' > /root/FIND_mutt-1.5.23-dev_$(date +%y%m%d_%H%M)_make_install_AFTER.txt
# diff FIND_mutt-1.5.23-dev_150716_093*.txt | grep '> ' | sed 's/> //' | egrep -v '\/proc\/|\/root\/|\/home\/ukrainian\/hg\/' > /var/log/no-portage/mutt-1.5.23-dev_150716_093219_make_install.ls-1
|
In that cheat sheet I also keep the removal procedure:
| Code: |
# for i in $(cat /var/log/no-portage/mutt-1.5.23-dev_150716_103148_make_install.ls-1) ; do if [ -f "$i" ] ; then rm -v $i ; fi ; done ;
# for i in $(cat /var/log/no-portage/mutt-1.5.23-dev_150716_103148_make_install.ls-1) ; do if [ -d "$i" ] ; then rmdir -v $i ; fi ; done ;
|
(About the last line, the removal of dirs, I just repeat till all is deleted. It's just up-arrow to recall history and Enter, two or three times.)
I'm pretty sure this procedure works exactly as needed, and does not get in the way of Portage, which is important.
That is what I did quite a few times (maybe a dozen times altogether). There were a few things to learn and to set correctly in my /etc/grsec/policy for Mutt compilation and runtime. Now it works. The out-of-portage Mutt, as most users would probably want it, the upstream way.
More on the issues that gave me hard time for almost a day, later. |
|
| Back to top |
|
|
miroR
l33t
Joined: 05 Mar 2008
Posts: 826
|
|
| Back to top |
|
|
miroR
l33t
Joined: 05 Mar 2008
Posts: 826
|
|
| Back to top |
|
|
miroR
l33t
Joined: 05 Mar 2008
Posts: 826
|
| Posted: Fri Jul 17, 2015 10:36 am Post subject: |
|
|
This is the text, that I just entered in Bugzilla, but which showed really poorly, no text-wrapping, on:
toggle header weeding in Mutt doesn't work
https://bugs.gentoo.org/show_bug.cgi?id=555180
======================
++++++++++++++++++++++
======================
I revisited the issue of Gentoo Mutt install.
(Mutt, with the gpg use flag works currently on my machine without gpgme,
without having to install the gpgme, which was my previous bug (527338).)
While I can not influence the
manual not being displayed in official portage Mutt's own window as is the
case for upstream, I believe the unweedable headers, which show in my Mutt,
such as when opening new emails, surely should be looked into:
In mutt, after opening any e-mail, regardless that it is in the help described as:
h display-toggle-weed display message and toggle header weeding
has, in Gentoo Mutt, the sole effect of slightly wrapping the headers, on and
off, and not weeding them. Surely it is a drag, when you always only see
headers if you just move from one mail to the others with up-arrow or down
arrow, on, say, non-huge monitors with the sole viewport solely for Mutt.
On an outside-of-portage installed Mutt, the behavior of pressing h while any
email is displayed, is of truely toggling the headers on and off, and the
default is, surely, off, just, say, the Date:, From:, To:, Subject:
User-Agent:, and no other headers displayed.
I have posted extensively, firstly, when I knew less, this video for the purpose:
http://www.croatiafidelis.hr/foss/cap/cap-150714_gen_mutt/Screen_150714_Mutt_in_Gentoo.webm
and the post on the ole topic:
Mutt without Portage/in Local Overlay
https://forums.gentoo.org/viewtopic-t-1002146-start-50.html#7779222
and then, as I researched more, about my grsec-hardened role base access policy issues:
My Hard Earned RBAC policy for Mutt
http://forums.grsecurity.net/viewtopic.php?f=5&t=4235
where in particular, see this post, regarding from-portage Mutt:
( same title as above )
http://forums.grsecurity.net/viewtopic.php?f=5&t=4235&p=15393#p15393
and surely, see the logs, screencast, traffic dump and all in the respective
subdirectory of:
http://www.croatiafidelis.hr/foss/cap/cap-150714_gen_mutt/
In which regard I will be available for a few days for any questions, or quick test, that developers might ask or need, on the Gentoo Portage installed Mutt, so we can see all more clearly in this issue, and if it is a bug, as it looks to me (but I am not an expert), fix it.
But later I will, for now, move to installing Mutt out-of-portage, because my
resources of time are compelling, and I really can't learn Mutt properly
without having the manual available in Mutt's own window, not allowing of
which is, according to my understanding, Gentoo devs' (wrong) choice. Do
correct me if my understanding is not right.
Namely I tried to get that manual in Mutt, and header weeding, in my own
ebuild, available, the ebuild is in the same dir as above (
http://www.croatiafidelis.hr/foss/cap/cap-150714_gen_mutt/mutt-1.5.23-r22.ebuild
), but without success.
Kind regards,
Miroslav Rovis, Gentoo user miroR |
|
| Back to top |
|
|
miroR
l33t
Joined: 05 Mar 2008
Posts: 826
|
| Posted: Fri Jul 17, 2015 10:40 am Post subject: |
|
|
It could be a Dillo issue, and I'll ask Dillo devs on their mailing lists, or it could be the issue with the Bugzilla not wrapping the text. I don't know.
What I do know is, that I pasted that exact sane text after I additionally corrected it in the Bugzilla page opened in my Dillo, and then saving it back into my system, by simply cat'ing it into a file...
What I do know is, that I cat'ed and selected that on Bugzilla page edited file, into the post just above, and, lo and behold, there is nothing wrong with the wrapping... (and I used Dillo for posting it in Bugzilla and above, that same text). |
|
| Back to top |
|
|
miroR
l33t
Joined: 05 Mar 2008
Posts: 826
|
| Posted: Sat Jul 18, 2015 11:12 am Post subject: |
|
|
That was (and apparently still is) a Dillo issue...
[Apparently still is.] However, I'm not expert to have the insight into all the possible influencing factors. See the post that I did with 3.0.5 Dillo:
toggle header weeding in Mutt doesn't work
https://bugs.gentoo.org/show_bug.cgi?id=555180#c8
This is the text, read it here more comfortably:
Well, how come, then, that that same .muttrc works, verbatim, unchanged, unmodified, just that exact configuration file, when I only install the upstream mutt, say the LFS way, not the Gentoo portage way?
RESOLVED INVALID. But, I bet we will see it applied!
Just as now a non-gpgme system like mine can install mutt which previously was not the case. See the Forums page linked in the bug 527338 (add support for app-crypt/gnupg as alternative to app-crypt/gpgme). That one was RESOLVED INVALID, but the support is now there.
Thanks! |
|
| Back to top |
|
|
miroR
l33t
Joined: 05 Mar 2008
Posts: 826
|
| Posted: Sun Jul 19, 2015 1:42 pm Post subject: |
|
|
Sorry about the digression. I hoope it no won't be anymore of it here, as from this other related loss of data at posting,
A Tentative at dillo-3.1-dev ebuild
https://forums.gentoo.org/viewtopic-t-1021878.html#7783338
that digression moves away from this topic.
Thanks! |
|
| Back to top |
|
|
miroR
l33t
Joined: 05 Mar 2008
Posts: 826
|
| Posted: Fri Aug 14, 2015 2:45 pm Post subject: |
|
|
After updating my system, and before getting it ready for cloning (I do all my work in the calm Air-Gap master Gentoo, and go online with a discardable clone only)...
[After updating my system] I tried (mutt is still installed out-of-portage, because I haven't figured to do it with the ebuild, nor has anybody taken time to do it for us the wishful of it --judging by the views of this topic there is a number of us--, nor have the devs decided to engage and offer it, it being what is mainstream in Mutt...)
So, my [mutt is still installed out-of-portage], and after updating my system, I tried:
| Code: |
$ mutt
mutt: error while loading shared libraries: libncursesw.so.5: cannot open
shared object file: No such file or directory
$
|
The error is simply because the package sys-libs/ncurses-6.0 has replaced the sys-libs/ncurses-5.9-r4 and Mutt was obviously built with run-time dependency on that now replaced version.
Apparently, I need to reistall Mutt. I'd really like to do it the ebuild way, and I learned to revision bump ebuilds in my local overlay, but I haven't yet figured (and have no time for that now) how to install the Mutt docs and things the right way with the ebuild. Plain uncommenting of the revision-bumped gentoo ebuild didn't do it...
And so I have to go the out-of-portage way.
It is now a month on from the last out-of-portage install. Let's see it my method is right...
First of all, let me repeat that I really would prefer to do it the portage way, but the task is beyond me, or maybe more to the point: beyond the time available to me currently. I'm left with no options.
My current no-portage{,-keep,-DEL}:
| Code: |
# ls -l /var/log/no-portage*
/var/log/no-portage:
total 212
-rw-r--r-- 1 ukrainian ukrainian 128305 2015-07-16 14:31 mutt-1.5.23-dev_150716_143050_config.log
-rw-r--r-- 1 ukrainian ukrainian 10986 2015-07-16 14:31 mutt-1.5.23-dev_150716_143050_prepare.log
-rw-r--r-- 1 ukrainian ukrainian 49215 2015-07-16 14:33 mutt-1.5.23-dev_150716_143233_make.log
-rw-r--r-- 1 root root 9173 2015-07-16 14:33 mutt-1.5.23-dev_150716_143339_make_install.log
-rw-r--r-- 1 root root 4240 2015-07-16 14:37 mutt-1.5.23-dev_150716_143339_make_install.ls-1
/var/log/no-portage-DEL:
total 1024
...
-rw-r--r-- 1 root root 128166 2015-07-16 14:03 mutt-1.5.23-dev_150716_135527_config.log
-rw-r--r-- 1 ukrainian ukrainian 12716 2015-07-16 13:55 mutt-1.5.23-dev_150716_135527_prepare.log
-rw-r--r-- 1 ukrainian ukrainian 55858 2015-07-16 13:57 mutt-1.5.23-dev_150716_135616_make.log
-rw-r--r-- 1 root root 9173 2015-07-16 13:58 mutt-1.5.23-dev_150716_135821_make_install.log
-rw-r--r-- 1 root root 4240 2015-07-16 14:00 mutt-1.5.23-dev_150716_135821_make_install.ls-1
-rw-r--r-- 1 root root 4240 2015-07-16 02:11 mutt-1.5.23-dev_150716_installed.ls-1
/var/log/no-portage-keep:
total 4
-rw-r--r-- 1 ukrainian ukrainian 1390 2015-07-16 11:27 mutt-1.5.23-dev_150716.HISTORY
gbn ~ #
|
My cheat-sheet that I left in the '-keep' (BTW the # are not comments, but signify the command is for root, while th $ signifies it is for ordinary user) is:
cat /var/log/no-portage-keep/mutt-1.5.23-dev_150716.HISTORY
| Code: |
$ cd ~/hg/mutt
$ ./prepare --prefix=/usr --enable-pop --enable-imap --with-ssl |& tee ../mutt-1.5.23-dev_$(date +%y%m%d_%H%M%S)_prepare.log
$ make |& tee ../mutt-1.5.23-dev_$(date +%y%m%d_%H%M%S)_make.log
as root:
# cd ~ukrainian/hg/mutt
# find / -xdev -name '*' > /root/FIND_mutt-1.5.23-dev_$(date +%y%m%d_%H%M)_make_AFTER.txt
# make install |& tee ../mutt-1.5.23-dev_$(date +%y%m%d_%H%M%S)_make_install.log
# find / -xdev -name '*' > /root/FIND_mutt-1.5.23-dev_$(date +%y%m%d_%H%M)_make_install_AFTER.txt
# diff FIND_mutt-1.5.23-dev_150716_093*.txt | grep '> ' | sed 's/> //' | egrep -v '\/proc\/|\/root\/|\/home\/ukrainian\/hg\/' > /var/log/no-portage/mutt-1.5.23-dev_150716_093219_make_install.ls-1
# for i in $(cat /var/log/no-portage/mutt-1.5.23-dev_150716_103148_make_install.ls-1) ; do if [ -f "$i" ] ; then rm -v $i ; fi ; done ;
# for i in $(cat /var/log/no-portage/mutt-1.5.23-dev_150716_103148_make_install.ls-1) ; do if [ -d "$i" ] ; then rmdir -v $i ; fi ; done ;
# for i in $(cat /var/log/no-portage/mutt-1.5.23-dev_150716_103148_make_install.ls-1) ; do if [ -d "$i" ] ; then rmdir -v $i ; fi ; done ;
# for i in $(cat /var/log/no-portage/mutt-1.5.23-dev_150716_103148_make_install.ls-1) ; do if [ -d "$i" ] ; then rmdir -v $i ; fi ; done ;
# for i in $(cat /var/log/no-portage/mutt-1.5.23-dev_150716_103148_make_install.ls-1) ; do if [ -e "$i" ] ; then ls -l $i ; fi ; done ;
|
But I don't need the first lines of that cheat-sheet yet. Those are for the installing. I first need the bottom for loop lines. Because I need to remove the currently installed Mutt first.
I changed the lines to list the installed files first:
| Code: |
for i in $(cat /var/log/no-portage/mutt-1.5.23-dev_150716_143339_make_install.ls-1) ; do if [ -f "$i" ] ; then ls -l $i ; fi ; done ;
|
The above lists all the files.
| Code: |
for i in $(cat /var/log/no-portage/mutt-1.5.23-dev_150716_143339_make_install.ls-1) ; do if [ -d "$i" ] ; then ls -ld $i ; fi ; done ;
|
And that listed the dirs.
And now...:
| Code: |
# for i in $(cat /var/log/no-portage/mutt-1.5.23-dev_150716_143339_make_install.ls-1) ; do if [ -f "$i" ] ; then rm -v $i ; fi ; done ; ^C
# for i in $(cat /var/log/no-portage/mutt-1.5.23-dev_150716_143339_make_install.ls-1) ; do if [ -d "$i" ] ; then rmdir -v $i ; fi ; done ;
|
...now these two removed the entire Mutt install.
Actually not:
| Code: |
# for i in $(cat /var/log/no-portage/mutt-1.5.23-dev_150716_143339_make_install.ls-1) ; do if [ -e "$i" ] ; then ls -l $i ; fi ; done ;
total 4
drwxr-xr-x 2 root root 4096 2015-08-14 11:05 samples
total 0
gbn ~ #
|
But I removed that one manually. Good enough.
At this point, I ran:
| Code: |
mv -vi /var/log/no-portage/mutt-1.5.23-dev_150716_143* /var/log/no-portage-DEL/
|
so /var/log/no-portage/ remained empty. No other out-of-portage installs here. This is the sole out-of-portage compilation that I am, still, bound to manually install. I can manage my dillo install with my local overlay, exampli gratia.
Now I went and got the new mercurial Mutt repo. Moved it, the air-gapped way (no wires, no wireless...), over into this calm off-line.
I got the old source moved to mutt-DEL. And I checked what's new in my non-advanced way:
| Code: |
$ ls -l hg/mutt/| egrep '[A-Z]{2,9}'
-rw-r--r-- 1 ukrainian ukrainian 18852 2015-08-14 10:17 ABOUT-NLS
-rw-r--r-- 1 ukrainian ukrainian 650 2015-08-14 10:17 BEWARE
-rw-r--r-- 1 ukrainian ukrainian 1605 2015-08-14 10:17 COPYRIGHT
-rw-r--r-- 1 ukrainian ukrainian 18013 2015-08-14 10:17 GPL
-rw-r--r-- 1 ukrainian ukrainian 10682 2015-08-14 10:17 INSTALL
-rw-r--r-- 1 ukrainian ukrainian 6366 2015-08-14 10:17 NEWS
-rw-r--r-- 1 ukrainian ukrainian 9360 2015-08-14 10:17 OPS
-rw-r--r-- 1 ukrainian ukrainian 189 2015-08-14 10:17 OPS.CRYPT
-rw-r--r-- 1 ukrainian ukrainian 374 2015-08-14 10:17 OPS.MIX
-rw-r--r-- 1 ukrainian ukrainian 244 2015-08-14 10:17 OPS.PGP
-rw-r--r-- 1 ukrainian ukrainian 44 2015-08-14 10:17 OPS.SMIME
-rw-r--r-- 1 ukrainian ukrainian 0 2015-08-14 10:17 PATCHES
-rw-r--r-- 1 ukrainian ukrainian 984 2015-08-14 10:17 README
-rw-r--r-- 1 ukrainian ukrainian 2471 2015-08-14 10:17 README.SECURITY
-rw-r--r-- 1 ukrainian ukrainian 4688 2015-08-14 10:17 README.SSL
-rw-r--r-- 1 ukrainian ukrainian 2354 2015-08-14 10:17 TODO
-rw-r--r-- 1 ukrainian ukrainian 9836 2015-08-14 10:17 UPDATING
-rw-r--r-- 1 ukrainian ukrainian 7 2015-08-14 10:17 VERSION
|
I checked the diffs btwn each in the nutt/ and in the mutt-DEL/ with a for loop. But no other of these uppecase files have changes, but only the UPDATING one:
| Code: |
diff hg/mutt/UPDATING hg/mutt-DEL/UPDATING
7,39d6
< 1.5.24 (unreleased):
<
< + terminal status-line (TS) support, a.k.a. xterm title. see the
< following variables: $ts_enabled, $ts_icon_format, $ts_status_format
< ! $ssl_use_sslv3 is disabled by default.
< ! command-line arguments: -H now combines template and command-line
< address arguments.
< ! GnuPG signature name is set to signature.asc
< + New color object "prompt" added.
< + Ability to encrypt postponed messages. See $postpone_encrypt and
< $postpone_encrypt_as.
< ! History ring now has a scratch buffer.
< ! mail-key is implemented for GPGME. (Requires a recent GPGME).
< ! Removed GPG_AGENT_INFO check for GnuPG 2.1 compatibility. Please
< set pgp_use_gpg_agent if using GnuPG 2.1 or later.
< ! $smime_encrypt_with now defaults to aes256.
< ! GnuPG fingerprints are used internally when possible.
< "--with-fingerprint" should be added to $pgp_list_pubring_command and
< $pgp_list_secring_command to enable this. Please see contrib/gpg.rc.
< Fingerprints may also be used at the prompts for key selection.
< + $crypt_opportunistic_encrypt automatically enables/disables encryption
< based on message recipients.
< ! Attachments for unencrypted emails may be deleted.
< ! Multiple crypt-hooks may be defined for the same regexp.
< This means multiple keys may be used for a recipient.
< + $crypt_confirmhook allows the confirmation prompt for crypt-hooks to
< be disabled.
< + $ssl_ciphers allows the SSL ciphers to be directly set.
< ! sime_keys better handles importing certificate chains.
< ! sime_keys now records certificate purposes (sign/encrypt). Run
< "sime_keys refresh" to update smime index files.
< + $maildir_check_cur to poll maildir "cur" directory for new mail.
<
44a12,13
> + terminal status-line (TS) support, a.k.a. xterm title. see the
> following variables: $ts_enabled, $ts_icon_format, $ts_status_format
diff hg/mutt/VERSION hg/mutt-DEL/VERSION
|
Ummmh! Very appetizing!
Importantly, though, the method of installing has not changed in the least (no diffs in the INSTALL). My cheat-sheet should work.
Going for it.
| Code: |
$ cd ~/hg/mutt
$ ./prepare --prefix=/usr --enable-pop --enable-imap --with-ssl |& tee ../mutt-1.5.24-dev_$(date +%y%m%d_%H%M%S)_prepare.log
bash: ./prepare: /bin/sh: bad interpreter: Permission denied
$
|
I like posting real events in my machines, so now I have to make a short digression here.
This is nothing really wrong here, it's just my grsec-enabled kernel does not allow other that trusted-path-execution. I'm digressing because I don't think anyone serious about computing in FOSS Linux can really get a decently secure system without Grsecurity, and a lot of Gentoo folks, especially advanced, use it, but the readers unfamiliar with it will need to acquaint themselves with it on: http://www.grsecurity.net ...
In brief, I have the default setting:
| Code: |
# cat /proc/sys/kernel/grsecurity/tpe
1
# cat /proc/sys/kernel/grsecurity/tpe_restrict_all
1
#
|
which is a great detail of grsec-protection generally, and does not interfere with my portage emerge'ing, but for a task like this, I have to disable it:
| Code: |
# echo 0 > /proc/sys/kernel/grsecurity/tpe
# echo 0 > /proc/sys/kernel/grsecurity/tpe_restrict_all
|
Now those 1's further above, are 0's, which means disabled.
However, more errors I get:
| Code: |
$ ./prepare --prefix=/usr --enable-pop --enable-imap --with-ssl |& tee ../mutt-1.5.24-dev_$(date +%y%m%d_%H%M%S)_prepare.log
Unescaped left brace in regex is deprecated, passed through in regex; marked by <-- HERE in m/\${ <-- HERE ([^ \t=:+{}]+)}/ at /usr/bin/automake-1.15 line 3936.
cp: cannot stat ‘/usr/share/automake-1.15/compile’: No such file or directory
configure.ac:16: error: installing './compile'
configure.ac:16: error while copying
cp: cannot stat ‘/usr/share/automake-1.15/config.guess’: No such file or directory
configure.ac:20: error: installing './config.guess'
configure.ac:20: error while copying
cp: cannot stat ‘/usr/share/automake-1.15/config.sub’: No such file or directory
configure.ac:20: error: installing './config.sub'
configure.ac:20: error while copying
cp: cannot stat ‘/usr/share/automake-1.15/install-sh’: No such file or directory
configure.ac:8: error: installing './install-sh'
configure.ac:8: error while copying
cp: cannot stat ‘/usr/share/automake-1.15/missing’: No such file or directory
configure.ac:8: error: installing './missing'
configure.ac:8: error while copying
cp: cannot stat ‘/usr/share/automake-1.15/depcomp’: No such file or directory
Makefile.am: error: installing './depcomp'
Makefile.am: error while copying
autoreconf-2.69: automake failed with exit status: 1
Some part of the preparation process failed.
Please refer to doc/devel-notes.txt for details.
|
Corrected (some of it, see below) as per:
My Hard Earned RBAC policy for Mutt
http://forums.grsecurity.net/viewtopic.php?f=5&t=4235
And again (some of it still not right):
| Code: |
$ ./prepare --prefix=/usr --enable-pop --enable-imap --with-ssl |& tee ../mutt-1.5.24-dev_$(date +%y%m%d_%H%M%S)_prepare.log
Unescaped left brace in regex is deprecated, passed through in regex; marked by <-- HERE in m/\${ <-- HERE ([^ \t=:+{}]+)}/ at /usr/bin/automake-1.15 line 3936.
configure.ac:16: installing './compile'
configure.ac:20: installing './config.guess'
configure.ac:20: installing './config.sub'
configure.ac:8: installing './install-sh'
configure.ac:8: installing './missing'
Makefile.am: installing './depcomp'
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... no
configure: error: in `/home/ukrainian/hg/mutt':
configure: error: C compiler cannot create executables
See `config.log' for more details
Some part of the preparation process failed.
Please refer to doc/devel-notes.txt for details.
|
But I've been here already. This is just grsecurity in practice. Pls. see:
My Hard Earned RBAC policy for Mutt
(the link already given a few lines above)
After fixing that (again, just like I fixed it a month ago), ./prepare script ran fine.
| Code: |
$ make |& tee ../mutt-1.5.24-dev_$(date +%y%m%d_%H%M%S)_make.log
|
also went fine.
Now, just like my cheat-sheet says, as root:
| Code: |
# cd ~ukrainian/hg/mutt/
# find / -xdev -name '*' > /root/FIND_mutt-1.5.24-dev_$(date +%y%m%d_%H%M)_make_AFTER.txt
|
which does take a higher number of seconds on yesteday's machines like mine (but only this first run --I guess the ext4 journal makes for a quick run of the second one below).
And:
| Code: |
# make install |& tee ../mutt-1.5.24-dev_$(date +%y%m%d_%H%M%S)_make_install.log
# find / -xdev -name '*' > /root/FIND_mutt-1.5.24-dev_$(date +%y%m%d_%H%M)_make_install_AFTER.txt
|
The install proper is done. But not the logs! And that is important. I don't want my portage having issues with these out-of-portage installs! Must keep track of what is installed out-of-portage!
So:
| Code: |
cp -iav ~ukrainian/hg/mutt/config.log /var/log/no-portage-DEL/mutt-1.5.24-dev_$(date +%y%m%d_%H%M%S)_config.log
cp -iav ~ukrainian/hg/mutt-1.5.24-dev_150814_143900_prepare.log /var/log/no-portage/
cp -iav ../mutt-1.5.24-dev_150814_150348_make_install.log /var/log/no-portage/
|
and now first:
| Code: |
diff /root/FIND_mutt-1.5.24-dev_150814_150* | grep '> ' | sed 's/> //' | egrep -v '\/proc\/|\/root\/|\/home\/ukrainian\/hg\/'
|
to see if what I get with the diff. It happens to be just about what I reckoned I would. So:
| Code: |
diff /root/FIND_mutt-1.5.24-dev_150814_150* | grep '> ' | sed 's/> //' | egrep -v '\/proc\/|\/root\/|\/home\/ukrainian\/hg\/' > /var/log/no-portage/mutt-1.5.24-dev_150814_150348_make_install.ls-1
|
That last '[...].ls-1' file is simply named after the make_install.log, using its timestamp.
The look of just the no-portage dir,
# ls -l /var/log/no-portage/
| Code: |
total 160
-rw-r--r-- 1 ukrainian ukrainian 11473 2015-08-14 14:39 mutt-1.5.24-dev_150814_143900_prepare.log
-rw-r--r-- 1 ukrainian ukrainian 129721 2015-08-14 14:39 mutt-1.5.24-dev_150814_144552_config.log
-rw-r--r-- 1 root root 9159 2015-08-14 15:03 mutt-1.5.24-dev_150814_150348_make_install.log
-rw-r--r-- 1 root root 4220 2015-08-14 15:10 mutt-1.5.24-dev_150814_150348_make_install.ls-1
# |
The moment of truth. And this surely might turn into a call for the "unsupported" support, if my next Mutt invocation fails for some reason, and I promise you I won't lie about the failure (I'm yet to know if I got my Mutt working)!...
But, no! All went fine! I got my...:
| Code: |
This certificate belongs to:
gitb-miro
Unknown
Croatia Fidelis
Officium Centralis
Zagreb
This certificate was issued by:
gitb-miro
Unknown
Croatia Fidelis
Officium Centralis
Zagreb
This certificate is valid
from Aug 29 08:52:03 2014 GMT
to Aug 29 08:52:03 2015 GMT
Fingerprint: 071A 2DC0 F91C 7E76 0020 BDEF 948B E119
------- -------
-------
-- Mutt: SSL Certificate check (certificate 0 of 0 in chain)
Password for miro@localhost:
|
...[my] usual screen back, and Mutt is working fine.
Except for one thing, the manual doesn't show when F1 is pressed. But I think I've been there. Sadly, I don't recollect things so quickly, nearing 60, nothing alarming yet... I think it's probably issue with grsec perm for lynx.
It's a minor issue though. Can wait.
This is what I installed.
| Code: |
$ mutt -v
Mutt 1.5.23+116 (55ea6e829b46) (2014-03-12)
Copyright (C) 1996-2009 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.
System: Linux 4.1.5-hardened-150813 (x86_64)
ncurses: ncurses 6.0.20150808 (compiled with 6.0)
libidn: 1.32 (compiled with 1.32)
Compiler:
Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.5/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.5/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-4.8.5/work/gcc-4.8.5/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.5 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.5/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.5 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.5/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.5/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.5/include/g++-v4 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.8.5/python --enable-languages=c,c++ --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo Hardened 4.8.5 p1.0, pie-0.6.1' --enable-esp --enable-libstdcxx-time --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64 --disable-altivec --disable-fixed-point --enable-targets=all --disable-libgcj --enable-libgomp --disable-libmudflap --disable-libssp --disable-libquadmath --enable-lto --without-cloog --disable-libsanitizer
Thread model: posix
gcc version 4.8.5 (Gentoo Hardened 4.8.5 p1.0, pie-0.6.1)
Configure options: '--prefix=/usr' '--enable-pop' '--enable-imap' '--with-ssl'
Compilation CFLAGS: -Wall -pedantic -Wno-long-long -g -O2
Compile options:
-DOMAIN
-DEBUG
-HOMESPOOL -USE_SETGID -USE_DOTLOCK -DL_STANDALONE +USE_FCNTL -USE_FLOCK
+USE_POP +USE_IMAP -USE_SMTP
+USE_SSL_OPENSSL -USE_SSL_GNUTLS -USE_SASL -USE_GSS +HAVE_GETADDRINFO
+HAVE_REGCOMP -USE_GNU_REGEX
+HAVE_COLOR +HAVE_START_COLOR +HAVE_TYPEAHEAD +HAVE_BKGDSET
+HAVE_CURS_SET +HAVE_META +HAVE_RESIZETERM
+CRYPT_BACKEND_CLASSIC_PGP +CRYPT_BACKEND_CLASSIC_SMIME -CRYPT_BACKEND_GPGME
-EXACT_ADDRESS -SUN_ATTACHMENT
+ENABLE_NLS -LOCALES_HACK +HAVE_WC_FUNCS +HAVE_LANGINFO_CODESET +HAVE_LANGINFO_YESEXPR
+HAVE_ICONV -ICONV_NONTRANS +HAVE_LIBIDN +HAVE_GETSID -USE_HCACHE
-ISPELL
SENDMAIL="/usr/sbin/sendmail"
MAILPATH="/var/mail"
PKGDATADIR="/usr/share/mutt"
SYSCONFDIR="/usr/etc"
EXECSHELL="/bin/sh"
-MIXMASTER
To contact the developers, please mail to <mutt-dev@mutt.org>.
To report a bug, please visit http://bugs.mutt.org/.
|
Cheers!
...Not yet. Can't leave till I solve the empty manual.txt call... You can see my:
http://www.croatiafidelis.hr/foss/cap/cap-150714_gen_mutt/Screen_150714_Mutt_in_Gentoo.webm
to see how the lack of manual in Mutt's own window was one of the reasons I felt bound to this method.
I looked up the logs that keep just about all in there for later perusing, when you have grsec-hardened kernel installed and properly configured.
And this...:
| Code: |
ug 14 14:56:29 gbn kernel: [78789.108488] grsec: (ukrainian:U:/bin/bash) exec of /bin/bash (/bin/sh -c LC_ALL=C lynx -dump -nolist -with_backspaces -display_charset=us-ascii manual.html > manual.txt || \ LC_ALL=C w3m -du) by /bin/bash[make:2898] uid/euid:1000/1000 gid/egid:1000/1000, parent /usr/bin/gmake[make:2851] uid/euid:1000/1000 gid/egid:1000/1000
Aug 14 14:56:29 gbn kernel: [78789.113680] grsec: (ukrainian:U:/usr/bin/lynx) exec of /usr/bin/lynx (lynx -dump -nolist -with_backspaces -display_charset=us-ascii manual.html ) by /usr/bin/lynx[sh:2899] uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[sh:2898] uid/euid:1000/1000 gid/egid:1000/1000
Aug 14 14:56:29 gbn kernel: [78789.158654] grsec: (ukrainian:U:/usr/bin/lynx) denied open of /home/ukrainian/hg/mutt/doc/manual.html for reading by /usr/bin/lynx[lynx:2899] uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[sh:2898] uid/euid:1000/1000 gid/egid:1000/1000
|
...[that] was the case.
Not a big problem. Running:
| Code: |
# for i in $(cat /var/log/no-portage/mutt-1.5.24-dev_150814_150348_make_install.ls-1) ; do ls -l $i ; read FAKE ; done ;
|
showed me:
| Code: |
-rw-r--r-- 1 root root 0 2015-08-14 15:03 /usr/share/doc/mutt/manual.txt
|
I could reinstall, but that's a hassle, isn't it? Why not, instead, just dump it somewhere with lynx, and simply put the resulting manual.txt instead of that empty file?
I'll use the same command that grsec told me the compilation executed:
| Code: |
$ lynx -dump -nolist -with_backspaces -display_charset=us-ascii manual.html > manual.txt |
That is basically what I did, and the manual is available in Mutt window at the press of F1, now. (I did see some issues in this occasion, but they are unrelated. This post is done.) |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Unsupported Software
