Bug#1008541: vagrant: Cant create boxes running ssh 8.8

[Rtp]

Package: vagrant
Severity: normal

Dear Maintainer,


It's not possible to start a VM on bullseye with this Vagrantfile:

Vagrant.configure("2") do |config|
  config.vm.box = "generic/alpine315"
end

It's stuck while trying the use SSH. generic/alpine310 is fine for instance.
After debugging, it turns out that it's due to ssh 8.8 running inside the guest.

It has been:
- fixed in ruby net-ssh:
  
https://github.com/net-ssh/net-ssh/commit/a45f54fe1de434605af0b7195dd9a91bccd2cec5
- workarounded in vagrant with lib/vagrant/patches/net-ssh.rb

Doing a quick backport of sid vagrant seems to fix the issue.

I'm not sure which package should be fixed (rubygem-net-ssh or vagrant)
so bugging against vagrant since it's this package not working.

Thanks,
Arnaud

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

Kernel: Linux 5.10.0-12-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#975643: grub-pc: Allow to set option on grub entries

[Rtp]

Package: grub-pc
Version: 2.04-10
Severity: normal

Dear Maintainer,


I'm using grub with a password set in /etc/grub.d/40_custom:
#!/bin/sh
exec tail -n +3 $0
set superusers="admin"
password_pbkdf2 admin grub.pbkdf2.sha512.

With this setup, I would have to enter the grub password to boot, so
I've been modifying /etc/grub.d/10_linux by hand to hardcode the option
'--unrestricted' in the default entry for quite some time.

I think it would be better for the long term to get a solution for that
in the grub package.

So, I've just made a patch to allow setting an option in /etc/default/grub
to allow setting options to grub entries. There's one option for the
default entry and one option for the others, as I guess setting the
option per entry for all entry would be quite hard.

Thanks,
Arnaud


./util/grub.d/10_linux.in: Allow to set menuentry options

Users restricting access according to
https://www.gnu.org/software/grub/manual/grub/html_node/Authentication-and-authorisation.html
may want to set options like '--users' or '--unrestricted'. While this code doesn't allow
to set the options per menuentry, it allows to set the options only for the 'simple' entry
and for all others.
The new variables will be called GRUB_SIMPLE_MENUENTRY_OPTS and GRUB_MENUENTRY_OPTS.

Signed-off-by: Arnaud Patard 

Index: grub2-2.04/util/grub-mkconfig.in
===
--- grub2-2.04.orig/util/grub-mkconfig.in
+++ grub2-2.04/util/grub-mkconfig.in
@@ -249,7 +249,9 @@ export GRUB_DEFAULT \
   GRUB_OS_PROBER_SKIP_LIST \
   GRUB_DISABLE_SUBMENU \
   GRUB_RECORDFAIL_TIMEOUT \
-  GRUB_RECOVERY_TITLE
+  GRUB_RECOVERY_TITLE \
+  GRUB_SIMPLE_MENUENTRY_OPTS \
+  GRUB_MENUENTRY_OPTS
 
 if test "x${grub_cfg}" != "x"; then
   rm -f "${grub_cfg}.new"
