Bug#819291: pitivi: 0.95-1+b1 segfaults against gtk+3.0 3.20
On Di, 2016-03-29 at 12:28 -0700, Marc J. Driftmeyer wrote: > Downloaded the latest executable from Pitivi, pitivi-0.95-x86_64- > 2016-03-26_0816, and it loads just fine. I meant the latest version of things in unstable :) Completely different binaries that ship their own versions of most of the dependencies are not a good comparison. Can you please get a backtrace of the crash? signature.asc Description: This is a digitally signed message part
Bug#794647: fixed in net-snmp 5.7.3+dfsg-1.1
Hi, I got an error when trying to install the lateset snmpd package, the "Debian-snmp" username fail the default adduser NAME_REGEX: Installing new version of config file /etc/default/snmpd ... adduser: Please enter a username matching the regular expression configured via the NAME_REGEX configuration variable. Use the `--force-badname' option to relax this check or reconfigure NAME_REGEX. dpkg: error processing package snmpd (--configure): subprocess installed post-installation script returned error exit status 1 As a side note i would like to add that this user change (snmp => Debian-snmp) isn't going to be welcome by users of automation systems like chef or puppet ... As for the need of doing this, the _S_ea_n_ _M_a_p_ rule seems a bit convoluted, and are there really admins who won't spot early on the snmp conflict ??
Bug#819498: [Resolvconf-devel] Bug#819498: /etc/resolvconf/update.d/resolvconf-update-bind called without CAP_CHOWN from n-m
Hi and thanks for the bug report. I am happy to remove the chown from the (example) script. But are you sure that bind processes the file if the owner is not root:bind? -- Thomas
Bug#784003: workaround
I confirm the bug on Jessie. I just commented both lines with has_separator property, and it seems ok. -- Theory is where you know everything, but nothing works; practice is where everything works, but nobody knows why. Here we combine theory with practice; nothing works and nobody knows why ! A.Einstein
Bug#819532: ITP: libgzstream -- provide functionality of zlib C-library in a C++ iostream
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: libgzstream Version : 1.5 Upstream Author : Deepak Bandyopadhyay, Lutz Kettner * URL : http://www.cs.unc.edu/Research/compgeom/gzstream/ * License : LGPL Programming Lang: C++ Description : provide functionality of zlib C-library in a C++ iostream Gzstream is a small C++ library, basically just a wrapper, that provides the functionality of the zlib C-library in a C++ iostream. Remark: This very small lib is embedded in several packages as code copy[1]. While this package is by no means in the field of Debian Med interest I think it is a good idea to do things right and since I need it for a Debian Med package I simply maintain it for the moment here: https://anonscm.debian.org/git/debian-med/libgzstream.git ACLs are set so any DD can commit here. Moving the package to some more fitting VCS / team is fine. [1] https://lists.debian.org/debian-mentors/2016/03/msg00550.html
Bug#793818: Pcmanfm crash sometimes at the end of file(s) copy
Hello, I just see that pcmanfm is now in version 1.2.4-1. I have upgrated it. # aptitude remove pcmanfm # aptitude install -t stretch pcmanfm Thank you again. Cédric.
Bug#819533: maim: please make the description clearer
Package: maim Version: 3.3.41-1 Severity: wishlist Dear Maintainer, Thanks for packaging maim! The synopsis has a typo, "screenshts". But I'm mainly filing a bug for the extended description, which left me rather non-plussed; here's what I'd like to find out without having to look at maim's web site: * is it command-line or GUI driven? * what's slop? is it packaged in Debian? * in what way is maim better than scrot? In fact scrot's extended description is a nice example to follow ;-). Regards, Stephen -- System Information: Debian Release: stretch/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing'), (500, 'stable'), (200, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.3.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#819534: libreoffice: LibreOffice fails to start
Package: libreoffice Version: 1:5.1.2~rc1-1 Severity: important Dear Maintainer, LibreOffice fails on running. Following dialog box appears (RU locale is used): -- Невозможно запустить приложение. [context="shared"] caught unexpected com.sun.star.deployment.DeploymentException: Extension Manager: failed to read data entry in backend db: file:///home/sf/.config/libreoffice/4/user/extensions/shared/registry/com.sun.star.comp.deployment.help.PackageRegistryBackend/backenddb.xml -- GDB trace is attached. -- System Information: Debian Release: 8.3 APT prefers stable APT policy: (990, 'stable'), (500, 'testing-updates'), (500, 'stable-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.4.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libreoffice depends on: ii fonts-dejavu 2.34-1 ii fonts-sil-gentium-basic1.1-7 ii libreoffice-avmedia-backend-gstreamer 1:5.1.2~rc1-1 ii libreoffice-base 1:5.1.2~rc1-1 ii libreoffice-calc 1:5.1.2~rc1-1 ii libreoffice-core 1:5.1.2~rc1-1 ii libreoffice-draw 1:5.1.2~rc1-1 ii libreoffice-impress1:5.1.2~rc1-1 ii libreoffice-java-common1:5.1.2~rc1-1 ii libreoffice-math 1:5.1.2~rc1-1 ii libreoffice-report-builder-bin 1:5.1.2~rc1-1 ii libreoffice-writer 1:5.1.2~rc1-1 ii python3-uno1:5.1.2~rc1-1 Versions of packages libreoffice recommends: ii fonts-liberation 1.07.4-1 ii libpaper-utils1.1.24+nmu4 Versions of packages libreoffice suggests: pn cups-bsd pn default-jre | openjdk-8-jre | openjdk-7-jre | open pn gstreamer1.0-libav pn gstreamer1.0-plugins-bad ii gstreamer1.0-plugins-base 1.4.4-2 ii gstreamer1.0-plugins-good 1.4.4-2 pn gstreamer1.0-plugins-ugly ii hunspell-en-us [hunspell-dictionary]20070829-6 ii hunspell-ru [hunspell-dictionary] 20120501-1 ii hyphen-en-us [hyphen-hyphenation-patterns] 2.8.8-2 ii hyphen-ru [hyphen-hyphenation-patterns] 20030310-1 ii iceweasel 38.7.1esr-1~deb8u1 pn imagemagick | graphicsmagick-imagemagick-compat ii libgl1-mesa-glx [libgl1]10.3.2-1+deb8u1 pn libreoffice-gnome | libreoffice-kde ii libreoffice-help-ru [libreoffice-help-5.1] 1:5.1.2~rc1-1 ii libreoffice-l10n-ru [libreoffice-l10n-5.1] 1:5.1.2~rc1-1 ii libreoffice-lightproof-en [libreoffice-grammarchec 0.4.3+1.5+git20140515-2 ii libreoffice-lightproof-ru-ru [libreoffice-grammarc 0.3.2+1.5+git20140515-2 pn libreoffice-officebean ii libsane 1.0.24-8 ii libxrender1 1:0.9.8-1+b1 pn myspell-dictionary ii mythes-en-us [mythes-thesaurus] 1:5.1.1-1 ii mythes-ru [mythes-thesaurus]1:5.1.1-1 pn openclipart2-libreoffice | openclipart-libreoffice ii pstoedit3.62-2+b1 pn unixodbc Versions of packages libreoffice-core depends on: ii fontconfig2.11.0-6.3 ii fonts-opensymbol 2:102.6+LibO4.3.3-2+deb8u3 ii libboost-date-time1.58.0 1.58.0+dfsg-5+b1 ii libc6 2.19-18+deb8u3 ii libcairo2 1.14.0-2.1 ii libclucene-contribs1v52.3.3.4-4.1 ii libclucene-core1v52.3.3.4-4.1 ii libcmis-0.5-5v5 0.5.1-2 ii libcups2 1.7.5-11+deb8u1 ii libcurl3-gnutls 7.38.0-4+deb8u3 ii libdbus-1-3 1.10.8-1 ii libdbus-glib-1-2 0.102-1 ii libdconf1 0.22.0-1 ii libeot0 0.01-3 ii libexpat1 2.1.0-6+deb8u1 ii libexttextcat-2.0-0 3.4.4-1 ii libfontconfig12.11.0-6.3 ii libfreetype6 2.5.2-3+deb8u1 ii libgcc1 1:5.3.1-13 ii libgl1-mesa-glx [libgl1] 10.3.2-1+deb8u1 ii libglew1.13 1.13.0-2 ii libglib2.0-0 2.48.0-1 ii libgltf-0.0-0v5 0.0.2-4+b1 ii libglu1-mesa [libglu1]9.0.0-2 ii libgraphite2-31.3.6-1~deb8u1 ii libharfbuzz-icu0 0.9.35-2 ii libharfbuzz0b 0.9.35-2 ii libhunspell-1.3-0 1.3.3-3 ii libhyphen02.8.8-1 ii libice6 2:1.0.9-1+b1 ii libicu55 55.1-7 ii libjpeg62-turbo 1:1
Bug#808183: icedove: FTPFS on hurd-i386 and enable successive builds
On Thu, 2015-12-24 at 22:24 -0500, Christoph Goehre wrote: > Hi Svante, > > On Mi, Dez 16, 2015 at 10:33:07 +0100, Svante Signell wrote: > > > > Currently icedove FTBFS on GNU/Hurd due to memory problems when linking > > large > > libraries. The attached patch fixes this problem by giving the --no-keep- > > memory > > flag to the linker as for alpha and ia64. > I use 'ifneq' instead of 'ifeq', so everything EXCEPT alpha and ia64 build > with > 'LDFLAGS += -Wl,--no-keep-memory'. If I apply your patch, hurd wouldn't get > -Wl,--no-keep-memory. Noted! But the rules: ifneq ($(DEB_BUILD_ARCH),ia64) LDFLAGS += -Wl,--no-keep-memory -Wl,--reduce-memory-overheads endif ifneq ($(DEB_BUILD_ARCH),alpha) LDFLAGS += -Wl,--no-keep-memory endif would set LDFLAGS --no-keep-memory twice and --reduce-memory-overheads once for all architectures not matching ia64,alpha, right? > > > > Additionally, since dh_clean does not enable building a second time after a > > build failure, add an override target for sh_auto_clean: > > override_dh_auto_clean: > > make -f client.mk distclean > Have you try to add this to debian/rules and build icedove from scratch? > For me, it's not working, see: > It does not work for me either. However the debian/rules is not OK, see below: dpkg-buildpackage: host architecture hurd-i386 fakeroot debian/rules clean dh clean dh_testdir dh_auto_clean dh_clean debian/rules build make: 'build' is up to date. <- This i not correct, the build hasn't even started fakeroot debian/rules binary <- Never build a package under fakeroot, this is not necessary and can can cause serious problems. I've seen this for other packages too, it is probably a bug in the dh_* tools. dh binary dh_testdir dh_update_autotools_config debian/rules override_dh_auto_configure ... Additionally: debian/rules binary does not restart the build from scratch after a failure. All built files e.g. under obj-icedove and obj- are still present, i.e. not cleaned out!
Bug#819534: libreoffice: LibreOffice fails to start
tag 819534 + moreinfo thanks Hi, On Wed, Mar 30, 2016 at 11:15:59AM +0300, Stanislav Fyodorov wrote: > Невозможно запустить приложение. which says what? > [context="shared"] caught unexpected > com.sun.star.deployment.DeploymentException: Extension Manager: failed > to read data entry in backend db: > file:///home/sf/.config/libreoffice/4/user/extensions/shared/registry/com.sun.star.comp.deployment.help.PackageRegistryBackend/backenddb.xml > -- So your profile is corrupted and/or you installed a broken extension and/or a extension install broke it. What did you do last before getting this? > GDB trace is attached. Which doesn't say anything. > -- System Information: > Debian Release: 8.3 > APT prefers stable > APT policy: (990, 'stable'), (500, 'testing-updates'), (500, > 'stable-updates'), (500, 'testing') > Architecture: amd64 (x86_64) Why on earth do people think mixing stable and testing ever is a good idea? There's uptodate versions in jessie-backports for that. Regards, Rene
Bug#819531: Invalid user name 'Debian-snmp' for adduser
Control: severity -1 serious (I don't think this deserves to be grave TBH.) Hi! On Wed, 2016-03-30 at 14:38:27 +0900, ISHIKAWA Mutsumi wrote: > Package: snmpd > Version: 5.7.3+dfsg-1.1 > Severity: grave > Setting up snmpd (5.7.3+dfsg-1.1) ... > adduser: Please enter a username matching the regular expression configured > via the NAME_REGEX configuration variable. Use the `--force-badname' > option to relax this check or reconfigure NAME_REGEX. > dpkg: error processing package snmpd (--configure): > subprocess installed post-installation script returned error exit status 1 > Errors were encountered while processing: > snmpd > > "Debian-snmp" is invalid for adduser. Because the change did not take place in the system, and as such there will be no need to revert it (from the passwd databases and similar), I'd ask request that the other nicer convention with a leading underscore, which is shorter and causes less problems on tools displaying file attributes, also "invalid" by default so namespace safe, is distro agnostic, and has precedent on other systems such as some of the BSDs. Thanks, Guillem
Bug#819491: transition: libfm-qt
Control: tags -1 confirmed On 29/03/16 15:38, ChangZhuo Chen (陳昌倬) wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > Hi release team, > > libfm-qt bumps its so version from 2 to 3, so we need to do the > transition for it. The affected packages are listed in [0], and the > following actions are needed: > > * lximage-qt needs binNMU. > * pcmanfm-qt has new version in experimental which supports new > libfm-qt. > > [0] https://release.debian.org/transitions/html/auto-libfm-qt.html Go ahead. Cheers, Emilio
Bug#819535: Nouveau Driver Issue - FCODE ROM Bug Report
Package: src:linux Version: 3.18-1~exp1 User: debian-powe...@lists.debian.org Usertags: ppc64 Hi, Regarding the issue with the nouveau drivers in vanilla kernels > 3.18.16 not being able to read the BIOS / DCB block out of the OpenFirmware nVidia GPU FCODE ROM. It seems that there has been some progress on this regression which affected powermac's with nvidia gpu's. A patch has been created and i have applied it to vanilla 4.3.0-rc4 kernel and it seems to fix this particular issue on my config (g5 quad with quadro fx4500). Please note for me the patch didnt apply cleanly, it needed some patching by hand for hunks that were rejected for shadowof.c. Please note that the fix hasn't hit mainline yet. Link to original bug report: https://bugs.freedesktop.org/show_bug.cgi?id=91319 link to patch: http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=5b5cc342d3154120f9bb5ca7839ab556e728c786 If interested, please look at the bug report for more info. Cheers, Peter
Bug#759886: [patch #8925] Support --clamp-mtime for binary reproducibility]
Hi! On Tue, 2016-03-29 at 21:03:38 -0400, Holger Levsen wrote: > FYI, GNU tar's upstream has accepted our patch! :-) Yes, I was notified on IRC, and also saw your private mail. :) In any case there's not been a release yet AFAIK. Given that upstream said that would happen in 7-10 days, I'll wait before commiting any change, so that dpkg depends on released features that other downstreams can use. And in any case there's still few things I want to wrap up before the next dpkg release so that should give enough time. Thanks, Guillem
Bug#793818: Pcmanfm crash sometimes at the end of file(s) copy
>I just see that pcmanfm is now in version 1.2.4-1. >I have upgrated it. Well, while 1.2.4 upstream version has many bugs fixed, I'm afraid this particular one wasn't touched in that update so still would need some fix and your backtrace input would be very appreciated. Well, you might be right and running under gdb may don't give any crashes but backtrace may be made from a coredump file as well, you just need to make sure you have enabled creating coredumps in your system: a) run command in terminal: sysctl kernel.core_pattern and see if output isn't something like /dev/null but a regular file path b) run command in terminal: ulimit -c and see if it's not set to 0 If coredumps creation is enabled then after crash happened just run a gdb in next form: gdb pcmanfm your-coredump-file-path and you'll be able to get backtrace. If -dbg package isn't installed then backtrace will lack most of useful information so that I would ask you to install mentioned -dbg packages before sending backtrace to us. Thank you in advance.
Bug#819536: RFS: linuxbrew-wrapper/20150804-3
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "linuxbrew-wrapper" * Package name: linuxbrew-wrapper Version : 20150804-3 Upstream Author : homebrew * URL : http://brew.sh/linuxbrew/ * License : BSD-2-Clause Section : utils It builds those binary packages: linuxbrew-wrapper - Missing Package Manager For Linux To access further information about this package, please visit the following URL: http://mentors.debian.net/package/linuxbrew-wrapper Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/l/linuxbrew-wrapper/linuxbrew-wrapper_20150804-3.dsc More information about hello can be obtained from http://www.example.com. Changes since the last upload: linuxbrew-wrapper (20150804-3) unstable; urgency=medium * control: + Bump standards version from 3.9.6 to 3.9.7 (requires no change) + Update Homepage. + Correct URL in Vcs-Browser field. + Remove homepage link in package description. * rules: + Disable DH_VERBOSE by default. + get-orig-source: Don't print command line, to avoiding confusion. * bin/linuxbrew: refresh wrapper script. * example/profile: refresh example. * linuxbrew-wrapper.7: reduce content in manpage. * README.Debian: refresh content.
Bug#819194: dpkg-buildflags: please add normalizedebugpath to reproducible feature set
Hi! On Tue, 2016-03-29 at 21:52:53 -0400, Holger Levsen wrote: > On Tue, Mar 29, 2016 at 09:36:00PM -0400, Daniel Kahn Gillmor wrote: > > This isn't fun-spoiling, it's a useful reality check. But if we were > > required to get all the way to 100% before we made any progress, then > > reproducible builds wouldn't have gotten off the ground at all. > > it's surely progress on the gcc/clang side of things but dropping the > build path from the .buildinfo files would be a huge step *backwards* > for reproducibility… I concur with Daniel, I don't see anyone suggesting to drop the build path from the .buildinfo file just yet. But as long as that field does not leak information I'm ok with having it there. I think eventually it should be dropped because nothing should be recording the build path in the build, and the build should really be independent of that. > > The changes proposed in this bug report are a good step that should > > handle a very large proportion of the debian archive. The fact that > > there will remain corners of the archive that need additional work is > > fine: we can turn our attention to the remaining 20% once we get 80% of > > the buildpaths resolved. > > true. > > my point was: I think we still need the build path in the .buildinfo files. For now probably yes. > Also, c/c++ packages today only make up a small portion of the archive. > Probably this famous someone should do a rebuild of the archive, using > our toolchain (and this patch), using arbitrary build pathes. That's why I mentioned that the other language flages be included so that we get better coverage besides C/C++. Thanks, Guillem
Bug#819537: Add a "--distribution" parameter
Package: java-package
Version: 0.61
Tags: Patch
Currently, there is no way to specify the target distribution of a package
created
using "make-jpkg" as the distribution is hardcoded to "unstable" in the source
of
java-package.
It may, however, be desirable to specify the target distribution. Non-official
repos
using tools such as reprepro are often organized internally based on the names
of the supported distributions ("stable", "sid" or "xenial"). When uploading to
such
repos, packages made by make-jpkg will not be processed due to a mismatch in
the name of the target distribution.
The attached patch adds the desired functionality by adding a parameter named
"--distribution". If the parameter is specified, the value of it will be used
as target
distribution in the changelog of the resulting package. If the parameter is
unset,
"unstable" will be used, imitating the default behavior until now.
Thanks,
Martin
0001-java-package-distribution.patch
Description: Binary data
signature.asc
Description: Message signed with OpenPGP using GPGMail
Bug#819540: valadoc: build against vala 0.32
Source: valadoc Version: 0.23.2~git20150422-3 Severity: serious Your package needs to be updated to build against the new vala 0.32. Cheers, Emilio
Bug#819538: gnome-builder: build against vala 0.32
Package: gnome-builder Version: 3.18.1-2 Severity: serious Your package needs to be updated to build against the new vala 0.32. Cheers, Emilio
Bug#819541: mirror submission for mirror.fccn.pt
Package: mirrors Severity: wishlist User: mirr...@packages.debian.org Usertags: mirror-submission Submission-Type: new Site: mirror.fccn.pt Type: leaf Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x Archive-http: /repos/pub/debian/ CDImage-http: /repos/pub/debian-cd/ IPv6: yes Archive-upstream: ftp.belnet.be CDImage-upstream: deb-mirror.de Updates: twice Maintainer: Joao Pagaime Country: PT Portugal Location: Lisbon Sponsor: Foundation for Science and Technology, National Scientific Computing Unit (FCT|FCCN) http://fccn.pt
Bug#819194: dpkg-buildflags: please add normalizedebugpath to reproducible feature set
Hi! On Mon, 2016-03-28 at 20:18:11 -0400, Daniel Kahn Gillmor wrote: > On Mon 2016-03-28 19:51:57 -0400, Guillem Jover wrote: > > I was thinking about the other language flags that dpkg-dev currently > > supports, namely: OBJCFLAGS, OBJCXXFLAGS, GCJFLAGS, FFLAGS and > > FCFLAGS. As I think all those should produce DWARF debugging symbols, > > they would benefit from the option. > > Ah, OK. That sounds reasonable to me but i haven't tested any of them. > Do you want me to propose a patch, or are you OK taking it from here? I can easily add the missing flags, no problem there. I think because all these flags are used with gcc frontends they all accept the option but something I'd find useful is if someone could try it out. I myself confirmed with the gfortran compiler. If no one else does I guess I'll do it myself eventually. Thanks, Guillem
Bug#819539: valabind: build against vala 0.32
Package: valabind Version: 0.9.2-2 Severity: serious Your package needs to be updated to build against the new vala 0.32. Cheers, Emilio
Bug#813949: resolved?
##SELECTION_END##It seems that the problem is resolved with the last version of gnome et gnome bluetooth ?
Bug#819486: routino: At parks routino often can not find the route.
Bugreport #819486 I also wrote. I work with routino a very long time. And how I can tell, these are two different bugs. 29.03.2016 23:29, Sebastiaan Couwenberg пишет: > Control: tags -1 upstream > Control: forwarded -1 a...@gedanken.org.uk > > Hi Andrew, > > Roman reported an issue in the Debian Bug Tracking System for Routino > 3.1.1 that it often cannot find routes when one of the locations is in a > park. > > The report is included below and available online: > https://bugs.debian.org/819486 > > Can you confirm this issue, and possibly suggest a fix? > > On 03/29/2016 02:32 PM, Roman V. Nikolaev wrote: >> Package: routino >> Version: 3.1.1-2 >> Severity: normal >> >> Reproduce: >> >> 1. Open http://www.routino.org/uk-leaflet/router.html >> 2. Set point "1": -0.73458 E / 51.37529 N >> 3. Set point "2": any. For example: -0.06579 E / 51.47898 N >> 4. Click "Shortest Route" >> 5. Get: >> >> router --shortest --lon2=-0.06579 --speed-steps=0 --highway-ferry=20 >> --highway-primary=90 --highway-service=40 --speed-residential=48 >> --transport=motorcar --property-multilane=60 --speed-secondary=88 >> --speed-service=32 --highway-unclassified=60 --speed-motorway=112 --height=0 >> --highway-steps=0 --property-footroute=45 --speed-ferry=10 >> --highway-cycleway=0 --highway-residential=50 --highway-motorway=100 >> --highway-secondary=80 --speed-path=0 --width=0 --speed-primary=96 >> --lat1=51.37529 --oneway=1 --speed-cycleway=0 --length=0 --turns=1 >> --weight=0 --speed-unclassified=64 --lon1=-0.73458 --property-paved=100 >> --speed-track=16 --lat2=51.47898 --highway-track=0 --property-bridge=50 >> --property-bicycleroute=45 --highway-tertiary=70 --property-tunnel=50 >> --speed-trunk=96 --highway-trunk=100 --speed-tertiary=80 --highway-path=0 >> --reverse= --loop= --dir=routino-data >> >> Loaded Files: nodes, segments, ways & relations >> Found Closest Point: Waypoint 1 >> Error: Cannot find node close to specified point 1. >> >> Time: 0.000 CPU / 0.011 elapsed >> >> I see this bug in many parks. I think this may be due to many footways >> around. >> >> -- System Information: >> Debian Release: 8.3 >> APT prefers stable >> APT policy: (990, 'stable'), (500, 'testing-updates'), (500, >> 'testing-proposed-updates'), (500, 'stable-updates'), (500, >> 'proposed-updates'), (500, 'unstable'), (500, 'testing'), (500, >> 'oldstable'), (1, 'experimental') >> Architecture: amd64 (x86_64) >> >> Kernel: Linux 4.2.0-1-amd64 (SMP w/8 CPU cores) >> Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) >> Shell: /bin/sh linked to /bin/dash >> Init: systemd (via /run/systemd/system) >> >> Versions of packages routino depends on: >> ii libbz2-1.01.0.6-7+b3 >> ii libc6 2.19-18+deb8u3 >> ii libroutino-slim0 3.1.1-2 >> ii libroutino0 3.1.1-2 >> ii routino-common3.1.1-2 >> ii zlib1g1:1.2.8.dfsg-2+b1 > > Kind Regards, > > Bas > -- Roman V. Nikolaev
Bug#819542: python3-winrm unusable due to encoding error
Package: python3-winrm
Version: 0.0.3-1
Severity: grave
Justification: renders package unusable
Dear Maintainer,
After installing python3-winrm and trying to follow the getting started example
on https://pypi.python.org/pypi/pywinrm
This fails:
edb@lapelidb:/tmp$ cat test.py
#!/usr/bin/env python
import winrm
s = winrm.Session("1.2.3.4", auth=("admin", "admin"))
s.run_cmd("ipconfig", ["/all"])
edb@lapelidb:/tmp$ python3 test.py
Traceback (most recent call last):
File "test.py", line 5, in
s.run_cmd("ipconfig", ["/all"])
File "/usr/lib/python3/dist-packages/winrm/__init__.py", line 28, in run_cmd
shell_id = self.protocol.open_shell()
File "/usr/lib/python3/dist-packages/winrm/protocol.py", line 103, in
open_shell
rs = self.send_message(xmltodict.unparse(rq))
File "/usr/lib/python3/dist-packages/winrm/protocol.py", line 173, in
send_message
return self.transport.send_message(message)
File "/usr/lib/python3/dist-packages/winrm/transport.py", line 76, in
send_message
response = urlopen(request, timeout=self.timeout)
File "/usr/lib/python3.5/urllib/request.py", line 162, in urlopen
return opener.open(url, data, timeout)
File "/usr/lib/python3.5/urllib/request.py", line 463, in open
req = meth(req)
File "/usr/lib/python3.5/urllib/request.py", line 1170, in do_request_
raise TypeError(msg)
TypeError: POST data should be bytes or an iterable of bytes. It cannot be of
type str.
There are some reports upstream:
- https://github.com/diyan/pywinrm/issues/47
- https://github.com/diyan/pywinrm/issues/80
I tested the latest upstream release (0.1.1 installed through pip3) which gave
the same result.
On my system I tried to hotfix the version form the package, inspired upon this
pull request https://github.com/diyan/pywinrm/pull/70
Mainly patching send_message() in protocol.py (lines 170-173) into
def send_message(self, message):
# TODO add message_id vs relates_to checking
# TODO port error handling code
return self.transport.send_message(message.encode("utf-8"))
And for me the package continued beyond this point.
So summary:
- python3-winrm as available through apt is broken.
- pywinrm as available today through pip (v 0.1.1) suffers from the same
problem on my system.
my 2 cents
E.
-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages python3-winrm depends on:
ii python3-isodate0.5.4-1
ii python3-xmltodict 0.9.2-3
pn python3:any
Versions of packages python3-winrm recommends:
ii python3-kerberos 1.1.5-2+b2
python3-winrm suggests no packages.
-- no debconf information
This message is subject to the following terms and conditions: MAIL
DISCLAIMER
Bug#819534: libreoffice: LibreOffice fails to start
tag 819534 + unreproducible thanks On Wed, Mar 30, 2016 at 10:25:34AM +0200, Rene Engelhard wrote: > On Wed, Mar 30, 2016 at 11:15:59AM +0300, Stanislav Fyodorov wrote: > > Невозможно запустить приложение. > > which says what? OK, a colleague of mine translated this :) > > [context="shared"] caught unexpected > > com.sun.star.deployment.DeploymentException: Extension Manager: failed > > to read data entry in backend db: > > file:///home/sf/.config/libreoffice/4/user/extensions/shared/registry/com.sun.star.comp.deployment.help.PackageRegistryBackend/backenddb.xml > > -- > > So your profile is corrupted and/or you installed a broken extension and/or > a extension install broke it. > > What did you do last before getting this? I just tried - deboostrap a jessie - apt-get install libreoffice - start LO to get a existing old profile - change apt source to testing - apt-get install libreoffice - start LO starts fine. > > GDB trace is attached. > > Which doesn't say anything. Did you try to gdb "soffice" or "libreoffice" or whatever? Doesn't work, it's scripts. You want soffice.bin. But I believe strace would help here, more. (Same issue, unless you use some -f's see man strace, you need them anyway, but it's better to strace soffice.bin I think) Regards, Rene
Bug#772808: gnome-core: epiphany should be the default browser again
Hi! On Thu, 2014-12-11 at 12:54 +0100, Emilio Pozuelo Monfort wrote: > The (main) problem is not the lack of security features, but the lack of > security updates in webkitgtk+. It seems there's at least some progress on this, please see https://blogs.gnome.org/mcatanzaro/2016/02/01/on-webkit-security-updates/ Best regards Alexander Kurtz signature.asc Description: This is a digitally signed message part
Bug#819543: reportbug: doesn't run bug scripts for report-with: packages
Package: reportbug Version: 6.6.3 Severity: normal # cat /usr/share/bug/libreoffice/control report-with: libreoffice-core libreoffice-writer libreoffice-calc libreoffice-base libreoffice-draw libreoffice-impress libreoffice-math See e.g. 819534. I have a bug script in libreoffice-core to get some important/interesting information in LO. The bug was reported against libreoffice and the various Report-With: packages (including libreoffice-core) get their information. But not the output of the bug script... The bug script itself works: # /usr/share/bug/libreoffice-core/script 3>&1 javaldx: Could not find a Java Runtime Environment! All deployed bundled extensions: javaldx: Could not find a Java Runtime Environment! All deployed shared extensions: javaldx: Could not find a Java Runtime Environment! ERROR: cannot run unopkg as root without --shared or --bundled option. Experimental features enabled: Installed VCLplugs: Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==---= un libreoffice-gt (no description available) un libreoffice-kd (no description available) dpkg-query: no packages found matching libreoffice-gtk3 and a reportbug libreoffice-core adds that. Given people usually report against libreoffice (metapackage!) and thus I have report-with: for the "real" packages I'd think it's worthwhile to make those run on report-with: packages, too. A workaround is to add it also to "libreoffice", but I don't like that. Regards, Rene -- Package-specific info: ** Environment settings: EDITOR="vim" DEBEMAIL="r...@debian.org" -- System Information: Debian Release: 8.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: armhf (armv7l) Kernel: Linux 3.18.0-trunk-rpi2 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages reportbug depends on: ii apt 1.0.9.8.2 ii python2.7.9-1 ii python-reportbug 6.6.3 pn python:any reportbug recommends no packages. Versions of packages reportbug suggests: pn claws-mail pn debconf-utils pn debsums pn dlocate pn emacs23-bin-common | emacs24-bin-common pn file ii gnupg1.4.18-7 ii postfix [mail-transport-agent] 2.11.3-1 pn python-gtk2 pn python-gtkspell pn python-urwid pn python-vte ii xdg-utils1.1.0~rc1+git20111210-7.4 Versions of packages python-reportbug depends on: ii apt 1.0.9.8.2 ii python-debian 0.1.27 ii python-debianbts 1.12 pn python:any python-reportbug suggests no packages. -- no debconf information
Bug#819498: [Resolvconf-devel] Bug#819498: /etc/resolvconf/update.d/resolvconf-update-bind called without CAP_CHOWN from n-m
On Wed, Mar 30, 2016 at 09:35:32AM +0200, Thomas Hood wrote: > I am happy to remove the chown from the (example) script. But are you sure > that bind processes the file if the owner is not root:bind? Mine takes it happily with root:staff. I guess it won't if it can't read the file, so the script should make sure to create the file world readable, which might introduce a privacy problem iff private information is in the file. Maybe take a look at the source file and spew an error if it isn't world readable, so that the local admin can decide whether to make the source file world readable or to add CAP_CHOWN to network-manager. I do not have an idea if a shell script can check for certain capabilities, so the script might want to add error handling for the chown like if ! stat --format="%A" "$TMP_FILE" | grep -q '...r..'; then if ! chown "$TMP_FILE"; then echo >&2 "Error: cannot chown $TMP_FILE, capability missing, see #819498" fi fi (untested) 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#772808: gnome-core: epiphany should be the default browser again
On Wed, Mar 30, 2016 at 10:44:37AM +0200, Alexander Kurtz wrote: > On Thu, 2014-12-11 at 12:54 +0100, Emilio Pozuelo Monfort wrote: > > The (main) problem is not the lack of security features, but the lack of > > security updates in webkitgtk+. > > It seems there's at least some progress on this, please see > > https://blogs.gnome.org/mcatanzaro/2016/02/01/on-webkit-security-updates/ FWIW I'm in the process of providing backports of the stable WebKitGTK+ releases. Berto
Bug#819463: RFS: python-arrayfire/3.3.20160328-1 [ITP]
On 29/03/16 22:52, Mattia Rizzolo wrote:
On Tue, Mar 29, 2016 at 05:58:28PM +0100, Ghislain Vaillant wrote:
Just realized I should have probably named the source package
"arrayfire-python" to reflect the name of the project on GitHub
Regarding the renaming, I meant the **source** package only, not the
binary packages.
no, for the very simple reason that there is Python Debian Policy that
asserts python modules have to be named python-${module_name}
Indeed the policy is explicit about the naming convention of the binary
packages, but I could not find anything regarding the naming convention
for the corresponding source package.
I recently suggested adopting the same naming convention in Bug#819157:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819157
But the OP justified not taking action by mentioning the lack of
consistency in that regard for modules maintained by the DPMT.
Do you think it is a deficiency in the current policy then?
Ghis
Bug#819250: minidlna: Poor handling of inotify limits
Hello Mark, On Tue, 29 Mar 2016 12:16:52 -0700 Mark Brown wrote: > On Sun, Mar 27, 2016 at 08:09:33PM +0300, Alexander Gerasiov wrote: > > > 1. I don't think the reason of crash is someway linked to inotify. > > But this doesn't matter because of 2. > > I am seeing other crashes due to Linn Kazoo which I need to report > properly (and would expect to be fixed in stable) but this is > happening separately to that with no client software on the network. > > > 2. I believe the problem is fixed in current testing version. Please > > try 1.1.5 from testing or backports and report if crash persists. > > Are you sure this isn't serious enough to be fixed in stable? The > number of directories it's failing on is relatively low... Debian release policy only allows to fix bugs in stable which are 1. security flows or 2. makes software totally (or really highly) unusable. Other fixes should go normal way through unstable and could be delivered to users of stable distribution via backports. So could you confirm that problem is not reproducible with 1.1.5? -- Best regards, Alexander Gerasiov Contacts: e-mail: g...@cs.msu.su Homepage: http://gerasiov.net Skype: gerasiov PGP fingerprint: 04B5 9D90 DF7C C2AB CD49 BAEA CA87 E9E8 2AAC 33F1 pgpZ2tM1TOoDV.pgp Description: OpenPGP digital signature
Bug#808754: lightproof-en settings revert after each update
occurred again with update to Version: 1:5.1.2~rc1-1 !
Bug#815618: ovmf: Please someone create a DFSG-free ovmf variant
Control: tags -1 + fixed-upstream On Fri, 26 Feb 2016 09:07:03 +0800 Paul Wise wrote: > He has replied to me today to say that they are aware of the issue and > are working with Microsoft to rectify the issue soon. We'll see :) Their work has paid off and there is a new FatPkg under the 2-clause BSD license, thanks to Microsoft agreeing to the change: http://thread.gmane.org/gmane.comp.bios.edk2.devel/9930/focus=9956 https://twitter.com/tianocore/status/715016134982930432?s=09 -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#790690: Powermac G5 7,2 Nvidia GeForce 6800 GT graphics issues
Control: affects -1 xserver-xorg-video-nouveau Control: tags -1 confirmed upstream On Wed, Mar 30, 2016 at 11:21 AM, Risto Suominen wrote: > The other reason for using Peter's kernel is the page size. The > official kernels use 64 k pages that do not work with nouveau. Which kernel version are you using ?
Bug#818598: src:linux: MTD device probe failed after migrating kernel variant from -orion5x to -marvell
Adding the cfi_cmdset_0002 module to /etc/initramfs-tools/modules and an update-initramfs -u did the trick for me too. Thanks for the info.
Bug#819544: linux-image-4.4.0-0.bpo.1-amd64: screen blink/glitch on dual monitor setup
Package: src:linux Version: 4.4.6-1~bpo8+1 Severity: normal Tags: upstream Dear Maintainer, * What led up to the situation? - setup dual monitor on notebook with secondary monitor plugged into DSUB/VGA port - configure 2nd monitor to extend desktop - move mouse pointer from one display to another rapidly * What exactly did you do (or not do) that was effective (or ineffective)? - just boot normally, then desktop showed up, moving my mouse across monitor and there I noticed it * What was the outcome of this action? - there is glitch on some part of screen (blinking), on both display * What outcome did you expect instead? - no blinking, no glitch But now I revert to linux-image-4.3.0-0.bpo.1-amd64 and the problem is gone. -- Package-specific info: ** Version: Linux version 4.4.0-0.bpo.1-amd64 (debian-ker...@lists.debian.org) (gcc version 4.9.2 (Debian 4.9.2-10) ) #1 SMP Debian 4.4.6-1~bpo8+1 (2016-03-20) ** Command line: BOOT_IMAGE=/boot/vmlinuz-4.4.0-0.bpo.1-amd64 root=UUID=0c275924-c64a-4700-89dc-d0401c85e576 ro initrd=/install/gtk/initrd.gz quiet splash acpi_osi=Linux ** Tainted: O (4096) * Out-of-tree module has been loaded. ** Kernel log: [9.899415] intel ips :00:1f.6: CPU TDP doesn't match expected value (found 25, expected 29) [9.899587] intel ips :00:1f.6: IPS driver initialized, MCP temp limit 90 [9.963318] ACPI: Battery Slot [BAT0] (battery present) [ 10.010158] ACPI Warning: SystemIO range 0x0428-0x042F conflicts with OpRegion 0x0400-0x047F (\PMIO) (20150930/utaddress-254) [ 10.010167] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver [ 10.010170] ACPI Warning: SystemIO range 0x11C0-0x11CF conflicts with OpRegion 0x1180-0x11E3 (\GPIO) (20150930/utaddress-254) [ 10.010175] ACPI Warning: SystemIO range 0x11C0-0x11CF conflicts with OpRegion 0x1180-0x11DF (\_SB_.PCI0.LPCB.EC0_.GPIO) (20150930/utaddress-254) [ 10.010179] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver [ 10.010180] ACPI Warning: SystemIO range 0x11B0-0x11BF conflicts with OpRegion 0x1180-0x11E3 (\GPIO) (20150930/utaddress-254) [ 10.010184] ACPI Warning: SystemIO range 0x11B0-0x11BF conflicts with OpRegion 0x1180-0x11DF (\_SB_.PCI0.LPCB.EC0_.GPIO) (20150930/utaddress-254) [ 10.010187] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver [ 10.010188] ACPI Warning: SystemIO range 0x1180-0x11AF conflicts with OpRegion 0x1180-0x11E3 (\GPIO) (20150930/utaddress-254) [ 10.010192] ACPI Warning: SystemIO range 0x1180-0x11AF conflicts with OpRegion 0x1180-0x11DF (\_SB_.PCI0.LPCB.EC0_.GPIO) (20150930/utaddress-254) [ 10.010195] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver [ 10.010196] lpc_ich: Resource conflict(s) found affecting gpio_ich [ 10.089493] ACPI Warning: SystemIO range 0x1840-0x185F conflicts with OpRegion 0x1840-0x184F (\_SB_.PCI0.SBUS.SMBI) (20150930/utaddress-254) [ 10.089502] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver [ 10.123423] input: PC Speaker as /devices/platform/pcspkr/input/input8 [ 10.489738] systemd-journald[205]: Received request to flush runtime journal from PID 1 [ 10.742218] kvm: VM_EXIT_LOAD_IA32_PERF_GLOBAL_CTRL does not work properly. Using workaround [ 10.869222] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC272X: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker [ 10.869226] snd_hda_codec_realtek hdaudioC0D0:speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 10.869228] snd_hda_codec_realtek hdaudioC0D0:hp_outs=1 (0x21/0x0/0x0/0x0/0x0) [ 10.869230] snd_hda_codec_realtek hdaudioC0D0:mono: mono_out=0x0 [ 10.869232] snd_hda_codec_realtek hdaudioC0D0:inputs: [ 10.869234] snd_hda_codec_realtek hdaudioC0D0: Internal Mic=0x19 [ 10.869236] snd_hda_codec_realtek hdaudioC0D0: Mic=0x18 [ 11.008359] psmouse serio1: synaptics: queried max coordinates: x [..5576], y [..4880] [ 11.051700] iTCO_vendor_support: vendor-support=0 [ 11.060042] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11 [ 11.060093] iTCO_wdt: Found a HM55 TCO device (Version=2, TCOBASE=0x0460) [ 11.060211] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0) [ 11.132944] psmouse serio1: synaptics: Touchpad model: 1, fw: 7.4, id: 0x1c0b1, caps: 0xd04773/0xa4/0xa0400/0x0, board id: 0, fw id: 641896 [ 11.186426] i
Bug#819393: linux-image-marvell: missing kirkwood-ds112.dtb
Gregory Clement maintainer of arch/arm/boot/dts/kirkwood applied the patches [PATCH 1/1] ARM: dts: kirkwood: add kirkwood-ds112.dtb to Makefile [PATCH 1/1] ARM: dts: kirkwood: add kirkwood-nsa320.dtb to Makefile to the dt branch of http://git.infradead.org/linux-mvebu.git . Best regards Heinrich Schuchardt
Bug#819533: maim: please make the description clearer
Package: maim Followup-For: Bug #819533 Seconded. > The synopsis has a typo, "screenshts". But I'm mainly filing a bug for > the extended description, which left me rather non-plussed; here's > what I'd like to find out without having to look at maim's web site: > > * is it command-line or GUI driven? > * what's slop? is it packaged in Debian? > * in what way is maim better than scrot? Or indeed * in what way is maim better than import (in imagemagick)? There's a ruby-slop, but apparently you're talking about the slop that exists only on GitHub. Looking at the upstream description leaves me wondering: * in what way is slop better than xwd (in x11-apps)? -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package
Bug#819545: crmsh: 'crm cluster health' fails because 'parallax' python-package missing
Package: crmsh
Version: 2.2.0-1~bpo8+1
Severity: normal
Dear Maintainer,
crmsh was installed from the jessie-backports, and fails to execute 'crm
cluster health'
because the 'parallax' python-package is not installed. When called from a
running crm shell
the shell crashes with the same stacktrace output, which is as follows:
# crm cluster health
INFO: Check the health of the cluster
INFO: Nodes: vm-ha-j2, vm-ha-j1
Traceback (most recent call last):
File "/usr/sbin/crm", line 54, in
rc = main.run()
File "/usr/lib/python2.7/dist-packages/crmsh/main.py", line 351, in run
return main_input_loop(context, user_args)
File "/usr/lib/python2.7/dist-packages/crmsh/main.py", line 240, in
main_input_loop
rc = handle_noninteractive_use(context, user_args)
File "/usr/lib/python2.7/dist-packages/crmsh/main.py", line 196, in
handle_noninteractive_use
if context.run(' '.join(l)):
File "/usr/lib/python2.7/dist-packages/crmsh/ui_context.py", line 75, in run
rv = self.execute_command() is not False
File "/usr/lib/python2.7/dist-packages/crmsh/ui_context.py", line 245, in
execute_command
rv = self.command_info.function(*arglist)
File "/usr/lib/python2.7/dist-packages/crmsh/ui_cluster.py", line 158, in
do_health
return scripts.run(script, script_args(params), script_printer())
File "/usr/lib/python2.7/dist-packages/crmsh/scripts.py", line 2045, in run
opts = _make_options(params)
File "/usr/lib/python2.7/dist-packages/crmsh/scripts.py", line 383, in
_make_options
opts = parallax.Options()
NameError: global name 'parallax' is not defined
At this time there seems to be no debian package for parallax (which is a fork
of parallel-ssh by crmsh author 'krig')
-- System Information:
Debian Release: 8.3
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages crmsh depends on:
ii pacemaker-cli-utils 1.1.14-2~bpo8+1
ii python 2.7.9-1
ii python-lxml 3.4.0-1
ii python-yaml 3.11-2
ii python2.72.7.9-2
pn python:any
Versions of packages crmsh recommends:
ii pacemaker 1.1.14-2~bpo8+1
crmsh suggests no packages.
-- no debconf information
Bug#819546: vsftpd no longer starts with systemd because of listen_ipv6=NO from Bug: #803999
Package: vsftpd Version: 3.0.3-3 Severity: grave Justification: renders package unusable Dear Maintainer, Bug #803999 sets listen_ipv6=NO as stated in the manpage. In doing so, it breaks the systemd unit vsftpd which tries to do the following : ExecStart=/usr/sbin/vsftpd /etc/vsftpd.conf Running the command manually leads to : # /usr/sbin/vsftpd /etc/vsftpd.conf 500 OOPS: vsftpd: not configured for standalone, must be started from inetd Switching back listen_ipv6=YES allows the vsftpd daemon to start correctly. Right now, installing vsftpd in a fresh debian/sid will lead to a failure to start unless the parameter is set to listen_ipv6=YES. This can be easily shown by running the DEP8 test : Setting up adt-satdep (0) ... Processing triggers for systemd (229-3ubuntu1) ... (Reading database ... 87432 files and directories currently installed.) Removing adt-satdep (0) ... adt-run [10:50:30]: test smoke: [--- + sed -i s/^#\(write_enable=YES\)$/\1/ /etc/vsftpd.conf + service vsftpd reload vsftpd.service is not active, cannot reload. adt-run [10:50:31]: test smoke: ---] adt-run [10:50:32]: test smoke: - - - - - - - - - - results - - - - - - - - - - smokeFAIL non-zero exit status 1 The systemd service will clearly not work with such a configuration. So either the default in the manpage needs to be changed, or the unit needs to force the option with : /usr/sbin/vsftpd /etc/vsftpd.conf -olisten_ipv6=YES In such a case, it should be outlined somewhere in the manpage. -- Package-specific info: -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.13.0-83-generic (SMP w/12 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages vsftpd depends on: ii adduser3.114 ii debconf [debconf-2.0] 1.5.59 ii init-system-helpers1.29 ii libc6 2.22-4 ii libcap21:2.24-12 ii libpam-modules 1.1.8-3.2 ii libpam0g 1.1.8-3.2 ii libssl1.0.21.0.2g-1 ii libwrap0 7.6.q-25 ii netbase5.3 Versions of packages vsftpd recommends: ii logrotate 3.8.7-2 ii ssl-cert 1.0.37 vsftpd suggests no packages. -- debconf information: vsftpd/username: ftp vsftpd/directory: /srv/ftp # Example config file /etc/vsftpd.conf # # The default compiled in settings are fairly paranoid. This sample file # loosens things up a bit, to make the ftp daemon more usable. # Please see vsftpd.conf.5 for all compiled in defaults. # # READ THIS: This example file is NOT an exhaustive list of vsftpd options. # Please read the vsftpd.conf.5 manual page to get a full idea of vsftpd's # capabilities. # # # Run standalone? vsftpd can run either from an inetd or as a standalone # daemon started from an initscript. listen=NO # # This directive enables listening on IPv6 sockets. By default, listening # on the IPv6 "any" address (::) will accept connections from both IPv6 # and IPv4 clients. It is not necessary to listen on *both* IPv4 and IPv6 # sockets. If you want that (perhaps because you want to listen on specific # addresses) then you must run two copies of vsftpd with two configuration # files. listen_ipv6=NO # # Allow anonymous FTP? (Disabled by default). anonymous_enable=NO # # Uncomment this to allow local users to log in. local_enable=YES # # Uncomment this to enable any form of FTP write command. #write_enable=YES # # Default umask for local users is 077. You may wish to change this to 022, # if your users expect that (022 is used by most other ftpd's) #local_umask=022 # # Uncomment this to allow the anonymous FTP user to upload files. This only # has an effect if the above global write enable is activated. Also, you will # obviously need to create a directory writable by the FTP user. #anon_upload_enable=YES # # Uncomment this if you want the anonymous FTP user to be able to create # new directories. #anon_mkdir_write_enable=YES # # Activate directory messages - messages given to remote users when they # go into a certain directory. dirmessage_enable=YES # # If enabled, vsftpd will display directory listings with the time # in your local time zone. The default is to display GMT. The # times returned by the MDTM FTP command are also affected by this # option. use_localtime=YES # # Activate logging of uploads/downloads. xferlog_enable=YES # # Make sure PORT transfer connections originate from port 20 (ftp-data). connect_from_port_20=YES # # If you want, you can arrange for uploaded anonymous files to be owned by # a different user. Note! Using "root" for uploaded files is not # recommended! #chown_uploads=YES #chown_username=whoever # # You may override where the log file goes if you like. The default is shown # below. #xferlog_file=/var/log/vsftpd.log # # If you w
Bug#819547: RM: jffnms -- ROM; Deadish upstream, php package
Package: ftp.debian.org Severity: normal Hi ftp-masters, Can you remove JFFNMS from unstable? It currently hasn't moved from sid due to a RC bug (it includes other javascript items) and with the php5 to php7 release it was time to consider should it be in Debian at all? I'm the remaining upstream maintainer for it too but haven't done much with it as I've been working on a python replacement. I think popcorn showed 16 installations. Thanks! - Craig
Bug#819548: gnome-maps fails to start
Package: gnome-maps Version: 3.20.0-1 Severity: normal Dear Maintainer, I just upgraded to gnome-maps 3.20 and it failed to start. $ gnome-maps (org.gnome.Maps:1990): Gjs-WARNING **: JS ERROR: TypeError: GObject.ParamSpec.override is not a function @resource:///org/gnome/Maps/js/mapMarker.js:44 @resource:///org/gnome/Maps/js/placeMarker.js:24 @resource:///org/gnome/Maps/js/geoJSONSource.js:30 @resource:///org/gnome/Maps/js/geoJSONShapeLayer.js:22 @resource:///org/gnome/Maps/js/mapView.js:34 @resource:///org/gnome/Maps/js/mainWindow.js:38 @resource:///org/gnome/Maps/js/application.js:36 @resource:///org/gnome/Maps/js/main.js:43 start@resource:///org/gnome/gjs/modules/package.js:176 @/usr/bin/gnome-maps:5 JS_EvaluateScript() failed I checked bug reports seeing multiple reports about start failing but none of them are relevant (mostly related to older versions). Tell me if I can help. Jean-Marc -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing'), (100, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.4.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_BE.utf8, LC_CTYPE=fr_BE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gnome-maps depends on: ii dconf-gsettings-backend [gsettings-backend] 0.24.0-2 ii geoclue-2.0 2.4.1-1 ii gir1.2-champlain-0.120.12.13-1 ii gir1.2-clutter-1.0 1.24.2-1 ii gir1.2-cogl-1.0 1.22.0-2 ii gir1.2-gdkpixbuf-2.0 2.32.3-1.2 ii gir1.2-geoclue-2.0 2.4.1-1 ii gir1.2-geocodeglib-1.0 3.20.0-1 ii gir1.2-gfbgraph-0.2 0.2.3-1 ii gir1.2-glib-2.0 1.46.0-4 ii gir1.2-goa-1.0 3.18.4-1 ii gir1.2-gtk-3.0 3.18.9-1 ii gir1.2-gtkchamplain-0.12 0.12.13-1 ii gir1.2-gtkclutter-1.01.6.6-1 ii gir1.2-gweather-3.0 3.20.0-1 ii gir1.2-rest-0.7 0.7.93-1 ii gir1.2-secret-1 0.18.3-1 ii gir1.2-soup-2.4 2.52.2-1 ii gir1.2-webkit2-4.0 2.10.8-1 ii gjs 1.43.3-2 ii libatk1.0-0 2.18.0-1 ii libc62.22-4 ii libcairo-gobject21.14.6-1 ii libcairo21.14.6-1 ii libchamplain-0.12-0 0.12.13-1 ii libclutter-1.0-0 1.24.2-1 ii libcogl-pango20 1.22.0-2 ii libcogl-path20 1.22.0-2 ii libcogl201.22.0-2 ii libdrm2 2.4.67-1 ii libegl1-mesa [libegl1-x11] 11.1.2-1 ii libfolks25 0.11.1-2+b1 ii libgbm1 11.1.2-1 ii libgdk-pixbuf2.0-0 2.32.3-1.2 ii libgee-0.8-2 0.18.0-1 ii libgeocode-glib0 3.20.0-1 ii libglib2.0-0 2.48.0-1 ii libgtk-3-0 3.18.9-1 ii libjson-glib-1.0-0 1.2.0-1 ii libpango-1.0-0 1.38.1-1 ii libpangocairo-1.0-0 1.38.1-1 ii librest-0.7-00.7.93-1 ii libsoup2.4-1 2.52.2-1 ii libwayland-client0 1.9.0-1 ii libwayland-cursor0 1.9.0-1 ii libwayland-egl1-mesa [libwayland-egl1] 11.1.2-1 ii libwayland-server0 1.9.0-1 ii libx11-6 2:1.6.3-1 ii libxcomposite1 1:0.4.4-1 ii libxdamage1 1:1.1.4-2+b1 ii libxext6 2:1.3.3-1 ii libxfixes3 1:5.0.1-2+b2 ii libxi6 2:1.7.6-1 ii libxkbcommon00.5.0-1 ii libxml2 2.9.3+dfsg1-1 ii libxrandr2 2:1.5.0-1 gnome-maps recommends no packages. gnome-maps suggests no packages. -- no debconf information
Bug#819531: Invalid user name 'Debian-snmp' for adduser
Package: snmpd Version: 5.7.3+dfsg-1.1 Followup-For: Bug #819531 Confirmed. WHile I don't have a strong opinion about the "Debian-" prefix (vs a leading underscore), in any case the postinst script needs to call adduser with the "--force-badname" (as is done e.g. by exim4-config) -- System Information: Debian Release: stretch/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.4.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=de_AT.utf8, LC_CTYPE=de_AT.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages snmpd depends on: ii adduser3.114 ii debconf [debconf-2.0] 1.5.59 ii libc6 2.22-5 ii libsnmp-base 5.7.3+dfsg-1.1 ii libsnmp30 5.7.3+dfsg-1.1 ii lsb-base 9.20160110 snmpd recommends no packages. Versions of packages snmpd suggests: pn snmptrapd -- Configuration Files: /etc/snmp/snmpd.conf [Errno 13] Keine Berechtigung: u'/etc/snmp/snmpd.conf' -- debconf information excluded
Bug#819500: general: Debian 8.3 CLI reboot using "init 6" shows username & password in plain text.
Control: reassign -1 systemd Not sure which to blame, but assign to systemd first, since it's easily got lost if keeping it unassigned.
Bug#818598: src:linux: MTD device probe failed after migrating kernel variant from -orion5x to -marvell
Control: tags -1 +pending On Wed, Mar 30, 2016 at 6:48 PM, Sandy Gould wrote: > Adding the cfi_cmdset_0002 module to /etc/initramfs-tools/modules and an > update-initramfs -u did the trick for me too. Thanks for the info. Good to know there's other orion5x user, and is benefit from my working. That module will become built-in on next sid kernel release. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Bug#816205: tagging 816205
2016-03-28 14:44 GMT+02:00 Adam D. Barratt : > On Mon, 2016-03-28 at 14:39 +0200, Mathieu Parent (Debian) wrote: >> 2016-03-26 18:35 GMT+01:00 Adam D. Barratt : >> > On Sat, 2016-03-26 at 17:14 +0100, Mathieu Parent wrote: >> >> tags 816205 + jessie-ignore >> >> thanks >> > >> > Was that discussed with anyone on the Release Team before the tag was >> > added? >> >> No.I've done it to remove this bug from my UDD dashboard. > > I see. Please don't do that in future. OK. > The tags have a specific purpose (which isn't "I don't want to fix or > see this in $release") and should only be set by, or with the agreement > of, the Release Team. See the bolded sections of > https://www.debian.org/Bugs/Developer#tags OK > Regards, > > Adam > -- Mathieu Parent
Bug#819549: What ever happened to yaboot?
Package: src:yaboot Version: 1.3.17-1 Severity: grave Looks like yaboot does not find its conf file any more. I'm trying to install (CD) Debian on a PowerMac G5 (7,3). Jessie (yaboot 1.3.16) works. Stretch (yaboot 1.3.17) does not. It complains: cd:-1,\install\yaboot.conf: Unable to open file, Invalid device Or, on a Mac mini G4: cd:-1,\install\mac32.conf: Unable to open file, Invalid device
Bug#650601: libpng is going to be NMUed soon
Hi Emilio wrote: > binary-NEW shouldn't be a big deal. Just make sure to upload to experimental. I triple checked, in 8 hours or so it will finish the deferred queue time. https://ftp-master.debian.org/deferred/libpng1.6_1.6.20-3_amd64.changes the changes file looks fine to me: Distribution: experimental libpng1.6 (1.6.20-3) experimental; urgency=medium (no answers from maintainers is sad) Tobias, I did some uploads in new queue, everything was accepted in a matter of a few hours. for binNEW I think this will be even faster, I got casablanca accepted in a matters of minutes IIRC :) (I think this won't be the case, but I can ping on -ftp if it takes longer times maybe). After the accept... we will be ready for the ack! (I think the unstable upload will follow with no delay after the ack). cheers, G.
Bug#815915: initramfs-tools-core: lsinitramfs causes zcat crash when Intel microcode is included in initrd
On Sat, Feb 27, 2016 at 08:09:47PM +, Ben Hutchings wrote: > > When using lsinitramfs to check the contents of an initrd: > > > > > root:~# lsinitramfs /boot/initrd.img-4.4.2 > > > /boot/initrd.img-4.4.2-curly-0 > > > kernel > > > kernel/x86 > > > kernel/x86/microcode > > > kernel/x86/microcode/GenuineIntel.bin > > > *** Error in `zcat': double free or corruption (!prev): > > > 0x02236940 *** > > > > lsinitramfs runs fine on my AMD boxes. > > > > It seems that Ubuntu has at least two reports of this: see their bug > > numberss 1541076 and 1507443. I don't see a Debian bug report on it, though. > > The crash is a bug in zcat. But presumably we are also not invoking it > correctly. I couldn't reproduce this. Ron, could you place your /boot/initrd.img-4.4.2 somewhere for download? Cheers, Moritz
Bug#819550: linux-image-4.4.0-0.bpo.1-rt-amd64: boot stall while trying 4.4 rt amd64 kernel
Package: linux-image-4.4.0-0.bpo.1-rt-amd64 Severity: critical Justification: breaks the whole system Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? installing rt 4.4 * 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? locked at startup *** End of the template - remove these template lines *** -- System Information: Debian Release: 8.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (500, 'oldstable'), (10, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.4.0-0.bpo.1-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#810982: [Pkg-net-snmp-devel] Bug#810982: net-snmp: FTBFS on kfreebsd10
On Tue, 29 Mar 2016 10:41:06 +0200 "Steinar H. Gunderson" wrote: > I intend to NMU for this bug and a few other bugs that I'd really like to see > fixed before stretch. I've uploaded to DELAYED/7-day; let me know if you'd > like anything changed. I've attached my own git diff on top of Steven's diff > (which is on top of latest pkg-net-snmp git). Already uploaded :-( git tree is WIP and has bug I thought, so it's bad for me upload... I don't know why you've uploaded it based on git, it should be minimized for change and now we have Bug#819531 (of course I know it is caused by my code but it should be tested before upload, though). -- Regards, Hideki Yamane henrich @ debian.or.jp/org http://wiki.debian.org/HidekiYamane
Bug#807021: mercurial: FTBFS when built with dpkg-buildpackage -A (No such file or directory)
Hello Javi and Julien. You could do this instead, which I think it's cleaner: --- a/debian/rules +++ b/debian/rules @@ -83,11 +83,9 @@ install-archindep: -name '*.so' ! -type d -delete , \ -type d -empty -delete -override_dh_python2: +override_dh_python2-arch: dh_python2 - if test -d debian/mercurial; then \ - find debian/mercurial/usr/share -type d -empty -delete ; \ - fi + find debian/mercurial/usr/share -type d -empty -delete override_dh_auto_clean: mercurial/__version__.py cp -a mercurial/__version__.py mercurial/__version__.py.save
Bug#819343: ITP: r-cran-dplyr -- A Grammar of Data Manipulation for GNU R
On 29 March 2016 at 08:28, Andreas Tille wrote: | Hi Chris, | | On Mon, Mar 28, 2016 at 08:45:41PM -0400, Chris Lawrence wrote: | > On Mon, Mar 28, 2016 at 9:21 AM, Andreas Tille wrote: | > > Thanks for this ITP since it is also on my list of needed packages for | > > r-cran-treescape which needs several dependencies. I have noticed | > > that its even in NEW. I wonder how you was able to build it without | > > r-cran-bh since I also tried to package r-cran-dplyr[1] but I had the | > > impression that r-cran-bh (#819389) would be required. | > | > The short answer is... I cheated. | | Ahhh. :-) | | > I edited out the BH reference in LinkingTo in DESCRIPTION and made the | > source package depend on libboost-all-dev (>= 1.58). Since all BH does | > is package a subset of libboost-all-dev, it works even though it's a | > minor hack of the upstream source. In principle, we should be able to | > do the same with anything that uses LinkingTo that isn't (yet) | > packaged with an r-cran-* shell package but we have Debian packages | > for. | > | > Dirk and I did talk about putting together an r-cran-bh that didn't | > needlessly duplicate the libboost-*-dev packages it brings in, but I | > don't know where that stands. | | I talked about this with Dirk[1] and may be I should have done this for | the moment as well. Meanwhile Dirk has ITPed r-cran-bh (#819389) and | has uploaded it to new - so this should be dealt with hopefully soon. It is messy and I can see it two ways. It is good not to double up installed size. It is bad to have a package behave differently -- eg users of a 'fake' r-cran-bh in Debian would see a complete Boost and be tempted to include headers users of the other one do not see. Plus, small deltas. BH is at 1.60.0; Debian still uses 1.58.0. Dirk | It would be nice to have a look into your packaging anyway in the mean | time. So finding it in some VCS (see below) would be helpful. | | > > It would be great if you would move your packaging to some VCS (for | > > instance Debian Science). I would volunteer to commit autopkg stuff | > > which I've just prepared[1]. | > > | > > Kind regards | > > | > > Andreas. | > > | > > [1] svn://anonscm.debian.org/debian-med/trunk/packages/R/r-cran-dplyr/trunk/ | > | > One of these decades I'll have to learn how to use VCSes for | > packaging. | | I'd recommend using Git in this case since there seem to be a tendency | inside Debian into this direction. While you can see from the URL above | I started in SVN. The rationale is that R packaging is in most cases | simple enough that we keep only the debian/ dir which is in line with | the usual workflow in SVN while the typical workflow in Git is to store | upstream source and packaging in one repository. | | Since I think r-cran-dplyr would be sensible inside the Debian Science | team you can read how to do it in the Debian Science policy document[2]. | I would volunteer to inject your packaging into Debian Science Git if | this would help you in the beginning. If you want me to do this simply | put somewhere online to enable me downloading it (while it resides in | new). | | Kind regards | | Andreas. | | [2] https://debian-science.alioth.debian.org/debian-science-policy.html#idp45010192 | | -- | http://fam-tille.de | -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#819504: mercurial: CVE-2016-3068 CVE-2016-3069 CVE-2016-3630
On Tue, Mar 29, 2016 at 21:34:20 +0200, Salvatore Bonaccorso wrote:
> the following vulnerabilities were published for mercurial.
>
> CVE-2016-3068[0]:
> arbitrary code execution with Git subrepos
>
> CVE-2016-3069[1]:
> arbitrary code execution when converting Git repos
>
> CVE-2016-3630[2]:
> remote code execution in binary delta decoding
>
Hi,
here's a diff for jessie, modulo s/UNRELEASED/jessie-security/ in the
changelog. OK to upload to security-master?
I'll work on wheezy next.
Cheers,
Julien
diff -Nru mercurial-3.1.2/debian/changelog mercurial-3.1.2/debian/changelog
--- mercurial-3.1.2/debian/changelog 2015-05-02 09:37:01.0 +0200
+++ mercurial-3.1.2/debian/changelog 2016-03-30 11:57:49.0 +0200
@@ -1,3 +1,19 @@
+mercurial (3.1.2-2+deb8u2) UNRELEASED; urgency=medium
+
+ * CVE-2016-3630:
++ parsers: fix list sizing rounding error
++ parsers: detect short records
+ * CVE-2016-3068:
++ subrepo: set GIT_ALLOW_PROTOCOL to limit git clone protocols
+ * CVE-2016-3069:
++ convert: add new, non-clowny interface for shelling out to git
++ convert: rewrite calls to Git to use the new shelling mechanism
++ convert: dead code removal - old git calling functions
++ convert: rewrite gitpipe to use common.commandline
++ convert: test for shell injection in git calls
+
+ -- Julien Cristau Wed, 30 Mar 2016 11:55:27 +0200
+
mercurial (3.1.2-2+deb8u1) jessie-security; urgency=high
* Fix "CVE-2014-9462" by adding patch
diff -Nru mercurial-3.1.2/debian/patches/from_upstream__convert-add-new,-non-clowny-interface-for-shelling-out-to-git.patch mercurial-3.1.2/debian/patches/from_upstream__convert-add-new,-non-clowny-interface-for-shelling-out-to-git.patch
--- mercurial-3.1.2/debian/patches/from_upstream__convert-add-new,-non-clowny-interface-for-shelling-out-to-git.patch 1970-01-01 01:00:00.0 +0100
+++ mercurial-3.1.2/debian/patches/from_upstream__convert-add-new,-non-clowny-interface-for-shelling-out-to-git.patch 2016-03-30 12:04:55.0 +0200
@@ -0,0 +1,80 @@
+# HG changeset patch
+# User Mateusz Kwapich
+# Date 1458691511 25200
+# Tue Mar 22 17:05:11 2016 -0700
+# Branch stable
+# Node ID 197eed39e3d5e9a8cadfd9ba5839eb14cc265caa
+# Parent 34d43cb85de8d06764039d8868eee19d00fddeab
+convert: add new, non-clowny interface for shelling out to git (SEC)
+
+CVE-2016-3069 (1/5)
+
+To avoid shell injection and for the sake of simplicity let's use the
+common.commandline for calling git.
+
+--- mercurial-3.1.2.orig/hgext/convert/git.py
mercurial-3.1.2/hgext/convert/git.py
+@@ -9,11 +9,11 @@ import os
+ import subprocess
+ from mercurial import util, config
+ from mercurial.node import hex, nullid
+ from mercurial.i18n import _
+
+-from common import NoRepo, commit, converter_source, checktool
++from common import NoRepo, commit, converter_source, checktool, commandline
+
+ class submodule(object):
+ def __init__(self, path, node, url):
+ self.path = path
+ self.node = node
+@@ -23,11 +23,11 @@ class submodule(object):
+ return "%s = [git]%s" % (self.path, self.url)
+
+ def hgsubstate(self):
+ return "%s %s" % (self.node, self.path)
+
+-class convert_git(converter_source):
++class convert_git(converter_source, commandline):
+ # Windows does not support GIT_DIR= construct while other systems
+ # cannot remove environment variable. Just assume none have
+ # both issues.
+ if util.safehasattr(os, 'unsetenv'):
+ def gitopen(self, s, err=None):
+@@ -69,10 +69,25 @@ class convert_git(converter_source):
+ return util.popen('GIT_DIR=%s %s' % (self.path, s), 'rb')
+
+ def gitpipe(self, s):
+ return util.popen3('GIT_DIR=%s %s' % (self.path, s))
+
++def _gitcmd(self, cmd, *args, **kwargs):
++return cmd('--git-dir=%s' % self.path, *args, **kwargs)
++
++def gitrun0(self, *args, **kwargs):
++return self._gitcmd(self.run0, *args, **kwargs)
++
++def gitrun(self, *args, **kwargs):
++return self._gitcmd(self.run, *args, **kwargs)
++
++def gitrunlines0(self, *args, **kwargs):
++return self._gitcmd(self.runlines0, *args, **kwargs)
++
++def gitrunlines(self, *args, **kwargs):
++return self._gitcmd(self.runlines, *args, **kwargs)
++
+ def popen_with_stderr(self, s):
+ p = subprocess.Popen(s, shell=True, bufsize=-1,
+ close_fds=util.closefds,
+ stdin=subprocess.PIPE,
+ stdout=subprocess.PIPE,
+@@ -86,10 +101,11 @@ class convert_git(converter_source):
+ data = fh.read()
+ return data, fh.close()
+
+ def __init__(self, ui, path, rev=None):
+ super(convert_git, self).__init__(ui, path, rev=rev)
++commandline.__init__(self, ui, 'git')
+
+ if os.path.isdir(path + "/.git"):
+ path += "/.git"
+ if not os.path.exists(path + "/objects"):
+
Bug#403289: add shorcut to compile a software
Control: tags -1 + wontfix Hi Ludovic, 2006-12-15 23:04 Ludovic Gasc: Package: aptitude Version: 0.4.4-1 With apt-build, it's possible to recompile easily a deb. It would be greatful if it's possible with a keyboard shortcut to select a software to recompile. Thanks for your response. 2011-08-30 08:50 Daniel Hartwig: severity 403289 wishlist block 403289 by 403372 468897 quit Compiling source packages requires fetching both the source [1] and any build-dep [2]. [1] 403372 -- To include option for download the source archives [2] 468897 -- implement build-dep and source actions (The following is mostly a consideration of the difficulty of the problem, not a reply to the original report per se). The implementation of this feature is not trivial, and there are many considerations to make. Firstly, fetching source and installing build-dependencies is not a solved problem in aptitude, as the reply above said; so these mechanisms would have to be implemented first. But what it's more important, aptitude would have to make several non-trivial decisions or implement quite a few things with the requested feature, with such as a high-level thing as compiling by pressing a key. For example, one has to download and install all build-dependencies, which can mean a huge amount of data to download (e.g. installing tetex to create the documentation), so a warning has to be issued in this case (perhaps the user thinks that compiling a small package is a small matter, but the process can eat up a lot of bandwith and surprise/annoy the user). Another matter is where to download the source. There's a well established place for downloading packages to be installed (/var/cache/apt/archives), but not so for such things as a package to be compiled. /usr/local/src? Maybe, but /usr/ can be mounted as read-only. /tmp/ or /var/tmp? /var/cache/aptitude-build? Perhaps, but compiling big packages like the web browsers can use a huge amount of space and could fill /tmp or the root partition with pretty disastrous consequences, so the program would have to get some kind of confirmation from the user of where to download this. A config variable could be used for that, but at least for the first time, the user would have to acknowledge it. apt-build doesn't suffer from this because it does that in the current directory, I think. There are other non-trivial questions to be solved like what to do when aptitude is root, because running such things as root is perhaps not the wisest thing to do; or what to do if the user is in the middle of a session of installing/removing packages (installing build-deps could ruin, or conflict, with the current actions). apt-build doesn't have to deal with the problem of being in the middle of a session, or being run interactively in ncurses. Doing this with the command line of aptitude could have similar advantages of simplifying the process a lot, but then again we already have apt-build for that. The last thing to consider that I will delve into is... why do all of this? In the original request, this is to "recompile" software. If it's software available in Debian (so build-deps can be installed and the package source downloaded), specially with the drive towards reproducible builds, the result should be an identical binary package, so I am not sure if this is the goal. If the goal is to (re)compile a package with some modifications, then the process cannot be automated, and a shell has to be spawned to be able to apply patches, or changing commands in debian/rules, enabling/disabling features (e.g. support for wayland, or codecs) or issuing different compilation flags. This is again another thing that would be better served by something more like apt-build (or apt source + HACK + debuild; or git-buildpackage; or any of the other tools) and not doing it interactively from the curses interface of aptitude. ... so these are some of the problems that come to mind as decisions to make to implement this feature. A simple keypress triggering actions like recompiling a package is not straightforward to implement at all. Given that this has been requested a decade ago and there's no drive to implement this any time soon, I am marking it as +wontfix for the time being. Cheers. -- Manuel A. Fernandez Montecelo
Bug#819181: RFS: cl-asdf/3.1.7 - Another System Definition Facility
Hi Gianfranco, thank you for taking care of this. > +override_dh_clean: > + dh_quilt_patch > + dh_clean > > > why? The reason is that the upstream 'make clean' deletes debian/patches completely. So without this, I'm not able to patch anything. > also adding quilt to b-d-i seems useless to me. You mean it should be added to Build-Depends? I guess I have misunderstood the description of b-d-i and thought that because quilt is architecture-independent, it belongs in b-d-i. Shall I move it to Build-Depends? Thanks Kambiz
Bug#819343: ITP: r-cran-dplyr -- A Grammar of Data Manipulation for GNU R
On Wed, Mar 30, 2016 at 06:21:55AM -0500, Dirk Eddelbuettel wrote: > > | I talked about this with Dirk[1] and may be I should have done this for > | the moment as well. Meanwhile Dirk has ITPed r-cran-bh (#819389) and > | has uploaded it to new - so this should be dealt with hopefully soon. > > It is messy and I can see it two ways. It is good not to double up installed > size. Could you please explain what size exactly is doubled? As far as I understood r-cran-b would be just a wrapper for the Debian packaged libboost. > It is bad to have a package behave differently -- eg users of a 'fake' > r-cran-bh in Debian would see a complete Boost and be tempted to include > headers users of the other one do not see. Plus, small deltas. I totally fail to understand what you mean. > BH is at > 1.60.0; Debian still uses 1.58.0. That should be a temporary thing since 1.60.0 is in new[1]. Is you packaging somewhere in VCS to enable others having a look which might clarify your text above? Kind regards Andreas. [1] https://ftp-master.debian.org/new/boost1.60_1.60.0+dfsg-1.html -- http://fam-tille.de
Bug#810982: [Pkg-net-snmp-devel] Bug#810982: net-snmp: FTBFS on kfreebsd10
On Wed, Mar 30, 2016 at 07:48:03PM +0900, Hideki Yamane wrote: > Already uploaded :-( Yes, something went wrong with the delay, like I said. すみません :-/ > git tree is WIP and has bug I thought, so it's bad for me upload... > I don't know why you've uploaded it based on git, it should be minimized > for change and now we have Bug#819531 (of course I know it is caused by > my code but it should be tested before upload, though). I'll have a look at it tonight and see what I can do. Thanks for alerting me of it. /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#819463: RFS: python-arrayfire/3.3.20160328-1 [ITP]
On Wed, Mar 30, 2016 at 10:11:53AM +0100, Ghislain Vaillant wrote: > Indeed the policy is explicit about the naming convention of the binary > packages, but I could not find anything regarding the naming convention > for the corresponding source package. > > I recently suggested adopting the same naming convention in Bug#819157: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819157 > > But the OP justified not taking action by mentioning the lack of > consistency in that regard for modules maintained by the DPMT. > > Do you think it is a deficiency in the current policy then? I do think so. I can accept having the source named with only the module name, but imho python-$module is better as it provides namespacing also between the source package names. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: http://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#819343: ITP: r-cran-dplyr -- A Grammar of Data Manipulation for GNU R
On 30 March 2016 at 13:34, Andreas Tille wrote: | On Wed, Mar 30, 2016 at 06:21:55AM -0500, Dirk Eddelbuettel wrote: | > | > | I talked about this with Dirk[1] and may be I should have done this for | > | the moment as well. Meanwhile Dirk has ITPed r-cran-bh (#819389) and | > | has uploaded it to new - so this should be dealt with hopefully soon. | > | > It is messy and I can see it two ways. It is good not to double up installed | > size. | | Could you please explain what size exactly is doubled? As far as I | understood r-cran-b would be just a wrapper for the Debian packaged | libboost. Nope. As I explained to you before and in this thread, there is downside in differing from what is on CRAN. So r-cran-bh, as packaged and so far only on my box, does what every r-cran-* package does: include the CRAN package: edd@max:~/src/debian/CRAN$ ls -lh /var/cache/pbuilder/result/*bh* -rw-r--r-- 1 root root 5.6M Mar 27 17:25 /var/cache/pbuilder/result/r-cran-bh_1.60.0-1-1_all.deb -rw-rw-r-- 1 edd edd 2.4K Mar 27 17:25 /var/cache/pbuilder/result/r-cran-bh_1.60.0-1-1_amd64.changes -rw-rw-r-- 1 edd edd 379 Mar 27 16:58 /var/cache/pbuilder/result/r-cran-bh_1.60.0-1-1_amd64.local.upload -rw-r--r-- 1 root root 4.1K Mar 27 17:24 /var/cache/pbuilder/result/r-cran-bh_1.60.0-1-1.diff.gz -rw-rw-r-- 1 edd edd 1.7K Mar 27 17:25 /var/cache/pbuilder/result/r-cran-bh_1.60.0-1-1.dsc -rw-rw-r-- 1 edd edd 9.2M Dec 28 08:13 /var/cache/pbuilder/result/r-cran-bh_1.60.0-1.orig.tar.gz edd@max:~/src/debian/CRAN$ But what is another 14mb between friends. | > It is bad to have a package behave differently -- eg users of a 'fake' | > r-cran-bh in Debian would see a complete Boost and be tempted to include | > headers users of the other one do not see. Plus, small deltas. | | I totally fail to understand what you mean. i) BH is not a complete Boost. Never was, never will be. Headers only. And a selected subset. So some non-Debian R users of BH would potentially see a build including 'boost-foo' fail whereas we do. ii) Small delta: 1.58 != 1.60. | > BH is at | > 1.60.0; Debian still uses 1.58.0. | | That should be a temporary thing since 1.60.0 is in new[1]. We had BH 1.60 for several months now. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#594868: Still applies
On Wed, 30 Mar 2016 01:52:40 +0200 Frank Lichtenheld wrote: > This bug still applies. > A more recent example would be > https://packages.debian.org/jessie-backports/libapache2-mod-security2 > > It depends on apache2-api-20120211 which is provided in jessie, but > the page in jessie-backports doesn't reflect that. I looked a bit further into this. It basically boils down to the horrible function Packages::Search::read_entry_simple() which is much too terse and too cryptic in its return value. It should be completely reimplemented. Which is not that bad since it is only used in two places in the code anyway. Regards, Frank -- Frank Lichtenheld
Bug#819530: transition: icu
On Wed, Mar 30, 2016 at 07:38:58AM +0200, Laszlo Boszormenyi (GCS) wrote: > Boost 1.58 -> successfully compiled LibreOffice 5.1.2~RC1. Including the tests? But then again, the broken help on the last transition and the crashes in some other one before that were not catched by the tests either ;) I asked, noone tried with 57 yet for LO. > May I proceed with the upload, targeting experimental first? Not from the RT, but... Well, uploading to experimental is fine anytime I think, that also has the advantage that you already cleared NEW when this is supposed to start in unstable. And people can try with experimental. Regards, Rene
Bug#819551: lintian: binaries-missing-depends-on-libc failure
Package: lintian Version: 2.5.42.1 If you run the binaries-missing-depends-on-libc test with -Wl,--as-needed in LDFLAGS (or on by default in your linker), then you might not actually get libc linked into the C++ library. Then the test fails because only the C library has libc in NEEDED but is missing the Depends. Running the test with -Wl,--no-as-needed fixes this and seems like a smart thing to do in general as we don't want the linker to silently remove things we're trying to test. Attached patch does that. -- Dan diff -Nru lintian-2.5.42.1/t/tests/binaries-missing-depends-on-libc/debian/debian/rules lintian-2.5.42.1endless1/t/tests/binaries-missing-depends-on-libc/debian/debian/rules --- lintian-2.5.42.1/t/tests/binaries-missing-depends-on-libc/debian/debian/rules 2016-02-08 12:50:20.0 -0800 +++ lintian-2.5.42.1endless1/t/tests/binaries-missing-depends-on-libc/debian/debian/rules 2016-03-29 15:02:25.0 -0700 @@ -2,6 +2,9 @@ export DEB_BUILD_MAINT_OPTIONS=hardening=+all +# Make sure the C++ library actually links to libc +export DEB_LDFLAGS_MAINT_APPEND=-Wl,--no-as-needed + %: dh $@
Bug#807579: [future CUDA 8.0] may come together with nvidia driver 361.X
Hello guys, CUDA 8.0 support can be seen in the release note of 361.X. for example: http://us.download.nvidia.com/Windows/361.91/361.91-win10-win8-win7-winvista-desktop-release-notes.pdf that means CUDA 8.0 will come soon. Debian's latest nvidia driver pending driver is 355.X pending in the NEW queue. @doko: When will Debian switch its default compiler to 6.0? Assume that cuda 8.0 works with gcc-6, if we have chance to sync the cuda 8.0 upload and gcc-6 transition, we can avoid breaking some packages. I've really had bad experience packaging cuda software when GCC is transitioning to 5, everything is not working. I hope we can eliminate this nightmare for other devs. I'll test GCC-6 compatibility with CUDA 8.0 when it comes, and inform you all in a new bug. Thanks. :-)
Bug#819552: gnome-shell: Alt + 3 strikes using left mouse button on rdesktop/xfreerdp mouse stuck
Package: gnome-shell Version: 3.14.4-1~deb8u1 Severity: important Hi, To reproduce: 1. Set "Window Action Key" to Alt 2. Start rdesktop/xfreerdp 3. Focus rdesktop/xfreerdp 4. Press and hold Alt 5. Click and hold left mouse button and strike right 6. Release left mouse button and return mouse position to left 7. Quickly repeat stpes 5 and 6 for 3 times or more 8. Mouse grab and click stuck To ungrab, have to either focus to applications other than rdesktop/xfreerdp and press the Win key or use Alt-Left click to move other applications around. During the stuck grab, the grab debug prints the following: Mar 30 19:52:52 sirloin gdm-Xorg-:0[1301]: (II) Printing all currently active device grabs: Mar 30 19:52:52 sirloin gdm-Xorg-:0[1301]: Active grab 0x100 (xi2) on device 'Virtual core pointer' (2): Mar 30 19:52:52 sirloin gdm-Xorg-:0[1301]: client pid 6637 /usr/bin/gnome-shell Mar 30 19:52:52 sirloin gdm-Xorg-:0[1301]: at 3526841 (from active grab) (device thawed, state 1) Mar 30 19:52:52 sirloin gdm-Xorg-:0[1301]: xi2 event mask for device 2: 0xfc100 Mar 30 19:52:52 sirloin gdm-Xorg-:0[1301]: owner-events false, kb 1 ptr 1, confine 0, cursor 0x0 Mar 30 19:52:52 sirloin gdm-Xorg-:0[1301]: (II) End list of active device grabs I used to use Alt-left click to move around windows, so always get stuck with this problem. Hope there's a workaround besides resorting to re-focusing to move window or press the Win key. - PY -- System Information: Debian Release: 8.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.4.0-0.bpo.1-amd64 (SMP w/4 CPU cores) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gnome-shell depends on: ii dconf-gsettings-backend [gsettings-back 0.22.0-1 ii evolution-data-server3.12.9~git20141128.5242b0-2+deb8u2 ii gir1.2-accountsservice-1.0 0.6.37-3+b1 ii gir1.2-atspi-2.0 2.14.0-1 ii gir1.2-caribou-1.0 0.4.15-1 ii gir1.2-clutter-1.0 1.20.0-1 ii gir1.2-freedesktop 1.42.0-2.2 ii gir1.2-gcr-3 3.14.0-2 ii gir1.2-gdesktopenums-3.0 3.14.1-1 ii gir1.2-gdm3 3.14.1-7 ii gir1.2-gkbd-3.0 3.6.0-1 ii gir1.2-glib-2.0 1.42.0-2.2 ii gir1.2-gnomebluetooth-1.03.14.0-2 ii gir1.2-gnomedesktop-3.0 3.14.1-1 ii gir1.2-gtk-3.0 3.14.5-1+deb8u1 ii gir1.2-ibus-1.0 1.5.9-1 ii gir1.2-mutter-3.03.14.4-1~deb8u1 ii gir1.2-networkmanager-1.00.9.10.0-7 ii gir1.2-nmgtk-1.0 0.9.10.0-2 ii gir1.2-pango-1.0 1.36.8-3 ii gir1.2-polkit-1.00.105-8 ii gir1.2-soup-2.4 2.48.0-1 ii gir1.2-telepathyglib-0.120.24.1-1 ii gir1.2-telepathylogger-0.2 0.8.1-1 ii gir1.2-upowerglib-1.00.99.1-3.2 ii gjs 1.42.0-1 ii gnome-backgrounds3.14.1-1 ii gnome-icon-theme-symbolic3.12.0-1 ii gnome-settings-daemon3.14.2-3 ii gnome-shell-common 3.14.4-1~deb8u1 ii gnome-themes-standard3.14.2.2-1 ii gsettings-desktop-schemas3.14.1-1 ii libatk-bridge2.0-0 2.14.0-2 ii libatk1.0-0 2.14.0-1 ii libc62.19-18+deb8u3 ii libcairo21.14.0-2.1 ii libcanberra-gtk3-0 0.30-2.1 ii libcanberra0 0.30-2.1 ii libclutter-1.0-0 1.20.0-1 ii libcogl-pango20 1.18.2-3 ii libcogl201.18.2-3 ii libcroco30.6.8-3+b1 ii libdbus-glib-1-2 0.102-1 ii libecal-1.2-16 3.12.9~git20141128.5242b0-2+deb8u2 ii libedataserver-1.2-183.12.9~git20141128.5242b0-2+deb8u2 ii libgcr-base-3-1 3.14.0-2 ii libgdk-pixbuf2.0-0 2.31.1-2+deb8u4 ii libgirepository-1.0-11.42.0-2.2 ii libgjs0e [libgjs0-libmozjs-24-0] 1.42.0-1 ii libglib2.0-0 2.42.1-1 ii libgstreamer1.0-01.4.4-2 ii libgtk-3-0 3.14.5-1+deb8u1 ii libical1a1.0-1.3 ii libjson-glib-1.0-0 1.0.2-1 ii libmozjs-24-024.2.0-2 ii libmutter0e 3.14.4-1~deb8u1 ii libnm-glib4
Bug#740998: problems with rdnssd and network-manager both installed in jessie
El 11/10/15 a las 23:29, Dominic Hargreaves escribió: > On Sun, Oct 11, 2015 at 05:45:05PM +0100, Adam D. Barratt wrote: > > On Sun, 2015-10-11 at 16:50 +0100, Dominic Hargreaves wrote: > > > On Sat, Feb 14, 2015 at 01:36:05AM +, Debian Bug Tracking System > > > wrote: > > > > > > > ndisc6 (1.0.1-2) unstable; urgency=medium > > > > . > > > >* QA upload. > > > >* Set maintainer to the Debian QA Group (see #713004). > > > >* Add conflicts between rdnssd and network-manager (closes: #740998). > > > > > > This bug just hit me in Debian stable (as it happens, it appeared to > > > be a particularly severe form where /etc/resolv.conf was wiped out > > > altogether; perhaps some sort of race condition?) ... Hi, My stable powerpc machine got also hit by this. It was installed a couple of months ago, but maybe the problem appeared after my internet provider made some IPv6 changes. rdnssd's merge-hook just replaces /etc/resolv.conf with an empty file. Neither resolvconf nor network-manager were installed on the machine, so I don't think conflicting against network-manager solves the issue. Playing inside a temporal directory, the patch provided by Pierre at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767071#43 seems to work fine: http://git.remlab.net/gitweb/?p=ndisc6.git;a=blob_plain;f=rdnssd/merge-hook.in;hb=f7bd3662d2292e248173721d4760c03df39df666 Cheers, Santiago signature.asc Description: PGP signature
Bug#819553: ITP: r-cran-xml2 -- GNU R XML parser
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: r-cran-xml2 Version : 0.1.2 Upstream Author : Hadley Wickham * URL : https://cran.r-project.org/web/packages/xml2/ * License : MIT Programming Lang: GNU R Description : GNU R XML parser This GNU R package works with XML files using a simple, consistent interface. Built on top of the 'libxml2' C library. Remark: This package is part of a pyramid of dependencies for r-cran-treescape and will be maintained by the Debian Med team at svn://anonscm.debian.org/debian-med/trunk/packages/R/r-cran-xml2/trunk/
Bug#783290: Re-opened
Turns out the previous fix does not work out, as the time stamp was not actually passed to the (cmake generated) installation script. Now patched upstream [1], but not yet in 0.6.5(~rc1-1). Thomas pgpSzKORflOjA.pgp Description: OpenPGP digital signature
Bug#819554: RFA: libpam-ldap -- Pluggable Authentication Module for LDAP
Package: wnpp Severity: normal I request an adopter for the libpam-ldap package. I'm reviewing bugs of this package and will upload the newer version. The idea is keep the retrocompatibility.
Bug#819556: github-backup: JsonError "failed to parse field homepage: expected String, encountered Null"
Package: github-backup
Version: 1.20160207-1
Severity: normal
To reproduce:
github-backup GrahamCobb
Gives the errors:
github-backup: Failed to query github for repos:
JsonError "failed to parse field homepage: expected String, encountered Null on
the JSON: Array [Object (fromList [(\"homepage\",Null),(\"hooks_url\",String
\"https://api.github.com/repos/GrahamCobb/backup-humax/hooks\";),(\"blobs_url\",String
\"https://api.github.com/repos/GrahamCobb/backup-humax/git/blobs{/sha}\";),(\"ssh_url\",String
\"g...@github.com:GrahamCobb/backup-humax.git\"),(\"svn_url\",S
tring \"https://github.com/GrahamCobb/backup-humax\";),(\"clone_url\",String ...
JsonError "failed to parse field homepage: expected String, encountered Null on
the JSON: Array [Object (fromList [(\"homepage\",String
\"\"),(\"hooks_url\",String
\"https://api.github.com/repos/Ericsson/exchangecalendar/hooks\";),(\"blobs_url\",String
\"https://api.github.com/repos/Ericsson/exchangecalendar/git/blobs{/sha}\";),(\"ssh_url\",String
\"g...@github.com:Ericsson/exchangecalendar.git\"),(\"svn_url\",String
\"https://github.com/Ericsson/exchangecalendar\";), ...
JsonError "failed to parse field homepage: expected String, encountered Null on
the JSON: Array [Object (fromList [(\"homepage\",String
\"\"),(\"hooks_url\",String
\"https://api.github.com/repos/Ericsson/exchangecalendar/hooks\";),(\"blobs_url\",String
\"https://api.github.com/repos/Ericsson/exchangecalendar/git/blobs{/sha}\";),
...
JsonError "expected [a], encountered Object on the JSON: Object (fromList
[(\"documentation_url\",String
\"https://developer.github.com/v3\";),(\"message\",String \"Not Found\")])"
Note: the "failed to parse" errors each include a very long JSON dump, which is
truncated here in this report.
-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (900, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.4.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_IE.utf8, LC_CTYPE=en_IE.utf8 (charmap=UTF-8) (ignored: LC_ALL
set to en_IE.utf8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
Versions of packages github-backup depends on:
ii git 1:2.8.0~rc3-1
ii libc6 2.22-4
ii libffi6 3.2.1-4
ii libgmp10 2:6.1.0+dfsg-2
ii zlib1g1:1.2.8.dfsg-2+b1
github-backup recommends no packages.
github-backup suggests no packages.
-- no debconf information
Bug#819555: pcscd: cyberJack pp_a2 init failed with pcscd_1.8.16-1
Package: pcscd Version: 1.8.16-1 Severity: important 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 *** -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.5.0-towo.1-siduction-amd64 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages pcscd depends on: ii init-system-helpers 1.29 ii libc6 2.22-5 ii libccid [pcsc-ifd-handler]1.4.22-1 ii libifd-cyberjack6 [pcsc-ifd-handler] 3.99.5final.sp09-1 ii libpcsclite1 1.8.16-1 ii libudev1 229-3 ii lsb-base 9.20160110 pcscd recommends no packages. Versions of packages pcscd suggests: ii systemd 229-3 -- no debconf information Hallo after upgrading pcscd_1.8.15-1 to 1.8.16-1 my cardreader REINER SCT cyberJack does not work anymore. I can see this error journalctl -f Mär 30 14:29:43 siductionbox kernel: usb 3-2: new full-speed USB device number 8 using xhci_hcd Mär 30 14:29:44 siductionbox kernel: usb 3-2: New USB device found, idVendor=0c4b, idProduct=0401 Mär 30 14:29:44 siductionbox kernel: usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Mär 30 14:29:44 siductionbox kernel: usb 3-2: Product: cyberJack e-com(f) Mär 30 14:29:44 siductionbox kernel: usb 3-2: Manufacturer: Reiner-SCT Mär 30 14:29:44 siductionbox kernel: usb 3-2: SerialNumber: 0047339731 Mär 30 14:29:44 siductionbox mtp-probe[13616]: checking bus 3, device 8: "/sys/devices/pci:00/:00:14.0/usb3/3-2" Mär 30 14:29:44 siductionbox mtp-probe[13616]: bus: 3, device: 8 was not an MTP device Mär 30 14:29:45 siductionbox pcscd[9581]: CYBERJACK: Started Mär 30 14:29:45 siductionbox pcscd[9581]: readerfactory.c:1097:RFInitializeReader() Open Port 0x20 Failed (usb:0c4b/0401:libudev:0:/dev/bus/usb/003/008) Mär 30 14:29:45 siductionbox pcscd[9581]: 0223 readerfactory.c:372:RFAddReader() REINER SCT cyberJack pp_a2 (0047339731) init failed. Mär 30 14:29:45 siductionbox pcscd[9581]: 0042 hotplug_libudev.c:520:HPAddDevice() Failed adding USB device: REINER SCT cyberJack pp_a2
Bug#819523: squid3 in wheezy-backports has unmet dependencies
Luigi, Since this is in the amd64 package and wheezy-backports does not even contain the libraries mentioned I suspect this is due to the package binary being the one generated in your build environment for upload. Requesting a re-build on the normal amd64 buildd should resolve this. Amos
Bug#813027: uploaded in new queue
Hi, the deferred upload was rejected by dak, because of "unallowed Multi-arch: no tag" so I deleted that line, built again, checked lintian, signed and uploaded. build available here. http://debomatic-amd64.debian.net/distribution#experimental/libpng1.6/1.6.20-3/lintian cheers, G.
Bug#819530: transition: icu
On Wed, Mar 30, 2016 at 2:09 PM, Rene Engelhard wrote: > On Wed, Mar 30, 2016 at 07:38:58AM +0200, Laszlo Boszormenyi (GCS) wrote: >> Boost 1.58 -> successfully compiled LibreOffice 5.1.2~RC1. > > Including the tests? I did the tests in a chroot, without any shell environmental settings. If the tests are run automatically, then yes. Sorry, my computer is such slow I just started the building and left it alone for several hours (stopped all daemons and only the console was used). As far as I can remember, this time it was more quicker, built the debs after eleven hours or so. But I still have the build log somewhere, will check that and report back. > But then again, the broken help on the last transition and the crashes > in some other one before that were not catched by the tests either ;) > > I asked, noone tried with 57 yet for LO. That's why I would like to be extra safe - don't want to cause any trouble if you do any testing / transition in experimental already. >> May I proceed with the upload, targeting experimental first? > > Not from the RT, but... > > Well, uploading to experimental is fine anytime I think, that also has > the advantage that you already cleared NEW when this is supposed to start > in unstable. Sure. The first step would be to binNMU Boost 1.58 as itself is build-depends on ICU. > And people can try with experimental. Do you have a local test environment for LibreOffice for example? Say, some big and/or Chinese document to open and test? Regards, Laszlo/GCS
Bug#690676: IPv6 kernel filtering still broken in conntrackd 1.4.3 with kernel 4.4
Hi,
I can confirm that IPv6 kernel filtering is still broken in conntrackd
1.4.3 with Linux kernel 4.4.
The test is simple:
* configure a two node conntrackd cluster to sync connections
* configure IPv6 kernelspace filtering
* launch `conntrack -E' to see conntrack events in both nodes
* launch some IPv6 matching traffic, and see it syncing to the other node
* switch the config to userspace filtering
* launch some IPv6 matching traffic, the sync don't happen this time.
This is an example configuration in one of my nodes:
8<
Sync {
Mode NOTRACK {
DisableInternalCache on
DisableExternalCache on
}
TCP {
IPv4_address 10.0.0.201
IPv4_Destination_Address 10.0.0.202
Port 3780
Interface eth0
Checksum on
SndSocketBuffer 12492800
RcvSocketBuffer 12492800
}
Options {
ExpectationSync On
}
}
General {
Nice -20
Scheduler {
Type FIFO
Priority 99
}
Syslog on
LockFile /var/lock/conntrackd.lock
UNIX {
Path /var/run/conntrackd.sock
Backlog 20
}
NetlinkBufferSize 800
NetlinkBufferSizeMaxGrowth 8000
Filter From Kernelspace {
Address Ignore {
IPv4_address 127.0.0.1
IPv4_address 10.0.0.200
IPv4_address 10.0.0.201
IPv4_address 10.0.0.202
IPv6_address ::1
IPv6_address fe00::200
IPv6_address fe00::201
IPv6_address fe00::202
}
}
EventIterationLimit 10
}
8<
You can switch to userspace filtering by replacing the 'Kernelspace'
keyword and restarting the daemon:
8<
Filter From Userspace {
Address Ignore {
IPv4_address 127.0.0.1
IPv4_address 10.0.0.200
IPv4_address 10.0.0.201
IPv4_address 10.0.0.202
IPv6_address ::1
IPv6_address fe00::200
IPv6_address fe00::201
IPv6_address fe00::202
}
}
8<
So, I will dig a bit more to see if I can find the bug.
--
Arturo Borrero González
Bug#756397: Add or replace
I was wondering how to proceed with this bug. Does it make sense to replace the PTS link with the tracker link or should both be present? Regards, -- Frank Lichtenheld
Bug#819181: RFS: cl-asdf/3.1.7 - Another System Definition Facility
Hi, >The reason is that the upstream 'make clean' deletes debian/patches >completely. So without this, I'm not able to patch anything. how? I would suggest to patch the upstream make clean to not change source files. (note: I'm *suggesting* stuff without looking at the code, I don't know about the build system, feel free to disagree) >You mean it should be added to Build-Depends? I guess I have >misunderstood the description of b-d-i and thought that because quilt is >architecture-independent, it belongs in b-d-i. debian has two kind of builds: all and any. packages needed for the arch-i packages (resulting in an _all.deb) can go in b-d-i while the others needs to go in b-d. an example is doxygen, used for the common -doc package (arch:all), so you can have it in build-depends-indep at one condition: you will override the dh_auto_build-indep: target to build the doxygen documentation. overriding e.g. dh_auto_build: will trigger a "file not found" exception while building on a common architecture, where b-d-i aren't installed. (the reason is exactly to avoid Porters to have too many dependencies for their porting work). So, if quilt is used in target called by -arch and -indep steps, it will go in b-d dpkg-buildpackage -A dpkg-buildpackage -B should work both (and try to remove quilt and see if the arch:any gets built correctly). cheers, G.
Bug#819557: dphys-config: Stops with "failed entirely to retrieve file […] HTTP status 304, aborting" when wget >= 1.17 is used and the same source file is used twice
Package: dphys-config
Version: 20100216-1
Severity: normal
Tags: sid stretch patch
Consider a dphys-config.list file like this:
foo.conf:/etc/foo-23/
foo.conf:/etc/foo-42/
dphys-config tries twice to download the file "foo.conf" from the
configuration files repository with wget. In the past, "wget -N" noticed
that the file is already there ("Server file no newer than local file
`foo.conf' -- not retrieving"), but still logged a "200 OK" response
code ("HTTP request sent, awaiting response... 200 OK"). So dphys-config
saw the "200" and was happy with it.
But since version 1.17, wget uses If-Modified-Since headers with the
-N/--timestamping option and reports a "304 Not Modified" instead of the
previous "Server file no newer than local file `foo.conf' -- not
retrieving" message. The HTTP code "304" confuses dphys-config as of now
and it considers it an error and aborts.
The according patch seems trivial:
diff --git a/dphys-config b/dphys-config
index e8f8771..b65d47c 100755
--- a/dphys-config
+++ b/dphys-config
@@ -385,7 +385,7 @@ broken_net_wget_or_die () {
# especially as all 3 attemps failing will fall into below FATAL
${CMD_NOTE} "failed try ${TRY} to resolve server for URL ${URL}" >&2
${CMD_LOG_NOTE} "failed try ${TRY} to resolve server for URL ${URL}"
-elif ( [ "${HTTP_STAT}" = 200 ] || [ "${HTTP_STAT}" = 404 ] ) ; then
+elif ( [ "${HTTP_STAT}" = 200 ] || [ "${HTTP_STAT}" = 304 ] || [
"${HTTP_STAT}" = 404 ] ) ; then
# we managed to get a file, or there is no file, both are OK for us
return 0
else
I'll verify that the patch works as expected and then probably do an
upload of dphys-config with all the minor stuff which has accumulated in
the packaging git repository at https://github.com/isgphys/dphys-config
since the last upload.
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'),
(500, 'buildd-unstable'), (400, 'stable'), (110, 'experimental'), (1,
'experimental-debug'), (1, 'buildd-experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.2.0-trunk-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages dphys-config depends on:
ii wget 1.17.1-1+b1
dphys-config recommends no packages.
Versions of packages dphys-config suggests:
ii pciutils 1:3.3.1-1.1
-- Configuration Files:
/etc/dphys-config [Errno 2] No such file or directory: u'/etc/dphys-config'
Bug#819558: inkscape: hangs on startup
Package: inkscape Version: 0.48.5-3 Severity: normal Dear Maintainer, * What led up to the situation? Just trying to start Inkscape from Gnomeshell or commandline * What exactly did you do (or not do) that was effective (or ineffective)? The window comes up, but isn't responding to any input. Even closing is not possible. Just killing helps When running "strace inkscape", the last line displayed is a stat to a file on a different machine wich isn't acessible at the time. The file isn't related to inkscape in any way, it's just a textfile which had been opened some weeks ago across the network. -- System Information: Debian Release: 8.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages inkscape depends on: ii gconf-service 3.2.6-3 ii libaspell150.60.7~20110707-1.3 ii libatk1.0-02.14.0-1 ii libatkmm-1.6-1 2.22.7-2.1 ii libc6 2.19-18+deb8u3 ii libcairo2 1.14.0-2.1 ii libcairomm-1.0-1 1.10.0-1.1 ii libfontconfig1 2.11.0-6.3 ii libfreetype6 2.5.2-3+deb8u1 ii libgc1c2 1:7.2d-6.4 ii libgcc11:4.9.2-10 ii libgconf-2-4 3.2.6-3 ii libgdk-pixbuf2.0-0 2.31.1-2+deb8u4 ii libglib2.0-0 2.42.1-1 ii libglibmm-2.4-1c2a 2.42.0-1 ii libgnomevfs2-0 1:2.24.4-6+b1 ii libgomp1 4.9.2-10 ii libgsl0ldbl1.16+dfsg-2 ii libgtk2.0-02.24.25-3 ii libgtkmm-2.4-1c2a 1:2.24.4-1.1 ii libgtkspell0 2.0.16-1.1 ii liblcms2-2 2.6-3+b3 ii libmagick++-6.q16-58:6.8.9.9-5 ii libmagickcore-6.q16-2 8:6.8.9.9-5 ii libmagickwand-6.q16-2 8:6.8.9.9-5 ii libpango-1.0-0 1.36.8-3 ii libpangocairo-1.0-01.36.8-3 ii libpangoft2-1.0-0 1.36.8-3 ii libpangomm-1.4-1 2.34.0-1.1 ii libpng12-0 1.2.50-2+deb8u2 ii libpoppler-glib8 0.26.5-2 ii libpoppler46 0.26.5-2 ii libpopt0 1.16-10 ii librevenge-0.0-0 0.0.1-3 ii libsigc++-2.0-0c2a 2.4.0-1 ii libstdc++6 4.9.2-10 ii libwpg-0.3-3 0.3.0-3 ii libx11-6 2:1.6.2-3 ii libxml22.9.1+dfsg1-5+deb8u1 ii libxslt1.1 1.1.28-2+b2 pn python:any ii zlib1g 1:1.2.8.dfsg-2+b1 Versions of packages inkscape recommends: ii aspell 0.60.7~20110707-1.3 ii imagemagick8:6.8.9.9-5 ii libgnomevfs2-extra 1:2.24.4-6+b1 ii libimage-magick-perl [perlmagick] 8:6.8.9.9-5 ii libwmf-bin 0.2.8.4-10.3+deb8u1 ii perlmagick 8:6.8.9.9-5 ii pstoedit 3.62-2+b1 ii python-lxml3.4.0-1 ii python-numpy 1:1.8.2-2 ii transfig 1:3.2.5.e-4 Versions of packages inkscape suggests: pn dia | dia-gnome pn libsvg-perl pn libxml-xql-perl pn python-uniconvertor ii ruby 1:2.1.5+deb8u1 -- no debconf information
Bug#819559: mate-panel: segfault
Package: mate-panel Version: 1.8.1+dfsg1-3 Severity: minor Dear Maintainer, I find regularly messages about Mate panel in the logs : kmail kernel: [ 388.286096] mate-panel[6543]: segfault at 6 ip 7f564aef0505 sp 7ffee3327348 error 4 in libgobject-2.0.so.0.4200.1[7f564aebd000+51000] I set the status to "minor" as the panel runs flawlessly ... Regards JP P -- System Information: Debian Release: 8.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.5.0 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages mate-panel depends on: ii dconf-gsettings-backend [gsettings-backend] 0.22.0-1 ii libatk1.0-0 2.14.0-1 ii libc62.19-18+deb8u4 ii libcairo21.14.0-2.1+deb8u1 ii libcanberra-gtk0 0.30-2.1 ii libcanberra0 0.30-2.1 ii libdbus-1-3 1.8.20-0+deb8u1 ii libdbus-glib-1-2 0.102-1 ii libdconf10.22.0-1 ii libfontconfig1 2.11.0-6.3 ii libfreetype6 2.5.2-3+deb8u1 ii libgdk-pixbuf2.0-0 2.31.1-2+deb8u4 ii libglib2.0-0 2.42.1-1+b1 ii libgtk2.0-0 2.24.25-3+deb8u1 ii libice6 2:1.0.9-1+b1 ii libmate-desktop-2-17 1.8.1+dfsg1-3+deb8u1 ii libmate-menu21.8.0-5 ii libmate-panel-applet-4-1 1.8.1+dfsg1-3 ii libmateweather1 1.8.0-2 ii libpango-1.0-0 1.36.8-3 ii libpangocairo-1.0-0 1.36.8-3 ii libpangoft2-1.0-01.36.8-3 ii librsvg2-2 2.40.5-1 ii libsm6 2:1.2.2-1+b1 ii libstartup-notification0 0.12-4 ii libwnck222.30.7-2 ii libx11-6 2:1.6.2-3 ii libxau6 1:1.0.8-1 ii libxrandr2 2:1.4.2-1+b1 ii mate-desktop 1.8.1+dfsg1-3+deb8u1 ii mate-menus 1.8.0-5 ii mate-panel-common1.8.1+dfsg1-3 ii mate-polkit 1.8.0+dfsg1-4 ii menu-xdg 0.5 ii python 2.7.9-1 mate-panel recommends no packages. mate-panel suggests no packages. -- no debconf information
Bug#819555: pcscd: cyberJack pp_a2 init failed with pcscd_1.8.16-1
On Wed, 30 Mar 2016 14:34:05 +0200 Juergen Rehnen wrote: Package: pcscd Version: 1.8.16-1 Severity: important 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 *** The template is here to help file the bug report. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.5.0-towo.1-siduction-amd64 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages pcscd depends on: ii init-system-helpers 1.29 ii libc6 2.22-5 ii libccid [pcsc-ifd-handler]1.4.22-1 ii libifd-cyberjack6 [pcsc-ifd-handler] 3.99.5final.sp09-1 ii libpcsclite1 1.8.16-1 ii libudev1 229-3 ii lsb-base 9.20160110 pcscd recommends no packages. Versions of packages pcscd suggests: ii systemd 229-3 -- no debconf information Hallo after upgrading pcscd_1.8.15-1 to 1.8.16-1 my cardreader REINER SCT cyberJack does not work anymore. I can see this error journalctl -f Mär 30 14:29:43 siductionbox kernel: usb 3-2: new full-speed USB device number 8 using xhci_hcd Mär 30 14:29:44 siductionbox kernel: usb 3-2: New USB device found, idVendor=0c4b, idProduct=0401 Mär 30 14:29:44 siductionbox kernel: usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Mär 30 14:29:44 siductionbox kernel: usb 3-2: Product: cyberJack e-com(f) Mär 30 14:29:44 siductionbox kernel: usb 3-2: Manufacturer: Reiner-SCT Mär 30 14:29:44 siductionbox kernel: usb 3-2: SerialNumber: 0047339731 Mär 30 14:29:44 siductionbox mtp-probe[13616]: checking bus 3, device 8: "/sys/devices/pci:00/:00:14.0/usb3/3-2" Please generate a pcscd log as described in https://pcsclite.alioth.debian.org/pcsclite.html#support Bye -- Dr. Ludovic Rousseau
Bug#819555: pcscd: cyberJack pp_a2 init failed with pcscd_1.8.16-1
Package: pcscd Version: 1.8.16-1 Followup-For: Bug #819555 Hi this is the output of the log debuglog.c:289:DebugLogSetLevel() debug level=debug 0009 debuglog.c:310:DebugLogSetCategory() Debug options: APDU 0011 utils.c:82:GetDaemonPid() Can't open /var/run/pcscd/pcscd.pid: No such file or directory 0040 configfile.l:281:DBGetReaderListDir() Parsing conf directory: /etc/reader.conf.d 0007 configfile.l:315:DBGetReaderListDir() Skipping non regular file: . 0002 configfile.l:315:DBGetReaderListDir() Skipping non regular file: .. 0001 configfile.l:353:DBGetReaderList() Parsing conf file: /etc/reader.conf.d/libccidtwin 0022 pcscdaemon.c:567:main() pcsc-lite 1.8.16 daemon ready. 1832 hotplug_libudev.c:294:get_driver() Looking for a driver for VID: 0x1D6B, PID: 0x0002, path: /dev/bus/usb/003/001 0056 hotplug_libudev.c:294:get_driver() Looking for a driver for VID: 0x1D6B, PID: 0x0002, path: /dev/bus/usb/003/001 0054 hotplug_libudev.c:294:get_driver() Looking for a driver for VID: 0x0C4B, PID: 0x0401, path: /dev/bus/usb/003/008 0004 hotplug_libudev.c:433:HPAddDevice() Adding USB device: REINER SCT cyberJack pp_a2 0029 readerfactory.c:1066:RFInitializeReader() Attempting startup of REINER SCT cyberJack pp_a2 (0047339731) 00 00 using /usr/lib/pcsc/drivers/libifd- cyberjack.bundle/Contents/Linux/libifd-cyberjack.so 0795 readerfactory.c:951:RFBindFunctions() Loading IFD Handler 3.0 8709 readerfactory.c:1097:RFInitializeReader() Open Port 0x20 Failed (usb:0c4b/0401:libudev:0:/dev/bus/usb/003/008) 0007 readerfactory.c:372:RFAddReader() REINER SCT cyberJack pp_a2 (0047339731) init failed. 0002 readerfactory.c:605:RFRemoveReader() UnrefReader() count was: 1 0002 readerfactory.c:1117:RFUnInitializeReader() Attempting shutdown of REINER SCT cyberJack pp_a2 (0047339731) 00 00. 0001 readerfactory.c:988:RFUnloadReader() Unloading reader driver. 0034 hotplug_libudev.c:520:HPAddDevice() Failed adding USB device: REINER SCT cyberJack pp_a2 0132 hotplug_libudev.c:294:get_driver() Looking for a driver for VID: 0x1D6B, PID: 0x0002, path: /dev/bus/usb/003/001 0081 hotplug_libudev.c:294:get_driver() Looking for a driver for VID: 0x05E3, PID: 0x0610, path: /dev/bus/usb/003/003 0111 hotplug_libudev.c:294:get_driver() Looking for a driver for VID: 0x046D, PID: 0xC534, path: /dev/bus/usb/003/004 0108 hotplug_libudev.c:294:get_driver() Looking for a driver for VID: 0x046D, PID: 0xC534, path: /dev/bus/usb/003/004 0099 hotplug_libudev.c:294:get_driver() Looking for a driver for VID: 0x05E3, PID: 0x0610, path: /dev/bus/usb/003/003 0107 hotplug_libudev.c:294:get_driver() Looking for a driver for VID: 0x1D6B, PID: 0x0003, path: /dev/bus/usb/004/001 0074 hotplug_libudev.c:294:get_driver() Looking for a driver for VID: 0x1D6B, PID: 0x0003, path: /dev/bus/usb/004/001 0068 hotplug_libudev.c:294:get_driver() Looking for a driver for VID: 0x05E3, PID: 0x0612, path: /dev/bus/usb/004/002 0087 hotplug_libudev.c:294:get_driver() Looking for a driver for VID: 0x1D6B, PID: 0x0002, path: /dev/bus/usb/001/001 0050 hotplug_libudev.c:294:get_driver() Looking for a driver for VID: 0x1D6B, PID: 0x0002, path: /dev/bus/usb/001/001 0054 hotplug_libudev.c:294:get_driver() Looking for a driver for VID: 0x8087, PID: 0x0024, path: /dev/bus/usb/001/002 0070 hotplug_libudev.c:294:get_driver() Looking for a driver for VID: 0x1D6B, PID: 0x0002, path: /dev/bus/usb/002/001 0048 hotplug_libudev.c:294:get_driver() Looking for a driver for VID: 0x1D6B, PID: 0x0002, path: /dev/bus/usb/002/001 0053 hotplug_libudev.c:294:get_driver() Looking for a driver for VID: 0x8087, PID: 0x0024, path: /dev/bus/usb/002/002 -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.5.0-towo.1-siduction-amd64 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages pcscd depends on: ii init-system-helpers 1.29 ii libc6 2.22-5 ii libccid [pcsc-ifd-handler]1.4.22-1 ii libifd-cyberjack6 [pcsc-ifd-handler] 3.99.5final.sp09-1 ii libpcsclite1 1.8.16-1 ii libudev1 229-3 ii lsb-base 9.20160110 pcscd recommends no packages. Versions of packages pcscd suggests: ii systemd 229-3 -- no debconf information
Bug#819559: mate-panel: segfault
Control: forcemerge -1 816282 Hello JP! On 03/30/2016 03:25 PM, jp.po...@izzop.net wrote: > I find regularly messages about Mate panel in the logs : > kmail kernel: [ 388.286096] mate-panel[6543]: segfault at 6 ip > 7f564aef0505 sp 7ffee3327348 error 4 in > libgobject-2.0.so.0.4200.1[7f564aebd000+51000] Why are you reporting the same bug twice? Also, you are running a two-year-old version of MATE, so it might be advisable for you to test a more recent version and see if the problem persists. Merging those bug reports in any case. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#801177: Any updates on this?
Ran into this - it's an annoying bug on space constrained devices. What needs to be done for it to be fixed?
Bug#819181: RFS: cl-asdf/3.1.7 - Another System Definition Facility
> how? I would suggest to patch the upstream make clean to not change source > files. Yes, definitely! I have already submitted a patch upstream which has been merged: https://gitlab.common-lisp.net/asdf/asdf/commit/9b4f0d5ef957e92d1303c694027502c2a7a7ae96 But alas 3.1.7 is released without this change and I have to cope with it somehow. So this is a temporary workaround which should disappear in the next package version. > So, if quilt is used in target called by -arch and -indep steps, it will go > in b-d > > dpkg-buildpackage -A > dpkg-buildpackage -B > should work both (and try to remove quilt and see if the arch:any gets built > correctly). dpkg-buildpackage -A runs until the end and these are the last output lines > fakeroot debian/rules binary-indep > dh binary-indep >dh_testroot -i >dh_prep -i >dh_install -i >dh_installdocs -i >dh_installchangelogs -i >dh_installexamples -i >dh_installinfo -i >dh_lintian -i >dh_perl -i >dh_link -i >dh_compress -i >debian/rules override_dh_fixperms > make[1]: Entering directory '/home/darabi/wrk/asdf/asdf' > dh_fixperms > chmod 644 debian/cl-asdf/usr/share/common-lisp/source/cl-asdf/tools/asdf-tools > make[1]: Leaving directory '/home/darabi/wrk/asdf/asdf' >dh_installdeb -i >dh_gencontrol -i >dh_md5sums -i >dh_builddeb -i > dpkg-deb: building package 'cl-asdf' in '../cl-asdf_3.1.7-1_all.deb'. > dpkg-genchanges -A >../cl-asdf_3.1.7-1_all.changes > dpkg-genchanges: binary-only arch-indep upload (source code and arch-specific > packages not included) > dpkg-source --after-build asdf > dpkg-source: info: unapplying 002-make-clean-should-not-touch-debian.patch > dpkg-source: info: unapplying 001-fix-codespell-typos.patch > dpkg-buildpackage: binary-only upload (no source included) > signfile cl-asdf_3.1.7-1_all.changes Running dpkg-buildpackage -B gives the following error: > dpkg-buildpackage: source package cl-asdf > dpkg-buildpackage: source version 2:3.1.7-1 > dpkg-buildpackage: source distribution unstable > dpkg-buildpackage: source changed by Kambiz Darabi > dpkg-buildpackage: host architecture amd64 > dpkg-source --before-build asdf > dpkg-source: info: applying 001-fix-codespell-typos.patch > dpkg-source: info: applying 002-make-clean-should-not-touch-debian.patch > fakeroot debian/rules clean > dh clean >dh_testdir >dh_auto_clean > make -j1 clean > make[1]: Entering directory '/home/darabi/wrk/asdf/asdf' > Cleaning /home/darabi/wrk/asdf/asdf > rm -rf build/ LICENSE test/try-reloading-dependency.asd > test/hello-world-example asdf.lisp > rm -rf test/hello-world-example.exe test/mkcl_*.dll # needed only on > MS-Windows > make -C doc clean > make[2]: Entering directory '/home/darabi/wrk/asdf/asdf/doc' > rm -f asdf.cps asdf.log asdf.vr asdf.aux asdf.fn asdf.toc asdf.vrs asdf.cp > asdf.fns asdf.ky asdf.pg asdf.tp asdf.tps > rm -f asdf.html asdf.pdf asdf.info > rm -rf asdf/ asdf.t2d/ > make[2]: Leaving directory '/home/darabi/wrk/asdf/asdf/doc' > make[1]: Leaving directory '/home/darabi/wrk/asdf/asdf' >debian/rules override_dh_clean > make[1]: Entering directory '/home/darabi/wrk/asdf/asdf' > dh_quilt_patch > File series fully applied, ends at patch > 002-make-clean-should-not-touch-debian.patch > dh_clean > make[1]: Leaving directory '/home/darabi/wrk/asdf/asdf' > debian/rules build-arch > dh build-arch > fakeroot debian/rules binary-arch > dh binary-arch > dpkg-genchanges -B >../cl-asdf_3.1.7-1_amd64.changes > dpkg-genchanges: error: binary build with no binary artifacts found; cannot > distribute > dpkg-buildpackage: error: dpkg-genchanges gave error exit status 2 When I remove quilt from Build-Depends-Indep AND Build-Depends and run gbp buildpackage --git-ignore-new --git-upstream-tag='3.1.7' --git-debian-branch=master I get this error from lintian: E: cl-asdf source: missing-build-dependency-for-dh_-command dh_quilt_patch => quilt And this was the reason why I added quilt to debian/control in the first place.
Bug#814419: Fixed
Version: 1:7.7+14 I can confirm that the latest version is no longer breaking on me as well :) Bogdan this freemail appends ads, sorry: -- реклама --- Поторопись зарегистрировать самый короткий почтовый адрес @i.ua http://mail.i.ua/reg - и получи 1Gb для хранения писем
Bug#819181: RFS: cl-asdf/3.1.7 - Another System Definition Facility
Hi, >Yes, definitely! I have already submitted a patch upstream which has >been merged: > >https://gitlab.common-lisp.net/asdf/asdf/commit/9b4f0d5ef957e92d1303c694027502c2a7a7ae96 > >But alas 3.1.7 is released without this change and I have to cope with >it somehow. So this is a temporary workaround which should disappear in >the next package version. no, you can add the commit as a patch, patches are applied *before* dh_clean and removed after the build successful. $ dpkg-buildpackage dpkg-buildpackage: source package cl-asdf dpkg-buildpackage: source version 2:3.1.7-1 dpkg-buildpackage: source distribution unstable dpkg-buildpackage: source changed by Kambiz Darabi dpkg-buildpackage: host architecture amd64 dpkg-source --before-build cl-asdf-3.1.7 dpkg-source: info: applying fix-clean.patch fakeroot debian/rules clean dh clean dh_testdir dh_auto_clean make -j1 clean make[1]: Entering directory '/tmp/cl-asdf-3.1.7' Cleaning /tmp/cl-asdf-3.1.7 rm -rf build/ LICENSE test/try-reloading-dependency.asd test/hello-world-example asdf.lisp rm -rf test/hello-world-example.exe test/mkcl_*.dll # needed only on MS-Windows make -C doc clean make[2]: Entering directory '/tmp/cl-asdf-3.1.7/doc' rm -f asdf.cps asdf.log asdf.vr asdf.aux asdf.fn asdf.toc asdf.vrs asdf.cp asdf.fns asdf.ky asdf.pg asdf.tp asdf.tps rm -f asdf.html asdf.pdf asdf.info rm -rf asdf/ asdf.t2d/ I converted it as patch, removed the clean override, removed quilt from b-d-i. Success in my machine and in a real pbuilder clean environment. dpkg-buildpackage -A runs until the end and these are the last output lines > dpkg-genchanges -B >../cl-asdf_3.1.7-1_amd64.changes > dpkg-genchanges: error: binary build with no binary artifacts found; cannot > distribute > dpkg-buildpackage: error: dpkg-genchanges gave error exit status 2 seems legit, you don't have arch:any packages :) >E: cl-asdf source: missing-build-dependency-for-dh_-command dh_quilt_patch => >quilt Probably because you don't have arch:any packages. anyway, with your patch and no quilt it builds successfully. cheers, G.
Bug#433568: add vlan support
Hi, On Sat, 12 Mar 2016 13:49:57 +0100 Tom H wrote: > You don't need vlan; iproute2's ip can do it: > > ip link add link eth0 name vlan9 type vlan id 9 > or > ip link add link eth0 name eth0.9 type vlan id 9 > > I know that. vlan package is needed for the ifupdown hooks to parse vlan stanza from /etc/network/interfaces and hence configure vlan id. Or am I missing something? Regards, Dimitri.
Bug#819560: lintian: Lintian::Relation::implies_inverse doesn't handle << correctly
Package: lintian
Version: 2.5.42.1
$ perl -MLintian::Relation -E "say Lintian::Relation->new('foo (<<
1)')->implies_inverse('foo (<< 2)')"
1
This is incorrect...
--
Jakub Wilk
Bug#739947: Debian package version does not match PCSXR version
Although bug #795196 has not been closed , the latest version from upstream on Linux kernel 4.4 has no issues. Savestates are not a reason for not updating the version, as it is not part of the package. Savestates, memory cards, etc can be remade on demand, and as such, are a non-issue. The last Debian changleog for this package is dated Fri, 15 Jun 2012. Nearly 4 years ago! Please upgrade the package.
Bug#811073: RFS: lbfgsb/3.0-1 [ITP]
On Friday 25 March 2016 18:56:40 Gianfranco Costamagna wrote: > Hi, Hi, and thanks for the feedback! > something needs changes: > - std-version= 3.9.7 Yep, I'll update that. > - no watch file? I didn't make one since upstream's tarball (at least for the latest version) contains precompiled binaries, as well as a few files outside of any directory (a little tarbomb). It is my understanding that these need to be stripped out of the Debian source. Should I make a script for that and have uscan run it? Upstream has a very slow release cycle, and it is my impression that the library is more or less "done". Is a watch file still important? > - no sane build system, why are you building the library such way? There is no build system upstream. How should I best approach this issue? > you seem to use just two files in your library, why everything is dropped? The following source files are not used: - blas.f: We use the system libblas instead of this bundled copy. - driver*.f*: These are demonstration files for how to use the library, and are therefore not compiled. Should they be installed as example source files somewhere? - linpack.f: We use the system liblapack instead of this bundled LINPACK. See also debian/patches/replace-linpack-with-lapack.patch. That leaves only lbfgsb.f and timer.f, as you say. The former contains the entire substance of the library. > I don't think flags in rules are actually evaluated, because you > don't set them Thank you, I'll look into that. > - dbg package is useless now that we have ddbg automatic generation. Will fix. Thanks. Best, Gard
Bug#819418: fte: watch file broken
Hi all, Before upload this package as sponsor, I analized this sittuation. However, I did a misinterpretation about upstream versions and I uploaded the package. Thanks for fixing this issue. Regards, Eriberto 2016-03-29 21:53 GMT-03:00 Axel Beckert : > Hi, > >> > >* debian/watch: Create. >> > >> > This is contra-productive. :-( >> > >> > I'm sorry, what should i have write on the changelog instead? [...] >> >> I think by "contra-productive" Axel refers to the file creation itself >> (for the reasons he explained later), not the changelog entry :-) > > Yes. In retroperspective, it may have been ambiguous with regards to > my other comments. Sorry for that. > > Regards, Axel > -- > ,''`. | Axel Beckert , http://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#819181: RFS: cl-asdf/3.1.7 - Another System Definition Facility
> no, you can add the commit as a patch, patches are applied *before* dh_clean > and removed after the build successful. > > I converted it as patch, removed the clean override, removed quilt from b-d-i. > > Success in my machine and in a real pbuilder clean environment. This sounds great, but can you describe to a newbie how to convert it? Does git-buildpackage have an option to handle this? >>E: cl-asdf source: missing-build-dependency-for-dh_-command dh_quilt_patch => >>quilt > > > Probably because you don't have arch:any packages. > > anyway, with your patch and no quilt it builds successfully. I would like to perform the conversion to a non-quilt patch and re-upload the package (to learn something).
Bug#759886: [patch #8925] Support --clamp-mtime for binary reproducibility]
Hey! On Wed, Mar 30, 2016 at 10:32:08AM +0200, Guillem Jover wrote: > Yes, I was notified on IRC, and also saw your private mail. :) hehe, lol. Too much travelling and a new mail client… so I forgot :) but then, it's also good to have that in the BTS, as a matter of proper workflows… > In any > case there's not been a release yet AFAIK. Given that upstream said > that would happen in 7-10 days, I'll wait before commiting any change, > so that dpkg depends on released features that other downstreams can > use. And in any case there's still few things I want to wrap up before > the next dpkg release so that should give enough time. cool! very :) +thanks for the update…! -- cheers, Holger signature.asc Description: Digital signature
Bug#819194: dpkg-buildflags: please add normalizedebugpath to reproducible feature set
Hi, On Wed, Mar 30, 2016 at 02:19:02AM -0400, Daniel Kahn Gillmor wrote: > No one is arguing for dropping the build path from .buildinfo files. ok, cool. Thanks (to you both) for clarifying! -- cheers, Holger signature.asc Description: Digital signature
Bug#790690: Powermac G5 7,2 Nvidia GeForce 6800 GT graphics issues
2016-03-30 12:25 UTC+03.00, Mathieu Malaterre : > > Which kernel version are you using ? > Originally 3.16.0-4-powerpc64 (Jessie) Now 4.4.0-rc7-powerpc64 (Peter) Risto
Bug#795196: pcsxr crashes on x86-64 systems.
I'm using Linux #1 SMP Debian 4.4.6-1 (2016-03-17) AMD64 arch. I'm also using PCSXR version 1.9.93 from their website with no issues nor need for work-arounds.
Bug#790690: Powermac G5 7,2 Nvidia GeForce 6800 GT graphics issues
Control: notfound -1 3.16.0-4 Control: found -1 4.4.6-1 On Wed, Mar 30, 2016 at 4:17 PM, Risto Suominen wrote: > 2016-03-30 12:25 UTC+03.00, Mathieu Malaterre : >> >> Which kernel version are you using ? >> > Originally 3.16.0-4-powerpc64 (Jessie) > Now 4.4.0-rc7-powerpc64 (Peter) Thanks
