Bug#920764: login: Please add /dev/ttyLP0 /dev/ttyLP1 to securetty

[Andrew Lunn]

Source: shadow
Version: 4.5
Severity: normal

Dear Maintainer,

I've install Debian on an Freescale Vybrid SoC, vf610. The Linux driver 
for its UARTs name the ttyLP0, ttyLP1. Please could you add these names
to /etc/securetty so that root can login via these UARTs. 

-- System Information:
Debian Release: 8.11
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: armhf (armv7l)

Kernel: Linux 5.0.0-rc3-00348-g830d493c07f6-dirty
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#892057: Fwd: Re: TS-x09 fails to boot when obtaining MAC

[Andrew Lunn]

On Tue, Mar 27, 2018 at 12:50:04AM +0200, Martin Michlmayr wrote:
> The fix is in Linus' tree since v.16-rc5:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=13a55372b64e00e564a08d785ca87bd9d454ba30
> 
> I don't see it in 4.9 stable or the stable queue.  Will Greg pick it
> up automatically because of the Fixes: info or do we have to let him
> know?

Hi Dave

This is one of your own patches. Please could you add it to stable, if
it is not already.

Thanks
Andrew

Bug#887873: linux-image-4.9.0-5-marvell: frequent "usercopy: kernel memory overwrite attempt detected" on QNAP NAS (ARM)

[Andrew Lunn]

> > Hi Menno
> > 
> > Could you also try linux-image-4.14.0-3-marvell from sid?
> 
> Can do. Should I just use the kernel packages from sid or update the whole 
> system to sid?

Hi Menno

The kernel packages should be sufficient.

Andrew

Bug#887873: linux-image-4.9.0-5-marvell: frequent "usercopy: kernel memory overwrite attempt detected" on QNAP NAS (ARM)

[Andrew Lunn]

On Thu, Mar 08, 2018 at 09:49:29AM +1300, Menno Finlay-Smits wrote:
> On Thu, 8 Mar 2018, at 02:36, Andrew Lunn wrote:
> > > What else can I try?
> > 
> > Do you have transparent huge pages enabled?
> > 
> > ~$ cat /sys/kernel/mm/transparent_hugepage/enabled 
> > [always] madvise never
> > 
> > If so, could you disable it with:
> > 
> > echo never > /sys/kernel/mm/transparent_hugepage/enabled
> > 
> > and run your rsync command.

Hi Menno

Could you also try linux-image-4.14.0-3-marvell from sid?

There does not appear to be a 4.15 yet for marvell.

  Andrew

Bug#887873: linux-image-4.9.0-5-marvell: frequent "usercopy: kernel memory overwrite attempt detected" on QNAP NAS (ARM)

[Andrew Lunn]

> What else can I try?

Do you have transparent huge pages enabled?

~$ cat /sys/kernel/mm/transparent_hugepage/enabled 
[always] madvise never

If so, could you disable it with:

echo never > /sys/kernel/mm/transparent_hugepage/enabled

and run your rsync command.

Thanks
Andrew

Bug#887873: linux-image-4.9.0-5-marvell: frequent "usercopy: kernel memory overwrite attempt detected" on QNAP NAS (ARM)

[Andrew Lunn]

> What else can I try? There doesn't appear to be a newer kernel in
> proposed right now.

Are you happy to apply patches, build a kernel, and test it?

Thanks
Andrew

Bug#887873: linux-image-4.9.0-5-marvell: frequent "usercopy: kernel memory overwrite attempt detected" on QNAP NAS (ARM)

[Andrew Lunn]

On Sun, Mar 04, 2018 at 09:41:15PM +0100, Andrew Lunn wrote:
> On Sun, Mar 04, 2018 at 06:41:57PM +0100, Martin Michlmayr wrote:
> > A Debian user reported the following issue on QNAP TS-119P II with
> > 4.9.65:
> > 
> > * Menno Finlay-Smits <in...@menno.io> [2018-01-21 23:08]:
> > > Rsyncing files between 2 HDDs on a QNAP 119p with a fresh, minimal 
> > > install of
> > > stretch NAS (armel) causes the kernel to fail after ~20mins with a kernel
> > > memory overwrite attempt (full error below). 
> 
> Please can you give me the exact rsync command being used. Having a
> unix domain socket seems a bit odd for rsync'ing files on the same
> machine.

I played with this a bit. When you rsync with both source and target
on the same machine, it appears to fork two processes, and connect
them together via a unix domain socket.

I tried reproducing this with 4.9.86. I used the command

