I just found my way to this bug nearly 10 years later whilst wanting to
report the same issue still persists.
PAM upstream changed the default of user_readenv from 1 to 0 in
https://github.com/linux-pam/linux-pam/commit/f83fb5f25263356391d71da595def409e8dd90f7
and subsequently added explicit
I found this bug when in the same circumstance of /etc/environment proxy
settings not applying to sudo sessions.
I understand the rationale for "wontfix"-ing the previously suggested fix
of changing /etc/sudoers.
However, Ubuntu have been carrying a patch for the past 12 years which
addresses
Package: src:python-pip
Version: 9.0.1-2
Currently, there is a Debian-specific patch "set_user_default.patch"
which changes various behaviour if the invoker is not root.
Whilst I understand the sense in defaulting to --user in this case, I
would like to request that you not force
On 17/06/14 23:40, Javi Merino wrote:
Control: tags -1 - pending + wontfix
On Sat, Jun 07, 2014 at 09:35:43PM +0100, Max Bowsher wrote:
The problem here is that some manual sed hackery munging the /usr/bin/hg
shebang was removed in PAPT SVN r10748, with the justification that
dh_python2
hooks to call only the upstream Makefile targets which
handle non-distutils parts of the build.
Patch attached.
Regards,
Max Bowsher.
diff -ru mercurial-3.0/debian/rules mercurial-3.0.fixed/debian/rules
--- mercurial-3.0/debian/rules 2014-04-07 22:58:25.0 +0100
+++ mercurial-3.0.fixed
Package: rtmpdump
Version: 2.4+20121230.gitdf6c518-1
Severity: normal
The contents of rtmpdump_2.4+20121230.gitdf6c518.orig.tar.gz is
significantly different from actual upstream commit df6c518.
It looks to me as if assorted upstream changes have been reverted or
were never merged, in a rather
On 07/04/14 02:51, Max Bowsher wrote:
Package: rtmpdump
Version: 2.4+20121230.gitdf6c518-1
Severity: normal
The contents of rtmpdump_2.4+20121230.gitdf6c518.orig.tar.gz is
significantly different from actual upstream commit df6c518.
It looks to me as if assorted upstream changes have
Package: passwd
Version: 1:4.1.4.2+svn3283-2+squeeze1
Severity: normal
The 'useradd -r' command (-r meaning 'system user') allocates UID values
top-down within the range reserved in login.defs. In contrast, adduser
allocates UID values bottom-up.
Whilst most user creation on a Debian system
Package: subversion
Version: 1.7.5-1
Severity: normal
I'll start by admitting that I've only actually reproduced this in
backport PPA builds for Ubuntu hardy, *but* on analysis I can't see why
this shouldn't happen in Debian sid too, so I'll report it
nonetheless...
If the package is built with
My use case is using tsocks to allow tunnelling into restricted
corporate IP space, whilst the vast majority of my IP connectivity is
direct.
Please consider accommodating this use case by allowing for fallback to
direct connections without unwanted notifications that this is happening.
Max.
The feature requested in this bug would be useful to me to enable nicer
support of old releases which have moved to archive.debian.org. For
example, I currently have approx instances which need to supply etch
lenny and squeeze.
I have resorted to configuring them like this:
debian
This FTBFS is the result of the python-subunit package not being
properly built for all current Python versions.
signature.asc
Description: OpenPGP digital signature
Package: apt
Version: 0.8.13.1
Severity: normal
I have explicitly set:
Acquire::Languages:: none;
However APT still attempts to download TranslationIndex files.
Looking at the code in debReleaseIndex::ComputeIndexTargets(), there
does not seem to be any way to turn this off.
Suppressing
is a plugin for the Bazaar Version Control System which
provides a variety of GUI dialogs for many version control operations.
As such, it is most accurately described as a 'vcs' tool rather than a
general 'devel'opment tool.
Thanks,
Max Bowsher.
--
To UNSUBSCRIBE, email to debian-bugs-dist
: wikkid is a wiki, which happens to store its data in the
Bazaar VCS for history management. Although it does make use of a vcs,
its primary defining characteristic is that it is software for running a
wiki, i.e. section 'web'.
Thanks,
Max Bowsher.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ
Package: debmirror
Version: 1:2.8
Hi,
The fix for #619146 Should not attempt to mirror debian-installer for
squeeze-updates has accidentally widened the regexp of dists that omit
a debian-installer section a little too far.
Whilst squeeze-updates and successors do not have a debian-installer
Package: debmirror
Version: 1:2.8
Tags: patch
Hi,
I am trying to use --ignore-missing-release to support the use-case of
mirroring lenny/updates and squeeze/updates from security.debian.org
into a mirror which still contains the final state of etch/updates
(which I want to keep).
It works, but
I would like to use a --trash feature too, and --snapshot would not
really serve my purposes.
My reason for wanting --trash is as a low-maintenance safety-net - I
don't have a need to preserve histories of the index file, I just need
to not delete many gigabytes if something goes awry.
I need
Package: debmirror
Version: 1:2.8
Severity: wishlist
Hi,
I'd like to get some initial feedback on a feature idea before I have a
go at implementing it.
The --ignore-missing-release option is useful, but even better would be
an option that took a list of dists, like --dist does, and instead of
Package: python-fastimport
Version: 0.9.0~bzr293-1
Severity: wishlist
Please drop the version constraint on the python-support Build-Depends.
In fact the source package builds just fine, producing working binary
packages, with python-support versions as old as Debian oldstable and
Ubuntu hardy.
Source: subvertpy
Version: 0.7.4-2
Severity: wishlist
Hi,
I have validated that the current subvertpy source package builds and
functions correctly even as far back as etch, if the version constraint
is removed from the python-support build-depenency.
Therefore, please remove the version
Package: subversion
Version: 1.6.12dfsg-1
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu maverick ubuntu-patch
*** /tmp/tmpIEOYZv
In Ubuntu, we've applied the attached patch amending the
XS-Python-Version line to = 2.4 rather than a list of explicit
I independently filed this bug upstream and then found this report when
about to report it in Debian.
Upstream bug: http://savannah.gnu.org/bugs/index.php?29253
I used bcopy rather than memmove in the patch I submitted to upstream
because that fitted with prevailing conventions in the function I
Package: ghc6
Version: 6.12.1-12
Severity: normal
I installed ghc6, and the next day was confronted with an error from the
daily debsums standard cronjob.
It appears that ghc6 ships the file
/var/lib/ghc-6.12.1/package.conf.d/package.cache in the .deb, but then
proceeds to modify it as part of
Package: python-dispatch
Version: 0.5a.svn20080510-4+b1
Severity: normal
Package is not compatible with Python 2.6, and causes errors to be
emitted when it is installed:
Compiling /usr/lib/python2.6/dist-packages/dispatch/predicates.py ...
SyntaxError: ('invalid syntax',
Package: reprepro
Version: 4.0.2-1
Severity: minor
I use reprepro on a non-Debian system.
The build fails because database.c uses the type uint32_t but fails to
include stdint.h. Whilst the current toolchain on Debian seems to
tolerate this omission, it would be more correct and portable to
forcemerge 363358 363389
thanks
Gosh, I can't even remember reporting this bug, but I certainly agree
that it appears to be an exact duplicate of 363358. Merging thusly.
Max.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
Faheem,
Look closer at the file list. The *exact same* set of files is present
for Python 2.4 and 2.5 - i.e. the package is compiled providing the
Mercurial modules for both of those Python versions - no bug here.
Max.
signature.asc
Description: OpenPGP digital signature
Package: reprepro
Version: 3.11.1-1
Severity: normal
I would expect, and the language of the manpage implies, that morguedir
would be relative to basedir, as all of reprepro's other directories
are. In 3.11.1 is is however relative to the cwd.
--
To UNSUBSCRIBE, email to
Package: reprepro
Version: 3.11.1-1
Severity: minor
The --keepunreferencedfiles option is most useful in the conf/options
file to set policy for a repository to not remove files at time of
obsoletion.
However, if you put it in conf/options, you then cannot use reprepro
deleteunreferenced at all,
Bernhard R. Link wrote:
* Max Bowsher m...@f2s.com [090801 17:32]:
The --keepunreferencedfiles option is most useful in the conf/options
file to set policy for a repository to not remove files at time of
obsoletion.
However, if you put it in conf/options, you then cannot use reprepro
Damien Raude-Morvan wrote:
Le lundi 27 juillet 2009 23:59:25, Max Bowsher a écrit :
Hi,
Hi Max,
Thanks for your bug report.
As your package does not build GCJ native code, please amend your
Build-Depends from default-jdk-builddep to default-jdk.
This will allow GCJ to not be pulled
Package: libjaudiotagger-java
Version: 1.0.9-2
Severity: wishlist
Hi,
As your package does not build GCJ native code, please amend your
Build-Depends from default-jdk-builddep to default-jdk.
This will allow GCJ to not be pulled in at build-time on architectures
or distros where GCJ is not the
Jakub Wilk wrote:
Package: mercurial-common
Version: 1.3-2
Severity: normal
$ zgrep -B1 'alias -' /usr/share/doc/mercurial-common/changelog.Debian.gz
New extensions:
* alias - allow user-defined command aliases
$ python -c 'import hgext.alias'
Traceback (most recent call
Package: libjaudiotagger-java
Version: 1.0.9-1
Severity: normal
Tags: patch
The class org.jaudiotagger.tag.reference.ISOCountry$Country contains
several enum values whose name contains non-ASCII characters. In the
current .deb in the archive, these have been miscompiled - for example:
FTBFS is due to incompatible changes in cdbs
Attached is a patch I am successfully using to build PPA packages in
Ubuntu Karmic.
Max.
--- a/debian/rules Fri Apr 17 00:33:15 2009 +0100
+++ b/debian/rules Mon May 11 00:15:27 2009 +0100
@@ -66,3 +66,13 @@
@echo Restore it from
Please note that the new upstream releases fixes #525403, not currently
noted in the unreleased changelog entry.
Also, whilst you're there, there's currently a typo in the unreleased
changelog entry: s/Dump/Bump/ .
signature.asc
Description: OpenPGP digital signature
http://bugs.debian.org/522426 - wishlist new upstream version
http://bugs.debian.org/527504 - FTBFS that has been blocking new
uploads, *with patch*
signature.asc
Description: OpenPGP digital signature
I've attached what I believe to be a better patch in
http://bugs.debian.org/527504.
signature.asc
Description: OpenPGP digital signature
Dmitrijs Ledkovs wrote:
--- debian/rules (revision 2804)
+++ debian/rules (working copy)
@@ -10,17 +10,15 @@
include /usr/share/cdbs/1/rules/debhelper.mk
include /usr/share/cdbs/1/rules/patchsys-quilt.mk
DEB_INSTALL_DOCS_ALL=
+DEB_PYTHON_DESTDIR =
Package: reprepro
Version: 3.9.2-1
Severity: normal
Tags: patch
I was trying to set up an 'update', and provided a 'VerifyRelease:' with
16-digit keyid as specified in the manpage. It appeared to be ignored.
After a bit of debugging, I found an off-by-one error in signature.c
line 129:
Another case that this affects is packages like the 'linux-latest-2.6'
source (which has simple integer version numbers), building binaries
like 'linux-image-2.6-amd64' which has a version number modelled on the
version of the kernel it pulls in.
signature.asc
Description: OpenPGP digital
suffix found on the binary
# version too.
A package which illustrates both binNMU and overridden-version
simultaneously is 'ure' in lenny.
Max.
From 1a57125501f87d11fd59fb5eddf9627a88f1ad26 Mon Sep 17 00:00:00 2001
From: Max Bowsher m...@f2s.com
Date: Sun, 12 Apr 2009 12:13:46 +0100
Subject
Package: mailman
Version: 1:2.1.12-1
Severity: mailman
Upgrading to mailman 2.1.12-1 (the first version to stop shipping an actual
/var/lock/mailman directory in the package), the postinst emits the following
error:
Upgrading from version 0x2010bf0 to 0x2010cf0
getting rid of old source files
Package: apt-listchanges
Version: 2.83
Severity: normal
A rare but possible construct in debian packages is for a source to
build binaries with a different version to the source. Examples may be
located by grepping for packages containing parentheses in their Source
control field:
Package: ghc6
Version: 6.8.2dfsg1-1
Severity: normal
debsums says, on my system:
debsums: checksum mismatch ghc6 file /usr/lib/ghc-6.8.2/package.conf.old
Should ghc6 be shipping a '.old' file in the package at all?
If it does, it shouldn't be modifying it.
Max.
--
To UNSUBSCRIBE, email to
Package: psgml
Version: 1.3.2-8
Severity: normal
After a fresh clean installation of psgml:
m...@sanpietro:~$ debsums -s psgml
debsums: checksum mismatch psgml file /usr/share/emacs/site-lisp/psgml/Makefile
debsums: checksum mismatch psgml file
/usr/share/emacs/site-lisp/psgml/config.status
Package: psgml
Version: 1.3.2-8
Severity: normal
The psgml package registers the 50psgml-init.el file with ucf, but never
unregisters it from ucf when the package is purged. However it does
delete the file from disk.
This results, after an install/purge, with ucf remembering that the file
has
Package: grub-common
Version: 1.96+20080724-12
Severity: important
Hi,
For me, update-grub is _painfully_ slow to execute, taking 10-30minutes!
I've tracked this to its use of grub-probe. An example grub-probe
command, such as:
grub-probe --device-map=/boot/grub/device.map --device /dev/sda3
Package: devscripts
Version: 2.10.41
Severity: minor
dget contains the misspelt wget option --no-chache, i.e. a typo for
--no-cache.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Package: apt
Version: 0.7.18
Severity: minor
apt-pkg/deb/dpkgpm.cc uses cfmakeraw(3) to put the terminal into raw
mode whilst running dpkg subprocesses.
This has the undesirable effect of mangling the output if you are piping
it through tee:
apt-get -y install iotop | tee /tmp/apt.log
Reading
Package: reprepro
Version: 3.6.2-1
I've discovered that for a particular file, the sha256 implementation in
reprepro gets the wrong answer (at least, GNU coreutils, openssl, and
the implementation on aarongifford.com all agree on one value, whilst
reprepro gets something else.)
Unfortunately the
I observed that the code in reprepro appears to share common ancestry
with that in glibc (I later also discovered
http://people.redhat.com/drepper/SHA-crypt.txt), and furthermore that
the code in glibc calculated the correct hash. Comparing the two, I
isolated a minimal fix as follows:
---
Package: mercurial
Version: 1.0.1-1
Severity: minor
Quoting from postinst:
ucf --sum-file /usr/share/mercurial/$conffile.md5sums --three-way \
$TMPFILE /etc/mercurial/hgrc.d/$conffile
ucfr mercurial /etc/hgrc.d/$conffile
The 'ucfr' line incorrectly mentions
Package: apt
Version: 0.7.14
Severity: normal
apt-get --no-install-recommends disables the behaviour of
APT::Install-Recommends, but does not disable any configured
APT::Install-Recommends-Sections. This is rather perplexing to users
who don't understand the details of how APT manages its
Package: apt
Version: 0.7.14
Severity: wishlist
The -o command line option allows arbitrary overriding on scalar-valued
configuration items, and appending extra entries to list-valued
configuration items. However, the ability to completely override the
contents of a list-valued configuration item
Details, including tarballs of pregenerated keysets and painfully
detailed information on how to be a script kiddie, are now published by
the metasploit project (which is linked from wiki.debian.org/SSLkeys,
even) so I think the benefits of secrecy have been eroded by now.
The only missing piece
I'm not sure whether Debian will ship blacklists generated by others,
since there's no way to verify a blacklist other than regenerating it
yourself, but I have generated RSA 1023, 1024 and 4096 bit blacklists
for my own use - available here: http://www.red-bean.com/~maxb/ .
These are i386+amd64
4096 bit RSA keys seem particularly common in my experience, could that
variant be considered for the the package, soon?
Max.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Package: python-clearsilver
Followup-For: Bug #479637
#479637 is essentially a duplicate of #452612, I think - the missing
Py_InitModule4 symbol is a manifestation of trying to reuse the
python2.4 module with python2.5 - so the bug is fixed in 0.10.4-1.2.
--
To UNSUBSCRIBE, email to [EMAIL
severity 427804 important
thanks
Based on my own and the other users comments above, I think it's
reasonable to say that this bug has a major effect on the usability of
the package.
Max.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL
According to http://bugs.mysql.com/bug.php?id=27694 this was fixed
upstream as of 5.0.50, so the current unstable package is probably no
longer affected.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
warrants severity=important.
Max Bowsher.
signature.asc
Description: OpenPGP digital signature
This sounds quite likely to be the same as
http://subversion.tigris.org/issues/show_bug.cgi?id=2580
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Package: python-moinmoin
Version: 1.5.3-1.1
Severity: important
Password reminder emails send by moinmoin display incorrect passwords,
since the reminder passwords sent by moinmoin always end with an '=',
which gets eaten by incorrect quoted-printable encoding.
See
To me, it is very unintuitive for a sysadmin to be expected to move away
a file which is normally under logrotate control.
At a minimum, I would suggest that the alert email contain a reference
to README.Debian.html section 2.5.1, so that sysadmins seeing this can
more quickly understand what's
Mark Purcell wrote:
On Friday 27 October 2006 13:03, Max Bowsher wrote:
Dropping support for wct4xxp represents a critical regression to people
using that hardware.
Max,
I would suggest you have a read of:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=388756
wct4xxp was removed
Package: zaptel
Version: 1:1.2.7.dfsg-1
Severity: important
Justification: Renders package unusable to users of specific hardware
Dropping support for wct4xxp represents a critical regression to people
using that hardware.
Ideally, a non-free package would have been created to avoid
Package: python-semanage
Version: 1.6.16-3
Severity: normal
python-semanage has a Conflicts against python2.4-semanage so that the
old package is removed upon upgrade. However, this does not work,
because the version range is (= 1.6), but 1.6-1 is a version of the
old package, which does not
severity 389780 normal
thanks
setuptools earlier than 0.6c3 do not support Subversion 1.4, which is
currently in unstable.
Specifically, attempting to install a setuptools-using python package
from a Subversion 1.4 working copy fails.
An update to 0.6c3 is needed to fix this loss of
Package: python-setuptools
Version: 0.6b3-3
Severity: normal
/usr/bin/easy_install-2.3 contains a clearly invalid shebang of:
#!/usr/bin/python2.4
This makes it rather difficult to perform easy_install maintenance on
Python 2.3 packages.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a
to be sure that this issue receives human attention before testing
migration, which the abnormal shortening of the 10-day delay due to the
sticky high urgency persisting from two months ago might otherwise
circumvent.
Thanks,
Max Bowsher.
signature.asc
Description: OpenPGP digital signature
Peter Eisentraut wrote:
Max Bowsher wrote:
Upgrading to the 4.2.2 ntp packages, which merge the ntp-server and
ntp-simple packages into the ntp package leaves the old packages in
the 'config-files' state. In particular, this leaves active cron
scripts under the name 'ntp-server', which
Package: ntp
Version: 1:4.2.2+dfsg-1
Severity: important
Setting severity to important for now, since I cannot actually point to
a specific policy directive, but this should quite possibly be elevated
to serious.
Upgrading to the 4.2.2 ntp packages, which merge the ntp-server and
ntp-simple
Package: grub
Version: 0.97-12
Severity: normal
Suppose you have kernel 2.6.15-1-somearch installed, and also have
2.6.15-1-somearch-somesuffix.
If you set the default kernel to 2.6.15-1-somearch, and run update-grub
with grub's 'update the default setting to continue pointing to the same
Package: bidentd
Severity: important
Justification for severity(important): An update to latest upstream
would solve the bug which is currently keeping bidentd out of testing.
Getting bidentd back into testing soon would be very nice, as it is not
just yet another identd - it's an identd with a
Package: apt-show-versions
Version: 0.09
Severity: normal
apt-show-versions is misbehaving for mailman. It says...
# apt-show-versions mailman
mailman 2.1.8-1 installed: No available version in archive
...but it is wrong, there is an available version...
# apt-cache policy mailman
mailman:
Package: python-setuptools
Version: 0.6b3-1
Severity: normal
$ easy_install-2.3
...
ImportError: Entry point ('console_scripts', 'easy_install-2.3') not found
The problem is due to the use of python-central to install egg-info built for
Python 2.4 into the python2.3/site-packages dir.
Package: python-configobj
Version: 4.3.1-1
Severity: normal
The .egg-info directory installed by python-configobj includes the
-py2.3 substring identifying it as version specific. Since the package
tries to be handled through python-support, it should remove the
version-specific specifier from
tags 373387 patch
done
Here's an attempt at upgrading the package to the new Python policy.
Max.
Index: debian/control
===
--- debian/control (revision 588)
+++ debian/control (working copy)
@@ -3,7 +3,7 @@
Priority:
Gustavo Noronha Silva wrote:
Hey Max!
Em Sáb, 2006-06-10 às 06:23 -0500, Max Bowsher escreveu:
Whilst pkg_resources.require() tolerates this, and still finds the
json-py egg, setuptools' easy_install does *not* find it, because it
performs filtering based on Python version declared in egg
Package: python-json
Version: 3.4-1
Severity: normal
Installing python-json causes the directory
/var/lib/python-support/python2.4/json_py-3.4-py2.3.egg-info to be
created. Note the mismatch between python versions in the containing
directory, and the egg-info name.
This creates issues for the
Package: python-formencode
Version: 0.4-5
Severity: wishlist
Please package new upstream version 0.5.1 - thanks!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Package: simplejson
Version: 1.1-1
Severity: normal
The content of the debian/copyright file appears to be intended for a
different package entirely. It refers to a piece of software called
'Pyflakes', and makes no reference to simplejson.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a
Package: simplejson
Severity: wishlist
Please package new upstream version 1.3 - thanks!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Package: x11-common
Version: 1:7.0.20
Severity: important
x11-common contains versioned conflicts with many old xorg-x11 packages
using the version specifier '= 6.9.0.dfsg.1-6'.
However, there was an AMD64 binNMU into testing via
testing-proposed-updates, of version 6.9.0.dfsg.1-6+b1, which
is still active at the time of disconnect.
Either calling $sth_vars-finish;, or moving the 5 lines concerning
$sth_vars into an enclosing block to cause $sth_vars to go out of scope
as soon as it is no longer required successfully avoid the warning.
Max Bowsher.
--
To UNSUBSCRIBE, email to [EMAIL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Laszlo Boszormenyi wrote:
Hi Max!
On Fri, 14 Apr 2006 11:34:56 -0500 Max Bowsher wrote:
sqlite = 3.3.3 exposes a bug in some pysqlite versions.
Specifically, the bug is present in:
The 2.0.x series, 2.0.7 (package: python-pysqlite2
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Laszlo Boszormenyi wrote:
On Mon, 2006-05-01 at 13:25 +0100, Max Bowsher wrote:
$ apt-cache show python2.3-pysqlite2
Package: python2.3-pysqlite2
...
Depends: libc6 (= 2.3.5-1), libsqlite3-0 (= 3.3.5), python2.3
...
As you can see
Package: dovecot-common
Version: 1.0.beta7-1
Severity: important
I have edited dovecot.conf to use a non-default SSL certificate and key,
instead of /etc/ssl/{private,certs}/dovecot.pem. My cert+key is shared
between multiple services, not only Dovecot.
The Dovecot postinst gets the cert/key
Package: mailman
Version: 2.1.7-2.1.8rc1-1
Severity: important
The explicit zero epoch in this version of the Mailman package exposes a
bug in apt-get: the package is perpetually considered in need of
upgrade, and apt-get reinstalls it every time an upgrade or dist-upgrade
is done.
The current
Package: apt
Version: 0.6.43.3
Severity: normal
Usually, an epoch value is either absent, and so zero implicitly, or
explicitly present and greater than zero.
If a package version number includes an explicit epoch value of zero,
apt-get misbehaves, considering the version present in the available
Package: sqlite3
Version: 3.3.5-0.1
Severity: normal
sqlite = 3.3.3 exposes a bug in some pysqlite versions.
Specifically, the bug is present in:
The 2.0.x series, 2.0.7 (package: python-pysqlite2)
The 1.1.x series, 1.1.7 (package: python-pysqlite)
The 2.1.x series, 2.1.3 (not in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
tags 283992 upstream
thanks
I'd be happy to commit such a patch to the upstream Subversion project,
if you still feel like writing it.
Max.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.1 (Cygwin)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
tags 217133 fixed-upstream upstream
thanks
Done for upstream 1.4.0.
Max.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.1 (Cygwin)
iD8DBQFEPnsjfFNSmcDyxYARArAAAJ4nFvBhXWNlICmCwdpKBkGicYXnNACgy2OY
UaSMK0NkLlKphHj5VTFvP9o=
=BnOq
-END PGP
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Peter Samuelson wrote:
[Max Bowsher]
Perhaps subversion should
Depends: libsvn0 (= ${Source-Version}) ?
This would avoid potential for confusion.
Hmmm. On the one hand, in Debian we try to keep our dependencies only
as tight as they need
retitle 359315 Differing versions of libsvn0 vs. subversion packages is
opportunity for confusion
thanks
Perhaps subversion should
Depends: libsvn0 (= ${Source-Version}) ?
This would avoid potential for confusion.
Are there any situations where having differing subversion and libsvn0
versions
tags 307184 wontfix
thanks
The indicated script is unmaintained, and includes hardcoded assumptions
about repo naming.
Therefore, tagging wontfix, with a recommendation to close.
There is a bash_completion script maintained within the Subversion
distribution, which is kept up-to-date with
tags 287756 wontfix upstream
thanks
Tagging wontfix, with a recommendation to close, because the reason 'svn
log' defaults to -rBASE:1 when run in a WC is actually dictated by the
underlying structure of the Subversion database:
Whilst the Subversion database makes it very easy to trace history
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Peter Samuelson wrote:
[Julian Gilbey]
burnside:~/debian/tex/tetex-bin $ perl -MSVN::Client -e \
'sub print_names { print $_[0]\n; } $ctx=new SVN::Client;
$ctx-status(, BASE, \print_names, 1, 1, 0, 1);' | head -5
.pc
.pc/.version
1 - 100 of 151 matches
Mail list logo
