Bug#1019347: Fixed NMU
Hi, I just wanted to give a heads up, that earlier today I uploaded an NMU to DELAYED+5 containing upstream version 1.7.4 which should fix this bug. I pushed the changes to the packaging repository on salsa, so I assume a debdiff of the NMU is not required here. Regards Sven OpenPGP_signature Description: OpenPGP digital signature
Bug#1019347: Similar bug still present in 1.7.2
Hi, I just noticed that the current upstream release 1.7.2 still has a bug very similar to this bug present. (https://projects.torsion.org/borgmatic-collective/borgmatic/issues/590) It's basically the same bug, only with `patterns_from` instead of `patterns`. Regards Sven OpenPGP_signature Description: OpenPGP digital signature
Bug#1019347: Backups end up mostly empty when location.patterns is used and /root/.borgmatic exists
Package: borgmatic Version: 1.5.12-2 Severity: grave Tags: upstream fixed-upstream Forwarded: https://projects.torsion.org/borgmatic-collective/borgmatic/issues/574 Control: found -1 1.6.3-1 Hi, Recently I reported the bug mentioned above upstream, which causes most data to be silently excluded from backups if /root/.borgmatic exists. Since details of the bug are already available in the upstream bug report, I will omit them here for brevity. Since the issue has already been fixed upstream, this bug is only meant to track the issue in Debian. I've set the severity to grave, because the bug causes borgmatic to produce effectively empty backups, while the user may believe to have secure backups, which qualifies as data loss to me. Feel free to lower the severity to normal if you disagree. Regards Sven -- System Information: Debian Release: bookworm/sid APT prefers testing-debug APT policy: (990, 'testing-debug'), (990, 'testing'), (102, 'unstable-debug'), (102, 'unstable'), (101, 'experimental-debug'), (101, 'experimental') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-4-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages borgmatic depends on: ii borgbackup 1.2.1-2 ii python33.10.6-1 ii python3-colorama 0.4.5-2 ii python3-jsonschema 4.6.0-3 ii python3-pkg-resources 59.6.0-1.2 ii python3-requests 2.27.1+dfsg-1 ii python3-ruamel.yaml0.17.16-1 borgmatic recommends no packages. borgmatic suggests no packages. -- no debconf information
Bug#1010556: undefined symbol extract_begin
Control: tag -1 +patch On Wed, 4 May 2022 12:57:46 -0400 =?UTF-8?Q?Louis-Philippe_V=c3=a9ronneau?= wrote: Thanks for reporting this bug. I confirm I can reproduce it on my system running unstable. Never caught it since I was running the poppler plugin. Understandable. I discovered this while trying to see what the differences between poppler and mupdf would be. After this I will probably go back to poppler myself. I'll have a closer look at this in the coming days. Since the fix was relatively simple, I opened a merge request on salsa[1]. Regards Sven [1]: https://salsa.debian.org/pollo/qpdfview/-/merge_requests/1 OpenPGP_signature Description: OpenPGP digital signature
Bug#986119: Source package includes files shared libraries with GPL violations
Source: dwarf-fortress
Version: 0.44.12-1
Severity: serious
The source tarballs for both amd64 and i386 contain the following
shared libraries:
$ ls {amd64,i386}/libs/lib{gcc_s.so.1,stdc++.so.6}
amd64/libs/libgcc_s.so.1
amd64/libs/libstdc++.so.6
i386/libs/libgcc_s.so.1
i386/libs/libstdc++.so.6
These files are presumably compiled from GCC runtime components and
licensed under a GPL. But upstream does not publish or point to source
code for these files or give any licensing information for them.
This is clearly a violation of the licenses of these files and we can
not distribute them.
Since these files aren't shipped in any binary packages, we can just
repack the source tarball to exclude them, to sidestep the problem.
-- System Information:
Debian Release: bullseye/sid
APT prefers testing-security
APT policy: (990, 'testing-security'), (990, 'testing-debug'), (990,
'testing'), (102, 'unstable-debug'), (102, 'unstable'), (101,
'experimental-debug'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-5-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
-- no debconf information
Bug#962492: Missing copyright attributions and other problems in debian/copyright
Source: vde2 Version: 2.3.2+r586-2.2+b1 Severity: serious Justification: Policy ยง12.5 Greetings, during the review of this package in the NEW queue I discovered various issues that are already present in the current unstable version of the package as outlined below. These files are marked in the copyright file as BSD-4-clause, but the files themselves only contain 3 clauses: * src/slirpvde/cksum.c * src/slirpvde/ip.h * src/slirpvde/ip_icmp.c * src/slirpvde/ip_icmp.h * src/slirpvde/ip_input.c * src/slirpvde/ip_output.c * src/slirpvde/mbuf.h * src/slirpvde/misc.c * src/slirpvde/qemu-queue.h * src/slirpvde/tcp.h * src/slirpvde/tcp_input.c * src/slirpvde/tcp_output.c * src/slirpvde/tcp_subr.c * src/slirpvde/tcp_timer.c * src/slirpvde/tcp_timer.h * src/slirpvde/tcp_var.h * src/slirpvde/tcpip.h * src/slirpvde/udp.c * src/slirpvde/udp.h The following authors are not attributed in the copyright file for files that list them as copyright holders. This list is not necessarily exhaustive. Please check every file and make sure all authors in the files are attributed in debian/copyright. 2002 Yon Uriarte, Jeff Dike: * README 2014 Renzo Davoli, Alessandro Ghedini VirtualSquare: * src/vde_vxlan/plug.h 2001,2002 Jeff Dike: * src/kvde_switch/consmgmt.h * src/kvde_switch/datasock.h * src/kvde_switch/kvde_switch.c * src/vde_switch/consmgmt.h * src/vde_switch/datasock.h * src/vde_switch/fstp.h * src/vde_switch/hash.c * src/vde_switch/hash.h * src/vde_switch/port.c * src/vde_switch/port.h * src/vde_switch/switch.h * src/vde_switch/tuntap.h * src/vde_switch/vde_switch.c * src/vde_tunctl.c * src/vde_tunctl.c 2004 Mattia Belletti: * src/kvde_switch/consmgmt.c * src/kvde_switch/datasock.c * src/kvde_switch/sockutils.c * src/kvde_switch/sockutils.h * src/vde_switch/consmgmt.c * src/vde_switch/datasock.c * src/vde_switch/sockutils.c * src/vde_switch/sockutils.h * src/vde_switch/tuntap.c * src/vde_switch/vde_switch.c 2007 Luca Bigliardi: * include/cmdparse.h * include/libvdemgmt.h * src/common/cmdparse.c * src/lib/libvdemgmt.c * src/lib/libvdesnmp.c * src/unixcmd.c * src/vde_pcapplug.c 2006-2011 Daniele Lacamera: * src/lib/python/VdePlug.py * src/lib/python/vdeplug_python.c * src/vde_cryptcab/crc32.c * src/vde_cryptcab/crc32.h * src/vde_cryptcab/cryptcab.c * src/vde_cryptcab/cryptcab.h * src/vde_cryptcab/vde_cryptcab_client.c * src/vde_cryptcab/vde_cryptcab_server.c * src/vde_l3/vde_buff.h * src/vde_l3/vde_l3.c * src/vde_router/vde_headers.h * src/vde_router/vde_router.c * src/vde_router/vde_router.h * src/vde_router/vder_arp.c * src/vde_router/vder_arp.h * src/vde_router/vder_datalink.c * src/vde_router/vder_datalink.h * src/vde_router/vder_icmp.c * src/vde_router/vder_icmp.h * src/vde_router/vder_olsr.c * src/vde_router/vder_packet.c * src/vde_router/vder_packet.h * src/vde_router/vder_queue.c * src/vde_router/vder_queue.h 2005 Ludovico Gargenghi: * src/common/canonicalize.c * src/common/poll.c 2005 Richard Kettlewell: * src/common/open_memstream.c 2007 Filippo Giunchedi: * include/libvdesnmp.h 2004-2008 Fabrice Bellard: * src/slirpvde/bootp.c * src/slirpvde/slirp.c 2004 Magnus Damm: * src/slirbvde/tftp.c 2007 Daniel Lacamera, 200 Florian Heinz, Julien Oster: * src/vde_over_ns/dns.c * src/vde_over_ns/dns.h * src/vde_over_ns/dns_proto.h * src/vde_over_ns/encode.c * src/vde_over_ns/fun.h * src/vde_over_ns/pstack.c * src/vde_over_ns/pstack.h * src/vde_over_ns/queue.c * src/vde_over_ns/util.c * src/vde_over_ns/vde_io.c * src/vde_over_ns/vde_over_ns.c 1999 Andrea Arcangeli: * src/vde_router/rbtree.c * src/vde_router/rbtree.h 2002 David Woodhouse: * src/vde_router/rbtree.c Allessandro Ghedini VirtualSquare: * src/vde_vxlan/log.c * src/vde_vxlan/log.h * src/vde_vxlan/plug.c * src/vde_vxlan/plug.h * src/vde_vxlan/vde_vxlan.c * src/vde_vxlan/vxlan.c * src/vde_vxlan/vxlan.h * src/vde_vxlan/vxlan_hash.c * src/vde_vxlan/vxlan_hash.h And finally a matter of personal taste: debian/copyright contains the following line: > Licenses for some components in src/slirpvde in addition to GPL-2: and then goes on to list the licenses that apply to some files in that directory. I think this fullfills the requirement of stating the license conditions for those files, but it doesn't really help me if I want to know *which* files these license conditions apply to. Stating the files each of these licenses applies to explicitly would make the statement more helpful, especially to ftp-masters doing future reviews of this package. Regards Sven -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (990, 'testing-debug'), (990, 'testing'), (102, 'unstable-debug'), (102, 'unstable'), (101, 'experimental-debug'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.6.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=de_DE.utf8 (c
Bug#950341: kubectx: kubernetes has been requested to be removed
Hi, On Fri, 31 Jan 2020 16:01:19 +0100 Andreas Beckmann wrote: > the kubernetes package has been requested to be removed (#950247), but > kubectx still build-depends on it. > > Please find a solution. Just adding my two cents, as I'm the one who originally reported the RM bug against kubernetes. I originally filed the RM bug, because I didn't see how the kubernetes package adds any value for users. In the worst case someone might use it and be surprised by the bugginess and old age of the package or even get hit by its abundant security issues. However, I have no particular technical problem with the package, so it would be fine by me if kubernetes stays in unstable just to satisfy the dependency for kubectx until a better solution is found. I just noticed that there are also RM bugs for dependencies of kubernetes (#902180) and apparently they actually do have a good reason to remove the package, so there actually seems to be a need to find a solution for this soon. Unfortunately, right now, I don't see a better solution than removing kubectx from unstable. Regards Sven signature.asc Description: OpenPGP digital signature
Bug#839840: ghci segfaults on armel, related to doctest failure
On Wed, 5 Oct 2016 17:12:45 + Clint Adams wrote: > Source: ghc > Version: 7.10.3-9 > Severity: serious > > clint@abel ~/haskell-http-api-data-0.2.4 > % ghci -isrc -XCPP -D"MIN_VERSION_base(X,Y,Z)=1" > GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help > Prelude> :l src/Web/HttpApiData.hs > [1 of 2] Compiling Web.HttpApiData.Internal ( > src/Web/HttpApiData/Internal.hs, interpreted ) > [2 of 2] Compiling Web.HttpApiData ( src/Web/HttpApiData.hs, interpreted ) > Ok, modules loaded: Web.HttpApiData, Web.HttpApiData.Internal. > *Web.HttpApiData> :set -XOverloadedStrings > *Web.HttpApiData> import Control.Applicative > *Web.HttpApiData Control.Applicative> import Data.Time > *Web.HttpApiData Control.Applicative Data.Time> import Data.Int > *Web.HttpApiData Control.Applicative Data.Time Data.Int> import Data.Text > (Text) > *Web.HttpApiData Control.Applicative Data.Time Data.Int Data.Text> import > Data.Time (Day) > *Web.HttpApiData Control.Applicative Data.Time Data.Int Data.Text Data.Time> > import Data.Version > *Web.HttpApiData Control.Applicative Data.Time Data.Int Data.Text Data.Time > Data.Version> toUrlPiece True > "true" > *Web.HttpApiData Control.Applicative Data.Time Data.Int Data.Text Data.Time > Data.Version> parseUrlPiece "false" :: Either Text Bool > zsh: segmentation fault ghci -isrc -XCPP -D"MIN_VERSION_base(X,Y,Z)=1" > > The backtrace is useless. This bug I reported upstream[1] might be related to that. Regards Sven [1]: https://ghc.haskell.org/trac/ghc/ticket/11831 pgpNHx3ISKto9.pgp Description: Digitale Signatur von OpenPGP
Bug#822472: various haskell -dev packages are missing Built-Using attributes
Am Mon, 4 Jul 2016 18:17:37 +0200 schrieb Matthias Klose : > On 04.07.2016 15:01, Sven Bartscher wrote: > > On Sun, 24 Apr 2016 22:13:47 +0200 Matthias Klose > > wrote: > >> [snip] > >> > >> [I was doing a transition (icu 55 to 57), and investigating some > >> build failures with link failures, some missing icu55 symbols. I > >> didn't find the appropriate haskell package immediately, because it > >> neither has a dependency on the icu runtime library or a > >> Built-Using attribute ] > >> > >> Seen with haskell-text-icu, but it looks like there are no > >> Built-Using attributes for any C library used for many packages. > >> Therefore filing this isssue on a package which is maintained by > >> the debian haskell maintainers. Feel free to clone, reassign, ... > > > > I'm afraid I don't understand what the problem is. > > I don't see why our packages would need Build-Using fields on any C > > libraries, because AFAIK all our packages that use C libraries are > > dynamically linked against them and have the appropriate Depends on > > them. > > I don't think so. For your library -dev packages you don't have any > such dependencies. Could you name an example? You mentioned libghc-text-icu-dev earlier, but it has dependencies on libc6, libicu55 and libicu-dev. I don't see anything missing here. > > Are you at DebConf? If so, maybe we could meet and you explain the > > problem to me. > > yes. You don't seem to be online on IRC, so finding you isn't trivial. Regards Sven pgpeWOPLozEQ8.pgp Description: Digitale Signatur von OpenPGP
Bug#822472: various haskell -dev packages are missing Built-Using attributes
On Sun, 24 Apr 2016 22:13:47 +0200 Matthias Klose wrote: > Package: haskell-devscripts > Version: 0.10.2.3 > Severity: serious > Tags: sid stretch > > [I was doing a transition (icu 55 to 57), and investigating some > build failures with link failures, some missing icu55 symbols. I > didn't find the appropriate haskell package immediately, because it > neither has a dependency on the icu runtime library or a Built-Using > attribute ] > > Seen with haskell-text-icu, but it looks like there are no > Built-Using attributes for any C library used for many packages. > Therefore filing this isssue on a package which is maintained by the > debian haskell maintainers. Feel free to clone, reassign, ... I'm afraid I don't understand what the problem is. I don't see why our packages would need Build-Using fields on any C libraries, because AFAIK all our packages that use C libraries are dynamically linked against them and have the appropriate Depends on them. Are you at DebConf? If so, maybe we could meet and you explain the problem to me. Regards Sven pgpRjZ_xS9ouH.pgp Description: Digitale Signatur von OpenPGP
Bug#813611: Passwords are stored as MD5
Package: simpleid Version: 0.8.1-14 Severity: grave Tags: security The identity files (in /var/lib/simpleid/identities) expect user passwords to be given as MD5 hashes of the actual passwords, but MD5 is generally considered broken and should probably not be used to store user passwords. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.3.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#810105: Bug#809763: cabal-helper: no binary in cabal-helper package
On Sun, 10 Jan 2016 20:37:13 +0100 Tomas Janousek wrote: > Hi, > > On Fri, Jan 08, 2016 at 03:19:49PM +0100, Sven Bartscher wrote: > > > It would be good if you open another report for ghc-mod, so it won't > > > migrate before its libexecdir is set to /usr/lib. > > Oh, I'm reading this only now, I forgot to scroll down the original e-mail, > sorry. :-( No problem. I noticed that it would be easier to clone the bug and did that instead. > > Searching through the code revealed, that the code for finding the > > executable is actually in haskell-cabal-helper. *reassign* > > If it's in libghc-cabal-helper-dev, then a rebuild of ghc-mod is necessary. > And I assume that's the case since newest cabal-helper with newest ghc-mod > gives the same error. ghc-mod has been rebuilt and for me the problem is gone. Are you sure you upgraded to ghc-mod 5.4.0.0-1+b1 (Note the +b1 addition)? Regards Sven pgpWZ0awLIc1y.pgp Description: Digitale Signatur von OpenPGP
Bug#810105: Bug#809763: cabal-helper: no binary in cabal-helper package
Control: reassign -1 haskell-cabal-helper On Mon, 4 Jan 2016 16:29:22 +0100 Sven Bartscher wrote: > On Sun, 3 Jan 2016 20:52:52 +0100 > Tomas Janousek wrote: > > Also, ghc-mod seems to expect cabal-helper in /usr/libexec: > > > > > $ ghc-mod list > > > ghc-mod: Could not find $libexecdir/cabal-helper-wrapper > > > > > > If you are a developer set the environment variable > > > `cabal_helper_libexecdir' to override $libexecdir[1]. The following will > > > work in the cabal-helper source tree: > > > > > > $ export cabal_helper_libexecdir=$PWD/dist/build/cabal-helper-wrapper > > > > > > [1]: /usr/libexec > > > > > > If you don't know what I'm talking about something went wrong with your > > > installation. Please report this problem here: > > > > > > https://github.com/DanielG/cabal-helper/issues > > > > Shall I open another bug or can you check that as well? > > It would be good if you open another report for ghc-mod, so it won't > migrate before its libexecdir is set to /usr/lib. Searching through the code revealed, that the code for finding the executable is actually in haskell-cabal-helper. *reassign* Regards Sven pgpyOlt8phNDU.pgp Description: Digitale Signatur von OpenPGP
Bug#809763: cabal-helper: no binary in cabal-helper package
Control: tag -1 + pending On Sun, 3 Jan 2016 20:52:52 +0100 Tomas Janousek wrote: > Package: cabal-helper > Version: 0.6.2.0-1 > Severity: grave > Justification: renders package unusable > > There's no cabal-helper binary in the package: > > > $ dpkg -L cabal-helper > > /. > > /usr > > /usr/share > > /usr/share/doc > > /usr/share/doc/cabal-helper > > /usr/share/doc/cabal-helper/changelog.Debian.gz > > /usr/share/doc/cabal-helper/buildinfo_i386.gz > > /usr/share/doc/cabal-helper/copyright > > Probably caused by the install file being called > debian/haskell-cabal-helper-utils.install but there being no mention of > "utils" anywhere in debian/control. Tank you for your report! Yes indeed, the file is missing. I think installing it to /usr/lib would be sensible, as Debian doesn't have /usr/libexec. > Also, ghc-mod seems to expect cabal-helper in /usr/libexec: > > > $ ghc-mod list > > ghc-mod: Could not find $libexecdir/cabal-helper-wrapper > > > > If you are a developer set the environment variable > > `cabal_helper_libexecdir' to override $libexecdir[1]. The following will > > work in the cabal-helper source tree: > > > > $ export cabal_helper_libexecdir=$PWD/dist/build/cabal-helper-wrapper > > > > [1]: /usr/libexec > > > > If you don't know what I'm talking about something went wrong with your > > installation. Please report this problem here: > > > > https://github.com/DanielG/cabal-helper/issues > > Shall I open another bug or can you check that as well? It would be good if you open another report for ghc-mod, so it won't migrate before its libexecdir is set to /usr/lib. Regards Sven pgpRtqrkYkSba.pgp Description: Digitale Signatur von OpenPGP
Bug#809088: ghc-mod: Unable to install ghc-mod
On Sun, 27 Dec 2015 15:37:43 +0100 Joachim Breitner wrote: > Hi, > > on ghc-mod: > > Am Sonntag, den 27.12.2015, 14:50 +0530 schrieb Vasudev Kamath: > > Checking at the tracker It looks like this package is having this > > problem for about ~6 months. > > Does this package actually have users? Or are the users very pardoning > and quiet? I use it, but I'm using testing for development, so I only get bugged by problems in ghc-mod if it affects testing. However, I didn't see ghc-mod having any problems in unstable before the GHC 7.10 upload. PS: In my last mail I messed up the recipients of my answer and sent a copy to the debian-haskell list and you answered to that one, so the bug tracker didn't get your answer. Regards Sven pgpmybNC_pBhE.pgp Description: Digitale Signatur von OpenPGP
Bug#803317: openmw-launcher: error while loading shared libraries: libboost_system.so.1.55.0
Package: openmw-launcher Version: 0.36.1-1+b2 Severity: grave Justification: renders package unusable omwlauncher doesn't start, but gives the following error message instead: omwlauncher: error while loading shared libraries: libboost_system.so.1.55.0: cannot open shared object file: No such file or directory It seems like it is linked against the wrong binary. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing'), (1, 'experimental'), (1, 'unstable') Architecture: i386 (i686) Kernel: Linux 4.2.0-1-686-pae (SMP w/2 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages openmw-launcher depends on: ii libboost-filesystem1.58.0 1.58.0+dfsg-3.1 ii libboost-program-options1.58.0 1.58.0+dfsg-3.1 ii libboost-system1.58.0 1.58.0+dfsg-3.1 ii libc6 2.19-22 ii libgcc1 1:5.2.1-22 ii libogre-1.9.0v5 1.9.0+dfsg1-6 ii libqtcore4 4:4.8.7+dfsg-3 ii libqtgui4 4:4.8.7+dfsg-3 ii libsdl2-2.0-0 2.0.2+dfsg1-7 ii libstdc++6 5.2.1-22 ii libunshield01.0-1 ii libxt6 1:1.1.4-1+b1 ii openmw 0.36.1-1+b2 openmw-launcher recommends no packages. openmw-launcher suggests no packages. -- no debconf information
Bug#778866: videotrans: movie-title terminates without doing anything
On Mon, 23 Feb 2015 17:04:11 + Alessio Treglia wrote: > severity 778866 grave > > On Mon, Feb 23, 2015 at 4:49 PM, Sven Bartscher > wrote: > > Control: severity -1 important > > > > This should set the severity, since you didn't prefix the commands with > > "Control:" > > I intended to CC: cont...@bugs.debian.org, I forgot it though but > ultimately I changed my mind about the severity: I do believe this is > RC. > > So I'm setting it back to grave. > > > log should be attached. I don't think the issue is bash related, since > > running it with bash doesn't solve the problem. > > Looks correct. Have you tried Sean's patch? [1] > If not, could you apply it and give the script another try please? I've tried with Sean's patch and it worked fine, until the error message described by Sean. Regards Sven pgpvBpIViLjrq.pgp Description: Digitale Signatur von OpenPGP
Bug#778866: videotrans: movie-title terminates without doing anything
Control: severity -1 important
This should set the severity, since you didn't prefix the commands with
"Control:"
On Mon, 23 Feb 2015 11:59:21 + Alessio Treglia
wrote:
> severity 778866 important
> thanks
>
> Hi,
>
> Thanks for reporting this issue and trying to make Debian better.
>
> On Fri, Feb 20, 2015 at 9:06 PM, Sven Bartscher
> wrote:
> > I converted to mp4 files with "movie-to-dvd movie1.mp4 movie2.mp4".
> > I made a background with "movie-make-title-simple -o title -m pal"
> > Then I tried to create the .vob with "movie-title -o title.vob -t title
> > movie1.m2v movie2.m2v", but that didn't have any effect.
> > "Not having any effect" means that there was no output or files generated or
> > anything else. Tje program just stops imediately without any message and the
> > exit code 1.
> > Doing some debugging I figured out that the script terminates at a read in
> > line
> > 279, but couldn't figure out why.
>
> Please run the script again via bash with the '-x' option added to the
> command line, e.g.:
>
>$ bash -x movie-title -o title.vob -t title movie1.m2v movie2.m2v
log should be attached. I don't think the issue is bash related, since
running it with bash doesn't solve the problem.
+ set -e
+ prefix=/usr
+ exec_prefix=/usr
+ datadir=/usr/share
+ bindir=/usr/bin
+ . /usr/share/videotrans/library.sh
++ dvdauthorescape_setting=
+ TEMP=/tmp/.movie-title.2723
+ trap 'rm -fr /tmp/.movie-title.2723* 2>/dev/null || :' EXIT
+ OUTPUT=
+ TITLE=
++ for i in '"$@"'
++ echoescape -o
+++ shellescape -o
+++ sed 's,[^-0-9a-zA-Z,./_],\\&,g'
+++ echo -n -o
++ echo -n '-o '
++ for i in '"$@"'
++ echoescape title.vob
+++ shellescape title.vob
+++ sed 's,[^-0-9a-zA-Z,./_],\\&,g'
+++ echo -n title.vob
++ echo -n 'title.vob '
++ for i in '"$@"'
++ echoescape -t
+++ shellescape -t
+++ echo -n -t
+++ sed 's,[^-0-9a-zA-Z,./_],\\&,g'
++ echo -n '-t '
++ for i in '"$@"'
++ echoescape title
+++ shellescape title
+++ echo -n title
+++ sed 's,[^-0-9a-zA-Z,./_],\\&,g'
++ echo -n 'title '
++ for i in '"$@"'
++ echoescape 'deutsche und polnische Handwerker.m2v'
+++ shellescape 'deutsche und polnische Handwerker.m2v'
+++ echo -n 'deutsche und polnische Handwerker.m2v'
+++ sed 's,[^-0-9a-zA-Z,./_],\\&,g'
++ echo -n 'deutsche\ und\ polnische\ Handwerker.m2v '
++ for i in '"$@"'
++ echoescape 'Dinner for one.m2v'
+++ shellescape 'Dinner for one.m2v'
+++ echo -n 'Dinner for one.m2v'
+++ sed 's,[^-0-9a-zA-Z,./_],\\&,g'
++ echo -n 'Dinner\ for\ one.m2v '
+ original_command_line='-o title.vob -t title deutsche\ und\ polnische\ Handwerker.m2v Dinner\ for\ one.m2v '
+ clean=
+ tile_x=
+ START=0
+ chapter_interval=2
+ getopts o:t:T:s:Cc: option
+ case "${option}" in
+ OUTPUT=title.vob
+ getopts o:t:T:s:Cc: option
+ case "${option}" in
+ TITLE=title
+ getopts o:t:T:s:Cc: option
+ '[' title.vob = '' ']'
+ '[' title = '' ']'
+ check_filenames title.vob title
+ local check_input
+ for check_input in '"$@"'
+ '[' title.vob '!=' title.vob ']'
++ echo -n title.vob
++ tr -d '[ -~]'
+ should_be_empty=
+ '[' '' '!=' '' ']'
++ echo -n title.vob
++ tr -dc ':,\\'
+ should_be_empty=
+ '[' '' '!=' '' ']'
+ for check_input in '"$@"'
+ '[' title '!=' title ']'
++ echo -n title
++ tr -d '[ -~]'
+ should_be_empty=
+ '[' '' '!=' '' ']'
++ echo -n title
++ tr -dc ':,\\'
+ should_be_empty=
+ '[' '' '!=' '' ']'
+ return 0
+ '[' -e title.vob -a '!' -f title.vob ']'
++ expr 5 - 1
+ shift 4
+ num_sources=2
+ '[' 2 -gt 0 ']'
+ check_filenames 'deutsche und polnische Handwerker.m2v' 'Dinner for one.m2v'
+ local check_input
+ for check_input in '"$@"'
+ '[' 'deutsche und polnische Handwerker.m2v' '!=' 'deutsche und polnische Handwerker.m2v' ']'
++ echo -n 'deutsche und polnische Handwerker.m2v'
++ tr -d '[ -~]'
+ should_be_empty=
+ '[' '' '!=' '' ']'
++ echo -n 'deutsche und polnische Handwerker.m2v'
++ tr -dc ':,\\'
+ should_be_empty=
+ '[' '' '!=' '' ']'
+ for check_input in '"$@"'
+ '[' 'Dinner for one.m2v' '!=' 'Dinner for one.m2v' ']'
++ echo -n 'Dinner for one.m2v'
++ tr -d '[ -~]'
+ should_be_empty=
+ '[' '' '!=' '' ']'
++ echo -n 'Dinner for one.m2v'
++ tr -dc ':,\\'
+ should_be_empty=
+ '[' '' '!=' '' ']'
+ return 0
+ '[' '' = yes ']'
++ cd -- title
++ echo static.jpg
+ title_frames=static.jpg
++ tr -d ' '
++ wc -w
++ echo static.jpg
+ num_title_frames=1
+ '[' 1 -lt 2 ']'
++ cd -- title
++ echo '*.png'
+ title_frames='*.png'
++ tr -d ' '
++ wc -w
++ echo '*.png'
+ num_title_frames=1
+ '[' 1 -lt 2 ']'
+ '[' -f title/static.jpg ']'
+ title_frames=static.jpg
+ num_title_frames=1
+ identify -format '%w %h' title/static.jpg
+ read xx yy
+ rm -fr /tmp/.movie-title.2723
pgpw9HEA1mTSA.pgp
Description: Digitale Signatur von OpenPGP
Bug#778866: read in movie-title failing
Greetings,
I've tried to figure out why the read terminates the whole script.
Disabling the set -e makes the script run almost fine. So it seems,
that read has a non-zero exit status. Ignoring the error with
'read xx yy < "${TEMP}"' made the script run fine (without disabling
set -e).
"run fine" isn't exactly true. It failed later for an unrelated reason.
Regards
Sven
pgplF7EwGCIG9.pgp
Description: Digitale Signatur von OpenPGP
Bug#778866: videotrans: movie-title terminates without doing anything
Package: videotrans Version: 1.6.1-2 Severity: grave Justification: renders package unusable I converted to mp4 files with "movie-to-dvd movie1.mp4 movie2.mp4". I made a background with "movie-make-title-simple -o title -m pal" Then I tried to create the .vob with "movie-title -o title.vob -t title movie1.m2v movie2.m2v", but that didn't have any effect. "Not having any effect" means that there was no output or files generated or anything else. Tje program just stops imediately without any message and the exit code 1. Doing some debugging I figured out that the script terminates at a read in line 279, but couldn't figure out why. -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (990, 'testing'), (1, 'experimental'), (1, 'unstable') Architecture: i386 (i686) Kernel: Linux 3.16.0-4-686-pae (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages videotrans depends on: ii dvdauthor 0.7.0-1.3 ii imagemagick 8:6.8.9.9-5 ii libav-tools 6:11.2-1 ii libc6 2.19-13 ii mjpegtools 1:2.1.0+debian-3 ii mplayer2 [mplayer] 2.0-728-g2c378c7-4+b1 videotrans recommends no packages. videotrans suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#774802: Incompatibility between Setup.hs and cabal-install when using hgettext
Source: haskell-hgettext Version: 0.1.30-2 Severity: grave When trying to build a package, that uses function from hgettext in its Setup.hs, with cabal-install and libghc-cabal-dev is installed, the build fails with a bunch of messages about not matching command line options. This happens, because the function from hgettext are compiled against the ghc version of the cabal library, but when compiling the Setup.hs it's compiled against the newer libghc-cabal-dev version. This results in a compiled binary that doesn't seem to be able to parse its command line options. This can be fixed by ensuring that hgettext is built against libghc-cabal-dev, since that ensures that libghc-cabal-dev is installed when compiling the Setup.hs of other packages. -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#752941: Not reproducible
Greetings, Can you reproduce this with 4.2.33-1? At least I can't. Maybe this was fixed in the new version. I think if you can't reproduce this, we can just close this bug. Regards Sven signature.asc Description: PGP signature
Bug#752807: Not reproducible anymore
Control: severity -1 minor Control: tag -1 + unreproducible I noticed that I can now install both packages again. Reinstalling libopenal1 fixed the problem. But it's a fact that llibopenal1 and libopenal-dev contain the same symlink? Is this intended? Should the symlink be removed from libopenal-dev? Regards Sven signature.asc Description: PGP signature
