headers
Greg Norris | 1 Nov 2006 01:16
Picon

Bug#395535: version 1:4.3p2-5.1 works for me

I just checked this using version 1:4.3p2-5.1 from sid, and it appears 
to be working as expected.

   adric <at> yggdrasil[~]$ tail -2 /etc/hosts.deny 
   ALL EXCEPT sshd: PARANOID
   sshd: 127.0.0.1

   adric <at> yggdrasil[~]$ ssh localhost
   ssh_exchange_identification: Connection closed by remote host

After removing the bottom line from /etc/hosts.deny, I'm able to logon 
normally.
Permalink | Reply | 4 comments |
headers
Eric Valette | 1 Nov 2006 01:07
Picon
Favicon

Bug#396482: installation-reports: S61mouse-support-x86 should use modprobe in the same way than other scripts (-q + || true)

Package: installation-reports
Severity: normal

Using this version of the script make this system boot with a kernel where all modules are built-in

if [ "$DEBIAN_FRONTEND" = gtk ] ; then
    modprobe -q evdev || true
    modprobe psmouse || true
fi

-- System Information:
Debian Release: 4.0
  APT prefers testing-proposed-updates
  APT policy: (500, 'testing-proposed-updates'), (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.19-rc3-git5
Locale: LANG=fr_FR <at> euro, LC_CTYPE=fr_FR <at> euro (charmap=ISO-8859-15)
Permalink | Reply | 0 comments |
headers
Hendrik Naumann | 1 Nov 2006 01:08
Picon
Picon

Bug#394684: libgphoto-2: privilege problem with PTP mode camera

Hi

Sorry for the delayed answer.

> Could you try 2.2.1-7; Fuji F30 was added in this version.

Yes with this version it works.

But it seems that the hotplug rules of libgphoto2 are better than the 
udev rules, because sarge can handle this camera. So any PTP camera 
released after etch will not work with etch but with sarge?

To my understanding the rule 

SYSFS{bInterfaceClass}=="06", SYSFS{bInterfaceSubClass}=="01",\ 
SYSFS{bInterfaceProtocol}=="01", MODE="0660", GROUP="camera"

should match. When I connect the camera

/sys/bus/usb/devices/1-8/1-8:1.0

contains bInterfaceClass, bInterfaceSubClass, bInterfaceProtocol with 
the correct entries.

So maybe this is an udev bug?

I experimented a bit and at least the rule

SYSFS{product}=="USB PTP Camera", MODE="0660", GROUP="camera"
(Continue reading)

Permalink | Reply | 5 comments |
headers
Clive Menzies | 1 Nov 2006 01:16
Picon

Bug#396483: d-i testing image 31Oct06 on amd64 failed on reboot

Package: installation-reports

Boot method: CD
Image version:
http://www.debian.org/devel/debian-installer/amd64/debian-testing-amd64-netinst.iso
Date: 23:15 (GMT) 31 0ct 06

Machine: Acer Aspire 1524WLMi
Processor: amd athlon 64 / 3400+
Memory:512Mb
Partitions:

Disk /dev/hda: 60.0 GB, 60011642880 bytes
255 heads, 63 sectors/track, 7296 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
   /dev/hda1               1         255     2048256   12  Compaq
   diagnostics
   /dev/hda2   *         256        1537    10297665    c  W95 FAT32
   (LBA)
   /dev/hda3            1538        7296    46259167+   f  W95 Ext'd
   (LBA)
   /dev/hda5            1538        2072     4297356    c  W95 FAT32
   (LBA)
   /dev/hda6            3648        4285     5124703+  8e  Linux LVM
   /dev/hda7            4286        4407      979933+  82  Linux swap /
   Solaris
   /dev/hda8            4408        6328    15430401   8e  Linux LVM
   /dev/hda9            6329        7296     7775428+  83  Linux
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marcel Dischinger | 1 Nov 2006 01:09
Picon

Bug#396398: kopete: Patch available

Package: kopete
Version: 4:3.5.5-1
Followup-For: Bug #396398

A patch to this is available in SVN commit 600778
(see original bug report at https://bugs.kde.org/show_bug.cgi?id=136566)

 M  +1 -0      client.cpp  

 ---
 branches/KDE/3.5/kdenetwork/kopete/protocols/oscar/liboscar/client.cpp
 #600777:600778
  at  at  -340,6 +340,7  at  at
  //we've finished logging in. start the services setup
  kdDebug(OSCAR_RAW_DEBUG) << k_funcinfo << "stage two done. setting
  up services" << endl;
  initializeStaticTasks();
+  d->ownStatusTask->go();
   ServiceSetupTask* ssTask = new ServiceSetupTask(
   d->connections.defaultConnection()->rootTask() );
   connect( ssTask, SIGNAL( finished() ), this, SLOT(
   serviceSetupFinished() ) );
   ssTask->go( true ); //fire and forget
Permalink | Reply | 0 comments |
headers
Steve Langasek | 1 Nov 2006 01:10
Picon
Favicon

Bug#379090: Still no news on 64bit i386 kernels

On Tue, Oct 31, 2006 at 02:01:22PM +0100, Frederik Schueler wrote:

> On Tue, Oct 31, 2006 at 01:30:59AM -0800, Steve Langasek wrote:
> > Can someone from the kernel team comment on whether there are problems with
> > this particular patch that have not yet been noted in the bug report?  If
> > there aren't any known objections, I could review the patch myself and look
> > at committing it.

> Adding amd64 as subarch to i386 would mean 3 additional flavors to
> build, raising the overall build-time of that package by 1.5-2h. 

Which doesn't sound like a blocker to me, FWIW.  Also, what about just
providing the "amd64" flavor for i386 without the xen/vserver flavors?  In
particular, I don't see any need for the xen flavor, wouldn't xen work just
fine with amd64 as the dom0 install and i386 in domX without any kernel
images installed in the domX?

> Additionally, I don't know in what state the current cross-build env for
> i386 is, and building 64bit kernels on i386 might produce
> abi-incompatible kernels causing even more problems.

As noted, it's not cross-building, this is treated as a native 64-bit build
by the compiler and the code path has been well-exercised by other packages.

> IMHO the best solution would be to repackage the amd64 debs into i386
> ones. This can be trivially done and should not cause any regressions.

> The "real" solution for this still is multiarch. I haven't heard much
> of it since a couple of months, is anyone still actively working on it?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Francesco Poli | 1 Nov 2006 01:13
Picon

Bug#383481: Must source code be easy to understand to fall under DFSG?

On Tue, 31 Oct 2006 20:50:19 +0100 Ola Lundqvist wrote:

> Hi Mathew
> 
> (Anyone on debian-legal: please note and maintain the Cc:s)

Again assuming that this means you and Matthew want to be Cc:ed as
well...

[...]
> > That's perfectly acceptable. Upstream can do whatever they want. 
> > However, if upstream do not provide the preferred form for
> > modification  (ie, the unobfuscated version), Debian can not
> > distribute it under the  terms of the GPL.
> 
> True. But do this mean that Nvidia have actually violated the license
> that they have released their software under? Well maybe not as they
> may not need to accept the license to actually use their rights...

A copyright holder cannot violate the license he/she releases his/her
work under: he/she needs *no* copyright license to deal with his/her own
work in any manner.
The only license violation that could possibly happen is on works
someone else holds copyright on.

Hence, nVidia could be in violation, *if* and *as long as* their work is
based on someone else's GPL'ed work.  I don't know if this is the case
here...

>
(Continue reading)

Permalink | Reply | 0 comments |
headers
José Alburquerque | 1 Nov 2006 01:05
Picon
Favicon

Bug#396481: nautilus-cd-burner's context menu does not include a "Blank Disc" selection

Package: nautilus-cd-burner
Version: 2.14.3-2
Severity: wishlist

nautilus-cd-burner is so excellently integrated into the nautilus
desktop that I barely need any other application for CD/DVD burning.
When blank disks are inserted it recognizes this and shows a dialog that
allows for creation of new Data/Audio CD's and Data/Audio DVD's.

The really nice thing about nautilus-cd-burner is that it shows a nice
icon on the desktop depicting the type of media that the disc in the
drive is.

The context menu includes a "Copy Disc" selection, but, though
nautilus-cd-burner is already sensitive to RW media, it'd be nice to
include a "Blank Disc" selection in the context menu for a quick
blanking of discs that are blanked to be used on other computers.  

Just a nice little add-on (wish) that would make this application even
better; wont make a difference if it's not achieved.

-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-1-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
(Continue reading)

Permalink | Reply | 2 comments |
headers
Andrew McNamara | 1 Nov 2006 01:00
Picon
Favicon

Bug#393889: libapache2-mod-fastcgi uninstallable in sid due to apache2 conflict

On Wed 18 Oct 2006, Tatsuki Sugiura said:
>I'll upload new version soon, please wait...

Waiting... 8-)

--

-- 
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/
Permalink | Reply | 0 comments |
headers
Otavio Salvador | 1 Nov 2006 01:32
Picon
Favicon
Gravatar

Bug#379090: Still no news on 64bit i386 kernels

Steve Langasek <vorlon <at> debian.org> writes:

> On Tue, Oct 31, 2006 at 02:01:22PM +0100, Frederik Schueler wrote:
[...]
>> Adding amd64 as subarch to i386 would mean 3 additional flavors to
>> build, raising the overall build-time of that package by 1.5-2h. 
>
> Which doesn't sound like a blocker to me, FWIW.  Also, what about just
> providing the "amd64" flavor for i386 without the xen/vserver flavors?  In
> particular, I don't see any need for the xen flavor, wouldn't xen work just
> fine with amd64 as the dom0 install and i386 in domX without any kernel
> images installed in the domX?

Yes. It can. I use it exactly this way here.

--

-- 
        O T A V I O    S A L V A D O R
---------------------------------------------
 E-mail: otavio <at> debian.org      UIN: 5906116
 GNU/Linux User: 239058     GPG ID: 49A5F855
 Home Page: http://www.freedom.ind.br/otavio
---------------------------------------------
"Microsoft gives you Windows ... Linux gives
 you the whole house."
Permalink | Reply | 0 comments |

Gmane