Upload every package every release cycle
Should we require each source package in Debian to be uploaded at least once per release cycle? Lintian[0] reports that there are currently over 7000 packages with an ancient Standards-Version. That's a lot of packages. Some of those haven't been uploaded in years. That means that the packages haven't had attention by their maintainer (or an NMUer) in years. Sometimes that's OK: there's nothing that needs changing in the package, and upstream is dormant. However, it seems to me that without inspecting each package manually, we can't know if fixes are needed. It would seems to me that having an automated way of verifying that a package gets at least minimal attention would be good for Debian. I propose we implement that by requiring that each package gets uploaded at least once per release cycle, and that the upload updates the package to match current policy, indicated by updating the Standards-Version field to one that is not ancient. In more detail, I propose the following: * When the release freeze begins, every package in testing must have a Standards-Version that is less than 24 months old (the threshold for the ancient-standards-version warning in lintian), and will be removed from testing. * Six months before the freeze, RC bugs get filed for any packages that have the ancient-standards-version lintian warning. This would leave ample time to fix the problem for any one package. [0]: https://lintian.debian.org/tags/ancient-standards-version.html -- I want to build worthwhile things that might last. --joeyh signature.asc Description: PGP signature
Bug#854227: unblock: python-cliapp/1.20160724-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package python-cliapp 1.20160724-1 fails to build from source because after it was originally uploaded, pylint was upgraded, and now has new checks, which fail the build. In 1.20160724-2 I have disabled build-time tests. I decided to disable the tests rather than fixing the thing that pylint now complains about, because I think it's a smaller, safer change than making code changes at this stage of the release cycle. Source debdiff: diff -Nru python-cliapp-1.20160724/debian/changelog python-cliapp-1.20160724/debian/changelog --- python-cliapp-1.20160724/debian/changelog 2016-07-24 20:54:18.0 +0200 +++ python-cliapp-1.20160724/debian/changelog 2017-02-05 09:19:14.0 +0100 @@ -1,3 +1,17 @@ +python-cliapp (1.20160724-2) unstable; urgency=medium + + * Fix "FTBFS: Test failures" by disabling build-time checks +(Closes: #852882) + - when -1 was uploaded, the tests passed, but pylint is +now a newer version with new checks + - Debian is in a freeze, this is the minimal change to work +around the bug; the tests have passed in previuos uploads, +with an older pylint, so disabling them should be sufficiently +safe and less risky than hacking up code at the last second of +a release cycle + + -- Lars Wirzenius <l...@liw.fi> Sun, 05 Feb 2017 09:19:14 +0100 + python-cliapp (1.20160724-1) unstable; urgency=medium * Change debian/rules to run automated tests during build. diff -Nru python-cliapp-1.20160724/debian/rules python-cliapp-1.20160724/debian/rules --- python-cliapp-1.20160724/debian/rules 2016-07-24 20:41:27.0 +0200 +++ python-cliapp-1.20160724/debian/rules 2017-02-05 09:19:14.0 +0100 @@ -7,12 +7,6 @@ $(MAKE) dh_auto_build --with=python2 --buildsystem=python_distutils -override_dh_auto_test: - $(MAKE) clean check - # RE-build - $(MAKE) - dh_auto_build --with=python2 --buildsystem=python_distutils - override_dh_auto_clean: $(MAKE) clean dh_auto_clean --with=python2 --buildsystem=python_distutils [PREVIOUS COMMAND EXIT: 1] ~/.../cliapp $ unblock python-cliapp/1.20160724-2 -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#770142: RM: seivot/1.17-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm I filed #770140 to remove seivot from unstable. Here's the justification: I'm the maintainer of seivot, and also its upstream. It has bit-rotted badly enough that it isn't useful anymore, and I don't develop it or use it upstream either. It should thus be removed from Debian: the source package and all binary packages from unstable. Please remove seivot from testing/jessie. As far as I can see, it has no reverse dependencies of any type, so it should be easy to remove. -- System Information: Debian Release: 7.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16-0.bpo.3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141119060726.14243.54638.reportbug@exolobe1
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Sun, Mar 31, 2013 at 12:33:46PM -0500, Dirk Eddelbuettel wrote: On 31 March 2013 at 18:18, Adam D. Barratt wrote: | Aside from the lack of pre-discussion, co-ordination etc., the last few | weeks of a freeze _really_ isn't the right time to be starting a large | (or indeed small) transition in unstable. We now have at least 87 (based | on this morning's britney run) packages which won't be able to receive | updates via unstable should they turn out to have lately discovered RC | bugs. If any of those packages are then involved in dependency chains, | the same could be true of packages outside of the R module packages. In the grand scheme of things, R is a rather peripheral package. A peripheral package can still cause extra work for the release team. Please just put a block on r-base-core to prevent it from migrating to testing. All these dependencies will be held too. The freeze already guarantees the these new R packages won't be entering wheezy. That is not the problem. The problem is that since you uploaded, to unstable, packages that cannot enter wheezy, any bug fixes _in_wheezy_ now have to go via testing-proposed-uploads, which is more work for everyone, including the release team. Because of the complicated dependencies between packages in Debian, this then cause _other_ packages to suffer the same fate. This is not a new thing, and it has been said repeatedly by the release team on debian-devel-announce. I cannot influence the R release cycle which happens within our freeze. As have a few previous R releases, and none of those created any trouble. You can, however, avoid uploading the new R packages to Debian unstable during a Debian release freeze, and you should have done so. You could have uploaded them to experimental instead. This would have avoided all the potential problems for the Debian release process. -- http://www.cafepress.com/trunktees -- geeky funny T-shirts http://gtdfh.branchable.com/ -- GTD for hackers -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130331175510.gh4...@havelock.liw.fi
Bug#689795: unblock: python-larch/1.20121006-1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
I humbly request that the release team allow the recently uploaded
python-larch package version 1.20121006-1 into wheezy before the
release. It fixes two bugs, one of which was reported to Debian:
* #675818: UnboundLocalError: local variable 'new_node' referenced
before assignment
- this bug is of normal severity, but could arguably be important
- what happens is that when the fsck feature of Obnam (my backup
program) is used in fix problems and do not just report them
mode, the program crashes because of an unknown local variable
name
- the problem is that I had inadvertently indented a line wrongly:
the line logs the value of a variable, but is not indented to be
inside the block in which the variable exists
- the fix is a one-line change to indent the problematic line to
the correct level
* the unreported problem is that the package is using the cmdtest tool
during build time to run tests, but is lacking this in the build
dependencies
- I apologise profusely for not reporting a bug for this myself
I am also upstream of python-larch, and have chosen to make a new
upstream release to include these fixes. I hope that is not a problem
for the release team.
An additional change, apart from a new entry in the NEWS file, is
that I fixed the spelling of the name of the person who developed the
B-tree variant the python-larch package implements.
The debdiff is below.
I hope the release team is in good health, and that this request of
mine leaves you in good spirits.
diff -Nru python-larch-1.20120527/debian/changelog
python-larch-1.20121006/debian/changelog
--- python-larch-1.20120527/debian/changelog2012-10-06 11:59:01.0
+0100
+++ python-larch-1.20121006/debian/changelog2012-10-06 11:59:01.0
+0100
@@ -1,3 +1,12 @@
+python-larch (1.20121006-1) unstable; urgency=low
+
+ * New upstream release.
+- Fix UnboundLocalError: local variable 'new_node' referenced before
+ assignment (Closes: #675818)
+ * debian/control: Add missing build-dependency on cmdtest.
+
+ -- Lars Wirzenius l...@liw.fi Sat, 06 Oct 2012 10:27:20 +0100
+
python-larch (1.20120527-1) unstable; urgency=low
* New upstream release.
diff -Nru python-larch-1.20120527/debian/control
python-larch-1.20121006/debian/control
--- python-larch-1.20120527/debian/control 2012-10-06 11:59:01.0
+0100
+++ python-larch-1.20121006/debian/control 2012-10-06 11:59:01.0
+0100
@@ -5,7 +5,7 @@
Standards-Version: 3.9.3
Build-Depends: debhelper (= 7.3.8), python (= 2.6.6-3~),
python-coverage-test-runner, python-tracing, python-sphinx,
-python-cliapp (= 0.14), python-ttystatus
+python-cliapp (= 0.14), python-ttystatus, cmdtest
X-Python-Version: = 2.6
Package: python-larch
diff -Nru python-larch-1.20120527/larch/fsck.py
python-larch-1.20121006/larch/fsck.py
--- python-larch-1.20120527/larch/fsck.py 2012-05-27 10:44:29.0
+0100
+++ python-larch-1.20121006/larch/fsck.py 2012-10-06 10:30:43.0
+0100
@@ -104,7 +104,7 @@
new_node = larch.IndexNode(node.id, keys,
[node[k] for k in keys])
self.fsck.forest.node_store.put_node(new_node)
-tracing.trace('fixed it: %s' % new_node.keys())
+tracing.trace('fixed it: %s' % new_node.keys())
class CheckRoot(WorkItem):
diff -Nru python-larch-1.20120527/larch/__init__.py
python-larch-1.20121006/larch/__init__.py
--- python-larch-1.20120527/larch/__init__.py 2012-05-27 10:44:29.0
+0100
+++ python-larch-1.20121006/larch/__init__.py 2012-10-06 10:30:43.0
+0100
@@ -14,7 +14,7 @@
# along with this program. If not, see http://www.gnu.org/licenses/.
-__version__ = '1.20120527'
+__version__ = '1.20121006'
class Error(Exception):
diff -Nru python-larch-1.20120527/NEWS python-larch-1.20121006/NEWS
--- python-larch-1.20120527/NEWS2012-05-27 10:44:29.0 +0100
+++ python-larch-1.20121006/NEWS2012-10-06 10:30:43.0 +0100
@@ -2,7 +2,16 @@
==
These are the release notes for larch, a Python implementation of a
-copy-on-write B-tree, designed by Odah Rodeh.
+copy-on-write B-tree, designed by Ohad Rodeh.
+
+Version 1.20121006
+--
+
+* Critical bug fix: an indentation problem in the Python code was fixed.
+ A line was intended wrong, resulting it to not be included in the right
+ block, and therefore not having access to the variable created in that
+ block.
+* Bug fix: The Debian packaging was missing a build dependency on cmdtest.
Version 1.20120527, released 2012-05-27
---
unblock python-larch/1.20121006-1
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (500
Bug#688793: unblock: obnam/1.1-1.1
Hi, thanks for the NMU. I'm still working on getting my CI system to work well enough that it builds packages. I need this so that when I make an upstream release, I can build packages for all the Debian release I support -- I don't want to build just for Debian unstable and then let people running squeeze just hope someone will make a backport. Getting all the infrastructure working to do this reliably is a bit of work that has obviously taken me too long. Do you have a personal interest in Obnam? Would you like to be a co-maintainer of the package in Debian? -- I wrote a book on personal productivity: http://gtdfh.branchable.com/ signature.asc Description: Digital signature
enemies-of-carlotta security problem: please allow fix into etch
I've just uploaded version 1.2.4-1 of enemies-of-carlotta to unstable. It contains a fix for CVE-2006-5875 (and only that fix), a security problem involving badly quoted shell arguments. Please allow the new version to enter etch as soon as possible. I have attached the debdiff from the previous version (1.2.3-1), currently in etch. If there's anything I forgot to do to make this easier, please tell me. diff -Nru /tmp/m0YNIVzyAI/enemies-of-carlotta-1.2.3/debian/changelog /tmp/WJGmpSGD2g/enemies-of-carlotta-1.2.4/debian/changelog --- /tmp/m0YNIVzyAI/enemies-of-carlotta-1.2.3/debian/changelog 2006-12-13 15:51:48.0 +0200 +++ /tmp/WJGmpSGD2g/enemies-of-carlotta-1.2.4/debian/changelog 2006-12-13 15:51:48.0 +0200 @@ -1,3 +1,13 @@ +enemies-of-carlotta (1.2.4-1) unstable; urgency=high + + * Security fix for CVE-2006-5875. There is no bug report for this, the +problem was reported privately to me by Antti-Juhani Kaijanaho. + * EoC did not correctly deal with SMTP level e-mail addresses that contain +shell meta characters. This has been fixed by running /usr/sbin/sendmail +via fork and exec, instead of os.popen. + + -- Lars Wirzenius [EMAIL PROTECTED] Sun, 9 Dec 2006 15:49:22 +0200 + enemies-of-carlotta (1.2.3-1) unstable; urgency=low * New upstream version: diff -Nru /tmp/m0YNIVzyAI/enemies-of-carlotta-1.2.3/eoc.py /tmp/WJGmpSGD2g/enemies-of-carlotta-1.2.4/eoc.py --- /tmp/m0YNIVzyAI/enemies-of-carlotta-1.2.3/eoc.py 2006-11-10 19:34:52.0 +0200 +++ /tmp/WJGmpSGD2g/enemies-of-carlotta-1.2.4/eoc.py 2006-12-13 15:30:02.0 +0200 @@ -4,7 +4,7 @@ address commands. See manual page for more information. -VERSION = 1.2.3 +VERSION = 1.2.4 PLUGIN_INTERFACE_VERSION = 1 import getopt @@ -80,6 +80,34 @@ def md5sum_as_hex(s): return md5.new(s).hexdigest() + +def forkexec(argv, text): +Run a command (given as argv array) and write text to its stdin +(r, w) = os.pipe() +pid = os.fork() +if pid == -1: +raise Exception(fork failed) +elif pid == 0: +os.dup2(r, 0) +os.close(r) +os.close(w) +fd = os.open(/dev/null, os.O_RDWR) +os.dup2(fd, 1) +os.dup2(fd, 2) +os.execvp(argv[0], argv) +sys.exit(1) +else: +os.close(r) +os.write(w, text) +os.close(w) +(pid2, exit) = os.waitpid(pid, 0) +if pid != pid2: +raise Exception(os.waitpid for %d returned for %d % (pid, pid2)) +if exit != 0: +raise Exception(subprocess failed, exit=0x%x % exit) +return exit + + environ = None def set_environ(new_environ): @@ -411,14 +439,8 @@ error(Error sending QMQP mail, mail probably not sent) sys.exit(1) else: -recipients = string.join(recipients, ) -f = os.popen(%s -oi -f '%s' %s % - (self.sendmail, - envelope_sender, - recipients), - w) -f.write(text) -status = f.close() +status = forkexec([self.sendmail, -oi, -f, + envelope_sender] + recipients, text) if status: error(%s returned %s, mail sending probably failed % (self.sendmail, status)) diff -Nru /tmp/m0YNIVzyAI/enemies-of-carlotta-1.2.3/NEWS /tmp/WJGmpSGD2g/enemies-of-carlotta-1.2.4/NEWS --- /tmp/m0YNIVzyAI/enemies-of-carlotta-1.2.3/NEWS 2006-11-10 19:34:52.0 +0200 +++ /tmp/WJGmpSGD2g/enemies-of-carlotta-1.2.4/NEWS 2006-12-13 15:30:02.0 +0200 @@ -1,5 +1,11 @@ NEWS file for Enemies of Carlotta, a mailing list manager +Significant user-visible changes from version 1.2.3 to version 1.2.4: + +* A fix to CVE-2006-5875, a security problem where EoC did not quote + shell command line arguments properly. Thanks to Antti-Juhani + Kaijanaho for finding the problem. + Significant user-visible changes from version 1.2.2 to version 1.2.3: * When there is a problem with MIME header encodings, don't kill EoC, signature.asc Description: This is a digitally signed message part
invoke-rc.d mass bug filing: binNMU candidates
(I'm not subscribed to -release, please Cc me on replies, thanks.) In May, I did a mass bug filing for the policy change related to invoke-rc.d [1]. Of the bugs that still remain open, four could be fixed by a simple rebuild, without any changes to the source, because they were built by an old version (a very old version) of debhelper. The packages and bugs in question are: * oss-preserve #367726 * diald #367735 * battery-stats #367745 * apcd #367749 If I have understood correctly, the release managers can trigger binNMUs for these. Would it be appropriate to do this even if the bugs are not release critical? (The other bugs need source changes to work.) [1] http://lists.debian.org/debian-devel/2006/05/msg01746.html -- You need fewer comments, if you choose your names carefully. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
init.d script dependencies for etch?
The traditional way of ordering init.d scripts is to have two-digit numbers for the symlinks in /etc/rc*d directories. It seems pretty clear to me that a dependency based scheme would work better here. Switching from one to the other could, I think, be done gradually, given sufficient magic and hair, but it is a big change that is going to touch a great many packages. I would like to work on making this happen for etch. I don't have an implementation yet, let alone a plan for how to do it, and I won't start work until after sarge is released, so this is just a heads-up for the release team. Anyone who wants to tell me this is a really bad idea, or has suggestions on the implementation, please mail me in private or take this thread to -devel. Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
