Re: [gentoo-dev] New package neomutt

[Nicolas Bock]

On Mon, Jul 31, 2017 at 09:11:19AM +0200, Nicolas Bock wrote:

Hi,

I would like to add neomutt to the tree. This new package is meant as 
an alternative and not a replacement of the existing mutt package.


Thanks for all of the great suggestions and feedback!

This is round two. I have update the ebuild with all your 
suggestions. I have also added support for eselecting between mutt 
and neomutt. Before the eselect ebuild can land though, we need to 
rename the mutt binary so that the managed link can be called 
mutt.



# Copyright 1999-2017 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2

EAPI=6

inherit autotools eutils flag-o-matic

if [[ ${PV} ==  ]] ; then
# live ebuild
inherit git-r3
EGIT_REPO_URI="https://github.com/neomutt/neomutt.git;
EGIT_CHECKOUT_DIR="${WORKDIR}/neomutt-${P}"
KEYWORDS=""
else
SRC_URI="https://github.com/${PN}/${PN}/archive/${P}.tar.gz;
KEYWORDS="~amd64 ~x86"
fi

DESCRIPTION="Teaching an Old Dog New Tricks"
HOMEPAGE="https://www.neomutt.org/;

LICENSE="GPL-2"
SLOT="0"
IUSE="berkdb crypt debug doc gdbm gnutls gpg idn kerberos libressl mbox
nls notmuch qdbm sasl selinux slang smime ssl tokyocabinet kyotocabinet
lmdb"

CDEPEND="
app-eselect/eselect-mutt
app-misc/mime-types
nls? ( virtual/libintl )
tokyocabinet?  ( dev-db/tokyocabinet )
qdbm?  ( dev-db/qdbm )
gdbm?  ( sys-libs/gdbm )
berkdb? ( >=sys-libs/db-4:= )
kyotocabinet? ( dev-db/kyotocabinet )
lmdb? ( dev-db/lmdb )
gnutls?  ( >=net-libs/gnutls-1.0.17 )
!gnutls? (
ssl? (
!libressl? ( >=dev-libs/openssl-0.9.6:0 )
libressl? ( dev-libs/libressl )
)
)
sasl?( >=dev-libs/cyrus-sasl-2 )
kerberos? ( virtual/krb5 )
idn? ( net-dns/libidn )
gpg? ( >=app-crypt/gpgme-0.9.0 )
smime?   (
!libressl? ( >=dev-libs/openssl-0.9.6:0 )
libressl? ( dev-libs/libressl )
)
notmuch? ( net-mail/notmuch )
slang? ( sys-libs/slang )
!slang? ( >=sys-libs/ncurses-5.2:0 )
"
DEPEND="${CDEPEND}
net-mail/mailbase
doc? (
dev-libs/libxml2
dev-libs/libxslt
app-text/docbook-xsl-stylesheets
|| ( www-client/lynx www-client/w3m www-client/elinks )
)"
RDEPEND="${CDEPEND}
selinux? ( sec-policy/selinux-mutt )
"

S="${WORKDIR}/${PN}-${P}"

src_prepare() {
eapply "${FILESDIR}/0001-Rename-mutt-to-neomutt.patch"
eapply_user
AT_M4DIR="m4" eautoreconf
}

src_configure() {
local myconf=(
"$(use_enable crypt pgp)"
"$(use_enable debug)"
"$(use_enable doc)"
"$(use_enable gpg gpgme)"
"$(use_enable nls)"
"$(use_enable smime)"
"$(use_enable notmuch)"
"$(use_with idn)"
"$(use_with kerberos gss)"
"$(use_with sasl)"
"$(use_with tokyocabinet)"
"$(use_with kyotocabinet)"
"$(use_with qdbm)"
"$(use_with gdbm)"
"$(use_with berkdb bdb)"
"$(use_with lmdb)"
"--with-$(use slang && echo slang || echo 
curses)=${EPREFIX}/usr"
"--sysconfdir=${EPREFIX}/etc/${PN}"
"--with-docdir=${EPREFIX}/usr/share/doc/${PN}-${PVR}"
)

if [[ ${CHOST} == *-solaris* ]] ; then
# arrows in index view do not show when using wchar_t
myconf+=( "--without-wc-funcs" )
fi

