Bug#980305: RFA: libcddb2
Hello Nick, This comes extremely late, my apologies. However: Nick Gasson kirjoitti 27.2.2021 klo 8.22: > I'm not maintaining a dependent package but I'd like to help Debian > more. I took a look at the two open bugs and I think they can be fixed > quite easily with the patches I attached. Let me know if you're happy > for me to adopt it. You don't need my permission to adopt it. When you find an uploading Debian Member who could guide and upload the package for you, you're welcome to update the package with your patches and other potential changes. -- Eugene V. Lyubimkin aka JackYF C++ GNU/Linux userspace developer, Debian Developer
Bug#980305: RFA: libcddb2
Package: wnpp Severity: normal Hello, The libcddb package needs a new maintainer. I no longer have time nor interest to maintain it properly. I had adopted it many years as a dependency of a package I no longer maintain. It was very low-maintenance until recently; there are now two outstanding bug reports which require attention [1]. If you maintain one of Debian packages that depend on libcddb (Cc:d), you might be interested in adopting it. [1] https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=libcddb
Bug#972869: RFA: fmtlib
Package: wnpp Severity: normal Hello, This package needs a more responsive maintainer. I unfortunately haven't had enough time for months and this is unlikely to change in the near future. fmtlib is a modern C++ library, it provides fast and type-safe replacement of (s)printf and related machinery. What needs to be done: - package a new upstream release; - solve a (documentation-related) FTBFS; - potentially make a shared library instead of a static library. Regards, -- Eugene V. Lyubimkin C++ GNU/Linux userspace developer, Debian Developer
Bug#952625: libixion: FTBFS: configure: error: Package requirements (spdlog >= 0.16.0) were not met
Hi, Rene Engelhard kirjoitti 26.2.2020 klo 18.49: [...] >> libfmt-dev does not have a .pc file. Thus this isn't resolvable. >> >> root@frodo:/# pkg-config --cflags fmt >> Package fmt was not found in the pkg-config search path. >> Perhaps you should add the directory containing `fmt.pc' >> to the PKG_CONFIG_PATH environment variable >> No package 'fmt' found >> >> -> bug in spdlog > > Commenting out the above line of course works. > > It seems to me that libfmt-dev is header-only or static? (-dev doesn't > depend on a fmt shared library). So that means that it could safely be > removed for the header-only usecase. It is correct that as of moment libfmt-dev provides a static library only, due to a small library size plus still somewhat frequent API changes. [...] > Or fmt gets a .pc file (Cced.) Thanks for the message. Upstream started to provide .pc-file in relatively recent versions. With libfmt-dev from experimental (and soon in unstable), "pkg-config --cflags fmt" works. Regards, -- Eugene V. Lyubimkin aka JackYF C++ GNU/Linux userspace developer, Debian Developer
Bug#950856: fmtlib: Please upload source package to salsa.debian.org and set Vcs-*
Hello, Michael R. Crusoe kirjoitti 7.2.2020 klo 14.33: > Hello, please upload source package to salsa.debian.org and set Vcs-*; thanks I currently don't have plans to upload packaging to some particular location. Any particular reason the packaging location is important for you? Regards, -- Eugene V. Lyubimkin aka JackYF C++ GNU/Linux userspace developer, Debian Developer
Bug#950857: fmtlib: Please upload a package for version 6.1.2
Hello, Michael R. Crusoe kirjoitti 7.2.2020 klo 14.35: > spdlog is currently using an embedded copy of version 6+, so if fmtlib > is updated we can use the packaged version instead Thank you for the heads-up. This is now work-in-progress. -- Eugene V. Lyubimkin aka JackYF C++ GNU/Linux userspace developer, Debian Developer
Bug#951208: fuse3's backwards compatibilty (Re: Bug#951208: Impossible to mount over nonempty directories)
Hello, Martin Pärtel kirjoitti 17.2.2020 klo 10.49: > I'm unfortunately unlikely to have time to port bindfs to FUSE 3 in the near > future :( > > The easiest distro-level workaround in terms of "least code required" would > probably be to patch fuse3's fusermount to > allow and ignore `nonempty` (and maybe print a deprecation warning). Or some > hacks could probably be invented to direct > FUSE 2 filesystems to use FUSE 2 helpers. It's up to the Debian maintainers > whether they want the maintenance burder of > either of these workarounds. CC'ing FUSE's maintainer for extra input if any. >From the discussion above I gather that bindfs is still (with limitations) >usable with fuse3. If true, then I wouldn't like to block users of fuse3 from using bindfs via strict Depends. I could add Suggests or Recommends on fuse2, though. How common of a use case is to use bindfs with a non-empty mount point? I never mounted filesystems like that myself, so I don't know if it's a minor nuisance with an easy workaround, or a significant limitation making some use case unachievable. Regards, -- Eugene V. Lyubimkin aka JackYF C++ GNU/Linux userspace developer, Debian Developer
Bug#951474: libfmt-dev: spdlog try to load fmt v5 function()
Control: tags -1 + moreinfo Hello, Christian Marillat kirjoitti 17.2.2020 klo 8.45: > Note : This bug is for armel, armhf, arm64 and powerpc arches. > > As said in bug #950857 spdlog is build using an embedded copy of version 6+ > and thus fail to load include from version 5. > > [...] I'd need more details to reproduce and understand the problem, particularly whether packaged libfmt v5 is a root case or not. I can see the from lines that there is a linking problem in the package 'gerbera`, but I do not see where these logs are coming from. The unstable version of the package builds cleanly for me - are you trying to build an unreleased version? If yes, which exact sources? Do you have links to build logs? Regards, -- Eugene V. Lyubimkin aka JackYF C++ GNU/Linux userspace developer, Debian Developer
Bug#947850: Backport fmtlib 5.3 to buster-backports
Hello, Jonas Meurer kirjoitti 31.12.2019 klo 18.04: > thanks for maintaining fmtlib in Debian. In order to bring waybar to > buster-backports, I'd like to upload a backport of fmtlib to buster-backports > as well. Would you like to take care of this yourself or are you fine with me > doing the backport? Thank you for the interest. I'd be okay with you doing the backport, as long as no dramatic changes are planned to what package provides. I guess you'd be mainly interested in a re-build so 'libstdc++6'-dependency are satisfiable in stable? Regards, -- Eugene V. Lyubimkin aka JackYF C++ GNU/Linux userspace developer, Debian Developer
Bug#941886: crashes with segfault while scanning library
Hello Antoine, Antoine Beaupre kirjoitti 7.10.2019 klo 6.02: > After starting fbreader (which takes 30 seconds), I go to the library > and hit settings. There I configure my ebook library (~/books), click > the "Look for books in subdirectories" button, and hit "OK". > > After a little scanning, it totally crashes with the following backtrace: Thank you for the detailed report. Unfortunately, the upstream development has stopped many years ago, and it's unlikely for problems to become fixed unless somebody steps up. Regards, -- Eugene V. Lyubimkin aka JackYF C++ GNU/Linux userspace developer, Debian Developer
Bug#931444: fixed in ncdu 1.14.1-1
Hi, Paul Wise kirjoitti 8.9.2019 klo 11.34: > On Sun, 2019-09-08 at 08:41 +0000, Eugene V. Lyubimkin wrote: > >>* debian/patches: >> - 0001-Increase-space-for-item-count-in-loading-screen: added >>(cherry-picked from upstream). (Closes: #931444) > > This just increases the size of the hardcoded space available so I > don't think it is the correct fix, since a larger item count will just > overflow the space again. It would be best to dynamically allocate it > based on the size of the item count/etc. Yes, the upstream went for a quick fix here. There are other places, too [1], where it would be beneficial to use runtime-determined sizes instead of the fixed-width approach, but the upstream hasn't gone into that direction so far. I've marked the bug resolved, as the immediate problem reported is fixed. Plus, there is a natural limit of how many files one can have before ncdu stops to be usable, so in this particular case the maximum width approach sounds okay [2]. Feel free to re-open this bug, if you're willing to convince upstream otherwise. [1] https://code.blicky.net/yorhel/ncdu/issues/37 [2] even though I'd myself allow 2-3 more digits than today. Regards, -- Eugene V. Lyubimkin aka JackYF C++ GNU/Linux userspace developer, Debian Developer
Bug#939290: missing dependency on newer libstdc++ (Re: Bug#939290: libfmt-dev)
Hi, Martin Michlmayr kirjoitti 2.9.2019 klo 22.53: > Package: libfmt-dev > Version: 5.3.0+ds-1 [...] > /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libfmt.a(format.cc.o): in function > `fmt::v5::system_error::init(int, fmt::v5::basic_string_view, > fmt::v5::format_args)': > (.text+0xd52): undefined reference to > `std::runtime_error::operator=(std::runtime_error&&)' > collect2: error: ld returned 1 exit status > > Any idea what this is about? Yes, thank you for the report. It seems the latest build in unstable picked up some symbols from libstdc++ which are not satisfied in stable. Quick work-around: install libstdc++6 from Debian testing. This bug will be fixed by listing the missing package dependency. Regards, -- Eugene V. Lyubimkin aka JackYF C++ GNU/Linux userspace developer, Debian Developer
Bug#931444: ncdu: progress dialog: for dirs with many files, total items can almost overlap size
Control: forwarded -1 https://code.blicky.net/yorhel/ncdu/issues/135 Hello Paul, Paul Wise kirjoitti 5.7.2019 klo 8.32: > For directories that have many subdirectories and many files, in the > ncdu progress dialog the total items count can encroach on and almost > overlap the total size count: > >Total items: 20161797size: 123.4 GiB > > [...] Thank you for the report, it's now forwarded upstream. Regards, -- Eugene V. Lyubimkin aka JackYF C++ GNU/Linux userspace developer, Debian Developer
Bug#929162: randtype FTCBFS: does not pass cross tools to make
Hello Helmut, Helmut Grohne kirjoitti 18.5.2019 klo 14.11: > randtype fails to cross build from source, because it does not pass > cross tools to make. The easiest way of doing so - using dh_auto_build - > makes randtype cross buildable. Please consider applying the attached > patch. Thank you for the patch, it looks good. I'll apply it in the next upload, likely post-freeze. Regards, -- Eugene V. Lyubimkin aka JackYF C++ GNU/Linux userspace developer, Debian Developer
Bug#902457: [Cupt-devel] Bug#902457: cupt: FTBFS in buster/sid (failing tests)
Hello, Thank you for the report. On 27.06.2018 00:52, Santiago Vila wrote: > [...] > > tt/query/repo-signatures/validation-errors.t >(Wstat: 768 Tests: 9 Failed: 3) > Failed tests: 1-2, 9 > Non-zero exit status: 3 [...] > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/cupt.html > > If this is really a bug in one of the build-depends, please use reassign and > affects, > so that this is still visible in the page for this package. Apologies for the late response. I will take a look at this failure during the coming week-end, even though it'd be too late to avoid a temporary auto-removal from testing. Regards, -- Eugene V. Lyubimkin aka JackYF C++ GNU/Linux userspace developer, Debian Developer
Bug#894544: cantata: please switch build-depends to libcddb2-dev
Package: cantata Version: 2.2.0.ds1-1 Severity: normal Dear Maintainer, Your package build-depends on 'libcddb-dev', which is an ancient transitional virtual package provided by 'libcddb2-dev'. I'm looking forward to remove this virtual package, and your package is the last in the Debian archive which uses it. Please replace 'libcddb-dev' with 'libcddb2-dev' in your build-depends. Regards, -- System Information: Debian Release: 8.0 Architecture: amd64 (x86_64) Kernel: Linux 4.3.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init)
Bug#882238: [Cupt-devel] Bug#882238: Bug#882238: cupt: FTBFS on hppa and hurd-i386: feeding-input.t fails
Control: tags -1 + pending Hi Dave, On 30.03.2018 19:41, John David Anglin wrote: > [...] > The attached change fixed the build failure on my rp3440. Don't know if 60s > is enough for the slower buildds. Thank you for investigation. It's good to know that the current timeout buffer just isn't large enough. It's interesting that, judging from the last buildd log, for a particularly CPU-intense case the slowdown versus my desktop was only 5x, but the more I/O-bound failing case didn't cut it despite a 20x buffer. I'll increase the timeout to 90s in the next upload, and see if that works better for buildds. Regards, -- Eugene V. Lyubimkin aka JackYF C++ GNU/Linux userspace developer, Debian Developer
Bug#882238: [Cupt-devel] Bug#882238: cupt: FTBFS on hppa and hurd-i386: feeding-input.t fails
Hi, Thank you for taking a look. On 30.03.2018 01:01, John David Anglin wrote: [...] >>> On hurd-i386, I tracked it down to a misbehaviour of timeout(1), reported >>> as #894379. >>> For HPPA, I didn't see any available porterboxes for HPPA on db.debian.org, >>> so I could not >>> reproduced it. Did I miss any? >> I'll take a look at the timeout problem. Access to a box can be arranged. > I find timeout works correctly on hppa. I see, so it's a different issue then. Please let me know if/when there is a box I could reproduce the test case failure on. Regards, -- Eugene V. Lyubimkin aka JackYF C++ GNU/Linux userspace developer, Debian Developer
Bug#894380: ncdu: please enable color by default
Control: tags -1 wontfix Hi Graham, Thank you for the interest. On 29.03.2018 17:32, Graham Inggs wrote: > Please consider enabling color by default as per the attached patch. > I believe doing so in Debian Testing can assist upstream in perfecting this > new feature. The color feature is explicitly marked as experimental by upstream. Additionally, there are quite a few old and new features not enabled by default, but we don't enable them all just for earlier testing. Coloring works fine for me, but I don't see it as a game-changer worth to diverge from upstream. Those who like the feature and want to assist with testing could easily use shell aliases to save the typing and personalise the options they prefer. If you persuade upstream to change the defaults earlier before the next release, I'm open to cherry-picking that. Regards, -- Eugene V. Lyubimkin aka JackYF C++ GNU/Linux userspace developer, Debian Developer
Bug#882238: [Cupt-devel] Bug#882238: cupt: FTBFS on hppa and hurd-i386: feeding-input.t fails
Hi Aaron, Hurd and HPPA porters, Thank you for the report. Sorry that it took so long to get it to it. On hurd-i386, I tracked it down to a misbehaviour of timeout(1), reported as #894379. For HPPA, I didn't see any available porterboxes for HPPA on db.debian.org, so I could not reproduced it. Did I miss any? Otherwise, if you know simple-to-use substitutes for timeout(1) or know what's going on in #894379, your input is welcome. Regards, -- Eugene V. Lyubimkin aka JackYF C++ GNU/Linux userspace developer, Debian Developer
Bug#894379: coreutils: timeout (hurd, possibly hppa): fails to detect that a program has exited
Package: coreutils Version: 8.28-1 Severity: normal Control: affects -1 cupt Hello, Thank you for maintaining coreutils. I use timeout(1) to conveniently detect hanging problems in the testsuite of cupt. Unfortunately, on hurd and hppa it makes the test suite fail. This issue is best illustrated through a test case: On hurd-i386 the commands which take less time to execute still make 'timeout' wait full time and exit with the error code: --8<- $ mkdir abc $ cd abc $ timeout 5s ls $ echo $? 124 $ timeout 5s cat $ echo $? 124 -->8- On, say, amd64 the same scenario works as expected: --8<- $ mkdir abc $ cd abc $ timeout 5s ls $ echo $? 0 $ timeout 5s cat $ echo $? 124 -->8- I couldn't check this scenario on hppa (as there are no porterboxes for it), but the bug report #882238 suggests a similar issue has been encountered on a hppa buildd box. On hurd-i386 portexbox, I did verify that the program run under timeout(1) does exit, but timeout(1) itself continues to run even though it has no child processes anymore.
Bug#890033: fmtlib: CVE-2018-1000052: Segmentation fault in fmt::print()
Control: severity -1 normal Control: tags -1 - security Hello Salvatore, Thank you for bring this CVE entry for my attention. Unfortunately I find that the entry contains a factual error and a judgement I disagree with (see below). On 10.02.2018 11:21, Salvatore Bonaccorso wrote: > [...] > CVE-2018-152[0]: > | fmtlib version prior to version 4.1.0 (before commit > | 0555cea5fc0bf890afe0071a558e44625a34ba85) contains a Memory corruption > | (SIGSEGV), CWE-134 vulnerability in fmt::print() library function that > | can result in Denial of Service. This attack appear to be exploitable > | via Specifying an invalid format specifier in the fmt::print() > | function results in a SIGSEGV (memory corruption, invalid write). This > | vulnerability appears to have been fixed in after commit > | 8cf30aa2be256eba07bb1cefb998c52326e846e7. Firstly, the crash in question happens when using a specially-crated format string. Just like for C-style printf(), application developers should not pass untrusted input as a first argument to formatting functions. For well-written applications using fmtlib, there is no exposure and therefore I disagree with labelling this bug as security vulnerability or DoS. One can argue that the library advertises itself as a safe prompts to think the library shall handle gracefully any junk in the format string. It ideally should, but failing to so still wouldn't IMO constitute a vulnerability, but simply a normal-severity bug. Secondly, the upstream commit 8cf30aa2be is not included in the upstream version 4.1.0 (unlike the entry indicates). 4.1.0 was released in January 2018, and the fix was committed in February 2018. Therefore, only next minor or patch release will contain the fix. I am not planning to cherry-pick the fix before that. Regards, -- Eugene V. Lyubimkin aka JackYF C++ GNU/Linux userspace developer, Debian Developer
Bug#874867: [fbreader] Future Qt4 removal from Buster
Hello, On 08.12.2017 17:37, Francesco Poli wrote: > I suppose you no longer user FBReader, nowadays. > I wonder: what alternative e-book reader are you currently using? I read less e-books nowadays, and those I read usually available (or convertible) to HTML or PDF. > Would you be willing to package Bookworm for inclusion in Debian? It's a good sign there are some other actively developed software for e-books. Bookworm specifically has an implementation language/ecosystem (Vala) I'm not familiar with, so I'd not package it myself. Regards, -- Eugene V. Lyubimkin aka JackYF C++ GNU/Linux userspace developer, Debian Developer signature.asc Description: OpenPGP digital signature
Bug#874867: [fbreader] Future Qt4 removal from Buster
Hello Francesco,
First and foremost: if anybody reading these lines has time to take good
care of fbreader, it has been up for adoption for quite some time (#808074).
On 26.11.2017 12:12, Francesco Poli wrote:
[...]
> Hello Eugene,
> I noticed that fbreader needs to be ported to Qt5, but the upstream
> project seems to be basically dead, as stated in [issue #285]
> (which is referenced on the Qt4 removal Debian wiki page).
>
> [issue #285]: <https://github.com/geometer/FBReader/issues/285>
>
> It would be really sad news, if fbreader had to be removed from Debian:
> it is a nice lightweight e-book reader.
>
> Some messages (currently) at the end of the above-cited [issue #285]
> claim that a Qt5 port is possible with a couple of patches ("pallegro
> commented Mar 30, 2016" and "idomeneo commented Nov 18, 2017").
> See also the [Gentoo pr #5970].
>
> [Gentoo pr #5970]: <https://github.com/gentoo/gentoo/pull/5970>
>
> Those patches seem to be based on version 0.99.4, which you [said] you
> were hesitant about packaging. Is it time to reconsider, perhaps?
The only long-term solution I see to revive and maintain long-stagnated fbreader
is that somebody becomes an involved and active upstream. I don't see that
packaging a dead-end beta version with some patches on top is supportable and
sustainable (but a prospective new maintainer can disagree with that).
Unlike 0.99.x serie, 0.12.x serie does have two back-ends: Qt4 and GTK2.
This is what I plan to do if nobody steps and as new Debian and/or
upstream maintainer:
1. When Qt4 is removed from Debian, libzlui-qt4 (Qt4 back-end for fbreader) will
go away. Fbreader will remain usable with libzlui-gtk (GTK2 back-end).
2. When GTK2 is removed from Debian, fbreader will be removed from Debian.
Regards,
--
Eugene V. Lyubimkin aka JackYF
C++ GNU/Linux userspace developer, Debian Developer
Bug#882146: dpkg: does not allow removing a dependency of an unpacked package without --force-depends
Package: dpkg Version: 1.19.0.4 Severity: normal Hi Guillem and all, Please consider the following situation: - package 'aa' is unpacked; - package 'aa' has a dependency on package 'bb' (version 2); - package 'bb' version 1 is currently installed; - we're trying to remove package 'bb'. I'd expect we can remove 'bb' (version 1), since dependencies do not have to be satisfied for merely-unpacked packages. Moreover, the dependency 'aa -> bb' was unsatisfied anyway due to a version mismatch, so removing 'bb' does not break any dependency which was satisfied before. Adding '--force-depends' works around the problem, but I'd prefer not having to mass-enable it. Here is a transcript with real packages (aa -> python3-uno, bb -> libreoffice-core): -8<--- $ dpkg -s python3-uno | egrep "Depends|Status" Status: install ok unpacked Depends: libreoffice-core (= 1:5.4.2-3), [...] $ dpkg -s libreoffice-core | grep Version Version: 1:5.2.2~rc2-2 $ dpkg --dry-run --force-bad-path --remove libreoffice-core [...] dpkg: dependency problems prevent removal of libreoffice-core: python3-uno depends on libreoffice-core (= 1:5.4.2-3). libreoffice-base-core depends on libreoffice-core (= 1:5.4.2-3). libreoffice-math depends on libreoffice-core (= 1:5.4.2-3). dpkg: error processing package libreoffice-core (--remove): dependency problems - not removing Errors were encountered while processing: libreoffice-core $ dpkg --dry-run --force-bad-path --force-depends --remove libreoffice-core [...] dpkg: libreoffice-core: dependency problems, but removing anyway as you requested: python3-uno depends on libreoffice-core (= 1:5.4.2-3). libreoffice-base-core depends on libreoffice-core (= 1:5.4.2-3). libreoffice-math depends on libreoffice-core (= 1:5.4.2-3). (Reading database ... 147478 files and directories currently installed.) Would remove or purge libreoffice-core (1:5.2.2~rc2-2) ... ->8--- Seen same behavior also in dpkg 1.18.24 and 1.17.24. -- System Information: Debian Release: 8.0 Architecture: amd64 (x86_64) Kernel: Linux 4.3.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages dpkg depends on: ii libbz2-1.0 1.0.6-7+b2 ii libc62.23-1 ii liblzma5 5.2.2-1.2+b1 ii libselinux1 2.3-2 ii tar 1.29b-1.1 ii zlib1g 1:1.2.8.dfsg-2+b1 dpkg recommends no packages. Versions of packages dpkg suggests: ii apt1.6~alpha5 pn debsig-verify -- no debconf information
Bug#879914: fmtlib: please make the build reproducible
Hi, On 27.10.2017 10:41, Chris Lamb wrote: > Whilst working on the Reproducible Builds effort [0], we noticed > that fmtlib could not be built reproducibly as — in a Doxygen error > message — it exposes the use of Doxygen's "FULL_PATH_NAMES = YES". > > Patch attached. Looks good, thanks. Will be applied in the next upload. -- Eugene V. Lyubimkin aka JackYF C++ GNU/Linux userspace developer, Debian Developer
Bug#878070: fmtlib: Removing header-only target is causing problem
Control: retitle -1 fmtlib: static library should be compiled with -fPIC Control: tags -1 + confirmed pending Hello, On 09.10.2017 15:15, Boyuan Yang wrote: > I saw that your recommendation is to use the static library provided. I think > that may not be best practice. I agree it's not. However, fmtlib changed its major version 4 times in the last 2½ years, so considering its small size and relative unstability (so far) the package doesn't provide a shared library right now. In version 4 there are less breaking changes than before, so I'll re-evaluate whether to add a shared library later in the release cycle. > As you might already know, Debian don't really recommend using static > libraries. Especially after the beginning of hardening efforts in Debian [2], > using static libraries while building hardened binaries will encounter > problem > that the static library is not built with -fPIC. This is the current case for > fcitx5 using fmtlib. Good point. The code should be definitely built with -fPIC. Thank you for the report, will be fixed in the next upload. Regards, -- Eugene V. Lyubimkin aka JackYF C++ GNU/Linux userspace developer, Debian Developer
Bug#877642: RM: cppformat -- ROM; superseded by fmtlib
Package: ftp.debian.org Severity: normal Hello, The newer version of 'cppformat' was uploaded as 'fmtlib' (following an upstream project rename). Thus, the older version can be now removed.
Bug#876543: cppformat: DOCUMENTATION_OPTIONS does not define SOURCELINK_SUFFIX
Hello, On 23.09.2017 16:06, Dmitry Shachnev wrote: > cppformat uses a custom Sphinx template which is not fully compatible > with Sphinx 1.5 and newer versions: search does not work because > SOURCELINK_SUFFIX attribute is not defined in DOCUMENTATION_OPTIONS in > search.html. > > dh_sphinxdoc currently emits a warning about this, I plan to make it > an error in the next upload. > > Please backport the relevant upstream patch (see the linked pull request) > or upgrade to upstream 4.0.0 release. Thank you for the report. fmtlib 4.0.0 entered unstable yesterday, so cppformat (old upstream name) will by superseded by it. -- Eugene V. Lyubimkin aka JackYF C++ GNU/Linux userspace developer, Debian Developer
Bug#866338: New version 4.0.0
Hello, On 29.06.2017 00:26, Craig Andrews wrote: > Source: cppformat > Version: 3.0.1+ds-1 > > Version 4.0.0 of libfmt has been released - can you please release new > packages for it? (libfmt4-dev, libfmt4-doc, etc) > > https://github.com/fmtlib/fmt/releases/tag/4.0.0 Thank you for the report. The work is in progress to package it. -- Eugene V. Lyubimkin aka JackYF C++ GNU/Linux userspace developer, Debian Developer
Bug#861422: fbreader FTCBFS: uses build architecture build tools
Hello Helmut, On 28.04.2017 22:03, Helmut Grohne wrote: > fbreader fails to cross build from source, because it uses build > architecture build tools (g++, pkg-config) where host architecture ones > should be used. Indirecting the $(MAKE) invocations through > dh_auto_build supplies CC and CXX, but the build system has a nother > copy of plain "g++" in LD, so that needs to be set as well. Furthermore, > pkg-config invocations need to be prefixed as well. After applying the > attached patch, fbreader successfully cross builds. Please consider > applying it after stretch is released. Thanks, the patch looks good. Feel free to ping me after Stretch if it blocks you for too long. -- Eugene V. Lyubimkin aka JackYF C++ GNU/Linux userspace developer, Debian Developer
Bug#849992: fbreader: provides no way to mark books as read or unread
Hello Francesco, On 02.01.2017 23:26, Francesco Poli wrote: > I mean: fbreader remembers which is the book the user is reading and > the point the user were, when the program was last closed. Valid point. Unfortunately, the desktop version of fbreader is not developed for years. I'd be happy to know if someone picks it up to continue the development and port the thing to Qt5 so fbreader can stay in archive for stretch+1. -- Eugene V. Lyubimkin aka JackYF C++ GNU/Linux userspace developer, Debian Developer
Bug#845358: [Cupt-devel] Bug#845358: cupt: please switch to libreadline7
Hi Sven, Thank you for the report and a patch, will be applied in the next upload. On 23.11.2016 09:53, Sven Joachim wrote: >> Would it not be better to just link against libreadline, rather than >> playing dlopen tricks which need to be adjusted on every readline soname >> bump? IIRC I did it this way because it's an optional feature of a not-so-often used subcommand, so I didn't want to introduce an absolute dependency just for that. Gains aren't big but neither are effors: the last time the SONAME was changed 6+ years ago.
Bug#841068: hurd: system() is broken if exe/lib which links to pthread calls dlclose() of SO which links to curl-gnutls
Hi, On 19.10.2016 23:34, Samuel Thibault wrote: > Samuel Thibault, on Wed 19 Oct 2016 18:15:03 +0200, wrote: >> Eugene V. Lyubimkin, on Mon 17 Oct 2016 13:26:58 +0200, wrote: >>> Unfortunately, it was not enough for Cupt test suite on Hurd, since the >>> bug still happens under another circumstances - namely, if the >>> caller itself (executable or shared library) links to pthread. >> >> A fix has been uploaded in libc0.3 2.24-5. We however now need to wait >> for p11-kit to be rebuilt with that libc in order to get the fix in (you >> don't want to know why). > > Yep, cupt now built fine! Cool, thanks :)
Bug#841068: hurd: system() is broken if exe/lib which links to pthread calls dlclose() of SO which links to curl-gnutls
Package: libc0.3 Version: 2.24-4 Severity: normal Control: affects -1 cupt Hello Samuel and all, Thank you for fixing #839742, the original test case now passes. Unfortunately, it was not enough for Cupt test suite on Hurd, since the bug still happens under another circumstances - namely, if the caller itself (executable or shared library) links to pthread. Updated test case attached. -- System Information: Debian Release: 8.0 Architecture: amd64 (x86_64) Kernel: Linux 4.3.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) dlclose.tar Description: Unix tar archive
Bug#839742: hurd: system() is broken after dlclose() of SO which links to curl-gnutls
Hi Samuel, On 09.10.2016 13:23, Samuel Thibault wrote: > Samuel Thibault, on Tue 04 Oct 2016 15:33:58 +0200, wrote: >> Eugene V. Lyubimkin, on Tue 04 Oct 2016 14:37:58 +0200, wrote: >>> On Hurd, if one loads and unloads the shared object which was linked to >>> curl-gnutls library, system() stops to work. >> >> It looks like gnutls calls pthread_atfork(), and thus on unload the >> registered hook points to nowhere. glibc seems to have support to avoid >> the issue, I had started to put the infrastructure for using it on >> hurd-i386 but didn't finish. I'll see how easy it'll be to finish it :) > > It's easy, will commit the fix :) Cool, thanks :)
Bug#839742: hurd: system() is broken after dlclose() of SO which links to curl-gnutls
Package: libc0.3 Version: 2.24-3 Severity: normal Control: affects -1 cupt [ Not sure if it's libc or kernel or something else, please reassign if needed. ] Dear Maintainer, Thank you for maintaining Glibc. On Hurd, if one loads and unloads the shared object which was linked to curl-gnutls library, system() stops to work. Namely, it then returns 11 without executing a command passed. A test case is attached. To run: 1) install cmake and libcurl4-gnutls-dev; 2) unpack attached .tar 3) $ ./run.sh -- System Information: Debian Release: 8.0 Architecture: amd64 (x86_64) Kernel: Linux 4.3.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) dlclose.tar Description: Unix tar archive
Bug#839589: valgrind: callgrind: annoying and useless 'brk segment overflow' warning
Package: valgrind
Version: 1:3.12.0~svn20160714-1+b1
Severity: normal
Dear Maintainer,
I discovered that in latest version available in testing, Valgrind's Callgrind
started to output a lot of annoying warnings which practically hides out
the important information.
Does not happen in e.g. memcheck or DRD.
Consider the following:
---8<--
$ cat main.cpp
#include
#include
int main()
{
std::size_t total = 0;
std::vector v;
for (std::size_t i = 0; i < 1; ++i)
{
v.push_back(new char[i]);
total += i;
if (i % 1000 == 0)
std::cout << "Allocated: " << total << std::endl;
}
for (auto e: v)
{
delete[] e;
}
}
$ cat Makefile
all:
g++ -O2 -Wall main.cpp -o main.e
$ valgrind --tool=callgrind ./main.e
==32597== Callgrind, a call-graph generating cache profiler
==32597== Copyright (C) 2002-2015, and GNU GPL'd, by Josef Weidendorfer et al.
==32597== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
==32597== Command: ./main.e
==32597==
==32597== For interactive control, run 'callgrind_control -h'.
Allocated: 0
Allocated: 500500
Allocated: 2001000
Allocated: 4501500
Allocated: 8002000
==32597== brk segment overflow in thread #1: can't grow to 0x4a3a000
==32597== (see section Limitations in user manual)
==32597== brk segment overflow in thread #1: can't grow to 0x4a3b000
==32597== (see section Limitations in user manual)
==32597== brk segment overflow in thread #1: can't grow to 0x4a3b000
==32597== (see section Limitations in user manual)
==32597== brk segment overflow in thread #1: can't grow to 0x4a3b000
==32597== (see section Limitations in user manual)
==32597== brk segment overflow in thread #1: can't grow to 0x4a3b000
==32597== (see section Limitations in user manual)
Allocated: 12502500
==32597== brk segment overflow in thread #1: can't grow to 0x4a3b000
==32597== (see section Limitations in user manual)
==32597== brk segment overflow in thread #1: can't grow to 0x4a3b000
==32597== (see section Limitations in user manual)
==32597== brk segment overflow in thread #1: can't grow to 0x4a3b000
==32597== (see section Limitations in user manual)
==32597== brk segment overflow in thread #1: can't grow to 0x4a3b000
==32597== (see section Limitations in user manual)
==32597== brk segment overflow in thread #1: can't grow to 0x4a3b000
==32597== (see section Limitations in user manual)
Allocated: 18003000
==32597== brk segment overflow in thread #1: can't grow to 0x4a3b000
==32597== (see section Limitations in user manual)
==32597== brk segment overflow in thread #1: can't grow to 0x4a3b000
==32597== (see section Limitations in user manual)
==32597== brk segment overflow in thread #1: can't grow to 0x4a3b000
==32597== (see section Limitations in user manual)
==32597== brk segment overflow in thread #1: can't grow to 0x4a3b000
==32597== (see section Limitations in user manual)
==32597== brk segment overflow in thread #1: can't grow to 0x4a3b000
==32597== (see section Limitations in user manual)
==32597== brk segment overflow in thread #1: can't grow to 0x4a3b000
==32597== (see section Limitations in user manual)
Allocated: 24503500
==32597== brk segment overflow in thread #1: can't grow to 0x4a3b000
==32597== (see section Limitations in user manual)
==32597== brk segment overflow in thread #1: can't grow to 0x4a3b000
==32597== (see section Limitations in user manual)
==32597== brk segment overflow in thread #1: can't grow to 0x4a3b000
==32597== (see section Limitations in user manual)
==32597== brk segment overflow in thread #1: can't grow to 0x4a3b000
==32597== (see section Limitations in user manual)
==32597== brk segment overflow in thread #1: can't grow to 0x4a3b000
==32597== (see section Limitations in user manual)
==32597== brk segment overflow in thread #1: can't grow to 0x4a3b000
==32597== (see section Limitations in user manual)
==32597== brk segment overflow in thread #1: can't grow to 0x4a3b000
==32597== (see section Limitations in user manual)
Allocated: 32004000
==32597== brk segment overflow in thread #1: can't grow to 0x4a3b000
==32597== (see section Limitations in user manual)
==32597== brk segment overflow in thread #1: can't grow to 0x4a3b000
==32597== (see section Limitations in user manual)
==32597== brk segment overflow in thread #1: can't grow to 0x4a3c000
==32597== (see section Limitations in user manual)
==32597== brk segment overflow in thread #1: can't grow to 0x4a3c000
==32597== (see section Limitations in user manual)
==32597== brk segment overflow in thread #1: can't grow to 0x4a3c000
==32597== (see section Limitations in user manual)
==32597== brk segment overflow in thread #1: can't grow to 0x4a3c000
==32597== (see section Limitations in user manual)
==32597== brk segment overflow in thread #1: can't grow to 0x4a3c000
==32597== (see section Limitations in user manual)
Bug#838438: g++/armel,armhf: -O2 causes memory corruption for some lambda captures
Package: g++-6
Version: 6.2.0-4
Severity: normal
Control: affects -1 cupt
Also applicable to g++ 6.1.1. This appears to be a regression from GCC 5.
The code works under -O1 or -O0.
See #836588 for more background.
Here's the test case which explains:
---8<--
(sid_armhf-dchroot)jackyf@harris:~/smalltests/small-std-function-arm$ cat hm.cpp
#include
#include
struct C
{
void doCb()
{
size_t dummy_a = 1;
std::cout << "Outside: " << this << std::endl;
std::function f;
f = [this, _a]()
{};
f = [this]()
{
std::cout << "Inside: " << this << std::endl;
};
f();
}
};
int main()
{
C c;
c.doCb();
}
(sid_armhf-dchroot)jackyf@harris:~/smalltests/small-std-function-arm$ cat
Makefile
all:
g++ -O2 -Wall -Wextra hm.cpp -o hm.e
(sid_armhf-dchroot)jackyf@harris:~/smalltests/small-std-function-arm$ ./hm.e
Outside: 0xbeaeb5f4
Inside: 0x2
(sid_armhf-dchroot)jackyf@harris:~/smalltests/small-std-function-arm$
~/valgrind/valgrind-3.12.0~svn20160714
/vg-in-place ./hm.e
==9628== Memcheck, a memory error detector
==9628== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==9628== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
==9628== Command: ./hm.e
==9628==
Outside: 0xbdb6a454
==9628== Use of uninitialised value of size 4
==9628==at 0x4916BF6: ??? (in
/usr/lib/arm-linux-gnueabihf/libstdc++.so.6.0.22)
==9628==
==9628== Conditional jump or move depends on uninitialised value(s)
==9628==at 0x4916BFC: ??? (in
/usr/lib/arm-linux-gnueabihf/libstdc++.so.6.0.22)
==9628==
==9628== Conditional jump or move depends on uninitialised value(s)
==9628==at 0x49179FA: std::ostreambuf_iterator std::num_put
>::_M_insert_int(std::ostreambuf_iterator, std::ios_base&, char, unsigned long) const (in
/usr/lib/arm-linux-gnueabihf/libstdc++.so.6.0.22)
==9628==by 0x4917AC5: std::num_put
>::do_put(std::ostreambuf_iterator,
>std::ios_base&, char, void const*) const (in
/usr/lib/arm-linux-gnueabihf/libstdc++.so.6.0.22)
==9628==by 0x491FDA3: std::ostream& std::ostream::_M_insert(void const*) (in
/usr/lib/arm-linux-gnueabihf/libstdc++.so.6.0.22)
==9628==
Inside: 0x2
==9628==
==9628== HEAP SUMMARY:
==9628== in use at exit: 0 bytes in 0 blocks
==9628== total heap usage: 2 allocs, 2 frees, 21,248 bytes allocated
==9628==
==9628== All heap blocks were freed -- no leaks are possible
==9628==
==9628== For counts of detected and suppressed errors, rerun with: -v
==9628== Use --track-origins=yes to see where uninitialised values come from
==9628== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0)
-- System Information:
Debian Release: 8.0
Architecture: amd64 (x86_64)
Kernel: Linux 4.3.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages g++-6 depends on:
ii gcc-66.1.1-11
ii gcc-6-base 6.1.1-11
ii libc62.23-1
ii libgmp10 2:6.0.0+dfsg-6
ii libisl15 0.17.1-1
ii libmpc3 1.0.2-1
ii libmpfr4 3.1.4-2
ii libstdc++-6-dev 6.1.1-11
ii zlib1g 1:1.2.8.dfsg-2+b1
g++-6 recommends no packages.
Versions of packages g++-6 suggests:
pn g++-6-multilib
pn gcc-6-doc
pn libstdc++6-6-dbg
-- debconf information excluded
Bug#836588: [Cupt-devel] Bug#836588: Bug#836588: cupt: FTBFS on armel/armhf: test failures
On 20.09.2016 16:06, Emilio Pozuelo Monfort wrote:
> On 19/09/16 22:00, Eugene V. Lyubimkin wrote:
>> On 18.09.2016 22:40, Eugene V. Lyubimkin wrote:
>>> Thank you. Turned out it is reproducible in release build (at the least on
>>> armel porterbox), but not in debug build.
>>>
>>> I'll look into it.
>>
>> Ok, something fishy is going on with lambda captures. I believe I found an
>> issue in either std::function or GCC
>> optimizer. Looks like a captured value ("this" in this case) is
>> uninitialized or corrupted, but only if previous lambda
>> captures a certain amount of variables, no matter was it called or not. Ugh.
>> I managed to reduce
>> the code to the following small example:
>
> Cool! Can you file a bug against g++-6 or libstdc++6 (or whatever you think is
> appropriate)? Have you found what optimization flag causes this? If it builds
> with -O1 or disabling some specific optimization, perhaps you can temporarily
> use that to avoid autoremoval from testing.
Sounds good for both points. Indeed, it builds with -O1. I will make a
packaging change and file a bug.
Bug#836588: [Cupt-devel] Bug#836588: Bug#836588: cupt: FTBFS on armel/armhf: test failures
On 18.09.2016 22:40, Eugene V. Lyubimkin wrote:
> Thank you. Turned out it is reproducible in release build (at the least on
> armel porterbox), but not in debug build.
>
> I'll look into it.
Ok, something fishy is going on with lambda captures. I believe I found an
issue in either std::function or GCC
optimizer. Looks like a captured value ("this" in this case) is uninitialized
or corrupted, but only if previous lambda
captures a certain amount of variables, no matter was it called or not. Ugh. I
managed to reduce
the code to the following small example:
(sid_armhf-dchroot)jackyf@harris:~/smalltests/small-std-function-arm$ cat hm.cpp
#include
#include
struct C
{
void doCb()
{
size_t dummy_a = 1;
std::cout << "Outside: " << this << std::endl;
std::function f;
f = [this, _a]()
{};
f = [this]()
{
std::cout << "Inside: " << this << std::endl;
};
f();
}
};
int main()
{
C c;
c.doCb();
}
(sid_armhf-dchroot)jackyf@harris:~/smalltests/small-std-function-arm$ cat
Makefile
all:
g++ -O2 -Wall -Wextra hm.cpp -o hm.e
(sid_armhf-dchroot)jackyf@harris:~/smalltests/small-std-function-arm$ ./hm.e
Outside: 0xbeaeb5f4
Inside: 0x2
(sid_armhf-dchroot)jackyf@harris:~/smalltests/small-std-function-arm$
~/valgrind/valgrind-3.12.0~svn20160714
/vg-in-place ./hm.e
==9628== Memcheck, a memory error detector
==9628== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==9628== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
==9628== Command: ./hm.e
==9628==
Outside: 0xbdb6a454
==9628== Use of uninitialised value of size 4
==9628==at 0x4916BF6: ??? (in
/usr/lib/arm-linux-gnueabihf/libstdc++.so.6.0.22)
==9628==
==9628== Conditional jump or move depends on uninitialised value(s)
==9628==at 0x4916BFC: ??? (in
/usr/lib/arm-linux-gnueabihf/libstdc++.so.6.0.22)
==9628==
==9628== Conditional jump or move depends on uninitialised value(s)
==9628==at 0x49179FA: std::ostreambuf_iterator<char, std::char_traits
> std::num_put<char,
std::ostreambuf_iterator<char, std::char_traits >
>::_M_insert_int(std::ostreambuf_iterator<char,
std::char_traits >, std::ios_base&, char, unsigned long) const (in
/usr/lib/arm-linux-gnueabihf/libstdc++.so.6.0.22)
==9628==by 0x4917AC5: std::num_put<char, std::ostreambuf_iterator<char,
std::char_traits >
>::do_put(std::ostreambuf_iterator<char, std::char_traits >,
>std::ios_base&, char, void const*) const (in
/usr/lib/arm-linux-gnueabihf/libstdc++.so.6.0.22)
==9628==by 0x491FDA3: std::ostream& std::ostream::_M_insert(void const*) (in
/usr/lib/arm-linux-gnueabihf/libstdc++.so.6.0.22)
==9628==
Inside: 0x2
==9628==
==9628== HEAP SUMMARY:
==9628== in use at exit: 0 bytes in 0 blocks
==9628== total heap usage: 2 allocs, 2 frees, 21,248 bytes allocated
==9628==
==9628== All heap blocks were freed -- no leaks are possible
==9628==
==9628== For counts of detected and suppressed errors, rerun with: -v
==9628== Use --track-origins=yes to see where uninitialised values come from
==9628== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0)
Bug#836588: [Cupt-devel] Bug#836588: Bug#836588: cupt: FTBFS on armel/armhf: test failures
Control: -1 tags - unreproducible On 18.09.2016 17:37, Emilio Pozuelo Monfort wrote: >> I cannot reproduce the issue (that is, on the armhf porterbox harris.d.o the >> test suit passes). Any chance that at the >> time of the build some toolchain packages were in an inconsistent shape or >> had know issues? >> >> Can I do anything else with this bug before requesting to give-back the >> package on arhmf and armel? > > I have given them back. Let's see what happens. Thank you. Turned out it is reproducible in release build (at the least on armel porterbox), but not in debug build. I'll look into it.
Bug#836588: [Cupt-devel] Bug#836588: cupt: FTBFS on armel/armhf: test failures
Control: tags -1 + unreproducible Hi Emilio, On 04.09.2016 12:17, Emilio Pozuelo Monfort wrote: > Your package failed to build on armel/armhf. Logs at > https://buildd.debian.org/status/package.php?p=cupt=unstable Thank you for the report. I cannot reproduce the issue (that is, on the armhf porterbox harris.d.o the test suit passes). Any chance that at the time of the build some toolchain packages were in an inconsistent shape or had know issues? Can I do anything else with this bug before requesting to give-back the package on arhmf and armel?
Bug#838203: valgrind: unusable on armhf: assertion 'sizeof(TTEntryC) <= 88' failed
Package: valgrind Version: 1:3.12.0~svn20160714-1+b1 Severity: important Dear Maintainer, I've just attempted to use valgrind on the armel porterbox, harris.debian.org. Here's what I got: ->8 $ valgrind ls ==29583== Memcheck, a memory error detector ==29583== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==29583== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info ==29583== Command: ls ==29583== valgrind: m_transtab.c:2459 (vgPlain_init_tt_tc): Assertion 'sizeof(TTEntryC) <= 88' failed. Segmentation fault -8< -- System Information: Debian Release: 8.0 Architecture: amd64 (x86_64) Kernel: Linux 4.3.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages valgrind depends on (semi-manually compiled list from the porterbox): $ dpkg -l | grep libc ii libc-bin 2.24-2 ii libc-dev-bin 2.24-3 ii libc-l10n 2.24-2 ii libc6:armhf2.24-3 ii libc6-dbg:armhf2.24-3 ii libc6-dev:armhf2.24-3 ii libc6 2.23-1 ii libc6-dbg 2.23-1
Bug#819932: ncdu: counts reflinks multiple times
Control: forwarded -1 https://dev.yorhel.nl/ncdu/bug/86 Hello, Sorry for the late answer. On 04.04.2016 02:07, Adam Borowski wrote: > On filesystems that support copy-on-write, such as btrfs, ocfs2, zfs, ncdu > will count shared space multiple times. I've now reported it to the upstream bug tracker.
Bug#821750: option to follow symlinks
Hello, Sorry for the late response. On 19.04.2016 02:25, Antoine Beaupré wrote: > I understand why ncdu doesn't count symlinks by default, but in some > cases, it would be very useful to do so. My use case is specifically > about git-annex repositories, which make heavy use of symlinks. > > There is a patch in the upstream bugtracker, but the thread has been > inactive for a few years now: > > https://dev.yorhel.nl/ncdu/bug/16 > https://p.blicky.net/j3py5 I understand the use case, but I share Yoran's reasons not to include this patch in its current form. The best case would of course be to convince upstream to write/include one or another proper symlink support. If we as Debian want to diverge from upstream, the patch should, at least, not introduce obvious bugs (counting symlinked stuff more than once) and security problems (recursive symlinks). That means, as upstream outlined, dev/inode table. If someone implements and tests that, I'd be willing to include the patch to the Debian package.
Bug#832159: ITP: qutebrowser -- A keyboard-driven, vim-like browser based on PyQt5.
Hi, > I also intend to package the dependency python3-pypeg2 do I have to write a > seperate > ITP for it? Yes. One ITP per each new (source) package.
Bug#601605: fbreader: Make it a minor bug
Control: severity -1 minor Hello, On 08.04.2016 22:49, Alex Henry wrote: > I actually think this is a bug, not a wishlist item. A program > should be registered to open the files it is able to open. > > Imagine someone without much technical knowledge: reads fbreader > is able to open epub books on the web, installs package and then > fails to open the books/files upon clicking on them. It could > practically make the package unusable on this case. > > Sure it's not a major bug but it's a bug nonetheless. Thank you > for your consideration. Sure, it should be minor now. Thanks for a suggestion. Patches also welcome.
Bug#822796: mpv: seeking with cache in stdin stopped working
Package: mpv Version: 0.14.0-1+b1 Severity: normal Dear Maintainer, When playing a video, when the remote stream is passed as '-' (stdin), seeking (both back and forward) stopped working after an upgrade from 0.9.1-1. I've tried both --hr-seek and without it. The error printed is "Can't seek in this file.". The detailed log: ---8< $ cat cur.flv | mpv --hr-seek=yes --msg-level=all=v - mpv: /usr/lib/x86_64-linux-gnu/liblua5.2.so.0: no version information available (required by mpv) [cplayer] Command line options: '--hr-seek=yes' '--msg-level=all=v' '-' [cplayer] mpv 0.14.0 (C) 2000-2015 mpv/MPlayer/mplayer2 projects [cplayer] built on UNKNOWN [cplayer] ffmpeg library versions: [cplayer]libavutil 54.31.100 [cplayer]libavcodec 56.60.100 [cplayer]libavformat 56.40.101 [cplayer]libswscale 3.1.101 [cplayer]libavfilter 5.40.101 [cplayer]libswresample 1.2.101 (runtime 1.2.100) [cplayer] ffmpeg version: 2.8.6-1+b2 [cplayer] [cplayer] Configuration: ./waf -v configure --prefix=/usr --libdir=/usr/lib/x86_64-linux-gnu --confdir=/etc/mpv --zshdir=/usr/share/zsh/vendor-completions --enable-cdda --enable-sdl2 --enable-sndio --enable-zsh-comp --enable-libmpv-shared --disable-build-date [cplayer] List of enabled features: alsa asm atomics audio-input av-pix-fmt-mmal av-version-info avcodec-chroma-pos-api avframe-metadata avframe-skip-samples c11-tls cdda cplayer debug-build dlopen drm dvbin dvdnav dvdread egl-x11 enca encoding fchmod gl gl-wayland gl-x11 glibc-thread-name glob iconv jack jpeg lcms2 libass libass-osd libav libavdevice libavfilter libbluray libdl libguess libm libmpv-shared librt libswresample linux-fstatfs lua nanosleep optimize oss-audio oss-audio-native posix posix-or-mingw posix-spawn pthreads pulse resampler rubberband sdl2 shm sndio sse4-intrinsics stdatomic subprocess termios tv tv-v4l2 vaapi vaapi-egl vaapi-glx vaapi-hwaccel vaapi-wayland vaapi-x-egl vaapi-x11 vdpau vdpau-gl-x11 vdpau-hwaccel videodev vt.h wayland x11 xext xinerama xrandr xss xv zlib zsh-comp [global] config path: '' -> '/home/jackyf/.config/mpv' [global] config path: 'mpv.conf' -/-> '/home/jackyf/.config/mpv/mpv.conf' [global] config path: 'config' -> '/home/jackyf/.config/mpv/config' [global] config path: 'mpv.conf' -/-> '/home/jackyf/.mpv/mpv.conf' [global] config path: 'config' -/-> '/home/jackyf/.mpv/config' [global] config path: 'mpv.conf' -/-> '/etc/mpv/mpv.conf' [global] config path: 'config' -/-> '/etc/mpv/config' [cplayer] Reading config file /home/jackyf/.config/mpv/config [cplayer] Setting option 'no-audio-display' = '' (flags = 4) [cplayer] Setting option 'force-window' = '' (flags = 4) [cplayer] Setting option 'softvol-max' = '400' (flags = 4) [cplayer] Setting option 'vo' = 'xv' (flags = 4) [cplayer] Setting option 'hr-seek' = 'yes' (flags = 4) [cplayer] Setting option 'hr-seek' = 'yes' (flags = 8) [cplayer] Setting option 'msg-level' = 'all=v' (flags = 8) [global] config path: 'input.conf' -/-> '/home/jackyf/.config/mpv/input.conf' [global] config path: 'input.conf' -/-> '/home/jackyf/.mpv/input.conf' [global] config path: 'input.conf' -/-> '/etc/mpv/input.conf' [input] Falling back on default (hardcoded) input config [osc] Loading script @osc.lua... [global] config path: 'scripts' -/-> '/home/jackyf/.config/mpv/scripts' [global] config path: 'scripts' -/-> '/home/jackyf/.mpv/scripts' [global] config path: 'scripts' -/-> '/etc/mpv/scripts' [osc] loading mp.defaults [osc] loading @osc.lua [global] config path: 'lua-settings/osc.conf' -/-> '/home/jackyf/.config/mpv/lua-settings/osc.conf' [global] config path: 'lua-settings/osc.conf' -/-> '/home/jackyf/.mpv/lua-settings/osc.conf' [global] config path: 'lua-settings/osc.conf' -/-> '/etc/mpv/lua-settings/osc.conf' [osc] lua-settings/osc.conf not found. [cplayer] Run command: define-section, flags=0, args=[showhide, mouse_move script-binding osc/__keybinding1 [cplayer] mouse_leave script-binding osc/__keybinding2 [cplayer] , force] [cplayer] Run command: enable-section, flags=0, args=[showhide, allow-hide-cursor+allow-vo-dragging] [cplayer] Run command: define-section, flags=0, args=[input, mouse_btn0 script-binding osc/__keybinding3 [cplayer] shift+mouse_btn0 script-binding osc/__keybinding4 [cplayer] mouse_btn2 script-binding osc/__keybinding5 [cplayer] mouse_btn0_dbl ignore [cplayer] shift+mouse_btn0_dbl ignore [cplayer] mouse_btn2_dbl ignore [cplayer] del script-binding osc/__keybinding6 [cplayer] , force] [cplayer] Run command: enable-section, flags=0, args=[input, ] [cplayer] Run command: disable-section, flags=0, args=[input] [cplayer] Done loading @osc.lua. [ytdl_hook] Loading script @ytdl_hook.lua... [global] config path: 'scripts' -/-> '/home/jackyf/.config/mpv/scripts' [global] config path: 'scripts' -/-> '/home/jackyf/.mpv/scripts' [global] config path: 'scripts' -/-> '/etc/mpv/scripts' [ytdl_hook] loading mp.defaults [ytdl_hook] loading @ytdl_hook.lua
Bug#814722: xserver-xorg-video-intel: blank screen with cursor when trying to open a second screen
Package: xserver-xorg-video-intel Version: 2.99.917+git20160218-1 Followup-For: Bug #814722 Dear Maintainer, I am not sure this is the same bug, but I get similar symptoms when I try to open a second X screen by using 'kdmctl reserve'. When I do this, the screen goes to blank black with a blinking cursor, and I cannot switch to any X screen or VT consoles anymore, only reboot helps. I verified this happens on my system with the current unstable and testing versions of xserver-xorg/video-intel, and this doesn't happen when I downgrade it back to jessie version. I'd happy to provide an additional info. -- System Information: Debian Release: 8.0 Architecture: amd64 (x86_64) Kernel: Linux 4.3.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages xserver-xorg-video-intel depends on: ii libc6 2.21-8 ii libdrm-intel1 2.4.65-3 ii libdrm22.4.65-3 ii libpciaccess0 0.13.2-3+b1 ii libpixman-1-0 0.32.6-3 ii libudev1 215-12 ii libx11-6 2:1.6.3-1 ii libx11-xcb12:1.6.3-1 ii libxcb-dri2-0 1.10-3+b1 ii libxcb-util0 0.3.8-3 ii libxcb11.10-3+b1 ii libxv1 2:1.0.10-1+b1 ii libxvmc1 2:1.0.8-2+b1 ii xserver-xorg-core [xorg-video-abi-18] 2:1.16.4-1 xserver-xorg-video-intel recommends no packages. xserver-xorg-video-intel suggests no packages. -- no debconf information
Bug#815401: dh_makeshlibs: man page still speaks about postinst and postrm, not triggers
Package: debhelper Version: 9.20150507 Severity: minor Dear Maintainer, Since recently, dh_makeshlibs does not generated postinst and postrm files anymore to call ldconfig, but a dpkg trigger instead. The description in the man page still speaks about the old way. This can be confusing especially if using older lintian which produces an error if it doesn't see postrm/postinst, since nothing suggests to a maintainer that it isn't a bug in dh_makeshlibs. Please modify the man page accordingly. Thanks! -- System Information: Debian Release: 8.0 Architecture: amd64 (x86_64) Kernel: Linux 4.3.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages debhelper depends on: ii binutils 2.25-5 ii dpkg 1.17.24 ii dpkg-dev 1.17.24 ii file 1:5.22+15-1 ii libdpkg-perl 1.17.24 ii man-db2.7.0.2-5 ii perl 5.20.2-6 ii po-debconf1.0.16+nmu3 debhelper recommends no packages. Versions of packages debhelper suggests: pn dh-make -- no debconf information
Bug#695263: mutt: segfault on synchronizing imap mailbox after joining threads
Hello Antonio, On 14.02.2016 13:00, Antonio Radici wrote: > this does not seem reproducible anymore on 1.5.24-1, could you please check if > that's still the case? I don't use mutt setups anymore, so I guess this bug can be closed for the time being. If I see this happening at newer mutts at some point, I'd re-open it then.
Bug#813768: fbreader: installation does not create a launch menu entry
Control: tags -1 + gift Hello, On 05.02.2016 07:50, john wrote: > on my system it seems like the installation of the fbreader package does not > create a application launch menu entry for FBReader. Thank you for the report. The FBReader is not actively maintained in the moment, so patches welcome.
Bug#808074: RFA: fbreader -- e-book reader
Package: wnpp Severity: normal Hello, I request an adopter for the fbreader package, since I don't use it actively anymore. The package description is: FBReader is an e-book reader. . Main features: * supports several open e-book formats: fb2, html, chm, plucker, palmdoc, ztxt, tcr (psion text), rtf, oeb, openreader, non-DRM'ed mobipocket, plain text, epub, eReader * reads directly from tar, zip, gzip, bzip2 archives (you can have several books in one archive) * supports a structured view of your e-book collection * automatically determines encodings * automatically generates a table of contents * keeps the last open book and the last read positions for all open books between runs * automatic hyphenation (patterns for several languages are included) * searching and downloading books from www.feedbooks.com and www.litres.ru * partial CSS support for epub files
Bug#807074: fbreader: includes files with unclear DFSG-freeness and/or copyright status
On 14.12.2015 22:56, Francesco Poli wrote: > Well, they themselves say that one of the files under consideration is > > | Derived, in part, from: > | > |* iso-pub.gml > | > |Copyright (C) 1986 International Organization for Standardization > |Permission to copy in any form is granted for use with > |conforming SGML systems and applications as defined in > |ISO 8879, provided this notice is included in all copies. > > and similarly for other files. > > Hence, they basically say that some OASIS files (that they distribute > under DFSG-free terms) are derived, in part, from some ISO files which > do *not* grant any permission to modify. > > Without any additional explanation, this sounds like a copyright > violation. Here our interpretations diverge then. Indeed it's always allowed to suspect, but I'd much prefer that a RC bug is filed after those suspects are confirmed. >> If they say 'yes', how one is >> supposed to verify that they really do? > > A simple "yes" answer would not suffice: they need to provide a > convincing explanation... Out of curiosity, what can that be? > Dropping the OASIS files from package fbreader is the last resort > solution, assuming that those files are not strictly needed for the > package to provide significant functionality. If a violation is present, this will be my first resort, otherwise fbreader will disappear from testing very quickly. Between absense of fbreader and worse DocBook format support in fbreader, I choose second. Ad plug: should anyone see a better action course, fbreader is open for adoption. > Please note that, as I have previously said, one FTP Assistant > confirmed that files under the ISO license are not fit for Debian main: > https://lists.debian.org/debian-legal/2015/12/msg0.html I don't read that as something I can directly apply for things under OASIS copyright. Of course I might be wrong, that's why I invited Debian archive masters to the loop. No reason for us to argue any longer, let's just wait for what they think. If those files are unfree, there were in the archive for 7+ years and can wait few days I presume. signature.asc Description: OpenPGP digital signature
Bug#795522: fbreader (dbtoepub: Not formattig docbook tables using )
Hello, Thank you for the report and investigation. Upstream development for Unix version of FBReader is practically stopped for years now. Patches for Debian package are welcome, though. -- Eugene V. Lyubimkin aka JackYF C++ GNU/Linux userspace developer, Debian Developer
Bug#797199: [Cupt-devel] Bug#797199: cupt must use the default C++ ABI
Control: tags -1 + pending Hello, On 28.08.2015 16:16, Matthias Klose wrote: Please revert. boost 1.58 was built using GCC 5 from the start. Maybe, but the default one (1.55?) was not back then. Anyway, the modified version is already in ftp-NEW [1]. [1] https://ftp-master.debian.org/new/cupt_2.9.3.html -- Eugene V. Lyubimkin aka JackYF C++ GNU/Linux userspace developer, Debian Developer
Bug#796273: [Cupt-devel] Bug#796273: cupt: segfault when install any package
Control: forcemerge 794430 -1 Control: tags -1 + fixed-upstream Hello! On 21.08.2015 01:24, cupt report wrote: cupt segfault when i try to install any package: [...] D: on request 'install cupt-dbg | for package 'cupt-dbg'' strictly satisfying relation 'cupt-dbg (=== 2.8.4)' Resolving possible unmet dependencies... D: started resolving D: ignoring soft dependency relation: gettext 0.19.3-2^installed: recommends 'autopoint' D: ignoring soft dependency relation: gettext 0.19.3-2^installed: recommends 'libasprintf-dev' D: ignoring soft dependency relation: gettext 0.19.3-2^installed: recommends 'libgettextpo-dev' D: ignoring soft dependency relation: gnupg 1.4.18-7^installed: recommends 'gnupg-curl' D: ignoring soft dependency relation: gtk2-engines-murrine 0.98.1.1-5^installed: recommends 'murrine-themes (= 0.98)' D: ignoring soft dependency relation: iceweasel-l10n-ru 1:31.8.0esr-1~deb8u1^installed: recommends 'myspell-ru' D: ignoring soft dependency relation: iproute2 3.16.0-2^installed: recommends 'libatm1 (= 2.4.1-17~)' D: ignoring soft dependency relation: libcap2-bin 1:2.24-8^installed: recommends 'libpam-cap' Ошибка сегментирования and segfault when i try to look at policy of some package: root@x200:~# cupt policy libc6 Ошибка сегментирования Thank you for the report and your interest. I have now a fix for it, and cupt won't segfault anymore. Though, since your system is multi-arch'ed (which was the segfault reason), right now Cupt won't be of big use anyway. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf(maildog)jabber.fsfe.org C++ GNU/Linux userspace developer, Debian Developer
Bug#795776: [htop] Excessive memory usage reported compared to free, conky
Control: tags -1 - moreinfo Control: tags -1 + upstream Control: forwarded -1 https://github.com/hishamhm/htop/issues/242 Hello, On 17.08.2015 23:45, OmegaPhil wrote: omega@omega1:~/.config/xfce4/panel$ free totalusedfree shared buff/cache available Mem: 32998636 9515852 466464 26363223016320 22807536 Swap: 10485756 010485756 free is '/usr/bin/free': [...] I see now, an output format of 'free' changed in sid, I get similar now after I have installed a newer version. Atm htop reports 12550/32225MB used. Yes, I see that numbers don't match exactly on your system. I forwarded your report upstream. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf(maildog)jabber.fsfe.org C++ GNU/Linux userspace developer, Debian Developer
Bug#795776: [htop] Excessive memory usage reported compared to free, conky
Control: tags -1 + moreinfo unreproducible Hello! == total usedfree shared buff/cache available Mem: 32998636 9011192 1532280 273112 22455164 23306740 Swap: 10485756 0 10485756 == In this full output? Could you re-check? Htop outputs what free describes in '-/+ buffers/cache' column, but I don't see it in the output you pasted. They match on my system. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf(maildog)jabber.fsfe.org C++ GNU/Linux userspace developer, Debian Developer
Bug#794430: [Cupt-devel] Bug#794430: Bug#794430: Bug#794430: cupt: Trying to install a uninstallable package, and not error is show
Control: tags -1 + confirmed upstream Control: retitle -1 crash on more than one installed version for a package in dpkg status file Hello, On 09.08.2015 22:41, Javier Barroso wrote: I'm attaching tar-metadata, if with attachment doesn't work, I will search another method It worked, thanks, and I managed to reproduce the problem. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf(maildog)jabber.fsfe.org C++ GNU/Linux userspace developer, Debian Developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#794430: [Cupt-devel] Bug#794430: Bug#794430: Bug#794430: cupt: Trying to install a uninstallable package, and not error is show
Hi! On 04.08.2015 17:22, Javier Barroso wrote: Yes, I'm attaching bt full (from cupt install sl) Many thanks, it revealed that certain data inconsistency happens which leads to a crash. I however still cannot reproduce it without more data. Would it be possible for you to send me (perhaps privately) the output of 'cupt tar-metadata | xz -c y.tar.xz' command? With some luck it might fit the mail attachment limits. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf(maildog)jabber.fsfe.org C++ GNU/Linux userspace developer, Debian Developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#794430: [Cupt-devel] Bug#794430: Bug#794430: cupt: Trying to install a uninstallable package, and not error is show
Control: severity -1 important Hi Javier, On 04.08.2015 00:18, Javier Barroso wrote: $ sudo cupt -o debug::resolve=yes install gnome-shell There is no log becaused you missed one 'r'. It's resolver, not resolve. Could you try? Why sudo is not showing me Violación de segmento? That's a good question indeed. At gdb: Program received signal SIGSEGV, Segmentation fault. 0x77aa9378 in boost::xpressive::detail::tracking_ptrboost::xpressive::detail::regex_implchar const* ::get (this=this@entry=0xfc5268) at /usr/include/boost/xpressive/detail/utility/tracking_ptr.hpp:430 430if(intrusive_ptrelement_type impl = this-fork_()) Ack, thanks, that gives the first pointer to Boost.Xpressive library, will test in unstable. Could you also install 'cupt-dbg' package, then launch the gdb, wait for segmentation fault, type 'bt full' and paste the full backtrace here? The same behaviour with any package: # cupt install cupt # cupt install sl # sl is not installed Ack, so it was not related to a specific package. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf(maildog)jabber.fsfe.org C++ GNU/Linux userspace developer, Debian Developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#794430: [Cupt-devel] Bug#794430: cupt: Trying to install a uninstallable package, and not error is show
Hi Javier, Thank you for the report. Indeed, it's looks like a bug if cupt didn't print any reason. On 03.08.2015 01:26, Javier Barroso wrote: Currently on sid (last apt full-upgrade, removed gnome-shell, there is a dependency which cannot be satisfied). There is a verbose / debug flag on cupt? Yes, there is, add -o debug::resolver=yes for this case. Could you try it and send the log? -- Eugene V. Lyubimkin aka JackYF, JID: jackyf(maildog)jabber.fsfe.org C++ GNU/Linux userspace developer, Debian Developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#794331: daptup: insane amounts of output on upgrades from testing or jessie to sid
On 01.08.2015 21:34, Andreas Beckmann wrote: Thanks for the explanation. I'll see how I can handle this in piuparts properly. You don't have any debconf question I could preseed to configure this? No. One more option is maybe you could get rid of the daptup hook using dpkg path filtering (didn't use it myself, man page suggests something like '--path-exclude=/etc/apt/apt.conf.d/11daptup'). -- Eugene V. Lyubimkin aka JackYF, JID: jackyf(maildog)jabber.fsfe.org C++ GNU/Linux userspace developer, Debian Developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793106: htop: Some processes running seem to be ‘hidden’ (i.e not showing - except when highlighted)
Hello, Thank you for the report, On 21.07.2015 13:54, Jean-Samuel Christophe wrote: I unfortunately cannot provide more info on when this occured as I do not use htop constantly but things were working fine untill very recently. This definitely looks like a bug. Let us try to pin-point the culprit: - Did you remember when it started to happen? Did you do any package upgrades at that time? Changes and dates could be looked up from e.g. /var/log/dpkg.log. - Does it happen every time or randomly? If you launch htop and exit it several times, are the same lines unvisible or different ones? - Does it work any better if you restart your terminal application? - Does it work in another terminals (like e.g. xterm, konsole, native tty)? - Does it work better in monochrome mode (htop -C)? - In case you have several servers with similar software, does this problem appear on all of them or one machine only? -- Eugene V. Lyubimkin aka JackYF, JID: jackyf(maildog)jabber.fsfe.org C++ GNU/Linux userspace developer, Debian Developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#791031: fbreader: library transition may be needed when GCC 5 is the default
Control: tag -1 + patch
Control: user release.debian@packages.debian.org
Control: usertag -1 + transition
Control: block -1 by 790756
Control: reassign -1 release.debian.org
Proposed patch attached.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf(maildog)jabber.fsfe.org
C++ GNU/Linux userspace developer, Debian Developer
diff --git a/debian/changelog b/debian/changelog
index 55c2f28..1faecad 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,14 @@
+fbreader (0.12.10dfsg-10) unstable; urgency=low
+
+ * NMU acknowledged - thanks, OndÅej!
+ * debian/control:
+- Bump ABI parts of libzlcore and libzltext package names for GCC5 C++11
+ ABI transition. For historical reasons these package name parts were
+ actually a bit off the SONAMEs, and now it's a good time to fix it.
+ (Closes: #763468)
+
+ -- Eugene V. Lyubimkin jac...@debian.org Tue, 21 Jul 2015 20:52:34 +0300
+
fbreader (0.12.10dfsg-9.1) unstable; urgency=medium
* Change B-D to libjpeg-dev to finish the transition to libjpeg-turbo
diff --git a/debian/control b/debian/control
index 10872e4..9a22a3c 100644
--- a/debian/control
+++ b/debian/control
@@ -34,10 +34,12 @@ Description: e-book reader
* searching and downloading books from www.feedbooks.com and www.litres.ru
* partial CSS support for epub files
-Package: libzlcore0.12
+Package: libzlcore0.13
Section: libs
Architecture: any
Depends: ${misc:Depends}, ${shlibs:Depends}, libzlcore-data (= ${source:Version})
+Breaks: libzlcore0.12
+Replaces: libzlcore0.12
Conflicts: fbreader-gtk, fbreader-qt, fbreader-qt4
Description: ZLibrary cross-platform development library (shared library)
This is the core of ZLibrary, the library that the fbreader e-book reader
@@ -59,11 +61,13 @@ Description: ZLibrary cross-platform development library (support files)
ZLibrary is a cross-platform library to build applications running on desktop
Linux, Windows, different Linux-based PDAs using this library.
-Package: libzltext0.12
+Package: libzltext0.13
Section: libs
Architecture: any
-Depends: ${misc:Depends}, ${shlibs:Depends}, libzlcore0.12 (= ${binary:Version}),
+Depends: ${misc:Depends}, ${shlibs:Depends}, libzlcore0.13 (= ${binary:Version}),
libzltext-data (= ${source:Version})
+Breaks: libzltext0.12
+Replaces: libzltext0.12
Description: ZLibrary text model/viewer part (shared library)
This package provides text model/viewer part of ZLibrary. See also
libzlcore0.10 package.
@@ -87,7 +91,7 @@ Description: ZLibrary text model/viewer part (support files)
Package: libzlui-gtk
Section: libs
Architecture: any
-Depends: ${misc:Depends}, ${shlibs:Depends}, libzlcore0.12 (= ${binary:Version})
+Depends: ${misc:Depends}, ${shlibs:Depends}, libzlcore0.13 (= ${binary:Version})
Suggests: ttf-unifont
Description: GTK+ interface module for ZLibrary
This package provides a GTK+-based UI for ZLibrary.
@@ -98,7 +102,7 @@ Description: GTK+ interface module for ZLibrary
Package: libzlui-qt4
Section: libs
Architecture: any
-Depends: ${misc:Depends}, ${shlibs:Depends}, libzlcore0.12 (= ${binary:Version})
+Depends: ${misc:Depends}, ${shlibs:Depends}, libzlcore0.13 (= ${binary:Version})
Description: Qt4 interface module for ZLibrary
This package provides a Qt4-based UI for ZLibrary.
.
@@ -108,7 +112,7 @@ Description: Qt4 interface module for ZLibrary
Package: libzlcore-dev
Section: libdevel
Architecture: any
-Depends: ${misc:Depends}, ${shlibs:Depends}, libzlcore0.12 (= ${binary:Version})
+Depends: ${misc:Depends}, ${shlibs:Depends}, libzlcore0.13 (= ${binary:Version})
Description: ZLibrary cross-platform development library (development files)
This package contains development files for the ZLibrary core.
.
@@ -118,7 +122,7 @@ Description: ZLibrary cross-platform development library (development files)
Package: libzltext-dev
Section: libdevel
Architecture: any
-Depends: ${misc:Depends}, ${shlibs:Depends}, libzltext0.12 (= ${binary:Version})
+Depends: ${misc:Depends}, ${shlibs:Depends}, libzltext0.13 (= ${binary:Version})
Description: ZLibrary text model/viewer part (development files)
This package contains development files for the ZLibrary text model/viewer
library.
diff --git a/debian/libzlcore0.12.dirs b/debian/libzlcore0.12.dirs
deleted file mode 100644
index 6845771..000
--- a/debian/libzlcore0.12.dirs
+++ /dev/null
@@ -1 +0,0 @@
-usr/lib
diff --git a/debian/libzlcore0.13.dirs b/debian/libzlcore0.13.dirs
new file mode 100644
index 000..6845771
--- /dev/null
+++ b/debian/libzlcore0.13.dirs
@@ -0,0 +1 @@
+usr/lib
diff --git a/debian/libzltext0.12.dirs b/debian/libzltext0.12.dirs
deleted file mode 100644
index 6845771..000
--- a/debian/libzltext0.12.dirs
+++ /dev/null
@@ -1 +0,0 @@
-usr/lib
diff --git a/debian/libzltext0.13.dirs b/debian/libzltext0.13.dirs
new file mode 100644
index 000..6845771
--- /dev/null
+++ b/debian/libzltext0.13.dirs
@@ -0,0 +1 @@
+usr/lib
diff --git a/debian/rules b/debian/rules
index db5c6f2
Bug#789267: libgtest-dev: inconsistency with GTEST_HAS_PTHREAD in library interface leads to crashes on non-linux
Control: tags -1 + patch
Hi!
Finally got to this one,
On 24.06.2015 06:43, Steve M. Robbins wrote:
Current libgtest-dev has two different means to determine if
GTEST_HAS_PTHREAD is defined: one in CMake rules [1] and second one in
the header [2]. When they don't match [3],
I have never used the CMake files, but in /usr/src/gtest/CMakeLists.txt, I
see:
config_compiler_and_linker() # Defined in internal_utils.cmake.
and as far as I can see, that macro unconditionally defines GTEST_HAS_PTHREAD
in cxx_base_flags. As long as the build uses these flags, it will override
the
logic in the header.
So I don't see the issue. Can you elaborate further?
Sure. Those flags are used for compiling libgtest, yes, but not for anything
else that links to libgtest.
For each target, CMake maintains two sets of compile definitions: one it uses
for compiling the target itself, and
another one which is passed (transitively unless specified otherwise) to
targets which link themselves to this one. And
the second one is missing.
If you prefer, I can try to produce a patch.
Yes, patch is always nice.
Ack, a patch and a test case attached.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf(maildog)jabber.fsfe.org
C++ GNU/Linux userspace developer, Debian Developer
--- gt-cmakelists 2015-07-18 16:17:22.150909549 +0300
+++ /usr/src/gtest/CMakeLists.txt 2015-07-18 16:53:53.725776982 +0300
@@ -68,6 +68,7 @@
# are used for other targets, to ensure that gtest can be compiled by a user
# aggressive about warnings.
cxx_library(gtest ${cxx_strict} src/gtest-all.cc)
+target_compile_options(gtest INTERFACE ${cxx_public})
cxx_library(gtest_main ${cxx_strict} src/gtest_main.cc)
target_link_libraries(gtest_main gtest)
--- gt-internal-utils 2015-07-18 16:30:19.190762682 +0300
+++ /usr/src/gtest/cmake/internal_utils.cmake 2015-07-18 16:58:22.703110769 +0300
@@ -42,6 +42,11 @@
endif()
endmacro()
+macro(set_public_compiler_definitions)
+ string(REGEX MATCHALL -DGTEST_HAS_[^ ]*( |$) list_of_definitions ${cxx_default})
+ string(REPLACEcxx_public ${list_of_definitions})
+endmacro()
+
# Defines the compiler/linker flags used to build Google Test and
# Google Mock. You can tweak these definitions to suit your need. A
# variable's value is empty before it's explicitly assigned to.
@@ -120,6 +125,7 @@
# For building the gtest libraries.
set(cxx_strict ${cxx_default} ${cxx_strict_flags})
+ set_public_compiler_definitions()
endmacro()
# Defines the gtest gtest_main libraries. User tests should link
testcase.tar.gz
Description: application/gzip
Bug#789267: libgtest-dev: inconsistency with GTEST_HAS_PTHREAD in library interface leads to crashes on non-linux
Package: libgtest-dev Version: 1.7.0-3 Severity: normal Dear Maintainer, Current libgtest-dev has two different means to determine if GTEST_HAS_PTHREAD is defined: one in CMake rules [1] and second one in the header [2]. When they don't match [3], the static library and the client code might be compiled with different value of this define. This, in turn, leads to the crashes because the definition of ThreadLocal class are different depending on the value of GTEST_HAS_PTHREAD. A possible solution would be to always declare CMake-determined defines as a public interface of gtest target, so everything which links gtest will get those defines as well. For this case, something along the lines target_compile_definitions(gtest PUBLIC -DGTEST_HAS_PTHREAD) If you prefer, I can try to produce a patch. [1] /usr/src/gtest/cmake/internal_utils.cmake:108 [2] /usr/include/gtest/internal/gtest-port.h:(473-481) [3] e.g. on our non-linux architectures -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#789186: libgtest-dev: death tests missing on kfreebsd-*
Hello again, Judging from the changelog entries from 2013-2014, death test didn't work on kfreebsd. If that's still the case, sorry for the extra trouble and this case can be closed. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf(maildog)jabber.fsfe.org C++ GNU/Linux userspace developer, Debian Developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#789186: libgtest-dev: death tests missing on kfreebsd-*
Package: libgtest-dev Version: 1.7.0-3 Severity: normal Dear Maintainer, Death tests (e.g. GTEST_HAS_DEATH_TEST) seem to be not provided on kfreebsd-* architectures [1]. Looking at the source code [2], seems like it could be supported but a FreeBSD-specific OS define is missing. Please add if possible. Thanks for considering and thanks for maintaining GTest! [1] https://buildd.debian.org/status/fetch.php?pkg=cppformatarch=kfreebsd-amd64ver=1.1.0%2Bds-1stamp=1434646285 [2] /usr/include/gtest/internal/gtest-port.h:641: | // Determines whether to support death tests. | // Google Test does not support death tests for VC 7.1 and earlier as | // abort() in a VC 7.1 application compiled as GUI in debug config | // pops up a dialog window that cannot be suppressed programmatically. | #if (GTEST_OS_LINUX || GTEST_OS_CYGWIN || GTEST_OS_SOLARIS || \ | (GTEST_OS_MAC !GTEST_OS_IOS) || GTEST_OS_IOS_SIMULATOR || \ | (GTEST_OS_WINDOWS_DESKTOP _MSC_VER = 1400) || \ | GTEST_OS_WINDOWS_MINGW || GTEST_OS_AIX || GTEST_OS_HPUX || \ | GTEST_OS_OPENBSD || GTEST_OS_QNX) | # define GTEST_HAS_DEATH_TEST 1 | # include vector // NOLINT | #endif -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787330: google-mock: please provide the wrapper package libgmock-dev for uniformity
Package: google-mock Version: 1.7.0-18092013-1 Severity: wishlist Dear Maintainer, As the C/C++ libraries usually reside in 'libxyz-dev' packages, please provide 'libgmock-dev' binary package (which would depend on current 'google-mock' binary package). Thank you for maintaining the package! -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages google-mock depends on: ii libgtest-dev 1.7.0-3 pn python:anynone google-mock recommends no packages. google-mock suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785408: ITP: cppformat -- fast type-safe C++ formatting library
Package: wnpp Severity: wishlist Owner: Eugene V. Lyubimkin jac...@debian.org * Package name: cppformat Version : 1.1.0 Upstream Author : Victor Zverovich victor.zverov...@gmail.com * URL : http://cppformat.github.io/ * License : BSD 2-clause Programming Lang: C++ Description : fast type-safe C++ formatting library This library provides fast, type-safe, small, C++11-aware replacement of (s)printf and related machinery. In some cases it's noticeably faster than boost::format, boost::lexical_cast and even sprintf itself. (http://zverovich.net/2013/09/07/integer-to-string-conversion-in-cplusplus.html) I plan to maintain it myself, unless someone wants to take it under a bigger umbrella. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783893: htop: Crashes with very specific input (fixed upstream)
Hello! On 01.05.2015 03:52, David McMackins wrote: This is fixed in htop version 1.0.4, so it just needs an update. Steps: - Open htop - Strike F4 to do a process search - Type at least one letter into the search - Strike End, Home, then End again Thank you for the report. According to all my sources, latest released version of htop is still 1.0.3. I will consider packaging the Git snapshot, but I'd prefer to wait for a proper released version. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf(maildog)jabber.fsfe.org C++ GNU/Linux userspace developer, Debian Developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782636: Feature request: add an ELAPSED column
Control: tags -1 upstream Control: forwarded -1 https://github.com/hishamhm/htop/issues/187 Hello, On 15.04.2015 12:53, Stéphane Glondu wrote: It would be nice if htop had the possibility to output the time elapsed since the start of a process (as ps -o etime does). Attached is a patch that implements this feature. It is probably not optimal, but it is a proof of concept that it is possible. Thank you for the proposal, I just forwarded it upstream. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf(maildog)jabber.fsfe.org C++ GNU/Linux userspace developer, Debian Developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#777576: [Cupt-devel] Bug#777576: cupt: please make the build reproducible
Control: tags -1 + confirmed Hi, 2015-02-10 02:13, Chris Lamb: The attached patch removes timestamps from the build system. Once applied, cupt can be built reproducibly in our current experimental framework. [1]: https://wiki.debian.org/ReproducibleBuilds Ack, thanks, will be applied. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776818: Temperature and fan speed meters?
Control: tags -1 upstream Control: forwarded -1 https://github.com/hishamhm/htop/issues/163 Hi! 2015-02-01 20:13, Josh Triplett: I'd love to have a meter (preferably combined) for current temperature and fan speed. That would help when monitoring a system with overheating problems. Thank you for the report, I just forwarded this upstream. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf(maildog)jabber.fsfe.org C++ GNU/Linux userspace developer, Debian Developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776804: gnupg2: scdaemon is called in a way that its syslog-style logs are printed to stdout
Package: gnupg2 Version: 2.0.26-4 Severity: normal Hello, I tried to use gpg2 with a smart card. It works (which is great!), but the console noise of scdaemon is rather annoying: ---8-- $ gpg2 --card-status scdaemon[27603]: reading public key failed: Missing item in object [ ... card data ... ] scdaemon[27603]: updating slot 0 status: 0x-0x0007 (0-1) $ scdaemon[27603]: scdaemon (GnuPG) 2.0.26 stopped $ ---8-- Same thing with 'gpg2 --decrypt'. Additionally, when used with pinentry-curses, scdaemon sometimes partially overwrites its screen messages. It would be nice if scdaemon, by default, doesn't print those debugging messages. -- System Information: Debian Release: 6.0.5 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.13-1-amd64 (SMP w/2 CPU cores) Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages gnupg2 depends on: ii dpkg 1.17.6 ii gnupg-agent 2.0.26-4 ii libassuan0 2.1.0-1 ii libbz2-1.0 1.0.6-4 ii libc62.19-13 ii libcurl3-gnutls 7.26.0-1 ii libgcrypt20 1.6.2-3 ii libgpg-error01.17-3 ii libksba8 1.3.0-2 ii libreadline6 6.2-8 ii zlib1g 1:1.2.7.dfsg-13 Versions of packages gnupg2 recommends: ii libldap-2.4-2 2.4.31-1 Versions of packages gnupg2 suggests: pn gnupg-doc none pn parcimonie none pn xloadimage none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774930: htop shows IORW. Man page says IO
Control: tags -1 upstream confirmed Control: forwarded -1 https://github.com/hishamhm/htop/issues/160 Hello! Thank you for the additional comments, now I see you point. I just forwarded the issue upstream. Thank you for the report! -- Eugene V. Lyubimkin aka JackYF, JID: jackyf(maildog)jabber.fsfe.org C++ GNU/Linux userspace developer, Debian Developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774930: htop shows IORW. Man page says IO
Control: tags -1 + moreinfo Hello, IORW can be confused with IOWR, but both seems okay as long as the they match what says in the man page as searching IORW in the man page shows nothing Hmm, here's from the htop man page I have: IO_READ_RATE (IORR) The I/O rate of read(2) in bytes per second, for the process. IO_WRITE_RATE (IOWR) The I/O rate of write(2) in bytes per second, for the process. IO_RATE (IO) The I/O rate, IO_READ_RATE + IO_WRITE_RATE (see above). In htop output columns, I have exactly 'IORR' and 'IOWR'. Could you please elaborate where did you see 'IORW'? -- Eugene V. Lyubimkin aka JackYF, JID: jackyf(maildog)jabber.fsfe.org C++ GNU/Linux userspace developer, Debian Developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773186: qprint: infinite loop on invalid input
Hello Jakub, 2014-12-15 13:05, Jakub Wilk: $ printf '= ' | qprint -d Error: invalid character 0x in soft line break sequence at byte 1 (0x1) of input. Error: invalid character 0x in soft line break sequence at byte 1 (0x1) of input. Error: invalid character 0x in soft line break sequence at byte 1 (0x1) of input. Error: invalid character 0x in soft line break sequence at byte 1 (0x1) of input. Error: invalid character 0x in soft line break sequence at byte 1 (0x1) of input. [...ad infinitum...] Thank you for report (this and previous). The upstream seems be quite inactive and without public contacts (last release in 2001). I nevertheless just tried to reach / forward the bugs by mail, let's see what happens. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf(maildog)jabber.fsfe.org C++ GNU/Linux userspace developer, Debian Developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#772558: [Cupt-devel] Bug#772558: libcupt3-0: why chooses irrelevant dependency
Control: tags -1 + confirmed Hi James, 2014-12-08 09:43, James McCoy: [...] Since info has a direct Depends relationship on install-info, I would expect that to be reported rather than the alternative relationship that cgdb has, especially since cgdb's primary alternative (dpkg = 1.15.4) is satisfied. True, this can be improved. Thank you for the report, added to the TODO list. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++ GNU/Linux userspace developer, Debian Developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766758: apt: does not process pending triggers
Hello! [ some CC's dropped, please tell if I missed someone ] Did not touch trigger stuff for a while, let's see if I catched up what happens here: 2014-11-15 00:28, Guillem Jover: [...] Only apt seems to be affected. dselect properly uses “dpkg transactions” and as such queues all configuration in a final «--configure --pending» call. And cupt seems to behave correctly by calling dpkg with «--triggers-only --pending», but Eugene might know for sure. Cupt calls '--triggers-only --pending' in the end of run when trigger deferring (i.e. '--no-triggers') is enabled, which is the default (both in wheezy and jessie). Do I read your explanation [1] correctly that '--triggers-only --pending' needs to be invoked (in the end) always, since dpkg may choose not to process triggers not just because '--no-triggers' is passed, but also because dependencies of a 'triggers-pending' package are not satisfied right at that time? [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766758#69 -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++ GNU/Linux userspace developer, Debian Developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764755: [Cupt-devel] Bug#764755: cupt: Pinned package is upgraded due to strict Depends from another package
Control: -1 + fixed-upstream Hi, 2014-10-17 23:48, Eugene V. Lyubimkin: Independently of that the bug against Cupt remains open to track the changes coming to 2.9.0 (work underway) to treat these kinds of 'version priority downgrade' more negatively than in 2.8.x by default plus the ability to configure it to be even more stricter if user wants so. [...] This has now landed to master branch. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++ GNU/Linux userspace developer, Debian Developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765762: cupt: Pinned package is upgraded due to strict Depends from another package
Hello,
Thank you for the feedback!
2014-10-19 23:34, Francesco Poli:
There's a command-line option (-P) that makes apt-listbugs use a
non-default Pin-Priority value, when pinning packages.
Please take a look at the apt-listbugs(1) man page for further details.
Cupt users may just edit their /etc/apt/apt.conf.d/10apt-listbugs
conf file, so that the line
DPkg::Pre-Install-Pkgs {/usr/sbin/apt-listbugs apt;};
gets replaced by
DPkg::Pre-Install-Pkgs {/usr/sbin/apt-listbugs -P 3 apt;};
This should address this need of Cupt.
Ack. That should be enough for most cases even in jessie-Cupt. Hopefully
users will find this bug report when they need it.
I could consider changing the default Pin-Priority to 3, but not
for jessie: I don't want to interrupt the unstable→testing migration
process for apt-listbugs/0.1.16 and any new version rushed into
unstable after the migration of version 0.1.16 would probably not make
it to be in testing before the freeze starts (on November, the 5th).
Maybe during the jessie+1 development cycle...
I'll think about it.
Ack.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++ GNU/Linux userspace developer, Debian Developer
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764755: cupt: Pinned package is upgraded due to strict Depends from another package
Control: clone -1 -2 Control: severity -2 wishlist Control: reassign -2 apt-listbugs Control: retitle -2 please increase priority of hold-type generated pins Hi, To apt-listbugs folks: please use much more higher pin priority (say, 1 or 2) if what you want to say is don't modify this package unless you have a very good reason, not try this version first unless some other package relations disagree. The difference between highest-possible-by-default-990 and 1000 might be enough for 'candidate-or-nothing' APT but unfortunately isn't for priority-based resolving in Cupt. I'd be grateful if you could consider this change for jessie so users of cupt in coming stable could use this feature of apt-listbugs. Independently of that the bug against Cupt remains open to track the changes coming to 2.9.0 (work underway) to treat these kinds of 'version priority downgrade' more negatively than in 2.8.x by default plus the ability to configure it to be even more stricter if user wants so. Even after that changes, though, high (or, on the contrary, low) priority numbers are still the best way to tell how negative/positive different version choices are, especially when compared to version choices of other packages. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++ GNU/Linux userspace developer, Debian Developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765039: fbreader: please package upstream fbreader 0.99.6
Control: tags -1 + wontfix Hello, 2014-10-13 11:42, shirish शिरीष: Dear Maintainer, Please package fbreader upstream 0.99.6 before freeze is upon us. Thank you for the report. 0.99.x are beta versions, which unfortunately have very little development nowadays: [1]. Even FBReader's official page speaks only about 0.99.4. I hesitate to put that into Debian experimental, not speaking of targeting for next stable release. [1] https://github.com/geometer/FBReader/commits/master -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++ GNU/Linux userspace developer, Debian Developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754480: [Cupt-devel] Bug#754480: Bug#754480: cupt: Needlessly tries to upgrade a package to experimental version instead of sid version
Control: tags -1 + fixed-upstream Hi, 2014-08-20 21:06, Eugene V. Lyubimkin: 2014-07-11 10:24, James McCoy: Apt currently has packages both in sid (1.0.6) and experimental (1.1~exp1). While running cupt safe-upgrade, I would expect cupt to suggest to upgrade the apt related packages from 1.0.5 - 1.0.6, but it is instead deciding to pull libapt-inst1.5 from experimental which then also pulls in libapt-pkg4.13 from experimental. The rest of the binary packages from the apt source package are, as expected, only trying to be upgraded to the latest sid version. Yes, I confirm, cupt pulled the experimental version of those packages without a good reason, due sort-of-known limitation in the current algorithms. I have some idea prototypes how to improve it in cases like this, let's see if I get them implemented for 2.9 or 2.10. Improvements underway, the test case for this scenario now passes in master. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++ GNU/Linux userspace developer, Debian Developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764468: [Cupt-devel] Bug#764468: cupt: Update Status field values handling
Control: tags -1 + confirmed Hi! 2014-10-08 13:22, Guillem Jover: Some time ago I went hunting for instances of old Status field values, and found cupt used them (probably inspired by apt's code or docs). So let's clean this up. More details in the commit message. :) Thanks! I will take it into 2.9.0. Definitely not from code (Cupt didn't borrow a single line of code from APT), but probably from [1]. I don't remember the whole thing, I guess that's the best source I had found in 2008, and apparently it happily sit for 6 years as nobody noticed. And yeah -- in 2008 dpkg had 'hold' in 'package flags' in its own man page. And I even remember times when it was 'man 8 dpkg' not 'man 1 dpkg' so I could extract even something more ancient from there... Huh, it was fun trying to dig it up from the past. [1] http://www.fifi.org/doc/libapt-pkg-doc/dpkg-tech.html/ch1.html#s1.2 The patch is not build-tested, and I'm not sure if this breaks ABI, as I've not checked the structure of the source and how it percolates into the shared library, etc. That's fine, 2.9 already has API(/ABI) breaks scheduled. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++ GNU/Linux userspace developer, Debian Developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764754: Bug#764238: Only non-suffixed version strings should be sent to other programs
Hi, 2014-10-10 15:49, James McCoy: [...] I didn't know apt-listbugs started to parse cupt's output. Or was it put by you or another tool? I ran cupt safe-upgrade and when apt-listbugs, run by cupt, showed me the set of bugs that would be introduced by upgrading, I used its 'p' option to pin the packages. If you still think that showing id suffixes is a bug, please clone this bug and let's continue discussion there. Cupt showing the suffixed versions isn't a problem. The problem is that cupt is sending those suffixed versions to other programs. This should be avoided, or at the very least avoided when running the dpkg hooks. I've cloned this to another bug. Ah, I see, didn't get it first time. Indeed, hooks... Will be fixed as well. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++ GNU/Linux userspace developer, Debian Developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764238: [Cupt-devel] Bug#764238: libcupt3-0: Version selectors are exposed to external tools, breaking pinning
Control: retitle -1 non-suffixed version strings in preferences aren't matched properly Hi James, s/version selectors/version string id suffixes [1]/ Thank you for your report! There are several things here: 2014-10-06 11:08, James McCoy: Doing an update today, apt-listbugs showed a bugs that seemed worth pinning the packages over, so I did that. This resulted in /etc/apt/preferences.d/apt-listbug containing pins like Pin: version 1.17.13^installed Any tool other than cupt doesn't understand that version, which means that e.g. a pinned package related to a security upgrade may get upgraded when it shouldn't (unattended-upgrades). Any tool which parses cupt's output is supposed to understand its way of saying things. For many commands cupt does mimic the apt way of saying things just for the sake of users/tools who wants to parse both with minimal effort, but for some commands it's intended to be different. I didn't know apt-listbugs started to parse cupt's output. Or was it put by you or another tool? If you still think that showing id suffixes is a bug, please clone this bug and let's continue discussion there. [1] https://people.debian.org/~jackyf/cupt2/tutorial.html#id_suffixes Removing the version selector from the pin causes apt to understand the pin again, but now cupt doesn't: [...] No questions here, this is a regression, many thanks for noticing, will be fixed in the next patch release. Regardless of how the pin is specified, cupt still decides to upgrade dpkg-dev due to libdpkg-perl having a lock-step Depends on dpkg-dev, although at different scores. [...] Without the version selector: D: (0:0) problem (3:1): user requests not installed: custom: upgrade libdpkg-perl D: (0:0) - (1,Δ:[uw=-460]) trying: '' - 'unsatisfied custom: upgrade libdpkg-perl' D: (0:0) - (2,Δ:[401v/u/pp=539]) trying: 'libdpkg-perl 1.17.13^installed' - 'libdpkg-perl 1.17.15' D: (0:0) - (3,Δ:[-200v/r/ra/2pp=-764]) trying: 'libdpkg-perl 1.17.13^installed' - 'libdpkg-perl not installed' D: (2:539) problem (5:2): dpkg-dev 1.17.13^installed: depends 'libdpkg-perl (= 1.17.13)' D: ignoring soft dependency relation: dpkg-dev 1.17.15: recommends 'libalgorithm-merge-perl' D: (2:539) - (4,Δ:[-200v/r=-1960]) trying: 'dpkg-dev 1.17.13^installed' - 'dpkg-dev not installed' D: (2:539) - (5,Δ:[401v/u/pp=539]) trying: 'dpkg-dev 1.17.13^installed' - 'dpkg-dev 1.17.15' This is the most interesting part. First, indeed, there is a deficiency here that new libdpkg-perl gets too high score. This is partly fixed in master already, and, hopefully, will get even better in 2.9.0. Second, even with the issue above fixed, dpkg-dev will still likely get upgraded if you issue an usual upgrade command. Pin of 1000, for Cupt, says that you only slightly prefer that version over others. Sure, it would get selected if there are no problems but doesn't quite stand the competition versus user-wanted upgrade. Even worse if there are several upgradable packages with doesn't like kept version. At least right now, the stronger the version needs to be kept, more zeroes should be added to the pin. Something like 10 for this case. I can split this part out to a separate bug if you'd like. Yes, please. There we can discuss what can be done if anything. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++ GNU/Linux userspace developer, Debian Developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763468: fbreader: Please change build dependency to libjpeg-dev (libjpeg-turbo transition)
Hello, 2014-09-30 15:06, Ondřej Surý: [...] That also means that if you are OK with NMU then please respond to this bug report and I will prepare and upload the recompiled packages for you. Yes, your prepared patch looks good, please go ahead. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++ GNU/Linux userspace developer, Debian Developer signature.asc Description: Digital signature
Bug#762785: htop: No more shows any processes if once a user starting with an underscore (_) was selected
Control: forwarded -1 https://github.com/hishamhm/htop/issues/132 Hi, 2014-09-25 09:48, Axel Beckert: with the new _apt user in apt 1.1~exp3 (in Debian Experimental), I wanted to see what it does and started htop -u _apt. [...] Thank you for detailed explanations, this issue is now forwarded to upstream tracker. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++ GNU/Linux userspace developer, Debian Developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750924: RFA: qmmp -- feature-rich audio player with support of many formats
Hi, 2014-09-09 11:55, Matteo Cypriani: I'm not a DD, only DM, so I'll need someone to grant me the upload rights on the packet. I asked a friend of mine to do it (and do a quick review too), but if you have some time to take care of the handover yourself, that would actually be great. I'm not going to grant DM upload permissions without several packages uploads at least, and my answer times tend to be long nowadays. If you have someone who knows you and your work already, just go ahead. Thank you for volunteering for maintaining qmmp! -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++ GNU/Linux userspace developer, Debian Developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750924: RFA: qmmp -- feature-rich audio player with support of many formats
Hello, 2014-09-08 16:19, Matteo Cypriani: I'm willing to adopt qmmp, I already started working on it. Hopefully I'll be able to upload the last upstream version (0.8.1) before the freeze. Great! Eugene, I noticed you used GPL-3 as the version for your packaging work; would you mind if I relicenced debian/* under the Expat license, so that the files can be used in any other Debian package? If not, what about GPL-2+, which is the main license used in Qmmp? Same license as in Qmmp seems reasonable. I hereby declare that all my work in debian/ directory of qmmp package(s) uploaded to Debian official archive, can be taken under GPL-2+ license. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++ GNU/Linux userspace developer, Debian Developer signature.asc Description: Digital signature
Bug#750924: RFA: qmmp -- feature-rich audio player with support of many formats
2014-09-08 23:44, Matteo Cypriani: [...] I think I did pretty much all I wanted to do for now, so I plan to upload tomorrow or the day after. Don't hesitate to comment on my modifications. If you have upload rights, you don't need my comments :) Or would you need a sponsor(ship)? -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++ GNU/Linux userspace developer, Debian Developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754480: [Cupt-devel] Bug#754480: cupt: Needlessly tries to upgrade a package to experimental version instead of sid version
Control: tags -1 + confirmed Hi James, I now got to the logs. 2014-07-11 10:24, James McCoy: Apt currently has packages both in sid (1.0.6) and experimental (1.1~exp1). While running cupt safe-upgrade, I would expect cupt to suggest to upgrade the apt related packages from 1.0.5 - 1.0.6, but it is instead deciding to pull libapt-inst1.5 from experimental which then also pulls in libapt-pkg4.13 from experimental. The rest of the binary packages from the apt source package are, as expected, only trying to be upgraded to the latest sid version. Yes, I confirm, cupt pulled the experimental version of those packages without a good reason, due sort-of-known limitation in the current algorithms. I have some idea prototypes how to improve it in cases like this, let's see if I get them implemented for 2.9 or 2.10. Again, many thanks for filing the bugs, they do help improving Cupt. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++ GNU/Linux userspace developer, Debian Developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758446: [Cupt-devel] Bug#758446: cupt: FTBFS with cmake 3.0
Hello Felix, 2014-08-17 19:04, Felix Geyer: cupt fails to build from source with cmake 3.0 because it tries to create a symlink from SRCDIR/test/t to BUILDDIR/test/t. This fails when SRCDIR == BUILDDIR, which is how the package is built: [...] I see. Thank you for report / heads up. I will hopefully address this in the next upload. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++ GNU/Linux userspace developer, Debian Developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754480: [Cupt-devel] Bug#754480: cupt: Needlessly tries to upgrade a package to experimental version instead of sid version
Hi James, 2014-07-11 10:24, James McCoy: Apt currently has packages both in sid (1.0.6) and experimental (1.1~exp1). While running cupt safe-upgrade, I would expect cupt to suggest to upgrade the apt related packages from 1.0.5 - 1.0.6, but it is instead deciding to pull libapt-inst1.5 from experimental which then also pulls in libapt-pkg4.13 from experimental. The rest of the binary packages from the apt source package are, as expected, only trying to be upgraded to the latest sid version. [...] Thanks for your report. I will study the logs and then write a follow-up. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++ GNU/Linux userspace developer, Debian Developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750924: RFA: qmmp -- feature-rich audio player with support of many formats
Package: wnpp Severity: normal I request an adopter for the qmmp package due to lack of using the package. Qmmp in Debian is in a relatively good shape, and mostly needs regular bug handling and uploading new upstream releases. The package description is: Qmmp is feature-rich audio player with support of many formats. It is written in Qt. . Audio formats supported: - FLAC; - Ogg Vorbis; - MPEG1 layer 1/2/3; - AAC; - CUE sheet; - WavePack. - Musepack; - CD audio; - FFmpeg-supported formats; - midi; - chiptune formats (AY, GBS, GYM, HES, KSS, NSF, NSFE, SAP, SPC, VGM, VGZ, VTX). . Audio output through: - ALSA; - OSS; - PulseAudio; - JACK. . DSP effects: - BS2B effect; - sample rate converter; - LADSPA effects; - extra stereo; - crossfade. . Features: - winamp and XMMS skins support; - plugins support; - last.fm scrobbler; - spectre analyzer; - rediscretization; - video playback via mplayer; - MPRIS (1.0 and 2.0) support; - lyrics (using lyrics.wikia.com); - removable device detection; - global hotkeys; - projectm visualization; - mms support; - multiple playlists; - cover art support; - ReplayGain support; - streaming Ogg Vorbis or MP3 via IceCast/ShoutCast. - audio converter; - stream browser; - audio formats conveter; - external programs execution on track change. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
