Re: [gentoo-dev] Lastrites: dev-java/jikes, net-misc/netkit-rusers, net-print/xerox-drivers, dev-dotnet/gnome-sharp...

[Brian Evans]

> # Pacho Ramos  (27 Dec 2017)
> # All Ekiga set is dead and broken for years, it relies on obsolete
> # dead/libs that are also old and broken and upstream looks to not release
> # newer ekiga ever. To keep this please go ahead and take care of it *and
> # all the dependencies it also needs*. See bugs #626176, #460458, #589276,
> # #638122, #641990, #633670, #624578, #600398, #627868.
> # Removal in a month.
> net-libs/ptlib
> net-libs/opal
> net-voip/openmcu
> net-voip/ekiga
> 
> 

It seems you missed net-libs/h323plus which needs net-libs/ptlib.

h323plus is needed for net-voip/openmcu (already masked above) and
net-voip/yate[h323]



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH 1/1] profiles: drop USE=cracklib from base/make.defaults.

[Mart Raudsepp]

On K, 2017-12-27 at 09:57 -0500, Michael Orlitzky wrote:
> > 2) What you plan to do to have USE=cracklib enabled by default. Two
> > people suggested you should keep this (one way or another) but
> instead
> > everyone is now without it enabled by default.
> 
> I plan to do nothing, because I think it should be disabled by
> default
> like all other USE flags. I've CC'ed all of the maintainers who might
> want to add the default to IUSE, and apparently none of them do. The
> hardened project and base-system are also CCed/assigned in case one
> of
> them wanted to adopt the default.
> 
> The base profile is the wrong place to enable USE=cracklib, but there
> are better places. If none of the people in charge of those places
> want
> to enable the flag, then maybe it should remain disabled.

If USE=cracklib is ever removed from base/make.defaults, then this IUSE
default enabling should be done before it is removed for many of the
places where it helps password safety, not afterwards when some
maintainers happen to see you've done it some months later, after we
have dozens of users with "12345" passwords or something.

If you need more opposing, then consider this one, as long as this
preparation work isn't done. Just removing it because maintainers
didn't get to it in your timeline isn't something I would see OK. If
you want to make such a base profile change, then I believe you should
contact the maintainers and see which one wants it default disabled,
and which default enabled; do the default enabled changes and only
afterwards you can touch a base default USE flag, otherwise you are
making a change to all these maintainers packages without their
consent. It IS an effective change to their package, and you are
effectively doing non-maintainer changes to them.



Mart

Re: [gentoo-dev] Lastrites: dev-java/jikes, net-misc/netkit-rusers, net-print/xerox-drivers, dev-dotnet/gnome-sharp...

[Mart Raudsepp]

On K, 2017-12-27 at 10:31 -0500, Brian Evans wrote:
> > 
> > # Pacho Ramos  (27 Dec 2017)
> > # All Ekiga set is dead and broken for years, it relies on obsolete
> > # dead/libs that are also old and broken and upstream looks to not
> > release
> > # newer ekiga ever. To keep this please go ahead and take care of
> > it *and
> > # all the dependencies it also needs*. See bugs #626176, #460458,
> > #589276,
> > # #638122, #641990, #633670, #624578, #600398, #627868.
> > # Removal in a month.
> > net-libs/ptlib
> > net-libs/opal
> > net-voip/openmcu
> > net-voip/ekiga
> > 
> > 
> 
> It seems you missed net-libs/h323plus which needs net-libs/ptlib.
> 
> h323plus is needed for net-voip/openmcu (already masked above) and
> net-voip/yate[h323]

Note that h323plus is active with latest release from 2017-09-01. Also
ptlib on h323plus website points at a version 2.12.8, while we only
have 2.10.11 - possibly because ekiga doesn't work with that 2.12.x.

Doesn't mean it can't be last rited due to maintainer-needed and
getting in the way of something; just mentioning how the state upstream
is, if someone wants to pick up h323plus or something. Perhaps radio@
as maintainers of yate?


Mart

Re: [gentoo-dev] Re: RFC: News: systemd sysv-utils blocker resolution

[Mike Gilbert]

