Re: Policy 12.3: should I rename?

[Tollef Fog Heen]

]] Tobias Frost 

> Am Samstag, den 23.07.2016, 18:58 +0200 schrieb Tollef Fog Heen:
> > Disk space is pretty cheap and we keep complaining about the
> > per-package overhead in Packages.gz, so it should be a net gain for
> > most people.
> 
> Think embedded devices. For those disk space is not cheap, maybe even
> not expandable at all.

For those, just use dpkg file exclusions, as I mentioned upthread.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Re: TMPDIR - Do we also need a drive backed TPMDIR ?

[Ritesh Raj Sarraf]

Hello All,

On Thu, 2016-07-21 at 20:41 +0530, Ritesh Raj Sarraf wrote:
> On Thu, 2016-07-21 at 13:38 +0100, Ian Jackson wrote:
> > 
> > You are using `survives reboots' as a proxy for `on disk'; and using
> > `on disk' as a proxy for `has enough space for large amounts of data'.
> 
> Yes. :-)
> 
> > 
> > I don't think this is a good approach.
> > 
> > It's true that /tmp has traditionally been smaller than /var/tmp,
> > partly as an accident of partition and filesystem layout.
> > 
> > As a practical matter, there are big performance gains to be had from
> > not requiring across-reboot (and, particularly, across-crash)
> > persistence.
> > 
> > Perhaps the right answer is instead that we should simply configure
> > more swap by default ?  (IIRC tmpfs data can be swapped.)
> 
> Yes. But that's not the default in our setups. Perhaps next step is to file a
> wishlist bug report.
> 
> 

Lots of folks on the list mentioned about swap. I wasn't very clear on how
that'd work. So I reached out to the tmpfs maintainer. From what  Hugh explained
(email attached), the size allocated to tmpfs (or rather /tmp on tmpfs) does not
change. It is a fixed size (kernel default to 50% of RAM). The benefit of tmpfs
over ramfs (previous implementation) is that tmpfs can be resized live.


So that said, I (still) wonder if there should be a [D]TMPDIR ?
Because RAM is limited. But having /tmp on tmpfs has obvious benefits.
And in the current form, lots of applications depend on /tmp for scratch space,
and they may break.


-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System--- Begin Message ---
On Mon, 25 Jul 2016, Ritesh Raj Sarraf wrote:
> 
> I am writing to you because you are listed as Maintainers for the tmpfs file
> system in the Linux kernel.
> 
> 
> Recently, I have had a bug in a general purpose application, where it ran out 
> of
> space in $TMPDIR. As is common, these days, most people vote for /tmp on 
> tmpfs,
> for obviously good reasons (performance, efficiency etc).
> 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=831998

I think the problem is not so much with tmpfs itself, as with tmpfs
defaulting to a smaller size (half of RAM) of filesystem than would
be common on disk.  You would see the same problems with a 3.7G
disk partition mounted on /tmp; but tmpfs is easier to resize.

Looks like it didn't need much more space, try
$ sudo mount -o remount,size=4G /tmp

Or, perhaps it's just that something else left its forgotten junk
behind in /tmp, and you need to do some cleanup.

> 
> 
> On bringing this bug, and the topic of "TMPDIR on tmpfs" on Debian-Devel,
> there's one comment which wasn't clear to me. Hence this email to you.
> 
> Even in the description below about tmpfs, it says, ". to accommodate the
> files it contains and is able to swap unneeded pages out to swap space."

It writes of growing and shrinking there, to distinguish the behavior of
tmpfs from that of the original ramdisks we had in v2.4: where the maximum
RAM was assigned to them at startup IIRC.  Then ramdisks were changed to
allocate on demand during v2.6.  But ramdisks have never used swap, so
cannot shrink their RAM use after it has been allocated.

And yes, it is confusing to write of growing and shrinking, when this
growth and shrinkage in RAM use makes no difference to the filesystem
size itself: that limit remains the same throughout, unless you choose
to change it with a remount, as suggested above.

> 
> When we say "swap unneeded pages out to swap space", as I understand, what is
> being referred as "Swappable" here is any process in the kernel's namespace. 
> And
> not referring to processes associated with /tmp ? Because those mostly will be
> active processes.

