Bug#902897: virtualbox broken by binutils master (new R_X86_64_PLT32 relocation type)

2018-07-12 Thread Volker Christian
I can confirm that the virtual machines start again with this fix!

Thank you very much!

Volker

On Donnerstag, 12. Juli 2018 10:52:59 CEST Gianfranco Costamagna wrote:
> Hello,
> 
> 
> >VMMR0.r0 has been built (presumably due to the recent binutils upgrades in 
> >unstable) with the new PLT32 relocation type, which the virtualbox ELF 
> >relocation >code cannot handle at the moment. Having a quick glance at .text 
> >and .rela.text of VMMR0.r0, it seems to me that PC32 and PLT32 can be 
> >handled identically, >similar to what commit b21ebf2fb4cd of the Linux 
> >kernel did?
> 
> 
> I really liked the analysis, the linux commit and the binutils stuff, I 
> crafted a patch based on this comment, and uploaded in unstable
> 
> If anybody wants to test the "fix", please grab the deb files from there
> http://debomatic-amd64.debian.net/distribution#unstable/virtualbox/5.2.14-dfsg-2/buildlog
> 
> 
> or wait some hours for the package to appear on unstable repositories/mirrors.
> 
> I'm not sure if this causes regressions or whatever else, the assumption 
> "they might behave in the same way" might not apply as it did in the kernel,
> even if my basic tests confirmed the VM to start.
> 
> Use at your own risk, like everything that comes from unstable, the urgency 
> is set to low, so I presume we will have 10 days of people testing this before
> going in buster.
> 
> thanks you all, I also submitted the patch to upstream mail list and irc for 
> review
> 
> G.
> 
> 



Bug#902897: virtualbox: fails to start vm (VERR_LDRELF_RELOCATION_NOT_SUPPORTED)

2018-07-03 Thread Volker Christian
Hi Gianfranco!

Here is the log - Tobias also provided a log already, see 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902897#15 

VirtualBox VM 5.2.14_Debian r122571 linux.amd64 (Jul  2 2018 17:50:29) release 
log
00:00:00.983105 Log opened 2018-07-03T08:34:32.706029000Z
00:00:00.983106 Build Type: release
00:00:00.983109 OS Product: Linux
00:00:00.983110 OS Release: 4.14.32-voc
00:00:00.983110 OS Version: #1 SMP Fri Apr 6 12:36:37 CEST 2018
00:00:00.983127 DMI Product Name: HP ZBook 15 G2
00:00:00.983132 DMI Product Version: A3008CD10003
00:00:00.983169 Host RAM: 7896MB (7.7GB) total, 3941MB (3.8GB) available
00:00:00.983173 Executable: /usr/lib/virtualbox/VirtualBox
00:00:00.983174 Process ID: 23905
00:00:00.983174 Package type: LINUX_64BITS_GENERIC (OSE)
00:00:00.987436 Installed Extension Packs:
00:00:00.987451   Oracle VM VirtualBox Extension Pack (Version: 5.2.14 r123301; 
VRDE Module: VBoxVRDP)
00:00:00.987459   VNC (Version: 5.2.14 r122571; VRDE Module: VBoxVNC)
00:00:00.989502 Console: Machine state changed to 'Starting'
00:00:00.989614 Qt version: 5.10.1
00:00:00.989621 X11 Window Manager code: 3
00:00:00.997829 GUI: UIMediumEnumerator: Medium-enumeration finished!
00:00:00.998302 X Server details: vendor: The X.Org Foundation, release: 
1200, protocol version: 11.0, display string: :0
00:00:00.998309 Using XKB for keycode to scan code conversion
00:00:00.999889 SUP: RTLdrGetBits failed for VMMR0.r0 
(/usr/lib/virtualbox/VMMR0.r0). rc=VERR_LDRELF_RELOCATION_NOT_SUPPORTED
00:00:00.19 PDMLdr: pdmR3LoadR0U: pszName="VMMR0.r0" 
rc=VERR_LDRELF_RELOCATION_NOT_SUPPORTED szErr="RTLdrGetBits failed"
00:00:00.41 VMSetError: 
/build/virtualbox-5ojW2E/virtualbox-5.2.14-dfsg/src/VBox/VMM/VMMR3/PDMLdr.cpp(731)
 int pdmR3LoadR0U(PUVM, const char*, const char*, const char*); 
rc=VERR_LDRELF_RELOCATION_NOT_SUPPORTED
00:00:00.44 VMSetError: Failed to load R0 module 
/usr/lib/virtualbox/VMMR0.r0: RTLdrGetBits failed
00:00:00.54 VMSetError: 
/build/virtualbox-5ojW2E/virtualbox-5.2.14-dfsg/src/VBox/VMM/VMMR3/VM.cpp(598) 
int vmR3CreateU(PUVM, uint32_t, PFNCFGMCONSTRUCTOR, void*); 
rc=VERR_LDRELF_RELOCATION_NOT_SUPPORTED
00:00:00.56 VMSetError: Failed to load VMMR0.r0
00:00:01.33 ERROR [COM]: aRC=NS_ERROR_FAILURE (0x80004005) 
aIID={872da645-4a9b-1727-bee2-5585105b9eed} aComponent={ConsoleWrap} 
aText={Failed to load R0 module /usr/lib/virtualbox/VMMR0.r0: RTLdrGetBits 
failed (VERR_LDRELF_RELOCATION_NOT_SUPPORTED).
00:00:01.40 Failed to load VMMR0.r0 
(VERR_LDRELF_RELOCATION_NOT_SUPPORTED)}, preserve=false aResultDetail=0
00:00:01.001021 Console: Machine state changed to 'PoweredOff'
00:00:01.007998 GUI: 
UIDesktopWidgetWatchdog::sltHandleHostScreenAvailableGeometryCalculated: Screen 
0 work area is actually resized to: 0x0 x 3200x1732
00:00:01.008350 Power up failed (vrc=VERR_LDRELF_RELOCATION_NOT_SUPPORTED, 
rc=NS_ERROR_FAILURE (0X80004005))
00:00:01.509022 GUI: UIMachineViewNormal::resendSizeHint: Restoring guest 
size-hint for screen 0 to 3180x1585
00:00:01.509084 ERROR [COM]: aRC=E_ACCESSDENIED (0x80070005) 
aIID={76eed314-3c72-4bbb-95cf-5eb4947a4041} aComponent={DisplayWrap} aText={The 
console is not powered up}, preserve=false aResultDetail=0
00:00:01.509155 GUI: UIMachineViewNormal::resendSizeHint: Restoring guest 
size-hint for screen 1 to 640x480
00:00:01.509175 ERROR [COM]: aRC=E_ACCESSDENIED (0x80070005) 
aIID={76eed314-3c72-4bbb-95cf-5eb4947a4041} aComponent={DisplayWrap} aText={The 
console is not powered up}, preserve=false aResultDetail=0
00:00:01.509225 GUI: Aborting startup due to power up progress issue detected...


Volker

On Dienstag, 3. Juli 2018 10:54:27 CEST you wrote:
> 
> >I am affected by this bug too!
> >
> >
> >On Tue, 03 Jul 2018 10:08:05 +0200 Christian Marillat  
> >wrote:
> >
> > Hi,
> >
> 
> 
> and nobody is providing logs?
> 
> G.
> 


Bug#902897: virtualbox: fails to start vm (VERR_LDRELF_RELOCATION_NOT_SUPPORTED)

2018-07-03 Thread Volker Christian
I am affected by this bug too!

On Tue, 03 Jul 2018 10:08:05 +0200 Christian Marillat  wrote:
> Hi,
> 
> I see also the same bug.
> 
> Christian
> 
> 



Bug#472631: cups-pdf: typo in config file

2008-03-25 Thread Volker Christian Behr
Thanks for the information. The typo will be fixed upstream with release
2.4.8

Regards,
Volker Behr

On Tue, 2008-03-25 at 10:02 -0300, Alvaro Herrera wrote:
 Package: cups-pdf
 Version: 2.4.6-5
 Severity: minor
 
 
 In /etc/cups/cups-pdf.conf, the description of the Cut parameter says
 is not longer than Out -- it should read is not longer than Cut.
 
 -- System Information:
 Debian Release: lenny/sid
   APT prefers testing
   APT policy: (990, 'testing'), (500, 'unstable')
 Architecture: amd64 (x86_64)
 
 Kernel: Linux 2.6.24-1-amd64 (SMP w/2 CPU cores)
 Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/bash
 
 Versions of packages cups-pdf depends on:
 ii  cupsys   1.3.6-2 Common UNIX Printing System(tm) 
 - 
 ii  cupsys-client1.3.6-2 Common UNIX Printing System(tm) 
 - 
 ii  gs-esp   8.15.3.dfsg.1-1 The Ghostscript PostScript 
 interpr
 ii  gs-gpl   8.56.dfsg.1-1.1 The GPL Ghostscript PostScript 
 int
 ii  libc62.7-6   GNU C Library: Shared libraries
 ii  libpaper-utils   1.1.23  library for handling paper 
 charact
 
 cups-pdf recommends no packages.
 
 -- no debconf information
-- 

Volker Christian Behr
Experimentelle Physik V (Biophysik), Physikalisches Institut
Universitaet Wuerzburg, Am Hubland, 97074 Wuerzburg, Germany

Office: Room F-069a
+49-931-888-5766 (phone)
+49-931-888-5851 (fax)





-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#425405: Impossible to do research in PDF documents

2007-05-21 Thread Volker Christian Behr
Hi, this is upstream,

I can reproduce this issue if you use exotic fonts in OpenOffice. Using
Arial for example the output is perfectly searchable by a PDF-viewer.

I have to check why GS does not simply replace the font by some other it
knows (or what exactly is causing the issue, if not the font unknown to
GS).

Martin-Eric, could you please re-tag this to 'wishlist' since it
technically is not a bug in CUPS-PDF (CUPS-PDF working as designed) but
rather in the conversion done by GS (maybe some additional option will
help).

Regards,

Volker


On Mon, 2007-05-21 at 16:14 +0200, Valerio Passini wrote:
 Package: cups-pdf
 Version: 2.4.2-3
 Severity: important
 
 
 
 Hi All,
 
 I have found that the pdf output from cups-pdf is 
 perfectely
 readable but you cannot perform researches in it (i.e: if 
 in the document is present the word donald and you 
 search for it there is no result (tested with kpdf and 
 Acrobat Reader). I've done this trial using an openoffice 
 document and converting it using both cups-pdf and the 
 internal pdf converter of OpenOffice.org. The output from 
 openoffice
 works while that from cups-pdf has this problem. This bug 
 is really annoying with indexing programs and when you 
 have large documents.
 Bye
 
 Valerio
 
 -- System Information:
 Debian Release: lenny/sid
APT prefers unstable
APT policy: (700, 'unstable'), (600, 'testing'), (1, 
 'experimental')
 Architecture: i386 (i686)
 
 Kernel: Linux 2.6.20.11 (PREEMPT)
 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] 
 (charmap=ISO-8859-15)
 Shell: /bin/sh linked to /bin/bash
 
 Versions of packages cups-pdf depends on:
 ii  cupsys   1.2.11-2Common UNIX 
 Printing System(tm) -
 ii  gs-esp   8.15.3.dfsg.1-1 The 
 Ghostscript PostScript interpr
 ii  libc62.5-7   GNU C 
 Library: Shared libraries
 
 cups-pdf recommends no packages.
 
 -- no debconf information
-- 

Volker Christian Behr
Experimentelle Physik V (Biophysik), Physikalisches Institut
Universitaet Wuerzburg, Am Hubland, 97074 Wuerzburg, Germany

Office: Room F-069a
+49-931-888-5766 (phone)
+49-931-888-5851 (fax)




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#425405: Impossible to do research in PDF documents