On Tue, Dec 26, 2017 at 7:18 PM, Robin H. Johnson  wrote:
> On Tue, Dec 26, 2017 at 11:22:50PM +0100, Jason A. Donenfeld wrote:
>> You might want to mention that alternatively, uninstalling
>> openrc on a systemd profile system is fine to do
>> these days, despite the warning.
> If you're using netifrc's systemd support, this would break your
> networking ;-).

I guess the winky face means you are not serious, but I'll respond anyway. :-)

I suspect the number of people using systemd with netifrc is in the
single digits. I would rather not clutter the news item to account for
this scenario.

Re: [gentoo-dev] Re: RFC: News: systemd sysv-utils blocker resolution

[Mike Gilbert]

On Tue, Dec 26, 2017 at 5:22 PM, Jason A. Donenfeld  wrote:
> You might want to mention that alternatively, uninstalling
> openrc on a systemd profile system is fine to do
> these days, despite the warning.

I have added the following text after the third paragraph. Let me know
if this is insufficient.

Enabling sysv-utils should cause Portage to un-merge sysvinit and OpenRC
if they are currently installed. emerge may emit a warning message
before doing so; if you are booting with systemd, this message is safe
to ignore.

Re: [gentoo-dev] Re: RFC: News: systemd sysv-utils blocker resolution

[Francesco Riosa]

On 12/27/17 16:47, Mike Gilbert wrote:
> On Tue, Dec 26, 2017 at 7:18 PM, Robin H. Johnson  wrote:
>> On Tue, Dec 26, 2017 at 11:22:50PM +0100, Jason A. Donenfeld wrote:
>>> You might want to mention that alternatively, uninstalling
>>> openrc on a systemd profile system is fine to do
>>> these days, despite the warning.
>> If you're using netifrc's systemd support, this would break your
>> networking ;-).
> I guess the winky face means you are not serious, but I'll respond anyway. :-)
>
> I suspect the number of people using systemd with netifrc is in the
> single digits. I would rather not clutter the news item to account for
> this scenario.
Just for the record,
 I'm using it if using systemd (desktop systems), it's the only network
manager that use iproute2 syntax, shortening it if context is available
(no need to specify interface if it's mentioned in variable name f.ex.).
Beside I don't like NetworkManager

worse than that I'm actually using the same gentoo image with openrc and
systemd in different scenarios.
Basically my build box is using openrc inside a lxc container (no use of
netifrc, since net is managed by lxc).
The clients of the build box instead boot with systemd _and_ netifrc.

Gentoo is used by people who like to change defaults and (ab)use the
(autodocumented) flexibility offered by portage and ebuilds. Don't be
light in assuming how strange people is using strange configuration, and
population of strange people, that could be surprising.

Re: [gentoo-dev] [PATCH 1/1] profiles: drop USE=cracklib from base/make.defaults.

[William Hubbs]

On Wed, Dec 27, 2017 at 05:42:04PM +0200, Mart Raudsepp wrote:
> On K, 2017-12-27 at 09:57 -0500, Michael Orlitzky wrote:
> > > 2) What you plan to do to have USE=cracklib enabled by default. Two
> > > people suggested you should keep this (one way or another) but
> > instead
> > > everyone is now without it enabled by default.
> > 
> > I plan to do nothing, because I think it should be disabled by
> > default
> > like all other USE flags. I've CC'ed all of the maintainers who might
> > want to add the default to IUSE, and apparently none of them do. The
> > hardened project and base-system are also CCed/assigned in case one
> > of
> > them wanted to adopt the default.
> > 
> > The base profile is the wrong place to enable USE=cracklib, but there
> > are better places. If none of the people in charge of those places
> > want
> > to enable the flag, then maybe it should remain disabled.
> 
> If USE=cracklib is ever removed from base/make.defaults, then this IUSE
> default enabling should be done before it is removed for many of the
> places where it helps password safety, not afterwards when some
> maintainers happen to see you've done it some months later, after we

I would say that it is up to you to show where it was approved for
adding to base/make.defaults by showing where it was discussed on this
list, or showing where it was added in the profile revision history.

A bug and that has been open as long as he said it was earlier in this
thread,  as well as notification here with a 72 hour delay as well as
contacting the maintainers directly as far in advance as he did seems
reasonable to me.

I will look at this more when I get back to my home system, but on the
face of it, I would support his change.

