from:"Michael Büsch"

Bug#1041652: udev: Udev database attached to udev reportbug might contain sensitive information

2023-08-22 Thread Michael Büsch

On Tue, 22 Aug 2023 17:11:29 +0200
Michael Biebl  wrote:

> I posted a MR here
> https://salsa.debian.org/systemd-team/systemd/-/merge_requests/207
> 
> The default is to include the information. If you have suggestions to 
> the wording, please follow-up in the MR.

Hi Michael,

thanks for your kind reply.
The MR looks good to me.

-- 
Michael Büsch
https://bues.ch/


pgpkgPjlBaFtI.pgp
Description: OpenPGP digital signature

Bug#991212: python3-myhdl: myhdl always crashes in python3.9/ast.py

2021-07-17 Thread Michael Büsch

Package: python3-myhdl
Version: 0.11-1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: m...@bues.ch

Result of running a very simple MyHDL file with Python 3.9 (Debian Sid):

$ python3 ./myhdltest.py
Traceback (most recent call last):
  File "..././myhdltest.py", line 14, in 
instance.convert(hdl='Verilog')
  File "/usr/lib/python3/dist-packages/myhdl/_block.py", line 342, in convert
return converter(self)
  File "/usr/lib/python3/dist-packages/myhdl/conversion/_toVerilog.py", line
177, in __call__
genlist = _analyzeGens(arglist, h.absnames)
  File "/usr/lib/python3/dist-packages/myhdl/conversion/_analyze.py", line 170,
in _analyzeGens
v.visit(tree)
  File "/usr/lib/python3.9/ast.py", line 407, in visit
return visitor(node)
  File "/usr/lib/python3/dist-packages/myhdl/conversion/_analyze.py", line
1119, in visit_Module
_AnalyzeBlockVisitor.visit_Module(self, node)
  File "/usr/lib/python3/dist-packages/myhdl/conversion/_analyze.py", line
1070, in visit_Module
self.generic_visit(node)
  File "/usr/lib/python3.9/ast.py", line 415, in generic_visit
self.visit(item)
  File "/usr/lib/python3.9/ast.py", line 407, in visit
return visitor(node)
  File "/usr/lib/python3/dist-packages/myhdl/conversion/_analyze.py", line
1099, in visit_FunctionDef
self.visit(n)
  File "/usr/lib/python3.9/ast.py", line 407, in visit
return visitor(node)
  File "/usr/lib/python3/dist-packages/myhdl/conversion/_analyze.py", line 521,
in visit_Assign
self.visit(target)
  File "/usr/lib/python3.9/ast.py", line 407, in visit
return visitor(node)
  File "/usr/lib/python3/dist-packages/myhdl/conversion/_analyze.py", line 466,
in visit_Attribute
self.setAttr(node)
  File "/usr/lib/python3/dist-packages/myhdl/conversion/_analyze.py", line 482,
in setAttr
self.visit(node.value)
  File "/usr/lib/python3.9/ast.py", line 407, in visit
return visitor(node)
  File "/usr/lib/python3/dist-packages/myhdl/conversion/_analyze.py", line 962,
in visit_Subscript
self.accessIndex(node)
  File "/usr/lib/python3/dist-packages/myhdl/conversion/_analyze.py", line 986,
in accessIndex
self.visit(node.slice.value)
  File "/usr/lib/python3.9/ast.py", line 407, in visit
return visitor(node)
  File "/usr/lib/python3.9/ast.py", line 411, in generic_visit
for field, value in iter_fields(node):
  File "/usr/lib/python3.9/ast.py", line 249, in iter_fields
for field in node._fields:
AttributeError: 'int' object has no attribute '_fields'


The myhdltest.py example does work fine with the current upstream git master of
MyHDL:

commit 7b17942abbb2d9374df13f4f1f8c9d4589e1c88c

$ PYTHONPATH=/.../git/myhdl/ python3 ./myhdltest.py
$


-- System Information:
Debian Release: 11.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-myhdl depends on:
ii  python3  3.9.2-3

Versions of packages python3-myhdl recommends:
ii  myhdl-cosimulation  0.11-1

Versions of packages python3-myhdl suggests:
ii  myhdl-doc  0.11-1
from myhdl import *

@block
def myhdltest(x, y):
@always_comb
def logic():
x[0].next = y[0]
return logic

instance = myhdltest(
x=Signal(intbv(0)[1:]),
y=Signal(intbv(0)[1:])
)
instance.convert(hdl='Verilog')

Bug#951367: debootstrap: Raspbian bootstrap: Failed getting release file

2020-02-16 Thread Michael Büsch

On Sun, 16 Feb 2020 23:52:27 +0900
Hideki Yamane  wrote:

> > $ sudo debootstrap --arch=armhf --foreign --verbose 
> > --keyring=raspbian-archive-keyring-20120528.2/raspbian.public.key.gpg 
> > buster /tmp/debootstrap-test/ 
> > http://mirror1.hs-esslingen.de/pub/Mirrors/archive.raspbian.org/raspbian/  
> 
>  Please try without --verbose, I guess its option is something wrong with.


whoa yes. That helps indeed:


0/mb@wiggum:~$ sudo rm -rf /tmp/debootstrap-test
0/mb@wiggum:~$ sudo debootstrap --arch=armhf --foreign 
--keyring=raspbian-archive-keyring-20120528.2/raspbian.public.key.gpg buster 
/tmp/debootstrap-test/ 
http://mirror1.hs-esslingen.de/pub/Mirrors/archive.raspbian.org/raspbian/
I: Retrieving InRelease 
I: Checking Release signature
I: Valid Release signature (key id A0DA38D0D76E8B5D638872819165938D90FDDD2E)
I: Retrieving Packages 
I: Validating Packages 
I: Resolving dependencies of required packages...
I: Resolving dependencies of base packages...
I: Checking component main on 
http://mirror1.hs-esslingen.de/pub/Mirrors/archive.raspbian.org/raspbian...
I: Retrieving adduser 3.118
I: Validating adduser 3.118
I: Retrieving apt 1.8.2
I: Validating apt 1.8.2
I: Retrieving apt-utils 1.8.2
I: Validating apt-utils 1.8.2
I: Retrieving base-files 10.3+rpi1+deb10u3
I: Validating base-files 10.3+rpi1+deb10u3
I: Retrieving base-passwd 3.5.46
I: Validating base-passwd 3.5.46
I: Retrieving bash 5.0-4
^CE: Interrupt caught ... exiting


Thanks :)

-- 
Michael


pgpVAytz3cJFG.pgp
Description: OpenPGP digital signature

Bug#951367: debootstrap: Raspbian bootstrap: Failed getting release file

2020-02-16 Thread Michael Büsch

On Sun, 16 Feb 2020 14:47:37 +0100
Geert Stappers  wrote:

> On Sun, Feb 16, 2020 at 12:14:28PM +0100, Michael Büsch wrote:
> > A different command has been used to "reproduce" this problem.  
> 
> Please elaborate that.


