Bug#922661: ITP: sandboxfs -- A virtual file system for sandboxing

2019-02-18 Thread Julio Merino
Package: wnpp
Severity: wishlist
Owner: Julio Merino 

* Package name: sandboxfs
  Version : 0.1.0
  Upstream Author : Julio Merino 
* URL : https://github.com/bazelbuild/sandboxfs
* License : Apache 2.0
  Programming Lang: Rust
  Description : A virtual file system for sandboxing

sandboxfs is a FUSE file system that exposes a combination of multiple
files and directories from the host's file system in the form of a virtual
tree with an arbitrary layout.  You can think of a sandbox as an arbitrary
view into the host's file system with different access privileges per
directory.

sandboxfs is designed to allow running commands with limited access to
the file system by using the virtual tree as their new root, and to do so
consistently across a variety of platforms.

--

Why is a package beneficial?

sandboxfs' primary user is Bazel which is not included in Debian.
However, I see sandboxfs as a primitive tool that should be available
with minimal fuss and therefore I think a Debian package would be very
beneficial for all Bazel users.  Being able to tell someone "just run
apt install sandboxfs" before running Bazel is much, much easier than
having to tell them how to set up the Rust toolchain, build the project,
and install it.  Plus sandboxfs has other users outside of Bazel as it
is a pretty generic FUSE file system.

How will this be maintained?

This package should be maintained as part of rust-team.  I am not yet
a Debian developer.

I am the primary developer of this software and have experience in
packaging for pkgsrc (NetBSD) and Fedora.



Bug#699214: xserver-xorg-video-nouveau: Fonts are not displayed

2013-01-30 Thread Julio Merino
On Wed, Jan 30, 2013 at 11:52 AM, Sven Joachim svenj...@gmx.de wrote:
 If you need a driver with working acceleration, look on
 snapshot.debian.org[1] until your bug is resolved.

FWIW, a patch has been posted to the upstream bug and it appears to
resolve my issues :-)

-- 
Julio Merino / @jmmv


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#699214: xserver-xorg-video-nouveau: Fonts are not displayed

2013-01-29 Thread Julio Merino
On Tue, Jan 29, 2013 at 10:45 AM, Sven Joachim svenj...@gmx.de wrote:
 On 2013-01-29 05:56 +0100, Julio Merino wrote:

 I installed Debian testing powerpc64 on a PowerMac G5 with a NVIDIA
 Corporation NV34 [GeForce FX 5200 Ultra] (rev a1) graphics card (as
 reported by lspci).

 Running the X server results in no fonts being displayed at all, with
 the exception of the default fixed font in xterm.  Something as simple
 as xterm -fa Monospace also shows the problem (a blank window with
 a cursor but no visible text), which denotes that the issue is quite
 down the dependency chain.

 * What exactly did you do (or not do) that was effective (or
   ineffective)?

 I uninstalled the xserver-xorg-video-nouveau package, to force the X
 server to fallback to fbdev, and the issue went away.  The fonts are
 now properly displayed.  But, of course, this is just a workaround and
 not a solution; I'd like to use the real driver.

 I suspect this is the same problem as #692156, and it is almost surely
 specific to powerpc.  Could you please try version 1:1.0.6-1 from
 experimental?  If the bug persists with that version, please report it
 upstream, see http://nouveau.freedesktop.org/wiki/Bugs for instructions.

Unfortunately, upgrading xserver-xorg-video-nouveau to 1.0.6 and
installing libdrm-nouveau2-2.4.40 did not resolve the issue.

I have filed Bug 60050 upstream.

 Also, does it help to disable acceleration (boot with nouveau.noaccel=1
 to test that)?

Yes, that helped too.

-- 
Julio Merino / @jmmv


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#699214: xserver-xorg-video-nouveau: Fonts are not displayed

2013-01-28 Thread Julio Merino
Package: xserver-xorg-video-nouveau
Version: 1:1.0.1-4
Severity: important

Dear Maintainer,

* What led up to the situation?

I installed Debian testing powerpc64 on a PowerMac G5 with a NVIDIA
Corporation NV34 [GeForce FX 5200 Ultra] (rev a1) graphics card (as
reported by lspci).

Running the X server results in no fonts being displayed at all, with
the exception of the default fixed font in xterm.  Something as simple
as xterm -fa Monospace also shows the problem (a blank window with
a cursor but no visible text), which denotes that the issue is quite
down the dependency chain.

* What exactly did you do (or not do) that was effective (or
  ineffective)?

