Bug#883772: lintian: please don't map implimentation language to sections

[Guillem Jover]

Hi!

On Thu, 2017-12-07 at 09:17:43 -0400, David Bremner wrote:
> As summarized in 
> 
>https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802488
> 
> the programming-language sections are a mess. It's not clear why the
> user cares about the implimentation language when looking for a
> package, so encouraging maintainers to move packages from sections
> that relate to the use of a package (e.g. mail) to one based on the
> implimentation language (e.g. lisp), is actively destructive (albeit
> in a minor way).

Certainly, and that's what I've been following when filing my mass
override fixes to ftp-masters.

> The specific case that's annoying me is the 'elpa-*' -> section lisp
> mapping added in c85f00e3.  There's an argument that all emacs
> extensions belong in section "editors" (where i believe the vim
> extensions are). Or, if you think emacs as more of an application
> platform, then emacs based mail-readers belong with other mail
> readers, emacs based irc-clients belong with other irc clients, and so
> on. Even if we care about implimentation language (or more defensibly,
> grouping extensions together) forcing all elpa-* into section lisp
> doesn't help anything; the package name already carries more
> information than the section.

Right, that was my mistake, I assumed these were generic lisp modules,
just coming from an external module registry similar to CPAN, CTAN and
similar. If these are instead more like plugins than modules
(automatically depended on by other package) then indeed these do not
belong in the lisp section at all. I'll prepare a fix for this.

On Fri, 2018-01-12 at 21:47:06 -0400, David Bremner wrote:
> Chris Lamb  writes:
> >> the programming-language sections are a mess
> >
> > Whilst I don't necessarily disagree, I'm not sure what the next steps
> > for Lintian are here.
> >
> > Putting it another way, I see you linked #802488 but until that gets
> > some kind of resolution (or some change to Policy), what is there for
> > us to do..?

The organization of the archive has always been in the hands of
ftp-masters. Policy might need to be updated, perhaps to reflect
ftp-masters decisions here, not the other way around. It's worth
noting that the Section and Priority override used to be an essential
part of the NEW processing, which unfortunately I've got the feeling
it is not being done for a long time now at least for the Section field. :(

Some time ago I tried to discuss and clarify the Section organization
with ftp-masters, but there was unfortunately no much reaction, since
then I wrote a tool [O] to help me track and send mass override fixes
out of my own criteria, which seems to get applied w/o complain.

[O] 

> Let me turn that question around. In the absence of clear policy [1] of what
> belongs in the programming language sections, why should lintian
> recommend adding things to them? At best it's busywork for maintainers
> and ftp-masters, and at worst it's making things worse for our users [2].

TBH I think the distinction here is clear (at least to me), language-
specific sections should *only* contain things that are language specifc
modules that are automatically depended on, and language-specific
toolchains and similar. But nothing for which the language is just an
implementation detail.

On Sat, 2018-01-13 at 10:38:12 +0530, Chris Lamb wrote:
> > In case you consider the previous not constructive ;), what about
> > lowering the severity to "pedantic"?
> 
> Again, I share your opinion about the entire section thing, just that
> a bug against Lintian is the best forum for such a discussion :) Lets
> downgrade it from "W" to "I" at the very least:
> 
>   
> https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=07bc5dff9aa74e738a24b50b30a2dd8ea103ac27

