Re: [gentoo-dev] Ebuild Generators
Am Dienstag, 11. Februar 2020, 16:18:44 CET schrieb Tom Gillespie: > For historical curiosity there was also > https://github.com/domenkozar/g-pypi at one point (similar to > https://github.com/rafaelmartins/g-octave). Having used g-octave, the > primary issue is as Michał says, there are a lot of corner cases that > the generation doesn't handle correctly which lead to broken ebuilds > and maintenance headaches. Speaking for python, catching and > correcting the use of setup_requires and other insanity visited upon > us by the wonders of setuptools makes this a non-starter That's essentially my whole point. Generators are _not_ able to catch all corner cases but should be able to lower the initial ebuild creation cost. That could be such things like figure out the license, try to fill the source url, In principal: Try to automate what is possible and leave the rest to the maintainer. But in that state they are a tool for the Gentoo developer not for the user. Gerion signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH 3/3] app-admin/kube-bench: convert to go-module go.sum
On Monday, 10 February 2020 7:55:01 AM AEDT 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? Perhaps I'm the one being ignorant here, but why are we lambasting someone for seeking clarification about an unusual inclusion on a review thread? -- Sam Jorna (wraeth) GnuPG ID: 0xD6180C26
Re: [gentoo-dev] Should we allow "GPL, v2 or later" for ebuilds?
[2020-02-11 10:52:57-0500] Rich Freeman:
> On Tue, Feb 11, 2020 at 10:05 AM Haelwenn (lanodan) Monnier
> wrote:
> >
> > Maybe it could for now be a simple agreement on putting your code to
> > the Gentoo Foundation under the GPL-2+ but it would be published under
> > the GPL-{2,3,…}?
> >
>
> Well, if we were going to get people to start signing things I suggest
> just sticking to the FLA since it actually was written by lawyers.
Absolutely, I misunderstood that the FLA wasn't ready at all, it's
much better to have it instead.
> I attached a copy, but along these lines the key section is:
> We agree to (sub)license the Contribution or any Materials containing,
> based on or derived from your Contribution under the terms of any
> licenses the Free Software Foundation classifies as Free Software
> License and which are approved by the Open Source Initiative as Open
> Source licenses.
>
> That is, Gentoo would control the licenses, but they would have to be
> FSF/OSI approved. That doesn't mean that anybody could choose any
> FSF-approved license - Gentoo would still have to do the licensing.
> This is just a limitation on the grant of power from the original
> author to Gentoo on WHAT licenses GENTOO can choose.
>
> There is also a variant of the FLA that can further narrow down the
> licenses that Gentoo gets to choose from, but IMO if you're going to
> go down this path it makes sense to keep things flexible. We could of
> course just limit Gentoo to GPL v2+, and initially Gentoo does v2/3
> and later Gentoo could revise to any later version of the GPL. But if
> for whatever reason the GPL falls out of favor then we can't adapt
> futher.
>
> Ultimately though anything like this involves giving up control.
Which happens a lot when you have do to anything with others, and is
quite how using the internet and free software sounds like to me.
Anyway, this FLA document generator looks really good to me, much better
than a weird "or later" on a license.
FSF/OSI sounds a bit too much flexible but personally I think I can
trust gentoo enough to pick a similar license and otherwise it seems to
restricts flexibility a bit too much. At least the option of GPL-2+ but
with the change control put to gentoo would be possible.
[gentoo-dev] packages up for grabs
Note that some of the packages in this list might have other maintainers, but I'm sure they wouldn't mind co-maintainers. dev-util/pkgcheck sys-apps/pkgcore dev-python/snakeoil dev-python/pychroot app-arch/vimball
Re: [gentoo-dev] Ebuild Generators
Tom Gillespie writes: > For historical curiosity there was also > https://github.com/domenkozar/g-pypi at one point (similar to > https://github.com/rafaelmartins/g-octave). Having used g-octave, the > primary issue is as Michał says, there are a lot of corner cases that > the generation doesn't handle correctly which lead to broken ebuilds > and maintenance headaches. Speaking for python, catching and > correcting the use of setup_requires and other insanity visited upon > us by the wonders of setuptools makes this a non-starter. Yes, I agree. > If you have a set a known sane packages you could in theory write an > eclass that captures the regularities of those packages, but I'm not > sure eclasses are suggested for that use case. eclass is designed for eliminating duplicated code in ebuilds. Therefore yes, it is the legitimate use of eclass. Benda
[gentoo-dev] Last-rites: sci-calculators/gonvert
# Andreas Sturmlechner (2020-02-11) # Upstream "unable to port away from" dev-python/pygtk, bug #708156 # Masked for removal in 30 days. sci-calculators/gonvert
Re: [gentoo-dev] Should we allow "GPL, v2 or later" for ebuilds?
On Tue, Feb 11, 2020 at 10:05 AM Haelwenn (lanodan) Monnier
wrote:
>
> Maybe it could for now be a simple agreement on putting your code to
> the Gentoo Foundation under the GPL-2+ but it would be published under
> the GPL-{2,3,…}?
>
Well, if we were going to get people to start signing things I suggest
just sticking to the FLA since it actually was written by lawyers.
I attached a copy, but along these lines the key section is:
We agree to (sub)license the Contribution or any Materials containing,
based on or derived from your Contribution under the terms of any
licenses the Free Software Foundation classifies as Free Software
License and which are approved by the Open Source Initiative as Open
Source licenses.
That is, Gentoo would control the licenses, but they would have to be
FSF/OSI approved. That doesn't mean that anybody could choose any
FSF-approved license - Gentoo would still have to do the licensing.
This is just a limitation on the grant of power from the original
author to Gentoo on WHAT licenses GENTOO can choose.
There is also a variant of the FLA that can further narrow down the
licenses that Gentoo gets to choose from, but IMO if you're going to
go down this path it makes sense to keep things flexible. We could of
course just limit Gentoo to GPL v2+, and initially Gentoo does v2/3
and later Gentoo could revise to any later version of the GPL. But if
for whatever reason the GPL falls out of favor then we can't adapt
futher.
Ultimately though anything like this involves giving up control.
For those interested in the FLA there is a license generator at:
http://contributoragreements.org/ca-cla-chooser/
You pick the terms (I used the defaults - which IMO are most
appropriate but not the only valid option). It spits out an agreement
for you.
--
Rich
fiduciary-license-license-agreement-2.0-2020-02-11-15_47_12.pdf
Description: Adobe PDF document
[gentoo-dev] Review request for dev-lang/clojure
Hi all, I have submitted a pull request (https://github.com/gentoo/gentoo/pull/14224) that allows dev-lang/clojure-1.9.0 and 1.10.0 to build. Two related bugs are https://bugs.gentoo.org/670680 and https://bugs.gentoo.org/684536. I have also attached the changes as patches below. Given that there is no maintainer for dev-lang/clojure I wondered if someone on this could take a look. Many thanks! Tom From 4d25fead235199b59f42c23ce91b723112e2472d Mon Sep 17 00:00:00 2001 From: Tom Gillespie Date: Fri, 3 Jan 2020 15:47:57 -0500 Subject: [PATCH 5/5] dev-java/spec-alpha: add metadata.xml Signed-off-by: Tom Gillespie --- dev-java/spec-alpha/Manifest | 3 --- dev-java/spec-alpha/metadata.xml | 8 2 files changed, 8 insertions(+), 3 deletions(-) create mode 100644 dev-java/spec-alpha/metadata.xml diff --git a/dev-java/spec-alpha/Manifest b/dev-java/spec-alpha/Manifest index db86db8f403..52d59ab3ee0 100644 --- a/dev-java/spec-alpha/Manifest +++ b/dev-java/spec-alpha/Manifest @@ -1,5 +1,2 @@ -AUX build.xml 1401 BLAKE2B 500b8a1de2b452a1198d66a222e82a8bc78fdc2827d457a50b70d5ffa59866a1f37295a4b275b7ded9bab2a544ee5458b98fba308fb6833816c7567cfc33 SHA512 6d2297aaa240e05688a8062ea02bbb6e488567c00df83d8325c75862240ab109d8c0d9f3779c702161a98ac2f0f684ab87d81c3c0637d73ec382e4e9ca2cf36b DIST spec.alpha-0.1.143.tar.gz 35568 BLAKE2B f63fdd2b3c83dbd3936e36ff57b6ea399b7173fe805c60a6ecbd8e4aef5942f051a8551c259d89885a202c20045f67921b66c4dc9e361aacc8903c6542d7c7b5 SHA512 87887d72bc7343f96fad937b90feb4cc1be1eeaad8b7c01ae090ebe5cb17c30612e63797ea9eb39e6fe4c07870dcba9e153a98777d372923e95163f3219a976c DIST spec.alpha-0.2.176.tar.gz 37055 BLAKE2B 0588772e4a47a5b122984abefaf5ef2d0fffbacaf277b22737c94889e646c16a029017d405b72b829e88bcf03b12f689cb2053884b24b47193a26978ab54a318 SHA512 decf0dbff09bf8ee12503e6117ab635b98cd8dd2c389acf7aeebf00f32b5fd8250d66c2ec54cfe5da45e727e39480ae738a3ee7fcad71684d8c3acf464fe21e7 -EBUILD spec-alpha-0.1.143.ebuild 960 BLAKE2B a3534caaf1e4f28a8b892b086c4427f0e6da7dae63232ba7aff769df6737f4fd927b64fd065c92f891267dea0b6eefc46f8ec0c437a0ddd174fd077ecd9bb37f SHA512 b60a477da8e233b8af0b98c83aaa40b8de298e1a4c47385bbab1ea5db1dfb65d6638635deb8a90acd93c41cbf02e0d7954685d0b134114911e8fad3eebe69708 -EBUILD spec-alpha-0.2.176.ebuild 960 BLAKE2B ad2e6b2c8beaed8c22d59ef9665dc78421928447f54118fc97815b0d46cd84756267a2b5c58c04ab707715e380f4d1d66c70a3140a1ae602a0248302b920 SHA512 50b2434013d5626b16eb3b8e36e9cac6098373948af406f89ef9143db72689e7d21e482fe1713f5a09fcd084aa9fd65c3c2979772e9f0042afb78dc827b54ba8 diff --git a/dev-java/spec-alpha/metadata.xml b/dev-java/spec-alpha/metadata.xml new file mode 100644 index 000..aeb8a865b1f --- /dev/null +++ b/dev-java/spec-alpha/metadata.xml @@ -0,0 +1,8 @@ + +http://www.gentoo.org/dtd/metadata.dtd;> + + + + clojure/spec.alpha + + -- 2.24.1 From 7fae2d16c41e4d62dd76f958fcd30c78b2ea7fcd Mon Sep 17 00:00:00 2001 From: Tom Gillespie Date: Fri, 3 Jan 2020 02:39:38 -0500 Subject: [PATCH 1/5] dev-java/spec-alpha: added for clojure build >=clojure-1.9.0 depends on spec-alpha includes an ant build.xml file to avoid maven Signed-off-by: Tom Gillespie --- dev-java/spec-alpha/Manifest | 5 ++ dev-java/spec-alpha/files/build.xml | 37 +++ dev-java/spec-alpha/spec-alpha-0.1.143.ebuild | 47 +++ dev-java/spec-alpha/spec-alpha-0.2.176.ebuild | 47 +++ 4 files changed, 136 insertions(+) create mode 100644 dev-java/spec-alpha/Manifest create mode 100644 dev-java/spec-alpha/files/build.xml create mode 100644 dev-java/spec-alpha/spec-alpha-0.1.143.ebuild create mode 100644 dev-java/spec-alpha/spec-alpha-0.2.176.ebuild diff --git a/dev-java/spec-alpha/Manifest b/dev-java/spec-alpha/Manifest new file mode 100644 index 000..db86db8f403 --- /dev/null +++ b/dev-java/spec-alpha/Manifest @@ -0,0 +1,5 @@ +AUX build.xml 1401 BLAKE2B 500b8a1de2b452a1198d66a222e82a8bc78fdc2827d457a50b70d5ffa59866a1f37295a4b275b7ded9bab2a544ee5458b98fba308fb6833816c7567cfc33 SHA512 6d2297aaa240e05688a8062ea02bbb6e488567c00df83d8325c75862240ab109d8c0d9f3779c702161a98ac2f0f684ab87d81c3c0637d73ec382e4e9ca2cf36b +DIST spec.alpha-0.1.143.tar.gz 35568 BLAKE2B f63fdd2b3c83dbd3936e36ff57b6ea399b7173fe805c60a6ecbd8e4aef5942f051a8551c259d89885a202c20045f67921b66c4dc9e361aacc8903c6542d7c7b5 SHA512 87887d72bc7343f96fad937b90feb4cc1be1eeaad8b7c01ae090ebe5cb17c30612e63797ea9eb39e6fe4c07870dcba9e153a98777d372923e95163f3219a976c +DIST spec.alpha-0.2.176.tar.gz 37055 BLAKE2B 0588772e4a47a5b122984abefaf5ef2d0fffbacaf277b22737c94889e646c16a029017d405b72b829e88bcf03b12f689cb2053884b24b47193a26978ab54a318 SHA512 decf0dbff09bf8ee12503e6117ab635b98cd8dd2c389acf7aeebf00f32b5fd8250d66c2ec54cfe5da45e727e39480ae738a3ee7fcad71684d8c3acf464fe21e7 +EBUILD spec-alpha-0.1.143.ebuild 960 BLAKE2B a3534caaf1e4f28a8b892b086c4427f0e6da7dae63232ba7aff769df6737f4fd927b64fd065c92f891267dea0b6eefc46f8ec0c437a0ddd174fd077ecd9bb37f SHA512
Re: [gentoo-dev] Ebuild Generators
For historical curiosity there was also https://github.com/domenkozar/g-pypi at one point (similar to https://github.com/rafaelmartins/g-octave). Having used g-octave, the primary issue is as Michał says, there are a lot of corner cases that the generation doesn't handle correctly which lead to broken ebuilds and maintenance headaches. Speaking for python, catching and correcting the use of setup_requires and other insanity visited upon us by the wonders of setuptools makes this a non-starter. If you have a set a known sane packages you could in theory write an eclass that captures the regularities of those packages, but I'm not sure eclasses are suggested for that use case. Tom On Mon, Feb 3, 2020 at 5:27 AM Michał Górny wrote: > > On Mon, 2020-02-03 at 14:20 +0100, Gerion Entrup wrote: > > Am Montag, 3. Februar 2020, 13:19:52 CET schrieb Benda Xu: > > > 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. > > I mean only on a primitive base: > > ``` > > if link contains "pypi": > > # it's a Python package from pypi > > handle_pypi() > > elif work_tree contains "setup.py": > > # it's a Python package > > handle_generic_python() > > > > Please don't use generators for Python. You'd have to put a lot of > effort to get things right. Most of the time, you'll end up with broken > or no tests, useless deps and py2 where unnecessary. > > Creating ebuilds is not a problem. Maintaining is. Python team ended > up with lots of packages dumped by former project members or other > developers. Many of them are of very bad quality. Even those that > aren't are a maintenance burden. Removing broken and/or useless > packages is taking a lot of our time. > > -- > Best regards, > Michał Górny >
Re: [gentoo-dev] Should we allow "GPL, v2 or later" for ebuilds?
[2020-01-30 08:19:08-0500] Rich Freeman:
> On Thu, Jan 30, 2020 at 6:20 AM Haelwenn (lanodan) Monnier
> wrote:
> > [2020-01-27 12:41:26+0100] Ulrich Mueller:
> > > So, the question is, should we allow ebuilds
> > > # Distributed under the terms of the GNU General Public License, v2 or
> > > later
> > > in the repository, or should we even encourage it for new ebuilds?
> > >
> > > I have somewhat mixed feelings about this. One the one hand, I think
> > > that GPL-2+ should generally be preferred because it offers better
> > > compatibility. For example, the compatibility clause in CC-BY-SA-4.0
> > > won't work with GPL-2.
> >
> > Is there another reason for GPL-2+ than just compatibility?
> > Because I quite find the "or later" thing to be quite a scary one as
> > whatever will come up next as a GPL will become applicable and it feels
> > quite weird to me to have a license that can evolve to whatever
> > license over time.
> Really the main threat (IMO) is that the code could be de-copylefted.
> They could make GPL v4 a copy of the BSD license, and now anything
> that was v2+ is effectively BSD and can be used in non-FOSS software
> without issue. I guess that isn't any worse than the previous case of
> it instead being merged into some other v4 variant that you can access
> the source for but prefer to avoid because of something else in the
> license, except now you might not see the code at all.
Yeah, I quite share this opinion/view, with also the scary wonder of
who can author a GPL-4 license as there doesn't seems to be any
restriction for this in the license, just a "or later".
> Another solution to this problem is the FLA - which is something we've
> talked about but shelved until we've sorted out some of our other
> copyright issues which were thorny enough. Perhaps we could consider
> taking that up again. Without getting into the details it is a bit
> like a copyleft-style copyright assignment, which isn't actually an
> assignment. We envisoned it being voluntary and would allow any
> contributor to give the Foundation the authority to relicense their
> contributions, with a number of restrictions, like the new license
> being FOSS. I'd have to dig up the latest version and take a look at
> it again. Basically instead of trusting the FSF you'd be trusting the
> Foundation instead, but there are some limitations on what they'd be
> allowed to do, and if they violate those limitations the agreement
> would be canceled and the rights would revert back to whatever was on
> the original contribution, which would probably be whatever the author
> originally wanted. That said, I'm not sure it really provides a whole
> lot more protection over what happens except for the fact that
> Foundation members have more say in how the Foundation operations than
> the FSF, if only because the number of people allowed to vote are
> limited to a relatively small pool Gentoo contributors, at least
> compared to the entire FOSS community.
I guess the FLA would be really interesting to have to get the quite
useful flexibility of relicensing but keeping it to Gentoo Foundation
to avoid giving this flexibility to everyone.
Maybe it could for now be a simple agreement on putting your code to
the Gentoo Foundation under the GPL-2+ but it would be published under
the GPL-{2,3,…}?
Re: [gentoo-dev] Inconsistent use of || preferences for www-client/elinks, links, lynx, w3m, and w3mmee
On 2/11/20 12:32 PM, Francesco Riosa wrote: > > > Il giorno lun 10 feb 2020 alle ore 08:20 Michał Górny > mailto:mgo...@gentoo.org>> ha scritto: > > On Sun, 2020-02-09 at 22:51 -0800, Zac Medico wrote: > > In that case, I suppose we'll have to apply consistency > manually? Can we > > all agree on a global order of preference for the relevant packages? > > That would be my idea, yes. I'd suggest going for the 'lightest' > package first. Would you be able to figure out some kind of measure > on how heavy each of those packages is? I suppose we need to account > for build time and dependencies. > > All of these packages are pretty old and not receiving commits in > years, may I suggest that the order should be from the less prone to > break to the most prone to break? How do you determine this? > I'll leave to maintainers decide on how to assign a vote on resilience, Ah. So no. Whats wrong with simply sorting by alphabetic order? Elinks seems a fine default for those who don't care enough to change it. -- juippis signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: app-vim/cream
# David Seifert (2020-02-11) # Unmaintained, EAPI 4, last release over 9 years ago, no revdeps. # Removal in 30 days. app-vim/cream signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: net-im/coccinella
# David Seifert (2020-02-11) # Unmaintained, EAPI 4, last release over 9 years ago, ebuild has QA # issues, no revdeps. Removal in 30 days. Bug #558354. net-im/coccinella signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: uid/gid for octoprint
В письме от вторник, 11 февраля 2020 г. 14:27:08 MSK пользователь Ulrich Mueller написал: > > On Tue, 11 Feb 2020, Alexey 'Alexxy' Shvetsov wrote: > > Ok. What is you're suggestion? > > If you really need that kind of mnemonics, how about 368 (68 being the > ASCII code for "D")? > > Ulrich i think Ulrich suggestion is better =D -- Best regards, Alexey 'Alexxy' Shvetsov signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: uid/gid for octoprint
> On Tue, 11 Feb 2020, Alexey 'Alexxy' Shvetsov wrote: > Ok. What is you're suggestion? If you really need that kind of mnemonics, how about 368 (68 being the ASCII code for "D")? Ulrich signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: uid/gid for octoprint
Ok. So it can be 340 for both uid an gid (its free) В письме от вторник, 11 февраля 2020 г. 14:17:48 MSK пользователь Michał Górny написал: > On Tue, 2020-02-11 at 14:15 +0300, Alexey 'Alexxy' Shvetsov wrote: > > В письме от вторник, 11 февраля 2020 г. 13:52:46 MSK пользователь Michał > > Górny> > > написал: > > > On Tue, 2020-02-11 at 13:18 +0300, Alexey 'Alexxy' Shvetsov wrote: > > > > В письме от вторник, 11 февраля 2020 г. 13:15:48 MSK пользователь > > > > Michał > > > > Górny> > > > > > > > > написал: > > > > > On Tue, 2020-02-11 at 13:06 +0300, Alexey 'Alexxy' Shvetsov wrote: > > > > > > Hi all! > > > > > > > > > > > > I'd like to reserve uid/gid 34 (3D printing) for > > > > > > www-apps/octoprint > > > > > > (cups > > > > > > analog for 3d printing) > > > > > > > > > > What is the rationale for taking UID/GID from the low range? > > > > > > > > 3 D (D is the 4 letter in latin alphabet) > > > > > > That's not a good justification. NAK. > > > > Ok. What is you're suggestion? > > Take any number in the 101..499 range, as indicated in the policy. -- Best regards, Alexey 'Alexxy' Shvetsov signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: uid/gid for octoprint
On Tue, 2020-02-11 at 14:15 +0300, Alexey 'Alexxy' Shvetsov wrote: > В письме от вторник, 11 февраля 2020 г. 13:52:46 MSK пользователь Michał > Górny > написал: > > On Tue, 2020-02-11 at 13:18 +0300, Alexey 'Alexxy' Shvetsov wrote: > > > В письме от вторник, 11 февраля 2020 г. 13:15:48 MSK пользователь Michał > > > Górny> > > > написал: > > > > On Tue, 2020-02-11 at 13:06 +0300, Alexey 'Alexxy' Shvetsov wrote: > > > > > Hi all! > > > > > > > > > > I'd like to reserve uid/gid 34 (3D printing) for www-apps/octoprint > > > > > (cups > > > > > analog for 3d printing) > > > > > > > > What is the rationale for taking UID/GID from the low range? > > > > > > 3 D (D is the 4 letter in latin alphabet) > > > > That's not a good justification. NAK. > > Ok. What is you're suggestion? > Take any number in the 101..499 range, as indicated in the policy. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: uid/gid for octoprint
В письме от вторник, 11 февраля 2020 г. 13:52:46 MSK пользователь Michał Górny написал: > On Tue, 2020-02-11 at 13:18 +0300, Alexey 'Alexxy' Shvetsov wrote: > > В письме от вторник, 11 февраля 2020 г. 13:15:48 MSK пользователь Michał > > Górny> > > написал: > > > On Tue, 2020-02-11 at 13:06 +0300, Alexey 'Alexxy' Shvetsov wrote: > > > > Hi all! > > > > > > > > I'd like to reserve uid/gid 34 (3D printing) for www-apps/octoprint > > > > (cups > > > > analog for 3d printing) > > > > > > What is the rationale for taking UID/GID from the low range? > > > > 3 D (D is the 4 letter in latin alphabet) > > That's not a good justification. NAK. Ok. What is you're suggestion? -- Best regards, Alexey 'Alexxy' Shvetsov signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: uid/gid for octoprint
On Tue, 2020-02-11 at 13:18 +0300, Alexey 'Alexxy' Shvetsov wrote: > В письме от вторник, 11 февраля 2020 г. 13:15:48 MSK пользователь Michał > Górny > написал: > > On Tue, 2020-02-11 at 13:06 +0300, Alexey 'Alexxy' Shvetsov wrote: > > > Hi all! > > > > > > I'd like to reserve uid/gid 34 (3D printing) for www-apps/octoprint (cups > > > analog for 3d printing) > > > > What is the rationale for taking UID/GID from the low range? > > 3 D (D is the 4 letter in latin alphabet) > That's not a good justification. NAK. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Inconsistent use of || preferences for www-client/elinks, links, lynx, w3m, and w3mmee
Il giorno lun 10 feb 2020 alle ore 08:20 Michał Górny ha scritto: > On Sun, 2020-02-09 at 22:51 -0800, Zac Medico wrote: > > In that case, I suppose we'll have to apply consistency manually? Can we > > all agree on a global order of preference for the relevant packages? > > That would be my idea, yes. I'd suggest going for the 'lightest' > package first. Would you be able to figure out some kind of measure > on how heavy each of those packages is? I suppose we need to account > for build time and dependencies. > > All of these packages are pretty old and not receiving commits in years, may I suggest that the order should be from the less prone to break to the most prone to break? I'll leave to maintainers decide on how to assign a vote on resilience, but monitoring upstream, active forks and other distro should be taken in account. Best, Francesco
Re: [gentoo-dev] RFC: uid/gid for octoprint
В письме от вторник, 11 февраля 2020 г. 13:15:48 MSK пользователь Michał Górny
написал:
> On Tue, 2020-02-11 at 13:06 +0300, Alexey 'Alexxy' Shvetsov wrote:
> > Hi all!
> >
> > I'd like to reserve uid/gid 34 (3D printing) for www-apps/octoprint (cups
> > analog for 3d printing)
>
> What is the rationale for taking UID/GID from the low range?
Also i seems need a group/user for uucp as dep (since octoprint need access to
/dev/tty{USB,ACM} or other types of com ports
--
Best regards,
Alexey 'Alexxy' Shvetsov
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: uid/gid for octoprint
В письме от вторник, 11 февраля 2020 г. 13:15:48 MSK пользователь Michał Górny написал: > On Tue, 2020-02-11 at 13:06 +0300, Alexey 'Alexxy' Shvetsov wrote: > > Hi all! > > > > I'd like to reserve uid/gid 34 (3D printing) for www-apps/octoprint (cups > > analog for 3d printing) > > What is the rationale for taking UID/GID from the low range? 3 D (D is the 4 letter in latin alphabet) -- Best regards, Alexey 'Alexxy' Shvetsov signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: uid/gid for octoprint
On Tue, 2020-02-11 at 13:06 +0300, Alexey 'Alexxy' Shvetsov wrote: > Hi all! > > I'd like to reserve uid/gid 34 (3D printing) for www-apps/octoprint (cups > analog for 3d printing) What is the rationale for taking UID/GID from the low range? -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] RFC: uid/gid for octoprint
Hi all! I'd like to reserve uid/gid 34 (3D printing) for www-apps/octoprint (cups analog for 3d printing) -- Best regards, Alexey 'Alexxy' Shvetsov signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Last-rites: net-misc/wicd
Ühel kenal päeval, E, 10.02.2020 kell 00:43, kirjutas Stefan Strogin: > Upd. > The port to Python 3 is not finished in the upstream. > Particularly it is still using pygtk, it seems no work in porting to > gtk+3 has been done yet. Just to be clear of misunderstanding here: A port away from py2-only pygtk does not necessarily have to mean a port to gtk+:3 at the same time - pygobject:3 (the `from gi.repository import ...` stuff) works just fine with gtk+:2[introspection] as well. Of course ideally it would be ported to gtk3 as well (and starting with later this year to gtk4). Mart signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH 3/3] app-admin/kube-bench: convert to go-module go.sum
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 +, 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
