Bug#836163: ITP: python-bottle-cork -- authentication for the bottle web framework

[Debian/GNU]

Package: wnpp
Severity: wishlist
Owner: "IOhannes m zmölnig (Debian/GNU)" 

* Package name: python-bottle-cork
  Version : 0.12.0
  Upstream Author : Federico Ceratto 
* URL : http://cork.firelet.net/
* License : LGPL
  Programming Lang: Python
  Description : authentication for the bottle web framework

 Cork provides a simple set of methods to implement Authentication and
 Authorization in web applications based on Bottle.
 .
 It is designed to stay out of the way and let you focus on what your 
application
 should do.


I intend to maintain this package (and a few other bottle-related packages)
within the Debian Python Modules Team.

Bug#836165: ITP: python-bottle-sqlite -- SQLite3 database integration for Bottle.

[Debian/GNU]

Package: wnpp
Severity: wishlist
Owner: "IOhannes m zmölnig (Debian/GNU)" 

* Package name: python-bottle-sqlite
  Version : 0.1.3
  Upstream Author : Marcel Hellkamp
* URL : http://bottlepy.org/docs/dev/plugins/sqlite.html
* License : MIT
  Programming Lang: Python
  Description : SQLite3 database integration for Bottle.

 Bottle-sqlite is a plugin that integrates SQLite3 with your Bottle application.
 It automatically connects to a database at the beginning of a request, passes
 the database handle to the route callback and closes the connection afterwards.
 .
 To automatically detect routes that need a database connection, the plugin
 searches for route callbacks that require a db keyword argument (configurable)
 and skips routes that do not. This removes any overhead for routes that don’t
 need a database connection.

I intend to maintain this package (and a few other bottle-related packages)
within the Debian Python Modules Team.

Bug#836167: ITP: python-bottle-beaker -- Bottle plugin to session and caching library with WSGI Middleware

[Debian/GNU]

Package: wnpp
Severity: wishlist
Owner: "IOhannes m zmölnig (Debian/GNU)" 

* Package name: python-bottle-beaker
  Version : 0.1.3
  Upstream Author : Thiago Avelino
* URL : https://github.com/bottlepy/bottle-beaker
* License : MIT
  Programming Lang: Python
  Description : Bottle plugin to session and caching library with WSGI 
Middleware

 beaker is a middleware for the bottle web framework, that adds session and
 caching management in a transparent way.

For all practical use-cases, this is a dependency for projects using
python-bottle-cork.  I intend to maintain this package (and a few other
bottle-related packages) within the Debian Python Modules Team,

Common location for face files

[Martin Bammer]

Hi,

why are the face files located in user's home? In case of encrypted home 
directories the login managers cannot access them and the user management 
programs of the different DEs need to create an extra copy of the face files in 
a location outside of the home directory, which is login manager specific. This 
increases the effort for developing user management program unnecessarily.
Wouldn't it be a good idea to have a common location for the users' face files? 
My suggestion would be /etc/faces, because the face files are part of the user 
configurations. A simple policy kit rule could enable the users to write their 
face file into this directory.
What do you think?

Best regards,

Martin

Re: Common location for face files

[Andrew Shadura]

On 31 August 2016 at 11:43, Martin Bammer  wrote:
> why are the face files located in user's home? In case of encrypted home 
> directories the login managers cannot access them and the user management 
> programs of the different DEs need to create an extra copy of the face files 
> in a location outside of the home directory, which is login manager specific. 
> This increases the effort for developing user management program 
> unnecessarily.
> Wouldn't it be a good idea to have a common location for the users' face 
> files? My suggestion would be /etc/faces, because the face files are part of 
> the user configurations. A simple policy kit rule could enable the users to 
> write their face file into this directory.
> What do you think?

I think something along these lines (in /var though) is what
accountsservice already does?

-- 
Cheers,
  Andrew

Re: Common location for face files

[Lars Wirzenius]

