Re: [gentoo-portage-dev] [PATCH gentoolkit 1/2] eclean: Rewrite findPackages()

2020-02-20 Thread Michael 'veremitz' Everitt
On 21/02/20 05:29, Matt Turner wrote:
> I found the original code to be nearly incomprehensible. Instead of
> populating a dict of potential binpkgs to remove and then removing from
> the to-be-removed list, just selectively add to-be-removed packages.
>
> Signed-off-by: Matt Turner 
> ---
> I switched from tabs to spaces in the process. I can revert back if
> desired.
>
Probably best to stick to tabs for consistency with the other portage code,
although naturally Zac probably better to ACK/NACK that.

Otherwise I think this is a good refresh. +1.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [Policy change] Package masking of live ebuilds

2020-02-18 Thread Michael 'veremitz' Everitt
On 18/02/20 19:52, Ulrich Mueller wrote:
> The devmanual says about live ebuilds:
>
> | CVS ebuilds must be either with empty KEYWORDS or package.masked
> | (but not both). Empty KEYWORDS are strongly preferred. This applies
> | to "live" ebuilds (-) and to ebuilds that extract a static
> | revision but still use CVS for fetching.
>
> As of today, I count 2123 live ebuilds in the Gentoo repository with
> empty KEYWORDS and 1 (one) ebuild with non-empty KEYWORDS but
> package.masked.
>
> So, can we finally make empty KEYWORDS mandatory and drop the part
> about package.masking?
>
> Ulrich
>
> [1] 
> https://devmanual.gentoo.org/ebuild-writing/functions/src_unpack/cvs-sources/index.html
> (Yes, there really should be a chapter about Git sources ...)
This sounds like an ideal opportunity for repoman/pkgcheck warnings .. no?



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] eclass/acct-user.eclass: disable pkg_* on Prefix.

2020-02-18 Thread Michael 'veremitz' Everitt
On 18/02/20 13:02, hero...@gentoo.org wrote:
> From: Benda Xu 
>
>   Gentoo Prefix runs with a normal user and cannot manage any other user.
>   Exit gracefully with a message.
>
> Closes: https://bugs.gentoo.org/709570
> Signed-off-by: Benda Xu 
> ---
>  eclass/acct-user.eclass | 10 ++
>  1 file changed, 10 insertions(+)
>
> diff --git a/eclass/acct-user.eclass b/eclass/acct-user.eclass
> index be6b3dd3e600..e3ec3966035d 100644
> --- a/eclass/acct-user.eclass
> +++ b/eclass/acct-user.eclass
> @@ -360,6 +360,11 @@ acct-user_pkg_preinst() {
>  acct-user_pkg_postinst() {
>   debug-print-function ${FUNCNAME} "${@}"
>  
> + if [[ ${EUID} != 0 ]] ; then
> + einfo "Insufficient privileges to execute ${FUNCNAME[0]}"
> + return 0
> + fi
> +
>   # NB: eset* functions check current value
>   esethome "${ACCT_USER_NAME}" "${ACCT_USER_HOME}"
>   esetshell "${ACCT_USER_NAME}" "${ACCT_USER_SHELL}"
> @@ -376,6 +381,11 @@ acct-user_pkg_postinst() {
>  acct-user_pkg_prerm() {
>   debug-print-function ${FUNCNAME} "${@}"
>  
> + if [[ ${EUID} != 0 ]] ; then
> + einfo "Insufficient privileges to execute ${FUNCNAME[0]}"
> + return 0
> + fi
> +
>   if [[ -z ${REPLACED_BY_VERSION} ]]; then
>   if [[ -z $(egetent passwd "${ACCT_USER_NAME}") ]]; then
>   ewarn "User account not found: ${ACCT_USER_NAME}"
Peanut gallery says 'ACK' +1



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Changes made by acct-* ebuilds

2020-02-14 Thread Michael 'veremitz' Everitt
On 14/02/20 19:48, Vadim A. Misbakh-Soloviov wrote:
>> And now you're changing the subject.  You've just claimed that *your*
>> user's group ownership will be overwritten and when challenged you
>> present the case of *system* user's group ownership being overwritten.
> Actually, he showed the rewrite of **system** user (that was modified 
> locally).
>
> And, as it already mentioned above, this behaviour violates Gentoo Philosophy 
> of not pretending to be smarter than user and don't dictate them a way to go.
>
> So, if the problem is only in the existance of the bug, I can create it 
> tomorrow morning.
> But it would be great to know that it wont be closed in a minute after with 
> "WONTFIX, works as expected".
>
> Also, as already stated, changing the stuff that was modified by user is 
> **prohibited**.
>
> P.S. I don't care about your  relations with whissi, but let's back to the 
> topic:
>
> [big red letters]
> We should **NEVER** ever rewrite any system configuration made by local 
> system 
> administrator (call it "user" or whatever). Dixi.
> [/big red letters]
>
> Modification of system users and groups are also covered by that user.
>
> So, we, actually don't need any changes to disable acct-* things at all and 
> make users to manage all the things by themselves.
> We need a change that will prevent any changes over **already existing** user.
>
> I think we should make it in a manner like:
> 1) when we install acct-pkg for a first time - CONFIG_PROTECT changes, and 
> let 
> user to review.
> 2) when we **reinstall** same package - do **nothing**. Although, I'm not 
> sure 
> here:
> on the one hand, why should we bother users by merging changes they already 
> did before,
> on the other hand, it can be useful way to reset to defaults in case if "all 
> this stuff is screwed up".
> 3) when we upgrade acct-package (assuming there was changes) - only allow 
> "positive" changes (group additions), but not negative (dropiing groups), and 
> anyway CONFIG_PROTECT all the changes.
>
>
> Well, there is also "kludgy way": does not globally reimplement anything, but:
> 1)  force CFGPROTECT
> 2) perform a "light" modification to only perform "positive" modifications 
> (see above) on users/groups, but no "negatives".
> It will anyway fix the both issues Whissi and OP had. 
>
There is a filthy hack which works around all this nonsense .. throw all
acct-* packages in a Package.Provided entry, and mask installation of any
other versions ..

*runs and hides*



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Changes made by acct-* ebuilds

2020-02-13 Thread Michael 'veremitz' Everitt
On 13/02/20 16:17, Mike Gilbert wrote:
> On Wed, Feb 12, 2020 at 8:32 PM Thomas Deutschmann  wrote:
>> In short: It was a very bad decision that acct-* stuff is *changing*
>> existing stuff. This must be turned of *by default*. Maybe provide a
>> setting a user can put into make.conf to opt into current, still new,
>> behavior but by default, a package should never ever make changes to
>> *existing* user (unless it knows for sure it was the only source
>> creating that user and nothing was changed since creation which isn't
>> easy to track).
> I think it would make sense to add some eclass variables that would
> turn user.eclass functions into no-ops.
>
> I don't agree that this should be happen by default. I suspect the
> majority of users do not wish to manage system users/groups
> themselves.
>
I would suggest anyone competent enough to build a kernel from scratch
(genkernel users, I'm ignoring you) should be equally at-home managing
system users and groups and associated permissions? Or am I perhaps
overestimating the average Genbuntu users here ... >,<




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH 3/3] app-admin/kube-bench: convert to go-module go.sum

2020-02-11 Thread Michael 'veremitz' Everitt
On 09/02/20 21:16, Michael 'veremitz' Everitt wrote:
> On 09/02/20 20:59, Michael 'veremitz' Everitt wrote:
>> On 09/02/20 20:57, Michael 'veremitz' Everitt wrote:
>>> On 09/02/20 20:55, Michał Górny wrote:
>>>> On Sun, 2020-02-09 at 20:38 +0000, Michael 'veremitz' Everitt wrote:
>>>>> Hrm, pardon my ignorance, but do 'we' really need to review 232 lines of
>>>>> Manifest?!
>>>> Pardon mine but do 'we' really need to read your useless comments
>>>> everywhere, all the time and just get irritated for no benefit to
>>>> Gentoo?
>>>>
>>> There's a really simple method to deal with that .. would you like me to
>>> explain, or would that be 'useless' too?
>>>
>> For the benefit of other readers, it's clear Michal is incapable of
>> implementing the measures I am thinking of .. or simply isn't aware of what
>> they might be?
>> which is quite unusual for a developer of his supposed capability ...
>>
> For the avoidance of doubt, whilst my ban from this list is enacted, here
> is the list of "Unacceptable behaviour" from the Gentoo Code of Conduct[1].
>
> "Deciding to suspend or ban someone isn't a decision to be taken lightly,
> but sometimes it has to happen. Below is a list of things that could result
> in disciplinary action. * Flaming and trolling. What is trolling? You are
> deemed to be trolling if you make comments intended to provoke an angry
> response from others. What is flaming? Flaming is the act of sending or
> posting messages that are deliberately hostile and insulting.
> * Posting/participating only to incite drama or negativity rather than to
> tactfully share information.
> * Being judgmental, mean-spirited or insulting. It is possible to
> respectfully challenge someone in a way that empowers without being
> judgemental.
> * Constantly purveying misinformation despite repeated warnings."
>
> It is left as an exercise for the reader, who is transgressing here...
>
My final posting to this list (for posting this I am insuring my permanent
banning) here is the correspondence from the "ComRel" or Community
Relations bug (currently private) in the subject of 'policing' the mailing
lists:
--
 David Seifert gentoo-dev 2020-02-10 15:18:53 GMT

M. J. Everitt (veremitz on IRC) has used the dev ML to post general chatter
which contributes zero to the discussion at hand and just lowers the
signal-to-noise ratio. Previously, when the ML had a whitelist instead of a
blacklist, I requested his removal already (bug 664688), and I'd like
comrel to vote on blacklisting him posting to the gentoo-dev ML.

Examples:
https://archives.gentoo.org/gentoo-dev/message/786a4475d72b67937716c9624354ba17
https://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg87819.html (ml
was down at the time)

Reproducible: Always

David Seifert 2020-02-10 15:19:19 GMT
Group: Community Relations
[tag] [reply] [\u2212] Comment 1 David Seifert gentoo-dev 2020-02-10
15:20:35 GMT

I vote yes (for a permanent ban).

[tag] [reply] [\u2212] Comment 2 Luca Barbato gentoo-dev 2020-02-10
20:05:37 GMT

I warned him again. Once he steps again out of boundary I'd link both
warnings and have him permabanned.-


Farewell folks.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH 3/3] app-admin/kube-bench: convert to go-module go.sum

