Gentoo Forums :: View topic - Mutt without Portage/in Local Overlay, for Air-Gappers

Mutt without Portage/in Local Overlay, for Air-Gappers

View unanswered posts
View posts from last 24 hours

Goto page Previous 1, 2, 3 Next

Gentoo Forums Forum Index

Unsupported Software

View previous topic :: View next topic

Author

Message

khayyam
Watchman

Joined: 07 Jun 2012
Posts: 6227
Location: Room 101

Posted: Thu Oct 30, 2014 2:45 pm Post subject: Re: Install Mutt without Portage, and Why, for Air-Gappers

miroR wrote:

Mutt should be fine with gnupg-1 without stupid frills.

... but mutt is fine using gnupg-1 ... it works perfectly here without any modification to the ebuild, so your "bug" is most likely due to your configuration. Also, gpgme is not a replacement for, or "alternative" to, gnupg ... it is simply a wrapper to make interfacing with gpg within mutt easier ... so, there is no "bug" here, you're just confused about what it is you think your seeing.

Code:

# for p in mutt app-crypt/gnupg gpgme ; do eix -necI $p ; done
[I] mail-client/mutt (1.5.22-r3@2014-08-22): A small but very powerful text-based mail client
[I] app-crypt/gnupg (1.4.18@2014-07-06): The GNU Privacy Guard, a GPL pgp replacement
[I] app-crypt/gpgme (1.3.2-r1(1)@2014-08-03): GnuPG Made Easy is a library for making GnuPG easier to use

miroR
l33t
l33t

Joined: 05 Mar 2008
Posts: 826

Posted: Fri Oct 31, 2014 12:49 pm Post subject: Re: Install Mutt without Portage, and Why, for Air-Gappers

khayyam wrote:

Code:

I'm on Debian (so typing, actually copying and modifying the above by typing parts over, to show what I have):

Code:

