Bug#836810: tj3: man pages for TaskJuggler

[Christopher Hoskin]

Package: tj3
Version: 3.6.0-3
Severity: wishlist

Dear Maintainer,

Man pages are not provided for the TaskJuggler programs (tj3, tj3client, tj3d, 
tj3man, tj3ss_receiver, tj3ss_sender, tj3ts_receiver, tj3ts_sender, 
tj3ts_summary, tj3webd). This is considered a bug by Debian[0].

I have submitted a pull request[1] upstream to address this, and will shortly 
attach a corresponding patch to this bug report.

Thanks.

Christopher Hoskin

[0] https://www.debian.org/doc/debian-policy/ch-docs.html
[1] https://github.com/taskjuggler/TaskJuggler/pull/196

Bug#836535: coordinate a way to use librevenge.pc from cross-pkg-config

[Rene Engelhard]

reassign 836535 librevenge-dev,pkg-config
thanks

Hi,

On Sat, Sep 03, 2016 at 10:01:01PM +0200, Rene Engelhard wrote:
> I was not, am not and will not do multiarch in my packages.

After some thinking (and having discussed this AGAIN in real-life)
I still don't see the need for multiarch except for multiarch per se
(multiarch was an needed where people needed to install i386 stuff on amd64,
or similar stuff for other architectures). But we missed the point where it
was stopped needed and nowadays that basically everything is amd64 and
remaining stuff is non-free (somoeone mentioned skype as an example...) and 
given Debian is not cross-built so that argument is moot, too. 

Actually if the 32bit archs are the argument, they should be
dropped instead of being cross-built...)

I have given up nevertheless and will do a mass-upload of my packages which
are not yet multiarched and multiarch them..

Which then also fixes this one. This bug will be closed by librevenges upload.

Regards,
 
Rene

Bug#681375: I would also like to support for having this mailing list

[Adalberto Naranjo]

Saludos

-- 
El contenido de este mensaje y sus anexos son únicamente para el uso del 
destinatario y pueden contener información  clasificada o reservada. Si 
usted no es el destinatario intencional, absténgase de cualquier uso, 
difusión, distribución o copia de esta comunicación.

Bug#836794: cme: 'cme update dpkg-copyright' no longer work

[Petter Reinholdtsen]

[Gregor Herrmann]
> 
> This sounds a bit like you don't have the dpkg-copyright model
> installed, a.k.a. you're missing libconfig-model-dpkg-perl (which is
> "only" a Recommends of cme).
> 

You are right.  Installing it got cme working again. No idea how that
package got uninstalled from my sid chroot.  'cme update dpkg-copyright'
used to work here, and suddenly no longer worked.

Perhaps the error message should be improved to suggest to install the
libconfig-model-dpkg-perl package if dpkg-copyright is used?

-- 
Happy hacking
Petter Reinholdtsen

Bug#836388: [pkg-go] Bug#836388: When cache is present, job run from incorrect working directory

[Dmitry Smirnov]

On Saturday, 3 September 2016 6:43:05 AM AEST Sam Hartman wrote:
> ...but I'm really
> frustrated when I am told to "discuss with upstream."

Too bad. Debian bug tracker is not a substitute to upstream one.
If you had a chance to check upstream bug reports there are chances you could 
have found more information about the problem from existing bug reports...

Of course it make sense to check Debian bug tracker first.


> We, Debian, have
> agreed to provide a coherent operating system that works together.
> Part of what we sign up to do when we agree to maintain packages is to
> do a fair bit of upstream coordination.

Debian is mostly an integration project. We do not do (much) upstream 
development here. Therefore if your problem is about upstream features/
functionality then the right place to discuss it is at the upstream bug 
tracker.

Also you can avoid delays and reduce maintenance burden by discussing the 
matter with upstream who have more expertise and more users who might be 
experiencing the same problem.

> I don't know where the upstream bug tracker is.  I don't have an account
> there.

  https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/issues

You do not need an account to check existing bug reports.


> I don't wish to get an account there.

Fair enough.


> I don't wish to evaluate whether
> Debian has applied patches that matter in this space.

To some extent this problem exists even on pristine latest release as 
upstream not always indicates which version fixes the problem...


> But the agreement we make to our users is that we provide a single
> consistent interface for them to report bugs.

I've never blamed you for opening a bug. What are you complaining about?


> If you don't have the skills to work on this issue it's entirely
> reasonable to forward it upstream.

Which takes time. Besides forwarding bugs is not an effortless thing. One 
have to validate the problem and clearly describe it with reproducer. It 
could be that I'm just too tired (or don't have enough experience) but from 
your bug report I could not understand the problem nor to find out clear 
reproducer or get what desirable behaviour would be... It might take weeks 
before I'll be able to get to this problem and the situation is such that you 
are more likely to find help upstream. gitlab-ci-multi-runner is still a 
young package so you'd be lucky to get help from another Debian user.


> It's also greatly appreciated that you let me know that if I want a
> faster response I  might want to deal with upstream directly.

Sorry for not being able to be more helpful with this problem...

-- 
Best wishes,
 Dmitry Smirnov.

---

There is no society in human history that ever suffered because its people
became too reasonable.
-- Sam Harris


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

Bug#831409: [pkg-gnupg-maint] Bug#831409: ltsp-client lacks gnupg / gnupg2 for apt-key to work

[Alkis Georgopoulos]

On 06/09/2016 06:10 πμ, Daniel Kahn Gillmor wrote:
> The original report does point out that the system in question doesn't
> have gpg available.  the awk|base64 pipeline was written to accomodate
> that constraint :)

gpg wasn't available in the chroot,
(so it was an issue with debootstrap --variant=minbase not pulling gnupg)
while now it's used in the server-side code
(so ltsp-server just needs to depend on gpupg).

Bug#836809: hexchat: New version of hexchat: 2.12.1 has released

[Arcademan]

Package: hexchat
Version: 2.12.0-2~bpo8+1
Severity: important

Dear Maintainer,

It would be great if you could push package to version 2.12.1 in debian 
backports.

Thanks, Arcademan.

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

Kernel: Linux 3.16.0-4-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: systemd (via /run/systemd/system)

Versions of packages hexchat depends on:
ii  hexchat-common   2.12.0-2~bpo8+1
ii  libatk1.0-0  2.14.0-1
ii  libc62.19-18+deb8u4
ii  libcairo21.14.0-2.1+deb8u1
ii  libcanberra0 0.30-2.1
ii  libdbus-1-3  1.8.20-0+deb8u1
ii  libdbus-glib-1-2 0.102-1
ii  libfontconfig1   2.11.0-6.3+deb8u1
ii  libfreetype6 2.5.2-3+deb8u1
ii  libgdk-pixbuf2.0-0   2.31.1-2+deb8u5
ii  libglib2.0-0 2.42.1-1+b1
ii  libgtk2.0-0  2.24.25-3+deb8u1
ii  libnotify4   0.7.6-2
ii  libpango-1.0-0   1.36.8-3
ii  libpangocairo-1.0-0  1.36.8-3
ii  libpangoft2-1.0-01.36.8-3
ii  libproxy10.4.11-4+b2
ii  libssl1.0.0  1.0.1t-1+deb8u2

Versions of packages hexchat recommends:
ii  gvfs-bin 1.22.2-1
ii  hexchat-perl 2.12.0-2~bpo8+1
ii  hexchat-plugins  2.12.0-2~bpo8+1
ii  hexchat-python3  2.12.0-2~bpo8+1

Versions of packages hexchat suggests:
pn  unifont  

-- no debconf information

Bug#831409: [pkg-gnupg-maint] Bug#831409: ltsp-client lacks gnupg / gnupg2 for apt-key to work

[Daniel Kahn Gillmor]

On Sat 2016-09-03 04:22:48 -0400, Werner Koch wrote:
> On Sat,  3 Sep 2016 05:24, vagr...@debian.org said:
>
>>> If you've got it in ascii-armored format and aren't sure how to decode
>>> it, you should be able to do that with a short awk | base64 -d pipeline:
>>>
>>>   awk '/^$/{ x = 1; } /^[^=-]/{ if (x) { print $0; } ; }' | base64 -d 
>>
>> Thanks!
>
> Or simply use
>
>   gpg --dearmor output
>
> to strip an OpenPGP armor.

The original report does point out that the system in question doesn't
have gpg available.  the awk|base64 pipeline was written to accomodate
that constraint :)

 --dkg

Bug#836732: strip-nd: FTBFS when locale is not English

[HW42]

Chris Lamb:
> tag 836732 + pending
> thanks
> 
>> Not sure how much related they are, but I guess it means something given
>> that it's not in the English build.
> 
> I don't really understand why that would be causing an error but we follow
> your assumption that the "return" that is causing the FTBFS, then it was
> removed and thus fixed in Git already:

I think this has nothing to do with locale. The problem is that dash and
bash are treating 'return' differently.

  $ bash -c 'true; return $?' && echo ok
  bash: line 0: return: can only `return' from a function or sourced script
  $ dash -c 'true; return $?' && echo ok
  ok
  $

So depending on what is used as /bin/sh the build fails or not.

>   
> https://anonscm.debian.org/git/reproducible/strip-nondeterminism.git/commit/?id=72d70fcd7a088ca0f97d4a9f67e2e42c0c1505ff

If it's not needed at all that's nice. Else you could replace 'return'
with 'exit'.



signature.asc
Description: OpenPGP digital signature

Bug#836808: ITP: golang-github-googleapis-gax-go -- Google API Extensions for Go

[Potter, Tim (HPE Linux Support)]

Package: wnpp
Severity: wishlist
Owner: Tim Potter 
X-Debbugs-CC: debian-de...@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org

* Package name: golang-github-googleapis-gax-go
  Version : 0.0~git20160714.0.8b0741b-1
  Upstream Author : Google APIs
* URL : https://github.com/googleapis/gax-go
* License : BSD-3-clause
  Programming Lang: Go
  Description : Google API Extensions for Go

 Google API Extensions for Go (gax-go) is a set of modules which aids
 the development of APIs for clients and servers based on gRPC and Google
 API conventions.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#785799: [festvox-ca-ona-hts] Since las festival upgrade, catalan voice is not correctly recognized and does not work

[Guillem Jover]

On Tue, 2016-09-06 at 00:54:38 +0200, Sergio Oller wrote:
> 2016-09-05 23:32 GMT+02:00 Guillem Jover :
> >  * The copyright years and holders might need an update?
> 
> I have updated the copyright years and holders for the files that have
> changed among versions.

Sorry for being nit-picky, but I think you mentioned that you modified
those files, although as holder UPC and/or Antonio Bonafonte are
mentioned. Shouldn't you add yourself there?

Once this is clarified, I'll be doing the upload.

> >  * I have no clue how these voices work internally so you'll have
> >to give me a hand here. What's the source for upc_ca_ona.htsvoice?
> >How do you generate that? Do we have the tools to do so in Debian?
> >Otherwise we might need to put this in contrib. :/
> 
> I would understand moving the package to contrib if that is where it
> belongs.
> 
> There is a summarised description of the process of generating the htsvoice
> file in the README.source file. Basically, the htsvoice file contains the
> voice model (so no "code", just "data").

Ah right, sorry I think I had seen it before when I checked the source
some weeks ago, but had forgotten. At first sight, it unfortunately looks
like a contrib candidate to me, indeed.

In Debian we consider code/data just software, so the distinction is
not usually significant.

I think the situation here is complicated by several factors:

 1) The LGPL on the output means the source should be shipped
together. And the DFSG does requite that anyway.
 2) The source is very huge, and might not be suitable for the
archive anyway.
 3) Generating the output is very time and memory consuming, which
means it is unfeasible to build as any normal package, but
given 2), we cannot easily fallback to use the pre-generated
files and just ship the sources in case someone wants to change
something.
 4) And to generate the source we need a non-free tool as well.

Perhaps other voices can easily get by because they do not suffer (as
much) from 1, 2 and 4, which means that 3 ends up being acceptable.

> Other packages (such as festlex-poslex) do provide trained models without
> the training the data from scratch and are in main. I found a thread
> https://lists.debian.org/debian-legal/2009/05/msg00028.html where a similar
> case is discussed, but I did not see a final consensus on the issue. Also,
> the ftp masters authorised the previous upload of this package.

Right, I think this has the potential to affect pretty much all the
festival voices in Debian, so this probably deserves a wider discussion
at least within the TTS team. So I'm fine with uploading a package fixing
the current bug, and then dealing with any decision on the location of
the sources in the archive.

> I (as part of upstream) cannot improve the situation for the htsvoice
> models as we don't have the resources to develop a fully free alternative
> to HTK. Providing the raw data should allow anyone to train better models
> and it is already more than what other packages have done.

Having the raw data and the output voices is already great! Even if we
end up concluding that this needs to go into contrib.

Thanks,
Guillem

Bug#836710: pkg_resources: ‘load_entry_point’ crashes without Setuptools

[Ben Burton]

> Had you updated your Sid VM recently? Which version of
> ‘python-pkg-resources’ was installed when you experienced that
> behaviour?

Yesterday.  The version you added was correct.

- b.

Bug#777651: RFS: syncterm/1.0+dfsg-1 [ITP]

[Fernando Toledo]

El 16/08/16 a las 09:15, Gianfranco Costamagna escribió:
> control: tags -1 moreinf
> 
> Hi,
> 
>>* Initial release (Closes: #739035)
> lets try a review:

Hi gianfranco! lets go:
> 
> 1) std-version is 3.9.8 now

fixed.

> 
> 2) debhelper (>= 9), libncurses5-dev (>= 5.9),
>  unzip (>= 6.0), libsdl2-dev (>= 2.0.2), libsdl1.2-dev (>= 1.2.15),
>  gcc (>= 4:4.9)
> 
> 
> do you really need both sdl1.2 and sdl2?
> do you really need the version constraints for each dependency?
> why gcc is listed here?
> please  drop versions when already satisfied in jessie, or wheezy in case you 
> want to try
> a backport-sloppy (I would really avoid that)

remove gcc,
let sdl 1.2 (remove unused sdl2)
update versions from unstable

fixed.

> 
> 3)
> Architecture: i386 amd64
> Depends: ${shlibs:Depends}, ${misc:Depends}, libncurses5 (>= 5.9),
>  libsdl2-2.0-0 (>= 2.0.2), libsdl1.2debian (>= 1.2.15)

>why only two architectures? why aren't the runtime dependencies picked up with 
>shlibs:Depends?
> ldd debian/syncterm/usr/bin/syncterm 
>   linux-vdso.so.1 =>  (0x7ffeca745000)
>   libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x7efc98d79000)
>   libncurses.so.5 => /lib/x86_64-linux-gnu/libncurses.so.5 
> (0x7efc98b57000)
>   libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 
> (0x7efc9892d000)
>   libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7efc98729000)
>   libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7efc9842)
>   libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
> (0x7efc98202000)
>   libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7efc97e39000)
>   /lib64/ld-linux-x86-64.so.2 (0x560b91261000)
> 
> 
> at least they seems to be mostly not linked at runtime.

fixed.
i only can test in these archs, but i changed it to =>  any


> 
> 4) rules: to understand the platform you are building, I suggest to use 
> dpkg-architecture
> dpkg-architecture -qDEB_TARGET_*
> 
im cleanup the code and use dpkg-architecture now. Great!
fixed

> 5) override_dh_strip:
> dh_strip --dbg-package=syncterm-dbg
> 
> 
> please avoid dbg packages, they are auto generated now

true! i remove it. fixed
> 
> 
> 6) ls src/
> build  comio  conio  sbbs3  smblib  syncterm  uifc  xpdev
> 
> some (most) of them looks like embedded libraries

it's part of uptream source. can i do something to make it better?
> 
> 7) disabled_cryptlib needs to end in .patch (also in series file you should 
> change it)

fixed.

> ---
> The information above should follow the Patch Tagging Guidelines, please
> checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
> are templates for supplementary fields that you might want to add:
> 
> this seems useless

fixed too

> 
> 8) the license is non dfsg
> 
>  The files sbbs3/zmodem.h and sbbs3/zmodem.c are derived from the
>  zmtx/zmrx package available at
>  ftp://ftp.netsw.org/net/modem/protocols/zmodem/zmtx-zmrx/
>  .
>  The licence contained in the archive is:
>  .
>  MCS allows you to use and copy/modify this source under the following
>  conditions:
>  .
>   - MCS or Jacques Mattheij shall not be liable for any damages arising
> from the use of this code
>   - the archive must be distributed as a whole leaving version numbers intact.
> please do not distribute modifications; mail them back to us for inclusion
> in the next release which should follow each other fairly quickly in
> the beginning
>   - you will not use this software for commercial purposes.
> (commercial licenses are available contact us for info)
>  .
>  As such, this program may not be redistributable.  YOU HAVE BEEN WARNED!
>  .
>  If anyone can put me (sh...@sasktel.net) in contact with the authours,
>  that would be greatly appreciated.
> 
this was fixed.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777651#57

You can check the  zmodem.* header file on cvs
http://cvs.synchro.net/cgi-bin/viewcvs.cgi/src/sbbs3/zmodem.h?revision=1.54=markup

Unfortunately, this was after 1.0 release date, and it was made through
my work to contact everyone involved and good response from them.

> 
> 9) LGPL with no versioning is wrong.

fixed

> 
> 10) many missing licenses: e.g. BSD-4-clause
> 11) many missing copyrights, e.g.
> grep copyright . -Ri
> 
> stopping here the review, because of 8, that needs to be fixed upstream I 
> think
> 

I think that can parse file by file to fine copyright settings.
i update it, please check,
I want to the package fit the debian legal requeriments, the code is
gpl, lgpl and some files bsd. i think that all are dfsg
The non-dfsg part was cryplib and was removed via patch (the app can be
used without that lib)

> automatic checks from check-all-the-things:
> 
> $ env PERL5OPT=-m-lib=. cme check dpkg
> [lots]
> $ codespell --quiet-level=3
> [lots]
> $ cppcheck -j1 --quiet -f .
> [lots]
> $ find -type f -iname '*.desktop' -exec desktop-file-validate {} \;
> [some]
> $ fdupes -q -r . | grep 

Bug#836714: security upload for Charybdis

[Antoine Beaupré]

Also note that there's a proposed-update in the release.debian.org queue
as well, in #834854. the p-u is built on top of this security upload.

not sure that matters, but i figured i would mention it.

a.
-- 
I believe that love is a better teacher than a sense of duty.
   - Albert Einstein

Bug#836807: opendkim: Existing /etc/default/opendkim causes startup failure

[Chris Chiappa]

Package: opendkim
Version: 2.10.3-5
Severity: normal

It may be that this is not technically a bug, but I recently upgraded
opendkim and encountered some mildly tricky problems.  I perhaps
should not have simply kept my existing /etc/default/opendkim, but
having done that, it was missing settings for RUNDIR and PIDFILE.
This caused /lib/opendkim/opendkim.service.generate to generate a bad
/lib/systemd/system/opendkim.service .  If the upgrade process won't
offer to fix up my /etc/default/opendkim, I think
opendkim.service.generate should at least raise an error if a required
setting is missing from the configuration file.

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

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

Versions of packages opendkim depends on:
ii  adduser  3.115
ii  dns-root-data2015052300+h+1
ii  init-system-helpers  1.42
ii  libbsd0  0.8.3-1
ii  libc62.24-2
ii  libdb5.3 5.3.28-12
ii  libldap-2.4-22.4.42+dfsg-2+b2
ii  liblua5.1-0  5.1.5-8.1
ii  libmemcached11   1.0.18-4.1
ii  libmemcachedutil21.0.18-4.1
ii  libmilter1.0.1   8.15.2-4
ii  libopendbx1  1.4.6-10
ii  libopendkim102.10.3-5
ii  librbl1  2.10.3-5
ii  libssl1.0.2  1.0.2h-1
ii  libunbound2  1.5.9-3
ii  libvbr2  2.10.3-5
ii  lsb-base 9.20160629

opendkim recommends no packages.

Versions of packages opendkim suggests:
ii  opendkim-tools  2.10.3-5
pn  unbound 

-- Configuration Files:
/etc/default/opendkim changed:
RUNDIR=/var/spool/postfix/var/run/opendkim
SOCKET="local:/var/spool/postfix/opendkim/opendkim.sock"
USER=opendkim
GROUP=opendkim
PIDFILE=$RUNDIR/$NAME.pid
EXTRAAFTER=

/etc/dkimkeys/README.PrivateKeys [Errno 13] Permission denied: 
u'/etc/dkimkeys/README.PrivateKeys'
/etc/opendkim.conf changed:
Syslog  yes
UMask   002
Canonicalizationrelaxed/relaxed
SubDomains  yes
OversignHeaders From
TrustAnchorFile   /usr/share/dns/root.key
AutoRestart Yes
AutoRestartRate 10/1h
LogWhy  Yes
ExternalIgnoreList  refile:/etc/opendkim/TrustedHosts
InternalHosts   refile:/etc/opendkim/TrustedHosts
KeyTablerefile:/etc/opendkim/KeyTable
SigningTablerefile:/etc/opendkim/SigningTable
Socket  local:/var/spool/postfix/opendkim/opendkim.sock
Statistics  /var/log/opendkim/dkim-stats
SignatureAlgorithm  rsa-sha256


-- no debconf information

Bug#836806: clang on dual arch (x86_64/i386) system tries to use 64 bit libs when m32 is passed

[Matt Parnell]

Package: clang (all versions?)

Ever since the upgrade to gcc6/libstdc++6, this has been an issue.
I build a private application that only works with 32 bit libs currently and
as a result have to include the i386 architecture to pull in a few
specific libraries.
For whatever reason, clang chooses to ignore -m32 and use the x86_64 libraries
if I do not disable (rename/move) them.

Before workaround:

clang -v -m32
Debian clang version 3.6.2-3 (tags/RELEASE_362/final) (based on LLVM 3.6.2)
Target: i386-pc-linux-gnu
Thread model: posix
Found candidate GCC installation: /usr/bin/../lib/gcc/i686-linux-gnu/5.4.1
Found candidate GCC installation: /usr/bin/../lib/gcc/i686-linux-gnu/6.1.1
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8.5
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9.3
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.1
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6.1.1
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.4.1
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6.1.1
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.3
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.1
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.1.1
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6.1.1
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64

After:

clang -v -m32
Debian clang version 3.6.2-3 (tags/RELEASE_362/final) (based on LLVM 3.6.2)
Target: i386-pc-linux-gnu
Thread model: posix
Found candidate GCC installation: /usr/bin/../lib/gcc/i686-linux-gnu/5.4.1
Found candidate GCC installation: /usr/bin/../lib/gcc/i686-linux-gnu/6.1.1
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8.5
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9.3
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.1
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.4.1
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6.1.1
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.3
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.1
Selected GCC installation: /usr/bin/../lib/gcc/i686-linux-gnu/5.4.1
Candidate multilib: .;@m32
Selected multilib: .;@m32

Bug#836805: gobgp: FTBFS (i386): undefined: syscall.SYS_SETSOCKOPT

[Aaron M. Ucko]

Source: gobgp
Version: 1.10-1
Severity: important
Justification: fails to build from source

The i386 build of gobgp failed:

  # github.com/osrg/gobgp/server
  src/github.com/osrg/gobgp/server/sockopt.go:66: undefined: 
syscall.SYS_SETSOCKOPT
  src/github.com/osrg/gobgp/server/sockopt_linux.go:95: undefined: 
syscall.SYS_SETSOCKOPT

AFAICT, this error stems from the fact that early Linux architectures such
as i386 historically multiplexed setsockopt and several other functions
through a special "socketcall" syscall.  i386 did eventually develop a
dedicated setsockopt syscall (number 366), but zsysnum_linux_386.go
doesn't (yet) reflect that, and I don't know what the runtime portability
considerations of using it would be anyway.  Instead, I'd recommend using
the predefined syscall.setsockopt wrapper.

Could you please take a look?

Thanks!

Bug#827936: po4a: please implement support for Ruby document format

[Martin Quinson]

Hello Francesco,

I had a quick lookup at your work, and it looks very promising to me. 

A first point would be to convert your tests to a proper test of our
infrastructure, somewhere under t/ Once you have some automated tests,
I will happily integrate your work in the main archive.

Then, the next step will be to test your work against the existing
Ruby documentation, and fix it until it works properly. I saw the
documented limitations, but I'm not sure of how bad they are,
considering the existing Ruby documentation.

When it will work with the existing doc, you will have a good selling
point to discuss with the Ruby community.

In any case, many thanks for this contribution, that's good work.

Kudos, Mt.

On Mon, Sep 05, 2016 at 11:15:08PM +0200, Francesco Poli wrote:
> On Mon, 5 Sep 2016 15:00:11 +0200 Martin Quinson wrote:
> 
> > Hello Francesco,
> 
> Hello Martin,
> thank you so much for writing me!
> 
> Your message is really appreciated, as I was just going to send an
> update today (an astonishing coincidence!).
> 
> > 
> > did you manage to do any progress on this front?
> 
> It was an interesting ride in the last two months, and the time devoted
> to the development of the po4a module was not so abundant...
> But, nonetheless, I've just come up with the attached version of the Rd
> module.
> The tar archive includes the module implementation and a little
> document to test it (the tests/ directory also contains the various
> output files and two scripts).
> 
> > Is there anything I could do to help?
> 
> Yes, there is.
> 
> Could you please
> 
>  * review the code I wrote
> 
>  * review the documentation I added (I haven't tried to convert it into
>a man page with POD tools, so bear with me!)
> 
>  * test the module with po4a
> 
> and tell me how the module could be improved?
> 
> Thanks for your time and helpfulness!
> Bye.
> 
> 
> 
> P.S.: Please remember to keep me in Cc, when replying (as I am not
>   subscribed to the mailing list or to the bug). Thanks.
> 
> -- 
>  http://www.inventati.org/frx/
>  There's not a second to spare! To the laboratory!
> . Francesco Poli .
>  GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE





-- 
Quelqu'un qui a commis des atrocités mérite la peine de mort. Ainsi, il
retiendra la leçon pour la prochaine fois.--- Britney Spears


signature.asc
Description: PGP signature

Bug#834854: jessie-pu: package charybdis/3.4.2-5~deb8u1

[Antoine Beaupré]

Control: tags -1 -moreinfo

On 2016-08-19 18:05:34, Antoine Beaupré wrote:
> On 2016-08-19 17:56:29, Adam D. Barratt wrote:
>> On Fri, 2016-08-19 at 17:35 -0400, Antoine Beaupré wrote:
>>> TL;DR: Charybdis 3.4 (Jessie) introduces a regression (CertFP broken)
>>> from Charybdis 3.3 (Wheezy). 7-line patch (attached) fixes the issue.
>>> 
>>> Charybdis 3.4 suffers from a regression which breaks authentication in
>>> certain scenarios. The bug is now documented upstream here:
>>> 
>>> https://github.com/charybdis-ircd/charybdis/pull/211
>> [...]
>>> I have produced a simple patch which fixes the issue for Charybdis 3.5
>>> here:
>>> 
>>> https://github.com/charybdis-ircd/charybdis/pull/211/commits/0ff0a0592de84dec2a2f46d9f8d6e22f6c1ee467
>>
>> That patch doesn't appear to have been applied to the package in
>> unstable. That's a pre-requisite for considering it for an update in
>> stable.
>
> Understood. I am waiting for upstream to release 3.5.3 which will
> include that patch, tonight, before doing a new upload.

Turns out this took about three weeks instead of 24h. But 3.5.3 is
released, and I will push the update to unstable now.

The situation is a tad more complicated now because there was a security
issue disclosed in the meantime:

https://security-tracker.debian.org/tracker/CVE-2016-7143

... which 3.5.3 fixes. I have prepared a deb8u2 update for the security
team in #836714, which the attached debdiff builds upon.

diff -Nru charybdis-3.4.2/debian/changelog charybdis-3.4.2/debian/changelog
--- charybdis-3.4.2/debian/changelog	2016-09-05 19:45:08.0 -0400
+++ charybdis-3.4.2/debian/changelog	2016-09-05 20:11:24.0 -0400
@@ -1,3 +1,10 @@
+charybdis (3.4.2-5+deb8u3) stable; urgency=medium
+
+  * backport patch from testing: fix error handling in gnutls certfp
+support
+
+ -- Antoine Beaupré   Mon, 05 Sep 2016 20:11:19 -0400
+
 charybdis (3.4.2-5+deb8u2) jessie-security; urgency=high
 
   * add fix for CVE-2016-7143, backported from upstream (Closes: #836714)
diff -Nru charybdis-3.4.2/debian/patches/0001-fix-error-handling-in-gnutls-certfp-support.patch charybdis-3.4.2/debian/patches/0001-fix-error-handling-in-gnutls-certfp-support.patch
--- charybdis-3.4.2/debian/patches/0001-fix-error-handling-in-gnutls-certfp-support.patch	1969-12-31 19:00:00.0 -0500
+++ charybdis-3.4.2/debian/patches/0001-fix-error-handling-in-gnutls-certfp-support.patch	2016-09-05 20:11:24.0 -0400
@@ -0,0 +1,41 @@
+Bug: https://github.com/charybdis-ircd/charybdis/pull/211
+
+will be factored into 3.5.3, so hold on before merging...
+
+From 0ff0a0592de84dec2a2f46d9f8d6e22f6c1ee467 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= 
+Date: Fri, 19 Aug 2016 11:53:59 -0400
+Subject: [PATCH] fix error handling in gnutls certfp support
+
+---
+ libratbox/src/gnutls.c | 13 ++---
+ 1 file changed, 6 insertions(+), 7 deletions(-)
+
+diff --git a/libratbox/src/gnutls.c b/libratbox/src/gnutls.c
+index f51211f..9bb69bb 100644
+--- a/libratbox/src/gnutls.c
 b/libratbox/src/gnutls.c
+@@ -608,18 +608,17 @@ rb_get_ssl_certfp(rb_fde_t *F, uint8_t certfp[RB_SSL_CERTFP_LEN], int method)
+ 	if (gnutls_certificate_type_get(SSL_P(F)) != GNUTLS_CRT_X509)
+ 		return 0;
+ 
+-	if (gnutls_x509_crt_init() < 0)
+-		return 0;
+-
+ 	cert_list_size = 0;
+ 	cert_list = gnutls_certificate_get_peers(SSL_P(F), _list_size);
+-	if (cert_list == NULL)
++	if (cert_list_size <= 0)
+ 	{
+-		gnutls_x509_crt_deinit(cert);
+ 		return 0;
+ 	}
+ 
+-	if (gnutls_x509_crt_import(cert, _list[0], GNUTLS_X509_FMT_DER) < 0)
++	if (gnutls_x509_crt_init() != GNUTLS_E_SUCCESS)
++		return 0;
++
++	if (gnutls_x509_crt_import(cert, _list[0], GNUTLS_X509_FMT_DER) != GNUTLS_E_SUCCESS)
+ 	{
+ 		gnutls_x509_crt_deinit(cert);
+ 		return 0;
diff -Nru charybdis-3.4.2/debian/patches/series charybdis-3.4.2/debian/patches/series
--- charybdis-3.4.2/debian/patches/series	2016-09-05 19:45:08.0 -0400
+++ charybdis-3.4.2/debian/patches/series	2016-09-05 20:11:24.0 -0400
@@ -7,3 +7,4 @@
 gnutls30
 libratbox-gnutls-add-gnutls-v3-api-compatibility-wit.patch
 CVE-2015-5290
+0001-fix-error-handling-in-gnutls-certfp-support.patch

I am running with those patches in production now.

Thanks and sorry for the delay.

A.

-- 
La propriété est un piège: ce que nous croyons posséder nous possède.
- Alphonse Karr

Bug#825840: localechooser: image display inverts red and blue color

[Samuel Thibault]

Control: reassign -1 linux

Mathieu Malaterre, on Mon 05 Sep 2016 07:26:15 +0200, wrote:
> Frame buffer device information:
> Name: OFfb ATY,RockHo
> Address : 0x9c008000
> Size: 614400
> Type: PACKED PIXELS
> Visual  : PSEUDOCOLOR

> Frame buffer device information:
> Name: ATI Radeon 5962
> Address : 0x9800
> Size: 33554432
> Type: PACKED PIXELS
> Visual  : PSEUDOCOLOR

Ok, so they look very similar. However, one thing that is different
is the way they handle FBIOPUTCMAP, i.e. offb_setcolreg(). ATY,RockHo
is not actually recognized by the offb driver, and it reverts to
"cmap_simple", which may not actually be the proper way for RockHo, and
it might very well be simply setting rgb in the wrong order.  You could
try to patch this over in there: turn

case cmap_simple:
writeb(regno, par->cmap_adr);
writeb(red, par->cmap_data);
writeb(green, par->cmap_data);
writeb(blue, par->cmap_data);
break;

into

case cmap_simple:
writeb(regno, par->cmap_adr);
writeb(blue, par->cmap_data);
writeb(green, par->cmap_data);
writeb(red, par->cmap_data);
break;

I really don't think it's a bterm bug, its only change of behavior is
when type or visual changes, which is not the case. It however does
use FBIOPUTCMAP, whose implementation does seem suspicious in offb for
RockHo.

Samuel

Bug#836782: Brian Bidulock has changed desktop files in GIT

[Frank McCormick]

Just to let you know that Brian Bidulock has changed the fields in

the desktop files in /usr/share/xsession  to "false" to allow lightdm to 
load


and display Icewm. I only have lightdm installed so I don't know

whether this mini-bug affects other display managers.

Bug#836804: evolution crashes when displaying any mail

[Jeff Burdges]

Package: evolution
Version: 3.12.9~git20141130.241663-1+b1
Severity: important


Evolution launches normally but if the user takes any action that would result 
in displaying an email, the it segfaults with the error :

(evolution:14698): GLib-GObject-CRITICAL **: g_object_ref: assertion 
'object->ref_count > 0' failed


/var/log/syslog contains messages like :
 kernel: [22296.533558] evolution[14698]: segfault at 0 ip 7fb52d12450a sp 
7fffe8f79b20 error 4 in libgobject-2.0.so.0.4906.0[7fb52d116000+51000]


The problem was caused by libglib2.0 being pulled in from testing somehow,
apt tooling could not detect or correct the problem because it did not
recognize the conflict with evolution.  Problem was solved by running 
dpkg -i  manually on :
libglib2.0-0_2.48.0-1~bpo8+1_amd64.deb
libglib2.0-bin_2.48.0-1~bpo8+1_amd64.deb
libglib2.0-dev_2.48.0-1~bpo8+1_amd64.deb



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

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

Versions of packages evolution depends on:
ii  dbus   1.8.20-0+deb8u1
ii  debconf [debconf-2.0]  1.5.56
ii  evolution-common   3.12.9~git20141130.241663-1
ii  evolution-data-server  3.12.9~git20141128.5242b0-2+deb8u2
ii  gnome-icon-theme   3.12.0-1
ii  libatk1.0-02.14.0-1
ii  libc6  2.19-18+deb8u4
ii  libcamel-1.2-493.12.9~git20141128.5242b0-2+deb8u2
ii  libclutter-gtk-1.0-0   1.6.0-1
ii  libecal-1.2-16 3.12.9~git20141128.5242b0-2+deb8u2
ii  libedataserver-1.2-18  3.12.9~git20141128.5242b0-2+deb8u2
ii  libevolution   3.12.9~git20141130.241663-1+b1
ii  libglib2.0-0   2.49.6-1
ii  libgtk-3-0 3.14.5-1+deb8u1
ii  libical1a  1.0-1.3
ii  libnotify4 0.7.6-2
ii  libsoup2.4-1   2.48.0-1
ii  libwebkitgtk-3.0-0 2.4.11-1~bpo8+1
ii  libxml22.9.1+dfsg1-5+deb8u2
ii  psmisc 22.21-2

Versions of packages evolution recommends:
ii  bogofilter 1.2.4+dfsg1-3+deb8u1
ii  evolution-plugins  3.12.9~git20141130.241663-1+b1
ii  yelp   3.14.1-1

Versions of packages evolution suggests:
pn  evolution-ews   
pn  evolution-plugins-experimental  
ii  gnupg   1.4.18-7+deb8u2
ii  network-manager 0.9.10.0-7

-- debconf information:
  evolution/kill_processes:
  evolution/needs_shutdown:

Bug#836714: security upload for Charybdis

[Antoine Beaupré]

Control: tags -1 +pending +patch
Hi,

This is a fix for a "certificate fingerprint spoofing through crafted
SASL messages" in Charybdis:

https://security-tracker.debian.org/tracker/CVE-2016-7143

I backported the patch from 3.5 to 3.4, it seems to apply, but I haven't
tested it directly.

Debdiff attached. Note that I restore the "+" separator for the deb8uX
version as 3.4 is not in stretch anymore, so there's no risk of a failed
upgrade. It felt confusing to keep X=1 so I bumped the release number to
3.4.2-5+deb8u2.

diff -Nru charybdis-3.4.2/debian/changelog charybdis-3.4.2/debian/changelog
--- charybdis-3.4.2/debian/changelog	2015-11-19 13:58:01.0 -0500
+++ charybdis-3.4.2/debian/changelog	2016-09-05 19:45:08.0 -0400
@@ -1,3 +1,9 @@
+charybdis (3.4.2-5+deb8u2) jessie-security; urgency=high
+
+  * add fix for CVE-2016-7143, backported from upstream (Closes: #836714)
+
+ -- Antoine Beaupré   Mon, 05 Sep 2016 19:41:12 -0400
+
 charybdis (3.4.2-5~deb8u1) stable; urgency=high
 
   * switch to new anonscm hostnames
diff -Nru charybdis-3.4.2/debian/patches/sasl-spoofing-836714.patch charybdis-3.4.2/debian/patches/sasl-spoofing-836714.patch
--- charybdis-3.4.2/debian/patches/sasl-spoofing-836714.patch	1969-12-31 19:00:00.0 -0500
+++ charybdis-3.4.2/debian/patches/sasl-spoofing-836714.patch	2016-09-05 19:45:08.0 -0400
@@ -0,0 +1,28 @@
+From 818a3fda944b26d4814132cee14cfda4ea4aa824 Mon Sep 17 00:00:00 2001
+From: Aaron Jones 
+Date: Sat, 3 Sep 2016 17:28:41 +
+Subject: [PATCH] SASL: Disallow beginning : and space anywhere in AUTHENTICATE
+ parameter
+
+This is a FIX FOR A SECURITY VULNERABILITY. All Charybdis users must
+apply this fix if you support SASL on your servers, or unload m_sasl.so
+in the meantime.
+---
+ modules/m_sasl.c | 6 ++
+ 1 file changed, 6 insertions(+)
+
+--- a/modules/m_sasl.c
 b/modules/m_sasl.c
+@@ -83,6 +83,12 @@ mr_authenticate(struct Client *client_p,
+ 		return 0;
+ 	}
+ 
++	if (*parv[1] == ':' || strchr(parv[1], ' '))
++	{
++		exit_client(client_p, client_p, client_p, "Malformed AUTHENTICATE");
++		return 0;
++	}
++
+ 	if(source_p->preClient->sasl_complete)
+ 	{
+ 		sendto_one(source_p, form_str(ERR_SASLALREADY), me.name, EmptyString(source_p->name) ? "*" : source_p->name);
diff -Nru charybdis-3.4.2/debian/patches/series charybdis-3.4.2/debian/patches/series
--- charybdis-3.4.2/debian/patches/series	2015-11-19 13:58:01.0 -0500
+++ charybdis-3.4.2/debian/patches/series	2016-09-05 19:45:08.0 -0400
@@ -1,3 +1,4 @@
+sasl-spoofing-836714.patch
 fix-paths
 ircd.conf.patch
 non-static-sqlite

I am running the resulting .deb in production, and am ready to upload
when confirmation is received.

A.

-- 
We all pay for life with death, so everything in between should be
free.
 - Bill Hicks

Bug#836224: gnome-shell-extension-taskbar: Please set dependency relationship for gnome-shell versions

[Jeremy Bicha]

Actually, to be compatible with gnome-shell currently in unstable,
you'll need to add this to your metadata.json:

"3.21.91", "3.21.92", "3.22"

Thanks,
Jeremy Bicha

Bug#836772: [pkg-gnupg-maint] Bug#836772: gnupg: unable to sign anyone's keys

[Daniel Kahn Gillmor]

Control: tags 836772 + moreinfo
Control: retitle 836772 gnupg: pinentry returns permission denied

Hi Ramakrishnan--

Thanks for the detailed report!

On Mon 2016-09-05 11:24:52 -0400, Ramakrishnan Muthukrishnan wrote:
> rkrishnan@ken:~$ gpg --sign-key ben
>
> pub  rsa4096/E7BFC8EC95861109
>  created: 2009-07-12  expires: never   usage: SC  
>  trust: unknown   validity: unknown
> sub  rsa4096/CF0469521357C3D7
>  created: 2009-07-12  expires: never   usage: E   
> [ unknown] (1). Ben Hutchings (DOB: 1977-01-11)
> [ unknown] (2)  Ben Hutchings 
> [ unknown] (3)  Ben Hutchings 
>
> Really sign all text user IDs? (y/N) y
> gpg: using "EB46CA9A" as default secret key for signing
>
> pub  rsa4096/E7BFC8EC95861109
>  created: 2009-07-12  expires: never   usage: SC  
>  trust: unknown   validity: unknown
>  Primary key fingerprint: AC2B 29BD 34A6 AFDD B3F6  8F35 E7BF C8EC 9586
>  1109
>
>  Ben Hutchings (DOB: 1977-01-11)
>  Ben Hutchings 
>  Ben Hutchings 
>
> Are you sure that you want to sign this key with your
> key "Ramakrishnan Muthukrishnan "
> (CF64CD61EB46CA9A)
>
> Really sign? (y/N) y
> gpg: signing failed: Permission denied
> gpg: signing failed: Permission denied
>
> Key not changed so no update needed.
 [...]
> write(7, "PKSIGN", 6)   = 6
> write(7, "\n", 1)   = 1
> read(7, "INQUIRE PINENTRY_LAUNCHED 31248\n", 1002) = 32
> write(7, "END", 3)  = 3
> write(7, "\n", 1)   = 1
> read(7, "ERR 83918849 Permission denied <"..., 1002) = 42

This suggests that the problem you're seeing is pinentry rejecting your
signature.  What version(s) of pinentry do you have installed and what
is your default?

   dpkg -l 'pinentry-*'
   readlink -f $(which pinentry)
   grep -i pinentry ~/.gnupg/*.conf

Is all your work being done within an X11 session, or are you connecting
to this machine via ssh or a text-mode terminal?  if X11, what graphical
environment are you using (e.g. gnome, kde, etc)?

--dkg


signature.asc
Description: PGP signature

Bug#825840: localechooser: image display inverts red and blue color

[Samuel Thibault]

Samuel Thibault, on Tue 06 Sep 2016 01:10:07 +0200, wrote:
> BTW, are only the blue and red colors inverted, or are some other colors
> (black, white, gray) inverted too?

An actual screen shot would be welcome to make sure how colors get
mangled precisely.

Samuel

Bug#825840: localechooser: image display inverts red and blue color

[Samuel Thibault]

BTW, are only the blue and red colors inverted, or are some other colors
(black, white, gray) inverted too?

Samuel

Bug#836803: please use modules for mobile users from new prosody-modules backport

[W. Martin Borgert]

Package: rtc.debian.org
Severity: wishlist

There is a new backport of prosody-modules with modules esp.
interesting for mobile users. Please install the new version
and enable the modules for MAM and CSI, maybe also HTTP Upload.
See https://bugs.debian.org/826271 for the reasoning.

Thanks!

Bug#785799: [festvox-ca-ona-hts] Since las festival upgrade, catalan voice is not correctly recognized and does not work

[Sergio Oller]

Hi,

I have just committed changes to address your comments and I have uploaded
the package again to mentors:

Again, you can fetch the package using:

dget -x 
https://mentors.debian.net/debian/pool/main/f/festvox-ca-ona-hts/festvox-ca-ona-hts_1.3-1.dsc

Further info is available here:

 https://mentors.debian.net/package/festvox-ca-ona-hts


Comments to your review follow here:

2016-09-05 23:32 GMT+02:00 Guillem Jover :

Sure! Here's the review, please:
>
>  * Document changes for Vcs-* fields.

 * Document dependency version bumps and additions.
>
 * Minor stylistic nit, add a space between the >= and the version. :)
>

All these three have been fixed.


>  * The copyright years and holders might need an update?
>

I have updated the copyright years and holders for the files that have
changed among versions.


>  * I have no clue how these voices work internally so you'll have
>to give me a hand here. What's the source for upc_ca_ona.htsvoice?
>How do you generate that? Do we have the tools to do so in Debian?
>Otherwise we might need to put this in contrib. :/
>

I would understand moving the package to contrib if that is where it
belongs.

There is a summarised description of the process of generating the htsvoice
file in the README.source file. Basically, the htsvoice file contains the
voice model (so no "code", just "data").

To generate this model, we used around 3 weeks of computer processing power
and up to 5GB of RAM in some parts of the process. I don't think it makes
much sense to regenerate it in Debian.

Apart from the computer power, you will need the recordings with their
phonetic segmentation. For this model, they can be downloaded from
http://festcat.talp.cat/download/data, distributed with a CC-BY-SA license
(the recordings are almost 1GB large). You will also need some tools, all
but one of them are free. The one that is non-free is called HTK. It can be
downloaded gratis and is open-source but is non-free because it is not
redistributable. You can see the license terms here:
http://htk.eng.cam.ac.uk/docs/license.shtml.


Other packages (such as festlex-poslex) do provide trained models without
the training the data from scratch and are in main. I found a thread
https://lists.debian.org/debian-legal/2009/05/msg00028.html where a similar
case is discussed, but I did not see a final consensus on the issue. Also,
the ftp masters authorised the previous upload of this package.

I (as part of upstream) cannot improve the situation for the htsvoice
models as we don't have the resources to develop a fully free alternative
to HTK. Providing the raw data should allow anyone to train better models
and it is already more than what other packages have done.



>  * The package is pretty much lintian clean, except for a pedantic
>tag about missing an upstream changelog, which we can ignore.
>
> I've built and tested these and they work fine, thanks!
>

Cool!


>
> > In the past it was a bit hard to find a sponsor and knowing that I had to
> > go through the process of finding one was demotivating me a bit.
>
> Please feel free to contact me anytime you need a sponsor, at least for
> any Catalan related package. In case I'm not responsive you could also
> try the debian-l10n-cata...@lists.debian.org mailing list, or just Cc
> it when you mail me. :)


Thanks, I will do that for sure!

Sergio

Bug#836802: gdb: Process record does not support instruction 0xc5

[mudongliang]

Package: gdb
Version: 7.11.1-2
Severity: normal
Tags: newcomer

Dear Maintainer,

$ cat simple.c

#include 
void foo (char *bar)
{
char  c[12];

strcpy(c, bar);  // no bounds checking
}
int main (int argc, char **argv)
{
foo(argv[1]);
}

$ gdb simple
..
(gdb) b main
Breakpoint 1 at 0x40050c
(gdb) r
Starting program: /home/mudongliang/Work/simple

Breakpoint 1, 0x0040050c in main ()
(gdb) record full
(gdb) c
Continuing.
Process record does not support instruction 0xc5 at address 0x77dee807.
Process record: failed to record execution log.

Program stopped.
_dl_runtime_resolve_avx () at ../sysdeps/x86_64/dl-trampoline.h:81
81  ../sysdeps/x86_64/dl-trampoline.h: No such file or directory.



-- 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/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: systemd (via /run/systemd/system)

Versions of packages gdb depends on:
ii  libbabeltrace-ctf1  1.4.0-3
ii  libbabeltrace1  1.4.0-3
ii  libc6   2.23-5
ii  libexpat1   2.2.0-1
ii  liblzma55.1.1alpha+20120614-2.1
ii  libncurses5 6.0+20160625-1
ii  libpython3.53.5.2-4
ii  libreadline66.3-8+b4
ii  libtinfo5   6.0+20160625-1
ii  zlib1g  1:1.2.8.dfsg-2+b1

Versions of packages gdb recommends:
ii  gdbserver 7.11.1-2
ii  libc6-dbg [libc-dbg]  2.23-5

Versions of packages gdb suggests:
pn  gdb-doc  

-- no debconf information

Bug#775708: po4a: Please add support for new gettext --add-location option

[Martin Quinson]

Hello,

I'm trying to restart the maintainance of po4a after a very quiet
period, but I would welcome any help that you could be willing to
give.

As your bug notices, the support for the --porefs option is somehow
broken in our tools. Your patch goes in the right direction, and I'd
really appreciate if you could complete it by also fixing
po4a-updatepo, and maybe adding a test or two of this behavior.

I'm perfectly fine with depending on more recent versions of gettext,
and I would not be too concerned if the backward compatibility of how
locations are generated would not be fully respected.

The location lines are very useful to the translators, but they don't
really care of whether they change when they rerun the tool, do they?

Thanks for your help,
Mt.


signature.asc
Description: PGP signature

Bug#835800: transmission: FTBFS with openssl 1.1.0

[Sandro Tosi]

On Mon, Sep 5, 2016 at 10:59 PM, Sebastian Andrzej Siewior
 wrote:
> control: tags -1 patch

thanks for the patch, against which version is this based on? 2.92
reached unstable after this bug was filed

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#835542: flex: comparison between signed and unsigned integer expressions

[Frank Heckenbach]

Hi,

> On Sat, Sep 03, 2016 at 10:57:13PM +0200, Frank Heckenbach wrote:
> >
> > Will this fix be pushed by security.debian.org as well now, or will
> > I have to install it manually?
> 
> It will be pushed via security.debian.org archive "soon", since we
> have not confirmation. It's not intended that you will have to fix
> those manually on your machines. We will issue a follow-up DSA for it.
> 
> > I'm asking because I'm involved with a number of machines that
> > probably all have gotten the bad update by now, if I have to patch
> > them all myself now. (I'm also asking because I found another bug in
> > a security update of another package, incidentally on the same day
> > as this one?!) What's the usual procedure for non-security bugs
> > introduced by security updates? (Couldn't find anything about it on
> > the web site.)
> 
> I guess it is about a regression in the imagemagick update? If so it's
> as well already on security team's radar, and we will need to issue a
> regression update for that (there are filled bugs for those, e.g.
> #835488, #835650, #836189).

Yes, I meant this one (#835650 is from me).

Thanks for the info. I'll await the updates then.

Frank

Bug#835677: remctl: FTBFS: dh_auto_test: make -j1 check VERBOSE=1 returned exit code 2

[Russ Allbery]

Lucas Nussbaum  writes:

> That's strange.

> What the script sees is:
> # ./runtests -o server/shell-misc-t
> 1..15
> ok 1 - no REMCTL_USER
> ok 2 - no SSH_CONNECTION
> ok 3 - value for REMUSER
> ok 4 - value for REMOTE_USER
> ok 5 - value for REMOTE_ADDR
> ok 6 - value for REMOTE_EXPIRES
> ok 7 - return status for REMOTE_HOST
> # env REMOTE_HOST: ip-172-31-8-210.eu-central-1.compute.internal
> not ok 8 - value for REMOTE_HOST
> ok 9 - file descriptors closed properly on server

> However:
> # cat /etc/hosts
> 127.0.0.1 ip-172-31-8-210.eu-central-1.compute.internal localhost

> And:
> # host 127.0.0.1
> 1.0.0.127.in-addr.arpa domain name pointer localhost.

host will always query DNS.  To simulate the results of getaddrinfo, you
have to use getent hosts 127.0.0.1.

Thanks, that explains it!  The local hostname is listed before localhost
in /etc/hosts, so it's going to return that.  That means my fix to check
against the value of `hostname` will fix the test.

-- 
Russ Allbery (r...@debian.org)   

Bug#836706: certificate spoofing via crafted SASL messages

[Guillaume Delacour]

Le 05/09/2016 à 22:41, James Lu a écrit :
> Hi,

Hi,

> 
> Just to narrow things down a bit, the relevant fix for InspIRCd 2.0 is
> this commit
> https://github.com/inspircd/inspircd/commit/74fafb7f11b06747f69f182ad5e3769b665eea7a

Yes, i've talked to upstream a few hours ago to include this particular
fix to 2.0.17; upload of 2.0.23 will follow to unstable.

> 
> Best,
> James
> 

-- 
Guillaume Delacour



signature.asc
Description: OpenPGP digital signature

Bug#835800: transmission: FTBFS with openssl 1.1.0

[Sebastian Andrzej Siewior]

control: tags -1 patch
control: forwarded -1 https://github.com/transmission/transmission/pull/24

On 2016-08-28 13:59:30 [+0200], Kurt Roeckx wrote:
> Experimental has the libssl-dev 1.1.0 packages in it. I suggest
> you try building against that to see if everything works.

builds.

> Kurt

Sebastian
>From 9978fb6970420bcaab9f60c544b6a369c5638ce2 Mon Sep 17 00:00:00 2001
From: Sebastian Andrzej Siewior 
Date: Mon, 5 Sep 2016 21:49:07 +
Subject: [PATCH] transmission: build against openssl 1.1.0

Signed-off-by: Sebastian Andrzej Siewior 
---
 libtransmission/crypto-utils-openssl.c | 65 +++---
 1 file changed, 61 insertions(+), 4 deletions(-)

diff --git a/libtransmission/crypto-utils-openssl.c b/libtransmission/crypto-utils-openssl.c
index c4539dccb42e..19144d3535e8 100644
--- a/libtransmission/crypto-utils-openssl.c
+++ b/libtransmission/crypto-utils-openssl.c
@@ -229,6 +229,53 @@ tr_rc4_process (tr_rc4_ctx_t   handle,
 
 ***/
 
+#if OPENSSL_VERSION_NUMBER < 0x1010
+static inline int DH_set0_pqg(DH *dh, BIGNUM *p, BIGNUM *q, BIGNUM *g)
+{
+	/* If the fields p and g in d are NULL, the corresponding input
+	 * parameters MUST be non-NULL.  q may remain NULL.
+	 */
+	if ((dh->p == NULL && p == NULL)
+	|| (dh->g == NULL && g == NULL))
+		return 0;
+
+	if (p != NULL) {
+		BN_free(dh->p);
+		dh->p = p;
+	}
+	if (q != NULL) {
+		BN_free(dh->q);
+		dh->q = q;
+	}
+	if (g != NULL) {
+		BN_free(dh->g);
+		dh->g = g;
+	}
+
+	if (q != NULL) {
+		dh->length = BN_num_bits(q);
+	}
+
+	return 1;
+}
+
+static inline int DH_set_length(DH *dh, long length)
+{
+	dh->length = length;
+	return 1;
+}
+
+static inline void DH_get0_key(const DH *dh, const BIGNUM **pub_key,
+			   const BIGNUM **priv_key)
+{
+	if (pub_key != NULL)
+		*pub_key = dh->pub_key;
+	if (priv_key != NULL)
+		*priv_key = dh->priv_key;
+}
+
+#endif
+
 tr_dh_ctx_t
 tr_dh_new (const uint8_t * prime_num,
size_t  prime_num_length,
@@ -236,13 +283,19 @@ tr_dh_new (const uint8_t * prime_num,
size_t  generator_num_length)
 {
   DH * handle = DH_new ();
+  BIGNUM *p, *g;
 
   assert (prime_num != NULL);
   assert (generator_num != NULL);
+  p = BN_bin2bn (prime_num, prime_num_length, NULL);
+  g = BN_bin2bn (generator_num, generator_num_length, NULL);
 
-  if (!check_pointer (handle->p = BN_bin2bn (prime_num, prime_num_length, NULL)) ||
-  !check_pointer (handle->g = BN_bin2bn (generator_num, generator_num_length, NULL)))
+  if (!check_pointer (p) ||
+  !check_pointer (g) ||
+  !DH_set0_pqg (handle, p, NULL, g))
 {
+  BN_free(p);
+  BN_free(g);
   DH_free (handle);
   handle = NULL;
 }
@@ -267,16 +320,20 @@ tr_dh_make_key (tr_dh_ctx_t   raw_handle,
 {
   DH * handle = raw_handle;
   int dh_size, my_public_key_length;
+  const BIGNUM *hand_pub_key;
 
   assert (handle != NULL);
   assert (public_key != NULL);
 
-  handle->length = private_key_length * 8;
+
+  DH_set_length(handle, private_key_length * 8);
 
   if (!check_result (DH_generate_key (handle)))
 return false;
 
-  my_public_key_length = BN_bn2bin (handle->pub_key, public_key);
+  DH_get0_key(handle, _pub_key, NULL);
+
+  my_public_key_length = BN_bn2bin (hand_pub_key, public_key);
   dh_size = DH_size (handle);
 
   tr_dh_align_key (public_key, my_public_key_length, dh_size);
-- 
2.9.3

Bug#836801: rdtool: rd2man-lib.rb crashes on MethodListItem

[Francesco Poli (wintermute)]

Package: rdtool
Version: 0.6.38-4
Severity: important

Hello and thanks for maintaining rdtool in Debian!

I think I found a bug in rd2man-lib.rb .
Steps to reproduce with the attached trivial Ruby Document file:

  $ rd2 -r rd/rd2html-lib.rb -o bar bar.rd

Everything's fine. The resulting HTML file looks OK:

  $ sensible-browser bar.html

But, if I want to get a man page:

  $ rd2 -r rd/rd2man-lib.rb -o bar bar.rd
  /usr/lib/ruby/vendor_ruby/rd/rd2man-lib.rb:127:in `apply_to_MethodListItem': 
