Bug#864858: strace: Please don't do unaligned access in the testsuite on ARM

[Steve Langasek]

Package: strace
Version: 4.15-2
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu artful ubuntu-patch

Hi Steve,

As you're probably aware, unaligned access on ARM is not guaranteed to
succeed; depending on the CPU and the kernel configuration, in may raise
SIGBUS instead.

The strace test suite avoids unaligned accesses for POWER and Sparc, but for
other archs, including ARM, it deliberately tests with unaligned access. 
This is not a problem on Debian's builders, but it is on Ubuntu's. 
Therefore, I've uploaded the attached patch to Ubuntu.

Please consider whether this is appropriate to apply in Debian as well.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru strace-4.15/debian/patches/no-arm-unaligned-access 
strace-4.15/debian/patches/no-arm-unaligned-access
--- strace-4.15/debian/patches/no-arm-unaligned-access  1969-12-31 
16:00:00.0 -0800
+++ strace-4.15/debian/patches/no-arm-unaligned-access  2017-06-15 
21:57:38.0 -0700
@@ -0,0 +1,18 @@
+Description: Don't allow unaligned access on ARM in the tests
+ The testsuite already handles alignment requirements on POWER and Sparc, add
+ ARM to the list as well.  Not all ARM enviroments raise SIGBUS on unaligned
+ access, but some (including the Ubuntu autobuilders) do.
+Author: Steve Langasek 
+Last-Update: 2017-06-16
+
+--- strace-4.15.orig/tests/perf_event_open.c
 strace-4.15/tests/perf_event_open.c
+@@ -500,7 +500,7 @@ end:
+ }
+ 
+ /* These require aligned access, so no byte-grain checks possible */
+-# if defined SPARC || defined SPARC64 || defined POWERPC || defined POWERPC64
++# if defined SPARC || defined SPARC64 || defined POWERPC || defined POWERPC64 
|| defined ARM
+ #  define ATTR_REC(sz) { tail_alloc((sz + 7) & ~7), sz }
+ # else
+ #  define ATTR_REC(sz) { tail_alloc(sz), sz }
diff -Nru strace-4.15/debian/patches/series strace-4.15/debian/patches/series
--- strace-4.15/debian/patches/series   2017-01-19 06:02:56.0 -0800
+++ strace-4.15/debian/patches/series   2017-06-15 21:57:38.0 -0700
@@ -1,1 +1,2 @@
 disable-failing-tests.patch
+no-arm-unaligned-access

Bug#849273: RFS: gemmlowp/0~20170407-g719389f-1 [ITP]

[Ying-Chun Liu (PaulLiu)]

On 2017年06月16日 12:33, Ying-Chun Liu (PaulLiu) wrote:
> Hi Lumin,
> 
> I've reviewed your package. The package looks quite good to me.
> The only thing missing is the README.source
> https://www.debian.org/doc/debian-policy/ch-source.html#s-readmesource
> 
> The orig.tar.gz seems to be repacked from upstream git repo.
> Please mention the steps on how you create the orig.tar.gz
> Like you git clone it. And re-tar it, exclude some directories like .git.
> 
> Or, provide a way to generate the orig.tar.gz by debian/rules
> get-orig-source
> 
> For example, added these to debian/rules
> DEB_SOURCE := $(shell dpkg-parsechangelog | grep Source: | sed -e
> 's/Source: //'
> )
> DEB_VERSION := $(shell dpkg-parsechangelog | grep Version: | sed -e
> 's/Version: //')
> DEB_UPSTREAM_VERSION := $(shell echo $(DEB_VERSION) | sed -e 's/-[^-]*$$//')
> GIT_URL = https://github.com/google/gemmlowp.git
> 
> get-orig-source:
> set -e; if echo $(DEB_VERSION) | grep -c "git"; \
> then \
> git_version=`echo $(DEB_VERSION) | sed -e
> 's/^.*~\([0-9]*\)*-\(.*\)-.*$$/\2/g'`; \
> else \
> git_version=$(DEB_UPSTREAM_VERSION); \
> fi; \
> tmpdir=`mktemp -d -t`; \
> cd $$tmpdir; \
> echo "checkout upstream repository ..."; \
> git clone $(GIT_URL); echo "getting specific upstream
> revision/tag: $$git_version"; \
> cd `ls | head -n 1`; git checkout -b orig $$git_version; cd ..; \
> tar --exclude=.git --exclude='*.exe' --exclude='*.jar' -cJvf
> $(CURDIR)/$(DEB_SOURCE)_$(DEB_UPSTREAM_VERSION).orig.tar.xz `ls | head
> -n 1`; \
Sorry, please update this line to

tar --exclude=.git --exclude='*.exe' --exclude='*.jar' -czvf
$(CURDIR)/$(DEB_SOURCE)_$(DEB_UPSTREAM_VERSION).orig.tar.gz `ls | head
-n 1`; \

because you use .tar.gz

> cd $(CURDIR); \
> rm -rf $$tmpdir
> 
> so when developer wants to pack the source tarball from the upstream,
> they can use debian/rules get-orig-source.
> 
> Either one way is ok. After that, I'll sponsor your package.
> 
> BTW,
> I also have projects that needs tensorflow to be packaged into Debian.
> If you have any further tensorflow related packages you can directly
> mail me. Also I'm willing to help packaging those stuff.
> 
> Yours Sincerely,
> Paul
> 
> 


-- 
PaulLiu (劉穎駿)
E-mail: Ying-Chun Liu (PaulLiu) 



signature.asc
Description: OpenPGP digital signature

Bug#849273: RFS: gemmlowp/0~20170407-g719389f-1 [ITP]

[Ying-Chun Liu (PaulLiu)]

Hi Lumin,

I've reviewed your package. The package looks quite good to me.
The only thing missing is the README.source
https://www.debian.org/doc/debian-policy/ch-source.html#s-readmesource

The orig.tar.gz seems to be repacked from upstream git repo.
Please mention the steps on how you create the orig.tar.gz
Like you git clone it. And re-tar it, exclude some directories like .git.

Or, provide a way to generate the orig.tar.gz by debian/rules
get-orig-source

For example, added these to debian/rules
DEB_SOURCE := $(shell dpkg-parsechangelog | grep Source: | sed -e
's/Source: //'
)
DEB_VERSION := $(shell dpkg-parsechangelog | grep Version: | sed -e
's/Version: //')
DEB_UPSTREAM_VERSION := $(shell echo $(DEB_VERSION) | sed -e 's/-[^-]*$$//')
GIT_URL = https://github.com/google/gemmlowp.git

get-orig-source:
set -e; if echo $(DEB_VERSION) | grep -c "git"; \
then \
git_version=`echo $(DEB_VERSION) | sed -e
's/^.*~\([0-9]*\)*-\(.*\)-.*$$/\2/g'`; \
else \
git_version=$(DEB_UPSTREAM_VERSION); \
fi; \
tmpdir=`mktemp -d -t`; \
cd $$tmpdir; \
echo "checkout upstream repository ..."; \
git clone $(GIT_URL); echo "getting specific upstream
revision/tag: $$git_version"; \
cd `ls | head -n 1`; git checkout -b orig $$git_version; cd ..; \
tar --exclude=.git --exclude='*.exe' --exclude='*.jar' -cJvf
$(CURDIR)/$(DEB_SOURCE)_$(DEB_UPSTREAM_VERSION).orig.tar.xz `ls | head
-n 1`; \
cd $(CURDIR); \
rm -rf $$tmpdir

so when developer wants to pack the source tarball from the upstream,
they can use debian/rules get-orig-source.

Either one way is ok. After that, I'll sponsor your package.

BTW,
I also have projects that needs tensorflow to be packaged into Debian.
If you have any further tensorflow related packages you can directly
mail me. Also I'm willing to help packaging those stuff.

Yours Sincerely,
Paul


-- 
PaulLiu (劉穎駿)
E-mail: Ying-Chun Liu (PaulLiu) 



signature.asc
Description: OpenPGP digital signature

Bug#864597: upgrade-reports: jessie -> stretch: gnome fails to upgrade: cycle found while processing triggers

[Guillem Jover]

Hi!

On Fri, 2017-06-16 at 03:34:06 +0200, gregor herrmann wrote:
> On Fri, 16 Jun 2017 01:38:28 +0200, Guillem Jover wrote:
> 
> > > Same as above, except that after 3) I did
> > > 
> > > 3a) sed -i -e 's/interest /interest-noawait /' 
> > > /var/lib/dpkg/info/{desktop-file-utils,shared-mime-info}.triggers
> > > 
> > > and after 6) I again ran
> > > 
> > > 6a) sed -i -e 's/interest /interest-noawait /' 
> > > /var/lib/dpkg/info/{desktop-file-utils,shared-mime-info}.triggers
> > 
> > The important file to modify in addition is actually
> > /var/lib/dpkg/triggers/File, "/noawait" would need to be appended to
> > the relevant lines. The individual .triggers files for this scenario are
> > pretty much just parsed on unpack and removals.
> 
> Oops, that's what you get when amateurs dabble around.
> Thanks for filling in my incomplete knowledge!

It's very possible that the internal documentation at
/usr/share/doc/dpkg-dev/triggers.txt.gz is not very clear on this
subject, and I'd be happy to clarify it!

> Ok, let's try again:
> 
> 1) enter a jessie cowbuilder chroot
> 2) rm /etc/apt/apt.conf.d/15pbuilder
> 3) apt-get install task-gnome-desktop
> 3a) sed -i -e 's/interest /interest-noawait /' 
> /var/lib/dpkg/info/{desktop-file-utils,shared-mime-info}.triggers
> 3b) sed -i -e 's;desktop-file-utils;desktop-file-utils/noawait;' -e 
> 's;shared-mime-info;shared-mime-info/noawait;' /var/lib/dpkg/triggers/File
> 
> 4) sed -i -e 's/jessie/stretch/g' /etc/apt/sources.list
> 5) apt-get update
> 6) apt-get upgrade
> 6a) sed -i -e 's/interest /interest-noawait /' 
> /var/lib/dpkg/info/{desktop-file-utils,shared-mime-info}.triggers
> 6b) sed -i -e 's;desktop-file-utils;desktop-file-utils/noawait;' -e 
> 's;shared-mime-info;shared-mime-info/noawait;' /var/lib/dpkg/triggers/File
> 7) apt-get dist-upgrade
> 
> Result:
[…]

Hmm, and thanks for the retest!

> It might well be that I again did something wrong. OTOH, this seems to
> match what anbe wrote of his similar tests some minutes ago.

So, I didn't try to reproduce the error first, and went directly for
a hunch. I followed your recipe, but in steps 3* and 6* I also amended
hicolor-icon-theme. And that seemed to fix the upgrade. Take into
account I've not had the time to analyze the dependency chain, nor if
my initial setup (not using cowbuilder, etc) matches, so maybe this is
an error in procedure. If someone else can reproduce, that'd be helpful,
otherwise I might retry tomorrow.

If this does fix it, it might be helpful also to try just amending the
triggers in the stretch "mock", instead of in the jessie one, to see if
such a fixed package would be enough.

Thanks,
Guillem

Bug#864857: [patch] avoid blhc warning about -fPIE

[Vincent McIntyre]

Package: autofs
Severity: wishlist
Version: 5.1.2-2
Tags: patch

thanks

Not sure this one is needed, use it or not as you please.

Signed-off-by: mci156 
---
 debian/patches/hardening-flags.patch | 20 
 debian/patches/series|  1 +
 2 files changed, 21 insertions(+)
 create mode 100644 debian/patches/hardening-flags.patch

diff --git a/debian/patches/hardening-flags.patch 
b/debian/patches/hardening-flags.patch
new file mode 100644
index 000..f6e2350
--- /dev/null
+++ b/debian/patches/hardening-flags.patch
@@ -0,0 +1,20 @@
+Last Updated: 2017-06-16
+Author: Vincent McIntyre 
+Forwarded: no
+Description: Avoid warning about -fPIE from blhc
+
+This is probably not entirely necessary since all modules are
+compiled with -fPIE, but it avoids a warning.
+Index: autofs-5.1.2/daemon/Makefile
+===
+--- autofs-5.1.2.orig/daemon/Makefile
 autofs-5.1.2/daemon/Makefile
+@@ -30,7 +30,7 @@ endif
+ all: automount
+ 
+ automount: $(OBJS) $(AUTOFS_LIB)
+-   $(CC) $(DAEMON_LDFLAGS) -o automount $(OBJS) $(LDFLAGS) $(AUTOFS_LIB) 
$(LIBS)
++   $(CC) $(DAEMON_CFLAGS) $(DAEMON_LDFLAGS) -o automount $(OBJS) 
$(LDFLAGS) $(AUTOFS_LIB) $(LIBS)
+$(STRIP) automount
+ 
+ clean:
diff --git a/debian/patches/series b/debian/patches/series
index 91208ef..e8163b9 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,3 +1,4 @@
+hardening-flags.patch
 11default_automaster_location.patch
 12disable_default_auto_master.patch
 15auto_net_nfs4.patch
-- 
2.1.4

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

[Ryan Tandy]

On Wed, Jun 14, 2017 at 09:06:20PM +0200, Karsten Heymann wrote:

1. There is already code in openldap that maps dn's to paths in the
cn=config backend when it writes the config tree to the file system in
/etc/ldap/slapd.d. Maybe that code or at least its escaping logic can
be reused.


There is. It uses \ as an escape character, which is likely to expose 
more bugs like this one, but that's probably a good thing as those are 
just lurking right now.


I'm more inclined to delete unsafe characters outright than escape them, 
I think, or maybe replace them with - or some other placeholder.



2. Wouldn't it be enough to use the database *number* to uniquely name
the database backup? This would remove the whole problem.
3. In order to use the basedn as a file name that can be safely used
in shell script, what about a whitelist approach that replaces or
encodes any character that is not a (ascii) letter, number, dash or
underscrore with something safe/sane? Seems a better way than the
approach where only certain "bad" characters are replaced. Unicode is
huge, and using a whitelist of known good characters seems a more
defensive approach, especially when prefixed with the database number.
So "o=|\/|y Über Company" would become something like
"db2-yberCompany".


I've thought about both of these, and indeed I think I'm converging on 
something like your last suggestion in order to maintain some kind of 
tradeoff between robustness and readability. The tricky parts are 
guaranteeing uniqueness (in case of two suffixes normalizing to the same 
string), and ensuring upgrades still work when the algorithm changes 
(the old algorithm needs to be kept, and used as a fallback if an 
expected file isn't found).


I already intended to change the maintainer scripts to process databases 
using the number as the key, instead of the suffix. This is just another 
reason to move in that direction.


SMOP and tuits as usual...

Thanks to both of you for the thoughts and suggestions.

Bug#864840: error: cannot overload functions distinguished by return type alone version graph

[Lumin]

Control: tags -1 +wontfix

Hi,

> The header file math_functions.h is not compatible with gcc 6.3 shipped with 
> stretch.

Actually CUDA 8.0.44 does not support GCC-6 at all. Lookup this document for
working compiler combinations:

  /usr/share/doc/nvidia-cuda-toolkit/README.Debian

I'd suggest that (1) compile the application with clang-3.8 (shipped
by stretch).
OR (2) temporarily add the sid/unstable apt source, pull GCC-5 then remove
that apt source and compile with GCC-5. OR (3) Get GCC-5/clang-3.8 by other
approaches.

We can do nothing to change the fact, hence marking this bug as wontfix.

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

[Ryan Tandy]

On Wed, Jun 14, 2017 at 12:59:04PM +0200, Thorsten Glaser wrote:

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


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

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

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


Agreed on all points. The code that uses backticks and grep|cut|sed is 
mostly from before my time. I don't have the energy for a wholesale 
update of the code style, but I'm updating pieces to a style like you 
suggest as I touch them. The diff was meant as an example of a very 
minimal change that would be suitable for backporting to stable, or 
applying to a customer system in your case.


I have to check more closely but I think the lack of quoting around the 
second grep may be intentional. I have a vague recollection of a case 
where it was valid to have multiple databases configured for the same 
suffix.



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


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

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


Possibly less portable, but for scripts targeted at Debian I've 
generally used a perl one-liner:


perl -00 -pe 's/\n[ \t]//g; s/^#.*\n//mg' "$@"

In any case I'm trying to (gradually...) update the maintainer scripts 
to use slapcat instead of parsing the config backend files directly, 
which comes with a '-o ldif-wrap=no' option.

Bug#864597: upgrade-reports: jessie -> stretch: gnome fails to upgrade: cycle found while processing triggers

[Andreas Beckmann]

On 2017-06-16 03:34, gregor herrmann wrote:
> (Reading database ... 132342 files and directories currently installed.)
> Removing openjdk-7-jre:amd64 (7u111-2.6.7-1~deb8u1) ...
> Removing openjdk-7-jre-headless:amd64 (7u111-2.6.7-1~deb8u1) ...
> Removing tzdata-java (2017b-0+deb8u1) ...
> Processing triggers for hicolor-icon-theme (0.15-1) ...
> dpkg: cycle found while processing triggers:
>  chain of packages whose triggers are or may be responsible:
>   gnome-menus -> desktop-file-utils
>  packages' pending triggers which are or may be unresolvable:
>   gnome-menus: /usr/share/applications
>   shared-mime-info: /usr/share/mime/packages
>   desktop-file-utils: /usr/share/applications
>   mime-support: /usr/share/applications
> dpkg: error processing package gnome-menus (--remove):
>  triggers looping, abandoned
> Processing triggers for desktop-file-utils (0.23-1) ...
> Processing triggers for mime-support (3.60) ...
> Errors were encountered while processing:
>  gnome-menus
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> 
> It might well be that I again did something wrong. OTOH, this seems to
> match what anbe wrote of his similar tests some minutes ago.

It was easier than I thought to do this with piuparts, and I can confirm
gregors test result with "real packages".
Full log, including dpkg trigger debug info:
https://people.debian.org/~anbe/864597/tgd.101-dfu89-smi89.log

it used for jessie:
  desktop-file-utils_0.22-1+deb8noawait_amd64.deb
  shared-mime-info_1.3-1+deb8noawait_amd64.deb
and for stretch:
  desktop-file-utils_0.23-1+test_amd64.deb
  shared-mime-info_1.8-1+test_amd64.deb
(all with s/interest/interest-noawait/ in debian/triggers)

Andreas

Bug#861989: nautilus: Nautilus freezes/crashes when right clicking and selecting properties for 1 or more files

[Luke Christopher Clarke]

Hello Jason,

Sorry for lack of reply. Been away from my computer.

I can confirm that I do have a lot of photos in RAW format about 25Mb each.
However once I have finished with the images I then move them to a external
hard drive.

I will hopefully run the commands tonight.

Regards
Luke

On Fri, Jun 16, 2017 at 6:31 AM, Jason Crain 
wrote:

> Control: reassign -1 tracker-gui 1.2.4-2
> Control: tags -1 - moreinfo
> Control: found -1 1.10.5-1
>
> On Sun, Jun 11, 2017 at 02:31:33PM -0500, Jason Crain wrote:
> > How large is your tracker database ~/.cache/tracker/meta.db?  Do you
> > have gigabytes of documents being indexed that would inflate the
> > database?
>
> I'm going to assume the answer to this is yes, you have gigabytes of
> PDFs and PowerPoint presentations causing a large tracker database.
>

Bug#863388: live-boot: Added new functionality to live-boot: rootcopy, modularized filesystems, package installer

[William Prochazka]

Ahhh, a thousand apologies as my original submission didn't make it clear.
The module stuff is all related to using the toram function.  When using
toram, the module function doesn't work as expected.

If you specify "toram=something.module" (not documented in man page, but
the arg is parsed into MODULETORAM), it assumes this is a single squashfs
filesystem, not a module file (maybe just confusion with what a "module"
is).
If you specify "module=foo toram", it ignores any foo.module and tries to
copy the whole live directory.  Maybe then it honors the module file, but I
never get that far as I run out of RAM ;)

I can clean up the patch but the additions to the toram file check to see
if:
a) module = something and  toram, then calculate size based on the sum of
the parts in the module file and only copy those parts to ram, then
continue as before.

The normal behavior for toram=filesystem.squashfs is kept and toram without
a "module=" is also kept as before...really just takes care of loading a
module into ram.

I concede that I didn't realize the module file could include a raw
directory since the man page refers to disk images.  It is a bit of a pain
to make a module file for each bootable filesystem you may want, but I can
make due with that if you don't like the actual rootcopy cheatcode.  I
might also point out that I would bet many people are unaware of this
feature since it is buried in the module functions and not well explained
in the man page, but thanks for clearing that up.

