date:20230804

Bug#1042874: unable to reproduce the problem

2023-08-04 Thread Janusz S . Bień

On Wed, Aug 02 2023 at  8:23 +02, Janusz S. Bień wrote:
> On Wed, Aug 02 2023 at  6:09 GMT, Debian Bug Tracking System wrote:
>> Thank you for filing a new Bug report with Debian.
>>
>> You can follow progress on this Bug here: 1042874: 
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042874.
>
> There was an encoding problem with quoting the error message, so I
> enclosed it in the attachment.

I've upgraded AUCTeX to the current version and I'm unable now to
reproduce the problem. I'm still curious what information is encoded in
the error message and I will try to look into it.

Regards

JSB

-- 
 ,   
Janusz S. Bien
emeryt (emeritus)
https://sites.google.com/view/jsbien

Bug#698640: gvfs-bin: gfvs-trash can not trash on fs that is bind mounted

2023-08-04 Thread Christian Pernegger

FWIW, the code that is responsible is in libglib2.0-0. Reasonably
recent versions will refuse to use the trash on
* mounted drives. I.e. I have a separate drive for bulk storage
mounted via fstab on a directory in my home directory, no go.
* btrfs subvolumes, even just somewhere under my home directory

Funnily enough this used to work, in fact it still does work if you
remove the checks. It'll find a location to trash to (in the root of
the mount/subvolume) just fine; and if it doesn't it errors out
elsewhere. The rationale for introducing them in the first place
escapes me, to put it politely.

It annoyed me enough that I may or may not have done the following.

Disclaimer: I do NOT know what I'm doing, use at your own risk.