undefined method `join' for "bar#run()":String (NoMethodError)
  from /usr/lib/ruby/vendor_ruby/rd/visitor.rb:64:in 
`visit_MethodListItem'
  from /usr/lib/ruby/vendor_ruby/rd/methodlist.rb:25:in `accept'
  from /usr/lib/ruby/vendor_ruby/rd/visitor.rb:20:in `block in 
visit_children'
  from /usr/lib/ruby/vendor_ruby/rd/element.rb:50:in `block in 
each_child'
  from /usr/lib/ruby/vendor_ruby/rd/element.rb:49:in `each'
  from /usr/lib/ruby/vendor_ruby/rd/element.rb:49:in `each_child'
  from /usr/lib/ruby/vendor_ruby/rd/visitor.rb:19:in `visit_children'
  from (eval):2:in `visit_MethodList'
  from /usr/lib/ruby/vendor_ruby/rd/methodlist.rb:9:in `accept'
  from /usr/lib/ruby/vendor_ruby/rd/visitor.rb:20:in `block in 
visit_children'
  from /usr/lib/ruby/vendor_ruby/rd/element.rb:50:in `block in 
each_child'
  from /usr/lib/ruby/vendor_ruby/rd/element.rb:49:in `each'
  from /usr/lib/ruby/vendor_ruby/rd/element.rb:49:in `each_child'
  from /usr/lib/ruby/vendor_ruby/rd/visitor.rb:19:in `visit_children'
  from (eval):2:in `visit_DocumentElement'
  from /usr/lib/ruby/vendor_ruby/rd/element.rb:151:in `accept'
  from /usr/lib/ruby/vendor_ruby/rd/tree.rb:79:in `accept'
  from /usr/lib/ruby/vendor_ruby/rd/visitor.rb:14:in `visit'
  from /usr/lib/ruby/vendor_ruby/rd/rd2man-lib.rb:39:in `visit'
  from /usr/bin/rd2:247:in `'

and no output is obtained.

Is there anything I failed to understand?

If this is indeed a bug in rd2man-lib.rb, please investigate the issue
and fix it, and/or forward my bug report upstream.

Thanks for your time.
Bye.


P.S.: I think the attached test case is so trivial that it is not copyrighted.
  Hence no license should be needed, for the file to be copied, modified,
  and/or distributed. Anyway, should this turn out to be false, I hereby
  grant premission to deal with the file under the terms of the Expat/MIT
  license 


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

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 rdtool depends on:
ii  ruby 1:2.3.0+4
ii  ruby-rd  0.6.38-4

rdtool recommends no packages.

rdtool suggests no packages.

-- no debconf information


bar.rd.gz
Description: application/gzip

Bug#836800: ITP: espeak-ng -- Multi-lingual software speech synthesizer

[Samuel Thibault]

Package: wnpp
Severity: wishlist
Owner: Samuel Thibault 

* Package name: espeak-ng
  Version : git snapshot
  Upstream Author : Reece H. Dunn 
* URL : https://github.com/espeak-ng/espeak-ng
* License : GPL
  Programming Lang: C++
  Description : Multi-lingual software speech synthesizer

eSpeak NG is a fork of espeak, which is currently unmaintained.  It
is API and ABI compatible with espeak, thus making it a drop-in
replacement, while providing fixes in source code and voices.

Bug#836246: libgtk-3-0: Upgrade from 3.20.9 to 3.21.5 broke Mate desktop

[Jeremy Bicha]

Control: severity -1 serious

I'm bumping the severity because I don't think we want GTK 3.21 in testing yet.

I don't think this will block most of the GNOME 3.21/3.22 transition
since most of the components don't need GTK 3.21.

Thanks,
Jeremy Bicha

Bug#836793: [apt-listbugs] [PATCH] Display Debian BTS URLs when listing bugs

[Keshav Kini]

On 09/05/2016 04:33 PM, Francesco Poli wrote:
> On Mon, 5 Sep 2016 14:50:34 -0500 Keshav Kini wrote:
> 
> [...]
>> Please find attached a small patch for apt-listbugs, which causes it to
>> print links to bugs.debian.org when listing bugs.
> 
> Hello Keshav,
> thanks for your bug report and for the patch!
> 
> To be honest, I have to say that this patch adds very little
> information to the output of apt-listbugs, while making it longer.
> 
> After all, with the current apt-listbugs, it's just a matter of taking
> the bug number #XX and building the URL
> ...
> 
> If you use firefox with package xul-ext-debianbuttons, it's just a
> matter of selecting the bug number and clicking on a button in your
> browser interface, which is even easier and quicker...
> 
> I don't know how useful the additional output could be regarded by the
> majority of the users. I have to think about it: maybe I can implement
> an option to display the URL in stead of the bug number. But maybe it
> would be an overkill...
> 
> I'll let you know, once I make up my mind.

My reasoning was that new users might not know where to go.  But I guess
new users would probably not be using apt-listbugs in the first place
(though personally I think everyone should use it).

Anyway, it was just an idea I had :)  And since it seemed easy to make a
patch, I made one in a few minutes.  Feel free to throw it away.

> Anyway, whatever I decide, thanks for using apt-listbugs and for caring
> about it.

Thank you for maintaining it!  I always recommend it to friends who
start using Debian.

-Keshav



signature.asc
Description: OpenPGP digital signature

Bug#836799: transition: ros-geometric-shapes

[Jochen Sprickerhof]

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

Hi,

ros-geometric-shapes got a small ABI change I would like to transition. Only
ros-robot-model is affected, which is also maintained by me.

Cheers Jochen

Ben file:

title = "ros-geometric-shapes";
is_affected = .depends ~ /\b(libgeometric\-shapes0d)\b/ | .depends ~ 
/\b(libgeometric\-shapes1d)\b/;
is_good = .depends ~ /\b(libgeometric\-shapes1d)\b/;
is_bad = .depends ~ /\b(libgeometric\-shapes0d)\b/;


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

Kernel: Linux 4.6.0-1-amd64 (SMP w/12 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: sysvinit (via /sbin/init)

Bug#828594: virtuoso-opensource: FTBFS with openssl 1.1.0

[Kurt Roeckx]

On Mon, Sep 05, 2016 at 10:02:43PM +0200, Sebastian Andrzej Siewior wrote:
> On 2016-06-26 12:24:41 [+0200], Kurt Roeckx wrote:
> > If you have problems making things work, feel free to contact us.
> 
> The patch attached fixes most of it.
> There are a few des ??? DES conversations like des_cblock ??? DES_cblock or
> des_key_schedule ??? DES_key_schedule or des_ede3_cbc_encrypt ???
> DESede3_cbc_encrypt which I hope are okay.
> There are M_ASN1_INTEGER_free ??? ASN1_STRING_free which I also hope that
> those are okay. That part where I replaced d2i_ASN1_BOOLEAN() looks like
> they copied it from old openssl code.
> There are a few #if HALP blocks which I simply don't know what should
> happen in there. If HALP is turned into 0 then it compiles.

I'll try to take a look at it soon.


Kurt

Bug#798509: owncloud-client: 100% CPU load all the time

[Juha Jäykkä]

Package: owncloud-client
Version: 2.2.2+dfsg-1
Followup-For: Bug #798509

Dear Maintainer,

Just to confirm this but "still" appears in 2.2.2+dfsg-1. In fact, it
only just appeared after latest upgrade, but as I am a bit lazy in upgradin
my sid systems, I have no idea what the previous version was. It was
certainly newer than the original reporter's version.

I tried running owncloud under strace but then it suddenly behaves normally,
so could not even find out WHAT it is doing consuming all my cpu.

Cheers,
Juha

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

Kernel: Linux 4.7.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_GB.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages owncloud-client depends on:
ii  libc6 2.24-1
ii  libgcc1   1:6.2.0-2
ii  libowncloudsync0  2.2.2+dfsg-1
ii  libqt5core5a  5.6.1+dfsg-3+b1
ii  libqt5dbus5   5.6.1+dfsg-3+b1
ii  libqt5gui55.6.1+dfsg-3+b1
ii  libqt5keychain0   0.5.0-1
ii  libqt5network55.6.1+dfsg-3+b1
ii  libqt5sql5-sqlite 5.6.1+dfsg-3+b1
ii  libqt5webkit5 5.6.1+dfsg-5
ii  libqt5widgets55.6.1+dfsg-3+b1
ii  libqt5xml55.6.1+dfsg-3+b1
ii  libssl1.0.2   1.0.2h-1
ii  libstdc++66.2.0-2
ii  owncloud-client-l10n  2.2.2+dfsg-1

owncloud-client recommends no packages.

owncloud-client suggests no packages.

-- no debconf information

Bug#836592: jessie-pu: package gdcm/2.4.4-3

[Adam D. Barratt]

Control: tags -1 + pending

On Sun, 2016-09-04 at 18:13 +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Sun, 2016-09-04 at 13:14 +0200, Gert Wollny wrote:
> > The version of gdcm in jessie suffers from two security problems:
> > 
> >   CVE-2015-8396 [1]
> >   CVE-2015-8397 [2]
> > 
> > However, the security team notified my that the issue does not warrant a DSA
> > and I should instead just fix it via a jessie point release.
> > 
> > The proposed patch against the package is enclosed, it adds the according 
> > fixes
> > from the upstream repository.
> 
> +gdcm (2.4.4-3+deb8u1) jessie-proposed-updates; urgency=medium
> 
> Simply "jessie" is preferred.
> 
> Please go ahead.

Uploaded and flagged for acceptance.

Regards,

Adam

Bug#785799: [festvox-ca-ona-hts] Since las festival upgrade, catalan voice is not correctly recognized and does not work

[Guillem Jover]

Hi!

On Mon, 2016-09-05 at 23:04:51 +0200, Sergio Oller wrote:
> I have been working this summer to get the new upstream version of this
> package and after some testing it seems it works fine, so I just uploaded
> its package to mentors. Could you please sponsor it?

Sure! Here's the review, please:

 * Document changes for Vcs-* fields.
 * Document dependency version bumps and additions.
 * Minor stylistic nit, add a space between the >= and the version. :)
 * The copyright years and holders might need an update?
 * I have no clue how these voices work internally so you'll have
   to give me a hand here. What's the source for upc_ca_ona.htsvoice?
   How do you generate that? Do we have the tools to do so in Debian?
   Otherwise we might need to put this in contrib. :/
 * The package is pretty much lintian clean, except for a pedantic
   tag about missing an upstream changelog, which we can ignore.

I've built and tested these and they work fine, thanks!

> In the past it was a bit hard to find a sponsor and knowing that I had to
> go through the process of finding one was demotivating me a bit.

Please feel free to contact me anytime you need a sponsor, at least for
any Catalan related package. In case I'm not responsive you could also
try the debian-l10n-cata...@lists.debian.org mailing list, or just Cc
it when you mail me. :)

Thanks,
Guillem

Bug#836793: [apt-listbugs] [PATCH] Display Debian BTS URLs when listing bugs

[Francesco Poli]

On Mon, 5 Sep 2016 14:50:34 -0500 Keshav Kini wrote:

[...]
> Please find attached a small patch for apt-listbugs, which causes it to
> print links to bugs.debian.org when listing bugs.

Hello Keshav,
thanks for your bug report and for the patch!

To be honest, I have to say that this patch adds very little
information to the output of apt-listbugs, while making it longer.

After all, with the current apt-listbugs, it's just a matter of taking
the bug number #XX and building the URL
...

If you use firefox with package xul-ext-debianbuttons, it's just a
matter of selecting the bug number and clicking on a button in your
browser interface, which is even easier and quicker...

I don't know how useful the additional output could be regarded by the
majority of the users. I have to think about it: maybe I can implement
an option to display the URL in stead of the bug number. But maybe it
would be an overkill...

I'll let you know, once I make up my mind.

Anyway, whatever I decide, thanks for using apt-listbugs and for caring
about it.

Bye.


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgp46eR5p3KcS.pgp
Description: PGP signature

Bug#827054: jessie-pu: package openssl/1.0.1t-1+deb8u3

[Adam D. Barratt]

Control: tags -1 + pending

On Sun, 2016-09-04 at 18:01 +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Tue, 2016-08-23 at 21:47 +0200, Kurt Roeckx wrote:
> > The current debdiff we'd like to upload is:
> > diff -Nru openssl-1.0.1t/debian/changelog openssl-1.0.1t/debian/changelog
> > --- openssl-1.0.1t/debian/changelog 2016-05-15 21:16:55.0 +0200
> > +++ openssl-1.0.1t/debian/changelog 2016-06-11 19:18:11.0 +0200
> > @@ -1,3 +1,14 @@
> > +openssl (1.0.1t-1+deb8u3) jessie; urgency=medium
> > +
> > +  [ Kurt Roeckx ]
> > +  * Fix length check for CRLs. (Closes: #826552)
> > +
> > +  [ Sebastian Andrzej Siewior ]
> > +  * Enable asm optimisation for s390x. Patch by Dimitri John Ledkov.
> > +(Closes: #833156).
> 
> Please go ahead.

Uploaded and flagged for acceptance.

Regards,

Adam

Bug#836787: jessie-pu: package pypdf2/1.23+git20141008-1+deb8u1

[Adam D. Barratt]

Control: tags -1 + pending

On Mon, 2016-09-05 at 19:59 +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Mon, 2016-09-05 at 20:06 +0200, Laszlo Boszormenyi (GCS) wrote:
> > A PyPDF2 user found a DoS, an infinite loop[1]. It has a reproducer
> > even. This affects Jessie as well (the Sid update is just uploaded).
> > Upstream fix is simple[2] and the Security Team noted this as no-dsa,
> > but can be updated via a Jessie PU.
> 
> Please go ahead.

Uploaded and flagged for acceptance.

Regards,

Adam

Bug#818926: perl6-panda: panda doesn't start up / find needed libraries

[gregor herrmann]

On Thu, 24 Mar 2016 11:50:56 +0100, Dominique Dumont wrote:

> On Wed, 23 Mar 2016 17:01:14 +0100 Dominique Dumont  wrote:
> > From what I've understood, distro packaging is not a feature of Panda. Some 
> > other tool must be developed by upstream. I'll follow what's going on there.
> 
> First stab at install tool is:
> https://gist.github.com/niner/8ad4cbefde16d9494e16
> 
> I'm going to test it for simple modules like JSON::Fast

Maybe zef is in option:
https://github.com/ugexe/zef

--install-to= # site/home/vendor/perl
sounds nice
(or -to="inst#/home/perl6/custom" for the package build)

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: Captain Jack: Holiday


signature.asc
Description: Digital Signature

Bug#833727: emacs24: FTBFS with glibc 2.24

[Aurelien Jarno]

On 2016-09-05 14:58, Rob Browning wrote:
> Aurelien Jarno  writes:
> 
> > Yes, the 0020-Always-define-gmalloc-etc.-in-src-gmalloc.c.patch actually
> > comes from upstream commit 4b1436b702d56eedd27a0777fc7232cdfb7ac4f6.
> 
> Ahh, yes, quite close, so I think this may be sufficient:
> 
>   Author: Wolfgang Jenkner 
>   Date:   Sat Dec 26 12:12:02 2015 -0800
> 
> Emacs should work with gcc 5.2 and newer
> 
> This patch, backported from upstream by Aurelien Jarno
> , has been added:
> 
>   Always define gmalloc etc. in src/gmalloc.c
> 
>   This is a work-around to prevent the compiler from using semantic
>   knowledge about malloc for optimization purposes.  E.g., gcc 5.2
>   with -O2 replaces most of calloc's definition by a call to calloc;
>   see Bug#22085.
>   * src/gmalloc.c [!HYBRID_MALLOC] (malloc, realloc, calloc)
>   (aligned_alloc, free): Do not undef.  Instead, define these as
>   functions (perhaps renamed to gmalloc etc.) in terms of gmalloc etc.
> 
> Origin: backport, commit: 4b1436b702d56eedd27a0777fc7232cdfb7ac4f6
> Bug-Debian: http://bugs.debian.org/833727

That looks fine.

> ...and for the glibc patch, this looks like the origin:
> e95b023163e96538b15f030b7176b7ec59cf86f5

Indeed, I confirm.

Aurelien

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

Bug#836611: Possibly related issue

[Jeremy Lainé]

I am having the same problem, and the symptoms match pretty well with this:

https://bugzilla.redhat.com/show_bug.cgi?id=1361157

Bug#836792: zip FTCBFS: uses the build architecture compiler

[Santiago Vila]

On Mon, Sep 05, 2016 at 09:40:32PM +0200, Helmut Grohne wrote:
> Source: zip
> Version: 3.0-11
> Tags: patch
> User: helm...@debian.org
> Usertags: rebootstrap
> 
> zip fails to cross build from source, because it uses the build
> architecture compiler (and later fails dh_strip). Simply passing a
> triplet-prefixed CC to configure makes the build pass already. Doing
> that produces a zip without large file support though, because configure
> determines large file support using a compile and run check. Thus I
> replaced that check with an equivalent compile-only check. Please
> consider applying the attached patch.

Thanks for your work.

This is a lot more intrusive than the patch for unzip, so I'll probably
forward it upstream before considering to apply it to the Debian
package.

Bug#836798: iceowl-extension: Taks from google calendare are read-only

[Carsten Schoenert]

Hello Daniel,

On Mon, Sep 05, 2016 at 11:11:21PM +0200, Daniel Materka wrote:
> Package: iceowl-extension
> Version: 1:45.2.0-4
> Severity: important
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>* What was the outcome of this action?
>* What outcome did you expect instead?
> 
> *** End of the template - remove these template lines ***

unfortunately that's some kind of non informative bug report. :-/

Without further information it's impossible to help or to triage a
possible bug.

BTW: I can successful create new tasks on my todo list in a GMail
account. So I assume there is something missconfigured or wrong on your
setup.

Regards
Carsten

Bug#828535: ruby2.3: FTBFS with openssl 1.1.0

[Sebastian Andrzej Siewior]

On 2016-06-28 16:40:09 [-0300], Antonio Terceiro wrote:
> upstream already has support for OpenSSL 1.1.0 in trunk for Ruby 2.4;
> see upstream bug linked above. given the current state of afairs, we
> will need to either backport that for Ruby 2.3 ourselves, or disable the
> openssl extension bundled with the interpreter and use a standalone
> ruby-openssl package.

2.4 is scheduled for 2016-12-25 so it is unlikely to be part of the next
Debian release, right?
Is the backport huge (in terms of conflicts of the original patch) or is
it simpler to go for the ruby-openssl package?

Sebastian

Bug#776193: unshield: CVE-2015-1386: directory traversal

[Moritz Mühlenhoff]

On Mon, Sep 05, 2016 at 10:34:30PM +0200, Petter Reinholdtsen wrote:
> Control: forwarded -1 https://github.com/twogood/unshield/issues/42
> 
> RedHat tagged this issue wontfix.

That just means that it's not in their set of supported packages
(which is pretty small for RHEL)

Cheers,
  Moritz

Bug#827936: po4a: please implement support for Ruby document format

[Francesco Poli]

On Mon, 5 Sep 2016 15:00:11 +0200 Martin Quinson wrote:

> Hello Francesco,

Hello Martin,
thank you so much for writing me!

Your message is really appreciated, as I was just going to send an
update today (an astonishing coincidence!).

> 
> did you manage to do any progress on this front?

It was an interesting ride in the last two months, and the time devoted
to the development of the po4a module was not so abundant...
But, nonetheless, I've just come up with the attached version of the Rd
module.
The tar archive includes the module implementation and a little
document to test it (the tests/ directory also contains the various
output files and two scripts).

> Is there anything I could do to help?

Yes, there is.

Could you please

 * review the code I wrote

 * review the documentation I added (I haven't tried to convert it into
   a man page with POD tools, so bear with me!)

 * test the module with po4a

and tell me how the module could be improved?

Thanks for your time and helpfulness!
Bye.



P.S.: Please remember to keep me in Cc, when replying (as I am not
  subscribed to the mailing list or to the bug). Thanks.

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


po4a-Rd-module_v013.tar.xz
Description: application/xz


pgpPw7WjLbXpr.pgp
Description: PGP signature

Bug#836798: iceowl-extension: Taks from google calendare are read-only

[Daniel Materka]

Package: iceowl-extension
Version: 1:45.2.0-4
Severity: important

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***



-- 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/2 CPU cores)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages iceowl-extension depends on:
ii  icedove 1:45.2.0-4
ii  libc6   2.23-5
ii  libgcc1 1:6.1.1-11
ii  libnspr42:4.12-2
ii  libstdc++6  6.1.1-11

iceowl-extension recommends no packages.

Versions of packages iceowl-extension suggests:
ii  calendar-google-provider  1:45.2.0-4
ii  fonts-lyx 2.2.0-2

-- debconf-show failed

Bug#785799: [festvox-ca-ona-hts] Since las festival upgrade, catalan voice is not correctly recognized and does not work

[Sergio Oller]

Hi Guillem,

I have been working this summer to get the new upstream version of this
package and after some testing it seems it works fine, so I just uploaded
its package to mentors. Could you please sponsor it?

In the past it was a bit hard to find a sponsor and knowing that I had to
go through the process of finding one was demotivating me a bit.

You can fetch the package using:

dget -x 
https://mentors.debian.net/debian/pool/main/f/festvox-ca-ona-hts/festvox-ca-ona-hts_1.3-1.dsc

Further info is available here:

 https://mentors.debian.net/package/festvox-ca-ona-hts

If there is anything on my side I can do to help please contact me.

Thanks in advance and sorry for the delay,

Sergio











2016-09-05 19:27 GMT+02:00 Guillem Jover :

> Control: severity -1 serious
>
> Hi!
>
> On Wed, 2015-05-20 at 12:41:04 +0200, Sergio Oller Moreno wrote:
> > Festival 2.4 seems to break compatibility with previous festival 2.1
> > HTS voices.
> >
> > I will update the Catalan voices as soon as possible (ideally this week)
> > to be compatible with festival 2.4 and I will check if there are other
> > HTS voices in Debian.
>
> Bumping the severity as this pretty much makes the package unsuitable
> for release.
>
> Oh, and I was going to propose that if doing the necessary changes
> were too involved, packaging the clunits variants might be an option,
> but then just noticed that there's now a new upstream release. So if
> you need a sponsor to update the package, please let me know!
>
> Thanks,
> Guillem
>

Bug#835677: remctl: FTBFS: dh_auto_test: make -j1 check VERBOSE=1 returned exit code 2

[Lucas Nussbaum]

On 05/09/16 at 10:13 -0700, Russ Allbery wrote:
> Control: severity 835677 normal
> 
> Lucas Nussbaum  writes:
> 
> > Source: remctl
> > Version: 3.12-1
> > Severity: serious
> > Tags: stretch sid
> > User: debian...@lists.debian.org
> > Usertags: qa-ftbfs-20160828 qa-ftbfs
> > Justification: FTBFS on amd64
> 
> > During a rebuild of all packages in sid, your package failed to build on
> > amd64.
> 
> >> server/shell-misc...FAILED 8
> 
> This appears to be another oddity of the testing environment: 127.0.0.1
> apparently doesn't resolve to a string containing the word "localhost."
> I'll try to make the test more robust against this by also checking for a
> string containing $(hostname), but if you happen to know what the reverse
> DNS is for 127.0.0.1 in the test environment, I'll make sure this is
> caught.
> 
> Downgrading since this shouldn't be a problem for Debian proper; this
> seems to work fine on all the buildds.

Hi,

That's strange.

What the script sees is:
# ./runtests -o server/shell-misc-t
1..15
ok 1 - no REMCTL_USER
ok 2 - no SSH_CONNECTION
ok 3 - value for REMUSER
ok 4 - value for REMOTE_USER
ok 5 - value for REMOTE_ADDR
ok 6 - value for REMOTE_EXPIRES
ok 7 - return status for REMOTE_HOST
# env REMOTE_HOST: ip-172-31-8-210.eu-central-1.compute.internal
not ok 8 - value for REMOTE_HOST
ok 9 - file descriptors closed properly on server

However:
# cat /etc/hosts
127.0.0.1 ip-172-31-8-210.eu-central-1.compute.internal localhost

And:
# host 127.0.0.1
1.0.0.127.in-addr.arpa domain name pointer localhost.

Lucas

Bug#836796: ITP: mdk3 -- Proof-of-concept tool to exploit common 802.11 protocol weaknesses

[Samuel Henrique]

Package: wnpp
Owner: "Samuel Henrique" 
Severity: wishlist

* Package name: mdk3
  Version : 6.0
  Upstream Author : Pedro Larbig "ASPj" 
* URL : http://aspj.aircrack-ng.org/#mdk3

* License : GPL-2+
  Programming Lang: C
  Description : Proof-of-concept tool to exploit common 802.11 protocol
weaknesses.

MDK3 is a Wi-Fi testing tool from ASPj of k2wrlz, it uses the osdep library
from the aircrack-ng project to inject frames on several operating systems.

I intend to maintain this under the pkg-security team, as this is part
of an effort to get kali packages within debian.

Any help from a pkg-security team member is highly appreciated, i'm going
to send the first draft of the packaging into our team's git soon.

Samuel Henrique O. P. [samueloph]

Bug#836797: taffybar: weather URL is no longer valid

[Rob Browning]

Package: taffybar
Version: 0.4.6-2

The weather URL in Weather.hs is no longer valid, if you have time, it'd
be nice if we could incorporate the upstream commit to fix it:

  
https://github.com/travitch/taffybar/commit/ee9207c278582e1f1040d50aa92558982765da98

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#836710: pkg_resources: ‘load_entry_point’ crashes without Setuptools

[Ben Finney]

On 06-Sep-2016, Ben Finney wrote:

> I have manually installed older versions of ‘python-pkg-resources’
> into a clean chroot, and confirmed that this behaviour happens […]

Note that the problem does *not* occur when running the same statement
at an interactive Python prompt:

=
$ python2
Python 2.7.12+ (default, Aug  4 2016, 20:04:34)
[GCC 6.1.1 20160724] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from pkg_resources import load_entry_point
>>>
=

This behaviour is only when the generated script is run:

=
$ dpkg-query --show python-pkg-resources
python-pkg-resources20.7.0-1

$ head -n 7 /usr/bin/dput
#!/usr/bin/python
# EASY-INSTALL-ENTRY-SCRIPT: 'dput==0.10.3','console_scripts','execute-dput'
__requires__ = 'dput==0.10.3'
import re
import sys
from pkg_resources import load_entry_point


$ /usr/bin/dput
Traceback (most recent call last):
  File "/usr/bin/dput", line 6, in 
from pkg_resources import load_entry_point
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2927, 
in 
@_call_aside
  […]
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 829, 
in resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'setuptools' distribution was not found 
and is required by dput
=

So a statement that works in a fresh Python interpreter, fails when
the same statement is executed by the same interpreter, early in the
command-line script.

-- 
 \  “If the desire to kill and the opportunity to kill came always |
  `\  together, who would escape hanging?” —Mark Twain, _Following |
