Bug#823631: [pkg-gnupg-maint] Bug#823631: please add cross build support for tilegx
On Fri, 6 May 2016 21:57, hel...@subdivi.de said: > there is another architecture around the corner. tilegx is about to be > added to dpkg (#823167). As usual, libgpg-error needs an update for it. > Chris Metcalf was kind enough to run a native build and I am attaching Applied to upstream. Thanks. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Bug#823630: [pkg-gnupg-maint] Bug#823630: please add cross build support for powerpcspe
On Fri, 6 May 2016 22:01, hel...@subdivi.de said: > Even though the powerpcspe architecture is around for some time already, > libgpg-error never got around adding cross build support for it. > Fortunately, libgpg-error is built as a Debian port already, so you can Applied to upstream. Thanks. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Bug#823488: [Python-modules-team] Bug#823488: python-ldap3: connection switch silently to anonymous bind if password is empty, failing auth
Simone Piccardi writes: > When creating a connection with the Connection object the code defaults to > AUTH_ANONYMOUS (doing so an anonymus bind) also when _only_ the password > is empty (not, as said by documentation, when both user and password are > empty). Hello, You appear to be reporting this bug against the version in Jessie. However the version in unstable is fixed. See https://github.com/cannatag/ldap3/issues/174 As a result, I don't think there is anything I can do with this report. You could try talking to the security team, however I don't think this would qualify as a security issue requiring a security fix. It might also qualify for an update as a point release. I would be nervous about changing the behaviour of a function in a stable release, and the potential of this change to break other applications that could potentially be relying on this (broken) behaviour. Regards -- Brian May
Bug#823599: task-polish-desktop: Please add firefox-l10n-pl to package recommendations
It is, but I don't know how to fix it. And I'm not sure if recommending Firefox-based browsers is enough, maybe it should be x-www-browser or similar package? task-gnome-desktop recommends iceweasel - why not epiphany-browser? 2016-05-07 7:11 GMT+02:00 Christian PERRIER : > Isn't this a more general issue with iceweasel|firefox in desktop > tasks ? > > To Mozilla package maintainers, since the change from iceweasel to > firefox, isn't there something we should change in tasksel tasks? > > (please keep all addresses CC'ed when answering, except /me as I'm > subscribed to tasksel bugs) >
Bug#823528: llvmopencl.so.5 should be packaged in it's own binary package
Le 05/05/2016 20:04, Matthias Klose a écrit : > Package: src:pocl > Version: 0.13-1 > > Found while looking at packaging 0.13 to be able to use llvm-3.8. > libpocl1 ships another library llvmopencl.so.5 in the package. > In 0.13, the llvmopencl soname is bumped to 7, which the libpocl > soname stays at 1. So you have to rename libpocl1 to e.g. > libpocl1-7 in any case, however why not packaging this library as > a separate binary? llvmopencl.so.5 is a private library ship in $libdir/pocl/ and not $libdir. Nothing but binaries from the pocl package itself must link to it (and, if I recall correctly, only the libpocl library itself link to it). So, I'm not convinced to the need of another library Debian package. Being in the same binary package ensure they upgrade at the same time and avoid to have to ensure the same things with dependencies. Upstream really managed them together and do not support using different version. Supporting it in Debian can be done (with more manpower) but I do not see any benefice. Do not hesitate to present other arguments as, for now, I'm really not convinced that "llvmopencl.so.5 should be packaged in it's own binary package" Regards, Vincent -- Vincent Danjean GPG key ID 0xD17897FA vdanj...@debian.org GPG key fingerprint: 621E 3509 654D D77C 43F5 CA4A F6AE F2AF D178 97FA Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html APT repo: deb http://people.debian.org/~vdanjean/debian unstable main
Bug#823658: ncurses-base: linux terminfo entry lacks the E3 capability
Package: ncurses-base Version: 6.0+20160319-1 Severity: normal The linux terminfo entry lacks the E3 capability, meaning that clear(1) does not clear the scrollback buffer. The capability was added to the linux3.0 terminfo entry, but we are not using this because it has some undesired side effects in non-Unicode locales, see the discussion in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=665959. I'm not quite sure what to do, but given that Linux kernels older than 3.0 are now unsupported, the terminfo entry for linux should certainly advertise this capability.
Bug#823659: openssh-server: Missing privilege separation directory: /var/run/sshd
Package: openssh-server Version: 1:7.2p2-5 Severity: normal Rebooted my computer today and found that "ssh.service" did not start: Missing privilege separation directory: /var/run/sshd "sudo mkdir /var/run/sshd" fixed the problem. IMHO the best way to fix this problem permanently would be to add "debian/openssh-server.ssh.tmpfile" file with the following content: d /var/run/sshd 0755 root root Thanks. --- System information. --- Architecture: amd64 Kernel: Linux 4.5.0-1-amd64 --- Package information. --- Depends (Version) | Installed ==-+-=== libc6(>= 2.17) | libcomerr2 (>= 1.01) | libgssapi-krb5-2(>= 1.12.1+dfsg-2) | libkrb5-3 (>= 1.6.dfsg.2) | libpam0g (>= 0.99.7.1) | libselinux1 (>= 1.32) | libssl1.0.0 (>= 1.0.1) | libwrap0 (>= 7.6-4~) | zlib1g(>= 1:1.1.4) | debconf (>= 0.5) | OR debconf-2.0| init-system-helpers (>= 1.18~) | openssh-client (= 1:6.6p1-7) | libpam-runtime(>= 0.76-14) | libpam-modules (>= 0.72-9) | adduser (>= 3.9) | dpkg(>= 1.9.0) | lsb-base (>= 4.1+Debian3) | procps | openssh-sftp-server| Recommends(Version) | Installed ===-+-=== xauth | 1:1.0.9-1 ncurses-term| 6.0+20160319-1 Suggests (Version) | Installed ===-+-=== ssh-askpass | 1:1.2.4.1-9 rssh| molly-guard | ufw | monkeysphere| 0.37-3 -- Best wishes, Dmitry Smirnov GPG key : 4096R/53968D1B --- The surest way to corrupt a youth is to instruct him to hold in higher esteem those who think alike than those who think differently. -- Friedrich Nietzsche signature.asc Description: This is a digitally signed message part.
Bug#823651: pbuilder: fails to make temp file - breaks
control: tag -1 moreinfo unreproducible On Sat, May 07, 2016 at 11:03:28AM +0900, Norbert Preining wrote: > the recent changes in /tmp handling seem to have made There have been no recent changes in /tmp handling. > cowbuilder/pbuilder unable to build any package: As you can guess problems like "pbuilder's unable to build any package" would be kind of spotted before releasing... > $ cowbuilder --build foobar.dsc > ... > This package was created automatically by pbuilder to satisfy the > build-dependencies of the package being currently built. > Depends: > dpkg-deb: building package 'pbuilder-satisfydepends-dummy' in > '/tmp/satisfydepends-aptitude/pbuilder-satisfydepends-dummy.deb'. > dpkg-deb: error: failed to make temporary file (control member): No such file > or directory > E: pbuilder-satisfydepends failed. This error is the same as the one reported in #576425, a report about pbuilder not working with libpam-tmpfs. Are you using libpam-tmpfs? If not please provide you /etc/pbuilderrc, ~/.pbuilderrc, a full log with --debug. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#822613: RFS: dynamic-graph/3.0.0-1
Control: tags -1 + moreinfo Your package has several lintian-detected problems of various severiuty, but the one about embedded jQuery is a blocker one. You will need to fix it before having a chance for the package to be uploaded. Please look into other issues as well. -- WBR, wRAR signature.asc Description: PGP signature
Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP]
On 07/05/16 02:35, lumin wrote:
Hi,
I've split the caffe-cpu package and the caffe-cuda package,
and I'd like to first handle the cpu version, leaving the CUDA
version pending at debian/science/caffe-contrib.
The updated cpu version has been uploaded to mentors:
https://mentors.debian.net/package/caffe
This update involves fix on multiarch, removal of caffe-cuda,
and removal of libproto.a .
However I found that hardening-no-fortify-functions is still
unsolved, and the upstream CMakeFiles.txt seems not to be
the trouble maker, as it contains this line
```
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fPIC -Wall")
```
and I really see the -D_FORTIFY_SOURCE=2 option added in the
verbose gcc command line.
On Tue, 2016-05-03 at 08:03 +, Gianfranco Costamagna wrote:
Hi,
set(CFLAGS ...) which should be replaced by set(CFLAGS $(CFLAGS) ...)
An upstream classic unfortunately.
as upstream I did this once, and the side effect was something weird.
when you run multiple times cmake .. the cflags gets appended multiple times,
so you might
end up in a really weird CMakeCache.txt and with really long build lines.
I'm not sure which way is the best one, but cmake should provide something
different from CFLAGS.
e.g.
CMAKE_C_FLAGS
CMAKE_C_FLAGS_RELEASE
CMAKE_C_FLAGS_DEBUG
CMAKE_EXE_LINKER_FLAGS
CMAKE_MODULE_LINKER_FLAGS
and so on.
that way they will be appended to current CFLAGS without having to override
them manually.
(thanks again for your nice reviews!)
g.
s/DEB_CPPFLAGS_MAINT_APPEND/DEB_CXXFLAGS_MAINT_APPEND in your d/rules.
Ghis
Bug#823660: initscripts: Restore locked root account access by using sulogin --force
Package: initscripts Version: 2.88dsf-59.3 Severity: important Dear Maintainer, Since sysvinit-utils/util-linux package versions shipped in Debian Stretch the sulogin program is now provided by util-linux (replacing previously supplied sulogin implementation from sysvinit-utils). The Debian sysvinit package used to carry a (buggy) patch against sulogin which allowed people to log in as root even when the root account is locked. (Neither sysvinit or util-linux upstreams for sulogin never supported it.) This patch was not carried over to the util-linux package when switching to util-linux sulogin implementation in Debian for various reasons primarily: - the patch had serious bugs - unconditionally handing out root shells where considered questionable for some usecases (eg. kiosk mode). After discussions with util-linux upstream a compromise was found to allow handing out root shell even with locked root account *only* when the --force (-e) option is specified. As far as I've been told the Debian installer creates a locked root account when people just press enter (without giving a password) at the root password prompt, which seems reasonably common among users. That means users has no way to be let in even when following instructions given by sulogin. The systemd package has been updated to pass the --force flag. The initscripts package (src:sysvinit) needs equivalent changes to restore the old status quo (and thus ignoring potential kiosk mode usecase problems -- kiosk mode users should alter their init scripts and remove the --force flag to be secure). Regards, Andreas Henriksson -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.5.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages initscripts depends on: ii coreutils 8.25-2 ii debianutils 4.7 ii lsb-base9.20160110 ii mount 2.28-1 ii sysv-rc 2.88dsf-59.3 ii sysvinit-utils 2.88dsf-59.3 Versions of packages initscripts recommends: ii e2fsprogs 1.43~WIP.2016.03.15-2 ii psmisc 22.21-2.1+b1 initscripts suggests no packages. -- no debconf information
Bug#822149: RFS: fed/0.951-17 [ITP]
Control: tags -1 + moreinfo Control: severity -1 wishlist On Thu, Apr 21, 2016 at 10:33:17AM -0400, Herbert Elwood Gilliland III wrote: > * URL : https://www.youtube.com/watch?v=vsc_NzxK67k Um, really? > fed (0.951-17) experimental; urgency=low Why experfimental? And you almost never should use anything other than 1 as the debian version of a new package. You should also drop the changelog entries for those older versions as they were never uploaded to the archive. > * Fixed version number to quiet lintian Huh. Now, some observations for the packaging itself: - d/copyright is almost totally wrong, the wrong license it contains is not its only problem - uscan says "Newest version of fed on remote site is 0.94a, local version is 0.951" - a quick look at configure.in and the Build-Depends: field tells me you didn't try to build this in a clean chroot - debian/patches/testy is something very wrong -- WBR, wRAR signature.asc Description: PGP signature
Bug#823661: owfs: Missing php bindings
Package: owfs Version: 3.1p1-4 Severity: normal PHP bindings have been disabled in 3.1p1-4. This bug is used to track the php7 support in swig (to reenable the bindings in owfs) Currently, Debian do not support php5 anymore and swig does not support php7 yet. Note that PHP users can still use the ownet PHP library to interface their PHP code with an owserver. Regards, Vincent -- System Information: Debian Release: stretch/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'squeeze-lts'), (500, 'oldstable-updates'), (500, 'oldoldstable'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armel, mipsel Kernel: Linux 4.5.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages owfs depends on: ii owfs-fuse 3.1p1-3 ii owftpd 3.1p1-3 ii owhttpd3.1p1-3 ii owserver 3.1p1-3 owfs recommends no packages. Versions of packages owfs suggests: ii owfs-doc 3.1p1-3 -- no debconf information
Bug#821314: RFS: traitlets -- Lightweight Traits-like package
On Sun, Apr 17, 2016 at 05:09:55PM +0200, Julien Puydt wrote: > It is packaged within the Debian Python Module Team repository here: > > Vcs-Git: > https://anonscm.debian.org/git/python-modules/packages/traitlets.git > Vcs-Browser: > https://anonscm.debian.org/cgit/python-modules/packages/traitlets.git There is no 4.2.1 there, the latest commits are ones for the git migration. -- WBR, wRAR signature.asc Description: PGP signature
Bug#823658: ncurses-base: linux terminfo entry lacks the E3 capability
On Sat, May 07, 2016 at 10:23:32AM +0200, Sven Joachim wrote: > Package: ncurses-base > Version: 6.0+20160319-1 > Severity: normal > > The linux terminfo entry lacks the E3 capability, meaning that > clear(1) does not clear the scrollback buffer. The capability was added > to the linux3.0 terminfo entry, but we are not using this because it has > some undesired side effects in non-Unicode locales, see the discussion > in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=665959. > > I'm not quite sure what to do, but given that Linux kernels older than > 3.0 are now unsupported, the terminfo entry for linux should certainly > advertise this capability. comparing linux to linux3.0. comparing booleans. comparing numbers. comparing strings. rmacs: '\E[10m', '^O'. sgr: '\E[0;10%?%p1%t;7%;%?%p2%t;4%;%?%p3%t;7%;%?%p4%t;5%;%?%p5%t;2%;%?%p6%t;1%;%?%p9%t;11%;m', '\E[0;10%?%p1%t;7%;%?%p2%t;4%;%?%p3%t;7%;%?%p4%t;5%;%?%p5%t;2%;%?%p6%t;1%;m%?%p9%t\016%e\017%;'. sgr0: '\E[0;10m', '\E[m\017'. smacs: '\E[11m', '^N'. E3: NULL, '\E[3J'. E3 is (as far as I know) harmless; the other features were the reason for reverting. When I checked a year or two ago, those were still relying on an unofficial patch (since the entire concept of SI/SO offends UTF-8 purists), and could be absent from various kernels. I'll see what I can learn, but adding E3 to "linux" might be the proper change. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net signature.asc Description: Digital signature
Bug#821907: RFS: fbless/0.2.3-1 ITP
Please rename README to README.ru, preferably upstream. Please consider using hyphenation data from hyphen-* packages. -- WBR, wRAR signature.asc Description: PGP signature
Bug#376841: please add clear_console to ncurses-bin
Control: tags -1 = wontfix Sorry for not having looked at this bug for a very long time. Am 05.07.2006 um 14:37 schrieb Matthias Klose: > Package: ncurses-bin > Severity: wishlist > Tags: patch > > clear_console is currently included in the bash package, used in > .bash_logout to clear the console and clear the buffer of the console. > It's not specific to bash and maybe should be added to the same > package where you find clear(1). It seems to me that clear_console is rather obsolete these days, because - The getty program (since util-linux 2.20) defaults to clearing the terminal, including the scrollback buffer. Systemd, while running getty with the --noclear argument, has a similar mechanism. So unless the sysadmin has modified /etc/inittab or systemd's getty*.service files, the console is cleared after the user logs out. - The clear(1) command (since the 20130622 ncurses patchlevel) also clears the scrollback buffer if the E3 capability is advertised in the terminfo description. While the linux terminfo entry currently lacks this capability (see #823658), it has been present in the xterm terminfo entry since ncurses-base 5.9+20140712-1. So instead of clear_console, you could simply run "TERM=xterm clear" from the .bash_logout file. Given these considerations, I don't see a good reason for adding clear_console to ncurses-bin. Cheers, Sven
Bug#823530: In favor of keeping the limit
In my opinion, the bugs here are in different packages: - Packages that provide a way for users to log in to the system, but don't create a user slice - Packages that provide services that operate using an unreasonable number of processes or threads, and can't be bothered to declare as much in the unit file The 512 limit is arbitrary, but a plausible point at which to say, if this isn't an interactive session and the service has not declared special needs, I should assume it's malfunctioning / fork bombing and shut it down. For comparison, RabbitMQ installations also regularly run into the "1024 open file descriptors" limit, but instead of abolishing that limit globally, it's been documented that the limit may need to be raised specifically for RabbitMQ for high-load installations. Regarding the user slice thing, maybe systemd should consider depending on libpam-systemd. It's currently quite easy to not install on custom installations, and not having user slices should break a number of things. (It's pulled in by ubuntu-standard on Ubuntu, but people like to remove that because it pulls in things of questionable usefulness.)
Bug#823415: cqrlog fails to build everywhere except on x86
It's already fixed in version 2.0.1 released a few minutes ago. 2016-05-04 16:30 GMT+02:00 Matthias Klose : > Package: src:cqrlog > Version: 2.0.0-1 > Severity: serious > Tags: sid stretch > > cqrlog fails to build everywhere except on x86. Please have a look at the > build logs. > > [...] > dUtils.pas(4334) Fatal: (10026) There were 2 errors compiling module, > stopping > Fatal: (1018) Compilation aborted > Error: /usr/bin/ppca64 returned an error exitcode > Error: (lazarus) Compile Project, Target: cqrlog: stopped with exit code 256 > ERROR: failed compiling of project /«PKGBUILDDIR»/src/cqrlog.lpi > Makefile:9: recipe for target 'cqrlog' failed > make[1]: *** [cqrlog] Error 2 > make[1]: Leaving directory '/«PKGBUILDDIR»' > dh_auto_build: make -j1 returned exit code 2 > -- http://HamQTH.com/ok2cqr http://ok2cqr.com https://www.cqrlog.com/
Bug#811418: fixed in swig 3.0.8-0
Hi, [...] > swig (3.0.8-0) experimental; urgency=medium [...] Could you please upload 3.0.8 to unstable? I've binding for python3.5 being broken with 3.0.7, rebuilding them with 3.0.8 fix the issue. Python 3.5 is now the default version now Cheers, Laurent Bigonville
Bug#823662: libinotify-dev: Please update to latest git.
Package: libinotify-dev Version: 20120419-1 Severity: normal Dear Maintainer, This release is really old (April 2012) and forked-daap now use libinotify but with the missing inotify_init1() function in 20120419-1, but this function is now in the latest git. https://github.com/dmatveev/libinotify-kqueue/search?utf8=%E2%9C%93&q=inotify_init1 So it is posssible to have new packages build from the latest git ? Christian -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: kfreebsd-i386 (i386) Kernel: kFreeBSD 10.1-0-686 Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages libinotify-dev depends on: ii libinotify0 20120419-1 libinotify-dev recommends no packages. libinotify-dev suggests no packages. -- no debconf information
Bug#821484: Bumping severity of PHP 7.0 transition bugs to serious
On 05/07/2016 12:48 AM, Sunil Mohan Adapa wrote: > I have applied the patch and marked that it closes the bug. However, > we need to address the issue of enabling php7 module for upgrading > users. I propose that we add 'a2enmod php7.0' to post-install. What do > you think? Yes, I think that would make sense. signature.asc Description: OpenPGP digital signature
Bug#823663: RFS: tio/1.6-1 [ITP] -- The simple TTY terminal I/O application
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "tie": Package name: tio Version : 1.6-1 Upstream Author : Martin Lund URL : http://tio.github.io/ License : GPL-2+ Section : comm It builds those binary packages: tio - Simple TTY terminal I/O application To access further information about this package, please visit the following URL: https://mentors.debian.net/package/tio Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/t/tio/tio_1.6-1.dsc More information about tio can be obtained from http://tio.github.io/. Cheers, sur5r
Bug#823465: dpkg: Won't run at all on i586 Pentium MMX due to illegal instruction
]] Pierre Ynard > Please tell me, what do I do with it?? Personally, I'd get some more recent hardware. Or run stable. In CPU performance terms, a Pentium MMX (at 200MHz) is about half to a third of the speed of the first-generation raspberry pi (underclocked to 700MHz). There's a limit to how long we're going to support old hardware. The last of the Pentium MMX-es was released in 1999-01. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Bug#769886: closed by Georges Khaznadar (fixed the path to icon.xpm)
Hi Eerste, is the new package in Sid (and shortly in Stretch) installable into a Jessie environment? It should work, since the dependency on python-wxgtk3.0 can be resolved in Jessie. If it is impossible, I should issue a package to jessie-backports, it may be available in a few weeks. Best regards, Georges. Eerste Laatste a écrit : > Bug as reported for python-wxglade in Jessie remains unchanged. > > > From: Debian Bug Tracking System > Sent: Saturday, April 23, 2016 4:42 PM > To: Eerste Laatste > Subject: Bug#769886 closed by Georges Khaznadar > (fixed the path to icon.xpm) > > This is an automatic notification regarding your Bug report > which was filed against the python-wxglade package: > > #769886: python-wxglade: Failed to load image from file > "/usr/lib/python2.7/dist-packages/wxglade/icons/icon.xpm" > > It has been closed by Georges Khaznadar . > > Their explanation is attached below along with your original report. > If this explanation is unsatisfactory and you have not received a > better one in a separate message then please contact Georges Khaznadar > by > replying to this email. > > > -- > 769886: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769886 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#604981: offlineimap: freezes while syncing debian.devel.general.2007
Control: tags -1 + moreinfo Hi Luca, On Thu, Nov 25, 2010 at 11:52PM, Luca Capello wrote: > I was (finally) moving to offlineimap to locally store all my emails, > but the initial sync frozen on a particular email from my 2007 archive > of debian-devel@. This raises the CPU usage to a point where my > laptop was automatically switched off to prevent thermal problems. > And this happens every time I tried to sync that single folder. Since this is a very old bug report, could you please test if this still occurs in the latest version of OfflineIMAP (v6.7.0+dfsg1)? Cheers, Ilias
Bug#618812: offlineimap: stacking connections to Exchange IMAP
Control: tags -1 + moreinfo Hi, Since this is a very old bug report, could you please test if this still occurs in the latest version of OfflineIMAP (v6.7.0+dfsg1)? Cheers, Ilias
Bug#823385: libutil-freebsd-dev: kinfo_getvmmap()
On Fri, May 06, 2016 at 10:59:48AM +0100, Steven Chamberlain wrote: > Hi, > > Jon Boden wrote: > > Please could you provide kinfo_getvmmap()? It is needed by gdb 7.11 > > (which is not in Debian yet but I'm porting at the moment as it was > > included with Ubuntu xenial) > > Thanks for this, it's great to get advance notice that we'll need it. > I'm enabling this in freebsd-libs/10.3 which will go into Debian > experimental until it is ready to enter sid. Excellent! Thank you > Do you plan to use the 10.3 userland in ubuntuBSD? Yes :-) -- Jon Boden ubuntuBSD -- The power of FreeBSD kernel with familiarity of Ubuntu OS! http://www.ubuntubsd.org/ -- https://twitter.com/ubuntuBSD
Bug#648195: Spordically hangs itself up on a futex
Control: tags -1 + moreinfo unreproducible Hi Martin, On Wed, Nov 09, 2011 at 03:25PM, martin f krafft wrote: > As of late, offlineimap hangs itself up sporadically. I have yet to > identify a pattern or capture a complete strace, but I am working on > it. I cannot reproduce this problem. Since this is a very old bug report, could you please test if this still occurs in the latest version of OfflineIMAP (v6.7.0+dfsg1)? Cheers, Ilias
Bug#816272: [Pkg-clamav-devel] Bug#816272: clamav-freshclam: logrotate errors out with "gzip: stdin: file size changed while zipping"
2016-05-06 23:56 GMT+02:00 Sebastian Andrzej Siewior < sebast...@breakpoint.cc>: > The question is now, what did you do to make the logrotate message go > away? Was it the upgrade to current stable or something else? Ok, now I've got it, sorry. The problem did occur until shortly before the update and not at all since, with no other changes that I'm aware of. So I'd say it was the update, yes. Cheers, C.
Bug#822130: Boost 1.55 to be removed; your attention required
On Sat, Apr 30, 2016 at 3:39 PM, Andreas Beckmann wrote: > On Thu, 21 Apr 2016 07:45:34 -0500 (CDT) "Steve M. Robbins" > wrote: >> Boost 1.55 has not built correctly since the GCC 5 introduction in July 2015 >> and I plan >> to ask for its removal from unstable very shortly. It has already been >> removed from >> testing. >> >> The package mongodb appeared on a list of reverse dependencies generated >> using 'dak rm -Rn boost1.55' (see below). This bug is to request an >> upload with updated boost dependencies. >> >> If your package build-depends on the default boost, then a simple rebuild >> will suffice. > > This package has stale binaries due to FTBFS on these two architectures: > >> mongodb: mongodb-clients [hurd-i386 kfreebsd-i386] >> mongodb-server [hurd-i386 kfreebsd-i386] > > I'd recommend this: > > Control: reassign -1 ftp.debian.org > Control: severity -1 normal > Control: retitle -1 RM: mongodb [hurd-i386 kfreebsd-i386] -- RoM; FTBFS, > depends on boost 1.55 Sorry for the slow reaction. The FTBFS reason is the package test case. It's threaded and the sequence is confused by the file timestamp resolution of Hurd and kFreeBSD architectures. It's one second only (Linux has millisecond resolution). Question is, how should it be handled? Disable self-tests, ignore the results or maybe remove mongodb from the mentioned architectures? Regards, Laszlo/GCS
Bug#823664: debsecan: reports new and available kernel security updates that, well, aren't
Package: debsecan Version: 0.4.17 Severity: normal Hi, the nightly e-mail report lists both "new security updates" and "available security updates" for linux-image-3.16.0-4-amd64, with multiple issues each. However, aptitude insists everything is current. At first I thought, something's just temporarily out of sync, but it's been doing it for days now, so maybe something is amiss. Cheers, Christian chris@crabtree:~$ LANG=C apt-cache policy linux-image-3.16.0-4-amd64 linux-image-3.16.0-4-amd64: Installed: 3.16.7-ckt25-2 Candidate: 3.16.7-ckt25-2 Version table: *** 3.16.7-ckt25-2 0 500 http://ftp.at.debian.org/debian/ jessie-updates/main amd64 Packages 100 /var/lib/dpkg/status 3.16.7-ckt25-1 0 500 http://ftp.at.debian.org/debian/ jessie/main amd64 Packages 3.16.7-ckt20-1+deb8u4 0 500 http://security.debian.org/ jessie/updates/main amd64 Packages chris@crabtree:~$ uname -a Linux crabtree 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08) x86_64 GNU/Linux -- System Information: Debian Release: 8.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages debsecan depends on: ii debconf [debconf-2.0] 1.5.56 ii python 2.7.9-1 ii python-apt 0.9.3.12 Versions of packages debsecan recommends: ii cron 3.0pl1-127+deb8u1 ii nullmailer [mail-transport-agent] 1:1.13-1 debsecan suggests no packages. -- debconf information: * debsecan/source: * debsecan/report: true * debsecan/suite: jessie * debsecan/mailto: root
Bug#823663: RFS: tio/1.6-1 [ITP] -- The simple TTY terminal I/O application
Control: owner -1 ! * Jakob Haufe , 2016-05-07, 12:04: https://mentors.debian.net/debian/pool/main/t/tio/tio_1.6-1.dsc As promised, I will look into this. -- Jakub Wilk
Bug#689921: offlineimap: socket error "Connection reset by peer" triggers python exception and exit
Control: tags -1 + moreinfo
Hi Jonathan,
On Mon, Oct 08, 2012 at 11:47AM, Jonathan Nieder wrote:
> Hi again,
>
> Jonathan Nieder wrote:
>
> > From today's offlineimap sync:
> [...]
> > | OfflineImapError: Server 'imap.gmail.com' closed connection, error on
> > SELECT '[Gmail]/All Mail'. Server said: command: EXAMINE => socket error:
> > - [Errno 104] Connection reset by peer
>
> Here's another uncaught OfflineImapError. I'll be happy to file a
> separate bug for it if that's useful --- just say the word.
>
[...]
>
> | File "/usr/lib/python2.7/dist-packages/offlineimap/imaplibutil.py", line
> 63, in select
> | raise OfflineImapError(errstr, severity)
> | OfflineImapError: Error SELECTing mailbox '[Gmail]/All Mail', server reply:
> | ('NO', ['System error (Failure)'])
These seem to be two different errors. Since this is a very old bug
report, could you please test if these still occur in the latest version
of OfflineIMAP (v6.7.0+dfsg1)?
Cheers,
Ilias
Bug#823465: dpkg: Won't run at all on i586 Pentium MMX due to illegal instruction
On Sat, May 07, 2016 at 02:42:37AM +0200, Pierre Ynard wrote: > That's not the idea I'd like to have about Debian. If I wanted > a distro where unstable is broken and unusable, I would have installed > long ago. I'm afraid there's not enough people who care about 586 enough to maintain it. And the bad decision of i386 to stick to a single arch during its whole life makes it hard to do so on debian-ports. Compare with ARM: there's arm armel armhf arm64 arm32(arm64ilp32) -- it frequently refreshes the ABI to make use of new CPU features, which also makes it easy to keep old compat without forcing new processors to stay with the lowest common denominator. > What do I do with my i586 system running unstable of last week? Drop it > into a tub of water, just like i586 support is getting dropped? That's > going to cause way more downtime than simply running unstable in > production. > > Please tell me, what do I do with it?? My recommendation would be going to jessie[1], it has whole four years of support left. Anything you need from unstable can be backported. After those four years you can reconsider, in the unlikely case your machine will be still alive. That's four more years than ia64 guys got. Unlike 586's half the speed of first-gen RasPi, ia64 machines can be pretty beefy -- new ones even are still being manufactured. > My "complaint" against unstable is valid. Typical Debian bugs don't > (or at least shouldn't) wait for the stable release to get fixed. I > don't see why you retitled this copy of the bug, since it described the > situation accurately. i586 users running unstable are getting their > system broken, with no obvious way to handle it. Maybe I'm the only such > user and you don't care, then at least have the decency to wontfix me. What kind of solution would you propose? We can't exactly add preinst guards to every single package. The only package that's depended on by (almost) all compiled code is libc6, but because of symbols handling the dependency is usually libc6 (>= 2.15) or such rather than (>= 2.22-7). Meow! [1]. Easiest way to downgrade: put into /etc/apt/preferences a pin for jessie with priority above 1000, then dist-upgrade. -- How to exploit the Bible for weight loss: Pr28:25: he that putteth his trust in the ʟᴏʀᴅ shall be made fat.
Bug#823665: util-linux breaks debootstrap
Package: util-linux Version: 2.28-2 Severity: grave User: helm...@debian.org Usertags: rebootstrap Hi, debootstrap sid just broke. debootstrap.log ends with: | Setting up util-linux (2.28-2) ... | update-alternatives: using /bin/more to provide /usr/bin/pager (pager) in auto mode | insserv: Service mountdevsubfs has to be enabled to start service hwclock | insserv: exiting now! | update-rc.d: error: insserv rejected the script header | dpkg: error processing package util-linux (--configure): | subprocess installed post-installation script returned error exit status 1 | dpkg: systemd-sysv: dependency problems, but configuring anyway as you requested: | systemd-sysv depends on systemd. | | Setting up systemd-sysv (229-5) ... | dpkg: e2fsprogs: dependency problems, but configuring anyway as you requested: | e2fsprogs depends on util-linux (>= 2.15~rc1-1); however: | Package util-linux is not configured yet. | | Setting up e2fsprogs (1.43~WIP.2016.03.15-2) ... | dpkg: sysvinit-utils: dependency problems, but configuring anyway as you requested: | sysvinit-utils depends on util-linux (>> 2.28-2~); however: | Package util-linux is not configured yet. | | Setting up sysvinit-utils (2.88dsf-59.4) ... | dpkg: systemd: dependency problems, but configuring anyway as you requested: | systemd depends on util-linux (>= 2.27.1); however: | Package util-linux is not configured yet. | | Setting up systemd (229-5) ... | Created symlink /etc/systemd/system/getty.target.wants/getty@tty1.service, pointing to /lib/systemd/system/getty@.service. | Created symlink /etc/systemd/system/multi-user.target.wants/remote-fs.target, pointing to /lib/systemd/system/remote-fs.target. | Created symlink /etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service, pointing to /lib/systemd/system/systemd-timesyncd.service. | Initializing machine ID from random generator. | Adding group `systemd-journal' (GID 101) ... | Done. | Setting up sysv-rc (2.88dsf-59.4) ... | Setting up initscripts (2.88dsf-59.4) ... | Running in chroot, ignoring request. | invoke-rc.d: policy-rc.d denied execution of start. | Setting up init (1.33) ... | Processing triggers for libc-bin (2.22-7) ... | Errors were encountered while processing: | util-linux Helmut
Bug#823418: Info received (Bug#823418: exim4: Since the last update, it seems like some messages are rejected after DATA)
Control: tags -1 pending
On 2016-05-05 Marc Haber wrote:
[...]
> Andreas, we should not have any deny stanza in any ACL without an
> explicit message.
I have just fixed to long-line-acl in that respect, the only remaining
ones without message are these:
deny
!acl = acl_local_deny_exceptions
senders = ${if exists{CONFDIR/local_sender_callout}\
{CONFDIR/local_sender_callout}\
{}}
!verify = sender/callout
deny
!acl = acl_local_deny_exceptions
recipients = ${if exists{CONFDIR/local_rcpt_callout}\
{CONFDIR/local_rcpt_callout}\
{}}
!verify = recipient/callout
I am not sure, but I think these provide useful reject messages on their
own, though.
cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
Bug#823527: tmux: Terminal bell not shown in status line
> > Did you have both symbols before version 2.2? > > Yes. And actually I have both symbols in Debian stable, where I run > tmux version 2.2-1~bpo8+1 from backports. Also, I checked with > someone running Debian unstable, and they get also both symbols. My fault. I didn’t restart the server after updating. The activity symbol supersedes the bell symbol also in Debian stable. I upgraded to version 2.3~git20160506-1 and have again only one symbol. A downgrade to version 1.9-6 gave me again both symbols. (I couldn’t check for version 2.1 since the deb file is no longer on the server.) I have no idea what is going on … Best, Marcel
Bug#823530: systemd 228 reduced maximum number of tasks in a cgroup to 512 by default
affects 823530 ruby2.3 affects 823530 openexr thanks On Fri, 6 May 2016, Antonio Terceiro wrote: > Will every package need to start declaring higher limits explicitly? I also would like to know the answer for that question. How does a package which needs a higher limit to build is supposed to override this? The above two packages FTBFS for me on stretch and the problem goes away by setting "DefaultTasksMax=infinity". But we don't have anything like "Build-Depends: DefaultTasksMax >= 1024". I'm using a hand-made autobuilder which is triggered by cron, asks a server for a package to build and uses sbuild to build the package. Should I override this for the cron service only? Thanks.
Bug#623062: #623062: terminator: High memory usage
Hi, Here's what I see with a freshly launched copy of Terminator 0.97-4 on my jessie system: dilinger 32148 0.3 1.4 636628 55928 pts/2Sl+ 04:07 0:01 /usr/bin/python /usr/bin/terminator That's not as high as the original bug report, but 55M is still quite significant for a terminal. Compare that to a freshly launched mate-terminal: dilinger 32678 3.3 0.5 471120 23416 pts/8Sl 04:20 0:00 mate-terminal Or xfce4-term: dilinger 968 3.6 0.5 403060 23136 ?Sl 04:22 0:00 xfce4-terminal So more than twice as much for terminator versus those other terms..
Bug#817005: RFS: aseqjoy/0.0.1-1 [ITP]
On Fri, May 06, 2016, Gianfranco Costamagna wrote: <..> > I would appreciate however a new tarball, because I don't like having to tell > ftpmasters > where to look in the mail list for the license change. OK, to settle this I created a new aseqjoy release, that should remove all license ambiguities. http://terminatorx.org/files/aseqjoy-0.0.2.tar.gz Hope this helps, Regards, Alex -- http://lisas.de/~alex
Bug#823666: Intel Matrix RAID 5
Package: Installer Version: 1 no support for Intel Matrix RAID 5, while Mint, Ubuntu, Suse have it. good luck asles On Fri, Apr 22, 2016, at 11:36 AM, Debian Bug Tracking System wrote: > Your message didn't have a Package: line at the very first line of the > mail body (part of the pseudo-header), or didn't have a Package: line > at all. Unfortunatly, this means that your message has been ignored > completely. > > Without this information we are unable to categorise or otherwise deal > with your problem report. Please _resubmit_ your report to > sub...@bugs.debian.org and tell us which package the > report is for. For help, check out > http://www.debian.org/Bugs/Reporting. > > Your message was dated Fri, 22 Apr 2016 11:33:53 -0700 and had > message-id > <1461350033.415309.586889281.2afe7...@webmail.messagingengine.com> > and subject Intel Matrix RAID 5. > The complete text of it is attached to this message. > > If you need any assistance or explanation please contact > ow...@bugs.debian.org and include the the attached > message. > > If you didn't send the attached message (spam was sent forging your > from address), we apologize; please disregard this message. > > -- > -1: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=-1 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems > Email had 1 attachment: > + Intel Matrix RAID 5 > 3k (message/rfc822) -- http://www.fastmail.com - Same, same, but different...
Bug#823553: openexr: FTBFS in testing: fork: Resource temporarily unavailable
severity 823553 important thanks This problem happens when running stretch, including the kernel in stretch. The problem goes away by setting "DefaultTasksMax=infinity" in /etc/systemd/system.conf. Related bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=823530 I'm downgrading this for now because it's not clear which package is to blame. But even if this ends up being a bug in systemd, I wonder why does this package need to simulate a nearly-fork-bomb to ensure that the program built ok. Thanks.
Bug#823668: RFS: twofish/0.3-5
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor of my package "twofish": Package name: twofish Version : 0.3-5 Upstream Author : Niels Ferguson URL : extinct License : liberal, demanding only copyright message Section : libdevel It builds two binary packages: libtwofish-dev - Niels Ferguson's Twofish cryptographic algorithm library libtwofish0- Niels Ferguson's Twofish cryptographic library -- runtime package Further information is available at https://mentors.debian.net/package/twofish The packaging is accessible in a standard manner: dget -x https://mentors.debian.net/debian/pool/main/t/twofish/twofish_0.3-5.dsc Changes since last upload are: * Step Standards-Version to 3.9.8, no changes. * Use debhelper in compatibility level 9. * debian/control: Use HTTPS transport for Vcs-Browser. * debian/copyright: Update my contribution including 2016. Rename license of packaging files, avoiding a name in duplicate. * debian/libtwofish0.lintian-overrides: Delete unused entry. * debian/libtwofish0.triggers: New file. * debian/libtwofish-dev.lintian-overrides: Delete unused entry. * debian/rules: Activate immediate bindings in so-library. Regards, Mats Erik Andersson
Bug#823667: transition: poppler 0.42
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi, I would like to ask a slot for a Poppler 0.42.0 transition. Currently there is Poppler 0.42.0 in experimental already. This transition impacts the existing poppler libraries in the following ways: - libpoppler57 → libpoppler60 Below it is a list of sources which are touched by the transition, and their situation, sorted by solutions: Sources that compile fine, and can be binNMU'ed: boomaga cups-filters gambas3 gdal gdcm inkscape ipe-tools libreoffice pdf2djvu pdf2htmlex popplerkit.framework texlive-bin texworks xpdf Sources that currently FTBFS: * calligra FTBFS for other reasons, not in testing already (can be ignored) Other cases: * derivations This source builds a libpoppler-based utility application which is only used during the build to generate other data, and no trace of that application are left in the resulting arch:all package. A change in poppler-glib 0.39 is the removal of an unused enum; this so far impacted only two sources: - ruby-gnome2 (#812677, fixed) - python-poppler (#812680) OTOH, this issue does not directly affect the libpoppler transition. I grouped all the bugs mentioned above (even the solved ones) with the following usertag: https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=p...@debian.org;tag=poppler-0.39 https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=p...@debian.org;tag=poppler-0.40 https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=p...@debian.org;tag=poppler-0.42 Ben file: title = "poppler 0.42"; is_affected = .depends ~ "libpoppler57" | .depends ~ "libpoppler60"; is_good = .depends ~ "libpoppler60"; is_bad = .depends ~ "libpoppler57"; Thanks, -- Pino
Bug#823669: transition: ctemplate 2.3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi, I would like to ask a slot for a transition for ctemplate 2.3. ctemplate 2.3, already in experimental and building fine everywhere, bumped SONAME from libctemplate2 to libctemplate3. The transition involves the following sources: kraft mysql-workbench all of them build fine with the new ctemplate. Ben file: title = "ctemplate"; is_affected = .depends ~ "libctemplate2v5" | .depends ~ "libctemplate3"; is_good = .depends ~ "libctemplate3"; is_bad = .depends ~ "libctemplate2v5"; Thanks, -- Pino
Bug#820622: linux-image-4.5.0-trunk-armmp-lpae: raspberry pi 2: smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
On Tue, 2016-05-03 at 09:13 -0700, Vagrant Cascadian wrote: > On 2016-05-02, Vagrant Cascadian wrote: > > > > On 2016-05-02, Ben Hutchings wrote: > > > > > > On Sun, 2016-05-01 at 18:20 -0700, Vagrant Cascadian wrote: > > > > > > > > On 2016-04-28, Ben Hutchings wrote: > > > > > > > > > > Could you test with turbo_mode re-enabled and with this patch applied? > > > > > > > > > > Also could you test network receive throughput (e.g. with netperf -t > > > > > TCP_STREAM, sending *to* the RPi) in these three different > > > > > configurations: > > > > Ok, if I understood you correctly... > > > > > > > > Installed netperf on another machine, and ran: > > > > > > > > netperf -t TCP_STREAM 10.0.0.50 > > > That is not correct syntax; you need to put a -H before the IP address. > > Ok. Never used netperf before... will try again! > Ok, this time with: > > netperf -l 60 -t TCP_STREAM -H 10.0.0.50 > > 4.5.2-1, with turbo disabled: > > MIGRATED TCP STREAM TEST from 0.0.0.0 () port 0 AF_INET to 10.0.0.50 () > port 0 AF_INET : demo > Recv SendSend > Socket Socket Message Elapsed > Size SizeSize Time Throughput > bytes bytes bytessecs.10^6bits/sec > > 87380 16384 1638460.04 93.95 Interesting - it's very close to saturating the link even without turbo. (The maximum possible TCP throughput over and Ethernet with standard MTU is about 94% of the underling bit rate.) > 4.5.2-1, with turbo enabled: > > MIGRATED TCP STREAM TEST from 0.0.0.0 () port 0 AF_INET to 10.0.0.50 () > port 0 AF_INET : demo > Recv SendSend > Socket Socket Message Elapsed > Size SizeSize Time Throughput > bytes bytes bytessecs.10^6bits/sec > > 87380 16384 1638460.03 94.15 > > > 4.5.2, patched with turbo enabled: > > MIGRATED TCP STREAM TEST from 0.0.0.0 () port 0 AF_INET to 10.0.0.50 () > port 0 AF_INET : demo > Recv SendSend > Socket Socket Message Elapsed > Size SizeSize Time Throughput > bytes bytes bytessecs.10^6bits/sec > > 87380 16384 1638460.04 94.15 So the patch doesn't seem to hurt performance at all. From your previous mail: > For what it's worth, the patched driver did still appear to eventually > generate the error logs reported: > > smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped > > So at best, it reduces the problem, rather than solving it. I think the basic problem is you're giving this machine more tasks than will comfortably fit in its memory, added to which the swap device is slow (or maybe you disabled swap?). If this patch reduces the risk of failed buffer allocations then I think it's still a win. Ben. -- Ben Hutchings Editing code like this is akin to sticking plasters on the bleeding stump of a severed limb. - me, 29 June 1999 signature.asc Description: This is a digitally signed message part
Bug#823426: asedriveiiie: FTBFS: install: cannot stat 'libASEDriveIIIe-USB.so': No such file or directory
Hello, I can't reproduce the problem on a freshly upgraded sid system. Your log contains a strange error: /usr/bin/ld: cannot find /lib/ /usr/bin/ld: cannot find s/libusb-0.1.so.4.4.4 collect2: error: ld returned 1 exit status Maybe the problem is on your build system? Do you have the package libusb-dev correctly installed? Bye Le 04/05/2016 à 18:16, Chris Lamb a écrit : Source: asedriveiiie Version: 3.7-5 Severity: serious Justification: fails to build from source User: reproducible-bui...@lists.alioth.debian.org Usertags: ftbfs X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org Dear Maintainer, asedriveiiie fails to build from source in unstable/amd64: [..] dh_testdir dh_testroot dh_prep dh_testdir dh_testroot dh_install dh_installdocs dh_installchangelogs dh_compress dh_fixperms dh_installdeb dh_gencontrol dh_md5sums dh_builddeb dpkg-deb: building package 'asedriveiiie-build-deps' in '../asedriveiiie-build-deps_3.7-5_all.deb'. The package has been created. Attention, the package has been created in the current directory, not in ".." as indicated by the message above! Selecting previously unselected package asedriveiiie-build-deps. (Reading database ... 23072 files and directories currently installed.) Preparing to unpack asedriveiiie-build-deps_3.7-5_all.deb ... Unpacking asedriveiiie-build-deps (3.7-5) ... Reading package lists... Building dependency tree... Reading state information... Correcting dependencies... Done The following additional packages will be installed: libpcsclite-dev libpcsclite1 libusb-dev pkg-config Suggested packages: pcscd The following NEW packages will be installed: libpcsclite-dev libpcsclite1 libusb-dev pkg-config 0 upgraded, 4 newly installed, 0 to remove and 0 not upgraded. 1 not fully installed or removed. Need to get 229 kB of archives. After this operation, 717 kB of additional disk space will be used. Get:1 http://httpredir.debian.org/debian sid/main amd64 libusb-dev amd64 2:0.1.12-29 [36.9 kB] Get:2 http://httpredir.debian.org/debian sid/main amd64 libpcsclite1 amd64 1.8.16-1 [56.2 kB] Get:3 http://httpredir.debian.org/debian sid/main amd64 libpcsclite-dev amd64 1.8.16-1 [73.1 kB] Get:4 http://httpredir.debian.org/debian sid/main amd64 pkg-config amd64 0.29-4 [62.5 kB] Fetched 229 kB in 0s (19.4 MB/s) Selecting previously unselected package libusb-dev. (Reading database ... (Reading database ... 5% (Reading database ... 10% (Reading database ... 15% (Reading database ... 20% (Reading database ... 25% (Reading database ... 30% (Reading database ... 35% (Reading database ... 40% (Reading database ... 45% (Reading database ... 50% (Reading database ... 55% (Reading database ... 60% (Reading database ... 65% (Reading database ... 70% (Reading database ... 75% (Reading database ... 80% (Reading database ... 85% (Reading database ... 90% (Reading database ... 95% (Reading database ... 100% (Reading database ... 23076 files and directories currently installed.) Preparing to unpack .../libusb-dev_2%3a0.1.12-29_amd64.deb ... Unpacking libusb-dev (2:0.1.12-29) ... Selecting previously unselected package libpcsclite1:amd64. Preparing to unpack .../libpcsclite1_1.8.16-1_amd64.deb ... Unpacking libpcsclite1:amd64 (1.8.16-1) ... Selecting previously unselected package libpcsclite-dev. Preparing to unpack .../libpcsclite-dev_1.8.16-1_amd64.deb ... Unpacking libpcsclite-dev (1.8.16-1) ... Selecting previously unselected package pkg-config. Preparing to unpack .../pkg-config_0.29-4_amd64.deb ... Unpacking pkg-config (0.29-4) ... Processing triggers for man-db (2.7.5-1) ... Processing triggers for libc-bin (2.22-7) ... Setting up libusb-dev (2:0.1.12-29) ... Setting up libpcsclite1:amd64 (1.8.16-1) ... Setting up libpcsclite-dev (1.8.16-1) ... Setting up pkg-config (0.29-4) ... Setting up asedriveiiie-build-deps (3.7-5) ... Processing triggers for libc-bin (2.22-7) ... dpkg-buildpackage -rfakeroot -D -us -uc -b dpkg-buildpackage: info: source package asedriveiiie dpkg-buildpackage: info: source version 3.7-5 dpkg-buildpackage: info: source distribution unstable dpkg-buildpackage: info: source changed by Ludovic Rousseau dpkg-source --before-build asedriveiiie-3.7 dpkg-buildpackage: info: host architecture amd64 fakeroot debian/rules clean dh_testdir dh_testroot rm -f build-stamp configure-stamp touch asedriveiiie-usb/Makefile.inc /usr/bin/make -C asedriveiiie-usb clean make[1]: Entering directory '/home/lamby/temp/cdt.20160504171441.1bydKUjNYo.asedriveiiie/asedriveiiie-3.7/asedriveiiie-usb' rm -f *~ *.o *.so || true make[1]: Leaving directory '/home/lamby/temp/cdt.20160504171441.1bydKUjNYo.asedriveiiie/asedriveiiie-3.7/asedriveiiie-usb' touch asedriveiiie-serial/Makefile.inc /usr/bin/make -C asedriveiiie-serial clean make[1]: Entering directory '/home/lamby/temp/cdt.2016050417144
Bug#823664: debsecan: reports new and available kernel security updates that, well, aren't
* Christian Pernegger: > the nightly e-mail report lists both "new security updates" and > "available security updates" for linux-image-3.16.0-4-amd64, with > multiple issues each. However, aptitude insists everything is current. > > At first I thought, something's just temporarily out of sync, but it's > been doing it for days now, so maybe something is amiss. The version of linux-image-3.16.0-4-amd64 on the affected system is 3.16.7-ckt25-2, if I read the apt-cache output correctly. Which issues are reported for it?
Bug#823530: systemd 228 reduced maximum number of tasks in a cgroup to 512 by default
On Sat, May 7, 2016 at 1:25 PM, Santiago Vila wrote: > I'm using a hand-made autobuilder which is triggered by cron, asks a > server for a package to build and uses sbuild to build the package. > Should I override this for the cron service only? cron probably shouldn't be running the actual jobs in its own service scope, applying its own process limits to the jobs. As long as cron does, you can try adding https://www.freedesktop.org/software/systemd/man/systemd-run.html to your job invocation, as in systemd-run --scope -p TasksMax=infinity your-original-command --your --original --args
Bug#820622: linux-image-4.5.0-trunk-armmp-lpae: raspberry pi 2: smsc95xx 1-1.1:1.0 eth0: kevent 2 may have been dropped
On Saturday 07 May 2016 12:44:41 Ben Hutchings wrote: > If this patch reduces the risk of > failed buffer allocations then I think it's still a win. I agree (fwiw). signature.asc Description: This is a digitally signed message part.
Bug#823567: ndiswrapper-dkms fails to compile
Control: severity -1 minor On Thu, 05 May 2016 17:47:22 -0800 Jon wrote: > -- System Information: > LSB Version: > core-2.0-ia32:core-2.0-noarch:core-3.0-ia32:core-3.0-noarch:core-3.1-ia32:core-3.1-noarch:core-3.2-ia32:core-3.2-noarch:core-4.0-ia32:core-4.0-noarch:core-4.1-ia32:core-4.1-noarch:security-4.0-ia32:security-4.0-noarch:security-4.1-ia32:security-4.1-noarch > Distributor ID: Kali > Description: Kali GNU/Linux 2.0 > Release: 2.0 > Codename: sana > Architecture: i686 This is not Debian. Please file bugs with your actual distribution. Andreas
Bug#823670: xserver-xorg-input-all: Tap to click not working after upgrade
Package: xserver-xorg-input-all Version: 1:7.7+15 Severity: important Dear Maintainer, After upgrading a bunch of packages (log attached) and restarting my sessions, I notice the mouse pad click via tapping stopped working. I'm using GNOME3 flashback mode and the option is enabled in the control center. Also, the whole mouse pad became much more sensitive (in an uncomfortable way). I'm not sure which package(s) is(are) responsible for this, but this one was the only one I found related to input, so I'm reporting it here. Sorry if it belongs somewhere else. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.5.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages xserver-xorg-input-all depends on: ii xserver-xorg-input-evdev 1:2.10.1-1+b1 ii xserver-xorg-input-libinput 0.18.0-1 ii xserver-xorg-input-synaptics 1.8.3-1+b1 ii xserver-xorg-input-vmmouse1:13.1.0-1+b1 Versions of packages xserver-xorg-input-all recommends: ii xserver-xorg-input-wacom 0.30.0-1+b1 xserver-xorg-input-all suggests no packages. -- no debconf information Log started: 2016-05-06 00:35:40 (Reading database ... 251383 files and directories currently installed.) Preparing to unpack .../init-system-helpers_1.31_all.deb ... Unpacking init-system-helpers (1.31) over (1.29) ... Processing triggers for man-db (2.7.5-1) ... Setting up init-system-helpers (1.31) ... (Reading database ... 251383 files and directories currently installed.) Preparing to unpack .../archives/init_1.31_amd64.deb ... Unpacking init (1.31) over (1.29) ... Setting up init (1.31) ... (Reading database ... 251383 files and directories currently installed.) Preparing to unpack .../libapt-pkg5.0_1.2.11_amd64.deb ... Unpacking libapt-pkg5.0:amd64 (1.2.11) over (1.2.10) ... Processing triggers for libc-bin (2.22-7) ... Setting up libapt-pkg5.0:amd64 (1.2.11) ... Processing triggers for libc-bin (2.22-7) ... (Reading database ... 251383 files and directories currently installed.) Preparing to unpack .../libapt-inst2.0_1.2.11_amd64.deb ... Unpacking libapt-inst2.0:amd64 (1.2.11) over (1.2.10) ... Preparing to unpack .../archives/apt_1.2.11_amd64.deb ... Unpacking apt (1.2.11) over (1.2.10) ... Processing triggers for libc-bin (2.22-7) ... Processing triggers for man-db (2.7.5-1) ... Setting up apt (1.2.11) ... Processing triggers for libc-bin (2.22-7) ... (Reading database ... 251383 files and directories currently installed.) Preparing to unpack .../apt-utils_1.2.11_amd64.deb ... Unpacking apt-utils (1.2.11) over (1.2.10) ... Processing triggers for man-db (2.7.5-1) ... (Reading database ... 251382 files and directories currently installed.) Removing python-gst0.10 (0.10.22-3) ... Removing python-libxml2 (2.9.3+dfsg1-1) ... (Reading database ... 251236 files and directories currently installed.) Preparing to unpack .../libpam-systemd_229-5_amd64.deb ... Unpacking libpam-systemd:amd64 (229-5) over (229-4) ... Preparing to unpack .../libudev1_229-5_amd64.deb ... Unpacking libudev1:amd64 (229-5) over (229-4) ... Processing triggers for man-db (2.7.5-1) ... Processing triggers for libc-bin (2.22-7) ... Setting up libudev1:amd64 (229-5) ... Processing triggers for libc-bin (2.22-7) ... (Reading database ... 251236 files and directories currently installed.) Preparing to unpack .../printer-driver-foo2zjs-common_20160313dfsg0-1_all.deb ... Unpacking printer-driver-foo2zjs-common (20160313dfsg0-1) over (20151024dfsg0-2) ... Preparing to unpack .../printer-driver-foo2zjs_20160313dfsg0-1_amd64.deb ... Unpacking printer-driver-foo2zjs (20160313dfsg0-1) over (20151024dfsg0-2) ... Preparing to unpack .../archives/udev_229-5_amd64.deb ... Unpacking udev (229-5) over (229-4) ... Preparing to unpack .../libnss-myhostname_229-5_amd64.deb ... Unpacking libnss-myhostname:amd64 (229-5) over (229-4) ... Preparing to unpack .../libsystemd0_229-5_amd64.deb ... Unpacking libsystemd0:amd64 (229-5) over (229-4) ... Processing triggers for man-db (2.7.5-1) ... Processing triggers for mime-support (3.59) ... Processing triggers for desktop-file-utils (0.22-1) ... Processing triggers for gnome-menus (3.13.3-6) ... Processing triggers for cups (2.1.3-5) ... Updating PPD files for foo2zjs-common ... Processing triggers for libc-bin (2.22-7) ... Setting up libsystemd0:amd64 (229-5) ... Processing triggers for libc-bin (2.22-7) ... (Reading database ... 251235 files and directories currently installed.) Preparing to unpack .../systemd_229-5_amd64.deb ... Unpacking systemd (229-5) over (229-4) ... Processing triggers for dbus (1.10.8-1) ... Processing triggers for man-db (2.7.5-1) ... Setting up systemd (229-5) ... addgroup: The group `systemd-journal' already exists as a system group. Exiting. (Reading database ... 251234 files and directories currentl
Bug#823671: liblhasa-dev: ship pkg-config file
Package: liblhasa-dev Version: 0.3.1-1 Severity: wishlist Hi, Please can you ship the upstream supplied pkg-config file (liblhasa.pc) in liblhasa-dev. At the moment I'm porting the LHA decompression code in MilkyTracker to use lhasa instead of the original non-free lha code, and I'm going to have to hardcode the include path which doesn't seem very nice (though will do for the moment). Thanks, James signature.asc Description: This is a digitally signed message part
Bug#823426: asedriveiiie: FTBFS: install: cannot stat 'libASEDriveIIIe-USB.so': No such file or directory
Control: tag -1 unreproducible moreinfo Hi Chris, On Wed, 04 May 2016 17:16:25 +0100 Chris Lamb wrote: > /usr/bin/ld: cannot find /lib/ > /usr/bin/ld: cannot find s/libusb-0.1.so.4.4.4 > collect2: error: ld returned 1 exit status > %Makefile:13: recipe for target 'libASEDriveIIIe-USB.so' failed I could reproduce this, but it goes away if I refresh my pbuilder sid chroot. So something else has been buggy here and fixed inbetween. Please update and try again. Andreas
Bug#823672: ITP: sse-support -- prevent installation on processors without required support
Package: wnpp
Severity: wishlist
Owner: Adam Borowski
> > It might be also good to make a "sse2-support" package as mentioned in
> > the thread Gert linked to to reduce duplication of such detection logic.
> > Please say so if you think this is a good idea.
>
> Saying "so". :-)
* Package name: sse-support
Upstream Author : me
Binaries: sse2-support, sse3-support, more?
Description : prevent installation on processors without required support
This is a mostly dummy package, whose only purpose is to detect the presence
of ${binary%%-support}. It refuses to install on inadequate processors, thus
allowing specifying such a requirement as a dependency.
Detection is done via a "boom instruction" rather than grep /proc/cpuinfo,
because of qemu and /proc-less chroots.
On failure, preinst complains via debconf and on stderr then dies.
I wonder which other extensions would be wanted -- sse4.2? More?
Note that in general you're not supposed to unconditionally use opcodes not
supported by the baseline ISA, but in some cases adding generic code paths
would be either too much work or outright useless. I for one just failed to
obtain access to a pre-sse2 machine despite raiding quite a few places; thus
it's understandable no one bothers to port scientific software to such
museal machines.
I'm afraid it's too late to use this for 686, though.
Bug#346182: Bug#822321: crashes when importing VRML file (containing PROTO)
reopen 346182
reassign 346182 libvtk6.2
thanks
This bug is still present for the same test file.
A gdb backtrace pins it on vtkVRMLImporter::exitField()
from /usr/lib/x86_64-linux-gnu/libvtkIOImport-6.2.so.6.2,
which is in package libvtk6.2.
It's essentially the same backtrace as before, only coming through
libvtkIOImport-6.2.so.6.2 instead of libvtkHybrid.so.5.8
Here is the backtrace for the python execution:
$ gdb python
GNU gdb (Debian 7.10-1+b1) 7.10
...
Reading symbols from python...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/bin/python
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Python 2.7.11+ (default, Apr 17 2016, 14:00:29)
[GCC 5.3.1 20160409] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import vtk
[New Thread 0x7fffadefa700 (LWP 27119)]
...
>>> reader = vtk.vtkVRMLImporter()
>>> reader.SetFileName('mayavi-crash.wrl')
>>> reader.Update()
Program received signal SIGSEGV, Segmentation fault.
0x7fff9bab3f3b in vtkVRMLImporter::exitField() () from
/usr/lib/x86_64-linux-gnu/libvtkIOImport-6.2.so.6.2
(gdb) bt
#0 0x7fff9bab3f3b in vtkVRMLImporter::exitField() () from
/usr/lib/x86_64-linux-gnu/libvtkIOImport-6.2.so.6.2
#1 0x7fff9baaf864 in ?? () from
/usr/lib/x86_64-linux-gnu/libvtkIOImport-6.2.so.6.2
#2 0x7fff9bab0ee2 in vtkVRMLImporter::ImportBegin() () from
/usr/lib/x86_64-linux-gnu/libvtkIOImport-6.2.so.6.2
#3 0x7fff9baabcbd in vtkImporter::Read() () from
/usr/lib/x86_64-linux-gnu/libvtkIOImport-6.2.so.6.2
#4 0x7fff9bcd2435 in ?? () from
/usr/lib/x86_64-linux-gnu/libvtkIOImportPython27D-6.2.so.6.2
#5 0x004c4aca in PyEval_EvalFrameEx ()
#6 0x004c2bd5 in PyEval_EvalCodeEx ()
#7 0x004c2979 in PyEval_EvalCode ()
#8 0x004f221f in ?? ()
#9 0x0044c6f0 in PyRun_InteractiveOneFlags ()
#10 0x0044c530 in PyRun_InteractiveLoopFlags ()
#11 0x0042ea01 in ?? ()
#12 0x0049de78 in Py_Main ()
#13 0x76f1a610 in __libc_start_main (main=0x49d7a0 , argc=1,
argv=0x7fffe0b8, init=, fini=,
rtld_fini=, stack_end=0x7fffe0a8) at libc-start.c:291
#14 0x0049d6c9 in _start ()
Bug#823663: RFS: tio/1.6-1 [ITP] -- The simple TTY terminal I/O application
* Jakob Haufe , 2016-05-07, 12:04: https://mentors.debian.net/debian/pool/main/t/tio/tio_1.6-1.dsc The short license name in d/copyright should be "GPL-2+". Please run autoreconf at build time. (That should be a matter of replacing the "autotools-dev" addon with "autoreconf".) My git doesn't like the certificate: fatal: unable to access 'https://git.sur5r.net/tio/': server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none If this is expected, then it would be probably useful to add a comment to d/control explaining how to persuade git to disable certificate verification. Please ask upstream to build with -Wall (and then fix the warnings...). Upstream changelog seems to cover only changes from the previous version. This is unimportant for the initial release, but in the future we'll need at least all changes from stable to stable+1 included. Please talk to upstream about their changelog habits. :) Lintian says: P: tio source: debian-watch-may-check-gpg-signature X: tio: binary-file-built-without-LFS-support usr/bin/tio Please talk to upstream about signing their releases. The LFS thing is probably not very important. The only regular files that tio opens are log files, which are unlikely to grow over 2GB. But upstream might want to fix it anyway. This should be a matter of adding AC_SYS_LARGEFILE to configure.ac. -- Jakub Wilk
Bug#788667: lintian: suggest adding DEP-8 tests when an automake installcheck-local target is detected
Hello Paul, Paul Wise [2016-05-07 14:45 +0800]: > AFAIK, autodep8 doesn't automatically run or turn on tests, the > maintainer has to look at the output and make it suitable. Strictly speaking, autodep8 only generates the contents of a debian/tests/control file to stdout indeed. But both ci.debian.net and autopkgtest.ubuntu.com *do* run autodep8 in production; in fact, adt-run invokes autodep8 by itself if the tested package does not have a d/t/control. So we *do* run the autogenerated tests in production, and have done so for a long time for perl, ruby, dkms, etc. > Are you suggesting the suggestion to setup a DEP-8 test for packages > that have installcheck-local in Makefile.am files be done in lintian > instead of in autodep8? No, lintian should (and can't) certainly not modify your package source. I think the original request here was to merely print out a suggestion to add an autopkgtest based on installcheck-local. Have a nice weekend, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: PGP signature
Bug#822130: Boost 1.55 to be removed; your attention required
On 2016-05-07 12:17, László Böszörményi (GCS) wrote: > Sorry for the slow reaction. The FTBFS reason is the package test > case. It's threaded and the sequence is confused by the file timestamp > resolution of Hurd and kFreeBSD architectures. It's one second only > (Linux has millisecond resolution). > Question is, how should it be handled? Disable self-tests, ignore the > results or maybe remove mongodb from the mentioned architectures? Does mongodb run reliably on filesystems with second resolution? Or will it cause problems like in this test? If the package is usable on !linux, maybe disabling just that problematic test could work. Otherwise I'd recommend partial removal. Andreas
Bug#816169: RFS: fake-factory/0.5.3-1
On 07/05/16 13:54, Mattia Rizzolo wrote: > On Thu, May 05, 2016 at 03:27:30PM +0100, Christopher Baines wrote: >> On 23/04/16 00:43, Mattia Rizzolo wrote: >>> any news on this? :) >>> nearly a month passed, and the "problematic" thing has been merged >>> upstream. >> >> Sorry for the long delay, I have now added the patch to the Debian >> package (in the Git repository). > > > uploaded :) Amazing, thanks Mattia :)
Bug#816169: RFS: fake-factory/0.5.3-1
On Sat, May 07, 2016 at 01:56:24PM +0100, Christopher Baines wrote: > Amazing, thanks Mattia :) except that while doing the tagging I noticed the patchedTag format was wrong/typoed. I manually remade the tag, and fixed it in a subsequent commit, so that will go in a following upload. Please pull :) -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#823673: samtools: FTBFS in testing
Package: samtools
Version: 1.3.1-1
Severity: serious
Dear maintainer:
This package currently fails to build from source in stretch.
=== Testing mpileup.reg regressions ===
UNEXPECTED FAIL: Output mismatch for $samtools mpileup -x -d 8500 -B -f
mpileup.ref.fa deep.sam|awk '{print $4}'
See FAIL-47.out.1 vs expected/47.out
The full build log is attached.
I see that this package required a change recently for htslib 1.3.1.
However, if this only builds now with libhts >= 1.3.1, then the
Build-Depends field should be updated accordingly.
Thanks.
samtools_1.3.1-1_amd64-20160507-1455.gz
Description: application/gzip
Bug#823674: Crash on start in QtCurve::Style::disconnectDBus()
Package: kde-style-qtcurve-qt5 Version: 1.8.18+git20160320-3d8622c-2 Severity: important After upgrading and rebooting I get four instances of kactivitymanagerd and one of yakuake crashing with the same backtrace (attached). Here is a sample of it: #6 0x7efed5c10490 in QDBusConnection::QDBusConnection(QDBusConnection const&) (this=0x7ffe767fccc0, other=...) at qdbusconnection.cpp:248 #7 0x7efed5c131ac in QDBusConnection::sessionBus() () at qdbusconnection.cpp:1093 #8 0x7efebbd937eb in QtCurve::Style::disconnectDBus() (this=0x24c7e70) at /build/qtcurve- nLsVyh/qtcurve-1.8.18+git20160320-3d8622c/qt5/style/qtcurve.cpp:694 #9 0x7efebbdcf836 in QtCurve::StylePlugin::~StylePlugin() () at /build /qtcurve- nLsVyh/qtcurve-1.8.18+git20160320-3d8622c/qt5/style/qtcurve_plugin.cpp:86 #10 0x7efebbdcf836 in QtCurve::StylePlugin::~StylePlugin() (this=0x24c0740, __in_chrg=) at /build/qtcurve- nLsVyh/qtcurve-1.8.18+git20160320-3d8622c/qt5/style/qtcurve_plugin.cpp:167 #11 0x7efebbdcf869 in QtCurve::StylePlugin::~StylePlugin() (this=0x24c0740, __in_chrg=) at /build/qtcurve- nLsVyh/qtcurve-1.8.18+git20160320-3d8622c/qt5/style/qtcurve_plugin.cpp:170 #12 0x7efed4396a55 in QLibraryPrivate::unload(QLibraryPrivate::UnloadFlag) (this=this@entry=0x24b9dc0, flag=flag@entry=QLibraryPrivate::UnloadSys) at plugin/qlibrary.cpp:553 All programs seem to work well after the system started. -- System Information: Debian Release: stretch/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.5.0-2-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 kde-style-qtcurve-qt5 depends on: ii libc62.22-7 ii libkf5archive5 5.16.0-1 ii libkf5completion55.16.0-1 ii libkf5configcore55.16.0-1 ii libkf5configwidgets5 5.16.0-1 ii libkf5coreaddons55.16.0-1 ii libkf5guiaddons5 5.16.0-1 ii libkf5i18n5 5.16.0-1 ii libkf5iconthemes55.16.0-1 ii libkf5kdelibs4support5 5.16.0-1 ii libkf5kiowidgets55.16.0-1.1 ii libkf5widgetsaddons5 5.16.0-1 ii libkf5windowsystem5 5.16.0-1 ii libkf5xmlgui55.16.0-1 ii libqt5core5a [qtbase-abi-5-5-1] 5.5.1+dfsg-16+b1 ii libqt5dbus5 5.5.1+dfsg-16+b1 ii libqt5gui5 5.5.1+dfsg-16+b1 ii libqt5printsupport5 5.5.1+dfsg-16+b1 ii libqt5svg5 5.5.1-2 ii libqt5widgets5 5.5.1+dfsg-16+b1 ii libqt5x11extras5 5.5.1-3 ii libqtcurve-utils21.8.18+git20160320-3d8622c-2 ii libstdc++6 6.1.1-1 kde-style-qtcurve-qt5 recommends no packages. Versions of packages kde-style-qtcurve-qt5 suggests: ii gtk2-engines-qtcurve 1.8.18+git20160320-3d8622c-2 ii kde-style-qtcurve-qt4 1.8.18+git20160320-3d8622c-2 -- debconf-show failed Application: kactivitymanagerd (kactivitymanagerd), signal: Segmentation fault Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Current thread is 1 (Thread 0x7efed5b1f900 (LWP 1664))] Thread 2 (Thread 0x7efec7669700 (LWP 1665)): #0 0x7efed3ad7e5d in poll () at ../sysdeps/unix/syscall-template.S:84 #1 0x7efed349d382 in _xcb_conn_wait (__timeout=-1, __nfds=1, __fds=0x7efec7668bc0) at /usr/include/x86_64-linux-gnu/bits/poll2.h:46 #2 0x7efed349d382 in _xcb_conn_wait (c=c@entry=0x2431260, cond=cond@entry=0x24312a0, vector=vector@entry=0x0, count=count@entry=0x0) at ../../src/xcb_conn.c:459 #3 0x7efed349eff7 in xcb_wait_for_event (c=0x2431260) at ../../src/xcb_in.c:693 #4 0x7efec9ff0789 in QXcbEventReader::run() (this=0x243f3c0) at qxcbconnection.cpp:1230 #5 0x7efed41c17fe in QThreadPrivate::start(void*) (arg=0x243f3c0) at thread/qthread_unix.cpp:331 #6 0x7efed2b32454 in start_thread (arg=0x7efec7669700) at pthread_create.c:334 #7 0x7efed3ae0eed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 1 (Thread 0x7efed5b1f900 (LWP 1664)): [KCrash Handler] #6 0x7efed5c10490 in QDBusConnection::QDBusConnection(QDBusConnection const&) (this=0x7ffe767fccc0, other=...) at qdbusconnection.cpp:248 #7 0x7efed5c131ac in QDBusConnection::sessionBus() () at qdbusconnection.cpp:1093 #8 0x7efebbd937eb in QtCurve::Style::disconnectDBus() (this=0x24c7e70) at /build/qtcurve-nLsVyh/qtcurve-1.8.18+git20160320-3d8622c/qt5/style/qtcurve.cpp:694 #9 0x7efebbdcf836 in QtCurve::StylePlugin::~StylePlugin() () at /build/qtcurve-nLsVyh/qtcurve-1.8.18+git20160320-3d8622c/qt5/style/qtcurve_plugin.cpp:86 #10 0x7efebbdcf836 in QtCurve::StylePlugi
Bug#823675: cloud-init: FTBFS: /usr/bin/python3: No module named pyflakes
Source: cloud-init Version: 0.7.7~bzr1215-1 Severity: serious Justification: fails to build from source Hi, cloud-init FTBFS in sid: https://buildd.debian.org/status/fetch.php?pkg=cloud-init&arch=all&ver=0.7.7~bzr1215-1&stamp=1462532671 debian/rules override_dh_auto_test make[1]: Entering directory '/«PKGBUILDDIR»' make PYVER=3 check make[2]: Entering directory '/«PKGBUILDDIR»' Running: pep8 cloudinit/ bin/ tests/ tools/ Running: python3 -m pyflakes cloudinit/ bin/ tests/ tools/ /usr/bin/python3: No module named pyflakes Makefile:42: recipe for target 'pyflakes3' failed make[2]: *** [pyflakes3] Error 1 make[2]: Leaving directory '/«PKGBUILDDIR»' debian/rules:9: recipe for target 'override_dh_auto_test' failed Looks like a new Build-Depends is needed. Andreas
Bug#823676: totem: FTBFS in testing (unmet build-depends)
Package: totem Version: 3.18.1-2 Severity: serious Dear maintainer: This package currently fails to build from source in stretch: Build-Depends: libgrilo-0.2-dev (>= 0.2.12) but it is not installable Since packages in testing should build in testing, this is RC for stretch. Thanks.
Bug#822130: Boost 1.55 to be removed; your attention required
On Sat, May 7, 2016 at 2:46 PM, Andreas Beckmann wrote: > On 2016-05-07 12:17, László Böszörményi (GCS) wrote: >> Sorry for the slow reaction. The FTBFS reason is the package test >> case. It's threaded and the sequence is confused by the file timestamp >> resolution of Hurd and kFreeBSD architectures. It's one second only >> (Linux has millisecond resolution). >> Question is, how should it be handled? Disable self-tests, ignore the >> results or maybe remove mongodb from the mentioned architectures? > > Does mongodb run reliably on filesystems with second resolution? Or will > it cause problems like in this test? > If the package is usable on !linux, maybe disabling just that > problematic test could work. Otherwise I'd recommend partial removal. I can't directly answer this question; I don't use kFreeBSD nor Hurd. While I don't know how many users do that, I've never had a bugreport indicating it may have any problem on these architectures. Upstream do _not_ list any of these in their supported platforms page[1] nor say it doesn't work. :) But I've already experienced this kind of FTBFS problem with an other package. That's a small one and doesn't handle too much data - it's not multithreaded in writing those. Could workaround the build situation and it is (and was always) worked correctly. I may look into the tests, but please don't take my word on it. I just wonder if Hurd and/or kFreeBSD will have a filesystem in the near future with more granular timestamp support or not. Regards, Laszlo/GCS [1] https://docs.mongodb.com/v3.0/installation/
Bug#823672: Streaming SIMD Extensions (SSE) is an SIMD instruction set extension to the x86 architecture
> * Package name: sse-support
> Upstream Author : me
> Binaries: sse2-support, sse3-support, more?
> Description : prevent installation on processors without required
> support
> This is a mostly dummy package, whose only purpose is to detect the presence
> of ${binary%%-support}. It refuses to install on inadequate processors, thus
> allowing specifying such a requirement as a dependency.
>
This e-mail is written with the awareness of PowerPC, ARM, MIPS and ARM64
architectures.
My gut feeling says that the package 'sse-support' is sabotage on architecture
"any".
After reading https://en.wikipedia.org/wiki/Streaming_SIMD_Extensions I'm even
more sure that "sse-support" is about 'there is only one true processor
architecture'
I think that is wrong.
Groeten
Geert Stappers
--
Leven en laten leven
Bug#823678: jessie-pu: package ngspice/26-1.1~deb8u1
Package: release.debian.org Severity: normal Tags: jessie User: release.debian@packages.debian.org Usertags: pu Hi, ngspice [non-free] FTBFS with recent pbuilder/sbuild that undefine HOME. This is just a rebuild of the fix theat I NMUed into sid: Pass an explicit -userdir to lyx to not fall back to $HOME/.lyx Andreas diff -Nru ngspice-26/debian/changelog ngspice-26/debian/changelog --- ngspice-26/debian/changelog 2014-07-05 23:49:29.0 +0200 +++ ngspice-26/debian/changelog 2016-05-07 14:51:06.0 +0200 @@ -1,3 +1,18 @@ +ngspice (26-1.1~deb8u1) jessie; urgency=medium + + * Non-maintainer upload. + * Rebuild for jessie. + + -- Andreas Beckmann Sat, 07 May 2016 14:50:10 +0200 + +ngspice (26-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Run lyx with a temporary -userdir to not rely on $HOME, thanks to +Johann Klammer. (Closes: #813119) + + -- Andreas Beckmann Mon, 25 Apr 2016 20:50:13 +0200 + ngspice (26-1) unstable; urgency=low * New upstream release (Closes: #706821) diff -Nru ngspice-26/debian/rules ngspice-26/debian/rules --- ngspice-26/debian/rules 2014-07-05 23:49:29.0 +0200 +++ ngspice-26/debian/rules 2016-04-25 19:30:19.0 +0200 @@ -33,6 +33,7 @@ #cp -f /usr/share/misc/config.sub build/ngspice/doc/config.sub #cp -f /usr/share/misc/config.guess build/ngspice/doc/config.guess cp -a manual build/ + mkdir -p build/manual/.lyx # Make build dir for tclspice mkdir -p build/tclspice cp -Rl `ls . |grep -v build|grep -v debian` build/tclspice @@ -77,9 +78,9 @@ build-indep: config.status # Build documentation dh_testdir - #cd build/manual && lyx --export ps manual.lyx - cd build/manual && lyx --export pdf2 manual.lyx - cd build/manual && lyx --export html manual.lyx + #cd build/manual && lyx -userdir ./.lyx -batch --export ps manual.lyx + cd build/manual && lyx -userdir ./.lyx -batch --export pdf2 manual.lyx + cd build/manual && lyx -userdir ./.lyx -batch --export html manual.lyx touch $@ clean:
Bug#823677: libclc-amdgcn: Add alias for Tonga (and others)
Package: libclc-amdgcn Version: 0.2.0+git20150813-2 Severity: normal Hi, It would be nice to add GPU aliases for Tonga and others in VI: https://github.com/llvm-mirror/libclc/commit/1b1b5a8551971ef4062bd8d84baccfe7a88e83b2 https://github.com/llvm-mirror/libclc/commit/b858eb3811ca8b49a66653473ef309eadcd491af At least applying the tonga patch seems to work here, I can compile and run a small OpenCL sample. Thanks in advance, -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.5.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#823530: systemd 228 reduced maximum number of tasks in a cgroup to 512 by default
On Fri, May 06, 2016 at 06:42:53PM -0500, Martin Pitt wrote: > Hello all, > > Sebastian Schmidt [2016-05-05 20:14 +0200]: > > Whilst debugging why Chrome would regularly fail to create new > > threads[1] and zsh couldn’t fork I noticed that: > > - - All affected processes run in the /system.slice/xdm.service cgroup > > - - “systemctl status xdm.service” says “Tasks: 476 (limit: 512)” > > Antonio Terceiro [2016-05-06 15:45 -0300]: > > I am seeing some inconsistency in this. On my laptop, I don't see any > > limits being applied, even though I am on a fully up to date unstable > > (tried both with my main account from a terminal emulator in GNOME, and > > from a console login with a freshly created user account): > > > > $ ulimit -u 22988 > > Note that these are two different things: > > * TasksMax is enforced via the pids cgroups, and only applies to > .service units started by systemd. It should not apply to user > sessions (i. e. .scopes) started through libpam-systemd, but > as Sebastian is not using them all subprocesses of xdm.service > inherit xdm's limit. > > * ulimit -u is the classic ulimit which is unrelated to TaskMax= >(instead, it is LimitNPROC= if you want to set it in a unit). >systemd does not have/impose a default setting for ulimits, this >usually comes through /etc/security/limits.conf and is being >applied to PAM sessions only, not to .services. > > > I do appreciate the idea of systemd imposing sane limits on tasks, but > > this will cause A LOT of breakage in all sorts of places, and we need > > figure out a plan forward. Will every package need to start declaring > > higher limits explicitly? > > Since we released Ubuntu 16.04 LTS with this I've also gotten reports > about this. E. g. MySQL and RabbitMQ easily break the TasksMax=512 > limit even under moderate load. (https://launchpad.net/bugs/1578080 > is one example) Note that this actually limits threads, not just full > processes. > > So in retrospect, having a default limit there was not such a good > idea after all: 512 is way too much for most "simple" services, and > it's way too little for others such as the ones mentioned above. There > is also no particular rationale about "512", so even if we'd bump it > to 1024 we'd just make the limit even less useful while still breaking > software. > > So I think we should disable the default limit. It is both much safer > and also much more effective in terms of guarding against berserk > programs/bugs/unintended fork bombs etc. to set limits in units > individually. Once someone looks at one, this is then a great time to > also flip on the other resource and privilege limitations that systemd > offers, such as CapabilityBoundingSet=, SecureBits=, PrivateDevices=, > PrivateNetwork=, ProtectSystem=, ProtectHome=, etc. > > So I'm proposing to change the default to "infinity". We could do this > with a /lib/systemd/system.conf.d/no-task-max.conf, but this would be > confusing to someone looking at /etc/systemd/system.conf, so a patch > might be preferable (i. e. reverting upstream commit 9ded9cd). I'll > also raise this upstream (once I have internet again), perhaps we can > even change the default there. > > Opinions? This sounds good to me. Thanks for the quick response. -- Antonio Terceiro signature.asc Description: PGP signature
Bug#823679: nmu: libccaudio2_2.1.3-1.1 libccrtp_2.0.9-2.2 libzrtpcpp_2.3.4-1.1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Looks like an unnoticed libucommon7v5 -> libucommon8 transition, the new ucommon is already in testing. Maybe the old one wasn't in testing. nmu libccaudio2_2.1.3-1.1 . ANY . unstable . -m "Rebuild against ucommon 7.0.0" nmu libccrtp_2.0.9-2.2 . ANY . unstable . -m "Rebuild against ucommon 7.0.0" nmu libzrtpcpp_2.3.4-1.1 . ANY . unstable . -m "Rebuild against ucommon 7.0.0" There is also twinke, but it FTBFS. Andreas
Bug#815567: [Pkg-kde-extras] Bug#815567: Amarok should depend on virtual-mysql-server-core to support MariaDB
On Friday, 22 April 2016 17:09:40 CEST Andreas Beckmann wrote: > Control: reopen -1 > On Mon, 22 Feb 2016 18:06:27 +0200 =?UTF-8?B?T3R0byBLZWvDpGzDpGluZW4=?= > wrote: > > Amarok defines as build dependency: > > Build-Depends-Indep: mysql-server-core-5.6 | mysql-server-core > > This should be changed to: > > Build-Depends-Indep: mysql-server-core-5.6 | virtual-mysql-server-core > That has been implemented, but that's the wrong approach. > The buildds only consider the first alternative. This will break once > mysql-5.6 gets replaced by mysql-5.7 (or whatever else). > This will break in stretch in case mysql-5.6 leaves stretch. > And even if secondary alternatives would be considered by the buildds - > which provider of virtual-mysql-server-core should be installed? There > is probably more than one ... > So in this case you would really want a generic real package as first > alternative: > Build-Depends(-Indep): default-mysql-server-core | virtual-mysql-server-core > except that we currently don't have default-mysql-server-core ... Would you mind cloning this bug and reassigning it to the mysql maintainers, so we either get a default-mysql-server-core to build depend on or some other valid solution. Happy hacking, -- "Nothing ever goes away." -- Commoner's Law of Ecology Saludos /\/\ /\ >< `/ signature.asc Description: This is a digitally signed message part.
Bug#823672: Streaming SIMD Extensions (SSE) is an SIMD instruction set extension to the x86 architecture
On Sat, May 07, 2016 at 03:23:41PM +0200, Geert Stappers wrote: > > My gut feeling says that the package 'sse-support' is sabotage on > architecture "any". > This is from #823465 http://bugs.debian.org/823465 | I'm afraid there's not enough people who care about 586 enough to maintain | it. And the bad decision of i386 to stick to a single arch during its whole | life makes it hard to do so on debian-ports. Compare with ARM: there's arm | armel armhf arm64 arm32(arm64ilp32) -- it frequently refreshes the ABI to | make use of new CPU features, which also makes it easy to keep old compat | without forcing new processors to stay with the lowest common denominator. I now have a better idea _why_ a sse-suport package. My concern is how should look a Debian control file at source level ( arch all ). At arch Intel makes a 'Depends: sse-support' sense Having at arch ARM 'Depens: sse-support' also, will prevent install, but not `build`. Gee, what a can of worms is thirty years so called binary compatible. Groeten Geert Stappers -- Leven en laten leven signature.asc Description: Digital signature
Bug#821022: python-lldb-3.8: Broken symlinks _lldb.so and libLLVM-3.8.0.so.1
Hi,
On Sun, 24 Apr 2016 16:40:39 +0200 Sylvestre Ledru
wrote:
> Le 24/04/2016 à 10:08, Graham Inggs a écrit :
> > Confirming. Python-lldb-3.8 has missing dependencies and some
broken symlinks.
> >
> > After installing python-lldb-3.8, I needed to take the steps below (as
> > root) before I could 'import lldb' successfully.
> >
> > apt-get install lldb-3.8 liblldb-3.8 liblldb-3.8-dev
> >
> > cd /usr/lib/llvm-3.8/lib/python2.7/site-packages/lldb
> > rm libLLVM-3.8.0.so.1
> > ln -s ../../../../../x86_64-linux-gnu/libLLVM-3.8.0.so.1
libLLVM-3.8.0.so.1
> > rm libLLVM-3.8.so.1
> > ln -s ../../../../../x86_64-linux-gnu/libLLVM-3.8.0.so.1
libLLVM-3.8.so.1
> > rm _lldb.so
> > ln -s ../../../../../x86_64-linux-gnu/liblldb-3.8.so _lldb.so
/pkg-llvm-team
>
> yes, this is fine. A patch would be appreciated as I don't have the
> bandwidth for the next two weeks.
Attached is a tentative patch fixing the symlinks and adding the missing
dependencies. I'm testing a full clean rebuild with it and will report back.
This patch does not fix the problem in #813798 (lldb testsuite failing
due to invalid _lldb.so symlink), which happens because lldb's
finishSwigPythonLLDB.py does not know about the SOEXT we are adding. I'm
working on that.
Regards,
Pablo
Index: control
===
--- control (revision 1915)
+++ control (working copy)
@@ -395,7 +395,7 @@
Package: python-lldb-3.8
Section: python
Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}, python
+Depends: ${shlibs:Depends}, ${misc:Depends}, liblldb-3.8, lldb-3.8, python
Conflicts: python-lldb-3.4, python-lldb-3.5, python-lldb-3.6, python-lldb-3.7
Pre-Depends: ${misc:Pre-Depends}
Description: Next generation, high-performance debugger, python lib
Index: liblldb-X.Y.links.in
===
--- liblldb-X.Y.links.in(revision 1915)
+++ liblldb-X.Y.links.in(working copy)
@@ -1,4 +1,3 @@
usr/lib/@DEB_HOST_MULTIARCH@/liblldb-@LLVM_VERSION@.so.1
usr/lib/@DEB_HOST_MULTIARCH@/liblldb-@LLVM_VERSION@.so
-usr/lib/@DEB_HOST_MULTIARCH@/liblldb-@LLVM_VERSION@.so
usr/lib/python2.7/dist-packages/lldb-@LLVM_VERSION@/_lldb.so
usr/lib/@DEB_HOST_MULTIARCH@/liblldb-@LLVM_VERSION@.so.1
usr/lib/llvm-@LLVM_VERSION@/lib/liblldb.so.1
Index: python-lldb-X.Y.links.in
===
--- python-lldb-X.Y.links.in(revision 1915)
+++ python-lldb-X.Y.links.in(working copy)
@@ -1,5 +1,6 @@
-usr/lib/@DEB_HOST_MULTIARCH@/libLLVM-@LLVM_VERSION_FULL@.so.1
usr/lib/python2.7/dist-packages/lldb/libLLVM-@LLVM_VERSION_FULL@.so.1
-usr/lib/@DEB_HOST_MULTIARCH@/libLLVM-@LLVM_VERSION_FULL@.so.1
usr/lib/python2.7/dist-packages/lldb/libLLVM-@LLVM_VERSION@.so.1
+usr/lib/@DEB_HOST_MULTIARCH@/libLLVM-@LLVM_VERSION_FULL@.so.1
usr/lib/llvm-@LLVM_VERSION@/lib/python2.7/site-packages/lldb/libLLVM-@LLVM_VERSION_FULL@.so.1
+usr/lib/@DEB_HOST_MULTIARCH@/libLLVM-@LLVM_VERSION_FULL@.so.1
usr/lib/llvm-@LLVM_VERSION@/lib/python2.7/site-packages/lldb/libLLVM-@LLVM_VERSION@.so.1
+usr/lib/@DEB_HOST_MULTIARCH@/liblldb-@LLVM_VERSION@.so.1
usr/lib/llvm-@LLVM_VERSION@/lib/python2.7/site-packages/lldb/_lldb.so
usr/lib/llvm-@LLVM_VERSION@/lib/python2.7/site-packages/lldb/
usr/lib/python2.7/dist-packages/lldb
Index: rules
===
--- rules (revision 1915)
+++ rules (working copy)
@@ -412,7 +412,7 @@
sed -i 's|LLVM_CMAKE_DIR
"/usr/lib/llvm-$(LLVM_VERSION)/share/llvm/cmake"|LLVM_CMAKE_DIR
"/usr/share/llvm-$(LLVM_VERSION)/cmake"|'
$(DEB_INST)/usr/lib/llvm-$(LLVM_VERSION)/share/llvm/cmake/LLVMConfig.cmake
# Managed in lldb-X.Y.links.in
- rm -f
$(CURDIR)/$(TARGET_BUILD)/$(BUILD_DIR)/lib/python*/site-packages/lldb/_lldb.so
+ rm -f
$(DEB_INST)/usr/lib/llvm-$(LLVM_VERSION)/lib/python*/site-packages/lldb/_lldb.so
# Manage the polly files. Sometimes, we build them. Sometimes not.
if test "$(POLLY_ENABLE)" = yes; then \
Bug#823672: Streaming SIMD Extensions (SSE) is an SIMD instruction set extension to the x86 architecture
On 05/07/2016 03:59 PM, Geert Stappers wrote: > On Sat, May 07, 2016 at 03:23:41PM +0200, Geert Stappers wrote: >> >> My gut feeling says that the package 'sse-support' is sabotage on >> architecture "any". >> > > This is from #823465 http://bugs.debian.org/823465 > > | I'm afraid there's not enough people who care about 586 enough to maintain > | it. And the bad decision of i386 to stick to a single arch during its whole > | life makes it hard to do so on debian-ports. Compare with ARM: there's arm > | armel armhf arm64 arm32(arm64ilp32) -- it frequently refreshes the ABI to > | make use of new CPU features, which also makes it easy to keep old compat > | without forcing new processors to stay with the lowest common denominator. > > > I now have a better idea _why_ a sse-suport package. > > My concern is how should look a Debian control file at source level ( arch > all ). > At arch Intel makes a 'Depends: sse-support' sense > Having at arch ARM 'Depens: sse-support' also, will prevent install, but not > `build`. I really don't get what you are saying here. Of course one would NOT have an arch: any package in Debian that depends on sse-support on non-i386, you'd put in Depends: sse-support [i386] in debian/control and the package build would then add the dependency on i386, but not and anything on other platforms. (If the package in question even supports other platforms than x86 in the first place.) Why so critical? The current situation is that if there's a package in the archive that now only works with SSE extensions, and is not easily portable to non-SSE (for example, if it contains hand-written assembly code), then the only recourse that's available _now_ is to drop i386 from that package's architecture (because it will segfault without a good error message) - or to add detection in preinst... (Because porting is not always an option, especially if it's lots of code.) This does not, however, excuse packages to force SSE support if a package CAN support other hardware, and it wasn't meant to. It is meant to cover the cases where a package is either not available on i386 at all or available to at least some users. I fail to see why you would think this is a bad thing? @Adam: One suggestion though: since this might also come in handy in other places, I'd recommend you name the source package something more generic (such as cpu-support or so, assuming that's not taken already, I didn't check), and have it generate a binary package with the name sse-support. I'm pretty sure that other cases could come up with a similar requirement in the future, and that way they'd easily find a home. Regards, Christian signature.asc Description: OpenPGP digital signature
Bug#823651: pbuilder: fails to make temp file - breaks
Hi Mattia, > This error is the same as the one reported in #576425, a report about > pbuilder not working with libpam-tmpfs. Are you using libpam-tmpfs? No, not even installed. > If not please provide you /etc/pbuilderrc, ~/.pbuilderrc, a full log > with --debug. /etc/pbuilderrc only contains MIRRORSITE=http://ftp.jaist.ac.jp/debian/ There is no ~/.pbuilderrc. debug log created with runing as root cowbuilder --build --debug --buildresult . ...dsc is attached. All the best Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live & Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 -> Copying COW directory forking: rm -rf /var/cache/pbuilder/build/cow.28356 forking: cp -al /var/cache/pbuilder/base.cow /var/cache/pbuilder/build/cow.28356 I: removed stale ilistfile /var/cache/pbuilder/build/cow.28356/.ilist forking: chroot /var/cache/pbuilder/build/cow.28356 cowdancer-ilistcreate /.ilist find . -xdev -path ./home -prune -o \( \( -type l -o -type f \) -a -links +1 -print0 \) | xargs -0 stat --format '%d %i ' -> Invoking pbuilder forking: pbuilder build --debug --buildplace /var/cache/pbuilder/build/cow.28356 --buildresult . --no-targz --internal-chrootexec chroot /var/cache/pbuilder/build/cow.28356 cow-shell /src/TeX/debian/git/build-area/texlive-bin_2016.20160507.40923-1.dsc W: /root/.pbuilderrc does not exist ++ shift ++ '[' -n --buildplace ']' ++ case "$1" in ++ '[' '!' -d /var/cache/pbuilder/build/cow.28356 ']' +++ readlink -f /var/cache/pbuilder/build/cow.28356 ++ BUILDPLACE=/var/cache/pbuilder/build/cow.28356 ++ shift ++ shift ++ '[' -n --buildresult ']' ++ case "$1" in ++ '[' -n . ']' ++ '[' -d . ']' +++ readlink -f . ++ BUILDRESULT=/src/TeX/debian/git/build-area ++ shift ++ shift ++ '[' -n --no-targz ']' ++ case "$1" in ++ log.i 'Running in no-targz mode' ++ case "$LOGLEVEL" in ++ log 'I: Running in no-targz mode' ++ case "$*" in ++ echo 'I: Running in no-targz mode' I: Running in no-targz mode ++ INTERNAL_BUILD_UML=yes ++ shift ++ '[' -n --internal-chrootexec ']' ++ case "$1" in ++ CHROOTEXEC='chroot /var/cache/pbuilder/build/cow.28356 cow-shell' ++ shift ++ shift ++ '[' -n /src/TeX/debian/git/build-area/texlive-bin_2016.20160507.40923-1.dsc ']' ++ case "$1" in ++ break ++ log.d 'cmdline: build --debug --buildplace /var/cache/pbuilder/build/cow.28356 --buildresult . --no-targz --internal-chrootexec chroot /var/cache/pbuilder/build/cow.28356 cow-shell /src/TeX/debian/git/build-area/texlive-bin_2016.20160507.40923-1.dsc' ++ case "$LOGLEVEL" in ++ BUILDPLACE=/var/cache/pbuilder/build/cow.28356 ++ BASEBUILDPLACE=/var/cache/pbuilder/build/cow.28356 ++ '[' yes '!=' yes -a no '!=' yes ']' ++ '[' -z 'chroot /var/cache/pbuilder/build/cow.28356 cow-shell' ']' ++ case "$LOGLEVEL" in ++ case "$PBUILDER_OPERATION" in ++ EXPERIMENTAL= ++ case "$PBUILDER_OPERATION" in ++ '[' noninteractive = noninteractive -o noninteractive = Noninteractive ']' ++ exec ++ FORCE_CONFNEW[0]=-o ++ FORCE_CONFNEW[1]=DPkg::Options::=--force-confnew ++ '[' -n '' ']' +++ sort -u ++ BINDMOUNTS= ++ '[' no = yes ']' + . /usr/lib/pbuilder/pbuilder-buildpackage-funcs + PACKAGENAME=/src/TeX/debian/git/build-area/texlive-bin_2016.20160507.40923-1.dsc + '[' '!' -f /src/TeX/debian/git/build-area/texlive-bin_2016.20160507.40923-1.dsc ']' + '[' .dsc '!=' .dsc ']' + shift + '[' -n '' ']' + '[' -n pbuilder -a -n 1234 ']' + SUTOUSER='LD_PRELOAD= LOGNAME=pbuilder USER=pbuilder /sbin/start-stop-daemon --start --pidfile /dev/null --chuid pbuilder --startas /bin/sh' + DEBBUILDOPTS=-rfakeroot + EXTRAPACKAGES=' fakeroot' + log.i 'using fakeroot in build.' + case "$LOGLEVEL" in + log 'I: using fakeroot in build.' + case "$*" in + echo 'I: using fakeroot in build.' I: using fakeroot in build. + UNSHARE= + case $USENETWORK in + /usr/bin/unshare -n -- /usr/lib/pbuilder/pbuilder-unshare-wrapper true + USENETWORK=no + UNSHARE='/usr/bin/unshare -n -- /usr/lib/pbuilder/pbuilder-unshare-wrapper' + log.i 'pbuilder: network access will be disabled during build' + case "$LOGLEVEL" in + log 'I: pbuilder: network access will be disabled during build' + case "$*" in + echo 'I: pbuilder: network access will be disabled during build' I: pbuilder: network access will be disabled during build + BUILDRESULTUID=0 + BUILDRESULTGID=0 + echobacktime ++ date + log.i 'Current time: Sat May 7 23:12:40 JST 2016' + case "$LOGLEVEL" in + log 'I: Current time: Sat May 7 23:12:40 JST 2016' + case "$*" in + echo 'I: Current time: Sat May 7 23:12:40 JST 2016' I: Current time: Sat May 7 23:12:40 JST 2016 ++ date +%s + log.i 'pbuilder-time-stamp: 1462630360' + case "$LOGLEVEL" in + log 'I: pbuilder-time-stamp: 1462630360' + case "$*" in + echo 'I: pbuilder-time-stamp: 1462630360' I:
Bug#823680: systemd + unbound + resolvconf + squid3 == boot hangs: systemctl reload run on inactive service without --no-block
Package: sysv-rc Version: 2.88dsf-59 Severity: normal File: /usr/sbin/invoke-rc.d Hi, If you install systemd, unbound, resolvconf and squid3 on jessie and boot, system boot hangs. systemd starts unbound. unbound is started properly and informs resolvconf about being a DNS server. resolvconf runs the update-libc.d hook placed by squid3. squid3's resolvconf hook runs "invoke-rc.d squid3 reload". invoke-rc.d runs "systemctl reload squid3.service" and blocks, because squid3 isn't started yet. Eventually unbound.service times out. I argue that invoke-rc.d changed API. Formerly (with sysv) reloading a service that isn't started would generally do nothing (or fail). In any case, one generally wouldn't expect a reload operation to finish before the invoke-rc.d call returns (as it often just sends a signal). With systemd that changes to blocking. This behaviour change is unexpected and can break system boot. Marco d'Itri recommeded adding --no-block to the systemctl invocation. What do you think? Helmut
Bug#823649: libjs-mediaelement: Reflected XSS vulnerability
Hi, On Sat, May 07, 2016 at 11:58:22AM +1000, Craig Small wrote: > Package: libjs-mediaelement > Version: 2.15.1+dfsg-1 > Severity: important > Tags: security upstream > > I saw this regarding the wordpress 4.5.2 release[1]. Thank you for the heads up. > MediaElement.js is > vulnerable to a reflected XSS attack. The wordpress patch is at [2] > but I cannot exactly find what has changed but I think it is the > url has the time added to randomize it more. [3] Looks like the issue is confined in the Flash player that is disabled in Debian, so we should be on the safe side. I’ll backport the fix anyway to be on the safer side, thanks. > 1: https://wordpress.org/news/2016/05/wordpress-4-5-2/ > 2: https://core.trac.wordpress.org/changeset/37370 > 3: > https://github.com/johndyer/mediaelement/commit/34834eef8ac830b9145df169ec22016a4350f06e Regards David signature.asc Description: PGP signature
Bug#810919: libsane: libusb_bulk_write returns "Resource temporarily unavailable"
Hi! So, I have had a quick look at this now and I'm a bit hesitating to patch libusb_bulk_write this way since it is a change that affects all scanners. Worst case would be that, while this patch fixes the problem Steve has, it could potentially break many other scanners. I would therefore like to ask you to remove this patch from the package until SANE upstream has decided how to resolve this issue. I'm not going to upload the package with the patch as-is due to the potential regression it could introduce. As for Steve, please try experimenting with the values in /etc/sane.d/ plustek.conf. Sometimes these issues can be resolved by tuning the parameter for the warmup time, e.g. "option warmup". I have had scanners which use the plustek backend and would refuse to work properly unless the warmup time would be set to 0. PS: Steve, please use "diff -u" to generate diffs in the future. Diffs generated without the "-u" option may cause issues with other tools and are also much harder to read. Cheers, 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#823418: Info received (Bug#823418: exim4: Since the last update, it seems like some messages are rejected after DATA)
On Sat, May 07, 2016 at 01:07:14PM +0200, Andreas Metzler wrote: > I am not sure, but I think these provide useful reject messages on their > own, though. I think they do, I remember checking this out when writing those parts of config. 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#821574: php-fpdf: PHP 7.0 Transition
Hi Ondrej,
sorry for delay, before do anything, to obtain php-fpdf compatible,
seems simply be enough,
change in my control
Depends: ${shlibs:Depends}, ${misc:Depends}, php5 | php5-cli
into
Depends: ${shlibs:Depends}, ${misc:Depends}, php | php-cli
can you confirm?
TIA
Alessandro - Lota
Bug#823681: RFS: hoteldruid/2.1.4-2
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "hoteldruid": * Package name: hoteldruid Version : 2.1.4-2 Upstream Author : Marco M. F. De Santis * URL : http://www.hoteldruid.com * License : AGPLv3 Section : web It builds those binary packages: hoteldruid - web-based property management system for hotels or B&Bs To access further information about this package, please visit the following URL: http://mentors.debian.net/package/hoteldruid Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/h/hoteldruid/hoteldruid_2.1.4-2.dsc More information about hoteldruid can be obtained from http://www.hoteldruid.com. Changes since the last upload: * debian/control: adopted new php packaging names. (Closes: #821503) * debian/control: added new dependency on php-xml and suggest firefox. * debian/control: updated Standards-Version (no change needed). Regards, Marco M. F. De Santis
Bug#823682: libc0.1-dev: can't link PIE executable on kfreebsd
Package: libc0.1-dev Version: 2.22-6 Severity: normal User: debian-...@lists.debian.org Usertags: kfreebsd Hi, It seems that ever since Bug #430455, dpkg-buildflags thinks kfreebsd does not support Position-Independent Executable, so does not enable it even if specifically requested with DEB_BUILD_MAINT_OPTIONS=hardening=+pie Fixing dpkg-dev's /usr/share/perl5/Dpkg/Vendor/Debian.pm to permit use of PIC on kfreebsd, still doesn't enable it by default. Trying to compile+link anything as PIE, actually seems to fail at the moment: $ cc -fPIE -Wl,-pie -o foo foo.c /usr/bin/ld: /usr/lib/gcc/x86_64-kfreebsd-gnu/5/../../../x86_64-kfreebsd-gnu/crt1.o: relocation R_X86_64_32S against `__libc_csu_fini' can not be used when making a shared object; recompile with -fPIC /usr/lib/gcc/x86_64-kfreebsd-gnu/5/../../../x86_64-kfreebsd-gnu/crt1.o: error adding symbols: Bad value collect2: error: ld returned 1 exit status The C runtime has been compiled as relocatable code, not PIC: $ file /usr/lib/x86_64-kfreebsd-gnu/crt1.o /usr/lib/x86_64-kfreebsd-gnu/crt1.o: ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), for GNU/kFreeBSD 8.3.0, not stripped Is that the right file to link with, or should it rather use Scrt1.o or something else? Or does this mean PIC/PIE must be enabled somewhere in glibc first? It's not clear to me how that is done, or how/why this works at the moment on linux-amd64 but not kfreebsd-amd64. Thanks! p.s. the kernel of FreeBSD didn't implement ASLR yet, but when it does, we'd like to have as much as possible compiled as PIC/PIE already. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 10.1-0-amd64 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash
Bug#819546: vsftpd no longer starts with systemd because of listen_ipv6=NO from Bug: #803999
Hi! > I must disagree. First of all, it is an accepted policy that daemons > on Debian do start upon installation of the package. Indeed. It's the case for Apache, too, for example. However, upstream, can't seem to agree on the default values either. >From the manpage from the upstream tarball: listen If enabled, vsftpd will run in standalone mode. This means that vsftpd must not be run from an inetd of some kind. Instead, the vsftpd exe‐ cutable is run once directly. vsftpd itself will then take care of listening for and handling incoming connections. Default: NO listen_ipv6 Like the listen parameter, except vsftpd will listen on an IPv6 socket instead of an IPv4 one. This parameter and the listen parameter are mutually exclusive. Default: NO and from the sample vsftpd.conf: # When "listen" directive is enabled, vsftpd runs in standalone mode and # listens on IPv4 sockets. This directive cannot be used in conjunction # with the listen_ipv6 directive. listen=YES # # This directive enables listening on IPv6 sockets. To listen on IPv4 and IPv6 # sockets, you must run two copies of vsftpd with two configuration files. # Make sure, that one of the listen options is commented !! #listen_ipv6=YES So, while I would like to see this bug fixed and vsftpd behave consistently with the remaining daemon packages in Debian, I want the end result not to deviate too much from upstream. Might be a good idea to report this issue upstream and ask them to fix either the manpage or the configuration file so that in the end, both files are consistent. I don't really want to upload the package as it is currently found on mentors.debian.net. 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#810919: libsane: libusb_bulk_write returns "Resource temporarily unavailable"
I totally agree with Adrian. My patch was just a workaround, but I thought it was worth documenting, because I did an internet search when I first experienced the problem, and other people with different scanners were reporting similar symptoms. I haven't investigated further, but it did occur to me that there might be a bug in libusb, with the call completing before the device acknowledges a successful write. (I don't actually know how libusb works though.) Steve (new email address)
Bug#823683: PHP 7.0 Transition
Package: php-services-json Version: 1.0.3-1 Severity: serious User: pkg-php-ma...@lists.alioth.debian.org Usertags: php7.0-transition Hi, As shown by php7cc, php-services-json contains deprecated PHP 4 constructors. As outlined in #783422, upstream has not been active in years, so unless that changes, this package should probably not be shipped in the next Debian stable release. Regards David signature.asc Description: PGP signature
Bug#823672: Streaming SIMD Extensions (SSE) is an SIMD instruction set extension to the x86 architecture
On Sat, May 07, 2016 at 04:14:05PM +0200, Christian Seiler wrote: > On 05/07/2016 03:59 PM, Geert Stappers wrote: > > On Sat, May 07, 2016 at 03:23:41PM +0200, Geert Stappers wrote: > >> My gut feeling says that the package 'sse-support' is sabotage on > >> architecture "any". Obviously, it's arch specific. > > This is from #823465 http://bugs.debian.org/823465 Sadly, nope. We'd need to somehow add a (possibly indirect) dependency on 686-support to every single gcc-compiled package on i386. > > I now have a better idea _why_ a sse-suport package. > > > > My concern is how should look a Debian control file at source level ( arch > > all ). > > At arch Intel makes a 'Depends: sse-support' sense > > Having at arch ARM 'Depens: sse-support' also, will prevent install, but > > not `build`. > > I really don't get what you are saying here. Of course one would NOT > have an arch: any package in Debian that depends on sse-support on > non-i386, you'd put in Depends: sse-support [i386] in debian/control > and the package build would then add the dependency on i386, but not > and anything on other platforms. (If the package in question even > supports other platforms than x86 in the first place.) I'd guess a package that has generic code paths is unlikely to have such a strict dependency (although sse2 is so old that a number-crunching package probably won't bother with runtime detection). > Why so critical? The current situation is that if there's a package > in the archive that now only works with SSE extensions, and is not > easily portable to non-SSE (for example, if it contains hand-written > assembly code), then the only recourse that's available _now_ is to > drop i386 from that package's architecture (because it will segfault > without a good error message) - or to add detection in preinst... Detection in preinst is exactly what sse-detect is for, yeah. > @Adam: One suggestion though: since this might also come in handy > in other places, I'd recommend you name the source package something > more generic (such as cpu-support or so, assuming that's not taken > already, I didn't check), and have it generate a binary package with > the name sse-support. I'm pretty sure that other cases could come up > with a similar requirement in the future, and that way they'd easily > find a home. Good idea! The test harness is already templated, so there's no reason to make this x86 specific. I think I'll put the master list as an 822-formatted file like: .-- Name: sse2 Architecture: any-i386 Instruction: addpd %xmm0, %xmm1 Name: sse3 Architecture: any-i386 any-amd64 x32 Instruction: haddpd %xmm0, %xmm1 Name: fp11 Architecture: pdp11 Instruction: ldbt ` which on pdp11 will generate fp11-support which will do the right thing (assuming I read the docs correctly, I don't know PDP-11 assembly :þ). Meow! -- How to exploit the Bible for weight loss: Pr28:25: he that putteth his trust in the ʟᴏʀᴅ shall be made fat.
Bug#823684: util-linux: FTBFS[!linux]: missing uuidd
Package: util-linux Version: 2.28-1 Severity: important Tags: patch User: debian-...@lists.debian.org Usertags: kfreebsd Hi, util-linux since 2.28 FTBFS on kfreebsd and hurd, because uuidd (daemon) now depends on non-portable sys/signalfd.h Please mark the binary as [linux-any] in the uuid-runtime.install file, as in the attached patch. Thanks. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 10.1-0-amd64 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash --- util-linux-2.28.orig/debian/uuid-runtime.install 2016-04-12 15:10:54.0 +0100 +++ util-linux-2.28/debian/uuid-runtime.install 2016-05-07 16:18:08.467243744 +0100 @@ -1,6 +1,6 @@ #!/usr/bin/dh-exec lib/systemd/system/uuidd.* [linux-any] usr/bin/uuidgen -usr/sbin/uuidd +usr/sbin/uuidd [linux-any] usr/share/man/man1/uuidgen.* -usr/share/man/man8/uuidd.* +usr/share/man/man8/uuidd.* [linux-any]
Bug#823682: libc0.1-dev: can't link PIE executable on kfreebsd
close 823682 notfound 823682 glibc/2.22-6 thanks Steven Chamberlain wrote: > $ cc -fPIE -Wl,-pie -o foo foo.c > /usr/bin/ld: > /usr/lib/gcc/x86_64-kfreebsd-gnu/5/../../../x86_64-kfreebsd-gnu/crt1.o: > relocation R_X86_64_32S against `__libc_csu_fini' can not be used when making > a shared object; recompile with -fPIC > /usr/lib/gcc/x86_64-kfreebsd-gnu/5/../../../x86_64-kfreebsd-gnu/crt1.o: error > adding symbols: Bad value > collect2: error: ld returned 1 exit status > Is that the right file to link with, or should it rather use Scrt1.o or > something else? Sorry, my fault, I'd passed -pie as a linker option, but not to the compiler. This works - and it uses Scrt1.o instead: $ cc -fPIE -pie -o foo foo.c I'll file a new bug about the change needed in dpkg-dev. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#814836: imagemagick: Font Metrics faulty textWidth | Integer overflow
On Mon, Feb 15, 2016 at 8:48 PM, Maximilian Bloch wrote: > Package: imagemagick > Severity: normal What is your arch ? > > Dear Maintainer, > > I seem to have stumbled across an integer overflow issue with imagemagick, > pertaining to calculated font metrics (width/bounds) for many fonts depending > on pointsize. A more detailed bug report of mine can be found in the > ImageMagick Forum: > > https://www.imagemagick.org/discourse-server/viewtopic.php?f=3&t=29135 > > > * What led up to the situation? > > $ convert -debug annotate -pointsize 72 -font ./RNS.ttf label:g null: > > NOTE RNS.ttf was taken from http://www.1001fonts.com/rns-font.html > > > * What was the outcome of this action? > > 2016-02-15T20:29:34+01:00 0:00.010 0.000u 6.9.3 Annotate convert[3989]: > annotate.c/RenderFreetype/1421/Annotate > Font ./RNS.ttf; font-encoding none; text-encoding none; pointsize 72 > 2016-02-15T20:29:34+01:00 0:00.010 0.000u 6.9.3 Annotate convert[3989]: > annotate.c/GetTypeMetrics/843/Annotate > Metrics: text: g; width: 3.35545e+07; height: 103; ascent: 70; descent: > -31; max advance: 61; bounds: -3.35544e+07,-0.09375 35,55.1719; origin: > 36,0; pixels per em: 72,72; underline position: -1.5625; underline thickness: > 0.78125 > > > * What outcome did you expect instead? > > 2016-02-12T06:56:07-05:00 0:00.110 0.010u 7.0.0 Annotate convert[22115]: > annotate.c/RenderFreetype/1442/Annotate > Font ./RNS.ttf; font-encoding none; text-encoding none; pointsize 72 > 2016-02-12T06:56:07-05:00 0:00.110 0.010u 7.0.0 Annotate convert[22115]: > annotate.c/GetTypeMetrics/860/Annotate > Metrics: text: g; width: 38.5625; height: 103; ascent: 70; descent: -31; > max advance: 61; bounds: 0.4375,-0.09375 35,55.1719; origin: 36.2812,0; > pixels per em: 72,72; underline position: -1.5625; underline thickness: > 0.78125 > > Any help would be much appreciated. > > Thanks, > Max > > -- 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=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) >
Bug#821022: python-lldb-3.8: Broken symlinks _lldb.so and libLLVM-3.8.0.so.1
On 05/07/2016 04:05 PM, Pablo Oliveira wrote: > On Sun, 24 Apr 2016 16:40:39 +0200 Sylvestre Ledru > wrote: >> [...] >> yes, this is fine. A patch would be appreciated as I don't have the >> bandwidth for the next two weeks. > > > Attached is a tentative patch fixing the symlinks and adding the missing > dependencies. I'm testing a full clean rebuild with it and will report back. The previously attached patch fixes the import issue on a clean build of llvm-toolchain-3.8. Regards, Pablo
Bug#823418: Info received (Bug#823418: exim4: Since the last update, it seems like some messages are rejected after DATA)
On Sat, May 07, 2016 at 11:57:55AM -0400, David Hill wrote: >The problem I have with this new behavior is that lots of mail server > such as exchange and lots of antivirus/antispam/antimail/etc are sending > mails with such lines... I've seen even banks using commercial product that > are not respecting that RFC document (821). Feel free to change the ACL. Configuration is meant to be subject to local changes. 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#823418: Info received (Bug#823418: exim4: Since the last update, it seems like some messages are rejected after DATA)
Hello sir, The problem I have with this new behavior is that lots of mail server such as exchange and lots of antivirus/antispam/antimail/etc are sending mails with such lines... I've seen even banks using commercial product that are not respecting that RFC document (821). Thank you very much, David Hill -Original Message- From: Marc Haber Sent: Friday, May 6, 2016 4:10 PM To: David Hill Cc: 823...@bugs.debian.org Subject: Re: Bug#823418: Info received (Bug#823418: exim4: Since the last update, it seems like some messages are rejected after DATA) retitle #823418 add message to max_received_linelength DATA ACL thanks On Fri, May 06, 2016 at 11:13:51AM -0400, David Hill wrote: This solved this issue ... Now, why is this enforced ? This is a new behavior and a lot of smtp servers are not enforcing this limitation like hotmail and some banks. Having excessively long head lines is an RFC violation, and exim doesn't want to send on messages that violate RFCs. While it cannot split such header line, it is reasonable behavior not to accept those messages in the first place. We should, however, add a meaningful message to this ACL, retitling the bug appropriately. 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 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Bug#823686: New upstream version 2.33 - please package
Package: keepass2 Version: 2.32+dfsg-1 Dear Maintainer, Please package KeePass 2.33. Lot's of fixes and improvements: http://keepass.info/news/n160507_2.33.html Thanks!
Bug#823195: evince-common: Mouse Inverted Reversed Scrolling Does not Function
Control: tags -1 + unreproducible On Fri, May 06, 2016 at 04:37:31PM -0400, Carl Nikolov wrote: > Yes I have done this > Only evince If it was not just Evince, but all GTK3 apps having this problem, I would say that it's a known problem that Xfce's reverse scrolling option does not work with GTK3 apps. That's what I see when I try it in a VM; Xfce's reverse scrolling works with things like Thunar file manager and Firefox, but does not work with GTK3 apps like Evince and gedit. There are various bug reports and workarounds for it, ex: https://bugzilla.xfce.org/show_bug.cgi?id=11193 https://bugs.launchpad.net/ubuntu/+source/xfce4-settings/+bug/1368402 https://bugzilla.gnome.org/show_bug.cgi?id=674716#c13 But if it's just Evince having this problem, I don't know how to help. I can't reproduce it on my side and I don't know of any reason for Evince to behave differently from any other GTK3 app.
Bug#823684: util-linux: FTBFS[!linux]: missing uuidd
Control: tags -1 + confirmed Hello Steven Chamberlain. Thanks for your bug report and patch! Very timely as I just spotted the failure and that it's now a very big problem since sysvinit upload in sid for non-linux. I was pondering either your solution (not shipping uuidd in the uuid-runtime package) or mark the entire uuid-runtime package as linux-any (instead of any). As I see it the main point of uuid-runtime package is to provide uuidd (which is of debatable usefulness I guess), but maybe there's a point in providing only the uuidgen utility on its own (it does not strictly require uuidd). Is there any particular reason you opted to only stop shipping uuidd only? I don't have a clear convincing argument either way but when I try to come up with arguments these are the one I can find: - uuidgen might be useful to have around on all archs? - not touching the debian/control file means I won't risk ending up in NEW. - maybe some day someone does upstream porting work on uuidd and then it's easy to start shipping it again. - still having uuid-runtime package around means it can satisfy the Recommends relation in libuuid1, while it's not really satisfying the reason for the relation - with is uuidd. Neither are very convincing arguments but if you can't present any better then I'll likely go with your patch given I assume it's atleast somewhat tested and gets the FTBFS problem out of the way. Either way, thanks for your input so far... Regards, Andreas Henriksson
Bug#823687: logrotate: Vcs-Svn should point to debian packaging Vcs, not upstream Vcs
Package: logrotate Version: 3.9.1-1~exp1 Severity: normal https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-VCS-fields indicates that Vcs- fields in debian/control should point to the debian packaging. currently, logrotate has: Vcs-Svn: http://svn.fedorahosted.org/svn/logrotate/ This is the upstream svn, and it isn't clear that anything in that repo (tags, trunk, or branches) contains debian packaging. I looked for a debian packaging repository but found nothing (there's an empty CVS repo associated with https://alioth.debian.org/projects/logrotate/). Ideally, the debian packaging would be published in a Vcs someplace, and debian/control would point to it. failing that, the Vcs- fields should just be removed from debian/control. --dkg -- System Information: Debian Release: stretch/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing'), (200, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.4.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)
Bug#823481: libimager-perl: FTBFS: t/200-file/400-basic.t failure
Control: reassign -1 giflib 5.1.4-0.1 Control: affects -1 libimager-perl On Thu, May 05, 2016 at 09:44:19PM +1000, Tony Cook wrote: > On Thu, May 05, 2016 at 10:05:55AM +0300, Niko Tyni wrote: > > t/200-file/400-basic.t .. > > 1..262 > > [...] > > # type gif > > #opening Format: gif, options: file=>GIF/testimg/expected.gif > > ok 69 # Imager=HASH(0x1b10430) > > ok 70 # opening GIF/testimg/expected.gif > > ok 71 # > > ok 72 # seek after read > > ok 73 # > > Dubious, test returned 255 (wstat 65280, 0xff00) > Both Imager 1.004 and 1.005 pass for me with stock giflib 5.1.4 on amd64 (but > I'm running Debian stable) Thanks. It looks like the uninitialized memory bug (Debian #812093 / SF #81) was fixed upstream in a different way [1], but giflib_5.1.4-0.1 still has a (now faulty) version of issue_81patch.diff [2]. The memset() for GifFile is just duplicated, but the one for the Private struct has moved after members (at least Private->FileState and Private->Read) have been assigned to, which is clearly wrong. Dropping issue_81patch.diff altogether makes the libimager-perl test suite pass for me. Reassigning, and copying Matthias. [1] https://sourceforge.net/p/giflib/code/ci/85a75b066df8dc290ef4a411bb7099a9b96c5a56 [2] https://sources.debian.net/src/giflib/5.1.4-0.1/debian/patches/issue81.diff/ -- Niko Tyni nt...@debian.org
Bug#823688: sitesummary: prerm called with unknown argument `upgrade'
Package: sitesummary Version: 0.1.20 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed the maintainer scripts of your package don't support all the ways they are going to be called. See policy 6.5 at https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-mscriptsinstact >From the attached log (scroll to the bottom...): 0m37.5s DEBUG: Starting command: ['chroot', '/tmp/piupartss/tmp5IwKQK', 'apt-get', '-y', 'install', '--reinstall', 'sitesummary=0.1.20'] 0m38.6s DUMP: Reading package lists... Building dependency tree... Reading state information... debconf: delaying package configuration, since apt-utils is not installed 0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded. Need to get 0 B/45.1 kB of archives. After this operation, 0 B of additional disk space will be used. (Reading database ... (Reading database ... 9514 files and directories currently installed.) Preparing to unpack .../sitesummary_0.1.20_all.deb ... prerm called with unknown argument `upgrade' dpkg: warning: subprocess old pre-removal script returned error exit status 1 dpkg: trying script from the new package instead ... prerm called with unknown argument `failed-upgrade' dpkg: error processing archive /var/cache/apt/archives/sitesummary_0.1.20_all.deb (--unpack): subprocess new pre-removal script returned error exit status 1 Errors were encountered while processing: /var/cache/apt/archives/sitesummary_0.1.20_all.deb E: Sub-process /usr/bin/dpkg returned an error code (1) 0m38.6s ERROR: Command failed (status=100): ['chroot', '/tmp/piupartss/tmp5IwKQK', 'apt-get', '-y', 'install', '--reinstall', 'sitesummary=0.1.20'] Cheers, Andreas sitesummary_0.1.20.log.gz Description: application/gzip
