Bug#921707: RFP: glowing-bear -- Web-based graphical interface for WeeChat

[Giovanni Mascellani]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

   Package name: glowing-bear
Version: 0.7.1
Upstream Author: Lorenz Hübschle-Schneider and others
URL: https://github.com/glowing-bear/glowing-bear
License: GPL-3
Description: Web-based graphical frontend for WeeChat
Glowing Bear is a web-based graphical frontend for the WeeChat IRC
client. It relies on WeeChat to do all the heavy lifting and then
provides some nice features on top of that, like embedding images,
videos, and other content.

Glowing Bear communicates with WeeChat using the (possibly encrypted)
relay protocol offered by WeeChat.

Glowing Bear is written in JavaScript and runs as an Electron application.


Thanks to will have some time to package it properly. I am unfortunately
not very experienced with JavaScript applications.

Giovanni.
-- 
Giovanni Mascellani 
Postdoc researcher - Université Libre de Bruxelles



signature.asc
Description: OpenPGP digital signature

Re: V8 depends from outdated and unmaintained libv8 with security issues

[Jérémy Lal]

cc-ing to -devel, because advices about libraries are scarce in javascript
land.

Le ven. 8 févr. 2019 à 11:48, Jérémy Lal  a écrit :

> Le ven. 8 févr. 2019 à 10:31, Jeroen Ooms  a écrit :
>
>> On Fri, Feb 8, 2019 at 9:44 AM Jérémy Lal  wrote:
>> >
>> >
>> >
>> > Le ven. 8 févr. 2019 à 07:36, Jeroen Ooms  a
>> écrit :
>> >>
>> >> For those following this discussion: there is now a version of
>> >> r-cran-v8 that uses libnode-dev in sid. Is there anything we need to
>> >> do to get r-cran-v8 back in buster?
>> >>
>> >
>> > Hi Jeroen,
>> >
>> > your work made me realize the debian nodejs source package might just
>> need
>> > to provide a libv8-dev package with headers in /usr/include/v8 and a
>> pkgconfig
>> > file that tell to use -lnode ?
>> > Would that be all ?
>>
>> That would be absolutely fantastic, yes.  Also a symlink from
>> libv8.so-> libnode.so woulde be handy, because libv8 doesn't use
>> pkg-config anywhere else so most bindings just test for linking with
>> -lv8.
>>
>
> Ok then no pkgconfig and a symlink instead.
> I suppose i need to ask a removal of libv8 from unstable (it's removed
> from testing) to
> be able to "take" libv8-dev. Or maybe declare a libv8-in-nodejs-dev
> package ?
> In any case i don't know if i should make a libv8-xx package (which would
> basically be
> symlinks to libnode).
> Any advice is welcome...
>

>

W związku ze zleceniem

[Agencja Interaktywna]

Dzień dobry, 

 reprezentuję firmę zajmującą się tworzeniem 
nowoczesnych *Stron i Sklepów WWW. 
*

 Z przyjemnością podeślę naszą aktualną 
propozycję w tym zakresie. 

 Jeśli mogę, proszę o e-mail zwrotny o treści 
"/*TAK"*/.

 -- 
 Pozdrawiam!

Re: Bug#877900: How to get 24-hour time on en_US.UTF-8 locale now?

[Wouter Verhelst]

On Thu, Feb 07, 2019 at 02:05:33PM +0100, Adam Borowski wrote:
> > LC_TIME="en_US.UTF-8"

If you don't want US time, don't set US time.

Instead, do something like:

LC_TIME=en_BE.UTF-8

which means "I want time in English, but using Belgian customs, not the
US ones".

You may have to custom edit that time definition, though. Alternatively,
set LC_TIME to en_GB.UTF-8 or whatever other pre-existing locale.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

SIMDebian: Debian Partial Fork with Radical ISA Baseline

[Mo Zhou]

Hi folks,

For most programs the "-march=native" option is not expected to bring any
significant performance improvement. However for some scientific applications
this proposition doesn't hold. When I was creating the tensorflow debian
package, I observed a significant performance gap between generic code and
kabylake (Intel 7XXX Series) code[1].

The significant improvement in performance basically stems from the Eigen
library (header only numerical linear algebra library). Here is a simple
example[2] for demonstrating the performance gap[3] between different ISA
baselines. (elapsed time is roughly measured with "perf stat ...")

Having seen such interesting results, I immediately created a Debian partial
fork named SIMDebian (SIMD + Debian)[0]. It makes great sense to some
applications due to the significant performance gain brought by SIMD code.
Currently this partial fork is still in the very early stage, and it needs

  * More experience about software that benefit a lot from SIMD code
(e.g. What package would potentially benefit from SIMD code?)
  * Suggestions and comments
(e.g. Is such a partial fork really useful and valuable?)
  * More people interested in this