2020-02-09 Thread Michael 'veremitz' Everitt
On 09/02/20 20:59, Michael 'veremitz' Everitt wrote:
> On 09/02/20 20:57, Michael 'veremitz' Everitt wrote:
>> On 09/02/20 20:55, Michał Górny wrote:
>>> On Sun, 2020-02-09 at 20:38 +, Michael 'veremitz' Everitt wrote:
>>>> Hrm, pardon my ignorance, but do 'we' really need to review 232 lines of
>>>> Manifest?!
>>> Pardon mine but do 'we' really need to read your useless comments
>>> everywhere, all the time and just get irritated for no benefit to
>>> Gentoo?
>>>
>> There's a really simple method to deal with that .. would you like me to
>> explain, or would that be 'useless' too?
>>
> For the benefit of other readers, it's clear Michal is incapable of
> implementing the measures I am thinking of .. or simply isn't aware of what
> they might be?
> which is quite unusual for a developer of his supposed capability ...
>
For the avoidance of doubt, whilst my ban from this list is enacted, here
is the list of "Unacceptable behaviour" from the Gentoo Code of Conduct[1].

"Deciding to suspend or ban someone isn't a decision to be taken lightly,
but sometimes it has to happen. Below is a list of things that could result
in disciplinary action. * Flaming and trolling. What is trolling? You are
deemed to be trolling if you make comments intended to provoke an angry
response from others. What is flaming? Flaming is the act of sending or
posting messages that are deliberately hostile and insulting.
* Posting/participating only to incite drama or negativity rather than to
tactfully share information.
* Being judgmental, mean-spirited or insulting. It is possible to
respectfully challenge someone in a way that empowers without being
judgemental.
* Constantly purveying misinformation despite repeated warnings."

It is left as an exercise for the reader, who is transgressing here...



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH 3/3] app-admin/kube-bench: convert to go-module go.sum

2020-02-09 Thread Michael 'veremitz' Everitt
On 09/02/20 20:57, Michael 'veremitz' Everitt wrote:
> On 09/02/20 20:55, Michał Górny wrote:
>> On Sun, 2020-02-09 at 20:38 +, Michael 'veremitz' Everitt wrote:
>>> Hrm, pardon my ignorance, but do 'we' really need to review 232 lines of
>>> Manifest?!
>> Pardon mine but do 'we' really need to read your useless comments
>> everywhere, all the time and just get irritated for no benefit to
>> Gentoo?
>>
> There's a really simple method to deal with that .. would you like me to
> explain, or would that be 'useless' too?
>
For the benefit of other readers, it's clear Michal is incapable of
implementing the measures I am thinking of .. or simply isn't aware of what
they might be?
which is quite unusual for a developer of his supposed capability ...



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH 3/3] app-admin/kube-bench: convert to go-module go.sum

2020-02-09 Thread Michael 'veremitz' Everitt
On 09/02/20 20:55, Michał Górny wrote:
> On Sun, 2020-02-09 at 20:38 +0000, Michael 'veremitz' Everitt wrote:
>> Hrm, pardon my ignorance, but do 'we' really need to review 232 lines of
>> Manifest?!
> Pardon mine but do 'we' really need to read your useless comments
> everywhere, all the time and just get irritated for no benefit to
> Gentoo?
>
There's a really simple method to deal with that .. would you like me to
explain, or would that be 'useless' too?



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH 3/3] app-admin/kube-bench: convert to go-module go.sum

2020-02-09 Thread Michael 'veremitz' Everitt
On 09/02/20 20:47, Robin H. Johnson wrote:
> On Sun, Feb 09, 2020 at 08:38:23PM +0000, Michael 'veremitz' Everitt wrote:
>> On 09/02/20 20:31, Robin H. Johnson wrote:
> ...
>> Hrm, pardon my ignorance, but do 'we' really need to review 232 lines of
>> Manifest?!
> No, but I wanted to show scale of Manifest that is going to be present
> in covering all the dependencies for static-build languages like Golang.
>
> Every entry in EGO_SUM is 2-3 files that need to be fetched (two tiny
> files, one a bit larger [zip of source]).
>
> app-admin/kube-bench has _77_ dependencies, each with 3 distfiles.
>
Yoikes, gotcha ! :]



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH 3/3] app-admin/kube-bench: convert to go-module go.sum

2020-02-09 Thread Michael 'veremitz' Everitt
On 09/02/20 20:31, Robin H. Johnson wrote:
> Signed-off-by: Robin H. Johnson 
> ---
>  app-admin/kube-bench/Manifest | 232 ++
>  .../kube-bench/kube-bench-0.2.3-r1.ebuild | 120 +
>  2 files changed, 352 insertions(+)
>  create mode 100644 app-admin/kube-bench/kube-bench-0.2.3-r1.ebuild
>
> diff --git app-admin/kube-bench/Manifest app-admin/kube-bench/Manifest
> index 0321873230e4..700b432ae04e 100644
> --- app-admin/kube-bench/Manifest
> +++ app-admin/kube-bench/Manifest
> @@ -1,3 +1,171 @@
> +DIST cloud.google.com%2Fgo%2F@v%2Fv0.37.4.info 51 BLAKE2B 
> 0b87b5b8f8ea4ccdd26272750a7fe8d9228d451c46b166f4478c89c0c7918bb6eb2d611c416795ea9e09c121754eed102933e996b6f4a731ad0a50cb97a01875
>  SHA512 
> ad485c9d6b16cbc36ec0e3b85ba9d80f7d46f68f8fb36bcfe721774a6e46d04a23705b166d8f606ca44d21fd412c97fc0d68f2e0d9a33011cc89aa9e9a856229
> +DIST cloud.google.com%2Fgo%2F@v%2Fv0.37.4.mod 1006 BLAKE2B 
> ed912b9fe91ee4e16f58b599232ea85bc1f994a290e8f514f6d053bad6312422c18e868b9d419079c63cd547781dcf82994b53af6ef10bb23fea05b66f55747f
>  SHA512 
> 8e12292cb0c83d0ea8d4227c27fdabaed182de6f42bc6a29bd53848c41c87754994dd50df282ff30ab78411d54a6667a371d84b620d1b02f3f953429e3c2e97b
> +DIST cloud.google.com%2Fgo%2F@v%2Fv0.37.4.zip 2717957 BLAKE2B 
> d5de25820cbee7f89ca2fce9c721b59839c1d1c38023e5d0ae153423b3ffc6b5e344d978d5a5cd18f99f732b56946a779adf82b1074eb78a2feccbdbd9962739
>  SHA512 
> 7bb51ac0b816eb709386e0116fdd2e7cd9f3e6dc55db7b0d2ea5e221b45647b05452da36839ef840c701d74fa0aabd71b92459944761b686aa91379f935ca5dc
> +DIST github.com%2F!burnt!sushi%2Ftoml%2F@v%2Fv0.3.1.info 50 BLAKE2B 
> 142643662a79ba5e13604668b5e5983c53c794ad5f6185e25bf4906c6a5a57f04fe30ff33be7da434799dea50e8562a68717a889f046eeb1776479ca781afb49
>  SHA512 
> 1e953b8c664b2c25982d7458129e61a41e9b91a75eea46ce2d0932fd14ea6a425810d1fb4dfe32988a41fa4bb975bdcd04a03439b7474b3d288a4b2d46067bd6
> +DIST github.com%2F!burnt!sushi%2Ftoml%2F@v%2Fv0.3.1.mod 34 BLAKE2B 
> ce54a247aef91043830bdf0603c8452ba38eceb1495af6e7a74c9119234a0dc5cd080cb25258c28f5e270acf91189a5ed33e361cbf17de2be5e37dadbda1d90d
>  SHA512 
> 320941bc3b7fb8bc595e6135cbc513a7583d129f0cd92508055291e141191066303cf75148e25198c21f6c6c539a790ea3210f3ecf5de6a2a03b70c753091146
> +DIST github.com%2F!burnt!sushi%2Ftoml%2F@v%2Fv0.3.1.zip 56132 BLAKE2B 
> 5edcfe991d7fc40094d637bae8d8d6f1f897ab3d3786ade2bb80287738103264520681ced8d30d2037253206c32d3f867f4d024a571cb9aad030ebc451e198eb
>  SHA512 
> 43ed64ae515738487e9b75a2290d0b2bc25e83c021a9f29b21487c37adbf34e74e1e7d3d5ec0dfe678c8396356f95c3993a5f5610d1791ff62056cd182a4272f
> +DIST github.com%2F!puerkito!bio%2Fpurell%2F@v%2Fv1.1.1.info 87 BLAKE2B 
> 5ba3587337f8cd5c67c84a707a6af2511996a78fdba29e7cc5a3a2d1ae9a0a56169b663f00831687d615786f89eb57b606d6e6106bae58e91290f4360e048152
>  SHA512 
> 37aba7f1fe097944d8f9600f02a578786015e955c67ade275329ca932e827765a279ac7af9795a2f607df4ae8663602ff1aa942c85674e8bbbef5b2d01a84d7e
> +DIST github.com%2F!puerkito!bio%2Fpurell%2F@v%2Fv1.1.1.mod 37 BLAKE2B 
> 9aad8d876b88c7c8976667747135ea2496c21542d029e879d80490e9d979923ac3060f65ddc443044db8eff2f92e2eed6b18682822f6b5706c5605d8de92ecbb
>  SHA512 
> 8382734877c9dc6a9c8a59b12d9735b6f971ea72ddeeb9985ea0cd0573820991a4b936baa1a643d38b694f1df7395d7b0d119f4f52be8d947f00adba96773989
> +DIST github.com%2F!puerkito!bio%2Fpurell%2F@v%2Fv1.1.1.zip 15402 BLAKE2B 
> efbf0c8a3f7e771b5a90ff620bfd513d476e21a672e3f7446202861121dcea08fa95d33b0438b6f1882273630e3cfe756c5934a14a1ab6b2676b117273616097
>  SHA512 
> 4c39d0907455b1c60e539e8497477e676bf7656c3b30996d55104d6129ebaa02079e5d7d27856352446ec2570c54f0d945be83e2a3445a025c85d12834120ea6
> +DIST 
> github.com%2F!puerkito!bio%2Furlesc%2F@v%2Fv0.0.0-20170810143723-de5bf2ad4578.info
>  78 BLAKE2B 
> 624792caee6d10a9767136e6206baa0f6874a126ceeba764c40dcf697850bc723299dd028c5c254262fc25a5b5b84878b0b874f71a267c9199a003f94150ddcb
>  SHA512 
> 5fa248cefba87b4376c9ebf40b8d271fba646106c68b903c90262344d054def1e7da472d059d09ae98b9c1f4ed2570e116eddf84cf544f839a49f312ed5b0e89
> +DIST 
> github.com%2F!puerkito!bio%2Furlesc%2F@v%2Fv0.0.0-20170810143723-de5bf2ad4578.mod
>  37 BLAKE2B 
> 28c9393f5171487d23b732afcbb1d3d835d13d1a63b7e852fd3205925742fcf5a686c39b0600359e9052770360e9396f6bfe52aecb51e3ed0a23611a2853
>  SHA512 
> a2b3211e3520fdef3d5c1991b5ad4b3745f4bb1b49be3afc5b1936c82b2a3058231b6cc17c63c85402cae0b80f037a70051d42738e89a708865e43dabf7b7b8a
> +DIST 
> github.com%2F!puerkito!bio%2Furlesc%2F@v%2Fv0.0.0-20170810143723-de5bf2ad4578.zip
>  8169 BLAKE2B 
> 61db06641c2c1db4102b72c097f63fae0bff296481556fa16e66ddd1808478aded29256befdc3d767b72f3abc91e376ae61656f8da2cfbfbb5ffbfe3fde20361
>  SHA512 
> 9746be89f7fc5d50acd6376f77d43754e4a40d9da173a0b3226b78b1b1fab9afd859f15332ae5a429ce1e0e85227ceef05d94f2237c4969a8e6fc5e8454937e6
> +DIST github.com%2Fdavecgh%2Fgo-spew%2F@v%2Fv1.1.1.info 50 BLAKE2B 
> 6189d1d85ef1da6c5f08a41697fc1690d6bf3cbef094affefdf78aa5c4e2342facdb1799d17c2bb1095184b0088f91e3ed54278857e82b5c1b5ed18af3923434
>  SHA512 
> 

