[Bug 445435] Re: evolution is hanging, if an email has a .tif attachment.
Bug is still in 10.04 LTS which uses gtk+ 2.20.. According to https://bugzilla.gnome.org/show_bug.cgi?id=581150 , this was patched in gtk+ 2.16.. did the patch not make it into ubuntu? OR perhaps the patch doesn't fix the problem. -- evolution is hanging, if an email has a .tif attachment. https://bugs.launchpad.net/bugs/445435 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 445435] Re: evolution is hanging, if an email has a .tif attachment.
When I strace evolution, and select the email with the tiff attachment, I can see it trying to open this file: /usr/share/icons/Humanity/mimes/22/image-x-generic.svg (via image- tiff.svg symlink) If you want to stick with Humanity theme (which I did).. you can copy the png from oxygen theme: cp /usr/share/icons/oxygen/22x22/mimetypes/image-x-generic.png /usr/share/icons/Humanity/mimes/22/image-x-generic.svg yes its a png with an svg extension, but it solves the problem! -- evolution is hanging, if an email has a .tif attachment. https://bugs.launchpad.net/bugs/445435 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 656358] [NEW] st module - dump of ext4 with block size = 1024k fails
Public bug reported: Binary package hint: linux-image-2.6.32-25-generic-pae When dumping an ext4 to an LTO-4 tape drive and specifying a block size of 1024K, dump fails - kernel reports st0: Can't allocate 1048576 byte tape buffer. dump -0uf /dev/nst0 -b 1024 /boot DUMP: Date of this level 0 dump: Thu Oct 7 00:03:43 2010 DUMP: Dumping /dev/sda1 (/boot) to /dev/nst0 DUMP: Label: none DUMP: Writing 1024 Kilobyte records DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 76708 blocks. DUMP: Volume 1 started with block 1 at: Thu Oct 7 00:03:46 2010 DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: 1.33% done, finished in 0:00 DUMP: write error 2048 blocks into volume 1: Value too large for defined data type DUMP: fopen on /dev/tty fails: No such device or address DUMP: The ENTIRE dump is aborted. NOTE: Strangely, dumping an ext3 file system to the same drive, using 1024K block size works fine. After this failure - the st module is confused - an mt -f /dev/st0 status reports Tape block size 13121963 bytes. Density code 0x0 (default). - whereas tape has variable block size - so should be zero. All subsequent attempts to read or write to the drive generate a failure : st0: Write not multiple of tape block size. If I unload st and reload it, then do mt -f /dev/st0 status, then its back to normal: Tape block size 0 bytes. Density code 0x46 (LTO-4). I can successfully dump ext4 to tape using 512k block size. DUMP: Date of this level 0 dump: Thu Oct 7 10:59:20 2010 DUMP: Dumping /dev/sda1 (/boot) to /dev/nst0 DUMP: Label: none DUMP: Writing 512 Kilobyte records DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 76196 blocks. DUMP: Volume 1 started with block 1 at: Thu Oct 7 10:59:21 2010 DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: 0.67% done, finished in 0:00 DUMP: Closing /dev/nst0 DUMP: Volume 1 completed at: Thu Oct 7 10:59:27 2010 DUMP: Volume 1 75776 blocks (74.00MB) DUMP: Volume 1 took 0:00:06 DUMP: Volume 1 transfer rate: 12629 kB/s DUMP: 75776 blocks (74.00MB) on 1 volume(s) DUMP: finished in 1 seconds, throughput 75776 kBytes/sec DUMP: Date of this level 0 dump: Thu Oct 7 10:59:20 2010 DUMP: Date this dump completed: Thu Oct 7 10:59:27 2010 DUMP: Average transfer rate: 12629 kB/s DUMP: DUMP IS DONE Device detection details is as follows: [ 11.583885] scsi 2:0:0:0: Sequential-Access IBM ULT3580-HH4 89B1 PQ: 0 ANSI: 3 [ 11.586457] scsi 2:0:0:0: Attached scsi generic sg0 type 1 [ 11.589235] scsi 2:0:0:1: Medium ChangerIBM 3573-TL 8.50 PQ: 0 ANSI: 5 [ 11.590793] st: Version 20081215, fixed bufsize 32768, s/g segs 256 [ 11.591059] st 2:0:0:0: Attached scsi tape st0 [ 11.591123] st 2:0:0:0: st0: try direct i/o: yes (alignment 4 B) [ 11.593079] osst :I: Tape driver with OnStream support version 0.99.4 [ 11.593080] osst :I: $Id: osst.c,v 1.73 2005/01/01 21:13:34 wriede Exp $ [ 11.626528] scsi 2:0:0:1: Attached scsi generic sg1 type 8 [ 11.628485] SCSI Media Changer driver v0.25 This is on an IBM BladeCenter S - HS21 blade server running ubuntu lucid (32-bit PAE), with a TS3100 Tape Library. The problem may lie with dump - but the fact that the st module needs reloading points to the module itself. ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Tags: dump ext4 st -- st module - dump of ext4 with block size = 1024k fails https://bugs.launchpad.net/bugs/656358 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 656358] Re: st module - dump of ext4 with block size = 1024k fails
On a seperate BladeCenter S, with same TS3100 tape library, and same lucid 32-bit pae install but on new HS21 blade server, the 1024k block dump of ext4 works. The only thing different is tape library firmware. On problem TS3100, its 8.50 / 2.80e , on working TS3100, its 7.30 / 2.70e. -- st module - dump of ext4 with block size = 1024k fails https://bugs.launchpad.net/bugs/656358 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 592745] Re: kernel panic - kernel stack corrupted
Received same kernel panic - so attaching to this bug report. [270989.199500] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: f83ccee0 This on an IBM HS22 blade server with dual quad-core Intel Xeon 5530 with 12GB running Lucid 2.6.32-24-generic-pae. Its configured as an application server running Nomachine's NX server providing gnome sessions to up to 30 users. In this instance, it has nothing to do with wireless (no wireless devices), nor powertop. Nothing known triggered this panic.. system was operational for a few days before this panic, with several users running gnome sessions. Here is lspci: 00:00.0 Host bridge: Intel Corporation 5520 I/O Hub to ESI Port (rev 13) 00:01.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI Express Root Port 1 (rev 13) 00:03.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI Express Root Port 3 (rev 13) 00:05.0 PCI bridge: Intel Corporation 5520/X58 I/O Hub PCI Express Root Port 5 (rev 13) 00:07.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI Express Root Port 7 (rev 13) 00:08.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI Express Root Port 8 (rev 13) 00:09.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI Express Root Port 9 (rev 13) 00:10.0 PIC: Intel Corporation 5520/5500/X58 Physical and Link Layer Registers Port 0 (rev 13) 00:10.1 PIC: Intel Corporation 5520/5500/X58 Routing and Protocol Layer Registers Port 0 (rev 13) 00:11.0 PIC: Intel Corporation 5520/5500 Physical and Link Layer Registers Port 1 (rev 13) 00:11.1 PIC: Intel Corporation 5520/5500 Routing Protocol Layer Register Port 1 (rev 13) 00:14.0 PIC: Intel Corporation 5520/5500/X58 I/O Hub System Management Registers (rev 13) 00:14.1 PIC: Intel Corporation 5520/5500/X58 I/O Hub GPIO and Scratch Pad Registers (rev 13) 00:14.2 PIC: Intel Corporation 5520/5500/X58 I/O Hub Control Status and RAS Registers (rev 13) 00:14.3 PIC: Intel Corporation 5520/5500/X58 I/O Hub Throttle Registers (rev 13) 00:15.0 PIC: Intel Corporation 5520/5500/X58 Trusted Execution Technology Registers (rev 13) 00:16.0 System peripheral: Intel Corporation 5520/5500/X58 Chipset QuickData Technology Device (rev 13) 00:16.1 System peripheral: Intel Corporation 5520/5500/X58 Chipset QuickData Technology Device (rev 13) 00:16.2 System peripheral: Intel Corporation 5520/5500/X58 Chipset QuickData Technology Device (rev 13) 00:16.3 System peripheral: Intel Corporation 5520/5500/X58 Chipset QuickData Technology Device (rev 13) 00:16.4 System peripheral: Intel Corporation 5520/5500/X58 Chipset QuickData Technology Device (rev 13) 00:16.5 System peripheral: Intel Corporation 5520/5500/X58 Chipset QuickData Technology Device (rev 13) 00:16.6 System peripheral: Intel Corporation 5520/5500/X58 Chipset QuickData Technology Device (rev 13) 00:16.7 System peripheral: Intel Corporation 5520/5500/X58 Chipset QuickData Technology Device (rev 13) 00:1a.0 USB Controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #4 00:1a.7 USB Controller: Intel Corporation 82801JI (ICH10 Family) USB2 EHCI Controller #2 00:1c.0 PCI bridge: Intel Corporation 82801JI (ICH10 Family) PCI Express Root Port 1 00:1c.4 PCI bridge: Intel Corporation 82801JI (ICH10 Family) PCI Express Root Port 5 00:1d.0 USB Controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #1 00:1d.1 USB Controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #2 00:1d.2 USB Controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #3 00:1d.7 USB Controller: Intel Corporation 82801JI (ICH10 Family) USB2 EHCI Controller #1 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 90) 00:1f.0 ISA bridge: Intel Corporation 82801JIB (ICH10) LPC Interface Controller 00:1f.3 SMBus: Intel Corporation 82801JI (ICH10 Family) SMBus Controller 06:00.0 PCI bridge: Vitesse Semiconductor VSC452 [SuperBMC] (rev 01) 07:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200EV 0b:00.0 SCSI storage controller: LSI Logic / Symbios Logic SAS1064ET PCI-Express Fusion-MPT SAS (rev 08) 10:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709S Gigabit Ethernet (rev 20) 10:00.1 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709S Gigabit Ethernet (rev 20) Previously had experienced a kernel panic with 64-bit lucid kernel, but was unable obtain log message - so not certain if its a repeat issue. Will see if it happens again. If there are any further details I could provide, please advise. -- kernel panic - kernel stack corrupted https://bugs.launchpad.net/bugs/592745 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 592745] Re: kernel panic - kernel stack corrupted
Well didn't have to wait long.. basically one day later - another kernel panic: [ 1769.714273] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: f825cee0 -- kernel panic - kernel stack corrupted https://bugs.launchpad.net/bugs/592745 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 491943] Re: Kernel trace buffer should be set to less unrealistic value
This fix works for me as well. Thanks Tim. -- Kernel trace buffer should be set to less unrealistic value https://bugs.launchpad.net/bugs/491943 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 491943] Re: Kernel trace buffer should be set to less unrealistic value
I have a 12 GB system with 2 quad-core Xeons running with lucid 32-bit PAE kernel, and am getting this as well. [ 13.068253] ureadahead invoked oom-killer: gfp_mask=0xd0, order=0, oom_adj=0 [ 13.068348] ureadahead cpuset=/ mems_allowed=0 [ 13.068433] Pid: 434, comm: ureadahead Not tainted 2.6.32-24-generic-pae #39-Ubuntu [ 13.068542] Call Trace: [ 13.068626] [c01d5714] oom_kill_process+0xa4/0x2b0 [ 13.068712] [c01d5d89] ? select_bad_process+0xa9/0xe0 [ 13.068800] [c01d5e11] __out_of_memory+0x51/0xa0 [ 13.068883] [c01d5eb8] out_of_memory+0x58/0xb0 [ 13.068969] [c01d86f7] __alloc_pages_slowpath+0x407/0x4a0 [ 13.069057] [c01d88ca] __alloc_pages_nodemask+0x13a/0x170 [ 13.069143] [c01d891c] __get_free_pages+0x1c/0x30 [ 13.069227] [c01b643a] ring_buffer_resize+0x18a/0x2a0 [ 13.069313] [c01b7a15] tracing_resize_ring_buffer+0x25/0x80 [ 13.069402] [c01bb772] tracing_entries_write+0xe2/0x160 [ 13.069485] [c01baf87] ? trace_nowake_buffer_unlock_commit+0x37/0x50 [ 13.069573] [c02ff724] ? security_file_permission+0x14/0x20 [ 13.069659] [c02123b4] ? rw_verify_area+0x64/0xe0 [ 13.069743] [c05b3347] ? unlock_kernel+0x27/0x30 [ 13.069828] [c02124d2] vfs_write+0xa2/0x1a0 [ 13.069911] [c035e7c9] ? copy_to_user+0x39/0x130 [ 13.069994] [c01bb690] ? tracing_entries_write+0x0/0x160 [ 13.070078] [c0212df2] sys_write+0x42/0x70 [ 13.070161] [c0109763] sysenter_do_call+0x12/0x28 [ 13.070243] Mem-Info: [ 13.070322] DMA per-cpu: [ 13.070459] CPU0: hi:0, btch: 1 usd: 0 [ 13.070542] CPU1: hi:0, btch: 1 usd: 0 [ 13.070623] CPU2: hi:0, btch: 1 usd: 0 [ 13.070705] CPU3: hi:0, btch: 1 usd: 0 [ 13.070786] CPU4: hi:0, btch: 1 usd: 0 [ 13.070870] CPU5: hi:0, btch: 1 usd: 0 [ 13.070951] CPU6: hi:0, btch: 1 usd: 0 [ 13.071032] CPU7: hi:0, btch: 1 usd: 0 [ 13.071114] Normal per-cpu: [ 13.071192] CPU0: hi: 186, btch: 31 usd: 176 [ 13.071274] CPU1: hi: 186, btch: 31 usd: 178 [ 13.071359] CPU2: hi: 186, btch: 31 usd: 76 [ 13.071442] CPU3: hi: 186, btch: 31 usd: 118 [ 13.071524] CPU4: hi: 186, btch: 31 usd: 135 [ 13.071609] CPU5: hi: 186, btch: 31 usd: 184 [ 13.071692] CPU6: hi: 186, btch: 31 usd: 172 [ 13.071773] CPU7: hi: 186, btch: 31 usd: 90 [ 13.071854] HighMem per-cpu: [ 13.071932] CPU0: hi: 186, btch: 31 usd: 172 [ 13.072014] CPU1: hi: 186, btch: 31 usd: 159 [ 13.072096] CPU2: hi: 186, btch: 31 usd: 166 [ 13.072177] CPU3: hi: 186, btch: 31 usd: 166 [ 13.072259] CPU4: hi: 186, btch: 31 usd: 40 [ 13.072343] CPU5: hi: 186, btch: 31 usd: 107 [ 13.072426] CPU6: hi: 186, btch: 31 usd: 185 [ 13.072510] CPU7: hi: 186, btch: 31 usd: 42 [ 13.072593] active_anon:204 inactive_anon:96 isolated_anon:0 [ 13.072593] active_file:122 inactive_file:618 isolated_file:0 [ 13.072594] unevictable:0 dirty:0 writeback:0 unstable:0 [ 13.072595] free:2914842 slab_reclaimable:404 slab_unreclaimable:5300 [ 13.072596] mapped:335 shmem:52 pagetables:73 bounce:0 [ 13.073010] DMA free:3524kB min:64kB low:80kB high:96kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15840kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:68kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes [ 13.073220] lowmem_reserve[]: 0 867 12149 12149 [ 13.073595] Normal free:3564kB min:3732kB low:4664kB high:5596kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:176kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:887976kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:1616kB slab_unreclaimable:21132kB kernel_stack:1312kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:55 all_unreclaimable? no [ 13.073810] lowmem_reserve[]: 0 0 90262 90262 [ 13.074184] HighMem free:11652280kB min:512kB low:12652kB high:24796kB active_anon:816kB inactive_anon:384kB active_file:492kB inactive_file:2296kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:11553620kB mlocked:0kB dirty:0kB writeback:0kB mapped:1340kB shmem:208kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:292kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no [ 13.074446] lowmem_reserve[]: 0 0 0 0 [ 13.074815] DMA: 3*4kB 1*8kB 5*16kB 5*32kB 3*64kB 2*128kB 3*256kB 2*512kB 1*1024kB 0*2048kB 0*4096kB = 3524kB [ 13.075623] Normal: 24*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 1*512kB 1*1024kB 1*2048kB 0*4096kB = 3680kB [ 13.076425] HighMem: 146*4kB 129*8kB 50*16kB 30*32kB 14*64kB 10*128kB 4*256kB 2*512kB 4*1024kB 6*2048kB 2839*4096kB = 11652528kB [
[Bug 491943] Re: Kernel trace buffer should be set to less unrealistic value
An easy way to disable ureadahead without uninstalling is to just move /etc/init/ureadahead* someplace else. eg. mv /etc/init/ureadahead* /root -- Kernel trace buffer should be set to less unrealistic value https://bugs.launchpad.net/bugs/491943 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 558431] Re: gparted crashes at startup - Assertion failed
Same issue with a Kingston 4GB DataTraveler. Backtrace has 16 calls on stack: 16: /lib/libparted.so.0(ped_assert+0x2a) [0x16af0a] 15: /lib/libparted.so.0(+0x42507) [0x1a2507] 14: /lib/libparted.so.0(+0x43317) [0x1a3317] 13: /lib/libparted.so.0(+0x4460c) [0x1a460c] 12: /lib/libparted.so.0(+0xf7b1) [0x16f7b1] 11: /lib/libparted.so.0(ped_disk_add_partition+0x262) [0x173032] 10: /lib/libparted.so.0(+0x45fa3) [0x1a5fa3] 9: /lib/libparted.so.0(+0x4619f) [0x1a619f] 8: /lib/libparted.so.0(ped_disk_new+0x75) [0x173e15] 7: parted() [0x804e389] 6: parted() [0x804f553] 5: parted() [0x80517da] 4: parted() [0x8052e51] 3: parted(main+0x2e) [0x8052f5e] 2: /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6) [0x31fbd6] 1: parted() [0x804c3f1] Assertion (head_size = 63) at ../../../libparted/labels/dos.c:659 in function probe_partition_for_geom() failed. This has something to do with manufacturers partitioning - here is what fdisk shows: r...@quabuntu:~# fdisk /dev/sdb WARNING: DOS-compatible mode is deprecated. It's strongly recommended to switch off the mode (command 'c') and change display units to sectors (command 'u'). Command (m for help): p Disk /dev/sdb: 3980 MB, 3980394496 bytes 9 heads, 9 sectors/track, 95977 cylinders Units = cylinders of 81 * 512 = 41472 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x Device Boot Start End Blocks Id System /dev/sdb1 * 100 95978 3883072c W95 FAT32 (LBA) If I delete the partition, and recreate a new primary partition, then parted works fine. -- gparted crashes at startup - Assertion failed https://bugs.launchpad.net/bugs/558431 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 264333] Re: remote printer : freeze when not available
This problem rears its head in many applications. Some WINE apps, for
example, try to connect to ALL defined cups printers (regardless of
whether they are set as default, or were the last-used printer), and
hang, waiting for connection to remote printer which isn't connected.
Another example is vym, which won't even start if it cannot connect to
ALL printers.. see https://bugzilla.novell.com/show_bug.cgi?id=418439
...
Some apps will timeout, but some seem to hang forever (Adobe acrobat).
MacOS uses CUPS - I wonder how it handles the same situation??
Anyway, the best solution I could find so far is based on what was
posted above by Sangala. IE. a script that checks which printer is
accessible and IF NOT, rejects packets destined there.
I toyed with the idea of having a script which actually removed the
printer from cups (lpadmin -x), but re-creating the printer is a little
more involved, and it seems like overkill. Unfortunately disabling or
rejecting the printer within CUPS, does not stop it from broadcasting
the printer to requesting applications.
Anyway, I simplified Sangala's script (removing requirement for MAC) and
put it in cron to run every 5 minutes (this is on a server running 24x7
with some off and on VPN connected printers):
#!/bin/bash
PINGTIME=3
PINGCOUNT=1
PINGCMD=/bin/ping
processByPing(){
if [ $# -eq 2 ]; then
$PINGCMD -c $PINGCOUNT -q -W $PINGTIME $1 /dev/null
if [ $? = 0 ]; then
iptables -D OUTPUT -p tcp -d $1 --dport $2 -j REJECT /dev/null
#Printer on IP: $1 port: $2 is accessible
else
iptables -D OUTPUT -p tcp -d $1 --dport $2 -j REJECT /dev/null
iptables -I OUTPUT -p tcp -d $1 --dport $2 -j REJECT /dev/null
#Printer on IP: $1 port: $2 is NOT accessible
fi
else
echo Bad parameters
fi
}
#Detect remote printers
#every remote printer server or printers
#1st IP addres
#2nd port
processByPing 10.8.0.62 631 #vpn connected printer #1
processByPing 10.8.0.74 631 #vpn connected printer #2
exit 0
I saved it as /usr/local/sbin/reject-remote-printers (and chmod 744) and added
this to cron:
*/5 * * * * /usr/local/sbin/reject-remote-printers
This way, within 5 mintues of VPN users connecting, their printers are
able to receive packets... and within 5 minutes of disconnecting, the
packets are rejected.
Thanks Sangala for the idea! It maybe convoluted, but it works!!
** Bug watch added: Novell/SUSE Bugzilla #418439
https://bugzilla.novell.com/show_bug.cgi?id=418439
--
remote printer : freeze when not available
https://bugs.launchpad.net/bugs/264333
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 147551] Re: cups-pdf fails to generate file when user does not print to default ~/PDF (apparmor vs.cups-pdf inconsistency)
Had this issue on hardy, found this bug - thought I'd share my solution.
In /etc/apparmor.d/usr.sbin/cupsd , here is my /usr/lib/cups/backend
/cups-pdf section:
/usr/lib/cups/backend/cups-pdf {
#include abstractions/base
#include abstractions/fonts
#include abstractions/nameservice
#include abstractions/user-tmp
capability chown,
capability fowner,
capability fsetid,
capability setgid,
capability setuid,
/bin/dash ixr,
/bin/bash ixr,
/etc/papersize r,
/etc/cups/cups-pdf.conf r,
@{HOME}/PDF/ rw,
@{HOME}/PDF/* rw,
/usr/bin/gs ixr,
/usr/lib/cups/backend/cups-pdf mr,
# /usr/lib/ghostscript/** mr,
/usr/share/** r,
/var/log/cups/cups-pdf_log w,
/var/spool/cups-pdf/** rw,
/var/tmp/ rw,
/var/tmp/** rw,
/var/spool/cups/ rw,
/var/spool/cups/** rw,
}
NOTE: commented out reference to non-existent /usr/lib/ghostscript, and
added /var/tmp and /var/spool/cups.
ALSO - output directory has to have perms at 700.. ie. chmod 700 ~/PDF
--
cups-pdf fails to generate file when user does not print to default ~/PDF
(apparmor vs.cups-pdf inconsistency)
https://bugs.launchpad.net/bugs/147551
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 304036] Re: evolution mailto CLI cannot handle attachments with # in filename
Will this fix make it into hardy? It is an LTS release.. and is my companies primary platform. -- evolution mailto CLI cannot handle attachments with # in filename https://bugs.launchpad.net/bugs/304036 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 304036] [NEW] evolution mailto CLI cannot handle attachments with # in filename
Public bug reported: When attempting to attach a file from the command line using evolution 'mailto:?attachment=file:///...' and the filename has a # (0x23) in it, the filename gets truncated at the #, and therefore cannot attach the file. URI-encoded filenames have the same problem (with %23). This is a fairly serious problem since OpenOffice uses this method for attaching files with choosing File - Send... So any OpenOffice document with # in the filename, cannot be sent with evolution. (of course workaround is saving the file, and then launching evolution, and attaching from a compose window ... a total pain). **Steps To Reproduce... Create an OpenOffice document with a # in the name.. set evolution as your mail handler.. and try to send the document. OR try from the command line: evolution 'mailto:?attachment=file:///home/user/some # document' Below is example of how OO uri-encodes the filename, but evolution still truncates after the %23 ++ echo 'file:///tmp/svjia.tmp/svjm4.tmp/K1 London #2 (asdf) CofA.pdf' ++ /usr/lib/openoffice/program/uri-encode + MAILTO='attachment=file:///tmp/svjia.tmp/svjm4.tmp/K1%20London%20%20%232%20%20%20(asdf)%20CofA.pdf' + shift + shift + '[' '' '!=' '' ']' + MAILTO='mailto:?attachment=file:///tmp/svjia.tmp/svjm4.tmp/K1%20London%20%20%232%20%20%20(asdf)%20CofA.pdf' + evolution 'mailto:?attachment=file:///tmp/svjia.tmp/svjm4.tmp/K1%20London%20%20%232%20%20%20(asdf)%20CofA.pdf' + exit 0 ** Affects: evolution (Ubuntu) Importance: Undecided Status: New -- evolution mailto CLI cannot handle attachments with # in filename https://bugs.launchpad.net/bugs/304036 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 53387] Re: Boot order problem
FYI, a workaround that I am using.. in /etc/rc.local I put the following: sudo ifdown eth1 sudo ifup eth1 (where eth1 is my wireless interface) -- Boot order problem https://bugs.launchpad.net/bugs/53387 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 53387] Re: Boot order problem
Having same issue - ubuntu feisty - with the following
/etc/wpa_supplicant.conf
ctrl_interface=/var/run/wpa_supplicant
network={
ssid=daintylink
scan_ssid=1
key_mgmt=NONE
wep_key0={wep key}
wep_tx_keyidx=0
priority=999
auth_alg=SHARED
}
network={
ssid=airplus
scan_ssid=1
key_mgmt=NONE
wep_key0={wep key}
wep_tx_keyidx=0
priority=998
auth_alg=SHARED
}
And the followng entry in /etc/network/interfaces:
auto eth1
iface eth1 inet dhcp
pre-up /sbin/wpa_supplicant -Bw -Dwext -ieth1 -c/etc/wpa_supplicant.conf
post-down /usr/bin/killall -q wpa_supplicant
Again - /etc/init.d/networking restart works... but reboot..
wpa_supplicant and dhclient get launched but interface does not come up!
-Bob
--
Boot order problem
https://bugs.launchpad.net/bugs/53387
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 57875] Re: Azureus does not start
Azureus crashed with JRE 1.5 update 9 as well. Installed azureus-gcj (x86).. works if I do sudo update-alternatives --config java and select java-gcj Problem is, this breaks Frostwire... So, altered /usr/bin/frostwire to be: #!/bin/bash cd /usr/lib/frostwire export JAVA_PROGRAM_DIR=/usr/lib/jvm/java-1.5.0-sun/bin/ sh runFrost.sh So for now - both work ah.. the joys of java -- Azureus does not start https://launchpad.net/bugs/57875 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 69339] Re: ipw3945 module fails to detect wireless card after upgrade
Yes - sorry.. not quite out-of-the-box.. I always install linux- restricted-modules. I've since upgraded to Edgy and have no wireless issues. Thanks. -- ipw3945 module fails to detect wireless card after upgrade https://launchpad.net/bugs/69339 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 69339] ipw3945 module fails to detect wireless card after upgrade
Public bug reported: Binary package hint: linux-image-2.6.15-27-686 Upgraded to latest 2.6.15-27 kernel (tried both 386 and 686) and the ipw3945 stopped detecting my wireless card. Previous version was 2.6.15-23 in which wireless card worked out-of-the-box. The workaround is this: sudo cp /sbin/ipw3945d-2.6.15-23-686 /sbin/ipw3945d-2.6.15-27-686 Obviously this is just a module version mismatch, but not good when it breaks wireless completely. BJ. ** Affects: linux-source-2.6.15 (Ubuntu) Importance: Undecided Status: Unconfirmed -- ipw3945 module fails to detect wireless card after upgrade https://launchpad.net/bugs/69339 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