_o__) the Equator_ |
Ben Finney 


signature.asc
Description: PGP signature

Bug#836700: jessie-pu: package cacti/0.8.8b+dfsg-8+deb8u6

[Paul Gevers]

Hi,

On 05-09-16 07:49, Paul Gevers wrote:
>>> The fix for CVE-2016-2313 in 0.8.8b+dfsg-8+deb8u5 was reported¹ to contain a
>>> regression. The attached debdiff contains the reporters patch that was 
>>> accepted
>>> upstream to fix the issue.
>>
>> What's the plan for getting the updated fix into unstable?
> 
> Will do that tonight (UTC+2). Due to the upload window for jpu, I
> focused on that one first and than it was bed time.

Uploaded at 22:11 (UTC+2).

Paul



signature.asc
Description: OpenPGP digital signature

Bug#836706: certificate spoofing via crafted SASL messages

[James Lu]

Hi,

Just to narrow things down a bit, the relevant fix for InspIRCd 2.0 is
this commit
https://github.com/inspircd/inspircd/commit/74fafb7f11b06747f69f182ad5e3769b665eea7a

Best,
James



signature.asc
Description: OpenPGP digital signature

Bug#836794: cme: 'cme update dpkg-copyright' no longer work

[gregor herrmann]

On Mon, 05 Sep 2016 22:16:17 +0200, Petter Reinholdtsen wrote:

> According to the App::Cme::Command::update(3pm) manual page, cme update
> dpkg-copyright should work, 

It still works for me.

> but cme itself claim it is an unknown
> argument:

No, an "unknown application" :)
 
>   % cme update dpkg-copyright
>   Unknown application: dpkg-copyright. Run 'cme list' to list available
> applications 


This sounds a bit like you don't have the dpkg-copyright model
installed, a.k.a. you're missing libconfig-model-dpkg-perl (which is
"only" a Recommends of cme).



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: Lenny Kravitz: Let Love Rule


signature.asc
Description: Digital Signature

Bug#836710: pkg_resources: ‘load_entry_point’ crashes without Setuptools

[Ben Finney]

Control: found -1 python-pkg-resources/25.2.0-1
Control: found -1 python-pkg-resources/20.7.0-1

On 06-Sep-2016, Ben Finney wrote:
> Since the version in Sid changed just before your report
> , I will assume that is
> the version with which you experienced this problem.

I have manually installed older versions of ‘python-pkg-resources’
into a clean chroot, and confirmed that this behaviour happens back to
at least version “20.7.0-1”. I did not go earlier than that so it may
exist before then also.

-- 
 \ “Religious faith is the one species of human ignorance that |
  `\ will not admit of even the *possibility* of correction.” —Sam |
_o__) Harris, _The End of Faith_, 2004 |
Ben Finney 


signature.asc
Description: PGP signature

Bug#776193: unshield: CVE-2015-1386: directory traversal

[Petter Reinholdtsen]

Control: forwarded -1 https://github.com/twogood/unshield/issues/42

RedHat tagged this issue wontfix.  Are we sure this issue is release critical?

-- 
Happy hacking
Petter Reinholdtsen

Bug#836530: nmu: lazarus_1.6+dfsg-4

[Paul Gevers]

Hi

On 04-09-16 12:42, peter green wrote:
>>
>> nmu lazarus_1.6+dfsg-4 . powerpc . unstable . -m "rebuild with fpc
>> 3.0.0+dfsg-7 to fix glibc>  2.23 related issues"
> Minor nitpick, the working powerpc fix didn't land until -8

Ouch, yes, sure.

>> nmu imapcopy_1.04-2 . powerpc . unstable . -m "rebuild with fpc
>> 3.0.0+dfsg-7 to fix glibc>  2.23 related issues"
>> nmu mricron_0.20140804.1~dfsg.1-1 . powerpc . unstable . -m "rebuild
>> with fpc 3.0.0+dfsg-7 to fix glibc>  2.23 related issues"
>>
> These have unrelated FTBFS bugs, so scheduling a binnmu is pointless.
> Instead the FTBFS bugs need to be fixed.

And they both contain patches even. Apparently nobody cares that the
packages are not in testing for a long time. @Peter, thanks for the patch ;)

> In addition to the binnmus we will want some give-backs once lazarus is
> rebuilt
> 
> gb ddrescueview_0.4~alpha3-1 . powerpc . unstable
> gb doublecmd_0.7.3-1 . powerpc . unstable

And since today:
gb winff_1.5.3-7 . powerpc . unstable


So in total we have:
nmu lazarus_1.6+dfsg-4 . powerpc . unstable . -m "rebuild with fpc 3.0.0+dfsg-7 
to fix glibc > 2.23 related issues"

Wait until lazarus is rebuild:
nmu cqrlog_2.0.1-1 . powerpc . unstable . -m "rebuild with fpc 3.0.0+dfsg-7 to 
fix glibc > 2.23 related issues"
nmu dozzaqueux_3.42-1 . powerpc . unstable . -m "rebuild with fpc 3.0.0+dfsg-7 
to fix glibc > 2.23 related issues"
nmu easymp3gain_0.5.0+svn135-6 . powerpc . unstable . -m "rebuild with fpc 
3.0.0+dfsg-7 to fix glibc > 2.23 related issues"
nmu gearhead_1.302-1 . powerpc . unstable . -m "rebuild with fpc 3.0.0+dfsg-7 
to fix glibc > 2.23 related issues"
nmu hedgewars_0.9.22-dfsg-7+b2 . powerpc . unstable . -m "rebuild with fpc 
3.0.0+dfsg-7 to fix glibc > 2.23 related issues"
nmu nbc_1.2.1.r4+dfsg-1 . powerpc . unstable . -m "rebuild with fpc 
3.0.0+dfsg-7 to fix glibc > 2.23 related issues"
nmu optgeo_2.23-1 . powerpc . unstable . -m "rebuild with fpc 3.0.0+dfsg-7 to 
fix glibc > 2.23 related issues"
nmu transgui_5.0.1-4 . powerpc . unstable . -m "rebuild with fpc 3.0.0+dfsg-7 
to fix glibc > 2.23 related issues"
nmu tuxcmd_0.6.70+dfsg-2 . powerpc . unstable . -m "rebuild with fpc 
3.0.0+dfsg-7 to fix glibc > 2.23 related issues"
nmu vmg_3.7.1-2 . powerpc . unstable . -m "rebuild with fpc 3.0.0+dfsg-7 to fix 
glibc > 2.23 related issues"
gb ddrescueview_0.4~alpha3-1 . powerpc . unstable
gb doublecmd_0.7.3-1 . powerpc . unstable
gb winff_1.5.3-7 . powerpc . unstable

Paul



signature.asc
Description: OpenPGP digital signature

Bug#836794: cme: 'cme update dpkg-copyright' no longer work

[Petter Reinholdtsen]

Package: cme
Version: 1.013-2

According to the App::Cme::Command::update(3pm) manual page, cme update
dpkg-copyright should work, but cme itself claim it is an unknown
argument:

  % cme update dpkg-copyright
  Unknown application: dpkg-copyright. Run 'cme list' to list available
applications 
  %

What happened with this very useful feature?

--
Happy hacking
Petter Reinholdtsen

Bug#746405: (no subject)

[Breno Leitao]

Closing this bug, since gnome-menus works fine on ppc64el.

Thanks!

Bug#828594: virtuoso-opensource: FTBFS with openssl 1.1.0

[Sebastian Andrzej Siewior]

On 2016-06-26 12:24:41 [+0200], Kurt Roeckx wrote:
> If you have problems making things work, feel free to contact us.

The patch attached fixes most of it.
There are a few des ⇾ DES conversations like des_cblock ⇾ DES_cblock or
des_key_schedule ⇾ DES_key_schedule or des_ede3_cbc_encrypt ⇾
DESede3_cbc_encrypt which I hope are okay.
There are M_ASN1_INTEGER_free ⇾ ASN1_STRING_free which I also hope that
those are okay. That part where I replaced d2i_ASN1_BOOLEAN() looks like
they copied it from old openssl code.
There are a few #if HALP blocks which I simply don't know what should
happen in there. If HALP is turned into 0 then it compiles.

> Kurt
Sebastian
>From 58fa4e5de620b90fca7c2366a130ec73d0aee0f0 Mon Sep 17 00:00:00 2001
From: Sebastian Andrzej Siewior 
Date: Mon, 5 Sep 2016 10:49:54 +
Subject: [PATCH] virtuoso-opensource: build against openssl 1.1.0

Signed-off-by: Sebastian Andrzej Siewior 
---
 libsrc/Dk/Dkernel.c  |   6 +-
 libsrc/Wi/bif_crypto.c   |  80 +++-
 libsrc/Wi/http.c |   2 +-
 libsrc/Wi/xmlenc.c   | 319 +++
 libsrc/Wi/xmlenc.h   | 176 --
 libsrc/Wi/xmlenc_algos.c | 132 +++-
 libsrc/util/sslengine.c  |   6 +-
 7 files changed, 485 insertions(+), 236 deletions(-)

diff --git a/libsrc/Dk/Dkernel.c b/libsrc/Dk/Dkernel.c
index c8dfbf7..82c77cb 100644
--- a/libsrc/Dk/Dkernel.c
+++ b/libsrc/Dk/Dkernel.c
@@ -4930,7 +4930,11 @@ ssl_server_init ()
 # if (OPENSSL_VERSION_NUMBER >= 0x00908000L)
   SSL_library_init ();
 # endif
-  SSLeay_add_all_algorithms ();
+#if OPENSSL_VERSION_NUMBER < 0x1010
+  SSLeay_add_all_algorithms();
+#else
+  OpenSSL_add_all_algorithms();
+#endif
   PKCS12_PBE_add ();		/* stub */
 
 #ifdef NO_THREAD
diff --git a/libsrc/Wi/bif_crypto.c b/libsrc/Wi/bif_crypto.c
index c759d11..23c676b 100644
--- a/libsrc/Wi/bif_crypto.c
+++ b/libsrc/Wi/bif_crypto.c
@@ -181,21 +181,26 @@ box_hmac (caddr_t box, caddr_t key, int alg)
   unsigned char temp[EVP_MAX_MD_SIZE];
   unsigned int size = 0;
   caddr_t res = NULL;
-  HMAC_CTX ctx;
+  HMAC_CTX *ctx;
   const EVP_MD *md = EVP_sha1 ();
 
   if (alg == 1)
 md = EVP_ripemd160 ();
 
-  HMAC_Init (, key, box_length (key) - DV_STRINGP (key) ? 1 : 0, md);
-  box_hmac_1 (box, );
-  HMAC_Final (, temp, );
+  ctx = HMAC_CTX_new();
+  if (!ctx)
+	  return res;
+
+  HMAC_Init_ex (ctx, key, box_length (key) - DV_STRINGP (key) ? 1 : 0, md, NULL);
+  box_hmac_1 (box, ctx);
+  HMAC_Final (ctx, temp, );
   if (size)
 {
   res = dk_alloc_box (size + 1, DV_SHORT_STRING);
   memcpy (res, temp, size);
   res[size] = 0;
 }
+  HMAC_CTX_free(ctx);
   return res;
 }
 
@@ -347,14 +352,12 @@ asn1_parse_to_xml (BIO * bp, unsigned char **pp, long length, int offset, int de
 	{
 	  int ii;
 
-	  opp = op;
-	  ii = d2i_ASN1_BOOLEAN (NULL, , len + hl);
-	  if (ii < 0)
+	  if (len + hl < 1)
 		{
 		  if (BIO_write (bp, "Bad boolean\n", 12))
 		goto end;
 		}
-	  BIO_printf (bp, "%d", ii);
+	  BIO_printf (bp, "%d", p[0]);
 	}
 	  else if (tag == V_ASN1_BMPSTRING)
 	{
@@ -415,7 +418,7 @@ asn1_parse_to_xml (BIO * bp, unsigned char **pp, long length, int offset, int de
 		}
 	  if (os != NULL)
 		{
-		  M_ASN1_OCTET_STRING_free (os);
+		  ASN1_STRING_free (os);
 		  os = NULL;
 		}
 	}
@@ -448,7 +451,7 @@ asn1_parse_to_xml (BIO * bp, unsigned char **pp, long length, int offset, int de
 		  if (BIO_write (bp, "BAD INTEGER", 11) <= 0)
 		goto end;
 		}
-	  M_ASN1_INTEGER_free (bs);
+	  ASN1_STRING_free (bs);
 	}
 	  else if (tag == V_ASN1_ENUMERATED)
 	{
@@ -479,7 +482,7 @@ asn1_parse_to_xml (BIO * bp, unsigned char **pp, long length, int offset, int de
 		  if (BIO_write (bp, "BAD ENUMERATED", 11) <= 0)
 		goto end;
 		}
-	  M_ASN1_ENUMERATED_free (bs);
+	  ASN1_STRING_free (bs);
 	}
 	  else if (len > 0 && dump)
 	{
@@ -515,7 +518,7 @@ end:
   if (o != NULL)
 ASN1_OBJECT_free (o);
   if (os != NULL)
-M_ASN1_OCTET_STRING_free (os);
+ASN1_STRING_free (os);
   *pp = p;
   return (ret);
 }
@@ -854,16 +857,18 @@ bif_smime_sign (caddr_t * qst, caddr_t * err_ret, state_slot_t ** args)
 }
 
   certs = sk_X509_new_null ();
+#if HALP
   if (store && store->objs)
 {
   for (inx = 0; inx < sk_X509_OBJECT_num (store->objs); inx++)
 	{
 	  X509_OBJECT *obj = sk_X509_OBJECT_value (store->objs, inx);
-	  if (obj->type == X509_LU_X509)
+	  if (X509_OBJECT_get_type(obj) == X509_LU_X509)
 	sk_X509_push (certs, X509_dup (obj->data.x509));
 	}
 
 }
+#endif
   if (store)
 X509_STORE_free (store);
   in_bio = BIO_new_mem_buf (msg, box_length (msg) - 1);
@@ -935,6 +940,7 @@ bif_smime_encrypt (caddr_t * qst, caddr_t * err_ret, state_slot_t ** args)
 sqlr_new_error ("42000", "CR006", "No recipient certificates");
 
   certs = sk_X509_new_null ();
+#if HALP
   if (store && 

Bug#756442: (no subject)

[Breno Leitao]

Control: tags 756442 + pending

Dear maintainer,

I've prepared an NMU for tablix2 (versioned as 0.3.5-3.1) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Regards.
diff -u tablix2-0.3.5/debian/changelog tablix2-0.3.5/debian/changelog
--- tablix2-0.3.5/debian/changelog
+++ tablix2-0.3.5/debian/changelog
@@ -1,3 +1,10 @@
+tablix2 (0.3.5-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS on ppc64el and arm64. (Closes: #756442)
+
+ -- Breno Leitao   Mon, 05 Sep 2016 15:48:40 -0400
+
 tablix2 (0.3.5-3) unstable; urgency=medium
 
   * maintenance and cleanup spin:
diff -u tablix2-0.3.5/debian/control tablix2-0.3.5/debian/control
--- tablix2-0.3.5/debian/control
+++ tablix2-0.3.5/debian/control
@@ -2,7 +2,7 @@
 Section: misc
 Priority: extra
 Maintainer: Robert Lemmen 
-Build-Depends: debhelper (>= 7.0.0), pvm-dev, libxml2-dev
+Build-Depends: debhelper (>= 7.0.0), pvm-dev, libxml2-dev, dh-autoreconf
 Homepage: http://www.tablix.org
 Standards-Version: 3.9.8
 
diff -u tablix2-0.3.5/debian/rules tablix2-0.3.5/debian/rules
--- tablix2-0.3.5/debian/rules
+++ tablix2-0.3.5/debian/rules
@@ -8,6 +8,7 @@
 
 config.status: configure
 	dh_testdir
+	dh_autoreconf
 	./configure CFLAGS="$(CFLAGS)" LDFLAGS="$(LDFLAGS)" --prefix=/usr --mandir=/usr/share/man --with-pvm3 --enable-conv --enable-more-teachers --enable-tunable
 
 build: build-stamp
@@ -20,6 +21,7 @@
 clean:
 	dh_testdir
 	dh_testroot
+	dh_autoreconf_clean
 	rm -f build-stamp 
 	rm -f examples/modules/*.so
 	[ ! -f Makefile ] || $(MAKE) distclean

Bug#833727: emacs24: FTBFS with glibc 2.24

[Rob Browning]

Aurelien Jarno  writes:

> Yes, the 0020-Always-define-gmalloc-etc.-in-src-gmalloc.c.patch actually
> comes from upstream commit 4b1436b702d56eedd27a0777fc7232cdfb7ac4f6.

Ahh, yes, quite close, so I think this may be sufficient:

  Author: Wolfgang Jenkner 
  Date:   Sat Dec 26 12:12:02 2015 -0800

Emacs should work with gcc 5.2 and newer

This patch, backported from upstream by Aurelien Jarno
, has been added:

  Always define gmalloc etc. in src/gmalloc.c

  This is a work-around to prevent the compiler from using semantic
  knowledge about malloc for optimization purposes.  E.g., gcc 5.2
  with -O2 replaces most of calloc's definition by a call to calloc;
  see Bug#22085.
  * src/gmalloc.c [!HYBRID_MALLOC] (malloc, realloc, calloc)
  (aligned_alloc, free): Do not undef.  Instead, define these as
  functions (perhaps renamed to gmalloc etc.) in terms of gmalloc etc.

Origin: backport, commit: 4b1436b702d56eedd27a0777fc7232cdfb7ac4f6
Bug-Debian: http://bugs.debian.org/833727

...and for the glibc patch, this looks like the origin:
e95b023163e96538b15f030b7176b7ec59cf86f5

Thanks again
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#836341: synaptic: Freezes after one or two mouse strokes

[Peter]

Hi,

I had the same problem and believe it was caused by version 3.21.5-3 of
libgtk-3-0

Downgraded to 3.20.9-1 and I now have a stable synaptic again.

See also bug# 836246


Peter

Bug#828354: #828354: ipsec-tools: FTBFS with openssl 1.1.0

[Christian Hofstaedtler]

I'd not be comfortable for a rigorous patching effort to make
ipsec-tools/racoon build against 1.1.0. There'd be about 10-20K LOC
to modify/port...

Honestly, if there is no OpenSSL-supplied compat library (and
upstream would not wake up), then the only sane option is to drop
ipsec-tools on the floor. :-(

-- 
 ,''`.  Christian Hofstaedtler 