Re: [gentoo-dev] Last rites: sys-firmware/iwl6050-ucode

2020-02-07 Thread Michael 'veremitz' Everitt
On 07/02/20 20:39, Matt Turner wrote:
> On Fri, Feb 7, 2020 at 12:03 PM Michael 'veremitz' Everitt
>  wrote:
>> On 07/02/20 19:50, Matt Turner wrote:
>>> On Fri, Feb 7, 2020 at 11:39 AM Ulrich Mueller  wrote:
>>>>>>>>> On Fri, 07 Feb 2020, Matt Turner wrote:
>>>>> On Fri, Feb 7, 2020 at 9:10 AM Mike Pagano  wrote:
>>>>>> # Mike Pagano  (2020-02-07)
>>>>>> # The standalone ebuild for this driver is made
>>>>>> # unnecessary as it is included in the package:
>>>>>> # sys-kernel/linux-firmware
>>>>>> sys-firmware/iwl6050-ucode
>>>>> How about all the others as well?
>>>>> sys-firmware/iwl1000-ucode
>>>>> sys-firmware/iwl3160-7260-bt-ucode
>>>>> sys-firmware/iwl3160-ucode
>>>>> sys-firmware/iwl6005-ucode
>>>>> sys-firmware/iwl6030-ucode
>>>>> sys-firmware/iwl7260-ucode
>>>>> sys-firmware/iwl8000-ucode
>>>> I had asked the same question back in November, but an argument against
>>>> it was that sys-kernel/linux-firmware is quite a monster. In the default
>>>> configuration, its installation footprint is 515 MiB.
>>> Oh yeah. The thread where the person arguing for keeping them didn't
>>> know about USE=savedconfig :)
>>>
>> You still have to install the full 515MiB before you can apply savedconfig,
>> unless you already know the list of firmwares included, and create the file
>> in advance. For some systems (esp. storage constrained) that's not a very
>> good option ...
> Even that's not true. Just look at the git repo.
>
In that case, and in truth this is what I do in practice, I just simply
download the relevant firmware files Direct from git, and side-step all
this package nonsense :)



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Last rites: sys-firmware/iwl6050-ucode

2020-02-07 Thread Michael 'veremitz' Everitt
On 07/02/20 19:50, Matt Turner wrote:
> On Fri, Feb 7, 2020 at 11:39 AM Ulrich Mueller  wrote:
>>> On Fri, 07 Feb 2020, Matt Turner wrote:
>>> On Fri, Feb 7, 2020 at 9:10 AM Mike Pagano  wrote:
 # Mike Pagano  (2020-02-07)
 # The standalone ebuild for this driver is made
 # unnecessary as it is included in the package:
 # sys-kernel/linux-firmware
 sys-firmware/iwl6050-ucode
>>> How about all the others as well?
>>> sys-firmware/iwl1000-ucode
>>> sys-firmware/iwl3160-7260-bt-ucode
>>> sys-firmware/iwl3160-ucode
>>> sys-firmware/iwl6005-ucode
>>> sys-firmware/iwl6030-ucode
>>> sys-firmware/iwl7260-ucode
>>> sys-firmware/iwl8000-ucode
>> I had asked the same question back in November, but an argument against
>> it was that sys-kernel/linux-firmware is quite a monster. In the default
>> configuration, its installation footprint is 515 MiB.
> Oh yeah. The thread where the person arguing for keeping them didn't
> know about USE=savedconfig :)
>
You still have to install the full 515MiB before you can apply savedconfig,
unless you already know the list of firmwares included, and create the file
in advance. For some systems (esp. storage constrained) that's not a very
good option ...



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Ebuild Generators

2020-02-03 Thread Michael 'veremitz' Everitt
On 03/02/20 12:19, Benda Xu wrote:
> Hi Gerion,
>
> Gerion Entrup  writes:
>
>>> Yes, that makes a lot of sense.  The R overlay follows this model.  Most
>>> of the ebuilds are automated.  When an ebuild generation fails, we add
>>> the ebuild manually, understand it and then update the generator to
>>> cover it in the future.
>> Is this possible in all cases? I think of adding custom patches,
>> appropriate mapping of dependencies, check for things like desktop
>> icon cache...
> That's too complex to handle automatically.  Luckily, in R overlay, such
> packages are less than 5%.  An ebuild generator is based on the
> observation that many language-specific packages are trivial to fetch,
> compile and install.
>
 I'm only "maintaining" an overlay so maybe I'm  missing experience
 but I often have wished a tool that automatically parses the language 
 specific
 packaging files and is able to generate a primitive ebuild out of that.
 Maybe it even can do this in an interactive way:
 "Hey, upstream needs the dependency 'foo'. In the Gentoo packages I have 
 found
 'dev-bar/foo' and 'dev-util/foo'. What is the correct one?"
>>> Yes, that's the way R overlay is working.  And I have a similar plan and
>>> proof-of-concept solution for the Java Maven overlay.
>> Nice to hear. I think, it is meaningful to solve all generation with one
>> tool. Maybe it can even "recognize" the used build system and package
>> database. Is this your plan, too?
> No, I don't think it possible as far as I can see...  That would be a
> strong AI.
>
> Yours,
> Benda
There was some interest in doing this for PyPI packages for Liguros linux.
See https://gitlab.com/liguros/bugs/issues/75 .



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Last rites: net-im/silc-toolkit

2020-01-18 Thread Michael 'veremitz' Everitt
On 19/01/20 06:23, Joonas Niilola wrote:
> On 1/19/20 5:44 AM, David Seifert wrote:
>> On Sat, 2020-01-18 at 23:48 +, Michael 'veremitz' Everitt wrote:
>>> On 18/01/20 22:12, David Seifert wrote:
>>>> # David Seifert  (2020-01-18)
>>>> # Leftover from silc* removal (#522916), unmaintained, no
>>>> # upstream releases since 2014, no revdeps, EAPI-4.
>>>> # Bug #705462. Removal in 14 days.
>>>> net-im/silc-toolkit
>>>>
>>>>
> After
>
>>> Looks like you missed:
>>> https://archives.gentoo.org/gentoo-dev/message/16247cdab4e597a5530eaec8b1229a62
>
> I asked the maintainer if he was ok with
>
>> Looks like you missed:
>> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=dfe1c280e312416b3856057ccd6c9f88bcaa1c88
> And he acked. I just didn't have time to make the PR so soap stepped in.
> So all is good. Thanks.
>
>
> -- juippis
>
>
>
WFM cheers.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Last rites: net-im/silc-toolkit

2020-01-18 Thread Michael 'veremitz' Everitt
On 18/01/20 22:12, David Seifert wrote:
> # David Seifert  (2020-01-18)
> # Leftover from silc* removal (#522916), unmaintained, no
> # upstream releases since 2014, no revdeps, EAPI-4.
> # Bug #705462. Removal in 14 days.
> net-im/silc-toolkit
>
>
Looks like you missed:
https://archives.gentoo.org/gentoo-dev/message/16247cdab4e597a5530eaec8b1229a62

Yw.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-portage-dev] [PATCH] Add QA check for unresolved soname dependencies (bug 704320)

2020-01-05 Thread Michael 'veremitz' Everitt
On 06/01/20 06:38, Zac Medico wrote:
> Example output for maven-bin-3.6.2 (bug 704618):
>
>  * QA Notice: Unresolved soname dependencies:
>  *
>  */usr/share/maven-bin-3.6/lib/jansi-native/freebsd32/libjansi.so: 
> libc.so.7 libutil.so.9
>  */usr/share/maven-bin-3.6/lib/jansi-native/freebsd64/libjansi.so: 
> libc.so.7 libutil.so.9
>  *
>
> This warning comes up when a library or executable has one or
> more soname dependencies (found in its NEEDED.ELF.2 metadata)
> that could not be resolved by usual means. If you run ldd
> on files like these then it will report a "not found" error
> for each unresolved soname dependency. In order to correct
> problems with soname dependency resolution, use one or more
> of the approaches described in the following sections.
>
> Content of the NEEDED.ELF.2 metadata file may be useful
> for debugging purposes. Find the NEEDED.ELF.2 file in the
> ${D}/../build-info/ directory after the ebuild src_install
> phase completes, or in the /var/db/pkg/*/*/ directory for an
> installed package. Each line of the NEEDED.ELF.2 file contains
> semicolon separated values for a single ELF file. The soname
> dependencies are found in the DT_NEEDED column:
>
>  E_MACHINE;path;DT_SONAME;DT_RUNPATH;DT_NEEDED;multilib category
>
> External dependencies
>
> For packages that install pre-built binaries, it may be possible
> to resolve soname dependencies simply by adding dependencies
> for one or more other packages that are known to provide the
> needed sonames.
>
> Removal of unecessary files
>
> For packages that install pre-built binaries, it may be possible
> to resolve soname dependencies simply by removing unnecessary
> files which have unresolved soname dependencies. For example,
> some pre-built binary packages include binaries intended for
> irrelevant architectures or operating systems, and these files
> can simply be removed because they are unnecessary.
>
> Addition of DT_RUNPATH entries
>
> If the relevant dependencies are installed in a location that
> is not included in the dynamic linker search path, then it's
> necessary for files to include a DT_RUNPATH entry which refers
> to the appropriate directory. The special $ORIGIN value can
> be used to create a relative path reference in DT_RUNPATH,
> where $ORIGIN is a placeholder for the directory where the
> file having the DT_RUNPATH entry is located.
>
> For pre-built binaries, it may be necessary to fix up
> DT_RUNPATH using patchelf --set-rpath. For example, use
> patchelf --set-rpath '$ORIGIN' if a given binary should link
> to libraries found in the same directory as the binary itself,
> or use patchelf --set-rpath '$ORIGIN/libs' if a given binary
> should link to libraries found in a subdirectory named libs
> found in the same directory as the binary itself.
>
> For binaries built from source, a flag like
> -Wl,-rpath,/path/of/directory/containing/libs will create
> binaries with the desired DT_RUNPATH entry.
>
> Bug: https://bugs.gentoo.org/704320
> Signed-off-by: Zac Medico 
> ---