On Fri, 16 Jun 2017 00:47:56 +0300 Mert Dirik  wrote:
>
> On Wed, 14 Jun 2017 01:48:05 + William Prochazka wrote:
>  > Well,
>  >
>  > 1. Root copy is not a squashfs filesystem, so it allows for quick
> tweaking
>  > and modification without having to "commit" your changes. This also
makes
>  > modifications (for the purpose of troubleshooting) much easier.
>  >
>  > 2. The alternative filesystem module is still a single file. The new
>  > feature allow for the specification and ordering of filesystem modules.
>  > For example, imagine the following:
>  > filesyste A contains all necessary files to boot a system into a basic
>  > shell with basic functionality, nothing more. Branch filesystem B
> contains
>  > a bunch of advanced tools (coimpilers, scripting environments, etc.
> Branch
>  > filesystem C contains X and Branch Filesystem D contains all of the X
> Bloat
>  > applications.
>  > Together, all four branches are roughly the size that the one
> "monolithic"
>  > filesystem D would have been if I wanted to use the legacy modules
>  > directive, but now, I have a boot time option to specify if I want
just A
>  > for a tiny system, (A and B) for more functionality, (A, B, and C) for
a
>  > GUI, or (A, B, C, and D) for all of the bells and whistle. Now I get
all
>  > of that and don't have four copies of the filesystem. Furthermore, if I
>  > then add a file to A, It will be present when booting into D due to
>  > squashfs.
>  >
>  > It is really nice.
>
> I'm still not getting it. You can accomplish all of these with the
> existing module functionality.
>
> Modules don't have to be squashfs files. They can also be regular
> directories. You can modify them freely. You can use them in the exact
> same way you use overlay directories, because they end up being just
> another layer of  the overlayfs mount. You can mix and match modules
> using *.module files or change their ordering, because they are just
> overlays. You can also select different *.module files with boot
parameters.
>
> Sorry if I still miss something obvious but this seems to cover all
> functionality you've brought so far.
>
>

Bug#864851: firefox-esr: Please revert to Gtk+ 2.0

[Pierre Ynard]

Hello,

> We should definitely follow testing/sid here and continue to use GTK3,

I'm not sure what you mean, because testing/sid has been using GTK2
until two days ago. According to the changelog, GTK3 was last enabled
in:

firefox (49.0-5) unstable; urgency=medium
[...]
  * debian/rules, debian/control: Re-enable Gtk+3 to see how it goes.
Closes: #832301.
[...]
 -- Mike Hommey   Sat, 29 Oct 2016 19:54:35 +0900

And #832301 requested:

> Shouldn't the GTK3 support be reenabled in the experimental version?
> That would be intresting to debug the remaining issues with GTK3

And indeed the GTK3-enabled 52 ESR was only in experimental, until the
upload to unstable two days ago. My system has been installed back when
it was still iceweasel and is running unstable, and I believe I've never
had to upgrade to a GTK3 version of Firefox.

So my understanding of the situation seems a bit different. What I'd
like to continue with is GTK2. And in fact I mean on unstable, not
just jessie. At least this would easily solve the question of jessie
diverging from unstable.

I think I understand that 52 ESR is supposed to make it into stretch?
But conversely, do you not worry about forcing a GTK version change this
late in stretch? And do you not worry about forcing a GTK version change
this late in jessie? This jessie maintenance update will trigger in some
cases the installation of a big bunch of new packages, and some people
won't be happy about that happening on stable.

I don't want to use GTK3 on my system because of the reasons you can
imagine, and in fact my system works fine without GTK3 even installed.
Is there a plan to drop all GTK2 apps and migrate them to GTK3? Is there
a plan to drop GTK2 for Firefox? It sure looks like that was not the
purpose when GTK3 was enabled.

If there is no such plan, can we please continue being provided with
GTK2-only Firefox packages? Personally, I'm just not upgrading to this.
Some applications offer split GTK2 and GTK3 binary packages, would that
be an option? Is 45 ESR end-of-life, can security fixes still not be
backported because trademarks, to that well-tested GTK2 build?

Is it also true that 52 is dropping ALSA and mandating PulseAudio?
There's certainly a demand for classic lightweight, minimalist,
no-plumbing-bloat desktop experience; will people have to switch web
browsers too to achieve that?

I've enjoyed your maintainership, and I dearly hope we can keep enjoying
such builds of Firefox.

Best regards,

-- 
Pierre Ynard
"Une âme dans un corps, c'est comme un dessin sur une feuille de papier."

Bug#864597: upgrade-reports: jessie -> stretch: gnome fails to upgrade: cycle found while processing triggers

[gregor herrmann]

On Fri, 16 Jun 2017 01:38:28 +0200, Guillem Jover wrote:

> > Same as above, except that after 3) I did
> > 
> > 3a) sed -i -e 's/interest /interest-noawait /' 
> > /var/lib/dpkg/info/{desktop-file-utils,shared-mime-info}.triggers
> > 
> > and after 6) I again ran
> > 
> > 6a) sed -i -e 's/interest /interest-noawait /' 
> > /var/lib/dpkg/info/{desktop-file-utils,shared-mime-info}.triggers
> 
> The important file to modify in addition is actually
> /var/lib/dpkg/triggers/File, "/noawait" would need to be appended to
> the relevant lines. The individual .triggers files for this scenario are
> pretty much just parsed on unpack and removals.

Oops, that's what you get when amateurs dabble around.
Thanks for filling in my incomplete knowledge!

Ok, let's try again:

1) enter a jessie cowbuilder chroot
2) rm /etc/apt/apt.conf.d/15pbuilder
3) apt-get install task-gnome-desktop
3a) sed -i -e 's/interest /interest-noawait /' 
/var/lib/dpkg/info/{desktop-file-utils,shared-mime-info}.triggers
3b) sed -i -e 's;desktop-file-utils;desktop-file-utils/noawait;' -e 
's;shared-mime-info;shared-mime-info/noawait;' /var/lib/dpkg/triggers/File

4) sed -i -e 's/jessie/stretch/g' /etc/apt/sources.list
5) apt-get update
6) apt-get upgrade
6a) sed -i -e 's/interest /interest-noawait /' 
/var/lib/dpkg/info/{desktop-file-utils,shared-mime-info}.triggers
6b) sed -i -e 's;desktop-file-utils;desktop-file-utils/noawait;' -e 
's;shared-mime-info;shared-mime-info/noawait;' /var/lib/dpkg/triggers/File
7) apt-get dist-upgrade

Result:

(Reading database ... 132342 files and directories currently installed.)
Removing openjdk-7-jre:amd64 (7u111-2.6.7-1~deb8u1) ...
Removing openjdk-7-jre-headless:amd64 (7u111-2.6.7-1~deb8u1) ...
Removing tzdata-java (2017b-0+deb8u1) ...
Processing triggers for hicolor-icon-theme (0.15-1) ...
dpkg: cycle found while processing triggers:
 chain of packages whose triggers are or may be responsible:
  gnome-menus -> desktop-file-utils
 packages' pending triggers which are or may be unresolvable:
  gnome-menus: /usr/share/applications
  shared-mime-info: /usr/share/mime/packages
  desktop-file-utils: /usr/share/applications
  mime-support: /usr/share/applications
dpkg: error processing package gnome-menus (--remove):
 triggers looping, abandoned
Processing triggers for desktop-file-utils (0.23-1) ...
Processing triggers for mime-support (3.60) ...
Errors were encountered while processing:
 gnome-menus
E: Sub-process /usr/bin/dpkg returned an error code (1)


It might well be that I again did something wrong. OTOH, this seems to
match what anbe wrote of his similar tests some minutes ago.


(Disclaimer:
I don't think this is any help for the imminent release, I was just
curious about this trigger issue and thought I'd try it out.
And since, according to his last mail, KiBi's "fix" on the java side
seems to allow for a working upgrade, there's probably also no
urgency to dig deeper into this trigger puzzle.)


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Janis Joplin: Farewell Song


signature.asc
Description: Digital Signature

Bug#864597: upgrade-reports: jessie -> stretch: gnome fails to upgrade: cycle found while processing triggers

[Andreas Beckmann]

On 2017-06-15 22:31, Niels Thykier wrote:
> Guillem and I have been talking about this over IRC and have a theory.
> 
> Basically, jessie's verison of desktop-file-utils and shared-mime-info
> have "-await" triggers (implicit) which will push other packages into a
> "TRIGGER_PENDING" state.
>   Once they are in that state, the "damage" is done and those other
> packages will no longer satisfy dependencies until the trigger has been
> processed.  Notably, dpkg is unable to /undo/ this state even if the
> trigger changes from -await to -noawait during the upgrade.

I think this theory is wrong. (Unless dpkg keeps packages in
trigger-pending state *after* a successful apt-get upgrade.)

I tested earlier this week the following upgrade path in piuparts:
Upgrade from jessie task-gnome-desktop with --install-recommends to
stretch (but with desktop-file-utils and shared-mime-info switched to
interest-noawait triggers in stretch).
The first (apt-get upgrade) phase upgraded both of these packages as
well as gnome-menues and finished with success. I assume there are no
pending triggers left at this point, and the 3 interesting packages have
noawait triggers.
The second phase (apt-get dist-upgrade) still runs into the trigger cycle.


Andreas

Bug#864788: [pkg-gnupg-maint] Bug#864788: Bug#864788: cache TTL values ignored for smartcard PINs

[Daniel Kahn Gillmor]

On Thu 2017-06-15 21:40:28 +0200, Werner Koch wrote:
> The properties of a smartcard and an on-disk key are very different.  In
> fact a smartcard should be considered another gpg-agent to which
> gpg-agent delegates its operation.

I understand this idea from the implementation perspective, and because
i've been thinking about the GnuPG architecture a lot.

But if a user just wants to plug in a smartcard and "have it Just Work"
then they're going to be surprised to find that caching properties they
were used to before suddenly have disappeared.

Does it make sense to keep this architectural parallel clean, when it
makes the user's mental model more complex?  or would it make sense to
try to map the simpler mental model to the underlying architecture, and
have gpg-agent forward its configuration to the smartcard via scdaemon?

Particularly when the user's configuration says "be more conservative
about caching" it seems unfriendly to ignore that directive when we know
that we could (since the scdaemon access is filtered through gpg-agent
itself).

 --dkgo


signature.asc
Description: PGP signature

Bug#864856: haskell-typed-process: FTBFS: typed-process-test: unknown RTS option: -N

[Aaron M. Ucko]

Source: haskell-typed-process
Version: 0.1.0.0-1
Severity: important
Justification: fails to build from source

Builds of haskell-typed-process failed on several architectures:

  Test suite test: RUNNING...
  typed-process-test: unknown RTS option: -N
  typed-process-test: 
  typed-process-test: Usage:   [+RTS  | -RTS ] ... 
--RTS 
  [...]

So far, this error has occurred on arm64, armel, mips, mips64el,
mipsel, s390x, and the non-release architectures hppa and (presumably)
sparc64.  Could you please pass this option only on architectures that
actually support it?

Thanks!

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

Bug#864855: haskell-say: FTBFS: say-test: unknown RTS option: -N

[Aaron M. Ucko]

Source: haskell-say
Version: 0.1.0.0-1
Severity: important
Justification: fails to build from source

Builds of haskell-say failed on several architectures:

  Test suite test: RUNNING...
  say-test: unknown RTS option: -N
  say-test: 
  say-test: Usage:   [+RTS  | -RTS ] ... --RTS 
  [...]

So far, this error has occurred on arm64, armel, mips, mips64el,
mipsel, s390x, and the non-release architectures hppa and (presumably)
sparc64.  Could you please pass this option only on architectures that
actually support it?

Thanks!

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

Bug#864854: haskell-lambdahack: FTBFS: test: unknown RTS option: -N1

[Aaron M. Ucko]

Source: haskell-lambdahack
Version: 0.5.0.0-1
Severity: important
Justification: fails to build from source

Builds of haskell-lambdahack failed on several architectures:

  Test suite test: RUNNING...
  test: unknown RTS option: -N1
  test: 
  test: Usage:   [+RTS  | -RTS ] ... --RTS 
  [...]

So far, this error has occurred on arm64, armel, mips, mips64el, mipsel,
s390x, and the non-release architecture alpha.  AFAICT, on amd64 (and
presumably other architectures that support -N), -N1 is already the
default, so perhaps you can simply stop setting it explicitly.

At any rate, could you please take a look?

Thanks!

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

Bug#864597: upgrade-reports: jessie -> stretch: gnome fails to upgrade: cycle found while processing triggers

[Cyril Brulebois]

Niels Thykier  (2017-06-15):
> Guillem and I have been talking about this over IRC and have a theory.
> 
> Basically, jessie's verison of desktop-file-utils and shared-mime-info
> have "-await" triggers (implicit) which will push other packages into a
> "TRIGGER_PENDING" state.
>   Once they are in that state, the "damage" is done and those other
> packages will no longer satisfy dependencies until the trigger has been
> processed.  Notably, dpkg is unable to /undo/ this state even if the
> trigger changes from -await to -noawait during the upgrade.
> 
>  * If this holds, then changing the desktop-file-utils and
>shared-mime-info triggers *in stable* to -noawait should make the
>problem go away.
> 
>  * I realise it is unfeasible to implement in Debian by Saturday, but
>it would help us understand the root cause of the problem.
>- Tests to confirm/disprove this would be very welcome.

I can run tests but how is this going to help with a release on saturday?

Anyway, your analysis seems wrong, see below.

> If this holds, then to fully resolve the problem, we will need 3 things:
> 
>  * A stable update to jessie for these two packages migrating to
>-noawait.
> 
>  * An upload targeting stretch for these two packages migrating them to
>-noawait.
> 
>  * A "big magic hammer" work around for stretch for r0
>- OR a release-notes remark to pull upgrades from jessie
>- OR ...
> 
> Obviously, the above possibly ignores some time constraints.
> Furthermore, the only thing remotely resembling a "big magic hammer"
> atm. seems to be #863820, which we are unwilling to do with such short
> notice[1].
>   I know that there was an upload to undo the changes in the java
> packages, but AFAIUI, it basically means that Java will not be upgraded.

That's wrong. The default-jre upgrade still happens, which means java 8
is installed; that just means java 7 can stay around for a little while
longer while the dist-upgrade is happening.

>  The user would explicitly have to install Java 8 and then uninstall the
> now unsupported Java 7 - that seems very unhelpful to me.

Nope. From the gnome upgrade log with ca-certificates-java “fixed”:
| Removing openjdk-7-jre:amd64 (7u111-2.6.7-1~deb8u1) ...
| …
| Removing openjdk-7-jre-headless:amd64 (7u111-2.6.7-1~deb8u1) ...
| …
| Setting up openjdk-8-jre-headless:amd64 (8u131-b11-2) ...
| …
| Setting up default-jre-headless (2:1.8-58) ...
| …
| Setting up openjdk-8-jre:amd64 (8u131-b11-2) ...
| …
| Setting up default-jre (2:1.8-58) ...

While I can't say for sure my ca-certificates-java upload will fix all
upgrade paths, I'm quite confident the current upgrade paths is utterly
broken, and is very much less so afterwards, with no known downsides.

Again, I'm not going to pretend I'll be calling the shots here. But I
really fail to see a simpler way to get a net positive gain on this
topic.


KiBi.


signature.asc
Description: Digital signature

Bug#864853: [patch] fix lintian warning about man/autofs.8

[Vincent McIntyre]

Package: autofs
Severity: wishlist
Version: 5.1.2-2
Tags: patch

thanks

This fixes the warning but the manpage heading now looks pretty ugly
thanks to the infelicitous line-
break

Perhaps removing the @@initdir@@@/ part of the line would be ok?


Signed-off-by: mci156 
---
 debian/patches/fix-whatis.patch | 18 ++
 debian/patches/series   |  1 +
 2 files changed, 19 insertions(+)
 create mode 100644 debian/patches/fix-whatis.patch

diff --git a/debian/patches/fix-whatis.patch b/debian/patches/fix-whatis.patch
new file mode 100644
index 000..386015d
--- /dev/null
+++ b/debian/patches/fix-whatis.patch
@@ -0,0 +1,18 @@
+Author: Vincent McIntyre 
+Forwarded: no
+Description: Reinstate - separator in NAME section, to satisfy lintian
+
+Upstream presumably dropped reference to the init script
+because the page now describes both that and the systemd
+.service file.
+Index: autofs-5.1.2/man/autofs.8.in
+===
+--- autofs-5.1.2.orig/man/autofs.8.in
 autofs-5.1.2/man/autofs.8.in
+@@ -1,5 +1,6 @@
+ .TH AUTOFS 8 "9 Sep 1997"
+ .SH NAME
++@@initdir@@/autofs, autofs.service \-
+ Service control for the automounter
+ .SH SYNOPSIS
+ If a SysV init script system is being used:
diff --git a/debian/patches/series b/debian/patches/series
index 91208ef..6f6cf7a 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,3 +1,4 @@
+fix-whatis.patch
 11default_automaster_location.patch
 12disable_default_auto_master.patch
 15auto_net_nfs4.patch
-- 
2.1.4

Bug#864852: [patch] fix missing dependency on lsb-base

[Vincent McIntyre]

Package: autofs
Severity: normal
Version: 5.1.2-2
Tags: patch

thanks

Lintian marks this as an error, may as well fix it.

Signed-off-by: mci156 
---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 9501d97..0bbca56 100644
--- a/debian/control
+++ b/debian/control
@@ -22,7 +22,7 @@ VCS-Git: 
https://anonscm.debian.org/git/collab-maint/autofs.git
 Package: autofs
 Architecture: any
 Pre-Depends: ${misc:Pre-Depends}
-Depends: ${shlibs:Depends}, ${misc:Depends}, ucf
+Depends: ${shlibs:Depends}, ${misc:Depends}, ucf, lsb-base (>=3.0-6)
 Provides: autofs5
 Breaks: autofs5 (<< 5.0.6-1~)
 Replaces: autofs5 (<< 5.0.6-1~)
-- 
2.1.4

Bug#864851: firefox-esr: Please revert Jessie build to use Gtk+ 2.0

[Moritz Muehlenhoff]

On Fri, Jun 16, 2017 at 08:59:38AM +0900, Mike Hommey wrote:
> This makes sense, but firefox-esr hasn't been tested against gtk+-2.0
> ever, neither on Debian nor on Mozilla end. AFAIK RedHat do such builds,
> but I don't know if they carry extra patches.
> 
> What does the security team think here? We had this discussion in the
> past, but IIRC back then it wasn't a given that building against
> gtk+-2.0 might be a possibility.

We should definitely follow testing/sid here and continue to use GTK3,
even the low level tool chain changes caused unexpected problems in
jessie compared to stretch, also diverging with a UI toolkit which
is not used by upstream would open a whole new can of worms.

Cheers,
Moritz

Bug#864597: upgrade-reports: jessie -> stretch: gnome fails to upgrade: cycle found while processing triggers

[Cyril Brulebois]

Bill Allombert  (2017-06-15):
> It would be really nice if we could remove the circular dependency 
> between openjdk-8 and ca-certificate before the release, otherwise
> the stretch to buster upgrade will be a nightmare.
> It always much easier to add circular dependency than to remove them.

Bill, we're trying to fix/work around a jessie to stretch upgrade path
issue for the default desktop setup. And we're days away from the
tentative date for the release. Needless to say, trying to fix this
upgrade path is somewhat more important than what happens for stretch to
buster, for which years still have to pass. Plenty of time to figure out
what to do.

Of course it would be better if ca-certificates-java wouldn't have been
“fixed” on 2017-05-31 when openjdk-7 was removed on 2016-04-22. But
that's the situation we have to deal with right now.


KiBi.


signature.asc
Description: Digital signature

Bug#864851: firefox-esr: Please revert Jessie build to use Gtk+ 2.0

[Mike Hommey]

On Fri, Jun 16, 2017 at 02:26:26AM +0300, Mert Dirik wrote:
> Package: firefox-esr
> Version: 52.2.0esr-1~deb8u1
> Severity: wishlist
> 
> Dear Maintainer,
> 
> Version 52 of firefox-esr jessie is with gtk+-3.0. I would be glad if you
> reconsider building it with gtk+-2.0.
> 
> Here is my reasoning:
> 
>  - Firefox 52 still can be built with gtk+-2.0
>  - It is the Firefox version to be used until mid 2018.
>  - Jessie is already late in its lifecycle (soon to be oldstable). It will be
> even older in mid 2018.
>  - All the previous Iceweasel and Firefox versions that has been in jessie 
> were
> built with gtk+-2.0
>  - There is no benefit changing the gtk version this late since Stretch 
> release
> is imminent and users who can benefit from using Firefox with gtk+-3.0 can
> upgrade to Stretch
>  - I use an extension that doesn't work with gtk 3.0 and it is not likely to 
> be
> ported. I would like to use it as long as I can. There may be dozens of users
> like me in a similar situation :)
> 
> Even though my main motivation is for selfish reasons I think building the new
> Firefox with old gtk is more appropriate for (old)stable distribution since it
> is still a suppported build option and it is a more conservative jump from
> Firefox 45.
> 
> Please consider building with gtk+-2.0.

This makes sense, but firefox-esr hasn't been tested against gtk+-2.0
ever, neither on Debian nor on Mozilla end. AFAIK RedHat do such builds,
but I don't know if they carry extra patches.

