[gentoo-dev] [warning] the bug queue has 86 bugs
Our bug queue has 86 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-python/intelhex/
On 10/21/2015 07:21 PM, Ciaran McCreesh wrote: > On Wed, 21 Oct 2015 01:25:53 +0200 > hasufell wrote: >> Also, my package manager chokes on it. Repoman not, so that looks >> like a bug. > > s/Repoman/Portage/ > > Portage will quite happily let you specify KEYWORDS=":)". > Yes, this has to be fixed. Bug reports are here: https://bugs.gentoo.org/show_bug.cgi?id=563702 https://bugs.gentoo.org/show_bug.cgi?id=563642
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-python/intelhex/
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 21/10/15 19:32, Justin Lecher (jlec) wrote: > On 21/10/15 19:21, Ciaran McCreesh wrote: >> On Wed, 21 Oct 2015 01:25:53 +0200 hasufell >> wrote: >>> Also, my package manager chokes on it. Repoman not, so that >>> looks like a bug. > >> s/Repoman/Portage/ > >> Portage will quite happily let you specify KEYWORDS=":)". > > > Lot's of ebuilds have "-*", which is the negation of what Mike set. > So why is that working but "*" not? > > Justin > Reading PMS helps ;) -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0 iQJ8BAEBCgBmBQJWJ8xoXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmi5PsP/1Iqaux1VzlibKC7WRgmqayS p2yuyPka8qH+q1XGQidMNaXLsGFhaK2+JUkZo8BqbjlsxhNOIPpme55qCUi1MQD1 nvPJuDZu3yvA96EZsNRpeDflqmY/hDs3SpZjP1Tk+25Oy5kzBi5keH2yjT7Vpsxx ynR0q8zFChnB9URg9ahE5NgXmz36rCX2aK4mq7eNWbD6kqgz16bvXkzoHYnYLsl1 mSrYdMNy4g6LkEpgros9VVG8Pft6mxvsN0/X2R5O8RzsPYaQBT6lTGjlp2R1uHCG FOc9JV1KR1E2TklbstN4szQYAWPdngyqCpl67XgxZ2q6LXmnjg/DlXaKokFXezvq K/iz2drqZVXmWN1V6S5bHUhtrgqCG2Ja7ri+t84uaZK/MRZnhCs4l1RGE5A6uIAX np0lmgeZ/lgmvSPlRAWA6cqHzofBTvBdjcOoDCkktvz0i8/k1CnDrxmlReRX7abv X4VAuNPl0L1BJixuFW9LN6YVIb5uLpOpamgekpFRZADsB0eWZMWYEaMMkB0phngl sN6xUkY0q7PP/RKL1nQZd9KMLr8k1WOgz3byp49cmagKkfDJSghm/cDctVxJU3lN N0RvnTaD11j4DAs+ZhbVL173pz5hfeT90sJ72fc2HkgISRhVDxLGpFeEbawEkuNs DndQxeE8y5Er8Rv60eAF =f0Li -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-python/intelhex/
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 21/10/15 19:21, Ciaran McCreesh wrote: > On Wed, 21 Oct 2015 01:25:53 +0200 hasufell > wrote: >> Also, my package manager chokes on it. Repoman not, so that >> looks like a bug. > > s/Repoman/Portage/ > > Portage will quite happily let you specify KEYWORDS=":)". > Lot's of ebuilds have "-*", which is the negation of what Mike set. So why is that working but "*" not? Justin -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0 iQJ8BAEBCgBmBQJWJ8xAXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0QUU0N0I4NzFERUI0MTJFN0EyODE0NUFF OTQwMkE3OUIwMzUyOUEyAAoJEOlAKnmwNSmiAWMP/3BafTzLvjKl3ovDQF9RY74R feZ73xa1UX6BpPaBzGqPG8p+5nlN+1aKrC0AkF/rfT1l46/GVGj9eQrCyMeMVUpb lZG6XU40rozDeiYg1Gyg8TXIO1tARJEbs1dkYsAcKhZcNChlc2/m16fk37SkfBQk wAL1qNCEJSmLe3+cIgTi46u+zoxaroYUKAlhiQp3PHeTBG2DXj+P5UN7IvwhHwHf p23CJQVNZHnGC+SQ0Cn3rCdsPIIQx+V2iM/veJfrhIaofUEfSTzwZU2l6NhaOPNt NUUH932oTOm8j6gqfJRBcdRoY9aG5wTWe2/3tcyIYwY9Z+2vltsVEWCZjKdDRErU 1TfGfo3KeP7oyTJ/cH70ea6tcuoeykD6mdUFIcq34qQ5dDzQxdbltP4jPjxym1vS o588dfVHQeGs7yGl1lCAWtl8BH10BvNE0zdI8wP2X/buP6v2r1pbmzQmDuQRBNlI vko/CSw1bHO1dj/L+wFWT+sschb/Gc9oBwknd7UGmdAeLlRxs1OD7eO9VbRL7AQU Fp9xhae+pLAw1hd2ds/YCG5dPq4TLW4wTXQzTrwWPK3xajab4eea+/xER+V9EMx9 HRSumA0mdN8DRNg0N4yLm2iMYjV/zv4XhmTZuNxw3JBM1xzw2ovCt2EGxbfdWw// x3wSoO287X/GAcVaGqv3 =OJI7 -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-python/intelhex/
On Wed, 21 Oct 2015 01:25:53 +0200 hasufell wrote: > Also, my package manager chokes on it. Repoman not, so that looks > like a bug. s/Repoman/Portage/ Portage will quite happily let you specify KEYWORDS=":)". -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Why is my news item not showing up.
On 10/21/15 6:05 AM, Rich Freeman wrote: On Wed, Oct 21, 2015 at 4:44 AM, Anthony G. Basile wrote: I pushed out my news item and it landed in /usr/portage/metadata on my hardened servers, but its not showing up with eselect news. Does anyone know why? 1. Do you have hardend-sources installed? 2. Do you have either hardened or pax_kernel in your ACCEPT_KEYWORDS? 3. Do you have one of the listed profiles selected? If the answer to any of those questions is no, then that's your problem - according to glep 42 the individual checks are ORs, and they're combined by AND. Wow, am I every blind. 2 is for keywords not use flags. Thanks. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] Why is my news item not showing up.
On Wed, Oct 21, 2015 at 4:44 AM, Anthony G. Basile wrote: > > I pushed out my news item and it landed in /usr/portage/metadata on my > hardened servers, but its not showing up with eselect news. Does anyone > know why? 1. Do you have hardend-sources installed? 2. Do you have either hardened or pax_kernel in your ACCEPT_KEYWORDS? 3. Do you have one of the listed profiles selected? If the answer to any of those questions is no, then that's your problem - according to glep 42 the individual checks are ORs, and they're combined by AND. -- Rich
Re: [gentoo-dev] Introduce ppc64le architecture into gentoo ! please share your comments
Hi Guys， We have finish compiling stage3 for ppc64 (little-endian).Here is the link: https://drive.google.com/file/d/0B2k84p6709AyTFlwLUF1WjlxUk0/view?usp=sharing Now we are going to build LiveCD using stage3. Could you help to give some demo or a guide for building LiveCD? That will help we a lot to make effort. Thanks ~ 2015-09-27 3:16 GMT+08:00 Anthony G. Basile : > On 9/24/15 8:23 AM, Leno Hou wrote: > >> >> >> Again, please apply POWER8 Systems and join our work :-) >> [1]: https://www.runabove.com/instances/ibm-power8.xml >> [2]: https://ptopenlab.com/cloudlabconsole/#/ >> [3]: http://osuosl.org/services/powerdev/request_hosting >> >> >> -Leno Hou >>> >>> > I have applied to osuosl for an ibm power8 ppc64le node. I've put myself > down as the point-of-contact. I asked for openstack gui access and will > try to build a system using Leno's stage3. I'm not sure what the env looks > like right now, but i assume i'll have to boot off a cd image. I'll use > debians. I guess I could be macho and try to build everything from > scratch, cross compile a kernel and all, but time. > > Has anyone tried qemu simulating ppc64le on amd64? Lu I thought you said > you tried on x86 and it didn't work. > > > > -- > Anthony G. Basile, Ph.D. > Gentoo Linux Developer [Hardened] > E-Mail: bluen...@gentoo.org > GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA > GnuPG ID : F52D4BBA > >
[gentoo-dev] Why is my news item not showing up.
Hi everyone, I pushed out my news item and it landed in /usr/portage/metadata on my hardened servers, but its not showing up with eselect news. Does anyone know why? I don't know how to debug this. I pushed it to git.gentoo.org/data/gentoo-news.git in a directory called 2015-10-21-future-support-of-hardened-sources-kernel. I have two files in there: 2015-10-21-future-support-of-hardened-sources-kernel.en.txt 2015-10-21-future-support-of-hardened-sources-kernel.en.txt.asc Here' it is again just so you don't have to go digging: Title: Future Support of hardened-sources Kernel Content-Type: text/plain Posted: 2015-10-21 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: sys-kernel/hardened-sources Display-If-Keyword: hardened Display-If-Keyword: pax_kernel Display-If-Profile: hardened/linux/amd64 Display-If-Profile: hardened/linux/amd64/no-multilib Display-If-Profile: hardened/linux/amd64/no-multilib/selinux Display-If-Profile: hardened/linux/amd64/selinux Display-If-Profile: hardened/linux/amd64/x32 Display-If-Profile: hardened/linux/arm/armv6j Display-If-Profile: hardened/linux/arm/armv7a Display-If-Profile: hardened/linux/ia64 Display-If-Profile: hardened/linux/musl/amd64 Display-If-Profile: hardened/linux/musl/amd64/x32 Display-If-Profile: hardened/linux/musl/arm/armv7a Display-If-Profile: hardened/linux/musl/mips Display-If-Profile: hardened/linux/musl/mips/mipsel Display-If-Profile: hardened/linux/musl/ppc Display-If-Profile: hardened/linux/musl/x86 Display-If-Profile: hardened/linux/powerpc/ppc32 Display-If-Profile: hardened/linux/powerpc/ppc64/32bit-userland Display-If-Profile: hardened/linux/powerpc/ppc64/64bit-userland Display-If-Profile: hardened/linux/uclibc/amd64 Display-If-Profile: hardened/linux/uclibc/arm/armv7a Display-If-Profile: hardened/linux/uclibc/mips Display-If-Profile: hardened/linux/uclibc/mips/mipsel Display-If-Profile: hardened/linux/uclibc/ppc Display-If-Profile: hardened/linux/uclibc/x86 Display-If-Profile: hardened/linux/x86 Display-If-Profile: hardened/linux/x86/selinux For many years, the Grsecurity team [1] has been supporting two versions of their security patches against the Linux kernel, a stable and a testing version, and Gentoo has made both of these available to our users through the hardened-sources package. However, on August 26 of this year, the team announced they would no longer be making the stable version publicly available, citing trademark infringement by a major embedded systems company as the reason. [2] The stable patches are now only available to sponsors of Grsecurity and can no longer be distributed in Gentoo. However, the team did assure us that they would continue to release and support the testing version as they have in the past. What does this means for users of hardened-sources? Gentoo will continue to make the testing version available through our hardened-sources package but we will have to drop support for the 3.x series. In a few days, those ebuilds will be removed from the tree and you will be required to upgrade to a 4.x series kernel. Since the hardened-sources package only installs the kernel source tree, you can continue using a currently built 3.x series kernel but bear in mind that we cannot support you, nor will upstream. Also keep in mind that the 4.x series will not be as reliable as the 3.x series was, so reporting bugs promptly will be even more important. Gentoo will continue to work closely with upstream to stay on top of any problems, but be prepared for the occasional "bad" kernel. The more reporting we receive from our users, the better we will be able to decide which hardened-sources kernels to mark stable and which to drop. Refs. [1] https://grsecurity.net [2] https://grsecurity.net/announce.php -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
[gentoo-dev] [PATCH] Recommend setting the bash compatibility level. (was: Re: utilizing BASH_COMPAT to smooth upgrades)
> On Tue, 20 Oct 2015, Mike Frysinger wrote:
> On 21 Oct 2015 00:03, Ulrich Mueller wrote:
>> Therefore I'd make it a recommendation at most. Something along the
>> lines of: "The interpreter is assumed to be GNU bash, version as
>> listed in table xyz, or any later version. If possible, the package
>> manager should set the shell's compatibility level to the exact
>> version specified."
> and include the recommended snippet as well as add a warning about
> not exporting the variable less it break external shell scripts.
"The interpreter is assumed to be GNU bash, version as listed in table
xyz, or any later version. If possible, the package manager should set
the shell's compatibility level to the exact version specified. It
must ensure that any such compatibility settings (e.g. the BASH_COMPAT
variable) are not exported to external programs."
Ulrich
From: =?UTF-8?q?Ulrich=20M=C3=BCller?=
Date: Wed, 21 Oct 2015 09:31:06 +0200
Subject: [PATCH] Recommend setting the bash compatibility level.
---
ebuild-format.tex | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/ebuild-format.tex b/ebuild-format.tex
index c741398..6eab1d5 100644
--- a/ebuild-format.tex
+++ b/ebuild-format.tex
@@ -3,11 +3,14 @@
The ebuild file format is in its basic form a subset of the format of a bash
script. The interpreter
is assumed to be GNU bash, version as listed in
table~\ref{tab:system-commands-table} on
-page~\pageref{tab:system-commands-table}, or any later version. The file
encoding must be UTF-8
-with Unix-style newlines. When sourced, the ebuild must define certain
variables and functions
-(see sections~\ref{sec:ebuild-vars} and~\ref{sec:ebuild-functions} for
specific information), and
-must not call any external programs, write anything to standard output or
standard error, or modify
-the state of the system in any way.
+page~\pageref{tab:system-commands-table}, or any later version. If possible,
the package manager
+should set the shell's compatibility level to the exact version specified. It
must ensure that any
+such compatibility settings (e.g. the \t{BASH\_COMPAT} variable) are not
exported to external programs.
+
+The file encoding must be UTF-8 with Unix-style newlines. When sourced, the
ebuild must define
+certain variables and functions (see sections~\ref{sec:ebuild-vars}
and~\ref{sec:ebuild-functions}
+for specific information), and must not call any external programs, write
anything to standard
+output or standard error, or modify the state of the system in any way.
% vim: set filetype=tex fileencoding=utf8 et tw=100 spell spelllang=en :
--
2.6.2
pgpQGua_ruCSI.pgp
Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-python/intelhex/
21.10.2015 02:25, hasufell пишет:
> On 10/20/2015 04:02 PM, Mike Frysinger wrote:
>> commit: a68f2479fba9422913cb760166316bf489d72ca8
>> Author: Vincent Palatin chromium org>
>> AuthorDate: Tue Oct 20 14:01:34 2015 +
>> Commit: Mike Frysinger gentoo org>
>> CommitDate: Tue Oct 20 14:01:50 2015 +
>> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a68f2479
>>
>> dev-python/intelhex: new package from Chromium OS
>>
>> dev-python/intelhex/Manifest| 1 +
>> dev-python/intelhex/intelhex-2.0.ebuild | 18 ++
>> dev-python/intelhex/metadata.xml| 9 +
>> 3 files changed, 28 insertions(+)
>>
> [...]
>
>> +
>> +EAPI="5"
>> +
>> +PYTHON_COMPAT=( python{2_7,3_3,3_4,3_5} )
>> +
>> +inherit distutils-r1
>> +
>> +DESCRIPTION="Python library for Intel HEX files manipulations"
>> +HOMEPAGE="http://pypi.python.org/pypi/IntelHex/
>> https://github.com/bialix/intelhex";
>> +SRC_URI="mirror://pypi/I/IntelHex/${P}.tar.gz"
>> +
>> +LICENSE="BSD"
>> +SLOT="0"
>> +KEYWORDS="*"
> What does that KEYWORDS mean? Unless I read PMS wrong [0][1], this isn't
> even allowed. And I don't see a single ebuild in the tree with that syntax.
>
> Also, my package manager chokes on it. Repoman not, so that looks like a
> bug.
>
>
> [0] https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-260003.1.6
> [1] https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-690007.3.2
>
As per commit message, it was imported from chromium os, AFAIR, they
have their own rules about how to write ebuilds, and of course our PMS
doesn't allow such things.
Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review
On Wed, 21 Oct 2015 01:24:00 + (UTC)
Duncan <1i5t5.dun...@cox.net> wrote:
> Alexis Ballier posted on Tue, 20 Oct 2015 12:25:07 +0200 as excerpted:
>
> > On Tue, 20 Oct 2015 06:00:15 -0400 Rich Freeman
> > wrote:
> >
> >> So, perhaps it is a fair question to ask what is the specific harm
> >> from allowing it to be a no-op on subsequent calls, other than
> >> encouraging a coding practice that could possibly have other
> >> unrelated effects?
> >
> > Yep; I can't see any real harm, but this is probably based on a
> > limited view of the big picture.
> > However, I do think the practice should be discouraged, but 'let
> > be' in specific cases like for eclasses co-existence. Actually,
> > just like any other (non breaking) QA issue is handled I think.
>
> Wouldn't the ultimate effect of "let be", assuming the simplest first-
> eclass-applies rule, effectively undo the entire purpose of having a
> mandatory eapply_user in the first place?
>
> IOW, now, without some hook, users can't depend on epatch_user.
>
> Wouldn't "let be" simply define eapply_user as just as undependable,
> if not more so, because users couldn't simply pickup patches, dump
> them in ${PM_LOCAL_PATCHDIR}, and expect them to actually apply
> properly, because the first eapply_user would apply them and then the
> patches other eclasses attempt to apply would break, triggering a die.
'let be' means that ebuild patches are applied before; whatever you may
invent, PM has no way to prevent:
src_prepare() {
some_eclass_that_calls_eapply_user_exactly_once
epatch "something"
}
what you describe is not fixed by dying on second eapply_user call, and
'let be' actually means we have to face it, understand it and handle it
properly
> And if eapply_user is as undependable, why go thru the whole empty
> exercise in the first place? Just leave epatch_user alone, because
> after all, users who really want it to be dependable can already
> hook-apply it as necessary.
'must be called at least once' makes it quite dependable I think
> Thus, this really does need worked thru, either somehow forcing the
> eapply_user to be applied once, after everything else, ignoring
> earlier calls (the new src_prepare2 phase, with the PM running
> eapply_user between the two and 2 only doing whatever auto* magic,
> etc, needs done), or forcing "exactly once" wording, effectively
> forcing eclasses to behave and not call it, which in turn forces the
> ebuild to call both the individual eclass functions and eapply_user,
> at the appropriate time.
>
> But thinking about it a bit, what happens if eapply_user is defined
> as a PM function/phase that will be called exactly once... between
> src_prepare and src_configure?
>
> Then existing patch functionality can continue to be called by the
> eclasses as it is now, perhaps a bit of a mess, but no change so it's
> a mess we've generally already adjusted to, eapply_user gets called
> as a PM function, and all the auto* and etc magic gets called in
> src_configure, just before the normal configure functionality.
that's another solution, but src_configure was meant for, heh,
configure, and src_prepare was meant for preparing the sources;
calling autotools in something else than src_prepare triggers warnings
I think. Nothing prevents from adding new phases, but as already said,
it's a bit late for eapi6 :/
[...]
Alexis.