Looks awesome!

One comment: would it be helpful for developers/maintainers to have some
indication of what's going on here, and what attempts portage is making in
this regard? Something like a 'verbose' option that would spit out some
debugging info so that /if/ something goes wrong, or the outcome wasn't
what was intended, then this can be picked up and corrected somehow else?

I think automation is great for picking these issues up, and shining a
light on where/why something goes wrong, but sometimes it needs a few
minutes of human intervention to achieve the sane outcome in many
circumstances.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Keywordreqs and slacking arch teams

2020-01-04 Thread Michael 'veremitz' Everitt
On 04/01/20 11:09, Rolf Eike Beer wrote:
> Am Freitag, 3. Januar 2020, 11:00:14 CET schrieb Rolf Eike Beer:
>> Am Freitag, 3. Januar 2020, 03:40:35 CET schrieb Aaron Bauman:
>>> On January 2, 2020 6:35:08 PM EST, Rolf Eike Beer  wrote:
 Am Freitag, 3. Januar 2020, 00:25:06 CET schrieb Mike Pagano:
> hppa is making us keep old kernels around [1].  Should the kernel team
> be
> doing more to get your attention then CC'ing hppa on all of the kernel
> STABLEREQ bugs [2]?
 I only run vanilla-sources since there are still lot of cache
 corruption
 problems in hppa kernels, or whatever makes them flaky.

 Linux pioneer 5.4.6-parisc64 #1 SMP Fri Dec 27 10:23:09 CET 2019 parisc64
 PA8800 (Mako) 9000/785/C8000 GNU/Linux
 Linux voyager 5.4.6-parisc #1 Fri Dec 27 15:46:43 CET 2019 parisc PA8600
 (PCX-W+) 9000/785/C3600 GNU/Linux

 So _I_ personally would say just drop old kernels, but that is in no
 way
 authorative.
>>> Ugh. gentoo-sources is just a patch (trivial) on top of vanilla-kernel
>>> sources of each stable and LTS version.
>> If it's just that I could test them, but this still be no LTS version that I
>> would look at.
> So, do you want me to stable a random gentoo-sources (usually the most recent 
> one) every few weeks when I just happen to upgrade my machine?
>
> Eike
I don't think that works very well with kernel/security-team stabilisation
policies, sadly.

Is there any possibility you would be able to do a stabilisation run, and
do a reboot cycle on one LTS branch (of choice, eg. most recent) and then
revert to your preferred kernel afterwards?

I appreciate this is a rather onerous process on older hardware, but just
trying to think of some form of semi-compromise that prevents potential
de-keywording, without also suggesting that something that genuinely has
issues is either (1) working or (2) supported, if so.

I believe Whissi is leading kernel stabilisation requests, on behalf of
security- and kernel- teams, so maybe a chat with him may be fruitful.
Cheers,
veremitz/Michael.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH v2] ruby-ng.eclass: Include (-) in RUBY_TARGETS USE-dependencies

2020-01-03 Thread Michael 'veremitz' Everitt
On 03/01/20 10:36, David Seifert wrote:
> On Thu, 2020-01-02 at 21:54 +0000, Michael 'veremitz' Everitt wrote:
>> On 02/01/20 21:08, Michał Górny wrote:
>>> On Thu, 2020-01-02 at 21:15 +0100, Ulrich Mueller wrote:
>>>>>>>>> On Thu, 02 Jan 2020, Michał Górny wrote:
>>>>> --- a/eclass/ruby-ng.eclass
>>>>> +++ b/eclass/ruby-ng.eclass
>>>>> @@ -137,7 +137,7 @@ ruby_samelib() {
>>>>>   local res=
>>>>>   for _ruby_implementation in $(_ruby_get_all_impls); do
>>>>>   has -${_ruby_implementation} $@ || \
>>>>> - res="${res}ruby_targets_${_ruby_impleme
>>>>> ntation}?,"
>>>>> + res="${res}ruby_targets_${_ruby_impleme
>>>>> ntation}(-)?,"
>>>>>   done
>>>>>  
>>>>>   echo "[${res%,}]"
>>>> Hadn't we established that ruby_samelib() is dead code, no longer
>>>> used
>>>> since 2010?
>>>>
>>> You did.  However, it isn't marked as private API and I'm not the
>>> eclass
>>> maintainer to take care of removing public API.  I have no clue if
>>> Ruby
>>> project doesn't have some secret overlays using it.
>>>
>>  You can't use QA super-powerz ?! BDFL + sub-BDFL ?!
>> *
>>
>> * Thought the tags probably worth making explicit
>>
> Can you please stop polluting the -dev mailing list with this senseless
> chatter?
>
>
Perhaps I should remind you that this is a public mailing list (or hasn't
successfully been censored Yet) and not a private communication channel for
developers (see -core for this). But I don't need to tell you this



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Vanilla sources

2020-01-03 Thread Michael 'veremitz' Everitt
On 03/01/20 14:48, Toralf Förster wrote:
> On 1/3/20 3:46 PM, Rich Freeman wrote:
>> If OpenRC contains a vulnerability wouldn't it make more sense to set
>> this as part of OpenRC,
> Indeed.
>
> Furthermore there's a nifty page 
> https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings
> which yields for me to this /etc/sysctl.d/local.conf :
>
>
> #   Restrict potential illegal access via links
> # 
> fs.protected_hardlinks = 1
> fs.protected_symlinks = 1 
>
> #
> # https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project#CONFIGs
> #
>
> # Try to keep kernel address exposures out of various /proc files (kallsyms, 
> modules, etc).
> kernel.kptr_restrict = 1
>
> # Avoid kernel memory address exposures via dmesg.
> kernel.dmesg_restrict = 1
>
> # Block non-uid-0 profiling (needs distro patch, otherwise this is the same 
> as "= 2")
> kernel.perf_event_paranoid = 3
>
> # Turn off kexec, even if it's built in.
> kernel.kexec_load_disabled = 1
>
> # Avoid non-ancestor ptrace access to running processes and their credentials.
> kernel.yama.ptrace_scope = 1
>
> # Disable User Namespaces, as it opens up a large attack surface to 
> unprivileged users.
> user.max_user_namespaces = 0
>
> # Turn off unprivileged eBPF access.
> kernel.unprivileged_bpf_disabled = 1
>
> # Turn on BPF JIT hardening, if the JIT is enabled.
> net.core.bpf_jit_harden = 2
>
>
FWIW, there is a move to add further hardening options to the
Gentoo-sources kernel - bug 689154, based on the kernsec recommendations.
Further details of proposals, and inspiration, are in the bug.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Keywordreqs and slacking arch teams

2020-01-02 Thread Michael 'veremitz' Everitt
On 02/01/20 23:35, Rolf Eike Beer wrote:
> Am Freitag, 3. Januar 2020, 00:25:06 CET schrieb Mike Pagano:
>> On Thursday, January 2, 2020 3:32:12 PM EST Rolf Eike Beer wrote:
 - Allowed a simple "Add keyword(s)  for package " interface,

   that intelligently created an issue and a target list, and then once
   the list was built, constantly ensured the list to be valid, or
   determined automatically when sub-work was completed and reducing the
   published list automatically, and then responded to potential issues
   based on changes in git, ( as opposed to being only triggered when
   the bug was touched )
>>> As someone who does both keywordings and stabilizations regularly on hppa
>>> and sparc I think I must share a bit of my experiences:
>> 
>>
>> hppa is making us keep old kernels around [1].  Should the kernel team be
>> doing more to get your attention then CC'ing hppa on all of the kernel
>> STABLEREQ bugs [2]?
> I only run vanilla-sources since there are still lot of cache corruption 
> problems in hppa kernels, or whatever makes them flaky.
>
> Linux pioneer 5.4.6-parisc64 #1 SMP Fri Dec 27 10:23:09 CET 2019 parisc64 
> PA8800 (Mako) 9000/785/C8000 GNU/Linux
> Linux voyager 5.4.6-parisc #1 Fri Dec 27 15:46:43 CET 2019 parisc PA8600 (PCX-
> W+) 9000/785/C3600 GNU/Linux
>
> So _I_ personally would say just drop old kernels, but that is in no way 
> authorative.
>
> Eike
Is it viable at all to test gentoo-sources or would it be better simply to
unkeyword?



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH v2] ruby-ng.eclass: Include (-) in RUBY_TARGETS USE-dependencies

2020-01-02 Thread Michael 'veremitz' Everitt
On 02/01/20 21:08, Michał Górny wrote:
> On Thu, 2020-01-02 at 21:15 +0100, Ulrich Mueller wrote:
>>> On Thu, 02 Jan 2020, Michał Górny wrote:
>>> --- a/eclass/ruby-ng.eclass
>>> +++ b/eclass/ruby-ng.eclass
>>> @@ -137,7 +137,7 @@ ruby_samelib() {
>>> local res=
>>> for _ruby_implementation in $(_ruby_get_all_impls); do
>>> has -${_ruby_implementation} $@ || \
>>> -   res="${res}ruby_targets_${_ruby_implementation}?,"
>>> +   res="${res}ruby_targets_${_ruby_implementation}(-)?,"
>>> done
>>>  
>>> echo "[${res%,}]"
>> Hadn't we established that ruby_samelib() is dead code, no longer used
>> since 2010?
>>
> You did.  However, it isn't marked as private API and I'm not the eclass
> maintainer to take care of removing public API.  I have no clue if Ruby
> project doesn't have some secret overlays using it.
>
 You can't use QA super-powerz ?! BDFL + sub-BDFL ?! *

* Thought the tags probably worth making explicit



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-portage-dev] [PATCH gentoolkit 1/2] eclean: Fix typos