The option --no-check-gpg has been used.


> > So I currently don't consider the unreproducible flag for this bug as 
> > valid.  
> 
> With the keyring file inplace, I had a succesfull "build".
> To me is the bugreport UNreproducible.
> 
> I have no idea how to dive deeper into this.


Ok. With the same options used, that statement is valid.

I'm not sure what's going on.
Did you delete the contents of /tmp/debootstrap-test/ before trying?
If that directory contains leftovers from a previous successful
attempt (even if interrupted), the problem does not occur.

Here's an example with a specific mirror instead of mirrordirector:


$ sudo rm -rf /tmp/debootstrap-test/
$ sudo debootstrap --arch=armhf --foreign --verbose 
--keyring=raspbian-archive-keyring-20120528.2/raspbian.public.key.gpg buster 
/tmp/debootstrap-test/ 
http://mirror1.hs-esslingen.de/pub/Mirrors/archive.raspbian.org/raspbian/
I: Retrieving InRelease 
I: Retrieving Release 
E: Failed getting release file 
http://mirror1.hs-esslingen.de/pub/Mirrors/archive.raspbian.org/raspbian/dists/buster/Release
$ sudo debootstrap --arch=armhf --foreign --verbose 
--keyring=raspbian-archive-keyring-20120528.2/raspbian.public.key.gpg buster 
/tmp/debootstrap-test/ http://ftp.gwdg.de/pub/linux/debian/raspbian/raspbian/
I: Retrieving InRelease 
I: Retrieving Release 
E: Failed getting release file 
http://ftp.gwdg.de/pub/linux/debian/raspbian/raspbian/dists/buster/Release
$ sudo dpkg -i debootstrap_1.0.116_all.deb 
dpkg: warning: downgrading debootstrap from 1.0.117 to 1.0.116
(Reading database ... 524483 files and directories currently installed.)
Preparing to unpack debootstrap_1.0.116_all.deb ...
Unpacking debootstrap (1.0.116) over (1.0.117) ...
Setting up debootstrap (1.0.116) ...
Processing triggers for man-db (2.9.0-2) ...
$ sudo debootstrap --arch=armhf --foreign --verbose 
--keyring=raspbian-archive-keyring-20120528.2/raspbian.public.key.gpg buster 
/tmp/debootstrap-test/ http://ftp.gwdg.de/pub/linux/debian/raspbian/raspbian/
I: Retrieving InRelease 
I: Checking Release signature
I: Valid Release signature (key id A0DA38D0D76E8B5D638872819165938D90FDDD2E)
I: Retrieving Packages 
I: Validating Packages 
I: Resolving dependencies of required packages...
I: Resolving dependencies of base packages...
I: Checking component main on 
http://ftp.gwdg.de/pub/linux/debian/raspbian/raspbian...
^CE: Interrupt caught ... exiting


As you can see with the old version 1.0.166 it works fine with this mirror.


> And I do hope that bugreporter is aware that BR got human attention.

Erm, yes?

-- 
Michael


pgpZrhWBlH74f.pgp
Description: OpenPGP digital signature

Bug#951367: debootstrap: Raspbian bootstrap: Failed getting release file

2020-02-16 Thread Michael Büsch

A different command has been used to "reproduce" this problem.
So I currently don't consider the unreproducible flag for this bug as
valid.

Please get the key from here:

http://mirrordirector.raspbian.org/raspbian//pool/main/r/raspbian-archive-keyring/raspbian-archive-keyring_20120528.2.tar.gz
SHA256: fdf50f775b60901a2783f21a6362e2bf5ee6203983e884940b163faa1293c002

Commands:

wget 
http://mirrordirector.raspbian.org/raspbian//pool/main/r/raspbian-archive-keyring/raspbian-archive-keyring_20120528.2.tar.gz
tar xf raspbian-archive-keyring_20120528.2.tar.gz
gpg --dearmor raspbian-archive-keyring-20120528.2/raspbian.public.key
sudo debootstrap --arch=armhf --foreign --verbose 
--keyring=raspbian-archive-keyring-20120528.2/raspbian.public.key.gpg buster 
/tmp/debootstrap-test/ http://mirrordirector.raspbian.org/raspbian/


Result with debootstrap 1.0.116:
I: Retrieving InRelease 
I: Checking Release signature
I: Valid Release signature (key id A0DA38D0D76E8B5D638872819165938D90FDDD2E)
I: Retrieving Packages 
I: Validating Packages 
I: Resolving dependencies of required packages...
I: Resolving dependencies of base packages...
I: Checking component main on http://mirrordirector.raspbian.org/raspbian...
I: Retrieving adduser 3.118
I: Validating adduser 3.118
I: Retrieving apt 1.8.2
I: Validating apt 1.8.2
I: Retrieving apt-utils 1.8.2
^CE: Interrupt caught ... exiting


Result with debootstrap 1.0.117:
I: Retrieving InRelease 
I: Retrieving Release 
E: Failed getting release file 
http://mirrordirector.raspbian.org/raspbian/dists/buster/Release


-- 
Michael


pgpip2GtohrxY.pgp
Description: OpenPGP digital signature

Bug#951367: debootstrap: Raspbian bootstrap: Failed getting release file

2020-02-15 Thread Michael Büsch

Package: debootstrap
Version: 1.0.117
Severity: important

Since debootstrap 1.0.117 Raspbian bootstrap fails with the following error
message:

$ debootstrap --arch=armhf --foreign --verbose --keyring=keyrings/raspbian-
archive-keyring.gpg buster /tmp/debootstrap-test
http://mirrordirector.raspbian.org/raspbian/
I: Retrieving InRelease
I: Retrieving Release
E: Failed getting release file
http://mirrordirector.raspbian.org/raspbian/dists/buster/Release



-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages debootstrap depends on:
ii  wget  1.20.3-1+b2

Versions of packages debootstrap recommends:
ii  arch-test   0.16-2
ii  debian-archive-keyring  2019.1
ii  gnupg   2.2.19-1

Versions of packages debootstrap suggests:
pn  squid-deb-proxy-client  
pn  ubuntu-archive-keyring  

-- no debconf information

Bug#918722: debootstrap: says InRelease file expired

2019-01-08 Thread Michael Büsch

Package: debootstrap
Version: 1.0.113
Severity: normal

When bootstrapping Raspbian with debootstrap it fails since version 1.0.113:

  debootstrap --arch=armhf --foreign --verbose 
--keyring=raspbian.public.key.gpg stretch /my/directory 
http://mirrordirector.raspbian.org/raspbian/

The error message is
  E: InRelease file 
http://mirrordirector.raspbian.org/raspbian/dists/stretch/InRelease is expired 
since (Tue, 08 Jan 2019 00:00:00 +0100)

Yesterday (on 07 Jan) the error message told me it was expired since 07 Jan.

The problem does not occur with version 1.0.112 of debootstrap.

I am not sure at all, if this is a problem within Raspbian or in debootstrap.


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-1-amd64 (SMP w/4 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)
LSM: AppArmor: enabled

