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
> 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.
> On Sat, 21 Dec 2019, Michael Orlitzky wrote:
> And then you tried to use my suggestion to be extra careful and run a
> CI check against me, which is obnoxious, so there you go.
Maybe you shouldn't suggest usage of non-free tools (like Github) then?
It's everyone's own choice if they want
On 12/21/19 6:39 AM, Ulrich Mueller wrote:
>> On Sat, 21 Dec 2019, Michael Orlitzky wrote:
>
>> I was being safe, and assuming that your standards for shell scripting
>> are as low as your standards for tree quality.
>
> Nice, resorting to a personal attack when out of arguments. :(
>
And
On 12/21/19 6:39 AM, Ulrich Mueller wrote:
>> On Sat, 21 Dec 2019, Michael Orlitzky wrote:
>
>> I was being safe, and assuming that your standards for shell scripting
>> are as low as your standards for tree quality.
>
> Nice, resorting to a personal attack when out of arguments. :(
>
I'm
> On Sat, 21 Dec 2019, Michael Orlitzky wrote:
> I was being safe, and assuming that your standards for shell scripting
> are as low as your standards for tree quality.
Nice, resorting to a personal attack when out of arguments. :(
On 12/21/19 1:57 AM, Ulrich Mueller wrote:
>
> See? You say it yourself, with 400 revbumps there is quite some chance
> for breakage.
>
I was being safe, and assuming that your standards for shell scripting
are as low as your standards for tree quality.
> On Fri, 20 Dec 2019, Michael Orlitzky wrote:
> Portage seems OK with the missing dependency, but for the overall plan
> to work, you have to wait a long time before deleting virtual/emacs;
> otherwise the upgrade path is broken. With virtual/emacs-26 installed
> and "old" copies of the
On 12/18/19 6:28 PM, Michael Orlitzky wrote:
>
> This *does* happen if you mask virtual/emacs. It *could* happen if you
> delete it.
>
I tested this out.
Portage seems OK with the missing dependency, but for the overall plan
to work, you have to wait a long time before deleting virtual/emacs;
On 12/18/19 11:34 AM, Ulrich Mueller wrote:
>
> Removal of the virtual/emacs ebuilds won't remove the installed package
> from users' systems. It will eventually disappear, when all its reverse
> dependencies have been updated. Why would its continued presence as an
> installed package (for
> On Wed, 18 Dec 2019, Michael Orlitzky wrote:
>> No revbumps will be done for this (and virtual/emacs will be simply
>> removed without prior masking).
> I guess it's nice that we know ahead of time, but is there any reason
> to suspect that this won't cause havoc?
Removal of the
On 12/18/19 6:08 AM, Ulrich Müller wrote:
> No revbumps will be done for this (and virtual/emacs will be simply
> removed without prior masking).
I guess it's nice that we know ahead of time, but is there any reason to
suspect that this won't cause havoc?
> On Wed, 18 Dec 2019, Michał Górny wrote:
>> - Package mask app-editors/emacs-vcs (but not the virtual) for removal.
> Maybe package.deprecated the virtual?
Good idea. I have to get used to this. :-)
signature.asc
Description: PGP signature
Dnia December 18, 2019 11:08:16 AM UTC, "Ulrich Müller"
napisał(a):
>The package split between app-editors/emacs for regular ebuilds and
>app-editors/emacs-vcs for live ebuilds has outlived its usefulness, and
>it entails additional maintenance effort to keep the two packages
>(e.g.,
>the list
14 matches
Mail list logo