2007-05-21 Thread Volker Christian Behr
On Mon, 2007-05-21 at 22:20 +0300, =?UTF-8?Q? Martin-=C3=89ric?= Racine
wrote:
 On 5/21/07, Volker Christian Behr [EMAIL PROTECTED] wrote:
  Hi, this is upstream,
 
  I can reproduce this issue if you use exotic fonts in OpenOffice. Using
  Arial for example the output is perfectly searchable by a PDF-viewer.
 
  I have to check why GS does not simply replace the font by some other it
  knows (or what exactly is causing the issue, if not the font unknown to
  GS).
 
  Martin-Eric, could you please re-tag this to 'wishlist' since it
  technically is not a bug in CUPS-PDF (CUPS-PDF working as designed) but
  rather in the conversion done by GS (maybe some additional option will
  help).
 
 Volker, since this is strictly-speaking a GS bug, I'm wondering if
 reassigning it to GS might make more sense?
 
 However, one part of the report attracted my attention: the user
 successfully creates searchable documents when exporting to PDF
 directly in OpenOffice.  I wonder how their PDF implementation differs
 from the one used by CUPS?
 
If they implement the PDF generation directly into OpenOffice, they
won't run into any unknown-font-issues as I tested: CUPS-PDF creates
perfectly searchable documents when a font like Arial is used.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#411620: changing init string to Virtual PDF Printer (CUPS-PDF)

2007-05-05 Thread Volker Christian Behr
Hello Martin-Éric,

On Sat, 2007-05-05 at 18:19 +0300, =?UTF-8?Q? Martin-=C3=89ric?= Racine
wrote:
 Greetings Volker,
 
 Now that Etch is released, I'm returning to packaging newer CUPS-PDF versions.
 
 I was wondering if you have already changed this string since version
 2.4.2 was issued?
 

the identification string was changed in version 2.4.5 .

Cheers,
Volker





Bug#421868: cups-pdf: gs hangs eating all memory when printing certain files

2007-05-04 Thread Volker Christian Behr
In CUPS-PDF release 2.4.6 the new options are in place.

On Wed, 2007-05-02 at 13:17 +0200, Volker Christian Behr wrote:
 Hi, this is upstream -
 
 I agree with Martin-Éric that you should definitely file this bug
 against gs-esp, too, since this is where the problem originates.
 
 Nevertheless thanks for this hint at the gs options. I will review them
 and change the CUPS-PDF defaults accordingly where necessary.
 
 Volker
 
 
 On Wed, 2007-05-02 at 11:28 +0300, =?UTF-8?Q? Martin-=C3=89ric?= Racine
 wrote:
  Thanks for your report.
  
  Critical: causes serious data loss, or introduces a security hole on
  systems where you install the package.
  
  Did the above issue introduce a security hole or cause serious data loss?
  I seriously doubt that it did. Thus, I'm bringing severity down to 
  important.
  
  PS: I would tremendously appreciate it if you filed a bug against
  gs-esp for this issue, as this seems to be where the real problem is.
  Thanks!
  
  On 5/2/07, Christopher Zimmermann [EMAIL PROTECTED] wrote:
   Package: cups-pdf
   Version: 2.4.2-3
   Severity: critical
   Tags: patch
   Justification: breaks the whole system
  
   Hi!
  
   When printing certain files via cups-pdf, gs runs forever using all cpu
   and slowly eating all memory. In consequence the system becomes
   unresponsive after a few seconds and therefore unusable.
   If you think this bug is not critical, please tell me, so I know better
   next time.
   A typical example in our environment would be a MS Excel user printing
   to the cups-pdf printer using dim borderlines. If you'd like an example
   .ps file I can provide one.
   Actually this seems to be a bug in gs-esp, but since I managed to fix it
   in cups-pdf, I file it against cups-pdf.
  
   I could fix it by adding -c .setpdfwrite in the config:
   GSCall %s -q -dCompatibilityLevel=%s -dNOPAUSE -dBATCH -dSAFER 
   -sDEVICE=pdfwrite -sOutputFile=%s -dAutoRotatePages=/PageByPage 
   -dAutoFilterColorImages=false -dColorImageFilter=/FlateEncode 
   -dPDFSETTINGS=/prepress -c .setpdfwrite -f %s
  
   I removed the -c save pop, since /usr/share/doc/gs-esp/Use.htm
   [Improving Performance] suggests that it is not needed.
  
   I don't really understand why this fix works and probably this has to be
   fixed in gs, too. But the default of gs should be changed anyway as far
   as I understand the -c .setpdfwrite option.
   I don't think it is the same bug as #267423 since for me gs never
   finishes.
  
  
   Kind Regards,
  
   Christopher Zimmermann
  
-- 

Volker Christian Behr
Experimentelle Physik V (Biophysik), Physikalisches Institut
Universitaet Wuerzburg, Am Hubland, 97074 Wuerzburg, Germany

Office: Room F-069a
+49-931-888-5766 (phone)
+49-931-888-5851 (fax)





Bug#421868: cups-pdf: gs hangs eating all memory when printing certain files

2007-05-02 Thread Volker Christian Behr
Hi, this is upstream -

I agree with Martin-Éric that you should definitely file this bug
against gs-esp, too, since this is where the problem originates.

Nevertheless thanks for this hint at the gs options. I will review them
and change the CUPS-PDF defaults accordingly where necessary.

Volker


On Wed, 2007-05-02 at 11:28 +0300, =?UTF-8?Q? Martin-=C3=89ric?= Racine
wrote:
 Thanks for your report.
 
 Critical: causes serious data loss, or introduces a security hole on
 systems where you install the package.
 
 Did the above issue introduce a security hole or cause serious data loss?
 I seriously doubt that it did. Thus, I'm bringing severity down to important.
 
 PS: I would tremendously appreciate it if you filed a bug against
 gs-esp for this issue, as this seems to be where the real problem is.
 Thanks!
 
 On 5/2/07, Christopher Zimmermann [EMAIL PROTECTED] wrote:
  Package: cups-pdf
  Version: 2.4.2-3
  Severity: critical
  Tags: patch
  Justification: breaks the whole system
 
  Hi!
 
  When printing certain files via cups-pdf, gs runs forever using all cpu
  and slowly eating all memory. In consequence the system becomes
  unresponsive after a few seconds and therefore unusable.
  If you think this bug is not critical, please tell me, so I know better
  next time.
  A typical example in our environment would be a MS Excel user printing
  to the cups-pdf printer using dim borderlines. If you'd like an example
  .ps file I can provide one.
  Actually this seems to be a bug in gs-esp, but since I managed to fix it
  in cups-pdf, I file it against cups-pdf.
 
  I could fix it by adding -c .setpdfwrite in the config:
  GSCall %s -q -dCompatibilityLevel=%s -dNOPAUSE -dBATCH -dSAFER 
  -sDEVICE=pdfwrite -sOutputFile=%s -dAutoRotatePages=/PageByPage 
  -dAutoFilterColorImages=false -dColorImageFilter=/FlateEncode 
  -dPDFSETTINGS=/prepress -c .setpdfwrite -f %s
 
  I removed the -c save pop, since /usr/share/doc/gs-esp/Use.htm
  [Improving Performance] suggests that it is not needed.
 
  I don't really understand why this fix works and probably this has to be
  fixed in gs, too. But the default of gs should be changed anyway as far
  as I understand the -c .setpdfwrite option.
  I don't think it is the same bug as #267423 since for me gs never
  finishes.
 
 
  Kind Regards,
 
  Christopher Zimmermann
 
-- 

Volker Christian Behr
Experimentelle Physik V (Biophysik), Physikalisches Institut
Universitaet Wuerzburg, Am Hubland, 97074 Wuerzburg, Germany

Office: Room F-069a
+49-931-888-5766 (phone)
+49-931-888-5851 (fax)





Bug#411620: please provide descriptive printer name

2007-02-20 Thread Volker Christian Behr
On Tue, 2007-02-20 at 18:43 +1100, Drew Parsons wrote:
 Package: cups-pdf
 Version: 2.4.2-2
 Severity: minor
 
 After cups-pdf is installed, the CUPS admin facilities (I use
 http://localhost:631/admin) identify that a New Printer has been
 found (nice).  The new printer is labelled as PDF Printer (Virtual
 Printer) (also nice).
 
 After clicking on the Add This Printer link, I find the new printer
 which I'm setting up is automatically given the name
 Virtual_Printer. This is not so nice.  Virtual_Printer could mean
 any number of things.  I think it would be very helpful if the default
 name identified just what kind of virtual printer it was.
 Virtual_PDF_Printer would do the job, or PDF_Printer or something
 like that.
 
 I can't see the name in the conffile or PPD, I assume it must be
 hardcoded in /usr/lib/cups/backend/cups-pdf ?

(This is upstream)
You are right - this information is taken from the backend's
initialisation string with which it informs CUPS of its existance. I
will change this to some more comprehensive name.
If no one objects, I will make it Virtual PDF Printer (CUPS-PDF) which
will result in CUPS-PDF as printer name.

Regards,
Volker


 Thanks,
 Drew
 
 
 -- System Information:
 Debian Release: 4.0
   APT prefers unstable
   APT policy: (990, 'unstable')
 Architecture: i386 (i686)
 Shell:  /bin/sh linked to /bin/dash
 Kernel: Linux 2.6.18
 Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
 
 Versions of packages cups-pdf depends on:
 ii  cupsys   1.2.7-4 Common UNIX Printing System(tm) 
 - 
 ii  gs-esp   8.15.3.dfsg.1-1 The Ghostscript PostScript 
 interpr
 ii  libc62.3.6.ds1-11GNU C Library: Shared libraries
 
 cups-pdf recommends no packages.
 
 -- no debconf information
-- 

Volker Christian Behr
Experimentelle Physik V (Biophysik), Physikalisches Institut
Universitaet Wuerzburg, Am Hubland, 97074 Wuerzburg, Germany

Office: Room F-069a
+49-931-888-5766 (phone)
+49-931-888-5851 (fax)




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#409356: cups-pdf: allows unprivileged user to read parts of any file

2007-02-02 Thread Volker Christian Behr
I am the CUPS-PDF developer. Though I am not using Debian I am quite
confused by this behaviour: CUPS-PDF is supposed to be mode 700 on CUPS
v1.2.x environments (so unprivileged users should not even be able to
execute it). Furthermore CUPS-PDF is explicitely not meant to be
installed SUID 'root' (neither is ghostscript) - so how can those two
programs access /etc/shadow at all?
Please check the permissions of the CUPS-PDF backend and GS - neither
should be SUID 'root' under any circumstances. CUPS-PDF should even more
be mode 700 executable by 'root' only. If this is not the case in the
default installation it has to be fixed in the Debian package.

On Fri, 2007-02-02 at 11:31 +0100, Grzegorz Żur wrote:
 Package: cups-pdf
 Version: 2.4.2-1
 Severity: critical
 Justification: root security hole
 Tags: security
 
 Unprivileged user can execute /usr/lib/cups/backend/cups-pdf to read
 parts of any file. End of file is printed by Ghostscript in error report.
 
 Execution of this command as unprivileged user
   /usr/lib/cups/backend/cups-pdf shadow user title 1 '' /etc/shadow
 will result in Ghostscript error showing last line of /etc/shadow file
 (possibly containing password hash)
   ERROR: /undefined in saned:!:13511:0:9:7:::
   ...
 
 -- System Information:
 Debian Release: 4.0
   APT prefers unstable
   APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (1,
 'experimental')
 Architecture: i386 (i686)
 Shell:  /bin/sh linked to /bin/bash
 Kernel: Linux 2.6.18-albemuth
 Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8)
 
 Versions of packages cups-pdf depends on:
 ii  cupsys   1.2.7-3 Common UNIX Printing
 System(tm) -
 ii  gs-esp   8.15.3.dfsg.1-1 The Ghostscript PostScript
 interpr
 ii  libc62.3.6.ds1-10GNU C Library: Shared libraries
 
 cups-pdf recommends no packages.
 
 -- no debconf information
 
-- 

Volker Christian Behr
Experimentelle Physik V (Biophysik), Physikalisches Institut
Universitaet Wuerzburg, Am Hubland, 97074 Wuerzburg, Germany

Office: Room F-069a
+49-931-888-5766 (phone)
+49-931-888-5851 (fax)





Bug#409356: cups-pdf: allows unprivileged user to read parts of any file