> 
> If you need more opposing, then consider this one, as long as this
> preparation work isn't done. Just removing it because maintainers
> didn't get to it in your timeline isn't something I would see OK. If
> you want to make such a base profile change, then I believe you should
> contact the maintainers and see which one wants it default disabled,
> and which default enabled; do the default enabled changes and only
> afterwards you can touch a base default USE flag, otherwise you are
> making a change to all these maintainers packages without their
> consent. It IS an effective change to their package, and you are
> effectively doing non-maintainer changes to them.

As he said, he contactedd the maintainers in ample time, so I would say
that since they didn't respond he went ahead in good faith. I'll get the
link later, but as I recall, the dev manual recommends a 2-4 week wait
for maintainers not responding then we can assume that what we are doing
is ok.

I will look into this more when I get back to my home system, but as a
member of base-system, tentavely count me as supporting his change.

To respond to the comment about preparation work: 
Again, I haven't checked the bug, but if it has been there a while and
received no input from base-system etc, there may not be any, so
removing it from base/make.defaults would be the way to go.

William



signature.asc
Description: Digital signature

Re: [gentoo-dev] [PATCH 1/1] profiles: drop USE=cracklib from base/make.defaults.

[Michael Orlitzky]

On 12/27/2017 10:42 AM, Mart Raudsepp wrote:
> If you want to make such a base profile change, then I believe you
> should contact the maintainers and see which one wants it default
> disabled, and which default enabled; do the default enabled changes
> and only afterwards you can touch a base default USE flag

The bug is titled "base/make.defaults: unset USE=cracklib by default"
and it says,

  I'm CCing the maintainers of all affected packages. If anyone would
  like us to wait until they've set "+cracklib" in their ebuilds, please
  just file a blocker bug against this.

It's been two months, and all I asked for is a "hey, don't do it yet..."

Re: [gentoo-dev] [PATCH 1/1] profiles: drop USE=cracklib from base/make.defaults.

[Michael Orlitzky]

On 12/27/2017 05:49 AM, Jeroen Roovers wrote:
> OK, let me explain again.
> 
> In #gentoo we give a lot of attention and support to people who want to
> set up full disk encryption, tor, VPNs, and other security mechanisms,
> and this tells me that they actually want security. By saying that "some
> people [might] want it enabled" you ignore one of the main reasons why
> people turn to Gentoo Linux in the first place.
> 
> Having it enabled by default prompts new users and veteran users alike
> to think about password safety, because this means that you get
> reminded of possibly bad passwords *during* installation/while setting
> up your services.

Enable it if you want, but base/make.defaults is the wrong place.


> People can always disable it easily when they feel they do not need it
> (any longer).

Not quite true due to the USE stacking order, as I mentioned on the bug.


>> If you disagree, please make your voice heard on the bug.
> 
> I already did that parallel to my response here. Note that *this* is
> the proper venue for discussing sweeping changes like this, and that a
> bug report that saw no input from anyone else for a couple of months
> is not.

That wasn't directed at you. It was directed at all of the other people
on this list, to avoid exactly this discussion that we're having. If
people voiced their opposition, I was happy to leave it alone. Even
after two threads and a bug, yours was the only sure "no." I think I
convinced floppym that base/make.defaults was the wrong place for it.
And keep in mind that I only asked for responses from people who disagree.


> You already went ahead and committed that change without proper
> discussion and waving away the input you did get suggesting you should
> drop it, so I have now reverted it. Next time, please discuss your
> problems with sane defaults like these before doing anything rash.

There have been two mailing list threads. The first was two months ago,

https://archives.gentoo.org/gentoo-dev/message/8ddc678a05cb6d3b93adfc5a54d6312c

and then there's this one, in which I tried to rally people to your
cause (to no avail). Not to mention the bug itself, where I CC'ed every
affected maintainer.


> As quoted from the bug report, please address these:
> 1) Why you think having USE=cracklib enabled by default is a *problem*
> which needs to be addressed by way of its removal. My original response
> questioned that, but you didn't actually answer it.

I never said that having it enabled by default is a problem. I said that
having it enabled in the base profile is a problem, and semantically
incorrect, as evidenced by the fact that at least one profile has to
unset it. Then there's the stacking issue again, which makes it awkward
to disable if the base profile enables it.


> 2) What you plan to do to have USE=cracklib enabled by default. Two
> people suggested you should keep this (one way or another) but instead
> everyone is now without it enabled by default.