rsync -az /home /root/home

which copied 12G of data. No problems seen. But this is one disk. I
assume the machine giving the problem has one of the disks as USB,
since the QNAP TS-119P II is a single bay NAS. So it could be the USB
disk is slower than the internal disk, and there is a backlog building
up. First a backlog for writing out to the disk, then a backlog
forming on the Unix domain socket? So maybe that is why i cannot
reproduce it. Or the problem has been fixed between 4.9.65 and 4.9.86.

Would it be possible to try to reproduce this problem with 4.9.86 on
the hardware reporting the issue?

Thanks
Andrew

Bug#887873: linux-image-4.9.0-5-marvell: frequent "usercopy: kernel memory overwrite attempt detected" on QNAP NAS (ARM)

[Andrew Lunn]

On Sun, Mar 04, 2018 at 06:41:57PM +0100, Martin Michlmayr wrote:
> A Debian user reported the following issue on QNAP TS-119P II with
> 4.9.65:
> 
> * Menno Finlay-Smits  [2018-01-21 23:08]:
> > Rsyncing files between 2 HDDs on a QNAP 119p with a fresh, minimal install 
> > of
> > stretch NAS (armel) causes the kernel to fail after ~20mins with a kernel
> > memory overwrite attempt (full error below). 

Please can you give me the exact rsync command being used. Having a
unix domain socket seems a bit odd for rsync'ing files on the same
machine.

Thanks
Andrew

Bug#887873: linux-image-4.9.0-5-marvell: frequent "usercopy: kernel memory overwrite attempt detected" on QNAP NAS (ARM)

[Andrew Lunn]

On Sun, Mar 04, 2018 at 06:41:57PM +0100, Martin Michlmayr wrote:
> A Debian user reported the following issue on QNAP TS-119P II with
> 4.9.65:
> 
> * Menno Finlay-Smits  [2018-01-21 23:08]:
> > Rsyncing files between 2 HDDs on a QNAP 119p with a fresh, minimal install 
> > of
> > stretch NAS (armel) causes the kernel to fail after ~20mins with a kernel
> > memory overwrite attempt (full error below). 
> > 
> > This happens reliably for any large rsync attempt. I have about 1TB of data 
> > to
> > copy between these 2 HDDs and have not managed to copy more than ~2% of the
> > total amount.
> > 
> > ** Kernel log:
> > 
> > [ 2775.213733] usercopy: kernel memory overwrite attempt detected to 
> > c29454e0 () (4294802208 bytes)

Not seen this before.

My first thought is that this actually looks like a userspace
problem. Userspace is passing 4294802208 bytes to the kernel. But the
kernel should of already sanity checked that before trying to copy it
into kernel space. This is also a Unix domain socket, which sounds odd
for rsync. And this is all generic code, nothing specific to kirkwood.

Has there been any similar reports on other targets?

Andrew

