Bug#1058704: ITP: nsncd -- Name service non-caching daemon
Cool! I'm one of the upstream maintainers for nsncd and a (somewhat inactive) DM. The Debian packaging in the upstream repo was written when Debian Rust support was nowhere near as mature, but we run this at my workplace on Debian and would be delighted to switch to official packaging. If it's helpful, I'm happy to accept PRs against the upstream packaging as long as I can figure out a way to keep building on oldstable onwards. Let me know if I can help in any other way! -- Geoffrey Thomas geo...@ldpreload.com On Thu, Dec 14, 2023, at 4:29 PM, Philipp Kern wrote: > Package: wnpp > Severity: wishlist > Owner: Philipp Kern > X-Debbugs-Cc: debian-de...@lists.debian.org, pk...@debian.org > > * Package name: nsncd > Version : 1.4.1 (plus patches[1]) > * URL : https://github.com/twosigma/nsncd > * License : Apache 2.0 > Programming Lang: Rust > Description : Name service non-caching daemon > > nsncd implements the NSCD (name-service caching daemon) protocol to > provide out-of-process NSS lookups but does not implement caching. > > It is designed to provide high-performance NSS lookups for programs > that are not using the system libc, while providing semantics as if > NSCD were not being used. > > This is useful in environments in which you are mixing binaries from > several sources. One such environment is Nix, where binaries will > be linked to a (hermetic) glibc from the Nix store. By dropping the > need to cache, nsncd is a lot simpler than nscd - it's only purpose > is to decouple your binaries from the NSS modules you have configured, > which will continue to run under the system glibc. > > I'm going to maintain the package for the time being. If the Rust team > also wants to maintain Rust leaf software, I'm also happy to collaborate > there. > > Kind regards > Philipp Kern > > [1] The Nix people also added support for host resolution in > https://github.com/nix-community/nsncd/.
Bug#1037342: python3-pyfuse3: should Recommends fuse3
Package: python3-pyfuse3 Version: 3.2.1-2+b2 Severity: wishlist Hi! I tried running a sample filesystem with pyfuse3 on a fresh VM and got "fuse: failed to exec fusermount3: No such file or directory". I think the package should have Recommends: fuse3. -- Geoffrey Thomas geo...@ldpreload.com
Bug#913190: bash-completion: Update 'java' completion to support '.java' files
Control: severity -1 normal A side effect of the lack of support for .java files is that bash-completion will turn slashes into dots for a Java command line. For instance, if you type $ java /home/ and press TAB, it will turn into $ java .home. IMO this raises the request from a new feature to a borderline bug, because instead of simply failing to complete the final path component (but letting the user type it in themselves or use M-/), it corrupts the command line already entered by the user. -- Geoffrey Thomas geo...@twosigma.com
Bug#991156: unblock: config-package-dev/5.6 [pre-approval]
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: config-package-...@mit.edu Hi release team, This is a pre-approval request to get a sense of your willingness to unblock config-package-dev to handle usrmerge/dpkg issues. [ Reason ] config-package-dev is a Debhelper (and CDBS) add-on for writing packages that use dpkg-divert to customize other packages' behavior. (The target audience is people customizing Debian for a university/company/etc. or preparing derivatives. Notable public users include Debathena and Whonix. That is, config-package-dev is a leaf package in the Debian archive, with no build-rdeps.) As noted on https://wiki.debian.org/Teams/Dpkg/MergedUsr , "dpkg-divert is currently broken by" the current implementation of usrmerge. What this seems to mean, specifically, is that if you divert a binary by the wrong name - e.g., dpkg-divert /bin/less instead of /usr/bin/less - the diversion is useless, and the underlying package can overwrite a file that was supposed to be diverted. I think config-package-dev ought to address this, somehow. Some options are listed in my email to our mailing list, where I also demonstrate what can go wrong: http://mailman.mit.edu/pipermail/config-package-dev/2021-July/66.html Options range from just documenting the issue to actually trying to address it in some fashion. I don't yet have a change ready for any of these options; I'm trying to gauge what you think is acceptable vs. too risky at this point in freeze. [ Impact ] A user on a usrmerged system could easily notice a file in (e.g.) /usr/bin and try to build a config-package of it without realizing the file actually lives in (e.g.) /bin. Things would even appear to work after installing the config-package, because the file would get renamed on disk; they would break after the underlying package (the target of the diversion) gets upgraded or reinstalled. [ Tests ] The examples directory contains a handful of sample source packages using most of config-package-dev's features. autopkgtests cover building but not installing those packages, so testing would be manual. Also, the tests only cover the positive case, using the correct paths, as opposed to the negative case, but manual testing of that would be easy (see the linked email above for essentially a currently-failing test case). [ Risks ] As noted, this is a leaf package within the Debian archive, so the risk to Debian itself from getting the change wrong would be low. The major alternative here would be fixing dpkg to handle diversions (and perhaps many other things) correctly on a usrmerged system. From the tone of the discussion, I would guess that this certainly isn't going to happen before Bullseye release, but if you're aware of work along those lines, I would be happy to wait for that / contribute to it / test it. [ Checklist ] [ ] all changes are documented in the d/changelog [ ] I reviewed all changes and I approve them [ ] attach debdiff against the package in testing [ Other info ] I'm open to whatever level of change you think is fine. I would prefer fixing it (somehow) to merely documenting it; if you think I should try to fix it and come back with a debdiff, I'm happy to do that. unblock config-package-dev/5.6 Thanks, -- Geoffrey Thomas https://ldpreload.com geo...@ldpreload.com
Bug#974531: krb5: Please include upstream fix "Unregister thread key in SPNEGO finalization"
Package: krb5 Version: 1.17-10 Hi maintainers, We're affected by the bug fixed in this upstream krb5 commit: https://github.com/krb5/krb5/commit/07ff54d0 I'm mostly filing this because we want this patch in Stretch LTS, but I think the process for that is including it in Sid and Buster first. I see that the patch is included in the latest 1.18 upload to experimental. It was backported to upstream's 1.17 branch here: https://github.com/krb5/krb5/commit/994f5f51 but 1.17.2 hasn't been released yet. I'd be happy to help by providing debdiffs or packages to sponsor or whatever if that's useful, but I'm guessing I should just wait for 1.17.2 to be released and reach unstable, and then file bugs for Buster and Stretch LTS? Thanks, -- Geoffrey Thomas geo...@twosigma.com
Bug#873012: Patch for broken live migration in qemu in stretch
Control: tag -1 patch
I ended up tracking this down - the problem is that the target qemu
accepts the NBD connection from the source but does not handle any of the
data on the socket. That plus Berni's comment that the NBD security
patches caused the regression helped me figure out what was going wrong
and get a proper fix to the security patches.
The patch
nbd-fully-initialize-client-in-case-of-failed-negotiation-CVE-2017-9524.patch
was not backported / cherry-picked properly. It's taken from this commit
in qemu 2.10:
https://github.com/qemu/qemu/commit/df8ad9f128c15aa0a0ebc7b24e9a22c9775b67af
Note that the backported patch moves around a call to nbd_set_handlers(),
which doesn't exist in the upstream commit. The upstream commit has a call
to nbd_client_receive_next_request() which _isn't_ moved by the patch;
that call doesn't exist in the backported commit. That's because this call
to nbd_set_handlers() was changed to nbd_client_receive_next_request() in
qemu 2.9:
https://github.com/qemu/qemu/commit/ff82911cd3f69f028f2537825c9720ff78bc3f19
If you adjust the backported patch to leave nbd_set_handlers() alone
instead of moving it around, the NBD server starts to work, and live
migration works again. I've tested this by patching the qemu on the target
hypervisor and doing a live migration using Stretch's versions of
OpenStack and libvirt (nova live-migration --block-migrate, VM disks are
qcow2 on local disk).
I've attached a debdiff of the local build I'm using. You should be able
to fix the version number in d/changelog and upload. If it would help for
me to prepare packages for upload (I'll need sponsorship, but I can upload
to mentors or something with my DM key) or open a pull request to Salsa, I
can do that too. (Not totally sure what the process is for an update to
stable.)
--
Geoffrey Thomas
https://ldpreload.com
geo...@ldpreload.comdiff -Nru qemu-2.8+dfsg/debian/changelog qemu-2.8+dfsg/debian/changelog
--- qemu-2.8+dfsg/debian/changelog 2018-11-08 15:41:45.0 +
+++ qemu-2.8+dfsg/debian/changelog 2019-04-05 19:02:53.0 +
@@ -1,3 +1,14 @@
+qemu (1:2.8+dfsg-6+deb9u5+geofft1) stretch-security; urgency=medium
+
+ * Fix improper backport of CVE-2017-9524 fix that caused NBD
+connections to hang (Closes: #873012).
+-
nbd-fully-initialize-client-in-case-of-failed-negotiation-CVE-2017-9524.patch:
+ Don't move nbd_set_handlers before nbd_negotiate.
+- nbd-fix-regression-on-resiliency-to-port-scan-CVE-2017-9524.patch:
+ Refresh.
+
+ -- Geoffrey Thomas Fri, 05 Apr 2019 19:02:53 +
+
qemu (1:2.8+dfsg-6+deb9u5) stretch-security; urgency=medium
* Backport SSBD support (Closes: #908682)
diff -Nru
qemu-2.8+dfsg/debian/patches/nbd-fix-regression-on-resiliency-to-port-scan-CVE-2017-9524.patch
qemu-2.8+dfsg/debian/patches/nbd-fix-regression-on-resiliency-to-port-scan-CVE-2017-9524.patch
---
qemu-2.8+dfsg/debian/patches/nbd-fix-regression-on-resiliency-to-port-scan-CVE-2017-9524.patch
2018-05-26 10:04:06.0 +
+++
qemu-2.8+dfsg/debian/patches/nbd-fix-regression-on-resiliency-to-port-scan-CVE-2017-9524.patch
2019-04-05 19:02:53.0 +
@@ -140,15 +140,15 @@
}
static void nbd_read(void *opaque)
-@@ -1410,7 +1410,7 @@ static coroutine_fn void nbd_co_client_start(void
*opaque)
- nbd_set_handlers(client);
+@@ -1409,7 +1409,7 @@ static coroutine_fn void nbd_co_client_s
+ qemu_co_mutex_init(>send_lock);
if (nbd_negotiate(data)) {
-client_close(client);
+client_close(client, false);
goto out;
}
-
+ nbd_set_handlers(client);
@@ -1418,11 +1418,17 @@ out:
g_free(data);
}
diff -Nru
qemu-2.8+dfsg/debian/patches/nbd-fully-initialize-client-in-case-of-failed-negotiation-CVE-2017-9524.patch
qemu-2.8+dfsg/debian/patches/nbd-fully-initialize-client-in-case-of-failed-negotiation-CVE-2017-9524.patch
---
qemu-2.8+dfsg/debian/patches/nbd-fully-initialize-client-in-case-of-failed-negotiation-CVE-2017-9524.patch
2018-05-26 10:04:06.0 +
+++
qemu-2.8+dfsg/debian/patches/nbd-fully-initialize-client-in-case-of-failed-negotiation-CVE-2017-9524.patch
2019-04-05 19:02:53.0 +
@@ -51,14 +51,13 @@
+QTAILQ_INSERT_TAIL(>clients, client, next);
}
+qemu_co_mutex_init(>send_lock);
-+nbd_set_handlers(client);
+
if (nbd_negotiate(data)) {
client_close(client);
goto out;
}
-qemu_co_mutex_init(>send_lock);
--nbd_set_handlers(client);
+ nbd_set_handlers(client);
-if (exp) {
-QTAILQ_INSERT_TAIL(>clients, client, next);
Bug#921401: RM: prelink -- ROM, dead upstream
Package: ftp.debian.org Severity: normal Hi ftp-master, Please remove src:prelink - the package is unmaintained upstream (no releases or SVN commits since 2013) and was removed from Fedora (where the upstream maintainer was packaging it) several releases ago. It has a bad habit of breaking binaries (see open bugs) and I don't think there's enough of a development community to really fix it; the remaining bugs likely require very arcane ELF magic to resolve properly. There are two binary packages, prelink and execstack. I don't think execstack is of much use by itself, espcially because any build scripts etc. using execstack can generally be replaced with the linkerflag -Wl,-z,noexecstack (or execstack, whichever you need). But if someone's interested I can try to split it out of the prelink source package. (Fedora currently has an "execstack" source package from the prelink tarball, but I think they care more than we do because SELinux blocks programs with executable stacks by default.) -- Geoffrey Thomas https://ldpreload.com geo...@ldpreload.com
Bug#914036: config-package-dev: scripts directly access internal dpkg database
On Sun, 18 Nov 2018, Guillem Jover wrote:
Source: config-package-dev
Source-Version: 5.5
Severity: important
User: debian-d...@lists.debian.org
Usertags: dpkg-db-access-blocker
Hi!
This package contain scripts that directly access the dpkg internal
database [S], instead of using the correct public interface
«dpkg --verify» (note that it currently does not return an error exit
code when it finds modified files, that will be fixed in 1.19.3, but
you can always just check the output).
[S] check-files.mk, dh_configpackage
Both check-files.mk and dh_configpackage use dpkg-query --control-path
$package md5sums, and only fall back to /var/lib/dpkg/info when that
option doesn't exit. Is that enough?
(I can drop the fallback if you'd like - we wanted to support backports to
LTSes but that code was written in 2011 so any current supported release
certainly has --control-path. Relatedly, we could probably switch to
--control-show at this point too if you'd like, but see also
https://bugs.debian.org/735021 .)
I suppose we could use dpkg --verify, which would in theory simplify
the code because (if I'm testing it right) it handles conffiles and
non-conffiles just the same, and so we don't need a special case for
dpkg-query -W'${Conffiles}'. But there are two downsides to it:
- It's less efficient, since it verifies all files in the package instead
of just the one we want to check.
- As far as I can tell, it doesn't distinguish "This file has not been
modified" from "I have no md5sums for this file". It's very rare to see a
package with a missing or incomplete md5sums control file these days, but
we do handle that case currently (we print an error if it's incomplete,
and a warning if the package has no md5sums at all) and I'd like to keep
handling it.
Do you think you can extend the --verify interface to support querying an
individual file by name, and print an error if the file could not be
verified?
If you can do a dpkg --verify-file (where dpkg figures out the package
name, and prints an error if the file is unknown or the owning package
doesn't provide md5sums) then I can skip most of the complexity in what
I'm doing and just call that in newer versions of dpkg. :) I could also
use a dpkg --verify "$package" --verify-file "$file", or something.
--
Geoffrey Thomas
https://ldpreload.com
geo...@ldpreload.com
Bug#891670: pymssql FTBFS with freetds-dev 1.00.82-2
I've been busy, sorry - feel free to team upload/NMU it but I'm hoping to get to it this weekend. -- Geoffrey Thomas (via mobile) geo...@ldpreload.com > On Jan 28, 2019, at 08:56, Raphael Hertzog wrote: > > Hi, > >> On Sun, 24 Jun 2018, Geoffrey Thomas wrote: >> Upstream is being slow to put out a new release, there's some blocker >> involving the new freetds. I asked if that was resolved yet: >> >> https://github.com/pymssql/pymssql/issues/528 >> >> At some point (probably in a month or two, honestly...) I'll cherry-pick the >> relevant patches if there's no release, but I'd prefer to see upstream be >> confident about the new freetds version. > > There's a new upstream release available. We need this package > updated for Python 3.7 for Kali so we will look into this if nobody > else is quicker. > > Cheers, > -- > Raphaël Hertzog ◈ Debian Developer > > Support Debian LTS: https://www.freexian.com/services/debian-lts.html > Learn to master Debian: https://debian-handbook.info/get/
Bug#902323: python-pathlib: Should this package be removed?
Source: python-pathlib Version: 1.0.1-2 [cc python-pathlib2 uploader] Hi! At the Brooklyn BSP, Lincoln and I were looking at the FTBFS #897496, and we found that this package is deprecated upstream in favor of python-pathlib2. This package hasn't had a Debian upload since 2015, and python-pathlib2 is actively maintained both upstream and in Debian. Also, there appear to be three remaining reverse dependencies in unstable (down from 4 in stable, beets switched to Python 3): - python-pytest-benchmark - python-pyscss - python-eyed3 Does it make sense to switch those packages over to using python-pathlib2 and remove python-pathlib? If so, I'll move this bug to the FTP team and request removal once we get the switches to pathlib2 in. Lincoln is working on getting the upstream projects switched to pathlib2 and then submitting those patches to Debian. (pathlib2 requires doing `import pathlib2 as pathlib`, so there are code changes in addition to metadata/setup.py changes.) -- Geoffrey Thomas https://ldpreload.com geo...@ldpreload.com
Bug#874214: src:python-pathlib: please add python3-pathlib binary package
Piotr, What's the python3 package you're looking at / did you package it already? As far as I can tell, python-pathlib is deprecated upstream in favor of python-pathlib2, which is Python 2-only. (And Python 3 in Jessie and newer has pathlib in the standard library.) We ran across at a BSP (from #897496, FTBFS) and it seems like probably python-pathlib should be RM'd; it has increasingly few reverse dependencies, and they should probably be switched to python-pathlib2 too. So I want to make sure there's no new uses of this package, before suggesting an RM! -- Geoffrey Thomas https://ldpreload.com geo...@ldpreload.com
Bug#881826: devscripts: sadt: does not parse debian/control with comments
Package: devscripts Version: 2.17.11 User: devscri...@packages.debian.org Usertags: sadt sadt fails to correctly parse debian/control files that include comments in their build-dependencies, for instance: $ mkdir -p debian/tests $ cat > debian/control << EOF Source: s Build-Depends: # some comment here sl EOF $ cat > debian/tests/control << EOF Tests: sl-exists Depends: @builddeps@ EOF $ cat > debian/tests/sl-exists << EOF #!/bin/sh dpkg -l sl EOF $ sadt Traceback (most recent call last): File "/usr/bin/sadt", line 476, in main() File "/usr/bin/sadt", line 378, in main for n, para in enumerate(deb822.Packages.iter_paragraphs(file)): File "/usr/lib/python3/dist-packages/debian/deb822.py", line 378, in iter_paragraphs for section in parser: apt_pkg.Error: E:Unable to parse package file (1) This is refused by libapt-pkg's deb822 format parser, but permitted by the pure-Python one in python-debian, as noted in a comment in python-debian: :param use_apt_pkg: if sequence is a file, apt_pkg can be used if available to parse the file, since it's much much faster. Set this parameter to True to enable use of apt_pkg. Note that the TagFile parser from apt_pkg is a much stricter parser of the Deb822 format, particularly with regards whitespace between paragraphs and comments within paragraphs. If these features are required (for example in debian/control files), ensure that this parameter is set to False. The "Packages" subclass (which is intended for parsing Packages files in apt repos, not deb822 files in general) sets use_apt_pkg to true. The simplest fix is to change sadt line 378 to pass use_apt_pkg=False, but in theory, python-debian should gain a new subclass for debian/control files that has the _PkgRelationMixin but uses the more lenient parser. If you would like me to commit this change to the collab-maint repo, let me know. I've confirmed that it does fix the problem. -- Geoffrey Thomas https://ldpreload.com geo...@ldpreload.com
Bug#881825: devscripts: sadt: does not parse tests separated by commas
Package: devscripts
Version: 2.17.11
User: devscri...@packages.debian.org
Usertags: sadt
The autopkgtest spec says that test names can be separated by "comma
and/or whitespace" [1]. sadt only understands tests separated by
whitespace:
$ mkdir -p debian/tests
$ echo 'Source: foo' > debian/control
$ echo 'Tests: one, two' > debian/tests/control
$ ln -s /bin/true debian/tests/one
$ ln -s /bin/true debian/tests/two
$ sadt -v
one, ... SKIP (debian/tests/one, could not be made executable: [Errno 2] No
such file or directory: 'debian/tests/one,')
two ... ok
--
Ran 2 tests
OK (skipped=1)
autopkgtest itself implements this with .replace(',', ' ').split() [2],
which seems reasonable. Also the spec isn't clear but it looks like the
same should be done with restrictions and features.
If you would like me to commit this change to the collab-maint repo, let
me know. I've confirmed that it does fix the problem.
[1]
https://anonscm.debian.org/git/autopkgtest/autopkgtest.git/tree/doc/README.package-tests.rst
[2]
https://anonscm.debian.org/git/autopkgtest/autopkgtest.git/tree/lib/testdesc.py?h=4.3#n413
--
Geoffrey Thomas
https://ldpreload.com
geo...@ldpreload.com
Bug#876552: nm: [PATCH] gendered pronoun in explain_statement_am_ok
Package: nm.debian.org
Tags: patch
The am_ok page has the sentence, "The applicant will be notified once an
Application Manager is assigned who will contact him."
Attached is a patch to change the pronoun to "them". I think this is the
only one-gender usage in nm2. (There are a couple of "he/she" or "him/her"
usages; if you want to update those to "they" or "them" for consistency,
I'm happy to send in a patch for that too.)
Thanks,
--
Geoffrey Thomas
https://ldpreload.com
geo...@ldpreload.comFrom 1cd7bca265e71c850f99c682b5aeba5ccf3fb20e Mon Sep 17 00:00:00 2001
From: Geoffrey Thomas <geo...@ldpreload.com>
Date: Sat, 23 Sep 2017 12:33:16 -0400
Subject: [PATCH 1/1] explain_statement_am_ok: Use gender-neutral pronoun
---
process/templates/process/explain_statement_am_ok.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/process/templates/process/explain_statement_am_ok.html b/process/templates/process/explain_statement_am_ok.html
index 418d1c2..69126ee 100644
--- a/process/templates/process/explain_statement_am_ok.html
+++ b/process/templates/process/explain_statement_am_ok.html
@@ -6,7 +6,7 @@ information collected on this site, has a look to past contributions, asks a
few questions if needed, and tries to build some trust that {{person.fullname}}
should indeed be {{process.applying_for|desc_status}}.
-The applicant will be notified once an Application Manager is assigned who will contact him.
+The applicant will be notified once an Application Manager is assigned who will contact them.
{% if edit %}
As the Application Manager, paste a few lines describing the idea you have
--
2.1.4
Bug#875712: nova-placement-api fails to start with "unrecognized arguments"
Package: nova-placement-api Version: 2:14.0.0-4 Installing nova-placement-api results in a service that crashes (and gets respawned by systemd) with these logs: systemd[1]: Starting OpenStack Compute Placement API... systemd[1]: Started OpenStack Compute Placement API. nova-placement-api[37773]: usage: nova-placement-api [-h] [--port PORT] -- [passed options] nova-placement-api[37773]: nova-placement-api: error: unrecognized arguments: --config-file=/etc/nova/nova.conf --log-file=/var/log/nova/nova-placement-api.log systemd[1]: nova-placement-api.service: Main process exited, code=exited, status=2/INVALIDARGUMENT systemd[1]: nova-placement-api.service: Unit entered failed state. systemd[1]: nova-placement-api.service: Failed with result 'exit-code'. systemd[1]: nova-placement-api.service: Service hold-off time over, scheduling restart. systemd[1]: Stopped OpenStack Compute Placement API. systemd[1]: Starting OpenStack Compute Placement API... [etc.] It looks like nova-placement-api is not intended to be run as a standalone service, but is a wsgi script that should be called from Apache mod_wsgi. -- Geoffrey Thomas geo...@twosigma.com
Bug#873966: config-package-dev: transform operation error
On Fri, 1 Sep 2017, Bruno Maitre wrote:
Dear Maintainer,
When using the transform operation dh_configpackage will output that kind
of error:
Can't use string ("/ARRAY(0x55f37e2c3080)") as an ARRAY ref while "strict refs"
in use at /usr/bin/dh_configpackage line 394.
This error has been introduced by the correction of:
#803962 : config-package-dev: Requires leading slashes un debian/*.displace
For this correction we iterrate through the differents operation arrays to
add a leading slash if needed.
The problem is that @transformfiles is an array of array since it's created
with filedoublearray function and not the filearray function like the others
operation arrays (which are simples arrays).
This lead to an add of a slash in front of the reference array ARRAY(0xXXX...)
as can be seen in the error message.
Subsequent processing of transformfiles results in an error.
I've attached a patch with a way to fix this issue by removing transformfiles
from the leading slashes verification loop and by checking leading slashes in
the treatment of transformfiles itself as it was done before.
Note that I've triggered the error in a Debian testing environment and
the stable version is not affected.
Oops - thank you! I've applied the patch and I'll aim to do an upload that
fixes this tonight.
Also, I could have sworn I did a test run of building all the examples in
examples/, but indeed `apt-get source config-package-dev; cd
examples/debhelper/debathena-transform-example-1.0; dpkg-buildpackage`
fails. (And also fails in unstable because the example config file has
changed location.) We should really add a test suite to make sure the
examples build and produce the .debs we expect.
--
Geoffrey Thomas
https://ldpreload.com
geo...@ldpreload.com
Bug#873043: debhelper: Please mv Debian lib/Debian for case-insensitive filesystems
Package: debhelper Version: 10.7.2 Tags: patch Severity: wishlist Hi Debhelper maintainers, I would sort of like to use Debhelper to build Debian packages on macOS, as an alternative to homebrew etc. The general process of bootstrapping Debian on macOS takes a lot of steps, but one of the sillier steps is creating a case-sensitive disk image, because Debhelper ships both a debian/ and Debian/ directory. The default macOS root filesystem is case-preserving but not case-sensitive, so extracting a tarball containing debian/ and Debian/ will cause one directory to clobber the other. I have a commit at https://gitlab.com/geofft/debhelper which does a `git mv Debian lib/Debian` (removing the existing lib -> . symlink), plus a few fixes to point things at the Debian subdirectory. I've tested that the resulting binary packages are identical to the one in unstable, other than the changed path in debian/copyright (and the lack of doc/SMARTER-BUILDSYSTEMS, which seems not to have been committed to git). I've also confirmed that `prove -vwlr t`, as mentioned in the commit introducing the lib symlink, continues to pass. For review, you probably want to use `git show -M` on my patch to recognize the renames. Can you please consider applying this patch? Thanks! -- Geoffrey Thomas https://ldpreload.com geo...@ldpreload.com
Bug#871324: www.debian.org: [PATCH] Remove gendered pronouns in english/devel/join
Package: www.debian.org Severity: normal Tags: patch Hi www team, Almost all of the pronouns in https://www.debian.org/devel/join are "they"/"them", but there are a few uses of "he"/"his" and one "(s)he" to refer to the applicant. Below is a patch to make them all consistent. I haven't looked at the other languages (because I'm not super familiar with the norms for pronouns in other languages) so I'm not sure if the same issue exists in translations. --- Index: nm-advocate.wml === RCS file: /cvs/webwml/webwml/english/devel/join/nm-advocate.wml,v retrieving revision 1.15 diff -r1.15 nm-advocate.wml 51c51 < he will go through all steps of the New Member checks. --- they will go through all steps of the New Member checks. Index: nm-checklist.wml === RCS file: /cvs/webwml/webwml/english/devel/join/nm-checklist.wml,v retrieving revision 1.26 diff -r1.26 nm-checklist.wml 33c33 < what (s)he has done for Debian and a few bits about future plans. --- what they have done for Debian and a few bits about future plans. Index: nm-step3.wml === RCS file: /cvs/webwml/webwml/english/devel/join/nm-step3.wml,v retrieving revision 1.30 diff -r1.30 nm-step3.wml 71c71 <The Applicant can put the Social Contract in his own words, --- The Applicant can put the Social Contract in their own words, 125c125 < his understanding is up to the Application --- their understanding is up to the Application Index: nm-step4.wml === RCS file: /cvs/webwml/webwml/english/devel/join/nm-step4.wml,v retrieving revision 1.20 diff -r1.20 nm-step4.wml 17c17 < Applicant will need to demonstrate his skills in this area. --- Applicant will need to demonstrate their skills in this area. 28c28 < By maintaining a package, a prospective Developer can show his --- By maintaining a package, a prospective Developer can show their 30c30 < and how he works with Debian users and bug submitters. --- and how they work with Debian users and bug submitters. 34c34 < The Applicant can demonstrate his skills in this area by writing --- The Applicant can demonstrate their skills in this area by writing -- Geoffrey Thomas https://ldpreload.com geo...@ldpreload.com
Bug#863166: aufs-dkms: Please enable CONFIG_AUFS_XATTR
On Mon, 22 May 2017, Geoffrey Thomas wrote: Can you enable CONFIG_AUFS_XATTR in config.mk for aufs? This allows aufs to support file capabilities (getcap/setcap) in aufs filesystems. Support has existed in aufs since early 2015 but the flag is off by default. The lack of this option is a problem for Docker users: https://github.com/moby/moby/issues/5650 https://stackoverflow.com/questions/44117543/getcap-setcap-not-working-in-docker-container-with-debian-stretch-host I've tested that setting `CONFIG_AUFS_XATTR = y` in config.mk, and rebuilding the DKMS module, causes running getcap inside Docker to start working. If it's possible to get this enabled for Stretch (either in the release or via stretch-backports), that would be very helpful -- it looks like the config option only enables setxattr etc. to be used on aufs inodes, so the risk of regressions is pretty low. Hi maintainers, Now that the freeze is over, can we get this change in buster and stretch-backports? Let me know if there's something I can do to help, e.g., test packages with this change in. Thanks! -- Geoffrey Thomas https://ldpreload.com geo...@ldpreload.com
Bug#863295: grr: Please remove dependency on prelink
Package: grr-server Version: 3.1.0.2+dfsg-2 Severity: wishlist Hi! I'm the current maintainer of prelink in Debian. The tool is pretty unloved upstream -- Fedora, where I get sources from, has removed it entirely in Fedora 23, and the latest release tarball isn't even in the usual place -- so there's a decent chance that prelink will leave Debian at some point in the next release cycle. It looks like grr only uses prelink to un-prelink things, and that entire code is conditional on whether /usr/sbin/prelink exists. If I'm reading this right, that means there's no need to install prelink on the machines of people who install grr -- no binaries on their machines will be prelinked, so there's no need to un-prelink anything. So prelink doesn't need to be a dependency: grr will do the right thing if it's installed, but will skip over that code if it's not. If that's correct, can you remove prelink from your Depends: line (whenever you next do an upload, no urgency)? That will avoid more people having prelink installed than necessary, and make it easier to remove prelink from Debian in the future. Thanks, -- Geoffrey Thomas https://ldpreload.com geo...@ldpreload.com
Bug#648230: Packaging (and RFS) for pymssql 2.1.1+dfsg-1
Control: severity 709210 grave On Wed, 24 May 2017, James Andrewartha wrote: Hi Geoffrey, Joss, DPMT There's been no substantive uploads of this package in the past 8 years, and we've missed the chance to get a new package into stretch. I'm tempted to request its removal from stretch given it's seriously buggy #709210 and unmaintened. Hi James, Thanks for the reminder! I've fixed up the packaging to work with the current upstream release 2.1.3 and uploaded it, and I've filed an unblock request, bug #863287, to see if the release team is willing to get it into Stretch. I'll also try to get it into backports, either way. Joss, I missed your reply before 2.1.3+dfsg-1 was tagged/uploaded but I added myself to Uploaders, and I can remove you from Maintainers in the next release. (I left the job where we were using SQL Server, but I'm able to test against SQL Server for Linux, because apparently we live in a world where Microsoft hosts an apt server and builds Debian packages with systemd unit files.) Thanks for all your past work on the package! -- Geoffrey Thomas https://ldpreload.com geo...@ldpreload.com
Bug#863287: unblock: pymssql/2.1.3+dfsg-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Hi release team! I'd like to get an unblock for pymssql/2.1.3+dfsg-1. This is a new upstream release: the current version in oldstable, stable, and testing is broken against the version of freetds (the underlying C library for talking to MS-SQL servers) in Debian. See https://bugs.debian.org/648230 and https://bugs.debian.org/709210 . It will be more supportable for Stretch to package the new upstream version: it's a rewrite using Cython, and 1.x is unmaintained now. Because of the above problem, I think nobody is using the current Jessie/Stretch package (or if they are, they're modifying it). Meanwhile, I've used this packaging at my previous employer to build pymssql 2.1.1 in November 2015, and that's been working fine in production, so the 2.x package is well-tested. It's also a leaf package (its only reverse-dependencies are as Suggests of python-sqlalchemy, python-sqlobject, and pyrit, alongside other backends for free software databases like MySQL and Postgres) so there shouldn't be a risk of regressions despite it being late in the release cycle. The full debdiff is at https://ldpreload.com/tmp/pymssql_2.1.3+dfsg-1.debdiff (not attaching it because it's 700 kB and debian-python is Cc'd). It's probably easier to browse the full changes via https://anonscm.debian.org/cgit/python-modules/packages/pymssql.git but here's the changelog entry: pymssql (2.1.3+dfsg-1) unstable; urgency=medium * Team upload. [ Ondřej Nový ] * Fixed VCS URL (https) [ Geoffrey Thomas ] * New upstream release (Closes: #648230), with DFSG repack to avoid embedded freetds binaries. - Be compatible with newer versions of freetds (Closes: #709210). - Consistently respect as_dict (Closes: #590548). - setup.py: Don't require setuptools_git. * Packaging cleanups: - Switch from CDBS to dh sequencer, and bump d/compat to 9. - Build for both Python 2 and 3 using pybuild. - Update Standards-Version to 3.9.8 (no changes). - Update copyright and follow machine-readable copyright spec. - Switch to source format 3.0 (quilt). - Use uscan and Files-Excluded in debian/copyright to simplify the DFSG repack target, and drop debian/rules get-orig-source (just call `uscan --rename`). * Add myself to Uploaders. -- Geoffrey Thomas <geo...@ldpreload.com> Wed, 24 May 2017 14:16:13 -0400 If you don't want to take the new upstream release, I could try applying the random patch on GitHub to the current 1.x package, but I'd probably prefer that we just remove it from Stretch (so that users use the upstream release or something) instead of supporting the 1.x release for the entire Stretch lifecycle. unblock pymssql/2.1.3+dfsg-1 Thanks, -- Geoffrey Thomas https://ldpreload.com geo...@ldpreload.com
Bug#863166: aufs-dkms: Please enable CONFIG_AUFS_XATTR
Package: aufs-dkms Version: 4.9+20161219-1 Hi maintainer, Can you enable CONFIG_AUFS_XATTR in config.mk for aufs? This allows aufs to support file capabilities (getcap/setcap) in aufs filesystems. Support has existed in aufs since early 2015 but the flag is off by default. The lack of this option is a problem for Docker users: https://github.com/moby/moby/issues/5650 https://stackoverflow.com/questions/44117543/getcap-setcap-not-working-in-docker-container-with-debian-stretch-host I've tested that setting `CONFIG_AUFS_XATTR = y` in config.mk, and rebuilding the DKMS module, causes running getcap inside Docker to start working. If it's possible to get this enabled for Stretch (either in the release or via stretch-backports), that would be very helpful -- it looks like the config option only enables setxattr etc. to be used on aufs inodes, so the risk of regressions is pretty low. Thanks, -- Geoffrey Thomas https://ldpreload.com geo...@ldpreload.com
Bug#827468: ipmitool: postinst unintentionally starts ipmievd.service
Package: ipmitool Version: 1.8.14-4 Hi maintainer, When I install the ipmitool package on Jessie (either 1.8.14-4 from stable, or a local backport of 1.8.17-1 to Jessie), the ipmievd.service systemd unit starts up, even though the packaging implies the intention is that it should not start up unless explicitly enabled. I think what's happening is that the package writes out an /etc/default/ipmievd that's supposed to disable the initscript, but on a machine where init is systemd, `invoke-rc.d ipmievd start` runs the systemd unit, which doesn't look at /etc/default/ipmievd. Since the systemd unit is not explicitly enabled, after a reboot, ipmievd isn't running. So this looks like unintentional behavior. I'm not sure what the right fix for this is. `dh_installinit --no-start` definitely solves the problem on systems where systemd is init, but maybe you want to restart ipmievd for systems that have it enabled and are using sysvinit as init. Thanks, -- Geoffrey Thomas https://ldpreload.com geo...@ldpreload.com
Bug#818318: git security updates for wheezy-backports?
Hi git maintainers, I believe the version of git in wheezy-backports is affected by last week's security issues in #818318 (CVE-2016-2315 and CVE-2016-2324), as well as by CVE-2015-7545, since both of those were applied to the versions in wheezy and jessie. Are you uploading patched versions to backports? Would it be helpful for me to prepare and test an upload to backports? (I'd need sponsorship, since I'm not a DD and also don't have a valid PGP key currently.) Thanks, -- Geoffrey Thomas geo...@hudson-trading.com
Bug#818602: r-cran-glmnet: Vcs-* URLs are wrong
Package: r-cran-glmnet Version: 2.0-2-2 Severity: minor Hi maintainer, You list the following Vcs-* URLs: Vcs-Browser: http://anonscm.debian.org/cgit/debian-science/r-cran-glmnet.git Vcs-Git: git://anonscm.debian.org/debian-science/r-cran-glmnet.git which don't work; they're missing a "packages" directory in the path. The correct ones are Vcs-Browser: http://anonscm.debian.org/cgit/debian-science/packages/r-cran-glmnet.git Vcs-Git: git://anonscm.debian.org/debian-science/packages/r-cran-glmnet.git Thanks for packaging this software! -- Geoffrey Thomas https://ldpreload.com geo...@ldpreload.com
Bug#654924: Helping with tigervnc 1.5.0
Hi maintainers, I'm interested in using tigervnc for its 3D acceleration support. I built tigervnc 1.5.0 from git (4a25ccd) on jessie, with a no-change backport of fltk1.3 1.3.3-6, and it seems to work very well out of the box: I can run GNOME 3 with llvmpipe inside the server, and the client also works well. Is there anything I can do to help get this package into Debian? I see the thread at http://lists.alioth.debian.org/pipermail/pkg-tigervnc-devel/Week-of-Mon-20160125/thread.html seems to be making good progress. If I can do more testing or look at copyrights or something, just let me know what's helpful! Thanks for your work in packaging this. -- Geoffrey Thomas geo...@hudson-trading.com
Bug#810942: ITP: premailer - Turns CSS blocks into style attributes
Package: wnpp Severity: wishlist Owner: Geoffrey Thomas <geo...@hudson-trading.com> * Package name: premailer Version : 2.9.7 Upstream Author : Peter Bengtsson <m...@peterbe.com> * URL : http://github.com/peterbe/premailer * License : BSD-3-Clause Programming Lang: Python Description : Turns CSS blocks into style attributes When you send HTML emails you can't use style tags but instead you have to put inline style attributes on every element. premailer parses an HTML page, looks up style blocks and parses the CSS. It then uses the lxml.html parser to modify the DOM tree of the page accordingly. I intend to team-maintain this package in DPMT. -- Geoffrey Thomas geo...@hudson-trading.com
Bug#806761: python-botocore: requests.packages.urllib3.exceptions should be urllib3.exceptions
Package: python-botocore Version: 1.3.9-1 Severity: wishlist Hi maintainer, In the "Don't use duplicated modules" patch, in botocore/retryhandler.py, botocore.vendored.requests.packages.urllib3.exceptions becomes requests.packages.urllib3.exceptions. But actually it should be just urllib3.exceptions, matching all the other imports from botocore.vendored.requests.packages.urllib3 from that patch. When running against python-requests from jessie (I'm trying to build botocore and boto3 for jessie-backports), that import doesn't actually work; see bug #771349 for a similar issue. In Stretch, python-requests (>= 2.7.0-3) has better devendorization logic that fixes that bug. So I've marked this wishlist since I don't actually think it affects Stretch. But it's still inconsistent. I suppose the same change should also be made to the diff to tests/unit/test_awsrequest.py in the "Don't use duplicated modules (in tests)" patch. Thanks, -- Geoffrey Thomas geo...@hudson-trading.com
Bug#533708: Licenses on libhugetlbfs files
Hi Mel, Eric, and Jarod, I'm looking into uploading libhugetlbfs to Debian, and I wanted to double-check a few files with ambiguous copyright or license notices. I assume they're all intended to be LGPLv2.1+ like the rest of the package but they're not labeled as such. * huge_page_setup_helper.py is labeled just "(c) Red Hat, Inc., 2009," but does not have a license statement. Jarod, can this be used under LGPLv2.1+? * Similarly, oprofile_start.sh just says "oprofile_start.sh (c) Mel Gorman 2008" with no license statement. Mel, is this also LGPLv2.1+? * A few files (TLBC/*, contrib/tlbmiss_cost.sh, cpupcstat, oprofile_map_events.pl) are "Licensed under LGPL 2.1 as packaged with libhugetlbfs." Eric, Mel, I assume that these are intended to be LGPLv2.1 or any higher version, like the rest of the package? Less importantly: * alloc.c and two tests have _just_ a license, not a copyright statement; I guess they're owned by IBM? * There are a few other files without copyright notices, but right now I'm assuming they're under the LGPL (though it would be great to have comments on them, or a clear statement in a README). It's the ones that have a copyright statement and no license that I want to be particularly sure of. * For the files that say things like "Copyright (C) 2005-2006 David Gibson & Adam Litke, IBM Corporation.", do you know if the copyright is held by the individuals as well as IBM, or just by IBM? I can just copy these statements verbatim into debian/copyright, but it seems worth clarifying. Sorry about the annoyance, but Debian cares about getting this stuff right (and I think that's a good policy, honestly). I can send in a follow-up patch to add comments to the files that don't have copyright notices once I get responses; I'd also be okay with a notice in the README that clearly asserts a license for the entire package, if you'd prefer that. (By the way, I seem to be unable to subscribe to the librelist, which is maybe where I should ask this - at least I have gotten no confirmation email from my subscribe email, and I'm not sure how to send without first subscribing as described in SubmittingCode.) Also if there's anything you'd like me to be aware of when preparing the Debian package or to package in a certain way, do let me know. Thanks, -- Geoffrey Thomas geo...@hudson-trading.com
Bug#805488: pristine-tar: Does not efficiently compress gzip --rsyncable, dpkg's default
Package: pristine-tar
Version: 1.33
Severity: important
(This bug may be a duplicate of other ones filed against pristine-tar; I
haven't yet investigated their cause.)
pristine-tar seems not to know how to efficiently re-compress files
compressed by gzip --rsyncable on both Jessie and Sid (which have gzip
1.6-4). From a Sid chroot:
$ gunzip pristine-tar_1.33.tar.gz
$ gzip --rsyncable pristine-tar_1.33.tar
$ pristine-tar gendelta pristine-tar_1.33.tar.gz tmp
warning: pristine-gz cannot reproduce build of pristine-tar_1.33.tar.gz;
storing 80% size diff in delta
(Please consider filing a bug report so the delta size can be improved.)
No such error happens if you leave off --rsyncable.
In fact, this happens on the unmodified tarball of pristine-tar itself
(versions 1.31, 1.32, and 1.33, but not older versions):
$ apt-get source --download-only pristine-tar
$ pristine-tar gendelta pristine-tar_1.33.tar.gz tmp
warning: pristine-gz cannot reproduce build of pristine-tar_1.33.tar.gz;
storing 86% size diff in delta
(Please consider filing a bug report so the delta size can be improved.)
I noticed this because uscan's repack mode calls mk-origtargz, which uses
Debhelper::Compression, which uses Dpkg::Compression, which passes
--rsyncable by default. From /usr/lib/perl5/Dpkg/Compression.pm:
gzip => {
file_ext => 'gz',
comp_prog => [ 'gzip', '--no-name', '--rsyncable' ],
decomp_prog => [ 'gunzip' ],
default_level => 9,
},
So I bet this affects a number of packages. For instance, this is how
pristine-tar's own native tarballs were made:
$ gunzip < pristine-tar_1.33.tar.gz | gzip -9 --no-name --rsyncable | diff -s -
pristine-tar_1.33.tar.gz
Files - and pristine-tar_1.33.tar.gz are identical
The changelog entry for pristine-tar 1.14 (August 2011) implies that it's
supposed to support the --rsyncable option already, but perhaps since
then, the gzip format has changed.
--
Geoffrey Thomas
https://ldpreload.com
geo...@ldpreload.com
Bug#648230: Packaging (and RFS) for pymssql 2.1.1+dfsg-1
Hi Joss, I've updated pymssql to 2.1.1+dfsg-1, closing #648230, #709210, and #590548, and pushed the packaging branch to DPMT git, in a new branch "2.1.1". We've had trouble with the freetds incompatibility; the new package solves the issue. There are a few packaging cleanups described in debian/changelog. Notably the new version reworks what sourceless files they include, so I've decided to let uscan handle it and dropped the get-orig-source target per advice on #debian-python. Could you look over it before I push it to master? Also, are you interested in sponsoring this upload? Thanks, -- Geoffrey Thomas geo...@hudson-trading.com
Bug#793491: Packaging for rocksdb?
Control: block 803502 by -1 Hi Laszlo, I'm working on packaging osquery, which has rocksdb as a dependency. I see that it's in the NEW queue; do you mind posting your packaging for it somewhere so I can build-depend on the package as it will be in Debian? (I could also make some local packaging of it, but that seems like wasted effort.) Thanks, -- Geoffrey Thomas geo...@hudson-trading.com
Bug#781948: [buildd-tools-devel] Bug#781948: --extra-package doesn't work
So I got pinged about this by someone who realized that he didn't actually
list all the necessary build-deps in --extra-package. Piotr, I
noticed that your log is saying "but it is not going to be
installed" -- that is, the package exists but cannot itself be installed
-- instead of "but it is a virtual package" -- that is, the package does
not exist and is merely referenced by sbuild-build-depends-dummy.
In particular, it looks like python3-plainbox has an exact-equality
dependency on plainbox-secure-policy (= ${binary:Version}) |
plainbox-insecure-policy (= ${binary:Version}), so you'll need to pass
your rebuild of one of those into --extra-package, too.
Wookey, are you using the functionality to run sbuild from a directory
instead of in a dsc? I don't use that myself, so I'd believe that it
changes directory in a way I wasn't expecting. Your patch (maybe with a
"$!" in there) sounds like a good idea.
Sven, what's the error message you're getting?
--
Geoffrey Thomas
https://ldpreload.com
geo...@ldpreload.com
Bug#803502: ITP: osquery -- operating system instrumentation framework
Package: wnpp Severity: wishlist Owner: Geoffrey Thomas <geo...@ldpreload.com> * Package name: osquery Version : 1.5.3+git20151029 Upstream Author : Facebook * URL : https://osquery.io/ * License : BSD-3-clause Programming Lang: C++ Description : operating system instrumentation framework osquery allows you to write SQL-based queries to explore operating system data. With osquery, SQL tables represent abstract concepts such as running processes, loaded kernel modules, open network connections, browser plugins, hardware events or file hashes. -- Geoffrey Thomas https://ldpreload.com geo...@ldpreload.com
Bug#782532: [buildd-tools-devel] Bug#782532: sbuild: Error creating ubuntu chroot: debfoster not found
On Mon, 13 Apr 2015, Dima Kogan wrote: I: Checking component main on http://us.archive.ubuntu.com/ubuntu... E: Couldn't find these debs: debfoster It's worth noting that one of the Ubuntu patches is to remove the use of debfoster. If there's a clever / robust way to make sbuild detect whether the target distro is Debian or Ubuntu, and conditionalize debfoster on that, that would both fix this bug and remove one of the deltas in Ubuntu. -- Geoffrey Thomas https://ldpreload.com geo...@ldpreload.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782427: strace: Please configure --with-libunwind
Package: strace Version: 4.10-1 Severity: wishlist Hi maintainer, I'd like to request that you build strace with the --with-libunwind compiler flag, and build-dep on libunwind8-dev. This will add the `-k` option to strace, which will print libunwind-based backtraces on every system call, which is pretty nifty. Right now the best way to do this (I think) is to use gdb to stop on every syscall, which doesn't offer the syscall-decode capabilities of strace. I don't think that Debian's strace package is used in any context where the libunwind runtime dependency would be annoying, though I might be wrong about that. -- Geoffrey Thomas https://ldpreload.com geo...@ldpreload.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#780871: libxdo-dev: Please wrap xdo.h in extern C guards
Package: libxdo-dev
Version: 1:3.20130111.1-3.1
Hi maintainer,
xdo.h isn't directly usable in C++ source files because it doesn't wrap
functions in extern C {} when __cplusplus is defined. This means that a
call to, say, xdo_init will resolve to the name-mangled version of the
function, but libxdo.so provides an unmangled name.
It looks like the X headers handle this with the _XFUNCPROTOBEGIN and
_XFUNCPROTOEND headers in X11/Xfuncproto.h, which you could use.
Alternatively, you could just conditionally wrap the header in extern C
yourself.
Thanks,
--
Geoffrey Thomas
gtho...@moka5.com
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778510: dnsutils: Please include edns-client-subnet patch to dig
Package: dnsutils
Version: 1:9.9.5.dfsg-8
Severity: wishlist
Tags: patch
X-Debbugs-CC: lin...@debian.org
Hi maintainers,
There's a patch available to add support for the edns-client-subnet
extension to the `dig` command. The edns-client-subnet extension lets an
intermediate DNS server (like Google Public DNS or OpenDNS) relay the
client's original subnet to the destination DNS server, so that DNS-based
CDNs can geolocate the actual client, not the IP address of the
intermediate DNS server. There's more discussion and a link to the patch
and the Internet-Draft on this site:
http://www.afasterinternet.com/howitworks.htm
For testing purposes it's handy to be able to issue these queries from the
command line, so you can see what DNS results would look like if you had a
different IP address.
The patches linked above are minimal and easy to review (it doesn't look
unreasonable at a casual glance, but I'm completely unfamiliar with BIND
source), and apply cleanly to the version in unstable, except for one
#define that was equivalently added upstream. I've built it locally and
confirmed that it works, and I've attached my debdiff if that helps.
Can you consider including this? Or if you want upstream to weigh in, do
you mind forwarding this request upstream? It looks like BIND has no
public bugtracker, so I don't quite understand the process of requesting
this from upstream.
Cc'ing the patch author -- I'm curious if there was any particular reason
you didn't submit it to Debian (or if I missed the bug where you did), or
you just didn't think there was interest or something.
Thanks,
--
Geoffrey Thomas
https://ldpreload.com
geo...@ldpreload.comdiff -u bind9-9.9.5.dfsg/debian/changelog bind9-9.9.5.dfsg/debian/changelog
--- bind9-9.9.5.dfsg/debian/changelog
+++ bind9-9.9.5.dfsg/debian/changelog
@@ -1,3 +1,10 @@
+bind9 (1:9.9.5.dfsg-8+geofft1) unstable; urgency=medium
+
+ * Apply the EDNS client subnet patch from
+http://wilmer.gaa.st/edns-client-subnet/
+
+ -- Geoffrey Thomas geo...@ldpreload.com Sat, 14 Feb 2015 17:27:30 -0500
+
bind9 (1:9.9.5.dfsg-8) unstable; urgency=medium
* Launch rndc command in the background in networking scripts to avoid a
only in patch2:
unchanged:
--- bind9-9.9.5.dfsg.orig/bin/dig/dig.c
+++ bind9-9.9.5.dfsg/bin/dig/dig.c
@@ -187,6 +187,7 @@
+domain=### (Set default domainname)\n
+bufsize=###(Set EDNS0 Max UDP packet size)\n
+ndots=### (Set NDOTS value)\n
+ +client=addr(Set edns-client-subnet option)\n
+[no]edns[=###] (Set EDNS version) [0]\n
+[no]search (Set whether to use searchlist)\n
+[no]showsearch (Search with intermediate results)\n
@@ -837,8 +838,25 @@
}
break;
case 'l': /* cl */
- FULLCHECK(cl);
- noclass = ISC_TF(!state);
+ switch (cmd[2]) {
+ case 'i':/* client */
+ FULLCHECK(client);
+ if (value == NULL)
+ goto need_value;
+ if (state lookup-edns == -1)
+ lookup-edns = 0;
+ if (parse_netprefix(lookup-ecs_addr,
+ lookup-ecs_len,
+ value) != ISC_R_SUCCESS)
+ fatal(Couldn't parse client);
+ break;
+ case '\0':
+ FULLCHECK(cl);
+ noclass = ISC_TF(!state);
+ break;
+ default:
+ goto invalid_option;
+ }
break;
case 'm': /* cmd */
FULLCHECK(cmd);
only in patch2:
unchanged:
--- bind9-9.9.5.dfsg.orig/bin/dig/dighost.c
+++ bind9-9.9.5.dfsg/bin/dig/dighost.c
@@ -100,6 +100,9 @@
#include dig/dig.h
+/* parse_netprefix */
+#include netdb.h
+
#if ! defined(NS_INADDRSZ)
#define NS_INADDRSZ 4
#endif
@@ -801,6 +804,8 @@
looknew-new_search = ISC_FALSE;
looknew-done_as_is = ISC_FALSE;
looknew-need_search = ISC_FALSE;
+ looknew-ecs_addr = NULL;
+ looknew-ecs_len = 0;
ISC_LINK_INIT(looknew, link);
ISC_LIST_INIT(looknew-q);
ISC_LIST_INIT(looknew-connecting);
@@ -818,6 +823,7 @@
dig_lookup_t *
clone_lookup(dig_lookup_t *lookold, isc_boolean_t servers) {
dig_lookup_t *looknew;
+ size_t len;
debug(clone_lookup());
@@ -878,6 +884,19 @@
looknew-need_search = lookold-need_search;
looknew-done_as_is = lookold-done_as_is
Bug#705926: [buildd-tools-devel] Bug#705926: sbuild: Add basic DEP-8 autopkgtest
On Mon, 22 Apr 2013, James Hunt wrote: Dear Maintainer, The attached debdiff adds a basic DEP-8 autopkgtest for sbuild. See: - https://code.launchpad.net/~jamesodhunt/ubuntu/raring/sbuild/dep8-procenv - https://code.launchpad.net/~jamesodhunt/ubuntu/raring/sbuild/dep8-procenv/+merge/159596 In Ubuntu, the attached patch was generated to achieve the following: * ability to detect if sbuilder is able to: - create a chroot for the current release. - build a package. * check that the resulting package is installable and the binary runnable. Thanks for considering the patch. Hi, Two quick questions about this. First, it appears that the patch uses `apt-get source` into the current directory, and doesn't change directory. It looks like the draft spec (README.package-tests.rst) says that you can't assume that the cwd is writable, and you should instead use $ADTTMP. Should there be a `cd $ADTTMP` at the top of the script? Second, should we be merging the latest autopkgtest from sbuild 0.64.1-1ubuntu6, including static sbuild signing keys? (I have some ideas for how to avoid the key requirement on recent distros by using [trusted=yes], but won't get around to trying it immediately.) -- Geoffrey Thomas https://ldpreload.com geo...@ldpreload.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760200: config-package-dev: [PATCH] package.displace-extension can now contain .extension or extension
On Mon, 1 Sep 2014, Dima Kogan wrote: Here's a small patch to allow package.displace-extension files to contain the extension without the .. This was a requirement that was not stated anywhere, and not following it produced mysterious, silent errors Thanks, looks good to me. I don't think any of the config-package-dev maintainers actually use displace-extension files, since the default behavior (first word of the package name) is fine for our projects, so feedback on this interface in general is welcome. I'll apply this before the next upload, and I (or someone else) will do at least one upload before the freeze. -- Geoffrey Thomas https://ldpreload.com geo...@ldpreload.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745590: msmtp: linking against OpenSSL?
On Fri, 25 Apr 2014, Emmanuel Bouthenot wrote: It seems that your bug could be fixed by linking msmtp against libgnutls28: Interesting. I did glance at the code for GnuTLS 3.x before reporting this and thought I saw the chain-verification code was substantially similar to 2.x's, but yes, I can confirm that if I apt-get install libgnutls28-dev and ./configure, the resulting build does work for me. So that works too. If you're confident in GnuTLS 3.x going forward, then that solution is fine with me. (I still think it's odd that upstream clearly intends to link against OpenSSL and has no exception, but whatever.) Hm, do you know why libgnutls-dev still points at libgnutls26? #731175 has no details other than a vague comment about licensing. Thanks, -- Geoffrey Thomas https://ldpreload.com geo...@ldpreload.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745590: msmtp: linking against OpenSSL?
Package: msmtp Version: 1.4.31-1 Severity: wishlist Dear maintainer, I find myself in the situation where OpenSSL is currently compatible with my email provider (pobox.com) and GnuTLS isn't (because of out-of-order intermediate certs, which it turns out OpenSSL is tolerant to and GnuTLS isn't). I would be interested in an msmtp linked against OpenSSL. It looks like msmtp is licensed under GPL with no OpenSSL exception, but since upstream is largely one author who clearly intended their code to work with OpenSSL, it seems like it's worth asking for the licensing exception. Has this conversation already happened? If not, I'm happy to post to the mailing list asking for the exception, if you're open to changing the Debian packaging to link against OpenSSL instead. It looks like there is another outstanding bug against msmtp (#745174) that also seems like OpenSSL would resolve it. Unfortunately, GnuTLS seems to be kind of a rare client for commercial email providers to support or test against, but OpenSSL is pretty popular on all platforms. I will separately report a bug against GnuTLS to address my specific issue, but converging on OpenSSL seems like it would also address both my current problem and several others. Thanks for your attention, and also thanks for maintaining the msmtp package -- I use it daily for both personal and work email, and it works so well that I generally don't have to think about it. :) -- Geoffrey Thomas https://ldpreload.com geo...@ldpreload.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744027: data point
On Thu, 10 Apr 2014, Kurt Roeckx wrote: What we really need is OCSP stapling. That would mean that the server asks the CA for the OCSP response and adds that response in the TLS session, and the client doesn't have to contact the CA anymore to ask for the status. Only the server would need to contact the CA. The server should have enough time to be able to refresh the OCSP response, which is valid for maximum 10 days. Yes, agreed. Unfortunately not many sites enable it. I think it'd be productive to have Debian-packaged SSL _servers_ all support and document and maybe default to OCSP stapling, so that in a few years, maybe we can have the start of a working revocation protocol. Sadly, there isn't one right now, so I don't there's anything we can do today. This documentation seems to imply that upstream Apache HTTPD does not usefully support stapling when intermediate certs are in play, which is basically always: https://httpd.apache.org/docs/trunk/mod/mod_ssl.html#sslusestapling I'm hereing some vague cases why OCSP mandatory checking can't be enabled by default because some users can't contact the OCSP server. I've never had this problem myself and I think I've seen way to many weird setups already to not consider this a real problem. Well, you'll have the problem as soon as you're being MITM'd. A cert verification solution that works fine when nobody's MITMing you is not particularly useful. :-) -- Geoffrey Thomas https://ldpreload.com geo...@ldpreload.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744027: Please remove StartCom Certification Authority root certificate
On Wed, 9 Apr 2014, Klemens Baum wrote: StartCom provides cheap and even free SSL certificates via the StartSSL brand. However, certificates revoking cerificates requires a US$ 24.90 fee [3]. This discourages responsible sysadmin procedure and and will ensure many compromised certificates remain in use. I don't believe that any browser or HTTPS client in Debian checks revocations with hard failures if the CRL or OCSP responder is unreachable, so I don't see how this is relevant for decisions regarding Debian's default trust store. The certificate will (it seems) get reissued for free with a new key, so the compromised certificate will not be in use. And an attacker in a position to MITM is also in a position to make the revocation useless: https://news.ycombinator.com/item?id=7556909 https://www.imperialviolet.org/2012/02/05/crlsets.html https://twitter.com/agl__/status/453602748601495553 Multiple commentors on the HN thread you link to imply that StartCom is happy to reissue certs for free, but they charge for revocations, for instance: The title is misleading. StartCom is asking for its fee for revoking, that's all. Not making revocation free of cost isn't refusal to reissue cert. If they were charging for reissues, there might be an argument here, but even if they didn't do revocations at all, I don't see how that affects security under the threat model used by the Debian packages that use on ca-certificates. As a consequence you can't trust certificates signed by StartCom before 2014-04-07. This only affects certs that were used on vulnerable versions of OpenSSL with allocation schemes that actually loaded the private key into freed memory that could be returned. I haven't seen a valid claim that this is anywhere near a significant fraction of the web. http://blog.erratasec.com/2014/04/why-heartbleed-doesnt-leak-private-key.html https://twitter.com/neelmehta/status/453625474879471616 -- Geoffrey Thomas https://ldpreload.com geo...@ldpreload.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744027: data point
On Wed, 9 Apr 2014, Kurt Roeckx wrote: However, iceweasel/firefox by default is happy to ignore a OCSP timeout. You need to turn it on that it doesn't allow a timeout. I have no idea why they use that as default. Because it's an easy DoS if an attacker is in a position to MITM the connection between you and the OCSP service (or CRL file), no? And if the attacker can MITM the connection between you and the SSL service you're trying to talk to, they can probably also MITM the OCSP or CRL server. Also (as Adam Langley points out in the stuff I linked to earlier in this bug report) the OCSP servers risk becoming a single point of failure if you do that. If a CA's OCSP server is down, everything they sign becomes inaccessible. That would be a bad default, and probably not something you want to turn on for yourself either. Also also, http://www.thoughtcrime.org/papers/ocsp-attack.pdf which appears to be still valid with Firefox at least: https://bugzilla.mozilla.org/505812 So there's really no value at all in using OCSP, it seems. -- Geoffrey Thomas https://ldpreload.com geo...@ldpreload.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744100: python-pelican: missing dependency on pkg_resources
Package: python-pelican Version: 3.2.1-1 Hi maintainers, I installed python-pelican on a VPS running Ubuntu 13.10 and got: geofft@cactuar:~/src/website/pelican-test$ pelican Traceback (most recent call last): File /usr/bin/pelican, line 5, in module from pkg_resources import load_entry_point ImportError: No module named pkg_resources I assume the package needs a dependency on python-pkg-resources, or I guess something in debian/pydist-overrides? (Admittedly I haven't actually tested on Jessie, but there doesn't seem to be a dependency there or any relevant changes.) Thanks, -- Geoffrey Thomas https://ldpreload.com geo...@ldpreload.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#428554: Can't reproduce this problem
On Sun, 2 Mar 2014, Carsten Schoenert wrote: what about closing this bug? The reported Icedove version out of the official repos for quite some times and notheing else happen to this report quite over 6 years. Hi Carsten, There are a number of bugs against prelink that are outdated or irrelevant or fixed by the much-newer version I uploaded last week. I'm planning on systematically going through all of them and verifying whether there is any validity in them, although this may not be for a few weekends. I will probably end up closing this bug when that happens. -- Geoffrey Thomas gtho...@mokafive.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657967: ITA: prelink
retitle 657967 ITA: prelink -- ELF prelinking utility to speed up dynamic linking owner 657967 ! thanks I intend to adopt prelink and get it updated the newest upstream version. I've been in touch with asheesh about sponsoring it, and I'm going to plan to do an upload this weekend. -- Geoffrey Thomas gtho...@mokafive.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735935: grub2: LVM trouble at boot after upgrade to 2.02 beta
Package: grub-pc Version: 2.02~beta2-3 Hi Colin, I have the strangest issue which I am not even entirely confident is a GRUB issue, but it started right after upgrading my system to GRUB 2.02 from experimental, and without other changes, and it's even reproducible when running my system inside kvm off a thumbdrive, so I'm going to provisionally blame it on the GRUB 2.02 beta build. I'm running a pretty standard LVM setup -- there's other stuff on this hard disk (like the preinstalled Windows), but one of the MS-DOS partitions is an LVM PV, containing a VG named leveret, containing two LVs named root and swap. /boot itself is located on the root LV. Every time I start up, since the upgrade, the initramfs fails to find my root hard disk via its /dev/disk/by-uuid path, and dumps me to a shell. If I look inside /dev/mapper, I see a node for leveret-swap but not leveret-root. `lvm lvs` happily lists both nodes, though, and I can get my system to boot if I do `lvm vgchange -an`, `lvm vgchange -ay` (at which point both nodes appear, as well as the by-uuid symlink), and `exit`. (Resume-from-hibernate even worked after doing this, right after the upgrade.) There's nothing particularly suspicious-sounding in dmesg at any point. The machine is a Toshiba L635 laptop, a few years old, BIOS boot only, running a somewhat out-of-date Debian testing, amd64. I'm running linux-image-3.9-1-amd64 3.9.8-1 (from testing this past summer or so) and lvm2 2.02.95-7. I'm happy to try to upgrade these, but since I haven't upgraded anything else on the system for a few weeks, I figured I'd report this and leave the system alone in case you had more questions about the current setup. Let me know if you need any more information from me or want me to try anything. I'm at a bit of a loss how GRUB could have caused this, but I don't have any other ideas what's going on. Thanks, -- Geoffrey Thomas https://ldpreload.com geo...@ldpreload.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735021: Dpkg::Path: Please expose dpkg-query --control-show and --control-list
Package: libdpkg-query Version: 1.17.5 Severity: wishlist Hi, dpkg-query's manpage says that --control-path is deprecated in favor of --control-show and --control-list, but Dpkg::Path only offers a wrapper around --control-path. Can you expose --control-show and --control-list via some API in Dpkg::Path? Thanks, -- Geoffrey Thomas https://ldpreload.com geo...@ldpreload.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#367320: Patch available
On Sat, 2 Sep 2006, Ted Percival wrote: I have written a patch that adds timestamps to the output of prelink through a -T command-line option. The patch is attached as prelink-timestamp.patch and has been sent upstream. Hi Ted, I notice this patch isn't present in current prelink SVN. Did you get a response from upstream about including it, or shall I resubmit it to them? -- Geoffrey Thomas https://ldpreload.com geo...@ldpreload.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#618273: gambc has been orphaned
tags 618273 - pending thanks The 2011 comment about a pending upload was from the previous maintainer, but this package was orphaned in 2012 ( http://bugs.debian.org/677709 ) due to lack of activity from that maintainer. So I'm untagging it as pending upload, for now, so that this bug's status is clearer. Jackson Doak is working on taking over maintenance and has a slightly-newer version on mentors: http://mentors.debian.net/package/gambc It looks like it hasn't gotten any (nontrivial) reviews. I have a bunch of other pending Debian work that I'd like to get to over Christmas break, but if I get all of that done, I'm happy to take a look -- for whatever my review is worth, since I'm not a DD either. I talked to Jackson on IRC yesterday and he said that he's having trouble getting the current upstream release to build. I recall having trouble with this too last time I saw him mention it on IRC. -- Geoffrey Thomas http://ldpreload.com geo...@ldpreload.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#718434: ca-certificates: should CAcert.org be included?
clone 718434 -1 reassign -1 libnss3 retitle -1 nss: Please remove CAcert.org roots thanks On Thu, 5 Dec 2013, Raphael Geissert wrote: On 16 November 2013 17:09, Thijs Kinkhorst th...@debian.org wrote: [...] This seems like an unlikely scenario, as CAcert is not enabled by default in Debian's most used browsers, Iceweasel (Firefox) and Chromium. I believe it is: http://patch-tracker.debian.org/patch/series/view/nss/2:3.14.3-1/95_add_spi+cacert_ca_certs.patch That said, I think it is time to start discontinuing the certificate. Aha, thanks for finding that, I was wondering if I was crazy or had misconfigured my system, which is why I didn't say anything. :-) nss maintainers: Please see the history of this bug for discussion about whether to continue to include CAcert's root in the ca-certificates package. A number of folks (including myself) believe that CAcert's security risk is too high and its benefit too low, these days. If ca-certificates removes the CAcert root, nss should presumably do likewise. I myself also think it makes sense to remove the CAcert root from nss now. For the sake of clarity, since nss adds both SPI and CAcert in the same patch, the present discussion is only about CAcert and there is no proposal to drop SPI. (See also #309564, the bug that originally added the CAcert and SPI roots to the nss package.) -- Geoffrey Thomas http://ldpreload.com geo...@ldpreload.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#718434: Bug #718434, please leave CAcert as is
On Thu, 5 Dec 2013, Alessandro Vesely wrote: I find CAcert pretty useful, and it is handy to have their certificate installed by default. From other contributions to this bug, it seems their auditing, policies, or disclaimer have some issues. Their code quality also has some issues, as described in this bug report, which directly impacts their trustworthiness to sign only valid requests. Can you quantify what you mean by useful and handy? If your specific use case involves free SSL certificates, there are multiple other providers of such things in the Mozilla-distributed root set, that are linked to by the above ticket. Server admins who currently use CAcert will find it more useful to switch to such a root, regardless of whether Debian drops CAcert, because then their site's security can be verified on other platforms. If there are use cases for CAcert other than the fact that their certificates are free-of-charge, I'd be curious to know that, but I'm under the impression that that's basically the only driver these days, and my arguments in this thread are mostly based on that. From a practical POV, the incidents reported by THC[0] mention different CAs, so I'd rather remove them than CAcert. I believe all those roots were either removed from the Mozilla set, or rekeyed. For what it's worth, I'd be happy to see Debian be _more_ conservative than Mozilla in what roots it includes, just not less. Note that CAcert has not rekeyed after the security issue that Ansgar found, and it's really the response to that issue (and lack of publicity) more than the issue itself that makes me uncomfortable with them as a default trusted root. Incidentally, that issue probably would have gotten widespread attention if CAcert was in the Mozilla list... Debian doesn't have the ability to generate the same sort of public outcry for roots that it's locally including. If anything, it should made clear[er] that there is no endorsement or assumption of responsibility in distributing ca-certificates: Just like any other package, it is done on a best-effort basis. I actually do think that's the right policy for Debian, but in the form that Debian should pass the trust questions off to an entity like Mozilla who is willing to make those endorsements (since the only other real way to make no endorsement clear is to make no roots trusted by default). That's exactly what FreeBSD did: http://www.freshports.org/security/ca-roots/ The port is deprecated since it is not supported by the FreeBSD Security Officer anymore. The reason for this is that the ca-roots port makes promises with regard to CA verification which the current Security Officer (and deputy) do not want to make. For people who need a general root certificate list see the security/ca_root_ns, but note that the difference in guarantees with regard to which CAs are included in ca_root_ns vs. ca-roots. The ca_root_ns port basically makes no guarantees other than that the certificates comes from the Mozilla project. -- Geoffrey Thomas http://ldpreload.com geo...@ldpreload.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#718434: ca-certificates: should CAcert.org be included?
I'm curious what the status of this bug is -- is there a plan to remove CAcert in the next upload? As far as I can tell, the only CA certificate sources making an active decision to ship CAcert are Debian, Mageia, and OpenBSD. All other OSes/distributions that do ship CAcert by default and trust it by default[3] do so either because they're downstream from Debian (in the case of e.g. Ubuntu) or because they are using Debian's package (in the case of e.g. Gentoo[4] and Arch[5]). Gentoo seems to have no policy or rules about what's included. OpenBSD seems to have no policy, possibly other than reasonably sane and We should probably think carefully (see r1.1 in [2]). A friend of mine once complained to me that this means that webmasters who use Debian (or a Debian derivative) as their personal OS will often fall into the trap of setting up a website using CAcert, test it on their own machine, and then be surprised when users not on Debian get untrusted certificate errors. This is a pretty strong negative effect on usable security, and seems like a disservice to Debian users and other users of this bundle. Since it seems unlikely, eight years later, that CA curators who don't currently include CAcert are likely to start until they pass their audit, and Debian's CA bundle is by far the most widely-used of the bundles that include CAcert, the positive value of Debian continuing to ship CAcert's root on the grounds of solidarity with their mission seems nil. For what it's worth, I also agree with the security concerns about CAcert -- I'm a little surprised that, given the code quality of the file that Ansgar found a vulnerability in, the root wasn't immediately distrusted. The specific reason I looked at this bug was that I found myself replying to a Reddit comment advocating for CAcert's inclusion in places other than Debian, and having to explain that Debian is not endorsing CAcert's security: http://www.reddit.com/r/technology/comments/1qj1tz/http_20_to_be_https_only/cddfmz0?context=1 Debian's continued inclusion of CAcert in the default certificate store is inevitably interpreted as an endorsement of their security practices, despite the disclaimer in the package description (see also the discussion in #647848). Incidentally, GlobalSign is now offering gratis wildcard certificates for open source projects[6], which they define as actively maintained projects under an OSI-approved license. Between that and StartCom's gratis offering[7], in my opinion 95% of the practical use cases for keeping CACert in Debian are probably covered. [1] http://svnweb.mageia.org/packages/cauldron/rootcerts/current/SPECS/rootcerts.spec?view=markup [2] http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/cert.pem [3] http://wiki.cacert.org/InclusionStatus [4] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-misc/ca-certificates/ca-certificates-20130906.ebuild?view=markup [5] https://www.archlinux.org/packages/core/any/ca-certificates/ [6] https://www.globalsign.com/ssl/ssl-open-source/ [7] http://www.startssl.com/?app=1 -- Geoffrey Thomas http://ldpreload.com geo...@ldpreload.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725040: Intention to use NMU to fix the bug
On Tue, 15 Oct 2013, Sergei Golovan wrote: Hi! I've bumped the severity of this bug to serious to ensure Tcl/Tk 8.4 will not go to jessie when it'll become stable. I'm planning to use NMU to fix this bug if there's no objection for that. Hi Sergei, The patch you posted looks good. Please go ahead and NMU -- I don't expect to have time to look at this package in detail for a couple of weeks. Is the USE_INTERP_RESULT something that ought to be fixed in the project's codebase? If so, it would be totally awesome if you filed a bug either here or on the SourceForge project with a link or something to the issue. -- Geoffrey Thomas http://ldpreload.com geo...@ldpreload.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722103: sbuild: Pass --no-options to gpg when creating temporary archive key
Package: sbuild
Version: 0.64.0-1
Tags: patch
Hi maintainer,
Jeffrey Hutzelman mentioned to me that `sbuild-update --keygen` was
creating ASCII-armored archive keys instead of a binary keyring, which
caused the process of signing the archive to fail. After some confusion on
my part because it totally works for me, we found that he had the armor
option set in his ~/.gnupg/gpg.conf, and that sbuild was respecting this
configuration file.
In order to get consistent scripted behavior out of the gpg command, you
need to pass --no-options. See also apt-key.
Very simple patch attached; you can also pull the single commit from the
gpg-no-options branch of https://github.com/geofft/sbuild if that's easier
. Jeff has confirmed that it fixes his problem.
--
Geoffrey Thomas
http://ldpreload.com
geo...@ldpreload.comFrom ad6d39482db4655a619eb26bc8c078deee0d3d87 Mon Sep 17 00:00:00 2001
From: Geoffrey Thomas geo...@ldpreload.com
Date: Wed, 21 Aug 2013 22:11:49 -0700
Subject: [PATCH] Sbuild::ChrootSetup: Pass --no-options to gpg
---
lib/Sbuild/ChrootSetup.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/Sbuild/ChrootSetup.pm b/lib/Sbuild/ChrootSetup.pm
index ab16e3c..649c5f3 100644
--- a/lib/Sbuild/ChrootSetup.pm
+++ b/lib/Sbuild/ChrootSetup.pm
@@ -261,7 +261,7 @@ EOF
return $?
}
-my @command = ('gpg', '--no-default-keyring', '--batch', '--gen-key',
+my @command = ('gpg', '--no-options', '--no-default-keyring', '--batch', '--gen-key',
$tmpfilename);
$host-run_command(
{ COMMAND = \@command,
--
1.8.4
Bug#700522: [PULL] sbuild --extra-package (#700522) and --extra-repository (#714883)
OK, I think the extra-package branch of https://github.com/geofft/sbuild is ready to be pulled. This adds functionality to make both locally-built .debs and additional apt repositories available to the build-dependency resolution process, without having to do any additional setup or customization of the chroot. The functionality should be compatible with any apt version inside the chroot that sbuild currently works with. Thanks to Emanuele Aina and David Kalnischkies for extensive review on GitHub (mostly on the older add-package branch). --- The following changes since commit d7f31eddcec5db5f5d0419daf520f9f19b857b5e: debian: Remove buildd preinst and correct init script dependencies (2013-05-17 23:31:10 +0100) are available in the git repository at: https://github.com/geofft/sbuild extra-package for you to fetch changes up to b22397d5e73f05a2ea08b993f4952d4dbda90b49: changelog for branch (2013-08-16 16:13:40 -0700) Geoffrey Thomas (4): Sbuild::ResolverBase: Implement update_archive using apt-get update Implement --extra-package=package.deb Implement --extra-repository=deb scheme://... changelog for branch debian/changelog |9 + lib/Sbuild/Conf.pm | 12 lib/Sbuild/Options.pm |8 +++- lib/Sbuild/ResolverBase.pm | 73 + man/sbuild.1.in| 24 5 files changed, 89 insertions(+), 37 deletions(-) -- Geoffrey Thomas gtho...@mokafive.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719655: ITP: svnstsw -- SVNServe Tunnel-mode Setuid/setgid Wrapper
Package: wnpp Severity: wishlist Owner: Geoffrey Thomas gtho...@mokafive.com * Package name: svnstsw Version : 1.4 Upstream Author : Richard Hansen svns...@ir.bbn.com * URL : http://www.ir.bbn.com/~rhansen/svnstsw/ * License : 3-clause BSD Programming Lang: C Description : SVNServe Tunnel-mode Setuid/setgid Wrapper svnstsw is a wrapper around svnserve that sets the tunnel user equal to the username of the user that started the wrapper. It is intended be made setuid or setgid by the local administrator, to allow local users on a shared system to invoke svnserve without having direct access to the repository itself. --- svnstsw's upstream source is in contrib/ in the Subversion repository, but contrib/ is not distributed as part of the Subversion release tarball. I'm copying the subversion packagers in case they have thoughts, want to co-maintain, etc. -- Geoffrey Thomas gtho...@mokafive.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717381: O: open-vm-tools -- Open VMware Tools for virtual machines hosted on VMware
Hi Nate, I noticed that you've been doing most of the Ubuntu uploads of open-vm-tools recently, and are packaging a newer upstream than Debian anyway. So I wanted to make sure you were aware that the Debian package has been orphaned and is in need of a new maintainer. Sadly I'm not a Debian developer and wouldn't have time to offer sponsorship anyway, but as an occasional user of open-vm-tools, I'd like to see the Debian package continue to get maintained. (Sorry for the noise if you're already aware of this -- just didn't see anything on the bug report.) -- Geoffrey Thomas http://ldpreload.com geo...@ldpreload.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#589737: Unknown symbol error in grub2 : 'grub_xputs'
Hi maintainer and others, I ran into this when installing Debian off the netboot kernel/initrd last night. I haven't attempted to reproduce the issue, but I think I ended up with GRUB being configured on my install media instead of my root disk, or something. Specifically, I plugged a USB stick into an existing Wheezy system, formatted it and mounted /dev/sdc1 on /mnt/sdc, ran grub-install --boot-directory=/mnt/sdc/boot /dev/sdc, and downloaded the netboot kernel and initrd from Wheezy current to it. (This all worked fine.) I started up the installer by booting the USB stick on my new system, and manually booting that kernel and initrd at the GRUB prompt. I noticed during the installer that my USB stick was detected fairly early in d-i, but I needed to run the Detect disks phase to get my root disk (I also backed up the old disk contents via openssh-client-udeb, before letting d-i format or install anything, which is why I noticed). My USB stick was /dev/sda, and the root d/targetisk was /dev/sdb. After installing and rebooting, I got the error mentioned in this bug when booting off my hard disk, whether or not my USB install stick was plugged in. If I plugged in my USB stick and booted from that, I got the menu I expected, offering to boot up the newly-installed system, and that booted fine. This is why I vaguely suspect some parts of GRUB got installed to my USB stick instead of to the hard disk. `dpkg-reconfigure grub-pc` got GRUB installed right on my new system, so now it reboots fine. If it's relevant, the old system (where I formatted the USB stick) was Wheezy amd64, and the new system was Wheezy i386. I might try reproducing this in a VM, but hopefully this is enough data to be somewhat helpful. -- Geoffrey Thomas http://ldpreload.com geo...@ldpreload.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#710073: [buildd-tools-devel] Bug#710073: Bug#710073: sbuild: add copy-on-write support
On Fri, 5 Jul 2013, Roger Leigh wrote: I would suspect that we can make it use overlayfs using the same infrastructure--it'll just need teaching about the new filesystem type. Hasn't overlayfs support been in schroot since 1.5.2-1 (May 2012)? I don't think any more support is needed on the sbuild side. Ubuntu seems to be making active use of overlayfs chroots -- mk-sbuild from ubuntu-dev-tools 0.136 (November 2011) onwards makes them, and they carry no patches to schroot and no relevant patches to sbuild. All you need a kernel with overlayfs support. Ubuntu's been carrying the patchset out of tree for a while. (I was pretty sure I'd _used_ overlayfs chroots, so I was surprised by the implication that it doesn't work yet...) By the way, regarding cowdancer and LD_PRELOAD, I semi-recently learned about fakeroot-ng, which implements fakeroot using ptrace instead of LD_PRELOAD and is therefore more reliable. I wonder if the same approach could be applied to cowdancer. (I've long wanted a fakeschroot that doesn't require elevated privilege in order to build things) -- Geoffrey Thomas http://ldpreload.com geo...@ldpreload.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714883: sbuild: Support --add-repository to add an apt source for just one build
On Wed, 3 Jul 2013, Geoffrey Thomas wrote: Also want to take a crack at --add-repository? :-) [...] It would a really nice thing to do but I'm not sure I will have the time to look into that. :( Is there an already open bug report for apt-get mentioning our use case or would you care to open it? They seems two different issues and it would be unfortunate to lose track of it once this bug gets closed. I just reported #714877 to apt, with the partial work I did. I'm also cloning my original bug to a separate report for --add-repository, since that's a separate request from --add-(extra)-package. I got a response pretty quickly from one of the apt maintainers pointing out that this can be done with apt-get as presently implemented, which is exciting, especially because this will work on existing chroots without requiring an apt upgrade. So I've implemented that suggestion on my Github branch (rebased on top of current master), and my existing patch for --add-repository now works properly. https://github.com/geofft/sbuild/tree/add-package The trick is that you can use apt-get update with -o Dir::Etc::sourcelist to point to the file, -o Dir::Etc::sourceparts pointing at an empty directory, and -o APT::List-Cleanup=0. Since this allows cleaning up the existing code in update_archive(), my first commit does this: https://github.com/geofft/sbuild/commit/557d3946e9fcbd709e003c05fcb211315dab1fab I think it'd be good to merge that patch now, since that's pure cleanup of existing code. -- Geoffrey Thomas gtho...@mokafive.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714980: apt: Please run dh_clean in debian/rules clean
Package: src:apt Version: 0.9.9 Severity: wishlist Hi folks, debian/rules clean doesn't run dh_clean, which means that if you do a build and clean in a directory and then do a source build, your source package ends up with the debian/$package/ tmpdirs (the results of the last build) inside it, as well as some debhelper temp files. This makes my debdiffs look silly. Running dh_clean manually fixes this, as you'd expect. It also clears out autom4te.cache, which seems to have ended up in some tarballs (like those in Ubuntu's quantal-updates, at least, which is what I'm running -- the _presence_ of autom4te.cache in Ubuntu's source tarballs makes my debdiffs look differently silly if I run dh_clean before building my source tarball). Can you call dh_clean from debian/rules clean? Thanks, -- Geoffrey Thomas gtho...@mokafive.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714877: apt: Please support an apt-get update for a single repository only
Package: apt
Version: 0.9.9
Severity: wishlist
Hi maintainers,
It would be useful to have the ability to apt-get update a single
repository, without touching the state of other repositories or
downloading their package lists. Updating a single sources.list.d file
would also suffice, and might be easier in terms of syntax.
The primary use case for this would be sbuild: currently, the apt resolver
needs to create a new repository inside the chroot and make apt aware of
it, but if sbuild is run without --apt-update, running `apt-get update`
(which updates every repository) would be inappropriate. So it resorts to
doing some black magic to write out the appropriate /var/lib/apt/lists/
file without actually invoking apt:
http://sources.debian.net/src/sbuild/0.64.0-1/lib/Sbuild/ResolverBase.pm#L179
Being able to run `apt-get update sbuild-build-depends-archive.list` or
something would be much cleaner.
The reason I care about this is that I'm hoping to extend sbuild to allow
adding a new repository at the sbuild command line to provide build
dependencies for the current build only (see bug #700522). I'd rather not
add code to do _more_ of the black magic, and would prefer that apt had a
documented interface to take a new sources.list.d file into account
without updating everything else.
There's also a use case for normal end users with lots of repositories,
where a full `apt-get update` takes a while, and they're only looking for
a package in a specific repository.
I tried writing a patch for this, but the most obvious approach ended up
with apt thinking that one sources.list.d file was the _only_ one
configured (and forgetting all other repositories). Patch is attached
because why not; I haven't had time to look into making it work properly,
yet, but might end up doing so eventually.
--
Geoffrey Thomas
gtho...@mokafive.comdiff -Nru apt-0.9.7.5ubuntu5.2/apt-pkg/cachefile.cc apt-0.9.7.5ubuntu5.2+gthomas1/apt-pkg/cachefile.cc
--- apt-0.9.7.5ubuntu5.2/apt-pkg/cachefile.cc 2012-11-01 02:48:40.0 -0700
+++ apt-0.9.7.5ubuntu5.2+gthomas1/apt-pkg/cachefile.cc 2013-03-04 18:22:17.0 -0800
@@ -110,6 +110,20 @@
return true;
}
/*}}}*/
+// CacheFile::BuildSourceListFile - Open and build one sources.list file/*{{{*/
+// -
+/* */
+bool pkgCacheFile::BuildSourceListFile(std::string file, OpProgress *Progress)
+{
+ if (SrcList != NULL)
+ return true;
+
+ SrcList = new pkgSourceList();
+ if (SrcList-Read(file) == false)
+ return _error-Error(_(The list of sources could not be read.));
+ return true;
+}
+ /*}}}*/
// CacheFile::BuildPolicy - Open and build all relevant preferences /*{{{*/
// -
/* */
diff -Nru apt-0.9.7.5ubuntu5.2/apt-pkg/cachefile.h apt-0.9.7.5ubuntu5.2+gthomas1/apt-pkg/cachefile.h
--- apt-0.9.7.5ubuntu5.2/apt-pkg/cachefile.h 2012-11-01 02:48:40.0 -0700
+++ apt-0.9.7.5ubuntu5.2+gthomas1/apt-pkg/cachefile.h 2013-03-04 18:22:12.0 -0800
@@ -62,6 +62,7 @@
bool BuildCaches(OpProgress *Progress = NULL,bool WithLock = true);
__deprecated bool BuildCaches(OpProgress Progress,bool const WithLock = true) { return BuildCaches(Progress, WithLock); };
bool BuildSourceList(OpProgress *Progress = NULL);
+ bool BuildSourceListFile(std::string file, OpProgress *Progress = NULL);
bool BuildPolicy(OpProgress *Progress = NULL);
bool BuildDepCache(OpProgress *Progress = NULL);
bool Open(OpProgress *Progress = NULL, bool WithLock = true);
diff -Nru apt-0.9.7.5ubuntu5.2/cmdline/apt-get.cc apt-0.9.7.5ubuntu5.2+gthomas1/cmdline/apt-get.cc
--- apt-0.9.7.5ubuntu5.2/cmdline/apt-get.cc 2012-11-09 00:40:44.0 -0800
+++ apt-0.9.7.5ubuntu5.2+gthomas1/cmdline/apt-get.cc 2013-03-04 18:21:04.0 -0800
@@ -1641,14 +1641,19 @@
/* */
bool DoUpdate(CommandLine CmdL)
{
- if (CmdL.FileSize() != 1)
- return _error-Error(_(The update command takes no arguments));
+ if (CmdL.FileSize() 2)
+ return _error-Error(_(The update command takes at most one argument));
CacheFile Cache;
// Get the source list
- if (Cache.BuildSourceList() == false)
- return false;
+ if (CmdL.FileSize() == 2) {
+ if (Cache.BuildSourceListFile(CmdL.FileList[1]) == false)
+ return false;
+ } else {
+ if (Cache.BuildSourceList() == false)
+ return false;
+ }
pkgSourceList *List = Cache.GetSourceList();
// Create the progress
Bug#714149: sbuild: Let users push additional s to the build dependencies dummy archive
clone 700522 -1 retitle -1 sbuild: Support --add-repository to add an apt source for just one build block -1 by 714877 merge 700522 714149 kthxbye On Wed, 3 Jul 2013, Emanuele Aina wrote: merge 700522 714149 thanks Cc cont...@bugs.debian.org :) I'm open to suggestions for the command line option name: you used --add-package, I used --add-extra-package but I'd also consider --inject-package to differentiate it more from the current --add-* options which operate on the control file. Yeah, I'm not picky about the name. Though, I'm a fan of shorter names, especially since this is something that's very likely to be primarily used interactively instead of by scripts/cronjobs/etc. driving sbuild. Also want to take a crack at --add-repository? :-) [...] It would a really nice thing to do but I'm not sure I will have the time to look into that. :( Is there an already open bug report for apt-get mentioning our use case or would you care to open it? They seems two different issues and it would be unfortunate to lose track of it once this bug gets closed. I just reported #714877 to apt, with the partial work I did. I'm also cloning my original bug to a separate report for --add-repository, since that's a separate request from --add-(extra)-package. -- Geoffrey Thomas gtho...@mokafive.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714877: apt: Please support an apt-get update for a single repository only
On Wed, 3 Jul 2013, David Kalnischkies wrote: Your problem is the cleanup of unused files and the solution should be: -o APT::List-Cleanup=0 In sofar you can implement the requested feature without changing apt code: -o APT::List-Cleanup=0 -o Dir::Etc::sourcelist=/dev/null -o Dir::Etc::sourceparts=/directory/with/just/a/few/sources.list.d/files/; (or the other way around with just one file; I remember writing a patch for behaving nicely if a directory is /dev/null – not sure what version this is in though currently, but wheezy should have it at least) Feel free to use this for sbuild as it will work in any APT version. Oh man, this is fantastic! Updating just a local apt repository (made with dpkg-scanpackages) takes a fraction of a second. I'll use this for my sbuild branch, and send in a patch to use this for sbuild's current implementation. I'd still like an actual feature for this, so that the syntax is more obvious, but I guess sbuild is running this inside the chroot and won't be able to rely on it. If you'd prefer not to add this as a feature, I'd be perfectly happy with documentation to this effect. Thanks for the tip! -- Geoffrey Thomas gtho...@mokafive.com
Bug#714149: sbuild: Let users push additional s to the build dependencies dummy archivearchive
On Wed, 26 Jun 2013, Emanuele Aina wrote: When building related set of packages most people resort to set up a local archive to enable the newly built packages to depend on locally built dependencies for which the needed version has not hit the main archive yet. Since sbuild already sets up a dummy archive for build dependencies, it could also allow users to specify a list of packages that should be pushed there. To do so I've added an --add-extra-package option that accepts a debfile and can be used multiple times. It already allowed me to locally build packages which depend on stuff not yet in the archive without any additional setup. The git repo (`add-extra-package` branch) with the patches is at http://cgit.collabora.com/git/user/em/sbuild/log/?h=add-extra-package I also took the chance to refactor a bit the dummy archive handling and split it out of the ResolverBase class. Even if not strictly needed it allowed me to have a clear idea of the involved pieces and I think that the result is a bit easier to understand and more flexible. Comments and suggestions welcome, I'm not very proficient in Perl. :) Hi Emanuele, This looks like exactly what I was going for with this much smaller patch, written for bug #700522: https://github.com/geofft/sbuild/commit/3f7ecfde5e07c66ec1d7e88fac7423f94400f68b See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700522 Want to merge these two wishlist bugs? I haven't looked in detail at your refactoring, but it felt like my patch was adding this in a slightly questionable manner, so I'd be happy for yours to get merged instead if it's preferable. Also want to take a crack at --add-repository? :-) My plan there was to patch `apt-get update` to let you update a single repository, clean up the existing messy code that you refactored into force_update_archive_list() to use that interface, and then allow adding a sources.list.d file and updating that. Unfortunately the most obvious way to implement that apt patch ends up with apt forgetting about every other source, and I didn't have time to try harder. -- Geoffrey Thomas gtho...@mokafive.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#712552: reportbug: Please describe difference between RFA and O better
reopen 712552 thanks On Sun, 30 Jun 2013, Sandro Tosi wrote: Attached is a patch that rephrases both of these descriptions to make the difference a little more distinct. In particular, it clarifies that the ... please first fix http://www.debian.org/devel/wnpp/ and then we'll update reportbug too. That page includes reportbug's output, so there's a dependency here, unfortunately -- I can't fix that page without including a patch to reportbug's output. Is the text that I proposed acceptable to you, for me to send in a patch to the website? If so, then feel free to close this, and I'll reopen this bug once I hear back from the web team. I don't want to say something about reportbug that the reportbug maintainers think is untrue. -- Geoffrey Thomas http://ldpreload.com geo...@ldpreload.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#712116: DPkg::Pre-Install-Pkgs should receive multiarch-qualified package names
tags 712116 + patch
thanks
Dear maintainers,
On Thu, 13 Jun 2013, Anders Kaseorg wrote:
The current input format for DPkg::Pre-Install-Pkgs hooks makes it
impossible to tell which architecture of a multiarch package is being
removed. For example, removing libbz2-1.0:amd64 and libbz2-1.0:i386
results in this input:
libbz2-1.0 1.0.6-4 - **REMOVE**
libbz2-1.0 1.0.6-4 - **REMOVE**
Can we change the format to arch-qualify the package names as
${binary:Package} does?
Attached is a patch to add a new v3 mode for input to Pre-Install-Pkgs,
and extend SendV2Pkgs to insert the architecture immediately after the
name of the package. I've tested this locally and this seems to work fine
for installing and removing native-arch, arch-all, and non-native-arch
packages. (The native arch, not all, seems to get displayed for arch-all
packages, which seems acceptable but a little confusing.)
So now a line of output is something like
libfuse2 i386 2.9.2-4 - **REMOVE**
I suppose what we're really interested in pkg.FullName(true), since we
don't hugely care to see the architecture if it's the native one. So for
our use case, v3 mode calling FullName(true) instead of Name() would also
be fine. I'm not sure if this would make any existing scripts harder to
implement, which is why I didn't include it. I suppose adding two new
fields for Arch and FullName(true) would be the most useful, but it seems
somewhat excessive.
Note that this issue applies to the configure step as well as to the
remove step.
--
Geoffrey Thomas
geo...@mit.eduFrom 924125b8eae1dbe9e057dd620c2572ef5955d779 Mon Sep 17 00:00:00 2001
From: Geoffrey Thomas geo...@ldpreload.com
Date: Mon, 17 Jun 2013 00:51:44 -0700
Subject: [PATCH] Add a v3 mode that includes the architecture for
Pre-Install-Pkgs input.
---
apt-pkg/deb/dpkgpm.cc |8 +---
apt-pkg/deb/dpkgpm.h |2 +-
doc/apt.conf.5.xml|5 +++--
3 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/apt-pkg/deb/dpkgpm.cc b/apt-pkg/deb/dpkgpm.cc
index 3bc31dc..732c58a 100644
--- a/apt-pkg/deb/dpkgpm.cc
+++ b/apt-pkg/deb/dpkgpm.cc
@@ -242,9 +242,9 @@ bool pkgDPkgPM::Remove(PkgIterator Pkg,bool Purge)
// -
/* This is part of the helper script communication interface, it sends
very complete information down to the other end of the pipe.*/
-bool pkgDPkgPM::SendV2Pkgs(FILE *F)
+bool pkgDPkgPM::SendV2Pkgs(FILE *F, unsigned int Version)
{
- fprintf(F,VERSION 2\n);
+ fprintf(F,VERSION %u\n, Version);
/* Write out all of the configuration directives by walking the
configuration tree */
@@ -280,6 +280,8 @@ bool pkgDPkgPM::SendV2Pkgs(FILE *F)
pkgDepCache::StateCache S = Cache[I-Pkg];
fprintf(F,%s ,I-Pkg.Name());
+ if (Version = 3)
+ fprintf(F,%s ,I-Pkg.Arch());
// Current version
if (I-Pkg-CurrentVer == 0)
fprintf(F,- );
@@ -404,7 +406,7 @@ bool pkgDPkgPM::RunScriptsWithPkgs(const char *Cnf)
}
}
else
- SendV2Pkgs(F);
+ SendV2Pkgs(F, Version);
fclose(F);
diff --git a/apt-pkg/deb/dpkgpm.h b/apt-pkg/deb/dpkgpm.h
index aab39f6..2aa0556 100644
--- a/apt-pkg/deb/dpkgpm.h
+++ b/apt-pkg/deb/dpkgpm.h
@@ -79,7 +79,7 @@ class pkgDPkgPM : public pkgPackageManager
// Helpers
bool RunScriptsWithPkgs(const char *Cnf);
- bool SendV2Pkgs(FILE *F);
+ bool SendV2Pkgs(FILE *F, unsigned int Version);
void WriteHistoryTag(std::string const tag, std::string value);
// apport integration
diff --git a/doc/apt.conf.5.xml b/doc/apt.conf.5.xml
index be1d7ad..39f47ec 100644
--- a/doc/apt.conf.5.xml
+++ b/doc/apt.conf.5.xml
@@ -691,8 +691,9 @@ DPkg::Pre-Install-Pkgs {/usr/sbin/dpkg-preconfigure --apt;};
paraVersion 2 of this protocol dumps more information, including the
protocol version, the APT configuration space and the packages, files
- and versions being changed. Version 2 is enabled by setting
- literalDPkg::Tools::options::cmd::Version/literal to 2. literalcmd/literal is a
+ and versions being changed. Version 3 also adds the architecture of the
+ package to the output. These versions can be enabled by setting
+ literalDPkg::Tools::options::cmd::Version/literal to 2 or 3. literalcmd/literal is a
command given to literalPre-Install-Pkgs/literal./para/listitem
/varlistentry
--
1.7.10.4
Bug#712627: sbuild: Please accept 0 as a source version number
Package: sbuild
Version: 0.64.0-1
Tags: patch
Dear maintainer,
I have a very local package whose source version is 0 because don't have
proper version numbering yet while the software is under initial
development (debian/rules adds a build timestamp to the binary package).
It doesn't build with sbuild, because sbuild checks the result of
Dpkg::Version-new for perl falseness, and 0 is false.
Attached is a super-trivial patch to check for undef instead, since that's
what Dpkg::Version is documented as returning on error. I've tested that
my package now builds, but setting the version in debian/changelog to
badversion still causes sbuild to fail.
--
Geoffrey Thomas
gtho...@mokafive.comFrom ffdb2d44754dd6d5f73da5e288928f0c30facff3 Mon Sep 17 00:00:00 2001
From: Geoffrey Thomas gtho...@mokafive.com
Date: Mon, 17 Jun 2013 18:44:15 -0700
Subject: [PATCH] sbuild: 0 is a valid version number
---
bin/sbuild |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/bin/sbuild b/bin/sbuild
index e12bf72..6711749 100755
--- a/bin/sbuild
+++ b/bin/sbuild
@@ -194,7 +194,7 @@ sub create_source_package ($) {
my $dist = $pclog-{'Distribution'};
my $pver = Dpkg::Version-new($version, check = 1);
-if (!$pver) {
+unless (defined $pver) {
Sbuild::Exception::Build-throw(
error = Bad version $version in $dsc/debian/changelog,
failstage = pack-source);
--
1.7.10.4
Bug#712552: reportbug: Please describe difference between RFA and O better
Package: reportbug
Version: 6.4.4
Tags: patch
Dear wonderful maintainers,
On #debian-mentors the other day, I learned that there's a consensus that
RFA is not merely a less-urgent version of O, but that in an RFA, the
package maintainer retains the right to decide their successor and the
package isn't up for immediate adoption by anyone who wants. See
http://lists.debian.org/debian-qa/2012/09/msg00055.html
for some discussion.
I think I'd gotten the impression that RFA and O were equivalent except
for urgency from the WNPP website
http://www.debian.org/devel/wnpp/
which, in part, quotes reportbug's output:
2 OThe package has been `Orphaned'. It needs a new maintainer as
soon as possible.
3 RFA This is a `Request for Adoption'. Due to lack of time,
resources, interest or something similar, the current
maintainer is asking for someone else to maintain this
package. They will maintain it in the meantime, but perhaps
not in the best possible way. In short: the package needs a
new maintainer.
This description, especially the last sentence, doesn't make the
distinction clear. Can the text be rephrased to clarify that RFA is about
soliciting volunteers, and not an open call for anyone to take over the
package like O?
Attached is a patch that rephrases both of these descriptions to make the
difference a little more distinct. In particular, it clarifies that the
maintainer remains with RFA but not O, adds the word prospective before
new maintainer in the RFA description, and drops the In short
sentence. If you have alternate phrasing that you prefer, I'd be happy
with that too.
I'll also follow up with a patch to the website to incorporate the text
you decide on including, and also explicitly state that the appropriate
response to an RFA is to contact the maintainer, instead of unilaterally
retitling to ITA as the page currently suggests. (If you're planning on
taking my phrasing, it'd be great if you could ack my patch promptly even
if you don't commit it immediately, so I can use that phrasing in my patch
to update the website.)
Thanks,
--
Geoffrey Thomas
http://ldpreload.com
geo...@ldpreload.comFrom 1300e055aa81f394be3406cd05989127835b32b2 Mon Sep 17 00:00:00 2001
From: Geoffrey Thomas geo...@ldpreload.com
Date: Sun, 16 Jun 2013 21:40:02 -0700
Subject: [PATCH] Update wnpp text to clarify distinction between RFA and O
---
reportbug/debbugs.py |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/reportbug/debbugs.py b/reportbug/debbugs.py
index 257ab10..ca988fc 100644
--- a/reportbug/debbugs.py
+++ b/reportbug/debbugs.py
@@ -591,9 +591,9 @@ def handle_wnpp(package, bts, ui, fromaddr, timeout, online=True, http_proxy=Non
'a bug in an existing package, please press Enter to '
'exit reportbug.)', {
'O' :
-The package has been `Orphaned'. It needs a new maintainer as soon as possible.,
+The package has been `Orphaned', and no longer has a maintainer. It needs a new maintainer as soon as possible, and anyone interested is welcome to pick up the package.,
'RFA' :
-This is a `Request for Adoption'. Due to lack of time, resources, interest or something similar, the current maintainer is asking for someone else to maintain this package. They will maintain it in the meantime, but perhaps not in the best possible way. In short: the package needs a new maintainer.,
+This is a `Request for Adoption'. The current maintainer is looking for a prospective new maintainer to transfer maintenance to. Until then, they will continue to maintain the package, but may not have the time, resources, or interest to maintain the package as well as possible.,
'RFH' :
This is a `Request For Help'. The current maintainer wants to continue to maintain this package, but they needs some help to do this, because their time is limited or the package is quite big and needs several maintainers.,
'ITP' :
--
1.7.10.4
Bug#685972: kernel BUG at /build/buildd-linux_3.2.41-2-amd64-Wvc92F/linux-3.2.41/drivers/pci/msi.c:3 16!
Devon, Dix, did either of you manage to reproduce this bug without out-of-tree modules? I'm seeing something that appears to be similar (it's a panic, not a bug, on a ThinkPad X1, but still on resume from suspend and involving e1000e and free_msi_irqs), when VMware Player is running. I'd like to know if anyone else had any luck tracking this down. Unfortunately because my issue is a panic, I'm not able to get a ton of information about it. -- Geoffrey Thomas gtho...@mokafive.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709682: ITP: python-github -- Python library for the full Github API v3
Package: wnpp Owner: Geoffrey Thomas geo...@ldpreload.com Severity: wishlist * Package name: python-github Version : 1.15.0 Upstream Author : Vincent Jacques vinc...@vincent-jacques.net * URL : https://github.com/jacquev6/PyGithub * License : LGPL-3+ Programming Lang: Python Description : Python library for the full Github API v3 pygithub is a Python library to access the Github API v3 (the current version of the API). With it, you can manage your Github resources (repositories, user profiles, organizations, etc.) from Python scripts. The code is compatible with both Python 2 and 3, so I'll provide both python-github and python3-github binary packages. This is a dependency for tratihubis, a tool to migrate Trac tickets to Github issues, which I also intend to package. I'm planning for both of these to be team-maintained by the debian-python team. -- Geoffrey Thomas http://ldpreload.com geo...@ldpreload.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695361: man-db: Please revert workaround for less 456
On Mon, 6 May 2013, Colin Watson wrote: Thanks for the patch. I'd like to review and upload this myself, but it's a public holiday today so I don't know whether I'll quite get to it before your deadline. I will definitely get to it by tomorrow, if you can wait until then. I'm perfectly happy to wait -- it'll take a bit to get to testing anyway. Speaking of migrations, I'm thinking through how to avoid the same problem (apt threatening to remove less) in saucy. Since man-db is Ubuntu-patched, it won't get automatically imported, so I guess the answer is just to hold off on merging (slash syncing, the patch is just M-A: foreign) until after less gets synced into Ubuntu. The other option would be to remove the Breaks entirely and decide it's not that important. -- Geoffrey Thomas http://ldpreload.com geo...@ldpreload.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695361: less: buggy backslash handling in prompt string: \ needs to be doubled
On Sun, 5 May 2013, Sven Joachim wrote:
On 2013-03-22 11:01 +0100, Vincent Lefevre wrote:
On 2013-03-22 22:50:40 +1300, Jan Larres wrote:
version 457 of less, released in December, reverts to the old parsing
behaviour and makes the new one available as an option instead. So it
would probably be a better idea to upgrade to that version instead.
I agree. And what's important is that compatible versions of less
and man-db are installed at the same time.
Unfortunately that's currently impossible in Jessie because the version
of man-db there declares a Breaks: less ( 456), and less cannot
transition to testing because of this bug. So it would be good to fix
it or downgrade the severity, since not being able to install both
man-db and less sucks.
Since upstream less has reverted this behavior, it seems to me that the
right approach is to revert man-db's workaround, mark it as breaking less
456 only (since 456 and = 457 are then both okay), and upload the new
less upstream release as closing this bug.
Attached is a debdiff for the change to man-db needed to implement this.
Since you can't have a Breaks field for a range bounded on both sides,
I've just marked it as breaking less 456-1 and 456-1ubuntu1, the only
known packaged versions. I've tested that building this patch works the
way that you'd expect: apt neither installs the new version of less from
unstable, nor attempts to remove it. I've also test-built the new less
upstream release (458; 457 is no longer available) with no other changes
to packaging, and it works fine and `man apt.conf` displays the right
thing.
If the other folks on this bug report think this looks sane, I'll clone
this bug and assign it to man-db.
In addition to uploading the new man-db packaging and the new less
upstream, man-db upstream r1443 should be reverted.
--
Geoffrey Thomas
http://ldpreload.com
geo...@ldpreload.comdiff -Nru man-db-2.6.3/debian/changelog man-db-2.6.3/debian/changelog
--- man-db-2.6.3/debian/changelog 2012-12-16 04:18:24.0 -0800
+++ man-db-2.6.3/debian/changelog 2013-05-05 16:20:30.0 -0700
@@ -1,3 +1,10 @@
+man-db (2.6.3-3geofft1) unstable; urgency=low
+
+ * The incompatible change from less 456 has been reverted, so revert
+our patch and instead Break that version of less.
+
+ -- Geoffrey Thomas geo...@ldpreload.com Sun, 05 May 2013 16:18:17 -0700
+
man-db (2.6.3-3) unstable; urgency=low
* Support parallel builds.
diff -Nru man-db-2.6.3/debian/control man-db-2.6.3/debian/control
--- man-db-2.6.3/debian/control 2012-12-16 04:17:47.0 -0800
+++ man-db-2.6.3/debian/control 2013-05-05 17:11:58.0 -0700
@@ -13,7 +13,7 @@
Suggests: groff, less, www-browser
Provides: man, man-browser
Conflicts: man, suidmanager ( 0.50)
-Breaks: less ( 456)
+Breaks: less (= 456-1), less (= 456-1ubuntu1)
Replaces: man, nlsutils, manpages-de ( 0.5-4)
Multi-Arch: foreign
Description: on-line manual pager
diff -Nru man-db-2.6.3/debian/patches/less-incompatibility.patch
man-db-2.6.3/debian/patches/less-incompatibility.patch
--- man-db-2.6.3/debian/patches/less-incompatibility.patch 2012-12-16
04:05:23.0 -0800
+++ man-db-2.6.3/debian/patches/less-incompatibility.patch 1969-12-31
16:00:00.0 -0800
@@ -1,52 +0,0 @@
-Description: Handle incompatible change to option string escaping in less 456
-Author: Colin Watson cjwat...@debian.org
-Origin: backport,
http://bazaar.launchpad.net/~cjwatson/man-db/trunk/revision/1443
-Bug-Debian: http://bugs.debian.org/695459
-Forwarded: not-needed
-Last-Update: 2012-12-16
-
-Index: b/src/man.c
-===
a/src/man.c
-+++ b/src/man.c
-@@ -814,17 +814,35 @@
- static char *escaped_string;
- char *ptr;
-
-- /* 2*strlen will always be long enough to hold the escaped string */
-+ /* 4*strlen will always be long enough to hold the escaped string */
- ptr = escaped_string = xrealloc (escaped_string,
-- 2 * strlen (string) + 1);
--
-+ 4 * strlen (string) + 1);
-+
- while (*string) {
-+ /* less 456 requires dollar and backslash to be escaped in
-+ * the option string; this means that we need two
-+ * backslashes to effectively escape characters special in
-+ * prompt strings, and that displaying a backslash requires
-+ * two levels of escaping. Note that this appears to be an
-+ * incompatible change, so this will overescape for earlier
-+ * versions of less.
-+ */
- if (*string == '?' ||
- *string == ':' ||
- *string == '.' ||
-- *string == '%' ||
-- *string == '\\')
-+ *string == '%') {
-+ /* Special only in prompt strings
Bug#695361: man-db: Please revert workaround for less 456
clone 695361 -1
reassign -1 man-db
retitle -1 man-db: Please revert workaround for less 456
severity -1 serious
# Justification: 695361 is serious
block 695361 by -1
tags -1 patch
thanks
Hi Colin,
In #695459 you added a workaround for the new backslash-escaping behavior
in less 456-1. Upstream less 457 has since reverted this behavior unless
opted in, so I think the sanest thing to do is to remove this workaround
entirely from man-db, declare a Breaks on just version 456, and put less
= 457 into testing.
Attached is a debdiff for a local test build to do this -- see also my
comment in the less bug, #695361, reproduced below. Please incorporate and
upload this change, and also revert the upstream commit of the workaround;
then less 457 or above can be safely uploaded to close #695361.
I note that the maintainers of both man-db and less are on the
LowThresholdNmu list, so since this is currently blocking sane
dist-upgrades to testing (I'm caring because I tried to upgrade my laptop
and apt is threatening to remove less), I'm happy to NMU either or both
these packages, if that's easier for you. I'll wait for comments until
tomorrow evening my time, about 24h, before doing so.
--
Geoffrey Thomas
http://ldpreload.com
geo...@ldpreload.com
On Mon, 6 May 2013, Vincent Lefevre wrote:
On 2013-05-05 17:55:44 -0700, Geoffrey Thomas wrote:
Since upstream less has reverted this behavior, it seems to me that the
right approach is to revert man-db's workaround, mark it as breaking less
456 only (since 456 and = 457 are then both okay), and upload the new
less upstream release as closing this bug.
Attached is a debdiff for the change to man-db needed to implement this.
Since you can't have a Breaks field for a range bounded on both sides, I've
just marked it as breaking less 456-1 and 456-1ubuntu1, the only known
packaged versions. I've tested that building this patch works the way that
you'd expect: apt neither installs the new version of less from unstable,
nor attempts to remove it. I've also test-built the new less upstream
release (458; 457 is no longer available) with no other changes to
packaging, and it works fine and `man apt.conf` displays the right thing.
I haven't tested, but I think this is the way to do.
--
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
diff -Nru man-db-2.6.3/debian/changelog man-db-2.6.3/debian/changelog
--- man-db-2.6.3/debian/changelog 2012-12-16 04:18:24.0 -0800
+++ man-db-2.6.3/debian/changelog 2013-05-05 16:20:30.0 -0700
@@ -1,3 +1,10 @@
+man-db (2.6.3-3geofft1) unstable; urgency=low
+
+ * The incompatible change from less 456 has been reverted, so revert
+our patch and instead Break that version of less.
+
+ -- Geoffrey Thomas geo...@ldpreload.com Sun, 05 May 2013 16:18:17 -0700
+
man-db (2.6.3-3) unstable; urgency=low
* Support parallel builds.
diff -Nru man-db-2.6.3/debian/control man-db-2.6.3/debian/control
--- man-db-2.6.3/debian/control 2012-12-16 04:17:47.0 -0800
+++ man-db-2.6.3/debian/control 2013-05-05 17:11:58.0 -0700
@@ -13,7 +13,7 @@
Suggests: groff, less, www-browser
Provides: man, man-browser
Conflicts: man, suidmanager ( 0.50)
-Breaks: less ( 456)
+Breaks: less (= 456-1), less (= 456-1ubuntu1)
Replaces: man, nlsutils, manpages-de ( 0.5-4)
Multi-Arch: foreign
Description: on-line manual pager
diff -Nru man-db-2.6.3/debian/patches/less-incompatibility.patch
man-db-2.6.3/debian/patches/less-incompatibility.patch
--- man-db-2.6.3/debian/patches/less-incompatibility.patch 2012-12-16
04:05:23.0 -0800
+++ man-db-2.6.3/debian/patches/less-incompatibility.patch 1969-12-31
16:00:00.0 -0800
@@ -1,52 +0,0 @@
-Description: Handle incompatible change to option string escaping in less 456
-Author: Colin Watson cjwat...@debian.org
-Origin: backport,
http://bazaar.launchpad.net/~cjwatson/man-db/trunk/revision/1443
-Bug-Debian: http://bugs.debian.org/695459
-Forwarded: not-needed
-Last-Update: 2012-12-16
-
-Index: b/src/man.c
-===
a/src/man.c
-+++ b/src/man.c
-@@ -814,17 +814,35 @@
- static char *escaped_string;
- char *ptr;
-
-- /* 2*strlen will always be long enough to hold the escaped string */
-+ /* 4*strlen will always be long enough to hold the escaped string */
- ptr = escaped_string = xrealloc (escaped_string,
-- 2 * strlen (string) + 1);
--
-+ 4 * strlen (string) + 1);
-+
- while (*string) {
-+ /* less 456 requires dollar and backslash to be escaped in
-+ * the option string; this means that we need two
-+ * backslashes to effectively escape characters special
Bug#702719: debian-maintainers: Please add Geoffrey Thomas as a DM
On Fri, 12 Apr 2013, Aníbal Monsalve Salazar wrote: On Thu, Apr 04, 2013 at 08:41:06AM +1100, Aníbal Monsalve Salazar wrote: package debian-maintainers tags 702719 + moreinfo stop Hello Geoffrey, The output of keycheck.sh [1] is below. [1] http://anonscm.debian.org/viewvc/nm/trunk/nm-templates/keycheck.sh pub 4096R/5C413520 2011-09-06 [expires: 2014-03-07] Key fingerprint = 8896 E71B 57BA F57C 0CB5 481D 5C52 4526 5C41 3520 uid Geoffrey Thomas geo...@mit.edu sig! A7D86B95 2011-10-02 Karl Ramm k...@debian.org sig! 70096AD1 2013-03-07 Asheesh Laroia ashe...@asheesh.org sig! BE595F6B 2012-05-19 Alexander Chernyakhovsky acher...@mit.edu sig! 7D86500B 2012-05-11 Colin Watson cjwat...@chiark.greenend.org.uk sig!35C413520 2012-05-08 Geoffrey Thomas geo...@mit.edu sig!35C413520 2013-03-07 Geoffrey Thomas geo...@mit.edu sig!35C413520 2011-09-06 Geoffrey Thomas geo...@mit.edu uid Geoffrey Thomas geo...@ldpreload.com sig! A7D86B95 2011-10-02 Karl Ramm k...@debian.org sig! 70096AD1 2013-03-07 Asheesh Laroia ashe...@asheesh.org sig! BE595F6B 2012-05-19 Alexander Chernyakhovsky acher...@mit.edu sig! D53FDCB1 2012-05-10 Andrew Starr-Bochicchio a.star...@gmail.com sig! 7D86500B 2012-05-11 Colin Watson cjwat...@chiark.greenend.org.uk sig!35C413520 2012-05-08 Geoffrey Thomas geo...@mit.edu sig!35C413520 2013-03-07 Geoffrey Thomas geo...@mit.edu sig!35C413520 2011-09-06 Geoffrey Thomas geo...@mit.edu sub 4096R/1CF674CB 2011-09-06 [expires: 2013-05-08] sig! 5C413520 2012-05-08 Geoffrey Thomas geo...@mit.edu . Key is OpenPGP version 4 or greater. Key has 4096 bits. Valid e flag, but it expires Wed 08 May 2013 17:14:51 UTC. This is too soon! Please ask the applicant to extend the lifetime of their OpenPGP key. Valid s flag, expires Fri 07 Mar 2014 04:02:15 UTC. Please extend the lifetime of your OpenPGP key. Please upload it to a keyserver and remove the moreinfo tag of #702719. Cheers, Aníbal ping Just did this (sorry, was travelling a bunch and my PGP key lives on a desktop at home). I've bumped the expiration for the encryption subkey to a year from now, and uploaded it to the standard keyservers (pgp.mit.edu, at least, has it). Is that sufficient, or do you want a jetring changeset thing too? -- Geoffrey Thomas http://ldpreload.com geo...@ldpreload.com
Bug#702719: debian-maintainers: Please add Geoffrey Thomas as a DM
Package: debian-maintainers Severity: normal Hi DM and keyring teams, Please add me to the DM keyring. I've attached a jetring changeset with my key (5C5245265C413520). Thanks, -- Geoffrey Thomas http://ldpreload.com geo...@ldpreload.comComment: Add Geoffrey Thomas geo...@ldpreload.com as a Debian Maintainer Date: Sun, 10 Mar 2013 10:07:57 -0700 Action: import Recommended-By: Luke Faraone lfara...@debian.org, Asheesh Laroia paulprot...@debian.org Agreement: http://lists.debian.org/debian-newmaint/2013/03/msg00011.html Advocates: http://lists.debian.org/debian-newmaint/2013/03/msg00012.html http://lists.debian.org/debian-newmaint/2013/03/msg00013.html Data: -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.4.12 (GNU/Linux) mQINBE5lljEBEAC3IscYabtThjMtDFhu6j2rlhvckoixIdNpq/hqciERYCUqoJNP ipsAVoMVZDgL9rC+jMNFHWfIlPMoTSmArKYxOTp03OOsebcUlP4mwnyCPHPPOZCO ZH+5eoCdZptX/cA6p9nPDGfzrRbi3ff70dEkd4Xt/xQ6YJrJWFMJbjlpa0pAdCB+ TU3gPqOkLv36NLNEATZM4roPXTn2pTxHpQyCzpb1FDihqaFrhchxvTP01O7ba+I2 3oSfa65LFFqOl9ffJsnwmUlyTFXaChw0HBLs6ShAKGrlHL4rUg9vID6VwLjkpqAv nCgOn9vOTPkGZraHp2RlxlEkXuS1kxYgvWjyBKWnFZPW27N71EtjVJVveUG8xtqt cXaDOeOepetLct+NCg46rnmu1zaVLLJQyfPGaa5VkKqc525JKSUdnV+35VMtRUUC ZXnQ231boy8ERG9Yacqdjnf2FKBT993Je6uA8rUyMLhVwxNRoY1OOOMaBOiJ3xYx P+kh47WIXwTTbTY9UcKv5CBkskxptDscZsggpn5w38H0G5BuR9jTdrRD6UjqJnTz lz/KWunvXU69dUW4h3uVN0XB8lk/3cWOdGVwGbUonAsfj86gMIvtUtLd+210Kk4x KL4Ra1tB//gYnodxgA55ZG2+JrhuXg2aR8LHbBE6phuJ1XFWq3sw+lEzgQARAQAB tCBHZW9mZnJleSBUaG9tYXMgPGdlb2ZmdEBtaXQuZWR1PohGBBARAgAGBQJOiNPb AAoJELHKkuin2GuVrHQAnj6tpYfkeypLO31ixmSmgyhAUASbAJ9DcYvjcz+43F87 Xnp/UZjlvKtJDokCHAQQAQIABgUCTojUWQAKCRDmNxb04GmUniWXEACfU5TRw8dt oC+7CiizkBfAdnLikNqNS/nKaPG1YUg9gnibpxdRVqODlEbys2zH48yW5sz7nGNQ ILFTYopDsE9O2sW7Pnf2ppF/wp+ib49CMB9I0DZ9y0jaDJ95dmfVJqN8cdwQbECA nqE3HWcSsctlz2nuPzWMLPts4iq6c49b/TxiFAf1QIq930/yYFEsB3OGK1hCELDX HLbvKC9uvNadzU3+6lsTiRG8Jo4O+4DVV9OG42Hqt5NnaMWBznHJVYDyHGOB4177 /Po4zr7LIro4iiAU//ZWXGlyK6XnfVcBvUkOiAo0W0YtXZoQPttQGxp/QkLJbdhi Jlv47y35TBF20n0sZJqpkjBiAvrCAbMuW+N9f9bmeURxdjHQZtu3XdJrGSXp//mV w+ZrYxd48uuAUZnCx5P44mW4e4d3Rovy0Lw6sdY4Nv6I1GjPD03PWdaZ37n9vxEm vFSF97mU28UseDSuy5dUXdCBHIU+f0FnhrHMGYGYz2aCMWUBey7tqpRyqGUwRNjN +6l4bnw+2xH7wnpdVDpMQ5xdm6XMWOE/GK4zTeyVlUYQxsyEmvYyzyACQj3yIzhL oGhQHicf/JRel57smIfC7inhLmp08m8WNE1RkZMkpQdk7/KdJsJFiZ3u00RCUxCo 648FxiW9PFyxsKNeWPCZcdGxqUpVtj/clYkCHAQQAQoABgUCTmWngwAKCRCYY8w5 F0FpIAt1EACw1syk6hD3Ag5Lmnp54E4jxonMZEn3h48i3yfW+0DYRTDgyv8rK9S9 TLiCMVUDpcvCUd98SRSr+MVDQw+KieTHlPlaGQJznvA6VekrlSzBw3Hxy7dCBxry 57PEEKU0ry5RyyYP+XcmbNjR5sbXSAm4UG+H2KP5kkJutB04gsrPd58p5xcxfbuH 0KvJJktREhfQoMXJ1t2Fr+dqZ8wh6p3XuCojk+diKayPrDZuqNnmC4NxvGlcCVt+ l/Gh+J2aJk3bJf0cSIwjmq+4T4HvvabnnkQbSur7prVbK1sZ5hJEOU8c52CxAW8l xMX0zEMhgMXxvIhM0i7tiqbreNest0ceA3Q91tHK9copg650GBgdoGobl4TnNtgj KhC/1gLLREwLHHt9SVHkeimxCA7kzpfFlMeRVZj2u7igbEgxcYN6WJ0PgIUyPNp+ 5Lt46gAK1LgWiP9a74bLp8KhvMF7WdMj4SnmXF4/0fP1MJsdl6QqfAOYXEbaPFEF SSVrGU9oEibJaAf1QVAd7ytsooIuFGAbRDu6mQMH8epURuNTxnFiDPWlP/X6AImr MqQw2TftpVIeMwPm1RDLmJfEDhsKNgDDw6D/ogkW0YeKVQlZC8V6HwU1JMLPkpMs I2ZGOPHnAtfAqxpAE9T44FST9MMouWnsgwNyi8jP8w/VSSWggKVJyokCPgQTAQIA KAIbAwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AFAk+pUsQFCQMk8BAACgkQXFJF JlxBNSCI6g//cOAQNxzlm0Edfwe3bNwerkgYap7S3A/ZOrhzHOc5Fb6CldK3HdsX +Xd/ZkznUIPVpTF5xF2KEW6dpCOpLOB/JNur6BqVSWX9upqFJiXcFraqzJ2yv9dc K1ASmQFHueV9MzpVh6A2ZV7UxxKPKfMRNLG68Uwv78Oh5Eozn16QSlsd44VDFt1f A3KXhBn9q/NAEerz7rINdrrsHi0U5SgaOdrQ+piWg4nqscas6ex/KGwLp96S5Wjb +unFEJisD/xc3QFcsRIfJDqBvbuIdJIN5sufiMTpLhO8yiJscvwl+V0a8Fx+FcEC zDwAWC33HA6wkEjALHZ33qbeQFMgWtSoQgf9BDWrhqXgjaqAhgdo6M72jVwjeeEe LeR8nHbBYP22fFVfrGpShc8oxgJyezWmQtK6trr4zywP1ZPTz6554kW57ETi5Ok7 p1BzzeO73C+hy6gOHGZxQvvT4bQUnSwbfTsAot2YbOW8gqdXZM/xjO7UBt3QHsrX S2eXQsy79avWY5WcjsUvyS+foN7nmCTCWdfjC4JxiWTHUdtotqrRjEFK9hEnmaVA 6psHSOqwiU3Q52RMhA84UHtn5P5AowusccF8L+P0FWj1H2j3Ert4op6ucZLR+0TR pfbawG8QV9BdxGmxSNWzV43VbTE6zHuWdFLSu9x1fWilFzdwK6asUamJAj4EEwEC ACgFAk5lnB0CGwMFCQCeNAAGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEFxS RSZcQTUgLLIP/iCHEKwUjY3xOhAXN2VSnD1GlfqTZWRGWaD/GRJtdEu1ZfCY7G3G Hd2BW7uvxvz27IlUa4ZkcI+HviAsz8jamdSQglhE4nHG/FgMrvttRzn9SXwRbZpc KE0jIvjJsIYqTyYV1K4p6utVln1ze+rWlY3hjPQPFWWw5XxsntzBQeNNhp/j4ccU m0ftm03AOskU5sfDBxKxRTH1/ZGiijv1vLL64I9bCB6Q8ywfEqXCJteFwK7NxylO 6wJXlWGJLH/aPFoIaF/fMcFmIDMRnI7FPKRdJJbnD6A4EfWIv1OO0b8f+hugZz/2 vcBUhcfIPZ8y1C5ivQQ3uLWZEDAk2I8domlZup6jokx4u118rU4HM8+aMXkTb6b7 HaTZQmHTLd5/SjW+irydsEhzRkeyMLw3HmEKP3Fx/KhE6QoHL5+7GNfkNj4I+K8h IHNT8LVcQijMoAhVaHd7cldRxTx7StsuDlKKNm3EDodn6K+G6klzjrF3S+tPAPeQ u1GmbwZN9ZW6C6GOqwqtAY0KXH3H90IcuLkiiaghcajg5zLx26+JBYG6BziFSCnu MnjLFnLGtPKiaYeboiv8uqdwRw+kkcDgzCDF/Na5y3BwjssS//mdDMxYLAa9oryd C9cxzgmyZo1lAWK/+ekCgKn2qmNkD4ROipiMpe3Z/fzhBDSHXsS+DbDCiQIcBBAB AgAGBQJPuBH2AAoJELvHVt2+WV9rk+YP/jJWjh7ukIzUX2F191kzgPJscUlNB642 10OU6nmNmkOsCULYCYROLv3AheoEgvvyxZq7zagds6r74GudSxYlrk4xCzaU5hB/ MW0tznkFsJyIm8sceLRLLpNgTDiP6wrNLXDskOlinzcNx/I2SikK2xG2WZX9UYRk kv1f+p8T
Bug#700522: sbuild: Support for locally-built build dependencies
Package: sbuild Version: 0.63.2-1 Severity: wishlist Tags: patch Hi maintainers, When I'm backporting packages locally with the help of sbuild, it's often the case that I need to backport a build-dependency too. Let's say that package foo version 2.0 depends on libbar1 (= 2.0~). If I backport libbar1, I need to make it available to the build of foo. One way to do this is to configure my local schroot to have e.g. ~/apt configured as a repository. This might work okay on a personal machine, provided I remember to be conscientious about cleaning out ~/apt between builds and pass --apt-update, but I'm running into a situation at work where I'm using the same build machine for two different products (one of which should not be built with a backported libbar1), and cleaning out a local apt repository would be painful and also enforce unnecessary serialization on builds. One way to do this would be to have multiple schroots for building the two products, only one of which has the local apt repo. This seems like a waste of space. Attached is a patch that provides the --add-package option to sbuild, which makes a .deb from the host system available to apt in the build chroot for use when resolving build dependencies. Concretely, this means I can do something like sbuild -d stable libbar1_2.0-1.dsc sbuild -d stable --add-package=libbar1_2.0-1_amd64.deb foo_2.0-1.dsc with non-hacked-up schroots, and have things work the way I expect. The implementation of this patch simply copies the .deb into the directory for the local archive (for build-dependency resolution). This makes it a very small patch, and works out fine because it specifically is needed for build-dependency resolution. I'm not positive this is the right approach, though, and would be willing to write a longer patch. Another feature along related lines would be --add-repository, e.g. sbuild -d stable --add-repository=file:/home/geofft/apt ./ foo_2.0-1.dsc or sbuild -d stable --add-repository=http://local-archive/apt stable myrepo foo_2.0-1.dsc I have a naive implementation of this, which doesn't actually work because `apt-get update` is not run after the local archive is created (which the manpage mentions). One approach would be to instead implement this somewhere before --apt-update executes, and have this imply --apt-update. Another would be to add functionality to apt to update only a single repo, which the manpage mentions would be useful (and I think I'd like that functionality for its own sake, anyway). Do you have thoughts on which approach would be better? Both patches are available on my github add-package branch, although this is more intended for feedback than merge: https://github.com/geofft/sbuild/commits/add-package Thanks, -- Geoffrey Thomas gtho...@mokafive.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#607228: [buildd-tools-devel] Bug#607228: no way to run setup command inside a chroot
On Mon, 3 Jan 2011, Roger Leigh wrote: On Wed, Dec 15, 2010 at 04:36:46PM -0500, Sam Hartman wrote: When --setup-hook was implemented in terms of --chroot-setup-commands, the user it is run as changed. Previously it was run as root; now it is run as the build user. That's problematic because there no longer seems to be a way a to run commands as root in the chroot. Yes, this looks like a regression, and we'll fix that so this continues to work for you. We might need to have setup commands that run as root, and some as non-root. I'll discuss it with Andres Mejia, who wrote these features. Has there been progress on this? Note that Ubuntu is carrying a patch to make --chroot-setup-commands run as root, which seems to be suboptimal for lots of reasons (e.g., I run Debian on my laptop and Ubuntu on some work machines, and generally expect sbuild to work fine on both provided the chroots are clean). My use case is as follows. I'm building a related set of packages that inter-depend on each other under the control of a buildbot. The build slave (which runs sbuild) doesn't have the permissions necessary to install into any apt archive. So, I want to modify the chroot to have an additional apt source. The location of that source will depend on which build slave it is, and so I'm running a setup hook to do this. You might like to look at the most recent sbuild in unstable (or git). We create a local apt archive during the build (when using the apt or aptitude build-dep resolvers) and set this up and use it. These are ephemeral (they only last for the duration of the build), but the logic to do the archive setup could be reused to do what you want. We only use it to serve a couple of packages, but it might be useful for your uses as well. Oh hey. Sam, this is exactly what I implemented in #700522. Want to try my git branch and see if that works for your use case? -- Geoffrey Thomas gtho...@mokafive.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672711: sbuild: --append-to-version should set source:Version substvar
tags 672711 + patch
tags 681292 + patch
thanks
On Thu, 12 Jul 2012, Raphael Hertzog wrote:
If you tag the changelog entry with binary-only=yes then
dpkg-gencontrol will use the former changelog entry to find
out the version to put in ${source:Version}.
ftplib (3.1-1-9+b1) unstable; urgency=low, binary-only=yes
You should update --append-to-version to use this mechanism too.
Hi sbuild maintainers,
I was checking on the Debian bugs I opened to see what their status was,
and didn't see progress on this, so I wanted to check to see if we were
waiting on anything from dpkg, or could fix this now in sbuild. The
conversation in #681292 seemd to indicate that you were okay with this
approach.
The debian-672711 branch of https://github.com/geofft/sbuild.git has the
following patch and a changelog entry:
--- a/lib/Sbuild/Build.pm
+++ b/lib/Sbuild/Build.pm
@@ -1324,7 +1324,7 @@ sub build {
}
$dists = $self-get_conf('DISTRIBUTION');
- print F $name ($NMUversion) $dists; urgency=low\n\n;
+ print F $name ($NMUversion) $dists; urgency=low,
binary-only=yes\n\n;
if ($self-get_conf('APPEND_TO_VERSION')) {
print F * Append , $self-get_conf('APPEND_TO_VERSION'),
to version number; no source changes\n;
Can you merge it?
Thanks,
--
Geoffrey Thomas
geo...@mit.edu
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697430: fakeroot: Please separate preloaded libraries with colons
Package: fakeroot Version: 1.18.4-2 Hi fakeroot developers, If @LDPRELOADVAR@ is already set, scripts/fakeroot.in separates LIBS with a space. This works fine for LD_PRELOAD on GNU/Linux, but not for DYLD_INSERT_LIBRARIES on Mac OS X, which must be colon-separated. So if you already have a library in DYLD_INSERT_LIBRARIES, this breaks usage of fakeroot: dyld: could not load inserted library: /Users/gthomas/src/debian/b/lib/libfakeroot.dylib /tmp/d.dylib /Users/gthomas/src/debian/b/bin/fakeroot: line 181: 75294 Trace/BPT trap: 5 FAKEROOTKEY=$FAKEROOTKEY DYLD_INSERT_LIBRARIES=$LIB $@ Fortunately, glibc permits separating LD_PRELOAD with either a space or a colon (see the comment near line 1658 or so in elf/rtld.c, and the changelog entry of 1998-02-01). So I propose that you make scripts/fakeroot.in line 168 use a colon, which will fix the bug on OS X and continue to work fine on GNU platforms. (Because glibc tokenizes at _both_ spaces and colons, there is no problem if the existing LD_PRELOAD variable includes multiple preloads separated by spaces.) I don't know if fakeroot supports any platforms that require @LDPRELOADVAR@ to be space-separated and not colon-separated, which would make my suggested fix not work. -- Geoffrey Thomas http://ldpreload.com geo...@ldpreload.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#693672: config-package-dev: please support using debhelper dh instead of cdbs
Hi Paul (and others reading this bug report), If you're interested in looking at my branch, check out git://geofft.mit.edu/config-package-dev.git. Documentation is sparse (which is mostly why I haven't opened a Debian bug requesting it be merged), but if you have time to look at it, I'm definitely interested in code review and knowing if it fits folks' use cases and fits the syntax you'd expect. The examples directory in the source has Debhelper variants of all the CDBS examples, so that's probably the most obvious place to figure out what using the Debhelper version looks like. I also have a vague intention of making this something suitable to be shipped in Debhelper itself; see the request for dh_divert in bug #41462. Here are the notes I sent to the debathena mailing list when asking for review: - You can generally use a Debhelper 7-style short rules file. You just need to use dh --with config-package instead of dh. (You can also invoke dh_configpackage by hand, with an old-style Debhelper rules file, but why would you do that.) - What you would put in DEB_DIVERT_FILES goes in debian/foo.divert, etc. - The syntax for debian/foo.transform is that each line contains a filename, followed by a command to transform it. This can either be some actual filter, e.g. etc/foo.conf.debathena sed -i 's/foo.com/foo.mit.edu/', or a longer script in the packaging, e.g. etc/foo.conf.debathena debian/transform_foo.conf.debathena. The latter is helpful for porting CDBS packaging, or just transformations that would be more than one line. - DEB_DIVERT_EXTENSION is now debian/foo.divert-extension. If you leave it off, it defaults to the first word of the package name. (I believe this happens to be correct for every single one of our current users, SIPB or otherwise.) Before actual release, I intend to add more documentation to the dh_configpackage command, the ability to invoke it with arguments (just like you can call e.g. dh_install either with no arguments to parse debian/*.install, or with arguments to install that specific file), and more upstreamable names for the divert and remove operations. I'll start a separate thread about that. [... Hm, I still haven't started that thread. I should go do that.] -- Geoffrey Thomas geo...@mit.edu On Mon, 19 Nov 2012, Tim Abbott wrote: Geoffrey Thomas actually has a branch adding support for doing it via debhelper -- Anders and I have unfortunately been slow about reviewing it. I'll see if I can find the time to get it out. -Tim Abbott On Mon, Nov 19, 2012 at 1:31 AM, Paul Wise p...@debian.org wrote: Package: config-package-dev Version: 4.13 Severity: wishlist I personally prefer using debhelper's dh system instead of cdbs. It would be great if config-package-dev could support configuration packages built using debhelper's dh system and drop the cdbs dep. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (700, 'testing'), (600, 'unstable'), (550, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.6-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages config-package-dev depends on: ii cdbs 0.4.115+deb7u1 -- bye, pabs http://wiki.debian.org/PaulWise -- -Tim Abbott
Bug#693672: config-package-dev: please support using debhelper dh instead of cdbs
On Tue, 20 Nov 2012, Paul Wise wrote: It would be great to merge this branch, for now I've gone for a workaround calling the cdbs Makefile before dh_installdeb. The dh_divert stuff kinda ties into the declarative diversions stuff: http://wiki.debian.org/SummerOfCode2011/DeclarativeDiversions The diversions stuff in config-package-dev seems like a workaround for dpkg being buggy with conffiles: http://bugs.debian.org/363524 http://bugs.debian.org/49 Yup, DeclarativeDiversions seems like the right long-term answer, but dpkg doesn't currently support it (as far as I know?), and a bunch of config-package-dev users want support on old Debian/Ubuntu versions, so it won't be obsolete even when dpkg gets that support. It seems likely that we should have config-package-dev end up using declarative diversion support when that lands, but I don't think anyone's thought about designing that transition. And yes, most of why config-package-dev diverts files in favor of a symlink to a new file, instead of to the new file itself, is to be more robust to dpkg. -- Geoffrey Thomas geo...@mit.edu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688713: timidity-daemon: mishandles conffiles
On Thu, 11 Oct 2012, Sébastien Villemot wrote: I have uploaded to DELAYED/2 a NMU of timidity versioned 2.13.2-40.1 which fixes that bug. The debdiff is attached. Don't hesitate to tell me if I should delay the upload longer. Thanks, but would you mind delaying until early next week? There are a couple of wrong patches in the current source package (see #649274), and I was hoping to ask for a single freeze exception to deal with that issue too and a couple of Ubuntu ones. I know I've been remiss about doing an upload, but if it's already past time that an NMU is reasonable, I will make a point of attempting to deal with it this weekend -- and if I don't, feel free to let the NMU proceed. -- Geoffrey Thomas http://ldpreload.com geo...@ldpreload.com
Bug#689070: Please take upstream D-Bus patches for CVE-2012-3524
Package: dbus Severity: serious Justification: local privilege escalation Tags: security Hi, CVE-2012-3524 is about setuid binaries linking libdbus being easily trickable to do bad things via a malicious PATH (for finding dbus-launch), or through a DBUS_* address variable using the unixexec address type. Initially the D-Bus developers thought that this should be fixed on the application side (hence the comment in the security-tracker), but decided that it would be better to have a defense-in-depth approach, and change _dbus_getenv to not succeed if the current program is setuid or similar, since that's faster than patching every relevant program. There's a patch in the D-Bus 1.6.6 release that implements this. Many other distros, including RHEL/Fedora, SUSE, and Ubuntu have taken this patch already. There are some other hardening things in the 1.6.6 release that broke gnome-keyring, prompting a 1.6.8 release a few hours later to revert those; you should either take 1.6.8, or just backport the four patches that weren't reverted in 1.6.8: http://cgit.freedesktop.org/dbus/dbus/commit/?id=23fe78ceefb6cefcd58a49c77d1154b68478c8d2 http://cgit.freedesktop.org/dbus/dbus/commit/?id=4b351918b9f70eaedbdb3ab39208bc1f131efae0 http://cgit.freedesktop.org/dbus/dbus/commit/?id=57ae3670508bbf4ec57049de47c9cae727a64802 http://cgit.freedesktop.org/dbus/dbus/commit/?id=f68dbdc3e6f895012ce33939fb524accf31bcca5 I think these are all easily backportable, but I'm happy to supply a debdiff if that'd make it easier for you. More discussion of the issue can be found at https://bugs.freedesktop.org/show_bug.cgi?id=52202 https://bugzilla.novell.com/show_bug.cgi?id=697105 https://bugzilla.redhat.com/show_bug.cgi?id=847402 http://seclists.org/oss-sec/2012/q3/29 -- Geoffrey Thomas gtho...@mokafive.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#687582: alpine: deadlock in signal handler
Package: alpine Version: 2.02-3 Noting this here, although it's an upstream bug and I'll submit it upstream soon. After disconnecting my machine from the network and leaving alpine open, it hung with the prompt Waited 919 seconds for server reply. Break connection to server? and the message [MAIL FOLDER INBOX CLOSED DUE TO ACCESS ERROR]. gdb gives the following backtrace: (gdb) bt #0 __lll_lock_wait_private () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:97 #1 0x7f196507c30f in _L_lock_12013 () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x7f196507a3d8 in __libc_free (mem=0x7f196538d1c0) at malloc.c:3736 #3 0x7f196509c67d in tzset_internal (always=value optimized out, explicit=value optimized out) at tzset.c:435 #4 0x7f196509c9eb in __tz_convert (timer=0x7fffa8af59b8, use_localtime=1, tp=0x7f1965390f00) at tzset.c:624 #5 0x7f196509aad9 in ctime (t=value optimized out) at ctime.c:32 #6 0x005ca3cc in debug_time (include_date=value optimized out, include_subseconds=value optimized out) at debugtime.c:63 #7 0x0054fda3 in add_review_message (message=value optimized out, level=5) at help.c:362 #8 0x005d0612 in output_debug_msg (dlevel=5, fmt=0x66921c end_signals(%d)\n) at debuging.c:323 #9 0x004ca2fb in end_signals (blockem=1) at signal.c:145 #10 0x004ca491 in auger_in_signal (sig=11) at signal.c:184 #11 signal handler called #12 0x7f196507565d in malloc_consolidate (av=0x7f196538d1c0) at malloc.c:5169 #13 0x7f1965076f72 in _int_malloc (av=0x7f196538d1c0, bytes=1296) at malloc.c:4373 #14 0x7f1965079e1e in __libc_malloc (bytes=1296) at malloc.c:3660 #15 0x005d9528 in fs_get (size=value optimized out) at fs_unix.c:38 #16 0x00482bcf in update_index (state=0x1483040, screen=0x7fffa8af6340) at mailindx.c:1220 #17 0x004834d1 in index_lister (state=0x1483040, cntxt=0x14c7480, folder=0x1483129 INBOX, stream=0x14ff860, msgmap=0x1521420) at mailindx.c:452 #18 0x0042c095 in main (argc=1, argv=0x7fffa8af8e78) at alpine.c:1331 According to signal(7), ctime is not safe to be called from a signal handler (nor, more generally, are malloc or free). Probably debug messages from signal handler context should not attempt to display the time, or should use some built-in time implementation that doesn't malloc or care about timezones, or something. -- Geoffrey Thomas http://ldpreload.com geo...@ldpreload.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649274: Forming a new upstream for timidity (and reporting various issues with current deb pkg)
, and am currently reading up on the Soundfont spec so I can make sense of the bug / your patch. :-) I haven't yet looked at the remainder of your patches, but will do so now. That rounds up the wrong (or so I believe) fixes in the Debian pkg. As said I hope to do a new upstream release soon, amongst a lot of bugfixes this will also include IPV6 support for the relevant bits of timidity. Thanks, and thanks for identifying these issues. I see there's been a bit of activity a week or two ago in upstream (and upstream looks to have most the patches originally submitted with this bug report), so I'll see if I can just make a new orig tarball based on upstream git and drop our patches entirely. -- Geoffrey Thomas http://ldpreload.com geo...@ldpreload.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#414264: alpine: 'Folder vulnerable' warning about /var/spool/mail
I failed to notice this bug before filing http://pad.lv/992145 (since I wasn't sure the bug existed in Debian). I've linked that bug to this one. -- Geoffrey Thomas http://ldpreload.com geo...@ldpreload.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631758: (no subject)
tags 631758 + patch thanks The patch at https://github.com/geofft/alpine/commit/01674610679e4af4a6c6d890659573133609cec5.patch rips out all the phone_home code, since there's no current party that's interested in usage counts. I think I've failed to forward it to upstream correctly, though (I sent it as a git format-patch instead of attaching it to the SourceForge patch tracker). Asheesh, please poke me if I haven't fixed that by tomorrow. -- Geoffrey Thomas http://ldpreload.com geo...@ldpreload.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672711: sbuild: --append-to-version should set source:Version substvar
Package: sbuild
Version: 0.62.6-1
Hi Roger,
As you saw on #debian-devel about a week ago, Paul Wise noticed (as a
result of running the debian-derivatives analysis scripts on Debathena,
which uses --append-to-version for all builds) that builds with
--append-to-version do not correctly report the original/source package
version number in the Source: field of the binary control file and binary
.changes file. Namely, the field is expected to contain something of the
form package (1.0), not just package, if the resulting binary package
is not version 1.0. This works fine for sbuild's --binNMU option -- the
binary package will be version e.g. 1.0+b1, but contain a Source: field of
package (1.0).
On tracking this down a little further (and noticing that
--append-to-version=+b2 did not exhibit this bug), I found that when
dpkg-source generates substvars (in Dpkg::Substvar), it uses the following
logic:
sub set_version_substvars {
my ($self, $version) = @_;
$self-{'vars'}{'binary:Version'} = $version;
$self-{'vars'}{'source:Version'} = $version;
$self-{'vars'}{'source:Version'} =~ s/\+b[0-9]+$//;
[...]
}
So the source:Version field is only correct when the binary version
happens to end with a +bNNN (or when it is the same as the source version,
of course). So sbuild did not need to specifically do anything about
source:Version when --binNMU was the only option that changed the binary
version from the source version, but this assumption is no longer true
with --append-to-version.
I'm not sure what the right way to fix this is. Possibly sbuild itself
should edit debian/substvars to change the source:Version field. I can't
get --dpkg-source-opt=-Vsource:Version=1.0 to work, although maybe
dpkg-source getting run before Hack binNMU version is relevant. Possibly
dpkg-source gaining an option to be explicitly told the source package
version is the most-right answer here, but would require changes in both
sbuild and dpkg-dev.
--
Geoffrey Thomas
geo...@mit.edu
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671085: vim: Please add Vala syntax highlighting
Package: vim Version: 2:7.3.429-2 Priority: wishlist Hi maintainer, Could you please add support for Vala (*.vala, *.vapi) syntax highlighting to the vim package? There's a syntax script and instructions on how to add it to your .vimrc here: http://live.gnome.org/Vala/Vim There are also comments in vala.vim itself about wanting to add some things to the global vimrc. The instructions also add parsing of valac errors, but I personally care less about those. I suspect they're waiting for a 1.0 release of Vala before adding it upstream (as implied by the vala.vim comments), but given that there's an increasing amount of code in Vala, it would be good to have some form of syntax highlighting now. If you'd like me to, I'm happy to give you a debdiff or something to implement this. Thanks, -- Geoffrey Thomas gtho...@mokafive.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670855: cyrus-sasl2-*-dbg doesn't correspond to cyrus-sasl2-*
Source: cyrus-sasl2
Version: 2.1.25.dfsg1-4
Priority: wishlist
Hi,
It looks like cyrus-sasl2-{mit,heimdal}-dbg are the debug symbols for
libsasl2-modules-gssapi-{mit,heimdal}, not cyrus-sasl2-{mit,heimdal} as
their name would imply (in fact those packages got removed a while ago).
This confuses me. Is there a reason not to rename them to
libsasl2-modules-gssapi-{mit,heimdal}-dbg?
Thanks,
--
Geoffrey Thomas
geo...@mit.edu
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#663327: timidity: timidity does not update system wide mailcup database to play .midi files...
On Sat, 10 Mar 2012, Oleksandr Gavenko wrote: To fix this issue maintainer must create: $ cat /usr/lib/mime/packages/timidity audio/midi; timidity %s; description=MIDI file and use update-mime(8) utility in postinstall script as say man page... Thanks. I'll test this out on my system and roll it into the next version of the package if it works. I should probably get a chance to work on a release either this weekend or the next. -- Geoffrey Thomas http://ldpreload.com geo...@ldpreload.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#663580: timidity: shouldn't daemonize when the parent process terminates
On Mon, 12 Mar 2012, Gilles Filippini wrote:
Hi,
Timidity has some known problems working with pulseaudio [0], and one of
the recommanded workarounds [1] is to launch it from the user session
instead of running it as a system service. The problem is that - even if
timidity wasn't launched as a daemon - it doesn't termminate itself at
the end of the user session. Instead it daemonizes itself and stands
running. This simply shouldn't happen when launched without the 'D'
flag.
thanks,
_g.
[0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=563252
[1] https://bugs.launchpad.net/ubuntu/+source/timidity/+bug/210472/comments/16
Interesting, and thank you for pointing me to that Ubuntu bug.
There's some suspicious behavior regarding SIGHUP in the ALSA module,
which runs independent of the -D flag:
/* reset all when SIGHUP is received */
static RETSIGTYPE sig_reset(int sig)
{
if (alsactx.active) {
stop_sequencer(alsactx);
server_reset();
}
signal(SIGHUP, sig_reset);
}
and later
signal(SIGHUP, sig_reset);
I'm not sure what the intention is there, but it sounds plausible this
should be daemon-only behavior. I'll try to take a closer look at it soon.
There's also a protocol of some sort to detect when a user session is
exiting (I believe using X or D-Bus); we should probably implement that if
X or D-Bus is available, which would make the use case you describe
smoother.
--
Geoffrey Thomas
http://ldpreload.com
geo...@ldpreload.com
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#661565: ITP: nyancat -- Terminal-based Pop Tart Cat animation
I certainly don't plan on uploading and abandoning this package, but given the high level of opposition to this ITP, guess there is little point pursuing it. Jon I'm not a DD, so I don't know how much my opinion counts, but I would have liked to see this in the archive. At the very least, I use sl as a standard demo package when I run packaging tutorials and such; nyancat would have been a somewhat easier-to-explain example. It'd be good to have this conveniently available when my school's student computing group runs an advertisement booth with a VT-100 attached to a modern computer running Debian. It would also be fun to integrate as a console-mode screensaver along the lines of cmatrix, which you mentioned. If you end up deciding you really don't want to upload this, please leave this open as an RFP. Thanks, -- Geoffrey Thomas http://ldpreload.com geo...@ldpreload.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#655735: lvm2: Please backport Remove udev dependency to stable
Package: lvm2 Version: 2.02.66-5 Hi, We have a local package that build-depends on lvm2. Since the build chroot does not have udev installed, we're running into the issue noted in bug #543163 that the package does not depend on udev but the initscript does. This causes the udev postinst to fail, and installation of bulild deps to fail. This has been fixed in 2.02.84-3, but that isn't present in stable. We're working around this by manually depending on udev, so it isn't super high priority, but it would be appreciated if you could backport that fix to squeeze. Thanks, -- Geoffrey Thomas geo...@mit.edu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#655193: libkrb53: transitional package bumped from extra to standard
Package: libkrb53 Version: 1.8.3+dfsg-4squeeze5 Severity: minor Hi Sam, I was searching for Priority: Standard packages that weren't installed on my machine, and noticed that libkrb53 1.8.3+dfsg-4squeeze2 is priority extra and 1.8.3+dfsg-4squeeze5 is priority standard. Presumably this was a typo or something in a recent upload, since the 4squeeze5 version is still a transitional package labeled may be removed if unneeded. Feel free to close this bug if you don't think it's worth worrying about. -- Geoffrey Thomas geo...@mit.edu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