I plan to do nothing, because I think it should be disabled by default
like all other USE flags. I've CC'ed all of the maintainers who might
want to add the default to IUSE, and apparently none of them do. The
hardened project and base-system are also CCed/assigned in case one of
them wanted to adopt the default.

The base profile is the wrong place to enable USE=cracklib, but there
are better places. If none of the people in charge of those places want
to enable the flag, then maybe it should remain disabled.


> 3) This bug report sat there for two months without notice to
> gentoo-dev@ (and largely immaterial, without even a response from the
> teams you CC'd). There was no proper discussion about a change that
> affects not just developers, but all users, and hardly anyone knew
> about it until you posted your patch.

Two separate threads and a bug CC'ed to everyone affected. What else did
you want me to do?

[gentoo-dev] Lastrites: dev-java/jikes, net-misc/netkit-rusers, net-print/xerox-drivers, dev-dotnet/gnome-sharp...

[Pacho Ramos]

# Pacho Ramos  (27 Dec 2017)
# Dead for ages, not needed, for java 1.5 (#638036). Removal in a month.
dev-java/jikes

# Pacho Ramos  (27 Dec 2017)
# Dead for ages, requires glibc with rpc (#371391). Removal in a month.
net-misc/netkit-rusers

# Pacho Ramos  (27 Dec 2017)
# Out ebuild is completely obsolete (#381073), download manually PPD is
# preferred, current tarballs cannot be downloaded even (#635146). Removal
# in a month.
net-print/xerox-drivers

# Pacho Ramos  (27 Dec 2017)
# Dead and broken for a long time (#427876), nothing requires this. Removal
# in a month.
dev-dotnet/gnome-sharp

# Pacho Ramos  (27 Dec 2017)
# Dead and broken for a long time (#428354, #562772, #624956, #558120,
# #585222, #585548, #605706, #612368), nothing requires this. Removal
# in a month.
# Mikhail Pukhlikov  (20 Jul 2017)
# Old mono/dotnet packages (used on GNOME2 stack)
# also some deprecated forks used for monodevelop
# awhile they are very unstable they will live in dotnet overlay
gnome-extra/docky
dev-dotnet/gnome-desktop-sharp
dev-dotnet/gtksourceview-sharp
dev-dotnet/rsvg-sharp
dev-dotnet/vte-sharp
dev-dotnet/wnck-sharp
dev-dotnet/xdt-for-monodevelop
dev-dotnet/nuget
dev-dotnet/referenceassemblies-pcl

# Pacho Ramos  (27 Dec 2017)
# Dead for ages, rely on deprecated/dead libs (#447466). Removal in a month.
dev-vcs/bzr-gtk
dev-vcs/bzr-explorer

# Pacho Ramos  (27 Dec 2017)
# Completely broken for years (#514400, #596078, #598609, #640096, #641428).
# Removal in a month.
dev-cpp/pficommon

# Pacho Ramos  (27 Dec 2017)
# Dead for a long time, failing tests (#526900), nothing requires it.
# Removal in a month.
net-misc/ytalk

# Pacho Ramos  (27 Dec 2017)
# Upstream dead, SRC_URI dead, nothing requires it (#533812). Removal in a
# month.
media-video/replex

# Pacho Ramos  (27 Dec 2017)
# Not compatible with mono-4 (#557588, #562546, #569252, #581920, #585860,
#596652),
# nothing requires them. Removal in a month.
dev-dotnet/xsp
dev-dotnet/nini
dev-lang/mono-basic
dev-util/jay

# Pacho Ramos  (27 Dec 2017)
# python files installed in wrong path (#580328), relies on qt4 and cannot
# be bumped (#585328), fails with gcc6 (#630332), fails to build (#641514).
# Removal in a month.
sci-visualization/qtiplot

# Pacho Ramos  (27 Dec 2017)
# Dead upstream for a long time, relies on dead gnome-icon-theme and has
# some crashes (#602144). Removal in a month.
app-doc/podbrowser

# Pacho Ramos  (27 Dec 2017)
# Dead upstream for a long time, relies on dead gnome-icon-theme and nothing
# requires it (#602146). Removal in a month.
games-emulation/gxmame

# Pacho Ramos  (27 Dec 2017)
# All Ekiga set is dead and broken for years, it relies on obsolete
# dead/libs that are also old and broken and upstream looks to not release
# newer ekiga ever. To keep this please go ahead and take care of it *and
# all the dependencies it also needs*. See bugs #626176, #460458, #589276,
# #638122, #641990, #633670, #624578, #600398, #627868.
# Removal in a month.
net-libs/ptlib
net-libs/opal
net-voip/openmcu
net-voip/ekiga

[gentoo-dev] Lastrites: compiz and related packages

[Pacho Ramos]

# Pacho Ramos  (27 Dec 2017)
# Remove all Compiz related packages: they all need major work/bumps to fix
# lots of pending issues and they need a dedicated maintainer (bug #339622
# and many others). Removal in a month.
x11-wm/compiz
x11-apps/fusion-icon
x11-libs/compizconfig-backend-gconf
x11-libs/libcompizconfig
dev-python/compizconfig-python
x11-misc/ccsm
x11-misc/simple-ccsm
x11-plugins/compiz-plugins-extra
x11-plugins/compiz-plugins-main
x11-plugins/compiz-plugins-unsupported
x11-wm/compiz-fusion
x11-wm/emerald
x11-themes/emerald-themes
x11-libs/compiz-bcop

Re: [gentoo-dev] [PATCH 1/1] profiles: drop USE=cracklib from base/make.defaults.

[Jeroen Roovers]

On Fri, 22 Dec 2017 12:30:35 -0500
Michael Orlitzky  wrote:

> On 12/21/2017 02:27 PM, Jeroen Roovers wrote:
> > On Thu, 21 Dec 2017 10:10:30 -0500
> > Michael Orlitzky  wrote:
> >   
> >> The "cracklib" USE flag ... this commit removes it from
> >> base/make.defaults.
> >>
> >> Closes: https://bugs.gentoo.org/635698  
> > 
> > As there:  
> >> ...  
> > 
> > Let me (easily) counter that by stating that having cracklib in
> > place makes people pick better passwords. Especially the brand new
> > Linux users we see so many of might benefit from a default
> > mechanism that helps them make better security choices, but I am
> > sure even advanced users and systems administrators might set a
> > "temporary" POC password "quickly" and then later see their systems
> > go into production without a second thought about using stronger
> > passwords.

> I don't think that "some people want it enabled" is enough
> justification to keep this in the base profile that is the parent of
> all others.

OK, let me explain again.

In #gentoo we give a lot of attention and support to people who want to
set up full disk encryption, tor, VPNs, and other security mechanisms,
and this tells me that they actually want security. By saying that "some
people [might] want it enabled" you ignore one of the main reasons why
people turn to Gentoo Linux in the first place.

Having it enabled by default prompts new users and veteran users alike
to think about password safety, because this means that you get
reminded of possibly bad passwords *during* installation/while setting
up your services.

People can always disable it easily when they feel they do not need it
(any longer).

> If you disagree, please make your voice heard on the bug.

I already did that parallel to my response here. Note that *this* is
the proper venue for discussing sweeping changes like this, and that a
bug report that saw no input from anyone else for a couple of months
is not.

You already went ahead and committed that change without proper
discussion and waving away the input you did get suggesting you should
drop it, so I have now reverted it. Next time, please discuss your
problems with sane defaults like these before doing anything rash.

As quoted from the bug report, please address these:
1) Why you think having USE=cracklib enabled by default is a *problem*
which needs to be addressed by way of its removal. My original response
questioned that, but you didn't actually answer it.

