GNOME issueshttps://gitlab.gnome.org/groups/GNOME/-/issues2024-03-10T15:24:57Zhttps://gitlab.gnome.org/GNOME/gvfs/-/issues/35Support native copy and move operation for SFTP2024-03-10T15:24:57ZBugzillaSupport native copy and move operation for SFTP## Submitted by Torsten Schönfeld `@tsch`
Assigned to **gvf..@..e.bugs**
**[Link to original bug (#518409)](https://bugzilla.gnome.org/show_bug.cgi?id=518409)**
## Description
When copying files or folders from a remote host with ...## Submitted by Torsten Schönfeld `@tsch`
Assigned to **gvf..@..e.bugs**
**[Link to original bug (#518409)](https://bugzilla.gnome.org/show_bug.cgi?id=518409)**
## Description
When copying files or folders from a remote host with the nautilus' sftp support to another place on that same remote host, the files get downloaded and then re-uploaded. Is it possible to do all the operations on the remote host only? That would speed things up quite a bit.
Version: git masterhttps://gitlab.gnome.org/GNOME/gnome-initial-setup/-/issues/44provide a way to test pages without actually saving any changes2020-10-29T15:22:28ZBugzillaprovide a way to test pages without actually saving any changes## Submitted by Jakub Steiner `@jimmac`
Assigned to **GNOME Initial Setup maintainer(s)**
**[Link to original bug (#762131)](https://bugzilla.gnome.org/show_bug.cgi?id=762131)**
## Description
We should have a way to dry-run all p...## Submitted by Jakub Steiner `@jimmac`
Assigned to **GNOME Initial Setup maintainer(s)**
**[Link to original bug (#762131)](https://bugzilla.gnome.org/show_bug.cgi?id=762131)**
## Description
We should have a way to dry-run all pages in sequence, without actually doing any real configuration on the system.
Version: 3.19.xhttps://gitlab.gnome.org/GNOME/gnome-subtitles/-/issues/97Feature request: Colored lines by label (or checkbox)2018-09-21T16:17:39ZBugzillaFeature request: Colored lines by label (or checkbox)## Submitted by narcisgarcia
Assigned to **Maintainers of GNOME subtitles**
**[Link to original bug (#759098)](https://bugzilla.gnome.org/show_bug.cgi?id=759098)**
## Description
To make easier the control of what subtitles are al...## Submitted by narcisgarcia
Assigned to **Maintainers of GNOME subtitles**
**[Link to original bug (#759098)](https://bugzilla.gnome.org/show_bug.cgi?id=759098)**
## Description
To make easier the control of what subtitles are already reviewed, synchronized or corrected: some kind of label/star/checkbox/coloration will be useful for the user.
For example, the user has 50 subtitles for that video, and needs to correct some of them. The user jumps through the video timeline and needs to know what subtitles has already reviewed and what others are pending.
For this task, colored or marked lines will help a lot.
Version: 1.2https://gitlab.gnome.org/GNOME/libsoup/-/issues/64Cookies sent in http headers do not get logged by SoupLogger2018-11-28T14:45:08ZBugzillaCookies sent in http headers do not get logged by SoupLogger## Submitted by Christophe Fergeau
Assigned to **libsoup-maint@gnome.bugs**
**[Link to original bug (#712230)](https://bugzilla.gnome.org/show_bug.cgi?id=712230)**
## Description
Logging this bug in case it would be a useful impro...## Submitted by Christophe Fergeau
Assigned to **libsoup-maint@gnome.bugs**
**[Link to original bug (#712230)](https://bugzilla.gnome.org/show_bug.cgi?id=712230)**
## Description
Logging this bug in case it would be a useful improvement, but a NOTABUG resolution also makes sense to me ;)
I've been using librest with REST_DEBUG=proxy set to dump all the http requests done when interacting with a webservice. While I can see the Set-Cookie headers in the HTTP response from the service, I do not see the corresponding Cookie header in requests sent to the service, even though the cookie seems to be sent (from the service behaviour and from a breakpoint in the appropriate SoupCookieJar method).
For logging, REST_DEBUG=proxy uses
if (REST_DEBUG_ENABLED(PROXY)) {
SoupSessionFeature *logger = (SoupSessionFeature*)soup_logger_new (SOUP_LOGGER_LOG_BODY, 0);
soup_session_add_feature (priv->session, logger);
g_object_unref (logger);
logger = (SoupSessionFeature*)soup_logger_new (SOUP_LOGGER_LOG_BODY, 0);
soup_session_add_feature (priv->session_sync, logger);
g_object_unref (logger);
}
What happens is that both logging and cookies are SoupSessionFeatures which hook into request_start()/... to do their work, and librest is first adding the logger and then the cookie jar. This can easily be avoided in librest by registering the features in the correct order (first cookie jar, then logger), but I'm wondering if libsoup should use g_signal_connect_after for SoupLogger so that logging is done after the various feature callbacks have run (I've tested 2 patches doing this, but both are ugly, one c&p a bunch of soup-session-feature.c into soup-logger.c, the other adds a if (SOUP_IS_LOGGER(feature)) connect_flags = G_CONNECT_AFTER; in soup-session-feature.c. I can attach them if needed :)
Version: 2.44.xhttps://gitlab.gnome.org/GNOME/libsoup/-/issues/63Proxy environment variables no longer picked up2018-11-28T14:45:08ZBugzillaProxy environment variables no longer picked up## Submitted by mai..@..el.org
Assigned to **libsoup-maint@gnome.bugs**
**[Link to original bug (#711462)](https://bugzilla.gnome.org/show_bug.cgi?id=711462)**
## Description
I use a webkit web browser and since upgrading from 2.4...## Submitted by mai..@..el.org
Assigned to **libsoup-maint@gnome.bugs**
**[Link to original bug (#711462)](https://bugzilla.gnome.org/show_bug.cgi?id=711462)**
## Description
I use a webkit web browser and since upgrading from 2.42.2 to any later version it no longer picks up my environment variables $http_proxy and $no_proxy. Downgrading to 2.42.2 fixes my issue. I've tried 2.43, 2.44 and the latest from git and none resolve the issue.
Version: 2.44.xhttps://gitlab.gnome.org/GNOME/gvfs/-/issues/34trash problems with filesystems not supporting uid and/or sticky bit - should...2018-09-21T16:17:22ZBugzillatrash problems with filesystems not supporting uid and/or sticky bit - should we allow admin override## Submitted by Sébastien Bacher `@seb128`
Assigned to **Alexander Larsson `@alexl`**
**[Link to original bug (#514697)](https://bugzilla.gnome.org/show_bug.cgi?id=514697)**
## Description
Trashing a file on a vfat disk create a d...## Submitted by Sébastien Bacher `@seb128`
Assigned to **Alexander Larsson `@alexl`**
**[Link to original bug (#514697)](https://bugzilla.gnome.org/show_bug.cgi?id=514697)**
## Description
Trashing a file on a vfat disk create a directory with the user uid, this one is ignored by gvfs then since the owner doesn't correspondhttps://gitlab.gnome.org/GNOME/gnome-subtitles/-/issues/95Option pour : Automatic pause video while typing2023-04-09T20:34:46ZBugzillaOption pour : Automatic pause video while typing## Submitted by dar..@..il.com
Assigned to **Maintainers of GNOME subtitles**
**[Link to original bug (#756912)](https://bugzilla.gnome.org/show_bug.cgi?id=756912)**
## Description
Very useful would stop video automatically withou...## Submitted by dar..@..il.com
Assigned to **Maintainers of GNOME subtitles**
**[Link to original bug (#756912)](https://bugzilla.gnome.org/show_bug.cgi?id=756912)**
## Description
Very useful would stop video automatically without using the Ctrl-Phttps://gitlab.gnome.org/GNOME/libsoup/-/issues/62SoupSession: cancel_message cancels the cancellable too2018-11-28T14:45:08ZBugzillaSoupSession: cancel_message cancels the cancellable too## Submitted by nagisa `@nagisa`
Assigned to **libsoup-maint@gnome.bugs**
**[Link to original bug (#710959)](https://bugzilla.gnome.org/show_bug.cgi?id=710959)**
## Description
Created attachment 258210
Minimal test case
If you p...## Submitted by nagisa `@nagisa`
Assigned to **libsoup-maint@gnome.bugs**
**[Link to original bug (#710959)](https://bugzilla.gnome.org/show_bug.cgi?id=710959)**
## Description
Created attachment 258210
Minimal test case
If you pass message to the soup_session_send_async with a cancellable, the cancellable will be cancelled when the message is cancelled. I don't think this should happen, especially given this behaviour is not documented.
Either the documentation should be updated or Soup should make a new cancellable and cancel that one when the message is cancelled of the passed in cancellable is cancelled.
**Attachment 258210**, "Minimal test case":
[test2.py](/uploads/cc1c3173338019ba0c0f8a6bd7e705c7/test2.py)
Version: 2.44.xhttps://gitlab.gnome.org/GNOME/gnome-initial-setup/-/issues/41Takes too long to start on non-SSD drives2023-06-07T08:56:40ZBugzillaTakes too long to start on non-SSD drives## Submitted by Bastien Nocera `@hadess`
Assigned to **GNOME Initial Setup maintainer(s)**
**[Link to original bug (#760360)](https://bugzilla.gnome.org/show_bug.cgi?id=760360)**
## Description
I've encountered this problem on 2 s...## Submitted by Bastien Nocera `@hadess`
Assigned to **GNOME Initial Setup maintainer(s)**
**[Link to original bug (#760360)](https://bugzilla.gnome.org/show_bug.cgi?id=760360)**
## Description
I've encountered this problem on 2 separate installations of Fedora 23, both on recent (last year) consumer laptops with spinning hard drives.
After boot, and logging in, the blank shell interface shows up, but it's possible to hear gnome-initial-setup start in the background (hard drives are noisy), and after waiting about 10 seconds, the interface will show up.
It doesn't look like the problem is with a timeout, or anything like that, as the hard drive sounds busy during the whole of the session startup.
If we know that gnome-initial-setup will be started, maybe we need to put gnome-shell in a particular cut-down mode, or postpone the loading of some backend tasks so that it's not possible to start using the computer while g-i-s is loading.
Version: 3.18.xhttps://gitlab.gnome.org/GNOME/dconf/-/issues/32swtich from /run/dconf/user/1000 to /run/user/$UID/dconf/profile as the path ...2018-09-21T16:17:12ZBugzillaswtich from /run/dconf/user/1000 to /run/user/$UID/dconf/profile as the path for system provided profiles## Submitted by Alberto Ruiz
Assigned to **dco..@..e.bugs**
**[Link to original bug (#769561)](https://bugzilla.gnome.org/show_bug.cgi?id=769561)**
## Description
While consulting the security guys at Red Hat we've found that usin...## Submitted by Alberto Ruiz
Assigned to **dco..@..e.bugs**
**[Link to original bug (#769561)](https://bugzilla.gnome.org/show_bug.cgi?id=769561)**
## Description
While consulting the security guys at Red Hat we've found that using /run/dconf/user/ wasn't perhaps the best idea as that path can't be guaranteed to only be readable by the user itself which is a bit leaky, leaving it up to the software creating the profile to ensure that the permissions are set right.
Given that AFAIK Fleet Commander is the only consumer of this feature I would suggest that we switch the path to the recommended one for 3.22 before this feature gets noticed by a wider set of projects
Version: git masterhttps://gitlab.gnome.org/GNOME/simple-scan/-/issues/67Scanner buttons support2018-09-24T23:58:22ZGhost UserScanner buttons supportFeature request.
Many scanners has quick buttons on them to perform various scan operations, named like copy, scan, PDF and e-mail - what buttons that are available differ between brands and models.
It would be benefical if these butto...Feature request.
Many scanners has quick buttons on them to perform various scan operations, named like copy, scan, PDF and e-mail - what buttons that are available differ between brands and models.
It would be benefical if these buttons could be configured and used in simple-scan.
The default operations could be something like that the copy button could perform a scan operation and send direct to the default printer, the scan button could perform a regular scan (same as clicking on the scan button in the program), the PDF could scan and output a PDF, the e-mail could create a PDF/JPEG and open the preferred email application.
What they do should be configurable. Some drop downs/select boxes with actions in the settings dialog could be enough. Some users may want to have all the buttons do the scan action for example, while others may want to have them perform exactly what they are labeled. An option to set actions to "None" is essential so users who do not want anything to happen when they touch the buttons do not get irritated.
There are some projects targeting this type of functionality already. Maybe code from them could be used as an inspiration or source for functionality:
* Scanner Button Daemon (scanbd), https://wiki.archlinux.org/index.php/Scanner_Button_Daemon
* scannerbuttond, http://scanbuttond.sourceforge.net/
* insaned, https://github.com/abusenius/insanedhttps://gitlab.gnome.org/GNOME/gvfs/-/issues/33burn: doesn't support monitoring2018-09-21T16:17:06ZBugzillaburn: doesn't support monitoring## Submitted by Baptiste Mille-Mathias
Assigned to **gvf..@..e.bugs**
**[Link to original bug (#512864)](https://bugzilla.gnome.org/show_bug.cgi?id=512864)**
## Description
When I start nautilus I have this warning
** WARNING **: ...## Submitted by Baptiste Mille-Mathias
Assigned to **gvf..@..e.bugs**
**[Link to original bug (#512864)](https://bugzilla.gnome.org/show_bug.cgi?id=512864)**
## Description
When I start nautilus I have this warning
** WARNING **: Unable to add monitor: Not supported
but except than this message I have no problem,
I don't know if it is specific to GIO.
please find hereunder the gdb stacktrace when running with --g-fatal-warnings
[New Thread 0xb68cab90 (LWP 14180)]
** WARNING **: Unable to add monitor: Not supported
aborting...
```
Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 0xb6ad96c0 (LWP 14174)]
IA__g_logv (log_domain=0x0, log_level=G_LOG_LEVEL_WARNING,
format=0xb60c8236 "Unable to add monitor: %s",
args1=0xbfdd804c "�CG\bpSl� \0255�h\200ݿ\0250l�")
at /build/buildd/glib2.0-2.15.4/glib/gmessages.c:503
503 /build/buildd/glib2.0-2.15.4/glib/gmessages.c: No such file or directory.
in /build/buildd/glib2.0-2.15.4/glib/gmessages.c
(gdb) thread apply all bt
Thread 5 (Thread 0xb68cab90 (LWP 14180)):
#0 0xb7f6f410 in __kernel_vsyscall ()
#1 0xb7353dd2 in pthread_cond_timedwait@@GLIBC_2.3.2 ()
from /lib/tls/i686/cmov/libpthread.so.0
#2 0xb76c31b3 in g_cond_timed_wait_posix_impl (cond=0x81d7c20,
entered_mutex=0x80, abs_time=0x111)
at /build/buildd/glib2.0-2.15.4/gthread/gthread-posix.c:242
#3 0xb757fe91 in g_async_queue_pop_intern_unlocked (queue=0x81d3e70,
try=<value optimized out>, end_time=0xb68ca384)
at /build/buildd/glib2.0-2.15.4/glib/gasyncqueue.c:364
#4 0xb75cedc2 in g_thread_pool_thread_proxy (data=0x81d3e38)
at /build/buildd/glib2.0-2.15.4/glib/gthreadpool.c:220
#5 0xb75cd03f in g_thread_create_proxy (data=0x8451be8)
at /build/buildd/glib2.0-2.15.4/glib/gthread.c:635
#6 0xb734f4fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#7 0xb72d18ee in clone () from /lib/tls/i686/cmov/libc.so.6
Thread 4 (Thread 0xb41bdb90 (LWP 14179)):
#0 0xb7f6f410 in __kernel_vsyscall ()
#1 0xb7353dd2 in pthread_cond_timedwait@@GLIBC_2.3.2 ()
from /lib/tls/i686/cmov/libpthread.so.0
#2 0xb76c31b3 in g_cond_timed_wait_posix_impl (cond=0x81d7c20,
entered_mutex=0x80, abs_time=0x110)
at /build/buildd/glib2.0-2.15.4/gthread/gthread-posix.c:242
#3 0xb757fe91 in g_async_queue_pop_intern_unlocked (queue=0x81d3e70,
try=<value optimized out>, end_time=0xb41bd384)
at /build/buildd/glib2.0-2.15.4/glib/gasyncqueue.c:364
#4 0xb75cedc2 in g_thread_pool_thread_proxy (data=0x81d3e38)
at /build/buildd/glib2.0-2.15.4/glib/gthreadpool.c:220
#5 0xb75cd03f in g_thread_create_proxy (data=0x83a7fd8)
at /build/buildd/glib2.0-2.15.4/glib/gthread.c:635
#6 0xb734f4fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#7 0xb72d18ee in clone () from /lib/tls/i686/cmov/libc.so.6
Thread 3 (Thread 0xb49c3b90 (LWP 14177)):
#0 0xb7f6f410 in __kernel_vsyscall ()
#1 0xb7353dd2 in pthread_cond_timedwait@@GLIBC_2.3.2 ()
from /lib/tls/i686/cmov/libpthread.so.0
#2 0xb76c31b3 in g_cond_timed_wait_posix_impl (cond=0x81d7c20,
entered_mutex=0x80, abs_time=0x10e)
at /build/buildd/glib2.0-2.15.4/gthread/gthread-posix.c:242
#3 0xb757fe91 in g_async_queue_pop_intern_unlocked (queue=0x81d3e70,
try=<value optimized out>, end_time=0xb49c3384)
at /build/buildd/glib2.0-2.15.4/glib/gasyncqueue.c:364
#4 0xb75cedc2 in g_thread_pool_thread_proxy (data=0x81d3e38)
at /build/buildd/glib2.0-2.15.4/glib/gthreadpool.c:220
#5 0xb75cd03f in g_thread_create_proxy (data=0x8389c58)
at /build/buildd/glib2.0-2.15.4/glib/gthread.c:635
#6 0xb734f4fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#7 0xb72d18ee in clone () from /lib/tls/i686/cmov/libc.so.6
Thread 1 (Thread 0xb6ad96c0 (LWP 14174)):
#0 IA__g_logv (log_domain=0x0, log_level=G_LOG_LEVEL_WARNING,
format=0xb60c8236 "Unable to add monitor: %s",
args1=0xbfdd804c "�CG\bpSl� \0255�h\200ݿ\0250l�")
at /build/buildd/glib2.0-2.15.4/glib/gmessages.c:503
#1 0xb75ae249 in IA__g_log (log_domain=0x0, log_level=G_LOG_LEVEL_WARNING,
format=0xb60c8236 "Unable to add monitor: %s")
at /build/buildd/glib2.0-2.15.4/glib/gmessages.c:517
#2 0xb60c6d88 in ?? ()
from /usr/lib/nautilus/extensions-2.0/libnautilus-burn-extension.so
#3 0x00000000 in ?? ()
```
Version: 0.1.x
### Blocking
* [Bug 520414](https://bugzilla.gnome.org/show_bug.cgi?id=520414)https://gitlab.gnome.org/GNOME/libsoup/-/issues/61SoupCache: causes an occasional SIGSEGV2018-11-28T14:45:08ZBugzillaSoupCache: causes an occasional SIGSEGV## Submitted by nagisa `@nagisa`
Assigned to **libsoup-maint@gnome.bugs**
**[Link to original bug (#710896)](https://bugzilla.gnome.org/show_bug.cgi?id=710896)**
## Description
Created attachment 258148
Full backtrace
Program rec...## Submitted by nagisa `@nagisa`
Assigned to **libsoup-maint@gnome.bugs**
**[Link to original bug (#710896)](https://bugzilla.gnome.org/show_bug.cgi?id=710896)**
## Description
Created attachment 258148
Full backtrace
Program received signal SIGSEGV, Segmentation fault.
0x00007fffe02248fd in istream_caching_finished (istream=0x2e86440,
bytes_written=51802, error=0x0, user_data=0x7fff9c001270) at soup-cache.c:776
776 entry->dirty = FALSE;
Backtrace attached. What stands out, is that entry = 0x0 at that point which means SoupCache tries to follow some pointer from NULL and then set FALSE to it.
I'll also attach some python code illustrating how I use the library.
**Attachment 258148**, "Full backtrace":
[backtrace](/uploads/7493baeee4db7a8e13676b32ee03f651/backtrace)
Version: 2.44.xhttps://gitlab.gnome.org/GNOME/gnome-initial-setup/-/issues/39Privacy policy dialog isn't big enough on Fedora2018-09-21T16:16:59ZBugzillaPrivacy policy dialog isn't big enough on Fedora## Submitted by Allan Day `@aday`
Assigned to **GNOME Initial Setup maintainer(s)**
**[Link to original bug (#757244)](https://bugzilla.gnome.org/show_bug.cgi?id=757244)**
## Description
The privacy policy window is quite small. O...## Submitted by Allan Day `@aday`
Assigned to **GNOME Initial Setup maintainer(s)**
**[Link to original bug (#757244)](https://bugzilla.gnome.org/show_bug.cgi?id=757244)**
## Description
The privacy policy window is quite small. On Fedora, the privacy policy is a desktop site and it's impossible to read it without resizing the dialog.
I'd imagined that most privacy policies would be too big for this small window.
Version: 3.18.xhttps://gitlab.gnome.org/GNOME/gnome-subtitles/-/issues/93Allow to change the colour of subtitles2018-09-21T16:16:55ZBugzillaAllow to change the colour of subtitles## Submitted by ger..@..il.com
Assigned to **Maintainers of GNOME subtitles**
**[Link to original bug (#747432)](https://bugzilla.gnome.org/show_bug.cgi?id=747432)**
## Description
Hi, i will apreciate if the program can change th...## Submitted by ger..@..il.com
Assigned to **Maintainers of GNOME subtitles**
**[Link to original bug (#747432)](https://bugzilla.gnome.org/show_bug.cgi?id=747432)**
## Description
Hi, i will apreciate if the program can change the colour of the subtitle. Thanks. Best regards!
Version: 1.3
### Depends on
* [Bug 580759](https://bugzilla.gnome.org/show_bug.cgi?id=580759)https://gitlab.gnome.org/GNOME/dconf/-/issues/31>=dconf-0.16.1 fails on test abicheck.sh2020-07-10T07:08:15ZBugzilla>=dconf-0.16.1 fails on test abicheck.sh## Submitted by Émeric MASCHINO
Assigned to **dco..@..e.bugs**
**[Link to original bug (#768799)](https://bugzilla.gnome.org/show_bug.cgi?id=768799)**
## Description
Created attachment 331471
dconf-0.26.0 build.log
Hi,
I was ask...## Submitted by Émeric MASCHINO
Assigned to **dco..@..e.bugs**
**[Link to original bug (#768799)](https://bugzilla.gnome.org/show_bug.cgi?id=768799)**
## Description
Created attachment 331471
dconf-0.26.0 build.log
Hi,
I was asked by Gentoo team to report this issue.
While stabilizing dconf on Gentoo, it appears that dconf failed to pass abicheck.sh test. No problem when tests are disabled.
Unfortunately, gsettings/test-suite.log is not that verbose and simply says:
============================================
dconf 0.16.1: gsettings/test-suite.log
============================================
# TOTAL: 1
# PASS: 0
# SKIP: 0
# XFAIL: 0
# FAIL: 1
# XPASS: 0
# ERROR: 0
.. contents:: :depth: 2
FAIL: abicheck.sh
=================
Same things happen with current dconf-0.26.0 (build.log and test-suite.log attached).
Let me know how I can help further.
Thanks,
Émeric
**Attachment 331471**, "dconf-0.26.0 build.log":
[build.log](/uploads/110d151d442546e0b4829623b2f1c620/build.log)
Version: 0.26.xhttps://gitlab.gnome.org/GNOME/libsoup/-/issues/60Redirects are not cached properly with SoupCache2018-11-28T14:45:08ZBugzillaRedirects are not cached properly with SoupCache## Submitted by nagisa `@nagisa`
Assigned to **libsoup-maint@gnome.bugs**
**[Link to original bug (#710895)](https://bugzilla.gnome.org/show_bug.cgi?id=710895)**
## Description
SoupCache doesn't cache cacheable resources that are ...## Submitted by nagisa `@nagisa`
Assigned to **libsoup-maint@gnome.bugs**
**[Link to original bug (#710895)](https://bugzilla.gnome.org/show_bug.cgi?id=710895)**
## Description
SoupCache doesn't cache cacheable resources that are behind redirects.
E.g. There's two endpoints:
1. /redirect (returns HTTP 307/302 redirect to /cacheable)
2. /cacheable (cacheable resource)
If I request `/cacheable` resource with Soup directly, it is cached properly and subsequent requests to that URI are returned from the cache.
If I request `/redirect` resource it is never cached and the `/cacheable` resource is always downloaded anew, even if it was cached beforehand by direct request to `/cacheable`.
I haven't tested it with 301 redirects, but I suspect the issue will be reproducible with those as well.
Version: 2.44.xhttps://gitlab.gnome.org/GNOME/gvfs/-/issues/32Some GFile operations not implemented in GDaemonFile2018-09-21T16:16:50ZBugzillaSome GFile operations not implemented in GDaemonFile## Submitted by Alexander Larsson `@alexl`
Assigned to **Hans Petter Jansson `@hansp`**
**[Link to original bug (#509613)](https://bugzilla.gnome.org/show_bug.cgi?id=509613)**
## Description
This is the current list of GFile metho...## Submitted by Alexander Larsson `@alexl`
Assigned to **Hans Petter Jansson `@hansp`**
**[Link to original bug (#509613)](https://bugzilla.gnome.org/show_bug.cgi?id=509613)**
## Description
This is the current list of GFile methods not implemented by GDaemonFile:
Async ops (now using default threaded sync implementation):
append_to_async
append_to_finish
create_async
create_finish
enumerate_children_async
enumerate_children_finish
find_enclosing_mount_async
find_enclosing_mount_finish
replace_async
replace_finish
set_attributes_async
set_attributes_finish
set_display_name_async
set_display_name_finish
Has default implementation that falls back to set_attbute() calls:
set_attributes_from_infohttps://gitlab.gnome.org/GNOME/gnome-initial-setup/-/issues/38Obscure input methods prioritised in the list2023-03-03T13:37:25ZBugzillaObscure input methods prioritised in the list## Submitted by Allan Day `@aday`
Assigned to **GNOME Initial Setup maintainer(s)**
**[Link to original bug (#757243)](https://bugzilla.gnome.org/show_bug.cgi?id=757243)**
## Description
The initial list of input methods is suppos...## Submitted by Allan Day `@aday`
Assigned to **GNOME Initial Setup maintainer(s)**
**[Link to original bug (#757243)](https://bugzilla.gnome.org/show_bug.cgi?id=757243)**
## Description
The initial list of input methods is supposed to include the most popular input methods, in order to reduce the amount of work for users. Right now, it's doing the opposite.
What I see in 3.18:
Cameroon Multilingual (Dvorak)
Cameroon Multilingual (querty)
English (Cameroon)
English (Canada)
English (Colemak)
English (UK)
This is unhelpful, and means that users will pretty much always have to dig down to find the input method they want.
Version: 3.18.xhttps://gitlab.gnome.org/GNOME/gnome-subtitles/-/issues/92Add some command-line options2018-09-21T16:16:46ZBugzillaAdd some command-line options## Submitted by Rodrigo Silva
Assigned to **Maintainers of GNOME subtitles**
**[Link to original bug (#740840)](https://bugzilla.gnome.org/show_bug.cgi?id=740840)**
## Description
It would be great if Gnome Subtitles offered comma...## Submitted by Rodrigo Silva
Assigned to **Maintainers of GNOME subtitles**
**[Link to original bug (#740840)](https://bugzilla.gnome.org/show_bug.cgi?id=740840)**
## Description
It would be great if Gnome Subtitles offered command line options for some of its features, so I would use it in scripts to automate some common tasks.
Currently the feature I need the most is to delete lines matching a given pattern, for example the those annoying OpenSubtitles.org ads or some sub release teams credits that spoil the end/opening of a TV Series episode.
If finding the line using a matching pattern is too complex, i'm fine with selecting by ID (the line #), I can use grep/awk myself to parse the subtitles, list the line IDs, and feed that to Gnome Subtitles, all automated in a script.
Oh, a --help would also be nice to have :)