> > [ 2775.224095] [ cut here ]
> > [ 2775.228728] kernel BUG at 
> > /build/linux-myVvPm/linux-4.9.65/mm/usercopy.c:75!
> > [ 2775.235800] Internal error: Oops - BUG: 0 [#1] ARM
> > [ 2775.240604] Modules linked in: marvell ehci_orion mvmdio mv643xx_eth 
> > ehci_hcd of_mdio fixed_phy xhci_pci xhci_hcd marvell_cesa des_generic sg 
> > usbcore libphy m25p80 spi_nor orion_wdt usb_common kirkwood_thermal evdev 
> > gpio_keys ip_tables x_tables ipv6 autofs4 ext4 crc16 jbd2 crc32c_generic 
> > fscrypto ecb mbcache sd_mod sata_mv libata scsi_mod
> > [ 2775.271023] CPU: 0 PID: 601 Comm: rsync Not tainted 4.9.0-5-marvell #1 
> > Debian 4.9.65-3+deb9u2
> > [ 2775.279582] Hardware name: Marvell Kirkwood (Flattened Device Tree)
> > [ 2775.285870] task: c0d496c0 task.stack: d5ffe000
> > [ 2775.290418] PC is at __check_object_size+0x120/0x1d8
> > [ 2775.295401] LR is at __check_object_size+0x120/0x1d8
> > [ 2775.300382] pc : []lr : []psr: 6013
> >sp : d5fffdb8  ip :   fp : d508
> > [ 2775.311908] r10: d5ffe000  r9 : fffd7b20  r8 : c29454e0
> > [ 2775.317148] r7 : c291d000  r6 :   r5 : fffd7b20  r4 : c29454e0
> > [ 2775.323697] r3 : c0554fa0  r2 : c055a20c  r1 : c055094c  r0 : 0065
> > [ 2775.330247] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment 
> > none
> > [ 2775.337405] Control: 0005397f  Table: 1481  DAC: 0051
> > [ 2775.343168] Process rsync (pid: 601, stack limit = 0xd5ffe190)
> > [ 2775.349020] Stack: (0xd5fffdb8 to 0xd600)
> > [ 2775.353390] fda0:   
> > c04623b8 fffd7b20
> > [ 2775.361598] fdc0: 000294e8 fffd7b20 1000 d5fffec0 c29454e0 c0202360 
> > 0008 008eafe8
> > [ 2775.369812] fde0: dfc4a380 c291c000 0051 6908 d5fffec0 8000 
> > 0008 0008
> > [ 2775.378026] fe00: 1000  c0c26b40 1008 c0495cf7 c02fc3d0 
> > c0c26b40 d5fffec0
> > [ 2775.386240] fe20: d5fffec0  8008 c0c26b40 df782d80 d5fffeb8 
> > 0001 
> > [ 2775.394445] fe40: df782b40 c03a21d0 d5fffe64 0003 de65b2c0 8000 
> > 0008 8008
> > [ 2775.402651] fe60: 5a644f89      
> >  
> > [ 2775.410866] fe80: d2bebb80 d5fffeb8 de65b2c0 de65b2c0 df79caa0 008c1b00 
> > d5ffe000 
> > [ 2775.419080] fea0: 00512e6c c02ee92c d510 d528 de65b2c0 c02ee9cc 
> >  
> > [ 2775.427294] fec0: 0001 0008 8000 d508 0001 3b9aa9ee 
> >  
> > [ 2775.435499] fee0: 0040 d528   df79caa0 d588 
> > 8008 c0114048
> > [ 2775.443705] ff00: 8008  008c1b00 8008 0001  
> > 8008 d508
> > [ 2775.451909] ff20: 0001 3b9aa9ee df79caa0    
> >  
> > [ 2775.460116] ff40:    df79caa0 8008  
> > d588 c0114cb4
> > [ 2775.468321] ff60: df79caa0 008c1b00 8008 df79caa0 df79caa0 008c1b00 
> > 8008 c000f704
> > [ 2775.476527] ff80: d5ffe000 c0115b68   8008 00512e6c 
> > bedfb878 bedfb7f8
> > [ 2775.484733] ffa0: 0004 c000f560 00512e6c bedfb878 0004 008c1b00 
> > 8008 008c1b00
> > [ 2775.492947] ffc0: 00512e6c bedfb878 bedfb7f8 0004 00520a80 00512e84 
> > 0051095c 00512e6c
> > [ 2775.501161] ffe0:  bedfb69c 004c6978 b6ea3d1c 4010 0004 
> > 624f 624f
> > [ 2775.509384] [] (__check_object_size) from [] 
> > (copy_page_from_iter+0x2e8/0x3d0)
> > [ 2775.518388] [] (copy_page_from_iter) from [] 
> > (skb_copy_datagram_from_iter+0xfc/0x188)
> > [ 2775.527997] [] (skb_copy_datagram_from_iter) from [] 
> > (unix_stream_sendmsg+0x208/0x2f8)
> > [ 2775.537691] [] 

Bug#860387: ostinato: .deb for python binding

[Andrew Lunn]

Package: ostinato
Version: 0.8-1
Severity: wishlist

Dear Maintainer,

The Ostinator sources contain a python binding library. This allows
the drone to be used directly from python scripts, rather than using
the GUI. This is particularly useful for Continuous Integration
setups.

Currently, this python binding is not packaged. It would be nice if
the packaging scripts where exteneded to create a python-ostinator.deb
containing this binding.

-- System Information:
Debian Release: 7.11
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Bug#811351: additional request...

[Andrew Lunn]

> I can add more verbose comments to mainline kernel .dts on how to
> enable serial port, and how to select between rs232/485. Andrew, do
> you want me to resend the current patches, or can it be done with an
> incremental patch?

Either, but incremental is probably easiest.

Andrew

Bug#811351: additional request...

[Andrew Lunn]

> As per the above discussion, would it be possible to have the patch
> comment the code, rather than delete it, so that people with a need
> for the serial port could activate it?  Maybe also add a note in the
> /usr/share/doc/ as to how to perform the activation.

FYI

The patches go into the kernel source tree. What goes into
/usr/share/doc is up to the distribution, and i'm not aware of any
mechanism of kernel documentation getting placed in there in Debian.

Possible you better bet for documentation is to suggest some text for:

https://www.cyrius.com/debian/kirkwood/openrd/

Andrew

Bug#714959: linux-image-3.2.0-4-kirkwood mdraid array fails to assemble b/c drives are not yet ready (sata_mv)

[Andrew Lunn]

 Having looked back at the initial mail, it looks like dmesg_error.txt
 and dmesg_after_patch.txt show approximately the same thing, or at least
 I'm not spotting the error.

I think error is too strong a word. It is more a problem of just
going too slow. Take a look at the time stamps. In the error case,
it takes it nearly 5 minutes to get the raid array assembled and
going. For some reason, adding the last disk to a partially assembled
raid is getting delayed long after the disc pops into existence.

 Andrew


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#714959: linux-image-3.2.0-4-kirkwood mdraid array fails to assemble b/c drives are not yet ready (sata_mv)

[Andrew Lunn]

On Wed, Mar 26, 2014 at 03:09:18PM +0100, Sebastian Hesselbarth wrote:
 On 03/26/2014 02:55 PM, Andrew Lunn wrote:
 * Martin Waschbuesch mar...@waschbuesch.de [2013-07-04 19:12]:
 Package: src:linux Version: 3.2.46-1 Severity: normal Tags:
 upstream patch
 
 Dear Maintainer,
 
 On my QNAP TS-412, after a clean install of Wheezy, the kernel
 fails to bring up all sata ports (using Marvell 88SX7042 via
 sata_mv driver) before md/raid tries to assemble the array. The
 same disks/array work in a different model (TS-410) and the
 drives/array from said TS-410 also fail in my TS-412. At the same
 time, using the original QNAP firmware, everything works as
 expected.
 
 I _guess_ the real problem here is the power supply. It cannot
 supply enough power to get all the drives spinning if they all start
 at the same time. Many of the multi-bay NAS boxes have GPIO lines
 which are used to individually power up each driver in a staggered
 way. The QNAP kernel patch is doing something similar. However in its
 current form it cannot be accepted. This delay needs to be made
 conditional and only applied on hardware with a weak power supply.
 
 I will take a look at the code and see how the platform can pass a
 flag to the driver that it needs to stagger port initialization.
 
 Actually, the code in question is not SoC's mvsata but PCI's mvsata,
 I guess.

Yes, it is a 4 port controller on the PCI bus, not the two ports in
the SoC. Same problem though.

It also seems like this is not the first board with this problem:

drivers/ata/libata-core.c:

static void async_port_probe(void *data, async_cookie_t cookie)
{
struct ata_port *ap = data;

/*
 * If we're not allowed to scan this host in parallel,
 * we need to wait until all previous scans have completed
 * before going further.
 * Jeff Garzik says this is only within a controller, so we
 * don't need to wait for port 0, only for later ports.
 */
if (!(ap-host-flags  ATA_HOST_PARALLEL_SCAN)  ap-port_no != 0)
async_synchronize_cookie(cookie);

I need to check if sata_mv is using this code, and what flags it has
set.

Andrew


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#714959: linux-image-3.2.0-4-kirkwood mdraid array fails to assemble b/c drives are not yet ready (sata_mv)

[Andrew Lunn]

 * Martin Waschbuesch mar...@waschbuesch.de [2013-07-04 19:12]:
  Package: src:linux
  Version: 3.2.46-1
  Severity: normal
  Tags: upstream patch
  
  Dear Maintainer,
  
  On my QNAP TS-412, after a clean install of Wheezy, the kernel fails to 
  bring up all sata ports (using Marvell 88SX7042 via sata_mv driver) before 
  md/raid tries to assemble the array.
  The same disks/array work in a different model (TS-410) and the 
  drives/array from said TS-410 also fail in my TS-412.
  At the same time, using the original QNAP firmware, everything works as 
  expected.

I _guess_ the real problem here is the power supply. It cannot supply
enough power to get all the drives spinning if they all start at the
same time. Many of the multi-bay NAS boxes have GPIO lines which are
used to individually power up each driver in a staggered way. The QNAP
kernel patch is doing something similar. However in its current form
it cannot be accepted. This delay needs to be made conditional and
only applied on hardware with a weak power supply.

I will take a look at the code and see how the platform can pass a
flag to the driver that it needs to stagger port initialization.

 Andrew


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#714959: linux-image-3.2.0-4-kirkwood mdraid array fails to assemble b/c drives are not yet ready (sata_mv)

[Andrew Lunn]

  +#defineQMV_SATA_INIT_DELAY_PHASE   5000 //milliseconds
  +
  +
   /*
* module options
*/
  @@ -4329,7 +4333,11 @@
  struct ata_port *ap = host-ports[port];
  void __iomem *port_mmio = mv_port_base(hpriv-base, port);
  unsigned int offset = port_mmio - hpriv-base;
  -
  +   // marvell 7042 port 2 port 3 will power on by order every  5 
  sec
  +   if( (port==2) || (port == 3) ){
  +   printk(Wait %d seconds to initialize scsi 
  %d.\n,QMV_SATA_INIT_DELAY_PHASE/1000,port);
  +   mdelay(QMV_SATA_INIT_DELAY_PHASE);
  +   }
  ata_port_pbar_desc(ap, MV_PRIMARY_BAR, -1, mmio);
  ata_port_pbar_desc(ap, MV_PRIMARY_BAR, offset, port);
  }

As i look at what this code is doing within this loop, you start to
wonder what is really going on here. The code does not initialize any
ATA ports. It is just adding strings to the PCI description.

If you look at the timing in dmesg_after_patch.txt and
dmesg_error_txt, for the last driver:

dmesg_error_txt
[   19.284722] ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300)

