Processed: Mail::DeliveryStatus::BounceParser contains a live virus and some real spam/phishing mails

[Debian Bug Tracking System]

Processing control commands:

> forwarded -1 Ricardo Signes 
Bug #864800 [src:libmail-deliverystatus-bounceparser-perl] 
Mail::DeliveryStatus::BounceParser contains a live virus and some real 
spam/phishing mails
Set Bug forwarded-to-address to 'Ricardo Signes '.
> found -1 1.536-1
Bug #864800 [src:libmail-deliverystatus-bounceparser-perl] 
Mail::DeliveryStatus::BounceParser contains a live virus and some real 
spam/phishing mails
Marked as found in versions libmail-deliverystatus-bounceparser-perl/1.536-1.
> found -1 1.542-1
Bug #864800 [src:libmail-deliverystatus-bounceparser-perl] 
Mail::DeliveryStatus::BounceParser contains a live virus and some real 
spam/phishing mails
Marked as found in versions libmail-deliverystatus-bounceparser-perl/1.542-1.

-- 
864800: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864800
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#864800: Mail::DeliveryStatus::BounceParser contains a live virus and some real spam/phishing mails

[Paul Wise]

Source: libmail-deliverystatus-bounceparser-perl
Version: 1.531-1
Severity: serious
X-Debbugs-CC: Ricardo Signes 
Control: forwarded -1 Ricardo Signes 
Control: found -1 1.536-1
Control: found -1 1.542-1
User: debian-ad...@lists.debian.org
Usertags: needed-by-DSA-Team

The Mail::DeliveryStatus::BounceParser source contains a live virus and
some real spam/phishing mails. This is leading to Netcraft and other
virus detection systems on the Internet reporting Debian mirrors as
malicious, which potentially reduces the reputation of debian.org on
various anti-spam and anti-malware services. Please fix this in
upstream git, with a new release on CPAN and in all Debian suites.

https://incident.netcraft.com/w/b0d11ab53944/
https://incident.netcraft.com/w/ffb6f95e5301/

To fix this you will need to strip the account-password.zip attachment
from t/corpus/virus-caused-multiple-weird-reports.msg and if possible
strip the phishing/spam content from the other files, while ensuring
that the tests still pass despite changes to the corpus but that the
new files in the corpus do not trip any anti-virus checkers:

https://www.virustotal.com/

$ clamdscan --fdpass --infected | sed "s|`pwd`/||"
t/corpus/virus-caused-multiple-weird-reports.msg: Win.Worm.Mytob-331 FOUND
t/corpus/spam-with-badly-parsed-email.msg: 
Sanesecurity.Phishing.Ivt.6456.UNOFFICIAL FOUND
t/corpus/spam-lots-of-bogus-addresses.msg: Sanesecurity.Spam.8684.UNOFFICIAL 
FOUND

--- SCAN SUMMARY ---
Infected files: 3
Time: 0.087 sec (0 m 0 s)

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#864793: crashes with JavaScript errors

[Steinar H. Gunderson]

Package: grafana
Version: 2.6.0+dfsg-3
Severity: grave

Hi,

After making a default installation of Grafana, I went to localhost:3000.
I got redirected to http://localhost:3000/login, which is black and otherwise
entirely blank (Chrome 59). The developer console says:

  Uncaught TypeError: Cannot read property 'indexOf' of undefined
  at 
public/vendor/angular-native-dragdrop/draganddrop.js?bust=1497481640638:25
  at 
public/vendor/angular-native-dragdrop/draganddrop.js?bust=1497481640638:390
  jquery.js?bust=1497481640638:3855 Uncaught Error: [$injector:modulerr] Failed 
to instantiate module ang-drag-drop due to:
  Error: [$injector:nomod] Module 'ang-drag-drop' is not available! You either 
misspelled the module name or forgot to load it. If registering a module ensure 
that you specify the dependencies as the second argument.
  http://errors.angularjs.org/1.4.3/$injector/nomod?p0=ang-drag-drop
  at 
http://localhost:3000/public/vendor/angular/angular.js?bust=1497481640638:68:12
  at 
http://localhost:3000/public/vendor/angular/angular.js?bust=1497481640638:1958:17
  at ensure 
