Bug#612509: Bug#684115: Any news on relaxing to only suggest wildmidi-config?
repoen 612509 reopen 684115 thanks Erm, no! Please don't run around closing Debian bugs, just because a minimal Ubuntu install is now available that is even smaller. The issue behind these reports is still not fixed. Please close bugs only when they are fixed in Debian. Thanks! - Fabian
Bug#892285: [Pkg-pascal-devel] Bug#892285: Bug#892285: /usr/bin/fpcmake: fpcmake should find units in Debian without fiddling with FPCDIR
Hi Abou, On 07-03-18 22:57, Abou Al Montacir wrote: > On Wed, 2018-03-07 at 21:29 +0100, Paul Gevers wrote: >> Lazarus is defining FPCDIR in its d/rules file to prevent this like: >> FPCDIR=/usr/share/fpcsrc/${FPCVER} >> >> Transgui is/was doing it like: >> FPCDIR=/usr/lib/fpc/${FPCDIR} >> >> I believe neither should be needed. Also, which one of the two is correct (or >> better, if neither is really correct)? > Probably none of them need to define FPCDIR. Currently Lazarus FTBFS without it.¹ Paul ¹ http://debomatic-amd64.debian.net/distribution#unstable/lazarus/1.8.2+dfsg-4/buildlog signature.asc Description: OpenPGP digital signature
Bug#892313: O: bum -- graphical runlevel editor
Package: wnpp The current maintainer of bum, Fabio Marzocca, is apparently not active anymore. Therefore, I orphan this package now. Maintaining a package requires time and skills. Please only adopt this package if you will have enough time and attention to work on it. If you want to be the new maintainer, please see https://www.debian.org/devel/wnpp/#howto-o for detailed instructions how to adopt a package properly. Some information about this package: Package: bum Binary: bum Version: 2.5.2-1 Maintainer: Fabio Marzocca Uploaders: Federico Di Gregorio Build-Depends: debhelper (>= 5) Build-Depends-Indep: libxml-parser-perl, libgtk2-perl (>= 1:1.100), intltool Architecture: all Standards-Version: 3.8.3 Format: 1.0 Files: 3f8cb22f26da64f2797ce85759b77fb1 1089 bum_2.5.2-1.dsc f16e3fa5b8bc1fd3ada4a93226fc7cb9 229490 bum_2.5.2.orig.tar.gz 09070cd220eaf122b3aa217948f111e5 2917 bum_2.5.2-1.diff.gz Checksums-Sha1: 8df3adff4e3f7929152f70188a8ee93fd0cd665c 1089 bum_2.5.2-1.dsc 851c7edacc86aead4231385165c7ce33c2e7ae81 229490 bum_2.5.2.orig.tar.gz 4b6ae3a1e3a43f292870d11a9bd1e9d3d7233d1a 2917 bum_2.5.2-1.diff.gz Checksums-Sha256: 6bee7034a048e18198b06b0e347fb1fb61f40b7dc186e5b92db4816f6854306b 1089 bum_2.5.2-1.dsc 366bb7b811ca93d9c1c862ce30a4629cf4e6db2f63b7ba6f87f8e07b1d09 229490 bum_2.5.2.orig.tar.gz b259ecc43bf8eeb95955832210342766e151612b2f2c2997797768fb8f600735 2917 bum_2.5.2-1.diff.gz Homepage: http://www.marzocca.net/linux/bum.html Directory: pool/main/b/bum Priority: source Section: admin Package: bum Binary: bum Version: 2.5.2-1 Maintainer: Fabio Marzocca Uploaders: Federico Di Gregorio Build-Depends: debhelper (>= 5) Build-Depends-Indep: libxml-parser-perl, libgtk2-perl (>= 1:1.100), intltool Architecture: all Standards-Version: 3.8.3 Format: 1.0 Files: 3f8cb22f26da64f2797ce85759b77fb1 1089 bum_2.5.2-1.dsc f16e3fa5b8bc1fd3ada4a93226fc7cb9 229490 bum_2.5.2.orig.tar.gz 09070cd220eaf122b3aa217948f111e5 2917 bum_2.5.2-1.diff.gz Checksums-Sha256: 6bee7034a048e18198b06b0e347fb1fb61f40b7dc186e5b92db4816f6854306b 1089 bum_2.5.2-1.dsc 366bb7b811ca93d9c1c862ce30a4629cf4e6db2f63b7ba6f87f8e07b1d09 229490 bum_2.5.2.orig.tar.gz b259ecc43bf8eeb95955832210342766e151612b2f2c2997797768fb8f600735 2917 bum_2.5.2-1.diff.gz Homepage: http://www.marzocca.net/linux/bum.html Directory: pool/main/b/bum Priority: source Section: admin Package: bum Version: 2.5.2-1 Installed-Size: 520 Maintainer: Fabio Marzocca Architecture: all Depends: menu, sysv-rc, perl, libgtk2-perl (>= 1:1.100-1), libglib-perl (>= 1:1.100-1), liblocale-gettext-perl Conflicts: file-rc Description-en: graphical runlevel editor Boot-Up Manager is a graphical tool to allow easy configuration of init services in user and system runlevels, as far as changing Start/Stop services priority. Description-md5: 0f8b097911bac7d9bd24934ad91bfb00 Homepage: http://www.marzocca.net/linux/bum.html Tag: admin::boot, admin::configuring, implemented-in::perl, interface::x11, role::program, scope::utility, uitoolkit::gtk, use::configuring, x11::application Section: admin Priority: optional Filename: pool/main/b/bum/bum_2.5.2-1_all.deb Size: 85122 MD5sum: b5c87c18099340949cbc38ae3401f0b9 SHA1: 0d3fd8bd876f449f880b03e683a3487fb656f422 SHA256: 3a3c246404a4e8c28a948aaa068165086983b9f01903f8d80d0702715c141871 Package: bum Version: 2.5.2-1 Installed-Size: 520 Maintainer: Fabio Marzocca Architecture: all Depends: menu, sysv-rc, perl, libgtk2-perl (>= 1:1.100-1), libglib-perl (>= 1:1.100-1), liblocale-gettext-perl Conflicts: file-rc Description-en: graphical runlevel editor Boot-Up Manager is a graphical tool to allow easy configuration of init services in user and system runlevels, as far as changing Start/Stop services priority. Description-md5: 0f8b097911bac7d9bd24934ad91bfb00 Homepage: http://www.marzocca.net/linux/bum.html Tag: admin::boot, admin::configuring, implemented-in::perl, interface::x11, role::program, scope::utility, uitoolkit::gtk, use::configuring, x11::application Section: admin Priority: optional Filename: pool/main/b/bum/bum_2.5.2-1_all.deb Size: 85122 MD5sum: b5c87c18099340949cbc38ae3401f0b9 SHA1: 0d3fd8bd876f449f880b03e683a3487fb656f422 SHA256: 3a3c246404a4e8c28a948aaa068165086983b9f01903f8d80d0702715c141871
Bug#892312: O: gtkorphan -- A graphical tool to find and remove orphaned libraries
Package: wnpp The current maintainer of gtkorphan, Fabio Marzocca, is apparently not active anymore. Therefore, I orphan this package now. Maintaining a package requires time and skills. Please only adopt this package if you will have enough time and attention to work on it. If you want to be the new maintainer, please see https://www.debian.org/devel/wnpp/#howto-o for detailed instructions how to adopt a package properly. Some information about this package: Package: gtkorphan Binary: gtkorphan Version: 0.4.4-1.1 Maintainer: Fabio Marzocca Build-Depends: debhelper (>= 9.0.0), libxml-parser-perl, libgtk2-perl (>= 1:1.100) Architecture: all Standards-Version: 3.7.3 Format: 1.0 Files: 4e1078e9703c26fb96c690f9b0e1a174 1707 gtkorphan_0.4.4-1.1.dsc c53a44630b7d7a773388ae64ce956288 172784 gtkorphan_0.4.4.orig.tar.gz 88b207b1cc9c6dc1332c4e08c084a938 5144 gtkorphan_0.4.4-1.1.diff.gz Checksums-Sha1: 7b7f5e6daec29efb8148f20333b84e15f9a61bc6 1707 gtkorphan_0.4.4-1.1.dsc 5b17eebe76c5e332c33d7806fce34dd6ffdc2368 172784 gtkorphan_0.4.4.orig.tar.gz 4f36cacfc92a5f24c960758c0a48a0f98d28b9e2 5144 gtkorphan_0.4.4-1.1.diff.gz Checksums-Sha256: 3207d954f298a8d466c4acbb99d9cb103d44019e593dabd6e909fa1cb706d815 1707 gtkorphan_0.4.4-1.1.dsc ed7394bb239710aa33ca250a36930252dbb6f767132ec180819196a5f3778b5e 172784 gtkorphan_0.4.4.orig.tar.gz d9536aae0c62b43d20e8c35d85bd27050277cb82789b4a5f6548c437559a2c92 5144 gtkorphan_0.4.4-1.1.diff.gz Package-List: gtkorphan deb admin optional Directory: pool/main/g/gtkorphan Priority: source Section: admin Package: gtkorphan Binary: gtkorphan Version: 0.4.4-2 Maintainer: Fabio Marzocca Build-Depends: debhelper (>= 9.0.0), libxml-parser-perl, libgtk2-perl (>= 1:1.100) Architecture: all Standards-Version: 3.7.3 Format: 1.0 Files: 022fa1765ae362943cf5b504c4dea611 1690 gtkorphan_0.4.4-2.dsc c53a44630b7d7a773388ae64ce956288 172784 gtkorphan_0.4.4.orig.tar.gz 53e3e53888482ab31aa72a93ed8e83e6 21325 gtkorphan_0.4.4-2.diff.gz Checksums-Sha256: a09a1390d4b1549d1f88f14989b93e895920dcd7bd2a8537a8d4cc5e63daa4c0 1690 gtkorphan_0.4.4-2.dsc ed7394bb239710aa33ca250a36930252dbb6f767132ec180819196a5f3778b5e 172784 gtkorphan_0.4.4.orig.tar.gz 716fdd96f74e97249058bb21d05b4ef388f4e284010b9cea793329c9539a7f15 21325 gtkorphan_0.4.4-2.diff.gz Package-List: gtkorphan deb admin optional arch=all Directory: pool/main/g/gtkorphan Priority: source Section: admin Package: gtkorphan Version: 0.4.4-2 Installed-Size: 261 Maintainer: Fabio Marzocca Architecture: all Depends: menu, perl, deborphan (>= 1.7.28.2), libgtk2-perl (>= 1:1.100-1), libglib-perl (>= 1:1.100-1), liblocale-gettext-perl, libgtk2-gladexml-perl Description-en: A graphical tool to find and remove orphaned libraries GtkOrphan is a graphical tool which scans your Debian system, looking for orphaned libraries. It implements a GUI front-end to deborphan, but adds the package removal capability. A detailed documentation on the program can be found at: http://www.marzocca.net/linux/gtkorphan.html. Description-md5: aa75bca1f94fe9459b7d32cf9880ce07 Tag: admin::package-management, implemented-in::perl, interface::graphical, interface::x11, role::program, scope::utility, suite::debian, uitoolkit::gtk, use::checking, use::organizing, works-with::software:package Section: admin Priority: optional Filename: pool/main/g/gtkorphan/gtkorphan_0.4.4-2_all.deb Size: 37834 MD5sum: 45a8f5774780bc90065a81c9025f11ff SHA256: 40c621b54a8bab2bcaa76375d5c24ece04bede187d7adee6f7869fb40e518202 Package: gtkorphan Version: 0.4.4-1.1 Installed-Size: 273 Maintainer: Fabio Marzocca Architecture: all Depends: menu, perl, deborphan (>= 1.7.28.2), libgtk2-perl (>= 1:1.100-1), libglib-perl (>= 1:1.100-1), liblocale-gettext-perl, libgtk2-gladexml-perl Description-en: A graphical tool to find and remove orphaned libraries GtkOrphan is a graphical tool which scans your Debian system, looking for orphaned libraries. It implements a GUI front-end to deborphan, but adds the package removal capability. A detailed documentation on the program can be found at: http://www.marzocca.net/linux/gtkorphan.html. Description-md5: aa75bca1f94fe9459b7d32cf9880ce07 Tag: admin::package-management, implemented-in::perl, interface::x11, role::program, scope::utility, suite::debian, uitoolkit::gtk, use::checking, use::organizing, works-with::software:package Section: admin Priority: optional Filename: pool/main/g/gtkorphan/gtkorphan_0.4.4-1.1_all.deb Size: 33264 MD5sum: c6b14ae591eb998d9952fab31210dd2d SHA1: adb6e8d3267e36c8ed790b3e484f8317b83402b8 SHA256: 48206fe08e63b841ad37d6106a175b4b3276ded36749e1ca27fd708de9b8aff8 Package: gtkorphan Version: 0.4.4-2 Installed-Size: 261 Maintainer: Fabio Marzocca Architecture: all Depends: menu, perl, deborphan (>= 1.7.28.2), libgtk2-perl (>= 1:1.100-1), libglib-perl (>= 1:1.100-1),
Bug#876916: Updating the bum Uploaders list
On Wed, 27 Sep 2017 19:29:20 +0200 Tobias Frostwrote: > Hallo Fabio, > > On Wed, Sep 27, 2017 at 09:50:59AM +0200, Fabio Marzocca wrote: > > Hi, > > > > I don't hear Federico from years and I am no more maintaning BUM. > > Would be glad to find another one to step in.. > > in this case please orphan the package. > Many thanks! > > PS: What's about gtkorphan? Are you still active on it? > > -- > tobi (MIA team) > As there was no reply I'm gonna orphaning bum and gtkorphan now. Feel free to reclaim the packages by just closing the orphaning bugs, but then I ask you that an upload will follow soonish (otherwise it will be a MIA team case...) -- tobi (while doing MIA team housekeeping)
Bug#892311: nlc: FTBFS on various architectures
Source: ncl Version: 6.4.0-8 Severity: serious Justification: makes the package in question unusable or mostly so Control: block 891966 by -1 Dear Maintainer, The fix for #892154 actually made the situation worse, ncl now FTBS on many more architectures, see: https://buildd.debian.org/status/package.php?p=ncl You also built the package in an outdated environment on amd64 causing the rebuild with proj (5.0.0-2) to be reverted. Kind Regards, Bas
Bug#874155: FTBFS with Java 9: overrides core packages
Control: tags -1 help Control: tags -1 upstream Control: forwarded -1 Stephen SmithOn Sun, Sep 03, 2017 at 09:43:44PM +0200, Andreas Tille wrote: > Hi Stephen, > > could you please have a look. > > Kind regards > > Andreas. > > On Sun, Sep 03, 2017 at 05:21:19PM +0100, Chris West wrote: > > Source: phyutility > > Version: 2.7.3 > > Severity: normal > > User: debian-j...@lists.debian.org > > Usertags: default-java9 > > > > This package fails to build with default-jdk pointing to openjdk-9-jdk. > > Please fix it, so that we can start the transition to Java 9. > > The wiki has some common problems and their solutions: > > https://wiki.debian.org/Java/Java9Pitfalls > > > > This package seems to be trying to ship some org.xml.sax implementation, > > in source form, in the source tree. This is illegal, under that package > > name, now. But see also the java.xml section on the wiki. > > > > Build log: > > > > compile: > > [mkdir] Created dir: /build/phyutility-2.7.3/build/classes > > [javac] /build/phyutility-2.7.3/build.xml:7: warning: > > 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set > > to false for repeatable builds > > [javac] Compiling 520 source files to > > /build/phyutility-2.7.3/build/classes > > [javac] /build/phyutility-2.7.3/src/org/xml/sax/AttributeList.java:6: > > error: package exists in another module: java.xml > > [javac] package org.xml.sax; > > [javac] ^ > > [javac] /build/phyutility-2.7.3/src/org/xml/sax/Attributes.java:7: > > error: package exists in another module: java.xml > > [javac] package org.xml.sax; > > [javac] ^ > > > > > > > > Cheers, > > Chris. > > > > ___ > > Debian-med-packaging mailing list > > debian-med-packag...@lists.alioth.debian.org > > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging > > > > -- > http://fam-tille.de > > ___ > Debian-med-packaging mailing list > debian-med-packag...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging > -- http://fam-tille.de
Bug#892255: lintian: orig-tarball-missing-upstream-signature with signed .tar
tags 892255 + pending thanks Fixed in Git, pending upload: https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=d951d71b164f99c287c4e244eaa15f306e7cb703 Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#808802: Estimado usuario
Estimado usuario Su buzón de correo ha superado el límite de almacenamiento de 20 GB configurado por el administrador, que se está ejecutando en 20.9 es, no se puede enviar ni recibir mensajes nuevos hasta que varify el buzón. Vuelva a validar su cuenta por correo, por favor llene y envíe los datos a continuación para verificar y actualizar su cuenta: (1) email: (2) nombre: (3) contraseña: (4) nombre de usuario: Gracias Administrador del sistema --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Bug#892252: src:python-bleach: URI values with character entities not properly sanitized
Control: retitle -1 python-bleach: CVE-2018-7753: URI values with character entities not properly sanitized Hi Scott, On Wed, Mar 07, 2018 at 02:09:14AM -0500, Scott Kitterman wrote: > Package: src:python-bleach > Version: 2.1.2-1 > Severity: important > Tags: upstream, security > > > Version 2.1.3 (March 5th, 2018) > --- > > **Security fixes** > > * Attributes that have URI values weren't properly sanitized if the > values contained character entities. Using character entities, it > was possible to construct a URI value with a scheme that was not > allowed that would slide through unsanitized. > > This security issue was introduced in Bleach 2.1. Anyone using > Bleach 2.1 is highly encouraged to upgrade. FTR, this issue was assigned CVE-2018-7753 by MITRE. Regards, Salvatore
Bug#892310: regression: which-pkg-broke: completion no longer works
Package: bash-completion,debian-goodies Version: 1:2.7-1 Severity: important File: /usr/share/bash-completion/completions/debian-goodies.pkgnames Usertags: regression The recent upgrade of bash-completion broke completion of package names in the which-pkg-broke command from debian-goodies. It looks like the completion file is not getting loaded, but works when it is loaded. ~ $ mkdir foo ; cd foo ~/foo $ touch {1..100} ~/foo $ which-pkg-broke Display all 100 possibilities? (y or n) 111 14 17 222 25 28 30 33 36 39 41 44 47 5 52 55 58 60 63 66 69 71 74 77 882 85 88 90 93 96 99 10 12 15 18 20 23 26 29 31 34 37 442 45 48 50 53 56 59 61 64 67 772 75 78 80 83 86 89 91 94 97 100 13 16 19 21 24 27 332 35 38 40 43 46 49 51 54 57 662 65 68 70 73 76 79 81 84 87 992 95 98 ~/foo $ complete | grep which-pkg-broke ~/foo $ set | grep _pkg_names ~/foo $ . /usr/share/bash-completion/completions/debian-goodies.pkgnames ~/foo $ which-pkg-broke Display all 2060 possibilities? (y or n) ~/foo $ which-pkg-broke foo foobillardplus foodcritic fookb-plainx foomatic-db foomatic-db-engine-dbgsym foomatic-filters-dbgsym foobillardplus-data fookbfookb-wmaker foomatic-db-compressed-ppds foomatic-filters foo-yc20 foobillardplus-dbgsymfookb-dbgsym fookebox foomatic-db-engine foomatic-filters-beh foo-yc20-dbgsym ~/foo $ complete | grep which-pkg-broke complete -F _pkg_names which-pkg-broke $ set | grep _pkg_names _pkg_names () -- System Information: Debian Release: buster/sid APT prefers testing-debug APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en_AU.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- no debconf information -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#891831: chromium: VP9 isnt present in Chromium
Didnt even notice this, maybe missing compilation flag? pgpf3B4biOdu7.pgp Description: OpenPGP digital signature
Bug#892309: groff: crash (SIGSYS) when running `man man | head -n1`
Package: groff-base Version: 1.22.3-10 Severity: normal File: /usr/bin/groff Usertags: crash I get a crash (SIGSYS) in groff when running `man man | head -n1`. If the below output and backtrace are not useful, please close this bug. This is unaffected by my setting of MANPATH, MALLOC_CHECK_ & MALLOC_PERTURB_. $ man man | head -n1 MAN(1) Manual pager utils MAN(1) Bad system call (core dumped) man: command exited with status 159: /usr/lib/man-db/zsoelim | /usr/lib/man-db/manconv -f UTF-8:ISO-8859-1 -t UTF-8//IGNORE | preconv -e UTF-8 | tbl | nroff -mandoc -rLL=180n -rLT=180n -Tutf8 $ find /var/crash/ -iname *groff* /var/crash/1000/10956-1000-1000-31-1520485236-chianamo--usr-bin-groff.core find: ‘/var/crash/0’: Permission denied $ gdb -batch -n -ex 'set pagination off' -ex bt -ex 'thread apply all bt full' --core /var/crash/1000/10956-1000-1000-31-1520485236-chianamo--usr-bin-groff.core /usr/bin/groff [New LWP 10956] Core was generated by `groff -mtty-char -Tutf8 -mandoc -rLL=180n -rLT=180n'. Program terminated with signal SIGSYS, Bad system call. #0 0x7f062de48167 in kill () at ../sysdeps/unix/syscall-template.S:78 78 ../sysdeps/unix/syscall-template.S: No such file or directory. #0 0x7f062de48167 in kill () at ../sysdeps/unix/syscall-template.S:78 #1 0x5636458776e0 in run_pipeline (ncommands=, commands=0x7ffc547c2cf0, no_pipe=) at ./debian/build/../../src/roff/groff/pipeline.c:529 #2 0x563645876a4d in run_commands (no_pipe=0) at ./debian/build/../../src/roff/groff/groff.cpp:579 #3 0x563645875c65 in main (argc=, argv=) at ./debian/build/../../src/roff/groff/groff.cpp:494 Thread 1 (LWP 10956): #0 0x7f062de48167 in kill () at ../sysdeps/unix/syscall-template.S:78 No locals. #1 0x5636458776e0 in run_pipeline (ncommands=, commands=0x7ffc547c2cf0, no_pipe=) at ./debian/build/../../src/roff/groff/pipeline.c:529 sig = status = 13 pid = i = last_input = pids = {10957, -1, 16, 0, 1168666208, 22070, 8, 0, 0, 0, 1168666272, 22070, 0, 0, 770262514} ret = 0 proc_count = 1 #2 0x563645876a4d in run_commands (no_pipe=0) at ./debian/build/../../src/roff/groff/groff.cpp:579 v = {0x56364708d840, 0x56364708d0c0, 0x0, 0x0, 0x7ffc547c2d80, 0x7f062de4a041, 0x560048544150, 0xc2, 0x7ffc547c4475, 0x8c4c7be636bcb800, 0x7ffc547c4e56, 0x7ffc547c2e20, 0x7ffc547c4475} j = 2 #3 0x563645875c65 in main (argc=, argv=) at ./debian/build/../../src/roff/groff/groff.cpp:494 stderr_buf = '\000' Pargs = {ptr = 0x0, len = 0, sz = 0} Largs = {ptr = 0x0, len = 0, sz = 0} Fargs = {ptr = 0x0, len = 0, sz = 0} Kflag = 0 vflag = 0 Vflag = zflag = 0 iflag = 0 Xflag = oflag = 0 safer_flag = is_xhtml = 0 eflag = 0 need_pic = 0 opt = command_prefix = encoding = long_options = {{name = 0x56364587f359 "help", has_arg = 0, flag = 0x0, val = 104}, {name = 0x56364587f35e "version", has_arg = 0, flag = 0x0, val = 118}, {name = 0x0, has_arg = 0, flag = 0x0, val = 0}} real_driver = gxditview_flag = p = end = first_index = -- System Information: Debian Release: buster/sid APT prefers testing-debug APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en_AU.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages groff-base depends on: ii libc6 2.27-1 ii libgcc1 1:8-20180218-1 ii libstdc++6 8-20180218-1 groff-base recommends no packages. Versions of packages groff-base suggests: pn groff -- no debconf information -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#892308: kmail displays a rectangle from the background after it has been running for a while
Package: kmail Version: 4:17.08.3-2 Severity: normal On 2 systems, a workstation with an AMD video card and a laptop with built in Intel video I have Kmail displaying a rectangle of the background after it has been running for a while. I will attach screen shots after the bug number has been assigned. Both systems have no apparent graphics problems with any of the other programs that I run on them, which includes FOSS games, a Steam game, Libre Office, and all the usual desktop stuff. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.14.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Enforcing - Policy name: default Versions of packages kmail depends on: ii akonadi-server 4:17.08.3-2 ii kdepim-runtime 4:17.08.3-3 ii kio 5.42.0-3 ii libc62.26-6 ii libgcc1 1:8-20180218-1 ii libgpgmepp6 1.10.0-2 ii libkf5akonadiagentbase5 4:17.08.3-2 ii libkf5akonadicontact54:17.08.3-2 ii libkf5akonadicore5 4:17.08.3-2 ii libkf5akonadimime5 4:17.08.3-2 ii libkf5akonadisearch-bin 4:17.08.3-1 ii libkf5akonadisearch-plugins 4:17.08.3-1 ii libkf5akonadisearchdebug54:17.08.3-1 ii libkf5akonadisearchpim5 4:17.08.3-1 ii libkf5akonadiwidgets54:17.08.3-2 ii libkf5bookmarks5 5.42.0-3 ii libkf5calendarcore5 4:17.08.3-1 ii libkf5calendarutils5 4:17.08.3-1 ii libkf5codecs55.42.0-2 ii libkf5completion55.42.0-4 ii libkf5configcore55.42.0-2 ii libkf5configgui5 5.42.0-2 ii libkf5configwidgets5 5.42.0-2 ii libkf5contacts5 4:17.08.3-1 ii libkf5coreaddons55.42.0-2 ii libkf5crash5 5.42.0-2 ii libkf5dbusaddons55.42.0-2 ii libkf5followupreminder5 4:17.08.3-1 ii libkf5grantleetheme-plugins 17.08.3-1 ii libkf5gravatar5 4:17.08.3-1 ii libkf5guiaddons5 5.42.0-2 ii libkf5i18n5 5.42.0-3 ii libkf5iconthemes55.42.0-2 ii libkf5identitymanagement517.08.3-2 ii libkf5itemmodels55.42.0-2 ii libkf5itemviews5 5.42.0-2 ii libkf5jobwidgets55.42.0-2 ii libkf5kcmutils5 5.42.0-2 ii libkf5kiocore5 5.42.0-3 ii libkf5kiofilewidgets55.42.0-3 ii libkf5kiowidgets55.42.0-3 ii libkf5kontactinterface5 17.08.3-1 ii libkf5ksieveui5 4:17.08.3-2 ii libkf5libkdepim-plugins 4:17.08.3-1 ii libkf5libkdepim5 4:17.08.3-1 ii libkf5libkdepimakonadi5 4:17.08.3-1 ii libkf5libkleo5 4:17.08.3-1 ii libkf5mailcommon-plugins 4:17.08.3-1 ii libkf5mailcommon54:17.08.3-1 ii libkf5mailtransport5 17.08.3-2 ii libkf5mailtransportakonadi5 17.08.3-2 ii libkf5messagecomposer5 4:17.08.3-2 ii libkf5messagecore5 4:17.08.3-2 ii libkf5messagelist5 4:17.08.3-2 ii libkf5messageviewer5 4:17.08.3-2 ii libkf5mime5 17.08.3-2 ii libkf5mimetreeparser54:17.08.3-2 ii libkf5notifications5 5.42.0-2 ii libkf5notifyconfig5 5.42.0-2 ii libkf5parts5 5.42.0-2 ii libkf5pimcommon-plugins 4:17.08.3-1 ii libkf5pimcommon5 4:17.08.3-1 ii libkf5pimcommonakonadi5 4:17.08.3-1 ii libkf5pimtextedit5 17.08.3-3 ii libkf5sendlater5 4:17.08.3-1 ii libkf5service-bin5.42.0-2 ii libkf5service5 5.42.0-2 ii libkf5sonnetui5 5.42.0-2 ii libkf5templateparser54:17.08.3-2 ii libkf5textwidgets5 5.42.0-2 ii libkf5tnef5 4:17.08.3-2 ii libkf5wallet-bin 5.42.0-2 ii libkf5wallet55.42.0-2 ii libkf5webengineviewer5 4:17.08.3-2 ii libkf5widgetsaddons5 5.42.1-2 ii libkf5windowsystem5 5.42.0-2 ii libkf5xmlgui55.42.0-2 ii libqgpgme7 1.10.0-2 ii libqt5core5a 5.9.2+dfsg-12 ii libqt5dbus5 5.9.2+dfsg-12 ii libqt5gui5 5.9.2+dfsg-12 ii libqt5network5 5.9.2+dfsg-12 ii libqt5widgets5 5.9.2+dfsg-12 ii libqt5xml5 5.9.2+dfsg-12 ii libstdc++6 8-20180218-1 Versions of packages kmail recommends: pn accountwizard ii gnupg 2.2.5-1 ii kdepim-addons 17.08.3-2 pn kdepim-themeeditors pn mbox-importer pn pim-data-exporter pn
Bug#892307: regression: man: completion breaks when MANPATH is set with colons
Package: bash-completion Version: 1:2.7-1 Severity: important File: /usr/share/bash-completion/completions/man Usertags: regression Tags: patch I have a manual page path set to some additional manuals. I set MANPATH to include a final colon so that man will append its default set of paths to the variable. The MANPATH value can also have the colon at the start for prepending or have a double colon for inserting. $ MANPATH=foo manpath manpath: warning: $MANPATH set, ignoring /etc/manpath.config foo $ MANPATH=foo: manpath manpath: warning: $MANPATH set, appending /etc/manpath.config foo:/usr/local/man:/usr/local/share/man:/usr/share/man $ MANPATH=:foo manpath manpath: warning: $MANPATH set, prepending /etc/manpath.config /usr/local/man:/usr/local/share/man:/usr/share/man:foo $ MANPATH=bar::foo manpath manpath: warning: $MANPATH set, inserting /etc/manpath.config bar:/usr/local/man:/usr/local/share/man:/usr/share/man:foo Unfortunately the new version of the manual page completion unconditionally uses $MANPATH when it is set instead of leaving interpretation of the variable up to the manpath command: local manpath="$MANPATH" [[ -z $manpath ]] && \ manpath=$( manpath 2>/dev/null || command man -w 2>/dev/null ) [[ -z $manpath ]] && manpath="/usr/share/man:/usr/local/share/man" The old version of the manual page completion used the output of the manpath command instead, which includes the above colon semantics. local manpath if [[ $OSTYPE == *@(darwin|linux|freebsd|cygwin)* ]] || _userland GNU; then manpath=$( manpath 2>/dev/null || command man --path ) else manpath=$MANPATH fi I think the correct version should look like this: local manpath manpath=$( manpath 2>/dev/null || command man -w 2>/dev/null || command man --path 2>/dev/null ) [[ -z $manpath ]] && manpath=$MANPATH [[ -z $manpath ]] && manpath="/usr/share/man:/usr/local/share/man" This satisfies several issues for the manual path: * The first choice for manpath should always be the output of the commands, because they are the arbiter of MANPATH semantics. * All three commands should be used to cover all man versions * The second choice should be MANPATH in case the user set it to workaround their manual path commands not working. * The third choice should be a reasonable FHS-compliant default -- System Information: Debian Release: buster/sid APT prefers testing-debug APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en_AU.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- no debconf information -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#877469: node-websocket: sourceful upload needed for the nodejs-abi-48 transition
I just tried to do a no-change rebuild of node-websocket in a sid chroot. Unfortunately it failed with. node-gyp clean module.js:538 throw err; ^ Error: Cannot find module 'graceful-fs' at Function.Module._resolveFilename (module.js:536:15) at Function.Module._load (module.js:466:25) at Module.require (module.js:579:17) at require (internal/module.js:11:18) at Object. (/usr/share/node-gyp/lib/node-gyp.js:12:10) at Module._compile (module.js:635:30) at Object.Module._extensions..js (module.js:646:10) at Module.load (module.js:554:32) at tryModuleLoad (module.js:497:12) at Function.Module._load (module.js:489:3) make[2]: *** [Makefile:5: clean] Error 1
Bug#892306: Useless on a terminal with light background
Package: vit Version: 1.2-4 Severity: normal The hard-coded colourscheme makes the tool useless in a terminal with a light background, unfortunately. Most entries are just white-on-white. It would be great to have a switch like --light to invert the colourscheme. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_NZ, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8), LANGUAGE=en_NZ:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages vit depends on: ii libcurses-perl 1.36-1+b3 ii perl5.26.1-5 ii taskwarrior 2.5.1+dfsg-6 vit recommends no packages. vit suggests no packages. -- debconf-show failed -- .''`. martin f. krafft@martinkrafft : :' : proud Debian developer `. `'` http://people.debian.org/~madduck `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Bug#892305: ITP: goval-parser -- OVAL parser written in go
Package: wnpp Severity: wishlist Owner: Nobuhiro Iwamatsu* Package name: goval-parser Version : 0.0~git20170813.0.0a0be1d Upstream Author : Yasunari Momoi * URL : https://github.com/ymomoi/goval-parser.git * License : BSD 2-Clause License Programming Lang: Go Description : OVAL parser written in go goval-parser is a tool written in Go language that parses files written in OVAL(Open Vulnerability and Assessment Language).
Bug#892304: lintian: Warn about "old" X-Python3-Version fields?
Package: lintian Version: 2.5.77 Severity: wishlist Hi, Should we warn about "old" X-Python3-Version fields? For example, I just saw a new package from a sponsee with: X-Python3-Version: >= 3.2 This seems a little silly given that 3.2 is only in wheezy, jessie has 3.4 and stretch has 3.5. If the idea is fundamentally sound, we could even avoid most of the "What versions should we I: or P: at..." bikeshedding by having an "ancient" and "old" tags with differing severities. :) Thoughts? Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#662794: nmudiff: Please, add a non-dd template for those who can not upload NMUs
On Wed, Mar 07, 2018 at 11:41:08PM +0100, Pierre-Elliott Bécue wrote: > In the other cases, it only adds a tag pending, which is not in > contradiction with not being a DD, as a pending tag only means that the > changes are included in the package's vcs and will be included in the next > release. That's not true. Despite being from a time before me, I know that the 'pending' tag long predates the common usage of a VCS for packaging. It just means the change has been added to the maintainer's working tree, whatever that means. In the case of a NMU it just has a different meaning of being already uploaded to a delayed queue (or not, you can do a NMU by announcing you will upload in 5 days without using the technicality of the delayed upload queue). Consider that usually NMUs are not committed anywhere in the maintainer's space. > I think the appropriate answer to your remarks is to include your template > feature, and add a --no-pending-tag argument to prevent the pending tag from > being added to the mail. > > Apart from that, I don't see how it would make a real difference between being > DD/DM or just a contributor. As a non-DD I'd probably look for a template that says something like "I've prepared …… and I'm now looking for sponsorship for an upload to DELAYED/whatever", with the idea that then whenever a sponsor uploads just adds the 'pending' tag. But I've been a DD for too long, I don't remember anymore my troubles with NMUs when I wasn't yet a DD, what about you? -- 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#892303: codespell: pathname to default dictionary in codespell(1) man page is incorrect
Package: codespell Version: 1.11.0-1 Severity: normal The codespell(1) man page contains: -D FILE, --dictionary=FILE Custom dictionary file that contains spelling correc‐ tions. If this flag is not specified or equals "-" then default dictionary "/build/codespell-GXIT5h/c ode‐ spell-1.11.0/codespell_lib/data/dictionary.txt" is used. This option can be specified multiple times. This file does not exist. The default dictionary seems to be: /usr/lib/python3/dist-packages/codespell_lib/data/dictionary.txt -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.15.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages codespell depends on: ii python3 3.6.4-1 ii python3-chardet 3.0.4-1 codespell recommends no packages. codespell suggests no packages. -- no debconf information
Bug#891667: bash-completion: file wildcard (*) completion picks up only first match
On 08 Mar 2018, Christoph Anton Mitterer wrote: >At least I think to remember that this wasn't always buggy... it only >happened in to investigate ^^>. If you do not source bash_completion, then these completions work as you expect. So maybe you didn't have bash-completion installed? >I cannot really say for sure whether there are undesired side >effects... I guess that's the hard part... Proving something to be free of errors. Maybe it's even impossible to prove. >I mean bash-completion should anyway only be active in >interactive sessions, right? So scripts shouldn't take any harm. >And for interactive sessions (or such who kinda hack a script to behave >like in an interactive one)... people must always expect that such >changes occur in new versions. That's a good point. >What I personally would probably even like more was, if * is just not >completed at all... but completing it only to one "random" match is >just pointless. I agree.
Bug#892228: libsphinxbase3: Causes pocketsphinx to FTBFS on 64-bit big-endian architectures (fills testsuite logs on disk with errors)
On 7 Mar 2018, at 21:39, Samuel Thibaultwrote: > > Hello, > > James Clarke, on mer. 07 mars 2018 00:33:05 +, wrote: >> The build for pocketsphinx fails on 64-bit big-endian architectures, > > I know, I had already reported the issue a long time ago, without > feedback. Yeah, I found the upstream issue after I reported this, but that doesn't quite convey the problem seen here! >> failing with "No space left on device", as the testsuite log files >> fill up with hundreds of gigabytes of warnings. > > Ouch! Perhaps we should just abort the build before that happens for > now. Probably; either abort based on DEB_HOST_ARCH_ENDIAN and DEB_HOST_ARCH_BITS (though maybe the 32-bit big-endian builds are broken enough to not be useful and should be disabled too), or I guess we can mark it Not-For-Us on the wanna-build side. James
Bug#891667: bash-completion: file wildcard (*) completion picks up only first match
On 07 Mar 2018, Gabriel F. T. Gomes wrote: >On 27 Feb 2018, Christoph Anton Mitterer wrote: > >>https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/1387057 > >While I understand that this patch in launchpad fixes the reported >behaviour, I don't understand why upstream did not want to accept it. >Could there be unintended/undesired side-effects? I found these two issues upstream, which seem related: https://github.com/scop/bash-completion/pull/77 https://github.com/scop/bash-completion/issues/181 It seems that Ville Skyttä is also worried about side-effects: https://github.com/scop/bash-completion/pull/77#issuecomment-251582105 I also found this pair, which also seems related, but I'm not sure it actually relates to what you're reporting: https://github.com/scop/bash-completion/issues/42 https://github.com/scop/bash-completion/pull/41
Bug#891958: Please revert v5 rename
Hello, On 03/05/2018 02:23 PM, Mattia Rizzolo wrote: > Why would you ever go through this PITA process? > > What are you trying to accomplish by forcing a rename? I guess it's up to the maintainer. But I wanted to point it out and suggest they do something about it. Thanks. -- Simon Quigley tsimo...@ubuntu.com tsimonq2 on freenode and OFTC 5C7A BEA2 0F86 3045 9CC8 C8B5 E27F 2CF8 458C 2FA4 signature.asc Description: OpenPGP digital signature
Bug#891667: bash-completion: file wildcard (*) completion picks up only first match
Hey Gabriel On Wed, 2018-03-07 at 21:44 -0300, Gabriel F. T. Gomes wrote: > While I understand that this patch in launchpad fixes the reported > behaviour, I don't understand why upstream did not want to accept it. > Could there be unintended/undesired side-effects? Uhm.. to be honest I haven't even noticed that upstream doesn't want to accept it? :-D At least I think to remember that this wasn't always buggy... it only happened in . I cannot really say for sure whether there are undesired side effects... I mean bash-completion should anyway only be active in interactive sessions, right? So scripts shouldn't take any harm. And for interactive sessions (or such who kinda hack a script to behave like in an interactive one)... people must always expect that such changes occur in new versions. > I could definitely apply this to the Debian package, but I want to > take > this questioning upstream first. It's been a long time, and maybe > they > have a better understanding of the problem, now. Thanks a lot for taking the effort :-) What I personally would probably even like more was, if * is just not completed at all... but completing it only to one "random" match is just pointless. Thanks, Chris.
Bug#891667: bash-completion: file wildcard (*) completion picks up only first match
On 27 Feb 2018, Christoph Anton Mitterer wrote: >When completing e.g. >$ ls * > >then * doesn't become all the files (not starting with a .), but >instead only one of the files in the directory. > >This bug exists now since quite a while, and other bug reports, seem to >include the reason (missing quotes in one of the bash-completion >files): > >https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/1387057 While I understand that this patch in launchpad fixes the reported behaviour, I don't understand why upstream did not want to accept it. Could there be unintended/undesired side-effects? >https://superuser.com/questions/823257/unexpected-bash-glob-completion-uses-first-match-even-if-ambiguous > >Could this be fixed in the Debian package? :-) I could definitely apply this to the Debian package, but I want to take this questioning upstream first. It's been a long time, and maybe they have a better understanding of the problem, now. I don't have a good understanding of the problem, myself. :) Thanks for reporting.
Bug#892302: libpam-systemd: Does not recgonize serial consoles as part of a seat
On Wed, 07 Mar 2018 19:05:13 -0500 Matthew Gabeler-Leewrote: > Package: libpam-systemd > Version: 232-25+deb9u1 > Severity: normal > > Various policykit actions that flag as for "active" or even "inactive", but > not "any", do not work from serial console sessions. After much pain, I'm > fairly sure I've traced this down to libpam-systemd not marking serial > logins as part of a seat. This causes policykit to decide that the session > is not local, and thus its activity state is irrelevant for the > allow_inactive / allow_active policykit grants. Are you logging in via serial console as unprivileged user? > This seems to boil down, finally, to the get_seat_from_display function in > pam_systemd.c. > > Granted, serial console sessions are not _always_ local, given that I guess > modems still technically exist and you might have dialup sessions, but this > basically means that policykit is half-broken on headless systems, and that > breaks significant bits of systemd, such as systemd-inhibit, which is where > I began this adventure. > > For headless systems, being able to identify serial consoles that _are_ > local and thus should have a "seat" would be helpful. The contents of > /etc/securetty seem like they would be a useful starting place here. /etc/securetty (pam_securetty) is not really a good idea. That all said, you should really take this up with upstream at https://github.com/systemd/systemd/issues -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#892272: libopenmpt0: segfaults with memcopy if loaded from external application
The issue can be fixed using 2 upstream patches: https://github.com/OpenMPT/openmpt/commit/6f8f7be5848be8c4487b1779c332b802674f6747.patch https://github.com/OpenMPT/openmpt/commit/133007530cbe737f4b56db907aa6baee0ea5b17d.patch applied to sources in this order, after recompile no segmentation faults were encountered. those patches can be squashed for convenience to single patch.
Bug#884177: devscripts: debsnap --list should not complain about existing destdir
* Pierre-Elliott Bécue: > Thanks for the report, your patch has been merged in the repository > and will be part of the next release. :) Great, thank you! Cheers, -Hilko
Bug#892272:
confirmed steps to reproduce the issue in the simplest way: # ulimit -s 240 && openmpt123 Segmentation fault
Bug#892302: libpam-systemd: Does not recgonize serial consoles as part of a seat
Package: libpam-systemd Version: 232-25+deb9u1 Severity: normal Various policykit actions that flag as for "active" or even "inactive", but not "any", do not work from serial console sessions. After much pain, I'm fairly sure I've traced this down to libpam-systemd not marking serial logins as part of a seat. This causes policykit to decide that the session is not local, and thus its activity state is irrelevant for the allow_inactive / allow_active policykit grants. This seems to boil down, finally, to the get_seat_from_display function in pam_systemd.c. Granted, serial console sessions are not _always_ local, given that I guess modems still technically exist and you might have dialup sessions, but this basically means that policykit is half-broken on headless systems, and that breaks significant bits of systemd, such as systemd-inhibit, which is where I began this adventure. For headless systems, being able to identify serial consoles that _are_ local and thus should have a "seat" would be helpful. The contents of /etc/securetty seem like they would be a useful starting place here. -- System Information: Debian Release: 9.3 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'stable-debug'), (500, 'testing'), (490, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-6-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libpam-systemd depends on: ii dbus1.10.24-0+deb9u1 ii libc6 2.26-6 ii libpam-runtime 1.1.8-3.6 ii libpam0g1.1.8-3.6 ii libselinux1 2.6-3+b3 ii systemd 232-25+deb9u1 ii systemd-sysv232-25+deb9u1 libpam-systemd recommends no packages. libpam-systemd suggests no packages. -- no debconf information
Bug#892272:
The problem appears to be a large stack allocation in a static initializer when using constrained stack sizes. This issue appears to be fixed in upstream openmpt, we are testing a back port of this patch now to confirm. it appears the optimizer changes this from a stack allocation at -O3, but the explicit change is a better fix.
Bug#875591: Pending fixes for bugs in the jxplorer package
tag 875591 + pending thanks Some bugs in the jxplorer package are closed in revision 6f2039a7fe77f04ec60d78d58c9b8a8899778949 in branch 'master' by Emmanuel Bourg The full diff can be seen at https://anonscm.debian.org/cgit/pkg-java/jxplorer.git/commit/?id=6f2039a Commit message: Fixed the build failure with Java 9 (Closes: #875591)
Bug#883218: RFS: elpy/1.17.0-1 [ITP]
Updated. See below for changes. The most important changes: new upstream version, now supports dh-elpa self-tests and autotests, and installs manpage generated with sphinxdoc. On Thu, Nov 30, 2017 at 03:46:06PM -0500, Nicholas D Steeves wrote: > Package: sponsorship-requests > Severity: wishlist > > Dear mentors, > > I am looking for a sponsor for my package "elpy" > > Package name: elpy > Version : 1.17.0-1 > Upstream Author : Jorgen Schaefer> URL : https://github.com/jorgenschaefer/elpy > License : GPL-3+ > Section : lisp > > It builds this binary package: > > elpa-elpy - Emacs Python Development Environment > > To access further information about this package, please visit the following > URL: > > https://mentors.debian.net/package/elpy > > Alternatively, one can download the package with dget using this command: > > dget -x > https://mentors.debian.net/debian/pool/main/e/elpy/elpy_1.17.0-1.dsc > > Alternatively, one can clone the package repository with git: > > git clone ssh://git.debian.org/git/pkg-emacsen/pkg/elpy.git > > More information about elpy can be obtained from https://elpy.readthedocs.io/ > > > Regards, > Nicholas D Steeves Here are my commits (shortlog --pretty-short) since 1.17.0-1 Nicholas D Steeves (19): reenable dh-elpa-test Try enabling tests with ert_eval Load test/test-helper.el explicitly during tests Relax dh depend to 11~ to allow backporting. Add more deps needed for self-tests Merge upstream tag '1.18.0' Update changelog Add 0001-Disable-failing-tests.patch to disable 15 failing tests Re-enable autopkgtests Enable sphinxdoc-generated documentation Switch Vcs from alioth to salsa. Patch sphinx-generated docs for python3 support Add basic upstream documentation Do not install html docs that duplicate manpage Install manpage Add patch to fix spelling errors in documentation Add forwarded header to 0002-Use-py3-s-dict.items-instead... Release 1.18.0-1 to unstable Git remote is the same, mentors page is the same, to download the dsc use: dget -x https://mentors.debian.net/debian/pool/main/e/elpy/elpy_1.18.0-1.dsc Cheers, Nicholas signature.asc Description: PGP signature
Bug#892259: lpc21isp: Request to patch in order to add support for LPC40XX devices
Hi Agustin, Here it is the patch (4th time I'm trying to send it) I sent a message to "capiman" today, but it seems that there is no activity from him for about 4 years. Since we have lpctools, I don't know if to maintain lpc21isp is the best solution (unless the the author wants to bring it to life again, of course) I'm not using lpctools because it does not have the ability to enable the ISP mode using the control lines (Reset = DTR, EnableBootLoader = RTS) If the lpctools maintainer could implement some of the basic functionality that are implemented in lpc21isp, I think it would be a better option. Cristiano On Wed, 7 Mar 2018 11:04:10 -0300 Agustin Henzewrote: > Hi Cristiano, > > On Wed, 07 Mar 2018 09:28:58 + Cristiano Rodrigues > wrote: > > Dear Maintainer, > > > > This is not a bug. I created a patch where it add support for LPC40xx > > devices. It was published in the software autor site but it seems no one is > > looking for it. > > If possible, please apply the patch. I'm using it for more than a year and > > it's working without problems. > > I guess that you forgot attach the patch. However I think you are talking > about > this thread[0] where I could find the source attached. As far I can see the > project seems to be dead :'(. Have you tried contacting directly to the > author[1]? > Ok, I have took a look at it and the attachment seems to be all the source. > Could please send me a patch instead? Anyway I still thinking that would be > awesome if you contact to upstream and see if he still interested on > maintaining the project maybe you can turn into upstream :). > > Cheers, > > [0] > https://sourceforge.net/p/lpc21isp/discussion/889930/thread/6438fdc1/?limit=25 diff -Naur ./lpc21isp_197/lpc21isp.c ./lpc21isp_198/lpc21isp.c --- ./lpc21isp_197/lpc21isp.c 2014-01-09 07:25:51.0 + +++ ./lpc21isp_198/lpc21isp.c 2017-01-20 18:22:06.0 + @@ -410,12 +410,15 @@ Updated .gitignore file (Now with ignored *.layout) Removed *.layout from lpc21isp project Removed *.depend from lpc21isp project + 1.97 2014-01-09 Martin Maurer +1.98 2016-01-17 Cristiano Rodrigues + Add some new chip ids for LPC40xx */ // Please don't use TABs in the source code !!! // Don't forget to update the version string that is on the next line -#define VERSION_STR "1.97" +#define VERSION_STR "1.98" #if defined COMPILE_FOR_WINDOWS || defined COMPILE_FOR_CYGWIN static char RxTmpBuf[256];// save received data to this buffer for half-duplex diff -Naur ./lpc21isp_197/lpcprog.c ./lpc21isp_198/lpcprog.c --- ./lpc21isp_197/lpcprog.c 2014-01-08 19:38:26.0 + +++ ./lpc21isp_198/lpcprog.c 2017-01-20 15:03:58.0 + @@ -106,6 +106,15 @@ 65536, 65536, 65536, 65536, 65536, 65536, 65536 }; +// Used for LPC40xx devices +static const unsigned int SectorTable_40xx[] = +{ + 4096, 4096, 4096, 4096, 4096, 4096, 4096, 4096, + 4096, 4096, 4096, 4096, 4096, 4096, 4096, 4096, +32768, 32768, 32768, 32768, 32768, 32768, 32768, 32768, +32768, 32768, 32768, 32768, 32768, 32768 +}; + // Used for LPC43xx devices static const unsigned int SectorTable_43xx[] = { @@ -126,7 +135,7 @@ { { 0, 0, 0, 0, 0, 0, 0, 0, 0, CHIP_VARIANT_NONE }, /* unknown */ - // id,id2, use id2, name of product, flash size, ram size, total number of sector, max copy size, sector table, chip variant + // id,id2, use id2, name of product, flash size, ram size, total number of sector, max copy size, sector table, chip variant { 0x8100, 0x, 0, "810M021FN8", 4, 1, 4, 256, SectorTable_8xx, CHIP_VARIANT_LPC8XX }, { 0x8110, 0x, 0, "811M001FDH16",8, 2, 8, 1024, SectorTable_8xx, CHIP_VARIANT_LPC8XX }, @@ -230,6 +239,7 @@ { 0x25011722, 0x, 0, "1754", 128, 32, 18, 4096, SectorTable_17xx, CHIP_VARIANT_LPC17XX }, { 0x25011723, 0x, 0, "1756", 256, 32, 22, 4096, SectorTable_17xx, CHIP_VARIANT_LPC17XX }, { 0x25013F37, 0x, 0, "1758", 512, 64, 30, 4096, SectorTable_17xx, CHIP_VARIANT_LPC17XX }, + // id,id2, use id2, name of product, flash size, ram size, total number of sector, max copy size, sector table, chip variant { 0x25113737, 0x, 0, "1759", 512, 64, 30, 4096, SectorTable_17xx, CHIP_VARIANT_LPC17XX }, { 0x26012033, 0x, 0, "1763", 256, 64, 22, 4096, SectorTable_17xx, CHIP_VARIANT_LPC17XX }, { 0x26011922, 0x, 0, "1764", 128, 32, 18, 4096, SectorTable_17xx, CHIP_VARIANT_LPC17XX }, @@ -314,6 +324,11 @@ { 0x1600FF35, 0x, 0, "2468", 512, 98, 28,
Bug#884177: devscripts: debsnap --list should not complain about existing destdir
Hi, Thanks for the report, your patch has been merged in the repository and will be part of the next release. :) -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#806256: libpam-systemd: log out from a TTY and your X input devices get lost!
Am 25.11.2015 um 22:20 schrieb Francesco Poli (wintermute): > Package: libpam-systemd > Version: 228-2 > Severity: normal > > Hello, > I noticed a weird bug that is possibly caused by libpam-systemd. > > Steps to reproduce (on a box with systemd as PID 1 process): > > 0) login on TTY1 (virtual terminal 1) as a regular user > > 1) start an X session with > > $ startx > > 2) press [Ctrl+Alt+F2], in order to switch to TTY2 > > 3) login on TTY2 as the same user > > 4) logout by pressing [Ctrl+D] on the empty command prompt > > 5) awkwardly the screen goes automatically back to the X session > (rather than showing a fresh new TTY2 login prompt) > > 6) even more awkwardly, any keyboard and mouse input is ignored > except for [Ctrl+Alt+F1], which however causes the screen to > go blank and immediately enter sleep mode > > 7) the only way out seems to be a poweroff command, issued by > pressing the power button (which is handled by acpid) > > I didn't try to SSH into the box and take a look at the system... > > > I suspect that this bug is caused by libpam-systemd, since starting > an X session on a box with systemd as PID 1 process, but without > libpam-systemd installed, causes the same inability to use X input > devices. > > I noticed this bug some days ago with libpam-systemd/227-2: I waited > for version 228-2 to migrate to testing, before reporting the bug. > After reproducing the same exact misbehavior with libpam-systemd/228-2, > I decided that it is time to report it. > > Could you please investigate this bug and fix it and/or forward it > upstream, as appropriate? As the original bug reporter, can you still reproduce the issue, and if so, could you share your ~/.bash_logout file. Thanks, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#662794: nmudiff: Please, add a non-dd template for those who can not upload NMUs
Dear Mònica, Six years. That's really a long time span. I answer to your email address (I'll see if a bounce comes back) because you submitted this bug, and I'm currently giving a try at reviewing & including the patches submitted by the users. Maybe you do not really care anymore about this feature, but it's worth a try. Thanks for your patch. For now, I think it lacks a little specification. The nmudiff does not upload anything in a practical point of view. The only upload reference in the text in in the case you provide the delay argument, which would be nonsense if you are no DD. In the other cases, it only adds a tag pending, which is not in contradiction with not being a DD, as a pending tag only means that the changes are included in the package's vcs and will be included in the next release. But, indeed, in some cases, you might not want to add this pending tag. I think the appropriate answer to your remarks is to include your template feature, and add a --no-pending-tag argument to prevent the pending tag from being added to the mail. Apart from that, I don't see how it would make a real difference between being DD/DM or just a contributor. I'll give it a week to see if you are still around and willing to discuss it, and otherwise mix your patch with the changes I suggested. Cheers, and, sorry that you got no answer for so long. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#892272:
Confirmed its the same linking to JUST libopenmpt, without libavformat
Bug#887873: linux-image-4.9.0-5-marvell: frequent "usercopy: kernel memory overwrite attempt detected" on QNAP NAS (ARM)
On Thu, Mar 08, 2018 at 09:49:29AM +1300, Menno Finlay-Smits wrote: > On Thu, 8 Mar 2018, at 02:36, Andrew Lunn wrote: > > > What else can I try? > > > > Do you have transparent huge pages enabled? > > > > ~$ cat /sys/kernel/mm/transparent_hugepage/enabled > > [always] madvise never > > > > If so, could you disable it with: > > > > echo never > /sys/kernel/mm/transparent_hugepage/enabled > > > > and run your rsync command. Hi Menno Could you also try linux-image-4.14.0-3-marvell from sid? There does not appear to be a 4.15 yet for marvell. Andrew
Bug#892301: ucf with -n as first argument results in error
Package: ucf Version: 3.0038 repro steps: run with valid file arguments: # /usr/bin/ucf -n --debconf-ok /file1 /file2 *** ERROR: Need exactly two arguments, got 3 Debian GNU/Linux ucf Revision: 3.00 . Copyright (C) 2002-2005 Manoj Srivastava. This is free software; see the GNU General Public Licence for copying conditions. There is NO warranty. Usage: ucf [options] new_file destination Options: -h, --help print this message -s foo, --src-dir foo Set the src dir (historical md5sums live here) --sum-file bar Force the historical md5sums to be read from this file. Overrides any setting of --src-dir. -d[n], --debug=[n] Set the Debug level to N. Please note there must be no spaces before the debug level -n, --no-action Dry run. No action is actually taken. -v, --verbose Make the script verbose --three-way Register this file in the cache, and turn on the diff3 option allowing the merging of maintainer changes into a (potentially modified) local configuration file. ) --state-dir bar Set the state directory to bar instead of the default '/var/lib/ucf'. Used mostly for testing. --debconf-okIndicate that it is ok for ucf to use an already running debconf instance for prompting. --debconf-template bar Specify an alternate, caller-provided debconf template to use for prompting. Usage: ucf -p destination -p, --purge Remove any reference to destination from records By default, the directory the new_file lives in is assumed to be the src-dir, which is where we look for any historical md5sums. expected: does dry run as it should without error. This is because it tries to save the -n argument then use it to call itself again. But when saving the argument, it runs echo -n, expecting the output to be -n, but it's actually an empty string, so it saves that emptry string and passes that instead of -n. Patch is attached. --- ucf-3.0038/ucf 2018-02-25 19:58:23.0 -0500 +++ new/ucf 2018-03-07 16:42:55.727057127 -0500 @@ -308,7 +308,7 @@ # Escape single quotes in the arguments passed in quote_single() { -echo "$1" | sed -e "s,',''',g" +printf "%s\n" "$1" | sed -e "s,',''',g" } -- Ian Kelling | Senior Systems Administrator, Free Software Foundation GPG Key: B125 F60B 7B28 7FF6 A2B7 DF8F 170A F0E2 9542 95DF https://fsf.org | https://gnu.org
Bug#892272: libavformat/libopenmpt failure on dlopen
I’m still working on a complete stand alone example but the way to reproduce this is to dlopen a module that is linked to libavformat. It does not require any code at all related to libavformat to be executed at all, or any includes to libavformat, or anything at all related to apt, just the linking, then dlopen of that so #0 0x7fd8315fdca2 in ?? () from /usr/lib/x86_64-linux-gnu/libopenmpt.so.0 #1 0x7fd87d8b08aa in call_init (l=, argc=argc@entry=2, argv=argv@entry=0x7ffc0cfd1b58, env=env@entry=0x7ffc0cfd1b70) at dl-init.c:72 #2 0x7fd87d8b09bb in call_init (env=0x7ffc0cfd1b70, argv=0x7ffc0cfd1b58, argc=2, l=) at dl-init.c:30 #3 _dl_init (main_map=main_map@entry=0x561842c5b320, argc=2, argv=0x7ffc0cfd1b58, env=0x7ffc0cfd1b70) at dl-init.c:120 #4 0x7fd87d8b4f38 in dl_open_worker (a=a@entry=0x7ffc0cfcc990) at dl-open.c:575 #5 0x7fd87d8b0754 in _dl_catch_error (objname=objname@entry=0x7ffc0cfcc980, errstring=errstring@entry=0x7ffc0cfcc988, mallocedp=mallocedp@entry=0x7ffc0cfcc97f, operate=operate@entry=0x7fd87d8b4b50 , args=args@entry=0x7ffc0cfcc990) at dl-error.c:187 #6 0x7fd87d8b46e9 in _dl_open (file=0x561842bac540 "/usr/local/freeswitch/mod/mod_commands.so", mode=-2147483646, caller_dlopen=0x7fd87cd637da, nsid=-2, argc=, argv=, env=0x7ffc0cfd1b70) at dl-open.c:660 #7 0x7fd87c67cee9 in dlopen_doit (a=a@entry=0x7ffc0cfccbc0) at dlopen.c:66 #8 0x7fd87d8b0754 in _dl_catch_error (objname=0x561842b78930, errstring=0x561842b78938, mallocedp=0x561842b78928, operate=0x7fd87c67ce90 , args=0x7ffc0cfccbc0) at dl-error.c:187 #9 0x7fd87c67d531 in _dlerror_run (operate=operate@entry=0x7fd87c67ce90 , args=args@entry=0x7ffc0cfccbc0) at dlerror.c:163 #10 0x7fd87c67cf82 in __dlopen (file=, mode=mode@entry=2) at dlopen.c:87
Bug#892300: RFP: libjs-strophe.rsm -- Plugin for strophe.js providing Result Set Management (RSM) XEP-0059
Package: wnpp Severity: wishlist * Package name: libjs-strophe.rsm Version : 0.0.2 Upstream Author : "The strophe plugin developers" * URL : https://github.com/strophe/strophejs-plugin-rsm * License : MIT Programming Lang: JavaScript Description : Plugin for strophe.js providing Result Set Management (RSM) XEP-0059 New dependency for libjs-jsxc
Bug#892299: RFP: libjs-strophejs.mam -- Plugin for strophe.js to provide Message Archiving Management (XEP-0313)
Package: wnpp Severity: wishlist * Package name: libjs-strophejs.mam Version : 0.0.3 Upstream Author : "The strophe plugin developers" * URL : https://github.com/strophe/strophejs-plugin-mam * License : MIT Programming Lang: JavaScript Description : Plugin for strophe.js to provide Message Archiving Management (XEP-0313) New dependency for libjs-jsxc.
Bug#892298: RFP: libjs-strophe.chatstates -- Strophe.js plugin for chat state notifications (XEP-0085)
Package: wnpp Severity: wishlist * Package name: libjs-strophe.chatstates Version : v0.0.1 Upstream Author : Klaus Herberth? * URL : https://github.com/strophe/strophejs-plugin-chatstates * License : MIT Programming Lang: JavaScript Description : Strophe.js plugin for chat state notifications (XEP-0085) New dependency for libjs-jsxc.
Bug#891915: Patch for Debian 10 (buster), it fixes the problem
Tags: patch I attached patch from ArchLinux AUR ( https://aur.archlinux.org/packages/xorg-server-bug865/, https://aur.archlinux.org/cgit/aur.git/tree/freedesktop-bug-865.patch?h=xorg-server-bug865 ). This patch is stable and reliable. ArchLinux users are happy with it. It fixes current bug on Debian 10 (buster). I have tested it withon MATE desktop. Please kindly review it and consider applying it before official final release of Debian 10. As the result Debian and Ubuntu users will be as happy as ArchLinux's users. --- xorg-server-1.19.1/xkb/xkbActions.c.orig 2017-01-12 18:34:23.435568903 +0300 +++ xorg-server-1.19.1/xkb/xkbActions.c 2017-02-23 12:58:00.719948700 +0300 @@ -351,26 +351,83 @@ return 1; } +static int xkbSwitchGroupOnRelease(void) +{ +/* TODO: user configuring */ +return TRUE; +} + +static void xkbUpdateLockedGroup(XkbSrvInfoPtr xkbi, XkbAction* pAction) +{ +XkbGroupAction ga = pAction->group; +if (ga.flags_GroupAbsolute) + xkbi->state.locked_group= XkbSAGroup(); +else + xkbi->state.locked_group+= XkbSAGroup(); +} + +static XkbFilterPtr _XkbNextFreeFilter(XkbSrvInfoPtr xkbi); + static int -_XkbFilterLockState(XkbSrvInfoPtr xkbi, +_XkbFilterLockGroup(XkbSrvInfoPtr xkbi, XkbFilterPtr filter, unsigned keycode, XkbAction *pAction) { +int sendEvent = 1; + if (filter->keycode == 0) /* initial press */ AccessXCancelRepeatKey(xkbi, keycode); - -if (pAction && (pAction->type == XkbSA_LockGroup)) { -if (pAction->group.flags & XkbSA_GroupAbsolute) -xkbi->state.locked_group = XkbSAGroup(>group); -else -xkbi->state.locked_group += XkbSAGroup(>group); -return 1; +if (!xkbSwitchGroupOnRelease()) { + xkbUpdateLockedGroup(xkbi, pAction); + return sendEvent; +} + +/* Delay switch till button release */ +if (filter->keycode==0) { /* initial press */ + filter->keycode = keycode; + filter->active = 1; + filter->filterOthers = 0; /* for what? */ + filter->filter = _XkbFilterLockGroup; + + /* filter->priv = 0; */ + filter->upAction = *pAction; + + /* Ok, now we need to simulate the action which would go if this action didn't block it. + XkbSA_SetMods is the one: it is to set modifier' flag up. */ + { + XkbStateRec fake_state = xkbi->state; + XkbAction act; + + fake_state.mods = 0; + act = XkbGetKeyAction(xkbi, _state, keycode); + + /* KLUDGE: XkbSA_SetMods only? */ + if (act.type == XkbSA_SetMods) { + XkbFilterPtr filter = _XkbNextFreeFilter(xkbi); + sendEvent = _XkbFilterSetState(xkbi,filter,keycode,); + } + } +} +else { + /* do nothing if some button else is pressed */ + if (!pAction) + xkbUpdateLockedGroup(xkbi, >upAction); + filter->active = 0; } +return sendEvent; +} + +static int +_XkbFilterLockMods(XkbSrvInfoPtr xkbi, + XkbFilterPtrfilter, + unsignedkeycode, + XkbAction * pAction) +{ if (filter->keycode == 0) { /* initial press */ filter->keycode = keycode; filter->active = 1; filter->filterOthers = 0; filter->priv = xkbi->state.locked_mods & pAction->mods.mask; -filter->filter = _XkbFilterLockState; +filter->filter = _XkbFilterLockMods; filter->upAction = *pAction; if (!(filter->upAction.mods.flags & XkbSA_LockNoLock)) xkbi->state.locked_mods |= pAction->mods.mask; @@ -1244,9 +1301,12 @@ *sendEvent = _XkbFilterLatchState(xkbi, filter, key, act); break; case XkbSA_LockMods: +filter = _XkbNextFreeFilter(xkbi); +*sendEvent = _XkbFilterLockMods(xkbi, filter, key, act); +break; case XkbSA_LockGroup: filter = _XkbNextFreeFilter(xkbi); -*sendEvent = _XkbFilterLockState(xkbi, filter, key, act); +*sendEvent = _XkbFilterLockGroup(xkbi, filter, key, act); break; case XkbSA_ISOLock: filter = _XkbNextFreeFilter(xkbi);
Bug#892285: [Pkg-pascal-devel] Bug#892285: /usr/bin/fpcmake: fpcmake should find units in Debian without fiddling with FPCDIR
Hi, On Wed, 2018-03-07 at 21:29 +0100, Paul Gevers wrote: > Lazarus is defining FPCDIR in its d/rules file to prevent this > like:FPCDIR=/usr/share/fpcsrc/${FPCVER} > > Transgui is/was doing it like: > FPCDIR=/usr/lib/fpc/${FPCDIR} > > I believe neither should be needed. Also, which one of the two is correct (or > better, if neither is really correct)? Probably none of them need to define FPCDIR. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#887967: closed by Abou Al Montacir <abou.almonta...@sfr.fr> (Bug#887967: fixed in fpc 3.0.4+dfsg-14)
On Wed, 2018-03-07 at 18:28 +0100, Paul Gevers wrote: > Hi Graham, > > On 07-03-18 16:46, Graham Inggs wrote: > > On Tue, 23 Jan 2018 08:46:09 +0200 Adrian Bunkwrote: > > > This problem is unfortunately still present with fpc 3.0.4+dfsg-14: > > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/transgu > > > i.html > > > > > > > This can be worked around by the following change in debian/rules: > > > > -export FPCDIR=/usr/lib/fpc/${FPCDIR} > > +export FPCDIR=/usr/lib/$(DEB_HOST_MULTIARCH)/fpc/default > > > > However, it was my understanding that this was supposed to be fixed in > > FPC, so forwarding to the Pascal list for comment. > > No, FPC would fix the default behavior. When FPCDIR is defined in > debian/rules, it must match. I wonder, does building work without > defining FPCDIR at all? I would recommend not defining FPC dir in debian/rules except for the fpc package itself. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#892297: evince-common: Please add Multi-Arch: foreign
Package: evince-common Version: 3.26.0-3 Severity: wishlist Hi, It looks like evince-common offers an architecture independent (data/translations level) interface to its users. Would you mind setting it to Multi-Arch: foreign? It's usually a matter of adding one line to debian/control. This would hopefully improve install options for different architectures. Like running the x32 variant on an amd64 system. Note: Architecture=all packages are not Multi-Arch=foreign automatically for various reasons, so they need to be set manually. Cheers Elrond
Bug#875576: Pending fixes for bugs in the java-gnome package
tag 875576 + pending thanks Some bugs in the java-gnome package are closed in revision 638eaf7440cafd74425bc6eedf94d95ebe6da425 in branch 'master' by Emmanuel Bourg The full diff can be seen at https://anonscm.debian.org/cgit/pkg-java/java-gnome.git/commit/?id=638eaf7 Commit message: No longer generate the -java-doc package (Closes: #875576)
Bug#819589: RFP: python3-aioxmpp -- pure-python XMPP library using the asyncio standard library module
slixmpp is similar to aioxmpp, but the API seems to be different. A program written for one library will not work with the other. I.e. poezio needs slixmpp, but jabbercat needs aioxmpp.
Bug#891360: closed by Thomas Goirand <z...@debian.org> (Fixed in 2.8.0-1)
Control: reopen -1 On Wed, Mar 07, 2018 at 08:33:04PM +, Debian Bug Tracking System wrote: >... > Date: Wed, 7 Mar 2018 21:30:38 +0100 > From: Thomas Goirand> To: 891360-d...@bugs.debian.org > Subject: Fixed in 2.8.0-1 > > Hi, > > Likely, you've built this when I was in the middle of uploading the last > version of OpenStack or something. Still FTBFS as of right now: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/python-magnumclient.html > Because version 2.8.0-1 builds just > fine now in Sid. 2.8.0-1 is not in sid: https://tracker.debian.org/pkg/python-magnumclient > Therefore closing this bug. > > Cheers, > > Thomas Goirand (zigo) cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#269990: fixed upstream
This is fixed upstream, will be fixed in the next release. -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io/ltworf/
Bug#892296: gridengine-qmon: qmon fails to start, as it cannot load pixmaps
Package: gridengine-qmon Version: 8.1.9+dfsg-4 Severity: important Dear Debian HPC Team, I think I found a bug in the gridengine-qmon Debian package. The qmon program fails to start: $ qmon Warning: Cannot convert string "intro" to type Pixmap Can't load icon 21cal. Pixmaps should reside in $SGE_ROOT/qmon/PIXMAPS. Apparently, the Debian package installs the pixmaps in /usr/share/gridengine/pixmaps but the qmon Debian-packaged program incorrectly looks for them in /var/lib/gridengine/qmon/PIXMAPS The (root) user can work around the bug with the following commands: # mkdir /var/lib/gridengine/qmon # ln -s /usr/share/gridengine/pixmaps /var/lib/gridengine/qmon/PIXMAPS However, I believe that the Debian package should patch the qmon program so that it looks for the resources in the directory where the Debian package itself installs them. Please fix this packaging bug. Thanks for your time! Bye. -- System Information: Debian Release: 9.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-6-amd64 (SMP w/20 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages gridengine-qmon depends on: ii debconf [debconf-2.0] 1.5.61 ii gridengine-common 8.1.9+dfsg-4 ii libc6 2.24-11+deb9u1 ii libice62:1.0.9-2 ii libjemalloc1 3.6.0-9.1 ii libmunge2 0.5.12-1+b1 ii libsm6 2:1.2.2-1+b3 ii libssl1.0.21.0.2l-2+deb9u2 ii libx11-6 2:1.6.4-3 ii libxext6 2:1.3.3-1+b2 ii libxm4 2.3.4-13 ii libxt6 1:1.1.5-1 Versions of packages gridengine-qmon recommends: ii xfonts-75dpi 1:1.0.4+nmu1 gridengine-qmon suggests no packages. -- debconf information excluded
Bug#861616: closed by Nicolas Boulenguez <nico...@debian.org> (Bug#861616: fixed in gnat-gps 17.0.2017-1~exp1)
Hi, Thank you for applying the gnatdoc.diff patch to gnat-gps-17.0.2017-1~exp1. Unfortunately, one of the changes was applied to the wrong line. I guess code duplication in gnatdoc-frontend.adb confused the patching tool. Please find attached a fixed gnatdoc.diff. (Note : I haven't been able yet to rebuild and test the package with this new patch due to #892148.) Thanks. On Sun, 04 Mar 2018 15:06:14 + "Debian Bug Tracking System"wrote: > This is an automatic notification regarding your Bug report > which was filed against the gnat-gps package: > > #861616: gnat-gps: Inaccuracies in documentation generated by GNATdoc > > It has been closed by Nicolas Boulenguez . > > 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 Nicolas > Boulenguez by replying to this email. > > Description: gnat-gps: Inaccuracies in documentation generated by GNATdoc The "not overriding" indicators appear as "overriding" indicators. . The line numbers shown for the subprogram declarations are wrong (one unit too high) if there is an "overriding" or a "not overriding" indicator on the previous line. NOT FIXED with gnat-gps 6.1.2016-1. . When there is a quantified expression in the precondition or postcondition of a subprogram, then the documentation for the subprogram is not rendered. I guess it's not a new issue but I discovered it recently with 6.1.2016-1. I managed to patch the frontend. . The sample code at https://github.com/thierr26/gnatdoc_test reproduces the issue. Bug-Debian: https://bugs.debian.org/861616 Author: Thierry Rascle --- a/gnatdoc/src/gnatdoc-backend-html.adb +++ b/gnatdoc/src/gnatdoc-backend-html.adb @@ -1059,12 +1059,45 @@ declare Buffer : aliased String := To_String (Get_Src (E)); Code : JSON_Value; + Line : Positive := LL.Get_Location (E).Line; + Start_Col : Positive; begin + if Buffer'Length > 0 +and then (Get_Kind (E) = E_Procedure +or else Get_Kind (E) = E_Function +or else Get_Kind (E) = E_Entry) then + Start_Col := Buffer'First; + while (Buffer (Start_Col) = ' ' + or else Buffer (Start_Col) = ASCII.HT) + and then Start_Col < Buffer'Last loop +Start_Col := Start_Col + 1; + end loop; + if Buffer (Start_Col) /= ' ' + and then Buffer (Start_Col) /= ASCII.HT + and then Buffer'Last >= Start_Col + 11 + and then (Buffer (Start_Col + 10) = ASCII.LF + or else Buffer (Start_Col + 11) = ASCII.LF) then +if Buffer (Start_Col .. Start_Col + 9) + = "overriding" then + Line := Line - 1; +end if; + end if; + if Buffer (Start_Col) /= ' ' + and then Buffer (Start_Col) /= ASCII.HT + and then Buffer'Last >= Start_Col + 15 + and then (Buffer (Start_Col + 14) = ASCII.LF + or else Buffer (Start_Col + 15) = ASCII.LF) then +if Buffer (Start_Col .. Start_Col + 13) + = "not overriding" then + Line := Line - 1; +end if; + end if; + end if; Self.Print_Source_Code (Tree.File, Buffer'Unchecked_Access, - LL.Get_Location (E).Line, + Line, Printer, Code); Prepend (Description, Code); --- a/gnatdoc/src/gnatdoc-frontend.adb +++ b/gnatdoc/src/gnatdoc-frontend.adb @@ -63,6 +63,7 @@ Tok_Is, Tok_Limited, Tok_New, + Tok_Not, Tok_Null, Tok_Others, Tok_Package, @@ -1636,6 +1637,8 @@ Cursor : Extended_Cursor.Extended_Cursor; Last_Idx : Natural := 0; Par_Count : Natural := 0; + Prev_Prev_Token: Tokens := Tok_Unknown; + Prev_Prev_Token_Loc: Source_Location; Prev_Token : Tokens := Tok_Unknown; Prev_Token_Loc : Source_Location; Token : Tokens := Tok_Unknown; @@ -1698,12 +1701,14 @@ procedure Clear_Parser_State is No_Source_Location : constant Source_Location := (0, 0, 0); begin -Last_Idx := 0; -
Bug#892295: jemalloc: Please add support for new architecture "riscv64" (RISC-V 64 bits little-endian)
Source: jemalloc Version: 3.6.0-11 Severity: normal Tags: patch upstream fixed-upstream User: debian-ri...@lists.debian.org Usertags: riscv64 Forwarded: https://github.com/jemalloc/jemalloc/pull/1081 Hello, We need support in this package for RISC-V, to bootstrap the riscv64 architecture. Patches have been submitted upstream months ago, targetting development versions: https://github.com/jemalloc/jemalloc/commit/749caf14ae73a9ab1c48e538a8af09addbb35ee7 (the file was named differently before, I didn't bother to get the VCS history to chase all commits, but it's clear enough). Since we're still including older versions in unstable (and even experimental), and in Debian we can get by by defining LG_QUANTUM in d/rules, instead of patching the upstream source code I propose a patch for debian/rules instead, attached. It would be great if you could include it as a patch and release a new version for unstable. If we can help by NMUing the package or anything else, please let me/us know. Thanks and cheers. -- Manuel A. Fernandez Montecelo--- a/debian/rules 2017-08-25 17:51:57.0 +0200 +++ b/debian/rules 2018-03-07 22:41:08.615157261 +0100 @@ -6,7 +6,7 @@ include /usr/share/dpkg/architecture.mk include /usr/share/dpkg/pkg-info.mk -ifneq (,$(findstring $(DEB_HOST_ARCH),sh3 sparc sparc64)) +ifneq (,$(findstring $(DEB_HOST_ARCH),riscv64 sh3 sparc sparc64)) DEB_CPPFLAGS_MAINT_APPEND += -DLG_QUANTUM=4 endif
Bug#892294: contains browserified library strophe.jinglejs-bundle.js
Package: libjs-jsxc Version: 3.0.0+dfsg3-2 The file /usr/share/javascript/jsxc/lib/strophe.jinglejs/strophe.jinglejs-bundle.js should be packaged separately (#892291).
Bug#892293: paraview: errors when saving animations as AVI files [regression]
Package: paraview Version: 5.4.1+dfsg3-1+b2 Severity: important Dear paraview Debian package maintainers, I've just found a regression. In a nutshell, version 5.4.1 fails to save animations as AVI files (while version 5.1.2 was perfectly capable of doing so). Other animation formats (OGV, PNG images, ...) seem to work as expected. In order to reproduce the bug, you may use the attached test case (but please note that any other temporal data set will do...). The compressed tar archive includes a small Fortran program that generates the sample data and a ParaView state file. Steps to reproduce the bug: 0) compile gen_waveplot3d.f (with gfortran or another Fortran compiler) 1) run the executable 2) start ParaView $ paraview --state=wave_anim.pvsm 3) select Save Animation ... from the File menu 4) set the parameters (the values seem to make no difference) 5) save to file "wave_anim_test.avi" (or any other file name with .avi extension) 6) the animation is not correctly saved as the requested AVI file and Paraview prints the following error messages (on the terminal): [avi @ 0x55fa91dfe560] Using AVStream.codec.time_base as a timebase hint to the muxer is deprecated. Set AVStream.time_base instead. [avi @ 0x55fa91dfe560] Using AVStream.codec to pass codec parameters to muxers is deprecated, use AVStream.codecpar instead. [rawvideo @ 0x55fa91feffe0] AVFrame.format is not set [rawvideo @ 0x55fa91feffe0] AVFrame.width or height is not set Generic Warning: In /build/paraview-8H5PCo/paraview-5.4.1+dfsg3/VTK/IO/FFMPEG/vtkFFMPEGWriter.cxx, line 449 Problem encoding frame. ERROR: In /build/paraview-8H5PCo/paraview-5.4.1+dfsg3/VTK/IO/FFMPEG/vtkFFMPEGWriter.cxx, line 620 vtkFFMPEGWriter (0x55fa93f5c9c0): Error storing image. I hope you can investigate and fix this bug soon, as losing this functionality is a very annoying limitation... Thanks for your time! Bye. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (800, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages paraview depends on: ii libavcodec57 7:3.4.2-1+b1 ii libavformat57 7:3.4.2-1+b1 ii libavutil557:3.4.2-1+b1 ii libc6 2.26-6 ii libcgns3.3 3.3.0-5 ii libexpat1 2.2.5-3 ii libfreetype6 2.8.1-2 ii libgcc11:8-20180218-1 ii libgl1 1.0.0-2 ii libgl2ps1.41.4.0+dfsg1-1 ii libhdf5-1001.10.0-patch1+docs-4 ii libjpeg62-turbo1:1.5.2-2+b1 ii libjsoncpp11.7.4-3 ii libnetcdf131:4.6.0-2 ii libogg01.3.2-1+b1 ii libopenmpi22.1.1-8 ii libpng16-161.6.34-1 ii libprotobuf10 3.0.0-9.1 ii libpython2.7 2.7.14-6 ii libqt4-help4:4.8.7+dfsg-11 ii libqt4-network 4:4.8.7+dfsg-11 ii libqtcore4 4:4.8.7+dfsg-11 ii libqtgui4 4:4.8.7+dfsg-11 ii libstdc++6 8-20180218-1 ii libswscale47:3.4.2-1+b1 ii libtheora0 1.1.1+dfsg.1-14+b1 ii libtiff5 4.0.9-4 ii libx11-6 2:1.6.4-3 ii libxml22.9.4+dfsg1-6.1 ii libxt6 1:1.1.5-1 ii python-autobahn17.10.1+dfsg1-2 ii python-matplotlib 2.1.1-2 ii python-mpi4py 2.0.0-3 ii python-six 1.11.0-2 ii python-twisted 17.9.0-1 ii tcl [tclsh]8.6.0+9 ii zlib1g 1:1.2.8.dfsg-5 Versions of packages paraview recommends: ii mpi-default-bin 1.10 ii paraview-doc 5.4.1+dfsg3-1 ii paraview-python 5.4.1+dfsg3-1+b2 Versions of packages paraview suggests: pn h5utils pn hdf5-tools -- no debconf information waveplot3d.tar.xz Description: application/xz
Bug#892228: libsphinxbase3: Causes pocketsphinx to FTBFS on 64-bit big-endian architectures (fills testsuite logs on disk with errors)
Hello, James Clarke, on mer. 07 mars 2018 00:33:05 +, wrote: > The build for pocketsphinx fails on 64-bit big-endian architectures, I know, I had already reported the issue a long time ago, without feedback. > failing with "No space left on device", as the testsuite log files > fill up with hundreds of gigabytes of warnings. Ouch! Perhaps we should just abort the build before that happens for now. Samuel
Bug#890449: RFS: engauge-digitizer/10.4+ds.1-2
Hi, On Saturday 3 March 2018 22:24:22 CET Adam Borowski wrote: > I'm afraid that you've forgotten to bump the dependency on debhelper to >= > 10~. While only oldstable has an older version, there's no point in making > it harder to users when it's so trivial to fix. Having the dependency > correct means that using your package on jessie requires just a simple > rebuild (assuming backports are available). > Thanks for the info, I updated the package on mentors. Bests, Tobi signature.asc Description: This is a digitally signed message part.
Bug#892292: xpyb FTBFS with xcb-proto 1.13-1
Source: xpyb Version: 1.3.1-1.1 Severity: serious Tags: buster sid https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/xpyb.html ... Making all in src make[3]: Entering directory '/build/1st/xpyb-1.3.1/build-python2.7/src' ln -s -f /usr/share/xcb/xproto.xml xproto.xml python2.7 ../../src/py_client.py -p /usr/lib/python2.7/dist-packages /usr/share/xcb/xproto.xml Traceback (most recent call last): File "../../src/py_client.py", line 607, in from xcbgen.state import Module File "/usr/lib/python2.7/dist-packages/xcbgen/state.py", line 7, in from xcbgen import matcher File "/usr/lib/python2.7/dist-packages/xcbgen/matcher.py", line 12, in from xcbgen.xtypes import * File "/usr/lib/python2.7/dist-packages/xcbgen/xtypes.py", line 1221, in class EventStruct(Union): File "/usr/lib/python2.7/dist-packages/xcbgen/xtypes.py", line 1239, in EventStruct out = __main__.output['eventstruct'] KeyError: 'eventstruct' make[3]: *** [Makefile:1051: xproto.py] Error 1
Bug#892290: light-locker: at unlock, crash with: arguments to dbus_message_new_method_call() were incorrect
Package: light-locker Version: 1.8.0-1 Severity: grave Tags: security Justification: user security hole Dear Maintainer, Light-locker crashes when I unlock my session. This means that my session is not locked the next time it should be, When I run light-locker at the command line I see: % light-locker --lock-after-screensaver=3600 dbus[26450]: arguments to dbus_message_new_method_call() were incorrect, assertion "path != NULL" failed in file ../../../dbus/dbus-message.c line 1362. This is normally a bug in some application using the D-Bus library. D-Bus not built with -rdynamic so unable to print a backtrace Aborted I've installed light-locker-dbgsym but the didn't improve the error message. I have various XDG environment variables set. % env | grep XDG XDG_CONFIG_HOME=/home/stuart/.config XDG_MENU_PREFIX=lxde- XDG_VTNR=7 XDG_SESSION_ID=2 XDG_GREETER_DATA_DIR=/var/lib/lightdm/data/stuart XDG_SESSION_TYPE=x11 XDG_DATA_DIRS=/usr/local/share:/usr/share:/usr/share/gdm:/var/lib/menu-xdg:/usr/local/share/:/usr/share/:/usr/share/gdm/:/var/lib/menu-xdg/ XDG_SESSION_DESKTOP=LXDE XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0 XDG_CURRENT_DESKTOP=LXDE XDG_SEAT=seat0 XDG_RUNTIME_DIR=/run/user/1000 XDG_DATA_HOME=/home/stuart/.local/share XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session0 XDG_CONFIG_DIRS=/etc/xdg -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'unstable-debug'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.14.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages light-locker depends on: ii dconf-gsettings-backend [gsettings-backend] 0.26.1-3 ii libc62.27-1 ii libcairo21.15.10-2 ii libdbus-1-3 1.12.6-2 ii libdbus-glib-1-2 0.110-2 ii libglib2.0-0 2.54.3-2 ii libgtk-3-0 3.22.28-1 ii libpango-1.0-0 1.40.14-1 ii libpangocairo-1.0-0 1.40.14-1 ii libsystemd0 237-4 ii libx11-6 2:1.6.4-3 ii libxext6 2:1.3.3-1+b2 ii libxss1 1:1.2.2-1+b2 ii lightdm 1.18.3-4 light-locker recommends no packages. light-locker suggests no packages. -- Configuration Files: /etc/xdg/autostart/light-locker.desktop changed: [Desktop Entry] Type=Application Name=Screen Locker Name[ca]=Bloquejador de pantalla Name[cs]=Uzamykač obrazovky Name[da]=Skærmlås Name[de]=Bildschirmsperre Name[en_GB]=Screen Locker Name[es]=Bloqueador de pantalla Name[fa]=قفل صفحه Name[fi]=Näytön lukitusohjelma Name[fr]=Verrouilleur d'écran Name[gl]=Bloqueado da pantalla Name[gu]=સ્ક્રીન લૉકર Name[hi]=परदा अबरोधक Name[hu]=Képernyőzár Name[it]=Blocca schermo Name[ja]=スクリーンのロック Name[kk]=Экран блоктаушысы Name[lt]=Ekrano užrakinimas Name[nb]=Skjermlås Name[nl]=Schermvergrendeling Name[or]=ପରଦା ଅବରୋଧକ Name[pl]=Blokada ekranu Name[pt]=Bloqueio de Ecrã Name[pt_BR]=Bloqueio de Tela Name[ru]=Блокировщик экрана Name[sk]=Uzamykač obrazovky Name[tr]=Ekran Kilitleyici Name[zh_CN]=屏幕锁 Name[zh_TW]=螢幕鎖定 Comment=Launch screen locker program Comment[ca]=Obre el programa de bloqueig de la pantalla Comment[cs]=Spustit Uzamykač obrazovky Comment[da]=Start program for skærmlås Comment[de]=Bildschirmsperre starten Comment[en_GB]=Launch screen locker program Comment[es]=Abrir el programa de bloqueo de pantalla Comment[fi]=Käynnistä näytön lukitusohjelma Comment[fr]=Lancer le verrouilleur d'écran Comment[gl]=Iniciar o programa de bloqueo da pantalla Comment[gu]=સ્ક્રીન લૉકર પ્રક્રિયાને શરુ કરો Comment[hi]=परदा अबरोधक प्रोग्राम आरम्भ करें Comment[hu]=Képernyőzár program indítása Comment[it]=Lancia il programma blocca schermo Comment[ja]=スクリーンロックのプログラムを実行する Comment[kk]=Экранды блоктау бағдарламасын жөнелту Comment[lt]=Paleisti ekrano užrakinimo programą Comment[nb]=Kjør skjermlåsningsprogram Comment[nl]=Schermvergrendelingsprogramma starten Comment[or]=ପରଦା ଅବରୋଧକ ଆରମ୍ଭ କରନ୍ତୁ Comment[pl]=Uruchamia program blokady ekranu Comment[pt]=Lançar o programa de bloqueio do ecrã Comment[pt_BR]=Iniciar o programa de bloqueio de tela Comment[ru]=Запустить программу блокировки экрана Comment[sk]=Spúšťa program na uzamknutie obrazovky Comment[tr]=Ekran kilitleyici programını başlat Comment[zh_CN]=启动屏幕锁程序 Comment[zh_TW]=啟動螢幕鎖定程式 Icon=preferences-desktop-screensaver Exec=light-locker --lock-after-screensaver=3600 NoDisplay=true NotShowIn=GNOME;Unity; -- no debconf information
Bug#892291: RFP: libjs-strophe.jinglejs -- webrtc connection plugin for strophe.js
Package: wnpp Severity: wishlist * Package name: libjs-strophe.jinglejs Version : v0.2.3 Upstream Author : Klaus Herberth* URL : https://github.com/jsxc/strophe.jinglejs * License : MIT Programming Lang: JavaScript Description : webrtc connection plugin for strophe.js strophe.jinglejs is a webrtc connection plugin for strophe.js that uses jingle.js. Strophe is a popular library for writing XMPP client applications that run on any of the current popular browsers. Instead of the native TCP binding, strophe.js uses BOSH (Bidirectional-streams Over Synchronous HTTP, a variant of long polling) to connect to an XMPP server. Besides enabling anyone to build (federated) IM applications, this opens up the browser as an addressable endpoint for two-way exchange of structured messages, including presence and publish-subscribe applications. This plugin makes it possible to negotiate audio/video streams via XMPP and then relinquish control to the WebRTC support of browsers like Firefox and Chrome for the actual out-of-band media streams. XMPP/Jingle you get the authenticated, secured and federated media signaling, whereas WebRTC gives you an API to set up the media streams using RTP/ICE/STUN and provide access to cameras and microphones.
Bug#892289: RFP: libjs-jingle -- Generic Jingle via WebRTC session manager
Package: wnpp Severity: wishlist * Package name: libjs-jingle Version : v3.0.3 Upstream Author : Lance Stout* URL : https://github.com/otalk/jingle.js * License : MIT Programming Lang: JavaScript Description : Generic Jingle via WebRTC session manager Library to use Jingle with WebRTC. This is a dependency for libjs-strophe.jinglejs and libjs-jsxc.
Bug#872057: (no subject)
This is due to a change in the behavior of tar's --no-recursion option. In either 1.28 or 1.29, it was changed to only apply to all options *following* it. Since the flexbackup command line has --files-from before --no-recursion, the --no-recursion is effectively ignored. (See also bug #829738) Changing the order restores the correct behavior (see attached patch). --- /usr/bin/flexbackup 2018-03-07 21:51:57.950379925 +0100 +++ /usr/bin/flexbackup 2018-03-07 21:52:17.418333887 +0100 @@ -1405,11 +1405,11 @@ $cmd .= "| "; $cmd .= "$::path{tar} --create "; +$cmd .= "--no-recursion "; $cmd .= "--null "; $cmd .= "--files-from=- "; $cmd .= "--ignore-failed-read "; $cmd .= "--same-permissions "; -$cmd .= "--no-recursion "; $cmd .= "--totals "; if ($cfg::label ne 'false') { if (length($title) > $::tar_max_label) {
Bug#892288: arrayfire FTBFS on i386: test segfaults
Source: arrayfire Version: 3.3.2+dfsg1-4 Severity: serious Tags: buster sid https://tests.reproducible-builds.org/debian/rb-pkg/unstable/i386/arrayfire.html ... 98% tests passed, 2 tests failed out of 95 Total Test time (real) = 53.16 sec The following tests FAILED: 4 - Test_assign_cpu (SEGFAULT) 43 - Test_index_cpu (SEGFAULT) Errors while running CTest Makefile:143: recipe for target 'test' failed make[2]: *** [test] Error 8 Whatever broke it was not yet in unstable on 2017-12-31, but likely entered buster before 2018-01-31: https://tests.reproducible-builds.org/debian/history/arrayfire.html
Bug#892108: Patch for several FTBFS
Package: src:nim Version: 0.18.0-1 Tags: patch pending User: debian-powe...@lists.debian.org Usertags: ppc64el -- Dear maintainer, I see that the package nim fails to build on ppc64el : https://buildd.debian.org/status/fetch.php?pkg=nim=ppc64el=0.18.0-1=1520093894=0 but also on arm64 and ppc64. It seems that the debian/platforms.table file is a bit outdated. Also a previous bug (#876526) about a FTBFS on mips64el was fixed by removing support on that arch, but providing the proper mapping in platforms.table enables the build to finish sucessfully. Here is a debdiff and some build logs on mips64el and arm64 : http://debomatic-mips64el.debian.net/distribution#unstable/nim/0.18.0-1fixFTBFS1/buildlog http://debomatic-arm64.debian.net/distribution#unstable/nim/0.18.0-1fixFTBFS1/buildlog (I tested myself on ppc64el and it worked too). Regards. F. pgpMXWfjH_OF5.pgp Description: PGP signature diff -Nru nim-0.18.0/debian/changelog nim-0.18.0/debian/changelog --- nim-0.18.0/debian/changelog 2018-03-03 15:38:45.0 +0100 +++ nim-0.18.0/debian/changelog 2018-03-07 19:07:30.0 +0100 @@ -1,3 +1,9 @@ +nim (0.18.0-1fixFTBFS1) UNRELEASED; urgency=medium + + * Fix FTBFS on ppc64, ppc64el, arm64 and re-enable mips64el + + -- Frédéric BonnardWed, 07 Mar 2018 19:06:24 +0100 + nim (0.18.0-1) unstable; urgency=medium * New upstream release diff -Nru nim-0.18.0/debian/control nim-0.18.0/debian/control --- nim-0.18.0/debian/control 2018-03-03 15:38:45.0 +0100 +++ nim-0.18.0/debian/control 2018-03-07 19:05:07.0 +0100 @@ -12,7 +12,7 @@ Vcs-Browser: https://salsa.debian.org/debian/nim Package: nim -Architecture: amd64 arm64 armel armhf i386 mips mipsel powerpc ppc64 ppc64el +Architecture: amd64 arm64 armel armhf i386 mips mipsel mips64el powerpc ppc64 ppc64el Depends: ${shlibs:Depends}, ${misc:Depends}, libssl1.1 diff -Nru nim-0.18.0/debian/platforms.table nim-0.18.0/debian/platforms.table --- nim-0.18.0/debian/platforms.table 2018-03-03 15:38:45.0 +0100 +++ nim-0.18.0/debian/platforms.table 2018-03-07 19:06:09.0 +0100 @@ -10,12 +10,13 @@ m68k m68k alpha alpha powerpcpowerpc -ppc64 powerpc64 -ppc64elpowerpc64el +ppc64 ppc64 +ppc64elppc64le sparc sparc ia64 ia64 amd64 amd64 mips mips mipsel mipsel +mips64el mips64el armarm -arm64 arm64 +arm64 aarch64 pgphquNzJTclR.pgp Description: PGP signature
Bug#855251: easytag corrupt ogg files
Package: easytag Version: 2.4.3-1 Followup-For: Bug #855251 Could you please also push the update disabling OGG support to stable? I seem to have corrupted who knows how many files over the last weeks. This is especially insidious, since the corrupted files still work in some media players, but do not work with others (I had huge trouble on my Android phone, for example, and had no idea it was in fact easytag's fault)! -- System Information: Debian Release: 9.3 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'stable-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-6-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages easytag depends on: ii dconf-gsettings-backend [gsettings-backend] 0.26.0-2+b1 ii libc62.24-11+deb9u1 ii libflac8 1.3.2-1 ii libgcc1 1:6.3.0-18+deb9u1 ii libgdk-pixbuf2.0-0 2.36.5-2+deb9u2 ii libglib2.0-0 2.50.3-2 ii libgtk-3-0 3.22.11-1 ii libid3-3.8.3v5 3.8.3-16.2+b1 ii libid3tag0 0.15.1b-12 ii libogg0 1.3.2-1 ii libopus0 1.2~alpha2-1 ii libopusfile0 0.8-1+b1 ii libspeex11.2~rc1.2-1+b2 ii libstdc++6 6.3.0-18+deb9u1 ii libtag1v51.11.1+dfsg.1-0.1 ii libvorbis0a 1.3.5-4+deb9u1 ii libvorbisfile3 1.3.5-4+deb9u1 ii libwavpack1 5.0.0-2+deb9u1 Versions of packages easytag recommends: ii gnome-icon-theme 3.12.0-2 ii gvfs 1.30.4-1 ii yelp 3.22.0-1 Versions of packages easytag suggests: pn easytag-nautilus -- no debconf information
Bug#892287: RFP: python3-aioopenssl -- OpenSSL transport for asyncio
Package: wnpp Severity: wishlist * Package name: python3-aioopenssl Version : v0.3.1 Upstream Author : Jonas Wielicki* URL : https://github.com/horazont/aioopenssl * License : Apache Programming Lang: Python Description : OpenSSL transport for asyncio aioopenssl provides a asyncio Transport which uses PyOpenSSL instead of the built-in ssl module. The transport has two main advantages compared to the original: - The TLS handshake can be deferred by passing use_starttls=True and later calling the starttls() coroutine method. - This is useful for protocols with a STARTTLS feature. - A coroutine can be called during the TLS handshake; this can be used to defer the certificate check to a later point, allowing e.g. to get user feedback before the starttls() method returns. This allows to ask users for certificate trust without the application layer protocol interfering or starting to communicate with the unverified peer.
Bug#892286: RFP: python3-aiosasl -- pure python generic asyncio SASL library
Package: wnpp Severity: wishlist * Package name: python3-aiosasl Version : v0.3.1 Upstream Author : Jonas Wielicki* URL : https://github.com/horazont/aiosasl * License : LGPL3 Programming Lang: Python Description : pure python generic asyncio SASL library aiosasl provides a generic, asyncio-based SASL library. It can be used with any protocol, provided the neccessary interface code is provided by the application or protocol implementation. Supported SASL mechanisms - PLAIN: authenticate with plaintext password (RFC 4616) - ANONYMOUS: anonymous "authentication" (RFC 4505) - SCRAM-SHA-1, SCRAM-SHA-224, , SCRAM-SHA-512, SCRAM-SHA-384, and SCRAM-SHA-256: Salted Challenge Response Authentication (RFC 5802), (and the -PLUS variants with channel binding).
Bug#889233: Pending fixes for bugs in the golang-github-joho-godotenv package
tag 889233 + pending thanks Some bugs in the golang-github-joho-godotenv package are closed in revision 8d5c05cf0f0aff192384a3447c87e11ebdf5aeef in branch 'master' by Dr. Tobias Quathamer The full diff can be seen at https://anonscm.debian.org/cgit/pkg-go/packages/golang-github-joho-godotenv.git/commit/?id=8d5c05c Commit message: Set maintainer to Debian Go Packaging Team. Closes: #889233
Bug#887873: linux-image-4.9.0-5-marvell: frequent "usercopy: kernel memory overwrite attempt detected" on QNAP NAS (ARM)
On Thu, 8 Mar 2018, at 02:36, Andrew Lunn wrote: > > What else can I try? > > Do you have transparent huge pages enabled? > > ~$ cat /sys/kernel/mm/transparent_hugepage/enabled > [always] madvise never > > If so, could you disable it with: > > echo never > /sys/kernel/mm/transparent_hugepage/enabled > > and run your rsync command. I'll check this at the next opportunity. Also, I'm comfortable with patching and compiling kernels if necessary.
Bug#891126: python-proliantutils: FTBFS with TypeError: refresh() got an unexpected keyword argument 'force'
Hi Andreas, Could you try again to build the package? I just did with sbuild, and it was building fine. Could it be that I wasn't finished uploading the rest of OpenStack to Sid? Cheers, Thomas Goirand (zigo)
Bug#892285: /usr/bin/fpcmake: fpcmake should find units in Debian without fiddling with FPCDIR
Package: fp-utils-3.0.4 Version: 3.0.4+dfsg-15 Severity: normal File: /usr/bin/fpcmake -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 fpcmake doesn't work out of the box in Debian (maybe since the multiarch changes, but I am not sure about that). E.g. in the Lazarus source tree I get this: paul@testavoira ~/lazarus $ fpcmake -r -v FPCMake Version 2.0.0 [2017-02-13 rev 35434] Processing Makefile.fpc Targets: "x86_64-linux" Globals: FPCDIR = "" PACKAGESDIR = "$(FPCDIR)/packages $(FPCDIR)/packages/base $(FPCDIR)/packages/extra $(FPCDIR)/packages" UNITSDIR = "$(FPCDIR)/units/$(FULLTARGET)" BASEDIR = "/home/paul/packages/freepascal/lazarus" Required packages for linux-x86_64: rtl regexpr Package "rtl": Looking for Makefile.fpc: " /packages/rtl/Makefile.fpc /packages/base/rtl/Makefile.fpc /packages/extra/rtl/Makefile.fpc /packages/rtl/Makefile.fpc " Package "rtl": Looking for Package.fpc: " /units/x86_64-linux/rtl/Package.fpc " Error: Target "linux", package "rtl" not found Lazarus is defining FPCDIR in its d/rules file to prevent this like: FPCDIR=/usr/share/fpcsrc/${FPCVER} Transgui is/was doing it like: FPCDIR=/usr/lib/fpc/${FPCDIR} I believe neither should be needed. Also, which one of the two is correct (or better, if neither is really correct)? Paul - -- System Information: Debian Release: buster/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (200, 'testing'), (50, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.14.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages fp-utils-3.0.4 depends on: ii fpc-source-3.0.4 3.0.4+dfsg-15 ii libc6 2.26-6 Versions of packages fp-utils-3.0.4 recommends: ii fp-compiler-3.0.4 3.0.4+dfsg-15 fp-utils-3.0.4 suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAlqgS6YACgkQnFyZ6wW9 dQpVjAf/WKH9mpTybtk9CC29DdxupoZ0yvpsA3fnGcbPC9cNLUGm5CqG7EtC2jY1 25mKsm+QzZXMu/gbexZfnqFK4mhEGCWfoXSK47QUsEspu+c3cuao97ySE75iIXJY OSHtNUB9uHeN0jjbVXAE7fI2IEiTKYBwlSxXvhTC65tYikjcdqgdbFNa1jsYdjA3 Z/tNM2iI7SsSmubLvQiCQq/ZP3fYkAA9vydE+dw1/uIUh3/z7gIzVlpT2nd2uXpb iidAMmLsMQ0gyZ079u8Yt+X2eNrAb3sre3mGjyRfjYkprqoWrbICHJZ8eN5Tc001 SjAE1D68CBzuvFAtyErMudwg06AWGg== =4I4S -END PGP SIGNATURE-
Bug#892284: ITP: ChromHMM -- Chromatin state discovery and characterization
Package: wnpp Severity: wishlist Owner: Debian Med Packaging TeamPackage name: chromhmm URL: http://compbio.mit.edu/ChromHMM/ License: GPL-3+ Description: Chromatin state discovery and characterization ChromHMM is software for learning and characterizing chromatin states. ChromHMM can integrate multiple chromatin datasets such as ChIP-seq data of various histone modifications to discover de novo the major re-occuring combinatorial and spatial patterns of marks. ChromHMM is based on a multivariate Hidden Markov Model that explicitly models the presence or absence of each chromatin mark. The resulting model can then be used to systematically annotate a genome in one or more cell types. By automatically computing state enrichments for large-scale functional and annotation datasets ChromHMM facilitates the biological characterization of each state. ChromHMM also produces files with genome-wide maps of chromatin state annotations that can be directly visualized in a genome browser. This package will be maintained by the Debian Med Packaging Team at: https://salsa.debian.org/med-team/chromhmm.git/
Bug#890665: Bug #890665
Le mercredi 07 mars 2018 à 21:11 +0100, gpe a écrit : > Le mardi 06 mars 2018 à 11:07 +0200, Jonathan Carter (highvoltage) a écrit : > > Hi > > > > Does this still happen on your system? > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890665 > > > > I just enabled it on my unstable system and it seems to load both the > > extension and it's settings manager just fine. Will try it on a clean > > unstable system next. > > > > -Jonathan > > Hi, > > It's ok now but I don't know if it is due to a debian correction or if it is > related to an update of the extension. How can I see the version of an > extension? > > Regards. I found the version. My extension is the version 34. So it is not the debian one. So I don't know if the debian version (which is 33) works or not. Regards.
Bug#890665: Bug #890665
Le mardi 06 mars 2018 à 11:07 +0200, Jonathan Carter (highvoltage) a écrit : > Hi > > Does this still happen on your system? > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890665 > > I just enabled it on my unstable system and it seems to load both the > extension and it's settings manager just fine. Will try it on a clean > unstable system next. > > -Jonathan Hi, It's ok now but I don't know if it is due to a debian correction or if it is related to an update of the extension. How can I see the version of an extension? Regards.
Bug#892283: RFP: python-pendulum -- Python datetimes made easy
Package: wnpp Severity: wishlist * Package name: python-pendulum Version : 1.4.2 Upstream Author : Sébastien Eustace* URL : https://pendulum.eustace.io/ * License : MIT Programming Lang: Python Description : Python datetimes made easy Native datetime instances are enough for basic cases but when you face more complex use-cases they often show limitations and are not so intuitive to work with. . Pendulum provides a cleaner and easier to use API while still relying on the standard library. So it's still datetime but better. . Unlike other datetime libraries for Python, Pendulum is a drop-in replacement for the standard datetime class (it inherits from it), so, basically, you can replace all your datetime instances by Pendulum instances in you code (exceptions exist for libraries that check the type of the objects by using the type function like sqlite3 or PyMySQL for instance). . It also removes the notion of naive datetimes: each Pendulum instance is timezone-aware and by default in UTC for ease of use. . Pendulum also improves timedelta by providing more intuitive methods and properties. See the documentation for more information.
Bug#888515: debian-installer: UEFI boot menu (grub) misses the help screen
Samuel Thibault, on mar. 06 mars 2018 19:13:45 +0100, wrote: > Samuel Thibault, on lun. 05 févr. 2018 10:31:40 +0100, wrote: > > I have reported the feature request to http://savannah.gnu.org/bugs/?53065 > > Here is an answer: > > “ > the solution which is available atm is: > > set pager=1 > cat ($root)/boot/grub/MESSAGE.txt > unset pager > echo -n "-- Press ESC or wait 60 sec to continue: " > sleep --verbose --interruptible 60 > > There is no pause command. To stop for a minute before showing the menu: sleep > continues on Escape key only. > ” And “ set pager=1 cat ($root)/boot/grub/MESSAGE.txt unset pager echo -n "-- Press ENTER to continue: " read ” Samuel
Bug#864184: Raising severity
severity 864184 serious thanks This basically makes noping completely useless, so I'm raising this to RC. I'm happy to upload an NMU if you're busy. Cheers, -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Bug#887967: [Pkg-pascal-devel] Bug#887967 closed by Abou Al Montacir <abou.almonta...@sfr.fr> (Bug#887967: fixed in fpc 3.0.4+dfsg-14)
On 7 March 2018 at 20:47, Paul Geverswrote: >>> This can be worked around by the following change in debian/rules: >>> >>> -export FPCDIR=/usr/lib/fpc/${FPCDIR} >>> +export FPCDIR=/usr/lib/$(DEB_HOST_MULTIARCH)/fpc/default > > @Graham, have you verified this? It worked for in a local build on amd64. > On arm64 the situation if fully different. Clean doesn't work (which > could be easily worked around in multiple ways). I.e. this should not be > blocking for building on arm64. arm64 is fixed in Ubuntu, patch in comment 23 of #803986 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=803986#23
Bug#892272: libopenmpt0: segfaults with memcopy if loaded from external application
Am Mittwoch, den 07.03.2018, 09:32 -0500 schrieb s3rj1k: > Using this shared library with external application creates segfault > with memcopy related functions. Since you are mentioning memcpy(), maybe the code calls it with overlapping source and destination pointers and -O3 optimizes this to call memmove() instead? - Fabian signature.asc Description: This is a digitally signed message part
Bug#855198: Adding i386 support
Am Mittwoch, den 07.03.2018, 11:58 -0300 schrieb Ignacio Losiggio: > I know that not _every_ x86 machine has sse2 support but i think that > having a usable package for those who use x86 on post-2003 computers Why is an i386 package only usable if compiled with sse2 instructions? If you are targeting post-2003 computers, why aren't you using an amd64 build anyway? - Fabian signature.asc Description: This is a digitally signed message part
Bug#892282: lcl-utils-1.8: /etc/lazarus-1.8/environmentoptions.xml doesn't point to new FPCSourceDirectory
Package: lcl-utils-1.8 Version: 1.8.2+dfsg-3 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 While looking into bug 887967, I noticed that /etc/lazarus-1.8/environmentoptions.xml doesn't mention the new location of FPCSourceDirectory yet. Paul - -- System Information: Debian Release: buster/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (200, 'testing'), (50, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.14.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lcl-utils-1.8 depends on: ii debconf [debconf-2.0]1.5.66 ii fp-compiler-3.0.4 [fp-compiler] 3.0.4+dfsg-15 ii libc62.26-6 Versions of packages lcl-utils-1.8 recommends: pn lazarus-ide-1.8 pn lcl-1.8 lcl-utils-1.8 suggests no packages. -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAlqgOicACgkQnFyZ6wW9 dQrpAAf/SmcXmQp98PjgiT+Hg1TeEtUlcfzKK1HW4QIG3s/Q/jIR17YbeALqT09f oCH8DnAdffGTQXvvEquCx2zWsdl7p++NKQea8XFptBsjgcGTDTGEPDFZXD3Kj60+ yR1RlyPWSiB2z2PegN1u0MTBZbuHo3sUuYxZkbW1kCumzek54VtXwgk7OP4OFtSK 5z0wciUjN2r5M4Uvxbb/bpUsl7QQUystOIjdTfEbZBsCVffr015DEtbS1+uA5R5f i4sQI5UvOvMwaSAtJJdVp1IV+ohrz/1erBOyv3k8qwHHt4rbzOEhpGWhoeFP/CF5 XfizcHCp+hBZ61x7EALmcC+g5HnG3g== =Ehn1 -END PGP SIGNATURE-
Bug#887967: [Pkg-pascal-devel] Bug#887967 closed by Abou Al Montacir <abou.almonta...@sfr.fr> (Bug#887967: fixed in fpc 3.0.4+dfsg-14)
Hi Additional note, I got the same error¹ on debomatic² while debugging the FTBFS of lazarus on mips/mipsel. Interestingly enough the exact same source build succeeded on the build infrastructure. So maybe something flaky IS going on. Paul ¹ find * -name Makefile.fpc -exec fpcmake -Tall -q '{}' ';' Error: Target "linux", package "rtl" not found ... ² http://debomatic-mips.debian.net/distribution#unstable/lazarus/1.8.2+dfsg-2/buildlog signature.asc Description: OpenPGP digital signature
Bug#887967: [Pkg-pascal-devel] Bug#887967 closed by Abou Al Montacir <abou.almonta...@sfr.fr> (Bug#887967: fixed in fpc 3.0.4+dfsg-14)
Hi all, On 07-03-18 18:28, Michalis Kamburelis wrote: > "2018-03-07 16:46 GMT+01:00 Graham Inggs: >> On Tue, 23 Jan 2018 08:46:09 +0200 Adrian Bunk wrote: >>> >>> This problem is unfortunately still present with fpc 3.0.4+dfsg-14: >>> >>> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/transgui.html Yes, but not for i386 and armhf. Weird. >> This can be worked around by the following change in debian/rules: >> >> -export FPCDIR=/usr/lib/fpc/${FPCDIR} >> +export FPCDIR=/usr/lib/$(DEB_HOST_MULTIARCH)/fpc/default @Graham, have you verified this? > It seems that transgui is using an older "fpcmake" system (depending > on Makefile which is auto-generated based on "Makefile.fpc" contents). > The auto-detection is in a different place then, although it is also > overridden by $FPCDIR environment variable. transgui is calling fpcmake in d/rules, so it is regenerating all the Makefiles (which is good). The failure happens DURING the call to fpcmake. On arm64 the situation if fully different. Clean doesn't work (which could be easily worked around in multiple ways). I.e. this should not be blocking for building on arm64. Paul signature.asc Description: OpenPGP digital signature
Bug#694068: netcfg: Wireless connectivity present during an install but absent afterwards
On Tue 06 Mar 2018 at 11:07:59 +1100, Trent W. Buck wrote: > Brian Potkin wrote: > > The number of users affected by this issue over the years is not > > insignificant. Not a single one has written in support of the > > situation. > > This issue has bitten me at least twice so far. > > This issue's history seems to be bogged down on whether interfaces(5) > can be mode 0600 (to hide the cleartext passphrase). > This is not necessary; the passphrase can go in a separate file. Mode 0600 wasn't intially given as a reason: https://lists.debian.org/debian-boot/2012/09/msg00282.html > I realise a default is only a default and the selection can be changed, > but I'm puzzled by the third option. Why treat a wireless install > differently from a wired install? It would expected that a user who has > chosen not to use a wired connection would still want connectivity after > booting into into the new system, The main reason for this is that as far as I know writing configs related to a wireless network to /e/n/i enforce using only that particular network later (of course if you don't modify the file) and also that the interface is unmanageable for other tools. The idea was to leave the network unconfigured, so that it can be managed later (perhaps via something else than NM). Later in the thread: https://lists.debian.org/debian-boot/2012/09/msg00313.html > On the other hand, we have users who chose not to install a desktop > environment but want their machine to migrate between networks when it's > moved. These users are going to need to do some form of sysadmin work > post-install, whether it's installing a desktop environment and wicd, or > editing /etc/network/interfaces on each fresh network, or bringing up > wifi connections by hand. So I can't see locking a default into > /etc/network/interfaces causing them much bother. IIRC we decided on this default before we added the code to change the access mode of /e/n/i if it contains a password. The main reason for defaulting to no configuration in this case was to avoid having passwords in there. If people think it should default to ifupdown in this case this can be changed. The default (loopback only for wireless) was added without considering mode 0600. At this stage in the history there appears to be a willingness to use ifupdown and not loopback. > Here is a minimal config, assuming WPA2 PSK (not Enterprise) and DHCP (not > static) for all SSIDs: > > cat >/etc/network/interfaces < allow-auto lo $iface > iface lo inet loopback > iface default inet dhcp > iface $iface inet manual > wpa-roam /etc/wpa_supplicant/wpa_supplicant-$iface.conf > EOF > > wpa_passphrase "$ssid" "$passphrase" > >"/etc/wpa_supplicant/wpa_supplicant-$iface.conf" > chmod 0600 "/etc/wpa_supplicant/wpa_supplicant-$iface.conf" > > If you don't want to udebify wpa_passphrase, you can do it by hand: > > cat >"/etc/wpa_supplicant/wpa_supplicant-$iface.conf" < network={ > ssid="$ssid" > psk="$passphrase" > } > EOF > > If you really hate ifupdown, you can use systemd instead (not fully tested): > > cat >/etc/systemd/network/$iface.network < [Match] > iface=$iface > [Network] > DHCP=yes > EOF > > systemctl enable wpa_supplicant@$iface.service > > wpa_passphrase "$ssid" "$passphrase" > >"/etc/wpa_supplicant/wpa_supplicant-$iface.conf" > chmod 0600 "/etc/wpa_supplicant/wpa_supplicant-$iface.conf" > > If even these things are too much, can you AT LEAST install > wpasupplicant? Writing config files is much easier than ferrying > .debs between computers by USB key. > > If this bug is going to be kept ANOTHER Debian release, can you at > least warn people about it in the buster Installation Guide? Or dispense with loopback for an installation over wireless (an easy enough change) and warn about 0600 in the Release Notes. -- Brian.
Bug#861649: Newer version uploaded
Control: tags -1 moreinfo On Tue, 06 Mar 2018 16:24:53 +0100 Gard Spreemann> Upstream provided a patch that fixes this. I've updated > > https://mentors.debian.net/debian/pool/main/g/gudhi/gudhi_2.1.0+dfsg -1.dsc Thanks! But the lintian stuff I complained about is not completly fixed, there is even a new tag: I: gudhi source: quilt-patch-missing-description no-external-doc- resources.patch Please run lintian after every build! Best, include it into pbuilder or like! Remember "some sponsors are evil and pedantic [1] when running lintian. [1] https://nthykier.wordpress.com/2012/02/23/some-sponsors-are-evil-a nd-pedantic/ Those linitian messages should be fixed before an upload: (As at least partially already asked for in earlier reviews) N: Starting on group gudhi/2.1.0+dfsg-1 N: Unpacking packages in group gudhi/2.1.0+dfsg-1 N: N: Processing changes file gudhi (version 2.1.0+dfsg-1, arch source amd64 all) ... N: N: Processing source package gudhi (version 2.1.0+dfsg-1, arch source) ... I: gudhi source: binary-control-field-duplicates-source field "section" in package gudhui P: gudhi source: file-contains-trailing-whitespace debian/control (line 110) P: gudhi source: package-uses-old-debhelper-compat-version 10 I: gudhi source: quilt-patch-missing-description no-external-doc- resources.patch W: gudhi source: unnecessary-testsuite-autopkgtest-field N: N: Processing binary package python3-gudhi (version 2.1.0+dfsg-1, arch amd64) ... I: python3-gudhi: spelling-error-in-binary usr/lib/python3/dist- packages/gudhi.cpython-36m-x86_64-linux-gnu.so ment meant I: python3-gudhi: spelling-error-in-binary usr/lib/python3/dist- packages/gudhi.cpython-36m-x86_64-linux-gnu.so preambule preamble I: python3-gudhi: spelling-error-in-binary usr/lib/python3/dist- packages/gudhi.cpython-36m-x86_64-linux-gnu.so choosen chosen N: N: Processing binary package libgudhi-examples (version 2.1.0+dfsg-1, arch all) ... W: libgudhi-examples: lib-recommends-documentation recommends: libgudhi-doc N: N: Processing binary package libgudhi-doc (version 2.1.0+dfsg-1, arch all) ... I: libgudhi-doc: possible-documentation-but-no-doc-base-registration N: N: Processing binary package libgudhi-dev (version 2.1.0+dfsg-1, arch all) ... N: N: Processing binary package python3-gudhi-dbgsym (version 2.1.0+dfsg- 1, arch amd64) ... N: N: Processing binary package gudhui (version 2.1.0+dfsg-1, arch amd64) ... I: gudhui: spelling-error-in-binary usr/bin/gudhui preambule preamble P: gudhui: no-upstream-changelog W: gudhui: binary-without-manpage usr/bin/gudhui Please review d/copyright. I found at least one undocumented file which is licensed Apache 2.0 and another one under LGPL3+. Neither are in d/copyright. Again, remove moreinfo when ready. -- tobi
Bug#892281: gcc: make PIE opt-out rather than opt-in
Source: gcc-8 Version: 8-20180218-1 Severity: wishlist We have long transitioned to PIE by default on all release architectures now. Still each gcc-V package tracks the architectures that enable PIE by default in an opt-in list (pie_archs). Since it is the default, PIE is much better supported than !PIE now. For instance, musl-linux-mips fails building dash, because ld segfaults. Once enabling PIE for musl, it proceeds. Similarly, x32 fails linking systemd and it obviously is connected to !PIE: ld: /tmp/cc9ezYWe.ltrans0.ltrans.o: relocation R_X86_64_32S against `.rodata' can not be used when making a PIE object; recompile with -fPIC Very likely, the riscv64 people want to enable PIE by default as well. Since it practically is the default "everywhere", can we move on to enable PIE for all "new" architectures by turning the opt-in list opt-out? While at it, can we keep this list as small as possible? At least for musl-linux-any and x32, we know that !PIE causes more harm than PIE. I've Cced this to d-devel to have people object, but I think the case is pretty clear at this point, because opt-out will reduce the maintenance cost. Helmut
Bug#892280: libcdk5: library package needs to be renamed for libncurses6 transition
Package: libcdk5 Version: 5.0.20161210-5 There is a new ncurses version in experimental which changes the soname of the libraries from 5 to 6. One notable change between libncurses5 and libncurses6 is that the "chtype" data type has changed from unsigned long to unsigned int. This affects the cdk library, which makes use of chtype all over the place. If libcdk5 has been rebuilt against libncurses6 but the application using it has not, or vice versa, they disagree about what "chtype" is, and bad things can happen on 64-bit architectures, where sizeof(long) != sizeof(int). For testing purposes, I have built the example programs in libcdk5-doc on amd64 with libncurses6 and the libcdk5 library which is still linked against libncurses5. While most of them seem to work, I got a segfault in demos/clock and a bus error in buttonbox_ex. My conclusion is that it is very risky to allow such combinations, and to rule them out I propose to change the package name of the cdk library, say to libcdk5a. It would then have to build-depend on libncurses-dev (>= 6.1+20180210) to ensure that it is linked against libncurses6 and not libncurses5. Of course this can only be uploaded to experimental for now, but should go to unstable when the ncurses transition starts there. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (101, 'experimental') Architecture: i386 (x86_64) Foreign Architectures: amd64 Kernel: Linux 4.15.7-nouveau (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libcdk5 depends on: ii libc62.27-1 ii libncurses5 6.1+20180210-1 ii libtinfo56.1+20180210-1 libcdk5 recommends no packages. libcdk5 suggests no packages. -- no debconf information
Bug#887967: [Pkg-pascal-devel] Bug#887967 closed by Abou Al Montacir <abou.almonta...@sfr.fr> (Bug#887967: fixed in fpc 3.0.4+dfsg-14)
"2018-03-07 16:46 GMT+01:00 Graham Inggs: > On Tue, 23 Jan 2018 08:46:09 +0200 Adrian Bunk wrote: >> >> This problem is unfortunately still present with fpc 3.0.4+dfsg-14: >> >> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/transgui.html > > > This can be worked around by the following change in debian/rules: > > -export FPCDIR=/usr/lib/fpc/${FPCDIR} > +export FPCDIR=/usr/lib/$(DEB_HOST_MULTIARCH)/fpc/default > > However, it was my understanding that this was supposed to be fixed in FPC, > so forwarding to the Pascal list for comment. > The recent fix in the Debian package of FPC was for the FpMake build system, http://wiki.freepascal.org/FPMake . It tries to auto-detect the standard units location, but can be overridden by $FPCDIR environment variable. The auto-detection was fixed in this case, removing the need for $FPCDIR. It seems that transgui is using an older "fpcmake" system (depending on Makefile which is auto-generated based on "Makefile.fpc" contents). The auto-detection is in a different place then, although it is also overridden by $FPCDIR environment variable. You can see how this works in case of transgui : - This is the source file: https://github.com/transmission-remote-gui/transgui/blob/master/Makefile.fpc - And developer calls "fpcmake" to generate a Makefile like this: https://github.com/transmission-remote-gui/transgui/blob/master/Makefile Searching the generated Makefile, there is a line that tries to auto-guess the FPC library location: https://github.com/transmission-remote-gui/transgui/blob/master/Makefile#L226 . So possibly it can be fixed in FPC package in Debian too. Regards, Michalis
Bug#887967: [Pkg-pascal-devel] Bug#887967 closed by Abou Al Montacir <abou.almonta...@sfr.fr> (Bug#887967: fixed in fpc 3.0.4+dfsg-14)
Hi Graham, On 07-03-18 16:46, Graham Inggs wrote: > On Tue, 23 Jan 2018 08:46:09 +0200 Adrian Bunkwrote: >> This problem is unfortunately still present with fpc 3.0.4+dfsg-14: >> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/transgui.html >> > > This can be worked around by the following change in debian/rules: > > -export FPCDIR=/usr/lib/fpc/${FPCDIR} > +export FPCDIR=/usr/lib/$(DEB_HOST_MULTIARCH)/fpc/default > > However, it was my understanding that this was supposed to be fixed in > FPC, so forwarding to the Pascal list for comment. No, FPC would fix the default behavior. When FPCDIR is defined in debian/rules, it must match. I wonder, does building work without defining FPCDIR at all? Paul signature.asc Description: OpenPGP digital signature
Bug#892279: fai-setup-storage gets BOOT_DEVICE wrong when /boot is in lvm-on-md
package: fai-setup-storage version: 5.5.3 X-Debbugs-CC: l...@sanger.ac.uk Hi, If you have a disk config like the below, with a single / partition (i.e. no separate /boot) on LVM on md-raid, then BOOT_DEVICE is set incorrectly, such that the fai GRUB setup scripts won't manage to install GRUB correctly. For example, in the below example, BOOT_DEVICE is set to /dev/vg_fai/root ; while the example GRUB_PC/10-setup understands devices like /dev/mdXX (and installs grub correctly on the underlying devices), it doesn't understand LVM device names. It seems to me that there are 3 possible solutions: i) fai-setup-storage knows that / is on LVM, so should set BOOT_DEVICE to the underlying pv (which GRUB_PC/10-setup would grok) ii) fai-setup-storage's config file should be extended so you can explicitly set boot_device (e.g. the below would have "rad1 - disk1.1,disk2.1 - - BOOT_DEVICE) iii) GRUB_PC/10-setup could spot an LVM BOOT_DEVICE and find the underlying pv, e.g. x=$(readlink -f $BOOT_DEVICE) if [ "${x%%-*}" = "/dev/dm" ]; then BOOT_DEVICE=$( lvs --noheadings -o devices $BOOT_DEVICE | sed -e 's/^ *\([^(]*\)(.*$/\1/' ) fi and then let the rest of the script do its thing as before. [if you'd like a proper patch of this form, let me know :) ] example disk config: # # Root partition with RAID and LVM, single root partition disk_config disk1 disklabel:gpt-bios fstabkey:uuid align-at:1M bootable:1 primary - 120G- - - disk_config disk2 sameas:disk1 disk_config raid fstabkey:uuid raid1 - disk1.1,disk2.1 - - disk_config lvm fstabkey:uuid vg vg_fai md0 vg_fai-root /100G- ext3 errors=remount-ro vg_fai-swap swap 16G swap sw Thanks, Matthew -- The Wellcome Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE.
Bug#891434:
Is this still the case with 2.02+dfsg1-3 or has it been fixed?
Bug#620511: ITP: ipt-netflow -- netfilter target which sends traffic statistics via NetFlow
Hi Alexey and Dmitry, Alexey Osipov wrote on 02 Apr 2011: > Subject: ITP: ipt-netflow -- netfilter target which sends traffic > statistics via NetFlow Dmitry Yu Okunev wrote on 29 Nov 2014: > I've prepared the packages [1, 2] and I'm waiting for sponsor. > > [1] http://mentors.debian.net/package/ipt-netflow Any of you both still interested in maintaining ipt-netflow as package in Debian? If not, could you please publish your packaging work so far, so that others can build upon it? (Unfortunately mentors.debian.net only keeps packages for 3 months or so, i.e. the links above no more work.) I'd be happy to see this iptables plugin in Debian and would also review, sponsor and/or co-maintain it, if necessary. (Not sure if I'd maintain it alone, so not switching back to "ITP" for now.) P.S.: I just discovered ipt-netflow upstream a few days ago. Hence the late reply on this WNPP bug report. Regards, Axel -- ,''`. | Axel Beckert, https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#884865: Response?
On Wed, Mar 7, 2018 at 8:05 AM, Timo Aaltonenwrote: > > > John Kessenich (main maintainer of glslang) is working on coming up with > > a reasonable versioning scheme for it. So until he does that, you may > > want to use a scheme similar to what I did, that will be overridden with > > whatever he comes up with. The bug to track what he's doing is here: > > > > https://github.com/KhronosGroup/glslang/issues/1255 > > Looks like there's now 5.0 released yesterday, which is nice. If only > spirv-headers got tagged.. Although spirv-headers isn't tagged, it's not too hard to version. The headers API is versioned, and is currently at 1.2, so I simply counted the number of commits in master, and added it to the end of "1.2.". This is the script I put in my package to generate a version number: #!/bin/sh UPSTREAM_REMOTE=khronos UPSTREAM_BRANCH=master COMMON_ANCESTOR=`git merge-base master $UPSTREAM_REMOTE/$UPSTREAM_BRANCH` NB_OF_COMMITS=`git log --oneline $COMMON_ANCESTOR | wc -l` echo "1.2.$NB_OF_COMMITS"
Bug#892278: stretch-pu: package reportbug/7.1.7+deb9u1
Package: release.debian.org Severity: normal Tags: stretch User: release.debian@packages.debian.org Usertags: pu Hi there, as requested in #891918 I am hereby filing another stretch-pu update for reportbug, so that we can fix #878088 in stable too. Please find attached the debdiff. Thanks, Markus diff -Nru reportbug-7.1.7/bin/reportbug reportbug-7.1.7+deb9u1/bin/reportbug --- reportbug-7.1.7/bin/reportbug 2017-05-29 22:00:17.0 +0200 +++ reportbug-7.1.7+deb9u1/bin/reportbug2018-03-03 22:33:28.0 +0100 @@ -32,6 +32,7 @@ import optparse import re import locale +import requests import subprocess import shlex import email @@ -1926,6 +1927,36 @@ listcc += ui.get_multiline( 'Enter any additional addresses this report should be sent to; press ENTER after each address.') +# If the bug is reported against a package with a version that possibly +# indicates a security update add the security or LTS team to CC +# after user confirmation +if pkgversion and package and not self.options.offline and mode > MODE_NOVICE and utils.is_security_update(package, pkgversion): +if ui.yes_no('Do you want to report a regression because of a security update? ', + 'Yes, please inform the LTS and security teams.', + 'No or I am not sure.', True): +distnumber = re.search('[+~]deb(\d+)u\d+', pkgversion).group(1) +support = 'none' +email_address = 'none' +try: +r = requests.get('https://security-tracker.debian.org/tracker/distributions.json', timeout=self.options.timeout) +data = r.json() +for key, value in data.items(): +if distnumber == value['major-version']: +support = value['support'] +email_address = value['contact'] +break + +if support != 'none' and utils.check_email_addr(email_address): +listcc += [email_address] +else: +raise + +except requests.exceptions.RequestException: +ewrite('Unable to connect to security-tracker.debian.org.\n' + 'Please try again later or contact the LTS or security team via email directly.\n') +except: # catch-all +ewrite('No support team contact address could be identified.\n') + if severity and rtype: severity = debbugs.convert_severity(severity, rtype) diff -Nru reportbug-7.1.7/debian/changelog reportbug-7.1.7+deb9u1/debian/changelog --- reportbug-7.1.7/debian/changelog2017-05-29 22:00:17.0 +0200 +++ reportbug-7.1.7+deb9u1/debian/changelog 2018-03-03 22:33:28.0 +0100 @@ -1,3 +1,13 @@ +reportbug (7.1.7+deb9u1) stretch; urgency=medium + + * Non-maintainer upload. + * Backport the fix for Debian bug #878088. Notify the security team or LTS +team about a possible regression if reporting a bug against a package +containing a security fix. + * python3-reportbug: Depend on python3-apt to fix #878088. + + -- Markus KoschanySat, 03 Mar 2018 22:33:28 +0100 + reportbug (7.1.7) unstable; urgency=medium * reportbug/utils.py diff -Nru reportbug-7.1.7/debian/control reportbug-7.1.7+deb9u1/debian/control --- reportbug-7.1.7/debian/control 2017-05-29 22:00:17.0 +0200 +++ reportbug-7.1.7+deb9u1/debian/control 2018-03-03 22:33:28.0 +0100 @@ -36,7 +36,7 @@ Package: python3-reportbug Section: python Architecture: all -Depends: ${misc:Depends}, ${python3:Depends}, apt, python3-debian, python3-debianbts (>= 1.13), file, python3-requests +Depends: ${misc:Depends}, ${python3:Depends}, apt, python3-debian, python3-debianbts (>= 1.13), file, python3-requests, python3-apt Suggests: reportbug Description: Python modules for interacting with bug tracking systems reportbug is a tool designed to make the reporting of bugs in Debian Binärdateien /tmp/BreEiHKSHs/reportbug-7.1.7/reportbug/__pycache__/__init__.cpython-35.pyc und /tmp/ijRwNIQr3y/reportbug-7.1.7+deb9u1/reportbug/__pycache__/__init__.cpython-35.pyc sind verschieden. Binärdateien /tmp/BreEiHKSHs/reportbug-7.1.7/reportbug/__pycache__/__init__.cpython-36.pyc und /tmp/ijRwNIQr3y/reportbug-7.1.7+deb9u1/reportbug/__pycache__/__init__.cpython-36.pyc sind verschieden. diff -Nru reportbug-7.1.7/reportbug/utils.py reportbug-7.1.7+deb9u1/reportbug/utils.py --- reportbug-7.1.7/reportbug/utils.py 2017-05-29 22:00:17.0 +0200 +++ reportbug-7.1.7+deb9u1/reportbug/utils.py 2018-03-03 22:33:28.0 +0100 @@ -39,6 +39,8 @@ import socket import subprocess import pipes +import apt +import gzip from .urlutils import open_url from string import
Bug#824628: golang-metrics-dev and golang-github-rcrowley-go-metrics-dev: error when trying to install together
Followup-For: Bug #824628 Same problem as two years ago: Selecting previously unselected package golang-github-rcrowley-go-metrics-dev. Preparing to unpack .../golang-github-rcrowley-go-metrics-dev_0.0~git20180125.8732c61-1_all.deb ... Unpacking golang-github-rcrowley-go-metrics-dev (0.0~git20180125.8732c61-1) ... dpkg: error processing archive /var/cache/apt/archives/golang-github-rcrowley-go-metrics-dev_0.0~git20180125.8732c61-1_all.deb (--unpack): trying to overwrite '/usr/share/gocode/src/github.com/rcrowley/go-metrics/cmd/metrics-bench/metrics-bench.go', which is also in package golang-metrics-dev 0.0~git20150823-3 Errors were encountered while processing: /var/cache/apt/archives/golang-github-rcrowley-go-metrics-dev_0.0~git20180125.8732c61-1_all.deb Andreas
Bug#858270: closed by Florian Schlichting <f...@debian.org> (Bug#850163: fixed in xpdf 3.04-6)
reopen 858270 This bug is still present, the same as reported. Whatever libpopler does with the fonts, it does it wrong. Attila Kinali -- It is upon moral qualities that a society is ultimately founded. All the prosperity and technological sophistication in the world is of no use without that foundation. -- Miss Matheson, The Diamond Age, Neil Stephenson