Bug#877911: Please set CONFIG_BRCMFMAC_SDIO=y for WiFi on the Raspberry Pi 3

2017-10-06 Thread Michael Stapelberg
Source: linux
Severity: wishlist

Thanks for the linux/4.13.4-1 upload!

On the Raspberry Pi 3, the Broadcom BRCM43430 chip is connected via
SDIO. Hence, the brcmfmac driver’s config option CONFIG_BRCMFMAC_SDIO=y
needs to be set, otherwise the driver won’t find the chip.

I verified this works by recompiling the Debian kernel with
CONFIG_BRCMFMAC_SDIO=y added to debian/config/arm64/config, and indeed
the wlan0 interface newly shows up after rebooting into my kernel.

Please include CONFIG_BRCMFMAC_SDIO=y in the next upload for arm64.

Thank you!

-- 
Best regards,
Michael



Bug#873860: FTBFFS can't be in buster

2017-10-06 Thread Osamu Aoki
control: tags -1 - buster
thanks

This FTBFS was caused by the upload of anthy to unstable/sid.  

Those broken versions are blocked by the RC bug to stay in unstable.

The testing/buster has the same version of anthy as the one in
stable/stretch.

Thus tagging this as buster bug is wrong ;-)  Also, my NMU'd version of
anthy (once accepted to unstable) should fix issues in unstable and
allow anthy package transition to buster without problem.

So I am dropping the buster tag.

Osamu



Bug#877900: general: en-us locale defaults to 24-hour "military" time on stock install

2017-10-06 Thread Adam Borowski
Control: reassign -1 locales

On Fri, Oct 06, 2017 at 05:29:20PM -0400, debianuser2017_ wrote:
> When Debian 9 is installed with the en-us locale selected, the clock defaults
> to 24 hour time in the resulting install. This is odd because the normal means
> of representing the time in the area covered by en-us is to separate the day
> into two 12-hour segments. (localization issue)

Actually, not two but four discontinuous segments:
12:00am..12:59am
01:00am..11:59am
12:00pm..12:59pm
01:00pm..11:59pm
-- ie, even inside an am/pm value, the order is bizarre.

Also, there's no way to unambigously refer to noon or midnight, or whether a
midnight belongs to the previous or next day, as even the same users often
keep shifting between two possible variants; you can read more about this
horror at:
https://en.wikipedia.org/wiki/12-hour_clock#Confusion_at_noon_and_midnight

But, the above reasons apply mostly to humans.  In a computing context, the
main reasons are:

* 12-hour times don't sort.  Save for some GUIs where display is distinct
  from the internal format, most cases would do it wrong.  And sorting by
  time is something with lots of use.

* en_US (.UTF-8) is used as the default English locale for all places that
  don't have a specific variant (and often even then).  Generally, technical
  users use English as a system locale as translations of computing terms
  tend to be a horror show: for example, in Polish even such a basic term
  as "file" has two versions ("zbiór" — correct, and "plik" — Microsoftese)
  that are not intelligible between some groups of people.  Anything more
  complex gets bad enough that no one bothers translating advanced technical
  documentation or running servers (rather than user-facing systems) in
  pl_PL locale.  And as far as I know, same applies to most languages.

Obviously, this is an abuse, but that's the cost of being the default.  If
we had C.UTF-8 as a first-class locale, this wouldn't be that much an
argument, but currently d-i falls back to en_US for English for most
countries.