What does the security team think here? We had this discussion in the
past, but IIRC back then it wasn't a given that building against
gtk+-2.0 might be a possibility.

Mike

Bug#864597: upgrade-reports: jessie -> stretch: gnome fails to upgrade: cycle found while processing triggers

[Cyril Brulebois]

Emmanuel Bourg  (2017-06-15):
> If you upload a NMU could you please push the changes to the Git
> repository?

I'll look into this when I've slept a bit. Reminders/prods welcome.


KiBi.


signature.asc
Description: Digital signature

Bug#790694: PPC64: 64kb kernel pagesizes and nouveau

[Vincent Pelletier]

Hello,

nouveau still does not support 64k pages, so I believe this bug is
still current.

It may not be the only one active on PPC64BE though: having built a
vanilla 4.11.5 using debian's 4.11 config and changing to 4k pages is
sadly not enough to make X work on a Powermac G5 ("late 2005" model)
with NV47.

The most visible aspect of the issue is similar in both 64k and 4k
pages: after a cold boot, there is a narrow solid grey rectangle from
screen top-left corner along top border which width seems to depend on
page size, and under it random noise in large vertical rectangles with
varying dominant hue (mostly white, mostly black, mostly cyan and mostly
magenta). After a warm reboot from OSX, elements of its GUI are
visible instead of these hue, with the same amount of random noise
added over it.

The dynamic effects are that once X has been started, chvt blocks (so
there is no going back to text mode), and X takes a long while to die
(several minutes) which also affects reboots and shutdown (maybe systemd
reaching its timeout threshold ?). ssh works fine during that time.

Regards,
-- 
Vincent Pelletier

Bug#864597: upgrade-reports: jessie -> stretch: gnome fails to upgrade: cycle found while processing triggers

[Guillem Jover]

Hi!

On Fri, 2017-06-16 at 00:37:20 +0200, gregor herrmann wrote:
> On Thu, 15 Jun 2017 20:31:00 +, Niels Thykier wrote:
> > Basically, jessie's verison of desktop-file-utils and shared-mime-info
> > have "-await" triggers (implicit) which will push other packages into a
> > "TRIGGER_PENDING" state.
> >   Once they are in that state, the "damage" is done and those other
> > packages will no longer satisfy dependencies until the trigger has been
> > processed.  Notably, dpkg is unable to /undo/ this state even if the
> > trigger changes from -await to -noawait during the upgrade.
> > 
> >  * If this holds, then changing the desktop-file-utils and
> >shared-mime-info triggers *in stable* to -noawait should make the
> >problem go away.
> > 
> >  * I realise it is unfeasible to implement in Debian by Saturday, but
> >it would help us understand the root cause of the problem.
> >- Tests to confirm/disprove this would be very welcome.
> 
> I think I can't confirm this theory. What I did:
> 
> A) Round 1: reproduce the problem:
> 
> 1) enter a jessie cowbuilder chroot
> 2) rm /etc/apt/apt.conf.d/15pbuilder # which turns off installing recommends
> 3) apt-get install task-gnome-desktop
> 4) sed -i -e 's/jessie/stretch/g' /etc/apt/sources.list
> 5) apt-get update
> 6) apt-get upgrade
> 7) apt-get dist-upgrade
> 
> Result:
[…]

> B) Round 2: play with triggers:
> 
> Same as above, except that after 3) I did
> 
> 3a) sed -i -e 's/interest /interest-noawait /' 
> /var/lib/dpkg/info/{desktop-file-utils,shared-mime-info}.triggers
> 
> and after 6) I again ran
> 
> 6a) sed -i -e 's/interest /interest-noawait /' 
> /var/lib/dpkg/info/{desktop-file-utils,shared-mime-info}.triggers

The important file to modify in addition is actually
/var/lib/dpkg/triggers/File, "/noawait" would need to be appended to
the relevant lines. The individual .triggers files for this scenario are
pretty much just parsed on unpack and removals.

Thanks,
Guillem

Bug#862057: Fwd: Fwd: Bug#862057: udev: If more than one NIC the system is booting longer

[a a]

Hi.

Yes. Now its fixed. It looks like the problem was with kernel after all. I
did not search yet for what caused this. After i updated my vbox debian9
the problem dissapered. It may be one of those pesky bugs that point to
something but its caused by something else. :(.
This bug report can be closed and deleted as unneded to be archived.

Thank you for you time

Bye

2017-06-15 18:19 GMT+02:00 Michael Biebl :

> Control: tags -1 + unreproducible
>
> On Mon, 29 May 2017 20:53:05 +0200 a a  wrote:
> > 
> >  type="virtio">
> >   
> > 
> >  type="virtio">
> >   
> > 
> >   
> >   
> > 
> >  type="virtio">
> >   
> > 
> >   
> >   
> > 
> >  type="virtio">
> >   
> > 
> >   
> >   
> > 
> > 
> > 
> > 
> > 
> >   
>
> I tried with exactly this configuration and could not reproduce the
> problem in an up-to-date, newly installed stretch vbox VM.
>
> Can you post a complete log file / dmesg output from your boot?
> Increasing the log level of udev (See /etc/udev/udev.conf) might help
> produce a more detailed log.
>
> Michael
> --
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
>
>

Bug#864851: firefox-esr: Please revert Jessie build to use Gtk+ 2.0

[Mert Dirik]

Package: firefox-esr
Version: 52.2.0esr-1~deb8u1
Severity: wishlist

Dear Maintainer,

Version 52 of firefox-esr jessie is with gtk+-3.0. I would be glad if you
reconsider building it with gtk+-2.0.

Here is my reasoning:

 - Firefox 52 still can be built with gtk+-2.0
 - It is the Firefox version to be used until mid 2018.
 - Jessie is already late in its lifecycle (soon to be oldstable). It will be
even older in mid 2018.
 - All the previous Iceweasel and Firefox versions that has been in jessie were
built with gtk+-2.0
 - There is no benefit changing the gtk version this late since Stretch release
is imminent and users who can benefit from using Firefox with gtk+-3.0 can
upgrade to Stretch
 - I use an extension that doesn't work with gtk 3.0 and it is not likely to be
ported. I would like to use it as long as I can. There may be dozens of users
like me in a similar situation :)

Even though my main motivation is for selfish reasons I think building the new
Firefox with old gtk is more appropriate for (old)stable distribution since it
is still a suppported build option and it is a more conservative jump from
Firefox 45.

Please consider building with gtk+-2.0.

Best regards

Bug#864850: menu: redundant code in term() function in /etc/menu-methods/menu.h

[Bill Allombert]

On Fri, Jun 16, 2017 at 01:06:18AM +0200, darthcat wrote:
> Package: menu
> Version: 2.1.47
> Severity: normal
> 
> Dear Maintainer,
> 
> I noticed in many terminal-emulators'manpage that the -e option enabled a
> terminal to execute a command, so why use "sh -c" with it? I think it's simply
> unuseful and heavier.

This is necessary to handle complex commands (using arguments, &&, |, >,
etc).  Not all terminal-emulators handle complex command the same way.
Using sh -c provide a common ground.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#864850: menu: redundant code in term() function in /etc/menu-methods/menu.h

[darthcat]

Package: menu
Version: 2.1.47
Severity: normal

Dear Maintainer,

I noticed in many terminal-emulators'manpage that the -e option enabled a
terminal to execute a command, so why use "sh -c" with it? I think it's simply
unuseful and heavier.
Please just remove it.

Best regards.

Philippe.



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

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

Versions of packages menu depends on:
ii  libc6   2.19-18+deb8u9
ii  libgcc1 1:4.9.2-10
ii  libstdc++6  4.9.2-10

menu recommends no packages.

Versions of packages menu suggests:
pn  gksu | kde-runtime | ktsuss  
pn  menu-l10n

-- no debconf information

Bug#864768: Duplicate bug reports?

[John Paul Adrian Glaubitz]

On Thu, Jun 15, 2017 at 06:57:25PM +0200, Emmanuel Bourg wrote:
> That was intentional, that's two different packages with different fixes.

Ah, I didn't look at the PTS pages. I thought that the binary package
in the one bug report was build from the source package in the other
bug report.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#864849: [patch] fix watch file

[Vincent McIntyre]

Package: autofs
Severity: normal
Version: 5.1.2
Tags: patch

thanks mate


This patch makes uscan do something useful again.

--- a/debian/watch
+++ b/debian/watch
@@ -1,2 +1,2 @@
 version=3
-ftp://ftp.kernel.org/pub/linux/daemons/autofs/v5/autofs-(5[^-]*)\.(?:tar\.xz|txz|tar\.bz2|tbz2|tar\.gz|tgz)
+https://git.kernel.org/pub/scm/linux/storage/autofs/autofs.git/refs/ 
.*tag/\?h=release_(\d)_(\d)_(\d)


% uscan --report --verbose --watchfile debian/watch
-- In debian/watch, processing watchfile line:
   https://git.kernel.org/pub/scm/linux/storage/autofs/autofs.git/refs/ 
.*tag/\?h=release_(\d)_(\d)_(\d)
-- Found the following matching hrefs:
 /pub/scm/linux/storage/autofs/autofs.git/tag/?h=release_5_1_3 (5.1.3)
 /pub/scm/linux/storage/autofs/autofs.git/tag/?h=release_5_1_2 (5.1.2)
 /pub/scm/linux/storage/autofs/autofs.git/tag/?h=release_5_1_1 (5.1.1)
 /pub/scm/linux/storage/autofs/autofs.git/tag/?h=release_5_1_0 (5.1.0)
 /pub/scm/linux/storage/autofs/autofs.git/tag/?h=release_5_0_9 (5.0.9)
 /pub/scm/linux/storage/autofs/autofs.git/tag/?h=release_5_0_8 (5.0.8)
 /pub/scm/linux/storage/autofs/autofs.git/tag/?h=release_5_0_7 (5.0.7)
 /pub/scm/linux/storage/autofs/autofs.git/tag/?h=release_5_0_6 (5.0.6)
 /pub/scm/linux/storage/autofs/autofs.git/tag/?h=release_5_0_5 (5.0.5)
 /pub/scm/linux/storage/autofs/autofs.git/tag/?h=release_5_0_4 (5.0.4)
 /pub/scm/linux/storage/autofs/autofs.git/tag/?h=release_5_0_3 (5.0.3)
 /pub/scm/linux/storage/autofs/autofs.git/tag/?h=release_5_0_2 (5.0.2)
 /pub/scm/linux/storage/autofs/autofs.git/tag/?h=release_5_0_1 (5.0.1)
 /pub/scm/linux/storage/autofs/autofs.git/tag/?h=release_4_1_1 (4.1.1)
 /pub/scm/linux/storage/autofs/autofs.git/tag/?h=release_4_1_2 (4.1.2)
 /pub/scm/linux/storage/autofs/autofs.git/tag/?h=release_4_1_3 (4.1.3)
 /pub/scm/linux/storage/autofs/autofs.git/tag/?h=release_4_1_4 (4.1.4)
Newest version on remote site is 5.1.3, local version is 5.1.2
 => Newer version available from

https://git.kernel.org/pub/scm/linux/storage/autofs/autofs.git/tag/?h=release_5_1_3

Kind regards
Vince

Bug#864597: upgrade-reports: jessie -> stretch: gnome fails to upgrade: cycle found while processing triggers

[gregor herrmann]

On Thu, 15 Jun 2017 20:31:00 +, Niels Thykier wrote:

> Basically, jessie's verison of desktop-file-utils and shared-mime-info
> have "-await" triggers (implicit) which will push other packages into a
> "TRIGGER_PENDING" state.
>   Once they are in that state, the "damage" is done and those other
> packages will no longer satisfy dependencies until the trigger has been
> processed.  Notably, dpkg is unable to /undo/ this state even if the
> trigger changes from -await to -noawait during the upgrade.
> 
>  * If this holds, then changing the desktop-file-utils and
>shared-mime-info triggers *in stable* to -noawait should make the
>problem go away.
> 
>  * I realise it is unfeasible to implement in Debian by Saturday, but
>it would help us understand the root cause of the problem.
>- Tests to confirm/disprove this would be very welcome.

I think I can't confirm this theory. What I did:

A) Round 1: reproduce the problem:

1) enter a jessie cowbuilder chroot
2) rm /etc/apt/apt.conf.d/15pbuilder # which turns off installing recommends
3) apt-get install task-gnome-desktop
4) sed -i -e 's/jessie/stretch/g' /etc/apt/sources.list
5) apt-get update
6) apt-get upgrade
7) apt-get dist-upgrade

Result:

(Reading database ... 132342 files and directories currently installed.)
Removing openjdk-7-jre:amd64 (7u111-2.6.7-1~deb8u1) ...
Removing openjdk-7-jre-headless:amd64 (7u111-2.6.7-1~deb8u1) ...
Removing tzdata-java (2017b-0+deb8u1) ...
Processing triggers for hicolor-icon-theme (0.15-1) ...
dpkg: cycle found while processing triggers:
 chain of packages whose triggers are or may be responsible:
  gnome-menus -> desktop-file-utils
 packages' pending triggers which are or may be unresolvable:
  gnome-menus: /usr/share/applications
  shared-mime-info: /usr/share/mime/packages
  desktop-file-utils: /usr/share/applications
  mime-support: /usr/share/applications
dpkg: error processing package gnome-menus (--remove):
 triggers looping, abandoned
Processing triggers for desktop-file-utils (0.23-1) ...
Processing triggers for mime-support (3.60) ...
Errors were encountered while processing:
 gnome-menus
E: Sub-process /usr/bin/dpkg returned an error code (1)


B) Round 2: play with triggers:

Same as above, except that after 3) I did

3a) sed -i -e 's/interest /interest-noawait /' 
/var/lib/dpkg/info/{desktop-file-utils,shared-mime-info}.triggers

and after 6) I again ran

6a) sed -i -e 's/interest /interest-noawait /' 
/var/lib/dpkg/info/{desktop-file-utils,shared-mime-info}.triggers


Result:

(Reading database ... 132342 files and directories currently installed.)
Removing openjdk-7-jre:amd64 (7u111-2.6.7-1~deb8u1) ...
Removing openjdk-7-jre-headless:amd64 (7u111-2.6.7-1~deb8u1) ...
Removing tzdata-java (2017b-0+deb8u1) ...
Processing triggers for hicolor-icon-theme (0.15-1) ...
dpkg: cycle found while processing triggers:
 chain of packages whose triggers are or may be responsible:
  gnome-menus -> desktop-file-utils
 packages' pending triggers which are or may be unresolvable:
  gnome-menus: /usr/share/applications
  shared-mime-info: /usr/share/mime/packages
  desktop-file-utils: /usr/share/applications
  mime-support: /usr/share/applications
dpkg: error processing package gnome-menus (--remove):
 triggers looping, abandoned
Processing triggers for desktop-file-utils (0.23-1) ...
Processing triggers for mime-support (3.60) ...
Errors were encountered while processing:
 gnome-menus
E: Sub-process /usr/bin/dpkg returned an error code (1)

# for p in desktop-file-utils shared-mime-info gnome-menus mime-support ; do 
echo $p:; cat /var/lib/dpkg/info/$p.triggers; done  

  
desktop-file-utils:
interest-noawait /usr/share/applications
shared-mime-info:
interest-noawait /usr/share/mime/packages
gnome-menus:
interest-noawait /usr/share/applications
interest-noawait gmenucache
mime-support:
interest-noawait /usr/lib/mime/packages
interest-noawait /usr/share/applications


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Donovan: Ballad of a crystal man


signature.asc
Description: Digital Signature

Bug#864829: screen reader stops speaking

[Luke Yelavich]

On Thu, Jun 15, 2017 at 11:39:35PM AEST, Mika Hanhijärvi wrote:
> I am using the Gnome desktop.
> I have espeakup and Orca installed. I would like to use espeakup on console 
> and
> Orca on desktop. I also would like to be able to switch between text mode
> console and graphical nome desktop without logging out from the desktop.

ESpeakup is running as root, and everything is running as a user. I think the 
easiest solution here is to configure Pulse to run system-wide. I know there 
is an option in one of the Pulse configuration files to enable this, but I 
don't think Debian ships a startup script or systemd service file to use 
PulseAudio in system mode. Happy to be corrected.
-- 
Please check out my Patreon campaign and spread the word.
https://patreon.com/lukefoss

Bug#864848: Should not talk about hd-media - that's armhf only

[Steve McIntyre]

Package: installation-guide-armel
Severity: normal

As seen in

  https://www.debian.org/releases/jessie/armel/ch05s01.html.en

there's discussion of "unpack the hd-media tarball". This doesn't
exist on armel...

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

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

Bug#863388: live-boot: Added new functionality to live-boot: rootcopy, modularized filesystems, package installer

[Mert Dirik]

On Wed, 14 Jun 2017 01:48:05 + William Prochazka wrote:
> Well,
>
> 1. Root copy is not a squashfs filesystem, so it allows for quick 
tweaking

> and modification without having to "commit" your changes. This also makes
> modifications (for the purpose of troubleshooting) much easier.
>
> 2. The alternative filesystem module is still a single file. The new
> feature allow for the specification and ordering of filesystem modules.
> For example, imagine the following:
> filesyste A contains all necessary files to boot a system into a basic
> shell with basic functionality, nothing more. Branch filesystem B 
contains
> a bunch of advanced tools (coimpilers, scripting environments, etc. 
Branch
> filesystem C contains X and Branch Filesystem D contains all of the X 
Bloat

> applications.
> Together, all four branches are roughly the size that the one 
"monolithic"

> filesystem D would have been if I wanted to use the legacy modules
> directive, but now, I have a boot time option to specify if I want just A
> for a tiny system, (A and B) for more functionality, (A, B, and C) for a
> GUI, or (A, B, C, and D) for all of the bells and whistle. Now I get all
> of that and don't have four copies of the filesystem. Furthermore, if I
> then add a file to A, It will be present when booting into D due to
> squashfs.
>
> It is really nice.

I'm still not getting it. You can accomplish all of these with the 
existing module functionality.


Modules don't have to be squashfs files. They can also be regular 
directories. You can modify them freely. You can use them in the exact 
same way you use overlay directories, because they end up being just 
another layer of  the overlayfs mount. You can mix and match modules 
using *.module files or change their ordering, because they are just 
overlays. You can also select different *.module files with boot parameters.


Sorry if I still miss something obvious but this seems to cover all 
functionality you've brought so far.

Bug#864847: ghc: on armhf should not use deprecated memory barrier instructions

[Edmund Grimley Evans]

Source: ghc
Version: 8.0.1-17+b1

If I try to run "ghc" in one of my armhf chroots, it does not work very well:

$ ghc
Illegal instruction

The offending instruction is this one:

mcr 15, 0, r6, cr7, cr10, {5}

This is, I think, an ARMv6 memory barrier, and these instructions are,
if I recall correctly, deprecated in ARMv7 and removed entirely in
ARMv8, though the kernel can be configured to emulate them. Since
armhf requires at least ARMv7, GHC should not be using or generating
these instructions on armhf.

I presume this problem concerns all binaries generated by GHC.

However, I hope it does not prevent any armhf binary from running
under a Debian armhf stock kernel image, even on ARMv8 hardware,
though someone should perhaps check that last point and raise the
severity if it turns out there is a problem on any standard
installation.

Bug#864846: ghc: on armhf should have load address of at least 0x10000

[Edmund Grimley Evans]

Source: ghc
Version: 8.0.1-17+b1

If I try to run "ghc" in one of my armhf chroots, it does not work very well:

$ ghc
Segmentation fault

$ wget http://ftp.debian.org/debian/pool/main/g/ghc/ghc_8.0.1-17+b1_armhf.deb
$ ar pf ghc_8.0.1-17+b1_armhf.deb data.tar.xz | tar xJf -
$ readelf -l usr/lib/ghc/bin/ghc | grep LOAD
  LOAD   0x00 0x8000 0x8000 0x19bc74 0x19bc74 R E 0x1000
  LOAD   0x19beb0 0x001a4eb0 0x001a4eb0 0x21d8c 0x21d8d RW  0x1000

Probably this binary should be a PIE, like nearly all other
executables in the system. Failing that, it should have a load address
of 0x1 instead of 0x8000 because many kernels are configured not
to allow an mmap below 0x1.

I presume this problem concerns all binaries generated by GHC.

However, I hope it does not prevent any armhf binary from running
under a Debian armhf stock kernel image.

Bug#852707: schleuder: FTBFS : refresh_keys test suite fails

[Daniel Kahn Gillmor]

On Wed 2017-02-01 10:49:21 +0100, schleu...@nadir.org wrote:
>> Could you confirm that changing the port make the tests work for you?
>
> Ping?

apologies, this message was addressed to the bug and not to me directly
and i'm just seeing it now (i had not subscribed to the bug report
itself).

if i disabled sks on the building host, i was able to complete the
build, so in that sense i "changed the port" and it built fine.

> Also: Are you using pbuilder with USENETWORK=no, the default, by any chance?

on a dedicated builder host without sks installed, pbuilder with
USENETWORK=no worked out fine. :)

  --dkg