No, it's not talking about processes there.  Under memory pressure
page reclaim uses swap for storing pages of process anonymous memory,
and for storing pages of tmpfs file memory, until it's needed in RAM again.
Similar mechanism is used for paging in both cases, and all these pages are
tracked on the same lists, but processes and files are swapped independently.

> 
> The way I observed, it looks like whatever "/tmp on tmpfs" is capped at, from
> the VFS point of view, is the standard limit for processes accessing files in
> /tmp. And that file system view and limitations won't change (in effect to 
> other
> processes being swapped or not).

Correct, the use of swap does not affect the filesystem size limit at all.

Hugh

> 
> Consider this example:
> 
> rrs@chutzpah:~$ df -h /tmp/
> Filesystem  Size  Used Avail Use% Mounted on
> tmpfs   3.7G  3.7M  3.7G   1% /tmp
> 
> rrs@chutzpah:~$ dd if=/dev/zero of=/tmp/foo.img bs=1M count=4000
> dd: error writing '/tmp/foo.img': No space left on device
> 3691+0 records in
> 3690+0 records out
> 3869605888 bytes (3.9 GB, 3.6 GiB) copied, 1.12808 s, 3.4 GB/s
> 
> rrs@chutzpah:~$ free -m
>   totalusedfree  shared  buff/cache   
> available

Bug#832420: ITP: qtwebengine -- Web content engine library for Qt

[Sandro Knauß]

Package: wnpp
Severity: wishlist
Owner: "Sandro Knauß" 

* Package name: qtwebengine
  Version : 5.6.1
  Upstream Author : The Qt Company Ltd.
* URL : http://trac.webengine.org/wiki/QtWebEngine
* License : LGPL2+,GPL2+, BSD
  Programming Lang: C++
  Description : Web content engine library for Qt

 QtWebEngine provides a Web browser engine that makes it easy to embed content
 from the World Wide Web into your Qt application.
 .
 This package contains the development files needed to build Qt 5 applications
 using QtWebEngine library.

We want to package it within the  Debian Qt/KDE Maintainers 
 umrella
and need it for newer KDE Applications.

Bug#832421: ITP: qtwebchannel -- Publish `QObjects` for the usage of webengine

[Sandro Knauß]

Package: wnpp
Severity: wishlist
Owner: "Sandro Knauß" 

* Package name: qtwebchannel
  Version : 5.6.1
  Upstream Author : The QtCompany Ltd.
* URL : http://doc.qt.io/qt-5/qtwebchannel-index.html
* License : LGPL2.1, LGPL3
  Programming Lang: C++
  Description : Publish `QObjects` for the usage of webengine

 Provides public API shared by both QtWebEngine and QtWebEngineWidgets

 We intend to package it under the Debian Qt/KDE Maintainers 
 umbrella.
 It is needed for QtWebEngine.

Re: TMPDIR - Do we also need a drive backed TPMDIR ? [and 1 more messages]

[Ian Jackson]

