Bug#831977: [libreoffice-calc] I can confirm bug831977 with Debian's own version but not upstream

[Thomas Hackert]

Good morning Rene, *,
On Thu, Jul 21, 2016 at 08:23:48PM +0200, Rene Engelhard wrote:
> tag 831977 confirmed
> forwarded 831977 https://bugs.documentfoundation.org/show_bug.cgi?id=100841
> tag 831977 + upstream
> thanks
> 
> On Thu, Jul 21, 2016 at 11:24:24AM +0200, Thomas Hackert wrote:
> > as the one who did some further testing with my parallel installed
> > versions of LO and recommended D. to report it here, I just want to
> 
> Aha.
> 
> > add my system's information in case this is of any importance ... ;)
> 
> Not really, if you used the script for -core, yes, maybe, due to reportbug
> shortcomings here, not really. It e.g. doesn't show the installed VCLplugs...

where do I find this script? Is it included in one of the LO
packages?

> (BTW: I see you are not using Debian but a crude mix of Ubuntu ppa,
> testing and stable-security, where the first one is questionable and the last
> one nonsense, testing either has newer versions or stuff in stable might not
> be compatible anymore - transitions, etc..)

Oh, I know, that this seems to be a crude mix ... ;) But all
security entries are those which were included after Debian's
installation AFAIKR. Do you mean I can remove them?

And the PPA is an entry for a newer version of Java. Then there are
my own entries for ownCloud, MariaDB, VirtualBox and the like.

> > For further information, please see my comment at
> > https://bugs.documentfoundation.org/show_bug.cgi?id=100841#c10.
> 
> Well, "it works here and not there". Where we obviously don't patch this
> stuff, so it's a interesting information but nothing which helps ;)

O.K.

> But yeah, I can confirm this in 5.1.5~rc1-1, too. Even with UI render: 
> standard
> (which is the immediate difference I can see in your above-mentioned comment)

Yes.

> I checked:
> - default install: libreoffice-gtk3: no tooltip
> - libreoffice-gtk3 removed so neither gtk2 or gtk3: tooltip
> - install libreoffice-gtk: LO picks up gtk(2): tooltip

Thanks for checking :)

> so it seems to be gtk3-only?