Bug#864845: failed: Access denied for user 'debian-sys-maint'@'localhost' (using password: NO)

[Ludovic Rousseau]

Package: munin-plugins-core
Version: 2.0.33-1
Severity: normal
Tags: patch

Dear Maintainer,

On a freshly installed Debian 9/Stretch system I get:
$ sudo munin-run mysql_commands 
DBI 
connect('mysql;mysql_read_default_file=/etc/mysql/debian.cnf;mysql_connect_timeout=5','debian-sys-maint',...)
 failed: Access denied for user 'debian-sys-maint'@'localhost' (using password: 
NO) at /etc/munin/plugins/mysql_commands line 903.

I note that this system is using mariadb-server-10.1 and I have:
# cat debian.cnf 
# Automatically generated for Debian scripts. DO NOT TOUCH!
[client]
host = localhost
user = root
password = 
socket   = /var/run/mysqld/mysqld.sock
[mysql_upgrade]
host = localhost
user = root
password = 
socket   = /var/run/mysqld/mysqld.sock
basedir  = /usr


On another Debian system using 8/Jessie I use mysql-server-5.5 and I
have:
$ sudo cat /etc/mysql/debian.cnf 
# Automatically generated for Debian scripts. DO NOT TOUCH!
[client]
host = localhost
user = debian-sys-maint
password = 
socket   = /var/run/mysqld/mysqld.sock
[mysql_upgrade]
host = localhost
user = debian-sys-maint
password = 
socket   = /var/run/mysqld/mysqld.sock
basedir  = /usr

On this system the mysql_* munin plugins are working fine.



>From /usr/share/doc/mariadb-server-10.1/README.Debian.gz

* ROOT USER AUTHENTICATION VIA UNIX SOCKET
==

On new installs no root password is set and no debian-sys-maint user is
created anymore. Instead the MariaDB root account is set to be authenticated
using the unix socket, e.g. any mysqld invocation by root or via sudo will
let the user see the mysqld prompt.

You may never ever delete the mysql user "root". Although it has no password
is set, the unix_auth plugin ensure that it can only be run locally as the root
user.

The credentials in /etc/mysql/debian.cnf specify the user which is used by the
init scripts to stop the server and perform logrotation. This used to be the
debian-sys-maint user which is no longer used as root can run directly.

If you have start/stop problems make sure that the /etc/mysql/debian.cnf file 
specifies the root user and no password.


Proposed patch:
--- /home/rousseau/munin-node   2017-06-15 23:12:53.880266037 +0200
+++ /etc/munin/plugin-conf.d/munin-node 2017-06-15 23:04:19.285684484 +0200
@@ -73,7 +73,7 @@
 [mysql*]
 user root
 env.mysqlopts --defaults-file=/etc/mysql/debian.cnf
-env.mysqluser debian-sys-maint
+env.mysqluser root
 env.mysqlconnection 
DBI:mysql:mysql;mysql_read_default_file=/etc/mysql/debian.cnf
 
 [postfix_mailqueue]


This change works for me.

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

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

Versions of packages munin-plugins-core depends on:
ii  munin-common  2.0.33-1
ii  perl  5.24.1-3

Versions of packages munin-plugins-core recommends:
ii  libnet-snmp-perl  6.0.1-2

Versions of packages munin-plugins-core suggests:
pn  conntrack
ii  libcache-cache-perl  1.08-2
ii  libdbd-mysql-perl4.041-2
ii  libnet-dns-perl  1.07-1
pn  libnet-netmask-perl  
pn  libnet-telnet-perl   
ii  libxml-parser-perl   2.44-2+b1
ii  python   2.7.13-2
pn  ruby | ruby-interpreter  

-- no debconf information

Bug#864843: Audio hangs on repeated playback

[Felipe Sateler]

-

On Thu, Jun 15, 2017 at 4:51 PM, John Smart  wrote:
> Sometimes it hangs half way through and I have to interrupt:
>
> $ aplay oboe-bassoon.wav
> Playing WAVE 'oboe-bassoon.wav' : Signed 16 bit Little Endian, Rate
> 48000 Hz, Stereo
>
> underrun!!! (at least 14300.479 ms long)
> ^CAborted by signal Interrupt...
> aplay: pcm_write:1939: write error: Interrupted system call
>
>
> Other times, it makes it to the end, and I can play it again.  Seems
> random.  After playback, there's also a quiet pink noise hiss for a
> three seconds.

This definitely sounds like a driver bug and not a pulseaudio one.
Could you try disabling timer-based scheduling? Edit
/etc/pulse/default.pa, by changing the line loading the udev module to
add 'tsched=0' at the end (without the quotes). Then restart
pulseaudio (or reboot) and try again.

-- 

Saludos,
Felipe Sateler

Bug#863991: debcheckout tellico content update available

[Geert Stappers]

Hello,


Someone with the write privilege on the KDE  git repository,
please do

wget 
http://ftp.debian.org/debian/pool/main/t/tellico/tellico_3.0.2-1.2.debian.tar.xz
debcheckout tellico
cd tellico
tar xf ../tellico_3.0.2-1.2.debian.tar.xz 
git add debian
git status
git diff --cached
# review the changes
git commit -m "updated the debian directory"
git push g...@git.kde.org:tellico.git


So `debcheckout tellico` content gets updated.
Thanks!!


Groeten
Geert Stappers
-- 
stappers@nero:~/Downloads
$ wget 
http://ftp.debian.org/debian/pool/main/t/tellico/tellico_3.0.2-1.2.debian.tar.xz
--2017-06-15 22:32:18--  
http://ftp.debian.org/debian/pool/main/t/tellico/tellico_3.0.2-1.2.debian.tar.xz
Resolving ftp.debian.org (ftp.debian.org)... 130.89.148.12, 
2001:610:1908:b000::148:12
Connecting to ftp.debian.org (ftp.debian.org)|130.89.148.12|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1198180 (1.1M) [application/x-xz]
Saving to: tellico_3.0.2-1.2.debian.tar.xz

100%[==>]
 1,198,180   2.09MB/s   in 0.5s   

2017-06-15 22:32:19 (2.09 MB/s) - tellico_3.0.2-1.2.debian.tar.xz saved 
[1198180/1198180]

stappers@nero:~/Downloads
$ debcheckout tellico
declared git repository at git://anongit.kde.org/tellico.git
git clone git://anongit.kde.org/tellico.git tellico ...
Cloning into 'tellico'...
remote: Counting objects: 26514, done.
remote: Compressing objects: 100% (5070/5070), done.
remote: Total 26514 (delta 22509), reused 25177 (delta 21392)
Receiving objects: 100% (26514/26514), 16.72 MiB | 2.22 MiB/s, done.
Resolving deltas: 100% (22509/22509), done.
Checking connectivity... done.
stappers@nero:~/Downloads
$ cd tellico
stappers@nero:~/Downloads/tellico
$ tar xf ../tellico_3.0.2-1.2.debian.tar.xz 
stappers@nero:~/Downloads/tellico
$ git add debian
stappers@nero:~/Downloads/tellico
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.

Changes to be committed:
  (use "git reset HEAD ..." to unstage)

new file:   debian/README.source
modified:   debian/changelog
modified:   debian/compat
modified:   debian/control
new file:   debian/patches/series
new file:   debian/patches/unclean
modified:   debian/rules
new file:   debian/source/include-binaries
new file:   debian/source/lintian-overrides
modified:   debian/tellico-data.install
new file:   debian/tellico-doc.install
modified:   debian/tellico-scripts.install
modified:   debian/watch

stappers@nero:~/Downloads/tellico
$ 

Bug#864843: Audio hangs on repeated playback

[John Smart]

Sometimes it hangs half way through and I have to interrupt:

$ aplay oboe-bassoon.wav
Playing WAVE 'oboe-bassoon.wav' : Signed 16 bit Little Endian, Rate
48000 Hz, Stereo

underrun!!! (at least 14300.479 ms long)
^CAborted by signal Interrupt...
aplay: pcm_write:1939: write error: Interrupted system call


Other times, it makes it to the end, and I can play it again.  Seems
random.  After playback, there's also a quiet pink noise hiss for a
three seconds.

On Thu, Jun 15, 2017 at 1:28 PM, Felipe Sateler  wrote:
> On Thu, Jun 15, 2017 at 4:14 PM, John Smart  wrote:
>> Package: pulseaudio
>> Version: pulseaudio 5.0
>> Distro: Raspbian GNU/Linux 8.0 (jessie)
>>
>> When I playback audio using, for example, aplay, the first playback
>> works fine.  Subsequent playback will hang indefinitely.  Several
>> ctrl+c signals will restore playback for one additional play.
>>
>> Reproduction steps:
>>
>> 1. Download any wav:
>> wget http://ccrma.stanford.edu/~jos/wav/oboe-bassoon.wav
>>
>> 2. Use aplay to playback the sound:
>>
>> $ aplay oboe-bassoon.wav
>> Playing WAVE 'oboe-bassoon.wav' : Signed 16 bit Little Endian, Rate
>> 48000 Hz, Stereo
>> # plays ok
>> ^CAborted by signal Interrupt...
>> aplay: pcm_write:1939: write error: Interrupted system call
>>
>> $ aplay oboe-bassoon.wav
>> Playing WAVE 'oboe-bassoon.wav' : Signed 16 bit Little Endian, Rate
>> 48000 Hz, Stereo
>> # hangs without any playback
>>
>> I have tried loading PulseAudio daemon in verbose mode to see what
>> might be going on.  When the process hangs, I see:
>>
>> D: [alsa-sink-bcm2835 ALSA] source.c: Processing rewind...
>>
>> I also see a lot of these warnings:
>>
>> D: [alsa-sink-bcm2835 ALSA] protocol-native.c: Implicit underrun of
>> 'ALSA Playback'
>> D: [alsa-sink-bcm2835 ALSA] sink.c: Found underrun 22784 bytes ago
>> (1792 bytes ahead in playback buffer)
>> D: [alsa-sink-bcm2835 ALSA] sink.c: Found underrun 22784 bytes ago
>> (1792 bytes ahead in playback buffer)
>> D: [alsa-sink-bcm2835 ALSA] sink.c: Found underrun 22784 bytes ago
>> (1792 bytes ahead in playback buffer)
>> D: [alsa-sink-bcm2835 ALSA] sink.c: Found underrun 22784 bytes ago
>> (1792 bytes ahead in playback buffer)
>> D: [alsa-sink-bcm2835 ALSA] sink.c: Found underrun 22784 bytes ago
>> (1792 bytes ahead in playback buffer)
>> D: [alsa-sink-bcm2835 ALSA] sink.c: Found underrun 22784 bytes ago
>> (1792 bytes ahead in playback buffer)
>> D: [alsa-sink-bcm2835 ALSA] sink.c: Found underrun 22784 bytes ago
>> (1792 bytes ahead in playback buffer)
>> D: [alsa-sink-bcm2835 ALSA] sink.c: Found underrun 22784 bytes ago
>> (1792 bytes ahead in playback buffer)
>
> Sounds like a driver bug. Does it hang if you let the wav play to the end?
>
>
> --
>
> Saludos,
> Felipe Sateler

Bug#864597: upgrade-reports: jessie -> stretch: gnome fails to upgrade: cycle found while processing triggers

[Niels Thykier]

Andreas Beckmann:
> [ added Guillem to the recipients, he is the expert for trigger cycles ]
> [ added Doko to the recipients, since #863820 is a possible solution ]
> [ therefore resending a full-quote ]
> 
> On 2017-06-11 12:00, Niels Thykier wrote:
>> Cyril Brulebois:
>>> Package: upgrade-reports
>>> Severity: critical
>>> Justification: makes upgrade from stable abort
>>>
>> [...]
> 
> Switching desktop-file-utils or/and shared-mime-info to -noawait
> triggers does not solve the problem.
> 

Hi,

Guillem and I have been talking about this over IRC and have a theory.

Basically, jessie's verison of desktop-file-utils and shared-mime-info
have "-await" triggers (implicit) which will push other packages into a
"TRIGGER_PENDING" state.
  Once they are in that state, the "damage" is done and those other
packages will no longer satisfy dependencies until the trigger has been
processed.  Notably, dpkg is unable to /undo/ this state even if the
trigger changes from -await to -noawait during the upgrade.

 * If this holds, then changing the desktop-file-utils and
   shared-mime-info triggers *in stable* to -noawait should make the
   problem go away.

 * I realise it is unfeasible to implement in Debian by Saturday, but
   it would help us understand the root cause of the problem.
   - Tests to confirm/disprove this would be very welcome.

If this holds, then to fully resolve the problem, we will need 3 things:

 * A stable update to jessie for these two packages migrating to
   -noawait.

 * An upload targeting stretch for these two packages migrating them to
   -noawait.

 * A "big magic hammer" work around for stretch for r0
   - OR a release-notes remark to pull upgrades from jessie
   - OR ...

Obviously, the above possibly ignores some time constraints.
Furthermore, the only thing remotely resembling a "big magic hammer"
atm. seems to be #863820, which we are unwilling to do with such short
notice[1].
  I know that there was an upload to undo the changes in the java
packages, but AFAIUI, it basically means that Java will not be upgraded.
 The user would explicitly have to install Java 8 and then uninstall the
now unsupported Java 7 - that seems very unhelpful to me.

Thanks,
~Niels

[1] We do have an another possible "big magic hammer", but it is even
less pretty and is called "Pre-Depends".  As I recall, Pre-Depends are
handled specially by apt so it runs them in smaller bundles before the
main upgrade.  We can almost certainly abuse this to work around the issue.

However, I hardly imagine that most of you will applaud that.

Bug#864843: Audio hangs on repeated playback

[Felipe Sateler]

On Thu, Jun 15, 2017 at 4:14 PM, John Smart  wrote:
> Package: pulseaudio
> Version: pulseaudio 5.0
> Distro: Raspbian GNU/Linux 8.0 (jessie)
>
> When I playback audio using, for example, aplay, the first playback
> works fine.  Subsequent playback will hang indefinitely.  Several
> ctrl+c signals will restore playback for one additional play.
>
> Reproduction steps:
>
> 1. Download any wav:
> wget http://ccrma.stanford.edu/~jos/wav/oboe-bassoon.wav
>
> 2. Use aplay to playback the sound:
>
> $ aplay oboe-bassoon.wav
> Playing WAVE 'oboe-bassoon.wav' : Signed 16 bit Little Endian, Rate
> 48000 Hz, Stereo
> # plays ok
> ^CAborted by signal Interrupt...
> aplay: pcm_write:1939: write error: Interrupted system call
>
> $ aplay oboe-bassoon.wav
> Playing WAVE 'oboe-bassoon.wav' : Signed 16 bit Little Endian, Rate
> 48000 Hz, Stereo
> # hangs without any playback
>
> I have tried loading PulseAudio daemon in verbose mode to see what
> might be going on.  When the process hangs, I see:
>
> D: [alsa-sink-bcm2835 ALSA] source.c: Processing rewind...
>
> I also see a lot of these warnings:
>
> D: [alsa-sink-bcm2835 ALSA] protocol-native.c: Implicit underrun of
> 'ALSA Playback'
> D: [alsa-sink-bcm2835 ALSA] sink.c: Found underrun 22784 bytes ago
> (1792 bytes ahead in playback buffer)
> D: [alsa-sink-bcm2835 ALSA] sink.c: Found underrun 22784 bytes ago
> (1792 bytes ahead in playback buffer)
> D: [alsa-sink-bcm2835 ALSA] sink.c: Found underrun 22784 bytes ago
> (1792 bytes ahead in playback buffer)
> D: [alsa-sink-bcm2835 ALSA] sink.c: Found underrun 22784 bytes ago
> (1792 bytes ahead in playback buffer)
> D: [alsa-sink-bcm2835 ALSA] sink.c: Found underrun 22784 bytes ago
> (1792 bytes ahead in playback buffer)
> D: [alsa-sink-bcm2835 ALSA] sink.c: Found underrun 22784 bytes ago
> (1792 bytes ahead in playback buffer)
> D: [alsa-sink-bcm2835 ALSA] sink.c: Found underrun 22784 bytes ago
> (1792 bytes ahead in playback buffer)
> D: [alsa-sink-bcm2835 ALSA] sink.c: Found underrun 22784 bytes ago
> (1792 bytes ahead in playback buffer)

Sounds like a driver bug. Does it hang if you let the wav play to the end?


-- 

Saludos,
Felipe Sateler

Bug#861989: nautilus: Nautilus freezes/crashes when right clicking and selecting properties for 1 or more files

[Jason Crain]

Control: reassign -1 tracker-gui 1.2.4-2
Control: tags -1 - moreinfo
Control: found -1 1.10.5-1

On Sun, Jun 11, 2017 at 02:31:33PM -0500, Jason Crain wrote:
> How large is your tracker database ~/.cache/tracker/meta.db?  Do you
> have gigabytes of documents being indexed that would inflate the
> database?

I'm going to assume the answer to this is yes, you have gigabytes of
PDFs and PowerPoint presentations causing a large tracker database.

Bug#864844: nautilus: google-drive support is great!

[Carlo Marchiori]

Package: nautilus
Version: 3.22.3-1
Severity: normal

Dear Maintainer,

google-drive support is great!



-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable'), (500, 'stable'), (100, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages nautilus depends on:
ii  desktop-file-utils 0.23-1
ii  gsettings-desktop-schemas  3.22.0-1
ii  gvfs   1.30.4-1
ii  libatk1.0-02.22.0-1
ii  libc6  2.24-11
ii  libcairo-gobject2  1.14.8-1
ii  libcairo2  1.14.8-1
ii  libexempi3 2.4.1-1
ii  libexif12  0.6.21-2+b2
ii  libgail-3-03.22.11-1
ii  libgdk-pixbuf2.0-0 2.36.5-2
ii  libglib2.0-0   2.50.3-2
ii  libglib2.0-data2.50.3-2
ii  libgnome-autoar-0-00.1.1-4+b1
ii  libgnome-desktop-3-12  3.22.2-1
ii  libgtk-3-0 3.22.11-1
ii  libnautilus-extension1a3.22.3-1
ii  libpango-1.0-0 1.40.5-1
ii  libselinux12.6-3+b1
ii  libtracker-sparql-1.0-01.10.5-1
ii  libx11-6   2:1.6.4-3
ii  nautilus-data  3.22.3-1
ii  shared-mime-info   1.8-1

Versions of packages nautilus recommends:
ii  gnome-sushi  3.21.91-2
ii  gvfs-backends1.30.4-1
ii  librsvg2-common  2.40.16-1+b1

Versions of packages nautilus suggests:
pn  brasero  
ii  eog  3.20.5-1+b1
ii  evince [pdf-viewer]  3.22.1-3
pn  nautilus-sendto  
ii  tracker  1.10.5-1
ii  vlc [mp3-decoder]2.2.6-1~deb9u1
ii  xdg-user-dirs0.15-2+b1

-- no debconf information

Bug#864779: Epetra doc missing

[Nico Schlömer]

Let me add also that Epetra isn't that important anymore. Trilinos devs try
to get people to switch over to Tpetra, and in fact Epetra hasn't seen
substantial development in many years now.

Cheers,
Nico



On Thu, Jun 15, 2017 at 5:22 PM Nico Schlömer 
wrote:

> Thanks Joachim for report.
>
> This is more of an upstream issue, see [1]. Once that is done, the package
> will have the Epetra documentation shipped.
>
> Cheers,
> Nico
>
> [1] https://github.com/trilinos/Trilinos/issues/1431
>
> On Wed, Jun 14, 2017 at 6:42 PM Joachim Wuttke 
> wrote:
>
>> Package: trilinos-doc
>> Version: 12.10.1-3
>>
>> Documentation of the important Trilinos component Epetra
>> is missing in /usr/share/doc/trilinos.
>>
>>

Bug#862755: RFS: golang-github-go-ini-ini/1.27.0-1

[Gianfranco Costamagna]

Hello,

> gbp clone --pristine-tar 
> https://anonscm.debian.org/git/pkg-go/packages/golang-go-ini-ini.git

lets review (the mentors link)
+golang-github-go-ini-ini (1.27.0-1) experimental; urgency=medium
+
+  * New upstream version 1.27.0
+  * update Standards-Version and debhelper version
+  * add myself to the uploaders
+  * use https in the Vcs-Browser field
+
+ -- Félix Sipma   Tue, 16 May 2017 16:22:10 +0200
+
+golang-github-go-ini-ini (1.8.6-3) unstable; urgency=medium
+
+  * Team upload.
+  * Use a secure transport for the Vcs-Git and Vcs-Browser URL
+
+ -- Paul Tagliamonte   Wed, 29 Jun 2016 20:21:03 -0400
+


please merge the two changelog entries together

please ask your comaintainers (in cc), if you can add yourself in uploaders list

> 2017/05/16 18:21:46 FAILED: grafana_2.6.0+dfsg-3 (see 
> buildlogs/grafana_2.6.0+dfsg-3)
> 2017/05/16 18:21:46 FAILED: nomad_0.4.0+dfsg-1 (see 
> buildlogs/nomad_0.4.0+dfsg-1)
> 2017/05/16 18:21:46 FAILED: packer_0.10.2+dfsg-5 (see 
> buildlogs/packer_0.10.2+dfsg-5)
> 2017/05/16 18:21:46 FAILED: goiardi_0.11.4-1 (see 
> buildlogs/goiardi_0.11.4-1)
> 
> grafana and nomad fails for unrelated reasons (see attached logs)
> 
> I don't get why goiardi and packer fail.

this should be sorted out before uploading in unstable, please ask upstream or 
relative maintainers
and fix this

> 
> If the person who sponsors the upload could also give me upload permissions 
> for
> this package, that would be great!
> 

after updating it, prod me if I forget :)