2007-02-02 Thread Volker Christian Behr
On Fri, 2007-02-02 at 13:49 +0200, =?UTF-8?Q? Martin-=C3=89ric?= Racine
wrote:
 On 2/2/07, Volker Christian Behr [EMAIL PROTECTED] wrote:
  Please check the permissions of the CUPS-PDF backend and GS - neither
  should be SUID 'root' under any circumstances. CUPS-PDF should even more
  be mode 700 executable by 'root' only. If this is not the case in the
  default installation it has to be fixed in the Debian package.
 
 Permissions were made 6755 to enable outputting documents to someone's
 home directory (or a subdirectory). Unless I'm mistaken, 0700 would
 not enable the same thing?

Starting with version 1.2.0 CUPS will call any backend that is owned by
'root' and set to mode 0700 with full root privileges which should
enable CUPS-PDF to print to any destination.
I know Ubuntu to have modified CUPS (e.g. the web-admin interface is
disabled) but I cannot tell what other changes they did.
I strongly reccommend making CUPS-PDF mode 0700 again since this is
to-the-letter within the specifications of CUPS.



-- 

Volker Christian Behr
Experimentelle Physik V (Biophysik), Physikalisches Institut
Universitaet Wuerzburg, Am Hubland, 97074 Wuerzburg, Germany

Office: Room F-069a
+49-931-888-5766 (phone)
+49-931-888-5851 (fax)




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#392938: kcemirror: FTBFS: /usr/lib/librapi.so: undefined reference to `synce_socket_get_descriptor'

