[gentoo-dev] Re: The problem of unmaintained packages in Gentoo

[Duncan]

Kent Fredric posted on Sat, 23 Dec 2017 10:25:51 +1300 as excerpted:

> On Thu, 21 Dec 2017 12:25:11 -0600 William Hubbs 
> wrote:
> 
>> I think there's some confusion here. I'm not trying to change the bar
>> for ~arch, just trying to understand what that bar is supposed to be.
> 
> The bar for ~arch is "end users should have reasonable expectations that
> it mostly works for most purposes, especially those that can be
> trivially checked for by its maintainer"
> 
> ~arch will however be imperfect, and there will be issues from time to
> time.
> 
> However, the goal is that those issues are not the "easy to find and
> obvious" kind, but the subtle and hard to stumble into.
> 
> And I see that as why we have the time interval: Because it gives a good
> opportunity for actual real world usage patterns to discover the sorts
> of problems that you can't discover by actively looking for them,
> the rumsfeldian "unknown unknowns".
> 
> Because realistically speaking, ~arch is the stable of tomorrow.
> 
> The goal is for it to be stable today.
> 
> And when it proves itself ready to be the stable of today, it becomes
> the stable of today.

Very well said. =:^)

I'd simply add a couple points, from a slightly different angle.  They're 
arguably obvious (at least to devs), but equally arguably should be 
explicitly stated to avoid doubt, and certainly clarified things for me 
back in 2004 when I was a new gentooer trying to figure all this stuff 
out.

* Because ~arch is intended to be (as the above says) "the stable of 
tomorrow", with few exceptions it should consist of packages upstream 
already considers stable releases.  As such, the "testing" implied by 
~arch is /Gentoo's/ testing, that is, testing of the ebuild and how it 
interacts with eclasses, profiles and the rest of the Gentoo tree in 
general, /not/ upstream testing.

* The primary exception to the the general rule above is for packages 
where Gentoo /is/ upstream, such that the most obvious method of testing 
the stability of the release (by Gentoo devs functioning as upstream) is 
by releasing it to ~arch, which in this case /is/ upstream's testing.

That isn't to say that where Gentoo is upstream ~arch should be alpha 
quality; the same "obvious bugs should have already been fixed" applies.  
It simply means the quality of ~arch for Gentoo-as-upstream packages may 
be experientially somewhat different, perhaps a bit lower, because in 
that case ~arch is functioning as upstream's testing as well as testing 
of the Gentoo packaging.

This is actually a big reason why I ended up running live-git openrc back 
when I was running it.  Gentoo effectively being upstream and ~arch thus 
being upstream testing, there were occasional breakages with ~arch openrc 
packages, and as a normal ~arch user I found it far easier to trace them 
down when I had full access to the git logs and commit history, as well 
as a finer grain "multiple pre-release snapshots (effectively a snapshot 
each time I upstated), less territory to bisect" testing strategy.

For portage, by contrast, I didn't end up running live-git, because each 
release lists the bugs fixed and I can and do at least review their one-
line summaries every time I update.  Between that and following the 
patches as they're posted for review in portage-dev (so the release-time 
bug list is primarily review), I'm effectively following live-git plus 
reviews anyway, but with the releases as my chosen snapshot frequency.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] [PATCH] meson.eclass: add meson_use function

[Mart Raudsepp]

On L, 2017-12-16 at 18:29 +0100, Jan Chren (rindeal) wrote:
> On 15 December 2017 at 17:38, Mike Gilbert 
> wrote:
> > ---
> >  eclass/meson.eclass | 13 +
> >  1 file changed, 13 insertions(+)
> > 
> > diff --git a/eclass/meson.eclass b/eclass/meson.eclass
> > index 2c943dd6ae27..71735fbfc67d 100644
> > --- a/eclass/meson.eclass
> > +++ b/eclass/meson.eclass
> > @@ -137,6 +137,19 @@ _meson_create_cross_file() {
> > EOF
> >  }
> > 
> > +# @FUNCTION: meson_use
> > +# @USAGE:  [option name]
> > +# @DESCRIPTION:
> > +# Given a USE flag and meson project option, outputs a string
> > like:
> > +#
> > +#   -Doption=true
> > +#   -Doption=false
> > +#
> > +# If the project option is unspecified, it defaults to the USE
> > flag.
> > +meson_use() {
> > +   usex "$1" "-D${2-$1}=true" "-D${2-$1}=false"
> > +}
> > +
> >  # @FUNCTION: meson_src_configure
> >  # @DESCRIPTION:
> >  # This is the meson_src_configure function.
> > --
> > 2.15.1

Looks good to me.
If we ever find any reason to support non-boolean options, we can
figure out a third/fourth argument for it, or new function, or just
using usex or whatnot in the ebuilds. Unless we want to have this
boolean one named as meson_bool or whatnot. But this is the most common
one, so in line with others as "meson_use" sounds best to me.

> Isn't this the beginning of this wheel
> https://github.com/gentoo/gentoo/commit/e9116b1aebc819a10410960cbb493
> 1aa5e399af1
> ?

Unlike in cmake, where the define key and USE flag name practically
never line up, with meson they most often do, and there will be no
capitalization tries and whatnot that the cmake stuff did.

[gentoo-dev] Willikins IRC bot offline due hardware fault

[Robin H. Johnson]

Hi all,

For anybody that depends on the IRC bot, willikins, it's temporarily
offline as of 2017/12/22 15:55 UTC due to a hardware fault in the
hosting server.

