Bug#311439: crossfire: non-free file lib/adm/map_check
On Wed, 01 Jun 2005, Kenshi Muto wrote: > Hi, > > here is a proposed source package. Hi, Kari is preparing the upload and I am going to sponsor it if needed. --j -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#183871: sfs on ppc
On Thu, 02 Jun 2005, the Edward Blevins wrote: > > Make sure you give both, CFLAGS and CXXFLAGS. I just tested, > > the problem and workaround are there, on current sid and > > gcc version there. > > Yes. I got this work around to work. Thanks a bunch. Would it be > possible to add a check for powerpc to do this automatically (at least > until the problem is acutally fixed)? It would be wonderful to be able > to just apt-get it and have it work. Tried that, but I could not find a way to feed the flags in rules file without the whole build system overriding all flags and breaking here and there as concequence. Have to see if this problem still exists with gcc 4.x. --j -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#268122: Addendum
This happens with exec-shield also, and can be worked around with either setarch or "echo 1 >/proc/sys/kernel/exec-shield-randomize". Wonder how Fedora manages to run ntpd, as they have exec-shield turned on by default (iirc). At least: http://www.mirrorservice.org/sites/download.fedora.redhat.com/pub/fedora/linux/core/development/SRPMS/ntp-4.2.0.a.20040617-6.src.rpm%5Bpeek%5D Shows nothing obivious. --j -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#293787: linux-wlan-ng: -pre21 includes firmware files with no license
Package: linux-wlan-ng Version: 0.2.0+0.2.1pre21-1.1 Severity: serious Justification: Policy 2.3 From upstream changelog of -pre21: - Primary/Secondary firmware (finally) bundled with the driver. src/prism2/*.hex are the files, and there is no license or even copyright for them anywhere. --j -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#183871: sfs on ppc
On Mon, 07 Feb 2005, the Edward Blevins wrote: > On Sat, 27 Mar 2004, Jaakko Niemi wrote: > >This seems to be gcc issue. If you build it with -O0, it will > >work. If you have bit of time, please try -O1 and -O also, so > >we can even see what the optimization level is that brings > >trouble. > > I am still having this exact same problem with version > 1:0.8-0+pre20041016.1-1 and recompiling the package with -O0 > seems to make no difference. I am still getting the "arg marshaling > failed" message in syslog. Make sure you give both, CFLAGS and CXXFLAGS. I just tested, the problem and workaround are there, on current sid and gcc version there. --j -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#301621: partimage-server: infernal loopy problems
Package: partimage-server Version: 0.6.4-10.1 Severity: important Only configuration on serverside was creation of partimagedusers file, and change of image directory. Client is same version. Here's debug log: -- [Main] netserver.cpp->AcceptClient#148: received banner for client 0: 0.6.4 SSL LOG [Main] netserver.cpp->AcceptClient#153: wrong banner received from 192.168.1.88:46954 [Main] netserver.h->Send#63: before GET: 0 [Main] netserver.h->Send#65: after GET: 0 [Main] net.cpp->nSend#30: begin # 13 for 5 bytes [Main] net.cpp->nSend#33: send avec ssl [Main] net.cpp->nSend#42: end ret=5 [Main] netserver.h->Send#63: before GET: 0 [Main] netserver.h->Send#65: after GET: 0 [Main] net.cpp->nSend#30: begin # 14 for 8 bytes [Main] net.cpp->nSend#33: send avec ssl [Main] net.cpp->nSend#42: end ret=8 [Main] partimaged-client.cpp->Release#84: 0 released [Main] netserver.cpp->AcceptClient#170: THROW: -36 [Main] exceptions.cpp->CExceptions#88: AcceptClient -> throws: -36 [Main] partimaged-main.cpp->main#383: *** excep catched [Main] partimaged-main.cpp->main#400: refused: banner or version [Main] partimaged-main.cpp->main#379: infernal loop -- -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.12-rc1 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8) Versions of packages partimage-server depends on: ii debconf 1.4.46 Debian configuration management sy ii libbz2-1.0 1.0.2-5 high-quality block-sorting file co ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an ii libgcc1 1:3.4.3-12 GCC support library ii libnewt0.51 0.51.6-21Not Erik's Windowing Toolkit - tex ii libpam0g0.76-22 Pluggable Authentication Modules l ii libssl0.9.7 0.9.7e-3 SSL shared libraries ii libstdc++5 1:3.3.5-12 The GNU Standard C++ Library v3 ii openssl 0.9.7e-3 Secure Socket Layer (SSL) binary a ii slang1a-utf81.4.9dbs-8 The S-Lang programming library wit ii zlib1g 1:1.2.2-4compression library - runtime -- debconf information: * partimage-server/run_on_boot: false * partimage-server/images: /usr/local/media/partimaged partimage-server/create_certs: true -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#295297: possibly vulnerable to dns hostname issues (CAN-2004-1485)
On Tue, 05 Apr 2005, Joey Hess wrote: > Jaakko, > I was reminded that this bug has been open for 7 weeks with no reaction. > It's a minor and somewhat hypothetical security hole, but we have a fix > for it; do you plan to close the bug soon? Uh, it got buried under other things. Yeah, the fix is trivial, but I won't have time to even look at it this week, so if you feel like, please NMU. If not, I'll ask Twin or someone to do it. Btw, did someone inform upstream? There is no new upstream version, and I at least could not find anything grepping the subject lines of syslinux list archives.. --j -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#327377: ion3: ignores bindings
Package: ion3 Version: 20050820-3 Severity: important Starting with 20050820-1, ~/.ion3/cfg_bindings.lua is ignored, according to strace, ion3 does not even try to read it. Reverting back to 20050728-5 fixes this. At least one other person in irc confirmed this. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.13-rc6 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8) Versions of packages ion3 depends on: ii libc6 2.3.5-6GNU C Library: Shared libraries an ii libice6 6.8.2.dfsg.1-6 Inter-Client Exchange library ii liblua50 5.0.2-5Main interpreter library for the L ii liblualib50 5.0.2-5Extension library for the Lua 5.0 ii libsm66.8.2.dfsg.1-6 X Window System Session Management ii libx11-6 6.8.2.dfsg.1-6 X Window System protocol client li ii libxext6 6.8.2.dfsg.1-6 X Window System miscellaneous exte ii libxinerama1 6.8.2.dfsg.1-6 X Window System multi-head display ii xlibs 6.8.2.dfsg.1-6 X Window System client libraries m ion3 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#326101: sfs_1:0.8-0+pre20050819.1-1(m68k/unstable/vault13): FTBFS on m68k
On Thu, 01 Sep 2005, Stephen R Marenka wrote: > Package: sfs > Version: 1:0.8-0+pre20050819.1-1 > Severity: serious > Justification: fails to build on release candidate arch. > Tags: sid Noticed same thing on other archs, and I have upload prepared and will do it after I get few other issues sorted. So, please do not touch sfs during BSP this weekend. If someone wants to help out and has fast PPC box, #183871 is there still. Needs to be verified with gcc 4 and real bug filed. --j -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#326271: sfs: Did not change package name for C++ ABI transition.
On Fri, 02 Sep 2005, Kurt Roeckx wrote: > Package: sfs > Version: 1:0.8-0+pre20050819.1-1 > Severity: grave > > Hi, > > Your package did not change from libsfs0 to libsfs0c2 as it > should have for the C++ ABI transition. This was intentionally left late, as I knew that it will blow up anyway on several arches. Upload tomorrow will take care of this. --j -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#326269: sfs: FTBFS on 64 bit arches: cast from 'dataPtr*' to 'int' loses precision
On Fri, 02 Sep 2005, Kurt Roeckx wrote: > I assume this is a other error than #113451 which is > supposed to be fixed. Older build logs do seem to have > this problem too however. It was just a warning with > older versions of g++. Already fixed in my tree that I'm about to upload tomorrow. --j -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#295297: Followup
On Sat, 30 Jul 2005, Micah Anderson wrote: > On Tue, 05 Apr 2005, Joey Hess wrote: > > >> Jaakko, I was reminded that this bug has been open for 7 weeks with > >> no reaction. It's a minor and somewhat hypothetical security hole, > >> but we have a fix for it; do you plan to close the bug soon? > > > Uh, it got buried under other things. Yeah, the fix is trivial, but > > I won't have time to even look at it this week, so if you feel like, > > please NMU. If not, I'll ask Twin or someone to do it. > > This was back in April, you said you didn't have time that week, > almost three months have passed. Have you asked Twin to do it instead, > and this person neglected to follow-up on it as well? Got buried under other things as this thing is not exploitable. > >> Btw, did someone inform upstream? There is no new upstream version, > >> and I at least could not find anything grepping the subject lines > >> of syslinux list archives.. > > >No, I didn't inform upstream, I figured you knew how to best pass it on > >to them. > > Have you informed upstream? Yes, and his answer: | It's not a security hole, since it would only be exploitable if you can | substitute libc, in which case you have root on the machine anyway. | | Might as well clean it up to keep the whiners quiet, though. | |-hpa --j -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#320630: libc6-dev: /usr/include/sys/socket.h broken with g++ 4.x
Package: libc6-dev
Version: 2.3.5-2
Severity: normal
Tags: patch
/usr/include/sys/socket.h has the definitions of SHUT_* in
a anonymous enum. g++ 4 started enforcing C++ standard part
which forbids using anonymous enums as template arguments.
Please see the thread starting with:
http://lists.debian.org/debian-devel/2005/07/msg01486.html
for more discussion about this. So, please just ditch the
enum and leave #defines.
--- /usr/include/sys/socket.h 2005-07-17 13:10:29.0 +0300
+++ socket.h2005-07-30 21:39:29.0 +0300
@@ -46,15 +46,9 @@
/* The following constants should be used for the second parameter of
`shutdown'. */
-enum
-{
- SHUT_RD = 0, /* No more receptions. */
#define SHUT_RDSHUT_RD
- SHUT_WR, /* No more transmissions. */
#define SHUT_WRSHUT_WR
- SHUT_RDWR/* No more receptions or transmissions. */
#define SHUT_RDWR SHUT_RDWR
-};
/* This is the type we use for generic socket address arguments.
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (990, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.13-rc3
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8)
Versions of packages libc6-dev depends on:
ii libc6 2.3.5-2 GNU C Library: Shared libraries an
ii linux-kernel-headers 2.6.13+0rc3-1 Linux Kernel Headers for developme
Versions of packages libc6-dev recommends:
ii gcc [c-compiler] 4:4.0.0-2 The GNU C compiler
ii gcc-3.3 [c-compiler] 1:3.3.6-7 The GNU C compiler
ii gcc-4.0 [c-compiler] 4.0.1-2The GNU C compiler
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#319771: sfs-common: can't install SFS in sid
tags 319771 +pending thanks On Sun, 24 Jul 2005, Francois Gurin wrote: > Package: sfs-common > Version: 1:0.8-0+pre20041016.1-1 > Severity: grave > Justification: renders package unusable > > > > SFS packages have a dependency on libgmp3 which is not available on sid. > It has been replaced with libgmp3c2. Sorry about the delay. I've been working on getting sfs compile with gcc4. All problems have been identified, and basically things depend on glibc 2.3.5 getting into unstable and #320630. --j -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#320630: libc6-dev: /usr/include/sys/socket.h broken with g++ 4.x
On Sat, 30 Jul 2005, Christoph Hellwig wrote: > > Please see the thread starting with: > > > > http://lists.debian.org/debian-devel/2005/07/msg01486.html > > > > for more discussion about this. So, please just ditch the > > enum and leave #defines. > > No, changing headers that way is a bad idea. Fix your program to > not assume whether constants are anonymous unions or defines. What is the enum needed for? --j -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#405349: enemies-of-carlotta: traceback with NameError: global name 'warning' is not defined
Package: enemies-of-carlotta
Version: 1.2.4
Severity: important
<[EMAIL PROTECTED]>: Command died with status 1:
"/usr/local/bin/deliver-to-eoc". Command output: Traceback (most recent
call last): File "/usr/local/bin/enemies-of-carlotta", line 16, in ?
eoc.main(sys.argv[1:]) File
"/usr/local/share/enemies-of-carlotta/eoc.py", line 1697, in main
mlm.incoming_message(skip_prefix, domain, moderate, post) File
"/usr/local/share/enemies-of-carlotta/eoc.py", line 408, in
incoming_message list.obey(dict) File
"/usr/local/share/enemies-of-carlotta/eoc.py", line 1094, in obey
self.obey_post(dict, text) File
"/usr/local/share/enemies-of-carlotta/eoc.py", line 993, in obey_post
self.post_into_moderate(poster, dict, text) File
"/usr/local/share/enemies-of-carlotta/eoc.py", line 958, in
post_into_moderate { File
"/usr/local/share/enemies-of-carlotta/eoc.py", line 590, in send_template
text = self.mime_encode_headers(text) File
"/usr/local/share/enemies-of-carlotta/eoc.py", line 554, in
mime_encode_headers warning("Cannot MIME encode header, using original
ones, sorry") NameError: global name 'warning' is not defined
-- System Information:
Debian Release: 4.0
APT prefers unstable
APT policy: (990, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#402705: culprit found
http://bugs.debian.org/cgi-bin/bugreport.cgi/slapd-init.patch?bug=390337;msg=5;att=1 piddir being /var/run ... paperbagbug. --j -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#272882: Confusing /etc/default setting
On Wed, 16 Feb 2005, Rainer Bawidamann wrote: > I.e. "RUN_DAEMON=yes" means to _not_ run it as a daemon ... Please observe bug #293040 and how it was closed by last upload. --j -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#296887: dancer-ircd-doc: borks on upgrade/installation
Package: dancer-ircd-doc Version: 1.0.32-2 Severity: normal Setting up dancer-ircd-doc (1.0.36-1) ... cannot create dhelp file '/usr/share/doc/dancer-ircd/dancer-user-guide/html/.dhelp': Tiedostoa tai hakemistoa ei ole dpkg: error processing dancer-ircd-doc (--configure): subprocess post-installation script returned error exit status 2 Errors were encountered while processing: dancer-ircd-doc 'xcuse my finnish, the directory does not exist. I do not have any other of dancer-* packages installed. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.9 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#408325: sfsauthd: fatal: Should not be reached - server fails on arm nslu2
Hello, I got access to an ARM box, and was unable to reproduce this problem. Linux debian 2.6.18-4-iop32x #1 Sat Feb 3 12:15:12 UTC 2007 armv5tel GNU/Linux The machine was running couple months old sid, and it was upgraded to this day, but in either case, everything works just fine. The only difference in package versions that I can see is libc6, 2.3.6.ds1-10 vs. 2.3.6.ds1-11. --j -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#408325: sfsauthd: fatal: Should not be reached - server fails on arm nslu2
On Wed, 24 Jan 2007, Brian Brunswick wrote: > Package: sfs-server > Version: 1:0.8-0+pre20060720.1-1 > Severity: grave > Justification: renders package unusable > > > While sfs-client seems to work ok onto another server, I get sfsauthd crashing > out and exiting leaving the above message in the syslog, when I do: > sfskey register > while trying to set up a server. (after sfskey gen) Sorry about the delay, I've been awfully busy with work. For starters, please do shut down the server, and start sfssd manually with -d switch, and see if any additional information is outputted. This seems unreproducible on other platforms, and given that the authentication function just runs to the end, I'm thinking that something (PAM or shadow) broke on ARM. Do you have possibility to rebuild sfs on your machine? (quite a few hours and >500mb of disk needed..) --j -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#389389: Opinion
Hello, I took a look at the bug and preinst, and got the feeling that there's too much mucking around with this syslog stuff. The current setup does not seem to handle at all the situation where I have already all "local" facilities used (yes, I do have two such machines..). It would be much nicer if ndtpd would by default just log to "daemon" facility and leave system administrator to worry about "local" facilities. --j -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#384381: More info needed, trac bug #384381
Hello, Somehow I suspect that trac needs versioned dep to python-subversion... Can you reproduce this with python-subversion 1.4.0 ? (provides python2.4-subversion ...) --j -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#378019: epic4: New upstream version 2.4
And which sunday would that be? :) Bug me if you need any help. --j -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#699532: Dependency chain
Hello, Any news on this? We have now nasty situation as leiningen is broken in testing, and fix is in unstable, but that won't go in because of it's depending on clojure-contrib, which depends on clojure1.2, which is broken on building and won't go in because of clojure1.4 which has the fix on dependencies. Is there help needed for 2.x ?
Bug#699532: Dependency chain
On Mon, Apr 7, 2014 at 9:16 PM, Jaakko Niemi wrote: > Hello, > > Any news on this? We have now nasty situation as leiningen is broken > in testing, and fix is in unstable, but that won't go in because of it's > depending on clojure-contrib, which depends on clojure1.2, which is > broken on building and won't go in because of clojure1.4 which has > the fix on dependencies. > > Is there help needed for 2.x ? > I'll correct myself. leiningen was removed from testing, but somehow I ended up installing it on my testing os. Recent version of leiningen upstream depends on clojure 1.6, which is not packaged yet. There's also major churn going on on dependencies: http://dev.clojure.org/display/community/Where+Did+Clojure.Contrib+Go --j
Bug#694534: sec: bad defaults
On Sun, Dec 9, 2012 at 3:31 PM, Ivo De Decker wrote: > Control: severity -1 important > > Hi, > > On Tue, Nov 27, 2012 at 12:23:31PM +0100, Florian Gleixner wrote: > > Source: sec > > Version: 2.5.3-1+nmu1 > > Severity: critical > > > > Starting sec with /etc/default/sec untouched causes sec to write to > > syslog for example every time a rule creates a context. This may cause > > another context to get created. So sec wrote > 400GB syslog in 24h at my > > system making it unusable. > > I'm downgrading this bug: > > The package doesn't create any rules. It doesn't start by default and it > doesn't create /etc/sec.conf (which is used in /etc/default/sec and needed > for > sec to run). It doesn't even provide an example sec.conf. So if you want to > use is, you have to read the documentation and create the configuration > yourself. If you do that in a way that creates a problem, that might be a > bug, > but not a critical one. > I do admit here that the default configuration does give gun pointed straight to foot. However at the moment there's no clear way with sec to filter or detect loops, which makes robust defaults hard to build. Single shot loop test in startup would be better than anything. I'll have to investigate the options. This is one of the reasons why there's no sec.conf by default. --j
Bug#608078: sec: removing the package does not stop daemon
Hi, That version of sec, does have prerm script in the package: -- #!/bin/sh set -e # Automatically added by dh_installinit if [ -x "/etc/init.d/sec" ]; then if [ -x "`which invoke-rc.d 2>/dev/null`" ]; then invoke-rc.d sec stop || exit $? else /etc/init.d/sec stop || exit $? fi fi # End automatically added section -- Doing installation and removal on clean box, I could not reproduce the issue. Can you see if you can make it happen again, please ? --j On Mon, 27 Dec 2010, Serafeim Zanikolas wrote: > Package: sec > Version: 2.5.3-1+nmu1 > Severity: normal > > Hi, > > Removing sec does not stop its daemon. The prerm script should be calling > sec's init script with a stop argument (this can be easily taken care of with > dh_installinit). > > Cheers, > Serafeim > > ps. I'm setting the severity only to normal since sec doesn't run out of the > box > > -- System Information: > Debian Release: squeeze/sid > APT prefers testing > APT policy: (500, 'testing'), (100, 'unstable'), (1, 'experimental') > Architecture: i386 (i686) > > Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores) > Locale: LANG=en_GB.UTF-8, LC_CTYPE=el_GR.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/bash > > Versions of packages sec depends on: > ii perl 5.10.1-16 Larry Wall's Practical > Extraction > > sec recommends no packages. > > sec suggests no packages. > > > > > ** CRM114 Whitelisted by: ow...@bugs.debian.org ** > > ** ACCEPT: CRM114 Whitelisted by: ow...@bugs.debian.org ** > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#770392: AttributeError: 'module' object has no attribute 'PROTOCOL_SSLv3'
Package: electrum Version: 1.9.8-2 Severity: important Since we don't have SSLv3 anymore, getting this error and electrum cannot connect: Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/electrum/interface.py", line 382, in start_tcp ssl_version=ssl.PROTOCOL_SSLv3, AttributeError: 'module' object has no attribute 'PROTOCOL_SSLv3' Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/electrum/interface.py", line 382, in start_tcp ssl_version=ssl.PROTOCOL_SSLv3, AttributeError: 'module' object has no attribute 'PROTOCOL_SSLv3' Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/electrum/interface.py", line 382, in start_tcp ssl_version=ssl.PROTOCOL_SSLv3, AttributeError: 'module' object has no attribute 'PROTOCOL_SSLv3' Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/electrum/interface.py", line 382, in start_tcp ssl_version=ssl.PROTOCOL_SSLv3, AttributeError: 'module' object has no attribute 'PROTOCOL_SSLv3' -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.18.0-rc4+ (SMP w/8 CPU cores) Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages electrum depends on: ii python 2.7.8-2 ii python-electrum 1.9.8-2 electrum recommends no packages. electrum suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#781456: udisks2: udisksd eats 100% cpu while looping through all devices on md0
Package: udisks2
Version: 2.1.5-1
Severity: important
ps shows udisksd eating 100% cpu:
15849 root 20 0 378856 9084 6752 R 99,3 0,1 134:13.88 udisksd
strace shows that it's just looping throug all devices that are part of md0
array:
readlink("/sys/devices/virtual/block/md0/md/dev-sdd1/block",
"../../../../../pci:00/:0"..., 4095) = 84
lstat("/sys", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
lstat("/sys/devices", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
lstat("/sys/devices/virtual", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
lstat("/sys/devices/virtual/block", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
lstat("/sys/devices/virtual/block/md0", {st_mode=S_IFDIR|0755, st_size=0, ...})
= 0
lstat("/sys/devices/virtual/block/md0/md", {st_mode=S_IFDIR|0755, st_size=0,
...}) = 0
lstat("/sys/devices/virtual/block/md0/md/dev-sdd1", {st_mode=S_IFDIR|0755,
st_size=0, ...}) = 0
lstat("/sys/devices/pci:00", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
lstat("/sys/devices/pci:00/:00:1f.2", {st_mode=S_IFDIR|0755, st_size=0,
...}) = 0
lstat("/sys/devices/pci:00/:00:1f.2/ata4", {st_mode=S_IFDIR|0755,
st_size=0, ...}) = 0
lstat("/sys/devices/pci:00/:00:1f.2/ata4/host3", {st_mode=S_IFDIR|0755,
st_size=0, ...}) = 0
lstat("/sys/devices/pci:00/:00:1f.2/ata4/host3/target3:0:0",
{st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
lstat("/sys/devices/pci:00/:00:1f.2/ata4/host3/target3:0:0/3:0:0:0",
{st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
lstat("/sys/devices/pci:00/:00:1f.2/ata4/host3/target3:0:0/3:0:0:0/block",
{st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
lstat("/sys/devices/pci:00/:00:1f.2/ata4/host3/target3:0:0/3:0:0:0/block/sdd",
{st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
lstat("/sys/devices/pci:00/:00:1f.2/ata4/host3/target3:0:0/3:0:0:0/block/sdd/sdd1",
{st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
open("/sys/devices/virtual/block/md0/md/dev-sdd1/state", O_RDONLY) = 16
fstat(16, {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
read(16, "in_sync\n", 4096) = 8
read(16, "", 4088) = 0
close(16) = 0
open("/sys/devices/virtual/block/md0/md/dev-sdd1/slot", O_RDONLY) = 16
fstat(16, {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
read(16, "0\n", 4096) = 2
read(16, "", 4094) = 0
close(16) = 0
open("/sys/devices/virtual/block/md0/md/dev-sdd1/errors", O_RDONLY) = 16
fstat(16, {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
read(16, "0\n", 4096) = 2
read(16, "", 4094) = 0
close(16) = 0
readlink("/sys/devices/virtual/block/md0/md/dev-sde1/block",
"../../../../../pci:00/:0"..., 4095) = 84
lstat("/sys", {st_mode=S_IFDIR|0555, st_size=0, ...}) = 0
lstat("/sys/devices", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
lstat("/sys/devices/virtual", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
lstat("/sys/devices/virtual/block", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
lstat("/sys/devices/virtual/block/md0", {st_mode=S_IFDIR|0755, st_size=0, ...})
= 0
lstat("/sys/devices/virtual/block/md0/md", {st_mode=S_IFDIR|0755, st_size=0,
...}) = 0
lstat("/sys/devices/virtual/block/md0/md/dev-sde1", {st_mode=S_IFDIR|0755,
st_size=0, ...}) = 0
lstat("/sys/devices/pci:00", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
lstat("/sys/devices/pci:00/:00:1f.2", {st_mode=S_IFDIR|0755, st_size=0,
...}) = 0
lstat("/sys/devices/pci:00/:00:1f.2/ata5", {st_mode=S_IFDIR|0755,
st_size=0, ...}) = 0
lstat("/sys/devices/pci:00/:00:1f.2/ata5/host4", {st_mode=S_IFDIR|0755,
st_size=0, ...}) = 0
lstat("/sys/devices/pci:00/:00:1f.2/ata5/host4/target4:0:0",
{st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
lstat("/sys/devices/pci:00/:00:1f.2/ata5/host4/target4:0:0/4:0:0:0",
{st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
lstat("/sys/devices/pci:00/:00:1f.2/ata5/host4/target4:0:0/4:0:0:0/block",
{st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
lstat("/sys/devices/pci:00/:00:1f.2/ata5/host4/target4:0:0/4:0:0:0/block/sde",
{st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
lstat("/sys/devices/pci:00/:00:1f.2/ata5/host4/target4:0:0/4:0:0:0/block/sde/sde1",
{st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
open("/sys/devices/virtual/block/md0/md/dev-sde1/state", O_RDONLY) = 16
fstat(16, {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
read(16, "in_sync\n", 4096) = 8
read(16, "", 4088) = 0
close(16) = 0
open("/sys/devices/virtual/block/md0/md/dev-sde1/slot", O_RDONLY) = 16
fstat(16, {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
read(16, "2\n", 4096) = 2
read(16, "", 4094) = 0
close(16) = 0
open("/sys/devices/virtual/block/md0/md/dev-sde1/errors", O_RDONLY) = 16
fstat(16, {st_mode=S_IFREG|0644, st_size=4096, ...})
Bug#789809: sec: etc/default/sec not respected
Thanks for the report. I'm just travelling, and will look through this and will fix it next week.
Bug#757381: cgminer: autobotched manpage
Package: cgminer Version: 4.4.2-1 Severity: normal Contents of manpage here: - .\" DO NOT MODIFY THIS FILE! It was generated by help2man 1.46.1. .TH LIBUSB_INIT() "1" "July 2014" "libusb_init() failed err -99 [2014-07-31 04:21:07] libusb_init() failed" "User Commands" .SH NAME libusb_init() \- multi-threaded multi-pool GPU, FPGA and CPU bitcoin miner. .SH DESCRIPTION libusb_init() failed err \fB\-99\fR [2014\-07\-31 04:21:07] libusb_init() failed - Looks like help2man needs some verification features.. --j -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-rc6-amd64 (SMP w/8 CPU cores) Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages cgminer depends on: ii libc62.19-7 ii libcurl3-gnutls 7.37.1-1 ii libjansson4 2.6-1 ii libncurses5 5.9+20140712-2 ii libtinfo55.9+20140712-2 ii libusb-1.0-0 2:1.0.19-1 cgminer recommends no packages. cgminer suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#708132: Jessie Freeze
Hello, I don't see the package in unstable yet, and Jessie release freeze is coming soon. Is there something needed? --j
Bug#765591: libclang1-3.5:i386 overwriting /usr/lib/llvm-3.5/lib/libclang-3.5.so.1
Package: libclang1-3.5 Version: 1:3.5-6 Severity: important libclang1-3.5:i386 is uninstallable: Preparing to unpack .../libclang1-3.5_1%3a3.5-6_i386.deb ... Unpacking libclang1-3.5:i386 (1:3.5-6) ... dpkg: error processing archive /var/cache/apt/archives/libclang1-3.5_1%3a3.5-6_i386.deb (--unpack): trying to overwrite shared '/usr/lib/llvm-3.5/lib/libclang-3.5.so.1', which is different from other instances of package libclang1-3.5:i386 Errors were encountered while processing: /var/cache/apt/archives/libclang1-3.5_1%3a3.5-6_i386.deb $ dpkg -S /usr/lib/llvm-3.5/lib/libclang-3.5.so.1 libclang1-3.5:amd64: /usr/lib/llvm-3.5/lib/libclang-3.5.so.1 --j -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.17.0-rc5+ (SMP w/8 CPU cores) Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libclang1-3.5 depends on: ii libc6 2.19-11 ii libedit2 3.1-20140620-2 ii libffi63.1-2 iu libgcc-4.9-dev 4.9.1-17 ii libgcc11:4.9.1-17 iu libllvm3.5 1:3.5-6 iu libobjc-4.9-dev4.9.1-17 iu libstdc++-4.9-dev 4.9.1-17 ii libstdc++6 4.9.1-17 ii libtinfo5 5.9+20140913-1 ii multiarch-support 2.19-11 ii zlib1g 1:1.2.8.dfsg-2 libclang1-3.5 recommends no packages. libclang1-3.5 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#832622: clang-3.9: Uninstallable in unstable
Package: clang-3.9 Version: 3.9-svn274438-1 Severity: serious Justification: Policy 7.6.1 (Reading database ... 179237 files and directories currently installed.) Preparing to unpack .../clang-3.9_1%3a3.9~svn274438-1_amd64.deb ... Unpacking clang-3.9 (1:3.9~svn274438-1) ... dpkg: error processing archive /var/cache/apt/archives/clang-3.9_1%3a3.9~svn274438-1_amd64.deb (--unpack): trying to overwrite '/usr/share/llvm-3.9/cmake', which is also in package llvm-3.9-dev 1:3.9~svn274438-1 Errors were encountered while processing: /var/cache/apt/archives/clang-3.9_1%3a3.9~svn274438-1_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) llvm-3.9-dev is: Version: 1:3.9~svn274438-1, not sure if the problem is actually there.. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.7.0-rc5+ (SMP w/8 CPU cores) Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#456846: sfs: FTBFS: configure: error: Could not find NFS mount argument structure!
On Tue, 18 Dec 2007, Lucas Nussbaum wrote: > Package: sfs > version: 1:0.8-0+pre20060720.1-1.1 > Severity: serious > User: [EMAIL PROTECTED] > Usertags: qa-ftbfs-20071217 qa-ftbfs > Justification: FTBFS on i386 > > Hi, > > During a rebuild of all packages in sid, your package failed to build on i386. > > Relevant part: > > > checking for libutil.h... no > > checking pty.h usability... yes > > checking pty.h presence... yes > > checking for pty.h... yes > > checking for BSD-style utmp slots... yes > > checking for pseudo ttys... bsd-style ptys > > checking for st_atimespec in stat structure... no > > checking for st_mtimespec in stat structure... no > > checking for st_mtim in stat structure... yes > > checking for memory.h... (cached) yes > > checking for a declaration of xdr_callmsg... yes > > checking what second xdr_getlong arg points to... long > > checking for wide select... [small fd limit anyway] no > > checking if putenv() copies its argument... no > > checking for vfsmount... no > > checking for unmount... no > > checking for nfs/nfsproto.h... no > > checking for nfs_args mount structure... no > > configure: error: Could not find NFS mount argument structure! http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=425319 Urgh. Where did the struct go this time? --j -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#365864: sfs-client: atkbd.c: Unknown key released (translated set 2, code 0x9e on isa0060/serio0).
On Wed, 03 May 2006, Jari Aalto wrote: > Package: sfs-client > Version: 1:0.8-0+pre20050819.1-2.1 > Severity: normal > > [ See following transscript ] > > # sfskey register > > sfskey needs secret bits with which to seed the random number generator. > Please type some random or unguessable text until you hear a beep: > > > > 16 atkbd.c: Unknown key released (translated set 2, code 0x9e on > isa0060/serio0). > atkbd.c: Use 'setkeycodes e01e ' to make it known. > DONE > sfskey: fatal: No changes made That error message comes from kernel, and sfskey aborts. I don't see anything in the code on sfs part (crypt/getkbdnoise.C) that could make kernel do that. I've seen that same error message from kernel few times with new keyboards that have extra keys. Map them into something sensible or just don't touch them. --j -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#365864: sfs-client: atkbd.c: Unknown key released (translated set 2, code 0x9e on isa0060/serio0).
On Wed, 03 May 2006, Jari Aalto wrote: > Hm. This is from year 1990 or so PII standard Compaq Armada > M700 Laptop with finninsh keyboard. Old laptops are another group with weird keyboards :) > The error message > > sfskey: fatal: No changes made > > is quite vague. PLease improve it ti announce what is wrong and > what should be done to fix the situation. Sure, that can be improved. I'll forward this upstream. Not sure if I have time to look deeper anytime soon, so patches welcome, as always. --j -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#356564: more
On Wed, 17 May 2006, Martin Michlmayr wrote: > found 356564 1:0.8-0+pre20060514.1-1 > thanks > > Either the new upstream release introduced more of these or I missed > them before. Given that that last changes to adb/ were about half a decade ago, I suspect the latter :) I'll forward this upstream and will put it in next upload which I'm hoping to do next weekend. > (Sangria) Kolme Leijonaa (blended scotch) --j -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#425319: sfs: FTBFS: configure: error: Could not find NFS mount argument structure!
On Mon, 21 May 2007, Kurt Roeckx wrote: > On Mon, May 21, 2007 at 08:19:55AM +0300, Jaakko Niemi wrote: > > On Sun, 20 May 2007, Kurt Roeckx wrote: > > > Package: sfs > > > Version: 1:0.8-0+pre20060720.1-1.1 > > > Severity: serious > > > > > > Hi, > > > > > > Your package is failing to build with the following error: > > > checking for vfsmount... no > > > checking for unmount... no > > > checking for nfs/nfsproto.h... no > > > checking for nfs_args mount structure... no > > > configure: error: Could not find NFS mount argument structure! > > > make: *** [/build/buildd/sfs-0.8-0+pre20060720.1/build/config.status] > > > Error 1 > > > > What's the version of libc and on which arch are you building ? > > This happened on a few arches, and I don't really see what they have in > common. See http://buildd.debian.org/sfs I believe that the cause for this was fixed in linux-libc-dev 2.6.21-3, so rebuild on the failed archs is needed. On s390 the failure was caused by nfs-common installation issue. Don't see anything on BTS, so retry attempt would be needed there too. --j -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#425319: sfs: FTBFS: configure: error: Could not find NFS mount argument structure!
On Sun, 20 May 2007, Kurt Roeckx wrote: > Package: sfs > Version: 1:0.8-0+pre20060720.1-1.1 > Severity: serious > > Hi, > > Your package is failing to build with the following error: > checking for vfsmount... no > checking for unmount... no > checking for nfs/nfsproto.h... no > checking for nfs_args mount structure... no > configure: error: Could not find NFS mount argument structure! > make: *** [/build/buildd/sfs-0.8-0+pre20060720.1/build/config.status] Error 1 What's the version of libc and on which arch are you building ? --j -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#455262: tftp-hpa: diff for NMU version 0.48-1.1
On Sun, 09 Mar 2008, Martin Zobel-Helas wrote: > tags 455262 + patch > thanks > > Hi, > > Attached is the diff for my tftp-hpa 0.48-1.1 NMU uploaded to delayed-3. Thanks, I'm going to upload new version with few other fixes tomorrow. Same patch is already included into it. So, if you haven't uploaded yet.. --j -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#453259: sfs-client: hangs with linux >= 2.6.22
On Tue, 27 Nov 2007, Clint Adams wrote: > Package: sfs-client > Version: 1:0.8-0+pre20060720.1-1.1 > Severity: important > > With Linux 2.6.21, everything works as expected. With newer kernel > versions, trying to run 'ls' in a directory with 1-23 files works. > With 24 or more files, it hangs for what appears to be forever (or until > I Ctrl-C). > > What can be done to track this down? If there's nothing on logs, strace of sfscd would be the next step. Unfortunately I'm dead busy with work for the next week, and won't have much time to look into this. --j -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#455262: Subject: tftpd-ha: Uses undocumented virtual package 'tftpd'
>Package: tftpd-ha >Version: 0.48-1 >Priority: serious >Justification: Policy violation, section 3.6 >ftpd-ha Provides: the 'tftpd' virtual package, but that package is not >listed >in the canonical virtual packages list at >http://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt Ok, don't remember where that comes from. >This is a Policy violation and, what is worst, induces users to >confusion and this (and aftpd) do not provide the same behaviour. For starters, >tftpd-hpa uses /srv/tftpboot as the standard location for TFTP files whileas >aftpd >use /tftpboot. tftpd-hpa uses /var/lib/tftproot by default. >Please either remove the provides or get together with other maintainers >of tftpd daemons and determine what is the common interface (and location >of files) so that users that install a package Providing: tftpd can make >reasonable assumptions as to its behaviou and *then* ask debian-policy >to add 'tftpd' as a virtual package. I think we really do need common tftpd configuration line. There's for example no way we can can currently provice common working ground with read-only and readwrite root filesystems. >I would really encourage you to follow the second road, even if more >complex, as it would be better overall for all our users. The only bigger question that I see, is how we handle /tftproot in root filesystem. This is legacy thing, and only way to deal with it, that I can see with my limited senses, is to make it a symlink, if it's not there already. Symlink to somewhere more manageable than root filesystem. Now, I tried to bring this up among tftp package maintainers while ago, but failed. --j -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#347663: sfs-common: failure to remove, trying to deregister inexistent document
On Wed, 08 Mar 2006, Lars Wirzenius wrote: > In other words, the error message is different, and the removal doesn't crash > on it. > I don't know what causes this. > > Still, the attached patch should fix it. I'm hesitant to actually do an NMU > before I can > reproduce. Jaakko, do you have a comment? I'm planning upload next weekend. If that does not happen, I'll ask for NMU then.. --j -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#350155: xterm: crash with non-ascii characters
Package: xterm Version: 208-3.1 Severity: important Hello, With up-to-date sid systems xterm has recently started crashing with error: xterm: warning, error event received: X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 77 (X_ImageText16) Value in failed request: 0x0 Serial number of failed request: 293923 Current serial number in output stream: 293923 Major opcode is always the same. I first noticed this when opening a message on debian-devel with mutt: http://lists.debian.org/debian-devel/2006/01/msg01482.html The problem goes away if I set LC_ALL to "C". -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15 Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Versions of packages xterm depends on: ii libc6 2.3.5-12 GNU C Library: Shared libraries an ii libfontconfig12.3.2-1.1 generic font configuration library ii libfreetype6 2.1.10-1 FreeType 2 font engine, shared lib ii libice6 6.9.0.dfsg.1-4 Inter-Client Exchange library ii libncurses5 5.5-1 Shared libraries for terminal hand ii libsm66.9.0.dfsg.1-4 X Window System Session Management ii libx11-6 6.9.0.dfsg.1-4 X Window System protocol client li ii libxaw8 6.9.0.dfsg.1-4 X Athena widget set library ii libxext6 6.9.0.dfsg.1-4 X Window System miscellaneous exte ii libxft2 2.1.7-1FreeType-based font drawing librar ii libxmu6 6.9.0.dfsg.1-4 X Window System miscellaneous util ii libxrender1 1:0.9.0.2-1X Rendering Extension client libra ii libxt66.9.0.dfsg.1-4 X Toolkit Intrinsics ii xlibs-data6.9.0.dfsg.1-4 X Window System client data ii zlib1g1:1.2.3-9 compression library - runtime Versions of packages xterm recommends: ii xutils6.9.0.dfsg.1-4 X Window System utility programs -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#601508: Comments from Upstream on 601508
Hi, Upstream promised to look at implementing iNotify support in future, if it can be done without compatibility issues to other platforms. Here are Risto's comments on the issue overall: " SEC is not only about tracking new lines that are appended to the log files, but it also does a lot of things based on the readings of the system clock. In fact, in order to keep event correlation data structures in a more or less consistent and reasonable state, SEC actually *needs* to process some data structures at least once in a couple of seconds. This work needs to be consistently done even if no data appears in input files for hours or days. In other words, SEC needs to wake up after each few seconds anyway, in order to check its internal state and accomplish various housekeeping tasks. Therefore the inotify functionality is likely to provide no considerable savings in terms of energy and CPU time. However, if the author of the question is running SEC on a system where it is specifically desired to avoid polling input sources for longer amounts of time, I recommend to use larger timeout values for --poll_timeout and --check_timeout options. If there are many files to monitor and most of them change only infrequently, I would especially recommend using a large value for --check_timeout option -- it is known to reduce the system load dramatically if most input sources rarely change. " --j -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630592: fglrx-glx: recent multiarch changes break fglrx
Package: fglrx-glx Version: 1:11-4-2 Severity: important Tags: wheezy Hello, The recent multiarch changes with Mesa (http://blog.mraw.org/2011/06/14/mesa_a_disturbance_in_the_Force/) broke also fglrx. On my system, libGL.so moved to /usr/lib/i386-linux-gnu, so the libGL supplied by fglrx did not get used anymore, so glxinfo gave this error: Error: couldn't find RGB GLX visual or fbconfig I did confirm this issue and worked around it by making couple symlinks back to /usr/lib. -- Package-specific info: VGA-compatible devices on PCI bus: 01:00.0 VGA compatible controller: ATI Technologies Inc Barts XT [ATI Radeon HD 6800 Series] DRM and fglrx Informations from dmesg: [1.236856] Linux agpgart interface v0.103 [ 17.000637] fglrx: module license 'Proprietary. (C) 2002 - ATI Technologies, Starnberg, GERMANY' taints kernel. [ 17.078322] [fglrx] Maximum main memory to use for locked dma buffers: 3856 MBytes. [ 17.078420] [fglrx] vendor: 1002 device: 6738 count: 1 [ 17.078809] [fglrx] ioport: bar 4, base 0xb000, size: 0x100 [ 17.079155] [fglrx] Kernel PAT support is enabled [ 17.079173] [fglrx] module loaded - fglrx 8.84.5 [Apr 5 2011] with 1 minors [ 27.871351] Modules linked in: powernow_k8 mperf cpufreq_stats cpufreq_powersave cpufreq_conservative cpufreq_userspace joydev fglrx(P) snd_emu10k1_synth snd_emux_synth snd_ice1724 snd_seq_virmidi snd_ice17xx_ak4xxx snd_ak4xxx_adda snd_seq_midi_emul snd_ak4114 snd_pt2258 snd_emu10k1 snd_i2c snd_ak4113 snd_ac97_codec ac97_bus snd_util_mem snd_hwdep psmouse snd_seq_midi processor snd_rawmidi i2c_piix4 snd_seq_midi_event snd_pcm_oss snd_seq snd_mixer_oss snd_pcm i2c_core snd_seq_device asus_atk0110 k10temp parport_pc parport snd_timer emu10k1_gp serio_raw pcspkr gameport evdev snd snd_page_alloc thermal_sys soundcore button ext3 jbd mbcache dm_mod raid456 md_mod async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx usbhid hid sg sr_mod sd_mod cdrom crc_t10dif ata_generic ohci_hcd ahci libahci pata_pdc2027x pata_atiixp libata floppy firewire_ohci ehci_hcd usbcore scsi_mod r8169 firewire_core crc_itu_t mii nls_base [last unloaded: scsi_wait_scan] [ 64.519770] fglrx_pci :01:00.0: irq 43 for MSI/MSI-X [ 64.520395] [fglrx] Firegl kernel thread PID: 2442 [ 64.520482] [fglrx] Firegl kernel thread PID: 2443 [ 64.520537] [fglrx] Firegl kernel thread PID: 2444 [ 64.521003] [fglrx] IRQ 43 Enabled [ 65.618316] [fglrx:drm_parse_option] *ERROR* "locked-userpages" is not a valid option [ 65.618321] [fglrx] Maximum main memory to use for locked dma buffers: 3856 MBytes. [ 65.618414] [fglrx] Gart USWC size:1280 M. [ 65.618416] [fglrx] Gart cacheable size:508 M. [ 65.618421] [fglrx] Reserved FB block: Shared offset:0, size:100 [ 65.618423] [fglrx] Reserved FB block: Unshared offset:fbfd000, size:403000 [ 65.618426] [fglrx] Reserved FB block: Unshared offset:3fff4000, size:c000 [ 1163.564740] [fglrx] IRQ 43 Disabled [ 1165.767883] fglrx_pci :01:00.0: irq 43 for MSI/MSI-X [ 1165.768535] [fglrx] Firegl kernel thread PID: 6029 [ 1165.768585] [fglrx] Firegl kernel thread PID: 6030 [ 1165.768637] [fglrx] Firegl kernel thread PID: 6031 [ 1165.769064] [fglrx] IRQ 43 Enabled [ 1166.042978] [fglrx:drm_parse_option] *ERROR* "locked-userpages" is not a valid option [ 1166.042984] [fglrx] Maximum main memory to use for locked dma buffers: 3856 MBytes. [ 1166.043067] [fglrx] Gart USWC size:1280 M. [ 1166.043070] [fglrx] Gart cacheable size:508 M. [ 1166.043075] [fglrx] Reserved FB block: Shared offset:0, size:100 [ 1166.043077] [fglrx] Reserved FB block: Unshared offset:fbfd000, size:403000 [ 1166.043080] [fglrx] Reserved FB block: Unshared offset:3fff4000, size:c000 Xorg X server configuration file status: -rw-r--r-- 1 root root 2970 Nov 29 2010 /etc/X11/xorg.conf Contents of /etc/X11/xorg.conf: # /etc/X11/xorg.conf (xorg X Window System server configuration file) # # This file was generated by dexconf, the Debian X Configuration tool, using # values from the debconf database. # # Edit this file with caution, and see the /etc/X11/xorg.conf manual page. # (Type "man /etc/X11/xorg.conf" at the shell prompt.) # # This file is automatically updated on xserver-xorg package upgrades *only* # if it has not been modified since the last upgrade of the xserver-xorg # package. # # If you have edited this file but would like it to be automatically updated # again, run the following command: # sudo dpkg-reconfigure -phigh xserver-xorg #Section "InputDevice" # Identifier "Generic Keyboard" # Driver "kbd" # Option "CoreKeyboard" # Option "XkbRules" "xorg" # Option "XkbModel" "pc105" # Option "XkbLayout" "fi" #EndSection #Section "InputDevice" # Identifier "Configured Mouse" # Driver "mouse" # Option "CorePointer" # Option "Device"
Bug#1109820: ITP: oxicloud -- Oxicloud is lightweight, Rust - powered alternative to NextCloud
Package: wnpp Severity: wishlist * Package name: oxicloud Version : 0.1.0-rc+git Upstream Contact: OxiCloud Contributors https://github.com/DioCrafts/OxiCloud/issues * URL : https://github.com/DioCrafts/OxiCloud * License : MIT Programming Lang: 76.2% Rust, 18.6% JavaScript Description : Oxicloud is lightweight, Rust - powered alternative to NextCloud "I built OxiCloud because I wanted a simpler, faster file storage solution than existing options. After struggling with NextCloud's performance on my home server, I decided to create something that prioritizes speed and simplicity while still being robust enough for daily use. What makes OxiCloud different? Lightweight: Minimal resource requirements compared to PHP-based alternatives Responsive UI: Clean, fast interface that works well on both desktop and mobile Rust Performance: Built with Rust for memory safety and speed Optimized Binary: Uses Link Time Optimization (LTO) for maximum performance Simple Setup: Get running with minimal configuration Multilingual: Full support for English and Spanish interface Prerequisites Rust 1.70+ and Cargo PostgreSQL 13+ database 512MB RAM minimum (1GB+ recommended)" - It would be preferred to have this group maintained, please contact me if you are interested. -Jaakko
