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

[Sam Jorna (wraeth)]

On Saturday, 15 February 2020 3:14:55 AM AEDT Matt Turner wrote:
> On Fri, Feb 14, 2020 at 12:31 AM Sam Jorna (wraeth)  
wrote:
> > In this instance, at least two people (myself included) have drawn an
> > impression that led them to voice their concern in some way (I'm unsure if
> > mpagano was voicing concern or just agreeing with the general concept).
> > Maybe we're the only ones. Maybe not.
> 
> What do you think the threshold should be? If one person objects,
> should ComRel cease and desist? Two? Should we have a Gentoo-wide
> vote?
> 
> I don't have the highest opinion of ComRel and I'm a member, but maybe
> you could let us do our jobs?

I didn't say ComRel shouldn't do their job, nor offered any opinion on ComRel 
whatsoever. I said people shouldn't be called out on what looks like a 
legitimate question, and that quote was illustrating one of the reasons why. 
The threshold I'm talking about would be "is this question, however it's 
worded, relevant to the subject."

Having said that, if this is you wearing a ComRel hat telling me to mind my 
own business, so be it.

-- 
Sam Jorna (wraeth)
GnuPG ID: 0xD6180C26



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

[Sam Jorna (wraeth)]

On Friday, 14 February 2020 2:21:32 PM AEDT Matt Turner wrote:
> On Thu, Feb 13, 2020 at 4:12 AM Mike Pagano  wrote:
> > On Thu, Feb 13, 2020 at 06:46:43PM +1100, Sam Jorna (wraeth) wrote:
> > > On Thursday, 13 February 2020 5:40:46 AM AEDT Matt Turner wrote:
> > > > On Wed, Feb 12, 2020 at 9:59 AM William Hubbs  
wrote:
> > > > > On Wed, Feb 12, 2020 at 06:54:19PM +1100, Sam Jorna (wraeth) wrote:
> > > > > > 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?>
> > > > > 
> > > > > I wasn't going to say anything, but I can't let this go by without
> > > > > commenting.
> > > > > 
> > > > > Sam is correct. Maybe the tone is a bit off, (and that is
> > > > > debatable),
> > > > > but this definitely can be seen as a legit question, regardless of
> > > > > other
> > > > > things Michael has posted.
> > > > 
> > > > Unfortunately it's not about a single issue or email. It's a
> > > > consistent pattern that multiple people have asked him to rein in over
> > > > a long period. :(
> > > 
> > > Without going into specifics, veremit and I have certainly had our
> > > 'differences of opinion' in the past; but I don't believe this is one
> > > of those occasions.
> > > 
> > > Calling out bad actors (not saying veremit is one, I just mean in the
> > > general sense) is an unfortunate but important task, but call them out
> > > on bad behaviour, not for what appears to be an impassioned but
> > > otherwise unremarkable query.
> > 
> > I agree with this 100 percent.  Not judging solely on the content of the
> > specific email in the thread does not allow people to grow and improve.
> > Are we all to be judged on our past behavior forever with no chance to
> > overcome past transgressions ?
> 
> That's not what's going on.

Maybe not; but that's what appears is going on.

mpagano is absolutely correct that people need an opportunity to engage 
positively if they're expected to change their behaviour in a positive way. At 
the same time, however, chastising someone without an apparent transgression 
both reinforces negative behaviour (such as the subsequent mails on that sub-
thread) *and* gives anyone not intimately familiar with that particular case 
the impression that people are ridiculed because they asked a relevant 
question (since there's no other context).

In this instance, at least two people (myself included) have drawn an 
impression that led them to voice their concern in some way (I'm unsure if 
mpagano was voicing concern or just agreeing with the general concept). Maybe 
we're the only ones. Maybe not.

I understand that you or others may have had a history of issues dealing with 
someone, perhaps to the point where even seeing their name puts a damper on 
your day. I'm sure there are people who feel the same about me. But let bad 
actors dig their own hole to fall in, even if you're certain beyond the shadow 
of a doubt that they're sitting in a darkened lair, twirling their moustache 
and saying things like "my evil plan is coming to fruition!"; because lashing 
out at an unrelated list post just looks like you're being an asshole.

-- 
Sam Jorna (wraeth)
GnuPG ID: 0xD6180C26



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

[Sam Jorna (wraeth)]

On Thursday, 13 February 2020 5:40:46 AM AEDT Matt Turner wrote:
> On Wed, Feb 12, 2020 at 9:59 AM William Hubbs  wrote:
> > On Wed, Feb 12, 2020 at 06:54:19PM +1100, Sam Jorna (wraeth) wrote:
> > > 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?> 
> > I wasn't going to say anything, but I can't let this go by without
> > commenting.
> > 
> > Sam is correct. Maybe the tone is a bit off, (and that is debatable),
> > but this definitely can be seen as a legit question, regardless of other
> > things Michael has posted.
> 
> Unfortunately it's not about a single issue or email. It's a
> consistent pattern that multiple people have asked him to rein in over
> a long period. :(

Without going into specifics, veremit and I have certainly had our 'differences 
of opinion' in the past; but I don't believe this is one of those occasions.

Calling out bad actors (not saying veremit is one, I just mean in the general 
sense) is an unfortunate but important task, but call them out on bad 
behaviour, not for what appears to be an impassioned but otherwise 
unremarkable query.

-- 
Sam Jorna (wraeth)
GnuPG ID: 0xD6180C26



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

[Sam Jorna (wraeth)]

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] Prevent binary/non-compiled packages from binary package creation

[Sam Jorna (wraeth)]

On 11/08/17 03:08, William L. Thomson Jr. wrote:
> Lets go down this rabbit hole.

Let's not.

-- 
Sam Jorna (wraeth)
GnuPG ID: D6180C26



signature.asc
Description: OpenPGP digital signature

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

[Sam Jorna (wraeth)]

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

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

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

-- 
Sam Jorna (wraeth)
GnuPG ID: D6180C26



signature.asc
Description: OpenPGP digital signature

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

[Sam Jorna (wraeth)]

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

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

-- 
Sam Jorna (wraeth)
GnuPG ID: D6180C26



signature.asc
Description: OpenPGP digital signature

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

[Sam Jorna (wraeth)]

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

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

-- 
Sam Jorna (wraeth)
GnuPG ID: D6180C26



signature.asc
Description: OpenPGP digital signature

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

[Sam Jorna (wraeth)]

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

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

-- 
Sam Jorna (wraeth)
GnuPG ID: D6180C26



signature.asc
Description: OpenPGP digital signature

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

[Sam Jorna (wraeth)]

On 09/08/17 10:43, William L. Thomson Jr. wrote:
> On Wed, 9 Aug 2017 10:29:40 +1000
> "Sam Jorna (wraeth)" <wra...@gentoo.org> wrote:
> 
>> On 09/08/17 04:20, William L. Thomson Jr. wrote:
>>> On Tue, 8 Aug 2017 19:32:48 +0200
>>> Kristian Fiskerstrand <k...@gentoo.org> wrote:  
>>>>  - You might be applying local patches through /etc/portage/patches
>>>> that are distributed to all clients  
>>>
>>> This might be the strongest reason. Though would only apply to stuff
>>> like say kernel sources. Not sure what patches could be applied to a
>>> binary ebuild, -bin. A patch would not effect src_install per my
>>> understanding.  
>>
>> There's also the fact that binpkgs may be manually installed exactly
>> as the package manager would have installed it, rather than extracting
>> whatever upstream supplies verbatim. 
> 
> What then is the benefit? If what is installed is the same from
> package manager or binpkg. Also your redistributing another's package
> in binary format which may not be legally allowed.

The difference is that how the package manager/ebuild installs the
package may be better suited to the environment than what upstream
expects (such as upstreams that install through a .run file)

>> This includes things like any wrappers, desktop files or symlinks
>> created by the ebuild, or other such downstream-isms.
> 
> If it was made via package manager. If it was made via quickpkg, it
> maybe different than if made by package manager.

Using quickpkg can create different binaries depending on your options,
but otherwise it should package any installed files as recorded by the
package manager - provided you use inclusive options, there should be no
appreciable difference as far as I'm aware.

-- 
Sam Jorna (wraeth)
GnuPG ID: D6180C26



signature.asc
Description: OpenPGP digital signature

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

[Sam Jorna (wraeth)]

On 09/08/17 04:20, William L. Thomson Jr. wrote:
> On Tue, 8 Aug 2017 19:32:48 +0200
> Kristian Fiskerstrand <k...@gentoo.org> wrote:
>>  - You might be applying local patches through /etc/portage/patches
>> that are distributed to all clients
> 
> This might be the strongest reason. Though would only apply to stuff
> like say kernel sources. Not sure what patches could be applied to a
> binary ebuild, -bin. A patch would not effect src_install per my
> understanding.

There's also the fact that binpkgs may be manually installed exactly as
the package manager would have installed it, rather than extracting
whatever upstream supplies verbatim. This includes things like any
wrappers, desktop files or symlinks created by the ebuild, or other such
downstream-isms.

-- 
Sam Jorna (wraeth)
GnuPG ID: D6180C26



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Sam Jorna (wraeth)]

On 28 July 2017 8:44:20 PM AEST, "Andreas K. Huettel"  
wrote:
>Am Dienstag, 25. Juli 2017, 01:22:44 CEST schrieb Peter Stuge:
>> 
>> I hold a perhaps radical view: I would like to simply remove stable.
>> 
>> I continue to feel that maintaining two worlds (stable+unstable)
>> carries with it an unneccessary cost.
>> 
>
>That's not feasible. It would kill off any semi-professional or
>professional 
>Gentoo use, where a minimum of stability is required. 
>
>(Try keeping ~10 machines on stable running without automation. That's
>already 
>quite some work. Now try the same with ~arch. Now imagine you're
>talking about 
>100 or 1000 machines.)

And further, try proposing that to management - that you'll be managing hosts 
on a platform that has no "stable" to speak of.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [gentoo-dev] News item: systemd rootprefix migration

[Sam Jorna (wraeth)]

On 14/07/17 11:32, Mike Gilbert wrote:
> Please share your comments/questions on the proposed news item below.
> There is no immediate action required for most users, but it seems
> like a significant enough change to warrant a broadcast.
> 
> --
> 
> Title: systemd rootprefix migration
> Author: Mike Gilbert <flop...@gentoo.org>
> Posted: 2017-07-14
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Installed: >=sys-apps/systemd-234
> 
> Starting with the 234 release, Gentoo's sys-apps/systemd package will
> be built with rootprefix=/. This means most of the included programs
> and system units will be installed under /lib/systemd instead of
> /usr/lib/systemd.
> 
> This change brings Gentoo into alignment with most other distros which
> still maintain a distiction between boot-critical programs in /, and
> less critical programs in /usr. This also means that users with a
> separate /usr filesystem will have an easier time booting if their
> initramfs should become corrupt or fail.
> 
> Symlinks are provided for /usr/lib/systemd/systemd and
> /usr/lib/systemd/systemd-shutdown to avoid breaking bootloader configs
> and to allow the system to be shutdown/rebooted without issue.

Will these symlinks be maintained indefinitely? Would it be worth
suggesting updating cmdline's to point to the new location rather than
the symlink?

> This change will be mostly transparent to typical users. You may notice
> that system units move from /usr/lib/system/system to
> /lib/system/system as you upgrade/re-install packages; this is normal.
> Units will function properly from both locations.

s:/lib/system::

> As always, if you run into problems, please report a bug.

Otherwise, lgtm.

-- 
Sam Jorna (wraeth)
GnuPG ID: D6180C26



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

[Sam Jorna (wraeth)]

On 12/07/17 16:06, William L. Thomson Jr. wrote:
> On Wed, 12 Jul 2017 15:49:14 +1000
> "Sam Jorna (wraeth)" <wra...@gentoo.org> wrote:
>>
>> I have trouble remembering what I ate for dinner last night, let alone
>> what I may or may not have merged a week, month or year ago, or what
>> options I used when merging it.
> 
> And if you used --oneshot, it is also saying you are not maintaining
> your system or ever running --depclean. Since anything you installed
> via --oneshot would be removed with --depclean.

If my concern in removing a package was whether it was a dependency, it
would make more sense to use --depclean in the first place. If I'm using
--unmerge, it's because I want the package unmerged regardless.

>>> What harm does a warning do?  
>>
>> Depends on the user, which can't really be avoided, but means that
>> warnings should be clear and meaningful, otherwise they become
>> background noise.
> 
> The example in the bug is as clear is it can get.
> 
> !!! 'sys-devel/gcc' is a dependency of another package on your system
> or
> !!! 'sys-devel/gcc' is a package not found in system profile or world
> or
> !!! 'sys-devel/gcc' may not have been installed by you
> or
> some other message
> 
>> Such as:
>>
>> emerge --unmerge dev-python/keyring
>>  * This action can remove important packages! In order to be safer,
>> use
>>  * `emerge -pv --depclean ` to check for reverse dependencies
>> before
>>  * removing packages.
> 
> Didn't you just say something about meaningful output vs noise? That is
> always outputted and ends up becoming what you are saying. Funny!

And your suggesting adding more noise to it... Funny, I know.

>>>> or may have been installed as an orphan but is now a
>>>> dependency.   
>>>
>>> Now being a dependency the warning would be valid.  
>>
>> "Sometimes being accurate" is not the most noble of goals.
> 
> What?
> 
>> So the idea is to duplicate the functionality of '--depclean
>> 
> 
> NO!!!
> 
> emerge --depclean gcc 
> 
> is not the same as 
> 
> emerge --umerge gcc
> 
> Depclean the user is cleaning things they are not aware of. Unmerge the
> user is removing something directly. They may think they do not need it.

No.

'--depclean' is the user removing things they are not aware of.

'--depclean foo' is the user removing something they /are/ aware of *if
it's not a dependency*.

'--unmerge foo' is the user explicitly removing something regardless of
whether it's a dependency.

Therefore, '--depclean foo' can be seen as a safe '--unmerge foo' which,
from what I understand, is what you're aiming for.

>> ' without actually checking to see if the package is a
>> dependency,
> 
> Word it how ever. If the user did not install, they should be warned on
> removal of a package they did not install.

That's what the current warning to --unmerge says - removing packages
can break things, so please make sure this isn't a dependency and you
really want to remove this.

>> only whether it is listed in a set; or to check if it's a
>> dependency of /something/ and, if so, redirect the user to the
>> command they should be using anyway?
> 
> You mean like emerge --unmerge does already that you pointed out
> above. After mentioning useful messages vs noise.  Again funny!

How does replacing one warning with another warning that may or may not
be meaningful ("maybe it's a dep, maybe it isn't" as opposed to "this
can be dangerous, please make sure you know what you're doing") make it
any better?

-- 
Sam Jorna (wraeth)
GnuPG ID: D6180C26



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

[Sam Jorna (wraeth)]

On 12/07/17 15:14, William L. Thomson Jr. wrote:
> Is it in system?
> Is it in a set?
> Is it in world?
> If no to all, its a dep, warn!

All this says is whether the package was explicitly installed and
recorded in world, or is a member of @system. The target package may or
may not be a dependency, may or may not have been --oneshot'd.

It may have been installed as a dependency but the requiring package was
removed, or may have been installed as an orphan but is now a
dependency. Assuming that if it's not in a set it must be a dependency
is incorrect and misleading.

-- 
Sam Jorna (wraeth)
GnuPG ID: D6180C26



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

[Sam Jorna (wraeth)]

On 12/07/17 14:43, William L. Thomson Jr. wrote:
>>> It is not the same as -C, which is remove a package directly.
>>>
>>>  --unmerge (-C)  
>> Correct, --unmerge will remove a package without considering
>> dependencies (give or take a few special cases). It is usually (or, at
>> least, should generally be) reserved for those taking a hammer to a
>> problem or with a particular desire to recover a broken system.
>>
>> Again, it's doing exactly what it's supposed to - removing a package
>> you've told it to remove (unless it's one of the few
>> almost-always-critical packages).
> Yes and if you see bug. All I am saying is adding warnings when someone
> goes to remove a dependency. Since a dependency IS a critical package :)
> 
> Add warning message when -C/--unmerge a dependency like system,
> profile, and set files.
> https://bugs.gentoo.org/show_bug.cgi?id=624630