--- glib2.0-2.72.4.orig/gio/glocalfile.c
+++ glib2.0-2.72.4/gio/glocalfile.c
@@ -1782,8 +1782,9 @@ ignore_trash_mount (GUnixMountEntry *mou
   const gchar *mount_options;
   gboolean retval = TRUE;

-  if (g_unix_mount_is_system_internal (mount))
-return TRUE;
+  // allow trash on mounted drives again
+  //  if (g_unix_mount_is_system_internal (mount))
+  //return TRUE;

   mount_options = g_unix_mount_get_options (mount);
   if (mount_options == NULL)
@@ -1807,7 +1808,10 @@ static gboolean
 ignore_trash_path (const gchar *topdir)
 {
   GUnixMountEntry *mount;
-  gboolean retval = TRUE;
+
+  // allow trash on subvolumes again
+  //  gboolean retval = TRUE;
+  gboolean retval = FALSE;

   mount = g_unix_mount_at (topdir, NULL);
   if (mount == NULL)

Cheers,
Christian

Bug#1043044: Versions of org-mode-doc do not match elpa-org

2023-08-04 Thread Maxim Nikulin


Package: org-mode-doc

Versions of org-mode-doc and elpa-org packages have diverged in 
stable-unstable repositories. Likely org-mode-doc was just forgotten 
during uploads of updates since it is in the non-free section


org-mode-doc | 9.5.2-1   | stable/non-free   | source, all
org-mode-doc | 9.5.2-1   | testing/non-free  | source, all
org-mode-doc | 9.5.2-1   | unstable/non-free | source, all

elpa-org   | 9.5.2+dfsh-5  | stable   | all
elpa-org   | 9.6.7+dfsg-1  | testing  | all
elpa-org   | 9.6.7+dfsg-1  | unstable | all

elpa-org_9.5.2+dfsh-5 is a dummy package to avoid Org mode version older 
than the one shipped with Emacs.

Bug#1043043: UDD patches: marks Forwarded as invalid if not 'no', 'not-needed', 'yes' or URL

2023-08-04 Thread David da Silva Polverari

Package: qa.debian.org
Severity: normal
User: qa.debian@packages.debian.org
Usertags: udd

Hi,

When using https://udd.debian.org/patches.cgi, I notice that whenever
the Forwarded field contains anything other than "no", "not-needed",
"yes" or an URL, it gets marked as invalid.

That includes cases where it begins with "yes", but is complemented with
other data, as can be seen by contrasting a search on Debian Sources
about those packages [1] with their respective patch metadata status on
UDD.

In its current form, patches.cgi marks as invalid patches that include
useful information on the Forwarded field, such as the mail address to
which the patch was forwarded, when upstream doesn't have a public
mailing list archive or a web pull/merge request tracker, for example.

According to DEP-3 [2], if the Forwarded field is present, any other
value other than "no" or "not-needed" should be considered valid:

  Any value other than "no" or "not-needed" means that the patch has
  been forwarded upstream. Ideally the value is an URL proving that it
  has been forwarded and where one can find more information about its
  inclusion status.

As such, I think it would be interesting to either propose changes to
DEP-3 or to adhere more closely to it.

Thanks,
David

[1] 
https://codesearch.debian.net/search?q=file%3Adebian%2Fpatches%2F*.patch+Forwarded%3A+yes+.%2B=0
[2] https://dep-team.pages.debian.net/deps/dep3/

Bug#815402: org-mode: * [[shell:cat ~/tmp | grep "asdf :: "]] does not work.

2023-08-04 Thread Max Nikulin

On 03/08/2023 22:03, Nicholas D Steeves wrote:

Nicolas Goaziou to emacs-orgmode. Re: * [[shell:cat ~/tmp | grep "asdf
:: "]] does not work. Wed, 24 Feb 2016 18:38:09 +0100

This is not a bug. - :: *is* description list syntax, no matter how
you look at it. You can easily work around this, e.g., by starting the
link on the next line.

I read the thread upstream, and see what you mean, and upstream's
perspective makes sense. How do you feel about keeping this bug open,

I do not see any value in having this bug in the open state, but I am
leaving decision up to you. I rarely visit list of bugs for the elpa-org
and org-mode packages.

because this "gotcha" should be documented somewhere. I'm not sure if
org-mode's documentation would be the best place, because it's non-free.

In my opinion, the "first wins" rule should be prominently stressed in
Org mode syntax description and it should be done in some general
section, not in description of items

https://orgmode.org/worg/org-syntax.html#Items
It should help to make behavior of pandoc, org-ruby, etc. more
consistent. However I can not suggest specific wording.

Despite some conflict of licenses, I do not think it is possible to
avoid reading of the Org mode manual. It may benefit from a note on
ambiguous syntax. Currently it has some references to zero width space
hack only

https://orgmode.org/manual/Escape-Character.html
that has some drawbacks and not applicable to links.
https://orgmode.org/manual/Link-Format.html
Discusses escaping of brackets only disregarding possible interference
with other markup structures.

https://orgmode.org/manual/Plain-Lists.html
does not mention possible issues as well.

Besides the manual, there are online-only (unless you clone the
repository) docs at https://orgmode.org/worg/ If you are more
comfortable with Debian wiki, you may create a page with tricks there.
Perhaps it would be more "visible" to users than the bug report.

For future readers of this bug, Brian G Powell wrote some nice style
suggestions for avoiding this pitfall, so here is the link:

https://list.orgmode.org/CAFm0skF=3JNXQQPFYutEvM8y+FRZJziE+QngVX=gocx3rkq...@mail.gmail.com/#t

While I agree with Brian in general, in this particular case I would
consider a more concise variant: breaking "::" by insertion of some
characters:

- [[shell:cat ~/tmp | grep "asdf :"": "]] does +not+ work.

More checkers may be added to `org-lint' to catch similar pitfalls.

Indeed! Please go ahead and give this bug a more useful title.

It falls in a rather generic class of
"Enclosing markup may lead to unexpected parsing results"
perhaps
"Double colon unexpectedly converts an item into description list"
would be better

1 2 >

1 - 100 of 140 matches

Mail list logo