Bug#883939: smbclient failing to connect with default protocol SMB3_11

[David Sanders]

As an update, I still have this behavior on my stretch machine running 
smbclient version 4.5.16+dfsg-1+deb9u2. However, on an installation of 
buster running smbclient version 4.9.5+dfsg-5, I do not have the bug.


The two installations are not identical however. The stretch machine is 
a server and the buster machine just has smbclient installed.


It may be that "my" bug is different than the originally reported 
problem in any case.


David

Bug#926450: spurious error "gzip: stdout: Permission denied"

[David Sanders]

This bug appears to be caused by the installed apparmor profile for 
man-db in buster. If you are the root user and/or /usr/bin/man has been 
configured as setuid and there are cat? directories in /var/cache/man, 
then man will try to write a cat page to those directories but will be 
prevented by apparmor.


The apparmor profile should be set so that the various filters like gzip 
can write to /var/cache/man/**. This would stop the error from appearing 
when logged in as root or /usr/bin/man configured as setuid.



David

Bug#916997: clang-tidy: manpage is empty (bug #916997)

[David Sanders]

Dear maintainer,

Actually more than just the clang-tidy-7 manpage is blank in Buster.

All of the following llvm/clang manpages are empty files:

clang-apply-replacement-7
clang-check-7
clang-include-fixer-7
clang-query-7
clang-rename-7
clang-reorder-fields-7
clang-tidy-7
lli-7
llvm-dwarfdump-7
llvm-mc-7
llvm-mcmarkup-7
llvm-objdump-7
llvm-ranlib-7
llvm-rtdyld-7
llvm-size-7
modularize-7
sancov-7

In addition, lld.1.gz is a dangling link (ie lld-7.1.gz is not present).

Please rebuild the relevant packages so that these manpages will be 
generated.


I suspect the severity should be higher than minor.

Thank you,

David

Bug#883939: Reproduce " smbclient failing to connect with default protocol SMB3_11"

[David Sanders]

Mattieu,

I just tried connecting to a Windows 10 machine with and without the
"client max protocol = SMB3_10" directive in my smb.conf.

I can connect without a problem with the directive present, however when
I comment it out I get the following error message:

protocol negotiation failed: NT_STATUS_CONNECTION_RESET

So either there's a bug with this version or something is screwy with
the configuration on the Windows machine. It's not a big problem for me
because the work around fixes it.

I am running stretch 9.8 with samba 2:4.5.16+dfsg-1

David

On 2/18/19 7:39 AM, Mathieu Parent wrote:
> Hello all,
>
> Are you able to reproduce this bug on latest stretch (2:4.5.16+dfsg-1)
> and/or latest buster (2:4.9.4+dfsg-3, -2 is ok).
>
> Regards

Bug#898630: enigmail: efail attack against enigmail

[David Sanders]

I think this bug applies to Thunderbird as well as Enigmail and both 
packages need urgent updates.


The Enigmail part can be corrected by updating to version 2.0.3, but the 
user will still be vulnerable until a new version of Thunderbird is 
released and pushed out to users. Long term the openPGP standard needs 
to be updated to address the issue.


Could the maintainers of Enigmail take for action updating to the 
already released 2.0.3? And forwarding the bug to Thunderbird for 
further action?


Thanks,
David

On Mon, 14 May 2018 15:15:26 +0200 Yves-Alexis Perez  
wrote:

> Package: enigmail
> Severity: grave
> Tags: security
> Justification: user security hole
>
> Hi Daniel,
>
> in case you haven't already heard about it by now, a vulnerability has
> been published against S/MIME and PGP/MIME in various email clients,
> including thunderbird (and enigmail).
>
> I'm unsure if CVE-2017-17688 (OpenPGP CFB gadget attacks) applies
> to Thunderbird/enigmail or only GnuPG, but the PGP/MIME vulnerability
> does apply to enigmail.
>
> Some fixes apparently went in to enigmail 2.0.0 but I'm unsure which of
> them yet, so any pointers appreciated (for example by closing with the
> correct version number :).
>
> I think we'll likely want to release a DSA too.
>
> Regards,
> --
> Yves-Alexis

Bug#894520: [sharutils] shar creates archives that will not extract files if the filename has spaces

[David Sanders]

Package: sharutils
Version: 1:4.15.2-2
Severity: important

--- Please enter the report below this line. ---
Dear maintainer,

shar does not handle filenames with spaces in them if using compression
(ie gzip or xz).  It creates
the archive without comment but then when trying to extract the archive
it fails with an error message.

This is the error message:
x - created lock directory _sh03236.
x - extracting Filename with spaces.txt gzipped
uudecode fatal error:
fserr 2 (No such file or directory) performing 'freopen' on Filename
with _sh03236/gzi
restore of Filename with spaces.txt failed
Filename with spaces.txt: MD5 check failed
x - removed lock directory _sh03236.

I have confirmed that the bug is present in the current upstream version.

The program works correctly with filenames containing spaces if you do
not specify compression.

Thank you

--- System information. ---
Architecture:
Kernel: Linux 4.9.0-6-amd64

Debian Release: 9.4
500 stable-updates ftp.us.debian.org
500 stable security.debian.org
500 stable ftp.us.debian.org
100 stretch-backports ftp.debian.org

--- Package information. ---
Depends (Version) | Installed
==-+-===
libc6 (>= 2.14) |


Package's Recommends field is empty.

Suggests (Version) | Installed
-+-===
sharutils-doc |
bsd-mailx | 8.1.2-0.20160123cvs-4
OR mailx |

Bug#893630: jacksum: java error when trying to verify rmd256 and rmd320 checksums

[David Sanders]

Package: jacksum
Version: 1.7.0-4.1
Severity: normal
Tags: upstream

Dear Maintainer,

When validating a checksum for rmd256 or rmd320 algorithms, jacksum fails due
to a java error.  This bug is present upstream.

The error message is:
java.lang.ArrayIndexOutOfBoundsException: 1

Steps to reproduce:
1. create a rmd320 or rmd256 checksum.
   $ jacksum -x -m -a rmd320 filename > filename.rmd320
2. attempt to verify the checksum
   $ jacksum -c filename.rmd320

The problem does not occur for rmd128 or rmd160.

Thanks



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

Kernel: Linux 4.9.0-6-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)

Versions of packages jacksum depends on:
ii  default-jre  2:1.8-58

jacksum recommends no packages.

jacksum suggests no packages.

-- no debconf information

Bug#883939: smbclient failing to connect with default protocol SMB3_11

[David Sanders]

I am also seeing this same bug in Debian v9.3 stretch.  I have smbclient 
version 4.5.12+dfsg-2+deb9u1.

The fix suggested of setting client "max protocol = SMB3_10" in 
/etc/samba/smb.conf also fixed the problem for me.

I’ll say that I’m specifically connecting to a Windows 10 client with all the 
latest security updates.

Not sure when this problem started but I believe since I upgraded to stretch 
late last year.

I can provide any other info requested.

Thanks

Bug#758121: [Pkg-crosswire-devel] Bug#758121: bibletime: Bibletime is unusable in testing and unstable

[David Sanders]

On Thursday, October 09, 2014 10:55:59 AM Dimitri John Ledkov wrote:
 On 8 October 2014 15:54,  da...@sandersweb.net wrote:
  retitle 758121 bibletime: New upstream release fixes display problem in
  jessie severity 758121 grave
  thanks
  
  On Monday, October 06, 2014 10:26:56 PM you wrote:
  Bibletime is unusable in jessie and sid.  When you open any Bible or
  commentary all you see is jibberish.  This needs to be fixed prior to
  the release of jessie.
  
  I just built the new upstream release (2.10.1) from source.  It does not
  have this problem.  Please update the bibletime package in jessie to the
  latest upstream release available on sourceforge.
 
 Debdiff would be appreciated. I don't use, nor typically updated bibletime.

Dimitri,

I don't have a deb of version 2.10.1 to create a debdiff with.  I think the 
package can be built from source without any patches and with minimum trouble.  
I may try to create a deb but I'm not a debian developer so I may be 
unsuccessful.  Any help would be appreciated.

David


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

Bug#758121: [Pkg-crosswire-devel] Bug#758121: bibletime: Bibletime is unusable in testing and unstable

[David Sanders]

On Thursday, October 09, 2014 10:27:48 AM David Sanders wrote:
 On Thursday, October 09, 2014 10:55:59 AM Dimitri John Ledkov wrote:
  On 8 October 2014 15:54,  da...@sandersweb.net wrote:
   retitle 758121 bibletime: New upstream release fixes display problem in
   jessie severity 758121 grave
   thanks
   
   On Monday, October 06, 2014 10:26:56 PM you wrote:
   Bibletime is unusable in jessie and sid.  When you open any Bible or
   commentary all you see is jibberish.  This needs to be fixed prior to
   the release of jessie.
   
   I just built the new upstream release (2.10.1) from source.  It does not
   have this problem.  Please update the bibletime package in jessie to the
   latest upstream release available on sourceforge.
  
  Debdiff would be appreciated. I don't use, nor typically updated
  bibletime.
 
 Dimitri,
 
 I don't have a deb of version 2.10.1 to create a debdiff with.  I think the
 package can be built from source without any patches and with minimum
 trouble. I may try to create a deb but I'm not a debian developer so I may
 be unsuccessful.  Any help would be appreciated.
 
 David

Alright I built a deb package for version 2.10.1-1.  I've attached your debdiff 
and the debian directory I used.  Let me know if you need anything else.

David
david@deb8vm:~/Downloads$ debdiff bibletime_2.9.2-1.1+b1_amd64.deb 
bibletime/bibletime_2.10.1-1_amd64.deb
[The following lists of changes regard files as different if they have
different names, permissions or owners.]

Files in first .deb but not in second
-
-rw-r--r--  root/root   /usr/share/doc/bibletime/changelog.Debian.amd64.gz

Control files: lines which differ (wdiff format)

Depends: libc6 (= 2.14), libclucene-core1 (= 2.3.3.4), [-libcurl3-gnutls (= 
7.16.2),-] libgcc1 (= 1:4.1.1), libqt4-dbus (= 4:4.5.3), libqt4-network (= 
4:4.5.3), libqt4-xml (= 4:4.5.3), libqt4-xmlpatterns (= 4:4.5.3), libqtcore4 
(= 4:4.8.0), libqtgui4 (= 4:4.8.0), libqtwebkit4 (= 2.1.0~2011week13), 
libstdc++6 (= 4.6), libsword11 (= 1.7.3+dfsg), [-zlib1g (= 1:1.1.4),-] 
libqt4-svg (= 4.4.0), bibletime-data (= [-2.9.2-1.1)-] {+2.10.1-1)+}
Installed-Size: [-2378-] {+2959+}
[-Source: bibletime (2.9.2-1.1)-]
Version: [-2.9.2-1.1+b1-] {+2.10.1-1+}



david@deb8vm:~/Downloads$ debdiff bibletime-data_2.9.2-1.1_all.deb 
bibletime/bibletime-data_2.10.1-1_all.deb 
[The following lists of changes regard files as different if they have
different names, permissions or owners.]

Files in second .deb but not in first
-
-rw-r--r--  root/root   /usr/share/bibletime/docs/handbook/fi/hdbk-config.html
-rw-r--r--  root/root   /usr/share/bibletime/docs/handbook/fi/hdbk-intro.html
-rw-r--r--  root/root   
/usr/share/bibletime/docs/handbook/fi/hdbk-op-bookshelfmanager.html
-rw-r--r--  root/root   
/usr/share/bibletime/docs/handbook/fi/hdbk-op-output.html
-rw-r--r--  root/root   /usr/share/bibletime/docs/handbook/fi/hdbk-op-parts.html
-rw-r--r--  root/root   
/usr/share/bibletime/docs/handbook/fi/hdbk-op-search.html
-rw-r--r--  root/root   /usr/share/bibletime/docs/handbook/fi/hdbk-op.html
-rw-r--r--  root/root   
/usr/share/bibletime/docs/handbook/fi/hdbk-reference-shortcuts.html
-rw-r--r--  root/root   
/usr/share/bibletime/docs/handbook/fi/hdbk-reference-works.html
-rw-r--r--  root/root   
/usr/share/bibletime/docs/handbook/fi/hdbk-reference.html
-rw-r--r--  root/root   
/usr/share/bibletime/docs/handbook/fi/hdbk-start-firstrun.html
-rw-r--r--  root/root   /usr/share/bibletime/docs/handbook/fi/hdbk-term.html
-rw-r--r--  root/root   /usr/share/bibletime/docs/handbook/fi/i_back.png
-rw-r--r--  root/root   /usr/share/bibletime/docs/handbook/fi/i_bible.png
-rw-r--r--  root/root   /usr/share/bibletime/docs/handbook/fi/i_bible_add.png
-rw-r--r--  root/root   /usr/share/bibletime/docs/handbook/fi/i_bibletime.png
-rw-r--r--  root/root   /usr/share/bibletime/docs/handbook/fi/i_book.png
-rw-r--r--  root/root   /usr/share/bibletime/docs/handbook/fi/i_book_add.png
-rw-r--r--  root/root   /usr/share/bibletime/docs/handbook/fi/i_bookmark.png
-rw-r--r--  root/root   /usr/share/bibletime/docs/handbook/fi/i_books.png
-rw-r--r--  root/root   /usr/share/bibletime/docs/handbook/fi/i_cascade.png
-rw-r--r--  root/root   /usr/share/bibletime/docs/handbook/fi/i_checkbox.png
-rw-r--r--  root/root   /usr/share/bibletime/docs/handbook/fi/i_commentary.png
-rw-r--r--  root/root   
/usr/share/bibletime/docs/handbook/fi/i_commentary_add.png
-rw-r--r--  root/root   /usr/share/bibletime/docs/handbook/fi/i_configure.png
-rw-r--r--  root/root   
/usr/share/bibletime/docs/handbook/fi/i_configuresword.png
-rw-r--r--  root/root   /usr/share/bibletime/docs/handbook/fi/i_contents2.png
-rw-r--r--  root/root   
/usr/share/bibletime/docs/handbook/fi/i_displayconfig.png
-rw-r--r--  root/root   
/usr/share/bibletime/docs/handbook/fi/i_document_magnifier.png
-rw-r--r--  root/root   /usr/share/bibletime/docs

Bug#758121: bibletime: Bibletime is unusable in testing and unstable

[David Sanders]

Package: bibletime
Version: 2.9.2-1.1+b1
Followup-For: Bug #758121

Dear Maintainer,

Bibletime is unusable in jessie and sid.  When you open any Bible or 
commentary all you see is jibberish.  This needs to be fixed prior to
the release of jessie.

Please fix.  Thank you.

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

Kernel: Linux 3.16-2-amd64 (SMP w/2 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 bibletime depends on:
ii  bibletime-data  2.9.2-1.1
ii  libc6   2.19-11
ii  libclucene-core12.3.3.4-4
ii  libcurl3-gnutls 7.38.0-2
ii  libgcc1 1:4.9.1-16
ii  libqt4-dbus 4:4.8.6+git64-g5dc8b2b+dfsg-2
ii  libqt4-network  4:4.8.6+git64-g5dc8b2b+dfsg-2
ii  libqt4-svg  4:4.8.6+git64-g5dc8b2b+dfsg-2
ii  libqt4-xml  4:4.8.6+git64-g5dc8b2b+dfsg-2
ii  libqt4-xmlpatterns  4:4.8.6+git64-g5dc8b2b+dfsg-2
ii  libqtcore4  4:4.8.6+git64-g5dc8b2b+dfsg-2
ii  libqtgui4   4:4.8.6+git64-g5dc8b2b+dfsg-2
ii  libqtwebkit42.3.4.dfsg-2
ii  libstdc++6  4.9.1-16
ii  libsword11  1.7.3+dfsg-2
ii  zlib1g  1:1.2.8.dfsg-2

bibletime recommends no packages.

bibletime 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#763892: aspell-en needs to be Multi-Arch: foreign

[David Sanders]

Package: aspell-en
Version: 7.1-0-1
Severity: normal

Dear Maintainer,

Aspell is now multi-arch in sid.  Associated aspell-xx dictionary
packages need to be Multi-Arch: foreign in accordance with debian
policy for library support files.  Currently apt-get doesn't
recognize aspell-en as an installation candidate on an amd64
system with i386 foreign arch when installing aspell:i386.  This
results in an incorrect dictionary being installed.



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

Kernel: Linux 3.16-2-amd64 (SMP w/2 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 aspell-en depends on:
ii  aspell   0.60.7~20110707-1.2
ii  dictionaries-common  1.23.12

aspell-en recommends no packages.

aspell-en 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#763892: aspell-en needs to be Multi-Arch: foreign

[David Sanders]

-Original Message-
From: Agustin Martin [mailto:agmar...@debian.org] 
Sent: Friday, October 03, 2014 12:54 PM
To: David Sanders; 763...@bugs.debian.org
Subject: Re: Bug#763892: aspell-en needs to be Multi-Arch: foreign

The problem I see above is in aspell-no, which does not use
aspell-autobuildhash, and is an arch:any package that might not work with
multiarch. In this particular case, pulled aspell-no:i386 will use 32 bit
sizes and is usable with libaspell15:amd64, but aspell-no:amd64 will not
work with current aspell because it was built with 64 bit numbers 

IIRC, Debian aspell maintainer, Brian Nelson, set as policy that all aspell
dictionaries must be automatically built at postinst stage, but do not have
the reference here. 

I am cloning this bug report to aspell-no. I think it should use
aspell-autobuildhash. As a lesser evil, should be rebuilt with new aspell
to make sure 32 bit numbers are always used in hash creation and set
appropriate versioned dependency on aspell, although might show some exotic
behavior during installation, like the one seen above.

We might later conclude that all aspell:all dicts need to be set as
Multi-Arch: foreign, but we should discard aspell-no influence first.


You have identified an additional problem that I did not see.  That is that
aspell-no is not compatible with multi-arch as it stands right now.  This
problem also applies to aspell-da which has the same problem.  Bugs with
important priority need to be filled against these two packages to they
can be fixed before the next release.

But back to aspell-en.  I stand behind my theory that aspell-en and the
other aspell-xx packages need to be Multi-Arch: foreign.  I should have
stated in my original bug report that this was my THEORY.  I guess I didn't
have my morning coffee.

According to:
https://wiki.debian.org/Multiarch/Implementation#Multi-Arch:_foreign_support
_packages
A runtime support package such as a dictionary must be marked Multi-Arch:
foreign.

According to https://wiki.ubuntu.com/MultiarchSpec
The package manager (apt-get) will only install a runtime support package to
satisfy a dependency for a foreign architecture if it is marked Multi-Arch:
foreign.

So an apt-get install libaspell15:i386 installs the Norwegian dictionary
aspell-no:i386 because aspell-en (and the other aspell-xx packages) are not
eligible to satisfy the dependency on an aspell dictionary due to the lack
of Multi-Arch: foreign.

To illustrate, consider:
david@deb8vm:~/Downloads/aspell$ apt-cache depends libaspell15:i386
libaspell15:i386
  Depends: libc6:i386
  Depends: libgcc1:i386
  Depends: libstdc++6:i386
  PreDepends: multiarch-support:i386
multiarch-support
  Suggests: aspell:i386
 |Recommends: aspell-en:i386
 |Recommends: aspell-dictionary:i386
  Recommends: aspell6a-dictionary:i386
aspell-da:i386
aspell-no:i386
  Conflicts: aspell6-dictionary
  Conflicts: aspell6-dictionary:i386
  Breaks: aspell-bin
  Breaks: aspell-bin:i386
  Replaces: libaspell15
  Breaks: libaspell15

As you can see there is no install candidate for aspell-en or
aspell-dictionary.  We have only aspell-da:i386 and aspell-no:i386.  Apt-get
installs aspell-no:i386.

Compare this situation with this:
david@deb8vm:~/Downloads/aspell$ apt-cache depends libaspell15
libaspell15
  Depends: libc6
  Depends: libgcc1
  Depends: libstdc++6
  PreDepends: multiarch-support
multiarch-support:i386
  Suggests: aspell
aspell:i386
 |Recommends: aspell-en
 |Recommends: aspell-dictionary
aspell-am
aspell-ar
aspell-ar-large
aspell-bg
aspell-br
aspell-ca
aspell-cs
aspell-cy
aspell-de
aspell-de-alt
aspell-el
aspell-en
aspell-eo
aspell-eo-cx7
aspell-es
aspell-et
aspell-eu-es
aspell-fa
aspell-fo
aspell-fr
aspell-ga
aspell-gl-minimos
aspell-he
aspell-hr
aspell-hsb
aspell-hu
aspell-hy
aspell-is
aspell-it
aspell-kk
aspell-ku
aspell-lt
aspell-lv
aspell-nl
aspell-pl
aspell-pt-br
aspell-pt-pt
aspell-ro
aspell-ru
aspell-sk
aspell-sl
aspell-sv
aspell-tl
aspell-uk
aspell-uz
  Recommends: aspell6a-dictionary
aspell-da
aspell-no
  Conflicts: aspell6-dictionary
  Conflicts: aspell6-dictionary:i386
  Breaks: aspell-bin
  Breaks: aspell-bin:i386
  Replaces: libaspell15:i386
  Breaks: libaspell15:i386

As you see aspell-en and aspell-xx are listed as install candidates for the
64-bit libaspell15 library support files.  The problem only involves trying
to install the 32-bit library on a 64-bit system.

The same problem reappears trying to install libenchant1c2a:i386.  In this
case there is no aspell install candidate at all (since it doesn't depend on
the Norwegian and Danish dictionaries) and the result is that apt-get
installs iukrainian:i386.  The problem is not with iukrainian but rather
with the aspell dictionaries.

Hope this helps.  This is only a one line change in the spec

Bug#667592: libaspell15: multiarch problem

[David Sanders]

On Sep 27, 2014, at 3:17 PM, Agustin Martin agmar...@debian.org wrote:
..
 Uploaded 0.60.7~20110707-1.2~exp3 to experimental. Should work around
 that recreation using the original pristine file. It has gone through
 autobuilders and should already be available in experimental mirrors.
 diff against exp1 experimental upload is attached for maintainer info.
 
 After the upload I noticed a couple of minor things pending, but that
 should not affect multiarch behavior. Will add them before uploading
 the real NMU.
 
 If you want to test things like aspell:i386 in an amd64 box you willl
 also need last dictionaries-common version (1.23.12), already uploaded
 to sid.
..


I installed the new experimental version of aspell.  libaspell15:i386 also 
installed on my amd64 system.  However apt-get insisted on also installing 
aspell-no.  This was unexpected.  I have aspell-en installed and don’t need a 
Norwegian dictionary but I went ahead and let it install.  

My system doesn’t pull in packages from unstable so I couldn’t install 
aspell:i386 or the new dictionaries-common.  So for testing I tried to install 
libenchant1c2a:i386.  It won’t install either, perhaps for the same reasons, 
but someone should probably check.

For testing I installed xmlcopyeditor:i386 which depends on libaspell15:i386.  
It installed and I successfully spell checked an xml document.  So I would say 
that things are working.  More testing needs to be done and once 
dictionaries-common makes it to the testing repository I’ll do more.

Thanks,

David


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

Bug#667592: libaspell15: multiarch problem

[David Sanders]

I installed the experimental aspell on my amd64 system and it seems to work 
fine.  However, I’ve been unable to install the i386 library for testing.  I 
get the following error:


david@jessie:~$ sudo apt-get -t experimental install libaspell15:i386
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Suggested packages:
  aspell:i386
Recommended packages:
  aspell-en:i386 aspell-dictionary:i386 aspell6a-dictionary:i386
The following NEW packages will be installed:
  libaspell15:i386
0 upgraded, 1 newly installed, 0 to remove and 206 not upgraded.
Need to get 0 B/360 kB of archives.
After this operation, 2,290 kB of additional disk space will be used.
(Reading database ... 400234 files and directories currently installed.)
Preparing to unpack .../libaspell15_0.60.7~20110707-1.2~exp1_i386.deb ...
Unpacking libaspell15:i386 (0.60.7~20110707-1.2~exp1) ...
dpkg: error processing archive 
/var/cache/apt/archives/libaspell15_0.60.7~20110707-1.2~exp1_i386.deb 
(--unpack):
 trying to overwrite shared '/usr/share/doc/libaspell15/changelog.html.gz', 
which is different from other instances of package libaspell15:i386
Errors were encountered while processing:
 /var/cache/apt/archives/libaspell15_0.60.7~20110707-1.2~exp1_i386.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
david@jessie:~$ 


It seems there is a conflict with a previously installed file.  Thanks for your 
work on this.


David



On Sep 15, 2014, at 6:21 AM, Agustin Martin agmar...@debian.org wrote:
 
 Hi,
 
 pre-NMU uploaded to experimental.
 
 Testing is appreciated. I am cc'ing all contributors to this bug report.
 
 Thanks in advance for the feedback.
 
 -- 
 Agustin


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

Bug#667592: libaspell15: multiarch problem

[David Sanders]

 I am writing as dictionaries-common maintainer (not aspell maintainer)
 since some things here are related to the common dictionaries support
 for aspell dictionary hashes autobuild.
 
 The problem behind is that dictionary hashes are arch dependent, and
 IIRC, this is not only about endianness. Currently, hashes are
 auto-generated at postinst stage for most dictionaries, which are
 arch:all. This way we keep our archive smaller and any possible change
 in hash format automatically triggers a hash rebuild for all
 dictionaries using this model making transitions painless.
 
 Unfortunately, this is not very multiarch-friendly.

The dictionary hashes depend on two things endianness and the size_t
for the architechture.  The upstream authors recognized this as a 
problem on systems with 32-bit and 64-bit code and have a workaround.
See here:

http://aspell.net/0.61/man-html/Using-32_002dBit-Dictionaries-on-a-64_002dBit-System.html

All that is required is to use a configure time flag to cause aspell to always
use a 32-bit number in the hash.  Then for example the i386 and amd64
architectures (and other combinations where the endianness is the same)
can be configured for multiarch support.

This could be done relatively simpley for jessie.

Please consider.


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

Bug#500846: linux-image-2.6.26-1-686: Kernel will not boot in Virtual PC

[David Sanders]

Subject: linux-image-2.6.26-1-686: Kernel will not boot in Virtual PC
Package: linux-image-2.6.26-1-686
Version: 2.6.26-5
Severity: important
Tags: patch

*** Please type your report below this line ***
Kernel will not boot in Virtual PC due to introduction of multi-byte
nops.  Problem has been fixed upstream for 2.6.27.  I am including patch
to fix problem in 2.6.26-1-686.

-- Package-specific info:

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

Kernel: Linux 2.6.27-rc8.local2 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages linux-image-2.6.26-1-686 depends on:
ii  debconf [debconf-2.0] 1.5.22 Debian configuration management sy
ii  initramfs-tools [linux-initra 0.92j  tools for generating an initramfs
ii  module-init-tools 3.4-1  tools for managing Linux kernel mo

Versions of packages linux-image-2.6.26-1-686 recommends:
ii  libc6-i6862.7-13 GNU C Library: Shared libraries [i

Versions of packages linux-image-2.6.26-1-686 suggests:
ii  grub  0.97-47GRand Unified Bootloader (Legacy v
pn  linux-doc-2.6.26  none (no description available)

-- debconf information:
  linux-image-2.6.26-1-686/preinst/abort-overwrite-2.6.26-1-686:
  shared/kernel-image/really-run-bootloader: true
  linux-image-2.6.26-1-686/postinst/bootloader-error-2.6.26-1-686:
  linux-image-2.6.26-1-686/postinst/depmod-error-initrd-2.6.26-1-686: false
  linux-image-2.6.26-1-686/prerm/removing-running-kernel-2.6.26-1-686: true
  linux-image-2.6.26-1-686/postinst/old-system-map-link-2.6.26-1-686: true
  linux-image-2.6.26-1-686/preinst/abort-install-2.6.26-1-686:
  linux-image-2.6.26-1-686/preinst/lilo-has-ramdisk:
  linux-image-2.6.26-1-686/preinst/bootloader-initrd-2.6.26-1-686: true
  linux-image-2.6.26-1-686/prerm/would-invalidate-boot-loader-2.6.26-1-686: true
  linux-image-2.6.26-1-686/preinst/elilo-initrd-2.6.26-1-686: true
  linux-image-2.6.26-1-686/postinst/kimage-is-a-directory:
  linux-image-2.6.26-1-686/postinst/old-dir-initrd-link-2.6.26-1-686: true
  linux-image-2.6.26-1-686/postinst/create-kimage-link-2.6.26-1-686: true
  linux-image-2.6.26-1-686/preinst/lilo-initrd-2.6.26-1-686: true
  linux-image-2.6.26-1-686/postinst/old-initrd-link-2.6.26-1-686: true
  linux-image-2.6.26-1-686/preinst/overwriting-modules-2.6.26-1-686: true
  linux-image-2.6.26-1-686/postinst/depmod-error-2.6.26-1-686: false
  linux-image-2.6.26-1-686/postinst/bootloader-test-error-2.6.26-1-686:
  linux-image-2.6.26-1-686/preinst/failed-to-move-modules-2.6.26-1-686:
  linux-image-2.6.26-1-686/preinst/initrd-2.6.26-1-686:
From 14469a8dd23677921db5e7354a602c98d9c6300f Mon Sep 17 00:00:00 2001
From: Linus Torvalds [EMAIL PROTECTED]
Date: Fri, 5 Sep 2008 09:30:14 -0700
Subject: [PATCH] x86: disable static NOPLs on 32 bits

On 32-bit, at least the generic nops are fairly reasonable, but the
default nops for 64-bit really look pretty sad, and the P6 nops really do
look better.

So I would suggest perhaps moving the static P6 nop selection into the
CONFIG_X86_64 thing.

The alternative is to just get rid of that static nop selection, and just
have two cases: 32-bit and 64-bit, and just pick obviously safe cases for
them.

Signed-off-by: H. Peter Anvin [EMAIL PROTECTED]
---
 arch/x86/Kconfig.cpu |   13 -
 1 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/arch/x86/Kconfig.cpu b/arch/x86/Kconfig.cpu
index 2c518fb..b225219 100644
--- a/arch/x86/Kconfig.cpu
+++ b/arch/x86/Kconfig.cpu
@@ -382,14 +382,17 @@ config X86_OOSTORE
 # P6_NOPs are a relatively minor optimization that require a family =
 # 6 processor, except that it is broken on certain VIA chips.
 # Furthermore, AMD chips prefer a totally different sequence of NOPs
-# (which work on all CPUs).  As a result, disallow these if we're
-# compiling X86_GENERIC but not X86_64 (these NOPs do work on all
-# x86-64 capable chips); the list of processors in the right-hand clause
-# are the cores that benefit from this optimization.
+# (which work on all CPUs).  In addition, it looks like Virtual PC
+# does not understand them.
+#
+# As a result, disallow these if we're not compiling for X86_64 (these
+# NOPs do work on all x86-64 capable chips); the list of processors in
+# the right-hand clause are the cores that benefit from this optimization.
 #
 config X86_P6_NOP
 	def_bool y
-	depends on (X86_64 || !X86_GENERIC)  (M686 || MPENTIUMII || MPENTIUMIII || MPENTIUMM || MCORE2 || MPENTIUM4 || MPSC)
+	depends on X86_64
+	depends on (MCORE2 || MPENTIUM4 || MPSC)
 
 config X86_TSC
 	def_bool y
-- 
1.6.0.2.GIT