My point was that --unmerge is not intended to be dependency-aware.
--depclean is. As far as I can tell, that is the point others have been
trying to make as well, when pointing out the differences between -c and -C.

-- 
Sam Jorna (wraeth)
GnuPG ID: D6180C26



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

[Sam Jorna (wraeth)]

On 12/07/17 10:05, William L. Thomson Jr. wrote:
> I should have caught that sooner. -c does not remove a package, it just
> removes its deps.
> 
> -c == --depclean.

--depclean is doing exactly what it is supposed to. If called with no
arguments, it searches for any unneeded dependencies and removes them,
however if called with a package as an argument, it will remove that
package *if it is not a dependency of another package*. Reporting
"nothing to remove" is precisely what it's supposed to do, and using
--verbose will tell you what is depending on the package.

To be clear, running '--depclean foo' does not remove dependencies of
foo, it removes foo provided it is not a dependency. It can be seen as a
dependency-aware (and thus, generally safe) --unmerge.

Making --depclean _always_ give you more information should just be a
case of adding --verbose to EMERGE_DEFAULT_OPTS.

> It is not the same as -C, which is remove a package directly.
> 
>  --unmerge (-C)

Correct, --unmerge will remove a package without considering
dependencies (give or take a few special cases). It is usually (or, at
least, should generally be) reserved for those taking a hammer to a
problem or with a particular desire to recover a broken system.