Not sure, sorry ... :( I have never installed gtk for itself, but as
dependencies to the one or the other package.
Have a nice day
Thomas.

-- 
Perhaps Debian is concerned more about technical excellence rather than
ease of use by breaking software. In the former we may excel.  In the
latter we have to concede the field to Microsoft. Guess where I want to go
today?
-- Manoj Srivastava

Bug#832088: sed: silently fails with -n option specified first

[Daniel Iancu]

Package: sed
Version: 4.2.2-4+b1
Severity: normal

Sed silently fails when -n option is specified first and leaves
the file blank. Thus resulting in the loss of the file contents.
Example:
# cd /tmp
echo 'foo' > test
sed -ni 's/foo/bar/' test # fails

echo 'foo' > test
sed -in 's/foo/bar/' test # works

Bug#830102: sitesummary: autopkgtest failure

[Petter Reinholdtsen]

[Jeremy Bicha]
> Failed to upload, answer 'HTTP/1.1 500 Internal Server Error

Hm, I managed to get it tested manually, but obviously something is
still missing.  Anything in the apache log?

-- 
Happy hacking
Petter Reinholdtsen

Bug#825562: dovecot-imapd: service fail to start at boot time

[Apollon Oikonomopoulos]

Control: tags -1 moreinfo

Hi,

On 21:55 Fri 27 May , zulu wrote:
> Package: dovecot-imapd
> Version: 1:2.2.24-1
> Severity: normal
> 
> Dear Maintainer,
> 
> At machine startup, dovecot-imap fail telling:
> May 27 21:37:51 cop21 dovecot[502]: Error: bind(192.168.0.36, 143) failed: 
> Cannot assign requested address
> May 27 21:37:51 cop21 dovecot[502]: Error: service(imap-login): 
> listen(192.168.0.36, 143) failed: Cannot assign requested address
> May 27 21:37:51 cop21 dovecot[502]: Error: bind(192.168.0.36, 993) failed: 
> Cannot assign requested address
> May 27 21:37:51 cop21 dovecot[502]: Error: service(imap-login): 
> listen(192.168.0.36, 993) failed: Cannot assign requested address
> May 27 21:37:51 cop21 dovecot[502]: Fatal: Failed to start listeners
> May 27 21:37:51 cop21 dovecot[502]: master: Error: bind(192.168.0.36, 143) 
> failed: Cannot assign requested address
> May 27 21:37:51 cop21 dovecot[502]: master: Error: service(imap-login): 
> listen(192.168.0.36, 143) failed: Cannot assign requested address
> May 27 21:37:51 cop21 dovecot[502]: master: Error: bind(192.168.0.36, 993) 
> failed: Cannot assign requested address
> May 27 21:37:51 cop21 dovecot[502]: master: Error: service(imap-login): 
> listen(192.168.0.36, 993) failed: Cannot assign requested address
> May 27 21:37:51 cop21 dovecot[502]: master: Fatal: Failed to start listeners
> May 27 21:37:51 cop21 systemd[1]: dovecot.service: Control process exited, 
> code=exited status=89
> May 27 21:37:51 cop21 systemd[1]: Failed to start Dovecot IMAP/POP3 email 
> server.
> May 27 21:37:51 cop21 systemd[1]: dovecot.service: Unit entered failed state.
> May 27 21:37:51 cop21 systemd[1]: dovecot.service: Failed with result 
> 'exit-code'.
> 
> manually restarting the service after boot works
> I suppose this is related to systemd not starting the network interface 
> before starting
> the dovecot-imap daemon?

Indeed, it looks like 192.168.0.36 has not been assigned (yet?) to the 
interface. Do you use /etc/network/interfaces or systemd-networkd for 
interface configuration? Can you provide the contents of 
/etc/network/interfaces or /etc/systemd/network/* respectively? Also, 
can you please provide the output of

 systemd-analyze dot dovecot.service network.target

As a workaround you could either use non-local binds (echo 1 > 
/proc/sys/net/ipv4/ip_nonlocal_bind) or bind to the wildcard address 
(0.0.0.0) if that's okay with your setup.

Regards,
Apollon

Bug#804622: -x auth_info is a required parameter, at least with SQL

[Apollon Oikonomopoulos]

Hi Martin,

On 22:00 Tue 12 Jul , martin f krafft wrote:
> Attached is the auth conf. The failing command is 'doveadm auth'
> without any -x parameter.

I'm afraid we'll also need the actual query from dovecot-sql.conf.ext.

Regards,
Apollon

Bug#775190: tex4ht-common: Solved in TexLive (was: Re: scrreprt is broken)

[Tobias Schlemmer]

Package: tex4ht-common
Version: 20090611-3
Followup-For: Bug #775190

Hi,

I came about the same bug which affects all KOMA script packages. It has been
resolved upstream, already. The fix has been included (together whith other
fixes) into texlive.

Maybe it would be a good idea to integrate at least tex4ht-common with the
texlive debian packages.




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

Kernel: Linux 4.5.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages tex4ht-common depends on:
ii  texlive-binaries [texlive-base-bin]  2016.20160513.41080-4

Versions of packages tex4ht-common recommends:
ii  dvipng  1.14-2+b2
ii  tex4ht  20090611-3
ii  zip 3.0-11

Versions of packages tex4ht-common suggests:
ii  default-jdk-headless  2:1.8-57
ii  default-jre-headless  2:1.8-57
ii  ghostscript   9.19~dfsg-1+b1
ii  imagemagick   8:6.8.9.9-7+b2
ii  libxml2-utils 2.9.3+dfsg1-1
ii  netpbm2:10.0-15.3+b1

-- no debconf information

Bug#831977: [libreoffice-calc] I can confirm bug831977 with Debian's own version but not upstream

[Rene Engelhard]

Hi,

On Fri, Jul 22, 2016 at 08:58:37AM +0200, Thomas Hackert wrote:
> where do I find this script? Is it included in one of the LO
> packages?

yes. /usr/share/bug//script. Here I mean

/usr/share/bug/libreoffice-core/script (run it as
/usr/share/bug/libreoffice-core/script 3>&1)

> > (BTW: I see you are not using Debian but a crude mix of Ubuntu ppa,
> > testing and stable-security, where the first one is questionable and the 
> > last
> > one nonsense, testing either has newer versions or stuff in stable might not
> > be compatible anymore - transitions, etc..)
> 
> Oh, I know, that this seems to be a crude mix ... ;) But all
> security entries are those which were included after Debian's
> installation AFAIKR. Do you mean I can remove them?

No, they weren't. They were when you installed it as stable. When you upgraded
to testing they are left-overs.

> > so it seems to be gtk3-only?
> 
> Not sure, sorry ... :( I have never installed gtk for itself, but as
> dependencies to the one or the other package.

But you also can look up what VCLplug you use etc.

Regards,

Rene

Bug#819530: transition: icu

[GCS]

Hi Emilio,

On Thu, Jul 21, 2016 at 5:02 PM, Emilio Pozuelo Monfort
 wrote:
> On 30/03/16 07:38, Laszlo Boszormenyi (GCS) wrote:
>> ICU has a new major upstream release, supporting several new things
>> that I would like to see in Stretch:
>> - CLDR[1] 28 [2] and 29 [3] support,
>> - Unicode 8.0.0 [4] support.
>
> What's the status of this? I see it is in experimental now. Have you
> build-tested all the reverse-deps?
 Back in time I had big hardware problems and only tested LibreOffice,
which was successful. HW issues is softened by Martin F. Krafft and
Jeffrey Walton since DebConf'16. Catching up with my backlog and the
big rebuild session planned to this weekend.
Meanwhile Ubuntu took my ICU package from experimental and made it
default without any additional patch to their upcoming Yakkety Yak
release[1]. This is a good sign that it doesn't have any problem, but
better to wait my own results. Is amd64 / i386 rebuilds enough or
should I try kFreeBSD i386 / amd64 and/or (emulated) ARM64 rebuilds?

Cheers,
Laszlo/GCS
[1] https://launchpad.net/ubuntu/yakkety/+source/icu

Bug#832089: ITP: libsys-cpuaffinity-perl -- set CPU affinity for processes

[Michael Prokop]

Package: wnpp
Severity: wishlist
Owner: Michael Prokop 

* Package name: libsys-cpuaffinity-perl
  Version : 1.06
  Upstream Author : Marty O'Brien 
* URL : https://metacpan.org/release/Sys-CpuAffinity
* License : Artistic / GPL
  Programming Lang: Perl
  Description : set CPU affinity for processes

 The details of getting and setting process CPU affinities varies greatly from
 system to system. Even among the different flavors of Unix there is very
 little in the way of a common interface to CPU affinities. The existing tools
 and libraries for setting CPU affinities are not very standardized, so that a
 technique for setting CPU affinities on one system may not work on another
 system with the same architecture.
 .
 Sys::CpuAffinity seeks to do one thing and do it well: manipulate CPU
 affinities through a common interface on as many systems as possible, by any
 means necessary.
 .
 The module is composed of several subroutines, each one implementing a
 different technique to perform a CPU affinity operation. A technique might
 try to import a Perl module, run an external program that might be installed
 on your system, or invoke some C code to access your system libraries.
 Usually, a technique is applicable to only a single or small group of
 operating systems, and on any particular system, the vast majority of
 techniques would fail. Regardless of your particular system and
 configuration, it is hoped that at least one of the techniques will work and
 you will be able to get and set the CPU affinities of your processes.

Note: One of the companies I'm working for plans to use this package
and we want to contribute this package back to Debian, work will be
done under the Perl pkg group umbrella as usual.

regards,
-mika-

Bug#829272: [openssl.org #4602] Missing accessors

[Mattias Ellert]

tor 2016-07-21 klockan 09:51 + skrev Richard Levitte via RT:
> On Thu Jul 21 08:18:30 2016, mattias.ell...@physics.uu.se wrote:
> > 
> > ons 2016-07-20 klockan 15:14 + skrev Richard Levitte via RT:
> > > 
> > > On Mon Jul 11 11:34:35 2016, mattias.ell...@physics.uu.se wrote:
> > > > 
> > > > 
> > > > I guess having a more restrictive accessor that only sets the
> > > > EXFLAG_PROXY bit could work. I suggested the more general
> > > > solution
> > > > of
> > > > having set/clear accessors for arbitrary flags since it was -
> > > > well
> > > > more
> > > > general.
> > > 
> > > So let me ask this in a different manner, does OpenSSL 1.1 still
> > > not
> > > set the
> > > EXFLAG_PROXY flag correctly? In what situations does that happen?
> > > That may be
> > > worth a bug report of its own.
> > > 
> > > --
> > > Richard Levitte
> > > levi...@openssl.org
> > > 
> > 
> > The answer to this is related to Mischa's reply, which
> > unfortunately
> > was only sent to the Debian BTS and not the the OpenSSL RT. I quote
> > it
> > below. As indicated in the answer, setting the EXFLAG_PROXY allows
> > handling non-RFC proxies in OpenSSL.
> > 
> > mån 2016-07-11 klockan 14:53 +0200 skrev Mischa Salle:
> > > 
> > > Hi Richard, Mattias, others,
> > > 
> > > I agree with you that it would be nice if OpenSSL could figure
> > > out
> > > itself whether a cert needs to be treated as a proxy, but
> > > currently
> > > that
> > > doesn't work reliably as far as I know.
> > > The flag is certainly needed in the case of non-RFC3820 proxies,
> > > also
> > > known as legacy proxies. Unfortunately these are still very
> > > widely
> > > used
> > > (majority of the proxies actually) and hence our code must be
> > > able to
> > > handle them correctly.
> > > 
> > > Best wishes,
> > > Mischa Sallé
> > > 
> 
> Ok... From looking at the voms code that was linked to earlier, I can
> see that
> legacy proxy certs are recognised by an older OID (called
> PROXYCERTINFO_V3 in
> the code), 1.3.6.1.4.1.3536.1.222. Is there a spec for the extensions
> in that
> version, whether they are critical or not and so on, that I can
> reach? Or is
> the OID the only actual difference? If it's easy enough (and it
> currently does
> look quite easy), I can certainly see adding some code in OpenSSL to
> recognise
> those...
> 
> --
> Richard Levitte
> levi...@openssl.org

As far as I know there are three different kinds of proxies, usually
called "legacy", "draft" and "rfc", or sometimes version 2, 3 and 4
respectively.

For example see "grid-proxy-init -help":

    -draftCreates a draft (GSI-3) proxy
-old  Creates a legacy globus proxy
-rfc  Creates a RFC 3820 compliant proxy

The really tricky one is the old legacy version 2 proxy I think.

Mattias


smime.p7s
Description: S/MIME cryptographic signature

Bug#800890: [Pkg-xfce-devel] Bug#800890: xfce4-power-manager: If set to suspend on lid close when on battery, suspends on the event when on power cord, too.

[Alexander Prokoshev]

21.07.2016 10:28, Yves-Alexis Perez пишет:
> On dim., 2015-10-04 at 19:25 +0300, Alexander Prokoshev wrote:
>> after an update the software changed its behavior.
> can you identify the update?

I don't think so, sorry.



signature.asc
Description: OpenPGP digital signature

Bug#829272: Missing accessors

[Mattias Ellert via RT]

tor 2016-07-21 klockan 09:51 + skrev Richard Levitte via RT:
> On Thu Jul 21 08:18:30 2016, mattias.ell...@physics.uu.se wrote:
> > 
> > ons 2016-07-20 klockan 15:14 + skrev Richard Levitte via RT:
> > > 
> > > On Mon Jul 11 11:34:35 2016, mattias.ell...@physics.uu.se wrote:
> > > > 
> > > > 
> > > > I guess having a more restrictive accessor that only sets the
> > > > EXFLAG_PROXY bit could work. I suggested the more general
> > > > solution
> > > > of
> > > > having set/clear accessors for arbitrary flags since it was -
> > > > well
> > > > more
> > > > general.
> > > 
> > > So let me ask this in a different manner, does OpenSSL 1.1 still
> > > not
> > > set the
> > > EXFLAG_PROXY flag correctly? In what situations does that happen?
> > > That may be
> > > worth a bug report of its own.
> > > 
> > > --
> > > Richard Levitte
> > > levi...@openssl.org
> > > 
> > 
> > The answer to this is related to Mischa's reply, which
> > unfortunately
> > was only sent to the Debian BTS and not the the OpenSSL RT. I quote
> > it
> > below. As indicated in the answer, setting the EXFLAG_PROXY allows
> > handling non-RFC proxies in OpenSSL.
> > 
> > mån 2016-07-11 klockan 14:53 +0200 skrev Mischa Salle:
> > > 
> > > Hi Richard, Mattias, others,
> > > 
> > > I agree with you that it would be nice if OpenSSL could figure
> > > out
> > > itself whether a cert needs to be treated as a proxy, but
> > > currently
> > > that
> > > doesn't work reliably as far as I know.
> > > The flag is certainly needed in the case of non-RFC3820 proxies,
> > > also
> > > known as legacy proxies. Unfortunately these are still very
> > > widely
> > > used
> > > (majority of the proxies actually) and hence our code must be
> > > able to
> > > handle them correctly.
> > > 
> > > Best wishes,
> > > Mischa Sallé
> > > 
> 
> Ok... From looking at the voms code that was linked to earlier, I can
> see that
> legacy proxy certs are recognised by an older OID (called
> PROXYCERTINFO_V3 in
> the code), 1.3.6.1.4.1.3536.1.222. Is there a spec for the extensions
> in that
> version, whether they are critical or not and so on, that I can
> reach? Or is
> the OID the only actual difference? If it's easy enough (and it
> currently does
> look quite easy), I can certainly see adding some code in OpenSSL to
> recognise
> those...
> 
> --
> Richard Levitte
> levi...@openssl.org

As far as I know there are three different kinds of proxies, usually
called "legacy", "draft" and "rfc", or sometimes version 2, 3 and 4
respectively.

For example see "grid-proxy-init -help":

    -draftCreates a draft (GSI-3) proxy
-old  Creates a legacy globus proxy
-rfc  Creates a RFC 3820 compliant proxy

The really tricky one is the old legacy version 2 proxy I think.

Mattias

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted



smime.p7s
Description: S/MIME cryptographic signature

Bug#804622: -x auth_info is a required parameter, at least with SQL

[Timo Sirainen]

On 22 Jul 2016, at 01:10, Apollon Oikonomopoulos  wrote:
> 
> Hi Martin,
> 
> On 22:00 Tue 12 Jul , martin f krafft wrote:
>> Attached is the auth conf. The failing command is 'doveadm auth'
>> without any -x parameter.
> 
> I'm afraid we'll also need the actual query from dovecot-sql.conf.ext.

The initial report says:

   pgsql: Query failed, aborting: SELECT p.userid, p.password, u.uid AS 
userdb_uid, u.gid AS userdb_gid, u.home AS userdb_home, u.mail AS userdb_mail 
FROM dovecotpassword('test','pantsfullofunix.net') p, dovecotuser('test', 
'pantsfullofunix.net') u WHERE doveadm

So here it means that the passdb_query has something like "... WHERE %s". The 
%s expands to the service name, which could be any of imap, pop3, lmtp, 
doveadm, sieve, and several others. In this database apparently there are 
"imap" and "pop3" fields in the database but not "doveadm" and maybe not the 
others. When using "doveadm auth" without explicitly specifying the service 
name, it also defaults to "doveadm". This in turn leads to the query failing 
due to the doveadm field not existing in SQL. This is all working as intended 
and I can't think of anything that could be fixed or improved here on Dovecot's 
side. It's not only doveadm that is failing with this config, but various other 
pieces of Dovecot that just aren't (currently) being used by Martin.

Bug#832090: lxc: dhcp fails due to invalid UDP checksum

[Lucas Nussbaum]

Package: lxc
Version: 1:2.0.3-1
Severity: important

Hi,

When booting containers, DHCP fails to get an IP due to invalid
UDP checksums.

I use the lxc-net-based setup as described in
https://wiki.debian.org/LXC/SimpleBridge ("using lxc-net").
This creates a lxcbr0 bridge.
When starting up, the containers' veth device is correctly attached to
the bridge.
However, it fails to get an IP using DHCP.
Using tcpdump on the host, on the veth device, I see:

9:41:14.923738 IP (tos 0xc0, ttl 64, id 42999, offset 0, flags [none], proto 
UDP (17), length 329)
10.0.3.1.67 > 10.0.3.233.68: [bad udp cksum 0x1c30 -> 0x2064!] BOOTP/DHCP, 
Reply, length 301, xid 0xa447c322, Flags [none] (0x)
  Your-IP 10.0.3.233
  Server-IP 10.0.3.1
  Client-Ethernet-Address 00:ff:aa:ab:cd:01
  Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: ACK
Server-ID Option 54, length 4: 10.0.3.1
Lease-Time Option 51, length 4: 3600
RN Option 58, length 4: 1800
RB Option 59, length 4: 3150
Subnet-Mask Option 1, length 4: 255.255.255.0
BR Option 28, length 4: 10.0.3.255
Default-Gateway Option 3, length 4: 10.0.3.1
Domain-Name-Server Option 6, length 4: 10.0.3.1
Hostname Option 12, length 7: "debian8"
09:41:17.594912 IP (tos 0x0, ttl 1, id 54287, offset 0, flags [DF], proto UDP 
(17), length 194)
10.0.3.1.44012 > 239.255.255.250.1900: [bad udp cksum 0xfdba -> 0x8df0!] 
UDP, length 166
09:41:18.596600 IP (tos 0x0, ttl 1, id 54466, offset 0, flags [DF], proto UDP 
(17), length 194)
10.0.3.1.44012 > 239.255.255.250.1900: [bad udp cksum 0xfdba -> 0x8df0!] 
UDP, length 166
09:41:19.597758 IP (tos 0x0, ttl 1, id 54542, offset 0, flags [DF], proto UDP 
(17), length 194)
10.0.3.1.44012 > 239.255.255.250.1900: [bad udp cksum 0xfdba -> 0x8df0!] 
UDP, length 166
09:41:19.928511 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.3.233 
tell 10.0.3.1, length 28

If, on the host, I disable checksum offloading using:
sudo ethtool -K vethILRWN4 tx off

Then DHCP succeeds.

This seems to be related to the bridge setup: if I manually remove the veth
device from the bridge, set an IP on it, etc. then everything works fine.

Lucas


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable-updates'), (400, 'stable'), (300, 
'unstable'), (150, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

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

Versions of packages lxc depends on:
ii  init-system-helpers  1.36
ii  libapparmor1 2.10.95-4
ii  libc62.23-1
ii  libcap2  1:2.25-1
ii  liblxc1  1:2.0.3-1
ii  libseccomp2  2.3.1-2
ii  libselinux1  2.5-3
ii  python3  3.5.1-4
pn  python3:any  

Versions of packages lxc recommends:
ii  bridge-utils  1.5-9
ii  cgmanager 0.41-2
ii  debootstrap   1.0.81
ii  dnsmasq-base  2.76-1.1
ii  iptables  1.6.0-2
ii  libpam-cgfs   2.0.1-2
ii  lxcfs 2.0.1-2
ii  openssl   1.0.2h-1
ii  rsync 3.1.1-3
ii  uidmap1:4.2-3.1

Versions of packages lxc suggests:
pn  apparmor 
pn  btrfs-tools  
pn  lua5.2   
ii  lvm2 2.02.160-1

-- no debconf information

Bug#832091: kpatch install: Error! Bad return status for module build on kernel: 4.6.0-1-amd64 (x86_64)

[choury]

Package: kpatch
Version: 0.3.2-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,


When install the kpatch with apt, it comes:
Error! Bad return status for module build on kernel: 4.6.0-1-amd64 (x86_64)

And the error log of build:
DKMS make.log for kpatch-0.3.2 for kernel 4.6.0-1-amd64 (x86_64)

 
2016年 07月 22日 星期五 15:51:07 CST  

   
make: Entering directory '/var/lib/dkms/kpatch/0.3.2/build/kmod'

 
make -C core clean  

 
make[1]: Entering directory '/var/lib/dkms/kpatch/0.3.2/build/kmod/core'

 
rm -f -Rf .*.o.cmd .*.ko.cmd .tmp_versions *.o *.ko *.mod.c \   

 
Module.symvers  

 
make[1]: Leaving directory '/var/lib/dkms/kpatch/0.3.2/build/kmod/core' 

 
make -C core

 
make[1]: Entering directory '/var/lib/dkms/kpatch/0.3.2/build/kmod/core'

 
make -C /lib/modules/4.6.0-1-amd64/build 
M=/var/lib/dkms/kpatch/0.3.2/build/kmod/core kpatch.ko  


make[2]: Entering directory '/var/lib/dkms/kpatch/0.3.2/build/kmod/core'

 
make[2]: warning: jobserver unavailable: using -j1.  Add '+' to parent make 
rule.   

 
  CC [M]  /var/lib/dkms/kpatch/0.3.2/build/kmod/core/core.o 

 
/var/lib/dkms/kpatch/0.3.2/build/kmod/core/core.c:255:13: error: initialization 
from incompatible pointer type [-Werror=incompatible-pointer-types] 
 
  .address = kpatch_backtrace_address_verify,   

 
 ^  

 
/var/lib/dkms/kpatch/0.3.2/build/kmod/core/core.c:255:13: note: (near 
initialization for 'kpatch_backtrace_ops.address')  

   
/var/lib/dkms/kpatch/0.3.2/build/kmod/core/core.c:275:13: error: initialization 
from incompatible pointer type [-Werror=incompatible-pointer-types] 
 
  .address = kpatch_print_trace_address,

  

Bug#825756: [pkg-cinnamon] Bug#825756: Bug#825756: cinnamon-session: stopped using/working with gpg-agent

[Maximiliano Curia]

¡Hola Norbert!

El 2016-07-22 a las 09:14 +0900, Norbert Preining escribió:

ok, lots of restarts etc later I found the culprit:
gnome-keyring


Right, gnome-keyring implements it's own ssh-agent. I had completely 
forgotten about it. Good catch.


I guess the problem is that gnome-keyring-daemon drops an 
entry into 
	/etc/xdg/autostart/gnome-keyring-*.desktop 
(for ssh,pkcs11,secrets).



Besides uninstalling gnome-keyring, do you see a different method?


You can always override the autostart desktop files adding a desktop file to 
~/.config/autostart/ with the same name and the content:

[Desktop Entry]
Hidden=true

I've just tested this with gnome-keyring-ssh and this avoids the 
gnome-keyring taking over the SSH_AUTH_SOCK.


Is this a bug in gnome-keyring? I guess yes, but what should 
one do, Gnome is going its own way in creating their own OS, 
so they will not listen anyway.


I think cinnamon is at fault here, as it doesn't show the desktop files that 
are in /etc/xdg/autostart in the Startup Applications settings, to allow an 
easy way to disable unwanted components.


Happy hacking,
--
"It takes three times the effort to find and fix bugs in system test than when
done by the developer. It takes ten times the effort to find and fix bugs in
the field than when done in system test. Therefore, insist on unit tests by
the developer"
-- Larry Bernstein
Saludos /\/\ /\ >< `/


signature.asc
Description: Digital signature

Bug#804622: -x auth_info is a required parameter, at least with SQL

[Apollon Oikonomopoulos]

Control: tags -1 - moreinfo + wontfix

Hi Timo,

On 01:51 Fri 22 Jul , Timo Sirainen wrote:
> The initial report says:
> 
>pgsql: Query failed, aborting: SELECT p.userid, p.password, u.uid AS 
> userdb_uid, u.gid AS userdb_gid, u.home AS userdb_home, u.mail AS userdb_mail 
> FROM dovecotpassword('test','pantsfullofunix.net') p, dovecotuser('test', 
> 'pantsfullofunix.net') u WHERE doveadm
> 
> So here it means that the passdb_query has something like "... WHERE 
> %s". The %s expands to the service name, which could be any of imap, 
> pop3, lmtp, doveadm, sieve, and several others. In this database 
> apparently there are "imap" and "pop3" fields in the database but not 
> "doveadm" and maybe not the others. When using "doveadm auth" without 
> explicitly specifying the service name, it also defaults to "doveadm". 
> This in turn leads to the query failing due to the doveadm field not 
> existing in SQL. This is all working as intended and I can't think of 
> anything that could be fixed or improved here on Dovecot's side. It's 
> not only doveadm that is failing with this config, but various other 
> pieces of Dovecot that just aren't (currently) being used by Martin.
> 

Thanks for the clarification. Indeed, it looks as if there's not much we 
can do on the Debian side either.

Martin, I guess you can work around this locally by rewriting your query 
to not check the service name at all, if that's consistent with your 
local policy.

Regards,
Apollon

Bug#831977: [libreoffice-calc] I can confirm bug831977 with Debian's own version but not upstream

[Thomas Hackert]

Hello Rene,
On Fri, Jul 22, 2016 at 09:31:21AM +0200, Rene Engelhard wrote:
> On Fri, Jul 22, 2016 at 08:58:37AM +0200, Thomas Hackert wrote:
> > where do I find this script? Is it included in one of the LO
> > packages?
> 
> yes. /usr/share/bug//script. Here I mean
> 
> /usr/share/bug/libreoffice-core/script (run it as
> /usr/share/bug/libreoffice-core/script 3>&1)

I'll attach a file with its output to this mail (less c&p errors ...
;) ). I hope it is O.K for you.

> > > (BTW: I see you are not using Debian but a crude mix of Ubuntu ppa,
> > > testing and stable-security, where the first one is questionable and the 
> > > last
> > > one nonsense, testing either has newer versions or stuff in stable might 
> > > not
> > > be compatible anymore - transitions, etc..)
> > 
> > Oh, I know, that this seems to be a crude mix ... ;) But all
> > security entries are those which were included after Debian's
> > installation AFAIKR. Do you mean I can remove them?
> 
> No, they weren't. They were when you installed it as stable. When you upgraded
> to testing they are left-overs.

I am only installing esting since years, with additional
repositories like mentioned before. I am mainly downloading the DVD
image 1 for AMD64.

> > > so it seems to be gtk3-only?
> > 
> > Not sure, sorry ... :( I have never installed gtk for itself, but as
> > dependencies to the one or the other package.
> 
> But you also can look up what VCLplug you use etc.

How? Sorry for such dumb n00b questions ... :(
Greetings
Thomas.

-- 
This dungeon is owned and operated by Frobozz Magic Co., Ltd.
All deployed bundled extensions:

Identifier: org.openoffice.comp.pyuno.lightproof.oxt.lightproof_en
  Version: 0.4.3
  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/lightproof_en
  is registered: yes
  Media-Type: application/vnd.sun.star.package-bundle
  Description: 
  bundled Packages: {
  URL: 
vnd.sun.star.expand:$BUNDLED_EXTENSIONS/lightproof_en/dialog/OptionsDialog.xcs
  is registered: yes
  Media-Type: application/vnd.sun.star.configuration-schema
  Description: 

  URL: 
vnd.sun.star.expand:$BUNDLED_EXTENSIONS/lightproof_en/dialog/OptionsDialog.xcu
  is registered: yes
  Media-Type: application/vnd.sun.star.configuration-data
  Description: 

  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/lightproof_en/Lightproof.py
  is registered: yes
  Media-Type: application/vnd.sun.star.uno-component;type=Python
  Description: 

  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/lightproof_en/Linguistic.xcu
  is registered: yes
  Media-Type: application/vnd.sun.star.configuration-data
  Description: 

  }

Identifier: org.openoffice.da.writer2latex.oxt
  Version: 1.4
  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/writer2latex
  is registered: yes
  Media-Type: application/vnd.sun.star.package-bundle
  Description: Writer2Latex bietet Writer Exportfilter für LaTeX und BibTeX

  bundled Packages: {
  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/writer2latex/help
  is registered: yes
  Media-Type: application/vnd.sun.star.help
  Description: 

  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/writer2latex/writer2latex.rdb
  is registered: yes
  Media-Type: application/vnd.sun.star.uno-typelibrary;type=RDB
  Description: 

  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/writer2latex/W2LDialogs2/
  is registered: yes
  Media-Type: application/vnd.sun.star.basic-library
  Description: 

  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/writer2latex/W2LDialogs/
  is registered: yes
  Media-Type: application/vnd.sun.star.basic-library
  Description: 

  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/writer2latex/Options.xcs
  is registered: yes
  Media-Type: application/vnd.sun.star.configuration-schema
  Description: 

  URL: 
vnd.sun.star.expand:$BUNDLED_EXTENSIONS/writer2latex/writer2latex-filter.jar
  is registered: yes
  Media-Type: application/vnd.sun.star.uno-component;type=Java
  Description: 

  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/writer2latex/w2l_types.xcu
  is registered: yes
  Media-Type: application/vnd.sun.star.configuration-data
  Description: 

  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/writer2latex/w2l_filters.xcu
  is registered: yes
  Media-Type: application/vnd.sun.star.configuration-data
  Description: 

  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/writer2latex/OptionPages.xcu
  is registered: yes
  Media-Type: application/vnd.sun.star.configuration-data
  Description: 

  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/writer2latex/Options.xcu
  is registered: yes
  Media-Type: application/vnd.sun.star.configuration-data
  Description: 

  }

Identifier: com.sun.star.mysql-connector-ooo-linux_x86_64
  Version: 1.0.2
  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/mysql-connector-ooo
  is registered: yes
  Media-Type: applic

Bug#830740: mrpt: FTBFS on hppa: parse_NMEA_RMC assertion failure

[JOSE LUIS BLANCO CLARACO]

>>Hi Aarom, Gianfranco,
> s/m/n ;)

fat finger typo!  ;-)


> since we have a fix for the other architecture, what about adding this patch 
> and upload on
> unstable?
> at least we have a fix for sparc64.

Done!

The new package is in mentors:
https://mentors.debian.net/debian/pool/main/m/mrpt/mrpt_1.4.0-4.dsc

I included the potential fix to the other HPPA bug... hopefully it'll
work at the first attempt!

Thanks for everything guys!
JL

Bug#798969: marked as done (jessie-pu: package qemu/1:2.1+dfsg-12+deb8u5)

[Salvatore Bonaccorso]

Hi Michael,

On Fri, Jul 15, 2016 at 08:57:08PM +, Debian Bug Tracking System wrote:
> On Wed, Jul 13, 2016 at 17:35:55 +0300, Michael Tokarev wrote:
> 
> > 28.06.2016 12:17, Julien Cristau wrote:
> > > Control: tag -1 moreinfo
> > > 
> > > On Sat, Feb 20, 2016 at 18:19:49 +, Julien Cristau wrote:
> > 
> > Hmm.  I haven't seen this email back in February.
> > 
> > Basically I gave up waiting for almost a year for this,
> > I don't even remember anymore what was in version 2.1.
> > 
> > Most likely it isn't worth pushing anymore, since freeze
> > of stretch is on horizon.
> > 
> I'd disagree, but obviously it's your call.  Closing.

Michael, hope you can reconsider that. I mean there are many CVEs
which do not warrant a DSA, but even after Stretch release Jessie will
be supported.

Regards,
Salvatore

Bug#827933: RFS: yabar/0.4.0-3 [ITP]

[Jack Henschel]

On 07/22/2016 03:32 AM, Sean Whitton wrote:
> I just took a look at the yabar homepage.  It says that "Yabar is still
> in its infancy and far from being mature. Feel free to contribute or
> report bugs!"

Initially, I was also held of by this disclaimer.
However there are two reasons why I decided to package yabar for Debian anyway:
* I have seen people use yabar "in production", since it can easily be extended 
with custom scripts
* while using yabar myself I have not encountered any breaking/major issues.

> As a general rule, experimental software is not included in Debian.
> However, plenty of upstreams write "far from mature" when really the
> software is mature and is suitable for Debian.
> 
> Do you consider yabar to be sufficiently mature?

That is exactly how I would describe it. yabar is not complete and yabar has 
some issues (as can be seen on GitHub).
Nevertheless, yabar is not experimental software and I do not expect any 
breaking changes (i.e. config file syntax).

Best Regards,
Jack Henschel



signature.asc
Description: OpenPGP digital signature

Bug#831977: [libreoffice-calc] I can confirm bug831977 with Debian's own version but not upstream

[Rene Engelhard]

Hi,

On Fri, Jul 22, 2016 at 10:12:56AM +0200, Thomas Hackert wrote:
> I'll attach a file with its output to this mail (less c&p errors ...
> ;) ). I hope it is O.K for you.
[...]
> How? Sorry for such dumb n00b questions ... :(

By telling me what you have installed (and maybe which desktop you use,
but here it's clear/not necessary)? :)

> Installed VCLplugs:
> Desired=Unknown/Install/Remove/Purge/Hold
> | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
> ||/ Name Version   Architecture Description
> +++--=--=
> un  libreoffice-gtk (no description available)
> ii  libreoffice-gtk3 1:5.1.5~rc1-1 amd64office productivity suite -- 
> GTK+ 3.0 integration
> ii  libreoffice-kde  1:5.1.5~rc1-1 amd64office productivity suite -- 
> KDE integration

or this :)
(That's exactly why I don't like reportbug it not picking up if you don't 
report againstz
libreoffice-core. See #819543)

But yeah, so it's indeed gtk3 what you use.

Regards,

Rene

Bug#798975: [Pkg-libvirt-maintainers] Bug#798975: Bug#798975: libvirt-daemon-system: AppArmor profile breaks startup of QEMU VM with type=pty serial port

[Guido Günther]

Control: tags -1 +wontfix

Hi,

On Wed, Nov 11, 2015 at 08:11:35PM +0100, intrigeri wrote:
> Guido Günther wrote (11 Nov 2015 18:09:21 GMT) :
> > So what I'd say this is not a bug in the Apparmor profile
> 
> Right.
> 
> > so should we mark this as "wontfix" so it stays open for others to
> > find this answyer?
> 
> Ideally one would report a bug against piuparts (it shouldn't affect
> the host system's existing mounts, should it?) and mark it as blocking
> this one, but I'm unlikely to have time to do this so wontfix is
> perhaps the best we can do.

Could you check if

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829146

Fixes the problem. It would be nice to get this one closes since it's
not caused by libvirt.
Cheers,
 -- Guido

Bug#831909: gstreamer coredumps when playing wavs since the libavcodec upgrade

[Sebastian Ramacher]

Hi

On 2016-07-20 22:06:05, Faidon Liambotis wrote:
> Package: libavcodec57
> Version: 7:3.1.1-2
> Severity: grave
> 
> I ran Debian testing on my desktop. Since about a day ago, pidgin
> started crashing unexpectedly. After a little bit of debugging, I found
> that it reproducibly crashes when trying to play sounds. Going a step
> further, I made the test case as simple as:
> 
> $ gst-launch-1.0 filesrc location=/usr/share/sounds/purple/alert.wav  ! 
> wavparse ! audioconvert !  fakesink
> Setting pipeline to PAUSED ...
> Pipeline is PREROLLING ...
> Aborted (core dumped)

Unfortunately I am unable to reproduce the issue. Since there are some accounts
of random crashes when building ffmpeg with tree vectorization enabled, I've
uploaded 7:3.1.1-3 with vectorization disabled. Could you please check if the
issue disappears with -3?

> My dpkg.log has a bunch of ffmpeg-related package upgrades, including
> libavcodec57, being installed on 2016-07-18, approximately when those
> crashes started. Because of this and the backtrace below, I'm filing
> this against libavcodec57 -- feel free to reassign if that's wrong.
> 
> The backtrace seems to be:
>PID: 4121 (gst-launch-1.0)
>UID: 1000 (paravoid)
>GID: 1000 (paravoid)
> Signal: 6 (ABRT)
>  Timestamp: Τετ 2016-07-20 21:55:59 EEST (5min ago)
>   Command Line: gst-launch-1.0 filesrc 
> location=/usr/share/sounds/purple/alert.wav ! wavparse ! audioconvert ! 
> fakesink
> Executable: /usr/bin/gst-launch-1.0
>  Control Group: /
>  Slice: -.slice
>Boot ID: fc3d59275e1042c491633f9a920c10e5
> Machine ID: ddb673bb6861472487a0edbc40f6f1fc
>   Hostname: donald
>   Coredump: 
> /var/lib/systemd/coredump/core.gst-launch-1\x2e0.1000.fc3d59275e1042c491633f9a920c10e5.4121.1469040959.xz
>Message: Process 4121 (gst-launch-1.0) of user 1000 dumped core.
> 
> Stack trace of thread 4122:
> #0  0x7fa47ae7f1c8 raise (libc.so.6)
> #1  0x7fa47ae8064a abort (libc.so.6)
> #2  0x7fa4719b8f5b n/a (libavcodec.so.57)
> #3  0x7fa4719b9026 avcodec_alloc_context3 
> (libavcodec.so.57)
> #4  0x7fa473360540 n/a (libgstlibav.so)
> #5  0x7fa473356e53 n/a (libgstlibav.so)
> #6  0x7fa47b74b22d g_type_class_ref (libgobject-2.0.so.0)
> #7  0x7fa47b9c8da4 gst_element_register 
> (libgstreamer-1.0.so.0)
> #8  0x7fa4733575b3 n/a (libgstlibav.so)
> #9  0x7fa473349e20 n/a (libgstlibav.so)
> #10 0x7fa47b9ea537 n/a (libgstreamer-1.0.so.0)
> #11 0x7fa47b9ec425 n/a (libgstreamer-1.0.so.0)
> #12 0x7fa47b9ed12c gst_plugin_load_by_name 
> (libgstreamer-1.0.so.0)
> #13 0x7fa47b9eda8d gst_plugin_feature_load 
> (libgstreamer-1.0.so.0)
> #14 0x7fa47ba137e3 gst_type_find_factory_call_function 
> (libgstreamer-1.0.so.0)
> #15 0x7fa479c48421 gst_type_find_helper_for_data 
> (libgstbase-1.0.so.0)
> #16 0x7fa479c485a4 gst_type_find_helper_for_buffer 
> (libgstbase-1.0.so.0)
> #17 0x7fa4799f446a n/a (libgstwavparse.so)
> #18 0x7fa4799f4b47 n/a (libgstwavparse.so)
> #19 0x7fa4799fabb1 n/a (libgstwavparse.so)
> #20 0x7fa47ba0ee71 n/a (libgstreamer-1.0.so.0)
> #21 0x7fa47b47b55e n/a (libglib-2.0.so.0)
> #22 0x7fa47b47abc5 n/a (libglib-2.0.so.0)
> #23 0x7fa47b1f4464 start_thread (libpthread.so.0)
> #24 0x7fa47af3330d __clone (libc.so.6)
> 
> Stack trace of thread 4121:
> #0  0x7fa47af2a19d poll (libc.so.6)
> #1  0x7fa47b45439c n/a (libglib-2.0.so.0)
> #2  0x7fa47b454722 g_main_loop_run (libglib-2.0.so.0)
> #3  0x7fa47b9af8e9 gst_bus_poll (libgstreamer-1.0.so.0)
> #4  0x004046f8 n/a (gst-launch-1.0)
> #5  0x004036e9 n/a (gst-launch-1.0)
> #6  0x7fa47ae6c730 __libc_start_main (libc.so.6)
> #7  0x00403d19 n/a (gst-launch-1.0)
> 
> Stack trace of thread 4123:
> #0  0x7fa47af2a19d poll (libc.so.6)
> #1  0x7fa47b45439c n/a (libglib-2.0.so.0)
> #2  0x7fa47b4544ac g_main_context_iteration 
> (libglib-2.0.so.0)
> #3  0x7fa47b4544e9 n/a (libglib-2.0.so.0)
> #4  0x7fa47b47abc5 n/a (libglib-2.0.so.0)
> #5  0x7fa47b1f4464 start_thread (libpthread.so.0)
> #6  0x7fa47af3330d __clone (libc.so.6)

Please install libavcodec57-dbgsym and the -dbgsym packages 

Bug#832092: ITP: libstring-copyright-perl -- representation of text-based copyright statements

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: libstring-copyright-perl
  Version : 0.001
  Upstream Author : Jonas Smedegaard 
* URL : https://metacpan.org/pod/String::Copyright
* License : GPL-3+
  Programming Lang: Perl
  Description : representation of text-based copyright statements

 String::Copyright Parses common styles of copyright statements and
 serializes in normalized format.

The project is needed for recent releases of licensecheck.

It will be maintained in the Debian Perl group.

 - Jonas

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJXkdqJAAoJECx8MUbBoAEhHjgP/3VdVg9vC8/19i4cvrYkgAWq
uF9cUl8RVo/aBmM6G38bJqU87KBE4bFMb+Blp/tTc2jjUcGNa16ljX2I+po2BI17
NBM8tInbYCh32kTuLz7srcU9/E1Q8tTF3Cltm9WtEMI56poxmFCUjABze2b/PPtJ
uLkGls0lF5mm1gjeOLCFGQCHMBMSP3+ihxH6YMtjddP63AaSC+sPCZGodn8xz6dz
Vn2hXlhP6BRZFWranrDJq40zTCET4R1UEYTsppC0/lw0mC97gqevGPR1D5D3Y0GM
V6dvcJ9M/5fxxSc8o4YadjhdRXJWwoikN4FsOorXpfrxQBy5Ab6TGzx+PlxC6wbi
fYN5llSwMyh4vS943AK3QD5k9UKiYTM/oO+JbppkcY0dvdDYmr1ZzZNj3kXq5rWr
reAWDWpNDwLH7A8AfXocjAz8ooROOYD4XqbVrQcl0IBr1z3UjhWn3nShlu7Hqavd
LqU/1L5xrVvqmzuMiTRDGLGlGEMme0WxHYn7bOD5aLGjLmo+uZYTXqkixAoEr3dq
0NCOIJGWmsH53yJyTWRV14vL3ik+f/owAgSXKt+ncDvcv2w6gy7e8JLmhofV3wQg
w08IpebUKK1RfmTTkjbWzX63XLHBLoPH5xAqJtAzkwfdbj3op9zHIQEbx/d4NFHz
d7kNoQjKqUnpmFcX0rHF
=0ByT
-END PGP SIGNATURE-

Bug#830740: mrpt: FTBFS on hppa: parse_NMEA_RMC assertion failure

[Gianfranco Costamagna]

Hi,



>fat finger typo!  ;-)


:)
>https://mentors.debian.net/debian/pool/main/m/mrpt/mrpt_1.4.0-4.dsc
>
>I included the potential fix to the other HPPA bug... hopefully it'll
>work at the first attempt!


you will know in a few hours, the package is uploaded, it will go in
unstable at the end of dinstall
https://ftp-master.debian.org/dinstall.status
https://ftp-master.debian.org/dinstall.html
>Thanks for everything guys!


you are welcome, lets hope for the best!
(and for hppa, if it doesn't fix, just reopen the bug and don't care,
we don't have porter machines, so porters have to look at the issue, I can't)

Gianfranco

Bug#819530: transition: icu

[Emilio Pozuelo Monfort]

On 22/07/16 09:26, László Böszörményi (GCS) wrote:
> Hi Emilio,
> 
> On Thu, Jul 21, 2016 at 5:02 PM, Emilio Pozuelo Monfort
>  wrote:
>> On 30/03/16 07:38, Laszlo Boszormenyi (GCS) wrote:
>>> ICU has a new major upstream release, supporting several new things
>>> that I would like to see in Stretch:
>>> - CLDR[1] 28 [2] and 29 [3] support,
>>> - Unicode 8.0.0 [4] support.
>>
>> What's the status of this? I see it is in experimental now. Have you
>> build-tested all the reverse-deps?
>  Back in time I had big hardware problems and only tested LibreOffice,
> which was successful. HW issues is softened by Martin F. Krafft and
> Jeffrey Walton since DebConf'16. Catching up with my backlog and the
> big rebuild session planned to this weekend.

Ok, cool.

> Meanwhile Ubuntu took my ICU package from experimental and made it
> default without any additional patch to their upcoming Yakkety Yak
> release[1]. This is a good sign that it doesn't have any problem, but
> better to wait my own results. Is amd64 / i386 rebuilds enough or
> should I try kFreeBSD i386 / amd64 and/or (emulated) ARM64 rebuilds?

Just one architecture is enough. Of course if you can / want to test in more,
that's fine.

Cheers,
Emilio

Bug#832093: NetworkManager-wait-online.service fails to start and delays boot

[Guido Günther]

Package: network-manager
Version: 1.2.2-2
Severity: normal

Hi,

NetworkManager-wait-online.service fails to start during boot like

$ journalctl -b --unit=NetworkManager-wait-online.service
-- Logs begin at Do 2015-08-06 09:54:25 SAST, end at Fr 2016-07-22 10:34:27 
SAST. --
Jul 22 09:57:14 bogon systemd[1]: Starting Network Manager Wait Online...
Jul 22 09:57:46 bogon systemd[1]: NetworkManager-wait-online.service: Main 
process exited, code=exited, status=1/FAILURE
Jul 22 09:57:46 bogon systemd[1]: Failed to start Network Manager Wait Online.
Jul 22 09:57:46 bogon systemd[1]: NetworkManager-wait-online.service: Unit 
entered failed state.
Jul 22 09:57:46 bogon systemd[1]: NetworkManager-wait-online.service: Failed 
with result 'exit-code'.

If it strat it later on it works as expected (although an ethernet cable
is plugged in all the time).

Since it waits for a timeout it also delays the boot by several
seconds. Disabling the service brings back the old boot speed. Should
this service be disabled by default?

Cheers,
 -- Guido


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

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

Versions of packages network-manager depends on:
ii  adduser3.115
ii  dbus   1.10.8-1
ii  init-system-helpers1.36
ii  isc-dhcp-client4.3.4-1
ii  libaudit1  1:2.5.2-1
ii  libbluetooth3  5.36-1+b1
ii  libc6  2.23-1
ii  libglib2.0-0   2.48.1-2
ii  libgnutls303.4.14-1
ii  libgudev-1.0-0 230-3
ii  libmm-glib01.5.993-1
ii  libndp01.6-1
ii  libnewt0.520.52.18-3
ii  libnl-3-2003.2.27-1
ii  libnm0 1.2.2-2
ii  libpam-systemd 230-7
ii  libpolkit-agent-1-00.105-15
ii  libpolkit-gobject-1-0  0.105-15
ii  libreadline6   6.3-8+b4
ii  libselinux12.5-3
ii  libsoup2.4-1   2.54.1-1
ii  libsystemd0230-7
ii  libteamdctl0   1.24-1
ii  libuuid1   2.28-6
ii  lsb-base   9.20160629
ii  policykit-10.105-15
ii  udev   230-7
ii  wpasupplicant  2.3-2.3

Versions of packages network-manager recommends:
ii  crda3.13-1+b1
ii  dnsmasq-base2.76-1.1
ii  iptables1.6.0-2
ii  iputils-arping  3:20150815-2
ii  modemmanager1.5.993-1
ii  ppp 2.4.7-1+2

Versions of packages network-manager suggests:
pn  libteam-utils  

-- no debconf information

Bug#832094: texlive-all: please package tex4ht from texlive

[Tobias Schlemmer]

Package: texlive-all
Severity: wishlist

Hi,

since bug fixes and new hacks for tex4ht are released exclusively via the
TeXLive repository the tex4ht-common package ist massivly outdated, as it is
built from a source that is marked „obsolete“. This affects widely used
classes as the KOMA script bundle.

Because of this I personally think it would be great to have integrated tex4ht
in the Debian TeXLive distribution.

Quote from the official homepage (https://www.tug.org/tex4ht/):

“In TeX Live, we have installed updates to some .4ht files. Other development
changes remain solely in the source repository.”

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

Kernel: Linux 4.5.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)

Bug#828775: Support multiple patch queues branches

[Guido Günther]

On Mon, Jun 27, 2016 at 08:41:18PM +0200, Michael Biebl wrote:
> Package: git-buildpackage
> Version: 0.7.5
> Severity: wishlist
> 
> Hi Guido,
> 
> as discussed offline, in pkg-systemd we typically have two type of
> patches: upstream cherrry-picks and Debian specific patches. Upstream
> cherry-picks happen much more often and should ideally be applied
> directly on upstream master (to avoid merge conflicts), i.e. before the
> Debian patches.
> 
> With the current gbp pq approach, the workflow atm looks like:
> gbp pq import --force
> git cherry-pick 
>   which means the new cherry-pick is the last patch in
>   debian/patches/series
> git rebase -i
>   to reorder the new cherry-picked patch
> 
> Ideally we would have two patch queue branches: one for upstream
> cherry-picks and one for Debian specific patches.

In case of the  upstream cherry-picks the branch should be based on the
upstream branch and not the Debian branch then?

I'm basically fine with having multiple branches combined before writing
the patch queue. We "just" need to figure out the right UI:

* how to tell pq which branches it should care about and in what
  order (a simple ordered list of refs with a common merge-base)?
  We could use the topics as branch names.

* Do we still want to produce the linear view we currently have before
  exporting so the user sees the patch queue as is or do we rather want
  s.th. like "I have these 5 branches please serialize this into a
  patch queue". I'd opt for the later, we need to handle conflicts then
  as well though. We could reuse the ordered list from above.

Does this make sense? 
Cheers,
 -- Guido

Bug#829272: [openssl.org #4602] Missing accessors

[Mischa Salle]

On Fri, Jul 22, 2016 at 09:38:13AM +0200, Mattias Ellert wrote:
> tor 2016-07-21 klockan 09:51 + skrev Richard Levitte via RT:
> > On Thu Jul 21 08:18:30 2016, mattias.ell...@physics.uu.se wrote:
> > > 
> > > ons 2016-07-20 klockan 15:14 + skrev Richard Levitte via RT:
> > > > 
> > > > On Mon Jul 11 11:34:35 2016, mattias.ell...@physics.uu.se wrote:
> > > > > 
> > > > > 
> > > > > I guess having a more restrictive accessor that only sets the
> > > > > EXFLAG_PROXY bit could work. I suggested the more general
> > > > > solution
> > > > > of
> > > > > having set/clear accessors for arbitrary flags since it was -
> > > > > well
> > > > > more
> > > > > general.
> > > > 
> > > > So let me ask this in a different manner, does OpenSSL 1.1 still
> > > > not
> > > > set the
> > > > EXFLAG_PROXY flag correctly? In what situations does that happen?
> > > > That may be
> > > > worth a bug report of its own.
> > > > 
> > > > --
> > > > Richard Levitte
> > > > levi...@openssl.org
> > > > 
> > > 
> > > The answer to this is related to Mischa's reply, which
> > > unfortunately
> > > was only sent to the Debian BTS and not the the OpenSSL RT. I quote
> > > it
> > > below. As indicated in the answer, setting the EXFLAG_PROXY allows
> > > handling non-RFC proxies in OpenSSL.
> > > 
> > > mån 2016-07-11 klockan 14:53 +0200 skrev Mischa Salle:
> > > > 
> > > > Hi Richard, Mattias, others,
> > > > 
> > > > I agree with you that it would be nice if OpenSSL could figure
> > > > out
> > > > itself whether a cert needs to be treated as a proxy, but
> > > > currently
> > > > that
> > > > doesn't work reliably as far as I know.
> > > > The flag is certainly needed in the case of non-RFC3820 proxies,
> > > > also
> > > > known as legacy proxies. Unfortunately these are still very
> > > > widely
> > > > used
> > > > (majority of the proxies actually) and hence our code must be
> > > > able to
> > > > handle them correctly.
> > > > 
> > > > Best wishes,
> > > > Mischa Sallé
> > > > 
> > 
> > Ok... From looking at the voms code that was linked to earlier, I can
> > see that
> > legacy proxy certs are recognised by an older OID (called
> > PROXYCERTINFO_V3 in
> > the code), 1.3.6.1.4.1.3536.1.222. Is there a spec for the extensions
> > in that
> > version, whether they are critical or not and so on, that I can
> > reach? Or is
> > the OID the only actual difference? If it's easy enough (and it
> > currently does
> > look quite easy), I can certainly see adding some code in OpenSSL to
> > recognise
> > those...
> > 
> > --
> > Richard Levitte
> > levi...@openssl.org
> 
> As far as I know there are three different kinds of proxies, usually
> called "legacy", "draft" and "rfc", or sometimes version 2, 3 and 4
> respectively.
> 
> For example see "grid-proxy-init -help":
> 
>     -draftCreates a draft (GSI-3) proxy
> -old  Creates a legacy globus proxy
> -rfc  Creates a RFC 3820 compliant proxy
> 
> The really tricky one is the old legacy version 2 proxy I think.

Hi,

there are 3 types of proxies, in chronological order:

- so called legacy proxies, which voms-proxy-init will call old and are
  also known as GT2 proxies.
  They have no special (critical) extension and can be recognized by:
1) being signed by an end-entity cert (i.e. a non-CA)
2) have the same subjectDN as the issuer with one extra CN RDN
   added, which can be either
a) "CN=proxy" for a 'inherit all' proxy
b) "CN=limited proxy" for a limited proxy (as in OID
   1.3.6.1.4.1.3536.1.1.1.9)
  These are widely used and we have therefore code in many places to
  handle them.

- the draft RFC proxies, also known as GT3 proxies.
  They contain an extension 1.3.6.1.4.1.3536.1.222
  At least voms-proxy-init does not mark it as critical. They are
  rarely used. The ordering in the extension is different in the sense
  that they usually put the proxyPolicy before the proxyPathlength (when
  finite, i.e. present) inside the extension, but RFC-style extensions
  also occur. In openssl.cnf style a GT3 extension would be something
  like this:
[ gt3_proxy ]
keyUsage = critical,digitalSignature,keyEncipherment
1.3.6.1.4.1.3536.1.222=critical,ASN1:SEQUENCE:gt3_seq_sect

# For a proxy pathlength of 42, leave out field2 for inf.
[ gt3_seq_sect ]
field1 = SEQUENCE:normal_policy
field2 = EXPLICIT:1C,INTEGER:42

# similarly for limited policy
[ normal_policy ]
p1 = OID:1.3.6.1.5.5.7.21.1

- RFC3820 compliant proxies, also known as GT4 proxies.
  They contain the standard critical extension 1.3.6.1.5.5.7.1.14

The default for at least voms-proxy-init (both from the voms-clients2
and voms-clients3) is to make the GT2 proxies, and this is why they are
still very-widely used (I think vast majority of proxies).

Mischa
-- 
Nikhef  Room  H155
Science Park 105Tel.  +31-20-592 5102
1098 XG Amsterdam   Fax   +31-

Bug#823436: switch from RFP to ITP

[Ghislain Vaillant]

control: owner -1 !
control: retitle -1 "ITP: python-prov -- W3C Provenance Data Model 
supporting PROV-JSON and PROV-XML"


I am on it.

Ghis

Bug#832094: texlive-all: please package tex4ht from texlive

[Mattia Rizzolo]

control: reassign src:texlive-base

On Fri, Jul 22, 2016 at 10:45:46AM +0200, Tobias Schlemmer wrote:
> Package: texlive-all

this package doesn't exist..
reassigning to texlive-base, possibly related.

> Severity: wishlist
> 
> Hi,
> 
> since bug fixes and new hacks for tex4ht are released exclusively via the
> TeXLive repository the tex4ht-common package ist massivly outdated, as it is
> built from a source that is marked „obsolete“. This affects widely used
> classes as the KOMA script bundle.
> 
> Because of this I personally think it would be great to have integrated tex4ht
> in the Debian TeXLive distribution.
> 
> Quote from the official homepage (https://www.tug.org/tex4ht/):
> 
> “In TeX Live, we have installed updates to some .4ht files. Other development
> changes remain solely in the source repository.”
> 
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers oldoldstable-updates
>   APT policy: (500, 'oldoldstable-updates'), (500, 'oldoldstable'), (500,
> 'unstable'), (500, 'testing'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386, mingw64-amd64, mingw64-i386
> 
> Kernel: Linux 4.5.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)

-- 
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#832050: [buildd-tools-devel] Bug#832050: sbuild: Allow to run commands as root before/after installing the build dependencies

[Johannes Schauer]

Hi,

Quoting Raphaël Hertzog (2016-07-21 21:18:52)
> I have updated a library and in the process I renamed ftplib-dev into
> libftp-dev (which provides "ftplib-dev") and I want to ensure that
> reverse dependencies build correctly with the new package. I used
> --extra-package to inject my package but the new package does not get
> picked due to the new name... but if I could install the new package
> before build dependencies are installed, then I could test my package.

How about:

sbuild --add-depends libftp-dev=VERSION

> So I want a new option like --pre-build-deps-commands="apt-get install 
> libftp-dev"
> Ideally I'm sure there are cases where we want to fix the set of packages
> after having installed the build dependencies... so a --pre-build-commands
> running as root would be nice too.

Why does --chroot-setup-commands not work in your case?

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#831977: [libreoffice-calc] I can confirm bug831977 with Debian's own version but not upstream

[Thomas Hackert]

Hello Rene,
On Fri, Jul 22, 2016 at 10:22:47AM +0200, Rene Engelhard wrote:
> On Fri, Jul 22, 2016 at 10:12:56AM +0200, Thomas Hackert wrote:
> > I'll attach a file with its output to this mail (less c&p errors ...
> > ;) ). I hope it is O.K for you.
> [...]
> > How? Sorry for such dumb n00b questions ... :(
> 
> By telling me what you have installed (and maybe which desktop you use,
> but here it's clear/not necessary)? :)

O.K.

> > Installed VCLplugs:
> > Desired=Unknown/Install/Remove/Purge/Hold
> > | 
> > Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
> > |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
> > ||/ Name Version   Architecture Description
> > +++--=--=
> > un  libreoffice-gtk (no description available)
> > ii  libreoffice-gtk3 1:5.1.5~rc1-1 amd64office productivity suite 
> > -- GTK+ 3.0 integration
> > ii  libreoffice-kde  1:5.1.5~rc1-1 amd64office productivity suite 
> > -- KDE integration
> 
> or this :)

O.K.

> (That's exactly why I don't like reportbug it not picking up if you don't 
> report againstz
> libreoffice-core. See #819543)

Will this be fixed in the future?

> But yeah, so it's indeed gtk3 what you use.

Thanks for the info :)
Thomas.

-- 
The world wants to be deceived.
-- Sebastian Brant

Bug#798794: Exception in thread "main" java.awt.AWTError

[殷啟聰]

This bug can be seen if you run "draw9patch" of Android SDK even if
you installed default-jdk & libawk-wrapper-java. By following a thread
[1] on Ask Ubuntu I successfully run "draw9patch". The workaround is:

Uncomment ``` assistive_technologies=org.GNOME.Accessibility.AtkWrapper```
in file .

I'm not sure if this is a bug of openjdk-8-jre, but it is surely a bug.

[1]: 
https://askubuntu.com/questions/695560/assistive-technology-not-found-error-while-building-aprof-plot

Bug#815045: libmeanwhile1: Changing debian/rules solves the problem

[Andreas Wagner]

Package: libmeanwhile1
Version: 1.0.2-8
Followup-For: Bug #815045

Dear Maintainer,

I've downloaded source package, changed file "debian/rules" as Vasi B. 
mentioned and rebuild the package. Now I was able to connect to sametime server.

So Vasi's fix would solve this problem.

With kind regards,
Andreas Wagner

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

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

Versions of packages libmeanwhile1 depends on:
ii  libc6 2.23-1
ii  libglib2.0-0  2.48.1-2

libmeanwhile1 recommends no packages.

libmeanwhile1 suggests no packages.

-- no debconf information

Bug#832045: RM: tidy -- RoQA; abandoned; superseded by tidy-html5

[Daniel James]

Hi Emilio,

> I don't think there is any
> problem in removing the old src:tidy and let the new tidy-html5
> take over the binaries.

Thanks, this was due to an upstream name change, the Tidy project is now
hosted at https://github.com/htacg/tidy-html5/

The original maintainer of tidy in Debian, Jason Thomas, is now
contributing to the tidy-html5 package in collab-maint:

http://anonscm.debian.org/cgit/collab-maint/tidy-html5.git/

Cheers!

Daniel

Bug#764494: libmeanwhile1: Solution provided in #815045 would solve the problem

[Andreas Wagner]

Package: libmeanwhile1
Version: 1.0.2-8
Followup-For: Bug #764494

I've tested Vasi's solution as described in #815045 and could connect to 
sametime server.

With kind regards,
Andreas Wagner


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

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

Versions of packages libmeanwhile1 depends on:
ii  libc6 2.23-1
ii  libglib2.0-0  2.48.1-2

libmeanwhile1 recommends no packages.

libmeanwhile1 suggests no packages.

-- no debconf information

Bug#831493: O: aptsh -- apt interactive shell

[Axel Beckert]

Hi,

Tobias Frost wrote:
> The current maintainer of aptsh, Marcin Wrochniak ,
> is apparently not active anymore.  Therefore, I orphan this package now.
> 
> Maintaining a package requires time and skills. Please only adopt this
> package if you will have enough time and attention to work on it.

Let me add some more info for the prospective maintainer:

* This is a native package, i.e. you need to become upstream of aptsh
  to maintain the package.

* aptsh currently fails to build from source (FTBFS) for several
  reasons, not only for those already reported:

  + Uses no more supported debhelper compatibility level (easy to fix,
reported as https://bugs.debian.org/817350)

  + As soon as you've fixed that, you'll run into some C++ issues
(either APT 1.3 or GCC 6 related, maybe both) which aren't
obvious, at least not to me. (I shortly looked into it for an NMU
before the package was orphaned, but I really only had a quick
look at it.)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#826816: openjpeg removal patch

[Ole Streicher]

Control: tags -1 patch

Dear Alastair,

I am the maintainer of gnudatalanguage, which is a transitive dependency
of grib-api.

since grib-api does not support openjpeg2 without changes (also not when
d/p/openjpeg2.patch is applied), it may be worth just to disabple
openjpeg for the moment completely, in order to avoid removal of
grib-api and its dependencies from Testing. Once grib-api works with the
openjpeg2 API, it may be re-enabled without effort.

The attached patch just removes the build dependency from d/control.
Since the autoremoval is scheduled for Aug 8, I would do a NMU in the
first days of august.

Best regards

Ole
diff -Nru grib-api-1.16.0/debian/changelog grib-api-1.16.0/debian/changelog
--- grib-api-1.16.0/debian/changelog	2016-07-08 16:48:39.0 +0200
+++ grib-api-1.16.0/debian/changelog	2016-07-22 11:04:16.0 +0200
@@ -1,3 +1,10 @@
+grib-api (1.16.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove libopenjpeg-dev build dependency. Closes: #826816
+
+ -- Ole Streicher   Fri, 22 Jul 2016 10:09:37 +0200
+
 grib-api (1.16.0-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru grib-api-1.16.0/debian/control grib-api-1.16.0/debian/control
--- grib-api-1.16.0/debian/control	2016-07-08 16:48:39.0 +0200
+++ grib-api-1.16.0/debian/control	2016-07-22 11:03:13.0 +0200
@@ -5,7 +5,7 @@
 Uploaders: Enrico Zini 
 Build-Depends: debhelper (>= 9), dh-buildinfo, cmake,
   libjpeg-dev, libpng-dev, gfortran, flex, bison, quilt,
-  libnetcdf-dev, libopenjpeg-dev, libboost-dev, libhdf5-dev, 
+  libnetcdf-dev, libboost-dev, libhdf5-dev, 
   curl,swig, 
   python3-all-dev,  python3-numpy, python3-six,
   python-all-dev, python-numpy, python-six,

Bug#832095: patch for SSE-optimizing resampling of stereo signals

[Steinar H. Gunderson]

Package: libzita-resampler1
Version: 1.3.0-2
Severity: wishlist
Tags: upstream patch

Hi,

Please find attached a patch for SSE-optimizing resampling of stereo signals;
it makes this more or less three times as fast on Intel systems, without
sacrificing any quality.

I talked to upstream about this patch back in the day, and he seemed happy to
accept it, but somehow just stopped answering -- I guess he got busy with other
things in life. It would be nice if we could get it into Debian nevertheless
(I want it for reducing CPU used in my realtime video mixer).

It is taken to be by Steinar H. Gunderson  (ie., work hat
from my ex-job), and licensed under the same terms as zita-resampler itself
(ie., GPLv3+).

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

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

Versions of packages libzita-resampler1 depends on:
ii  libc6  2.23-2
ii  libgcc11:6.1.1-9
ii  libstdc++6 6.1.1-9
ii  multiarch-support  2.23-2

libzita-resampler1 recommends no packages.

libzita-resampler1 suggests no packages.

-- no debconf information
diff -ur orig/zita-resampler-1.3.0/libs/resampler.cc zita-resampler-1.3.0/libs/resampler.cc
--- orig/zita-resampler-1.3.0/libs/resampler.cc	2012-10-26 22:58:55.0 +0200
+++ zita-resampler-1.3.0/libs/resampler.cc	2015-11-15 12:27:42.764591015 +0100
@@ -24,6 +24,10 @@
 #include 
 #include 
 
+#ifdef __SSE2__
+#include 
+#endif
+
 
 static unsigned int gcd (unsigned int a, unsigned int b)
 {
@@ -47,6 +51,45 @@
 return 1; 
 }
 
+#ifdef __SSE2__
+
+static inline void calc_stereo_sample_sse (unsigned int hl,
+   float *c1,
+   float *c2,
+   float *q1,
+   float *q2,
+   float *out_data)
+{
+unsigned int   i;
+__m128 denorm, s, w1, w2;
+
+denorm = _mm_set1_ps (1e-20f);
+s = denorm;
+for (i = 0; i < hl; i += 4)
+{
+	q2 -= 8;
+
+	// s += *q1 * c1 [i];
+	w1 = _mm_loadu_ps (&c1 [i]);
+	s = _mm_add_ps (s, _mm_mul_ps (_mm_loadu_ps (q1), _mm_unpacklo_ps (w1, w1)));
+	s = _mm_add_ps (s, _mm_mul_ps (_mm_loadu_ps (q1 + 4), _mm_unpackhi_ps (w1, w1)));
+
+	// s += *q2 * c2 [i];
+	w2 = _mm_loadu_ps (&c2 [i]);
+	s = _mm_add_ps (s, _mm_mul_ps (_mm_loadu_ps (q2 + 4), _mm_shuffle_ps (w2, w2, _MM_SHUFFLE (0, 0, 1, 1;
+	s = _mm_add_ps (s, _mm_mul_ps (_mm_loadu_ps (q2), _mm_shuffle_ps (w2, w2, _MM_SHUFFLE (2, 2, 3, 3;
+
+	q1 += 8;
+}
+s = _mm_sub_ps (s, denorm);
+s = _mm_add_ps (s, _mm_shuffle_ps (s, s, _MM_SHUFFLE (1, 0, 3, 2)));
+
+// Writes two bytes more than we want, but this is fine since out_count >= 2.
+_mm_storeu_ps (out_data, s);
+}
+
+#endif
+
 
 Resampler::Resampler (void) :
 _table (0),
@@ -213,18 +256,28 @@
 		{
 		float *c1 = _table->_ctab + hl * ph;
 		float *c2 = _table->_ctab + hl * (np - ph);
-		for (c = 0; c < _nchan; c++)
+#ifdef __SSE2__
+		if ((hl % 4) == 0 && _nchan == 2 && out_count >= 2)
 		{
-			float *q1 = p1 + c;
-			float *q2 = p2 + c;
-			float s = 1e-20f;
-			for (i = 0; i < hl; i++)
+			calc_stereo_sample_sse (hl, c1, c2, p1, p2, out_data);
+			out_data += 2;
+		}
+		else
+#endif
+{
+			for (c = 0; c < _nchan; c++)
 			{
-			q2 -= _nchan;
-			s += *q1 * c1 [i] + *q2 * c2 [i];
-			q1 += _nchan;
+			float *q1 = p1 + c;
+			float *q2 = p2 + c;
+			float s = 1e-20f;
+			for (i = 0; i < hl; i++)
+			{
+q2 -= _nchan;
+s += *q1 * c1 [i] + *q2 * c2 [i];
+q1 += _nchan;
+			}
+			*out_data++ = s - 1e-20f;
 			}
-			*out_data++ = s - 1e-20f;
 		}
 		}
 		else
@@ -260,4 +313,3 @@
 return 0;
 }
 
-
diff -ur orig/zita-resampler-1.3.0/libs/vresampler.cc zita-resampler-1.3.0/libs/vresampler.cc
--- orig/zita-resampler-1.3.0/libs/vresampler.cc	2012-10-26 22:58:55.0 +0200
+++ zita-resampler-1.3.0/libs/vresampler.cc	2015-11-15 12:27:58.424544882 +0100
@@ -25,6 +25,58 @@
 #include 
 
 
+#ifdef __SSE2__
+
+#include 
+
+static inline void calc_stereo_sample_sse (int hl,
+   float b,
+   float *p1,
+   float *p2,
+   float *q1,
+   float *q2,
+   float *out_data)
+{
+inti;
+__m128 denorm, bs, s, c1, c2, w1, w2;
+
+denorm = _mm_set1_ps (1e-25f);
+bs = _mm_set1_ps (b);
+s = denorm;
+for

Bug#832098: transition: llvm-defaults

[Sylvestre Ledru]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hello,

This is again the time to transition to a more recent version of LLVM.
This time, I would be more agressive and skip the 3.7 transition:
* takes too much time
* 3.8 is stable with its 3.8.1 release
* 3.7 is no longer maintained
* we have too many releases of llvm in the archive
* I don't remember seeing critical changes between 3.7 and 3.8

Ben file:

title = "llvm-defaults-3.8";
is_affected = .depends ~ "lib(clang1-3.5|libllvm3.5|clang1-3.6|libllvm3.6)" | 
.depends ~ "lib(clang1-3.8|libllvm3.8)";
is_good = .depends ~ "lib(clang1-3.8|libllvm3.8)";
is_bad = .depends ~ "lib(clang1-3.5|libllvm3.5|clang1-3.6|libllvm3.6)";


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (900, 'testing'), (600, 'unstable'), (500, 'stable'), (300, 
'experimental')
Architecture: amd64 (x86_64)

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

Bug#832097: new upstream version 1.0.21-rc1

[Steinar H. Gunderson]

Source: libusb-1.0
Version: 2:1.0.20-1
Severity: wishlist

Hi,

libusb-1.0 1.0.21-rc1 is out; do you think it would be possible to package it
for unstable? I'm interested especially since it has zerocopy USB support that
I need for my live video mixer.

Thanks!

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

Kernel: Linux 4.7.0-rc1 (SMP w/40 CPU cores)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#832096: lintian: please check for common typos in debian/rules target names

[Chris Lamb]

Source: lintian
Version: 2.5.45
Severity: wishlist
Tags: patch

Hi,

Attached is the following:

  commit 22f75ee230c6ae93e9192a663225626e73cf14c7
  Author: Chris Lamb 
  Date:   Fri Jul 22 10:36:54 2016 +0100
  
  c/rules: Check for common typos in debian/rules target names.
  
  Misspelling an target (eg. "override_dh_install_debconf") results in that
  rule silently not being called. See #831772 for an example in the wild.
  
  Signed-off-by: Chris Lamb 
  
   checks/rules.desc |  7 +++
   checks/rules.pm   |  4 
   data/rules/target-typos   | 32 
+++
   t/tests/rules-general/debian/debian/rules |  2 ++
   t/tests/rules-general/desc|  3 ++-
   t/tests/rules-general/tags|  1 +
   6 files changed, 48 insertions(+), 1 deletion(-)


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
From 22f75ee230c6ae93e9192a663225626e73cf14c7 Mon Sep 17 00:00:00 2001
From: Chris Lamb 
Date: Fri, 22 Jul 2016 10:36:54 +0100
Subject: [PATCH] c/rules: Check for common typos in debian/rules target names.

Misspelling an target (eg. "override_dh_install_debconf") results in that
rule silently not being called. See #831772 for an example in the wild.

Signed-off-by: Chris Lamb 
---
 checks/rules.desc |  7 +++
 checks/rules.pm   |  4 
 data/rules/target-typos   | 32 +++
 t/tests/rules-general/debian/debian/rules |  2 ++
 t/tests/rules-general/desc|  3 ++-
 t/tests/rules-general/tags|  1 +
 6 files changed, 48 insertions(+), 1 deletion(-)
 create mode 100644 data/rules/target-typos

diff --git a/checks/rules.desc b/checks/rules.desc
index 25c565b..70e64fc 100644
--- a/checks/rules.desc
+++ b/checks/rules.desc
@@ -248,3 +248,10 @@ Info: The source package does not have both a build-arch and a build-indep
  .
  Please consider adding both the build-arch and build-indep targets.
 
+Tag: typo-in-debian-rules-target
+Severity: normal
+Certainty: certain
+Info: The listed target in debian/rules command is a misspelling.
+ .
+ This can result in (for example) an dh_override_-style target
+ silently not being executed by make.
diff --git a/checks/rules.pm b/checks/rules.pm
index bd3a141..1100032 100644
--- a/checks/rules.pm
+++ b/checks/rules.pm
@@ -38,6 +38,7 @@ our $ANYPYTHON_DEPEND
 my $KNOWN_MAKEFILES = Lintian::Data->new('rules/known-makefiles', '\|\|');
 my $DEPRECATED_MAKEFILES = Lintian::Data->new('rules/deprecated-makefiles');
 my $POLICYRULES = Lintian::Data->new('rules/policy-rules', qr/\s++/);
+my $TARGETTYPOS = Lintian::Data->new('rules/target-typos', qr/\s++/);
 
 # forbidden construct in rules
 my $BAD_CONSTRUCT_IN_RULES
@@ -313,6 +314,9 @@ sub run {
 if (any { $target =~ /$_/ } @arch_rules) {
 push(@arch_rules, @depends);
 }
+tag 'typo-in-debian-rules-target', $target, '->',
+$TARGETTYPOS->value($target), "(line $.)"
+if ($TARGETTYPOS->known($target));
 }
 undef %debhelper_group;
 } elsif (/^define /) {
diff --git a/data/rules/target-typos b/data/rules/target-typos
new file mode 100644
index 000..9dd2e7f
--- /dev/null
+++ b/data/rules/target-typos
@@ -0,0 +1,32 @@
+# a list of common incorrect targets in debian/rules
+# format is
+#
+#
+override_dh_autotest			override_dh_auto_test
+override_dh_install_catalogs		override_dh_installcatalogs
+override_dh_install_changelog		override_dh_installcangelogs
+override_dh_install_changelog		override_dh_installchangelogs
+override_dh_install_cron		override_dh_installcron
+override_dh_install_deb			override_dh_installdeb
+override_dh_install_debconf		override_dh_installdebconf
+override_dh_install_dirs		override_dh_installdirs
+override_dh_install_docs		override_dh_installdocs
+override_dh_install_emacsen		override_dh_installemacsen
+override_dh_install_example		override_dh_installexamples
+override_dh_install_examples		override_dh_installexamples
+override_dh_install_info		override_dh_installinfo
+override_dh_install_init		override_dh_installinit
+override_dh_install_logcheck		override_dh_installlogcheck
+override_dh_install_logrotate		override_dh_installlogrotate
+override_dh_install_man			override_dh_installman
+override_dh_install_manpage		override_dh_installmanpage
+override_dh_install_manpages		override_dh_installmanpage
+override_dh_install_mans		override_dh_installman
+override_dh_install_menu		override_dh_installmenu
+override_dh_install_mime		override_dh_installmime
+override_dh_install_modules		override_dh_installmodules
+override_dh_install_pam			override_dh_installpam
+override_dh_install_udev		override_dh_installudev
+override_dh_install_xmlcatalogs		override_dh_installxmlcat

Bug#832098: transition: llvm-defaults

[Emilio Pozuelo Monfort]

On 22/07/16 11:40, Sylvestre Ledru wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hello,
> 
> This is again the time to transition to a more recent version of LLVM.
> This time, I would be more agressive and skip the 3.7 transition:
> * takes too much time
> * 3.8 is stable with its 3.8.1 release
> * 3.7 is no longer maintained
> * we have too many releases of llvm in the archive
> * I don't remember seeing critical changes between 3.7 and 3.8

Yes please! But first the build problems need to be fixed:

https://buildd.debian.org/status/package.php?p=llvm-toolchain-3.8&suite=sid

Cheers,
Emilio

Bug#829272: Missing accessors

[Richard Levitte via RT]

On Fri Jul 22 07:38:25 2016, mattias.ell...@physics.uu.se wrote:
> tor 2016-07-21 klockan 09:51 + skrev Richard Levitte via RT:
> > On Thu Jul 21 08:18:30 2016, mattias.ell...@physics.uu.se wrote:
> > >
> > > ons 2016-07-20 klockan 15:14 + skrev Richard Levitte via RT:
> > > >
> > > > On Mon Jul 11 11:34:35 2016, mattias.ell...@physics.uu.se wrote:
> > > > >
> > > > >
> > > > > I guess having a more restrictive accessor that only sets the
> > > > > EXFLAG_PROXY bit could work. I suggested the more general
> > > > > solution
> > > > > of
> > > > > having set/clear accessors for arbitrary flags since it was -
> > > > > well
> > > > > more
> > > > > general.
> > > >
> > > > So let me ask this in a different manner, does OpenSSL 1.1 still
> > > > not
> > > > set the
> > > > EXFLAG_PROXY flag correctly? In what situations does that happen?
> > > > That may be
> > > > worth a bug report of its own.
> > > >
> > > > --
> > > > Richard Levitte
> > > > levi...@openssl.org
> > > >
> > >
> > > The answer to this is related to Mischa's reply, which
> > > unfortunately
> > > was only sent to the Debian BTS and not the the OpenSSL RT. I quote
> > > it
> > > below. As indicated in the answer, setting the EXFLAG_PROXY allows
> > > handling non-RFC proxies in OpenSSL.
> > >
> > > mån 2016-07-11 klockan 14:53 +0200 skrev Mischa Salle:
> > > >
> > > > Hi Richard, Mattias, others,
> > > >
> > > > I agree with you that it would be nice if OpenSSL could figure
> > > > out
> > > > itself whether a cert needs to be treated as a proxy, but
> > > > currently
> > > > that
> > > > doesn't work reliably as far as I know.
> > > > The flag is certainly needed in the case of non-RFC3820 proxies,
> > > > also
> > > > known as legacy proxies. Unfortunately these are still very
> > > > widely
> > > > used
> > > > (majority of the proxies actually) and hence our code must be
> > > > able to
> > > > handle them correctly.
> > > >
> > > > Best wishes,
> > > > Mischa Sallé
> > > >
> >
> > Ok... From looking at the voms code that was linked to earlier, I can
> > see that
> > legacy proxy certs are recognised by an older OID (called
> > PROXYCERTINFO_V3 in
> > the code), 1.3.6.1.4.1.3536.1.222. Is there a spec for the extensions
> > in that
> > version, whether they are critical or not and so on, that I can
> > reach? Or is
> > the OID the only actual difference? If it's easy enough (and it
> > currently does
> > look quite easy), I can certainly see adding some code in OpenSSL to
> > recognise
> > those...
> >
> > --
> > Richard Levitte
> > levi...@openssl.org
>
> As far as I know there are three different kinds of proxies, usually
> called "legacy", "draft" and "rfc", or sometimes version 2, 3 and 4
> respectively.
>
> For example see "grid-proxy-init -help":
>
> -draft Creates a draft (GSI-3) proxy
> -old Creates a legacy globus proxy
> -rfc Creates a RFC 3820 compliant proxy
>
> The really tricky one is the old legacy version 2 proxy I think.

Ok, so after doing quite a bit of searching, I found some references to GT2
(old) in a 3.0 document:

http://toolkit.globus.org/toolkit/docs/3.0/gsi/GSI-message-specification-02.doc
(section 5)

As I understand it, the GT2 format is a simple EE cert, with just two
differences:

1. the issuer is also a EE (so it has the basic constraint CA set to false)...
or it's another GT2 proxy, which amounts to the same thing.
2. the subject name is the issuer name plus an appended 'CN=Proxy' or
'CN=LimitedProxy'

Good so far?

My main problem here is GT3 (draft) proxy certs. If I look at
https://tools.ietf.org/html/draft-ietf-pkix-proxy-10, they look exactly the
same as RFC3820 proxy certs, down to the extension OID. If I look at a really
old draft
(http://sigillum.pl/upload/pdf/Internet%20X.509%20Public%20Key%20Infrastructure.%20Proxy%20Certificate%20Profile.pdf),
the difference is *wild*, and if look at a random shell script
(https://www.nikhef.nl/~janjust/proxy-verify/genproxy) I found while searching
for OID 1.3.6.1.4.1.3536.1.222, I find a third variant that has a slightly
different proycertinfo extension...

Btw, this should really become a new ticket, along the lines of "OpenSSL
doesn't recognise earlier proxy certs".

--
Richard Levitte
levi...@openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted

Bug#829409: libhtml-tidy-perl: FTBFS: Failed 7/21 test programs. 8/69 subtests failed.

[Simon McVittie]

On Sun, 03 Jul 2016 at 07:54:05 +0200, Chris Lamb wrote:
> libhtml-tidy-perl fails to build from source in unstable/amd64

I don't think it was necessarily a good idea to forward this upstream:
the build failure is because Debian forked this Perl module to stop using
its author's fork (tidyp) of the underlying C library (tidy), and now we've
also replaced the C library with a different fork (tidy-html5), which is
what's making the tests fail.

The author of HTML::Tidy seems quite likely to respond "if you had
packaged my fork of tidy like the documentation told you to, you wouldn't
have this problem".

However, tidy-html5 seems likely to be better than either tidy or tidyp,
so hopefully the HTML::Tidy author will be somewhat receptive to the idea
of supporting tidy-html5.

Possible patches for the Debian packaging attached, also available from
.

S
>From 2bca8ddf43494c9f6d2b5c516088e0c3cf5682ac Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Fri, 22 Jul 2016 09:45:53 +0100
Subject: [PATCH 1/4] d/p/fix-error-message-in-webtidy: move to end of patch
 series

This is a firmly Debian-specific change that is not suitable for upstream.
---
 debian/changelog  | 5 +
 debian/patches/series | 2 +-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index 1eeac67..d0db8e1 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -10,6 +10,11 @@ libhtml-tidy-perl (1.56-2) UNRELEASED; urgency=medium
   [ gregor herrmann ]
   * debian/copyright: change Copyright-Format 1.0 URL to HTTPS.
 
+  [ Simon McVittie ]
+  * d/p/fix-error-message-in-webtidy: move to end of patch series.
+This is a firmly Debian-specific change that is not suitable for
+upstream.
+
  -- gregor herrmann   Thu, 27 Feb 2014 22:36:29 +0100
 
 libhtml-tidy-perl (1.56-1) unstable; urgency=low
diff --git a/debian/patches/series b/debian/patches/series
index 57718d6..4adbeaa 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,3 +1,3 @@
-fix-error-message-in-webtidy
 remove-tidy_version.patch
 tidy-not-tidyp.patch
+fix-error-message-in-webtidy
-- 
2.8.1

>From 447aa2e692a4276dc51c0e1d958c19f231c54279 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Fri, 22 Jul 2016 09:46:18 +0100
Subject: [PATCH 2/4] d/patches: put all patches in the git style allowed by
 DEP-3, so they can be manipulated with gbp-pq

---
 debian/changelog|  2 +
 debian/patches/fix-error-message-in-webtidy | 13 +++--
 debian/patches/remove-tidy_version.patch| 79 ++---
 debian/patches/tidy-not-tidyp.patch | 19 +--
 4 files changed, 76 insertions(+), 37 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index d0db8e1..2c0a999 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -14,6 +14,8 @@ libhtml-tidy-perl (1.56-2) UNRELEASED; urgency=medium
   * d/p/fix-error-message-in-webtidy: move to end of patch series.
 This is a firmly Debian-specific change that is not suitable for
 upstream.
+  * d/patches: put all patches in the git style allowed by DEP-3,
+so they can be manipulated with gbp-pq
 
  -- gregor herrmann   Thu, 27 Feb 2014 22:36:29 +0100
 
diff --git a/debian/patches/fix-error-message-in-webtidy b/debian/patches/fix-error-message-in-webtidy
index afdfb7c..0efb8d3 100644
--- a/debian/patches/fix-error-message-in-webtidy
+++ b/debian/patches/fix-error-message-in-webtidy
@@ -1,10 +1,17 @@
-Description: make webtidy error message more debianish
-Author: Ryan Niebur 
+From: Ryan Niebur 
+Date: Tue, 2 Jun 2009 21:15:36 -0700
+Subject: make webtidy error message more debianish
+
 Forwarded: not-needed
+---
+ bin/webtidy | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
 
+diff --git a/bin/webtidy b/bin/webtidy
+index be57814..4a92423 100755
 --- a/bin/webtidy
 +++ b/bin/webtidy
-@@ -29,7 +29,7 @@
+@@ -29,7 +29,7 @@ for my $url ( @ARGV ) {
  my @lines;
  if ( $url =~ /^https?:/ ) {
  if ( !eval { require LWP::Simple; 1; } ) {
diff --git a/debian/patches/remove-tidy_version.patch b/debian/patches/remove-tidy_version.patch
index 6bbeffa..7b553f2 100644
--- a/debian/patches/remove-tidy_version.patch
+++ b/debian/patches/remove-tidy_version.patch
@@ -1,15 +1,26 @@
-Description: remove tidyVersion as it is a special call
- to Andy Lester's modified version of libtidy. Also remove
- the corresponding call from Perl, the documentation, and
- the tests.
-Author: gregor herrmann 
+From: gregor herrmann 
+Date: Sat, 20 Feb 2010 09:50:30 -0500
+Subject: remove tidyVersion
+
+It is a special call to Andy Lester's modified version of libtidy. Also
+remove the corresponding call from Perl, the documentation, and the tests.
+
 Reviewed-by: Jonathan Yu 
 Origin: vendor
 Forwarded: not-needed
+---
+ Tidy.xs  | 11 ---
+ bin/webtidy  |  2 +-
+ lib/HTML/Tidy.pm | 17 -
+ t/00-load.t  |  2 +-
+ t/version.t  |  5 +
+ 5 files changed, 7 insertions(+), 30 deletio

Bug#826656: [Pkg-cmake-team] Bug#826656: openssl 1.0.1t in jessie broke find_package OpenSSL

[Felix Geyer]

Hi,

On 2016-07-13 09:20, Ute Witt wrote:

Hi,
just ran into the same error output with Debian jessie armhf. Full
upgrade didn't solve the problem.

cmake_3.0.2-1_armhf.deb
libssl-dev_1.0.1t-1+deb8u2_armhf.deb


You need to enable jessie-proposed-updates if you don't want to wait for 
the next point release:

https://wiki.debian.org/StableProposedUpdates

Felix

Bug#832099: lintian: please check for unnecessary SOURCE_DATE_EPOCH assignments

[Chris Lamb]

Source: lintian
Version: 2.5.45
Severity: wishlist
Tags: patch
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi,

Attached is the following:

  commit 3b10f7dbaecedb0a458c25cc0b8615b489d424af
  Author: Chris Lamb 
  Date:   Fri Jul 22 10:54:02 2016 +0100
  
  c/rules: Check for unnecessary SOURCE_DATE_EPOCH assignments
  
  As of dpkg 1.18.8, this is no longer necessary as dpkg exports this
  variable if it is not already set (#75). This should encourage
  removing some duplicated code from a lot of our rules files.
  
  Signed-off-by: Chris Lamb 
  
   checks/rules.desc | 8 
   checks/rules.pm   | 2 ++
   t/tests/rules-general/debian/debian/rules | 2 ++
   t/tests/rules-general/desc| 3 ++-
   t/tests/rules-general/tags| 7 ---
   5 files changed, 18 insertions(+), 4 deletions(-)



Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
From 3b10f7dbaecedb0a458c25cc0b8615b489d424af Mon Sep 17 00:00:00 2001
From: Chris Lamb 
Date: Fri, 22 Jul 2016 10:54:02 +0100
Subject: [PATCH] c/rules: Check for unnecessary SOURCE_DATE_EPOCH assignments

As of dpkg 1.18.8, this is no longer necessary as dpkg exports this
variable if it is not already set (#75). This should encourage
removing some duplicated code from a lot of our rules files.

Signed-off-by: Chris Lamb 
---
 checks/rules.desc | 8 
 checks/rules.pm   | 2 ++
 t/tests/rules-general/debian/debian/rules | 2 ++
 t/tests/rules-general/desc| 3 ++-
 t/tests/rules-general/tags| 7 ---
 5 files changed, 18 insertions(+), 4 deletions(-)

diff --git a/checks/rules.desc b/checks/rules.desc
index 25c565b..13bf4c2 100644
--- a/checks/rules.desc
+++ b/checks/rules.desc
@@ -248,3 +248,11 @@ Info: The source package does not have both a build-arch and a build-indep
  .
  Please consider adding both the build-arch and build-indep targets.
 
+Tag: unnecessary-source-date-epoch-assignment
+Severity: normal
+Certainty: certain
+Info: There is an assignment to a SOURCE_DATE_EPOCH variable in the
+  debian/rules file.  As of dpkg 1.18.8, this is no longer necessary
+  as dpkg exports this variable if it is not already set.
+  .
+  Consider removing this assignment.
diff --git a/checks/rules.pm b/checks/rules.pm
index bd3a141..ce77909 100644
--- a/checks/rules.pm
+++ b/checks/rules.pm
@@ -226,6 +226,8 @@ sub run {
 # rather well.
 my ($var, $value) = ($1, $2);
 $variables{$var} = $value;
+tag 'unnecessary-source-date-epoch-assignment', "line $."
+if $var eq "SOURCE_DATE_EPOCH";
 }
 
 # Keep track of whether this portion of debian/rules may be optional
diff --git a/t/tests/rules-general/debian/debian/rules b/t/tests/rules-general/debian/debian/rules
index cddbc03..121305a 100755
--- a/t/tests/rules-general/debian/debian/rules
+++ b/t/tests/rules-general/debian/debian/rules
@@ -2,6 +2,8 @@
 
 DEB_AUTO_UPDATE_DEBIAN_CONTROL = yes
 
+export SOURCE_DATE_EPOCH = $(shell date -d "$$(dpkg-parsechangelog -SDate)" +%s)
+
 %:
 	dh $@
 
diff --git a/t/tests/rules-general/desc b/t/tests/rules-general/desc
index 1f41c20..cab329e 100644
--- a/t/tests/rules-general/desc
+++ b/t/tests/rules-general/desc
@@ -7,4 +7,5 @@ Test-For:
  debian-rules-should-not-automatically-update-control
  debian-rules-should-not-use-DEB_BUILD_OPTS
  debian-rules-should-not-use-pwd
- debian-rules-should-not-use-underscore-variable
\ No newline at end of file
+ debian-rules-should-not-use-underscore-variable
+ unnecessary-source-date-epoch-assignment
diff --git a/t/tests/rules-general/tags b/t/tests/rules-general/tags
index 3e7351b..6675064 100644
--- a/t/tests/rules-general/tags
+++ b/t/tests/rules-general/tags
@@ -1,5 +1,6 @@
 E: rules-general source: clean-should-be-satisfied-by-build-depends debhelper
 E: rules-general source: debian-rules-should-not-automatically-update-control line 3
-W: rules-general source: debian-rules-should-not-use-DEB_BUILD_OPTS line 10
-W: rules-general source: debian-rules-should-not-use-pwd line 10
-W: rules-general source: debian-rules-should-not-use-underscore-variable line 11
+W: rules-general source: debian-rules-should-not-use-DEB_BUILD_OPTS line 12
+W: rules-general source: debian-rules-should-not-use-pwd line 12
+W: rules-general source: debian-rules-should-not-use-underscore-variable line 13
+W: rules-general source: unnecessary-source-date-epoch-assignment line 5
-- 
2.8.1

Bug#832097: new upstream version 1.0.21-rc1

[Aurelien Jarno]

On 2016-07-22 11:38, Steinar H. Gunderson wrote:
> Source: libusb-1.0
> Version: 2:1.0.20-1
> Severity: wishlist
> 
> Hi,
> 
> libusb-1.0 1.0.21-rc1 is out; do you think it would be possible to package it
> for unstable? I'm interested especially since it has zerocopy USB support that
> I need for my live video mixer.

I don't think it's appropriate for unstable yet, but I'll put it in
experimental.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#832100: RFS: eclib/20160720-1

[Julien Puydt]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "eclib"

 * Package name: eclib
   Version : 20160720-1
   Upstream Author : John Cremona
 * URL : https://github.com/JohnCremona/eclib/
 * License : GPL-2+
   Section : math

  It builds those binary packages:

eclib-tools - Programs for modular symbols and elliptic curves over Q
 libec-dev  - Library for modular symbols and elliptic curves over Q 
(developme

 libec2 - Library for modular symbols and elliptic curves over Q

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


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


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

dget -x 
https://mentors.debian.net/debian/pool/main/e/eclib/eclib_20160720-1.dsc


  It is packaged within the Debian Science team:
Vcs-Git: https://anonscm.debian.org/git/debian-science/packages/eclib.git
Vcs-Browser: 
https://anonscm.debian.org/cgit/debian-science/packages/eclib.git



  This upload is a new upstream version -- a bugfix release for better 
C++11 support.


Cheers,

Snark on #debian-science

Bug#832050: [buildd-tools-devel] Bug#832050: sbuild: Allow to run commands as root before/after installing the build dependencies

[Raphael Hertzog]

Hi,

On Fri, 22 Jul 2016, Johannes Schauer wrote:
> Quoting Raphaël Hertzog (2016-07-21 21:18:52)
> > I have updated a library and in the process I renamed ftplib-dev into
> > libftp-dev (which provides "ftplib-dev") and I want to ensure that
> > reverse dependencies build correctly with the new package. I used
> > --extra-package to inject my package but the new package does not get
> > picked due to the new name... but if I could install the new package
> > before build dependencies are installed, then I could test my package.
> 
> How about:
> 
>   sbuild --add-depends libftp-dev=VERSION

That would work for me for my specific need. I was just trying to suggest
something that could be more generally useful. But it's up to you.

It would not allow customizing something installed by a build dependency in
/etc for example.

> > So I want a new option like --pre-build-deps-commands="apt-get install 
> > libftp-dev"
> > Ideally I'm sure there are cases where we want to fix the set of packages
> > after having installed the build dependencies... so a --pre-build-commands
> > running as root would be nice too.
> 
> Why does --chroot-setup-commands not work in your case?

Because the extra packages are not yet available at that point in time.
But if you ensure that they are, then I'm happy with using that hook.

$ sbuild --extra-package=libftp4_4.0-1-1_amd64.deb 
--extra-package=libftp-dev_4.0-1-1_amd64.deb --chroot-setup-commands="apt-get 
install libftp-dev" -d unstable coriander_2.0.2-4
[...]
+--+
| Chroot Setup Commands|
+--+


apt-get install libftp-dev
--

Reading package lists...
Building dependency tree...
Reading state information...
E: Unable to locate package libftp-dev

E: Command 'apt-get install libftp-dev' failed to run.
[...]

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Bug#832097: new upstream version 1.0.21-rc1

[Steinar H. Gunderson]

On Fri, Jul 22, 2016 at 11:57:11AM +0200, Aurelien Jarno wrote:
> I don't think it's appropriate for unstable yet, but I'll put it in
> experimental.

Thanks, that sounds reasonable.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#832101: pavucontrol configuration tab empty and other issues with pulseaudio 9

[bbuggreport@discard.email]

Package: pulseaudio
Version: 9.0-1.1

 
The pavucontrol configuration tab is empty since update to pulseaudio 9 - on 
two different pc! An error message is shown under this tab (something like no 
devices found).
Also I'm not able to record the monitored sound.
Also master sound is muted after a restart, only qasmixer can switch it back 
on, not pavucontrol.
Reverting back to stable version restores all fuctions (so I did).
Hardware is Realtek HD audio on both machines.
 

Bug#832096: lintian: please check for common typos in debian/rules target names

[Jakub Wilk]

Hi Chris!

Thanks for the patch. I agree it would cool to have a check like this in 
Lintian.


* Chris Lamb , 2016-07-22, 11:38:

Misspelling an target (eg. "override_dh_install_debconf") results in that


Typo: an -> a


+ This can result in (for example) an dh_override_-style target


Ditto.


+override_dh_install_changelog  override_dh_installcangelogs


Typo in the correction...


+override_dh_install_changelog  override_dh_installchangelogs


...but this one is good. :)


+override_dh_install_manpageoverride_dh_installmanpage
+override_dh_install_manpages   override_dh_installmanpage


Typo in the correction: s/manpage$/manpages/.

Lintian is already aware of existing dh_* commands (see 
data/debhelper/dh_commands), so maybe we could use this list instead of 
manually maintaining possible misspellings?


--
Jakub Wilk

Bug#832074: networking.service: Start operation timed out

[Guus Sliepen]

On Thu, Jul 21, 2016 at 06:43:15PM -0700, Gerald Turner wrote:

> I have a Linux router running jessie that has four ethernet ports and a
> pair of ath9k radios.
> 
> Three of the ethernet interfaces (eth0, eth1, eth2) are statically
> configured LAN ports.  The fourth ethernet interface (eth3) is connected
> to an ISP via cable modem and uses DHCP¹.  The two wlan interfaces are
> also configured statically and have hostapd running.
[...]
> My vague understanding is that wlan0/wlan1 don't have "carrier" until
> hostapd's take control.  I believe this is what's causing ifupdown
> networking.service to timeout.

Hm, I don't think that can be the problem. First, the carrier has
nothing to do with hotplugging. Hotplugging is when udev detects that a
device is added or removed. This should happen early at boot for your
radios. Second, you are doing static configuration of those interfaces.
That means ifupdown just executes the equivalent of the ifconfig
command. It doesn't wait for anything here. So this cannot be the
problem. Last, allow-hotplug interfaces are configured asynchronously
wrt. the normal boot process, so even if something would hang here, it
should not interfere with the boot process.

If anything, ifupdown waits for dhclient on the eth3 interface to exit
before continuing. But according to your syslog it seems it got an IP
address just fine:

> Jul 21 17:02:09 headboard ifup[2426]: DHCPREQUEST on eth3 to 255.255.255.255 
> port 67
> Jul 21 17:02:09 headboard ifup[2426]: DHCPACK from 69.252.80.75
> Jul 21 17:02:30 headboard systemd[1]: networking.service: Start operation 
> timed out. Terminating.

Maybe there is something in the backported ifupdown that doesn't
interact well with dhclient or something else from jessie. Could you try
removing "auto eth3" from /etc/network/interfaces and see if that fixes
the timeout? If that doesn't change anything, try removing the
"allow-hotplug" lines. That would at least narrow things down.

> P.S. I noticed there's an /lib/systemd/system/ifup@.service file
> installed by ifupdown, however I don't see it used anywhere, no
> documentation, and only found a few meaningless results about it on the
> www.  Would it be sensible to disable networking.service and enable
> ifup@eth0 et al services (perhaps with After=hostapd for ifup@wlan0/1)?

I wouldn't disable networking.service, instead don't mark those
interfaces auto then.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: Digital signature

Bug#832102: transition: ftplib

[Raphaël Hertzog]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hello,

I have small transition in the ftplib package, the SONAME got
bumped but the API is fully backwards-compatible. The package
is ready in experimental and I tested that the build of the 4 reverse
dependencies still succeeds against the new library.

I took this opportunity to rename "ftplib-dev" into "libftp-dev",
the latter providing the former so as to not break existing build
dependencies. Similarly ftplib3 morphed into libftp4.

Let me know when I can upload to unstable.

Ben file:

title = "ftplib";
is_affected = .depends ~ "ftplib3" | .depends ~ "libftp4";
is_good = .depends ~ "libftp4";
is_bad = .depends ~ "ftplib3";


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

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

Bug#803647: No solution for llvm and gambas (for now)

[Gianfranco Costamagna]

control: forwarded -1 http://gambaswiki.org/bugtracker/edit?object=BUG.835

thanks



signature.asc
Description: OpenPGP digital signature

Bug#831873: xrdp created dir ${HOME}/.thinclient_drives which has permissions 000 belongs to root

[Andreas Tille]

[including Debian GNOME Maintainers as maintainer of gvfs into the
 discussion.  The issue id that when using xrdp 0.9 from Jessie backports
 gvfs seems to have trouble with the dir ~user/.thinclient_drives]

On Thu, Jul 21, 2016 at 12:16:09AM +0200, Dominik George wrote:
> On Mittwoch, 20. Juli 2016 23:03:11 CEST Andreas Tille wrote:
> > Hi Dominik,
> > 
> > On Wed, Jul 20, 2016 at 05:58:40PM +0200, Dominik George wrote:
> > > Some references:
> > > 
> > > http://serverfault.com/questions/188894/denied-root-access-to-user-mounted
> > > -fuse-file-system
> > > 
> > > In conclusion, I think it is arguable whether xrdp should create that
> > > directory. IMHO, the behaviour is correct.
> > 
> > But also the user can not see this dir.  I need to try again tomorrow.
> 
> Are you sure about that?

Yes.  On the production machine in question this was the case.  I have
rolled back to xrdp 0.6 to enable users to keep on working.  Please note
that besides this xrdp 0.9 was crashing randomly several times so the
rollback became necessary in any case.  It would be great if you could
raise your opinion on the thread in debian-edu list but this should be
discussed separately.

I'm now trying to reproduce the issue on a *different* machine which I
used for testing previously.

> Please verify again by doing the following:
> 
> Log in to the machine as root.
> Make sure the user is not logged in.
> Make sure that nothing is mounted on ~user/.thinclient_drives.

I've umounted everything now.

> rm -rf ~user/.thinclient_drives

done.

> Have the user log in through xrdp, with directory sharing enabled.

What do you mean by "with directory sharing enabled".  I'm just logging
in.  If there is a specific option please tell me how I can (de)activate
it.

> Have the user open a terminal and type ls -lhad ~/.thinclient_drives

$ ls -lhad ~/.thinclient_drives/
drwxr-xr-x 0 root root 0 Jan  1  1970 /home/tillea/.thinclient_drives/
$ mount | grep .thinclient_drives
xrdp-chansrv on /home/tillea/.thinclient_drives type fuse.xrdp-chansrv 
(rw,nosuid,nodev,relatime,user_id=1001,group_id=1001)

> At this point. on my jessie machine, I see the directory owned by root with 
> permissions 755 (which is correct).

I confirm the directory is owned by root with permissions 755 zero byte
size and dated 1970-01-01.
 
> Look at the directory as root while the user is logged in. It should indeed 
> be 
> shown with 000 permissions. *This is correct* - it is a design decision 
> (flaw?) of FUSE and well-known. Without special mount options, the krenel 
> refuses to disclose anything about a FUSE mountpoint to anyone, including 
> root. I think this is stupid - but that's how things are.

OK, I confirm the fact (permissions 000) and will not question those
design decisions.

> > > But in any case, this is not a bug, and even less an important one,
> > > because the creation and use of the directory as a FUSE mount point is
> > > not what prevents the users from seeing other mounts in Thunar.
> > > 
> > > Even if xrdp created a thousand fiels and directories with random
> > > permissions somewhere in the home directory, this should not prevent
> > > Thunar or gvfs from finding other mount points, fiels or directories.
> > > 
> > > Please report to the Thunar or gvfs maintainers that Thunar or gvfs
> > > break on an unreadable, random directory/mount point in the user's home,
> > > because that is exactly what happens and causes the issues for your
> > > users.
> > I need to track down this in more detail tomorrow.
> 
> Yep. Independent of whether it turns out there is a bug in xrdp concerning 
> this directory, it is at least *also* a serious bug in gvfs or Thunar that 
> such a directory breaks it.

gvfs maintainers are now in the row.
 
> > > I would be glad, if, as DD, not as reporter, you could advice me on
> > > whether to keep this bug as a wishlist item („should not create a
> > > directory in $HOME) or close it as invalid, because creating any random
> > > directories is not supposed to have side effects and breakage exists in
> > > Thunar/gvfs.
> > 
> > Well, if upgrading a package renders a system partly unusable this is
> > per definition
> > 
> >   critical
> >makes unrelated software on the system (or the whole system) break,
> 
> Most certainly. But again, it is, above all, gvfs's fault to break because it 
> cannot read a directory. I see a million ways of using this for a DoS. There 
> are maybe two issues:
> 
>  1. xrdp might create an unreadable directory.
>  2. gvfs/Thunar breaks on an unreadable directory.
> 
> Number 1 is not proven to me yet, as I cannot reproduce it. I am very certain 
> that what you see is only true when running as root, and in that case, it is 
> correct as it is the expected behaviour of FUSE. Not a nice one, but 
> expected. 
> I believe that gvfs breaking is a side-effect of it crawling mount points as 
> root, through policykit.

No idea about this.
 
> Number 2 is in fact a critical bug, but not in

Bug#832102: transition: ftplib

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

On 22/07/16 12:12, Raphaël Hertzog wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hello,
> 
> I have small transition in the ftplib package, the SONAME got
> bumped but the API is fully backwards-compatible. The package
> is ready in experimental and I tested that the build of the 4 reverse
> dependencies still succeeds against the new library.
> 
> I took this opportunity to rename "ftplib-dev" into "libftp-dev",
> the latter providing the former so as to not break existing build
> dependencies. Similarly ftplib3 morphed into libftp4.
> 
> Let me know when I can upload to unstable.

Go ahead.

The provides is not enough while the old package is still available, as real
packages are preferred. We'll need to get the old -dev decrufted once ftplib is
built everywhere, so the new one is picked up. Then we can schedule the binNMUs.
Hmm, or probably some --extra-depends on the new package will suffice.

Cheers,
Emilio

Bug#831648: [Python-modules-team] Bug#831648: python-mkdocs: please make the build reproducible

[Brian May]

Hello,

Just to confirm: Does this fix the same problem as #824266?

If so, might be still worth applying the patch; upstream don't appear to
be in a hurry to make a new release.

Thanks for the patch.

Chris Lamb  writes:

> Source: python-mkdocs
> Version: 0.15.3-3
> Severity: wishlist
> Tags: patch
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: timestamps
> X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
>
> Whilst working on the "reproducible builds" effort [0], we noticed
> that python-mkdocs could not be built reproducibly.
-- 
Brian May 

Bug#832062: supertuxkart: source for GPL song Boom_boom_boom.ogg missing

[James Cowgill]

On Thu, 2016-07-21 at 22:59 +0200, Guus Sliepen wrote:
> Source: supertuxkart
> Version: 0.9.2-1
> Severity: serious
> Justification: does not include source code of GPL licensed work
> 
> Supertuxkart contains a song called "Boom boom boom" in Ogg Vorbis
> format. According to the credits and debian/copyright, this song is
> created by Matt Thomas, and is licensed under the GNU GPL v3 or
> later. The source of the .ogg file is missing. Although what consists
> the source of media assets can be unclear, I would like to point out
> that there is also a module tracker version of this song, which can
> reasonably considered the source, as it contains the score, the
> samples used and can be editted in any module editor:
> 
> https://modarchive.org/index.php?request=view_by_moduleid&query=38184

If this is the source then there is a more serious problem. The license
of modarchive modules prohibits modification, so the file would be non-
free for Debian anyway (even if the "source" was included).

https://modarchive.org/index.php?terms-upload
https://modarchive.org/index.php?faq-licensing

James

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

Bug#832055: Quick hack

[Turbo Fredriksson]

A quick hack to get it working was to change the

/usr/lib/python2.7/dist-packages/designatedashboard/__init__.py

as mentioned in the PKG-INF file:

--- /usr/lib/python2.7/dist-packages/designatedashboard/__init__.py~
2016-04-07 21:38:14.0 +0100
+++ /usr/lib/python2.7/dist-packages/designatedashboard/__init__.py 
2016-07-22 11:18:41.495043798 +0100
@@ -15,5 +15,6 @@
 import pbr.version


-__version__ = pbr.version.VersionInfo(
-'designatedashboard').version_string()
+#__version__ = pbr.version.VersionInfo(
+#'designatedashboard').version_string()
+__version__ = '1.0.1'

Bug#830102: sitesummary: autopkgtest failure

[Wolfgang Schweer]

On Thu, Jul 21, 2016 at 06:53:10PM -0400, Jeremy Bicha wrote:
> I then added -y to the two apt lines you posted for them to work, but
> the test still failed after that point:
 
[..]

> Apache/2.4.18 (Ubuntu) Server at localhost Port 80
> 
> '
> error: unable to submit to 
> 'http://localhost/cgi-bin/sitesummary-collector.cgi'
> /var/lib/sitesummary
> /var/lib/sitesummary/www
> /var/lib/sitesummary/www/index.html
> /var/lib/sitesummary/tmpstorage
> /var/lib/sitesummary/entries
> error: did not find entry

This seems to indicate that the directory /var/lib/sitesummary/entries 
is still empty (no ether-* subdirs, no data to submit).

IMO sitesummary-client didn't collect any information for some reason 
and the error message is sort of misleading.

Wolfgang


signature.asc
Description: Digital signature

Bug#820537: closed by Sylvestre Ledru (Bug#820537: fixed in llvm-toolchain-3.8 1:3.8.1-4)

[Mattia Rizzolo]

control: reopen -1

On Wed, Jul 20, 2016 at 04:12:08PM +, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the src:llvm-toolchain-3.8 package:
> 
> #820537: llvm-toolchain-3.8: FTBFS on mips and mipsel
> 
> It has been closed by Sylvestre Ledru .

>* Fix the FTBFS under mips/mipsel? (enable the link against atomic)
>  (Closes: #820537)

This was not enough, it still FTBFS on mips/mipsel/mips64el (which is a
release arch now and possibly you'd like to build there too).


-- 
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#831909: gstreamer coredumps when playing wavs since the libavcodec upgrade

[Faidon Liambotis]

On Fri, Jul 22, 2016 at 10:21:05AM +0200, Sebastian Ramacher wrote:
> Unfortunately I am unable to reproduce the issue. Since there are some 
> accounts
> of random crashes when building ffmpeg with tree vectorization enabled, I've
> uploaded 7:3.1.1-3 with vectorization disabled. Could you please check if the
> issue disappears with -3?

I upgraded all ffmpeg packages to 7:3.1.1-3 but I'm still experiencing
crashes.

I then installed libavcodec57-dbgsym, libgstreamer1.0-0-dbg,
gstreamer1.0-libav-dbg and gstreamer1.0-plugins-good-dbg. The full
backtrace is below. The "codec = " seems
relevant, since this is on an Intel Broadwell, which may not be the case
for you. This looks a lot like #831529, doesn't it?

I still don't exactly understand how H.264/VA-API are related when playing
just a .wav file, though... This was with the same gstreamer pipeline,
  gst-launch-1.0 filesrc location=/usr/share/sounds/purple/alert.wav  !
  wavparse ! audioconvert ! fakesink


#0  0x76fc01c8 in __GI_raise (sig=sig@entry=6)
at ../sysdeps/unix/sysv/linux/raise.c:54
#1  0x76fc164a in __GI_abort () at abort.c:89
#2  0x7fffeda6260b in init_context_defaults (s=s@entry=0x70095720, 
codec=codec@entry=0x7fffee3a8900 )
at src/libavcodec/options.c:142
#3  0x7fffeda626d6 in avcodec_alloc_context3 (codec=0x7fffee3a8900 
) at src/libavcodec/options.c:163
#4  0x7fffef360540 in gst_ffmpeg_cfg_install_property 
(klass=0x70095200, base=8) at gstavcfg.c:732
#5  0x7fffef356e53 in gst_ffmpegvidenc_class_init (klass=0x70095200)
at gstavvidenc.c:225
#6  0x7788c22d in g_type_class_ref (pclass=0x70094690, 
node=0x70094500) at 
/build/glib2.0-vjfO_h/glib2.0-2.48.1/./gobject/gtype.c:2241
#7  0x7788c22d in g_type_class_ref (type=type@entry=140737220527360)
at /build/glib2.0-vjfO_h/glib2.0-2.48.1/./gobject/gtype.c:2956
#8  0x77b09da4 in gst_element_register (plugin=plugin@entry=0x69bbf0 
[GstPlugin], name=name@entry=0x7006d110 "avenc_h264_vaapi", 
rank=rank@entry=128, type=type@entry=140737220527360) at gstelementfactory.c:243
#9  0x7fffef3575b3 in gst_ffmpegvidenc_register 
(plugin=plugin@entry=0x69bbf0 [GstPlugin]) at gstavvidenc.c:1009
#10 0x7fffef349e20 in plugin_init (plugin=0x69bbf0 [GstPlugin])
at gstav.c:158
#11 0x77b2b537 in gst_plugin_register_func (plugin=0x69bbf0 
[GstPlugin], desc=0x7fffef578180 , user_data=0x0) at 
gstplugin.c:523
#12 0x77b2d425 in _priv_gst_plugin_load_file_for_registry 
(filename=0x6c2e20 "/usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstlibav.so", 
registry=0x61c150 [GstRegistry], registry@entry=0x0, 
error=error@entry=0x74de7bf0)
at gstplugin.c:826
#13 0x77b2dcea in gst_plugin_load_file (filename=, 
error=error@entry=0x74de7bf0) at gstplugin.c:680
#14 0x77b2e12c in gst_plugin_load_by_name (name=0x6c218d "libav")
at gstplugin.c:1265
#15 0x77b2ea8d in gst_plugin_feature_load 
(feature=feature@entry=0x6e58a0 [GstTypeFindFactory]) at gstpluginfeature.c:111
#16 0x77b547e3 in gst_type_find_factory_call_function (factory=0x6e58a0 
[GstTypeFindFactory], find=0x74de7c90) at gsttypefindfactory.c:210
#17 0x75d89421 in gst_type_find_helper_for_data (obj=obj@entry=0x812070 
[GstWavParse], data=, size=, 
prob=prob@entry=0x74de7db4) at gsttypefindhelper.c:535
#18 0x75d895a4 in gst_type_find_helper_for_buffer 
(obj=obj@entry=0x812070 [GstWavParse], buf=buf@entry=0x70003450, 
prob=prob@entry=0x74de7db4)
at gsttypefindhelper.c:591
#19 0x75b3546a in gst_wavparse_add_src_pad (wav=wav@entry=0x812070 
[GstWavParse], buf=0x70003450) at gstwavparse.c:1908
#20 0x75b35b47 in gst_wavparse_stream_data (wav=wav@entry=0x812070 
[GstWavParse]) at gstwavparse.c:2061
#21 0x75b3bbb1 in gst_wavparse_loop (pad=0x8042a0 [GstPad])
at gstwavparse.c:2202
#22 0x77b4fe71 in gst_task_func (task=0x81c050 [GstTask])
at gsttask.c:332
#23 0x775bc55e in g_thread_pool_thread_proxy (data=) at 
/build/glib2.0-vjfO_h/glib2.0-2.48.1/./glib/gthreadpool.c:307
#24 0x775bbbc5 in g_thread_proxy (data=0x81a800) at 
/build/glib2.0-vjfO_h/glib2.0-2.48.1/./glib/gthread.c:780
#25 0x77335464 in start_thread (arg=0x74de8700) at 
pthread_create.c:333
#26 0x7707430d in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:109


Thanks,
Faidon

Bug#828652: [Python-modules-team] Bug#828652: Commited to Git

[Brian May]

Thomas Goirand  writes:

> The fix (ie: upgrading to 1.4.4) is pushed to git. Would you allow me to
> NMU what's in git?

The packaging changes look fine to me (django-nose). I suggest you join
the python-modules-team (if you are not already joined) and upload as a
normal team upload (not NMU).

Otherwise I can do the upload too if you want me to.
-- 
Brian May 

Bug#828499: Fixed in 7.1

[Pedretti Fabio]

https://bugs.php.net/bug.php?id=72360

Bug#832103: docker.io: Can't run images after upgrading to 1.11.2~ds1-6

[Sandro Knauß]

Package: docker.io
Version: 1.11.2~ds1-6
Severity: grave
Justification: renders package unusable

Hey,

after upgrading from 1.11.2~ds1-5 -> 1.11.2~ds1-6. I can't run any image.
It fails with:

$ docker run -it debian:sid
exec: "/bin/bash": stat /bin/bash: no such file or directory
docker: Error response from daemon: Container command not found or does
not exist..

downgrading to 1.11.2~ds1-5 and restart the daemon fixed the problem:

docker run -it debian:sid
root@686f2edff3f2:/# 

Regards,

sandro

-- System Information:
Debian Release: stretch/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages docker.io depends on:
ii  adduser  3.115
ii  containerd   0.2.1~ds1-2
ii  init-system-helpers  1.39
ii  iptables 1.6.0-2
ii  libapparmor1 2.10.95-4
ii  libc62.23-2
ii  libdevmapper1.02.1   2:1.02.130-1
ii  libsqlite3-0 3.13.0-1
ii  libsystemd0  230-7
ii  runc 0.1.1+dfsg1-1

Versions of packages docker.io recommends:
ii  ca-certificates  20160104
ii  cgroupfs-mount   1.3
ii  git  1:2.8.1-1
ii  xz-utils 5.1.1alpha+20120614-2.1

Versions of packages docker.io suggests:
pn  aufs-tools   
ii  btrfs-progs  4.5.2-1
ii  debootstrap  1.0.81
pn  lxc  
pn  rinse
pn  zfs-fuse | zfsutils  

-- no debconf information

Bug#832099: lintian: please check for unnecessary SOURCE_DATE_EPOCH assignments

[Mattia Rizzolo]

On Fri, Jul 22, 2016 at 11:55:46AM +0200, Chris Lamb wrote:
> Attached is the following:
> 
>   commit 3b10f7dbaecedb0a458c25cc0b8615b489d424af
>   Author: Chris Lamb 
>   Date:   Fri Jul 22 10:54:02 2016 +0100
>   
>   c/rules: Check for unnecessary SOURCE_DATE_EPOCH assignments
>   
>   As of dpkg 1.18.8, this is no longer necessary as dpkg exports this
>   variable if it is not already set (#75). This should encourage
>   removing some duplicated code from a lot of our rules files.

though, using dpkg-buildpackage is not mandatory, a package should be
able to build with just `debian/rules binary`.  In such case SDE
wouldn't be exported.

This looks fairly similar to e.g. DEB_HOST_ARCH & friends variables,
that even if they are exported by dpkg-buildpackage you should set them
in d/rules nonetheless.

At least, that's what my AM told me back then ^^

-- 
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#832104: [sparc64] Program received signal SIGBUS, Bus error.

[Mathieu Malaterre]

Package: src:tbb
Version: 4.3~20150611-2

tbb test suite currently fails on sparc64:

https://buildd.debian.org/status/fetch.php?pkg=tbb&arch=sparc64&ver=4.3~20150611-2&stamp=1468511222

./test_malloc_pools.exe  1:4
../../build/Makefile.tbbmalloc:212: recipe for target
'malloc_test_no_depends' failed
make[2]: *** [malloc_test_no_depends] Bus error
make[2]: Leaving directory
'/<>/build/linux_sparc64_gcc_cc5.4.0_libc2.23_kernel4.6.0_debug'
Makefile:44: recipe for target 'test' failed
make[1]: *** [test] Error 2
make[1]: Leaving directory '/<>'
dh_auto_test: make -j1 test returned exit code 2
debian/rules:12: recipe for target 'build-arch' failed
make: *** [build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2

Bug#804622: -x auth_info is a required parameter, at least with SQL

[martin f krafft]

also sprach Timo Sirainen  [2016-07-22 09:51 +0200]:
>pgsql: Query failed, aborting: SELECT p.userid, p.password, u.uid AS 
> userdb_uid, u.gid AS userdb_gid, u.home AS userdb_home, u.mail AS userdb_mail 
> FROM dovecotpassword('test','pantsfullofunix.net') p, dovecotuser('test', 
> 'pantsfullofunix.net') u WHERE doveadm
> 
> So here it means that the passdb_query has something like "...
> WHERE %s". The %s expands to the service name, which could be any
> of imap, pop3, lmtp, doveadm, sieve, and several others. In this
> database apparently there are "imap" and "pop3" fields in the
> database but not "doveadm" and maybe not the others. When using
> "doveadm auth" without explicitly specifying the service name, it
> also defaults to "doveadm".

Thanks for the explanation. Just one question: does it make sense to
default to doveadm in this case? It's not really a service, or is
it? Wouldn't it be better to make the service parameter required, or
use a 'true' (tautological) default?

-- 
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#832104: more info

[Mathieu Malaterre]

user debian-sp...@lists.debian.org
usertag 822583 sparc64
thanks

Here is what I see on notker.d.n:

% cd build/linux_sparc64_gcc_cc5.4.0_libc2.23_kernel4.6.0_debug
% export LD_LIBRARY_PATH=.
% gdb ./test_malloc_pools.exe
GNU gdb (Debian 7.11.1-2) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "sparc64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./test_malloc_pools.exe...done.
(gdb) r
Starting program:
/home/malat/tbb-4.3~20150611/build/linux_sparc64_gcc_cc5.4.0_libc2.23_kernel4.6.0_debug/test_malloc_pools.exe
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/sparc64-linux-gnu/libthread_db.so.1".

Program received signal SIGBUS, Bus error.
rml::internal::Backend::addNewRegion (this=0x800100e74150,
size=size@entry=2097152,
memRegType=memRegType@entry=rml::internal::MEMREG_FLEXIBLE_SIZE,
addToBin=addToBin@entry=true) at ../../src/tbbmalloc/backend.cpp:1318
1318region->allocSz = rawSize;
(gdb) bt full
#0  rml::internal::Backend::addNewRegion (this=0x800100e74150,
size=size@entry=2097152,
memRegType=memRegType@entry=rml::internal::MEMREG_FLEXIBLE_SIZE,
addToBin=addToBin@entry=true) at ../../src/tbbmalloc/backend.cpp:1318
requestSize = 2097152
rawSize = 2097152
region = 0x800101074021
fBlock = 
#1  0x80010012d2d4 in rml::internal::Backend::bootstrap
(this=, extMemoryPool=0x800100e74150) at
../../src/tbbmalloc/backend.cpp:1336
No locals.
#2  0x800100132198 in rml::internal::ExtMemoryPool::init
(this=0x800100e74140, this@entry=0x800100e74150,
poolId=poolId@entry=0, rawAlloc=0x7fef008,
rawFree=0x800100e74140, granularity=18446603340526324080,
keepAllMemory=, fixedPool=false) at
../../src/tbbmalloc/frontend.cpp:1084
No locals.
#3  0x8001001321e0 in rml::internal::MemoryPool::init
(this=0x800100e74140, poolId=0, policy=0x7fef008) at
../../src/tbbmalloc/frontend.cpp:1091
No locals.
#4  0x800100137bec in rml::pool_create_v1
(pool_id=pool_id@entry=0, policy=policy@entry=0x7fef008,
pool=pool@entry=0x7fef000)
at ../../src/tbbmalloc/frontend.cpp:2635
memPool = 0x800100e74140
pool = 0x7fef000
policy = 0x7fef008
pool_id = 0
#5  0x00102a60 in TestPoolReset () at
../../src/test/test_malloc_pools.cpp:95
pol = {pAlloc = 0x102438 ,
pFree = 0x10275c , granularity
= 0, version = 1, fixedPool = 0,
  keepAllMemory = 0, reserved = 0}
pool = 0x0
regionsBeforeReset = 
#6  0x00104214 in TestMain () at
../../src/test/test_malloc_pools.cpp:532
No locals.
#7  0x00101e80 in main (argc=,
argv=0x7fef528) at ../../src/test/harness.h:391
res = 2
__FUNCTION__ = "main"
(gdb)

Bug#832102: transition: ftplib

[Raphael Hertzog]

On Fri, 22 Jul 2016, Emilio Pozuelo Monfort wrote:
> Go ahead.

Uploaded (4.0-1-2).

> The provides is not enough while the old package is still available, as real
> packages are preferred. We'll need to get the old -dev decrufted once ftplib 
> is
> built everywhere, so the new one is picked up. Then we can schedule the 
> binNMUs.
> Hmm, or probably some --extra-depends on the new package will suffice.

I also had to build a fake ftplib-dev for my test rebuilds to pick up the
new package. I filed #832050 on sbuild due to this.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Bug#832105: subversion: svn is unusable when there are filenames it cannot understand in the working directory

[Vincent Lefevre]

Package: subversion
Version: 1.9.4-1
Severity: important
Tags: upstream

svn is unusable when there are filenames it cannot understand.
For instance, in the C locale:

$ svn st
svn: E22: Error converting entry in directory 
'/home/vlefevre/software/mpfr/tests' to UTF-8
svn: E22: Can't convert string from native encoding to 'UTF-8':
svn: E22:?\E0P@@
W

The user (or some arbitrary tool) should be free to add any
unversioned filename to the working directory, and this should
not have an effect on svn, which should just regard the file as
unversioned.

The only current solution for the user is to remove these files
one by one, which is not easy to do since svn (which is unusable)
can't even give a list of such files. Switching to UTF-8 doesn't
solve the problem if there are invalid UTF-8 sequences, e.g. due
to bug 816313.

Note 1: If the system allows one to create such files, the user
should not be blamed for that! This is a matter of consistency
between the different components of the system.

Note 2: If the goal of the error is to detect that the current
charset is different from the charset used at checkout time, this
is not the correct way to do this detection (a correct solution
would be to record the charset used at checkout time somewhere in
the .svn directory). And this cannot even be disabled.

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

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

Versions of packages subversion depends on:
ii  libapr11.5.2-4
ii  libaprutil11.5.4-2
ii  libc6  2.23-2
ii  libldap-2.4-2  2.4.42+dfsg-2+b2
ii  libsasl2-2 2.1.26.dfsg1-15
ii  libsvn11.9.4-1

subversion recommends no packages.

Versions of packages subversion suggests:
pn  db5.3-util
ii  patch 2.7.5-1
ii  subversion-tools  1.9.4-1

-- no debconf information

Bug#832106: ITP: ruby-vmstat -- gather memory, cpu, network, load avg and disk information

[Pirate Praveen]

package: wnpp
severity: wishlist
owner: Pirate Praveen 

from https://rubygems.org/gems/vmstat









signature.asc
Description: OpenPGP digital signature

Bug#832057: PATCH

[Turbo Fredriksson]

Looking at the source package, the file(s) is indeed
there:

root@sid64:/usr/local/src/Openstack/manila-ui-2.1.0# find -name index.html
./manila_ui/dashboards/project/shares/templates/shares/index.html
./manila_ui/dashboards/admin/shares/templates/shares/index.html

However, both of the "templates" directories are missing from the
package.


The correct (?) fix seems to create a MANIFEST.in with the following content:

  recursive-include manila_ui *.html *.scss *.js

Bug#832107: ghc: please stop build-depending on llvm-3.5

[Mattia Rizzolo]

source: ghc
version: 7.10.3-1
severity: important
control: block -1 by 812778
control: fixed -1 8.0.0.20160111-2

We'd like to drop old LLVMs, but ghc still uses llvm-3.5, which the
maintainer already flagged for RM (see #812778).

ghc is currently the very last blocker for llvm-3.5 removal.

I understood ghc 8 builds with llvm 3.7, so possibly the best course of
action is to get to a point where ghc 8 can go to unstable, sooner
rather than later please…

BTW, there will be a migration from llvm 3.7 to 3.8 before stretch, so
it'd be good to check whether ghc8 can build and be nice with 3.8.

-- 
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#832108: ITP: android-platform-frameworks-data-binding -- Data Binding Library for Android

[殷啟聰]

Package: wnpp
Severity: wishlist

* Package name: android-platform-frameworks-data-binding
  Version : 2.0.0-1
* Upstream Author : The Android Open Source Project
* License : Apache-2.0
* Programming lang: Java
* Description : Data Binding Library
* URL :
https://android.googlesource.com/platform/frameworks/data-binding
* Alioth  :
https://anonscm.debian.org/cgit/android-tools/android-platform-frameworks-data-binding.git

The Data Binding Library enables Android application developers to write
declarative layouts and minimize the glue code necessary to bind application
logic and layouts.

This packages intends to provide Android libraries (AARs) of Data Binding
Library for Android, however it building AARs needs the Android Plugin for
Gradle, which is being packaged at the time. Building the Android Plugin for
Gradle also needs a Java library in this package, hence at the time
src:android-platform-frameworks-data-binding only provides the Java library used
to build the Android Plugin for Gradle.

Bug#831909: gstreamer coredumps when playing wavs since the libavcodec upgrade

[Sebastian Dröge]

On Fri, 22 Jul 2016 13:27:09 +0300 Faidon Liambotis  wrote:

> I still don't exactly understand how H.264/VA-API are related when playing
> just a .wav file, though...

They are not, it's just that the initialization of this GStreamer
plugin (the ffmpeg/libav one) is going through all the codecs that are
provided and remembers what is available.

> #0  0x76fc01c8 in __GI_raise (sig=sig@entry=6)
> at ../sysdeps/unix/sysv/linux/raise.c:54
> #1  0x76fc164a in __GI_abort () at abort.c:89
> #2  0x7fffeda6260b in init_context_defaults (s=s@entry=0x70095720, 
> codec=codec@entry=0x7fffee3a8900 )
> at src/libavcodec/options.c:142

All the hardware based ffmpeg codecs should be disabled in gst-libav
though. It of course still shouldn't crash like this, which seems like
a problem in ffmpeg, but I'll fix gst-libav to ignore them all now.

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

Bug#829272: Missing accessors

[msa...@nikhef.nl via RT]

On Fri, Jul 22, 2016 at 09:38:13AM +0200, Mattias Ellert wrote:
> tor 2016-07-21 klockan 09:51 + skrev Richard Levitte via RT:
> > On Thu Jul 21 08:18:30 2016, mattias.ell...@physics.uu.se wrote:
> > > 
> > > ons 2016-07-20 klockan 15:14 + skrev Richard Levitte via RT:
> > > > 
> > > > On Mon Jul 11 11:34:35 2016, mattias.ell...@physics.uu.se wrote:
> > > > > 
> > > > > 
> > > > > I guess having a more restrictive accessor that only sets the
> > > > > EXFLAG_PROXY bit could work. I suggested the more general
> > > > > solution
> > > > > of
> > > > > having set/clear accessors for arbitrary flags since it was -
> > > > > well
> > > > > more
> > > > > general.
> > > > 
> > > > So let me ask this in a different manner, does OpenSSL 1.1 still
> > > > not
> > > > set the
> > > > EXFLAG_PROXY flag correctly? In what situations does that happen?
> > > > That may be
> > > > worth a bug report of its own.
> > > > 
> > > > --
> > > > Richard Levitte
> > > > levi...@openssl.org
> > > > 
> > > 
> > > The answer to this is related to Mischa's reply, which
> > > unfortunately
> > > was only sent to the Debian BTS and not the the OpenSSL RT. I quote
> > > it
> > > below. As indicated in the answer, setting the EXFLAG_PROXY allows
> > > handling non-RFC proxies in OpenSSL.
> > > 
> > > mån 2016-07-11 klockan 14:53 +0200 skrev Mischa Salle:
> > > > 
> > > > Hi Richard, Mattias, others,
> > > > 
> > > > I agree with you that it would be nice if OpenSSL could figure
> > > > out
> > > > itself whether a cert needs to be treated as a proxy, but
> > > > currently
> > > > that
> > > > doesn't work reliably as far as I know.
> > > > The flag is certainly needed in the case of non-RFC3820 proxies,
> > > > also
> > > > known as legacy proxies. Unfortunately these are still very
> > > > widely
> > > > used
> > > > (majority of the proxies actually) and hence our code must be
> > > > able to
> > > > handle them correctly.
> > > > 
> > > > Best wishes,
> > > > Mischa Sallé
> > > > 
> > 
> > Ok... From looking at the voms code that was linked to earlier, I can
> > see that
> > legacy proxy certs are recognised by an older OID (called
> > PROXYCERTINFO_V3 in
> > the code), 1.3.6.1.4.1.3536.1.222. Is there a spec for the extensions
> > in that
> > version, whether they are critical or not and so on, that I can
> > reach? Or is
> > the OID the only actual difference? If it's easy enough (and it
> > currently does
> > look quite easy), I can certainly see adding some code in OpenSSL to
> > recognise
> > those...
> > 
> > --
> > Richard Levitte
> > levi...@openssl.org
> 
> As far as I know there are three different kinds of proxies, usually
> called "legacy", "draft" and "rfc", or sometimes version 2, 3 and 4
> respectively.
> 
> For example see "grid-proxy-init -help":
> 
>     -draftCreates a draft (GSI-3) proxy
> -old  Creates a legacy globus proxy
> -rfc  Creates a RFC 3820 compliant proxy
> 
> The really tricky one is the old legacy version 2 proxy I think.

Hi,

there are 3 types of proxies, in chronological order:

- so called legacy proxies, which voms-proxy-init will call old and are
  also known as GT2 proxies.
  They have no special (critical) extension and can be recognized by:
1) being signed by an end-entity cert (i.e. a non-CA)
2) have the same subjectDN as the issuer with one extra CN RDN
   added, which can be either
a) "CN=proxy" for a 'inherit all' proxy
b) "CN=limited proxy" for a limited proxy (as in OID
   1.3.6.1.4.1.3536.1.1.1.9)
  These are widely used and we have therefore code in many places to
  handle them.

- the draft RFC proxies, also known as GT3 proxies.
  They contain an extension 1.3.6.1.4.1.3536.1.222
  At least voms-proxy-init does not mark it as critical. They are
  rarely used. The ordering in the extension is different in the sense
  that they usually put the proxyPolicy before the proxyPathlength (when
  finite, i.e. present) inside the extension, but RFC-style extensions
  also occur. In openssl.cnf style a GT3 extension would be something
  like this:
[ gt3_proxy ]
keyUsage = critical,digitalSignature,keyEncipherment
1.3.6.1.4.1.3536.1.222=critical,ASN1:SEQUENCE:gt3_seq_sect

# For a proxy pathlength of 42, leave out field2 for inf.
[ gt3_seq_sect ]
field1 = SEQUENCE:normal_policy
field2 = EXPLICIT:1C,INTEGER:42

# similarly for limited policy
[ normal_policy ]
p1 = OID:1.3.6.1.5.5.7.21.1

- RFC3820 compliant proxies, also known as GT4 proxies.
  They contain the standard critical extension 1.3.6.1.5.5.7.1.14

The default for at least voms-proxy-init (both from the voms-clients2
and voms-clients3) is to make the GT2 proxies, and this is why they are
still very-widely used (I think vast majority of proxies).

Mischa
-- 
Nikhef  Room  H155
Science Park 105Tel.  +31-20-592 5102
1098 XG Amsterdam   Fax   +31-

Bug#618530: NICE DAY,

[engela]

NICE DAY,

 My name is Miss Angela, I pray that this letter meets you well,though we
never meet or seen each other before, but I believe that nature has a way
of bringing people together for specific purposes.If you need a friend
Email me back,

Bug#832109: add postfix config and command line option

[Marvin Renich]

Package: milter-greylist
Version: 4.5.11-1
Severity: wishlist
Tags: patch

Please add a runtime option to select behavior appropriate for Postfix.
I believe this should replace the USE_POSTFIX macro, but the attached
patches do not remove this macro (or associated configure option).

My rational is that, while a compile-time option might be appropriate
for software that is compiled by the end user, who is likely to only be
using one MTA, or for a distribution like Gentoo that compiles software
at install-time, the binary package distributed by Debian is likely to
be used with both Postfix and Exim, and perhaps other MTAs.

The included patches add a "-x" command-line option and corresponding
config file option "postfix" to enable Postfix-specific behavior.  This
option currently only suppresses one warning.

The suppressed warning (which the --enable-postfix configure option and
corresponding USE_POSTFIX macro currently remove at compile time), is
completely useless in a Postfix environment, but is emitted once for
each message processed by milter-greylist.  This just clutters the log
files.

I envision this option being used to enable other Postfix-specific
behavior in the future, if such behavior is identified.

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

Kernel: Linux 4.6.0-1-amd64 (SMP w/8 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: sysvinit (via /sbin/init)
Index: milter-greylist-4.5.11/milter-greylist.c
===
--- milter-greylist-4.5.11.orig/milter-greylist.c
+++ milter-greylist-4.5.11/milter-greylist.c
@@ -515,7 +515,9 @@ real_envfrom(ctx, envfrom)
 		 * until after it accepts the first valid RCPT TO 
 		 * command, so don't log the failure 
 		 */
-		mg_log(LOG_DEBUG, "smfi_getsymval failed for {i}");
+		if (conf.c_postfix == 0) {
+			mg_log(LOG_DEBUG, "smfi_getsymval failed for {i}");
+		}
 #endif
 		priv->priv_queueid = "(unknown id)";
 	}