vs

dmesg_after_patch.txt
[   22.276626] ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300)

The error case is actually 3 seconds faster at detecting all the
drives.

The real clue could be:

// marvell 7042 port 2 port 3 will power on by order every  5 sec

So what i think is happening is the controller is performing a
staggered start, independent of the software. The 10 second pause
added by this patch means all the discs are spinning by the time the
driver goes looking at them, and so it notices 4 drives all at the
same time. Without the pause, three drives are ready, and the four
pops up later.

I think the real problem here is, why does it take 230 seconds between
the drive becoming available, and the md: bindsdd1.

I think you need to be talking to the device mapper/raid people.

  Andrew


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#731345: flash-kernel: add support for DT based kernels on Sheeva Plug

[Andrew Lunn]

 Hi Marc
 
 I've not tested it, but ethernet should work. Adding DT support to the
 ethernet driver took time, so during the transition, we instantiated
 ethernet using old style platform_driver.
 
 If it really does not work, it is a bug, which i will fix and get put
 into stable.
 
 Feel free to ask me about such issues.
 

 Sheeva Plug without DT works on 3.11, but there isn't any Ethernet
 with 3.11 and appended DT. I'm in 3.12 with my proposed patches and
 everything is fine.

So i looked at 3.11. The code is there to start the ethernet on Sheeva
plug. So it is not obvious why it does not work.