I uninstalled the xserver-xorg-video-nouveau package, to force the X
server to fallback to fbdev, and the issue went away.  The fonts are
now properly displayed.  But, of course, this is just a workaround and
not a solution; I'd like to use the real driver.

I also attempted to downgrade libxft and libfreetype6 to older versions
(libfreetype6_2.4.2-2.1+squeeze4_powerpc.deb and
libxft2_2.1.14-2_powerpc.deb) but this did not help.

The graphics driver seems to be at fault here.

* Logs and screenshot depicting the problem:

http://www.NetBSD.org/~jmmv/g5-no-fonts/Xorg.log-with-nouveau
http://www.NetBSD.org/~jmmv/g5-no-fonts/Xorg.log-without-nouveau
http://www.NetBSD.org/~jmmv/g5-no-fonts/dmesg
http://www.NetBSD.org/~jmmv/g5-no-fonts/screenshot.jpg

-- System Information:
Debian Release: 7.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: powerpc (ppc64)

Kernel: Linux 3.2.0-4-powerpc64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/dash

Versions of packages xserver-xorg-video-nouveau depends on:
ii  libc6  2.13-37
ii  libdrm22.4.40-1~deb7u2
ii  libudev0   175-7
ii  xserver-xorg-core [xorg-video-abi-12]  2:1.12.4-4

Versions of packages xserver-xorg-video-nouveau recommends:
ii  libgl1-mesa-dri  8.0.5-3

xserver-xorg-video-nouveau suggests no packages.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#675626: [pkg-lua-devel] Bug#675626: ITP: lutok -- Lightweight C++ API library for Lua

2012-06-15 Thread Julio Merino
On Fri, Jun 15, 2012 at 7:48 AM, Enrico Tassi ga...@fettunta.org wrote:
 On Fri, Jun 15, 2012 at 01:34:36PM +0200, Luca Capello wrote:
 - based on my experience in previous teams (especially on the Debian
   Common Lisp one), having a single point of contact for questions
   related to all $LANGUAGE packages is really useful.

 Exactly. This software seems to be really tight to Lua, so It would be
 nice to have it close to it. For example when I change the lua5.1
 package I also recompile all the lua packages in the svn repository just
 to be sure I did not break them.
 In case the policy for lua packages gets changed, or lua packages get renamed,
 you may also get a patch for free ;-)

Sure thing.  I was not arguing otherwise.  If this package can be
overseen by the Lua team for all the benefits you list, the better!

 Unless you have serious concerns against an svn repository (that will
 eventually become a git one) I suggest you put your package there.

I'm sorry but I don't understand.  This is my very first Debian
package, so everything related to package development in Debian still
escapes my mind...

I don't have any problems with using svn, but what for?  To store the
source package?  I'd have thought all packages were stored in the same
place/system... so I'm a little bit surprised by this.  I may not be
understanding this correctly though.

Lastly, are any of you actually offering to review this package? :-)

Thanks!

-- 
Julio Merino / @jmmv



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#675626: ITP: lutok -- Lightweight C++ API library for Lua

2012-06-14 Thread Julio Merino
On Thu, Jun 14, 2012 at 3:45 AM, Luca Capello l...@pca.it wrote:
 Do you know that there is a Debian Lua Team (Cc:ed) for (ideally)
 packaging Lua software?  IMHO the package should be maintained by you
 under that umbrella:

Thanks for the information.

Based on the policy and the web page, the team you reference seems to
focus on packaging Lua modules.  Lutok is a C++ library that just so
happens to interface with Lua... so I'm not sure it qualifies.  That
said, I'm obviously open to any feedback and reviews from the team!

-- 
Julio Merino / @jmmv



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#675626: Package uploaded to mentors.debian.net

2012-06-03 Thread Julio Merino
I have just uploaded my preliminary package to mentors.debian.net:

http://mentors.debian.net/package/lutok
http://mentors.debian.net/debian/pool/main/l/lutok/lutok_0.2-1.dsc



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#675626: ITP: lutok -- Lightweight C++ API library for Lua

2012-06-02 Thread Julio Merino
Package: wnpp
Severity: wishlist
Owner: Julio Merino j...@julipedia.org

* Package name: lutok
  Version : 0.2
  Upstream Author : Julio Merino j...@julipedia.org
* URL : http://code.google.com/p/lutok/
* License : BSD
  Programming Lang: C++
  Description : Lightweight C++ API library for Lua