2006-10-14 Thread Volker Christian
On Saturday 14 October 2006 23:10, Steve Langasek wrote:
 reassign 392938 librapi2
 found 392938 0.9.3-2
 tags 392938 -patch
 thanks

 On Sat, Oct 14, 2006 at 12:47:10PM +0200, Andreas Jochens wrote:
  When building 'kcemirror' on unstable,
  I get the following error:
 
  /usr/lib/librapi.so: undefined reference to `wstrlen'
  /usr/lib/librapi.so: undefined reference to `synce_socket_get_descriptor'
  /usr/lib/librapi.so: undefined reference to `synce_socket_write'
  /usr/lib/librapi.so: undefined reference to `synce_socket_connect_proxy'
  /usr/lib/librapi.so: undefined reference to `_synce_log_wstr'
  /usr/lib/librapi.so: undefined reference to `synce_password_recv_reply'
  /usr/lib/librapi.so: undefined reference to `synce_socket_connect'
  /usr/lib/librapi.so: undefined reference to `synce_info_destroy'
  /usr/lib/librapi.so: undefined reference to `synce_socket_read'
  /usr/lib/librapi.so: undefined reference to `filetime_from_unix_time'
  /usr/lib/librapi.so: undefined reference to `synce_socket_new'
  /usr/lib/librapi.so: undefined reference to `synce_socket_wait'
  collect2: ld returned 1 exit status
  make[3]: *** [kcemirror] Error 1
  make[3]: Leaving directory
  `/kcemirror-0.1.5/obj-x86_64-linux-gnu/kcemirror'
 
  With the attached patch 'kcemirror' can be compiled on unstable.
 
  diff -urN ../tmp-orig/kcemirror-0.1.5/debian/rules ./debian/rules
  --- ../tmp-orig/kcemirror-0.1.5/debian/rules2006-10-14
  10:16:59.0 + +++ ./debian/rules 2006-10-14 10:14:32.0
  +
  @@ -75,7 +75,7 @@
  mkdir $(objdir)
 
  # run configure with build tree $(objdir)
  -   cd $(objdir)  \
  +   cd $(objdir)  LIBS=-lsynce \
  ../configure $(configkde) \
  --with-distribution=$$version (`cat /etc/debian_version`) \
  --enable-mitshm --with-alsa --with-ipv6-lookup=auto \

 This is a wrong fix.  The error is that librapi2 includes a shared lib that
 isn't linked properly against libsynce.  It is absolutely wrong to try to
 work around this in packages that need librapi2, the responsibility lies
 with librapi2.

I completely agree with Stevens analysis - fix will be available soon.

regards
voc


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#392706: (no subject)

2006-10-13 Thread Volker Christian Behr
(upstream here)
In the past there were some issues with non-ESP versions of GS in
combination with CUPS-PDF since not all options were supported (at least
not in the same way). I never tested CUPS-PDF against GS-GPL, so I cannot
guarantee that it will work.
But if the maintainer can test CUPS-PDF with the GS-GPL that comes with
Debian, it is ok for me to include this alternative.


Martin Haefele said:
 Subject: cups-pdf should depend on either gs-esp or gs-gpl
 Package: cups-pdf
 Version: 2.4.2-1
 Severity: normal

 *** Please type your report below this line ***
 cups-pdf depends on gs-esp solely. Since from version 8.54 gs-gpl is
 available
 as complete gpl'ed program, it should be possible to install either
 gs-gpl or gs-esp.

 -- System Information:
 Debian Release: testing/unstable
   APT prefers testing
   APT policy: (990, 'testing')
 Architecture: i386 (i686)
 Shell:  /bin/sh linked to /bin/bash
 Kernel: Linux 2.6.18
 Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15)

 Versions of packages cups-pdf depends on:
 ii  cupsys   1.2.4-2+b1  Common UNIX Printing
 System(tm) -
 ii  gs-esp   8.15.3.dfsg.1-1 The Ghostscript PostScript
 interpr
 ii  libc62.3.6.ds1-4 GNU C Library: Shared
 libraries

 cups-pdf recommends no packages.

 -- no debconf information



-- 

Volker Christian Behr
Experimentelle Physik V (Biophysik), Physikalisches Institut
Universitaet Wuerzburg, Am Hubland, 97074 Wuerzburg, Germany

Office: Room F-069a
+49-931-888-5766 (phone)
+49-931-888-5851 (fax)



Bug#390590: /etc/cups/cups-pdf.conf is updated for every new release

2006-10-03 Thread Volker Christian Behr
On Tue, 2006-10-03 at 05:22, Jonas Meurer wrote:
 On 02/10/2006 Volker Christian Behr wrote:
   unfortunately, a version information in /etc/cups/cups-pdf.conf is
   updated every new upstream release. i consider this as a bug as it
   causes dpkg to ask for a configfile update even if no content changed.
   
   if you have local changes in the configuration, this is very annoying.
   
   maybe you can convince upstream to remove the release version from the
   configuration file.
  
  Is there a way to make dpkg ignore this comment in the configuration
  file?
 
 unfortunately not. the only solution i can think of now, is that the
 debian package strips the version line from the config at build time.
 
  For some other installations/distributions I depend on the version
  number being part of the config file
 
 could you explain in which situations a version number in the config is
 required?

Anytime people do not use the pre-packaged versions (i.e. Debian
packages, rpms and so on) but compile and install from the sources. They
tend to forget to update the configuration along with binary. So I have
to check each config-file they send to me by comparing with my sources
whether it matches the version they are using and they cannot check it
by themselves easily. This is - as I had to learn the hard way - a lot
of extra work when debugging installation issues.


-- 

Volker Christian Behr
Experimentelle Physik V (Biophysik), Physikalisches Institut
Universitaet Wuerzburg, Am Hubland, 97074 Wuerzburg, Germany

Office: Room F-069a
+49-931-888-5766 (phone)
+49-931-888-5851 (fax)



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#390590: /etc/cups/cups-pdf.conf is updated for every new release

2006-10-02 Thread Volker Christian Behr
On Mon, 2006-10-02 at 03:12, Jonas Meurer wrote:
 Package: cups-pdf
 Version: 2.4.2-1
 Severity: normal
 
 hello,
 
 unfortunately, a version information in /etc/cups/cups-pdf.conf is
 updated every new upstream release. i consider this as a bug as it
 causes dpkg to ask for a configfile update even if no content changed.
 
 if you have local changes in the configuration, this is very annoying.
 
 maybe you can convince upstream to remove the release version from the
 configuration file.

Hi!

Is there a way to make dpkg ignore this comment in the configuration
file? For some other installations/distributions I depend on the version
number being part of the config file

Volker

 ...
  jonas
 
 -- System Information:
 Debian Release: testing/unstable
   APT prefers unstable
   APT policy: (500, 'unstable'), (1, 'experimental')
 Architecture: amd64 (x86_64)
 Shell:  /bin/sh linked to /bin/bash
 Kernel: Linux 2.6.18-1-amd64-resivo
 Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
 
 Versions of packages cups-pdf depends on:
 ii  cupsys   1.2.4-2 Common UNIX Printing System(tm) 
 - 
 ii  gs-esp   8.15.3.dfsg.1-1 The Ghostscript PostScript 
 interpr
 ii  libc62.3.6.ds1-5 GNU C Library: Shared libraries
 
 cups-pdf recommends no packages.
 
 -- no debconf information
-- 

Volker Christian Behr
Experimentelle Physik V (Biophysik), Physikalisches Institut
Universitaet Wuerzburg, Am Hubland, 97074 Wuerzburg, Germany

Office: Room F-069a
+49-931-888-5766 (phone)
+49-931-888-5851 (fax)



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#390229: cups-pdf: Feature request: do not overwrite files for jobs with identical names

2006-09-30 Thread Volker Christian Behr
On Fri, 2006-09-29 at 23:57, Dimitris Kogias wrote:
 Package: cups-pdf
 Version: 2.4.1-2
 Severity: wishlist
 
 
 When two print jobs are sent to cups-pdf with the same name, the second job's 
 PDF
 file will overwrite the first job's file in $HOME/PDF/.
 
 cups-pdf should use a convention like foo-1, foo-2 etc or similar.
 
 This is especially a problem when printing from a browser (firefox) where the
 job name is derived from the page title.  Some web sites (e.g. my online 
 banking
 site) keep the same title for different pages one might want to print, leading
 to lost PDFs.

This feature is already implemented - just set the option Label in
/etc/cups/cups-pdf.conf to 1 (it is set to 0 by default). For that point
on all jobs will be labeled with a unique ID.

Volker

 -- System Information:
 Debian Release: testing/unstable
   APT prefers unstable
   APT policy: (500, 'unstable')
 Architecture: i386 (i686)
 Shell:  /bin/sh linked to /bin/bash
 Kernel: Linux 2.6.18
 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
 
 Versions of packages cups-pdf depends on:
 ii  cupsys   1.2.4-1 Common UNIX Printing System(tm) 
 - 
 ii  gs-esp   8.15.2.dfsg.1-2 The Ghostscript PostScript 
 interpr
 ii  libc62.3.6.ds1-4 GNU C Library: Shared libraries
 
 cups-pdf recommends no packages.
 
 -- no debconf information
-- 

Volker Christian Behr
Experimentelle Physik V (Biophysik), Physikalisches Institut
Universitaet Wuerzburg, Am Hubland, 97074 Wuerzburg, Germany

Office: Room F-069a
+49-931-888-5766 (phone)
+49-931-888-5851 (fax)



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#390141: cups-pdf: please migrate PPD to /usr/share/ppd directory

2006-09-29 Thread Volker Christian Behr
On Fri, 2006-09-29 at 16:43, Martin-Éric Racine wrote:
 On Fri, September 29, 2006 15:52, Kenshi Muto wrote:
  Package: cups-pdf
  Version: 2.4.1-2
  Severity: normal
 
  Debian printing team had already decided all PPDs should be under
  /usr/share/ppd.
  Could you move PPD files to that directory?
  (you may make a subdirectory)
 
 Volker: is cups-pdf dependent upon the PPD being at a specific location?

No, the CUPS-PDF does not access the PPD itself. So if you move it into
a location where CUPS can find it, it will work fine.

-- 

Volker Christian Behr
Experimentelle Physik V (Biophysik), Physikalisches Institut
Universitaet Wuerzburg, Am Hubland, 97074 Wuerzburg, Germany

Office: Room F-069a
+49-931-888-5766 (phone)
+49-931-888-5851 (fax)




Bug#387752: cups-pdf: support UTF-8

2006-09-17 Thread Volker Christian Behr
On Sat, 2006-09-16 at 17:15, Martin-Éric Racine wrote:
 la, 2006-09-16 kello 20:21 +0800, Dan Jacobson kirjoitti:
  Package: cups-pdf
  Version: 2.4.1-1
  Severity: normal
  
  Support UTF-8, so one can do
  $ date|lp
  and not have characters missing.
 
 Good point. 
 
 However, I am not convinced that CUPS-PDF is to blame, since printing
 UTF-8 text works fine from GNOME.  Here, I regularly mix Cyrillic and
 Latin characters, a combination that clearly requires UTF-8 support.
 
 I suspect that how CUPS clients and Ghostscript select fonts affect the
 absence or presence of certain characters, thus why I'm copying this to
 the CUPS and Ghostscript maintainers for comment.
 
 The CUPS-PDF author is already subscribed to this package's PTS and can
 probably also contribute answers to this bug report.

Hi,

I agree that this is most likely not the fault of CUPS-PDF itself but
one of the other programs it uses. 
You might want to try a different postscript PPD file that is known to
work with your charset (CUPS-PDF will accept any PPD file that creates
postscript code).
In order to track down the issue it would be helpful to know where the
error occurs: 
$ date|enscript -o date.ps 
creates a PS-file with the date-sting (you can also use e.g. a2ps
instead of enscript). Printing this file to CUPS-PDF set up without a
PPD file (i.e. raw queue) will result in a PDF: if there the characters
are mangled it is a issue with the setup of ghostscript, if there
everything is fine it is probably due to the PPD file.

Volker


-- 

Volker Christian Behr
Experimentelle Physik V (Biophysik), Physikalisches Institut
Universitaet Wuerzburg, Am Hubland, 97074 Wuerzburg, Germany

Office: Room F-069a
+49-931-888-5766 (phone)
+49-931-888-5851 (fax)




Bug#259294: Intent to NMU

2006-08-16 Thread Volker Christian
Hi Margarita,

thank you for the NMU. I didn't respond earlier to your mail, as i have been 
on vacation for a few weeks.

Thank you again - i will communicate your patch to upstream.

regards
voc


On Sunday 06 August 2006 03:10, Margarita Manterola wrote:
 Hi!

 Maximiliano Curia noticed this important bug that included a patch, and we
 worked together into making an NMU for it.

 The NMU is really simple.  Basically, it applies Kari's patch, and adds a
 changelog entry.  config.guess and config.sub where also upgraded, due to
 the way the package is built.

 I'll be uploading this NMU to the 7-day delayed queue.  I'm attaching the
 full interdiff output of the package I've prepared.

 Hope you find it useful.

 --
 Love,
   Marga


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#361062: cups-pdf: Incorrect reading of *UMask configuration parameters

2006-04-06 Thread Volker Christian Behr
Thanks for this patch - I will implement it asap.

Volker

On Thu, 2006-04-06 at 11:34, Nickolay Kondrashov wrote:
 Package: cups-pdf
 Version: 2.0.5-1
 Severity: normal
 Tags: patch
 
 
 CUPS-PDF reads it's configuration options AnonUMask and UserUMask
 incorrectly, using decimal base, instead of octal.
 
 Patch follows:
 diff -ru a/src/cups-pdf.h b/src/cups-pdf.h
 --- a/src/cups-pdf.h2006-02-26 15:48:50.0 +0300
 +++ b/src/cups-pdf.h2006-04-06 13:16:37.0 +0400
 @@ -133,11 +133,11 @@
  conf.lowercase=(tmp0)?1:0;
}
else if (!strcmp(AnonUMask,key)) {
 -tmp=atoi(value);
 +tmp=(int)(strtol(value,NULL,8));
  conf.anonumask=tmp;
}
else if (!strcmp(UserUMask,key)) {
 -tmp=atoi(value);
 +tmp=(int)(strtol(value,NULL,8));
  conf.userumask=tmp;
}
else 
 
 -- System Information:
 Debian Release: 3.1
   APT prefers stable
   APT policy: (990, 'stable'), (50, 'testing'), (25, 'unstable')
 Architecture: i386 (i686)
 Kernel: Linux 2.6.12-1-686
 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
 
 Versions of packages cups-pdf depends on:
 ii  adduser  3.63Add and remove users and groups
 ii  cupsys   1.1.23-10sarge1 Common UNIX Printing System(tm) 
 - 
 ii  gs-esp   7.07.1-9The Ghostscript PostScript 
 interpr
 ii  libc62.3.2.ds1-22GNU C Library: Shared libraries 
 an
 
 -- no debconf information
-- 

Volker Christian Behr
Experimentelle Physik V (Biophysik), Physikalisches Institut
Universitaet Wuerzburg, Am Hubland, 97074 Wuerzburg, Germany

Office: Room F-069a
+49-931-888-5766 (phone)
+49-931-888-5851 (fax)



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#344872: Same bug empty files to print with cups-pdf

2006-04-02 Thread Volker Christian Behr
Hi,

it might be that the New-Stylus-Color-printer driver does not create
correct postscript. Try using the PostScript Color driver that comes
with CUPS-PDF (or at least some driver that explicitely says generic PS
driver).

Since the PDF is correctly created if you call cups-pdf directly (on the
commandline) with a PS-File the printer driver seems the obvious
culprit.

Volker

On Sat, 2006-04-01 at 22:44, Mario Oyorzabal Salgado wrote:
 Hi, i have make more test's for know about this problem :-P, i have made this:
 
 # /usr/lib/cups/backend/cups-pdf 1 tuxsoul Test 1 0 /home/tuxsoul/mozilla.ps
 
 I think so cups-pdf run with user tuxsoul, the result is a correct pdf file, 
 in
 tuxsoul home, but if try to print since gedit or any gnome or gui, 
 application,
 the result is the empty file, may be ¿is the communication between cups and
 cups-pdf?
 
 I have install the driver for printer New-Stylus-Color-printer for using
 cups-pdf, in my gnome enviroment. Sorry for skype this info =P.
 
 
 
 Volker Christian Behr wrote:
  Hi,
  
  from what I can see from the logfile, when printing as non-root GS returns
  the error code 256 - this usually means that the source file cannot be
  read. Please check whether the directory /var/spool/cups-pdf/SPOOL is
  readable for the group lpadmin. One thing you can try is removing the
  entire directory /var/spool/cups-pdf ... CUPS-PDF will re-create the tree
  with suitable permissions.
  
  Volker
  
-- 

Volker Christian Behr
Experimentelle Physik V (Biophysik), Physikalisches Institut
Universitaet Wuerzburg, Am Hubland, 97074 Wuerzburg, Germany

Office: Room F-069a
+49-931-888-5766 (phone)
+49-931-888-5851 (fax)




Bug#344872: Same bug empty files to print with cups-pdf

2006-04-02 Thread Volker Christian Behr
On Sun, 2006-04-02 at 18:49, Martin-Éric Racine wrote:
 su, 2006-04-02 kello 11:21 -0500, Mario Oyorzabal Salgado kirjoitti:
 Volker Christian Behr wrote:
   it might be that the New-Stylus-Color-printer driver does not create
   correct postscript. Try using the PostScript Color driver that comes
   with CUPS-PDF (or at least some driver that explicitely says generic PS
   driver).
  Is posible when install cups-pdf automatic install this driver postscript 
  color
  driver, or show a notice in the process of instalation for know to the 
  user the
  best driver compatibility with cups-pdf ?.
 
 I'm starting to think that making our driver the only possible choice
 for the CUPS-PDF back-end might indeed make a lot of sense.

I agree - it supports by now a wide choice of paper formats (probably
more than most other drivers) and produces good PS code. Perhaps the
post-installation configuration can do an automatic setup of the printer
(if the user agrees) with 
lpadmin -p PDF -v cups-pdf:/ -m PostscriptColor.ppd -E


-- 

Volker Christian Behr
Experimentelle Physik V (Biophysik), Physikalisches Institut
Universitaet Wuerzburg, Am Hubland, 97074 Wuerzburg, Germany

Office: Room F-069a
+49-931-888-5766 (phone)
+49-931-888-5851 (fax)




Bug#344872: Same bug empty files to print with cups-pdf

2006-04-01 Thread Volker Christian Behr
Hi,

from what I can see from the logfile, when printing as non-root GS returns
the error code 256 - this usually means that the source file cannot be
read. Please check whether the directory /var/spool/cups-pdf/SPOOL is
readable for the group lpadmin. One thing you can try is removing the
entire directory /var/spool/cups-pdf ... CUPS-PDF will re-create the tree
with suitable permissions.

Volker

Mario Oyorzabal Salgado said:

 Hi, i'm do the step's you send me, and the pdf file was create correctly
 for
 user root.

 Testing again with user tuxsoul don't using the steps you send me, to
 record the
 log in the cups-pdf_log file, when a user print but not is root, and the
 pdf
 file is create with 718 or 716 bytes empty.

 You can see this in the attach file.

 greeting, sorry my english is bad =).

 Volker Christian Behr wrote:
 Hi,

 ok, so we will need a step-by-step diagnostics. CUPS-PDF can be called
 by hand to verify its operation. Let's try the following steps:

 1. set the option LogType to 7 in /etc/cups/cups-pdf.conf

 2. as user 'root' do the following call:
 /usr/lib/cups/backend/cups-pdf

 the output should read
 file cups-pdf:/ PDF Printer Virtual Printer

 3. as user 'root' try to convert a PS file with CUPS-PDF
 /usr/lib/cups/backend/cups-pdf 1 root Test 1 0 some-PS-file

 Now a PDF should have been created for root and in
 /var/log/cups/cups-pdf_log there should be a lot of debug output.

 This debug output should help determining the culprit.

 Regards,

 Volker



 --
 hechando a perder se aprende
 http://mx.tuxsoul.com
 http://mx.dolric.com
 --BEGIN GEEK CODE BLOCK-
 Version: 3.12
 GCS d? s: a? C+++ UL+++ P+ L++ E--- W++ N+ o K- w++
 O-- M V- PS PE Y PGP++ t++ 5 X+++ R* tv++ b- DI+++ D
 G++ e- h++ !r !z
 ---END GEEK CODE BLOCK--



-- 

Volker Christian Behr
Experimentelle Physik V (Biophysik), Physikalisches Institut
Universitaet Wuerzburg, Am Hubland, 97074 Wuerzburg, Germany

Office: Room F-069a
+49-931-888-5766 (phone)
+49-931-888-5851 (fax)



Bug#344872: Same bug empty files to print with cups-pdf

2006-03-29 Thread Volker Christian Behr
Ok, do we get a log-file by now (/var/log/cups/cups-pdf_log)? This one
cups-pdf should write at least even if the PDF creation fails. 

Btw.: are you using SELinux?

Volker

On Wed, 2006-03-29 at 03:43, Mario Oyorzabal Salgado wrote:
 Volker Christian Behr wrote:
  Oops, sorry, my mistake:
  
  it must read: /etc/cups/cupsd.conf , not /etc/cups/cups-pdf.conf
  
  So, please check /etc/cups/cupsd.conf for the RunAsUser Statement and if
  there is none add the following line:
  
  RunAsUser No
  
  and restart CUPS.
  
  Volker
  
 
 Ho, ok, I have add the RunAsUser in cupsd.conf file, in line: 369, restarting
 cups, but i have the same result, a file empty with 718 bytes. :-(
-- 

Volker Christian Behr
Experimentelle Physik V (Biophysik), Physikalisches Institut
Universitaet Wuerzburg, Am Hubland, 97074 Wuerzburg, Germany

Office: Room F-069a
+49-931-888-5766 (phone)
+49-931-888-5851 (fax)



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#344872: Same bug empty files to print with cups-pdf

2006-03-29 Thread Volker Christian Behr
From the directory listing I can see that the cups-pdf_log was not
touched for 2 days by now, but there are enties in the error_log. Do
those give any insight?

Volker

On Wed, 2006-03-29 at 19:00, Mario Oyorzabal Salgado wrote:
 Volker Christian Behr wrote:
  Ok, do we get a log-file by now (/var/log/cups/cups-pdf_log)? This one
  cups-pdf should write at least even if the PDF creation fails. 
  
  Btw.: are you using SELinux?
  
  Volker
  
  On Wed, 2006-03-29 at 03:43, Mario Oyorzabal Salgado wrote:
  
 
 Nop, i'm not using SELinux.
 The log is empty:
 
 -rw-r--r--  1 root lpadmin 43318 2006-03-29 09:32 access_log
 -rw---  1 root lpadmin 0 2006-03-27 10:23 cups-pdf_log
 -rw-r--r--  1 root lpadmin 10416 2006-03-29 09:31 error_log
 -rw-r--r--  1 root lpadmin  8976 2006-03-28 19:39 page_log
-- 

Volker Christian Behr
Experimentelle Physik V (Biophysik), Physikalisches Institut
Universitaet Wuerzburg, Am Hubland, 97074 Wuerzburg, Germany

Office: Room F-069a
+49-931-888-5766 (phone)
+49-931-888-5851 (fax)



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#344872: Same bug empty files to printf with cups-pdf

2006-03-28 Thread Volker Christian Behr
Oops, sorry, my mistake:

it must read: /etc/cups/cupsd.conf , not /etc/cups/cups-pdf.conf

So, please check /etc/cups/cupsd.conf for the RunAsUser Statement and if
there is none add the following line:

RunAsUser No

and restart CUPS.

Volker

Mario Oyorzabal Salgado said:
 Volker Christian Behr wrote:
 On Mon, 2006-03-27 at 21:28, Mario Oyorzabal Salgado wrote:

 In /etc/cups/cups-pdf.conf: is the RunAsUser option set to No ?

 Volker


 I'm check the conf file:

 #grep RunAsUser cups-pdf.conf

 but don't show nothing, i don't have the RunAsUser option in my conf
 file, how
 can set this option ?, so if necesary ?

 p.d. sorry my engish is bad =)

 --
 hechando a perder se aprende
 http://mx.tuxsoul.com
 http://mx.dolric.com
 --BEGIN GEEK CODE BLOCK-
 Version: 3.12
 GCS d? s: a? C+++ UL+++ P+ L++ E--- W++ N+ o K- w++
 O-- M V- PS PE Y PGP++ t++ 5 X+++ R* tv++ b- DI+++ D
 G++ e- h++ !r !z
 ---END GEEK CODE BLOCK--



-- 

Volker Christian Behr
Experimentelle Physik V (Biophysik), Physikalisches Institut
Universitaet Wuerzburg, Am Hubland, 97074 Wuerzburg, Germany

Office: Room F-069a
+49-931-888-5766 (phone)
+49-931-888-5851 (fax)



Bug#344872: Same bug empty files to printf with cups-pdf

2006-03-27 Thread Volker Christian Behr
On Mon, 2006-03-27 at 21:28, Mario Oyorzabal Salgado wrote:
 Package: cups-pdf
 Version: 2.0.5-1
 Followup-For: Bug #344872
 
 I have the same problem with cups-pdf, when printf files any application
 the result file is empty with 716 bytes =), the log files cups-pdf is 
 too empty.

In /etc/cups/cups-pdf.conf: is the RunAsUser option set to No ?

Volker

 sorry my english is poor =P.
 
 -- System Information:
 Debian Release: testing/unstable
   APT prefers testing
   APT policy: (500, 'testing')
 Architecture: i386 (i686)
 Shell:  /bin/sh linked to /bin/bash
 Kernel: Linux 2.6.15-1-686
 Locale: LANG=es_MX.UTF-8, LC_CTYPE=es_MX.UTF-8 (charmap=UTF-8)
 
 Versions of packages cups-pdf depends on:
 ii  adduser  3.85Add and remove users and groups
 ii  cupsys   1.1.23-12   Common UNIX Printing System(tm) 
 - 
 ii  gs-esp   8.15.1.dfsg.1-1 The Ghostscript PostScript 
 interpr
 ii  libc62.3.6-3 GNU C Library: Shared libraries 
 an
 
 cups-pdf recommends no packages.
 
 -- no debconf information
-- 

Volker Christian Behr
Experimentelle Physik V (Biophysik), Physikalisches Institut
Universitaet Wuerzburg, Am Hubland, 97074 Wuerzburg, Germany

Office: Room F-069a
+49-931-888-5766 (phone)
+49-931-888-5851 (fax)



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#358074: FTBFS with G++ 4.1: extra qualification

2006-03-21 Thread Volker Christian
Hi Martin,

thank you for this hint ... it's a simple copy/past error with bad 
consequences.
I'll upload a fixed package soon.

regards
voc


On Tuesday 21 March 2006 04:15, Martin Michlmayr wrote:
 Package: syncekonnector
 Version: 0.3.2-1
 Severity: important
 Tags: patch

 Your package fails to build with G++ 4.1.  I'm filing this bug as
 important for now, but when 4.1 will be the default compiler in
 unstable (probably in a few weeks) I'll upgrade this to serious.

 A patch is attached.

  Automatic build of syncekonnector_0.3.2-1 on bigsur by sbuild/mips 1.106

 ...

  if /bin/sh ../libtool --silent --tag=CXX --mode=compile
  mips-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../libksynce
  -I../includes -I/usr/include/kde -I/usr/share/qt3/include
  -I/usr/X11R6/include -I/usr/include/kde/kitchensync 
  -DQT_THREAD_SUPPORT  -D_REENTRANT  -Wno-long-long -Wundef -ansi
  -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion
  -Wchar-subscripts -Wall -W -Wpointer-arith -O2 -Wformat-security
  -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions
  -fno-check-new -fno-common  -MT pimsyncmanager.lo -MD -MP -MF
  .deps/pimsyncmanager.Tpo -c -o pimsyncmanager.lo pimsyncmanager.cpp; \
  then mv -f .deps/pimsyncmanager.Tpo .deps/pimsyncmanager.Plo; else rm
  -f .deps/pimsyncmanager.Tpo; exit 1; fi ./synceengine.h:89: error:
  extra qualification 'KSync::SynCEEngine::' on member 'templateSyncee'
  /usr/lib/gcc/mips-linux-gnu/4.1.0/../../../../include/c++/4.1.0/bits/basi
 c_string.h: In member function 'std::basic_string_CharT, _Traits,
  _Alloc::_Rep* std::basic_string_CharT, _Traits, _Alloc::_M_rep() const
  [with _CharT = char, _Traits = std::char_traitschar, _Alloc =
  std::allocatorchar]':
  /usr/lib/gcc/mips-linux-gnu/4.1.0/../../../../include/c++/4.1.0/bits/basi
 c_string.h:478:   instantiated from 'std::basic_string_CharT, _Traits,
  _Alloc::~basic_string() [with _CharT = char, _Traits =
  std::char_traitschar, _Alloc = std::allocatorchar]'
  /usr/share/qt3/include/qstring.h:667:   instantiated from here
  /usr/lib/gcc/mips-linux-gnu/4.1.0/../../../../include/c++/4.1.0/bits/basi
 c_string.h:283: warning: cast from 'char*' to 'std::basic_stringchar,
  std::char_traitschar, std::allocatorchar ::_Rep*' increases required
  alignment of target type make[3]: *** [pimsyncmanager.lo] Error 1

 --- ./librakikpimsync/synceengine.h~  2006-03-21 03:08:54.0 +
 +++ ./librakikpimsync/synceengine.h   2006-03-21 03:09:13.0 +
 @@ -86,7 +86,7 @@

private:
  void doSync();
 -templateclass T T  *SynCEEngine::templateSyncee(SynceeList
 *synceeList) const; +templateclass T T  *templateSyncee(SynceeList
 *synceeList) const;

  Konnector::List mOpenedKonnectors;
  Konnector::List mProcessedKonnectors;


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#357977: syncekonnector: fails to install (type in control file)

2006-03-20 Thread Volker Christian
Hi Stefan,

thank you for this info. This bug is already fixed in version 0.3.2-2

regards
voc


On Monday 20 March 2006 16:58, Stefan Huehner wrote:
 Package: syncekonnector
 Severity: important
 Tags: patch


 Hi,
 due to a type in debian/control this ends in your binary package:
 Depends: syncekonnector (= ${Source-Version]).

 Attached patch fixes the typo so that the placeholder will correctly be
 replaced.

 Please consider applying the patch.

 Regards,
 Stefan


 -- System Information:
 Debian Release: testing/unstable
   APT prefers unstable
   APT policy: (500, 'unstable')
 Architecture: amd64 (x86_64)
 Shell:  /bin/sh linked to /bin/bash
 Kernel: Linux 2.6.15-1-amd64-k8-smp
 Locale: LANG=C, LC_CTYPE=de_DE.UTF8 (charmap=UTF-8)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#355717: synce-serial: upgrade from sarge to sid, then purging, leaves /etc/hotplug/usb/ipaq

2006-03-07 Thread Volker Christian
Thank you for the hint. It will be included in the next release.

regard
voc


On Tuesday 07 March 2006 15:56, Lars Wirzenius wrote:
 Package: synce-serial
 Version: 0.9.1-3

 When testing synce-serial with piuparts, I get the following error:

 2m17.4s ERROR: Package purging left files on system:
   /etc/default/hotplug.dpkg-old
   /etc/hotplug
 owned by: hotplug
   /etc/hotplug/usb
 owned by: hotplug
   /etc/hotplug/usb/ipaq

 This happens when testing an upgrade from sarge to etch to sid, then
 removing and purging the package. The problem seems to be that the sarge
 version's postinst creates /etc/hotplug/usb/ipaq, and the sarge
 version's postrm also removes it, but newer versions don't do that
 anymore. Unfortunately, because the upgrade scenario is likely, the
 postrm even in newer versions needs to include the removal of the file
 when the package is purged.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#352934: hald-probe-serial should not be called after connecting a Windows-CE device via USB

2006-02-16 Thread Volker Christian
On Thursday 16 February 2006 13:53, Sjoerd Simons wrote:
 On Wed, Feb 15, 2006 at 11:25:33AM +0100, Volker Christian wrote:
  Package: hal
  Version: 0.4.8-8
  Severity: important
 
  Connecting a Windows-CE device via USB causes a call to
  hald-probe-serial. This is bad for a Windows-CE device as
  hald-probe-serial is trying to open the ttyUSBx device what causes the
  Windows-CE device to start the connection-initiation-sequence. This
  sequence
  couldn't succeed, because no program is waiting for a connection on the
  pc-side. This wouldn't be that bad if the Windows-CE device would accept
  a second triggering of the connection-initiation-seqnence by appropriate
  desktop software (synce-serial). But unfortunately, Windows-CE devices
  didn't allow a second trigger. Hence, with the present hal-package no
  USB connection with an Windows-CE device is possible.
 
  A proper solution would be the integration of the SynCE package
  (especially the synce-serial package) into hal, such that
  synce-serial-start would be called instead of hald-probe-serial on
  device-connect and that synce-serial-abort would be called after the
  device is unplugged.
 
  Please let me know how we could achieve this goal - or maybe an other
  appropriate solution.

 Imho the correct solution for hal is not to probe USB serial ports. The
 only reason for the serial port prober is that you can't know if /dev/ttyS3
 actually corresponds to a real device. But that's not an issue for USB.
I agree, this is not really an issue for USB. I think this is a todo for 
upstream, isn't it? :-)


 Now i must admin that i don't know a lot about how synce works, but it's my
 opinion that hal should remain a facts database and shouldn't start
 triggering system setup programs. That should be done on a higher level.
I agree also. But unfortunately, i am not a udev/hal expert. Could you please 
give me some hints how i could automate this triggering at a higher level? I 
am willing to integrate this in the synce software.

Desired behaviour:
===
Everytimes a pda is connected to an usb-port a special command 
(synce-serial-start) should be called - this initiates a ppp-connection.
Everytimes a pda is disconnected from the usb-port an other command 
(synce-serial-abort) should be called - this shuts down the ppp-connection.


 What do you think ?
As already said above, i completely agree with you.
Thank you very much.

Volker



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#352934: hald-probe-serial should not be called after connecting a Windows-CE device via USB

2006-02-15 Thread Volker Christian
Package: hal
Version: 0.4.8-8
Severity: important

Connecting a Windows-CE device via USB causes a call to
hald-probe-serial. This is bad for a Windows-CE device as
hald-probe-serial is trying to open the ttyUSBx device what causes the
Windows-CE device to start the connection-initiation-sequence. This
sequence
couldn't succeed, because no program is waiting for a connection on the
pc-side. This wouldn't be that bad if the Windows-CE device would accept
a second triggering of the connection-initiation-seqnence by appropriate
desktop software (synce-serial). But unfortunately, Windows-CE devices
didn't allow a second trigger. Hence, with the present hal-package no
USB connection with an Windows-CE device is possible.

A proper solution would be the integration of the SynCE package
(especially the synce-serial package) into hal, such that
synce-serial-start would be called instead of hald-probe-serial on
device-connect and that synce-serial-abort would be called after the
device is unplugged.

Please let me know how we could achieve this goal - or maybe an other
appropriate solution.

best regards
Volker Christian
[EMAIL PROTECTED]
Maintainer of the SynCE-packages


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15.2
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

Versions of packages hal depends on:
ii  adduser   3.82   Add and remove users and groups
ii  dbus-10.23.4-8   simple interprocess messaging syst
ii  dbus-glib-1   0.23.4-8   simple interprocess messaging syst
ii  libc6 2.3.5-12.1 GNU C Library: Shared libraries an
ii  libcap1   1:1.10-14  support for getting/setting POSIX.
ii  libexpat1 1.95.8-3   XML parsing C library - runtime li
ii  libglib2.0-0  2.8.6-1The GLib library of C routines
ii  libhal-storage0   0.4.8-8Hardware Abstraction Layer - share
ii  libhal0   0.4.8-8Hardware Abstraction Layer - share
ii  libpopt0  1.7-5  lib for parsing cmdline parameters
ii  pciutils  1:2.1.11-15.3  Linux PCI Utilities
ii  udev  0.070-2/dev/ management daemon
ii  usbutils  0.71+cvs20051029-4 USB console utilities

hal recommends no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#350210: amd64 build of unshield fails to extract files due to checksum error

2006-01-28 Thread Volker Christian
Hi,

thanks for this report. Would it be possible for you do track down the problem 
as i didn't own a amd64-based machine?

regards
voc


On Saturday 28 January 2006 00:15, Zinx Verituse wrote:
 Package: unshield
 Version: 0.5-3
 Severity: important

 Extracting any cab on amd64 with the amd64 binary with -D 3 yields:
 [unshield_file_save:710] MD5 checksum failure for file 66 (W83627THF.ini)
 Failed to extract file 'W83627THF.ini'.

 Extracting with the 32-bit debian version, still on amd64, works fine
 (extracts files, does not have a checksum error)

 -- System Information:
 Debian Release: testing/unstable
   APT prefers unstable
   APT policy: (500, 'unstable')
 Architecture: amd64 (x86_64)
 Shell:  /bin/sh linked to /bin/bash
 Kernel: Linux 2.6.15-1-amd64-k8-smp
 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

 Versions of packages unshield depends on:
 ii  libc6 2.3.5-12   GNU C Library: Shared
 libraries an ii  libunshield0  0.5-3  library to
 extracts CAB files from ii  zlib1g1:1.2.3-9 
 compression library - runtime

 unshield recommends no packages.

 -- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#343145: cups-pdf: graphics work, text is garbled

2006-01-17 Thread Volker Christian Behr
On Mon, 2006-01-16 at 23:16, Alex Satrapa wrote:
 On 16 Jan 2006, at 21:15, Volker Christian Behr wrote:
 
  What printer driver is your CUPS on the Mac OS X platform using?
 
 The printer is set up as a Generic - Colour PostScript Printer.
 
  (What I have in mind is that perhaps your Mac OS X driver uses a font
  description which is not available on the Linux-server and for some
  reason the font substitution fails.)
 
 Is there a way I can get GhostScript to produce sensible debugging 
 output about fonts it is trying to use? It may simply be the case that 
 one font I need is missing.

Unfortunately I am not that deep into GhostScript. If the postscript
still looks ok (text and images when viewed with ghostview or similar)
and only the converted PDF shows garbled text it might be worthwhile to
talk to the people in charge of GhostScript.

 Alex Satrapa
 Australian Phenomics Facility
 Building 117 Garran Road
 The Australian National University 
 Canberra ACT 0200 Australia
 
 T: +61 2 6125 1335
 F: +61 2 6125 1381
 W: www.apf.edu.au
 
 CRICOS Provider #0120C
-- 

Volker Christian Behr
Experimentelle Physik V (Biophysik), Physikalisches Institut
Universitaet Wuerzburg, Am Hubland, 97074 Wuerzburg, Germany

Office: Room F-069a
+49-931-888-5766 (phone)
+49-931-888-5851 (fax)



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#343145: cups-pdf: graphics work, text is garbled

2006-01-17 Thread Volker Christian Behr
On Tue, 2006-01-17 at 23:22, Alex Satrapa wrote:
 On 17 Jan 2006, at 23:38, Volker Christian Behr wrote:
 
  Unfortunately I am not that deep into GhostScript. If the postscript
  still looks ok (text and images when viewed with ghostview or similar)
  and only the converted PDF shows garbled text it might be worthwhile to
  talk to the people in charge of GhostScript.
 
 Sounds like a plan - I'll come back to this bug when I find out what 
 the problem is, so other people with the same problem can quickly find 
 the solution.

Ok, thanks a lot for your help! :-)

Cheers,
Volker

 Regards
 Alex
 
 Alex Satrapa
 Australian Phenomics Facility
 Building 117 Garran Road
 The Australian National University 
 Canberra ACT 0200 Australia
 
 T: +61 2 6125 1335
 F: +61 2 6125 1381
 W: www.apf.edu.au
 
 CRICOS Provider #0120C
-- 

Volker Christian Behr
Experimentelle Physik V (Biophysik), Physikalisches Institut
Universitaet Wuerzburg, Am Hubland, 97074 Wuerzburg, Germany

Office: Room F-069a
+49-931-888-5766 (phone)
+49-931-888-5851 (fax)



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#343145: cups-pdf: graphics work, text is garbled

2006-01-16 Thread Volker Christian Behr
On Mon, 2006-01-16 at 07:37, Alex Satrapa wrote:
 On 14 Jan 2006, at 21:26, Martin-Éric Racine wrote:
 
  to, 2005-12-15 kello 11:43 +0100, Volker Christian Behr kirjoitti:
  gs -q -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -dSAFER
  -sDEVICE=pdfwrite -sOutputFile=/tmp/testpage.pdf
  -dAutoRotatePages=/PageByPage -dAutoFilterColorImages=false
  -dColorImageFilter=/FlateEncode -dPDFSETTINGS=/prepress -c save pop -f
  spoolfile
 
  Alex:  have you tried the above test?  Could you please provide me and
  Volker with your results, so that we can resolve this issue? Thanks!
 
 Yes - I thought I had responded to it some time ago.
 
 The output is garbled, just like the original PDF printed out by the 
 cups-pdf printer.
 
 It turns out that the printing is only garbled when printing from my 
 Mac OS X computer - when I print from a Windows XP computer the 
 postscript works fine. So there's something the Mac OS X print system 
 does differently that causes cups-pdf to have a headache. If you are 
 prepared to pursue this bug to see what CUPS can do to better handle 
 printing from Mac OS X, I'd love to continue.
 
 Printing to PostScript laser printers works fine from this computer.
 
 I've stripped the command down to the following, that still produces 
 scrambled output:
 gs -sDEVICE=pdfwrite -dNOPAUSE -dBATCH -sOutputFile=out.pdf -c save pop 
 -f in.ps

What printer driver is your CUPS on the Mac OS X platform using? Perhaps
changing there to another PostScript driver will resolve the issue. 
(What I have in mind is that perhaps your Mac OS X driver uses a font
description which is not available on the Linux-server and for some
reason the font substitution fails.)

 Alex Satrapa
 Australian Phenomics Facility
 Building 117 Garran Road
 The Australian National University 
 Canberra ACT 0200 Australia
 
 T: +61 2 6125 1335
 F: +61 2 6125 1381
 W: www.apf.edu.au
 
 CRICOS Provider #0120C
-- 

Volker Christian Behr
Experimentelle Physik V (Biophysik), Physikalisches Institut
Universitaet Wuerzburg, Am Hubland, 97074 Wuerzburg, Germany

Office: Room F-069a
+49-931-888-5766 (phone)
+49-931-888-5851 (fax)




Bug#344872: cups-pdf creates 0 bytes pdf file.

2005-12-27 Thread Volker Christian Behr
A NFS mount is a possibility though that should not prevent logging
(except /var is also an NFS mount).
Is perhaps the RunAsUser option set to yes in CUPS? Then CUPS would not
run as root and therefore would fail for all CUPS-PDF operations except if
initiated by root.
If already the initialization of CUPS-PDF fails there could be a hint in
the error log of CUPS itself.

Martin-Ã#8240;ric Racine said:
 ti, 2005-12-27 kello 15:51 -0300, Andres Junge kirjoitti:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Martin-Ã#8240;ric Racine wrote:
  ti, 2005-12-27 kello 02:53 -0300, Andres Junge kirjoitti:
 
 Cups creates 0 byte pdf file as normal user. As root works ok.
 
  Please check /var/log/cups/cups-pdf_log and paste a copy of what it
  reports to [EMAIL PROTECTED] Thanks.

 Nothing. /var/log/cups/cups-pdf_log is an empty file (0 byte file).

 If CUPS-PDF had problems creating the file, it would have logged
 something about it automatically.

 Do you have an unusual situation involving e.g. home directories mounted
 via NFS that could perhaps have the worng mounting options?

 --
 Martin-Ã#8240;ric Racine
 http://q-funk.iki.fi



-- 

Volker Christian Behr
Experimentelle Physik V (Biophysik), Physikalisches Institut
Universitaet Wuerzburg, Am Hubland, 97074 Wuerzburg, Germany

Office: Room F-069a
+49-931-888-5766 (phone)
+49-931-888-5851 (fax)



Bug#343145: cups-pdf: graphics work, text is garbled

2005-12-15 Thread Volker Christian Behr
On Thu, 2005-12-15 at 04:41, Alex Satrapa wrote:
 On 14 Dec 2005, at 20:23, Volker Christian Behr wrote:
 
  This might also be due to some settings for character encoding. I 
  suggest
  the following tests:
 
  1st: print the CUPS printer test page to CUPS-PDF and check whether 
  there
  the text appears properly
 
 Test page works perfectly.
 
  2nd: create a postscript from a simple text file (e.g. by a2ps or 
  encode),
  check it with ghostview and print this postscript to CUPS-PDF
 
 I created a text file (blah.txt) containing the characters Blah, 
 then used a2ps to create  a PostScript file (blah.ps), a2ps blah.txt 
 -o blah.ps.
 
 The PostScript file looks fine, and cups-pdf converts it to PDF just 
 fine.

Ok, so we seem to only run into a problem if the PostScript is generated
by CUPS (with the PPD). 

  3rd: if 1st and 2nd work, to get to the PostScript file that is used by
  CUPS-PDF you will have to edit the source code of cups-pdf ...
 
 Finished this - the postscript in the CUPS spool (/var/spool/cups) and 
 the cups-pdf backend spool (/var/spool/cups-pdf/SPOOL) are identical 
 (which seems reasonable enough), and both render fine in kghostview 
 (I'm using KDE3 on my Linux workstations, Mac OS X 10.3 on my desktop).
 
 When trying to open one of the PostScript files in Preview (the Mac OS 
 X equivalent of Kghostview) I get the error, Can't create CMap 
 Adobe-Identity-UCS2. Does this provide any hints as to the nature of 
 the problem?
 
 I guess the next step is to go through the process that is automated by 
 cups-pdf to figure out at what point the damage is being done.

I do not know this error but it might be related to the problem. First I
would like to try to generate a PDF on the command line from the
spoolfile with options identicl to the ones CUPS-PDF uses. To do this,
execute the following command for spoolfile:

gs -q -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -dSAFER
-sDEVICE=pdfwrite -sOutputFile=/tmp/testpage.pdf
-dAutoRotatePages=/PageByPage -dAutoFilterColorImages=false
-dColorImageFilter=/FlateEncode -dPDFSETTINGS=/prepress -c save pop -f
spoolfile

Now gs should generate a PDF the same way as if invoked by cups-pdf. If
we still get garbled text we can debug without cups-pdf being involved
which will make things easier.



-- 

Volker Christian Behr
Experimentelle Physik V (Biophysik), Physikalisches Institut
Universitaet Wuerzburg, Am Hubland, 97074 Wuerzburg, Germany

Office: Room F-069a
+49-931-888-5766 (phone)
+49-931-888-5851 (fax)



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#343145: cups-pdf: graphics work, text is garbled

2005-12-14 Thread Volker Christian Behr
Alex Satrapa said:
 On 13 Dec 2005, at 17:51, Martin-Éric Racine wrote:

 1) Ghostscript versions that you use?
 dpkg -l gs-esp

 11:19 [0|16]% dpkg -l gs-esp
 [snip]
 ii  gs-esp   7.07.1-9 The Ghostscript PostScript
 interpreter - ESP ver

 2) DPI setting of your cups-pdf printer in CUPS preferences?

 DPI is set to 1200 default in the PPD.

 Note that CUPS-PDF is completely dependant [on]
 Ghostscript for the printing quality.

 This might be a ghostscript problem then, since the text is being
 garbled - as in encrypted, not drawn badly. For example, your message
 to me started with the text:

severity 343145 important
thanks

 while on the PDF version printed via CUPS-PDF, the starting text was:



2013!

 So by garbled I don't mean printed unclearly, I mean replaced with
 meaningless rubbish or perhaps even encrypted.

 The layout is great - almost pixel for pixel, but the actual glyphs
 that make up the text are replaced with other symbols. In fact,
 having a closer look at the text, it looks almost like a
 transliteration error:

 Note that CUPS-PDF is completely dependant upon the DPI resolution
 configured in CUPS via the printer management interface and upon
 Ghostscript for the printing quality.

 is replaced with:

 W/(20(UV@[EMAIL PROTECTED](%!(A/-.88'(D.1D01(C./1(2([EMAIL 
 PROTECTED]($!/8C%/1
 A/1E%BC$D(%1(UV@(#%0(2(.$%1$(-010B-1(%1$E0A(01D(C./1
 R2/!!A$%.(E/$(2(.$%1%1B(XC08%'G(

 If - as you already suggested - this is something I should take up with
 the gs-esp maintainer, please let me know. Otherwise I can try to
 capture the PostScript being sent from my computer to CUPS, in order to
 further test the CUPS-PDF printer - would it be enough to Stop the
 printer and simply snarf the files from the CUPS spool?


This might also be due to some settings for character encoding. I suggest
the following tests:

1st: print the CUPS printer test page to CUPS-PDF and check whether there
the text appears properly

2nd: create a postscript from a simple text file (e.g. by a2ps or encode),
check it with ghostview and print this postscript to CUPS-PDF

3rd: if 1st and 2nd work, to get to the PostScript file that is used by
CUPS-PDF you will have to edit the source code of cups-pdf: close to the
end of the code there are the lines:

if (unlink(spoolfile))
  log_event(CPERROR, failed to unlink spoolfile (non fatal), spoolfile);
else
  log_event(CPDEBUG, spoolfile unlinked, spoolfile);

Just remove or comment out this block, re-compile cups-pdf and the
spoolfile will stay after the printout.

-- 

Volker Christian Behr
Experimentelle Physik V (Biophysik), Physikalisches Institut
Universitaet Wuerzburg, Am Hubland, 97074 Wuerzburg, Germany

Office: Room F-069a
+49-931-888-5766 (phone)
+49-931-888-5851 (fax)



Bug#331183: synce-serial: [INTL:sv] Swedish debconf templates translation

2005-10-02 Thread Volker Christian
Hi

Thank you very much for the translation - i will be integrated in the next 
package.

best regards
voc

On Sunday 02 October 2005 09:15, Daniel Nylander wrote:
 Package: synce-serial
 Severity: wishlist
 Tags: patch l10n



 -- System Information:
 Debian Release: testing/unstable
   APT prefers unstable
   APT policy: (500, 'unstable'), (500, 'stable')
 Architecture: i386 (i686)
 Shell:  /bin/sh linked to /bin/bash
 Kernel: Linux 2.6.13.2
 Locale: LANG=sv_SE, LC_CTYPE=sv_SE (charmap=ISO-8859-1)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#331238: synce-serial: [INTL:fr] French debconf templates translation update

2005-10-02 Thread Volker Christian
Thank you very much for the update. I will integrate it into the synce-serial 
package soon.

regards
voc


On Sunday 02 October 2005 16:30, Michel Grentzinger wrote:
 Package: synce-serial
 Version: N/A
 Severity: wishlist
 Tags: patch l10n

 Hello,

 Please find the attached fr.po file, which is an update of the french
 translation of the debconf templates. This file has been reviewed by
 the contributors of the debian-l10n-french mailing-list.

 Could you put this file to the debian/po/ directory of this package,
 in remplacement of the old fr.po file ?

 Regards,

 -- System Information:
 Debian Release: 3.1
 Architecture: i386 (i686)
 Kernel: Linux 2.6.13
 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#330908: synce-kde: Raki segfaulting after partnership attempt

2005-09-30 Thread Volker Christian
Thank you for this report - this is a known problem when using g++-4.x.
I will fix this soon.

regards
voc


On Friday 30 September 2005 14:01, Hervé Leroux wrote:
 Package: synce-kde
 Version: 0.8.1.1-1.1
 Severity: grave
 Justification: renders package unusable

 (Bugs #328020  #327204 about package deps broken seems to be fixed
 today in Debian Sid).

 I start Raki (synce-kde) with vdccm.
 When putting my pda on craddle, raki detects the connection and asks for
 a password. That's ok. Then when trying to create a partnership, it
 checks if slots are available. So I decide to delete old partnerships
 made with MS Active Sync.
 Then, the application segfaults.

 Here are the stack calls :

 (no debugging symbols found)
 Using host libthread_db library /lib/tls/libthread_db.so.1.
 (no debugging symbols found)
 `system-supplied DSO at 0xe000' has disappeared; keeping its
 symbols.
 (no debugging symbols found)
 ... (many)
 (no debugging symbols found)
 [Thread debugging using libthread_db enabled]
 [New Thread -1232828736 (LWP 4674)]
 (no debugging symbols found)
 ... (many)
 (no debugging symbols found)
 [KCrash handler]
 #3  0x080772e8 in Rra::getTypes ()
 #4  0x0806f1c6 in PDA::getSynchronizationTypes ()
 #5  0x0806f67d in PDA::synchronizationTasks ()
 #6  0x0807c832 in ThreadEventObject::customEvent ()
 #7  0xb70b7dc3 in QObject::event () from /usr/lib/libqt-mt.so.3
 #8  0xb7050778 in QApplication::internalNotify () from
 /usr/lib/libqt-mt.so.3
 #9  0xb7050996 in QApplication::notify () from /usr/lib/libqt-mt.so.3
 #10 0xb77c99fc in KApplication::notify () from /usr/lib/libkdecore.so.4
 #11 0xb6fe0665 in QApplication::sendEvent () from /usr/lib/libqt-mt.so.3
 #12 0xb7051dac in QApplication::sendPostedEvents () from
 /usr/lib/libqt-mt.so.3
 #13 0xb7051ed9 in QApplication::sendPostedEvents () from
 /usr/lib/libqt-mt.so.3
 #14 0xb6ff38ae in QEventLoop::processEvents () from
 /usr/lib/libqt-mt.so.3
 #15 0xb7068ea2 in QEventLoop::enterLoop () from /usr/lib/libqt-mt.so.3
 #16 0xb7068dcb in QEventLoop::exec () from /usr/lib/libqt-mt.so.3
 #17 0xb704f305 in QApplication::exec () from /usr/lib/libqt-mt.so.3
 #18 0x08066e54 in main ()



 The connection with the PocketPC perfectly works using synce-serial
 (browsing remote FS, IP forwarding, installing cab and running
 programs...)


 -- System Information:
 Debian Release: testing/unstable
   APT prefers unstable
   APT policy: (500, 'unstable')
 Architecture: i386 (i686)
 Shell:  /bin/sh linked to /bin/bash
 Kernel: Linux 2.6.13.2
 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)
 (ignored: LC_ALL set to [EMAIL PROTECTED])

 Versions of packages synce-kde depends on:
 ii  agsync0.2-pre-8
 ii  kdelibs4c24:3.4.2-4
 ii  libart-2.0-2  2.3.17-1
 ii  libaudio2 1.7-3
 ii  libc6 2.3.5-6
 ii  libdynamite0  0.1-4
 ii  libfam0   2.7.0-8
 ii  libfontconfig12.3.2-1
 ii  libfreetype6  2.1.10-1
 ii  libgcc1   1:4.0.1-9
 ii  libice6   6.8.2.dfsg.1-7
 ii  libidn11  0.5.18-1
 ii  libjpeg62 6b-10
 ii  libmimedir0   0.4-4
 ii  liborange00.3-2
 ii  libpng12-01.2.8rel-4
 ii  libqt3-mt 3:3.3.5-1
 ii  librapi2  0.9.1-2
 ii  librra0   0.9.1-1
 ii  libsm66.8.2.dfsg.1-7
 ii  libstdc++64.0.1-9
 ii  libsynce0 0.9.1-2
 ii  libunshield0  0.5-3
 ii  libx11-6  6.8.2.dfsg.1-7
 ii  libxcursor1   1.1.3-1
 ii  libxext6  6.8.2.dfsg.1-7
 ii  libxft2   2.1.7-1
 ii  libxi66.8.2.dfsg.1-7
 ii  libxinerama1  6.8.2.dfsg.1-7
 ii  libxrandr26.8.2.dfsg.1-7
 ii  libxrender1   1:0.9.0-2
 ii  libxt66.8.2.dfsg.1-7
 ii  xlibs 6.8.2.dfsg.1-7
 ii  zlib1g1:1.2.3-4

 synce-kde recommends no packages.

 -- no debconf information