If you are happy with 3.12, i won't debug further. But if 3.11 is of
interest, i can help figure out what is wrong.

   Andrew


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#731345: flash-kernel: add support for DT based kernels on Sheeva Plug

[Andrew Lunn]

 Not quite, as 3.11 comes with DT for the sheeva plug, but that DT
 lacks ethernet support.

Hi Marc

I've not tested it, but ethernet should work. Adding DT support to the
ethernet driver took time, so during the transition, we instantiated
ethernet using old style platform_driver.

If it really does not work, it is a bug, which i will fix and get put
into stable.

Feel free to ask me about such issues.

 Andrew


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#549050: cupsd segfaults on SIGHUP

[Andrew Lunn]

Me two:

londo:/var/log# zless kern.log* | grep cups
Oct 25 06:56:46 londo kernel: cupsd[3772]: segfault at 2b24d0e8 ip b7d803e4 sp 
bf965320 error 4 in libcups.so.2[b7d71000+41000]
Oct 28 06:40:20 londo kernel: cupsd[6838]: segfault at 2be440d8 ip b7e753e4 sp 
bfb13b50 error 4 in libcups.so.2[b7e66000+41000]
Oct 19 06:54:39 londo kernel: cupsd[13789]: segfault at 4d4554 ip b7d7a582 sp 
bfc6ac60 error 4 in libcups.so.2[b7d6b000+41000]
Oct 15 06:53:33 londo kernel: cupsd[18334]: segfault at 299e70e0 ip b7e593e4 sp 
bfbed9d0 error 4 in libcups.so.2[b7e4a000+41000]
Oct  5 06:55:19 londo kernel: cupsd[10661]: segfault at 29a440e0 ip b7d363e4 sp 
bf8f41d0 error 4 in libcups.so.2[b7d27000+41000]
Oct  7 06:35:54 londo kernel: cupsd[3697]: segfault at 2bab3d68 ip b7d7a3e4 sp 
bfde3700 error 4 in libcups.so.2[b7d6b000+41000]
Oct  9 06:58:33 londo kernel: cupsd[2038]: segfault at 2c0600d8 ip b7e203e4 sp 
bfe4a2c0 error 4 in libcups.so.2[b7e11000+41000]
Oct 11 06:38:45 londo kernel: cupsd[20610]: segfault at 29f5d0d8 ip b7e143e4 sp 
bfb6d900 error 4 in libcups.so.2[b7e05000+41000]
Sep 30 06:51:04 londo kernel: cupsd[26457]: segfault at 17 ip 0017 sp 
bfac3edc error 4 in libnss_files-2.9.so[b79ff000+a000]
Oct  1 06:46:39 londo kernel: cupsd[12447]: segfault at 289cd0d8 ip b7ce03e4 sp 
bfde3880 error 4 in libcups.so.2[b7cd1000+41000]