@@ -1605,7 +1607,7 @@ main(argc, argv)
 	/* 
 	 * Process command line options 
 	 */
-	while ((ch = getopt(argc, argv, "Aa:cvDd:qw:f:hp:P:Tu:rSL:M:l")) != -1) {
+	while ((ch = getopt(argc, argv, "Aa:cvDd:qw:f:hp:P:Tu:rSL:M:lx")) != -1) {
 		switch (ch) {
 		case 'A':
 			defconf.c_noauth = 1;
@@ -1799,6 +1801,11 @@ main(argc, argv)
 			defconf.c_forced |= C_ACLDEBUG;
 			break;
 
+		case 'x':
+			defconf.c_postfix = 1;
+			defconf.c_forced |= C_POSTFIX;
+			break;
+
 		case 'h':
 		default:
 			usage(argv[0]);
@@ -3251,7 +3258,7 @@ fstring_expand(priv, rcpt, fstring, cv)
 fqdn = host;
 			}
 
-			snprintf(output, HDRLEN, 
+			snprintf(output, HDRLEN,
  "milter-greylist-%s (%s [%s]); %s %s (%s)",
 			 PACKAGE_VERSION, fqdn, local_ipstr(priv),
  timestr, tzstr, tznamestr);
Index: milter-greylist-4.5.11/conf.c
===
--- milter-greylist-4.5.11.orig/conf.c
+++ milter-greylist-4.5.11/conf.c
@@ -493,5 +493,6 @@ conf_defaults(c)
 	c->c_syncmaxqlen = SYNC_MAXQLEN;
 	(void)memset(&c->c_localaddr, 0, sizeof(c->c_localaddr));
 	(void)memset(&c->c_localaddr_string, 0, sizeof(c->c_localaddr_string));
+	c->c_postfix = 0;
 	return;
 }
Index: milter-greylist-4.5.11/conf.h
===
--- milter-greylist-4.5.11.orig/conf.h
+++ milter-greylist-4.5.11/conf.h
@@ -123,6 +123,7 @@ struct conf_rec {
 	struct sockaddr_storage c_localaddr;
 	char c_localaddr_string[IPADDRSTRLEN];
 	int c_fixldapcheck;
+	int c_postfix;
 };
 
 /* c_forced flags */
@@ -146,6 +147,7 @@ struct conf_rec {
 #define C_DOMAINEXACT	0x1
 #define C_TARPIT	0x2
 #define C_TARPIT_SCOPE	0x4
+#define C_POSTFIX	0x8
 #define C_NOTFORCED(x) 	((conf.c_forced & (x)) == 0) 
 
 /* c_report */
Index: milter-greylist-4.5.11/conf_lex.l
===
--- milter-greylist-4.5.11.orig/conf_lex.l
+++ milter-greylist-4.5.11/conf_lex.l
@@ -143,6 +143,7 @@ log_local6	[Ll][Oo][Cc][Aa][Ll]6
 log_local7	[Ll][Oo][Cc][Aa][Ll]7
 p0fsock		[Pp]0[Ff][Ss][Oo][Cc][Kk]
 p0f		[Pp]0[Ff]
+postfix		[Pp][Oo][Ss][Tt][Ff][Ii][Xx]
 spamdsock	[Ss][Pp][Aa][Mm][Dd][Ss][Oo][Cc][Kk]
 spamdsockt	[Ii][Nn][Ee][Tt]|[Uu][Nn][Ii][Xx]
 spamd		[Ss][Pp][Aa][Mm][Dd]
@@ -314,6 +315,7 @@ type		[Tt][Yy][Pp][Ee]
 {domatch}	{ return DOMATCH; }
 {p0fsock}	{ return P0FSOCK; }
 {p0f}		{ BEGIN(S_REGEX); return P0F; }
+{postfix}	{ return POSTFIX; }
 {spamdsock}	{ return SPAMDSOCK; }
 {spamdsockt}	{ 
 			strncpy(yylval.spamdsockt, yytext, QSTRLEN);
Index: milter-greylist-4.5.11/conf_yacc.y
===
--- milter-greylist-4.5.11.orig/conf_yacc.y
+++ milter-greylist-4.5.11/conf_yacc.y
@@ -13,7 +13,7 @@
 %token LOGFAC_MAIL LOGFAC_DAEMON LOGFAC_A

Bug#831648: [Python-modules-team] Bug#831648: python-mkdocs: please make the build reproducible

[Chris Lamb]

> Just to confirm: Does this fix the same problem as #824266?

I believe so, yes. I didn't spot that wishlist bug as it didn't
have a patch.

> If so, might be still worth applying the patch; upstream don't appear to
> be in a hurry to make a new release.

Indeed; please do this as it would make a number of reverse
build-dependencies immediately reproducible. :)


Regards,

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

Bug#832096: lintian: please check for common typos in debian/rules target names

[Chris Lamb]

Jakub Wilk wrote:

> Lintian is already aware of existing dh_* commands (see 
> data/debhelper/dh_commands), so maybe we could use this list instead of 
> manually maintaining possible misspellings?

Not without changing this data structure as we want multiple misspellings
to map to the correct spelling. A clever regex is also not suitable either
as there are some dh_ commands that *do* have an underscore as a separator.

> [..]

Well, all those typos in my patch were ironically embarrassing
given what its meant to solve. :)

Updated patch attached.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
From 213ec736850d0c706264d6a482dad14f8172be89 Mon Sep 17 00:00:00 2001
From: Chris Lamb 
Date: Fri, 22 Jul 2016 12:43:30 +0100
Subject: [PATCH] c/rules: Check for common typos in debian/rules target names.

Misspelling a target (eg. "override_dh_install_debconf") results in that
rule silently not being called. See #831772 for an example in the wild.

Signed-off-by: Chris Lamb 
---
 checks/rules.desc |  7 +++
 checks/rules.pm   |  4 
 data/rules/target-typos   | 31 +++
 t/tests/rules-general/debian/debian/rules |  2 ++
 t/tests/rules-general/desc|  3 ++-
 t/tests/rules-general/tags|  1 +
 6 files changed, 47 insertions(+), 1 deletion(-)
 create mode 100644 data/rules/target-typos

diff --git a/checks/rules.desc b/checks/rules.desc
index 25c565b..3f4f738 100644
--- a/checks/rules.desc
+++ b/checks/rules.desc
@@ -248,3 +248,10 @@ Info: The source package does not have both a build-arch and a build-indep
  .
  Please consider adding both the build-arch and build-indep targets.
 
+Tag: typo-in-debian-rules-target
+Severity: normal
+Certainty: certain
+Info: The listed target in debian/rules command is a misspelling.
+ .
+ This can result in (for example) a dh_override_-style target
+ silently not being executed by make.
diff --git a/checks/rules.pm b/checks/rules.pm
index bd3a141..1100032 100644
--- a/checks/rules.pm
+++ b/checks/rules.pm
@@ -38,6 +38,7 @@ our $ANYPYTHON_DEPEND
 my $KNOWN_MAKEFILES = Lintian::Data->new('rules/known-makefiles', '\|\|');
 my $DEPRECATED_MAKEFILES = Lintian::Data->new('rules/deprecated-makefiles');
 my $POLICYRULES = Lintian::Data->new('rules/policy-rules', qr/\s++/);
+my $TARGETTYPOS = Lintian::Data->new('rules/target-typos', qr/\s++/);
 
 # forbidden construct in rules
 my $BAD_CONSTRUCT_IN_RULES
@@ -313,6 +314,9 @@ sub run {
 if (any { $target =~ /$_/ } @arch_rules) {
 push(@arch_rules, @depends);
 }
+tag 'typo-in-debian-rules-target', $target, '->',
+$TARGETTYPOS->value($target), "(line $.)"
+if ($TARGETTYPOS->known($target));
 }
 undef %debhelper_group;
 } elsif (/^define /) {
diff --git a/data/rules/target-typos b/data/rules/target-typos
new file mode 100644
index 000..e7da585
--- /dev/null
+++ b/data/rules/target-typos
@@ -0,0 +1,31 @@
+# a list of common incorrect targets in debian/rules
+# format is
+#
+#
+override_dh_autotest			override_dh_auto_test
+override_dh_install_catalogs		override_dh_installcatalogs
+override_dh_install_changelog		override_dh_installchangelogs
+override_dh_install_cron		override_dh_installcron
+override_dh_install_deb			override_dh_installdeb
+override_dh_install_debconf		override_dh_installdebconf
+override_dh_install_dirs		override_dh_installdirs
+override_dh_install_docs		override_dh_installdocs
+override_dh_install_emacsen		override_dh_installemacsen
+override_dh_install_example		override_dh_installexamples
+override_dh_install_examples		override_dh_installexamples
+override_dh_install_info		override_dh_installinfo
+override_dh_install_init		override_dh_installinit
+override_dh_install_logcheck		override_dh_installlogcheck
+override_dh_install_logrotate		override_dh_installlogrotate
+override_dh_install_man			override_dh_installman
+override_dh_install_manpage		override_dh_installmanpages
+override_dh_install_manpages		override_dh_installmanpages
+override_dh_install_mans		override_dh_installman
+override_dh_install_menu		override_dh_installmenu
+override_dh_install_mime		override_dh_installmime
+override_dh_install_modules		override_dh_installmodules
+override_dh_install_pam			override_dh_installpam
+override_dh_install_udev		override_dh_installudev
+override_dh_install_xmlcatalogs		override_dh_installxmlcatalogs
+override_dh_installmanpage		override_dh_installman
+override_dh_usr_local			override_dh_usrlocal
diff --git a/t/tests/rules-general/debian/debian/rules b/t/tests/rules-general/debian/debian/rules
index cddbc03..2febda6 100755
--- a/t/tests/rules-general/debian/debian/rules
+++ b/t/tests/rules-general/debian/debian/rules
@@ -9,3 +9,5 @@ clean:
 	dh_clean
 	echo $(DEB_BUILD_OPTS) $(PWD)
 	@ech

Bug#832110: libjs-c3: c3.css missing from install

[Mathias Behrle]

Package: libjs-c3
Version: 0.4.11+dfsg-1
Severity: important

Hi Laszlo,

thanks for packaging c3.

c3.css (also existant in the debian directory of the source tarball, so
probably regenerated?) is not installed into the binary.

Cheers,
Mathias

BTW: Would you mind to push to some publicly available repos, best
perhaps in pkg-javascript and add some VCS fields?


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

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

Versions of packages libjs-c3 depends on:
ii  libjs-d3  3.5.17-1

libjs-c3 recommends no packages.

libjs-c3 suggests no packages.

-- no debconf information

Bug#830740: mrpt: FTBFS on hppa: parse_NMEA_RMC assertion failure

[Gianfranco Costamagna]

Hi sad mips,

/«PKGBUILDDIR»/libs/base/include/mrpt/utils/CStream.h:103:73: error: no 
matching function for call to 'reverseBytesInPlace(long unsigned int&)'
for (size_t i=0;i
void BASE_IMPEXP reverseBytesInPlace(bool& v_in_out);
^
/«PKGBUILDDIR»/libs/base/include/mrpt/utils/bits.h:129:20: note:   conversion 
of argument 1 would be ill-formed:
In file included from /«PKGBUILDDIR»/libs/maps/src/maps-precomp.h:14:0,
from /«PKGBUILDDIR»/libs/maps/src/maps/CColouredPointsMap.cpp:10:
/«PKGBUILDDIR»/libs/base/include/mrpt/utils/CStream.h:103:77: error: invalid 
initialization of non-const reference of type 'bool&' from an rvalue of type 
'bool'
for (size_t i=0;i
void BASE_IMPEXP reverseBytesInPlace(uint8_t& v_in_out);
^
/«PKGBUILDDIR»/libs/base/include/mrpt/utils/bits.h:130:20: note:   conversion 
of argument 1 would be ill-formed:
In file included from /«PKGBUILDDIR»/libs/maps/src/maps-precomp.h:14:0,
from /«PKGBUILDDIR»/libs/maps/src/maps/CColouredPointsMap.cpp:10:
/«PKGBUILDDIR»/libs/base/include/mrpt/utils/CStream.h:103:77: error: invalid 
initialization of non-const reference of type 'uint8_t& {aka unsigned char&}' 
from an rvalue of type 'uint8_t {aka unsigned char}'
for (size_t i=0;i
void BASE_IMPEXP reverseBytesInPlace(int8_t& v_in_out);
^
/«PKGBUILDDIR»/libs/base/include/mrpt/utils/bits.h:131:20: note:   conversion 
of argument 1 would be ill-formed:
In file included from /«PKGBUILDDIR»/libs/maps/src/maps-precomp.h:14:0,
from /«PKGBUILDDIR»/libs/maps/src/maps/CColouredPointsMap.cpp:10:
/«PKGBUILDDIR»/libs/base/include/mrpt/utils/CStream.h:103:77: error: invalid 
initialization of non-const reference of type 'int8_t& {aka signed char&}' from 
an rvalue of type 'int8_t {aka signed char}'
for (size_t i=0;i
void BASE_IMPEXP reverseBytesInPlace(uint16_t& v_in_out);
^
/«PKGBUILDDIR»/libs/base/include/mrpt/utils/bits.h:132:20: note:   conversion 
of argument 1 would be ill-formed:
In file included from /«PKGBUILDDIR»/libs/maps/src/maps-precomp.h:14:0,
from /«PKGBUILDDIR»/libs/maps/src/maps/CColouredPointsMap.cpp:10:
/«PKGBUILDDIR»/libs/base/include/mrpt/utils/CStream.h:103:77: error: invalid 
initialization of non-const reference of type 'uint16_t& {aka short unsigned 
int&}' from an rvalue of type 'uint16_t {aka short unsigned int}'
for (size_t i=0;i
void BASE_IMPEXP reverseBytesInPlace(int16_t& v_in_out);
^
/«PKGBUILDDIR»/libs/base/include/mrpt/utils/bits.h:133:20: note:   conversion 
of argument 1 would be ill-formed:
In file included from /«PKGBUILDDIR»/libs/maps/src/maps-precomp.h:14:0,
from /«PKGBUILDDIR»/libs/maps/src/maps/CColouredPointsMap.cpp:10:
/«PKGBUILDDIR»/libs/base/include/mrpt/utils/CStream.h:103:77: error: invalid 
initialization of non-const reference of type 'int16_t& {aka short int&}' from 
an rvalue of type 'int16_t {aka short int}'
for (size_t i=0;ihttps://buildd.debian.org/status/package.php?p=mrpt&suite=unstable

G.





Il Venerdì 22 Luglio 2016 10:32, Gianfranco Costamagna 
 ha scritto:
Hi,



>fat finger typo!  ;-)


:)
>https://mentors.debian.net/debian/pool/main/m/mrpt/mrpt_1.4.0-4.dsc
>
>I included the potential fix to the other HPPA bug... hopefully it'll
>work at the first attempt!


you will know in a few hours, the package is uploaded, it will go in
unstable at the end of dinstall
https://ftp-master.debian.org/dinstall.status
https://ftp-master.debian.org/dinstall.html
>Thanks for everything guys!


you are welcome, lets hope for the best!
(and for hppa, if it doesn't fix, just reopen the bug and don't care,
we don't have porter machines, so porters have to look at the issue, I can't)


Gianfranco

Bug#777382: O: dogtail

[Michael Prokop]

Cc-ing intrigeri from Tails project

* Alessio Treglia [Sat Feb 07, 2015 at 08:29:14PM +]:

> Due to the lack of time and interest, I ask for someone
> else to maintain dogtail.

> The packaging is in good shape and upstream is active
> and responsive.

I just took care of the upload of a new upstream version of dogtail.
(We started using dogtail for automated testing but ran into too many
issues back then, so we need to re-evaluate current state, if it
turns out to be useful for us then I'd be happy to assist in package
maintance.)

@intrigeri: IIRC Tails uses dogtail too, so maybe you're interested
in helping the dogtail maintence? :)

FTR: upstream added python3 support, so it might be interesting to
switch the packaging from binary package python-dogtail into
dogtail, python-dogtail + python3-dogtail?

regards,
-mika-


signature.asc
Description: Digital signature

Bug#832111: Please add a fake "status" function to init script (like in procps)

[Raphaël Halimi]

Package: sysfsutils
Version: 2.1.0+repack-4
Severity: wishlist
Tags: patch

Hi,

sysfsutils' init script lacks a "status" function. This disturbs some
third-party software (in my case, saltstack) which interpret it as an
error and think that the "service" is not running.

procps implemented a fake "status" function in its init script to
address this; please do the same for sysfsutils.

Attached is a very small patch doing just that.

Regards,

-- 
Raphaël Halimi
diff --git a/debian/sysfsutils.init b/debian/sysfsutils.init
index b0610ed..21bf713 100644
--- a/debian/sysfsutils.init
+++ b/debian/sysfsutils.init
@@ -73,8 +73,10 @@ case "$1" in
 	;;
 stop)
 	;;
+status)
+	;;
 *)
-	echo "Usage: /etc/init.d/sysfsutils {start|stop|force-reload|restart}"
+	echo "Usage: /etc/init.d/sysfsutils {start|stop|force-reload|restart|status}"
 	exit 1
 	;;
 esac


signature.asc
Description: OpenPGP digital signature

Bug#832112: xrdp: Listening socket is in wrong state we terminate listener

[Andreas Tille]

Package: xrdp
Severity: important


Hi,

I had installed xrdp 0.9.0~20160601+git703fedd-3~bpo8+1 on a
Jessie+backports machine.  Users have reported several crashes.  This
reflects in the following syslog entries:

# grep xrdp syslog syslog.1 | grep terminated
syslog:Jul 22 08:17:24 host03 xrdp[108161]: (108161)(140047400961792)[ERROR] 
Listening socket is in wrong state we terminate listener
syslog.1:Jul 21 08:38:11 host03 xrdp[109844]: (109844)(140047400961792)[ERROR] 
Listening socket is in wrong state we terminate listener
syslog.1:Jul 21 11:29:57 host03 xrdp[28375]: (28375)(140047400961792)[ERROR] 
Listening socket is in wrong state we terminate listener
syslog.1:Jul 21 11:30:28 host03 xrdp-sesman[83999]: 
(83999)(140226112505600)[INFO ] ++ terminated session:  username user1, display 
:41.0, session_pid 28496, ip 0.0.0.0:49459 - socket: 11
syslog.1:Jul 21 11:30:28 host03 xrdp[28377]: (28377)(140047400961792)[ERROR] 
Listening socket is in wrong state we terminate listener
syslog.1:Jul 21 13:19:25 host03 xrdp[53248]: (53248)(140047400961792)[ERROR] 
Listening socket is in wrong state we terminate listener
syslog.1:Jul 21 13:44:14 host03 xrdp[109845]: (109845)(140047400961792)[ERROR] 
Listening socket is in wrong state we terminate listener
syslog.1:Jul 21 13:44:14 host03 xrdp-sesman[83999]: 
(83999)(140226112505600)[INFO ] ++ terminated session:  username user2, display 
:40.0, session_pid 7692, ip 0.0.0.0:51916 - socket: 11
syslog.1:Jul 21 13:46:50 host03 xrdp[57803]: (57803)(140047400961792)[ERROR] 
Listening socket is in wrong state we terminate listener
syslog.1:Jul 21 13:47:44 host03 xrdp-sesman[83999]: 
(83999)(140226112505600)[INFO ] ++ terminated session:  username user1, display 
:41.0, session_pid 53256, ip 0.0.0.0:50336 - socket: 11
syslog.1:Jul 21 14:19:37 host03 xrdp[63934]: (63934)(140047400961792)[ERROR] 
Listening socket is in wrong state we terminate listener
syslog.1:Jul 21 15:26:24 host03 xrdp[82647]: (82647)(140047400961792)[ERROR] 
Listening socket is in wrong state we terminate listener
syslog.1:Jul 21 16:14:00 host03 xrdp[63941]: (63941)(140047400961792)[ERROR] 
Listening socket is in wrong state we terminate listener
syslog.1:Jul 21 16:14:01 host03 xrdp-sesman[83999]: 
(83999)(140226112505600)[INFO ] ++ terminated session:  username user1, display 
:43.0, session_pid 64021, ip 0.0.0.0:50624 - socket: 11
syslog.1:Jul 21 16:23:49 host03 xrdp[108160]: (108160)(140047400961792)[ERROR] 
Listening socket is in wrong state we terminate listener
syslog.1:Jul 21 17:59:12 host03 xrdp-sesman[83999]: 
(83999)(140226112505600)[INFO ] ++ terminated session:  username user2, display 
:42.0, session_pid 57891, ip 0.0.0.0:49333 - socket: 11
syslog.1:Jul 21 17:59:12 host03 xrdp[57811]: (57811)(140047400961792)[ERROR] 
Listening socket is in wrong state we terminate listener

I have no idea how to track down this.

Note: Since the issue happens on a backport I have not choosen a RC
severity.

Kind regards

   Andreas.

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

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

Versions of packages xrdp depends on:
ii  adduser  3.113+nmu3
ii  libc62.19-18+deb8u4
ii  libpam0g 1.1.8-3.1+deb8u1+b1
ii  libssl1.0.0  1.0.1t-1+deb8u2
ii  libx11-6 2:1.6.2-3
ii  libxfixes3   1:5.0.1-2+b2

Versions of packages xrdp recommends:
pn  vnc4server | tightvncserver | vnc-server  

xrdp suggests no packages.

Bug#830740: mrpt: FTBFS on hppa: parse_NMEA_RMC assertion failure

[JOSE LUIS BLANCO CLARACO]

You're quick! Alright... (sigh) I'll wait until everything ends to see if
there are more problems and will submit one more patch this is
something personal now ;-)

