Bug#874404: debian mirror debs.pelotas.ifsul.edu.br issues

[Peter Palfrader]

On Tue, 05 Sep 2017, Peter Palfrader wrote:

> It seems your mirror isn't updating correctly at the moment.
> 
> cf.
> https://mirror-master.debian.org/status/mirror-info/debs.pelotas.ifsul.edu.br.html
> 
> Please investigate.
> 
> Also, it is not clear from the data I have right now how often your
> mirror updates. We recommend four runs a day to match the number of
> times the archive updates.

Ping.

It appears you only sync once a week.  That is far too infrequent to be
listed in our mirror list.  Please let me know how you wish to proceed.

Peter
-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#877050: Debian mirror mirror.liquidtelecom.com: out-of-date

[Peter Palfrader]

Package: mirrors
User: mirr...@packages.debian.org
Usertags: mirror-problem may-auto-close
Control: submitter -1 mirr...@debian.org

Hi,

I was checking some things in the Debian mirror universe and noticed
a problem with your mirror:

It seems to not have updated in several days now, cf.
 
https://mirror-master.debian.org/status/mirror-info/mirror.liquidtelecom.com.html

Please investigate.

Also,
o The tracefile
  
http://mirror.liquidtelecom.com/debian/debian/project/trace/mirror.liquidtelecom.com
  suggests that the ftpsync version you are using is old.  Please upgrade.

  Using a modern ftpsync ensures updates are done in the correct order
  so apt clients don't get confused.   In particular, it processes
  translations, contents, and more files that have been added to the
  archive in recent years in the correct stage.  It also should produce
  trace files that contain more information that is useful for us.

  http://ftp.debian.org/debian/project/ftpsync/ftpsync-current.tar.gz

Furthermore,
o we recommend mirrors not sync directly from service aliases such as
  ftp..debian.org (only http is guaranteed to be available at
  ftp..d.o sites).  Maybe change your config to sync from
  the site currently backing the ftp..debian.org service you sync
  from?

Cheers,
-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#874397: debian mirror ftp.arnes.si issues

[Mitja Mihelič]

On 26/09/2017 15:18, Peter Palfrader wrote:

On Tue, 26 Sep 2017, Mitja Mihelič wrote:


The Debian mirror is now also available as an alias.
http://ftp.arnes.si/debian/
https://ftp.arnes.si/debian/

Thanks.

You're welcome.


Regarding rsync, I note ftp.arnes.si::mirrors/debian/ works but
also ftp.arnes.si::debian/ is advertised but doesn't:

| weasel@orinoco:~$ rsync ftp.arnes.si::debian/
| @ERROR: invalid uid debian
| rsync error: error starting client-server protocol (code 5) at main.c(1666) 
[Receiver=3.1.2]

Should this work?

The configuration is fixed now. It should work.

Regards,
Mitja Mihelič

Bug#877049: Debian mirror ftp.rezopole.net: unreachable

[Peter Palfrader]

Package: mirrors
User: mirr...@packages.debian.org
Usertags: mirror-problem may-auto-close
Control: submitter -1 mirr...@debian.org

Hi,

I was checking some things in the Debian mirror universe and noticed
a problem with your mirror.

It appears that requests to it time out for over a day now, cf.
https://mirror-master.debian.org/status/mirror-info/ftp.rezopole.net.html

Please investigate.

Also,
o your trace file suggests suggests that the ftpsync version you are
  using is a bit dated.  Please upgrade.

  Using a modern ftpsync ensures updates are done in the correct order
  so apt clients don't get confused.   In particular, it processes
  translations, contents, and more files that have been added to the
  archive in recent years in the correct stage.  It also should produce
  trace files that contain more information that is useful for us.

  http://ftp.debian.org/debian/project/ftpsync/ftpsync-current.tar.gz

o Furthermore, we recommend mirrors not sync directly from service aliases
  such as ftp..debian.org (only http is guaranteed to be available
  at ftp..d.o sites).  Maybe change your config to sync from the
  site currently backing the ftp..debian.org service you sync from?

Cheers,
-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#706656: ITP: cura -- Controller for 3D printers

[Gregor Riepl]

> Do you plan to maintain these packages as part of the 3dprinter group?
> If so, the maintainer should be changed from your name to the mailing
> list, to make sure the packages show up on
>  https://qa.debian.org/developer.php?login=3dprinter-gene...@lists.alioth.debian.org
>  >.

Ok.

> The packages have outdated standards-version.  The current one is 4.1.0,
> if I am not mistaken.

That must have changed in the meantime...
It was still ok when I packaged 2.5.0 AFAIR.

> You mention that you suspect the lintian issue
> hardening-no-fortify-functions might be a bug in lintian or g++.  I am
> quite sure it is not a bug in lintian, and suggest to not hide it until
> you figure out what is going on.

I did quite a bit of research, and I'm almost certain it's a false positive.
The docs mention posting to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673112 in such a case.
I'll remove the override until this has been done (post-release).

> Did you consider multiarch when structuring the library packages?

I did follow the advice given in the maintainer docs, but I never tested if
building for other archs or parallel installation would actually work.

> The cura-engine package is already in Debian, so a new upload should
> either use a different package name or continue the d/changelog from
> where the last upload left off.

This problem has already been resolved. cura-engine will be given a new epoch
(1:in), which makes it a working upgrade to the "old" CuraEngine. As far as I
understand, the epoch was introduced for exactly this use case.

Bas agreed that we shouldn't change the package name, as that would be
confusing to users.

> I suspect you can get a similar effect by importing orig tarballs (with
> pristine-tar, preferably) using the --upstream-vcs-tag=tag_name
> argument.

Ok... I'll look into this.

> Which package do you believe should be uploaded first?

libArcus is a dependency of Cura and CuraEngine, and libSavitar is needed by
Cura. Both should be built first. After that, CuraEngine, then Uranium (that's
the UI framework) and ultimately Cura. fdm-materials is an optional package
containing only data files and can be built separately.

Bug#808379: please consider patch to customize E-Mail Subject

[Marc Haber]

On Wed, Sep 27, 2017 at 10:36:55PM +0200, Ola Lundqvist wrote:
> Yes, but maybe I accidentally signed it with the old key. I'll check
> and re-upload.

The second upload made it. Thanks.

Greetigns
Marc
 

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#855494: PMV in Debian: oldnumeric is no more

[Andreas Tille]

[Put publicly archived bug page in CC to have a record of the discussion]

Hi Michel,

I'm not involved in MGLTools packaging but out of curiosity:  Where can
I download MGLTools 1.5.7.  The page

http://mgltools.scripps.edu/downloads/

only lists 1.5.6.

Kind regards

   Andreas.

On Wed, Sep 27, 2017 at 04:46:47PM -0700, Michel Sanner wrote:
> Hallo Steffen
> 
> I am not sure what this bug is about but MGLTools 1.5.7 does not use
> oldnumeric at all
> 
> the bug mentions version 1.5.7-1 which I am not sure if it a debian release
> numbering thing or whether this refers to 1.5.7rc1 which pre-dates 1.5.7
> (final)
> 
> So this might be a non-issue in the end
> 
> -Michel
> 
> On 09/20/2017 02:53 PM, Steffen Möller wrote:
> > Dear all,
> > 
> > It is quite some time that we had been in touch and I hope you are doing
> > just fine.
> > 
> > I am very bad myself at skimming through our bug reports and was only
> > now pointed by Andreas (CCed) to a report from February that with the
> > advent of numpy 1.9.1 the oldnumeric is gone. The report is at
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855494
> > 
> > ...

-- 
http://fam-tille.de

Bug#877048: sendxmpp: sometimes goes into an infinite loop

[Russell Coker]

Package: sendxmpp
Version: 1.23-1.1
Severity: normal

  PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+ COMMAND
14489 mon   20   0   74188  27640   7204 R 100.0  0.2   4924:43 sendxmpp
27711 mon   20   0   74240  27396   6984 R 100.0  0.2   4859:49 sendxmpp

Above is part of the output of "top" which shows sendxmpp in an infinite loop.

I don't know why it did that and haven't seen it happen in test situations yet.

Strace shows that it's not making any system calls, so something in the Perl
code is looping without doing any system calls.

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

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

Versions of packages sendxmpp depends on:
ii  libnet-xmpp-perl  1.05-1
ii  perl  5.24.1-3+deb9u2

sendxmpp recommends no packages.

sendxmpp suggests no packages.

-- no debconf information

Bug#877043: stretch-pu: package weechat/1.6-1+deb9u2

[Adam D. Barratt]