The decision belongs to the maintainer (I'm reassigning), but per the above
reasoning, I expect wontfix.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ We domesticated dogs 36000 years ago; together we chased
⣾⠁⢰⠒⠀⣿⡁ animals, hung out and licked or scratched our private parts.
⢿⡄⠘⠷⠚⠋⠀ Cats domesticated us 9500 years ago, and immediately we got
⠈⠳⣄ agriculture, towns then cities. -- whitroth on /.



Bug#877910: irssi-plugin-xmpp: Fails to install due to conflict with irssi

2017-10-06 Thread Diederik de Haas
Package: irssi-plugin-xmpp
Version: 0.54-1
Severity: grave
Justification: renders package unusable

Trying to upgrade the package to 0.54-1 from 0.53-1+b1 fails with the
following error:

Preparing to unpack .../irssi-plugin-xmpp_0.54-1_amd64.deb ...
Unpacking irssi-plugin-xmpp:amd64 (0.54-1) over (0.53-1+b1) ...
dpkg: error processing archive 
/var/cache/apt/archives/irssi-plugin-xmpp_0.54-1_amd64.deb (--unpack):
 trying to overwrite '/usr/share/irssi/help/ban', which is also in package 
irssi 1.0.4-1+b2
Errors were encountered while processing:
 /var/cache/apt/archives/irssi-plugin-xmpp_0.54-1_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

So it looks like some package needs a rebuild or a Breaks/Replaces
config item needs to be added.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(101, 'experimental'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)

Kernel: Linux 4.13.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:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages irssi-plugin-xmpp depends on:
ii  irssi1.0.4-1+b2
ii  libc62.24-17
ii  libglib2.0-0 2.54.1-1
ii  libloudmouth1-0  1.5.3-2

irssi-plugin-xmpp recommends no packages.

irssi-plugin-xmpp suggests no packages.

-- no debconf information


signature.asc
Description: This is a digitally signed message part.


Bug#877909: NEW UPSTREAM 5 series VERSION !!!

2017-10-06 Thread Osamu Aoki
Package: getmail4
Version: 4.53.0-1
Severity: important

The watch file locks scanning of version to 4.  So it loos only one
version behind the upstream.  But reality is different!!!

| Version 5.4
| 6 October 2017
| -bugfix: fix another error in logging an error condition.  Thanks: "ng0".
| 
| Version 5.3
| 5 October 2017
| -bugfix: another case where an error condition resulted in getmail not
| displaying the correct message.  Thanks: "ng0".
| 
| Version 5.2
| 4 October 2017
| -bugfix: disconnection during IMAP IDLE could result in an error message
| rather than silently exiting.  Thanks: David Gray.
| 
| Version 5.1
| 15 July 2017
| -bugfix: if password_command parameter was used with a non-existent 
program,
| getmail would error out during the handling of that condition and not 
report
| the problem correctly.
| 
| Version 5.0
| 15 July 2017
| -new release numbering scheme; previous version numbers were just getting
| too high.
| -catch and ignore/exit cleanly after reset connection in IMAP IDLE mode.
| Thanks:  Stephan Schulz.
| -allow specifying an expected SSL certificate hostname, for when the
| server's certificate does not match the domain name used to connect to
| it.  Thanks:  "Andre".
| -fix error message not actually giving the header field name incorrectly
| specified as containing the envelope recipient address.  Thanks:  Hardy 
| Braunsdorf.
| -add new password_command configuration parameter for retrievers, allowing
| getmail to retrieve the account password from any arbitrary external 
| command.  Suggestion:  "ng0".
| 
| Version 4.54.0
| 19 February 2017
| -fix error running getmail_fetch introduced in 4.53.0.  Thanks: "fsckd"
| of Arch Linux.

(Actually, there are 5.0.0a1 and 5.0.0a2 from 2010 in the download
directory.  This was the reason why uscan was locked to version 4).

So the game plan is to upload 4.54.0 to testing (maybe as 4.53.0-2), to
pave the way to the stable-update upload.

Then update the watch file and start uploading the 5 series!
AS I see the daily updates for the last few days, waiting a bit may not
be a bad idea.

The question is do I upload as getmail, getmail4, or getmail5?

Since there is no getmail in any active release, re-using "getmail" as
the package name may be safe.

This bug will be closed with the 5 series upload.

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

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:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages getmail4 depends on:
ii  python  2.7.13-2

getmail4 recommends no packages.

getmail4 suggests no packages.

-- no debconf information



Bug#877838: clang-5.0: c++17 std::get(std::variant) fails to compile with libstdc++

2017-10-06 Thread Daniele Di Proietto
It appears that clang is ignoring a friend declaration, while gcc is not.

This simplified version of the program shows the problem:

$ cat variant.cpp
namespace __detail {
namespace __variant {

template 
decltype(auto) __get(const T ) {
  return t.i_;
}

}
}

template  class variant {
public:
  variant(const T ) : i_(t) {}
  template 
  friend decltype(auto) __detail::__variant::__get(const Type &);
private:
  T i_;
};

int main() {
  variant v{2};
  return __detail::__variant::__get(v);
}


$ g++-7 variant.cpp -std=c++1z
$ clang++-5.0 variant.cpp -std=c++1z
variant.cpp:6:12: error: 'i_' is a private member of 'variant'
  return t.i_;
   ^
variant.cpp:24:31: note: in instantiation of function template
specialization '__detail::__variant::__get' requested
here
  return __detail::__variant::__get(v);
  ^
variant.cpp:18:5: note: declared private here
  T i_;
^
1 error generated.

I suspect this might be related to the use of decltype(auto), but I
don't know anything about clang internals to investigate more.

I've also tried clang-6.0 from unstable and the output is similar.

I'd appreciate any help.

Thanks!

Daniele



Bug#497859: Gruß

2017-10-06 Thread Meinze Klaus Peter
In kurzen Einleitung

Ich bin ein Anwalt Meinze Klaus Peter, aus Deutschland, ich lebe jetzt
in London jetzt, ich habe dir eine E-Mail über dein verstorbenes
Familienmitglied verspätete Familie geschickt, ich habe keine Antwort
von dir erhalten. Der Verstorbene ist ein Bürger in deinem Land mit
demselben Nachname mit dir Er ist ein Gold-Exporteur hier in London,
mein Klient starb vor ein paar Jahren mit seiner Familie, die sein
Geschäft verlassen und riesige Geldbeträge

  £ 5,7 Millionen bei GBP Investment Bank hier in London, ich bin der
persönliche Anwalt des verspäteten Klienten, und ich brauche Ihre
volle Zusammenarbeit, soweit wir das Geld von der Bank nehmen können,
bevor die Regierung es endlich nimmt. Der Gesamtbetrag in der Die Bank
ist £ 5,7 Millionen, GBP aber wird erklären, mehr Details, wenn ich
von Ihnen zu hören

   Ich brauche jetzt deine Antwort?



Bug#877908: ITP: libweasel-widgets-dojo-perl - Dojo Widgits for Weasel

2017-10-06 Thread Robert J. Clay
Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org,debian-p...@lists.debian.org

* Package name: libweasel-widgets-dojo-perl
  Version : 0.02
  Upstream Author : Erik Huelsmann 
* URL or Web page : https://metacpan.org/pod/Weasel::Widgets::Dojo
* License : perl
  Description : Weasel::Widgets::Dojo - Dojo Widgits for Weasel

The Weasel::Widgets::Dojo module is a Weasel extension set for testing
Dojo-based web apps (tag matchers and widgets).


-- 
Robert J. Clay
rjc...@gmail.com



Bug#877907: music ftbfs on all archs except for amd64

2017-10-06 Thread Matthias Klose
Package: src:music
Version: 1.0.7-1.3
Severity: serious
Tags: sid buster

see https://buildd.debian.org/status/package.php?p=music

make[2]: Leaving directory '/<>'
( cd /<>/debian/tmp/usr/lib/x86_64-linux-gnu; chrpath -d
libmusic.so libmusic-c.so )
/bin/sh: 1: cd: can't cd to /<>/debian/tmp/usr/lib/x86_64-linux-gnu
open: No such file or directory
elf_open: Invalid argument
debian/rules:10: recipe for target 'override_dh_auto_install' failed
make[1]: *** [override_dh_auto_install] Error 1
make[1]: Leaving directory '/<>'
debian/rules:7: recipe for target 'binary-arch' failed
make: *** [binary-arch] Error 2



Bug#877895: intersphinx plugin makes packages unreproducible

2017-10-06 Thread Antoine Beaupré
[taking the liberty to add back the BTS in CC, I hope that's okay]

On 2017-10-06 22:20:11, Daniel Shahaf wrote:
> Antoine Beaupre wrote on Fri, Oct 06, 2017 at 15:51:46 -0400:
>> -to_addr (> href="https://docs.python.org/3/library/stdtypes.html#str; title="(in Python 
>> v3.6)">str) – the email to use as “to” (defaults to
>> +to_addr (str) – the email to use as “to” 
>> (defaults to
>
>  problem is the interlinks mapping is sometimes more than stdlib 
> (like in my case)
>  gtg
>
> In this case, the solution I described on IRC works more generally...  
>
> If python3-foo's docs link to python3-bar's, then have python3-foo
> build-depend on python3-bar, have python3-bar provide a parseable
> documentation index, and have python3-foo's build use that index.

I believe that those docs package already do provide docs index, e.g.:

/usr/share/doc/python-configparser/html/objects.inv

it's just a matter of fixing sphinx to make that work then... i wonder
if interlinks supports file:// paths?

a.

-- 
I believe that if someone choose arts as their subject but do not
criticize the issues of their society, they have have betrayed
themselves, their conscience, and their society.
- Atena Farghadani



Bug#877679: [Openjdk] Bug#877679: java-8-openjdk (version 8u141-b15-1~deb9u1) fails to install if /usr/share/man is not available

2017-10-06 Thread Matthias Klose
Control: severity -1 wishlist

On 04.10.2017 11:52, Mattia Rizzolo wrote:
> Control: reassign -1 openjdk-8-jre-headless 8u141-b15-1~deb9u1
> Control: severity -1 serious

no. why?  Please don't exaggerate bug severities without looking at them.

> On Tue, Oct 03, 2017 at 09:47:12PM +0200, Olliver Schinagl wrote:
>> Package: java-8-openjdk
>>
>> Version 8u141-b15-1~deb9u1
> 
> Please use reportbug to report your bugs if you are unsure about the the
> proper syntax: the package you mentioned doesn't exist, and the version
> line lacks a column.
> 
>> Severity: normal
> 
> failures to install are serious bugs.

no, not if the user choose to drop installation of manual pages, and the
infrastructure is broken not to handle creating symlinks for these cases. If you
want to help, please find an appropriate package and reassign.  We had these bug
reports before.

> Reassigning and leaving the rest of the message as a context for the
> maintainer.
> 
>> When setting up java-8-openjdk on a minimal debian (where I would have rm
>> -rf-ed /usr/share/man) the following snipped shows the failure error.
>>
>> I have had a similar error with postgres which was fixed in Bug#866729
>>
>> update-alternatives: using /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/rmid to
>> provide /usr/bin/rmid (rmid) in auto mode
>> update-alternatives: error: error creating symbolic link
>> '/usr/share/man/man1/rmid.1.gz.dpkg-tmp': No such file or directory
>> dpkg: error processing package openjdk-8-jre-headless:amd64 (--configure):
>>  subprocess installed post-installation script returned error exit status 2
>> dpkg: dependency problems prevent configuration of
>> openjdk-8-jdk-headless:amd64:
>>  openjdk-8-jdk-headless:amd64 depends on openjdk-8-jre-headless (=
>> 8u141-b15-1~deb9u1); however:
>>   Package openjdk-8-jre-headless:amd64 is not configured yet.
>>
>> Thank you,
>>
>> Olliver
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~openjdk
> Post to : open...@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openjdk
> More help   : https://help.launchpad.net/ListHelp
> 



Bug#877418: dh-strip-nondeterminism: kills clojure performance

2017-10-06 Thread Daniel Kahn Gillmor
On Fri 2017-10-06 10:00:27 +0100, Chris Lamb wrote:
> If it were hardcoded into the filenames, one wouldn't need to do
> anything onerous, eg.
>
>   -rw-r--r-- 1 0 Oct  6 09:56 
> helloworld.adc83b19e793491b1c6ea0fd8b46cd9f32e592fc.class
>   -rw-r--r-- 1 0 Oct  6 09:56 
> helloworld.adc83b19e793491b1c6ea0fd8b46cd9f32e592fc.clj
>
> (Not entirely serious)

ah!  i hadn't even thought of that :)  I wonder whether any language
would consider such a construct.

> Just to underline, Python in Debian would not be a problem even with <
> unless you consider building a .deb with SOURCE_DATE_EPOCH="$(date +%s)"
> and installing that very same .deb within same second...
>
>  … but I understand you were being more general about this topic!

yep, exactly -- i'm not saying that python is broken in debian, just
citing it as an example of another language that does the same kind of
thing, similarly to elisp, etc.

   --dkg



Bug#877906: hwinfo: hangs forever at > bios.2: ram

2017-10-06 Thread MJ Ray (Debian)
Package: hwinfo
Version: 21.49-1
Severity: normal

Dear Maintainer,

Running "hwinfo --bios" displays things overtyping itself then hangs forever
with "> bios.2: ram" displayed.

Running it in strace shows that this is just after it opens /dev/mem

Thanks for any assistance or advice you can offer.

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

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

Versions of packages hwinfo depends on:
ii  libc62.24-11+deb9u1
ii  libhd21  21.49-1

hwinfo recommends no packages.

hwinfo suggests no packages.

-- debconf-show failed



Bug#255572: ITP: cc65 -- Cross development suite for 65xxx processors, necesary for nesicide env

2017-10-06 Thread PICCORO McKAY Lenz
a bit late but great work! please upload to debian..

Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com

2017-10-06 17:46 GMT-04:00 Michael Stapelberg :

> Indeed, I can confirm that compilation works now. Can you upload the
> package to Debian please? :)
>
> On Fri, Oct 6, 2017 at 11:26 PM, László Böszörményi (GCS)
>  wrote:
> > On Fri, Oct 6, 2017 at 10:26 PM, Michael Stapelberg
> >  wrote:
> >> Thanks for sharing! The Debian package builds fine. However, when
> >> trying to use cc65 to compile a project of mine, compilation fails
> >> with “include/general.h(4): Error: Include file `peekpoke.h' not
> >> found”.
> >  Please fetch and build again. Should be fixed.
> >
> > Laszlo/GCS
>
>
>
> --
> Best regards,
> Michael
>


Bug#875423: openssl: Please re-enable TLS 1.0 and TLS 1.1

2017-10-06 Thread Gedalya

This is affecting EAP with wpa_supplicant.
See https://bugs.debian.org/877904



Bug#877905: lintian: False positive for dh-exec-script-without-dh-exec-features

2017-10-06 Thread Axel Beckert
Package: lintian
Version: 2.5.54

The following working dh-exec file (from gpm 1.20.7-3, currently in
Experimental) triggers the lintian warning
dh-exec-script-without-dh-exec-features despite it clearly uses dh-exec
features:

---8<---
#!/usr/bin/dh-exec
contrib/control/gpm_has_mouse_control  usr/lib/gpm/
contrib/scripts/microtouch-setup=> usr/sbin/gpm-microtouch-setup
debian/gpm.apm  => etc/apm/event.d/gpm
src/prog/mouse-test => usr/sbin/gpm-mouse-test
src/gpmusr/sbin/
src/prog/mev   usr/bin/
--->8---

Reason seems to be that the file uses tabs instead of simple blanks in
front of the "=>" arrow.

I think, I'll already found the code which causes this, so I'll very
likely add a commit to fix this soon.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), 
(500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 
'buildd-experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.13.0-rc7-amd64 (SMP w/8 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages lintian depends on:
ii  binutils  2.29.1-4
ii  bzip2 1.0.6-8.1
ii  diffstat  1.61-1+b1
ii  dpkg  1.18.24
ii  file  1:5.32-1
ii  gettext   0.19.8.1-4
ii  intltool-debian   0.35.0+20060710.4
ii  libapt-pkg-perl   0.1.33
ii  libarchive-zip-perl   1.59-1
ii  libclass-accessor-perl0.34-1
ii  libclone-perl 0.38-2+b2
ii  libdigest-sha-perl5.98-1
ii  libdpkg-perl  1.18.24
ii  libemail-valid-perl   1.202-1
ii  libfile-basedir-perl  0.07-1
ii  libipc-run-perl   0.96-1
ii  liblist-moreutils-perl0.416-1+b3
ii  libparse-debianchangelog-perl 1.2.0-12
ii  libperl5.26 [libdigest-sha-perl]  5.26.0-8
ii  libtext-levenshtein-perl  0.13-1
ii  libtimedate-perl  2.3000-2
ii  liburi-perl   1.72-1
ii  libxml-simple-perl2.24-1
ii  libyaml-libyaml-perl  0.63-2+b2
ii  man-db2.7.6.1-2
ii  patchutils0.3.4-2
ii  perl  5.26.0-8
ii  t1utils   1.40-2
ii  xz-utils  5.2.2-1.3

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1+b4

Versions of packages lintian suggests:
ii  binutils-multiarch 2.29.1-4
ii  dpkg-dev   1.18.24
ii  libhtml-parser-perl3.72-3+b2
ii  libtext-template-perl  1.47-1

-- no debconf information



Bug#877687: pidgin: (xmpp) checks wrong certificate when connecting to explicit server

2017-10-06 Thread Ari Pollak
Are you sure this isn't intended behavior? Why should pidgin trust the
hostname on a certificate just because it matches the ID? If anything, it
seems like having that behavior for a SRV record would be a bug.


Bug#877904: EAP: TLS version too low

2017-10-06 Thread Gedalya

Package: wpa
Version: 2:2.6-4

OpenSSL 1.1.0f-5 will not by default negotiate a version of TLS lower 
than 1.2.

I'm having an issue with EAP authentication that seems related to this.

With openssl 1.1.0f-3 installed:

wpa_supplicant[30538]: wlp3s0: SME: Trying to authenticate with xx:xx:.. 
(SSID='UPC Wi-Free' freq=2437 MHz)
wpa_supplicant[30538]: wlp3s0: Trying to associate with xx:xx:.. 
(SSID='UPC Wi-Free' freq=2437 MHz)

wpa_supplicant[30538]: wlp3s0: Associated with xx:xx:..
wpa_supplicant[30538]: wlp3s0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
wpa_supplicant[30538]: wlp3s0: CTRL-EVENT-EAP-STARTED EAP authentication 
started
wpa_supplicant[30538]: wlp3s0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 
method=25
wpa_supplicant[30538]: wlp3s0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 
25 (PEAP) selected
wpa_supplicant[30538]: wlp3s0: CTRL-EVENT-EAP-PEER-CERT depth=2 
subject='/C=NL/O=Liberty Global Operations B.V./OU=Root 
CA0001/CN=Liberty Global Root Certification Authority' hash=...
wpa_supplicant[30538]: wlp3s0: CTRL-EVENT-EAP-PEER-CERT depth=2 
subject='/C=NL/O=Liberty Global Operations B.V./OU=Root 
CA0001/CN=Liberty Global Root Certification Authority' hash=...
wpa_supplicant[30538]: wlp3s0: CTRL-EVENT-EAP-PEER-CERT depth=1 
subject='/C=NL/O=Liberty Global Operations B.V./OU=HORIZON Service 
Operator CA0001/CN=Liberty Global HORIZON Service Operator Certification 
Authority' hash=...
wpa_supplicant[30538]: wlp3s0: CTRL-EVENT-EAP-PEER-CERT depth=0 
subject='/C=NL/O=LGI/OU=HORIZON/CN=Liberty Global WiFi 0001' hash=...
wpa_supplicant[30538]: wlp3s0: CTRL-EVENT-EAP-PEER-ALT depth=0 
DNS:wifi-auth.upc.biz

wpa_supplicant[30538]: EAP-MSCHAPV2: Authentication succeeded
wpa_supplicant[30538]: wlp3s0: CTRL-EVENT-EAP-SUCCESS EAP authentication 
completed successfully
wpa_supplicant[30538]: EAPOL: Received IEEE 802.1X EAPOL-Key even though 
this was not accepted - ignoring this packet
wpa_supplicant[30538]: wlp3s0: WPA: Key negotiation completed with 
xx:xx:.. [PTK=CCMP GTK=TKIP]
wpa_supplicant[30538]: wlp3s0: CTRL-EVENT-CONNECTED - Connection to 
xx:xx:.. completed [id=0 id_str=]
wpa_supplicant[30538]: EAPOL: Received IEEE 802.1X EAPOL-Key even though 
this was not accepted - ignoring this packet
wpa_supplicant[30538]: wlp3s0: CTRL-EVENT-SIGNAL-CHANGE above=1 
signal=-49 noise= txrate=144400



With 1.1.0f-5 installed:

wpa_supplicant[32704]: wlp3s0: CTRL-EVENT-SSID-REENABLED id=0 ssid="UPC
Wi-Free"
wpa_supplicant[32704]: wlp3s0: SME: Trying to authenticate with xx:xx:..
(SSID='UPC Wi-Free' freq=2412 MHz)
wpa_supplicant[32704]: wlp3s0: Trying to associate with xx:xx:..
(SSID='UPC Wi-Free' freq=2412 MHz)
wpa_supplicant[32704]: wlp3s0: Associated with xx:xx:..
wpa_supplicant[32704]: wlp3s0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
wpa_supplicant[32704]: wlp3s0: CTRL-EVENT-EAP-STARTED EAP authentication
started
wpa_supplicant[32704]: wlp3s0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0
method=25
wpa_supplicant[32704]: wlp3s0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method
25 (PEAP) selected
wpa_supplicant[32704]: SSL: SSL3 alert: write (local SSL3 detected an
error):fatal:protocol version
wpa_supplicant[32704]: OpenSSL: openssl_handshake - SSL_connect
error:1417118C:SSL routines:tls_process_server_hello:version too low
wpa_supplicant[32704]: wlp3s0: CTRL-EVENT-EAP-FAILURE EAP authentication
failed
wpa_supplicant[32704]: wlp3s0: Authentication with xx:xx:.. timed out.
wpa_supplicant[32704]: wlp3s0: CTRL-EVENT-DISCONNECTED bssid=xx:xx:..
reason=3 locally_generated=1
wpa_supplicant[32704]: wlp3s0: CTRL-EVENT-SSID-TEMP-DISABLED id=0
ssid="UPC Wi-Free" auth_failures=2 duration=37 reason=AUTH_FAILED

Related bug reports:

https://bugs.debian.org/875423
https://bugs.debian.org/871987
https://bugs.debian.org/873302

Regards,

Gedalya



Bug#866118: unattended-upgrades: test suite reads files from /etc/apt

2017-10-06 Thread Balint Reczey
Control: fixed -1 0.96

Hi Raphael,

On Tue, 27 Jun 2017 15:36:36 +0200 Raphael Geissert
 wrote:
> Package: unattended-upgrades
> Version: 0.93.1+nmu1
>
> Hi,
>
> As discussed via IRC, unattended-upgrades' test suite appears to read
> files from the host's /etc/apt/, which may at least make it fail.
>
> For instance, test_minimal_partitions uses apt.Cache which ends up
> reading the preferences files.
> Given an environment where those files are not world-readable the test
> suite fails.

This made builds on buildds fail, too, but it is fixed now.

Cheers,
Balint



Bug#643680: Could I ask for a reproducer?

2017-10-06 Thread Matěj Cepl
Hi,

this is your happy upstream maintainer of M2Crypto. I tried to reproduce
this bug here, but I have failed so far. Could you be so kind and and
provide some complete standalone testing script together with all data
files (certificates, etc.) needed for the reproduction, please?

If I can reproduce the problem, I will gladly try to fix it.

Thank you for reporting this,

Matěj Cepl



signature.asc
Description: OpenPGP digital signature


Bug#865497: CVE-2017-9781 not yet fixed in 1.2.8p26-1?

2017-10-06 Thread Matt Taggart

On 10/06/2017 02:28 PM, Salvatore Bonaccorso wrote:

Control: notfixed -1 1.2.8p26-1

Hi!

On Fri, Oct 06, 2017 at 09:09:03PM +, Debian Bug Tracking System wrote:

This is an automatic notification regarding your Bug report
which was filed against the src:check-mk package:

#865497: check-mk: CVE-2017-9781: reflected XSS in webapi.py


I looked up the source for 1.2.8p26-1.

The fix for CVE-2017-9781 is

http://git.mathias-kettner.de/git/?p=check_mk.git;a=commitdiff;h=c248f0b6ff7b15ced9f07a3df8a80fad656ea5b1

which does not yet seem to be applied to 1.2.8p26-1?

Can you please double-check?


Note, there is a second CVE now for check-mk, that one got addressed
in 1.2.8p26, but it's not clear yet in which version in was
introduced.

Hi,

You are right, the fix for CVE-2017-9781, which upstream calls "werk 
#4757" is _not_ in 1.2.8p26. I was confused with upstream #5208 when I 
wrote the changelog that closed the bug.


Upstream lists the following security related fixes for 1.2.8
==
#5208
http://mathias-kettner.com/check_mk_werks.php?werk_id=5208=yes
http://git.mathias-kettner.de/git/?p=check_mk.git;a=commitdiff;h=673360408b90f99bd54cf936091cff08d979a057

#4902
http://mathias-kettner.com/check_mk_werks.php?werk_id=4902=yes
http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=96e39a0f024d9b2b521576c1eb71aca7fb3e818d

#7661 (fixed in 1.4.0p8, supposedly fixed in 1.2.8p25?)
http://mathias-kettner.com/check_mk_werks.php?werk_id=7661=yes

#7631
http://mathias-kettner.com/check_mk_werks.php?werk_id=7631=yes

#3970 (fixed in 1.2.8p14)
http://mathias-kettner.com/check_mk_werks.php?werk_id=3970=yes

#3855 (fixed in 1.2.8p11)
http://mathias-kettner.com/check_mk_werks.php?werk_id=3855=yes

#3743 (fixed in 1.2.8p10)
http://mathias-kettner.com/check_mk_werks.php?werk_id=3743=yes

Full list of changes for 1.2.8p26
=
http://mathias-kettner.com/check_mk_werks.php?edition_id=raw=1.2.8=1.2.8p26=yes

Full list of changes for 1.4.0p14
=
http://mathias-kettner.com/check_mk_werks.php?edition_id=raw=1.4.0=1.4.0p14=yes

which additionally lists

#4757 (as you mentioned above, fixed in 1.4.0p6)
http://mathias-kettner.com/check_mk_werks.php?werk_id=4757=yes
http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=14a5b79c6f549502244a60146ed6831dc3473f2a

#7643 (only in 1.4 and newer)
http://mathias-kettner.com/check_mk_werks.php?werk_id=7643=yes

So I think the Debian 1.2.8p16 package is only missing #4757.

I will ask upstream if they intend to fix #4757 in the 1.2.8 series.
Unfortunately due to how the upstream tarball/build works, it is tricky 
to patch upstream files. If upstream doesn't intend to include this fix 
I can generate a patch to make it work.


I had started working on packaging 1.4.0 as a way to fix these security 
bugs (and even did an upload to experimental) but I recently learned 
from upstream that:


"The use of Check_MK without OMD environment and customization of paths 
is explicitly not supported anymore."


ie you can't use check-mk stand-alone, you have to use OMD (and 
livestatus/WATO/multisite, the whole stack) and you have to use 
upstream's installer to upstream's paths. It's very much the "network 
appliance" model (or flatpak, docker image, etc)
I don't know if we'll be able to make this work in Debian. (not to 
mention that nagios is gone and icinga1 will go away at some point)


That prompted me to go back to 1.2.8 and package the latest release 
there in order to at least have something working without the security bugs.


--
Matt Taggart
tagg...@debian.org



Bug#877903: CVE-2017-15037

2017-10-06 Thread Moritz Muehlenhoff
Source: kfreebsd-10
Severity: important
Tags: security

Please see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-15037

Cheers,
Moritz



Bug#255572: ITP: cc65 -- Cross development suite for 65xxx processors, necesary for nesicide env

2017-10-06 Thread Michael Stapelberg
Indeed, I can confirm that compilation works now. Can you upload the
package to Debian please? :)

On Fri, Oct 6, 2017 at 11:26 PM, László Böszörményi (GCS)
 wrote:
> On Fri, Oct 6, 2017 at 10:26 PM, Michael Stapelberg
>  wrote:
>> Thanks for sharing! The Debian package builds fine. However, when
>> trying to use cc65 to compile a project of mine, compilation fails
>> with “include/general.h(4): Error: Include file `peekpoke.h' not
>> found”.
>  Please fetch and build again. Should be fixed.
>
> Laszlo/GCS



-- 
Best regards,
Michael



Bug#877902: ftp.debian.org: removals.822 contains invalid stanzas

2017-10-06 Thread Guillem Jover
Package: ftp.debian.org
Severity: normal

I've written a local script (to be submitted to devscripts) that
parses the removals.822, but it seems the generated one(s) is bogus.

We have for example joined stanzas, which make the parser trip over
the duplicate field:

[ error: syntax error in Debian package removals at line 11506:
  duplicate field Date found ]
,---
Date: Sat, 01 Apr 2017 00:00:14 +
Ftpmaster: Scott Kitterman
Suite: unstable
Sources:
 libdc0_0.3.24~svn3121-4
Binaries:
 libdc-dev_0.3.24~svn3121-4 [amd64, arm64, armel, armhf, i386, kfreebsd-amd64, 
kfreebsd-i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x]
 libdc5v5_0.3.24~svn3121-4 [amd64, arm64, armel, armhf, i386, kfreebsd-amd64, 
kfreebsd-i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x]
Reason: RoQA; unmaintained, dead upstream, low popcon, library with no rdeps
Bug: 761989
Date: Sat, 01 Apr 2017 14:22:46 +
Ftpmaster: DAK's auto-decrufter
Suite: experimental
Sources:
 wine_1.8.7-1
Binaries:
 fonts-wine_1.8.7-1 [all]
 libwine_1.8.7-1 [amd64, arm64, armel, armhf, hurd-i386, i386, kfreebsd-i386, 
powerpc]
 libwine-dev_1.8.7-1 [amd64, arm64, armel, armhf, hurd-i386, i386, 
kfreebsd-i386, powerpc]
 wine_1.8.7-1 [all]
 wine-binfmt_1.8.7-1 [all]
 wine32_1.8.7-1 [armel, armhf, hurd-i386, i386, kfreebsd-i386, powerpc]
 wine32-preloader_1.8.7-1 [armel, armhf, i386, powerpc]
 wine32-tools_1.8.7-1 [armel, armhf, hurd-i386, i386, kfreebsd-i386, powerpc]
 wine64_1.8.7-1 [amd64, arm64]
 wine64-preloader_1.8.7-1 [amd64]
 wine64-tools_1.8.7-1 [amd64, arm64]
Reason: [auto-cruft] NVIU
`---

[ error: syntax error in Debian package removals at line 13372:
  line with unknown format (not field-colon-value) ]
,---
Date: sh: 0: getcwd() failed: No such file or directory
Sat, 06 May 2017 08:45:30 +
Ftpmaster: Chris Lamb
Suite: unstable
Binaries:
 rnahybrid_2.1.2-1 [armel]
Reason: ROM; Does not build on armel
Bug: 861794
Date: Sat, 06 May 2017 08:45:49 +
Ftpmaster: Chris Lamb
Suite: unstable
Sources:
 cpp-netlib_0.11.2+dfsg1-2
Binaries:
 libcppnetlib-dev_0.11.2+dfsg1-2+b1 [arm64, hurd-i386, kfreebsd-amd64, 
kfreebsd-i386]
 libcppnetlib-dev_0.11.2+dfsg1-2+b3 [amd64, armel, armhf, i386, mips, mips64el, 
mipsel, powerpc, ppc64el, s390x]
 libcppnetlib-doc_0.11.2+dfsg1-2 [all]
 libcppnetlib0_0.11.2+dfsg1-2+b1 [arm64, hurd-i386, kfreebsd-amd64, 
kfreebsd-i386]
 libcppnetlib0_0.11.2+dfsg1-2+b3 [amd64, armel, armhf, i386, mips, mips64el, 
mipsel, powerpc, ppc64el, s390x]
Reason: ROM; Doesn't work against current libboost, no time to maintain it
Bug: 861888
Also-Bugs: 834186
Also-WNPP: 857461
`---

Thanks,
Guillem



Bug#877900: general: en-us locale defaults to 24-hour "military" time on stock install

2017-10-06 Thread debianuser2017_
Package: general
Severity: minor

Dear Maintainer,

When Debian 9 is installed with the en-us locale selected, the clock defaults
to 24 hour time in the resulting install. This is odd because the normal means
of representing the time in the area covered by en-us is to separate the day
into two 12-hour segments. (localization issue)



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

Kernel: Linux 4.9.0-3-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#877901: libseccomp: Test failures should cause the build to fail

2017-10-06 Thread Tyler Hicks
Package: libseccomp
Version: 2.3.1-2.1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu artful ubuntu-patch

Dear Maintainer,

While doing some work on libseccomp in Ubuntu, I noticed that the exit
code of the `make check` target was being ignored despite the tests
passing on all architectures we build on. I think we should make test
failures be fatal for the build as the old issues that caused Debian bug
721292 seem to have been fixed.

In Ubuntu, the attached patch was applied to achieve the following:

  * debian/rules: Make test failures cause the build to fail (LP: #1657425)

To test the attached patch, I injected a fake test failure into
tests/13-basic-attrs.py and verified that the subsequent build failed.

Thanks for considering the patch.

Tyler

-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (400, 'xenial-proposed')
Architecture: amd64 (x86_64)

Kernel: Linux 4.4.0-96-generic (SMP w/12 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)
diff -Nru libseccomp-2.3.1/debian/rules libseccomp-2.3.1/debian/rules
--- libseccomp-2.3.1/debian/rules	2016-11-17 17:23:10.0 +
+++ libseccomp-2.3.1/debian/rules	2017-10-06 18:08:35.0 +
@@ -29,9 +29,3 @@
 		"usr/lib/$(DEB_HOST_MULTIARCH)/libseccomp.so.*" \
 		lib/$(DEB_HOST_MULTIARCH)
 	dh_install --remaining-packages --list-missing
-
-override_dh_auto_test:
-ifeq (,$(findstring nocheck,$(DEB_BUILD_OPTIONS)))
-	make check 2>&1 | tee regression.out && \
-	  grep -q "^ tests failed: 0" regression.out || true
-endif


Bug#865497: CVE-2017-9781 not yet fixed in 1.2.8p26-1?

2017-10-06 Thread Salvatore Bonaccorso
Control: notfixed -1 1.2.8p26-1

Hi!

On Fri, Oct 06, 2017 at 09:09:03PM +, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the src:check-mk package:
> 
> #865497: check-mk: CVE-2017-9781: reflected XSS in webapi.py

I looked up the source for 1.2.8p26-1.

The fix for CVE-2017-9781 is 

http://git.mathias-kettner.de/git/?p=check_mk.git;a=commitdiff;h=c248f0b6ff7b15ced9f07a3df8a80fad656ea5b1

which does not yet seem to be applied to 1.2.8p26-1?

Can you please double-check?


Note, there is a second CVE now for check-mk, that one got addressed
in 1.2.8p26, but it's not clear yet in which version in was
introduced.

Regards,
Salvatore



Bug#255572: ITP: cc65 -- Cross development suite for 65xxx processors, necesary for nesicide env

2017-10-06 Thread GCS
On Fri, Oct 6, 2017 at 10:26 PM, Michael Stapelberg
 wrote:
> Thanks for sharing! The Debian package builds fine. However, when
> trying to use cc65 to compile a project of mine, compilation fails
> with “include/general.h(4): Error: Include file `peekpoke.h' not
> found”.
 Please fetch and build again. Should be fixed.

Laszlo/GCS



Bug#862657: Weird setup

2017-10-06 Thread Santiago Garcia Mantinan
Hi!

I'm revisiting this bug and I still don't get the setup, it looks quite
weird to me.

br0 connected to eth0.6 (vlan 6)
br1 connected to eth0.7 (vlan 7)
br2 connected to eth0

It seems logic to me that putting br2 down also takes down eth0, the problem
here is that eth0 is also part of the other bridges.

What is the reason of using several bridges bound to the same physical
interfaces?

I believe this isn't even a supported setup, in fact if one tries to bridge
the same interface to a couple of bridges this won't be allowed:

device eth0 is already a member of a bridge; can't enslave it to bridge br0.

So, I believe this bug should be closed unless ther is something useful to
do with the weird setup.

There is an easy way to fix this bug, it would be to not put down the
interfaces when putting down the bridge, but I don't really like this.

What do you think?

Regards.
-- 
Manty/BestiaTester -> http://manty.net



Bug#877899: RM: gtable -- RoQA; binary package taken over by src:r-cran-gtable

2017-10-06 Thread Sébastien Villemot
Package: ftp.debian.org
Severity: normal

Dear ftpmasters,

Please remove src:gtable from the archive. The binary package that it built
(r-cran-gtable) has been taken over by src:r-cran-gtable.

Thanks,

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄  http://www.debian.org


signature.asc
Description: PGP signature


Bug#877898: RM: zelig -- RoQA; binary package taken over by src:r-cran-zelig

2017-10-06 Thread Sébastien Villemot
Package: ftp.debian.org
Severity: normal

Dear ftpmasters,

Please remove src:zelig from the archive. The binary package that it built
(r-cran-zelig) has been taken over by src:r-cran-zelig.

Thanks,

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄  http://www.debian.org


signature.asc
Description: PGP signature


Bug#744112: Release is being prepared

2017-10-06 Thread Gregor Riepl
Hi,

the Debian 3dprinter team is preparing a release of the new CuraEngine and the
rest of the Cura packages:
https://anonscm.debian.org/cgit/3dprinter/packages/cura-engine.git/
https://anonscm.debian.org/cgit/3dprinter/packages/cura.git/

We're still working on 2.5, but 2.7 or 3.0 will be released shortly after the
packages are in Debian.



Bug#877897: RFS: wxmaxima/17.10.0-3

2017-10-06 Thread Phil Wyett
On Fri, 2017-10-06 at 22:25 +0200, Gunter Königsmann wrote:
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am afraid this time I have made another bug in my package "wxmaxima"
> and therefore kindly ask you to sponsor another upload.
> 
>  * Package name: wxmaxima
>    Version : 17.10.0-3
>    Upstream Author : Andrej Vopodivec
>  * URL : http://andrejv.github.io/wxmaxima/
>  * License : GPL-2
>    Section : math
> 
> It builds those binary packages:
> 
> wxmaxima   - GUI for the computer algebra system Maxima
> 
> To access further information about this package, please visit the
> following URL:
> 
> https://mentors.debian.net/package/wxmaxima
> 
> 
> Alternatively, one can download the package with dget using this command:
> 
> dget -x
> https://mentors.debian.net/debian/pool/main/w/wxmaxima/wxmaxima_17.10.0-2.dsc
> 
> wxMaxima is a powerful graphical front-end for maxima, a program that
> does symbolic algebra. An example:
> 
> (%i1) val:[
>   a=10,
>   b=sqrt(2),
>   c=5
>   ];
> (val) [a=10,b=sqrt(2),c=5]
> 
> (%i2) poly:y=a*x^2+b*x+c$
> 
> (%i3) solve(poly,x);
> (%o3) [x=-(sqrt(4*a*y-4*a*c+b^2)+b)/(2*a),x=(sqrt(4*a*y-4*a*c+b^2)-
> b)/(2*a)]
> 
> (%i4) subst(y=0,%);
> (%o4) [x=-(sqrt(b^2-4*a*c)+b)/(2*a),x=(sqrt(b^2-4*a*c)-b)/(2*a)]
> 
> (%i5) subst(val,%);
> (%o5) [x=-(3*sqrt(22)*%i+sqrt(2))/20,x=(3*sqrt(22)*%i-sqrt(2))/20]
> 
> (%i6) rectform(float(%));
> (%o6)
> [x=-0.7035623639735145*%i-0.07071067811865477,x=0.7035623639735145*%i-
> 0.07071067811865477]
> 
> 
> Don't know why mentors.debian.net doesn't like my watchfile: uscan does.
> If anybody has an idea how to make it work for mentors, too, I will
> prepare a new wxMaxima package that fixes this.
> 
> 
> Changes since the last upload:
> 
> Re-Added an accidentally-dropped dependency.
> 
>   Regards,
>    Gunter Königsmann
> 

Hi, Regards

For watch file query. See:

https://wiki.debian.org/debian/watch#GitHub

Regards

Phil

-- 
*** If this is a mailing list, I am subscribed, no need to CC me.***

Playing the game for the games sake.

Web: https://kathenas.org

GitLab: https://gitlab.com/kathenas

Twitter: kathenasorg

Instagram: kathenasorg

GPG: 1B97 6556 913F 73F3 9C9B 25C4 2961 D9B6 2017 A57A

signature.asc
Description: This is a digitally signed message part


Bug#876654: prosody: incompatible lua-sec version as dependency of prosody in stable

2017-10-06 Thread Felix Geyer
Hi,

On Sun, 24 Sep 2017 16:16:59 +0200 Leah Oswald  
wrote:
> It seems that this bug occures becaus the package lua5.1-sec that is a 
> dependency of prosody resolves to the lua-sec package with version 0.6-3
> in debian stretch. But lua-sec with version 0.6 isn't supported by 
> prosody 0.9.x. See: https://prosody.im/doc/depends
> 
> It seems this issue makes prosody mostly unusable for encrypted
> connections.

I don't think this analysis is correct. I've tested connecting prosody with 
jabber.ccc-mannheim.de
on stretch and captured the packets.
The two sides just can't agree on a TLS cipher/curve.

jabber.ccc-mannheim.de supports only ECDHE ciphers and the secp256r1 (aka 
prime256v1) curve.
Prosody by default allows only the secp384r1 curve.

You can verify this with:
openssl s_client -cipher ECDHE-RSA-AES128-GCM-SHA256 -curves prime256v1 
-starttls xmpp-server
-connect falster.c3ma.de:xmpp-server
works

openssl s_client -cipher ECDHE-RSA-AES128-GCM-SHA256 -curves secp384r1 
-starttls xmpp-server
-connect falster.c3ma.de:xmpp-server
fails

You can of course argue whether allowing only secp384r1 is a good default.

Felix



Bug#877629: wordpress: CVE-2017-14990

2017-10-06 Thread Craig Small
Hi Yves-Alexis,
  I have now applied that patch to the stretch version of wordpress. Other
than some minor problems (some comments had changed) the patch applied
cleanly.
You'll find the update at

https://anonscm.debian.org/git/collab-maint/wordpress.git/commit/?h=stretch=5c88ea7390caed18e9c986294d45f6c7f718740b

Hopefully we can get the security release out before the next set of
WordPress security issues!

 - Craig

-- 
Craig Small https://dropbear.xyz/ csmall at : enc.com.au
Debian GNU/Linuxhttps://www.debian.org/   csmall at : debian.org
Mastodon: @smalls...@social.dropbear.xyz Twitter: @smallsees
GPG fingerprint:  5D2F B320 B825 D939 04D2  0519 3938 F96B DF50 FEA5


Bug#865986: stretch-pu: package openssh/1:7.4p1-10+deb9u2

2017-10-06 Thread Colin Watson
Control: tag -1 - moreinfo

On Mon, Jun 26, 2017 at 01:57:25PM +0200, Cyril Brulebois wrote:
> Colin Watson  (2017-06-26):
> > I've committed this patch to master, but it isn't in unstable yet
> > because I'm waiting for openssh-ssh1 to clear NEW before I upload
> > openssh to unstable again, in order to avoid confusion with versions.
> > However, point release dates are close enough that I wanted to seek
> > approval for this sooner rather than later.
> 
> I was surprised by the double ExecReload entry at first, but that seems
> to be allowed. Moreover, that keeps sshd alive when a typo is willingly
> introduced in sshd_config.
> 
> (Granted: Tested on a jessie system only.)
> 
> This looks good to me. I'll wait until the bug fix clears NEW, and until
> you post a final debdiff, targetting stretch, to tag this request with
> the "confirmed" tag.

I got kind of distracted and forgot about this, and in the meantime a
few more bugs have become evident that ought to be fixed in stable, so
here's an extended debdiff for approval.

 * #877800 causes current versions of WinSCP to be unable to connect due
   to overly-general version patterns in sshd's bug-compatibility code.

 * #873201 was implicated in a few CVEs a while back in packages using
   ssh; I'm not sure whether it *quite* counts as a security
   vulnerability in and of itself, but we should fix it anyway.

(And yes, I'll deal with these in jessie too as necessary as soon as I
summon the energy for oldstable updates.)

A current version of git introduced a small amount of noise into the
diff, but it's small enough that I don't think it's worth brutalising
the tools to avoid it.

diff -Nru openssh-7.4p1/debian/.git-dpm openssh-7.4p1/debian/.git-dpm
--- openssh-7.4p1/debian/.git-dpm   2017-06-18 01:08:18.0 +0100
+++ openssh-7.4p1/debian/.git-dpm   2017-10-06 20:03:26.0 +0100
@@ -1,6 +1,6 @@
 # see git-dpm(1) from git-dpm package
-1fbd56e33d641c08a8f573406cf27f9adf667763
-1fbd56e33d641c08a8f573406cf27f9adf667763
+39d60bbd309be74d337685c2da524233652513f4
+39d60bbd309be74d337685c2da524233652513f4
 971a7653746a6972b907dfe0ce139c06e4a6f482
 971a7653746a6972b907dfe0ce139c06e4a6f482
 openssh_7.4p1.orig.tar.gz
diff -Nru openssh-7.4p1/debian/changelog openssh-7.4p1/debian/changelog
--- openssh-7.4p1/debian/changelog  2017-06-18 01:11:26.0 +0100
+++ openssh-7.4p1/debian/changelog  2017-10-06 20:03:40.0 +0100
@@ -1,3 +1,15 @@
+openssh (1:7.4p1-10+deb9u2) stretch; urgency=medium
+
+  * Test configuration before starting or reloading sshd under systemd
+(closes: #865770).
+  * Adjust compatibility patterns for WinSCP to correctly identify versions
+that implement only the legacy DH group exchange scheme (closes:
+#877800).
+  * Make "--" before the hostname terminate argument processing after the
+hostname too (closes: #873201).
+
+ -- Colin Watson   Fri, 06 Oct 2017 20:03:40 +0100
+
 openssh (1:7.4p1-10+deb9u1) stretch; urgency=medium
 
   * Fix incoming compression statistics (thanks, Russell Coker; closes:
diff -Nru openssh-7.4p1/debian/openssh-server.ssh.service 
openssh-7.4p1/debian/openssh-server.ssh.service
--- openssh-7.4p1/debian/openssh-server.ssh.service 2017-06-18 
01:08:12.0 +0100
+++ openssh-7.4p1/debian/openssh-server.ssh.service 2017-10-06 
20:03:26.0 +0100
@@ -5,7 +5,9 @@
 
 [Service]
 EnvironmentFile=-/etc/default/ssh
+ExecStartPre=/usr/sbin/sshd -t
 ExecStart=/usr/sbin/sshd -D $SSHD_OPTS
+ExecReload=/usr/sbin/sshd -t
 ExecReload=/bin/kill -HUP $MAINPID
 KillMode=process
 Restart=on-failure
diff -Nru openssh-7.4p1/debian/patches/auth-log-verbosity.patch 
openssh-7.4p1/debian/patches/auth-log-verbosity.patch
--- openssh-7.4p1/debian/patches/auth-log-verbosity.patch   2017-06-18 
01:08:11.0 +0100
+++ openssh-7.4p1/debian/patches/auth-log-verbosity.patch   2017-10-06 
20:03:26.0 +0100
@@ -18,7 +18,7 @@
 index 57b49f7f..7eb87b35 100644
 --- a/auth-options.c
 +++ b/auth-options.c
-@@ -59,9 +59,20 @@ int forced_tun_device = -1;
+@@ -59,8 +59,19 @@ int forced_tun_device = -1;
  /* "principals=" option. */
  char *authorized_principals = NULL;
  
@@ -28,17 +28,16 @@
 +
  extern ServerOptions options;
  
- void
++void
 +auth_start_parse_options(void)
 +{
 +  logged_from_hostip = 0;
 +  logged_cert_hostip = 0;
 +}
 +
-+void
+ void
  auth_clear_options(void)
  {
-   no_agent_forwarding_flag = 0;
 @@ -316,10 +327,13 @@ auth_parse_options(struct passwd *pw, char *opts, char 
*file, u_long linenum)
/* FALLTHROUGH */
case 0:
diff -Nru openssh-7.4p1/debian/patches/dash-dash-before-hostname.patch 
openssh-7.4p1/debian/patches/dash-dash-before-hostname.patch
--- openssh-7.4p1/debian/patches/dash-dash-before-hostname.patch
1970-01-01 01:00:00.0 +0100
+++ openssh-7.4p1/debian/patches/dash-dash-before-hostname.patch

Bug#877897: RFS: wxmaxima/17.10.0-3

2017-10-06 Thread Gunter Königsmann
Package: sponsorship-requests
Severity: normal

Dear mentors,

I am afraid this time I have made another bug in my package "wxmaxima"
and therefore kindly ask you to sponsor another upload.

 * Package name: wxmaxima
   Version : 17.10.0-3
   Upstream Author : Andrej Vopodivec
 * URL : http://andrejv.github.io/wxmaxima/
 * License : GPL-2
   Section : math

It builds those binary packages:

wxmaxima   - GUI for the computer algebra system Maxima

To access further information about this package, please visit the
following URL:

https://mentors.debian.net/package/wxmaxima


Alternatively, one can download the package with dget using this command:

dget -x
https://mentors.debian.net/debian/pool/main/w/wxmaxima/wxmaxima_17.10.0-2.dsc

wxMaxima is a powerful graphical front-end for maxima, a program that
does symbolic algebra. An example:

(%i1)   val:[
a=10,
b=sqrt(2),
c=5
];
(val)   [a=10,b=sqrt(2),c=5]

(%i2)   poly:y=a*x^2+b*x+c$

(%i3)   solve(poly,x);
(%o3)   [x=-(sqrt(4*a*y-4*a*c+b^2)+b)/(2*a),x=(sqrt(4*a*y-4*a*c+b^2)-b)/(2*a)]

(%i4)   subst(y=0,%);
(%o4)   [x=-(sqrt(b^2-4*a*c)+b)/(2*a),x=(sqrt(b^2-4*a*c)-b)/(2*a)]

(%i5)   subst(val,%);
(%o5)   [x=-(3*sqrt(22)*%i+sqrt(2))/20,x=(3*sqrt(22)*%i-sqrt(2))/20]

(%i6)   rectform(float(%));
(%o6)
[x=-0.7035623639735145*%i-0.07071067811865477,x=0.7035623639735145*%i-0.07071067811865477]


Don't know why mentors.debian.net doesn't like my watchfile: uscan does.
If anybody has an idea how to make it work for mentors, too, I will
prepare a new wxMaxima package that fixes this.


Changes since the last upload:

Re-Added an accidentally-dropped dependency.

  Regards,
   Gunter Königsmann



Bug#255572: ITP: cc65 -- Cross development suite for 65xxx processors, necesary for nesicide env

2017-10-06 Thread Michael Stapelberg
Thanks for sharing! The Debian package builds fine. However, when
trying to use cc65 to compile a project of mine, compilation fails
with “include/general.h(4): Error: Include file `peekpoke.h' not
found”.

Using strace, I can see:

read(4, "#ifndef GENERAL_H_\n#define GENER"..., 4096) = 1790
access("include/peekpoke.h", F_OK)  = -1 ENOENT (No such file or directory)
access("/build/cc65-cBYPC5/cc65-2.16/include/peekpoke.h", F_OK) = -1
ENOENT (No such file or directory)
write(2, "include/general.h(4): Error: ", 29include/general.h(4): Error: ) = 29
write(2, "Include file `peekpoke.h' not fo"..., 35Include file
`peekpoke.h' not found) = 35

So it seems like the import path is incorrect — it currently points
into the temporary path in which sbuild placed the source when
building the Debian package, while it should point to
/usr/share/cc65/include.

On Fri, Oct 6, 2017 at 9:21 PM, László Böszörményi (GCS)  
wrote:
> On Fri, Oct 6, 2017 at 11:00 AM, Michael Stapelberg
>  wrote:
>> Great! Thanks for letting us know, please keep us posted on the progress.
>  OK, you can download[1] and build the package for testing.
>
> Regards,
> Laszlo/GCS
> [1] dget -x http://www.barcikacomp.hu/gcs/cc65_2.16-1.dsc



-- 
Best regards,
Michael



Bug#868157: heimdal-kdc: Crashes periodically (bad error handling?)

2017-10-06 Thread Chris Chiappa
FWIW, this appears to be a known problem, as per this thread:
http://www.h5l.org/pipermail/heimdal-discuss/2017-August/000259.html



Bug#877891: wxmaxima: should depend on maxima

2017-10-06 Thread Gunter Königsmann
On 06.10.2017 21:07, Daniel Serpell wrote:
> Package: wxmaxima
> Version: 17.10.0-1
> Severity: important
> 
> Hi,
> 
> New wxmaxima version no longer depends on maxima, so it was uninstalled
> on upgrade, making the package unusable.
> 
> Installing maxima manually made it work again.
> 
Thanks for the bug report! Seems like I dropped the dependency along
with the minimum version (which I meant to drop).

Will upload the fix to debian mentors in a moment.

Kind regards,

  Gunter.



Bug#877896: certspotter: FTBFS on mips{,el}

2017-10-06 Thread Julien Cristau
Source: certspotter
Version: 0.5-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

certspotter FTBFS on the mips and mipsel buildds with no useful error message:

> dh_auto_build: go install 
> -gcflags=\"-trimpath=/<>/obj-mips-linux-gnu/src\" 
> -asmflags=\"-trimpath=/<>/obj-mips-linux-gnu/src\" -v -p 4 
> software.sslmate.com/src/certspotter software.sslmate.com/src/certspotter/cmd 
> software.sslmate.com/src/certspotter/cmd/certspotter 
> software.sslmate.com/src/certspotter/cmd/ctparsewatch 
> software.sslmate.com/src/certspotter/cmd/submitct 
> software.sslmate.com/src/certspotter/ct 
> software.sslmate.com/src/certspotter/ct/client returned exit code 1
> debian/rules:4: recipe for target 'build-arch' failed
> make: *** [build-arch] Error 1

Cheers,
Julien



Bug#862058: python-debian: required dependency on python-apt

2017-10-06 Thread Matthieu Caneill
Control: reopen -1
Control: tags -1 + patch 

Hi Stuart,

On Sun, Sep 10, 2017 at 01:47:22AM +1000, Stuart Prescott wrote:
> That iter_paragraphs works with compressed indexes at all is somewhat 
> accidental. I don't believe it is documented anywhere that this is a 
> supported 
> use of iter_paragraphs. (But it's rather handy that it does work!) In fact, 
> the documentation says that iter_paragraphs accepts:
> 
>  sequence: a string, or any any object that returns a line of
> input each time, normally a file.
> 
> (not a compressed file).
> 
> Further, my feeling is that if a user chooses to break a Recommends, they get 
> what is coming to them and policy is quite clear about that. 

Thanks for your explanation, I agree with your conclusions.

> As a user of the iter_paragraphs (and other!) functions, if you are in a 
> position to add to the docstrings of these functions so that this contract is 
> more clear to programmer, then that would be greatly appreciated. Building 
> some API docs with sphinx is something we should aim for but at present, 
> there 
> is not nearly enough documentation to make that worthwhile.

I attached a patch that adds a couple lines of doc. In the process I
realised there was a deprecated example with shared_storage in a
README, which I took the opportunity to remove.

Cheers,
--
Matthieu
From 86df0a5b86ec44f07e4fa624d33a5a002a479359 Mon Sep 17 00:00:00 2001
From: Matthieu Caneill 
Date: Fri, 6 Oct 2017 21:47:35 +0200
Subject: [PATCH] deb822: add clarifications for iter_paragraphs with
 compressed files

---
 README.deb822| 6 ++
 lib/debian/deb822.py | 4 +++-
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/README.deb822 b/README.deb822
index 89e7d64..4480c87 100644
--- a/README.deb822
+++ b/README.deb822
@@ -68,10 +68,8 @@ For example:
 print src['Package'], src['Version']
 
 This method uses python-apt if available to parse the file, since it
-significantly boosts performance. The downside, though, is that yielded
-objects share storage, so they should never be kept accross iterations.
-To prevent this behavior, pass a "shared_storage=False" keyword-argument
-to the iter_paragraphs() function.
+significantly boosts performance. If python-apt is not present and the
+file is a compressed file, it must first be decompressed manually.
 
 
 Sample usage (TODO: Improve)
diff --git a/lib/debian/deb822.py b/lib/debian/deb822.py
index 26f4b68..84af3c2 100644
--- a/lib/debian/deb822.py
+++ b/lib/debian/deb822.py
@@ -313,7 +313,9 @@ class Deb822(Deb822Dict):
 
 :param sequence: a string, or any any object that returns a line of
 input each time, normally a file.  Alternately, sequence can
-be a dict that contains the initial key-value pairs.
+be a dict that contains the initial key-value pairs. When
+python-apt is present, sequence can also be a compressed object,
+for example a file object associated to something.gz.
 
 :param fields: if given, it is interpreted as a list of fields that
 should be parsed (the rest will be discarded).
-- 
2.8.1



signature.asc
Description: PGP signature


Bug#868927: python-pybedtools FTBFS with more than one supported Python3 version

2017-10-06 Thread Andreas Tille
On Wed, Jul 19, 2017 at 10:47:09PM +0300, Adrian Bunk wrote:
> On Wed, Jul 19, 2017 at 09:37:35PM +0200, Andreas Tille wrote:
> >...
> > I guess python-pysam is not yet build for Python3 3.6.
> 
> That's #867017/#867018, which seems to require that you update 
> python-pysam to 0.11.2.2

That's done now.  Unfortunately there is one remaining issue in the test
suite: 

...
I: pybuild base:184: cd 
/build/python-pybedtools-0.7.10/.pybuild/pythonX.Y_3.6/build; python3.6 -m nose 
--attr '!url'
..


E.S..
==
ERROR: pybedtools.test.test1.test_issue_178
--
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/nose/case.py", line 198, in runTest
self.test(*self.arg)
  File 
"/build/python-pybedtools-0.7.10/.pybuild/pythonX.Y_3.6/build/pybedtools/test/test1.py",
 line 2108, in test_issue_178
pybedtools.contrib.bigwig.bam_to_bigwig(fn, genome='dm3', output='tmp.bw')
  File 
"/build/python-pybedtools-0.7.10/.pybuild/pythonX.Y_3.6/build/pybedtools/contrib/bigwig.py",
 line 123, in bam_to_bigwig
p = subprocess.Popen(cmds, stdout=subprocess.PIPE, stderr=subprocess.PIPE, 
universal_newlines=True)
  File "/usr/lib/python3.6/subprocess.py", line 709, in __init__
restore_signals, start_new_session)
  File "/usr/lib/python3.6/subprocess.py", line 1344, in _execute_child
raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: 'bedGraphToBigWig': 
'bedGraphToBigWig'

--
Ran 491 tests in 12.192s

FAILED (SKIP=1, errors=1)
E: pybuild pybuild:283: test: plugin distutils failed with: exit code=1: cd 
/build/python-pybedtools-0.7.10/.pybuild/pythonX.Y_3.6/build; python3.6 -m nose 
--attr '!url'
dh_auto_test: pybuild --test --test-nose -i python{version} -p "3.6 3.5" 
returned exit code 13
...

Kind regards

   Andreas.

-- 
http://fam-tille.de



Bug#875265: RFS: rednotebook/2.3-1 [ITP] [ITA] -- A cross-platform journal

2017-10-06 Thread Phil Wyett
Hi,

New version upload.

Your upload of the package 'rednotebook' to mentors.debian.net was
successful. Others can now see it. The URL of your package is:
https://mentors.debian.net/package/rednotebook

The respective dsc file can be found at:
https://mentors.debian.net/debian/pool/main/r/rednotebook/rednotebook_2.3-1.dsc

Changes since last upload:

rednotebook (2.3-1) unstable; urgency=low

  [ Jendrik Seipp ]
  * New upstream release
  * Compress backups.
  * Use newer txt2tags version 2.6 and reapply changes to obtain a GPL-2+
version.
  * Remove brittle PDF export. Please export to HTML and print to PDF with
browser instead.
  * Remove intro page from export wizard.
  * Fix: image files were not found on Windows and Mac OS.
  * Print peak memory usage on Linux when program exits.
  * Hide tags panel completely by default instead of only minimizing it.
  * Update Debian files (@kathenas).

 -- Phil Wyett   Fri, 06 Oct 2017 20:20:27 +0100

Regards

Phil

-- 
*** If this is a mailing list, I am subscribed, no need to CC me.***

Playing the game for the games sake.

Web: https://kathenas.org

GitLab: https://gitlab.com/kathenas

Twitter: kathenasorg

Instagram: kathenasorg

GPG: 1B97 6556 913F 73F3 9C9B 25C4 2961 D9B6 2017 A57A

signature.asc
Description: This is a digitally signed message part


Bug#864255: Status

2017-10-06 Thread Andreas Moog
This is just a status information:

Currently this ITP is blocked by a licensing issue, vzlogger is GPL without a 
OpenSSL exception clause but has components linked to OpenSSL. I opened a Git
issue to track a possible reclicense or rewrite of that portion of the code at
https://github.com/volkszaehler/vzlogger/issues/331

-- 
PGP-encrypted mails preferred PGP Fingerprint: 
74CD D9FE 5BCB FE0D 13EE 8EEA 61F3 4426 74DE 6624


signature.asc
Description: PGP signature


Bug#877745: gthumb: Recommends: gvfs-bin, which contains only deprecated tools

2017-10-06 Thread Herbert Fortes
Hi Paul Wise,

> Package: gthumb
> Version: 3.5.2-2
> Severity: normal
> User: pkg-gnome-maintain...@lists.alioth.debian.org
> Usertags: gvfs-bin-deprecation
> 
> This package Recommends: gvfs-bin, which contains only deprecated
> tools. Please port it to the `gio` commands from libglib2.0-bin:
> 
> $ grep deprecated, /usr/bin/gvfs-cat
>> &2 echo "This tool has been deprecated, use '$replacement' instead."
> $ grep replacement= /usr/bin/gvfs-*
> /usr/bin/gvfs-cat:replacement="gio cat"
> /usr/bin/gvfs-copy:replacement="gio copy"
> /usr/bin/gvfs-info:replacement="gio info"
> /usr/bin/gvfs-ls:replacement="gio list"
> /usr/bin/gvfs-mime:replacement="gio mime"
> /usr/bin/gvfs-mkdir:replacement="gio mkdir"
> /usr/bin/gvfs-monitor-dir:replacement="gio monitor"
> /usr/bin/gvfs-monitor-file:replacement="gio monitor"
> /usr/bin/gvfs-mount:replacement="gio mount"
> /usr/bin/gvfs-move:replacement="gio move"
> /usr/bin/gvfs-open:replacement="gio open"
> /usr/bin/gvfs-rename:replacement="gio rename"
> /usr/bin/gvfs-rm:replacement="gio remove"
> /usr/bin/gvfs-save:replacement="gio save"
> /usr/bin/gvfs-set-attribute:replacement="gio set"
> /usr/bin/gvfs-trash:replacement="gio trash"
> /usr/bin/gvfs-tree:replacement="gio tree"
> 

Gthumb does not use gvfs-bin. But I was the one who put 
gvfs-bin as "Recommends". I will update the package 
tomorrow. New version.

Thanks!



Regards,
Herbert



Bug#877894: apticron: Encrypt apticron mails

2017-10-06 Thread Matthias Baumgarten
Package: apticron
Version: 1.1.61
Severity: wishlist
Tags: patch

Dear Tiago,

as this is my first time sending a bug report I hope to do this the right way. 
As requested in your last mail I file this bug report.
As you might remember the feature idea for apticron was to send the mails 
encrypted.

I'll try to append the patch file.

Best wishes,
Matthias

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

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

Versions of packages apticron depends on:
ii  apt1.4.7
ii  bzip2  1.0.6-8.1
ii  cron [cron-daemon] 3.0pl1-128+b1
ii  debconf [debconf-2.0]  1.5.61
ii  dpkg   1.18.24
ii  mailutils [mailx]  1:3.1.1-1
ii  ucf3.0036

Versions of packages apticron recommends:
ii  apt-listchanges  3.10
ii  iproute2 4.9.0-1

apticron suggests no packages.

-- debconf information excluded
diff --git a/apticron b/apticron
index 3edbca5..49c6df4 100755
--- a/apticron
+++ b/apticron
@@ -4,27 +4,41 @@
 # implementations in Debian. Make sure we send proper headers, and a
 # text/plain content type.
 Mailx() {
+# The statement msg="$(xargs --null echo)" will fail if the generated 
message
+# is very long with xargs: argument line too long.
+msg="$(xargs --null echo)"
+if which gpg > /dev/null ; then
+msg=$(echo "$msg" | gpg --trust-model always --batch --armor --encrypt 
--recipient $EMAIL --sign --passphrase $GPG_PASS_PHRASE)
+if [ -z "$msg" ]; then
+echo "GnuPG error. Could not encrypt message for $EMAIL. Exiting 
here."
+exit 1
+fi
+else
+echo "GnuPG not installed. Exiting here."
+exit 1
+fi
+
 local MAILER="`readlink -e /usr/bin/mailx`"
 if [ x$MAILER = "x/usr/bin/heirloom-mailx" -o x$MAILER = 
"x/usr/bin/s-nail" ]
then
# heirloom-mailx creates correct headers, but needs help
# if the terminal charset (LC_CTYPE) is no UTF-8 locale
if [ -n "$CUSTOM_FROM" ] ; then
-   /usr/bin/mailx -S ttycharset=utf-8 -r "$CUSTOM_FROM" 
"$@"
+   echo "$msg" | /usr/bin/mailx -S ttycharset=utf-8 -r 
"$CUSTOM_FROM" "$@"
else
-   /usr/bin/mailx -S ttycharset=utf-8 "$@"
+   echo "$msg" | /usr/bin/mailx -S ttycharset=utf-8 "$@"
fi
else
# bsd-mailx/mailutils' mailx don't do character set
# conversion, but do not support MIME either.
if [ -n "$CUSTOM_FROM" ] ; then
-   /usr/bin/mailx -a "MIME-Version: 1.0" \
+   echo "$msg" | /usr/bin/mailx -a "MIME-Version: 1.0" \
-a "Content-type: text/plain; charset=UTF-8" \
-a "Content-transfer-encoding: 8bit" \
-a "From: $CUSTOM_FROM" \
"$@"
else
-   /usr/bin/mailx -a "MIME-Version: 1.0" \
+   echo "$msg" | /usr/bin/mailx -a "MIME-Version: 1.0" \
-a "Content-type: text/plain; charset=UTF-8" \
-a "Content-transfer-encoding: 8bit" \
"$@"


Bug#877893: libpython3.5-stdlib: csv module: Sniffer shouldn't use '.*?' regex

2017-10-06 Thread Celelibi
Package: libpython3.5-stdlib
Version: 3.5.4-2
Severity: normal

Dear Maintainer,

The csv module has a Sniffer class to try and detect the dialect used by
a given csv file. To do so, at some point (in the method
_guess_quote_and_delimiter), it runs several regular expressions on the
data provided. Unfortunately, the regex are written such that the search
time might grow quadratically with the size of the input when there is
no match.

For instance on the data:
1234,"foobar"
1234,"foobar"
...
1 lines like this

The first regex, roughly simplified to r',".*?",' can take several
seconds on 1 lines, growing like the square of the number of lines.

To avoid this, I might suggest preventing the .*? to match an unescaped
and un-doubled quote.

Best regards,
Celelibi


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

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

Versions of packages libpython3.5-stdlib depends on:
ii  libbz2-1.01.0.6-8.1
ii  libc6 2.24-17
ii  libdb5.3  5.3.28-13.1
ii  liblzma5  5.2.2-1.3
ii  libmpdec2 2.4.2-1
ii  libncursesw5  6.0+20170902-1
ii  libpython3.5-minimal  3.5.4-2
ii  libreadline7  7.0-3
ii  libsqlite3-0  3.20.1-1
ii  libtinfo5 6.0+20170902-1
ii  mime-support  3.60

libpython3.5-stdlib recommends no packages.

libpython3.5-stdlib suggests no packages.

-- no debconf information



Bug#255572: ITP: cc65 -- Cross development suite for 65xxx processors, necesary for nesicide env

2017-10-06 Thread GCS
On Fri, Oct 6, 2017 at 11:00 AM, Michael Stapelberg
 wrote:
> Great! Thanks for letting us know, please keep us posted on the progress.
 OK, you can download[1] and build the package for testing.

Regards,
Laszlo/GCS
[1] dget -x http://www.barcikacomp.hu/gcs/cc65_2.16-1.dsc



Bug#764730: dh_systemd_start: un-escapes - in unit/directory names

2017-10-06 Thread Niels Thykier
Control: tags -1 moreinfo

On Fri, 10 Oct 2014 18:21:34 +0200 Bernd Zeimetz 
wrote:
> On 10/10/2014 06:14 PM, Michael Biebl wrote: 
> > Do you have an example where this actually is a practical issue and not
> > just a theoretical one? I.e, which package makes use escaped unit names?
> > 
> 
> https://github.com/bzed/pkg-open-vm-tools/commit/1130d9e91b696f1a364ce6a73b84d2a2d41fcc1f
> 
> just not uploaded yeat because of this and other systemd-related issues...
> (which are not a bug in systemd, just an annoying thing).
> 
> 
> 
> -- 
> Mit freundlichen Grüßen
> 
> 
> Bernd Zeimetz
> Systems Engineer
> Debian Developer
> 
> [...]


Hi Bernd,

I may have accidentally fixed as a side effect of another change in
debhelper/10.7.  Can you please check whether this bug has been fixed in
10.7 (or later)?

Thanks,
~Niels



Bug#877892: docker.io is not installable, missing dependency on containerd

2017-10-06 Thread Abhijit Hoskeri
Source: docker.io
Version: docker.io is not installable.
Severity: normal

Dear Maintainer,

On up to date debian unstable, docker.io is not installable.

The following information may help to resolve the situation:

The following packages have unmet dependencies:
 docker.io : Depends: containerd (>= 0.2.3+git20170126.85.aa8187d~ds1~) but 
it is not going to be installed
 Depends: runc (>= 1.0.0~rc2+git20170201.133.9df8b30~) but it 
is not going to be installed
E: Unable to correct problems, you have held broken packages.

containerd is available, but its version is

$ apt-cache show containerd|grep Version
Version: 0.2.3+git20170126.85.aa8187d~ds1-2

Thanks,
Abhijit


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

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



Bug#631806: This is almost certainly obsolete

2017-10-06 Thread Matěj Cepl
I cannot reproduce this even with python-m2crypto in
Debian/stretch (that's 0.24.0 from 2016-03-21). The last version
where I could reproduce it is on my RHEL-7 (0.21.1 from 2011-01-
15).

If you can reproduce the bug with version of M2Crypto more recent
than the last year, I would be interested in the bug report
upstream (https://gitlab.com/m2crypto/m2crypto/issues/new ).

Thank you,

Matěj



Bug#877891: wxmaxima: should depend on maxima

2017-10-06 Thread Daniel Serpell
Package: wxmaxima
Version: 17.10.0-1
Severity: important

Hi,

New wxmaxima version no longer depends on maxima, so it was uninstalled
on upgrade, making the package unusable.

Installing maxima manually made it work again.

Thanks,

Daniel.

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

Kernel: Linux 4.13.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)

Versions of packages wxmaxima depends on:
ii  ibus-gtk3 1.5.14-3
ii  libc6 2.24-17
ii  libgcc1   1:7.2.0-8
ii  libstdc++67.2.0-8
ii  libwxbase3.0-0v5  3.0.3.1+dfsg2-1
ii  libwxgtk3.0-0v5   3.0.3.1+dfsg2-1

Versions of packages wxmaxima recommends:
ii  maxima-doc  5.40.0-3

Versions of packages wxmaxima suggests:
ii  fonts-jsmath 0.090709+0-3
pn  texlive-latex-extra  

-- no debconf information



Bug#877583: [octocatalog-diff] Patch for missing scripts

2017-10-06 Thread Mathieu Parent
Control: tag -1 + patch

Here is a patch.

Regards

Mathieu Parent
From 30ca15b5ff90d3871d34a12f2c6f9cec378e2dcc Mon Sep 17 00:00:00 2001
From: Mathieu Parent 
Date: Fri, 6 Oct 2017 20:51:52 +0200
Subject: [PATCH] Install scripts (Closes: #877583)

---
 debian/rules | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/debian/rules b/debian/rules
index ad8762e..68456dc 100755
--- a/debian/rules
+++ b/debian/rules
@@ -12,6 +12,8 @@ override_dh_auto_install:
 	dh_auto_install
 	rm debian/octocatalog-diff/usr/lib/ruby/vendor_ruby/octocatalog-diff/external/pson/LICENSE
 	sed -e 's/@VERSION@/$(VERSION)/' debian/version.rb > debian/octocatalog-diff/usr/lib/ruby/vendor_ruby/octocatalog-diff/version.rb
+	mkdir -p debian/octocatalog-diff/usr/lib/ruby/scripts
+	cp -a scripts/* debian/octocatalog-diff/usr/lib/ruby/scripts/
 
 override_dh_installdocs:
 	dh_installdocs -Xdev/ -XCHANGELOG.md
-- 
2.14.2



Bug#871619: [Pkg-zfsonlinux-devel] Bug#871619: Bug#871619: Packaging

2017-10-06 Thread Fabian Grünbichler

On Fri, 6 Oct 2017 08:49:51 +0200 Dmitry Galenko  wrote:
> I successful build deb packages from upstream repo, for kernel 4.10
> (custom) without any changes with this instruction:
> 
> [snip]

this is not a good idea for production use IMHO - those converted packages 
using alien lack all of the integration into Debian proper (including missing 
all the systemd service stuff, among other things)..



Bug#871619: Packaging

2017-10-06 Thread Fabian Grünbichler
> Aron Xu  hat am 6. Oktober 2017 um 18:19 geschrieben:
> 
> 
> Hi,
> 
> On Fri, Oct 6, 2017 at 4:59 PM, Petter Reinholdtsen  wrote:
> >
> > [Antonio Russo]
> >> How can I help out the packaging team on this? Who should I email?
> >
> > The best way to help is to continue contributing and participating on
> > the team mailing list and IRC channel.
> >
> > Aron Xu has been most active with maintenance, and I hope he can comment
> > on how you best can contribute.  I am not competent do to so. :)
> >
> > Any project admin on
> > https://alioth.debian.org/projects/pkg-zfsonlinux/ > can grant
> > access, ie Aron, Liang and Carlos.
> >
> > CC to Aron, and email to the bts also go to the project mailing list.
> >
> 
> I've started to update the package to 0.7.2 release and it appears
> there are some build system changes that installs quite some files
> into non-FHS compliant paths, and possibly a new package (could be
> "zfs-tests") is needed. If you are eager to help, please start from
> these changes and my latest work is available on alioth git.
> 
> Regards,
> Aron
> 

did you see my WIP branch on github, linked earlier here (and also separately 
on pkg-zfsonlinux-de...@lists.alioth.debian.org)[1,2]? I already did most of 
the work (including splitting out zfs-test) except for updating 
debian/copyright.. note that I merged the actual upstream tags and not the 
upstream release tar balls, so you probably only want to take a closer look at 
commits touching debian/ ;) I have been running this branch (recently with the 
addition of upstream PR#6616[3]) for quite some time on my personal machines 
(Sid and Stretch), and have been testing a variant of it with a 4.13 kernel at 
work as well - all without any problems so far (except for the send/receive 
incompatibility with 0.6.5, for which I made the PR ;))

the only other point up for discussion besides splitting out zfs-test was 
whether the zfs and zpool binaries should move to /bin instead of /sbin, as 
they are now usable by unprivileged users for certain read-only operations..

I would be glad to assist in any future work here, both for the 0.7.2 release 
as well as further packaging (I am responsible for most of the downstream ZFS 
packaging in Proxmox VE, which is based on Debian - so I am familiar with both 
ZoL and Debian packaging ;)).

if you have any questions about my branch or want to discuss stuff, just drop 
me an e-mail (here, on-list or directly) or catch me on IRC (f_g on OFTC and 
freenode)

1: https://github.com/Fabian-Gruenbichler/zfs/commits/debian/wip-0.7
2: 
https://lists.alioth.debian.org/pipermail/pkg-zfsonlinux-devel/2017-August/001196.html
3: https://github.com/zfsonlinux/zfs/pull/6616



Bug#877766: lintian: more false positives in copyright-year-in-future

2017-10-06 Thread Mattia Rizzolo
I see what you mean.
Point taken :)

On Fri, Oct 6, 2017 at 8:43 PM Chris Lamb  wrote:

> Hi Mattia,
>
> > Dunno if this is the case, but would be possible to at least keep it for
> > some cases
> […]
>
> Whilst this is certainly possible I just can't shake the feeling that
> this tag isn't actually finding "real" bugs in packages worth of the
> investment.
>
> Sure, a typo of 2117 instead of 2017 is objectively "wrong" but whilst
> I am not a lawyer (I just play one on TV, etc. etc.) no court anywhere
> in the world is going to rule against someone on the basis of such an
> obvious typo.
>
> Thus, I think the Lintian developers' precious hours are better spent
> elsewhere and not playing whack-a-mole with this tag, and that's not
> taking into consideration the time or annoyance this tag can cause or
> has already caused regular developers.
>
>
> Best wishes,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-
>


Bug#717675: This has been fixed upstream

2017-10-06 Thread Matěj Cepl
This has been already fixed by the upstream commit 79032181 in
the release 0.26.0 from 2017-03-25.

Happy hacking!

Matěj

signature.asc
Description: This is a digitally signed message part


Bug#877766: lintian: more false positives in copyright-year-in-future

2017-10-06 Thread Chris Lamb
Hi Mattia,

> Dunno if this is the case, but would be possible to at least keep it for
> some cases
[…]

Whilst this is certainly possible I just can't shake the feeling that
this tag isn't actually finding "real" bugs in packages worth of the
investment.

Sure, a typo of 2117 instead of 2017 is objectively "wrong" but whilst
I am not a lawyer (I just play one on TV, etc. etc.) no court anywhere
in the world is going to rule against someone on the basis of such an
obvious typo.

Thus, I think the Lintian developers' precious hours are better spent
elsewhere and not playing whack-a-mole with this tag, and that's not
taking into consideration the time or annoyance this tag can cause or
has already caused regular developers.


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-



Bug#877766: lintian: more false positives in copyright-year-in-future

2017-10-06 Thread Mattia Rizzolo
Hi Chris,

On Fri, Oct 06, 2017 at 11:00:15AM +0100, Chris Lamb wrote:
> "Fixed" in Git:
> 
>   
> https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=b82460be905f860ef0b878b4b927c29ae9535566

Dunno if this is the case, but would be possible to at least keep it for
some cases where the amount of fpos would be way lower?  I'm thinking
about checking on machine-parsable d/copyright, and only for the
Copyright fields, and even there only the first chars of the field.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature


Bug#877421: lintian: privacy-breach-donation check should ignore URLs in comments

2017-10-06 Thread Chris Lamb
tags 877421 + pending
thanks

Fixed in Git:

  
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=077f99c547c9e79b40b625e8d60aea05258637b7


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-



Bug#859225: M2Crypto na OpenSSL 1.1.0

2017-10-06 Thread Matěj Cepl
Just to say, that M2Crypto since 0.26.2 (current release is
0.27.0) officially supports OpenSSL 1.1.0 API, no compat-
libraries are needed anymore.

Best,

Matěj Cepl
(upstream maintainer of M2Crypto)

signature.asc
Description: This is a digitally signed message part


Bug#877890: qemu: CVE-2017-15038: 9p: virtfs: information disclosure when reading extended attributes

2017-10-06 Thread Salvatore Bonaccorso
Source: qemu
Version: 1:2.10.0+dfsg-1
Severity: important
Tags: patch security upstream

Hi,

the following vulnerability was published for qemu.

CVE-2017-15038[0]:
|Qemu: 9p: virtfs: information disclosure when reading extended
|attributes

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-15038
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-15038
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1499110
[2] https://lists.gnu.org/archive/html/qemu-devel/2017-10/msg00729.html
[3] http://www.openwall.com/lists/oss-security/2017/10/06/1

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore



Bug#789594: does this problem still exist?

2017-10-06 Thread Thorsten Alteholz

Hi Nigel,

while browsing through older bugs of apcupsd I wonder whether this bug 
report is still valid.


Do you still have problems with apcaccess contacting your apcupsd?

  Thorsten



Bug#752195: does this problem still exist?

2017-10-06 Thread Thorsten Alteholz

Hi,

while browsing through older bugs of apcupsd I wonder whether your bug 
report is still valid.


Do you still have problems with your Eaton 3s?

  Thorsten



Bug#876667: RFS: pragha/1.3.3-1

2017-10-06 Thread Breno Leitao
Hello Gabriel,

On Tue, Sep 26, 2017 at 09:05:58PM +0200, Lukas Schwaighofer wrote:
> Hi Gabriel,
> 
> it seems you are getting the knack of it quickly :) .  I don't have
> any additional feedback.  I hope you're able to find a sponsor soon.

I am just doing a final review for the sponsor, and I found something
that annoys every developer, it seems that pragha does not re-builds
after an initial build.

It builds fine for the very first time, but if you try to re-build, the
directory stays dirty and does not allow the package to be rebuilt:

This is what I tried:

$ get -x
https://mentors.debian.net/debian/pool/main/p/pragha/pragha_1.3.3-1.dsc

$ cd pragha-1.3.3 

$ debuild ; debuild

You are going to see something like:

dpkg-source: error: cannot represent change to po/bg.gmo: binary file 
contents changed
dpkg-source: error: add po/bg.gmo in debian/source/include-binaries if 
you want to store the modified binary in the debian tarball

This means that your clean rules is not cleaning everything that was
generated during the build process.

Thank you and sorry for the delay,
Breno



Bug#877806: pulseaudio: Speaker silent after updating eeepc to Debian 9

2017-10-06 Thread Guenter Milde
On  5.10.17, Felipe Sateler wrote:

> > Note:
> >   Before the update, pavucontrol listed 3 outputs:
> >   audio, speaker, and headphone.  "audio" worked.
> >
> >   After the update, the "audio" port is missing on the list.

> This suggests that relevant change is in the kernel. Did you try
> booting with the old kernel?

Booting with 3.16 did not make a change.

GM



Bug#877889: RM: pbnj -- RoQA; thoroughly buggy, dead upstream, popcon 18/4

2017-10-06 Thread Adam Borowski
Package: ftp.debian.org
Severity: normal


Hi!
"pbnj" has been dead upstream in a decade, and hasn't seen a maintainer
upload that long as well.  There was a NMU in meantime, but apparently only
to fix FTBFS, without testing the functionality.

When preparing a QA upload for a seemingly trivial bug, I've refreshed the
packaging, which happened to auto-enable the testsuite.  And all hell broke
loose.  Some of the fixes are simple (such as s/ipv4_sort/addr_sort/ when
using Nmap::Parser), some are not -- but fixing everything to even let it
build (without sweeping the testsuite under the carpet) is way above the
amount of damn I give for a popcon vote:4 package.

Thus, let's let it follow the upstream project into the great bit bucket
in the sky.



Bug#877888: cups-bsd: lpq and lp ignore the PRINTER environment variable

2017-10-06 Thread Sanjoy Mahajan
Package: cups-bsd
Version: 2.2.4-7
Severity: normal
File: /usr/bin/lpq

lpq and lp are no longer paying attention to the PRINTER environment
variable.  (The cups(1) manpage says that PRINTER is used except for
setuid binaries.  But lpq and lp are not setuid.)

Here is a commented log with lpq:

  $ lpq 
  lj400 is ready  /* my default destination */
  no entries
  $ PRINTER=mh371 printenv PRINTER 
  mh371   /* to show that the environment variable inherits */
  $ PRINTER=mh371 lpq
  lj400 is ready  /* but lpq ignores it */
  no entries
  $ lpq -Pmh371
  mh371 is ready  /* to show that mh371 is a known destination */
  no entries

And for lp:

  $ PRINTER=mh371 lp /usr/share/hplip/data/ps/testpage.ps.gz
  request id is lj400-2890 (1 file(s))

It went to the default destination despite the environment setting.

Here is my /etc/cups/lpoptions:

Default lj400 fitplot=true PageSize=Letter sides=two-sided-long-edge
Dest lj400/gs fitplot=true PageSize=Letter pdftops-renderer=gs 
sides=two-sided-long-edge
Dest mh235 fitplot=true PageSize=Letter sides=two-sided-long-edge
Dest mh271 fitplot=true PageSize=Letter sides=two-sided-long-edge
Dest mh271/duplex fitplot=true PageSize=Letter sides=two-sided-long-edge
Dest mh271/saver fitplot=true number-up=2 PageSize=Letter 
sides=two-sided-long-edge
Dest mh371 PageSize=Letter sides=two-sided-long-edge
Dest mitx duplex=duplexnotumble
Dest psc outputorder=reverse PageSize=Letter PrintoutMode=High

-Sanjoy

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

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

Versions of packages cups-bsd depends on:
ii  cups-client  2.2.4-7
ii  cups-common  2.2.4-7
ii  debconf  1.5.63
ii  libc62.24-17
ii  libcups2 2.2.4-7

cups-bsd recommends no packages.

Versions of packages cups-bsd suggests:
ii  cups  2.2.4-7
ii  update-inetd  4.44

-- debconf information:
  cups-bsd/setuplpd: false

-- 



Bug#877887: please package latest upstream version (1.14.x)

2017-10-06 Thread Evgeni Golov
Source: koji
Version: 1.10.0-1
Severity: wishlist

Ohai,

https://pagure.io/koji/releases lists 1.14.0 as latest koji release,
please update the packaging :)

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
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)



Bug#877886: fedorahosted.org is deprecated, koji upstream is now at https://pagure.io/koji

2017-10-06 Thread Evgeni Golov
Source: koji
Severity: wishlist

please update d/control, d/copyright and d/watch accordignly :)

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
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)



Bug#877885: sssd: CVE-2017-12173: unsanitized input when searching in local cache database

2017-10-06 Thread Salvatore Bonaccorso
Source: sssd
Severity: important
Tags: upstream security

Hi,

the following vulnerability was published for sssd.

CVE-2017-12173[0]:
unsanitized input when searching in local cache database

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-12173
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-12173
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1498173

Please adjust the affected versions in the BTS as needed, and
unfortuantely at time of writing, I have not found any furhter
information on the issue than what is written in [1].

Any ideas? Is there an upstream issue to track?

Regards,
Salvatore



Bug#877884: Missing CLDR data from http://www.unicode.org/Public/

2017-10-06 Thread Osamu Aoki
Package: unicode-data
Version: 10.0.0-3
Severity: wishlist

http://www.unicode.org/Public/ has a lot of data.

Data under emoji is included in the unicode-data package but data under
cldr is not.  It will be nice cldr data is also available.

Background:

I actually needed emoji data and some parts of cldr data under the
/usr/share/unocode directory to update ibus program.

I understand emoji is mentioned in but cldr is not mentioned in
http://www.unicode.org/versions/Unicode10.0.0/

But http://www.unicode.org/ has a prominent link to
http://cldr.unicode.org/index so I do expect this data is also included
or coordinated with this package.

Fedora seems to create another rpm
 https://github.com/fujiwarat/cldr-emoji-annotation
which looks like coming from the unicode cldr data but not all of them.
He installs part of idata from the zip file under 
 /usr/share/unocode/cldr/common/annotations
 /usr/share/unocode/cldr/common/annotationsDerived

The data used is 
 http://www.unicode.org/Public/cldr/31.0.1/cldr-common-31.0.1.zip
 http://www.unicode.org/Public/cldr/31.0.1/core.zip
 (These seem to be the same file)

It will be nice you also include or package these zip files in
 http://www.unicode.org/Public/cldr/31.0.1/
or its new version.

Anyway, this data archive is huge.  Unless careful coordination is done,
we may end up lots of duplicated data.

I am not quite sure how these should be packaged for Debian.  I guess
unicode-data maintainer has a better idea,  So i am filing this bug
report.

Osamu
-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable'), (90, 'unstable')
Architecture: amd64 (x86_64)

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:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information



Bug#841623: python-pyrax: FTBFS: Forbidden: 'novaclient.v2.client.Client' is not designed to be initialized directly. It is inner class of novaclient. You should use 'novaclient.client.Client' instead

2017-10-06 Thread Sascha Girrulat
Hi,

fixed in git, but i got new build problems with python-novaclient and
it's dependencies python-keyring and dbus inside the pbuilder chroot.

==
ERROR: tests.unit.test_image (unittest.loader.ModuleImportFailure)
--
ImportError: Failed to import test module: tests.unit.test_image
Traceback (most recent call last):
  File "/usr/lib/python2.7/unittest/loader.py", line 254, in _find_tests
module = self._get_module_from_name(name)
  File "/usr/lib/python2.7/unittest/loader.py", line 232, in
_get_module_from_name
__import__(name)
  File "tests/unit/test_image.py", line 13, in 
import pyrax
  File "pyrax/__init__.py", line 42, in 
import keyring
  File "/usr/lib/python2.7/dist-packages/keyring/__init__.py", line 6,
in 
from .core import (set_keyring, get_keyring, set_password, get_password,
  File "/usr/lib/python2.7/dist-packages/keyring/core.py", line 148, in

init_backend()
  File "/usr/lib/python2.7/dist-packages/keyring/core.py", line 64, in
init_backend
keyrings = filter(limit, backend.get_all_keyring())
  File "/usr/lib/python2.7/dist-packages/keyring/util/__init__.py", line
20, in wrapper
func.always_returns = func(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/keyring/backend.py", line 191,
in get_all_keyring
exceptions=TypeError))
  File "/usr/lib/python2.7/dist-packages/keyring/util/__init__.py", line
29, in suppress_exceptions
for callable in callables:
  File "/usr/lib/python2.7/dist-packages/keyring/backend.py", line 183,
in is_class_viable
keyring_cls.priority
  File "/usr/lib/python2.7/dist-packages/keyring/util/properties.py",
line 22, in __get__
return self.fget.__get__(None, owner)()
  File
"/usr/lib/python2.7/dist-packages/keyring/backends/SecretService.py",
line 30, in priority
bus = secretstorage.dbus_init()
  File "/usr/lib/python2.7/dist-packages/secretstorage/__init__.py",
line 47, in dbus_init
return dbus.SessionBus()
  File "/usr/lib/python2.7/dist-packages/dbus/_dbus.py", line 211, in
__new__
mainloop=mainloop)
  File "/usr/lib/python2.7/dist-packages/dbus/_dbus.py", line 100, in
__new__
bus = BusConnection.__new__(subclass, bus_type, mainloop=mainloop)
  File "/usr/lib/python2.7/dist-packages/dbus/bus.py", line 122, in __new__
bus = cls._new_for_bus(address_or_type, mainloop=mainloop)
DBusException: org.freedesktop.DBus.Error.FileNotFound: Failed to
connect to socket /run/user/1000/bus: No such file or directory

Regards
Sascha



signature.asc
Description: OpenPGP digital signature


Bug#827395: [privacy] not as 'secure by default'

2017-10-06 Thread Ivan Shmakov
> Narcis Garcia  writes:

 > Note: trek.eu.org link provided by Trek is not working.

I’ve just checked and [1] does work for me.  (Note though that
‘www’ has to be there.)  An archived copy [2] is also available.

[1] http://www.trek.eu.org/text/firefox-tuning.html
[2] 
https://web.archive.org/web/20170411151300/http://www.trek.eu.org/text/firefox-tuning.html

 > Why a non-private browsing?  User activity should be assumed as
 > private by default.

Or at least there should be an easier (and more prominently
presented) way for the user to opt out.

 > Proposed defaults:

 > browser.newtabpage.directory.ping = ""
 > browser.newtabpage.directory.source = ""

Personally, I’ve disabled all the ‘safebrowsing’, ‘update’, and
similar options I could find.  Also, just to be sure, I’ve
uniformly replaced nearly every single URI in prefs.js like:

user_pref("browser.safebrowsing.provider.mozilla.updateURL", 
"http://browser.safebrowsing.provider.mozilla.updateurl.unwanted.nowhere.invalid/;);

Now I can refer to my HTTP proxy logs for the possible attempts
to disclose my use of Firefox to third parties (like my ISP,
employer, and whatever the entity it tries to connect to.)

Which seem to be surprisingly few (and the last one below is due
to xul-ext-noscript, not Firefox proper):

browser.newtabpage.directory.source
browser.safebrowsing.provider.mozilla.updateurl
browser.search.geoip.url
extensions.blocklist.url
noscript.abe.wanipcheckurl

Can at least the ‘safebrowsing’ one please be fixed to respect
the whatever ‘browser.safebrowsing.*.enabled = false’ setting
applicable?  Can there be also options to cleanly disable the
‘newtabpage.directory’ and ‘search.geoip’ functions as well?

TIA.

 > captivedetect.canonicalURL = ""
 > app.update.url = ""
 > browser.safebrowsing.downloads.remote.url = ""

[…]

 > browser.safebrowsing.reportPhishURL = ""
 > browser.search.geoSpecificDefaults.url = ""
 > browser.search.geoip.url = ""

I think it should also include browser.search.suggest.enabled =
false, which appears rather important as “search suggestions”
result in even the partial input being communicated to a remote
party.  (Which may even be a genuinely sensitive information –
like one’s password – by the way of pure accident.)

It’s basically Firefox’ very own remote keyboard logger!

 > browser.tabs.crashReporting.sendReport = false
 > datareporting.healthreport.service.enabled = false
 > datareporting.healthreport.uploadEnabled = false
 > datareporting.policy.dataSubmissionEnabled = false
 > security.ssl.errorReporting.enabled = false
 > security.ssl.errorReporting.url = ""
 > security.ssl.errorReporting.automatic = ""
 > browser.startup.homepage = "https://start.duckduckgo.com/;

I believe it should rather be about:blank, file:/, or something
like that – not requiring any network access whatsoever.

 > devtools.gcli.imgurUploadURL = ""

[…]

 > devtools.webide.templatesURL = ""
 > experiments.manifest.uri = ""
 > geo.wifi.uri = ""
 > identity.mobilepromo.android = ""
 > identity.mobilepromo.ios = ""
 > security.ssl.errorReporting.url = ""
 > toolkit.telemetry.server = ""
 > webextensions.storage.sync.enabled = false

-- 
FSF associate member #7257  http://am-1.org/~ivan/7D17 4A59 6A21 3D97 6DDB



Bug#871648: qemu-system-x86: /usr/bin/qemu-system-i386 eats slowly but surely all the Dom0 memory

2017-10-06 Thread astian
Michael Tokarev:
> This bug has been fixed by the last security update of qemu.
> 
> Thanks,
> 
> /mjt

Shall we close it then?  The "Closes:" in the changelog somehow did not do it...



Bug#877883: [openblas] cblas_* takes double* instead of void* for complex arrays

2017-10-06 Thread Claudius Hubig
Package: openblas
Version: 0.2.19-3
Severity: wishlist

Dear Maintainer,

OpenBLAS in version 0.2.19-3 currently installed on Debian Stretch as
well as the version 0.2.20+ds-4 in Testing declares the cblas_*() as
taking double* instead of void* for complex values. As an example, it
declares cblas_zdscal as

void cblas_zdscal(OPENBLAS_CONST blasint N, OPENBLAS_CONST double alpha, double 
*X, OPENBLAS_CONST blasint incX);

This function takes an array of complex numbers X and scales them by
the real value alpha.

In contrast to this, all other packages in Debian as well as the
Intel MKL define cblas_zdscal as taking a void* for X, i.e.:

void cblas_zdscal(const int N, const double alpha, void *X, const int incX);

See e.g. https://codesearch.debian.net/search?q=cblas_zdscal=1
or https://software.intel.com/en-us/mkl-developer-reference-c-cblas-scal
or http://www.netlib.org/blas/cblas.h

The same difference applies to the cblas_zscal() function and all others:

$ dpkg -S /usr/include/cblas.h; dpkg -S /usr/include/openblas/cblas.h; grep 
zscal /usr/include/openblas/cblas.h /usr/include/cblas.h
libblas-dev: /usr/include/cblas.h
libopenblas-dev: /usr/include/openblas/cblas.h
/usr/include/openblas/cblas.h:void cblas_zscal(OPENBLAS_CONST blasint N, 
OPENBLAS_CONST double *alpha, double *X, OPENBLAS_CONST blasint incX);
/usr/include/cblas.h:void cblas_zscal(const int N, const void *alpha, void *X, 
const int incX);

I have only noticed the issue now as cblas.h has become part of the
alternatives system and is currently directing to the OpenBLAS
version in testing. In Stretch, if also libblas-dev is installed, its
cblas.h is used and the difference hence hidden away.

I suspect that this problem is not more widespread because people
tend to cast their arguments to (void*) explicitly, but the
conversion std::complex* => void* => double* is probably
actually undefined…

There was also some discussion in 2013, but it seemed to go nowhere:
http://comments.gmane.org/gmane.comp.lib.openblas.general/192

I would be very thankful if there was some way to avoid the explicit
casts to (void*) in calls specifically for OpenBLAS.

Best wishes,

Claudius

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

Debian Release: 9.1
  990 stable  security.debian.org 
  990 stable  ftp.de.debian.org 
  500 unstableftp.de.debian.org 
  500 stable  repo.skype.com 

--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Package's Suggests field is empty.


pgpuf13nCNRtX.pgp
Description: OpenPGP digital signature


Bug#835189: python-pyrax: FTBFS (failing tests)

2017-10-06 Thread Sascha Girrulat
Hi,

fixed in git, but i got new buildproblems with python-novaclient and
it's dependencies python-keyring and dbus inside the pbuilder chroot.

==
ERROR: tests.unit.test_image (unittest.loader.ModuleImportFailure)
--
ImportError: Failed to import test module: tests.unit.test_image
Traceback (most recent call last):
  File "/usr/lib/python2.7/unittest/loader.py", line 254, in _find_tests
module = self._get_module_from_name(name)
  File "/usr/lib/python2.7/unittest/loader.py", line 232, in
_get_module_from_name
__import__(name)
  File "tests/unit/test_image.py", line 13, in 
import pyrax
  File "pyrax/__init__.py", line 42, in 
import keyring
  File "/usr/lib/python2.7/dist-packages/keyring/__init__.py", line 6,
in 
from .core import (set_keyring, get_keyring, set_password, get_password,
  File "/usr/lib/python2.7/dist-packages/keyring/core.py", line 148, in

init_backend()
  File "/usr/lib/python2.7/dist-packages/keyring/core.py", line 64, in
init_backend
keyrings = filter(limit, backend.get_all_keyring())
  File "/usr/lib/python2.7/dist-packages/keyring/util/__init__.py", line
20, in wrapper
func.always_returns = func(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/keyring/backend.py", line 191,
in get_all_keyring
exceptions=TypeError))
  File "/usr/lib/python2.7/dist-packages/keyring/util/__init__.py", line
29, in suppress_exceptions
for callable in callables:
  File "/usr/lib/python2.7/dist-packages/keyring/backend.py", line 183,
in is_class_viable
keyring_cls.priority
  File "/usr/lib/python2.7/dist-packages/keyring/util/properties.py",
line 22, in __get__
return self.fget.__get__(None, owner)()
  File
"/usr/lib/python2.7/dist-packages/keyring/backends/SecretService.py",
line 30, in priority
bus = secretstorage.dbus_init()
  File "/usr/lib/python2.7/dist-packages/secretstorage/__init__.py",
line 47, in dbus_init
return dbus.SessionBus()
  File "/usr/lib/python2.7/dist-packages/dbus/_dbus.py", line 211, in
__new__
mainloop=mainloop)
  File "/usr/lib/python2.7/dist-packages/dbus/_dbus.py", line 100, in
__new__
bus = BusConnection.__new__(subclass, bus_type, mainloop=mainloop)
  File "/usr/lib/python2.7/dist-packages/dbus/bus.py", line 122, in __new__
bus = cls._new_for_bus(address_or_type, mainloop=mainloop)
DBusException: org.freedesktop.DBus.Error.FileNotFound: Failed to
connect to socket /run/user/1000/bus: No such file or directory

Regards
Sascha

Am 18.01.2017 um 17:10 schrieb Sascha Girrulat:
> thx for the update. I try to handle it asap. I'm only short of time at
> the moment.
> 
> Regards
> Sascha
> 
> Am 17.01.2017 um 01:50 schrieb Santiago Vila:
>> retitle 835189 python-pyrax: FTBFS (failing tests)
>> thanks
>>
>> Hi.
>>
>> After building this package many times today, it always fail
>> and not just sometimes, so I'm retitling accordingly.
>>
>> As a summary, I see that the following tests always fail:
>>
>> ERROR: test_set_http_debug (tests.unit.test_module.PyraxInitTest)
>> ERROR: test_connect_to_cloudservers (tests.unit.test_module.PyraxInitTest)
>>
>> and the following one fails approximately 70% of the time:
>>
>> ERROR: test_rax_endpoints (tests.unit.test_identity.IdentityTest)
>>
>> [ The first two failing tests are the ones reported by Lucas Nussbaum
>>   in Bug #841623 ].
>>
>> Thanks.
>>
> 



signature.asc
Description: OpenPGP digital signature


Bug#871619: Packaging

2017-10-06 Thread Aron Xu
Hi,

On Fri, Oct 6, 2017 at 4:59 PM, Petter Reinholdtsen  wrote:
>
> [Antonio Russo]
>> How can I help out the packaging team on this? Who should I email?
>
> The best way to help is to continue contributing and participating on
> the team mailing list and IRC channel.
>
> Aron Xu has been most active with maintenance, and I hope he can comment
> on how you best can contribute.  I am not competent do to so. :)
>
> Any project admin on
> https://alioth.debian.org/projects/pkg-zfsonlinux/ > can grant
> access, ie Aron, Liang and Carlos.
>
> CC to Aron, and email to the bts also go to the project mailing list.
>

I've started to update the package to 0.7.2 release and it appears
there are some build system changes that installs quite some files
into non-FHS compliant paths, and possibly a new package (could be
"zfs-tests") is needed. If you are eager to help, please start from
these changes and my latest work is available on alioth git.

Regards,
Aron



Bug#877865: IMAP access to bug reports

2017-10-06 Thread Daniel Pocock
On 06/10/17 17:35, Don Armstrong wrote:
> On Fri, 06 Oct 2017, Daniel Pocock wrote:
>> Package: bugs.debian.org
>> Severity: wishlist
>>
>> Bug reports can currently be accessed in mbox format
>>
>> Has anybody looked at ways to provide read-only IMAP access to the bug
>> reports or another API that mail clients like Thunderbird could use?
> Hrm; I've not, but that sounds interesting. I'd certainly consider
> patches which enabled such a thing. [Though I'd think that having
> thunderbird open a mailbox on local disk would be pretty easy?]
>
> I did have thoughts about making a more-maildir style storage for mail,
> but it was really low on my priority list.
>

People could rsync a Maildir very easily too



Bug#877882: RM: r-cran-boolnet [hurd-i386 kfreebsd-amd64 kfreebsd-i386] -- RoQA; transitive B-D: r-cran-nmf not available

2017-10-06 Thread Andreas Beckmann
Package: ftp.debian.org
Severity: normal


$ dak rm -Rn -a hurd-i386,kfreebsd-amd64,kfreebsd-i386 r-cran-boolnet
W: -a/--architecture implies -p/--partial.
Will remove the following packages from unstable:

r-cran-boolnet |2.1.3-1 | source, hurd-i386, kfreebsd-amd64, kfreebsd-i386

Maintainer: Debian Med Packaging Team 


--- Reason ---

--

Checking reverse dependencies...
No dependency problem found.


Andreas



Bug#877881: RM: r-cran-lexrankr [hurd-i386 kfreebsd-amd64 kfreebsd-i386] -- RoQA; transitive B-D: r-cran-nmf not available

2017-10-06 Thread Andreas Beckmann
Package: ftp.debian.org
Severity: normal

$ dak rm -Rn -a hurd-i386,kfreebsd-amd64,kfreebsd-i386 r-cran-lexrankr
W: -a/--architecture implies -p/--partial.
Will remove the following packages from unstable:

r-cran-lexrankr |0.4.0-1 | source, hurd-i386, kfreebsd-amd64, kfreebsd-i386

Maintainer: Debian Med Packaging Team 


--- Reason ---

--

Checking reverse dependencies...
No dependency problem found.


Andreas



Bug#877880: RM: r-cran-phangorn [hurd-i386 kfreebsd-amd64 kfreebsd-i386] -- RoQA; transitive B-D: r-cran-nmf not available

2017-10-06 Thread Andreas Beckmann
Package: ftp.debian.org
Severity: normal

$ dak rm -Rn -a hurd-i386,kfreebsd-amd64,kfreebsd-i386 r-cran-phangorn
W: -a/--architecture implies -p/--partial.
Will remove the following packages from unstable:

r-cran-phangorn |  1.99.14-1 | source, hurd-i386, kfreebsd-amd64, kfreebsd-i386
r-cran-phangorn |2.2.0-2 | source

Maintainer: Debian Med Packaging Team 


--- Reason ---

--

Checking reverse dependencies...
# Broken Build-Depends:
r-cran-treescape: r-cran-phangorn (>= 2.0.3)

Dependency problem found.


r-cran-treescape is already not built on these architectures.


Andreas



Bug#871690: libglib2.0-0: gtk filechooser places populates with *all* filesystems

2017-10-06 Thread Martintxo
Hello

I find this: 
https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/1701780

At the end it says that the fix is in glib2.0 - 2.54.1-1ubuntu1. I installed
libglib2.0-0, libglib2.0-bin and libglib2.0-data 2.54.1-1 from sid (i'm in
testing) and that fixed my problem!!

So, for me, you can close this bug report. Many thanks for all. Greetings.

2017/09/10 13:11 (ig.) eguna,
Michael Biebl (e)k idatzi zuen:

> Am 10.09.2017 um 12:15 schrieb Martintxo:
> 
> > By other side, I need to inform that I'm not using any desktop environment,
> > I use a plain Icewm, and not use nor udisks, nor gvfs. If that's a problem,
> > you can forget this report, but I think that this is a important issue...
> >   
> 
> I guess no-one of the GNOME maintainers actually uses glib without
> gvfs/udisks. Most likely your issue would be solved if you use those
> packages.
> So if you want to see this addressed I guess it's up to you to further
> investigate this on your own, i.e. which changes in glib caused this new
> behaviour
> 
> 
> -- 
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
> 



Sustrai Erakuntza: respuesta jurídico-técnica a proyectos insostenibles.
  proiektu jasangaitzei erantzun juridiko-teknikoa.
  http://www.fundacionsustrai.org
  http://www.sustraierakuntza.org



Bug#877878: ITP: mailman3-suite -- Django project integrating Mailman3 Postorius and HyperKitty

2017-10-06 Thread Jonas Meurer
Package: wnpp
Severity: wishlist
Owner: Jonas Meurer 

* Package name: mailman3-suite
  Version : 0+20170523
  Upstream Author : Free Software Foundation, Inc
* URL : https://gitlab.com/mailman/mailman-suite
* License : GPL-3
  Programming Lang: Python
  Description : Django project integrating Mailman3 Postorius and HyperKitty

This django web application provides the Mailman3 Postorius web interface
and the HyperKitty mailinglist archiver integrated into one project and
made available via uwsgi.

This package will be maintained under the pkg-mailman umbrella.

Cheers
 jonas



Bug#877879: RM: r-cran-igraph [hurd-i386 kfreebsd-amd64 kfreebsd-i386] -- RoQA; B-D: r-cran-nmf not available

2017-10-06 Thread Andreas Beckmann
Package: ftp.debian.org
Severity: normal

$ dak rm -Rn -a hurd-i386,kfreebsd-amd64,kfreebsd-i386 r-cran-igraph
W: -a/--architecture implies -p/--partial.
Will remove the following packages from unstable:

r-cran-igraph |0.7.1-1 | source
r-cran-igraph | 0.7.1-1+b1 | hurd-i386, kfreebsd-amd64, kfreebsd-i386
r-cran-igraph |1.1.2-2 | source

Maintainer: Debian Med Packaging Team 


--- Reason ---

--

Checking reverse dependencies...
# Broken Depends:
r-bioc-phyloseq: r-bioc-phyloseq
r-cran-boolnet: r-cran-boolnet
r-cran-lexrankr: r-cran-lexrankr
r-cran-phangorn: r-cran-phangorn

# Broken Build-Depends:
r-bioc-phyloseq: r-cran-igraph
r-cran-adegenet: r-cran-igraph
r-cran-boolnet: r-cran-igraph
r-cran-lexrankr: r-cran-igraph
r-cran-phangorn: r-cran-igraph (>= 1.0)

Dependency problem found.


r-bioc-phyloseq is arch:all, will file RM requests for the others if needed.


Andreas



Bug#877865: IMAP access to bug reports

2017-10-06 Thread Don Armstrong
On Fri, 06 Oct 2017, Daniel Pocock wrote:
> Package: bugs.debian.org
> Severity: wishlist
> 
> Bug reports can currently be accessed in mbox format
> 
> Has anybody looked at ways to provide read-only IMAP access to the bug
> reports or another API that mail clients like Thunderbird could use?

Hrm; I've not, but that sounds interesting. I'd certainly consider
patches which enabled such a thing. [Though I'd think that having
thunderbird open a mailbox on local disk would be pretty easy?]

I did have thoughts about making a more-maildir style storage for mail,
but it was really low on my priority list.

-- 
Don Armstrong  https://www.donarmstrong.com

G: If we do happen to step on a mine, Sir, what do we do?
EB: Normal procedure, Lieutenant, is to jump 200 feet in the air and
scatter oneself over a wide area.
 -- Somewhere in No Man's Land, BA4



Bug#877877: devscripts: debchange manpage out of sync with help-text

2017-10-06 Thread Jerome Charaoui
Package: devscripts
Version: 2.17.6+deb9u1
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

The manpage for the debchange script is out of sync with the help-text provided
by it.

Specifically, the --bpo argument description found in the manpage mentions
"jessie-backports", while the help-text (correctly) mentions "stretch-
backports".

Thanks.



- -- Package-specific info:

- --- /etc/devscripts.conf ---

- --- ~/.devscripts ---
BTS_SMTP_HOST=ssmtp://mail.riseup.net
DEBSIGN_KEYID=0B5A33B8A26D60109C509C6C83E33BD7D4DD4CA1
DEBUILD_LINTIAN=yes
DEBUILD_LINTIAN_OPTS="--info --display-info --pedantic"

- -- System Information:
Debian Release: 9.1
  APT prefers stable
  APT policy: (900, 'stable'), (1, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.12.0-0.bpo.1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_CA.utf8, LC_CTYPE=fr_CA.utf8 (charmap=ANSI_X3.4-1968) (ignored: 
LC_ALL set to C), LANGUAGE=fr_CA.utf8 (charmap=ANSI_X3.4-1968) (ignored: LC_ALL 
set to C)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages devscripts depends on:
ii  dpkg-dev  1.18.24
ii  libc6 2.24-11+deb9u1
ii  libfile-homedir-perl  1.00-1
ii  perl  5.24.1-3+deb9u2
ii  python3   3.5.3-1

Versions of packages devscripts recommends:
ii  apt 1.4.7
ii  at  3.1.20-3
ii  curl7.52.1-5
ii  dctrl-tools 2.24-2+b1
ii  debian-keyring  2017.05.28
ii  dput-ng [dput]  1.13
ii  equivs  2.0.9+nmu1
ii  fakeroot1.21-3.1
ii  file1:5.30-1+deb9u1
ii  gnupg   2.1.18-6
ii  gnupg2  2.1.18-6
ii  libdistro-info-perl 0.14
ii  libdpkg-perl1.18.24
ii  libencode-locale-perl   1.05-1
ii  libgit-wrapper-perl 0.047-1
ii  liblist-compare-perl0.53-1
ii  liblwp-protocol-https-perl  6.06-2
ii  libsoap-lite-perl   1.20-1
ii  liburi-perl 1.71-1
ii  libwww-perl 6.15-1
ii  licensecheck3.0.29-1
ii  lintian 2.5.53~bpo9+1
ii  man-db  2.7.6.1-2
ii  patch   2.7.5-1+b2
ii  patchutils  0.3.4-2
ii  python3-debian  0.1.30
ii  python3-magic   1:5.30-1+deb9u1
ii  sensible-utils  0.0.9
ii  strace  4.15-2
ii  unzip   6.0-21
ii  wdiff   1.2.2-2
ii  wget1.18-5
ii  xz-utils5.2.2-1.2+b1

Versions of packages devscripts suggests:
ii  adequate 0.15.1
ii  autopkgtest  4.4
pn  bls-standalone   
ii  bsd-mailx [mailx]8.1.2-0.20160123cvs-4
ii  build-essential  12.3
pn  check-all-the-things 
pn  cvs-buildpackage 
pn  devscripts-el
pn  diffoscope   
pn  disorderfs   
pn  dose-extra   
pn  duck 
pn  faketime 
ii  gnuplot  5.0.5+dfsg1-6+deb9u1
ii  gpgv 2.1.18-6
ii  how-can-i-help   15
ii  libauthen-sasl-perl  2.1600-1
ii  libfile-desktopentry-perl0.22-1
ii  libnet-smtps-perl0.04-1
pn  libterm-size-perl
ii  libtimedate-perl 2.3000-2
pn  libyaml-syck-perl
pn  mozilla-devscripts   
ii  mutt 1.7.2-1
ii  openssh-client [ssh-client]  1:7.4p1-10+deb9u1
ii  piuparts 0.77
pn  ratt 
pn  reprotest
pn  svn-buildpackage 
ii  w3m  0.5.3-34

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJGBAEBCgAwFiEEC1ozuKJtYBCcUJxsg+M719TdTKEFAlnXoqcSHGplcm9tZUBy
aXNldXAubmV0AAoJEIPjO9fU3Uyh1OgQAI08SZNqFMVKb1/fjohBQmJKkUWRoHvM
3qjKOxueaKgSLT9SveXMrsYSmqXVG3cGt0KNnHClP5EZvx2itJGELLhvET11dtfX
IMWvwlPOVcZ+L8BuQ6BXMhtH32EGYxMhzN9oD/HFDRcvA+Sc1kafRNQRJjwHOWq4
shlJVkAQdZiV8pyqxlubc/dY6mSbHDo4PrEq/RatIAK34JVJClSddcxPVqoY9a3y
VYxXUvj7sTKo72iHLFN6mdveEgFgCgLhUX4H404rLmXBkPNDCdxAhBYdrjYBCKac
vTuME9y+kwcngOgnz7UyC+nGI/sld2ctQA3F1RDre1xmPDRiOfE4UHHWdW0GKh1e
Mv0EhRj4H7pdNrYuGGrZ3BnHAAKgO336cxhGN5M+8l0TcP9gXN3PWdOmRGJHMJ/F
7U/+Mkk3YHuyVgA7mUxZ8PaoMT6miViwSRSFhh/pxiTP09AcHvOTP5uigDlRwBKq
lKvNd761Smmc+37OnYxC/bV6DjRGGIXGWgzNcBbPnOZC4njjwwE/gZdijR7To1yy
1wEl4IQ71xl8R4Z4vOEa9UQVFwqidWEjtvr6juOPquZmVBOyeXQCALwieBzhYOpU
pgX+xheYsC018/Mkyndl+D0U1Lsskc2h/gD4cPYfACiDxZOBFTa79hA76g+Jpgh2
Q21eK3qWux1M
=Sw9F
-END PGP SIGNATURE-



Bug#877876: python-zaqarclient: FTBFS: ModuleNotFoundError: No module named 'requests_mock'

2017-10-06 Thread Andreas Beckmann
Source: python-zaqarclient
Version: 1.7.0-1
Severity: serious
Justification: fails to build from source

Hi,

python-zaqarclient FTBFS in an up-to-date sid+experimental environment:

[...]
==
ERROR: Failure: ModuleNotFoundError (No module named 'requests_mock')
--
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/nose/failure.py", line 39, in runTest
raise self.exc_val.with_traceback(self.tb)
  File "/usr/lib/python3/dist-packages/nose/loader.py", line 418, in 
loadTestsFromName
addr.filename, addr.module)
  File "/usr/lib/python3/dist-packages/nose/importer.py", line 47, in 
importFromPath
return self.importFromDir(dir_path, fqname)
  File "/usr/lib/python3/dist-packages/nose/importer.py", line 94, in 
importFromDir
mod = load_module(part_fqname, fh, filename, desc)
  File "/usr/lib/python3.6/imp.py", line 235, in load_module
return load_source(name, filename, file)
  File "/usr/lib/python3.6/imp.py", line 172, in load_source
module = _load(spec)
  File "", line 684, in _load
  File "", line 665, in _load_unlocked
  File "", line 678, in exec_module
  File "", line 219, in _call_with_frames_removed
  File "/build/python-zaqarclient-1.7.0/tests/unit/cli/v1/test_queues.py", line 
16, in 
from tests.unit.cli import fakes
  File "/build/python-zaqarclient-1.7.0/tests/unit/cli/fakes.py", line 18, in 

from osc_lib.tests import utils
  File "/usr/lib/python3/dist-packages/osc_lib/tests/utils.py", line 27, in 

from requests_mock.contrib import fixture
ModuleNotFoundError: No module named 'requests_mock'

--
Ran 190 tests in 0.201s

FAILED (errors=1)
debian/rules:13: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 1
make[1]: Leaving directory '/build/python-zaqarclient-1.7.0'


Andreas


python-zaqarclient_1.7.0-1.log.gz
Description: application/gzip


Bug#877875: python-requestsexceptions: insufficiently versioned B-D: python-pbr/python3-pbr

2017-10-06 Thread Andreas Beckmann
Source: python-requestsexceptions
Version: 1.3.0-1
Severity: serious
Justification: fails to build from source

Hi,

python-requestsexceptions FTBFS in a current sid+experimental
environment with the sid versions of python-pbr/python3-pbr (1.10.0-1):

 fakeroot debian/rules clean
pyversions: missing X(S)-Python-Version in control file, fall back to 
debian/pyversions
pyversions: missing debian/pyversions file, fall back to supported versions
py3versions: no X-Python3-Version in control file, using supported versions
dh clean --buildsystem=python_distutils --with python2,python3
   dh_auto_clean -O--buildsystem=python_distutils
pyversions: missing X(S)-Python-Version in control file, fall back to 
debian/pyversions
pyversions: missing debian/pyversions file, fall back to supported versions
python setup.py clean -a
Download error on https://pypi.python.org/simple/pbr/: [Errno -3] Temporary 
failure in name resolution -- Some packages may not be found!
Download error on https://pypi.python.org/simple/: [Errno -3] Temporary failure 
in name resolution -- Some packages may not be found!
No local packages or working download links found for pbr>=2.0.0
Traceback (most recent call last):
  File "setup.py", line 29, in 
pbr=True)
  File "/usr/lib/python2.7/distutils/core.py", line 111, in setup
_setup_distribution = dist = klass(attrs)
  File "/usr/lib/python2.7/dist-packages/setuptools/dist.py", line 325, in 
__init__
self.fetch_build_eggs(attrs['setup_requires'])
  File "/usr/lib/python2.7/dist-packages/setuptools/dist.py", line 446, in 
fetch_build_eggs
replace_conflicting=True,
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 855, 
in resolve
dist = best[req.key] = env.best_match(req, ws, installer)
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 1127, 
in best_match
return self.obtain(req, installer)
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 1139, 
in obtain
return installer(requirement)
  File "/usr/lib/python2.7/dist-packages/setuptools/dist.py", line 518, in 
fetch_build_egg
return cmd.easy_install(req)
  File "/usr/lib/python2.7/dist-packages/setuptools/command/easy_install.py", 
line 691, in easy_install
raise DistutilsError(msg)
distutils.errors.DistutilsError: Could not find suitable distribution for 
Requirement.parse('pbr>=2.0.0')
dh_auto_clean: python setup.py clean -a returned exit code 1
debian/rules:7: recipe for target 'clean' failed
make: *** [clean] Error 1


Andreas

PS: network access is not available during build


python-requestsexceptions_1.3.0-1.log.gz
Description: application/gzip


Bug#877842: Pending fixes for bugs in the libxml-compile-soap-perl package

2017-10-06 Thread pkg-perl-maintainers
tag 877842 + pending
thanks

Some bugs in the libxml-compile-soap-perl package are closed in
revision f7069513ccdbea788a13a574cca967dce98d13e6 in branch 'master'
by gregor herrmann

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-perl/packages/libxml-compile-soap-perl.git/commit/?id=f706951

Commit message:

Add build dependencies on libtest-deep-perl and libxml-compile-tester-perl.

Thanks: Andreas Beckmann for the bug report.
Closes: #877842



Bug#877874: RM: qlvnictools -- ROM; dead upstream, low popcorn, no maintainers

2017-10-06 Thread Ana Guerrero Lopez
Package: ftp.debian.org
Severity: normal

Please, remove qlvnictools from the archive.

Thank you,
Ana



Bug#877870: lighttpd: "reload" action breaks further actions

2017-10-06 Thread Stefan Bühler
Hi,

(upstream) 1.4.46 will contain an updated unit file which includes a 
reload action, see


https://git.lighttpd.net/lighttpd/lighttpd1.4.git/commit/?h=0ae6bab4a97f12a0c93200df36ac1741696eeed5

for details.

(Afaics the debian packages installs the upstream unit file).

On 10/06/2017 03:53 PM, Andreas Hasenack wrote:
> Package: lighttpd
> Version: 1.4.45-1
> Severity: normal
> 
> Dear Maintainer,
> 
> After you issue a "service lighttpd reload" (or call /etc/init.d/lighttpd
> directly with the same action), all further actions stop working.
> 
> This happens because the "reload" action is not defined in the systemd
> service file, so the code in /etc/init.d/lighttpd is used. That code in
> turn restarts the service. When you later run status/stop/start/restart,
> these are done via systemd and it thinks the service is dead because the
> PID changed.
> 
> For example, starting with a running lighttpd:
> root@sid-lighttpd-reload-1721635:~# ps fxaw
>   PID TTY  STAT   TIME COMMAND
> (...)
> 17184 ?Ss 0:00 /usr/sbin/lighttpd -D -f
> /etc/lighttpd/lighttpd.conf
> root@sid-lighttpd-reload-1721635:~# service lighttpd status
> ● lighttpd.service - Lighttpd Daemon
>Loaded: loaded (/lib/systemd/system/lighttpd.service; enabled; vendor
> preset: enabled)
>Active: active (running) since Fri 2017-10-06 13:48:53 UTC; 4s ago
> (...)
> 
> Let's reload:
> root@sid-lighttpd-reload-1721635:~# service lighttpd reload
> [ ok ] Reloading web server configuration: lighttpd.
> 
> Status now is dead:
> root@sid-lighttpd-reload-1721635:~# service lighttpd status
> ● lighttpd.service - Lighttpd Daemon
>Loaded: loaded (/lib/systemd/system/lighttpd.service; enabled; vendor
> preset: enabled)
>Active: inactive (dead) since Fri 2017-10-06 13:49:08 UTC; 2s ago
>   Process: 17184 ExecStart=/usr/sbin/lighttpd -D -f
> /etc/lighttpd/lighttpd.conf (code=exited, status=0/SUCCESS)
>   Process: 17177 ExecStartPre=/usr/sbin/lighttpd -tt -f
> /etc/lighttpd/lighttpd.conf (code=exited, status=0/SUCCESS)
>  Main PID: 17184 (code=exited, status=0/SUCCESS)
> 
> But it's still running, albeit a new copy:
> root@sid-lighttpd-reload-1721635:~# ps fxaw
>   PID TTY  STAT   TIME COMMAND
> (...)
> 17231 ?S  0:00 /usr/sbin/lighttpd -f /etc/lighttpd/lighttpd.conf
> 
> "start" will fail now, for example:
> root@sid-lighttpd-reload-1721635:~# service lighttpd status
> ● lighttpd.service - Lighttpd Daemon
>Loaded: loaded (/lib/systemd/system/lighttpd.service; enabled; vendor
> preset: enabled)
>Active: failed (Result: exit-code) since Fri 2017-10-06 13:51:25 UTC;
> 836ms ago
>   Process: 17391 ExecStart=/usr/sbin/lighttpd -D -f
> /etc/lighttpd/lighttpd.conf (code=exited, status=255)
>   Process: 17384 ExecStartPre=/usr/sbin/lighttpd -tt -f
> /etc/lighttpd/lighttpd.conf (code=exited, status=0/SUCCESS)
>  Main PID: 17391 (code=exited, status=255)
> 
> Oct 06 13:51:25 sid-lighttpd-reload-1721635 systemd[1]: lighttpd.service:
> Unit entered failed state.
> Oct 06 13:51:25 sid-lighttpd-reload-1721635 systemd[1]: lighttpd.service:
> Failed with result 'exit-code'.
> 
> journalctl shows the reason:
> Oct 06 13:51:24 sid-lighttpd-reload-1721635 lighttpd[17377]: 2017-10-06
> 13:51:24: (network.c.464) can't bind to port:  80 Address already in use
> 
> Managing this service via systemd or sysv is now effectively broken.
> 



Bug#877873: RM: libpcap-dev [all] -- RoQA; obsolete arch:all package

2017-10-06 Thread Andreas Beckmann
Package: ftp.debian.org
Severity: normal

Hi,

libpcap-dev is now arch:any

libpcap-dev | 1.8.1-4   | unstable   | all
libpcap-dev | 1.8.1-5   | unstable   | amd64, arm64, armel, armhf, 
hurd-i386, i386, kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, 
powerpc, ppc64el, s390x


Andreas



Bug#877841: Pending fixes for bugs in the libxml-compile-wsdl11-perl package

2017-10-06 Thread pkg-perl-maintainers
tag 877841 + pending
thanks

Some bugs in the libxml-compile-wsdl11-perl package are closed in
revision e18c54cebaef92fba9a7405ffdad1ca88f4629b2 in branch 'master'
by gregor herrmann

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-perl/packages/libxml-compile-wsdl11-perl.git/commit/?id=e18c54c

Commit message:

Add build dependency on libxml-compile-tester-perl.

Thanks: Andreas Beckmann for the bug report.
Closes: #877841



Bug#877872: RM: r-cran-backports [all] -- RoQA; obsolete arch:all package

2017-10-06 Thread Andreas Beckmann
Package: ftp.debian.org
Severity: normal

* package r-cran-backports in version 1.0.5-1 is no longer built from source
  - suggested command:
dak rm -m "[auto-cruft] no longer built from source" -s unstable -a all -p 
-R -b r-cran-backports
  - broken Depends:
r-cran-checkmate: r-cran-checkmate
r-cran-rprojroot: r-cran-rprojroot
  - broken Build-Depends:
r-cran-checkmate: r-cran-backports
r-cran-rprojroot: r-cran-backports

r-cran-backports is now arch:any:

r-cran-backports | 1.0.5-1   | unstable   | all
r-cran-backports | 1.1.1-1   | unstable   | source, amd64, arm64, 
armel, armhf, hurd-i386, i386, kfreebsd-amd64, kfreebsd-i386, mips, mips64el, 
mipsel, powerpc, ppc64el, s390x


Andreas



Bug#877871: RFP: pyside2 -- Python bindings for Qt5

2017-10-06 Thread W. Martin Borgert

Package: wnpp
Severity: wishlist

* Package name: pyside2
  Version : 2.0.0.dev0
  Upstream Author : PySide2 Team 
* URL : https://wiki.qt.io/PySide
* License : LGPL3, GPL3+
  Programming Lang: C++, Python
  Description : Python bindings for Qt5

(information mainly from
https://code.qt.io/cgit/pyside/pyside-setup.git/tree/setup.py)

Long description can probably copied from pyside.

PySide2 is the successor of PySide and is a dependency for
at least FreeCAD and python-ghost. PySide will be removed
from Debian soon, so PySide2 must be packaged.

Dominique Belhachemi  explains how to
get PySide2 from a Ubuntu PPA on Debian:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784512#78

Maybe also helpful:
https://wiki.qt.io/PySide2_GettingStarted
--
"Furthermore, I consider that PySide2 must be packaged" -- Qt the Elder



Bug#870860: openjfx: CVE-2017-10086 CVE-2017-10114

2017-10-06 Thread Moritz Muehlenhoff
On Fri, Oct 06, 2017 at 04:27:02PM +0200, Emmanuel Bourg wrote:
> Hi,
> 
> Quick update on openjfx: the package is back on track, as of version
> 8u141-b14-3 I eventually managed to get it to build on both amd64 and
> i386 in unstable for the first time since January. If the tests go well
> I'll prepare the security update next week.

Thanks.

Cheers,
Moritz



Bug#870860: openjfx: CVE-2017-10086 CVE-2017-10114

2017-10-06 Thread Emmanuel Bourg
Hi,

Quick update on openjfx: the package is back on track, as of version
8u141-b14-3 I eventually managed to get it to build on both amd64 and
i386 in unstable for the first time since January. If the tests go well
I'll prepare the security update next week.

Emmanuel Bourg



Bug#874868: [Pkg-ime-devel] Bug#874868: [fcitx] Future Qt4 removal from Buster

2017-10-06 Thread Lisandro Damián Nicanor Pérez Meyer
On 6 October 2017 at 10:23, Aron Xu  wrote:
[snip]
>>> I'd like to remove Qt4 support from fcitx in the last minute of our
>>> actions because quite some users do depend on part of it to input text
>>> into Qt4 applications. Will keep an eye on the progress, thank you.
>>
>> Would this be just for fcitx or for all the ficitx-* packages?
[snip]
> Only fcitx is relevant, we'll try to migrate all other fcitx-*
> packages as soon as possible.

In that case I suggest you wait until the bug's severity is increased
to the RC level (serious).


-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/



  1   2   >