Versions of packages debootstrap depends on:
ii  wget  1.20.1-1

Versions of packages debootstrap recommends:
ii  arch-test   0.15-1
ii  debian-archive-keyring  2018.1
ii  gnupg   2.2.12-1

Versions of packages debootstrap suggests:
pn  squid-deb-proxy-client  
pn  ubuntu-archive-keyring  

-- no debconf information

Bug#834335: ngspice isn't providing libngspice.so

2018-08-02 Thread Michael Büsch

I would like to second the proposal to add libngspice.so support to the
ngspice package.
PySpice ( https://pyspice.fabrice-salvaire.fr/ ) needs libngspice.so.
So I'm currently stuck with compiling ngspice from source by myself.

Also new versions of ngspice are available. Please consider an upgrade.

Thanks.

-- 
Michael


pgpMXc7WcMS6j.pgp
Description: OpenPGP digital signature

Bug#905031: bind9 fails to install

2018-07-30 Thread Michael Büsch

Package: bind9
Version: 1:9.11.4+dfsg-3
Severity: important


apt throws some apparmor and permission errors while installing bind9:



$ sudo apt install bind9
Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
  bind9-doc ufw
The following NEW packages will be installed:
  bind9
0 upgraded, 1 newly installed, 0 to remove and 136 not upgraded.

Need to get 627 kB of archives.
After this operation, 2,189 kB of additional disk space will be used.   

Get:1 http://ftp.de.debian.org/debian sid/main amd64 bind9 amd64 
1:9.11.4+dfsg-3 [627 kB]   
Fetched 627 kB in 0s (1,346 kB/s)
Preconfiguring packages ...
Selecting previously unselected package bind9.
(Reading database ... 458381 files and directories currently installed.)

Preparing to unpack .../bind9_1%3a9.11.4+dfsg-3_amd64.deb ...   

Unpacking bind9 (1:9.11.4+dfsg-3) ...
Setting up bind9 (1:9.11.4+dfsg-3) ...
AppArmor parser error for /etc/apparmor.d/usr.sbin.named in 
/etc/apparmor.d/usr.sbin.named at line 36: missing an end of line character? 
(entry: /usr/share/dns/root.*)
bind9-pkcs11.service is a disabled or a static unit not running, not starting 
it.   
bind9-resolvconf.service is a disabled or a static unit not running, not 
starting it.   
Job for bind9.service failed because the control process exited with error 
code.
See "systemctl status bind9.service" and "journalctl -xe" for details.  

invoke-rc.d: initscript bind9, action "restart" failed.
● bind9.service - BIND Domain Name Server
   Loaded: loaded (/lib/systemd/system/bind9.service; enabled; vendor preset: 
enabled)  
   Active: failed (Result: exit-code) since Mon 2018-07-30 21:45:34 CEST; 15ms 
ago  
 Docs: man:named(8)
  Process: 14667 ExecStart=/usr/sbin/named $OPTIONS (code=exited, 
status=1/FAILURE) 
 Main PID: 9684 (code=exited, status=0/SUCCESS)

Jul 30 21:45:34 hostname named[14670]: listening on IPv4 interface lo, 
127.0.0.1#53   
Jul 30 21:45:34 hostname named[14670]: listening on IPv4 interface wlan0, 
192.168.179.21#53   
Jul 30 21:45:34 hostname named[14670]: generating session key for dynamic DNS   
  
Jul 30 21:45:34 hostname named[14670]: sizing zone task pool based on 5 zones   
  
Jul 30 21:45:34 hostname named[14670]: could not configure root hints from 
'/usr/share/dns/root.hints': permission denied
Jul 30 21:45:34 hostname named[14670]: loading configuration: permission denied 
  
Jul 30 21:45:34 hostname named[14670]: exiting (due to fatal error) 
  
Jul 30 21:45:34 hostname systemd[1]: bind9.service: Control process exited, 
code=exited status=1  
Jul 30 21:45:34 hostname systemd[1]: bind9.service: Failed with result 
'exit-code'.   
Jul 30 21:45:34 hostname systemd[1]: Failed to start BIND Domain Name Server.   
  
dpkg: error processing package bind9 (--configure):
 installed bind9 package post-installation script subprocess returned error 
exit status 1   
Processing triggers for systemd (239-7) ...
Processing triggers for man-db (2.8.4-1) ...
Errors were encountered while processing:
 bind9
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)







-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.17.0-1-amd64 (SMP w/4 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)
LSM: AppArmor: enabled

Versions of packages bind9 depends on:
ii  adduser3.117
ii  bind9utils 1:9.11.4+dfsg-3
ii  debconf [debconf-2.0]  1.5.69
ii  dns-root-data  2018013001
ii  libbind9-160   1:9.11.4+dfsg-3
ii  libc6  2.27-5
ii  libcap21:2.25-1.2
ii  libcom-err21.44.3-1
ii  libdns1102 1:9.11.4+dfsg-3
ii  libfstrm0  0.3.0-1+b1
ii  libgeoip1  1.6.12-1
ii  libgssapi-krb5-2   1.16-2
ii  libisc169  1:9.11.4+dfsg-3
ii  libisccc1601:9.11.4+dfsg-3
ii  libisccfg160   1:9.11.4+dfsg-3
ii  libjson-c3

Bug#902551: [cython3] Miscompilation of exception handling with global tuple as exception type (since 0.28.2-1)

2018-06-27 Thread Michael Büsch

Package: cython3
Version: 0.28.2-4
Severity: important
Tags: patch

--- Please enter the report below this line. ---


cython 0.28.x-x miscompiles exception handling, if a global tuple is
used as exception type.

This is the upstream bug:
https://github.com/cython/cython/issues/2425

This is the upstream fix:
https://github.com/cython/cython/commit/7f41244db2479eaf07343c5d3b07b4183fc6877a



--- System information. ---
Architecture: 
Kernel:   Linux 4.16.0-2-amd64

Debian Release: buster/sid
  500 unstableftp.de.debian.org 

--- Package information. ---
Depends (Version) | Installed
=-+-==
python3  (<< 3.7) | 3.6.5-3
python3 (>= 3.6~) | 3.6.5-3
python3:any (>= 3.3.2-2~) | 
libc6   (>= 2.14) | 


Recommends   (Version) | Installed
==-+-===
python3-dev| 3.6.5-3
gcc| 4:7.3.0-3


Suggests(Version) | Installed
=-+-===
cython-doc|



-- 
Michael


pgpgVnA2FncwY.pgp
Description: OpenPGP digital signature

Bug#877405: jython: 'import socket' fails

2017-10-01 Thread Michael Büsch

Package: jython
Version: 2.7.1+repack-2
Severity: normal