Bug#329441: agsync: FTBFS on GNU/kFreeBSD

2005-09-22 Thread Volker Christian
Hi,

thanks for the patch and the hint about config.guess and config.sub - i will 
prepare and upload a new package soon.

regards
voc

On Wednesday 21 September 2005 23:05, Aurelien Jarno wrote:
 Package: agsync
 Severity: important

 Hi,

 The current version of agsync fails to build on GNU/kFreeBSD. Please
 find attached a patch to fix that.

 Please also note that it needs an update of config.guess and config.sub,
 as these files are too old to correctly support Debian GNU/k*BSD. A
 version is needed from this year, which is available in the
 autotools-dev packages that are in current sarge, and sid.

 Could you please do that in the next upload?

 Thanks for your cooperation,
 Aurelien


 -- System Information:
 Debian Release: testing/unstable
 Architecture: kfreebsd-i386 (i686)
 Shell:  /bin/sh linked to /bin/bash
 Kernel: GNU/kFreeBSD 5.4-1-686
 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#328103: unshield: Unshield fails with linker problems

2005-09-13 Thread Volker Christian
There must be something wrong with your installation. I have just checked 
apt-get --build source unshield (version 0.4) on a clean debian machine and 
it works fine. Please check, if all parts of a self-compiled unshield 
(sourceforge CVS) or from a previous installation has been removed from your 
machine.

