Bug#922681: libsecret-1-0: Returns an invalid pointer if an item does not have a schema name

[Alberto Garcia]

Package: libsecret-1-0
Version: 0.18.5-3.1
Severity: important
Tags: upstream patch

Hi!

The version of libsecret available in Debian stretch returns an
invalid pointer if you call secret_item_get_schema_name() on an item
that does not have a schema name.

This crashes e.g. Seahorse:

Thread 1 "seahorse" received signal SIGSEGV, Segmentation fault.
__strcmp_sse2_unaligned () at 
../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S:31
31  ../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S: No such file or 
directory.
(gdb) bt
#0  __strcmp_sse2_unaligned () at 
../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S:31
#1  0x5560676b in check_object_type (object=0x55da12c0, 
user_data=0x0) at libseahorse/seahorse-search-provider.c:488
#2  0x55602076 in seahorse_predicate_match (pred=0x558e8890, 
obj=0x55da12c0) at libseahorse/seahorse-predicate.c:70
#3  0x555fa162 in maybe_add_object (self=0x558deca0, 
obj=0x55da12c0) at libseahorse/seahorse-collection.c:77
#4  0x555fa2b4 in on_base_added (base=0x558de0a0, 
obj=0x55da12c0, user_data=0x558deca0) at 
libseahorse/seahorse-collection.c:107
#5  0x76064f75 in g_closure_invoke () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
[...]
(gdb) up
#1  0x5560676b in check_object_type (object=0x55da12c0, 
user_data=0x0) at libseahorse/seahorse-search-provider.c:488
488 if (g_strcmp0 (schema_name, "org.gnome.keyring.Note") 
!= 0)
(gdb) print schema_name
$2 = 0x2 

This was fixed upstream, I confirm that this patch fixes the problem:

   
https://gitlab.gnome.org/GNOME/libsecret/commit/5a217c5cae721afef1273e3d272552e467f7440e

Regards,

Berto

-- System Information:
Debian Release: 9.8
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libsecret-1-0 depends on:
ii  libc6 2.24-11+deb9u4
ii  libgcrypt20   1.7.6-2+deb9u3
ii  libglib2.0-0  2.50.3-2
ii  libsecret-common  0.18.5-3.1

libsecret-1-0 recommends no packages.

libsecret-1-0 suggests no packages.

-- no debconf information

Bug#921869: libwebkit2gtk-4.0-37: Renders some Hebrew characters as square boxes

[Alberto Garcia]

Control: tags -1 patch

On Sun, Feb 10, 2019 at 01:11:58PM +0100, Teus Benschop wrote:

> Of course, the WebKit engine should display Hebrew in decomposed
> format, as well as in composed format.

I have good news, there's now a patch available fixing this problem.

I tested it and it does show all characters correctly, so I requested
it to be included in the next stable release.

Regards,

Berto

Bug#921869: libwebkit2gtk-4.0-37: Renders some Hebrew characters as square boxes

[Alberto Garcia]

On Sat, Feb 09, 2019 at 05:30:06PM +0100, Teus Benschop wrote:

> The webkit engine renders some Hebrew characters as square boxes.
> 
> I have created a minimal example that shows the problem.

Hello,

thanks for the example, I can reproduce the problem with WebKitGTK
2.22.6.

I did a quick test with other browsers:

  - Chromium 71.0.3578.80 also fails but in a different way:
- "he-goat" is right in Chromium, but wrong in WebKit
- "speak" is wrong in Chromium, but right in WebKit 
  - Chrome 71.0.3578.98 however displays everything correctly.
  - Firefox-ESR 60.5.0 also works fine.

Other apps (terminal, text editor, etc) can display the text
correctly.

I'll discuss the problem with the upstream developers.

> The link to the minimal example is here:

In case it's useful, the Debian WebKitGTK package also contains a mini
web browser:

   /usr/lib/*/webkit2gtk-4.0/MiniBrowser

Regards,

Berto

Bug#921010: flatpak: Polkit and dbus-related error messages on every new terminal

[Alberto Garcia]

Package: flatpak
Version: 1.2.0-1
Severity: normal

Hi,

(I'm reporting this on behalf of someone else, so please apologize for the
possible inaccuracies)

Flatpak prints a few warning messages everytime a new terminal is opened,
seemingly if polkit is not installed:

  ** (flatpak:11008): WARNING **: 14:38:53.222: Unable to register 
authentication agent: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: 
The name org.freedesktop.PolicyKit1 was not provided by any .service files

The source of the problem seems to be the /etc/profile.d/flatpak.sh script
running flatpak --installations on every shell.

I made a quick test to try to reproduce this on my computer and I get this:

   # flatpak  --installations
   (flatpak:18398): GLib-GIO-CRITICAL **: 14:56:15.151: 
g_dbus_connection_register_object: assertion 'G_IS_DBUS_CONNECTION 
(connection)' failed
   ** (flatpak:18398): CRITICAL **: 14:56:15.151: 
polkit_authority_register_authentication_agent_with_options_sync: assertion 
'POLKIT_IS_AUTHORITY (authority)' failed
   Segmentation fault

Thanks

Berto

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C), 
LANGUAGE=en_US:en (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages flatpak depends on:
ii  bubblewrap 0.3.1-2
ii  libappstream-glib8 0.7.14-1
ii  libarchive13   3.3.3-3
ii  libc6  2.28-5
ii  libdconf1  0.30.1-2
ii  libgdk-pixbuf2.0-0 2.38.0+dfsg-7
ii  libglib2.0-0   2.58.2-4
ii  libgpgme11 1.12.0-6
ii  libjson-glib-1.0-0 1.4.4-2
ii  libostree-1-1  2019.1-1
ii  libpolkit-agent-1-00.105-25
ii  libpolkit-gobject-1-0  0.105-25
ii  libseccomp22.3.3-3
ii  libsoup2.4-1   2.64.2-2
ii  libsystemd0240-5
ii  libxau61:1.0.8-1+b2
ii  libxml22.9.4+dfsg1-7+b3
ii  xdg-dbus-proxy 0.1.1-1
ii  xdg-desktop-portal 1.2.0-1

Versions of packages flatpak recommends:
pn  desktop-file-utils   
pn  gtk-update-icon-cache
pn  hicolor-icon-theme   
ii  libpam-systemd   240-5
pn  p11-kit  
pn  policykit-1  
ii  shared-mime-info 1.10-1
pn  xdg-desktop-portal-gtk | xdg-desktop-portal-backend  

Versions of packages flatpak suggests:
pn  avahi-daemon  

-- no debconf information

Bug#916347: (no subject)

[Alberto Garcia]

On Fri, Dec 14, 2018 at 09:54:01AM -0600, mcatanz...@gnome.org wrote:

> But equally problematic is the Debian security team's lack of
> interest in allowing updates to the security-critical WebKitGTK+
> package, which is currently vulnerable to issues since WSA-2018-0003
> [1]

Notice however that the latest stable release of WebKitGTK+ is always
available in stable-backports at the same time as in testing, so it
is indeed possible to run Epiphany from Debian stable with the most
up-to-date WebKitGTK+.

Berto

Bug#916347: (no subject)

[Alberto Garcia]

On Fri, Dec 14, 2018 at 10:17:18AM -0600, mcatanz...@gnome.org wrote:
> On Fri, Dec 14, 2018 at 10:02 AM, Alberto Garcia  wrote:
> >Notice however that the latest stable release of WebKitGTK+ is always
> >available in stable-backports at the same time as in testing, so it
> >is indeed possible to run Epiphany from Debian stable with the most
> >up-to-date WebKitGTK+.
> 
> Perhaps the epiphany package could be made available only in backports?

WebKitGTK+ has a policy of being conservative with the build
dependencies so we can rely on it being buildable for Debian stable. I
don't know if that's the case with Epiphany, and if someone has the
time to take care of the backport.

Berto

Bug#914986: webkit2gtk: FTBFS on i386: ENABLE_SAMPLING_PROFILER conflicts with ENABLE_C_LOOP

[Alberto Garcia]

Control: forwarded -1 https://bugs.webkit.org/show_bug.cgi?id=186722
Control: tags -1 upstream fixed-upstream pending

On Thu, Nov 29, 2018 at 11:28:27AM +0100, Andreas Beckmann wrote:

> webkit2gtk/experimental FTBFS on i386:

Known problem, it's been fixed upstream already.

You can work around it in the meantime by passing
-DENABLE_SAMPLING_PROFILER=OFF.

Berto

Bug#861632: nettle: Please configure with --enable-fat

[Alberto Garcia]

On Mon, May 01, 2017 at 07:54:27PM -0500, David Gilman wrote:
> Source: nettle
> Severity: wishlist
> 
> Please consider running the configure script with --enable-fat.  It adds
> code to detect CPU features at runtime and use appropriate optimized
> crypto routines.

The optimized routines with AES-NI support increase the performance
very significantly on my system, is there any reason why this is not
enabled in the Debian packages?

Berto

Bug#907960: highlight: Doesn't work on armel: Illegal instruction

[Alberto Garcia]

On Wed, Sep 05, 2018 at 03:18:49AM +0100, Steve McIntyre wrote:

> >> > $ /usr/bin/highlight /dev/null
> >> > Illegal instruction
> >>
> >I can reproduce it in amdahl using an armel chroot. The rest of the
> >build works fine, it only fails at the end when calling highlight.
> 
> amdahl is an arm64 machine, and so doesn't support the SWP
> instruction directly in hardware. It was deprecated a long time
> ago, and was removed in most implementation of version 8 of the ARM
> architecture.

Ok, I was unaware of this. From my side I often use amdahl for
debugging because it has more memory and is faster than abel, which in
the case of WebKit makes a huge difference.

If the armel buildds don't have this problem and can build the package
fine then it's not a big deal for me.

> That *can* be changed, but a better solution for now would be to use
> a machine with a v7 or earlier CPU (like abel).

Ok, feel free to close the bug in this case.

Berto

Bug#907960: highlight: Doesn't work on armel: Illegal instruction

[Alberto Garcia]

On Tue, Sep 04, 2018 at 12:00:57PM -0300, David Bremner wrote:
> > running /usr/bin/highlight on armel fails with this error message:
> >
> > $ /usr/bin/highlight /dev/null
> > Illegal instruction
> >
> > Because of this I can't build WebKitGTK+ for this platform.
> 
> I can't duplicate this problem on abel (armel porterbox).

I can reproduce it in amdahl using an armel chroot. The rest of the
build works fine, it only fails at the end when calling highlight.

Berto

Bug#907960: highlight: Doesn't work on armel: Illegal instruction

[Alberto Garcia]

Package: highlight
Version: 3.41-2
Severity: important

Hi,

running /usr/bin/highlight on armel fails with this error message:

$ /usr/bin/highlight /dev/null
Illegal instruction

Because of this I can't build WebKitGTK+ for this platform.

Regards,

Berto

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: armel (armv8l)

Kernel: Linux 4.9.0-8-arm64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8), 
LANGUAGE=C (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages highlight depends on:
ii  highlight-common  3.41-2
ii  libc6 2.27-5
ii  libgcc1   1:8.2.0-4
ii  liblua5.2-0   5.2.4-1.1+b2
ii  libstdc++68.2.0-4

highlight recommends no packages.

highlight suggests no packages.

-- no debconf information

Bug#907078: libwebkit2gtk-4.0-37-gtk2: Drop this package?

[Alberto Garcia]

On Thu, Aug 23, 2018 at 03:56:42PM -0400, Jeremy Bicha wrote:

> libwebkit2gtk-4.0-37-gtk2 has only one reverse dependency in Debian:
> epiphany-browser recommends it. epiphany-browser 3.29 no longer
> supports NPAPI plugins. Since epiphany 3.30 will be released around
> the same time as webkit 2.22, I propose we drop the -gtk2 package
> now in the 2.21 (experimental) series.

No problem with that, but I wonder: what about backports? If 2.22
builds and runs in stretch we surely want to have a backport there...

Berto

Bug#907078: libwebkit2gtk-4.0-37-gtk2: Drop this package?

[Alberto Garcia]

On Mon, Aug 27, 2018 at 07:17:19AM -0400, Jeremy Bicha wrote:
> > > libwebkit2gtk-4.0-37-gtk2 has only one reverse dependency in
> > > Debian: epiphany-browser recommends it. epiphany-browser 3.29
> > > no longer supports NPAPI plugins. Since epiphany 3.30 will be
> > > released around the same time as webkit 2.22, I propose we drop
> > > the -gtk2 package now in the 2.21 (experimental) series.
> >
> > No problem with that, but I wonder: what about backports? If 2.22
> > builds and runs in stretch we surely want to have a backport
> > there...
> 
> Could you just revert dropping the gtk2 package in your backports
> branch?

Yes, I don't think that would be a problem.

Berto

Bug#906519: libjavascriptcoregtk-4.0-dev: missing jsc/jsc.h

[Alberto Garcia]

On Mon, Aug 20, 2018 at 07:08:08AM -0400, Jeremy Bicha wrote:

> > But I'm not sure how the doc-base files would go, I suppose
> > we need three doc-base files in total, or can you put several
> > documents in the same one?
> 
> I'm not very familiar with doc-base at all but it looks like you'll
> need separate doc-base files.
> 
> glib has 3 doc-base files:
> https://salsa.debian.org/gnome-team/glib/tree/debian/master/debian

That example is perfect, thanks.

Berto

Bug#906519: libjavascriptcoregtk-4.0-dev: missing jsc/jsc.h

[Alberto Garcia]

Control: tags -1 pending

> Suggestions
> --
> - debian/libjavascriptcoregtk-4.0-dev.install should install
> usr/include/webkitgtk-4.0/jsc/

Done

> - debian/libwebkit2gtk-4.0-doc.install should install both
> usr/share/gtk-doc/html/jsc-glib-4.0/
> usr/share/gtk-doc/html/webkitdomgtk-4.0/
> 
> I didn't submit a merge request for this because I'm not sure where
> exactly you want the docs installed.

That location looks good to me, those can be links to
/usr/share/doc/libwebkit2gtk-4.0-doc/{jsc-glib-4.0,webkitdomgtk-4.0}/html/
or something like that.

But I'm not sure how the doc-base files would go, I suppose we need
three doc-base files in total, or can you put several documents in the
same one?

> - add a debian/rules override to run dh_missing --fail-missing so we
> can detect this problem sooner next time.

Done

Berto

Bug#906242: cannot export OCR'ed Russian text

[Alberto Garcia]

Control: tags -1 moreinfo

On Thu, Aug 16, 2018 at 01:08:54AM +0300, Dmitry Eremin-Solenikov wrote:
> Package: ocrfeeder
> Version: 0.8.1-4
> Severity: important
> 
> After ocrfeeder has successfully OCR'ed Russian text, it is unable to
> export it to any of the formats, dumping following errors to the
> console:

I seem to be able to export cyrillic text do ODT just fine, can you
share one image that you are using to reproduce this problem?

Berto

Bug#906242: cannot export OCR'ed Russian text

[Alberto Garcia]

On Fri, Aug 17, 2018 at 05:13:02PM +0300, Dmitry Eremin-Solenikov wrote:

> The issue is not with OCR'ing itself, just exporting I found that
> running ocrfeeder with Russian locale (LANG=ru_RU.UTF-8 ocrfeeder)
> allows me to export text w/o issues. However with my default locale
> (en_GB.utf8) I can see recognized text in GUI, but can not export it
> to the file.

I understand. In my case I tried with some random text and it doesn't
recognize it correctly, but if I replace the text in the box with some
Russian text and then export it I can do it fine.

Berto

Bug#904058: megatools: megaput hangs at 100% upload

[Alberto Garcia]

On Thu, Jul 19, 2018 at 11:56:46AM +1200, Ben Caradoc-Davies wrote:
> 1.10.0-rc1, which includes the fix for this issue, was just released
> upstream:
> https://github.com/megous/megatools/issues/362

Thanks, I'll probably wait for the final 1.10.0 release before
auploading it to Debian, but if it takes too long I'll upload this
release candidate.

Berto

Bug#904058: megatools: megaput hangs at 100% upload

[Alberto Garcia]

On Thu, Jul 19, 2018 at 11:10:34AM +1200, Ben Caradoc-Davies wrote:
> Package: megatools
> Version: 1.9.98-1+b1
> Severity: important
> 
> Dear Maintainer,
> 
> megaput hangs when upload is at 100%. Seen twice with 3.0 GiB files. Seems
> fixed upstream on master, likely by reverting upload to not use TLS:
> https://github.com/megous/megatools/issues/360

Ok, it seems like a new version is about to be released:

https://github.com/megous/megatools/issues/362

Berto

Bug#902915: megatools: all mega tools don't honor .megarc settings

[Alberto Garcia]

I see, I reported the documentation bug upstream:

   https://github.com/megous/megatools/issues/359

I'll keep this bug open until that problem is fixed.

Thanks!

Berto

On Sat, Jul 07, 2018 at 11:55:51PM +, Pavel Kreuzt wrote:
> OK, it's my fault. I just made my megarc copying the example from megarc
> man page, which reads:
> 
>[Login]
>Username = your@email
>Password = yourpassword
> 
>[Network]
>; 1MiB/s
>SpeedLimit = 1024
>; Use over TOR
>Proxy = socks5://127.0.0.1:9050
> 
> 
> I supposed the lines with `;` would be interpreted as comments by the
> tools, but they aren't. Erasing those comments, megarc file is correctly
> acknowledged by tools. Reading more closely megarc man page it says "Create
> ~/.megarc (on linux) or mega.ini file containing these 3 lines:" so we are
> not supposed to copy those comments.
> If you consider the man page to be a little confusing, please modify it
> accordingly (for example, changing the `;` for `#`). But for me this bug
> can be closed now.

Bug#902915: megatools: all mega tools don't honor .megarc settings

[Alberto Garcia]

Control: tags -1 moreinfo

On Tue, Jul 03, 2018 at 02:50:05PM +0200, Pavel Kreuzt wrote:

> When trying to create a .megarc settings file as explained on
> documentation, these settings are not acknowledged by mega
> tools. They only follow options set on command line.

> For example, I tried to use a Tor proxy on .megarc with this option:
> 
> Proxy = socks5h://127.0.0.1:9050

Did you put that in the Network section? It should look like this in
the config file:

[Login]
Username = ...
Password = ...
[Network]
Proxy = socks5h://127.0.0.1:9050

> This also happens with other settings as user/pass or speed
> limitations.

Also with user/pass?

What's the output of this command?

$ strace megadf 2>&1|grep megarc

Berto

Bug#900282: webkitgtk FTBFS with new ICU

[Alberto Garcia]

On Mon, May 28, 2018 at 02:21:26PM +0100, peter green wrote:

> Webkitgtk seems to be failing to build, failures have been seen
> with binnmus in Debian and Raspbian and also on the reproducible
> builds service. I had a look at the insanely large build log from
> reproducible builds and found the following error, there are likely
> many others.

Although this is a very old and unsupported version of WebKitGTK+,
I think this upstream patch still applies:

   https://bugs.webkit.org/show_bug.cgi?id=171612

I'll give it a try and see if it works.

Berto

Bug#899338: WTFCrash

[Alberto Garcia]

On Thu, May 24, 2018 at 07:26:52PM +0800, 積丹尼 Dan Jacobson wrote:
> I can confirm that the problem doesn't occur on amd64 2.21.2-1, only i386.
> Do you have a i386 machine you can test
> /usr/lib/*-linux-gnu/webkit2gtk-4.0/MiniBrowser 
> https://www.couchsurfing.com/dashboard
> on?

Right, I can reproduce it here too.

A temporary workaround is to set the JavaScriptCoreUseJIT=0
environment variable.

Thread 1 "WebKitWebProces" received signal SIGSEGV, Segmentation fault.
WTFCrash () at ./Source/WTF/wtf/Assertions.cpp:267
267 *(int *)(uintptr_t)0xbbadbeef = 0;
(gdb) bt
#0  WTFCrash () at ./Source/WTF/wtf/Assertions.cpp:267
#1  0xf341d145 in WTF::CrashOnOverflow::crash () at 
./obj-i686-linux-gnu/DerivedSources/ForwardingHeaders/wtf/CheckedArithmetic.h:85
#2  WTF::CrashOnOverflow::overflowed () at 
./obj-i686-linux-gnu/DerivedSources/ForwardingHeaders/wtf/CheckedArithmetic.h:78
#3  WTF::Vector::at ()
at ./obj-i686-linux-gnu/DerivedSources/ForwardingHeaders/wtf/Vector.h:691
#4  WTF::Vector::operator[] ()
at ./obj-i686-linux-gnu/DerivedSources/ForwardingHeaders/wtf/Vector.h:711
#5  JSC::JIT::emitSlow_op_get_by_id () at 
./Source/JavaScriptCore/jit/JITPropertyAccess32_64.cpp:679
#6  0xf33d0457 in JSC::JIT::privateCompileSlowCases () at 
./Source/JavaScriptCore/jit/JIT.cpp:525
#7  0xf33d507d in JSC::JIT::compileWithoutLinking () at 
./Source/JavaScriptCore/jit/JIT.cpp:724
#8  0xf34359ae in JSC::JITWorklist::Plan::compileInThread () at 
./Source/JavaScriptCore/jit/JITWorklist.cpp:48
#9  JSC::JITWorklist::Plan::compileNow () at 
./Source/JavaScriptCore/jit/JITWorklist.cpp:89
#10 0xf343284a in JSC::JITWorklist::compileLater () at 
./Source/JavaScriptCore/jit/JITWorklist.cpp:233
#11 0xf345e93e in JSC::LLInt::jitCompileAndSetHeuristics () at 
./Source/JavaScriptCore/llint/LLIntSlowPaths.cpp:356
#12 0xf345d444 in entryOSR () at 
./Source/JavaScriptCore/llint/LLIntSlowPaths.cpp:378
#13 0xf3445b7e in llint_entry () from 
/usr/lib/i386-linux-gnu/libjavascriptcoregtk-4.0.so.18
#14 0xf344a2f7 in llint_entry () from 
/usr/lib/i386-linux-gnu/libjavascriptcoregtk-4.0.so.18
#15 0xf344a2f7 in llint_entry () from 
/usr/lib/i386-linux-gnu/libjavascriptcoregtk-4.0.so.18
#16 0xf344a53c in llint_entry () from 
/usr/lib/i386-linux-gnu/libjavascriptcoregtk-4.0.so.18
#17 0xf344a2f7 in llint_entry () from 
/usr/lib/i386-linux-gnu/libjavascriptcoregtk-4.0.so.18
#18 0xf344a2f7 in llint_entry () from 
/usr/lib/i386-linux-gnu/libjavascriptcoregtk-4.0.so.18
#19 0xf3444e1d in vmEntryToJavaScript () from 
/usr/lib/i386-linux-gnu/libjavascriptcoregtk-4.0.so.18
#20 0xf33bfd8c in JSC::JITCode::execute () at 
./Source/JavaScriptCore/jit/JITCodeInlines.h:38
#21 JSC::Interpreter::executeProgram () at 
./Source/JavaScriptCore/interpreter/Interpreter.cpp:956
#22 0xf35afe34 in JSC::evaluate () at 
./Source/JavaScriptCore/runtime/Completion.cpp:103
#23 0xf35aff95 in JSC::profiledEvaluate () at 
./Source/JavaScriptCore/runtime/Completion.cpp:118
#24 0xf5f928e6 in WebCore::JSMainThreadExecState::profiledEvaluate () at 
./Source/WebCore/bindings/js/JSMainThreadExecState.h:78
#25 WebCore::ScriptController::evaluateInWorld () at 
./Source/WebCore/bindings/js/ScriptController.cpp:130
#26 0xf5f92af8 in WebCore::ScriptController::evaluate () at 
./Source/WebCore/bindings/js/ScriptController.cpp:146
#27 0xf61e4b63 in WebCore::ScriptElement::executeClassicScript () at 
./Source/WebCore/dom/ScriptElement.cpp:387
#28 0xf61b3731 in WebCore::LoadableClassicScript::execute () at 
./Source/WebCore/dom/LoadableClassicScript.cpp:123
#29 0xf61f08ba in WebCore::ScriptElement::executeScriptAndDispatchEvent () at 
./Source/WebCore/dom/ScriptElement.cpp:426
#30 0xf61f09dd in WebCore::ScriptElement::executePendingScript () at 
./Source/WebCore/dom/ScriptElement.cpp:434
#31 0xf64146fe in 
WebCore::HTMLScriptRunner::executePendingScriptAndDispatchEvent () at 
./Source/WebCore/html/parser/HTMLScriptRunner.cpp:114
#32 0xf641a70b in WebCore::HTMLScriptRunner::executeParsingBlockingScripts () 
at ./Source/WebCore/html/parser/HTMLScriptRunner.cpp:164
#33 0xf641b90e in 
WebCore::HTMLScriptRunner::execute(WTF::Ref&&, WTF::TextPosition const&) () at 
./Source/WebCore/html/parser/HTMLScriptRunner.cpp:148
#34 0xf6407318 in WebCore::HTMLDocumentParser::runScriptsForPausedTreeBuilder 
() at ./Source/WebCore/html/parser/HTMLDocumentParser.cpp:212
#35 0xf640813e in WebCore::HTMLDocumentParser::pumpTokenizerLoop () at 
./Source/WebCore/html/parser/HTMLDocumentParser.cpp:231
#36 0xf640828d in WebCore::HTMLDocumentParser::pumpTokenizer () at 
./Source/WebCore/html/parser/HTMLDocumentParser.cpp:281
#37 0xf640848d in WebCore::HTMLDocumentParser::pumpTokenizerIfPossible () at 
./Source/WebCore/html/parser/HTMLDocumentParser.cpp:172
#38 0xf6408c9e in 
WebCore::HTMLDocumentParser::resumeParsingAfterScriptExecution () at 

Bug#899338: WTFCrash

[Alberto Garcia]

On Wed, May 23, 2018 at 09:05:24AM +0800, 積丹尼 Dan Jacobson wrote:
> Package: libjavascriptcoregtk-4.0-18
> Version: 2.21.2-1
> Severity: grave
> 
> 1   0xb37f73a4 
> /usr/lib/i386-linux-gnu/libjavascriptcoregtk-4.0.so.18(WTFCrash+0x14) 
> [0xb37f73a4]
> 2   0xb340f325 
> /usr/lib/i386-linux-gnu/libjavascriptcoregtk-4.0.so.18(_ZN3JSC3JIT20emitSlow_op_in_by_idEPNS_11InstructionERPNS_13SlowCaseEntryE+0x1a5)
>  [0xb340f325]
> 3   0xb33c243a 
> /usr/lib/i386-linux-gnu/libjavascriptcoregtk-4.0.so.18(_ZN3JSC3JIT23privateCompileSlowCasesEv+0x60a)
>  [0xb33c243a]
> 4   0xb33c707d 
> /usr/lib/i386-linux-gnu/libjavascriptcoregtk-4.0.so.18(_ZN3JSC3JIT21compileWithoutLinkingENS_20JITCompilationEffortE+0x55d)
>  [0xb33c707d]
> 5   0xb34279ae 
> /usr/lib/i386-linux-gnu/libjavascriptcoregtk-4.0.so.18(_ZN3JSC11JITWorklist4Plan10compileNowEPNS_9CodeBlockEj+0x6e)
>  [0xb34279ae]
> 6   0xb342484a 
> /usr/lib/i386-linux-gnu/libjavascriptcoregtk-4.0.so.18(_ZN3JSC11JITWorklist12compileLaterEPNS_9CodeBlockEj+0x7a)
>  [0xb342484a]
> 7   0xb345093e 
> /usr/lib/i386-linux-gnu/libjavascriptcoregtk-4.0.so.18(_ZN3JSC5LLInt26jitCompileAndSetHeuristicsEPNS_9CodeBlockEPNS_9ExecStateEj+0x12e)
>  [0xb345093e]
> 8   0xb344f444 
> /usr/lib/i386-linux-gnu/libjavascriptcoregtk-4.0.so.18(+0x778444) [0xb344f444]
> 
> Seen in epiphany or webkit minibrowser on pages like
> https://www.couchsurfing.com/dashboard
> or even after logging in to
> bugs.webkit.org .

Any chance that you could reproduce this with the debug symbols
installed? It would help to have a more detailed backtrace.

Berto

Bug#895969: webkit2gtk: FTBFS on riscv64 due to not linking against libatomic

[Alberto Garcia]

On Wed, Apr 25, 2018 at 11:47:39PM +0200, Manuel A. Fernandez Montecelo wrote:
> I was able to build with the simple patch/debdiff attached (and uploaded
> to "unreleased").
> 
> I am now sure, though, which knobs need to be modified to make this
> happen in the upstream part in the cleanest way.

I think that the patch proposed by Aurelien is probably the best way:

set(THREADS_PREFER_PTHREAD_FLAG ON)

Berto

Bug#895969: webkit2gtk: FTBFS on riscv64 due to not linking against libatomic

[Alberto Garcia]

On Tue, Apr 24, 2018 at 09:18:13PM +0200, Aurelien Jarno wrote:
> > > The correct way to link with -pthread instead of -lpthread is
> > > to use define THREADS_PREFER_PTHREAD_FLAG before importing the
> > > Thread package:
> > 
> > Oh, great, I'll give it a try.

That didn't fix the problem for me, I'm considering to try this
instead:

--- webkitgtk.orig/Source/JavaScriptCore/CMakeLists.txt
+++ webkitgtk/Source/JavaScriptCore/CMakeLists.txt
@@ -120,11 +120,9 @@ set(JavaScriptCore_LIBRARIES
 # __atomic_fetch_add_8 is not available as a compiler intrinsic. It is
 # available on other platforms (including 32-bit Arm), so the link
 # with libatomic is only neede on MIPS.
-if (WTF_CPU_MIPS)
 list(APPEND JavaScriptCore_LIBRARIES
--latomic
+-Wl,--as-needed -Wl,-latomic -Wl,--no-as-needed
 )
-endif ()

> > > I haven't tried the patch for webkit2gtk, but it works
> > > for qtwebkit. In addition I guess it's necessary to add
> > > support for riscv64 in various places of WTF, by defining
> > > WTF_CPU_RISCV64. At least it's the case also for qtwebkit.
> > 
> > webkit has now WTF_CPU_UNKNOWN for cases like this so perhaps we
> > don't need to do anything else.
> 
> Hmm that might work for a first version, but it means that
> USE_JSVALUE32_64 will be used instead of USE_JSVALUE64. And that
> might disable a few features.
> 
> Is that correct?

I don't know, but it's worth checking.

Platform.h suggests that it wouldn't be the case however:

#if __SIZEOF_POINTER__ == 8
#define USE_JSVALUE64 1
#elif __SIZEOF_POINTER__ == 4
#define USE_JSVALUE32_64 1

Berto

Bug#895969: webkit2gtk: FTBFS on riscv64 due to not linking against libatomic

[Alberto Garcia]

On Sun, Apr 22, 2018 at 08:48:19PM +0200, Aurelien Jarno wrote:

> The correct way to link with -pthread instead of -lpthread is to
> use define THREADS_PREFER_PTHREAD_FLAG before importing the Thread
> package:

Oh, great, I'll give it a try.

> I haven't tried the patch for webkit2gtk, but it works for
> qtwebkit. In addition I guess it's necessary to add support for
> riscv64 in various places of WTF, by defining WTF_CPU_RISCV64. At
> least it's the case also for qtwebkit.

webkit has now WTF_CPU_UNKNOWN for cases like this so perhaps we don't
need to do anything else.

> This leads me to the question about where we should send all
> the patches common to all the forks? Is it fine sending them to
> bugs.webkit.org?

Yes it's fine, you can use the WebKitGTK+ component when relevant.

Berto

Bug#895969: webkit2gtk: FTBFS on riscv64 due to not linking against libatomic

[Alberto Garcia]

On Wed, Apr 18, 2018 at 08:00:50PM +0200, Karsten Merker wrote:

> > Is there any way that I can have access to / set up a riscv64
> > build environment in order to debug this problem?
> 
> we don't yet have a "regular" porterbox for riscv64, but you can run
> a local qemu-based riscv64 virtual machine.

Ok. I can't promise that I'll have time to look at this in the next
few days, though, but I'll give it a try if I have the opportunity.

In the meantime, patches are welcome. If someone has a readymade qcow2
image with a basic Debian riscv64 installation that would also be
helpful.

Berto

Bug#895969: webkit2gtk: FTBFS on riscv64 due to not linking against libatomic

[Alberto Garcia]

On Wed, Apr 18, 2018 at 08:36:29AM +0200, Karsten Merker wrote:
> Source: webkit2gtk
> Version: 2.20.1-1
> X-Debbugs-CC: debian-ri...@lists.debian.org
> User: debian-ri...@lists.debian.org
> Usertags: riscv64
> 
> Hello,
> 
> webkit2gtk 2.20.1-1 FTBFS on the riscv64 architecture with "undefined
> reference to `__atomic_compare_exchange_1'". Full log at:

Is there any way that I can have access to / set up a riscv64 build
environment in order to debug this problem?

Or, do you have a working patch for this ?

Berto

Bug#895000: atril always shows a stacktrace/crash from webkit displaying pdf files

[Alberto Garcia]

On Fri, Apr 13, 2018 at 02:00:05PM -0400, Jeremy Bicha wrote:
> Version: 2.20.1-1
> 
> The webkit2gtk developers believe this is already fixed in webkit2gtk
> 2.20.1 which should reach Testing in a few days.

Can this bug be closed then, or what's the situation?

Berto

Bug#816750: uswsusp: suspend-keygen missing

[Alberto Garcia]

Control: merge 816750 824464
Control: severity -1 important

On Fri, Mar 04, 2016 at 10:16:31PM +0100, Marc Lehmann wrote:
> Package: uswsusp
> Version: 1.0+20120915-6.1
> Severity: normal
> 
> Dear Maintainer,
> 
> the package contains the manpage for suspend-keygen, but the actual
> suspend-keygen comamnd is missing:

So it seems that this package needs an old version of gcrypt (#758995)
and because of that encryption support was disabled (#763260).

Raising severity to important because I believe that this is an
important feature.

Berto

Bug#850513: epiphany-browser: Epiphany locks up system when visiting https://exoplanets.nasa.gov/newworldsatlas/582/ or the like

[Alberto Garcia]

Control: tags -1 moreinfo

On Sat, Jan 07, 2017 at 09:58:11PM +1000, Vince Barwinski wrote:
> Package: epiphany-browser
> Version: 3.22.3-1
> Severity: important

>* What led up to the situation? System locked up when visiting
>https://exoplanets.nasa.gov/newworldsatlas/582/ or the
>like. Also, visiting Goolge Maps led to the page failing to load
>with epiphany bringing up its error page.

Hello, is this still a thing? The NASA page no longer exists and I'm
not having any problem Google Maps.

Berto

Bug#891983: gir1.2-javascriptcoregtk-4.0 from stable-pu breaks the whole Gnome

[Alberto Garcia]

On Thu, Mar 08, 2018 at 02:22:37PM +0100, Julien Aubin wrote:

> No I confirm the offending packages are *gstreamer*bad from
> deb-multimedia.org

Is then problem solved if you use the official gstreamer packages
then?

Berto

Bug#891983: gir1.2-javascriptcoregtk-4.0 from stable-pu breaks the whole Gnome

[Alberto Garcia]

On Sat, Mar 03, 2018 at 06:11:10PM +0100, Julien Aubin wrote:
> You released this morning on stable-pu new versions of the following
> packages :
> gir1.2-javascriptcoregtk-4.0
> gir1.2-webkit2-4.0/
> libjavascriptcoregtk-4.0-18
> libwebkit2gtk-4.0-37
> 
> It turns out that they won't upgrade automatically if you run apt upgrade or
> dist-upgrade, and if you try to install them manually here's the list of
> packages they break :

I installed all the packages that you mention (minus the ones that are
not in Debian) and I can do the upgrade just fine, so the problem has
to be in openra and/or steam-launcher.

We would need to see the exact output of the commands you're running,
but most likely the problem is in the unofficial packages. See also
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892216 for a related
problem.

Berto

Bug#892216: libwebkit2gtk-4.0-37: Does not install. Dependecy conflict

[Alberto Garcia]

Control: tags -1 moreinfo

On Tue, Mar 06, 2018 at 05:57:51PM -0300, Patrick Davis Naylor Gonzalez wrote:

> I tried to install Zenity and Shotwell, which both have
> libwebkit2gtk-4.0-37 as a dependency, but it is not possible
> because of a dependency problem with libwebkit2gtk-4.0-37: Depends:
> libgstreamer-plugins-bad1.0-0 (<1.10.5) but 1:1.10.4-dmo2 will be
> installed.

> ii  libgstreamer-plugins-bad1.0-0   1:1.10.4-dmo2

It seems that the version of libgstreamer-plugins-bad1.0-0 that you
have installed is not from Debian, isn't that from deb-multimedia.org?

I don't know why they added an epoch (the "1:" part) to their version
number, but that's what's causing this.

So basically it seems that the gstreamer version from deb-multimedia
is incompatible with the one from Debian, you're using the former and
webkit2gtk was linked against the latter.

Can you try installing libgstreamer-plugins-bad1.0-0 from Debian and
see if that solves your problem?

Berto

Bug#887589: stretch-pu: package grilo-plugins/0.3.3-1

[Alberto Garcia]

Control: tags -1 - moreinfo

On Mon, Feb 26, 2018 at 08:55:51PM +, Adam D. Barratt wrote:

> > I would like to upload a new grilo-plugins package, which contains
> > a fix for https://bugs.debian.org/887469
> 
> The BTS metadata for that bug indicates that it affects the version
> of grilo-plugins in unstable and has not yet been resolved there -
> is that correct?

It's not correct, the version is sid is already patched.

Here's the proposed patch:

   
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=887589;filename=grilo-plugins.diff;msg=5

Here's the source code of the version in sid:

   
https://sources.debian.org/src/grilo-plugins/0.3.5-2/src/lua-factory/sources/grl-radiofrance.lua/#L108

I'll update the metadata of the bug report.

Berto

Bug#889072: Relates to experimental strict isolation mode

[Alberto Garcia]

On Thu, Feb 22, 2018 at 01:45:47PM +, Dominic Hargreaves wrote:

> I tracked this problem down to having enabled strict isolation mode
> in response to a recommendation at the time meltdown was announced.

I can confirm that this is the cause of the problem for me too. Thanks
for tracking it down!

Berto

Bug#889659: libwebkit2gtk: segmentation fault in strlen-avx2

[Alberto Garcia]

On Thu, Feb 22, 2018 at 07:58:36AM +, Teus Benschop wrote:

Hello Teus,

> There's just one thing that is different from before: After
> installing from experimental, when running bibledit, it now says
> this:
> 
> *teus@debian-sid-gui*:*~*$ bibledit
> 
> WaylandCompositor requires eglBindWaylandDisplayWL,
> eglUnbindWaylandDisplayWL and eglQueryWaylandBuffer.
> 
> Nested Wayland compositor could not initialize EGL

That's the expected message that you get when hardware rendering
cannot be initialized, so nothing to worry about!

Regards,

Berto

Bug#889659: libwebkit2gtk: segmentation fault in strlen-avx2

[Alberto Garcia]

Control: fixed -1 2.19.91-1

On Mon, Feb 05, 2018 at 02:06:09PM +0100, Teus Benschop wrote:
> Package: libwebkit2gtk-4.0-37
> Version: 2.18.6-1
> Severity: important
> File: libwebkit2gtk

Hello Teus,

I just uploaded webkit2gtk 2.19.91-1, that contains the fix for this
bug.

This release is from the experimental branch. The stable branch
(2.18.x) hasn't been updated yet, I'll close this bug as soon as that
happens.

In the meantime you can try this version if you want. I believe that
it should be stable as the 2.18.x branch for most purposes. If you do
tell me if the bug is still happening.

Thanks,

Berto

Bug#889659: libwebkit2gtk: segmentation fault in strlen-avx2

[Alberto Garcia]

On Thu, Feb 08, 2018 at 11:02:42AM +, Teus Benschop wrote:

Hello Teus,

> There will be some difference between your system, where the minimal
> case that was supplied works well without any segmentation fault,
> and my system where the minimal case leads to a segmentation fault.

According to a comment on the upstream bug report, "this causes a
crash on newer Mesa when using software rendering".

So this shouldn't crash with hardware acceleration enabled. It also
seems to be specific to Wayland, so if you use X.org it probably won't
crash.

As I said that problem has been detected and there's a patch
available, so expect a fixed version of WebKitGTK+ soon.

Thanks!

Berto

Bug#889659: libwebkit2gtk: segmentation fault in strlen-avx2

[Alberto Garcia]

Control: tags -1 - moreinfo - unreproducible + confirmed + upstream
Control: forwarded -1 https://bugs.webkit.org/show_bug.cgi?id=182490

On Wed, Feb 07, 2018 at 04:21:17PM +0100, Alberto Garcia wrote:

> > (gdb) bt
> > #0  0x70f2a1b1 in __strlen_avx2 ()
> > at ../sysdeps/x86_64/multiarch/strlen-avx2.S:62
> > #1  0x70e5961e in __GI___strdup (s=0x0) at strdup.c:41
> > #2  0x7fffe00ea13a in  () at /usr/lib/x86_64-linux-gnu/libEGL_mesa.so.0
> > #3  0x7fffe00dd471 in  () at /usr/lib/x86_64-linux-gnu/libEGL_mesa.so.0
> > #4  0x7fffe00d3ab8 in  () at /usr/lib/x86_64-linux-gnu/libEGL_mesa.so.0
> > #5  0x735b3eca in  ()
> > at /usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37
> 
> Could you try to obtain a backtrace after installing the
> libwebkit2gtk-4.0-37-dbgsym package ?

Wait, it may not be necessary after all, I think your bug is
https://bugs.webkit.org/show_bug.cgi?id=182490

See also https://bugs.freedesktop.org/show_bug.cgi?id=104949

Thanks! We'll make sure to have this fixed soon.

Berto

Bug#889659: libwebkit2gtk: segmentation fault in strlen-avx2

[Alberto Garcia]

Control: tags -1 moreinfo unreproducible

On Mon, Feb 05, 2018 at 02:06:09PM +0100, Teus Benschop wrote:
> Package: libwebkit2gtk-4.0-37
> Version: 2.18.6-1
> Severity: important
> File: libwebkit2gtk
> 
> Dear Maintainer,
> 
> At https://github.com/bibledit/cloud/issues/156 is a minimal test case.
> This test case aims to display a web page.
> It uses libwebkit2gtk-4.
> The issue at https://github.com/bibledit/cloud/issues/156 describes a 
> segmentation fault.

I cannot reproduce the problem (I'm using 2.18.6 as well). I see a
window with an open book and a few seconds after three columns showing
quotes from the Bible.

> A back trade is included too.
> 
> (gdb) bt
> #0  0x70f2a1b1 in __strlen_avx2 ()
> at ../sysdeps/x86_64/multiarch/strlen-avx2.S:62
> #1  0x70e5961e in __GI___strdup (s=0x0) at strdup.c:41
> #2  0x7fffe00ea13a in  () at /usr/lib/x86_64-linux-gnu/libEGL_mesa.so.0
> #3  0x7fffe00dd471 in  () at /usr/lib/x86_64-linux-gnu/libEGL_mesa.so.0
> #4  0x7fffe00d3ab8 in  () at /usr/lib/x86_64-linux-gnu/libEGL_mesa.so.0
> #5  0x735b3eca in  ()
> at /usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37

Could you try to obtain a backtrace after installing the
libwebkit2gtk-4.0-37-dbgsym package ?

You'll need to add this line to /etc/apt/sources.list:

deb http://debug.mirrors.debian.org/debian-debug/ unstable-debug main

Berto

Bug#774848: git: "git rebase -i" fails with "index.lock: File exists" every now and then

[Alberto Garcia]

On Mon, Jan 29, 2018 at 08:48:23PM +0100, Sebastian Pipping wrote:

> For the record, I was not using Magit or even emacs but KWrite,
> Kate, and Komodo IDE at the time.  I guess one of these may have a
> similar issue.

Ok... well, it not only needs to reopen modified files automatically,
it also needs to run git commands when it detects changes in the
working directory.

Berto

Bug#774848: git: "git rebase -i" fails with "index.lock: File exists" every now and then

[Alberto Garcia]

On Thu, Jan 08, 2015 at 12:15:55PM +0100, sebast...@pipping.org wrote:

> I keep running into "git rebase -i" errors on Debian wheezy. In
> most cases, "git rebase --abort" and trying again works around the
> problem. This is what it looks like:
> 
> $ git rebase -i REMOTE/BRANCH
> [detached HEAD XXX] MESSAGE1
>  3 files changed, 14 insertions(+), 2 deletions(-)
> fatal: Unable to create '[..]/.git/index.lock': File exists.

I finally figured out what's going on.

It turns out that the problem is not in git, but in Emacs. If a buffer
has the auto-revert-mode enabled (see the `auto-revert-mode' variable)
then Emacs will reopen it when the file changes on disk (for example
during a rebase).

This can in turn call `vc-find-file-hook', launching git and taking
the repository lock.

auto-revert-mode is disabled by default but Magit enables it in the
buffers that are under version control (see magit-auto-revert-mode).

I can reproduce this problem reliably if I do a git-rebase (e.g.
run "git rebase -f" a few times on top of the same branch) while
having some of the files affected by that rebase opened in Emacs with
auto-revert-mode enabled.

Here's the upstream bug report:

   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=21559

And a related magit bug:

   https://github.com/magit/magit/issues/2708

Berto

Bug#888543: webkit2gtk: Please reduce optimization level to -O1 on sh3 and sh4

[Alberto Garcia]

Control: tags 888543 pending

On Mon, Jan 29, 2018 at 12:04:26AM +0100, John Paul Adrian Glaubitz wrote:

> > I can apply the patch as-is, but that will affect the whole
> > codebase.  I wonder if you prefer / have tried to disable -O2 only
> > on the file(s) that cause problems? This can be useful:
> 
> No, it's fine as is. It's also considered to be a temporary solution
> until gcc upstream has been fixed.

Ok then.

Btw I just noticed that you set CXXFLAGS in your patch, but that's
unnecessary because it's the CFLAGS value that is later passed to
dh_auto_configure. So I'll remove that line from your patch.

Berto

Bug#888543: webkit2gtk: Please reduce optimization level to -O1 on sh3 and sh4

[Alberto Garcia]

On Fri, Jan 26, 2018 at 11:04:44PM +0100, John Paul Adrian Glaubitz wrote:

Hey, thanks for the bug report and the patch!

> Source: webkit2gtk
> Version: 2.18.6-1
> Severity: normal
> Tags: patch
> User: debian-sup...@lists.debian.org
> Usertags: sh3 sh4

Is sh3 being built by Debian at all? :-?

> webkit2gtk currently FTBFS on sh3/sh4 due to an upstream gcc bug [1]:
  [...]
> While the upstream bug has not been fixed yet, it can be worked
> around by reducing the optimization level on sh3/sh4 to -O1 which is
> what the attached patch does.

I can apply the patch as-is, but that will affect the whole codebase.
I wonder if you prefer / have tried to disable -O2 only on the file(s)
that cause problems? This can be useful:

https://gcc.gnu.org/onlinedocs/gcc/Function-Specific-Option-Pragmas.html

Your patch will go in the next release, so if you change your mind and
instead of using -O1 globallly you prefer to try with #pragma optimize
tell me!

Berto

Bug#887589: stretch-pu: package grilo-plugins/0.3.3-1

[Alberto Garcia]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

I would like to upload a new grilo-plugins package, which contains a
fix for https://bugs.debian.org/887469

The Radio France website has changed and Grilo can no longer detect
the available radios correctly.

This was fixed upstream more than a year ago already. These are the
upstream bug report and the fix:

   https://bugzilla.gnome.org/show_bug.cgi?id=773310

   
https://github.com/grilofw/grilo-plugins/commit/4617b91983792f3282757b93134f0b7e8f287d52

I have tested the patch and it works correctly. The reporter of the
original bug also confirms that it solves the problem.

I haven't uploaded the package yet, I'll do it as soon as I get the
confirmation that the changes are fine. Debdiff attached.

Thanks!

-- System Information:
Debian Release: 9.3
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru grilo-plugins-0.3.3/debian/changelog 
grilo-plugins-0.3.3/debian/changelog
--- grilo-plugins-0.3.3/debian/changelog2016-09-12 10:50:22.0 
+0300
+++ grilo-plugins-0.3.3/debian/changelog2018-01-17 11:30:37.0 
+0200
@@ -1,3 +1,10 @@
+grilo-plugins (0.3.3-1+deb9u1) stretch; urgency=medium
+
+  * debian/patches/radiofrance.patch:
+- Fix Radio France source after website changes (Closes: #887469).
+
+ -- Alberto Garcia <be...@igalia.com>  Wed, 17 Jan 2018 11:30:37 +0200
+
 grilo-plugins (0.3.3-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru grilo-plugins-0.3.3/debian/patches/radiofrance.patch 
grilo-plugins-0.3.3/debian/patches/radiofrance.patch
--- grilo-plugins-0.3.3/debian/patches/radiofrance.patch1970-01-01 
02:00:00.0 +0200
+++ grilo-plugins-0.3.3/debian/patches/radiofrance.patch2018-01-17 
11:30:37.0 +0200
@@ -0,0 +1,24 @@
+From: Bastien Nocera <had...@hadess.net>
+Bug: https://bugzilla.gnome.org/show_bug.cgi?id=773310
+Bug-Debian: https://bugs.debian.org/887469
+Subject: Fix radiofrance unset URLs after recent website changes
+Origin: 
https://github.com/grilofw/grilo-plugins/commit/4617b91983792f3282757b93134f0b7e8f287d52
+Index: grilo-plugins/src/lua-factory/sources/grl-radiofrance.lua
+===
+--- grilo-plugins.orig/src/lua-factory/sources/grl-radiofrance.lua
 grilo-plugins/src/lua-factory/sources/grl-radiofrance.lua
+@@ -105,9 +105,12 @@ function create_media(id, result)
+ media.id = 'fip'
+   end
+ 
+-  media.url = result:match("liveUrl: '(.-)',")
++  media.url = result:match("urlLive:'(http.-%mp3)")
+   if not media.url then
+-media.url = result:match('"player" href="(http.-%.mp3)')
++media.url = result:match('player" href="(http.-%.mp3)')
++  end
++  if not media.url then
++media.url = result:match('data%-url%-live="(http.-%.mp3)')
+   end
+ 
+   media.title = get_title(id)
diff -Nru grilo-plugins-0.3.3/debian/patches/series 
grilo-plugins-0.3.3/debian/patches/series
--- grilo-plugins-0.3.3/debian/patches/series   1970-01-01 02:00:00.0 
+0200
+++ grilo-plugins-0.3.3/debian/patches/series   2018-01-17 11:30:37.0 
+0200
@@ -0,0 +1 @@
+radiofrance.patch

Bug#887469: grilo-plugins-0.3: radiofrance source broken

[Alberto Garcia]

On Wed, Jan 17, 2018 at 03:05:44PM +0100, Antoine Musso wrote:

> I went with apt-get source, rebuild and installed the package. In
> Rhythmbox I now have the radios:
> 
>  France Inter
>  France Culture
>  France Musique
>  FIP
>  Mouv'

Yeah I just tried the patch here and I can see those as well. I'll
take care of this then.

Berto

Bug#887469: grilo-plugins-0.3: radiofrance source broken

[Alberto Garcia]

On Tue, Jan 16, 2018 at 11:54:55PM +0100, Antoine Musso wrote:
> Package: grilo-plugins-0.3
> Version: 0.3.3-1
> Severity: normal
> 
> Dear Maintainer,
> 
> On Stretch using Rhythmbox I have enabled the grilo plugin which get
> me a lot of online sources automagically. Notably a Radio France
> list but unfortunately it lists a single radio "Mouv'" when there
> are several of them.
> 
> Turns out the URL have been changed since 0.3.3 and a patch needs to
> be applied and release for stretch.
> 
> The upstream bug with patch:
> https://bugzilla.gnome.org/show_bug.cgi?id=773310
> 
> The commit is 4617b91983792f3282757b93134f0b7e8f287d52

Thanks for the bug report.

I can take care of this. Is that patch enough to fix the problem?

Thanks!

Berto

Bug#866503: webkit2gtk: stuttering audio playback

[Alberto Garcia]

Control: tags -1 moreinfo

> > I just got an upgrade to surf-2.0 in Debian testing. I use surf
> > for this site:
> > 
> > http://radio.dos.nl/
> > 
> > But on several computers the sound is interrupted a few times
> > per second (I think depending on the bitrate). Downgrading to
> > 0.7 resolves the problem. Can you try this site to see if you
> > encounter the same issues?
> 
> Thank you for testing surf and providing feedback.
> 
> I can reproduce the issue you described. On the site you mentioned
> the sound is also stuttering for me (1-2 times per second), though
> it works fine on other sites like YouTube.

I can't reproduce this problem anymore (I'm using webkit2gtk 2.18.4).
Does it still happen to you?

Berto

Bug#883712: webkit2gtk: Add Debian to webkit user agent string

[Alberto Garcia]

Control: tags 883712 pending

On Mon, Dec 11, 2017 at 09:44:45PM -0500, Jeremy Bicha wrote:
> > If the only debate is having statistics of OS popularity vs making
> > the user harder to identify, I think I choose the latter. I don't
> > know what the rest of the team thinks...
> 
> Like I said, I think Ubuntu wants it. How about this patch then?

That looks good to me. Applied, thanks!

Berto

Bug#883712: webkit2gtk: Add Debian to webkit user agent string

[Alberto Garcia]

On Thu, Dec 07, 2017 at 11:38:11AM -0500, Jeremy Bicha wrote:

> As for whether it makes sense for Debian, I guess you have to decide
> whether it's more useful to be able to see how popular Debian is on
> websites that report OS statistics (like Wikipedia) or whether it's
> more useful to hide that info to make it a bit tougher for third
> parties to identify our users (of course, website owners already
> know the IP address of every visitor).

If the only debate is having statistics of OS popularity vs making the
user harder to identify, I think I choose the latter. I don't know
what the rest of the team thinks...

Berto

Bug#883712: webkit2gtk: Add Debian to webkit user agent string

[Alberto Garcia]

On Wed, Dec 06, 2017 at 01:14:52PM -0500, Jeremy Bicha wrote:

> Consider applying the Fedora patch to add Debian to the webkit user
> agent string.

What are the reasons for adding the distributor name to the user agent
string? Does it solve any problem?

Thanks!

Berto

Bug#881341: webkit2gtk FTCBFS: debian/rules confuses build and host

[Alberto Garcia]

On Fri, Nov 10, 2017 at 07:07:00PM +0100, Helmut Grohne wrote:

> > > ifeq ($(DEB_HOST_ARCH_BITS),32)
> > >   LDFLAGS += -Wl,--no-keep-memory
> > >  endif
> > >  
> > > -ifeq ($(DEB_BUILD_ARCH),alpha)
> > > +ifeq ($(DEB_HOST_ARCH),alpha)
> > >   LDFLAGS += -Wl,--no-relax
> > >  endif
> > 
> > Wait a minute, why do you change this to DEB_HOST_ARCH here? Shouldn't
> > we be using the DEB_BUILD_* variables in these two cases?
> 
> I think you are confusing build and host again.
> 
> If you check DEB_BUILD_ARCH, then you will pass -Wl,--no-relax when
> building for amd64 on alpha. Since --no-relax is machine-dependent,
> that seems wrong to me. In general, changing the build architecture
> should not affect the resulting binary packages. Passing different
> flags for different build architectures often breaks that.

Both those flags (--no-keep-memory and --no-relax) plus the -g1 that
you're changing in your patch were added because the build was failing
(not enough memory, at least in the 1st and the 3rd case).

If the build machine is able to compile webkit without those flags
then there's no need to add them, so if I'm understanding it right it
doesn't depend on the target architecture but on the machine where
you're doing the build.

For the -g1 case we probably want to do it depending on the target
architecture anyway, but for the --no-keep-memory case I don't see
why.

And now that we're at it, I'm not sure if --no-relax is even necessary
anymore. This was added for alpha in 2008 to work around a binutils
bug, which I guess has been already fixed ? It would be nice to test
that, but I don't have access to an alpha machine.

Berto

Bug#881341: webkit2gtk FTCBFS: debian/rules confuses build and host

[Alberto Garcia]

On Fri, Nov 10, 2017 at 03:49:58PM +0100, Helmut Grohne wrote:
> ifeq ($(DEB_HOST_ARCH_BITS),32)
>   LDFLAGS += -Wl,--no-keep-memory
>  endif
>  
> -ifeq ($(DEB_BUILD_ARCH),alpha)
> +ifeq ($(DEB_HOST_ARCH),alpha)
>   LDFLAGS += -Wl,--no-relax
>  endif

Wait a minute, why do you change this to DEB_HOST_ARCH here? Shouldn't
we be using the DEB_BUILD_* variables in these two cases?

Berto

Bug#881341: webkit2gtk FTCBFS: debian/rules confuses build and host

[Alberto Garcia]

Control: tags -1 pending

On Fri, Nov 10, 2017 at 03:49:58PM +0100, Helmut Grohne wrote:

> webkit2gtk fails to cross build from source for a significant number
> of reasons. One of those reasons is that debian/rules confuses build
> and host.

Thanks, I was preparing a new release and I'll include this patch.

Berto

Bug#870597: Updates?

[Alberto Garcia]

On Wed, Oct 04, 2017 at 11:10:44AM +0530, Joseph N wrote:

> Any updates on this?
> Does the upstream need need help in fixing the issue?

I have the upstream developer right here with me, we'll try to have
this fixed asap.

Berto

Bug#877281: at least suggest gstreamer1.0-alsa or gstreamer1.0-pulseaudio

[Alberto Garcia]

Control: tags -1 pending

On Sat, Sep 30, 2017 at 10:20:06AM +0800, 積丹尼 Dan Jacobson wrote:

> Try to watch a video, or even listen to a .wav file, using
> MiniBrowser.
> 
> Result: No sound.
> 
> That's because nowhere does any of the chain of
> Depends/Recommends/Suggests no matter how deep of this package
> finally reach gstreamer1.0-alsa gstreamer1.0-pulseaudio .

Ok, I'll recommend one of those plugins. This will be fixed in the
next upload.

Thanks,

Berto

Bug#876597: goocanvas FTBFS with gtk-doc-tools 1.26: gtkdoc-mktmpl is no longer available

[Alberto Garcia]

On Sun, Sep 24, 2017 at 01:08:34AM +0300, Adrian Bunk wrote:
> Source: goocanvas-2.0
> Version: 2.0.2-2
> Severity: serious
> Tags: buster sid

This seems to have been fixed in the most recent upstream version
(2.0.3). Packaging it should be enough to fix this bug.

Berto

Bug#857341: dosbox: crashes with core=dynamic: DRC64:Unhandled memory reference

[Alberto Garcia]

On Mon, Sep 25, 2017 at 07:31:11PM +0200, Jens Reyer wrote:

> >> Yes I read this, an NMU is welcome. I would also be happy if
> >> there would be a new maintainer for dosbox because I use it very
> >> rarely these days and have not much time to take care of the
> >> package.
> > 
> > Hey, thanks for the reply. I don't think I can maintain the
> > package but I can take care of this NMU. Perhaps you would like to
> > file an RFA bug in order to look for a new maintainer?
> 
> Personally I think it would be a good idea to do this within the
> pkg-wine team.  Unfortunately we're not doing much teamwork there
> atm, but maybe it's still helping e.g. Alberto to reconsider and
> take maintainership.  I would at least try to help out then, too.
> If anybody is interested in going that route just subscribe and mail
> to pkg-wine-pa...@lists.alioth.debian.org.

The upstream repository is relatively active, but there hasn't been an
official DOSBox release in 7 years and apart for a couple of bugs like
this one this program works just fine, so maintaining it shouldn't
take a lot of time.

However I don't really have much interest to maintain DOSBox at the
moment, but thanks anyway for considering me. I don't even use the
program that much, I was just annoyed by this particular bug and
wanted to fix it once and for all.

Anyway, I just updated the fixed package to DELAYED/5, it should hit
the repositories by the end of the week. I updated the changelog
message slightly, but otherwise the debdiff is the same I uploaded in
comment #35.

Berto

Bug#857341: dosbox: crashes with core=dynamic: DRC64:Unhandled memory reference

[Alberto Garcia]

On Mon, Sep 25, 2017 at 05:14:21PM +0200, Jan Dittberner wrote:

> > I can handle the NMU if the maintainer (Jan Dittberner) is busy /
> > unavailable. Jan, are you reading this?
> 
> Yes I read this, an NMU is welcome. I would also be happy if there
> would be a new maintainer for dosbox because I use it very rarely
> these days and have not much time to take care of the package.

Hey, thanks for the reply. I don't think I can maintain the package
but I can take care of this NMU. Perhaps you would like to file an RFA
bug in order to look for a new maintainer?

Regards,

Berto

Bug#857341: dosbox: crashes with core=dynamic: DRC64:Unhandled memory reference

[Alberto Garcia]

On Mon, Sep 25, 2017 at 10:26:05AM +0300, Alberto Garcia wrote:
> Anyway, this has been fixed upstream a while ago already so we should
> simply backport the solution. It's a problem in the 64bit dynamic
> recompiler and the fix is in r3951:
> 
>https://sourceforge.net/p/dosbox/code-0/3951/
> 
> However in order to apply that patch to the current Debian package you
> also need to cherry pick r3674 and r3894.

Since the patch that I just uploaded includes r3674, it should also
fix bug #799586, which has been by the way open for two years with a
patch available.

I can handle the NMU if the maintainer (Jan Dittberner) is busy /
unavailable. Jan, are you reading this?

Berto

Bug#865366: dosbox: Crash on Doom's startup

[Alberto Garcia]

Control: tags 865366 patch upstream fixed-upstream

On Tue, Jun 20, 2017 at 07:51:54PM +0200, Francesco wrote:

> Dosbox crash at Doom's startup.

This is bug #857341. This is triggered when dosbox uses the dynamic
core, used for programs that run in protected mode such as Doom.

Berto

Bug#857341: dosbox: crashes with core=dynamic: DRC64:Unhandled memory reference

[Alberto Garcia]

Control: tags 857341 patch upstream fixed-upstream

Hi,

I had a bit of time to take a look at this. Altough people are
reporting that the dosbox package in jessie (0.74-4) doesn't have
this problem, what happens is not that later versions introduced a
regression, but it rather seems that the bug was already there but was
triggered by a gcc update.

This can be seen easily if you build the jessie package with a recent
gcc version: it still crashes. I think you would need to use gcc 4 to
make it work again.

Anyway, this has been fixed upstream a while ago already so we should
simply backport the solution. It's a problem in the 64bit dynamic
recompiler and the fix is in r3951:

   https://sourceforge.net/p/dosbox/code-0/3951/

However in order to apply that patch to the current Debian package you
also need to cherry pick r3674 and r3894.

Considering that those are all the changes to that recompiler up to
that point, and that after that there was only one more bug fix made
one year ago (r3990), I think it makes sense to include all those four
changes in the Debian package.

I have just tested it and everything seems to work fine again. I'm
attaching the debdiff so it can be uploaded to Debian.

Regards,

Berto
diff -Nru dosbox-0.74/debian/changelog dosbox-0.74/debian/changelog
--- dosbox-0.74/debian/changelog2015-10-13 17:55:00.0 +0300
+++ dosbox-0.74/debian/changelog2017-09-25 09:04:55.0 +0300
@@ -1,3 +1,12 @@
+dosbox (0.74-4.3) unstable; urgency=medium
+
+  * non-maintainer upload.
+  * Update 64bit dynamic recompiler to the most recent upstream version.
+This solves a crash when core=dynamic and comes with a couple of other
+fixes. (Closes: #857341).
+
+ -- Alberto Garcia <be...@igalia.com>  Mon, 25 Sep 2017 09:04:55 +0300
+
 dosbox (0.74-4.2) unstable; urgency=medium
 
   * non-maintainer upload
diff -Nru dosbox-0.74/debian/patches/series dosbox-0.74/debian/patches/series
--- dosbox-0.74/debian/patches/series   2015-06-17 21:28:00.0 +0300
+++ dosbox-0.74/debian/patches/series   2017-09-25 09:04:55.0 +0300
@@ -3,3 +3,4 @@
 fix-ftbfs-format-security.patch
 wine-move-z-mount-svn3736.patch
 wine-style-namemangling-svn3742.patch
+update-64bit-recompiler.patch
diff -Nru dosbox-0.74/debian/patches/update-64bit-recompiler.patch 
dosbox-0.74/debian/patches/update-64bit-recompiler.patch
--- dosbox-0.74/debian/patches/update-64bit-recompiler.patch1970-01-01 
02:00:00.0 +0200
+++ dosbox-0.74/debian/patches/update-64bit-recompiler.patch2017-09-25 
09:02:42.0 +0300
@@ -0,0 +1,437 @@
+From: gulikoza
+Bug-Debian: https://bugs.debian.org/857341
+Description: Update 64bit dynamic recompiler to fix several bugs
+ This adds support for absolute 64bit addressing and fixes the
+ "Unhandled memory reference" crash. This comes from upstream SVN
+ r3951, and includes related patches r3674 and r3894. This patch also
+ contains an LLVM compile fix (r3990).
+Index: dosbox-0.74/src/cpu/core_dynrec/risc_x64.h
+===
+--- dosbox-0.74.orig/src/cpu/core_dynrec/risc_x64.h
 dosbox-0.74/src/cpu/core_dynrec/risc_x64.h
+@@ -83,36 +83,106 @@ static void gen_mov_regs(HostReg reg_dst
+   cache_addb(0xc0+(reg_dst<<3)+reg_src);
+ }
+ 
++// move a 64bit constant value into a full register
++static void gen_mov_reg_qword(HostReg dest_reg,Bit64u imm) {
++  cache_addb(0x48);
++  cache_addb(0xb8+dest_reg);  // mov dest_reg,imm
++  cache_addq(imm);
++}
+ 
+-static INLINE void gen_memaddr(HostReg reg,void* data) {
+-  Bit64s diff = (Bit64s)data-((Bit64s)cache.pos+5);
+-  if ((diff<0x8000LL) && (diff>-0x8000LL)) {
++
++// This function generates an instruction with register addressing and a 
memory location
++static INLINE void gen_reg_memaddr(HostReg reg,void* data,Bit8u op,Bit8u 
prefix=0) {
++  Bit64s diff = (Bit64s)data-((Bit64s)cache.pos+(prefix?7:6));
++//if ((diff<0x8000LL) && (diff>-0x8000LL)) { //clang messes 
itself up on this...
++  if ( (diff>>63) == (diff>>31) ) { //signed bit extend, test to see if 
value fits in a Bit32s
++  // mov reg,[rip+diff] (or similar, depending on the op) to 
fetch *data
++  if(prefix) cache_addb(prefix);
++  cache_addb(op);
+   cache_addb(0x05+(reg<<3));
+   // RIP-relative addressing is offset after the instruction 
+   cache_addd((Bit32u)(((Bit64u)diff)&0xLL)); 
+   } else if ((Bit64u)data<0x1LL) {
++  // mov reg,[data] (or similar, depending on the op) when 
absolute address of data is <4GB
++  if(prefix) cache_addb(prefix);
++  cache_addb(op);
+   cache_addw(0x2504+(reg<<3));
+   cache_addd((Bit32u)(((Bit64u)data)&0xLL));
+   } else {
+- 

Bug#774848: git: "git rebase -i" fails with "index.lock: File exists" every now and then

[Alberto Garcia]

On Tue, Mar 07, 2017 at 06:26:23PM -0800, Jonathan Nieder wrote:

> >> PS: Still occurring with Git 2.1.4 of jessie.
> >
> > I'm having this problem very often even with the latest git from
> > unstable (1:2.11.0-2).
> 
> Thanks for writing. Please file a separate bug with details about
> what steps you use to reproduce it and the exact output.  If you can
> get output with the GIT_TRACE environment variable set to 1, that's
> even better.

I'm still having problems with this once a while. I had opened a
separate bug (#862895) with more information, and then I closed it
when I thought that the problem had disappeared, but I still run into
this every now and then.

I'm using git 1:2.11.0-3+deb9u1 now.

Berto

Bug#876257: libwebkit2gtk-4.0-37: blocks upgrade path for libgstreamer-plugins-bad1.0-0 1.12.3

[Alberto Garcia]

On Wed, Sep 20, 2017 at 01:04:20PM +0300, Sebastian Dröge wrote:

> > > libgstreamer-plugins-bad1.0-0 (>= 1.12.2), libgstreamer-plugins-bad1.0-0 
> > > (<< 1.12.3)

> > That's gst-plugins-bad:
> > 
> > DEB_DH_MAKESHLIBS_ARGS_libgstreamer-plugins-bad$(gst_deb_abi) += -V 
> > "libgstreamer-plugins-bad$(gst_deb_abi) (>= $(gst_version)), 
> > libgstreamer-plugins-bad$(gst_deb_abi) (<< $(gst_version_next))"
> > 
> > I understand that its rdeps need to be rebuilt each time there's a
> > new upstream version, or how is that supposed to work? Sebastian?
> 
> That's correct. The API and ABI of the libraries in gst-plugins-bad
> is not stable and can change every release.
> 
> However only every new minor release, not micro release.  So >= 1.12
> < 1.13 would be sufficient here and probably would solve most of the
> headaches.
> 
> Feel free to send me a patch or NMU directly for that, otherwise
> I'll get it done with the next upload.

I see, thanks. This particular instance is alreay being dealt with
(#876227) so no hurries here. I think it's fine if the version
contraints in gstreamer are updated in the next upload.

Thanks!!

Berto

Bug#876257: libwebkit2gtk-4.0-37: blocks upgrade path for libgstreamer-plugins-bad1.0-0 1.12.3

[Alberto Garcia]

On Wed, Sep 20, 2017 at 10:53:07AM +0200, Antonio Ospite wrote:
> it looks like libwebkit2gtk-4.0-37 is blocking the upgrade path
> for libgstreamer-plugins-bad1.0-0 1.12.3, looking at the package
> dependencies I spotted these constraints:
> 
> libgstreamer-plugins-bad1.0-0 (>= 1.12.2), libgstreamer-plugins-bad1.0-0 (<< 
> 1.12.3)
> 
> which explain the issue.
> 
> However I am not sure about why both constraints are there.

That's gst-plugins-bad:

DEB_DH_MAKESHLIBS_ARGS_libgstreamer-plugins-bad$(gst_deb_abi) += -V 
"libgstreamer-plugins-bad$(gst_deb_abi) (>= $(gst_version)), 
libgstreamer-plugins-bad$(gst_deb_abi) (<< $(gst_version_next))"

From its changelog:

  + Split the libraries into their own package and add a -dev package.
The API of the library is not guaranteed to be stable and as such
the shlibs of the library package are very strict and will require
dependant libraries to get a rebuild after every new upstream version.

I understand that its rdeps need to be rebuilt each time there's a new
upstream version, or how is that supposed to work? Sebastian?

Berto

Bug#872994: fuse-emulator-gtk: screen with wrong size at startup.

[Alberto Garcia]

Control: reassign 872994 libgtk-3.0 3.22.21-1
Control: affects 872994 fuse-emulator-gtk

Hi again,

I'm reassigning this bug, so here's the summary of the problem:

   "when I start fuse-emulator-gtk, it opens with a streched window
   size and does not show the bottom screen of ZX Spectrum.

   If I maximize the window, it shows all the zx spectrum screen, but
   in normal window size, it doesn't."

This is a problem that only happens with Wayland, and only in the GTK+
version of the Fuse emulator (the SDL build works fine), so I suspect
the problem is in the Wayland backend of GTK+.

I'm reassigning it to libgtk-3-0, although I have to say that I
also notice some other odd behaviour when I run the desktop with
WaylandEnable=true, especially the keyboard input is more unreliable.

I can reproduce it with:

   libgtk-3-03.22.21-1
   libglib2.0-0  2.54.0-1
   xwayland  2:1.19.3-2
   gdm3  3.26.0-1
   fuse-emulator-gtk 1.4.0+dfsg1-1

Berto

Bug#872994: fuse-emulator-gtk: screen with wrong size at startup.

[Alberto Garcia]

On Tue, Aug 29, 2017 at 07:55:21PM +, Reds Reds wrote:
> Hi,
> 
> yes, I had problems with gedit which didn't load as root in terminal
> Window.
> 
> The problem is X related with the new wayland config. I disabled it
> and everything is ok now.

Can you try enabling wayland again and see if fuse-emulator-sdl also
has problems, or is it only fuse-emulator-gtk?

Thanks!

Berto

Bug#866121: add Depends gvfs-backends

[Alberto Garcia]

On Tue, Jun 27, 2017 at 10:09:53PM +0800, 積丹尼 Dan Jacobson wrote:

> Add Depends: gvfs-backends
> or else right out of the box
> $ epiphany
> will produce error messages and the add blocker won't work.
> 
> Or, just add it as a Recommends,

I confirm this, a user has just reported this same problem to me, and
it's not obvious what the missing component is.

So I'd add gvfs-backends as a recommended package.

Berto

Bug#872994: fuse-emulator-gtk: screen with wrong size at startup.

[Alberto Garcia]

On Fri, Aug 25, 2017 at 09:21:29PM +, Reds Reds wrote:

> No, right now I don't see any error.
> 
> It had to do with wayland option.
> 
> I have other emulators, and Vice for commodore 64 didn't run at all
> when I executed it.
> 
> With wayland disabled, everything is normal again.

Ok... that might be a problem in Gtk perhaps? Did you notice anything
strange with other apps, or is it only with Fuse and Vice?

Berto

Bug#873084: failed to open swrast (search paths /usr/lib/x86_64-linux-gnu/dri:${ORIGIN}/dri:/usr/lib/dri)

[Alberto Garcia]

On Fri, Aug 25, 2017 at 10:31:48PM +0800, 積丹尼 Dan Jacobson wrote:

> Please add libgl1-mesa-dri to Depends or at least Recommends or
> Suggests, else one cannot even use Google Maps, a basic use of the
> web.

Note that libgl1-mesa-dri is already recommended by libgl1-mesa-glx,
one of the dependencies of libwebkit2gtk-4.0-37

Berto

Bug#870814: show message if unable to play video

[Alberto Garcia]

On Sat, Aug 05, 2017 at 09:07:59PM +0800, 積丹尼 Dan Jacobson wrote:
> Package: libwebkit2gtk-4.0-37
> Version: 2.17.5-2
> 
> $ set https://www.youtube.com/watch?v=3i1r12rkqAU
> $ /usr/lib/i386-linux-gnu/webkit2gtk-4.0/MiniBrowser $@
> User just sees a black box where the video is supposed to play.

Is there any error message if you launch the MiniBrowser from the
command line?

Berto

Bug#873084: failed to open swrast (search paths /usr/lib/x86_64-linux-gnu/dri:${ORIGIN}/dri:/usr/lib/dri)

[Alberto Garcia]

On Thu, Aug 24, 2017 at 08:10:15PM +0800, 積丹尼 Dan Jacobson wrote:
> Package: libwebkit2gtk-4.0-37
> Version: 2.17.91-1
> Severity: important
> File: /usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/MiniBrowser
> 
> Can't even use Google Maps.
> 
> $ /usr/lib/x86_64-linux-gnu/webkit2gtk-4.0/MiniBrowser https://maps.google.com
> libEGL warning: DRI2: failed to authenticate
> libEGL warning: DRI2: failed to open swrast (search paths 
> /usr/lib/x86_64-linux-gnu/dri:${ORIGIN}/dri:/usr/lib/dri)

$ cd /usr/lib/*/dri/ ; ls *swrast*
kms_swrast_dri.so  swrast_dri.so