Index: grub2-2.04/util/grub.d/10_linux.in
===
--- grub2-2.04.orig/util/grub.d/10_linux.in
+++ grub2-2.04/util/grub.d/10_linux.in
@@ -139,9 +139,9 @@ linux_entry ()
 	  title_correction_code="${title_correction_code}if [ \"x\$default\" = '$quoted' ]; then default='$(echo "$replacement_title" | grub_quote)'; fi;"
 	  grub_warn "$(gettext_printf "Please don't use old title \`%s' for GRUB_DEFAULT, use \`%s' (for versions before 2.00) or \`%s' (for 2.00 or later)" "$GRUB_ACTUAL_DEFAULT" "$replacement_title" "gnulinux-advanced-$boot_device_id>gnulinux-$version-$type-$boot_device_id")"
   fi
-  echo "menuentry '$(echo "$title" | grub_quote)' ${CLASS} \$menuentry_id_option 'gnulinux-$version-$type-$boot_device_id' {" | sed "s/^/$submenu_indentation/"
+  echo "menuentry '$(echo "$title" | grub_quote)' ${CLASS} ${GRUB_MENUENTRY_OPTS} \$menuentry_id_option 'gnulinux-$version-$type-$boot_device_id' {" | sed "s/^/$submenu_indentation/"
   else
-  echo "menuentry '$(echo "$os" | grub_quote)' ${CLASS} \$menuentry_id_option 'gnulinux-simple-$boot_device_id' {" | sed "s/^/$submenu_indentation/"
+  echo "menuentry '$(echo "$os" | grub_quote)' ${CLASS} ${GRUB_SIMPLE_MENUENTRY_OPTS} \$menuentry_id_option 'gnulinux-simple-$boot_device_id' {" | sed "s/^/$submenu_indentation/"
   fi  
   if [ "$quick_boot" = 1 ]; then
   echo "	recordfail" | sed "s/^/$submenu_indentation/"

Bug#908712: Still present in stable

[Rtp]

Martin Michlmayr  writes:

> * Salvatore Bonaccorso  [2020-05-08 07:30]:
>> I have looked up the stable list but did not found any followup
>> specific with the 4.19 backport.
>> 
>> Might it be worth doing one last timme a request explicitly for a
>> backport to 4.19 including your patch, sending it to stable list, and
>> as required Cc'ed again to Andrew Lunn, Dave and the netdev list and
>> other required people?
>
> Arnaud, did you see Salvatore's request?

No, I've missed it. Sorry. I've just sent the patch again.

Arnaud

Bug#908712: Still present in stable

[Rtp]

Martin Michlmayr  writes:

> The fix got accepted upstream a long time ago and made it into
> unstable.
>
> Unfortunately, even though Arnaud submitted it to the -stable tree and
> even though maintainer Andrew Lunn acked it, it never made it into
> the 4.19 stable series (despite several pings from Arnaud).
>
> Can we just add the patch to the Debian kernel in buster.  Without
> this path, all Orion-based QNAP fail to boot.  (Technically, they
> boot, but without Ethernet, which is how 99% of users access the
> device.)
>
> Arnaud, can you send the 4.19 patch you prepared?

I've attached to this mail the version I sent for 4.19.

Arnaud

[patch 4.19] drivers/net/ethernet/marvell/mvmdio.c: Fix non OF case

commit d934423ac26ed373dfe089734d505dca5ff679b6 upstream.

Orion5.x systems are still using machine files and not device-tree.
Commit 96cb4342382290c9 ("net: mvmdio: allow up to three clocks to be
specified for orion-mdio") has replaced devm_clk_get() with of_clk_get(),
leading to a oops at boot and not working network, as reported in
https://lists.debian.org/debian-arm/2019/07/msg00088.html and possibly in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908712.

Link: https://lists.debian.org/debian-arm/2019/07/msg00088.html
Fixes: 96cb4342382290c9 ("net: mvmdio: allow up to three clocks to be specified for orion-mdio")
Signed-off-by: Arnaud Patard 
Reviewed-by: Andrew Lunn 
Signed-off-by: David S. Miller 

Index: linux/drivers/net/ethernet/marvell/mvmdio.c
===
--- linux.orig/drivers/net/ethernet/marvell/mvmdio.c
+++ linux/drivers/net/ethernet/marvell/mvmdio.c
@@ -319,15 +319,25 @@ static int orion_mdio_probe(struct platf
 
 	init_waitqueue_head(>smi_busy_wait);
 
-	for (i = 0; i < ARRAY_SIZE(dev->clk); i++) {
-		dev->clk[i] = of_clk_get(pdev->dev.of_node, i);
-		if (PTR_ERR(dev->clk[i]) == -EPROBE_DEFER) {
+	if (pdev->dev.of_node) {
+		for (i = 0; i < ARRAY_SIZE(dev->clk); i++) {
+			dev->clk[i] = of_clk_get(pdev->dev.of_node, i);
+			if (PTR_ERR(dev->clk[i]) == -EPROBE_DEFER) {
+ret = -EPROBE_DEFER;
+goto out_clk;
+			}
+			if (IS_ERR(dev->clk[i]))
+break;
+			clk_prepare_enable(dev->clk[i]);
+		}
+	} else {
+		dev->clk[0] = clk_get(>dev, NULL);
+		if (PTR_ERR(dev->clk[0]) == -EPROBE_DEFER) {
 			ret = -EPROBE_DEFER;
 			goto out_clk;
 		}
-		if (IS_ERR(dev->clk[i]))
-			break;
-		clk_prepare_enable(dev->clk[i]);
+		if (!IS_ERR(dev->clk[0]))
+			clk_prepare_enable(dev->clk[0]);
 	}
 
 	dev->err_interrupt = platform_get_irq(pdev, 0);

Bug#953556: equivs: equivs-build --full is broken

[Rtp]

Package: equivs
Severity: normal

Dear Maintainer,

When trying to build with a package with the --full option, the build
fails:
$ equivs-control test
$ sed -i test -e 's!Package:.*!Package: test!'
$ LC_ALL=C equivs-build --full test
dpkg-buildpackage: info: source package test
dpkg-buildpackage: info: source version 1.0
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Arnaud Patard 

dpkg-buildpackage: info: host architecture amd64
 dpkg-source --before-build .
  fakeroot debian/rules clean
  dh_testdir
  dh_clean
   dpkg-source -b .
   dpkg-source: error: can't build with source format '3.0 (quilt)': no 
upstream tarball found at ../test_1.0.orig.tar.{bz2,gz,lzma,xz}
   dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status 
255
   Error in the build process: exit status 255
   
The issue is that /usr/share/equivs/template/debian/source/format is
wrong:
$ cat /usr/share/equivs/template/debian/source/format
3.0 (quilt)

As mentionned by the package version and from what I understand of
equivs way of working, it's a native package (no dash in the version),
which means that the file content has to be "3.0 (native)".

If a non-native package is really wanted, equivs should use a version like
1.0-1 and has to provide a tarball.

Thanks,

-- System Information:
Debian Release: 9.6
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-8-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#908712: Kernel quirks on QNAP TS-109 (Marvell orion)

[Rtp]

Hi,

Martin Michlmayr  writes:

> * Arnaud Patard  [2019-07-29 14:45]:
>> As promised, please fix the updated patch. Please note that there are 2
>
> Can you submit it upstream for review, or if you have already, send us
> a link.

Sorry for the delay. I was waiting for some feedback before sending and
then got busy with other stuff. I've now sent it:
https://marc.info/?l=linux-netdev=156473570707976=2.

Arnaud

Bug#908712: Kernel quirks on QNAP TS-109 (Marvell orion)

[Rtp]

Matthieu CERDA  writes:

[ Adding bug #908712 in Cc: ]

> Hello again !
>
> Le 26/07/2019 à 22:36, Matthieu CERDA a écrit :
>> Le 26/07/2019 à 11:29, Arnaud Patard (Rtp) a écrit :
>>> Martin Michlmayr  writes:
>>>> * Matthieu CERDA  [2019-07-26 00:17]:
>>>>>   * On stretch stock kernel (4.9.0-9-marvell), qcontrol does not work:
>>>>> calling it with "qcontrol --direct buzzer" outputs no error, but
>>>>> does nothing, and the status led stays red/green after system has
>>>>> booted.
>>>> There are different potential causes for this but I think I've seen
>>>> this before myself and this particular issue hasn't been reported.
>> I'll open a bug report on the Debian package to discuss the issue there.
> Done: https://bugs.debian.org/cgi-bin/pkgreport.cgi?package=qcontrol
>>>>>   * On stretch backports kernel (4.19.0-0.bpo.5-marvell), qcontrol does
>>>>> not work as well, and more annoyingly, no Ethernet interface gets
>>>>> initialized. dmesg shows a kernel oops. (copy attached)
>>>> This sounds like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908712
>> Yep, I looks like the exact same issue. I'll be happy to help if I can,
>> at least by testing the fix that Arnaud proposed below :)
>>> As noted in the bug, might worth reporting to Andrew. iirc ts109 are
>>> devices without device tree and I'm curious to see how the kernel handle
>>> things like of_clk_get(pdev->dev.of_node, i) on a system without DT.
>>> of_clk_get() is coded like this:
>>> (...)
>>>
>>> Arnaud.
>> All right, I'll try to build a 4.19.0-0.bpo.5-marvell-based kernel with
>> the patch.
>>
>> I will also try building a linux master-based kernel, to test if
>> https://github.com/torvalds/linux/commit/433a06d7d74e677c40b1148c70c48677ff62fb6b
>> solves the issue.
>>
>> Thank you for the help to both of you :) (and also, thank you Martin for
>> the highly detailed website and instructions about QNAP devices)
>
> Well, good news. the fix Arnaud proposed seems to work! (cf patch joined
> to this mail)
>
> ---8<---
> [   35.281494] mv643xx_eth: MV-643xx 10/100/1000 ethernet driver version 1.4
> [   35.348374] libphy: PHY orion-mdio-mii:08 not found
> [   35.696124] libphy: PHY orion-mdio-mii:08 not found
> (...)
> [   35.780513] libphy: orion_mdio_bus: probed
> (...)
> [   35.998946] mv643xx_eth_port mv643xx_eth_port.0 eth0: port 0 with MAC
> address 00:08:9b:ac:e2:f4
> (...)
> [   46.105299] mv643xx_eth_port mv643xx_eth_port.0 eth0: link down
> [   49.537051] mv643xx_eth_port mv643xx_eth_port.0 eth0: link up, 1000
> Mb/s, full duplex, flow control enabled
> ---8<---
>
> I'll send a copy to Andrew, if that's okay with you Arnaud ?

As promised, please fix the updated patch. Please note that there are 2
patches, one for linux HEAD and one for 4.19. I had to make two patches
as there are changes in HEAD not present in 4.19. btw, your version of
the 4.19 patch is possibly broken with OF platforms, that's why your
patches and mine are different. For your case on orion5x, it should not
make any difference.


Arnaud
drivers/net/ethernet/marvell/mvmdio.c: Fix non OF case

Orion5.x systems are still using machine files and not device-tree.
Commit 96cb4342382290c9 ("net: mvmdio: allow up to three clocks to be
specified for orion-mdio") has replaced devm_clk_get() with of_clk_get(),
leading to a oops at boot and not working network, as reported in 
https://lists.debian.org/debian-arm/2019/07/msg00088.html and possibly in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908712.

Link: https://lists.debian.org/debian-arm/2019/07/msg00088.html
Fixes: 96cb4342382290c9 ("net: mvmdio: allow up to three clocks to be specified for orion-mdio")
Signed-off-by: Arnaud Patard 
Index: linux-next/drivers/net/ethernet/marvell/mvmdio.c
===
--- linux-next.orig/drivers/net/ethernet/marvell/mvmdio.c
+++ linux-next/drivers/net/ethernet/marvell/mvmdio.c
@@ -319,20 +319,33 @@ static int orion_mdio_probe(struct platf
 
 	init_waitqueue_head(>smi_busy_wait);
 
-	for (i = 0; i < ARRAY_SIZE(dev->clk); i++) {
-		dev->clk[i] = of_clk_get(pdev->dev.of_node, i);
-		if (PTR_ERR(dev->clk[i]) == -EPROBE_DEFER) {
+	if (pdev->dev.of_node) {
+		for (i = 0; i < ARRAY_SIZE(dev->clk); i++) {
+			dev->clk[i] = of_clk_get(pdev->dev.of_node, i);
+			if (PTR_ERR(dev->clk[i]) == -EPROBE_DEFER) {
+ret = -EPROBE_DEFER;
+goto out_clk;
+			}
+			if (IS_ERR(dev->clk[i]))
+break;
+			clk_prepare_enable(dev->clk[i]);
+		}
+
+		if (!IS_ERR(of_clk_get(pdev->

Bug#918783: ansible-lint: Update to newer release

[Rtp]

Package: ansible-lint
Severity: wishlist

Dear Maintainer,

The current package is quite outdated, so it would be nice to get a
newer version, as there has been quite a lot of upstream activity theses
days.

Please note that ansible-lint is now maintained by Ansible, as
mentionned in upstream commit :
https://github.com/ansible/ansible-lint/commit/4d5774ae3eac47fca485eb44fdd2d8ba933e2129

Thanks,

-- System Information:
Debian Release: 9.6
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-8-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#910288: libnss-libvirt: Please provide libnss_libvirt_guest

[Rtp]

Package: libnss-libvirt
Severity: normal

Dear Maintainer,

Since libvirt 3.0.0, there's an alternative to libnss_libvirt which is
libnss_libvirt_guest. It allows to get name resolution according to the
libvirt domain names, instead of relying to dnsmasq leases when using
libnss_libvirt.

It's already built but it's not installed anywhere, so at least, the
debian/rules is missing something like:

dh_install -p libnss-libvirt usr/lib/libnss_libvirt_guest.so.2 
lib/$(DEB_HOST_MULTIARCH)/

Of course, more work is needed if one wants to put it into a different
package than libnss-libvirt.

Thanks,


-- System Information:
Debian Release: 9.5
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-8-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#853894: similar issue with hauppauge WinTV nova-t-usb2

[Rtp]

Dominique Dumont  writes:

Hi,

> Hello
>
> I have a similar issue with Hauppauge WinTV-NOVA-T usb2 (note the wrong 
> Manufacturer shown in the traces):
>
> févr. 26 12:33:23 gandalf kernel: usb 7-2: new high-speed USB device number 2 
> using ehci-pci
> févr. 26 12:33:23 gandalf kernel: usb 7-2: New USB device found, 
> idVendor=2040, idProduct=9300
> févr. 26 12:33:23 gandalf kernel: usb 7-2: New USB device strings: Mfr=1, 
> Product=2, SerialNumber=3
> févr. 26 12:33:23 gandalf kernel: usb 7-2: Product: SOHO-FX2
> févr. 26 12:33:23 gandalf kernel: usb 7-2: Manufacturer: Hauppau⁧攀 
> févr. 26 12:33:23 gandalf kernel: usb 7-2: SerialNumber: 9301-00-F008B260
> févr. 26 12:33:23 gandalf kernel: dvb-usb: found a 'Hauppauge WinTV-NOVA-T 
> usb2' in cold state, will try to load a firmware
> févr. 26 12:33:23 gandalf kernel: usb 7-2: firmware: direct-loading firmware 
> dvb-usb-nova-t-usb2-02.fw

I can't find my nova-t usb2 but from what I remember theses strings are
fine. Nothing wrong there.

> févr. 26 12:33:23 gandalf kernel: [ cut here ]
> févr. 26 12:33:23 gandalf kernel: WARNING: CPU: 1 PID: 2590 at
> /build/linux-FoK828/linux-4.9.10/drivers/usb/core/hcd.c:1584
> usb_hcd_map_urb_for_dma+0x37c/0x570 [usbcore]
> févr. 26 12:33:23 gandalf kernel: transfer buffer not dma capable
> févr. 26 12:33:23 gandalf kernel: Modules linked in:
> dvb_usb_nova_t_usb2(+) dvb_usb_dibusb_mc_common dvb_usb_dibusb_common
> dib3000mc dibx000_common dvb_usb dvb_core rc_core bnep xt_multiport
> uinput snd_hrtimer cpufreq_userspace cpufreq_conservative
> cpufreq_powersave ip6table_filter ip6_tables iptable_filter bluetooth
> rfkill binfmt_misc amdkfd edac_mce_amd evdev radeon edac_core kvm_amd
> kvm irqbypass snd_hda_codec_via snd_hda_codec_generic cdc_ether pcspkr
> ttm serio_raw snd_hda_codec_hdmi k10temp usbnet snd_hda_intel
> drm_kms_helper snd_seq_midi snd_hda_codec snd_seq_midi_event
> snd_rawmidi drm snd_seq snd_hda_core snd_seq_device sp5100_tco
> snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm sg snd_timer i2c_algo_bit
> snd soundcore asus_atk0110 button shpchp loop wmi acpi_cpufreq tpm_tis
> tpm_tis_core tpm sunrpc parport_pc ppdev lp
> févr. 26 12:33:23 gandalf kernel: parport ip_tables x_tables autofs4
> ext4 crc16 jbd2 crc32c_generic fscrypto ecb glue_helper lrw gf128mul
> ablk_helper cryptd aes_x86_64 mbcache hid_generic usbhid hid sr_mod
> cdrom sd_mod ata_generic uas usb_storage ohci_pci firewire_ohci ahci
> pata_atiixp libahci firewire_core uhci_hcd xhci_pci crc_itu_t ehci_pci
> xhci_hcd ohci_hcd ehci_hcd libata i2c_piix4 scsi_mod psmouse usbcore
> r8169 mii usb_common fjes
> févr. 26 12:33:23 gandalf kernel: CPU: 1 PID: 2590 Comm: systemd-udevd Not 
> tainted 4.9.0-2-amd64 #1 Debian 4.9.10-1
> févr. 26 12:33:23 gandalf kernel: Hardware name: System manufacturer System 
> Product Name/M4A785TD-V EVO, BIOS 021107/08/2009
> févr. 26 12:33:23 gandalf kernel:   8c929304 
> afc77738 
> févr. 26 12:33:23 gandalf kernel:  8c676e1e 9bdcad786180 
> afc77790 
> févr. 26 12:33:23 gandalf kernel:  afc77944 9bdccc44e000 
> 0001 8c676e9f
> févr. 26 12:33:23 gandalf kernel: Call Trace:
> févr. 26 12:33:23 gandalf kernel:  [] ? dump_stack+0x5c/0x78
> févr. 26 12:33:23 gandalf kernel:  [] ? __warn+0xbe/0xe0
> févr. 26 12:33:23 gandalf kernel:  [] ? 
> warn_slowpath_fmt+0x5f/0x80
> févr. 26 12:33:23 gandalf kernel:  [] ? 
> usb_hcd_map_urb_for_dma+0x37c/0x570 [usbcore]
> févr. 26 12:33:23 gandalf kernel:  [] ? 
> usb_hcd_submit_urb+0x330/0xaa0 [usbcore]

>From a very quick search, I guess it's fixed by
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=43fab9793c1f44e665b4f98035a14942edf03ddc.

As said, I can't find my device so can't test that it's fixing the issue.

[...]
>
> On the other hand, a WinTV MiniStick loads fine (but does not work with 
> kaffeine or vdr):

The issue is in the dvb-usb stuff and the WinTV MiniStick doesn't use
it from what I can see.

Arnaud

Bug#837989: openocd: can no longer use SheevaPlug JTAGKey FT2232D (regression)

[Rtp]

Hi,

Wanted to try a new uboot on my guruplug server with openocd
0.9.0-1+b1 and my SheevaPlug JTAGKey FT2232D device. I got very similar
bug.
I've modified the
/usr/share/openocd/scripts/interface/ftdi/sheevaplug.cfg file to use
ftdi_channel 0 and not 1. With that change, I was able to use openocd,
keep the serial console open and flash a new uboot.

I guess it would be interesting that others people having the problem
confirm it's working for them too.

Arnaud

Bug#818598: src:linux: MTD device probe failed after migrating kernel variant from -orion5x to -marvell

[Rtp]

Roger Shimizu  writes:

Hi,

> Dear Ian, Martin,
>
> May I know your comment regarding to this armel/orion5x related bug?
> I don't know whether qnap also uses MTD to store u-boot related stuff
> or not. Just guessing it may have the same issue.

>From a quick look at your logs, your mtd device is needing support for
cmdset 2, provided by cfi_cmdset_0002.ko (CONFIG_MTD_CFI_AMDSTD). Maybe
it's not available when the mtd chip is probed ?
Eg missing in the initrd or should be built-in or something like that ?

Arnaud

Bug#810894: src:linux: GPIO probe failure on Linkstation LS-WXL/WSXL

[Rtp]

Roger Shimizu  writes:

Hi,

> Dear Uwe,
>
> On Thu, Jan 14, 2016 at 11:08 PM, Uwe Kleine-König
>  wrote:
> I need to run the following command to enable USB port on Linkstation
> LS-WXL/WSXL (armel/kirkwood with DTS [0] ):
>   echo 37 >/sys/class/gpio/export
>   echo out > /sys/class/gpio/gpio37/direction
>   echo 1 > /sys/class/gpio/gpio37/value
>>
>> Can you post the contents of /sys/kernel/debug/gpio when the broken
>> kernel is running?
>
> Thanks for the debugging tool!
> It seems there's clue ...
>
> Here's the log for working & non-working kernel:
>
> # uname -a
> Linux LS-WXL 4.2.0-0.bpo.1-kirkwood #1 Debian 4.2.6-3~bpo8+2
> (2015-12-14) armv5tel GNU/Linux
> # mount -t debugfs none /sys/kernel/debug
> # cat  /sys/kernel/debug/gpio
> GPIOs 0-31, platform/f1010100.gpio, f1010100.gpio:
>  gpio-28  (HDD0 Power  ) out hi
>  gpio-29  (HDD1 Power  ) out hi
>
> GPIOs 32-49, platform/f1010140.gpio, f1010140.gpio:
>  gpio-34  (?   ) out hi
>  gpio-35  (?   ) out hi
>  gpio-37  (?   ) out lo
>  gpio-38  (?   ) out hi
>  gpio-40  (?   ) out hi
>
> # uname -a
> Linux LS-WXL 3.16.0-4-kirkwood #1 Debian 3.16.7-ckt7-1 (2015-03-01)
> armv5tel GNU/Linux
> # mount -t debugfs none /sys/kernel/debug
> # cat  /sys/kernel/debug/gpio
> GPIOs 0-31, platform/f1010100.gpio, f1010100.gpio:
>  gpio-28  (HDD0 Power  ) out hi
>  gpio-29  (HDD1 Power  ) out hi
>
> GPIOs 32-49, platform/f1010140.gpio, f1010140.gpio:
>  gpio-34  (lswxl:red:hdderr0   ) out hi
>  gpio-35  (lswxl:red:hdderr1   ) out hi
>  gpio-37  (lswxl:red:func  ) out lo
>  gpio-38  (lswxl:amber:info) out hi
>  gpio-40  (lswxl:blue:power) out hi

>From a quick look, dts looks broken, if gpio 37 is not for the led:
   label = "lswxl:red:func";
   gpios = < 5 GPIO_ACTIVE_LOW>;


btw, this is broken too:
   usb_power: regulator@1 {
...
   gpio = < 37 GPIO_ACTIVE_HIGH>;

There's no such a thing as gpio 37 on bank 0 as kirkwood bank have 32
gpios. I'm supprised nobody ever noticed it. Change it to "gpio1 5" and
there are chances that export won't be needed anymore.

imho, you should double check all the gpios entries in your dts.

Arnaud

Bug#740219: FTBFS on armel: modules in more than one package

[Rtp]

Ian Campbell i...@hellion.org.uk writes:

 On Thu, 2014-02-27 at 03:07 +, Wookey wrote:

 End of the build log at:
 https://buildd.debian.org/status/fetch.php?pkg=linuxarch=armelver=3.13.4-1stamp=1393291598

 some modules are in more than one package
 debian/jffs2-modules-3.13-1-orion5x-di 
 lib/modules/3.13-1-orion5x/kernel/lib/lzo/lzo_compress.ko
 debian/btrfs-modules-3.13-1-orion5x-di 
 lib/modules/3.13-1-orion5x/kernel/lib/lzo/lzo_compress.ko

 Looks like lzo_compress became a module again, so we should (partially?)
 revert r18646. Looking at the log I only see it built as a module, so I
 think entirely revert is probably the answer.

iirc Ben has already committed a fix for that some days ago so I'm not
sure that this needs to be discussed further.

Arnaud


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

Bug#703209: linux: Please Add multiplatform flavour to armhf

[Rtp]

Ben Hutchings b...@decadent.org.uk writes:

Hi,

 On Mon, 2013-03-18 at 08:41 +0900, Nobuhiro Iwamatsu wrote:
 Hi,
 
 Thank you for your comment.
 
 On Sun, Mar 17, 2013 at 10:23 AM, Ben Hutchings b...@decadent.org.uk wrote:
  On Sun, 2013-03-17 at 08:35 +0900, Nobuhiro Iwamatsu wrote:
  Package: linux
  Version: 3.8.2-1~experimental.1
  Severity: wishlist
  Tags: patch
 
  Hi,
 
  From linux 3.8, support of armada 370/xp was added in arm.
  This is classified into the armhf architecture of debian.
  First I began and thought that an armada flavor would be added.
  When I consulted about this in debian-arm ML, I got advice from
  several developers what multiplatform flavour was better than
  armada flavour[0].
 
  Since arm is developed toward multiplatform from now on,
  I think that multiplatform is desirable.
  Although there is still little SoC which is supporting
  multiplatform, I would like to support armada 370/xp
  (mach-mvebu) first.
 
  I created the patch which supports this.
  Please check and apply.
 
  In future all ARM kernels should be multi-platform, but I expect there
  will still be different flavours, such as for LPAE or the RT featureset.
  I would much prefer a name that will provide a more useful distinction
  in future (and not be too long!).  Perhaps it should refer to the CPU
  requirement like the flavours for some other architectures.
 
 I see. Although it is very simple, how is armmp?

armmp is imho confusing. There are some Marvell platforms called MMP.

 [...]

 Sounds alright to be, but let's allow the other ARM porters a few more
 days to comment.

I already commented some days ago on debian-arm that currently
multiplatform support must wait. It is useless as usb support is
_broken_ on multiplatform. Hopefully, Linaro devs seem back to work
and looks like we may have a patch merged soon. Until then, doing more
is near to a waste of time.

And about the patch in this bug, it fails to be really
multiplatform. During my tests on 3.8, I could already enable platforms
like MVEBU, HIGHBANK, BCM, MXC and you can enable OMAP too with 2-3
backports. Once done, it needs to be tested on real platforms as it
would probably allow to detect some more bugs. 3.9 may be better.

On the long term, we'll have also to consider if we should keep
omap/mx5/vexpress or not. If we remove them, we should make sure that
the transition will work nicely.


Arnaud


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

Bug#648325: Fwd: Bug#648325: dreamplug breakage

[Rtp]

luke.leighton luke.leigh...@gmail.com writes:

 ok thanks marco.  does anyone know what this is referring to?  would
 it be the accept4 syscall as shown in dmitri's patch:
 http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=68;filename=udev-182.patch;att=2;bug=648325

according to git accept4 has been added into 2.6.36 and according to the
squeeze changelog, it has been added into the 2.6.32-35 kernel.


 this is a long-standing issue, it would be good to have it sorted out.

If you're running debian kernels (the 3.2 from wheezy or any kernel
newer than 2.6.32-35 on squeeze), it should already be fine. If you're
running any other kernel, I don't see how it can be handled. At least
disabling the accept4 syscall for every kernels doesn't seem a good
idea.

  i had to track down a suitable replacement kernel plus the
 installation instructions, of course it's not a kernel from debian,
 and the recommended one of course wifi didn't work.  i ended up here:
 http://www.spinifex.com.au/plugs/dphowtowificl.html

off-topic (it's not related to udev): if the wifi is not working, please
check if it's working with newer kernels and if not, please report to
libertas devs so that they can try to fix it, otherwise it's never going
to be fixed.

Arnaud


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

Bug#695575: ITP: waagent -- Windows Azure Linux Agent

[Rtp]

Package: wnpp
Owner: Arnaud Patard (Rtp) arnaud.pat...@rtp-net.org
Severity: wishlist
X-Debbugs-CC: debian-cl...@lists.debian.org

* Package name: waagent
  Version : 1.2

* URL : https://github.com/Windows-Azure/WALinuxAgent/
* License : Apache 2.0
  Description : Windows Azure Linux Agent

 The Windows Azure Linux Agent (waagent) manages VM interaction with the
 Windows Azure Fabric Controller.


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

Bug#680699: unblock: flash-kernel/3.1

[Rtp]

Philipp Kern pk...@debian.org writes:

 Hi,

 On Sun, Jul 08, 2012 at 03:16:41AM +0200, Hector Oron wrote:
 Please unblock package flash-kernel
 
 Hello,
 
   flash-kernel/3.1 adds device tree support for Dreamplug device (used by
   freedombox).
 
   Dreamplug support has been backported into linux/3.2.21-1, which we expect
   it to get into wheezy sometime.
 
   Therefore, it would be really nice if we can get flash-kernel/3.1 in 
 wheezy.
 
 unblock flash-kernel/3.1

 my only concern is that /proc/device-tree/model takes precedence over
 /proc/cpuinfo in any case with no fallback to the latter. So if any ARM SoC
 gets device-tree enabled by a backport it might potentially need a change to
 flash-kernel, if the Hardware string does not match up with what the model
 file delivers.

no. With DT, the Hardware string doesn't change with the model but with
the SoC. For instance, all kirkwood systems booting with DT have :

Hardware: Marvell Kirkwood (Flattened Device Tree)

[ defined in arch/arm/mach-kirkwood/board-dt.c ]

Then, the model is found in /proc/device-tree/model and I don't think
that things in /proc are changing a lot.


Arnaud



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

Bug#675922: [armel] please support dreamplug platform

[Rtp]

Ian Campbell i...@hellion.org.uk writes:

Hi,

 Package: src:linux-2.6
 Version: 3.2.19-1
 Severity: wishlist

 This has been discussed on debian-kernel:
 http://lists.debian.org/debian-kernel/2012/03/msg6.html
 http://lists.debian.org/debian-kernel/2012/06/msg00120.html

 I posted the backport of the relevant patches at:
 http://lists.debian.org/debian-kernel/2012/04/msg00246.html

 I also have a local pkg-kernel git-svn branch pending with the changes
 but it needs a bit of rebasing over the recent linux-2.6-linux and
 series file changes.

 We also likely want to include DTB files in the linux-image packages for
 armel, something like:
 http://lists.debian.org/debian-kernel/2012/04/msg00571.html

I've made a deb with the patches you've listed so it has dreamplug DT
support (I've even added iconnect). You'll find it here:
http://www.rtp-net.org/kirkwood/linux-image-3.2.0-2-kirkwood_3.2.20-2_armel.deb

Can you please test it ?

Thanks,
Arnaud



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

Bug#673107: dependency error

[Rtp]

Damien Martins doc...@makelofine.org writes:

 Hi,

Hi,

 I'm the one who posted this problem on QNAP's forum. I got your debian
 package and I thank you for this.
 When doing a 'dpkg -i 
 linux-image-2.6.32-5-orion5x_2.6.6~bug673107_armel.deb'
 I got the following error :
 linux-image-2.6.32-5-orion5x depends on linux-base (=
 2.6.32-46~bug673107); however:
   Version of linux-base on system is 2.6.32-45

 As I'm not sure of side effects if I add --force-depends, I'd like a
 feedback before breaking my system.

Oops. Uploaded at the same place:
http://www.rtp-net.org/kirkwood/linux-base_2.6.32-46~bug673107_all.deb

Arnaud



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

Bug#673107: kirkwood: TCP checksum errors when using MTU 9000

[Rtp]

Martin Michlmayr t...@cyrius.com writes:

 * Arnaud Patard arnaud.pat...@rtp-net.org [2012-05-21 11:40]:
 I've uploaded a test kernel at :
 http://www.rtp-net.org/kirkwood/linux-image-2.6.32-5-kirkwood_2.6.32-46~bug673107_armel.deb
 
 Can you please check that the issue is gone with it ?

 Can you make a kernel image for Orion available?

Done. Kernel available at :
http://www.rtp-net.org/kirkwood/linux-image-2.6.32-5-orion5x_2.6.32-46~bug673107_armel.deb

Thanks,
Arnaud



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

Bug#673107: kirkwood: TCP checksum errors when using MTU 9000

[Rtp]

Hi,

I've uploaded a test kernel at :
http://www.rtp-net.org/kirkwood/linux-image-2.6.32-5-kirkwood_2.6.32-46~bug673107_armel.deb

Can you please check that the issue is gone with it ?


Thanks,
Arnaud



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

Bug#673107: kirkwood: TCP checksum errors when using MTU 9000

[Rtp]

Martin Michlmayr t...@cyrius.com writes:

Hi,

 Package: linux-2.6
 Version: 2.6.32-45

 A user on the Kirkwood platform reported TCP checksum errors when
 using MTU 9000:
 http://forum.qnap.com/viewtopic.php?f=147t=59281p=266527#p266527

 This has been previously discussed:
 http://lists.debian.org/debian-arm/2009/11/msg00087.html

 iirc a patch went into the kernel to set the limits for the various
 platforms (orion, kirkwood)... or maybe it was just discussed and
 never went in.

From a quick look, it seems that the support to handle the smaller FIFO
on kirkwood/dove has been merged on the ethernet driver side but has
never been merged in the platform code. Will make a patch and come back
once I'll have more informations.

Thanks,
Arnaud



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

Bug#670462: linux-2.6: Support new armhf kernel variant for Versatile Express (vexpress)

[Rtp]

Vagrant Cascadian vagr...@freegeek.org writes:

Hi.

 The following trimmed down debian/config/armhf/config.vexpress still worked 
 for me in qemu (built against 3.2.16-1). It also trimmed out the extraneous 
 Supported text in the defines file. The control file can be generated, as I 
 understand it, so didn't include in this diff.

 diff -u linux-2.6-3.2.16/debian/config/armhf/defines 
 linux-2.6-3.2.16/debian/config/armhf/defines
 --- linux-2.6-3.2.16/debian/config/armhf/defines
 +++ linux-2.6-3.2.16/debian/config/armhf/defines
 @@ -2,6 +2,7 @@
  flavours:
   mx5
   omap
 + vexpress
  kernel-arch: arm
  
  [image]
 @@ -28,0 +30,8 @@
 +
 +[vexpress_build]
 +image-file: arch/arm/boot/zImage
 +
 +[vexpress_description]
 +hardware: ARM Ltd. Versatile Express
 +hardware-long: ARM Ltd. Versatile Express family of processors
 +

 only in patch2:
 unchanged:
 --- linux-2.6-3.2.16.orig/debian/config/armhf/config.vexpress
 +++ linux-2.6-3.2.16/debian/config/armhf/config.vexpress
 @@ -0,0 +1,54 @@
 +##
 +## file: arch/arm/Kconfig
 +##
 +## choice: ARM system type
 +CONFIG_ARCH_VEXPRESS=y
 +## end choice
 +
 +## arch/arm/mach-vexpress/Kconfig
 +CONFIG_ARCH_VEXPRESS_CA9X4=y
 +
 +CONFIG_LOG_BUF_SHIFT=14

any reason for this change ?

 +CONFIG_OPROFILE=m
 +
 +CONFIG_SMP=y
 +CONFIG_VMSPLIT_2G=y
 +CONFIG_HOTPLUG_CPU=y
 +
 +CONFIG_ZBOOT_ROM_TEXT=0x0
 +CONFIG_ZBOOT_ROM_BSS=0x0
 +
 +CONFIG_NEON=y
 +
 +
 +CONFIG_MTD=m

hm. why is it still enabled ? from what I understand, qemu vexpress doesn't
simulate the flash peripheral. If you want to support something else
than qemu, you're missing some drivers I guess. If you want to support
only qemu vexpress emulation, maybe it worthes to be mentionned in the
description ?

 +CONFIG_MTD_CONCAT=m
 +CONFIG_MTD_PARTITIONS=m
 +CONFIG_MTD_CMDLINE_PARTS=m
 +CONFIG_MTD_CHAR=m
 +CONFIG_MTD_BLOCK=m
 +CONFIG_MTD_CFI=m
 +CONFIG_MTD_CFI_INTELEXT=m
 +CONFIG_MTD_CFI_AMDSTD=m
 +CONFIG_MTD_ARM_INTEGRATOR=m

fwiw, doesn't exist anymore. physmap should be used now.

Nevertheless, I've built tested this configuration and it worked in Qemu
as expected. I'll add that once we agree on the configuration. Also, do
you intend to add support for it into the debian-installer too ?


Thanks,
Arnaud



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

Bug#671200: linux-2.6: Generate leds-modules for Kirkwood Debian installer

[Rtp]

Simon Guinot si...@sequanux.org writes:

Hi,

 On Thu, May 03, 2012 at 11:19:43AM +0100, Martin Michlmayr wrote:
 * Simon Guinot si...@sequanux.org [2012-04-27 01:15]:
  On LaCie boards, the leds-ns2 and leds-netxbig drivers are used to
  configure the LEDs. This drivers are currently not embedded into the
  network-console installer. As a consequence, it is not possible to
  change the LEDs behaviour on LaCie boards when the SSH server is ready.
  
  Please, consider applying the attached patch.
 
 This patch is not correct:
 
  --- debian/installer/armel/package-list(revision 18961)
  +++ debian/installer/armel/package-list(working copy)
  @@ -5,7 +5,7 @@
   #
   Package: kernel-image
   Provides_iop32x: rtc-modules
  -Provides_kirkwood: rtc-modules, jffs2-modules, zlib-modules
  +Provides_kirkwood: rtc-modules, jffs2-modules, zlib-modules, leds-modules
 
 This says that the LEDs moduleas are built-in, which is not the case.
 You have to create
 debian/installer/armel/modules/armel-kirkwood/leds-modules with a list
 of modules.

 You will find in attachment an updated patch.


This updated version is working as advertised. I'm not seeing any
led trigger in your patch, does this mean that built-in ones are enough?

 
 I'm also not sure about the name leds-modules... maybe they should just
 be added to input-modules or something but I'll leave that to the
 kernel/installer team to decide.

leds are more outputs than inputs imho. From the current list of udebs,
creating a new one sounds a little bit cleaner. Moreover one may need
more stuff later, like new led module or trigger. There are traces of a
beeper udeb so if we had a udeb like this one, I don't understand why we
wouldn't have a leds udeb.

In the case I commit the patch, is there a bug asking to add support for
this udeb into d-i or do you intend to do it ?

Arnaud



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

Bug#655344: linux-image-3.1.0-1-kirkwood: Missing support for LaCie machines

[Rtp]

Simon Guinot si...@sequanux.org writes:


Hi,
 Hi,

 On Thu, Jan 12, 2012 at 12:08:06PM +0100, Arnaud Patard wrote:
 Simon Guinot si...@sequanux.org writes:
 Hi,
 
  Package: linux-2.6
  Version: 3.1.6-1
  Severity: important
 
  Dear Maintainer,
 
  The kernel image provided by package linux-image-3.1.0-1-kirkwood don't
  support the LaCie Kirkwood boards.
 
  Please, consider applying the following patch:
 
  diff --git a/config/armel/config.kirkwood b/config/armel/config.kirkwood
  index 1eae313..85b0c64 100644
  --- a/config/armel/config.kirkwood
  +++ b/config/armel/config.kirkwood
  @@ -63,6 +63,12 @@ CONFIG_MACH_DOCKSTAR=y
   CONFIG_MACH_OPENRD_BASE=y
   CONFIG_MACH_OPENRD_CLIENT=y
   CONFIG_MACH_OPENRD_ULTIMATE=y
  +CONFIG_MACH_NETSPACE_V2=y
  +CONFIG_MACH_INETSPACE_V2=y
  +CONFIG_MACH_NETSPACE_MAX_V2=y
  +CONFIG_MACH_D2NET_V2=y
  +CONFIG_MACH_NET2BIG_V2=y
  +CONFIG_MACH_NET5BIG_V2=y
   CONFIG_MACH_T5325=y
   
   ##
  @@ -172,6 +178,11 @@ CONFIG_GPIO_SYSFS=y
   # CONFIG_DRM is not set
   
   ##
  +## file: drivers/hwmon/Kconfig
  +##
  +CONFIG_SENSORS_GPIO_FAN=m
  +
  +##
   ## file: drivers/i2c/Kconfig
   ##
   CONFIG_I2C=y
  @@ -244,6 +255,8 @@ CONFIG_ISDN_DIVAS_MAINT=m
   CONFIG_NEW_LEDS=y
   CONFIG_LEDS_CLASS=y
   CONFIG_LEDS_GPIO=y
  +CONFIG_LEDS_NS2=y
  +CONFIG_LEDS_NETXBIG=y
   CONFIG_LEDS_TRIGGERS=y
   CONFIG_LEDS_TRIGGER_TIMER=y
   CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
 
 Does this really need to be built-in ? (side note: if it can't work as
 module, why is it a tristate and not a boolean in kernel config ?)

 No it doesn't. I should have configured them as modules.

ok. I've enabled the devices in svn for 3.2.


 By the way, why is the driver leds-gpio built-in ?


There may be various reason, but I've no idea why.

 
 Also, do you plan to add support for them into d-i (unless it's already
 done) ?

 Note that the having d-i support is not mandatory to run Debian on a
 LaCie NAS. Please, let's fix the kernel support. On my side, I will have
 a look at the Debian installer as quickly as possible (knowing that I am
 quite busy this days).

I didn't want to imply that d-i support was needed to enable the
devices. I was thinking it would be a nice addition to this change in
the kernel package.

Thanks,
Arnaud



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

Bug#655344: linux-image-3.1.0-1-kirkwood: Missing support for LaCie machines

[Rtp]

Simon Guinot si...@sequanux.org writes:
Hi,

 Package: linux-2.6
 Version: 3.1.6-1
 Severity: important

 Dear Maintainer,

 The kernel image provided by package linux-image-3.1.0-1-kirkwood don't
 support the LaCie Kirkwood boards.

 Please, consider applying the following patch:

 diff --git a/config/armel/config.kirkwood b/config/armel/config.kirkwood
 index 1eae313..85b0c64 100644
 --- a/config/armel/config.kirkwood
 +++ b/config/armel/config.kirkwood
 @@ -63,6 +63,12 @@ CONFIG_MACH_DOCKSTAR=y
  CONFIG_MACH_OPENRD_BASE=y
  CONFIG_MACH_OPENRD_CLIENT=y
  CONFIG_MACH_OPENRD_ULTIMATE=y
 +CONFIG_MACH_NETSPACE_V2=y
 +CONFIG_MACH_INETSPACE_V2=y
 +CONFIG_MACH_NETSPACE_MAX_V2=y
 +CONFIG_MACH_D2NET_V2=y
 +CONFIG_MACH_NET2BIG_V2=y
 +CONFIG_MACH_NET5BIG_V2=y
  CONFIG_MACH_T5325=y
  
  ##
 @@ -172,6 +178,11 @@ CONFIG_GPIO_SYSFS=y
  # CONFIG_DRM is not set
  
  ##
 +## file: drivers/hwmon/Kconfig
 +##
 +CONFIG_SENSORS_GPIO_FAN=m
 +
 +##
  ## file: drivers/i2c/Kconfig
  ##
  CONFIG_I2C=y
 @@ -244,6 +255,8 @@ CONFIG_ISDN_DIVAS_MAINT=m
  CONFIG_NEW_LEDS=y
  CONFIG_LEDS_CLASS=y
  CONFIG_LEDS_GPIO=y
 +CONFIG_LEDS_NS2=y
 +CONFIG_LEDS_NETXBIG=y
  CONFIG_LEDS_TRIGGERS=y
  CONFIG_LEDS_TRIGGER_TIMER=y
  CONFIG_LEDS_TRIGGER_DEFAULT_ON=y

Does this really need to be built-in ? (side note: if it can't work as
module, why is it a tristate and not a boolean in kernel config ?)

Also, do you plan to add support for them into d-i (unless it's already
done) ?

Thanks,
Arnaud



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

Bug#651215: Kernel fails to boot on NSLU2

[Rtp]

Hi,

I've uploaded a 3.1.5-1 with a patch which should fix the boot failure
at http://www.rtp-net.org/misc/deb/. Can you please test it ?

Thanks,
Arnaud



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

Bug#651215: Kernel fails to boot on NSLU2

[Rtp]

Ben Hutchings b...@decadent.org.uk writes:
Hi,

 On Tue, 2011-12-06 at 20:40 +0100, Jochen Friedrich wrote:
 Package: linux-image-3.1.0-1-ixp4xx
 Severity: normal
 
 While 3.0.0-6 booted OK on NSLU2 platform, 3.1.0-1 or -4 fails to do so.
 
 Boot log:
 [...]
 [0.00] Linux version 3.1.0-1-ixp4xx (Debian 3.1.4-1) 
 (wa...@debian.org)
 (gcc version 4.6.2 (Debian 4.6.2-4) ) #1 Wed Nov 30 06:35:38 UTC 2011
 [0.00] CPU: XScale-IXP42x Family [690541f1] revision 1 (ARMv5TE),
 cr=397f
 [0.00] CPU: VIVT data cache, VIVT instruction cache
 [0.00] Machine: Linksys NSLU2
 [...]
 [3.269860] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
 [3.350596] PCI: enabling device :00:01.2 (0140 - 0142)
 [3.356553] ehci_hcd :00:01.2: EHCI Host Controller
 [3.452053] ehci_hcd :00:01.2: new USB bus registered, assigned bus
 number 1
 [3.459646] ehci_hcd :00:01.2: coherent DMA mask 0x3ff is smaller
 than system GFP_DMA mask 0x
 [3.570085] ehci_hcd :00:01.2: coherent DMA mask 0x3ff is smaller
 than system GFP_DMA mask 0x
 [3.680189] ehci_hcd :00:01.2: coherent DMA mask 0x3ff is smaller
 than system GFP_DMA mask 0x
 (repeated over and over)

 I assume that this has something to do with:

 commit 650320181a08b64d4421c65c639cf47ad8cc2cd6
 Author: Nicolas Pitre n...@fluxnic.net
 Date:   Mon Jul 18 15:05:10 2011 -0400

 ARM: change ARM_DMA_ZONE_SIZE into a variable

 commit 7553ee777b513c3bc8f45bb9fc75fb1bbc584ba1
 Author: Nicolas Pitre nicolas.pi...@linaro.org
 Date:   Tue Jul 5 22:28:09 2011 -0400

 ARM: mach-ixp4xx: move from ARM_DMA_ZONE_SIZE to mdesc-dma_zone_size

 It's clear that the DMA zone size is supposed to be 64 MB on this
 machine and I don't see why the DMA mask hasn't propagated correctly.
 Any idea, Nicholas?

I may be wrong but it seems that arm_dma_zone_size is used before being
set. It would be interesting if someone can boot test a nslu2 kernel with
appended patch.


Thanks,
Arnaud

Index: linux-2.6-3.2~rc4/arch/arm/kernel/setup.c
===
--- linux-2.6-3.2~rc4.orig/arch/arm/kernel/setup.c	2011-12-01 23:56:01.0 +0100
+++ linux-2.6-3.2~rc4/arch/arm/kernel/setup.c	2011-12-07 23:04:39.0 +0100
@@ -921,6 +921,12 @@ void __init setup_arch(char **cmdline_p)
 	sanity_check_meminfo();
 	arm_memblock_init(meminfo, mdesc);
 
+#ifdef CONFIG_ZONE_DMA
+	if (mdesc-dma_zone_size) {
+		extern unsigned long arm_dma_zone_size;
+		arm_dma_zone_size = mdesc-dma_zone_size;
+	}
+#endif
 	paging_init(mdesc);
 	request_standard_resources(mdesc);
 
@@ -934,12 +940,6 @@ void __init setup_arch(char **cmdline_p)
 
 	tcm_init();
 
-#ifdef CONFIG_ZONE_DMA
-	if (mdesc-dma_zone_size) {
-		extern unsigned long arm_dma_zone_size;
-		arm_dma_zone_size = mdesc-dma_zone_size;
-	}
-#endif
 #ifdef CONFIG_MULTI_IRQ_HANDLER
 	handle_arch_irq = mdesc-handle_irq;
 #endif

Bug#636531: linux-image-3.0.0-1-kirkwood: NULL pointer deref in rt2800usb_get_txwi

[Rtp]

Marc Kleine-Budde m...@pengutronix.de writes:

Hi,


 [frogger@hardanger:linux-2.6]$ git show
 b52398b6e4522176dd125722c72c301015d24520
 commit b52398b6e4522176dd125722c72c301015d24520
 Author: Stanislaw Gruszka sgrus...@redhat.com
 Date:   Sat Jul 30 13:32:56 2011 +0200

 rt2x00: rt2800: fix zeroing skb structure

 We should clear skb-data not skb itself. Bug was introduced by:
 commit 0b8004aa12d13ec750d102ba4082a95f0107c649 rt2x00: Properly
 reserve room for descriptors in skbs.

 Cc: sta...@kernel.org # 2.6.36+
 Signed-off-by: Stanislaw Gruszka sgrus...@redhat.com
 Acked-by: Gertjan van Wingerde gwinge...@gmail.com
 Acked-by: Ivo van Doorn ivdo...@gmail.com
 Signed-off-by: John W. Linville linvi...@tuxdriver.com


I've done a quick build of 3.0 with this patch [1], can you please try
it in order to check if the patch is fixing the issue ?


Thanks,
Arnaud

[1] 
http://www.rtp-net.org/kirkwood/linux-image-3.0.0-1-kirkwood_3.0.0-2_armel.deb



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

Bug#636477: buildd: Errors at upload time

[Rtp]

Package: buildd
Severity: normal

When uploading something, I'm getting errors this error:

Can't locate object method new via package Buildd::Client (perhaps you
forgot to load Buildd::Client?) at /usr/share/perl5/Buildd/Base.pm line 120 
(#1)

From what I understand, it's due to commit
72f987c0a03e58358ea616628514efa0113f0332 which moved Client class from
Sbuild::DB to Buildd::

I'm joining a patch for this but it's possible that there's a better
fix.


-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.37-rsbac-1-lebrac (PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

From 28df4186c6cf782496ccfc74320b18435dacc2e5 Mon Sep 17 00:00:00 2001
From: Arnaud Patard arnaud.pat...@rtp-net.org
Date: Tue, 19 Jul 2011 09:44:41 +0200
Subject: [PATCH 1/2] Fix get_db_handle

Commit 72f987c0a03e58358ea616628514efa0113f0332 moved Client class from
Sbuild::DB to Buildd:: and now, when uploading, there are errors in the
log:
Can't locate object method new via package Buildd::Client (perhaps you
forgot to load Buildd::Client?) at /usr/share/perl5/Buildd/Base.pm line 120 (#1)

Adding a use Buildd:Client; cures the problem for me.

Signed-off-by: Arnaud Patard arnaud.pat...@rtp-net.org
---
 lib/Buildd/Base.pm |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/lib/Buildd/Base.pm b/lib/Buildd/Base.pm
index 2ed134c..91d831f 100644
--- a/lib/Buildd/Base.pm
+++ b/lib/Buildd/Base.pm
@@ -25,6 +25,7 @@ use warnings;
 
 use IO::File;
 use Buildd qw(lock_file unlock_file);
+use Buildd::Client qw();
 
 use Sbuild::Base;
 use Sbuild qw($devnull);
-- 
1.7.4.1

Bug#636478: buildd: bug in configuration parsing

[Rtp]

Package: buildd
Severity: normal

When dealing with configuration without take_from_dists, it ends up
calling Buildd::DistConf::new_hash() with a hash ref but new_hash()
is expecting a hash.
This leads to complains about being unable to find needed configuration
informations (I don't have the exact error message anymore).

I'm joining to this bug a proposed fix for this.

Thanks.

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.37-rsbac-1-lebrac (PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

From 579ea84de6f7c12a7c2e770aa14d034b2d0affa5 Mon Sep 17 00:00:00 2001
From: Arnaud Patard arnaud.pat...@rtp-net.org
Date: Tue, 19 Jul 2011 09:50:47 +0200
Subject: [PATCH 2/2] Buildd: fix configuration parsing

When dealing with configuration without take_from_dists, it ends up
calling Buildd::DistConf::new_hash() with a hash ref but new_hash()
is expecting a hash. Fix that by using same kind of arguments as
the one used in the other new_hash() calls.

Signed-off-by: Arnaud Patard arnaud.pat...@rtp-net.org
---
 lib/Buildd/Conf.pm |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/lib/Buildd/Conf.pm b/lib/Buildd/Conf.pm
index dcf4bd0..2bd5324 100644
--- a/lib/Buildd/Conf.pm
+++ b/lib/Buildd/Conf.pm
@@ -532,7 +532,8 @@ if (\@take_from_dists) {
 	#Make one entry per distribution, it's easier later on:
 	for my \$dist (\@dist_names) {
 	\$entry{'DIST_NAME'} = \$dist;
-my \$dist_config = Buildd::DistConf::new_hash(\\\%entry);
+my \$dist_config = Buildd::DistConf::new_hash(CHECK=$conf-{'CHECK'},
+		  HASH=\\\%entry);
 push \@distributions_info, \$dist_config;
 	}
 }
-- 
1.7.4.1

Bug#633738: ip6_tunnel: kernel BUG at net_namespace.c:497

[Rtp]

Alexander Clouter a...@digriz.org.uk writes:

Hi,

 [   33.356789] [c02397ec] (net_assign_generic+0x3c/0xbc) from [bf24d3d0] 
 (ip6_tnl_init_net+0x98/0x19c [ip6_tunnel])
 [   33.367378] [bf24d3d0] (ip6_tnl_init_net+0x98/0x19c [ip6_tunnel]) from 
 [c023942c] (register_pernet_operations+0x40/0xf4)
 [   33.378658] [c023942c] (register_pernet_operations+0x40/0xf4) from 
 [c02395c0] (register_pernet_device+0x20/0x54)
 [   33.389240] [c02395c0] (register_pernet_device+0x20/0x54) from 
 [bf25200c] (ip6_tunnel_init+0xc/0x84 [ip6_tunnel])
 [   33.399915] [bf25200c] (ip6_tunnel_init+0xc/0x84 [ip6_tunnel]) from 
 [c002734c] (do_one_initcall+0x6c/0x1e4)
 [   33.410062] [c002734c] (do_one_initcall+0x6c/0x1e4) from [c00738ec] 
 (sys_init_module+0xc0/0x1f0)
 [   33.419241] [c00738ec] (sys_init_module+0xc0/0x1f0) from [c0027ea0] 
 (ret_fast_syscall+0x0/0x28)
 [   33.428333] Code: e1a01000 e59f000c eb0a2ec7 e3a03000 (e5833000)
 [   33.434502] ---[ end trace bf87ce5c849aaa8e ]---
 Segmentation fault
 Failed to bring up iptv-shironeko.
 

 This is a regression as I was able to do all this with earlier kernels; 
 definately 2.6.32-34squeeze1.

hm... looks like it's from the backport of mainline commit
d5aa407f59f5b83d2c50ec88f5bf56d40f1f8978. It's changing a call to
register_pernet_gen_device() into a call to
register_pernet_device(). Changing it back to
register_pernet_gen_device() [1] allows to load the ip6_tunnel module but
I've not tested if it was working.

If you want a test kernel for kirkwood with the change, please say it
and I'll build one.

Arnaud

[1]
--- linux-source-2.6.32/net/ipv6/ip6_tunnel.c	2011-06-11 21:10:52.0 +0200
+++ linux-source-2.6.32/net/ipv6/ip6_tunnel.c	2011-07-14 18:45:59.0 +0200
@@ -1465,7 +1465,7 @@ static int __init ip6_tunnel_init(void)
 {
 	int  err;
 
-	err = register_pernet_device(ip6_tnl_net_ops);
+	err = register_pernet_gen_device(ip6_tnl_net_id, ip6_tnl_net_ops);
 	if (err  0)
 		goto out_pernet;
 

Bug#630113: linux-image-2.6.39-2-kirkwood: doesn't boot on HP t5325 thin client

[Rtp]

Vagrant Cascadian vagr...@debian.org writes:
Hi,

 Package: linux-image-2.6.39-2-kirkwood
 Version: 2.6.39-2
 Severity: normal

 when trying to boot on an HP t5325, i get the following error:

   Error: unrecognized/unsupported machine ID (r1 = 0x020f).

That looks bogus [ I'm even wondering why such a choice as 527 is a
pxa255 based system ].


   Available machine support:

   ID (hex)NAME
   0690Marvell DB-88F6281-BP Development Board
   0691Marvell RD-88F6192-NAS Development Board
   0692Marvell RD-88F6281 Reference Board
   078cMarvell 88F6281 GTW GE Board
   0a76Marvell eSATA SheevaPlug Reference Board
   0831Marvell SheevaPlug Reference Board
   0a63Marvell GuruPlug Reference Board
   0bb6Seagate FreeAgent DockStar
   085bQNAP TS-119/TS-219
   09c6QNAP TS-41x
   0b44Marvell OpenRD Ultimate Board
   0939Marvell OpenRD Client Board
   0915Marvell OpenRD Base Board
   0b1eHP t5325 Thin Client

   Please check your kernel config and/or bootloader.

 i also get the same error with the 2.6.32 or 2.6.38 kernels in debian.


 i'm using the following uboot environment variables/settings to boot it over
 the network:

 nfsbootargs=setenv bootargs console=ttyS0,115200 boot=nfs
 tftpload=bootp ; tftpboot 0x80 /ltsp/armel/uImage ; tftpboot 0x110 
 /ltsp/armel/uInitrd ; bootm 0x80 0x110
 nfsboot=${nfsbootargs} ; run tftpload
 run nfsboot

 these uboot values work with the 2.6.22.18-2-armel kernel that came with the
 thin client.


Check that your uboot firmware env has:
arcNumber=2846
mainlineLinux=yes

You can check with fw_printenv or printenv at uboot prompt or with
something like :
# strings /dev/mtd0ro |grep arcNumber

If it's not there, you'll have to set theses 2 variables (I don't
remember if I had to set it on mine or not, sorry).

Arnaud



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

Bug#629636: linux-image-2.6.32-5-kirkwood: IPsec aes-sha1 with kirkwood/mv_cesa causes CPU to spin

[Rtp]

Sebastian Andrzej Siewior sebast...@breakpoint.cc writes:

Hi,

 * Alexander Clouter | 2011-06-08 09:54:58 [+]:

Whilst deploying IPsec (with strongswan-ike2) I ran into a complication[1]
that causes mv_cesa to spin the CPU when the system receives an IPsec ESP
packet; it seems to be able to send traffic (before the CPU spin) as a
ICMP Echo request (a la pin) out from the system out is okay, until the
ICMP Reply comes back.  The packet never 'arrives' as far as userspace is
concerned and the only way to stop the CPU spinning is a reboot.

 I've been working on that and forgot about it in the meantime. The
 problem is that incremental sha1 checksum are wrong i.e. the previous
 state is ignored by the hardware.

if it's known to be broken, what about disabling it and enable it when
it's working ?
Also, I'm not familiar with cesa support but from what I understand in
the manual, you need to change the mode bit of the 0x3dd18 regiter to
configure continuous mode and I don't see anything for that [ feel free
to correct me if I'm wrong on that ].

Also, do you have a small test case to reproduce that ?

 Kernel's auto-test droppped an error message which disappeared in later
 a kernel so I assumed that it was fixed. This was not case but
 oldconfig disabled the algorithm test.

You're talking of CRYPTO_MANAGER_DISABLE_TESTS, right ?

Arnaud



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

Bug#622325: linux-image-2.6.38-2-orion5x: Problem With I2C

[Rtp]

Hi,

It should be fixed the 2.6.39 kernel uploaded to unstable. Can you test it,
please ?

Thanks,
Arnaud



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

Bug#519006: mips/ld: non-dynamic relocations refer to dynamic symbol

[Rtp]

Aurelien Jarno aurel...@aurel32.net writes:

 Hi all,

Hi,

 I have made some progress on this bug, though it has not progress in the
 expected direction. In other words I got some surprises.

 First of all it the bug has been introduced in binutils when introducing
 the MIPS PLT support [1] (commits around 2008-08-08). I am still
 convinced it is actually a binutils bug. Secondly, if the problem is
 actually not present in gcc-snapshot in gcc 4.5 we have *in Debian*, it
 is not due to the fix linked in the bugzilla entry. It is due to the
 fact we default to -mplt on these compilers. It is possible to
 workaround the bug on gcc 4.4 using -mplt (like it is possible to 
 workaround it by dropping the -g).

To sum up, there's no fix upstream for the bug but the
solution/workaround for now is -mplt, right ?


 Given all of that, the only forseen solution for this fix is to also
 default to -mplt on gcc 4.4. It also brings speed improvements, as 
 well as some more standard binaries with regard to other 
 architectures. On the other hand, I understand it is something quite 
 risky so close to a release. If we go for this solution, we may want

If the bug is fixed by this change and as a side effect, there are
improvements, there's no reason to not include it. I don't think it can
be worse than the current situation. Moreover (iirc) this bug is a
release blocker for mips so seeing it closed would be really nice.

 to trigger a rebuild of part of the archive as it is currently done
 on sparc.

There's a bunch of packages known to be bitten by this bug but there may
be others we're not aware of. imho a rebuild is mandatory. This would
also give us a good up-to-date status of the mips/mipsel ports for the
release.

My 2 cents,
Arnaud



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

Bug#590126: [Pkg-tcltk-devel] Bug#590126: rcmdr: FTBFS on mips{, el}: Error : package 'tcltk' could not be loaded

[Rtp]

Dirk Eddelbuettel e...@debian.org writes:

Hi,

 On 2 August 2010 at 10:20, Arnaud Patard (Rtp) wrote:
 | Dirk Eddelbuettel e...@debian.org writes:
 | 
 | Hi,
 | 
 | 
 |  |  (the failing program is attached). It seems that r-base hit bug
 |  |  #519006 (see [1]). It's a bug in gcc-4.4, and it's unlikely that
 |  |  Tcl/Tk itself can do something to it.
 |  | 
 |  | yeah, r-base is hitting this bug. As a _workaround_, you can patch the
 |  | r-base package with the joined patch. It'll disable the '-g' flag when
 |  | running the configure test. With that, the tcltk.so lib is generated
 |  | (and thus the tcl/tk deps are there too). Please note that I've not
 |  | tested if the R tcl/tk stuff is working, I've only checked that the lib
 |  | was built.
 | 
 |  Thanks for the patch (and the upstream maintainer for configure / m4 is
 |  CC'ed).  I will prepare a new r-base upload for Debian.
 | 
 |  Any idea why tcltk dies on mips when -g is present? Is that being
 |  addressed on on mips or in tcl/tk?
 | 
 | It's a gcc-4.4 bug specific to the mips platform. If you want more
 | details about it, see bug #519006.

 It failed again :-/  


oops. I've sent only the R.m4 change to make things clear but you need
to do a little bit more to get things working. You need to regenerate the
configure file (with autoreconf for instance) so that this change is
taken into account.

Arnaud



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

Bug#590126: [Pkg-tcltk-devel] Bug#590126: rcmdr: FTBFS on mips{, el}: Error : package 'tcltk' could not be loaded

[Rtp]

Dirk Eddelbuettel e...@debian.org writes:

Hi,


 |  (the failing program is attached). It seems that r-base hit bug
 |  #519006 (see [1]). It's a bug in gcc-4.4, and it's unlikely that
 |  Tcl/Tk itself can do something to it.
 | 
 | yeah, r-base is hitting this bug. As a _workaround_, you can patch the
 | r-base package with the joined patch. It'll disable the '-g' flag when
 | running the configure test. With that, the tcltk.so lib is generated
 | (and thus the tcl/tk deps are there too). Please note that I've not
 | tested if the R tcl/tk stuff is working, I've only checked that the lib
 | was built.

 Thanks for the patch (and the upstream maintainer for configure / m4 is
 CC'ed).  I will prepare a new r-base upload for Debian.

 Any idea why tcltk dies on mips when -g is present? Is that being
 addressed on on mips or in tcl/tk?

It's a gcc-4.4 bug specific to the mips platform. If you want more
details about it, see bug #519006.

Arnaud



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

Bug#590126: [Pkg-tcltk-devel] Bug#590126: rcmdr: FTBFS on mips{, el}: Error : package 'tcltk' could not be loaded

[Rtp]

Sergei Golovan sgolo...@nes.ru writes:
Hi,

 On Sat, Jul 31, 2010 at 8:49 AM, Shane McDonald
 mcdonald.sh...@gmail.com wrote:

 Mips and mipsel definitely have Tcl/Tk.

 Investigating a little further, I tried building rcmdr on a mipsel
 system with tcl8.5 and tk8.5 present, but it still gave the same
 errors that you saw.  But maybe it needs r-base to have been compiled
 with them present?  Just wild speculation, I really don't know
 anything about these packages.

 I've looked through the config.log after the ./configure run (for r-base) and
 found the following error message during testing for Tcl/Tk usability:

 configure:32106: checking whether compiling/linking Tcl/Tk code works
 configure:32144: gcc -std=gnu99 -o conftest -g -O2 -fpic
 -I/usr/include/tcl8.5 -I/usr/include/tcl8.5   conftest.c -ldl -lm
 -L/usr/lib -ltcl8.5 -L/usr/lib -ltk8.5 -lX11 -lXss -lXext 5
 /usr/bin/ld: non-dynamic relocations refer to dynamic symbol Tk_Init
 /usr/bin/ld: failed to set dynamic section sizes: Bad value
 collect2: ld returned 1 exit status
 configure:32144: $? = 1
 configure: failed program was:

 (the failing program is attached). It seems that r-base hit bug
 #519006 (see [1]). It's a bug in gcc-4.4, and it's unlikely that
 Tcl/Tk itself can do something to it.

yeah, r-base is hitting this bug. As a _workaround_, you can patch the
r-base package with the joined patch. It'll disable the '-g' flag when
running the configure test. With that, the tcltk.so lib is generated
(and thus the tcl/tk deps are there too). Please note that I've not
tested if the R tcl/tk stuff is working, I've only checked that the lib
was built.

Arnaud

Index: r-base-2.11.1/m4/R.m4
===
--- r-base-2.11.1.orig/m4/R.m4	2010-07-31 10:21:47.0 +
+++ r-base-2.11.1/m4/R.m4	2010-07-31 10:33:12.0 +
@@ -2426,8 +2426,10 @@
 [r_cv_tcltk_works],
 [AC_LANG_PUSH(C)
 r_save_CPPFLAGS=${CPPFLAGS}
+r_save_CFLAGS=${CFLAGS}
 r_save_LIBS=${LIBS}
 CPPFLAGS=${CPPFLAGS} ${TCLTK_CPPFLAGS}
+CFLAGS=`echo ${CFLAGS}|sed -e 's!-g!!'`
 LIBS=${LIBS} ${TCLTK_LIBS}
 AC_LINK_IFELSE([AC_LANG_PROGRAM(
 [[#include tcl.h
@@ -2439,6 +2441,7 @@
 r_cv_tcltk_works=yes,
 r_cv_tcltk_works=no)
 CPPFLAGS=${r_save_CPPFLAGS}
+CFLAGS=${r_save_CFLAGS}
 LIBS=${r_save_LIBS}
 AC_LANG_POP(C)])
 ])# _R_TCLTK_WORKS

Bug#519006: breaks dump builds, too

[Rtp]

Matthias Klose d...@debian.org writes:

 On 09.06.2010 12:02, Arnaud Patard (Rtp) wrote:
 Matthias Klosed...@debian.org  writes:

 Hi,

 On 08.06.2010 20:02, Bdale Garbee wrote:
 This prevents dump from building on mips/mipsel, which means the version
 of dump in testing is now months out of date.

 Is there an estimate for when this bug will be fixed?

 this is up to the debian-mips maintainers to answer.

 is there different behaviour when all objects involved in the link are
 rebuilt with binutils from experimental?

 hmm... Why are you talking about binutils ? From what I remember, the
 patch fixing the issue is in gcc 4.5

 reference?

http://sourceware.org/bugzilla/show_bug.cgi?id=10144#c6
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=519006#97
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=519006#111



 and someone said it won't be easy to backport it.

 so what do you propose?

  - drop mips as a release architecture?
  - do you volunteer to make gcc-4.5 ready for inclusion
in mips and fix any resulting RC-critical issue?

I'm no gcc or binutils hacker. I've reported what I understood on the
issue in order to help seeing it fixed. My mail was not intended to
offense you at all. Unfortunately, it looks like it was not well
perceived so I will stop replying to this bug. I'm not using Debian on
my mips boxes after all...

Arnaud



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

Bug#519006: breaks dump builds, too

[Rtp]

Matthias Klose d...@debian.org writes:

Hi,

 On 08.06.2010 20:02, Bdale Garbee wrote:
 This prevents dump from building on mips/mipsel, which means the version
 of dump in testing is now months out of date.

 Is there an estimate for when this bug will be fixed?

 this is up to the debian-mips maintainers to answer.

 is there different behaviour when all objects involved in the link are
 rebuilt with binutils from experimental?

hmm... Why are you talking about binutils ? From what I remember, the
patch fixing the issue is in gcc 4.5 and someone said it won't be easy
to backport it.

Arnaud



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

Bug#580136: [buildd-tools-devel] Bug#580136: schroot personality build fails on armel

[Rtp]

Roger Leigh rle...@codelibre.net writes:

Hi,

 Could the Debian ARM list/porters possibly comment upon this
 bug?  Please could you keep buildd-tools-devel and the bug
 in the CC on any reply.  Thanks.

 It's not clear to me why this bug has suddenly appeared, and
 only on armel.  There seem to be a few possibilities:

 1) schroot is using personality(2) incorrectly, but this is
only causing breakage on armel because only armel sets
some of the high bits outside the range of PER_MASK
 2) there's an armel-specific bug in the glibc personality
wrapper and/or headers
 3) there's an armel-specific bug in the kernel and/or its
headers

I would rather say it's a little bit more complicated than that. From
what I understand :

by default, the personality is PER_LINUX_32BIT on eabi (and PER_LINUX on
oabi [1]), but :

- on arm  v6, there's no xn/nx which means that READ_IMPLIES_EXEC will be
  set. So personality(0x) gives 0x00c0
- on arm = v6, there's xn/nx so READ_IMPLIES_EXEC will not be set and then
  personality(0x) gives 0x0080

It was giving 0x0080  on all systems before because it was
broken. It has been fixed in the kernel with commit :
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=9da616fb9946c8d65387052e5a538b8f54ddb292

Arnaud

[1] I can't check on oabi right now but I would be surprised to be wrong
here.



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

Bug#570848: ams: FTBFS: error: no matching function for call to 'min(qreal, double)'

[Rtp]

Reinhard Tartler siret...@tauware.de writes:

Hi,

 Package: ams
 Severity: serious

 relevant log:

 g++ -D_REENTRANT -DLADSPA_PATH=\/usr/lib/ladspa:/usr/local/lib/ladspa\ 
 -DTRANSLATIONSDIR=\/usr/share/ams/translations\ -DHAVE_CONFIG_H -I.
 -DQT_SHARED -I/usr/include/qt4 -I/usr/include/qt4/QtCore 
 -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtOpenGL   -Wall -g -O2 -c -o 
 canvasfunction.o canvasfunction.cpp
 In file included from /usr/include/qt4/QtCore/qobject.h:48,
  from /usr/include/qt4/QtCore/qiodevice.h:46,
  from /usr/include/qt4/QtCore/qdatastream.h:45,
  from /usr/include/qt4/QtCore/qpair.h:45,
  from /usr/include/qt4/QtGui/qbrush.h:45,
  from canvasfunction.cpp:4:
 /usr/include/qt4/QtCore/qstring.h:91: note: the mangling of 'va_list' has 
 changed in GCC 4.4
 canvasfunction.cpp: In member function 'void 
 CanvasFunction::mouseMoveEvent(int, QGraphicsSceneMouseEvent*)':
 canvasfunction.cpp:37: error: no matching function for call to 'min(qreal, 
 double)'
 canvasfunction.cpp:38: error: no matching function for call to 'max(qreal, 
 double)'
 canvasfunction.cpp:39: error: no matching function for call to 'min(qreal, 
 double)'
 canvasfunction.cpp:40: error: no matching function for call to 'max(qreal, 
 double)'
 canvasfunction.cpp:61: error: no matching function for call to 'min(qreal, 
 double)'
 canvasfunction.cpp:62: error: no matching function for call to 'max(qreal, 
 double)'
 canvasfunction.cpp:72: error: no matching function for call to 'min(qreal, 
 double)'
 canvasfunction.cpp:73: error: no matching function for call to 'max(qreal, 
 double)'
 canvasfunction.cpp:83: error: no matching function for call to 'min(qreal, 
 double)'
 canvasfunction.cpp:84: error: no matching function for call to 'max(qreal, 
 double)'
 canvasfunction.cpp:94: error: no matching function for call to 'min(qreal, 
 double)'
 canvasfunction.cpp:95: error: no matching function for call to 'max(qreal, 
 double)'

 the affected code however reads like this:

 ,
 | void CanvasFunction::mouseMoveEvent(int p, QGraphicsSceneMouseEvent *event)
 | {
 |   qreal x = event-scenePos().x();
 |   qreal y = event-scenePos().y();
 | 
 |   x = std::min(x, 5.0 * FUNCTION_SCALE);
 |   x = std::max(x, -5.0 * FUNCTION_SCALE);
 |   y = std::min(y, 5.0 * FUNCTION_SCALE);
 |   y = std::max(y, -5.0 * FUNCTION_SCALE);
 | 
 |   switch (*function.mode) {
 `

 not sure what this problem could mean. Perhaps debian armel people can
 comment on this?