: :' :  Debian Developer
`. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
  `-

Bug#836793: [apt-listbugs] [PATCH] Display Debian BTS URLs when listing bugs

[Keshav Kini]

Package: apt-listbugs
Version: 0.1.18
Severity: wishlist
Tags: patch

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

Please find attached a small patch for apt-listbugs, which causes it to
print links to bugs.debian.org when listing bugs.

--- System information. ---
Architecture: amd64
Kernel:   Linux 4.6.0-1-amd64

Debian Release: stretch/sid
  990 unstableftp.us.debian.org   990 sid
linux.dropbox.com   500 stable  dl.google.com
--- Package information. ---
Depends(Version) | Installed
-+-
ruby | 1:2.3.0+4
 OR ruby-interpreter | ruby-debian   (>= 0.3.3) |
0.3.9+b6
apt  (>= 0.9.11) | 1.3~rc4
ruby-gettext  (>= 3.0.2) | 3.2.2-1
ruby-xmlparser   | 0.7.3-3
ruby-soap4r  | 2.0.5-3
ruby-unicode | 0.4.4-2+b7


Recommends   (Version) | Installed
==-+-===
ruby-httpclient (>= 2.1.5.2-1) |

Suggests (Version) | Installed
==-+-===
reportbug  | 6.6.6
debianutils  (>= 2.0)  | 4.8
 OR www-browser|  OR w3m| 0.5.3-29