I'd rather we fixed the actual problem here with elpa, instead of
lowering it from W to I. In addition to my mass overrides, I was happy
to see that we could slowly course-correct the Section degradation via
lintian, but lowering this, makes it more difficult. :(

Thanks,
Guillem

Bug#883986: Don't drop -frounding-math

[Joachim Reichel]

You shouldn't drop ${CGAL_CXX_FLAGS_INIT} completely. If you want to avoid the
troublesome flags, you should at least include -frounding-math, which is
strictly needed for CGAL.

  Joachim

Bug#886670: libcgal-dev: CGAL_CXX_FLAGS_INIT contains flags that shouldn't be there

[Joachim Reichel]

severity 886670 normal
unblock 883986 by 886670
tag 886670 upstream
forwarded 886670 https://github.com/CGAL/cgal/issues/2734
thanks

On 08.01.2018 20:35, Adrian Bunk wrote:
> While looking into fixing #883986 I ran into the following problem
> due to openscad using CGAL_CXX_FLAGS_INIT:
> 
> /usr/lib/x86_64-linux-gnu/cmake/CGAL/CGALConfig.cmake:
> set(CGAL_CXX_FLAGS_INIT   "-g -O2 
> -fdebug-prefix-map=/build/cgal-d6DBFP/cgal-4.11=. -fstack-protector-strong 
> -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 
> -frounding-math" )
> 
> The only flag that might be correct in this place is -frounding-math,
> in case that is required for using CGAL.
> 
> Exposing flags like -fdebug-prefix-map is simply wrong.
> 
> (For #883986 the problem is the -g, that is also wrong here.)

I agree and I have forwarded this as
https://github.com/CGAL/cgal/issues/2734

> The severity might seem inflated, but this should be fixed
> for fixing the RC #883986 FTBFS in openscad.

However, I disagree about the severity. Since there is a simple workaround I've
reset the severity to normal and removed the block relation.

  Joachim

Bug#887079: node-emoji-unicode-version --Get the unicode version for a given emoji name

[Suman]

Package: wnpp
Severity: wishlist
Owner: suman 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-emoji-unicode-version
  Version : 0.2.1
  Upstream Author : Eric Eastwood  
(http://ericeastwood.com/)
* URL : 
https://github.com/MadLittleMods/emoji-unicode-version#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Get the unicode version for a given emoji name
Useful for testing native unicode emoji support
.
Node.js is an event-based server-side JavaScript engine.

Praveen agreed to sponser this package.

Bug#856448: gdk-pixbuf: CVE-2017-6314: Infinite loop in io-tiff.c with large size

[Salvatore Bonaccorso]

Control: tags -1 + fixed-upstream patch

Fixed upstream via:

https://git.gnome.org/browse/gdk-pixbuf/commit/?id=1e513abdb55529f888233d3c96b27352d83aad5f

Regards,
Salvatore

Bug#883772: lintian: please don't map implimentation language to sections

[David Bremner]

Guillem Jover  writes:

> TBH I think the distinction here is clear (at least to me), language-
> specific sections should *only* contain things that are language specifc
> modules that are automatically depended on, and language-specific
> toolchains and similar. But nothing for which the language is just an
> implementation detail.

You classification seems plausible, and getting some ftp-master
documentation that reflected that would be a good start.

Unfortunately making distinction is not possible based on the package
name for elpa- packages.  Even making the distinction by hand is not so
easy. Consider the example of 'magit', which is an editor plugin that
probably belongs in either either "editors" or "version control" (or
realistically, both). On the other hand, it is a dependency of magithub,
and the elpa- naming is necessary for the dh_elpa tooling to work. I
think similar confusion exists in many other places in the
archive. `libapp-nopaste-perl` is in section perl, but its users don't
care that it's written in perl.

Unfortunately warnings with "certainty = possible" don't seem to be
interpreted as the lintian maintainers probably intended, as suggestions
requiring maintainer judgement. People just want to make their packages
"lintian clean".



signature.asc
Description: PGP signature

Bug#856445: gdk-pixbuf: CVE-2017-6313: Integer underflow in io-icns.c

[Salvatore Bonaccorso]

Control: tags -1 + fixed-upstream patch

Fixed upstream via:

https://git.gnome.org/browse/gdk-pixbuf/commit/?id=210b16399a492d05efb209615a143920b24251f4

Regards,
Salvatore

Bug#886919: Please enable system notify support

[Guido Günther]

Hi,
On Sat, Jan 13, 2018 at 01:36:06PM +0100, Julien Cristau wrote:
> On Thu, Jan 11, 2018 at 11:12:49 +0100, Guido Günther wrote:
> 
> > Package: weston
> > Version: 3.0.0-1
> > Severity: wishlist
> > Tags: patch
> > 
> > Hi,
> > possible patch attached.
> 
> You may want to explain more.  What are the benefits, costs, risks,
> anything else?

It's can be used when starting weston as a systemd unit. 

 - notify systemd about startup via sd_notify (READY=1)
 - notify systemd that it's still alive via WATCHDOG=1
 - notify systemd about shutdow using STOPPING=1

An example unit file is being prepared upsteam:


https://lists.freedesktop.org/archives/wayland-devel/2017-November/035973.html

Since we already link against libsystemd no new dependencies are
introduced and the module needs to be loaded explicitly so no risk for
running installations.
Cheers,
 -- Guido

Bug#887081: xl2tpd cannto connect to provider

[richman1000000]

Package: xl2tpd
Version: 1.3.10-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?
   - Neet to setup l2tp connection with my internet provider

   * What exactly did you do (or not do) that was effective (or ineffective)?
   - I've had this error from the beginning in syslog 
udp_xmit failed to 80.241.35.34:1701 with err=-1:Network is unreachable
I've searched solution to my problem in google and etc. I've tryed to 
updated xl2tp package to sid version, error still the sameb

PS. Sorry for my english.


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

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

Versions of packages xl2tpd depends on:
ii  libc6   2.24-11+deb9u1
ii  libpcap0.8  1.8.1-3
ii  lsb-base9.20161125
ii  ppp 2.4.7-1+4

xl2tpd recommends no packages.

xl2tpd suggests no packages.

-- Configuration Files:
/etc/xl2tpd/l2tp-secrets changed:
0013348000 *  Za123456

/etc/xl2tpd/xl2tpd.conf changed:
[global]
port = 1701
auth file = /etc/xl2tpd/xl2tp-secrets
access control = no
[lac beeline]
lns = l2tp.internet.beeline.kz
;lns = tp.internet.beeline.ru
redial = yes
redial timeout = 15
require chap = yes
require authentication = no
name = 0013348000
ppp debug = yes
pppoptfile = /etc/ppp/options.xl2tpd.corbina
require pap = no
autodial = yes
 tx bps=1

-- no debconf information

Bug#881871: stretch-pu: package bacula/7.4.4+dfsg-6

[Julien Cristau]

Control: tag -1 moreinfo

On Thu, Nov 16, 2017 at 00:02:29 +0100, Carsten Leonhardt wrote:

> 2) Bug #880529: When updating from jessie to stretch, the package
> "bacula-director-common" will be removed, but the postrm will stay
> around. Upon purging this package, postrm unconditionally removes the
> main bacula configuration file /etc/bacula/bacula-dir.conf, leaving
> bacula unusable. We fix this by introducing a transitional package that
> can then be safely removed.
> 
It sounds like this won't solve the issue for anyone who has already
upgraded but hasn't yet purged bacula-director-common.  Couldn't
bacula-director's postinst neuter the old postrm instead?

Cheers,
Julien

Bug#882158: stretch-pu: package glibc/2.24-11+deb9u2

[Julien Cristau]

Control: tag -1 confirmed

On Sat, Dec  9, 2017 at 14:22:45 +0100, Aurelien Jarno wrote:

> Unfortunately it didn't make in 9.3 due to the regression introduced wrt
> /etc/ld.so.nohwcap (see bug#883394). The issue is due to the conversion
> of libc6-i686 into a transitional package between jessie and stretch, and
> dropping the postinst and postrm script handling the removal of
> /etc/ld.so.nohwcap after the upgrade. The problem always existed in
> stretch, but the probability for it to happen has been greatly increased
> by the fix for #882272. The issue doesn't affect buster/sid as the
> transitional package has been removed.
> 
> I have fixed the issue in version 2.24-11+deb9u3 by reintroducing the
> postinst and postrm scripts in the transitional package. You will find
> below the corresponding patch.
> 
> Thanks for considering it for 9.4.
> 
Assuming that's been tested in all the various scenarios, please go
ahead.

Cheers,
Julien

Bug#855464: devscripts: [mk-origtargz] Fails to create tar if too many files excluded

[Ximin Luo]

Package: devscripts
Version: 2.17.12
Followup-For: Bug #855464

Dear Maintainer,

I've implemented a patch here:

https://anonscm.debian.org/cgit/collab-maint/devscripts.git/diff/?id=pu/mk-origtargz-argmax=master

it is not the most correct - ARG_MAX is measured in bytes, and it assumes that
16384 command-line arguments will fit within this - but it is simple and it
works for rustc. Perhaps the OP can test if it works for him too.

X

-- Package-specific info:

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

--- ~/.devscripts ---
export DEBSIGN_PROGRAM="gpg2"

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

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

Versions of packages devscripts depends on:
ii  dpkg-dev  1.19.0.4
ii  libc6 2.25-5
ii  libfile-homedir-perl  1.002-1
ii  perl  5.26.1-3
ii  python3   3.6.4-1
ii  sensible-utils0.0.11

Versions of packages devscripts recommends:
ii  apt 1.6~alpha6
ii  at  3.1.20-3.1
ii  curl7.57.0-1
ii  dctrl-tools 2.24-2+b1
ii  debian-keyring  2017.11.24
ii  dput-ng [dput]  1.15
ii  equivs  2.1.0
ii  fakeroot1.22-2
ii  file1:5.32-1
ii  gnupg   2.2.4-1
ii  gnupg2  2.2.4-1
ii  libdistro-info-perl 0.17
ii  libdpkg-perl1.19.0.4
ii  libencode-locale-perl   1.05-1
ii  libgit-wrapper-perl 0.047-1
ii  liblist-compare-perl0.53-1
ii  liblwp-protocol-https-perl  6.07-2
ii  libsoap-lite-perl   1.26-1
ii  liburi-perl 1.72-2
ii  libwww-perl 6.31-1
ii  licensecheck3.0.31-2
ii  lintian 2.5.67
ii  man-db  2.7.6.1-4
ii  patch   2.7.5-1+b2
ii  patchutils  0.3.4-2
ii  python3-apt 1.4.0~beta3+b1
ii  python3-debian  0.1.31
ii  python3-magic   1:5.32-1
ii  python3-requests2.18.4-1
ii  python3-unidiff 0.5.4-1
ii  python3-xdg 0.25-4
ii  strace  4.19-1
ii  unzip   6.0-21
ii  wdiff   1.2.2-2
ii  wget1.19.2-1
ii  xz-utils5.2.2-1.3

Versions of packages devscripts suggests:
ii  adequate  0.15.1
ii  autopkgtest   5.1
pn  bls-standalone
ii  bsd-mailx [mailx] 8.1.2-0.20160123cvs-4
ii  build-essential   12.4
pn  check-all-the-things  
pn  cvs-buildpackage  
pn  devscripts-el 
ii  diffoscope90
ii  disorderfs0.5.2-2
pn  dose-extra
pn  duck  
ii  faketime  0.9.6-7+b1
ii  gnuplot   5.2.2+dfsg1-2
ii  gnuplot-x11 [gnuplot] 5.2.2+dfsg1-2
ii  gpgv  2.2.4-1
ii  how-can-i-help15
ii  libauthen-sasl-perl   2.1600-1
ii  libfile-desktopentry-perl 0.22-1
pn  libnet-smtps-perl 
pn  libterm-size-perl 
ii  libtimedate-perl  2.3000-2
ii  libyaml-syck-perl 1.29-1+b3
ii  mozilla-devscripts0.47
ii  mutt  1.9.2-1
ii  openssh-client [ssh-client]   1:7.6p1-2
ii  piuparts  0.83
ii  postgresql-client-10 [postgresql-client]  10.1-2
ii  quilt 0.63-8.2
pn  ratt  
ii  reprotest 0.7.7
pn  svn-buildpackage  
pn  w3m   

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/bin/mk-origtargz (from devscripts package)

Bug#882815: stretch-pu: package exam/0.10.5-2~deb9u1

[Julien Cristau]

Control: tag -1 moreinfo

On Mon, Nov 27, 2017 at 01:43:26 +0100, Andreas Beckmann wrote:

> Package: release.debian.org
> Severity: normal
> Tags: stretch
> User: release.debian@packages.debian.org
> Usertags: pu
> 
> Fixing up the python dependencies.
> 
> The debdiff is a bit noisy due to the renaming of the patches ...
> but therefore it's just a rebuild of the package from sid.
> 
Any reason to not just fix the bug and avoid the patch renaming?

Cheers,
Julien

Bug#882813: stretch-pu: package python-pyperclip/1.5.27-3~deb9u1

[Julien Cristau]

Control: tag -1 confirmed

On Mon, Nov 27, 2017 at 01:14:27 +0100, Andreas Beckmann wrote:

> python3-pyperclip misses a proper python3 dependency.
> 
> $ debdiff python3-pyperclip_1.5.27-2_all.deb 
> python3-pyperclip_1.5.27-3~deb9u1_all.deb
> File lists identical (after any substitutions)
> 
> Control files: lines which differ (wdiff format)
> 
> Depends: {+python3:any (>= 3.4~),+} xclip | xsel | python3-pyqt4
> Version: [-1.5.27-2-] {+1.5.27-3~deb9u1+}
> 
Go ahead, thanks.

Cheers,
Julien

Bug#882434: stretch-pu: package ust/2.9.0-2+deb9u1

[Julien Cristau]

Control: tag -1 confirmed

On Wed, Nov 22, 2017 at 15:05:52 -0500, Michael Jeanson wrote:

> The attached diff fixes a bug that makes the python3-lttngust package
> completely broken unless the corresponding liblttng-ust-dev is also
> installed.
> 
> The original python code load the library using ctypes without specifying a
> soname. This fix was reported and merged upstream.
> 
Anything using ctypes for library bindings should be taken out back and
shot.

However, this seems like an improvement over the previous
even-more-buggy state, so go ahead.

Cheers,
Julien

Bug#883772: lintian: please don't map implementation language to sections

[Chris Lamb]

[Altering Subject to match updated bug title]

Hi Guillem & David,

> I'd rather we fixed the actual problem here with elpa, instead of
> lowering it from W to I. In addition to my mass overrides, I was happy
> to see that we could slowly course-correct the Section degradation via
> lintian, but lowering this, makes it more difficult. :(

With my Lintian hat on here, what I am 100% trying to avoid here is either
encouraging folks to blindly following it in error (and possibly tediously
asking them to change later) as well as being overly nagging in general.

Once we have nailed the section mapping "upstream", let's 100%, definitely
bump this back up. Perhaps even higher. In the meantime, I really want to
avoid harmful false positives (of sorts) as maintainers ignoring Lintian
undermines the quality of the entire Debian archive in areas outside of
sections.

> that's what I've been following when filing my mass override
> fixes to ftp-masters.

Thanks for sending these!


Best wishes,

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

Bug#886986: please remove bump-fasl-loader-version.patch

[Sébastien Villemot]

On Sat, Jan 13, 2018 at 01:55:58PM +0900, Norbert Preining wrote:

> > I wonder if this can properly be achieved through dpkg triggers.
> 
> Yes it can ;-)
> 
> > That would be based on a specific dpkg trigger (e.g. xindy-buildmem).
> 
> No, it would be a clisp trigger. clisp would look for some place where 
> new files are dropped, and rebuilds mems. If a new version of clisp is
> uploaded then all mems are rebuilt.
> 
> I have done that for tex-common and all the tex-formats:
> - tex-common shows interest (dpkg parlance) in a certain directory
> - packages shipping tex formats drop a certain file there
> - if that occurred, triggers are called and .fmt files are rebuilt
> - if tex-common is updated, all formats are rebuilt
> - (irrelevant for clisp) if one of the engines is updated, then all
>   the formats based on this engine (like tex, xetex, luatex etc) are
>   rebuilt.
> 
> Similar things happen with python (compiling py to pyc), elisp files (el
> to elc) etc. The main "compiler" is triggered when depending packages
> are installed.
> 
> If this is the plan I can help setting up such a layout in clisp.

Thanks to Bruno's cooperation, the plan seems rather to generate a proper
ABI-like number (in this case the .mem hash code), which will allow us to solve
this issue with minimal changes to both xindy and clisp packages.

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


signature.asc
Description: PGP signature

Bug#882822: stretch-pu: package python-hkdf/0.0.3-3~deb9u1

[Julien Cristau]

Control: tag -1 confirmed

On Mon, Nov 27, 2017 at 02:22:54 +0100, Andreas Beckmann wrote:

> Let's fix the python3 dependencies. #867433
> (And by just rebuilding the package from sid,
> we get some metadata updates as well.)
> 
Please go ahead.

Cheers,
Julien

Bug#886986: please remove bump-fasl-loader-version.patch

[Agustin Martin]

2018-01-12 20:22 GMT+01:00 Agustin Martin :
> I wonder if this can properly be achieved through dpkg triggers.
>
> That would be based on a specific dpkg trigger (e.g. xindy-buildmem).
> The result should be that xindy.mem is removed on prerm and rebuilt
> after fas contents on package postinst any time clisp or xindy are changed.
> It should be located under /var/lib/xindy and xindy.in modified for that.
>
> This may have the additional advantage of making xindy an arch:all package.

Forgot about tex2xindy, a binary file :-(

(Replying only to the Debian part to avoid extra noise on Bruno and
Sam. This is too Debian specific)

-- 
Agustin

Bug#883483: stretch-pu: package flatpak/0.8.8-0+deb9u1

[Simon McVittie]

On Sat, 13 Jan 2018 at 17:51:04 +0100, Julien Cristau wrote:
> On Mon, Dec  4, 2017 at 15:45:40 +, Simon McVittie wrote:
> > The upstream maintainer of Flatpak has made a 0.8.8 release
> > 
> Assuming this has been tested on stretch, please go ahead.

Thanks, uploaded.

smcv

Bug#886445: needrestart: detect need to reboot due to Intel microcode updates

[Henrique de Moraes Holschuh]

On Sat, 13 Jan 2018, Thomas Liske wrote:
> # iucode_tool -Sl /lib/firmware/intel-ucode/

It would have to be:

iucode_tool -Sl /lib/firmware/intel-ucode /usr/share/misc/intel-microcode*

and that could still miss something.


Maybe it would be best to look inside the initrds directly, too...

iucode_tool -Sl -tb /lib/firmware/intel-ucode \
-ta /usr/share/misc/intel-microcode* \
-tr /boot/initrd*


anything you do will have *some* failure mode, some people load
microcode the Arch way for example... others might have appended it to
the kernel image...

> I wonder if it is still required to look at the revision value for each
> CPU/Core (grep microcode /proc/cpuinfo). For single socket systems each

To be safe, you'd have to, yes.

> core should report the same version. I do not now if it would possible
> to run different microcode releases on multi socket systems.

There is something called "mixed stepping" systems, where the steppings
of the processors are not exactly the same, and thus neither is the
microcode.  Family and model of all processors must be the same.

So far, there no mixed-model systems.

BTW, iucode_tool had a few bugs on this area, they have been fixed since
iucode-tool 1.5.2-1.

> For the check in needrestart it should be enough to compare the current
> running microcode signature with the latest available one. This would
> also handle outdated initrd images gracefuly.

Well, it would not be perfect.  But maybe it would be good enough.

-- 
  Henrique Holschuh

Bug#886445: needrestart: detect need to reboot due to Intel microcode updates

[Henrique de Moraes Holschuh]

On Sat, 13 Jan 2018, Paul Wise wrote:
> It should be enough, but it would be better to handle all cases IMO.
> I have no idea if iucode-tool handles systems with multiple sockets,
> so I am CCing Debian's Intel/AMD microcode maintainer.

Current versions of iucode_tool will include microcode for every
stepping of whatever processor it detects using cpuid.

This errs in the side of caution (it may include more steppings than
strictly required), because the allowed-stepping-mixing rules vary with
processor model(!).

> > For the check in needrestart it should be enough to compare the current
> > running microcode signature with the latest available one. This would
> > also handle outdated initrd images gracefuly.
> 
> I think on Debian at least, outdated microcode in the initrd could only
> be intentional on the part of the sysadmin.

Who knows... people do strange things.

-- 
  Henrique Holschuh

Bug#884108: Update info

[Philipp Kern]

On 12/12/2017 12:51 PM, roma1390 wrote:
> more info about regression from version 1.0.92 to 1.0.93
> 
> tried Debian versions: 6-10: works OK. Not affected
> 
> affected Ubuntu versions:
> 10.04 - Lucid Lynx
> 10.10 - Maverick Meerkat
> 11.04 - Natty Narwhal
> 11.10 - Oneiric Ocelot

Unfortunately these are all out of support and there isn't a benefit to
provide bootstrapping support for ancient Ubuntu derivatives in Debian.

Thanks for documenting a workaround. FWIW, the right fix would be to
just add lucid to the list of distributions immediately before the *)
part where you commented out the problematic line. In that case the
variable set and setup_merged_usr would simply be skipped.

Kind regards
Philipp Kern

Bug#880663: marked as done (Sometimes crashes on resuming from suspend)

[Simon McVittie]

Ari Pollak wrote:
> After upgrading from 3.22 to 3.26, gnome-shell under wayland has started
> crashing with some regularity when my laptop resumes from suspend, about once
> every day or two (I suspend and resume much more often than that).

After upgrading to gnome-shell/3.26.2-3 and gjs/1.50.2-3 you should
find that whenever you would previously have experienced a crash (and
perhaps a lot more often), you now get a JavaScript stack trace in the
systemd journal. It'll look something like the one I reported in
. Please report
these stack traces as new bug reports, and make sure to include details
of any Shell extensions that you have enabled, either from
gnome-shell-extensions ("GNOME Classic") or separate packages.

> This is the
> backtrace I got from the coredump; it doesn't look particularly useful to me,
> but maybe it does to you.

Unfortunately this is, as you suspected, not very useful (it basically
says "some unknown JavaScript set the text property of an invalid
StLabel"), but the JavaScript-level stack traces should hopefully tell
us *which* JavaScript in enough detail to find the root cause.

Thanks,
smcv

Bug#883483: stretch-pu: package flatpak/0.8.8-0+deb9u1

[Julien Cristau]

Control: tag -1 confirmed

On Mon, Dec  4, 2017 at 15:45:40 +, Simon McVittie wrote:

> Package: release.debian.org
> Severity: normal
> Tags: stretch
> User: release.debian@packages.debian.org
> Usertags: pu
> 
> The upstream maintainer of Flatpak has made a 0.8.8 release, which
> collects the patches we apply to 0.8.7 in stretch, together with some
> more fixes backported from the 0.10.x branch. I would like to update
> stretch to this release.
> 
Assuming this has been tested on stretch, please go ahead.

Cheers,
Julien

Bug#882827: stretch-pu: package python-mimeparse/0.1.4-3.1~deb9u1

[Julien Cristau]

Control: tag -1 = confirmed stretch

On Sat, Jan 13, 2018 at 17:44:10 +0100, Julien Cristau wrote:

> Control: tag -1 moreinfo
> 
Woops wrong tag.

Cheers,
Julien

Bug#883854: stretch-pu: package mate-polkit/1.16.0-2+deb9u1

[Julien Cristau]

Control: tag -1 moreinfo

On Fri, Dec  8, 2017 at 12:17:33 +0100, Mike Gabriel wrote:

> Whenever mate-polkit asks for the user's password to change the user
> context via PolicyKit, an icon is shown in the system tray.
> 
> In Debian stretch, this icon is broken. It should show dialog-password.
> The attached .debdiff fixes that.
> 
> Please consider an ACK to get this change into the next point release of
> Debian 9.
> 
The bug severity is "minor".  I'm not convinced that qualifies.

Cheers,
Julien

Bug#884452: stretch-pu: package python-evtx/0.5.3b-3+deb9u1

[Julien Cristau]

Control: tag -1 confirmed

On Fri, Dec 15, 2017 at 11:28:21 +0100, Hilko Bengen wrote:

> Package: release.debian.org
> Severity: normal
> Tags: stretch
> User: release.debian@packages.debian.org
> Usertags: pu
> 
> Dear release team,
> 
> please consider allowing an update to the python-evtx package in
> stretch. It fixes Python3 dependencies (RC bug #867428).
> 
Please go ahead.

Cheers,
Julien

Bug#882827: stretch-pu: package python-mimeparse/0.1.4-3.1~deb9u1

[Andreas Beckmann]

On 2018-01-13 17:44, Julien Cristau wrote:
>> Control files: lines which differ (wdiff format)
>> 
>> {+Depends: python3:any (>= 3.3.2-2~)+}

> Are these things flagged by lintian nowadays?

Nope :-(
So I filed #887083


Andreas

Bug#884451: stretch-pu: package libvhdi/20160424-1+deb9u1

[Julien Cristau]

Control: tag -1 confirmed

On Fri, Dec 15, 2017 at 11:28:16 +0100, Hilko Bengen wrote:

> Package: release.debian.org
> Severity: normal
> Tags: stretch
> User: release.debian@packages.debian.org
> Usertags: pu
> 
> Dear release team,
> 
> please consider allowing an update to the libvhi package in stretch. It
> fixes missing Python3 dependencies (RC bug #867409).
> 
Looks ok, please go ahead.

Cheers,
Julien

Bug#884111: stretch-pu: package vdirsyncer/0.14.1-1

[Julien Cristau]

Control: tag -1 confirmed

On Mon, Dec 11, 2017 at 15:53:28 +0100, Filip Pytloun wrote:

> Package: release.debian.org
> Severity: normal
> Tags: stretch
> User: release.debian@packages.debian.org
> Usertags: pu
> 
> Hello,
> 
> I would like to upload vdirsyncer 0.14.1-2 containing fix for bug #883299
> [1][2][3]. This fixes critical issue that's making vdirsyncer 0.14.1 unusable 
> for
> some users as it's unable to sync Google contacts.
> 
The version number should be 0.14.1-1+deb9u1.  With that fixed, and
assuming the updated package is tested in stretch, please go ahead.

Cheers,
Julien

Bug#883948: [pkg-apparmor] Bug#883948: apparmor: xdg-user-dirs should have localized directory names

[Vincas Dargis]

Tried OpenSUSE Tumbleweed, and no, localized Downloads folder was not allowed 
when using `abstractions/user-download`.

Bug#877593: Acknowledgement (stretch-pu: package ocfs2-tools/1.8.4-4+deb9u1)

[Valentin Vidic]

On Sat, Jan 13, 2018 at 05:20:06PM +0100, Julien Cristau wrote:
> I'm worried about the risk of regressions for users who already worked
> around the bug or otherwise changed the links, e.g. to disable those
> services.

The updated postinst checks if the service is still enabled in
rcS and only than does the update so it should only make changes
for users with the default installation.

-- 
Valentin

Bug#887086: wesnoth-1.13: please provide update → 13.10

[H . -Dirk Schmitt]

Package: wesnoth-1.13
Severity: wishlist

Dear Maintainer,

please provide an update to 13.10 (or newer).

Thanks in advance,

H.-Dirk Schmitt

Bug#883948: [pkg-apparmor] Bug#883948: apparmor: xdg-user-dirs should have localized directory names

[Vincas Dargis]

Ubuntu does not handle handle localized directories too:

```
vincas@vincas-ubuntu1804:~$ foo ~/Atsiuntimai/fake.download
foo: /home/vincas/Atsiuntimai/fake.download: Permission denied
vincas@vincas-ubuntu1804:~$ cat /etc/apparmor.d/usr.local.bin.foo
#include 

@{foo_executable} = /usr/local/bin/foo

profile @{foo_executable} {
#include 
#include 

@{foo_executable} r,
}
```

Where `foo` is simply a copy of `/bin/cat`.

It works after I add:

`@{XDG_DOWNLOAD_DIR}+=Atsiuntimai`

into

`/etc/apparmor.d/tunables/xdg-user-dirs.d/site.local`.

as expected.

Bug#886852: NVidia driver : upgrade to version 384.111

[Luca Boccassi]

On Sat, 2018-01-13 at 14:59 +0100, Andreas Beckmann wrote:
> On 2018-01-11 23:26, Luca Boccassi wrote:
> > The new meta packages for switching over are handy, unfortunately
> > apt
> > chokes on them - aptitude is able to figure it out though.
> > 
> > I suspect it's again due to multiarch - seems to be a recurring
> > problem
> > with apt. So don't think there's anything we can do.
> 
> Do you have more details? What does not work with apt?

It cannot find a resolution (with hints it gets to a point where it
present removing half of the GUI packages as a solution) - if you
remember we had the same problem a month ago or so, and it looked like
it was due to having both amd64 and i386 installed - as with only one
arch (in a chroot) it couldn't be reproduced:

$ dpkg -l | grep nvidia-driver
ii  nvidia-driver 384.111-1~bpo9+1  
  amd64NVIDIA metapackage
ii  nvidia-driver-bin 384.111-1~bpo9+1  
  amd64NVIDIA driver support binaries
ii  nvidia-driver-libs:amd64  384.111-1~bpo9+1  
  amd64NVIDIA metapackage (OpenGL/GLX/EGL/GLES 
libraries)
ii  nvidia-driver-libs:i386   384.111-1~bpo9+1  
  i386 NVIDIA metapackage (OpenGL/GLX/EGL/GLES 
libraries)
ii  nvidia-driver-libs-i386:i386  384.111-1~bpo9+1  
  i386 NVIDIA metapackage (OpenGL/GLX/EGL/GLES 
32-bit libraries)
$ sudo apt install -t stretch-backports nvidia-driver-libs-nonglvnd 
nvidia-driver-libs-nonglvnd-i386
[sudo] password for luca: 
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libgl1 : Depends: libglx0 (= 1.0.0-1) but it is not going to be installed
 libpurple0 : Depends: libfarstream-0.2-5 (>= 0.2.7) but it is not going to be 
installed
  Recommends: libpurple-bin but it is not going to be installed
 nvidia-driver-libs-nonglvnd : Depends: libgl1-nvidia-glx (= 384.111-1~bpo9+1) 
but it is not going to be installed
   Depends: libegl1-nvidia (= 384.111-1~bpo9+1) but 
it is not going to be installed
   Recommends: libglx-nvidia0 (= 384.111-1~bpo9+1) 
but it is not going to be installed
   Recommends: libgles-nvidia1 (= 384.111-1~bpo9+1) 
but it is not going to be installed
   Recommends: libgles-nvidia2 (= 384.111-1~bpo9+1) 
but it is not going to be installed
   Recommends: libnvidia-cfg1 (= 384.111-1~bpo9+1) 
but it is not going to be installed
   Recommends: nvidia-egl-wayland-icd (= 
384.111-1~bpo9+1) but it is not going to be installed
   Recommends: nvidia-nonglvnd-vulkan-icd (= 
384.111-1~bpo9+1) but it is not going to be installed
 nvidia-driver-libs-nonglvnd-i386:i386 : Depends: 
nvidia-driver-libs-nonglvnd:i386 but it is not going to be installed
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by 
held packages.

$ sudo aptitude install -t stretch-backports nvidia-driver-libs-nonglvnd 
nvidia-driver-libs-nonglvnd-i386
Note: selecting "nvidia-driver-libs-nonglvnd-i386:i386" instead of the virtual 
package "nvidia-driver-libs-nonglvnd-i386"
The following NEW packages will be installed:
  libegl1-nvidia{a} libegl1-nvidia:i386{a} libgl1-nvidia-glx{ab} 
libgl1-nvidia-glx:i386{ab} libgles-nvidia1{a} 
  libgles-nvidia1:i386{a} libgles1-glvnd-nvidia{a} 
libgles1-glvnd-nvidia:i386{a} nvidia-driver-libs-nonglvnd{b} 
  nvidia-driver-libs-nonglvnd:i386{ab} nvidia-driver-libs-nonglvnd-i386:i386 
nvidia-nonglvnd-vulkan-common{ab} 
  nvidia-nonglvnd-vulkan-icd{ab} nvidia-nonglvnd-vulkan-icd:i386{ab} 
0 packages upgraded, 14 newly installed, 0 to remove and 169 not upgraded.
Need to get 3,382 kB of archives. After unpacking 5,976 kB will be used.
The following packages have unmet dependencies:
 nvidia-vulkan-icd : Conflicts: nvidia-nonglvnd-vulkan-icd but 384.111-1~bpo9+1 
is to be installed
 Conflicts: nvidia-nonglvnd-vulkan-icd:i386 but 
384.111-1~bpo9+1 is to be installed
 nvidia-vulkan-icd:i386 : Conflicts: nvidia-nonglvnd-vulkan-icd but 
384.111-1~bpo9+1 is to be installed
  Conflicts: nvidia-nonglvnd-vulkan-icd:i386 but 
384.111-1~bpo9+1 is to be installed
 nvidia-nonglvnd-vulkan-icd : Conflicts: nvidia-vulkan-icd but 384.111-1~bpo9+1 
is installed
 

Bug#856444: gdk-pixbuf: CVE-2017-6312: Possible out-of-bounds read

[Salvatore Bonaccorso]

Control: tags -1 + fixed-upstream patch

Fixed upstream via:

https://git.gnome.org/browse/gdk-pixbuf/commit/?id=dec9ca22d70c0f0d4492333b4e8147afb038afd2

Regards,
Salvatore

Bug#887080: ITP: node-pinkyswear -- very small implementation of the Promises/A+ specification

[Philip Rinn]

Package: wnpp
Severity: wishlist
Owner: Philip Rinn 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-pinkyswear
  Version : 2.2.3
  Upstream Author : Tim Jansen 
* URL : https://github.com/timjansen/PinkySwear.js
* License : public-domain
  Programming Lang: JavaScript
  Description : very small implementation of the Promises/A+ specification

 This Node.js package is a minimalist Promises/A+ implementation for embedding.
 You can use it as a lightweight dependency for your library if you need to
 return a promise. It is not intended as a stand-alone library for more complex
 applications, and therefore does not support assimilation of other promises.
 .
 Node.js is an event-based server-side JavaScript engine.


This package is a dependency of node-shiny-server-client (ITP will follow) which
is a dependency of shiny-server (will be maintained by Debian-science).

I intend to maintain the package under the Debian JavaScript maintainers or the
Debian Science umbrella. I'll need a sponsor to upload the package.

Packaging can be found (until I know which team I'll use) at

https://salsa.debian.org/rinni-guest/node-pinkyswear

Bug#877374: stretch-pu: shadow 1:4.4-4.1+deb9u1

[Julien Cristau]

Control: tag -1 moreinfo

On Sun, Oct  1, 2017 at 08:04:48 +0200, Balint Reczey wrote:

>  shadow (1:4.4-4.1+deb9u1) stretch; urgency=medium
>  .
>    * Revert adding pts/0 and pts/1 to securetty.
>      Adding pts/* defeats the purpose of securetty. Let containers add it if
>      needed as described in #830255.

I'm not sure I'm comfortable with the regression risk for users from
this one.  How long have those been listed in securetty?

>    * Fix buffer overflow if NULL line is present in db (CVE-2017-12424)
>      (Closes: #756630)
> 
I guess that's ok.

Cheers,
Julien

Bug#882826: stretch-pu: package python-hacking/0.11.0-2.1~deb9u1

[Julien Cristau]

Control: tag -1 confirmed

On Mon, Nov 27, 2017 at 03:51:31 +0100, Andreas Beckmann wrote:

> Package: release.debian.org
> Severity: normal
> Tags: stretch
> User: release.debian@packages.debian.org
> Usertags: pu
> 
> Let's fix the python3 dependencies. #867431
> 
> $ debdiff python3-hacking_0.11.0-2_all.deb 
> python3-hacking_0.11.0-2.1~deb9u1_all.deb
> File lists identical (after any substitutions)
> 
> Control files: lines which differ (wdiff format)
> 
> Depends: [-pyflakes,-] {+pyflakes3,+} python3-flake8 (>= 3.0.0), python3-pbr 
> (>= 1.8), python3-pep8 (>= 1.5.7), python3-six (>= [-1.9.0)-] {+1.9.0), 
> flake8, python3-mccabe, python3-pycodestyle, python3-pyflakes, python3:any 
> (>= 3.3.2-2~)+}
> Version: [-0.11.0-2-] {+0.11.0-2.1~deb9u1+}
> 
OK, please go ahead.

Cheers,
Julien

Bug#882827: stretch-pu: package python-mimeparse/0.1.4-3.1~deb9u1

[Julien Cristau]

Control: tag -1 moreinfo

On Mon, Nov 27, 2017 at 04:05:26 +0100, Andreas Beckmann wrote:

> Package: release.debian.org
> Severity: normal
> Tags: stretch
> User: release.debian@packages.debian.org
> Usertags: pu
> 
> Let's fix the python3 dependencies. #867439
> 
> $ debdiff python3-mimeparse_0.1.4-3_all.deb 
> python3-mimeparse_0.1.4-3.1~deb9u1_all.deb
> File lists identical (after any substitutions)
> 
> Control files: lines which differ (wdiff format)
> 
> {+Depends: python3:any (>= 3.3.2-2~)+}
> Installed-Size: [-24-] {+25+}
> Version: [-0.1.4-3-] {+0.1.4-3.1~deb9u1+}
> 
Go ahead.

Are these things flagged by lintian nowadays?

Cheers,
Julien

Bug#883959: stretch-pu: package cappuccino/0.5.1-8~deb9u1

[Julien Cristau]

Control: tag -1 moreinfo

On Sat, Dec  9, 2017 at 20:52:45 +0100, Andreas Beckmann wrote:

> Package: release.debian.org
> Severity: normal
> Tags: stretch
> User: release.debian@packages.debian.org
> Usertags: pu
> 
> Let's fix the missing dependency on gir1.2-gtk-3.0, #879848, by
> rebuilding the package from sid. This also adds a 
>   /usr/games/cappuccino -> ../bin/cappuccino
> symlink.
> 
The latter doesn't seem necessary, and even less so in stable.

Cheers,
Julien

Bug#883952: stretch-pu: package activity-log-manager/0.8.0-1.2~deb9u1

[Julien Cristau]

Control: tag -1 confirmed

On Sat, Dec  9, 2017 at 20:23:18 +0100, Andreas Beckmann wrote:

> Package: release.debian.org
> Severity: normal
> Tags: stretch
> User: release.debian@packages.debian.org
> Usertags: pu
> 
> Let's fix the missing dependency on python-zeitgeist, #881438, by
> rebuilding the corresponding fixed package from sid.
> 
Go ahead.

Cheers,
Julien

Bug#884483: stretch-pu: package xrdp/0.9.1-9+deb9u1

[Julien Cristau]

Control: tag -1 confirmed

On Fri, Dec 15, 2017 at 19:41:29 +0100, Dominik George wrote:

> Package: release.debian.org
> Severity: normal
> Tags: stretch
> User: release.debian@packages.debian.org
> Usertags: pu
> 
> Hi,
> 
> I'd like to update xrdp in stretch for two important bugs:
> 
>  1. #882463, CVE-2017-16927: Local DoS
> Security team says it's not critical enough for stretch-security and I 
> should instead
> target stretch-pu (although I disagree).
> 
>  2. #884453, High CPU load in ssl_tls_accept
> Remote users could use up quite a lot or all system resources by keeping 
> TLS contexts
> in a certain state.
> 
Looks ok, please go ahead.

Cheers,
Julien

Bug#887083: lintian: does not report missing Depends: python3:any on python3-mimeparse_0.1.4-3_all.deb

[Chris Lamb]

Hi Andreas,

> the package is missing the python3 dependency, see #867439
> 
> $ less python3-mimeparse_0.1.4-3_all.deb
> python3-mimeparse_0.1.4-3_all.deb:
>  new Debian package, version 2.0.
> [...]
>  Package: python3-mimeparse
>  Source: python-mimeparse
>  Version: 0.1.4-3
>  Architecture: all
>  Maintainer: Mathias Ertl 
>  Installed-Size: 24
>  Section: python
>  Priority: optional
>  Homepage: https://pypi.python.org/pypi/python-mimeparse
>  Description: Parse mime-types and quality parameters - python 3.x

(Note that the source package would have triggered mismatched-python-substvar.)


Regards,

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

Bug#887017: apt: French debconf templates translation

[David Kalnischkies]

Hi,

On Fri, Jan 12, 2018 at 04:27:21PM +0100, Julien Patriarca wrote:
> Please find attached the french debconf templates translation, proofread by 
> the
> debian-l10n-french mailing list contributors.

Thanks a lot for the update of the *program* translation! :)


1.6~alpha6 has a small additional string:

| #: methods/connect.cc
| #, fuzzy, c-format
| #| msgid "Connecting to %s (%s)"
| msgid "Connected to %s (%s)"
| msgstr "Connexion à %s (%s)"

(yes, there is now a "Connecting" and a "Connected" msg)


Could you perhaps tell us what to write there?
I will merge it into the po file then (as I have to fix two more
needless fuzzies anyhow which slipped into ~alpha6).


Thanks again & Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#887090: ITP: r-cran-cli -- GNU R helpers for developing command line interfaces

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-cli
  Version : 1.0.0
  Upstream Author : Gábor Csárdi 
* URL : https://cran.r-project.org/package=cli
* License : MIT
  Programming Lang: GNU R
  Description : GNU R helpers for developing command line interfaces
 A suite of tools designed to build attractive command line
 interfaces ('CLIs'). Includes tools for drawing rules, boxes, trees, and
 'Unicode' symbols with 'ASCII' alternatives.


Remark: This package is needed to upgrade r-cran-tibble to the new
 upstream version 1.4.1.  It will be maintained by the r-pkg-team at
 https://salsa.debian.org/r-pkg-team/r-cran-cli.git

Bug#886881: dput-ng: Please provide a hook to catch NMU without explicit --delayed parameter

[Mattia Rizzolo]

On Wed, Jan 10, 2018 at 10:39:00PM +0100, Niels Thykier wrote:
> (ideally overridable in the
> off-hand case that I actually need to do a zero-delay NMU - which I
> think is different from --delayed 0).

It may be different in practice, but for all regular purpose it's the
same, IME it simply delays acceptances of some extra minutes (maybe an
extra unchecked run?  Or anyway, that kind of time that doesn't really
matter).

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#884542: [pkg-go] Bug#884542: prometheus-mysqld-exporter FTBFS: FAIL: TestScrapeInnodbMetrics

[Martín Ferrari]

Status update: still waiting for upstream's fix.

On 18/12/17 04:55, Martín Ferrari wrote:
> Adrian,
> 
> Thanks for the report. I presume this error is due to the change in the
> Prometheus' common library. I am already preparing a new upstream
> release, but that is waiting on an upstream bug:
> https://github.com/prometheus/mysqld_exporter/issues/251
> 
> 
> On 16/12/17 12:03, Adrian Bunk wrote:
>> Source: prometheus-mysqld-exporter
>> Version: 0.9.0+ds-3
>> Severity: serious
>> Tags: buster sid
>>
>> Some recent change in unstable makes prometheus-mysqld-exporter FTBFS:
>>
>> https://tests.reproducible-builds.org/debian/history/prometheus-mysqld-exporter.html
>> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/prometheus-mysqld-exporter.html
>>
>> ...
>> === RUN   TestScrapeInnodbMetrics
>> --- FAIL: TestScrapeInnodbMetrics (0.00s)
>>  info_schema_innodb_metrics_test.go:17: no such flag -log.level
> 
> 
> 


-- 
Martín Ferrari (Tincho)

Bug#641264: debian-installer: cannot install to already encrypted partitions

[Matthew Munro]

Package: debian-installer
Version: debian-9.3.0
Severity: normal

On Thu, 23 Feb 2012 21:20:33 +0100 Johan Vervloet  
wrote:
> device-mapper: reload ioctl failed: Invalid argument
> Failed to setup dm-crypt key mapping for device /dev/sda6.
> Check that kernel supports aes-xts-plain64 cipher (check syslog for more 
> info).

I was led to this bug report by similar output in speech synthesis + expert 
mode, while attempting to select the correct components to achieve a cryptsetup.

My route to success was to load the rescue component and then execute ‘depmod 
-a’ in a shell before the cryptsetup command. (Message #5 taught me the depmod 
bit; thank you.)

Bug#788496: Bug#887055: git-buildpackage: Please word-wrap generated changelog lines

[Guido Günther]

Hi,
On Sat, Jan 13, 2018 at 07:06:31PM +0530, Chris Lamb wrote:
> Hi Guido,
> 
> > Please check the above report on how this can be achieved today. I
> > prefer keeping the original git formatting by default.
> 
> Adding #788496 to cc for this purpose, can you elaborate why? I'm not
> sure I follow the rationale, especially when Lintian will merrily warn
> about debian-changelog-line-too-long… :)

Proper line wrapping needs proper reformatting of the whole
message. E.g. I want lists (starting with '-' or '*') to be preserved
(so line wrapping also involves indenting the wrapped line
correctly). If text is inside a paragraph the next line needs to be
joined with the previous line, etc. etc. It's complicated to get this
right so that everybody is happy. Text editors are far better at
this. If somebody comes up with a clever formatter I might reconsider
but just wrapping the line doesn't cut it in my opinion.

Cheers,
 -- Guido


> 
> > control: forcemerge 788496 -1
> 
> (Apologies for that; must have been failing at search!)
> 
> 
> Best wishes,
> 
> -- 
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-
> 

Bug#887082: gnome-shell: Object (Clutter.Clone|Shell.GenericContainer) has been already finalized. Impossible to get any property from it [ui/tweener.js:73, ui/tweener.js:80]

[Simon McVittie]

Package: gnome-shell
Version: 3.26.2-3
Severity: normal

 Introduction 

Versions of gnome-shell prior to 3.26.2-3 have some issues where an
invalid pointer to a destroyed object gets used, for example #881301.
This affects some users more than others, depending on use patterns.
In 3.26.2-3 I've made gnome-shell depend on a version of gjs where this
situation is handled a bit more gracefully, with warnings logged to the
systemd journal when it happens. This is still a bug, but it's a less
serious bug than crashing the Shell.

If other gnome-shell users see warnings similar to what I've quoted in
this bug report, but with a different stack trace, please report each
different stack trace as a *separate* bug report, otherwise we will
get hopelessly confused. Please make sure to report which extensions,
if any, you have enabled.

These bugs can usually be fixed by disconnecting from signals when an
object emits the destroy signal, similar to this upstream issue report
and fix in the pomodoro extension:
https://github.com/codito/gnome-pomodoro/issues/320
Depending where the root cause is, it might require changes to
gnome-shell itself, or changes to an extension.

 Bug report 

I get matching stack traces for different objects in both the gdm
greeter, and the gnome-shell running as me. The gdm greeter never has any
extensions enabled. My gnome-shell currently has the caffeine extension
and no others.

% pgrep gnome-shell|xargs ps u
USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
Debian-+  2523  0.4  0.9 3228224 148576 tty1   Sl+  15:48   0:04 
/usr/bin/gnome-shell
smcv  2883  4.3  1.1 3499568 182360 tty2   Sl+  15:48   0:49 
/usr/bin/gnome-shell
smcv  2939  0.0  0.1 616488 19100 ?Ssl  15:49   0:00 
/usr/lib/gnome-shell/gnome-shell

gdm greeter (only once so far, after one boot/login):

Jan 13 15:48:53 perpetual gnome-shell[2523]: Object Clutter.Clone 
(0x5613efba6aa0), has been already finalized. Impossible to get any property 
from it.
Jan 13 15:48:53 perpetual gnome-shell[2523]: Object Clutter.Clone 
(0x5613efba6aa0), has been already finalized. Impossible to set any property to 
it.
Jan 13 15:48:53 perpetual org.gnome.Shell.desktop[2523]: == Stack trace for 
context 0x5613ee636000 ==
Jan 13 15:48:53 perpetual org.gnome.Shell.desktop[2523]: #0 0x5613ee8c61e8 i   
resource:///org/gnome/shell/ui/tweener.js:73 (0x7f19e41ddef0 @ 9)
Jan 13 15:48:53 perpetual org.gnome.Shell.desktop[2523]: #1 0x5613ee8c6168 i   
resource:///org/gnome/shell/ui/tweener.js:105 (0x7f19e41df230 @ 36)
Jan 13 15:48:53 perpetual org.gnome.Shell.desktop[2523]: #2 0x5613ee8c60e0 i   
resource:///org/gnome/shell/ui/tweener.js:92 (0x7f19e41df098 @ 52)
Jan 13 15:48:53 perpetual org.gnome.Shell.desktop[2523]: #3 0x7ffd10c13420 b   
resource:///org/gnome/gjs/modules/tweener/tweener.js:203 (0x7f19e41e9cd0 @ 54)
Jan 13 15:48:53 perpetual org.gnome.Shell.desktop[2523]: #4 0x7ffd10c13570 b   
resource:///org/gnome/gjs/modules/tweener/tweener.js:332 (0x7f19e41e9d58 @ 1626)
Jan 13 15:48:53 perpetual org.gnome.Shell.desktop[2523]: #5 0x7ffd10c13620 b   
resource:///org/gnome/gjs/modules/tweener/tweener.js:345 (0x7f19e41e9de0 @ 100)
Jan 13 15:48:53 perpetual org.gnome.Shell.desktop[2523]: #6 0x7ffd10c136b0 b   
resource:///org/gnome/gjs/modules/tweener/tweener.js:360 (0x7f19e41e9e68 @ 10)
Jan 13 15:48:53 perpetual org.gnome.Shell.desktop[2523]: #7 0x7ffd10c137a0 b   
resource:///org/gnome/gjs/modules/signals.js:126 (0x7f19e41e2b38 @ 386)
Jan 13 15:48:53 perpetual org.gnome.Shell.desktop[2523]: #8 0x7ffd10c13850 b   
resource:///org/gnome/shell/ui/tweener.js:208 (0x7f19e41df808 @ 159)
Jan 13 15:48:53 perpetual org.gnome.Shell.desktop[2523]: #9 0x7ffd10c138b0 I   
resource:///org/gnome/gjs/modules/_legacy.js:82 (0x7f19e41c2bc0 @ 71)
Jan 13 15:48:53 perpetual org.gnome.Shell.desktop[2523]: #10 0x7ffd10c138b0 I   
resource:///org/gnome/shell/ui/tweener.js:183 (0x7f19e41df780 @ 20)
Jan 13 15:48:53 perpetual org.gnome.Shell.desktop[2523]: #11 0x7ffd10c13980 b   
self-hosted:917 (0x7f19e41ee5e8 @ 394)
Jan 13 15:48:53 perpetual org.gnome.Shell.desktop[2523]: == Stack trace for 
context 0x5613ee636000 ==
Jan 13 15:48:53 perpetual org.gnome.Shell.desktop[2523]: #0 0x5613ee8c61e8 i   
resource:///org/gnome/shell/ui/tweener.js:80 (0x7f19e41ddef0 @ 82)
Jan 13 15:48:53 perpetual org.gnome.Shell.desktop[2523]: #1 0x5613ee8c6168 i   
resource:///org/gnome/shell/ui/tweener.js:105 (0x7f19e41df230 @ 36)
Jan 13 15:48:53 perpetual org.gnome.Shell.desktop[2523]: #2 0x5613ee8c60e0 i   
resource:///org/gnome/shell/ui/tweener.js:92 (0x7f19e41df098 @ 52)
Jan 13 15:48:53 perpetual org.gnome.Shell.desktop[2523]: #3 0x7ffd10c13420 b   
resource:///org/gnome/gjs/modules/tweener/tweener.js:203 (0x7f19e41e9cd0 @ 54)
Jan 13 15:48:53 perpetual org.gnome.Shell.desktop[2523]: #4 0x7ffd10c13570 b   
resource:///org/gnome/gjs/modules/tweener/tweener.js:332 (0x7f19e41e9d58 @ 1626)
Jan 13 15:48:53 perpetual 

Bug#882819: stretch-pu: package python-spake2/0.7-3~deb9u1

[Julien Cristau]

Control: tag -1 confirmed

On Mon, Nov 27, 2017 at 02:00:48 +0100, Andreas Beckmann wrote:

> Package: release.debian.org
> Severity: normal
> Tags: stretch
> User: release.debian@packages.debian.org
> Usertags: pu
> 
> Let's fix the python3 dependencies. #867457
> 
OK.

Cheers,
Julien

Bug#881301: marked as pending

[Simon McVittie]

On Sat, 13 Jan 2018 at 20:38:39 +0900, Mike Hommey wrote:
> On Sat, Jan 13, 2018 at 11:35:08AM +, Simon McVittie wrote:
> > On Sat, 13 Jan 2018 at 08:50:14 +0900, Mike Hommey wrote:
> > > When can this reach unstable?

The source packages have now been accepted. The buildds haven't picked
them up yet, but you should see binaries later today.

> > Huh. Did you recently enable any new Shell extensions, or update
> > existing extensions, or anything like that?
> 
> I've had extensions enabled for a while, and reading this bug I disabled
> them all. That didn't stop.

As a general note, disabling an extension at runtime does not guarantee to
unload it fully (it's meant to, but bugs in the extension can mean that
its actions are not completely undone) so to be completely sure please
disable extensions, log out and log back in. (But if the Shell crashes,
that's also sufficient!)

> What /does/ seem to have stopped it is me killing my script that
> overwrites the background image every ~10 minutes. But I've been running
> that for well over a year.

Based on this, it's very likely that in the new version, you'll get
warnings logged (in the systemd journal if you're using systemd; I
don't know where they end up on non-systemd machines) with a JavaScript
stack trace. This will hopefully be more useful in tracking down the root
cause than the C backtraces we've already seen, which mostly just say
"I'm interpreting some JavaScript" without indicating what.

Please report each distinct stack trace as a separate bug, similar
to the one I just reported at
.

Since you have a reproducer (your background-changing script) it would
be great if you could run without that script for a couple of hours,
report any stack traces you see with a note that they are *not* caused by
your background-changing script, then re-enable your script and report
any new stack traces that are well-correlated with background changes,
this time mentioning what your script does/how it works. There's probably
a bug in the code that sets the background.

Thanks,
smcv

Bug#883897: stretch-pu: package congress/4.0.0+dfsg1-3 -> +deb9u1

[Julien Cristau]

Control: tag -1 moreinfo

On Sat, Dec  9, 2017 at 00:30:01 +0100, Thomas Goirand wrote:

> Package: release.debian.org
> Severity: normal
> Tags: stretch
> User: release.debian@packages.debian.org
> Usertags: pu
> 
> Dear release team,
> 
> congress-server was built with openstack-pkg-tools *before* it stopped using
> /sbin/route from net-tools. Therefore, it's using /usr/sbin at setup time
> even though net-tools isn't a runtime dependency.
> 
> So I would like to upload a rebuild of Congress to Stretch, so its
> maintainer scripts would not need net-tools anymore. This would fix #858693.
> 
> Of course, since I am not planning any modification to the package, I have
> no debdiff to show (it would only contain a new changelog entry, which isn't
> very useful to review).
> 
If the rebuild makes a difference, then please show what that difference
actually is?  Possibly that means a binary debdiff in addition to the
normal source diff.

Cheers,
Julien

Bug#887077: spectre-meltdown-checker: Should return a sensible exit code

[Chris Lamb]

forwarded 887077 https://github.com/speed47/spectre-meltdown-checker/pull/76
thanks

This has been forwarded this upstream here:

  https://github.com/speed47/spectre-meltdown-checker/pull/76


Regards,

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

Bug#884561: stretch-pu: package pam-krb5-migrate/0.0.11-4

[Julien Cristau]

Control: tag -1 moreinfo

On Sat, Dec 16, 2017 at 22:19:00 +0100, Dominik George wrote:

> Package: release.debian.org
> Severity: normal
> Tags: stretch
> User: release.debian@packages.debian.org
> Usertags: pu
> 
> Hi,
> 
> I would like to update pam-krb5-migrate in stretch to fix #873271.
> 
> Right now, the package is unusable because it installs files to the
> wrong directories.
> 
Hi Dominik,

Care to provide the binary debdiff as well?
Also, when did this break?

Cheers,
Julien

Bug#884711: stretch-pu: package dpdk/16.11.4-1+deb9u1

[Julien Cristau]

Control: tag -1 moreinfo

Hi Luca,

On Mon, Dec 18, 2017 at 14:46:04 +, Luca Boccassi wrote:

> DPDK maintains LTS branches upstream for 2 years [1]. This is covered
> by regressions tests from Intel and AT on various networking hardware
> and virtualized environments.These tests are run to validate the
> release branch before tagging a new version. Other hardware vendors
> regularly test these LTS versions too. They are also used by other
> distros such as RedHat and Ubuntu.
> Only bug fixes that affect that release branch, and that have already
> been merged in the mainline, are allowed. No API/ABI changes of any
> kind are allowed. Full changelog can be found at the bottom of the
> release notes [2].
> Each major mainline release is followed by an LTS branch release, where
> the relevant bug fixes are backported, so there are usually 4 bugfix
> LTS releases per year. There are usually between 10 and 100 patches
> backported per release.
> 
> Stretch shipped with the first release of 16.11. Since then, there have
> been 4 bugfix LTS releases, up to 16.11.4 a few days ago.
> We have uploaded them to unstable/testing/stretch-backports.
> 
> We would like to take advantage of the upstream LTS maintenance and
> push these point releases to Stretch.
> 
> Attached is the full debdiff. I can provide a debdiff for each
> individual point release between 16.11 and 16.11.4 if required.
> There is only one change in dependency, python-elftools was demoted
> from Recommends to Suggests as it's not useful in most cases. I think
> this change is fine but can remove it if asked.
> 
> Patches to fix bugs reported on Ubuntu, and to make the build
> reproducible, are also included. I can remove them if asked.
> 
> The changelog is inlined at the bottom.
> 
> Although the main users are Debian users with custom software, there is
> a reverse build-dep in Stretch as well, collectd. It works fine with
> the new LTS version.
> 
Thanks for the detailed explanation, that helps.

A few comments:
- I'd rather do without the changes in debian/control
- likewise init script, pkg-config file (unless there's an explanation)
- the above doesn't seem to address the changes in debian/patches/, can
  you detail the reason behind each of those?
- I think from our perspective the reproducibility changes are adding
  more risk than anything else, and normally not appropriate for stable
- the change in prep-modules, generating dependencies on the exact version
  of linux-image rather than the ABI (probably with ">=" the build
  version), looks wrong.  I don't know if/how that is used by the package
  though.
- the debian/rules changes introduce noise, so if that can be trimmed
  down it would be welcome
- I can't speak to the upstream changes, but no objection in principle
  if that stuff is tested as you describe.  Is any of the LTS branch
  testing done in a Debian stable environment, either by upstream, you,
  or some other users of this code?

Cheers,
Julien

Bug#886445: needrestart: detect need to reboot due to Intel microcode updates

[Thomas Liske]

Hi,


Paul Wise  writes:

> On Sat, 2018-01-13 at 14:20 +0100, Thomas Liske wrote:
>
>> during adding the feature in needrestart I've looked more closely at the
>> uicode-tool stuff. I don't think we need to examine the initrd since
>> the following command should give already the required informations:
>> 
>> # iucode_tool -Sl /lib/firmware/intel-ucode/
>
> That would give false positives when the system has disabled adding the
> microcode to the initrd, since rebooting will not give the new ucode.
> This could happen if the sysadmin experienced issues with new ucodes.

wouldn't the microcode updates included into the initrd automaticly? I
don't find any config option in intel-microcode or initramfs-tools to
disable adding the microcode updates. I would expect that
intel-microcode is removed in such cases.

In case the initrd is build manually it will be still possible to
disable the microcode feature in needrestart 3.0 by an configuration
option. So the sysadmin needs to consciously decide to ignore them.


>> For the check in needrestart it should be enough to compare the current
>> running microcode signature with the latest available one. This would
>> also handle outdated initrd images gracefuly.
>
> I think on Debian at least, outdated microcode in the initrd could only
> be intentional on the part of the sysadmin.

Maybe some postinst problems like running out of disk space.

I still prefere to ignore the initrd completly since it is not provided by
Debian but build on the host and so it can be broken or outdated or
isn't used at all. It is hard to find the correct initrd file,
especially for 3rd party or self-build kernels not using the kernel-package.


Regards,
Thomas

-- 

::  WWW:https://fiasko-nw.net/~thomas/  ::
   :::  Jabber:   xmpp:tho...@jabber.fiasko-nw.net  :::
::  flickr: https://www.flickr.com/photos/laugufe/  ::

Bug#886858:

[Dennis Heddicke]

I tested the 3.16.53 upstream kernel and got the same problem.
Will you do something against this? Shall i report upstream?

Bug#877593: Acknowledgement (stretch-pu: package ocfs2-tools/1.8.4-4+deb9u1)

[Julien Cristau]

Control: tag -1 moreinfo

On Sun, Nov 26, 2017 at 16:35:18 +0100, Valentin Vidic wrote:

> Hi,
> 
> Any thoughs from the release team about this update request?
> 
I'm worried about the risk of regressions for users who already worked
around the bug or otherwise changed the links, e.g. to disable those
services.

Cheers,
Julien

Bug#882821: stretch-pu: package cerealizer/0.8.1-2~deb9u1

[Julien Cristau]

Control: tag -1 moreinfo

On Mon, Nov 27, 2017 at 02:12:32 +0100, Andreas Beckmann wrote:

> Package: release.debian.org
> Severity: normal
> Tags: stretch
> User: release.debian@packages.debian.org
> Usertags: pu
> 
> Let's fix the python3 dependencies. #867396
> 
> There is a bit patch noise due to the maintainer switch from svn to git,
> but therefore it's just a rebuild of the package from sid.
> 
The dependency change is good, the rest doesn't seem necessary.

Cheers,
Julien

Bug#887063: [nvidia-driver-libs] WTF this shit conflicts with it's own GLVND libs?

[Andreas Beckmann]

On 2018-01-13 10:37, Alex Volkov wrote:
> So out of two packages on which nvidia-driver is depending 
> (nvidia-driver-libs 
> and nvidia-driver-libs-nonglvnd), BOTH are conflicting with nvidia's glvnd 
> libs, making them not installable.

> Debian Release: 9.3
>   990 stable  security.debian.org 
>   990 stable  ftp.fi.debian.org 
>   990 stable  dl.google.com 
>   990 stable  deb.torproject.org 
>   900 stretch-backports ftp.debian.org 
>90 unstabledeb.i2p2.no 
>   100 testing ftp.fi.debian.org 

And if you are on stretch, use the packages from stretch-backports, that
have the dependencies adjusted for stretch. (nvidia-driver-libs-nonglvnd
is still buggy there ...).


Andreas

Bug#886445: needrestart: detect need to reboot due to Intel microcode updates

[Thomas Liske]

Henrique de Moraes Holschuh  writes:

> On Sat, 13 Jan 2018, Thomas Liske wrote:
>> # iucode_tool -Sl /lib/firmware/intel-ucode/
>
> It would have to be:
>
> iucode_tool -Sl /lib/firmware/intel-ucode /usr/share/misc/intel-microcode*
>
> and that could still miss something.
>
>
> Maybe it would be best to look inside the initrds directly, too...
>
> iucode_tool -Sl -tb /lib/firmware/intel-ucode \
>   -ta /usr/share/misc/intel-microcode* \
>   -tr /boot/initrd*

ACK on the /usr/share/misc/intel-microcode* glob, but I still don't like to 
attend
the initrd's since they are just an intermediate. If the sysadmin
follows intel-microcode/README.Debian.gz the /usr... glob should be sufficient.


Regards,
Thomas

-- 

::  WWW:https://fiasko-nw.net/~thomas/  ::
   :::  Jabber:   xmpp:tho...@jabber.fiasko-nw.net  :::
::  flickr: https://www.flickr.com/photos/laugufe/  ::

Bug#885835: awstats: CVE-2017-1000501: path traversals in config and migrate parameter

[Abhijith PA]

Hello.

I am working on updating awstats for jessie and stretch.

--
Abhijith PA

Bug#884375: bootscr.cubox-i

[Rainer Dorsch]

Hi,

wouldn't bootscr.cubox-i benefit from the same modification (?):

*rd@xbian*:*/etc/flash-kernel/bootscript*$ diff -u bootscr.cubox-i~ 
bootscr.cubox-i 
*rd@xbian*:*/etc/flash-kernel/bootscript*$ 

since it uses the same SoC (imx6), it needs the same cma bootarg:

https://wiki.debian.org/InstallingDebianOn/Wandboard#cma

Thanks
Rainer

-- 
Rainer Dorsch
http://bokomoko.de/

Bug#887083: lintian: does not report missing Depends: python3:any on python3-mimeparse_0.1.4-3_all.deb

[Andreas Beckmann]

Package: lintian
Version: 2.5.68
Severity: normal

$ lintian -I -E --pedantic python3-mimeparse_0.1.4-3_all.deb 
P: python3-mimeparse: no-upstream-changelog
I: python3-mimeparse: capitalization-error-in-description-synopsis python Python

but the package is missing the python3 dependency, see #867439

$ less python3-mimeparse_0.1.4-3_all.deb
python3-mimeparse_0.1.4-3_all.deb:
 new Debian package, version 2.0.
[...]
 Package: python3-mimeparse
 Source: python-mimeparse
 Version: 0.1.4-3
 Architecture: all
 Maintainer: Mathias Ertl 
 Installed-Size: 24
 Section: python
 Priority: optional
 Homepage: https://pypi.python.org/pypi/python-mimeparse
 Description: Parse mime-types and quality parameters - python 3.x
[...]
*** Contents:
[...]
drwxr-xr-x root/root 0 2016-12-26 20:13 ./usr/lib/python3/dist-packages/
-rw-r--r-- root/root  6452 2016-12-20 10:58 
./usr/lib/python3/dist-packages/mimeparse.py
-rw-r--r-- root/root  1744 2016-12-26 20:13 
./usr/lib/python3/dist-packages/python_mimeparse-0.1.4.egg-info
[...]

Andreas

Bug#887084: libmoosex-xsaccessor-perl: FTBFS: t/moose_accessor_overwrite_warning.t broken by new libmoose-perl

[Niko Tyni]

Package: libmoosex-xsaccessor-perl
Version: 0.007-1
Severity: serious
Tags: fixed-upstream
Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=120155

This package fails its test suite on current sid, apparently
due to a libmoose-perl update.

The problem should be fixed in 0.008 as seen in the upstream bug.
-- 
Niko Tyni   nt...@debian.org

Bug#883963: stretch-pu: package xchain/1.0.1-9~deb9u1

[Julien Cristau]

Control: tag -1 moreinfo

On Sat, Dec  9, 2017 at 21:21:27 +0100, Andreas Beckmann wrote:

> Package: release.debian.org
> Severity: normal
> Tags: stretch
> User: release.debian@packages.debian.org
> Usertags: pu
> 
> Let's fix the dependency problem of xchain in stretch, too. #878090
> It calls /usr/bin/wish, therefore it needs to depend on wish and not
> tk8.5 (which no longer provides the generic wish binary, that's tk8.6
> realm now).
> 
Was there a reason for the version-specific tk dependency?  Was xchain
tested with wish 8.6?

Cheers,
Julien

Bug#886445: needrestart: detect need to reboot due to Intel microcode updates

[Henrique de Moraes Holschuh]

On Sat, 13 Jan 2018, Thomas Liske wrote:
> wouldn't the microcode updates included into the initrd automaticly? I
> don't find any config option in intel-microcode or initramfs-tools to
> disable adding the microcode updates. I would expect that
> intel-microcode is removed in such cases.

/etc/default/intel-microcode and /etc/default/amd64-microcode.

You can disable them, yes.  Or force-enable them.  And in
intel-microcode's case, you can tell it to do pretty much anything as
far as microcode selection goes.

> I still prefere to ignore the initrd completly since it is not provided by
> Debian but build on the host and so it can be broken or outdated or
> isn't used at all. It is hard to find the correct initrd file,
> especially for 3rd party or self-build kernels not using the kernel-package.

Yes, it is a mess.

-- 
  Henrique Holschuh

Bug#887085: Convert init script provided by the package to systemd unit file

[I Sagar]

Package: diaspora-common

Version: 0.7.2.0+debian2

Severity: wishlist

Dear Maintainer,

 Please, provide systemd unit file instead of init script.
I plan to work on this in separate branch here
https://salsa.debian.org/ruby-team/diaspora-installer/tree/init-to-systemd

Thanks,
Sagar

Bug#887087: ftconfig.h:113:26: warning: "__SIZEOF_LONG__4" is not defined, evaluates to 0 [-Wundef]

[Daniel Boles]

Package: libfreetype6-dev
Version: 2.8.1-1
Severity: normal

Dear Maintainer,


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

   * What led up to the situation?

I simply updated/full-upgraded and eventually recompiled one of my own
projects, which previously produced no compiler errors or warnings (with
-Wall
-Wextra -Wpedantic on latest g++).


   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?

The new outcome is that I am spammed by multiple sets of warnings like this:

In file included from /usr/include/freetype2/freetype/freetype.h:33:0,
 from /usr/include/cairo/cairo-ft.h:47,
 from /usr/include/cairomm-1.0/cairomm/enums.h:23,
 from /usr/include/cairomm-1.0/cairomm/surface.h:37,
 from /usr/include/cairomm-1.0/cairomm/context.h:24,
 from /usr/include/pangomm-1.4/pangomm/context.h:42,
 from /usr/include/gtkmm-3.0/gtkmm/widget.h:31,
 from /usr/include/gtkmm-3.0/gtkmm/container.h:28,
 from /usr/include/gtkmm-3.0/gtkmm/bin.h:27,
 from /usr/include/gtkmm-3.0/gtkmm/window.h:30,
 from /usr/include/gtkmm-3.0/gtkmm/dialog.h:29,
 from /usr/include/gtkmm-3.0/gtkmm/aboutdialog.h:32,
 from /home/daniel/src/[project]/src/gui/About.hpp:4,
 from /home/daniel/src/[project]/src/gui.cpp:9:
/usr/include/freetype2/freetype/config/ftconfig.h:113:26: warning:
"__SIZEOF_LONG__4" is not defined, evaluates to 0 [-Wundef]
 #define FT_SIZEOF_LONG  (__SIZEOF_LONG__4 / FT_CHAR_BIT)
  ^
/usr/include/freetype2/freetype/config/ftconfig.h:293:5: note: in expansion
of
macro ‘FT_SIZEOF_LONG’
 #if FT_SIZEOF_LONG == __SIZEOF_LONG__
 ^~
/usr/include/freetype2/freetype/config/ftconfig.h:113:26: warning:
"__SIZEOF_LONG__4" is not defined, evaluates to 0 [-Wundef]
 #define FT_SIZEOF_LONG  (__SIZEOF_LONG__4 / FT_CHAR_BIT)
  ^
/usr/include/freetype2/freetype/config/ftconfig.h:302:9: note: in expansion
of
macro ‘FT_SIZEOF_LONG’
 #elif ( FT_SIZEOF_LONG == __SIZEOF_LONG__ )   && \


   * What outcome did you expect instead?

I expected simply to be able to continue compiling my project with no
errors or
warnings, especially not ones about a macro that looks like it might
eventually
end up somewhere where its having the wrong value could create security
risks.
:)


Thanks!



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

Kernel: Linux 4.14.0-3-amd64 (SMP w/8 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)
LSM: AppArmor: enabled

Versions of packages libfreetype6-dev depends on:
ii  libc6-dev [libc-dev]   2.26-3
ii  libfreetype6   2.8.1-1
ii  libpng-dev 1.6.34-1
ii  zlib1g-dev [libz-dev]  1:1.2.8.dfsg-5

libfreetype6-dev recommends no packages.

libfreetype6-dev suggests no packages.

-- no debconf information

Bug#887088: kile: okular dependency missing

[Luca Ghio]

Package: kile
Version: 4:2.9.91-3
Severity: normal

Dear Maintainer,

If the okular package is not installed, kile can not start and crashes on a
segmentation fault.

Manually installing the okular package fixes the problem, so it should probably
be added to the dependencies.

>From a quick debug session in the code, I saw that the code tries deferencing
the m_livePreviewManager pointer but that pointer was previously deleted.



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

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

Versions of packages kile depends on:
ii  kio5.37.0-2
ii  konsole-kpart  4:17.08.3-1
ii  libc6  2.26-2
ii  libgcc11:7.2.0-19
ii  libkf5codecs5  5.37.0-2
ii  libkf5completion5  5.37.0-2
ii  libkf5configcore5  5.37.0-2
ii  libkf5configgui5   5.37.0-2
ii  libkf5configwidgets5   5.37.0-2
ii  libkf5coreaddons5  5.37.0-2
ii  libkf5dbusaddons5  5.37.0-2
ii  libkf5guiaddons5   5.37.0-2
ii  libkf5i18n55.37.0-2
ii  libkf5iconthemes5  5.37.0-2
ii  libkf5jobwidgets5  5.37.0-2
ii  libkf5khtml5   5.37.0-3
ii  libkf5kiocore5 5.37.0-2
ii  libkf5kiofilewidgets5  5.37.0-2
ii  libkf5kiowidgets5  5.37.0-2
ii  libkf5parts5   5.37.0-2
ii  libkf5service-bin  5.37.0-2
ii  libkf5service5 5.37.0-2
ii  libkf5texteditor5  5.37.0-2+b1
ii  libkf5textwidgets5 5.37.0-2
ii  libkf5widgetsaddons5   5.37.0-2
ii  libkf5windowsystem55.37.0-2
ii  libkf5xmlgui5  5.37.0-2
ii  libpoppler-qt5-1   0.61.1-2
ii  libqt5core5a   5.9.2+dfsg-6
ii  libqt5dbus55.9.2+dfsg-6
ii  libqt5gui5 5.9.2+dfsg-6
ii  libqt5script5  5.9.2+dfsg-2
ii  libqt5widgets5 5.9.2+dfsg-6
ii  libqt5xml5 5.9.2+dfsg-6
ii  libstdc++6 7.2.0-19
ii  perl   5.26.1-3
ii  texlive-latex-base 2017.20180103-1

Versions of packages kile recommends:
ii  dvipng   1.14-2+b3
ii  ghostscript  9.22~dfsg-1
ii  imagemagick  8:6.9.7.4+dfsg-16
ii  imagemagick-6.q16 [imagemagick]  8:6.9.7.4+dfsg-16
ii  psutils  1.17.dfsg-4
ii  texlive  2017.20180103-1

Versions of packages kile suggests:
ii  aspell  0.60.7~20110707-4
pn  asymptote   
pn  context 
pn  dblatex 
ii  ispell  3.4.00-6
pn  kbibtex 
pn  kile-doc
pn  kile-l10n   
pn  latex2html  
ii  lilypond2.18.2-11
ii  texlive-plain-generic [tex4ht]  2017.20180103-2
pn  texlive-xetex   
ii  zip 3.0-11+b1

-- no debconf information

Bug#887089: ITP: node-shiny-server-client -- browser library for connecting to Shiny Server

[Philip Rinn]

Package: wnpp
Severity: wishlist
Owner: Philip Rinn 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-shiny-server-client
  Version : 1.0.0+gitf214eae
  Upstream Author : RStudio 
* URL : https://github.com/rstudio/shiny-server-client
* License : AGPL-3.0
  Programming Lang: JavaScript
  Description : browser library for connecting to Shiny Server

 This Node.js package provides unified client code for Shiny Server, Shiny 
Server
 Pro, and RStudio Connect. Previously, each server product had its own version 
of
 this code with slight differences. This package provides the superset of
 functionality needed by the different products, and runtime options determine
 what features to enable.
 .
 Node.js is an event-based server-side JavaScript engine.

This package is a dependency of shiny-server (which will be maintained by
Debian-science). I intend to maintain the package under the Debian Science
umbrella. I'll need a sponsor to upload the package.

Bug#872459: python-numpy: please make the output reproducible

[Chris Lamb]

Hey!

> [fixed upstream]

Could you merge this into Debian? Was fixed upstream and I just
noticed it is making src:numexpr unreproducible :)


Best wishes,

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

Bug#886120: FTBFS: chown: cannot access '..._cgraph.dot': No such file or directory

[Vasudev Kamath]

Adam Borowski  writes:

> On Tue, Jan 09, 2018 at 10:42:19PM +0530, Vasudev Kamath wrote:
>> Control: tag -1 +moreinfo +unreproducible
>> 
>> Adam Borowski  writes:
>> > Source: ctpp2
>> > Version: 2.8.3-23
>> >
>> > Hi!
>> > I'm afraid your package fails to build:
>> >
>> > dh_fixperms -pctpp2-doc 
>> > chown: cannot access 
>> > 'debian/ctpp2-doc/usr/share/doc/ctpp2-doc/html/a01323_acf0137f96d20b71a2e2e18b489d1a33e_cgraph.dot':
>> >  No such file or directory
>> > chown: cannot access 
>> > 'debian/ctpp2-doc/usr/share/doc/ctpp2-doc/html/inherit_graph_65.md5': No 
>> > such file or directory
>> > dh_fixperms: find debian/ctpp2-doc -true -print0 2>/dev/null | xargs -0r 
>> > chown --no-dereference 0:0 returned exit code 123
>> > dh_fixperms: Aborting due to earlier error
>> >
>> > Tried on armhf amd64.  Log attached.
>> 
>> Could not reproduce on amd64, it built fine. Was not able to check on
>> armhf yet. Attaching my build log for reference.
>
> Sorry for the delay.  I haven't found the cause yet, but here's my progress:
>
> It looks like kernel version is a factor.  All my test machines run current
> 4.15-rc, so that was common to all builds.
>
> On amd64, with today's unstable:
> ✓ 4.9.76, self-compiled
> ✗ 4.14.13, self-compiled
> ✗ linux-image-4.14.0-3-amd64 (4.14.12-2)
> ✗ 4.15.0-rc7-debug-00137, self-compiled
>
> You do run some version of 4.14.0-3-amd64, though.  Hrm...  Lemme poke more.

Yeah. Since you mentioned its random can we reduce the severity of the
bug?.

Meow,

Bug#887110: Debian Testing Cannot be installed on Macchiatobin

[Cyril Brulebois]

Hi Thorsten,

And thanks for the report.

Thorsten Alteholz  (2018-01-13):
> Package: debian-installer
> Version: debian-testing-arm64-netinst.iso  dated 2018-13-01  226492416
> 
> I am trying to use the netinst iso on an USB stick to install Debian on a
> recent Macchiatobin (ref 1.3) via serial line. After starting the default
> installation, some prints appeared:
> 
> (...)
> Loading driver at 0x000B3A6B000 EntryPoint=0x000B452FF8C
> Loading driver at 0x000B3A6B000 EntryPoint=0x000B452FF8C
> [0.337121] hw perfevents: unable to count PMU IRQs
> [1.905802] armada8k-pcie f260.pcie: phy link never came up
> [1.911763] armada8k-pcie f260.pcie: Link not up after reconfiguration
> 
> and everything freezes.
> Trying this with an installer some days before (unfortunately I don't know
> which version, but from 2018) the installation went further ...

Any chance you could check what happens with daily builds?
  https://d-i.debian.org/daily-images/amd64/

Tentative culprit: the kernel ABI bump from -2 to -3 on the 7th?

Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#887124: lintian: Do not use new-package-should-not-package-python2-module on lintian.d.o

[Scott Kitterman]

Package: lintian
Version: 2.5.68
Severity: normal

Dear Maintainer,

When new-package-should-not-package-python2-module appears on lintian.d.o, it
is an unneeded distraction.  At this point it's no longer a new package.  Any
future upload will 'fix' the issue since all this test does is check that
there is only a single debian/changelog entry.

I can, sort of, see the utility of this, for new packages, to get the
maintainer to consider if the new python2 package is really needed or not, but
by the time lintian.d.o sees the package, it's too late.

Please supress this tag from lintian.d.o

Scott K

Bug#887115: pull requests upstream

[Jeffrey Cliff]

Between

https://github.com/zheller/flake8-quotes/pull/66
https://github.com/zheller/flake8-quotes/pull/67

there's a preliminary debian package directory that successfully builds a
package

Hope this helps
Jeff Cliff

Bug#887096: python3-ipdb: new version available upstream: 0.10.3

[Jeff Cliff]

Package: python3-ipdb
Version: 0.10.1-1
Severity: normal

Dear Maintainer,

As the PTS suggests ( https://packages.qa.debian.org/i/ipdb.html ), there is
a new version available upstream ( 0.10.3 ).

PTS suggests this can be found at pypi at 
http://pypi.debian.net/ipdb/ipdb-0.10.3.tar.gz
but there's also the github as well
https://github.com/gotcha/ipdb/releases/tag/0.10.3

Thanks in advance,
Jeff Cliff



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

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

Versions of packages python3-ipdb depends on:
pn  ipython3   
ii  python33.5.3-1
ii  python3-pkg-resources  33.1.1-1

python3-ipdb recommends no packages.

python3-ipdb suggests no packages.

Bug#811565: [uscan] git mode: allow for scanning repositories without tags

[Osamu Aoki]

Hi,

On Thu, Jan 11, 2018 at 09:56:01AM +0100, Michael Stapelberg wrote:
> Happy new year!
> 
> Osamu, any update on this? We’re still really interested.

In progress ... partially working

I need to clean up codes ;-)
I also need couple test cases to test these out.

git served from github, git over WEBDAV, ...

Latest local diff is attached.

Osamu
>From a635d170bfc8b09218c778ea1f7d3866b0776531 Mon Sep 17 00:00:00 2001
From: Osamu Aoki 
Date: Sat, 13 Jan 2018 21:24:34 +0900
Subject: [PATCH] Improve git (wip)

Now git and git-dumb exists

Need to clean up temporary directory etc.

Signed-off-by: Osamu Aoki 
---
 scripts/uscan.pl | 214 +--
 1 file changed, 160 insertions(+), 54 deletions(-)

diff --git a/scripts/uscan.pl b/scripts/uscan.pl
index 1b47da63..208115cc 100755
--- a/scripts/uscan.pl
+++ b/scripts/uscan.pl
@@ -357,14 +357,42 @@ either B or B by URL.
 =item B
 
 This mode accesses the upstream git archive directly with the B command
-and packs the source tree with the specified tag into
+and packs the source tree with the specified tag via I into
 IB<.tar.xz>.
 
 If the upstream publishes the released tarball via its web interface, please
 use it instead of using this mode.  This mode is the last resort method.
 
+If I is set to B, the pertinent I is
+automatically generated with the date and hush of the B of the git
+repository.
+
+=item B
+
+B.
+
+When the upstream git archive is a dumb HTTP server which doesn't allow shallow
+checkout, this B mode should be used instead.
+
+Other than the fact that this mode makes full clone of the upstream repository
+as needed, this mode behaves exactly the same as the B mode.
+
 =back
 
+=item 

Bug#887098: joe orphans buffers for no reason

[Wolfgang Tichy]

Package: joe
Version: 4.4-1
Severity: normal
Tags: upstream

Dear Maintainer,

I am using your joe editor since 1994, and I love it.
Thanks for maintaining it!

However, I just noticed a srange bug. When I start joe with just one C-file
and then press Esc-C to compile, joe orphans my C-file into a buffer.
Instead I am left with 2 windows. One contains the new file "Unnamed" , the
other contains "* Build Log *". If I use Ctrl-K N, I cannot get back to my
C-file, because it's in an orphaned buffer. The only way to get it back is
with Esc-U to put the buffer back into a window. This seems a little
counterintuitive. It happens with joe 4.4 (that I have from Debian) and 4.6
(that I compiled myself) but not 3.7 (which was in the previous stable
Debian version), I don't know about other versions. I think it's caused by
mwind, mfit, or scratch in :def compile in /etc/joe/joerc. It seems that one
of them takes over a window and orphans the buffer that was in it before. In
fact something similar happens if I open several files and then hit Esc-C to
compile, one buffer is orphaned.

It seems this behavior is very confusing for new users, and should be
changed... Of course I can live with this, but considering joe 3.7 bahaved
better, it feels unfortunate. In joe 3.7 no buffer was orphaned, joe simply
put the new buffers for compiling into additional new windows.

Thanks a lot,
Wolfgang


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

Kernel: Linux 4.9.0-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 joe depends on:
ii  libc62.24-11+deb9u1
ii  libncurses5  6.0+20161126-1+deb9u1
ii  libtinfo56.0+20161126-1+deb9u1

joe recommends no packages.

joe suggests no packages.

-- no debconf information

Bug#887097: ITP: dh-octave -- Debhelper-based infrastructure for building Octave add-on packages

[Rafael Laboissière]

Package: wnpp
Severity: wishlist
Owner: Rafael Laboissiere 

* Package name: dh-octave 
 Version : 0.1.0 
 Upstream Author : Debian Octave Group  
* URL : https://salsa.debian.org/pkg-octave-team/dh-octave 
* License : GPL-3+ 
 Programming Lang: Bourne shell, Octave, Perl 
 Description : Debhelper-based infrastructure for building Octave add-on packages


Since version 3.0 of Octave (a numerical computation software), 
add-ons can be installed through the pkg.m system.  This package 
provides the infrastructure for packaging such add-ons for Debian, 
based on debhelper.  It replaces the deprecated octave-pkg-dev 
package. This package contains debhelper-like scripts for building, 
checking and cleaning the add-on package as well as for generating the 
substitution variables in debian/control.


This package is intended to be used by the Debian Octave Group 
and should be of little interest to general users.


Once this package will be in unstable, the ~50 octave-* packages that 
provide Octave-Forge add-ons will migrate their build-dependency from 
octave-pkg-dev to dh-octave.


This package will be maintained in the realm of the Debian Octave 
Group.

Bug#887104: libchemps2-dev: Please ship CMake files

[Michael Banck]

Package: libchemps2-dev
Version: 1.8.4-2
Severity: wishlist

Dear Maintainer,

chemps2 includes CMake config files and they get installed during the
package build in debian/tmp/usr/share/cmake/, but are not shipped in
libchemps2-dev.

I am currently looking at packaging Psi4-1.1, and they revamped the
build system, requiring CMake config files for external projects, so
currently there is no CheMPS2 support.

Please ship the CMake config files in the -dev package, unless there is
some major issue in doing so.

Best regards,

Michael

-- System Information:
Debian Release: 8.10
  APT prefers oldstable
  APT policy: (500, 'oldstable')
Architecture: i386 (i686)

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

Bug#887106: denying ptrace access check without PTRACE_MODE_*CREDS

[Anton Gorlov]

Package: linux-image-3.2.0-5-amd64
Version: 3.2.96-3


When i boot server . based on

Manufacturer: Supermicro
Product Name: X7DB8

I get  many messages in dmesg like

_wait_scan]
[Sat Jan 13 23:52:23 2018] Pid: 2840, comm: snmpd Tainted: GW 
3.2.0-5-amd64 #1 Debian 3.2.96-3

[Sat Jan 13 23:52:23 2018] Call Trace:
[Sat Jan 13 23:52:23 2018]  [] ? 
warn_slowpath_common+0x78/0x8c
[Sat Jan 13 23:52:23 2018]  [] ? 
warn_slowpath_fmt+0x45/0x4a

[Sat Jan 13 23:52:23 2018]  [] ? find_ge_pid+0x13/0x34
[Sat Jan 13 23:52:23 2018]  [] ? 
__ptrace_may_access+0x47/0xf9
[Sat Jan 13 23:52:23 2018]  [] ? 
ptrace_may_access+0x24/0x36
[Sat Jan 13 23:52:23 2018]  [] ? 
proc_pid_readdir+0xfc/0x1dc

[Sat Jan 13 23:52:23 2018]  [] ? fillonedir+0xaa/0xaa
[Sat Jan 13 23:52:23 2018]  [] ? fillonedir+0xaa/0xaa
[Sat Jan 13 23:52:23 2018]  [] ? fillonedir+0xaa/0xaa
[Sat Jan 13 23:52:23 2018]  [] ? vfs_readdir+0x6f/0xa7
[Sat Jan 13 23:52:23 2018]  [] ? kmem_cache_free+0x2d/0x81
[Sat Jan 13 23:52:23 2018]  [] ? sys_getdents+0x7d/0xcd
[Sat Jan 13 23:52:23 2018]  [] ? 
system_call_fastpath+0x16/0x1b

[Sat Jan 13 23:52:23 2018] ---[ end trace 6d1185e92fa57d12 ]---
[Sat Jan 13 23:52:23 2018] [ cut here ]
[Sat Jan 13 23:52:23 2018] WARNING: at 
/build/linux-HPGG73/linux-3.2.96/kernel/ptrace.c:228 
__ptrace_may_access+0x47/0xf9()

[Sat Jan 13 23:52:23 2018] Hardware name: X7DB8
[Sat Jan 13 23:52:23 2018] denying ptrace access check without 
PTRACE_MODE_*CREDS
[Sat Jan 13 23:52:23 2018] Modules linked in: xt_recent ts_bm ts_kmp 
ipt_LOG xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 xt_st
ate nf_conntrack ipt_REJECT xt_string xt_owner xt_multiport 
iptable_filter ip_tables x_tables ext2 loop radeon ttm drm_kms_he
lper snd_pcm drm snd_page_alloc snd_timer power_supply i2c_algo_bit 
iTCO_wdt iTCO_vendor_support ioatdma i5000_edac snd psmou
se edac_core i2c_i801 i5k_amb rng_core parport_pc dca i2c_core parport 
shpchp soundcore coretemp evdev serio_raw processor bu
tton container pcspkr thermal_sys ext4 crc16 jbd2 mbcache dm_mod 
microcode usbhid hid ses enclosure sd_mod crc_t10dif sg sr_m
od cdrom ata_generic uhci_hcd floppy ata_piix libata ehci_hcd usbcore 
aacraid usb_common scsi_mod e1000e [last unloaded: scsi

_wait_scan]

and some messages for
Pid: 3830, comm: sudo Tainted: GW3.2.0-5-amd64 #1 Debian 
3.2.96-3


after login from ssh i get in console. but proc is mounted

Error, do this: mount -t proc proc /proc
Error, do this: mount -t proc proc /proc
Error, do this: mount -t proc proc /proc
-bash: __rvm_add_to_path: команда не найдена

Bug#886901: base-files: FTBFS: cannot remove '/etc/debian_version'

[Niels Thykier]

Santiago Vila:
> On Thu, Jan 11, 2018 at 08:10:00PM +, Niels Thykier wrote:
> 
>>> I'm confused. Do you mean that the install target is "taken"
>>> and packages may not freely use it in debian/rules?
>>>
>>
>> Afraid so; it occurred before my involvement in debhelper, but I think
>> it used to be more common for packages to also have an "install" target
>> and debhelper basically mirrored that (with -arch + -indep variants).
> 
> I must be missing something, then, because today I've checked that
> "dpkg-buildpackage":
> 
> - Works ok in stretch.
> - Does only fail in buster/sid (I actually tried it in sid).
> 
> ("dpkg-buildpackage -B" works ok in both stretch and buster/sid).
> 

debhelper before 11.1 had a very suboptimal handling of sequence targets
in debian/rules (reported in #880840).  In debhelper/11.1, this was
fixed by properly treating d/rules targets as opaque and assuming that
the target will properly delegate tasks on as necessary.
  This bug has been present more or less since compat 9 was introduced,
but we have not noticed until now.  I suspect it is related to how
dpkg-buildpackage calls d/rules, which somehow hides the issue in
base-files (but shows a bug in the behaviour of debhelper/10.2.5).

In a clean base-files source checkout, you can see that dh thinks it
should run "debian/rules install":

$ dh binary --no-act | grep 'debian/rules install'
   debian/rules install
$

(You can see the suboptimal handling of this target by looking at the
full sequence.  dh actually wants to run "debian/rules install" as the
very first thing before calling any of the build commands and will then
follow it by calling the build + install commands *again*)

But if you emulate the way dpkg-buildpackage calls the rules file, then
the "debian/rules install" call disappears in debhelper/10.2.5:

$ dpkg-buildpackage -us -uc -T build
[...]
$ dh binary --no-act | grep 'debian/rules install'
$

The absence of the "debian/rules install" is a technically a violation
of the API that debhelper promises for compat 9 packages, which says:

"""
>-   dh is aware of the usual dependencies between targets in 
> debian/rules.  So, "dh binary" will run any build, build-arch, build-indep, 
> install,
>etc targets that exist in the rules file. There's no need 
> to define an explicit binary target with explicit dependencies on the other 
> targets"""

(Turns out that Joey happened to list "install" explicitly before the
"etc.".  I had not noticed that until now.)

For the record, debhelper recognises the following sequence targets:

 * build, build-arch and build-indep
 * install, install-arch and install-indep
 * binary, binary-arch and binary-indep
 * clean

They were present for as long as I mentioned debhelper and I assume they
were present since debhelper/9 (but I haven't bothered digging in the
git log to confirm that).

> Fixing this is base-files would be trivial, of course, but before I do
> that I'd like to confirm that it's a bug in base-files.
> 
> Considering that this used to work in stretch, are you sure that
> debhelper is following the "specs"?
> 
> Thanks.
> 


I believe debhelper finally follows the spec it set for itself and I
would appreciate if we fixed it in base-files.  Apologies for the extra
work on your end.

Thanks,
~Niels

Bug#887111: ITP: elpa-alect-themes -- Configurable color themes for GNU Emacs 24

[Thomas Cordeu]

Package: wnpp
Severity: wishlist
Owner: Thomas Cordeu 

* Package name: elpa-alect-themes
  Version : 0.8
  Upstream Author : Alex Kost 
* URL : https://github.com/alezost/alect-themes
* License : GPL
  Programming Lang: Emacs Lisp
  Description : Configurable color themes for GNU Emacs 24

This package is needed to package Spacemacs.
This package will be team mantained by Debian Emacs addons team 
.

Bug#887106: Acknowledgement (denying ptrace access check without PTRACE_MODE_*CREDS)

[Anton Gorlov]

CPU model name  : Intel(R) Xeon(R) CPU   E5430  @ 2.66GHz

Bug#887046: libxext: Please make w3m Build-Depends-Indep

[Sven Joachim]

Control: tags -1 + pending

On 2018-01-13 01:09 +0100, Samuel Thibault wrote:

> Source: libxext
> Version: 2:1.3.3-1
> Severity: normal
>
> Hello,
>
> w3m ends up depending on mesa, which ends up depending on libxext,
> which build-depends on w3m. This is thus making a loop in architecture
> bootstrap. Could you move the w3m Build-Dep to Build-Depends-Indep to
> avoid this loop? Other depends could be moved there such as xsltproc
> etc.

I have done that in git and also made a few other cleanups to the
package, such as switching debian/rules to dh and killing xsfbs[1].

Cheers,
   Sven


1. https://salsa.debian.org/xorg-team/lib/libxext/commits/debian-unstable

Bug#887102: Please add quirk US_FL_BROKEN_FUA JMS567-based USB3 UAS enclosure (152d:0578) to stretch debian kernels

[Laurent GUERBY]

Package: linux
Version: 4.9.65-3+deb9u
Severity: wishlist

Hi,

The quirk  US_FL_BROKEN_FUA JMS567-based USB3 UAS enclosure
(152d:0578) has been added by this patch :

https://patchwork.kernel.org/patch/10120851/

It has been included by upstream kernel 4.9.71 and 4.14.8 but isn't
available on released debian kernel stretch and stretch-backports.

We have a debian stretch machine with this USB3 enclosure and we get
this kind of error which should be fixed by the quirk:

https://unix.stackexchange.com/questions/237204/filesystem-is-reporting
-a-write-error-on-a-specific-sector-even-after-the-partit

Thanks in advance for your help,

Sincerely,

Laurent

Bug#887110: Debian Testing Cannot be installed on Macchiatobin

[Thorsten Alteholz]

Package: debian-installer
Version: debian-testing-arm64-netinst.iso  dated 2018-13-01  226492416

I am trying to use the netinst iso on an USB stick to install Debian on a 
recent Macchiatobin (ref 1.3) via serial line. After starting the default 
installation, some prints appeared:


(...)
Loading driver at 0x000B3A6B000 EntryPoint=0x000B452FF8C
Loading driver at 0x000B3A6B000 EntryPoint=0x000B452FF8C
[0.337121] hw perfevents: unable to count PMU IRQs
[1.905802] armada8k-pcie f260.pcie: phy link never came up
[1.911763] armada8k-pcie f260.pcie: Link not up after reconfiguration

and everything freezes.
Trying this with an installer some days before (unfortunately I don't know 
which version, but from 2018) the installation went further ...


  Thorsten

Bug#887107: [debian-i18n] https://i18n.debian.org/material/data/unstable.gz not updated since 2017-11-23

[Laura Arjona Reina]

Forgot to attach the summarized log file.

Cheers

-- 
--
Laura Arjona Reina
https://wiki.debian.org/LauraArjona

/srv/mirrors/debian//pool/main/a/ansible/ansible_2.4.2.0+dfsg.orig.tar.gz:ansible-2.4.2.0/test/integration/targets/copy/files/subdir/subdir1/circles/subdir1/circles/subdir1/c:
 checksum error.
 at /srv/i18n.debian.org//dl10n/git/dl10n-check line 463.
/srv/mirrors/debian//pool/main/a/ansible/ansible_2.4.2.0+dfsg.orig.tar.gz:r1/circles/subdir1/circles/subdir1/circles/subdir1/circles/subdir1/circles/subdir1/circles/subdir1/c:
 checksum error.
[... many more like these two...]

/srv/mirrors/debian//pool/main/a/ansible/ansible_2.4.2.0+dfsg.orig.tar.gz:ansible-2.4.2.0/test/integration/targets/copy/files/subdir/subdir1/circles/subdir1/circles/subdir1/c:
 checksum error.
 at /srv/i18n.debian.org//dl10n/git/dl10n-check line 463.
/srv/mirrors/debian//pool/main/a/ansible/ansible_2.4.2.0+dfsg.orig.tar.gz:r1/circles/subdir1/circles/subdir1/circles/subdir1/circles/subdir1/circles/subdir1/circles/subdir1/c:
 checksum error.
 at /srv/i18n.debian.org//dl10n/git/dl10n-check line 463.

Package cinder, debconf-updatepo returned:
pt.po:32:3: invalid multibyte sequence
pt.po:33:58: invalid multibyte sequence
[.. many more like these two, in different lines of the file]
pt.po:326:34: invalid multibyte sequence
pt.po:326:35: invalid multibyte sequence
msgmerge: found 83 fatal errors

Package glance, debconf-updatepo returned:
pt.po:69:17: invalid multibyte sequence
pt.po:70:20: invalid multibyte sequence
[.. many more like these two, in different lines of the file]
pt.po:373:23: invalid multibyte sequence
pt.po:373:24: invalid multibyte sequence
msgmerge: found 72 fatal errors

Package glare, debconf-updatepo returned:
pt.po:32:3: invalid multibyte sequence
pt.po:33:58: invalid multibyte sequence
[.. many more like these two, in different lines of the file]
pt.po:320:10: invalid multibyte sequence
pt.po:320:11: invalid multibyte sequence
msgmerge: found 83 fatal errors

/srv/mirrors/debian//pool/main/g/gnome-software/gnome-software_3.26.3.orig.tar.xz:../../../../../../../../app-missing-runtime/org.test.Chiron/files/share/icons/hicolor/128x128/apps/o:
 checksum error.
 at /srv/i18n.debian.org//dl10n/git/dl10n-check line 463.
readline() on closed filehandle PO at 
/srv/i18n.debian.org//dl10n/git/dl10n-check line 748.
readline() on closed filehandle PO at 
/srv/i18n.debian.org//dl10n/git/dl10n-check line 748.
[.. many more like these two]
readline() on closed filehandle PO at 
/srv/i18n.debian.org//dl10n/git/dl10n-check line 748.
readline() on closed filehandle PO at 
/srv/i18n.debian.org//dl10n/git/dl10n-check line 748.

gzip: 
/srv/i18n.debian.org//tmp/gen-material/gnome-software/gnome-software-3.26.3/po/ko.po:
 No such file or directory
Cannot run: gzip -9f -c 
"/srv/i18n.debian.org//tmp/gen-material/gnome-software/gnome-software-3.26.3/po/ko.po"
 > 
"/srv/i18n.debian.org//dl10n/git/../data/gen-material/po/testing/main/g/gnome-software/gnome-software-3.26.3/po/gnome-software_3.26.3-4_ko.po.gz":
 No such file or directory
gzip: 
/srv/i18n.debian.org//tmp/gen-material/gnome-software/gnome-software-3.26.3/po/pt.po:
 No such file or directory
Cannot run: gzip -9f -c 
"/srv/i18n.debian.org//tmp/gen-material/gnome-software/gnome-software-3.26.3/po/pt.po"
 > 
"/srv/i18n.debian.org//dl10n/git/../data/gen-material/po/testing/main/g/gnome-software/gnome-software-3.26.3/po/gnome-software_3.26.3-4_pt.po.gz":
 No such file or directory
[.. many more like these two, in different languages]
Cannot run: gzip -9f -c 
"/srv/i18n.debian.org//tmp/gen-material/gnome-software/gnome-software-3.26.3/po/sr.po"
 > 
"/srv/i18n.debian.org//dl10n/git/../data/gen-material/po/testing/main/g/gnome-software/gnome-software-3.26.3/po/gnome-software_3.26.3-4_sr.po.gz":
 No such file or directory
gzip: 
/srv/i18n.debian.org//tmp/gen-material/gnome-software/gnome-software-3.26.3/po/eo.po:
 No such file or directory
Cannot run: gzip -9f -c 
"/srv/i18n.debian.org//tmp/gen-material/gnome-software/gnome-software-3.26.3/po/eo.po"
 > 
"/srv/i18n.debian.org//dl10n/git/../data/gen-material/po/testing/main/g/gnome-software/gnome-software-3.26.3/po/gnome-software_3.26.3-4_eo.po.gz":
 No such file or directory

/srv/mirrors/debian//pool/main/libv/libvirt/libvirt_3.10.0.orig.tar.xz:0: 
checksum error.
 at /srv/i18n.debian.org//dl10n/git/dl10n-check line 463.
/srv/mirrors/debian//pool/main/libv/libvirt/libvirt_3.10.0.orig.tar.xz:0: 
checksum error.
 at /srv/i18n.debian.org//dl10n/git/dl10n-check line 463.
[...some more like these two..]

/usr/bin/xgettext: warning: file '../../mktemplates.continents' extension 
'continents' is unknown; will try C
/usr/bin/xgettext: error while opening "../../mktemplates.continents" for 
reading: No such file or directory
ERROR: xgettext failed to generate PO template file. Please consult
   error message above if there is any.
/usr/bin/xgettext: warning: file '../../mktemplates.continents' extension 
'continents' is unknown; will 

Bug#887091: ITP: r-cran-utf8 -- GNU R unicode text processing

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-utf8
  Version : 1.1.3
  Upstream Author : Patrick O. Perry 
* URL : https://cran.r-project.org/package=utf8
* License : Apache
  Programming Lang: GNU R
  Description : GNU R unicode text processing
 This GNU R package helps processing and printing 'UTF-8' encoded
 international text (Unicode). Input,  validate, normalize, encode,
 format, and display.


Remark: This package is needed to upgrade r-cran-tibble to the new
 upstream version 1.4.1.  It will be maintained by the r-pkg-team at
 https://salsa.debian.org/r-pkg-team/r-cran-utf8.git

Bug#887092: nm.debian.org: provide a button to push back hide_until date

[Mattia Rizzolo]

Package: nm.debian.org

My use case as usual is with dd_e/dd_r processes: I just pinged a dd_r
process and I'd like it to be hidden for at least 2 weeks.
I'd like to have a button to do so.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#886942: Further information

[Martin King]

Further information in two parts, my own experience and a separate bug report.

Part 1.
My PC is a new Intel NUC7i5BNH with both an SSD and HDD. Debian 9 Stretch is 
installed on both drives, two bootable copies. The EFI timeout pre-configured 
by Intel was 1 second.

It is clear from web pages and on-line forums that others have successfully 
used efibootmgr -t. I wondered if it would work with another Distro. I made a 
live USB of current releases;

Fedora Workstation V27 (efibootmgr version 15)
Ubuntu Desktop 16.04 (efibootmgr version 0.12)

I had the same failure of efibootmgr with both.

I then wondered if the problem only affected current releases so tried an old 
release;
Ubuntu Desktop 14.04 (efibootmgr version 0.5.4)

With Ubuntu 14.04, efibootmgr -t worked. Things then got stranger.

After re-booting into Debian from my SSD efibootmgr -t still worked. I tried 
again when booted into Debian from HDD, efibootmgr again still worked.

Did Ubuntu 14.04 change something in the NUC's firmware that allows Debian to 
now work?

efibootmgr continued to work until I set the timeout back to 1 second, after 
which the original fault recurred. I then had to reboot from Ubuntu 14.04 and 
set the timeout to something other than 1 second to recover functionality in 
Debian.

Part 2.
I found another bug report that describes the same symptoms as I experience but 
logged against efivar. See;

https://github.com/rhboot/efivar/issues/95

In Conclusion.
Reproducing the fault may require a combination of firmware/EFI state and OS 
utility versions.

Bug#870445: libglvnd: FTBFS on non-Linux: u_execmem_free undefined

[Samuel Thibault]

Control: tags -1 forwarded https://github.com/NVIDIA/libglvnd/pull/142

Julien Cristau, on sam. 13 janv. 2018 13:34:32 +0100, wrote:
> On Sat, Jan 13, 2018 at 10:35:48 +0100, Samuel Thibault wrote:
> > Andreas Beckmann, on sam. 25 nov. 2017 16:41:41 +0100, wrote:
> > > attached are two patches to fix this FTBFS.
> > > Build-tested on falla and exodar.
> > 
> > I have uploaded the attached debdiff to DELAYED/5.
> > 
> Was the patch ever sent upstream?

The patch was apparently commited to the Debian repository without an
upstream submission.  I have pushed it as a pull request.

Samuel

Bug#887100: geeqie: Orientation controls do nothing

[sleibt]

Package: geeqie
Version: 1:1.4-3
Severity: normal

Dear Maintainer,

In Geeqie 1.4, Edit/Orientation/Rotate (but also flip, mirror) have no effect.

Downgrading geeqie and geeqie-common to the version from stable (1:1.3-1+b1 and 
1:1.3-1, respectively) sorts the problem.  

Tested with both PNGs and JPEGs, using menu or right-click.

Starting with --debug=9, those are the lines that are printed when clicking 
"rotate clockwise":

*** version 1.4: ***

filecache.c:file_cache_get:72:cache hit: fc=0x55b874d97d50 
/tmp/geeqie/Geeqie_-_Logo.png
metadata.c:metadata_cache_remove:156:not removed Xmp.tiff.Orientation 
/tmp/geeqie/Geeqie_-_Logo.png

filedata.c:file_data_ref_debug:589:file_data_ref fd=0x55b874ee25a0 (8): 
'/tmp/geeqie/Geeqie_-_Logo.png' @ metadata.c:195
filedata.c:file_data_unref_debug:693:file_data_unref fd=0x55b874ee25a0 (7:0): 
'/tmp/geeqie/Geeqie_-_Logo.png' @ filedata.c:1401
layout_image.c:layout_image_focus_in_cb:1694:image activate focus_in 0

*** version 1.3: ***

metadata.c:156: not removed Xmp.tiff.Orientation /tmp/geeqie/Geeqie_-_Logo.png

filedata.c:563: file_data_ref fd=0x563e71fbb9e0 (8): 
'/tmp/geeqie/Geeqie_-_Logo.png' @ metadata.c:195
renderer-tiles.c:1516: redraw priority: 2pass
pixbuf-renderer.c:1274:11.195391 (+00010.873120) pixbuf renderer updated - 
started drawing 0x563e71d3e050, img: 70x200
filedata.c:666: file_data_unref fd=0x563e71fbb9e0 (7:0): 
'/tmp/geeqie/Geeqie_-_Logo.png' @ filedata.c:1320
layout_image.c:1394: image activate focus_in 0
renderer-tiles.c:1516: redraw priority: 2pass
*** [SNIP many identical lines] ***
renderer-tiles.c:1516: redraw priority: 2pass
pixbuf-renderer.c:1302:11.241367 (+0.045976) pixbuf renderer done 
0x563e71d3e050


It looks like pixbuf-renderer and renderer-tiles are not called anymore, which 
might have something to do with this problem.

Anyway, thanks for a usefull piece of software.

Sebastien

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

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

Versions of packages geeqie depends on:
ii  geeqie-common1:1.4-3
ii  libatk1.0-0  2.26.1-2
ii  libc62.26-3
ii  libcairo21.15.8-3
ii  libexiv2-14  0.25-3.1
ii  libfontconfig1   2.12.6-0.1
ii  libfreetype6 2.8.1-1
ii  libgcc1  1:7.2.0-19
ii  libgdk-pixbuf2.0-0   2.36.11-1
ii  libglib2.0-0 2.54.3-1
ii  libgtk2.0-0  2.24.31-5
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  liblcms2-2   2.9-1
ii  liblirc-client0  0.10.0-2+b1
ii  liblua5.1-0  5.1.5-8.1+b2
ii  libpango-1.0-0   1.40.14-1
ii  libpangocairo-1.0-0  1.40.14-1
ii  libpangoft2-1.0-01.40.14-1
ii  libstdc++6   7.2.0-19
ii  libtiff5 4.0.9-3

Versions of packages geeqie recommends:
ii  cups-bsd [lpr]   2.2.6-4
ii  exiftran 2.10-2+b3
ii  exiv20.25-3.1
ii  imagemagick  8:6.9.7.4+dfsg-16
ii  imagemagick-6.q16 [imagemagick]  8:6.9.7.4+dfsg-16
ii  librsvg2-common  2.40.20-2
ii  ufraw-batch  0.22-2
ii  zenity   3.26.0-2

Versions of packages geeqie suggests:
pn  geeqie-dbg   
ii  gimp 2.8.20-1.1
ii  libjpeg-turbo-progs [libjpeg-progs]  1:1.5.2-2+b1
pn  ufraw
pn  xpaint   

-- no debconf information

Bug#701484: reportbug: "/usr/share/bug/nis/script: 7: yesno: not found"

[Nis Martensen]

control: tags -1 patch

The yesno command is provided as a bash function by reportbug itself,
and only available to bug scripts written as bash scripts.  This is
documented in /usr/share/doc/reportbug/README.developers.gz.

This small change fixes this bug, and #772282 as well:


diff --git a/debian/reportbug-script b/debian/reportbug-script
index 18fcf3e..2e65c30 100644
--- a/debian/reportbug-script
+++ b/debian/reportbug-script
@@ -1,4 +1,4 @@
-#!/bin/sh -e
+#!/bin/bash -e

 if [ -z "$YESNO" ]; then
   YESNO=$"yYnN"

Bug#887105: RFP: python3-flake8-blind-except -- A flake8 extension that checks for blind, catch-all except statements

[Jeff Cliff]

Package: wnpp
Severity: wishlist

* Package name: python3-flake8-blind-except
  Version : 0.1.1
  Upstream Author : Elijah Andrews
* URL : https://github.com/elijahandrews/flake8-blind-except
* License : MIT 
https://github.com/elijahandrews/flake8-blind-except/blob/master/LICENSE
  Programming Lang: Python
  Description : A flake8 extension that checks for blind, catch-all except 
statements

A flake8 extension that checks for blind, catch-all except: statements.

Using except without explicitly specifying which exceptions to catch is 
generally considered bad practice, since it catches system signals like SIGINT. 
You probably want to handle system interrupts differently than exceptions 
occuring in your code.

It's also usually better style to have many small try-except blocks catching 
specific exceptions instead of a giant try: block with a catch-all except: at 
the bottom. It's also nicer to your fellow programmers to be a bit more 
specific about what exceptions they can expect in specific parts of the code, 
and what the proper course of action is when they occur.

Bug#887107: [debian-i18n] https://i18n.debian.org/material/data/unstable.gz not updated since 2017-11-23

[Laura Arjona Reina]

Package: debian-i18n
Severity: normal
X-Debbugs-CC: debian-...@lists.debian.org

Dear i18n/l10n team

I've seen that this .po file is up-to-date:

https://i18n.debian.org/material/po/unstable/main/d/django-allauth/allauth/locale/es/LC_MESSAGES/django-allauth_0.34.0-2_django.po.gz

Date: 2018-01-13 14:40

But the list of packages is not:

https://i18n.debian.org/material/data/unstable.gz

Date: 2017-11-23 14:33

(e.g. that unstable.gz file contains a link to
https://i18n.debian.org/material/po/unstable/main/d/django-allauth/allauth/locale/es/LC_MESSAGES/django-allauth_0.33.0-1_django.po.gz
which does not exist anymore).
So, I think something is failing in the script that generate the
translation material daily. Looking at the git repo, I think the script
that fails is this one:

https://anonscm.debian.org/cgit/debian-l10n/dl10n.git/tree/cron/gen-material

I've looked at tye.debian.org and I can find error log files in
/srv/i18n.debian.org/log/gen-material/ every day since 2017-11-23 but I
have no idea about which one is the one breaking the process, and how to
fix it. I attach today's log error (summarized, deleting the repeated
messages).

I believe this issue is causing some pages in the Debian website (some
of the "Status of PO files for language code" pages,
https://www.debian.org/international/l10n/po/xx.yy.html) to show
outdated info and broken links. There is also a validation error caused
by a bad encoded character in a .po file, which is fixed in the
corresponding package (django-allauth, bug #881727), but still present
in the website due to the pages not being rebuilt because the material
is not updated. For this reason I will disable validation checking in
the problematic languages and will enable it again when this bug is fixed.

If I can be of any help, just tell.

Thanks
--
Laura Arjona Reina
https://wiki.debian.org/LauraArjona