Bug#1069294: [PATCH] install emacs-nox desktop file

Package: emacs-nox Version: 1:29.3+1-1 Tags: patch A minor typo in debian/rules installs the emacs.term-desktop file in the wrong location for emacs-nox. It appears to be a simple typo (copy-and-paste error). Compare the entries in /usr/share/applications of:

Bug#1068124: exec-path-from-shell-el 2.1-1 FTBFS if network is unavailable

Package: exec-path-from-shell-el Version: 2.1-1 Tags: patch The upstream Makefile attempts to run some sanity checks on the library, including running `package-lint`, which it attempts to download via `package.el`. This fails when the build daemon does not have network access: *

Bug#1067238: Add support for man preprocessors, like tbl

On Thu, 21 Mar 2024 at 03:27, Faidon Liambotis wrote: > In trixie and above, including tables in a manpage does not work > anymore, unless the "tbl" preprocessor is added explicitly. [...] I'm not aware of a change to help2man which would have affected this, so I'm assuming that it is a

Bug#1006193: Remove luit, now packaged separately

On Sun, Nov 12, 2023 at 04:39:30PM -0500, Thomas Dickey wrote: >On Wed, Mar 02, 2022 at 03:09:37PM -0500, Thomas Dickey wrote: >While this has been applied, it's not moving along because the related >version x11-utils (7.7+6) has not gone into testing yet - more than a year. It hasn't reached

Bug#1032651: vile FTCBFS: broken cross-compilation specific autoconf test

On Mon, Mar 13, 2023 at 11:03:11AM +0100, Helmut Grohne wrote: >On Sat, Mar 11, 2023 at 08:24:40AM +1100, Brendan O'Dea wrote: >> This was fixed in 9.8y-2 (closing #1029956). > >This is partially correct. The bug was closed. The actual problem was >fixed at the root indeed. But

Bug#1032651: vile FTCBFS: broken cross-compilation specific autoconf test

tags 1032651 unreproducible thanks On Fri, Mar 10, 2023 at 12:24:26PM +0100, Helmut Grohne wrote: >Source: vile >Version: 9.8y-2 > >vile fails to cross build from source, because the cross-compilation >specific test contains a syntax error. This will become obvious once >looking at the attached

Bug#1024997: install-info: dir entry for emacs is bolloxed

On Mon, Jan 30, 2023 at 10:37:00AM +0100, Hilmar Preuße wrote: >Am 30.01.2023 um 06:51 teilte Brendan O'Dea mit: >> This is still present in the unstable version of the package. You >> should probably keep this open until 7.0 gets to unstable. >> >IIRC the Debian BTS is b

Bug#1024997: install-info: dir entry for emacs is bolloxed

reopen 1024997 ! thanks On Mon, Nov 28, 2022 at 11:46:49PM +0100, Hilmar Preuße wrote: >Version: 7.0-1 > >Am 28.11.2022 um 23:28 teilte Barak A. Pearlmutter mit: > >> Yes! That fixes it. >> >Closing then. This is still present in the unstable version of the package. You should probably keep

Bug#1012474: [PATCH] Xsession does not recognise shell builtins as session-type

Package: x11-common Version: 1:7.7+23 Severity: normal Tags: patch X-Debbugs-Cc: b...@debian.org A recent change[1] to 20x11-common_process-args causes "/etc/X11/Xsession true" to pop up an xmessage error, followed by running the default session. The default xpra configuration contains such an

Bug#1006193: Remove luit, now packaged separately

Package: x11-utils Version: 7.7+5 Severity: normal Tags: patch X-Debbugs-Cc: b...@debian.org Merge request to remove luit from x11-utils: https://salsa.debian.org/xorg-team/app/x11-utils/-/merge_requests/1 now packaged separately, this commit removes luit and adds a recommends for the new

Bug#894126: help2man: Problem with encoding kk_KZ.RK1048

On Wed, Jan 05, 2022 at 02:54:48PM +0100, Marcus Hardt wrote: >I'm experiencing the same problem every now and then, because reprotest >uses this encoding to verify reproducible builds. > >The problem seems to be triggered by setting this environment: > >LANG=kk_KZ.RK1048 >LANGUAGE=kk_KZ.RK1048:fr

Bug#1004660: [PATCH] lintian-annotate-hints: line-wrapping broken when stdin is not a terminal

Package: lintian Version: 2.114.0 Severity: normal Tags: patch When lintian-annotate-hints reads input from a file, or has lintian ouput piped to it (as is suggested in the manual), the terminal width is unset, which produces warnings to stderr and wrapping at 19 colums: % lintian *.dsc

Bug#1002990: ITS: byacc