>From f02150ae042eea42f610f34c55dde8481535ccb1 Mon Sep 17 00:00:00 2001
From: Keshav Kini 
Date: Mon, 5 Sep 2016 14:25:58 -0500
Subject: [PATCH] Display Debian BTS URLs when listing bugs
To: foo 

This commit dumps the URL for the bug on bugs.debian.org alongside the
bug ID when reporting bugs for a package.  This allows a user to easily
find more information about the bug if the summary/title alone is
insufficient.
---
 lib/aptlistbugs/logic.rb | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lib/aptlistbugs/logic.rb b/lib/aptlistbugs/logic.rb
index 7a416d4..4dfb67d 100644
--- a/lib/aptlistbugs/logic.rb
+++ b/lib/aptlistbugs/logic.rb
@@ -689,7 +689,8 @@ class Viewer
 bug.id = @bugmap.length.next
 @bugmap[bug.id.to_s] = bug.bug_number
   end
-  bug_str = " b#{bug.id} - ##{bug.bug_number} - #{bug.desc}"
+  bug_link = "http://bugs.debian.org/#{bug.bug_number};
+  bug_str = " b#{bug.id} - ##{bug.bug_number} [ #{bug_link} ] - #{bug.desc}"
   # TRANSLATORS: "Found" refers to one singular bug
   bug_str += sprintf(_(" (Found: %s)"), "#{bug.found}") if ( ! bug.found.nil? ) && $DEBUG
   # TRANSLATORS: "Fixed" refers to one singular bug
-- 
2.9.3

Bug#606224: oggvideotools: oggJoin fails on powerpc

[Petter Reinholdtsen]

The code has been rewritten in 0.9.1-2, but the powerpc problem still
exist.  The autobuilders report this during testing now:

  VorbisPosInterpreter::extract: This page is not a BOS (Begin Of
Stream) page
  Warning:

is not a valid ogg fileError: could not open any stream - abort

I know upstream would be happy to get a patch with a fix for this
problem. :)

-- 
Happy hacking
Petter Reinholdtsen

Bug#836792: zip FTCBFS: uses the build architecture compiler

[Helmut Grohne]

Source: zip
Version: 3.0-11
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

zip fails to cross build from source, because it uses the build
architecture compiler (and later fails dh_strip). Simply passing a
triplet-prefixed CC to configure makes the build pass already. Doing
that produces a zip without large file support though, because configure
determines large file support using a compile and run check. Thus I
replaced that check with an equivalent compile-only check. Please
consider applying the attached patch.

Helmut
diff --minimal -Nru zip-3.0/debian/changelog zip-3.0/debian/changelog
--- zip-3.0/debian/changelog2015-08-16 23:38:20.0 +0200
+++ zip-3.0/debian/changelog2016-09-05 21:37:00.0 +0200
@@ -1,3 +1,12 @@
+zip (3.0-11.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Closes: #-1
++ Pass triplet prefixed CC to configure.
++ Add d/patches/11-cross-large-file.
+
+ -- Helmut Grohne   Mon, 05 Sep 2016 21:23:18 +0200
+
 zip (3.0-11) unstable; urgency=medium
 
   * Ship a debian/copyright file in source package instead of generating
diff --minimal -Nru zip-3.0/debian/patches/11-cross-large-file 
zip-3.0/debian/patches/11-cross-large-file
--- zip-3.0/debian/patches/11-cross-large-file  1970-01-01 01:00:00.0 
+0100
+++ zip-3.0/debian/patches/11-cross-large-file  2016-09-05 21:36:18.0 
+0200
@@ -0,0 +1,66 @@
+From: Helmut Grohne 
+Subject: make the large file support check work under cross compilation
+
+Index: zip-3.0/unix/configure
+===
+--- zip-3.0.orig/unix/configure
 zip-3.0/unix/configure
+@@ -434,18 +434,48 @@
+ if [ $? -ne 0 ]; then
+   echo -- no Large File Support
+ else
+-# run it
+-  ./conftest
+-  r=$?
+-  if [ $r -eq 1 ]; then
++  cat > conftest.c << _EOF_
++# define _LARGEFILE_SOURCE   /* some OSes need this for fseeko */
++# define _LARGEFILE64_SOURCE
++# define _FILE_OFFSET_BITS 64   /* select default interface as 64 bit */
++# define _LARGE_FILES/* some OSes need this for 64-bit off_t */
++#include 
++#include 
++#include 
++#include 
++int main()
++{
++  int check[1 - 2 * (sizeof(off_t) < 8)] = {};
++  return check[0];
++}
++_EOF_
++  $CC -o conftest conftest.c >/dev/null 2>/dev/null
++  if [ $? -ne 0 ]; then
+ echo -- no Large File Support - no 64-bit off_t
+-  elif [ $r -eq 2 ]; then
+-echo -- no Large File Support - no 64-bit stat
+-  elif [ $r -eq 3 ]; then
+-echo -- yes we have Large File Support!
+-CFLAGS="${CFLAGS} -DLARGE_FILE_SUPPORT"
+   else
+-echo -- no Large File Support - conftest returned $r
++cat > conftest.c << _EOF_
++# define _LARGEFILE_SOURCE   /* some OSes need this for fseeko */
++# define _LARGEFILE64_SOURCE
++# define _FILE_OFFSET_BITS 64   /* select default interface as 64 bit */
++# define _LARGE_FILES/* some OSes need this for 64-bit off_t */
++#include 
++#include 
++#include 
++#include 
++int main()
++{
++  struct stat s;
++  int check[1 - 2 * (sizeof(s.st_size) < 8)] = {};
++  return check[0];
++}
++_EOF_
++$CC -o conftest conftest.c >/dev/null 2>/dev/null
++if [ $? -ne 0 ]; then
++  echo -- no Large File Support - no 64-bit stat
++else
++  echo -- yes we have Large File Support!
++  CFLAGS="${CFLAGS} -DLARGE_FILE_SUPPORT"
++fi
+   fi
+ fi
+ 
diff --minimal -Nru zip-3.0/debian/patches/series zip-3.0/debian/patches/series
--- zip-3.0/debian/patches/series   2015-05-17 12:30:00.0 +0200
+++ zip-3.0/debian/patches/series   2016-09-05 21:26:18.0 +0200
@@ -8,3 +8,4 @@
 08-hardening-build-fix-1
 09-hardening-build-fix-2
 10-remove-build-date
+11-cross-large-file
diff --minimal -Nru zip-3.0/debian/rules zip-3.0/debian/rules
--- zip-3.0/debian/rules2015-08-16 23:25:10.0 +0200
+++ zip-3.0/debian/rules2016-09-05 21:23:17.0 +0200
@@ -1,6 +1,9 @@
 #!/usr/bin/make -f
 
-CC = gcc
+include /usr/share/dpkg/architecture.mk
+ifeq ($(origin CC),default)
+CC = $(DEB_HOST_GNU_TYPE)-gcc
+endif
 CFLAGS := `dpkg-buildflags --get CFLAGS` -Wall -I. -DUNIX
 LDFLAGS := `dpkg-buildflags --get LDFLAGS`
 CPPFLAGS := `dpkg-buildflags --get CPPFLAGS`

Bug#836710: pkg_resources: ‘load_entry_point’ crashes without Setuptools

[Ben Finney]

Control: found -1 python-pkg-resources/26.1.1-1

On 05-Sep-2016, Ben Finney wrote:
> On 05-Sep-2016, Ben Burton wrote:
> 
> > I tried to run dput today in my sid VM, and it gave the following error:

Had you updated your Sid VM recently? Which version of
‘python-pkg-resources’ was installed when you experienced that
behaviour?

Since the version in Sid changed just before your report
, I will assume that is
the version with which you experienced this problem.

If that's not the case, please correct the “found” information I set
in this bug report, to the actual package version where the problem
first appears.

-- 
 \   “Most people are other people. Their thoughts are someone |
  `\  else’s opinions, their lives a mimicry, their passions a |
_o__)   quotation.” —Oscar Wilde, _De Profundis_, 1897 |
Ben Finney 


signature.asc
Description: PGP signature

Bug#836791: jigit FTCFBS: uses the build architecture compiler

[Helmut Grohne]

Source: jigit
Version: 1.20-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

jigit fails to cross build from source, because it uses the build
architecture compiler (and later dh_strip causes the failure). For
libjte, this can be fixed by passing the right flags to ./configure as
is done by dh_auto_configure. For the extra programs building, a proper
CC variable needs to be passed to make. For a successful cross build,
some configure variables need to be exported in addition to applying the
patch. At least ac_cv_func_malloc_0_nonnull=yes and
ac_cv_func_realloc_0_nonnull=yes are needed here. As these are
libc-specific and we are heading to supporting multiple libcs in Debian,
I think jigit should not set them and instead rely on the environment
providing them. Please consider applying the patch.

Helmut
diff --minimal -Nru jigit-1.20/debian/changelog jigit-1.20/debian/changelog
--- jigit-1.20/debian/changelog 2015-11-18 01:45:48.0 +0100
+++ jigit-1.20/debian/changelog 2016-09-05 21:02:54.0 +0200
@@ -1,3 +1,12 @@
+jigit (1.20-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Let dh_auto_configure pass relevant cross flags
++ Pass triplet-prefixed CC to make
+
+ -- Helmut Grohne   Mon, 05 Sep 2016 20:02:51 +0200
+
 jigit (1.20-2) unstable; urgency=medium
 
   * Update the priority of libjte1 to optional, to match libisofs6 that
diff --minimal -Nru jigit-1.20/debian/rules jigit-1.20/debian/rules
--- jigit-1.20/debian/rules 2013-12-19 15:44:03.0 +0100
+++ jigit-1.20/debian/rules 2016-09-05 20:02:47.0 +0200
@@ -6,7 +6,11 @@
 #export DH_VERBOSE=1
 
 DPKG_EXPORT_BUILDFLAGS = 1
+include /usr/share/dpkg/architecture.mk
 include /usr/share/dpkg/buildflags.mk
+ifeq ($(origin CC),default)
+   CC = $(DEB_HOST_GNU_TYPE)-gcc
+endif
 
 build: build-arch build-indep
 build-arch: build-stamp
@@ -17,8 +21,8 @@
 
# Add here commands to compile the package.
AUTOMAKE='automake --foreign' dh_autoreconf
-   cd libjte && ./configure --prefix=/usr
-   $(MAKE)
+   dh_auto_configure --sourcedirectory libjte
+   $(MAKE) CC=$(CC)
 
touch build-stamp
 

Bug#834235: pdns-recursor: FTBFS on !linux archs

[Christian Hofstaedtler]

Control: tags -1 + wontfix

This has a high chance of silently breaking in the future, and I'm
not going to test on !linux archs. As I'm highly opposed to shipping
untested stuff, I'd rather not apply this patch.

-- 
 ,''`.  Christian Hofstaedtler 
: :' :  Debian Developer
`. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
  `-

Bug#836416: libreoffice: Depends on both fonts-sil-gentium-basic and fonts-dejavu

[Fabian Greffrath]

Am Montag, den 05.09.2016, 16:28 +0200 schrieb Rene Engelhard:
> [ becomes *a bit* offtopic regarding your bug, but... ]

Indeed, sorry. To summarize, I think by now this bug is about (1)
extending the description of the libreoffice meta-package to mention
that additional packages are installed in order to match an upstream
Libreoffice installation as closely as possible and (2) considering
fonts-croscore as an alternative dependency to fonts-liberation.

> Hmm? I don't get that. Liberation is the replacement for Arial etc,
> ttbomk.

fonts-croscore is Google's variant of Red Hat's fonts-liberation. It
provides wider glyph coverage under a "better" license (i.e. SIL OFL),
but lacks the Sans Narrow variant and has Liberation's carfully crafted
hinting replaced by some auto-hinting. Fedora maintains this font under
the Liberation v2 name, but has currently reverted back to using the
Liberation v1 fonts again because of the hinting issues.

Anyway, the fonts in fonts-croscore fit well visually with the ones in
fonts-crosextra-*, so I think it should be possible to replace fonts-
liberation for the former. Maybe this is also something that should be
brought to consideration upstream.

> Well, upstreams "deb"-download? :)

Wow, thanks for this massive list of packages. What I was actually
going to ask for, though, was a line somewhere in the build scripts
that has all the fonts listed that will go into a standard upstream
install. But I guess you already provided that in the last paragraph,
so thank you! ;)

Cheers,

Fabian


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

Bug#836790: RM: django-localflavor -- ROM; Package no longer a reverse dependency for wtforms, has 2 rc bugs and no users

[Orestis Ioannou]

Package: ftp.debian.org
Severity: normal

Hello,

I initially uploaded django-localflavor as a reverse dep for wtforms. It is no
longer the case and the package has 2 rc bugs + no users. I am no longer
interested in the package and i believe that removing it is better than
orphaning.

Cheers,

Orestis

Bug#836728: kde-spectacle: Please provide .desktop file for ksnapshot