2020-01-02 Thread Michael 'veremitz' Everitt
On 02/01/20 18:57, Matt Turner wrote:
> Signed-off-by: Matt Turner 
> ---
>  pym/gentoolkit/eclean/cli.py| 4 ++--
>  pym/gentoolkit/eclean/search.py | 2 +-
>  2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/pym/gentoolkit/eclean/cli.py b/pym/gentoolkit/eclean/cli.py
> index 1d2f52b..1a99b3e 100644
> --- a/pym/gentoolkit/eclean/cli.py
> +++ b/pym/gentoolkit/eclean/cli.py
> @@ -304,7 +304,7 @@ def parseArgs(options={}):
>   options['size-limit'] = 0
>   options['verbose'] = False
>   options['ignore-failure'] = False
> - # if called by a well-named symlink, set the acction accordingly:
> + # if called by a well-named symlink, set the action accordingly:
>   action = None
>   # temp print line to ensure it is the svn/branch code running, etc..
>   #print(  "## svn/branch/gentoolkit_eclean ### ==> ", 
> os.path.basename(sys.argv[0]))
> @@ -400,7 +400,7 @@ def doAction(action,options,exclude={}, output=None):
>   )
>  
>   # initialize our cleaner
> - cleaner = CleanUp( output.progress_controller)
> + cleaner = CleanUp(output.progress_controller)
>  
>   # actually clean files if something was found
>   if clean_me:
> diff --git a/pym/gentoolkit/eclean/search.py b/pym/gentoolkit/eclean/search.py
> index ce455a3..58bd97e 100644
> --- a/pym/gentoolkit/eclean/search.py
> +++ b/pym/gentoolkit/eclean/search.py
> @@ -574,7 +574,7 @@ def findPackages(
>   del clean_me[cpv]
>   continue
>   if portage.cpv_getkey(cpv) in cp_all and 
> port_dbapi.cpv_exists(cpv):
> - # exlusion because of --package-names
> + # exclusion because of --package-names
>   del clean_me[cpv]
>  
>   # the getname method correctly supports FEATURES=binpkg-multi-instance,
LGTM fwiw.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] git-r3.eclass: Handle recursive submodules in EGIT_SUBMODULES

2019-12-30 Thread Michael 'veremitz' Everitt
On 30/12/19 14:11, Michał Górny wrote:
> On Mon, 2019-12-30 at 14:03 +0000, Michael 'veremitz' Everitt wrote:
>> On 30/12/19 13:30, Michał Górny wrote:
>>> Match recursive submodules using their full paths rather than path
>>> relatively to the parent submodule.
>>>
>>> Closes: https://bugs.gentoo.org/694494
>>> Signed-off-by: Michał Górny 
>>> ---
>>>  eclass/git-r3.eclass | 27 +++
>>>  1 file changed, 19 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/eclass/git-r3.eclass b/eclass/git-r3.eclass
>>> index 144236c6ac38..663fd939b295 100644
>>> --- a/eclass/git-r3.eclass
>>> +++ b/eclass/git-r3.eclass
>>> @@ -401,16 +401,22 @@ _git-r3_set_gitdir() {
>>>  }
>>>  
>>>  # @FUNCTION: _git-r3_set_submodules
>>> -# @USAGE: 
>>> +# @USAGE:  
>>>  # @INTERNAL
>>>  # @DESCRIPTION:
>> 
>>
>> How is this backward compatible?
>>
> This is an internal function.
>
Ah thanks. id10t check passed! :]



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] git-r3.eclass: Handle recursive submodules in EGIT_SUBMODULES

2019-12-30 Thread Michael 'veremitz' Everitt
On 30/12/19 13:30, Michał Górny wrote:
> Match recursive submodules using their full paths rather than path
> relatively to the parent submodule.
>
> Closes: https://bugs.gentoo.org/694494
> Signed-off-by: Michał Górny 
> ---
>  eclass/git-r3.eclass | 27 +++
>  1 file changed, 19 insertions(+), 8 deletions(-)
>
> diff --git a/eclass/git-r3.eclass b/eclass/git-r3.eclass
> index 144236c6ac38..663fd939b295 100644
> --- a/eclass/git-r3.eclass
> +++ b/eclass/git-r3.eclass
> @@ -401,16 +401,22 @@ _git-r3_set_gitdir() {
>  }
>  
>  # @FUNCTION: _git-r3_set_submodules
> -# @USAGE: 
> +# @USAGE:  
>  # @INTERNAL
>  # @DESCRIPTION:


How is this backward compatible?



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Keywordreqs and slacking arch teams

2019-12-28 Thread Michael 'veremitz' Everitt
On 28/12/19 11:32, Kent Fredric wrote:
> On Sat, 28 Dec 2019 11:14:15 +
> Michael 'veremitz' Everitt  wrote:
>
>> I know I'm gonna be shot down in flames, because $heresy, but here is where
>> a package 'database' would actually work quite well, because you can
>> trivially create a query that pulls this data out, and sorts it by package
>> category or maintainer or whatever you like .
> Oh, and once upon a time, there was actually a trick you could do to
> make portage keep its metadata caches in an SQLite database, which had
> its benefits, and I even had a rough tool I wrote in ruby and shared on
> the old (defunct) wiki that helped do quick database queries.
>
> But the trick actually makes portage slower in multiple ways, and it
> never really got widespread love.
>
> ( Though I would argue how the data was stored was also inadequate for
> a lot of other tasks one might want to do with a database, like,
> keeping DEPEND stored in its string format )
Note:  we're nnot acttually talking about replacing portage here, just
creating a tool thiink php script web tthingy)) that will do some of
the pre-screeninng wok that AT hate (eg what kensiington did  with
stable-bbot)

* with apologies for keyboard/remote-access la creating typo hell.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Keywordreqs and slacking arch teams

2019-12-28 Thread Michael 'veremitz' Everitt
On 28/12/19 11:05, Kent Fredric wrote:
> On Sat, 28 Dec 2019 10:35:09 +0100
> Fabian Groffen  wrote:
>
>> Hmmm, interested to hear what kind of things you're thinking about here.
> A lot of the "Work" of filing a keyword request is modelling all the
> consequential keywordings that have to take place.
>
> If there was say, a web based UI, that:
>
> - Automatically determined which packages are ready for stabilization
>   due to all their dependencies already being stable (and maybe with
>   automatic cooldown-from-testing detection )
>
> - Automatically determined which packages can be keyworded without
>   additional work due to all their dependencies being keyworded


I know I'm gonna be shot down in flames, because $heresy, but here is where
a package 'database' would actually work quite well, because you can
trivially create a query that pulls this data out, and sorts it by package
category or maintainer or whatever you like ..

Ok, let the flamewars begin ...



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH 0/3] elisp{,-common}.eclass update for emacs-vcs consolidation

2019-12-21 Thread Michael 'veremitz' Everitt
On 21/12/19 11:52, Ulrich Mueller wrote:
>> On Sat, 21 Dec 2019, Michael Orlitzky wrote:
>> And for the record, commenting on standards in response to a series of
>> commits that display low standards is not a personal attack.
> *shrug* As a matter of fact, I've run that series of commits past the
> QA lead, who has approved them.
>
FWIW, the QA lead doesn't always reflect the opinion of the whole QA team ..



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Packages up for grabs due to slis' retirement

2019-12-18 Thread Michael 'veremitz' Everitt
On 18/12/19 22:33, Michał Górny wrote:
> Hi,
>
> Due to slis retiring, the following packages are now in need of a new
> maintainer:
>
> [ v] app-arch/wimlib
> [ v] dev-embedded/lpc21isp
> [b?] dev-libs/libflatarray
> [  ] dev-libs/libpfm
> [bv] dev-libs/papi
> [ v] dev-python/aldryn-
> boilerplates
> [ v] dev-python/aldryn-common
> [ v] dev-python/click-plugins
> [
> v] dev-python/cligj
> [ v] dev-python/django-durationfield
> [ v] dev-
> python/django_polymorphic
> [ v] dev-python/django-sortedm2m
> [bv] dev-
> python/django-spurl
> [ v] dev-python/easy-thumbnails
> [ v] dev-
> python/ipdbplugin
> [bv] dev-python/Kivy
> [  ] dev-python/kivy-garden
> [  ]
> dev-python/munch
> [ v] dev-python/scoop
> [  ] dev-python/URLObject
> [ v] dev-
> python/YURL
> [b ] media-gfx/librecad
> [b ] media-gfx/pycam
> [b ] media-
> libs/assimp
> [S ] net-analyzer/ntopng
> [  ] net-libs/nDPI
> [ v] sci-libs/deap
> [
> v] sci-libs/Fiona
> [b?] sci-libs/libgeodecomp
> [ v] sci-libs/pyshp
> [ v] sci-
> libs/Rtree
> [  ] sci-libs/Shapely
> [bv] sci-misc/repsnapper
> [bv] sci-
> visualization/visit
> [bv] sys-cluster/hpx
>
> Legend:
> b - package has (regular) bugs
> S - package has vulnerabilities reported
> v - package needs version bump
>
There is some very strange wrapping/formatting in this message, was that
intentional?



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-portage-dev] Build path abi missing in qemu-user

2019-12-18 Thread Michael 'veremitz' Everitt
On 18/12/19 17:36, Joakim Tjernlund wrote:
> On Wed, 2019-12-18 at 11:22 -0500, Mike Gilbert wrote:
>> CAUTION: This email originated from outside of the organization. Do not 
>> click links or open attachments unless you recognize the sender and know the 
>> content is safe.
>>
>>
>> On Thu, Dec 12, 2019 at 10:18 AM Joakim Tjernlund
>>  wrote:
>>> When build in a qemu-user chroot I get odd build paths:
>>>   /var/tmp/portage/dev-libs/libxml2-2.9.9-r1/work/libxml2-2.9.9-.ppc
>>>
>>> This path is missing the abi_ppc_32 like so:
>>>   
>>> /var/tmp/portage/dev-libs/libxml2-2.9.9-r1/work/libxml2-2.9.9-abi_ppc_32.ppc
>>>
>>> I struggle to find out why this happens, any ideas?
>> I would guess you are using a profile that doesn't define the ABI_PPC
>> USE_EXPAND variable properly.
>>
> # portageq envvar USE_EXPAND
> ABI_MIPS ABI_PPC ABI_S390 ABI_X86 ALSA_CARDS APACHE2_MODULES APACHE2_MPMS 
> CALLIGRA_FEATURES CAMERAS COLLECTD_PLUGINS CPU_FLAGS_X86 CROSSCOMPILE_OPTS 
> CURL_SSL DRACUT_MODULES
> DVB_CARDS ELIBC ENLIGHTENMENT_MODULES FCDSL_CARDS FFTOOLS FOO2ZJS_DEVICES 
> FRITZCAPI_CARDS GPSD_PROTOCOLS GRUB_PLATFORMS INPUT_DEVICES KERNEL 
> LCD_DEVICES LIBREOFFICE_EXTENSIONS
> LINGUAS LIRC_DEVICES MONKEYD_PLUGINS NETBEANS_MODULES NGINX_MODULES_HTTP 
> NGINX_MODULES_MAIL OFED_DRIVERS OFFICE_IMPLEMENTATION OPENMPI_FABRICS 
> OPENMPI_OFED_FEATURES OPENMPI_RM
> PHP_TARGETS PYTHON_SINGLE_TARGET PYTHON_TARGETS QEMU_SOFTMMU_TARGETS 
> QEMU_USER_TARGETS ROS_MESSAGES RUBY_TARGETS SANE_BACKENDS USERLAND 
> UWSGI_PLUGINS VIDEO_CARDS
> VOICEMAIL_STORAGE XFCE_PLUGINS XTABLES_ADDONS
> cu3-jocke fs # portageq envvar ABI_PPC
> 32
> cu3-jocke fs # eselect profile list
> Available profile symlink targets:
>   [1]   default/linux/powerpc/ppc32/13.0
>   [2]   default/linux/powerpc/ppc32/13.0/desktop
>   [3]   default/linux/powerpc/ppc32/13.0/desktop/gnome
>   [4]   default/linux/powerpc/ppc32/13.0/desktop/gnome/systemd
>   [5]   default/linux/powerpc/ppc32/13.0/desktop/kde
>   [6]   default/linux/powerpc/ppc32/13.0/desktop/kde/systemd
>   [7]   default/linux/powerpc/ppc32/13.0/developer
>   [8]   default/linux/powerpc/ppc64/13.0/32bit-userland
>   [9]   default/linux/powerpc/ppc64/13.0/32bit-userland/desktop
>   [10]  default/linux/powerpc/ppc64/13.0/32bit-userland/desktop/gnome
>   [11]  default/linux/powerpc/ppc64/13.0/32bit-userland/desktop/gnome/systemd
>   [12]  default/linux/powerpc/ppc64/13.0/32bit-userland/desktop/kde
>   [13]  default/linux/powerpc/ppc64/13.0/32bit-userland/desktop/kde/systemd
>   [14]  default/linux/powerpc/ppc64/13.0/32bit-userland/developer
>   [15]  hardened/linux/powerpc/ppc32
>   [16]  hardened/linux/powerpc/ppc64/32bit-userland
>   [17]  hardened/linux/musl/ppc
>   [18]  default/linux/uclibc/ppc
>   [19]  hardened/linux/uclibc/ppc
>   [20]  tmv3-target-overlay:cusfpv3 *
>
> cusfpv3 inherits default/linux/powerpc/ppc32/13.0
>
>  Jocke
>
Haven't 13.0 profiles been deprecated? (and/or deleted by now ...)



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Output of ANSI escape sequences in ebuilds

