On Sat, 27 Apr 2024 at 00:53, Karl Berry wrote:
> Reuben, any chance you can whomp up a test for this patch?
>
No problem, I will do this when I can find a moment. Since I don't actually
need this fix after all, it may not be quick!
--
https://rrt.sc3d.org
On Thu, 25 Apr 2024 at 14:07, Bruno Haible wrote:
> OK, I'm committing as shown below.
>
Great, thanks!
> Is there a reason not to make a similar macro for compute_curr_prefix?
>
> Yes:
> - For compute_curr_prefix, the need has not been demonstrated.
> - Even if ENABLE_RELOCATABLE is 1,
On Wed, 24 Apr 2024 at 23:38, Reuben Thomas wrote:
> Apologies, I should have run the tests before posting the patch. Indeed, I
> have broken things. So, please consider the documentation patch, and I'll
> take another look at the bug-fix (which in any case I have also realised
> do
On Wed, 24 Apr 2024 at 22:57, Reuben Thomas wrote:
>
> The patch is trivial, so hopefully it's obvious if there's a problem for
> some reason! I hope I explained well enough what problem I'm trying to
> solve.
>
Apologies, I should have run the tests before posting the patch.
enough what problem I'm trying to
solve.
--
https://rrt.sc3d.org
From 490777db71c2086cfbd3ec359fceca5fc853047d Mon Sep 17 00:00:00 2001
From: Reuben Thomas
Date: Wed, 24 Apr 2024 22:41:48 +0200
Subject: [PATCH 2/2] vala: do not build Vala sources excluded by automake
conditionals
MIME-Version: 1.0
On Wed, 24 Apr 2024 at 01:24, Bruno Haible wrote:
>
> Can you please try the attached patch?
>
Works beautifully, thanks. (Sorry to cause confusion: I was actually
quoting code from a C-based project, not a Vala-based project, where I
don't need the fix. But if you install this patch then I
On Wed, 24 Apr 2024 at 22:03, Bastian Germann wrote:
>
> I have seen Simon's post about this. The new gnulib package has a new
> README that describes how to use the Debian
> package. There is a slight chance that FTP Masters might intervene in
> having a git bundle in a package because their
>
On Tue, 19 Mar 2024 at 21:46, Reuben Thomas wrote:
> On Tue, 19 Mar 2024 at 21:37, Bastian Germann wrote:
>
>>
>> As nobody has provided any patch yet and I do not have an idea how to use
>> gnulib properly generally and in Debian
>> context, I came up with this
On Wed, 24 Apr 2024 at 15:56, Simon Josefsson wrote:
>
> The last aspect should be solved: the latest gnulib in Debian contains a
> git bundle of gnulib,
That's fantastic, I wish I had thought of that. I still don't fancy doing
the necessary packaging work, but I'll let those who have been
On Wed, 24 Apr 2024 at 01:51, Bruno Haible wrote:
> Reuben Thomas wrote:
> > (not yet in Debian, sadly, as they don't like me "vendoring gnulib", as
> FTP
> > Master calls it, or "using gnulib as other packages like Enchant do, and
> as
> > designed"
On Tue, 23 Apr 2024 at 21:46, Bruno Haible wrote:
> How does or would the code you are talking about look like, with #ifs?
> And would it be code for a library, or for a program?
>
For a library. For example, from the libpaper commit referenced below,
using #ifdefs:
/* Set the prefix directory
relocatable.h has partial support for building without
--enable-relocatable: it #defines relocate and relocate2 to empty macros.
This is great! Could macros be similarly added for the other relocatable.h
APIs, namely set_relocation_prefix and compute_curr_prefix? This would
allow relocate-using
On Fri, 12 Apr 2024 at 21:20, Bruno Haible wrote:
> Reuben Thomas wrote:
> > gcc -DHAVE_CONFIG_H -I. -I.. --include configmake.h --include config.h
>
Oh dear, the command-line includes were right in front of me, sorry!
> > ... enchant.c
>
> If you #include these tw
On Fri, 12 Apr 2024 at 18:55, Bruno Haible wrote:
> Reuben Thomas wrote:
> > With up-to-date gnulib (and I can't see any relevant changes for some
> > years), I am getting the following error while using the configmake
> module
> > and building on Mingw 64 x86_64:
>
With up-to-date gnulib (and I can't see any relevant changes for some
years), I am getting the following error while using the configmake module
and building on Mingw 64 x86_64:
In file included from :
C:/msys64/mingw64/include/objidl.h:10677:3: error: expected identifier or
'(' before string
On Sat, 6 Apr 2024 at 22:05, Paul Eggert wrote:
> Thanks for the suggestion. Although I didn't go to the trouble of
> writing code to generate the multiline diagnostic you suggested, it's
> easy to change "possibly undefined macro" (which doesn't cover the
> situation you mentioned) to the
Last night I had the baffling error "possibly undefined macro: AC_MSG_WARN".
Surely "impossibly undefined macro"!
Anyway, I was led to the following excellent analysis of the problem:
https://ae1020.github.io/undefined-macro-pkg-config/
In my case, I was briefly baffled even further, as I *had*
On Wed, 27 Mar 2024 at 20:25, Santiago Vila wrote:
>
> When I had already a bunch of them, I realized there is a macro
> STDC_HEADERS which is not properly detected.
Ah, I suspect the configure code is too old. Regenerating configure etc.
(autoreconf) might help.
-#if STDC_HEADERS
> +#if
On Wed, 27 Mar 2024 at 20:25, Santiago Vila wrote:
>
> When I had already a bunch of them, I realized there is a macro
> STDC_HEADERS which is not properly detected.
Ah, I suspect the configure code is too old. Regenerating configure etc.
(autoreconf) might help.
-#if STDC_HEADERS
> +#if
On Tue, 19 Mar 2024 at 21:37, Bastian Germann wrote:
>
> As nobody has provided any patch yet and I do not have an idea how to use
> gnulib properly generally and in Debian
> context, I came up with this. I have actually tried to use Debian's gnulib
> but could not get the thing to work.
>
Fair
On Mon, 18 Mar 2024 at 23:33, Bastian Germann wrote:
> Hi,
>
> I have updated the salsa repo to build without gnulib.
>
Fantastic, thanks for doing this!
I am a little puzzled, I thought that the idea was to build with Debian
gnulib? I think that could be a simpler patch.
Looking at the
On Wed, 13 Mar 2024 at 13:40, Arash Esbati wrote:
> Reuben Thomas writes:
>
> > I think it does make sense to make it file-local, as one could be
> > engaged in quite different workflows and want different behaviours.
>
Many thanks for addressing this report and add
On Tue, 12 Mar 2024 at 21:16, Arash Esbati wrote:
> Reuben Thomas writes:
>
> > Yes, that looks good!
>
> Thanks for your swift response. My plan is to install the following
> change (incl. addition to manual etc.). Does it make sense to have the
> custom variable sett
On Tue, 12 Mar 2024 at 18:59, Arash Esbati wrote:
>
> are you thinking about something like this:
>
> --8<---cut here---start->8---
> (defun TeX-process-check (name)
> "Check if a process for the TeX document NAME already exists.
> If so, give the user the
On Wed, 6 Mar 2024 at 21:45, Bruno Haible wrote:
>
> There's no need to change this comment, because the primary places to look
> for a function's behaviour are:
> 1. the documentation and standard documents,
> 2. the .h file (in this case: unistd.in.h line 1121).
>
Fair enough that there
On Wed, 6 Mar 2024 at 20:12, Bruno Haible wrote:
> Reuben Thomas wrote:
> > In getcwd.c I find the following comment:
>
> The Gnulib documentation
> https://www.gnu.org/software/gnulib/manual/html_node/getcwd.html
> points to the specification. That's usually a more
On Wed, 6 Mar 2024 at 20:09, Paul Smith wrote:
> On Wed, 2024-03-06 at 19:55 +0100, Reuben Thomas wrote:
> > In getcwd.c I find the following comment:
> >
> > > In GNU, if BUF is NULL, an array is allocated with 'malloc'; the
> > > array is SIZE bytes long
In getcwd.c I find the following comment:
In GNU, if BUF is NULL, an array is allocated with 'malloc'; the array is
> SIZE bytes long, unless SIZE == 0, in which case it is as big as necessary.
>
However, as far as I can see from the code, it always allocates if BUF is
NULL.
I assume this is
On Wed, 6 Mar 2024 at 17:07, Bruno Haible wrote:
> Reuben Thomas wrote:
> > > Such info could be added to the Gnulib manual.
> >
> > I doubt that would help many users (why should they read the gnulib
> manual
> > just to build software?)
>
> OK. In
On Tue, 5 Mar 2024 at 22:23, Reuben Thomas wrote:
>
> I'm asking to have a workaround for each program that gnulib uses in one
> place (in gnulib) rather than have every user of every package who wants to
> build from git on macOS have to add the PATH workaround, which is the sort
On Tue, 5 Mar 2024 at 21:47, Bruno Haible wrote:
>
> The programs are also in a libexec/gnubin/ directory, as symlinks, without
> the 'g' prefix. See [1] line 80 and [2] line 39.
>
Indeed.
So, it seems to me that it is simpler to ask the users to put this
> libexec/gnubin/ directory in front of
On Tue, 5 Mar 2024 at 19:06, Bruno Haible wrote:
>
> When people install the coreutils through Homebrew, which prefix do the
> programs have by default? Is it "g", or is it none?
>
There seem to be two different ways: either with no prefix (e.g. m4), or
with `g` prefix (e.g. coreutils); in both
On Tue, 5 Mar 2024 at 18:51, Bruno Haible wrote:
>
> The habit of installing GNU coreutils with --program-prefix=g was common
> on OSes like Solaris and *BSD, when people wanted to do serious development
> on these platforms. But nowadays, why would anyone choose to do their
> development on
Now that gnulib checks that `join` is working, could it also try `gjoin` as
a fallback, in the same way that other tools are searched for with a `g`
prefix, e.g. `glibtoolize` and `gxargs`?
--
https://rrt.sc3d.org
On Sat, 9 Dec 2023 at 15:16, Reuben Thomas wrote:
>
> If you're happy with that, I'll write a patch.
>
Patch attached.
--
https://rrt.sc3d.org
From 06f6765b7d10132d0dcefde1265b4d5f01df76b4 Mon Sep 17 00:00:00 2001
From: Reuben Thomas
Date: Sat, 9 Dec 2023 15:20:44 +0200
Subject: [P
On Sat, 9 Dec 2023 at 00:03, Karl Berry wrote:
> The manual currently says: "You should never explicitly mention the
> intermediate (C or C++) file in any `SOURCES' variable; only list
> the source file."
>
> I don't know the code here, and this probably wasn't the question, but I
>
On Wed, 6 Dec 2023 at 23:59, Karl Berry wrote:
> Any chance that one of you could write a patch for the manual to explain
> whatever needs to be explained (better)? --thanks, karl.
>
I'd happily do that if I could work out, or someone could explain, exactly
what's going on here.
The manual
On Sun, 3 Dec 2023 at 03:47, Mike Frysinger wrote:
> >
> > I think I've worked it out: I need to add the .c file that is generated
> > from the .y file, not the .h file, to BUILT_SOURCES. Certainly, doing
> that
> > fixes the problem.
>
> we prob could add a .y/.l example to the manual. i think
Copypasta is fine (as in the case of the Debian "package removed"
message I mentioned, as it's easier to change! I appreciate the clean-up
effort.
--
You received this bug notification because you are a member of Ubuntu
Studio Bugs, which is subscribed to audacity in Ubuntu.
Matching
Thanks for closing this bug; maybe it would be possible to add some
wording apologising for not getting around to it? The way this
particular message is worded it looks as though it's telling the user
"you dummy, you reported a bug in an out-of-date version of Ubuntu",
rather than "sorry, we
On Thu, 24 Aug 2023 at 01:40, Nicholas D Steeves wrote:
>
> Wow, it seems no one saw this bug for quite some time... I recently did
> some Debian Emacsen Team uploads for org-mode, and I noticed that the
> following are not currently installed in the elpa-org package:
>
>
On Thu, 24 Aug 2023 at 01:40, Nicholas D Steeves wrote:
>
> Wow, it seems no one saw this bug for quite some time... I recently did
> some Debian Emacsen Team uploads for org-mode, and I noticed that the
> following are not currently installed in the elpa-org package:
>
>
I just tried to make a backport to Debian 12. Unsurprisingly, I had to
change the build-deps on GCC 13 to GCC 12. Rather more surprisingly, I then
got the following error during build:
/home/rrt/.local/var/Downloads/emacs-29.1+1/debian/build-src/src/process.c:129:10:
fatal error: glib.h: No such
Package: ddclient
Version: 3.9.1-7
Severity: important
Tags: upstream
As of yesterday, upstream has marked the project unmaintained and archived the
GitHub project. See https://github.com/ddclient/ddclient/
I and at least one other person offered to take over the project;
unfortunately, since
like this:
gpg --verify a2ps-4.15.5.tar.gz.sig
The signature should match the fingerprint of the following key:
pub rsa2048 2013-12-11 [SC]
2409 3F01 6FFE 8602 EF44 9BB8 4C8E F3DA 3FD3 7230
uid Reuben Thomas
uid keybase.io/rrt
If that command fails because you don't have
Package: psutils
Version: 1.17.dfsg-4
Followup-For: Bug #1002514
As an encouragement to update psutils in Debian, I have just released
version 3, which adds full support for PDF, with transparent filetype
detection, using exactly the same commands as before.
I have rewritten the package
Package: xdg-utils
Version: 1.1.3-4
Severity: normal
I was noticing that xdg-mime was very slow on one system; this turned out to
be a server where I did not have a desktop environment, so xdg-mime was
going through all of its DE checks every time. Commenting out the calls to
“xprop” fixed it;
Hi,
I just tried to use this function and gave up.
I appreciate that it is carefully written to cope with a wide variety of
situations, but at present it looks more like the innards of something else
(which indeed it appears to be, I see it in coreutils's mkdir!) rather than
a reusable function
:
pub rsa2048 2013-12-11 [SC]
2409 3F01 6FFE 8602 EF44 9BB8 4C8E F3DA 3FD3 7230
uid Reuben Thomas
uid keybase.io/rrt
If that command fails because you don't have the required public key,
or that public key has expired, try the following commands to retrieve
or refresh
On Wed, 12 Apr 2023 at 17:59, Reuben Thomas wrote:
> On Wed, 12 Apr 2023 at 16:17, Reuben Thomas wrote:
>
>> I am bootstrapping GNU a2ps git master[1] with automake 1.16.5. When I do
>> a parallel build (in my case, MAKEFLAGS=-j4), I get build failures
>> sometimes:
>
On Wed, 12 Apr 2023 at 16:17, Reuben Thomas wrote:
> I am bootstrapping GNU a2ps git master[1] with automake 1.16.5. When I do
> a parallel build (in my case, MAKEFLAGS=-j4), I get build failures
> sometimes:
>
In fact, I don't need to do a parallel build, just build serially from
I am bootstrapping GNU a2ps git master[1] with automake 1.16.5. When I do a
parallel build (in my case, MAKEFLAGS=-j4), I get build failures sometimes:
$ make all
make all-am
make[1]: Entering directory '/home/rrt/.local/var/repo/a2ps/src'
YACC parsessh.c
CC libparse_a-lexssh.o
On Thu, 23 Mar 2023 at 13:24, Bruno Haible wrote:
>
> What I mean is that when a developer has removed or renamed some info nodes
> in the documentation, previously existing HTML pages no longer exist.
> Last time this happened, for example, after restructured the regular
> expressions
>
On Wed, 22 Mar 2023 at 05:42, Bruno Haible wrote:
>
> If we do this unconditionally, the user will get a warning message
>
> cvs add: manual/CVS already exists
>
> in the update case. This patch should thus work better.
>
Thanks for the improvement!
> Btw, I prefer to not use this script,
I spent a while trying to work out why I was getting CVS errors from the
script for GNU a2ps, and I realised that the problem was that a2ps's manual
wasn't online yet. This causes confusing error messages when the "manual"
subdirectory isn't online, and cvs can't find a CVS directory and hence
.tar.gz.sig
The signature should match the fingerprint of the following key:
pub rsa2048 2013-12-11 [SC]
2409 3F01 6FFE 8602 EF44 9BB8 4C8E F3DA 3FD3 7230
uid Reuben Thomas
uid keybase.io/rrt
If that command fails because you don't have the required public key
3F01 6FFE 8602 EF44 9BB8 4C8E F3DA 3FD3 7230
uid Reuben Thomas
uid keybase.io/rrt
If that command fails because you don't have the required public key,
or that public key has expired, try the following commands to retrieve
or refresh it, and then rerun the 'gpg --verify' command.
gpg
On Sun, 26 Feb 2023 at 19:17, Bruno Haible wrote:
> So, the cause could be that you are using a different version of mingw.
> You might not be the only one. Therefore it would be useful if you could
> analyze this failure. Then, let's see what is the best way forward (in
> Gnulib and in
:
pub rsa2048 2013-12-11 [SC]
2409 3F01 6FFE 8602 EF44 9BB8 4C8E F3DA 3FD3 7230
uid Reuben Thomas
uid keybase.io/rrt
If that command fails because you don't have the required public key,
or that public key has expired, try the following commands to retrieve
or refresh
Package: xsane
Version: 0.999-11ubuntu1
Followup-For: Bug #1013933
Thanks for keeping XSane alive in Debian.
I am a long-time user myself, out of necessity: I have tried several times
to use simple-scan (the only alternative I can find), and it just doesn’t
offer the functionality of XSane.
Package: xsane
Version: 0.999-11ubuntu1
Followup-For: Bug #1013933
Thanks for keeping XSane alive in Debian.
I am a long-time user myself, out of necessity: I have tried several times
to use simple-scan (the only alternative I can find), and it just doesn’t
offer the functionality of XSane.
Package: xsane
Version: 0.999-11ubuntu1
Severity: minor
When I select Help→Show license, nothing happens.
-- System Information:
Debian Release: bookworm/sid
APT prefers jammy-updates
APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 'jammy'),
(100, 'jammy-backports')
Package: xsane
Version: 0.999-11ubuntu1
Severity: normal
If I select Help→About XSane, the application pauses for a couple of seconds
then crashes. (The changes in Ubuntu’s version are just to depend on a
different JPEG library, so I think it’s reasonable to file a bug here.)
-- System
On Wed, 1 Mar 2023 at 01:33, Zefram wrote:
>
> The invocation with both encodings the same superficially looks like
> it's requesting an identity transformation, and it would correctly have
> the behaviour of an identity transformation on input that were correctly
> encoded. Because of the
On Mon, 27 Feb 2023 at 14:05, Bruno Haible wrote:
> Hi Reuben,
>
> Reuben Thomas wrote:
> > The perl module has a GPL license, but its only file, m4/perl.m4, has an
> > "unlimited" license.
>
> The license of a module, in the module description, cannot be &qu
The perl module has a GPL license, but its only file, m4/perl.m4, has an
"unlimited" license.
--
https://rrt.sc3d.org
I get an error with compiling:
In file included from fstat.c:52:
stat-time.h: In function ‘get_stat_atime_ns’:
stat-time.h:52:43: error: invalid use of undefined type ‘const struct
_stati64’
52 | # define STAT_TIMESPEC(st, st_xtim) ((st)->st_xtim)
and lots more the same.
I came across this
On Sun, 19 Feb 2023 at 00:58, Bruno Haible wrote:
> Reuben Thomas wrote:
> > See https://sourceware.org/bugzilla/show_bug.cgi?id=29913
> >
> > This is a bug I just came across (in my capacity as maintainer of Recode)
> > in current glibc.
> >
> > glibc ic
See https://sourceware.org/bugzilla/show_bug.cgi?id=29913
This is a bug I just came across (in my capacity as maintainer of Recode)
in current glibc.
glibc iconv(3) can return EILSEQ when the input is merely untranslatable,
rather than invalid. This is directly contrary to the POSIX spec[1],
On Sat, 11 Feb 2023 at 12:40, Corinna Vinschen wrote:
> On Feb 11 12:29, Reuben Thomas wrote:
> > On Sat, 11 Feb 2023 at 12:06, Corinna Vinschen
> wrote:
> >
> > >
> > > If you're sure that the native recode.dll has been built, is it
> possible
>
On Sat, 11 Feb 2023 at 12:06, Corinna Vinschen wrote:
>
> If you're sure that the native recode.dll has been built, is it possible
> that it's just not found, because it's not in Windows' DLL search path?
>
>
Yes, because it was working fine before, and I've not changed anything
about where it
On Fri, 10 Feb 2023 at 14:21, Bruno Haible wrote:
> It complains about the symbols defined in libiconv. This means, you need
> to invoke the Gnulib module 'iconv' and add $(LIBICONV) or $(LTLIBICONV)
> to the LDFLAGS.
>
Bruno to the rescue again! Many thanks.
Having added the iconv gnulib
On Sat, 11 Feb 2023 at 09:05, Bruno Haible wrote:
> The package name doesn't change that often. (Although, for 'recode', it
> already changed 3 times: recode → GNU recode → Free recode → recode.)
>
It may just be me, but I've renamed packages myself often enough, and then
failed to find
On Sat, 11 Feb 2023 at 08:48, Bruno Haible wrote:
> I got the impression that without a .x file, the NAME section of the output
> is too silly.
>
>
This is correct, but although (as you observe) this means that some
documentation goes in the Makefile.am, it avoids repeating the name of the
On Thu, 9 Feb 2023 at 02:49, Bruno Haible wrote:
> >
> > In general, then, it would be good if x-to-1 ignored unknown options and
> > passed them to help2man; would that be possible?
>
> Passing down additional options to help2man is a very good idea;
> implemented
> below. Ignoring unknown
On Tue, 7 Feb 2023 at 15:22, Corinna Vinschen wrote:
> In Cygwin projects using libtool, we always have to add -no-undefined
> iLDFLAGS. This is some old safe-guard in libtool to remind developers
> that when creating Windows DLLs, all external symbols must be resolved.
>
> Fortunately, libtool
I just found this handy script while puzzling over various problems with
help2man. In particular, it tests for cross-compilation, and copes with
help2man missing.
There are a couple of minor nits compared with direct usage of help2man,
however:
1. Before, I passed --locale=en_US.UTF-8 so I could
On Mon, 6 Feb 2023 at 20:38, Bruno Haible wrote:
> 1. 'recode' is updated to a current gnulib and publish a corresponding
> tarball. (Hi Reuben :) )
>
I've updated gnulib in recode git; I'd be grateful if I could have a report
that it's doing what's needed here before I make a release,
On Sun, 5 Feb 2023 at 06:09, Nick Bowler wrote:
>
> What Automake is trying to tell you is that LDFLAGS is meaningless
> on a static library. This message could definitely be improved!
>
Of course, thanks! I was confused because in another Makefile.am that had
only a static library I did not
Bruno pointed out to me that there's a bug fixed in the Makfile.in.in from
gettext 0.20.2, which postdates the 0.20 version found in gnulib. (The bug
is that the Makefile.in.in has prerequisites on suffix rules, which are
ignored.)
--
https://rrt.sc3d.org
On Wed, 1 Feb 2023 at 17:04, Michael Biebl wrote:
> Am 31.01.23 um 16:05 schrieb Reuben Thomas:
> > Package: rsyslog
> > Version: 8.2112.0-2ubuntu2.2
>
> This appears to be an Ubuntu version not known in the Debian archive
>
Apologies.
> > Severity: normal
&
Bruno has been helping me test https://github.com/rrthomas/libpaper on
various systems. (Many thanks, Bruno!)
On Wed, 1 Feb 2023 at 12:39, Bruno Haible wrote:
> On GNU/Hurd and Cygwin, I see 9 test failures. Such as
>
> --- expected-fixed.txt 2023-02-01 03:02:44.0 +0100
> +++
On Sat, 4 Feb 2023 at 21:18, Simon Josefsson wrote:
>
> To automatically understand if a cc to the translation project is
> necessary or not, I think we'd need access to the previously sent pot
> file, no? I guess we could wget that from somewhere and compare it, but
> that seems a bit fragile.
Using automake 1.16.5, in my Makefile.am, I have the following lines:
noinst_LTLIBRARIES = liba2ps.la
liba2ps_la_LDFLAGS = $(LIBGC_LIBS)
liba2ps_la_SOURCES = $(liba2pssources) $(libitsources) $(mylibitsources)
liba2ps_la_LIBADD = ../lib/libgnu.la $(LIBINTL) $(LIBSOCKET)
$(GETHOSTNAME_LIB)
I am maintaining a2ps, and have recently been making frequent alpha
releases as I attempt to stabilise the result of a massive updating effort
after a long period of quiescence.
The most recent release involves no changes to the gettext strings.
Using the standard gnulib release procedure for
Package: scanbd
Version: 1.5.1-6build1
Severity: important
When I first installed scanbd, I found that the systemd unit could not
start, because inetd was already listening on the scanbd port.
It seems to me that scanbd should only configure one of systemd or
inetd when it installs. In
I found this bug when I was about to file a WNPP bug myself. I just
installed AirSane from source on my Ubuntu system and was delighted by how
well it worked, and how easy it was.
--
https://rrt.sc3d.org
I found this bug when I was about to file a WNPP bug myself. I just
installed AirSane from source on my Ubuntu system and was delighted by how
well it worked, and how easy it was.
--
https://rrt.sc3d.org
Package: scanbd
Version: 1.5.1-6build1
Severity: important
When I first installed scanbd, I found that the systemd unit could not
start, because inetd was already listening on the scanbd port.
It seems to me that scanbd should only configure one of systemd or
inetd when it installs. In
Package: rsyslog
Version: 8.2112.0-2ubuntu2.2
Severity: normal
In order to work around a bug in scanbd (#901695), I tried to add a
property-based filter as /etc/rsyslog.d/99-scanbd.conf:
:msg, regex, "/usr/sbin/scanbd: abandon polling of"
^/usr/local/sbin/restart-scanbd
The filter appeared to
I am experiencing the same issue with a Canon 9000F scanner: when I switch
the scanner off then back on, scanbd fails to reconnect to it. The error
message is identical (mutans mutatis) to that in the logs posted here, but
in my case `scanimage -L` shows that the device name has not changed.
I am experiencing the same issue with a Canon 9000F scanner: when I switch
the scanner off then back on, scanbd fails to reconnect to it. The error
message is identical (mutans mutatis) to that in the logs posted here, but
in my case `scanimage -L` shows that the device name has not changed.
Package: scanbd
Version: 1.5.1-6build1
Severity: normal
I am using the excellent AirSane (sadly unpackaged for Debian):
https://github.com/SimulPiscator/AirSane
In order to get it to work, I had to increase MaxConnections to 2 for the
scanbm.socket systemd unit file.
I am sorry, it took me
Package: scanbd
Version: 1.5.1-6build1
Severity: normal
I am using the excellent AirSane (sadly unpackaged for Debian):
https://github.com/SimulPiscator/AirSane
In order to get it to work, I had to increase MaxConnections to 2 for the
scanbm.socket systemd unit file.
I am sorry, it took me
Package: devscripts
Version: 2.22.1ubuntu1
Severity: normal
I was puzzled by getting no results from build-rdeps; running with --debug did
not help.
Finally, I ran the dose-ceve command manually, and found out that it was
being killed because it used more memory than the VM I was using had
I found the "Rules-*" feature of gettext to do this; sorry for the noise!
--
https://rrt.sc3d.org
I have an automake project with a 'po' subdirectory whose contents,
including Makefile.in.in, is entirely generated by gettext. 'po' is in my
top level Makefile.am's SUBDIRS.
When I add an AM_EXTRA_RECURSIVE_TARGETS entry, say 'foo', automake tries
to recurse into po and 'make foo', and of course
On Sun, 8 Jan 2023 at 00:23, Karl Berry wrote:
> How does this change to the doc look? --thanks, karl.
>
Thanks for this Karl; it certainly fixes the problem I had! (I'll leave the
assessment of technical accuracy to others.)
--
https://rrt.sc3d.org
On Sat, 7 Jan 2023 at 08:46, Nick Bowler wrote:
>
> This example in the manual is talking about writing a custom
> Makefile, *without* using Automake, that you want to recurse
> into using Automake's SUBDIRS feature.
>
Aha! Thanks for pointing this out. I think the manual is misleading in
I'm using automake 1.16.5. The advice about how to disable the "dvi" target
doesn't seem to work.
In the manual it says:
To make ‘dvi’ into a do-nothing target, see the example for
‘EMPTY_AUTOMAKE_TARGETS’ in *note Third-Party Makefiles::.
If I have:
EMPTY_AUTOMAKE_TARGETS = dvi
.PHONY:
1 - 100 of 4931 matches
Mail list logo