On Wed, Aug 31, 2016 at 11:43:43AM +0200, Martin Bammer wrote:
> Hi,
> 
> why are the face files located in user's home? In case of encrypted home 
> directories the login managers cannot access them and the user management 
> programs of the different DEs need to create an extra copy of the face files 
> in a location outside of the home directory, which is login manager specific. 
> This increases the effort for developing user management program 
> unnecessarily.
> Wouldn't it be a good idea to have a common location for the users' face 
> files? My suggestion would be /etc/faces, because the face files are part of 
> the user configurations. A simple policy kit rule could enable the users to 
> write their face file into this directory.
> What do you think?

I think this is something that should be discussed with upstream
developers of display/login managers, etc. Changing the location from
user's home directories to a system directory has a security impact
that needs careful consideration. Further, for some, the right place
would be somewhere like LDAP instead. In any case, such changes would
seem to me to be beyond what Debian does: we package software and
integrate it into a working system, rather than making fundamental
changes to functionality like this.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Re: Porter roll call for Debian Stretch

[Dimitri John Ledkov]

Hello,

On 30 August 2016 at 23:07, Lucas Nussbaum  wrote:
> On 22/08/16 at 19:12 +0200, Bálint Réczey wrote:
>> Hi Guillem,
>>
>> 2016-08-21 14:02 GMT+02:00 Guillem Jover :
>> > Hi!
>> >
>> > On Sun, 2016-08-21 at 10:24:42 +0200, Bálint Réczey wrote:
>> >> I'm testing a set of patches [2] for gcc and dpkg which enable bindnow 
>> >> for all
>> >> arches and PIE for amd64, ppc64el and s390x in sync with Ubuntu.
>> >>
>> >> My assumption was that this set of architectures need the least amount of
>> >> additional work since they are tested already in Ubuntu, but I would be 
>> >> happy
>> >> if more ports would opt in for PIE.
>> >>
>> >> I plan filing wishlist bugs against dpkg and gcc with the patches
>> >> after I rebuilt a
>> >> few packages with the defaults.
>> >
>> > TBH I think PIE should in fact be safer to enable globally than
>> > bindnow, because the latter changes the run-time behavior and things
>> > might break (perhaps even silently) when failing to load plugins
>> > or similar.
>>
>> Yes, in that sense enabling PIE is safer indeed. Regarding bindnow
>> I don't expect too many surprises either, since other distributions
>> already tested enabling bindnow and probably they found
>> most issues.
>>
>> >
>> > From dpkg PoV enabling both, would at least require a full-archive
>> > rebuild, for bindnow ideally also a full autopkgtest run (as the
>> > updated dpkg FAQ states now, after Lucas Nussbaum approached me some
>> > weeks ago mentioning he was willing to do such archive-wide rebuild).
>>
>> The patches at [2] seem to work well and since you expressed that you would
>> prefer changing both toolchain and dpkg, too, I would like to suggest running
>> the rebuild with those patches.
>>
>> I think Matthias would be OK with the patch since it is very small and brings
>> Debian's gcc closer to Ubuntu's.
>>
>> Lucas, could you please run the rebuild with the three patches?
>
> Hi,
>
> Results are available at
> https://people.debian.org/~lucas/logs/2016/08/30/pie-bindnow-20160830/
>
> I did a full rebuild with bindnow and PIE enabled, then rebuilt all
> failed packages with a pristine unstable chroot.
>
> You can take a look at
> https://people.debian.org/~lucas/logs/2016/08/30/pie-bindnow-20160830/diff.txt
> and grep for "OK Failed" (failed with PIE+bindnow, built fine in
> unstable). (There are 1188 packages failing to build)
>
> Logs for both builds are available in the respective subdirectories.
>
> Lucas
>

Are you sure these are correct? The numbers for PIE+bindnow are a lot
higher than what we see in Ubuntu, for same unmodified packages.

E.g. looking at http://qa.ubuntuwire.org/ftbfs/