Vincent Lefevre writes ("Re: TMPDIR - Do we also need a drive backed TPMDIR ? 
[and 1 more messages]"):
> On an older laptop, I had 4 GB RAM, and under normal conditions,
> I was using only around 1 GB. Swap was used only in two cases:
> 
> 1. Because Firefox was taking more than 4 GB after some time, but
> in this case, the system was more or less frozen. So, the only thing
> I could do was to kill Firefox from a terminal, which was taking me
> several minutes... I ended up by using a wrapper script that did:
> 
>   ulimit -v 4096000
>   exec /usr/bin/firefox "$@"
> 
> so that Firefox would crash instead of freezing the system. Now, it
> seems that Firefox has improved and no longer take so much memory.

You may find that changing the io scheduler from cfq (which is
appallingly bad) to deadline helps.

> 2. Due to bugs in my programs, or something similar. Ditto, I would
> have preferred a crash than a frozen system.

Perhaps I have a different use pattern.

Ian.

Bug#832435: ITP: lua-nvim -- lua client for neovim

[Jason Pleau]

Package: wnpp
Severity: wishlist
Owner: Jason Pleau 

* Package name: lua-nvim
  Version : 0.0.1-25
  Upstream Author : Neovim contributors
* URL : https://github.com/neovim/lua-client/
* License : Apache-2.0
  Programming Lang: Lua, C
  Description : lua client for neovim

Lua library to communicate with Neovim through its msgpack-rpc API

It will eventually be able to act as a Lua plugin host, enabling the use and
development of Lua plugins for Neovim.



This package is required to run the tests for neovim

It will be maintained in pkg-lua

Bug#832430: ITP: haskell-th-data-compat -- Compatibility for data definition template of TemplateHaskell

[Kei Hibino]

Package: wnpp
Severity: wishlist
Owner: Kei Hibino 

* Package name: haskell-th-data-compat
  Version : 0.0.2.2
  Upstream Author : Kei Hibino 
* URL : https://github.com/khibino/haskell-th-data-compat
* License : BSD3
  Programming Lang: Haskell
  Description : Compatibility for data definition template of 
TemplateHaskell

This package contains wrapped name definitions of data definition template
using in TemplateHaskell.

- This package provides compatible interface for data definition template
  in TemplateHaskell between GHC 7.x and 8.0
- This package is used in Haskell Relatoinal Record 
  ( http://khibino.github.io/haskell-relational-record/ ) project.
- I'm planning to maintain this package inside the pkg-haskell team.
- I need a sponsor.

Bug#832443: ITP: mergerfs -- mergerfs is a union filesystem geared towards simplifing storage

[Ritesh Raj Sarraf]

Package: wnpp
Severity: wishlist
Owner: Ritesh Raj Sarraf 

* Package name: mergerfs
  Version : 2.14.0
  Upstream Author : Antonio SJ Musumeci 
* URL : http://github.com/trapexit/mergerfs
* License : ISC
  Programming Lang: C++
  Description : mergerfs is a union filesystem geared towards simplifing 
storage

 mergerfs is a union filesystem geared towards simplifing storage and 
management of files across numerous commodity storage devices. It is similar to 
mhddfs, unionfs, and aufs.

 Some salient features include
 * Runs in userspace (FUSE)
 * Configurable behaviors
 * Support for extended attributes (xattrs)
 * Support for file attributes (chattr)
 * Runtime configurable (via xattrs)
 * Safe to run as root
 * Opportunistic credential caching
 * Works with heterogeneous filesystem types
 * Handling of writes to full drives
 * Handles pool of readonly and read/write drives

Bug#832451: ITP: aufs4 -- advanced multi layered unification filesystem version 4.x

[Jan Luca Naumann]

Package: wnpp
Severity: wishlist
Owner: Jan Luca Naumann 

* Package name: aufs4
  Version : 4.6+20160523
  Upstream Author : Junjiro R. Okajima 
* URL : http://aufs.sourceforge.net/
* License : GPL2+
  Programming Lang: C
  Description : advanced multi layered unification filesystem version 4.x

Aufs is a stackable unification filesystem such as Unionfs, which unifies
several directories and provides a merged single directory.
In the early days, aufs was entirely re-designed and re-implemented
Unionfs Version 1.x series. After
many original ideas, approaches and improvements, it
becomes totally different from Unionfs while keeping the basic features.
See Unionfs Version 1.x series for the basic features.
Recently, Unionfs Version 2.x series begin taking some of same
approaches to aufs's.

I'm intending to package the version 4.x for Debian. The module
should use dkms to be build as kernel module.

I hope to do the work as part of the filesystems project on Alioth:
https://alioth.debian.org/projects/filesystems/

I need a sponsor for the package.

Re: Bug#832451: ITP: aufs4 -- advanced multi layered unification filesystem version 4.x

[Thomas Goirand]

On 07/25/2016 06:12 PM, Jan Luca Naumann wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Jan Luca Naumann 
> 
> * Package name: aufs4
>   Version : 4.6+20160523
>   Upstream Author : Junjiro R. Okajima 
> * URL : http://aufs.sourceforge.net/
> * License : GPL2+
>   Programming Lang: C
>   Description : advanced multi layered unification filesystem version 4.x
> 
> Aufs is a stackable unification filesystem such as Unionfs, which unifies
> several directories and provides a merged single directory.
> In the early days, aufs was entirely re-designed and re-implemented
> Unionfs Version 1.x series. After
> many original ideas, approaches and improvements, it
> becomes totally different from Unionfs while keeping the basic features.
> See Unionfs Version 1.x series for the basic features.
> Recently, Unionfs Version 2.x series begin taking some of same
> approaches to aufs's.
> 
> I'm intending to package the version 4.x for Debian. The module
> should use dkms to be build as kernel module.
> 
> I hope to do the work as part of the filesystems project on Alioth:
> https://alioth.debian.org/projects/filesystems/
> 
> I need a sponsor for the package.

We have already overlayfs in modern kernels. Could you explain why we
need aufs4 as well?

Cheers,

Thomas Goirand (zigo)

Bug#832466: ITP: python-ubjson -- Universal Binary JSON encoder/decoder

[Orestis Ioannou]

Package: wnpp
Severity: wishlist
Owner: Orestis Ioannou 

* Package name: python-ubjson
  Version : 0.8.5
  Upstream Author : 2016 Iotic Labs Ltd vilnis.terma...@iotic-labs.com
* URL : https://github.com/Iotic-Labs/py-ubjson
* License : Apache-2.0
  Programming Lang: Python
  Description : Universal Binary JSON encoder/decoder

Universal Binary JSON encoder/decoder based on the draft-12 specification.
It’s meant to behave very much like Python’s built-in JSON module

Limitations

* The No-Op type is not supported. (This should arguably be a protocol-
level rather than serialisation-level option.)
* Strongly-typed containers are only supported by the decoder (apart from
for bytes/bytearray).
* Encoder/decoder extensions are not supported at this time.
* cython optimizations could be improved.

Last off-archive dependency for crossbar which i want to package

Proposed mass bug filing: use and misuse of dbus-launch (dbus-x11)

[Simon McVittie]

I'm planning to do a mass-bug-filing against packages that mention
dbus-x11 in their dependencies, or dbus-launch in their code, asking
maintainers to adjust their dependencies to make dbus-x11 optional.
My goal is that users can install the major desktop tasks in stretch
(GNOME, KDE, etc.) with either one of dbus-user-session or dbus-x11,
defaulting to dbus-user-session for new installations.

I'm deliberately not doing a dd-list yet because there's an open
question about the order of preference, but the affected source
packages are basically

(minus some false positives that just mention dbus-launch or dbus-x11
without any technical effect). I'll re-post this with a dd-list when
there's something like consensus.

The tl;dr version:

* I think we should default to dbus-user-session for stretch on Linux.
* dbus-launch (dbus-x11) without dbus-user-session should continue to
  be supported, but should be a non-default configuration on Linux.
* On kFreeBSD and Hurd, dbus-launch is still the best we can do.
* Regression tests should use dbus-run-session, not dbus-launch,
  on all kernels.
* Fallback plan: make it possible for early adopters to use
  dbus-user-session instead of dbus-launch, but keep dbus-launch the
  default for new installs even on Linux, and reconsider for stretch+1.

Background: ways you might get a session bus


As of current stable, the correct way to start a "production"
D-Bus session in Debian was for /etc/X11/Xsession.d to invoke
dbus-launch(1). This would result in a session bus (dbus-daemon) per
X11 display, and is set up by the dbus-x11 package. The dbus-daemon
terminates when the X11 display does.

dbus 1.10 in testing/unstable introduces a new way for systemd users
to get a D-Bus session bus per uid (the *user bus*), shared between
all parallel logins whether they are X11, Wayland, Mir, text or
non-interactive. This is not 100% compatible with traditional practice,
particularly if you have two or more parallel X11 logins with the same uid
(GNOME's gdm won't do that, but some other display managers do), which
is why it is "opt-in". In Debian, this is not done by default, but can be
activated by installing the dbus-user-session package. In this case the
dbus-daemon terminates when "systemd --user" does, which is when the uid
responsible for this dbus-daemon ends their last parallel login session.

Some desktop environment core components, such as GNOME's gnome-session,
will automatically start a session bus per login session using
dbus-launch if there is not already one available. I believe GNOME on
Wayland currently relies on this mechanism if dbus-user-session is not
installed. This session bus terminates when the X11 display does (in the
case of GNOME on Wayland, the X11 display is XWayland, and terminates
when gnome-shell does). Similarly, regression tests sometimes start a
fake X11 display (Xvfb) and run dbus-launch scoped to that X11 display.

Another possible way to get a session bus is to run dbus-run-session(1),
or run dbus-daemon directly (typically using its --print-address
option). This is frequently done by regression tests. In this case,
a dbus-daemon started by dbus-run-session is terminated when
dbus-run-session's child process terminates, and a directly-run
dbus-daemon must be killed by the test script at the appropriate time.

Finally, if you start a program that uses D-Bus with no session bus
running, and you have an X11 display, the D-Bus library (typically
libdbus or GLib's GDBus) will attempt "X11 autolaunching": the program
forks and execs dbus-launch in a special "autolaunching" mode, and the
various dbus-launch processes that were started in this way attempt to
acquire a hidden X11 resource. Whichever dbus-launch process happens to
get there first forks and execs the dbus-daemon for this X11 session,
then continues to run to supervise it; the other dbus-launch processes
just report its address back to their parents and then terminate.
This mode is discouraged, and not particularly reliable: it has
a tendency to start the dbus-daemon in a somewhat precarious situation,
as a child of some random GUI app with arbitrary environment variables,
resource limits, std{in,out,err} fds and so on.

Autolaunching can also get used if you run a graphical program under
su/sudo with access to your X11 display (but seriously, don't do that).

X11 autolaunching may have been important 10 years ago, when people
installed D-Bus into distributions that didn't otherwise integrate it,
and used it to run individual GNOME or KDE apps inside a fvwm session
or something. However, in 2016 and in a well-integrated distribution
like Debian, I would be inclined to treat any use of X11 autolaunching
as a bug.

Why should we prefer dbus-user-session?
===

* If a GUI login session is running (for example you are logged-in
  to a GUI environment but the

Re: TMPDIR - Do we also need a drive backed TPMDIR ?

[Ben Hutchings]

On Mon, 2016-07-25 at 14:27 +0530, Ritesh Raj Sarraf wrote:
> Hello All,
> 
> On Thu, 2016-07-21 at 20:41 +0530, Ritesh Raj Sarraf wrote:
> > On Thu, 2016-07-21 at 13:38 +0100, Ian Jackson wrote:
> > > 
> > > You are using `survives reboots' as a proxy for `on disk'; and using
> > > `on disk' as a proxy for `has enough space for large amounts of data'.
> > 
> > Yes. :-)
> > 
> > > 
> > > I don't think this is a good approach.
> > > 
> > > It's true that /tmp has traditionally been smaller than /var/tmp,
> > > partly as an accident of partition and filesystem layout.
> > > 
> > > As a practical matter, there are big performance gains to be had from
> > > not requiring across-reboot (and, particularly, across-crash)
> > > persistence.
> > > 
> > > Perhaps the right answer is instead that we should simply configure
> > > more swap by default ?  (IIRC tmpfs data can be swapped.)
> > 
> > Yes. But that's not the default in our setups. Perhaps next step is to file 
> > a
> > wishlist bug report.
> > 
> > 
> 
> Lots of folks on the list mentioned about swap. I wasn't very clear on how
> that'd work. So I reached out to the tmpfs maintainer.

It is a shame that you didn't read more carefully what he said.

> From what  Hugh explained
> (email attached), the size allocated to tmpfs (or rather /tmp on tmpfs) does 
> not
> change. It is a fixed size (kernel default to 50% of RAM).

That is a *limit* on the size allocated to it.

> The benefit of tmpfs over ramfs (previous implementation) is that
> tmpfs can be resized live.
[...]

He said ramdisk, not ramfs.  A ramdisk has a fixed size.  A ramfs has a
variable size, like tmpfs, but its files are never swapped.  It's
intended for processors without an MMU.

Ben.

-- 

Ben Hutchings
Knowledge is power.  France is bacon.


signature.asc
Description: This is a digitally signed message part

Re: Bug#832451: ITP: aufs4 -- advanced multi layered unification filesystem version 4.x

[Ben Hutchings]

On Mon, 2016-07-25 at 21:05 +0200, Thomas Goirand wrote:
> On 07/25/2016 06:12 PM, Jan Luca Naumann wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Jan Luca Naumann 
> > 
> > * Package name: aufs4
> >   Version : 4.6+20160523
> >   Upstream Author : Junjiro R. Okajima 
> > * URL : http://aufs.sourceforge.net/
> > * License : GPL2+
> >   Programming Lang: C
> >   Description : advanced multi layered unification filesystem
> > version 4.x
> > 
> > Aufs is a stackable unification filesystem such as Unionfs, which
> > unifies
> > several directories and provides a merged single directory.
> > In the early days, aufs was entirely re-designed and re-implemented
> > Unionfs Version 1.x series. After
> > many original ideas, approaches and improvements, it
> > becomes totally different from Unionfs while keeping the basic
> > features.
> > See Unionfs Version 1.x series for the basic features.
> > Recently, Unionfs Version 2.x series begin taking some of same
> > approaches to aufs's.
> > 
> > I'm intending to package the version 4.x for Debian. The module
> > should use dkms to be build as kernel module.
> > 
> > I hope to do the work as part of the filesystems project on Alioth:
> > https://alioth.debian.org/projects/filesystems/
> > 
> > I need a sponsor for the package.
> 
> We have already overlayfs in modern kernels. Could you explain why we
> need aufs4 as well?

I believe aufs stil has these advantages over overlayfs:

- Can be exported via NFS
- White-outs share an inode rather than
requiring an inode each
- Sparse files remain sparse when copied-up
-
Multiple writeable branches
- Creating a hard link does not require a
copy-up

Ben.

-- 

Ben Hutchings
Knowledge is power.  France is bacon.


signature.asc
Description: This is a digitally signed message part

Bug#832498: ITP: apertium-kaz-tat -- Apertium translation data for the Kazakh-Tatar pair

[Kartik Mistry]

Package: wnpp
Severity: wishlist
Owner: Kartik Mistry 

* Package name: apertium-kaz-tat
  Version : 0.2.1
  Upstream Author : Nathan Maxson,
Francis M. Tyers ,
Jonathan N. Washington ,
Ilnar Salimzyan ,
Kevin Brubeck Unhammer ,
Qdinar .
* URL : http://www.apertium.org/
* License : GPL-3
  Programming Lang: 
  Description : Apertium translation data for the Kazakh-Tatar pair

Data package providing Apertium language resources for translating
between the Kazakh and Tatar languages.

-- 
Kartik Mistry | IRC: kart_
{0x1f1f, kartikm}.wordpress.com


signature.asc
Description: PGP signature

Bug#832497: ITP: apertium-is-sv -- Apertium translation data for the Icelandic-Swedish pair

[Kartik Mistry]

Package: wnpp
Severity: wishlist
Owner: Kartik Mistry 

* Package name: apertium-is-sv
  Version : 0.1.0
  Upstream Author : Tihomir Rangelov ,
Francis M. Tyers ,
Kevin Brubeck Unhammer ,
Trond Trosterud 
* URL : http://www.apertium.org/
* License : GPL-2
  Programming Lang: 
  Description : Apertium translation data for the Icelandic-Swedish pair

Data package providing Apertium language resources for translating
between the Icelandic and Swedish languages.

-- 
Kartik Mistry | IRC: kart_
{0x1f1f, kartikm}.wordpress.com


signature.asc
Description: PGP signature

Bug#832499: ITP: apertium-mlt-ara -- Apertium translation data for the Maltese-Arabic pair

[Kartik Mistry]

Package: wnpp
Severity: wishlist
Owner: Kartik Mistry 

* Package name: apertium-mlt-ara
  Version : 0.2.0
  Upstream Author : Kevin Brubeck Unhammer ,
Francis M. Tyers ,
Maria Fronczak .
* URL : http://www.apertium.org/
* License : GPL-2+
  Programming Lang: 
  Description : Apertium translation data for the Maltese-Arabic pair

Data package providing Apertium language resources for translating
between the Maltese and Arabic languages.

-- 
Kartik Mistry | IRC: kart_
{0x1f1f, kartikm}.wordpress.com


signature.asc
Description: PGP signature