On Thu, 2017-09-28 at 07:53 +0200, Salvatore Bonaccorso wrote:
> Hi Adam,
> 
> On Thu, Sep 28, 2017 at 06:43:59AM +0100, Adam D. Barratt wrote:
> > Control: tags -1 + confirmed
> > 
> > On Thu, 2017-09-28 at 05:02 +0200, Salvatore Bonaccorso wrote:
> > > weechat in stretch is affected by CVE-2017-14727, tracked as
> > > #876553.
> > > 
> > > >  * logger: call strftime before replacing buffer local
> > > > variables
> > > >    (CVE-2017-14727) (Closes: #876553)
> > > 
> > > https://weechat.org/news/98/20170923-Version-1.9.1-security-relea
> > > se/
> > > 
> > > Attached proposed debdiff for the stretch point release.
> > > 
> > 
> > There's quite a bit of noise in such a small diff. :-( I appreciate
> > why, though.
> 
> Yes I can understand, you are a bit unahppy with me with that regard.
> I followed upstream, which renamed several of the mask_* pointers and
> added a new one for one more operation and shuffled around.
> 
> I prefered to rather follow upstream here, hope I can convince you.
> 
> or did you mean something else?

No problem; I wasn't unhappy with you. Following upstream's diff makes
perfect sense, it's just unfortunate that they ended up with a patch
that was significantly larger than the actual change. In their
position, I'm not sure I'd have wanted to be having to add "mask_2.5"
type variables just to avoid the rename though.

Apologies if that wasn't clear.

Regards,

Adam

Bug#877045: jessie-pu: package weechat/1.0.1-1+deb8u2

[Salvatore Bonaccorso]

On Thu, Sep 28, 2017 at 06:44:28AM +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Thu, 2017-09-28 at 05:15 +0200, Salvatore Bonaccorso wrote:
> > weechat in jessie is affected by CVE-2017-14727, tracked as #876553.
> > 
> > >  * logger: call strftime before replacing buffer local variables
> > >    (CVE-2017-14727) (Closes: #876553)
> > 
> > https://weechat.org/news/98/20170923-Version-1.9.1-security-release/
> > 
> 
> Please go ahead.

Thank you, uploaded.

Salvatore

Bug#877043: stretch-pu: package weechat/1.6-1+deb9u2

[Salvatore Bonaccorso]

Hi Adam,

On Thu, Sep 28, 2017 at 06:43:59AM +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Thu, 2017-09-28 at 05:02 +0200, Salvatore Bonaccorso wrote:
> > weechat in stretch is affected by CVE-2017-14727, tracked as #876553.
> > 
> > >  * logger: call strftime before replacing buffer local variables
> > >    (CVE-2017-14727) (Closes: #876553)
> > 
> > https://weechat.org/news/98/20170923-Version-1.9.1-security-release/
> > 
> > Attached proposed debdiff for the stretch point release.
> > 
> 
> There's quite a bit of noise in such a small diff. :-( I appreciate
> why, though.

Yes I can understand, you are a bit unahppy with me with that regard.
I followed upstream, which renamed several of the mask_* pointers and
added a new one for one more operation and shuffled around.

I prefered to rather follow upstream here, hope I can convince you.

or did you mean something else?

> Please go ahead.

Done, despite maybe the above raises questions. In case of such, feel
free to reject the upload and we can do a turnaround.

Salvatore

Bug#876949: stretch-pu: package postfix/3.1.6-0+deb9u1

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Wed, 2017-09-27 at 01:14 -0400, Scott Kitterman wrote:
> This upload is intended to solve several problems.  While it's
> somewhat
> unusual, since it includes new upstream releases, the upstream
> changes are
> very targetted and all things that I believe are appropriate to fix
> in a
> stable update:
> 
[...]
> Additionally, there's a packaging fix for a bug that broke multi-
> instance.
> 

The latter (#873957) doesn't appear to have been applied in unstable
yet. Are the upstream fixes relevant to unstable and applied there?

Regards,

Adam

Bug#876706: stretch-pu: package liblouis/3.0.0-3

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2017-09-25 at 01:31 +0200, Samuel Thibault wrote:
> Several CVEs have been reported against liblouis in Bug#874302. The
> upstream fixes have been tested for 6 days in Debian unstable then 5
> days in Debian testing.
> 

It might be nice to have slightly more descriptive changelog entries.
In any case, please feel free to upload.

Regards,

Adam

Bug#877043: stretch-pu: package weechat/1.6-1+deb9u2

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2017-09-28 at 05:02 +0200, Salvatore Bonaccorso wrote:
> weechat in stretch is affected by CVE-2017-14727, tracked as #876553.
> 
> >  * logger: call strftime before replacing buffer local variables
> >    (CVE-2017-14727) (Closes: #876553)
> 
> https://weechat.org/news/98/20170923-Version-1.9.1-security-release/
> 
> Attached proposed debdiff for the stretch point release.
> 

There's quite a bit of noise in such a small diff. :-( I appreciate
why, though.

Please go ahead.

Regards,

Adam

Bug#877045: jessie-pu: package weechat/1.0.1-1+deb8u2

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2017-09-28 at 05:15 +0200, Salvatore Bonaccorso wrote:
> weechat in jessie is affected by CVE-2017-14727, tracked as #876553.
> 
> >  * logger: call strftime before replacing buffer local variables
> >    (CVE-2017-14727) (Closes: #876553)
> 
> https://weechat.org/news/98/20170923-Version-1.9.1-security-release/
> 

Please go ahead.

Regards,

Adam

Bug#867814: stretch-pu: package ncurses/6.0+20161126-1+deb9u1

[Adam D. Barratt]

Control: tags -1 + pending

On Sun, 2017-09-24 at 09:16 +0200, Sven Joachim wrote:
> On 2017-09-23 19:59 +0100, Adam D. Barratt wrote:
> 
> > Control: tags -1 -moreinfo +confirmed
> > 
> > On Thu, 2017-09-07 at 19:06 +0200, Cyril Brulebois wrote:
> > > Sven Joachim  (2017-09-06):
> > > > Meanwhile seven new CVEs in the tic library and programs have
> > > > been
> > > > reported, and I would like to fix those as well, see the
> > > > attached
> > > > new
> > > > debdiff.  It contains all the library changes from the 20170826
> > > > upstream
> > > > patchlevel and the program fixes of the 20170902 patchlevel.  I
> > > > have
> > > > also attached the test cases for the 13 bugs reported in the
> > > > Red
> > > > Hat
> > > > bugtracker.
> > > > 
> > > > > > > I'd be okay with this, but it will need a kibi-ack due to
> > > > > > > the
> > > > > > > udeb.
> > > > > > 
> > > > > > The changes do not touch the tinfo library which is all
> > > > > > that
> > > > > > shipped in
> > > > > > the udeb.
> > > > > 
> > > > > To elaborate on that, ncurses/tinfo/{alloc,parse}_entry.c are
> > > > > compiled
> > > > > into the tic library while progs/dump_entry.c is for the
> > > > > infocmp
> > > > > and tic
> > > > > programs.  Building 6.0+20161126-1 and 6.0+20161126-1+deb9u1
> > > > > in a
> > > > > stretch chroot produced identical libtinfo.so.5.9 files.
> > > > 
> > > > This is unfortunately no longer the case, since strings.c and
> > > > trim_sgr0.c are compiled into the tinfo library.  However, the
> > > > changes
> > > > to these files are small.
> > > 
> > > I have no straightforward way to double check things still run
> > > smoothly
> > > with stretch's d-i, so I'll follow whatever decision the release
> > > team
> > > makes; if regressions pop up, we'll figure out how to fix them.
> > > 
> > 
> > Let's go with it and keep our fingers crossed that any issues show
> > up
> > quickly.
> 
> Thanks, uploaded.
> 

Flagged for acceptance, thanks.

Regards,

Adam

Bug#872441: stretch-pu: package gsoap/2.8.35-4+deb9u1

[Adam D. Barratt]

Control: tags -1 + pending

On Sat, 2017-09-23 at 18:24 +0100, Jonathan Wiltshire wrote:
> Control: tag -1 confirmed
> 
> On Fri, Aug 18, 2017 at 11:35:09AM +0200, Mattias Ellert wrote:
[...]
> > diff -Nru gsoap-2.8.35/debian/changelog gsoap-
> > 2.8.35/debian/changelog
> > --- gsoap-2.8.35/debian/changelog   2016-12-06
> > 09:32:36.0 +0100
> > +++ gsoap-2.8.35/debian/changelog   2017-08-16
> > 11:58:11.0 +0200
> > @@ -1,3 +1,9 @@
> > +gsoap (2.8.35-4+deb9u1) stretch; urgency=medium
> > +
> > +  * Fix for CVE-2017-9765
> > +
> > + -- Mattias Ellert   Wed, 16 Aug
> > 2017 11:58:11 +0200
> 
> Please go ahead, but a little more detail in your changelog (what is
> CVE-2017-9765 and what changed to fix it?) is always appreciated.
> 

Uploaded and flagged for acceptance.

Regards,

Adam

Bug#875777: stretch-pu: package ecl/15.3.7+dfsg1-2+deb9u1

[Adam D. Barratt]

Control: tags -1 + pending

On Mon, 2017-09-25 at 14:05 +0200, Sébastien Villemot wrote:
> On Sat, Sep 23, 2017 at 05:25:15PM +0100, Jonathan Wiltshire wrote:
> 
> > On Thu, Sep 14, 2017 at 02:45:16PM +0200, Sébastien Villemot wrote:
> > > I have prepared a stretch-pu for ecl. The debdiff is attached. It
> > > simply fixes
> > > #873091 by adding the dependency on libffi-dev.
> > 
> > Please go ahead.
> 
> Thanks, uploaded.

Flagged for acceptance.

Regards,

Adam

Bug#866537: stretch-pu: package cross-gcc/113

[Adam D. Barratt]

Control: tags -1 + pending

On Sat, 2017-09-23 at 19:55 +0100, Adam D. Barratt wrote:
> Control: tags -1 -moreinfo +confirmed
> 
> On Sat, 2017-07-22 at 02:06 +0100, Wookey wrote:
> > New patch attached with suggested changes. Is this OK?
> > 
> 
> Please go ahead.
> 
> 

Uploaded and flagged for acceptance.

Regards,

Adam

Bug#863734: unblock: gnupg2/2.1.18-8

[Adam D. Barratt]

Control: tags -1 + pending

On Tue, 2017-09-26 at 01:11 -0400, Daniel Kahn Gillmor wrote:
> On Sat 2017-09-23 19:46:42 +0100, Adam D. Barratt wrote:
> > On Wed, 2017-09-20 at 23:07 -0400, Daniel Kahn Gillmor wrote:
> > > I've built this against a stretch system and tested it on a
> > > stretch
> > > system, and it still works.
> > > 
> > > Please advise me whether i should make an upload.
> > 
> > With a slightly more definite changelog stanza, please go ahead. :-
> > )
> 
> Thanks, I've uploaded.
> 

Flagged for acceptance.

Regards,

Adam

Bug#876629: stretch-pu: package db5.3/5.3.28-12+deb9u1

[Adam D. Barratt]

Control: tags -1 + pending

On Sun, 2017-09-24 at 18:27 +0200, Salvatore Bonaccorso wrote:
> Hi Jonathan,
> 
> On Sun, Sep 24, 2017 at 02:52:03PM +0100, Jonathan Wiltshire wrote:
> > Control: tag -1 confirmed
> > 
> > Hi,
> > 
> > On Sun, Sep 24, 2017 at 09:52:06AM +0200, Salvatore Bonaccorso
> > wrote:
> > > db5.3 in stretch is affected by the CVE-2017-10140 ("Berkeley DB
> > > reads
> > > DB_CONFIG from cwd)", #872436. The NMU to unstable back on end of
> > > august has not raised any regression reports we would be aware
> > > of. We
> > > though think it's still safer to have it via point release
> > 
> > Please go ahead.
> 
> Thanks, uploaded.
> 

Flagged for acceptance into p-u, thanks.

Regards,

Adam

Bug#877047: RFS: sane-backends-extras/1.0.22.5 [QA]

[Hugh McMaster]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "sane-backends-extras".

* Package name: sane-backends-extras
   Version: 1.0.22.5
   Upstream Author: SANE
* URL: http://www.sane-project.org/
* License: GPL v2
   Section: graphics

It builds the following binary packages:
  * libsane-extras - API library for scanners -- extra backends
  * libsane-extras-common - API library for scanners -- documentation and 
support files
  * libsane-extras-dev - API development library for scanners [development 
files]

To access further information about this package, please visit the following 
URL:
  https://mentors.debian.net/package/sane-backends-extras

Alternatively, you may download the package with dget using this command:

dget -x 
https://mentors.debian.net/debian/pool/main/s/sane-backends-extras/sane-backends-extras_1.0.22.5.dsc

Changes since the last upload:
  * QA upload.
  * debhelper update:
- Update package compatibility to level 10
  * debian/control:
- Bump debhelper build-dep to >= 10~.
- Remove autotools-dev from the Build-Depends list, as debhelper
  enables the 'autoreconf' sequence by default.
- Bump Standards-Version from 3.9.8 to 4.1.0 (no changes needed).
- Convert libsane-extras-common to Architecture: all.
- Mark libsane-extras-dev Multi-Arch: same (Closes: #862263).
  * debian/extras-backends/geniusvp2:
- Fix a spelling error in the BUGS file (lintian).
  * debian/rules:
- Remove '--with=autotools_dev' (now handled by debhelper level 10).
  * doc/sane-geniusvp2.man:
- Fix spelling errors (lintian).
  * Rename configure.in to configure.ac (lintian).

Regards,

Hugh McMaster

Bug#877046: [q4wine] You must totally remove this app made by insane fascist hohol's

[Fuck-ukrains-Fascists]

Package: q4wine
Version: any
Severity: critical

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

Look at homepage of app http://q4wine.brezblock.org.ua/ from Russian IP 
and you will see:



 Доступ запрещен

В связи с агрессией россии против суверенного государства Украина:

 * аннексии Крыма;
 * вторжения в восточные регионы Украины;
 * поддержка оружием и военным присутствием боевиков и террористов;
 * попыток дестабилизации политической ситуации;

доступ к сайтам и проектам brezblock ограничен для всех жителей на 
территории российской федерации.


Ограничение действует бессрочно, без исключений.

Debian should not include so stuff from fascists.

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

Debian Release: 9.1
999 stable deb.debian.org
950 stretch-backports deb.debian.org
900 testing deb.debian.org
800 unstable deb.debian.org
700 experimental deb.debian.org

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

Package's Recommends field is empty.

Package's Suggests field is empty.

Bug#877045: jessie-pu: package weechat/1.0.1-1+deb8u2

[Salvatore Bonaccorso]

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

Hi

weechat in jessie is affected by CVE-2017-14727, tracked as #876553.

>  * logger: call strftime before replacing buffer local variables
>(CVE-2017-14727) (Closes: #876553)

https://weechat.org/news/98/20170923-Version-1.9.1-security-release/

Attached proposed debdiff for the jessie point release.

Regards,
Salvatore
diff -Nru weechat-1.0.1/debian/changelog weechat-1.0.1/debian/changelog
--- weechat-1.0.1/debian/changelog  2017-04-25 07:01:43.0 +0200
+++ weechat-1.0.1/debian/changelog  2017-09-27 21:27:15.0 +0200
@@ -1,3 +1,11 @@
+weechat (1.0.1-1+deb8u2) jessie; urgency=medium
+
+  * Non-maintainer upload.
+  * logger: call strftime before replacing buffer local variables
+(CVE-2017-14727) (Closes: #876553)
+
+ -- Salvatore Bonaccorso   Wed, 27 Sep 2017 21:27:15 +0200
+
 weechat (1.0.1-1+deb8u1) jessie-security; urgency=high
 
   * Non-maintainer upload by the Security Team.
diff -Nru 
weechat-1.0.1/debian/patches/0001-logger-call-strftime-before-replacing-buffer-local-v.patch
 
weechat-1.0.1/debian/patches/0001-logger-call-strftime-before-replacing-buffer-local-v.patch
--- 
weechat-1.0.1/debian/patches/0001-logger-call-strftime-before-replacing-buffer-local-v.patch
1970-01-01 01:00:00.0 +0100
+++ 
weechat-1.0.1/debian/patches/0001-logger-call-strftime-before-replacing-buffer-local-v.patch
2017-09-27 21:27:15.0 +0200
@@ -0,0 +1,152 @@
+From: =?UTF-8?q?S=C3=A9bastien=20Helleu?= 
+Date: Sat, 23 Sep 2017 09:36:09 +0200
+Subject: logger: call strftime before replacing buffer local variables
+Origin: 
https://github.com/weechat/weechat/commit/f105c6f0b56fb5687b2d2aedf37cb1d1b434d556
+Bug-Debian: https://bugs.debian.org/876553
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2017-14727
+
+---
+ src/plugins/logger/logger.c | 88 ++---
+ 2 files changed, 51 insertions(+), 44 deletions(-)
+
+
+--- a/src/plugins/logger/logger.c
 b/src/plugins/logger/logger.c
+@@ -316,71 +316,71 @@ logger_get_mask_for_buffer (struct t_gui
+ char *
+ logger_get_mask_expanded (struct t_gui_buffer *buffer, const char *mask)
+ {
+-char *mask2, *mask_decoded, *mask_decoded2, *mask_decoded3, 
*mask_decoded4;
+-char *mask_decoded5;
++char *mask2, *mask3, *mask4, *mask5, *mask6, *mask7;
+ const char *dir_separator;
+ int length;
+ time_t seconds;
+ struct tm *date_tmp;
+ 
+ mask2 = NULL;
+-mask_decoded = NULL;
+-mask_decoded2 = NULL;
+-mask_decoded3 = NULL;
+-mask_decoded4 = NULL;
+-mask_decoded5 = NULL;
++mask3 = NULL;
++mask4 = NULL;
++mask5 = NULL;
++mask6 = NULL;
++mask7 = NULL;
+ 
+ dir_separator = weechat_info_get ("dir_separator", "");
+ if (!dir_separator)
+ return NULL;
+ 
++/* replace date/time specifiers in mask */
++length = strlen (mask) + 256 + 1;
++mask2 = malloc (length);
++if (!mask2)
++goto end;
++seconds = time (NULL);
++date_tmp = localtime (&seconds);
++mask2[0] = '\0';
++if (strftime (mask2, length - 1, mask, date_tmp) == 0)
++mask2[0] = '\0';
++
+ /*
+  * we first replace directory separator (commonly '/') by \01 because
+  * buffer mask can contain this char, and will be replaced by replacement
+  * char ('_' by default)
+  */
+-mask2 = weechat_string_replace (mask, dir_separator, "\01");
+-if (!mask2)
++mask3 = weechat_string_replace (mask2, dir_separator, "\01");
++if (!mask3)
+ goto end;
+ 
+-mask_decoded = weechat_buffer_string_replace_local_var (buffer, mask2);
+-if (!mask_decoded)
++mask4 = weechat_buffer_string_replace_local_var (buffer, mask3);
++if (!mask4)
+ goto end;
+ 
+-mask_decoded2 = weechat_string_replace (mask_decoded,
+-dir_separator,
+-weechat_config_string 
(logger_config_file_replacement_char));
+-if (!mask_decoded2)
++mask5 = weechat_string_replace (mask4,
++dir_separator,
++weechat_config_string 
(logger_config_file_replacement_char));
++if (!mask5)
+ goto end;
+ 
+ #ifdef __CYGWIN__
+-mask_decoded3 = weechat_string_replace (mask_decoded2, "\\",
+-weechat_config_string 
(logger_config_file_replacement_char));
++mask6 = weechat_string_replace (mask5, "\\",
++weechat_config_string 
(logger_config_file_replacement_char));
+ #else
+-mask_decoded3 = strdup (mask_decoded2);
++mask6 = strdup (mask5);
+ #endif
+-if (!mask_decoded3)
++if (!mask6)
+ goto end;
+ 
+ /* restore directory separator */
+-mask_decoded4 = weechat_string_replace (mask_decoded3,
+- 

Bug#877044: Outdated Conflicts: ubuntu-dev-tools

[Ivan Kozik]

Package: perf-tools-unstable
Version: 0.0.1~20160212+git0c13e83-2

perf-tools-unstable's control file lists a Conflicts:
ubuntu-dev-tools.  I believe it should no longer conflict with
ubuntu-dev-tools because perf-tools-unstable's bitesize was renamed to
bitesize-perf and therefore no longer conflicts with ubuntu-dev-tools'
bitesize.

Best regards,

Ivan

Bug#877043: stretch-pu: package weechat/1.6-1+deb9u2

[Salvatore Bonaccorso]

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

Hi

weechat in stretch is affected by CVE-2017-14727, tracked as #876553.

>  * logger: call strftime before replacing buffer local variables
>(CVE-2017-14727) (Closes: #876553)

https://weechat.org/news/98/20170923-Version-1.9.1-security-release/

Attached proposed debdiff for the stretch point release.

Regards,
Salvatore
diff -Nru weechat-1.6/debian/changelog weechat-1.6/debian/changelog
--- weechat-1.6/debian/changelog2017-04-29 16:31:58.0 +0200
+++ weechat-1.6/debian/changelog2017-09-27 20:53:31.0 +0200
@@ -1,3 +1,11 @@
+weechat (1.6-1+deb9u2) stretch; urgency=medium
+
+  * Non-maintainer upload.
+  * logger: call strftime before replacing buffer local variables
+(CVE-2017-14727) (Closes: #876553)
+
+ -- Salvatore Bonaccorso   Wed, 27 Sep 2017 20:53:31 +0200
+
 weechat (1.6-1+deb9u1) stretch; urgency=medium
 
   * Non-maintainer upload.
diff -Nru 
weechat-1.6/debian/patches/03_logger-call-strftime-before-replacing-buffer-local-v.patch
 
weechat-1.6/debian/patches/03_logger-call-strftime-before-replacing-buffer-local-v.patch
--- 
weechat-1.6/debian/patches/03_logger-call-strftime-before-replacing-buffer-local-v.patch
1970-01-01 01:00:00.0 +0100
+++ 
weechat-1.6/debian/patches/03_logger-call-strftime-before-replacing-buffer-local-v.patch
2017-09-27 20:53:31.0 +0200
@@ -0,0 +1,158 @@
+From: =?UTF-8?q?S=C3=A9bastien=20Helleu?= 
+Date: Sat, 23 Sep 2017 09:36:09 +0200
+Subject: logger: call strftime before replacing buffer local variables
+Origin: 
https://github.com/weechat/weechat/commit/f105c6f0b56fb5687b2d2aedf37cb1d1b434d556
+Bug-Debian: https://bugs.debian.org/876553
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2017-14727
+
+---
+ src/plugins/logger/logger.c | 88 ++---
+ 2 files changed, 51 insertions(+), 44 deletions(-)
+
+
+diff --git a/src/plugins/logger/logger.c b/src/plugins/logger/logger.c
+index 1abc3efc7..347f1d5a6 100644
+--- a/src/plugins/logger/logger.c
 b/src/plugins/logger/logger.c
+@@ -295,71 +295,71 @@ logger_get_mask_for_buffer (struct t_gui_buffer *buffer)
+ char *
+ logger_get_mask_expanded (struct t_gui_buffer *buffer, const char *mask)
+ {
+-char *mask2, *mask_decoded, *mask_decoded2, *mask_decoded3, 
*mask_decoded4;
+-char *mask_decoded5;
++char *mask2, *mask3, *mask4, *mask5, *mask6, *mask7;
+ const char *dir_separator;
+ int length;
+ time_t seconds;
+ struct tm *date_tmp;
+ 
+ mask2 = NULL;
+-mask_decoded = NULL;
+-mask_decoded2 = NULL;
+-mask_decoded3 = NULL;
+-mask_decoded4 = NULL;
+-mask_decoded5 = NULL;
++mask3 = NULL;
++mask4 = NULL;
++mask5 = NULL;
++mask6 = NULL;
++mask7 = NULL;
+ 
+ dir_separator = weechat_info_get ("dir_separator", "");
+ if (!dir_separator)
+ return NULL;
+ 
++/* replace date/time specifiers in mask */
++length = strlen (mask) + 256 + 1;
++mask2 = malloc (length);
++if (!mask2)
++goto end;
++seconds = time (NULL);
++date_tmp = localtime (&seconds);
++mask2[0] = '\0';
++if (strftime (mask2, length - 1, mask, date_tmp) == 0)
++mask2[0] = '\0';
++
+ /*
+  * we first replace directory separator (commonly '/') by \01 because
+  * buffer mask can contain this char, and will be replaced by replacement
+  * char ('_' by default)
+  */
+-mask2 = weechat_string_replace (mask, dir_separator, "\01");
+-if (!mask2)
++mask3 = weechat_string_replace (mask2, dir_separator, "\01");
++if (!mask3)
+ goto end;
+ 
+-mask_decoded = weechat_buffer_string_replace_local_var (buffer, mask2);
+-if (!mask_decoded)
++mask4 = weechat_buffer_string_replace_local_var (buffer, mask3);
++if (!mask4)
+ goto end;
+ 
+-mask_decoded2 = weechat_string_replace (mask_decoded,
+-dir_separator,
+-weechat_config_string 
(logger_config_file_replacement_char));
+-if (!mask_decoded2)
++mask5 = weechat_string_replace (mask4,
++dir_separator,
++weechat_config_string 
(logger_config_file_replacement_char));
++if (!mask5)
+ goto end;
+ 
+ #ifdef __CYGWIN__
+-mask_decoded3 = weechat_string_replace (mask_decoded2, "\\",
+-weechat_config_string 
(logger_config_file_replacement_char));
++mask6 = weechat_string_replace (mask5, "\\",
++weechat_config_string 
(logger_config_file_replacement_char));
+ #else
+-mask_decoded3 = strdup (mask_decoded2);
++mask6 = strdup (mask5);
+ #endif /* __CYGWIN__ */
+-if (!mask_decoded3)
++if (!mask6)
+ goto end;
+ 
+ /* restore direct

Bug#843448: linux-image-4.8.0-1-armmp-lpae: fails to boot on Odroid-Xu4 with rootfs on USB

[gustavo panizzo]

On Sun, Sep 24, 2017 at 07:52:29AM +, Jochen Sprickerhof wrote:

Hi,

Finally I had the time and hardware available to look into this again 
and found a better way to fix it. Applying the attached patch results 
in a new exynos5422-odroidxu4.dtb that could simply be copied to 
/boot/dtbs/*/

I've tested this with the current kernel in sid (linux-image-4.12.0-2-armmp)
as well as stretch (linux-image-4.9.0-3-armmp). More tests welcome.


I've tested with linux-next, on top of commit
73527316e3fdde8a210b8ab66c1bf48538cf6b09
4.14.0-rc1-next-20170922+

everything works fine, USB3 devices work fine after reboot :)

@Jochen, will you try to get it merged upstream?



@Ben: This seems unintrusive enough to be included in the next stretch 
point release, what do you think?


Cheers Jochen






--
IRC: gfa
GPG: 0X44BB1BA79F6C6333

Bug#866306:

[Guy Lunardi]

This issue still appears to exist against Linux 4.13.3.

Have not looked at haveged at all but noticed that passing "--data=16"
instead on relying on the fallback seems to allow haveged to start properly.

Tested with armbian on a LibreComputer Le Potato.

HTH (I might try to look into haveged if I have time but I doubt)

Bug#877042: i2p: FTBFS on x32: bogus -m32, so not found

[Aaron M. Ucko]

Source: i2p
Version: 0.9.30-4
Severity: important
Tags: upstream
Justification: fails to build from source

Builds of i2p for x32 (admittedly not a release architecture) have
been failing:

  Compile: "gcc -c -m32 -fPIC -Wall  -I. -I./jbigi/include 
-I/usr/lib/jvm/default-java/include -I/usr/lib/jvm/default-java/include/linux 
-I/usr/local/include ./jbigi/src/jbigi.c"
  In file included from /usr/include/stdio.h:27:0,
   from ./jbigi/src/jbigi.c:1:
  /usr/include/features.h:364:12: fatal error: sys/cdefs.h: No such file or 
directory
   #  include 
  ^
  compilation terminated.
  debian/rules:161: recipe for target 'build-arch' failed
  make: *** [build-arch] Error 1

The use of -m32 here makes the compiler target i386, which fails in
the absence of corresponding headers and libraries, and would yield
inappropriate results if those files were available.  Please drop this
flag, which is necessary only under highly specialized circumstances,
since Debian's normal compilers are already native by default.

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#877041: RFA: ublock-origin -- general-purpose lightweight ads, malware, trackers blocker

[Sean Whitton]

Package: wnpp
Severity: normal

I request an adopter for the ublock-origin package.

I do not have time/interest to deal with #877040, which is a bug of
normal severity for now, but will become RC within the next eighteen
months or so.  See the bug for details.

This is a team-maintained package, so it would be best if the adoptor
replaced me in Uploaders:, but they could also take the package out of
the team's hands.

The package description is:
 uBlock is a small footprint blocker for against web ads, malware, trackers,
 analytics and similar invasive items.
 .
 Compared to other blockers like AdBlock and Ghostery, µBlock is focused on
 having a smaller memory and CPU footprint.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#877040: New upstream version, including transition to webext

[Sean Whitton]

Source: ublock-origin
Version: 1.13.8+dfsg-1
Severity: normal
Tags: help

uBlock Origin in Debian is several versions behind upstream.  This is
because packaging a recent upstream release requires

- installing the webext version, as a new binary package
  webext-ublock-origin, rather than the traditional XUL extension; and

- providing a script for the user to transition their data from the XUL
  extension to the new webext.

I am filing this bug because I know that I won't be able to work on this
any time soon.  I hope to provide enough information that someone else
is able to work on it independently.

This bug will become release-critical when every version of Firefox in
unstable is greater than or equal to 57, assuming Mozilla's plans do not
change.  At that point, XUL extensions will stop working.

Note that none of this affects the Chrome extension binary package,
unless Chrome, too, decides to support only web extensions.

Installing the webext
=

Ideally this would be achieved by fixing #866997.  But it would be fine
for this package to install the web extension without a helper; indeed,
it's not clear we need a helper for web extensions.

There have been several discussions about what needs to be done.  In
addition to those linked from #866997, see [3].  In summary:

- use the binary package namespace 'webext-'

- install to /usr/share/webext/ublock-origin

- create a symlink in the appropriate subdirectory of /usr/share/firefox
  such that Firefox loads the web extension (requires searching through
  the source of Firefox; possibly no such directory exists yet)

The purpose of the symlinking is to accommodate the fact that some web
extensions work with only one browser but others work with multiple
browsers.  We can manage this with symlinks.

See the webext branch of ublock-origin's Vcs-Git repository for first
attempts at installing the webext.

Providing the transition script
===

It is not possible to automatically transition the user's data -- by
patching the web extension to import the data, say.  This is because web
extensions cannot access the parts of the filesystem where the XUL
extension stored its data.

Upstream attempted a hybrid XUL and web extension which would import the
data.  They abandoned this project, but in any case, it would have been
no use for Debian: later point updates of stretch and the initial
release of buster will contain no version of Firefox capable of loading
XUL extensions.  So we must provide a script that users can run to
transition their data.  I would suggest a NEWS.Debian entry suggesting
that users run the script.

Upstream (Raymond Hill) has very helpfully provided guidance on writing
such a script.[1] For archival purposes, I reproduce the most
significant parts of Raymond's messages in the linked thread here:

> So anyways, basically this is how things are:
> 
> - With uBO/legacy, the settings are located in
>   ~/.config/firefox/[profile]/extension-data/ublock0.sqlite
>   - The content of the ublock0.sqlite db is one table, named settings,
> with two columns, named name and value.
>   - Each name is unique, and is the name of a setting.
>   - Each value is a string, and is JSON.parse'd after being read, and
> before being sent to the caller.
> - With uBO/webext, the settings are located in
>   
> ~/.config/firefox/[profile]/browser-extension-data/ublo...@raymondhill.net/storage.js
>   (that is a Firefox's controlled location).
>   - The content of storage.js is simple JSON data, in which each setting
> is a [setting name]: [setting value] entry. The value can be any
> valid JSON value: number, string, array, etc.
> 
> Now given all this, it's a matter of fetching all entries in the sqlite
> table, and converting them into an object property in one single
> destination JSON object structure { ... }.
> 
> Now not all entries in the table are to be transferred to the JSON
> structure, many entries are strictly for internal use by uBO. Any entry
> which name starts with cache/ must be ignored. Additionally, the
> following entries must also be ignored: assetCacheRegistry,
> assetSourceRegistry, selfie.
> 
> The code to migrate is located in this bootstrap.js file.[2] The
> function named getStorageMigrator contains all the code to deal with
> reading all entries one by one from the settings table.
> 
> [...]
> 
> So far I got something with this command -- needs more work though to
> get a valid JSON file -- so before I lose that command:
> 
> sqlite3 ublock0.sqlite ".separator "\\t " SELECT * FROM settings;" | awk 
> '!/^(?:assetCacheRegistry|assetSourceRegistry|cache\/.+|selfie)$/' > 
> output.txt
> 
> This outputs two fields per line, separated by \t.
> 
> [field1]  [field2]
> 
> After this is for each line to be output this way:
> 
> "[field1]": [field2]
> 
> Then to separate all the lines with a , character, then finally wrap the
> result in { and }.

[1]  https://github.com/gor

Bug#877024: modemmanager should ask before messing with serial ports

[Keith Packard]

Ian Jackson  writes:

> But I should be able to use the same laptop to (1) control my machine
> tools or talk to my rpi or whatever (2) go online with a usb mobile
> modem when I'm out of the house.  Possibly even simultaneously.

That requires fixing the package instead of just getting it out of the
way, a significantly harder thing to manage.

I'm not saying your wrong. The simpler fix would make things better for
some people (those who use no USB modems, but do use other USB serial
devices), worse for others (those who use USB modems but not other USB
serial devices), and the same for a few (those who use both). The
question is whether the simpler fix would be a net positive for Debian
users, or a net negative.

Obviously, a "real" fix that asked the user whether a particular
device was actually a modem would be best for the third class of
people.

Of course, the simpler fix has the side effect of not installing
software or running I don't ever need and which serves only to annoy me.
So, for me, the simpler fix is even better...

> And, people shouldn't have to install support software to get their
> internet to work.

It's all a question of what support we install by default; there are
certainly plenty of network configurations which are not supported in a
default install. Are modems still common enough that supporting them by
default is worth the cost of wasting space and power on the remaining
machines which will never use one?

If it were just software that got installed and sat idle, I'd complain a
lot less. As it is, modemmanager does "stuff" by default, even if I
haven't asked it to. Software which runs on every machine by default
should be held to a higher standard than software which users explicitly
request. So, if we didn't install it by default, I'd be happy for it to
continue to suck.

-- 
-keith


signature.asc
Description: PGP signature

Bug#877023: debian-policy: No section numbers in policy.txt.gz

[Russ Allbery]

Olly Betts  writes:

> /usr/share/doc/debian-policy/policy.txt.gz no longer has any section
> numbers, which makes it useless as a way to quickly locate a policy
> section to quote to someone as a reference.  The plain text version is
> the easiest to search, so this is a really annoying regression.

Yeah, this is a limitation of Sphinx that hopefully will be fixed.  In the
meantime, w3m to read the HTML version does work pretty well and supports
search (plus has an index that makes it pretty fast to find particular
sections).  But I did the same thing you did, and definitely want to fix
this sooner rather than later.

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

Bug#864721: algobox: There is no way to create real functions (and other wishes)

[David Prévot]

Hi Nicolas,

Thank you for your interest in algobox.

On Tue, Jun 13, 2017 at 03:34:14PM +0200, Nicolas Patrois wrote:
> Package: algobox
> Version: 0.9+dfsg-1+b1
> Severity: wishlist
> Tags: upstream

Forwarding your requests to Pascal Brachet (algobox upstream author), he
is in a better place to reply and/or address your requests than I am.
Please note there have been some improvements in the recent upstream
releases, does all your request still apply to the 1.0.2+dfsg-1 version?

> The function tool is too weak:
> * F1 is a function defined with a single formula.
> * F2 is a function defined by a succession of tests, the first one that is 
> true returns a value.
> It’s too simple in order to create a bit harder algorithms. At least, we 
> should be able to create a real function and why not, create one’s own 
> classes (because I see that there is a few OO syntax in Algobox).
> Moreover:
> * There is no operator for the power, for example ** because ^ seems already 
> used as the undocumented binary bitwise operator.
> * There is no way to create a generalized quantile function, for example 
> ALGOBOX_QUANTILE(list,1,4) would give the first quartile with, why not, an 
> optional flag to tell if the returned value is in the list or if it is 
> interpoled.
> * The operations on integers is not internal, pow(2,100) returns a float.
> 
> -- System Information:
> Debian Release: 9.0
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: i386 (i686)

Regards

David


signature.asc
Description: PGP signature

Bug#877024: modemmanager should ask before messing with serial ports

[Ian Jackson]

Keith Packard writes ("Re: Bug#877024: modemmanager should ask before messing 
with serial ports"):
> Yeah, I was just thinking that it would be easier to stop installing
> support for modems by default than to actually fix modemmanager to
> behave itself. It's certainly how I work -- apt remove modemmanager
> solves a world of problems for me.

But I should be able to use the same laptop to (1) control my machine
tools or talk to my rpi or whatever (2) go online with a usb mobile
modem when I'm out of the house.  Possibly even simultaneously.

And, people shouldn't have to install support software to get their
internet to work.

Ian.

Bug#868558: transition: r-api-3.4 [was Re: Bug#868558: nmu: multiple r-* packages]

[Graham Inggs]

On 24 September 2017 at 15:36, Sébastien Villemot  wrote:
> title = "r-api-3.4";
> is_affected = .depends ~ /r-api-3(\.4)?/;
> is_good = .depends ~ /r-api-3\.4/;
> is_bad = .depends ~ /r-api-3\b/;

I had some trouble with this in Ubuntu until Stefano Rivera suggested:
is_bad = .depends ~ /r-api-3(,|$)/;

Interesting thing is that r-cran-nlp doesn't show up in the Debian tracker.
It must have missed a binNMU to pick up a dependency on 'r-api-3' in
the first place.
I wonder if there are other packages like this.

Maybe we need 'r-base-core' in is_affected as well?

Bug#877036: dgit: Updating d/patches/debian-changes fails when that file is to be deleted

[Sean Whitton]

Hello,

On Thu, Sep 28 2017, Ian Jackson wrote:

> Can you please provide references to (i) your git HEAD (ii) any
> relevant origs ?

https://anonscm.debian.org/git/pkg-emacsen/pkg/s-el.git

9289bd2cb52bc55e935012d024af81175058119f is the commit that will show
the bug.

The/an orig may be obtained by typing `git deborig`.

> Also:
>
>> iris ~/src/s-el % build-for-upload
>
> What is this "build-for-upload" script ?

Sorry, I intended to launder this out.  In this case, it's just invoking
`dgit sbuild` and passing a few sbuild options.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#877024: modemmanager should ask before messing with serial ports

[Keith Packard]

Ian Jackson  writes:

> Also, AIUI modemmanager contains code to do things with the new-style
> MBIM dongles (which can also be done with the cli tools in
> mbim-utils).  But I definitely wouldn't suggest disabling its ability
> to work with AT-command modems, as they are still being sold.[1]

Yeah, I was just thinking that it would be easier to stop installing
support for modems by default than to actually fix modemmanager to
behave itself. It's certainly how I work -- apt remove modemmanager
solves a world of problems for me.

-- 
-keith


signature.asc
Description: PGP signature

Bug#877036: dgit: Updating d/patches/debian-changes fails when that file is to be deleted

[Ian Jackson]

Sean Whitton writes ("Bug#877036: dgit: Updating d/patches/debian-changes fails 
when that file is to be deleted"):
> Package: dgit
> Version: 3.12
> Severity: normal
> 
> Steps to reproduce:
> 
> 1. Package with single-debian-patch in d/source/options.
> 2. Diff in d/patches/debian-changes.
> 3. Merge new upstream version that incorporates the changes in
>d/patches/debian-changes, i.e., the patch needs to be dropped.
> 4. `dgit sbuild` (oddly, `dgit quilt-fixup` thinks it has nothing to do)

Can you please provide references to (i) your git HEAD
(ii) any relevant origs ?

I always ask for this.  It's always much better for me to try these
repros with the exact same thing that the bug reporter had, in case
there is anything unusual that the submitter doesn't mention (or in
case the submitter has misdiagnosed the cause).

Also:

> iris ~/src/s-el % build-for-upload

What is this "build-for-upload" script ?

Thanks,
Ian.

Bug#877038: libavahi-ui0.0-cil depends on obsolete package libavahi-ui0

[peter green]

Package: libavahi-ui0.0-cil
Severity: serious
Tags: buster sid

libavahi-ui0.0-cil depends on libavahi-ui0 which has been dropped by the avahi 
source package.

Bug#877039: ":80" is appended to socket file name

[Jonathan Krebs]

Package: lighttpd
Version: 1.4.45-1

If the server is bound to a socket in file system, three characters :80 are 
appended to the file path, breaking my reverse proxy setup.
Minimal example:

jonny@heron:/var/tmp/ltest$ lighttpd -D -f config &
[1] 30888
jonny@heron:/var/tmp/ltest$ 2017-09-28 00:26:22: (log.c.217) server started 

jonny@heron:/var/tmp/ltest$ ls
config  lighty.pid  lighty.sock:80

jonny@heron:/var/tmp/ltest$ cat config 
server.document-root = "/var/tmp/ltest/"

index-file.names = ( "index.html", "index.lighttpd.html" )

server.bind = "/var/tmp/ltest/lighty.sock"
server.errorlog = "/dev/tty"

server.pid-file = "/var/tmp/ltest/lighty.pid"

dir-listing.activate = "enable"


#  -- end of lighttpd config.


expected: a socket "lighty.sock" without :80

jonny@heron:~$ dpkg -s libc6 | grep ^Version
Version: 2.24-17
jonny@heron:~$ uname -a
Linux heron 4.11.0-1-amd64 #1 SMP Debian 4.11.6-1 (2017-06-19) x86_64 GNU/Linux

I think the source lines appending the port are src/network.c,
buffer_copy_buffer(b, srv->srvconf.bindhost);
buffer_append_string_len(b, CONST_STR_LEN(":"));
buffer_append_int(b, srv->srvconf.port);

I remember my setup to work some time ago (jessie or something older)

Bug#877037: RFP: python-pyfcm -- Python client library for FCM - Firebase Cloud Messaging (Android, iOS and Web)

[Johannes Schilling]

Package: wnpp
Severity: wishlist

* Package name: python-pyfcm
  Version : 1.4.2
  Upstream Author : Emmanuel Adegbite 
* URL : https://github.com/olucurious/PyFCM
* License : MIT
  Programming Lang: Python
  Description : Python client library for FCM - Firebase Cloud Messaging 
(Android, iOS and Web)

PyFCM is a library to easily communicate with the server side of the
Google Firebase Messaging infrastructure.

Firebase Cloud Messaging (FCM) is the new version of GCM. Using FCM, you
can notify a client app that new email or other data is available to
sync. You can send notifications to drive user reengagement and
retention. For use cases such as instant messaging, a message can
transfer a payload of up to 4KB to a client app.

Bug#877036: dgit: Updating d/patches/debian-changes fails when that file is to be deleted

[Sean Whitton]

Package: dgit
Version: 3.12
Severity: normal

Steps to reproduce:

1. Package with single-debian-patch in d/source/options.
2. Diff in d/patches/debian-changes.
3. Merge new upstream version that incorporates the changes in
   d/patches/debian-changes, i.e., the patch needs to be dropped.
4. `dgit sbuild` (oddly, `dgit quilt-fixup` thinks it has nothing to do)

Expected outcome:

d/patches/* deleted, and this change committed to git by dgit, as with
other quilt fixups under single-debian-patch.

Actual outcome:

d/patches/* deleted, and the change is not committed, and the build
aborts:

iris ~/src/s-el % dgit quilt-fixup
Format `3.0 (quilt)', need to check/update patch stack
starting quiltify (single-debian-patch)
dpkg-source: info: using options from work/debian/source/options: 
--single-debian-patch --auto-commit
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building s-el using existing ./s-el_1.12.0.orig.tar.xz
dpkg-source: info: building s-el in s-el_1.12.0-1.debian.tar.xz
dpkg-source: info: building s-el in s-el_1.12.0-1.dsc
dpkg-source: warning: extracting unsigned source package (s-el_1.12.0-1.dsc)
dpkg-source: info: extracting s-el in s-el-1.12.0
dpkg-source: info: unpacking s-el_1.12.0.orig.tar.xz
dpkg-source: info: unpacking s-el_1.12.0-1.debian.tar.xz
nothing quilty to commit, ok.
iris ~/src/s-el % build-for-upload
Format `3.0 (quilt)', need to check/update patch stack
starting quiltify (single-debian-patch)
dpkg-source: info: using options from work/debian/source/options: 
--single-debian-patch --auto-commit
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building s-el using existing ./s-el_1.12.0.orig.tar.xz
dpkg-source: info: building s-el in s-el_1.12.0-1.debian.tar.xz
dpkg-source: info: building s-el in s-el_1.12.0-1.dsc
dpkg-source: warning: extracting unsigned source package (s-el_1.12.0-1.dsc)
dpkg-source: info: extracting s-el in s-el-1.12.0
dpkg-source: info: unpacking s-el_1.12.0.orig.tar.xz
dpkg-source: info: unpacking s-el_1.12.0-1.debian.tar.xz
nothing quilty to commit, ok.
dpkg-source: info: using options from s-el/debian/source/options: 
--single-debian-patch --auto-commit
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building s-el using existing ./s-el_1.12.0.orig.tar.xz
dpkg-source: error: cannot read s-el/.pc/applied-patches: No such file or 
directory
dgit: failed command: dpkg-source '-i'\\'.git/' -I.git -b -- s-el
dgit: subprocess failed with error exit status 2

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

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

Versions of packages dgit depends on:
ii  apt   1.5~rc4
ii  ca-certificates   20170717
ii  coreutils 8.26-3
ii  curl  7.55.1-1
ii  devscripts2.17.10
ii  dpkg-dev  1.18.24
ii  dput-ng [dput]1.15
ii  git [git-core]1:2.14.1-3
ii  git-buildpackage  0.8.18
ii  libdpkg-perl  1.18.24
ii  libjson-perl  2.94-1
ii  liblist-moreutils-perl0.416-1+b3
ii  libperl5.26 [libdigest-sha-perl]  5.26.0-8
ii  libtext-glob-perl 0.10-1
ii  libtext-iconv-perl1.7-5+b6
ii  libwww-perl   6.15-2
ii  perl  5.26.0-8

Versions of packages dgit recommends:
ii  openssh-client [ssh-client]  1:7.5p1-10

Versions of packages dgit suggests:
ii  sbuild  0.73.0-4

-- no debconf information

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#877033: device-tree-compiler: Please update to 1.4.5

[Vagrant Cascadian]

Control: found 1.4.4-1

On 2017-09-27, Nobuhiro Iwamatsu wrote:
> Vagrant, thanks for your work!
> But version 1.4.5 has been released. (Not tag yet)
>   
> https://git.kernel.org/pub/scm/utils/dtc/dtc.git/commit/?id=22a65c5331c22979d416738eb756b9541672e00d

Ah, that's a different story!

Uploaded the most current version two days ago, and already behind the
times... heh.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#861281: rnahybrid: FTBFS on armel

[Adrian Bunk]

Control: reopen -1

On Wed, Sep 27, 2017 at 10:42:05AM -0400, Lennart Sorensen wrote:
> On Wed, Sep 27, 2017 at 04:39:39PM +0200, Andreas Tille wrote:
>...
> > To make things really clear for me: Edmund suggested another upload
> > with only -O1 (how can I make sure that -O1 is used only on armel?)
> > but your suggestion seems to affect the autobuilder which means for
> > me: "Wait until we tell you something else."  Is this correct?
> 
> I tried with -O1 and it did not make any noticeable reduction in compile
> time, so don't bother.  The only option for this package is to increase
> the timeout on armel.  It needs that much time.

What compile times exactly did you measure?

The numbers I got are:
-O0: 11s
-O1: 82m
-O2: 249m

The following builds for me easily within the 150m time limit:

--- debian/rules.old2017-09-27 18:38:24.225620119 +
+++ debian/rules2017-09-27 18:40:59.878867203 +
@@ -1,6 +1,13 @@
 #!/usr/bin/make -f
 # -*- makefile -*-
 
+DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH)
+
+# work around the #861281 gcc >= 6 compile time regression on 32bit arm
+ifneq (,$(findstring $(DEB_HOST_ARCH), armel))
+export DEB_CFLAGS_MAINT_APPEND = -O1
+endif
+
 export DEB_BUILD_MAINT_OPTIONS=hardening=+all
 
 %:


cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#876825: gcc: infinite loop targeting armel

[Adrian Bunk]

On Tue, Sep 26, 2017 at 09:48:52AM +0100, Edmund Grimley Evans wrote:
>...
> This is not specific to cross-compiling and not even to gcc-6.
> 
> We noticed the infinite loop when the buildd tries to build rnahybrid:
> 
> https://buildd.debian.org/status/logs.php?pkg=rnahybrid&arch=armel
>...

In addition to not being an infinite loop, it is also not only armel.

armhf does not hit the 150 minute timeout, but it also has a factor 10 
in the build time with gcc 5 -> 6 for literally the same sources:
  https://buildd.debian.org/status/logs.php?pkg=rnahybrid&arch=armhf

There is no such gcc 5 -> 6 performance regression for rnahybrid visible 
on the buildds of any other (release or ports) architecture, so this
performance regression seems to be specific to 32bit ARM.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#877024: modemmanager should ask before messing with serial ports

[Wouter Verhelst]

On Wed, Sep 27, 2017 at 02:13:50PM -0700, Keith Packard wrote:
> Ian Jackson  writes:
> 
> (speaking as a Debian user, not as a TC member)
> 
> > I'm afraid don't really want to do the work of writing a better UI.
> > But I have provided a simple patch which at least makes the behaviour
> > safe.
> 
> Would it be sufficient to simply stop installing this largely-useless
> package at this point? In what environments do users typically have
> modems which work with AT-style commands?

ModemManager supports more than just those modems that work with AT
command sets; it supports the modern UMTS/3G/4G modems which don't even
support AT commands anymore, too.

> It would be far safer to not install this package than try to hack it up
> to keep it from breaking systems. Simply removing it from 'depends' on
> the handful of packages which currently list it would 'fix' this problem
> with a minimum of fuss.

Except that then for people who use NetworkManager, configuring their
mobile internet will stop functioning. While I agree with Ian that the
current behaviour of ModemManager is more than just highly annoying, it
cannot be said that ModemManager does not function as designed, nor that
it does not provide any useful functionality of which the loss would be
felt by those users who need it.

While dropping dependencies might make the issue somewhat less of a
problem, I don't think it's the right course of action.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Bug#877035: mps-youtube: crashes with TypeError after search

[Jameson Graef Rollins]

Package: mps-youtube
Version: 0.2.7.1-2
Severity: grave
Justification: renders package unusable

mpsyt crashes whenever I try to do a search:

Searching for 'radiohead'
Traceback (most recent call last):
  File "/usr/bin/mpsyt", line 11, in 
load_entry_point('mps-youtube==0.2.7.1', 'console_scripts', 'mpsyt')()
  File "/usr/lib/python3/dist-packages/mps_youtube/main.py", line 141, in main
if matchfunction(i.function, i.regex, userinput):
  File "/usr/lib/python3/dist-packages/mps_youtube/main.py", line 64, in 
matchfunction
func(*matches)
  File "/usr/lib/python3/dist-packages/mps_youtube/commands/search.py", line 
212, in search
_search(term, query, msg, failmsg)
  File "/usr/lib/python3/dist-packages/mps_youtube/commands/search.py", line 
41, in _search
loadmsg=loadmsg)
  File "/usr/lib/python3/dist-packages/mps_youtube/commands/songlist.py", line 
56, in paginatesongs
songs = func[s:e]
  File "/usr/lib/python3/dist-packages/mps_youtube/util.py", line 47, in 
__getitem__
self.ilist.append(next(self.iterable))
  File "/usr/lib/python3/dist-packages/mps_youtube/commands/search.py", line 
28, in iter_songs
for song in get_tracks_from_json(wdata2):
  File "/usr/lib/python3/dist-packages/mps_youtube/commands/search.py", line 
342, in get_tracks_from_json
'id': ','.join([get_track_id_from_json(i) for i in items])}
TypeError: sequence item 9: expected str instance, dict found

Other searches produce slightly different tracebacks, this time after
the search seemingly has returned:

Traceback (most recent call last):
  File "/usr/lib/python3.5/threading.py", line 914, in _bootstrap_inner
self.run()
  File "/usr/lib/python3.5/threading.py", line 862, in run
self._target(*self._args, **self._kwargs)
  File "/usr/lib/python3/dist-packages/mps_youtube/streams.py", line 171, in 
_preload
streamlist = get(song)
  File "/usr/lib/python3/dist-packages/mps_youtube/streams.py", line 51, in get
p = util.get_pafy(vid, force=force, callback=callback)
  File "/usr/lib/python3/dist-packages/mps_youtube/util.py", line 201, in 
get_pafy
p = pafy.new(ytid, callback=callback_fn)
  File "/usr/lib/python3/dist-packages/pafy/pafy.py", line 122, in new
return Pafy(url, basic, gdata, size, callback, ydl_opts)
  File "/usr/lib/python3/dist-packages/pafy/backend_youtube_dl.py", line 29, in 
__init__
super(YtdlPafy, self).__init__(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/pafy/backend_shared.py", line 95, in 
__init__
self._fetch_basic()
  File "/usr/lib/python3/dist-packages/pafy/backend_youtube_dl.py", line 53, in 
_fetch_basic
self._category = self._ydl_info['categories'][0]
TypeError: 'NoneType' object is not subscriptable
  
In any event, the package is unusable as is.

Thanks.

jamie.


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

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

Versions of packages mps-youtube depends on:
ii  ffmpeg 7:3.3.4-1
ii  mpv0.26.0-3
ii  python33.5.3-3
ii  python3-pafy   0.5.2-2
ii  python3-pkg-resources  36.2.7-2

Versions of packages mps-youtube recommends:
ii  libnotify40.7.7-2
ii  python3-dbus  1.2.4-1+b2
ii  python3-gi3.24.1-3
ii  xclip 0.12+svn84-4+b1

mps-youtube suggests no packages.

-- no debconf information

Bug#873643: FTBFS with Java 9: removed class

[Emmanuel Bourg]

codemodel was moved into jaxb in 2013 [1] and the Java 9 issue have been
addressed upstream earlier this year [2].

With the move to jaxb the groupId and the version number of codemodel
were changed:

  com.sun.codemodel:codemodel:2.6 -> org.glassfish.jaxb:codemodel:2.2.11

src:jaxb should be upgraded to the latest release (2.3.0) and modified
to generate either libcodemodel-java with an epoch (due to the backward
change of the version number) and a pom relocation, or a new codemodel
package (libjaxb-codemodel-java or libglassfish-codemodel-java). Once
this is done src:codemodel can be removed.


[1] https://github.com/javaee/jaxb-v2/commit/46a372cb2
[2] https://github.com/javaee/jaxb-v2/commit/0e09f0ac2

Bug#868558: transition: r-api-3.4 [was Re: Bug#868558: nmu: multiple r-* packages]

[Emilio Pozuelo Monfort]

Control: forwarded -1 
https://release.debian.org/transitions/html/r-base-3.4.html
Control: tags -1 confirmed

On 24/09/17 15:36, Sébastien Villemot wrote:
> Control: reopen -1
> Control: retitle -1 transition: r-api-3.4
> Control: user release.debian@packages.debian.org
> Control: usertags -1 = transition
> 
> On Sun, Sep 10, 2017 at 04:15:00PM +, Niels Thykier wrote:
> 
>> To be perfectly, honest, I would prefer if you did a proper ABI-like
>> transition over the Breaks.  At this scale, Breaks seems too fragile and
>> too likely for people to get wrong.
> 
> The latest upload of r-base, versioned 3.4.1.20170921-1, has bumped the ABI
> pseudo package from "r-api-3" to "r-api-3.4", as requested.
> 
> Please therefore schedule rebuilds as necessary.

Will do so.

Cheers,
Emilio

Bug#876871: Non-empty transitional package

[Steffen Nurpmeso]

Hallo.

Christoph Berg  wrote:
 |Re: Steffen Nurpmeso 2017-09-26 <20170926152012.hbcvl%stef...@sdaoden.eu>
 |> I am the developer of that program and it seems the Debian
 |> maintainer has quit.
 |
 |Hilko is still around, he's active on other packages.

Maybe the last gasp for air before the giant totally breaks down?
I do not think so.  There was something about go on debian-deb
once i have searched last (verified a second a-go), but how can
anyone be active once broken down?

 |Hilko: Maybe you could RFA/O the package so another maintainer could
 |take over?

I could make the cloned and updated repo public and then all we
need is his private signing key!

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Bug#877034: yap FTBFS on i386: YAP OOOPS: tried to access illegal address

[Adrian Bunk]

Source: yap
Version: 6.2.2-6
Severity: serious
Tags: buster sid

Some recent change in unstable (gcc 6 -> 7?) makes yap FTBFS on i386:

https://tests.reproducible-builds.org/debian/history/yap.html
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/i386/yap.html

...
YAPSHAREDIR=/build/1st/yap-6.2.2/debian/yap/usr/share/Yap 
YAPLIBDIR=/build/1st/yap-6.2.2/debian/yap/usr/lib/Yap 
/build/1st/yap-6.2.2/debian/yap/usr/bin/yap 
/build/1st/yap-6.2.2/debian/yap/usr/lib/Yap/startup.yss -f none -g make -t halt
% Restoring file /build/1st/yap-6.2.2/debian/yap/usr/lib/Yap/startup.yss
YAP 6.2.2 (i686-linux): Wed Sep 27 09:34:43 -12 2017
%
%
% YAP OOOPS: tried to access illegal address 0xfd30103e.
%
%
1287KB of Code Space (0x1000--0x10141db0)
%
% PC: prolog:$file_is_unchanged/3 at clause 1 
%   Continuation: prolog:$ensure_file_unchanged/3 at clause 1 
%512KB of Global Stack (0x103ea000--0x1046a25c)
%0KB of Local Stack (0x10515d00--0x10516000)
%0KB of Trail (0x10516004--0x10516030)
%Performed 0 garbage collections
% All Active Calls and
% Goals With Alternatives Open  (Global In Use--Local In Use)
%
%  prolog:$ensure_file_unchanged/3 at clause 1 
%  prolog:$ensure_file_unchanged/3 at clause 1 
%  prolog:$start_lf/11 at clause 2 
%  prolog:$lf/14 at clause 7 
%  prolog:$load_files/3 at clause 1 
% idb:$lf_loaded/0 (512KB--0KB)
%  prolog:make/0 at clause 1 
%  prolog:once/1 at clause 1 
%  prolog:$do_yes_no/2 at clause 2 
%  prolog:$yes_no/2 at clause 1 
% prolog:$catch/3 (512KB--0KB)
%  prolog:$system_catch/4 at clause 1 
%  prolog:$startup_goals/0 at clause 2 
%  prolog:$init_system/0 at clause 1 
%  prolog:$live/0 at clause 1 
%  meta-call

   Exiting 
Makefile:171: recipe for target 'install' failed
make[2]: *** [install] Error 1

Bug#877033: device-tree-compiler: Please update to 1.4.4

[Nobuhiro Iwamatsu]

Control: retitle -1 device-tree-compiler: Please update to 1.4.5

Hi,

Vagrant, thanks for your work!
But version 1.4.5 has been released. (Not tag yet)
  
https://git.kernel.org/pub/scm/utils/dtc/dtc.git/commit/?id=22a65c5331c22979d416738eb756b9541672e00d

Best regards,
  Nobuhiro

-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6

Bug#877033: device-tree-compiler: Please update to 1.4.4

[Nobuhiro Iwamatsu]

Package: device-tree-compiler
Version: 1.4.2-1
Severity: wishlist

Dear Maintainer,

device-tree-compiler version 1.4.4 has been released.
Could you update to 1.4.4 ?

  https://git.kernel.org/pub/scm/utils/dtc/dtc.git/tag/?h=v1.4.4

Best regards,
  Nobuhiro

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

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

Versions of packages device-tree-compiler depends on:
ii  libc6  2.24-17

device-tree-compiler recommends no packages.

device-tree-compiler suggests no packages.

-- no debconf information

Bug#877032: vdr: Can't start vdr

[Michael Jarosch]

Package: vdr
Version: 2.3.8-1
Severity: normal

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

after I upgraded to vdr version 2.3.8-1 my system wasn't able to start
it up, again.

systemctl says:
# systemctl status vdr.service 
● vdr.service - Video Disk Recorder
   Loaded: loaded (/lib/systemd/system/vdr.service; enabled; vendor
preset: enabled)
   Active: failed (Result: protocol) since Wed 2017-09-27 23:26:31
CEST; 19s ago
  Process: 9509 ExecStart=/usr/bin/vdr (code=exited, status=1/FAILURE)
  Process: 9499 ExecStartPre=/bin/sh /usr/lib/vdr/merge-commands.sh
reccmds (code=exited, status=0/SUCCESS)
  Process: 9489 ExecStartPre=/bin/sh /usr/lib/vdr/merge-commands.sh
commands (code=exited, status=0/SUCCESS)
 Main PID: 9509 (code=exited, status=1/FAILURE)

Sep 27 23:26:31 dog systemd[1]: Failed to start Video Disk Recorder.
Sep 27 23:26:31 dog systemd[1]: vdr.service: Unit entered failed state.
Sep 27 23:26:31 dog systemd[1]: vdr.service: Failed with result
'protocol'.
Sep 27 23:26:31 dog systemd[1]: vdr.service: Service hold-off time
over, scheduling restart.
Sep 27 23:26:31 dog systemd[1]: Stopped Video Disk Recorder.
Sep 27 23:26:31 dog systemd[1]: vdr.service: Start request repeated too
quickly.
Sep 27 23:26:31 dog systemd[1]: Failed to start Video Disk Recorder.
Sep 27 23:26:31 dog systemd[1]: vdr.service: Unit entered failed state.
Sep 27 23:26:31 dog systemd[1]: vdr.service: Failed with result
'protocol'.

# systemctl restart vdr.service 
Job for vdr.service failed because the service did not take the steps
required by its unit configuration.


journalctl prints out (shortened for saving space):
Sep 27 23:28:02 dog systemd[1]: Starting Video Disk Recorder...
-- Subject: Unit vdr.service has begun start-up
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- Unit vdr.service has begun starting up.
Sep 27 23:28:02 dog vdr[9683]: [9683] VDR version 2.3.8 started
Sep 27 23:28:02 dog vdr[9683]: [9683] switched to user 'vdr'
Sep 27 23:28:02 dog vdr[9683]: [9683] codeset is 'UTF-8' - known
Sep 27 23:28:02 dog vdr[9683]: [9683] found 28 locales in
/usr/share/locale
Sep 27 23:28:02 dog vdr[9683]: [9683] loading plugin:
/usr/lib/vdr/plugins/libvdr-conflictcheckonly.so.2.3.8
[…]
Sep 27 23:28:02 dog vdr[9683]: [9683] loading plugin:
/usr/lib/vdr/plugins/libvdr-live.so.2.3.8
Sep 27 23:28:02 dog vdr[9683]: [9683] [live] INFO: validating server ip
'0.0.0.0'
Sep 27 23:28:02 dog vdr[9683]: INFO: validating live server ip
'0.0.0.0'
Sep 27 23:28:02 dog vdr[9683]: [9683] loading plugin:
/usr/lib/vdr/plugins/libvdr-osddemo.so.2.3.8
[…]
Sep 27 23:28:02 dog vdr[9683]: [9683] probing
/dev/dvb/adapter0/frontend0
Sep 27 23:28:02 dog vdr[9683]: [9683] creating cDvbDevice
Sep 27 23:28:02 dog vdr[9683]: [9683] new device number 1
Sep 27 23:28:02 dog vdr[9683]: [9684] video directory scanner thread
started (pid=9683, tid=9684, prio=low)
Sep 27 23:28:02 dog vdr[9683]: [9684] video directory scanner thread
ended (pid=9683, tid=9684)
Sep 27 23:28:02 dog vdr[9683]: [9683] DVB API version is 0x050A (VDR
was built with 0x050A)
Sep 27 23:28:02 dog vdr[9683]: [9683] frontend 0/0 provides DVB-T,DVB-
T2,DVB-C with QPSK,QAM16,QAM32,QAM64,QAM128,QAM256 ("Silicon Labs
Si2168")
Sep 27 23:28:02 dog vdr[9683]: [9683] cTimeMs: using monotonic clock
(resolution is 1 ns)
Sep 27 23:28:02 dog vdr[9683]: Error opening terminal: unknown.
Sep 27 23:28:02 dog vdr[9683]: [9683] found 1 DVB device
Sep 27 23:28:02 dog vdr[9683]: [9688] device 1 section handler thread
started (pid=9683, tid=9688, prio=low)
Sep 27 23:28:02 dog vdr[9683]: [9687] frontend 0/0 tuner thread started
(pid=9683, tid=9687, prio=high)
[…]
Sep 27 23:28:02 dog systemd[1]: vdr.service: Main process exited,
code=exited, status=1/FAILURE
Sep 27 23:28:02 dog systemd[1]: Failed to start Video Disk Recorder.
-- Subject: Unit vdr.service has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- Unit vdr.service has failed.
-- 
-- The result is failed.
Sep 27 23:28:02 dog systemd[1]: vdr.service: Unit entered failed state.
Sep 27 23:28:02 dog systemd[1]: vdr.service: Failed with result 'exit-
code'.
Sep 27 23:28:02 dog systemd[1]: vdr.service: Service hold-off time
over, scheduling restart.
Sep 27 23:28:02 dog systemd[1]: Stopped Video Disk Recorder.
-- Subject: Unit vdr.service has finished shutting down
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- Unit vdr.service has finished shutting down.
Sep 27 23:28:02 dog systemd[1]: vdr.service: Start request repeated too
quickly.
Sep 27 23:28:02 dog systemd[1]: Failed to start Video Disk Recorder.
-- Subject: Unit vdr.service has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- Unit vdr.service has failed.
-- 
-- The result is failed.
Sep 27 23:28:02 dog systemd[1]: vdr.service: Unit entered failed state.
Sep 27 23:28:02 dog systemd[1]: vdr.service: Failed with result 'exit-
code'.



I'm using the debian package without any p

Bug#877024: modemmanager should ask before messing with serial ports

[Ian Jackson]

Ansgar Burchardt writes ("Bug#877024: modemmanager should ask before messing 
with serial ports"):
> It's not useless.  At least not when using UMTS via USB dongles which I
> would guess more people use than ham radio.  (Some of these USB dongles
> also emulate network cards and provide a DHCP server instead IIRC.)

Right.  These kind of dongles are very common.  My last one (which
died recently) was one.

Also, AIUI modemmanager contains code to do things with the new-style
MBIM dongles (which can also be done with the cli tools in
mbim-utils).  But I definitely wouldn't suggest disabling its ability
to work with AT-command modems, as they are still being sold.[1]

Ian.

[1] I think.  I tried to buy one and ended up with one which is
switchable between MBIM and Hilink instead.

Bug#877031: sextractor FTBFS with multiarch atlas

[Adrian Bunk]

Source: sextractor
Version: 2.19.5+dfsg-4
Severity: serious
Tags: patch

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/sextractor.html

...
checking /usr/include/atlas//cblas.h usability... no
checking /usr/include/atlas//cblas.h presence... no
checking for /usr/include/atlas//cblas.h... no
checking /usr/include/atlas//clapack.h usability... no
checking /usr/include/atlas//clapack.h presence... no
checking for /usr/include/atlas//clapack.h... no
configure: error: CBLAS/LAPack include files not found in /usr/include/atlas/! 
Exiting.


No longer passing the now incorrect paths in debian/rules fixes it:

--- debian/rules.old2017-09-27 21:48:47.0 +
+++ debian/rules2017-09-27 21:49:01.0 +
@@ -15,8 +15,6 @@
dh_auto_configure -- --host=$(DEB_HOST_GNU_TYPE) \
 --build=$(DEB_BUILD_GNU_TYPE) \
  --prefix=/usr --mandir=\$${prefix}/share/man \
- --with-atlas-incdir=/usr/include/atlas/ \
- --with-atlas=/usr/lib/ \
  --disable-threads
 
 # Testing fails with a timeout on the MIPS Debian build system -- probably due

Bug#877030: ITP: pat -- Winlink client with basic messaging capabilities

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
Owner: Antoine Beaupre 

* Package name: pat
  Version : 0.3.0
  Upstream Author : Martin Hebnes Pedersen 
* URL : http://getpat.io/
* License : MIT (Expat)
  Programming Lang: Go
  Description : Winlink client with basic messaging capabilities

Pat is a cross platform Winlink client with basic messaging
capabilities.

It is the primary sandbox/prototype application for the wl2k-go
project, and provides both a command line interface and a responsive
(mobile-friendly) web interface.

It is mainly developed for Linux, but are also known to run on OS X,
Windows and Android.

Features

 * Message composer/reader (basic mailbox functionality).
 * Auto-shrink image attachments.
 * Post position reports with location from local GPS, browser
   location or manual entry.
 * Rig control (using hamlib) for winmor PTT and QSY.
 * CRON-like syntax for execution of scheduled commands (e.g. QSY or
   connect).
 * Built in http-server with web interface (mobile friendly).
 * Git style command line interface.
 * Listen for P2P connections using multiple modes concurrently.
 * AX.25, telnet, WINMOR and ARDOP support.
 * Experimental gzip message compression



I have used pat and it works pretty well. It's the first time I'm
able to use WinLink in a meaningful way in Linux. I remember trying
the Windows binary in Wine a while back and it was really painful. Now
there's a nice interface, both web GUI and commandline. I have yet to
test AX-25, but i'm hopeful to get good results.

There are a lot of vendored dependencies present in the source,
however:

github.com/bndr/gotabulate
github.com/elazarl/go-bindata-assetfs
github.com/fsnotify/fsnotify
github.com/gorhill/cronexpr
github.com/gorilla/context
github.com/gorilla/mux
github.com/gorilla/websocket
github.com/howeyc/gopass
github.com/jteeuwen/go-bindata
github.com/la5nta/wl2k-go
github.com/mattn/go-runewidth
github.com/microcosm-cc/bluemonday
github.com/nfnt/resize
github.com/peterh/liner
github.com/spf13/pflag
golang.org/x/crypto
golang.org/x/net
golang.org/x/sys
golang.org/x/text

I'm unsure which one are already in debian and which ones are not.

Of the above, only the following are missing from Debian, which is
pretty awesome:

github.com/bndr/gotabulate
github.com/la5nta/wl2k-go

and the latter is basically the library backend for pat.

I would be happy to comaintain this or delegate maintainership: just
scratching an itch here. I would also love to get help from the golang
packages as I have never packaged golang stuff before.

An equivalent free software of this is "paclink-unix", but it's
apparently less user-friendly. A comparative of different winlink
clients is available here:

https://www.winlink.org/ClientSoftware

Bug#740094: bug seems to be fixed

[Oliver Grimm]

This bug seems to be fixed in 5.4.1-1~bpo9+1.

Bug#877029: taskcoach: Program fails to start

[william l-k]

Package: taskcoach
Version: 1.4.3-4
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Taskcoach will no longer start on my system. When selecting the program from
the gui nothing happens. Launching from the command line gives this:

 Traceback (most recent call last):
  File "/usr/bin/taskcoach", line 72, in 
start()
  File "/usr/bin/taskcoach", line 63, in start
app = application.Application(options, args)
  File "/usr/lib/python2.7/dist-packages/taskcoachlib/patterns/singleton.py",
line 29, in __call__
class_.instance = super(Singleton, class_).__call__(*args, **kwargs)
  File "/usr/lib/python2.7/dist-
packages/taskcoachlib/application/application.py", line 117, in __init__
self.initTwisted()
  File "/usr/lib/python2.7/dist-
packages/taskcoachlib/application/application.py", line 164, in initTwisted
if map(int, twisted.__version__.split('.')) < (11,):
ValueError: invalid literal for int() with base 10: '0rc1'






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

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

Versions of packages taskcoach depends on:
ii  fonts-dejavu 2.37-1
ii  libxss1  1:1.2.2-1+b2
ii  python   2.7.13-2
ii  python-chardet   3.0.4-1
ii  python-dateutil  2.6.1-1
ii  python-keyring   10.4.0-1
ii  python-lockfile  1:0.12.2-2
ii  python-pyparsing 2.1.10+dfsg1-1
ii  python-squaremap 1:1.0.4-2
ii  python-twisted-core  17.9.0~rc1-1
ii  python-wxgtk3.0  3.0.2.0+dfsg-4
ii  python-wxversion 3.0.2.0+dfsg-4
ii  python-xdg   0.25-4
ii  x11-utils7.7+3+b1
ii  xdg-utils1.1.1-1

Versions of packages taskcoach recommends:
ii  libavahi-compat-libdnssd1  0.7-3
ii  libgnome-2-0   2.32.1-6
ii  python-notify  0.1.1-4

Versions of packages taskcoach suggests:
pn  espeak   
pn  python-kde4  

-- debconf-show failed

Bug#876940: boinc: Depends on libwxgtk-webview3.0-0v5 which depends on webkit1

[Olly Betts]

Note: With Debian's BTS you need to Cc the submitter if you want to
ensure they see it - I only saw your reply because I happened to
check in on the bug.

On Wed, Sep 27, 2017 at 11:21:03AM +0200, Christian Beer wrote:
> There is already an upstream PR [1] that replaces wxWebView with
> wxHtmlWindow. Maybe it's better to wait a bit for the PR and then use
> this to patch 7.8.2 on Debian?
> 
> [1] https://github.com/BOINC/boinc/pull/2093

Sigh, I got the impression from Gianfranco that nobody upstream was
working on this, or I wouldn't have spent time on a patch.

Thanks for the link - I've followed up in the ticket above.

If an upstream patch is actually being worked on but needs more time,
we can drop boinc temporarily from testing and then it can reenter once
patched.

Cheers,
Olly

Bug#877024: modemmanager should ask before messing with serial ports

[Ansgar Burchardt]

"Keith Packard" writes:
> Ian Jackson  writes:
>
> (speaking as a Debian user, not as a TC member)
>
>> I'm afraid don't really want to do the work of writing a better UI.
>> But I have provided a simple patch which at least makes the behaviour
>> safe.
>
> Would it be sufficient to simply stop installing this largely-useless
> package at this point? In what environments do users typically have
> modems which work with AT-style commands?

It's not useless.  At least not when using UMTS via USB dongles which I
would guess more people use than ham radio.  (Some of these USB dongles
also emulate network cards and provide a DHCP server instead IIRC.)

Ansgar

Bug#877028: starpu: missing build dependency on gfortran

[Adrian Bunk]

Source: starpu
Version: 1.2.0+dfsg-5
Severity: serious

It seems something was until recently pulling in gfortran,
but not anymore - exposing the missing build dependency:

https://tests.reproducible-builds.org/debian/history/starpu.html
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/starpu.html

...
checking whether we are using the GNU Fortran 77 compiler... no
checking whether f77 accepts -g... no
checking whether we are using the GNU Fortran compiler... no
checking whether f77 accepts -g... no
...
f77  -g -O2 -fstack-protector-strong -c -o starpu_mod.o 
'../../'include/starpu_mod.f90
/bin/bash: f77: command not found
Makefile:8930: recipe for target 'starpu_mod.o' failed
make[4]: *** [starpu_mod.o] Error 127

Bug#877024: modemmanager should ask before messing with serial ports

[Keith Packard]

Ian Jackson  writes:

(speaking as a Debian user, not as a TC member)

> I'm afraid don't really want to do the work of writing a better UI.
> But I have provided a simple patch which at least makes the behaviour
> safe.

Would it be sufficient to simply stop installing this largely-useless
package at this point? In what environments do users typically have
modems which work with AT-style commands?

It would be far safer to not install this package than try to hack it up
to keep it from breaking systems. Simply removing it from 'depends' on
the handful of packages which currently list it would 'fix' this problem
with a minimum of fuss.

-- 
-keith


signature.asc
Description: PGP signature

Bug#876701: rc-alert: a patch for ~/.boring-bugs to ignore

[Guillem Jover]

Hi!

On Mon, 2017-09-25 at 00:37:57 +0200, Adam Borowski wrote:
> Package: devscripts
> Version: 2.17.10
> Severity: wishlist
> Tags: patch

> Thus, it'd be nice to be able to mark bugs _you_ don't care about.  I don't
> think this is a good use for usertags: your personal preferences are utterly
> irrelevant for others.  Thus, such a list would be best stored locally.
> 
> Here's a patch that implements "~/.boring-bugs".  If such a file exists, all
> lines starting with a bug number make rc-alert and tools that use it filter
> out those bugs.

Could this file be namespaced under some devscripts directory, ideally
under the XDG hierarchy?

Thanks,
Guillem

Bug#876382: dput: TypeError when custom port specified

[Ben Finney]

Control: retitle -1 dput: TypeError when custom port specified
Control: tags -1 + pending

On 22-Sep-2017, Ben Finney wrote:
> This is more wide-reaching; it's not only one upload method.
> 
> The command-line argument processing is wrong. It needs to convert
> the ‘port’ argument when it is read from the command line.

The argument is not read from the command line, it is parsed from the
‘fqdn’ value text.

I have implemented a fix for this, which will be in the next release.

-- 
 \ “Religions have contrived to make it impossible to disagree |
  `\   with them critically, without being rude.” —Daniel Dennett, |
_o__)  _The Four Horsemen_, 2008-05-20 |
Ben Finney 


signature.asc
Description: PGP signature

Bug#706656: ITP: cura -- Controller for 3D printers

[Petter Reinholdtsen]

[Gregor Riepl]
> Yes. The source packages I pushed to Debian Mentors correspond to the
> branches on git.debian.org.

Very good.  I had a quick look at some of the packages, and noticed a
few things, none of which is serious enough to delay an upload to the
NEW queue for review.

Do you plan to maintain these packages as part of the 3dprinter group?
If so, the maintainer should be changed from your name to the mailing
list, to make sure the packages show up on
https://qa.debian.org/developer.php?login=3dprinter-gene...@lists.alioth.debian.org
 >.

The packages have outdated standards-version.  The current one is 4.1.0,
if I am not mistaken.

You mention that you suspect the lintian issue
hardening-no-fortify-functions might be a bug in lintian or g++.  I am
quite sure it is not a bug in lintian, and suggest to not hide it until
you figure out what is going on.

Did you consider multiarch when structuring the library packages?

The cura-engine package is already in Debian, so a new upload should
either use a different package name or continue the d/changelog from
where the last upload left off.

> As far as I can see, there is nothing in the way of code licenses that
> would block a release. A license compatibility cross-check may still
> be useful - perhaps I missed something.

I did not see anything obvious.

>> It did seem quite complicated.  Some of it could be made easier by
>> adding a debian/gpb.conf file, and some of it could perhaps be made
>> easier by using gbp import-orig.  Why do you use release branches?  I
>> normally do not.
>
> Mostly because upstream works with release branches too. Branches make code
> comparison a bit easier.

I suspect you can get a similar effect by importing orig tarballs (with
pristine-tar, preferably) using the --upstream-vcs-tag=tag_name
argument.

Which package do you believe should be uploaded first?

-- 
Happy hacking
Petter Reinholdtsen

Bug#877027: python3-requests: Please provide a -doc package

[Diane Trout]

Package: python3-requests
Version: 2.18.1-1
Severity: wishlist

Dear Maintainer,

Please provide a requests documentation package.

It looks like requests is one of the packages where upstream doesn't
ship the documentation files in the source package uploaded to pypi.

It is available from the releases on github though.

In the case of pypi packages missing docs or tests, I tend to pull
directly from github. But it might also be worth trying to talk upstream
into including them on pypi.

Thank you,
Diane


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

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

Versions of packages python3-requests depends on:
ii  ca-certificates  20170717
ii  python3  3.5.3-3
ii  python3-certifi  2017.4.17-2
ii  python3-chardet  3.0.4-1
ii  python3-idna 2.5-1
ii  python3-urllib3  1.21.1-1

python3-requests recommends no packages.

Versions of packages python3-requests suggests:
ii  python3-cryptography  1.9-1
ii  python3-idna  2.5-1
ii  python3-openssl   16.2.0-1
ii  python3-socks 1.6.5-1

-- no debconf information

Bug#877026: cinnamon: Cinamon fills logs with window manager warnings

[Martin Hardcastle]

Package: cinnamon
Version: 3.2.7-4
Severity: critical
Tags: upstream
Justification: breaks unrelated software

Dear Maintainer,

In some circumstances (maybe to do with screen rotation/multiple monitors)
cinnamon in stretch spams messages of the form

Sep 27 21:48:22 sirius /usr/lib/gdm3/gdm-x-session[3520]: Window manager
warning: Log level 8: meta_screen_get_monitor_geometry: assertion 'monitor >= 0
&& monitor < screen->n_monitor_infos' failed

to the logs many times per second. This can fill the root partition and make
the system temporarily unusable.

https://github.com/linuxmint/muffin/issues/267

may be relevant.




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

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

Versions of packages cinnamon depends on:
ii  caribou  0.4.21-1+b1
ii  cinnamon-common  3.2.7-4
ii  cinnamon-control-center  3.2.1-3
ii  cinnamon-desktop-data3.2.4-4
ii  cinnamon-screensaver 3.2.13-4
ii  cinnamon-session 3.2.0-4
ii  cinnamon-settings-daemon 3.2.1-3
ii  cjs  3.2.0-3
ii  cups-pk-helper   0.2.6-1+b1
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2+b1
ii  gir1.2-accountsservice-1.0   0.6.43-1
ii  gir1.2-caribou-1.0   0.4.21-1+b1
ii  gir1.2-clutter-1.0   1.26.0+dfsg-3
ii  gir1.2-cmenu-3.0 3.2.0-3
ii  gir1.2-cogl-1.0  1.22.2-2
ii  gir1.2-cvc-1.0   3.2.4-4
ii  gir1.2-gdkpixbuf-2.0 2.36.5-2+deb9u1
ii  gir1.2-gkbd-3.0  3.22.0.1-1+b1
ii  gir1.2-glib-2.0  1.50.0-1+b1
ii  gir1.2-gnomedesktop-3.0  3.22.2-1
ii  gir1.2-gtk-3.0   3.22.11-1
ii  gir1.2-gtkclutter-1.01.8.2-2
ii  gir1.2-javascriptcoregtk-3.0 2.4.11-3
ii  gir1.2-keybinder-3.0 0.3.1-1
ii  gir1.2-meta-muffin-0.0   3.2.1-2
ii  gir1.2-networkmanager-1.01.6.2-3
ii  gir1.2-notify-0.70.7.7-2
ii  gir1.2-pango-1.0 1.40.5-1
ii  gir1.2-polkit-1.00.105-18
ii  gir1.2-soup-2.4  2.56.0-2+deb9u1
ii  gir1.2-upowerglib-1.00.99.4-4+b1
ii  gir1.2-xapp-1.0  1.0.2-1
ii  gkbd-capplet 3.22.0.1-1+b1
ii  gnome-backgrounds3.22.1-1
ii  gnome-themes-standard3.22.2-2
ii  gsettings-desktop-schemas3.22.0-1
ii  iso-flags-png-320x2401.0.1-1
ii  libatk-bridge2.0-0   2.22.0-2
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-11+deb9u1
ii  libcairo21.14.8-1
ii  libcinnamon-menu-3-0 3.2.0-3
ii  libcjs0  3.2.0-3
ii  libclutter-1.0-0 1.26.0+dfsg-3
ii  libcogl-pango20  1.22.2-2
ii  libcogl-path20   1.22.2-2
ii  libcogl201.22.2-2
ii  libcroco30.6.11-3
ii  libgdk-pixbuf2.0-0   2.36.5-2+deb9u1
ii  libgirepository-1.0-11.50.0-1+b1
ii  libgl1-mesa-glx [libgl1] 13.0.6-1+b2
ii  libglib2.0-0 2.50.3-2
ii  libglib2.0-bin   2.50.3-2
ii  libgstreamer1.0-01.10.4-1
ii  libgtk-3-0   3.22.11-1
ii  libjs-jquery 3.1.1-2
ii  libmozjs-24-024.2.0-5.1+b2
ii  libmuffin0   3.2.1-2
ii  libpango-1.0-0   1.40.5-1
ii  libpangocairo-1.0-0  1.40.5-1
ii  libstartup-notification0 0.12-4+b2
ii  libx11-6 2:1.6.4-3
ii  libxfixes3   1:5.0.3-1
ii  libxml2  2.9.4+dfsg1-2.2+deb9u1
ii  mesa-utils   8.3.0-3
ii  muffin   3.2.1-2
ii  nemo   

Bug#877023: debian-policy: No section numbers in policy.txt.gz

[Olly Betts]

Control: forcemerge 872868 877023

Sorry, I failed to spot the existing report.

Cheers,
Olly

Bug#877025: nmu: dlib_18.18-2

[Adrian Bunk]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
Control: affects -1 src:plastimatch

The latest plastimatch binNMU did FTBFS due to libdlib-dev exposing
the full path to libblas.so in CMake files, which changed with the
recent BLAS multiarchification.

nmu dlib_18.18-2 . ANY . unstable . -m "rebuild with multiarch libblas3"
gb plastimatch_1.6.5+dfsg.1-1 . amd64 i386 . --extra-depends "libdlib-dev (>= 
18.18-2+b1)"

Bug#742829: closed by intrigeri (Bug#742829: fixed in apparmor 2.10.95-8)

[Daniel Richard G.]

On Wed, 2017 Sep 27 22:26+0200, Guido Günther wrote:
>
> Great! I'm a big fan of doing things upstream but from my pov I'd
> consider apparmor or chromium to be upstream not Ubuntu. What about
> filing a bug against the Debian chromium package with an updated
> profile as a start? We can then take it from there and file another
> one against apparor once it proves working for more people.

That would amount to the Debian Chromium maintainers becoming the new
upstream for the profile. (Apparmor is basically maintained by
Canonical, so also Ubuntu, and Google pretty surely will never touch
this.) If they're willing, I can hardly see how they could do worse
than Ubuntu.

And if it does work out, then that would be a basis to have Ubuntu ship
the Debian profile instead of its own (neglected) version.

I don't know any of the Debian-Chromium folks to have a sense of what
they're open to; would you?

I'll be happy to provide that updated Chromium profile if you want it.

Bug#877024: modemmanager should ask before messing with serial ports

[Ian Jackson]

Package: tech-ctte
Control: block 683839 by -1

modemmanager is a program for handling modems, particularly
usb-connected mobile-telephony modems (aka "3G/4G sticks" etc.)

Many such modems present as USB serial devices, eg ttyACM or ttyUSB.
Consequently, modemmanager has the ability to open serial ports and
probe them to see if they respond to Hayes-style AT commands.  That
functionality is currently triggered automatically by default, even
for USB serial ports whose USB device IDs are unknown to modemmanager,
or whose device IDs correspond to generic USB-to-serial adapters.

I.e., if one is running a normal Debian installation and plugs in a
usb-to-serial converter, modemmanager will open the device and send AT
commands to it, to see if it is a modem.

This behaviour is IMO unaccaptable, as a default.

Serial connections are used to connect a wide variety of equipment
including industrial robots, electronic test equipment capable of
generating hazardous voltages, accessibility hardware, scientific
instruments, and embedded computers.

In the worst case (luckily, as far as I know, hypothetical):

 * This behaviour could cause someone personal injury, if a real-world
   device connected to the serial port misinteprets modemmanager's
   probe (or if its control firmware crashes) and makes hazardous
   movements or some such

Symptoms which have been observed include:

 * User's braille display stopped working during system boot
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=621851
   With a less resourceful user, that might make the computer
   completely unuseable.

 * Random number generator "interfered with"
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=840697
   Ultimate consequences not clear from the bug report, but if the RNG
   driver software has poor error handling it might include poor
   quality random numbers and therefore weak cryptographic keys.

 * GPS no longer recognised at boot
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798193
   (Not as trivial a problem as it sounds, as it could prevent the
   system being used as a navigation aid.)

 * "Breaks" apcupsd
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683839#32

 * User's Palm Pilot PDA crashes
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683839#52

 * User's 1-wire DS9097 interface is messed up, requiring a
   reboot to become functional again
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683839#72

 * My 3D printer reported protocol violations on startup
   and host software could sometimes not connect to printer
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683839#5

Other possible consequences which have been hypothesised are:

 * Simply opening the port and enabling RTS might enable radio
   transmissions in a ham radio context
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683839#42
   (Resulting in possibly-illegal radio interference.)

 * Simply opening the port and enabling RTS switches some scientific
   equipment into remote control mode, disabling the front panel
   and perhaps leading to hazardous situations.  (pers. comm)

 * Some 3D printers will reset when RTS is toggled, interrupting
   any print job (causing real world lossage in the form of wasted
   feedstock and printer time)
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683839#32

In August 2012 I experienced this bug and filed #683839 with severity
`important'.  The maintainers apparently do not agree with my analysis
and there has been no action by them since then other than efforts to
maintain the blocklist.

In the intervening time many users have reported manifestations of
this problem to #683839 and to other bug reports.  The reactions from
the maintainers have consistently been to try to get individual
devices blocklisted, even though as has been explained repeatedly,
this is not really sufficient.  The maintainers have not engaged with
the arguments against blanket probing.

Note that safe behaviour does not necessarily mean that every time the
user plugs in their modem, they have to confirm its use.  Other
solutions are possible, for example asking for explicit permission
from the user, the first time any particular device is seen, that it
is OK to probe that device.  (Similar behaviour is already implemented
for USB HID devices - keyboards etc. - because of the security
implications.)

I'm afraid don't really want to do the work of writing a better UI.
But I have provided a simple patch which at least makes the behaviour
safe.

IMO at the very least, for buster, we should apply that patch - or an
equivalent - and then the maintainers can consider how to improve the
UI/UX to explicitly ask permission, if they think that is desirable.

We should also consider whether to backport any of the resulting
changes, or include them in stable updates of some kind.

Thanks for your attention.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net

Bug#808379: please consider patch to customize E-Mail Subject

[Ola Lundqvist]

Hi

Yes, but maybe I accidentally signed it with the old key. I'll check
and re-upload.

// Ola

On 27 September 2017 at 16:54, Marc Haber  wrote:
> On Tue, Sep 26, 2017 at 08:38:01PM +0200, Ola Lundqvist wrote:
>> Uploaded to unstable now.
>
> Did your upload work? Package is not in unstable as of now.
>
> Greetings
> Marc
>
> --
> -
> Marc Haber | "I don't trust Computers. They | Mailadresse im Header
> Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
> Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#877023: debian-policy: No section numbers in policy.txt.gz

[Olly Betts]

Package: debian-policy
Version: 4.1.0.0
Severity: important

/usr/share/doc/debian-policy/policy.txt.gz no longer has any section
numbers, which makes it useless as a way to quickly locate a policy
section to quote to someone as a reference.  The plain text version is
the easiest to search, so this is a really annoying regression.

Cheers,
Olly

Bug#877022: i2p: README.Debian refer to wrong port number in config URL

[Jonas Smedegaard]

Package: i2p
Version: 0.9.30-4
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

README.Debian says to access http://localhost:5657
but that URL fails.

Upstream documentation refers to URLs below http://localhost:7657/ which works.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlnMCpsACgkQLHwxRsGg
ASEmFhAAqD/eAPUbAc6unXkw5hGUc+4rY42VBabeBmC+Z53igQCOiB+OmokJB2Vw
GCELn+8w1a2z5y21gtk7I7WKz6wnu81QCvf9vK7X75KzhPizvm9FMKBuZ19jzrw2
2MGg35yHeeUvCBySrw/XKbHd7h0MYA0ov4T+M/oapBwJsaedFxYknYeA7xTSzA7X
yrUmGGmPEIvQ6akHCe7GdV5rZogRWqzZkxUKVXp1JABTjy/pIXarTp9vSRl1fr96
qTO8+aCcCOoe8fmJlik9QtB+wG4G532AnFQ34850+XdLr/HJUL24LYZhOgv/4Jb5
Z1wOmXkmgz9//xcGE2+xc97F/aA6uQX0nadbZQ9B+xnVgQHMxd0shCxemHCn8csN
YXFu0bCr3FoEBkRKhp8EHGk+xLajr+x1FFXSYkNoE+iF0/lXE3HQ5gOJ/93T1WWp
iAGuuEJ1cPh79DgACPahkNPC0+xKmmiQmVWVgvfYi73x7h81pSwN91YnereN6LIl
4nDciA91q9QSfVO0u9fWCOiGhZVXFuhky0TwhXejgnugqZgoyevBnVKT/zFrVqmx
21PtFvm6xg6DjFHlvABsA6ffrBM1J1ZFkS+jMnMa+uxFwW2ZPqguU8ktOrh6Gyvh
FYoHKfkN1nV69GKQkoGd2O2jZWIymt7csDdiC5X0jFLFfbMYtQo=
=I0XH
-END PGP SIGNATURE-

Bug#742829: closed by intrigeri (Bug#742829: fixed in apparmor 2.10.95-8)

[Guido Günther]

Hi Richard,
On Wed, Sep 27, 2017 at 03:49:48PM -0400, Daniel Richard G. wrote:
> Hi Guido!
> 
> On Wed, 2017 Sep 27 15:31+0200, Guido Günther wrote:
> > 
> > I stumbled across this today again since I was looking for a chromium
> > profile and still had one in /etc/apparmor.d/usr.bin.chromium-browser
> > so it seems the fix for 742829 didn't remove existing files:
> > 
> >$ dpkg -S /etc/apparmor.d/usr.bin.chromium-browser 
> >apparmor-profiles: /etc/apparmor.d/usr.bin.chromium-browse
> > 
> > So I ended up writing the same fixes in that were already suggested
> > here and I wonder why we can't just ship a profile if it's working
> > for people?
> 
> You'll get no argument from me :)  The main difficulty I've had is
> getting upstream (Ubuntu) to accept patches to fix the profile whenever
> Chromium's footprint gets bigger.

Great! I'm a big fan of doing things upstream but from my pov I'd
consider apparmor or chromium to be upstream not Ubuntu. What about
filing a bug against the Debian chromium package with an updated profile
as a start? We can then take it from there and file another one against
apparor once it proves working for more people.
Cheers,
 -- Guido

> 
> Case in point: No one's looked at this (old) merge request since it
> was posted, even though I was told to file a merge request to get
> my fixes in:
> 
> 
> https://code.launchpad.net/~skunk/apparmor-profiles/+git/apparmor-profiles/+merge/321802
> 
> I wouldn't mind officially maintaining the Chromium profile myself,
> given that I already do so for my own use and would like to see others
> benefit as well.
> 
> > That said I'd rather see this shipped with the chromium package so we
> > could reassign this (or open a separate report).
> 
> I'd like to see this happen too, if for no other reason than that the
> Chromium profile is currently maintained in a sort of no-man's land on
> the Ubuntu side.
> 

Bug#877014: python3-sphinx exception building breathe

[Dmitry Shachnev]

Control: clone -1 -2
Control: reassign -2 src:breathe
Control: forwarded -2 https://github.com/michaeljones/breathe/pull/353
Control: tags -2 +patch
Control: severity -1 important

Hi Adrian and Sebastian!

On Wed, Sep 27, 2017 at 09:51:49PM +0300, Adrian Bunk wrote:
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/breathe.html
>
> [...]
>   File "/usr/lib/python3/dist-packages/sphinx/domains/cpp.py", line 4969, in 
> checkType
> assert False
> AssertionError
> Type is member, declType is class

I agree that there is a breaking change in Sphinx 1.6.4: instead of printing
a warning about type mismatch, it raises AssertionError.

However in my opinion the real issue here is in breathe, and it should be
fixed in the first place. I have just created an upstream pull request about
this, and with that change applied breathe builds fine.

I will also create a pull request to sphinx fixing the regression, but unless
there are other affected packages I will not backport it to Debian before new
upstream release.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#876879: Acknowledgement (ttf-mscorefonts-installer: computed checksum did NOT match)

[Markus Kolb]

Hi,
I've tried it today again and it was ok.
We've had yesterday some network problems. Maybe this was the cause.

Bug#877020: openssh-client: Fails to unlink ControlMaster socket early enough, confuses other clients

[Paul "LeoNerd" Evans]

Package: openssh-client
Version: 1:7.5p1-5
Severity: normal

TL;DR: ssh(1) must unlink local socket _before_ attempting more network
  traffic otherwise broken TCP sockets will stall the entire thing.

-

I make heavy use of the shared control sockets to multiplex multiple
shells, sftp, and other commands down a single TCP connection to remote
servers.

  ControlPath ~/var/run/ssh-master-%r@%h:%p.sock
  ControlPersist 1s
  ControlMaster auto

In this setup, under stable networking all works nicely.

However, my machine is a laptop, and sometimes due to mobile data, wifi,
ethernet cable swapping, or other isses my IP address and hence routing
change. After such a change, all existing TCP sockets are now unuseable
and must be closed and reopened.

Simply closing all ssh clients is insufficient here, because the client
tries to perform a controlled shutdown of the TCP socket *first* and
will only unlink(2) the control master socket from the local filesystem
after it has done this. By ordering the operations thus, the client
stalls trying to perform this controlled TCP shutdown over now-invalid
networking, and never gets around to removing the local unix socket. New
ssh clients would try to use this and similarly stall.

The correct order of operation ought to be that the control master local
socket is unlinked *before* trying to send any traffic, thus restoring
the user's "turn it off and on again" approach to fixing the problem -
namely by just killing all their clients and making a new one.


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

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

Versions of packages openssh-client depends on:
ii  adduser   3.116
ii  dpkg  1.18.24
ii  libc6 2.24-12
ii  libedit2  3.1-20170329-1
ii  libgssapi-krb5-2  1.15.1-2
ii  libselinux1   2.6-3+b2
ii  libssl1.0.2   1.0.2l-2
ii  passwd1:4.4-4.1
ii  zlib1g1:1.2.8.dfsg-5

Versions of packages openssh-client recommends:
ii  xauth  1:1.0.9-1+b2

Versions of packages openssh-client suggests:
pn  keychain  
pn  libpam-ssh
pn  monkeysphere  
pn  ssh-askpass   

-- Configuration Files:
/etc/ssh/ssh_config changed:
Host *
SendEnv LANG LC_*
HashKnownHosts no
GSSAPIAuthentication yes
GSSAPIDelegateCredentials no


-- no debconf information


-- 
Paul "LeoNerd" Evans

leon...@leonerd.org.uk  |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/

Bug#877019: ITP: nix -- Purely functional package manager

[Kai Harries]

Package: wnpp
Severity: wishlist
Owner: Kai Harries 

* Package name: nix
  Version : 1.1.15
  Upstream Author : Eelco Dolstra 
* URL : https://nixos.org/nix/
* License : LGPL v2.1
  Programming Lang: C++, Shell, C, Perl
  Description : Purely functional package manager

A powerful package manager for Linux and other Unix systems that
makes package management reliable and reproducible. Nix provides
atomic upgrades and rollbacks, side-by-side installation of multiple
versions of a package, multi-user package management and easy setup of
build environments. 

I personally use it to install software that is not part of Debian or
software that I need in a newer version.

My packaging efforts can be found here [1].

I am looking for a sponsor.

[1] https://github.com/KaiHa/nix-debian/releases

Bug#876964: ycmd: libclang1-3.9 crashes when ycmd starts after upgrade to version 1:3.9.1-16

[Yllman, Jens]

Yes, the change is probably in libclang1-3.9. But to me it only looks 
like libclang1-3.9 got stricter on reading JSON. In the error message 
you can see the error in the JSON that is sent to libclang1-3.9 from 
ycmd. So, I think it is ycmd that is wrong. But earlier versions of 
libclang1-3.9 was more forgiving. On the other end, libclang1-3.9 should 
not crash on this? But last entry in a list or object of JSON should not 
have a , at the end.

Bug#877018: texlive-luatex: Missing dependency to etoolbox, which is required by lualatex-math to function

[Timo Kalliomäki]

Package: texlive-luatex
Version: 2016.20170123-5
Severity: important

Dear Maintainer,

lualatex-math in this package requires etoolbox to function. There is no 
dependency or even recommendation path to texlive-latex-extra where 
etoolbox is placed. So, just installing this package and trying to use 
lualatex-math (in my case it was required by unicode-math) leads to 
documents not compiling.


Best regards,
Timo

-- Package-specific info:
IMPORTANT INFORMATION: We will only consider bug reports concerning
the packaging of TeX Live as relevant. If you have problems with
combination of packages in a LaTeX document, please consult your
local TeX User Group, the comp.text.tex user group, the author of
the original .sty file, or any other help resource.

In particular, bugs that are related to up-upstream, i.e., neither
Debian nor TeX Live (upstream), but the original package authors,
will be closed immediately.

   *** The Debian TeX Team is *not* a LaTeX Help Desk ***

If you report an error when running one of the TeX-related binaries
(latex, pdftex, metafont,...), or if the bug is related to bad or wrong
output, please include a MINIMAL example input file that produces the
error in your report.

Please run your example with
(pdf)latex -recorder ...
(or any other program that supports -recorder) and send us the generated
file with the extension .fls, it lists all the files loaded during
the run and can easily explain problems induced by outdated files in
your home directory.

Don't forget to also include minimal examples of other files that are
needed, e.g. bibtex databases. Often it also helps
to include the logfile. Please, never send included pictures!

If your example file isn't short or produces more than one page of
output (except when multiple pages are needed to show the problem),
you can probably minimize it further. Instructions on how to do that
can be found at

http://www.minimalbeispiel.de/mini-en.html (english)

or

http://www.minimalbeispiel.de/mini.html (german)

##
minimal input file


##
other files

##
 List of ls-R files

-rw-r--r-- 1 root root 1200 Sep 27 22:41 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 Jan 17  2017 /usr/share/texmf/ls-R -> 
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 Mar  4  2017 
/usr/share/texlive/texmf-dist/ls-R -> /var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 Mar  4  2017 
/usr/share/texlive/texmf-dist/ls-R -> /var/lib/texmf/ls-R-TEXLIVEDIST

##
 Config files
-rw-r--r-- 1 root root 475 Sep 15 22:48 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 Mar  4  2017 
/usr/share/texmf/web2c/fmtutil.cnf -> /var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 Mar  4  2017 /usr/share/texmf/web2c/updmap.cfg 
-> /var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 3613 Sep 27 17:11 
/var/lib/texmf/tex/generic/config/language.dat

##
 Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 Jan 17  2017 mktex.cnf
-rw-r--r-- 1 root root 475 Sep 15 22:48 texmf.cnf
##
 md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf

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

Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), 
LANGUAGE= (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages texlive-luatex depends on:
ii  libjs-jquery  3.1.1-2
ii  tex-common6.06
ii  texlive-base  2016.20170123-5
ii  texlive-binaries  2016.20160513.41080.dfsg-2

texlive-luatex recommends no packages.

texlive-luatex suggests no packages.

Versions of packages tex-common depends on:
ii  dpkg  1.18.24
ii  ucf   3.0036

Versions of packages tex-common suggests:
pn  debhelper  

Versions of packages texlive-luatex is related to:
ii  tex-common6.06
ii  texlive-binaries  2016.20160513.41080.dfsg-2

-- no debconf information

Bug#861281: rnahybrid: FTBFS on armel

[Edmund Grimley Evans]

Those loop nests that set every element of a multi-dimensional array
to (floating-point) zero could perhaps be replaced with memset (not
officially portable) or memcpy (from a local variable of the same type
with an initialiser).

Bug#742829: closed by intrigeri (Bug#742829: fixed in apparmor 2.10.95-8)

[Daniel Richard G.]

Hi Guido!

On Wed, 2017 Sep 27 15:31+0200, Guido Günther wrote:
> 
> I stumbled across this today again since I was looking for a chromium
> profile and still had one in /etc/apparmor.d/usr.bin.chromium-browser
> so it seems the fix for 742829 didn't remove existing files:
> 
>$ dpkg -S /etc/apparmor.d/usr.bin.chromium-browser 
>apparmor-profiles: /etc/apparmor.d/usr.bin.chromium-browse
> 
> So I ended up writing the same fixes in that were already suggested
> here and I wonder why we can't just ship a profile if it's working
> for people?

You'll get no argument from me :)  The main difficulty I've had is
getting upstream (Ubuntu) to accept patches to fix the profile whenever
Chromium's footprint gets bigger.

Case in point: No one's looked at this (old) merge request since it
was posted, even though I was told to file a merge request to get
my fixes in:


https://code.launchpad.net/~skunk/apparmor-profiles/+git/apparmor-profiles/+merge/321802

I wouldn't mind officially maintaining the Chromium profile myself,
given that I already do so for my own use and would like to see others
benefit as well.

> That said I'd rather see this shipped with the chromium package so we
> could reassign this (or open a separate report).

I'd like to see this happen too, if for no other reason than that the
Chromium profile is currently maintained in a sort of no-man's land on
the Ubuntu side.

Bug#877017: ITP: python-rstr -- easily generate random strings of various types

[Ximin Luo]

Package: wnpp
Severity: wishlist
Owner: Ximin Luo 

* Package name : python-rstr
  Version : 2.2.6
  Upstream Author : Brendan McCollam 
* URL : https://bitbucket.org/leapfrogdevelopment/rstr/
* License : BSD-3-Clause
  Programming Lang: Python
  Description : Easily generate random strings of various types

rstr is a helper module for easily generating random strings of various 
types. It could be useful for fuzz testing, generating dummy data, or 
other applications. It has no dependencies outside the standard library, 
and is compatible with Python 3.

The basic method of rstr is rstr(). At a minimum, it requires one 
argument, an alphabet of characters from which to create a string.

Inspired by the Java library of the same name, the xeger() method allows 
users to create a random string from a regular expression.

You can combine rstr with Python's built-in string formatting to produce 
strings that fit a variety of templates.

Bug#877000: Acknowledgement (mutt: not plain/text /usr/share/doc/mutt/manual.txt.gz)

[Jari Aalto]

Fix:

   Please add to debian/rules additional step, where the manual.txt is
   treated for removing overstrike using call to:

   col -bx

   e.g. in override_dh_install

Jari

Bug#874845: [clonalframe] Future Qt4 removal from Buster

[Xavier Didelot]

Perfect, thanks Andreas!
Xavier

On 27 September 2017 at 19:56, Andreas Tille  wrote:
> Hi Xavier,
>
> On Wed, Sep 27, 2017 at 04:42:49PM +0100, Xavier Didelot wrote:
>>
>> Thanks very much for your work on this. I have added your patches to
>> the github version. For the version.h file I think including the
>> debian package revision number is the right thing to do since we can't
>> call git.
>
> OK.
>
>> Concerning the old ClonalFrame, I would recommend removing it
>> completely since I am no longer going to maintain it and it is
>> superseeded by ClonalFrameML.
>
> Since the porting was super-easy (you are not really using Qt but only
> qtmake there was no code change needed.  So I keep the package but
> recommend ClonalFrameML in it.
>
> Kind regards
>
>  Andreas.
>
> --
> http://fam-tille.de

Bug#877016: Time to drop cpufrequtils?

[Phil Susi]

Package: cpufrequtils
Version: 008-1

In your last changelog entry from 2012, you mentioned that this should
be the last time this package is packaged, as it was being replaced by
cpupowerutils.  It appears that cpupowerutils is part of the upstream
kernel source and built in the linux-tools-xxversionxx package.  If this
is the case, should cpufrequtils not be removed now?

Bug#877015: fizmo FTBFS with debhelper 10.9

[Adrian Bunk]

Source: fizmo
Version: 0.7.10-2
Severity: serious
Tags: buster sid

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/fizmo.html

...
dh_prep -pbuild-stamp
dh_prep: Requested unknown package build-stamp via -p/--package, expected one 
of: fizmo-common fizmo-ncursesw fizmo-console
dh_prep: unknown option or error during option parsing; aborting
debian/rules:31: recipe for target 'build-stamp' failed
make: *** [build-stamp] Error 25

Bug#874845: [clonalframe] Future Qt4 removal from Buster

[Andreas Tille]

Hi Xavier,

On Wed, Sep 27, 2017 at 04:42:49PM +0100, Xavier Didelot wrote:
> 
> Thanks very much for your work on this. I have added your patches to
> the github version. For the version.h file I think including the
> debian package revision number is the right thing to do since we can't
> call git.

OK.
 
> Concerning the old ClonalFrame, I would recommend removing it
> completely since I am no longer going to maintain it and it is
> superseeded by ClonalFrameML.

Since the porting was super-easy (you are not really using Qt but only
qtmake there was no code change needed.  So I keep the package but
recommend ClonalFrameML in it.

Kind regards

 Andreas.

-- 
http://fam-tille.de

Bug#877014: python3-sphinx exception building breathe

[Adrian Bunk]

Package: python3-sphinx
Version: 1.6.4-1
Severity: serious
Control: affects -1 src:breathe

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/breathe.html

...
writing output... [ 25%] differences
writing output... [ 27%] directives
writing output... [ 30%] domains
Exception occurred while building, starting debugger:
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/sphinx/cmdline.py", line 306, in main
app.build(opts.force_all, filenames)
  File "/usr/lib/python3/dist-packages/sphinx/application.py", line 339, in 
build
self.builder.build_update()
  File "/usr/lib/python3/dist-packages/sphinx/builders/__init__.py", line 331, 
in build_update
'out of date' % len(to_build))
  File "/usr/lib/python3/dist-packages/sphinx/builders/__init__.py", line 397, 
in build
self.write(docnames, list(updated_docnames), method)
  File "/usr/lib/python3/dist-packages/sphinx/builders/__init__.py", line 434, 
in write
self._write_serial(sorted(docnames))
  File "/usr/lib/python3/dist-packages/sphinx/builders/__init__.py", line 441, 
in _write_serial
doctree = self.env.get_and_resolve_doctree(docname, self)
  File "/usr/lib/python3/dist-packages/sphinx/environment/__init__.py", line 
910, in get_and_resolve_doctree
self.apply_post_transforms(doctree, docname)
  File "/usr/lib/python3/dist-packages/sphinx/environment/__init__.py", line 
957, in apply_post_transforms
transformer.apply_transforms()
  File "/usr/lib/python3/dist-packages/sphinx/transforms/__init__.py", line 92, 
in apply_transforms
Transformer.apply_transforms(self)
  File "/usr/lib/python3/dist-packages/docutils/transforms/__init__.py", line 
171, in apply_transforms
transform.apply(**kwargs)
  File 
"/usr/lib/python3/dist-packages/sphinx/transforms/post_transforms/__init__.py", 
line 89, in apply
typ, target, node, contnode)
  File "/usr/lib/python3/dist-packages/sphinx/domains/cpp.py", line 5008, in 
resolve_xref
target, node, contnode)[0]
  File "/usr/lib/python3/dist-packages/sphinx/domains/cpp.py", line 4970, in 
_resolve_xref_inner
if not checkType():
  File "/usr/lib/python3/dist-packages/sphinx/domains/cpp.py", line 4969, in 
checkType
assert False
AssertionError
Type is member, declType is class
> /usr/lib/python3/dist-packages/sphinx/domains/cpp.py(4969)checkType()
-> assert False
(Pdb) 
Makefile:54: recipe for target 'html' failed
make[3]: *** [html] Error 1
make[3]: Leaving directory '/build/1st/breathe-4.7.2/documentation'
Makefile:5: recipe for target 'html' failed
make[2]: *** [html] Error 2
make[2]: Leaving directory '/build/1st/breathe-4.7.2'
E: pybuild pybuild:283: build: plugin custom failed with: exit code=2: env 
PYTHONPATH=/build/1st/breathe-4.7.2/.pybuild/pythonX.Y_3.5/build /usr/bin/make 
SPHINXBUILD=/usr/share/sphinx/scripts/python3/sphinx-build
debian/rules:21: recipe for target 'override_dh_auto_build' failed
make[1]: *** [override_dh_auto_build] Error 13


I can reproduce the problem and that downgrading Sphinx
to 1.6.3-2 fixes it.

Bug#706656: ITP: cura -- Controller for 3D printers

[Gregor Riepl]

>> The package is on mentors.debian.net, but you also need to get all the
>> dependencies if you want to build it yourself:
>> https://mentors.debian.net/packages/uploader/onitake%40gmail.com
> 
> Is this the same code as on git.debian.org?

Yes. The source packages I pushed to Debian Mentors correspond to the branches
on git.debian.org.

> OK.  The most important part to review before uploading is
> debian/copyright.  Errors there will block the package from entering
> Debian.  All other errors can be fixed when the package is in unstable. :)

This was a concern initially, but has been resolved.
I checked all files for inconsistent license headers and verified that there
were no leftovers. Bas suggested removing shipped dependencies that are
already available in Debian, and I patched those out successfully.

As far as I can see, there is nothing in the way of code licenses that would
block a release. A license compatibility cross-check may still be useful -
perhaps I missed something.

> It did seem quite complicated.  Some of it could be made easier by
> adding a debian/gpb.conf file, and some of it could perhaps be made
> easier by using gbp import-orig.  Why do you use release branches?  I
> normally do not.

Mostly because upstream works with release branches too. Branches make code
comparison a bit easier.
But since Ultimaker doesn't do minor releases anyway (or hasn't so far), that
seems overkill.
I have no preference personally.

> Btw, you might find this look useful to include in your README:
> 
>   while quilt push ; do quilt refresh; done
> 
> It will refresh all patches unless one of them cause a problem.

Ok. That's a good idea. :)

Bug#877012: apt-setup: debian sources.list entries should have signed-by options pointing to specific keys

[Daniel Kahn Gillmor]

Package: apt-setup
Severity: wishlist
Control: clone -1 -2
Control: retitle -2 set up local repository keys using signed-by option, and do 
not use "apt-key add"
Control: block -1 861695 -2
Control: affects 861695 + apt-setup


When apt-setup creates a sources.list, it currently just expects every
repository key to be already present in /etc/apt/trusted.gpg or
/etc/apt/trusted.gpg.d/*.gpg.

collecting all keys in one repository means that each key is
authorized to sign other repositories as well.  This lack of scoping
makes it difficult to constrain repository owners from malicious
behavior.  It also makes it difficult to know when to remove old keys
-- should the wheezy archive signing key still be enabled on my buster
system?

In #861695, i'm trying to get debian-archive-keyring to ship the
standard repository keys in /usr/share/keyrings/.  on a system where
that's done, apt-setup should write the sources.list snippets for the
debian repos with a "signed-by" option (see sources.list(5), which
points specifically to the key that should be used to authorize this
repo.

I think doing this right for debian repositories is going to require
#861695 to be corrected first, which is why the first bug report here
("debian sources.list entries should have signed-by options pointing
to specific keys") is marked as blocked by that bug.

But apt-setup can fix its configuration of any pre-seeded local
repositories without waiting on the debian-archive-keyring package,
which is the point of the second bug ("set up local repository keys
using signed-by option, and do not use "apt-key add"").

In particular, generators/60local can place the proposed key into a
file *outside* of /etc/apt/trusted.gpg.d/, and can add the signed-by
argument to the sources.list stanza it creates.

The result of fixing these two bugs should be that new installations
can have an empty /etc/apt/trusted.gpg and nothing in
/etc/apt/trusted.gpg.d/*.gpg, and each repository added will be
individually authenticated.  This is a pre-requisite for being able to
more tightly constrain software repositories (e.g. pinning, etc), and
should be the default of the future.

Thanks for helping to maintain debian-installer!

   --dkg

Bug#877011: reposurgeon: "you have not specified an editor and $EDITOR is not set"

[Jakub Wilk]

Package: reposurgeon
Version: 3.42-2

The edit command doesn't work when $EDITOR is not set:

  reposurgeon% edit
  reposurgeon: you have not specified an editor and $EDITOR is not set

This is violation of Policy §11.4, which says that you should fall back 
to /usr/bin/editor when $EDITOR is not set.



-- System Information:
Architecture: i386

Versions of packages reposurgeon depends on:
ii  libc6 2.24-17
ii  libpython2.7  2.7.14-2
ii  python3   3.5.3-3
ii  python2.7.14-1

--
Jakub Wilk

Bug#706656: ITP: cura -- Controller for 3D printers

[Petter Reinholdtsen]

Hi Gregor.

[Gregor Riepl]
> sorry about the delay. I was waiting for a review from Bas (or another
> DD).  The package is also currently stuck at version 2.5.0, due to a
> lack of time on my side, but I'll try to prepare and push an update
> ASAP.

No worries.

> The package is on mentors.debian.net, but you also need to get all the
> dependencies if you want to build it yourself:
> https://mentors.debian.net/packages/uploader/onitake%40gmail.com

Is this the same code as on git.debian.org?

> Thanks, I'll consider it.
> But I'd really prefer another review of the package before releasing
> it into the wild.

OK.  The most important part to review before uploading is
debian/copyright.  Errors there will block the package from entering
Debian.  All other errors can be fixed when the package is in unstable. :)

> I could also use some help with common usage of Debian git.
> My current build/release procedure for Cura is slightly complicated:
> https://anonscm.debian.org/cgit/3dprinter/packages/cura.git/tree/debian/README.source
> The same has to be repeated for all dependencies.

It did seem quite complicated.  Some of it could be made easier by
adding a debian/gpb.conf file, and some of it could perhaps be made
easier by using gbp import-orig.  Why do you use release branches?  I
normally do not.

Btw, you might find this look useful to include in your README:

  while quilt push ; do quilt refresh; done

It will refresh all patches unless one of them cause a problem.

-- 
Happy hacking
Petter Reinholdtsen

Bug#849121: $dbh->state sometimes trashed

[Christoph Berg]

Control: tags -1 moreinfo

Re: Ian Jackson 2016-12-22 <22620.10148.188151.598...@mariner.uk.xensource.com>
> Package: libdbd-pg-perl
> Version: 2.19.2-2+deb7u1

> Sometimes, when used with SET TRANSACTION ISOLATION LEVEL
> SERIALIZABLE, generates this message:
[...]
> Observe that the "state" value is "", meaning no error.  This is
> AFAICT contrary to the documentation and also not very helpful.

Hi Ian,

are you still seeing this behavior with newer versions of DBD::Pg?
2.19.2 was in wheezy.

Christoph


signature.asc
Description: PGP signature

Bug#877010: mpdecimal FTBFS with Sphinx 1.6.4-1: dh_sphinxdoc: DOCUMENTATION_OPTIONS does not define SOURCELINK_SUFFIX

[Adrian Bunk]

Source: mpdecimal
Version: 2.4.2-1
Severity: serious
Tags: buster sid

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/mpdecimal.html

...
dh_sphinxdoc
dh_sphinxdoc: DOCUMENTATION_OPTIONS does not define SOURCELINK_SUFFIX
debian/rules:56: recipe for target 'override_dh_sphinxdoc' failed
make[1]: *** [override_dh_sphinxdoc] Error 255



sphinx (1.6.4-1) unstable; urgency=medium
...
  * dh_sphinxdoc: Turn warning about missing SOURCELINK_SUFFIX to an error.
...
 -- Dmitry Shachnev   Tue, 26 Sep 2017 17:47:54 +0300

Bug#706656: [3dprinter-general] Bug#706656: ITP: cura -- Controller for 3D printers

[Gregor Riepl]

Hi Petter,

sorry about the delay. I was waiting for a review from Bas (or another DD).
The package is also currently stuck at version 2.5.0, due to a lack of time on
my side, but I'll try to prepare and push an update ASAP.

The package is on mentors.debian.net, but you also need to get all the
dependencies if you want to build it yourself:
https://mentors.debian.net/packages/uploader/onitake%40gmail.com

> I need it for a project, and would love to get official Debian packages for
> it.  If a sponsor is needed, feel free to get in touch.  My sponsoring 
> preferences
> are available from http://www.hungry.com/~pere/debian-sponsoring.html >.

Thanks, I'll consider it.
But I'd really prefer another review of the package before releasing it into
the wild.

I could also use some help with common usage of Debian git.
My current build/release procedure for Cura is slightly complicated:
https://anonscm.debian.org/cgit/3dprinter/packages/cura.git/tree/debian/README.source
The same has to be repeated for all dependencies.

Regards,
Gregor

Bug#865762: What about stretch? (Was: Bug#865762 closed by Balint Reczey (Bug#865762: fixed in shadow 1:4.5-1))

[Baptiste Jonglez]

Hi,

On 27-09-17, Debian Bug Tracking System wrote:
>* New upstream version 4.5
>  - Fix buffer overflow if NULL line is present in db (CVE-2017-12424)
>(Closes: #756630)
>  - Make the sp_lstchg shadow field reproducible (Closes: #857803)
>  - Fix regression in useradd not loading defaults properly.
>(Closes: #865762)

Thanks for the update.  However, will shadow 4.5 get pushed to stretch?

If stretch is stuck with shadow 4.4, then the patch I supplied should be
applied to stretch to fix this issue.

Thanks,
Baptiste