amd64/ppc64el/s390x have PIE+bindnow enabled, and
i386/armhf/arm64/powerpc do not. here is nothing in the thousands
range. There might be a dozen packages with PIE+bindnow fixes in
ubuntu, that's not in debian, but that amount cannot be more than a
dozen or two.

Looking at e.g. ace buildlog the PIE+bindnow has this:
-fno-PIE -no-pie -Wl,-z,relro -Wl,-z,now

Which is bindnow without pie, instead of with pie.

And same ace build fine in Ubuntu, with PIE+bindnow on the relevant
arches. https://launchpad.net/ubuntu/+source/ace/6.3.3+dfsg-1.1

-- 
Regards,

Dimitri.

Re: Common location for face files

[Martin Bammer]

> I think something along these lines (in /var though) is what
> accountsservice already does?

Oh yes, this is exactly what I wanted to have! Thanks a lot.

Best regards,

Martin

Re: Mass bug filing: use and misuse of dbus-launch (dbus-x11)

[Simon McVittie]

On Mon, 29 Aug 2016 at 15:49:55 +0100, Jonathan de Boyne Pollard wrote:
> One can run PCDMd,
> kdm, gdm, and lxdm under nosh service management, and it would be good for the
> programs in the login session(s) to just expect "/run/user/$UID/..." sockets,
> as one already obtains from running "user" Desktop Bus brokers under nosh
> service management.

This can already work. If you put XDG_RUNTIME_DIR in user programs'
environment, and arrange for your favourite service manager to make a
dbus-daemon (or something else that speaks the same protocol) listen
on $XDG_RUNTIME_DIR/bus before any user process would try to connect
to it, then modern versions of at least libdbus, GDBus and sd-bus will
connect to it by default with no additional effort on your part. This
client-side code path does not depend on systemd, does not depend on
libsystemd (except obviously sd-bus which is part of libsystemd), and
is compiled in for all supported Unix platforms.

To be nice to the smaller D-Bus client implementations (dbus-java,
dbus-sharp, etc.), and to programs that second-guess how D-Bus is to be
set up, setting user processes' DBUS_SESSION_BUS_ADDRESS to an appropriate
unix: address is strongly recommended. This is not strictly necessary if
your use cases are limited to the major D-Bus implementations - libdbus
(used by QtDBus, dbus-python, etc.), GDBus and sd-bus - and you do not
run any of the session managers etc. whose relevant bugs are listed in

(list is not necessarily complete, I'm about 80% through a grep-based
mass bug filing).

Alternatively, if you cut out the XDG_RUNTIME_DIR middle-man, arrange
for user processes' DBUS_SESSION_BUS_ADDRESS to be set to a value of
your choice, and arrange for your service manager to make a dbus-daemon
listen at that address, that should work in any reasonable D-Bus client
implementation going back at least a decade.

If you want to maintain equivalent integration as part
of your service manager or a third-party project, the current MBF
means you will be able to give the corresponding Debian package
"Provides: dbus-session-bus" and have it satisfy packages' dependencies.

Meanwhile, if you want the relevant integration files (your favourite
service manager's equivalent of systemd units) to be part of dbus (the
reference implementation of D-Bus), please propose tested patches; if
they follow the "user session" model[1], they could eventually go in
dbus-user-session.deb, with its dependencies changed from the current
systemd-sysv to "systemd-sysv | your-service-manager".

For any significant addition to dbus, the contributor will need to be
prepared to help support it - I don't run those other service managers,
so I won't be fixing them. Some systemd contributors, notably Lennart
Poettering from systemd upstream and Jan Alexander Steffens from Arch
Linux, have stepped up to support that aspect of the dbus codebase,
and I would expect similar ongoing contributions from the communities
around other service managers if people want that service manager to be
as well-supported by dbus as systemd is.

> In terms of needs, what I actually need is for you to respect the final
> paragraph of the environment section of the XDG Base Directory Specification,
> if you are not respecting it already, which I hope that you are but suspect
> that you might not be.