regards
voc


On Tuesday 13 September 2005 15:04, Markus Schaber wrote:
 Package: unshield
 Version: 0.5-2
 Severity: important

 Both unshield 0.4 (debian testing) and 0.5 (debian incoming, compiled
 with apt-get --build source) fail with the following error message:

 [/daten/q205/shapes/k1] {127} - unshield x /cdrom/k1/data2.cab
 2005-09-13 14:47:44
 Cabinet: /cdrom/k1/data2.cab
 unshield: symbol lookup error: unshield: undefined symbol:
 unshield_file_group_count

 Using a self-compiled unshield from sourceforge CVS works fine.

 Thanks,
 Markus


 -- System Information:
 Debian Release: testing/unstable
   APT prefers testing
   APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
 Architecture: i386 (i686)
 Shell:  /bin/sh linked to /bin/bash
 Kernel: Linux 2.6.11.11-madwifi-fire
 Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15)

 Versions of packages unshield depends on:
 ii  libc6 2.3.5-6GNU C Library: Shared
 libraries an ii  libunshield0  0.5-2  library to
 extracts CAB files from ii  zlib1g1:1.2.3-4 
 compression library - runtime

 unshield recommends no packages.

 -- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#326001: cups-pdf: [NFS] mkdir: cannot create directory `/home/ANONYMOUS': Permission denied