# there's no need for gnutls, ssl or sasl without socket support
if use gnutls; then
myconf+=( "--with-gnutls" )
elif use ssl; then
myconf+=( "--with-ssl" )
fi

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

econf "${myconf[@]}"
}

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

# A newer file is provided by app-misc/mime-types. So we link it.
rm "${ED}"/etc/${PN}/mime.types || die
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
# make the fake slightly better, bug #413405
sed -e 's#@docdir@/manual.txt#http://www.mutt.org/doc/manual/#' 
\
-e 's#in 

Re: [gentoo-dev] New package neomutt

[Nicolas Bock]

On Mon, Jul 31, 2017 at 10:34:53AM +0200, Patrice Clement wrote:

Hi Nicolas

See my comments inline.

Monday 31 Jul 2017 09:23:51, Nicolas Bock wrote :

On Mon, Jul 31, 2017 at 09:11:19AM +0200, Nicolas Bock wrote:
>Hi,
>
>I would like to add neomutt to the tree. This new package is meant as
>an alternative and not a replacement of the existing mutt package.

I should have inlined the patch. Sorry.



From 63f5d569aec514d67645b1c2e891e51810bb7ab5 Mon Sep 17 00:00:00 2001
From: Nicolas Bock 
Date: Mon, 31 Jul 2017 09:06:07 +0200
Subject: [PATCH] mail-client/neomutt: New package mail-client/neomutt-20170714

Package-Manager: Portage-2.3.6, Repoman-2.3.1
---
 mail-client/neomutt/Manifest|   1 +
 mail-client/neomutt/metadata.xml|  24 +
 mail-client/neomutt/neomutt-20170714.ebuild | 161 
 3 files changed, 186 insertions(+)
 create mode 100644 mail-client/neomutt/Manifest
 create mode 100644 mail-client/neomutt/metadata.xml
 create mode 100644 mail-client/neomutt/neomutt-20170714.ebuild

diff --git a/mail-client/neomutt/Manifest b/mail-client/neomutt/Manifest
new file mode 100644
index 000..2b38484e24d
--- /dev/null
+++ b/mail-client/neomutt/Manifest
@@ -0,0 +1 @@
+DIST neomutt-20170714.tar.gz 2509160 SHA256 
40d48920f95ca49ab96eb109b658f5cf6e1c222320c58bdd03769c1355d7a383 SHA512 
eb31d2f23b7211904cd66ba293c008f953778b37f13fd09d4db571d013f1c8e6449fccd827872f3ad0a2c8e62555f92b3f9591a1f0f4ac37ab362a4681abaaa0
 WHIRLPOOL 