Again, it's doing exactly what it's supposed to - removing a package
you've told it to remove (unless it's one of the few
almost-always-critical packages).

-- 
Sam Jorna (wraeth)
GnuPG ID: D6180C26



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: taking a break from arches stabilization

[Sam Jorna (wraeth)]

On 12/07/17 03:16, William Hubbs wrote:
> On Tue, Jul 11, 2017 at 11:47:32PM +1000, Michael Palimaka wrote:
>> On 07/11/2017 11:06 PM, Rich Freeman wrote:
>>> On Tue, Jul 11, 2017 at 8:59 AM, Michael Palimaka <kensing...@gentoo.org> 
>>> wrote:
>>>> On 07/11/2017 09:29 AM, Andrew Savchenko wrote:
>>>>>
>>>>> Even if such stabilization is allowed, there are unanswered
>>>>> questions here:
>>>>> - is following seciton 4.1 from wg recommendations is sufficient?
>>>>> - should developer test each stabilization candidate on an
>>>>> up-to-date stable setup?
>>>>
>>>> The guidelines from that document are ripped straight out of the
>>>> devmanual and are a good starting point but rather generic. You can find
>>>> some more detailed suggestions on things to consider while testing on
>>>> the wiki: https://wiki.gentoo.org/wiki/Package_testing
>>>>
>>>
>>> I think that in practice arch teams don't do have the stuff on that
>>> wiki page.  Maybe some people do, but back when I was an amd64 AT I
>>> don't think anybody went testing multiple USE combinations for a
>>> typical package.
>>
>> Everything on that page is deliberately a suggestion only, and not
>> necessarily specific to stabilisation testing.
>>
>> In the end, we've never been able to reach any consensus on what exactly
>> an arch tester should do. Personally, I think we should just switch to
>> fully-automated, build-only testing for stabilistions unless the
>> maintainer opts otherwise (something that largely happens in practice
>> already). The main risk of breakage of a package moving from testing to
>> stable is always at build time anyway.
> 
> I would not be opposed to this. As a maintainer, I am as guilty as the
> next guy of not filing stable requests or not stabilizing packages.

As the next guy, I also +1 this.

As is often explained in #gentoo, "stable" and "testing" for upstream
have a different meaning to "stable" and "testing" for Gentoo - in fact,
beyond ensuring it builds, any testing performed by a downstream distro
is additional testing to what upstream have already released.

I can understand the concern with automatically stabilising a package
that has some flaw affecting users, but the two things i see are that
upstream have already released said flawed package, and Gentoo simply
doesn't have the manpower to perform comprehensive runtime testing of
all packages.

If a maintainer is aware of a significant issue with a package that
should prevent it from being marked as stable, then a bug should be
filed acting as a block to the automated stabilisation. Users aware of
an issue are just as likely to file a bug as well, also preventing
stabilisation of packages with some known issue. Therefore packages with
known issues don't get stabilised automatically.

Similarly, if the maintainer believes more comprehensive testing should
be done (eg. for critical base-system packages) a note could be made
somewhere of that requirement (metadata.xml?), meaning significantly
reduced workload for people like ago (if the maintainer doesn't
stabilise it beforehand).
-- 
Sam Jorna (wraeth)
GnuPG ID: D6180C26



signature.asc
Description: OpenPGP digital signature