2) What you plan to do to have USE=cracklib enabled by default. Two
people suggested you should keep this (one way or another) but instead
everyone is now without it enabled by default.

3) This bug report sat there for two months without notice to
gentoo-dev@ (and largely immaterial, without even a response from the
teams you CC'd). There was no proper discussion about a change that
affects not just developers, but all users, and hardly anyone knew
about it until you posted your patch.


Kind regards,
 jer

Re: [gentoo-dev] [PATCH 1/1] profiles: drop USE=cracklib from base/make.defaults.

[R0b0t1]

On Wed, Dec 27, 2017 at 10:32 AM, William Hubbs  wrote:
> As he said, he contactedd the maintainers in ample time, so I would say
> that since they didn't respond he went ahead in good faith. I'll get the
> link later, but as I recall, the dev manual recommends a 2-4 week wait
> for maintainers not responding then we can assume that what we are doing
> is ok.

This assumes there is some pressing need for the change to take place,
which I am not sure there is. I can understand wanting to make the
change for consistency's sake, but the feature is important enough
that I think a suitable replacement should explicitly be found before
continuing. E.g. affirmative feedback from all affected packages.

Enforcement of rules or Gentoo development guidelines does not happen
consistently, and the times when rules are enforced "for consistency's
sake" seem completely arbitrary. There seems to be no extant problems
caused by the flag as set, so why focus on this specifically?

There is a lot of discussion of not burdening developers with
pointless talk or changes. If that is a goal, then why is this posting
receiving so many replies?

Respectfully,
 R0b0t1

OT: Re: [gentoo-dev] [PATCH 1/1] profiles: drop USE=cracklib from base/make.defaults.

[Nils Freydank]

Am Mittwoch, 27. Dezember 2017, 22:33:03 CET schrieb R0b0t1:
> On Wed, Dec 27, 2017 at 10:32 AM, William Hubbs  wrote:
> > As he said, he contactedd the maintainers in ample time, so I would say
> > that since they didn't respond he went ahead in good faith. I'll get the
> > link later, but as I recall, the dev manual recommends a 2-4 week wait
> > for maintainers not responding then we can assume that what we are doing
> > is ok.
> 
> This assumes there is some pressing need for the change to take place,
> which I am not sure there is. I can understand wanting to make the
> change for consistency's sake, but the feature is important enough
> that I think a suitable replacement should explicitly be found before
> continuing. E.g. affirmative feedback from all affected packages.

Often a fix timeline is the only way to achieve any responses - or at least
get stuff done, even if the matter itself is not urgent at all. In this 
specific case the points Michael had were quite clear, and the timespan of
two month was long enough to react somehow (at least in the context of typical
periods in Gentoo, e.g. last rite/removal period of 30 days).

On topic: There are some users including myself that find cracklib mostly 
annoying. I use strong passwords (or ssh keys only) where I can, and cracklib 
annoys me with the request to set "secure passwords" for a container 
playground, where I want root:test as login credentials.
Beside that the point that profiles in general should contain as least USE as 
possible (see the bug report for that).

> Enforcement of rules or Gentoo development guidelines does not happen
> consistently, and the times when rules are enforced "for consistency's
> sake" seem completely arbitrary. There seems to be no extant problems
> caused by the flag as set, so why focus on this specifically?

To me these times look as they're based upon agreement between the involved 
parties, and in itself consistently, e.g. at least 30 days masking before
removal out of the tree, or in this case at least two to four weeks to let 
others respond.

> There is a lot of discussion of not burdening developers with
> pointless talk or changes. If that is a goal, then why is this posting
> receiving so many replies?

With all due respect, your posting didn't bring any new relevant aspects into 
this thread on this mailing list with the explicit focus and topic of Gentoo 
development, and might be exactly part of the "pointless talk" you mention.

My one isn't better; I just want to point that out to you, because you tend to
write messages with this kind of meta questions about the cause of things.

If you want to discuss this, I'd prefer another place than this list.

Regards,
Nils

-- 
GPG fingerprint: '00EF D31F 1B60 D5DB ADB8 31C1 C0EC E696 0E54 475B'
Nils Freydank

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Re: RFC: News: systemd sysv-utils blocker resolution

[Robin H. Johnson]

On Wed, Dec 27, 2017 at 05:18:11PM +0100, Francesco Riosa wrote:
> 
> 
> On 12/27/17 16:47, Mike Gilbert wrote:
> > On Tue, Dec 26, 2017 at 7:18 PM, Robin H. Johnson  
> > wrote:
> >> On Tue, Dec 26, 2017 at 11:22:50PM +0100, Jason A. Donenfeld wrote:
> >>> You might want to mention that alternatively, uninstalling
> >>> openrc on a systemd profile system is fine to do
> >>> these days, despite the warning.
> >> If you're using netifrc's systemd support, this would break your
> >> networking ;-).
> > I guess the winky face means you are not serious, but I'll respond anyway. 
> > :-)
> >
> > I suspect the number of people using systemd with netifrc is in the
> > single digits. I would rather not clutter the news item to account for
> > this scenario.
It was a GSOC project, but since then I hadn't heard of any users of it,
other than the GSOC student, and haven't had any bug reports of it being
broken.