455495501a2ab1989d5f3bfa75aa2370896956cdfd7d2e852e225c96aa23a1abdaf2dbb9d886d1d96486d19b2b38c225e8263f268ebafcef8cbd0024885189f3
diff --git a/mail-client/neomutt/metadata.xml b/mail-client/neomutt/metadata.xml
new file mode 100644
index 000..081f253b3a1
--- /dev/null
+++ b/mail-client/neomutt/metadata.xml
@@ -0,0 +1,24 @@
+
+http://www.gentoo.org/dtd/metadata.dtd;>
+
+   
+   nicolasb...@gentoo.org
+   Nicolas Bock
+   
+   
+   net-m...@gentoo.org
+   Net-Mail
+   
+   
+   Enable support for 
app-crypt/gpgme
+   Enable support for 
net-mail/notmuch
+   Enable support for S/MIME
+   Enable dev-db/tokyocabinet
+   database backend for header caching
+   
+   
+   
+   
+   neomutt/neomutt
+   
+
diff --git a/mail-client/neomutt/neomutt-20170714.ebuild 
b/mail-client/neomutt/neomutt-20170714.ebuild
new file mode 100644
index 000..9bcf72e7479
--- /dev/null
+++ b/mail-client/neomutt/neomutt-20170714.ebuild
@@ -0,0 +1,161 @@
+# Copyright 1999-2017 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+# $Id$
+
+EAPI=6
+
+inherit autotools eutils flag-o-matic
+
+DESCRIPTION="A small but very powerful text-based mail client"
+HOMEPAGE="https://www.neomutt.org/;
+SRC_URI="https://github.com/${PN}/${PN}/archive/${P}.tar.gz;
+
+LICENSE="GPL-2"
+SLOT="0"
+KEYWORDS="~amd64 ~x86"
+IUSE="berkdb crypt debug doc gdbm gnutls gpg idn kerberos libressl mbox nls
+   notmuch qdbm sasl selinux slang smime ssl tokyocabinet vanilla"
+
+CDEPEND="
+   !mail-client/mutt
+   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:= ) )
+   )
+   )
+   gnutls?  ( >=net-libs/gnutls-1.0.17 )
+   !gnutls? (
+   ssl? (
+   !libressl? ( >=dev-libs/openssl-0.9.6:0 )
+   libressl? ( dev-libs/libressl )
+   )
+   )
+   sasl?( >=dev-libs/cyrus-sasl-2 )
+   kerberos? ( virtual/krb5 )
+   idn? ( net-dns/libidn )
+   gpg? ( >=app-crypt/gpgme-0.9.0 )
+   smime?   (
+   !libressl? ( >=dev-libs/openssl-0.9.6:0 )
+   libressl? ( dev-libs/libressl )
+   )
+   notmuch? ( net-mail/notmuch )
+   slang? ( sys-libs/slang )
+   !slang? ( >=sys-libs/ncurses-5.2:0 )
+"
+DEPEND="${CDEPEND}
+   net-mail/mailbase
+   doc? (
+   dev-libs/libxml2
+   dev-libs/libxslt
+   app-text/docbook-xsl-stylesheets
+   || ( www-client/lynx www-client/w3m www-client/elinks )
+   )"
+RDEPEND="${CDEPEND}
+   selinux? ( sec-policy/selinux-mutt )
+"
+
+S="${WORKDIR}/${PN}-${P}"
+
+src_prepare() {
+   eapply_user
+   eautoreconf
+}
+
+src_configure() {
+   local myconf=(
+   "$(use_enable crypt pgp)"
+   "$(use_enable debug)"
+   "$(use_enable doc)"
+   "$(use_enable gpg gpgme)"
+   "$(use_enable nls)"
+   "$(use_enable smime)"
+   "$(use_enable notmuch)"
+   "$(use_with idn)"
+

Re: [gentoo-dev] New package neomutt

[Nicolas Bock]

On Mon, Jul 31, 2017 at 02:15:16PM +0200, Floyd Anderson wrote:

Hi Nicolas,

below just some remarks from me.

On Mo, 31 Jul 09:23:51 +0200
Nicolas Bock  wrote:

On Mon, Jul 31, 2017 at 09:11:19AM +0200, Nicolas Bock wrote:

Hi,

I would like to add neomutt to the tree. This new package is meant 
as an alternative and not a replacement of the existing mutt 
package.


+1 Very nice idea, I appreciate that.


From 63f5d569aec514d67645b1c2e891e51810bb7ab5 Mon Sep 17 00:00:00 2001
From: Nicolas Bock 
Date: Mon, 31 Jul 2017 09:06:07 +0200
Subject: [PATCH] mail-client/neomutt: New package mail-client/neomutt-20170714

Package-Manager: Portage-2.3.6, Repoman-2.3.1
---
mail-client/neomutt/Manifest|   1 +
mail-client/neomutt/metadata.xml|  24 +
mail-client/neomutt/neomutt-20170714.ebuild | 161 
3 files changed, 186 insertions(+)
create mode 100644 mail-client/neomutt/Manifest
create mode 100644 mail-client/neomutt/metadata.xml
create mode 100644 mail-client/neomutt/neomutt-20170714.ebuild

diff --git a/mail-client/neomutt/Manifest b/mail-client/neomutt/Manifest


[…]


diff --git a/mail-client/neomutt/metadata.xml b/mail-client/neomutt/metadata.xml


[…]


diff --git a/mail-client/neomutt/neomutt-20170714.ebuild 
b/mail-client/neomutt/neomutt-20170714.ebuild
new file mode 100644
index 000..9bcf72e7479
--- /dev/null
+++ b/mail-client/neomutt/neomutt-20170714.ebuild
@@ -0,0 +1,161 @@
+# Copyright 1999-2017 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+# $Id$


Drop $Id$ per council decision in bug #611234.

[1] 


Fixed.


+
+EAPI=6
+
+inherit autotools eutils flag-o-matic
+
+DESCRIPTION="A small but very powerful text-based mail client"


Why not assimilate upstream (NeoMutt) motto? Mutt upstream has no objects on
this, see [2].

[2] 


I'll change it. The new motto is pretty funny :)


+HOMEPAGE="https://www.neomutt.org/;
+SRC_URI="https://github.com/${PN}/${PN}/archive/${P}.tar.gz;
+
+LICENSE="GPL-2"
+SLOT="0"
+KEYWORDS="~amd64 ~x86"
+IUSE="berkdb crypt debug doc gdbm gnutls gpg idn kerberos libressl mbox nls
+   notmuch qdbm sasl selinux slang smime ssl tokyocabinet vanilla"
+


[…]


+
+src_install() {
+   emake DESTDIR="${D}" install || die "install failed"
+   if use mbox; then
+   insinto /etc/neomutt
+   newins "${FILESDIR}"/Muttrc.mbox Muttrc
+   else
+   insinto /etc/neomutt
+   doins "${FILESDIR}"/Muttrc
+   fi
+
+   # 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/muttrc.man muttrc.5
+   doman mutt.1 muttrc.5
+   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

The *devel* manual is located here [3] and release manual here [4].

[3] 
[4] 


Fixed.


+
+   dodoc COPYRIGHT ChangeLog.md OPS* README*
+}
--
2.13.0


--
Nicolas Bock 


In the end it would be nice if Lua would also be integrated.


I'll have a look at it.


In the case you haven’t noticed that, have a look at [5]. But note the link [6]
for the faked manual page is dead if you consider to use this one. Also it
seems the documentation will be restructured in the future [7][8].


Thanks!


[5] 
[6] 
[7] 

[8] 


--
Regards,
floyd




--
Nicolas Bock 


signature.asc
Description: PGP signature

Re: [gentoo-dev] Prevent binary/non-compiled packages from binary package creation

[Sam Jorna (wraeth)]

On 10/08/17 11:42, William L. Thomson Jr. wrote:
> On Thu, 10 Aug 2017 10:50:45 +1000
> "Sam Jorna (wraeth)"  wrote:
> 
>> On 10/08/17 06:35, William L. Thomson Jr. wrote:
>>> FYI binpkgs have no hash. If someone did something malicious within
>>> the binhost to the binpkgs. You have no way of knowing. Yes the
>>> same can happen with ebuilds and manifest. But easy to sync portage
>>> and see if a manifest has changed.  
>>
>> This isn't exactly true - see ${PKGDIR}/Packages on the binhost, which
>> is a manifest of built packages and related metadata. Granted this is
>> created by the binhost, it does exist and contains SHA1 and MD5
>> hashes, as well as package size. In that sense it's no different to
>> how a package Manifest file works within a repository.
> 
> You are correct. I meant to say no verifiable hash. You can hash
> anything locally and claim it to be trustworthy. Thus mentioning
> syncing portage to compare manifest of ebuild/SRC_URI
> IMHO SRI_URI is more trustworthy than binhost, in the sense of
> verification. If  you have means to verify the binhost stuff it maybe
> more trustworthy. That is left to the admin.

This is no greater risk than syncing from a potentially compromised
mirror. You would use a mirror you trust and, similarly (perhaps even
more so) you would use a binhost you trust.

It does raise the idea of some form of signing of the Packages file,
similar to gpg-signed portage snapshots, but that's moving well beyond
the scope of this thread.

-- 
Sam Jorna (wraeth)
GnuPG ID: D6180C26



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Prevent binary/non-compiled packages from binary package creation

[Sam Jorna (wraeth)]

On 10/08/17 11:47, William L. Thomson Jr. wrote:
> On Thu, 10 Aug 2017 11:25:34 +1000
> "Sam Jorna (wraeth)"  wrote:
> 
>> On 09/08/17 10:43, William L. Thomson Jr. wrote:
>>> Also your redistributing another's package
>>> in binary format which may not be legally allowed.  
>>
>> Just to clarify, I wasn't suggesting redistributing license-encumbered
>> packages. Since binary packages are managed by the system
>> administrator, not Gentoo (as a distro), it remains with the
>> administrator to adhere to any relevant license restrictions. Plus
>> the package manager can't tell if you're distributing binaries or not.
> 
> Sure, I was just pointing out that there maybe legal needs to prevent
> such. Unless someone wants to circumvent. Their call but not default.
> 
> The package manager knows about fetch restricted ebuilds. It should
> not to re-package that stuff. IMHO

Packaging a binary is not redistributing. Building binpkgs does not mean
you're going to redistribute them, and even if you were, the package
manager has no way of determining that aside from an
--im-going-to-redist-this-package option.

-- 
Sam Jorna (wraeth)
GnuPG ID: D6180C26



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Prevent binary/non-compiled packages from binary package creation

[William L. Thomson Jr.]

On Thu, 10 Aug 2017 11:25:34 +1000
"Sam Jorna (wraeth)"  wrote:

> On 09/08/17 10:43, William L. Thomson Jr. wrote:
> > Also your redistributing another's package
> > in binary format which may not be legally allowed.  
> 
> Just to clarify, I wasn't suggesting redistributing license-encumbered
> packages. Since binary packages are managed by the system
> administrator, not Gentoo (as a distro), it remains with the
> administrator to adhere to any relevant license restrictions. Plus
> the package manager can't tell if you're distributing binaries or not.

Sure, I was just pointing out that there maybe legal needs to prevent
such. Unless someone wants to circumvent. Their call but not default.

The package manager knows about fetch restricted ebuilds. It should
not to re-package that stuff. IMHO

-- 
William L. Thomson Jr.


pgpfMvLJegYBY.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Prevent binary/non-compiled packages from binary package creation

[William L. Thomson Jr.]

On Thu, 10 Aug 2017 10:50:45 +1000
"Sam Jorna (wraeth)"  wrote:

> On 10/08/17 06:35, William L. Thomson Jr. wrote:
> > FYI binpkgs have no hash. If someone did something malicious within
> > the binhost to the binpkgs. You have no way of knowing. Yes the
> > same can happen with ebuilds and manifest. But easy to sync portage
> > and see if a manifest has changed.  
> 
> This isn't exactly true - see ${PKGDIR}/Packages on the binhost, which
> is a manifest of built packages and related metadata. Granted this is
> created by the binhost, it does exist and contains SHA1 and MD5
> hashes, as well as package size. In that sense it's no different to
> how a package Manifest file works within a repository.

You are correct. I meant to say no verifiable hash. You can hash
anything locally and claim it to be trustworthy. Thus mentioning
syncing portage to compare manifest of ebuild/SRC_URI.

Someone remakes a binpkg tarball, edits ${PKGDIR}/Packages with new
SHA1 and MD5. No way to know.

IMHO SRI_URI is more trustworthy than binhost, in the sense of
verification. If  you have means to verify the binhost stuff it maybe
more trustworthy. That is left to the admin.

I see binpkg as a temporary convenience. I am doing updates across many
of the same systems. Less images, containers, etc. I made binaries on
one system. Immediately used as updated on others. Then discarded on
binhost. Also used for  testing, reverting between slotted versions.

-- 
William L. Thomson Jr.


pgpo6yopgjta1.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Prevent binary/non-compiled packages from binary package creation

[Sam Jorna (wraeth)]

On 09/08/17 10:43, William L. Thomson Jr. wrote:
> Also your redistributing another's package
> in binary format which may not be legally allowed.

Just to clarify, I wasn't suggesting redistributing license-encumbered
packages. Since binary packages are managed by the system administrator,
not Gentoo (as a distro), it remains with the administrator to adhere to
any relevant license restrictions. Plus the package manager can't tell
if you're distributing binaries or not.

-- 
Sam Jorna (wraeth)
GnuPG ID: D6180C26



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Handbook Improvements

[R0b0t1]

Hello,

I am not a developer, but most of the discussion pertaining to the
handbook that has happened on user-oriented discussion forums has
never resulted in any changes.

Due to lack of recent inspiration, I have reproduced some of my
comments on a thread in gentoo-user below.

On Fri, Jul 28, 2017 at 8:44 PM, R0b0t1  wrote:
>
> Not to get away from OP's question, but how good would the installer
> need to be before it held the interest of any developers that manage
> the website or handbook?
>
> I ask because the much simpler thing I suggested - fleshing out the
> handbook - has been done and redone by some individuals and some of
> the guides are truly inspired. Unfortunately, I think it keeps being
> redone because these guides are hard to find and because the people
> who make them have no way to contribute to the handbook.
>
> Sakaki's EFI install guide, while very specific, is something that the
> majority of people who want to use Linux but don't want to maintain
> Portage seem to expect from the handbook. It actually tells them how
> to configure most of the things that produce a modern x86 system that
> interacts with a user. I mention it because it is the only guide I'm
> aware of that has persisted long enough to be indexed by Google that
> is also still relevant.
>
> The problem most people seem to have with Gentoo is not necessarily
> the installation process, but knowing what to configure after they
> have it installed.

I hope that serves as justification for the following proposals:

1) Migrate the Wiki to gollum (https://github.com/gollum/gollum) which
would permit the management of the Wiki using Git and optionally pull
requests. Gollum is typically used with Markdown, though all current
articles could exported without being rewritten. Gollum is written in
Ruby and is used by GitHub.
2) If developer or user support is available, allow the addition of
architecture and device specific sections to the handbook. As it is,
the handbook mostly contains generic "extract the stage 3 tarball"
instructions for most architectures. Creating links to landing pages
that list various popular devices or installation scenarios inside the
handbook would help users by centralizing installation guides.
3) Since this documentation would be more closely associated with the
project, create some rough guidelines for content submissions.