(http://localhost:3000/public/vendor/angular/angular.js?bust=1497481640638:1882:38)
  at module 
(http://localhost:3000/public/vendor/angular/angular.js?bust=1497481640638:1956:14)
  at 
http://localhost:3000/public/vendor/angular/angular.js?bust=1497481640638:4362:22
  at forEach 
(http://localhost:3000/public/vendor/angular/angular.js?bust=1497481640638:336:20)
  at loadModules 
(http://localhost:3000/public/vendor/angular/angular.js?bust=1497481640638:4346:5)
  at createInjector 
(http://localhost:3000/public/vendor/angular/angular.js?bust=1497481640638:4272:11)
  at doBootstrap 
(http://localhost:3000/public/vendor/angular/angular.js?bust=1497481640638:1630:20)
  at Object.bootstrap 
(http://localhost:3000/public/vendor/angular/angular.js?bust=1497481640638:1651:12)
  
http://errors.angularjs.org/1.4.3/$injector/modulerr?p0=ang-drag-drop=Er…Fpublic%2Fvendor%2Fangular%2Fangular.js%3Fbust%3D1497481640638%3A1651%3A12)
  at 
http://localhost:3000/public/vendor/angular/angular.js?bust=1497481640638:68:12
  at 
http://localhost:3000/public/vendor/angular/angular.js?bust=1497481640638:1958:17
  at ensure 
(http://localhost:3000/public/vendor/angular/angular.js?bust=1497481640638:1882:38)
  at module 
(http://localhost:3000/public/vendor/angular/angular.js?bust=1497481640638:1956:14)
  at 
http://localhost:3000/public/vendor/angular/angular.js?bust=1497481640638:4362:22
  at forEach 
(http://localhost:3000/public/vendor/angular/angular.js?bust=1497481640638:336:20)
  at loadModules 
(http://localhost:3000/public/vendor/angular/angular.js?bust=1497481640638:4346:5)
  at createInjector 
(http://localhost:3000/public/vendor/angular/angular.js?bust=1497481640638:4272:11)
  at doBootstrap 
(http://localhost:3000/public/vendor/angular/angular.js?bust=1497481640638:1630:20)
  at Object.bootstrap 
(http://localhost:3000/public/vendor/angular/angular.js?bust=1497481640638:1651:12)
  
http://errors.angularjs.org/1.4.3/$injector/modulerr?p0=ang-drag-drop=Er…Fpublic%2Fvendor%2Fangular%2Fangular.js%3Fbust%3D1497481640638%3A1651%3A12)
  at 
http://localhost:3000/public/vendor/angular/angular.js?bust=1497481640638:68:12
  at 
http://localhost:3000/public/vendor/angular/angular.js?bust=1497481640638:4385:15
  at forEach 
(http://localhost:3000/public/vendor/angular/angular.js?bust=1497481640638:336:20)
  at loadModules 
(http://localhost:3000/public/vendor/angular/angular.js?bust=1497481640638:4346:5)
  at createInjector 
(http://localhost:3000/public/vendor/angular/angular.js?bust=1497481640638:4272:11)
  at doBootstrap 
(http://localhost:3000/public/vendor/angular/angular.js?bust=1497481640638:1630:20)
  at Object.bootstrap 
(http://localhost:3000/public/vendor/angular/angular.js?bust=1497481640638:1651:12)
  at HTMLDocument. 
(http://localhost:3000/public/app/app.js?bust=1497481640638:85:19)
  at mightThrow 
(http://localhost:3000/public/vendor/jquery/dist/jquery.js?bust=1497481640638:3570:29)
  at process 
(http://localhost:3000/public/vendor/jquery/dist/jquery.js?bust=1497481640638:3638:12)

I can't find a workaround, and thus, the package seems entirely broken to me.

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

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

Bug#864729: assimp: Bundles ConvertUTF code which is under non-DFSG license

[Dmitry Shachnev]

Hi IOhannes,

On Wed, Jun 14, 2017 at 10:06:27AM +0200, IOhannes m zmölnig wrote:
> thanks a lot for your bug-report.
>
> please do not forget to also file bugs against the remaining packages
> that still use ConvertUTF.c:
>   https://lintian.debian.org/tags/license-problem-convert-utf-code.html

Sorry, I do not intend to start a mass bug filing because there are quite
many packages there.

In this particular case, I noticed the issue in assimp code which is bundled
into qt3d-opensource-src, and decided to report it here, so that qt3d can
benefit from the future fix in your package.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#864719: [Pkg-openldap-devel] Bug#864719: Bug#864719: Bug#864719: slapd: fails to configure when olcSuffix contains a backslash-escaped umlaut

[Karsten Heymann]

Some thoughts about the bug report (sorry for the borked first version
of this mail):

1. There is already code in openldap that maps dn's to paths in the
cn=config backend when it writes the config tree to the file system in
/etc/ldap/slapd.d. Maybe that code or at least its escaping logic can
be reused.
2. Wouldn't it be enough to use the database *number* to uniquely name
the database backup? This would remove the whole problem.
3. In order to use the basedn as a file name that can be safely used
in shell script, what about a whitelist approach that replaces or
encodes any character that is not a (ascii) letter, number, dash or
underscrore with something safe/sane? Seems a better way than the
approach where only certain "bad" characters are replaced. Unicode is
huge, and using a whitelist of known good characters seems a more
defensive approach, especially when prefixed with the database number.
So "o=|\/|y Über Company" would become something like
"db2-yberCompany".

Feedback appreciated.

Processed: severity of 761658 is wishlist

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> severity 761658 wishlist
Bug #761658 {Done: m...@linux.it (Marco d'Itri)} [systemd] Please do not 
default to using Google nameservers
Severity set to 'wishlist' from 'serious'
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
761658: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761658
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: RM: aiccu/20070115-17

[Debian Bug Tracking System]

Processing control commands:

> severity 863720 serious
Bug #863720 [src:aiccu] aiccu: SixXS will shutdown on 2017-06-06
Severity set to 'serious' from 'important'
> found 863720 20070115-14
Bug #863720 [src:aiccu] aiccu: SixXS will shutdown on 2017-06-06
Marked as found in versions aiccu/20070115-14.

-- 
863720: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863720
864783: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864783
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#864719: [Pkg-openldap-devel] Bug#864719: Bug#864719: Bug#864719: slapd: fails to configure when olcSuffix contains a backslash-escaped umlaut

[Karsten Heymann]

Hi guys,

please allow me to add some thoughts to this bug report:

1. Is there any way to re-use the way dn's are mapped to paths by the
cn=config backend for this purpose?

2017-06-14 12:59 GMT+02:00 Thorsten Glaser :
> On Tue, 13 Jun 2017, Ryan Tandy wrote:
>
>>> Hi Thorsten, thanks for reporting this.
>
> You’re welcome.
>
>>> (But I'm curious: how did you wind up with the escaped form on wheezy?  For
>>> me, slapd via ldapmodify and slapadd both write it in base64.)
>
> I’ve first set up the test server, then, in order to reproduce another
> bug mich later, we got an actual LDIF from the customer, so I had to
> change the base DN and import a partial tree of theirs. I used the DN
> as it was written in their LDIF.
>
> This is also the reason the base DN doesn’t match the domain debconf.
>
>> For the backslashes case, the attached ought to do. Would you be willing to
>> test it? It should apply to /var/lib/dpkg/info/slapd.postinst.
>
> The patch works as-is, however, as a shell author and informed about
> writing portable shell scripts, I’m a tad concerned about the use of
> the accent gravis form of command substitution, especially as it can
> *not* be quoted both inside and outside (which is not the case here,
> but someone might decide to do that in the future).
>
> Therefore I’m urging you to change the last addition to…
> +   grep "olcDbDirectory:" $(grep -Fl "olcSuffix: $1" 
> ${SLAPD_CONF}/cn\=config/olcDatabase*.ldif) | cut -d: -f 2 | sed 's/^  *//g'
> … or possibly, quoting, just to be safe:
> +   grep "olcDbDirectory:" "$(grep -Fl "olcSuffix: $1" 
> "${SLAPD_CONF}/cn\=config/olcDatabase*.ldif")" | cut -d: -f 2 | sed 's/^  
> *//g'
>
> (Side note, I cringe every time I see such grep|cut|sed thingies,
> this can almost certainly be done with just sed¹.)
>
>> Still thinking about the base64 case. Since we use the suffix to name files
>> and directories for backup and restore, I guess it's most robust to just use
>> the base64 directly - even if it's not quite as nice for showing to users.
>
> Remember that that can span multiple lines (although this is also true
> for the non-base64 base). I usually just read LDIF line by line in my
> shell scripts concatenating as needed, but for quick, I’ve found this
> useful:
>
> cat² x.ldif | tr '\n' '\001' | sed $'s/\001 //g' | tr '\001' '\n' >y
>
> Note that $'…' needs a shell supporting this ksh93ism / recent addition
> to POSIX (i.e. ksh93, GNU bash, mksh, zsh, but not dash). For this
> purpose it’s commonly accepted to change the shebang of the maintainer
> script to #!/bin/bash (which is still Essential currently). Another
> option would be to embed the control character directly into the script.
> (Actually, perhaps GNU sed can handle 's/\001 //g' just fine? I’m more
> used to BSD sed which honours the standard more.)
>
> bye,
> //mirabilos
>
> ① I’m thinking of something along the lines of:
>
>   sed --posix -n '/^olcDbDirectory: *\([^ ].*\)$/s//\1/p' "$(grep -Fl 
> "olcSuffix: $1" "${SLAPD_CONF}/cn\=config/olcDatabase*.ldif")"
>
>   I think this fully replaces that line of yours.
>
> ② Not a useless use of cat but an example.
>
> --
> tarent solutions GmbH
> Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
> Tel: +49 228 54881-393 • Fax: +49 228 54881-235
> HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
> Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
>
> ___
> Pkg-openldap-devel mailing list
> pkg-openldap-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-openldap-devel

Bug#761658: reliably disable DNS resolving

[Michael Biebl]

Hi

Am 14.06.2017 um 19:49 schrieb benaryorg:
> As this is about the default nameservers to be used when there is
> nothing else configured, how would I disable DNS resolution then?

First of all, systemd-resolved is not used and enabled by default.
If you actually do use systemd-resolved, disabling the
fallback DNS server(s) is trivial.

Either edit /etc/systemd/resolved.conf and set 
FallbackDNS=

or create a drop-in snippet like this:
mkdir /etc/systemd/resolved.conf.d/
echo -e "[Resolve]\nFallbackDNS=" > 
/etc/systemd/resolved.conf.d/no-fallback.conf

Then run systemctl restart systemd-resolved.service.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#761658: reliably disable DNS resolving

[benaryorg]

As this is about the default nameservers to be used when there is
nothing else configured, how would I disable DNS resolution then?

Because I see that this is a technical issue for which there is no
solution mentioned in this bugreport yet.
At least for settling this part of the issue can you please present a
solution that is equal to not configuring any hosts on a system which
does not have it's defaults set?




signature.asc
Description: OpenPGP digital signature

Bug#864775: apt-get: computes wrong upgrade path for chained Pre-Depends on i386

[Julian Andres Klode]

Control: severity -1 important
Version: 1.2.12

On Wed, Jun 14, 2017 at 04:56:19PM +0200, Andreas Beckmann wrote:
> Package: apt
> Version: 1.0.9.8.4
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> Hi,
> 
> during a test with piuparts I noticed the [non-free]
> xserver-xorg-video-nvidia package failed to upgrade from jessie to
> stretch (with --install-recommends disabled) on i386, but succeeded on
> amd64. TTBOMK there shouldn't be any differences in the packaging
> between the architectures.
> 
> The upgrade fails with:
> 
>   dpkg: dependency problems prevent configuration of nvidia-legacy-check:
>nvidia-legacy-check depends on nvidia-installer-cleanup; however:
> Package nvidia-installer-cleanup is not configured yet.
>   
>   dpkg: error processing package nvidia-legacy-check (--configure):
>dependency problems - leaving unconfigured
> 
> There is a Pre-Depends chain
>   xserver-xorg-video-nvidia -> nvidia-legacy-check -> nvidia-installer-cleanup
> and at this point both nvidia-legacy-check and nvidia-installer-cleanup
> have been unpacked, but not configured, yet. There was a 
> nvidia-installer-cleanup
> package in jessie, that was also installed. The nvidia-legacy-check package
> is new in stretch.
> 
> I'm attaching piuparts logs for the upgrades on these two architectures.
> 
> A workaroud is to make the Pre-Depends in nvidia-legacy-check versioned s.t.
> the jessie version of nvidia-installer-cleanup cannot satisfy it. In that
> case the new nvidia-installer-cleanup is configured first before unpacking
> nvidia-legacy-check.
> 
> Assigning this bug to jessie's apt, since that was used to perform the
> dist-upgrade.

I believe that is fixed in 1.2.11 with
  * recheck Pre-Depends satisfaction in SmartConfigure (LP: #1569099)

If not, feel free to reopen. That's a somewhat odd corner case though,
and not release critical.

-- 
Debian Developer - deb.li/jak | jak-linux.org - free software dev
  |  Ubuntu Core Developer |
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to ('inline').  Thank you.

Processed: Re: Bug#864775: apt-get: computes wrong upgrade path for chained Pre-Depends on i386

[Debian Bug Tracking System]

Processing control commands:

> severity -1 important
Bug #864775 [apt] apt-get: computes wrong upgrade path for chained Pre-Depends 
on i386
Severity set to 'important' from 'serious'

-- 
864775: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864775
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: affects 864775

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> affects 864775 + xserver-xorg-video-nvidia
Bug #864775 [apt] apt-get: computes wrong upgrade path for chained Pre-Depends 
on i386
Added indication that 864775 affects xserver-xorg-video-nvidia
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
864775: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864775
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#771790: Fixed with 1.0.0

[Marcos Marado]

Hi, and sorry for the late reply.

1) OK
2) I use it on both stable, testing and unstable, but I'm OK with not
having this available in testing or stable: in fact I think it is better
not to have the buggy version available at all than to have it and then
suffer potential data loss.
3) As you can see from my late reply, I don't really have much time to
spend in these matters. That being said, I wouldn't mind joining the JS
maintainers, even if I'm unsure if anything good would come out of it. In
particular, your e-mail suggests to me that being a JS maintainer still
means finding a sponsor, which really is what I've been feeling as stalling
my contributions (this NMU an example, but also others like this ITP:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=772135 ).

If you still feel it would be useful to have me joining in, please let me
know.

Best regards,

On Tue, May 16, 2017 at 3:02 AM Val Markovic  wrote:

> OK, so talking to pabs@ on debian-mentors, seems like a good approach
> to take here is to do NMU uploads to unstable and stable. I'm happy to
> do the work there (short of uploading, since I can't).
>
> Second part: Marcos, do you use this package on stable, testing or
> unstable? Also note that dirty.js has been removed from testing branch
> because of the RC bug and thus won't be in stretch. So if you'll be
> using stable (which will be stretch soon), this NMU business isn't
> going to help you much.
>
> Third part: it seems like you might want to join Debian JS
> Maintainers. :) It looks like they could use the help, you use their
> packages and have already prepared an NMU upload once, so you know
> your way around deb packaging. Something to consider, especially if
> you use this package and would like to see it continue being
> maintained. :)
>

Processed: Retry after another cup of tea

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> notfound 864746 1.1.1+20160115
Bug #864746 [src:radicale] radicale: Radicale 1.1.3 required to migrate data to 
Radicale 2
The source 'radicale' and version '1.1.1+20160115' do not appear to match any 
binary packages
No longer marked as found in versions radicale/1.1.1+20160115.
> notfound 864746 1.1.1+2016011-2
Bug #864746 [src:radicale] radicale: Radicale 1.1.3 required to migrate data to 
Radicale 2
The source 'radicale' and version '1.1.1+2016011-2' do not appear to match any 
binary packages
No longer marked as found in versions radicale/1.1.1+2016011-2.
> found 864746 1.1.1+20160115-2
Bug #864746 [src:radicale] radicale: Radicale 1.1.3 required to migrate data to 
Radicale 2
Marked as found in versions radicale/1.1.1+20160115-2.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
864746: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864746
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: Re: Bug#864316: libapache2-mod-perl: FTBFS in jessie due to apache2 changes

[Debian Bug Tracking System]

Processing control commands:

> tag -1 patch
Bug #864316 [libapache2-mod-perl2] libapache2-mod-perl: FTBFS in jessie due to 
apache2 changes
Added tag(s) patch.

-- 
864316: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864316
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#864316: libapache2-mod-perl: FTBFS in jessie due to apache2 changes

[Niko Tyni]

Control: tag -1 patch

On Tue, Jun 06, 2017 at 11:06:05PM +0300, Niko Tyni wrote:
> Package: libapache2-mod-perl2
> Version: 2.0.9~1624218-2+deb8u1
> Severity: serious
> 
> As per
> 
>  
> http://perl.debian.net/rebuild-logs/jessie/libapache2-mod-perl2_2.0.9~1624218-2+deb8u1/libapache2-mod-perl2_2.0.9~1624218-2+deb8u1_amd64-2017-06-05T19:42:17Z.build
> 
> this package currently fails to build in jessie.
> 
>   Test Summary Report
>   ---
>   t/apache/read.t   (Wstat: 0 Tests: 1 Failed: 1)
> Failed test:  1
>   t/filter/in_bbs_inject_header.t   (Wstat: 512 Tests: 0 Failed: 0)
> Non-zero exit status: 2
> Parse errors: Bad plan.  You planned 36 tests but ran 0.
>  
> This is very similar to #849082 and was most probably caused by 
> 
>  apache2 (2.4.10-10+deb8u8) jessie-security; urgency=medium

I've verified that the package builds again with the attached
test suite changes (identical to the ones in stretch/sid.)

I've filed #864770 for pushing this to (almost old-)stable.
-- 
Niko
>From 4a803fdb4c9eae8538293fe31c9222eecb6465be Mon Sep 17 00:00:00 2001
From: Niko Tyni 
Date: Fri, 23 Dec 2016 18:27:23 +0200
Subject: [PATCH 1/2] Fix t/apache/read.t HTTP syntax for Apache 2.4.24
 compatibility

HTTP/1.1 RFC 7230, section 2.6. "Protocol Versioning" says the HTTP name
is case sensitive. Starting with Apache 2.4.24, using lower case will
make the server issue a 400 Bad request response, causing a test failure.

https://tools.ietf.org/html/rfc7230#section-2.6

Bug-Debian: https://bugs.debian.org/849082
---
 t/apache/read.t | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/t/apache/read.t b/t/apache/read.t
index 83670c9..9f7f504 100644
--- a/t/apache/read.t
+++ b/t/apache/read.t
@@ -24,7 +24,7 @@ close $fh;
 
 my $size = length $data;
 
-for my $string ("POST $location http/1.0",
+for my $string ("POST $location HTTP/1.0",
 "Content-length: $size",
 "") {
 my $line = "$string\r\n";
-- 
2.11.0

>From d59229cf4f5b91ed58e25e27977e76f59096b72d Mon Sep 17 00:00:00 2001
From: Niko Tyni 
Date: Sat, 24 Dec 2016 23:07:28 +0200
Subject: [PATCH 2/2] Fix in_bbs_inject_header line terminators for Apache
 2.4.24 compatibility

rfc7230 3.5 says:

  Although the line terminator for the start-line and header fields is
   the sequence CRLF, a recipient MAY recognize a single LF as a line
   terminator and ignore any preceding CR.

Apache with strict enabled chooses not to implement the MAY.

Author: Stefan Fritsch 
Bug-Debian: https://bugs.debian.org/849082
---
 t/filter/TestFilter/in_bbs_inject_header.pm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/t/filter/TestFilter/in_bbs_inject_header.pm b/t/filter/TestFilter/in_bbs_inject_header.pm
index b09d6f9..5380c65 100644
--- a/t/filter/TestFilter/in_bbs_inject_header.pm
+++ b/t/filter/TestFilter/in_bbs_inject_header.pm
@@ -181,7 +181,7 @@ sub handler : FilterConnectionHandler {
 
 if ($data and $data =~ /^POST/) {
 # demonstrate how to add a header while processing other headers
-my $header = "$header1_key: $header1_val\n";
+my $header = "$header1_key: $header1_val\r\n";
 push @{ $ctx->{buckets} }, APR::Bucket->new($c->bucket_alloc, $header);
 debug "queued header [$header]";
 }
@@ -199,7 +199,7 @@ sub handler : FilterConnectionHandler {
 # we hit the headers and body separator, which is a good
 # time to add extra headers:
 for my $key (keys %headers) {
-my $header = "$key: $headers{$key}\n";
+my $header = "$key: $headers{$key}\r\n";
 push @{ $ctx->{buckets} }, APR::Bucket->new($c->bucket_alloc, $header);
 debug "queued header [$header]";
 }
-- 
2.11.0

Processed (with 1 error): Re: Bug#863082: pulseaudio: debian/copyright does not contain AGPL-3+ text, and references missing file instead

[Debian Bug Tracking System]

Processing control commands:

> tags -1 help gift
Unknown tag/s: gift.
Recognized are: patch wontfix moreinfo unreproducible fixed potato woody sid 
help security upstream pending sarge sarge-ignore experimental d-i confirmed 
ipv6 lfs fixed-in-experimental fixed-upstream l10n newcomer etch etch-ignore 
lenny lenny-ignore squeeze squeeze-ignore wheezy wheezy-ignore jessie 
jessie-ignore stretch stretch-ignore buster buster-ignore bullseye 
bullseye-ignore.

Bug #863082 [src:pulseaudio] pulseaudio: debian/copyright does not contain 
AGPL-3+ text, and references missing file instead
Added tag(s) help.

-- 
863082: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863082
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: Fix the found version

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> notfound 864746 1.1.1+2016011
Bug #864746 [src:radicale] radicale: Radicale 1.1.3 required to migrate data to 
Radicale 2
The source 'radicale' and version '1.1.1+2016011' do not appear to match any 
binary packages
Ignoring request to alter found versions of bug #864746 to the same values 
previously set
> found 864746 1.1.1+2016011-2
Bug #864746 [src:radicale] radicale: Radicale 1.1.3 required to migrate data to 
Radicale 2
The source 'radicale' and version '1.1.1+2016011-2' do not appear to match any 
binary packages
Marked as found in versions radicale/1.1.1+2016011-2.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
864746: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864746
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#863082: pulseaudio: debian/copyright does not contain AGPL-3+ text, and references missing file instead

[Felipe Sateler]

Control: tags -1 help gift

On Sun, May 21, 2017 at 7:11 PM, Felipe Sateler  wrote:

> On Sun, May 21, 2017 at 10:36 AM, Mattia Rizzolo 
> wrote:
> > Source: pulseaudio
> > Version: 10.0-1
> > Severity: serious
> >
> > the copyright file has this paragraph:
> >
> > |Files: src/utils/qpaeq
> > |Copyright: 2009  Jason Newton 
> > |License: AGPL-3+
> > | This program is free software: you can redistribute it and/or modify
> > | it under the terms of the GNU Affero General Public License as
> > | published by the Free Software Foundation, either version 3 of the
> > | License, or (at your option) any later version.
> > | .
> > | This program is distributed in the hope that it will be useful,
> > | but WITHOUT ANY WARRANTY; without even the implied warranty of
> > | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > | GNU Affero General Public License for more details.
> > | .
> > | On Debian systems, the complete text of the AGPL 3 can be found in
> > | /usr/share/doc/pulseaudio/AGPL
> >
> >
> > This is not acceptable for our current policy for the same points:
> >
> > * said file /usr/share/doc/pulseaudio/AGPL is missing, it appears to be
> >   compressed instead
> > * so /use/share/doc/pulseaudio/AGPL.gz iscompressed, and quoting the
> >   policy "This file must neither be compressed nor be a symbolic link"
>
> Indeed, it was compressed by dh_compress. I need to add an exclusion
>
> > * there are binaries shipped by src:pulseaudio which do not depend on
> >   the pulseaudio binary package, thus totally missing the AGPL-3 text
>
> All packages ship AGPL file, but indeed the reference is to the
> pulseaudio package directory. Will fix.
>
> > * policy does not consider files different than
> >   /usr/share/doc//copyright to be possible, except for a few cases
> >   explicitly listed there (where this is not one of those)
>
> `grep usr/share/doc /usr/share/doc/*/copyright` in my system lists
> several files making references to copyright in other files. Policy
> might need to be updated.
>

I've found myself lacking the time to do this. NMU welcome.


-- 

Saludos,
Felipe Sateler

Processed: Re: Bug#864768: libquartz2-java: Disable the update checker

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> severity 864768 serious
Bug #864768 [libquartz2-java] libquartz2-java: Disable the update checker
Severity set to 'serious' from 'important'
> tags 864768 + security
Bug #864768 [libquartz2-java] libquartz2-java: Disable the update checker
Added tag(s) security.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
864768: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864768
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: Re: Bug#864768: libquartz2-java: Disable the update checker

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> severity 864769 serious
Bug #864769 [src:libquartz-java] libquartz-java: Disable the update checker
Severity set to 'serious' from 'important'
> tags 864769 + security
Bug #864769 [src:libquartz-java] libquartz-java: Disable the update checker
Added tag(s) security.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
864769: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864769
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: bug 840516 is forwarded to https://github.com/graphite-project/graphite-web/pull/1960

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> forwarded 840516 https://github.com/graphite-project/graphite-web/pull/1960
Bug #840516 [graphite-web] doesn't work with django 1.10
Set Bug forwarded-to-address to 
'https://github.com/graphite-project/graphite-web/pull/1960'.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
840516: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=840516
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#864719: [Pkg-openldap-devel] Bug#864719: Bug#864719: slapd: fails to configure when olcSuffix contains a backslash-escaped umlaut

[Thorsten Glaser]

On Tue, 13 Jun 2017, Ryan Tandy wrote:

>> Hi Thorsten, thanks for reporting this.

You’re welcome.

>> (But I'm curious: how did you wind up with the escaped form on wheezy?  For
>> me, slapd via ldapmodify and slapadd both write it in base64.)

I’ve first set up the test server, then, in order to reproduce another
bug mich later, we got an actual LDIF from the customer, so I had to
change the base DN and import a partial tree of theirs. I used the DN
as it was written in their LDIF.

This is also the reason the base DN doesn’t match the domain debconf.

> For the backslashes case, the attached ought to do. Would you be willing to
> test it? It should apply to /var/lib/dpkg/info/slapd.postinst.

The patch works as-is, however, as a shell author and informed about
writing portable shell scripts, I’m a tad concerned about the use of
the accent gravis form of command substitution, especially as it can
*not* be quoted both inside and outside (which is not the case here,
but someone might decide to do that in the future).

Therefore I’m urging you to change the last addition to…
+   grep "olcDbDirectory:" $(grep -Fl "olcSuffix: $1" 
${SLAPD_CONF}/cn\=config/olcDatabase*.ldif) | cut -d: -f 2 | sed 's/^  *//g'
… or possibly, quoting, just to be safe:
+   grep "olcDbDirectory:" "$(grep -Fl "olcSuffix: $1" 
"${SLAPD_CONF}/cn\=config/olcDatabase*.ldif")" | cut -d: -f 2 | sed 's/^  *//g'

(Side note, I cringe every time I see such grep|cut|sed thingies,
this can almost certainly be done with just sed¹.)

> Still thinking about the base64 case. Since we use the suffix to name files
> and directories for backup and restore, I guess it's most robust to just use
> the base64 directly - even if it's not quite as nice for showing to users.

Remember that that can span multiple lines (although this is also true
for the non-base64 base). I usually just read LDIF line by line in my
shell scripts concatenating as needed, but for quick, I’ve found this
useful:

cat² x.ldif | tr '\n' '\001' | sed $'s/\001 //g' | tr '\001' '\n' >y

Note that $'…' needs a shell supporting this ksh93ism / recent addition
to POSIX (i.e. ksh93, GNU bash, mksh, zsh, but not dash). For this
purpose it’s commonly accepted to change the shebang of the maintainer
script to #!/bin/bash (which is still Essential currently). Another
option would be to embed the control character directly into the script.
(Actually, perhaps GNU sed can handle 's/\001 //g' just fine? I’m more
used to BSD sed which honours the standard more.)

bye,
//mirabilos

① I’m thinking of something along the lines of:

  sed --posix -n '/^olcDbDirectory: *\([^ ].*\)$/s//\1/p' "$(grep -Fl 
"olcSuffix: $1" "${SLAPD_CONF}/cn\=config/olcDatabase*.ldif")"

  I think this fully replaces that line of yours.

② Not a useless use of cat but an example.

-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#857986: request not to remove the package as people asked

[Thierry Vilmart]

Jonas Smedegaard wrote:

> Exactly: Packages poorly _maintained_ should be removed.  E.g. npm!
> My point in previous post was that focusing only on the workload for 
> _initial_ packaging masks the actual real workload, which is being 
> discussed here!
> - Jonas

I agree. If it is too complicated to maintain nodejs and npm packages, they 
should be removed for security reasons. There could be a vulnerability in the 
nodejs web server.

Serious professionals will have to install tar balls from the official web 
pages.

Thierry Vilmart

Bug#840516: patterns are deprecated

[Vincent Bernat]

 ❦  8 mai 2017 10:38 GMT, Stephane Bortzmeyer  :

> There are several reasons why graphite-web does not work with Django
> 1.10 (the current version in sid). One of them is that it uses the
> "patterns" variable:

This seems to have been fixed upstream (but unreleased):

https://github.com/graphite-project/graphite-web/commit/bf8e53b15b957d63cf2b85e679d931093c764e9d
-- 
Choose variable names that won't be confused.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#864729: assimp: Bundles ConvertUTF code which is under non-DFSG license

[Debian/GNU]

On 2017-06-13 18:26, Dmitry Shachnev wrote:
> Source: assimp
> Version: 3.3.1~dfsg-4
> Severity: serious
> 
> Dear maintainer,
> 
> assimp seems to bundle ConvertUTF library which is under a non-DFSG license.

thanks a lot for your bug-report.

pease do not forget to also file bugs against the remaining packages
that still use ConvertUTF.c:
  https://lintian.debian.org/tags/license-problem-convert-utf-code.html

mfadr
IOhannes

Bug#864746: radicale: Radicale 1.1.3 required to migrate data to Radicale 2

[Jonas Smedegaard]

Quoting Timo Boettcher (2017-06-14 00:59:50)
> according to the radicale 1 to 2 migration guide 
> http://radicale.org/1to2/
> 
>   "Calendars and address books are stored in a different way between 
>   1.x.x and 2.0.x versions. Launching 2.0.x without migrating your 
>   collections first will not work, Radicale won’t be able to read your 
>   previous data." "To migrate data to Radicale 2.0.x the command line 
>   argument --export-storage was added to Radicale 1.1.3."
> 
> As Radicale 1.1.3 is currently the newest release of the Radicale 
> 1.1.x branch, it is the ownly Radicale release providing the ability 
> to convert existing data stored in radicale installations to the 
> format required by Radicale 2.x.x.
> 
> Currently, Radicale 1.1.3 is not available as Debian package. To 
> enable continued use of the Radicale package by Debian users in the 
> future 2.x.x releases (already in experimental), I kindly ask Radicale 
> 1.1.3 to be packaged or the --export-storage functionality backported.
> 
> This would ensure that this functionality is rolled out once it is 
> needed when migration to Radicale 2.x.x is required.

Thanks for reporting.

Yes, we need to include the recently added --export-storage option in 
order to have a migration path to newer upstream releases.

Since the radicale package targeted the upcoming stable Debian release 
is ahead of the older 1.x branch, we need to backport that code change.  
And then convince Debian release managers to get that change accepted 
into a point release of stable Debian.

Also, I believe we should add a package-specific routine to create a 
backup to /var/backup each time the package is updated, similar to how 
slapd and ejabberd does it.  And get that change into a point release 
too.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#864744: marked as done (texlive-formats-extra: fails to install: fmtutil failed)

[Debian Bug Tracking System]

Your message dated Wed, 14 Jun 2017 06:43:40 +
with message-id 
and subject line Bug#864744: fixed in texlive-extra 2017.20170614-1
has caused the Debian Bug report #864744,
regarding texlive-formats-extra: fails to install: fmtutil failed
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
864744: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864744
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: texlive-formats-extra
Version: 2017.20170613-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

texlive-formats-extra fails to install in experimental:

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package texlive-formats-extra.
  (Reading database ... 
(Reading database ... 21085 files and directories currently installed.)
  Preparing to unpack .../texlive-formats-extra_2017.20170613-1_all.deb ...
  Unpacking texlive-formats-extra (2017.20170613-1) ...
  Processing triggers for tex-common (6.06) ...
  Running mktexlsr. This may take some time... done.
  Setting up texlive-formats-extra (2017.20170613-1) ...
  Processing triggers for tex-common (6.06) ...
  Running updmap-sys. This may take some time... done.
  Running mktexlsr /var/lib/texmf ... done.
  Building format(s) --all.
This may take some time... 
  fmtutil failed. Output has been stored in
  /tmp/fmtutil.mSH219t8
  Please include this file if you report a bug.
  
  dpkg: error processing package tex-common (--configure):
   subprocess installed post-installation script returned error exit status 1
  Errors were encountered while processing:
   tex-common


The (probably) relevant part from the fmtutil logfile:

[...]
fmtutil [INFO]: --- remaking pdfjadetex with pdftex
fmtutil: running `pdftex -ini   -jobname=pdfjadetex -progname=pdfjadetex 
*pdfjadetex.ini' ...
This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017/Debian) (INITEX)
 restricted \write18 enabled.
entering extended mode
(/usr/share/texlive/texmf-dist/tex/jadetex/base/pdfjadetex.ini
(/usr/share/texlive/texmf-dist/tex/latex/latexconfig/pdflatex.ini
(/var/lib/texmf/tex/generic/config/pdftexconfig.tex)
(/usr/share/texlive/texmf-dist/tex/latex/base/latex.ltx
(/usr/share/texlive/texmf-dist/tex/latex/base/texsys.cfg)
./texsys.aux found


\@currdir set to: ./.


Assuming \openin and \input 
have the same search path.


Defining UNIX/DOS style filename parser.

catcodes, registers, parameters,
LaTeX2e <2017-04-15>
hacks, control, par, spacing, files, font encodings, lengths,


Local config file fonttext.cfg used


(/usr/share/texlive/texmf-dist/tex/latex/base/fonttext.cfg
(/usr/share/texlive/texmf-dist/tex/latex/base/fonttext.ltx
=== Don't modify this file, use a .cfg file instead ===

(/usr/share/texlive/texmf-dist/tex/latex/base/omlenc.def)
(/usr/share/texlive/texmf-dist/tex/latex/base/t1enc.def)
(/usr/share/texlive/texmf-dist/tex/latex/base/ot1enc.def)
(/usr/share/texlive/texmf-dist/tex/latex/base/omsenc.def)
(/usr/share/texlive/texmf-dist/tex/latex/base/t1cmr.fd)
(/usr/share/texlive/texmf-dist/tex/latex/base/ot1cmr.fd)
(/usr/share/texlive/texmf-dist/tex/latex/base/ot1cmss.fd)
(/usr/share/texlive/texmf-dist/tex/latex/base/ot1cmtt.fd)))


Local config file fontmath.cfg used


(/usr/share/texlive/texmf-dist/tex/latex/base/fontmath.cfg
(/usr/share/texlive/texmf-dist/tex/latex/base/fontmath.ltx
=== Don't modify this file, use a .cfg file instead ===

(/usr/share/texlive/texmf-dist/tex/latex/base/omlcmm.fd)
(/usr/share/texlive/texmf-dist/tex/latex/base/omscmsy.fd)
(/usr/share/texlive/texmf-dist/tex/latex/base/omxcmex.fd)
(/usr/share/texlive/texmf-dist/tex/latex/base/ucmr.fd)))


Local config file preload.cfg used

=
(/usr/share/texlive/texmf-dist/tex/latex/base/preload.cfg
(/usr/share/texlive/texmf-dist/tex/latex/base/preload.ltx)) page nos., x-ref,
environments, center, verbatim, math definitions, boxes, title, sectioning,
contents, floats, footnotes, index, bibliography, output,
===
Local configuration file hyphen.cfg used
===
(/usr/share/texlive/texmf-dist/tex/generic/babel/hyphen.cfg
(/usr/share/texlive/texmf-dist/tex/generic/babel/switch.def)
(/usr/share/texlive/texmf-dist/tex/generic/hyphen/hyphen.tex)

Processed: your mail

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> severity 767465 normal
Bug #767465 [installation-reports] Installed Debian Jessie fails to recognize 
USB flash drive upon reboot
Severity set to 'normal' from 'serious'
>
End of message, stopping processing here.

Please contact me if you need assistance.
-- 
767465: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767465
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#864750: marked as done (texlive-base: dvipdfmx.def is broken)

[Debian Bug Tracking System]

Your message dated Wed, 14 Jun 2017 06:20:18 +
with message-id 
and subject line Bug#864750: fixed in texlive-base 2017.20170614-1
has caused the Debian Bug report #864750,
regarding texlive-base: dvipdfmx.def is broken
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
864750: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864750
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: texlive-base
Version: 2017.20170613-1
Severity: serious
Justification: broken


dvipdfmx.def is missing a }, so dvipdmfx is broken for now in experimental.
This is already fixed upstream, we need new packages.
--- End Message ---
--- Begin Message ---
Source: texlive-base
Source-Version: 2017.20170614-1

We believe that the bug you reported is fixed in the latest version of
texlive-base, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 864...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Norbert Preining  (supplier of updated texlive-base 
package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Wed, 14 Jun 2017 12:09:43 +0900
Source: texlive-base
Binary: texlive-base texlive-latex-base texlive-latex-recommended 
texlive-fonts-recommended texlive-pictures texlive-luatex texlive-metapost 
texlive-xetex texlive-lang-african texlive-lang-indic 
texlive-generic-recommended texlive-generic-extra texlive-plain-extra 
texlive-htmlxml texlive-omega luasseq texlive texlive-full 
texlive-fonts-recommended-doc texlive-latex-base-doc 
texlive-latex-recommended-doc texlive-metapost-doc texlive-pictures-doc
Architecture: source all
Version: 2017.20170614-1
Distribution: experimental
Urgency: medium
Maintainer: Debian TeX Maintainers 
Changed-By: Norbert Preining 
Description:
 luasseq- TeX Live: transitional dummy package
 texlive- TeX Live: A decent selection of the TeX Live packages
 texlive-base - TeX Live: Essential programs and files
 texlive-fonts-recommended - TeX Live: Recommended fonts
 texlive-fonts-recommended-doc - TeX Live: Documentation files for 
texlive-fonts-recommended
 texlive-full - TeX Live: metapackage pulling in all components of TeX Live
 texlive-generic-extra - TeX Live: transitional dummy package
 texlive-generic-recommended - TeX Live: transitional dummy package
 texlive-htmlxml - TeX Live: transitional dummy package
 texlive-lang-african - TeX Live: transitional dummy package
 texlive-lang-indic - TeX Live: transitional dummy package
 texlive-latex-base - TeX Live: LaTeX fundamental packages
 texlive-latex-base-doc - TeX Live: Documentation files for texlive-latex-base
 texlive-latex-recommended - TeX Live: LaTeX recommended packages
 texlive-latex-recommended-doc - TeX Live: Documentation files for 
texlive-latex-recommended
 texlive-luatex - TeX Live: LuaTeX packages
 texlive-metapost - TeX Live: MetaPost and Metafont packages
 texlive-metapost-doc - TeX Live: Documentation files for texlive-metapost
 texlive-omega - TeX Live: transitional dummy package
 texlive-pictures - TeX Live: Graphics, pictures, diagrams
 texlive-pictures-doc - TeX Live: Documentation files for texlive-pictures
 texlive-plain-extra - TeX Live: transitional dummy package
 texlive-xetex - TeX Live: XeTeX and packages
Closes: 864750
Changes:
 texlive-base (2017.20170614-1) experimental; urgency=medium
 .
   * new upstream checkout - fix for broken dvipdmfx.def (Closes: #864750)
Checksums-Sha1:
 095f7b8eed147faa0de066f36014eb1b375bce43 3095 texlive-base_2017.20170614-1.dsc
 cc385c716d2bddc69308f587282a0477f94d6f9b 292853820 
texlive-base_2017.20170614.orig.tar.xz
 a097f88ce6f06aa8c1ce8b202928d0339225d82d 13397456 
texlive-base_2017.20170614-1.debian.tar.xz
 2f3c426ce27086a26416d1a3f49cbc00ab057b60 30338 luasseq_2017.20170614-1_all.deb
 2c7b627f6aa7056aafbf030f2a7cd60db428a98e 18690980 
texlive-base_2017.20170614-1_all.deb
 9aa66582653247e5a2d0221df39d684995fdcf8a 12538 
texlive-base_2017.20170614-1_amd64.buildinfo
 be58492cee130afa956259ec522e4bc3486faf00 2659332