hmm... my guess this issue is similar to this one :
http://wiki.debian.org/ArmEabiFixes#qreal.28qMin.2CqMax.2CQt.29

Maybe adding a cast will solve your issue.

Hope this helps,
Arnaud



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

Bug#381615: gitweb: Malformed rss 2.0 xml file

[Rtp]

Package: gitweb
Severity: normal

Hi,

gitweb is using a tag called content for describing the content of a
commit (eg in http://git.kernel.org/git/?p=git/git.git;a=rss). According
to the RSS 2.0 specifications
(http://www.rssboard.org/rss-specification), this tag does not
exist. The tag description should be used for this purpose. 

Please fix :)


Regards,
Arnaud

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17.6
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to fr_FR.UTF-8)



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

Bug#348293: yaird fails to generate initrd image for 2.6.15-ck2

[Rtp]

Hi,

I was building a custom kernel package based on the 2.6.16-rc1-mm2 and I
had this problem to. When parsing the configuration, yaird does a
sensitive match on lower case. 
The following patch fixe the issue for me :

--- /usr/lib/yaird/perl/KConfig.pm.orig2006-01-22 16:54:00.0 
+0100
+++ /usr/lib/yaird/perl/KConfig.pm 2006-01-22 16:54:09.0 +0100
@@ -65,7 +65,7 @@ sub init () {
if ($value eq 'y'
|| $value eq 'm'
|| $value =~ /^-?\d+$/
-   || $value =~ /^0x[0-9a-f]+$/
+   || $value =~ /^0x[0-9a-f]+$/i
|| $value =~ /^[-a-zA-Z0-9@,._\/= ]*$/
) {
$kConfMap-{$key} = $value;

Regards,
Arnaud



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

Bug#335550: Problems with jadetex

[Rtp]

Hi,

I've just got this bug too. The problem is caused by this line : 
etex -ini  -jobname=jadetex -progname=jadetex latex jadetex.ini

[ iirc, this line comes from the parsing of the
/etc/texmf/fmt.d/40jadetex.cnf. ]


This line is interpreted by the shell as the following two lines :

$ etex -ini  -jobname=jadetex -progname=jadetex  
$ latex jadetex.ini


The correct line should be :
$ etex -ini  -jobname=jadetex -progname=jadetex \latex jadetex.ini

imho, fmtutil/fmtutils-sys should be fixed to handle correctly this
separator. Unfortunately, I don't know how to fix this.

I hope that this information will help you in solving this issue.

Regards,
Arnaud Patard



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

Bug#292681: gnome-mouse-properties: Can not switch to left-handed mouse

[Rtp]

Hi,

Could you give me the following information : 
- your mouse type
- your configuration of it in your X configuration file ?

In case of you have the mouse device set to /dev/psaux, could you try
with /dev/input/mice ?


Regards,
Arnaud Patard



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