Lutok provides thin C++ wrappers around the Lua C API to ease the
interaction between C++ and Lua.  These wrappers make intensive use of
RAII to prevent resource leakage, expose C++-friendly data types, report
errors by means of exceptions and ensure that the Lua stack is always
left untouched in the face of errors.  The library also provides a small
subset of miscellaneous utility functions built on top of the wrappers.

Lutok focuses on providing a clean and safe C++ interface; the drawback
is that it is not suitable for performance-critical environments.  In
order to implement error-safe C++ wrappers on top of a Lua C binary
library, Lutok adds several layers or abstraction and error checking
that go against the original spirit of the Lua C API and thus degrade
performance.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#578885: libpaper: Fix __STDC__ test

2010-04-23 Thread Julio Merino
Package: libpaper
Version: 1.1.23+nmu2
Tags: patch

__STDC__ may not be defined, so attempting to use its value in those cases
may cause build failures.  Fix this by just checking whether __STDC__ is
defined or not, which according to GCC documentation should be enough to
detect whether function prototypes are available or not.

Index: libpaper-1.1.23+nmu2/lib/paper.h
===
--- libpaper-1.1.23+nmu2.orig/lib/paper.h   1996-09-24 08:16:07.0 
+0100
+++ libpaper-1.1.23+nmu2/lib/paper.h2010-04-23 11:16:30.562907882 +0100
@@ -22,7 +22,7 @@
  *
  */
 
-#if __STDC__ - 0 == 0
+#if !defined(__STDC__)
 
 #define __PAPER_CONST
 #define __PAPER_PROTO(p)   ()



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#578884: libpaper: Remove unnecessary malloc.h inclusion

2010-04-23 Thread Julio Merino
Package: libpaper
Version: 1.1.23+nmu2
Tags: patch

The malloc.h header is obsolete.  malloc(3) is provided by stdlib.h, so fix
headers inclusions accordingly.  I'm unaware of any platform that *requires*
the inclusion of malloc.h these days.

Index: libpaper-1.1.23+nmu2/lib/paper.c
===
--- libpaper-1.1.23+nmu2.orig/lib/paper.c   2002-11-11 00:56:08.0 
+
+++ libpaper-1.1.23+nmu2/lib/paper.c2010-04-23 11:15:45.843639096 +0100
@@ -14,14 +14,12 @@
 #include sys/stat.h
 
 #include stdio.h
-#include malloc.h
+#include stdlib.h
 #include string.h
 #include ctype.h
 
 #include unistd.h
 
-#include stdlib.h
-
 #include paper.h
 
 struct paper {



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#578886: libpaper: Remove bash dependency and make script portable

2010-04-23 Thread Julio Merino
Package: libpaper
Version: 1.1.23+nmu2
Tags: patch

Do not rely on bash for a script that works in other shells.  The only
portability change required to make this work is to avoid using the ==
test(1) operator, as it is a GNU extension.  Instead, use -eq to compare
for integer equality.

Index: libpaper-1.1.23+nmu2/src/paperconfig.in
===
--- libpaper-1.1.23+nmu2.orig/src/paperconfig.in2006-01-05 
08:59:35.0 +
+++ libpaper-1.1.23+nmu2/src/paperconfig.in 2010-04-23 11:15:07.220310176 
+0100
@@ -1,4 +1,4 @@
-#! /bin/bash
+#! /bin/sh
 
 # paperconfig: configuration of system paper name
 #
@@ -44,7 +44,7 @@
 
 force=0
 
-if [ $# == 0 ]
+if [ $# -eq 0 ]
   then
 usage
 fi



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#578887: libpaper: Fix path to RUNPARTSDIR in manual page

2010-04-23 Thread Julio Merino
Package: libpaper
Version: 1.1.23+nmu2
Tags: patch

Correctly use @RUNPARTSDIR@ in the manpage instead of hardcoding the path to
/etc/libpaper.d.  This was already in use in another instance of the path, but
not everywhere.

Index: libpaper-1.1.23+nmu2/man/paperconfig.8.in
===
--- libpaper-1.1.23+nmu2.orig/man/paperconfig.8.in  2006-01-07 
21:05:34.0 +
+++ libpaper-1.1.23+nmu2/man/paperconfig.8.in   2010-04-23 11:19:04.800594970 
+0100
@@ -27,7 +27,7 @@
 When the paper size has been changed,
 .B paperconfig
 notifies other packages of the change by running the scripts in the
-.I /etc/libpaper.d
+.I @RUNPARTSDIR@
 directory.
 .SH OPTIONS
 .TP



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org