Re: Seeking hardening flag / blhc expoert

[Sven Hartge]

Andrey Rahmatullin  wrote:
> [-- text/plain, encoding quoted-printable, charset: utf-8, 11 lines --]

> On Fri, Apr 05, 2019 at 09:07:06PM +0200, Sven Hartge wrote:
>> CMake is a bit "special" in that regard. To get the right hardening
>> flags to work for some parts of Bacula, we had to include the following
>> patch to kind-of brute force the flags:
>> https://salsa.debian.org/bacula-team/bacula/blob/master/debian/patches/debian/enable-hardening-for-qmake

> qmake != CMake.

Yes, I noticed this the moment I hit sent. Must have been more tired
than I thought I was yesterday.

Grüße,
Sven

-- 
Sigmentation fault. Core dumped.

first epoch for acme-tiny

[Samuel Henrique]

Hello d-devel, and Harlan,

I'm currently working on a fix for an RC bug on acme-tiny that requires the
packaging of the latest upstream release:
acme-tiny: Please update to ACMEv2 API #924393 [0]

In order for that to happen I need to introduce an epoch as we were using
calver and now we have semver, I'm assuming this is a non-controversial
epoch but I need to send this email on d-devel anyway.

Previous version: 20171115-2
Current/Proposed Version: 1:4.0.4-1

I'm CCíng Harlan, a member of the LetsEncrypt Debian Team, as I will need
ack from the team to proceed with the upload (I requested access on salsa
already, can you accept me?) and I couldn't find a mailing list for the
team.

And to be clear I do understand that I will have to ask for an unblock for
this new upstream release.

The packaging is currently on my fork[1], and it will be there until I'm
added on the team, then I will push all of the changes there[2].

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924393
[1] https://salsa.debian.org/samueloph/acme-tiny
[2] https://salsa.debian.org/letsencrypt-team/acme-tiny


-- 
Samuel Henrique 

Re: first epoch for acme-tiny

[Samuel Henrique]

Let me also CC Sebastien Badia, I just CC'ed the first two people that I
found out and are active on the LetsEncrypt team.

On Sat, 6 Apr 2019 at 14:11, Samuel Henrique  wrote:

> Hello d-devel, and Harlan,
>
> I'm currently working on a fix for an RC bug on acme-tiny that requires
> the packaging of the latest upstream release:
> acme-tiny: Please update to ACMEv2 API #924393 [0]
>
> In order for that to happen I need to introduce an epoch as we were using
> calver and now we have semver, I'm assuming this is a non-controversial
> epoch but I need to send this email on d-devel anyway.
>
> Previous version: 20171115-2
> Current/Proposed Version: 1:4.0.4-1
>
> I'm CCíng Harlan, a member of the LetsEncrypt Debian Team, as I will need
> ack from the team to proceed with the upload (I requested access on salsa
> already, can you accept me?) and I couldn't find a mailing list for the
> team.
>
> And to be clear I do understand that I will have to ask for an unblock for
> this new upstream release.
>
> The packaging is currently on my fork[1], and it will be there until I'm
> added on the team, then I will push all of the changes there[2].
>
> [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924393
> [1] https://salsa.debian.org/samueloph/acme-tiny
> [2] https://salsa.debian.org/letsencrypt-team/acme-tiny
>
>
> --
> Samuel Henrique 
>


-- 
Samuel Henrique 

Re: first epoch for acme-tiny

[Guillem Jover]

Hi!

On Sat, 2019-04-06 at 14:11:57 +0100, Samuel Henrique wrote:
> In order for that to happen I need to introduce an epoch as we were using
> calver and now we have semver, I'm assuming this is a non-controversial
> epoch but I need to send this email on d-devel anyway.
> 
> Previous version: 20171115-2
> Current/Proposed Version: 1:4.0.4-1

LGTM, this is what epochs were designed for. :)

Thanks,
Guillem

Re: is Wayland/Weston mature enough to be the default desktop choice in Buster?

