Bug#936336: coz-profiler: Python2 removal in sid/bullseye

[Lluís Vilanova]

On Wed, Aug 12, 2020 at 3:27 PM Petter Reinholdtsen  wrote:
> I've managed to fix my key problems, and can do the upload.
>
> Is it ready to go in?

I've pushed a new version for coz, please check
https://salsa.debian.org/coz-team/coz-profiler.

Cheers,
Lluis

Bug#936336: coz-profiler: Python2 removal in sid/bullseye

[Lluís Vilanova]

On Wed, Aug 12, 2020 at 3:27 PM Petter Reinholdtsen  wrote:
> I've managed to fix my key problems, and can do the upload.
>
> Is it ready to go in?

New releases of coz-profiler and libelfin are now available. Let me
prepare an upstream merge and I'll ping back here.

Cheers,
Lluis

Bug#936336: coz-profiler: Python2 removal in sid/bullseye

[Lluís Vilanova]

I pushed some changes to the package repository to solve the bug when
it was opened (should be rebased onto the latest upstream release
now).

Unfortunately I do not have upload privileges and couldn't find
anybody that would keep uploading them for coz.

Bug#851682: emacs25: Re-enable xwidgets on selected builds

[Lluís Vilanova]

Package: emacs25
Version: 25.1+1-3
Severity: wishlist

Bug #843462 [1] disabled emacs' xwidgets feature, but shouldn't the same be
applied to epiphany in debian stable? And doesn't the xwidget feature enable
more than just embedding webkit?

Since debian testing should receive all the updates (including the security
ones), maybe it would make sense to have a build without xwidgets/webkit on all
releases, and another one with xwidgets/webkit only on testing/sid/experimental:

  https://blogs.gnome.org/mcatanzaro/2016/02/01/on-webkit-security-updates/
  (see the "Debian" section)

Sorry for my ignorance if having security updates for the browser-related part
is not the only reason for disabling xwidgets.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843462


Thanks,
  Lluis

Bug#850569: jstest-gtk: Crash for missing data files

[Lluís Vilanova]

James Cowgill writes:

> Control: forcemerge 850022 -1
> Hi,

> On 07/01/17 21:43, Lluís Vilanova wrote:
>> Package: jstest-gtk
>> Version: 0.1.1~git20160825-1
>> Severity: important
>> 
>> Starting jstest-gtk with a PS3 controller connected crashes the application 
>> with
>> the following message:
>> 
>> Error: Failed to open file '/usr/bin/data/PS3.png': No such file or directory

> Duplicate of #850022 (different symptoms but caused by the same bug).

>> If I start the app with a disconnected controller, an unhandled exception 
>> error
>> is shown after connecting the controller and clicking refresh.

> Just to clarify, is this the same message as above (ie not a separate bug)?

Same message, but seems like it's happening inside a signal handler and GTK
catches it to show a report instead of terminating the application:

  unhandled exception (type Glib::Error) in signal handler:
  domain: g-file-error-quark
  code  : 4
  what  : Failed to open file '/usr/bin/data/PS3.png': No such file or directory


Thanks,
  Lluis

Bug#850569: jstest-gtk: Crash for missing data files

[Lluís Vilanova]

Package: jstest-gtk
Version: 0.1.1~git20160825-1
Severity: important

Starting jstest-gtk with a PS3 controller connected crashes the application with
the following message:

  Error: Failed to open file '/usr/bin/data/PS3.png': No such file or directory

If I start the app with a disconnected controller, an unhandled exception error
is shown after connecting the controller and clicking refresh.

It seems like the program is calculating the data path from its main program's
basename. This is useful for running from the build directory, but does not
follow the installation structure (the missing file is installed at
/usr/share/jstest-gtk/data/PS3.png).


Thanks,
  Lluis


-- System Information:
Debian Release: stretch/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.8.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages jstest-gtk depends on:
ii  libatkmm-1.6-1v52.24.2-2
ii  libc6   2.24-8
ii  libcairomm-1.0-1v5  1.12.0-1+b1
ii  libgcc1 1:6.2.1-5
ii  libglibmm-2.4-1v5   2.50.0-1
ii  libgtkmm-2.4-1v51:2.24.5-1
ii  libsigc++-2.0-0v5   2.10.0-1
ii  libstdc++6  6.2.1-5
ii  libx11-62:1.6.4-2

