How to discover whether a language compiler was actually found

I have a project with some optional Objective C++. If I simply use AC_PROG_OBJCXX, then if it finds no Objective C++ compiler, it still sets OBJCXX=g++. I can't see a documented way to find out whether an actual compiler was found. Am I missing something? -- http://rrt.sc3d.org

[Desktop-packages] [Bug 708311] Re: Manually added startup application is deleted

It seems not. I think this bug can be closed, thanks. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/708311 Title: Manually added startup application is deleted Status in

[Bug 708311] Re: Manually added startup application is deleted

It seems not. I think this bug can be closed, thanks. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/708311 Title: Manually added startup application is deleted To manage notifications about this

Re: The place of mimeinfo.cache in freedesktop specs

On 24 April 2017 at 14:59, Maxwell Anselm wrote: > > If the standard is being followed, mimeapps.list is what xdg-open should be > reading from xdg-open delegates by default to desktop-specific helpers such as gvfs-open, kde-open, (Mac OS X) open etc. It has a generic

Printing out generic advice during bootstrap

I just wrote a valgrind suppressions file for the relocatable modules, because relocatable.c intentionally leaks memory. I intend to add this as part of my (forthcoming!) patchset for the relocatable modules. (Since no-one has provided detailed feedback on my questions so far, I intend to proceed

Bug#849517: The valgrind diagnostic is a false positive

On 14 April 2017 at 13:47, Florian Weimer <f...@deneb.enyo.de> wrote: > * Reuben Thomas: > > > ​A workaround is to build bash with --without-bash-malloc (but I presume > > there's a good reason not to do that?).​ > > FWIW, Fedora and Red Hat Enterprise Linux compil

Re: Running bash under valgrind gives "invalid free()"

On 13 April 2017 at 22:05, Reuben Thomas <r...@sc3d.org> wrote: > > On 13 April 2017 at 21:17, Chet Ramey <chet.ra...@case.edu> wrote: > >> On 4/13/17 3:57 PM, Reuben Thomas wrote: >> >> > Meanwhile, in the valgrind bug report, Mark Wielaard observed: &

Bug#849517: Alternative fix

A Valgrind maintainer pointed out that an alternative to disabling bash's malloc is to configure bash with CPPFLAGS=-DDISABLE_MALLOC_WRAPPERS=1. This disable the debugging wrappers that confuse valgrind. I guess it's still preferable not to do that. The obvious alternative is to ship either bash

Re: Running bash under valgrind gives "invalid free()"

On 13 April 2017 at 21:17, Chet Ramey <chet.ra...@case.edu> wrote: > On 4/13/17 3:57 PM, Reuben Thomas wrote: > > > Meanwhile, in the valgrind bug report, Mark Wielaard observed: > > > > "I think the problem is that bash not only has its own malloc/free

Leaks detected by valgrind

Here they are. I guess you probably won't care about them as as far as I can see they are all one-off allocations at initialization: ==1289== 276 bytes in 1 blocks are definitely lost in loss record 230 of 249 ==1289==at 0x4C2DB2F: malloc (in

Re: Running bash under valgrind gives "invalid free()"

On 13 April 2017 at 16:46, Chet Ramey <chet.ra...@case.edu> wrote: > On 4/13/17 11:41 AM, Reuben Thomas wrote: > > > ​This is not the result I obtained. I simply ran gdb on the bash binary, > > valgrind was not involved.​ > > If you didn't build the binary yours

Re: Running bash under valgrind gives "invalid free()"

​O​ n 13 April 2017 at 16:27, Chet Ramey <chet.ra...@case.edu> wrote: > On 4/13/17 11:18 AM, Reuben Thomas wrote: > > On 13 April 2017 at 16:11, Chet Ramey <chet.ra...@case.edu > > <mailto:chet.ra...@case.edu>> wrote: > > > > > > I see n

Re: Running bash under valgrind gives "invalid free()"

On 13 April 2017 at 16:11, Chet Ramey wrote: > > I see no reason why, since all of these things are defined in the same > file and are statically linked, `free' would resolve to the glibc free > when malloc resolves to the bash malloc. So this is the real problem?​ ​Do

Re: Running bash under valgrind gives "invalid free()"

​O​ n 13 April 2017 at 15:33, Reuben Thomas <r...@sc3d.org> wrote: > On 12 April 2017 at 15:49, Chet Ramey <chet.ra...@case.edu> wrote: > >> >> It's a false positive, or a bug in valgrind. I took a quick look. There's >> one place in this code path where free

Re: Running bash under valgrind gives "invalid free()"

On 12 April 2017 at 15:49, Chet Ramey wrote: > > It's a false positive, or a bug in valgrind. I took a quick look. There's > one place in this code path where free() gets called. ​Julian Seward (valgrind author) pointed out:​ " ​…​ what you report is symptomatic of bash

Bug#849517: The valgrind diagnostic is a false positive

See: https://bugs.kde.org/show_bug.cgi?id=378732 https://lists.gnu.org/archive/html/bug-bash/2017-04/msg00042.html ​The problem, in short, is that valgrind does not intercept the malloc call (which is made via bash's built-in malloc), but does intercept the free call, and hence concludes that

Re: Running bash under valgrind gives "invalid free()"

On 13 April 2017 at 09:15, Reuben Thomas <r...@sc3d.org> wrote: > > Having confirmed Chet's analysis with a few printfs added to bash (i.e. > just to check the address being allocated and the one complained about were > the same) I've filed a bug report against valgrind: >

Re: Running bash under valgrind gives "invalid free()"

On 12 April 2017 at 17:58, Hanno Böck <ha...@hboeck.de> wrote: > On Wed, 12 Apr 2017 14:59:26 +0100 > Reuben Thomas <r...@sc3d.org> wrote: > > > ​frequently, it's the only tool that shows up bugs of this sort, as > > it's rather more powerful than a debugging

Re: Running bash under valgrind gives "invalid free()"

On Apr 12, 2017 4:56 PM, "Chet Ramey" wrote: [snip] > Maybe update the Debian bug report you cited as well. There's still stuff > there from 2005. The report is from December 2016. I can't find "2005" in the page. I'll certainly send an update to point to the upstream

Re: Running bash under valgrind gives "invalid free()"

​O​ n 12 April 2017 at 15:49, Chet Ramey wrote: > > It's a false positive, or a bug in valgrind. I took a quick look. There's > one place in this code path where free() gets called. Here's the trace: > ​[analysis snipped] Thanks very much, looks like it's time for me to

Re: Problem with valgrind-tests: relies on bash not causing error

On 12 April 2017 at 15:23, Bruno Haible wrote: > Hi Reuben, > > > This is a separate issue, though: the real problem here is that a way is > > needed to run libtool wrappers with libtool > > In GNU gettext, I never succeeded in making valgrind work with the libtool > wrappers;

Re: Running bash under valgrind gives "invalid free()"

​O​ n 12 April 2017 at 14:50, Chet Ramey <chet.ra...@case.edu> wrote: > On 4/12/17 8:57 AM, Reuben Thomas wrote: > > See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849517 > > > > ​I can reproduce this also in bash 4.3 as supplied with Ubuntu 16.04, and > &

Running bash under valgrind gives "invalid free()"

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849517 ​I can reproduce this also in bash 4.3 as supplied with Ubuntu 16.04, and in a build of 4.4 from source on my Ubuntu system. ​As stated in the bug report, the bug causes problems beyond bash, as it causes build systems to think that

Re: Problem with valgrind-tests: relies on bash not causing error

​Having applied the workaround of using "ls" in the configure test, my tests still don't run because the LOG_COMPILER trick suggested in the gnulib manual doesn't take account of libtool wrappers. Net result: valgrind is being called on bash (as it runs the test binary's wrapper script). This is

Re: Documentation update for relocatable-lib{,-lgpl}

On 5 April 2017 at 04:28, Ben Pfaff <b...@cs.stanford.edu> wrote: > On Tue, Apr 04, 2017 at 01:07:58AM +0100, Reuben Thomas wrote: > > [Ben: Ccing you on Bruno Haible's advice] > > > > Having gone through the changes I needed to make to my sources to use the >

Re: relocatable given GPL boilerplate despite asking for relocatable-lib-lgpl

attach a patch to make this change.​ -- http://rrt.sc3d.org From 8fad23e97b9a82676782199313b2b6759fbf767c Mon Sep 17 00:00:00 2001 From: Reuben Thomas <r...@sc3d.org> Date: Wed, 5 Apr 2017 14:43:19 +0100 Subject: [PATCH] relocatable: Make the license on the sources the GPL. * lib/relocata

Re: relocatable given GPL boilerplate despite asking for relocatable-lib-lgpl

On 4 April 2017 at 10:21, Bruno Haible <br...@clisp.org> wrote: > Reuben Thomas asks: > > > This is because there are alternative instructions for using these > files > > > without gnulib-tool. (Although I don't know whether anyone still goes > > > with

Documentation update for relocatable-lib{,-lgpl}

[Ben: Ccing you on Bruno Haible's advice] Having gone through the changes I needed to make to my sources to use the relocatable-lib-lgpl module, here's a list of things I think should be documented in doc/relocatable-maint.texi. If they're agreed to be correct, I'll prepare a documentation patch.

Re: relocatable given GPL boilerplate despite asking for relocatable-lib-lgpl

On 20 March 2017 at 23:11, Bruno Haible <br...@clisp.org> wrote: > Reuben Thomas wrote: > > That just leaves the discrepancy I noticed where relocatable.[ch] > > specifically mention the LGPL in the versions in gnulib git, whereas the > > manual says that all the

Re: relocatable-lib and "make distcheck"

On 2 April 2017 at 20:59, Bruno Haible wrote: > Yes, this time I can analyze it. > ​Thanks very much for your help, again!​ So, you need the relocate() function only in lib.c, which is part of > libenchant_la_SOURCES. libenchant_la_LIBADD already contains libgnu.la, > so there

Re: relocatable-lib and "make distcheck"

On 29 March 2017 at 17:51, Reuben Thomas <r...@sc3d.org> wrote: > > On 29 March 2017 at 16:59, Reuben Thomas <r...@sc3d.org> wrote: > >> >> >> I'm now just floundering around in the sources without a very clear idea, >> a long way from any docume

Re: relocatable-lib and "make distcheck"

On 29 March 2017 at 16:59, Reuben Thomas <r...@sc3d.org> wrote: > > > I'm now just floundering around in the sources without a very clear idea, > a long way from any documentation, so I shall back up and try to create a > minimal failing example. > ​See https://github.

Re: relocatable-lib and "make distcheck"

On 29 March 2017 at 13:38, Reuben Thomas <r...@sc3d.org> wrote: > > On 29 March 2017 at 13:32, Reuben Thomas <r...@sc3d.org> wrote: > >> >> >> I cannot see how relocatable.c is treated specially (i.e. included >> directly, as it needs to be, rathe

Re: relocatable-lib and "make distcheck"

On 29 March 2017 at 13:38, Reuben Thomas <r...@sc3d.org> wrote: > > On 29 March 2017 at 13:32, Reuben Thomas <r...@sc3d.org> wrote: > >> >> >> I cannot see how relocatable.c is treated specially (i.e. included >> directly, as it needs to be, rathe

Re: relocatable-lib and "make distcheck"

On 29 March 2017 at 13:32, Reuben Thomas <r...@sc3d.org> wrote: > > > I cannot see how relocatable.c is treated specially (i.e. included > directly, as it needs to be, rather than just via libgnu.la). > m4/relocatable-lib.m4 doesn't seem to mention it, and > modules/relo

Re: relocatable-lib and "make distcheck"

On 28 March 2017 at 20:06, Bruno Haible wrote: > > So, I cannot reproduce. => Next time, please tell how to reproduce it. > ​Current master head of https://github.com/rrthomas/enchant/ : ./autogen.sh make make clean make distclean​ ​Do let me know if you'd prefer a M!WE​. ​

relocatable-lib and "make distcheck"

When I use relocatable-lib it adds a line like this to Makefile in src/: include ../lib/$(DEPDIR)/relocatable.Plo In my top-level Makefile.am, I have "lib" (containing gnulib) before "src", which is necessary, because the programs in src link against libgnu.la. When I run "make distcheck",

Detecting that a language compiler is not found

I have AC_PROG_OBJCXX in my configure.ac. On a system that lacks an Objective C++ compiler, but has g++, this happily sets OBJCXX=g++. Later, I have a stanza that looks like this: AC_LANG_PUSH([Objective C++]) ... some stuff ... AC_LANG_POP([Objective C++]) On a system without an Objective C++

Re: relocatable given GPL boilerplate despite asking for relocatable-lib-lgpl

On 20 March 2017 at 22:06, Eric Blake wrote: > [adding Gary in cc] > > Interesting - that file is not part of gnulib proper at the moment, but > Gary's bootstrap project aims to be something that plays nicely with > gnulib, and has the same directory layouts. In fact, the

Re: relocatable given GPL boilerplate despite asking for relocatable-lib-lgpl

On 20 March 2017 at 21:31, Bruno Haible wrote: > Hi Reuben, > > > Although gnulib/lib/relocatable.[ch] are LGPL-licensed in their original > > forms in the gnulib source tree, they are rewritten to be under GPL, even > > though I ask for relocatable-lib-lgpl. Is this a bug? > >

relocatable given GPL boilerplate despite asking for relocatable-lib-lgpl

Although gnulib/lib/relocatable.[ch] are LGPL-licensed in their original forms in the gnulib source tree, they are rewritten to be under GPL, even though I ask for relocatable-lib-lgpl. Is this a bug? -- http://rrt.sc3d.org

Bug#713051: bash: in /etc/skel/.bashrc, check if bash_completion has already run before

Package: bash Version: 4.4-4 Followup-For: Bug #713051 This bug report is correct, however, the situation is a little more complicated. /etc/profile.d/bash_completion.sh already contains code that checks whether bash_completion has already run. Hence, there should be no need to uncomment the

Using relocatable-lib-lgpl

I seem to have to add AC_CONFIG_LIBOBJ_DIR([lib]) to my configure.ac, otherwise {LT}LIBOBJDIR is not set, and relocatable.c is not found when building in the src directory of my project. But I don't find this documented anywhere in gnulib. Should a note be added to relocatable-lib{,-lgpl}, or am I

AC_PROG_OBJCXX succeeds without Objective C++ compiler present

AC_PROG_OBJCXX is satisfied by finding g++, but this does not mean that cc1objplus is installed. This means that AC_PROG_OBJCXX passes, but compilation fails with an obscure error about "execvp: not found". This problem presumably also affects C (if it's possible to install cc1obj without cc1),

Re: relocatable-lib{,-lgpl}

On 7 March 2017 at 12:19, Reuben Thomas <r...@sc3d.org> wrote: > I have read the documentation in gnulib, and also dug out the original > announcement, coincidentally almost exactly 10 years old: > http://lists.gnu.org/archive/html/bug-gnulib/2003-03/msg00020.html > ​By

Re: manywarnings for C++

On 22 February 2017 at 13:55, Reuben Thomas <r...@sc3d.org> wrote: > > ​I attach the latest state of play, which consists simply of updated > versions of manywarnings.m4 and warnings.m4, in place of the new files I > had before. (To test them I have simply placed them

relocatable-lib{,-lgpl}

I am trying to use relocatable-lib-lgpl, to make Enchant relocatable. (Enchant is a spell-checker library wrapper, itself a library, and it needs to be able to find resources such as dictionaries at run-time, relative to the library's location. See https://github.com/AbiWord/enchant/ ) I have

Bug#856464: xdg-utils: Remove hard-wired fallbacks

Package: xdg-utils Version: 1.1.1-1ubuntu1.16.04.1 Severity: normal See https://bugs.freedesktop.org/show_bug.cgi?id=98509 The upstream maintainer of xdg-utils doesn’t think hard-wired fallbacks are useful for upstream, and this seems sensible. Perhaps they should be removed from the Debian

Re: manywarnings for C++

On 21 February 2017 at 14:58, Bruno Haible wrote: > Hi Reuben, > > This looks reasonable: Since a project can use both gcc and g++ and since > the > desired warning options for gcc and g++ are likely different, it's good to > have different macros, that set different variables

Re: manywarnings for C++

On 21 February 2017 at 15:05, Bruno Haible wrote: > Hi Reuben, > > > ​For example, would it be sensible to have a single spec file, with each > > row as follows: > > > > warning language-list comment > > > > i.e. the first and third columns as at present, and the second giving

Documentation of AC_ARG_WITH

In the first example for AC_ARG_WITH, there's an "if test…fi" block: if test "x$with_readline" != xcheck; then AC_MSG_FAILURE( [--with-readline was given, but test for readline failed]) fi Is there some reason why this doesn't use AS_IF? I see a comment above saying:

manywarnings for C++

I needed this recently, so I made it. I have not attempted to refactor the code, as there seem to be multiple sensible-seeming ways to do this; I attach a simple duplication of the manywarnings files, reconfigured for C++. I'd be happy to work this up into a patch given some guidance on what

Re: manywarnings for C++

On 21 February 2017 at 12:13, Reuben Thomas <r...@sc3d.org> wrote: > I needed this recently, so I made it. I have not attempted to refactor the > code, as there seem to be multiple sensible-seeming ways to do this; I > attach a simple duplication of the manywarnings files, rec

[Bug 374059] Re: mpd is not configured to use pulseaudio

This bug still needs fixing. Since mpd is now run by default per-user, if system mpd is disabled, the fix would require a patch to mpd's source code to have it try PulseAudio before ALSA. This would have the disadvantage stated in comment #15 that it could result in PulseAudio being started for a

[Bug 780583] Re: When using ALSA backend, does not manage to use PulseAudio

This seems to be working correctly now, in Ubuntu 16.04 (mpd still uses ALSA by default, but uses the PulseAudio plugin, so it shows up under Applications in the Sound control panel, listed as "mpd (ALSA plug- in)"). -- You received this bug notification because you are a member of Ubuntu Bugs,

Re: [Rpcemu] RPCEmu and Sibelius

Very interested to know. -- http://rrt.sc3d.org On Feb 12, 2017 11:59 AM, "Jim Lesurf" wrote: > I *think* I'm still subscribed to this list, but haven't used it or seen > anything in ages, so maybe things have changed. > > However if this works... > > My main questions

Re: Out of date comment in setenv.c?

On 10 February 2017 at 18:17, Bruno Haible wrote: > > setenv.c comes from glibc (file glibc/stdlib/setenv.c). You could guess it > by seeing the _LIBC conditional, or by looking at config/srclist.txt. > ​I did wonder about that, but I thought maybe glibc used some code from

Out of date comment in setenv.c?

In setenv.c, it says /* This function is used by 'setenv' and 'putenv'. The difference between the two functions is that for the former must create a new string which is then placed in the environment, while the argument of 'putenv' must be used directly. This is all complicated by the

AC_LIBTOOL_WIN32_DLL is obsolete

​The gnulib manual mentions this macro, which seems to be obsolete. As libtool's documentation covers the replacement (win32-dll), along with remarks about passing -no-undefined, I suggest removing this section from the gnulib manual. -- http://rrt.sc3d.org

Bug#695179: psnup(1) has a confusing bit

On 21 January 2017 at 19:36, Ian Jackson wrote: > > In the absence of time to fix this properly by listing the available > units I have at least dropped the confusing sentence. > ​I have since become upstream, and have rewritten the documentation. I need to do a

Bug#695179: psnup(1) has a confusing bit

On 21 January 2017 at 19:36, Ian Jackson wrote: > > In the absence of time to fix this properly by listing the available > units I have at least dropped the confusing sentence. > ​I have since become upstream, and have rewritten the documentation. I need to do a

Bug#809801: dailystrips: Correction to last update

Package: dailystrips Version: 1.0.28-11 Followup-For: Bug #809801 Apologies, my last update didn’t actually work. Here is a corrected version, which should also be more robust: class gocomics-srch homepage http://www.gocomics.com/$strip/ searchpage

[Touch-packages] [Bug 1608880] Re: systemd doesnt work with timed fsck, only with counted mount fsck

I confirm this problem. Another curious thing is that fsck appears to be run, but doesn't do anything as the file system is clean: /run/initramfs/fsck.log says: Log of fsck -C -a -T -t ext4 /dev/md1 Thu Jan 19 19:09:43 2017 /dev/md1: clean, 46950805/57753600 files, 197262216/231002624 blocks

[Bug 1608880] Re: systemd doesnt work with timed fsck, only with counted mount fsck

I confirm this problem. Another curious thing is that fsck appears to be run, but doesn't do anything as the file system is clean: /run/initramfs/fsck.log says: Log of fsck -C -a -T -t ext4 /dev/md1 Thu Jan 19 19:09:43 2017 /dev/md1: clean, 46950805/57753600 files, 197262216/231002624 blocks

Bug#809801: dailystrips: Further update

Package: dailystrips Version: 1.0.28-11 Followup-For: Bug #809801 The gocomics web site appears to have changed again. Here is a new gocomics-srch class definition; as before, only tested for Doonesbury. class gocomics-srch homepage http://www.gocomics.com/$strip/ searchpage

bug#25413: Trivial typo in automake.texi

I just noticed, and still present in git: requited → required -- http://rrt.sc3d.org

Re: [O] Remove Org from Emacs repository?

On 19 December 2016 at 15:32, Phillip Lord wrote: > > This kind of idea is, indeed, being actively considered on > emacs-devel. ​That's good to hear!​ In fact, I managed to get a simple version of this working > using package.el during the build process. The idea

Re: [O] Remove Org from Emacs repository?

On 18 December 2016 at 19:21, Samuel Wales wrote: > auto-mode-alist has more than 200 entries. we're gonna remove .org? > ​Org is nearly 90kLOC, or about 6.5% of the total ELisp code currently in Emacs. It's bigger than CEDET, smaller than GNUS. It's a project of its own

Time to increase the defaults for history size?

The default HISTSIZE and HISTFILESIZE have been set for as long as I can remember (and the repo only seems to back to bash 3.2). For those concerned about privacy or security, 500 lines is probably too much. For those concerned about disk space, it's hard to come up with a sensible default. My

Re: [O] Remove Org from Emacs repository?

On 18 December 2016 at 13:20, Carsten Dominik wrote: > Dear all, > > I'd hate to see Org removed from Emacs. It took a lot of work to get it > in, and I believe that the vast majority of Emacs users does not install > packages. For a newbie to get to Emacs and to be able to

[O] Remove Org from Emacs repository?

Now that Emacs has had package.el for some years, and Org is installable directly from GNU ELPA, would it be a good idea to remove Org from Emacs's source repository? The current situation is left over from before Emacs had package.el, and I see no compelling reason to keep it. Org is too big and

Bug#801067: Bug still present in nfs-utils 1.3.4-1

The README.Debian.nfsv4 file is now ten years old. My previous comments apply, only more so (owing to the passing of time). -- http://rrt.sc3d.org

Bug#801067: Bug still present in nfs-utils 1.3.4-1

The README.Debian.nfsv4 file is now ten years old. My previous comments apply, only more so (owing to the passing of time). -- http://rrt.sc3d.org

Bug#796938: Bug still present in nfs-utils 1.3.4-1

This bug is still present, and the fix I give will still work. -- http://rrt.sc3d.org

Bug#796938: Bug still present in nfs-utils 1.3.4-1

This bug is still present, and the fix I give will still work. -- http://rrt.sc3d.org

Bug#725910: colormake: man page refers to non-existent configuration file

On 29 November 2016 at 20:04, Ludovic Rousseau <ludovic.rouss...@free.fr> wrote: > On Wed, 09 Oct 2013 23:54:23 +0100 Reuben Thomas <r...@sc3d.org> wrote: > >> Package: colormake >> Version: 0.9-1 >> Severity: minor >> >> colormake(1) refers

Re: [O] Bug: Errors when installing from package.el [9.0.1 (9.0.1-elpa @ /home/rrt/.emacs.d/elpa/org-20161118/)]

On 28 November 2016 at 22:50, Reuben Thomas <r...@sc3d.org> wrote: > > > Invalid function async-start > ​Apologies, this is nothing to do with org-mode. Please ignore this report!​

[O] Bug: Errors when installing from package.el [9.0.1 (9.0.1-elpa @ /home/rrt/.emacs.d/elpa/org-20161118/)]

Remember to cover the basics, that is, what you expected to happen and what in fact did happen. You don't know how to make a good report? See http://orgmode.org/manual/Feedback.html#Feedback Your bug report will be posted to the Org mailing list.

Re: [racket-dev] Browser support on unix

On November 15, 2016 2:07:24 PM GMT, Eli Barzilay <e...@barzilay.org> wrote: >On Mon, Nov 14, 2016 at 4:31 PM, Reuben Thomas <r...@sc3d.org> wrote: >> On 13 November 2016 at 03:54, Eli Barzilay <e...@barzilay.org> wrote: >>> >>> xdg-open still

Re: [racket-dev] Browser support on unix

On 13 November 2016 at 03:54, Eli Barzilay <e...@barzilay.org> wrote: > On Wed, Nov 9, 2016 at 6:24 PM, 'Reuben Thomas' via Racket Developers > <racket-dev@googlegroups.com> wrote: > > > > That's a good idea, but I don't think there is much point. xdg-open is

Re: [racket-dev] Browser support on unix

On 9 November 2016 at 23:22, Eli Barzilay <e...@barzilay.org> wrote: > On Tue, Nov 8, 2016 at 8:01 PM, 'Reuben Thomas' via Racket Developers > <racket-dev@googlegroups.com> wrote: > >> > >> Thanks, I'll take that back to the xdg-utils list, and prepare a &g

Re: [racket-dev] Browser support on unix

On 9 November 2016 at 17:10, Vincent St-Amour < stamo...@eecs.northwestern.edu> wrote: > I'd put `chromium-browser` next to `google-chrome` in the list. > ​Sounds sensible!​ Other than that, looks good to me. I'm happy to make the above change > when committing, if that works for you. >

Re: [racket-dev] Browser support on unix

On 8 November 2016 at 17:16, Reuben Thomas <r...@sc3d.org> wrote: > On 8 November 2016 at 17:11, Ryan Culpepper <ry...@ccs.neu.edu> wrote: > >> On 11/07/2016 03:25 PM, 'Reuben Thomas' via Racket Developers wrote: >> >>> A couple of questions: >>>

Re: [racket-dev] Browser support on unix

On 8 November 2016 at 17:11, Ryan Culpepper <ry...@ccs.neu.edu> wrote: > On 11/07/2016 03:25 PM, 'Reuben Thomas' via Racket Developers wrote: > >> A couple of questions: >> >> 1. Why is xdg-open commented out in all-unix-browsers? (These days it >> should be

[racket-dev] Browser support on unix

A couple of questions: 1. Why is xdg-open commented out in all-unix-browsers? (These days it should be possible to put this first, and also to remove gnome-open, long-obsolete.) In particular, xdg-open does support file: URLs. 2. chromium-browser should be added to the list. If some developer

[racket-dev] Use of this list as a mailing list

Can I email d...@racket-lang.org as suggested on https://lists.racket-lang.org/ or not? I tried, and got no error, but neither did my mail appear here… -- You received this message because you are subscribed to the Google Groups "Racket Developers" group. To unsubscribe from this group and

[issue28609] argparse claims '*' positional argument is required in error output

Reuben Thomas added the comment: Thanks, that's a simple, robust workaround. I'll duck out now and leave the Python experts to sort out the underlying problem, if they can; I think it's still well worth sorting out, though documenting the problem and workaround would be much better than

[issue28609] argparse claims '*' positional argument is required in error output

Reuben Thomas added the comment: > Try `nargs='?'` or try providing a `default` along with the '*'. Why would I do that? I want 0 or more arguments, and there's no default value. > Including your ARGUMENT action in the error message is intentional. It will likely confuse the user. The

[Bug 815856] Re: On Lexmark X543dn, "All pages from feeder" only returns one page

Since the bug has been present for years, and there's nothing in the current Changelog about a fix, it doesn't seem worth just trying the latest version in the hope that it might have been fixed by accident. -- You received this bug notification because you are a member of Ubuntu Bugs, which is

[Desktop-packages] [Bug 815856] Re: On Lexmark X543dn, "All pages from feeder" only returns one page

Since the bug has been present for years, and there's nothing in the current Changelog about a fix, it doesn't seem worth just trying the latest version in the hope that it might have been fixed by accident. -- You received this bug notification because you are a member of Desktop Packages,

[issue28609] argparse claims '*' positional argument is required in error output

Reuben Thomas added the comment: Thanks very much for this. It would be great if the redundancy I referred to in the usage message could also be removed, so that instead of "[ARGUMENT [ARGUMENT ...]]" it just said "[ARGUMENT ...]". (Similarly, for a '+' argument, it coul

[issue28609] argparse claims '*' positional argument is required in error output

New submission from Reuben Thomas: In Python 3.5.2, with a positional argument with nargs='*', running the program with no arguments gives an error like this: usage: caffeinate [-h] [-V] COMMAND [ARGUMENT [ARGUMENT ...]] caffeinate: error: the following arguments are required: COMMAND

[Desktop-packages] [Bug 1634490] Re: Pattern drawn over dialog title bars obscures title

I'm using gnome-shell, as shipped in Ubuntu 16.04. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to libreoffice in Ubuntu. https://bugs.launchpad.net/bugs/1634490 Title: Pattern drawn over dialog title bars obscures title Status in

[Desktop-packages] [Bug 1634490] Re: Pattern drawn over dialog title bars obscures title

The effect occurs in no other application. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to libreoffice in Ubuntu. https://bugs.launchpad.net/bugs/1634490 Title: Pattern drawn over dialog title bars obscures title Status in

[Bug 1634490] Re: Pattern drawn over dialog title bars obscures title

I'm using gnome-shell, as shipped in Ubuntu 16.04. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1634490 Title: Pattern drawn over dialog title bars obscures title To manage notifications about

[Bug 1634490] Re: Pattern drawn over dialog title bars obscures title

The effect occurs in no other application. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1634490 Title: Pattern drawn over dialog title bars obscures title To manage notifications about this bug

[Desktop-packages] [Bug 624172] Re: Multiple copies of irexec started at login

Feel free to close it. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to lirc in Ubuntu. https://bugs.launchpad.net/bugs/624172 Title: Multiple copies of irexec started at login Status in lirc package in Ubuntu: Incomplete Bug

[Bug 624172] Re: Multiple copies of irexec started at login

Feel free to close it. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/624172 Title: Multiple copies of irexec started at login To manage notifications about this bug go to:

[Mythbuntu-bugs] [Bug 624172] Re: Multiple copies of irexec started at login

Feel free to close it. -- You received this bug notification because you are a member of Mythbuntu Bug Team, which is subscribed to lirc in Ubuntu. https://bugs.launchpad.net/bugs/624172 Title: Multiple copies of irexec started at login Status in lirc package in Ubuntu: Incomplete Bug

Re: [O] Bug: Please supply stable releases on ELPA or MELPA Stable [8.3.4 (8.3.4-dist @ /usr/local/share/emacs/25.1.50/site-lisp/org-mode/)]

On 1 November 2016 at 17:01, Bastien Guerry wrote: > > Let me know if the current page is at least 90% "good enough" :) > ​You can have your 90% rating now! Thanks very much for engaging with my criticism to improve things! -- http://rrt.sc3d.org

<    2   3   4   5   6   7   8   9   10   11   >