I'm happy to hear it has at least one other user in Francesco.

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Asst. Treasurer
E-Mail   : robb...@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136


signature.asc
Description: Digital signature

Re: OT: Re: [gentoo-dev] [PATCH 1/1] profiles: drop USE=cracklib from base/make.defaults.

[R0b0t1]

On Wed, Dec 27, 2017 at 4:16 PM, Nils Freydank  wrote:
> Am Mittwoch, 27. Dezember 2017, 22:33:03 CET schrieb R0b0t1:
>> On Wed, Dec 27, 2017 at 10:32 AM, William Hubbs  wrote:
>> > As he said, he contactedd the maintainers in ample time, so I would say
>> > that since they didn't respond he went ahead in good faith. I'll get the
>> > link later, but as I recall, the dev manual recommends a 2-4 week wait
>> > for maintainers not responding then we can assume that what we are doing
>> > is ok.
>>
>> This assumes there is some pressing need for the change to take place,
>> which I am not sure there is. I can understand wanting to make the
>> change for consistency's sake, but the feature is important enough
>> that I think a suitable replacement should explicitly be found before
>> continuing. E.g. affirmative feedback from all affected packages.
>
> Often a fix timeline is the only way to achieve any responses - or at least
> get stuff done, even if the matter itself is not urgent at all. In this
> specific case the points Michael had were quite clear, and the timespan of
> two month was long enough to react somehow (at least in the context of typical
> periods in Gentoo, e.g. last rite/removal period of 30 days).
>