[Guillem Jover]

Hi!

On Fri, 2019-04-05 at 16:12:22 +0100, Jonathan Dowland wrote:
> I was surprised to learn — by way of synaptic being autoremoved — that
> the default desktop in Buster will be GNOME/Wayland. I personally do not
> think that Wayland is a sensible choice for the default *yet*; and if
> the consequence is that bugs for software that do not work properly with
> Wayland have their severity inflated such that they are autoremoved (and
> thus potentially removed entirely from Buster), a decision that — in
> isolation — makes sense to me; although Synaptic is quite a high profile
> package within Debian for this to happen.

I don't use GNOME at all, but I tried to switch to Wayland last month
(from i3 to sway), and sadly the experience lasted only a couple of days.

I noticed that not all big desktop programs support Wayland natively
(such as Chromium), or do so out of the box (such as Qt or KDE), this
implies you need to have XWayland running most of the time, which
consumes around 100 MiB of resident memory. Wayland also uses libinput
which I've found to be subpar compared to the synpatics input drivers.
There seems to be also some issue with Qt/KDE programs and text DPI.

The other were problems specific to sway so not relevant to this thread,
but the issues in general were annoying enough that even if I'd really
like to fully switch, I didn't find this was good enough for now.

Although I don't think I care about the default desktop, as users can
select whatever they want at install time or switch to something else,
I can see Jonathan's reasoning that this can inadvertently affect other
bystanders.

Thanks,
Guillem

Re: is Wayland/Weston mature enough to be the default desktop choice in Buster?

[Bastian Blank]

On Sat, Apr 06, 2019 at 08:47:51PM +0200, Guillem Jover wrote:
> I don't use GNOME at all, but I tried to switch to Wayland last month
> (from i3 to sway), and sadly the experience lasted only a couple of days.

You changed display manager implementations and are trying to compare
that?  How can you differentiate between problems causes by the i3 to
sway switch from problems caused by xorg to wayland?

> I noticed that not all big desktop programs support Wayland natively
> (such as Chromium), or do so out of the box (such as Qt or KDE), this
> implies you need to have XWayland running most of the time, which
> consumes around 100 MiB of resident memory.

My gnome-shell consumes a multiple of that usualy.  But much more
important: why is the qt wayland support not installed?

> Wayland also uses libinput
> which I've found to be subpar compared to the synpatics input drivers.

xorg only installs the libinput and the separate wacom input by default:

| Package: xserver-xorg-input-all
| Depends: xserver-xorg-input-libinput
| Recommends: xserver-xorg-input-wacom

> There seems to be also some issue with Qt/KDE programs and text DPI.

I don't see such problems, and I use it in HiDPI mode, which becomes
increasingly more common.  wireshark is now a Qt application and looks
fine, apart from the fact that it's Qt and the design choices of this
library.

I could add a number of problems I found myself, but none of them are
relevant for Joe Random user.

Regards,
Bastian

-- 
It is a human characteristic to love little animals, especially if
they're attractive in some way.
-- McCoy, "The Trouble with Tribbles", stardate 4525.6

Re: SIMDebian: Debian Partial Fork with Radical ISA Baseline

[Guillem Jover]

Hi!

On Fri, 2019-02-08 at 16:25:41 +, Mo Zhou wrote:
> 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].

> 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.

There's been talk in the past about this, AFAIR the most recent one
previous to this was about the various MIPS ISAs (?). We covered this
in the Debian Bootstrap sprint in 2014 (see §2):

  

There's not been much progress there, as it seemed like interest had
wanned.

If what you are interested in though is just a small subset of the
archive, another option that would benefit everyone and is perhaps
less cumbersome than having to jugle around with multiple archives
and package rebuilds/variants, is to make use of libc's hwcaps [H]
support, which means the dynamic linker will automatically load the
best optimized shared object for the current hardware. This of course
can complicate a bit the packaging, and bloat it, but if the performance
improvement is substantial, it might be a very good trade-off.

  [H] man ld.so "NOTES" / "Hardware capabilities"