review:

+Vcs-Browser: 
https://anonscm.debian.org/gitweb/?p=pkg-go/packages/golang-github-go-ini-ini.git;a=summary

please use cgit

+ ${misc:Depends},
+ golang-go

not mentioned in changelog

+version=3
+ https://github.com/go-ini/ini/releases \
+ .*/v?(\d[\d\.]*)\.tar\.gz

please mention in changelog


and then we should be good :)

G.

G.



signature.asc
Description: OpenPGP digital signature

Bug#864843: Audio hangs on repeated playback

[John Smart]

Package: pulseaudio
Version: pulseaudio 5.0
Distro: Raspbian GNU/Linux 8.0 (jessie)

When I playback audio using, for example, aplay, the first playback
works fine.  Subsequent playback will hang indefinitely.  Several
ctrl+c signals will restore playback for one additional play.

Reproduction steps:

1. Download any wav:
wget http://ccrma.stanford.edu/~jos/wav/oboe-bassoon.wav

2. Use aplay to playback the sound:

$ aplay oboe-bassoon.wav
Playing WAVE 'oboe-bassoon.wav' : Signed 16 bit Little Endian, Rate
48000 Hz, Stereo
# plays ok
^CAborted by signal Interrupt...
aplay: pcm_write:1939: write error: Interrupted system call

$ aplay oboe-bassoon.wav
Playing WAVE 'oboe-bassoon.wav' : Signed 16 bit Little Endian, Rate
48000 Hz, Stereo
# hangs without any playback

I have tried loading PulseAudio daemon in verbose mode to see what
might be going on.  When the process hangs, I see:

D: [alsa-sink-bcm2835 ALSA] source.c: Processing rewind...

I also see a lot of these warnings:

D: [alsa-sink-bcm2835 ALSA] protocol-native.c: Implicit underrun of
'ALSA Playback'
D: [alsa-sink-bcm2835 ALSA] sink.c: Found underrun 22784 bytes ago
(1792 bytes ahead in playback buffer)
D: [alsa-sink-bcm2835 ALSA] sink.c: Found underrun 22784 bytes ago
(1792 bytes ahead in playback buffer)
D: [alsa-sink-bcm2835 ALSA] sink.c: Found underrun 22784 bytes ago
(1792 bytes ahead in playback buffer)
D: [alsa-sink-bcm2835 ALSA] sink.c: Found underrun 22784 bytes ago
(1792 bytes ahead in playback buffer)
D: [alsa-sink-bcm2835 ALSA] sink.c: Found underrun 22784 bytes ago
(1792 bytes ahead in playback buffer)
D: [alsa-sink-bcm2835 ALSA] sink.c: Found underrun 22784 bytes ago
(1792 bytes ahead in playback buffer)
D: [alsa-sink-bcm2835 ALSA] sink.c: Found underrun 22784 bytes ago
(1792 bytes ahead in playback buffer)
D: [alsa-sink-bcm2835 ALSA] sink.c: Found underrun 22784 bytes ago
(1792 bytes ahead in playback buffer)

Bug#864788: [pkg-gnupg-maint] Bug#864788: Bug#864788: cache TTL values ignored for smartcard PINs

[Werner Koch]

On Thu, 15 Jun 2017 17:43, d...@fifthhorseman.net said:

> I believe that killing gpg-agent kills scdaemon, which de-initializes
> the smartcard on shutdown, which takes it out of authenticated mode.

Right the smartcard is power-cycled and thus it clears all its transient
state.

> on whether that's feasible or not.  it would be nice to have the
> semantics of the cache ttl be the same, regardless of whether a key is
> stored on a smartcard or not.

The properties of a smartcard and an on-disk key are very different.  In
fact a smartcard should be considered another gpg-agent to which
gpg-agent delegates its operation.  The properties of the smartcard are
controlled by the card; for example an OpenPGP card can be configured to
require a PIN for each signing operation.  Other types of smartcards
have different conditions for example cards for quailified signatures
allow only a cewrtain number of signatures before a PIN  needs to be
re-entered as well as more complicated schemes.  Using the
passphrase TTL also for a card does not really match.

A workaround is to force a reset of the card by putting

  card-timeout N

in scdaemon.conf which shuts down the card after N seconds.  Well, as of
now N is just a binary flag to tell sdaemon to shutdown the card at the
next timer tick; thus immediately after an operation.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgpwnqfmacdKZ.pgp
Description: PGP signature

Bug#864841: Mixed paths

[Mattia Rizzolo]

Control: reassign -1 ax25-tools 0.0.10-rc4-1

On Thu, Jun 15, 2017 at 03:20:56PM -0400, Brian wrote:
> Package: ax25-tools (ax25-apps is missing in the repositories, should
> exist.)

please don't write random chars after the package name, as it counts as
a different (invalid in this case) name.

> Version: Debian 9.0

And this is not a package version…

Rassigning appropriately.

