Re: [gentoo-dev] Re: [PATCH 3/5] xdg.eclass: move deps to RDEPEND
On Mon, Oct 01, 2018 at 10:08:03AM -0400, Mike Gilbert wrote:
> On Mon, Oct 1, 2018 at 9:17 AM James Le Cuirot wrote:
> >
> > On Mon, 1 Oct 2018 09:00:38 -0400
> > Mike Gilbert wrote:
> >
> > > > The reason why it is in DEPEND though is that none of these tools
> > > > are required at runtime. They are needed at postinst and postrm
> > > > stages which afaik makes them DEPEND on EAPI previous to EAPI 7 and
> > > > BDEPEND in EAPI 7 if I'm not mistaken.
> > >
> > > This is incorrect; programs executed in pkg_postinst/pkg_postrm should
> > > be present in RDEPEND. Consider a binpkg installation, which would
> > > ignore DEPEND, but would still execute pkg_postinst.
> > >
> > > Another option: since xdg-utils.eclass functions will politely skip
> > > the updates if the tools are missing, we could just drop the
> > > dependency from xdg.eclass entirely and wait for the tools to get
> > > installed through some indirect means.
> >
> > Unfortunately there is no correct answer here as we didn't consider
> > this scenario when planning EAPI 7. We should have looked at Exherbo,
> > which does make this important distinction. There is a bug report open.
> >
> > https://bugs.gentoo.org/660306
> >
> > What I will say is that we should not attempt to executing anything
> > from within ROOT or SYSROOT unless it known to be interpreted
> > (e.g. a shell script) and there is no feasible alternative. I add that
> > exclusion clause because I have been forced to do this with
> > python-config.
>
> That's a good point; both update-desktop-database and
> update-mime-database are compiled binaries, and should probably be
> executed from BROOT (/) instead. I'll revise my patchset.
>
Not to steal the show/etc, but I do have a patchset which does most of
this already across {gnome2,xdg}{,-utils}.eclass, though I'm as
conflicted as you guys are with regards to the DEPEND/PDEPEND/BDEPEND/RDPEND
for it as well.
https://archives.gentoo.org/gentoo-dev/message/e0167edbb7b48b03dc90bfbb250ae16d
[gentoo-dev] Introducing SharkBait: Gentoo GSoC 2018 project to manage Android with Portage
Dear all, I'm Pengcheng Xu, one of the participants in Gentoo Google Summer of Code 2018, with Benda (heroxbd) Xu as my mentor. I've been working on the project SharkBait [1] (previously known as Portage-powered Android), which aims to manage the build and update process of Android systems with Portage. Development details can be found on my personal blog [2]. I've recently delivered a talk on the Software Freedom Day event at Tsinghua University, China on September 22nd about the SharkBait project. The talk slides are attached and should serve as a concise introduction. We've finished booting Android in LXC while having OpenRC as the service manager for the rest of the system. Work to build Android components with Portage has started, and we have successfully built bionic (Android's libc) with Portage on amd64, but there are a few issues left on ARM. If you're interested, follow the porting guide at [3] to get started with your Android device. The slides contain a slightly more detailed overview of porting a device, while the wiki page holds all the details to get a port up and running. We're planning to implement an eclass for Soong, the AOSP build system, and develop mechanisms to automatically convert Soong metadata to ebuilds. We may have to figure out how to build Java parts of Android (gradle mostly) elegantly with Portage. In this way, we can achieve the final goal of the project, that is, to manage Android update process with Portage. I've always been looking forward to responses from Gentoo developers, so please tell me what you think about the project as well as questions. Thanks! [1]: https://www.shark-bait.org/ [2]: https://jsteward.moe/ [3]: https://wiki.gentoo.org/wiki/Android/SharkBait/Porter_Guide Sincerely, -- Pengcheng Xu i...@jsteward.moe
[gentoo-dev] libffi-3.3_rc0 is in ~arch
libffi-3.3 is mostly compatible with 3.2.x series. There are a few things to watch out: - SONAME changed to .so.7: libffi ebuilds got SLOT=0/7 You might want to add dependency against that to save a @revdep-rebuild iteration. - There was at least one minor API change in x86_64 supported calling convention list. A few packages might break. See: https://wiki.gentoo.org/wiki/Libffi_3.3_porting_notes/FFI_SYSV We'll gather example fixes at: https://wiki.gentoo.org/wiki/Project:Toolchain#libffi-3.3 Tracker bug: https://bugs.gentoo.org/show_bug.cgi?id=libffi-3.3 Please add newly discovered failures against that bug. I hope to see low amount of failures. All should be easy to fix. If there will be large fallout I'll mask libffi-3.3. -- Sergei
Re: [gentoo-dev] RFC: Portage QA check for FHS/Gentoo policy paths, for top-level dirs and /usr/share/doc
On Mon, 1 Oct 2018 13:48:46 -0700
Zac Medico wrote:
> On 10/01/2018 01:04 PM, Sergei Trofimovich wrote:
> > On Mon, 1 Oct 2018 08:19:29 -0700
> > Zac Medico wrote:
> >
> >> Hi all,
> >>
> >> The ~arch version of portage hs a new QA check that reports installation
> >> of files outside of directories that have been whitelisted [1]. The
> >> current whitelist includes:
> >>
> >> directories common to / and /usr
> >>
> >> bin lib lib32 lib64 libx32 sbin
> >>
> >> top level directories
> >>
> >> boot dev etc opt srv usr var
> >>
> >> /usr level directories
> >>
> >> include libexec share src
> >>
> >> /usr/share/doc level directories
> >>
> >> /usr/share/doc/${PF}
> >
> > As this will break existing ebuilds I'd suggest guarding it against
> > next EAPI. Out of top of by head the change will break at least
> > crossdev outright. At least for two reasons:
> > 1. building a gcc cross-compiler usually refers to $SYSROOT/sys-include.
> >'git grep sys-include' will show a bunch of ebuilds that create that
> >symlinks outside the space.
> > 2. cross-building target libc is currently done on the host's emerge
> > and installs into /usr/$CTARGET/.
> >
> > I think whitelist would be able to cover these use cases as they are
> > a function of ${CTARGET} (or $CATEGORY) value.
>
> The QA check currently does not die, it only calls eqawarn. So the worst
> case is a message like this:
>
> > QA: other
> > The ebuild is installing to one or more unexpected paths:
> >
> > /usr/share/doc/qt-5.11.1
> >
> > Please fix the ebuild to use correct FHS/Gentoo policy paths.
>
> It will be annoying if this message triggers for every package installed
> by crossdev, so we should do something about that.
Ah, QA warning is fine. We'll have some time to address it.
For crossdev it should be only libc packages that do unusual paths
(their initial version is installed into /. We'll fix it like
https://bugs.gentoo.org/642604#c6 but it takes time).
Normal packages should be installed into $SYSROOT proper.
--
Sergei
pgpe6cO_BLQm7.pgp
Description: Цифровая подпись OpenPGP
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: net-libs/libssh2/
On Mon, 2018-10-01 at 23:13 +0200, Jeroen Roovers wrote: > On Mon, 01 Oct 2018 17:00:24 +0200 > Michał Górny wrote: > > > On Mon, 2018-10-01 at 11:46 +, Jeroen Roovers wrote: > > > commit: d866d4705e1e4a092579a31df2815e3407950a19 > > > Author: Jeroen Roovers gentoo org> > > > AuthorDate: Mon Oct 1 11:45:43 2018 + > > > Commit: Jeroen Roovers gentoo org> > > > CommitDate: Mon Oct 1 11:46:10 2018 + > > > URL: > > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d866d470 > > > > > > net-libs/libssh2: Add USE=mbedtls, switch to cmake for building > > > > > > * Add support for net-libs/mbedtls > > > * Switch to cmake as the autotools build is even more broken > > > * Remove USE=static-libs as that inhibits building shared libs > > > * Use REQUIRED_USE to force choosing a crypto backend > > You completely skipped over the improvements. In effect, you show > yourself to be completely unresponsive to what were considered positive > changes to the author of the work. > > Then you begin to pick apart what you think is wrong. It's not obvious > why you are doing it this way, and with regard to practically all > of your earlier e-mails addressed to me, I can only assume malice. I'm sorry but I'm not going to help you if you keep attacking me like this. I have merely pointed out mistakes I've noticed. I did it privately specifically with respect to you. You turn this into some kind of public slandering effort, apparently for no other reason than 'assuming malice'. I'm sorry if you can't see anything good in people. When someone points out an issue with my ebuild, I assume he just wants to have the ebuild improved. But now I learn people do that out of sheer malice. I'm sorry that my comments were not detailed enough. I have wrongly assumed they'd point you in the right direction, and you'd be able to solve those issues with help of eclass documentation. > Someone suggested in an e-mail that "he is just annoyed that you broke > an ebuild that he has spent some time maintaining", but `git shortlog > -- .` would tell you quite a different story. What I think is happening > here is that you think I am "touching your stuff". You have to nitpick > at it instead of just fixing it together and then sending me an update > about the extra work or by pointing out the problems in a more humane > way and leaving me to fix them. That's one way to look at it. The other way is that you're so horribly abrasive that I'm *scared* to touch this ebuild beyond what needs to be absolutely done. That's why I didn't switch it to CMake earlier -- because I presumed you'd attack me again. It seems I wasn't wrong after all. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: net-libs/libssh2/
OK, let's do a full review of your review.
On Mon, 01 Oct 2018 17:00:24 +0200
Michał Górny wrote:
> On Mon, 2018-10-01 at 11:46 +, Jeroen Roovers wrote:
> > commit: d866d4705e1e4a092579a31df2815e3407950a19
> > Author: Jeroen Roovers gentoo org>
> > AuthorDate: Mon Oct 1 11:45:43 2018 +
> > Commit: Jeroen Roovers gentoo org>
> > CommitDate: Mon Oct 1 11:46:10 2018 +
> > URL:
> > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d866d470
> >
> > net-libs/libssh2: Add USE=mbedtls, switch to cmake for building
> >
> > * Add support for net-libs/mbedtls
> > * Switch to cmake as the autotools build is even more broken
> > * Remove USE=static-libs as that inhibits building shared libs
> > * Use REQUIRED_USE to force choosing a crypto backend
You completely skipped over the improvements. In effect, you show
yourself to be completely unresponsive to what were considered positive
changes to the author of the work.
Then you begin to pick apart what you think is wrong. It's not obvious
why you are doing it this way, and with regard to practically all
of your earlier e-mails addressed to me, I can only assume malice.
> So your src_compile() is now broken for Ninja users, and src_test()
> is broken altogether. How about cmake-multilib eclass?
ninja is a thing? Can you explain what it is? Can you show me how it's
broken, and how I reproduce the ninja problem, pro forma by filing a bug
report at https://bugs.gentoo.org/
> > +DESCRIPTION="Library implementing the SSH2 protocol"
> > +HOMEPAGE="https://www.libssh2.org;
> > +SRC_URI="https://www.${PN}.org/download/${P}.tar.gz;
> > +
> > +LICENSE="BSD"
> > +SLOT="0"
> > +KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~mips ~ppc ~ppc64
> > ~s390 ~sh ~sparc ~x86 ~amd64-fbsd ~x86-fbsd ~amd64-linux ~x86-linux
> > ~ppc-macos ~x64-macos ~x86-solaris" +IUSE="gcrypt libressl mbedtls
> > test zlib"
>
> IUSE=test is not used at all.
So that's a minor problem we could fix even without a revision bump.
You could have pointed it out in that missing bug report.
> > +REQUIRED_USE="
> > + ?? ( gcrypt libressl mbedtls )
> > +"
> > +
> > +RDEPEND="
> > + !libressl?
> > ( >=dev-libs/openssl-1.0.1h-r2:0=[${MULTILIB_USEDEP}] )
> > + gcrypt?
> > ( >=dev-libs/libgcrypt-1.5.3:0[${MULTILIB_USEDEP}] )
> > + libressl? ( dev-libs/libressl:0=[${MULTILIB_USEDEP}] )
> > + mbedtls? ( net-libs/mbedtls )
>
> By the way, MULTILIB_USEDEP certainly missing here.
This wants another explanation. How is this different from the ebuild
that went before, -r1? You don't even explain what you think the
problem is. You're not trying to be nice. I have to make an effort
to turn your comment into intelligible English.
MULTILIB_USEDEP *is* missing here? By here you presumably mean
net-libs/mbedtls needs it because that's the line your comment follows?
Right?
So you could have said:
That should be
mbedtls? ( net-libs/mbedtls[MULTILIB_USEDEP] )
> > + zlib? ( >=sys-libs/zlib-1.2.8-r1[${MULTILIB_USEDEP}] )
> > +"
> > +DEPEND="${RDEPEND}"
> > +
> > +PATCHES=(
> > + "${FILESDIR}"/${PN}-1.8.0-libgcrypt-prefix.patch
>
> You sure this autoconf patch is needed for CMake build?
It's harmless. See above. But you also know that it is not needed, but
you're not kindly pointing that out, you're just taking any opportunity
to make a snide comment.
> > + "${FILESDIR}"/${PN}-1.8.0-mansyntax_sh.patch
> > + "${FILESDIR}"/${PN}-1.8.0-openssl11-memleak.patch
> > + "${FILESDIR}"/${PN}-1.8.0-openssl11.patch
> > +)
> > +
> > +multilib_src_configure() {
> > + local crypto_backend=OpenSSL
> > + if use gcrypt; then
> > + crypto_backend=Libgcrypt
> > + elif use mbedtls; then
> > + crypto_backend=mbedTLS
> > + fi
> > +
> > + local mycmakeargs=(
> > + -DBUILD_SHARED_LIBS=ON
> > + -DCRYPTO_BACKEND=${crypto_backend}
> > + -DENABLE_ZLIB_COMPRESSION=$(usex zlib)
> > + )
> > + cmake-utils_src_configure
> > +}
> > +
> > +multilib_src_install_all() {
> > + einstalldocs
> > + find "${D}" -name '*.la' -delete || die
>
> They must have hacked that CMake hard to get it to generate .la files.
So again it's harmless? But you're in snide mode now.
> > + mv "${D}"/usr/share/doc/${PN}/*
> > "${D}"/usr/share/doc/${PF}/ || die
> > + rm -r "${D}"/usr/share/doc/${PN}/ || die
> > +}
> >
> > diff --git a/net-libs/libssh2/metadata.xml
> > b/net-libs/libssh2/metadata.xml index e9e734ab02f..2149f2ed0c6
> > 100644 --- a/net-libs/libssh2/metadata.xml
> > +++ b/net-libs/libssh2/metadata.xml
> > @@ -10,5 +10,7 @@
> >
> >
> > Use dev-libs/libgcrypt
> > instead of dev-libs/openssl
> > + Use dev-libs/libressl
> > instead of dev-libs/openssl
> > + Use net-libs/mbedtls
> > instead of dev-libs/openssl
> >
You're quoting the rest because you agree? Or what? OK, let's go back
to the beginning:
> > net-libs/libssh2: Add USE=mbedtls, switch to cmake for building
> >
> > * Add support for net-libs/mbedtls
> > *
Re: [gentoo-dev] RFC: Portage QA check for FHS/Gentoo policy paths, for top-level dirs and /usr/share/doc
On 10/01/2018 01:04 PM, Sergei Trofimovich wrote:
> On Mon, 1 Oct 2018 08:19:29 -0700
> Zac Medico wrote:
>
>> Hi all,
>>
>> The ~arch version of portage hs a new QA check that reports installation
>> of files outside of directories that have been whitelisted [1]. The
>> current whitelist includes:
>>
>> directories common to / and /usr
>>
>> bin lib lib32 lib64 libx32 sbin
>>
>> top level directories
>>
>> boot dev etc opt srv usr var
>>
>> /usr level directories
>>
>> include libexec share src
>>
>> /usr/share/doc level directories
>>
>> /usr/share/doc/${PF}
>
> As this will break existing ebuilds I'd suggest guarding it against
> next EAPI. Out of top of by head the change will break at least
> crossdev outright. At least for two reasons:
> 1. building a gcc cross-compiler usually refers to $SYSROOT/sys-include.
>'git grep sys-include' will show a bunch of ebuilds that create that
>symlinks outside the space.
> 2. cross-building target libc is currently done on the host's emerge
> and installs into /usr/$CTARGET/.
>
> I think whitelist would be able to cover these use cases as they are
> a function of ${CTARGET} (or $CATEGORY) value.
The QA check currently does not die, it only calls eqawarn. So the worst
case is a message like this:
> QA: other
> The ebuild is installing to one or more unexpected paths:
>
> /usr/share/doc/qt-5.11.1
>
> Please fix the ebuild to use correct FHS/Gentoo policy paths.
It will be annoying if this message triggers for every package installed
by crossdev, so we should do something about that.
--
Thanks,
Zac
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Portage QA check for FHS/Gentoo policy paths, for top-level dirs and /usr/share/doc
On Mon, 1 Oct 2018 08:19:29 -0700
Zac Medico wrote:
> Hi all,
>
> The ~arch version of portage hs a new QA check that reports installation
> of files outside of directories that have been whitelisted [1]. The
> current whitelist includes:
>
> directories common to / and /usr
>
> bin lib lib32 lib64 libx32 sbin
>
> top level directories
>
> boot dev etc opt srv usr var
>
> /usr level directories
>
> include libexec share src
>
> /usr/share/doc level directories
>
> /usr/share/doc/${PF}
As this will break existing ebuilds I'd suggest guarding it against
next EAPI. Out of top of by head the change will break at least
crossdev outright. At least for two reasons:
1. building a gcc cross-compiler usually refers to $SYSROOT/sys-include.
'git grep sys-include' will show a bunch of ebuilds that create that
symlinks outside the space.
2. cross-building target libc is currently done on the host's emerge
and installs into /usr/$CTARGET/.
I think whitelist would be able to cover these use cases as they are
a function of ${CTARGET} (or $CATEGORY) value.
--
Sergei
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: net-libs/libssh2/
On Mon, 2018-10-01 at 21:30 +0200, Jeroen Roovers wrote: > On Mon, 01 Oct 2018 17:00:24 +0200 > Michał Górny wrote: > > > So your src_compile() is now broken for Ninja users, and src_test() > > is broken altogether. How about cmake-multilib eclass? > > DROP > > > IUSE=test is not used at all. > > THAT > > > By the way, MULTILIB_USEDEP certainly missing here. > > BLOODY > > > You sure this autoconf patch is needed for CMake build? > > AWFUL > > > They must have hacked that CMake hard to get it to generate .la files. > > ATTITUTE Since I've been approached by developers asking me about the original mail missing in the archives, I would like to note that I didn't send it to this mailing list. My purpose was to ask him to improve the ebuild and not publicly point out his mistakes. The choice of posting a reply to gentoo-dev was entirely his decision. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: net-libs/libssh2/
On Mon, 2018-10-01 at 21:30 +0200, Jeroen Roovers wrote: > On Mon, 01 Oct 2018 17:00:24 +0200 > Michał Górny wrote: > > > So your src_compile() is now broken for Ninja users, and src_test() > > is broken altogether. How about cmake-multilib eclass? > > DROP > > > IUSE=test is not used at all. > > THAT > > > By the way, MULTILIB_USEDEP certainly missing here. > > BLOODY > > > You sure this autoconf patch is needed for CMake build? > > AWFUL > > > They must have hacked that CMake hard to get it to generate .la files. > > ATTITUTE Then please kindly improve the quality of your Gentoo work. Ebuild writing is more than copying files and doing the minimal change necessary for it not to explode in your face. Furthermore, I don't really understand why you're CC-ing netmon@ here. Given you've cut off all the context, my suggestions would seem rather meaningless to the other member. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: net-libs/libssh2/
On Mon, 01 Oct 2018 17:00:24 +0200 Michał Górny wrote: > So your src_compile() is now broken for Ninja users, and src_test() > is broken altogether. How about cmake-multilib eclass? DROP > IUSE=test is not used at all. THAT > By the way, MULTILIB_USEDEP certainly missing here. BLOODY > You sure this autoconf patch is needed for CMake build? AWFUL > They must have hacked that CMake hard to get it to generate .la files. ATTITUTE
Re: [gentoo-dev] RFC: Portage QA check for FHS/Gentoo policy paths, for top-level dirs and /usr/share/doc
On 10/01/2018 11:16 AM, Michał Górny wrote:
> On Mon, 2018-10-01 at 19:23 +0200, Andreas Sturmlechner wrote:
>> On Montag, 1. Oktober 2018 17:48:16 CEST Michał Górny wrote:
>>> On Mon, 2018-10-01 at 08:19 -0700, Zac Medico wrote:
/usr/share/doc level directories
/usr/share/doc/${PF}
The first bug report [2] is for qt-core, which installs documentation
into /usr/share/doc/${PN}-${PV} instead of /usr/share/doc/${PF} (${PF}
includes ebuild revision such as -r1, -r2, and so on).
>>>
>>> No, it doesn't. There's no /usr/share/doc/qtcore-5.11.1 on my system.
>>
>> This is coming from dev-qt/qt-docs.
>
> Nope, still not /usr/share/doc/qt*core*-...
>
>> It is a problem because any other package
>> building QCH API docs with cross-references to Qt API needs to install below
>> this path, and will generate the same QA warning (currently kde-frameworks/*
>> does this).
>
> Yes. That is why I believe that hardcoding the exception in every
> package is simply wrong. Wouldn't it be cleaner to account for the path
> in the QA check?
There may be cases where we want to fix the ebuild to use
/usr/share/doc/${PF} though, right?
--
Thanks,
Zac
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Portage QA check for FHS/Gentoo policy paths, for top-level dirs and /usr/share/doc
On Mon, 2018-10-01 at 19:23 +0200, Andreas Sturmlechner wrote:
> On Montag, 1. Oktober 2018 17:48:16 CEST Michał Górny wrote:
> > On Mon, 2018-10-01 at 08:19 -0700, Zac Medico wrote:
> > > /usr/share/doc level directories
> > >
> > > /usr/share/doc/${PF}
> > >
> > > The first bug report [2] is for qt-core, which installs documentation
> > > into /usr/share/doc/${PN}-${PV} instead of /usr/share/doc/${PF} (${PF}
> > > includes ebuild revision such as -r1, -r2, and so on).
> >
> > No, it doesn't. There's no /usr/share/doc/qtcore-5.11.1 on my system.
>
> This is coming from dev-qt/qt-docs.
Nope, still not /usr/share/doc/qt*core*-...
> It is a problem because any other package
> building QCH API docs with cross-references to Qt API needs to install below
> this path, and will generate the same QA warning (currently kde-frameworks/*
> does this).
Yes. That is why I believe that hardcoding the exception in every
package is simply wrong. Wouldn't it be cleaner to account for the path
in the QA check?
--
Best regards,
Michał Górny
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: Portage QA check for FHS/Gentoo policy paths, for top-level dirs and /usr/share/doc
On Montag, 1. Oktober 2018 17:48:16 CEST Michał Górny wrote:
> On Mon, 2018-10-01 at 08:19 -0700, Zac Medico wrote:
> > /usr/share/doc level directories
> >
> > /usr/share/doc/${PF}
> >
> > The first bug report [2] is for qt-core, which installs documentation
> > into /usr/share/doc/${PN}-${PV} instead of /usr/share/doc/${PF} (${PF}
> > includes ebuild revision such as -r1, -r2, and so on).
>
> No, it doesn't. There's no /usr/share/doc/qtcore-5.11.1 on my system.
This is coming from dev-qt/qt-docs. It is a problem because any other package
building QCH API docs with cross-references to Qt API needs to install below
this path, and will generate the same QA warning (currently kde-frameworks/*
does this).
Re: [gentoo-dev] RFC: Portage QA check for FHS/Gentoo policy paths, for top-level dirs and /usr/share/doc
On 10/01/2018 08:48 AM, Michał Górny wrote: > On Mon, 2018-10-01 at 08:19 -0700, Zac Medico wrote: >> I have created a patch that will allow ebuilds to whitelist directories >> by setting a QA_INSTALL_PATHS variable [3], however @mgorny said: > > @mgorny was seriously concerned about trigger-happy patch authors who > find it urgent to silence QA warnings without even bothering to properly > discuss the problem. Discussion takes time, and I'm a very busy person, sorry about that. Anyway, eventually we are forced to discuss those issues that really matter. > And is continuously concerned about people who > want something but don't bother starting the discussion, and instead > rely on somebody else to start the discussion, even without having > the appropriate knowledge on what the problem is in the first place. > In other words, this is something that should be discussed on a case-by- > case basis. Not the usual Gentoo thing of 'I don't like this QA > warning, let's silence it quickly and go on ignoring everyone, whether > my package is broken or not'. Maybe we should implement a policy requiring gentoo-dev mailing list proposals for QA_INSTALL_PATHS usage in gentoo ebuilds (similar to the policy for news items and eclass changes)? -- Thanks, Zac signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Portage QA check for FHS/Gentoo policy paths, for top-level dirs and /usr/share/doc
On Mon, 2018-10-01 at 08:19 -0700, Zac Medico wrote:
> Hi all,
>
> The ~arch version of portage hs a new QA check that reports installation
> of files outside of directories that have been whitelisted [1]. The
> current whitelist includes:
>
> directories common to / and /usr
>
> bin lib lib32 lib64 libx32 sbin
>
> top level directories
>
> boot dev etc opt srv usr var
>
> /usr level directories
>
> include libexec share src
>
> /usr/share/doc level directories
>
> /usr/share/doc/${PF}
>
> The first bug report [2] is for qt-core, which installs documentation
> into /usr/share/doc/${PN}-${PV} instead of /usr/share/doc/${PF} (${PF}
> includes ebuild revision such as -r1, -r2, and so on).
No, it doesn't. There's no /usr/share/doc/qtcore-5.11.1 on my system.
> I have created a patch that will allow ebuilds to whitelist directories
> by setting a QA_INSTALL_PATHS variable [3], however @mgorny said:
@mgorny was seriously concerned about trigger-happy patch authors who
find it urgent to silence QA warnings without even bothering to properly
discuss the problem. And is continuously concerned about people who
want something but don't bother starting the discussion, and instead
rely on somebody else to start the discussion, even without having
the appropriate knowledge on what the problem is in the first place.
In other words, this is something that should be discussed on a case-by-
case basis. Not the usual Gentoo thing of 'I don't like this QA
warning, let's silence it quickly and go on ignoring everyone, whether
my package is broken or not'.
--
Best regards,
Michał Górny
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] Re: RFC: Portage QA check for FHS/Gentoo policy paths, for top-level dirs and /usr/share/doc
On 10/01/2018 11:19 AM, Zac Medico wrote:
>
> The first bug report [2] is for qt-core, which installs documentation
> into /usr/share/doc/${PN}-${PV} instead of /usr/share/doc/${PF}
It would be helpful to know why qtcore installs into the wrong directory
in the first place.
If ${PF} really causes serious problems, then would a symlink from
${PN}-${PV} to ${PF} fare any better?
Re: [gentoo-dev] RFC: Portage QA check for FHS/Gentoo policy paths, for top-level dirs and /usr/share/doc
On Mon, Oct 1, 2018 at 11:19 AM Zac Medico wrote:
>
> Hi all,
>
> The ~arch version of portage hs a new QA check that reports installation
> of files outside of directories that have been whitelisted [1]. The
> current whitelist includes:
>
> directories common to / and /usr
>
> bin lib lib32 lib64 libx32 sbin
>
> top level directories
>
> boot dev etc opt srv usr var
>
> /usr level directories
>
> include libexec share src
>
> /usr/share/doc level directories
>
> /usr/share/doc/${PF}
>
> The first bug report [2] is for qt-core, which installs documentation
> into /usr/share/doc/${PN}-${PV} instead of /usr/share/doc/${PF} (${PF}
> includes ebuild revision such as -r1, -r2, and so on).
>
> I have created a patch that will allow ebuilds to whitelist directories
> by setting a QA_INSTALL_PATHS variable [3], however @mgorny said:
>
> On Mon, Oct 1, 2018 at 12:34 AM Michał Górny wrote:
> > QA NAK on this. The purpose of QA checks is not for ebuilds to
> > officially override them because histerical raisins.
I don't think QA has the final word on features that are added to the
package manager. They can prevent abuse of those features by ebuilds
in the repository, however.
Personally, I think compatibility with historical code is a perfectly
valid reason to make an exception here.
[gentoo-dev] RFC: Portage QA check for FHS/Gentoo policy paths, for top-level dirs and /usr/share/doc
Hi all,
The ~arch version of portage hs a new QA check that reports installation
of files outside of directories that have been whitelisted [1]. The
current whitelist includes:
directories common to / and /usr
bin lib lib32 lib64 libx32 sbin
top level directories
boot dev etc opt srv usr var
/usr level directories
include libexec share src
/usr/share/doc level directories
/usr/share/doc/${PF}
The first bug report [2] is for qt-core, which installs documentation
into /usr/share/doc/${PN}-${PV} instead of /usr/share/doc/${PF} (${PF}
includes ebuild revision such as -r1, -r2, and so on).
I have created a patch that will allow ebuilds to whitelist directories
by setting a QA_INSTALL_PATHS variable [3], however @mgorny said:
On Mon, Oct 1, 2018 at 12:34 AM Michał Górny wrote:
> QA NAK on this. The purpose of QA checks is not for ebuilds to
> officially override them because histerical raisins.
[1]
https://gitweb.gentoo.org/proj/portage.git/commit/?id=d5f97eaa464736a454c8ad410f4acd4fccdf2324
[2] https://bugs.gentoo.org/667280
[3] https://bugs.gentoo.org/667378
--
Thanks,
Zac
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [PATCH 3/5] xdg.eclass: move deps to RDEPEND
On Mon, Oct 1, 2018 at 9:17 AM James Le Cuirot wrote: > > On Mon, 1 Oct 2018 09:00:38 -0400 > Mike Gilbert wrote: > > > > The reason why it is in DEPEND though is that none of these tools > > > are required at runtime. They are needed at postinst and postrm > > > stages which afaik makes them DEPEND on EAPI previous to EAPI 7 and > > > BDEPEND in EAPI 7 if I'm not mistaken. > > > > This is incorrect; programs executed in pkg_postinst/pkg_postrm should > > be present in RDEPEND. Consider a binpkg installation, which would > > ignore DEPEND, but would still execute pkg_postinst. > > > > Another option: since xdg-utils.eclass functions will politely skip > > the updates if the tools are missing, we could just drop the > > dependency from xdg.eclass entirely and wait for the tools to get > > installed through some indirect means. > > Unfortunately there is no correct answer here as we didn't consider > this scenario when planning EAPI 7. We should have looked at Exherbo, > which does make this important distinction. There is a bug report open. > > https://bugs.gentoo.org/660306 > > What I will say is that we should not attempt to executing anything > from within ROOT or SYSROOT unless it known to be interpreted > (e.g. a shell script) and there is no feasible alternative. I add that > exclusion clause because I have been forced to do this with > python-config. That's a good point; both update-desktop-database and update-mime-database are compiled binaries, and should probably be executed from BROOT (/) instead. I'll revise my patchset.
Re: [gentoo-dev] Re: [PATCH 3/5] xdg.eclass: move deps to RDEPEND
On Mon, 1 Oct 2018 09:00:38 -0400 Mike Gilbert wrote: > > The reason why it is in DEPEND though is that none of these tools > > are required at runtime. They are needed at postinst and postrm > > stages which afaik makes them DEPEND on EAPI previous to EAPI 7 and > > BDEPEND in EAPI 7 if I'm not mistaken. > > This is incorrect; programs executed in pkg_postinst/pkg_postrm should > be present in RDEPEND. Consider a binpkg installation, which would > ignore DEPEND, but would still execute pkg_postinst. > > Another option: since xdg-utils.eclass functions will politely skip > the updates if the tools are missing, we could just drop the > dependency from xdg.eclass entirely and wait for the tools to get > installed through some indirect means. Unfortunately there is no correct answer here as we didn't consider this scenario when planning EAPI 7. We should have looked at Exherbo, which does make this important distinction. There is a bug report open. https://bugs.gentoo.org/660306 What I will say is that we should not attempt to executing anything from within ROOT or SYSROOT unless it known to be interpreted (e.g. a shell script) and there is no feasible alternative. I add that exclusion clause because I have been forced to do this with python-config. -- James Le Cuirot (chewi) Gentoo Linux Developer
[gentoo-dev] Re: [PATCH 3/5] xdg.eclass: move deps to RDEPEND
On Mon, Oct 1, 2018 at 8:27 AM Gilles Dartiguelongue wrote: > > Le lundi 01 octobre 2018 à 07:40 +0200, Rémi Cardona a écrit : > > Le 01/10/2018 à 00:50, Mike Gilbert a écrit : > > > update-desktop-database and update-mime-database are called from > > > ROOT in > > > pkg functions, so the related dependenices belong in RDEPEND. > > > > > > Signed-off-by: Mike Gilbert > > > > As far as the eclass goes, this is correct. But AFAIR, this was > > needed > > because some packages look for those tools at build time. It was ages > > ago so maybe it no longer applies. > > > > Rémi > > > > A lot of autotools based packages do explicitly search for it. I don't > think they fail if it is missing though but a tinderbox run would be > welcome. That's... interesting. I think it would make more sense for these packages to state this dependency explicitly instead of relying on the dep from the eclass. > The reason why it is in DEPEND though is that none of these tools are > required at runtime. They are needed at postinst and postrm stages > which afaik makes them DEPEND on EAPI previous to EAPI 7 and BDEPEND in > EAPI 7 if I'm not mistaken. This is incorrect; programs executed in pkg_postinst/pkg_postrm should be present in RDEPEND. Consider a binpkg installation, which would ignore DEPEND, but would still execute pkg_postinst. Another option: since xdg-utils.eclass functions will politely skip the updates if the tools are missing, we could just drop the dependency from xdg.eclass entirely and wait for the tools to get installed through some indirect means.
[gentoo-dev] Re: [PATCH 3/5] xdg.eclass: move deps to RDEPEND
Le lundi 01 octobre 2018 à 07:40 +0200, Rémi Cardona a écrit : > Le 01/10/2018 à 00:50, Mike Gilbert a écrit : > > update-desktop-database and update-mime-database are called from > > ROOT in > > pkg functions, so the related dependenices belong in RDEPEND. > > > > Signed-off-by: Mike Gilbert > > As far as the eclass goes, this is correct. But AFAIR, this was > needed > because some packages look for those tools at build time. It was ages > ago so maybe it no longer applies. > > Rémi > A lot of autotools based packages do explicitly search for it. I don't think they fail if it is missing though but a tinderbox run would be welcome. The reason why it is in DEPEND though is that none of these tools are required at runtime. They are needed at postinst and postrm stages which afaik makes them DEPEND on EAPI previous to EAPI 7 and BDEPEND in EAPI 7 if I'm not mistaken. -- Gilles Dartiguelongue Gentoo
[gentoo-dev] [PATCH 2/2] profiles: mask module signing for testing
Signed-off-by: Georgy Yakovlev --- profiles/base/use.mask | 4 1 file changed, 4 insertions(+) diff --git a/profiles/base/use.mask b/profiles/base/use.mask index 6082a468925..374cdbe85fe 100644 --- a/profiles/base/use.mask +++ b/profiles/base/use.mask @@ -4,6 +4,10 @@ # This file is only for generic masks. For arch-specific masks (i.e. # mask everywhere, unmask on arch/*) use arch/base. +# Georgy Yakovlev (01 Oct 2018) +# mask module signing for testing +module-sign + # Aaron W. Swenson (09 Sep 2018) # Mask PostgreSQL 12 while in (pre-)alpha. postgres_targets_postgres12 -- 2.19.0
[gentoo-dev] [PATCH 1/2] eclass/linux-mod.eclass: add module signing support
This commit adds some eclass variables and private functions
and a new global useflag.
Example config, part of make.conf
USE="... module-sign ..."
KERNEL_MODULE_SIG_KEY="/secure/location/kernel.pem"
And possible kernel options:
CONFIG_MODULE_SIG=y
CONFIG_MODULE_SIG_FORCE=y
CONFIG_MODULE_SIG_ALL=y
CONFIG_MODULE_SIG_SHA512=y
CONFIG_MODULE_SIG_HASH="sha512"
NOTE to libressl users: libressl does not support anything
except CONFIG_MODULE_SIG_SHA1=y CONFIG_MODULE_SIG_HASH="sha1"
Even if user does not follow key creation procedure and
just enables module encryption while configuring kernel eclass "just works".
All the signing happens in pkg_preinst.
This means that binpkg users are expected to
have keys and sign modules on target system, not on builder.
I've been using this since March and have not encountered
a single problem with various out-of-tree kernel modules
Tested so far:
virtualbox-modules
nvidia-drivers
zfs & co
wireguard
and many more
If an ebuild uses Kbuild and/or runs linux-mod_pkg_preinst(), signing should
work.
All the signing happens as root, this means user can have the
keys stored with secure permissions and mount as required.
If user configured kernel to require signed modules the eclass
will detect it and refuse to emerge if useflag is not enabled.
I'll appreciate your testing and feedbak.
NOTE to amdgpu users: if you use CONFIG_HSA_AMD, you'll want to have
CONFIG_HSA_AMD=y
having it as a module fails to sing for some reason, it's something in
kernel/kbuild and not related to this eclass change.
Bug: https://bugs.gentoo.org/447352
Signed-off-by: Georgy Yakovlev
---
eclass/linux-mod.eclass | 109 ++--
profiles/use.desc | 1 +
2 files changed, 106 insertions(+), 4 deletions(-)
diff --git a/eclass/linux-mod.eclass b/eclass/linux-mod.eclass
index 920790b8db9..de43f2d234e 100644
--- a/eclass/linux-mod.eclass
+++ b/eclass/linux-mod.eclass
@@ -132,6 +132,20 @@
# @DESCRIPTION:
# It's a read-only variable. It contains the extension of the kernel modules.
+# @ECLASS-VARIABLE: KERNEL_MODULE_SIG_KEY
+# @USER_VARIABLE
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# A string, containing absolute path to the private key file.
+# eclass will use value of CONFIG_MODULE_SIG_KEY extracted from .config
+# if KERNEL_MODULE_SIG_KEY is not set by user.
+#
+# Example:
+# @CODE
+# KERNEL_MODULE_SIG_KEY="/secure/location/kernel.pem"
+# @CODE
+# Assumes that "/secure/location/kernel.x509" public key file exists.
+
inherit eutils linux-info multilib
EXPORT_FUNCTIONS pkg_setup pkg_preinst pkg_postinst src_install src_compile
pkg_postrm
@@ -144,13 +158,16 @@ esac
0) die "EAPI=${EAPI} is not supported with
MODULES_OPTIONAL_USE_IUSE_DEFAULT due to lack of IUSE defaults" ;;
esac
-IUSE="kernel_linux
${MODULES_OPTIONAL_USE:+${_modules_optional_use_iuse_default}}${MODULES_OPTIONAL_USE}"
+IUSE="module-sign kernel_linux
${MODULES_OPTIONAL_USE:+${_modules_optional_use_iuse_default}}${MODULES_OPTIONAL_USE}"
SLOT="0"
RDEPEND="${MODULES_OPTIONAL_USE}${MODULES_OPTIONAL_USE:+? (} kernel_linux? (
virtual/modutils ) ${MODULES_OPTIONAL_USE:+)}"
DEPEND="${RDEPEND}
${MODULES_OPTIONAL_USE}${MODULES_OPTIONAL_USE:+? (}
sys-apps/sed
- kernel_linux? ( virtual/linux-sources virtual/libelf )
+ kernel_linux? (
+ virtual/linux-sources virtual/libelf
+ module-sign? ( || ( dev-libs/openssl dev-libs/libressl ) )
+ )
${MODULES_OPTIONAL_USE:+)}"
# eclass utilities
@@ -352,6 +369,84 @@ get-KERNEL_CC() {
echo "${kernel_cc}"
}
+# @FUNCTION: _check_sig_force
+# @INTERNAL
+# @DESCRIPTION:
+# Check if kernel requires module signing and die
+# if modules are not going to be signed.
+_check_sig_force() {
+ debug-print-function ${FUNCNAME} "${@}"
+
+ if linux_chkconfig_present MODULE_SIG_FORCE; then
+ if use !module-sign; then
+ eerror "kernel .config has MODULE_SIG_FORCE=y option
set"
+ eerror "This means that kernel requires all modules"
+ eerror "to be signed and verified before loading"
+ eerror "please enable USE=\"module-sign\" or
reconfigure your kernel"
+ eerror "otherwise loading the module will fail"
+ die "signature required"
+ fi
+ fi
+}
+
+# @FUNCTION: _sign_module
+# @INTERNAL
+# @USAGE:
+# @DESCRIPTION:
+# Sign a kernel module
+_sign_module() {
+ debug-print-function ${FUNCNAME} "${@}"
+
+ local dotconfig_sig_hash dotconfig_sig_key
+ local sign_binary_path sig_key_path sig_x509_path
+ local module
+
+ # extract values from kernel .config
+ # extracted key path is not full, e.g. "certs/signing_key.pem"
+ dotconfig_sig_hash="$(linux_chkconfig_string MODULE_SIG_HASH)"
+ dotconfig_sig_key="$(linux_chkconfig_string MODULE_SIG_KEY)"
+
+ # sign-file binary chokes on
Re: [gentoo-portage-dev] [PATCH] Support QA{,_STRICT}_INSTALL_PATHS variables (bug 667378)
On Sun, 2018-09-30 at 22:45 -0700, Zac Medico wrote:
> The QA_INSTALL_PATHS variable exempts paths from "unexpected paths"
> warnings generated by install-qa-check.d/08gentoo-paths. This is
> useful for QT packages that are expected to install a directory
> named /usr/share/doc/${PN}-${VERSION} (which may differ from the
> usual /usr/share/doc/${PF} location as reported in bug 667280).
>
> Bug: https://bugs.gentoo.org/667378
> Signed-off-by: Zac Medico
> ---
> bin/install-qa-check.d/08gentoo-paths | 21 +
> man/ebuild.5 | 7 +++
> man/make.conf.5 | 4
> 3 files changed, 32 insertions(+)
>
> diff --git a/bin/install-qa-check.d/08gentoo-paths
> b/bin/install-qa-check.d/08gentoo-paths
> index 3ee887df0..a00f9f6af 100644
> --- a/bin/install-qa-check.d/08gentoo-paths
> +++ b/bin/install-qa-check.d/08gentoo-paths
> @@ -60,6 +60,27 @@ gentoo_path_check() {
>
> ${shopt_save}
>
> + if [[ ${#bad_paths[@]} -gt 0 && ${QA_INSTALL_PATHS} &&
> + ${QA_STRICT_INSTALL_PATHS-unset} == unset ]]; then
> + local filtered_paths=()
> + local sed_args=()
> + local qa_install_paths
> + if [[ $(declare -p QA_INSTALL_PATHS) == "declare -a "* ]]; then
> + qa_install_paths=("${QA_INSTALL_PATHS[@]}")
> + else
> + set -f
> + qa_install_paths=(${QA_INSTALL_PATHS})
> + set +f
> + fi
> + for x in "${qa_install_paths[@]}"; do
> + sed_args+=(-e "s#^/${x#/}\$##")
> + done
> + while read -r -d ''; do
> + [[ ${REPLY} ]] && filtered_paths+=("${REPLY}")
> + done < <(printf -- '%s\0' "${bad_paths[@]}" | sed -z
> "${sed_args[@]}")
> + bad_paths=("${filtered_paths[@]}")
> + fi
> +
> # report
> # --
> if [[ -n ${bad_paths[@]} ]]; then
> diff --git a/man/ebuild.5 b/man/ebuild.5
> index 9f491dd73..01f3e09aa 100644
> --- a/man/ebuild.5
> +++ b/man/ebuild.5
> @@ -791,6 +791,13 @@ characters.
> This variable is intended to be used on files of binary packages which ignore
> CFLAGS, CXXFLAGS, FFLAGS, FCFLAGS, and LDFLAGS variables.
> .TP
> +.B QA_INSTALL_PATHS
> +This should contain a list of file paths (may be an array), relative to the
> +image directory, of files that are exempt from QA notices regarding ebuilds
> +that install files to unusual locations.
> +The paths may contain regular expressions with escape\-quoted special
> +characters.
> +.TP
> .B QA_MULTILIB_PATHS
> This should contain a list of file paths, relative to the image directory, of
> files that should be ignored for the multilib\-strict checks.
> diff --git a/man/make.conf.5 b/man/make.conf.5
> index a33929143..d97d83767 100644
> --- a/man/make.conf.5
> +++ b/man/make.conf.5
> @@ -1060,6 +1060,10 @@ settings from ebuilds. See also \fBebuild\fR(5).
> Set this to cause portage to ignore any \fIQA_FLAGS_IGNORED\fR override
> settings from ebuilds. See also \fBebuild\fR(5).
> .TP
> +\fBQA_STRICT_INSTALL_PATHS = \fI"set"\fR
> +Set this to cause portage to ignore any \fIQA_INSTALL_PATHS\fR override
> +settings from ebuilds. See also \fBebuild\fR(5).
> +.TP
> \fBQA_STRICT_MULTILIB_PATHS = \fI"set"\fR
> Set this to cause portage to ignore any \fIQA_MULTILIB_PATHS\fR override
> settings from ebuilds. See also \fBebuild\fR(5).
QA NAK on this. The purpose of QA checks is not for ebuilds to
officially override them because histerical raisins.
--
Best regards,
Michał Górny
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH 5/5] xdg.eclass: support EAPI 7
> On Mon, 01 Oct 2018, Mike Gilbert wrote:
> @@ -15,7 +15,7 @@
> inherit xdg-utils
> case "${EAPI:-0}" in
This was there before your change, but the ":-0" isn't needed here ...
> - 4|5|6)
> + 4|5|6|7)
> EXPORT_FUNCTIONS src_prepare pkg_preinst pkg_postinst pkg_postrm
> ;;
> *) die "EAPI=${EAPI} is not supported" ;;
... while this line could profit from it.
> @@ -35,7 +35,7 @@ fi
> xdg_src_prepare() {
> xdg_environment_reset
>
> - has ${EAPI:-0} 6 && default
> + has "${EAPI:-0}" 4 5 || default
Ditto.
Ulrich
signature.asc
Description: PGP signature
