Re: [arch-dev-public] Killing Python 2 (v2)

[keenerd via arch-dev-public]

On 1/2/20, Jelle van der Waa  wrote:
> * rox - python2, dead and GTK2

Also was an easy fix.  Well, the python2 part at least.

-Kyle

Re: [arch-dev-public] Killing Python 2 (v2)

[keenerd via arch-dev-public]

On 1/2/20, Jelle van der Waa  wrote:
> * armagetronad - dead upstream, optional dep can be removed

Fixed instead.  It still works a treat.

-Kyle

Re: [arch-dev-public] Phasing out webkitgtk{,2}

[keenerd via arch-dev-public]

As the maintainer of one of those browsers, I'll also be prodding
upstream about the issue if it can't easily be updated.  The last time
this came up (Dec 2015), Xombrero's author said

> We briefly looked at the 2.x stuff but that would basically be a rewrite and 
> even more unfortunate is that not all required hooks to make a “secure” 
> browser are available.

He's an OpenBSD dev too, so it isn't like people have to explain the
usefulness of security to him.  We'll see how it goes.

Contacting upstream (either with patches or "hey, we are going to have
to remove your software from our repos") should be a fourth step on
the policy.

-Kyle
http://kmkeen.com

[arch-dev-public] Bringing Bugday Back

[keenerd via arch-dev-public]

Years ago we had monthly Bug Days.  They were on the second Saturday
of every month, for the global duration of Saturday.  (So 48 hours
thanks to time zones.)

The original Bug Days petered out for a couple of reasons, primarily
because it focused on developer activity instead of community
activity.  I'd like to bring back the monthly Bug Day, but this time
with an entirely community focus.

The basic plan would be to improve the lower-quality bugs in the
tracker.  This mostly involves going through a checklist and fleshing
out where the bug is lacking:

* Was the bug fixed in a new version?
* Is the bug reported upstream?
* Is the bug reproducible?
* Is there a minimum test case?
* Is the bug a regression?
* If so, was it bisected to a version or commit?
* Has another distro already patched around it?

And probably more that escape me.  But there is a lot someone can do
without having a thorough understanding of the code base.  (Obviously
if you do have that understanding, try to write patches.)

Simultaneously, I'd like to extend Bug Day to also cover other
Arch-related "bugs" that aren't on the tracker.  If someone has a
question about improving the accuracy of a wiki article or fixing up a
broken AUR pkgbuild, then Bug Day is a reminder for them to ask a TU
about it.  These are of course all activities that our most diligent
volunteers do every day without prompting.  I'd like to see Bug Days
as a means to help more people become better volunteers.

Previous Bug Days were developer focused, and we needed to have two
developers who could commit to the weekend before Bug Day would go
forward.  We should waive that requirement.  Improving bug reports and
pkgbuilds does not necessarily need devs or TUs at all.  However
without that dev quorum, Bug Days probably shouldn't be announced in
the Arch News.  I don't see that as a problem because much of the
active community follows the BBS or IRC.  Our resident bug wrangler,
Doug Newgard (Scimmia), agrees with the devs-optional sentiment and is
looking forward to the re-opening of Bug Days.

Personally I'll be working on Namcap bugs, or porting Python2 holdouts
to Python3.

Thoughts or criticisms?

-Kyle
http://kmkeen.com

Re: [arch-dev-public] Discussion about optional dependencies

[keenerd via arch-dev-public]

On 7/19/16, Antonio Rojas  wrote:
> In theory: +1
>
> But splitting VLC properly is a non-trivial task.

I've had a very similar problem for several years with the Gnuradio
package.  It can either be run headless (which is usually how it is
used in production) but it also has a graphical "flow language" IDE
that is used during design.  The IDE required around six optdeps.
Some were required for the IDE to even start, some parts were
optional-optional.  Some were kind of confusing, since it could use
either WX or QT.

And like VLC, there was no upstream provision for actually splitting
the headless and GUI parts.  Gnuradio is about the same size project
as VLC too.

(The GUI optdeps would add about 600MB to a headless system.  For
"appliance" installs that run from an SD card, this is not a trivial
waste.)

The cleanest workaround was to make a fake kitchen sink package.  It
has no files but depends on all the optdeps.  If I think the IDE needs
a new depend, I add it to the kitchen sink and users get it
automatically next update.  If you want to make a streamlined install,
you don't install the kitchen sink and just the optdeps you need.  If
the dangling packages are a bother for a nice clean dep tree, then it
is easy (and doesn't require rebuilding anything) to make a custom
fake pacakge to establish the dependency links.

Pros get full control over the system by ignoring the fake package.
Newbs get a zero maintainence just-works experience.  I don't have to
cut against upstream by trying to split the unsplitable.  Pretty much
everyone is happy and it has all but eliminated routine
bugs/complaints/confusion.

-Kyle