Versions of packages jstest-gtk recommends:
ii  joystick  1:1.6.0-1

jstest-gtk suggests no packages.

-- no debconf information

Bug#848974: ftp.debian.org: override: coz-profiler:devel/optional

[Lluís Vilanova]

Package: ftp.debian.org
Severity: normal

I mis-stated the section due to c in previous releases of the package (was set
to "net", which is incorrect for a program profiling tool).

Thanks!

Bug#844633: coz-profiler: Cannot run build tests (insufficient permissions for perf)

[Lluís Vilanova]

Petter Reinholdtsen writes:

> [Lluís Vilanova]
>> H, with grub2 that's easier to do because it's going to test the
>> bootloader that is the first thing going to start. In our case we'd
>> have to bootstrap a full system and then start it in qemu just to run
>> the test. That doesn't sound feasible to me (time and disk space to
>> run the test), but I might be wrong.

> It is possible to run "foreign" binaries in the current file system
> using qemu.  I have used it with vmdebootstrap to build arm chroots on
> x86.  I tested, and this seem to work when installing qemu-user:

>   qemu-x86_64 /usr/bin/python /usr/bin/coz run --- /bin/ls

> I'm not sure if qemu then start its own kernel or passes through the
> perf syscalls to the underlying kernel.  But I can not test this in
> Jessie:

> # /sbin/sysctl kernel.perf_event_paranoid=3
> kernel.perf_event_paranoid = 3
> # TMPDIR= TEMP= TEMPDIR= TMP= chroot /scratch/chroot-sid su - 
> mesg: ttyname failed: Success
> # qemu-x86_64 /usr/bin/python /usr/bin/coz run --- /bin/ls
> [libcoz.cpp:100] bootstrapping coz
> [libcoz.cpp:128] Including MAIN, which is /bin/ls
> [inspect.cpp:319] Unable to locate debug information for /bin/ls
> [inspect.cpp:325] /lib/x86_64-linux-gnu/ld-2.24.so is not in scope
> [inspect.cpp:325] /usr/lib/coz-profiler/libcoz.so is not in scope
> [inspect.cpp:325] /lib/x86_64-linux-gnu/libselinux.so.1 is not in scope
> [inspect.cpp:325] /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.22 is not in 
> scope
> [inspect.cpp:325] /lib/x86_64-linux-gnu/libm-2.24.so is not in scope
> [inspect.cpp:325] /lib/x86_64-linux-gnu/libgcc_s.so.1 is not in scope
> [inspect.cpp:325] /lib/x86_64-linux-gnu/libpthread-2.24.so is not in scope
> [inspect.cpp:325] /lib/x86_64-linux-gnu/libpcre.so.3.13.3 is not in scope
> [inspect.cpp:325] /lib/x86_64-linux-gnu/libdl-2.24.so is not in scope
> [inspect.cpp:325] /lib/x86_64-linux-gnu/librt-2.24.so is not in scope
> [inspect.cpp:325] /usr/lib/x86_64-linux-gnu/libelf++.so.0 is not in scope
> [inspect.cpp:325] /usr/lib/x86_64-linux-gnu/libdwarf++.so.0 is not in scope
> [inspect.cpp:325] /lib/x86_64-linux-gnu/libc-2.24.so is not in scope
> [profiler.cpp:75] Starting profiler thread
> profile.coz
> # /sbin/sysctl kernel.perf_event_paranoid  
> kernel.perf_event_paranoid = 3
> # logout
> #

> At least the value is inherited into qemu.

> But if we can not get this to work before Christmas, we should probably
> rewrite the test to only test if the value of kernel.perf_event_paranoid
> is 2 or lower.

