Re: [arch-dev-public] Bringing Multipath TCP kernel (linux-mptcp) to [community]

[Levente Polyak]

On June 11, 2017 12:47:07 AM GMT+02:00, Baptiste Jonglez 
 wrote:
>At that point, Multipath TCP is mostly useful to researchers and
>tinkerers, because both ends of a TCP connection need to run the
>modified
>kernel (otherwise, it just falls back to regular TCP).
>
>However, I still think it would be useful in [community]:
>
>1) One nice use-case is link aggregation, where you basically tunnel
> traffic over a Multipath TCP connection.  You may want to build such a
>   tunnelling system with Arch.
>


That there may be useful things provided by multipath per say is out of 
question, it's more how useful it is to package yet another kernel into the 
repository. It's very much an edge case variant at this point (as you pointed 
out yourself).


>2) Not everybody has the resources to build a kernel (time, CPU,
>memory, disk...)
>


If you're a researcher or thinker you will somehow manage to compile a kernel 
from the AUR and the resources to do so are not really that high. 


>So, I would say the project is active and focused on the long term.
>There have been minor releases in-between these major releases, to
>integrate bugfixes and update to latest stable kernel.  For instance,
>v0.91.2 was based on linux 4.1.35.
>


Which is quite ancient actually. Also the mentioned support includes handling 
of vulnerabilities by our security team. Each kernel, especially when not in 
sync with neither LTS nor the default, creates overhead when handling and 
researching patches and vulnerabilities as they are part of the official 
repositories. 
This can get pretty cumbersome and personally I don't quite see the 
justification fur the additional burden it creates.
My humble opinion is that multipath sounds nice but belongs into the AUR rather 
then into our repository.


Cheers, 
Levente 

Re: [arch-dev-public] libalpm hook and wrapper for detecting broken perl modules

[Allan McRae]

On 11/06/17 08:03, Florian Pritz via arch-dev-public wrote:
> One possibility to counter this would be to replace the perl executable
> with a wrapper that performs the check and prints errors to stderr.
> Optionally it could also exit with an error code rather than continuing
> to run the script. I'm not sure if I want this or not, but I'm leaning
> towards a yes since exiting will make the error more difficult to miss.

I am very against this part (hook is completely fine).   Having the perl
executable be something other than upstream (and every other distro)
provides, is not what Arch is about.

I'm assuming the new location would be transparent to packagers (i.e.
they would not need to alter their PKGBUILDs)?

A

Re: [arch-dev-public] Bringing Multipath TCP kernel (linux-mptcp) to [community]

[Baptiste Jonglez]

Hi Gaetan,

On Wed, Jun 07, 2017 at 08:55:15AM -1000, Gaetan Bisson wrote:
> [2017-06-06 22:58:01 +0200] Baptiste Jonglez:
> > Since a few years, I maintain a variant of the linux kernel in the AUR [1]
> > that adds support for Multipath TCP [2].  The most recent version is based
> > on linux 4.4, and the package I maintain tries to follow the "linux"
> > package from [core] as much as possible.
> > 
> > There is no short- or medium-term perspective to merge Multipath TCP
> > upstream, so I would like to bring this package to [community].  There are
> > already several kernel variants in the official repos, but I would like to
> > get some feedback before adding another one.
> 
> We already have an official linux package in [core] which is very well
> maintained and works great for 99% of our users, so I'd really like if
> you tried to explain why we need another variant and why the AUR is not
> suitable for it anymore.

At that point, Multipath TCP is mostly useful to researchers and
tinkerers, because both ends of a TCP connection need to run the modified
kernel (otherwise, it just falls back to regular TCP).

However, I still think it would be useful in [community]:

1) One nice use-case is link aggregation, where you basically tunnel
   traffic over a Multipath TCP connection.  You may want to build such a
   tunnelling system with Arch.

2) Not everybody has the resources to build a kernel (time, CPU, memory, 
disk...)

3) It is good to have kernel diversity in our repositories.  For instance,
   I had a laptop that couldn't go to sleep with the kernels from [core]
   (either linux or linux-lts), but it worked with linux-mptcp.  This is
   really not the main goal of having linux-mptcp in [community], but it's
   a nice side-effect.

By the way, the kernel is completely stable, I have been using it on a
daily basis (on my laptop) since a few years.  At the beginning of the
project in ~2014, there were occasional kernel panics, but not anymore.

> As you're aware, we've had another package (linux-grsec) with a user
> base certainly much larger than linux-multipath come and go because
> upstream went another direction and nobody had the resources to fork it.
> I'd really like our packages to enjoy some level of support and not just
> go to [community] "because they can" and get dropped just as fast. What
> could you tell us about linux-multipath on that front?

When talking about "some level of support", do you mean whether the
upstream project is active?

The project has one main developer, 2 to 3 additional developers, and
several small contributors (including myself).  I think nobody is working
full-time on it, though.

Regarding activity, major releases happen when the project is rebased on a
more recent kernel version and sufficiently tested:

- v0.86 released 2013-03-07, based on linux 3.5
- v0.87 released 2013-07-25, based on linux 3.10
- v0.88 released 2013-10-30, based on linux 3.11
- v0.89 released 2014-10-12, based on linux 3.14
- v0.90 released 2015-09-02, based on linux 3.18
- v0.91 released 2016-06-21, based on linux 4.1
- v0.92 released 2017-06-04, based on linux 4.4

So, I would say the project is active and focused on the long term.
There have been minor releases in-between these major releases, to
integrate bugfixes and update to latest stable kernel.  For instance,
v0.91.2 was based on linux 4.1.35.

Baptiste


signature.asc
Description: PGP signature

Re: [arch-dev-public] wxgtk split

[Antonio Rojas]

El Wed, 07 Jun 2017 19:37:44 +, Antonio Rojas escribió:

> 
>  If you maintain a wx-based package, you may want to try switching to
> build against wxgtk3, which offers some additional features (hipdi,
> smooth scrolling, touchscreen support).

Packages using wx-webview (boinc, moneymanagerex and perhaps some other 
via wxpython) should get high priority for porting. Besides gnucash, these 
are the only packages left using the insecure webkitgtk.