Bug#905763: virtualbox-5.2: libcurl3 and libcurl4
Package: virtualbox-5.2 Version: 5.2.16-123759~Debian~stretch Severity: critical Justification: breaks unrelated software Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.16.0-2-amd64 (SMP w/12 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages virtualbox-5.2 depends on: ii adduser3.117 ii debconf [debconf-2.0] 1.5.67 ii libc6 2.27-3 ii libcurl3 7.60.0-1 ii libdevmapper1.02.1 2:1.02.145-4.1 ii libgcc11:8.1.0-9 ii libgl1 1.0.0+git20180308-3 ii libgl1-mesa-glx18.1.3-1 ii libopus0 1.3~beta+20180518-1 ii libpng16-161.6.34-1 ii libqt5core5a 5.10.1+dfsg-7 ii libqt5gui5 5.10.1+dfsg-7 ii libqt5opengl5 5.10.1+dfsg-7 ii libqt5printsupport55.10.1+dfsg-7 ii libqt5widgets5 5.10.1+dfsg-7 ii libqt5x11extras5 5.10.1-2 ii libsdl1.2debian1.2.15+dfsg2-1 ii libssl1.1 1.1.0h-4 ii libstdc++6 8.1.0-9 ii libvpx41.6.1-3+deb9u1 ii libx11-6 2:1.6.5-1 ii libxcb11.13-1 ii libxcursor11:1.1.15-1 ii libxext6 2:1.3.3-1+b2 ii libxinerama1 2:1.1.3-1+b3 ii libxml22.9.4+dfsg1-7+b1 ii libxmu62:1.1.2-2 ii libxt6 1:1.1.5-1 ii psmisc 23.1-1+b1 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages virtualbox-5.2 recommends: ii atril [pdf-viewer] 1.20.2-1 ii binutils 2.30.90.20180705-1 ii build-essential 12.5 ii dpkg-dev 1.19.0.5 ii evince [pdf-viewer] 3.28.2-1 ii gcc 4:7.3.0-3 ii kmod 25-1 ii libasound2 1.1.6-1 ii libgl1 1.0.0+git20180308-3 ii libpulse012.0-1 ii libsdl-ttf2.0-0 2.0.11-4 ii linux-headers-amd64 4.16+94 pn linux-image ii make 4.2.1-1 ii okular [pdf-viewer] 4:17.12.2-2 virtualbox-5.2 suggests no packages. -- debconf information: virtualbox/old-installation-found: virtualbox/old-running: virtualbox/group-vboxusers: virtualbox/module-compilation-failed:
Bug#895271: konqueror: crahses while running programms which try to start it
Package: konqueror Version: 4:17.08.3-2 Severity: critical Tags: upstream Justification: breaks unrelated software Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? trying to run stack haddock --open lens I get immediate a crash: Application: Konqueror (kdeinit5), signal: Aborted Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Current thread is 1 (Thread 0x7f0185b09780 (LWP 29858))] Thread 18 (Thread 0x7f010700 (LWP 29877)): #0 0x7f0176653273 in pa_mainloop_dispatch () at /usr/lib/x86_64-linux- gnu/libpulse.so.0 #1 0x7f01766536ce in pa_mainloop_iterate () at /usr/lib/x86_64-linux- gnu/libpulse.so.0 #2 0x7f0176653750 in pa_mainloop_run () at /usr/lib/x86_64-linux- gnu/libpulse.so.0 #3 0x7f01766615b9 in () at /usr/lib/x86_64-linux-gnu/libpulse.so.0 #4 0x7f01761fbc78 in () at /usr/lib/x86_64-linux- gnu/pulseaudio/libpulsecommon-11.1.so #5 0x7f018208e5aa in start_thread (arg=0x7f010700) at pthread_create.c:463 #6 0x7f0183c0fcbf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 17 (Thread 0x7f011cff9700 (LWP 29876)): #0 0x7f018209481a in futex_reltimed_wait_cancelable (private=, reltime=0x7f011cff89d0, expected=0, futex_word=0x7f011cff8b58) at ../sysdeps/unix/sysv/linux/futex-internal.h:142 #1 0x7f018209481a in __pthread_cond_wait_common (abstime=0x7f011cff8a70, mutex=0x7f011cff8b08, cond=0x7f011cff8b30) at pthread_cond_wait.c:533 #2 0x7f018209481a in __pthread_cond_timedwait (cond=0x7f011cff8b30, mutex=0x7f011cff8b08, abstime=0x7f011cff8a70) at pthread_cond_wait.c:667 #3 0x7f0155318552 in () at /usr/lib/x86_64-linux- gnu/libQt5WebEngineCore.so.5 #4 0x7f01552df82e in () at /usr/lib/x86_64-linux- gnu/libQt5WebEngineCore.so.5 #5 0x7f01552ba4bb in () at /usr/lib/x86_64-linux- gnu/libQt5WebEngineCore.so.5 #6 0x7f01552b6d38 in () at /usr/lib/x86_64-linux- gnu/libQt5WebEngineCore.so.5 #7 0x7f01552d370b in () at /usr/lib/x86_64-linux- gnu/libQt5WebEngineCore.so.5 #8 0x7f01552eb3e6 in () at /usr/lib/x86_64-linux- gnu/libQt5WebEngineCore.so.5 #9 0x7f01552e74fb in () at /usr/lib/x86_64-linux- gnu/libQt5WebEngineCore.so.5 #10 0x7f018208e5aa in start_thread (arg=0x7f011cff9700) at pthread_create.c:463 #11 0x7f0183c0fcbf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 16 (Thread 0x7f011d7fa700 (LWP 29875)): #0 0x7f01820944ec in futex_wait_cancelable (private=, expected=0, futex_word=0x557ac74c25b8) at ../sysdeps/unix/sysv/linux/futex- internal.h:88 #1 0x7f01820944ec in __pthread_cond_wait_common (abstime=0x0, mutex=0x557ac74c24f8, cond=0x557ac74c2590) at pthread_cond_wait.c:502 #2 0x7f01820944ec in __pthread_cond_wait (cond=0x557ac74c2590, mutex=0x557ac74c24f8) at pthread_cond_wait.c:655 #3 0x7f0155a6f8b0 in () at /usr/lib/x86_64-linux- gnu/libQt5WebEngineCore.so.5 #4 0x7f01552eae21 in () at /usr/lib/x86_64-linux- gnu/libQt5WebEngineCore.so.5 #5 0x7f01552e74fb in () at /usr/lib/x86_64-linux- gnu/libQt5WebEngineCore.so.5 #6 0x7f018208e5aa in start_thread (arg=0x7f011d7fa700) at pthread_create.c:463 #7 0x7f0183c0fcbf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 15 (Thread 0x7f011dffb700 (LWP 29874)): #0 0x7f01820944ec in futex_wait_cancelable (private=, expected=0, futex_word=0x7f011dffab38) at ../sysdeps/unix/sysv/linux/futex- internal.h:88 #1 0x7f01820944ec in __pthread_cond_wait_common (abstime=0x0, mutex=0x7f011dffaae8, cond=0x7f011dffab10) at pthread_cond_wait.c:502 #2 0x7f01820944ec in __pthread_cond_wait (cond=0x7f011dffab10, mutex=0x7f011dffaae8) at pthread_cond_wait.c:655 #3 0x7f01552df8a9 in () at /usr/lib/x86_64-linux- gnu/libQt5WebEngineCore.so.5 #4 0x7f01552df8d7 in () at /usr/lib/x86_64-linux- gnu/libQt5WebEngineCore.so.5 #5 0x7f01552ba46b in () at /usr/lib/x86_64-linux- gnu/libQt5WebEngineCore.so.5 #6 0x7f01552b6d38 in () at /usr/lib/x86_64-linux- gnu/libQt5WebEngineCore.so.5 #7 0x7f01552d370b in () at /usr/lib/x86_64-linux- gnu/libQt5WebEngineCore.so.5 #8 0x7f01552eb3e6 in () at /usr/lib/x86_64-linux- gnu/libQt5WebEngineCore.so.5 #9 0x7f01552e74fb in () at /usr/lib/x86_64-linux- gnu/libQt5WebEngineCore.so.5 #10 0x7f018208e5aa in start_thread (arg=0x7f011dffb700) at pthread_create.c:463 #11 0x7f0183c0fcbf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 14 (Thread 0x7f011e7fc700 (LWP 29873)): #0 0x7f01820944ec in futex_wait_cancelable (private=, expected=0, futex_word=0x557ac74b1328) at ../sysdeps/unix/sysv/linux/futex- internal.h:88 #1 0x7f01820944ec in __pthread_cond_wait_common (abstime=0x0, mutex=0x557ac74b12d8,
Bug#711236: Could it be?
That the following problem is related. I tried to upgrad redmine and I
come at least to the old Login page from redmine. After I try to login I
get the following backtrace:
Redirected to http://www.q-software-solutions.de/support/
Completed 302 Found in 302ms (ActiveRecord: 54.7ms)
NoMethodError (undefined method `options' for {:ctime=1371727458,
:atime=1371727458, :user_id=3}:Hash):
/usr/lib/ruby/vendor_ruby/rack/session/abstract/id.rb:329:in `commit_session'
Well in the start it seems it is a RakeSessionHash, but during this call
it's just an Hash?
Sorry I've not more information
Regards
Friedrich
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#476645: extra information
Ok, I spend another few hours on this problem, it seems this is a problem with the package management. I reinstalled complete fresh Debian distribution but just choose a a 2.6.22 Kernel, I rebuild this kernel here and used 4.2 vor compiling this kernel. Then I installed the gcc-4.2-multilib also and now the bug is gone. But it's still there on another machine running a 2.6.24 Kerrnel, although gcc-4.2 lib was installed there also. So I guess during dist-upgrade or such, the bug was introduced. Regards Friedrich -- Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#476645: Extra information (dpkg, ls) as requested
Here'e the output: Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name VersionBeschreibung +++--==- ii gcc 4:4.2.3-8 The GNU C compiler ii gcc-4.2 4.2.3-3The GNU C compiler ii gcc-4.2-multilib 4.2.3-3The GNU C compiler (multilib files) pn gcc-multilib keine(keine Beschreibung vorhanden) and insgesamt 220 -rw-r--r-- 1 root root 1608 25. Mär 06:52 crtbegin.o -rw-r--r-- 1 root root 2184 25. Mär 06:52 crtbeginS.o -rw-r--r-- 1 root root 1928 25. Mär 06:52 crtbeginT.o -rw-r--r-- 1 root root 1300 25. Mär 06:52 crtend.o -rw-r--r-- 1 root root 1544 25. Mär 06:52 crtendS.o -rw-r--r-- 1 root root 3656 25. Mär 06:52 crtfastmath.o -rw-r--r-- 1 root root 78946 25. Mär 06:54 libgcc.a -rw-r--r-- 1 root root 33260 25. Mär 06:54 libgcc_eh.a lrwxrwxrwx 1 root root38 19. Apr 08:11 libgcc_s.so - /emul/ia32-linux/usr/lib/libgcc_s.so.1 -rw-r--r-- 1 root root 25538 25. Mär 06:54 libgcov.a -rw-r--r-- 1 root root 45444 25. Mär 06:54 libgomp.a lrwxrwxrwx 1 root root37 19. Apr 08:11 libgomp.so - /emul/ia32-linux/usr/lib/libgomp.so.1 With best regards Friedrich -- Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus
Bug#476645: multilib is installed also
the gcc-4.2 multilib is installed, Package: gcc-multilib Status: install ok installed Priority: optional Section: devel Installed-Size: 20 Maintainer: Debian GCC Maintainers [EMAIL PROTECTED] Architecture: amd64 Source: gcc-defaults (1.69) Version: 4:4.2.3-7 but it seems this is not good because above I found also Package: cpp-4.2 Status: install ok installed Priority: optional Section: interpreters Installed-Size: 6068 Maintainer: Debian GCC Maintainers [EMAIL PROTECTED] Architecture: amd64 Source: gcc-4.2 Version: 4.2.3-3 Depends: gcc-4.2-base (= 4.2.3-3), libc6 (= 2.7-1) Suggests: gcc-4.2-locales (= 4.2.3-1) Conflicts: cpp-4.2 ( 4.2-20070307), g++-4.2 ( 4.2-20070307), g++-4.2-multilib ( 4.2-20070307), gcc-4.2 ( 4.2-20070307), gcc-4.2-multilib ( 4.2-20070307), gcj-4.2 ( 4.2-20070307), gfortran-4.2 ( 4.2-20070307), gfortran-4.2-multilib ( 4.2-20070307), gobjc++-4.2 ( 4.2-20070307), gobjc++-4.2-multilib ( 4.2-20070307), gobjc-4.2 ( 4.2-20070307), gobjc-4.2-multilib ( 4.2-20070307), treelang-4.2 ( 4.2-20070307) So it seems one of the other is fine, but that seems not to be the case, however the dependencies should be taken care of by apt or not? Regards Friedrich -- Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#443666: projectcenter.app: Fresh install and generatd code does not compile
Package: projectcenter.app Version: 0.4.3-3+b1 Severity: normal Very simple problem. I let Projectcenter genarte the a Tools application while trying to compile the generated code I got: main.m:25:35: warning: Foundation/Foundation.h. Datei oder Verzeichnis nicht gefunden (file not found!!) It's fresh install of all the GNUStep stuff.. Regards Friedrich -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.21-2-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages projectcenter.app depends on: ii gnustep-back0.11 0.11.0-3 The GNUstep GUI Backend ii gnustep-base-runtime 1.13.0-7 GNUstep Base library ii gnustep-gpbs 0.11.0-3 The GNUstep PasteBoard Server ii gnustep-gui-runtime 0.11.0-2 GNUstep GUI Library - runtime file ii libc6 2.6.1-1GNU C Library: Shared libraries ii libgnustep-base1.13 1.13.0-7 GNUstep Base library ii libgnustep-gui0.110.11.0-2 GNUstep GUI Library ii libobjc2 4.2.1-4Runtime library for GNU Objective- Versions of packages projectcenter.app recommends: ii gorm.app 1.1.0-1+b1 Visual Interface Builder for GNUst -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#425838: The updated gdb is not in Lenny
My system is a Lenny one and there the new package is not there. So I had to go to the sid/unstable to get the updated gdb. Regards Friedrich -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#443666: package problem?
Maybe it's problem of packaging and dependencies. After installing libgnustep-base-dev. At least the program could be compiled. But according to the GNUstep pages, one has to do the following to install all what is needed: apt-get install gnustep gnustep-devel gnustep-games but gnustep-devel does not load the -dev libraries But even if that is overcome the next problem still is there. I just can tell I had reported it to the GNUStep people around 3-6 months before. I will open a new bug on that... Regards Friedrich -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#443676: projectcenter.app: Debugging an application failed with no such error found
Package: projectcenter.app Version: 0.4.3-3+b1 Severity: important In Projectcenter after having compiled a Foundation tool. trying to launch or debug a package failed: Error while launching: usr/lib/GNUstep/System/Tools/opentool: line 163: /home/frido/programming/Objective-C/test1/test1: Datei oder Verzeichnis nicht gefunden Error while trying to debug: Message Box with the content: Can't execute test1.debug That's no suprise because the output is placed in shared_obj and there is no symbolic link into the directory. You can solve it while adding this symbolic link but that surely means one has to know how to get around with that. And a test1.debug simply does not exist. And so one has to dig what might cause the trouble. This are so elementary problems that's hard to believe anyone has ever installed ProjectCenter -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.21-2-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages projectcenter.app depends on: ii gnustep-back0.11 0.11.0-3 The GNUstep GUI Backend ii gnustep-base-runtime 1.13.0-7 GNUstep Base library ii gnustep-gpbs 0.11.0-3 The GNUstep PasteBoard Server ii gnustep-gui-runtime 0.11.0-2 GNUstep GUI Library - runtime file ii libc6 2.6.1-1GNU C Library: Shared libraries ii libgnustep-base1.13 1.13.0-7 GNUstep Base library ii libgnustep-gui0.110.11.0-2 GNUstep GUI Library ii libobjc2 4.2.1-4Runtime library for GNU Objective- Versions of packages projectcenter.app recommends: ii gorm.app 1.1.0-1+b1 Visual Interface Builder for GNUst -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#373290: libapr0-dev: Outdated header files?
Package: libapr0-dev
Version: 2.0.55-4
Severity: serious
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.11
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Versions of packages libapr0-dev depends on:
ii libapr0 2.0.55-4 the Apache Portable Runtime
ii libdb4.3-dev 4.3.29-3 Berkeley v4.3 Database Libraries [
ii libexpat1-dev 1.95.8-3 XML parsing C library - developmen
ii libldap2-dev 2.1.30-12 OpenLDAP development libraries
ii libpcre3-dev 6.4-1.1Perl 5 Compatible Regular Expressi
ii libtool 1.5.22-1 Generic library support script
libapr0-dev recommends no packages.
-- no debconf information
Could it be that the headers are outdated? I installed the very last
package and I got also the sources from libpar. In the debian package
and the apr_file_info.h header one finds:
/**
* @defgroup apr_file_permissions File Permissions flags
* @{
*/
#define APR_USETID 0x8000 /** Set user id */
#define APR_UREAD 0x0400 /** Read by user */
#define APR_UWRITE 0x0200 /** Write by user */
#define APR_UEXECUTE0x0100 /** Execute by user */
#define APR_GSETID 0x4000 /** Set group id */
#define APR_GREAD 0x0040 /** Read by group */
#define APR_GWRITE 0x0020 /** Write by group */
#define APR_GEXECUTE0x0010 /** Execute by group */
#define APR_WSTICKY 0x2000 /** Sticky bit */
#define APR_WREAD 0x0004 /** Read by others */
#define APR_WWRITE 0x0002 /** Write by others */
#define APR_WEXECUTE0x0001 /** Execute by others */
#define APR_OS_DEFAULT 0x0FFF /** use OS's default permissions */
/* additional permission flags for apr_file_copy and apr_file_append */
#define APR_FILE_SOURCE_PERMS 0x1000 /** Copy source file's permissions */
In the sources of libapr this looks very different:
/**
* @defgroup apr_file_permissions File Permissions flags
* @{
*/
#define APR_FPROT_USETID 0x8000 /** Set user id */
#define APR_FPROT_UREAD 0x0400 /** Read by user */
#define APR_FPROT_UWRITE 0x0200 /** Write by user */
#define APR_FPROT_UEXECUTE0x0100 /** Execute by user */
#define APR_FPROT_GSETID 0x4000 /** Set group id */
#define APR_FPROT_GREAD 0x0040 /** Read by group */
#define APR_FPROT_GWRITE 0x0020 /** Write by group */
#define APR_FPROT_GEXECUTE0x0010 /** Execute by group */
#define APR_FPROT_WSTICKY 0x2000 /** Sticky bit */
#define APR_FPROT_WREAD 0x0004 /** Read by others */
#define APR_FPROT_WWRITE 0x0002 /** Write by others */
#define APR_FPROT_WEXECUTE0x0001 /** Execute by others */
#define APR_FPROT_OS_DEFAULT 0x0FFF /** use OS's default permissions */
/* additional permission flags for apr_file_copy and apr_file_append */
#define APR_FPROT_FILE_SOURCE_PERMS 0x1000 /** Copy source file's permissions
*/
/* backcompat */
#define APR_USETID APR_FPROT_USETID /** @deprecated @see
APR_FPROT_USETID */
#define APR_UREAD APR_FPROT_UREAD /** @deprecated @see
APR_FPROT_UREAD */
#define APR_UWRITE APR_FPROT_UWRITE /** @deprecated @see
APR_FPROT_UWRITE */
#define APR_UEXECUTE APR_FPROT_UEXECUTE /** @deprecated @see
APR_FPROT_UEXECUTE */
#define APR_GSETID APR_FPROT_GSETID /** @deprecated @see
APR_FPROT_GSETID */
#define APR_GREAD APR_FPROT_GREAD /** @deprecated @see
APR_FPROT_GREAD */
#define APR_GWRITE APR_FPROT_GWRITE /** @deprecated @see
APR_FPROT_GWRITE */
#define APR_GEXECUTE APR_FPROT_GEXECUTE /** @deprecated @see
APR_FPROT_GEXECUTE */
#define APR_WSTICKYAPR_FPROT_WSTICKY/** @deprecated @see
APR_FPROT_WSTICKY*/
#define APR_WREAD APR_FPROT_WREAD /** @deprecated @see
APR_FPROT_WREAD */
#define APR_WWRITE APR_FPROT_WWRITE /** @deprecated @see
APR_FPROT_WWRITE */
#define APR_WEXECUTE APR_FPROT_WEXECUTE /** @deprecated @see
APR_FPROT_WEXECUTE */
#define APR_OS_DEFAULT APR_FPROT_OS_DEFAULT /** @deprecated @see
APR_FPROT_OS_DEFAULT */
#define APR_FILE_SOURCE_PERMS APR_FPROT_FILE_SOURCE_PERMS /** @deprecated @see
APR_FPROT_FILE_SOURCE_PERMS */
/** @} */
Regards
Friedrich
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#373290: closed by Thom May [EMAIL PROTECTED] (Re: Bug#373290: libapr0-dev: Outdated header files?)
[EMAIL PROTECTED] (Debian Bug Tracking System) writes:
This is an automatic notification regarding your Bug report
#373290: libapr0-dev: Outdated header files?,
which was filed against the libapr0-dev package.
It has been closed by Thom May [EMAIL PROTECTED].
Their explanation is attached below. If this explanation is
unsatisfactory and you have not received a better one in a separate
message then please contact Thom May [EMAIL PROTECTED] by replying
to this email.
Debian bug tracking system administrator
(administrator, Debian Bugs database)
From: Thom May [EMAIL PROTECTED]
Subject: Re: Bug#373290: libapr0-dev: Outdated header files?
To: Friedrich Dominicus [EMAIL PROTECTED], [EMAIL PROTECTED]
Date: Wed, 14 Jun 2006 10:27:40 +0100
You're attempting to compare APR 1.2 from upstream (which is available in
debian in the libapr1{,-dev} packages to APR 0.9, which is a
differently
Well this is difficult to understand the debian package system
description says:
unstable (net): the Apache Portable Runtime
2.0.55-4: alpha amd64 arm hppa i386 ia64 kfreebsd-i386 m68k mips
mipsel powerpc s390 sparc
and well that seems to go with the apache2 I'm using so I was thinking
this is the most actual library.
I'm sorry if I did get that wrong, but I hope one can see how
it has come to this misunderstanding.
Regards
Friedrich
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329334: Well how about removing the package then
I installed the packages just a 5 days or so ago. If it's orphaned why is is there still then? Regards Friedrich -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329347: Well I do not have a decent suggestion
just I found this problem and I had to change the setting manually. If someone installs the package as I did and is afraid on changing things he or she is stuck. It shouldn't be all to hard to check if there is a group named after the user, and act accordingly. Regards Friedrich -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329334: acl-alisp8: bug in alisp8.sh?
Package: acl-alisp8 Version: 6.2.32 Severity: normal I found the following in that file case $1 in rebuild) echo $0 Rebuilding packages... shift while [ -x $acl_dir/$lisp_builder -a ! -z $1 ] ; do echo ...rebuilding $1 /usr/bin/$lisp_target -q -batch -L $acl_dir/siteinit.cl -e (let ((*compile-print* nil) (*compile-progress* nil) (*compile-verbose* nil) (*require-verbose* nil) (*load-verbose* nil)) with high likliness you do not want to have /usr/bin/$lisp_target but $acl_dir/$lisp_builder why should one check for an executable file in the while if one does not use it. If one installed AllegroCL. If that is still correct how should one know that there should be e.g a /usr/bin/alisp8 ? Regards Friedrich -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages acl-alisp8 depends on: ii acl-pro-installer 6.2.32 Installer for Franz' Allegro 6.2 L ii common-lisp-controller4.18 This is a Common Lisp source and c Versions of packages acl-alisp8 recommends: ii acldoc-el 6.2.32 Display AllegroCL documentation fr -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329347: common-lisp-controller: checking of permissions of the output directory
Package: common-lisp-controller Version: 4.18 Severity: minor Well AFAIFK is the standard policy for adding new users to the system as follows. - the user is created - a groups is created also so if I do a adduser foobar a group foobar will generated to If that is true then the following check should probably be changed (file post-sysdef-install.lisp) (unless (= 0 (logand mode #o022)) should be (unless (= 0 (logand mode #o002)) or one has to check - if the user has it's own group whether the permissions are ok then. With best regards Friedrich -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages common-lisp-controller depends on: ii bash 3.0-14 The GNU Bourne Again SHell ii cl-asdf 1.86-2 Another System Definition Facility ii debconf [debconf-2.0] 1.4.48 Debian configuration management sy ii debianutils 2.13.2 Miscellaneous utilities specific t ii perl 5.8.7-4Larry Wall's Practical Extraction ii realpath 1.9.20 Return the canonicalized absolute common-lisp-controller recommends no packages. -- debconf information: * common-lisp-controller/long-site-name: * common-lisp-controller/short-site-name: flarge -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