> 
> ax25-tools still uses /var/ax25/* for it's data storage paths
> yet uronode is looking for them at /var/lib/ax25/*
> 
> locate mheard.dat
> /var/ax25/mheard/mheard.dat
> 
> I suggest going through all ham apps using data from ax25-tools/apps and
> insuring everything syncs up. If /var/ax25 is to be continued then the
> paths in uronode should revert to this, otherwise the paths in
> ax25-tools needs to be fixed.
> 
> Also note, ax25-apps *needs* to be included in the repositories. It is
> missing and breaks half of ax25-tools.
> 
> 
> 
> -- 
> With all the leaks coming from the U.S. Government from ALL branches,
> we don't need a Democrat or a Republican as President, we need:
> Joe the plumber!
> 
> 73 de Brian - N1URO/AFT1BR
> email: (see above)
> Web: http://www.n1uro.net/
> Ampr1: http://n1uro.ampr.org/
> Ampr2: http://nos.n1uro.ampr.org
> Linux Amateur Radio Services
> axMail-Fax & URONode
> http://uronode.sourceforge.net
> http://axmail.sourceforge.net
> AmprNet coordinator for:
> Connecticut, Delaware, Maine,
> Maryland, Massachusetts, 
> New Hampshire, New Jersey, Pennsylvania, 
> Rhode Island, and Vermont.



-- 
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#854511: chromium: Media-router has been re-enabled, making cast-extension useless

[Ximin Luo]

Package: chromium
Followup-For: Bug #854511

I think this bug is fixed in the latest version, 59. The in-built Media Router
extension works and you don't need an extra cast-extension. At least I've been
using it to watch youtube videos on my TV for the past few days. It didn't work
in 58 but after upgrading to 59 it works fine.

Sometimes it causes segfaults however, then your chromium will keep segfaulting
every time it starts. To fix this, you can remove the extension directory, 
disable
the router, restart chrome, reenable the router, restart chrome again. In a 
script
for your convenience:


#!/bin/sh
# If Chrome segfaults while running Chrome Cast, it will keep segfaulting on 
startup.
# Run this to fix things and get back to where you were.
CHROMIUM_CONFIGDIR="${CHROMIUM_CONFIGDIR:-$HOME/.config/chromium}"
CHROMIUM_PROFILE="${CHROMIUM_PROFILE:-$CHROMIUM_CONFIGDIR/Default}"

rm -rf "${CHROMIUM_PROFILE}/Extensions/pkedcjkdefgpdelpbcmbmeomcjbeemfm/"
sed -i -e 
"s/load-media-router-component-extension@1/load-media-router-component-extension@0/"
 "$CHROMIUM_CONFIGDIR/Local State"
chromium &
sleep 1; kill $!; wait $! # otherwise non-exited child processes will clobber 
the value below
sed -i -e 
"s/load-media-router-component-extension@0/load-media-router-component-extension@1/"
 "$CHROMIUM_CONFIGDIR/Local State"
chromium


X

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (300, 'unstable'), (200, 'experimental'), (1, 
'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.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)

Versions of packages chromium depends on:
ii  libasound2   1.1.3-5
ii  libatk1.0-0  2.22.0-1
ii  libavcodec57 7:3.2.5-1
ii  libavformat577:3.2.5-1
ii  libavutil55  7:3.2.5-1
ii  libc62.24-11
ii  libcairo21.14.8-1
ii  libcups2 2.2.1-8
ii  libdbus-1-3  1.10.18-1
ii  libdrm2  2.4.74-1
ii  libevent-2.0-5   2.0.21-stable-3
ii  libexpat12.2.0-2
ii  libflac8 1.3.2-1
ii  libfontconfig1   2.11.0-6.7+b1
ii  libfreetype6 2.6.3-3.2
ii  libgcc1  1:6.3.0-18
ii  libgdk-pixbuf2.0-0   2.36.5-2
ii  libglib2.0-0 2.50.3-2
ii  libgtk2.0-0  2.24.31-2
ii  libharfbuzz0b1.4.2-1
ii  libicu57 57.1-6
ii  libjpeg62-turbo  1:1.5.1-2
ii  libminizip1  1.1-8+b1
ii  libnspr4 2:4.12-6
ii  libnss3  2:3.26.2-1.1
ii  libpango-1.0-0   1.40.5-1
ii  libpangocairo-1.0-0  1.40.5-1
ii  libpng16-16  1.6.28-1
ii  libpulse010.0-1
ii  libre2-3 20170101+dfsg-1
ii  libsnappy1v5 1.1.3-3
ii  libstdc++6   6.3.0-18
ii  libvpx4  1.6.1-3
ii  libwebp6 0.5.2-1
ii  libwebpdemux20.5.2-1
ii  libx11-6 2:1.6.4-3
ii  libx11-xcb1  2:1.6.4-3
ii  libxcb1  1.12-1
ii  libxcomposite1   1:0.4.4-2
ii  libxcursor1  1:1.1.14-1+b4
ii  libxdamage1  1:1.1.4-2+b3
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxi6   2:1.7.9-1
ii  libxml2  2.9.4+dfsg1-2.2
ii  libxrandr2   2:1.5.1-1
ii  libxrender1  1:0.9.10-1
ii  libxslt1.1   1.1.29-2.1
ii  libxss1  1:1.2.2-1
ii  libxtst6 2:1.2.3-1
ii  x11-utils7.7+3+b1
ii  xdg-utils1.1.1-1
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages chromium recommends:
ii  fonts-liberation  1:1.07.4-2

Versions of packages chromium suggests:
pn  chromium-driver
pn  chromium-l10n  
pn  chromium-shell 
pn  chromium-widevine  

-- Configuration Files:
/etc/chromium.d/default-flags changed [not included]

-- no debconf information

Bug#864842: puppet-module-puppetlabs-apt: Depends on transitional dummy package puppet-common

[Mykola Nikishov]

Package: puppet-module-puppetlabs-apt
Version: 2.3.0-1
Severity: normal

The same issue as in #858390.

-- System Information:
Debian Release: 9.0
  APT prefers stable
  APT policy: (500, 'stable'), (70, 'unstable'), (60, 'testing'), (50, 
'experimental'), (40, 'oldstable')
Architecture: amd64
 (x86_64)

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

Bug#864841: Mixed paths

[Brian]

Package: ax25-tools (ax25-apps is missing in the repositories, should
exist.)
Version: Debian 9.0

ax25-tools still uses /var/ax25/* for it's data storage paths
yet uronode is looking for them at /var/lib/ax25/*

locate mheard.dat
/var/ax25/mheard/mheard.dat

I suggest going through all ham apps using data from ax25-tools/apps and
insuring everything syncs up. If /var/ax25 is to be continued then the
paths in uronode should revert to this, otherwise the paths in
ax25-tools needs to be fixed.

Also note, ax25-apps *needs* to be included in the repositories. It is
missing and breaks half of ax25-tools.



-- 
With all the leaks coming from the U.S. Government from ALL branches,
we don't need a Democrat or a Republican as President, we need:
Joe the plumber!

73 de Brian - N1URO/AFT1BR
email: (see above)
Web: http://www.n1uro.net/
Ampr1: http://n1uro.ampr.org/
Ampr2: http://nos.n1uro.ampr.org
Linux Amateur Radio Services
axMail-Fax & URONode
http://uronode.sourceforge.net
http://axmail.sourceforge.net
AmprNet coordinator for:
Connecticut, Delaware, Maine,
Maryland, Massachusetts, 
New Hampshire, New Jersey, Pennsylvania, 
Rhode Island, and Vermont.


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

Bug#864769: Duplicate bug reports?

[Emmanuel Bourg]

Le 15/06/2017 à 17:16, John Paul Adrian Glaubitz a écrit :

> Is there a reason why you filed the same bug report twice? One against
> src:libquartz-java (#864768) and one against libquartz-java (#864769)?
> 
> Otherwise I'd suggest merging both bug reports.

Hi Adrian,

That was intentional, that's two different packages with different fixes.

Emmanuel Bourg

Bug#864733: Error: "Download error: Download Error: 404 Not Found", Debian stable

[Mykola Nikishov]

Package: torbrowser-launcher
Version: 0.2.7-2
Followup-For: Bug #864733

It is broken in unstable:

--8<---cut here---start->8---
Tor Browser Launcher
By Micah Lee, licensed under MIT
version 0.2.7
https://github.com/micahflee/torbrowser-launcher
Downloading over Tor
Downloading and installing Tor Browser for the first time.
Downloading 
https://dist.torproject.org/torbrowser/update_2/release/Linux_x86_64-gcc3/x/en-US
Latest version: 6.5.2
Downloading 
https://www.torproject.org/dist/torbrowser/6.5.2/tor-browser-linux64-6.5.2_en-US.tar.xz.asc
Download Error: Download Error: 404 Not Found 
--8<---cut here---end--->8---


-- System Information:
Debian Release: 9.0
  APT prefers stable
  APT policy: (500, 'stable'), (70, 'unstable'), (60, 'testing'), (50, 
'experimental'), (40, 'oldstable')
Architecture: amd64
 (x86_64)

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

Versions of packages torbrowser-launcher depends on:
ii  ca-certificates  20161130+nmu1
ii  gnupg2.1.21-2
ii  python-gtk2  2.24.0-5.1
ii  python-lzma  0.5.3-3
ii  python-parsley   1.2-1
ii  python-psutil5.0.1-1
ii  python-twisted   17.1.0-1
ii  python-txsocksx  1.15.0.2-1
pn  python:any   
ii  wmctrl   1.07-7+b1

Versions of packages torbrowser-launcher recommends:
ii  tor  0.3.0.8-1

Versions of packages torbrowser-launcher suggests:
ii  apparmor   2.11.0-3
pn  python-pygame  

-- no debconf information

Bug#834015: phpldapadmin: fails to install: ln: failed to create symbolic link '/etc/apache2/conf-available/phpldapadmin.conf': No such file or directory

[Gerald Turner]

Control: tags -1 + patch

Dear Maintainer,

In preparation for upgrading several hosts from jessie to stretch, my
colleague and I discovered that phpldapadmin was removed from stretch
due to this bug.

Attached is a trivial one-line patch that solves the piuparts postisnt
failure by ensuring path /etc/apache2/mods-available is installed by the
package.  I verified that this is what other 'a2enconf' style packages
are doing.  I've also verified that piuparts is successful (but there's
a caveat¹).


¹ Caveat: piuparts now fails for another reason, but I believe it's a
problem with php7.0.  I ran piuparts on phpmyadmin and had the same
results.

Output:

0m55.8s ERROR: FAIL: Package purging left files on system:
  /var/lib/php/   owned by: php-common
  /var/lib/php/modules/owned by: php-common
  /var/lib/php/modules/7.0/ not owned
  /var/lib/php/modules/7.0/apache2/not owned
  /var/lib/php/modules/7.0/apache2/enabled_by_maint/ not owned
  /var/lib/php/modules/7.0/apache2/enabled_by_maint/calendar not owned
  ...

-- 
Gerald Turner Encrypted mail preferred!
OpenPGP: 4096R / CA89 B27A 30FA 66C5 1B80  3858 EC94 2276 FDB8 716D
From 5baf2008b598c929be011d4f4b76698583f8a72a Mon Sep 17 00:00:00 2001
From: Gerald Turner 
Date: Thu, 15 Jun 2017 10:53:14 -0700
Subject: [PATCH] Install /etc/apache2/conf-available directory so postinst
 does not fail (Closes: #834015)

---
 debian/dirs | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/dirs b/debian/dirs
index 55fe3fb..5d3ea56 100644
--- a/debian/dirs
+++ b/debian/dirs
@@ -5,3 +5,4 @@ etc/phpldapadmin
 etc/phpldapadmin/templates
 etc/phpldapadmin/templates/creation
 etc/phpldapadmin/templates/modification
+etc/apache2/conf-available
-- 
2.11.0



signature.asc
Description: PGP signature

Bug#864840: error: cannot overload functions distinguished by return type alone

[Jorge Moraleda]

Package: nvidia-cuda-dev
Version: 8.0.44-4
Severity: important

Dear Maintainer,

The header file math_functions.h is not compatible with gcc 6.3 shipped with 
stretch. In particular, when this header is included in a cuda project the 
following errors are reported:

/usr/include/math_functions.h(8897): error: cannot overload functions 
distinguished by return type alone

/usr/include/math_functions.h(8901): error: cannot overload functions 
distinguished by return type alone

The solution is to comment out the offending lines (which is completely 
harmless since the lines are work arounds an issue with gcc 6.1 as mentioned in 
the source itself). The following is a diff of the modified file and original 
file:

diff /usr/include/math_functions.h /usr/include/math_functions.h~
8897c8897
< //__DEVICE_FUNCTIONS_DECL__ __cudart_builtin__ int isnan(double x) throw();
---
> __DEVICE_FUNCTIONS_DECL__ __cudart_builtin__ int isnan(double x) throw();
8901c8901
< //__DEVICE_FUNCTIONS_DECL__ __cudart_builtin__ int isinf(double x) throw();
---
> __DEVICE_FUNCTIONS_DECL__ __cudart_builtin__ int isinf(double x) throw();

This problem also occurred in Fedora 24 and was solved the same way as can be 
seen at: https://xpra.org/trac/ticket/1328

Thank you very much. Best regards,

Jorge Moraleda

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing'), (200, 'unstable'), (100, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages nvidia-cuda-dev depends on:
ii  libcublas8.08.0.44-4
ii  libcudart8.08.0.44-4
ii  libcufft8.0 8.0.44-4
ii  libcufftw8.08.0.44-4
ii  libcuinj64-8.0  8.0.44-4
ii  libcurand8.08.0.44-4
ii  libcusolver8.0  8.0.44-4
ii  libcusparse8.0  8.0.44-4
ii  libnppc8.0  8.0.44-4
ii  libnppi8.0  8.0.44-4
ii  libnppial8.08.0.44-4
ii  libnppicc8.08.0.44-4
ii  libnppicom8.0   8.0.44-4
ii  libnppidei8.0   8.0.44-4
ii  libnppif8.0 8.0.44-4
ii  libnppig8.0 8.0.44-4
ii  libnppim8.0 8.0.44-4
ii  libnppist8.08.0.44-4
ii  libnppisu8.08.0.44-4
ii  libnppitc8.08.0.44-4
ii  libnpps8.0  8.0.44-4
ii  libnvblas8.08.0.44-4
ii  libnvgraph8.0   8.0.44-4
ii  libnvrtc8.0 8.0.44-4
ii  libnvtoolsext1  8.0.44-4
ii  libnvvm38.0.44-4
ii  libthrust-dev   1.8.1-1

Versions of packages nvidia-cuda-dev recommends:
ii  libcuda1 [libcuda-8.0-1] 375.66-1
ii  libgl1-mesa-dev [libgl-dev]  13.0.6-1+b2
ii  libnvcuvid1  375.66-1
ii  libvdpau-dev 1.1.1-6

nvidia-cuda-dev suggests no packages.

-- no debconf information

Bug#864597: upgrade-reports: jessie -> stretch: gnome fails to upgrade: cycle found while processing triggers

[Bill Allombert]

On Thu, Jun 15, 2017 at 03:16:17PM +0200, Cyril Brulebois wrote:
> Julien Cristau  (2017-06-15):
> > It sounds like openjdk-8 added two Breaks recently, one or both of
> > which are causing trouble, and none of which fix anything as bad as
> > this.  So I think we should remove the Breaks on tzdata-java from
> > openjdk-8-jdk-headless, and remove the Breaks on ca-certificates-java
> > from openjdk-8-jre-headless.  Would that fix the current issue?
> > 
> > From what I can see #863820 is at most a normal-severity issue.  Not
> > upgrading some packages is way way better than a failed upgrade.
> 
> I'm currently building an updated openjdk-8 with the attached changes
> to see what the upgrade-desktop test cases would look like.
> 
> Note: I've chosen to remove the “Breaks: ${jrehl:Breaks}” line from
> debian/control* so that I'm only touching these files, since d/rules
> seems to only set it to tzdata-java anyway, depending on the target
> dist.
> 
> I'll report the results afterwards, but as mentioned on IRC, even if
> that looks good in the end, fewer than 2 days to become confident it
> won't regress in other cases is really short. :(

It would be really nice if we could remove the circular dependency 
between openjdk-8 and ca-certificate before the release, otherwise
the stretch to buster upgrade will be a nightmare.
It always much easier to add circular dependency than to remove them.

Cheers,
Bill.

Bug#864597: upgrade-reports: jessie -> stretch: gnome fails to upgrade: cycle found while processing triggers

[Emmanuel Bourg]

Le 15/06/2017 à 18:09, Cyril Brulebois a écrit :

> If all succeed, I intend to NMU ca-certificates-java with the attached
> changes. I could have reintroduced the old package, but I chose to retain
> the svn to git changes, and to drop the version for the openjdk-7 case,
> since even jessie had a higher version. Attached debdiffs against current
> version, and previous one.

Is this the only solution? That's a bit odd to retain the openjdk-7
dependency on ca-certificates-java and potentially stick with it
forever. Maybe we should simply remove the JRE dependency on
ca-certificates-java and move the keystore generation to openjdk-8. That
would also solve the circular dependency (#864657).

If you upload a NMU could you please push the changes to the Git repository?

Emmanuel Bourg

Bug#864802: unblock: squashfs-tools/1:4.3-4

[Niels Thykier]

Control: tags -1 moreinfo

László Böszörményi (GCS):
> Package: release.debian.org
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Hi Release Team,
> 
> There are two data corruption bug in squashfs-tools that fixed in the
> last upload for Sid.

Hi,

Thanks for fixing it and notifying us.

> I let it age seven days even if the fixes quite
> straightforward.
> 

This was a very unfortunate choice.  We are way past the deadline for
fixes to stretch.  If you had come to us Thursday or Friday last week
(i.e. around the time of the upload),  granting an exception would have
been a lot easier for us (like aggressive aging).

 * Done is done. I am mentioning it for the next release.  Please be
   mindful of deadlines.

For the fixes themselves, they look like something we would very much
like to have in stretch.  Please consider submitting them for the stable
upload after the release.

Thanks,
~Niels

Bug#863436: #863436 - No success: Even after deleting ALL Partitions from the Harddrive

[Harrison]

I do not know how much more "pristine" I can make the test environment. 
Even after deleting ALL Partitions from the Harddrive during the
Debian-9-RC4 install, I still cannot create Grub2 Menuentries that
Display on the Boot Menu?  I could on Debian-8 releases.

Bug#794890: [Pkg-javascript-devel] Bug#794890: Bug#794890: status update

[Dominique Dumont]

On Tuesday, 13 June 2017 10:49:29 CEST Jérémy Lal wrote:
> - populate debian/copyright (including everything in node_modules as well),
> it shouldn't be that difficult.
> 
> With this approach the only maintenance burden will be to update
> debian/copyright.

Hopefully cme can help in creating and updating debian/copyright file

See [1] for instructions

All the best

[1] 
https://github.com/dod38fr/config-model/wiki/Updating-debian-copyright-file-with-cme

-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org

Bug#864839: RFS: yices2/2.6.0-2 [ITP]

[Ian A Mason]

Package: sponsorship-requests
  Severity: normal [important for RC bugs, wishlist for new packages]

  Dear mentors,

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

 * Package name: yices2
   Version : 2.6.0-2
   Upstream Author : Bruno Dutertre 
 * URL : yices.csl.sri.com
 * License : GPL-3.0
   Section : misc

  It builds those binary packages:

 libyices2.6 - Yices SMT Solver API Library
 yices2 - Yices SMT Solver
 yices2-dbg - Yices SMT Solver
 yices2-dev - C library for manipulating multivariate polynomials

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

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


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

dget -x 
https://mentors.debian.net/debian/pool/main/y/yices2/yices2_2.6.0-2.dsc

  More information about hello can be obtained from https://www.example.com.

  Changes since the last upload:

  None.


  Regards,
   Ian A. Mason

Bug#864838: RFS: libpoly0/1.3-2 [ITP]

[Ian A Mason]

Package: sponsorship-requests
  Severity: normal [important for RC bugs, wishlist for new packages]

  Dear mentors,

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

 * Package name: libpoly0
   Version : 1.3-2
   Upstream Author : Dejan Jovanović 
 * URL : https://github.com/SRI-CSL/libpoly
 * License : LGPL-3.0
   Section : libs

  It builds those binary packages:

 libpoly-dbg - C library for manipulating multivariate polynomials
 libpoly-dev - C library for manipulating multivariate polynomials
 libpoly0   - C library for manipulating multivariate polynomials

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

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


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

dget -x 
https://mentors.debian.net/debian/pool/main/libp/libpoly0/libpoly0_1.3-2.dsc

  More information about hello can be obtained from https://www.example.com.

  Changes since the last upload:

  None.


  Regards,
   Ian A. Mason

Bug#864837: screenreader stops speaking

[Mika Hanhijärvi]

Package: gnome-orca
Version: 3.22.2-3
Severity: grave

Hi

I am sorry that I repport this so close to release of Stretch.

I am not really sure to which package I should report this bug. I am not sure
if this bug is in Orca, Pulseaudio, speech-dispatcher or someething else. I
think it might be problem with Pulseaudio, or maybe not. Really do not know.

Note that I tryed to send this bug report earlier but my laptop did run out of
battery when reportbug was sending the bug report so bug report probably was
not sent. I first tryed to send itthe bug report to pulseaudio, but I am now
thinking that maybe I should reportit o Orca so that Debian accessibility guys
get notified about this. I am really sorry if thiscauses mess and a duplicate
bug report to two packages.

I am blind so I have to use computer using the screen reader. So it is
important for me that screen reader works relealibly.

I have espeakup and Orca installed. I would like to use espeakup on console and
Orca on desktop. I also would like to be able to switch between text mode
console and graphical nome desktop without logging out from the desktop.
Currently that does not work. I have two laptops and both have this problem.
Note that I have not made clean Stretch installation, Ihave upgraded my systems
to Stretch.


For some reason if espeakup sppeaks something when the computer is booting then
screen reader does not speak anytging on GDM login screen. If that happens then
screen reader also does not speak at all on desktop. This makes it impossible
for me to login to desktop or use the deshtop. I have noticed that if I go to
text console then eseakup speaks just fin.

If espeakup does not speak anytging then screen reader speaks on GDM login
screen. If I go to text console then espeakup does not speak at all. If I login
to desktop then Orca screen reader speaks just fine. If I login to desktop then
this also happens: If I switch from desktop to GDM login screen thusing the
ctrl + alt + f1 then screen reader does not speak on GDM login screen at all.
If I then return to desktop then Orca screen reader on desktop speaks again
just fine. If I switch form desktop to text console using e.g ctrl + alt + f3
then espeakup does not speak at all on console. If I then switch back to
desktothen Orca speaks again on desktop just fine.


If I logout from desktop to gdm login screen then screen reader speaks on gdm
login screen.

So it seems that the sc reader works just on one of the following views:
console, gdm or desktop. It is not possible to switch between those. That is
not good.



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

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

Versions of packages gnome-orca depends on:
ii  gir1.2-glib-2.01.50.0-1+b1
ii  gir1.2-gtk-3.0 3.22.11-1
ii  gir1.2-pango-1.0   1.40.5-1
ii  gir1.2-wnck-3.03.20.1-3
ii  gsettings-desktop-schemas  3.22.0-1
ii  python33.5.3-1
ii  python3-brlapi 5.4-7
ii  python3-cairo  1.10.0+dfsg-5+b1
ii  python3-gi 3.22.0-2
ii  python3-louis  3.0.0-3
ii  python3-pyatspi2.20.3+dfsg-1
ii  python3-speechd0.8.6-4
ii  speech-dispatcher  0.8.6-4

Versions of packages gnome-orca recommends:
ii  libgail-common  2.24.31-2
ii  xbrlapi 5.4-7

gnome-orca suggests no packages.

-- no debconf information

Bug#863309: curvedns RFS

[Stéphane Neveu]

Hi Gianfranco,

curvedns is on alioth :
https://anonscm.debian.org/cgit/pkg-security/curvedns.git/
I've made some changes but the blhc issue is still here :/
Thanks for your help !

Stephane

2017-06-14 17:57 GMT+02:00 Stéphane Neveu :
> Gianfranco, Philippe,
>
> I've just pushed my updated package on mentors again, because my ssh
> key isn't working on alioth yet...
>
>>> lets review:
>>>
>>>
>>> debian/copyright has some GPL-2 packaging, why not just take the same
>>> upstream license
>>>
>>> for the packaging?
>>>
>
> license-reconcile told me to do so but following your advice I've
> changed everything to BSD-2-clause.
>
>
>>>
>>> lots of useless files?
>>>
>>> debian/README.source
>>>
>>> debian/README.Debian
>>>
>>> debian/service
>>> debian/env
>>>
>>> (and so on)
>>>
>
> yes, all those files are deleted now sorry.
>
>>>
>>> and lots of debian files, e.g. is debian/dirs needed?
>>>
>>> (usually it is a task for the upstream build system to install
>>> directories)
>>>
>
> Yes no automated install.
>
>>> override_dh_installinit:
>>> dh_installinit
>>>
>
> Sorry deleted.
>
>>>
>>>
>>> I will continue the review after the above is fixed
>>>
>>>
>>> some CPPFLAGS seems missing?
>>>
>>> http://debomatic-amd64.debian.net/distribution#unstable/curvedns/0.87-1/blhc
>>>
>
> Yes I still have this issue, I made a patch but it doesn't seem to fix blhc.
>
>>> and some stuff is uselessly installed in the end user system (e.g. README
>>> files)
>>>
>>>
>>> (the packaging looks good, but I prefer less files to review, if
>>> something can be just
>>> deleted)
>>>
>>> G.
>>
>
> Thank you Gianfranco !
>
>>
>> Little review:
>>
>>
>> $ splint -I . +posixlib -preproc -standard *.c
>> ... And one memory leak :-/
>>
>
> Philippe, like we said no need to patch it since it only affect init cache.
>
>> $ env PERL5OPT=-m-lib=. license-reconcile
>> Copyright mismatch: File
>> nacl/crypto_scalarmult/curve25519/donna_c64/smult.c: Trying to match 'Google
>> Inc.' against 'Lieuwe Jan Koning' but it does not look like a good match. at
>> /usr/share/perl5/Debian/LicenseReconcile/App.pm line 222,  line 3.
>>
>
> Google Inc. is added but license-reconcile isn't happy now for
> debian/* with my BSD-2-clause license.
>
>>
>> $ find . -type d \( -iname .bzr -o -iname .git -o -iname .hg -o -iname .svn
>> -o -iname CVS -o -iname RCS -o -iname SCCS -o -iname _MTN -o -iname _darcs
>> -o -iname .pc -o -iname .cabal-sandbox -o -iname .cdv -o -iname .metadata -o
>> -iname CMakeFiles -o -iname _build -o -iname  _sgbak -o -iname
>> autom4te.cache -o -iname blib -o -iname cover_db -o -iname node_modules -o
>> -iname '~.dep' -o -iname '~.dot' -o -iname '~.nib' -o -iname '~.plst' \)
>> -prune -o -type f ! \( -iname '*.bak' -o  -iname '*.swp' -o -iname '#.*' -o
>> -iname '#*#' -o -iname 'core.*' -o -iname '*~' -o -iname '*.gif' -o -iname
>> '*.jpg' -o -iname '*.jpeg' -o  -iname '*.png' -o -iname '*.min.js' -o -iname
>> '*.js.map' -o -iname '*.js.min' -o -iname '*.min.css' -o -iname '*.css.map'
>> -o -iname  '*.css.min' -o -iname '*.wav' \) -exec env PERL5OPT=-m-lib=.
>> spellintian --picky {}
>> 
>>
>> (thanks to Paul Wise for this last line :) )
>>
>> Didn't try lintian/piuparts/blhc...
>>
>
> No more errors except in spelling.patch :)
>
>> Cheers,
>> --
>> Philippe.
>
>
> I also need to work a bit on curvedns.service to add some security features !
>
>
> Stephane

Bug#864788: [pkg-gnupg-maint] Bug#864788: cache TTL values ignored for smartcard PINs

[Daniel Kahn Gillmor]

On Wed 2017-06-14 23:26:22 +0200, martin f krafft wrote:
> also sprach Teemu Likonen  [2017-06-14 22:48 +0200]:
>> That's because the OpenPGP card (Yubikey) itself goes to authenticated
>> mode and don't require the PIN anymore.
>
> If that's the case — thanks for putting it so concisely — then why
> does killing gpg-agent mean having to enter a PIN the next time
> around? 

I believe that killing gpg-agent kills scdaemon, which de-initializes
the smartcard on shutdown, which takes it out of authenticated mode.

I suppose that scdaemon could be taught to de-initialize the smartcard
after expiration of the ttl, though.  maybe gniibe (cc'ed) could comment
on whether that's feasible or not.  it would be nice to have the
semantics of the cache ttl be the same, regardless of whether a key is
stored on a smartcard or not.

   --dkg


signature.asc
Description: PGP signature

Bug#864480: why is en_DK included but not en_DE?

[Samuel Thibault]

Marc Haber, on jeu. 15 juin 2017 18:07:07 +0200, wrote:
> On Fri, Jun 09, 2017 at 12:15:15PM +0200, Marc Haber wrote:
> > On Fri, Jun 09, 2017 at 11:14:20AM +0200, Samuel Thibault wrote:
> > > So what you want is actually LC_LANG=de_DE LANGUAGE=en, right?
> > 
> > If all software was correct, yes. I have a few programs from the GNOME
> > ecosystem that still insist on their German l10n with this setting.
> > 
> > I must admit that I have never fully understood all the locale stuff in
> > Unix :-(
> 
> I tried reading up on this again. Which man page should I read aside
> from locale (5) and locale(7), which does explain a bunch of LC_foo, but
> neither LC_LANG nor LANGUAGE?

Sorry, LC_LANG was a typo, I should have written LANG.
LANGUAGE is documented in info gettext.

Samuel

Bug#862057: Fwd: Fwd: Bug#862057: udev: If more than one NIC the system is booting longer

[Michael Biebl]

Control: tags -1 + unreproducible

On Mon, 29 May 2017 20:53:05 +0200 a a  wrote:
> 
>  type="virtio">
>   
> 
>  type="virtio">
>   
> 
>   
>   
> 
>  type="virtio">
>   
> 
>   
>   
> 
>  type="virtio">
>   
> 
>   
>   
> 
> 
> 
> 
> 
>   

I tried with exactly this configuration and could not reproduce the
problem in an up-to-date, newly installed stretch vbox VM.

Can you post a complete log file / dmesg output from your boot?
Increasing the log level of udev (See /etc/udev/udev.conf) might help
produce a more detailed log.

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



signature.asc
Description: OpenPGP digital signature

Bug#864835: update symbols for libasan and libubsan

[Helmut Grohne]

Source: gcc-7
Version: 7.1.0-6
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

Hi Matthias,

the symbols for libasan and libubsan are still wrong for a couple of
architectures including sparc, sparc64, x32 and a few more. The build
doesn't fail, because errors from dh_makeshlibs are still being
ignored[1]. Maybe it is time to change that?

After consulting gcc's source code I believe that the following
statements correct the symbols:

sed -i -e 
'/__sanitizer_print_memory_profile/s/([^)]*)/(arch=base-any-linux-amd64 
base-any-linux-arm64 any-linux-mips64 any-linux-mips64el)/' 
debian/libasan.symbols.64
sed -i -e '/internal_sigreturn/s/([^)]*)/(arch=base-any-any-amd64 any-mips 
any-mipsel)/' debian/libasan4.symbols
sed -i -e '/internal_sigreturn/s/([^)]*)/(arch=base-any-any-amd64 any-mips 
any-mipsel)/' debian/libubsan0.symbols

It fixes at least x32. It may not be completely correct. I'll put it to
wider testing and see what happens.

Helmut

[1] http://sources.debian.net/src/gcc-7/7.1.0-6/debian/rules.defs/#L280

Bug#864836: emacs24: common lisp aliases not loaded

[John van der Kamp]

Package: emacs24
Version: 24.5+1-11
Severity: normal

Dear Maintainer,

I was unable to use company-rtags package, because functions like caadr and
cadadr are unavailable. M-x describe-function does not result in a function.
Evaluating this:

(caadr '((a b) (c d)))

returns the error: Symbol's function definition is void: caadr

Putting cl-caadr as function does work, so cl-lib.el is loaded. when I evaluate
(require 'cl) then the caadr function does work too.
I added this as a workaround to my .emacs file, but flycheck returns a warning
saying: cl package required at runtime
So I feel this workaround should be unnecessary. On an ubuntu 16.04 machine
(with seemingly the same emacs packages) it does work out of the box.
On a new debian stable install I get the wrong behavior too, so it seems it's
not just my current installation only.

Is there a reason cl is not loaded on startup?

John



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

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

Versions of packages emacs24 depends on:
ii  emacs24-bin-common 24.5+1-11
ii  gconf-service  3.2.6-4+b1
ii  libacl12.2.52-3+b1
ii  libasound2 1.1.3-5
ii  libatk1.0-02.22.0-1
ii  libc6  2.24-11
ii  libcairo-gobject2  1.14.8-1
ii  libcairo2  1.14.8-1
ii  libdbus-1-31.10.18-1
ii  libfontconfig1 2.11.0-6.7+b1
ii  libfreetype6   2.6.3-3.2
ii  libgconf-2-4   3.2.6-4+b1
ii  libgdk-pixbuf2.0-0 2.36.5-2
ii  libgif75.1.4-0.4
ii  libglib2.0-0   2.50.3-2
ii  libgomp1   6.3.0-18
ii  libgpm21.20.4-6.2+b1
ii  libgtk-3-0 3.22.11-1
ii  libice62:1.0.9-2
ii  libjpeg62-turbo1:1.5.1-2
ii  libm17n-0  1.7.0-3+b1
ii  libmagickcore-6.q16-3  8:6.9.7.4+dfsg-11
ii  libmagickwand-6.q16-3  8:6.9.7.4+dfsg-11
ii  libotf00.9.13-3+b1
ii  libpango-1.0-0 1.40.5-1
ii  libpangocairo-1.0-01.40.5-1
ii  libpng16-161.6.28-1
ii  librsvg2-2 2.40.16-1+b1
ii  libselinux12.6-3+b1
ii  libsm6 2:1.2.2-1+b3
ii  libtiff5   4.0.8-2
ii  libtinfo5  6.0+20161126-1
ii  libx11-6   2:1.6.4-3
ii  libxft22.3.2-1+b2
ii  libxinerama1   2:1.1.3-1+b3
ii  libxml22.9.4+dfsg1-2.2
ii  libxpm41:3.5.12-1
ii  libxrandr2 2:1.5.1-1
ii  libxrender11:0.9.10-1
ii  zlib1g 1:1.2.8.dfsg-5

emacs24 recommends no packages.

Versions of packages emacs24 suggests:
pn  emacs24-common-non-dfsg  

-- no debconf information

Bug#864597: upgrade-reports: jessie -> stretch: gnome fails to upgrade: cycle found while processing triggers

[Cyril Brulebois]

Cyril Brulebois  (2017-06-15):
> I was just saying this on IRC:
> 
> “should I try to reinstate ca-certificates-java's old dependencies and
> compare? from my initial bug report, that's the change in the archive
> that led to the regression.”
> 
> and mentioned earlier that given the old dependencies have an OR anyway,
> we shouldn't be introducing an uninstallable package. This would have
> the nice effect of being a solution that can be implemented in hours
> instead of days (given openjdk-8's build time). This doesn't mean we
> should jump the gun anyway…
> 
> I'll report back.

This is looking good so far: gnome upgrade path fixed, kde and xfce are
still looking good, and tests with other desktop tasks are still running.

If all succeed, I intend to NMU ca-certificates-java with the attached
changes. I could have reintroduced the old package, but I chose to retain
the svn to git changes, and to drop the version for the openjdk-7 case,
since even jessie had a higher version. Attached debdiffs against current
version, and previous one.


KiBi.
diff -Nru ca-certificates-java-20170531/debian/changelog ca-certificates-java-20170531+nmu1/debian/changelog
--- ca-certificates-java-20170531/debian/changelog	2017-05-31 15:02:23.0 +0200
+++ ca-certificates-java-20170531+nmu1/debian/changelog	2017-06-15 17:33:00.0 +0200
@@ -1,3 +1,13 @@
+ca-certificates-java (20170531+nmu1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * Revert to depending on openjdk-7 instead of openjdk-8, since this triggers
+a failure to dist-upgrade, due to the triggers loop (See: #864597). The
+openjdk-7 package was dropped from stretch, but the java7-runtime-headless
+alternative dependency is satisfied by openjdk-8.
+
+ -- Cyril Brulebois   Thu, 15 Jun 2017 17:33:00 +0200
+
 ca-certificates-java (20170531) unstable; urgency=medium
 
   * Team upload.
diff -Nru ca-certificates-java-20170531/debian/rules ca-certificates-java-20170531+nmu1/debian/rules
--- ca-certificates-java-20170531/debian/rules	2017-05-31 15:00:28.0 +0200
+++ ca-certificates-java-20170531+nmu1/debian/rules	2017-06-15 17:31:24.0 +0200
@@ -6,11 +6,11 @@
 
 ifeq ($(shell dpkg-vendor --derives-from Ubuntu && echo yes),yes)
 	SUBSTVARS = -Vnss:Depends="libnss3 (>= 3.12.9+ckbi-1.82-0ubuntu3~)" \
--Vjre:Depends="openjdk-8-jre-headless"
+-Vjre:Depends="openjdk-7-jre-headless"
 	nss_lib = libnss3
 else
 	SUBSTVARS = -Vnss:Depends="libnss3 (>= 3.12.10-2~)" \
--Vjre:Depends="openjdk-8-jre-headless"
+-Vjre:Depends="openjdk-7-jre-headless"
 	nss_lib = libnss3
 endif
 
diff -Nru ca-certificates-java-20161107/debian/changelog ca-certificates-java-20170531+nmu1/debian/changelog
--- ca-certificates-java-20161107/debian/changelog	2016-11-07 13:45:23.0 +0100
+++ ca-certificates-java-20170531+nmu1/debian/changelog	2017-06-15 17:33:00.0 +0200
@@ -1,3 +1,21 @@
+ca-certificates-java (20170531+nmu1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * Revert to depending on openjdk-7 instead of openjdk-8, since this triggers
+a failure to dist-upgrade, due to the triggers loop (See: #864597). The
+openjdk-7 package was dropped from stretch, but the java7-runtime-headless
+alternative dependency is satisfied by openjdk-8.
+
+ -- Cyril Brulebois   Thu, 15 Jun 2017 17:33:00 +0200
+
+ca-certificates-java (20170531) unstable; urgency=medium
+
+  * Team upload.
+  * Depend on openjdk-8 instead of openjdk-7 (Closes: #863803)
+  * Moved the package to Git
+
+ -- Emmanuel Bourg   Wed, 31 May 2017 15:02:23 +0200
+
 ca-certificates-java (20161107) unstable; urgency=medium
 
   * Team upload.
diff -Nru ca-certificates-java-20161107/debian/control ca-certificates-java-20170531+nmu1/debian/control
--- ca-certificates-java-20161107/debian/control	2016-11-07 13:41:49.0 +0100
+++ ca-certificates-java-20170531+nmu1/debian/control	2017-05-31 15:00:11.0 +0200
@@ -8,8 +8,8 @@
James Page 
 Build-Depends: debhelper (>= 9), default-jdk, javahelper, junit4
 Standards-Version: 3.9.8
-Vcs-Svn: svn://anonscm.debian.org/pkg-java/trunk/ca-certificates-java
-Vcs-Browser: https://anonscm.debian.org/viewvc/pkg-java/trunk/ca-certificates-java/
+Vcs-Git: https://anonscm.debian.org/git/pkg-java/ca-certificates-java.git
+Vcs-Browser: https://anonscm.debian.org/cgit/pkg-java/ca-certificates-java.git
 
 Package: ca-certificates-java
 Architecture: all
diff -Nru ca-certificates-java-20161107/debian/rules ca-certificates-java-20170531+nmu1/debian/rules
--- ca-certificates-java-20161107/debian/rules	2016-03-21 14:05:28.0 +0100
+++ ca-certificates-java-20170531+nmu1/debian/rules	2017-06-15 17:31:24.0 +0200
@@ -6,7 +6,7 @@
 
 ifeq ($(shell dpkg-vendor --derives-from Ubuntu && echo yes),yes)
 	SUBSTVARS = -Vnss:Depends="libnss3 (>= 3.12.9+ckbi-1.82-0ubuntu3~)" \
-

Bug#864480: why is en_DK included but not en_DE?

[Marc Haber]

On Fri, Jun 09, 2017 at 12:15:15PM +0200, Marc Haber wrote:
> On Fri, Jun 09, 2017 at 11:14:20AM +0200, Samuel Thibault wrote:
> > So what you want is actually LC_LANG=de_DE LANGUAGE=en, right?
> 
> If all software was correct, yes. I have a few programs from the GNOME
> ecosystem that still insist on their German l10n with this setting.
> 
> I must admit that I have never fully understood all the locale stuff in
> Unix :-(

I tried reading up on this again. Which man page should I read aside
from locale (5) and locale(7), which does explain a bunch of LC_foo, but
neither LC_LANG nor LANGUAGE?

Greetings
Marc

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

Bug#864766: [Pkg-emacsen-addons] Bug#864766: Bug#864766: elpa-circe: extract tracking from the rest of circe

[Sean Whitton]

control: severity -1 wishlist

On Wed, Jun 14, 2017 at 12:21:12PM -0300, David Bremner wrote:
> I think upstream is probably fine with the split. See
> 
>   https://github.com/jorgenschaefer/circe/issues/258

Thanks for this.  In that case, circe /should/ be split, so this is not
wishlist.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#864834: [ITP] libpoly -- a C library for manipulating polynomials

[Ian A Mason]

Package: wnpp
Severity: wishlist
Control: owner -1 !

Bug#859778: [supp...@mentors.debian.net: xtrs uploaded to mentors.debian.net]

[Sean Whitton]

control: tag -1 +moreinfo

Dear Branden,

Please accept my apologies for letting this RFS sit for so long.  Thank
you for all your work.  Looking forward to uploading it soon.

Here's a full review of dc84e1861798b3aba0969e2fe81a2431f2ee17de:

Should be fixed
===

1. Maybe we should just upload to unstable, DELAYED/7, because the
freeze will be over this weekend?  Would save another RFS next week.

2. Lintian says

W: xtrs source: file-without-copyright-information .gitignore

.gitignore is not copyrightable, so there is no bug, but I think it
would be best to add a Lintian override.  Then the package will be
Lintian-clean.

3. The orig.tar doesn't seem to be the same as the one available from
upstream:

zephyr ~ % shasum tmp/xtrs-4.9d.tar.gz rfs/xtrs_4.9d.orig.tar.gz
72b99ede6e8024b8ade4f8aa22eb073078576e74  tmp/xtrs-4.9d.tar.gz
42b1fc90246901456d29071421e838b545f39f0f  rfs/xtrs_4.9d.orig.tar.gz

Do you know why?  (I'm working from git, but I grabbed the orig.tar from
mentors.)

4. A few things not mentioned in the changelog:

   - new d/clean
   - new d/watch
   - deleted d/dirs
   - debhelper compat bump
   - rewrite d/rules & switch to use dh sequencer (not the same as
 compat bump)
 - add d/xtrs.install
   - std-ver bump (it would be reassuring to see "no changes required")
   - new build deps, e.g. bsdmainutils (btw, really nice commenting of
 the build-deps)
   - postinst tidied up (changes to maintscripts should always be
 mentioned in the changelog, since they are such a frequent source
 of bugs)
   - various patches in d/patches are not in d/changelog.  it might also
 be a good idea to give the patch name, instead of just the file
 modified, so someone can track down the change

5. Copyright file issues:

   - id.po and nl.po seem to have broken template "Copyright (C)" lines.

   - you need entries in d/copyright for the *.po files.  Or you could just
  add the author's names to the stanza for debian/*.

   - The FSF hold copyright on some code in *-idiomatize-manpage.patch

Suggestions
===

1. You could use debhelper compat 10.

2. You could uncomment Vcs-* and fill in the address of your alioth
repo.

3. Typo "appply" in xtrs.doc-base.cpmutil.

4. I think that cpmutil.dsk and utility.dsk should go into
/usr/share/xtrs not /usr/lib/xtrs, since they are binary but not
architecture-dependent

5. emtsafe-flag-on-by-default.patch would benefit from a description
explaining why it's a good idea.

If you're able to address the issues I've raised in this message, please
remove the moreinfo tag in this bug, and don't forget to re-run `dch -r`
to refresh the changelog timestamp.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#864807: debian-installer: Lamobo R1 requires modprobe b53_mdio

[Heinrich Schuchardt]

On 06/15/2017 12:57 PM, Karsten Merker wrote:
> Cyril Brulebois wrote:
>> On Thu, Jun 15, 2017 at 10:43:18AM +0100, Ben Hutchings wrote:
>>> Control: tag -1 moreinfo
>>>
>>> On Thu, 2017-06-15 at 08:34 +0200, Heinrich Schuchardt wrote:
 Package: debian-installer
 Version: stretch
 Severity: normal

 Dear Maintainer,

 the Lamobo R1 is an Arm system based on the Amlogic A20.
 The network interface of the A20 is connected to a switch.
 If the switch is not configured there is no external
 network access and subsequently a network install fails.

 On an installed system it is sufficient to have a line
 in /etc/modules:
 b53_mdio

 I suggest the following corrections to the installer:

 The initrd.img should include the b53_mdio module and its
 prerequisites b53_common and dsa_core plus aforementioned
 file /etc/modules.

 The installer should compare the content of
 /proc/device-tree/model
 to the string
 Lamobo R1

 If this string is found, the file /etc/modules should be
 appended with b53_mdio on the installed system.
>>>
>>> Why is this necessary?  It should load automatically.
>>
>> Because of missing i2c? Lamobo R1 is listed here:
>>   https://bugs.debian.org/864536#15
>>
>> (Didn't check the recursive list of dependencies though.)
> 
> If I understood the original submitter correctly, the problem
> also exists in the installed system, not only in d-i.  The
> i2c-modules udeb issue (or other modules unavailable in the udebs
> but available in the regular kernel deb) would explain problems
> inside d-i, but not in the installed system.
> 
> Heinrich, can you clarify on that?
> 
> Regards,
> Karsten
> 

Yes, the problems exists both in the installer and in an installed system.

I set up the installed system via debootstrap:
https://github.com/xypron/debian-image-lamobo-r1/commit/8fa1b7cb3a0cc2bfd44475d0c9972115ffb82e15

Best regards

Heinrich Schuchardt

Bug#853783: Failed to open hpaio:/net/HP_Color_Laserjet_MFP_M277DW?ip=194.168.1.4: Error during device I/O

[Brian Potkin]

On Wed 14 Jun 2017 at 21:19:11 +0200, Martin Heine wrote:

> I am using Ubuntu 16.04.2. Kernel Version 4.8.0-52-generic
> #55~16.04.1-Ubuntu SMP Fri Apr 28 14:36:29 UTC 2017 x86_64 x86_64 x86_64
> GNU/Linux

It probably doesn't make any difference but we'd have expected Debian to
be being used.
 
> sage@z620:~$ scanimage -L
> device `brother4:net1;dev0' is a Brother DCP-9022CDW DCP-9022CDW
> device `hpaio:/net/HP_Color_LaserJet_MFP_M277dw?ip=192.168.178.29' is a
> Hewlett-Packard HP_Color_LaserJet_MFP_M277dw all-in-one
>
> Before the installation of the Brother DCP-9022CDW, the HP MFP_M277 scanner
> ran perfectly fine. Now, The HP is no more working, but the Brother scanner
> does. Both devices are connected via network.

Your device has AirPrint. scanimage has picked up its DNS-SD broadcasts
from 192.168.178.29.

scanimage -d "hpaio:/net/HP_Color_LaserJet_MFP_M277dw?ip=192.168.178.29" > 
scan.pnm

should give you a file which is viewable with imagemagick.

You should also be able to scan from the device's web interface.
 
> I just ran into that bug report, when I was trying to solve the HP problem
> after brscan4 installation and thought maybe it helps. I already informed
> Brother Company about this issues and hope they are working on a bug fix of
> their driver. I am also trying to give this machine back to the reseller, it
> prints terrible with Linux as well, compared to the HP, which does a
> fantastic job.

Thank you for the thought but, if it is a Brother issue, there is nothing
we can do about it. I'd remove whatever the DCP-9022CDW installed and go
from there.

-- 
Brian.

Bug#864597: upgrade-reports: jessie -> stretch: gnome fails to upgrade: cycle found while processing triggers

[Cyril Brulebois]

Andreas Beckmann  (2017-06-15):
> On 2017-06-15 15:16, Cyril Brulebois wrote:
> > Julien Cristau  (2017-06-15):
> >> It sounds like openjdk-8 added two Breaks recently, one or both of
> >> which are causing trouble, and none of which fix anything as bad as
> >> this.  So I think we should remove the Breaks on tzdata-java from
> >> openjdk-8-jdk-headless, and remove the Breaks on ca-certificates-java
> >> from openjdk-8-jre-headless.  Would that fix the current issue?

FWIW, there are absolutely no differences when removing those two breaks,
even with resolver debugging enabled.

> What I had tested was reverting the recent ca-certificates-java change,
> i.e. switching the dependency on
>   openjdk-8-jre-headless | java7-runtime-headless
> back to
>   openjdk-7-jre-headless | java7-runtime-headless
> (or similar)
> That change was made later than the one in openjdk-8 and it proved to be
> sufficient in my piuparts test to fix^Wnot activate that trigger cycle.

I was just saying this on IRC:

“should I try to reinstate ca-certificates-java's old dependencies and
compare? from my initial bug report, that's the change in the archive
that led to the regression.”

and mentioned earlier that given the old dependencies have an OR anyway,
we shouldn't be introducing an uninstallable package. This would have
the nice effect of being a solution that can be implemented in hours
instead of days (given openjdk-8's build time). This doesn't mean we
should jump the gun anyway…

I'll report back.


KiBi.


signature.asc
Description: Digital signature

Bug#864779: Epetra doc missing

[Nico Schlömer]

Thanks Joachim for report.

This is more of an upstream issue, see [1]. Once that is done, the package
will have the Epetra documentation shipped.

Cheers,
Nico

[1] https://github.com/trilinos/Trilinos/issues/1431

On Wed, Jun 14, 2017 at 6:42 PM Joachim Wuttke 
wrote:

> Package: trilinos-doc
> Version: 12.10.1-3
>
> Documentation of the important Trilinos component Epetra
> is missing in /usr/share/doc/trilinos.
>
>

Bug#864597: upgrade-reports: jessie -> stretch: gnome fails to upgrade: cycle found while processing triggers

[Andreas Beckmann]

On 2017-06-15 10:02, Michael Biebl wrote:
> Am 12.06.2017 um 20:33 schrieb Andreas Beckmann:
>> Switching desktop-file-utils or/and shared-mime-info to -noawait
>> triggers does not solve the problem.
> 
> So afaics there is nothing that can be done from the Debian GNOME team
> side, right?

You could add a Breaks: tzdata-java to some library deep in the gnome
stack (so that it gets a high score from apt) ... that could serve as a
workaround as well.


Andreas

Bug#864768: Duplicate bug reports?

[John Paul Adrian Glaubitz]

Hi Emmanuel!

Is there a reason why you filed the same bug report twice? One against
src:libquartz-java (#864768) and one against libquartz-java (#864769)?

Otherwise I'd suggest merging both bug reports.

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#864597: upgrade-reports: jessie -> stretch: gnome fails to upgrade: cycle found while processing triggers

[Andreas Beckmann]

On 2017-06-15 15:16, Cyril Brulebois wrote:
> Julien Cristau  (2017-06-15):
>> It sounds like openjdk-8 added two Breaks recently, one or both of
>> which are causing trouble, and none of which fix anything as bad as
>> this.  So I think we should remove the Breaks on tzdata-java from
>> openjdk-8-jdk-headless, and remove the Breaks on ca-certificates-java
>> from openjdk-8-jre-headless.  Would that fix the current issue?

What I had tested was reverting the recent ca-certificates-java change,
i.e. switching the dependency on
  openjdk-8-jre-headless | java7-runtime-headless
back to
  openjdk-7-jre-headless | java7-runtime-headless
(or similar)
That change was made later than the one in openjdk-8 and it proved to be
sufficient in my piuparts test to fix^Wnot activate that trigger cycle.


Andreas

Bug#864828: ITP: sogoupinyin-installer -- Sogou Pinyin Input Method installer

[Shengjing Zhu]

On Thu, Jun 15, 2017 at 04:17:34PM +0200, Karsten Merker wrote:
> You write "License: GPL-3", but according to the description,
> this is only a downloader script that downloads a precompiled
> binary from somewhere else.  Under which license is the actual
> application code available?  Why isn't the actual application
> packaged for Debian instead?
> 

The sogoupinyin itself is licensed non-free. But the package is a
installer which is licensed under GPL-3. And this package will not be
included in main section, contrib instead.

I admits that the url in this ITP is some misleading. This installer
script is available at
https://anonscm.debian.org/cgit/pkg-ime/sogoupinyin-installer.git

> What does "is backed with search engine technology" mean in
> detail?  Does the application send all user input to an online
> service to to do the actual transliteration work?  If yes, I
> would consider that unsuitable for an inclusion into Debian
> on privacy grounds.

Yes, people will be promoted by debconf to accept a license which
indicates this privacy concerns during preinst stage.

Thanks,
Shengjing Zhu


signature.asc
Description: PGP signature

Bug#864793: [#864793] crashes with JavaScript errors

[Sylvain Veyrié]

Tag: +workaround

Hello,

I have the same issue. It seems Debian’s Grafana is packaged with jQuery 2.1. 
However, jQuery.event.props has been removed before this version.

I think Grafana 2.6.0 depends on jQuery 1.8. By all means, I successfully 
worked around this bug by replacing /usr/share/grafana/public/vendor/jquery 
with https://github.com/components/jquery/tree/1.8 
 — you just need to create a 
"dist" directory with a jquery.js symlink in it.

The fix would be then to change the jQuery version to 1.8.x.

Sylvain

Bug#864833: RFA: redmine -- flexible project management web application

[Antonio Terceiro]

Package: wnpp
Severity: normal

I request an adopter for the redmine package. In theory redmine is
already team-maintained in the Ruby team, but in practice I am the only
one doing updates for almost 3 years. However, I do not use redmine
myself anymore, so I don't have a strong motivation to continue
maintaining it.

A maintainer should ideally be confortable with Ruby and know the basics
of Rails. Someone that is willing to learn those things will also work.

If you are interested, please get in touch. I can sponsor uploads, and
will also be happy to spend some time answering questions and/or
explaining anything non-trivial in the packaging.

8<8<8<-

The package description is:
 Redmine is a flexible project management web application. Written using Ruby
 on Rails framework, it is cross-platform and cross-database.
 .
 Dependencies for database support are provided by these metapackages:
 redmine-mysql, redmine-pgsql, redmine-sqlite.
 .
 Features
   * Multiple projects support
   * Flexible role based access control
   * Flexible issue tracking system
   * Gantt chart and calendar
   * News, documents & files management
   * Feeds & email notifications
   * Per project wiki
   * Per project forums
   * Time tracking
   * Custom fields for issues, time-entries, projects and users
   * SCM integration (SVN, CVS, Git, Mercurial, Bazaar and Darcs)
   * Issue creation via email
   * Multiple LDAP authentication support
   * User self-registration support
   * Multilanguage support


signature.asc
Description: PGP signature

Bug#864832: kio: Dolphin file window unresponsive once file opens on multi-screen setup

[Nick Bailey]

Package: kio
Version: 5.28.0-2
Severity: important

Dear Maintainer,

On a multiscreen setup where one of the screens is HiDPI,
Dolphin refuses to respond to mouse events after the first
file is open.

This bug is reported here: https://bugs.kde.org/show_bug.cgi?id=363548#c7

A patch is given here: https://bugs.kde.org/show_bug.cgi?id=363548#c18

I am reporting the bug against this package because the patch
is made against kio and purports to fix the issue.

Although it is still possible to use Dolphin by selecting the files
using the cursor keys and enter keys after mouse functionality is
lost, I think most users would not use that modality. It took me a
while to find out that would work. For these users the application
would appear unusable. for that reason I've nomintated it as
important.

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (650, 'testing'), (450, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages kio depends on:
ii  libacl1   2.2.52-3+b1
ii  libc6 2.24-11
ii  libgcc1   1:6.3.0-18
ii  libgssapi-krb5-2  1.15-1
ii  libkf5archive55.28.0-2
ii  libkf5codecs5 5.28.0-1+b2
ii  libkf5completion5 5.28.0-1
ii  libkf5configcore5 5.28.0-2
ii  libkf5configwidgets5  5.28.0-2
ii  libkf5coreaddons5 5.28.0-2
ii  libkf5dbusaddons5 5.28.0-1
ii  libkf5i18n5   5.28.0-2
ii  libkf5itemviews5  5.28.0-1
ii  libkf5kiocore55.28.0-2
ii  libkf5kiontlm55.28.0-2
ii  libkf5kiowidgets5 5.28.0-2
ii  libkf5notifications5  5.28.0-1
ii  libkf5service-bin 5.28.0-1
ii  libkf5service55.28.0-1
ii  libkf5solid5  5.28.0-3
ii  libkf5textwidgets55.28.0-1
ii  libkf5wallet-bin  5.28.0-3
ii  libkf5wallet5 5.28.0-3
ii  libkf5widgetsaddons5  5.28.0-3
ii  libkf5windowsystem5   5.28.0-2
ii  libqt5core5a  5.7.1+dfsg-3+b1
ii  libqt5dbus5   5.7.1+dfsg-3+b1
ii  libqt5gui55.7.1+dfsg-3+b1
ii  libqt5network55.7.1+dfsg-3+b1
ii  libqt5script5 5.7.1~20161021+dfsg-2
ii  libqt5widgets55.7.1+dfsg-3+b1
ii  libqt5x11extras5  5.7.1~20161021-2
ii  libqt5xml55.7.1+dfsg-3+b1
ii  libstdc++66.3.0-18
ii  libxml2   2.9.4+dfsg1-2.2
ii  libxslt1.11.1.29-2.1

kio recommends no packages.

kio suggests no packages.

-- no debconf information

Bug#864829: screen reader stops speaking

[Felipe Sateler]

Control: tags -1 moreinfo

Hi Mika Hanhijärvi,

On Thu, Jun 15, 2017 at 9:39 AM, Mika Hanhijärvi  wrote:

> Package: pulseaudio
> Version: 10.0-1
> Severity: grave
>
> Hi
>
> I am sorry that I repport this so close to release of Stretch.
>
> I am not really sure to which package I should report this bug. I am not
> 100%
> sure if this g is in Pulseaudio, speech-eispatcher or someething else. I
> think
> it might be a problem with Pulseaudio.
>
> I am blind so I have to use computer using the screen reader. So it is
> important for me that screen reader works relealibly.
>

I am very much ignorant about how screen readers work. Could you describe a
bit how the stack works please? In particular, what program is actually
responsible for playing the synthesized speech to speakers, and how does it
run? Also, the audio-related configuration (if any) of these programs would
be useful.


>
> I am using the Gnome desktop.
> I have espeakup and Orca installed. I would like to use espeakup on
> console and
> Orca on desktop. I also would like to be able to switch between text mode
> console and graphical nome desktop without logging out from the desktop.
> Currently that does not work. I have two laptops and both have this
> problem.
> Note that I have not made clean Stretch installation, Ihave upgraded my
> systems
> to Stretch.
>
>
> For some reason if espeakup sppeaks something when the computer is booting
> then
> screen reader does not speak anytging on GDM login screen. If that happens
> then
> screen reader also does not speak at all on desktop. This makes it
> impossible
> for me to login to desktop or use the deshtop. I have noticed that if I go
> to
> text console then eseakup speaks just fin.
>
> If espeakup does not speak anytging then screen reader speaks on GDM login
> screen. If I go to text console then espeakup does not speak at all. If I
> login
> to desktop then Orca screen reader speaks just fine. If I login to desktop
> then
> this also happens: If I switch from desktop to GDM login screen thusing the
> ctrl + alt + f1 then screen reader does not speak on GDM login screen at
> all.
> If I then return to desktop then Orca screen reader on desktop speaks again
> just fine. If I switch form desktop to text console using e.g ctrl + alt +
> f3
> then espeakup does not speak at all on console. If I then switch back to
> desktothen Orca speaks again on desktop just fine.
>
>
> If I logout from desktop to gdm login screen then screen reader speaks on
> gdm
> login screen.


> So it seems that the sc reader works just on one of the following views:
> console, gdm or desktop. It is not possible to switch between those. That
> is
> not good.
>

It sounds like the programs that play the speech to the speakers are
grabbing the sound device and not letting it go - thus making it impossible
for the alternative programs to actually play the sound.

Some information that would be useful:

1. Is your user part of the audio group?
2. Does any of the programs that actually play the sound run as root or a
user that is in the audio group?
3. Please attach the output of `lsof /dev/snd/*` for each of the
problematic states (this should answer question 2).


-- 

Saludos,
Felipe Sateler

Bug#864831: ntl: New upstream version available

[Ximin Luo]

Source: ntl
Version: 9.9.1-3
Severity: wishlist

Dear Maintainer,

There's a new upstream version available, 10.3.0.

http://shoup.net/ntl/doc/tour-changes.html

X

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

Kernel: Linux 4.9.0-3-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)

Bug#864830: mysql-server-5.7: Logrotate config is not quiet causing cron to send email

[Arjan Opmeer]

Package: mysql-server-5.7
Version: 5.7.18-1
Severity: normal

Dear Maintainer,

The logrotate config of mysql-server contains this test:

   if killall -q -s0 -umysql mysqld; then

However killall unconditionally emits the output "sending signal 0 to
procs". See this source line:

   975   printf("sending signal %d to procs\n", sig_num);

Because lograte is started from the cron.daily cronjob this extra output
causes cron to send email to root.

I believe this issue can be easily fixed by redirecting output to /dev/null
like so:

   if killall -q -s0 -umysql mysqld >/dev/null; then


Thanks,

Arjan



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

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

Versions of packages mysql-server-5.7 depends on:
ii  adduser3.115
ii  bsdutils   1:2.29.2-1
ii  debconf [debconf-2.0]  1.5.61
ii  init-system-helpers1.48
ii  libatomic1 6.3.0-18
ii  libc6  2.24-11
ii  libevent-core-2.0-52.0.21-stable-3
ii  libgcc11:6.3.0-18
ii  liblz4-1   0.0~r131-2+b1
ii  libmecab2  0.996-3.1
ii  libstdc++6 7.1.0-5
ii  lsb-base   9.20161125
ii  mysql-client-5.7   5.7.18-1
ii  mysql-common   5.8+1.0.2
ii  mysql-server-core-5.7  5.7.18-1
ii  passwd 1:4.4-4.1
ii  perl   5.24.1-3
ii  psmisc 23.0-1
ii  zlib1g 1:1.2.8.dfsg-5

Versions of packages mysql-server-5.7 recommends:
ii  libhtml-template-perl  2.95-2

Versions of packages mysql-server-5.7 suggests:
ii  bsd-mailx [mailx]  8.1.2-0.20160123cvs-4
pn  tinyca 

-- debconf information:
  mysql-server/no_upgrade_when_using_ndb:
  mysql-server-5.7/nis_warning:
  mysql-server/password_mismatch:
  mysql-server-5.7/really_downgrade: false
  mysql-server-5.7/postrm_remove_databases: false
  mysql-server-5.7/start_on_boot: true

Bug#864829: screen reader stops speaking

[Mika Hanhijärvi]

Package: pulseaudio
Version: 10.0-1
Severity: grave

Hi

I am sorry that I repport this so close to release of Stretch.

I am not really sure to which package I should report this bug. I am not 100%
sure if this g is in Pulseaudio, speech-eispatcher or someething else. I think
it might be a problem with Pulseaudio.

I am blind so I have to use computer using the screen reader. So it is
important for me that screen reader works relealibly.

I am using the Gnome desktop.
I have espeakup and Orca installed. I would like to use espeakup on console and
Orca on desktop. I also would like to be able to switch between text mode
console and graphical nome desktop without logging out from the desktop.
Currently that does not work. I have two laptops and both have this problem.
Note that I have not made clean Stretch installation, Ihave upgraded my systems
to Stretch.


For some reason if espeakup sppeaks something when the computer is booting then
screen reader does not speak anytging on GDM login screen. If that happens then
screen reader also does not speak at all on desktop. This makes it impossible
for me to login to desktop or use the deshtop. I have noticed that if I go to
text console then eseakup speaks just fin.

If espeakup does not speak anytging then screen reader speaks on GDM login
screen. If I go to text console then espeakup does not speak at all. If I login
to desktop then Orca screen reader speaks just fine. If I login to desktop then
this also happens: If I switch from desktop to GDM login screen thusing the
ctrl + alt + f1 then screen reader does not speak on GDM login screen at all.
If I then return to desktop then Orca screen reader on desktop speaks again
just fine. If I switch form desktop to text console using e.g ctrl + alt + f3
then espeakup does not speak at all on console. If I then switch back to
desktothen Orca speaks again on desktop just fine.


If I logout from desktop to gdm login screen then screen reader speaks on gdm
login screen.

So it seems that the sc reader works just on one of the following views:
console, gdm or desktop. It is not possible to switch between those. That is
not good.

I dreally hope this will be fixed vecause this bug makes it impossible to
switch between desktop, gdm and console if you can not see and have to rely on
screen reader.



-- Package-specific info:
File '/etc/default/pulseaudio' does not exist


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

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

Versions of packages pulseaudio depends on:
ii  adduser  3.115
ii  libasound2   1.1.3-5
ii  libasound2-plugins   1.1.1-1
ii  libc62.24-11
ii  libcap2  1:2.25-1
ii  libdbus-1-3  1.10.18-1
ii  libgcc1  1:6.3.0-18
ii  libice6  2:1.0.9-2
ii  libltdl7 2.4.6-2
ii  liborc-0.4-0 1:0.4.26-2
ii  libpulse010.0-1
ii  libsm6   2:1.2.2-1+b3
ii  libsndfile1  1.0.27-3
ii  libsoxr0 0.1.2-2
ii  libspeexdsp1 1.2~rc1.2-1+b2
ii  libstdc++6   6.3.0-18
ii  libsystemd0  232-25
ii  libtdb1  1.3.11-2
ii  libudev1 232-25
ii  libwebrtc-audio-processing1  0.3-1
ii  libx11-6 2:1.6.4-3
ii  libx11-xcb1  2:1.6.4-3
ii  libxcb1  1.12-1
ii  libxtst6 2:1.2.3-1
ii  lsb-base 9.20161125
ii  pulseaudio-utils 10.0-1

Versions of packages pulseaudio recommends:
ii  rtkit  0.11-4+b1

Versions of packages pulseaudio suggests:
ii  paman0.9.4-1+b3
ii  paprefs  0.9.10-2+b1
ii  pavucontrol  3.0-3.1
ii  pavumeter0.9.3-4+b3
ii  udev 232-25

-- no debconf information
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for PulseAudio clients. See pulse-client.conf(5) for
## more information. Default values are commented out.  Use 

Bug#864828: ITP: sogoupinyin-installer -- Sogou Pinyin Input Method installer

[Shengjing Zhu]

Package: wnpp
Severity: wishlist
Owner: Shengjing Zhu 

* Package name: sogoupinyin-installer
  Version : 2.1.0.0086~1
  Upstream Author : Shengjing Zhu
* URL : https://pinyin.sogou.com/linux/
* License : GPL-3
  Programming Lang: Shell
  Description : Sogou Pinyin Input Method installer

 Based on web search engine technology, Sogou Pinyin input method is
 the next-generation input method designed for Internet users. As it
 is backed with search engine technology, user input method can be
 extremely fast, and it is much more advanced than other input method
 engines in terms of the volume of the vocabulary database and its
 accuracy. Sogou input method is the most popular input methods in
 China, and Sogou promises it will always be free of charge.
 .
 Note: this package does not contain any software from Sogou Inc. This
 package does however contain a script to download and install Sogou
 Pinyin.


Please also include as much relevant information as possible.
For example, consider answering the following questions:
 - why is this package useful/relevant? is it a dependency for
   another package? do you use it? if there are other packages
   providing similar functionality, how does it compare?

   Sogou Pinyin is popular among Chinese users. This package will help
   people install it.

 - how do you plan to maintain it? inside a packaging team
   (check list at https://wiki.debian.org/Teams)? are you
   looking for co-maintainers? do you need a sponsor?

   This package will be maintained in pkg-ime team.


signature.asc
Description: PGP signature

Bug#864827: [zotero-standalone] No longer works with firefox 54 update

[Kwang Moo Yi]

Package: zotero-standalone
Version: 4.0.29.16+dfsg-1
Severity: normal

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

Dear maintainer,

The stand alone version of the zotero no longer displays the contents 
inside the collections after upgrading to firefox 54. When I run it from 
the command line, what I get is


> xulrunner not found, trying firefox instead.

Which is probably why it's not running properly.

Thanks,
Kwang


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

Debian Release: 9.0
  500 unstablemirror.switch.ch   500 stable 
repo.skype.com   500 stable  dl.google.com 1 experimental 
deb.debian.org

--- Package information. ---
Depends  (Version) | Installed
==-+-===
firefox-esr   (>= 45)  |  OR firefox(>= 45) | 54.0-1


Package's Recommends field is empty.

Package's Suggests field is empty.

Bug#864826: gammaray: 2.8.0 is out

[ydirson]

Package: gammaray
Version: 2.7.0-1
Severity: wishlist

https://github.com/KDAB/GammaRay/releases

Bug#864597: upgrade-reports: jessie -> stretch: gnome fails to upgrade: cycle found while processing triggers

[Cyril Brulebois]

Julien Cristau  (2017-06-15):
> It sounds like openjdk-8 added two Breaks recently, one or both of
> which are causing trouble, and none of which fix anything as bad as
> this.  So I think we should remove the Breaks on tzdata-java from
> openjdk-8-jdk-headless, and remove the Breaks on ca-certificates-java
> from openjdk-8-jre-headless.  Would that fix the current issue?
> 
> From what I can see #863820 is at most a normal-severity issue.  Not
> upgrading some packages is way way better than a failed upgrade.

I'm currently building an updated openjdk-8 with the attached changes
to see what the upgrade-desktop test cases would look like.

Note: I've chosen to remove the “Breaks: ${jrehl:Breaks}” line from
debian/control* so that I'm only touching these files, since d/rules
seems to only set it to tzdata-java anyway, depending on the target
dist.

I'll report the results afterwards, but as mentioned on IRC, even if
that looks good in the end, fewer than 2 days to become confident it
won't regress in other cases is really short. :(


KiBi.
diff -Nru openjdk-8-8u131-b11/debian/changelog openjdk-8-8u131-b11/debian/changelog
--- openjdk-8-8u131-b11/debian/changelog	2017-05-16 21:38:22.0 +
+++ openjdk-8-8u131-b11/debian/changelog	2017-06-15 12:57:13.0 +
@@ -1,3 +1,13 @@
+openjdk-8 (8u131-b11-2.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * Remove recently-added Breaks which trigger dist-upgrade failures from
+jessie to stretch for some desktop tasks. Closes: #864597.
+- openjdk-8-jdk-headless → ${jrehl:Breaks}
+- openjdk-8-jre-headless → tzdata-java
+
+ -- Cyril Brulebois   Thu, 15 Jun 2017 12:57:13 +
+
 openjdk-8 (8u131-b11-2) unstable; urgency=medium
 
   * Tighten dependency on libatk-wrapper-java-jni. Closes: #862508.
diff -Nru openjdk-8-8u131-b11/debian/control openjdk-8-8u131-b11/debian/control
--- openjdk-8-8u131-b11/debian/control	2017-05-16 21:36:52.0 +
+++ openjdk-8-8u131-b11/debian/control	2017-06-15 12:57:13.0 +
@@ -30,7 +30,6 @@
   java5-sdk-headless, java6-sdk-headless,
   java7-sdk-headless, java8-sdk-headless,
 Replaces: openjdk-8-jdk (<< 8u72-b15-4),
-Breaks: ${jrehl:Breaks}
 Description: OpenJDK Development Kit (JDK) (headless)
  OpenJDK is a development environment for building applications,
  applets, and components using the Java programming language.
@@ -56,7 +55,6 @@
   java7-runtime-headless, java8-runtime-headless,
   ${defaultvm:Provides}, ${jvm:Provides}
 Breaks: oracle-java8-installer (<< 8u77+8u77arm-1),
-  ca-certificates-java (<< 20160321~)
 Description: OpenJDK Java runtime, using ${vm:Name} (headless)
  Minimal Java runtime - needed for executing non GUI Java programs,
  using ${vm:Name}.
diff -Nru openjdk-8-8u131-b11/debian/control.in openjdk-8-8u131-b11/debian/control.in
--- openjdk-8-8u131-b11/debian/control.in	2017-04-08 19:44:58.0 +
+++ openjdk-8-8u131-b11/debian/control.in	2017-06-15 12:57:13.0 +
@@ -30,7 +30,6 @@
   java5-sdk-headless, java6-sdk-headless,
   java7-sdk-headless, java8-sdk-headless,
 Replaces: @basename@-jdk (<< 8u72-b15-4),
-Breaks: ${jrehl:Breaks}
 Description: OpenJDK Development Kit (JDK) (headless)
  OpenJDK is a development environment for building applications,
  applets, and components using the Java programming language.
@@ -56,7 +55,6 @@
   java7-runtime-headless, java8-runtime-headless,
   ${defaultvm:Provides}, ${jvm:Provides}
 Breaks: oracle-java8-installer (<< 8u77+8u77arm-1),
-  ca-certificates-java (<< 20160321~)
 Description: OpenJDK Java runtime, using ${vm:Name} (headless)
  Minimal Java runtime - needed for executing non GUI Java programs,
  using ${vm:Name}.


signature.asc
Description: Digital signature

Bug#864825: gammaray: crashes target program on attach

[ydirson]

Package: gammaray
Version: 2.7.0-1
severity: grave

When attaching to any Qt5 or Qt4 process, the target process crashes.
Here with a freshly-launched kwrite for demonstration:

#0  0x7f21b4fd96ad in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x7f21af8429f6 in g_main_context_poll (priority=, 
n_fds=1, fds=0x7f2194003020, timeout=, context=0x7f2194000990) 
at ././glib/gmain.c:4228
#2  g_main_context_iterate (context=context@entry=0x7f2194000990, 
block=block@entry=1, dispatch=dispatch@entry=1, self=) at 
././glib/gmain.c:3924
#3  0x7f21af842b0c in g_main_context_iteration (context=0x7f2194000990, 
may_block=1) at ././glib/gmain.c:3990
#4  0x7f21b58ed06b in 
QEventDispatcherGlib::processEvents(QFlags) () 
from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x7f21b58969ca in 
QEventLoop::exec(QFlags) () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#6  0x7f21b56c40f3 in QThread::exec() () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#7  0x7f21b88b26d5 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5DBus.so.5
#8  0x7f21b56c8da8 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#9  0x7f21b151e494 in start_thread (arg=0x7f21a0dfc700) at 
pthread_create.c:333
#10 0x7f21b4fe2aff in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:97

Thread 1 (Thread 0x7f21a5b0a580 (LWP 31110)):
[KCrash Handler]
#4  0x7f219a2d65b1 in GammaRay::Server::listen() () from 
/usr/lib/libgammaray_core-qt5_7-x86_64.so.2.7.0
#5  0x7f219a294bd1 in GammaRay::Probe::delayedInit() () from 
/usr/lib/libgammaray_core-qt5_7-x86_64.so.2.7.0
#6  0x7f21b58c5499 in QObject::event(QEvent*) () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#7  0x7f21b617bb8c in QApplicationPrivate::notify_helper(QObject*, QEvent*) 
() from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#8  0x7f21b6183341 in QApplication::notify(QObject*, QEvent*) () from 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#9  0x7f21b58989e0 in QCoreApplication::notifyInternal2(QObject*, QEvent*) 
() from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#10 0x7f21b589b16d in QCoreApplicationPrivate::sendPostedEvents(QObject*, 
int, QThreadData*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#11 0x7f21b58ecc43 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#12 0x7f21af8427f7 in g_main_dispatch (context=0x7f219c0016f0) at 
././glib/gmain.c:3203
#13 g_main_context_dispatch (context=context@entry=0x7f219c0016f0) at 
././glib/gmain.c:3856
#14 0x7f21af842a60 in g_main_context_iterate 
(context=context@entry=0x7f219c0016f0, block=block@entry=1, 
dispatch=dispatch@entry=1, self=) at ././glib/gmain.c:3929
#15 0x7f21af842b0c in g_main_context_iteration (context=0x7f219c0016f0, 
may_block=1) at ././glib/gmain.c:3990
#16 0x7f21b58ed04f in 
QEventDispatcherGlib::processEvents(QFlags) () 
from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#17 0x7f21b58969ca in 
QEventLoop::exec(QFlags) () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#18 0x7f21b589f13c in QCoreApplication::exec() () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#19 0x557eafc8198f in main ()

Bug#864385: live-boot: fix file duplication in initramfs-tools hook

[Raphael Hertzog]

Control: tag -1 + pending

Hello Daniel,

On Wed, 07 Jun 2017, Daniel Reichelt wrote:
> The duplication was introduced by [3] and is fixed by this patch to read
> 
> 8<-
> cp -a /bin/live-boot "${DESTDIR}/bin"
> >8-

Applied in the git repository, thanks for the patch.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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