When qemu runs user applications, it simply forwards system calls to the host
kernel (it does a bit more than that, but that's the basic idea). If we want to
be able to control perf's configuration, we have to run a full-blown system in
qemu (i.e., a VM).

Building a VM image every time coz is built is what I do not consider feasible
(although it is perfectly doable).

The poor man's solution is to do as you suggested. If perf's configuration is
insufficient, barf at the user and exit, but do not return any error code.

Bug#844633: coz-profiler: Cannot run build tests (insufficient permissions for perf)

[Lluís Vilanova]

Petter Reinholdtsen writes:

> [Petter Reinholdtsen]
>> What options do we have?  I can think of two: (1) Stop verifying during
>> build that coz when the kernel prohibits it or (2) find another way to
>> test coz during build that do not involve the kernel perf interface.
>> Any other ideas?

> I asked about this on #debian-release, and a third option came up.
> Change the build time testing to use qemu and enable the perf interface
> there.  I do not know how to do this, but they suggested to check out
> other packages doing this by searching for them using
> https://codesearch.debian.net/search?q=qemu+path%3A%2Fdebian%2Frules >.
> Look like at least grub2 is doing this.

> Lluís, do you have time to check this out?

H, with grub2 that's easier to do because it's going to test the bootloader
that is the first thing going to start. In our case we'd have to bootstrap a
full system and then start it in qemu just to run the test. That doesn't sound
feasible to me (time and disk space to run the test), but I might be wrong.

Bug#844633: coz-profiler: Cannot run build tests (insufficient permissions for perf)

[Lluís Vilanova]

I've made a pull request to upstream that makes coz be more informative about
that error:

  https://github.com/plasma-umass/coz/pull/86

Cheers,
  Lluis

Bug#844633: coz-profiler: Cannot run build tests (insufficient permissions for perf)

[Lluís Vilanova]

Petter Reinholdtsen writes:

> [Lluís Vilanova]
>> The package currently fails to run its tests during build due to
>> insufficient permissions to access Linux's perf interface.

> Is there some way to figure out if such permissions are missing or not?

> On my machine, where the build work, the value of 
> /proc/sys/kernel/perf_event_paranoid is '1', so '0' is not required.

> I notice the autobuilders work, the ci.debian.org builders work, but the
> reproducable build builders do not.  No idea what the difference is.

I've rechecked, and things seem to be a bit different...

For some reason my kernel (4.7.0-1-amd64) ignores changes through the file
system. It's more reliable to use:

  /sbin/sysctl kernel.perf_event_paranoid
  sudo /sbin/sysctl kernel.perf_event_paranoid=

Now, I've tried on a nother machine, and (strangely) the kernel starts with a
perf paranoid level of 3, which is not even documented as a valid value on
Linux's source code.

Getting it down to 2 is sufficient to run the check successfully.

A possible check could be:

  if [ `/sbin/sysctl kernel.perf_event_paranoid` -gt 2 ]; then
  echo "ERROR: perf is too paranoid for us"
  exit 1
  fi

This would build-depend on procps (which installs sysctl).

Cheers,
  Lluis

Bug#844633: coz-profiler: Cannot run build tests (insufficient permissions for perf)

[Lluís Vilanova]

Package: coz-profiler
Version: 0.0.git.20161011T1320-3
Severity: normal

The package currently fails to run its tests during build due to insufficient
permissions to access Linux's perf interface.

There's three ways to solve this:

* running the checks as root
* granting CAP_SYS_ADMIN to the user running the checks
* configuring perf's paranoid level: sudo sh -c 'echo 0 
>/proc/sys/kernel/perf_event_paranoid'

Something I have not yet checked is if there is a subset of the interface,
sufficient for coz, that will provide the profiling information without
additional permissions.


Cheers,
  Lluis

Bug#839615: libelfin: Library do not work with clang

[Lluís Vilanova]

Petter Reinholdtsen writes:

> I found interesting comments regarding this in
> http://allanmcrae.com/2015/06/the-case-of-gcc-5-1-and-the-two-c-abis/ >
> and https://llvm.org/bugs/show_bug.cgi?id=23529 >.

> Apparently clang do not understand a new gcc invention, the API tag,
> which is inserted in symbols build using -std=c++11.

> According to
>  https://www.reddit.com/r/cpp/comments/442b38/clang_38_gcc_53_incompatibilities/
>  >,
> We might get it working by building the library using
> --with-defualt-libstdcxx-abi=gcc4-compatible to avoid the problem, or
> perhaps we need -D_GLIBCXX_USE_CXX11_ABI=0.  More testing is needed.

AFAIU the "--with-defualt-libstdcxx-abi=gcc4-compatible" is a gcc configure flag
that enables it to produce code with multiple ABIs. The
"-D_GLIBCXX_USE_CXX11_ABI=0" then tells gcc to produce C++0x code with the old
(incompatible with the standard) ABI.

The main problem is that CLang invariably produces code with the gcc's old C++0x
ABI, and only "recently" accepted a patch to accept the new ABI names used by
glibc (as compiled with gcc) [1]. Therefore, I (like [2]) would advise against
compiling any library with the old ABI, and wait for debian to pack a newer
CLang release with that patch.

[1] https://llvm.org/bugs/show_bug.cgi?id=23529
[2] https://wiki.debian.org/GCC5
"To build code with gcc-5 which is compatible with the old ABI, define the
macro _GLIBCXX_USE_CXX11_ABI to 0 before including any C++ standard library
headers. Should only be used for leaf packages, not for libraries as a last
resort."


Cheers,
  Lluis

Bug#837697: systemtap: Arguments of user probes are always (incorrectly) zero

[Lluís Vilanova]

Frank Ch Eigler writes:

> Hi, Lluís -
>> I've attached both. BTW, I'm using debian's gcc 6.1.1-1.

> Thank you.  Those both look just fine, argh.  Could you try using
> gdb's "static probe points" facility to break at the same point, to
> see if the arguments are accessible?

> https://sourceware.org/gdb/onlinedocs/gdb/Static-Probe-Points.html

> Maybe provide a disassembly of the two functions of that binary, just
> to confirm that the numeric parameters are being passed?

Everything seems correct (gdb 7.11.1-2), so either the kernel or systemtap are
garbling up the arguments when retrieving them, or systemtap gets confused and
gets them from the wrong place.

$ gdb ./test
(gdb) break main
(gdb) run
Starting program: /home/lluis/tmp/systemtap/test 

Breakpoint 3, main (argc=1, argv=0x7fffe168) at test.c:12
12  f(1, 1);

# just in case, I made sure the program is loaded

(gdb) disassemble main
Dump of assembler code for function main:
   0x0040050f <+0>: push   %rbp
   0x00400510 <+1>: mov%rsp,%rbp
   0x00400513 <+4>: sub$0x10,%rsp
   0x00400517 <+8>: mov%edi,-0x4(%rbp)
   0x0040051a <+11>:mov%rsi,-0x10(%rbp)
=> 0x0040051e <+15>:mov$0x1,%esi
   0x00400523 <+20>:mov$0x1,%edi
   0x00400528 <+25>:callq  0x4004e6 
   0x0040052d <+30>:mov$0x2,%esi
   0x00400532 <+35>:mov$0x2,%edi
   0x00400537 <+40>:callq  0x4004e6 
   0x0040053c <+45>:mov$0x0,%eax
   0x00400541 <+50>:leaveq 
   0x00400542 <+51>:retq   
(gdb) disassemble f
Dump of assembler code for function f:
   0x004004e6 <+0>: push   %rbp
   0x004004e7 <+1>: mov%rsp,%rbp
   0x004004ea <+4>: sub$0x10,%rsp
   0x004004ee <+8>: mov%edi,-0x4(%rbp)
   0x004004f1 <+11>:mov%esi,-0x8(%rbp)
   0x004004f4 <+14>:nop
   0x004004f5 <+15>:mov-0x8(%rbp),%edx
   0x004004f8 <+18>:mov-0x4(%rbp),%eax
   0x004004fb <+21>:mov%eax,%esi
   0x004004fd <+23>:mov$0x4005d4,%edi
   0x00400502 <+28>:mov$0x0,%eax
   0x00400507 <+33>:callq  0x4003c0 
   0x0040050c <+38>:nop
   0x0040050d <+39>:leaveq 
   0x0040050e <+40>:retq   
(gdb) info probes
Type Provider Name Where  Semaphore  Object 

stap test f0x004004f4 0x00600988 
/home/lluis/tmp/systemtap/test 
(gdb) enable probes test
Probe test:f cannot be enabled.
(gdb) b -probe test:f
Breakpoint 1 at 0x4004f4
(gdb) info b
Num Type   Disp Enb AddressWhat
1   breakpoint keep y   0x004004f4 -probe test:f
(gdb) c
Continuing.

Breakpoint 1, f (a1=1, a2=1) at test.c:6
6   TEST_F(a1, a2);
(gdb) p $rsi
$1 = 1
(gdb) p $rdi
$2 = 1
(gdb) c
Continuing.
a1=1 a2=1

Breakpoint 1, f (a1=2, a2=2) at test.c:6
6   TEST_F(a1, a2);
(gdb) p $rsi
$3 = 2
(gdb) p $rdi
$4 = 2
(gdb) c
Continuing.
a1=2 a2=2
[Inferior 1 (process 30372) exited normally]


Thanks,
  Lluis

Bug#837697: systemtap: Arguments of user probes are always (incorrectly) zero

[Lluís Vilanova]

Frank Ch Eigler writes:

> Hi -
>> $ cat >test.c <<\EOF
>> [...]
>> int f(int a1, int a2)
>> {
>> TEST_F(a1, a2);
>> [...]
>> }
>> 
>> int main(int argc, char *argv[])
>> {
>> f(1, 1);
>> f(2, 2);
>> return 0;
>> }
>> EOF
>> [...]
>> $ gcc -o test -O0 -g test.c events.o
>> $ sudo stap test.stp -c './test'
>> [...]
>> 0 0
>> 0 0

> It would be interesting to see the "stap -p3" output for that test
> script, and/or the "readelf -n ./test", so we could tell what kind of
> operands the compiler generated for those two arguments.

I've attached both. BTW, I'm using debian's gcc 6.1.1-1.

Cheers,
  Lluis



stap-p3
Description: Binary data


readelf-n
Description: Binary data

Bug#837697: systemtap: Arguments of user probes are always (incorrectly) zero

[Lluís Vilanova]

Vincent Bernat writes:

>  ❦ 13 septembre 2016 19:10 CEST, Lluís Vilanova <vilan...@ac.upc.edu> :
>> Hi! I've been writing some very simple systemtap scripts, and printing the
>> values of arguments to user-defined probe marks always shows zeroes.
>> 
>> Here's an minimal failing example:
>> 
>> $ cat >events.d <<\EOF
>> provider test
>> {
>> probe f(int a1, int a2);
>> };
>> EOF
>> 
>> $ cat >test.c <<\EOF
>> #include 
>> #include "events.h"
>> 
>> int f(int a1, int a2)
>> {
>> TEST_F(a1, a2);
>> printf("a1=%d a2=%d\n", a1, a2);
>> }
>> 
>> int main(int argc, char *argv[])
>> {
>> f(1, 1);
>> f(2, 2);
>> return 0;
>> }
>> EOF
>> 
>> $ dtrace -s events.d -G
>> $ dtrace -s events.d -h
>> $ gcc -o test -O0 -g test.c events.o
>> $ sudo stap test.stp -c './test'
>> a1=1 a2=1
>> a1=2 a2=2
>> hello
>> 0 0
>> 0 0

> You didn't provide the test.stp script. I suppose this is something like:

> probe process.begin {
>   printf("hello\n");
> }
> probe process("./test").mark("f") {
>   printf("%d %d\n", $arg1, $arg2);
> }

That's exactly it, sorry.


>> Bug #691167 should no longer be applicable, since I'm running a stock debian
>> kernel (4.7) with UPROBES enabled:

> It's odd that you succeed in compiling anything with 4.7 as it needs a
> patch to work. I am uploading an updated version with this patch:
>  
> https://sourceware.org/git/gitweb.cgi?p=systemtap.git;a=commitdiff;h=8f888904d8de9a798e4664caa373ea552366b304;hp=79be36dbc39d25270261b857e51edbc198f204d7

> With this patch applied, I can compile your example and I get:

> a1=1 a2=1
> a1=2 a2=2
> hello
> hello
> 1 1
> 2 2

Sorry, I said 4.7 from the top of my head, but I was in fact testing with
debian's 4.6. But I do remember patching "transport.c" to compile scripts with
my locally built 4.8.0-rc5 (same patch needed for 4.7).

I just re-tested with 4.6 and it's failing. I also re-checked my local
"transport.c" patch (I'm checking against LINUX_VERSION_CODE) and re-tested with
debian's 4.7, and I'm still getting the "all zeroes" error.


Thanks,
  Lluis

Bug#837697: systemtap: Arguments of user probes are always (incorrectly) zero

[Lluís Vilanova]

Package: systemtap
Version: 3.0-6
Severity: normal

Hi! I've been writing some very simple systemtap scripts, and printing the
values of arguments to user-defined probe marks always shows zeroes.

Here's an minimal failing example:

$ cat >events.d <<\EOF
provider test
{
probe f(int a1, int a2);
};
EOF

$ cat >test.c <<\EOF
#include 
#include "events.h"

int f(int a1, int a2)
{
TEST_F(a1, a2);
printf("a1=%d a2=%d\n", a1, a2);
}

int main(int argc, char *argv[])
{
f(1, 1);
f(2, 2);
return 0;
}
EOF

$ dtrace -s events.d -G
$ dtrace -s events.d -h
$ gcc -o test -O0 -g test.c events.o
$ sudo stap test.stp -c './test'
a1=1 a2=1
a1=2 a2=2
hello
0 0
0 0


While the printf's show correct values for a1 and a2, the stap script always
shows zeroes. Executing as a regular use (on the stapdev and stapusr groups)
shows the same errors.

Bug #691167 should no longer be applicable, since I'm running a stock debian
kernel (4.7) with UPROBES enabled:

$ grep UPROBES /boot/config-*
/boot/config-3.16.0-4-amd64:CONFIG_ARCH_SUPPORTS_UPROBES=y
/boot/config-3.16.0-4-amd64:CONFIG_UPROBES=y
/boot/config-4.6.0-1-amd64:CONFIG_ARCH_SUPPORTS_UPROBES=y
/boot/config-4.6.0-1-amd64:CONFIG_UPROBES=y
/boot/config-4.7.0-1-amd64:CONFIG_ARCH_SUPPORTS_UPROBES=y
/boot/config-4.7.0-1-amd64:CONFIG_UPROBES=y
/boot/config-4.8.0-rc5:CONFIG_ARCH_SUPPORTS_UPROBES=y
/boot/config-4.8.0-rc5:CONFIG_UPROBES=y

I've also tried to compile the latest linux kernel version (4.8.0-rc5, vanilla
upstream) and the failure is still the same.



Thanks,
  Lluis


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), 
(500, 'stable'), (250, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.8.0-rc5 (SMP w/4 CPU cores)
Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages systemtap depends on:
ii  libavahi-client3   0.6.32-1
ii  libavahi-common3   0.6.32-1
ii  libc6  2.23-5
ii  libdw1 0.166-2
ii  libelf10.166-2
ii  libgcc11:6.1.1-11
ii  libnspr4   2:4.12-2
ii  libnss32:3.25-1
ii  libsqlite3-0   3.14.1-1
ii  libstdc++6 6.1.1-11
ii  make   4.1-9
ii  systemtap-common   3.0-6
ii  systemtap-runtime  3.0-6

systemtap recommends no packages.

Versions of packages systemtap suggests:
pn  systemtap-doc  
pn  vim-addon-manager  

-- no debconf information

Bug#746643: Manual fix

[Lluís Vilanova]

This seems to be a manual work-around:

  cd /usr/src/nvidia-current-331.67
  make
  cp Module.symvers uvm/
  make -C uvm
  cp uvm/nvidia-uvm.ko /lib/modules/`uname -r`/updates/dkms

Cheers!


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

Bug#721342: Any news?

[Lluís Vilanova]

Is there any news regarding the packaging of autolatex? Can I help on something
even though I'm not a developer of the package nor a debian member?

Thanks,
  Lluis


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

Bug#684731: Fix found

[Lluís Vilanova]

Hilmar Preusse writes:

 On 06.11.13 Lluís Vilanova (vilan...@ac.upc.edu) wrote:
 Hi,

 Sorry, I was not aware you're the maintainer. BTW, is it just me or
 upstream rubber (https://launchpad.net/rubber) has been dead for a
 long time?
 
 I don't really see a real active development in upstream.

 I've contacted some bug submitters for rubber and asked them for some
 details regarding their reports and got the answer I don't use
 rubber any more. If you look at http://www.arakhne.org/autolatex/
 you see that there a few more tools on the market and at least one
 seems to be better than rubber.

 I'm not sure if I'd recommend rubber to anybody.

Mmmm, thanks for the pointer. I didn't know about these alternatives; I will
consider switching to autolatex.

Thanks again,
  Lluis


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

Bug#684731: Fix found

[Lluís Vilanova]

Hilmar Preusse writes:
 On 04.11.13 Lluís Vilanova (vilan...@ac.upc.edu) wrote:
 Please consider packaging the fix for this bug
 (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684731#25).
 
 As you know, I've packaged the fix already and have a package ready
 for upload. However there are a few other bugs in the queue, which
 have patches. I'd like to fix them too in next upload.

Sorry, I was not aware you're the maintainer. BTW, is it just me or upstream
rubber (https://launchpad.net/rubber) has been dead for a long time?

Thanks for your work!


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

Bug#684731: Fix found

[Lluís Vilanova]

Please consider packaging the fix for this bug
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684731#25).

Thanks,
  Lluis


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

Bug#684731: Fix found

[Lluís Vilanova]

Please consider adding the patch in [1] (plain diff available at [2]). Although
it would be nice, I suppose it's not going to make it into stable :)

[1] https://code.launchpad.net/~lluis.vilanova/rubber/816470
[2] 
https://code.launchpad.net/~lluis.vilanova/rubber/816470/+merge/162076/+preview-diff/+files/preview.diff


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

Bug#684731: Fix found

[Lluís Vilanova]

Hilmar Preusse writes:
 Many thanks! I've put new packages here:
 http://wagner.debian.org/~hilmar-guest/rubber/

 Let me know if it solves your problem.

Works like a charm for me, although I suppose you meant to ask if it works for
other people too :)

Thanks


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

Bug#684731: Duplicates in launchpad

[Lluís Vilanova]

This bug has some duplicates in Launchpad, all of which can be reached from this
one:

  https://bugs.launchpad.net/rubber/+bug/816470


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

Bug#684731: Duplicates in launchpad

[Lluís Vilanova]

This bug has some duplicates in Launchpad, all of which can be reached from this
one:

  https://bugs.launchpad.net/rubber/+bug/816470


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

Bug#684731: rubber: Broken image conversion

[Lluís Vilanova]

Package: rubber
Version: 1.1+20100306-1
Severity: important

I've attached a tarball with a minimal example that shows the failure.

First, rubber is unable to use more than 1 rule for converting an image (dia -
eps - pdf). This has not been working for quite some time, so this is probably
not the place to discuss it (besides, I have some rules of my own to fix that).

The new breakage appears to incorrectly infer the source and destination paths
for files (example building article.ps):

  `here' is `/home/lluis/Projects/rubber-test/here.eps', made from 
`/home/lluis/Projects/rubber-test/here.dia' by rule `dia'
  `here2' is `/home/lluis/Projects/rubber-test/here2.eps', made from 
`/home/lluis/Projects/rubber-test/here.dia' by rule `dia'
  `there' is `/home/lluis/Projects/rubber-test/there.eps', made from 
`/home/lluis/Projects/rubber-test/here.dia' by rule `dia'

As you can see, 'here2' is produces from the wrong source, and 'there2' should
be found in the 'figures/' subdir when scanning the 'graphicspath' directive in
the article.

To be honest, I don't know when this broke, but makes rubber quite unusable at
least for me.

I tried to follow the error, and it looks like the routine doing the path
expansion returns incorrect results.

I've attached a simple example that exemplifies the error.


Thanks,
  Lluis


-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'testing-proposed-updates'), (500, 
'unstable'), (250, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=ca_ES.utf8, LC_CTYPE=ca_ES.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages rubber depends on:
ii  dpkg1.16.4.3
ii  install-info4.13a.dfsg.1-10
ii  python  2.7.3~rc2-1
ii  python-support  1.0.15
ii  texlive-latex-base  2012.20120611-3

rubber recommends no packages.

Versions of packages rubber suggests:
ii  imagemagick  8:6.7.7.10-3
ii  sam2p0.49.1-1
ii  transfig 1:3.2.5.d-3

-- no debconf information



rubber-test.tgz
Description: application/gtar-compressed

Bug#580733: Please close

[Lluís Vilanova]

Please close this bug, as the 23.2 version already exists in stable.



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