No ETA on it being back online, it's very close to Christmas. Waiting to
hear back still on a ticket filed ~4 hours ago (hopefully somebody looks
at the tickets before the 26th!).

(my personal IRC also normally runs on that server, so better to reach
me via email for now, as I'm not sure of the connection stability of my
IRC alternate host)

-- 
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: [gentoo-dev] The problem of unmaintained packages in Gentoo

[Kent Fredric]

On Thu, 21 Dec 2017 12:25:11 -0600
William Hubbs  wrote:

> I think there's some confusion here. I'm not trying to change the bar
> for ~arch, just trying to understand what that bar is supposed to be.

The bar for ~arch is "end users should have reasonable expectations
that it mostly works for most purposes, especially those that can be
trivially checked for by its maintainer"

~arch will however be imperfect, and there will be issues from time to time.

However, the goal is that those issues are not the "easy to find and
obvious" kind, but the subtle and hard to stumble into.

And I see that as why we have the time interval: Because it gives a
good opportunity for actual real world usage patterns to discover the
sorts of problems that you can't discover by actively looking for them,
the rumsfeldian "unknown unknowns".

Because realistically speaking, ~arch is the stable of tomorrow.

The goal is for it to be stable today.

And when it proves itself ready to be the stable of today, it becomes
the stable of today.


pgpLBmGG4qGK7.pgp
Description: OpenPGP digital signature

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

[Michael Orlitzky]

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.
> 
> Please close that bug report.

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.

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

[gentoo-dev] Last rites: media-radio/tucnak2

[tomjbe]

# Thomas Beierlein  (22 Dec 2017)
# Development moved to another naming scheme.
# Use media-radio/tucnak instead.
# Masked for removal in 30 days.
media-radio/tucnak2

Re: [gentoo-dev] Re: [RFC] First (experimental) 17.1 profiles news item for review (v2)

[Mike Gilbert]

On Thu, Dec 21, 2017 at 11:28 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> Reading the bug (506276), it seems to me it's all about /supporting/
> symlink=no, discussing migration scripts to make it possible to migrate
> existing installations, etc, not /mandating/ it.
>
> I don't see anything suggesting that vapier, or anyone else for that
> matter, decided it was going to be the _only_ choice, just that it would
> eventually be _a_ choice.

On 2014-03-31, vapier changed the bug summary to "kill SYMLINK_LIB=yes
support". I'm not sure how else that could be interpreted.

[gentoo-dev] Last rites: sci-calculators/qalculator, x11-misc/basqet, x11-misc/okindd

[Michael Palimaka]

# Michael Palimaka  (22 Dec 2017)
# Dead upstream. Requires dead Qt 4.
# Masked for removal in 30 days.
sci-calculators/qalculator

# Michael Palimaka  (22 Dec 2017)
# Dead upstream. Requires dead Qt 4.
# Masked for removal in 30 days.
x11-misc/basqet

# Michael Palimaka  (22 Dec 2017)
# Dead upstream. Requires dead Qt 4.
# Masked for removal in 30 days.
x11-misc/okindd

[gentoo-dev] Last rites: x11-misc/qsynergy

[Michael Palimaka]

# Michael Palimaka  (22 Dec 2017)
# Dead upstream. Requires dead Qt 4.
# Masked for removal in 30 days.
x11-misc/qsynergy

[gentoo-dev] Last rites: app-editors/znotes

[Michael Palimaka]

# Michael Palimaka  (22 Dec 2017)
# Dead upstream. Requires dead Qt 4.
# Masked for removal in 30 days.
app-editors/znotes

Re: [gentoo-dev] Projects up for grabs: cron, m68k

[Patrice Clement]

Wednesday 20 Dec 2017 12:49:18, Anthony G. Basile wrote :
> On 12/20/17 12:07 PM, Anthony G. Basile wrote:
> > On 12/20/17 12:02 PM, Michał Górny wrote:
> >> Hello, everyone.
> >>
> >> Due to prolonged inactivity of Mike Frysinger (vapier), the following
> >> projects have had effectively no members for 6 months already:
> >>
> >> https://wiki.gentoo.org/wiki/Project:Cron
> >>
> >>   sys-process/anacron [m]
> >>   sys-process/at
> >>   sys-process/bcron
> >>   sys-process/cronbase
> >>   sys-process/cronie [m]
> >>   sys-process/dcron
> >>   sys-process/fcron [m]
> >>   sys-process/vixie-cron
> >>   virtual/cron
> >>
> >> https://wiki.gentoo.org/wiki/Project:M68k
> >>
> >>   sys-apps/zorroutils [m]
> >>   sys-fs/atari-fdisk
> >>
> >> The packages listed with '[m]' have other maintainers. The remaining
> >> packages are solely maintained by the listed projects.
> >>
> >> If you are interested in helping out with some of those packages, please
> >> consider joining the appropriate project and/or co-maintaining the
> >> individual packages.
> >>
> >> If the projects see no activity within the next month, I will disband
> >> them and move the appropriate packages to maintainer-needed.
> >>
> > 
> > Those are very important packages.  I use fcron and at and I can help
> > take care of those.  I should probably take a look a t cronbase and
> > virtual/cron too.
> > 
> 
> Okay a followup on my last email, I added myself to the project and will
> try to take care of all cron packages.
> 
> -- 
> Anthony G. Basile, Ph.D.
> Gentoo Linux Developer [Hardened]
> E-Mail: bluen...@gentoo.org
> GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
> GnuPG ID  : F52D4BBA
> 

Hi there

We use fcron a lot at ${work} so I've also added myself to the project in an
attempt to help out with fcron-related bugs.

Cheers

-- 
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org