[Salvo Tomaselli]

> Which is expected, since ksnapshot is not supposed to be installed
> anymore.

Yes but how would I know that? I just saw an update installing some
more stuff, which isn't unusual.

my 1st thought was "ksnapshot is broken".

> While spectacle does everything ksnapshot did, it is not compatibile
> with it: spectacle does not have the same the command line options
> ksnapshot had, so adding a ksnapshot -> spectacle symlink means there
> could be options mismatches.
What about a desktop file with a name field like "ksnapshot ->
spectacle"? as it was done for the change to firefox?

Bug#728191: Update on assaultcube-data

[Nicolás Ortega]

I've managed to start packaging assaultcube-data. There are still some
things that I have forgotten (like updating copyright and stuff like
that, along with fixing lintian errors), but it should be finished soon
(along with the main assaultcube package). You can find the package at
the following link:

https://mentors.debian.net/package/assaultcube-data

-- 
Nicolás A. Ortega (Deathsbreed)
http://themusicinnoise.net/

Bug#825512: jessie-pu: package policykit-1/0.105-15~deb8u1

[Adam D. Barratt]

Hi,

On Mon, 2016-09-05 at 18:16 +0200, Michael Biebl wrote:
> sd_uid_get_state() is apparently broken in jessie with systemd-logind
> under sysvinit. This was fixed in a later systemd version, that's why
> no-one ever noticed it in unstable/testing.
> 
> debian/patches/0.113/sessionmonitor-systemd-Use-sd_uid_get_state-to-check.patch
> and
> debian/patches/0.113/sessionmonitor-systemd-prepare-for-D-Bus-user-bus-mo.patch
> 
> where added to support the systemd --user / D-Bus user model.
> This is not really a concern for jessie though.
> 
> So my proposal would be, to simply disable those two particular patches.
> Those would be the only change between policykit-1/0.105-15~deb8u1 and
> deb8u2.
> 
> Does that sound ok to you?

Yes, please feel free to upload that; thanks.

Regards,

Adam

Bug#836787: jessie-pu: package pypdf2/1.23+git20141008-1+deb8u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2016-09-05 at 20:06 +0200, Laszlo Boszormenyi (GCS) wrote:
> A PyPDF2 user found a DoS, an infinite loop[1]. It has a reproducer
> even. This affects Jessie as well (the Sid update is just uploaded).
> Upstream fix is simple[2] and the Security Team noted this as no-dsa,
> but can be updated via a Jessie PU.

Please go ahead.

Regards,

Adam

Bug#829046: Status of pagure

[Sergio Durigan Junior]

On Sunday, September 04 2016, Ben Finney wrote:

>> To be fair, I recently packaged selectize.js (which also depends on
>> Grunt), and I spent a big time creating a replacement for it using
>> only GNU tools available on Debian, but I don't feel like doing that
>> for every other library.
>
> Please join the discussion at the ‘pkg-javascript-devel’ forum
> 
> to join forces with others in tackling this problem.

To be honest, I do not have time nor interest now to spend my energy
solving this JS problem.  My total focus now is getting pagure ready for
Debian in the best way I can.  Also, from my recent experience packaging
some JS libs, I fear that the building issue will not be solved in the
near future.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#836789: ITP: vagrant-mutate -- convert vagrant boxes to work with different providers

[Hans-Christoph Steiner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: wnpp
Severity: wishlist
Owner: "Hans-Christoph Steiner" 

* Package name: vagrant-cachier
  Version : 1.2.0
  Upstream Author : Fabio Rehm
* URL : https://github.com/sciurus/vagrant-mutate
* License : MIT
  Programming Lang: Ruby
  Package source  :
https://anonscm.debian.org/git/pkg-ruby-extras/vagrant-mutate.git
  Description : convert vagrant boxes to work with different provide
rs

Vagrant-mutate is a vagrant plugin to convert vagrant boxes to work
with different providers.
Supported Conversions

Virtualbox to kvm
Virtualbox to libvirt
Virtualbox to bhyve
Libvirt to kvm
Kvm to libvirt
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJXzbehAAoJED4XeBe6G5v6wjYIAIt1EyOn/uGU5n9g+dSOz2OR
+kCnretHtKOQm3KRePdD/ZFwBsCKoy789Tj1nYjUdHj0VAbgWjkRpO0WgIrf1LEV
1hBiJBoZ2bLaCmdgVjogzSQlcm72QJMKKlY7dOvOHMYUoe2Al1ERN7qDyLXegfNL
9dWrt55svFtfYibQKidQMqUNtviUMPuvxS8dPEuynidcbDdNnWGVsD/e3uKZk97y
FanNFreEI2zJBOp1IUjtMbEVkVVwSMC/bBhu7tT1L4n5Xd5fOyoVgi6QsZnd7glH
660qt8+tsmHaev0KpdhI+vlu0dHO/ChNYNeFb6IapVEZIlAfWxo4BhVpnFxul8M=
=b794
-END PGP SIGNATURE-

Bug#836788: inn: not installable in sid

[Ralf Treinen]

Package: inn
Version: 1:1.7.2q-44.1
Severity: serious
User: trei...@debian.org
Usertags: edos-uninstallable

Hi,

inn is not installable in sid on any architecture. This is the case at
least since 2015-12-20. The reason is that it depends on libperl5.20
(>= 5.20.2), which does not exist in sid.

-Ralf.

Bug#836787: jessie-pu: package pypdf2/1.23+git20141008-1+deb8u1

[Laszlo Boszormenyi (GCS)]

Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu

Hi Release Team,

A PyPDF2 user found a DoS, an infinite loop[1]. It has a reproducer
even. This affects Jessie as well (the Sid update is just uploaded).
Upstream fix is simple[2] and the Security Team noted this as no-dsa,
but can be updated via a Jessie PU.

Proposed patch is attached.

Thanks for considering,
Laszlo/GCS
[1] https://github.com/mstamy2/PyPDF2/issues/184
[2] 
https://github.com/mstamy2/PyPDF2/commit/4fc7f9d14adb2a9b890aea2616955ec54229f48cdiff -Nru pypdf2-1.23+git20141008/debian/changelog pypdf2-1.23+git20141008/debian/changelog
--- pypdf2-1.23+git20141008/debian/changelog	2014-10-25 21:00:12.0 +
+++ pypdf2-1.23+git20141008/debian/changelog	2016-09-05 17:50:32.0 +
@@ -1,3 +1,10 @@
+pypdf2 (1.23+git20141008-1+deb8u1) jessie; urgency=medium
+
+  * Backport fix 'prevent infinite loop in readObject() function' to prevent
+DoS from upstream Git tree.
+
+ -- Laszlo Boszormenyi (GCS)   Mon, 05 Sep 2016 17:46:41 +
+
 pypdf2 (1.23+git20141008-1) unstable; urgency=low
 
   * Upstream snapshot with various bug fixes.
diff -Nru pypdf2-1.23+git20141008/debian/patches/Prevent_infinite_loop_in_readObject.patch pypdf2-1.23+git20141008/debian/patches/Prevent_infinite_loop_in_readObject.patch
--- pypdf2-1.23+git20141008/debian/patches/Prevent_infinite_loop_in_readObject.patch	1970-01-01 00:00:00.0 +
+++ pypdf2-1.23+git20141008/debian/patches/Prevent_infinite_loop_in_readObject.patch	2016-09-05 17:49:22.0 +
@@ -0,0 +1,25 @@
+From 48193975e5a0e48ebbb68217f8533ad2bfbdede2 Mon Sep 17 00:00:00 2001
+From: Henri Salo 
+Date: Tue, 18 Aug 2015 13:42:22 +0300
+Subject: [PATCH] Prevent infinite loop in readObject() function. Patch by
+ dhudson1. Closes mstamy2/PyPDF2#184
+
+---
+ PyPDF2/generic.py | 4 
+ 1 file changed, 4 insertions(+)
+
+diff --git a/PyPDF2/generic.py b/PyPDF2/generic.py
+index df1e028..657612a 100644
+--- a/PyPDF2/generic.py
 b/PyPDF2/generic.py
+@@ -82,6 +82,10 @@ def readObject(stream, pdf):
+ # comment
+ while tok not in (b_('\r'), b_('\n')):
+ tok = stream.read(1)
++# Prevents an infinite loop by raising an error if the stream is at
++# the EOF
++if len(tok) <= 0:
++raise PdfStreamError("File ended unexpectedly.")
+ tok = readNonWhitespace(stream)
+ stream.seek(-1, 1)
+ return readObject(stream, pdf)
diff -Nru pypdf2-1.23+git20141008/debian/patches/series pypdf2-1.23+git20141008/debian/patches/series
--- pypdf2-1.23+git20141008/debian/patches/series	1970-01-01 00:00:00.0 +
+++ pypdf2-1.23+git20141008/debian/patches/series	2016-09-05 17:50:00.0 +
@@ -0,0 +1 @@
+Prevent_infinite_loop_in_readObject.patch

Bug#785799: [festvox-ca-ona-hts] Since las festival upgrade, catalan voice is not correctly recognized and does not work

[Guillem Jover]

Control: severity -1 serious

Hi!

On Wed, 2015-05-20 at 12:41:04 +0200, Sergio Oller Moreno wrote:
> Festival 2.4 seems to break compatibility with previous festival 2.1
> HTS voices.
> 
> I will update the Catalan voices as soon as possible (ideally this week)
> to be compatible with festival 2.4 and I will check if there are other
> HTS voices in Debian.

Bumping the severity as this pretty much makes the package unsuitable
for release.

Oh, and I was going to propose that if doing the necessary changes
were too involved, packaging the clunits variants might be an option,
but then just noticed that there's now a new upstream release. So if
you need a sponsor to update the package, please let me know!

Thanks,
Guillem

Bug#833727: emacs24: FTBFS with glibc 2.24

[Aurelien Jarno]

On 2016-09-05 12:31, Rob Browning wrote:
> Aurelien Jarno  writes:
> 
> > The patch i have attached is actually a backport of the above patch. It
> > was present in various branches, so I might have backported one with a
> > different commit number, but in practice it's the same.
> 
> Assuming you mean the gmalloc patch, do you know if there's a very
> similar patch upstream?  The one you've attached is quite a bit
> different than the one I quoted.

Yes, the 0020-Always-define-gmalloc-etc.-in-src-gmalloc.c.patch actually
comes from upstream commit 4b1436b702d56eedd27a0777fc7232cdfb7ac4f6.

It looks different given that the emacs 24 branch do not include the
commits to add hybrid malloc [2] and thus some #undef #define are needed
instead of changing the HYBRID_MALLOC conditional.

OTOH, you might want to consider my patch as a mix of [1] and [2].

Aurelien

[1] 
http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=4b1436b702d56eedd27a0777fc7232cdfb7ac4f6
[2] 
http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=ea652500776aacbb8cb64f9ecca16a2d2c7add80

http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=a4817d834e7d125d31049dfb6fd0a0df4782bad0

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

Bug#836780: [Pkg-libvirt-maintainers] Bug#836780: libvirt: New upstream version 2.2.0

[Guido Günther]

On Mon, Sep 05, 2016 at 06:39:49PM +0200, Salvatore Bonaccorso wrote:
> Source: libvirt
> Version: 2.1.0-2
> Severity: wishlist
> 
> Hi Guido
> 
> I know it's only some days ago it was released, but it would be great
> to see libvirt 2.2.0 packaged for sid.

I have already imported an rc a while ago and rebased the patches but
did not get around to fire up the test builds due to limited band width
during available computer time ;)

Cheers,
 -- Guido

Bug#829632: neat: please make the build reproducible

[Chris Lamb]

Dear Maintainer,

> Source: neat
> Version: 2.0-1
> Tags: patch

There hasn't seem to be any update on this bug in 62 days, in which
time the Reproducible Builds effort has come on a long way. :)

Would you consider applying this patch and uploading?


Regards,

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

Bug#829628: irsim: please make the build reproducible

[Chris Lamb]

Dear Maintainer,

> Source: irsim
> Version: 9.7.75-1
> Tags: patch

There hasn't seem to be any update on this bug in 62 days, in which
time the Reproducible Builds effort has come on a long way. :)

Would you consider applying this patch and uploading?


Regards,

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

Bug#835983:

[GCS]

Control: severity -1 important

Hi Raphaël,

On Mon, Sep 5, 2016 at 12:13 PM, Raphael Hertzog  wrote:
> did you see #835983 that I filed a few days ago? I did not offer an NMU
> because I know that you are usually quite reactive...
 Yes, from time to time I get mails on my mobile phone. This means I
can read those at least, but not able to answer those.

I'm not sure that the 'we need this in Kali' justifies the severity,
but sure needs to be solved. The breaks/replaces was added by Jonathan
Wiltshire[1].
Please note that python-pypdf is noted unmaintained[2]:
-- cut --
This page is no longer updated. I've stopped maintaining pyPdf [...]
-- cut --
The fork it refers to as continued development is disappeared. As
such, python-pypdf is not touched for more than six years[3] and it's
Python 2 only which may be deprecated somewhen soon. As I know, Ubuntu
doesn't ship it anymore for example. In the contrary, PyPDF2 has
Python 3 support, constantly updated and supported[4].
I think it would be better to update your software for PyPDF2 support.

> If the package had been part of the python-modules team, I would have
> fixed it by myself but for some reason you are the sole maintainer.
> If you need an NMU to help you, let me know.
 I'm going to upload a new package revision soon.

Regards,
Laszlo/GCS
[1] https://packages.qa.debian.org/p/pypdf2/news/20141010T113501Z.html
[2] http://pybrary.net/pyPdf/
[3] https://github.com/mfenniak/pyPdf/commits/trunk
[4] https://github.com/mstamy2/PyPDF2/commits/master

Bug#836786: diffoscope: Differences between long lines are missing in HTML format

[Emanuel Bronshtein]

Source: diffoscope
Severity: normal

Dear Maintainer,

The packages "python-hypothesis" & "cppformat" & "python-xmp-toolkit" & 
"python-mne" from unstable/amd64 have long line that contain JavaScript code, 
the HTML format don't contain the differences between the lines (it cut the 
line by scissors symbol instead)

searchindex.js:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/python-hypothesis.html

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/cppformat.html

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/python-xmp-toolkit.html

bootstrap.min.js:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/python-mne.html


Suggestion for fixes:
1. The above examples are minified JavaScript code, thus it's possible to use 
JavaScript beautifier on JavaScript files (*.js) and then compare the results.
2. Add JavaScript code to the HTML format that will expand the view when 
scissors is clicked (or don't cut the line at all)

Bug#836381: RFS: couchapp/1.0.2+dfsg1-1

[Gianfranco Costamagna]

Hi Gustavo


>> INSTALL_REQUIRES = ['restkit==4.2.2', 'watchdog==0.6.0']

>> why is restkit manually listed in runtime dependencies?
>
>that's for setuptools, I could patch it out, but why?


please read what I wrote :)
python-restkit is a build-dependency, and listed in install_requires keyword.
dh_python2 should pick it up automagically and translate it into
a runtime-dependency in ${python:Depends}

please remove it, and check if the dependency is correctly added in the binary
file (debian/control)

>no, is not wrong
>$ git clone
>https://anonscm.debian.org/cgit/collab-maint/couchapp.git
>Cloning into 'couchapp'...


yes, I know it works, but probably because of some rewrite rule in collab-maint 
git
apache configuration.
I still prefer to have them separate, because it won't work on other non alioth 
git repo.
(and some bad copy-paste might introduce such issues)

(this *isn't* a blocker for this upload, feel free to keep it that way)

>restkit doest not have a python3 package, nose-testconfig does not work on
>python3 AFAIK, and it is necesary for tests
>
>the mention in README.md about python3 is to host the coverage
>reports


ack thanks


>thanks, how did you find it? licensecheck didn't!


some grep copyright . -Ri ; grep license . -Ri
and debdiff between the two versions did spot it

(did you remove such file in debian/repack script?)

>PS: I've added autopkgtest support to the package :)

nice!
this is always appreciated.

Ready for a next ping on the above points :)

G.

Bug#836784: diffoscope: Several "Too much input for diff" on debian packages from unstable/amd64

[Ximin Luo]

Emanuel Bronshtein:
> Source: diffoscope
> Severity: normal
> 
> Dear Maintainer,
> 
> The packages "esajpip" & "aptly" & "nikwi" from unstable/amd64:
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/esajpip.html
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/aptly.html
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/nikwi.html
> 
> return "Too much input for diff" instead of meaningful diff.
> 

Hi Emanuel, try setting the --max-diff-input-lines flag to a higher value. In 
the next version we'll let "0" mean "unlimited" as well as having a --no-max 
value to disable all such limits.

If you are satisfied with this, please close this bug - otherwise please 
suggest something concrete that we can do to satisfy you.

(The reason for this input limit is that diff(1) reads the whole file into 
memory, so runs out of memory for very large files.)

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git