[+m...@qa.debian.org] On Sun, Jan 02, 2022 at 05:05:20AM -0500, Thomas Dickey wrote: >Package: byacc >Version: 20220101 >Severity: important > >Dear Maintainer, > > * byacc package has not been updated in Debian since 2014. > * sent email to package maintainer (December 4, 2021) > * package

Bug#972741: help2man: version-string too restrictive, needs to allow empty version

severity 972741 wishlist thanks On Fri, Oct 23, 2020 at 11:29:28AM +0800, Drew Parsons wrote: >help2man is too restrictive with regards to the version string. Often >a program does not support the --version flag at all, but help2man >does not handle that tidily. The only way you can manage that

Bug#958345: help2man generates invalid .TH line for pasdoc

On Tue, 21 Apr 2020 at 04:39, Paul Gevers wrote: > Package: help2man > Version: 1.47.13 > Severity: normal > > change in the output of help2man. dh_installman determines the section > based on the .TH line. [...] Sorry, unintended consequence of a recent change. I've reverted that mostly for

Bug#953604: vile: Mismatched source format vs source version

On Wed, Mar 11, 2020 at 12:57:59AM +0100, Guillem Jover wrote: >From the historical data in snapshot.debian.org, this would appear as >the build was done with a missing orig so dpkg-source considered it a >native format? Thanks for the report, and the pointer to the possible cause. Indeed, this

Bug#948403: help2man: Produces man pages with warnings that cause lintian check to fail

On Sat, Jan 11, 2020 at 08:45:10PM +1100, Brendan O'Dea wrote: >[...] I've attached a shell script which outputs an amended --help text for >qmi-firmware-update which may work better. Use "help2man X | man -l -" to >test, where "X" is the filename you save

Bug#948403: help2man: Produces man pages with warnings that cause lintian check to fail

On Wed, Jan 08, 2020 at 08:26:22AM +, Bob Ham wrote: >I'm creating a package of an updated version of libqmi which uses >help2man to generate its man pages. Unfortunately, the resulting man >pages have issues which cause lintian checks for the package to fail: > >W: libqmi-utils:

Bug#934601: help2man: FTBFS when binNMUed

Ah, never mind me. It was the very last change I made that seems to have tickled this problem. Uploading shortly. On Mon, 12 Aug 2019 at 22:19, Brendan O'Dea wrote: > This is due to a sanity check that I've added to ensure that everything is > prepared for an "upstream" releas

Bug#934601: help2man: FTBFS when binNMUed

This is due to a sanity check that I've added to ensure that everything is prepared for an "upstream" release to both Debian and GNU. This is the first time in ~16 years of the package containing an arch-specific binary that I've come across a case where a bin-NMU has been required for help2man.

Bug#932560: vile: Don't build against flex-old

On Sat, Jul 20, 2019 at 01:10:19PM -0400, Thomas Dickey wrote: >Actually it's debatable whether flex "new" is maintained. I did a test build against the current version (2.6.4), and it no longer has the issue[0] which caused me to revert to flex-old some time ago. Some brief testing of a handful

Bug#930653: libapt-pkg-perl: Port to apt 1.9.0

On Mon, Jun 17, 2019 at 06:47:53PM +0200, Julian Andres Klode wrote: >Package: libapt-pkg-perl >Version: 0.1.34 >Ports libapt-pkg-perl to apt 1.9.0 (coming soon to experimental), this > >removes: > >- IsOk() method of a PkgFileIterator >- GetMatch() method of a Policy >- GetPriority(Package) of

Bug#925136: help2man: FTBFS in unstable (dh_clean fails)

On Fri, Mar 22, 2019 at 05:42:37PM +0100, Sven Joachim wrote: >On 2019-03-21 20:45 +1100, Brendan O'Dea wrote: >> I suspect that it is related to reproducible builds, [...] >There has indeed been such a change in dpkg-source: > >, >| - Generate reproducible source tarb

Bug#925136: help2man: FTBFS in unstable (dh_clean fails)

On Wed, Mar 20, 2019 at 10:21:39AM +0100, Gianfranco Costamagna wrote: >Looks like README needs a newer timestamp wrt help2man.PL file? [...] >dpkg-buildpackage: info: host architecture amd64 > fakeroot debian/rules clean >test README -nt help2man.PL # maintainer sanity check >make: ***

Bug#894126: help2man: Problem with encoding kk_KZ.RK1048

On Mon, Mar 26, 2018 at 01:05:21PM -0300, Iñaki Malerba wrote: >Found a bug while running reprotests with the kk_KZ.RK1048 LC_ALL option > >How to reproduce: >``` ># LC_ALL=kk_KZ.RK1048 help2man >Unknown encoding 'RK1048' at /usr/bin/help2man line 56. >``` Unfortunately, Perl's Encode module does