Another option which requires upstream code changes (and ideally them
being complicit) is to add run-time selection for the more suitable
optimized functions, for example via the __target__ and __ifunc__ [I]
function __attribute__ (and __builtin_cpu_supports or __builtin_cpu_is),
or the __target_clone__ function __attribute__. Perhaps also of
interest is the __simd__ function __attribute__.

  [I] info gcc "Function Attributes";
  

Thanks,
Guillem

Re: is Wayland mature enough to be the default desktop choice in Buster?

[Simon McVittie]

On Sat, 06 Apr 2019 at 20:47:51 +0200, Guillem Jover wrote:
> On Fri, 2019-04-05 at 16:12:22 +0100, Jonathan Dowland wrote:
> > I was surprised to learn — by way of synaptic being autoremoved — that
> > the default desktop in Buster will be GNOME/Wayland.

It's perhaps important to point out before this thread gets much further
that Wayland is not like Xorg: it's a protocol, not a program. GNOME
Shell, Weston and sway are all (separate) Wayland implementations: they
share some library code (and they share Xwayland as a compatibility
layer for X11 apps), but GNOME in Wayland mode and KDE in Wayland mode
have less in common than GNOME on X11 and KDE on X11.

In particular, when GNOME Shell runs in Wayland mode, there is no Weston
involvement.

Weston is definitely not a candidate for the default desktop in buster.
It's the reference implementation of a Wayland compositor, and doesn't
provide a full desktop environment - think of it as more like an
equivalent of Xorg + openbox (or some similarly minimal window manager)
than an equivalent of GNOME or KDE.

GNOME in buster has defaulted to Wayland mode since August 2017. The
default could presumably be swapped back to X11, as we did for stretch,
but I'm not sure whether post-hard-freeze is necessarily an appropriate
time to do that. The GNOME team made the corresponding change in stretch
(for which we had been hoping to default to Wayland, but decided that
it wasn't ready) 2 months before the transition freeze.

If I understand correctly, the pattern that led to synaptic's removal is
that it runs its full GUI as root, which isn't supported by the way many
(all?) Wayland environments set up Xwayland. The reason that Wayland
environment developers don't want to support this is that it makes it
very likely that the GUI that runs as root can be subverted by other
X11 apps connected to the same display.

> I don't use GNOME at all, but I tried to switch to Wayland last month
> (from i3 to sway), and sadly the experience lasted only a couple of days.

sway is not GNOME any more than Weston is, and doesn't necessarily
implement all the same Wayland interfaces as GNOME Shell. I would
recommend assessing Wayland implementations (compositors) on their
own merits.

smcv

Re: is Wayland/Weston mature enough to be the default desktop choice in Buster?

[Guillem Jover]

On Sat, 2019-04-06 at 21:48:57 +0200, Bastian Blank wrote:
> On Sat, Apr 06, 2019 at 08:47:51PM +0200, Guillem Jover wrote:
> > I don't use GNOME at all, but I tried to switch to Wayland last month
> > (from i3 to sway), and sadly the experience lasted only a couple of days.
> 
> You changed display manager implementations and are trying to compare
> that?

Well it was obviously easier to compare than against Weston/GNOME/KDE.

> How can you differentiate between problems causes by the i3 to
> sway switch from problems caused by xorg to wayland?

Because the problems I listed were the ones that are obviously
Wayland-related/specific or because I tried with Xwayland and native
support. And because I think all sway-specific problems I found had
already bugs filed.

> > I noticed that not all big desktop programs support Wayland natively
> > (such as Chromium), or do so out of the box (such as Qt or KDE), this
> > implies you need to have XWayland running most of the time, which
> > consumes around 100 MiB of resident memory.
> 
> My gnome-shell consumes a multiple of that usualy.  But much more
> important: why is the qt wayland support not installed?

On my main system that's way too much memory used, and i3 and sway
consume just a fraction of that.

For Qt, qtwayland5 is just a Suggests from libqt5gui5, and a Recommends
from libkf5windowsystem5, or Depends from kwayland-integration via a
Recommends from libkf5windowsystem5|libkf5idletime5.

Even then, AFAIR Qt does not enable Wayland support by default, and it
might need the following environment variables:

  # KDE
  export XDG_SESSION_TYPE=wayland
  export QT_QPA_PLATFORM=wayland-egl

I also tried to play with:

  export QT_WAYLAND_FORCE_DPI=physical

I also used:

  # Gtk3 (this might crash chromium f.ex.)
  export GDK_BACKEND=wayland
  export CLUTTER_BACKEND=wayland
  # SDL
  export SDL_VIDEODRIVER=wayland

(For a tailing WM you might also want:

  export QT_WAYLAND_DISABLE_WINDOWDECORATION=1
  export _JAVA_AWT_WM_NONREPARENTING=1
?)

So, are you sure you are not running Qt apps via Xwayland? To make
sure I disabled Xwayland support to see what was not starting at all,
as I wanted as much as possible to be running natively, to check if
it was feasible to run w/o Xwayland.

> > Wayland also uses libinput
> > which I've found to be subpar compared to the synpatics input drivers.
> 
> xorg only installs the libinput and the separate wacom input by default:

Sure, and I've tried libinput with X.Org and for me it's the same subpar
experience as on Wayland. The difference is that with X.Org I can install
the synaptics driver.

> > There seems to be also some issue with Qt/KDE programs and text DPI.
> 
> I don't see such problems, and I use it in HiDPI mode, which becomes
> increasingly more common.  wireshark is now a Qt application and looks
> fine, apart from the fact that it's Qt and the design choices of this
> library.

See above?

> I could add a number of problems I found myself, but none of them are
> relevant for Joe Random user.

I think I qualified my reply enough as to what was relevant to the
discussion and to what extent I care about the GNOME default? :)
Dunno, just felt like commenting on my attemps as someone who really
wants to switch away from X.Org, but didn't find it satisfactory yet.