R0b0t1.

Re: [gentoo-dev] Prevent binary/non-compiled packages from binary package creation

[Sam Jorna (wraeth)]

On 10/08/17 06:35, William L. Thomson Jr. wrote:
> FYI binpkgs have no hash. If someone did something malicious within the
> binhost to the binpkgs. You have no way of knowing. Yes the same can
> happen with ebuilds and manifest. But easy to sync portage and see if a
> manifest has changed.

This isn't exactly true - see ${PKGDIR}/Packages on the binhost, which
is a manifest of built packages and related metadata. Granted this is
created by the binhost, it does exist and contains SHA1 and MD5 hashes,
as well as package size. In that sense it's no different to how a
package Manifest file works within a repository.

-- 
Sam Jorna (wraeth)
GnuPG ID: D6180C26



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] toolchain team lead election and team meeting

[Andreas K. Huettel]

Hey there, 

it's time we do a proper lead election and have a toolchain meeting again. 

So, here's the plan:

1) team lead election:
* Nominations from now until August 18, by e-mailing to the toolchain alias
* Voting (Helios) August 19-25
I'm volunteering as organizer, since I won't run myself.

2) team meeting:
how about Saturday 26 August, 19:00 UTC ?!

Cheers, 
Andreas


-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer (council, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Prevent binary/non-compiled packages from binary package creation

[William L. Thomson Jr.]

Just to clarify, the contenders for no binpkg would be the
following, potentially more.

 - ebuilds that are fetch restricted
 - ebuilds that installs files unchanged, like kernel sources
 - Binary ebuilds, -bin, that just use src_install and do not build
   anything

There may be some other cases, but I think that covers the main ones.
The first case, should NEVER, not even optionally be allowed to be
binpkg. That is re-distributing something that is fetch restricted. If
it cannot be mirrored, I doubt it can legally be  re-packaged.

The later 2 could be "optional" defaulted to not build, but could be
forced. There is little benefit at that point but some may prefer those
be a binpkg.

I have no problem with it being optional.

-- 
William L. Thomson Jr.


pgpZrNRHTl9GN.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Prevent binary/non-compiled packages from binary package creation

[William L. Thomson Jr.]

On Wed, 9 Aug 2017 22:23:41 +0200
Francesco Riosa  wrote:

> 2017-08-09 17:33 GMT+02:00 William L. Thomson Jr. :
> 
> > On Wed, 9 Aug 2017 11:07:04 +1000
> > "Sam Jorna (wraeth)"  wrote:
> >
> > > > What then is the benefit? If what is installed is the same from
> > > > package manager or binpkg. Also your redistributing another's
> > > > package in binary format which may not be legally allowed.
> > >
> > > The difference is that how the package manager/ebuild installs the
> > > package may be better suited to the environment than what upstream
> > > expects (such as upstreams that install through a .run file)
> >
> > I fail to see how basically skipping src_install and maybe some
> > prepare stuff that makes it better suited to an environment.
> > Can you explain that further?
> >
> > These packages are just exploded tarballs. I fail to see the benefit
> > to repacking those into another tarball to be exploded. At best
> > skipping src_install and/or prepare, seems to be the only
> > difference.
> >
> one such benefit is that the binhost is known and managed by someone
> you trust, SRC_URI point to the wider and dangerous internet.

Interesting argument, saying upstreams cannot be trusted. Nor Gentoo
with its manifests and hashes of the files referenced in SRC_URI. Given
that most will come from Gentoo mirrors not upstream servers. Ignoring
that the binhost has to use these SRC_URI's just the same. It makes
sense in very strange way.

FYI binpkgs have no hash. If someone did something malicious within the
binhost to the binpkgs. You have no way of knowing. Yes the same can
happen with ebuilds and manifest. But easy to sync portage and see if a
manifest has changed.

Therefore relying on binhost as means of security is possible but odd,
as it leaves things open to potentially larger issues.

> So please leave this as a configurable choice.

For some things configurable would make sense. For things like fetch
restricted, it would not. Since it is not legal to mirror that stuff to
begin with. It surely is not to re-package.

-- 
William L. Thomson Jr.


pgp_OCWY10rTw.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Prevent binary/non-compiled packages from binary package creation

[Francesco Riosa]

2017-08-09 17:33 GMT+02:00 William L. Thomson Jr. :

> On Wed, 9 Aug 2017 11:07:04 +1000
> "Sam Jorna (wraeth)"  wrote:
>
> > > What then is the benefit? If what is installed is the same from
> > > package manager or binpkg. Also your redistributing another's
> > > package in binary format which may not be legally allowed.
> >
> > The difference is that how the package manager/ebuild installs the
> > package may be better suited to the environment than what upstream
> > expects (such as upstreams that install through a .run file)
>
> I fail to see how basically skipping src_install and maybe some prepare
> stuff that makes it better suited to an environment.
> Can you explain that further?
>
> These packages are just exploded tarballs. I fail to see the benefit
> to repacking those into another tarball to be exploded. At best
> skipping src_install and/or prepare, seems to be the only difference.
>

one such benefit is that the binhost is known and managed by someone you
trust, SRC_URI point to the wider and dangerous internet.
So please leave this as a configurable choice.


>
> I see no difference in installing kernel sources via source ebuild or a
> binpkg, pre-built ebuild binary. Other than the time it takes to
> re-package the kernel sources into another tarball.
>
>
> --
> William L. Thomson Jr.
>

Re: [gentoo-dev] Packages up for grabs

[Nelo-Thara Wallus]

On 2017-08-08 13:05, Amy Liffey wrote:
> Hello,
> The following packages are up for grabs:
>
>   x11-wm/afterstep
>   mail-client/nmh
>   dev-util/wsta
>   dev-util/bats
>   app-admin/yadm
>
> Best regards,
> Amy Liffey
>

I'll take dev-util/bats, my proxy is my mentor polynomial-c.

Cheers,
Nelo

--
/"\  ASCII Ribbon Campaign
\ /  - against HTML emails
 X   - against proprietory attachments
/ \  http://en.wikipedia.org/wiki/ASCII_Ribbon_Campaign

Re: [gentoo-dev] Prevent binary/non-compiled packages from binary package creation

[William L. Thomson Jr.]

On Wed, 9 Aug 2017 11:07:04 +1000
"Sam Jorna (wraeth)"  wrote:

> > What then is the benefit? If what is installed is the same from
> > package manager or binpkg. Also your redistributing another's
> > package in binary format which may not be legally allowed.  
> 
> The difference is that how the package manager/ebuild installs the
> package may be better suited to the environment than what upstream
> expects (such as upstreams that install through a .run file)

I fail to see how basically skipping src_install and maybe some prepare
stuff that makes it better suited to an environment.
Can you explain that further?

These packages are just exploded tarballs. I fail to see the benefit
to repacking those into another tarball to be exploded. At best
skipping src_install and/or prepare, seems to be the only difference.

I see no difference in installing kernel sources via source ebuild or a
binpkg, pre-built ebuild binary. Other than the time it takes to
re-package the kernel sources into another tarball.


-- 
William L. Thomson Jr.


pgprjYBDQKsdt.pgp
Description: OpenPGP digital signature