Bug#682347: mark 'editor' virtual package name as obsolete

On Wed, Aug 23, 2017 at 11:03:23PM -0700, Russ Allbery wrote: >Would anyone on the Policy list or any of the maintainers bcc'd want to >make a case for keeping the virtual package "editor"? No strong objection to removing this virtual package. >In previous discussions, no one seemed to feel that

Bug#872391: libapt-pkg-perl: Please provide Uploaders in AptPkg::Source

On 17 August 2017 at 12:25, Norbert Preining wrote: > I am writing a tool for generating graph database from the apt cache, > but I am missing access to the uploaders in AptPkg::Source. Unfortunately that field is not exposed in the underlying libapt-pkg library. The best I

Bug#869541: lintian warns both with and without autotools-dev build-dep

Package: lintian Version: 2.5.52 I added calls to dh_autotools-dev_{update,restore}config to the debian/rules for vile* in order to update/restore the config.guess/config.sub. I added a versioned build-dependency for the version of autotools-dev which added these commands: autotools-dev (>=

Bug#851951: AptPkg::Cache: installed packages in TriggersAwaited or TriggersPending state have no CurrentState() at all!

merge 851951 852273 thanks On Fri, Jan 20, 2017 at 06:22:35PM +0800, Michael Deegan wrote: >It looks like (according to a brief grep through the source) AptPkg hasn't >been updated since dpkg gained triggers. Right, it hasn't been changed for some time. I'll take a look at the triggers. >The

Bug#833656: cme fails with dpkg error

reassign -1 lintian 2.5.45 thanks On Sun, Aug 14, 2016 at 01:00:33PM +0200, David Kalnischkies wrote: >On Sun, Aug 14, 2016 at 05:27:39PM +1000, Brendan O'Dea wrote: >> which suggests that the _config object has been modified prior to this code >> being run. Not sure

Bug#833656: cme fails with dpkg error

On Sun, Aug 14, 2016 at 12:36:03AM +0200, gregor herrmann wrote: >use AptPkg::Config '$_config'; >use AptPkg::System '$_system'; >use AptPkg::Version; >use AptPkg::Cache ; > >$_config->init; >$_system = $_config->system; >my $vs = $_system->versioning; >my $apt_cache = AptPkg::Cache->new ; This

Bug#832973: vile-filters: vile filter for mail broken

On Tue, Aug 02, 2016 at 09:30:38PM -0400, Thomas Dickey wrote: >(got to that point - attaching a diff which built with 2.6.0) I'm not entirely convinced that this change captures what you're trying to achieve with 2.6.0, as the second expression to sed makes LEX_SUBVERSION in this case equal to

Bug#832973: vile-filters: vile filter for mail broken

On Mon, Aug 01, 2016 at 02:41:12AM -0400, Thomas Dickey wrote: >On Mon, Aug 01, 2016 at 04:22:37PM +1000, Brendan O'Dea wrote: >> configure.in doesn't cope with 2.6: >> >> sed -e 's/^2.5.// >> >> resulting in this output from configure: >>

Bug#832973: vile-filters: vile filter for mail broken

On Sun, Jul 31, 2016 at 03:40:14PM -0400, Thomas Dickey wrote: >I normally don't build with "new" flex, but took a look today and had >no problem building with the version in testing (which appears to match >that in experimental). > >What is the problem that you are seeing when building? The

Bug#832973: vile-filters: vile filter for mail broken

The problem appears to be that flex is now version 2.6.0, which configure doesn't appear to handle. I'll revert to the older flex for now. On 30 July 2016 at 21:44, Paul van Tilburg wrote: > Package: vile-filters > Version: 9.8r-1 > Severity: normal > > Dear Maintainer, > >

Bug#832973: Acknowledgement (vile-filters: vile filter for mail broken)

On 30 July 2016 at 22:34, Paul van Tilburg wrote: > It seems that (almost) all filters are broken. > All miss the _wrap symbol? Not all: vile @/usr/share/vile/filters.rc /tmp/foo.cc for example, highlights fine. But you're right: there is clearly something awry,

Bug#787444: [Reproducible-builds] Bug#787444: Bug#787444: help2man: support externally-supplied --date for reproducibility

On 10 June 2015 at 01:59, Ximin Luo infini...@pwned.gg wrote: Given the above, I think it would still be good to define SOURCE_DATE as I originally suggested: SOURCE_DATE = $(date -d $(dpkg-parsechangelog --count 1 -SDate) --iso-8601=seconds) # includes the TZ offset - if the

Bug#787444: [Reproducible-builds] Bug#787444: Bug#787444: Bug#787444: help2man: support externally-supplied --date for reproducibility

On 10 June 2015 at 20:54, Ximin Luo infini...@pwned.gg wrote: On 10/06/15 12:41, Brendan O'Dea wrote: On 10 June 2015 at 01:59, Ximin Luo infini...@pwned.gg wrote: SOURCE_DATE = $(date -d $(dpkg-parsechangelog --count 1 -SDate) --iso-8601=seconds) # includes the TZ offset The TZ offset

Bug#787444: [Reproducible-builds] Bug#787444: help2man: support externally-supplied --date for reproducibility

On 5 June 2015 at 21:12, Ximin Luo infini...@pwned.gg wrote: If we're going to mandate that it ends with Z, might I suggest that we add UTC or _UTC to the variable name? It leaves the option open in the future that we might allow TZ offsets. Note that the TZ offsets mentioned in ISO8601 and

Bug#787444: [Reproducible-builds] Bug#787444: help2man: support externally-supplied --date for reproducibility

On 5 June 2015 at 04:40, Ximin Luo infini...@pwned.gg wrote: On 04/06/15 19:30, Daniel Kahn Gillmor wrote: What TZ should SOURCEDATE have? ISO8601 is capable of supplying a TZ as well, so the current time could be written in a wide variety of ways while meaning the same instant: 0

Bug#787444: help2man: support externally-supplied --date for reproducibility

On 4 June 2015 at 00:19, Daniel Kahn Gillmor d...@fifthhorseman.net wrote: On Wed 2015-06-03 08:24:51 -0400, Brendan O'Dea wrote: My inclination is instead to do something fairly specific to your project: If the environment variable DEB_BUILD_CHANGELOG (or something similar) is set

Bug#787444: help2man: support externally-supplied --date for reproducibility

On 2 June 2015 at 04:49, Daniel Kahn Gillmor d...@fifthhorseman.net wrote: Please consider the attached patch as a step on the way toward allowing packages that use help2man to build reproducibly. For more info, see: Hi Daniel, I appreciate that you've provided a relatively generic solution

Bug#601600: package protobuf-mode.el

+++ b/debian/changelog @@ -1,3 +1,10 @@ +protobuf (2.6.1-2) unstable; urgency=medium + + * Split protobuf-mode.el into a separate package (closes: #601600.) + * Work around emacs bug #18845 when byte compiling protobuf-mode.el. + + -- Brendan O'Dea b...@debian.org Mon, 24 Nov 2014 21:53:54 +1100

Bug#757891: init-system-helpers: Please do not depend on perl

On 13 August 2014 17:11, Michael Stapelberg stapelb...@debian.org wrote: Brendan O'Dea b...@c47.org writes: I think an increase of 150 KiB is perfectly fine when it frees us from unnecessary reimplementation work, whose only potential outcome is to introduce new bugs :). Sure, although

Bug#757891: init-system-helpers: Please do not depend on perl

On 13 August 2014 05:15, Niko Tyni nt...@debian.org wrote: [cc'ing the rsyslog maintainers too] On Tue, Aug 12, 2014 at 09:02:59AM +0200, Michael Stapelberg wrote: Samuel Thibault sthiba...@debian.org writes: perl is separate from perl-base so that in tight environement, Debian can be

Bug#739249: dh_perl support for packages embedding perl

On 17 February 2014 13:20, Marco d'Itri m...@linux.it wrote: Package: debhelper The inn and inn2 packages, which use an embedded perl interpreter, currently do this to express a proper dependency on perlapi-* (see #182089): dh_gencontrol -u-VPERLAPI=$$(perl -MConfig -e 'print

Bug#712613: libapt-pkg-perl: Size,InstalledSize fields missing

On 18 June 2013 07:38, Kevin Ryde use...@zip.com.au wrote: The Size and InstalledSize fields from a package Version object seem to have been lost in this change, http://anonscm.debian.org/gitweb/?p=users/bod/libapt-pkg-perl.git;a=commitdiff;h=03ae8d187f3081ebfbd05a2412d187a09d349d15

Bug#708027: closed by Brendan O'Dea b...@debian.org (Bug#708027: fixed in vile 9.8j-2)

On 21 May 2013 06:09, Dominic Hargreaves d...@earth.li wrote: Regrettably we don't seem to be quite there yet: vile-perl-api.pod around line 1266: =over without closing =back POD document had syntax errors at /usr/bin/pod2text line 84. Sorry Dominic, I just fixed the errors listed and didn't

Bug#707142: libapt-pkg-perl: AptPkg::Cache can't iterate installed packages from foreign architectures

On 8 May 2013 04:55, Andrew Ayer b...@mm.beanwood.com wrote: AptPkg::Cache exhibits some strange behavior with its hash iteration on multi-arch systems. [...] Thanks for the report Andrew, you are quite correct that the multi-arch support is broken in this respect. The correct solution is

Bug#701899: libapt-pkg-perl: Doesn't give long description

On Thu, Feb 28, 2013 at 04:03:18PM +, jep wrote: On a fresh installation of wheezy (netinst RC1 on amd64), when I ask this Perl module to get a package's long description, it gets the short description instead: [...] I suspect this is because long descriptions are no longer kept in the

Bug#563250: xvile: Warning: Cannot convert string lucidasans-10 to type FontStruct

On 15 May 2012 15:12, Jonathan Nieder jrnie...@gmail.com wrote: The Lucida fonts are in the xfonts-75dpi and xfonts-100dpi packages. Does installing both those packages remove the error for you? Thanks for the quick reply.  No, alas.  $ dpkg -l xfonts-75dpi xfonts-100dpi xfonts-scalable  

Bug#563250: xvile: Warning: Cannot convert string lucidasans-10 to type FontStruct

On 15 May 2012 06:36, Jonathan Nieder jrnie...@gmail.com wrote: xvile emits the following message whenever I run it: | Warning: Cannot convert string lucidasans-10 to type FontStruct Sorry Jonathan, I didn't see the original bug--I think that probably went to Paul (I've since changed the

Bug#657293: help2man and command with dash in the name

On 25 January 2012 21:57, Mathieu Malaterre mathieu.malate...@gmail.com wrote: Package: help2man Version: 1.40.5 Severity: normal It would be nice if help2man would support generating man page from command with - (dash) in the name. help2man uses the regular expression \S+ to identify the

Bug#656242: perl: .packlist file missing

On 20 January 2012 20:02, Niko Tyni nt...@debian.org wrote: This is a very longstanding Debian deviation for both the core and the vendor directories. I can't easily find the full rationale and this was way before my time, so I'm taking the debian-perl list in the loop. I hope the discussion

Bug#479681: Perl symbol problem - release critical (Re: Bug#489132)

On 2 June 2011 20:56, Niko Tyni nt...@debian.org wrote: Reviewing the discussion, I think that Ian had a valid point and that we should revisit the vendorarch directory choice. Brendan (cc'd): I'd love to have your thoughts on this. vendorarch was chosen for simplicity, and consistency with

Bug#625963: vile: FTBFS on armel and s390 (hangs in configure?)

On Sat, May 07, 2011 at 02:20:33PM +0200, Julien Cristau wrote: See https://buildd.debian.org/status/package.php?p=vile The configure failed at different points for both armel and s390, but there is nothing particularly exceptional about either test, moreover this exact source package has

Bug#624401: help2man: [INTL:de] Updated German translation

On 28 April 2011 17:18, Chris Leick c.le...@vollbio.de wrote: please find attached the updated German translation of help2man. Thanks Chris, applied. I also added a small unrelated correction as previously suggested by another (see

Bug#620250: help2man: [INTL:fr] French translation update

On 1 April 2011 01:29, David Prévot da...@tilapin.org wrote: Please find attached the French translation updated, proofread by the debian-l10n-french mailing list contributors. Please note that, following your advise on #590580, I've already submit this version to translationproject.org: I

Bug#590580: help2man: [INTL:fr] French translation update

On 8 January 2011 08:07, David Prévot da...@tilapin.org wrote: I'll sure take care of that as soon as I send the disclaimer to the FSF (I fail to understand its purpose), or when you stop require it. The copyright to help2man has been assigned to the FSF, and as they require this disclaimer[0]

Bug#590580: help2man: [INTL:fr] French translation update

On 27 July 2010 23:58, David Prévot da...@tilapin.org wrote: Please find attached the French translation updated, proofread by the debian-l10n-french mailing list contributors. Thanks David, I have included this translation in the latest release. Could you please also submit this version to

Bug#579457: debian-policy: finer granularity for perlapi-*

On Fri, May 07, 2010 at 07:16:32PM +0300, Niko Tyni wrote: Final version with the nonzero thing removed. I'm looking for seconds. diff --git a/perl-policy.sgml b/perl-policy.sgml index 1d26df7..1ee5df5 100644 --- a/perl-policy.sgml +++ b/perl-policy.sgml @@ -89,8 +89,11 @@ /p p

Bug#579457: debian-policy: finer granularity for perlapi-*

On 6 May 2010 23:26, Niko Tyni nt...@debian.org wrote: I was trying to cater for the degenerate case of $Config{debian_abi}=0 (which breaks the above short-circuit form) so dependants wouldn't have to check for that. Sure, but this is not an arbitrary string which may accidentally contain 0.

Bug#579457: debian-policy: finer granularity for perlapi-*

I would like to include these settings in the virtual package name so that it would be possible to make incompatible ABI changes during the life time of a single Perl upstream version and have a clean transition path. As for the implementation, the name of the virtual package could be derived

Bug#579457: debian-policy: finer granularity for perlapi-*

On 6 May 2010 04:57, Niko Tyni nt...@debian.org wrote: Update: this formulation avoids an unnecessary patch to the perl package until the ABI is actually changed. It also allows debhelper and the few other affected packages to easily stay compatible with older perl package versions. I'm

Bug#571812: help2man

On Mon, Mar 1, 2010 at 9:19 AM, Will Daniels deb...@willdaniels.co.uk wrote: My apologies, it does not have to do with the path prefixing the command name, it seems the problem was that the help output does not begin with a description line and just starts with Usage. I must have gotten things

Bug#571812: help2man: can't cope with path prefix (Usage: /usr/bin/foo bar)

On Sun, Feb 28, 2010 at 6:36 PM, Will Daniels deb...@willdaniels.co.uk wrote: Package: help2man Version: 1.36.4+nmu1 Severity: minor I have an upstream bin that outputs the path of the command after Usage: in --help (i.e. Usage: /usr/bin/oauth [options]... which causes help2man to take

Bug#564668: libapt-pkg-perl should have a function to view upgradable packes

On Mon, Jan 11, 2010 at 2:16 PM, William Orr w...@worrbase.com wrote: I'm working on a patch for apt-build, and it would be really nice to have a function that returns upgradable packages. Using AptPkg::Policy works unless apt pinning is used. In what way does it not work? On a system with

Bug#552797: perl: dpkg-shlibdeps fails on suid-perl on i386

On Wed, Oct 28, 2009 at 7:13 PM, Niko Tyni nt...@debian.org wrote:  http://git.debian.org/?p=perl/perl.git;a=commitdiff;h=063f225d0fdeca563c7906927fc30171c3684f70 This makes sure the script runs with the system perl and not the new one. Note that one of the reasons why perl has a slightly

Bug#547154: help2man: [INTL:DE] Initial German translation

On Thu, Sep 17, 2009 at 7:49 PM, Chris Leick c.le...@vollbio.de wrote: Please find the initial German translation help2man attached. Would it be possible to also get a translation of the help2man.h2m file also please? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with

Bug#546863: libapt-pkg-perl: Does not expose architecture conditions for build dependencies

On Wed, Sep 16, 2009 at 5:58 PM, Frans Pop elen...@planet.nl wrote: AFAICT libapt-pkg-perl currently does not expose these architecture conditions in the BuildDepends hash. Would it be possible to add this? Not easily, these architecture-specific entries are filtered by the underlying

Bug#536384: perl-modules must depend on perl-base (= 5.10.0-24) or ship the changelog.Debian.gz

On Mon, Aug 17, 2009 at 7:01 AM, Niko Tynint...@debian.org wrote: There are ways around that, have the perl package provide a name which maps to the debian version less NMUs (either by manually updating debian/control, or an automated process which removes bin NMUs from the version). As

Bug#542137: perl-doc: No description of changes for version 5.10.0-25 in changelog.Debian.gz

On Tue, Aug 18, 2009 at 12:02 PM, Dave Witbrodtdawit...@sbcglobal.net wrote: Where's the notes for 5.10.0-25? In the perl-base package, which you should get an update for shortly, once the buildds are done. There is discussion going on now (see debian bug #536384) as to if/how this should be

Bug#541551: perl-base: detecting stopped child process fails using POSIX WIFSTOPPED

So it seems that this is an intentional upstream change*. The perlvar entry for $? now notes that it contains the 16-bit status word returned by the traditional Unix wait() system call (or else is made up to look like it). Thus, the exit value of the subprocess is really ($? 8), and $? 127

Bug#541551: perl-base: detecting stopped child process fails using POSIX WIFSTOPPED

On Sat, Aug 15, 2009 at 5:15 AM, torp1250272...@noid.net wrote: When perl is testing if a child process is stopped, the result of the WIFSTOPPED function is never correct: Thanks for the bug report Tor. It appears that the problem is actually with waitpid not setting $? correctly when the

Bug#536384: perl-modules must depend on perl-base (= 5.10.0-24) or ship the changelog.Debian.gz

On Mon, Jul 13, 2009 at 6:12 AM, Niko Tynint...@debian.org wrote: On Fri, Jul 10, 2009 at 11:15:17PM +1000, Brendan O'Dea wrote: I vote that we fix this problem by simply nailing the dependencies between perl-base/perl/perl-modules to an exact equivalence.  [...] I agree with you

Bug#539145: RM: xpumon -- RoQA: RC-buggy, obsolete

On Wed, Jul 29, 2009 at 9:41 PM, Thomas Viehmannt...@beamnet.de wrote: xpumon has an unanswered RC bug open since May 1st. Its description contains  Requires a 2.4 kernel with the /proc/pmu interface. and the popcon is 3. Correct, thanks Thomas. Please remove this package. I no longer have

Bug#138752: Got me again

On Sat, Jul 11, 2009 at 7:39 AM, Steve M. Robbinsst...@sumost.ca wrote: I wasted 20 minutes debugging help2man because it outputs a completely unhelpful message:        help2man: can't get `--help' info from inspect when the program writes to stderr. David Bremner suggested to at least

Bug#536384: perl-modules must depend on perl-base (= 5.10.0-24) or ship the changelog.Debian.gz

On Fri, Jul 10, 2009 at 1:23 AM, Adrian Bunkb...@stusta.de wrote: /usr/share/doc/perl-modules is a symlink to /usr/share/doc/perl, and /usr/share/doc/perl/changelog.Debian.gz is shipped in the perl-base package. [...] the Debian source tree of perl-modules 5.10.0-24 is hardly the 5.10.0-1 or

Bug#527917: please break circular dependency

For reference, an install/remove of perl on current unstable: # apt-get install perl Reading package lists... Done Building dependency tree Reading state information... Done The following extra packages will be installed: make perl-modules Suggested packages: make-doc perl-doc

Bug#527917: please break circular dependency

On Sat, May 9, 2009 at 10:16 PM, Holger Levsen hol...@layer-acht.org wrote: Whats wrong with making perl depend perl-modules and making perl-modules only recommend perl? (I do the same with the tuxtype and tuxtype-data packages, and tuxtype-data is also basically useless without tuxtype. You

Bug#522827: perl: policy violation with the current /usr/share/doc symlinks

On Tue, Apr 7, 2009 at 5:45 AM, Niko Tyni nt...@debian.org wrote: As revealed by lintian, shipping /usr/share/doc/perl/copyright in perl-base and symlinking /usr/share/doc/perl-base - perl is a policy violation. [...] Is there a historical reason for the current setup or is it just cosmetics?

Bug#510895: perlivp fails

On Wed, Jan 7, 2009 at 12:21 AM, Niko Tyni nt...@debian.org wrote: On Mon, Jan 05, 2009 at 11:32:28AM -0800, Eric Wilhelm wrote: The `perlivp` program fails two of its tests. One is due to the absence of '/usr/local/lib/site_perl' and the other appears to be an artifact of the build procedure

Bug#151745: [Fwd: Perl bug on Socket.pm on SO_REUSEPORT constant]

In the current version, the behaviour has changed from what was seen in the initial report. SO_REUSEPORT is exported, but since this constant is not defined in asm/socket.h, using ReusePort in the IO::Socket::INET constructor will eilicit a die Your vendor has not defined I figure that this

Bug#504042: perl-doc recommendation

On Mon, Dec 8, 2008 at 6:24 PM, Raphael Hertzog [EMAIL PROTECTED] wrote: Brendan meant: apt-get install perl should install perl-doc because the user is interested in perl but apt-get install dpkg-dev which does also depend on perl should not install perl-doc because perl-doc is not really

Bug#504042: perl-doc recommendation

[+#504042, debian-dpkg, deity] On Mon, Nov 3, 2008 at 1:02 AM, Niko Tyni [EMAIL PROTECTED] wrote: I could use some backing with #504042 / #496770 (perl-doc gets pulled in by default). You tagged #442805 as wontfix with There is a bit of history with the perl-doc package... The perl

Bug#495394: perl: Install of diffrent versions in parallel alternatives

On Sun, Aug 17, 2008 at 7:02 PM, Peter Eisentraut [EMAIL PROTECTED] wrote: Actually, the solution is that postgresql-plperl-8.1 needs to be re-built for 5.10. That is not possible, because postgresql-plperl-8.1 is part of etch. Ah, it was not clear that you were trying to do a partial

Bug#495394: perl: Install of diffrent versions in parallel alternatives

reassign 495394 postgresql-plperl-8.1 thanks On Sun, Aug 17, 2008 at 9:54 AM, Peter Niebling [EMAIL PROTECTED] wrote: It should be possible to have different perl versions installed in parallel. This concerns also perl-base and perl-modules. This is somewhat more complicated than you might

Bug#474529: Perl policy vs. the search order for .1{,p} manpages

On Wed, Aug 6, 2008 at 6:34 PM, Colin Watson [EMAIL PROTECTED] wrote: I'd contend that you should simply divert the manual page in the same way. It's almost always wrong to handle manual pages differently from binaries in maintainer scripts - if you divert foo to foo.real, you should also

Bug#474529: Perl policy vs. the search order for .1{,p} manpages

On Wed, Aug 6, 2008 at 4:34 AM, Niko Tyni [EMAIL PROTECTED] wrote: while Brendan hasn't found the time to comment on this, I think moving .1p up on the search list would be the best thing to do for lenny at least. Would you still be willing to do that? The reason that modules manual pages have

Bug#492816: libperl must NOT be installed in /usr/lib

On Wed, Jul 30, 2008 at 7:52 AM, Marc Lehmann [EMAIL PROTECTED] wrote: On Tue, Jul 29, 2008 at 11:17:33PM +1000, Brendan O'Dea [EMAIL PROTECTED] wrote: I think that you have some other problem. -Lpath -lperl will search at compile time for libperl.so or libperl.a in path before it searches

Bug#492816: libperl must NOT be installed in /usr/lib

On Wed, Jul 30, 2008 at 7:55 AM, Marc Lehmann [EMAIL PROTECTED] wrote: (I really wonder when debian maintainers learn to do their job properly and stop trying to act like bignosed idiots who know everything better - wasn't the we-know-better-than-openssl incident enough?). Sorry, but you

Bug#492816: libperl must NOT be installed in /usr/lib

On Tue, Jul 29, 2008 at 10:44 AM, Marc Lehmann [EMAIL PROTECTED] wrote: debian makes it impossible to install perls in other prefixes by forcing libperl.so (a private library that should not be in the default search path) into /usr/lib, where it clashes with every other libperl. Impossible?

Bug#489928: libcgi-pm-perl: tries to overwrite file owned by libcgi-fast-perl

On Wed, Jul 9, 2008 at 5:53 AM, gregor herrmann [EMAIL PROTECTED] wrote: On Tue, 08 Jul 2008 20:47:48 +0200, Ralf Treinen wrote: Possible solutions include: * make libcgi-pm-perl conflict (and maybe provide) with libcgi-fast-perl; that would mean changing the Priority to extra (also of

Bug#479681: Perl symbol problem - release critical (Re: Bug#489132)

On Fri, Jul 4, 2008 at 6:17 AM, Raphael Hertzog [EMAIL PROTECTED] wrote: This is why I suggested to integrate liblocale-gettext-perl in perl-base itself. This would be the simplest/nicest solution IMO. It would always be synchronized with the current perl. See

Bug#484681: perl-base: imperfect package description

On Fri, Jun 6, 2008 at 9:09 PM, Niko Tyni [EMAIL PROTECTED] wrote: On Thu, Jun 05, 2008 at 03:16:44PM +0100, Justin B Rye wrote: Here's a suggestion that fixes all those and has spacing and quotes standardised to match the debian-l10n-english house style: Thanks, this looks good to me. I'd

Bug#483834: debian-policy: contradiction how to name man pages in perl-policy

On Tue, Jun 3, 2008 at 6:22 AM, Russ Allbery [EMAIL PROTECTED] wrote: Ansgar Burchardt [EMAIL PROTECTED] writes: there is a contradiction how to name man pages for perl modules. Section 4.1 states Module packages must install manual pages into the standard directories (see

Bug#479711: eval require Foo with binary-incompatible XS modules

On Sat, May 31, 2008 at 4:41 AM, Raphael Hertzog [EMAIL PROTECTED] wrote: On Fri, 30 May 2008, Andy Dougherty wrote: On Sat, 31 May 2008, Brendan O'Dea wrote: Not really. Adding a version into the path simply changes the failure from an issue loading the .so (module is unusable) to one

Bug#479711: eval require Foo with binary-incompatible XS modules

[-doughera] On Tue, Jun 3, 2008 at 12:11 AM, Raphael Hertzog [EMAIL PROTECTED] wrote: On Mon, 02 Jun 2008, Brendan O'Dea wrote: Modifying update-alternatives to set $ENV{PERL_DL_NONLAZY} would appear to be the most appropriate solution here. I tried this but it doesn't work. The variable

Bug#484021: perl: evaluation of errno ($!) violates priniciple of DWIM

On Mon, Jun 2, 2008 at 8:20 AM, Stephen Gran [EMAIL PROTECTED] wrote: perl should clear errno before going into a function where the API depends on checking it afterwards. Yes, I am aware there are other ways to determine that the setegid call failed. The problem is that the documentation

Bug#483442: RFH: cvsweb - test -x fails with Perl 5.10

On Fri, May 30, 2008 at 10:10 AM, Daniel Leidert [EMAIL PROTECTED] wrote: And real and effective UID are the same. So why does -x fail? Any idea? It cannot be a general bug, because a small test script prints the correct result. Right. I've attempted pretty much every combination of user

  1   2   3   4   >