However i'm not sure poppler-utils is an issue. I don't have it
installed.

Andrew



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#445670: aiccu: Asked twice about configuration when updating package

[Andrew Lunn]

Package: aiccu
Version: 20070115-6
Severity: wishlist


When updating the aiccu package it always asks me twice what my tunnel
broken is. It asks first during pre-configure and again during package
configuration.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.22.1 (PREEMPT)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash

Versions of packages aiccu depends on:
ii  debconf 1.5.14   Debian configuration management sy
ii  iproute 20070313-1   Professional tools to control the 
ii  iputils-ping3:20070202-2 Tools to test the reachability of 
ii  iputils-tracepath   3:20070202-2 Tools to trace the network path to
ii  libc6   2.6.1-5  GNU C Library: Shared libraries
ii  libgnutls13 2.0.1-1  the GNU TLS library - runtime libr
ii  lsb-base3.1-24   Linux Standard Base 3.1 init scrip

Versions of packages aiccu recommends:
ii  ntp 1:4.2.4p3+dfsg-1 Network Time Protocol daemon and u

-- debconf information:
* aiccu/username: ALI2-SIXXS
  aiccu/nobrokers:
  aiccu/notunnels:
  aiccu/badauth:
* aiccu/tunnelname: T11185
* aiccu/brokername: SixXS



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

Bug#445671: aiccu: When promping for configuration, select the current tunnal broker as default

[Andrew Lunn]

Package: aiccu
Version: 20070115-6
Severity: wishlist


It would be nice if during configuration of aiccu it set the default
tunnel broken to the currently configured setting. As you can see from
the debconf information it knows i use SixXs, so it would be better to
have that as the default instead of AARNet.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.22.1 (PREEMPT)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash

Versions of packages aiccu depends on:
ii  debconf 1.5.14   Debian configuration management sy
ii  iproute 20070313-1   Professional tools to control the 
ii  iputils-ping3:20070202-2 Tools to test the reachability of 
ii  iputils-tracepath   3:20070202-2 Tools to trace the network path to
ii  libc6   2.6.1-5  GNU C Library: Shared libraries
ii  libgnutls13 2.0.1-1  the GNU TLS library - runtime libr
ii  lsb-base3.1-24   Linux Standard Base 3.1 init scrip

Versions of packages aiccu recommends:
ii  ntp 1:4.2.4p3+dfsg-1 Network Time Protocol daemon and u

-- debconf information:
* aiccu/username: ALI2-SIXXS
  aiccu/nobrokers:
  aiccu/notunnels:
  aiccu/badauth:
* aiccu/tunnelname: T11185
* aiccu/brokername: SixXS



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

Bug#391714: tar: Man page: -l no longer means --one-file-system

[Andrew Lunn]

Package: tar
Version: 1.15.91-2
Severity: normal


The Debian man page for tar says:

   -l, --one-file-system
  stay in local file system when creating an archive

Since version 1.15.91 this is no longer true. The use of -l has been
dropped. See 
http://www.gnu.org/software/tar/manual/html_node/Option-Summary.html#fn-2

It might also be worth reading 
http://www.gnu.org/software/tar/manual/html_node/Changes.html#Changes

for other changes that have been made and might require the
man page is updated.

Andrew

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages tar depends on:
ii  libc62.3.6.ds1-5 GNU C Library: Shared libraries

tar recommends no packages.

-- no debconf information


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