SIMDebian is only a PARTIAL fork, which means that it only takes care of
packages that would obviously benefit from SIMD code, because no performance
gain is expected in terms of the majority of packages in the Debian archive.

Generally speaking, in order to bump the ISA baseline for a given package, one
could add the -march=xxx flag to {C,CXX,F}FLAGS by modifying debian/rules.
However SIMDebian employes a more economic approach to this end: forking
dpkg[5] and injecting -march=xxx flag to the system default flag list. With the
resulting dpkg package, most debian packages could be rebuilt with bumped ISA
baseline without any code modification.

I think Debian Science team is interested in this partial fork as well. In the
past there was a highly-related GSoC project[4] (In my fuzzy memory the topic
lead to the creation of the GSoC project was raised by me). However for some
reason (I forgot it) it didn't start.

This is the first time I try to fork Debian and apparently I have no experience
on running a fork. I need comments from especially the Debian Science Team.
Any response/pointer would be much appreciated!

P.S. SIMDebian has an alias: SIGILLbian (SIGILL + Debian).
---

[0] https://github.com/SIMDebian/SIMDebian

[1] https://github.com/SIMDebian/SIMDebian/blob/master/benchmarks/tensorflow.md

[2] ```c++
#include 
#include 
using namespace std;

#define N 4096
int main(void)
{
auto A = Eigen::MatrixXd::Random(N, N);
auto B = Eigen::MatrixXd::Random(N, N);
auto C = A * B;
//cout << A << endl << B << endl << C << endl;
(void) C(0,0);
return 0;
}
```

[3] ``` (command-line) (perf-stat-elapsed-time)
CPU: Intel I5-7440HQ

g++ a.cc -I/usr/include/eigen3 -O2 -march=skylake \
-DEIGEN_USE_MKL_ALL -I/usr/include/mkl -lmkl_rt
1.275162977 (seconds)

g++ a.cc -I/usr/include/eigen3 -O2 \
-DEIGEN_USE_MKL_ALL -I/usr/include/mkl -lmkl_rt
1.382608279

g++ a.cc -I/usr/include/eigen3 -O2 -march=skylake -fopenmp
1.460047514

g++ a.cc -I/usr/include/eigen3 -O3 -march=skylake -fopenmp
1.313478657

g++ a.cc -I/usr/include/eigen3 -O2 -march=haswell -fopenmp
1.334523068

g++ a.cc -I/usr/include/eigen3 -O2 -march=sandybridge -fopenmp
1.988947143

g++ a.cc -I/usr/include/eigen3 -O2 -march=nehalem -fopenmp
3.099827038

g++ a.cc -I/usr/include/eigen3 -O2 -march=x86-64 -fopenmp
3.106337852

However, please note that Eigen's fastest result is still much slower
than OpenBLAS, even if Eigen called MKL:

~ ❯❯❯ julia -e 'A = rand(Float64, 4096, 4096); A*A; @time A*A;'
  1.011168 seconds (6 allocations: 128.000 MiB, 2.69% gc time)

BLAS optimization is another story. Omitted here.
```

[4] https://wiki.debian.org/SummerOfCode2017/Projects/Benchmarking

[5] https://github.com/SIMDebian/dpkg
Currently this fork aims on "haswell" due to availability of AVX2.
Only minor modification on my patch is reqired to further bump the
baseline to e.g. icelake (AVX512).

Re: package management symlink

[rajudev]

Sören Reinecke writes:

> Dear Debian mailing list community,
>
> I am Sören alias Valor Naram and I founded the project "goeasyLinux". I will 
> help to make linux more user friendly.
>
> A short introduction to "goeasyLinux" can be found at 
> https://github.com/ValorNaram/goeasylinux/blob/master/README.md
>
> The specification I wrote in order to make a cross platform symlink to 
> package management systems: 
> https://github.com/ValorNaram/goeasylinux/blob/master/package%20management/package%20install.md

I appreciate your efforts and idea of having a common package management
system across all/most linux distributions. I took a look at your git
repository above. And I realized there are already a few package
managers which work similar to your idea.

Take a look at `pkcon`  provided by `packagekit-tools` in Debian.
It is also present in various other linux distributions, I have used it
on a few other distributions including Fedora, Gentoo and even on my
phone's Sailfish OS.

since pkcon does already what you are trying to achieve here, and is
also very matured in terms of functionality that it provides. You seem
to be just re-inventing the wheel. 

>
> With your help I want to make package installing/removing equal on all linux 
> systems without disturbing the diversity we have across linux distributions. 
> In order to do that we need just a symlink, no replacement of existing 
> software.
>
>
> Best wishes
>
> Sören alias Valor Naram

Fwd: Status of PHP support in stretch

[Jochen Spieker]

Hi,

I originally sent this to debian-user and did not receive any replies
there. I thought I should retry here and maybe get a (more or less)
official response.