Jython 2.7.1 (, Sep 30 2017, 13:31:09) 
[OpenJDK 64-Bit Server VM (Oracle Corporation)] on java1.8.0_144
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/share/jython/Lib/socket.py", line 3, in 
from _socket import (
  File "/usr/share/jython/Lib/_socket.py", line 2, in 
import encodings.idna
  File "/usr/share/jython/Lib/encodings/idna.py", line 9, in 
from com.ibm.icu.text import StringPrep, StringPrepParseException
ImportError: No module named ibm


-- System Information:
Debian Release: sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.12.0-2-amd64 (SMP w/4 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)

Versions of packages jython depends on:
ii  antlr3.2 3.2-16
ii  libasm-java  6.0~alpha-1
ii  libguava-java19.0-1
ii  libjffi-java 1.2.7-10
ii  libjline2-java   2.11-4
ii  libjnr-constants-java0.9.9-2
ii  libjnr-netdb-java1.1.6-1
ii  libjnr-posix-java3.0.37-2
ii  libjnr-x86asm-java   1.0.2-5
ii  liblivetribe-jsr223-java 2.0.6-1
ii  openjdk-8-jre-headless [java5-runtime-headless]  8u144-b01-2
ii  perl 5.26.0-8
ii  python   2.7.14-1

Versions of packages jython recommends:
ii  openjdk-8-jdk [java-compiler]  8u144-b01-2

Versions of packages jython suggests:
pn  jython-doc   
pn  libmysql-java
pn  libpostgresql-jdbc-java  

-- no debconf information

Bug#815196: ITP: awlsim -- S7 compatible soft-PLC

2016-04-10 Thread Michael Büsch

On Sun, 10 Apr 2016 21:14:27 +0200
Geert Stappers  wrote:

> Not yet tried. It is 'override_dh_auto_test:' which I wanna try.

Hm yes. It probably is best to add that override and either do nothing
or call tests/run.sh -q to execute the actual unit tests.

-- 
Michael


pgpdjYM9u0T0U.pgp
Description: OpenPGP digital signature

Bug#815196: ITP: awlsim -- S7 compatible soft-PLC

2016-04-03 Thread Michael Büsch

On Sun, 3 Apr 2016 22:58:12 +0200
Geert Stappers  wrote:

> After a `git clone`,
> I did `dpkg-checkbuilddeps && dpkg-buildpackage -uc -us` and got
> 
> 
> running build_scripts
>dh_auto_test -O--buildsystem=pybuild
> I: pybuild base:184: cd 
> /home/stappers/src/awlsim/.pybuild/pythonX.Y_2.7/build; python2.7 -m unittest 
> discover -v 
> 
> --
> Ran 0 tests in 0.000s
> 
> OK
> I: pybuild base:184: cd 
> /home/stappers/src/awlsim/.pybuild/pythonX.Y_3.5/build; python3.5 -m unittest 
> discover -v 
> awlsim-gui ERROR: Neither PySide nor PyQt found.
> PLEASE INSTALL PySide (http://www.pyside.org/)
> or PyQt4 with v2 APIs 
> (http://www.riverbankcomputing.com/software/pyqt/download)
> or PyQt5 with v2 APIs 
> (http://www.riverbankcomputing.com/software/pyqt/download5)
> Press enter to exit.
> 
> 
> What to do to get a "clean build"?
> 
> If I should have build from  a .tar.gz ( not from git ), please tell. 

Using the git tree is fine.

pybuild seems to pull in the gui libraries at build time. Funny
thing is that it only seems to do this on Python 3.
So we probably have to add pyside or pyqt for Python 3 to the build
deps.

If you install python3-pyside it should build.

-- 
Michael


pgpBdb3yAURco.pgp
Description: OpenPGP digital signature

Bug#815196: ITP: awlsim -- S7 compatible soft-PLC

2016-03-04 Thread Michael Büsch

On Fri, 19 Feb 2016 22:46:33 +0100
Michael Büsch <m...@bues.ch> wrote:

> Package: wnpp
> Severity: wishlist
> Owner: "Michael Büsch" <m...@bues.ch>
> 
> * Package name: awlsim
>   Version : 0.44?
>   Upstream Author : Michael Buesch <m...@bues.ch>
> * URL : http://bues.ch/h/awlsim
> * License : GPLv2+
>   Programming Lang: Python
>   Description : S7 compatible soft-PLC
> 
> Awlsim is a soft-PLC (see
> https://en.wikipedia.org/wiki/Programmable_logic_controller) that can execute
> STEP7 (see German https://de.wikipedia.org/wiki/STEP_7) compatible AWL/STL
> code.
> 
> I plan to maintain the Debian package by myself.
> The upstream repository, also maintained by me, already contains some basic
> Debian packaging scripts. (see http://bues.ch/gitweb?p=awlsim.git;a=tree)


As I am currently neither debian developer nor debian maintainer, I
will need sponsoring on this package.

I would be happy if somebody commented on the existing debian scripts
that are currently used to build Raspbian packages from the repository
above.

-- 
Michael


pgpWWRotH06f8.pgp
Description: OpenPGP digital signature

Bug#815199: ITP: acme-tiny -- letsencrypt tiny python client

2016-02-21 Thread Michael Büsch

On Fri, 19 Feb 2016 21:38:44 -0300
Jeremías Casteglione  wrote:

> Package: wnpp
> Severity: wishlist
> Owner: "Jeremías Casteglione" 
> 
> * Package name: acme-tiny
>   Version : 20151229
>   Upstream Author : Daniel Roesler 
> * URL : https://github.com/diafygi/acme-tiny
> * License : MIT
>   Programming Lang: Python
>   Description : letsencrypt tiny python client
> 
> acme-tiny is a tiny script to issue and renew TLS certs from Let's Encrypt

>PLEASE READ THE SOURCE CODE!

Ok. :)

The error handling in the whole script but especially in the
wellknown-file writing section is a bit lacking. It can easily happen
that a wellknown file is left in place, if some exception happens. Or
even in the common path where the validation did not pass.

Also I don't like the part where it does urlopen(challenge['uri'])
This essentially opens any url, that can even be a local file, that the
remote end said it wants to open. I think the uri should be validated
before being passed to urlopen(). The connection the 'challenge' was
retrieved through is https, but we'd still have to trust the other end
not sending us funky uris.

And I'm not sure about the github fork network. There seem to be forks
that added major stuff to the code and also (from a quick look)
addressed the exception bug from above.

-- 
Michael

pgpuIUiBScco9.pgp
Description: OpenPGP digital signature

Bug#815196: ITP: awlsim -- S7 compatible soft-PLC

2016-02-19 Thread Michael Büsch

Package: wnpp
Severity: wishlist
Owner: "Michael Büsch" <m...@bues.ch>

* Package name: awlsim
  Version : 0.44?
  Upstream Author : Michael Buesch <m...@bues.ch>
* URL : http://bues.ch/h/awlsim
* License : GPLv2+
  Programming Lang: Python
  Description : S7 compatible soft-PLC

Awlsim is a soft-PLC (see
https://en.wikipedia.org/wiki/Programmable_logic_controller) that can execute
STEP7 (see German https://de.wikipedia.org/wiki/STEP_7) compatible AWL/STL
code.

I plan to maintain the Debian package by myself.
The upstream repository, also maintained by me, already contains some basic
Debian packaging scripts. (see http://bues.ch/gitweb?p=awlsim.git;a=tree)

Bug#813232: debootstrap: Two-staged bootstrapping with --second-stage broken

2016-02-16 Thread Michael Büsch

devices4.diff fixes my Rasbian foreign architecture bootstrapping
problem (see Bug#813242). So thumbs up from me.

-- 
Michael


pgp2_iKFndeT7.pgp
Description: OpenPGP digital signature

Bug#813242: debootstrap: second stage foreign boostrap fails

2016-01-30 Thread Michael Büsch

Package: debootstrap
Version: 1.0.75
Severity: important

I use debootstrap in combination with qemu-user (binfmt-misc) to bootstrap
Raspbian armhf on a Debian sid amd64 host.
The first stage works fine, but in recent debootstrap releases the second stage
fails.
debootstrap --second-stage fails without any message with error code 1. It just
seems to do nothing and return an error.
I downgraded to debootstrap 1.0.75, which does not have the problem.



-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores)
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)

Versions of packages debootstrap depends on:
ii  wget  1.17.1-1+b1

Versions of packages debootstrap recommends:
ii  debian-archive-keyring  2014.3
ii  gnupg   1.4.20-1

debootstrap suggests no packages.

-- no debconf information

Bug#798205: gcc-avr: Throws bogus 'appears to be a misspelled signal handler' warning with lto

2015-09-06 Thread Michael Büsch

Package: gcc-avr
Version: 1:4.8.1+Atmel3.4.5-1
Severity: normal
Tags: patch

avr-gcc 4.8.1 throws an annoying bogus warning when linking with -flto.
The bug is fixed upstream (4.8.3).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59396

Please update the Debian package.



-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.1.0-2-amd64 (SMP w/4 CPU cores)
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)

Versions of packages gcc-avr depends on:
ii  binutils-avr  2.24+Atmel3.4.5-1
ii  libc6 2.19-19
ii  libgmp10  2:6.0.0+dfsg-7
ii  libmpc3   1.0.3-1
ii  libmpfr4  3.1.3-1
ii  zlib1g1:1.2.8.dfsg-2+b1

gcc-avr recommends no packages.

Versions of packages gcc-avr suggests:
ii  avr-libc  1:1.8.0+Atmel3.4.5-1
ii  gcc   4:5.2.1-4
pn  gcc-doc   
pn  task-c-devel  

-- no debconf information

Bug#773024: pm-utils: laptop-mode hook may cause heavy write performance degradation

2014-12-13 Thread Michael Büsch

Package: pm-utils
Version: 1.4.1-15
Severity: important
Tags: patch

The laptop-mode hook tries to save the dirty_ratio and dirty_background_ratio
values before it modifies them.
This breaks, if the user set dirty_bytes or dirty_background_bytes before. In
that case the _ratio files will read as 0.
That in turn means that on restore of the 0 values to the _ratio files,
which happens on laptop-mode switch off, dirty memory ratio will be set to
zero. This heavily breaks disk write performance and renders the system mostly
unusable.

The proposed patch tries to fix this by aborting the hook, if any ratio field
is zero.



-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
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)

Versions of packages pm-utils depends on:
ii  powermgmt-base  1.31+nmu1

Versions of packages pm-utils recommends:
ii  ethtool  1:3.16-1
ii  hdparm   9.43-1.1
ii  kbd  1.15.5-2
ii  procps   2:3.3.9-8
ii  vbetool  1.1-3

Versions of packages pm-utils suggests:
ii  cpufrequtils008-1
pn  radeontool  none
ii  wireless-tools  30~pre9-8

-- no debconf information
--- laptop-mode.orig	2014-12-13 11:55:35.527031386 +0100
+++ laptop-mode	2014-12-13 12:01:44.430429767 +0100
@@ -48,6 +48,13 @@
 
 [ -w $VM/laptop_mode -a -w $VM/dirty_ratio ] || exit $NA
 
+# If the user set any of dirty_bytes or dirty_background_bytes
+# the corresponding _ratio field will appear as 0.
+# Abort in that case, because restoring 0 to any _ratio field will
+# result in disabled dirty memory and thus heavy breakage.
+[ x0 = x$(cat $VM/dirty_ratio) ]  exit $NA
+[ x0 = x$(cat $VM/dirty_background_ratio) ]  exit $NA
+
 read_values() {
 for f in $vmfiles; do
 	[ -r $VM/$f ]  cat $VM/$f || echo 0

Bug#769135: linux-image-3.2.0-4-amd64: Backport of fix for JMicron USB-SATA bridges

2014-11-11 Thread Michael Büsch

Package: linux-image-3.2.0-4-amd64
Version: 3.2.0
Severity: normal
Tags: patch

Please apply a backport of the JMicron USB-SATA quirk fix to 3.2.0 (wheezy).
Without this fix certain JMicron USB-SATA bridges are not usable in Debian
Wheezy.
The fix already is upstream (git b14bf2d0c0358140041d1c1805a674376964d0e0)
and in Debian's 3.16.0 kernel (Sid/Jessie).
A proposed backport of the fix is attached to this report.
Index: linux-3.2.60/drivers/scsi/sd.c
===
--- linux-3.2.60.orig/drivers/scsi/sd.c	2014-06-09 14:29:18.0 +0200
+++ linux-3.2.60/drivers/scsi/sd.c	2014-08-29 20:25:58.0 +0200
@@ -2149,7 +2149,10 @@
 		}
 
 		sdkp-DPOFUA = (data.device_specific  0x10) != 0;
-		if (sdkp-DPOFUA  !sdkp-device-use_10_for_rw) {
+		if (sdp-broken_fua) {
+			sd_printk(KERN_NOTICE, sdkp, Disabling FUA\n);
+			sdkp-DPOFUA = 0;
+		} else if (sdkp-DPOFUA  !sdkp-device-use_10_for_rw) {
 			sd_printk(KERN_NOTICE, sdkp,
   Uses READ/WRITE(6), disabling FUA\n);
 			sdkp-DPOFUA = 0;
Index: linux-3.2.60/drivers/usb/storage/scsiglue.c
===
--- linux-3.2.60.orig/drivers/usb/storage/scsiglue.c	2014-06-09 14:29:18.0 +0200
+++ linux-3.2.60/drivers/usb/storage/scsiglue.c	2014-08-29 20:33:40.0 +0200
@@ -255,6 +255,10 @@
 	US_FL_SCM_MULT_TARG)) 
 us-protocol == USB_PR_BULK)
 			us-use_last_sector_hacks = 1;
+
+		/* A few buggy USB-ATA bridges don't understand FUA */
+		if (us-fflags  US_FL_BROKEN_FUA)
+			sdev-broken_fua = 1;
 	} else {
 
 		/* Non-disk-type devices don't need to blacklist any pages
Index: linux-3.2.60/drivers/usb/storage/unusual_devs.h
===
--- linux-3.2.60.orig/drivers/usb/storage/unusual_devs.h	2014-06-09 14:29:18.0 +0200
+++ linux-3.2.60/drivers/usb/storage/unusual_devs.h	2014-08-29 20:25:58.0 +0200
@@ -1916,6 +1916,13 @@
 		USB_SC_DEVICE, USB_PR_DEVICE, NULL,
 		US_FL_IGNORE_RESIDUE ),
 
+/* Reported by Michael Büsch m...@bues.ch */
+UNUSUAL_DEV(  0x152d, 0x0567, 0x0114, 0x0114,
+		JMicron,
+		USB to ATA/ATAPI Bridge,
+		USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+		US_FL_BROKEN_FUA ),
+
 /* Reported by Alexandre Oliva ol...@lsd.ic.unicamp.br
  * JMicron responds to USN and several other SCSI ioctls with a
  * residue that causes subsequent I/O requests to fail.  */
Index: linux-3.2.60/include/linux/usb_usual.h
===
--- linux-3.2.60.orig/include/linux/usb_usual.h	2014-06-09 14:29:18.0 +0200
+++ linux-3.2.60/include/linux/usb_usual.h	2014-08-29 20:28:18.0 +0200
@@ -64,7 +64,9 @@
 	US_FLAG(NO_READ_CAPACITY_16,	0x0008)		\
 		/* cannot handle READ_CAPACITY_16 */		\
 	US_FLAG(INITIAL_READ10,	0x0010)			\
-		/* Initial READ(10) (and others) must be retried */
+		/* Initial READ(10) (and others) must be retried */ \
+	US_FLAG(BROKEN_FUA,	0x0100)			\
+		/* Cannot handle FUA in WRITE or READ CDBs */	\
 
 #define US_FLAG(name, value)	US_FL_##name = value ,
 enum { US_DO_ALL_FLAGS };
Index: linux-3.2.60/include/scsi/scsi_device.h
===
--- linux-3.2.60.orig/include/scsi/scsi_device.h	2014-06-09 14:29:18.0 +0200
+++ linux-3.2.60/include/scsi/scsi_device.h	2014-08-29 20:32:53.0 +0200
@@ -151,6 +151,7 @@
 	unsigned no_read_disc_info:1;	/* Avoid READ_DISC_INFO cmds */
 	unsigned no_read_capacity_16:1; /* Avoid READ_CAPACITY_16 cmds */
 	unsigned is_visible:1;	/* is the device visible in sysfs */
+	unsigned broken_fua:1;		/* Don't set FUA bit */
 
 	DECLARE_BITMAP(supported_events, SDEV_EVT_MAXBITS); /* supported events */
 	struct list_head event_list;	/* asserted events */

Bug#743704: python-setuptools fails to install

2014-04-05 Thread Michael Büsch

Package: python-setuptools
Version: 3.3-1
Severity: important

python-setuptools fails to install with the following messages:

 Preparing to unpack .../python-setuptools_3.4.1-1_all.deb ...
 Unpacking python-setuptools (3.4.1-1) over (3.3-1) ...
 dpkg: error processing archive /var/cache/apt/archives/python-
setuptools_3.4.1-1_all.deb (--unpack):
  trying to overwrite '/usr/lib/python2.7/dist-packages/build', which is also
in package python-pyaudio 0.2.7-2+b1
 dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
 E: Sub-process /usr/bin/dpkg returned an error code (1)



-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages python-setuptools depends on:
iu  python-pkg-resources  3.4.1-1
pn  python:anynone

python-setuptools recommends no packages.

python-setuptools suggests no packages.

-- no debconf information


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

Bug#741049: tmux: C-b C-c no longer starts new window in CWD

2014-03-23 Thread Michael Büsch

Hallo,

What about adding a default configuration to /etc/tmux.conf
that brings back the old behavior?
Or if that's not desired, please add an example configuration
to /usr/share/doc/tmux/examples/ that brings back the feature.
This would save users part of the trouble in search for a fix.

As-is, this clearly is a regression. A useful and very visible feature,
that used to work well in previous releases, suddenly disappeared.

Greetings, Michael.


signature.asc
Description: PGP signature

Bug#741049: tmux: C-b C-c no longer starts new window in CWD

2014-03-23 Thread Michael Büsch

On Sun, 23 Mar 2014 20:01:14 +0100
Romain Francoise rfranco...@debian.org wrote:

 It's not Debian's place to decide defaults...

It's Debian's place to decide Debian-defaults, though.

  Or if that's not desired, please add an example configuration
  to /usr/share/doc/tmux/examples/ that brings back the feature.
  This would save users part of the trouble in search for a fix.
 
 There are examples of how to use the new way in the upstream changelog
 already,

An upstream changelog is not exactly the place where the _user_ would expect
information about required configuration changes on a debian package,
to restore a feature that suddenly stopped working.
From the user's point of view a feature suddenly just broke. And
to the user that looks like a bug. So there should be an easy and
quick way to get information on it, without digging through upstream changelogs.

 But maybe a FAQ entry would make sense.

Yes, please document that somewhere with example config snippets to
get the old behavior back.

 And as the person who implemented it in
 the first place[1], I think the new way to do things is much better.

Well, and as the user, who uses it in the first place, I think the
old way was just fine. ;)

-- 
Greetings, Michael.


signature.asc
Description: PGP signature

Bug#728876: qemu: smbd forked by qemu uses global directory /var/run/samba/ncalrpc

2013-11-06 Thread Michael Büsch

Package: qemu
Version: 1.6.0+dfsg-2
Severity: normal
Tags: patch

The smbd forked by qemu still uses the default ncalrpc directory
in /var/run/samba. This may lead to problems, if the directory
does not exist (for example if /var/run is a tmpfs and the host
smbd was not started).

This leads to the following error message from samba
and an unworkable smbd:
Failed to create pipe directory /var/run/samba/ncalrpc - No such file
or directory

The attached patch fixes this by pointing smbd to /tmp/qemu-smb.%d.%d/ncalrpc
as ncalrpc directory.
Smbd will create the actual ncalrpc subdirectory on its own.

Using a private directory also avoids possible clashes with the system-smbd.



-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.11-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages qemu depends on:
ii  qemu-system  1.6.0+dfsg-2
ii  qemu-user1.6.0+dfsg-2
ii  qemu-utils   1.6.0+dfsg-2

qemu recommends no packages.

Versions of packages qemu suggests:
pn  qemu-user-static  none

-- no debconf information
From: Michael Buesch m...@bues.ch
Subject: [PATCH] slirp/smb: Move ncalrpc directory to tmp

The smbd forked by qemu still uses the default ncalrpc directory
in /var/run/samba. This may lead to problems, if /var/run/samba
does not exist (for example if /var/run is a tmpfs and the host
smbd was not started).

This leads to the following error message from samba
and an unworkable smbd:
	Failed to create pipe directory /var/run/samba/ncalrpc - No such file or directory

Fix this by pointing smbd to /tmp/qemu-smb.%d.%d/ncalrpc as ncalrpc directory.
Smbd will create the actual ncalrpc subdirectory on its own.

Signed-off-by: Michael Buesch m...@bues.ch

---

Index: qemu-1.6.0+dfsg/net/slirp.c
===
--- qemu-1.6.0+dfsg.orig/net/slirp.c
+++ qemu-1.6.0+dfsg/net/slirp.c
@@ -527,6 +527,7 @@ static int slirp_smb(SlirpState* s, cons
 pid directory=%s\n
 lock directory=%s\n
 state directory=%s\n
+ncalrpc dir=%s/ncalrpc\n
 log file=%s/log.smbd\n
 smb passwd file=%s/smbpasswd\n
 security = user\n
@@ -539,6 +540,7 @@ static int slirp_smb(SlirpState* s, cons
 s-smb_dir,
 s-smb_dir,
 s-smb_dir,
+s-smb_dir,
 s-smb_dir,
 s-smb_dir,
 s-smb_dir,

Bug#727756: qemu: Broken -smb with latest SAMBA package. (Unsupported security=share option)

2013-11-01 Thread Michael Büsch

On Fri, 01 Nov 2013 13:32:49 +0400
Michael Tokarev m...@tls.msk.ru wrote:

 That looks right.  Are you okay adding your Signed-off-by to the patch
 you initially submitted?  If yes, I'll make a formal patch submission
 upstream.

Here you go.
From: Michael Buesch m...@bues.ch
Subject: [PATCH] qemu/slirp: Fix SMB security configuration on newer samba versions

The smb.conf automatically generated by qemu's -smb option fails on current
samba, because smbd rejects the security=share option with the following warning:

   WARNING: Ignoring invalid value 'share' for parameter 'security'  

Which makes it fall back to security=user without guest login.
This results in being unable to login to the samba server from the guest OS.

This fixes it by selecting 'user' explicitly and mapping
unknown users to guest logins.

Signed-off-by: Michael Buesch m...@bues.ch

---

Index: qemu-1.6.0+dfsg/net/slirp.c
===
--- qemu-1.6.0+dfsg.orig/net/slirp.c
+++ qemu-1.6.0+dfsg/net/slirp.c
@@ -529,7 +529,8 @@ static int slirp_smb(SlirpState* s, cons
 state directory=%s\n
 log file=%s/log.smbd\n
 smb passwd file=%s/smbpasswd\n
-security = share\n
+security = user\n
+map to guest = Bad User\n
 [qemu]\n
 path=%s\n
 read only=no\n

signature.asc
Description: PGP signature

Bug#727756: qemu: Broken -smb with latest SAMBA package. (Unsupported security=share option)

2013-10-26 Thread Michael Büsch

Package: qemu
Version: 1.6.0+dfsg-2
Severity: normal
Tags: patch

The smb.conf automatically generated by qemu's -smb option fails on current
samba,
because smbd rejects the security=share option with the following warning:

   WARNING: Ignoring invalid value 'share' for parameter 'security'

Which makes it fall back to security=user without guest login.
This results in being unable to login to the samba server from the guest OS.

The attached patch fixes this by selecting 'user' explicitly and mapping
unknown users to guest logins.



-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.11-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages qemu depends on:
ii  qemu-system  1.6.0+dfsg-2
ii  qemu-user1.6.0+dfsg-2
ii  qemu-utils   1.6.0+dfsg-2

qemu recommends no packages.

Versions of packages qemu suggests:
pn  qemu-user-static  none

-- no debconf information
Index: qemu-1.6.0+dfsg/net/slirp.c
===
--- qemu-1.6.0+dfsg.orig/net/slirp.c
+++ qemu-1.6.0+dfsg/net/slirp.c
@@ -529,7 +529,8 @@ static int slirp_smb(SlirpState* s, cons
 state directory=%s\n
 log file=%s/log.smbd\n
 smb passwd file=%s/smbpasswd\n
-security = share\n
+security = user\n
+map to guest = Bad User\n
 [qemu]\n
 path=%s\n
 read only=no\n

Bug#727756: qemu: Broken -smb with latest SAMBA package. (Unsupported security=share option)

2013-10-26 Thread Michael Büsch

On Sat, 26 Oct 2013 13:19:29 +0400
Michael Tokarev m...@tls.msk.ru wrote:

 Thank you for the report and the patch Michael.  Are you sure the result
 is equivalent?

Well, I am far from being an SMB expert. So I can't really say whether this
is equivalent.
I also posted this patch to the qemu-devel list, but didn't get a reply, yet.

I tested this with a Windows XP client. Without this patch the
client will always ask for username and password. Which I am unable to
supply (smbpasswd is empty after all).
With this patch applied, the share works without authentication. And this
is how it used to work in previous versions, too.

 explicitly says that guest is okay, and forces user to the
 right one.  And it should work the same with other versions
 of samba too.

I only tried this with smbd from sid.
My guess is that it would work on older versions, too. But that is
untested.

 Also, which users are bad -- will it be possible for our
 user to clash with some built-in/known user?

'bad users seem to be users that are not in the smbpasswd file.
As qemu creates an empty smbpasswd file, all users probably are bad.
But I'm not sure if there are exceptions to that.

 Cc'ing qemu-devel@ because this needs to be resolved
 upstream too.


signature.asc
Description: PGP signature

Bug#727707: spice-client-gtk: spicy crashes with assertion `palette != NULL' failed

2013-10-25 Thread Michael Büsch

Package: spice-client-gtk
Version: 0.21-0nocelt2
Severity: important

Dear Maintainer,

spicy often crashes with the following error message:

spice-ERROR **: pixman_utils.c:1343:bitmap_1be_32_to_32: assertion
`palette != NULL' failed



-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.11-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages spice-client-gtk depends on:
ii  libatk1.0-0 2.10.0-2
ii  libc6   2.17-93
ii  libcairo2   1.12.16-2
ii  libfontconfig1  2.11.0-1
ii  libfreetype62.4.9-1.1
ii  libgdk-pixbuf2.0-0  2.28.2-1
ii  libglib2.0-02.36.4-1
ii  libgtk2.0-0 2.24.22-1
ii  libjpeg88d-1
ii  libpango-1.0-0  1.36.0-1
ii  libpangocairo-1.0-0 1.36.0-1
ii  libpangoft2-1.0-0   1.36.0-1
ii  libpixman-1-0   0.30.2-1
ii  libpulse-mainloop-glib0 4.0-6+b1
ii  libpulse0   4.0-6+b1
ii  libsasl2-2  2.1.25.dfsg1-17
ii  libspice-client-glib-2.0-8  0.21-0nocelt2
ii  libspice-client-gtk-2.0-4   0.21-0nocelt2
ii  libssl1.0.0 1.0.1e-3
ii  libusb-1.0-02:1.0.17-1+b1
ii  libusbredirhost10.6-2
ii  libusbredirparser1  0.6-2
ii  libx11-62:1.6.2-1
ii  libxrandr2  2:1.4.1-1
ii  zlib1g  1:1.2.8.dfsg-1

spice-client-gtk recommends no packages.

spice-client-gtk suggests no packages.

-- no debconf information


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

Bug#727707: spice-client-gtk: spicy crashes with assertion `palette != NULL' failed

2013-10-25 Thread Michael Büsch

A workaround to the issue is to downgrade spice-client-gtk to version 
0.20-0nocelt3.

I installed the following old packages:
libspice-client-glib-2.0-8_0.20-0nocelt3_amd64.deb
libspice-client-gtk-2.0-4_0.20-0nocelt3_amd64.deb
spice-client-glib-usb-acl-helper_0.20-0nocelt3_amd64.deb
spice-client-gtk_0.20-0nocelt3_amd64.deb


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

Bug#657109: nm fails for ipv6

2012-02-15 Thread Michael Büsch

I also see this since I did a safe-upgrade on sid today and rebooted the 
machine.
nm is unable to establish the wireless link, unless ipv6 is disabled.
Even unchecking Require IPv6 addressing for this connection to complete 
doesn't help.
Only disabling IPv6 on the link seems to be a workaround to the issue.

Syslog shows this:
Feb 15 12:26:04 milhouse NetworkManager[2134]: error [1329305164.622525] 
[nm-system.c:1061] nm_system_replace_default_ip6_route(): (wlan0): failed to 
set IPv6 default route: -1

The IPv6 setting was set to automatic.

-- 
Greetings, Michael.



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

Bug#655242: ext4: Warning at ext4 inode.c:885

2012-01-09 Thread Michael Büsch

On Mon, 09 Jan 2012 18:34:32 +0100
Michael Buesch m...@bues.ch wrote:

 The ext4 filesystem in question is the rootfs on a LUKS encrypted partition.
 The machine had at least one s2disk (uswsusp) cycle before this happened. But 
 this probably doesn't matter. Just for completeness.

Hm, now that I think about it...
It may actually be PEBCAK.
The ext4 filesystem was mounted (from another system) read-only, but without 
the -o noload option,
while the system was suspended. This may not be a valid thing to do, as far as 
I can see.
So you may drop this bug, if you think it was caused by this.

-- 
Greetings, Michael.



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

Bug#645208: tint2: Crashes on xrandr --output XXX --off

2011-10-14 Thread Michael Büsch

On Sat, 15 Oct 2011 00:30:15 +0200
Sebastian Reichel s...@debian.org wrote:

 Can you please attach your ~/.config/tint2/tint2rc? I can't
 reproduce the error with my own tint2 configuration.

I'm running two machines (both sid/amd64) with identical tint2 configs (the 
attached).
On one machine it crashes and on the other it doesn't.

Just in case it matters:
The machine that crashes runs a fairly recent radeon-git driver with mesa-git.
It's a radeon HD (cedar) card.
The non-crashing machine uses standard debian intel-video.

 Removing the screen results in a tint2 reload. I guess the following
 command also results in a crash of tint2 on your system?
 
   kill -SIGUSR1 `pidof tint2`

yep. But only on the one machine where it crashes otherwise, too.
The valgrind backtrace is similar.

-- 
Greetings, Michael.


tint2rc
Description: Binary data

Bug#588196: b43: does not join multicast groups

2010-07-15 Thread Michael Büsch


On 07/15/2010 10:51 AM, Simon Richter wrote:

The same applies to receiving. The RX queue is also dropped on switch
from DMA to PIO.


Sure, but the packet is repeated every ten seconds. The problem is that
none of those packets is received, even long after the switch to PIO.


The filter flags are not updated because (as I already said) the reinit
happens without mac80211's knowledge.


The actual switch from DMA to PIO mode completely reinitializes
the hardware and drops all queues.


Would it be possible to reinitialize the multicast filter at this point?


Yeah everything is possible.
I'd rather like to see the actual _problem_ fixed instead of
continuing to waste hours and hours on the hackish workaround.
So in the end the workaround (aka PIO fallback) can be removed.

If this problem is fixed, the next one will show up. (For example
the fact that the PIO fallback won't work on an AP, too, for these
reasons).

Please work on fixing up the PCI core code, which most likely
causes the problem, instead of extending the workaround hack.

--
Greetings Michael.



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

Bug#588196: b43: does not join multicast groups

2010-07-14 Thread Michael Büsch


On 07/14/2010 09:50 AM, Simon Richter wrote:

Hi,

On Tue, Jul 13, 2010 at 04:05:10PM +0200, Michael Büsch wrote:


So it is up to the upper layer to detect the failure. I don't think
it's possible to automatically detect such incidents for multicast
transmissions. So the mechanism fails here.


Well, it is about *receiving* a multicast transmission


The same applies to receiving. The RX queue is also dropped on switch
from DMA to PIO.


advertisement, sent to 33:33:00:00:00:01). I have no idea where the
packet is dropped; from my somewhat limited understanding of 802.11, I'd
expect the frames to be treated like broadcast frames by the AP, so it'd
be the receiver dropping them in the MAC filter.


The actual switch from DMA to PIO mode completely reinitializes
the hardware and drops all queues.

--
Greetings Michael.



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

Bug#588196: b43: does not join multicast groups

2010-07-13 Thread Michael Büsch


On 07/13/2010 09:37 AM, Simon Richter wrote:

That appears to work, at least I have v6 addresses now.

Unlike before, you now have communication.

Well, v4 worked fine before. :)


That's very nice.
But I wanna say again that this all is expected behavior. The PIO
fallback workaround randomly drops packets when switching modes.
So it is expected that certain handshaking packages may be lost.

It's just a hackish workaround. No more, but also no less.


I was also having some suspend related issues, I'm going to give it a
few days now to see whether they also disappear now.


Please open a new bug for this. Thanks.

--
Greetings Michael.



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

Bug#588196: b43: does not join multicast groups

2010-07-13 Thread Michael Büsch


On 07/13/2010 03:06 PM, Simon Richter wrote:

Hi,

On Tue, Jul 13, 2010 at 03:00:00PM +0200, Michael Büsch wrote:


But I wanna say again that this all is expected behavior. The PIO
fallback workaround randomly drops packets when switching modes.
So it is expected that certain handshaking packages may be lost.


So if the handshake to join a MC group is lost for whatever reason, it
is lost forever, or is that just in the shit happened, reset
everything code path?


It's not entirely possible to answer that question from a b43 point of view.
What happens in b43 is:
It tries to transmit through DMA. If that fails, it drops all queued
packets (but does not tell any upper layer about that) and resets the
hardware to PIO mode and waits for further work.
So it is up to the upper layer to detect the failure. I don't think
it's possible to automatically detect such incidents for multicast
transmissions. So the mechanism fails here.


I was also having some suspend related issues, I'm going to give it a
few days now to see whether they also disappear now.



Please open a new bug for this. Thanks.


If they keep appearing; this may also be related to lost packets.


I'm pretty sure that any suspend issue is not related to the PIO
fallback mechanism.

--
Greetings Michael.



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

37 matches

Mail list logo