Thanks!

Bug#832113: apt: "Hash sum mismatch" since apt(1.2.14, 1.3~pre2) behind proxy => mixed-up deb filenames

[nice sw123]

Package: apt
Version: 1.3~pre2
Severity: normal

Dear Maintainer,

Short Description
==
Im on Debian Stretch (testing), behind a proxy, and since using
apt:amd64 (1.2.14, 1.3~pre2), I have problems:
When deb's are aquired (via apt install, or apt upgrade), I get the
bunch of deb's, but their names are mixed up.
No joke!
Obviously if content of deb-file has the wrong filename, a "hash sum
mismatch" will occur.


PROBLEM SINCE apt:amd64 (1.2.14, 1.3~pre2)
==
ON my Debian Stretch (testing), on 2016-07-14 I got a new apt package:
apt:amd64 (1.2.14, 1.3~pre2)
as can be seen in my
   /var/log/apt/history.log
->
Start-Date: 2016-07-14  07:35:32
Requested-By: me (1000)
Install: libwebrtc-audio-processing1:amd64 (0.3-1, automatic)
Upgrade: libapt-inst2.0:amd64 (1.2.14, 1.3~pre2), apt:amd64 (1.2.14,
1.3~pre2), python-apt-common:amd64 (1.1.0~beta2, 1.1.0~beta3),
libapt-pkg5.0:amd64 (1.2.14, 1.3~pre2), apt-utils:amd64 (1.2.14,
1.3~pre2), apt-transport-https:amd64 (1.2.14, 1.3~pre2),
python3-apt:amd64 (1.1.0~beta2, 1.1.0~beta3), [...]
End-Date: 2016-07-14  07:38:58