Do you have the libgl1-mesa-dri package installed? If not, and that
solves the problem, please tell me.

Thanks!

Berto

Bug#872994: fuse-emulator-gtk: screen with wrong size at startup.

[Alberto Garcia]

On Thu, Aug 24, 2017 at 09:16:31PM +, Reds Reds wrote:

> I found the problem.
> 
> It has to do with wayland. I put WaylandEnable=false in
> /etc/gdm3/daemon.conf and fuse is working normal now. I was having
> other issues with graphical apps called with root giving "can't
> connect to X" errors.
> 
> I didn't change this setting before, so I guess it's a new thing in
> debian.

Oh, I see. If you start fuse from the command-line (a terminal), do
you see any error messages?

I see this one:

Gtk-CRITICAL **: gtk_distribute_natural_allocation: assertion 'extra_space >= 
0' failed

Berto

Bug#872994: fuse-emulator-gtk: screen with wrong size at startup.

[Alberto Garcia]

On Wed, Aug 23, 2017 at 10:59:44PM +, Reds Reds wrote:

> I have more information for you. I compiled the fuse-emulator-gtk
> and the compiled app is working fine.

This is odd, I also tried the same version of fuse you're using with
the exact same list of libraries and everything works fine...

Try removing ~/.fuserc and see if it makes a difference.