Are you are referring to this?

"""
If $XDG_RUNTIME_DIR is not set applications should fall back to a
replacement directory with similar capabilities and print a warning
message
"""

Are you saying that if XDG_RUNTIME_DIR is not set, D-Bus client libraries
should choose some arbitrary other directory that is conjectured to have
the same properties that the XDG_RUNTIME_DIR spec guarantees, look for
a ./bus socket in *that* directory, use it as the session bus if it exists
and has suitable ownership, and meanwhile write a warning message to
stderr? It is not at all clear to me how this behaviour would be useful:
D-Bus is only useful when it interoperates, and having each client
implementation choose an arbitrary fallback (that might not match
where your dbus-daemon is even listening) is not interoperable.

One reasonable fallback that I've seen used for a missing
XDG_RUNTIME_DIR is to create a new empty directory, and use that.
The implementation in libdbus could be interpreted as an optimized,
0-line implementation of that fallback, which elides the actual directory
creation and check for the socket on the basis that the latter will
never succeed in practice, because there is no way for the dbus-daemon
to know that it is expected to put a socket in a newly created directory.

The pragmatic way to make this work is to arrange for your favourite
alternative(s) to systemd to provide an XDG_RUNTIME_DIR with the
properties that are called for by its spec, and make user code inherit
that environment variable from it. A

Re: Porter roll call for Debian Stretch

[Bálint Réczey]

Hi,

2016-08-31 12:26 GMT+02:00 Dimitri John Ledkov :
> Hello,
>
> On 30 August 2016 at 23:07, Lucas Nussbaum  wrote:
>> On 22/08/16 at 19:12 +0200, Bálint Réczey wrote:
>>> Hi Guillem,
>>>
>>> 2016-08-21 14:02 GMT+02:00 Guillem Jover :
>>> > Hi!
>>> >
>>> > On Sun, 2016-08-21 at 10:24:42 +0200, Bálint Réczey wrote:
>>> >> I'm testing a set of patches [2] for gcc and dpkg which enable bindnow 
>>> >> for all
>>> >> arches and PIE for amd64, ppc64el and s390x in sync with Ubuntu.
>>> >>
>>> >> My assumption was that this set of architectures need the least amount of
>>> >> additional work since they are tested already in Ubuntu, but I would be 
>>> >> happy
>>> >> if more ports would opt in for PIE.
>>> >>
>>> >> I plan filing wishlist bugs against dpkg and gcc with the patches
>>> >> after I rebuilt a
>>> >> few packages with the defaults.
>>> >
>>> > TBH I think PIE should in fact be safer to enable globally than
>>> > bindnow, because the latter changes the run-time behavior and things
>>> > might break (perhaps even silently) when failing to load plugins
>>> > or similar.
>>>
>>> Yes, in that sense enabling PIE is safer indeed. Regarding bindnow
>>> I don't expect too many surprises either, since other distributions
>>> already tested enabling bindnow and probably they found
>>> most issues.
>>>
>>> >
>>> > From dpkg PoV enabling both, would at least require a full-archive
>>> > rebuild, for bindnow ideally also a full autopkgtest run (as the
>>> > updated dpkg FAQ states now, after Lucas Nussbaum approached me some
>>> > weeks ago mentioning he was willing to do such archive-wide rebuild).
>>>
>>> The patches at [2] seem to work well and since you expressed that you would
>>> prefer changing both toolchain and dpkg, too, I would like to suggest 
>>> running
>>> the rebuild with those patches.
>>>
>>> I think Matthias would be OK with the patch since it is very small and 
>>> brings
>>> Debian's gcc closer to Ubuntu's.
>>>
>>> Lucas, could you please run the rebuild with the three patches?
>>
>> Hi,
>>
>> Results are available at
>> https://people.debian.org/~lucas/logs/2016/08/30/pie-bindnow-20160830/
>>
>> I did a full rebuild with bindnow and PIE enabled, then rebuilt all
>> failed packages with a pristine unstable chroot.
>>
>> You can take a look at
>> https://people.debian.org/~lucas/logs/2016/08/30/pie-bindnow-20160830/diff.txt
>> and grep for "OK Failed" (failed with PIE+bindnow, built fine in
>> unstable). (There are 1188 packages failing to build)
>>
>> Logs for both builds are available in the respective subdirectories.
>>
>> Lucas
>>
>
> Are you sure these are correct? The numbers for PIE+bindnow are a lot
> higher than what we see in Ubuntu, for same unmodified packages.
>
> E.g. looking at http://qa.ubuntuwire.org/ftbfs/
>
> amd64/ppc64el/s390x have PIE+bindnow enabled, and
> i386/armhf/arm64/powerpc do not. here is nothing in the thousands
> range. There might be a dozen packages with PIE+bindnow fixes in
> ubuntu, that's not in debian, but that amount cannot be more than a
> dozen or two.
>
> Looking at e.g. ace buildlog the PIE+bindnow has this:
> -fno-PIE -no-pie -Wl,-z,relro -Wl,-z,now
>
> Which is bindnow without pie, instead of with pie.