2005-09-01 Thread Volker Christian Behr
This looks to me as if the home was exported with root_squash from the
server. This will make cups-pdf fail in any case since it uses /home as
output directory on Debian. 
Martin-Éric - is it possible for the installation to check this and
issue an warning?

Volker

On Thu, 2005-09-01 at 08:53, Jari Aalto wrote:
 Package: cups-pdf
 Version: 1.7.3-3
 Severity: normal
 
 The /home directory can be NFS mounted and may cause following error.
 directly. Please take a look.
 
# mount | grep /home
# server:/home on /home type nfs 
 (rw,noatime,rsize=8192,wsize=8192,hard,intr,bg,addr=192.168.1.2)
 
 
 Install these packages without verification [y/N]? y
 Get:1 http://deb unstable/main cups-pdf 1.7.3-4 [17.4kB]
 Fetched 17.4kB in 1s (9535B/s)
 (Reading database ... 139867 files and directories currently installed.)
 Preparing to replace cups-pdf 1.7.3-3 (using .../cups-pdf_1.7.3-4_i386.deb) 
 ...
 mkdir: cannot create directory `/home/ANONYMOUS': Permission denied
 dpkg: error processing /var/cache/apt/archives/cups-pdf_1.7.3-4_i386.deb 
 (--unpack):
  subprocess pre-installation script returned error exit status 1
 Errors were encountered while processing:
  /var/cache/apt/archives/cups-pdf_1.7.3-4_i386.deb
 E: Sub-process /usr/bin/dpkg returned an error code (1)
 
 -- System Information:
 Debian Release: testing/unstable
   APT prefers unstable
   APT policy: (500, 'unstable')
 Architecture: i386 (i686)
 Shell:  /bin/sh linked to /bin/bash
 Kernel: Linux 2.6.12-1-686
 Locale: LANG=C, LC_CTYPE=C (charmap=ISO-8859-1) (ignored: LC_ALL set to en_US)
 
 Versions of packages cups-pdf depends on:
 ii  cupsys1.1.23-12  Common UNIX Printing System(tm) 
 - 
 ii  gs-esp8+8.15rc4.dfsg.1-2 The Ghostscript PostScript 
 interpr
 ii  libc6 2.3.5-6GNU C Library: Shared libraries 
 an
 
 cups-pdf recommends no packages.
 
 -- no debconf information
-- 

Volker Christian Behr
Experimentelle Physik V (Biophysik), Physikalisches Institut
Universitaet Wuerzburg, Am Hubland, 97074 Wuerzburg, Germany

Office: Room F-069a
+49-931-888-5766 (phone)
+49-931-888-5851 (fax)




Bug#325584: cups-pdf: installation failed: cannot create dir /home/ANONYMOUS

2005-09-01 Thread Volker Christian Behr
On Mon, 2005-08-29 at 21:40, Felipe Massia Pereira wrote:
 Kaare Hviid wrote:
  If /home is mounted over NFS via an automount map, root is unlikely to
  be able to create directories in /home.  While root can be configured
  to be allowed to write in individual home directories, it can't
  automatically create an automount map, which is very common in larger
  NFS setups.  Thus, it's very unfortunate that the debian/preinst script
  fails - if it has to create a /home/ANONYMOUS directory, could it
  possibly be set to just warn if it detects autofs?  Something along the
  lines of:
   ...
 
 Ok for this package, but the problem of creating a dir on an 
 autofs-mounted /home remains unsolved. Other packages will eventually 
 need to do this (anonymous ftp packages come to mind).
 
 I think there must be a way for the admin(box owner) to set the default 
 dir for creating new home dirs. I used useradd -D -b /l/home. I think 
 useradd is an optional package, though, and may be not there.
 
 Anyway, I wonder why do they create /home/ANONYMOUS and not 
 /var/cache/cups-pdf or alike. I need to read docs...

Usually cups-pdf uses /var/spool/cups-pdf for all output but I will
extend the possibilities for output destinations so the setup can be
better adapted for Debian.

Volker

 []s
 -- Felipe
-- 

Volker Christian Behr
Experimentelle Physik V (Biophysik), Physikalisches Institut
Universitaet Wuerzburg, Am Hubland, 97074 Wuerzburg, Germany

Office: Room F-069a
+49-931-888-5766 (phone)
+49-931-888-5851 (fax)



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#319353: cups-pdf: does printing also fail for non-anonymous users?

2005-08-14 Thread Volker Christian Behr
I recommend updating to version 1.7.3-1 from the unstable branch which is
already available for PPC. There were some issues with earlier versions on
some platforms that are fixed in 1.7.3.
If the error still exisits, we need to go into detail.

Volker

P.S.: Please also make sure output is directed to a non-root_squashed
filesystem.


Martin-Ã#8240;ric Racine said:
 A question that came to mind: Does printing also fail for non-anonymous
 users?

 --
 Martin-Eric Racine
 http://q-funk.iki.fi



-- 

Volker Christian Behr
Experimentelle Physik V (Biophysik), Physikalisches Institut
Universitaet Wuerzburg, Am Hubland, 97074 Wuerzburg, Germany

Office: Room F-069a
+49-931-888-5766 (phone)
+49-931-888-5851 (fax)



Bug#320352: synce-dccm: synce-sound fails to copy audio files from PDA

2005-07-29 Thread Volker Christian
Hi!

You are right, it should be synce-pcp. Thanks for this report.

regards
voc


On Thursday 28 July 2005 19:58, Antoine Boulart wrote:
 Package: synce-dccm
 Version: 0.9.0-1
 Severity: normal

 The script /usr/bin/synce-sound on lines 22 and 23 tries to use the binary
 /usr/bin/pcp to copy sound files from the PDA. On a debian system, I
 believe this should be synce-pcp.


 -- System Information:
 Debian Release: testing/unstable
   APT prefers testing
   APT policy: (990, 'testing'), (500, 'unstable')
 Architecture: i386 (i686)
 Shell:  /bin/sh linked to /bin/bash
 Kernel: Linux 2.6.12.3
 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

 Versions of packages synce-dccm depends on:
 ii  libc6   2.3.2.ds1-22 GNU C Library: Shared
 libraries an ii  libsynce0   0.9.0-3  A helper library
 for synce, a tool ii  sox 12.17.7-2A universal
 sound sample translato

 synce-dccm recommends no packages.

 -- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#300246: synce-serial: hotplug framework isn't used

2005-03-18 Thread Volker Christian
Yes, the hotplug mechanism didn't work quite well at the moment. But we are 
working on it.

regards
voc


On Friday 18 March 2005 15:34, Xavier Bestel wrote:
 Package: synce-serial
 Version: 0.9.0+cvs051204-2
 Severity: wishlist


 Hi,

 when using SynCE over USB, synce-serial-start has to be launched by
 hand by root. Apart from the obvious inconveniency caused, the problem
 is that sometimes the iPaq appears as /dev/ttyUSB1 instead of
 /dev/ttyUSB0 (and I suppose that if I plug several USB-to-serial
 devices, SynCE will get even more confused).
 Would it be possible to integrate synce-serial-start/abort with hotplug,
 to have it automatically start with the right /dev/ttyUSB? port ?

 Thanks,
  Xav

 -- System Information:
 Debian Release: 3.1
   APT prefers unstable
   APT policy: (500, 'unstable'), (1, 'experimental')
 Architecture: i386 (i686)
 Kernel: Linux 2.6.10-1-686-smp
 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8)

 Versions of packages synce-serial depends on:
 ii  debconf 1.4.46   Debian configuration
 management sy ii  hotplug 0.0.20040329-19  Linux Hotplug
 Scripts ii  libc6   2.3.2.ds1-20 GNU C Library: Shared
 libraries an ii  ppp 2.4.3-20041231+2 Point-to-Point
 Protocol (PPP) daem

 -- debconf information:
 * synce-serial/tty: /dev/ttyUSB0
 * synce-serial/dnsip: 192.168.1.1
 * synce-serial/remoteip: 192.168.131.201
 * synce-serial/localip: 192.168.131.102


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#300242: librra0: deadlock on unexpected escape

2005-03-18 Thread Volker Christian
Thank you for your report and patch. Nevertheless, this was a known problem 
which is already fixed in cvs.
I will prepare a fixed debian package soon.

regards
voc


On Friday 18 March 2005 15:21, Xavier Bestel wrote:
 Package: librra0
 Version: 0.9.0-2
 Severity: important
 Tags: patch


 I have setup an Evolution2/SynCE pair with multisync, but somehow
 Evolution had some entries ending with a '\' character. The problem is
 that librra then deadlock around contact.c:670.
 Here is a fix for that problem (note that you can't do source+=2
 otherwise you skip the EOS char) :

 --- lib/contact.c.orig  2005-03-18 14:49:45.0 +0100
 +++ lib/contact.c   2005-03-18 15:06:57.0 +0100
 @@ -668,6 +668,7 @@ static void unescape_string(char* value)

 default:
 synce_warning(Unexpected escape:
 '%c%c', source[0], source[1]); +  
 source++;
 break;
 }
 }


 -- System Information:
 Debian Release: 3.1
   APT prefers unstable
   APT policy: (500, 'unstable'), (1, 'experimental')
 Architecture: i386 (i686)
 Kernel: Linux 2.6.10-1-686-smp
 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8)

 Versions of packages librra0 depends on:
 ii  libc6   2.3.2.ds1-20 GNU C Library: Shared
 libraries an ii  libmimedir  0.4-2A library to
 parse RFC 2425 Direct ii  librapi20.9.0-6  Make
 RAPI calls to a WinCE device, ii  libsynce0   0.9.0-3 
 A helper library for synce, a tool

 -- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#300244: libsynce: could you package synce-gnome ?

2005-03-18 Thread Volker Christian
I will have a look at it - but i am not using gnome so this could take some 
time. In the meanwhile, please compile it yourself maybe you could contribute 
and prepare a debian package :-)

regards
voc


On Friday 18 March 2005 15:27, Xavier Bestel wrote:
 Package: libsynce
 Severity: wishlist


 I have discovered SynCE and quite like it. However I'd like to have the
 trayicon and gnome-vfs plugins, to fully use it. Could you please
 package them, say in a synce-gnome package like you did synce-kde ?

 Thanks,
 Xav

 -- System Information:
 Debian Release: 3.1
   APT prefers unstable
   APT policy: (500, 'unstable'), (1, 'experimental')
 Architecture: i386 (i686)
 Kernel: Linux 2.6.10-1-686-smp
 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#290824: Tools renamed but scripts not updated to reflect the change

2005-01-17 Thread Volker Christian
Thank you very much! I will prepare fixed packages soon!

regards
voc


On Monday 17 January 2005 01:45, Kimmo Jukarainen wrote:
 Package: librapi2-tools
 Version: 0.9.0-5
 Severity: important
 Tags: patch

 The binaries provided by librapi2-tools have changed from /usr/bin/pfoo
 to /usr/bin/synce-pfoo but scripts using these binaries have not been
 updated. At least following scrips are currently broken:

 from librapi2-tools (0.9.0-5):
   synce-install-cab
   synce-remove-program

 from synce-dccm (0.9.0-1):
   synce-sound

 The fix is trivial (sed s:bin/p:bin/synce-p:g) and I have attached a
 patch fixing the previously mentioned three scripts.

 -kimju


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]