Regards,
Guillem

Re: is Wayland/Weston mature enough to be the default desktop choice in Buster?

[Shengjing Zhu]

As a KDE user, I don't have much knowledge about GNOME.

But I remember at the Chinese user support channel, many people have
problems with the default input method (fcitx) and GNOME. The answer is
usually to ask them to switch to GNOME on Xorg.

Someone may argue that ibus(another input method) is ready for Wayland, but
fcitx is far better than ibus (for Simplified Chinese), except it's not
ready for Wayland.

This user case may be not enough to change the default choice of GNOME, but
I think this should at least be in release notes.

// send from my mobile device


Jonathan Dowland  于 2019年4月5日周五 23:12写道：

> I was surprised to learn — by way of synaptic being autoremoved — that
> the default desktop in Buster will be GNOME/Wayland. I personally do not
> think that Wayland is a sensible choice for the default *yet*; and if
> the consequence is that bugs for software that do not work properly with
> Wayland have their severity inflated such that they are autoremoved (and
> thus potentially removed entirely from Buster), a decision that — in
> isolation — makes sense to me; although Synaptic is quite a high profile
> package within Debian for this to happen.
>
> I think the default should be reconsidered.
>
> --
>
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
> ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
> ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
>
>

Bug#926570: ITP: ruby-sigdump -- Use signal to show stacktrace of a Ruby process without restarting it

[Hideki Yamane]

Package: wnpp
Severity: wishlist
Owner: Hideki Yamane 

* Package name: ruby-sigdump
  Version : 0.2.4
  Upstream Author : Sadayuki Furuhashi 
* URL : https://github.com/frsyuki/sigdump
* License : MIT
  Programming Lang: Ruby
  Description : Use signal to show stacktrace of a Ruby process without 
restarting it

 fluentd depends on it.