Ubuntu sets bindnow in GCC in Ubuntu while it is set by dpkg in Debian.

Ace requests those flags in d/rules:
...
export DEB_BUILD_MAINT_OPTIONS =
hardening=+format,+fortify,+stackprotector,+relro,+bindnow,-pie
...

I have just started looking at the logs and I think I have a patch to GCC which
will fix many of the FTBFS-es.
I'm also looking at the GCC diff in Ubuntu.

Cheers,
Balint

>
> And same ace build fine in Ubuntu, with PIE+bindnow on the relevant
> arches. https://launchpad.net/ubuntu/+source/ace/6.3.3+dfsg-1.1
>
> --
> Regards,
>
> Dimitri.

Bug#836217: ITP: nfstash -- CLI tools suite implementing NFS client procedures

[Sandro Tosi]

Package: wnpp
Severity: wishlist
Owner: Sandro Tosi 

* Package name: nfstash
  Version : 0.5
  Upstream Author : Matthew Provost
* URL : https://github.com/mprovost/NFStash
* License : BSD
  Programming Lang: C
  Description : CLI tools suite implementing NFS client procedures

 NFStash is a suite of command line tools which implement Network File System
 (NFS) client procedures. These utilities can be used for testing, debugging,
 monitoring and benchmarking the responses from an NFS server in a composable
 and reproducible way, either interactively or in scripts.
 .
 The suite consists of these tools:
 .
   * nfsping: checks status and response time of various RPC protocols on NFS
 servers
   * nfsmount: finds NFS filesystem root filehandles
   * nfsdf: reports NFS server disk space usage
   * nfsls: lists files and directories on an NFS server
   * nfscat: reads and prints files using NFS
   * nfslock: checks if an NFS client can lock a file
   * clear_locks: clears stuck file locks on an NFS server
~   

Re: Porter roll call for Debian Stretch

[Steve Langasek]

On Wed, Aug 31, 2016 at 11:26:55AM +0100, Dimitri John Ledkov wrote:
> Hello,
> > Results are available at
> > https://people.debian.org/~lucas/logs/2016/08/30/pie-bindnow-20160830/

> > I did a full rebuild with bindnow and PIE enabled, then rebuilt all
> > failed packages with a pristine unstable chroot.

> > You can take a look at
> > https://people.debian.org/~lucas/logs/2016/08/30/pie-bindnow-20160830/diff.txt
> > and grep for "OK Failed" (failed with PIE+bindnow, built fine in
> > unstable). (There are 1188 packages failing to build)

> > Logs for both builds are available in the respective subdirectories.

> Are you sure these are correct? The numbers for PIE+bindnow are a lot
> higher than what we see in Ubuntu, for same unmodified packages.

