Bug#908449: firefox-esr_60.2.0esr-1~deb9u2.1_i386.deb not working
On Tue, Sep 18, 2018 at 02:30:03PM +0900, Mike Hommey wrote: > On Tue, Sep 18, 2018 at 05:26:43PM +1200, Tim Makarios wrote: > > On 18/09/18 17:05, Mike Hommey wrote: > > > Oh, right. Forgot about the crash reporter interposing itself. You can > > > do one of the following: > > > ... > > > - or send the report to Mozilla, and find its id in > > >~/.mozilla/firefox/Crash Reports/submitted > > > ... > > > > I'd already reported a few earlier crashes to Mozilla, but I did it again > > today, and the most recent file in that directory contains just the line: > > > > Crash ID: bp-a47d7854-9ea2-4c6b-b432-4b98e0180918 > > > > Is that what you're looking for? > > Yes, thanks. So the crash is happening in JITed code, which is not expected: the JIT should disable itself. There might be something wrong either in the detection or maybe some parts don't disable themselves as they're supposed to. Can you try starting with `firefox-esr -safe-mode`? If that works, can you then go to about:config and switch javascript.options.ion to false, then restart without -safe-mode? If that works, stop there. If it doesn't work, can you try -safe-mode again, and switch javascript.options.baselinejit to false? Can you then report what worked and what didn't? Thanks Mike
Bug#902760: Two failed tests remaining in igraph which are arpack related
Hi Arpack maintainers, could you please vote for one of the following options: [ ] You will upload arpack with the patch mentioned below [ ] You prefer if I do a team upload with the patch below [ ] I rather should exclude the two failing tests and lower the severity of bug #902760 Kind regards Andreas. On Mon, Sep 17, 2018 at 09:51:49PM +0200, Tamas Nepusz wrote: > Hi Andreas & Adrian, > > This is the ARPACK patch that needs to be applied in order to fix the > failing test cases in igraph: > > https://github.com/opencollab/arpack-ng/commit/31854cadaff067e30b8715f10533c459a9b7d447 > > As far as I know, there was no official ARPACK release with the patch > above yet so it has to be applied manually. > > All the best, > Tamas > On Mon, 17 Sep 2018 at 21:44, Andreas Tille wrote: > > > > Control: tags -1 help > > > > Hi Adrian, > > > > I realised that you have set > > > >908648: libarpack2 needs fix applied for igraph > > > > fixed. So I tried to build igraph from Git[1] with latest arpack but > > there are two remaining issues in the build time test which both are > > connected to arpack: > > > > ... > > 196: Eigenvector centrality (igraph_eigenvector_centrality): FAILED > > (arpack.at:59) > > 197: Non-symmetric ARPACK solver (igraph_arpack_rnsolve): FAILED > > (arpack.at:66) > > ... > > ## - ## > > ## Test results. ## > > ## - ## > > > > ERROR: 219 tests were run, > > 2 failed unexpectedly. > > 13 tests were skipped. > > ## -- ## > > ## testsuite.log was created. ## > > ## -- ## > > > > Please send `tests/testsuite.log' and all information you think might help: > > > >To: > >Subject: [igraph 0.7.1] testsuite: 196 197 failed > > > > You may investigate any problem if you feel able to do so, in which > > case the test suite provides a good starting point. Its output may > > be found below `tests/testsuite.dir'. > > > > > > I admit I have no idea about igraph - just picked it up since the former > > Uploader just left the team. > > > > Any hint is welcome > > > > Andreas. > > > > > > [1] https://salsa.debian.org/med-team/igraph > > > > -- > > http://fam-tille.de > -- http://fam-tille.de
Bug#909073: snmptt: IPV6 RDNS translation broken
Package: snmptt Version: 1.4-1 Severity: minor Tags: ipv6 upstream It looks like IPV6 translation in snmptt does not work. There is the following sf bug, maybe a patch can be included into the debian package? https://sourceforge.net/p/snmptt/bugs/34/ -- System Information: Debian Release: 9.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-6-amd64 (SMP w/12 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages snmptt depends on: ii adduser 3.115 ii libconfig-inifiles-perl 2.94-1 ii libsnmp-perl 5.7.3+dfsg-1.7 ii snmpd5.7.3+dfsg-1.7 Versions of packages snmptt recommends: ii libperl5.24 [libsys-syslog-perl] 5.24.1-3+deb9u4 snmptt suggests no packages. -- Configuration Files: /etc/snmp/snmptt.conf [Errno 2] Datei oder Verzeichnis nicht gefunden: '/etc/snmp/snmptt.conf' /etc/snmp/snmptt.ini changed [not included] -- no debconf information
Bug#908449: firefox-esr_60.2.0esr-1~deb9u2.1_i386.deb not working
On Tue, Sep 18, 2018 at 05:26:43PM +1200, Tim Makarios wrote: > On 18/09/18 17:05, Mike Hommey wrote: > > Oh, right. Forgot about the crash reporter interposing itself. You can > > do one of the following: > > ... > > - or send the report to Mozilla, and find its id in > >~/.mozilla/firefox/Crash Reports/submitted > > ... > > I'd already reported a few earlier crashes to Mozilla, but I did it again > today, and the most recent file in that directory contains just the line: > > Crash ID: bp-a47d7854-9ea2-4c6b-b432-4b98e0180918 > > Is that what you're looking for? Yes, thanks. Mike
Bug#909072: RFP: petardfs -- a FUSE filessytem for injecting intentional errors (e.g. for testing)
Package: wnpp Severity: wishlist * Package name: petardfs Version : 0.1 Upstream Author : Ben Martin * URL : https://github.com/jrandall/petardfs * License : GPL 3 Programming Lang: C++ Description : a FUSE filessytem for injecting intentional errors (e.g. for testing) PetardFS - a FUSE filessytem for injecting intentional errors (e.g. for testing) With no configuration petardfs takes a base filesystem and exposes it through FUSE. An XML configuration file is used to tell petardfs which files to report errors for and what error code to use. For example, foo.txt can have an EIO error at bytes 34 to 37. There is explicit support for errors such as EAGAIN and EINTR where petardfs will only report such transient errors a nominated number of times, handy for testing applications support such IO conditions gracefully. original source: http://sourceforge.net/projects/witme/files/petardfs/0.0.2/
Bug#908449: firefox-esr_60.2.0esr-1~deb9u2.1_i386.deb not working
On 18/09/18 17:05, Mike Hommey wrote: Oh, right. Forgot about the crash reporter interposing itself. You can do one of the following: ... - or send the report to Mozilla, and find its id in ~/.mozilla/firefox/Crash Reports/submitted ... I'd already reported a few earlier crashes to Mozilla, but I did it again today, and the most recent file in that directory contains just the line: Crash ID: bp-a47d7854-9ea2-4c6b-b432-4b98e0180918 Is that what you're looking for? Tim <><
Bug#909071: pbbam: FTBFS on every release architecture where it previously built
Source: pbbam
Version: 0.18.0+dfsg-1
Severity: serious
Hi,
The pbbam package FTBFS on every release architecture. The following
snippet is from the arm64 build:
"""
# Fix broken PATH
synthetic_movie_all_path=`find $PWD -name synthetic_movie_all.subreadset.xml` ;
\
sed -i -e
"s?.GENERATEDDATADIR/synthetic_movie_all.subreadset.xml?${synthetic_movie_all_path}?"
tests/src/cram/pbbamify*
BINDIR=`dirname $(find $PWD -name pbmerge -type f -executable)`; \
LIBDIR=`find $PWD -name lib -type d`; \
PATH="$BINDIR:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games"
LD_LIBRARY_PATH="$LIBDIR:" \
cram -v tests/src/cram/pbmerge_pacbio_ordering.deb.t
tests/src/cram/pbmerge_mixed_ordering.deb.t
tests/src/cram/pbmerge_aligned_ordering.deb.t
tests/src/cram/pbindexdump_json.deb.t tests/src/cram/pbindexdump_cpp.deb.t
tests/src/cram/pbmerge_fofn.deb.t tests/src/cram/pbbamify.deb.t
tests/src/cram/pbmerge_dataset.deb.t
tests/src/cram/pbmerge_pacbio_ordering.deb.t: failed
--- tests/src/cram/pbmerge_pacbio_ordering.deb.t
+++ tests/src/cram/pbmerge_pacbio_ordering.deb.t.err
@@ -14,444 +14,104 @@
Sanity Check:
$ samtools view -H $HQREGION_BAM
- @HD\tVN:1.1\tSO:unknown\tpb:3.0.1 (esc)
-
@RG\tID:ca75d884\tPL:PACBIO\tDS:READTYPE=HQREGION;DeletionQV=dq;DeletionTag=dt;InsertionQV=iq;MergeQV=mq;SubstitutionQV=sq;SubstitutionTag=st;Ipd:Frames=ip;PulseWidth:Frames=pw;PkMid=pm;PkMean=pa;LabelQV=pq;AltLabel=pt;AltLabelQV=pv;PulseMergeQV=pg;PulseCall=pc;PrePulseFrames=pd;PulseCallWidth=px;BINDINGKIT=100372700;SEQUENCINGKIT=100356200;BASECALLERVERSION=0.1;FRAMERATEHZ=100.00\tPU:ArminsFakeMovie
(esc)
- @PG\tID:baz2bam-0.15.0\tPN:baz2bam\tVN:0.15.0 (esc)
- @PG\tID:bazFormat-0.3.0\tPN:bazFormat\tVN:0.3.0 (esc)
- @PG\tID:bazwriter-0.15.0\tPN:bazwriter\tVN:0.15.0 (esc)
+ [E::hts_open_format] Failed to open file
/<>/pbbam-0.18.0/tests/data/polymerase/internal.hqregions.bam
+ samtools view: failed to open
"/<>/pbbam-0.18.0/tests/data/polymerase/internal.hqregions.bam" for
reading: No such file or directory
+ [1]
$ samtools view $HQREGION_BAM | cut -f 1
- ArminsFakeMovie/10/2659_7034
+ [E::hts_open_format] Failed to open file
/<>/pbbam-0.18.0/tests/data/polymerase/internal.hqregions.bam
+ samtools view: failed to open
"/<>/pbbam-0.18.0/tests/data/polymerase/internal.hqregions.bam" for
reading: No such file or directory
[...]
"""
Thanks,
~Niels
Bug#853231: Please update xsensor to newer fork
Hi Jeremy, I am no longer actively maintaining Xsensors and just sent a request to orphan the package in bug #839654. I'm not familiar with the process of replacing a package with a fork. Perhaps the next maintainer can look into this. Regards, Nanley On Mon, Jan 30, 2017 at 10:20 AM, Jeremy Newton wrote: > Package: xsensors > Version: 0.70 > Severity: wishlist > > I forked xsensors a while ago due to upstream no longer being active. > > Please consider changing the xsensors debian package to my fork, as it has > some bug fixes and new features, including GTK3 support, preferences and > appdata: > https://github.com/Mystro256/xsensors > > Thanks!
Bug#858595:
Bug#908449: firefox-esr_60.2.0esr-1~deb9u2.1_i386.deb not working
On Tue, Sep 18, 2018 at 04:55:07PM +1200, Tim Makarios wrote: > On 13/09/18 21:23, Mike Hommey wrote: > > Huh. Can you then try ulimit -c unlimited, and upload the resulting core > > file somewhere? > > I'm not sure I quite understand you here. I ran > > $ ulimit -c unlimited > $ firefox-esr > > The output was: > > > ExceptionHandler::GenerateDump cloned child 1472 > > ExceptionHandler::SendContinueSignalToChild sent continue signal to child > > ExceptionHandler::WaitForContinueSignal waiting for continue signal... > > and a window popped up inviting me to choose whether to report the crash to > Mozilla, and whether to quit or restart Firefox. > > I couldn't find any resulting core file. Where is it meant to be? Oh, right. Forgot about the crash reporter interposing itself. You can do one of the following: - set MOZ_CRASHREPORTER_DISABLE to 1 in the environment and try again - or send the report to Mozilla, and find its id in ~/.mozilla/firefox/Crash Reports/submitted - or attach the crash report data from ~/.mozilla/firefox/Crash Reports/pending (both the .dmp and the .extra with the same id; only the last pair) I'd suggest the second one, in case your session crashed at some point where some private data might have been on the stack. That would limit the number of people who can look at the data, while attaching the raw data to the bug would make it public. Or the third one, if you send the files to me rather than the bug (that would also be smaller to transfer than a full core). Thanks Mike
Bug#908449: firefox-esr_60.2.0esr-1~deb9u2.1_i386.deb not working
On 13/09/18 21:23, Mike Hommey wrote: Huh. Can you then try ulimit -c unlimited, and upload the resulting core file somewhere? I'm not sure I quite understand you here. I ran $ ulimit -c unlimited $ firefox-esr The output was: ExceptionHandler::GenerateDump cloned child 1472 ExceptionHandler::SendContinueSignalToChild sent continue signal to child ExceptionHandler::WaitForContinueSignal waiting for continue signal... and a window popped up inviting me to choose whether to report the crash to Mozilla, and whether to quit or restart Firefox. I couldn't find any resulting core file. Where is it meant to be? Tim <><
Bug#908865: exim4: Default CHECK_RCPT_REMOTE_LOCALPARTS blocks legal email addresses (in particular the % character)
tags #908865 upstream thanks On Mon, Sep 17, 2018 at 10:04:34PM +0200, Rainer Dorsch wrote: > I particular, I do not understand the spam risk you mention and also > Google did not help me :-/ ... Could you give me a pointer to more > details? In particular do I carry a SPAM risk if I do the local > modification to accept the % sign? As far as I remember, exim itself is not vulnerable, but might be part of a relay chain relaying such a message to a relay that _is_ vulnerable to the issue. I have looked again and found that this is indeed a configuration that is part of upstream's default configuration (see src/configure.default in the upstream code - the only thing we add is the macro that makes it easier to change the setting). This means that Debian is unlikely to change this as we try sticking to upstream's configuration as close as sanely possible. You might want to discuss this on the upsteam maiilng list exim-u...@exim.org and get a better explanation (or even a change) there. 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#909070: mypy: autopkgtest regression: The 'mypy_extensions<0.5.0,>=0.4.0' distribution was not found
Source: mypy
Version: 0.630-1
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression
Dear maintainers,
With a recent upload of mypy the autopkgtest of mypy fails in testing
when that autopkgtest is run with the binary packages of mypy from
unstable. It passes when run with only packages from testing. I copied
some of the output at the bottom of this report.
Reading the error message, mypy fails to run because because it is
missing a dependency. Therefore I file this bug at severity serious,
please downgrade if I misjudged.
Even before I filed this bug, this regression is contributing to the
delay of the migration to testing [1]. Can you please investigate the
situation and fix it?
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[1] https://qa.debian.org/excuses.php?package=mypy
https://ci.debian.net/data/autopkgtest/testing/amd64/m/mypy/1010214/log.gz
autopkgtest [03:19:46]: test command1: mypy --help
autopkgtest [03:19:46]: test command1: [---
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line
578, in _build_master
ws.require(__requires__)
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line
895, in require
needed = self.resolve(parse_requirements(requirements))
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line
786, in resolve
raise VersionConflict(dist, req).with_context(dependent_req)
pkg_resources.ContextualVersionConflict: (mypy-extensions 0.5.0.dev0
(/usr/lib/python3/dist-packages),
Requirement.parse('mypy_extensions<0.5.0,>=0.4.0'), {'mypy'})
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/bin/mypy", line 6, in
from pkg_resources import load_entry_point
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line
3105, in
@_call_aside
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line
3089, in _call_aside
f(*args, **kwargs)
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line
3118, in _initialize_master_working_set
working_set = WorkingSet._build_master()
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line
580, in _build_master
return cls._build_from_requirements(__requires__)
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line
593, in _build_from_requirements
dists = ws.resolve(reqs, Environment())
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line
781, in resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'mypy_extensions<0.5.0,>=0.4.0'
distribution was not found and is required by mypy
autopkgtest [03:19:47]: test command1: ---]
signature.asc
Description: OpenPGP digital signature
Bug#909069: RFP: charybdefs -- fuse based fault injection filesystem with a Thrift RPC interface for instrumentation
Package: wnpp Severity: wishlist * Package name: CharybdeFS Version : 0.1 Upstream Author : ScyllaDB * URL : https://github.com/scylladb/charybdefs * License : Epat Programming Lang: C++ Description : ScyllaDB fault injection filesystem CharybdeFS is a fuse based fault injection filesystem with a Thrift RPC interface for instrumentation. Block devices sometimes do bad things (or just fill up), so sometimes bad things happen to good software. CharybdeFS makes it easy to do integration testing that covers hard-to test filesystem errors. And good error handling is a sign of well-thought-out software. For example, your program will make a much better impression on users if you have it show a nice “insufficient space” message than if it just crashes for no apparent reason. The CharybdeFS filesystem lets you inject arbitrary file errors for testing. This article covers some common examples for getting started. https://www.scylladb.com/2016/05/02/fault-injection-filesystem-cookbook/
Bug#909068: mypy: Crash
Package: mypy
Version: 0.630-1
Severity: grave
Justification: renders package unusable
Dear Maintainer,
$ mypy
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 578, in
_build_master
ws.require(__requires__)
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 895, in
require
needed = self.resolve(parse_requirements(requirements))
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 786, in
resolve
raise VersionConflict(dist, req).with_context(dependent_req)
pkg_resources.ContextualVersionConflict: (mypy-extensions 0.5.0.dev0
(/usr/lib/python3/dist-packages),
Requirement.parse('mypy_extensions<0.5.0,>=0.4.0'), {'mypy'})
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/bin/mypy", line 6, in
from pkg_resources import load_entry_point
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3105,
in
@_call_aside
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3089,
in _call_aside
f(*args, **kwargs)
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3118,
in _initialize_master_working_set
working_set = WorkingSet._build_master()
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 580, in
_build_master
return cls._build_from_requirements(__requires__)
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 593, in
_build_from_requirements
dists = ws.resolve(reqs, Environment())
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 781, in
resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'mypy_extensions<0.5.0,>=0.4.0'
distribution was not found and is required by mypy
Best
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.18.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE=
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages mypy depends on:
ii python3 3.6.6-1
ii python3-mypy 0.630-1
mypy recommends no packages.
Versions of packages mypy suggests:
pn mypy-doc
-- no debconf information
Bug#908978: openvswitch: FTBFS on armel, mips, mips64el, mipsel
On Mon, Sep 17, 2018 at 09:41:50AM +0200, Thomas Goirand wrote: > On 09/17/2018 12:50 AM, Ivo De Decker wrote: > > package: openvswitch > > version: 2.10.0+2018.08.28+git.8ca7c82b7d+ds1-3 > > severity: serious > > > > Hi, > > > > The latest version of openvswitch in unstable fails on armel, mips, > > mips64el, > > mipsel: > > > > https://buildd.debian.org/status/package.php?p=openvswitch > > > > Cheers, > > > > Ivo > > Hi, > > We know, and we're already working on it. But I've been traveling in Japan for the last week and so not making progress. I'm back Wednesday, though.
Bug#909067: nmu: libthrift-0.9.2_0.9.2-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Hello, libthrift in experimental[1] depends on an outdated version of libssl and should be updated to depend on libssl1.0.2 The following packages have unmet dependencies: libthrift-0.9.2 : Depends: libssl1.0.0 (>= 1.0.1) but it is not installable libssl1.0.2/testing,now 1.0.2o-1 i386 [installed,automatic] Secure Sockets Layer toolkit - shared libraries nmu libthrift-0.9.2_0.9.2-2 . ANY -i386 -amd64 -mips -mipsel -ppc64 -s390x . -m "Rebuild with libssl1.0.2 to correct dependency" Thanks! [1] https://packages.debian.org/experimental/libthrift-0.9.2 -- System Information: Debian Release: buster/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 4.17.0-3-686 (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) LSM: AppArmor: enabled
Bug#909066: RM: ubiquity-extension -- RoQA; broken with current Firefox
Package: release.debian.org Severity: normal Tags: stretch User: release.debian@packages.debian.org Usertags: rm ubiquity-extension no longer works with firefox-esr 60, removal from unstable is requested in #909053.
Bug#909065: ITP: xfce4-statusnotifier-plugin -- plugin to display status notifiers in the Xfce4 panel
Package: wnpp Severity: wishlist Owner: Unit 193 * Package name: xfce4-statusnotifier-plugin Version : 0.2.1 Upstream Author : Viktor Odintsev * URL : https://goodies.xfce.org/projects/panel-plugins/xfce4-statusnotifier-plugin * License : GPL-2+ Programming Lang: C Description : plugin to display status notifiers in the Xfce4 panel A small plugin to display status notifiers, including application indicators, in the Xfce4 panel as described in freedesktop.org StatusNotifierItem specification. Status notifiers are a modern alternative to the system tray. This provides a nice way in Xfce to display indicators in the panel. There may be other panel plugins that do a similar thing, but this is an official project of Xfce.
Bug#864827: [zotero-standalone] No longer works with firefox 54 update
Package: zotero-standalone Version: 4.0.29.16+dfsg-1 Followup-For: Bug #864827 Dear Maintainer, This bug basically makes the package unusable. I understand that adapting the packaging to the new structure of Zotero-5 will take some time, but in the mean time, could someone add a page to the Debian wiki outlining how to install Zotero-5 by hand on a Debian system (ideally in a way that will interact well with a future fixed zotero-standalone Debian package)? [ A little script would be even better. ] Also, including some discussion about whether libreoffice-zotero-integration can be kept as is and things like that. The Zotero site has some info, but it doesn't take Debian's packaging into account, of course, and instead presumes you want to install the package for a single non-admin user. -- System Information: Debian Release: 9.5 APT prefers stable APT policy: (990, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.UTF-8 (charmap=UTF-8), LANGUAGE=fr_CH.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages zotero-standalone depends on: ii firefox-esr 60.2.0esr-1~deb9u2 zotero-standalone recommends no packages. zotero-standalone suggests no packages. -- no debconf information
Bug#908951: libinput: Intermittent unrecoverable failures due to tp_detect_thumb_while_moving assertion failure
This is definitely (still) upstream in tp_detect_thumb_while_moving().
I have 1.12.0-1, identical to HEAD evdev-mt-touchpad.c as of right now.
The assumption that there is one (or more) new TOUCH_BEGIN touch and one
(or more) older TOUCH_UPDATE (not _BEGIN or _HOVER or _NONE) touch is false.
Here are two touches that triggered this bug for me, extracted from a core:
{ tp = 0x55952647f5e0,
index = 0,
state = TOUCH_BEGIN,
has_ended = false,
dirty = true,
point = { x = 167, y = 3432 },
time = 29468145253,
pressure = 0,
is_tool_palm = false,
major = 152,
minor = 264,
was_down = true,
quirks = { reset_motion_history = true },
history = { samples = { { time = 29468121253,
point = { x = 113, y = 3477 } },
{ time = 29468129254,
point = { x = 115, y = 3475 } },
{ time = 29468137199,
point = { x = 129, y = 3460 } },
{ time = 29468145253,
point = { x = 167, y = 3432 } } },
index = 3,
count = 1 },
jumps = { last_delta_mm = 0 },
hysteresis = { center = { x = 167, y = 3432 },
x_motion_history = 0 '\000' },
pinned = { is_pinned = false, center = { x = 2818, y = 2976 } },
button = { state = BUTTON_STATE_NONE,
current = 0,
timer = { libinput = 0x5595264688d0,
timer_name = 0x55952647f2e0 "event12 (1) button",
link = { prev = 0x0, next = 0x0 },
expire = 0,
timer_func =
0x7f8624ec3450 < tp_button_handle_timeout >,
timer_func_data = 0x55952647fba0 },
initial = { x = 1647, y = 4150 },
has_moved = false },
tap = { state = TAP_TOUCH_STATE_IDLE,
initial = { x = 1647, y = 4150 },
is_thumb = false,
is_palm = false },
scroll = { edge_state = EDGE_SCROLL_TOUCH_STATE_NONE,
edge = 0,
direction = -1,
timer = { libinput = 0x5595264688d0,
timer_name = 0x559526481950 "event12 (0)
edgescroll",
link = { prev = 0x0, next = 0x0 },
expire = 0,
timer_func =
0x7f8624ec4f70 < tp_edge_scroll_handle_timeout >,
timer_func_data = 0x55952647fba0 },
initial = { x = 0, y = 0 } },
palm = { state = PALM_NONE,
first = { x = 5023, y = 4326 },
time = 29468145253 },
gesture = { initial = { x = 1629, y = 4030 } },
thumb = { state = THUMB_STATE_NO,
first_touch_time = 29468145253,
initial = { x = -205, y = 5762 } },
speed = { last_speed = 27.794631398589125, exceeded_count = 1 } },
and
{ tp = 0x55952647f5e0,
index = 1,
state = TOUCH_BEGIN,
has_ended = false,
dirty = true,
point = { x = 1456, y = 2133 },
time = 29468145253,
pressure = 0,
is_tool_palm = false,
major = 135,
minor = 203,
was_down = true,
quirks = { reset_motion_history = true },
history = { samples = { { time = 29468121253,
point = { x = 1472, y = 2252 } },
{ time = 29468129254,
point = { x = 1460, y = 2206 } },
{ time = 29468137199,
point = { x = 1451, y = 2173 } },
{ time = 29468145253,
point = { x = 1456, y = 2133 } } },
index = 3,
count = 1 },
jumps = { last_delta_mm = 0 },
hysteresis = { center = { x = 1456, y = 2133 },
x_motion_history = 0 '\000' },
pinned = { is_pinned = false, center = { x = 1740, y = 3448 } },
button = { state = BUTTON_STATE_NONE,
current = 0,
timer = { libinput = 0x5595264688d0,
timer_name = 0x55952647f4c0 "event12 (2) button",
link = { prev = 0x0, next = 0x0 },
expire = 0,
timer_func =
0x7f8624ec3450 < tp_button_handle_timeout >,
timer_func_data = 0x55952647fd40 },
initial = { x = 243, y = 5311 },
has_moved = false },
tap = { state = TAP_TOUCH_STATE_IDLE,
initial = { x = 243, y = 5311 },
is_thumb = false,
is_palm = false },
scroll = { edge_state = EDGE_SCROLL_TOUCH_STATE_NONE,
edge = 0,
direction = -1,
timer = {
Bug#861128: RFP: elpa-markdown-toc -- Generate a TOC in markdown file with Emacs
Control: tag -1 + moreinfo Hi Antoine, On Mon, Apr 24, 2017 at 04:22:35PM -0400, Antoine Beaupre wrote: > Package: wnpp > Severity: wishlist > > * Package name: elpa-markdown-toc > Version : 0.1.2 > Upstream Author : Antoine R. Dumont > * URL : https://github.com/ardumont/markdown-toc/ > * License : GPL-3+ > Programming Lang: Elisp > Description : Generate a TOC in markdown file [...] > > I use this when I write markdown reports that get translated in > standalone HTML documents that I ship to clients. I used to rely on > pandoc's --toc functionality, but that was too limited: I couldn't > control output levels and fix headings the way I wanted. > > It depends on markdown-mode, certain versions: > > https://github.com/ardumont/markdown-toc/issues/29 > > Happy to comaintain... Re: a couple of markdown-toc bugs: https://github.com/ardumont/markdown-toc/issues/29 * Solve in Debian with a hard depends on >= markdown-mode 2.2? * You mentioned markdown-mode 2.1 is bad, 20161222.1416 is good, and 2.2 is from 20170526, thus 2.2 should be good. * possibly fixed in markdown-toc? https://github.com/ardumont/markdown-toc/issues/15 * "Don't assume that a document has an h1" * How serious is this one? Seems like it could be annoying. https://github.com/ardumont/markdown-toc/issues/35 * "Lines starting with # in code sections are treated as headings" * I imagine this one will frustrate many users. By the way, if you'd like I'd be happy to give you an intro on dh-elpa packaging. With the exception of a couple of autopkgtest on LXC workarounds it's easy stuff--the trickiest bit is identifying why an upstream self-test doesn't work on buildd. Also, we're working on improving dh-elpa's documentation, so alternatively it would be nice to hear about your experiences with it--and than make improvements if necessary! dh_elpa(1), dh_elpa_test(1), dh-make-elpa(1), plus Failing that I think I'd like to package this one :-) Cheers, Nicholas signature.asc Description: PGP signature
Bug#861124: ITP: elpa-writeroom-mode -- distraction-free writing for Emacs
On 2018-09-17 20:08:36, Nicholas D Steeves wrote: > I haven't yet heard back from upstream via PM, so I opened an issue > added a forwarded URL. Hopefully the issue is sufficiently vague so > as not to be bothersome. > > I check my archives and found that we quickly transitioned to using > CCed PM list of recipients. The rationale being that websearching the > open mailing lists and bts could potentially provide a target for lazy > litigators (of two American companies). How about this: if we don't > hear for upstream by the end of the month let's meet in person and > I'll summarise the issue. Since those emails were PMs I don't think > it would be appropriate to forward them, even privately. Makes sense, thanks for the update. A. -- When I came back to the United States, I decided that if you could use propaganda for war, you could certainly use it for peace. And "propaganda" got to be a bad word because of the Germans using it, so what I did was to try and find some other words so we found the words "public relations". - Edward Bernays
Bug#901249: xterm: translation overrides for copy/paste do not work as documented
On Sun, Jun 10, 2018 at 05:19:34PM +0200, Thorsten Glaser wrote: > Package: xterm > Version: 333-1 > Severity: normal > > I was working on my .Xresources and found this quite crazy. > I could not select PRIMARY and CLIPBOARD independent of each > other. To reproduce, I chose to have *only* the lines from actually it was never intended that you could select both at the same time. In #336, I've disallowed that. -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: Digital signature
Bug#837091: firefox-esr: EME DRM extention present and enabled
Using the firefox-esr package currently in stable, visiting any page with EME media causes a "you must enable DRM" nag bar to be displayed with an "enable DRM" button. A single click enables DRM and causes the proprietary wildvine plugin to be downloaded, installed, and executed. There is no setting that disables this nag box or prevents it from installing the plugin. Example page: https://bitmovin.com/demos/drm There's no way this behavior is appropriate for a package in "main".
Bug#906236: fatal regression in openssh (1:6.0p1-4+deb7u8) elts for 7/wheezy
On Mon, Sep 17, 2018 at 10:58:15AM +0200, Joost van Baal-Ilić wrote: > Hi, > > After upgrading openssh on debian 7/wheezy from 6.0p1-4+deb7u7 to > 6.0p1-4+deb7u8, > we see > > Sep 17 10:47:13 host sshd[124622]: Failed publickey for root from 1.2.3.4 > port 39792 ssh2 > Sep 17 10:47:13 host sshd[124622]: fatal: xfree: NULL pointer given as > argument [preauth] > > . Login fails: > > joostvb@home:~% ssh root@host > Authentication failed. > > . Downgrading back to 6.0p1-4+deb7u7 restores login functionality. > > Behaviour observed on 2 of our machines. Possibly more debug information > available; please ask. > > Bye, > > Joost > Joost, Thanks to your detailed report and the supplementary information you provided I have been able to determine the cause of the defect in the patch for openssh 1:6.0p1-4+deb7u8. I have just uploaded a new openssh (version 1:6.0p1-4+deb7u10) and published an updated advisory (ELA-37-3). With the additional information I received from you I was able to perform much more thorough testing of these packages and specific testing to ensure that the defect has been corrected. Regards, -Roberto -- Roberto C. Sánchez
Bug#900579: RFS: libminini/1.2.a-1 [ITP]
On Mon, Sep 17, 2018 at 10:26 PM, Yangfl wrote: > I don't see there's a need to edit or regenerate PDF doc; it just > provides some simple API documents. Anyway I remove it since I just > want to provide a shared library (for utox). When the API changes, the documentation will need to change too. There are many other ways documentation can be improved, so source and an automatic build process is just as important for documentation as it is for binaries. -- bye, pabs https://wiki.debian.org/PaulWise
Bug#909064: libc6:amd64: getaddrinfo AF_INET6 behaves differently with nscd
Package: libc6
Version: 2.19-18+deb8u10
Severity: normal
Tags: upstream ipv6 patch
Dear Maintainer,
The behavior of the test program from
https://bugzilla.redhat.com/show_bug.cgi?id=1416496
(titled "getaddrinfo() call returns wrong IPv6 address if nscd is used") when
asked to
return the IPv6 address of my local system varies according to whether nscd is
running.
I think that the configuration is reasonable but, when nscd is running, the
program
fails to return any IPv6 address:
martind@swiftboat:~$ ~/download/getaddrinfo AF_INET6 swiftboat
Hints family=10
error in getaddrinfo: Name or service not known
martind@swiftboat:~$
However, when I stop nscd, a local IPv6 address is returned:
martind@swiftboat:~$ sudo /etc/init.d/nscd stop
[ ok ] Stopping nscd (via systemctl): nscd.service.
martind@swiftboat:~$ ~/download/getaddrinfo AF_INET6 swiftboat
Hints family=10
host=swiftboat, family=10 addr=fdca:f995:220a:8400:ec4:7aff:fe00:cf5c
host=swiftboat, family=10 addr=fdca:f995:220a:8400:ec4:7aff:fe00:cf5c
host=swiftboat, family=10 addr=fdca:f995:220a:8400:ec4:7aff:fe00:cf5c
martind@swiftboat:~$
The applicable line in /etc/nsswitch.conf is:
hosts: files myhostname dns
I think this is the Debian base-files default as modified by the postinst from
libnss-myhostname, a recommendation of gnome-control-center, an (indirect)
dependency of task-gnome-desktop.
The only applicable line in /etc/hosts is:
127.0.1.1 swiftboat.us.dev.bluearc.comswiftboat
I think this is as suggested by the FQDN section in:
https://manpages.debian.org/jessie/hostname/dnsdomainname.1.en.html
Such a line causes hostname --fqdn to return the desired result.
There is no IPv6 address in /etc/hosts, but the host has a dynamically
determined IPv6 address known to libnss-myhostname.
Looking at the interface between glibc and nscd, the client side of which
I think is in sysdeps/posix/getaddrinfo.c's gaih_inet(), where it calls
__nscd_getai, I don't think nscd gets told what address family flags the
application passed to glibc. I think nscd does pay correct attention to
nsswitch.conf, perhaps in the no_more loop in nscd/aicache.c's addhstaiX(),
but (correctly) stops on the first provider that returns any result.
In the case of my configuration, that's "files". The one result returned
there is IPv4, so is discarded by glibc's nscd client leaving no result
to be returned.
If I put "myhostname" before "files" in /etc/nsswitch.conf, then this test
works perfectly but hostname --fqdn returns an unqualified name.
If I put an IPv6 address in /etc/hosts, then this test works perfectly and
I still have a FQDN, but that's inconvenient for a host whose IPv6 address
is dynamic.
Perhaps it's unusual to ask for a IPv6 address specifically from getaddrinfo,
but that's a useful way to determine a local IPv6 endpoint.
For a minority-interest query like that, perhaps it would be acceptable to
forego the full performance benefit of nscd's caching?
I contrived the attached patch on this assumption and saw that it passes this
test.
Apologies for submitting a bug report on such an old version of the code.
I haven't tried to patch any other version but I do see the problem on
Wheezy and Stretch systems as well as Jessie ones.
I think the upstream source would behave the same, but I haven't
experimentally verified that.
Upstream's bug submission guide:
https://sourceware.org/glibc/wiki/FilingBugs
... requested that I submit the issue to Debian first.
I was happy to do that not least because I'm less confident about
upstream's recommended /etc/nsswitch.conf and /etc/hosts.
-- System Information:
Debian Release: 8.10
APT prefers oldstable-updates
APT policy: (990, 'oldstable-updates'), (990, 'oldstable'), (500,
'oldoldstable-updates'), (500, 'oldoldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-6-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages libc6:amd64 depends on:
ii libgcc1 1:4.9.2-10+deb8u1
libc6:amd64 recommends no packages.
Versions of packages libc6:amd64 suggests:
ii debconf [debconf-2.0] 1.5.56+deb8u1
ii glibc-doc 2.19-18+deb8u10
ii locales2.19-18+deb8u10
-- debconf-show failed
--- sysdeps/posix/getaddrinfo.c 2018-09-17 11:00:52.932314024 -0700
+++ /home/martind/tmp/D136297/getaddrinfo.c.after 2018-09-17 11:00:20.821731456 -0700
@@ -788,13 +788,14 @@
free (air);
- if (at->family == AF_UNSPEC)
+ if (at->family == AF_UNSPEC && req->ai_family == AF_UNSPEC)
{
result = -EAI_NONAME;
goto free_and_return;
}
- goto process_list;
+ if (at->family != AF_UNSPEC)
+ goto process_list;
}
else if (err == 0)
/* The database contains a negative entry. */
Bug#900579: RFS: libminini/1.2.a-1 [ITP]
On Mon, Sep 17, 2018 at 6:00 PM, Adam Borowski wrote: > I also don't see any source for the PDF documentation. According to the PDF metadata, the source is minini.dvi and the PDF was built using a very old version of dvips (from texlive-binaries), please ask upstream if they still have a copy of that and get them to include it in the source for the next release. $ pdfinfo minIni.pdf | head -n3 Title: minini.dvi Creator:dvips(k) 5.96dev Copyright 2007 Radical Eye Software Producer: AFPL Ghostscript 8.53 > This makes it impossible for anyone to edit it. Technically there are ways to edit PDFs (pdfmod for eg) but since they are almost never produced this way, they are almost never their own source. -- bye, pabs https://wiki.debian.org/PaulWise
Bug#907999: fonts-noto-cjk: Unable to use system fonts in Firefox after #907048
It may be worth to mention a config file we are using in Ubuntu for the CJK languages (attached). We ship fonts-noto-cjk by default, and that file seems to be sufficient to allow decent rendering in any CJK language irrespective of the locale, i.e. for all users. As a supplement we use language guarded "prepend" for zh-cn and zh-tw to avoid confusion in Chinese user sessions. -- Gunnar Hjalmarsson https://launchpad.net/~gunnarhj sans-serif Noto Sans CJK JP Noto Sans CJK KR Noto Sans CJK SC Noto Sans CJK TC serif Noto Serif CJK JP Noto Serif CJK KR Noto Serif CJK SC Noto Serif CJK TC monospace Noto Sans Mono CJK JP Noto Sans Mono CJK KR Noto Sans Mono CJK SC Noto Sans Mono CJK TC
Bug#861124: ITP: elpa-writeroom-mode -- distraction-free writing for Emacs
Control: forwarded -1 https://github.com/joostkremers/writeroom-mode/issues/45 Hi Antoine! On Mon, Sep 17, 2018 at 03:17:05PM -0400, Antoine Beaupré wrote: > > Hi! > > Pinging again here... Did you get any news from upstream? > > You mentioned a discussion with debian-legal... I looked (briefly) in > the archives and didn't find a trace of this in the mailing list. Can we > get a better idea of what the legal issue is in general? You mention > trademark infringement, which trademark? > > What's our next step here? > > Or did you switch to olivetti mode? :) I haven't yet heard back from upstream via PM, so I opened an issue added a forwarded URL. Hopefully the issue is sufficiently vague so as not to be bothersome. I check my archives and found that we quickly transitioned to using CCed PM list of recipients. The rationale being that websearching the open mailing lists and bts could potentially provide a target for lazy litigators (of two American companies). How about this: if we don't hear for upstream by the end of the month let's meet in person and I'll summarise the issue. Since those emails were PMs I don't think it would be appropriate to forward them, even privately. Cheers, Nicholas signature.asc Description: PGP signature
Bug#904810: ITP: muttrc-mode-el -- Emacs major mode for editing muttrc
user debian-emac...@lists.debian.org usertag 904810 elpafy quit signature.asc Description: PGP signature
Bug#904810: ITP: muttrc-mode-el -- Emacs major mode for editing muttrc
retitle 904810 ITP: muttrc-mode-el -- Emacs major mode for editing muttrc reassign 904810 wnpp thanks This package was previously in emacs-goodies-el, and this bug was originally filed against emacs-goodies-el. While it is being reassigned to wnpp, this bug is for reentry into Debian; therefor priority normal and not wishlist. signature.asc Description: PGP signature
Bug#909060: seems 2011_node-gyp-path.patch might be to blame -
Dear all, I just cloned the repo. from https://anonscm.debian.org/git/pkg-javascript/npm.git/ I saw that in /npm/debian/patches$ cat 2011_node-gyp-path.patch you see - if [ "x$npm_config_node_gyp" = "x" ]; then - node "`dirname "$0"`/../../node_modules/node-gyp/bin/node-gyp.js" "$@" this is mentioned twice in the above patch, maybe something needs to be done there. -- Regards, Shirish Agarwal शिरीष अग्रवाल My quotes in this email licensed under CC 3.0 http://creativecommons.org/licenses/by-nc/3.0/ http://flossexperiences.wordpress.com EB80 462B 08E1 A0DE A73A 2C2F 9F3D C7A4 E1C4 D2D8
Bug#909063: apacheds: package installation fails due to incorrect apacheds.service unit
Package: apacheds Version: 2.0.0~M15-4 Severity: grave Justification: renders package unusable Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** I am unable to install the apacheds package. The installation fails when dpkg attempts to start the service due to incorrect ExecStart= directives in the apacheds.service system unit. I have tried on both stretch and buster, the same problem happens on both. Below I have included the complete output of the apt-get command used, as well as the output of "journalctl -u apacheds.service" after the package failed to install. *** apt-get-install-apacheds.txt root@ldap01:~# apt-get install apacheds Reading package lists... Done Building dependency tree Reading state information... Done The following additional packages will be installed: ant ant-optional ca-certificates-java default-jre-headless fontconfig-config fonts-dejavu-core java-common junit4 libantlr-java libapache-directory-api-java libapache-directory-jdbm-java libapache-pom-java libapacheds-i18n-java libapacheds-java libapacheds-kerberos-codec-java libavahi-client3 libavahi-common-data libavahi-common3 libbcprov-java libcommons-collections3-java libcommons-io-java libcommons-lang-java libcommons-logging-java libcommons-parent-java libcommons-pool-java libcups2 libdom4j-java libehcache-java libfontconfig1 libhamcrest-java libisorelax-java libjaxen-java libjaxp1.3-java libjdom1-java libjetty9-java libjpeg62-turbo liblcms2-2 liblog4j1.2-java libmavibot-java libmina2-java libmsv-java libnspr4 libnss3 libpcsclite1 librelaxng-datatype-java libservlet3.1-java libslf4j-java libxerces2-java libxi6 libxml-commons-external-java libxml-commons-resolver1.1-java libxom-java libxpp2-java libxpp3-java libxrender1 libxtst6 openjdk-8-jre-headless x11-common Suggested packages: ant-doc ant-gcj default-jdk | java-compiler | java-sdk ant-optional-gcj antlr javacc junit jython libbcel-java libbsf-java libcommons-net-java libmail-java libjdepend-java libjsch-java liboro-java libregexp-java libxalan2-java default-jre libbcprov-java-doc libcommons-collections3-java-doc libcommons-io-java-doc libcommons-lang-java-doc libavalon-framework-java libcommons-logging-java-doc libexcalibur-logkit-java cups-common libdom4j-java-doc libjaxp1.3-java-gcj libjdom1-java-doc jetty9 liblcms2-utils liblog4j1.2-java-doc libmina-java-doc libspring-beans-java libjzlib-java libognl-java libtomcat8-java pcscd libxerces2-java-doc libxerces2-java-gcj libxml-commons-resolver1.1-java-doc libxom-java-doc libnss-mdns fonts-dejavu-extra fonts-ipafont-gothic fonts-ipafont-mincho fonts-wqy-microhei fonts-wqy-zenhei fonts-indic The following NEW packages will be installed: ant ant-optional apacheds ca-certificates-java default-jre-headless fontconfig-config fonts-dejavu-core java-common junit4 libantlr-java libapache-directory-api-java libapache-directory-jdbm-java libapache-pom-java libapacheds-i18n-java libapacheds-java libapacheds-kerberos-codec-java libavahi-client3 libavahi-common-data libavahi-common3 libbcprov-java libcommons-collections3-java libcommons-io-java libcommons-lang-java libcommons-logging-java libcommons-parent-java libcommons-pool-java libcups2 libdom4j-java libehcache-java libfontconfig1 libhamcrest-java libisorelax-java libjaxen-java libjaxp1.3-java libjdom1-java libjetty9-java libjpeg62-turbo liblcms2-2 liblog4j1.2-java libmavibot-java libmina2-java libmsv-java libnspr4 libnss3 libpcsclite1 librelaxng-datatype-java libservlet3.1-java libslf4j-java libxerces2-java libxi6 libxml-commons-external-java libxml-commons-resolver1.1-java libxom-java libxpp2-java libxpp3-java libxrender1 libxtst6 openjdk-8-jre-headless x11-common 0 upgraded, 59 newly installed, 0 to remove and 1 not upgraded. Need to get 53.3 MB of archives. After this operation, 141 MB of additional disk space will be used. Do you want to continue? [Y/n] Get:1 http://deb.debian.org/debian stretch/main amd64 libnspr4 amd64 2:4.12-6 [117 kB] Get:2 http://deb.debian.org/debian stretch/main amd64 libnss3 amd64 2:3.26.2-1.1+deb9u1 [1,161 kB] Get:3 http://deb.debian.org/debian stretch/main amd64 ca-certificates-java all 20170531+nmu1 [14.7 kB] Get:4 http://deb.debian.org/debian stretch/main amd64 java-common all 0.58 [13.5 kB] Get:5 http://deb.debian.org/debian stretch/main amd64 libavahi-common-data amd64 0.6.32-2 [118 kB] Get:6 http://deb.debian.org/debian stretch/main amd64 libavahi-common3 amd64 0.6.32-2 [52.0 kB] Get:7 http://deb.debian.org/debian stretch/main amd64 libavahi-client3 amd64 0.6.32-2 [55.3 kB] Get:8 http://deb.debian.org/debian stretch/main amd64 libjpeg62-turbo amd64 1:1.5.1-2 [134 kB] Get:9
Bug#909062: kexec-tools: Want man page for kdump
Package: kexec-tools Version: 1:2.0.14-1 Severity: wishlist Tags: patch Dear Maintainer, I was mildly annoyed by the lack of a real man page for kdump (not that it needs much of one), so I wrote a slightly better one than the stub. I'd love to see it included here or upstream, and thought that requesting its inclusion here might be a decent way to shake out any objections first. If you have any suggestions for improvement or would like to see me just submit it to upstream, I'd be happy to. Thanks, - Rich -- System Information: Debian Release: 9.5 APT prefers stable-debug APT policy: (1000, 'stable-debug'), (1000, 'stable'), (900, 'testing-debug'), (900, 'testing'), (800, 'unstable-debug'), (800, 'unstable'), (500, 'stable-updates'), (500, 'proposed-updates-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-8-amd64 (SMP w/16 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 kexec-tools depends on: ii debconf [debconf-2.0] 1.5.61 ii libc6 2.24-11+deb9u3 ii lsb-base 9.20161125 ii zlib1g 1:1.2.8.dfsg-5 kexec-tools recommends no packages. kexec-tools suggests no packages. -- debconf information excluded .\" Hey, EMACS: -*- nroff -*- .\" First parameter, NAME, should be all caps .\" Second parameter, SECTION, should be 1-8, maybe w/ subsection .\" other parameters are allowed: see man(7), man(1) .TH KDUMP 8 "Sep 17, 2018" .\" Please adjust this date whenever revising the manpage. .\" .\" Some roff macros, for reference: .\" .nhdisable hyphenation .\" .hyenable hyphenation .\" .ad l left justify .\" .ad b justify to both left and right margins .\" .nfdisable filling .\" .fienable filling .\" .brinsert line break .\" .sp insert n+1 empty lines .\" for manpage-specific macros, see man(7) .SH NAME kdump \- Tool to take a Linux kernel dump .SH SYNOPSIS .B kdump .RI [ options ] " start_address" ... .SH DESCRIPTION .PP .\" TeX users may be more comfortable with the \fB\fP and .\" \fI\fP escape sequences to invode bold face and italics, .\" respectively. \fBkdump\fP is a tool to take a crash dump of a formerly-running kernel after kexec into a reserved area of memory with a tiny Linux environment. .SH OPTIONS None. .PP .SH USAGE .PP You almost never want to invoke this directly; see .BR kdump-tools (5) or .BR kexec (8) for what you likely want to know. .SH SEE ALSO .BR makedumpfile (8), .BR crash (8), .BR kdump-tools (5), .BR kexec (8), .BR vmcore-dmesg (8) .SH AUTHOR kdump was written by Eric Biederman. .PP This manual page was initially written by Khalid Aziz , for the Debian project (but may be used by others). Additional content was added by Rich Ercolani .
Bug#908818: [Pkg-zsh-devel] Bug#908818: Reopen: #908818: Zsh: [7] + 23074 suspended (tty output)
Hi Daniel, Daniel Shahaf wrote: > Axel Beckert wrote on Mon, 17 Sep 2018 23:17 +0200: > > Daniel: If you have the patch already in git for your test build, feel > > free to push it to the debian branch on Salsa. > > Actually I just did 'apt-get source zsh/sid' earlier, but I ported that > to git and pushed. The commit2quilt script generated a different > debian/patches/* filename than the one you created last weekend, but > I left that as is. I did that manually for years. I had forgotten that we even have a script for that, despite I added it. Probably because I didn't need it for quite a while. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#909040: davmail: A JNI error has occurred
Control: reassign -1 jarwrapper Control: affects -1 davmail This is a jarwrapper bug, the CheckProperty class was compiled without specifying the source/target level, thus defaulting to Java 10 bytecode (version 54.0).
Bug#872778: xterm -lc (with UTF-8 locale) cannot properly copy some utf-8 unicode chars
On Tue, Sep 18, 2018 at 04:37:00AM +0800, 積丹尼 Dan Jacobson wrote:
> All I know is
> U+7522 CJK UNIFIED IDEOGRAPH-7522
> U+9109 CJK UNIFIED IDEOGRAPH-9109
> show up as empty squares.
Agreed, but that wasn't the point of this particular bug report.
I just created a test-script to print the 5 codepoints mentioned to a
text-file, and use xterm to copy and paste the result. As I pointed
out "select/paste should work". It worked for me - there may be some
locale dependency or resource-setting which is creating the problem
you reported.
(script attached)
--
Thomas E. Dickey
https://invisible-island.net
ftp://ftp.invisible-island.net
#!/usr/bin/env perl
use strict;
use warnings;
use Encode 'encode_utf8';
binmode( STDOUT, ":utf8" );
sub show($$) {
my $code = shift;
my $name = shift;
my $show = sprintf("U+%04X", $code);
printf "%8s \"%c%c%c\" %s\n", $show, $code, $code, $code, $name;
}
(0x1f618, "FACE THROWING A KISS");
(0x7522, "CJK UNIFIED IDEOGRAPH-7522");
(0x9109, "CJK UNIFIED IDEOGRAPH-9109");
(0x0192, "LATIN SMALL LETTER F WITH HOOK");
(0x266E, "MUSIC NATURAL SIGN");
1;
signature.asc
Description: Digital signature
Bug#902570: asm: Package rebuilt from source gets lots of empty jars
Control: fixed -1 6.2.1-1 Control: close -1 It looks like the upgrade to the version 6.2.1 fixed this issue.
Bug#821448: Bug#858654: Intent to NMU colplot to fix longstanding l10n bugs
On 09/15/18 12:25, Helge Kreutzmann wrote: > -- Helge Kreutzmann Sat, 15 Sep 2018 11:52:55 +0200 > Please tell me if you are currently preparing a new release yourself > and would like me to skip the NMU. Thank you for the reminder, I will prepare an upload with the l10n updates this week. Troy signature.asc Description: PGP signature
Bug#896698: deprecating needs-recommends
On Mon, Sep 17, 2018 at 10:50:01PM +0200, gregor herrmann wrote: > On Sat, 15 Sep 2018 15:40:33 +0200, Michael Biebl wrote: > > > On Thu, 30 Aug 2018 12:03:31 +0200 Paul Gevers wrote: > > > I have just pushed commit 9fade8dcb501250f704da9c77af1f8e6165dc941 that > > > documents that we want to remove the needs-recommends option as we > > > discussed in https://lists.debian.org/debian-ci/2018/06/msg00016.html. > > So I have this specific case where I found needs-recommends quite > > convenient: > > I have a package (firewalld) which has optional dependencies like ipset > > or ebtables. If those are not installed, firewalld will log a warning > > and continue with the functionality disabled. > > We're also using needs-recommends for perl packages / in > pkg-perl-autopkgtest. > > % autodep8 > Test-Command: /usr/share/pkg-perl-autopkgtest/runner build-deps > Depends: @, @builddeps@, pkg-perl-autopkgtest > > Test-Command: /usr/share/pkg-perl-autopkgtest/runner runtime-deps > Depends: @, pkg-perl-autopkgtest > > Test-Command: /usr/share/pkg-perl-autopkgtest/runner > runtime-deps-and-recommends > Depends: @, pkg-perl-autopkgtest > Restrictions: needs-recommends > > In practice, there's currently one test in the > "runtime-deps-and-recommends" department: syntax.t which, among other > things, does `perl -wc ' and is helpful to detect > syntax errors in code which is not used during build tests. > Cf. also https://perl-team.pages.debian.net/autopkgtest.html#syntax.t > > The reason we need the packages in Recommends is quite simple: there > are often modules in packages which are no core functionality, hence > their dependencies are not in Depends but in Recommends. > > Without needs-recommends we would > - need to exclude them from syntax.t (the machinery exists but it's > quite some work) > - lose the ability to test them. > > So if needs-recommends vanishes, there will be at least dozens if not > hundreds of perl packages which will immediately fail their > autopkgtests. > > (josch's count of 154 affected packages in > https://lists.debian.org/debian-ci/2018/06/msg00016.html > fails to take all the autodep8 packages into account.) Yes. We will need to find a replacement before dropping needs-recommends completely. Maybe we want autopkgtest to also support @recommends@ alongside @builddeps@? This way tests that use @recommends@ would *depend* on the packages in Recommends:, and thus fail if those become uninstallable. This is contrary to the current status quo, where `Restrictions: needs-recommends` doesn't actually ensure that the packages in Recommends are installed. signature.asc Description: PGP signature
Bug#909061: ITP: openscenegraph-3.6 -- 3D scene graph C++ framework
Package: wnpp Severity: wishlist Owner: Alberto Luaces * Package name: openscenegraph-3.6 Version : 3.6.3 Upstream Author : Robert Osfield * URL : http://www.openscenegraph.org/ * License : OpenSceneGraph Public License, OSGPL Programming Lang: C++ Description : 3D scene graph C++ framework A portable, high level graphics toolkit for the development of high performance graphics applications such as flight simulators, games, virtual reality or scientific visualization. Providing an object orientated framework on top of OpenGL, it frees the developer from implementing and optimizing low level graphics calls, and provide many additional utilities for rapid development of graphics applications. This package intends to bring the new stable 3.6 series, replacing 3.4 and 3.2 already present in the repository.
Bug#907677: s-nail: [INTL:fr] French debconf templates translation
On Fri, 31 Aug 2018 14:47:37 +0800 wrote: > Please find attached the French debconf templates translation, proofread by > the > debian-l10n-french mailing list contributors. Dear Grégoire, There is a newer version of the debconf strings: https://salsa.debian.org/debian/s-nail/tree/master/debian/po The change reflects the deprecation of a s-nail option. This version simpler and more general, thus less likely to vary in the future. Could you please update your translation? Thank you! Paride
Bug#908925: s-nail: [INTL:de] initial German debconf translation
On Sun, 16 Sep 2018 Helge Kreutzmann wrote: > Please find the initial German debconf translation for s-nail > attached. > > Please place this file in debian/po/ as de.po for your next upload. > > If you update your template, please use > 'msgfmt --statistics ' > to check the po-files for fuzzy or untranslated strings. > > If there are such strings, please contact me so I can update the > German translation. Dear Helge, There is a newer version of the debconf strings: https://salsa.debian.org/debian/s-nail/tree/master/debian/po The change reflects the deprecation of a s-nail option. This version simpler and more general, thus less likely to vary in the future. Could you please update your translation? Thank you! Paride
Bug#907991: s-nail: [INTL:pt] Portuguese translation for debconf messages
On Tue, 4 Sep 2018 22:16:28 +0100 Traduz PT wrote: > Updated Portuguese translation for s-nail's debconf messages. > Feel free to use it. > > For translation updates please contact 'Last Translator' or the > Portuguese Translation Team . Dear Portuguese Translation Team, There is a newer version of the debconf strings: https://salsa.debian.org/debian/s-nail/tree/master/debian/po The change reflects the deprecation of a s-nail option. This version simpler and more general, thus less likely to vary in the future. Could you please update your translation? Thank you! Paride
Bug#909060: npm: adequate reports broken symlink of npm: broken-symlink of node-gyp
Package: npm Version: 5.8.0+ds4-1 Severity: normal Dear Maintainer, Thank you for maintaining npm. While trying the new version got the following via adequate - adequate found packaging bugs - npm: broken-symlink /usr/share/npm/node_modules/npm-lifecycle/node_modules/.bin/node-gyp -> ../node-gyp/bin/node-gyp.js The mistake is at the end - ../node-gyp/bin/node-gyp.js it should be - /usr/share/npm/node_modules/npm-lifecycle/node-gyp-bin$ ls node-gyp node-gyp.cmd -- System Information: Debian Release: buster/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (100, 'unstable-debug'), (100, 'experimental-debug'), (100, 'experimental'), (100, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages npm depends on: ii ca-certificates 20170717 ii node-abbrev 1.0.9-1 ii node-ansi 0.3.0-2 ii node-ansi-regex 3.0.0-1 ii node-ansistyles 0.1.3-1 ii node-aproba 1.2.0-1 ii node-archy 1.0.0-1 ii node-bluebird 3.5.1+dfsg2-2 ii node-boxen 1.2.2-1 ii node-call-limit 1.1.0-1 ii node-config-chain 1.1.11-1 ii node-detect-indent 5.0.0-1 ii node-detect-newline 2.1.0-1 ii node-editor 1.0.0-1 ii node-encoding 0.1.12-2 ii node-from2 2.3.0-1 ii node-fs-vacuum 1.2.10-2 ii node-fs-write-stream-atomic 1.0.10-4 ii node-glob 7.1.2-6 ii node-graceful-fs4.1.11-1 ii node-gyp3.6.2-2 ii node-has-unicode2.0.1-2 ii node-hosted-git-info2.7.1-1 ii node-iferr 1.0.2-1 ii node-import-lazy3.0.0.REALLY.2.1.0-1 ii node-inflight 1.0.6-1 ii node-inherits 2.0.3-1 ii node-ini1.3.5-1 ii node-is-npm 1.0.0-1 ii node-json-parse-better-errors 1.0.2-2 ii node-jsonstream 1.3.2-1 ii node-latest-version 3.1.0-1 ii node-lazy-property 1.0.0-3 ii node-lockfile 1.0.4-1 ii node-lru-cache 4.1.1-2 ii node-marked-man 0.3.0-2 ii node-minimatch 3.0.4-3 ii node-mississippi3.0.0-1 ii node-mkdirp 0.5.1-1 ii node-move-concurrently 1.0.1-1 ii node-nopt 3.0.6-3 ii node-normalize-package-data 2.4.0-1 ii node-npm-package-arg6.0.0-2 ii node-npmlog 4.1.2-1 ii node-once 1.4.0-2 ii node-opener 1.4.3-1 ii node-osenv 0.1.4-1 ii node-path-is-inside 1.0.2-1 ii node-promise-inflight 1.0.1-1 ii node-promzard 0.3.0-1 ii node-qw 1.0.1-1 ii node-read 1.0.7-1 ii node-read-package-json 2.0.13-1 ii node-request2.26.1-1 ii node-resolve-from 4.0.0-1 ii node-retry 0.10.1-1 ii node-rimraf 2.6.2-1 ii node-safe-buffer5.1.2-1 ii node-semver 5.5.1-1 ii node-semver-diff2.1.0-2 ii node-sha2.0.1-1 ii node-slide 1.1.6-2 ii node-sorted-object 2.0.1-1 ii node-ssri 5.2.4-2 ii node-stream-iterate 1.2.0-4 ii node-strip-ansi 4.0.0-1 ii node-tar4.4.4+ds1-2 ii node-text-table 0.2.0-2 ii node-uid-number 0.0.6-1 ii node-unique-filename1.1.0+ds-2 ii node-unpipe 1.0.0-1 ii node-validate-npm-package-name 3.0.0-1 ii node-which 1.3.0-2 ii node-wrappy 1.0.2-1 ii node-write-file-atomic 2.3.0-1 ii node-xdg-basedir3.0.0-1 ii node-yargs 10.0.3-2 ii nodejs 8.11.2~dfsg-1 npm recommends no packages. npm suggests no packages. -- no debconf information -- Regards, Shirish Agarwal शिरीष अग्रवाल My quotes in this email licensed under CC 3.0 http://creativecommons.org/licenses/by-nc/3.0/ http://flossexperiences.wordpress.com EB80 462B 08E1 A0DE A73A 2C2F 9F3D C7A4 E1C4 D2D8
Bug#909014: [pkg-gnupg-maint] Bug#909014: Bug#909014: pinentry-efl binary package build request
On 18/09/2018 00:26, Daniel Kahn Gillmor wrote: libsecret talks to the "secret service", which afaik is provided only by GNOME Keyring these days. In this case I though pinentry-efl (as qt and fltk versions) should not talk to libsecret. -- sergio.
Bug#909059: nvidia-legacy-340xx-driver: Crash ends session after multiple suspend/resume cycles
Package: nvidia-legacy-340xx-driver Version: 340.107-2 Severity: grave Tags: upstream Justification: causes non-serious data loss When I suspend and resume my computer multiple times with a live X session with multiple applications running, it tends to crash the X server and terminate the session. These crashes seem to be absent or at least much rarer when I don't have big applications like Firefox open in the session. They seem to have become more frequent (or present at all) since upgrading from a 1920x1200 display to un that runs at 4k resolution. The contents of /var/log/Xorg.*.log* are ancient junk, since the session log is recorded in my ~/.local/share/xorg directory since 2015 (I think since the systemd transition, perhaps). So, I have deleted the junk log from below, and include the recent log with a back trace here: > Xorg log [ 6536.528] _XSERVTransSocketUNIXCreateListener: ...SocketCreateListener() failed [ 6536.528] _XSERVTransMakeAllCOTSServerListeners: server already running [ 6536.528] (--) Log file renamed from "/home/phil/.local/share/xorg/Xorg.pid-11284.log" to "/home/phil/.local/share/xorg/Xorg.1.log" [ 6536.528] X.Org X Server 1.20.1 X Protocol Version 11, Revision 0 [ 6536.528] Build Operating System: Linux 4.9.0-7-amd64 x86_64 Debian [ 6536.528] Current Operating System: Linux itu 4.18.0-1-amd64 #1 SMP Debian 4.18.6-1 (2018-09-06) x86_64 [ 6536.529] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.18.0-1-amd64 root=UUID=3e436e2a-5d44-49aa-a1f1-d6d8e67b1b08 ro slab_common.usercopy_fallback=Y quiet resume=/dev/sda6 [ 6536.529] Build Date: 17 August 2018 08:05:00PM [ 6536.529] xorg-server 2:1.20.1-1 (https://www.debian.org/support) [ 6536.529] Current version of pixman: 0.34.0 [ 6536.529]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 6536.529] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 6536.529] (==) Log file: "/home/phil/.local/share/xorg/Xorg.1.log", Time: Wed Sep 12 14:27:21 2018 [ 6536.529] (==) Using config file: "/etc/X11/xorg.conf" [ 6536.529] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [ 6536.529] (==) No Layout section. Using the first Screen section. [ 6536.529] (**) |-->Screen "Default Screen" (0) [ 6536.529] (**) | |-->Monitor "Configured Monitor" [ 6536.530] (==) No device specified for screen "Default Screen". Using the first device section listed. [ 6536.530] (**) | |-->Device "Configured Video Device" [ 6536.530] (==) Automatically adding devices [ 6536.530] (==) Automatically enabling devices [ 6536.530] (==) Automatically adding GPU devices [ 6536.530] (==) Max clients allowed: 256, resource mask: 0x1f [ 6536.530] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. [ 6536.530]Entry deleted from font path. [ 6536.530] (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, built-ins [ 6536.530] (**) ModulePath set to "/usr/lib/xorg/modules/linux,/usr/lib/xorg/modules" [ 6536.530] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [ 6536.530] (II) Loader magic: 0x55aedee4bde0 [ 6536.530] (II) Module ABI versions: [ 6536.530]X.Org ANSI C Emulation: 0.4 [ 6536.530]X.Org Video Driver: 24.0 [ 6536.530]X.Org XInput driver : 24.1 [ 6536.530]X.Org Server Extension : 10.0 [ 6536.531] (++) using VT number 2 [ 6536.534] (II) systemd-logind: took control of session /org/freedesktop/login1/session/_310 [ 6536.534] (II) xfree86: Adding drm device (/dev/dri/card0) [ 6536.535] (II) systemd-logind: got fd for /dev/dri/card0 226:0 fd 13 paused 0 [ 6536.539] (--) PCI:*(1@0:0:0) 10de:0659:10de:063a rev 161, Mem @ 0xfa00/16777216, 0xc000/536870912, 0xf800/33554432, I/O @ 0xec00/128, BIOS @ 0x/131072 [ 6536.540] (II) LoadModule: "glx" [ 6536.540] (II) Loading /usr/lib/xorg/modules/linux/libglx.so [ 6536.555] (II) Module glx: vendor="NVIDIA Corporation" [ 6536.555]compiled for 4.0.2, module version = 1.0.0 [ 6536.555]Module class: X.Org Server Extension [ 6536.555] (II) NVIDIA GLX Module 340.107 Thu May 24 21:40:32 PDT 2018 [ 6536.555] (II) LoadModule: "nvidia" [ 6536.555] (II) Loading /usr/lib/xorg/modules/drivers/nvidia_drv.so [ 6536.556] (II) Module nvidia: vendor="NVIDIA Corporation" [ 6536.556]compiled for 4.0.2, module version = 1.0.0 [ 6536.556]Module class: X.Org Video Driver [ 6536.556] (II) NVIDIA dlloader X Driver 340.107 Thu May 24 21:18:05 PDT
Bug#908818: [Pkg-zsh-devel] Bug#908818: Reopen: #908818: Zsh: [7] + 23074 suspended (tty output)
Axel Beckert wrote on Mon, 17 Sep 2018 23:17 +0200: > Daniel: If you have the patch already in git for your test build, feel > free to push it to the debian branch on Salsa. Actually I just did 'apt-get source zsh/sid' earlier, but I ported that to git and pushed. The commit2quilt script generated a different debian/patches/* filename than the one you created last weekend, but I left that as is. Thanks, Daniel
Bug#909058: fonts-telu-extra: adequate reports broken symlink for fonts-telu-extra
Package: fonts-telu-extra
Version: 2.0-4
Severity: normal
Dear Maintainer,
Thank you for maintaining indic fonts. While troubleshooting
yesterday, I purged and installed fonts-telu. Interestingly, it wanted
to install fonts-telu-extra as well -
$ sudo aptitude install fonts-telu
[97%]
The following NEW packages will be installed:
fonts-telu fonts-telu-extra{a}
0 packages upgraded, 2 newly installed, 0 to remove and 91 not upgraded.
Need to get 0 B/185 kB of archives. After unpacking 457 kB will be used.
Do you want to continue? [Y/n/?] n
Abort.
sudo aptitude install fonts-telu fonts-telu-extra
[97%]
The following NEW packages will be installed:
fonts-telu fonts-telu-extra
0 packages upgraded, 2 newly installed, 0 to remove and 91 not upgraded.
Need to get 0 B/185 kB of archives. After unpacking 457 kB will be used.
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
(Reading database ... 806597 files and directories currently installed.)
Preparing to unpack .../fonts-telu-extra_2.0-4_all.deb ...
Unpacking fonts-telu-extra (2.0-4) ...
Selecting previously unselected package fonts-telu.
Preparing to unpack .../fonts-telu_2%3a1.2_all.deb ...
Unpacking fonts-telu (2:1.2) ...
Setting up fonts-telu-extra (2.0-4) ...
Setting up fonts-telu (2:1.2) ...
Processing triggers for fontconfig (2.13.0-5) ...
adequate found packaging bugs
-
fonts-telu-extra: broken-symlink
/etc/fonts/conf.d/65-0-fonts-telu-extra.conf ->
../conf.avail/65-0-fonts-telu-extra.conf
Interestingly, if you purge the packages it doesn't clean itself
properly as well .
$ sudo aptitude purge fonts-telu fonts-telu-extra -y
The following packages will be REMOVED:
fonts-telu{p} fonts-telu-extra{p}
0 packages upgraded, 0 newly installed, 2 to remove and 0 not upgraded.
Need to get 0 B of archives. After unpacking 457 kB will be freed.
(Reading database ... 413598 files and directories currently installed.)
Removing fonts-telu (2:1.2) ...
Removing fonts-telu-extra (2.0-4) ...
Processing triggers for fontconfig (2.13.0-5) ...
(Reading database ... 413588 files and directories currently installed.)
Purging configuration files for fonts-telu-extra (2.0-4) ...
dpkg: warning: while removing fonts-telu-extra, directory
'/usr/share/fonts/truetype/fonts-telu-extra' not empty so not removed
Processing triggers for fontconfig (2.13.0-5) ...
/usr/share/fonts/truetype/fonts-telu-extra$ ls
/usr/share/fonts/truetype/fonts-telu-extra$
Could you please fix fonts-telu-extra ?
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable-debug'), (500,
'stable-debug'), (100, 'unstable'), (1, 'experimental-debug'), (1,
'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 4.18.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_IN.UTF-8, LC_CTYPE=en_IN.UTF-8 (charmap=UTF-8)
(ignored: LC_ALL set to en_IN.UTF-8), LANGUAGE=en_IN.UTF-8
(charmap=UTF-8) (ignored: LC_ALL set to en_IN.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
-- Configuration Files:
/etc/fonts/conf.avail/65-0-fonts-telu-extra.conf [Errno 2] No such
file or directory: '/etc/fonts/conf.avail/65-0-fonts-telu-extra.conf'
-- no debconf information
--
Regards,
Shirish Agarwal शिरीष अग्रवाल
My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A 2C2F 9F3D C7A4 E1C4 D2D8
Bug#882666: "*.libretro" key/value files are missing
On Mon, Sep 17, 2018 at 4:48 PM Patrick Ammann wrote: > When i add files like found here manually (e.g. nestopia.libretro) it > starts to work: nestopia is fixed in https://salsa.debian.org/games-team/nestopia/commits/master but the package maintainer hasn't uploaded the fix yet to Debian. Thanks, Jeremy Bicha
Bug#909057: RFS: calibre/3.31.0+dfsg-1~bpo9+1
Package: sponsorship-requests Severity: normal Hi Chris, and dear mentors, I am looking for a sponsor for my update to the "calibre" stretch-backport. It is a no-change backport, and I confirmed that it works perfectly well with my Kobo. This update is justified because epub to mobi conversion was broken for a time; as I do not own a Kindle I am not able to confirm for what versions this functionality was broken. Don't forget to build with -v3.26.0+dfsg-1~bpo9+1 Package name: calibre Version : 3.31.0+dfsg-1~bpo9+1 URL : https://calibre-ebook.com/ License : GPL-3, GPL2+, BSD-3-Clause, LGPL-2.1+, MIT, BSD-2-Clause, et al Section : text It builds these binary packages: calibre - powerful and easy to use e-book manager calibre-bin - powerful and easy to use e-book manager To access further information about this package, please visit the following URL: https://mentors.debian.net/package/calibre Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/c/calibre/calibre_3.31.0+dfsg-1~bpo9+1.dsc Changes since the last upload: calibre (3.31.0+dfsg-1~bpo9+1) stretch-backports; urgency=medium * Rebuild for stretch-backports. -- Nicholas D Steeves Sun, 16 Sep 2018 21:30:02 -0400 calibre (3.31.0+dfsg-1) unstable; urgency=medium * New upstream version 3.31.0+dfsg -- Norbert Preining Fri, 07 Sep 2018 15:06:49 +0900 calibre (3.30.0+dfsg-1) unstable; urgency=medium * New upstream version 3.30.0+dfsg (probably already fixed much earlier) - python epub to mobi conversion works (Closes: #699057) - PyQt4 not used anymore (Closes: #771550) - markdown patch is not used anymore (Closes: #723907) - properly open directories (Closes: #738535) - man pages are now available for calibre/ebook cmds (Closes: #766555) * add python-html5lib for recipe dependencies (Closes: #906572) * add depends on libjpeg-turbo-progs and optipng for image optimization in ebook editor (Closes: #884767) -- Norbert Preining Fri, 24 Aug 2018 12:50:53 +0900 calibre (3.29.0+dfsg-1) unstable; urgency=medium * New upstream version 3.29.0+dfsg * update patches -- Norbert Preining Fri, 10 Aug 2018 21:22:26 +0900 calibre (3.28.0+dfsg-1) unstable; urgency=medium * New upstream version 3.28.0+dfsg -- Norbert Preining Sat, 21 Jul 2018 13:44:07 +0900 calibre (3.27.1+dfsg-1) unstable; urgency=medium * New upstream version 3.27.1+dfsg -- Norbert Preining Mon, 09 Jul 2018 14:06:12 +0900 calibre (3.26.1+dfsg-1) unstable; urgency=medium Regards, Nicholas D Steeves
Bug#905123: [pkg-uWSGI-devel] Bug#905123: additional info
Quoting Jonas Smedegaard (2018-09-17 19:26:34)
> Quoting Diego Roversi (2018-09-17 17:45:22)
> > Dear maintener,
> >
> > instead to revert changes to do_command, you can also just apply this
> > simple patch:
> >
> > --- do_command.orig 2018-07-10 10:41:47.0 +
> > +++ do_command 2018-09-17 15:28:57.799075703 +
> > @@ -80,7 +80,7 @@
> > ERRORS="$((ERRORS+$?))"
> >done 4< <(find "$UWSGI_APPS_CONFDIRS" \
> >-regextype posix-basic \
> > - -iregex ".*\\.${UWSGI_CONFFILE_TYPES_REGEXP}\$" -a
> > -xtype f \
> > + -iregex ".*\.${UWSGI_CONFFILE_TYPES_REGEXP}\$" -a -xtype
> > f \
> >-print0 \
> > | sed -e "s:\\(^\\|\\x0\\)${UWSGI_CONFDIR}/:\\1:g" \
> >-e
> > "s:\\([^\\x0/]\\+\\)\\([^\\x0]\\+\\)\\?/\\([^/\\x0]\\+\\)\\.${UWSGI_CONFFILE_TYPES_REGEXP}\\x0:\\1/\\3\\x0:g"
> > \
> >
> > It should be enough. It worked for me: I tested on a fresh vm with
> > testing and sysvinit.
>
> Thanks a lot. Above looks actually sensible (unlike reverting the whole
> patch, which I looked into but then backed off from.
No wait, sorrym, not even that makes sense to me.
Please describe exactly what failed before above change which succeeds
with that change applied. I.e. which uwsgi file paths were ignored
before which now gets included?
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
Bug#902597: protobuf ftbfs with python3.7
severity 902597 grave affects 902597 src:gnocchi reopen 902597 thanks I'm setting this as "grave" because it breaks other packages. I'm also marking the bug as reopened so that it's shown as a pending issue at the top of this page: https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=gnocchi Please consider uploading for unstable. Thanks.
Bug#772800: po-debconf: podebconf-report-po --bts=NNNN doesn't produce Reply-To field
On Thu, 11 Dec 2014 09:16:18 + Ian Campbell wrote: > Package: po-debconf > Version: 1.0.16+nmu3 > Severity: important > > I ran: > podebconf-report-po --postpone=mbox --bts=772771 > and it produced me an mbox where the text correctly referred to respecting the > reply-to and gave the bug number but the message headers themselves did not. I think there is something broken in how the headers are added in general. If I try to add a header using the "# followed by a 'Name: Value'" syntax no header is added, even if ParseHeaders() seems to correctly find them. Paride
Bug#909040: Analysis
Hi, Thanks for reporting. Debian buster has java10 as default java. I cannot make davmail run with java8 and java10 and at the same time compile it with java10. I'm seeking advice for now about how to solve. You can work around the bug by running davmail with java10: $ sudo update-alternatives --config java or $ /usr/lib/jvm/java-10-openjdk-amd64/bin/java -jar /usr/share/java/davmail.jar /etc/davmail.properties Thanks, Alex
Bug#909014: [pkg-gnupg-maint] Bug#909014: Bug#909014: pinentry-efl binary package build request
over in https://bugs.debian.org/909014, sergio asked for inclusion of GnuPG's pinentry-efl in debian. sergio wrote:: > On 17/09/2018 22:54, Daniel Kahn Gillmor wrote: > >> i hadn't heard from any debian users that this was desirable > > Hope pkg-e-de...@lists.alioth.debian.org will say this is desirable. > > Is it possible to subscribe it to this bug? we can certainly cc the pkg-e-devel list, as i'm doing here! >> do you think that pinentry-efl should talk to libsecret (the way that >> pinentry-gnome3 and pinentry-gtk2 do), or do you think it should be >> independent of libsecret? > > I even don't understand why pinentry-gnome3/gtk2 depends on libsecret > and pinentry-qt/fltk does not. Are them statically compiled to do not > make debian package dependencies? Anyway I thought pkg-e-devel should > provide a more complete answer. i think the underlying question is whether we expect to be pulling in extra dependencies that will be useful or not. libsecret talks to the "secret service", which afaik is provided only by GNOME Keyring these days. If a user is using GNOME, then they're likely to use one of these pinentries. if they're not using GNOME, then presumably they've opted for something else, and we don't want to pull in extra unwanted or unnecessary dependencies. that said, this isn't a strong argument from me, just a reconstruction of what i can recall of the decision-making process. if anyone else has strong feelings about this, or wants to propose a change that they think will help users of GnuPG's pinentry, i always welcome that kind of discussion. all the best, --dkg signature.asc Description: PGP signature
Bug#909056: SyntaxError: addonsInfo.js:91:66
Package: firefox-esr Version: 60.2.0esr-1~deb9u2 Severity: minor Dear Maintainer, Start Firefox-esr, open browser console (Ctrl+Shift+J), view error: SyntaxError: "0"-prefixed octal literals and octal escape sequences are deprecated; for octal literals use the "0o" prefix instead[Learn More] addonsInfo.js:91:66 Contract ID '@mozilla.org/toolkit/addonsInfo-clh;1' was registered as a command line handler for entry 'a-addons-info', but could not be created. This error in every start Firefox-esr. Also after start reportdebug in browser console appear warning: Warning: unrecognized command line flag -dump-addons-info nsBrowserContentHandler.js:776 -- Package-specific info: -- Addons package information -- System Information: Debian Release: 9.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-7-amd64 (SMP w/2 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages firefox-esr depends on: ii debianutils 4.8.1.1 ii fontconfig2.11.0-6.7+b1 ii libatk1.0-0 2.22.0-1 ii libc6 2.24-11+deb9u3 ii libcairo-gobject2 1.14.8-1 ii libcairo2 1.14.8-1 ii libdbus-1-3 1.10.26-0+deb9u1 ii libdbus-glib-1-2 0.108-2 ii libevent-2.0-52.0.21-stable-3 ii libffi6 3.2.1-6 ii libfontconfig12.11.0-6.7+b1 ii libfreetype6 2.6.3-3.2 ii libgcc1 1:6.3.0-18+deb9u1 ii libgdk-pixbuf2.0-02.36.5-2+deb9u2 ii libglib2.0-0 2.50.3-2 ii libgtk-3-03.22.11-1 ii libjsoncpp1 1.7.4-3 ii libpango-1.0-01.40.5-1 ii libstartup-notification0 0.12-4+b2 ii libstdc++66.3.0-18+deb9u1 ii libvpx4 1.6.1-3+deb9u1 ii libx11-6 2:1.6.4-3 ii libx11-xcb1 2:1.6.4-3 ii libxcb-shm0 1.12-1 ii libxcb1 1.12-1 ii libxcomposite11:0.4.4-2 ii libxdamage1 1:1.1.4-2+b3 ii libxext6 2:1.3.3-1+b2 ii libxfixes31:5.0.3-1 ii libxrender1 1:0.9.10-1 ii libxt61:1.1.5-1 ii procps2:3.3.12-3+deb9u1 ii zlib1g1:1.2.8.dfsg-5 Versions of packages firefox-esr recommends: ii libavcodec57 7:3.2.12-1~deb9u1 Versions of packages firefox-esr suggests: pn fonts-lmodern pn fonts-stix | otf-stix ii libcanberra0 0.30-3 ii libgssapi-krb5-2 1.15-1+deb9u1 ii libgtk2.0-02.24.31-2 -- no debconf information
Bug#908698: smarty3: CVE-2018-16831
On Mon, Sep 17, 2018 at 09:07:38PM +, Mike Gabriel wrote: > I have looked at the changes between 3.1.33 (just uploaded to unstable) and > 3.1.31 (in stable). They are awful. Read the below... > > 15:42 < sunweaver> Hi all, I have just looked into > https://security-tracker.debian.org/tracker/CVE-2018-16831 > 15:43 < sunweaver> even for stretch, it is pretty much impossible to > backport the patch series (at least for patches, all containing tons of > regexp with > multitudes of slashes and backslashes). > 15:43 < sunweaver> totall insane... > 15:44 < sunweaver> in fact, my recommendation for jessie and stretch would > be (with my maintainer hat _and_ LTS team hats on at once): bring the latest > upstream release to jessie/stretch. > 15:44 < sunweaver> In jessie, we need to upgrade smarty-lexer as well for > that. > 15:46 < sunweaver> the 4 patches we needed at least are these... > 15:47 < sunweaver> > https://github.com/smarty-php/smarty/commit/8d21f38dc35c4cd6b31c2f23fc9b8e5adbc56dfe > 15:47 < sunweaver> > https://github.com/smarty-php/smarty/commit/f9ca3c63d1250bb56b2bda609dcc9dd81f0065f8 > 15:47 < sunweaver> > https://github.com/smarty-php/smarty/commit/2e081a51b1effddb23f87952959139ac62654d50 > 15:47 < sunweaver> > https://github.com/smarty-php/smarty/commit/c9dbe1d08c081912d02bd851d1d1b6388f6133d1 > 15:48 < sunweaver> and these four sit on top of this... > 15:48 < sunweaver> > https://github.com/smarty-php/smarty/commit/f7a53162058de410a35a9848e6d0795d7c252aaf > 15:48 < sunweaver> and 10+ other commits. > 15:48 < sunweaver> all tackling the same code passage. > 15:49 < sunweaver> @all: can we reach consensus that latest upstream release > would be best for jessie LTS and stretch (OT here). > > The pile of patches is so awful, I strongly advise getting latest > smarty-lexer and latest smarty3 from unstable into stable with thorough > testing of dependent application (gosa, FusionDirectory, slbackup-php, ...). > Most of them are maintained by me and I have running setups for testing this > (except 1 package in Debian IIRC). If you have reasonable test coverage of the reverse deps, we can do that. But let's wait for a few more days to spot eventual regressions reported in unstable first. Also, make sure to coordinate the release of the DLA with the DSA, otherwise we end up with a situation where oldstable has a higher version number than stable. Cheers, Moritz
Bug#909018: gnome-shell: fail to switch between applications, desktop and to show all applications of a desktop
On Mon, 17 Sep 2018 at 16:04:19 +0200, Paul Compagnon wrote: >* What led up to the situation? this is how gnome-shell behave since a fex > days What does "this" mean? Please describe exactly what you did when trying to "switch between applications, desktop and to show all applications of a desktop". Also please describe what you expected to happen, and what actually happened. For instance, you might say something like this: """ What I did: * run Files * run Firefox * hold Alt * press Tab Expected result: * a list of running applications appears * when I press Tab, a Files icon is selected * when I let go of Alt, the Files window appears Actual result: * GNOME Shell crashed """ Thanks, smcv
Bug#852342: Workaround
I agree that this is a bug, and at the very least an option should be passed to make-jpkg to disable symbol stripping. Luckily this can be worked-around without a patch by passing "DEB_BUILD_OPTIONS=nostrip” in the env when calling make-jpkg.
Bug#905123: [pkg-uWSGI-devel] Bug#905123: additional info
Quoting Diego Roversi (2018-09-17 17:45:22)
> Dear maintener,
>
> instead to revert changes to do_command, you can also just apply this
> simple patch:
>
> --- do_command.orig 2018-07-10 10:41:47.0 +
> +++ do_command 2018-09-17 15:28:57.799075703 +
> @@ -80,7 +80,7 @@
> ERRORS="$((ERRORS+$?))"
>done 4< <(find "$UWSGI_APPS_CONFDIRS" \
>-regextype posix-basic \
> - -iregex ".*\\.${UWSGI_CONFFILE_TYPES_REGEXP}\$" -a -xtype
> f \
> + -iregex ".*\.${UWSGI_CONFFILE_TYPES_REGEXP}\$" -a -xtype f
> \
>-print0 \
> | sed -e "s:\\(^\\|\\x0\\)${UWSGI_CONFDIR}/:\\1:g" \
>-e
> "s:\\([^\\x0/]\\+\\)\\([^\\x0]\\+\\)\\?/\\([^/\\x0]\\+\\)\\.${UWSGI_CONFFILE_TYPES_REGEXP}\\x0:\\1/\\3\\x0:g"
> \
>
> It should be enough. It worked for me: I tested on a fresh vm with testing
> and sysvinit.
Thanks a lot. Above looks actually sensible (unlike reverting the whole
patch, which I looked into but then backed off from.
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
Bug#908818: [Pkg-zsh-devel] Reopen: #908818: Zsh: [7] + 23074 suspended (tty output)
Hi, Daniel Shahaf wrote: > TS wrote on Mon, 17 Sep 2018 21:54 +0200: > > Just to be sure i again tried stock debian zsh 5.6.2 which still fails for > > me. > > The version you uploaded fixes it for me. > > Thanks for testing both versions! A thanks from me, too. Will soon upload 5.6.2-2 with that patch and some more changes I have planned for the next upload. Daniel: If you have the patch already in git for your test build, feel free to push it to the debian branch on Salsa. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#909055: RM: ubiquity-extension/0.6.4~pre20140729-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm Broken with Firefox ESR60 and dead upstream. Filed for removal from the archive in #909053, also remove it from stable. Cheers, Moritz
Bug#909027: Leaves daemons running after purge
On Mon, 17 Sep 2018 at 15:36:48 -0400, Jeremy Bicha wrote: > On Mon, Sep 17, 2018 at 12:47 PM Steve McIntyre wrote: > > >I appear to have had some of the gvfs packages installed by accident > > >on my machine, I guess through dependencies. I noticed this a few days > > >ago and purged them all. I saw no errors when I did that. I noticed > > >again today that I still have gvfs programs running. This is clearly > > >not right. > > The gvfs daemon are system user services. I assume this was meant to say "systemd user services" (that is, services that are managed by the systemd --user process that runs under your own uid, as opposed to systemd system services, which are managed by pid 1). Various other packages install per-user daemons, some of which are managed by systemd, some of which are not, and many of which can go either way depending on whether systemd --user is in use. We've had per-user daemons for a long time, some of them longer than I've been involved in Debian - prominent examples include ssh-agent, gpg-agent, configuration synchronization points like dconf and gconf, IPC systems like D-Bus and CORBA, and sound mixers like pulseaudio, esd and arts. > These services keep running > after removal; another example is gpg-agent. All you need to do is log > out for the services to be stopped. I don't think Debian has ever had a general solution to terminating per-user services on remove or purge. The least-bad option I can see would be to use pkill or killall from the postinst, but that comes with a serious risk of accidentally terminating processes other than the one being removed (for example if you'd removed the packaged gvfs services in order to run your own /usr/local/bin/gvfsd, you'd be upset if the maintainer script killed that). Even if we can assume that all interesting per-user daemons are systemd user services, it's generally considered to be an anti-pattern for a system-wide operation (removing a package) to reach into user sessions and do things there. In particular, it can't use D-Bus on the session bus, because the trust relationships would be wrong: D-Bus clients trust their dbus-daemon, but maintainer scripts running as root must not trust a dbus-daemon running as a user. smcv
Bug#909014: [pkg-gnupg-maint] Bug#909014: pinentry-efl binary package build request
On 17/09/2018 22:54, Daniel Kahn Gillmor wrote: i hadn't heard from any debian users that this was desirable Hope pkg-e-de...@lists.alioth.debian.org will say this is desirable. Is it possible to subscribe it to this bug? do you think that pinentry-efl should talk to libsecret (the way that pinentry-gnome3 and pinentry-gtk2 do), or do you think it should be independent of libsecret? I even don't understand why pinentry-gnome3/gtk2 depends on libsecret and pinentry-qt/fltk does not. Are them statically compiled to do not make debian package dependencies? Anyway I thought pkg-e-devel should provide a more complete answer. -- sergio.
Bug#909054: RM: searchload-options -- RoQA; Dead upstream, broken with Firefox ESR60
Package: ftp.debian.org Severity: normal Hi, please remove searchload-options. It's broken with Firefox ESR60 and dead upstream for a long time (#814563) Cheers, Moritz
Bug#814563: xul-ext-searchload-options abandoned upstream
On Mon, Jul 23, 2018 at 06:18:28PM +0800, David Prévot wrote: > Hi Christoph, > > On Sat, May 14, 2016 at 01:46:51AM +0200, Christoph Anton Mitterer wrote: > > > I think this is any extremely helpful add-on, and just because there is > > (currently) no active upstream, doesn't mean it must necessarily be > > removed. > > […] > > > So pleas refrain from dropping it, unless there would be no way around > > it in some point in the future. > > With the move to the new webext format, I guess it’s now time to get rid > of xul-ext-searchload-options. I’d like to ask for it’s removal unless > someone really wants to take it over. I just went ahead and filed a removal bug. Cheers, Moritz
Bug#908698: smarty3: CVE-2018-16831
(Re-sending, with security@d.o in Cc: now). Hi Salvatore, On Mi 12 Sep 2018 21:37:18 CEST, Salvatore Bonaccorso wrote: Source: smarty3 Version: 3.1.32+20180424.1.ac9d4b58+selfpack1-1 Severity: important Tags: security upstream Forwarded: https://github.com/smarty-php/smarty/issues/486 Hi, The following vulnerability was published for smarty3. CVE-2018-16831[0]: | Smarty before 3.1.33-dev-4 allows attackers to bypass the trusted_dir | protection mechanism via a file:./../ substring in an include | statement. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2018-16831 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-16831 [1] https://github.com/smarty-php/smarty/issues/486 Please adjust the affected versions in the BTS as needed. Regards, Salvatore I have looked at the changes between 3.1.33 (just uploaded to unstable) and 3.1.31 (in stable). They are awful. Read the below... 15:42 < sunweaver> Hi all, I have just looked into https://security-tracker.debian.org/tracker/CVE-2018-16831 15:43 < sunweaver> even for stretch, it is pretty much impossible to backport the patch series (at least for patches, all containing tons of regexp with multitudes of slashes and backslashes). 15:43 < sunweaver> totall insane... 15:44 < sunweaver> in fact, my recommendation for jessie and stretch would be (with my maintainer hat _and_ LTS team hats on at once): bring the latest upstream release to jessie/stretch. 15:44 < sunweaver> In jessie, we need to upgrade smarty-lexer as well for that. 15:46 < sunweaver> the 4 patches we needed at least are these... 15:47 < sunweaver> https://github.com/smarty-php/smarty/commit/8d21f38dc35c4cd6b31c2f23fc9b8e5adbc56dfe 15:47 < sunweaver> https://github.com/smarty-php/smarty/commit/f9ca3c63d1250bb56b2bda609dcc9dd81f0065f8 15:47 < sunweaver> https://github.com/smarty-php/smarty/commit/2e081a51b1effddb23f87952959139ac62654d50 15:47 < sunweaver> https://github.com/smarty-php/smarty/commit/c9dbe1d08c081912d02bd851d1d1b6388f6133d1 15:48 < sunweaver> and these four sit on top of this... 15:48 < sunweaver> https://github.com/smarty-php/smarty/commit/f7a53162058de410a35a9848e6d0795d7c252aaf 15:48 < sunweaver> and 10+ other commits. 15:48 < sunweaver> all tackling the same code passage. 15:49 < sunweaver> @all: can we reach consensus that latest upstream release would be best for jessie LTS and stretch (OT here). The pile of patches is so awful, I strongly advise getting latest smarty-lexer and latest smarty3 from unstable into stable with thorough testing of dependent application (gosa, FusionDirectory, slbackup-php, ...). Most of them are maintained by me and I have running setups for testing this (except 1 package in Debian IIRC). Comments? Feedbacks? Mike -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby mobile: +49 (1520) 1976 148 landline: +49 (4354) 8390 139 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de pgp010BQdgN01.pgp Description: Digitale PGP-Signatur
Bug#909053: RM: ubiquity-extension -- RoQA; RC-buggy/broken with current Firefox, unmaintained, dead upstream
Package: ftp.debian.org Severity: normal Please remove ubiquity-extension, it's broken with Firefox ESR60, dead upstream (last release in Feb 2016, https://addons.mozilla.org/de/firefox/addon/mozilla-labs-ubiquity/), hasn't been updated since 2014 and has no active uploaders (#856776). Cheers, Moritz
Bug#909001: [Pkg-mozext-maintainers] Bug#909001: enigmail: Enigmail get uninstalled while upgrading thunderbird (60.0-3~deb9u1)
Control: forcemerge 909000 909001 On Mon 2018-09-17 10:36:16 +0200, Pierre Dinh van wrote: > Today, all my users have trouble reading their encrypted emails, because > the last upgrade of thunderbird from security.debian.org on 16/09/2018 breaks > enigmail (and a lot of other things). > > apt show thunderbird > [...] > Breaks: [...] enigmail (<<2:2~), [...] > [...] > > Automatic Upgrade of my systems removed enigmail everywhere. > > An upgrade would be usefull. agreed, sorry for this breakage! please follow up at https://bugs.debian.org/909000, where this is being tracked. --dkg
Bug#909052: RFS: rhythmbox-plugin-alternative-toolbar/0.18.1-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "rhythmbox-plugin-alternative-toolbar" * Package name: rhythmbox-plugin-alternative-toolbar Version : 0.18.1-1 Upstream Author : David Mohammed fossfree...@ubuntu.com * URL : github.com/fossfreedom/alternative-toolbar * License : GPLv3 Section : misc It builds those binary packages: rhythmbox-plugin-alternative-toolbar - Enhanced play controls and interface for Rhythmbox To access further information about this package, please visit the following URL: https://mentors.debian.net/package/rhythmbox-plugin-alternative-toolbar Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/r/rhythmbox-plugin-alternative-toolbar/rhythmbox-plugin-alternative-toolbar_0.18.1-1.dsc Notes: I am the author of this plugin and maintainer of the package in both Debian and Ubuntu. The following checks have been made: lintian -i -I --pedantic on the built source. This is lintian free except for one pedantic - testsuite-autopkgtest-missing ; I don't consider it necessary to create a autopkgtest suite for this python plugin for rhythmbox check-all-the-things has been run on the source pbuilder-dist unstable build - this package was successfully built. If possible please can I be allowed to continue maintaining this in the future by DM upload privileges through auth via dak fossfree...@ubuntu.com ? N.B. my debian maintainer key is registered in the maintainership keyring Changes since the last upload: * Bug fix and Translation release - Use precise repeat one code rather than the previous estimate method - Fix laggy volume slider - Fix buggy click-to-seek - Use default GNOME Headerbar spacing * Packaging Changes: - control: Bump Standards-Version - rules updated for verbose build - control: Correct Vcs-Browser URL - copyright: Refresh to capture revised copyright holders - rules: Removed unnecessary --parallel Regards, David Mohammed
Bug#870641: light-locker: screen stays black after closing and opening laptop lid
I think I am experiencing the same issue as Thomas Maaß, though I am not convinced that it is the same behavior as the initial report. Namely, sometimes the display does not turn on when light-locker should be prompting for a password (I think I have seen this both when returning from hibernation and after a "normal" lock-screen event when the machine should still be running), though other times the display does turn on. Switching to a text terminal and returning causes the display to activate, whereupon things function as expected. I'll try to file a separate report tomorrow with reportbug unless informed otherwise. -Ben
Bug#909051: RM: stylish/2.0.3-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm xul-ext-stylish is broken with Firefox ESR 60, removal from unstable was requested in #906828, also remove it from stretch. Cheers, Moritz
Bug#896698: deprecating needs-recommends
On Sat, 15 Sep 2018 15:40:33 +0200, Michael Biebl wrote: > On Thu, 30 Aug 2018 12:03:31 +0200 Paul Gevers wrote: > > I have just pushed commit 9fade8dcb501250f704da9c77af1f8e6165dc941 that > > documents that we want to remove the needs-recommends option as we > > discussed in https://lists.debian.org/debian-ci/2018/06/msg00016.html. > So I have this specific case where I found needs-recommends quite > convenient: > I have a package (firewalld) which has optional dependencies like ipset > or ebtables. If those are not installed, firewalld will log a warning > and continue with the functionality disabled. We're also using needs-recommends for perl packages / in pkg-perl-autopkgtest. % autodep8 Test-Command: /usr/share/pkg-perl-autopkgtest/runner build-deps Depends: @, @builddeps@, pkg-perl-autopkgtest Test-Command: /usr/share/pkg-perl-autopkgtest/runner runtime-deps Depends: @, pkg-perl-autopkgtest Test-Command: /usr/share/pkg-perl-autopkgtest/runner runtime-deps-and-recommends Depends: @, pkg-perl-autopkgtest Restrictions: needs-recommends In practice, there's currently one test in the "runtime-deps-and-recommends" department: syntax.t which, among other things, does `perl -wc ' and is helpful to detect syntax errors in code which is not used during build tests. Cf. also https://perl-team.pages.debian.net/autopkgtest.html#syntax.t The reason we need the packages in Recommends is quite simple: there are often modules in packages which are no core functionality, hence their dependencies are not in Depends but in Recommends. Without needs-recommends we would - need to exclude them from syntax.t (the machinery exists but it's quite some work) - lose the ability to test them. So if needs-recommends vanishes, there will be at least dozens if not hundreds of perl packages which will immediately fail their autopkgtests. (josch's count of 154 affected packages in https://lists.debian.org/debian-ci/2018/06/msg00016.html fails to take all the autodep8 packages into account.) 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 VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- NP: R.E.M.: Losing My Religion signature.asc Description: Digital Signature
Bug#882666: "*.libretro" key/value files are missing
Still an issue with version "3.30.0-1" Looks like "*.libretro" key/value files are missing in the installation path "/usr/lib/x86_64-linux-gnu/libretro" When i add files like found here manually (e.g. nestopia.libretro) it starts to work: https://gitlab.gnome.org/GNOME/gnome-games/tree/master/flatpak/libretro-cores libretro-gtk depends on those files (see file: retro-module-iterator.c function:retro_module_iterator_iterate_next_in_current_path) Thanks, Patrick
Bug#907988: rubber must specify the encoding when opening files
On 09.09.2018 15:33, Adrian Bunk wrote: Hi Adrian, > I can confirm that it fixes the why3 build. > > Your solution is a bit ouch, but I understand why it is not easy to > fix in a better way. > Upstream decided to solve the problem a different way and has released version 1.5.1. New package is on [1], could you retest? Thanks! Hilmar [1] https://freeshell.de/~hille42/rubber/ -- sigfault #206401 http://counter.li.org
Bug#907243: [pkg-cryptsetup-devel] Bug#907243: cryptsetup-initramfs recursive resolution broken
Hi,
Am So, 09. Sep 2018 um 05:10:44 +0200 schrieb Guilhem Moulin:
Making _CRYPTTAB_{NAME,SOURCE,KEY,OPTIONS} local to
crypttab_find_and_print_entry() should also fix this, and that's what I
did in c355422:
https://salsa.debian.org/cryptsetup-team/cryptsetup/commit/c3554229394912bfbee03fadb8c56e9b4c175eb3
I had the same problem as the bug reporter with two lines of crypttab.
First one is an encrypted partition, second one is an encrypted and
decrypt_derived swap partition. I can confirm that this patch fixes the
problem for me.
Thanks,
Dirk
Bug#909050: keepass2: New Version 2.40
Package: keepass2 Version: 2.39.1+dfsg-1 Severity: normal Tags: upstream Dear Maintainer, there is a new version of keepass2 out since the 10th september 2018. Please package the new version. Thanks -- System Information: Debian Release: buster/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages keepass2 depends on: ii libgcrypt20 1.8.3-1 ii libmono-corlib4.5-cil4.6.2.7+dfsg-2 ii libmono-system-drawing4.0-cil4.6.2.7+dfsg-2 ii libmono-system-security4.0-cil 4.6.2.7+dfsg-2 ii libmono-system-windows-forms4.0-cil 4.6.2.7+dfsg-2 ii libmono-system-xml4.0-cil4.6.2.7+dfsg-2 ii libmono-system4.0-cil4.6.2.7+dfsg-2 ii libx11-6 2:1.6.6-1 ii mono-runtime 4.6.2.7+dfsg-2 Versions of packages keepass2 recommends: ii xsel 1.2.0+git9bfc13d.20180109-1 Versions of packages keepass2 suggests: pn keepass2-doc pn mono-dmcs ii xdotool 1:3.20160805.1-4 -- no debconf information
Bug#502611: po-debconf: podebconf-report-po should be able to use /usr/sbin/sendmail
On Wed, 26 Jan 2011 18:46:46 +0200 "Eugene V. Lyubimkin"
wrote:
> Hi,
>
> On 2011-01-26 15:54, Denis Barbier wrote:
> > Nicolas is right, AFAICT one can run
> >$ podebconf-report-po --postpone=/tmp/msg.out
> >$ formail -s /usr/sbin/sendmail -t < /tmp/msg.out
> >
> > Does this fit your needs?
>
> This probably works, but it's unconvenient, kind of hack, and hardly can
> be called '/usr/sbin/sendmail support'. I would still want it
> implemented in the code. Or least without temporary file so I can pipe
> the mail directly to sendmail.
I just stumbled upon this 10 years old wishlist item. Rather than just
bumping it I will add that the 'formail' line can be replaced with an
awk command like:
awk 'BEGIN {cmd = "/usr/sbin/sendmail -t"} /^From / {close(cmd);
getline}; {print $0 | cmd}' < /tmp/msg.out
thus installing procmail can be avoided. It is not really solid
('^From_' could be found in the message body), but probably good enough
for the specific purpose. It still remains a kludge, and I hope
podebconf-report-po will get a --sendmail[=/path/to/sendmail] option
someday.
Cheers,
Paride
Bug#909049: libdbus-1-dev : Depends: libdbus-1-3 (= 1.10.8-1+devuan1) but 1.10.18-1+devuan2.3 is to be installed
Package: libdbus-1-dev Version: 1.10.8-1+devuan1 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? attempting to apt-get install libgtk-3-dev * What exactly did you do (or not do) that was effective (or ineffective)? apt-get install libgtk-3-dev * What was the outcome of this action? nico@devuan-3xS:~/Projects/itadinanta/gfx-gtk$ sudo apt-get install libgtk-3-dev Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libgtk-3-dev : Depends: libatk-bridge2.0-dev but it is not going to be installed E: Unable to correct problems, you have held broken packages. nico@devuan-3xS:~/Projects/itadinanta/gfx-gtk$ sudo apt-get install libatk-bridge2.0-dev Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libatk-bridge2.0-dev : Depends: libatspi2.0-dev but it is not going to be installed E: Unable to correct problems, you have held broken packages. nico@devuan-3xS:~/Projects/itadinanta/gfx-gtk$ sudo apt-get install libatspi2.0-dev Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libatspi2.0-dev : Depends: libdbus-1-dev but it is not going to be installed * What outcome did you expect instead? libgtk-3-dev and all dependencies are installed *** End of the template - remove these template lines *** -- System Information: Distributor ID:Devuan Description:Devuan GNU/Linux unstable (ceres) Release:unstable Codename:ceres Architecture: x86_64 Kernel: Linux 4.18.0-1-amd64 (SMP w/16 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: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages libdbus-1-dev depends on: ii libdbus-1-3 1.10.18-1+devuan2.3 ii pkg-config 0.29-4+b1 libdbus-1-dev recommends no packages. libdbus-1-dev suggests no packages. -- Cheers, Nico
Bug#908865: exim4: Default CHECK_RCPT_REMOTE_LOCALPARTS blocks legal email addresses (in particular the % character)
Hi Marc, thanks for your quick reply. Am Montag, 17. September 2018, 13:01:11 CEST schrieb Marc Haber: > Hi, > > please feel free to do a local override of the macro. How to do this is > explained in the package docs. That is exactly what I attempted by adding # accept % in email addresses (local part, i.e. not domain) /etc/exim4/conf.d/main/00_localconfig I hope that is the way it is intended by the exim4 Debian developers. > Andreas might revise the default in the > package, if it were my decision, I wouldn't change this, even if in > these days where explicit SMTP routing is not even used any more by > spammers. Here I probably have not enough knowledge... >From what I understand from RFC2822 the % is a character like any other >character in the alphabet for the local-part https://tools.ietf.org/html/rfc2822#section-3.4.1 https://tools.ietf.org/html/rfc2822#section-3.2.4 Why is there any disadvantage to allow it? I particular, I do not understand the spam risk you mention and also Google did not help me :-/ ... Could you give me a pointer to more details? In particular do I carry a SPAM risk if I do the local modification to accept the % sign? > > Please also note that it is clearly documented that this rule blocks > addresses that are RFC-valid. There are people which advise the opposite https://archive.fosdem.org/2018/schedule/event/email_address_quiz/ but this is beyond my expertise to judge what are the implications there Thanks again for your quick response Rainer -- Rainer Dorsch http://bokomoko.de/
Bug#909048: glare: tests are run in dh_install
Package: src:glare Version: 0.5.0-4 Dear maintainer: While we are at it, I noticed that the debian/rules target which made the package to FTBFS is dh_install (or its override). I have not checked, but this is most probably a bug. I don't think it is possible to honor DEB_BUILD_OPTIONS=nocheck and having a debian/rules file which runs the tests in dh_install at the same time. Thanks.
Bug#909047: libc6.preinst: possible typo in 's/\bsamaba\b/smbd/g'
Package: libc6 Version: 2.27-6 Severity: normal libc6.preinst includes: -e's/\bsamaba\b/smbd/g' This looks like a typo to me. I assume it should be samba instead of samaba? Ansgar
Bug#909045: glare: FTBFS (failing tests)
Package: src:glare
Version: 0.5.0-4
Severity: serious
Tags: ftbfs
Dear maintainer:
I tried to build this package in buster but it failed:
[...]
debian/rules build-indep
pyversions: missing X(S)-Python-Version in control file, fall back to
debian/pyversions
pyversions: missing debian/pyversions file, fall back to supported versions
py3versions: no X-Python3-Version in control file, using supported versions
dh build-indep --buildsystem=python_distutils --with python3,sphinxdoc,systemd
dh_update_autotools_config -i -O--buildsystem=python_distutils
dh_autoreconf -i -O--buildsystem=python_distutils
dh_auto_configure -i -O--buildsystem=python_distutils
dh_auto_configure: Please use the third-party "pybuild" build system instead of
python-distutils
dh_auto_configure: This feature will be removed in compat 12.
debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
pyversions: missing X(S)-Python-Version in control file, fall back to
debian/pyversions
pyversions: missing debian/pyversions file, fall back to supported versions
[... snipped ...]
running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-160} \
${PYTHON:-python} -m subunit.run discover -t ./ ./glare/tests --list
running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-160} \
${PYTHON:-python} -m subunit.run discover -t ./ ./glare/tests --load-list
/tmp/tmp0k1f023j
==
FAIL: glare.tests.unit.test_wsgi.RequestTest.test_best_match_language_unknown
glare.tests.unit.test_wsgi.RequestTest.test_best_match_language_unknown
--
_StringException: Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/mock/mock.py", line 1297, in patched
arg = patching.__enter__()
File "/usr/lib/python3/dist-packages/mock/mock.py", line 1369, in __enter__
original, local = self.get_original()
File "/usr/lib/python3/dist-packages/mock/mock.py", line 1343, in get_original
"%s does not have the attribute %r" % (target, name)
AttributeError: does not have the
attribute 'best_match'
==
FAIL: glare.tests.unit.test_wsgi.ResourceTest.test_translate_exception
glare.tests.unit.test_wsgi.ResourceTest.test_translate_exception
--
_StringException: Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/mock/mock.py", line 1297, in patched
arg = patching.__enter__()
File "/usr/lib/python3/dist-packages/mock/mock.py", line 1369, in __enter__
original, local = self.get_original()
File "/usr/lib/python3/dist-packages/mock/mock.py", line 1343, in get_original
"%s does not have the attribute %r" % (target, name)
AttributeError: does not have the
attribute 'best_match'
--
Ran 250 tests in 20.664s
FAILED (failures=2, skipped=2)
make[1]: *** [debian/rules:31: override_dh_install] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:6: binary-indep] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary-indep subprocess
returned exit status 2
The build was made in my autobuilder with "dpkg-buildpackage -A" in buster,
but a similar error happens here in sid:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/glare.html
where you can get a full build log if you need it.
I would like to see the official build log, but there is none:
https://buildd.debian.org/status/package.php?p=glare
Please re-re-re-consider uploading in source only-form (dpkg-buildpackage -S)
so that these kind of bugs never propagate to testing.
Thanks.
Bug#909046: thunderbird: Missing react-dom.js on addon debugging page
Package: thunderbird Version: 1:60.0-3~deb9u1 Severity: normal Dear Maintainer, if I select "Debug Add-ons" in the drop down on the add-on page, a blank page opens. In the terminal I get the following output: JavaScript error: resource://devtools/client/shared/browser-loader.js, line 143: Error: Module `resource://devtools/client/shared/vendor/react-dom.js` is not found at resource://devtools/client/shared/vendor/react-dom.js -- System Information: Debian Release: 9.5 APT prefers stable APT policy: (800, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-7-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages thunderbird depends on: ii debianutils 4.8.1.1 ii fontconfig2.11.0-6.7+b1 ii libatk1.0-0 2.22.0-1 ii libc6 2.24-11+deb9u3 ii libcairo-gobject2 1.14.8-1 ii libcairo2 1.14.8-1 ii libdbus-1-3 1.10.26-0+deb9u1 ii libdbus-glib-1-2 0.108-2 ii libevent-2.0-52.0.21-stable-3 ii libffi6 3.2.1-6 ii libfontconfig12.11.0-6.7+b1 ii libfreetype6 2.6.3-3.2 ii libgcc1 1:6.3.0-18+deb9u1 ii libgdk-pixbuf2.0-02.36.5-2+deb9u2 ii libglib2.0-0 2.50.3-2 ii libgtk-3-03.22.11-1 ii libgtk2.0-0 2.24.31-2 ii libjsoncpp1 1.7.4-3 ii libpango-1.0-01.40.5-1 ii libpangocairo-1.0-0 1.40.5-1 ii libpangoft2-1.0-0 1.40.5-1 ii libstartup-notification0 0.12-4+b2 ii libstdc++66.3.0-18+deb9u1 ii libvpx4 1.6.1-3+deb9u1 ii libx11-6 2:1.6.4-3 ii libx11-xcb1 2:1.6.4-3 ii libxcb-shm0 1.12-1 ii libxcb1 1.12-1 ii libxext6 2:1.3.3-1+b2 ii libxrender1 1:0.9.10-1 ii libxt61:1.1.5-1 ii psmisc22.21-2.1+b2 ii x11-utils 7.7+3+b1 ii zlib1g1:1.2.8.dfsg-5 Versions of packages thunderbird recommends: ii hunspell-en-us [hunspell-dictionary] 20070829-7 pn lightning Versions of packages thunderbird suggests: pn apparmor ii fonts-lyx 2.2.2-1 ii libgssapi-krb5-2 1.15-1+deb9u1 -- no debconf information
Bug#909044: quota: Running quotacheck -cmug / fails with buster version but not with stretch version on lxc container
Package: quota Version: 4.04-2 Severity: grave Justification: renders package unusable Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Running debian buster on a LXC container with quotas enabled "quotacheck -cmug /" to enable the creation of aquota.user and aquota.group fails: lxc ~# quotacheck -cmug / quotacheck: error (1) while opening /dev/mapper/pve-vm--9002--disk--0 but installing stretch version works perfectly: root@test-lxc ~ # dpkg -i quota_4.03-2+deb9u1_amd64.deb dpkg: warning: downgrading quota from 4.04-2 to 4.03-2+deb9u1 (Reading database ... 45469 files and directories currently installed.) Preparing to unpack quota_4.03-2+deb9u1_amd64.deb ... Unpacking quota (4.03-2+deb9u1) over (4.04-2) ... Setting up quota (4.03-2+deb9u1) ... Processing triggers for systemd (239-9) ... Processing triggers for man-db (2.8.4-2) ... root@test-lxc ~ # quotacheck -cmug / root@test-lxc ~ # repquota -a *** Report for user quotas on device /dev/mapper/pve-vm--9002--disk--0 Block grace time: 7days; Inode grace time: 7days Block limitsFile limits Userusedsofthard graceused soft hard grace -- root -- 1198096 0 0 50733 0 0 man --1136 0 0140 0 0 _apt -- 12 0 0 3 0 0 postfix -- 60 0 0 44 0 0 I`ve been checking the diff between quota 4.03 and 4.04 but cannot find anything related to this. *** End of the template - remove these template lines *** -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.15.18-4-pve (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages quota depends on: ii debconf [debconf-2.0] 1.5.69 pn e2fslibs ii libc6 2.27-6 pn libcomerr2 ii libdbus-1-31.12.10-1 ii libldap-2.4-2 2.4.46+dfsg-5 ii libnl-3-2003.4.0-1 ii libnl-genl-3-200 3.4.0-1 ii libtirpc1 0.2.5-1.3 ii libwrap0 7.6.q-27 ii lsb-base 9.20170808 quota recommends no packages. Versions of packages quota suggests: pn libnet-ldap-perl ii postfix [mail-transport-agent] 3.3.0-1+b1 pn rpcbind -- debconf information: quota/run_warnquota: false quota/message: quota/signature: quota/mailfrom: quota/charset: quota/rquota_setquota: quota/cc_before: quota/supportphone: quota/group_signature: quota/subject: quota/group_message: quota/cc: quota/supportemail:
Bug#908818: [Pkg-zsh-devel] Bug#908818: Reopen: #908818: Zsh: [7] + 23074 suspended (tty output)
Control: tags -1 fixed-upstream TS wrote on Mon, 17 Sep 2018 21:54 +0200: > Just to be sure i again tried stock debian zsh 5.6.2 which still fails for me. > The version you uploaded fixes it for me. Thanks for testing both versions! Daniel
Bug#909043: golang-github-hashicorp-go-retryablehttp breaks golang-github-circonus-labs-circonus-gometrics autopkgtest
Source: golang-github-hashicorp-go-retryablehttp, golang-github-circonus-labs-circonus-gometrics Control: found -1 golang-github-hashicorp-go-retryablehttp/0.0+git20180718.e651d75-1 Control: found -1 golang-github-circonus-labs-circonus-gometrics/1.2.0-1 X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: breaks needs-update Dear maintainers, With a recent upload of golang-github-hashicorp-go-retryablehttp the autopkgtest of golang-github-circonus-labs-circonus-gometrics fails in testing when that autopkgtest is run with the binary packages of golang-github-hashicorp-go-retryablehttp from unstable. It passes when run with only packages from testing. I copied some of the output at the bottom of this report. Currently this regression is contributing to the delay of the migration of golang-github-hashicorp-go-retryablehttp to testing [1]. Due to the nature of this issue, I filed this bug report against both packages. Can you please investigate the situation and reassign the bug to the right package? If needed, please change the bug's severity. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=golang-github-hashicorp-go-retryablehttp https://ci.debian.net/data/autopkgtest/testing/amd64/g/golang-github-circonus-labs-circonus-gometrics/1002797/log.gz autopkgtest [04:38:44]: test command1: /usr/bin/dh_golang_autopkgtest autopkgtest [04:38:44]: test command1: [--- [info] Testing github.com/circonus-labs/circonus-gometrics... [info] Source code installed by binary package, overriding dh_auto_configure... dh build --buildsystem=golang --with=golang dh_update_autotools_config -O--buildsystem=golang dh_autoreconf -O--buildsystem=golang debian/rules override_dh_auto_configure make[1]: Entering directory '/tmp/autopkgtest-lxc.zwmm6eep/downtmp/autopkgtest_tmp' mkdir -p "obj-x86_64-linux-gnu" cp -a /usr/share/gocode/src "obj-x86_64-linux-gnu" make[1]: Leaving directory '/tmp/autopkgtest-lxc.zwmm6eep/downtmp/autopkgtest_tmp' dh_auto_build -O--buildsystem=golang cd obj-x86_64-linux-gnu && go install -gcflags=\"-trimpath=/tmp/autopkgtest-lxc.zwmm6eep/downtmp/autopkgtest_tmp/obj-x86_64-linux-gnu/src\" -asmflags=\"-trimpath=/tmp/autopkgtest-lxc.zwmm6eep/downtmp/autopkgtest_tmp/obj-x86_64-linux-gnu/src\" -v -p 2 github.com/circonus-labs/circonus-gometrics github.com/circonus-labs/circonus-gometrics/api github.com/circonus-labs/circonus-gometrics/api/config github.com/circonus-labs/circonus-gometrics/checkmgr github.com/circonus-labs/circonus-gometrics/api/config github.com/circonus-labs/circonusllhist github.com/hashicorp/go-cleanhttp github.com/hashicorp/go-retryablehttp github.com/circonus-labs/circonus-gometrics/api # github.com/circonus-labs/circonus-gometrics/api src/github.com/circonus-labs/circonus-gometrics/api/api.go:376:20: cannot use retryPolicy (type func(*http.Response, error) (bool, error)) as type retryablehttp.CheckRetry in assignment dh_auto_build: cd obj-x86_64-linux-gnu && go install -gcflags=\"-trimpath=/tmp/autopkgtest-lxc.zwmm6eep/downtmp/autopkgtest_tmp/obj-x86_64-linux-gnu/src\" -asmflags=\"-trimpath=/tmp/autopkgtest-lxc.zwmm6eep/downtmp/autopkgtest_tmp/obj-x86_64-linux-gnu/src\" -v -p 2 github.com/circonus-labs/circonus-gometrics github.com/circonus-labs/circonus-gometrics/api github.com/circonus-labs/circonus-gometrics/api/config github.com/circonus-labs/circonus-gometrics/checkmgr returned exit code 2 make: *** [debian/rules:4: build] Error 2 autopkgtest [04:38:46]: test command1: ---] signature.asc Description: OpenPGP digital signature
Bug#902760: Two failed tests remaining in igraph which are arpack related
Hi Andreas & Adrian, This is the ARPACK patch that needs to be applied in order to fix the failing test cases in igraph: https://github.com/opencollab/arpack-ng/commit/31854cadaff067e30b8715f10533c459a9b7d447 As far as I know, there was no official ARPACK release with the patch above yet so it has to be applied manually. All the best, Tamas On Mon, 17 Sep 2018 at 21:44, Andreas Tille wrote: > > Control: tags -1 help > > Hi Adrian, > > I realised that you have set > >908648: libarpack2 needs fix applied for igraph > > fixed. So I tried to build igraph from Git[1] with latest arpack but > there are two remaining issues in the build time test which both are > connected to arpack: > > ... > 196: Eigenvector centrality (igraph_eigenvector_centrality): FAILED > (arpack.at:59) > 197: Non-symmetric ARPACK solver (igraph_arpack_rnsolve): FAILED > (arpack.at:66) > ... > ## - ## > ## Test results. ## > ## - ## > > ERROR: 219 tests were run, > 2 failed unexpectedly. > 13 tests were skipped. > ## -- ## > ## testsuite.log was created. ## > ## -- ## > > Please send `tests/testsuite.log' and all information you think might help: > >To: >Subject: [igraph 0.7.1] testsuite: 196 197 failed > > You may investigate any problem if you feel able to do so, in which > case the test suite provides a good starting point. Its output may > be found below `tests/testsuite.dir'. > > > I admit I have no idea about igraph - just picked it up since the former > Uploader just left the team. > > Any hint is welcome > > Andreas. > > > [1] https://salsa.debian.org/med-team/igraph > > -- > http://fam-tille.de
Bug#909014: [pkg-gnupg-maint] Bug#909014: pinentry-efl binary package build request
Control: tags 909014 + moreinfo On Mon 2018-09-17 15:21:06 +0300, sergio wrote: > Please make a new binary packages with --enable-pinentry-efl for > enlightenment. thanks for your suggestion! I'd put off doing this because i hadn't heard from any debian users that this was desirable. do you think that pinentry-efl should talk to libsecret (the way that pinentry-gnome3 and pinentry-gtk2 do), or do you think it should be independent of libsecret? > https://github.com/gpg/pinentry/commit/948105b7a34ec9a9e5479d376b7c86bafee50a01 this isn't a standard GnuPG git reference -- please use https://dev.gnupg.org/ links for upstream pointers! --dkg signature.asc Description: PGP signature
Bug#908818: [Pkg-zsh-devel] Bug#908818: Reopen: #908818: Zsh: [7] + 23074 suspended (tty output)
Daniel Shahaf schrieb/wrote: -- -- > For the time being I did a quick build with that commit backported and > uploaded it to https://home.apache.org/~danielsh/zsh/debian/ . Hello, Just to be sure i again tried stock debian zsh 5.6.2 which still fails for me. The version you uploaded fixes it for me. Thanks! kind regards, Thilo
Bug#909000: Enigmail 2.0 needed in Stretch after Thunderbird 60 upload
On Mon 2018-09-17 10:14:31 +0200, Jonas Meurer wrote: > yesterday, Thunderbird 1:60.0-2~deb9u1 got uploaded to Stretch (via > security). This thunderbird version breaks enigmail (<< 2:2~), which > leads to uninstallable/unusable Enigmail in Debian Stretch. > > May I suggest to backport Enigmail 2.0 to Debian Stretch as well? Thanks for this report, Jonas! it's definitely correct. It's important to fix, but the dependency on more recent versions of GnuPG will be needed as well. There are several problems that i'm trying to work through for enigmail in the limited time that i've got for this. Some background: * enigmail imported a copy of OpenPGP.js wholesale in version 2.0.x * unfortuantely, the version they imported isn't the actual preferred form of modification -- it's an assembled/"compiled" form of the project, using node. * I asked enigmail upstream whether he had ever built OpenPGP.js from source, and he had not -- he simply copied their distributed bundle. * the DFSG-free way to get that into debian is to get OpenPGP.js into debian -- see https://bugs.debian.org/787774 for that ITP. * i tried off and on for weeks to figure out how to make that happen cleanly, but eventually gave up because of the explosion of node packaging that would have been required. even if i'd been able to follow the dependency tree to its ends (which was problematic for lots of reasons), i don't think i can responsibly maintain all those node packages :( * instead, i realized that the OpenPGP.js node package was only needed by enigmail for a few things, in particular to avoid needing a newer version of GnuPG. * there were a few small changes that needed to be made to GnuPG to make enigmail pass its test suites properly without OpenPGP.js, so i got them made upstream in GnuPG. * then i stripped OpenPGP.js from enigmail, and bumped enigmail's dependency on GnuPG. * new versions of thunderbird apparently change the behavior of some of the enigmail tests -- see #907984 and #906885 * i subsequently discovered that the enigmail test suite was inadequate for the Autocrypt Setup Message -- i'm currently working on fixing that. (this is #908510) If i can get that fixed, then i can look into porting the improvements to GnuPG needed by enigmail's test suite into the stable version of GnuPG. Sadly, i'm pretty behind on this, but i would welcome help. --dkg signature.asc Description: PGP signature
Bug#902760: Two failed tests remaining in igraph which are arpack related
Control: tags -1 help Hi Adrian, I realised that you have set 908648: libarpack2 needs fix applied for igraph fixed. So I tried to build igraph from Git[1] with latest arpack but there are two remaining issues in the build time test which both are connected to arpack: ... 196: Eigenvector centrality (igraph_eigenvector_centrality): FAILED (arpack.at:59) 197: Non-symmetric ARPACK solver (igraph_arpack_rnsolve): FAILED (arpack.at:66) ... ## - ## ## Test results. ## ## - ## ERROR: 219 tests were run, 2 failed unexpectedly. 13 tests were skipped. ## -- ## ## testsuite.log was created. ## ## -- ## Please send `tests/testsuite.log' and all information you think might help: To: Subject: [igraph 0.7.1] testsuite: 196 197 failed You may investigate any problem if you feel able to do so, in which case the test suite provides a good starting point. Its output may be found below `tests/testsuite.dir'. I admit I have no idea about igraph - just picked it up since the former Uploader just left the team. Any hint is welcome Andreas. [1] https://salsa.debian.org/med-team/igraph -- http://fam-tille.de
Bug#909027: Leaves daemons running after purge
On Mon, Sep 17, 2018 at 12:47 PM Steve McIntyre wrote: > On Mon, Sep 17, 2018 at 05:23:53PM +0100, Steve McIntyre wrote: > >Package: gvfsd-metadata > >Version: 1.30.4-1 > >Severity: serious > > > >Hi folks, > > > >I appear to have had some of the gvfs packages installed by accident > >on my machine, I guess through dependencies. I noticed this a few days > >ago and purged them all. I saw no errors when I did that. I noticed > >again today that I still have gvfs programs running. This is clearly > >not right. To verify, I've just reinstalled gvfs-daemons and purged it > >again. I still have things running: Steve, thank you for filing this bug. However, it doesn't look release-critical to me since I don't think Debian Policy says anywhere that daemons or services must be stopped on package removal. For instance, Firefox or any app keeps running after you remove it. Many GNOME apps now are D-Bus-activated and keep running in the background even though they may not appear to be running unless someone looks closely. The gvfs daemon are system user services. These services keep running after removal; another example is gpg-agent. All you need to do is log out for the services to be stopped. Maybe, this ends up being a duplicate of https://bugs.debian.org/764678 or maybe it needs a new bug not in gvfs. Or maybe we don't even need to change the behavior here. But we have others on the Debian GNOME team that know a lot more about dbus and systemd than I do. Thanks, Jeremy Bicha
Bug#908938: [alsa-devel] Bug#908938: alsa-utils: amixer does not unmute pulseaudio
Control: reassign -1 pulseaudio Control: severity -1 minor Clemens Ladisch writes: > In theory, alsamixer and amixer should be able to access the same controls in > the same way. > > Please show the output of "amixer scontrols". > What is the output of the "toggle"/"unmute" commands without "-q"? --8<---cut here---start->8--- $ amixer -c 0 sset Master toggle Simple mixer control 'Master',0 Capabilities: pvolume pvolume-joined pswitch pswitch-joined Playback channels: Mono Limits: Playback 0 - 127 Mono: Playback 85 [67%] [-31.50dB] [off] $ amixer -c 0 sset Master toggle Simple mixer control 'Master',0 Capabilities: pvolume pvolume-joined pswitch pswitch-joined Playback channels: Mono Limits: Playback 0 - 127 Mono: Playback 85 [67%] [-31.50dB] [on] $ amixer -c 0 scontrols Simple mixer control 'Master',0 Simple mixer control 'Headphone',0 Simple mixer control 'Speaker+LO',0 Simple mixer control 'PCM',0 Simple mixer control 'IEC958',0 Simple mixer control 'IEC958',1 Simple mixer control 'IEC958',2 Simple mixer control 'Beep',0 Simple mixer control 'Capture',0 Simple mixer control 'Auto-Mute Mode',0 Simple mixer control 'Digital',0 Simple mixer control 'Dock Mic',0 Simple mixer control 'Dock Mic Boost',0 Simple mixer control 'Headset Mic',0 Simple mixer control 'Headset Mic Boost',0 Simple mixer control 'Internal Mic Boost',0 Simple mixer control 'Loopback Mixing',0 --8<---cut here---end--->8--- OK, -c0 means amixer is accessing the hardware instead of PulseAudio. (Somehow I have assumed PA is selectable via -c, my mistake.) Without -c the output is simpler. --8<---cut here---start->8--- $ amixer scontrols Simple mixer control 'Master',0 Simple mixer control 'Capture',0 --8<---cut here---end--->8--- This is PulseAudio. Indeed, when I run alsamixer -c0 and see the hardware (previously I wasn't specifing -c0), the Master is unmuted properly. However, Speker+LO (which is muted by the first toggle) is not unmuted. I believe, this is a problem with PulseAudio rather than with ALSA. Unmuting both Master and Speaker+LO hardware channels makes PA unmute master. amixer without -c mutes and unmutes PA as expected. Thank you for helping to figure all this stuff out. -- Było mi bardzo miło. --- Rurku. --- ... >Łukasz<--- To dobrze, że mnie słuchasz. signature.asc Description: PGP signature
Bug#851309: meanwhile
a building package exists at: http://sid.ethz.ch/debian/rtl-433/
Bug#875086: Fixed since 5.4.1+dfsg4-1
Control: reopen -1 On Mon, Sep 17, 2018 at 10:16:19PM +0300, Juhani Numminen wrote: > Hi, Hi Juhani, > On Mon, 17 Sep 2018 20:07:23 +0300 Adrian Bunk wrote: > > Version: 5.4.1+dfsg4-1 > > > > paraview (5.4.1+dfsg4-1) unstable; urgency=medium > > ... > > * [145a06f] d/rules: Switch to qt5 > > * [a7aaa49] d/control: Switch to qt5 > > ... > > -- Gert Wollny Thu, 15 Mar 2018 19:02:28 +0100 > > Did you notice https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=875086#21 > where I say "I'm reopening because paraview-dev still depends on > qt4-dev-tools." > Please have a look at debian/control of paraview. :) >... No, I missed that. Reopening again. > Juhani Sorry for that Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#909042: firefox-esr: firefox showing libgl errors when in session
Package: firefox-esr Version: 60.2.0esr-1 Severity: normal Dear Maintainer, Thank you for maintaining firefox and more specifically firefox-esr. I updated the newest version and saw the following statements looped in firefox-esr - ~$ firefox libGL error: MESA-LOADER: failed to retrieve device information libGL error: Version 4 or later of flush extension not found libGL error: failed to load driver: i915 I looked at various bug-reports of libGL error and all seemed to point at either chromium or/and raspberry pi. I have Intel Graphics 630 as my integrated graphics card - $ sudo lshw -class display *-display description: VGA compatible controller product: HD Graphics 630 vendor: Intel Corporation physical id: 2 bus info: pci@:00:02.0 version: 04 width: 64 bits clock: 33MHz capabilities: pciexpress msi pm vga_controller bus_master cap_list rom configuration: driver=i915 latency=0 Look forward to know what could have caused it. -- Package-specific info: -- Addons package information -- System Information: Debian Release: buster/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (100, 'unstable-debug'), (100, 'experimental-debug'), (100, 'experimental'), (100, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages firefox-esr depends on: ii debianutils 4.8.6 ii fontconfig2.13.0-5 ii libatk1.0-0 2.28.1-1 ii libc6 2.27-6 ii libcairo-gobject2 1.15.12-1 ii libcairo2 1.15.12-1 ii libdbus-1-3 1.12.10-1 ii libdbus-glib-1-2 0.110-3 ii libevent-2.1-62.1.8-stable-4 ii libffi6 3.2.1-8 ii libfontconfig12.13.0-5 ii libfreetype6 2.8.1-2 ii libgcc1 1:8.2.0-6 ii libgdk-pixbuf2.0-02.36.12-2 ii libglib2.0-0 2.56.1-2 ii libgtk-3-03.22.30-2 ii libhunspell-1.6-0 1.6.2-1+b1 ii libjsoncpp1 1.7.4-3 ii libnspr4 2:4.20-1 ii libnss3 2:3.39-1 ii libpango-1.0-01.42.4-1 ii libsqlite3-0 3.24.0-1 ii libstartup-notification0 0.12-5 ii libstdc++68.2.0-6 ii libvpx5 1.7.0-3 ii libx11-6 2:1.6.6-1 ii libx11-xcb1 2:1.6.6-1 ii libxcb-shm0 1.13-3 ii libxcb1 1.13-3 ii libxcomposite11:0.4.4-2 ii libxdamage1 1:1.1.4-3 ii libxext6 2:1.3.3-1+b2 ii libxfixes31:5.0.3-1 ii libxrender1 1:0.9.10-1 ii libxt61:1.1.5-1 ii procps2:3.3.15-2 ii zlib1g1:1.2.11.dfsg-1 Versions of packages firefox-esr recommends: ii libavcodec58 7:4.0.2-1+b1 Versions of packages firefox-esr suggests: ii fonts-lmodern 2.004.5-5 ii fonts-stix [otf-stix] 1.1.1-4 ii libcanberra0 0.30-6 ii libgssapi-krb5-2 1.16-2 ii libgtk2.0-02.24.32-3 -- no debconf information -- Regards, Shirish Agarwal शिरीष अग्रवाल My quotes in this email licensed under CC 3.0 http://creativecommons.org/licenses/by-nc/3.0/ http://flossexperiences.wordpress.com EB80 462B 08E1 A0DE A73A 2C2F 9F3D C7A4 E1C4 D2D8