2019-12-14 Thread Michael 'veremitz' Everitt
On 14/12/19 12:03, Kent Fredric wrote:
> On Sat, 14 Dec 2019 08:16:03 +0100
> Ulrich Mueller  wrote:
>
>> These prevent NOCOLOR in make.conf or emerge --color=n from working
>> correctly, and I guess they are also problematic from an accessibility
>> point of view.
>>
>> Are there any objections against removing these sequences from strings?
>> AFAICS, they are used by less than ten packages, and one eclass.
> Maybe we can have some future EAPI feature, or special eclass, that
> allows people to add escape codes while also respecting the
> configuration.
>
> Sort of like what git has in its formatting codes, where they're turned
> off when colours are turned off.
>
>   hl 1 "${@}"  # because 'hl' inherently behaves like echo when not captures 
>   einfo "Fetching $(hl "${r}" ) ..."
>
> Or something along those lines?
>
> I'd wager that a large body of things "not using it" is not because
> it wouldn't be useful, but due to people knowing this problem exists?
>
> -- Further Bikeshed --
>
> Maybe it could even be thematic?
>
>"Fetching $(hl url https://path.to/whatever )"
>
> Nah.
>
> But < hl   > as a general concept works.
>
Something that could be included in gentoo-functions script(s)?



signature.asc
Description: OpenPGP digital signature


[gentoo-portage-dev] RFC: [QA] notice with 'failed' seds [was PATCH: eapply drop -s option]

2019-12-13 Thread Michael 'veremitz' Everitt
On 13/12/19 20:36, Michał Górny wrote [excerpted]:
>
> Is this really an argument for or *against* it?  Developers are entirely
> capable of keeping seds that do nothing for years, as well as patches
> that -- while apparently applying correctly -- are entirely meaningless.


I think there is some merit in some kind of feedback when sed's are doing
nothing, although how feasible it is to generate any useful feedback I
can't say. I wouldn't say it needs to explicitly fail or make lots of
noise, just an info message that could prompt some further investigation.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-portage-dev] [PATCH] eapply: Drop -s option for patch.

2019-12-13 Thread Michael 'veremitz' Everitt
On 13/12/19 21:59, Michał Górny wrote:
> On Fri, 2019-12-13 at 21:56 +0000, Michael 'veremitz' Everitt wrote:
>> On 13/12/19 21:42, Michał Górny wrote:
>>> On Fri, 2019-12-13 at 16:37 -0500, Mike Gilbert wrote:
>>>> On Fri, Dec 13, 2019 at 3:36 PM Michał Górny  wrote:
>>>>> Just like 'many of the proposals lately', developers are going to be
>>>>> the ones disabling it (because they don't care), and users will be the
>>>>> ones enabling it (because they do care), just to learn that developers
>>>>> don't care and go complaining to the mailing lists that users dare
>>>>> report issues they don't care about.
>>>> I care if the patch is actually broken, which the warning doesn't
>>>> really tell me. It's just not a very reliable indicator, and will
>>>> produce false-positives frequently.
>>>>
>>> You can also take less context into the patch and use -F0.  Then you'll
>>> have the same effect, no warnings to bother you and no pretending that
>>> the patch applies when it doesn't.
>>>
>> Is there any mileage in having a similar scheme to which we already apply
>> '-p' increments to the -F variable?
>> eg.
>> 1) attempt patch with -F0
>> 2) if (1) fails, attempt with -F2/3 & display 'yellow' warning & QA notice
> That is precisely what my patch does and what people are complaining
> about.
Ah, apologies for the failure to grok.

Tangentially, but also brought up on the thread, I'm actually even
moderately concerned about the ghost seds that may never apply. Topic for
another thread though I feel.
>> 3) if (2) fails, attempt with, say, -F10 & display big fat 'red' warning
>> and QA notice
> That makes no sense as it exceeds context provided in most patches.
>
Fair .. hadn't thought of that - depends very much if you're using unified
diffs, which I believe we largely are.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-portage-dev] [PATCH] eapply: Drop -s option for patch.

2019-12-13 Thread Michael 'veremitz' Everitt
On 13/12/19 21:42, Michał Górny wrote:
> On Fri, 2019-12-13 at 16:37 -0500, Mike Gilbert wrote:
>> On Fri, Dec 13, 2019 at 3:36 PM Michał Górny  wrote:
>>> Just like 'many of the proposals lately', developers are going to be
>>> the ones disabling it (because they don't care), and users will be the
>>> ones enabling it (because they do care), just to learn that developers
>>> don't care and go complaining to the mailing lists that users dare
>>> report issues they don't care about.
>> I care if the patch is actually broken, which the warning doesn't
>> really tell me. It's just not a very reliable indicator, and will
>> produce false-positives frequently.
>>
> You can also take less context into the patch and use -F0.  Then you'll
> have the same effect, no warnings to bother you and no pretending that
> the patch applies when it doesn't.
>
Is there any mileage in having a similar scheme to which we already apply
'-p' increments to the -F variable?
eg.
1) attempt patch with -F0
2) if (1) fails, attempt with -F2/3 & display 'yellow' warning & QA notice
3) if (2) fails, attempt with, say, -F10 & display big fat 'red' warning
and QA notice
4) Fail and abort

Regards,
veremitz/Michael.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] unsanctioned python 2.7 crusade

2019-12-06 Thread Michael 'veremitz' Everitt
On 06/12/19 20:10, Andreas Sturmlechner wrote:
> On Friday, 6 December 2019 20:47:31 CET Thomas Deutschmann wrote:
>> On 2019-12-06 17:44, Mike Gilbert wrote:
>>> 1. Keep the old version installed.
>>> 2. Emit a confusing error message to the user since the use-dependency
>>> on dev-python/example[python_targets_python2_7] cannot be resolved
>>> with the latest visible version.
>> I don't fully understand #2 to be honest but yes, you will be cut off
>> from latest version at some point. Same in PHP.
> Considering that above statement, I would expect a bit more humility than the 
> following:
>
>> Maybe someday one of those responsible will admit that this step was not
>> a thoughtful and good decision and promise not to do it that way again
>> and I'll get over it. Who knows. :)
> Just so we're on the same page, a recent example of what some people 
> suggesting to keep py27 ad nauseam are asking users to deal with:
>
>
>
> # emerge -uDpv @world
>
> These are the packages that would be merged, in order:
>
> Calculating dependencies... done!
>
> Total: 0 packages, Size of downloads: 0 KiB
>
> WARNING: One or more updates/rebuilds have been skipped due to a dependency 
> conflict:
>
> dev-python/sphinx:0
>
>   (dev-python/sphinx-2.0.1:0/0::gentoo, ebuild scheduled for merge) conflicts 
> with
> >=dev-python/
> sphinx-1.5.3[python_targets_python2_7(-),python_targets_python3_6(-),-
> python_single_target_pypy(-),-python_single_target_pypy3(-),-
> python_single_target_python2_7(-),-python_single_target_python3_5(-),-
> python_single_target_python3_6(-),-python_single_target_python3_7(-)] 
> required 
> by (dev-python/sphinxcontrib-websupport-1.1.0:0/0::gentoo, installed)
>   
>   
>   
>  
> dev-python/
> sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
> python_single_target_python2_7(-),-python_single_target_python3_5(-),-
> python_single_target_python3_6(-),-python_single_target_python3_7(-)] 
> required 
> by (dev-python/cython-0.29.4:0/0::gentoo, installed)
>   
>   
>  
> dev-python/
> sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
> python_single_target_python2_7(-),-python_single_target_python3_5(-),-
> python_single_target_python3_6(-),-python_single_target_python3_7(-)] 
> required 
> by (dev-python/flask-babelex-0.9.3:0/0::gentoo, installed)
>   
>   
>  
> dev-python/
> sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
> python_single_target_pypy(-),-python_single_target_pypy3(-),-
> python_single_target_python2_7(-),-python_single_target_python3_5(-),-
> python_single_target_python3_6(-),-python_single_target_python3_7(-)] 
> required 
> by (dev-python/testtools-2.3.0:0/0::gentoo, installed)
>   
>   
>   
>  
> dev-python/
> sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
> python_single_target_pypy(-),-python_single_target_pypy3(-),-
> python_single_target_python2_7(-),-python_single_target_python3_5(-),-
> python_single_target_python3_6(-),-python_single_target_python3_7(-)] 
> required 
> by (dev-python/pytest-runner-4.2:0/0::gentoo, installed)
>   
>   
>   
>  
> dev-python/
> sphinx[python_targets_python2_7(-),python_targets_python3_6(-),-
> python_single_target_pypy(-),-python_single_target_pypy3(-),-
> python_single_target_python2_7(-),-python_single_target_python3_5(-),-
> python_single_target_python3_6(-),-python_single_target_python3_7(-)] 
> required 
> by (dev-python/flask-babel-0.11.2-r2:0/0::gentoo, installed)
>   
>   
>   
> 

Re: [gentoo-dev] [PATCH] package.deprecated: Create initial template

