Bug#1050210: libssl3: include the fips provider
Package: libssl3 Version: 3.0.9-1 Severity: wishlist Please include the fips provider module in this package. This fips provider has now been certified, so more people are looking to use it. (Conversely, it is confusing that the openssl package currently installs the "openssl-fipsinstall" program but not the module that that program is supposed to install. If there is a problem with shipping the module, then the documentation that claims you can use it should not be included in the package.)
Bug#991267: pg_config.h leaks internal macros
On 21.07.21 13:51, Max Kellermann wrote: On 2021/07/21 13:42, Peter Eisentraut wrote: What specifically are you trying to check for in libpq? Maybe there is a better way, or we could add one. It's about this compile-time check: https://github.com/CM4all/libcommon/blob/master/src/pg/Connection.hxx#L430 This is a C++ wrapper for libpq, and some users of this library run on very old Debian versions with just libpq 8, and other users run on Debian 11 with libpq wrapped in C++20 Coroutines, and for that they need PQsetSingleRowMode() which is only available since version 9. For more recently added features, libpq has feature macros such as /* Indicates presence of PQenterPipelineMode and friends */ #define LIBPQ_HAS_PIPELINING 1 /* Indicates presence of PQsetTraceFlags; also new PQtrace output format */ #define LIBPQ_HAS_TRACE_FLAGS 1 The feature you are testing arrived in PostgreSQL 9.2, so it's too old to do anything about at this point.
Bug#991267: pg_config.h leaks internal macros
On 21.07.21 08:51, Max Kellermann wrote: On 2021/07/21 08:44, Peter Eisentraut wrote: pg_config.h should only be included when compiling server-side plugins. Under what circumstances would such a plug-in use OpenSSL directly? Could you explain in more detail what you are trying to do? I did not know that - I use it to check the library version at compile time with PG_VERSION_NUM / PG_MAJORVERSION_NUM to see which features are available. This is about a client using libpq, not a server-side plugin. Obviously, PQlibVersion() is a function that can only be used at runtime, and it's too late then. Other than those macros in pg_config.h, I could not find any other compile-time way to check the libpq version. What specifically are you trying to check for in libpq? Maybe there is a better way, or we could add one.
Bug#991267: pg_config.h leaks internal macros
On 19.07.21 11:33, Max Kellermann wrote: Package: libpq-dev Version: 14~beta2-1 pg_config.h is a public header and needed if an application wants to check the version number at compile time. However, in version 14, it leaks a lot of internal PostgreSQL macros, e.g. OPENSSL_API_COMPAT which breaks applications using OpenSSL directly: /usr/include/postgresql/pg_config.h:791:9: error: 'OPENSSL_API_COMPAT' macro redefined [-Werror,-Wmacro-redefined] #define OPENSSL_API_COMPAT 0x10001000L ^ :10:9: note: previous definition is here #define OPENSSL_API_COMPAT 0x1010L ^ pg_config.h should only be included when compiling server-side plugins. Under what circumstances would such a plug-in use OpenSSL directly? Could you explain in more detail what you are trying to do?
Bug#813487: pgbouncer: Upgrading pgbouncer drops connections when run with systemd
On 2019-11-28 18:02, Christoph Berg wrote: Not sure if there's a way around that, certainly not with TLS connections (but that doesn't work without systemd either). Possibly moving the connections to a helper process first, and then exec()ing to the new version, and moving the connections back to the original PID would work. It might be possible to do this if we have systemd organize the file descriptor passing (using socket activation and all that). It's something I've been meaning to look into, but it would be a development effort, not just a packaging change. Another option might be to use the SO_REUSEPORT socket option and start a new pgbouncer instance concurrently with the old one. Then you can shut down the old one once the new one is up and taking on connections. I don't know whether that's in scope for packaging, either, though.
Bug#945145: O: docbook-dsssl -- modular DocBook DSSSL stylesheets, for print and HTML
On 2019-12-29 22:29, Chris Hofstaedtler wrote: * Peter Eisentraut [191229 21:26]: I'm not sure if anyone or anything is still using this. Certainly a few reverse (Build-)Depends: Checking reverse dependencies... # Broken Depends: docbook-utils: docbook-utils ldp-docbook-stylesheets: ldp-docbook-dsssl sgmltools-lite: sgmltools-lite # Broken Build-Depends: bochs: docbook-dsssl dictionaries-common: docbook-dsssl docbook-utils: docbook-dsssl hugs98: docbook-dsssl idzebra: docbook-dsssl installation-guide: docbook-dsssl kannel: docbook-dsssl kannel-sqlbox: docbook-dsssl libdbi: docbook-dsssl libdbi-drivers: docbook-dsssl libetpan: docbook-dsssl libopenusb: docbook-dsssl libusb: docbook-dsssl lprng-doc: docbook-dsssl opensp: docbook-dsssl pgpool2: docbook-dsssl privoxy: docbook-dsssl sgml2x: docbook-dsssl slony1-2: docbook-dsssl yaz: docbook-dsssl Yeah, about half of these are wrapper tools or something of the sort, half are very old software packages that should update their documentation build process upstream (or should be removed from Debian). While investigating this - knowing nothing about docbook myself -, I discovered that docbook.org recommends using pandoc instead of the openjade/xmlto/... zoo. Maybe other maintainers might find this useful. I'm not aware of this recommendation and I couldn't find it. The most straightforward change would be to change to docbook-xsl. But that would be an upstream decision.
Bug#948230: RFA: source-highlight -- convert source code to syntax highlighted document
Package: wnpp Severity: normal I'm looking for a new maintainer. There is a new upstream release to be packaged and some technical packaging cleanup work to be done. Everything works well, it's a useful package, it just needs a bit of attention.
Bug#948229: RFA: cmark -- CommonMark parsing and rendering program
Package: wnpp Severity: normal I'm looking for a new maintainer. The first job would be to update to the new upstream release. The shared library does not have a track record of compatibility, so updating it might require some care. Perhaps there is a way to collaborate better with the cmark-gfm package.
Bug#947175: O: sgml-spell-checker -- spell checker for SGML documents
Package: wnpp Severity: normal I am the upstream maintainer of this package, but I don't really maintain it any longer. It's really more of a private tool at this point. If no one is interested in this package, I will ask for its removal.
Bug#946757: O: lzop -- fast compression program
Package: wnpp Severity: normal Most sensibly maintained together with its underlying library lzo2 (see #946756), but the two source packages are released separately upstream.
Bug#946756: O: lzo2 -- data compression library
Package: wnpp Severity: normal Looking for new maintainer. Requires some care, source has some assembly code, had some portability issues in the past. Upstream releases are rare but appear to still happen.
Bug#946410: O: libtap-formatter-junit-perl -- Perl module for converting TAP output to JUnit XML output
Package: wnpp Severity: normal This was once useful for use with Jenkins, before Jenkins had a plugin for TAP results. Nowadays, I think it's obsolete. Perhaps it should be removed.
Bug#945988: O: libintl-perl -- Uniforum message translations system compatible i18n library
Package: wnpp Severity: normal The package has a sizeable installation count and an active upstream. It needs an active maintainer to keep it up to date with upstream and in line with various policies. Perhaps the Debian Perl Group should take it.
Bug#945394: O: delimmatch -- Perl module to match delimited substrings
Package: wnpp Severity: normal This package is abandoned upstream. I don't think this package was ever in general use. It was only used in the process of doing upstream releases of the docbook-dsssl package (note: not a build dependency in Debian). If docbook-dsssl is removed (see #945145), so should this. That said, there is nothing wrong with it, but I imagine in the Perl world there are countless other modules that have the same functionality.
Bug#945146: O: docbook-dsssl-doc -- documentation for the DocBook DSSSL stylesheets
Package: wnpp Severity: normal This package belongs together with docbook-dsssl, about which see #945145.
Bug#945145: O: docbook-dsssl -- modular DocBook DSSSL stylesheets, for print and HTML
Package: wnpp Severity: normal This package is abandoned upstream. I'm not sure if anyone or anything is still using this. There are close relationships with other similarly obsolescent packages such as docbook (the SGML variant) and openjade and some reverse dependencies with what are essentially wrapper scripts. It might be worth making a concerted effort removing all of these from Debian. Otherwise this package can stay on life support without doing much harm.
Bug#897138: O: anacron -- cron-like program that doesn't go by time
On 5/4/18 19:55, Sean Whitton wrote: > On Sat, Apr 28, 2018 at 11:03:07PM +0000, Peter Eisentraut wrote: >> The package is no longer maintained upstream, > > Oh dear :( > >> and it doesn't interact well with systemd. > > Could you expand/provide some bug numbers, please? What exactly can go > wrong? I think most of the "important" bugs are related to this and similar issues.
Bug#897138: O: anacron -- cron-like program that doesn't go by time
Package: wnpp Severity: normal I intend to orphan the anacron package. The package description is: Anacron (like "anac(h)ronistic") is a periodic command scheduler. It executes commands at intervals specified in days. Unlike cron, it does not assume that the system is running continuously. It can therefore be used to control the execution of daily, weekly, and monthly jobs (or anything with a period of n days), on systems that don't run 24 hours a day. When installed and configured properly, Anacron will make sure that the commands are run at the specified intervals as closely as machine uptime permits. . This package is pre-configured to execute the daily jobs of the Debian system. You should install this program if your system isn't powered on 24 hours a day to make sure the maintenance jobs of other Debian packages are executed each day. The package is no longer maintained upstream, and it doesn't interact well with systemd. It might need a complete rethink or replacement. (The co-maintainer has never been active, but they are welcome to take over the package like everyone else.)
Bug#887940: [Pkg-postgresql-public] Bug#887940: libpq-dev: changed version format in pg_config causes other packages to FTBFS
On 1/21/18 16:07, Adrian Bunk wrote: > Package: libpq-dev > Version: 10.1-3 > Severity: serious > Control: affects -1 src:libpreludedb > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libpreludedb.html > > ... > checking for ... checking for pg_config... /usr/bin/pg_config > checking for PostgreSQL libraries... yes > ./configure: line 19300: test: too many arguments > ... Looks like the ax_lib_postgresql.m4 macro should be fixed with some additional shell quoting.
Bug#459427: changelog vs. NEWS handling
On 12/1/17 11:19, Ian Jackson wrote: > Is there some reason why exacdt standardisation of the filenames is > necessary here ? For most of the uses I can think of, it is OK to > look in a handful of files to see which one might answer the question. I wrote the bug originally. My goal was simply to get more packages to ship release notes (NEWS), and optionally, to get fewer packages to ship useless source-level changelogs. A policy adjustment can help that a bit because that also influences things like debhelper and a lot of packages just use that without much further thought.
Bug#865020: [Pkg-postgresql-public] Bug#865020: postgresql-9.6: FTBFS with Perl 5.26: hstore_plperlu differences
On 6/18/17 15:15, Niko Tyni wrote: > Package: postgresql-9.6 > Version: 9.6.3-3 > Severity: important > User: debian-p...@lists.debian.org > Usertags: perl-5.26-transition > > This package fails to build with Perl 5.26 (currently in experimental.) This will be fixed in upstream 9.6.4, expected in August. So it's perhaps not worth patching around in it before then.
Bug#855342: RFH: ntp
On 2/19/17 07:01, Kurt Roeckx wrote: >>> I could really use some help with the ntp (network time protocol) >>> package. There have been various bugs filed, and I didn't have the >>> time to properly look at them and deal with them. >>> >>> It's currently team maintained, but I've been the only one doing >>> anything the past few years. >> >> I'm willing to help (both triaging bugs and updating the package). >> >> I would prefer the repository to be converted to git though, I'm much >> more experienced with git-buildpackage than the svn toolchain. > > I wanted to give you access to the repository, but I see I'm only > a junior developer. > > Peter, > > Can you change the permissions on the alioth project? done I'm sorry I haven't been of much use lately. If I'm in the way of new people taking over, let me know.
Bug#840727: cmark: please provide libcmark0 and libcmark-dev packages
On 10/14/16 4:33 AM, Andrew Shadura wrote: > Please provide libcmark-* packages, so that packages using > CommonMark library can link against and depend on these > packages. Do you have an actual package in mind that needs this? I have some doubts that upstream is following "proper" shared library compatibility practices. So I don't want to put out a shared library package on a hunch. A static library might be possible.
Bug#837503: RM: chkconfig -- ROM; obsolescent and buggy
Package: ftp.debian.org Severity: normal Please remove as it is obsolescent and buggy. See also orphaning bug #833672.
Bug#255208: [Pkg-postgresql-public] Bug#255208: obsolete?
On 8/8/16 10:46 AM, Christoph Berg wrote: >> I haven't tested this in detail for local socket connections, but for >> TCP/IP, the backend carries on if the client disappears. The >> server-side TCP keepalive settings are there to control this to some extent. > > I mean... why? If PG receives SIGPIPE in that case (I haven't tested > it, but I believe it does), why carry on? For example, if you have a long-running update, it will run to completion even if you're no longer connected. This is arguably a feature.
Bug#617802: Excessively long content in /proc/#/cmdline.
The child processes inherit the command-line area from the parent process, and the zero bytes are necessary to overwrite what the parent process left in there.
Bug#255208: obsolete?
Since PostgreSQL 9.2, an unprivileged user can cancel their own queries using pg_cancel_backend(). So I think the original reason behind this complaint is obsolete. I propose to close this bug.
Bug#832440: libintl-perl: CVE-2016-1238 fix
On 8/4/16 12:06 PM, Dominic Hargreaves wrote:
>> if ($no_xs) {
>> > +local @INC = @INC;
>> > +pop @INC if $INC[-1] eq '.';
>> > eval {
>> > require POSIX;
>> > # void
> This 'local @INC' should I believe reside within the eval block.
No, it applies to the requires after the eval block, just like in the
original patch.
Bug#833682: ITP: cmark -- CommonMark parsing and rendering library and program in C
Package: wnpp Severity: wishlist Owner: Peter Eisentraut <pet...@debian.org> * Package name: cmark Version : 0.26.1 Upstream Author : John MacFarlane <j...@berkeley.edu> * URL : https://github.com/jgm/cmark * License : BSD, MIT Programming Lang: C Description : CommonMark parsing and rendering library and program in C cmark is the C reference implementation of CommonMark, a rationalized version of Markdown syntax with a spec.
Bug#833672: O: chkconfig
Package: wnpp Severity: normal This package has been obsoleted by the wide-spread adoption of systemd. It's also pretty buggy at this point. Unless there is some last-minute interest in this, I will ask for removal soon.
Bug#833341: [Pkg-postgresql-public] Bug#833341: Change default fallback locale to C.UTF-8
On 8/3/16 5:21 AM, Christoph Berg wrote: > Package: postgresql-common > Version: 175 > Severity: normal > > Too many people end up with SQL_ASCII clusters when they didn't have > any specific OS locale configured. We should change the default locale > to C.UTF-8. That sounds useful.
Bug#832440: libintl-perl: CVE-2016-1238 fix
On 7/25/16 10:45 AM, Dominic Hargreaves wrote:
> Package: libintl-perl
> Version: 1.24-1
> Severity: important
>
> Hi maintainer,
>
> An update for this package has been released as part of our handling for
> the issue described below. This fixes an instance of the dynamic module
> loading vulnerability alluded to.
>
> I attach the patch I applied for jessie; please could you review this
> and apply something similar for sid?
The code has changed a little bit in sid. I ported your patch. Could
you check that the attached makes sense?
--- a/lib/Locale/Messages.pm
+++ b/lib/Locale/Messages.pm
@@ -28,6 +28,8 @@
# Try to load the C version first.
$package = 'gettext_xs';
+local @INC = @INC;
+pop @INC if $INC[-1] eq '.';
eval <<'EOF';
require Locale::gettext_xs;
my $version = Locale::gettext_xs::__gettext_xs_version();
@@ -40,6 +42,8 @@
#
# On such systems, we always fall back to gettext_dumb.
if ($no_xs) {
+local @INC = @INC;
+pop @INC if $INC[-1] eq '.';
eval {
require POSIX;
# void
@@ -200,9 +204,15 @@
my $filename = "Locale::$pkg";
$filename =~ s{::|\'}{/};
$filename .= '.pm';
-eval { require $filename };
+eval {
+local @INC = @INC;
+pop @INC if $INC[-1] eq '.';
+require $filename
+};
$package = $pkg unless $@;
} else {
+local @INC = @INC;
+pop @INC if $INC[-1] eq '.';
eval "require Locale::gettext_xs";
$package = 'gettext_xs' unless $@;
}
Bug#812054: lzop: diff for NMU version 1.03-3.3
On 7/6/16 4:19 PM, Reiner Herrmann wrote: Control: tags 812054 + patch Control: tags 812054 + pending Dear maintainer, I've prepared an NMU for lzop (versioned as 1.03-3.3) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. Thanks, I had already been working on a different solution.
Bug#797234: source-highlight, regina-normal and libstdc++6
On 10/24/15 1:44 PM, Benjamin Burton wrote: >> That leaves the question: what to do with this bug? > > FYI, if a rebuild *is* required then I presume it would be a simple rename > from libsource-highlight4 to libsource-highlight4v5; see the (tested) patch > below. I’m happy to NMU this if the maintainer does not have time (which is > why the changelog entry reads as an NMU). Works for me.
Bug#797234: source-highlight: library rename needed for libstdc++6 ABI changes
On 8/28/15 3:15 PM, Matthias Klose wrote: Package: src:source-highlight Version: 3.1.8-1 Severity: serious Tags: sid stratch ^^^ source-highlight: library rename needed for libstdc++6 ABI changes or else at least regina-normal ftbfs with link errors. More details? Wiki page?
Bug#795984: [Pkg-postgresql-public] Bug#795984: postgresql-plproxy: please make the build reproducible
On 8/23/15 2:48 PM, Jérémy Bobbio wrote: Hi Peter, Peter Eisentraut: On 8/18/15 9:15 AM, Dhole wrote: The attached patch sets the timezone to UTC before calling asciidoc to avoid timezone differences in the generated docs. Once applied, postgresql-plproxy can be built reproducibly in our current experimental framework. Stupid question: Couldn't dpkg-buildpackage set the time zone? This is a legitimate question. :) `dpkg-buildpackage` is not mandatory to build Debian package. It would be confusing to developers if `fakeroot debian/rules binary` would create different packages than `dpkg-buildpackage.` Well, nothing is mandatory for building a Debian package, since you can just assemble the archives manually. But you could say, if you want a reproducible build, you need to use dpkg-buildpackage. I feel the environment variable issue in particular could use a centralized solution, instead of patching each package individually. You guys have identified a few environment variables that are common culprits, such as local and time zone, because those are very often set by users. But that doesn't address that infinite number of other environment variables that users could set. Nothing technically prevents a package from being built with LD_PRELOAD set or a nonstandard JAVA_HOME, for example. The other thing is that it might break some packages or test suites in subtle ways. Overriding the timezone in a local manner avoids any surprises. The problem here in particular is that I don't know whether setting the time zone in this way is portable to non-Linux, non-GNU systems. So a patch like this might not be acceptable upstream.
Bug#795984: [Pkg-postgresql-public] Bug#795984: postgresql-plproxy: please make the build reproducible
On 8/18/15 9:15 AM, Dhole wrote: The attached patch sets the timezone to UTC before calling asciidoc to avoid timezone differences in the generated docs. Once applied, postgresql-plproxy can be built reproducibly in our current experimental framework. Stupid question: Couldn't dpkg-buildpackage set the time zone?
Bug#787468: [Pkg-postgresql-public] Bug#787468: postgresql-9.4: FTBFS with perl 5.22 (test failures)
On 8/20/15 6:10 AM, Dominic Hargreaves wrote: On Sat, Jun 06, 2015 at 09:05:54PM -0400, Peter Eisentraut wrote: Upstream will come up with a fix for this pretty soon, at which time we could either incorporate the patch or wait for the next minor releases. Hi, Thanks for the quick response! It looks like this is still outstanding upstream. Would it be possible to apply something like http://pkgs.fedoraproject.org/cgit/postgresql.git/commit/?id=71849163567e1 in the meantime? Here is the upstream patch: http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=4a1944ec6caf41f1008e86296fa8712ba8b59317 What is the planned timeline for the Perl 5.22 transition?
Bug#794103: please support cross compilation using libpq-dev as a build-dependency
On 7/30/15 10:31 AM, Helmut Grohne wrote: * Do not use pg_config at all. Use pkg-config instead. + pkg-config nicely supports cross compilation (for autotools based projects) out of the box (assuming that #759556 gets fixed). - pkg-config does not work for Windows and thus does not work for PostgreSQL upstream. In particular, the documentation will keep referring to pg_config. So reverse Build-Depends would need to support both pkg-config (for Debian) and pg_config (for Windows). - (Consequence:) Many packages need patches. A sane libpq-using package would give the user some kind of choice or check in sequence some combination of: - use pkg-config - use pg_config - rely on default paths A package that insists on using pg_config is not only broken for cross-compilation, but also for multi-arch. So those packages should be fixed. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#789439: similar case
While looking into a similar case I found this bug report. I brought up the debian/jessie64 vagrant image and upgraded it to sid. The starting setup contains a /etc/network/interfaces file that refers to eth0: # The primary network interface allow-hotplug eth0 iface eth0 inet dhcp pre-up sleep 2 After upgrading and rebooting, the interface appears as enp0s3 instead and the network does not come up. To be fair, the NEWS.Debian entry for udev says If you have ifupdown ... configuration that relies on old names, but I doubt that many normal users will be able to interpret that. I also tried it a different way: I installed the jessie netinst CD into a new virtualbox machine, upgraded it to sid, rebooted, but there the network came up as eth0 again. This is doubly confusing. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787468: [Pkg-postgresql-public] Bug#787468: postgresql-9.4: FTBFS with perl 5.22 (test failures)
Upstream will come up with a fix for this pretty soon, at which time we could either incorporate the patch or wait for the next minor releases. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#777623: pg_wrapper can fail before picking latest version
Package: postgresql-client-common pg_wrapper is supposed to pick the latest version of psql and other tools, but it can fail with Error: No existing local cluster is suitable as a default target. Please see man pg_wrapper(1) how to specify one. before it gets to that point. This will happen if you don't specify a host or port and there is no local cluster using port 5432. It seems to me that https://alioth.debian.org/scm/loggerhead/pkg-postgresql/postgresql-common/trunk/view/head:/pg_wrapper#L109 should be moved before https://alioth.debian.org/scm/loggerhead/pkg-postgresql/postgresql-common/trunk/view/head:/pg_wrapper#L90 (Not sure about the exact order, but I'm sure the awesome test suite will sort it out. ;-) ) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#772990: /usr/sbin/ntpdate-debian: does not synchronize time
On 1/9/15 3:47 PM, Michal Suchanek wrote: It's obviously not bad thing to consult dhcp but doing so silently is not so nice. It should be documented that dhcp supplied server overrides configuration file. I think it would be useful if the user-supplied configuration actually overrode dhcp supplied one but that would make supplying a default server set in the package impractical. Actually, you could try dhcp supplied server and if that fails try the one from configuration file. I agree something could be better there. Not sure what yet. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#772990: /usr/sbin/ntpdate-debian: does not synchronize time
On Fri, 2014-12-12 at 21:01 +0100, Michal Suchanek wrote: ~# cat /etc/default/ntpdate # The settings in this file are used by the program ntpdate-debian, but not # by the upstream program ntpdate. # Set to yes to take the server list from /etc/ntp.conf, from package ntp, # so you only have to keep it in one place. NTPDATE_USE_NTP_CONF=no # List of NTP servers to use (Separate multiple servers with spaces.) # Not used if NTPDATE_USE_NTP_CONF is yes. NTPSERVERS=tik.cesnet.cz # Additional options to pass to ntpdate NTPOPTIONS= ~# ntpdate tik.cesnet.cz 12 Dec 19:46:32 ntpdate[1236]: adjust time server 195.113.144.201 offset 0.001415 sec ~# ntpdate-debian 12 Dec 19:46:45 ntpdate[1237]: no server suitable for synchronization found This works as expected for me. Please run ntpdate-debian under sh -x to see why it does not pick up your server. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764546: ntp: Init script returns 5 if the daemon is not executable
On 10/8/14 6:50 PM, Felipe Sateler wrote: Package: ntp Version: 1:4.2.6.p5+dfsg-3.1 Severity: normal The ntp init script has this check: test -x $DAEMON || exit 5 That is the LSB exit code, but I guess that practice never really caught on. Which means that if ntp has been removed but not purged, the ntp script will fail at boot. With systemd actually checking the return code of init scripts, this results in the system being flagged as not correctly booted. Hmm, is that something that should be fixed in jessie then? (Other packages might be affected.) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757037: forwarded upstream
Control: forwarded 757037 mar...@oberhumer.com Thanks for everyone's help on this. I have forwarded the patch upstream. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750163: postgresql-plproxy: Conflicting declarations of function plproxy_yy_scan_bytes to cause undefined behaviour
The flex documentation has Function: YY_BUFFER_STATE yy_scan_bytes ( const char *bytes, int len) which is what plproxy abides by. The actual flex implementation uses yy_size_t, which is really size_t. Reported upstream as https://sourceforge.net/p/flex/bugs/184/. Ideally, flex --header-file should be used instead of copying the declaration. Patch proposed upstream as https://github.com/markokr/plproxy-dev/pull/10. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744753: anacron: Anacron not triggered when system resumes under systemd
I don't know much about systemd, so I can't be of much help with this. If anyone wants to take responsibility for a solution, please go ahead. (Also consider addressing #771393 at the same time.) An alternative would be to remove systemd support from the package for the release and rely on the plain old sysvinit setup. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#772202: pg_upgradecluster should not restrict upgrading tablespaces
Package: postgresql-common pg_upgradecluster --method=dump refuses to upgrade tablespaces because of bug #523574, but that check is no longer necessary as of PostgreSQL 9.0, because tablespaces can be upgraded in place (postgresql commit 22817041). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764705: [Pkg-postgresql-public] Bug#764705: Bug#764705: Bug#764705: Bug#764705: Bug#764705: postgresql-9.4: ERROR: The database format changed between beta 2 and 3. Please dump, but how?
On 10/13/14 11:35 AM, Christoph Berg wrote: Yeah, though it was pretty unexpected that there was another catalog version bump after beta2 :-(. Possibly, but it's not unheard of. There could also be other issues such as WAL format changes or extension ABI changes that could affect the upgrade process. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764705: [Pkg-postgresql-public] Bug#764705: Bug#764705: postgresql-9.4: ERROR: The database format changed between beta 2 and 3. Please dump, but how?
On 10/10/14 6:17 PM, Thorsten Glaser wrote: I’ve read in the archives that you did this before, in 9.1 times. Please invest some time into creating a proper fix for this scenario, one which keeps cluster-wide settings (such as locale, encoding, etc.) and configuration files the way they were before. (Especially as pg_createcluster is highly dependent on the environment it is run from.) pg_upgradecluster does that for you. I think the mistake here was to upload postgresql-9.4 into unstable before it was released. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757037: liblzo2-2: Upgrading liblzo2-2 to 2.08 crashes openvpn
On Mon, 2014-08-04 at 21:02 +0200, Thomas Herrmann wrote: after upgrading to 2.08-1, openvpn (version 2.3.2-9) fails with the following error message: Cannot initialize LZO compression library Exiting due to fatal error Downgrading to 2.06 fixes the problem for me. Do you have a reproducible test case for that? (It doesn't happen for me if I just run /usr/sbin/openvpn without anything else.) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#627377: #627377: dirmngr: special requests can make dirmngr hang, can be denial of service for email signatures
Control: tags -patch +moreinfo The links in this bug report no longer work. I was hoping that this issue would be fixed in the release 1.1.1, but it doesn't seem so. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743448: [anacron] Allow job serialisation to be customisable
On Wed, 2014-04-02 at 20:54 +0100, OmegaPhil wrote: Debian's '/etc/init.d/anacron' script indeed hobbles this by calling anacron with '-s'. I have attached a patch to allow anacron's arguments to be user-customisable in the '/etc/default/anacron' file - the patch keeps the current configuration. Maybe it should be on by default? I don't know why it's off. It was like that when I inherited the package. It might overwhelm small machines when it's on. Could use some research. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#577737: [pinentry-qt4] Re: gpg command won't use agent if the agent is configured to use pinentry-qt4
I can't reproduce this, and I can't explain it. A couple of things to try: Try running pinentry-qt4 independently of gpg. Just start it and enter GETPIN at the prompt, and see if a window appears. Also check your login setup to make sure that the environment variables GPG_TTY and/or GPG_AGENT_INFO are set correctly. Although that wouldn't explain why pinentry-gtk-2 works. There could be other environment variables or settings that affect Qt but not Gtk. Testing the programs separately, as described above, might clarify that. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741392: build dyn libraries
Package: haskell-devscripts Version: 0.8.19.4 Severity: wishlist I was building some code of my own that ended up complaining Could not find module `Language.Haskell.Interpreter' Perhaps you haven't installed the dyn libraries for package `hint-0.3.3.6'? Use -v to see a list of the files searched for. Online I found a suggestion for that, which is to rebuild everything with --enable-shared. Which works, if I use cabal to manage packages, but it would be nice if the Debian packages supported that as well. It seems that this could be doable by just putting --enable-shared in the right place, but it would have to be done package by package from the bottom up. Thoughts? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736245: [pkg-ntp-maintainers] Bug#736245: /usr/sbin/ntp-wait: insufficient dependency on perl
On 1/21/14, 8:16 AM, Jonathan Wiltshire wrote: Please Depends: perl, and backport this to stable via proposed-updates. If we do that, then someone will complain that ntp now depends on perl, which they don't like for some reason or other. The alternative is to split out ntp-wait into a separate package, but that will create more overhead than simply depending on perl when required. I kind of doubt that calling ntp-wait in a postinst script is reasonable anyway. I understand that you want to have an accurate clock, but you could make that argument about approximately 37% of packages. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737157: source-highlight: [PATCH] Enable build on newer arches
On Thu, 2014-01-30 at 13:37 -0500, Daniel T Chen wrote: In Ubuntu 14.04, the attached patch was applied to achieve the following: * Use dh-autoreconf for newer arches. Which newer arches? AFAICT, this package builds fine on all architectures supported by Debian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736476: uscan: always downloads signature files over HTTP
Package: devscripts Version: 2.13.9 Severity: normal uscan supports ftp and http URLs for the main package file, but the OpenPGP signature file is always downloaded over HTTP, even if it's using an ftp URL, which fails. The same conditional logic that is used for the main download needs to be applied for the signature file. While we're at is, the error message is also wrong: uscan_warn $progname warning: In directory $pkg_dir, downloading OpenPGP signature\n $upstream_url failed: . $sigresponse-status_line . \n; even though it was actually downloading $pgpsig_url. Looks like copy and paste. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (101, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.10-3-686-pae (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages devscripts depends on: ii dpkg-dev 1.17.5 ii libc62.17-97 ii perl 5.18.1-5 ii python3 3.3.2-17 pn python3:any none Versions of packages devscripts recommends: pn at none ii curl7.34.0-1 ii dctrl-tools 2.23 ii debian-keyring 2013.12.13 ii dput0.9.6.4 ii dupload 2.7.0 ii equivs 2.0.9 ii fakeroot1.18.4-2 ii gnupg 1.4.15-3 ii libdistro-info-perl 0.11 ii libencode-locale-perl 1.03-1 ii libjson-perl2.61-1 ii liblwp-protocol-https-perl 6.04-2 ii libparse-debcontrol-perl2.005-4 ii libsoap-lite-perl 0.716-1 ii liburi-perl 1.60-1 ii libwww-perl 6.05-2 ii lintian 2.5.20 ii man-db 2.6.5-2 ii patch 2.7.1-4 ii patchutils 0.3.2-3 ii python3-debian 0.1.21+nmu2 ii python3-magic 1:5.14-2 ii sensible-utils 0.0.9 ii strace 4.5.20-2.3 ii unzip 6.0-10 ii wdiff 1.2.1-1 ii wget1.14-5 ii xz-utils5.1.1alpha+20120614-2 Versions of packages devscripts suggests: ii bsd-mailx [mailx]8.1.2-0.20131005cvs-1 ii build-essential 11.6 pn cvs-buildpackage none pn devscripts-elnone ii gnuplot 4.6.4-1 ii gpgv 1.4.15-3 ii libauthen-sasl-perl 2.1500-1 ii libfile-desktopentry-perl0.07-1 ii libnet-smtp-ssl-perl 1.01-3 ii libterm-size-perl0.207-1+b1 ii libtimedate-perl 2.3000-1 ii libyaml-syck-perl1.27-2+b1 pn mutt none ii openssh-client [ssh-client] 1:6.4p1-2 ii svn-buildpackage 0.8.5 ii w3m 0.5.3-12 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732187: missing dependency on libpng12-dev?
Package: libgtk2.0-dev Version: 2.24.22-1 Severity: important $ pkg-config --cflags gtk+-2.0 Package libpng12 was not found in the pkg-config search path. Perhaps you should add the directory containing `libpng12.pc' to the PKG_CONFIG_PATH environment variable Package 'libpng12', required by 'GdkPixbuf', not found If I install the libpng12-dev package, then it works as expected. This is currently causing the pinentry package to fail to build, possibly others as well. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (101, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.10-3-686-pae (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libgtk2.0-dev depends on: ii gir1.2-gtk-2.02.24.22-1 ii libatk1.0-dev 2.10.0-2 ii libcairo2-dev 1.12.16-2 ii libgdk-pixbuf2.0-dev 2.28.2-1+b1 ii libglib2.0-dev2.36.4-1 ii libgtk2.0-0 2.24.22-1 ii libgtk2.0-common 2.24.22-1 ii libpango1.0-dev 1.36.0-1 ii libx11-dev2:1.6.2-1 ii libxcomposite-dev 1:0.4.4-1 ii libxcursor-dev1:1.1.14-1 ii libxdamage-dev1:1.1.4-1 ii libxext-dev 2:1.3.2-1 ii libxfixes-dev 1:5.0.1-1 ii libxi-dev 2:1.7.2-1 ii libxinerama-dev 2:1.1.3-1 ii libxml2-utils 2.9.1+dfsg1-3 ii libxrandr-dev 2:1.4.1-1 ii pkg-config0.26-1 Versions of packages libgtk2.0-dev recommends: ii debhelper 9.20131127 ii python 2.7.5-5 Versions of packages libgtk2.0-dev suggests: pn libgtk2.0-doc none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731352: ntpdate-debian ignores DHCP ntp-servers option by default
On Wed, 2013-12-04 at 14:13 +, Robie Basak wrote: However, the logic in /usr/sbin/ntpdate-debian does not use or examine /var/lib/ntpdate/default.dhcp if NTPDATE_USE_NTP_CONF is set to yes, which is the default, even when the ntp package is not installed and /etc/ntp.conf does not exist. I can see how this can seem suboptimal. It seems to me that the setting of NTPDATE_USE_NTP_CONF=yes is nonsensical if there is no /etc/ntp.conf, and so should be treated as if it says no in this case. Well, it could also be a mistake that /etc/ntp.conf is missing. Alternatively, should /var/lib/ntpdate/default.dhcp be added to the search list for the NTPDATE_USE_NTP_CONF=yes case, after /etc/ntp.conf? That wouldn't really be true to the name use ntp.conf. We could conceivably add a mode that says, use any NTP servers you can find, but that might be bit too unspecific. Generally, our idea is that ntpdate is deprecated and shouldn't be used at all, or certainly not be used without an ntp server installed as well, so other cases might not be well supported. I would, however, consider patches. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#720619: closed by Charles Plessy ple...@debian.org (Bug#720619: fixed in mime-support 3.55~experimental1)
Control: reopen -1 application/x-sha1 is still there. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729759: new upstream release 2.5.37
Package: flex Version: 2.5.35-10.1 Severity: normal A new upstream release has been available for some time. Please package it. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722763: dirmngr link with -L/usr/lib
On Sat, 2013-09-14 at 11:27 +0800, YunQiang Su wrote: This package has one or more -L/usr/lib in its build system, which will make it ftbfs if there is libraries under /usr/lib, while is not the default architecture, mips* for example. It looks like you are building against an ancient version of libpth-dev: Get:6 http://192.168.252.248/debian/ sid/main libpth-dev mips64el 2.0.7-16 [151 kB] I have version 2.0.7-19, whose pth-config doesn't produce -L/usr/lib. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729103: O: php-net-lmtp
Package: wnpp Severity: normal I have no attachment to this package anymore. It was once a dependency of kolab, but it doesn't have any reverse dependencies anymore. If the package is deemed worth keeping, there is a new upstream release with a slightly changed file structure that needs someone with more enthusiasm than me to package it. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#723503: [Pkg-postgresql-public] Bug#723503: postgresql-9.3 link with -L/usr/lib
On Tue, 2013-09-17 at 18:52 +0800, YunQiang Su wrote:
This package has one or more -L/usr/lib in its build system,
which will make it ftbfs if there is libraries under /usr/lib,
while is not the default architecture, mips* for example.
The occurrence of -L/usr/lib that is making your build fail is the
directory where to find the Python library, which is obtained by
python -c import distutils.sysconfig; print('
'.join(filter(None,distutils.sysconfig.get_config_vars('LIBDIR'
I don't know how this is supposed to work when you have libraries for
multiple architectures on the system but only one python binary.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#728834: doesn't know how to open http links by default
On 11/6/13, 1:06 AM, Carsten Schoenert wrote: Hello Peter, On Tue, Nov 05, 2013 at 09:51:36PM -0500, Peter Eisentraut wrote: Package: icedove Version: 24.0-1 Severity: normal I fresh icedove installation doesn't know how to open http links in emails. Instead, it requires me to use a file system dialog to dig my way down to /usr/bin/something, which is very unfriendly and slow. Given that Debian has a standard for this (x-www-browser), this could be configured by default. what kind of window manager do you use? What's your system? A fresh install from unstable or experiemental? What else do you have done? Window manager is GNOME. The system is running testing. The icedove package was from experimental (see version number). I had never used icedove on this system before. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#728831: use docbook-xsl for building man pages
Package: moreutils Version: 0.50 Severity: wishlist Tags: patch moreutils still uses the obsolescent docbook2x package for building man pages from DocBook sources. I have taken the liberty to port this to the more current and better maintained docbook-xsl package (the same package that is normally used to produce HTML). This also helps building moreutils on other platforms, where the docbook2x package is increasingly difficult to come by. I have also fixed a few bugs in the markup along the way. I hope you will find the attached patches useful. From 4d0ce7c7eaca224e9c5d8868f6399b4c91e3c73b Mon Sep 17 00:00:00 2001 From: Peter Eisentraut pet...@debian.org Date: Sat, 2 Nov 2013 16:24:37 -0400 Subject: [PATCH 1/5] Use http system identifiers This makes the DocBook files independent of particular file-system layout. On system with proper XML catalog setups, there should be no difference. (No actual HTTP calls will be made.) --- errno.docbook| 2 +- ifdata.docbook | 2 +- ifne.docbook | 2 +- isutf8.docbook | 2 +- lckdo.docbook| 2 +- mispipe.docbook | 2 +- parallel.docbook | 2 +- pee.docbook | 2 +- sponge.docbook | 2 +- 9 files changed, 9 insertions(+), 9 deletions(-) diff --git a/errno.docbook b/errno.docbook index 63ae492..bcfbf9a 100644 --- a/errno.docbook +++ b/errno.docbook @@ -21,7 +21,7 @@ with this program; if not, write to the Free Software Foundation, Inc., -- !DOCTYPE refentry PUBLIC -//OASIS//DTD DocBook V4.4//EN -file:///usr/share/xml/docbook/schema/dtd/4.4/docbookx.dtd +http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd; [] refentry diff --git a/ifdata.docbook b/ifdata.docbook index 963943e..a57680b 100644 --- a/ifdata.docbook +++ b/ifdata.docbook @@ -21,7 +21,7 @@ with this program; if not, write to the Free Software Foundation, Inc., -- !DOCTYPE refentry PUBLIC -//OASIS//DTD DocBook V4.4//EN -file:///usr/share/xml/docbook/schema/dtd/4.4/docbookx.dtd +http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd; [] refentry diff --git a/ifne.docbook b/ifne.docbook index 41fa9ab..0a8c01c 100644 --- a/ifne.docbook +++ b/ifne.docbook @@ -21,7 +21,7 @@ with this program; if not, write to the Free Software Foundation, Inc., -- !DOCTYPE refentry PUBLIC -//OASIS//DTD DocBook V4.4//EN -file:///usr/share/xml/docbook/schema/dtd/4.4/docbookx.dtd +http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd; [] refentry diff --git a/isutf8.docbook b/isutf8.docbook index 58355a2..6451d8a 100644 --- a/isutf8.docbook +++ b/isutf8.docbook @@ -21,7 +21,7 @@ with this program; if not, write to the Free Software Foundation, Inc., -- !DOCTYPE refentry PUBLIC -//OASIS//DTD DocBook V4.4//EN -file:///usr/share/xml/docbook/schema/dtd/4.4/docbookx.dtd +http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd; [] refentry diff --git a/lckdo.docbook b/lckdo.docbook index effe84d..3bec67a 100644 --- a/lckdo.docbook +++ b/lckdo.docbook @@ -8,7 +8,7 @@ Public domain. -- !DOCTYPE refentry PUBLIC -//OASIS//DTD DocBook V4.4//EN -file:///usr/share/xml/docbook/schema/dtd/4.4/docbookx.dtd +http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd; [] refentry diff --git a/mispipe.docbook b/mispipe.docbook index bd8faa8..6d0d758 100644 --- a/mispipe.docbook +++ b/mispipe.docbook @@ -21,7 +21,7 @@ with this program; if not, write to the Free Software Foundation, Inc., -- !DOCTYPE refentry PUBLIC -//OASIS//DTD DocBook V4.4//EN -file:///usr/share/xml/docbook/schema/dtd/4.4/docbookx.dtd +http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd; [] refentry diff --git a/parallel.docbook b/parallel.docbook index d3ffcce..b5d438d 100644 --- a/parallel.docbook +++ b/parallel.docbook @@ -7,7 +7,7 @@ Written by Joey Hess -- !DOCTYPE refentry PUBLIC -//OASIS//DTD DocBook V4.4//EN -file:///usr/share/xml/docbook/schema/dtd/4.4/docbookx.dtd +http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd; [] refentry diff --git a/pee.docbook b/pee.docbook index f6a8441..850b9bd 100644 --- a/pee.docbook +++ b/pee.docbook @@ -21,7 +21,7 @@ with this program; if not, write to the Free Software Foundation, Inc., -- !DOCTYPE refentry PUBLIC -//OASIS//DTD DocBook V4.4//EN -file:///usr/share/xml/docbook/schema/dtd/4.4/docbookx.dtd +http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd; [] refentry diff --git a/sponge.docbook b/sponge.docbook index daab8eb..474155e 100644 --- a/sponge.docbook +++ b/sponge.docbook @@ -21,7 +21,7 @@ USA -- !DOCTYPE refentry PUBLIC -//OASIS//DTD DocBook V4.4//EN -file:///usr/share/xml/docbook/schema/dtd/4.4/docbookx.dtd +http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd; [] refentry -- 1.8.4.rc3 From 358982575411aa043de6dd47535de9833f916024 Mon Sep 17 00:00:00 2001 From: Peter Eisentraut pet...@debian.org Date: Sat, 2 Nov 2013 17:02:03 -0400 Subject: [PATCH 2/5] Fix invalid DocBook markup --- errno.docbook | 4 ++-- isutf8.docbook | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/errno.docbook b
Bug#728834: doesn't know how to open http links by default
Package: icedove Version: 24.0-1 Severity: normal I fresh icedove installation doesn't know how to open http links in emails. Instead, it requires me to use a file system dialog to dig my way down to /usr/bin/something, which is very unfriendly and slow. Given that Debian has a standard for this (x-www-browser), this could be configured by default. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#575294: fix for ifdata on OS X
Control: tags -1 + patch This patch will get ifdata building and working on OS X. diff --git a/ifdata.c b/ifdata.c index 031bc19..6d7ed6f 100644 --- a/ifdata.c +++ b/ifdata.c @@ -18,6 +18,11 @@ #include net/if.h #endif +#if defined(__APPLE__) + #define s6_addr16 __u6_addr.__u6_addr16 + #include net/if.h +#endif + #include netinet/in.h #include errno.h #include fcntl.h
Bug#728599: point pg_isready to latest version
Package: postgresql-common Version: 150 Severity: wishlist pg_isready should always be pointed to the latest version, same as psql is handled now. pg_isready does not depend on the server version. Also, since it is new in 9.3, running it against an older version sometimes gets complaints from pg_wrapper about the client not existing for old versions, which is confusing. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#728602: source tarball has all files read-only
Package: po4a Version: 0.45-1 Severity: minor Tags: upstream The source tarballs of this package have all files read-only. This is unusual and strange, because it makes it more cumbersome to edit any files. It is more normal to have all files 644 in a source tarball. Please look into this for the next upstream release. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#728607: consistent PREFIX support in build
Package: devscripts Version: 2.13.4 Severity: wishlist Some parts of the makefiles support setting the PREFIX variable and other variables to control the installation layout, but this is not consistently done. Here is a patch to make that consistent. This is useful to allow test installations etc. diff --git a/Makefile b/Makefile index 2907a5a..236cfaa 100644 --- a/Makefile +++ b/Makefile @@ -7,10 +7,6 @@ DESTDIR = PERL_MODULES = Devscripts EXAMPLES = conf.default README.mk-build-deps -PREFIX ?= /usr -DOCDIR ?= $(PREFIX)/share/doc/devscripts -MAN1DIR ?= $(PREFIX)/share/man/man1 - all: version make_scripts $(EXAMPLES) translated_manpages version: diff --git a/Makefile.common b/Makefile.common index 74aa252..75a0671 100644 --- a/Makefile.common +++ b/Makefile.common @@ -3,6 +3,11 @@ GEN_MAN1S := bts.1 build-rdeps.1 chdist.1 dcontrol.1 debcheckout.1 debcommit.1 \ mk-build-deps.1 namecheck.1 rmadison.1 svnpath.1 tagpending.1 \ origtargz.1 transition-check.1 who-permits-upload.1 -PERLMOD_DIR = /usr/share/devscripts -EXAMPLES_DIR = /usr/share/devscripts - +PREFIX = /usr +BINDIR = $(PREFIX)/bin +PKGLIBDIR = $(PREFIX)/lib/devscripts +DOCDIR = $(PREFIX)/share/doc/devscripts +MAN1DIR = $(PREFIX)/share/man/man1 +PERLMOD_DIR = $(PREFIX)/share/devscripts +EXAMPLES_DIR = $(PREFIX)/share/devscripts +SYSCONFDIR = /etc diff --git a/scripts/Makefile b/scripts/Makefile index d981b81..56a6a1a 100644 --- a/scripts/Makefile +++ b/scripts/Makefile @@ -24,10 +24,6 @@ COMPLETION = $(patsubst %.bash_completion,devscripts.%,$(COMPL_FILES)) GEN_MAN1S += devscripts.1 -BINDIR = /usr/bin -LIBDIR = /usr/lib/devscripts -BIN_LIBDIR = /usr/lib/devscripts - all: $(SCRIPTS) $(GEN_MAN1S) $(LIBS) $(CWRAPPERS) $(COMPLETION) $(VERSION_FILE): @@ -93,12 +89,12 @@ test: install: all python3 setup.py install --root=$(DESTDIR) --no-compile --install-layout=deb - install -dD $(DESTDIR)$(BINDIR) $(DESTDIR)$(LIBDIR) + install -dD $(DESTDIR)$(BINDIR) $(DESTDIR)$(PKGLIBDIR) cp $(SCRIPTS) $(DESTDIR)$(BINDIR) ln -sf edit-patch $(DESTDIR)$(BINDIR)/add-patch - cp $(LIBS) $(DESTDIR)$(LIBDIR) - install -dD $(DESTDIR)/etc/bash_completion.d - cp $(COMPLETION) $(DESTDIR)/etc/bash_completion.d + cp $(LIBS) $(DESTDIR)$(PKGLIBDIR) + install -dD $(DESTDIR)$(SYSCONFDIR)/bash_completion.d + cp $(COMPLETION) $(DESTDIR)$(SYSCONFDIR)/bash_completion.d # Special treatment for debpkg install -dD $(DESTDIR)$(PERLMOD_DIR) mv $(DESTDIR)$(BINDIR)/debpkg $(DESTDIR)$(PERLMOD_DIR)
Bug#723847: [Pkg-postgresql-public] Bug#723847: Bug#723847: Bug#723847: Bug#723847: postgresql-9.3: server - pg_upgradecluster - initdb: --data-checksums ?
On 10/19/13, 5:35 PM, Karsten Hilbert wrote: On Sat, Oct 19, 2013 at 02:05:34PM +0200, Christoph Berg wrote: What we could do is to add this as an example (comment) to the default version we ship for createcluster.conf. I would say that's better than the current situation. Also, what about a debonf question of medium priority ? Debconf is only for when no default is suitable and the user needs to make a decision. It's not for, hey, you might be interested in this configuration item. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#723847: [Pkg-postgresql-public] Bug#723847: Bug#723847: postgresql-9.3: server - pg_upgradecluster - initdb: --data-checksums ?
On Sat, 2013-10-12 at 11:09 +0200, Karsten Hilbert wrote: So, to rephrase the question: I wonder whether --data-checksums can be pre-set in /etc/postgresql-common/createcluster.conf's initdb_options ? It doesn't matter where you attach the option, the answer is the same: Upstream has decided that checksums should not be the default at this time. If you want to override that for the entire world of Debian, you need to come up with a good reason. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#723847: [Pkg-postgresql-public] Bug#723847: postgresql-9.3: server - pg_upgradecluster - initdb: --data-checksums ?
On 9/20/13 8:51 AM, Karsten Hilbert wrote: Package: postgresql-9.3 Version: 9.3~rc1-2 Severity: wishlist I wonder whether --data-checksums / -k can be made the default for creating new clusters starting with PG 9.3. It's an upstream decision, and it's not our place to override that. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#723470: libzdb link with -L/usr/lib
On 9/18/13 6:03 AM, Christoph Berg wrote: We will probaby do the multi-archification in a way that pg_config --libdir will continue to point to /usr/lib, because that's the location where the PostgreSQL modules are located. Only the client libraries (libpq5 and friends) will be moved. Modules are found via --pkglibdir. --libdir should point to libpq. (Arguably, pkg-config is a better way going forward.) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722649: dtrace leaves temporary files
Package: systemtap-sdt-dev
Version: 2.3-1
Severity: normal
Calling dtrace with the -C and -h options to generate a header file
from a *.d file leaves temporary files in /tmp. For example, take
this file probes.d:
provider test {
probe test();
};
Calling
dtrace -C -h -s probes.d -o probes.h
generates a file like /tmp/tmpzXuKas.d every time that is never
cleaned up.
I can reproduce this behavior in stable and testing.
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (101,
'experimental')
Architecture: i386 (i686)
Kernel: Linux 3.9-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages systemtap-sdt-dev depends on:
ii python 2.7.5-4
systemtap-sdt-dev recommends no packages.
systemtap-sdt-dev suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#720619: application/x-md5 etc. of dubious usefulness
On Sat, 2013-08-24 at 13:31 +0900, Charles Plessy wrote: Altogether, I do not see evidence that these media types do a service to our users, and I am ready to remove them. If the issue is pressing, I can upload a revised version of mime-support. Otherwise, I will wait for a larger-scale cleaning of non-registered media types (that start by x-). Not urgent. It would only be useful to me if it got into stable anyway, which isn't going to happen. Doing a general clean up of x- things sounds like the way to go. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#720619: application/x-md5 etc. of dubious usefulness
Package: mime-support Version: 3.54 Severity: normal Somewhere between squeeze and wheezy, media types application/x-md5 and application/x-sha1 were added. Many download services offer such files alongside tarballs for verification, and making such files application/* makes it harder for users to quickly view these files. It would be easier if they were under the text group. (This is not an uncommon problem if you search around the internet.) What were the reasons behind the current choice? I couldn't find anything in the change log. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (101, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.9-1-686-pae (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash mime-support depends on no packages. Versions of packages mime-support recommends: ii file 1:5.14-2 mime-support suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719282: installing dictionary package restarts postgresql servers
On Mon, 2013-08-12 at 10:53 +0200, Christoph Berg wrote: It might be smarter just to do nothing with the servers here, or just invoke reload, if necessary. (Or at least show a less frightening output on the console.) I think we could just call exit 0 after pg_updatedicts in postinst. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719282: installing dictionary package restarts postgresql servers
Package: postgresql-common Version: 147.pgdg70+1 Severity: normal Installing a dictionary package, for example apt-get install hunspell-de-de, ends up restarting all PostgreSQL servers on the machine, because the dictionary trigger calls postinst, which restarts everything because of the way debhelper sets this up. I think that's a fairly radical reaction. This might be more general problem. Maybe a fix in debhelper is needed? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719180: no documentation
Package: debugedit Version: 4.11.1-2 Severity: normal This package apparently has no documentation at all, apart from a brief --help message. There is no man page, no README file, and nothing easy findable on the web. The package description says it's supposed to be useful on its own, but I don't see how that is supposed to happen. Bug #717020 says something about dh_strip using it, but I don't see that either. Also, shouldn't the binary be in /usr/bin (possibly symlinked) if it's supposed to usable directly? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#710633: bison =2.6
This is related to bison. The issue starts with bison 2.6. Stable is OK. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717320: allow overriding logging options
Package: fop Version: 1:1.1.dfsg-2 Severity: wishlist I would find it useful to be able to override certain logging options such as org.apache.commons.logging.Log and org.apache.commons.logging.simplelog.defaultlog in .foprc. This is not possible for the former case, because LOG_OPTION is unconditionally set. Maybe you can put a if [ -z $LOG_OPTION ] or something like that around it. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717073: [Pkg-postgresql-public] Bug#717073: The libpq-dev package misses some dependencies
On 7/16/13 10:15 AM, Evgeni Golov wrote: Nope, the real issue is that pg_config is not pkg-config :) pg_config --help says --libsshow LIBS value used when PostgreSQL was built So it has nothing in common with pkg-config --libs pq (if that would exist) which will tell you which libs are needed to link with libpq. Yes, this is frequently misunderstood. PostgreSQL 9.3 will provide pkg-config support for libpq. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714725: [Pkg-postgresql-public] Bug#714725: Consider setting APT::NeverAutoRemove::postgresql-* in apt.conf
On 7/2/13 4:26 AM, Christoph Berg wrote: The question now is which package(s) should be marked as NeverAutoRemove. 1) The postgresql-x.y package of the (old)stable release 2) ^postgresql-[0-9]+-[0-9]$ 3) ^postgresql-.* 2) is probably equivalent to 1), as there's only one version in stable, and also easier to maintain, because we don't need to deal with changing the file, and partial upgrades. 3) would be needed if we decide that we also need to care about extension modules that should not be removed on dist-upgrade. (Though I tend to think these would usually be manually installed. But we might have the same metapackage-with-changing-dependency problem there as well.) It should be 3), because otherwise the postgresql-contrib-x.y package will be removed and you won't be able to dump your database if it uses any data type provided in a contrib module. The same goes for things like postgresql-x.y-ip4r. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714725: [Pkg-postgresql-public] Bug#714725: Consider setting APT::NeverAutoRemove::postgresql-* in apt.conf
On Tue, 2013-07-02 at 15:42 +0200, Christoph Berg wrote: Re: Peter Eisentraut 2013-07-02 51d2bd16.6020...@debian.org 3) would be needed if we decide that we also need to care about extension modules that should not be removed on dist-upgrade. (Though I tend to think these would usually be manually installed. But we might have the same metapackage-with-changing-dependency problem there as well.) It should be 3), because otherwise the postgresql-contrib-x.y package will be removed and you won't be able to dump your database if it uses any data type provided in a contrib module. The same goes for things like postgresql-x.y-ip4r. My thinking was that if you have any -contrib package installed, it will be marked as manually installed and won't be removed automatically anyway. Same for -ip4r and friends. Could be, but it's not guaranteed. Marking all postgresql-* packages for NeverAutoRemove might also be a bit overzealous, do we want to restrict this to postgresql-*$laststableversion*? Do we want to drop the NeverAutoRemove for $laststableversion once the cluster got upgraded? Marking only the stable version doesn't sound very reliable. If you want to guard the data, you have to do it independent of what the preferred version is. Users of apt.postgresql.org will have even more complex requirements. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#701339: known upstream bug
This issue is discussed here: http://www.postgresql.org/message-id/14242.1365200...@sss.pgh.pa.us Currently, there is no fixed upstream release for the older branches, but 9.2 is OK. So for jessie, the fix is to move to 9.2 or 9.3, and remove 9.1 and whatever may be left of 8.4. For compiling older versions on jessie (e.g., apt.postgresql.org), the thread discusses workarounds. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#710471: broken symlink /usr/lib/jvm/java-1.5.0-gcj
Package: gcj-jre-headless Version: 4:4.7.2-1 Severity: important This package contains the broken symlink /usr/lib/jvm/java-1.5.0-gcj - java-1.5.0-gcj-4.7 The correct target is presumably /usr/lib/jvm/java-1.5.0-gcj-4.7-i386 (with the architecture). -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (101, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gcj-jre-headless depends on: ii gcj-4.7-jre-headless 4.7.3-2 ii libgcj-common 1:4.6.3-8 gcj-jre-headless recommends no packages. Versions of packages gcj-jre-headless suggests: ii gcj-jdk 4:4.7.2-1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#701341: gcj packaging bug
This has nothing to do with gcc 4.8. It's a gcj packaging bug: #710471. pljava currently fails to build with gcj 4.7 as well. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705652: add support for repo
Package: mr
Version: 1.14
Severity: wishlist
Tags: patch
Here is a file that can be installed at /usr/share/mr/repo to add
support for the repo tool. Or it could be put into mr proper, don't
know what the threshold for that is.
# Adds support for repo repositories.
# To make mr use this file, add a line like this inside the [DEFAULT]
# section of your ~/.mrconfig
#include = cat /usr/share/mr/repo
repo_test = perl: -d $ENV{MR_REPO}/.repo
repo_diff = repo diff $@
repo_grep = repo grep $@
repo_status = repo status $@
repo_update = repo sync $@
Bug#705652: add support for repo
On Wed, 2013-04-17 at 22:22 -0400, Joey Hess wrote: Peter Eisentraut wrote: Here is a file that can be installed at /usr/share/mr/repo to add support for the repo tool. Or it could be put into mr proper, don't know what the threshold for that is. Can you provide a link to the tool? http://source.android.com/source/version-control.html (It's not only used for Android, however.) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704802: [Pkg-postgresql-public] Bug#704802: plperl crashes immediately on kfreebsd
On Mon, 2013-04-08 at 10:15 +0200, Christoph Berg wrote:
Re: Peter Eisentraut 2013-04-06
20130406030939.14051.80312.report...@vanquo.pezone.net
Package: postgresql-plperl-9.1
Version: 9.1.9-1
Severity: important
Creating a plperl function on kfreebsd (amd64) immediately crashes the
PostgreSQL server in the plperl.so module. You can see this either by
running the built-in regression tests (should probably be done during
the build anyway) or by running the tests from
t/020_create_sql_remove.t in the postgresql-common package.
Unfortunately the postgresql-common tests need root, so we can't run
these at build time.
I meant the regression tests that ship with upstream.
(Getting the postgresql-common tests running on kfreebsd is a whole
another matter -- we'll get to that next. ;-) )
I'd favor activating as many regression tests as possible at build
time. I was looking into that some time ago but somehow got lost
between the isolation tests and similar more academic tests.
Should be pretty simple: Just run make check-world. I think the current
stuff in debian/rules was written before check-world was invented.
Something like the attached patch (not fully tested) should do the job.
diff -Nru postgresql-9.1-9.1.9/debian/rules postgresql-9.1-9.1.9/debian/rules
--- postgresql-9.1-9.1.9/debian/rules 2013-04-02 04:27:35.0 -0400
+++ postgresql-9.1-9.1.9/debian/rules 2013-04-05 21:24:50.0 -0400
@@ -138,15 +138,13 @@
set -e; \
patch --no-backup-if-mismatch -p1 debian/disable-root-check.patch; \
patch --no-backup-if-mismatch -p1 debian/pg_regress-in-tmp.patch; \
- make -C build/src/test/regress bigcheck || fail=1; \
+ make -C build -k check-world || fail=1; \
patch --no-backup-if-mismatch -Rp1 debian/pg_regress-in-tmp.patch; \
patch --no-backup-if-mismatch -Rp1 debian/disable-root-check.patch; \
if [ -n $$fail ]; then \
- for l in regression.diffs log/initdb.log log/postmaster.log; do \
- if [ -e build/src/test/regress/$$l ]; then \
- echo * $$l ***; \
- cat build/src/test/regress/$$l; \
- fi; \
+ for l in `find build -name regression.diffs -o -name initdb.log -o name postmaster.log`; do \
+ echo * $$l ***; \
+ cat $$l; \
done; \
$(TESTSUITE_FAIL_CMD); \
fi
@@ -155,36 +153,5 @@
override_dh_strip:
dh_strip --dbg-package=postgresql-$(MAJOR_VER)-dbg
-# run tests in contrib in temporary test installations, using programs
-# from local tree
-contrib-check:
- set -e; cd build/contrib; \
- for d in *; do \
- [ -d $$d/sql ] || continue; \
- echo == Running tests in $$d; \
- (cd $$d; \
- if ! ../../src/test/regress/pg_regress --top-builddir=../.. --temp-install=tmp_check --dbname=contrib_regression `cd sql; ls *.sql | sed 's/.sql$$//'`; then \
- cat regression.diffs; \
- fi); \
- done
-
-# run tests in contrib in temporary test installation, using programs
-# from system installation
-contrib-installcheck:
- # set up temporary db
- rm -rf tmp_data
- mkdir tmp_data
- /usr/lib/postgresql/$(MAJOR_VER)/bin/initdb -D tmp_data
- /usr/lib/postgresql/$(MAJOR_VER)/bin/pg_ctl -D tmp_data -l tmp_data/postgres.log -o '-k /tmp' start
- # wait until it started up
- while !/usr/lib/postgresql/$(MAJOR_VER)/bin/psql -h /tmp -l /dev/null 21; do sleep 1; done
- sleep 1
- while !/usr/lib/postgresql/$(MAJOR_VER)/bin/psql -h /tmp -l /dev/null 21; do sleep 1; done
- # run the tests
- -cd build/contrib; make installcheck
- /usr/lib/postgresql/$(MAJOR_VER)/bin/pg_ctl -D tmp_data stop
- # find and print the regression diffs
- find build/contrib/ -name regression.diffs -exec cat '{}' \;
-
override_dh_builddeb:
dh_builddeb -- -Zxz
Bug#704802: plperl crashes immediately on kfreebsd
Package: postgresql-plperl-9.1 Version: 9.1.9-1 Severity: important Creating a plperl function on kfreebsd (amd64) immediately crashes the PostgreSQL server in the plperl.so module. You can see this either by running the built-in regression tests (should probably be done during the build anyway) or by running the tests from t/020_create_sql_remove.t in the postgresql-common package. Everything else works, including all the other procedural languages (Python, Tcl). I can also reproduce this problem with PostgreSQL Git master, so it's not specific to the packaging. The actual problem might be somewhere down the stack (libperl etc.). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678979: request freeze exception for slony1-2
On 3/19/13 2:48 PM, Steve Singer wrote: Since the original bug was opened we've figured out why adding PG 9.1 support to slony 2.0.x was causing occasional test failures. The fixes for PG 9.1 (upstream bugs #255) along with the fixes for the MOVE SET issue caused by the #255 fix (upstream bug #285) I think will produce a working slony 2.0.x against 9.1. If Debian would like I can assemble assemble these two patches and run it through the testing suite. Sure, if it's only two isolated patches that upstream is endorsing, we can give this a try. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678979: request freeze exception for slony1-2
On Sat, 2013-03-16 at 11:38 +, Adam D. Barratt wrote: On Sun, 2012-10-07 at 14:30 +0200, Mehdi Dogguy wrote: On 21/09/2012 04:58, Peter Eisentraut wrote: According to bug #678979 [0], which was submitted by the lead upstream developer, slony 2.0 does not work well with postgresql 9.1. Therefore, we had to resolve to making an upgrade to slony version 2.1, and I request that that be allowed into wheezy now. [...] Unfortunately, we are not able to accept such large changes at this stage of the freeze. [2] Since slony in Debian have little popcon, does it make sense to skip the Wheezy release? iow, remove slony from wheezy (since it doesn't work and we are not able to accept the new one). Alternatively, we could very well accept a targeted fix based on current Wheezy's version… (correct me if I'm wrong), the discussion in #678979 made me think that it was not possible to extract a minimal patch. Ping? As far as I'm concerned, the matter is closed. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#694719: me too
I'm getting the same error message as of very recently. But I get it soon after the browser starts. Something is fishy. For example, custom search key words are not recognized. Extensions seem to work, though. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695979: reports Py_ENABLE_SHARED as 0
Package: python2.7-minimal
Version: 2.7.3~rc2-2.1
Severity: normal
python -c import distutils.sysconfig;
print(distutils.sysconfig.get_config_var('Py_ENABLE_SHARED'))
prints 0, but should print 1, because a shared library is built.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674116: dirmngr: init script does not write pid into the pid file
On Wed, 2012-12-05 at 19:58 +0100, John Paul Adrian Glaubitz wrote: the issue only occurs if the local bash profile contains any echo statements: I think the only answer to that is: Don't do that then. I think you will be able to find many shell scripts that will be unhappy about this. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