Regards,
Jochen.

- Forwarded message from Jochen Spieker  -

I noticed that PHP 7.0 is unsupported by upstream since the beginning of
2019:

https://secure.php.net/supported-versions.php

The most recent PHP version in stretch is, as of now, 7.0.33-0+deb9u1.
As far as I can tell, this is (roughly) the same as upstream 7.0.33 and
not a relabeled later upstream version and it does not contain
significant backports from later upstream versions.

Do I need to assume that PHP 7.0 in Debian is now only
security-supported by Debian alone? Is any DD close enough to upstream
to be able to at least backport new fixes from 7.1 and later if
necessary?

I found https://deb.sury.org/ which appears to be run by a DD[1]. But I
noticed that this version of PHP pulls in a different version of openssl
which rang some alarm bells with me. I would very much prefer something
more official, e.g. backpors.debian.org.

So, what do you do with your stretch servers running PHP now? Pray for
good support in Debian, upgrade to 3rd party packages? Upgrade to buster
already?

Regards,
Jochen.

[1] FWIW, the PGP key used for the repository (AC0E47584A7A714D) is
signed by Ondřej Surý (0C99B70EF4FCBB07) which, in turn, is
signed by 184 keys fro debian-keyring. The WoT probably does not get
better than that.

- End forwarded message -

-- 
If I was a supermodel I would give all my cocaine to the socially
excluded.
[Agree]   [Disagree]
 


signature.asc
Description: PGP signature

Re: Status of PHP support in stretch

[Ondřej Surý]

I still don’t understand why everybody suddenly thinks PHP is special
in any way.  The packages will be treated same as any other Debian
package - the important security fixes will be backported.

Ondrej

> On 8 Feb 2019, at 22:06, Jochen Spieker  wrote:
> 
> Hi,
> 
> I originally sent this to debian-user and did not receive any replies
> there. I thought I should retry here and maybe get a (more or less)
> official response.
> 
> Regards,
> Jochen.
> 
> - Forwarded message from Jochen Spieker  -
> 
> I noticed that PHP 7.0 is unsupported by upstream since the beginning of
> 2019:
> 
> https://secure.php.net/supported-versions.php
> 
> The most recent PHP version in stretch is, as of now, 7.0.33-0+deb9u1.
> As far as I can tell, this is (roughly) the same as upstream 7.0.33 and
> not a relabeled later upstream version and it does not contain
> significant backports from later upstream versions.
> 
> Do I need to assume that PHP 7.0 in Debian is now only
> security-supported by Debian alone? Is any DD close enough to upstream
> to be able to at least backport new fixes from 7.1 and later if
> necessary?
> 
> I found https://deb.sury.org/ which appears to be run by a DD[1]. But I
> noticed that this version of PHP pulls in a different version of openssl
> which rang some alarm bells with me. I would very much prefer something
> more official, e.g. backpors.debian.org.
> 
> So, what do you do with your stretch servers running PHP now? Pray for
> good support in Debian, upgrade to 3rd party packages? Upgrade to buster
> already?
> 
> Regards,
> Jochen.
> 
> [1] FWIW, the PGP key used for the repository (AC0E47584A7A714D) is
>signed by Ondřej Surý (0C99B70EF4FCBB07) which, in turn, is
>signed by 184 keys fro debian-keyring. The WoT probably does not get
>better than that.
> 
> - End forwarded message -
> 
> -- 
> If I was a supermodel I would give all my cocaine to the socially
> excluded.
> [Agree]   [Disagree]
> 

Re: Status of PHP support in stretch

[Jochen Spieker]

Hi Ondřej,

thanks for chiming in.

Ondřej Surý:
>
> I still don’t understand why everybody suddenly thinks PHP is special
> in any way.  The packages will be treated same as any other Debian
> package - the important security fixes will be backported.

I am not sure who you are addressing (I may have missed relevant
discussion about this question), but from my (not particularly well
informed) point of view, PHP is a big piece of software which plays a
critical role on many systems. Additionally, it is generally perceived
to be prone to security issues.

Debian has already dropped support for packages in stable in the past
when nobody felt able to support them. Kudos and many thanks to you if
you are able and willing to do so. I just do not think this can be taken
as a given under all circumstances. Hence my question.

Of course, the question remains what is going to happen with security
issues in 7.0 for which there is no backportable upstream fix.

J.
-- 
If I could travel in time I would show my minidisc to the Romans and
become Caesar until the batteries ran out.
[Agree]   [Disagree]
 


signature.asc
Description: PGP signature

Re: SIMDebian: Debian Partial Fork with Radical ISA Baseline

[Drew Parsons]

On 2019-02-09 03:25, Mo Zhou wrote:

Hi folks,