Since then I have problems.


BEHIND A PROXY
==
I need to mention, that I'm behind a proxy; and already have these settings:
 Acquire::http::No-Cache=True;
 Acquire::https::No-Cache=True;
 Acquire::http::Pipeline-Depth 0;
 Acquire::https::Pipeline-Depth 0;
 Acquire::http::No-Cache true;
 Acquire::BroxenProxytrue;


WHAT'S THE PROBLEM WITH APT
===
When doing upgrades or installs, I get "hash sum mismatches"

The mismatched deb files land up in
  /var/cache/apt/archives/partial/* and have FAILED as filename suffix.
Example:
  
/var/cache/apt/archives/partial/libvamp-hostsdk3v5_2.6~repack0-2_amd64.deb.FAILED

The incredible thing is this:

The mismatched deb file
  libvamp-hostsdk3v5_2.6~repack0-2_amd64.deb.FAILED
is a valid archive and contains the content of
  libwxgtk3.0-0v5_3.0.2+dfsg-1.4_amd64.deb

So it seems apt MIXES UP THE FILENAMES on the downloaded deb-packages.



ANALYSIS


Using proxy:
  echo $http_proxy
OUTPUT => http://192.1.1.5:3128

Doing, sudo apt update, now usually hangs waiting indefinately for headers.
This I solve like this:
  sudo rm -rf /var/lib/apt/lists/*
  sudo rm -rf /var/cache/apt/archives/partial/*
  sudo apt update  # now succeeds

Then I install audacity (as an example):
  sudo apt install audacity
OUTPUT =>
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  audacity-data libflac++6v5 libid3tag0 liblilv-0-0 libportsmf0
libqt4-dbus libqt4-xml libqtcore4 libqtdbus4 libqtgui4 libsbsms10
libserd-0-0 libsord-0-0 libsratom-0-0 libsuil-0-0
  libvamp-hostsdk3v5 libwxbase3.0-0v5 libwxgtk3.0-0v5 qdbus qt-at-spi
qtchooser qtcore4-l10n
Suggested packages:
  ladspa-plugin qt4-qtconfig serdi sordi
The following NEW packages will be installed:
  audacity audacity-data libflac++6v5 libid3tag0 liblilv-0-0
libportsmf0 libqt4-dbus libqt4-xml libqtcore4 libqtdbus4 libqtgui4
libsbsms10 libserd-0-0 libsord-0-0 libsratom-0-0
  libsuil-0-0 libvamp-hostsdk3v5 libwxbase3.0-0v5 libwxgtk3.0-0v5
qdbus qt-at-spi qtchooser qtcore4-l10n
0 upgraded, 23 newly installed, 0 to remove and 0 not upgraded.
Need to get 10.8 MB/17.4 MB of archives.
After this operation, 66.7 MB of additional disk space will be used.
Do you want to continue? [Y/n]
Get:1 http://ftp.debian.de/debian stretch/main amd64 libsuil-0-0 amd64
0.8.2~dfsg0-1 [19.5 kB]
Get:2 http://ftp.debian.de/debian stretch/main amd64 audacity-data all
2.1.2-1 [1,549 kB]
Get:3 http://ftp.debian.de/debian stretch/main amd64 libflac++6v5
amd64 1.3.1-4 [37.5 kB]
Get:4 http://ftp.debian.de/debian stretch/main amd64 libid3tag0 amd64
0.15.1b-11 [35.3 kB]
Get:5 http://ftp.debian.de/debian stretch/main amd64 liblilv-0-0 amd64
0.22.0~dfsg0-1 [41.0 kB]
Err:5 http://ftp.debian.de/debian stretch/main amd64 liblilv-0-0 amd64
0.22.0~dfsg0-1
  Hash Sum mismatch
  Hashes of expected file:
   - SHA256:96592e821cf2d3a909469f9ab999a48ee3d51798e18a4f3cb02709a10e1d2427
   - SHA1:9fcd1de0288033cf983fdacf17b2b257dec90a9e [weak]
   - MD5Sum:d410276a8c668f5131cd3b04d760d099 [weak]
   - Checksum-FileSize:41008 [weak]
  Hashes of received file:
   - SHA256:c110e10b0835bacc746a695699914f13710fb57f9fe7d75cabf8017cdca69e1b
   - SHA1:18d984bfc336548614cfcf544c34ede06a4b7560 [weak]
   - MD5Sum:dbf3b4f6c73f84d7d530da1b59274321 [weak]
   - Checksum-FileSize:88708 [weak]
  Last modification reported: Thu, 06 Aug 2015 17:26:52 +
Get:6 http://ftp.debian.de/debian stretch/main amd64
libvamp-hostsdk3v5 amd64 2.6~repack0-2 [88.7 kB]
Err:6 http://ftp.debian.de/debian stretch/main amd64
libvamp-hostsdk3v5 amd64 2.6~repack0-2
  Hash Sum mismatch
  Hashes of expected file:
   - SHA256:c110e10b0835bacc746a695699914f13710fb57f9fe7d75cabf8017cdca69e1b
   - SHA1:18d984bfc336548614cfcf544c34ede06a4b7560 [weak]
   - MD5Sum:dbf3b4f6c73f84d7d530da1b59274321 [weak]

Bug#832112: xrdp: Listening socket is in wrong state we terminate listener

[Dominik George]

Control: tag -1 + moreinfo

Hi Andreas,

thanks for your report!

In order to reproduce this, could you please provide information like

 * What DE/kind of session is used
 * What client(s) is/are used
 * Any information about the network between clients and server, like 
NAT/proxy/etc.

Also, is the session terminated, or can the user re-attach?

Cheers,
Nik
-- 
PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17 FD26 B79A 3C16 A0C4 F296

Dominik George · Mobil: +49-1520-1981389

Teckids e.V. · FrOSCon e.V. · OpenRheinRuhr e.V.
Fellowship of the FSFE · Piratenpartei Deutschland
Opencaching Deutschland e.V. · Debian Contributor

LPIC-3 Linux Enterprise Professional (Security)

Bug#831181: oding: ftbfs with gcc-6

[Gianfranco Costamagna]

new debdiff attached.

G.
diff -Nru odin-2.0.2/debian/changelog odin-2.0.2/debian/changelog
--- odin-2.0.2/debian/changelog 2016-07-16 09:33:28.0 +0200
+++ odin-2.0.2/debian/changelog 2016-07-22 13:58:53.0 +0200
@@ -1,3 +1,10 @@
+odin (2.0.2-0.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Revert a little bit of the previous gcc-6-fix2.
+
+ -- Gianfranco Costamagna   Fri, 22 Jul 2016 
13:58:23 +0200
+
 odin (2.0.2-0.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru odin-2.0.2/debian/patches/gcc-6-fix2.patch 
odin-2.0.2/debian/patches/gcc-6-fix2.patch
--- odin-2.0.2/debian/patches/gcc-6-fix2.patch  2016-07-16 09:52:15.0 
+0200
+++ odin-2.0.2/debian/patches/gcc-6-fix2.patch  2016-07-22 13:58:22.0 
+0200
@@ -2,25 +2,6 @@
 
 Author: Gianfranco Costamagna 
 
 odin-2.0.2.orig/odinseq/seqgradspiral.cpp
-+++ odin-2.0.2/odinseq/seqgradspiral.cpp
-@@ -27,12 +27,12 @@ float SeqGradSpiral::readout_npts() cons
- const kspace_coord& tds=traj_cache->calculate(s);
- if(i) {
-   
deltaKtangential=STD_max(double(deltaKtangential),norm(tds.kx-last_kx,tds.ky-last_ky));
--  max_grad_diff=STD_max(double(max_grad_diff),fabs(tds.Gx-last_Gx));
--  max_grad_diff=STD_max(double(max_grad_diff),fabs(tds.Gy-last_Gy));
-+  max_grad_diff=STD_max(max_grad_diff,fabs(tds.Gx-last_Gx));
-+  max_grad_diff=STD_max(max_grad_diff,fabs(tds.Gy-last_Gy));
- }
- 
--max_grad_magn=STD_max(double(max_grad_magn),fabs(tds.Gx));
--max_grad_magn=STD_max(double(max_grad_magn),fabs(tds.Gy));
-+max_grad_magn=STD_max(max_grad_magn,fabs(tds.Gx));
-+max_grad_magn=STD_max(max_grad_magn,fabs(tds.Gy));
- 
- last_kx=tds.kx;
- last_ky=tds.ky;
 --- odin-2.0.2.orig/cmdline-utils/swab.cpp
 +++ odin-2.0.2/cmdline-utils/swab.cpp
 @@ -28,7 +28,7 @@ int main(int argc, char* argv[]) {


signature.asc
Description: OpenPGP digital signature

Bug#817586: most: diff for NMU version 5.0.0a-2.4

[gregor herrmann]

On Fri, 22 Jul 2016 03:36:06 +0200, gregor herrmann wrote:

> > I'd love to see your NMU with all those fixes get into the archive
> > (compared to my minimal "just bump debhelper compat level"), so I've
> > reschedule my NMU to DELAYED/12 (as a hopefully not needed fallback).
> 
> Or did I reschedule your NMU? Or was your NMU rejected and I
> rescheduled mine? Or something else?
> 
> https://ftp-master.debian.org/deferred/ currently shows my .changes
> -- and nothing more from me or you :/

It's back, and it seems to be my variant ...
I guess I should cancel it so that you can upload your version?


Cheers,
gregor

-- 
 .''`.  Homepage https://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer -  https://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Leonard Cohen: So long, Marianne


signature.asc
Description: Digital Signature

Bug#762829: file: Pascal modules (ISO 10206) wrongly classified as text/x-ruby

[Peter]

On 16/07/16 23:28, Christoph Biedl wrote:
> tags 762829 confirmed upstream help
> thanks
> 
> It's been a while but it hasn't been forgotten ...
> 
> Peter wrote...
> 
>> Some Pascal source files are classified as Ruby.
>> Maybe file is confused by the keywords 'module', 'import' and export,
>> which are valid Pascal extension keywords in ISO 10206?
> 
> Correct, the "module" keyword in the first line of your example
> triggers one of the tests for ruby (magic/Magdir/ruby:25).
> 
> However I'm reluctant to change this as it easily might create
> false-positives. If there's is a distinct rule to tell Ruby and
> Pascal apart, I'll happily forward it to upstream.
> 
> Christoph
> 

Hi Christoph,

Thanks for looking at this. I'm afraid I know very little about Ruby.

Pascal files often have semicolons at the end of some lines, and the
final line is often "end."

The Ruby code I have looked at on http://rosettacode.org never has
semicolons at the end of lines and the final "end" does not have a
period after it.

This suggests two tests that could separate Ruby & Pascal.

Regards,
Peter

Bug#832110: libjs-c3: c3.css missing from install

[Mathias Behrle]

* Debian Bug Tracking System: " Bug#832110: Acknowledgement (libjs-c3: c3.css
  missing from install)" (Fri, 22 Jul 2016 11:54:05 +):

Just to be complete: same for c3.min.css obviously,

Best,
Mathias

Bug#831072: singular: FTBFS with GCC 6: segfault

[Jerome BENOIT]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

retitle 831072 singular: FTBFS with GCC 6: segfault
thanks


Hello Folks,

it appears that it is segfault bug.

I could reproduced it the vanilla source ball by
building with GCC compilers (6.1.1) and by forcing shared library
at configure time:

$ ./configure --enable-shared --disable-static

Then, after processing `make', ./Singular/Singular emits a segfault.

The GDB prints:

 GNU gdb (Debian 7.11.1-2) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./Singular/Singular...done.
[New LWP 7786]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `./Singular/Singular'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7fa9769a810d in idrec::get(char const*, int) () from 
/home/calculus/singular/unpacked/singular-4.0.3-11/Singular/.libs/libSingular-4.0.3.so

Exporting dpkg-buildflags FLAGS, shows that the issue is emiited from line 104 
of Singular/ipid.cc :

l=IDLEV(h);

where `idhdl h = this;' (line 94) and IDLEV is the macro  `((a)->lev)' defined 
in Singular/ipid.h .

Thanks,
Jerome



- -- 
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B
-BEGIN PGP SIGNATURE-

iQQcBAEBCgAGBQJXkgy7AAoJED+SGaZ/NsaLfa4gAKkOJfSVdtNLv3WUO5mfDFr3
/iaky+2BxHMEXt/s5/hURe0/6JbdP5I/Y2dIsuHXObTp8xt0WKIIVgIhF7BuJ53m
vU4bOv4F/ByncstN+6fekXTTwI0xYi2EZwmhPCdAcz5Dn4Rx4gE7ixPynDOl5iJZ
6CWOBdlH+Cq6nqqHZun6cihol6FjKUiDWtRyvnuGqEopv05aEbtH3MZFECAHxi3j
himoj9VOgGDOYZ2IW/Ro0mAPkZyay5KcBAY0NGen4kry0OlYV6OmG+N5ogV6IKFh
o2ICpF7m5mbiagLF2XcjK03oZWLcCeS/EzG0YIIL1fd/Y7dJg6KxHvAJwSD04mW+
c8AGmqTeeeWxv7JnvU+MtixiVVjQPwkSs53K5EOMzJVT/6gtH/wUWTN/AtXn20te
cbo8KXht/K1x+oFuq/ELpRWK8yvuzCJ9WT1vvkxE1bTm/8D8ABgmyDHIXQ6siUWk
zFQtiWV9aRLpQjO4WWMRFx/UW3cg4uG0lnvirbxBK9nCKk6BrV5X5lh+98/bPvnd
F+Ab51Rf+s50TLEN6Z2ju3yD5RCGPrBIY3MckiG8U2sglKfbfDwMxu+EAqWjESsb
dYiby2h4FWWODUOK8N1JzLc0aMS9Gc6vX+IVLilCVKxfAzvCXJ5SZ54ZvUsTfZg/
oOGWcM0EkEsZGAgSOHonLOa+AbvdwOFfPAjm63u+MXGE3537Gteo9U6MmLfF8Yc6
HYpopsYMvxd4b57tRETc+d4KPTLqR/jjl4ObtxQ79nFjR1CnEIRuI+6P7593aJAw
Dlo8nhzgIuitwysfd+vKbmPCjXk47NtN/cVi7qHfd93vYlUFaR+7Ey3KVqA4Emut
W4lscFaR7PVjRYW+HPzR5zmUdB++ZIm21awlbCCgzqYq8MJb785jxdogbf6ekpC/
FiS1kk0PyWWQbFu7sOEkjwCtTfvr4+5XvIeDsh5U8oJJV8BgfDvMOfdi9lIKAg7P
13KCdLtqGn7XxaMvWHjVcpxfmd6V8MuSAfWdf/ywguIiEN0LoxAM7T4MzPufOLVs
P1RhQioURYGVc73QD6lH0Q5y6uU4t2PjLr7CNRNIfhuD2HBXgmtkQAlr9luFbqXx
TStcMNIr/yWkMz1QWNW8QJlWq3oRL34t7ipaCmkG/eQkXOOrLxYNFAoezNyB6FPd
M2AFsHV9PDxUqkSsJZ9ciw6P1ZS7HUh3iP4W+DGZzGQh1NUVsVMHqXi1pqKVksyr
gdXCF6Rucp1+jVNew/ncWw7sxZAXZl3EiNT9/uxvJvZ6ho/pl/07TXGXZsp1jFqM
m+OkuG7Y4H2yAUUYaxuR6M8KNQ7CWFRjEWvTBbJEbElIeBOUu17qaoRDsMpMZCU=
=z9wv
-END PGP SIGNATURE-

Bug#485753: dogtail: dogtail-detect-session of limited usefulness

[Michael Prokop]

forwarded -1 https://fedorahosted.org/dogtail/ticket/68
thanks

* Yann Dirson (Debian) [Wed Jun 11, 2008 at 10:24:04AM +0200]:

> When run without any at-spi client launched (eg. under kde, just after
> starting registryd manyally):

> $ dogtail-detect-session
> Creating logfile at
> /tmp/dogtail/logs/dogtail-detect-session_20080611-101909_debug ...
> Detecting distribution: Debian (or derived distribution)
> Warning: AT-SPI's desktop is visible but it has no children. Are you
> running any AT-SPI-aware applications?
> Traceback (most recent call last):
>   File "/usr/bin/dogtail-detect-session", line 60, in 
> if GNOME() or KDE() or JustSomeApps():
>   File "/usr/bin/dogtail-detect-session", line 32, in GNOME
> assert focus.desktop.children
> AssertionError

> And even after starting one more app:

> $ dogtail-detect-session --help
> Creating logfile at
> /tmp/dogtail/logs/dogtail-detect-session_20080611-101946_debug ...
> Detecting distribution: Debian (or derived distribution)
> Warning: /usr/bin/dogtail-detect-session:60: The requested object was not
> found:
>   if GNOME() or KDE() or JustSomeApps():

> ERROR: No session found.

AFAICS the KDE code is just boilerblate code which does nothing but
returning false all the time and only the GNOME desktop is actually
covered.

I've forwarded this to upstream's BTS:
https://fedorahosted.org/dogtail/ticket/68

regards,
-mika-


signature.asc
Description: Digital signature