Bug#1016506: marked as pending in haskell-devscripts
Control: tag -1 pending Hello, Bug #1016506 in haskell-devscripts reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/haskell-team/haskell-devscripts/-/commit/364466d4b97a2c7d565749cea9f607e73ce6 Only install extra-packages file for -dev package. closes: #1016506 (this message was generated automatically) -- Greetings https://bugs.debian.org/1016506
Bug#995393: fakeroot: FTBFS on ppc64el
On Thu, Sep 30, 2021 at 04:46:47PM +0200, Frédéric Bonnard wrote: > Not sure what optimization breaks, I just tried changing openat() to > modify some aggressive optimization on that function and it helped. The optimization seems to break with -O1, but not with -O0 -fcombine-stack-adjustments -fcompare-elim -fcprop-registers -fdefer-pop -fforward-propagate -fguess-branch-probability -fipa-profile -fipa-pure-const -fipa-reference -fipa-reference-addressable -fmerge-constants -fomit-frame-pointer -freorder-blocks -fshrink-wrap -fsplit-wide-types -ftree-builtin-call-dce -ftree-ccp -ftree-ch -ftree-coalesce-vars -ftree-copy-prop -ftree-dce -ftree-dominator-opts -ftree-fre -ftree-sink -ftree-slsr -ftree-ter -fbranch-count-reg -fdelayed-branch -fdse -fif-conversion -fif-conversion2 -finline-functions-called-once -fmove-loop-invariants -fssa-phiopt -fipa-modref -ftree-bit-ccp -ftree-dse -ftree-pta -ftree-sra It also seems fine at -O2 if fprintf(stderr, "%i, %s, %x\n", dir_fd, pathname, flags); is called prior to next_openat.
Bug#997799: feynmf: Use disappeared /bin/tempfile in debian patch
On Sun, Oct 24, 2021 at 03:09:46PM -0400, Boyuan Yang wrote: > I just realized the ongoing discussion at https://bugs.debian.org/994275 , > which may mitigate the impact of this bug report. Now I believe depending on > either tempfile(1) or mktemp(1) should be ok. I would recommend switching to mktemp(1) regardless. There is no possible final outcome wherein any version of tempfile(1) would be a better choice.
Bug#993665: debianutils: tempfile still required in printer-driver-pnm2ppa
On Wed, Sep 08, 2021 at 02:40:50PM +0200, Bill Allombert wrote: > It will also break any local shell scripts the user systems might depend > on that happens to use tempfile, for little or no benefit to the users. They get the benefit of needing to switch to an alternative that is supported upstream and present on more operaitng systems.
Bug#992411: not fixed
On Sat, Aug 21, 2021 at 03:43:12AM +0800, 積丹尼 Dan Jacobson wrote: > All I know is the bug was to make > /usr/bin/which keep working. > > All I see that was 'fixed' was making a news item. > > There are hundreds of cgi etc. scripts that are now emitting errors. /usr/bin/which is working. It's emitting a warning, not an error. Why are CGI scripts emitting errors?
Bug#992410: move of /bin/run-parts to /usr/bin breaks network with ifup
On Thu, Aug 19, 2021 at 08:27:03AM +0200, Felix Zielcke wrote: > I can confirm that the NMU of ifupdown fixes the problem. > So you can add now a Breks: and close #992410 Perfect, thanks.
Bug#992399: debianutils: removes interface from essential package without proper transition
On Wed, Aug 18, 2021 at 11:22:53AM -0400, Michael Stone wrote: > apologies, box I checked was buster and not bullseye No problem, it seems evident that it did little good anyway.
Bug#992410: move of /bin/run-parts to /usr/bin breaks network with ifup
On Wed, Aug 18, 2021 at 10:33:17AM +0200, fziel...@z-51.de wrote: > After todays updates and a reboot my network didn't come up anymore. > Problem is the move of /bin/run-parts to /usr/bin: > > systemd[1]: Starting Raise network interfaces... > ifup[1663]: /bin/sh: 1: /bin/run-parts: not found > ifup[1661]: ifup: pre-up script failed > systemd[1]: networking.service: Main process exited, code=exited, > status=1/FAILURE > systemd[1]: networking.service: Failed with result 'exit-code'. > systemd[1]: Failed to start Raise network interfaces. Also see #992425
Bug#992399: debianutils: removes interface from essential package without proper transition
On Wed, Aug 18, 2021 at 10:53:45AM -0400, Michael Stone wrote: > Adding a message to stderr telling people to use mktemp may be a reasonable > step. You mean the thing it does in our stable release?
Bug#992396: debianutils: tempfile binary is gone, breaks Xsession
On Wed, Aug 18, 2021 at 03:57:01PM +0900, Norbert Preining wrote: > /etc/X11/XSession relies on tempfile, which is not available anymore, > thus logging into an X session is broken. In our stable release, tempfile outputs this to stderr: WARNING: tempfile is deprecated; consider using mktemp instead. Apparently no one has cared.
Bug#964621: fakeroot: statx function not wrapped, causing FTBFS
On Mon, Sep 21, 2020 at 12:48:25PM +0200, jhcha54008 wrote: > should this bug be merged with #940056 and #968868 ? If statx is the only reason for the failures.
Bug#968157: src:haskell-cborg: testsuite fails due to bus errors on armhf
Package: src:haskell-cborg Version: 0.2.3.0-1 Severity: serious Unlike some other armhf bus errors, this problem does not go away when compiler optimization is disabled.
Bug#967991: glirc, build-depends on package which is not in testing
On Thu, Aug 06, 2020 at 11:20:00AM +0100, peter green wrote: > glirc can no longer be built in testing because haskell-regex-tdfa is no > longer > present in testing. Ilias Tsitsimpis has filed a bug report against the > package > saying he intends to remove it and asked the release team to remove it from > testing ( https://lists.debian.org/debian-haskell/2020/08/msg2.html ) . > which the release team did. That list appears to have haskell-regex-tdfa-text, not haskell-regex-tdfa?
Bug#965064: pkg-haskell-tools: FTBFS in unstable
On Wed, Jul 15, 2020 at 03:09:24PM +0100, Iain Lane wrote: > Upgrading shake will fix this, or it can be worked around in the In theory we can upgrade shake once js-dgtable clears NEW. It's been sitting there for 3 months.
Bug#962973: haskell-readline: Removal notice: broken and unmaintained
On Tue, Jun 16, 2020 at 09:10:32PM -0700, Sean Whitton wrote: > keysafe, in experimental, depends on haskell-readline. > > CCing upstream: Joey, do you think it would be possible for keysafe to > migrate to use something maintained? Some options suggested at https://github.com/haskell-infra/hackage-trustees/issues/268#issuecomment-645354720
Bug#945729: zomg: Python2 removal in sid/bullseye
On Wed, Apr 15, 2020 at 06:29:18AM -0400, Jeremy Bicha wrote: > python3-mutagen now contains mutagen-inspect. Wonderful.
Bug#954443: jp: name conflict of /usr/bin/jp with sat-xmpp-jp
> jp includes /usr/bin/jp, which is already "taken" since ~2013 by > something completely different, sat-xmpp-jp. Given that jp has > not yet been part of Debian release, it is probably easy to just > rename the binary, e.g. jp-cli, jp-jmespath, or jmespath. Thanks! If we do that, are we expecting users to create a jp symlink so that jp-dependent scripts can be used unchanged?
Bug#955295: photofilmstrip: incompatible with python 3.8?
Package: photofilmstrip Version: 3.7.2-2 Severity: serious % photofilmstrip Traceback (most recent call last): File "/usr/bin/photofilmstrip", line 8, in main() File "/usr/lib/python3/dist-packages/photofilmstrip/GUI.py", line 46, in main guiApp.Start() File "/usr/lib/python3/dist-packages/photofilmstrip/AppMixin.py", line 41, in Start self.InitI18N() File "/usr/lib/python3/dist-packages/photofilmstrip/AppMixin.py", line 31, in InitI18N ActionI18N().Execute() File "/usr/lib/python3/dist-packages/photofilmstrip/action/ActionI18N.py", line 43, in Execute lang.install(True) File "/usr/lib/python3.8/gettext.py", line 352, in install for name in allowed & set(names): TypeError: 'bool' object is not iterable % photofilmstrip-cli Traceback (most recent call last): File "/usr/bin/photofilmstrip-cli", line 8, in main() File "/usr/lib/python3/dist-packages/photofilmstrip/CLI.py", line 44, in main exitCode = cliApp.Start() File "/usr/lib/python3/dist-packages/photofilmstrip/AppMixin.py", line 41, in Start self.InitI18N() File "/usr/lib/python3/dist-packages/photofilmstrip/AppMixin.py", line 31, in InitI18N ActionI18N().Execute() File "/usr/lib/python3/dist-packages/photofilmstrip/action/ActionI18N.py", line 43, in Execute lang.install(True) File "/usr/lib/python3.8/gettext.py", line 352, in install for name in allowed & set(names): TypeError: 'bool' object is not iterable
Bug#896971: ghc-mod
It appears as though ghc-mod has been deprecated in favor of haskell-ide-engine.
Bug#913053: src:haskell-cabal-helper: ftbfs
Package: src:haskell-cabal-helper Version: 0.8.0.2-1 Severity: serious Someone will need to package cabal-plan to update to a modern version.
Bug#913019: src:haskell-text: now a ghc bootlib
Package: src:haskell-text Version: 1.2.3.0-1 Severity: serious 1.2.3.0 is bundled with ghc and should not be released separately in buster
Bug#912924: classy-prelude-yesod: not worth maintenance burden?
On Mon, Nov 05, 2018 at 10:04:52AM +0100, Mattia Rizzolo wrote: > you typoed the package name here… reassigning. Thanks
Bug#912924: classy-prelude-yesod: not worth maintenance burden?
Package: classy-prelude-yesod Version: 1.4.0-1 Severity: serious classy-prelude-yesod is not currently needed and may not be worth the maintenance burden. Please close this bug if you disagree.
Bug#911571: src:haskell-hastache: deprecated and broken
Package: src:haskell-hastache Version: 0.6.1-8 Severity: serious Replacements for hastache are mustache and microstache
Bug#911570: src:haskell-cabal-file-th: needs to be patched for newer Cabal
Package: src:haskell-cabal-file-th Version: 0.2.4-3 Severity: serious Source needs to be updated for Cabal API changes, if worth the maintenance burden.
Bug#911569: src:haskell-hit: dead upstream, not worth the maintenance burden?
Package: src:haskell-hit Version: 0.6.3-8 Severity: serious If hit is worth keeping, here is a patch: https://github.com/vincenthz/hit/pull/37
Bug#911535: src:haskell-parsec: now a ghc bootlib
Package: src:haskell-parsec Version: 3.1.13.0-1 Severity: serious parsec 3.1.13.0 is now bundled with ghc and this version should not be shipped separately in buster.
Bug#911354: src:haskell-stm: now a ghc bootlib
Package: src:haskell-stm Version: 2.4.5.0-1 Severity: serious 2.4.5.0 is bundled with ghc; this version should not be shipped in buster.
Bug#911353: src:haskell-mtl: now a ghc bootlib
Package: src:haskell-mtl Version: 2.2.2-1 Severity: serious 2.2.2 is bundled with ghc and should not be released separately in buster
Bug#911024: src:haskell-monadplus: unmaintained
On Sun, Oct 14, 2018 at 05:01:16PM -0700, Sean Whitton wrote: > Just to note in the bug that the reason haskell-monadplus was packaged > was for agda, which still build-depends on it. So if we don't think > monadplus is worth the maintenance burden, neither is agda; we should > get rid of that too. (I don't have an opinion on this as I am not > maintaining either.) agda 2.5.4.1 no longer build-depends on it so this particular problem will be resolved whenever there are binary builds of agda/unstable.
Bug#911024: src:haskell-monadplus: unmaintained
Package: src:haskell-monadplus Version: 1.4.2-5 Severity: serious monadplus is probably not worth the maintenance burden. Please close this bug if you disagree.
Bug#910532: src:haskell-enumerator: unlikely to be worth the maintenance burden
Package: src:haskell-enumerator Version: 0.4.20-7 Severity: serious If there is a good reason to keep this package, please close the bug.
Bug#882108: xmonad is almost entirely nonfunctional
On Sat, Nov 18, 2017 at 09:19:24PM -0500, Alexis Hunt wrote: > I have been using xmonad for a long while, and today upgraded to Buster. While > xmonad worked at first, after making a change to my configuration file, it > stopped working: > > 1. I can't run xmonad --recompile; it just says "Use Stack!" > 2. Previously, I put xmonad in my .xsession and started it like that. Trying > to >do so causes it to fail, again saying "Use Stack!" in .xsession-errors, and >kicks me back to the login screen. > 3. Switching to select Xmonad in LightDM's WM list lets me log in properly, > but >then xmonad crashes after executing the startup scripts. > 4. Trying to manually recover it with --replace also says "Use Stack!" > 5. Removing my .xmonad directory lets me log in and xmonad does not crash, but >none of the keybinds work so I cannot open programs, dmenu, etc. > > It is, as a result, completely unusable. Is there any chance you have an ~/.xmonad/build script?
Bug#902827: FTBFS: GHC OOM on armel/armhf
Source: agda Version: 2.5.2-2 Severity: serious ghc: out of memory (requested 2097152 bytes)
Bug#902367: monkeysphere: test/keytrans depends on older GnuPG format
Package: monkeysphere Version: 0.41-1 Severity: serious test/keytrans contains some "golden" output that matches an older version of GnuPG. When running the testsuite with "current" GnuPG, it fails due to the presence of extra fields in the --with-colons output.
Bug#899060: FTBFS: even if tests pass, dh_auto_test fails
On Fri, May 18, 2018 at 08:40:56PM +0200, Adam Borowski wrote: > ## > Monkeysphere basic tests completed successfully! > ## > ### removing temp dir... > make[1]: Leaving directory '/<>' > dh_auto_test: make -j2 -Oline test returned exit code 2 Does it happen without -j2?
Bug#902318: monkeysphere: testsuite ssh config contains invalid option
Package: monkeysphere Version: 0.41-1 Severity: serious Tags: patch RSAAuthentication has been removed from OpenSSH, and therefore using it tests/home/testuser/.ssh/config contributes to testsuite failure >From 91ffa734a9d3ce695c85b24d0f418ce3939ed592 Mon Sep 17 00:00:00 2001 From: Clint Adams Date: Sun, 24 Jun 2018 19:02:07 -0400 Subject: [PATCH] Remove RSAAuthentication from test ssh config --- tests/home/testuser/.ssh/config | 1 - 1 file changed, 1 deletion(-) diff --git a/tests/home/testuser/.ssh/config b/tests/home/testuser/.ssh/config index ab1efa6..8c1e9bb 100644 --- a/tests/home/testuser/.ssh/config +++ b/tests/home/testuser/.ssh/config @@ -3,7 +3,6 @@ Host * ChallengeResponseAuthentication no PasswordAuthentication no KbdInteractiveAuthentication no -RSAAuthentication no GSSAPIAuthentication no StrictHostKeyChecking yes LogLevel DEBUG -- 2.18.0
Bug#902279: youtube-dl: FTBFS in buster/sid (No module named 'setuptools')
On Sun, Jun 24, 2018 at 01:59:02PM +0200, Santiago Vila wrote: > File "setup.py", line 11, in > from setuptools import setup, Command > ModuleNotFoundError: No module named 'setuptools' Attached fix uploaded to DELAYED/3-day as part of today's BSP. diff --git a/debian/changelog b/debian/changelog index a43539f..6db3181 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +youtube-dl (2018.06.18-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Add missing python3-setuptools build dependency. closes: #902279. + + -- Clint Adams Sun, 24 Jun 2018 16:54:30 -0400 + youtube-dl (2018.06.18-1) unstable; urgency=medium * New upstream version 2018.06.18 (Closes: #900642) diff --git a/debian/control b/debian/control index 037371e..9bd52ab 100644 --- a/debian/control +++ b/debian/control @@ -9,6 +9,7 @@ Build-Depends: dh-python, pandoc, python3-pkg-resources, + python3-setuptools, zip Build-Depends-Indep: python3
Bug#901327: tigervnc: FTBFS: Hunk #1 FAILED
On Mon, Jun 11, 2018 at 05:21:00PM +0300, Niko Tyni wrote:
> touch debian/stamp-patched
> /usr/bin/make -f debian/rules update-config
> make[1]: Entering directory '/<>/tigervnc-1.7.0+dfsg'
> make[1]: 'update-config' is up to date.
> make[1]: Leaving directory '/<>/tigervnc-1.7.0+dfsg'
> cd ./unix/xserver && \
> { tar --strip-components 1 -xvJf /usr/src/xorg-server.tar.xz | \
> sed -e 's@^[^/]*/@@' > .apply-patches-unify-xorg-and-vnc-tree.files;
> } && \
> touch .apply-patches-unify-xorg-and-vnc-tree.stamp
> cd ./unix/xserver && { \
> patch --no-backup-if-mismatch -p1 <
> /<>/tigervnc-1.7.0+dfsg/debian/xserver119.patch && \
> touch .apply-patches-vnc-patch-xorg.stamp; \
> }
> patching file configure.ac
> Hunk #2 succeeded at 1778 (offset -86 lines).
> Hunk #3 succeeded at 1817 (offset -86 lines).
> Hunk #4 succeeded at 2036 (offset -87 lines).
> Hunk #5 succeeded at 2571 (offset -126 lines).
> patching file hw/Makefile.am
> patching file mi/miinitext.c
> Hunk #1 FAILED at 114.
> Hunk #2 succeeded at 109 (offset -129 lines).
> 1 out of 2 hunks FAILED -- saving rejects to file mi/miinitext.c.rej
> patching file include/os.h
> Hunk #1 succeeded at 633 (offset 12 lines).
> make: *** [debian/rules:129:
> unix/xserver/.apply-patches-vnc-patch-xorg.stamp] Error 1
Why is patchsys-quilt.mk being used with a 3.0 (quilt) source package?
Bug#900302: FTBFS: bitrot
Source: gitit Version: 0.12.2.1-1 Severity: serious gitit needs patching for newer dependencies (feed in particular)
Bug#899392: darcs: FTBFS: unsatisfied build-deps: - libghc-graphviz-dev:amd64 (< 2999.19)
Please update darcs to build with graphviz 2999.20.0.0. On Wed, May 23, 2018 at 07:08:14PM +0200, Emilio Pozuelo Monfort wrote: > darcs can't be built anymore on sid: > > darcs build-depends on missing: > - libghc-graphviz-dev:amd64 (< 2999.19)
Bug#899208: pandoc: FTBFS on armel/armhf: Identifier `InvalidYaml' used as a constructor-like thing
On Sun, May 20, 2018 at 09:20:44PM -0700, John MacFarlane wrote: > This is puzzling. We build regularly with ghc 8.2.2 on CI, > and must have built with that version of yaml. This must be > some armel/armhf specific issue that is beyond my ability > to diagnose. It's certainly strange.
Bug#899208: pandoc: FTBFS on armel/armhf: Identifier `InvalidYaml' used as a constructor-like thing
On Sun, May 20, 2018 at 04:38:36PM -0700, John MacFarlane wrote:
> I don't understand this error. InvalidYaml *is* a constructor for the
> type ParseException in Data.Yaml (yaml package). So it's not clear why
> the compiler would complain about it being used as a "constructor-like
> thing."
on armel:
GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help
Prelude> :m Data.Yaml
Prelude Data.Yaml> :i ParseException
data ParseException
= NonScalarKey
| UnknownAlias {_anchorName :: Text.Libyaml.AnchorName}
| UnexpectedEvent {_received :: Maybe Text.Libyaml.Event,
_expected :: Maybe Text.Libyaml.Event}
| InvalidYaml (Maybe YamlException)
| AesonException String
| OtherParseException GHC.Exception.SomeException
| NonStringKeyAlias Text.Libyaml.AnchorName Value
| CyclicIncludes
-- Defined in `yaml-0.8.29:Data.Yaml.Internal'
instance Show ParseException
-- Defined in `yaml-0.8.29:Data.Yaml.Internal'
> What version of ghc is being used to compile?
8.2.2
> What version of the Haskell yaml package is being used?
0.8.29
Bug#899166: haskell-cryptohash-sha256: FTBFS: infinite loop on mips/el with ghc 8.2
Control: forwarded 899166 https://github.com/haskell-hvr/cryptohash-sha256/issues/3 hvr would like access to a mips box so he can play with FFI things. On Sun, May 20, 2018 at 11:03:04AM +0200, Emilio Pozuelo Monfort wrote: > haskell-cryptohash-sha256 gets into an infinite loop during the build against > GHC 8.2, endlessly printing: > > test-sha256: lost signal due to full pipe: 10
Bug#897172: FTBFS: pandoc 2.2
Source: haskell-blogliterately Version: 0.8.4.3-2 Severity: serious Forwarded: https://github.com/byorgey/BlogLiterately/issues/39 Jonas is about to upload pandoc 2.2
Bug#897041: FTBFS: mismatch with heist
Source: haskell-snap Version: 1.0.0.2-2 Severity: serious Unfortunately, heist got ahead, so one solution is to patch snap for newer heist.
Bug#897001: libghc-cmark-gfm-dev: not big-endian-safe
Package: libghc-cmark-gfm-dev Version: 0.1.3-1 Severity: serious Forwarded: https://github.com/kivikakk/cmark-gfm-hs/issues/6 FTBFS on big-endian arches
Bug#896973: libghc-intern-doc: needs sourceful upload to rebuild doc package against newer ghc haddock interface
Package: libghc-intern-doc Version: 0.9.1.4-3 Severity: serious .
Bug#896974: libghc-swish-doc: needs sourceful upload to rebuild doc package against newer ghc haddock interface
Package: libghc-swish-doc Version: 0.9.1.10-1 Severity: serious .
Bug#896972: curry-base: needs sourceful upload to rebuild doc package against newer ghc haddock interface
Package: curry-base Version: 1.0.0-1 Severity: serious This is also true of curry-frontend.
Bug#896971: FTBFS: needs patching for GHC 8.2
Source: ghc-mod Version: 5.8.0.0-1 Severity: serious Forwarded: https://github.com/DanielG/ghc-mod/issues/900 .
Bug#896505: FTBFS: needs to be patched for newer feed API
Package: rss2irc Version: 1.1-3 Severity: serious Types have changed
Bug#895965: FTBFS: needs to be patched for newer persistent
Source: haskell-esqueleto Version: 2.5.3-2 Severity: serious Forwarded: https://github.com/bitemyapp/esqueleto/issues/80 .
Bug#895952: FTBFS: incompatible with terminal-progress-bar 0.2
Source: haskell-bytestring-progress Version: 1.0.9-1 Severity: serious Forwarded: https://github.com/acw/bytestring-progress/issues/9 .
Bug#895876: FTBFS: needs update for newer src-exts
Source: haskell-derive Version: 2.6.3-2 Severity: serious Forwarded: https://github.com/ndmitchell/derive/issues/33 .
Bug#895828: haskell-vector-space-points: cannot be built in sid
Source: haskell-vector-space-points Version: 0.2.1.2-3 Severity: serious vector-space-points must either be patched or removed
Bug#895612: haskell-protobuf: FTBFS: testCase import ambiguity
Package: haskell-protobuf Version: 0.2.1.1-3 Severity: serious https://github.com/alphaHeavy/protobuf/issues/35
Bug#895609: haskell-language-python: incompatible with Prelude changes in ghc 8.2
Source: haskell-language-python Version: 0.5.4-5 Severity: serious https://github.com/bjpop/language-python/issues/39
Bug#895576: haskell-uulib: FTBFS with GHC 8.2
Source: haskell-uulib Version: 0.9.20-5 Severity: serious Doesn't build with GHC 8.2.
Bug#895552: haskell-token-bucket: needs patching for newer base and time
Source: haskell-token-bucket Version: 0.1.0.1-5 Severity: serious .
Bug#895551: haskell-gloss-rendering: upper bound on base older than ghc 8.2's
Source: haskell-gloss-rendering Version: 1.11.1.1-2 Severity: serious https://github.com/Teaspot-Studio/gloss-rendering/issues/1
Bug#889829: ghc: error while loading shared libraries: libHShaskeline-0.7.3.0-ghc8.0.2.so
On Thu, Feb 08, 2018 at 06:12:31AM +0100, Petter Reinholdtsen wrote: > 15427: file=libHSterminfo-0.4.0.2-ghc8.0.2.so [0]; needed by > /usr/lib/ghc/bin/ghc-pkg [0] objdump -p /usr/lib/ghc/bin/ghc-pkg | grep RUNPATH
Bug#884173: Extensions are just part of it
On Fri, Jan 26, 2018 at 11:56:41AM -0300, Matías Bellone wrote: > After a month of testing, I couldn't isolate the issue to one particular > extension either. I tried uninstalling all my extensions one by one. I even > tried creating a new profile, but the issue still happens no matter what. > Granted, I did sync up the new profile with my google account - which > pulled my extensions. In my case it seems to be Chrome Media Router
Bug#865975: docker.io breaks (bridged) network for VMs
On Sun, Oct 22, 2017 at 02:00:58AM +0200, Alban Browaeys wrote:
> or a config item in /etc/docker/daemon.json:
> {
> "iptables": false
> }
Seems like the docker.io package should ship this as a conffile then.
Bug#885793: #885793: tldr-py,tldr: File collision when installing together: /usr/bin/tldr (and maybe further files)
On Wed, Jan 03, 2018 at 04:48:12PM +0100, Ondrej Novy wrote: > I prefer to use update-alternatives. > > What do you think Clint? I haven't looked at the different implementations but alternatives sounds like the right answer to me.
Bug#884173: Bug#882801: chromium: segfaults like crazy
On Sat, Dec 09, 2017 at 05:52:16PM +0100, Pascal Obry wrote: > Does it runs if started with --disable-extensions ? Yes, it appears so.
Bug#876240: libghc-xmonad-contrib-dev: unmet dependency libghc-x11-xft-dev-0.3.1-c557c
On Wed, Sep 20, 2017 at 12:16:13AM +0200, Sacha Delanoue wrote: > I tried to install libghc-xmonad-contrib-dev by doing > `apt install libghc-xmonad-contrib-dev` on an up-to-date 9.1 Debian. > The install failed with the following information: > > The following packages have unmet dependencies: > libghc-xmonad-contrib-dev : Depends: libghc-x11-xft-dev-0.3.1-c557c > E: Unable to correct problems, you have held broken packages. > > I am no expert in Debian, but a search on the Internet lead me to this: > https://unix.stackexchange.com/a/392888 stating that this kind of errors > in expected in Sid. But since I am using stable I reported it. Please reply with the output of dpkg -s libghc-x11-xft-dev | grep -e '^Status' -e '^Version' -e '^Provides'
Bug#860739: libghc-xcb-types-dev: cannot parse xcb-proto 1.12
On Sun, Apr 23, 2017 at 01:22:33PM +0100, James Cowgill wrote: > It looks like the xcffib dependency from cairocffi is optional, so this > would be a much easier solution. Otherwise we have to backport tons of > stuff or use upstream 0.5.1. So does this mean this is no longer a bug?
Bug#867470: haskell-chell-quickcheck2 FTBFS: Not in scope: `QuickCheck.exhaustive'
John, chell-quickcheck needs patching for QuickCheck 2.9 On Thu, Jul 06, 2017 at 09:01:23PM +0300, Adrian Bunk wrote: > Source: haskell-chell-quickcheck2 > Version: 0.2.5-7 > Severity: serious > > https://buildd.debian.org/status/package.php?p=haskell-chell-quickcheck2=sid > > ... > Preprocessing library chell-quickcheck-0.2.5... > [1 of 1] Compiling Test.Chell.QuickCheck ( lib/Test/Chell/QuickCheck.hs, > dist-ghc/build/Test/Chell/QuickCheck.o ) > > lib/Test/Chell/QuickCheck.hs:104:31: error: > Not in scope: `QuickCheck.exhaustive' > Module `Test.QuickCheck' does not export `exhaustive'. > /usr/share/cdbs/1/class/hlibrary.mk:147: recipe for target 'build-ghc-stamp' > failed > make: *** [build-ghc-stamp] Error 1
Bug#865711: haskell-yaml: FTBFS everywhere (except all)
On Sat, Jun 24, 2017 at 03:34:35AM +0100, James Clarke wrote: > Hi, > haskell-yaml FTBFS on every architecture (except all) due to testsuite > failures: > > > Failures: > > > > test/Data/YamlSpec.hs:440: > > 1) Data.Yaml.Data.Yaml encode invalid numbers > >expected: ".\n" > > but got: ".\n...\n" > > > > test/Data/YamlSpec.hs:458: > > 2) Data.Yaml.numbers integers have no decimals > >expected: "1\n" > > but got: "1\n...\n" > > > > Randomized with seed 1628861893 I don't know what we should do here. The behavior of the embedded libyaml differs from our libyaml and I'm not sure why, but it appears to be on purpose.
Bug#865399: Cabal conflict
Control: reassign -1 libghc-cabal-dev Control: found -1 1.24.2.0-1 haskell-cabal should be kept out of testing for the foreseeable future, and any packages build-depending on it should be switched to use ghc's Cabal for the foreseeable future.
Bug#847677: "unable to decommit memory" data loss
On Sat, Dec 10, 2016 at 11:24:26AM -0400, Joey Hess wrote: > It apparently then led to memory corruption, since git-annex created > some very bogus symlinks: > > lrwxrwxrwx 1 user user 338 Jun 17 22:36 > bup.git/objects/pack/pack-47b493a3bbbd22200d2b390c277e49ce713243cc.pack -> > *??:?;J? > > So, we seem to have data loss, presumably any git-annex binary built > with this ghc and used with a too old kernel. Could also affect other > haskell programs. If the MADV_FREE is actually causing memory corruption we have two problems: 1) The upstream patch will not fix it 2) There is a serious bug in Linux < 4.5
Bug#839760: patch?
Looks like Ilias and Emilio found https://github.com/tych0/xcffib/commit/9b6a190e6d46b11b4565322626c702caecff9d8b
Bug#828506: pkcs11-helper: FTBFS with openssl 1.1.0
On Tue, Nov 01, 2016 at 12:03:40AM +0100, Sebastian Andrzej Siewior wrote: > There is an pull request from fedora. The fedora bug ist at > https://bugzilla.redhat.com/show_bug.cgi?id=1388463 Better to switch to libssl1.0-dev to avoid breaking openvpn.
Bug#844323: (no subject)
On Mon, Nov 14, 2016 at 01:34:05PM -0200, Breno Leitao wrote: > reassign ghc > > After some further debug, I found this is, in fact, a ghc bug and it was > fixed in version 8.0.2, as showed in: > > https://ghc.haskell.org/trac/ghc/ticket/12621 Great!
Bug#843405: haskell-intern: needs sourceful upload
Source: haskell-intern Version: 0.9.1.4-1 Severity: serious libghc-intern-doc needs to be rebuilt with ghc 8 so it can become installable.
Bug#843404: haskell-swish: needs sourceful upload for ghc8 transition
Source: haskell-swish Version: 0.9.1.7-2 Severity: serious libghc-swish-doc needs to be rebuilt against ghc 8 so it can become installable.
Bug#842740: libghc-lambdabot-haskell-plugins-dev: inane memory usage during profiling build
Package: libghc-lambdabot-haskell-plugins-dev Version: 5.1-2 Severity: serious Control: forwarded -1 https://ghc.haskell.org/trac/ghc/ticket/12790 Number of terms skyrockets during Simplify, probable GHC bug.
Bug#842572: FTBFS: newer persistent
Package: git-annex Version: 6.20161012-1 Severity: serious git-annex no longer build in sid because we have moved to ghc 8 and with it persistent 2.6. The reason git-annex conflicts with newer persistent is because esqueleto's upstream is MIA. However, we have patched our version of esqueleto to work with persistent 2.6, so git-annex.cabal could have a Debian patch along the lines of - persistent (< 2.5), + persistent >= 2.5 && < 2.7, HTH
Bug#842524: libghc-wreq-dev: fails to build from source
Package: libghc-wreq-dev Version: 0.4.1.0-1 Severity: serious wreq needs patching for ghc 8
Bug#842515: github-backup: FTBFS with newer directory
Package: github-backup Version: 1.20160522-1 Severity: serious Because we've updated GHC to 8.0, the version of the directory library has also been updated, and you'll need something like https://github.com/joeyh/github-backup/commit/848f6b64f75f4d267ba364405fb2a7b284969020
Bug#842395: libghc-fail-dev: this version should not be released with stretch
Package: libghc-fail-dev Version: 4.9.0.0-1 Severity: serious fail 4.9.0.0 should not be released with ghc 8.0 in stretch
Bug#842394: haskell-cabal: this version should not be released with stretch
Source: haskell-cabal Version: 1.22.8.0-1 Severity: serious stretch should be released either without the haskell-cabal package or with a newer version than is shipped with ghc
Bug#839840: ghci segfaults on armel, related to doctest failure
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.
Bug#832824: haskell-src-exts: reporting a bug at GHC for linker error. build fail on mips64el
On Sat, Oct 01, 2016 at 04:06:15PM +0200, Florian Weimer wrote: > So passing -mxgot would be worth a try. This seems to be similar to > the -fpic/-fPIC distinction. That appears to do the trick.
Bug#832824: haskell-src-exts: reporting a bug at GHC for linker error. build fail on mips64el
On Wed, Aug 17, 2016 at 01:14:35AM -0400, Jonathan Jackson wrote: > The last build of haskell-src-exts 1.17.1-1 has failed 30 days > ago on a mips64el device. More information since first report > of this failure have been acquired. Bug report seems to > indicate that there is a linker problem during compilation, > indicated by some of the last lines of the build log: > > "ghc_8.hc:(.text+0x884): relocation truncated to fit: > R_MIPS_GOT_DISP against `base_GHCziNum_zp_entry' > ghc_8.hc:(.text+0x8e4): additional relocation overflows omitted > from the output collect2: error: ld returned 1 exit status" > > Scarce documentation documentation on the subject exists but > the available syntax of Haskell does not give any control at > this level of abstraction. > > This would indicate a compiler problem which should be reported > at GHC. No "ld" options have been identified as potentially > helpful for this problem. GHC has some. > > GHC has some specifics about package building when reporting a > bug: https://ghc.haskell.org/trac/ghc/wiki/ReportABug > > If you need more information or have some more information > about the source of the build fail, do not hesitate to write > back. Hi Jonathan, Thanks for looking at this. I don't know anything about MIPS ELF or GHC internals, but the last time haskell-src-exts succeeded it was with GHC 7.10.3 and it is now failing with GHC 7.10.3, whereas the version of binutils has changed. Can you explain what GHC might be doing wrong? Did binutils get stricter about something? What is R_MIPS_GOT_DISP? Are the GOT constraints the same on mips64el as they are on mipsel? Is this failure only occurring on the profiling build because there are more symbols or is it for a different reason?
Bug#837208: python-ofxclient: chokes on %{secured}
Package: python-ofxclient
Version: 2.0.2-1
Severity: serious
Control: forwarded -1 https://github.com/captin411/ofxclient/issues/28
Traceback (most recent call last):
File "/usr/bin/ofxclient", line 9, in
load_entry_point('ofxclient==2.0.2', 'console_scripts', 'ofxclient')()
File "/usr/lib/python2.7/dist-packages/ofxclient/cli.py", line 60, in run
main_menu()
File "/usr/lib/python2.7/dist-packages/ofxclient/cli.py", line 80, in
main_menu
add_account_menu()
File "/usr/lib/python2.7/dist-packages/ofxclient/cli.py", line 127, in
add_account_menu
if login_check_menu(bank):
File "/usr/lib/python2.7/dist-packages/ofxclient/cli.py", line 215, in
login_check_menu
GlobalConfig.add_account(a)
File "/usr/lib/python2.7/dist-packages/ofxclient/config.py", line 246, in
add_account
self.encrypt_account(id=section_id)
File "/usr/lib/python2.7/dist-packages/ofxclient/config.py", line 254, in
encrypt_account
self.parser.set_secure(id, key, value)
File "/usr/lib/python2.7/dist-packages/ofxclient/config.py", line 134, in
set_secure
ConfigParser.set(self, section, option, value)
File "/usr/lib/python2.7/dist-packages/configparser.py", line 1233, in set
super(ConfigParser, self).set(section, option, value)
File "/usr/lib/python2.7/dist-packages/configparser.py", line 930, in set
value)
File "/usr/lib/python2.7/dist-packages/configparser.py", line 409, in
before_set
u"position %d" % (value, tmp_value.find(u'%')))
ValueError: invalid interpolation syntax in u'%{secured}' at position 0
Bug#833904: haskell-blogliterately: FTBFS: fails with -ENOENT
On Wed, Aug 10, 2016 at 11:59:14AM -0400, Joachim Breitner wrote: > we do have that for Haskell ABI changes, but I believe it does not > cover the names of shared C libraries. Maybe that can be considered a > bug, and something that can be fixed on the GHC side. If someone wants > to dig deeper, I’ll happily assist. Any reason to not get rid of DEB_DH_SHLIBDEPS_ARGS_ALL += -XlibHS ?
Bug#833904: haskell-blogliterately: FTBFS: fails with -ENOENT
On Wed, Aug 10, 2016 at 07:44:25AM +, Mattia Rizzolo wrote: > : can't load .so/.DLL for: > /usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-7.10.3/pandoc-citeproc-0.9.1.1-H4nKjmy3LdhAeupsyJYDB0/libHSpandoc-citeproc-0.9.1.1-H4nKjmy3LdhAeupsyJYDB0-ghc7.10.3.so > (libicuuc.so.55: cannot open shared object file: No such file or directory) Looks like haskell-pandoc-citeproc needs to be rebuilt against the new libicu-dev and then haskell-blogliterately can be given back.
Bug#819890: ugh
severity 819890 important quit This has been worked around by disabling the doctests. Whatever is broken on armel is still broken, but that is irrelevant to the testing migration held up by this bug.
Bug#819890: haskell-http2: FTBFS on armel buildds (was: Re: Please give back haskell-http2 on armel)
On Mon, Apr 04, 2016 at 05:24:38AM +, Riku Voipio wrote: > The reproducible-builds is armhf while the failing ones are armel. The > regression > appears to be a code change in haskell-http2 between 1.0.4 and 1.3.1: > > https://buildd.debian.org/status/logs.php?pkg=haskell-http2=armel I think we can be pretty confident that the bug is in ghc or doctest.
Bug#713313: drift: FTBFS: GenUtil.hs:290:14: Not in scope: `catch'
On Sun, Aug 16, 2015 at 10:46:06PM +0200, Uwe Kleine-König wrote: I'm currently in NM trying to become DD. As part of the process I prepared an NMU for this with the following debdiff. It's that big because I converted the package from dpatch to 3.0 (quilt). I assume the that Thijs will upload this nmu to a delayed queue (assuming he is happy with it). I suggest NMUing the latest upstream version as it will be less painful both long-term nd short-term.
Bug#635711: [monkeysphere] Bug#635711: further analysis of monkeysphere.postinst failures
On Tue, Nov 25, 2014 at 04:05:37PM -0500, Daniel Kahn Gillmor wrote: gpg_sphere is a shell function but according to the set -x it isn't even getting invoked before the SIGPIPE hits. No? + printf '%s:6:\n' 473F86D46E0B3CA0611450A8C9A7E0FFD1CD8FDC + gpg_sphere --import-ownertrust + RET=141 If, for some reason, su_monkeysphere_user (called by gpg_sphere) asked for a password instead of quietly changing to the monkeysphere user, you would get this SIGPIPE. I don't know why that would happen though. export GNUPGHOME=$(pwd) for x in 5 6 5 6 5 6 5 6 5 6 5 6; do printf %s:$x:\n $FPR | gpg --import-ownertrust 21 | log verbose done -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#635711: [monkeysphere] Bug#635711: Bug#635711: further analysis of monkeysphere.postinst failures
On Wed, Nov 26, 2014 at 04:07:57PM -0500, Daniel Kahn Gillmor wrote: + printf '%s:6:\n' 473F86D46E0B3CA0611450A8C9A7E0FFD1CD8FDC + gpg_sphere --import-ownertrust + RET=141 this just tells us that bash wanted to invoke gpg_sphere, not that it actually did invoke it. Had it invoked it, we should see more set -x output messages, right? look further up the page for a previous invocation of gpg_sphere. I'd expect to see at least: + GNUPGHOME=/var/lib/monkeysphere/authentication/sphere + export GNUPGHOME ... There should be no chance that gpg_sphere is not invoked in a subshell, though I may not remember how pipelines actually work in bash. Presumably it starts to run but is killed off by the SIGPIPE before it can set GNUPGHOME? -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#635711: [monkeysphere] Bug#635711: Bug#635711: Bug#635711: further analysis of monkeysphere.postinst failures
On Wed, Nov 26, 2014 at 04:44:53PM -0500, Daniel Kahn Gillmor wrote: but the SIGPIPE should only happen if a write is actually being done to the closed pipe, though, right? And what would be writing to that pipe? I suppose logic would indicate that printf is writing and gpg_sphere is aborting abruptly for no apparent reason. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#635711: [monkeysphere] Bug#635711: Reproducing Install Error on Freedom-Maker DreamPlug Build
On Sat, Jun 28, 2014 at 03:55:16PM -0500, Nick Daly wrote: diff -r 9e5e6d9f91b1 debian/monkeysphere.postinst --- a/debian/monkeysphere.postinstSat Jun 28 14:54:59 2014 -0500 +++ b/debian/monkeysphere.postinstSat Jun 28 14:55:33 2014 -0500 @@ -21,12 +21,15 @@ monkeysphere fi - # try all available transitions: + # try all *necessary* transitions for trans in 0.23 0.28 ; do Wouldn't it make sense to just remove this entirely, since there's no need to support upgrades from before lenny? -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762442: Removal imminent
On Mon, Sep 22, 2014 at 01:48:42PM +0200, Joachim Breitner wrote: Source: haskell-libtagc Version: 0.12.0-5 Severity: serious If pandoc is staying where it is, should this severity be downgraded until after the release? -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756801: [Pkg-haskell-maintainers] Bug#756801: haskell-bloomfilter: FTBFS almost everywhere
forwarded 756801 https://github.com/bos/bloomfilter/issues/7 quit Broken on 32-bit. On Fri, Aug 01, 2014 at 08:45:42PM +0200, Sebastian Ramacher wrote: Source: haskell-bloomfilter Version: 2.0.0.0-1 Severity: serious Justification: fails to build from source (but built successfully in the past) haskell-bloomfilter failed to build almost everywhere with: | Running 1 test suites... | Test suite tests: RUNNING... | (): [Failed] | *** Failed! Exception: 'Data.BloomFilter.Util.suggestSizing: capacity too large to represent' (after 1 test): -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750032: Changes for the NMU
On Sun, Jun 15, 2014 at 06:09:57PM -0700, Don Armstrong wrote: The changes for this NMU are available from Thanks, Don! -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750032: New version of xul-ext-pentadactyl
On Thu, Jun 05, 2014 at 10:50:54AM -0700, Don Armstrong wrote: Just wanted to check in on this; I actively use pentadactyl, and would like to see the new version in Debian. If you'd like additional assistance, I can help upload a new version or whatever makes sense. I'd just like to avoid duplicating work or getting in your way. [I'm not sure if I have commit access to the pkg-mozext repo, either... but if I do, and I have your blessing, I can prepare an upload of the new version.] Please NMU or hijack. This delay is infuriating. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
