Bug#754401: gource starts on the wrong X11 screen
FYI, A fix for the basic case of this bug has been pushed upstream: https://hg.libsdl.org/SDL/rev/3d2c0f659ad3 Details here: https://bugzilla.libsdl.org/show_bug.cgi?id=2192 I'd love to see this fix show up in the Debian package. :)
Bug#715464: This is still not fixed
Note, despite the above stated belief, this is still *not* fixed as of current wheezy+updates. The above-mentioned patch is still required to make icedove usable in sawfish on large displays. I just confirmed this patch still applied cleanly, and allowed me to build a working icedove_17.0.10-1~deb7u1 package.
Bug#715464: This is still not fixed
Oh, ok. Makes sense. Thanks for the clarification. On Tue, Feb 18, 2014 at 2:25 PM, Carsten Schönert c.schoen...@t-online.dewrote: Hello Steaphan, Am 18.02.2014 23:10, schrieb Steaphan Greene: Note, despite the above stated belief, this is still *not* fixed as of current wheezy+updates. that is not difficult to make it clear, obviously. The release team only allows security related fixes for the current version 17.0.10 in stable-security. By this the patch is only applied to the versions in testing and not stable-security. But we work hardly on the current 24.3.0 version to get it into testing and finally to stable-security. But this will need some more time. The above-mentioned patch is still required to make icedove usable in sawfish on large displays. I just confirmed this patch still applied cleanly, and allowed me to build a working icedove_17.0.10-1~deb7u1 package. Fine! Otherwise this would require a backport release. But with a version 24.3.0 in starting we don't want to make such a backport for this short time. We fighted the last time a not so simple issue with needed libraries and symbols for other packages that depended on Icedove. -- Regards Carsten
Bug#715464: Sorry, No Time
Sorry, but I'm afraid I've put in all the time I have to spend on this already. :/ -- Steaphan [STEF-in] Greene Software Engineer: DB-Eng/MySQL -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#715464: Fix for bug #715464
This patch fixes this bug: https://bugzilla.mozilla.org/attachment.cgi?id=685492action=diff I confirmed this by patching (patch applies cleanly to the mozilla subdir) and rebuilding icedove_17.0.7-1~deb7u1_amd64. Works fine now in sawfish. -- Steaphan [STEF-in] Greene Software Engineer: DB-Eng/MySQL -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#596468: linux-image-2.6.32-5-openvz-amd64: Keyspan USA-49WG USB-Serial 4th Port Doesn't Work
On 04/30/2011 09:49 PM, Steaphan Greene wrote: On 04/23/2011 03:41 PM, Moritz Mühlenhoff wrote: it seems you didn't followup in the kernel.org bugzilla. Is this fixed in current kernels from sid or testing? Testing on a different computer, just plugging it in with a clean boot on the same kernel version as before (that this bug was filed against) immediately crashed the kernel (OOPS, followed shortly by a constant terminal bell and no response to any input, not even numlock or SysRq). Testing this device using linux-image2.6.38-2-amd64 from current sid (v2.6.38-4) resulted in all 4 ports working perfectly. However, I only could test them individually on that machine, so I can not confirm they will work simultaneously as they are used on the real system. But, it certainly seems better to me. I will follow up once I get a chance to test this on the live system with this new kernel version, but that may be a while. I suspect this bug is now resolved, but I can't confirm this until then. I found a window to reboot the main system using this hardware to test this newer kernel, and it just went through a cycle using all 4 serial ports on this device simultaneously, and worked perfectly. So, I can confirm this bug has definitely been fixed as of the above kernel package version (linux-image2.6.38-2-amd64 from sid 5 days ago). Thanks! -- Steaphan Greene sgre...@cs.binghamton.edu Lecturer, Computer Science, Binghamton University GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#596468: linux-image-2.6.32-5-openvz-amd64: Keyspan USA-49WG USB-Serial 4th Port Doesn't Work
On 04/23/2011 03:41 PM, Moritz Mühlenhoff wrote: On Wed, Dec 29, 2010 at 09:35:30PM +, Ben Hutchings wrote: On Wed, 2010-12-29 at 14:05 -0500, Steaphan Greene wrote: On 12/29/2010 09:10 AM, Ben Hutchings wrote: On Wed, 2010-12-29 at 03:55 -0500, Steaphan Greene wrote: On 12/26/2010 06:46 AM, Moritz Muehlenhoff wrote: Could you try to reproduce this with a current 2.6.37-rcX kernel from experimental? The kernel is available from packages.debian.org. If the error can still be reproduced, we should report it upstream. Unfortunately, 2.6.37-rc7-amd64 has an even greater problem, which prevents me from testing it. The error I am now encountering seems to be the one discussed here: https://bugzilla.kernel.org/show_bug.cgi?id=23012 [...] That was fixed in 2.6.37-rc5. ...then it has been re-introduced, or a new bug which causes the same behavior for at least my keyspan device has cropped up in -rc7. All access attempts to all of the 4 ports of my device with 2.6.37-rc7 failed with a Resource Temporarily Unavailable error. Please add that information on bugzilla.kernel.org. Steaphan, it seems you didn't followup in the kernel.org bugzilla. Is this fixed in current kernels from sid or testing? Testing on a different computer, just plugging it in with a clean boot on the same kernel version as before (that this bug was filed against) immediately crashed the kernel (OOPS, followed shortly by a constant terminal bell and no response to any input, not even numlock or SysRq). Testing this device using linux-image2.6.38-2-amd64 from current sid (v2.6.38-4) resulted in all 4 ports working perfectly. However, I only could test them individually on that machine, so I can not confirm they will work simultaneously as they are used on the real system. But, it certainly seems better to me. I will follow up once I get a chance to test this on the live system with this new kernel version, but that may be a while. I suspect this bug is now resolved, but I can't confirm this until then. -- Steaphan Greene sgre...@cs.binghamton.edu Lecturer, Computer Science, Binghamton University GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#596468: linux-image-2.6.32-5-openvz-amd64: Keyspan USA-49WG USB-Serial 4th Port Doesn't Work
On 04/23/2011 03:41 PM, Moritz Mühlenhoff wrote: On Wed, Dec 29, 2010 at 09:35:30PM +, Ben Hutchings wrote: On Wed, 2010-12-29 at 14:05 -0500, Steaphan Greene wrote: On 12/29/2010 09:10 AM, Ben Hutchings wrote: On Wed, 2010-12-29 at 03:55 -0500, Steaphan Greene wrote: On 12/26/2010 06:46 AM, Moritz Muehlenhoff wrote: Could you try to reproduce this with a current 2.6.37-rcX kernel from experimental? The kernel is available from packages.debian.org. If the error can still be reproduced, we should report it upstream. Unfortunately, 2.6.37-rc7-amd64 has an even greater problem, which prevents me from testing it. The error I am now encountering seems to be the one discussed here: https://bugzilla.kernel.org/show_bug.cgi?id=23012 [...] That was fixed in 2.6.37-rc5. ...then it has been re-introduced, or a new bug which causes the same behavior for at least my keyspan device has cropped up in -rc7. All access attempts to all of the 4 ports of my device with 2.6.37-rc7 failed with a Resource Temporarily Unavailable error. Please add that information on bugzilla.kernel.org. Steaphan, it seems you didn't followup in the kernel.org bugzilla. Is this fixed in current kernels from sid or testing? No, I did not. By the time I got a chance to follow up on this, new kernel version were available, and I have not had time to test any of them (the machine using this hardware is constantly in use, including the serial device itself). I will see if I can follow up by connecting the device to a more expendable machine at some point when the serial ports won't be needed on my main machine for some time. I will e-mail again when I do finally manage to do that. -- Steaphan Greene sgre...@cs.binghamton.edu Lecturer, Computer Science, Binghamton University GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#596468: linux-image-2.6.32-5-openvz-amd64: Keyspan USA-49WG USB-Serial 4th Port Doesn't Work
On 12/26/2010 06:46 AM, Moritz Muehlenhoff wrote: Could you try to reproduce this with a current 2.6.37-rcX kernel from experimental? The kernel is available from packages.debian.org. If the error can still be reproduced, we should report it upstream. Unfortunately, 2.6.37-rc7-amd64 has an even greater problem, which prevents me from testing it. The error I am now encountering seems to be the one discussed here: https://bugzilla.kernel.org/show_bug.cgi?id=23012 Let me know what you'd like me to do next (though I won't be able to do any more testing until Jan 1 at the earliest, due to holiday plans). Thanks. -- Steaphan Greene sgre...@cs.binghamton.edu Lecturer, Computer Science, Binghamton University GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#596468: linux-image-2.6.32-5-openvz-amd64: Keyspan USA-49WG USB-Serial 4th Port Doesn't Work
On 12/29/2010 09:10 AM, Ben Hutchings wrote: On Wed, 2010-12-29 at 03:55 -0500, Steaphan Greene wrote: On 12/26/2010 06:46 AM, Moritz Muehlenhoff wrote: Could you try to reproduce this with a current 2.6.37-rcX kernel from experimental? The kernel is available from packages.debian.org. If the error can still be reproduced, we should report it upstream. Unfortunately, 2.6.37-rc7-amd64 has an even greater problem, which prevents me from testing it. The error I am now encountering seems to be the one discussed here: https://bugzilla.kernel.org/show_bug.cgi?id=23012 [...] That was fixed in 2.6.37-rc5. ...then it has been re-introduced, or a new bug which causes the same behavior for at least my keyspan device has cropped up in -rc7. All access attempts to all of the 4 ports of my device with 2.6.37-rc7 failed with a Resource Temporarily Unavailable error. Thanks. -- Steaphan Greene sgre...@cs.binghamton.edu Lecturer, Computer Science, Binghamton University GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#596468: linux-image-2.6.32-5-openvz-amd64: Keyspan USA-49WG USB-Serial 4th Port Doesn't Work
On 12/26/2010 06:46 AM, Moritz Muehlenhoff wrote: Could you try to reproduce this with a current 2.6.37-rcX kernel from experimental? The kernel is available from packages.debian.org. If the error can still be reproduced, we should report it upstream. Sure. I won't be able to try this until tomorrow afternoon (GMT-5), however, as the machine using this hardware is my MythTV box and it will be busy (recording continuously) until then. I will let you know the result(s) once I try this. Thanks. -- Steaphan Greene sgre...@cs.binghamton.edu Lecturer, Computer Science, Binghamton University GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#596468: linux-image-2.6.32-5-openvz-amd64: Keyspan USA-49WG USB-Serial 4th Port Doesn't Work
Package: linux-2.6 Version: 2.6.32-21 Severity: important I've confirmed that linux-image-2.6.32-5-amd64 has this same problem. I believe this problem did not exist in 2.6.31 from backports. With the Keyspan USA-49WG (a 4-port USB-to-Serial device), only 3 ports work. Reads/writes from/to the port 4 just hang. I tried swapping the serial cables between ports 3 and 4, and port #3 always worked fine, #4 never worked. Also, sometimes, when I interrupt a port #4 read/write, I get this: Message from sysl...@hostname at Sep 11 13:16:31 ... kernel:[258715.792095] Oops: [#3] SMP Message from sysl...@hostname at Sep 11 13:16:31 ... kernel:[258715.792099] last sysfs file: /sys/module/thermal/initstate Message from sysl...@hostname at Sep 11 13:16:31 ... kernel:[258715.792277] Stack: Message from sysl...@hostname at Sep 11 13:16:31 ... kernel:[258715.792295] Call Trace: Message from sysl...@hostname at Sep 11 13:16:31 ... kernel:[258715.792385] Code: b0 00 00 00 48 89 df e8 be 86 10 e1 44 8b a5 60 01 00 00 48 89 c6 48 89 df eb 28 45 31 e4 80 7b 1f 00 74 24 48 8b 9d 50 01 00 00 48 8b 7b 18 e8 96 86 10 e1 44 8b 63 0c 44 2b 63 10 48 89 c6 48 Message from sysl...@hostname at Sep 11 13:16:31 ... kernel:[258715.792429] CR2: 0018 -- Package-specific info: ** Version: Linux version 2.6.32-5-openvz-amd64 (Debian 2.6.32-21) (b...@decadent.org.uk) (gcc version 4.3.5 (Debian 4.3.5-2) ) #1 SMP Wed Aug 25 14:41:25 UTC 2010 ** Command line: BOOT_IMAGE=/boot/vmlinuz-2.6.32-5-openvz-amd64 root=UUID=c179a7a2-26ed-4268-8cf0-5970bf6ff22c ro ** Tainted: D (128) * Kernel has oopsed before. ** Kernel log: [5.261073] XFS mounting filesystem sda1 [5.412216] Ending clean XFS mount for filesystem: sda1 [5.545270] r8169: eth0: link up [5.546033] r8169: eth0: link up [8.517217] RPC: Registered udp transport module. [8.517933] RPC: Registered tcp transport module. [8.518635] RPC: Registered tcp NFSv4.1 backchannel transport module. [8.528950] Slow work thread pool: Starting up [8.529674] Slow work thread pool: Ready [8.530364] FS-Cache: Loaded [8.546248] FS-Cache: Netfs 'nfs' registered for caching [8.556684] Installing knfsd (copyright (C) 1996 o...@monad.swb.de). [8.632472] fuse init (API version 7.13) [8.837465] svc: failed to register lockdv1 RPC service (errno 97). [8.838733] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory [8.839974] NFSD: starting 90-second grace period [ 10.142323] Bluetooth: Core ver 2.15 [ 10.142353] NET: Registered protocol family 31 [ 10.142354] Bluetooth: HCI device and connection manager initialized [ 10.142357] Bluetooth: HCI socket layer initialized [ 10.243759] Bluetooth: L2CAP ver 2.14 [ 10.243761] Bluetooth: L2CAP socket layer initialized [ 10.247922] Bluetooth: RFCOMM TTY layer initialized [ 10.247926] Bluetooth: RFCOMM socket layer initialized [ 10.247927] Bluetooth: RFCOMM ver 1.11 [ 10.260436] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [ 10.260439] Bluetooth: BNEP filters: protocol multicast [ 10.277098] Bridge firewalling registered [ 10.287246] Bluetooth: SCO (Voice Link) ver 0.6 [ 10.287248] Bluetooth: SCO socket layer initialized [ 10.989236] ip_tables: (C) 2000-2006 Netfilter Core Team [ 15.141536] CPU0 attaching NULL sched-domain. [ 15.141542] CPU1 attaching NULL sched-domain. [ 15.160107] CPU0 attaching sched-domain: [ 15.160111] domain 0: span 0-1 level MC [ 15.160114] groups: 0 1 [ 15.160120] CPU1 attaching sched-domain: [ 15.160123] domain 0: span 0-1 level MC [ 15.160126] groups: 1 0 [ 15.736517] eth0: no IPv6 routers present [ 16.860007] eth1: no IPv6 routers present [ 18.188203] BUG: unable to handle kernel NULL pointer dereference at 0018 [ 18.188210] IP: [a0320488] usb_serial_generic_chars_in_buffer+0x76/0xc3 [usbserial] [ 18.188220] PGD 221078067 PUD 23ce6c067 PMD 0 [ 18.188225] Oops: [#1] SMP [ 18.188228] last sysfs file: /sys/devices/pci:00/:00:1d.7/usb2/2-1/2-1:1.0/uevent [ 18.188233] CPU 1 [ 18.188235] Modules linked in: vzethdev vznetdev simfs vzrst vzcpt vzdquota vzmon vzdev xt_tcpudp xt_length xt_hl xt_tcpmss xt_TCPMSS iptable_mangle iptable_filter xt_multiport xt_limit xt_dscp ipt_REJECT ip_tables x_tables acpi_cpufreq sco cpufreq_powersave bridge cpufreq_stats stp cpufreq_userspace bnep cpufreq_conservative rfcomm l2cap crc16 bluetooth rfkill fuse nfsd nfs lockd fscache nfs_acl auth_rpcgss sunrpc xfs exportfs i2c_dev firewire_sbp2 loop keyspan lgdt330x cx88_dvb cx88_vp3054_i2c snd_hda_codec_intelhdmi snd_hda_codec_realtek videobuf_dvb dvb_core tuner_simple tuner_types lirc_streamzap lirc_dev snd_hda_intel tda9887 snd_hda_codec tda8290 snd_hwdep snd_seq_dummy snd_seq_oss usbserial tuner snd_seq_midi snd_rawmidi snd_seq_midi_event
Bug#407652: Do you still intend to adopt html2ps?
Niels Thykier wrote: I checked this bug report recently and noticed that you expressed interest in adopting html2ps - though it is now about 6 months ago. If you still want to adopt the package, please assume ownership over the bug (and retitle it to ITA). Otherwise, if you have lost interest or the time, - which is quite alright - I can email Steaphan and ask if he is still interested in adopting it. For the record, I am still interested in taking this package over, if no current DD wants to do it. However, I am still NOT a DD, so I would still need a sponsor. -- Steaphan Greene sgre...@cs.binghamton.edu Lecturer, Computer Science, Binghamton University GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#407652: ITA: html2ps -- HTML to PostScript converter
Jeremiah, Since I haven't heard anything from Daniel since I offered to sponsor this, I think it's best you take it over instead. I'll find another needy package (which nobody else wants to deal with) to start on. Jeremiah C. Foster wrote: Hi Steaphan! I wish to, yes, but I am not a DD, so I would need a sponsor. No problem, and of course you do not need to be a DD, but you're right about a sponsor. The good news is that Daniel Bauman, a DD, offered to sponsor this package, he mentioned that when he orphaned the package: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=407652 So if you want to, go ahead and create a package for html2ps, but if you do not want to, let me know and I will package it. If you are a DD, then you would probably be a better choice, since you would also need someone to sponsor your work. Jeremiah C. Foster wrote: Hello Steaphan! Do you still intend to adopt html2ps? If not I am happy to do it. I maintain a number of packages in debian already with the debian-perl team as well as the swedish dictionary package. Warm regards, Jeremiah -- Steaphan Greene [EMAIL PROTECTED] Lecturer, Computer Science, Binghamton University GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407652: ITA: html2ps -- HTML to PostScript converter
I wish to, yes, but I am not a DD, so I would need a sponsor. If you are a DD, then you would probably be a better choice, since you would also need someone to sponsor your work. Jeremiah C. Foster wrote: Hello Steaphan! Do you still intend to adopt html2ps? If not I am happy to do it. I maintain a number of packages in debian already with the debian-perl team as well as the swedish dictionary package. Please reply if you are interested in packaging html2ps. Warm regards, Jeremiah -- Steaphan Greene [EMAIL PROTECTED] Lecturer, Computer Science, Binghamton University GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407652: ITA: html2ps -- HTML to PostScript converter
Daniel/Dave, If I am understanding the bug system right, this package (html2ps) was not actually adopted and is still in need of a maintainer. If that is true, I would like to adopt it. Since I use this script on a weekly basis, and I know both Perl and Postscript, this seems a good fit for me. If nobody else is working on it, I plan to remove the tcl/tk interface (thus removing the xhtml2ps binary package from Debian) and focus on fixing whatever bugs I can with the html2ps script itself. I am not (yet) a DD, or DM (though my key is signed by several in the Debian keyring) so I will apparently need a sponsor to pull this off. I may also need help working with the bug system, as I have limited experience with it, and adopting a package will be a first for me. Note that I have worked with the Debian packaging system several times before, just not the bug tracker. It's something I wanted to learn anyway, and am looking forward to it. Dave, if you are still working toward this, then I apologize for misunderstanding the situation, and never mind this message. I will find another package that I can help out with instead. Just let me know. Thanks! -- Steaphan Greene [EMAIL PROTECTED] Lecturer, Computer Science, Binghamton University GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#488031: mirror submission for debian.cs.binghamton.edu
Package: mirrors Severity: wishlist Submission-Type: new Site: debian.cs.binghamton.edu Type: leaf Archive-architecture: ALL alpha amd64 arm hppa hurd-i386 i386 ia64 m68k mips mipsel powerpc s390 sparc Archive-ftp: /debian/ Archive-http: /debian/ Archive-rsync: debian/ IPv6: no Archive-upstream: ftp.us.debian.org Updates: twice Maintainer: Steaphan Greene [EMAIL PROTECTED] Country: US United States Location: Binghamton, New York, USA Sponsor: Binghamton University Computer Science Department http://www.cs.binghamton.edu/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#488031: mirror submission for debian.cs.binghamton.edu
Simon Paillard wrote: Your local trace file is currently named commander.cs.binghamton.edu (in debian/project/trace). Could you please force the HOSTNAME variable in anonftpsync to debian.cs.binghamton.edu so that it matchs the submitted site name ? Done. Next sync (underway now) should show that. Type: leaf Archive-architecture: ALL alpha amd64 arm hppa hurd-i386 i386 ia64 m68k mips mipsel powerpc s390 sparc Just a reminder, the submission form is missing armel which is in the archive and provided by your mirror. Yes. Is there anything I need to do for this? I have been mirroring everything for the last 5+ years, and have no intent of removing any arch or source in the future either. Archive-ftp: /debian/ Archive-http: /debian/ Archive-rsync: debian/ IPv6: no Archive-upstream: ftp.us.debian.org ftp.us.debian.org is a DNS round-robin, so you must select explicitely one mirror out of the several composiing ftp.us.d.o, then configure it in anonftpsync and tell us. Right, I did that because my previous selections kept becoming out of date, while this round-robin is alway up-to-date. I've set it to the fastest of these for us at the moment, which seems to be: debian.lcs.mit.edu We like to know and to tell our users how much bandwidth is available (and possible presence on specific networks such as Internet2, etc.), could you provide us this info ? It's hard to say. This is a cluster of two machines (with two more in reserve) each on 1GB ethernet, interlinked in a 80GB internal network, uplinked to the 'net via a shared 350 Mbit link (last I checked). Does that give you the info you need? Please take care to subscribe to http://lists.debian.org/debian-mirrors-announce Already done. Thanks for mirroring Debian and best regards, Thanks for the quick response. Anything else you need? -- Steaphan Greene [EMAIL PROTECTED] Lecturer, Computer Science, Binghamton University GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#410010: linux-image-2.6.18-3-amd64: Panic When BNX2 Ring Buffer Fills
On Wed, Feb 07, 2007 at 03:09:18PM +0100, Frederik Schueler wrote: On Tue, Feb 06, 2007 at 08:51:58PM -0500, Steaphan Greene wrote: The Linux kernel in Etch does not yet contain the following patch: http://www.mail-archive.com/netdev@vger.kernel.org/msg28143.html I'll have a look at this, thanks. I will ping you in this bug again when we have a snapshot to test. Best regards Frederik Schueler Did I miss a development on this one? I just saw an announcement that the etch kernel had only usability issues left. Has this bug been fixed without me seeing it in the changelogs, or did this get missed? -- Steaphan Greene [EMAIL PROTECTED] Lecturer, Computer Science, Binghamton University GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt signature.asc Description: Digital signature
Bug#410010: linux-image-2.6.18-3-amd64: Panic When BNX2 Ring Buffer Fills
Package: linux-image-2.6.18-3-amd64 Version: 2.6.18-7 Severity: critical Tags: patch Justification: breaks the whole system The Linux kernel in Etch does not yet contain the following patch: http://www.mail-archive.com/netdev@vger.kernel.org/msg28143.html While running our NFS server in Etch, it began panicing in the BNX2 driver sometimes as often as once every 15 minutes, leading to loss of sync with the clients and even loss of some data. This bug seems to affect all systems using the BNX2 networking driver. I created a new kernel package from the Etch linux-source-2.6.18 (2.6.18-7 Debian:testing) with just the above patch applied, and have been running that, and it seems that has solved the problem. I believe this simple patch must be backported into the etch kernel right away - certainly before Etch's release. Otherwise, this hard-to-track bug will cause the highest-usage affected machines to crash without warning, especially at times of highest load. This network driver seems to be the one which will be used for all the Dell PowerEdge 1950/2950 servers, so the impact will probably rather widespread. Let me know if I can provide any further information. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.18-3-amd64 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages linux-image-2.6.18-3-amd64 depends on: ii coreutils 5.2.1-2 The GNU core utilities ii debconf [debconf-2.0] 1.4.30.13 Debian configuration management sy ii e2fsprogs 1.37-2sarge1 ext2 file system utilities and lib ii initramfs-tools [linux-ini 0.85b~bpo.1 tools for generating an initramfs ii module-init-tools 3.2.2-3~bpo.1 tools for managing Linux kernel mo -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#406686: exim4: Client Auth Can't Handle Special Characters in Passwords
On Sun, Jan 14, 2007 at 02:02:01PM +0100, Marc Haber wrote: Can you please try this new, simplified authenticator? Sorry I didn't reply sooner - I have been down sick. Yes, the changes which have propogated through etch have resolved the problems with all the symbols I was testing. Thank you for you help. -- Steaphan Greene [EMAIL PROTECTED] Lecturer, Computer Science, Binghamton University GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#406686: closed by Andreas Metzler [EMAIL PROTECTED] (Re: Bug#406686: exim4: Client Auth Can't Handle Special Characters in Passwords)
On Sat, Jan 13, 2007 at 03:18:22AM -0800, Debian Bug Tracking System wrote: Both ^ and $ work without anyproblems for AUTH CRAM-MD5. $ works fine too with AUTH LOGIN and AUTH PLAIN. AUTH LOGIN and PLAIN will indeed fail with ^ since exim converts it to a binary zero. Doubling the ^ in /etc/exim4/passwd.client will disable this. http://www.exim.org/exim-html-4.66/doc/html/spec_html/ch34.html Confirmed. Thank you. Can this be added to the man page for this config file (exim4_files). I did look around quite a bit for the cause of this problem and was not able to find documentation on it. I'm sure I won't be the only one confused by this. -- Steaphan Greene [EMAIL PROTECTED] Lecturer, Computer Science, Binghamton University GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#406686: exim4: Client Auth Can't Handle Special Characters in Passwords
On Sat, Jan 13, 2007 at 03:05:26PM +0100, Marc Haber wrote: I cannot reproduce this. Please change your password in /etc/exim/passwd.client to something containing $ or ^ (but _not_ being your password) and send me the output of echo bla | exim4 -odq [EMAIL PROTECTED]; exim4 -d-all+lists+expand -M $(exipick -i -bpu) The issue is apparently only with the ^ when using plain or login auth. Replacing it with ^^ did solve the problem. I thought I had found problems without the ^ and using other test symbols, but apparently I had made a mistake. The only problem characters I now find are ^ and, obviously, :. Given this info, do you still want this additional information from me? -- Steaphan Greene [EMAIL PROTECTED] Lecturer, Computer Science, Binghamton University GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#406686: exim4: Client Auth Can't Handle Special Characters in Passwords
On Sat, Jan 13, 2007 at 04:02:37PM +0100, Marc Haber wrote: Can you try the following new plain authenticator? That one seems to work. I believe the same would have to be done for login auth as well, right? -- Steaphan Greene [EMAIL PROTECTED] Lecturer, Computer Science, Binghamton University GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#406686: exim4: Client Auth Can't Handle Special Characters in Passwords
On Sat, Jan 13, 2007 at 05:35:14PM +0100, Marc Haber wrote: Yes, and for the versions allowing unencrypted authentication as well. I just wanted to know if the change works outside my lab. Yep, it seems to, but I only tried my tests with test-passwords with shifted-number-keys (US QWERTY keyboard, so, [EMAIL PROTECTED]*()). I did not test it with any others, such as :. -- Steaphan Greene [EMAIL PROTECTED] Lecturer, Computer Science, Binghamton University GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt signature.asc Description: Digital signature
Bug#406686: exim4: Client Auth Can't Handle Special Characters in Passwords
Package: exim4 Version: 4.63-12 Severity: important There seems to be no way to handle a password with special characters in /etc/exim4/passwd.client. I can find no docs on this but have confirmed that many special characters (including ^ and $) in a password cause exim4 to not authenticate as a client, and they don't seem to be escapable via the normal means. -- Package-specific info: Exim version 4.63 #1 built 20-Dec-2006 17:15:23 Copyright (c) University of Cambridge 2006 Berkeley DB: Sleepycat Software: Berkeley DB 4.3.29: (September 6, 2005) Support for: crypteq iconv() IPv6 GnuTLS move_frozen_messages Lookups: lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmnz dsearch nis nis0 passwd Authenticators: cram_md5 plaintext Routers: accept dnslookup ipliteral manualroute queryprogram redirect Transports: appendfile/maildir/mailstore autoreply lmtp pipe smtp Fixed never_users: 0 Size of off_t: 8 Configuration file is /var/lib/exim4/config.autogenerated # /etc/exim4/update-exim4.conf.conf # # Edit this file and /etc/mailname by hand and execute update-exim4.conf # yourself or use 'dpkg-reconfigure exim4-config' # # Please note that this is _not_ a dpkg-conffile and that automatic changes # to this file might happen. The code handling this will honor your local # changes, so this is usually fine, but will break local schemes that mess # around with multiple versions of the file. # # update-exim4.conf uses this file to determine variable values to replace # the DEBCONFsomethingDEBCONF strings in the configuration template files. # # Most settings found in here do have corresponding questions in the # Debconf configuration, but not all of them. # # This is a Debian specific file dc_eximconfig_configtype='smarthost' dc_other_hostnames='sentry.cs.binghamton.edu' dc_local_interfaces='127.0.0.1' dc_readhost='cs.binghamton.edu' dc_relay_domains='' dc_minimaldns='false' dc_relay_nets='' dc_smarthost='mail.cs.binghamton.edu' CFILEMODE='644' dc_use_split_config='false' dc_hide_mailname='true' dc_mailname_in_oh='true' dc_localdelivery='mail_spool' mailname:sentry.cs.binghamton.edu -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-2-powerpc-smp Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages exim4 depends on: ii debconf [debconf-2.0] 1.5.11 Debian configuration management sy ii exim4-base4.63-12support files for all exim MTA (v4 ii exim4-daemon-light4.63-12lightweight exim MTA (v4) daemon exim4 recommends no packages. -- debconf information: exim4/drec: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#319455: dovecot-common: All messages marked as old but not deleted
Package: dovecot-common Version: 0.99.14-1 Severity: important It seems that Dovecot marks every message served up by its pop and imap servers as Status: O if downloaded with certain clients (like fetchmail), which, according to RFC 2076 means message is old but not deleted - though this is non-standard. This makes mail readers that use this field (like mutt) think all new mail is just old unread mail. There also seems to be no way to disable this in the current version's configuration, making these clients unable to function correctly when used with dovecot. This also seems to have an affect on kmail's ability to automatically read new messages from the dovecot imap server as well, but I have not confirmed this is certainly due to the same problem. This seems to have been discussed upstream, but with no resolution I can find: http://dovecot.org/pipermail/dovecot/2004-March/003088.html -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-2-k7-smp Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages dovecot-common depends on: ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii libldap2 2.1.30-8 OpenLDAP libraries ii libmysqlclient12 4.0.24-10 mysql database client library ii libpam-runtime 0.76-22 Runtime support for the PAM librar pi libpam0g 0.76-22 Pluggable Authentication Modules l ii libpq3 7.4.7-6sarge1 PostgreSQL C client library ii libsasl2 2.1.19-1.5Authentication abstraction library pi libssl0.9.70.9.7e-3 SSL shared libraries pi openssl0.9.7e-3 Secure Socket Layer (SSL) binary a ii zlib1g 1:1.2.2-4.sarge.1 compression library - runtime -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#319455: dovecot-common: All messages marked as old but not deleted
On Fri, Jul 22, 2005 at 06:59:19AM -0400, Jaldhar H. Vyas wrote: On Fri, 22 Jul 2005, Steaphan Greene wrote: Package: dovecot-common Version: 0.99.14-1 Severity: important It seems that Dovecot marks every message served up by its pop and imap servers as Status: O if downloaded with certain clients (like fetchmail), which, according to RFC 2076 means message is old but not deleted - though this is non-standard. This makes mail readers that use this field (like mutt) think all new mail is just old unread mail. There also seems to be no way to disable this in the current version's configuration, making these clients unable to function correctly when used with dovecot. Can you check to see if this problem still exists in 0.99.20050712 which is in sid? The problem seems to no longer be there with 0.99.20050712. I haven't tested to see if the kmail problem is also resolved yet, but the problem with fetchmail/mutt seems to be gone. Thanks. -- Steaphan Greene [EMAIL PROTECTED] GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt signature.asc Description: Digital signature