What is your screen resolution?

Berto

Bug#872994: fuse-emulator-gtk: screen with wrong size at startup.

[Alberto Garcia]

On Wed, Aug 23, 2017 at 01:21:37PM +0100, Reds wrote:

> when I start fuse-emulator-gtk, it opens with a streched window size
> and does not show the bottom screen of ZX Spectrum.

Can you go to Options -> Filter and tell me what filter you have
selected? Do things improve if you select a different filter?

Berto

Bug#870597: filetea: Please upgrade package to 0.1.18 to support reverse proxy

[Alberto Garcia]

On Thu, Aug 03, 2017 at 01:31:22PM +0530, njoseph wrote:

> The current version of package filetea on Debian doesn't support
> running the filetea server behind a reverse proxy. This feature has
> been introduced in version 0.1.18. Please upgrade the package to the
> release 0.1.18.

Hi, it seems that FileTea 0.1.18 does not build with the latest
published version of EventDance (0.1.28), I'll discuss it with
upstream first.

Berto

Bug#870409: webkit2gtk: FTBFS on hppa - WebKitEnumTypes.h:27:0: error: unterminated #ifndef

[Alberto Garcia]

On Thu, Aug 03, 2017 at 11:16:52PM -0400, Jeremy Bicha wrote:
> On Thu, Aug 3, 2017 at 3:25 AM, Alberto Garcia <be...@igalia.com> wrote:
> > This change is not necessary because the problem will be fixed in glib
> > (see bug #870310).
> 
> By the way, the fixed glib2.0 is now in unstable.

Great, thanks.

Fortunately webkit built fine in unstable, this bug was introduced
later, but it did affect the version in experimental. I just uploaded
a new one, though, so it should build with the fixed glib.

John, about the WTF_CPU_NEEDS_ALIGNED_ACCESS bit for HPPA, I believe
that it should be fixed directly upstream, can you file a bug there or
do you prefer that I do it?

Berto

Bug#747244: gnome-terminal: mouse cursor hides when typing and won't unhide when moving it again

[Alberto Garcia]

On Wed, Nov 23, 2016 at 11:18:18PM +0100, Egmont Koblinger wrote:

> I belive this is the same as the upstream bug at
> https://bugzilla.gnome.org/show_bug.cgi?id=725342, which in turn boiled
> down to the Gtk+ focus-out issue:
> https://bugzilla.gnome.org/show_bug.cgi?id=677329.
> 
> If so, it's fixed in gtk+ 3.18.9.

I still have this problem (gtk+ 3.22.11-1, gnome-terminal 3.22.2-1).

Berto

Bug#870409: webkit2gtk: FTBFS on hppa - WebKitEnumTypes.h:27:0: error: unterminated #ifndef

[Alberto Garcia]

On Wed, Aug 02, 2017 at 10:52:26AM -0400, John David Anglin wrote:
> --- webkit2gtk-2.16.6.orig/Source/WebKit2/UIProcess/API/gtk/WebKitWebContext.h
> +++ webkit2gtk-2.16.6/Source/WebKit2/UIProcess/API/gtk/WebKitWebContext.h
> @@ -77,7 +77,7 @@ typedef enum {
>   *   can crash while the rest of the views keep working normally. This
>   *   process model is indicated for applications which may use a number
>   *   of web views and the content of in each must not interfere with the
> - *   rest — for example a full-fledged web browser with support for
> + *   rest - for example a full-fledged web browser with support for
>   *   multiple tabs.

This change is not necessary because the problem will be fixed in glib
(see bug #870310).

>  #endif /* ARM */
>  
> -#if CPU(ARM) || CPU(MIPS) || CPU(SH4) || CPU(SPARC64) || CPU(ALPHA)
> +#if CPU(ARM) || CPU(MIPS) || CPU(SH4) || CPU(SPARC64) || CPU(ALPHA) 
> ||CPU(HPPA)
>  #define WTF_CPU_NEEDS_ALIGNED_ACCESS 1
>  #endif

OK

Berto

Bug#870409: webkit2gtk: FTBFS on hppa - WebKitEnumTypes.h:27:0: error: unterminated #ifndef

[Alberto Garcia]

Control: forwarded -1 https://bugs.webkit.org/show_bug.cgi?id=175040
Control: tags -1 upstream

On Tue, Aug 01, 2017 at 08:52:54PM +0200, Alberto Garcia wrote:

> What I don't get is what that has to do with the missing #endif in
> the WebKitEnumTypes.h file.

I saw the problem, there's a non-ascii character in WebKitWebContext.h
and glib-mkenums fails if the locale is POSIX:

Traceback (most recent call last):
  File "/usr/bin/glib-mkenums", line 669, in 
process_file(fname)
  File "/usr/bin/glib-mkenums", line 406, in process_file
line = curfile.readline()
  File "/usr/lib/python3.5/encodings/ascii.py", line 26, in decode
return codecs.ascii_decode(input, self.errors)[0]
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 3887: 
ordinal not in range(128)

I'll try to have it fixed.

Berto

Bug#870409: webkit2gtk: FTBFS on hppa - WebKitEnumTypes.h:27:0: error: unterminated #ifndef

[Alberto Garcia]

On Tue, Aug 01, 2017 at 02:15:29PM -0400, John David Anglin wrote:
> Source: webkit2gtk
> Version: 2.16.6-1
> Severity: normal
> 
> Dear Maintainer,
> 
> The following error occurs building webkit2gtk on hppa:

I just saw the same problem with 2.17.5 and arm64.

> In file included from 
> /<>/Source/WebKit2/UIProcess/API/gtk/WebKitCookieManager.cpp:26:0:
> /<>/obj-hppa-linux-gnu/DerivedSources/webkit2gtk/webkit2/WebKitEnumTypes.h:27:0:
>  error: unterminated #ifndef
>  #ifndef WEBKIT_ENUM_TYPES_H
> 
> Full build logs are here:
> https://buildd.debian.org/status/fetch.php?pkg=webkit2gtk=hppa=2.16.6-1=1501516291=0
> https://buildd.debian.org/status/fetch.php?pkg=webkit2gtk=hppa=2.16.6-1=1501603998=0
> 
> Doing a build outside buildd to try and find more details.  The problem isn't
> in the template.
> 
> I noticed the following patch in the fix-ftbfs-alpha.patch:
> 
> Index: webkitgtk/Source/WTF/wtf/Platform.h
> ===
> --- webkitgtk.orig/Source/WTF/wtf/Platform.h
> +++ webkitgtk/Source/WTF/wtf/Platform.h
> @@ -354,7 +354,7 @@
>  
>  #endif /* ARM */
>  
> -#if CPU(ARM) || CPU(MIPS) || CPU(SH4) || CPU(SPARC64)
> +#if CPU(ARM) || CPU(MIPS) || CPU(SH4) || CPU(SPARC64) || CPU(ALPHA)
>  #define WTF_CPU_NEEDS_ALIGNED_ACCESS 1
>  #endif
> 
> I believe we need to add " || CPU(HPPA)" to the list of CPUs needing
> aligned accesses.

What I don't get is what that has to do with the missing #endif in the
WebKitEnumTypes.h file.

Berto

Bug#856381: libjavascriptcoregtk-4.0-18: WebProcess hits a SIGSEV at JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback

[Alberto Garcia]

Control: tags -1 moreinfo

On Mon, Mar 06, 2017 at 01:49:48PM +0100, Alberto Garcia wrote:

> > Package: libjavascriptcoregtk-4.0-18
> > Version: 2.14.2-1
> > Severity: normal
> > Tags: upstream
> 
> Do you have steps to reproduce this bug? Does it happened often to
> you?

Are you able to reproduce this bug? stretch shipped with 2.16.3, do
you know if this is still an issue?

Berto

Bug#868126: webkit2gtk: Please add build support for m68k

[Alberto Garcia]

Control: tags -1 pending

On Thu, Jul 13, 2017 at 08:32:24AM +0200, John Paul Adrian Glaubitz wrote:

> Another update. Fixes a typo and adds another missing assertion fix.
> 
> With the patch, the package builds fine for me.

Thanks, applied. It will be included in the next release.

Berto

Bug#867345: gmime transition to 3.0

[Alberto Garcia]

Control: tags -1 - fixed-upstream

> This has already been fixed upstream, so I'll close this bug with
> the next grilo-plugins release.

Sorry, this message was intended for bug #867350, please ignore it.

Berto

Bug#867350: Bug#867345: gmime transition to 3.0

[Alberto Garcia]

Control: tags -1 fixed-upstream

On Wed, Jul 05, 2017 at 07:04:56PM -0400, Daniel Kahn Gillmor wrote:

> Please try to convert your debian packages to use libgmime-3.0-dev
> in unstable if possible, so that we can avoid shipping gmime 2.6 in
> buster.

This has already been fixed upstream, so I'll close this bug with the
next grilo-plugins release.

I can backport the patches if there's no release in a reasonable
amount of time.

Berto

Bug#867345: gmime transition to 3.0

[Alberto Garcia]

Control: tags -1 fixed-upstream

On Wed, Jul 05, 2017 at 07:04:56PM -0400, Daniel Kahn Gillmor wrote:

> Please try to convert your debian packages to use libgmime-3.0-dev
> in unstable if possible, so that we can avoid shipping gmime 2.6 in
> buster.

This has already been fixed upstream, so I'll close this bug with the
next grilo-plugins release.

I can backport the patches if there's no release in a reasonable
amount of time.

Berto

Bug#838992: mutt: using mutt, will not default to home mail directory: "c", "?" with "set folder" remains in /var/mail

[Alberto Garcia]

On Wed, Oct 05, 2016 at 01:37:39AM +0300, Alberto Garcia wrote:

> I'll also give my input on what changed in the folder navigation in
> Mutt recently.

Here's one other effect of the new folder navigation style that is
very annoying.

I have my e-mail locally in ~/mail, and let's say that I want to send
an new message with a few attachments.

When I'm in the Compose menu, I can press 'a' ('attach-file') to
select a file. Then I can navigate the filesystem (starting from
~/mail) to look for the file that I want to attach (let's say it's in
~/work/documents/reports/) and select it from there.

If I want to attach a new file, previous versions of Mutt would
start the navigation from the last directory, so I can attach 4 or
5 files very easily. The new versions forget the previous directory
and start again in ~/mail, forcing me to navigate every time to
~/work/documents/reports/. I can work around this by using tags and
the 'tag-prefix' command but the new behavior is quite annoying and
counter-intuitive.

Berto

Bug#866503: webkit2gtk: stuttering audio playback

[Alberto Garcia]

Control: forwarded -1 https://bugs.webkit.org/show_bug.cgi?id=174022 

On Thu, Jun 29, 2017 at 06:44:49PM +0200, Reiner Herrmann wrote:
> I can reproduce the issue you described. On the site you mentioned
> the sound is also stuttering for me (1-2 times per second)

Same problem here. Thanks for reporting this bug, I just filed it
upstream:

https://bugs.webkit.org/show_bug.cgi?id=174022

Berto

Bug#860176: [Pkg-mutt-maintainers] Bug#860176: mutt: segfaults when trying to show a progress bar

[Alberto Garcia]

On Sun, Apr 16, 2017 at 05:36:52AM +, Antonio Radici wrote:

> > Simply replacing  with pbar in that call and
> > refreshing the patch fixes the problem.
> 
> This sounds like a bug that should be fixed before stretch is
> released, I'll submit your patch on Monday.

Oops, seems like we missed the stretch release :( Can it be fixed in
sid at least?

Thanks!

Berto

Bug#864318: unblock: filetea/0.1.16-4

[Alberto Garcia]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package filetea

The version of Filetea currently in testing (0.1.16-3) does not
work at all because of an API change in one of its dependencies
(libjs-jquery).

See https://bugs.debian.org/862742 for more details.

In addition to that, 0.1.16-4 contains the following changes, all of
them trivial:

   - Replace the build dependency on the libgcrypt11-dev transition
 package (#864101).
   - Correct the homepage URL.
   - Add the missing dependency on lsb-base (fixes a lintian error).
   - Update Standards-Version to 3.9.8 (no changes to the package).
   - Add the name of the manpage to the systemd service file.

The debdiff comparing both versions is attached.

Regards,

Berto

unblock filetea/0.1.16-4

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64
 (x86_64)

Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru filetea-0.1.16/debian/changelog filetea-0.1.16/debian/changelog
--- filetea-0.1.16/debian/changelog 2014-08-27 16:15:15.0 +0300
+++ filetea-0.1.16/debian/changelog 2017-06-06 12:01:04.0 +0300
@@ -1,3 +1,20 @@
+filetea (0.1.16-4) unstable; urgency=high
+
+  * debian/control:
+- Replace build dependency on libgcrypt11-dev with libgcrypt20-dev
+  (Closes: #864101).
+- Update Homepage URL.
+- Update Standards-Version to 3.9.8 (no changes).
+- Depend on lsb-base (>= 3.0-6).
+  * debian/patches/jquery-compat.patch:
+- Make Filetea work with libjs-jquery 3.x (Closes: #862742).
+  * debian/patches/systemd.patch:
+- Add missing Documentation key.
+  * debian/copyright:
+- Update copyright years.
+
+ -- Alberto Garcia <be...@igalia.com>  Tue, 06 Jun 2017 12:01:04 +0300
+
 filetea (0.1.16-3) unstable; urgency=medium
 
   * Add systemd service file.
diff -Nru filetea-0.1.16/debian/control filetea-0.1.16/debian/control
--- filetea-0.1.16/debian/control   2014-08-27 16:15:15.0 +0300
+++ filetea-0.1.16/debian/control   2017-06-06 12:01:04.0 +0300
@@ -6,11 +6,11 @@
dh-autoreconf,
dh-systemd,
uuid-dev,
-   libgcrypt11-dev,
+   libgcrypt20-dev,
libevd-0.1-dev (>= 0.1.18),
libjson-glib-dev (>= 0.10.0)
-Standards-Version: 3.9.5
-Homepage: https://gitorious.org/filetea
+Standards-Version: 3.9.8
+Homepage: https://github.com/elima/FileTea
 
 Package: filetea
 Architecture: any
@@ -18,6 +18,7 @@
  adduser,
  shared-mime-info,
  libjs-jquery,
+ lsb-base (>= 3.0-6),
  ${misc:Depends}
 Suggests: ssl-cert
 Description: Web-based file sharing system
diff -Nru filetea-0.1.16/debian/copyright filetea-0.1.16/debian/copyright
--- filetea-0.1.16/debian/copyright 2014-08-27 16:15:15.0 +0300
+++ filetea-0.1.16/debian/copyright 2017-06-06 12:01:04.0 +0300
@@ -15,7 +15,7 @@
 License: Expat or GPL-2
 
 Files: debian/*
-Copyright: 2011-2013 Alberto Garcia <be...@igalia.com>
+Copyright: 2011-2013,2017 Alberto Garcia <be...@igalia.com>
 License: AGPL-3+
 
 License: GPL-2
diff -Nru filetea-0.1.16/debian/patches/jquery-compat.patch 
filetea-0.1.16/debian/patches/jquery-compat.patch
--- filetea-0.1.16/debian/patches/jquery-compat.patch   1970-01-01 
02:00:00.0 +0200
+++ filetea-0.1.16/debian/patches/jquery-compat.patch   2017-06-06 
12:01:04.0 +0300
@@ -0,0 +1,140 @@
+From: harikrishnakanchi <harikrishnakan...@gmail.com>
+Subject: Make Filetea work with jQuery 3
+Bug-Debian: https://bugs.debian.org/862742
+Index: filetea/html/default/transfersView.js
+===
+--- filetea.orig/html/default/transfersView.js
 filetea/html/default/transfersView.js
+@@ -73,6 +73,24 @@ Evd.Object.extend (TransfersView.prototy
+ "aborted",
+ "aborted"
+ ];
++this._cancelDialog = $ ("#transfer-list-confirm-cancel");
++this._cancelDialog.dialog({
++modal: true,
++title: "Cancel transfer",
++autoOpen: false,
++buttons: {
++"Yes": function () {
++var id = $ (this).dialog("option", "transferId");
++self._transfers.cancel ([id]);
++
++$ (this).dialog ("close");
++},
++"No": function () {
++$ (this).dialog ("close");
++}
++}
++});
++
+ },
+ 
+ _

Bug#862742: Error report for filetea

[Alberto Garcia]

On Tue, May 23, 2017 at 09:24:31AM +, Hari Krishna wrote:

> This is the patch for making filetea to work with jQuery
> v3.2.x. Hope this helps. Apply to upstream if needed.

This patch does not apply cleanly on the version of Filetea available
in Debian (0.1.16).

I'll try to backport it.

Berto

Bug#862742: Error report for filetea

[Alberto Garcia]

On Tue, Jun 06, 2017 at 11:32:43AM +0300, Adrian Bunk wrote:

> > > This is the patch for making filetea to work with jQuery
> > > v3.2.x. Hope this helps. Apply to upstream if needed.
> > 
> > Thanks for the patch, I'll forward it to upstream and discuss it
> > with him.
> > 
> > I guess another simpler possibility for the Debian case is to use
> > the libjs-jquery-migrate-1 package.
> 
> If filetea should not be removed from stretch, a fix has to be in
> unstable no later than tomorrow morning.

Thanks for pinging me, I'll try to upload the fixed version today.

Berto

Bug#862742: Error report for filetea

[Alberto Garcia]

On Tue, May 23, 2017 at 09:24:31AM +, Hari Krishna wrote:

> This is the patch for making filetea to work with jQuery v3.2.x. Hope this
> helps. Apply to upstream if needed.

Thanks for the patch, I'll forward it to upstream and discuss it with
him.

I guess another simpler possibility for the Debian case is to use the
libjs-jquery-migrate-1 package.

Berto

Bug#862742: Error report for filetea

[Alberto Garcia]

Control: tags -1 - unreproducible moreinfo

On Tue, May 23, 2017 at 07:14:39AM +, Hari Krishna wrote:

> ".live" method has been removed in jQuery version 1.9+. Please refer
> https://jquery.com/upgrade-guide/1.9/#live-removed

Yeah, I'm not sure how it worked last time I tried but I managed to
reproduce the problem now, thanks.

Berto

Bug#862742: filetea: Wrong version of jQuery gets installed

[Alberto Garcia]

Control: tags -1 moreinfo unreproducible

On Tue, May 16, 2017 at 12:30:10PM +, Rahul De wrote:

> The package uses the function live which has been removed in
> jQuery 1.9.  The source in the upstream depends on 1.7.2 and no
> version has been mentioned in the control file of the packaging
> for libjs-jquery. Hence the latest version(3.1.1) is fetched which
> breaks it and makes it unusable for everyone.

Hi,

I just tried filetea 0.1.16-3+b1 with libjs-jquery 3.1.1-2 and it
seems to work just fine. I shared a file between two machines without
problems.

What is the problem that you are having exactly?

Berto

Bug#862895: git rebase fails often with "index.lock: File exists"

[Alberto Garcia]

Package: git
Version: 1:2.11.0-3
Severity: normal

Hi!

this looks very similar to bug #774848, but I'm filing a separate bug
as requested.

I'm having problems with 'git rebase' once a while. I cannot find a
pattern that explains why it fails: sometimes it works fine, sometimes
it produces an error message. After the error it's usually enough with
running 'git rebase --abort' and repeating the process.

Because of this it's not always easy to reproduce it, but I just did
now: I was trying to pull from the upstream QEMU repository. My master
branch had one additional commit from me, so I did 'git pull --rebase'
to ensure that my commit remains on top.

There's no index.lock file, and git has not crashed as far as I'm
aware (syslog also shows nothing odd). I'm including the full output
below with GIT_TRACE=1.

Perhaps the only thing "special" about this repository is that it was
cloned using 'git clone --reference', and thus has an 'alternates'
file (.git/objects/info/alternates). Other than that, I've been using
this for a long time without any problems until around the beginning
of 2016 if I recall correctly.

Thanks!

Berto

$ GIT_TRACE=1 git pull --rebase
11:15:36.867251 git.c:371   trace: built-in: git 'pull' '--rebase'
11:15:36.880735 run-command.c:350   trace: run_command: 'merge-base' 
'--fork-point' 'refs/remotes/origin/master' 'master'
11:15:36.936053 run-command.c:350   trace: run_command: 'fetch' 
'--update-head-ok'
11:15:36.936333 exec_cmd.c:116  trace: exec: 'git' 'fetch' 
'--update-head-ok'
11:15:36.937298 git.c:371   trace: built-in: git 'fetch' 
'--update-head-ok'
11:15:36.941266 run-command.c:350   trace: run_command: 'git-remote-https' 
'origin' 'https://github.com/qemu/qemu'
11:15:38.001933 run-command.c:350   trace: run_command: 'rev-list' 
'--objects' '--stdin' '--not' '--all' '--quiet'
11:15:38.018560 run-command.c:350   trace: run_command: 'rev-list' 
'--objects' '--stdin' '--not' '--all' '--quiet'
11:15:38.018992 exec_cmd.c:116  trace: exec: 'git' 'rev-list' 
'--objects' '--stdin' '--not' '--all' '--quiet'
11:15:38.020063 git.c:371   trace: built-in: git 'rev-list' 
'--objects' '--stdin' '--not' '--all' '--quiet'
11:15:38.043289 run-command.c:1130  run_processes_parallel: preparing to 
run up to 1 tasks
11:15:38.043435 run-command.c:1162  run_processes_parallel: done
11:15:38.043898 run-command.c:350   trace: run_command: 'gc' '--auto'
11:15:38.044160 exec_cmd.c:116  trace: exec: 'git' 'gc' '--auto'
11:15:38.045213 git.c:371   trace: built-in: git 'gc' '--auto'
11:15:38.049490 run-command.c:350   trace: run_command: 'rebase' '--onto' 
'cdece0467c7cf8e3f4b3c3f0b13bf2c4fea9' 
'cdece0467c7cf8e3f4b3c3f0b13bf2c4fea9'
11:15:38.049768 exec_cmd.c:116  trace: exec: 'git' 'rebase' '--onto' 
'cdece0467c7cf8e3f4b3c3f0b13bf2c4fea9' 
'cdece0467c7cf8e3f4b3c3f0b13bf2c4fea9'
11:15:38.050855 git.c:600   trace: exec: 'git-rebase' '--onto' 
'cdece0467c7cf8e3f4b3c3f0b13bf2c4fea9' 
'cdece0467c7cf8e3f4b3c3f0b13bf2c4fea9'
11:15:38.050890 run-command.c:350   trace: run_command: 'git-rebase' 
'--onto' 'cdece0467c7cf8e3f4b3c3f0b13bf2c4fea9' 
'cdece0467c7cf8e3f4b3c3f0b13bf2c4fea9'
11:15:38.054262 git.c:371   trace: built-in: git 'rev-parse' 
'--parseopt' '--stuck-long' '--' '--onto' 
'cdece0467c7cf8e3f4b3c3f0b13bf2c4fea9' 
'cdece0467c7cf8e3f4b3c3f0b13bf2c4fea9'
11:15:38.057001 git.c:371   trace: built-in: git 'rev-parse' 
'--git-dir'
11:15:38.058526 git.c:371   trace: built-in: git 'rev-parse' 
'--git-path' 'objects'
11:15:38.059874 git.c:371   trace: built-in: git 'rev-parse' 
'--is-bare-repository'
11:15:38.061035 git.c:371   trace: built-in: git 'rev-parse' 
'--show-toplevel'
11:15:38.063275 git.c:371   trace: built-in: git 'config' '--bool' 
'rebase.stat'
11:15:38.064884 git.c:371   trace: built-in: git 'config' '--bool' 
'rebase.autostash'
11:15:38.066078 git.c:371   trace: built-in: git 'config' '--bool' 
'rebase.autosquash'
11:15:38.067089 git.c:371   trace: built-in: git 'config' '--bool' 
'commit.gpgsign'
11:15:38.068494 git.c:371   trace: built-in: git 'rev-parse' 
'--verify' 'cdece0467c7cf8e3f4b3c3f0b13bf2c4fea9^0'
11:15:38.070227 git.c:371   trace: built-in: git 'rev-parse' 
'--verify' 'cdece0467c7cf8e3f4b3c3f0b13bf2c4fea9^0'
11:15:38.071891 git.c:371   trace: built-in: git 'symbolic-ref' 
'-q' 'HEAD'
11:15:38.073472 git.c:371   trace: built-in: git 'rev-parse' 
'--verify' 'HEAD'
11:15:38.075400 git.c:371   trace: built-in: git 'rev-parse' 
'--verify' 'HEAD'
11:15:38.076887 git.c:371   trace: built-in: git 'update-index' 
'-q' '--ignore-submodules' '--refresh'
11:15:38.082856 git.c:371   trace: built-in: git 'diff-files' 
'--quiet' 

Bug#860176: mutt: segfaults when trying to show a progress bar

[Alberto Garcia]

Package: mutt
Version: 1.7.2-1
Severity: normal
Tags: patch

Hi,

mutt crashes when I'm trying to pipe messages through an external
program because 228671-pipe-mime.patch (from Debian bug #569279) needs
to be updated.

This is the code:

   int imap_fetch_message (CONTEXT *ctx, MESSAGE *msg, int msgno)
   {
 /* ... */
 progress_t progressbar, *pbar;
 /* ... */
 if (!isendwin())
 {
   mutt_progress_init (, _("Fetching message..."),
   MUTT_PROGRESS_SIZE, NetInc, bytes);
   pbar = 
 }
 else
   pbar = NULL;
 if (imap_read_literal (msg->fp, idata, bytes, ) < 0)
 /* ... */
   }

As you can see the code is passing  to imap_read_literal()
but chances are that that variable has not been uninitialized.

Simply replacing  with pbar in that call and refreshing
the patch fixes the problem.

Berto

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mutt depends on:
ii  libassuan02.4.3-2
ii  libc6 2.24-9
ii  libcomerr21.43.4-2
ii  libgnutls30   3.5.8-3
ii  libgpg-error0 1.26-2
ii  libgpgme111.8.0-3+b2
ii  libgssapi-krb5-2  1.15-1
ii  libidn11  1.33-1
ii  libk5crypto3  1.15-1
ii  libkrb5-3 1.15-1
ii  libncursesw5  6.0+20161126-1
ii  libnotmuch4   0.23.7-3
ii  libsasl2-22.1.27~101-g0780600+dfsg-3
ii  libtinfo5 6.0+20161126-1
ii  libtokyocabinet9  1.4.48-11+b1

Versions of packages mutt recommends:
ii  libsasl2-modules  2.1.27~101-g0780600+dfsg-3
ii  locales   2.24-9
ii  mime-support  3.60

Versions of packages mutt suggests:
ii  aspell 0.60.7~20110707-3+b2
ii  ca-certificates20161130
ii  exim4-daemon-light [mail-transport-agent]  4.88-5
ii  gnupg  2.1.18-6
ii  ispell 3.4.00-5
pn  mixmaster  
ii  openssl1.1.0e-1
pn  urlview

Versions of packages mutt is related to:
ii  mutt  1.7.2-1

-- no debconf information

Bug#859100: webkit2gtk: webkit2gtk loads system-installed extensions by default

[Alberto Garcia]

On Tue, Apr 04, 2017 at 02:26:47PM +0200, Jérémy Lal wrote:

> > Try to disable them with this setting:
> >
> >
> > https://webkitgtk.org/reference/webkit2gtk/unstable/WebKitSettings.html#webkit-settings-set-enable-plugins
> 
> i'm already doing that
> 
> ```
> WebKitSettings* settings = webkit_web_view_get_settings(view);
> g_object_set(settings,
>   "enable-plugins", FALSE,
>   "enable-java", FALSE,
>   NULL
> );
> webkit_web_view_load_uri(view, uri);
> ```

Ok... would it possible for you to prepare a very simple program that
shows the problem? I can discuss it directly with the development team
and forward it upstream if necessary.

Berto