# for p in mutt app-crypt/gnupg gpgme ; do eix -necI $p ; done
[I] mail-client/mutt (1.5.23-r8[?]@29/10/14 -> (~)1.5.23-r2: A small but very powerful text-based mail client
[I] app-crypt/gnupg (1.4.18@09/10/14): The GNU Privacy Guard, a GPL pgp replacement

So it's slightly different, and no gpgme. Works great. Other than errors shown in the bug (comment 4). The errors showed in the mutt from portage when installing the regular way. Those errors didn't show when installing outside portage.

But I did get confused some. I mixed gpgme with kgpgme (or somesuch program which I remember didn't like but that was long ago). So gpgme does not entail GUI... My bad.

khayyam wrote:

miroR wrote:

Mutt should be fine with gnupg-1 without stupid frills.

... but mutt is fine using gnupg-1 ... it works perfectly here without any modification to the ebuild, so your "bug" is most likely due to your configuration.

Hmmmh... What could it be? I generally keep to what the book says....

khayyam wrote:

Also, gpgme is not a replacement for, or "alternative" to, gnupg ... it is simply a wrapper

No, it's a library. Typing what I see in my Gentoo:

portage wrote:

GnuPG Made Easy is a libarary for making GnuPG easier to use.

And I would like that much of a layer less to have to use when I want to simply type my password in. Isn't that kind of right to wish so?

khayyam wrote:

to make interfacing with gpg within mutt easier ... so, there is no "bug" here, you're just confused about what it is you think your seeing.

That does not result from anything that I wrote or said. I never claimed it soo stupidly. Never even thought that gpgme would be a

Quote:

a replacement for, or "alternative"

for gnupg.

No, khayyam, it's you who somewhat jumped to conclusion about that.

And the ebuild install from my overlay works fine for me. And it has no gpgme in there.

So it's not that simple as being my complete confusion. Some is yours too (although I expect that you invested terribly much less time than me in reviewing this topic).

If we start by looking up again at what there is in the ebuilds, mutt-1.5.22-r3.ebuild and mutt-1.5.23-r2.ebuild, as already reported above (copy-pasting from the first post, way in the very top):

Code:

# view /usr/portage/mail-client/mutt/mutt-1.5.23-r2.ebuild
...[snip]...
gpg? ( >=app-crypt/gpgme-0.9.0 )
...[snip]...

we can go and see that in my ebuild, posted in the bug report, more precisely this attachment, view it, and see that we find:

Code:

gpg? ( >=app-crypt/gnupg-1.4.18 )

in it, and no gpgme string to be found.

OTOH, it's not anymore fresh in my recollection, all the details about this topic, as I was aware concentrating on other things for a few days now...

So it may not be this:
how did you installed mutt, and with gnupg-1, the regular portage way, without modifications in your local overlay?

But rather, I need now look into my logs and see why I apparently, back at the time of writing this topic, I couldn't do it from portage, not without issues (just pls. don't jump to conclusion it was my confusion the only reason, before you really know it)...

Hmmh, before looking those up, I remember it was this: the patches! My ebuild. linked above (look it up, only sections commented out, not really modifications), went without patches, and I did not have much of issues, just the ones reported above.

You don't have any of those issues? And you go the regular way, with all the patches?

I insist that I don't have any issues, those or others, if I install without portage.

Anyway, this Developer sums up what I tried with my ebuild (in the bug 527338)

Jeroen Roovers wrote:

2014-10-29 14:10:16 UTC
Assignee: bug-wranglers@gentoo.org → grobian@gentoo.org
Summary: mail-client/mutt-1.5.23-r2 naturally best gnupg-1 not possible, other issues → mail-client/mutt - add support for app-crypt/gnupg as alternative to app-crypt/gpgme

and

Jeroen Roovers wrote:

2014-10-29 14:11:16 UTC
Attachment #387738 - Attachment description: mutt-1.5.23-r8.ebuild for local overlay to keep gnupg-1 in the text mail-client Mutt → mutt-1.5.23-r8.ebuild

However, I now need to look up my logs and see why I reported that gnupg-2 was to be installed on my system, instead of portage honoring my package.mask and accepting the already installed gnupg-1.
But already exhausted from other work elsewhere. If I'm late, pls. apply patience (ingredient of many a computing work).

jonathan183
Guru
Guru

Joined: 13 Dec 2011
Posts: 318

Posted: Fri Oct 31, 2014 3:51 pm Post subject:

For me having

Code:

>=app-crypt/gnupg-2.0.2

in /etc/portage/package.mask is sufficient for me to use gnupg version 1.4.18. I have mutt and claws-mail installed, which both required gpgme. If I wanted to avoid using gpgme then I would use a local overlay and modify the ebuild for mutt to suit.
I have only recently started using mutt, so not sure yet whether I will be switching from claws-mail yet ... so for the moment I have gpgme on my system.

miroR
l33t
l33t

Joined: 05 Mar 2008
Posts: 826

Posted: Fri Oct 31, 2014 5:01 pm Post subject:

jonathan183 wrote:

For me having

Code:

>=app-crypt/gnupg-2.0.2

in /etc/portage/package.mask is sufficient for me to use gnupg version 1.4.18.

I guess... And I wish more users would figure that out, where having it in portage we owe to khayyam.
But also more thought for all users considerations as well are just a few lines below from me (interpreting steveL's writing for myself.

jonathan183 wrote:

I have mutt and claws-mail installed, which both required gpgme. If I wanted to avoid using gpgme then I would use a local overlay and modify the ebuild for mutt to suit.

You could help improve my ebuild further, well it you found that you needed it, and then we could post it for all to use...
Anyway, your help has been great in various places... :-)

. I bow my head to you!

jonathan183 wrote:

I have only recently started using mutt, so not sure yet whether I will be switching from claws-mail yet ... so for the moment I have gpgme on my system.

Probably once you switch you'll find it liberating to live witout the overhead of IPC that talks to dbus encrypted about whatever that the user is not supposed to know about (which dbus is there for IMO)...
That is how I interpret what I found here (especially in this post by steveL):

Re: KDE for surveillance-aware people
https://forums.gentoo.org/viewtopic-t-1002800.html

(but there is also fine talk of his in some places --maybe not a minute or two but even more to find it in all those pages-- in this topic:

Why is Gentoo not switching to systemd?
https://forums.gentoo.org/viewtopic-t-998108.html

-- 26 pages by now, and if a reader finds it, tell us all... He also wrote there about dbus.)

Anyway, happy to read from you. But a little more is now coming from me yet.

Just to say: I only now noticed that steveL has replied previously then khayyam, but I saw it only now. Will reply to that too.

Last edited by miroR on Fri Oct 31, 2014 5:11 pm; edited 1 time in total

miroR
l33t
l33t

Joined: 05 Mar 2008
Posts: 826

Posted: Fri Oct 31, 2014 5:10 pm Post subject:

steveL wrote:

miroR wrote:

I filed Bug 527338

Good. Note the link above ("Bug" button)

I looked it up and I don't get what you mean.

steveL wrote:

Quote:

It seems to have been noticed fine and that it is being worked on.

*sigh* you are new

Yeah. Sorry!

steveL wrote:

It's being processed, not worked on, since all that's happened is that a bug-wrangler has assigned it to
the correct team. So yes, they'll see it soon enough. When it will get corrected is another matter.
...[snip]...
Trust me, you've done very little so far, compared to what Gentoo users do on a daily or weekly basis.

Sure.

steveL wrote:

If it was expensive, I presume you mean your time. You could save us all a lot of that with shorter posts, yourself most of all.

I really would like if I could, but this is me working at the top of my abilities.

miroR
l33t
l33t

Joined: 05 Mar 2008
Posts: 826

Posted: Fri Oct 31, 2014 5:24 pm Post subject:

Back to the topic.
I have mutt from my overlay installed in my master Gentoo. So I didn't feel like uninstalling to try here.
But in a clone of the same system (...Bkp/Cloning Mthd... (if some newbie is interested to know how to clone), I was able to check.

This is, essentially, what I don't want to have, in my system, without a proper reason.
WARNING: If anyone has a large desktop such as KDE/GNOME and relatives, they can't go this way here, because they can't go without dbus.

So:

Code:

# emerge -avtuDN mutt

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

Calculating dependencies ... done!
[ebuild N ] mail-client/mutt-1.5.23-r2 USE="berkdb crypt doc gdbm gnutls gpg imap mbox nls pop sasl smime smtp ssl -debug -idn -kerberos -nntp -qdbm (-selinux) -sidebar -slang -tokyocabinet" 0 KiB
[ebuild N ] app-crypt/gpgme-1.5.1:1/11 USE="-common-lisp -static-libs" 943 KiB
[ebuild N ] dev-libs/libassuan-2.1.2 USE="-static-libs" 504 KiB

Total: 3 packages (3 new), Size of downloads: 1,446 KiB

And those other programs are:

Code:

# emerge -s gpgme
Searching...
[ Results for search key : gpgme ]
[ Applications found : 2 ]

* app-crypt/gpgme
Latest version available: 1.5.1
Latest version installed: [ Not Installed ]
Size of files: 943 KiB
Homepage: http://www.gnupg.org/related_software/gpgme
Description: GnuPG Made Easy is a library for making GnuPG easier to use
License: GPL-2 LGPL-2.1

* dev-python/pygpgme
Latest version available: 0.3-r1
Latest version installed: [ Not Installed ]
Size of files: 49 KiB
Homepage: https://launchpad.net/pygpgme
Description: A Python wrapper for the GPGME library
License: LGPL-2.1

and

Code:

# emerge -s libassuan
Searching...
[ Results for search key : libassuan ]
[ Applications found : 1 ]

* dev-libs/libassuan
Latest version available: 2.1.2
Latest version installed: [ Not Installed ]
Size of files: 504 KiB
Homepage: http://www.gnupg.org/related_software/libassuan/index.en.html
Description: IPC library used by GnuPG and GPGME
License: GPL-3 LGPL-2.1

So that's the overhead that if we get (this is my opinion) lots of users to get rid of, the corporate tools (like the "f*ing tool" that I quoted someone cleverer than me about) will have headaches deploying their intrusion (IMO) software on us.

There is no technically impelling reason in the world to have to use gpgme and libassuan for Mutt to sign/verify/encrypt/decrypt mail, other than what I just said... And the big desktops have gone that corporate non-free non-privacy (really not, sorry!) way...

So to be in the [F]ree [O]pen [S]ource [S]oftware way, this needs to be done, just like the bug-wragler Jeroen Roovers assigned it, and you, Developers who are hopefully reading this, pls. make it an option into Portage to install mutt without libassuan and gpgme!

And if you do, thank you for that (and many users will be thankful to you for that, I believe). Also, sorry for costing you so much time, I work at the top of what I can.

Last edited by miroR on Fri Oct 31, 2014 5:35 pm; edited 1 time in total

khayyam
Watchman

Joined: 07 Jun 2012
Posts: 6227
Location: Room 101

Posted: Fri Oct 31, 2014 5:34 pm Post subject: Re: Install Mutt without Portage, and Why, for Air-Gappers

miroR wrote:

But I did get confused some. I mixed gpgme with kgpgme (or somesuch program which I remember didn't like but that was long ago). So gpgme does not entail GUI... My bad.

... nor does it have any relation to gnupg-1 being somehow required ... which is the quote from you I was responding to: "Mutt should be fine with gnupg-1 without stupid frills". So the "confusion" is deeper than you suggest.

miroR wrote:

khayyam wrote:

... but mutt is fine using gnupg-1 ... it works perfectly here without any modification to the ebuild, so your "bug" is most likely due to your configuration.

Hmmmh... What could it be? I generally keep to what the book says....

No idea ... given your tendency to post the most irrelavant, and/or unfactual, information, there isn't anything in this thread so far that might provide some idea of your actual problem.

miroR wrote:

And I would like that much of a layer less to have to use when I want to simply type my password in. Isn't that kind of right to wish so?

"wrapper" or "library" ... you want to make some semantic distinction? It provides more than the ability to "type [your] password" it makes it possible to avoid having "set pgp_decode_command="gpg --status-fd=2 %?p?--passphrase-fd 0? --no-verbose --quiet --batch --output - %f" (and every other definition required for mutt to handle OpenPGP MIME messages), all that is needed it "set crypt_use_gpgme=yes" ... besides it has no relation, or preference for, gnupg-2 ... which is what you seem to be banging on about from the get go (as you say: "[b]ecause you are better of trying to use gpg-1 instead --that one above is a GUI interface, goes with the gpg-2 which you have to use gpg-agent and GUI to type password; not the mutt way really"). Now, if you don't want to use gpgme, fine, you can place it in package.provided and configure mutt as per the exerpt above ... solved ... but its not a bug, and gnupg-1 works perfectly fine without any changes to the ebuild.

miroR wrote:

khayyam wrote:

to make interfacing with gpg within mutt easier ... so, there is no "bug" here, you're just confused about what it is you think your seeing.

That does not result from anything that I wrote or said. I never claimed it soo stupidly. Never even thought that gpgme would be "a replacement for", or "alternative" for gnupg.

Infact you did ... the bug report was titled "mail-client/mutt - add support for app-crypt/gnupg as alternative to app-crypt/gpgme", that reads to me as though you want gnupg as a "alternative".

miroR wrote:

No, khayyam, it's you who somewhat jumped to conclusion about that.

gahhhhh ...

miroR wrote:

So it's not that simple as being my complete confusion. Some is yours too (although I expect that you invested terribly much less time than me in reviewing this topic).

No, the confusion is completely yours.

miroR
l33t
l33t

Joined: 05 Mar 2008
Posts: 826

Posted: Fri Oct 31, 2014 5:46 pm Post subject:

I would like not to discuss it anymore with you khayyam, since you are IMO misquoting me where it suits you.
My reply stands at:
< this same topic >
https://forums.gentoo.org/viewtopic-t-1002146-start-25.html#7642630
and constructions in the next khayyam's post (immediately above) are not worth it.
Besides, as far as the topic goes, I have corrected my part of confusion and made very precise what the entire topic is about:
< this same topic >
https://forums.gentoo.org/viewtopic-t-1002146-start-25.html#7642750

Kind readers, and Developers who hopefully will be looking into this,

the original lapsus mentis of mine, for which I apologize to you, was mine, and happened to me here:

KMail to mutt with Maildir and procmail
https://forums.gentoo.org/viewtopic-t-945868.html#7638640
I'm quoting what I wrote there.

miroR wrote:

...[snip]...
Nope! It was dbus back in there. And it just wouldn't install without replacing my gnupg-1, which I want (
Install Mutt without Portage, and Why, for Air-Gappers
https://forums.gentoo.org/viewtopic-t-1002146.html
) with gnupg-2 which introduces GUI and other overhead...

This is the original gnupg-2 imposition when installing Kaffeine I took on over into Mutt install issues.

Kind of a forum type of lapsus mentis. I'm sure it only happens to me, and never to any of the gentle readers ;-)

.

Sorry for that.

So it is now obvious how that lapsus come about.

I mixed installing Kaffeine, which I report how I tried to install it, in that topic above (which was split on, so it would be wrong for me to post there on topic different than is dealt with there), which installing (emerging) of Kaffeine got me yes the gnupg-2 after it unemerged gnupg-1, and also got some more stuff, of the dbus family or relatives....

And sadly I went on about gnupg-2 in this topic, while gnupg-1 is supported fine with Mutt.

So, for the record. Pls. disregard gnupg-2 where I mention it, and consider the unnecessary overhead to be these libassuan and gpgme as I explained.

I feel it is good to post this about gnupg-2 imposition when installing Kaffeine here, because that is really the same kind of issue as here, only with some variation.

I can't correct any of my previous posts for a while, because of misquoting that happened by a contributor to discussion. I don't want any new timestamps anywhere previous from here on my posts, for a while. Thank you.

Also tried to mend it in the bug

jonathan183
Guru
Guru

Joined: 13 Dec 2011
Posts: 318

Posted: Fri Oct 31, 2014 8:40 pm Post subject: Re: Install Mutt without Portage, and Why, for Air-Gappers

khayyam wrote:

Now, if you don't want to use gpgme, fine, you can place it in package.provided and configure mutt as per the exerpt above

I don't think this will work if you unmerge gpgme and try emerging mutt ... I tried it fairly recently and the emerge failed. So the options left are:-
1. accept installation of gpgme
2. modify the ebuild for mutt
3. install mutt manually

As I said in my previous post for the moment I'm going with option 1 ...

Ed: just tried again, emerge of mutt fails at

Code:

checking whether to build with GPGME support... yes
checking for gpgme-config... no
checking for GPGME - version >= 1.0.0... no
configure: error: *** GPGME not found ***

!!! Please attach the following file when seeking support:
!!! /var/tmp/portage/mail-client/mutt-1.5.22-r3/work/mutt-1.5.22/config.log
* ERROR: mail-client/mutt-1.5.22-r3::gentoo failed (configure phase):

You should be able to patch mutt-1.5.22-r3.ebuild with patch

Code:

48d47
< gpg? ( >=app-crypt/gpgme-0.9.0 )
133c132
< $(use_enable gpg gpgme) \
---
> $(use_enable gpg ) \

steveL
Watchman

Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

Posted: Sat Nov 01, 2014 1:53 pm Post subject:

Good info, jon; miroR you should try that patch out and if it works for you too, attach it to the bug, stating jonathan183 wrote it and it also works for you.

miroR
l33t
l33t

Joined: 05 Mar 2008
Posts: 826

Posted: Sat Nov 01, 2014 8:28 pm Post subject:

steveL wrote:

Good info, jon; miroR you should try that patch out and if it works for you too, attach it to the bug, stating jonathan183 wrote it and it also works for you.

Pls. excuse me for being replying late. I was busy, and I finally am free.
It's basically just what I did, but on top of that, I went without the patches --I commented them all out from the original ebuild, on top of the same thing that Jonathan did--, which probably didn't get into Mutt for not being, say, orthodox enough, or not deemed universal enough, or maybe not compatible with something somewhere, how else do I put it?

I prefer what I offered on the bug page (see my ebuild there).

Last edited by miroR on Sat Nov 01, 2014 10:31 pm; edited 1 time in total

jonathan183
Guru
Guru

Joined: 13 Dec 2011
Posts: 318

Posted: Sat Nov 01, 2014 10:31 pm Post subject:

steveL wrote:

Good info, jon; miroR you should try that patch out and if it works for you too, attach it to the bug, stating jonathan183 wrote it and it also works for you.

The patch only removes the need for gpgme with mutt, so it should do in the case you don't want to use gpgme ... there is no logic to determine if the user wants to use gpgme. Specific select would need a use flag, since there will be no other way to determine automagically if the user wants to use gpgme or not with mutt.

I don't think there is a gpgme flag ... and it would not be appropriate to impose this approach on everyone using mutt

One of the great things about Gentoo is we can create a local overlay and modify the ebuild to do exactly what we want ... and portage will keep track of what we did

Last edited by jonathan183 on Sat Nov 01, 2014 10:42 pm; edited 1 time in total

miroR
l33t
l33t

Joined: 05 Mar 2008
Posts: 826

Posted: Sat Nov 01, 2014 10:34 pm Post subject:

Why have the timestamps changed? What server games[1] are those (like with the temporary addresses)?
I have last night srcreencasts here is how I do them, along with my Flowstamp program to be accompanied with network captures (just

Code:

touch dump_`date +%y%m%d_%H%M`_`hostname`.pcap && dumpcap -i any -w dump_`date +%y%m%d_%H%M`_`hostname`.pcap &

. (I decided I was going to screencast-and-capture and keep to it most of the time, eversince I was attacked; well not since then, but eversince I with my stubbornness, some months or years --that's how slow I work, and how stubborn-- learned how to do it), that show how, at the time I posted my "1 time" edited post immediately previous to this post, it read as I wrote at the top of this post:

Code:

c5774b18eb188e50e460d1392ce8e0d3025c723329a10bac05bc2efa722eaefd dump_141101_2252_naibd6.pcap
d85febe0c60c1eb6ee8d5de198605f0c32ad750f64f02368725af583757712bb Screen_141101_2252_naibd6.mkv

And it read:

Code:

11:31

, for both the consecutive, but in seconds, mine edit of the post, and jonathan's creating of the post. It didn't read

Code:

10:31

as now. I'm aware that there could be some automatic adjustments/auto-something-else in the server, so mostly I'm curious to know how come? The "daylight savings time" was a week or so ago, but I may not remember correctly (about that DST)...

---
[1] Have a look at these events:

The Gentoo servers went down (and generally I sooo rarely see them down, ever, actually I remember them down only at that precise time):
https://ffmpeg.org/pipermail/ffmpeg-user/2014-April/021025.html
almost immediately explained by some server man:
https://ffmpeg.org/pipermail/ffmpeg-user/2014-April/021027.html

and there were lots of temporary addresses for same pages:

https://ffmpeg.org/pipermail/ffmpeg-user/2014-April/021065.html
(look in there where you see a stack of http:// forums.gentoo.org preceded by my explanation how:

me wrote:

At some point in the past, all of these opened exactly the same page

miroR
l33t
l33t

Joined: 05 Mar 2008
Posts: 826

Posted: Sun Nov 02, 2014 7:57 am Post subject:

Code:

touch dump_`date +%y%m%d_%H%M`_`hostname`.pcap && dumpcap -i any -w dump_`date +%y%m%d_%H%M`_`hostname`.pcap &

Code:

c5774b18eb188e50e460d1392ce8e0d3025c723329a10bac05bc2efa722eaefd dump_141101_2252_naibd6.pcap
d85febe0c60c1eb6ee8d5de198605f0c32ad750f64f02368725af583757712bb Screen_141101_2252_naibd6.mkv

And it read:

Code:

11:31

, for both the consecutive, but in seconds, mine edit of the post, and jonathan's creating of the post. It didn't read

Code:

10:31

me wrote:

At some point in the past, all of these opened exactly the same page

Well, now (Sun 2 Nov 08:09:47 CET 2014) they all do open, but not the same page...

After that event, I learned to cite always, always the pages with the -t- only, that I get from "View your posts" link, and never any temporary ones.

And I also like using http://www.PublicTimeStamp.org sometimes...
======= cut off from this line to end if verifying hashes =======
File corresponding to this post: Gen_141102_Mirror_verification.txt,
has Publictimestamp # 1246118

EDIT: sadly I gave the filename wrong title, but the rest I gave right and can be verified on PTS page.
And it verifies on PTS fine. Anyone can do it. At this time, it corresponds with what is on Gentoo Forums, where you are reading this.
Here's how to do it. Quote me. Remove carefully the quotes, and what reads to be removed. And the hashes correspond to the ones found on PTS search pages (there are two documents of that title, but you can search by the.Publictimestamp # 1246118.
--
publictimestamp.org/ptb/PTB-22005 sha256 2014-11-02 06:01:45
CCE783CE3E21C9FFE69CC31B7A67783EC6373446CB70E7A796E2D3BFBFC7876D

229566
Tux's lil' helper

Joined: 16 Aug 2010
Posts: 127

Posted: Sun Nov 02, 2014 10:50 am Post subject:

miroR wrote:

The "daylight savings time" was a week or so ago, but I may not remember correctly (about that DST)...

In Croatia, but this Sunday, today, was in USA.

steveL
Watchman

Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

Posted: Sun Nov 02, 2014 12:14 pm Post subject:

jonathan183 wrote:

The patch only removes the need for gpgme with mutt, so it should work in the case you don't want to use gpgme ... there is no logic to determine if the user wants to use gpgme. Specific select would need a use flag, since there will be no other way to determine automagically if the user wants to use gpgme or not with mutt.

I don't think there is a gpgme flag ... and it would not be appropriate to impose this approach on everyone using mutt ;)

It's fine to introduce a USE-flag, defaulting to on.

So any existing users who don't care, don't notice a difference, since it keeps on doing what it did before. And any who do can turn it off in package.use.

Admittedly it's a little trickier here, since gpgme only applies if you're already using gpg; I think an || dependency might help, but I don't know the ins and outs like you do.

Quote:

One of the great things about Gentoo is we can create a local overlay and modify the ebuild to do exactly what we want ... and portage will keep track of what we did 8)

Indeed: since everything is from source, and we have bash scriptlets doing the actual build, it's transparent and easy to modify, and as you say the tools support that. It also makes collaboration a lot easier, and more fun :-)

miroR
l33t
l33t

Joined: 05 Mar 2008
Posts: 826

Posted: Sun Nov 02, 2014 3:49 pm Post subject:

GrueXYZ wrote:

miroR wrote:

The "daylight savings time" was a week or so ago, but I may not remember correctly (about that DST)...

In Croatia, but this Sunday, today, was in USA.

In the European Union which Croatia is member of, was a week ago.
But I see. It must have been exactly that, the reason. Thanks.

miroR
l33t
l33t

Joined: 05 Mar 2008
Posts: 826

Posted: Mon Dec 01, 2014 7:20 pm Post subject:

There has been a reply on the bugs.gentoo.org:
https://bugs.gentoo.org/show_bug.cgi?id=527338#c6

which I saw only now. Will reply there, or at least thank the dev.

There I made progress recently on this issue of bringing Mutt closer to original, without patches, which is the way I will be going for now.

Also I discovered why the error as I expained in the beginning of this post --quoting it here:

miroR wrote:

...[snip]...
After doing a regular "emerge mutt", and trying to use it, I got:

Code:

ukrainian@mybox ~ $ mutt
Error in /home/ukrainian/.muttrc, line 11: ssl_usesystemcerts: unknown variable
source: errors in /home/ukrainian/.muttrc
Press any key to continue...
ukrainian@mybox ~ $

...[snip]...

That one is solved by sticking -gnutls along with ssl, in the /etc/portage/package.use:
Exampli gratia (or e.g. ;-)

), I have:

Code:

mail-client/mutt doc imap mbox pop smime gpg smtp ssl -gnutls

in my /etc/portage/package.use.

And with this ebuild (excuse me for my last portage update being 32 days ago, but the principle is the same, probably, if things have radically changed, I'll update this my information here, later)...

--you can see in the header that it is based on r2, but the diff btwn r2 and r4 which was the latest back 32 days ago is really only in maybe two lines that concern patching, and those lines are commented anyway in my r10-- also, I'm not bothering with diff to that r2 ebuild, because mine is heavily commented out, so very different, and giving diff makes little sense:

Code:

# Copyright 1999-2014 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/mail-client/mutt/mutt-1.5.23-r2.ebuild,v 1.1 2014/04/08 20:37:42 grobian Exp $

# Modified by miroR from portage repo to accept gnupg-1 and no gpg-agent and GUI

EAPI="5"

inherit eutils flag-o-matic autotools

# No patches, plain upstream
#PATCHSET_REV="-r2"

DESCRIPTION="A small but very powerful text-based mail client"
HOMEPAGE="http://www.mutt.org/"
SRC_URI="mirror://sourceforge/${PN}/${P}.tar.gz
https://bitbucket.org/${PN}/${PN}/downloads/${P}.tar.gz
ftp://ftp.mutt.org/mutt/devel/${P}.tar.gz"
# mirror://gentoo/${P}-gentoo-patches${PATCHSET_REV}.tar.bz2
# http://dev.gentoo.org/~grobian/distfiles/${P}-gentoo-patches${PATCHSET_REV}.tar.bz2"
IUSE="berkdb crypt debug doc gdbm gnutls gpg idn imap kerberos mbox nls nntp pop qdbm sasl selinux sidebar slang smime smtp ssl tokyocabinet"
SLOT="0"
LICENSE="GPL-2"
KEYWORDS="~alpha ~amd64 ~arm ~hppa ~ia64 ~mips ~ppc ~ppc64 ~sparc ~x86 ~x86-fbsd ~x64-freebsd ~x86-freebsd ~x86-interix ~amd64-linux ~x86-linux ~ppc-macos ~x64-macos ~x86-macos ~sparc-solaris ~sparc64-solaris ~x64-solaris ~x86-solaris"
RDEPEND="
app-misc/mime-types
nls? ( virtual/libintl )
tokyocabinet? ( dev-db/tokyocabinet )
!tokyocabinet? (
   qdbm? ( dev-db/qdbm )
   !qdbm? (
      gdbm? ( sys-libs/gdbm )
      !gdbm? ( berkdb? ( >=sys-libs/db-4 ) )
   )
)
imap? (
   gnutls? ( >=net-libs/gnutls-3.3.8 )
   !gnutls? ( ssl? ( >=dev-libs/openssl-1.0.1j ) )
   sasl? ( >=dev-libs/cyrus-sasl-2 )
)
kerberos? ( virtual/krb5 )
pop? (
   gnutls? ( >=net-libs/gnutls-3.3.8 )
   !gnutls? ( ssl? ( >=dev-libs/openssl-1.0.1j ) )
   sasl? ( >=dev-libs/cyrus-sasl-2 )
)
smtp? (
   gnutls? ( >=net-libs/gnutls-3.3.8 )
   !gnutls? ( ssl? ( >=dev-libs/openssl-1.0.1j ) )
   sasl? ( >=dev-libs/cyrus-sasl-2 )
)
idn? ( net-dns/libidn )
gpg? ( >=app-crypt/gnupg-1.4.18 )
smime? ( >=dev-libs/openssl-1.0.1j )
selinux? ( sec-policy/selinux-mutt )
slang? ( sys-libs/slang )
!slang? ( >=sys-libs/ncurses-5.2 )
"
DEPEND="${RDEPEND}
net-mail/mailbase
doc? (
   dev-libs/libxml2
   dev-libs/libxslt
   app-text/docbook-xsl-stylesheets
   || ( www-client/lynx www-client/w3m www-client/elinks )
)"

# No patches, plain upstream
#PATCHDIR="${WORKDIR}"/${P}-gentoo-patches${PATCHSET_REV}

src_prepare() {
# Post-release hot-fixes grabbed from HG, this is what all following
# patches are based on in my Mercurial patchqueue (mq).
# If you ever take over or need to modify patches here, just check
# out the gentoo branch(es) of Gentoo's Mutt Mercurial clone, and
# the patchqueue as it'll save you a lot of work.
# http://prefix.gentooexperimental.org:8000/mutt/
# http://prefix.gentooexperimental.org:8000/mutt-patches/
# for rev in $(eval echo {0..${PR#r}}) ; do
#    local revpatch="${PATCHDIR}"/mutt-gentoo-${PV}-r${rev}.patch
#    [[ -e ${revpatch} ]] && \
#       epatch "${revpatch}"
# done
# # fix compilation with ncurses[tinfo], #459260
# epatch "${PATCHDIR}"/ncurses-tinfo.patch
#
# # this patch is non-generic and only works because we use a sysconfdir
# # different from the one used by the mailbase ebuild
# use prefix && epatch "${PATCHDIR}"/prefix-mailcap.patch
#
# # must have fixes to compile or behave correctly, upstream
# # ignores, disagrees or simply doesn't respond/apply
# epatch "${PATCHDIR}"/bdb-prefix.patch # fix bdb detection
# # same category, but functional bits
# epatch "${PATCHDIR}"/dont-reveal-bbc.patch
#
# # the big feature patches that upstream doesn't want to include, but
# # nearly every distro has due to their usefulness
# for p in "${PATCHDIR}"/[0-9][0-9]-*.patch ; do
#    epatch "${p}"
# done
#
# # we conditionalise this one, simply because it has considerable
# # impact on the code
# if use sidebar ; then
#    epatch "${PATCHDIR}"/sidebar.patch
#    epatch "${PATCHDIR}"/sidebar-utf8.patch
#    epatch "${PATCHDIR}"/sidebar-dotpathsep.patch
# fi
#
# local upatches=
# # allow user patches
# epatch_user && upatches=" with user patches"
#
# # patch version string for bug reports
## sed -i -e 's/"Mutt %s (%s)"/"Mutt %s (%s, Gentoo '"${PVR}${upatches}"')"/' \
#    muttlib.c || die "failed patching in Gentoo version"
#
# # many patches touch the buildsystem, we always need this
# AT_M4DIR="m4" eautoreconf

# really plain upstream first
# # the configure script contains some "cleverness" whether or not to setgid
# # the dotlock program, resulting in bugs like #278332
# sed -i -e 's/@DOTLOCK_GROUP@//' \
#    Makefile.in || die "sed failed"
#
# don't just build documentation (lengthy process, with big dependencies)
if use !doc ; then
#    sed -i -e '/SUBDIRS =/s/doc//' Makefile.in || die
echo "I don't think src_prepare() can be empty."
fi
}

src_configure() {
local myconf="
   $(use_enable crypt pgp) \
   $(use_enable debug) \
   $(use_enable gpg) \
   $(use_enable imap) \
   $(use_enable nls) \
   $(use_enable nntp) \
   $(use_enable pop) \
   $(use_enable smime) \
   $(use_enable smtp) \
   $(use_with idn) \
   $(use_with kerberos gss) \
   $(use slang && echo --with-slang) \
   --enable-compressed \
   --enable-external-dotlock \
   --enable-mixmaster \
   --enable-nfs-fix \
   --sysconfdir=${EPREFIX}/etc/${PN} \
   --with-curses \
   --with-docdir=${EPREFIX}/usr/share/doc/${PN}-${PVR} \
   --with-regex \
   --with-exec-shell=${EPREFIX}/bin/sh"

case $CHOST in
   *-solaris*)
      # Solaris has no flock in the standard headers
      myconf="${myconf} --enable-fcntl --disable-flock"
   ;;
   *)
      myconf="${myconf} --disable-fcntl --enable-flock"
   ;;
esac

# mutt prioritizes gdbm over bdb, so we will too.
# hcache feature requires at least one database is in USE.
if use tokyocabinet; then
   myconf="${myconf} --enable-hcache \
      --with-tokyocabinet --without-qdbm --without-gdbm --without-bdb"
elif use qdbm; then
   myconf="${myconf} --enable-hcache \
      --without-tokyocabinet --with-qdbm --without-gdbm --without-bdb"
elif use gdbm ; then
   myconf="${myconf} --enable-hcache \
      --without-tokyocabinet --without-qdbm --with-gdbm --without-bdb"
elif use berkdb; then
   myconf="${myconf} --enable-hcache \
      --without-tokyocabinet --without-qdbm --without-gdbm --with-bdb"
else
   myconf="${myconf} --disable-hcache \
      --without-tokyocabinet --without-qdbm --without-gdbm --without-bdb"
fi

# there's no need for gnutls, ssl or sasl without socket support
if use pop || use imap || use smtp ; then
   if use gnutls; then
      myconf="${myconf} --with-gnutls"
   elif use ssl; then
      myconf="${myconf} --with-ssl"
   fi
   # not sure if this should be mutually exclusive with the other two
   myconf="${myconf} $(use_with sasl)"
else
   myconf="${myconf} --without-gnutls --without-ssl --without-sasl"
fi

if use mbox; then
   myconf="${myconf} --with-mailpath=${EPREFIX}/var/spool/mail"
else
   myconf="${myconf} --with-homespool=Maildir"
fi

econf ${myconf} || die "configure failed"
}

src_install() {
emake DESTDIR="${D}" install || die "install failed"
if use mbox; then
   insinto /etc/mutt
   newins "${FILESDIR}"/Muttrc.mbox Muttrc
else
   insinto /etc/mutt
   doins "${FILESDIR}"/Muttrc
fi

# really plain upstream first
# # A newer file is provided by app-misc/mime-types. So we link it.
# rm "${ED}"/etc/${PN}/mime.types
# dosym /etc/mime.types /etc/${PN}/mime.types

# A man-page is always handy, so fake one
if use !doc; then
   emake -C doc DESTDIR="${D}" muttrc.man || die
   # make the fake slightly better, bug #413405
   sed -e 's#@docdir@/manual.txt#http://www.mutt.org/doc/devel/manual.html#' \
      -e 's#in @docdir@,#at http://www.mutt.org/,#' \
      -e "s#@sysconfdir@#${EPREFIX}/etc/${PN}#" \
      -e "s#@bindir@#${EPREFIX}/usr/bin#" \
      doc/mutt.man > mutt.1
   cp doc/muttbug.man flea.1
   cp doc/muttrc.man muttrc.5
   doman mutt.1 flea.1 muttrc.5
# really plain upstream first
# else
#    # nuke manpages that should be provided by an MTA, bug #177605
#    rm "${ED}"/usr/share/man/man5/{mbox,mmdf}.5 \
#       || ewarn "failed to remove files, please file a bug"
fi

if use !prefix ; then
   fowners root:mail /usr/bin/mutt_dotlock
   fperms g+s /usr/bin/mutt_dotlock
fi

dodoc BEWARE COPYRIGHT ChangeLog NEWS OPS* PATCHES README* TODO VERSION
}

pkg_postinst() {
echo
elog "If you are new to mutt you may want to take a look at"
elog "the Gentoo QuickStart Guide to Mutt E-Mail:"
elog " http://www.gentoo.org/doc/en/guide-to-mutt.xml"
echo
}

So, if anyone feels like trying that ebuild (writing this for the newbies, advanced Gentooers, just skip this text),..

So, if anyone feels like trying that ebuild copy it from this post that you are reading,, name it mutt-1.5.23-r10.ebuild, and, I believe, once you have a local overlay in /var/lib/layman and not in /usr/local/portage as is at this time erroneously (for current layman) told you in: Overlay/Local overlay (but otherwise once you have all set as explained there) ...

Then I believe do just:

Code:

# mkdir /var/lib/layman/mail-client/
# cp -iav mutt-1.5.23-r10.ebuild /var/lib/layman/mail-client/
# cd /var/lib/layman/mail-client/
# repoman manifest

If all went fine, you will see the "1.5.23-r10" mutt that emerge wants to install for you when you:

Code:

# emerge mutt

Ah, the differences and why the ebuild that I posted in the bug 527338 - mail-client/mutt - add support for app-crypt/gnupg as alternative to app-crypt/gpgme , here:

https://527338.bugs.gentoo.org/attachment.cgi?id=387738

and this new one in this post, and why this latter works, is, also because I stuck in the new version of openssl, principally.

I'll be back, but maybe not urgently (really kind of quagmired in mind-strenuos work)...

I hope this helps other Gentooers. Because our devs are often too busy to offer, esp.explanations, such as the difference btwn the gpg and pgp flags (not recognized by the pure upstream that flag, when installed without gentoo specific pathes, just to mention)... and differs that what the Mutt manual offers, then, in a few places such as the error that I explained.... Also, in 32 days ago old portage, there are Mutt USE flags missing, not mentioned at all, in /usr/portage/profiles/use.desc and /usr/portage/profiles/use.local.desc

Still only have the F1 not working to bring up the manual in the Mutt window, as in upstream Mutt; can read it in my Apache, but the former is much nicer and more efficient...

This is the signature for the ebuild above (don't know a better way currently:

Code:

For newbies, again: quote this post, (I don't know if otherwise it would work.) Mouse over to select it. You have it in your mouse clipboard (or whatever it's called).

Do this. Make sure mutt-1.5.23-r10.ebuild does not exist from previous attempts:

Code:

# cat > mutt-1.5.23-r10.ebuild

That is waiting for your input. Middle mouse what you copied into the mouse clipboard, and it will all stream down for you.

Hit Ctrl-D. You'll get the prompt back.

Open that file in Vim, XEmacs, Nano or some other editor. Now look at this page, while you And find where the ebuild begins. Cut all, including the first

[ code]

Leave all the way until the

[ /code]

Cut all after that line, after the ending of what you see in the page. Save it. That is the ebuild..

And likewise, for the signature. except, paste it like above, into the file mutt-1.5.23-r10.ebuild.sig instead.

# gpp --verify mutt-1.5.23-r10.ebuild.sig

will tell you my key. Go get it (see wiki.gentoo.org), and use it only if signature good.

If some senior Gentooers strongly believe that I should post it in the bug report that I opened, I can do it, as soon as I can, and if needed, replace it in here with just a link.

And, just to mention, if all this is too complex for you, maybe you can more easily follow the shorter tip by jonathan183:
https://forums.gentoo.org/viewtopic-t-1002146-start-25.html#7642848

Cheers.

miroR
l33t
l33t

Joined: 05 Mar 2008
Posts: 826

Posted: Tue Dec 02, 2014 3:21 am Post subject:

Just replied to dev Fabian Groffen on this issue: https://bugs.gentoo.org/show_bug.cgi?id=527338#c7

miroR
l33t
l33t

Joined: 05 Mar 2008
Posts: 826

Posted: Tue Dec 02, 2014 11:45 am Post subject:

Just corrected:

https://wiki.gentoo.org/wiki/Overlay/Local_overlay

All I did was, open the edit page and, cat'ed it into new file Gen_141202_Layman_WIKI.txt (as explained two posts above for my ebuild), and then:

Code:

$ sed -i.bak 's/\/usr\/local\/portage/\/var\/lib\/layman/' Gen_141202_Layman_WIKI.txt

EDIT Tue 2 Dec 14:34:21, and 15:06:19, CET 2014: there was a superfluous Gen_141202_Layman_WIKI.txt.bak in the sed line above, and was missing in the diff line below.

Checked what I got with:

Code:

$ diff Gen_141202_Layman_WIKI.txt Gen_141202_Layman_WIKI.txt.bak
$ cat Gen_141202_Layman_WIKI.txt | grep usr
$ cat Gen_141202_Layman_WIKI.txt | grep var

and pasted my new edit Gen_141202_Layman_WIKI.txt back, previewed it and saved it.

( All this explaining for hopefully our newbies to grow more quickly ;-)

)

And if some senior finds something still lacking, tell us!

Last edited by miroR on Tue Dec 02, 2014 2:07 pm; edited 2 times in total

khayyam
Watchman

Joined: 07 Jun 2012
Posts: 6227
Location: Room 101

Posted: Tue Dec 02, 2014 12:51 pm Post subject:

miroR wrote:

Just corrected:

miro ... no, you didn't. Besides the fact that the method/namespace we currently use is inherently broken a "local" overlay does not belong under /var/lib/layman and the originaly provided /usr/local/portage in the wiki is at least seperated from "layman" managed overlays. Your "corrected" namespace will look the following:

/var/lib/layman/overlayA
/var/lib/layman/overlayB
/var/lib/layman/overlayC
/var/lib/layman/<category>/<package>
/var/lib/layman/profiles
/var/lib/layman/metadata/

So, I'm not sure why you think that "/var/lib/layman [...] is the default since long" but your correction just adds to what is a confused namespace ... I suggest you revert the change.

best ... khay

miroR
l33t
l33t

Joined: 05 Mar 2008
Posts: 826

Posted: Tue Dec 02, 2014 2:05 pm Post subject:

khayyam wrote:

miroR wrote:

Just corrected:

miro ... no, you didn't.
...[snip]...

I'm not sure my correction, or "correction", is worse than what was before.

If we do:

Code:

# equery f layman

and see that it ends the listing of the files installed with:

Code:

/var
/var/lib
/var/lib/layman
/var/lib/layman/.keep_app-portage_layman-0

and that:

Code:

# equery f layman | grep '\/usr\/local'

or not even:

Code:

# equery f layman | grep 'local'

gives any founds back.

And, on my air-gapped it works perfect.

khayyam wrote:

Besides the fact that the method/namespace we currently use is inherently broken a "local" overlay does not belong under /var/lib/layman and the originaly provided /usr/local/portage in the wiki is at least seperated from "layman" managed overlays.

Hmmh... You might be right in part...

khayyam wrote:

Your "corrected" namespace will look the following:
/var/lib/layman/overlayA
/var/lib/layman/overlayB
/var/lib/layman/overlayC
/var/lib/layman/<category>/<package>
/var/lib/layman/profiles
/var/lib/layman/metadata/

and that:

Quote:

/var/lib/layman/<category>/<package>

sure would be misplaced. However, how come the emerge found my ebuild and installed it just fine?
I don't have any overlays currently, since I haven't found yet a way to download them away from my air-gapped master machine, copy them over securely, and only then install them, which is a related issue that itches me very much... But that aside...

But that aside, I don't think that reverting would solve this puzzle:

Quote:

(for layman 1.1)
# echo "source /usr/portage/local/layman/make.conf" >> /etc/portage/make.conf

(for layman 1.2)
# echo "source /usr/local/portage/layman/make.conf" >> /etc/portage/make.conf

(for layman 1.3 and later)
# echo "source /var/lib/layman/make.conf" >> /etc/portage/make.conf

and that is from:
Gentoo Overlays: Users' Guide
http://www.gentoo.org/proj/en/overlays/userguide.xml

So neither is my correction completely wrong, not is...

khayyam wrote:

So, I'm not sure why you think that "/var/lib/layman [...] is the default since long" but your correction just adds to what is a confused namespace ... I suggest you revert the change.

best ... khay

[Nor is] your suggestion to revert the change the best thing to do either.

You are higher in the hierarchy, and if you insist, you can revert the change that I made, I would object to it, but will not fight it.

I'm afraid, if you revert it back, the Gentoo Overlays: Users' Guide on www.gentoo.org and the Overlay/Local overlay guide on Wiki will continue to contain confusing information.

I agree that I have not done completely right from the point of users who want to use other overlays (including me, when I solve my itch above).

So maybe, create:

Code:

mkdir -p /var/lib/layman/miro

and place the ebuilds there?

I haven't yet figured it out...

Code:

# cd /var/lib/layman/miro/
# mv -iv /var/lib/layman/mail-client/ /var/lib/layman/miro/

And I got the error upon:

Code:

# cd /var/lib/layman/miro/mail-client/
# repoman manifest
repoman: miro is not an official category. Skipping QA checks in this directory.
Please ensure that you add miro to /var/lib/layman/profiles/categories
if it is a new category.
#

What should be done. Reverting, again, is against the layman 1.3 suggestion in Guide in the www.gentoo.org.

This, what I did previously, works, as I posted it, and is in agreement with the Guide in the www.gentoo.org, but surely is very imperfect.

So, I don't know what to do... I do think this the Overlay wiki page is better now than before though, so I won't revert it. You do, if you insist.

steveL
Watchman

Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

Posted: Tue Dec 02, 2014 2:23 pm Post subject:

miroR wrote:

I'm not sure my correction, or "correction", is worse than what was before.

Yes it is.

Fix your own mistake.

I can't believe you've been a member here since 2008.

khayyam
Watchman

Joined: 07 Jun 2012
Posts: 6227
Location: Room 101

Posted: Tue Dec 02, 2014 4:39 pm Post subject:

miroR wrote:

I'm not sure my correction, or "correction", is worse than what was before.

miro ... it is in that /usr/local/portage (or whatever, and wherever, the "local" overlay is) and /var/lib/layman historically co-exist, and */layman (as the name suggests) is where *layman* installs its overlays. By changing the wiki you're suggesting that */layman is where the "local" overlay *should* be ... which isn't the case. You're welcome to keep it under */layman if you so please, but its wrong to suggest that this is somehow the correct location and that "*/layman [...] is the default since long".

[SNIP lots of irrelevant, and repetitive, code/stuffs]

Your basic intuition that these directories *should* be somehow grouped together is correct, which is why I mention the current namespace is "inherently broken", but that's besides the point. If it were somehow logical then we would have something like the following:

/top/level/path/gentoo <= the "gentoo" repo (erroneously called "portage")
/top/level/path/local <= the "local" overlay (its default name/location)
/top/level/path/overlayA <= layman installed/managed overlay
/top/level/path/overlayB <= layman installed/managed overlay
/top/level/path/overlayC <= layman installed/managed overlay
/top/level/path/mips-unknown-linux-uclibc <= CROSSDEV_OVERLAY for mips-*-linux-uclib
/path/to/distfiles <= seperate from main "gentoo" repo
/path/to/packages <= seperate from main "gentoo" repo

... such would make more sense and many of the methods currently implemented, such as layman sourcing '/var/lib/layman/make.conf', make.conf variables, and the various methods used by crossdev to "guess" the overlay it should dump ebuilds into, would be greatly simplified ... but such as things are.

best ... khay

Last edited by khayyam on Tue Dec 02, 2014 4:41 pm; edited 1 time in total

py-ro
Veteran
Veteran

Joined: 24 Sep 2002
Posts: 1734
Location: Velbert

Posted: Tue Dec 02, 2014 4:40 pm Post subject:

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

Display posts from previous:

	Gentoo Forums Forum Index Unsupported Software	All times are GMT Goto page Previous 1, 2, 3 Next
Page 2 of 3

Jump to:

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

Copyright 2001-2024 Gentoo Foundation, Inc. Designed by Kyle Manna © 2003; Style derived from original subSilver theme. | Hosting by Gossamer Threads Inc. © | Powered by phpBB 2.0.23-gentoo-p11 © 2001, 2002 phpBB Group
Privacy Policy