Bug#975650: blhc: reports false positives for missing flags
On 10/5/21 1:48 PM, Simon Ruderich wrote: > Could you test the attached patch and tell me if this works for > you for real builds? Thankfully, I still had the full log file lying around in which I originally discovered this issue, and I am indeed no longer getting any false positives with your patch. (I don't know whether this causes any new false negatives, but I suppose you have other tests for this?) Thanks for your work on this! Best, Fabian
Bug#989308: unblock: backintime/1.2.1-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Hi, please consider unblocking version 1.2.1-3 of backintime, currently in unstable. The upload fixes the release critical bug #946349 by cherry-picking the relevant fix from the upstream repository. The same fix has also been proposed as a patch in a response to #946349. The patch itself is only a few lines long. It has been approved and merged by the upstream maintainers, adding to its trustworthiness. No other changes have been made in this package for the 1.2.1-3 upload. I have attached the debdiff between 1.2.1-2 (testing) and 1.2.1-3 (unstable). Let me know if you need anything else. Thank you! Fabian diff -Nru backintime-1.2.1/debian/changelog backintime-1.2.1/debian/changelog --- backintime-1.2.1/debian/changelog 2019-10-30 22:35:50.0 +0100 +++ backintime-1.2.1/debian/changelog 2021-05-31 15:14:50.0 +0200 @@ -1,3 +1,10 @@ +backintime (1.2.1-3) unstable; urgency=medium + + * Cherry-pick patch for #946349 from upstream Git repository +(Closes: #946349). + + -- Fabian Wolff Mon, 31 May 2021 15:14:50 +0200 + backintime (1.2.1-2) unstable; urgency=medium * Source-only reupload after the package has been in the NEW queue diff -Nru backintime-1.2.1/debian/patches/00-fix-946349.patch backintime-1.2.1/debian/patches/00-fix-946349.patch --- backintime-1.2.1/debian/patches/00-fix-946349.patch 1970-01-01 01:00:00.0 +0100 +++ backintime-1.2.1/debian/patches/00-fix-946349.patch 2021-05-31 15:14:50.0 +0200 @@ -0,0 +1,39 @@ +Description: Cherry-pick fix for #946349 from upstream repository +Origin: upstream, https://github.com/bit-team/backintime/commit/7f6f570a01e7e0a623e670baaf63eaaf879948c4 +Bug: https://github.com/bit-team/backintime/issues/974 +Bug-Debian: https://bugs.debian.org/946349 +Last-Update: 2021-05-31 +--- +This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ +--- a/common/mount.py b/common/mount.py +@@ -648,7 +648,7 @@ + """ + tools.mkdir(self.mount_root, 0o700) + tools.mkdir(self.hash_id_path, 0o700) +-tools.mkdir(self.currentMountpoint, 0o700) ++tools.mkdir(self.currentMountpoint, 0o700, False) + tools.mkdir(self.lock_path, 0o700) + + def mountProcessLockAcquire(self, timeout = 60): +--- a/common/tools.py b/common/tools.py +@@ -287,7 +287,7 @@ + %(path, str(e)), traceDepth = 1) + return os.path.isdir(path) + +-def mkdir(path, mode = 0o755): ++def mkdir(path, mode = 0o755, enforce_permissions = True): + """ + Create directory ``path``. + +@@ -300,7 +300,8 @@ + """ + if os.path.isdir(path): + try: +-os.chmod(path, mode) ++if enforce_permissions: ++os.chmod(path, mode) + except: + return False + return True diff -Nru backintime-1.2.1/debian/patches/series backintime-1.2.1/debian/patches/series --- backintime-1.2.1/debian/patches/series 1970-01-01 01:00:00.0 +0100 +++ backintime-1.2.1/debian/patches/series 2021-05-31 15:14:50.0 +0200 @@ -0,0 +1 @@ +00-fix-946349.patch
Bug#989303: RFS: backintime/1.2.1-3 [RC] -- simple backup/snapshot system
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for an upload of the 'backintime' package. The upload fixes a release critical bug in the current version of the package (#946349). A patch was provided in the Debian bug tracking system and has since been applied upstream. My changes in this upload consist solely of cherry-picking the fix for #946349. Therefore, this upload is a targeted fix for a release critical bug and should qualify as an appropriate change according to the bullseye freeze policy [1]. Since this package neither is a key package nor has any autopkgtests, it will require manual review by the release team. Bullet point five of "Applying for an unblock" in the freeze policy states that If the diff is small and you believe it will be approved, you can upload it to unstable before filing the unblock request to avoid a round-trip. I suppose this applies here, which is why I'm looking for a sponsor for this upload now. The package is available on Salsa as well as on Mentors: https://salsa.debian.org/jmw/pkg-backintime https://mentors.debian.net/package/backintime/ I have also attached the debdiff of my changes vs. the current version of the package in testing/unstable. Thanks for your help! Fabian [1] https://release.debian.org/bullseye/freeze_policy.html diff -Nru backintime-1.2.1/debian/changelog backintime-1.2.1/debian/changelog --- backintime-1.2.1/debian/changelog 2019-10-30 22:35:50.0 +0100 +++ backintime-1.2.1/debian/changelog 2021-05-31 15:14:50.0 +0200 @@ -1,3 +1,10 @@ +backintime (1.2.1-3) unstable; urgency=medium + + * Cherry-pick patch for #946349 from upstream Git repository +(Closes: #946349). + + -- Fabian Wolff Mon, 31 May 2021 15:14:50 +0200 + backintime (1.2.1-2) unstable; urgency=medium * Source-only reupload after the package has been in the NEW queue diff -Nru backintime-1.2.1/debian/patches/00-fix-946349.patch backintime-1.2.1/debian/patches/00-fix-946349.patch --- backintime-1.2.1/debian/patches/00-fix-946349.patch 1970-01-01 01:00:00.0 +0100 +++ backintime-1.2.1/debian/patches/00-fix-946349.patch 2021-05-31 15:14:50.0 +0200 @@ -0,0 +1,39 @@ +Description: Cherry-pick fix for #946349 from upstream repository +Origin: upstream, https://github.com/bit-team/backintime/commit/7f6f570a01e7e0a623e670baaf63eaaf879948c4 +Bug: https://github.com/bit-team/backintime/issues/974 +Bug-Debian: https://bugs.debian.org/946349 +Last-Update: 2021-05-31 +--- +This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ +--- a/common/mount.py b/common/mount.py +@@ -648,7 +648,7 @@ + """ + tools.mkdir(self.mount_root, 0o700) + tools.mkdir(self.hash_id_path, 0o700) +-tools.mkdir(self.currentMountpoint, 0o700) ++tools.mkdir(self.currentMountpoint, 0o700, False) + tools.mkdir(self.lock_path, 0o700) + + def mountProcessLockAcquire(self, timeout = 60): +--- a/common/tools.py b/common/tools.py +@@ -287,7 +287,7 @@ + %(path, str(e)), traceDepth = 1) + return os.path.isdir(path) + +-def mkdir(path, mode = 0o755): ++def mkdir(path, mode = 0o755, enforce_permissions = True): + """ + Create directory ``path``. + +@@ -300,7 +300,8 @@ + """ + if os.path.isdir(path): + try: +-os.chmod(path, mode) ++if enforce_permissions: ++os.chmod(path, mode) + except: + return False + return True diff -Nru backintime-1.2.1/debian/patches/series backintime-1.2.1/debian/patches/series --- backintime-1.2.1/debian/patches/series 1970-01-01 01:00:00.0 +0100 +++ backintime-1.2.1/debian/patches/series 2021-05-31 15:14:50.0 +0200 @@ -0,0 +1 @@ +00-fix-946349.patch
Bug#843113: better missing kernel headers message
Control: found -1 2.8.4-1 I've encountered a similar issue today: Setting up linux-image-5.10.0-2-amd64 (5.10.9-1) ... I: /vmlinuz.old is now a symlink to boot/vmlinuz-5.10.0-1-amd64 I: /initrd.img.old is now a symlink to boot/initrd.img-5.10.0-1-amd64 I: /vmlinuz is now a symlink to boot/vmlinuz-5.10.0-2-amd64 I: /initrd.img is now a symlink to boot/initrd.img-5.10.0-2-amd64 /etc/kernel/postinst.d/dkms: dkms: WARNING: Linux headers are missing, which may explain the above failures. please install the linux-headers-5.10.0-2-amd64 package to fix this. There are no "above failures", so reading this warning message is somewhat misleading. Of course, if dkms needs some extra package, it should ideally depend on it in some way, but this seems to be nontrivial and is already covered by other bug reports, such as #762061 and #951404. But perhaps it is possible to make the above warning conditional and only print it if there actually were any errors?
Bug#975672: Bug#979245: RFS: xylib/1.6-0.1 [RC] [NMU] -- Library for reading x-y data from several file formats
On 1/11/21 3:45 AM, Stuart Prescott wrote: >> In any case, I've changed my upload to a QA upload now and reuploaded >> it to Salsa and Mentors. > > I see bartm beat me to uploading it. Are you sure? I didn't receive any emails about an upload, and the tracker doesn't say anything about a recent upload either...
Bug#979245: RFS: xylib/1.6-0.1 [RC] [NMU] -- Library for reading x-y data from several file formats
Hi Stuart, thanks for having a look at the package! But no, I do not currently intend to adopt this package. I just thought I'd try and help with the freeze preparation by fixing the RC bug in this package. The reason I created the repository in the Science Team area is that I have write access there (unlike in the Debian group) and because it fits topically. If this is a problem, you can create a repository in the Debian group, give me "Maintainer" access (so that I can push to master), and I'll change the Vcs-* fields in d/control. In any case, I've changed my upload to a QA upload now and reuploaded it to Salsa and Mentors. Best, Fabian On 1/10/21 7:11 AM, Stuart Prescott wrote: > Hi Fabian > > I see you've imported the package into the Debian Science Team area on salsa. > Since xylib is orphaned, do you intend to adopt it and maintain it within the > Debian Science team? That would be a great outcome. > > If you update the Maintainer and Uploaders fields in debian/control, close > #979256 in the changelog and update the version to 1.6-1, then I can sponsor > the maintainer upload to adopt the package :) > > regards > Stuart >
Bug#979245: RFS: xylib/1.6-0.1 [RC] [NMU] -- Library for reading x-y data from several file formats
Package: sponsorship-requests Severity: important X-Debbugs-CC: woj...@gmail.com Dear mentors, I am looking for a sponsor for a non-maintainer upload for the 'xylib' package. The package currently suffers from RC bug #975672; in the bug discussion, the current package maintainer has pointed out that the latest upstream release solves the bug, and that he is no longer able to maintain the Debian package (the last upload was five years ago). I have thus taken the liberty to package this new upstream release and perform some maintenance work which may exceed what is considered customary for a normal NMU but is arguably non-controversial and reversible (e.g., updating debian/copyright and changing it to the machine-readable format). I have also added the current package maintainer in X-Debbugs-CC so that he can voice any objections he may have regarding this NMU. The package is on Salsa and on Mentors: https://mentors.debian.net/package/xylib/ https://salsa.debian.org/science-team/xylib Thanks! Fabian
Bug#975650: blhc: reports false positives for missing flags
On 11/28/20 10:47 PM, Eriberto wrote: > Thanks Fabian and Simon! > > Considering that some false positives can't be fixed in blhc source > code, could I close this bug? I think it would make more sense to close this bug with the next upstream release, given that some changes in blhc have been applied because of it (commit 79d3a9e in the upstream repository), and it's also mentioned in the NEWS entry for the next release.
Bug#975650: blhc: reports false positives for missing flags
On 11/28/20 12:28 PM, Simon Ruderich wrote: > blhc uses a few heuristics to detect lines with (possible) > compiler commands to prevent false negatives. Lines containing > `gcc` and similar are flagged. In this case the CC= environment > variable triggers this. Then blhc looks for the actual build > command and its flags. Here the quote after -D_FORTIFY_SOURCE=2 > is the problem because blhc requires a space after each flag. I > know this handling is not perfect but parsing arbitrary shell > commands is difficult. I see. Thanks for your explanation! I'm aware of the complexity and difficulty of parsing arbitrary shell commands, so it's not a problem at all that some false positives (and negatives) exist. I just found this particular example confusing because blhc seemed to recognize the compiler command in the environment variable assignment, but not the flags on the same line, which seemed weird to me. Thanks again for having a look at this! Fabian
Bug#975650: blhc: reports false positives for missing flags
Hi Eriberto, thanks for your quick reply! On 11/24/20 5:59 PM, Eriberto wrote: > Since 0.12 version, blhc is able to ignore false positives spotted by > line(s) "injected" inside .build file via debian/rules. See more > details in blhc(1) manpage. There are examples in > /usr/share/doc/blhc/README.Debian. Please, check also the debian/rules > files in blhc, ngetty, libinsane, calibre, dxvk and picard-tools. > > Please, let me know if I can close this bug. Well, just because you can work around it doesn't mean that the bug is fixed, right? I'm trying to help improve blhc, so that false positives such as the ones I was describing ideally don't even arise. Let's wait to see what Simon thinks of this; if he deems it irrelevant and/or doesn't want to fix it, then you can close the bug. Best, Fabian
Bug#975655: RFS: smlnj -- Standard ML of New Jersey interactive compiler [QA upload]
Package: sponsorship-requests Severity: normal Dear Mentors, I am looking for a sponsor for a QA upload of the 'smlnj' package. The Debian package has not been updated in four years except for minor maintenance work. I have now packaged the latest upstream version, 110.98.1, which, most notably, contains actual support for amd64: Until now, the smlnj package on amd64 shipped 32-bit binaries; see #796661. This is fixed now, but since upstream does not yet support the NLFFI component for amd64, I had to drop the two corresponding packages for amd64. They never should have been built on this architecture, anyway, though, because as I was saying, prior to the version I have now packaged, the amd64 packages contained 32-bit code. Apart from this, I performed some maintenance work, such as accounting for the fact that compat 11 changed the directory into which the -doc package installs most of its contents. I also added a simple autopkgtest to verify that the package is functional. The package is not Lintian-clean, but my changes did not cause any additional warnings that are not already present in the current version. I would also like to ask you to give me "Maintainer" access to the Salsa repository (https://salsa.debian.org/debian/smlnj) so that I can push my changes to it; currently, you can look at them in this fork and on Mentors: https://salsa.debian.org/wolff/smlnj https://mentors.debian.net/package/smlnj/ Thanks! Fabian
Bug#975650: blhc: reports false positives for missing flags
Package: blhc Version: 0.12-2 Severity: normal X-Debbugs-CC: si...@ruderich.org Dear maintainer, consider the following warnings emitted by blhc (line breaks are mine; see the attached "test.log" file for an input that reproduces this problem): LDFLAGS missing (-Wl,-z,relro): make VERSION="v-amd64-linux" MAKE="make" \ CC="gcc -std=gnu99 -Wall" CFLAGS="-O2 -m64 -g -O2 \ -fdebug-prefix-map=/<>=. -fstack-protector-strong\ -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 \ -Wl,-z,relro" DEFS="-DARCH_AMD64 -DSIZE_64 -DOPSYS_UNIX -DOPSYS_LINUX \ -D_GNU_SOURCE -DGNU_ASSEMBLER -DDLOPEN -DINDIRECT_CFUNC" \ CPPFLAGS="-Wdate-time -D_FORTIFY_SOURCE=2" LDFLAGS="-Wl,-z,relro" \ AR="ar" ARFLAGS="rcv" RANLIB="ranlib" INCLUDES="-I../../objs \ -I../../include -I.." libposix-os.a) CPPFLAGS missing (-D_FORTIFY_SOURCE=2): VERSION=v-amd64-linux \ CPP="gcc -x assembler-with-cpp -E -P -Wdate-time -D_FORTIFY_SOURCE=2" \ CPPFLAGS="-Wdate-time -D_FORTIFY_SOURCE=2"\ ../../config/gen-posix-names.sh _SC_ ml_sysconf.h One could argue whether blhc should even consider lines like these, because they do not actually contain any compiler calls; perhaps it would be more sensible to delay the warnings to the actual compiler calls that the recursive make or the script perform. However, it doesn't hurt to be on the safe side and check calls like these, too. The problem is that the reportedly missing flags aren't missing at all: The former call contains "-Wl,-z,relro" in both CFLAGS and LDFLAGS; the latter call contains "-D_FORTIFY_SOURCE=2" in both CPP and CPPFLAGS. So, why does blhc think that those flags are missing? Best regards, Fabian dpkg-buildpackage: info: host architecture amd64 (cd ../c-libs/posix-os; make VERSION="v-amd64-linux" MAKE="make" CC="gcc -std=gnu99 -Wall" CFLAGS="-O2 -m64 -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-z,relro" DEFS="-DARCH_AMD64 -DSIZE_64 -DOPSYS_UNIX -DOPSYS_LINUX -D_GNU_SOURCE -DGNU_ASSEMBLER -DDLOPEN -DINDIRECT_CFUNC" CPPFLAGS="-Wdate-time -D_FORTIFY_SOURCE=2" LDFLAGS="-Wl,-z,relro" AR="ar" ARFLAGS="rcv" RANLIB="ranlib" INCLUDES="-I../../objs -I../../include -I.." libposix-os.a) VERSION=v-amd64-linux CPP="gcc -x assembler-with-cpp -E -P -Wdate-time -D_FORTIFY_SOURCE=2" CPPFLAGS="-Wdate-time -D_FORTIFY_SOURCE=2" ../../config/gen-posix-names.sh _PC_ ml_pathconf.h
Bug#970510: why3: does not work with current version of cvc4
And while we're at it, even though this is technically an unrelated problem, it also has something to do with SMT solver versions: In the autopkgtests control file [0], you have the following code: Tests: why3+z3 Depends:why3, z3 (<< 4.8.7) Restrictions: skip-not-installable This is not a big issue, because it doesn't block migration of z3 (unlike the cvc4 failure [1]), you might still want to adjust this version restriction, given that the current z3 version in unstable is 4.8.9 (unless, of course, there is a reason why why3 won't work with more recent versions of z3). Thanks! Fabian [0] https://sources.debian.org/src/why3/1.3.2-1/debian/tests/control/#L13 [1] https://lists.debian.org/debian-ci/2020/09/msg00042.html
Bug#970511: cvc4: test failures on various architectures
Source: cvc4 Version: 1.8-1 Severity: important CVC4 1.8-1 fails to build on several release architectures due to a few test case failures [0]. I have reported the issue upstream [1]. I am going to reupload the cvc4 package soon with the test cases in question disabled, as a temporary solution, and I'm opening this bug report to remain aware of the problem. [0] https://buildd.debian.org/status/logs.php?pkg=cvc4&ver=1.8-1 [1] https://github.com/CVC4/CVC4/issues/5082
Bug#970510: why3: does not work with current version of cvc4
Package: why3 Severity: important Dear maintainer, this seems to be the same issue as #942344, just this time it's cvc4 instead of z3: share/provers-detection-data.conf lists CVC4 versions up to 1.7, but the current version is 1.8, so the autopkgtests for why3 fail. Best regards, Fabian
Bug#810871: [buildd-tools-devel] Bug#810871: Bug#810871: [sbuild] Please provide a way to set an environment variable to the build directory
Hi, so after four and a half years, the same issue still exists - when building a package that uses CMake, I got a cache hit rate of zero. After some investigation (I wasn't aware of this bug report), it turned out that the issue was caused by the differing build paths, as described in this bug report. Could you at least add some advice to the wiki page [0] that points out the existence of this issue, and ideally a proposed solution? I mean, I'm no expert with sbuild, so my solution consisted of something like export CCACHE_BASEDIR = $(shell pwd) in debian/rules; which is fine, it works, but it is obviously quite inelegant and untrue to the spirit of a cache (which is supposed to be hidden in the background, "caché", so to speak). Is there a better solution, perhaps something I can put into $dir/sbuild-setup, to use the wiki page's terminology? Thanks, Fabian [0] https://wiki.debian.org/sbuild#Using_.22ccache.22_with_sbuild
Bug#963098: dwarfdump: dump .eh_frame fails on x86-64 elf
Control: tags -1 + patch pending upstream confirmed fixed-upstream On 6/19/20 6:51 PM, David Anderson wrote: > I too reproduce the error. > > The relocation used was -not- one I was aware of. > This diff fixes the problem. it should be on sourceforge > in a day or two. I hope to create a new full release > this month --- there is significant new DWARF5 support > in the next libdwarf/dwarfdump release. Sweet. Thanks! In that case, I think I'll just wait for the next release (no hurry, though, David!) to close this bug. Best regards, Fabian
Bug#963098: dwarfdump: dump .eh_frame fails on x86-64 elf
Hi Nick, thanks for reporting this; indeed, I could reproduce the error, and llvm-dwarfdump doesn't produce a similar error (unsurprisingly, if the file was generated with LLVM in the first place). I'm hereby forwarding your report to libdwarf's upstream developer - David, could you have a look at this? Thanks! On 6/18/20 11:44 PM, Nick Lewycky wrote: > Package: dwarfdump > Version: 20200114-1 > Severity: normal > > Dear Maintainer, > > I have an ordinary x86-64 ELF .o file (attached) which was produced by LLVM, > but dwarfdump issues an error when asked to dump the .eh_frame: > > $ dwarfdump -F function_0.o > > .eh_frame > > dwarfdump ERROR: dwarf_get_fde_list: > DW_DLE_RELOC_SECTION_RELOC_TARGET_SIZE_UNKNOWN (233) so doing a relocation is > unsafe > > -- System Information: > Debian Release: bullseye/sid > APT prefers stable-updates > APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 5.6.0-1-amd64 (SMP w/8 CPU cores) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), > LANGUAGE=en_US.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages dwarfdump depends on: > ii libc6 2.30-8 > ii libdwarf1 20200114-1 > ii libelf1 0.176-1.1 > > dwarfdump recommends no packages. > > dwarfdump suggests no packages. > > -- no debconf information > function_0.o Description: application/object
Bug#962215: libfox-1.6-0: Is it possible to package fox-1.7.67 or higher?
Hi Roland,
I totally understand your need for a more recent version of the FOX
toolkit. There has been very little upstream activity on the 1.6
("stable") branch in the last few years, and honestly, I don't know
why the 1.7 branch isn't yet considered stable or if/when this will
ever happen.
However, there are a few packages in Debian that depend on the 1.6
branch of FOX, and, without having checked this myself, I would assume
that they won't just work with 1.7 (i.e., someone would have to patch
them). Additionally, some Debian users are probably using the FOX 1.6
development package for their own projects, so I can't just drop 1.6
and move to 1.7.
Instead, one would have to create a new package for the 1.7 branch and
maintain that in parallel to the existing 1.6 package (as far as I can
see, this won't lead to any package name clashes).
The fact that 1.7 is still considered the "development" branch is not
such a big deal in my view, because there are regular releases and the
1.7 branch has existed for quite a long time now. The much larger
practical problem is that I currently don't have the time to package
and maintain the 1.7 branch myself.
I have reassigned your bug report as a RFP (Request For Package) to
the "wnpp" package, because it really doesn't have much to do with the
fox1.6 source package, which I maintain. This way, other people can
see that FOX 1.7 has been requested as a Debian package, and if you're
lucky, someone will come along and package/maintain it.
Even if that happens, it can take a while, though, so your best bet
right now would probably be to package and maintain FOX 1.7 yourself.
I haven't personally attempted this, but I would suspect that the
package would look rather similar to the fox1.6 package, so you could
use this as a basis.
I hope this helps, sorry for not being able to solve your problem
right away!
Best regards,
Fabian
Bug#949133: z3: request for backport to buster
Hi Benjamin, sorry for the very late reply, I kept putting it off... Anyway, I have now set up a stable sbuild chroot and built z3 there, and, almost surprisingly (and embarrassingly, because I waited so long to give it a try), it built immediately, without me having to change anything, and the autopkgtests passed, too. So in principle, I could upload it now, but I'm kind of hesitant with regards to how this would make me responsible for the package until buster's EOL [1]. Do you have any experience with backports, is it really such a big commitment as they make it sound in [1]? Because my personal focus is definitely on testing. Best regards, Fabian [1] https://backports.debian.org/Contribute/ On Fri, 17 Jan 2020 10:55:54 +0100 Benjamin Albrecht wrote: > Package: z3 > Version: 4.8.7-2 > Severity: wishlist > > Dear Maintainer, > > I'm happy to see that z3 is actively being maintained again in Debian. > > The version shipped in buster is quite old by now. Is there any chance you > might be interested in providing a backport of the current version? > > Sincerely > > Benjamin Albrecht > > signature.asc Description: OpenPGP digital signature
Bug#955322: RFS: pulseaudio-dlna -- stream audio to DLNA devices and Chromecasts
On 3/30/20 7:19 PM, Muammar El Khatib wrote: > Does it seem you already got access? > > https://salsa.debian.org/debian/pulseaudio-dlna/-/commit/61d6ee13c13eb76cb6b70b6b50c2fb5efe04dc7f Yeah, somebody (probably Adam -- thanks!) created the repository and gave me the necessary access permissions to it. I have now added the debian/ tag for the latest release, so everything should be in order now!
Bug#955322: RFS: pulseaudio-dlna -- stream audio to DLNA devices and Chromecasts
Hi Adam and Muammar, thanks for your quick replies! Adam, thank you for looking over my changes and sponsoring the upload. One more thing: As I said in my original email, I have a Git repository set up for this package, but I don't have the necessary permissions to create a repository in the "Debian" group on Salsa, so could one of you (or somebody else) please create the repository and give me "Maintainer" access to it, so that I can push to it? https://salsa.debian.org/debian/pulseaudio-dlna Thank you! Fabian
Bug#955322: RFS: pulseaudio-dlna -- stream audio to DLNA devices and Chromecasts
Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: muam...@debian.org, sergi...@debian.org
Dear mentors,
I am looking for a sponsor for a NMU of the 'pulseaudio-dlna' package.
The package has been removed from testing because it's still using Python 2,
and there seems to be no recent upstream activity. There is, however, a fork
of the upstream repository with a port to Python 3, which I have packaged
for this upload to make the package usable again.
All of the details, including where my upstream tarball came from, are in
d/changelog. The package is Lintian-clean, and I have verified that it works
with a DLNA device of mine.
The current maintainer hasn't made an upload for this package in three years
and does not seem to have made any effort to solve the open RC bugs, so I
think a NMU is warranted here. However, I've still added him in X-Debbugs-CC
to be sure.
I have created a Git repository for this package, but I think it would be
best to maintain this repository in the Debian group on Salsa, so whoever
sponsors this package: Please also create the repository that the
Vcs-{Git,Browser} fields point to and give me "Maintainer" access to it, so
that I can push to it.
The package can be found on Salsa (temporarily, see above) and on Mentors:
https://mentors.debian.net/package/pulseaudio-dlna
https://salsa.debian.org/wolff-guest/pulseaudio-dlna
Thanks for your help!
Fabian
Bug#949070: debci: information is out of date
Package: debci Dear debci maintainers, it seems to me that the information on ci.debian.net is often confusingly out of date. For instance, I recently uploaded a new version of the z3 package, 4.8.7-4, which at the time of writing this bug report has already migrated to testing: https://web.archive.org/web/20200116154412/https://tracker.debian.org/pkg/z3 >From my understanding, this means that the autopkgtest tests must have been run successfully for 4.8.7-4 (in fact, when 4.8.7-4 was in unstable but not yet in testing, tracker.debian.org displayed the "Excuses" information for why the package hasn't migrated yet, and this included a link to a test log for 4.8.7-4, proving that the test has indeed been run somewhere). But even now, the Debian Continuous Integration website still displays old information: https://web.archive.org/web/20200116154353/https://ci.debian.net/packages/z/z3/ Perhaps I have confused something here, in which case I am sorry for the noise. But even in that case, it's still confusing why the debci web page links to outdated information - either the tests for the new version have run already, in which case the page should link to the new logs, or the tests haven't run already, but then a green thumbs-up wouldn't be warranted, I think, but rather, the page should say "test results pending" or something like that. Best wishes, Fabian
Bug#948927: RFS: dafny -- programming language with program correctness verifier [NMU, RC]
Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: bba...@mit.edu, sergi...@debian.org
Dear mentors,
I am looking for a sponsor for an upload of the 'dafny' package.
There have been new upstream releases, I have fixed the two open RC
bugs for this package, enabled autopkgtest package testing, and
performed some additional package maintenance tasks.
I have created a Git repository for this package, but I think it
would be best to maintain this repository in the Debian group on
Salsa, so whoever sponsors this package: Please also create the
repository that the Vcs-{Git,Browser} fields point to and give me
"Maintainer" access to it, so that I can push to it.
My changes are on Mentors and in a (temporary) repository on Salsa:
https://mentors.debian.net/package/dafny
https://salsa.debian.org/wolff-guest/dafny
The current maintainer has not made an upload for this package in
over three years, has not fixed the open RC bugs, is looking for
somebody to adopt the package and did not object to an NMU for a
related package, so I think this NMU should be fine:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944876#10
Still, I have added him in the X-Debbugs-CC header to let him know
what's going on.
Thanks for your help!
Fabian
Bug#948894: z3: add nojava build profile
Source: z3 Severity: wishlist X-Debbugs-CC: hel...@subdivi.de [discussion continued from #948763] On 1/13/20 7:30 PM, Helmut Grohne wrote: > Why is the libz3-java package "Architecture: any" (long list actually) > instead of "Architecture: all"? Many lib*-java packages are > "Architecture: all" instead, so I'd like to understand the reason. > > Why is the libz3-java package "Multi-Arch: foreign"? It seems to depend > on libz3-jni, which is "Multi-Arch: same". Such a setup seems wrong as > both seem to be libraries. As a dependency on libz3-java would be > expected to provide the jni components for the requested architecture, > but this is not the case here. Possibly, the "Multi-Arch: foreign" is > wrong here. In that case, "Architecture: any" does make sense as > "Architecture: all" cannot propagate an architecture-constraint. (This > is also known as the multi-arch-interpreter-problem.) > > Why are libz3-java and libz3-jni separate packages? Why not merge them > into one? In which situations would you install one, but not the other? First of all, I should note that I have adopted this package not too long ago from an inactive maintainer, so I'm still somewhat in the process of cleaning things up (and unfortunately, I can't ask the previous maintainer about decisions he's made because he won't reply to any emails). >From my understanding of what has happened, there used to be a single libz3-java package that included the shared library in usr/lib/*/jni/, which is why it had to be Architecture: any. It was also marked Multi-Arch: same, but because the JAR file in /usr/share/java/ was not built reproducibly, bug #797515 complained that the JAR file was an architecture-dependent file in a Multi-Arch: same package. It actually isn't architecture-dependent, of course, but because the build was (is?) not reproducible, rebuilding it on different architectures still yields different results (as does rebuilding on the same architecture). The previous maintainer's solution to this was to split the libz3-java package into an Architecture: any, Multi-Arch: same libz3-jni package containing the JNI shared library and the current libz3-java package containing only arch-independent files, but because they did not build reproducibly, they *looked* like arch-dependent files, which is why, I suppose, he marked the package Architecture: any (instead of all) and Multi-Arch: foreign (because it's actually not arch-dependent). Of course, this solution is not very satisfying. Please correct me if I'm wrong, but I think that the proper solution should consist of a single libz3-java package marked Architecture: any (because of the JNI shared library) and Multi-Arch: same (for the JAR file), right? Apparently [0], JAR files still aren't built reproducibly, but dh_strip_nondeterminism might take care of this; do you know more about this? Comparing the amd64 and armhf builds of libz3-java from snapshot.debian.org actually does suggest that the package is built reproducibly by now. Best regards, Fabian [0] https://wiki.debian.org/ReproducibleBuilds/TimestampsInJarFiles
Bug#948605: dwarfutils: Please make autopkgtests cross-test-friendly
Control: tags -1 pending Hi Steve, thanks for your patch! I have applied it in the Salsa repository: https://salsa.debian.org/wolff-guest/dwarfutils/commit/ef186156885aef96d600c9c5c5d43eaba143ffb0 Since this issue doesn't look very urgent to me, I would simply wait for the next regular upload (e. g. new upstream release), but if this is blocking something else or you have some other reason for why you need this in unstable ASAP, just let me know and I'll upload it. Best regards, Fabian
Bug#948763: z3: cannot be built on buildds
On Mon, 13 Jan 2020 06:21:56 +0100 Helmut Grohne wrote: > Source: z3 > Version: 4.8.7-3 > Severity: serious > > z3 cannot be built on buildds, because its Build-Depends cannot be > satisfied on buildds. Failing to build on buildds is a serious problem. It builds now on all but three architectures, including, in particular, all release architectures. > [...] Thanks for your suggestions, but I'm not very familiar with how Multi-Arch annotations should be used; I just accepted a patch to make the z3 package more cross-build friendly (see #948109). Can you give me a patch where you set the build dependency annotations in a sound way that also works for cross-building? Otherwise, I would have to simply remove all annotations again in order to fix this bug (but clearly, that would not be the most desirable solution). I would also be happy to use the nojava build profile that you suggested, but again, I'm not familiar with this technique, and from what I've heard, there are still some problems e. g. with using "dh-sequence-javahelper ". But if somebody gave me a patch, I'd be happy to apply it. Thanks for your help! Fabian
Bug#948109: z3: FTBFS on riscv64, needs -latomic, blocks rustc:riscv64
On 1/11/20 12:02 PM, Aurelien Jarno wrote: > I have just tried to build the current master branch natively on > riscv64, it builds fine. Great! I just pushed z3 4.8.7-3 to unstable, so let's hope everything goes well. Thanks again to all of you for your help with this!
Bug#948109: z3: FTBFS on riscv64, needs -latomic, blocks rustc:riscv64
On 1/10/20 6:50 PM, Ximin Luo wrote:
> Sorry. I changed it to -headless because it *usually* is sufficient for a
> java package, and it avoids installing extra unnecessary X libraries during
> the build. I tested this with version -2 and it worked fine before switching
> to cmake, so I don't know why it is failing now.
>
> Oh, do the tests require X libraries? Maybe that is why. Cross-compiling
> doesn't run the tests of course. I may or may not have also run a native
> amd64->amd64 build to run the tests, but I can't remember now.
No problem. The reason why the build fails is because the CMake configuration
can't find 'jawt.h', and an 'apt-file search jawt.h' reveals that this file
is apparently only included in the full openjdk-{11,13}-jdk (and not in the
corresponding -headless).
Bug#948109: z3: FTBFS on riscv64, needs -latomic, blocks rustc:riscv64
On 1/9/20 5:22 PM, Aurelien Jarno wrote: > On 2020-01-09 14:18, Ximin Luo wrote: >> So setting CMAKE_USE_PTHREADS might work. > > Yep, I confirm that works. In short with the following patch, z3 builds > natively on riscv64: Thanks for checking! I was planning to upload the changes today, but building z3 in a clean sbuild amd64 chroot failed because Ximin changed the Build-Dependency from default-jdk to default-jdk-headless. I changed it back to fix the build, but was there a specific reason for why you changed this, Ximin? Is default-jdk not working on riscv64, or for cross-building, or ...? The Salsa repository's master branch now contains what I'm planning to upload (including Ximin's MRs and Aurelien's patch), so feel free to have another look if you want. Best regards, Fabian
Bug#948109: z3: FTBFS on riscv64, needs -latomic, blocks rustc:riscv64
Thank you for your MR, Ximin! Do you need anything else? I see you haven't added -pthread anywhere yet; is this not necessary with CMake (maybe CMake adds it automatically?), and have you tried building on/for riscv64 again to verify that it works now?
Bug#948109: z3: FTBFS on riscv64, needs -latomic, blocks rustc:riscv64
I've mostly finished porting the package to the CMake build system now, so to avoid further confusion as to which parts of which patches should be applied, what I would suggest is for you to just have a look at the Salsa repository and port your patches so that I know precisely what changes you need (just open a MR or something): https://salsa.debian.org/pkg-llvm-team/z3/tree/cmake I hope this won't be too much work for you, but the CMake build scripts are actually a lot easier to work with, and the new debian/rules is also much shorter, so it shouldn't be too much effort, I think! This would also give you the opportunity to test whether my changes, together with your patch, will actually work on riscv64. Ximin: I do realize that coordinating the SONAME with upstream would be preferable, but upstream's handling of it does not appear to be very mature yet (e. g. the two build systems generate different SONAMEs, and the CMake scripts set the SONAME to MAJOR_VERSION.MINOR_VERSION, which is incorrect because the SONAME should count ABI compatibility breaks and not version numbers). Perhaps I should discuss this with upstream at some point, but for now, I don't want to cause any unnecessary transitions just because the build system changed.
Bug#948109: z3: FTBFS on riscv64, needs -latomic, blocks rustc:riscv64
Thank you all for your patches and the ensuing discussion. I am currently working on porting the z3 Debian package to use the CMake build scripts; I think this will simplify things for all parties involved now and in the future. In the process, I will drop the OCaml bindings; they are currently broken, anyways, have no reverse dependencies, and the upstream CMake scripts don't support building them. There is still some work that needs to be done (e. g. setting the SONAME correctly), but you can have a look at my current progress here: https://salsa.debian.org/pkg-llvm-team/z3/tree/cmake Is it enough to add -latomic to DEB_LDFLAGS_MAINT_APPEND in debian/rules and disable the Java bindings on riscv64?
Bug#948376: lintian: no-dh-sequencer tag shouldn't be "certain"
Package: lintian Severity: minor The no-dh-sequencer tag should not be marked "certain", especially not the way the check is implemented right now. For instance, it breaks even for simple examples like this one: %: if [ $(WITH_JAVA) = yes ]; then \ dh $@ --with python3,javahelper,ocaml; \ else \ dh $@ --with python3,ocaml; \ fi Additionally, let's say I start a Turing machine and then run "dh $@"; then the no-dh-sequencer tag applies iff the Turing machine does not halt. So the check is undecidable, another reason for why it shouldn't be "certain" :-) Best regards, Fabian
Bug#944876: RFS: boogie 2.4.1-0.1 -- verifiable programming language [NMU, RC]
On 11/24/19 7:13 PM, Benjamin Barenblat wrote:
> As the current maintainer, I definitely do not object to this NMU (or
> any other NMUs associated with this package). Sponsors, please feel free
> to upload without delay.
Thanks. One more question: Upstream has switched to the Expat ("MIT/X11")
license
for the Boogie code; I think it would make things much simpler and
straightforward
if we could use the same license for the debian/* files as well.
Would you be willing to relicense your work on the Boogie Debian package under
the
Expat license? If so, and with your consent documented here in the bug tracker
for
#944876, I'd simply change the license to Expat in debian/copyright. What do you
think?
Thanks for your help!
Bug#888914: backintime adds current directory to path?
Thanks for reporting this bug.
It appears to me that the issue you're referring to might have been fixed by
this commit:
https://github.com/bit-team/backintime/commit/7795b40772c821805037664a559d96642b768391
Could you check again and confirm this, please? Then we could close this bug.
On Wed, 31 Jan 2018 06:18:35 + David Starner wrote:
> Package:backintime-qt4
> Version:1.1.12-2
>
> ~/RPG/Mine/Traveller/Traveller_USB $ backintime-qt4 &
> [1] 326
> ~/RPG/Mine/Traveller/Traveller_USB $ sh: 0: getcwd() failed: No such file
> or directory
> sh: 0: getcwd() failed: No such file or directory
> Traceback (most recent call last):
> File "/usr/share/backintime/qt4/app.py", line 46, in
> import snapshotsdialog
> File "/usr/share/backintime/qt4/snapshotsdialog.py", line 32, in
> if tools.check_command('meld'):
> File "/usr/share/backintime/common/tools.py", line 167, in check_command
> return not which(cmd) is None
> File "/usr/share/backintime/common/tools.py", line 173, in which
> path.insert(0, os.getcwd())
> FileNotFoundError: [Errno 2] No such file or directory
>
> [1]+ Exit 1 backintime-qt4
>
> I'm not going to trying to set up a proof-of-concept security hole with
> this, but it seems quite obvious that backintime-qt4 should not insert the
> current directory into the path for the same reasons that you don't insert
> the current directory into the path in bash. All a user has to do is insert
> the right executables into the current directory and then convince the
> admin to run backintime-qt4 from that directory (and the social part of
> that exploit seems simple enough).
>
> If nothing else, getting a backtrace from a program is bad, and this would
> leave a non-programmer utterly baffled about what went wrong.
Bug#944876: RFS: boogie 2.4.1-0.1 -- verifiable programming language [NMU, RC]
Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: bba...@mit.edu
Dear mentors,
I am looking for a sponsor for an upload of the 'boogie' package.
My changes are summarized in the latest changelog entry:
boogie (2.4.1-0.1) unstable; urgency=medium
* Non-maintainer upload.
* New upstream release.
* Update debian/watch file.
* Update debian/copyright.
* Change Priority to optional in debian/control.
* Upgrade to debhelper compat level 12.
* Update build dependencies (Closes: #927171).
* Upgrade to Standards-Version 4.4.1.
* Fix debian/rules to make the new version build.
* Enable autopkgtest package testing, and add mccarthy-{91,92} tests.
* Update Vcs-Git and Vcs-Browser fields in debian/control.
-- Fabian Wolff Sat, 16 Nov 2019 19:16:48 +0100
The current maintainer is looking for someone to adopt the package (#903142)
and has not made any attempt to keep the package in shape even after it had
been removed from testing, so I don't think he will object to this NMU. But
I have added him in the X-Debbugs-CC header just to be sure.
The Git repository that the Vcs-Git and Vcs-Browser fields point to does not
exist yet, but I've already sent a request on debian-mentors for someone to
create it for me and give me access to it. Once this has happened, I will
push my changes there; in the meantime, the package can be found here:
https://salsa.debian.org/wolff-guest/boogie
And also on Mentors:
https://mentors.debian.net/package/boogie
Thank you for your help!
Best regards,
Fabian
Bug#941431: Build cvc4 on other architectures
On Mon, 30 Sep 2019 15:35:36 +0200 =?UTF-8?B?RnLDqWTDqXJpYw==?= Bonnard wrote: > Dear maintainer, > is there any reason that cvc4 isn't build on "any" ? > I tested ppc64 and ppc64el and it worked well. Thanks for bringing this to my attention. Yes, there is a reason: https://buildd.debian.org/status/logs.php?pkg=cvc4&ver=1.5-1&suite=sid In other words, the build used to fail on all those architectures that are now excluded, which is why I excluded them. I haven't tried building newer versions of cvc4 on those architectures, mostly because I don't have the resources for it: Building cvc4 takes pretty long even on native hardware, and since I don't have access to any powerpc/alpha/... machines, I would have to cross-build using QEMU or something, which is even slower. However, I just noticed that cvc4's watch file is out of date and there has been a new upstream release (1.7). I'm not sure when I will find the time to package it, but when I do, I can include more architectures while I'm at it. Which architectures do you think I should include? Just ppc64 and ppc64el, or "any" and hope for the best, or ... ? Best regards, Fabian
Bug#943669: RFS: backintime 1.2.1-2 -- simple backup/snapshot system [closes RC bugs]
Thank you for pointing this out to me - I was not aware of the GFDL-NIV short name. I have now changed it to GFDL-NIV-1.1+ (because legal.xml says "Version 1.1 or any later version") and pushed the updated version to the Salsa repository. Thank you for sponsoring this upload! On 10/30/19 9:48 PM, Dmitry Shachnev wrote: > Hi Fabian! > > On Sun, Oct 27, 2019 at 06:28:26PM +0100, Fabian Wolff wrote: >> Dear mentors, >> >> I am looking for a sponsor for an upload of the 'backintime' package. >> [...] > > I would be happy to sponsor this, just please change one thing. > > In debian/copyright, you specify license as “GFDL”. However, the copyright > specification [1] says: > > “Use GFDL-NIV instead if there are no Front-Cover or Back-Cover Texts or > Invariant Sections.” > > So can you please change the license short name to GFDL-NIV-1.3+? > Then your comment would be not needed, however you may include the first > paragraph of qt/docbook/en/legal.xml in the license text (before the > “On Debian systems” part). > > [1]: > https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-short-name > > -- > Dmitry Shachnev >
Bug#943669: RFS: backintime 1.2.1-2 -- simple backup/snapshot system [closes RC bugs]
Package: sponsorship-requests Severity: normal X-Debbugs-CC: j...@debian.org Dear mentors, I am looking for a sponsor for an upload of the 'backintime' package. My changes are summarized in the latest changelog entry: backintime (1.2.1-2) unstable; urgency=medium * Source-only reupload after the package has been in the NEW queue (due to backintime-qt). * Change incorrect dependency on python3-dbus.mainloop.qt to the Qt 5 python3-dbus.mainloop.pyqt5 (thanks to Michael Weghorn for pointing this out to me!) (Closes: #941686). * Audit and update debian/copyright (Closes: #941984, #942155). * Upgrade to Standards-Version 4.4.1 (no changes). * Add additional backintime-qt_polkit.1.gz symlink to backintime.1.gz to silence the binary-without-manpage Lintian warning. -- Fabian Wolff Sat, 19 Oct 2019 23:21:22 +0200 The package is available on Mentors and on Salsa: https://salsa.debian.org/jmw/pkg-backintime https://mentors.debian.net/package/backintime Thank you very much for your help! Best regards, Fabian
Bug#837415: [arm64] segmentation fault
Hi Ralf, since I don't have an arm64 machine available to try this out myself: Could you check whether this problem still exists in the current version of z3? Your bug report refers to a quite old version of z3, so I'd say there is a good chance that the issue has been fixed since then. If not, then at least I know I need to forward the issue to upstream. Best regards, Fabian On Sun, 11 Sep 2016 14:43:33 +0200 Ralf Treinen wrote: > Package: z3 > Version: 4.4.1-0.2 > > Hello, executing z3 on arm64 on the attached file produces a Segmentation > fault, while it works fine on amd64. I didn't check any other architectures. > > z3 -smt2 gauss-Gauss-WP_parameter_gauss.smt2 > Segmentation fault > > -Ralf.
Bug#942344: why3: does not work with current version of z3
Package: why3 Severity: important X-Debbugs-CC: pkg-llvm-t...@lists.alioth.debian.org Dear maintainer, in share/provers-detection-data.conf (in the why3 source tree), only z3 versions up to 4.8.4 are listed as "version_ok". But the 4.8.4 release of z3 was almost two years ago and has since been superseded by two later releases, one of which (4.8.6) is now finally available in Debian unstable. However, its arrival has caused an autopkgtest regression for why3, which also blocks z3 from migrating to testing (among other things that I will fix soon): https://ci.debian.net/data/autopkgtest/testing/amd64/w/why3/3154338/log.gz This seems to be caused by why3's version requirement on z3 <= 4.8.4 as mentioned above. Please either add a versioned dependency on z3 in debian/control, or add more acceptable z3 versions to your prover detection system, or, ideally, rewrite your prover detection system so that this failure won't happen again the next time a new z3 release is packaged for Debian. Best regards, Fabian
Bug#941857: Z3 4.8.4 contains cache bugs and should not be packaged
Hi Roman, > Dear maintainer. > It is good to see Z3 4.8.4 finally being packaged in Debian! > > As i have personally just encountered, that version contains some bugs, > that result in incorrect modelling, which effectively renders the whole > library unusable. Upstream developer, Nuno Lopes, notes: >> https://github.com/AliveToolkit/alive2/issues/122 >> https://github.com/AliveToolkit/alive2/issues/123#issuecomment-538761842 >> BTW, it's important to have a recent Z3 so you can get the counterexample >> above. I fixed a bug a while ago in Z3's model cache (I don't remember which >> release it integrated). > > I have manually rebuilt z3-4.8.6 from salsa and `sudo dpkg -i` it. > That resolved the bugs i was observing. > > I personally consider these bugs to be fatal to the package, > as in it would be better to unpackage said package version. > Given that 4.8.6 is ready to be packaged thanks to the work of > Fabian Wolff, it may be good to proceed with that. thanks for pointing this out to me. 4.8.6 is ready and uploaded, but because it introduced the new python3-z3 package, it's still hanging in the NEW queue, which seems to be moving quite slowly recently: https://ftp-master.debian.org/new/z3_4.8.6-1.html Unfortunately, all I can do at this point is to wait for someone from the FTP team to review and, hopefully, accept the package, but I do not know when this is going to happen (the package has been in the queue for about a week now). Best regards, Fabian
Bug#941367: RFS: z3 4.8.6-1 -- theorem prover from Microsoft Research
On 10/4/19 11:44 PM, Gianfranco Costamagna wrote:
>>My changes are on Salsa (I'll push to the actual repository once somebody has
>>given
>>me sufficient ("Maintainer") permissions to do so), and also on Mentors:
>>
>> https://salsa.debian.org/wolff-guest/z3
>> https://mentors.debian.net/package/z3
>
> you are now member of the group, and I merged your PR, please make sure it is
> correct!
Looks good to me, thanks!
> also,
> dcut -k 92978A6E195E4921825F7FF0F34F09744E9F5DD9 ssh-upload dm --uid
> fabi.wo...@arcor.de --allow z3
> Uploading commands file to ssh.upload.debian.org (incoming:
> /srv/upload.debian.org/UploadQueue/)
> Picking DM Fabian Wolff with fingerprint
> 4C22AB203E83493607A16E4480AD73734275BDAF
> SCP is deprecated. Please consider upgrading to SFTP.
> Uploading locutus-1570225216.dak-commands to ssh-upload
>
> you proved to be a good maintainer, providing good packages to sponsor,
> keeping the package in a perfect shape, without need to review changes.
>
> You deserve to upload it by yourself, even if in this case a DD upload was
> needed in any case :)
>
> keep up the wonderful work you are doing here!
Fantastic, thank you! I am flattered by your praise, and I'll try to live up to
it.
Best,
Fabian
Bug#941367: RFS: z3 4.8.6-1 -- theorem prover from Microsoft Research
Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: m...@debian.org, locutusofb...@debian.org, sylves...@debian.org,
lebedev...@gmail.com
Dear mentors,
I am looking for a sponsor for an upload of the z3 package.
The current maintainer, Michael Tautschnig, is apparently not active anymore,
because
he has not made an upload for this package for several years now, and didn't
respond
to any of my emails. Because I'd already made several non-maintainer uploads
for this
package in the past, I decided to add myself as co-maintainer (I have added
Michael in
the X-Debbugs-CC above just to be sure).
My changes are summarized in the latest changelog entry:
z3 (4.8.6-1) unstable; urgency=medium
* New upstream release.
* Make watch file more robust (match (z3|Z3) instead of just z3).
* Add myself to Uploaders in debian/control.
* Drop the libz3-cil package (not all build dependencies are available
in Debian; also see the discussion in #886590).
* Update/refresh patches.
* Drop python-z3 package and replace it with python3-z3
(Closes: #886590, #938876).
* Enable autopkgtest package testing and add several superficial and
non-superficial test cases.
* Add -fPIC to DEB_CXXFLAGS_MAINT_APPEND in an attempt to fix #940266.
* Try to make the build more reproducible.
-- Fabian Wolff Sun, 29 Sep 2019 18:21:54 +0200
In particular, I've introduced the new python3-z3 package, so whoever decides to
sponsor this upload, please remember to also upload binaries, because the
package has
to go through the NEW queue.
My changes are on Salsa (I'll push to the actual repository once somebody has
given
me sufficient ("Maintainer") permissions to do so), and also on Mentors:
https://salsa.debian.org/wolff-guest/z3
https://mentors.debian.net/package/z3
Thanks for your help!
Best regards,
Fabian
Bug#886590: Please add python3-z3 package
On 9/25/19 9:52 AM, Sylvestre Ledru wrote: > > Le 24/09/2019 à 16:41, Roman Lebedev a écrit : >> On Tue, Sep 24, 2019 at 5:39 PM Fabian Wolff wrote: >>> >>> What are your thoughts on this? >> I personally would not see dumping libz3-cil and libz3-ocaml-dev as a >> problem. > > +1 > > Having base packages working and maintained is more important than two leaf > packages! > > Any programs or libs using these libs? No reverse dependencies according to apt-rdepends, and grepping through /var/lib/apt/lists/*Sources, I didn't find any reverse build dependencies, either. As I said, dropping the libz3-cil package has a higher priority, because that's what's preventing an update to a newer version of z3. If the OCaml bindings don't cause any trouble when I try to update the package, they may survive a little longer. Roman: Thanks for pointing out that the Python 2 bindings don't work! I am planning to include some autopkgtests, which are great for testing such basic package functionality (e. g. checking that one can import the Python package). This should hopefully prevent such problems in the future, or at least make them much easier to detect. I'll try to have a look at all this over the weekend. Best regards, Fabian
Bug#886590: Please add python3-z3 package
On 9/24/19 2:49 PM, Roman Lebedev wrote: > On Tue, Sep 24, 2019 at 3:32 PM Sylvestre Ledru wrote: >> >> Hello >> >> >> Le 24/09/2019 à 12:51, Roman Lebedev a écrit : >>> Bump. Any chance this could be prioritized? >>> Lack of python3-z3 package prevents me from porting >>> some other python2 software to python3. >> >> Thanks to the work of Fabian Wolff, we have a better version of z3. > I'm a little bit out of context here, of *z3* or of z3 packaging? > Also, link? The z3 *package* was several years behind upstream z3, so I put in some work to package a more recent version of z3 for Debian, which is what Sylvestre was referring to. >> I don't know if he is planning to work on this soon but if you write a patch >> i would be happy to sponsor it. I can work on it; in fact, there has been a new upstream release of z3 (4.8.6, current Debian is 4.8.4), which I'd also like to package. *However*, there is one big problem: In order to build the libz3-cil package (.NET bindings), z3 (starting from version 4.8.5) requires the 'dotnet' command: https://github.com/dotnet/cli/tree/master/src/dotnet This command isn't currently available in Debian, and I have no plans of packaging it, because I'm very inexperienced with Mono et al. (and packaging thereof). Rather, I'd like to take this as an opportunity to drop the libz3-cil (and maybe also libz3-ocaml-dev) package altogether. Those two packages cause _by far_ the highest maintenance effort, and I dare presume that they were the main reason why nobody has bothered to update the z3 package for so long. The question is: Wouldn't it be better to have more regular updates and better maintenance in general of the z3 package (I'd even consider co-maintaining it, given that Michael Tautschnig hasn't made an upload for this package in almost four years), at the cost of dropping those two little-used (according to Popcon) packages? Because I suppose that I'm not the only one not very knowledgeable about Mono and OCaml packaging, and this is a pretty large barrier to working on the z3 package (because nobody wants to break these two packages, so they decide not to touch z3 at all). But now, building the libz3-cil package is no longer possible unless somebody packages the dotnet command (in which case we could always reintroduce it), and as to the OCaml bindings, I have to admit that I'm not even sure whether they are currently functioning at all (I had to do some patching in the build system even just to get them to build). So, in conclusion: If I'm allowed to drop these two packages (but especially libz3-cil), I will have a look at packaging the newer upstream release, and, while doing so, I can also include a new python3-z3 package (and probably drop the Python 2 package, given that it's reaching its end-of-life soon). What are your thoughts on this? Best regards, Fabian
Bug#940243: RFS: eqonomize 1.4.2-1 -- personal accounting software for the small household economy
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for a QA upload of the eqonomize package. The only change I made has been the introduction of a new upstream version. The package can be found on Mentors, and my changes are also in the Git repository on Salsa: https://mentors.debian.net/package/eqonomize https://salsa.debian.org/debian/eqonomize Thanks for your help! Best regards, Fabian
Bug#940241: RFS: backintime 1.2.1-1 -- simple backup/snapshot system
Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: j...@debian.org
Dear mentors,
I am looking for a sponsor for an upload of the 'backintime' package.
I have already made the previous upload (1.1.24-0.1) for this package, and the
maintainer,
Jonathan Wiltshire, has offered me to join him as co-maintainer of the package:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881205#34
I wrote to him about this new upload a couple of weeks ago, but I did not get a
response,
so I suspect he is still short on time, and that his offer to co-maintain the
package still
holds. I have added him in the X-Debbugs-CC field of this email just to be sure.
The new upload fixes various bugs, including one release critical bug
pertaining to the
removal of Qt 4. The changes are summarized in the latest changelog entry:
backintime (1.2.1-1) unstable; urgency=medium
* Add myself as co-maintainer in debian/control.
* New upstream release (Closes: #930589, #935341, #879611).
* Upgrade to Standards-Version 4.4.0 (no changes).
* Upgrade to debhelper compat level 12.
* Remove debian/patches (all fixed upstream).
* Introduce new backintime-qt package, because upstream moved from
Qt 4 to Qt 5. Make backintime-qt4 a transitional package.
* Drop the transitional backintime-{gnome,kde} packages
(Closes: #939139, #939140).
-- Fabian Wolff Sat, 14 Sep 2019 14:36:13 +0200
The package is available on Mentors, and I have put my changes in a forked
repository on
Salsa (I will push to the original repository once this upload has been
accepted):
https://mentors.debian.net/package/backintime
https://salsa.debian.org/wolff-guest/pkg-backintime
Thank you very much for your help!
Best regards,
Fabian
Bug#935900: RFS: z3 4.8.4-0.1 [NMU]
Great, thank you! Yes, I'm also hoping that the package will migrate quickly and smoothly. But the results so far (e. g. it builds on all release architectures) look promising! On 9/4/19 12:24 PM, Gianfranco Costamagna wrote: > git was already correct, I sponsored it! > > lets hope it migrates fast in testing, I also added some tweak in rules file > and changed a little bit changelog > > thanks for your contribution to Debian! > > G.
Bug#935900: RFS: z3 4.8.4-0.1 [NMU]
On 8/27/19 4:00 PM, Matthew Fernandez wrote: >> z3 (4.8.4-0.1) unstable; urgency=medium > > I am not a z3 dev, but the latest z3 release is 4.8.5. Is there a > particular motivation for uploading a 4.8.4-based release? Thanks for pointing this out; I did not notice this, because I was using uscan, and upstream suddenly changed the tag format on Github for tagging new releases: https://github.com/Z3Prover/z3/tags In the last hour or so, I have tried to import version 4.8.5, but they apparently changed something in the build system so that building with Mono no longer works (it fails with 'dotnet: Command not found', and I don't know what the Mono equivalent of the dotnet command is, or if one exists at all). So, I'd say having version 4.8.4 is still better than 4.4.1, and if someone else wants to give 4.8.5 another try in the future, they can do so after this upload.
Bug#935900: RFS: z3 4.8.4-0.1 [NMU]
Package: sponsorship-requests Severity: normal X-Debbugs-CC: m...@debian.org X-Debbugs-CC: locutusofb...@debian.org Dear mentors, I am looking for a sponsor for a non-maintainer upload of the z3 package. The z3 package is several years out of date (see #909494), and it is maintained in a packaging team anyways, so I think a NMU is warranted here to finally get the package back into shape. My changes are summarized in the latest changelog entry: z3 (4.8.4-0.1) unstable; urgency=medium * Non-maintainer upload. * New upstream release (Closes: #909494). * Add debian/gbp.conf. * Update and reorganize patches. * Upgrade to debhelper compat level 12. * Upgrade to Standards-Version 4.4.0 (no changes). * Remove trailing whitespace from debian/control. * Build-Depend on libnum-ocaml-dev (Closes: #934048). -- Fabian Wolff Tue, 27 Aug 2019 14:30:11 +0200 My changes can be found on Salsa, and I will create a Merge Request referencing this RFS soon: https://salsa.debian.org/wolff-guest/z3 The package is also available on Mentors: https://mentors.debian.net/package/z3 Thanks for your help! Best regards, Fabian
Bug#935808: RFS: dbacl 1.14.1-2 [QA upload]
On 8/27/19 12:20 AM, Sergio Durigan Junior wrote: > On Monday, August 26 2019, Fabian Wolff wrote: > >> Dear mentors, >> >> I am looking for a sponsor for a QA upload of the dbacl package. >> >> This upload attempts to fix a FTBFS bug (#916182), and I have also performed >> some standard package maintenance tasks. >> >> I will push to the proper repository (in the Debian group on Salsa) as >> soon as I have the required permissions on Salsa; in the meantime, you >> can find my changes here: https://salsa.debian.org/wolff-guest/dbacl >> >> And also on Mentors: https://mentors.debian.net/package/dbacl > > Hm, I wasn't able to generate the orig tarball; maybe you forgot to push > the pristine-tar branch? No, I forgot to add --pristine-tar when doing gbp import-orig, and I don't know how to do it retroactively; I guess that whoever imports the next upstream version can create the branch (or somebody more knowledgeable about git-buildpackage can do it now for the current version). > While at it, please follow the standard being used to organize the build > deps (1 item per line): > > + flex, bison > > Out of curiosity, why do you have to regenerate the parser/lexer files? Hm, somebody else already uploaded the package now, so I can't change it anymore for this upload. As for why I have to regenerate the lexer and parser, I think some of the arguments from [0] apply, but in particular, just including in dbacl.h did not fix the FTBFS issue; I actually had to regenerate the lexer and parser for my changes to take effect (or maybe I just made a mistake somewhere - I don't have much experience with flex/bison). In any case, thank you very much for having a look at my changes (and also for creating the Salsa repositories!). Best regards, Fabian [0] https://wiki.debian.org/Autoreconf#General_reasoning_for_autoreconfing
Bug#935808: RFS: dbacl 1.14.1-2 [QA upload]
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for a QA upload of the dbacl package. This upload attempts to fix a FTBFS bug (#916182), and I have also performed some standard package maintenance tasks. I will push to the proper repository (in the Debian group on Salsa) as soon as I have the required permissions on Salsa; in the meantime, you can find my changes here: https://salsa.debian.org/wolff-guest/dbacl And also on Mentors: https://mentors.debian.net/package/dbacl Thanks for your help! Best regards, Fabian
Bug#935806: RFS: ffe 0.3.9-1 [QA upload]
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for a QA upload of the ffe package. I have mainly imported a new upstream version and performed some standard package maintenance tasks. I will push to the proper repository (in the Debian group on Salsa) as soon as I have the required permissions on Salsa; in the meantime, you can find my changes here: https://salsa.debian.org/wolff-guest/ffe And also on Mentors: https://mentors.debian.net/package/ffe Thanks for your help! Best regards, Fabian
Bug#935804: RFS: aj-snapshot 0.9.9-1 [QA upload]
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for a QA upload of the aj-snapshot package. I have mainly imported a new upstream version and performed some standard package maintenance tasks. I will push to the proper repository (in the Debian group on Salsa) as soon as I have the required permissions on Salsa; in the meantime, you can find my changes here: https://salsa.debian.org/wolff-guest/aj-snapshot And also on Mentors: https://mentors.debian.net/package/aj-snapshot Thanks for your help! Best regards, Fabian
Bug#935765: RFS: eqonomize 1.4.1-1 [QA upload]
Package: sponsorship-requests
Severity: normal
Dear mentors,
I am looking for a sponsor for a QA upload of the eqonomize package.
My changes can be found on Salsa: https://salsa.debian.org/debian/eqonomize
I have mainly imported a new upstream version and performed some standard
package maintenance tasks (Ondřej Nový pushed one commit to the Salsa
repository a while ago, so I've kept him in the changelog):
eqonomize (1.4.1-1) unstable; urgency=medium
* QA upload.
[ Ondřej Nový ]
* d/control: Fix wrong Vcs-*
[ Fabian Wolff ]
* New upstream release.
* Upgrade to Standards-Version 4.4.0 (no changes).
* Upgrade to debhelper compat level 12.
* Update debian/copyright.
-- Fabian Wolff Mon, 26 Aug 2019 00:37:56 +0200
Lintian reports one warning regarding an icon having the wrong size, which I
have forwarded to upstream: https://github.com/Eqonomize/Eqonomize/issues/88
Other than that, the package should be in good shape; here is the Mentors
report: https://mentors.debian.net/package/eqonomize
Thanks for your help!
Best regards,
Fabian
Bug#935763: RFS: doclifter/2.19-1 [QA upload]
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for a QA upload of the doclifter package. My changes include mostly just standard maintenance work and a new upstream release: doclifter (2.19-1) unstable; urgency=medium * QA upload. * New upstream release. * Upgrade to Standards-Version 4.4.0 (no changes). * Upgrade to debhelper compat level 12. -- Fabian Wolff Sun, 25 Aug 2019 23:56:47 +0200 These changes can be found on Salsa: https://salsa.debian.org/debian/doclifter And I've also uploaded the package to Mentors: https://mentors.debian.net/package/doclifter Thanks for your help! Best regards, Fabian
Bug#925053: unblock: squirrel3/3.1-6
Control: tags -1 - moreinfo On Wed, 20 Mar 2019 13:02:13 +0100 Emilio Pozuelo Monfort wrote: > Yeah, it's too late for debhelper compat bumps really. Please revert that and > remove the moreinfo tag when that's done. The rest looks fine. I have now reverted the debhelper compat bump. I have also updated the meta-information of one of the two patches (the issue has been fixed upstream in the meantime). I have attached a debdiff between the version in testing (3.1-5) and the new version in unstable (3.1-7). Thanks, Fabian diff -Nru squirrel3-3.1/debian/changelog squirrel3-3.1/debian/changelog --- squirrel3-3.1/debian/changelog 2017-09-17 21:31:30.0 +0200 +++ squirrel3-3.1/debian/changelog 2019-03-20 20:37:02.0 +0100 @@ -1,3 +1,22 @@ +squirrel3 (3.1-7) unstable; urgency=medium + + * Revert upgrade to debhelper compat level 12. + * Update meta-information of 02-sphinx-ext.patch. + + -- Fabian Wolff Wed, 20 Mar 2019 20:37:02 +0100 + +squirrel3 (3.1-6) unstable; urgency=medium + + * Update Vcs-Git and Vcs-Browser fields in debian/control. + * Add patch 02-sphinx-ext.patch to disable the pngmath Sphinx +extension (Closes: #923012). + * Add Applied-Upstream field to header of patch +01-fix-spelling-errors.patch. + * Upgrade to Standards-Version 4.3.0 (no changes). + * Upgrade to debhelper compat level 12. + + -- Fabian Wolff Sun, 03 Mar 2019 01:37:29 +0100 + squirrel3 (3.1-5) unstable; urgency=medium * Update debian/copyright. diff -Nru squirrel3-3.1/debian/control squirrel3-3.1/debian/control --- squirrel3-3.1/debian/control 2017-09-17 21:31:30.0 +0200 +++ squirrel3-3.1/debian/control 2019-03-20 20:37:02.0 +0100 @@ -9,10 +9,10 @@ texlive-latex-extra, texlive-generic-extra, latexmk -Standards-Version: 4.1.0 +Standards-Version: 4.3.0 Homepage: http://squirrel-lang.org/ -Vcs-Git: https://anonscm.debian.org/git/collab-maint/squirrel3.git -Vcs-Browser: https://anonscm.debian.org/cgit/collab-maint/squirrel3.git +Vcs-Git: https://salsa.debian.org/wolff-guest/squirrel3.git/ +Vcs-Browser: https://salsa.debian.org/wolff-guest/squirrel3 Package: squirrel3 Architecture: any diff -Nru squirrel3-3.1/debian/patches/01-fix-spelling-errors.patch squirrel3-3.1/debian/patches/01-fix-spelling-errors.patch --- squirrel3-3.1/debian/patches/01-fix-spelling-errors.patch 2017-09-17 21:31:30.0 +0200 +++ squirrel3-3.1/debian/patches/01-fix-spelling-errors.patch 2019-03-20 20:37:02.0 +0100 @@ -3,7 +3,8 @@ false positive). Author: Fabian Wolff Forwarded: https://github.com/albertodemichelis/squirrel/pull/30 -Last-Update: 2016-04-03 +Applied-Upstream: https://github.com/albertodemichelis/squirrel/commit/6db0aa2095da222d06a0690eaacd5a8966c0651e +Last-Update: 2019-03-03 --- This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ --- a/sq/sq.c diff -Nru squirrel3-3.1/debian/patches/02-sphinx-ext.patch squirrel3-3.1/debian/patches/02-sphinx-ext.patch --- squirrel3-3.1/debian/patches/02-sphinx-ext.patch 1970-01-01 01:00:00.0 +0100 +++ squirrel3-3.1/debian/patches/02-sphinx-ext.patch 2019-03-20 20:37:02.0 +0100 @@ -0,0 +1,19 @@ +Description: Remove pngmath extension from Sphinx configuration +Author: Fabian Wolff +Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923012 +Forwarded: https://github.com/albertodemichelis/squirrel/issues/176 +Applied-Upstream: https://github.com/albertodemichelis/squirrel/commit/ca2c74b319ce379a00b646750bbbcd6cb81a39ed +Last-Update: 2019-03-20 +--- +This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ +--- a/doc/source/conf.py b/doc/source/conf.py +@@ -30,7 +30,7 @@ + # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom + # ones. + extensions = [ +-'sphinx.ext.pngmath', ++#'sphinx.ext.pngmath', + ] + + # Add any paths that contain templates here, relative to this directory. diff -Nru squirrel3-3.1/debian/patches/series squirrel3-3.1/debian/patches/series --- squirrel3-3.1/debian/patches/series 2017-09-17 21:31:30.0 +0200 +++ squirrel3-3.1/debian/patches/series 2019-03-20 20:37:02.0 +0100 @@ -1 +1,2 @@ 01-fix-spelling-errors.patch +02-sphinx-ext.patch
Bug#925053: unblock: squirrel3/3.1-6
Hi Andreas, thanks so much for uploading those changes! I prepared them some time ago, but unfortunately really didn't get around to uploading the package, so I'm glad you took the initiative. This is to let the Release Team know that I, as the package maintainer, fully endorse this upload (in case it makes a difference). Best regards, Fabian signature.asc Description: OpenPGP digital signature
Bug#923041: Scala interpreter cannot interpret files
Package: scala
Version: 2.11.12-4
Severity: important
Dear maintainer,
consider the following Scala script test.scala:
println("Hello, world!")
If I try to run
$ scala test.scala
I get the following output:
error: Compile server encountered fatal condition:
javax/tools/DiagnosticListener
java.lang.ClassNotFoundException: javax.tools.DiagnosticListener
[...]
Interestingly, the call stack differs for repeated executions, so I have not
included it here.
Running scala -e 'println("Hello, world!")' produces a similar error message,
but executing the code manually in the REPL seems to work.
Although the exception being thrown is a different one, this is probably
related to #903140. In particular, I do not have Java 8 installed, and my
default Java version is 11.
Please try to have a look at this soon - ideally, this problem should be fixed
before the buster freeze, because it really does impact the usability of the
package...
Kind regards,
Fabian
Bug#916967: dwardump: passing any options prevents output
Control: tags -1 + upstream Dear Tj, thanks for reporting this problem. I am hereby forwarding it to dwarfdump's upstream developer, David Anderson. David, could you have a look at this? Thank you! Best regards, and happy holidays, Fabian On 12/20/18 10:18 PM, Tj wrote: > Package: dwarfdump > Version: 20180809-1 > Severity: important > > Whilst using dwarfdump (amd64 build) on MIPS ELF files I discovered that > adding any > command-line options (such as '-v' or '-x abi=mips') somehow prevents > the program from writing any output. > > I then tried it on x86_64 ELF files, and on another system, and got someone > else to verify it. > > This affects (at least) the package versions 20180129-1 and 20180809-1. > > I then fetched and built the upstream source and it exhibits the same > problem. >
Bug#881205: NMU for backintime 1.1.24
Hi Jonathan, On Fri, 29 Jun 2018 22:21:54 +0100, Jonathan Wiltshire wrote: > Would you like to co-maintain? If so, please add yourself to uploaders and > prepare a maintainer upload (rather than NMU). I added you to the > repository members in anticipation. Thanks. In principle, I'd be interested in co-maintaining the package, but unfortunately, I don't think that I have the time for it right now. I might reconsider co-maintaining this package in the future, though. For the time being, I'd like to leave it at a NMU. Can I proceed with the NMU? If so, would you like to sponsor it, or should I look for a sponsor elsewhere? Best regards, Fabian
Bug#901880: transition: libantlr3c
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Dear Release Team, I would hereby like to request a transition slot for libantlr3c. The current version of libantlr3c in experimental, 3.4+dfsg-1, includes a patch for the RC bug #900601 that changes the public API of the library. It also includes a new upstream version with a different SONAME. The package builds on all release architectures [0]. The reverse dependencies of libantlr3c (belle-sip, cvc4 and forked-daapd) can all be built with the libantlr3c version from experimental (build logs are available at [1]). Therefore, binNMUs for these packages should be sufficient. The auto-generated tracker file at [2] looks good to me. Thank you! Best regards, Fabian [0] https://buildd.debian.org/status/package.php?p=libantlr3c&suite=experimental [1] https://salsa.debian.org/snippets/86 [2] https://release.debian.org/transitions/html/auto-libantlr3c.html
Bug#881205: NMU for backintime 1.1.24
Hi, since there has not been any progress on this for a while now, I have decided to prepare a non-maintainer upload myself, including the latest upstream release, 1.1.24, as well as some minor maintenance work. Jonathan, could you have a look at this? Of course I won't upload a NMU without your consent. Also, I would need a sponsor. I have uploaded my package to Mentors: https://mentors.debian.net/package/backintime I have also forked your repository and pushed my changes: https://salsa.debian.org/wolff-guest/pkg-backintime If you're satisfied with my changes, I can add a debian/1.1.24-0.1 tag and open a merge request, or you could give me write access to your repository so that I can push the changes myself. Thanks! Best regards, Fabian
Bug#898557: RFS: doclifter/2.17-1 [QA upload]
On Mon, May 14, 2018 at 08:10:24PM +0200, Tobias Frost wrote: > On Mon, May 14, 2018 at 05:33:03PM +0200, Fabian Wolff wrote: > > On Mon, May 14, 2018 at 11:03:58AM -0400, Sergio Durigan Junior wrote: > > > Thanks! And yeah, I'd say it's OK to just start from scracth in this > > > case. > > > > I have imported every version I found on snapshot.debian.org into the > > repository, so at least some history is available now. > > That sounds you've done it manually... In this case > gbp import-dscs --debsnap will be your friend ;.) Yes, I did indeed do it manually ... Thanks for the hint!
Bug#898557: RFS: doclifter/2.17-1 [QA upload]
On Mon, May 14, 2018 at 11:03:58AM -0400, Sergio Durigan Junior wrote: > Thanks! And yeah, I'd say it's OK to just start from scracth in this > case. I have imported every version I found on snapshot.debian.org into the repository, so at least some history is available now. > Done: > > https://salsa.debian.org/debian/doclifter Thanks! I've just pushed my changes there, and I reuploaded the package to Mentors: https://mentors.debian.net/package/doclifter I have added the Vcs-Git and Vcs-Browser fields, of course, and I also followed the Multiarch hinter's suggestion [0] to mark the python dependency with ":any"; could you have another look at this? Thank you! [0] https://tracker.debian.org/pkg/doclifter
Bug#898557: RFS: doclifter/2.17-1 [QA upload]
On Sun, May 13, 2018 at 08:38:41PM -0400, Sergio Durigan Junior wrote: > Have you considered moving this package to salsa? It'd be a shame to > not have a VCS for it. Sure, I can do that. The only problem is that since the Bazaar repository is no longer reachable, I don't have the commit history. > The package is good as is. I'll wait on your reply above salsa above, > and then upload it. If you don't have time/don't want to move it to > salsa, just let me know. Could you create a doclifter repository in the Debian group and give me (wolff-guest) write access to it? Then I'll populate the repository and reupload the package to Mentors.
Bug#898557: RFS: doclifter/2.17-1 [QA upload]
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for a QA upload of the doclifter package. My changes are summarized in the latest changelog entry: doclifter (2.17-1) unstable; urgency=medium * QA upload. * Set Maintainer to Debian QA Group in debian/control (see #854220). * New upstream release (Closes: #739048). * Upgrade to debhelper compat level 11. * Remove Vcs-Bzr and Vcs-Browser fields from debian/control (the repository is no longer reachable). * Upgrade to Standards-Version 4.1.4 in debian/control (no changes). * Remove "Suggests: python-profiler" line from debian/control as python-profiler is no longer part of any Debian distribution. * Remove useless ">= 2.2" version restriction of python dependency. * Update patches. * Upgrade to version 4 format in debian/watch (no changes). * Upgrade debian/copyright to the machine-readable format. * Delete trailing whitespace from debian/changelog in order to silence the file-contains-trailing-whitespace Lintian tag. * Add xmlto as a build dependency in debian/control. -- Fabian Wolff Sun, 13 May 2018 15:38:52 +0200 The package is available on Mentors: https://mentors.debian.net/package/doclifter https://mentors.debian.net/debian/pool/main/d/doclifter/doclifter_2.17-1.dsc Thank you! Best regards, Fabian
Bug#897376: RFS: fox1.6/1.6.57-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "fox1.6". This is a routine upload with a new upstream release and only relatively minor changes otherwise. My changes are summarized in the latest changelog entry: fox1.6 (1.6.57-1) unstable; urgency=medium * New upstream release. * Upgrade to Standards-Version 4.1.4 in debian/control (no changes). * Upgrade to debhelper compat level 11. * Remove libtiff-dev (which is in Section oldlibs) as an alternative to libtiff5-dev in the Depends field of libfox-1.6-dev in debian/control. * Update debian/copyright. * Remove trailing whitespace from debian/changelog and debian/control in order to silence the file-contains-trailing-whitespace Lintian tag. -- Fabian Wolff Mon, 23 Apr 2018 21:32:14 +0200 The package is available on Mentors: https://mentors.debian.net/package/fox1.6 https://mentors.debian.net/debian/pool/main/f/fox1.6/fox1.6_1.6.57-1.dsc And also in the packaging Git repository: https://salsa.debian.org/wolff-guest/fox1.6 I will add a debian/1.6.57-1 tag once the package has been uploaded. Best regards, Fabian
Bug#897046: RFS: link-grammar/5.4.4-1 [QA upload]
On Mon, Apr 30, 2018 at 08:27:02PM -0400, Sergio Durigan Junior wrote: > Hm, I think you forgot to push the upstream/pristine-tar branches, > because I can't rebuild the tarball here. Could you do that, please? Are you sure? The upstream/5.5.0 tag seems to be available in the Salsa repository: https://salsa.debian.org/debian/link-grammar/tags/upstream%2F5.5.0 Also, I just tried to reproduce your problem by cloning the Salsa repository in an empty directory on my system and then running gbp-buildpackage, but everything worked fine for me. Could you perhaps give me some more details about your problem? > The package looks good to me, so I'll upload after you push these > branches and rebuild it locally. BTW, if anyone ask me, I think you'd > be a good maintainer for this package ;-). Thanks! I will consider adopting this package in the future ... Best regards, Fabian
Bug#897046: RFS: link-grammar/5.4.4-1 [QA upload]
On Mon, Apr 30, 2018 at 01:16:04PM -0400, Sergio Durigan Junior wrote: > Thank to everybody who replied. Really appreciated. > > Fabian, I think it's OK if you just update the upstream project's > copyright info, so I agree with the proposed modification you suggested > above. > > Please let me know when you push it, and I'll upload the package. Somebody else has made an upload yesterday: https://tracker.debian.org/news/953154/accepted-link-grammar-5316-3-source-into-unstable/ The packaging repository was not updated, which is why I had to import the changes manually. This is a bit unfortunate, but I did not want to rebase all my work at this point (also, to my knowledge, the 'master' branch is a protected branch by default on Salsa, which means that force-pushing is not allowed). However, I did manage to make the changes available in the repository by different means (see the debian/5.3.16-3 tag). To further complicate things, there has also been a new upstream release. I have imported this new release as well, pushed everything to the Salsa repository and reuploaded the package to Mentors.
Bug#897046: RFS: link-grammar/5.4.4-1 [QA upload]
On Mon, Apr 30, 2018 at 12:24:42PM +0200, Steve Langasek wrote:
> I don't think you should be taking it upon yourself to add copyright
> statements regarding debian/ contents where authors have not asserted their
> copyright up front. There is precious little in debian/, outside of
> debian/patches/, which should generally be considered copyrightable in a
> well-done package.
I see. Then how about updating debian/copyright simply like so:
"""
diff --git a/debian/copyright b/debian/copyright
index f72a2e5..9e71f1f 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -12,8 +12,8 @@ Copyright: 2003-2004 Daniel Sleator
2007 Mike Ross
2008 Filip Maric
2008-2010 Borislav Iordanov
[-2008-2016-]{+2008-2018+} Linas Vepstas
[-2014-2016-]{+2014-2018+} Amir Plivatsky
License: LGPL-2.1
Files: bindings/java/org/linkgrammar/JSONReader.java
"""
This seems to match the activity in the upstream repository:
https://github.com/opencog/link-grammar/graphs/contributors
Bug#896704: RFS: python-picklable-itertools/0.1.1-2 [RC]
On Fri, Apr 27, 2018 at 12:47:12PM -0400, Sergio Durigan Junior wrote: > I've uploaded the package now. Great, thank you!
Bug#896704: RFS: python-picklable-itertools/0.1.1-2 [RC]
On Tue, Apr 24, 2018 at 10:55:00PM -0400, Sergio Durigan Junior wrote:
> Or you can also move the package under the Debian Python Modules Team
> umbrella, if it makes more sense. Packaging Python modules with the
> DPMT is the preferred way nowadays, but that's really up to you (and
> just to be clear, I have no problem if you decide to maintain the
> package by yourself).
I have joined the DPMT and created a repository there:
https://salsa.debian.org/python-team/modules/python-picklable-itertools
I have also set the DPMT as Maintainer in debian/control.
> I think it's best if we keep the package unchanged for now. Sorry about
> this extra round-trip, but can you please re-add the Python 2 package?
>
> Actually, I've just noticed that the lintian flag in question
> ("new-package-should-not-package-python2-module") only applies to the
> first upload of the package, and will actually be gone once we upload
> this next version, so there's really nothing that needs to be done from
> your part about it. I'm sorry about the noise.
>
> Once you reintroduce the Python 2 package, I'll do the upload.
I have reuploaded the package to Mentors:
https://mentors.debian.net/package/python-picklable-itertools
Best regards,
Fabian
Bug#897046: RFS: link-grammar/5.4.4-1 [QA upload]
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for a QA upload of the link-grammar package. My changes are summarized in the latest changelog entry: link-grammar (5.4.4-1) unstable; urgency=medium * QA upload. * New upstream release. * Update symbols file. * Remove trailing whitespace from debian/changelog in order to silence the file-contains-trailing-whitespace Lintian tag. * Upgrade to debhelper compat version 11. * Remove the empty file debian/patches/series. * Use HTTPS URI in debian/watch. * Upgrade to Standards-Version 4.1.4 (no changes). * Add debian/python3-link-grammar.lintian-overrides to override the python-package-depends-on-package-from-other-python-variant Lintian tag. * Update Vcs-Browser and Vcs-Git fields in debian/control. * Update Homepage field in debian/control and Source field in debian/copyright to use HTTPS. * Remove incorrect Multi-Arch fields in debian/control. -- Fabian Wolff Fri, 27 Apr 2018 15:35:36 +0200 I have to admit that I'm not entirely sure about the Multi-Arch fields that I removed. The link-grammar binary package installs an architecture-dependent binary into /usr/bin, but it was marked Multi-Arch: foreign, which looked suspect to me. Also, the liblink-grammar-java package seems to have an incorrect Multi-Arch field according to the Multiarch hinter: https://tracker.debian.org/pkg/link-grammar Other than that, I made sure that the autopkgtests pass and that the package is mostly Lintian-clean, save for several package-has-unnecessary-activation-of-ldconfig-trigger warnings (which, according to the Lintian tag documentation, might be due to a debhelper bug) and an orig-tarball-missing-upstream-signature warning (which I would blame on git-buildpackage, see #872864). The package is available on Mentors: https://mentors.debian.net/package/link-grammar Thank you! Best regards, Fabian
Bug#896704: RFS: python-picklable-itertools/0.1.1-2 [RC]
On Mon, Apr 23, 2018 at 08:58:30PM -0400, Sergio Durigan Junior wrote:
> Hi Fabian,
>
> I can help with it, but there are two things I'd like to see first.
Thank you for your review!
> 1) There are no Vcs-* fields, and it's unclear to me where the git
> repository for the package is located (I couldn't find it on
> salsa.d.o).
I did not maintain the package in a public Git repository so far, so I
created a fresh repository, imported my changes and put it on Salsa:
https://salsa.debian.org/wolff-guest/python-picklable-itertools
I have added Vcs-Git and Vcs-Browser fields accordingly.
> 2) If having the Python 2 version of this package is important for some
> reason, could you please override the lintian warning
> ("new-package-should-not-package-python2-module")?
I think that the Python 2 version is not really important; in fact, I
did not even include it in the original package, but my previous
sponsor for this package suggested that I should add it (see #841228).
I have now simply removed the Python 2 package from debian/control; is
this sufficient, or do I have to do anything more than that?
I have reuploaded the package to Mentors with the aforementioned
changes.
Best regards,
Fabian
Bug#896704: RFS: python-picklable-itertools/0.1.1-2 [RC]
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "python-picklable-itertools". The current version of this package is missing a dependency, which is why it fails to import on systems where that dependency is not installed (see #896213, #896214). dh-python did not find this dependency, and I apparently only tested the package on systems that happened to have the missing dependency installed, which is why importing worked fine for me. I have now manually added the missing dependency in debian/control. In order to (hopefully) avoid this problem in the future, I have also added a Testsuite field in debian/control. My changes are summarized in the latest changelog entry: python-picklable-itertools (0.1.1-2) unstable; urgency=medium * Depend on python[3]-pkg-resources (Closes: #896213, #896214). * Add Testsuite field to debian/control. * Upgrade to Standards-Version 4.1.4 (no changes). * Upgrade to debhelper compat level 11 (no changes). -- Fabian Wolff Mon, 23 Apr 2018 18:30:09 +0200 The package is available on Mentors: https://mentors.debian.net/package/python-picklable-itertools https://mentors.debian.net/debian/pool/main/p/python-picklable-itertools/python-picklable-itertools_0.1.1-2.dsc Thank you! Best regards, Fabian
Bug#894616: RFS: eqonomize/1.2.0-1 [QA upload]
On Fri, Apr 13, 2018 at 09:19:41PM +0200, Tobias Frost wrote: > Hi Fabian, > > LGTM, Uploading! Great, thanks! > (The only thing you could do is to file those patches upstream to get > them included.) Done. I probably should have done this right away. Best regards, Fabian
Bug#894637: RFS: apparix/11-062-1 [QA upload]
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for a QA upload of the apparix package. My changes are summarized in the latest changelog entry: apparix (11-062-1) unstable; urgency=medium * QA upload. * New upstream release (Closes: #643670). * Update debian/watch. * Set Debian QA Group as Maintainer in debian/control (see #741089). * Upgrade to Standards-Version 4.1.3 in debian/control. * Upgrade to debhelper compat level 11. * Rewrite debian/rules. * Update debian/copyright to the machine-readable format. * Add 00-fix-spelling.patch. -- Fabian Wolff Mon, 02 Apr 2018 18:39:00 +0200 The package is available on Mentors: https://mentors.debian.net/package/apparix https://mentors.debian.net/debian/pool/main/a/apparix/apparix_11-062-1.dsc Thank you! Best regards, Fabian
Bug#894616: RFS: eqonomize/1.2.0-1 [QA upload]
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for a QA upload of the eqonomize package. My changes are summarized in the latest changelog entry: eqonomize (1.2.0-1) unstable; urgency=medium * QA upload. * New upstream release. * Build with Qt 5 (Closes: #874860). * Remove eqonomize-doc's recommendation of khelpcenter4 (Closes: #886536). * Update Homepage field in debian/control. * Update debian/copyright. * Update debian/watch. * Update eqonomize[-doc].install files (Closes: #875530). * Upgrade to debhelper compat level 11. * Upgrade to Standards-Version 4.1.3 in debian/control (no changes). * Update patches. * Enable hardening flags in debian/rules. * Add doc-base registration file for eqonomize-doc. * Add 03-fix-spelling.patch. * Update Vcs-Git and Vcs-Browser fields in debian/control. * Mark eqonomize-doc as Multi-Arch: foreign. -- Fabian Wolff Mon, 02 Apr 2018 14:43:28 +0200 The package is available on Mentors: https://mentors.debian.net/package/eqonomize https://mentors.debian.net/debian/pool/main/e/eqonomize/eqonomize_1.2.0-1.dsc Thank you! Best regards, Fabian
Bug#894576: RFS: ffe/0.3.8-1 [QA upload]
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for a QA upload of the ffe package. My changes are summarized in the latest changelog entry: ffe (0.3.8-1) unstable; urgency=medium * QA upload. * New upstream release. * Upgrade to debhelper compat level 11. * Upgrade to Standards-Version 4.1.3 in debian/control (no changes). * Update debian/watch to version 4 format (no changes). * Remove debian/dirs (not needed). * Remove trailing whitespace from old changelog entries to silence the file-contains-trailing-whitespace Lintian tag. -- Fabian Wolff Sun, 01 Apr 2018 21:15:13 +0200 The package is available on Mentors: https://mentors.debian.net/package/ffe https://mentors.debian.net/debian/pool/main/f/ffe/ffe_0.3.8-1.dsc Thank you! Best regards, Fabian
Bug#894528: RFS: dbacl/1.14.1-1 [QA upload]
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for a QA upload of the dbacl package. My changes are summarized in the latest changelog entry: dbacl (1.14.1-1) unstable; urgency=medium * QA upload. * New upstream release. * Update debian/watch to version 4 format (no changes). * Update debian/copyright to the machine-readable format. * Upgrade to debhelper compat level 11. * Update patches: - Use quilt. - Update patch 01_manpage_doc_paths.diff and rename it to 00-fix-man-page-paths.patch. - Update patch 10_fix_bashisms.patch and rename it to 01-fix-bashisms.patch. - Delete 20_autotools_update.patch (useless with dh_autoreconf). - Add 02-fix-spelling.patch, 03-fix-find-param.patch and 04-fix-ldflags.patch. * Rewrite debian/rules to use debhelper (instead of CDBS). * Upgrade to Standards-Version 4.1.3 in debian/control (no changes). * Add build dependency on libncurses-dev (Closes: #646734). -- Fabian Wolff Sat, 31 Mar 2018 21:59:24 +0200 The package is available on Mentors: https://mentors.debian.net/package/dbacl https://mentors.debian.net/debian/pool/main/d/dbacl/dbacl_1.14.1-1.dsc Thank you! Best regards, Fabian
Bug#894506: RFS: aj-snapshot/0.9.8-1 [QA upload]
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for a QA upload of the aj-snapshot package. My changes are summarized in the latest changelog entry: aj-snapshot (0.9.8-1) unstable; urgency=medium * QA upload. * New upstream release. * Update debian/copyright. * Upgrade to debhelper compat level 11: - Remove useless dh-autoreconf build dependency. - Remove unnecessary --parallel dh argument in debian/rules. - Remove unnecessary --with autoreconf dh argument in debian/rules. * Upgrade to Standards-Version 4.1.3 in debian/control (no changes). * Remove fixman.patch (fixed upstream). * Add 00-fix-long-options.patch (Closes: #715625). -- Fabian Wolff Sat, 31 Mar 2018 15:09:03 +0200 The package is available on Mentors: https://mentors.debian.net/package/aj-snapshot https://mentors.debian.net/debian/pool/main/a/aj-snapshot/aj-snapshot_0.9.8-1.dsc Thank you! Best regards, Fabian
Bug#880771: libdwarf/dwarfdump cross compile
Control: tags -1 + fixed-upstream On Tue, Mar 27, 2018 at 10:02:25AM -0700, David Anderson wrote: > code/dwarfdump/configure and code/libdwarf/configure > now support cross building. see code/README. That's good to hear. Thank you very much for the effort you put into this!
Bug#892053: libtcod-dev: Debian Buster: external/pstdint.h not found
tag 892053 pending thanks On Sun, Mar 04, 2018 at 04:24:57PM +, Matthew Lugg wrote: > Dear Maintainer, > >When attempting to use a project which makes use of libtcod, I >encountered the error `external/pstdint.h: No such file or >directory`. This is an issue in libtcod_portability.h which affects >Debian Buster and potentially other versions (untested). It can be >easily resolved by changing `#include external/pstdint.h` on line >138 to `#include pstdint.h`. > >Thanks! Dear Matthew, thanks for pointing this out to me! I have fixed this issue in my libtcod packaging repository, and I will probably upload a new release of the package soon. Best regards, Fabian
Bug#886989: fox1.6: please make the build reproducible
tag 886989 pending thanks On Fri, Jan 12, 2018 at 03:38:31PM +0530, Chris Lamb wrote: > Hi, > > Whilst working on the Reproducible Builds effort [0], we noticed > that fox1.6 could not be built reproducibly. > > This is because the date call in debian/rules (which does use > SOURCE_DATE_EPOCH - thanks!) does not correct ensure the timezone > is consistent across builds). > > Patch attached. Thanks! I have already made a similar change in the Git packaging repository a few days ago: https://salsa.debian.org/wolff-guest/fox1.6/commit/8c94797f19c504968d7b5a35cea6793cd08b9f14 But I have now included your full patch, so the next upload of fox1.6 should be reproducible again. Regards, Fabian
Bug#868054: stretch-pu: package dwarfutils/20161124-1+deb9u1
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu
Dear Release Team,
I would like to propose the following changes to the dwarfutils
package in stretch:
* Add patch 02-fix-CVE-2017-9052.patch to fix CVE-2017-9052 and
CVE-2017-9055 (Closes: #864064).
* Add patch 03-fix-CVE-2017-9053.patch to fix CVE-2017-9053.
* Add patch 04-fix-CVE-2017-9054.patch to fix CVE-2017-9054.
* Add patch 05-fix-CVE-2017-9998.patch to fix CVE-2017-9998
(Closes: #866968).
This update would fix all currently known vulnerabilities in the
dwarfutils package in stretch. All changes have been cherry-picked
from the upstream development repository, and all of them are already
in unstable.
I have attached the debdiff that I would like to apply to the current
version in stable.
Thank you!
Kind regards,
Fabian
diff -Nru dwarfutils-20161124/debian/changelog
dwarfutils-20161124/debian/changelog
--- dwarfutils-20161124/debian/changelog2016-11-25 14:23:27.0
+0100
+++ dwarfutils-20161124/debian/changelog2017-07-11 15:33:51.0
+0200
@@ -1,3 +1,14 @@
+dwarfutils (20161124-1+deb9u1) stable; urgency=medium
+
+ * Add patch 02-fix-CVE-2017-9052.patch to fix CVE-2017-9052 and
+CVE-2017-9055 (Closes: #864064).
+ * Add patch 03-fix-CVE-2017-9053.patch to fix CVE-2017-9053.
+ * Add patch 04-fix-CVE-2017-9054.patch to fix CVE-2017-9054.
+ * Add patch 05-fix-CVE-2017-9998.patch to fix CVE-2017-9998
+(Closes: #866968).
+
+ -- Fabian Wolff Tue, 11 Jul 2017 15:33:51 +0200
+
dwarfutils (20161124-1) unstable; urgency=medium
* New upstream release.
diff -Nru dwarfutils-20161124/debian/patches/02-fix-CVE-2017-9052.patch
dwarfutils-20161124/debian/patches/02-fix-CVE-2017-9052.patch
--- dwarfutils-20161124/debian/patches/02-fix-CVE-2017-9052.patch
1970-01-01 01:00:00.0 +0100
+++ dwarfutils-20161124/debian/patches/02-fix-CVE-2017-9052.patch
2017-07-11 15:33:51.0 +0200
@@ -0,0 +1,31 @@
+Description: Fix CVE-2017-9052 and CVE-2017-9055
+Origin: upstream,
https://sourceforge.net/p/libdwarf/code/ci/cc37d6917011733d776ae228af4e5d6abe9613c1/
+Bug: https://www.prevanders.net/dwarfbug.html#DW201703-006
+Bug-Debian: https://bugs.debian.org/864064
+Last-Update: 2017-07-08
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/libdwarf/dwarf_form.c
b/libdwarf/dwarf_form.c
+@@ -934,6 +934,10 @@
+ switch (attr->ar_attribute_form) {
+
+ case DW_FORM_data1:
++if (attr->ar_debug_ptr >= section_end) {
++_dwarf_error(dbg, error, DW_DLE_DIE_BAD);
++return DW_DLV_ERROR;
++}
+ *return_sval = (*(Dwarf_Sbyte *) attr->ar_debug_ptr);
+ return DW_DLV_OK;
+
+--- a/libdwarf/dwarf_query.c
b/libdwarf/dwarf_query.c
+@@ -377,7 +377,7 @@
+ }
+ if (_dwarf_reference_outside_section(die,
+ (Dwarf_Small*) info_ptr,
+-(Dwarf_Small*) info_ptr)) {
++((Dwarf_Small*) info_ptr)+1)) {
+ _dwarf_error(dbg, error,DW_DLE_ATTR_OUTSIDE_SECTION);
+ return DW_DLV_ERROR;
+ }
diff -Nru dwarfutils-20161124/debian/patches/03-fix-CVE-2017-9053.patch
dwarfutils-20161124/debian/patches/03-fix-CVE-2017-9053.patch
--- dwarfutils-20161124/debian/patches/03-fix-CVE-2017-9053.patch
1970-01-01 01:00:00.0 +0100
+++ dwarfutils-20161124/debian/patches/03-fix-CVE-2017-9053.patch
2017-07-11 15:33:51.0 +0200
@@ -0,0 +1,86 @@
+Description: Fix CVE-2017-9053
+Origin: upstream,
https://sourceforge.net/p/libdwarf/code/ci/cc37d6917011733d776ae228af4e5d6abe9613c1/
+Bug: https://www.prevanders.net/dwarfbug.html#DW201703-005
+Bug-Debian: https://bugs.debian.org/864064
+Last-Update: 2017-07-08
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/libdwarf/dwarf_loc.c
b/libdwarf/dwarf_loc.c
+@@ -237,6 +237,10 @@
+ break;
+
+ case DW_OP_const1u:
++if (loc_ptr >= section_end) {
++_dwarf_error(dbg,error,DW_DLE_LOCEXPR_OFF_SECTION_END);
++return DW_DLV_ERROR;
++}
+ operand1 = *(Dwarf_Small *) loc_ptr;
+ loc_ptr = loc_ptr + 1;
+ if (loc_ptr > section_end) {
+@@ -247,6 +251,10 @@
+ break;
+
+ case DW_OP_const1s:
++if (loc_ptr >= section_end) {
++_dwarf_error(dbg,error,DW_DLE_LOCEXPR_OFF_SECTION_END);
++return DW_DLV_ERROR;
++}
+ operand1 = *(Dwarf_Sbyte *) loc_ptr;
+ SIGN_EXTEND(operand1,1);
+ loc_ptr = loc_ptr + 1;
+@@ -372,6 +380,10 @@
+ break;
+
+ case DW_OP_pick:
++if (loc_ptr >= section_end) {
++_dwarf_error(dbg,error,DW_DLE_LOCEXPR_OFF_SECTION_END);
++return DW_DLV_ERROR;
++}
+ operand1 = *(Dwarf_Small *) loc_ptr;
+ loc_ptr = loc_ptr + 1;
+ i
Bug#757048: Alive ping
I am really sorry that this is taking so long, but I am still working on this. In particular, at the recommendation of the upstream developers, I have been waiting for version 1.5 of CVC4, which has finally been released yesterday: http://cvc4.cs.stanford.edu/web/2017/07/10/cvc4-1-5-released/ Regards, Fabian signature.asc Description: PGP signature
Bug#835865: RFP: blocks -- deep learning framework build on the top of Theano
On Sun, Nov 20, 2016 at 05:31:40PM +0100, Daniel Stender wrote: > I haven't discussed this yet with the ITP holder (busy), but as foreseeable > sponsor and > reporter of this bug I say that's all right. We could name the source package > that way, > no problem. Sorry for the delay. Yes, of course I will change the name of the package if there is a conflict with the name of another project. Thanks for pointing this out to me. Kind regards, Fabian
Bug#841228: RFS: python-picklable-itertools/0.1.1-1 [ITP] -- picklable reimplementation of Python's itertools
On Sun, Oct 23, 2016 at 06:02:05PM +, Gianfranco Costamagna wrote: > just a question, why aren't you packaging the Python2 version? > (the question is that I would like to avoid another binNEW queue in case some > other people asks for it) In this document https://www.debian.org/doc/packaging-manuals/python-policy/ch-python3.html it says "Programs should use Python 3, and should not be packaged for Python 2 as well." On rereading it, though, I realized that this only applies to Python programs, whereas the rules are less strict for Python libraries. I have added a Python 2 package and reuploaded the package to Mentors. Regards, Fabian
Bug#841646: RFS: libtcod/1.6.1+dfsg-1 -- graphics and utility library for roguelike developers
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "libtcod". The main change since the last upload was the introduction of a new "python-libtcod" package that offers Python bindings for libtcod. Since I am relatively new to Python packaging, I would appreciate it if someone could review the changes pertaining to the Python package in particular. Thank you! Changes since the last upload: * New upstream release. * Fix debian/watch. * Update patches: - Remove 0001-Use-global-zlib.h.patch (fixed upstream). - Rewrite 0002-Fix-soname.patch as 00-fix-makefile.patch. - Remove 0003-Fix-spelling-errors.patch (fixed upstream). - Remove 0005-Fix-warnings.patch (fixed upstream). - Rename patch 0004-Fix-cppcheck.patch as 01-fix-cppcheck.patch. * Update symbols file. * Adjust debian/rules. * Update debian/copyright. * Install upstream changelog. * Add the python-libtcod package. * Add patch 02-python-multiarch.patch to help the Python wrapper find libtcod.so in /usr/lib//. * Add debian/clean file and override_dh_auto_clean target in debian/rules. Further information: * Package name: libtcod Version : 1.6.1+dfsg-1 Upstream Author : Richard Tew * URL : https://bitbucket.org/libtcod/libtcod * License : BSD-3 Section : libs It builds those binary packages: libtcod-dev - development files for the libtcod roguelike library libtcod0 - graphics and utility library for roguelike developers python-libtcod - Python bindings for the libtcod library To access further information about this package, please visit the following URL: https://mentors.debian.net/package/libtcod Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/libt/libtcod/libtcod_1.6.1+dfsg-1.dsc Regards, Fabian Wolff
Bug#841228: RFS: python-picklable-itertools/0.1.1-1 [ITP] -- picklable reimplementation of Python's itertools
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "python-picklable-itertools": * Package name: python-picklable-itertools Version : 0.1.1-1 Upstream Author : David Warde-Farley * URL : https://github.com/mila-udem/picklable-itertools * License : Expat Section : python This package is a dependency for blocks (#835865). It builds those binary packages: python3-picklable-itertools - picklable reimplementation of Python's itertools To access further information about this package, please visit the following URL: https://mentors.debian.net/package/python-picklable-itertools Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/python-picklable-itertools/python-picklable-itertools_0.1.1-1.dsc Regards, Fabian Wolff
Bug#841209: ITP: python-picklable-itertools -- a picklable reimplementation of Python's itertools
Package: wnpp Severity: wishlist Owner: Fabian Wolff * Package name: python-picklable-itertools Version:: 0.1.1 Upstream Author : David Warde-Farley * URL : https://github.com/mila-udem/picklable-itertools * License:: Expat Programming Lang: Python Description : a picklable reimplementation of Python's itertools picklable-itertools is a reimplementation of the Python standard library's "itertools", in Python, using picklable iterator objects. It should serve as a drop-in replacement in cases where functionality from itertools is used, but serializability has to be maintained. This package is a dependency for blocks (#835865).
Bug#835743: z3: FTBFS: ../src/util/mpz.cpp:137:8: error: call of overloaded 'set(mpz&, long unsigned int)' is ambiguous
Control: tags -1 + upstream patch fixed-upstream Hi, the following patch fixes this issue: --- a/src/util/mpz.cpp +++ b/src/util/mpz.cpp @@ -134,7 +134,7 @@ #endif mpz one(1); -set(m_two64, UINT64_MAX); +set(m_two64, static_cast(UINT64_MAX)); add(m_two64, one, m_two64); } The problem has already been fixed in the upstream repository by this commit: https://github.com/Z3Prover/z3/commit/27399309009314f56cdfbd8333f287b1a9b7a3a6 Kind regards, Fabian
Bug#835754: z3: FTBFS: util/debug.cpp:79:38: error: cannot convert 'std::basic_istream' to 'bool' in initialization
Control: tags = patch fixed-upstream
Hi,
the issue here is that GCC 6 defaults to -std=gnu++14. Since C++11,
std::basic_ios no longer provides an implicit void* operator but only
an explicit bool operator. Therefore, the problem can be fixed with
this patch:
--- a/src/util/debug.cpp
+++ b/src/util/debug.cpp
@@ -76,7 +76,7 @@
for (;;) {
std::cerr << "(C)ontinue, (A)bort, (S)top, (T)hrow exception, Invoke
(G)DB\n";
char result;
-bool ok = (std::cin >> result);
+bool ok = bool(std::cin >> result);
if (!ok) exit(ERR_INTERNAL_FATAL); // happens if std::cin is eof or
unattached.
switch(result) {
case 'C':
Reference: http://en.cppreference.com/w/cpp/io/basic_ios/operator_bool
This was fixed in the upstream repository by this commit:
https://github.com/Z3Prover/z3/commit/f02d273ee39ae047222e362c37213d29135dc661
Kind regards,
Fabian
signature.asc
Description: PGP signature
Bug#834745: jessie-pu: package dwarfutils/20120410-2+deb8u1
Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu
Dear release team,
I would like to propose the following changes to the dwarfutils
package in jessie:
* New maintainer.
* Add patch CVE-2015-8538.patch to fix CVE-2015-8538 (Closes: #807817).
* Add patch CVE-2015-8750.patch to fix CVE-2015-8750 (Closes: #813182).
* Add patch CVE-2016-2050.patch to fix CVE-2016-2050.
* Add patch CVE-2016-2091.patch to fix CVE-2016-2091 (Closes: #813148).
* Add patch CVE-2016-5034.patch to fix CVE-2016-5034.
* Add patch CVE-2016-5036.patch to fix CVE-2016-5036.
* Add patch CVE-2016-5038.patch to fix CVE-2016-5038.
* Add patch CVE-2016-5039.patch to fix CVE-2016-5039.
* Add patch CVE-2016-5042.patch to fix CVE-2016-5042.
The current version in stable is rather old and still has Troy Heber
listed as the package maintainer, who orphaned the package a few years
ago. I am the new maintainer.
Because of the rather large number of patches, I have decided against
replicating them in this bug report, but each one of them features a
DEP-3 conformant header with information regarding its origin and, if
applicable, the corresponding Debian bug, so I hope you won't have
much trouble navigating them.
I have attached the debdiff I would like to apply to the current
version in stable.
Thank you!
Kind regards,
Fabian
diff -u dwarfutils-20120410/debian/changelog
dwarfutils-20120410/debian/changelog
--- dwarfutils-20120410/debian/changelog
+++ dwarfutils-20120410/debian/changelog
@@ -1,3 +1,18 @@
+dwarfutils (20120410-2+deb8u1) stable; urgency=medium
+
+ * New maintainer.
+ * Add patch CVE-2015-8538.patch to fix CVE-2015-8538 (Closes: #807817).
+ * Add patch CVE-2015-8750.patch to fix CVE-2015-8750 (Closes: #813182).
+ * Add patch CVE-2016-2050.patch to fix CVE-2016-2050.
+ * Add patch CVE-2016-2091.patch to fix CVE-2016-2091 (Closes: #813148).
+ * Add patch CVE-2016-5034.patch to fix CVE-2016-5034.
+ * Add patch CVE-2016-5036.patch to fix CVE-2016-5036.
+ * Add patch CVE-2016-5038.patch to fix CVE-2016-5038.
+ * Add patch CVE-2016-5039.patch to fix CVE-2016-5039.
+ * Add patch CVE-2016-5042.patch to fix CVE-2016-5042.
+
+ -- Fabian Wolff Tue, 16 Aug 2016 15:27:35 +0200
+
dwarfutils (20120410-2) unstable; urgency=low
* Fix FTBFS on Debian GNU/Hurd by Barry deFreese
diff -u dwarfutils-20120410/debian/control dwarfutils-20120410/debian/control
--- dwarfutils-20120410/debian/control
+++ dwarfutils-20120410/debian/control
@@ -1,8 +1,7 @@
Source: dwarfutils
Section: libs
Priority: optional
-Maintainer: Troy Heber
-Uploaders:
+Maintainer: Fabian Wolff
Build-Depends: debhelper (>> 9), quilt (>= 0.47), libelf-dev, binutils-dev
Standards-Version: 3.9.3.1
diff -u dwarfutils-20120410/debian/patches/series
dwarfutils-20120410/debian/patches/series
--- dwarfutils-20120410/debian/patches/series
+++ dwarfutils-20120410/debian/patches/series
@@ -2,0 +3,9 @@
+CVE-2016-5034.patch
+CVE-2016-2050.patch
+CVE-2015-8538.patch
+CVE-2015-8750.patch
+CVE-2016-2091.patch
+CVE-2016-5042.patch
+CVE-2016-5039.patch
+CVE-2016-5038.patch
+CVE-2016-5036.patch
only in patch2:
unchanged:
--- dwarfutils-20120410.orig/debian/patches/CVE-2015-8538.patch
+++ dwarfutils-20120410/debian/patches/CVE-2015-8538.patch
@@ -0,0 +1,340 @@
+Description: Fix for CVE-2015-8538 (OOB read)
+Origin:
http://sourceforge.net/p/libdwarf/code/ci/da724a0bc5eec8e9ec0b0cb0c238a80e34466459/
+Bug-Debian: https://bugs.debian.org/807817
+
+--- a/libdwarf/dwarf_abbrev.c
b/libdwarf/dwarf_abbrev.c
+@@ -126,6 +126,10 @@
+ attr = (Dwarf_Half) utmp2;
+ DECODE_LEB128_UWORD(abbrev_ptr, utmp2);
+ attr_form = (Dwarf_Half) utmp2;
++if (!_dwarf_valid_form_we_know(dbg,attr_form,attr)) {
++_dwarf_error(NULL, error, DW_DLE_UNKNOWN_FORM);
++return DW_DLV_ERROR;
++}
+
+ if (attr != 0)
+ (labbr_count)++;
+--- a/libdwarf/dwarf_die_deliv.c
b/libdwarf/dwarf_die_deliv.c
+@@ -657,13 +657,15 @@
+ Dwarf_Byte_Ptr info_ptr = 0;
+ Dwarf_Byte_Ptr abbrev_ptr = 0;
+ Dwarf_Word abbrev_code = 0;
+-Dwarf_Abbrev_List abbrev_list;
++Dwarf_Abbrev_List abbrev_list = 0;
+ Dwarf_Half attr = 0;
+ Dwarf_Half attr_form = 0;
+ Dwarf_Unsigned offset = 0;
+ Dwarf_Word leb128_length = 0;
+ Dwarf_Unsigned utmp = 0;
+ Dwarf_Debug dbg = 0;
++Dwarf_Error error = 0;
++int lres = 0;
+
+ info_ptr = die_info_ptr;
+ DECODE_LEB128_UWORD(info_ptr, utmp);
+@@ -673,8 +675,8 @@
+ }
+
+
+-abbrev_list = _dwarf_get_abbrev_for_code(cu_context, abbrev_code);
+-if (abbrev_list == NULL) {
++lres = _dwarf_get_abbrev_for_code(cu_context, abbrev_code, &abbrev_list,
&error);
++if (lres == DW_DLV_ERROR || lres == DW_DLV_NO_ENTRY) {
+ return (NULL);
+ }
+ dbg = cu_context->cc_dbg;
+@@ -833,6 +835,7 @@
+ Dwarf_Byte_Ptr die_info_
Bug#757048: ITP: cvc4 -- An automatic theorem prover for SMT problems
Control: owner -1 ! >From http://cs.nyu.edu/~mdeters/: The Department of Computer Science regrets to inform you that Morgan Deters passed away on Saturday, January 17, 2015. To ensure progress with this package, I'm claiming this ITP. I am already in contact with the upstream developers, so I hope to complete the task within a few weeks or so. Regards, Fabian
Bug#831962: binary packages in recent z3 uploads
Hi everybody, On Sat, Jul 23, 2016 at 08:19:33AM +, Gianfranco Costamagna wrote: > let me explain, we (Fabian to be honest) had to restrict the built binary > packages only to some > architectures, because -1 revision was failing somewhere. Yes, the main issue was that mono, required to build the libz3-cil package, is only available on a handful of platforms, so the -0.1 revision was BD-Uninstallable on quite a few platforms. To change that, I restricted the -cil package, along with its build dependencies, to those architectures that support mono, so that the remaining binaries would be available on all platforms. While I was at it, I decided to attempt to do the same for the -java and -jni packages. The -java package was arch:all, but it depends on the architecture-dependent -jni package, so it couldn't be installed on all platforms anyways. The main issue, however, is that the build system of z3 is capable of building either both the -jni and -java material, or neither. That means that z3 would fail to build on platforms that can't build the -jni package even when we're just trying to build the arch:all packages. > that said, I'm wondering about making the java package arch:all again, and > move > the java dependencies to build depends-indep target, maybe this will fix this > > issue in a better way. The -jni package remains architecture-dependent, however. This means that Java would still have to be present in *both* Build-Depends and Build-Depends-Indep, which would be kind of useless. I will have another look at this, although I probably won't get around to doing that before next week. -- Fabian