Yes, but as per past comments it seems some people think the action
taken was slightly inappropriate. It feels like you didn't read what I
said: in some cases, a fix timeline may not be appropriate. I don't
know when that is.

> On topic: There are some users including myself that find cracklib mostly
> annoying. I use strong passwords (or ssh keys only) where I can, and cracklib
> annoys me with the request to set "secure passwords" for a container
> playground, where I want root:test as login credentials.
> Beside that the point that profiles in general should contain as least USE as
> possible (see the bug report for that).
>

I must be confused, because this is the only part of your message that
is offtopic.

>> Enforcement of rules or Gentoo development guidelines does not happen
>> consistently, and the times when rules are enforced "for consistency's
>> sake" seem completely arbitrary. There seems to be no extant problems
>> caused by the flag as set, so why focus on this specifically?
>
> To me these times look as they're based upon agreement between the involved
> parties, and in itself consistently, e.g. at least 30 days masking before
> removal out of the tree, or in this case at least two to four weeks to let
> others respond.
>

But why male models^H^H^H^H^H^H^H^H^H^H^Hfocus on this issue in
particular? If I understand the situation, nothing is actually
*broken.* That is why I was questioning consistency.

>> There is a lot of discussion of not burdening developers with
>> pointless talk or changes. If that is a goal, then why is this posting
>> receiving so many replies?
>
> With all due respect, your posting didn't bring any new relevant aspects into
> this thread on this mailing list with the explicit focus and topic of Gentoo
> development, and might be exactly part of the "pointless talk" you mention.
>
> My one isn't better; I just want to point that out to you, because you tend to
> write messages with this kind of meta questions about the cause of things.
>
> If you want to discuss this, I'd prefer another place than this list.
>

As someone watching from the outside I see this type of discussion
crop up from time to time. All I am suggesting is thinking about
actions before they are acted out. This isn't to say what was
undertaken was not thought out - but the patterns of behavior I see
that that decision exists within are what I am suggesting needs more
careful consideration.

If you can not see the utility in thinking about thinking, I am not
sure we would have much to talk about.

Respectfully,
 R0b0t1

[gentoo-dev] Last rites: app-doc/linux-gazette

[Jonas Stein]

profiles: Last rite app-doc/linux-gazette

Upstream deleted all files more than 6 years ago and is inactive.
Masked for removal on 2018-02-01
app-doc/linux-gazette-base
app-doc/linux-gazette-all
app-doc/linux-gazette

Bug: https://bugs.gentoo.org/628960

--
Best regards,
Jonas Stein





signature.asc
Description: OpenPGP digital signature