For most programs the "-march=native" option is not expected to bring 
any
significant performance improvement. However for some scientific 
applications
this proposition doesn't hold. When I was creating the tensorflow 
debian
package, I observed a significant performance gap between generic code 
and

kabylake (Intel 7XXX Series) code[1].


...


Generally speaking, in order to bump the ISA baseline for a given 
package, one
could add the -march=xxx flag to {C,CXX,F}FLAGS by modifying 
debian/rules.
However SIMDebian employes a more economic approach to this end: 
forking
dpkg[5] and injecting -march=xxx flag to the system default flag list. 
With the
resulting dpkg package, most debian packages could be rebuilt with 
bumped ISA

baseline without any code modification.




I think it would be more constructive to provide arch-specific packages 
for eigen/blas etc on amd64 which Conflict/Replace/Provide the standard 
packages.


That way a local administrator can choose to install them if they help 
improve performance.


Hacking dpkg itself for this purpose and forking an entire linux 
distribution is way too invasive and distracts from solving the actual 
problem.


Drew

Re: SIMDebian: Debian Partial Fork with Radical ISA Baseline

[Benda Xu]

Hi Mo,

Mo Zhou  writes:

> For most programs the "-march=native" option is not expected to bring any
> significant performance improvement. However for some scientific applications
> this proposition doesn't hold. When I was creating the tensorflow debian
> package, I observed a significant performance gap between generic code and
> kabylake (Intel 7XXX Series) code[1].

> ...

Very interesting initiative.  I understand it will Intel-specific for
the moment.  What is your vision in opitmizing with AMD CPUs?

Yours,
Benda

Re: SIMDebian: Debian Partial Fork with Radical ISA Baseline

[Mo Zhou]

Hi Drew,

On Sat, Feb 09, 2019 at 01:07:47PM +1100, Drew Parsons wrote:
> On 2019-02-09 03:25, Mo Zhou wrote:
> 
> I think it would be more constructive to provide arch-specific packages for
> eigen/blas etc on amd64 which Conflict/Replace/Provide the standard
> packages.
>
> That way a local administrator can choose to install them if they help
> improve performance.

Theoretically graceful, but this actually makes packaging much harder
and more complex, in order to avoid SIGILL. However, in a partial fork
we could directly assume a haswell baseline and provide rebuilt packages
from identical source. This way looks unconstructive but it's economic.

https://tracker.debian.org/pkg/isa-support was available since Aug 2017,
but the highest ISA baseline (SSE4.2) is still too conservative to make
actual sense.

> Hacking dpkg itself for this purpose and forking an entire linux
> distribution is way too invasive and distracts from solving the actual
> problem.

I must emphasize that SIMDebian only cares about packages that would
definitely benefit from bumped ISA baseline, and hence I call it a
**partial** fork.  The modified dpkg is not used for rebuilding the
whole archive by brute force, but for (automatically) picking
low-hanging fruits. If package benefits a lot from bumped ISA baseline,
the modified dpkg helps you quickly rebuild it without any code change.

Apart from that, reminded by jrtc27 on IRC, I dug a bit on compiler's
FMV (function multi-versioning) feature[1]. Julia[2] and Clear Linux[3]
are taking advantage from this feature. And most importantly, packages
with FMV feature can enter the Debian archive. So FMV is another
feasible solution to packages need to be accelerated.

After glancing at some benchmarks[4][5] of Clear Linux I started to
wonder if we could borrow some ideas or even patches from Clear linux
and introduce them to Debian...

[1] https://lwn.net/Articles/691932/
[2] https://github.com/JuliaLang/julia/pull/21849
[3] https://clearlinux.org/documentation/clear-linux/tutorials/fmv
[4] 
https://www.phoronix.com/scan.php?page=article&item=arch-antergos-clear&num=1
[5] 
https://www.phoronix.com/scan.php?page=article&item=ubuntu-clear-tweaks&num=1

Re: SIMDebian: Debian Partial Fork with Radical ISA Baseline

[Mo Zhou]

On Sat, Feb 09, 2019 at 01:14:43PM +0800, Benda Xu wrote:
> Hi Mo,
> 
> Very interesting initiative.  I understand it will Intel-specific for
> the moment.  What is your vision in opitmizing with AMD CPUs?

Thanks for your interest. This project didn't mention AMD CPU because I
have no experience about it[1]. Maybe we could select a better set of
compiler options from [2] ?

Currently there are three branches (although badly synchronized
currently) in the SIMDebian archive[3]. With some slight modification on
the forked dpkg we can also setup specific archives for e.g. NEON (arm),
VSX (ppc64el), and advanced AMD CPU microarchitectures.

SIMDebian only cares about packages that would benefit from bumped ISA.
So the archive will be small even if we support tens of baselines over
different architectures at the same time.

[1] I've never had an AMD CPU in my life.
[2] https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/x86-Options.html#x86-Options
[3] https://sim.debiancn.org/simdebian/