> E.g. looking at http://qa.ubuntuwire.org/ftbfs/

> amd64/ppc64el/s390x have PIE+bindnow enabled, and
> i386/armhf/arm64/powerpc do not. here is nothing in the thousands
> range. There might be a dozen packages with PIE+bindnow fixes in
> ubuntu, that's not in debian, but that amount cannot be more than a
> dozen or two.

Note that enabling PIE by default is going to cause build failures for a
number of packages which link against static libraries, if those static
libraries have not been rebuilt yet with PIE/PIC.  Ubuntu has worked through
this transition, so a direct comparison would require a rebootstrap test in
Debian instead of just a rebuild test (i.e.: test rebuild packages in
dependency order, and build later packages against the output of the earlier
rebuilds).

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Re: Is missing SysV-init support a bug?

[Nikolaus Rath]

On Aug 29 2016, Russ Allbery  wrote:
> Nikolaus Rath  writes:
>> On Aug 28 2016, Bart Schouten  wrote:
>
>>> But that's not the relevance. The idea that systemd is clearly superior
>>> to sysvinit is just something you concoct up because you don't know how
>>> to write a service file or script and you want to let systemd do the
>>> hard work.
>
>> How is that concoted? Yes, systemd is clearly superior to sysvinit
>> because it doesn't require me to know how to write a service file or
>> script but does the hard work for me.
>
> Python is clearly superior to C in that I don't have to do tedious memory
> management or worry about buffer overflows in allocated arrays.  Yet, I
> often prefer to implement things in C for a bunch of different reasons.  A
> couple of major ones are wanting more fine control and wanting a
> standalone binary that doesn't depend on an installed Python ecosystem.
>
> I disagree with both of you in that these aren't really "clearly superior"
> sorts of things, I think.  It feels like the wrong question entirely.

It seems I should have added an irony marker. My point was that the
quoted reasons support the statement just as well as its opposite and
was therefore pretty bogus, not that systemd is clearly superior.

And no, this email is also not stating that systemd is not clearly
superior.

Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Bug#836247: ITP: libsquish -- DXT texture compression library

[Wookey]

Package: wnpp
Severity: wishlist
Owner: Wookey 

  Package name: libsquish
  Version : 1.13
  Upstream Author : Simon Brown, Stefan Röttger
  URL : https://sourceforge.net/projects/libsquish
  License : MIT
  Programming Lang: C++
  Description : DXT texture compression library

 libsquish is a software DXT texture compression library. It
 implements the 5 DXT flavours and has SIMD support for x86 (SSE) and
 powerpc (Altivec). It can be used (as a much slower software
 fallback) instead of the hardware implementations present on most
 modern graphics chips.

This package is a build-dependency of Cavewhere
(https://github.com/Cavewhere, http://www.cavewhere.com), used because
using the hardware implementations has been unreliable in practice,
and speed is not critical here..

Bug#836249: ITP: cavewhere -- Cave survey processing and visualisation

[Wookey]

Package: wnpp
Severity: wishlist
Owner: Wookey 

  Package name: cavewhere
  Version : 0~20160817
  Upstream Author : Philip Schuchardt 
  URL : http://www.cavewhere.com/
  License : GPL3
  Programming Lang: C++
  Description : Cave survey processing and visualisation

 GUI cave survey software, with data entry entry covering multiple data
 formats. Data is processed using survex. Sketches are distorted to fit
 and displayed in 3D, allowing very fast turnaround maps to be produced.
 Uses QT and works on Windows, Mac and Linux. Data can be imported from
 Walls and Survex.

This is quite new software, with a user-friendly modern GUI and taking
a different approach to Tunnel and Therion, the other free-software
cave-survey drawing packages. It has a very helpful upstream. It has
several dependencies which are not yet in debian and thus will need
packaging first: libsquish, qmath3d, dewalls, qt-qml-tricks.