2019-12-06 Thread Michael 'veremitz' Everitt
On 06/12/19 16:28, Mike Gilbert wrote:
> On Fri, Dec 6, 2019 at 10:46 AM Michael 'veremitz' Everitt
>  wrote:
>> I hope you're not suggesting a rebase of any sort in gentoo.git, Matt  ;)
> He's talking about rebasing local commits that haven't yet been
> pushed. That's perfectly normal.
>
Fair .. it was a very tongue-in-cheek remark .. fwiw.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] package.deprecated: Create initial template

2019-12-06 Thread Michael 'veremitz' Everitt
On 06/12/19 15:41, Matt Turner wrote:
> On Fri, Dec 6, 2019 at 5:51 AM Alexis Ballier  wrote:
>> On Fri, 6 Dec 2019 04:33:36 -0500
>> Tim Harder  wrote:
>>
>>> On 2019-12-06 Fri 04:03, Alexis Ballier wrote:
 it's not just like repoman and cvs since repoman commit did push ;)
 it will never be perfect but i really like repoman commit to refuse
 to even commit if there's something obviously wrong
>>> I'm more of the opinion (and am working towards that practicality in
>>> terms of runtime speed) that a subset of QA checks should be run as a
>>> git hook which would cause push failures on certain classes of bad
>>> commits.
>>
>> There should be both. Amending the 23rd commit message because one
>> mistyped a semicolon is kind of a PITA.
> It is?
>
> git rebase -i HEAD~23
>
> Is that what you think is a pain in the ass, or do you not know about
> interactive rebase? :)
>
I hope you're not suggesting a rebase of any sort in gentoo.git, Matt  ;)



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Last rites: dev-python/* leaf packages

2019-12-04 Thread Michael 'veremitz' Everitt
On 05/12/19 00:15, Aaron Bauman wrote:
> Fellow devs,

> dev-python/sqlitecachec
> dev-python/supervisor-quick
> dev-python/python-cdb
> dev-python/fabric
^ https://github.com/mathiasertl/fabric/ is a fork of fabric for py3.4+
FYI. Also on PyPi at https://pypi.org/project/Fabric3/.
> dev-python/foolscap
> net-fs/tahoe-lafs
> dev-python/pyvtk


HTH,
veremitz/Michael.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] RFC acct-{user,group} for net-dns/avahi, net-vpn/tor, net-misc/stunnel

2019-12-01 Thread Michael 'veremitz' Everitt
On 02/12/19 06:23, Joonas Niilola wrote:
>
>
> On 11/27/19 8:21 PM, Anthony G. Basile wrote:
>>
>> 3) For net-misc/stunnel
>>
>> stunnel uid = 478
>> stunnel gid = 478
>>
>>
> I just noticed Tomáš Mózes (hydrapolic) had requested 478 UID+GID for
> graylog in 21 Nov. I've just merged it.
>
> Come on people, ctrl+fing your ID in your mail client for the gentoo-dev
> ML shows pretty fast if it's been requested or not. Ideally we'd update
> uid-gid.txt for every request, but not everyone has commit access /
> interest for that...
>
>
> -- juippis
>
surely if you have commit access to gentoo.git you can update uid-gid.txt ?
how hard can it be?! 


signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC] Perspectives on improving (dis-hacking) python-single-r1

2019-11-24 Thread Michael 'veremitz' Everitt
On 24/11/19 16:06, Francesco Riosa wrote:
> Since we are here ...
> I'd still like to see some way to adopt latest python version if user
> wants to.
> One way it could work is that we add a "LATEST" to PYTHON_TARGETS that
> would always build against best version of python.
> To avoid complications if a new version of python is emerged together
> with other packages it must always include also a numeric version like 3_8
>
> Regarding your proposal getting rid of PYTHON_SINGLE_TARGET would be nice
> but being able to have multiple version of python installed is nicer and
> differentiate gentoo from most other distro
>
> Alternative 2 is also nice, the only thing that make me dubious is that
> it looks like it will be a gigantic work, but you have a better sense of
> the situation and will be one of those doing the actual work, so go for it!
Most distros have (or haD) .. python2 and python3 (not necessarily each
with their suffix) in their repo's .. but being able to have multiple
branches of either is certainly a feature IMHO.

I'm certainly for re-working the PYTHON_[SINGLE_]TARGETS dependencies, as
they can often get 'screwed up' when upgrading between versions, and
updating packages in between, and all quickly gets out of sync, and
requires a lot of hacking to fix up properly.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Addressing split usage of USE=gles[123]

2019-11-21 Thread Michael 'veremitz' Everitt
On 21/11/19 21:53, Dennis Schridde wrote:
> On Donnerstag, 21. November 2019 09:11:46 CET Mart Raudsepp wrote:
>> See also this related old thread:
>> https://archives.gentoo.org/gentoo-dev/message/e04f6d321e424a237af62721d1d09
>> 211
> I think tackling the triad of opengl/gles, egl/glx, X/wayland is also a good
> idea.  Generally, all these probably have to distinguish between "support for
> XYZ" and "use only XYZ", the latter hopefully being the exception, so that the
> former can take the shorter use-flag.  That's what I don't like about the
> proposal from 2018: Globally enabling USE=gles will have different effects on
> different packages.  That's also what I like about the recent proposal: The
> flags are more explicit.
>
> --Dennis
I don't think the problem is so much in the principle of making a change,
or even the specifics of any particular permutation of change, it's who
gets to manage and implement the change in a maintainable fashion, and who
has to deal with the fallout of any changes occurring where a particular
scenario 'slips through the net'

If you can convince the latter people that there is no problem arising from
making said changes, and you ensure that there genuinely *is* minimal
impact (by whatever means) then you stand a much better chance of this
change actually being implemented ..



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Last rites: app-misc/toilet

2019-11-16 Thread Michael 'veremitz' Everitt
On 17/11/19 02:07, Aaron Bauman wrote:
> On Sat, Nov 16, 2019 at 08:29:58PM -0500, Aaron Bauman wrote:
>> # Aaron Bauman  (2019-11-16)
>> # EAPI=4. --filter=gay Really?!
>> # Removal in 15 days
>> app-misc/toilet
>>
>> -- 
>> Cheers,
>> Aaron
> Add the following as it is an rdep
>
> net-irc/rbot
>
OOps, there goes willikins ...



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Package up for grabs: sys-firmware/iwl1000-ucode

2019-11-16 Thread Michael 'veremitz' Everitt
On 16/11/19 16:59, Matt Turner wrote:
> On Sat, Nov 16, 2019 at 1:06 AM Jaco Kroon  wrote:
>> Hi,
>>
>> On 2019/11/15 21:35, Matt Turner wrote:
>>> On Fri, Nov 15, 2019 at 2:20 AM Ulrich Mueller  wrote:
 The package is somewhat redundant, because sys-kernel/linux-firmware
 installs the same files. (Same for all other sys-firmware/iwl*-ucode
 packages.)
>>> Should last-rite all of them, IMO.
>>>
>> I both agree and disagree with this.  It's the simpler solution and
>> therefore I agree.
>>
>> I disagree because in some cases I really only want specific firmware
>> for specific sets of hardware (especially where space constraints are an
>> issue, read: embedded type systems).
>>
>> The current linux-firmware package is getting quite big in terms of install.
> USE=savedconfig allows you to choose exactly which files to install :)
>
I've never found a good way (yet...) to figure out how to write a fresh new
'savedconfig' if you haven't ever previously emerged the package in
question. Does anyone have a good method for this, that doesn't require
unpacking the whole nine yards (Megs, Gigs...) first?



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-portage-dev] Re: seed emerge with old /var/db/pkg ?

2019-11-13 Thread Michael 'veremitz' Everitt
On 13/11/19 19:07, Zac Medico wrote:
> On 11/8/19 9:09 AM, Joakim Tjernlund wrote:
>> On Fri, 2019-11-08 at 01:57 +0100, Joakim Tjernlund wrote:
>>> I am looking for a way to seed emerge with an older pkg db so emerge can 
>>> calculate
>>> which packages needs to be rebuild/upgraded in order to get to the same 
>>> state as the system pkg db,
>>> Is that possible?
>>>
>>> Also, is there some tool that allows med to copy just files needed for a 
>>> profile?
>>> Something like "cp" /etc/portage/make.profile /my/destination
>>>
>> portage-utils has variables Q_VDB and Q_EDB which allows qmerge to use 
>> different VDBs/EDBs
>> Does portage have something similar?
> No, nothing like either of those things.
>
> However, if you want to operate on an old system then the usual
> recommendation is to unpack a stage3 and bind mount the old system root
> into the stage3 so that you can chroot into the stage3 and run something
> like this:
>
> emerge --root /mnt/old-system portage
In the interests of clarity, what does this achieve, and what would the
next couple of steps look like?
(actual commands not necessary, pseudo-code WFM)



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Do (old-ish) Portage QA checks comprise policy?

2019-11-04 Thread Michael 'veremitz' Everitt
On 04/11/19 23:17, Michael Orlitzky wrote:
> On 11/4/19 2:40 PM, William Hubbs wrote:
>>
>> This is a whole other thread I've been talking about for years, but if
>> we want to be concerned about dumping "garbage" on people's limited root
>> file systems, there are other things we need to re-consider, like our
>> notion that we have to install small files everywhere even though they
>> aren't always used.
>>
>> So, if you want to talk about that, please start a whole new thread.
>>
>
> 1. The idea that we should fix all existing problems before we can
>    prevent people from creating new ones is ridiculous.
>
> 2. Those other files don't get installed to the root filesystem on the
>    systems that we're talking about.
>
> 3. Those other files generally aren't completely useless.
>
> 4. "small files" aren't big.
>
>
Straw man anyone? I know Guy Fawkes night is coming up here in the UK ... ;)



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] acct-{group,user}/minetest request for ID 481

2019-11-04 Thread Michael 'veremitz' Everitt
On 04/11/19 07:57, Tomas Mozes wrote:
>
> On Mon, Nov 4, 2019 at 4:50 AM Joonas Niilola  > wrote:
>
>
> On 11/4/19 1:37 AM, William Breathitt Gray wrote:
> > Hello,
> >
> > `games-action/minetest` creates a "minetest" user and group with random
> > respective IDs, used for running the Minetest server daemon. The latest
> > version bump PR (https://github.com/gentoo/gentoo/pull/13272) follows
> > GLEP 81 by creating acct-{group,user}/minetest with 481 assigned as
> > their respective IDs.
> >
> > Is this assignment all right?
> >
> > Thank you,
> >
> > William Breathitt Gray
> >
>
> Hey,
>
>
> 481 was already requested for mongodb.
>
> 
> https://archives.gentoo.org/gentoo-dev/message/b981a29d9ade23d10663f0c0ae850044
>
>
> -- juippis
>
>
> Sorry, I haven't seen this UID/GID in the ML so I used it, haven't
> checked the PRs on github. Next time, please send a mail to the ML along
> with the PR creation.
>
> Thanks,
> Tomas 
You can also look up what's currently in use at
https://api.gentoo.org/uid-gid.txt FYI :]


signature.asc
Description: OpenPGP digital signature


Re: [gentoo-portage-dev] [PATCH] install-qa-check.d: remove check that bans libtool files and static libs from /

2019-11-03 Thread Michael 'veremitz' Everitt
On 03/11/19 21:37, Michał Górny wrote:
> On Sun, 2019-11-03 at 15:26 -0600, William Hubbs wrote:
>>
>> You being a qa member doesn't have a lot to do with this mgorny. you
>> know there was no official policy when I posted this, and as far as I
>> know there is not one now.
>>
> That is a really poor argument.  Something that's respected for 10+
> years and reported as QA violation is a standing policy as far as I'm
> concerned.  Just because it isn't backed by a formally stamped policy
> (at least as far as we know -- maybe it was actually stamped somewhere
> in the past?) doesn't mean you it's fine for one person to change it ad-
> hoc because it stands in his way.
>
> I should point that I'm very concerned that you're pushing this forward
> even though:
>
> 1) I've objected to the change itself,
>
> 2) I've pointed out that it's been sent to the wrong mailing list,
> and that this explicitly prevents a number of developers from even
> knowing that this is happening,
>
> 3) removing it provides a way for regressions that can have major impact
> on users and that involve much effort in reverting that.
>
> So if I send a revert patch afterwards, and you object, should the patch
> be accepted because only one person objected?
>
Children, please take this off-list ...



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] RFC: Require full $P not just $PN on stable/keyword commit messages

2019-11-02 Thread Michael 'veremitz' Everitt
On 02/11/19 08:54, Kent Fredric wrote:
> On Fri, 1 Nov 2019 19:59:35 +
> Michael 'veremitz' Everitt  wrote:
>
>> Thoughts from outside peanut gallery?
>>
>> Michael / veremitz.
> I have an alternative that might be more pleasant:
>
> 1. Change repoman so that when its clear that:
>- There is at least one ebuild being changed
>- There is only one ebuild being changed
>   Then the templated summary line is full ${P}
>
> 2. Otherwise, retain the current semantics of using a simpler
>${P} in other cases.
>
> 3. Make no *requirements* that ${P} be used instead of ${PN},
>and that way people who think they have a good reason to use ${PN}
>instead of ${P} can do just that (if for instance, they need to lop
>off context so they can have a longer commit message )
>
> This IMO improves things by default, given that the majority of changes
> get run through repoman, and a majority of changes have very terse
> requirements for extra data.
>
> It also means that by default, when people just make the commit message
> something silly like "bump", or "version bump", despite the fact they
> didn't put in much effort, the log defaults to being useful, and the
> commit messages relayed to #gentoo-commits improves in usefulness.
>
> Partly, because for me, one of my prime vectors where I become aware
> changes are occuring is in #gentoo commits, particularly because
> something in there highlights me.
>
> I don't want to *have* to:
> - Resync my git repo 
> - Dig into git wizardry 
>
> *just* to ascertain what version was involved, and to then ascertain if
> I need to investigate further.
>
> ( Because once I've already synced and started using git wizardry, I'm
> already starting to pay investigation taxes )
>
>
This sounds like a good compromise, and one I'm content to work on. Anyone
else able/willing to pitch in?



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] RFC: Require full $P not just $PN on stable/keyword commit messages

2019-11-01 Thread Michael 'veremitz' Everitt
On 01/11/19 21:45, Mike Gilbert wrote:
> On Fri, Nov 1, 2019 at 5:34 PM Michael 'veremitz' Everitt
>  wrote:
>> On 01/11/19 21:11, Rich Freeman wrote:
>>> On Fri, Nov 1, 2019 at 4:36 PM Matt Turner  wrote:
>>>> On Fri, Nov 1, 2019 at 12:59 PM Michael 'veremitz' Everitt
>>>>  wrote:
>>>>> Therefore, it would be much /more/ useful to have the package-version
>>>>> tagged in the commit message, so that you could easily grep logs for when 
>>>>> a
>>>>> given version of a package was stabilised, and/or keyworded.
>>> git log --format=oneline glibc-2.29-r2.ebuild | grep stable
>>> 9c04d06d06d51d9c76b3fe5ceb573213769f45ae sys-libs/glibc-2.29-r2: sparc
>>> stable, bug 685818
>>> b61ab167e82261ed2078c068ba0c2fc3a7b58aa3 sys-libs/glibc: stable
>>> 2.29-r2 for hppa, bug #685818
>>> fad52f75c759ca326ce0f8c37e227827f01cd2f1 sys-libs/glibc: m68k stable
>>> wrt bug #685818
>>> 0fe91535a7ba382f10084def5482e61359f201cb sys-libs/glibc: sh stable wrt
>>> bug #685818
>>> 7b7ec9a6b3355d6111e1a449ca13e24cb6ef0295 sys-libs/glibc: s390 stable
>>> wrt bug #685818
>>> bcddad6780ead2b44528a4aa1d51107b4a225524 sys-libs/glibc-2.29-r2: alpha 
>>> stable
>>> 2ca6a4b9d647f567d2300e7b90829993d7575b41 sys-libs/glibc: ia64 stable
>>> wrt bug #685818
>>> e56c3c1f1c0a256c228a59be94869751d7fd31d7 sys-libs/glibc: ppc64 stable
>>> wrt bug #685818
>>> 52355459ec00b9ca9921bd5f788bad9b95346910 sys-libs/glibc: ppc stable
>>> wrt bug #685818
>>> 745b07e84b5035576737d3e1a719121d02e53feb sys-libs/glibc: arm stable
>>> wrt bug #685818
>>> 332fc91e3e72a6dd1b183ce4a19d08b45daa8e00 sys-libs/glibc: x86 stable
>>> (bug #685818)
>>> 9e06c1242e104b66a532e7d5d919c1b3b1f8343d sys-libs/glibc: arm64 stable
>>> (bug #685818)
>>> b3ad265998a04a40820d078d25c06b7cb51173ef sys-libs/glibc: amd64 stable
>>> wrt bug #685818
>>>
>>> Seems to work fine for me.
>>>
>>>
>> How well does git handle that when the ebuild is deleted from the tree?
> It handles it just fine, though you need to add "--" to disambiguate
> it from a ref. For example:
>
> git log --format=oneline --grep=stable -- foo-123.ebuild
>
Consider me somewhat enlightened .. (!) :]



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] RFC: Require full $P not just $PN on stable/keyword commit messages

2019-11-01 Thread Michael 'veremitz' Everitt
On 01/11/19 21:11, Rich Freeman wrote:
> On Fri, Nov 1, 2019 at 4:36 PM Matt Turner  wrote:
>> On Fri, Nov 1, 2019 at 12:59 PM Michael 'veremitz' Everitt
>>  wrote:
>>>
>>> Therefore, it would be much /more/ useful to have the package-version
>>> tagged in the commit message, so that you could easily grep logs for when a
>>> given version of a package was stabilised, and/or keyworded.
> git log --format=oneline glibc-2.29-r2.ebuild | grep stable
> 9c04d06d06d51d9c76b3fe5ceb573213769f45ae sys-libs/glibc-2.29-r2: sparc
> stable, bug 685818
> b61ab167e82261ed2078c068ba0c2fc3a7b58aa3 sys-libs/glibc: stable
> 2.29-r2 for hppa, bug #685818
> fad52f75c759ca326ce0f8c37e227827f01cd2f1 sys-libs/glibc: m68k stable
> wrt bug #685818
> 0fe91535a7ba382f10084def5482e61359f201cb sys-libs/glibc: sh stable wrt
> bug #685818
> 7b7ec9a6b3355d6111e1a449ca13e24cb6ef0295 sys-libs/glibc: s390 stable
> wrt bug #685818
> bcddad6780ead2b44528a4aa1d51107b4a225524 sys-libs/glibc-2.29-r2: alpha stable
> 2ca6a4b9d647f567d2300e7b90829993d7575b41 sys-libs/glibc: ia64 stable
> wrt bug #685818
> e56c3c1f1c0a256c228a59be94869751d7fd31d7 sys-libs/glibc: ppc64 stable
> wrt bug #685818
> 52355459ec00b9ca9921bd5f788bad9b95346910 sys-libs/glibc: ppc stable
> wrt bug #685818
> 745b07e84b5035576737d3e1a719121d02e53feb sys-libs/glibc: arm stable
> wrt bug #685818
> 332fc91e3e72a6dd1b183ce4a19d08b45daa8e00 sys-libs/glibc: x86 stable
> (bug #685818)
> 9e06c1242e104b66a532e7d5d919c1b3b1f8343d sys-libs/glibc: arm64 stable
> (bug #685818)
> b3ad265998a04a40820d078d25c06b7cb51173ef sys-libs/glibc: amd64 stable
> wrt bug #685818
>
> Seems to work fine for me.
>
>
How well does git handle that when the ebuild is deleted from the tree?




signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Re: RFC: Require full $P not just $PN on stable/keyword commit messages

2019-11-01 Thread Michael 'veremitz' Everitt
On 01/11/19 19:59, Michael 'veremitz' Everitt wrote:
> Hello,
>
> I've noticed a lot of stabilisation commit messages (and a few keywording
> ones too) simply state the package atom and not the relevant
> release/version. I find this a little meaningless, as unless this is the
> first time the package has ever been either stabilised or keyworded, it is
> reasonable to expect that there is/was some transition point for a package
> from when it first entered the Gentoo Repository.
>
> Therefore, it would be much /more/ useful to have the package-version
> tagged in the commit message, so that you could easily grep logs for when a
> given version of a package was stabilised, and/or keyworded. Granted, this
> is more of-use in a historical context compared to a present (future?!)
> one, but I would argue that it conveys more meaning -with- the version than
> without.
>
> Thoughts from outside peanut gallery?
>
> Michael / veremitz.
>
Also, it's particularly helpful if you have an atom feed of a given
package, to see when versions are stabilised (present and future contexts
covered... ;D)



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] RFC: Require full $P not just $PN on stable/keyword commit messages

2019-11-01 Thread Michael 'veremitz' Everitt
Hello,

I've noticed a lot of stabilisation commit messages (and a few keywording
ones too) simply state the package atom and not the relevant
release/version. I find this a little meaningless, as unless this is the
first time the package has ever been either stabilised or keyworded, it is
reasonable to expect that there is/was some transition point for a package
from when it first entered the Gentoo Repository.

Therefore, it would be much /more/ useful to have the package-version
tagged in the commit message, so that you could easily grep logs for when a
given version of a package was stabilised, and/or keyworded. Granted, this
is more of-use in a historical context compared to a present (future?!)
one, but I would argue that it conveys more meaning -with- the version than
without.

Thoughts from outside peanut gallery?

Michael / veremitz.



signature.asc
Description: OpenPGP digital signature