Bug#858242: libwine: winemenubuilder creates .desktop files with invalid WINEPREFIX
On 10/11/2017 08:08 PM, Sven Joachim wrote:
> On 2017-10-08 14:58 +0200, Jens Reyer wrote:
>
>> control: tags -1 + moreinfo unreproducible
>>
>> On 03/20/2017 05:22 PM, Jens Reyer wrote:
>>> On 03/20/2017 11:20 AM, Sven Joachim wrote:
>>>> wine: invalid directory "/home/sven/.wine" in WINEPREFIX: not
>>>> an absolute path
>>>>
>>>> Apparently the program was trying to run winebrowser from one
>>>> of my .desktop files under ~/.local/share/applications/, those
>>>> look like this:
>>>
>>> This was already mentioned in #845334 (wine32: breaks xdg-open,
>>> which wants to start wine and crashes). As a result of that
>>> report the .desktop files aren't generated anymore for some
>>> standard mimetypes, e.g. pdf. So the mentioned file should be a
>>> relic from older times (please verify its timestamp).
>>> Unfortunately we can't simply remove these existing files,
>>> because we can't know if they are still wanted by the user.
>>>
>>> I never saw this behavior here, but since it's now observed again
>>> I'd really like to fix it (assuming it might also be triggered by
>>> the .desktop files created by some Windows applications).
>> Tagging unreproducible because I can't reproduce it, although it
>> happened both here and in #845334.
>>
>> Tagging moreinfo because I wonder if this was some issue with
>> previous versions. Please check the timestamp of any issue-causing
>> .desktop file and report the wine version and its origin installed
>> at that time.
>
> I just had a look at the .desktop files, and the most recent ones
> are from July 23, 2017, just after I upgraded wine to 2.0.2-1. And
> they still have WINEPREFIX="/home/sven/.wine" in them, causing the
> same complaints as mentioned in my original report.
Sorry for my permanent delays.
Files for common extensions like
~/.local/share/applications/wine-extension-pdf.desktop don't get created
automatically anymore since wine-development/2.0_rc4-1 and wine/1.8.6-2.
So if your answer was for one of these files, then I assume they simply
got touched during a Wine upgrade. So looking for the timestamp is of
no use here.
Use something like this to remove this specific set of unwanted files
and update your desktop database:
rm
~/.local/share/applications/wine-extension-{chm,gif,hlp,htm,html,ini,jfif,jpe,jpeg,jpg,msp,pdf,png,rtf,txt,url,vbs,wri,xml}.desktop
update-desktop-database ~/.local/share/applications/
Then report any new issue causing file (this is the info that I need to
work on this bug).
If these specific files reappear please report a separate bug!
Now, I assume without these files for the common extensions the issue
won't be observed very often. But as soon as someone installs an
application which adds its own association that should cause this issue.
Therefore keeping the moreinfo tag and not closing the bug for now.
However I'm still absolutely clueless and ask for help to solve this
issue at its root:
I see the check for the wineprefix starting with a "/" (slash, no
quotation marks) in libs/wine/config.c[1], which is indeed the only
place in the code which has the mentioned warning. But I assume (I'm
not a C coder) that the quotation marks are not relevant here.
I still triple-checked debian/patches/debsuffix/winemenubuilder.patch,
but I don't find any issue with it. The quotation marks after
WINEPREFIX= are added by upstream, not our patch. What we do here
instead is replacing the name of the Wine binary loader in the PATH
"wine" with "wine-stable" or "wine-development".
Please someone tell me what I miss here.
Greets
jre
[1]: libs/wine/config.c:
[...]
/* build config_dir */
if (prefix)
{
config_dir = xstrdup( prefix );
remove_trailing_slashes( config_dir );
if (config_dir[0] != '/')
fatal_error( "invalid directory %s in WINEPREFIX: not an
absolute path\n", prefix );
[...]
Bug#879453: wine32: Unmet dependencies in Stretch
control: tags -1 moreinfo
Hi Omar,
in order to work on this we need to know the name of the broken packages.
So first upgrade your package sources and then install wine32 from a
terminal, e.g.:
sudo apt update && sudo apt install wine32
and check its output. Then you should try to go down the dependency
chain to find the real culprit ("apt install libfoo:i386", then "apt
install libbar:i386" and so on until you don't get any further). Paste
the full terminal output of the last command when you don't get any further.
Thus having said, since you are the first to report this I think/hope
there is no bug. Either you have some packages on hold manually or from
some 3rd party repository (note that they must have identical versions
on amd64 and i386), or maybe there was some security/stable update which
hasn't been built on all architectures yet. So my bet is, wait some
time, apt update, and see it working.
Please let us know about your progress.
Greets
jre
Bug#869233: khronos-api: Update to new version from new git repo
On 07/21/2017 08:58 PM, Jens Reyer wrote: > Package: khronos-api > Version: 0~svn29735-1.1 > Severity: wishlist > > > While working on #865307 and #865308 I saw that the Khronos Group moved, > see > https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/README.txt: > ~ > As of 2017-01-21, the OpenGL Registry has been MOVED to > > https://www.khronos.org/registry/OpenGL/ > > The new registry location is backed by a github repository at > > https://github.com/KhronosGroup/OpenGL-Registry > > There will be no further updates to the public Subversion area. We are > in the process of setting up redirects so that deep links under > opengl.org/registry will continue to work, and the old website will > remain active until those redirects are established; but everyone should > begin using the new registry on khronos.org as soon as possible. > > Please file issues with the new registry on the github repository. > ~ > > > For now I uploaded 0~svn33340-0.1, so that we have the latest version > from the old repo for comparison with the new ones. (There have been a > few more svn revisions, but they don't touch the api/ directory.) > > Next I'll be working on updating upstream Wine to the current version > and the new location. > > Then I'd like to update khronos-api here, however there are a few things > to consider: > > > 1.) Version > --- > > Currently there are no upstream releases or tags available, so we have > to continue to make our own number. > > Unfortunately 0~gitVERSION < 0~svnVERSION, so I suggest 0+gitVERSION. > > For the specific VERSION: > > A commonly used scheme (especially for golang packages) is > 0~git- > e.g.: > $ git log -1 --pretty=format:0.0~git%cd.%h --date=format:%Y%m%d%H%M > 0.0~git201707111832.9755811 > > This works without any additional tags. Also the maintainer of the > github repo may merge other branches, even if they have older committer > dates, without breaking it. AFAICS also cherry-picking an old commit, > or rebasing another branch, should work. > > > Alternatively we might tag the inital commit in the repo "0", and then > use git describe: > > $ git tag 0 2f2b0f91f0a7ed3b468e03593dde66176e9b3032 > $ git describe --tags > 0-126-g9755811 > $ VERSION="$(git describe --tags | sed "s|-|+git|")-1" > $ echo $VERSION > 0+git126-g9755811-1 > > > Any preferences or suggestions? > > > > 2.) EGL API and Extension Registry > > EGL is part of the current khronos-api package, but Khronos moved it now > to a separate repository. (I might have gotten this wrong, or missed > further changes. Can't say for sure yet.) > > This shouldn't be a problem for Wine, because it only uses gl.xml and > wgl.xml. > > But there's one other package (qtwebengine-opensource-src) which > build-depends on khronos-api. I've rebuilt that successfully with > 0~svn33340-0.1, but I don't know yet if it requires egl. > > So we have to keep that in mind, but generally I'd just suggest to drop > egl from the khronos-api package (no multi source tarball package). Hi Mike any news on this? I just uploaded Wine 2.18, but had to patch it because it requires OpenGL 4.6. Greets jre
Bug#878255: [Qa-jenkins-dev] Bug#878255: reproducible: increase the diffoscope timeout
Hi Holger, thanks for the quick answer. Of course I understand you have to prioritize overall performance over specific packages. On 10/11/2017 07:46 PM, Holger Levsen wrote: > I think you are better off with requesting the builds artifacts from our tests > and then running diffoscope yourself. I already tried with two local builds, unfortunately my machine ran out of space and/or memory then. But I'd be very happy if someone else could send me a diffoscope log of wine(-development). Should I manage that on my own, I'll update this bug here. Greets jre
Bug#878255: reproducible: increase the diffoscope timeout
Package: jenkins.debian.org Severity: normal Hi all, as discussed on irc yesterday, I'd like to ask to increase the timeout of diffoscope from 120 minutes to something more, e.g. 6 hours. Reasoning is that the wine and wine-development packages always run into this, probably just because they are quite big. I understood you might look into splitting diffoscope into a separate job first, or make other changes so that this scales better. Since this needs time to discuss, I don't expect an answer soon. Whatever, it would be great to see results for Wine sometimes again. Thanks and greets! jre
Bug#858242: libwine: winemenubuilder creates .desktop files with invalid WINEPREFIX
control: tags -1 + moreinfo unreproducible On 03/20/2017 05:22 PM, Jens Reyer wrote: > On 03/20/2017 11:20 AM, Sven Joachim wrote: >> wine: invalid directory "/home/sven/.wine" in WINEPREFIX: not an absolute >> path >> >> Apparently the program was trying to run winebrowser from one of my >> .desktop files under ~/.local/share/applications/, those look like this: > > This was already mentioned in #845334 (wine32: breaks xdg-open, which > wants to start wine and crashes). As a result of that report the > .desktop files aren't generated anymore for some standard mimetypes, > e.g. pdf. So the mentioned file should be a relic from older times > (please verify its timestamp). Unfortunately we can't simply remove > these existing files, because we can't know if they are still wanted by > the user. > > I never saw this behavior here, but since it's now observed again I'd > really like to fix it (assuming it might also be triggered by the > .desktop files created by some Windows applications). Tagging unreproducible because I can't reproduce it, although it happened both here and in #845334. Tagging moreinfo because I wonder if this was some issue with previous versions. Please check the timestamp of any issue-causing .desktop file and report the wine version and its origin installed at that time. Greets jre
Bug#877178: [pkg-wine-party] Bug#877178: Wine crashes with freetype2 2.8.1
On 09/29/2017 03:26 PM, Laurent Bigonville wrote: > It seems that the current version of wine is crashing with 2.8.1 version > of freetype. > > This is already fixed upstream Thanks Laurent. Indeed this is fixed in the *current development* version (Wine 2.18 released 2017-09-29; not yet, but probably quite soon, packaged), and will be fixed in the *upcoming stable* version (Wine 2.0.3, not announced yet, personally I expect it for October/November). I assume freetype will land in unstable really soon now, so we shouldn't wait for 2.0.3. I'll look into a separate src:wine/2.0.2-2 release later this week. > https://bugs.winehq.org/show_bug.cgi?id=43715 Fixed - in upstream master (tracked in src:wine-development) by d82321006de92dcd74465c905121618a76eae76a, and - in the preparation branch for the stable release (tracked in src:wine) by 17dfb6eba2a9e1c347b9a5e23885e08ba7c4aafc. > https://bugs.winehq.org/show_bug.cgi?id=43716 Fixed - in upstream master by 40166848a7944383a4cfdaac9b18bd03fbb2b4f9, and - for stable by ef8876f1fdeea88d36c561fa2841046f4f07e34e Greets jre
Bug#857341: dosbox: crashes with core=dynamic: DRC64:Unhandled memory reference
On 09/25/2017 05:32 PM, Alberto Garcia wrote: > 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? 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. Anyway, thank you all for your work! Greets jre (DM and wine co-maitainer)
Bug#871323: installation-reports: Successful with weekly. Daily 2017-07-31 failed. One line needs wrapping
Package: installation-reports Severity: normal Tags: newcomer The installation with the mentioned installer worked quite fine. Previously I tried the daily build (build date probably 2017-07-31): the keyboard worked in the first screen for selecting the installation method (I chose default), but no more in the language selection dialog. So I had to abort that attempt. With the weekly build there was only one minor issue (not sure where to report this, d-i, debconf or partman-crypto): The debconf question by partman-crypto was too long to be displayed on my 1920x1280 display, and was just cut off. So I read: "The installer is now overwriting /dev/sda with random data to prevent meta- information leaks from the encrypted volume. This step may be skipped by cancelling this action, albeit at the expense of a slight red" According to http://sources.debian.net/src/partman-crypto/90/debian/partman- crypto.templates/?hl=193#L193 the rest of the line was: "uction of the quality of the encryption." Just tell me if I should make another test, or file separate bugs. Greets jre -- Package-specific info: Boot method: USB stick Image version: iirc https://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/debian-testing-amd64-netinst.iso, 2017-07-24 Date: Machine: Samsung Series 9 900X4C Partitions: Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [ ] Detect network card:[ ] Configure network: [ ] Detect CD: [ ] Load installer modules: [ ] Clock/timezone setup: [ ] User/password setup:[ ] Detect hard drives: [ ] Partition hard drives: [ ] Install base system:[ ] Install tasks: [ ] Install boot loader:[ ] Overall install:[ ] Comments/Problems: -- Please make sure that the hardware-summary log file, and any other installation logs that you think would be useful are attached to this report. Please compress large files using gzip. Once you have filled out this report, mail it to sub...@bugs.debian.org. == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION="Debian GNU/Linux installer" DISTRIB_RELEASE="9 (stretch) - installer build 20170615+deb9u1" X_INSTALLATION_MEDIUM=cdrom == Installer hardware-summary: == uname -a: Linux hope 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u2 (2017-06-26) x86_64 GNU/Linux lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation 3rd Gen Core processor DRAM Controller [8086:0154] (rev 09) lspci -knn: Subsystem: Samsung Electronics Co Ltd Device [144d:c0d3] lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation 3rd Gen Core processor Graphics Controller [8086:0166] (rev 09) lspci -knn: Subsystem: Samsung Electronics Co Ltd Device [144d:c0d3] lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation 7 Series/C216 Chipset Family MEI Controller #1 [8086:1e3a] (rev 04) lspci -knn: Subsystem: Samsung Electronics Co Ltd Device [144d:c0d3] lspci -knn: 00:1b.0 Audio device [0403]: Intel Corporation 7 Series/C216 Chipset Family High Definition Audio Controller [8086:1e20] (rev 04) lspci -knn: Subsystem: Samsung Electronics Co Ltd Device [144d:c0d3] lspci -knn: Kernel driver in use: snd_hda_intel lspci -knn: Kernel modules: snd_hda_intel lspci -knn: 00:1c.0 PCI bridge [0604]: Intel Corporation 7 Series/C216 Chipset Family PCI Express Root Port 1 [8086:1e10] (rev c4) lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:1c.4 PCI bridge [0604]: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 5 [8086:1e18] (rev c4) lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:1d.0 USB controller [0c03]: Intel Corporation 7 Series/C216 Chipset Family USB Enhanced Host Controller #1 [8086:1e26] (rev 04) lspci -knn: Subsystem: Samsung Electronics Co Ltd Device [144d:c0d3] lspci -knn: Kernel driver in use: ehci-pci lspci -knn: Kernel modules: ehci_pci lspci -knn: 00:1f.0 ISA bridge [0601]: Intel Corporation HM75 Express Chipset LPC Controller [8086:1e5d] (rev 04) lspci -knn: Subsystem: Samsung Electronics Co Ltd Device [144d:c0d3] lspci -knn: 00:1f.2 SATA controller [0106]: Intel Corporation 7 Series Chipset Family 6-port SATA Controller [AHCI mode] [8086:1e03] (rev 04) lspci -knn: Subsystem: Samsung Electronics Co Ltd Device [144d:c0d3] lspci -knn: Kernel driver in use: ahci lspci -knn: Kernel modules: ahci lspci -knn: 00:1f.3 SMBus [0c05]: Intel Corporation 7 Series/C216 Chipset Family SMBus Controller [8086:1e22] (rev 04) lspci -knn: Subsystem: Samsung Electronics Co Ltd Device [144d:c0d3] lspci -knn: 01:00.0 Network controller [0280]: Intel Corporation Centrino Advanced-N 6235 [8086:088e] (rev 24) lspci -knn:
Bug#870892: debhelper: Tries building "Architecture: all" despite --binary-arch (regression compat 11).
On 08/06/2017 10:38 AM, Niels Thykier wrote: > I believe I got all the information I need to reproduce and fix the > issue now. Thanks for finding this bug and reporting it. :) Great, thanks again for your work!
Bug#870892: debhelper: Tries building "Architecture: all" despite --binary-arch (regression compat 11).
Package: debhelper Version: 10.7.2 Severity: normal Hi, I'm trying to build wine in compat 11, but the --binary-arch build fails on the binary package wine, which is "Architecture: all" - so it shouldn't be built at all here. I'm not sure if this is related to (the fix for) #863887 (debhelper: Broken handling of -indep/-arch override target in 10.3+) The same build works in compat 10. Just tell me if you need more information. Greets jre -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.11.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages debhelper depends on: ii autotools-dev20161112.1 ii binutils 2.29-3 ii dh-autoreconf14 ii dh-strip-nondeterminism 0.038-1 ii dpkg 1.18.24 ii dpkg-dev 1.18.24 ii file 1:5.30-1 ii libdpkg-perl 1.18.24 ii man-db 2.7.6.1-2 ii perl 5.26.0-5 ii po-debconf 1.0.20 debhelper recommends no packages. Versions of packages debhelper suggests: pn dh-make -- no debconf information
Bug#865308: khronos-api is not Multi-Arch compatible
On 08/01/2017 11:30 PM, Jens Reyer wrote: > Maintainer fields aren't mentioned explicitly in policy 5.11, while > large parts of Debian take a very liberal stance at NMUs nowadays. s/policy/debian reference/ Anyway, what I meant is afaic there is no rule about it.
Bug#865308: khronos-api is not Multi-Arch compatible
Hi Mike On 07/31/2017 05:11 AM, Michael Gilbert wrote: > On Fri, Jul 21, 2017 at 3:03 PM, Jens Reyer wrote: >> I just uploaded 0~svn33340-0.1 to delayed/10, debdiff attached. >> >> Changelog: >> >> khronos-api (0~svn33340-0.1) unstable; urgency=medium >> >> * Non-maintainer upload. >> * New (and final in svn) upstream revision 33340. >> * Refresh timestamps.patch. >> * Make package Multi-Arch: foreign (closes: #865308). >> Thanks to Hugh McMaster >> * Minor improvement to the package description (closes: #865307). >> * Bump standards version to 4.0.0, no changes needed. >> * Fix file exclusion in tarball generation. > > Hi Jens, > > This isn't really a great version, but ok it will land later today. > It would be far better to update to upstream git, which is now in sync > with the latest opengl 4.5 spec. For the reasoning to do this intermediate version see my follow-up bug #869233. (btw, I'm quite busy atm, but luckily upstream Wine had a patch for this just today, so they will do the initial testing.) > By the way, NMUs are not supposed to touch maintainer fields like the > standards version, but it's not a big deal. I'm not sure about your intention here. My goal is keeping the build-dependencies of Wine (especially unicode-data and khronos-api) in fine shape. Since I know that you don't have much time I offered to add me as co-maintainer, and started to work on the package in kind of an extension of pkg-wine. The spirit of this upload was to fix uncritical things, while I opened #869233 before doing eventually controversial things. Not checking and bumping the standards version would have felt wrong to me. Maintainer fields aren't mentioned explicitly in policy 5.11, while large parts of Debian take a very liberal stance at NMUs nowadays. So I'm really not sure about your intention here, and how/if to progress with khronos-api: should I only work on khronos-api if there's a rc bug and no sign of activity from your side? Or how far can I go in helping you here and do you want a specific workflow, e.g. bugs for every change or a git repo? So I'll postpone this until further notice from you. I'd really appreciate an answer to #869233. Greets jre
Bug#827770: wine-development: FTBFS in Ubuntu
On 07/26/2017 11:05 AM, Gianfranco Costamagna wrote: > control: reopen -1 > control: tags -1 patch > >> No, they get to deal with the problems they create for themselves. > > while this is true in general, in this particular case this is a problem in > Debian too, when different versions of > the same libraries might coexist in Debian too. > > Fortunately the new approach patch seems sane and applicable directly in > Debian too > > diff -Nru wine-development-2.13/debian/scripts/sonames2elf > wine-development-2.13/debian/scripts/sonames2elf > --- wine-development-2.13/debian/scripts/sonames2elf2017-07-22 > 17:17:47.0 +0200 > +++ wine-development-2.13/debian/scripts/sonames2elf2017-07-23 > 00:25:08.0 +0200 > @@ -34,7 +34,10 @@ > fi > tmpdir=$(mktemp -d -t sonames2elf.XX) > cd "$tmpdir" > -printf 'INPUT(%s)\n' "$@" > libeverything.so > +# Use the unversioned solink because the soname might be not found. > +# solink always points to the default soname, which is what wine uses. > +SOLINKS="$(echo $@ | sed "s|\([[:alnum:]]*\.so\)[\.[0-9]*]*|\1|g")" > +printf 'INPUT(%s)\n' "$SOLINKS" > libeverything.so > gcc -shared -Wl,--no-as-needed -L. -leverything -o elf > cat elf > rm -rf "$tmpdir" > > what do you think about? Having written that patch, I totally agree and suggest to add it.
Bug#869233: khronos-api: Update to new version from new git repo
Package: khronos-api Version: 0~svn29735-1.1 Severity: wishlist While working on #865307 and #865308 I saw that the Khronos Group moved, see https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/README.txt: ~ As of 2017-01-21, the OpenGL Registry has been MOVED to https://www.khronos.org/registry/OpenGL/ The new registry location is backed by a github repository at https://github.com/KhronosGroup/OpenGL-Registry There will be no further updates to the public Subversion area. We are in the process of setting up redirects so that deep links under opengl.org/registry will continue to work, and the old website will remain active until those redirects are established; but everyone should begin using the new registry on khronos.org as soon as possible. Please file issues with the new registry on the github repository. ~ For now I uploaded 0~svn33340-0.1, so that we have the latest version from the old repo for comparison with the new ones. (There have been a few more svn revisions, but they don't touch the api/ directory.) Next I'll be working on updating upstream Wine to the current version and the new location. Then I'd like to update khronos-api here, however there are a few things to consider: 1.) Version --- Currently there are no upstream releases or tags available, so we have to continue to make our own number. Unfortunately 0~gitVERSION < 0~svnVERSION, so I suggest 0+gitVERSION. For the specific VERSION: A commonly used scheme (especially for golang packages) is 0~git- e.g.: $ git log -1 --pretty=format:0.0~git%cd.%h --date=format:%Y%m%d%H%M 0.0~git201707111832.9755811 This works without any additional tags. Also the maintainer of the github repo may merge other branches, even if they have older committer dates, without breaking it. AFAICS also cherry-picking an old commit, or rebasing another branch, should work. Alternatively we might tag the inital commit in the repo "0", and then use git describe: $ git tag 0 2f2b0f91f0a7ed3b468e03593dde66176e9b3032 $ git describe --tags 0-126-g9755811 $ VERSION="$(git describe --tags | sed "s|-|+git|")-1" $ echo $VERSION 0+git126-g9755811-1 Any preferences or suggestions? 2.) EGL API and Extension Registry EGL is part of the current khronos-api package, but Khronos moved it now to a separate repository. (I might have gotten this wrong, or missed further changes. Can't say for sure yet.) This shouldn't be a problem for Wine, because it only uses gl.xml and wgl.xml. But there's one other package (qtwebengine-opensource-src) which build-depends on khronos-api. I've rebuilt that successfully with 0~svn33340-0.1, but I don't know yet if it requires egl. So we have to keep that in mind, but generally I'd just suggest to drop egl from the khronos-api package (no multi source tarball package). Greets jre
Bug#782075: gnome-tweak-tool: Crashes Gnome when reducing Number of Workspaces
control: forwarded -1 https://bugzilla.gnome.org/show_bug.cgi?id=784223 control: found -1 3.22.4-2 On 07/20/2017 07:27 AM, intrigeri wrote: > The Mutter 3.24.4 announcement says that > https://bugzilla.gnome.org/show_bug.cgi?id=784223 has been fixed. > I suspect this is the same bug as this one. Thanks, intrigeri! That indeed looks identical. > So anyone affected: please try to reproduce once Mutter 3.24.4 is in > Debian :) Thanks in advance! I'll do so. I also verified that the current version is still affected here. This bug is still marked as unreproducible. Did you (or anyone else) try to reproduce with my previously described steps (see below)? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782075#84 > In a freshly installed Stretch system (my main machine) this happens > only if you've set in the Gnome Tweak Tool: > > Desktop - Icons on Desktop - On > > After this as previously described: > Workspaces - Workspace Creation - Static > Workspaces - Number of Workspaces - Reduce by one > --> the Desktop wallpaper gets black for a short time, then > everything is back to normal. > Workspaces - Number of Workspaces - Reduce by one > --> Gnome session crashes Greets! jre
Bug#868175: [pkg-wine-party] Bug#868175: wine: FTBFS: unknown matra Bottom_And_Left at ./tools/make_unicode
control: tags -1 patch Hi On 07/12/2017 09:03 PM, Niko Tyni wrote: > Package: wine > Version: 1.8.7-2 > > This package fails to build on current sid. > > From the timing I'm guessing it regressed with unicode-data_10.0.0-1. > ./tools/make_unicode > unknown matra Bottom_And_Left at ./tools/make_unicode line 1226, > line 684. Yes, indeed. We already fixed that in wine-development 2.11-2 (the changes in debian/patches/generate/unicode.patch), but I forgot about src:wine in the archive. Upstream is currently preparing wine 2.0.2 (eta ~ 1 week). I'll add the fix with that release (or whoever does it should do so). Greets and thanks! jre
Bug#865308: khronos-api is not Multi-Arch compatible
Hi Mike On 07/03/2017 06:34 AM, Hugh McMaster wrote: > This bug is still present. Has any progress been made on resolving this issue? >From all I know this is the correct fix. See also https://wiki.debian.org/MultiArch/Hints#ma-foreign Mike, I'd like to NMU with - the patch from this bug - the patch from #865307 (but wrapped at 72 chars and keeping the double space after ".") - probably a new upstream version (assuming it is trivial and works with Wine, otherwise I'd postpone that) Is that ok? Instead I might also upload to deferred/10 or mentors first. And/or I might add myself as uploader. Greets!! jre
Bug#867106: wine-development: build-depends unicode-data (< 10.0) but 10.0.0-1 is to be installed
I'm just catching up, and am not working on Wine yet. So just fyi recently there was a patchset at WineHQ for Unicode 10: https://www.winehq.org/pipermail/wine-patches/2017-July/163321.html https://www.winehq.org/pipermail/wine-patches/2017-July/163322.html That one got rejected, but I assume it at least made Wine build again. Alternatively, I wonder if it is acceptable to temporarily embed the Unicode 9 files in our source packages. (I'm quite sure that WineHQ will update to 10 soon, definitely in time for buster.)
Bug#865580: gdebi: incorrectly claims wine32:i386 no longer provides wine32
Package: gdebi Version: 0.9.5.7+nmu1 Severity: normal User: multiarch-de...@lists.alioth.debian.org Usertags: multiarch Hi! With wine32:i386 installed on an amd64 system, gdebi incorrectly says "Status: Error: no longer provides wine32". However it displays the "Included files" correctly (fun fact: in synaptic the issue is just the other way). Original report: https://bugs.launchpad.net/ubuntu/+source/synaptic/+bug/1682874 Background: wine32 is a multi-arch foreign package, available only on 32-bit architectures. But it is required also on 64-bit architectures to run 32-bit Windows executables, so it is an essential part of nearly every Wine installation. This seems to be an issue only for M-A: foreign if the package is not available on the native arch. Not found for e.g. dosbox:i386 which is Multi-Arch: foreign, or libwine:i386, which is M-A: same and exists on 32- and 64-bit archs. $ dpkg -s wine32 Package: wine32 Status: install ok installed [...] Architecture: i386 Multi-Arch: foreign Source: wine Version: 2.0.1-1 $ dpkg -L wine32 /. /usr /usr/lib /usr/lib/wine /usr/lib/wine/wine /usr/lib/wine/wineserver32 /usr/share /usr/share/bug /usr/share/bug/wine32 /usr/share/bug/wine32/control /usr/share/bug/wine32/script /usr/share/doc /usr/share/doc/wine32 /usr/share/doc/wine32/NEWS.Debian.gz /usr/share/doc/wine32/changelog.Debian.gz /usr/share/doc/wine32/changelog.gz /usr/share/doc/wine32/copyright /usr/share/lintian /usr/share/lintian/overrides /usr/share/lintian/overrides/wine32 Greets jre -- System Information: Debian Release: 9.0 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'stable-debug'), (500, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gdebi depends on: ii gdebi-core0.9.5.7+nmu1 ii gir1.2-gtk-3.03.22.11-1 ii gir1.2-vte-2.91 0.46.1-1 ii gksu 2.0.2-9+b1 ii gnome-icon-theme 3.12.0-2 ii python3 3.5.3-1 ii python3-gi3.22.0-2 Versions of packages gdebi recommends: ii libgtk2-perl 2:1.2499-1 ii lintian 2.5.50.4 ii shared-mime-info 1.8-1 gdebi suggests no packages.
Bug#865578: synaptic: fails to display installed files of foreign arch packages
Package: synaptic Version: 0.84.2 Severity: normal User: multiarch-de...@lists.alioth.debian.org Usertags: multiarch Hi! With wine32:i386 installed on an amd64 system, synaptics still claims in the "wine32:i386 Properties - Installed Files" tab: "The list of installed files is only available for installed packages" However in the "Common" tab it correctly says "Status: installed" (fun fact: in gdebi the issue is just the other way). Original report: https://bugs.launchpad.net/ubuntu/+source/synaptic/+bug/1682874 Background: wine32 is a multi-arch foreign package, available only on 32-bit architectures. But it is required also on 64-bit architectures to run 32-bit Windows executables, so it is an essential part of nearly every Wine installation. I checked with dosbox (also M-A: foreign, but available on 32- and 64-bit). With dosbox:i386 installed the "Installed Files" also gives the wrong message. However at the same time dosbox:amd64 shows the installed files (which are from the i386 packages). $ dpkg -s wine32 Package: wine32 Status: install ok installed [...] Architecture: i386 Multi-Arch: foreign Source: wine Version: 2.0.1-1 $ dpkg -L wine32 /. /usr /usr/lib /usr/lib/wine /usr/lib/wine/wine /usr/lib/wine/wineserver32 /usr/share /usr/share/bug /usr/share/bug/wine32 /usr/share/bug/wine32/control /usr/share/bug/wine32/script /usr/share/doc /usr/share/doc/wine32 /usr/share/doc/wine32/NEWS.Debian.gz /usr/share/doc/wine32/changelog.Debian.gz /usr/share/doc/wine32/changelog.gz /usr/share/doc/wine32/copyright /usr/share/lintian /usr/share/lintian/overrides /usr/share/lintian/overrides/wine32 Greets jre -- System Information: Debian Release: 9.0 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'stable-debug'), (500, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages synaptic depends on: ii hicolor-icon-theme 0.15-1 ii libapt-inst2.0 1.4.6 ii libapt-pkg5.01.4.6 ii libatk1.0-0 2.22.0-1 ii libc62.24-11+deb9u1 ii libcairo-gobject21.14.8-1 ii libcairo21.14.8-1 ii libept1.5.0 1.1+nmu3+b1 ii libgcc1 1:6.3.0-18 ii libgdk-pixbuf2.0-0 2.36.5-2 ii libglib2.0-0 2.50.3-2 ii libgnutls30 3.5.13-1 ii libgtk-3-0 3.22.11-1 ii libpango-1.0-0 1.40.5-1 ii libpangocairo-1.0-0 1.40.5-1 ii libpcre2-8-0 10.22-3 ii libstdc++6 6.3.0-18 ii libvte-2.91-00.46.1-1 ii libx11-6 2:1.6.4-3 ii libxapian30 1.4.3-2 ii policykit-1 0.113-6 ii zlib1g 1:1.2.8.dfsg-5 Versions of packages synaptic recommends: ii libgtk2-perl 2:1.2499-1 ii rarian-compat 0.8.1-6+b1 ii xdg-utils 1.1.1-1 Versions of packages synaptic suggests: pn apt-xapian-index pn deborphan pn dwww ii menu 2.1.47+b1 ii software-properties-gtk 0.96.20.2-1 ii tasksel 3.39 -- no debconf information
Bug#865387: [pkg-wine-party] Bug#865387: wine32: can't install wine32 in a 64 bits system
On 20.06.2017 23:51, Aniol Martí wrote: > I'm not able to install "wine32" in Debian Sid (64 bits). > > First I have added an extra arch: > # dpkg --add-architecture i386 > # apt update > > Then, I have tried to install wine32: > # apt install wine32 > > But I get the following error: > The following packages have unmet dependencies: > wine32:i386 : Depends: libwine:i386 (= 1.8.7-2) but it is not going to > be installed > E: Unable to correct problems, you have held broken packages. > > Is there something I'm missing? Go down the dependency chain and post its output # apt install libwine:i386 # ...
Bug#858371: unblock: wine/1.8.7-2
Control: tags -1 - moreinfo On 04/01/2017 03:03 PM, Niels Thykier wrote: > Please go ahead and remove the moreinfo tag once it has been built on > all relevant release architectures. I uploaded wine/1.8.7-2 to unstable yesterday. It is now built on all relevant architectures. Thanks again! jre
Bug#858371: unblock: wine/1.8.7-2
Hi again On 03/21/2017 05:40 PM, Jens Reyer wrote: > Please unblock package wine/1.8.7-2 (pre-approval, 1.8.7-1 is in > experimental). > > I ask to make an exception of the freeze policy for upstream's last > and final update for their old stable release series 1.8. I know > the change is huge, but I think it's worth it and risk-free: Should I go ahead and upload -2 to unstable (as usually advised)? I want to make it easy for you, but at the same time don't want to upload to unstable if the unblock is unlikely to happen. (And I'd like to continue with buster/ubuntu work in experimental.) So it would help a lot to know if you tend to ack or nack this (but I'm not asking for your final decision now). debdiff stat: 71 files changed, 2120 insertions(+), 806 deletions(-) Thanks a lot for your work, and sorry for starting to nag about this (I barely dare to send this mail). Also sorry for the previous non-wrapped mail. Greets jre (jere21 on irc)
Bug#858242: libwine: winemenubuilder creates .desktop files with invalid WINEPREFIX
Hi! On 03/20/2017 11:20 AM, Sven Joachim wrote: > wine: invalid directory "/home/sven/.wine" in WINEPREFIX: not an absolute path > > Apparently the program was trying to run winebrowser from one of my > .desktop files under ~/.local/share/applications/, those look like this: This was already mentioned in #845334 (wine32: breaks xdg-open, which wants to start wine and crashes). As a result of that report the .desktop files aren't generated anymore for some standard mimetypes, e.g. pdf. So the mentioned file should be a relic from older times (please verify its timestamp). Unfortunately we can't simply remove these existing files, because we can't know if they are still wanted by the user. I never saw this behavior here, but since it's now observed again I'd really like to fix it (assuming it might also be triggered by the .desktop files created by some Windows applications). > Note that WINEPREFIX is in quotation marks here, due to the > Debian-specific patch debian/patches/debsuffix/winemenubuilder.patch, > and wine does not like this: it expects the first character to be a > slash and not a quotation mark, see libs/wine/config.c. Unfortunately I can't follow your analysis: we don't add any quotation marks in that line, they are already there from upstream. Instead we just replace wine with wine-stable or wine-development there. Greets jre
Bug#854818: firefox-esr: creates mimeapps.list entries for thunderbird.desktop if started from TB
On 03/16/2017 03:06 PM, Jens Reyer wrote: > [ CC'ing the thunderbird-bug #857755 (Please do not associate > application/octet-stream with thunderbird), which targets the same > issue. Unfortunately I can reproduce this issue in firefox with both > the unfixed thunderbird 1:45.8.0-1 and the "fixed" 1:45.8.0-2 again. ] I forgot to CC the thunderbird-bug #857755, and upon rereading that bug it's about another issue anyway. Sorry for the noise. The issue described in this firefox-bug here however still exists: mime types that should be associated with firefox get associated with thunderbird instead. Greets jre
Bug#854818: firefox-esr: creates mimeapps.list entries for thunderbird.desktop if started from TB
control: found 854818 45.8.0esr-1 control: severity 854818 important [ CC'ing the thunderbird-bug #857755 (Please do not associate application/octet-stream with thunderbird), which targets the same issue. Unfortunately I can reproduce this issue in firefox with both the unfixed thunderbird 1:45.8.0-1 and the "fixed" 1:45.8.0-2 again. ] On 03/09/2017 04:06 PM, Jens Reyer wrote: > However luckily it seems thunderbird 1:45.7.1-2 fixes this - firefox now > correctly recognizes that it is already the default app. > > Therefore closing (although I still don't know what exactly went wrong). Reopening, I see the behavior reproducibly again (not sure why it diappeared for a short while): $ rm -rf .local/share/applications/* $ rm .config/mimeapps.list - Start thunderbird (via launcher or from terminal) - Click a https link in thunderbird --> Firefox starts and prompts: "Default Browser - Firefox is not currently set as your default browser. Would you like to make it your default browser?" --> Click "Use Firefox as my default browser" $ cat ~/.config/mimeapps.list [Default Applications] x-scheme-handler/http=thunderbird.desktop x-scheme-handler/https=thunderbird.desktop x-scheme-handler/ftp=thunderbird.desktop x-scheme-handler/chrome=thunderbird.desktop text/html=thunderbird.desktop application/x-extension-htm=thunderbird.desktop application/x-extension-html=thunderbird.desktop application/x-extension-shtml=thunderbird.desktop application/xhtml+xml=thunderbird.desktop application/x-extension-xhtml=thunderbird.desktop application/x-extension-xht=thunderbird.desktop [Added Associations] x-scheme-handler/http=thunderbird.desktop; x-scheme-handler/https=thunderbird.desktop; x-scheme-handler/ftp=thunderbird.desktop; x-scheme-handler/chrome=thunderbird.desktop; text/html=thunderbird.desktop; application/x-extension-htm=thunderbird.desktop; application/x-extension-html=thunderbird.desktop; application/x-extension-shtml=thunderbird.desktop; application/xhtml+xml=thunderbird.desktop; application/x-extension-xhtml=thunderbird.desktop; application/x-extension-xht=thunderbird.desktop; ==> Now it's not possible anymore to open https-links from thunderbird. The following is not clearly reproducible, but quite annoying: If I now remove ~/.config/mimeapps.list again, a link previously clicked in thunderbird opens in firefox, and firefox asks about being default again. If I say "Not now" it will endlessly spawn new tabs with the same link. I think only killing thunderbird stops this then. Unfortunately I'm still totally clueless about the exact reason for this, and all attempts to fix this by exporting several variables from the firefox script didn't help. I don't know if this needs to be fixed in thunderbird or firefox. Greets jre
Bug#855501: Patch to change migration to linking and other related things
Hi Carsten (and/or Chris),
attached is a new patch with 2 fixes and some (more or less pedantic)
nitpicking. It's based on b5fd889 in Carsten's github repo (I didn't
review every change, but it looks very good!).
You can see the single changes in the branch jre/migration20170301 at
https://github.com/jre-wine/icedove.
It contains:
* Grammar/Typo fixes
I'd suggest asking debian-l10n-english@l.d.o for
proof-reading of the scripts and the README.
* Let find follow symlinks when searching the profile folder.
* Merge 2 sed commands.
* Avoid using -a / -o in tests as this is not well defined.
Logically group tests with braces + semicolon instead.
Note: Parantheses would achieve the same, but in a subshell.
See:
http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html
2.9.4 Compound Commands
https://github.com/koalaman/shellcheck/wiki/SC2166
* Avoid using full pathnames when using system functions.
cat, echo, ln and readlink are in /bin/, not in /usr/bin/.
Previously this made thunderbird fail to start here (.thunderbird
is a link to .icedove) with:
/usr/bin/thunderbird: 151: /usr/bin/thunderbird: /usr/bin/readlink: not
found
/usr/bin/thunderbird: 189: /usr/bin/thunderbird: /usr/bin/readlink: not
found
<12>Feb 28 17:38:33 jens[26504]: /usr/bin/thunderbird: [profile
migration] Couldn't migrate Icedove into Thunderbird profile due
existing or symlinked folder '/home/jens/.thunderbird'!
/usr/bin/thunderbird: 195: /usr/bin/thunderbird: /usr/bin/readlink: not
found
<12>Feb 28 17:38:33 jens[26506]: /usr/bin/thunderbird: [profile
migration] /home/jens/.icedove is probably a symlink pointing to a non
existing target, at least not to /home/jens/.icedove.
/usr/bin/thunderbird: 195: /usr/bin/thunderbird: /usr/bin/readlink: not
found
<12>Feb 28 17:38:33 jens[26508]: /usr/bin/thunderbird: [profile
migration] /home/jens/.thunderbird is probably a symlink pointing to a
non existing target, at least not to /home/jens/.icedove.
Gtk-Message: GtkDialog mapped without a transient parent. This is
discouraged.
/usr/bin/thunderbird: 321: /usr/bin/thunderbird: /usr/bin/echo: not found
/usr/bin/thunderbird: 321: /usr/bin/thunderbird: /usr/bin/echo: not found
Greets
jre
diff --git a/debian/thunderbird-wrapper-helper.sh b/debian/thunderbird-wrapper-helper.sh
index acc2c8e8c7..bab6e7600e 100644
--- a/debian/thunderbird-wrapper-helper.sh
+++ b/debian/thunderbird-wrapper-helper.sh
@@ -44,8 +44,8 @@ An existing profile folder (or symlink) '.thunderbird' was found in
your Home directory '${HOME}/' while trying to migrate the Icedove
profile(s) folder!
-This can probably be a old, currently not used profile folder or
-you maybe using a Thunderbird installation from the Mozilla packages.
+This could be an old, currently not used profile folder or you might
+be using a Thunderbird installation from the Mozilla packages.
If you don't need this old profile folder, you can remove or backup
it and start Thunderbird again.
@@ -106,21 +106,21 @@ TITLE="Icedove to Thunderbird Profile adoption"
# Simple search all files where we made a backup from
do_collect_backup_files () {
output_debug "Collect all files we've made a backup."
-BACKUP_FILES=$(/usr/bin/find "${TB_PROFILE_FOLDER}/" -type f -name "*backup_thunderbird_migration*")
+BACKUP_FILES=$(find -L "${TB_PROFILE_FOLDER}/" -type f -name "*backup_thunderbird_migration*")
if [ "${BACKUP_FILES}" != "" ]; then
-output_info "The following backups related Icedove to Thunderbird transition are existing:"
-/usr/bin/cat << EOF
+output_info "The following backups related to the Icedove to Thunderbird transition are existing:"
+cat << EOF
${BACKUP_FILES}
EOF
else
-output_info "No backups related Icedove to Thunderbird transition found."
+output_info "No backups related to the Icedove to Thunderbird transition found."
fi
}
# Create the file .thunderbird/.migrated with some content
do_create_migrated_mark_file (){
-/bin/cat < "${TB_PROFILE_FOLDER}/.migrated"
-This is a automatically created file by /usr/bin/thunderbird, it will be
+cat < "${TB_PROFILE_FOLDER}/.migrated"
+This is an automatically created file by /usr/bin/thunderbird, it will be
recreated by every start of Thunderbird. Remove that files only if you know
the propose of this file.
@@ -131,15 +131,14 @@ EOF
# Fix the file $PROFILE/mimeTypes.rdf
do_fix_mimetypes_rdf (){
-for MIME_TYPES_RDF_FILE in $(/usr/bin/find "${TB_PROFILE_FOLDER}/" -name mimeTypes.rdf); do
+for MIME_TYPES_RDF_FILE in $(find -L "${TB_PROFILE_FOLDER}/" -name mimeTypes.rdf); do
RDF_SEARCH_PATTERN=$(grep '/usr/bin/iceweasel\|icedove' "${MIME_TYPES_RDF_FILE}")
if [ "${RDF_SEARCH_PATTERN}" != "" ]; then
output_debug "Backup ${MIME_TYPES_RDF_FILE} to ${MIME_TYPES_RDF_FILE}.backup_thunderbird_migration-${DATE}"
cp "${MIME_TYPES_RDF_FILE}" "${MIME_TYPES_RDF_FILE}.backup_thunderbird_migration-${DATE}"
output_debug "Fixing possible broken
Bug#856492: thunderbird: duplicate install of thunderbird binary
Package: thunderbird Version: 1:45.7.1-1 Severity: normal Hi the thunderbird binary is installed twice: $ dpkg -S /usr/lib/thunderbird/thunderbird* thunderbird: /usr/lib/thunderbird/thunderbird thunderbird: /usr/lib/thunderbird/thunderbird-bin $ sha256sum /usr/lib/thunderbird/thunderbird* 0750c82a151419f7c284115afdda55054464a694b23ddf2767ba1ed6f70eb427 /usr/lib/thunderbird/thunderbird 0750c82a151419f7c284115afdda55054464a694b23ddf2767ba1ed6f70eb427 /usr/lib/thunderbird/thunderbird-bin In debian/thunderbird.install I see this line: debian/tmp/usr/lib/thunderbird/thunderbird* Greets jre -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages thunderbird depends on: ii debianutils 4.8.1 ii fontconfig2.11.0-6.7+b1 ii libasound21.1.3-5 ii libatk1.0-0 2.22.0-1 ii libc6 2.24-9 ii libcairo2 1.14.8-1 ii libdbus-1-3 1.11.10-1 ii libdbus-glib-1-2 0.108-2 ii libevent-2.0-52.0.21-stable-3 ii libffi6 3.3~20160224-1 ii libfontconfig12.11.0-6.7+b1 ii libfreetype6 2.6.3-3+b2 ii libgcc1 1:6.3.0-6 ii libgdk-pixbuf2.0-02.36.5-2 ii libglib2.0-0 2.51.2-1 ii libgtk2.0-0 2.24.31-2 ii libhunspell-1.4-0 1.4.1-2+b2 ii libicu57 57.1-5 ii libnspr4 2:4.12-6 ii libnss3 2:3.26.2-1 ii libpango-1.0-01.40.3-3 ii libpangocairo-1.0-0 1.40.3-3 ii libpangoft2-1.0-0 1.40.3-3 ii libpixman-1-0 0.34.0-1 ii libsqlite3-0 3.16.2-2 ii libstartup-notification0 0.12-4 ii libstdc++66.3.0-6 ii libvpx4 1.6.1-2 ii libx11-6 2:1.6.4-3 ii libxcomposite11:0.4.4-2 ii libxdamage1 1:1.1.4-2+b1 ii libxext6 2:1.3.3-1 ii libxfixes31:5.0.3-1 ii libxrender1 1:0.9.10-1 ii libxt61:1.1.5-1 ii psmisc22.21-2.1+b1 ii zlib1g1:1.2.8.dfsg-5 Versions of packages thunderbird recommends: ii hunspell-de-de-frami [hunspell-dictionary] 1:5.2.5-1 ii hunspell-en-us [hunspell-dictionary]20070829-7 ii lightning 1:45.7.1-1 Versions of packages thunderbird suggests: pn apparmor pn fonts-lyx ii libgssapi-krb5-2 1.15-1 -- no debconf information
Bug#855501: Patch to change migration to linking and other related things
control: tags -1 + patch
control: tags 855265 + patch
control: tags 855391 + patch
control: tags 855286 + patch
Hi,
this patch is for several things from the thread at debian-devel and
some related bugs. Not sure if you've already been working on this, but
I hope this patch helps. Just tell me if you want something done
differently, or if I should split this patch into a patch series.
I did some basic testing, but will do some more. I just feel it's
better to share the current state with you now.
At its core this patch changes copying the profiles to just linking them.
Since this wildly moves around code in the script I tried to put some
more things in separate functions (displaying messages and mimeTypes.rdf
migration) to keep the script clear. Unfortunately this further bloats
this patch.
I added several checks to test if something needs to be migrated before
the actual migration command, and also moved some debug messages inside
conditional code.
#855265 (thunderbird: migration script should not error out on trivial
migrations)
--> I check for existing links between .thunderbird and .icedove
#855391 (icedove -> thunderbird transition: Original profile removed
when using symlinks)
--> not relevant anymore since the profiles are now linked (assuming we
only need backups for things explicitly changed in this script)
#855501 (thunderbird: copy account during transition from icedove to
thunderbird not a good idea)
--> now we link
#855286 (migration script should use zenity on MATE)
--> this touches the same code as above changes, so I added it to this
patch. I also dropped the obsolete upper-case handling, see thread in
debian-devel iirc.
Greets
jre
diff --git a/debian/thunderbird-wrapper.sh b/debian/thunderbird-wrapper.sh
index 61c4cc0e79..681bf94cda 100755
--- a/debian/thunderbird-wrapper.sh
+++ b/debian/thunderbird-wrapper.sh
@@ -57,10 +57,7 @@ with underlaying profile(s) from Icedove.
The Icedove package is now de-branded back to Thunderbird.
The Icedove profile(s) will now be migrated to the Thunderbird folder
-structure. This will take some time!
-
-Please be patient, the Thunderbird program will be started right after
-the migration.
+structure. Thunderbird will be started right after the migration.
If you need more information about the de-branding of the Icedove package
please take a look into
@@ -87,6 +84,50 @@ if [ "${VERBOSE}" = "1" ]; then
fi
}
+migration_message() {
+if [ -x "$(which xmessage)" ]; then
+migration_message_cmd="xmessage -center"
+else
+migration_message_cmd="echo"
+fi
+case "${DESKTOP}" in
+gnome|xfce|mate)
+if [ -x "$(which zenity)" ]; then
+migration_message_cmd="zenity --info --no-wrap --title ${TITLE} --text"
+fi
+;;
+
+kde)
+if [ -x "$(which kdialog)" ]; then
+migration_message_cmd="kdialog --title ${TITLE} --msgbox"
+fi
+;;
+esac
+$migration_message_cmd "$@"
+}
+
+migrate_MIME_TYPES_RDF_FILE() {
+# only move on if we not have already a problem
+if [ "${FAIL}" != 1 ]; then
+# Fixing mimeTypes.rdf which may have registered the iceweasel binary
+# as browser, instead of x-www-browser
+for MIME_TYPES_RDF_FILE in $(find ${TB_PROFILE_FOLDER}/ -name mimeTypes.rdf); do
+if grep -q /usr/bin/iceweasel ${MIME_TYPES_RDF_FILE}; then
+debug "Fixing broken 'mimeTypes.rdf'."
+# Note: changed to create backup copy, and check the result.
+sed -i.copy_by_thunderbird_starter "s|/usr/bin/iceweasel|/usr/bin/x-www-browser|g" "${MIME_TYPES_RDF_FILE}"
+if [ $? -ne 0 ]; then
+echo "${MIME_TYPES_RDF_FILE} couldn't be fixed."
+echo "Please check for potential problems like low disk space or wrong access rights!"
+logger -i -p warning -s "$0: [profile migration] Couldn't fix '${MIME_TYPES_RDF_FILE}'!"
+exit 1
+fi
+debug "${MIME_TYPES_RDF_FILE} has been fixed."
+fi
+done
+fi
+}
+
migrate_old_icedove_desktop() {
# Fixing mimeapps.list files in ~/.config/ and ~/.local ... which may have
# icedove.desktop associations, the latter location is deprecated, but still
@@ -115,9 +156,9 @@ for MIMEAPPS_LIST in ${HOME}/.config/mimeapps.list ${HOME}/.local/share/applicat
logger -i -p warning -s "$0: [profile migration] Couldn't fix '${MIMEAPPS_LIST}'!"
exit 1
fi
+debug "A copy of the configuration file of default applications for some MIME types"
+debug "was saved into '${MIMEAPPS_LIST_COPY}'."
fi
-debug "A copy of the configuration file of default applications for some MIME types"
-debug "was saved into '${MIMEAPPS_LIST_COPY}'."
done
# Migrate old user specific desktop entries
@@ -257,7 +298,7 @@ fi
# trying to
Bug#849592: bug report - icedove: href links inoperative
On 02/14/2017 09:55 PM, Rick Lutowski wrote:
> On 02/14/2017 07:06 AM, Jens Reyer wrote:
>> since you seem to use your system for some years now without cleaning
>> config files in /home: can you please execute the following commands to
>> look for more iceweasel files (first command), or files referencing
>> iceweasel (second command, this might take a while):
>>
>> $ find .config/ .local/ -iname iceweasel
>> $ find .config/ .local/ -type f -exec grep -il iceweasel '{}' ';'
>>
>> On my system the output is empty (except a tracker file).
>
> The first command finds nothing. The second finds several files:
D'oh, the first should've been:
$ find .config/ .local/ -iname "*iceweasel*"
The second looks good on the first glance (nothing left to fix).
Thanks!
Bug#849592: bug report - icedove: href links inoperative
Hi Rick,
since you seem to use your system for some years now without cleaning
config files in /home: can you please execute the following commands to
look for more iceweasel files (first command), or files referencing
iceweasel (second command, this might take a while):
$ find .config/ .local/ -iname iceweasel
$ find .config/ .local/ -type f -exec grep -il iceweasel '{}' ';'
On my system the output is empty (except a tracker file).
Greets
jre
Bug#828069: icedove: random crashes after latest security update
On 02/13/2017 10:59 AM, Paul van der Vlis wrote: > Is the old 1:45.1 version from before the security patch somewhere > available? And the patch? http://snapshot.debian.org/package/icedove/ You can also use debsnap from the devscripts package, for example: $ debsnap -v -d . icedove 1:45.1.0-1~deb7u1 debsnap fetches source packages by default, which you will then need to build (see debuild). You can compare packages with "debdiff", or check the git repository: git clone https://anonscm.debian.org/cgit/pkg-mozilla/icedove.git Greets jre
Bug#854815: Patch for bug #854815 (firefox: transition old userapp .desktop file)
control: reassign -1 src:firefox-esr 45.7.0esr-4
control: severity -1 important
control: tags -1 + patch
Reassigning to the version I actually use. Raising severity, but that's
the maintainer's decision. This should be fixed for all released
firefox packages.
Attached is a patch that removes (backups) iceweasel desktop files in
$HOME, and references the system wide firefox[-esr].desktop file in
mimeapps.list. If iceweasel was previously set as the default
application, it will be changed to either firefox or firefox-esr now,
depending on which package is installed and does the migration. That
sounds good to me, but I'm not really familiar with the 2 flavors of
firefox in debian.
This patch does not exactly what I previously suggested, please find the
rationale in the patch comments.
Please note that I only tested a static version of this patch, but not
the @browser@ substitution in firefox.in.
If you find any errors/issues with this patch, please tell me, since a
similar version will also be used for thunderbird.
Greets
jre
diff --git a/debian/firefox.in b/debian/firefox.in
index 66aaa5870cd..03d4a362afc 100644
--- a/debian/firefox.in
+++ b/debian/firefox.in
@@ -1,5 +1,48 @@
#!/bin/sh
+# Fix old mimeapps.list files referencing iceweasel.
+# The latter location (in ~/.local) is deprecated, but still commonly used.
+# Note: mimeapps.list files configure default applications for MIME types.
+for MIMEAPPS_LIST in ${HOME}/.config/mimeapps.list ${HOME}/.local/share/applications/mimeapps.list; do
+# Check if file exists and has an old iceweasel entry
+if [ -e "${MIMEAPPS_LIST}" ] && \
+ grep -iq "\(userapp-\)*iceweasel\(-.*\)*\.desktop" "${MIMEAPPS_LIST}"; then
+echo "Fixing broken '${MIMEAPPS_LIST}'."
+MIMEAPPS_LIST_COPY="${MIMEAPPS_LIST}.copy_by_firefox_starter"
+# Fix mimeapps.list and create backup suffixed ".copy_by_firefox_starter"
+# (requires GNU sed 3.02 or ssed to make the search case-insensitive
+# with the option "I").
+sed -i.copy_by_firefox_starter "s|\(userapp-\)*iceweasel\(-.*\)*\.desktop|@browser@.desktop|gI" "${MIMEAPPS_LIST}"
+if [ "$(echo $?)" != 0 ]; then
+echo "The configuration file for default applications for some MIME types"
+echo "'${MIMEAPPS_LIST}' couldn't be fixed."
+echo "Please check for potential problems like low disk space or wrong access rights!"
+logger -i -p warning -s "$0: [desktop migration] Couldn't fix '${MIMEAPPS_LIST}'!"
+exit 1
+fi
+fi
+echo "A copy of the configuration file for default applications for some MIME types"
+echo "was saved into '${MIMEAPPS_LIST_COPY}'."
+done
+
+# Remove old iceweasel desktop files in $(HOME)/.local/share/applications/.
+# They are superseded by /usr/share/applications/firefox[-esr].desktop. The old
+# ones in $(HOME)/.local/share/applications/ don't receive updates and might
+# have missing/outdated fields.
+# They are named 'userapp-Iceweasel-RYY0FY.desktop' (or similar) or
+# 'iceweasel.desktop'. Usually there should be only one of them at most.
+# Note: .desktop files and their reverse cache mimeinfo.cache provide
+# information about available applications.
+for ICEWEASEL_DESKTOP in $(find ${HOME}/.local/share/applications/ -iname "*iceweasel*.desktop"); do
+ICEWEASEL_DESKTOP_COPY=${ICEWEASEL_DESKTOP}.copy_by_firefox_starter
+mv ${ICEWEASEL_DESKTOP} ${ICEWEASEL_DESKTOP_COPY}
+# Update the mimeinfo cache. This is not critical because non-existing
+# .desktop files are ignored by the system anyway.
+if [ -x "$(which update-desktop-database)" ]; then
+update-desktop-database ${HOME}/.local/share/applications/
+fi
+done
+
FIREFOX="$(which firefox)"
[ -x "$FIREFOX.real" ] && exec "$FIREFOX.real" "$@"
Bug#849592: icedove: transition old userapp .desktop file
control: tags -1 + patch
Hi,
I went ahead and made some changes. I didn't follow my previously
suggested plan, but went for removing the old .desktop files.
Attached are 3 patches. I successfully tested them with Rick's files
(see my previous comment).
I'll propose something similar for firefox tomorrow, to actually fix
Rick's original problem.
1_mimeapps.list.patch:
--
Also migrate .local/share/applications/mimeapps.list.
Combine this with the existing fix of .config/mimeapps.list in a for loop.
Since some people have migrated already move this fix out of the
conditional migration code, but add a new test if executing this code is
necessary.
Note: mimeapps.list specifies default applications for mime types.
2_remove_desktop_files.patch:
-
Backup and remove old icedove .desktop files.
Update mimeinfo.cache for this change.
All icedove .desktop files in $HOME are superseded by the system-wide
/usr/share/applications/thunderbird.desktop (they don't receive updates
and might have missing/outdated fields).
Note: .desktop files and their reverse cache mimeinfo.cache provide
information about available applications.
3_unrelated.patch:
--
a missing ";;", and unrelated non-critical fixes
Greets
jre
diff --git a/debian/thunderbird-wrapper.sh b/debian/thunderbird-wrapper.sh
index 91f467e541..d6a7ed4f9a 100755
--- a/debian/thunderbird-wrapper.sh
+++ b/debian/thunderbird-wrapper.sh
@@ -254,25 +254,7 @@ if [ -d "${ID_PROFILE_FOLDER}" -o -L "${ID_PROFILE_FOLDER}" ] && \
for MIME_TYPES_RDF_FILE in $(find ${TB_PROFILE_FOLDER}/ -name mimeTypes.rdf); do
sed -i "s|/usr/bin/iceweasel|/usr/bin/x-www-browser|g" "${MIME_TYPES_RDF_FILE}"
done
-
-if [ -f ${HOME}/.config/mimeapps.list ]; then
-# Fixing mimeapps.list which may have icedove.desktop associations
-debug "Fixing possible broken '~/.config/mimeapps.list'."
-# first make a copy of the file
-cp ${HOME}/.config/mimeapps.list ${HOME}/.config/mimeapps.list.copy_by_thunderbird_starter
-if [ "$(echo $?)" != 0 ]; then
-echo "The configuration file with for the associated MIME applications"
-echo "'${HOME}/.config/mimeapps.list' couldn't be saved into a backup file"
-echo "'${HOME}/.config/mimeapps.list.copy_by_thunderbird_starter'."
-echo "Please check for potentially problems like low disk space or wrong access rights!"
-logger -i -p warning -s "$0: [profile migration] Couldn't copy '${HOME}/.config/mimeapps.list' into '${HOME}/.config/mimeapps.list.copy_by_thunderbird_starter'!"
-FAIL=1
-else
-sed -i "s|icedove\.desktop|/thunderbird\.desktop|g" "${HOME}/.config/mimeapps.list"
-fi
-fi
debug "Migration done."
-debug "A copy of the previous MIME associations was saved into '${HOME}/.config/mimeapps.list.copy_by_thunderbird_starter'."
debug "The old Icedove profile folder was moved to '${HOME}/.icedove_moved_by_thunderbird_starter'"
fi
@@ -308,6 +290,39 @@ if [ "$FAIL" = 1 ]; then
exit 1
fi
+# Fixing mimeapps.list files which may have icedove.desktop associations
+# (the latter location is deprecated, but still commonly used)
+# mimeapps.list configures default applications for MIME types
+for MIMEAPPS_LIST in ${HOME}/.config/mimeapps.list ${HOME}/.local/share/applications/mimeapps.list; do
+# Check if file exists and has old icedove entry
+if [ -e ${MIMEAPPS_LIST} ] && grep -iq "\(userapp-\)*icedove\(-.*\)*\.desktop" ${MIMEAPPS_LIST}; then
+debug "Fixing broken '${MIMEAPPS_LIST}'."
+MIMEAPPS_LIST_COPY=${MIMEAPPS_LIST}.copy_by_thunderbird_starter
+if [ -e ${MIMEAPPS_LIST_COPY} ]; then
+echo "The configuration file for default applications for some MIME types"
+echo "'${MIMEAPPS_LIST}' already has a backup file"
+echo "'${MIMEAPPS_LIST_COPY}'."
+echo "Please remove the backup file or fix the configuration file manually!"
+echo "Please report a bug at https://bugs.debian.org!;
+logger -i -p warning -s "$0: [profile migration] Backup file '${MIMEAPPS_LIST_COPY}' of '${MIMEAPPS_LIST}' already exists!"
+exit 1
+else
+# Fix mimeapps.list and create backup
+# (requires GNU sed 3.02 or ssed for case-insensitive "I")
+sed -i.copy_by_thunderbird_starter "s|\(userapp-\)*icedove\(-.*\)*\.desktop|thunderbird.desktop|gI" ${MIMEAPPS_LIST}
+if [ "$(echo $?)" != 0 ]; then
+echo "The configuration file for default applications for some MIME types"
+echo "'${MIMEAPPS_LIST}' couldn't be fixed."
+echo "Please check for potential problems like low disk space or wrong access rights!"
+logger -i -p warning -s
Bug#854820: firefox-esr: creates thunderbird.desktop entries in mimeapps.list if called from thunderbird
Package: firefox-esr
Version: 45.7.0esr-3
Severity: normal
Control: found -1 45.7.0esr-1
Control: affects -1 thunderbird
Hi
in a clean system, with no previous mime entries in
~/.config/mimeapps.list and ~/.local/share/applications, and firefox
enabled to check if it is the default app:
firefox is not running. In thunderbird I click on a link. This starts
firefox and opens the link there. But now, firefox thinks it's not the
default browser. If I allow firefox to change this it creates
~/.config/mimeapps.list with *thunderbird.desktop* entries:
-
[Default Applications]
x-scheme-handler/http=thunderbird.desktop
x-scheme-handler/https=thunderbird.desktop
x-scheme-handler/ftp=thunderbird.desktop
x-scheme-handler/chrome=thunderbird.desktop
text/html=thunderbird.desktop
application/x-extension-htm=thunderbird.desktop
application/x-extension-html=thunderbird.desktop
application/x-extension-shtml=thunderbird.desktop
application/xhtml+xml=thunderbird.desktop
application/x-extension-xhtml=thunderbird.desktop
application/x-extension-xht=thunderbird.desktop
[Added Associations]
x-scheme-handler/http=thunderbird.desktop;
x-scheme-handler/https=thunderbird.desktop;
x-scheme-handler/ftp=thunderbird.desktop;
x-scheme-handler/chrome=thunderbird.desktop;
text/html=thunderbird.desktop;
application/x-extension-htm=thunderbird.desktop;
application/x-extension-html=thunderbird.desktop;
application/x-extension-shtml=thunderbird.desktop;
application/xhtml+xml=thunderbird.desktop;
application/x-extension-xhtml=thunderbird.desktop;
application/x-extension-xht=thunderbird.desktop;
-
This not only causes thunderbird fail to open links, but also to
repeatedly spawn thunderbird processes, which requires a "killall
thunderbird". (Or something like that, I don't remember exactly and
don't want to reproduce it now.)
If I start firefox directly, I'm currently not asked about the default
browser (somehow it now realizes that it's default as set in
/usr/share/applications/gnome-mimeapps.list).
But in the past I sometimes was asked, and then the
~/.config/mimeapps.list was created correctly with firefox.desktop entries.
I've observed this behavior for a few weeks now, while I was working on
something unrelated and frequently deleted all related files. It still
happens with current 45.7.0esr-3.
Thanks and greets
jre
-- Package-specific info:
-- Extensions information
Name: ACE editor for sources.d.n
Location: ${PROFILE_EXTENSIONS}/acesour...@geissert.debian.org.xpi
Status: app-disabled
Name: Adblock Plus
Location:
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/{d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}
Package: xul-ext-adblock-plus
Status: enabled
Name: Debian buttons
Location:
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/{8fb11c5b-84eb-4da0-9128-292eacce2dcb}
Package: xul-ext-debianbuttons
Status: enabled
Name: Default theme
Location:
/usr/lib/firefox-esr/browser/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}.xpi
Package: firefox-esr
Status: enabled
Name: Firefox Hello Beta
Location: ${PROFILE_EXTENSIONS}/l...@mozilla.org.xpi
Status: enabled
Name: Leet Key
Location: ${PROFILE_EXTENSIONS}/{3335F91D-2AEF-4097-B831-C96C60349822}.xpi
Status: enabled
Name: Password Exporter
Location: ${PROFILE_EXTENSIONS}/{B17C1C5A-04B1-11DB-9804-B622A1EF5492}.xpi
Status: enabled
Name: Privacy Badger
Location: ${PROFILE_EXTENSIONS}/jid1-mnnxcxisbpnsxq-...@jetpack.xpi
Status: enabled
Name: Tree Style Tab
Location:
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/treestyle...@piro.sakura.ne.jp
Package: xul-ext-treestyletab
Status: enabled
-- Plugins information
Name: GNOME Shell Integration
Location: /usr/lib/mozilla/plugins/libgnome-shell-browser-plugin.so
Package: gnome-shell
Status: enabled
Name: IcedTea-Web Plugin (using IcedTea-Web 1.6.2 (1.6.2-3.1))
Location: /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/IcedTeaPlugin.so
Package: icedtea-8-plugin:amd64
Status: enabled
Name: iTunes Application Detector
Location: /usr/lib/mozilla/plugins/librhythmbox-itms-detection-plugin.so
Package: rhythmbox-plugins
Status: enabled
Name: Shockwave Flash (24.0.0.194)
Location:
/usr/lib/browser-plugin-freshplayer-pepperflash/libfreshwrapper-flashplayer.so
Package: browser-plugin-freshplayer-pepperflash
Status: enabled
-- Addons package information
ii browser-plugin 0.3.5-1+b1 amd64PPAPI-host NPAPI-plugin
adapter f
ii firefox-esr45.7.0esr-3 amd64Mozilla Firefox web browser
- Ext
ii gnome-shell3.22.2-4 amd64graphical shell for the
GNOME des
ii icedtea-8-plug 1.6.2-3.1amd64web browser plugin based on
OpenJ
ii rhythmbox-plug 3.4.1-2+b1 amd64plugins for rhythmbox music
playe
ii xul-ext-adbloc 2.7.3+dfsg-1 all advertisement blocking
extension
ii xul-ext-debian 1.11-3 all Buttons for querying
Debian-relat
ii xul-ext-treest 0.18.2016111 all Show browser tabs like a tree
--
Bug#854818: firefox-esr: creates mimeapps.list entries for thunderbird.desktop if started from TB
Package: firefox-esr
Version: 45.7.0esr-3
Severity: normal
Control: found -1 45.7.0esr-1
Control: affects -1 thunderbird
Hi
in a clean system, with no previous mime entries in
~/.config/mimeapps.list and ~/.local/share/applications, and firefox
enabled to check if it is the default app:
firefox is not running. In thunderbird I click on a link. This starts
firefox and opens the link there. But now, firefox thinks it's not the
default browser. If I allow firefox to change this it creates
~/.config/mimeapps.list with *thunderbird.desktop* entries:
-
[Default Applications]
x-scheme-handler/http=thunderbird.desktop
x-scheme-handler/https=thunderbird.desktop
x-scheme-handler/ftp=thunderbird.desktop
x-scheme-handler/chrome=thunderbird.desktop
text/html=thunderbird.desktop
application/x-extension-htm=thunderbird.desktop
application/x-extension-html=thunderbird.desktop
application/x-extension-shtml=thunderbird.desktop
application/xhtml+xml=thunderbird.desktop
application/x-extension-xhtml=thunderbird.desktop
application/x-extension-xht=thunderbird.desktop
[Added Associations]
x-scheme-handler/http=thunderbird.desktop;
x-scheme-handler/https=thunderbird.desktop;
x-scheme-handler/ftp=thunderbird.desktop;
x-scheme-handler/chrome=thunderbird.desktop;
text/html=thunderbird.desktop;
application/x-extension-htm=thunderbird.desktop;
application/x-extension-html=thunderbird.desktop;
application/x-extension-shtml=thunderbird.desktop;
application/xhtml+xml=thunderbird.desktop;
application/x-extension-xhtml=thunderbird.desktop;
application/x-extension-xht=thunderbird.desktop;
-
This not only causes thunderbird fail to open links, but also repeatedly
spawn thunderbird processes, which requires a "killall thunderbird". (Or
something like that, I don't remember exactly and don't want to
reproduce it now.)
If I start firefox directly, I'm currently not asked about the default
browser (somehow it now realizes that it's default as set in
/usr/share/applications/gnome-mimeapps.list).
But in the past I sometimes was asked, and then the
~/.config/mimeapps.list was created correctly with firefox.desktop entries.
I've observed this behavior for a few weeks now, while I was working on
something unrelated and frequently deleted all related files. It still
happens with current 45.7.0esr-3.
Thanks and greets
jre
-- Package-specific info:
-- Extensions information
Name: ACE editor for sources.d.n
Location: ${PROFILE_EXTENSIONS}/acesour...@geissert.debian.org.xpi
Status: app-disabled
Name: Adblock Plus
Location:
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/{d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}
Package: xul-ext-adblock-plus
Status: enabled
Name: Debian buttons
Location:
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/{8fb11c5b-84eb-4da0-9128-292eacce2dcb}
Package: xul-ext-debianbuttons
Status: enabled
Name: Default theme
Location:
/usr/lib/firefox-esr/browser/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}.xpi
Package: firefox-esr
Status: enabled
Name: Firefox Hello Beta
Location: ${PROFILE_EXTENSIONS}/l...@mozilla.org.xpi
Status: enabled
Name: Leet Key
Location: ${PROFILE_EXTENSIONS}/{3335F91D-2AEF-4097-B831-C96C60349822}.xpi
Status: enabled
Name: Password Exporter
Location: ${PROFILE_EXTENSIONS}/{B17C1C5A-04B1-11DB-9804-B622A1EF5492}.xpi
Status: enabled
Name: Privacy Badger
Location: ${PROFILE_EXTENSIONS}/jid1-mnnxcxisbpnsxq-...@jetpack.xpi
Status: enabled
Name: Tree Style Tab
Location:
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/treestyle...@piro.sakura.ne.jp
Package: xul-ext-treestyletab
Status: enabled
-- Plugins information
Name: GNOME Shell Integration
Location: /usr/lib/mozilla/plugins/libgnome-shell-browser-plugin.so
Package: gnome-shell
Status: enabled
Name: IcedTea-Web Plugin (using IcedTea-Web 1.6.2 (1.6.2-3.1))
Location: /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/IcedTeaPlugin.so
Package: icedtea-8-plugin:amd64
Status: enabled
Name: iTunes Application Detector
Location: /usr/lib/mozilla/plugins/librhythmbox-itms-detection-plugin.so
Package: rhythmbox-plugins
Status: enabled
Name: Shockwave Flash (24.0.0.194)
Location:
/usr/lib/browser-plugin-freshplayer-pepperflash/libfreshwrapper-flashplayer.so
Package: browser-plugin-freshplayer-pepperflash
Status: enabled
-- Addons package information
ii browser-plugin 0.3.5-1+b1 amd64PPAPI-host NPAPI-plugin
adapter f
ii firefox-esr45.7.0esr-3 amd64Mozilla Firefox web browser
- Ext
ii gnome-shell3.22.2-4 amd64graphical shell for the
GNOME des
ii icedtea-8-plug 1.6.2-3.1amd64web browser plugin based on
OpenJ
ii rhythmbox-plug 3.4.1-2+b1 amd64plugins for rhythmbox music
playe
ii xul-ext-adbloc 2.7.3+dfsg-1 all advertisement blocking
extension
ii xul-ext-debian 1.11-3 all Buttons for querying
Debian-relat
ii xul-ext-treest 0.18.2016111 all Show browser tabs like a tree
--
Bug#849592: bug report - icedove: href links inoperative
control: clone -1 -2
control: retitle -1 icedove: transition old userapp .desktop file
control: retitle -2 firefox: transition old userapp .desktop file
tl;dr for the firefox and thunderbird maintainers:
The files
~/.local/share/applications/userapp-Icedove-*.desktop
~/.local/share/applications/userapp-Iceweasel-*.desktop
need to be transitioned for the new path of the Exec. Tell me if you
need more help (patches).
On 02/07/2017 09:18 PM, Rick Lutowski wrote:
> Hope this helps to isolate the problem.
Thanks for your quick feedback!
What happened is (these are sometimes only assumptions, I'm not in-depth
familiar with these packages):
Once upon a time you accepted icedove's and iceweasel's suggestion to
make them the default application for their tasks.
At that time:
* icedove created
~/.local/share/applications/userapp-Icedove-EGPMWX.desktop
with the line[1]
Exec=/usr/lib/icedove/icedove %u
* iceweasel created
~/.local/share/applications/userapp-Iceweasel-RYY0FY.desktop
with the line[2]
Exec=/usr/lib/iceweasel/iceweasel %u
* Then icedove and iceweasel each created entries for these in
~/.local/share/applications/mimeapps.list[3], which lists your
personal preferences for default applications.
Now today your issue (icedove fails to open links) is because you
followed the transition from iceweasel to firefox. Thus the specified
default app for weblinks /usr/lib/iceweasel/iceweasel doesn't exist anymore.
So the
~/.local/share/applications/userapp-{Icedove,Iceweasel}-*.desktop
files need to be transitioned. For Rick's specific issue the iceweasel
one is relevant.
A1:
It's probably best to backup them and only make a minimal change in them.
A2:
Another option would be to also rename them. This would require a change
of mimeapps.list, too. For this one needs to check both the deprecated
location ~/.local/share/applications/, and the modern one in ~/.config
(I'm still confused when which file is used by a Debian system today).
Maybe it's also necessary to explicitly trigger an update of the inverse
index of the .desktop files in mimecache.info.
A3:
Finally one could just backup and then delete the .desktop files
(current packages provide their desktop files in
/usr/share/applications/, so a new mimeapps.list entry doesn't require
the old .desktop files). Again this would require a change of
mimeapps.list and mimecache.info.
Thunderbird has a wrapper script /usr/bin/thunderbird (linked to from
/usr/bin/icedove) which does a migration of some things if an old
icedove profile folder exists, and there's no new thunderbird profile
folder yet. I now wonder if the fix should be:
B1:
in the conditional (one-time only) part of /usr/bin/thunderbird, or
B2:
(because testing users already went through this one-time transition) in
a separate new part, conditional on the existence of the old .desktop
file and its contents (e.g. grep -i icedove).
For thunderbird I suggest A1/B2.
I'm not familiar with what firefox did/does for the transition. Maybe
it already does something (see my note in [3]), but then it didn't do it
in a way that worked for you. I suggest to do something similar like
A1/B2 in /usr/bin/firefox.
Greets
jre
[1]
Rick's ~/.local/share/applications/userapp-Icedove-EGPMWX.desktop:
---
[Desktop Entry]
Encoding=UTF-8
Version=1.0
Type=Application
NoDisplay=true
Exec=/usr/lib/icedove/icedove %u
Name=Icedove
Comment=Custom definition for Icedove
[2]
Rick's ~/.local/share/applications/userapp-Iceweasel-RYY0FY.desktop:
[Desktop Entry]
Encoding=UTF-8
Version=1.0
Type=Application
NoDisplay=true
Exec=/usr/lib/iceweasel/iceweasel %u
Name=Iceweasel
Comment=Custom definition for Iceweasel
Note: I had a userapp-Firefox-1M35PY.desktop, but just deleted it
instead of investigating, because I was working on something else, see
#845334 for Wine.
[3]
I don't know when this changed, but nowadays (on a clean system with no
previous entries) firefox/thunderbird only create entries in
~/.config/mimeapps.list, which appears to use
/usr/share/applications/thunderbird.desktop and
/usr/share/applications/firefox-esr.desktop.
.
Rick's ~/.local/share/applications/mimeapps.list:
--
[Default Applications]
x-scheme-handler/mailto=userapp-Icedove-EGPMWX.desktop
message/rfc822=userapp-Icedove-EGPMWX.desktop
application/x-extension-eml=userapp-Icedove-EGPMWX.desktop
x-scheme-handler/http=userapp-Iceweasel-RYY0FY.desktop
x-scheme-handler/https=userapp-Iceweasel-RYY0FY.desktop
x-scheme-handler/ftp=userapp-Iceweasel-RYY0FY.desktop
x-scheme-handler/chrome=userapp-Iceweasel-RYY0FY.desktop
text/html=userapp-Iceweasel-RYY0FY.desktop
application/x-extension-htm=userapp-Iceweasel-RYY0FY.desktop
application/x-extension-html=userapp-Iceweasel-RYY0FY.desktop
application/x-extension-shtml=userapp-Iceweasel-RYY0FY.desktop
application/xhtml+xml=userapp-Iceweasel-RYY0FY.desktop
application/x-extension-xhtml=userapp-Iceweasel-RYY0FY.desktop
Bug#849592: bug report - icedove: href links inoperative
On 02/06/2017 05:38 PM, Rick Lutowski wrote: > On 02/06/2017 09:34 AM, Jens Reyer wrote: >> Hi Rick, >> >> [I'm currently investigating a similar issue here (yay, another one ;).] >> >> Can you post the content of these two files (if they exist on your >> system): >> ~/.config/mimeapps.list > > File mimeapps.list does not appear in ~/.config or any of its > subdirectories on my system. > >> ~/.local/share/applications/mimeapps.list > > This file exists on my system. Here are its contents: Do the files ~/.local/share/applications/userapp-Icedove-EGPMWX.desktop and userapp-Iceweasel-RYY0FY.desktop exist? If yes please post them. I assume they have broken content and need some specific transition in the packaging. As manual workaround I'd suggest to remove these .desktop files and the mimeapps.list. Afterwards I assume everything will work as expected. Firefox and Icedove/Thunderbird might ask you to make them the default apps. Assuming everything works I'd just disable that check. (Your whole *system* is probably configured correctly, but these programs don't realize this, and therefore want to be set as default in the *user session*. If you click Yes (make default) a file similar to your current mimeapps.list will be created in ~/.config/mimeapps.list (the other location is deprecated). I'd hope the new content is ok. Greets jre
Bug#849592: bug report - icedove: href links inoperative
Hi Rick, [I'm currently investigating a similar issue here (yay, another one ;).] Can you post the content of these two files (if they exist on your system): ~/.config/mimeapps.list ~/.local/share/applications/mimeapps.list On 12/30/2016 08:46 PM, Rick Lutowski wrote: > You mean mozilla-thunderbird, not Icedove/Thunderbird? (My ~home has a > .mozilla-thunderbird > config directory, but it is inactive; not accessed since 2013.) Not accessed (read) or not written to? Greets jre
Bug#851337: Desktop Integration Folder paths resets on upgrade
control: forwarded -1 https://bugs.winehq.org/show_bug.cgi?id=22974 control: tags -1 - moreinfo + upstream On 01/15/2017 04:17 AM, Marc Dequènes (duck) wrote: > On 2017-01-15 07:30, Michael Gilbert wrote: > >> I don't think this is the same issue. I think he is referring to the >> Desktop Integration settings available from winecfg (like themes and >> folders I guess), not default file associations. > > Yes, this is it. In winecfg you have a tab called "Desktop Integration" > and folder mappings for "Desktop", "My Documents"… > I don't like the default to drop all these things at the top of my home, > so I changed the paths. > > I just marked as found the other version I know affected, but this maybe > be an old issue. Possibly an upstream one, but because the Wine > integration in Debian is a bit sophisticated, I thought it was better to > see with the maintainers first. Now I understand. Indeed that is an old upstream issue since at least Wine 1.2. Setting forwarded to the upsream bug. There is a little workaround mentioned in this bug, that you might try. Besides that I doubt we can do anything about this issue in Debian. Greets jre
Bug#853886: pbuilder: Does not parse DEBBUILDOPTS to determine build type
Hi Mattia On 02/02/2017 07:44 PM, Mattia Rizzolo wrote: >> Wow, I admit I didn't have a look at the pbuilder manpage for a long >> time, but indeed this is very well described there. With this new >> knowledge I'm totally fine with this change. > > Are you? > As said, there are no way -S is going to be supported, that's just plain > stupid IMHO, but I can be convinced in supporing -A in --debbuildopts by > always looking at _all.changes. For -S I'd have a use case (gbp tagging, and separate source build with the same tool after testing the binaries), but I see how this breaks the logic. I do this now in a "--binary-indep --source-only-changes" run, which is nearly as fast as the -S previously. Now --binary-indep gives me exactly the same as -A in the past, so there is a clean way to get the needed functionality. Since -S is not supported, I think it's less confusing to also not support -A. So yes, I'm fine with that by now. Maybe you could be even more explicit about the changes in NEWS. I'll revisit the wiki page in the next days/weeks. Greets jre
Bug#853793: dpkg: ABI mismatch detector is too strict on armel/armhf
On 02/02/2017 02:30 PM, Steve McIntyre wrote: > Dropping the -nostdlib argument to the gcc call inside sonames2elf > makes a difference - it'll add libc6 to the mix and force the output > to match the system you're building for. You may then need to filter > out the libc6 entry afterwards, but that's easily done. I'll do that for wine and wine-development, keeping options open for dpkg to handle this correctly. Filtering out isn't necessary: dpkg-shlibdeps already takes care of removing redundant entries. And we do want to depend on libc6.
Bug#853886: pbuilder: Does not parse DEBBUILDOPTS to determine build type
On 02/01/2017 08:42 PM, James Clarke wrote: > For source-only builds, I don't understand why you would want to perform the > build in a chroot. You already have to be able to build the source package > outside the chroot, which then gets copied into the chroot, unpacked and a new > source package is built; why not use the first source package? If your aim is > to check the package builds, you're not actually building any binary packages; > you should instead use the new --source-only-changes option, which will build > binary packages but also generate a source-only changes. I first build the binary packages to test them. Only once everything is fine I build the source package for uploading, using gbp's magic to git tag the release. This workflow saves me from accidentally uploading/pushing something wrong, and at the same time I'm able to change minor things and release them, without having to rebuild the binary packages (which takes some time for Wine). Further it's just laziness: use the same command for all kinds of builds, just change one or two options. So this is a small plea to reconsider this decision for source-only. But of course, I can definitely set up something working again with your explanations and the new --source-only-changes, thanks! > For binary-indep-only, I assume you are using -A, which git-pbuilder sees as a > dpkg-buildpackage option and passes on to cowbuilder via --debbuildopts. > However, cowbuilder/pbuilder do not look at debbuildopts to determine what > kind > of build is being done; they have their own flags. Please use > --binary-arch/--binary-indep as per the pbuilder man page (you may need to use > --git-pbuilder-options=--binary-indep to get it passed through properly). Yes, I used -A. Funnily, the similar command with -B worked (building only the arch binaries, but not the indep ones). Wow, I admit I didn't have a look at the pbuilder manpage for a long time, but indeed this is very well described there. With this new knowledge I'm totally fine with this change. Greets jre
Bug#853886: cowbuilder: doesn't create _amd64.changes for binary-indep-only or source-only builds
Package: cowbuilder Version: 0.84 Severity: important Hi, after the recent cowbuilder update my gbp build script started to fail for binary-indep-only (-A) and source-only builds (-S), complaining about a missing *_amd64.changes file (see log below). I assume the recent changes in cowbuilder cause this, but I'm not totally sure about that. I also failed to find information what the arch in the .changes file must be. I assume it's the host arch. Otherwise I'd say git-pbuilder is looking for the wrong file. Personally I see this as rc bug, but that's your call. Thanks for taking care of cowbuilder! Greets jre $ gbp buildpackage --git-pbuilder --git-arch=amd64 --git-dist=sid --git-upstream-tag="wine-%(version)s" -S gbp:info: Building with (cowbuilder) for sid:amd64 Building with cowbuilder for distribution sid, architecture amd64 + pdebuild --buildresult ../ --pbuilder cowbuilder --debbuildopts ' '\''-S'\''' -- --architecture amd64 --basepath /home//base-sid-amd64.cow I: using cowbuilder as pbuilder [...] make[1]: Leaving directory '/build/wine-development-2.0' dpkg-source -b wine-development-2.0 dpkg-source: info: using source format '3.0 (quilt)' dpkg-source: info: building wine-development using existing ./wine-development_2.0.orig.tar.xz dpkg-source: info: building wine-development in wine-development_2.0-3.debian.tar.xz dpkg-source: info: building wine-development in wine-development_2.0-3.dsc dpkg-genbuildinfo --build=source dpkg-genchanges --build=source >../wine-development_2.0-3_source.changes dpkg-genchanges: info: not including original source code in upload dpkg-source --after-build wine-development-2.0 dpkg-buildpackage: info: binary and diff upload (original source NOT included) I: copying local configuration E: Missing changes file: /home/build/cow.29103/build/wine-development_2.0-3_amd64.changes I: unmounting /home/ccache filesystem I: unmounting dev/pts filesystem I: unmounting dev/shm filesystem I: unmounting proc filesystem I: unmounting sys filesystem I: Cleaning COW directory I: forking: rm -rf /home/build/cow.29103 gbp:error: 'git-pbuilder -S' failed: it exited with 1 -- Manually added: ii git-buildpackage 0.8.12.1 -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages cowbuilder depends on: ii cowdancer0.84 ii libc62.24-9 ii libncurses5 6.0+20161126-1 ii libtinfo56.0+20161126-1 ii pbuilder 0.228.3 cowbuilder recommends no packages. cowbuilder suggests no packages. -- no debconf information
Bug#853793: dpkg: ABI mismatch detector is too strict on armel/armhf
On 02/01/2017 04:34 PM, Steve McIntyre wrote: > Hey folks, > > On Wed, Feb 01, 2017 at 05:08:50AM +0100, Guillem Jover wrote: >> On Tue, 2017-01-31 at 22:44:36 +, James Cowgill wrote: >>> >>> Here libgsm.so has neither HARD or SOFT flags set. Also, asking gcc to >>> generate a library which does not link against libc (this is used by >>> sonames2elf in some packages) causes both flags to be set (maybe >>> because it's compatible with both?). >> >> Even worse, I've found at least one instance of a package containing >> binaries with EABIv4 (on armel, paris-traceroute). So I guess I'll have >> to remove the flags matching on EM_ARM ELF binaries for now. At least >> this will get us back to the previous behavior with objdump, no >> regression in that sense. >> >> To be able to distinguish armel from armhf I'd probably need to check >> the arm attributes section for Tag_ABI_VFP_args, which annoyingly >> seems to be set even when the HARD flag is not set. :/ But this will >> be for dpkg 1.19.x. > > Please don't go down that route, the ABI flags are intended to save > people from that. I'm curious what's going wrong with libgsm1 here > such that we're not seeing consistent ABI flags. It's not just libgsm1, on armhf the build fails because of more than 20 libraries: https://buildd.debian.org/status/fetch.php?pkg=wine=armhf=1.8.6-4=1485847439=0 Greets jre If it helps, this is the short form of the code that triggers this (we compute a list of dependencies for libs that are dlopen'ed by Wine): $ sonamesDepends="libfontconfig.so.1 libfreetype.so.6 libncurses.so.5" $ sonamesRecommends="libcups.so.2 libdbus-1.so.3 libfontconfig.so.1 libfreetype.so.6 libGL.so.1 libgnutls.so.30 libgsm.so.1 libjpeg.so.62 libncurses.so.5 libodbc.so.2 libopenal.so.1 libOSMesa.so.8 libpng16.so.16 libtiff.so.5 libX11.so.6 libXcomposite.so.1 libXcursor.so.1 libXext.so.6 libXi.so.6 libXinerama.so.1 libXrandr.so.2 libXrender.so.1 libxslt.so.1 libXxf86vm.so.1" $ printf 'INPUT(%s)\n' "$sonamesDepends" > libeverything.so $ gcc -shared -nostdlib -Wl,--no-as-needed -L. -leverything -o elf.depends $ printf 'INPUT(%s)\n' "$sonamesRecommends" > libeverything.so $ gcc -shared -nostdlib -Wl,--no-as-needed -L. -leverything -o elf.recommends $ dpkg-shlibdeps --warnings=1 \ -pdlopen \ -dDepends -edebian/tmp/elf.depends \ -dRecommends -edebian/tmp/elf.recommends \ -Tdebian/libwine.substvars
Bug#853793: dpkg: ABI mismatch detector is too strict on armel/armhf
On 02/01/2017 05:08 AM, Guillem Jover wrote: > On Tue, 2017-01-31 at 22:44:36 +, James Cowgill wrote: >> The new ABI mismatch detector seems to be a bit too strict on armel and >> armhf. Thanks to both of you for quickly handling this! >> This was first seen with wine: >> https://buildd.debian.org/status/fetch.php?pkg=wine=armhf=1.8.6-4=1485847439=0 >> https://buildd.debian.org/status/fetch.php?pkg=wine=armel=1.8.6-4=1485847712=0 >> >> But there seem to be some other recent build failures relating to this >> as well. > > Oh, wow, I'm not sure this is very kosher, but if it is causing build > failures, then it does not matter much. This sonames2elf stuff is only used to calculate dependencies on dlopen'ed libraries. For this we grep the sonames from config.h, create an ELF that depends on all of them, and then use dpkg-shlibdeps against it. It's an workaround until this feature is implemented directly in dpkg-shlibdeps (#596715, dpkg-shlibdeps: Please allow to manually add library dependencies via shlibdeps). Greets jre
Bug#848839: AppStream metadata for Wine
On 01/24/2017 12:42 AM, Matthias Klumpp wrote: > 2017-01-22 23:02 GMT+01:00 Jens Reyer <jre.wine...@gmail.com>: >> On 01/22/2017 10:36 PM, Matthias Klumpp wrote: >>> 2017-01-22 22:02 GMT+01:00 Jens Reyer <jre.wine...@gmail.com>: >>>> The new wine-development now shows up in GNOME Software Center, the >>>> installed status is correct and install/removal works. >>>> >>>> But wine is still broken in there (install status is always >>>> "installed"). I don't know if I just broke my system, or if everyone is >>>> affected. Feedback from anyone is welcome. [...] > Very strange - I can't reproduce this here, everything looks as > expected. If this persists, it's probably worth filing an upstream > bug... Nevermind, I had a stray /usr/share/appdata/org.winehq.wine.appdata.xml from my tests. Now it basically works :) So here a final thank you for working on this with me, Matthias. For the minor inconveniences I reported: https://bugzilla.gnome.org/show_bug.cgi?id=777837 (Installed status of dependencies only updated after restart) https://bugzilla.gnome.org/show_bug.cgi?id=777838 (Please disable "Launch" if only appdata.xml but no .desktop is provided) Greets jre
Bug#848839: AppStream metadata for Wine
On 01/22/2017 10:36 PM, Matthias Klumpp wrote: > 2017-01-22 22:02 GMT+01:00 Jens Reyer <jre.wine...@gmail.com>: >> The new wine-development now shows up in GNOME Software Center, the >> installed status is correct and install/removal works. >> >> But wine is still broken in there (install status is always >> "installed"). I don't know if I just broke my system, or if everyone is >> affected. Feedback from anyone is welcome. > > Sounds like a GNOME Software bug... Maybe it assumes stuff to be > installed when a metainfo file exists in /usr/share/metainfo, so if > you manually place it there, GS gets confused. If that's not the case, > this is a weird GS bug - can you verify this bug with GNOME Software > 3.22.5 (in unstable)? Still there with 3.22.5-1. What's strange is that this only happens with wine, but not with wine-development, although both are identical here besides their AppStream id and name. While testing I indeed had placed the files manually somewhere (maybe only the one for wine, but not that for wine-development), but removed them since. With all wine packages uninstalled: $ ls /usr/share/applications/*wine* ls: cannot access '/usr/share/applications/*wine*': No such file or directory $ ls /usr/share/metainfo org.freedesktop.appstream.cli.metainfo.xml $ ls /var/cache/app-info/xmls/ fwupd.xml
Bug#848839: AppStream metadata for Wine
[ Wine in GNOME Software Center ] On 01/21/2017 12:24 AM, Jens Reyer wrote: > Can anybody else check this, to rule out me messing with my system > during working on this? > > The installed status should be correct, and install/remove work. > "Launch" will not work, that is known. The new wine-development now shows up in GNOME Software Center, the installed status is correct and install/removal works. But wine is still broken in there (install status is always "installed"). I don't know if I just broke my system, or if everyone is affected. Feedback from anyone is welcome. Greets jre
Bug#848839: AppStream metadata for Wine
On 01/19/2017 09:14 PM, Matthias Klumpp wrote: > Looks like GNOME Software chokes on the project_group being set to a > group it has no knowledge of and trashes the component directly... > Removing the group and adding categories ( > https://www.freedesktop.org/software/appstream/docs/chap-CollectionData.html#tag-ct-categories > ) made it show up for me. Thanks again, indeed that worked and wine shows up in the GNOME Software Center now. However it is always shown as "installed", whether that's true or not. I've uninstalled all Wine packages, made an update and restarted the computer. Can anybody else check this, to rule out me messing with my system during working on this? The installed status should be correct, and install/remove work. "Launch" will not work, that is known. btw, all these things work for current winetricks now. Greets jre
Bug#848839: AppStream metadata for Wine
Hi again Matthias On 01/17/2017 08:17 PM, Matthias Klumpp wrote: > Anyway, Wine is now in the metadata, and after the next dinstall run > it should show up in GNOME Software. > https://appstream.debian.org/sid/main/metainfo/wine.html Thanks, the link works fine! But unfortunately wine still doesn't show up in the GNOME Software Center (unless you have it installed). Greets jre PS: If useful, please point me to a better suited place for following up on this.
Bug#848839: AppStream metadata for Wine
Hi Matthias tl;dr: it seems it's not working with appstream-generator (?) yet. Can/Should we (Wine) do something? On 01/14/2017 03:06 AM, Jens Reyer wrote: > Thanks again, also for the quick update of the documentation! > > On 01/13/2017 06:26 PM, Matthias Klumpp wrote: >>>> P.S: Let me know when an updated Wine is uploaded, this will be the >>>> only app I know which does not use the metainfo file to augment a >>>> .desktop file, and I am curious to see if the file is handled >>>> correctly. > > Just done, wine 1.8.6-2. > > appstreamcli fails with a warning: > ~ > $ appstreamcli validate debian/org.winehq.wine.appdata.xml > W - org.winehq.wine.appdata.xml:org.winehq.wine:3 > Component id belongs to a desktop-application, but does not resemble > the > .desktop file name: "org.winehq.wine" > > Validation failed. > ~ I can now see wine in the GNOME Software Center, but only if wine is installed. So I assume the metainfo from the new appstream.xml is evaluated locally, but doesn't make it in the distro-wide AppStream dataset. Assuming this is the case, I assume it is because of the missing desktop file. The appstream-generator shows the following error on https://appstream.debian.org/sid/main/issues/wine.html: ~ Hints for wine in main org.winehq.wine Errors missing-desktop-file: Found an AppStream metainfo XML file, but the associated .desktop file is missing. This often happens when the .desktop file is renamed, but the tag of the AppStream metainfo file is not adapted as well, or if the metainfo file is located in a different package than the .desktop file. Please fix the packaging or work with upstream to resolve this issue. ~ Did I understand you correctly previously that in your opinion this should work, and thus needs fixing in AppStream (appstream-generator?), but not in Wine? Besides that GNOME Software Center indeed now has a "Launch" button for wine, which obviously doesn't work. But you already said that you're discussing this with Richard Hughes, so I assume there's nothing we (Wine) can do about this. Greets! jre
Bug#851337: Desktop Integration Folder paths resets on upgrade
Hi On 01/14/2017 06:36 AM, Marc Dequènes (duck) wrote: > Since a few versions at least (but was away from gaming for some time), > after the registry is upgraded when first running a new Wine version, my > custom Desktop Integration paths are reset to default. Needless to say > it is annoying. What exactly did you set, which is then reverted by Wine? ftr, recently we (only) changed something in this area in wine-development 2.0~rc4-1 / wine 1.8.6-2, so I don't think there's a regression in the Debian packaging itself. Greets jre
Bug#848839: AppStream metadata for Wine
Thanks again, also for the quick update of the documentation! On 01/13/2017 06:26 PM, Matthias Klumpp wrote: >>> P.S: Let me know when an updated Wine is uploaded, this will be the >>> only app I know which does not use the metainfo file to augment a >>> .desktop file, and I am curious to see if the file is handled >>> correctly. Just done, wine 1.8.6-2. appstreamcli fails with a warning: ~ $ appstreamcli validate debian/org.winehq.wine.appdata.xml W - org.winehq.wine.appdata.xml:org.winehq.wine:3 Component id belongs to a desktop-application, but does not resemble the .desktop file name: "org.winehq.wine" Validation failed. ~ Now I'm curious if that works :) Greets jre
Bug#848839: AppStream metadata for Wine
Thanks a lot Matthias! On 01/12/2017 07:40 PM, Matthias Klumpp wrote: >> There is a wine.desktop, but for other reasons we only ship it as an >> example. Still, other distros probably install it. However that >> .desktop file has "NoDisplay=true" so afaik it wouldn't be used for >> AppStream anyway. > > That's not necessarily the case - if a metainfo file is provided, a > NoDisplay field is ignored. Did you use "metainfo" generally here, or specifically for foo.metainfo.xml? > "desktop" btw is an outdated name, to describe applications you can > pick the component types "desktop-application" and > "console-application" Thanks, changed. is still widespread in the documentation (tell me if I should file separate bugreports/submit patches somewhere): https://www.freedesktop.org/software/appstream/docs/sect-Metadata-Application.html "Note that the XML root must have the type property set to desktop" ^^^ "All tags defined in the generic component specification are valid for desktop application components as well." --> Suggestion: add "(and vice versa)" https://www.freedesktop.org/software/appstream/docs/chap-Quickstart.html#sect-Quickstart-DesktopApps "" ^^^ https://wiki.debian.org/AppStream/Guidelines "you can tell by the XML root-node having a type="desktop" attribute" ^^^ With appstream 0.10.5-1: $ appstream-util appdata-from-desktop foo.desktop foo.appdata.xml" --> type="desktop" > For the example file: > The validation fails with: > > Could not parse XML data: Entity: line 2: parser error : Start tag expected, > '<' > not found > > ^ > > I assume this is due to the < being some other character, because > rewriting the header worked well. Ouch, thanks! These were 'ZERO WIDTH SPACE' (U+200B) characters. I had seen "appstream-util validate" complaining, but had assumed I did the test wrongly. This was based on the example file from https://www.freedesktop.org/software/appstream/docs/chap-Quickstart.html, copied in Debian from firefox to emacs. If I copy to vim I indeed see them. So I guess the homepage needs to be fixed. > The icon types "cached", "remote" and "local" are not allowed in > metainfo files (reminds me to add a validator test for that), only > "stock" is fine. Sounds as if you are referring explicitly to "foo.metainfo.xml" files here. Should I use metainfo.xml or appdata.xml? https://www.freedesktop.org/software/appstream/docs/chap-CollectionData.html says "stock icons are loaded from stock." I don't understand what this exactly means. Where is this stock, and how is it created/what does it contain? Do I as packager have any direct influence on what it contains? Even if I address all other issues and rename to metainfo.xml I still get: $ appstream-util validate-relax org.winehq.wine.development.metainfo.xml org.winehq.wine.development.metainfo.xml: FAILED: • markup-invalid: does not have correct extension for kind Validation of files failed Is this critical? Can I ignore it or do I need to use type "generic" (I want to see Wine in Gnome Software Center)? What do you use to validate? > Otherwise the file looks fine, a screenshot might be nice though. Thanks. I'll discuss screenshots and generic release info with upstream, once I submit it there. > (Edited file is attached) Thanks again! > P.S: Let me know when an updated Wine is uploaded, this will be the > only app I know which does not use the metainfo file to augment a > .desktop file, and I am curious to see if the file is handled > correctly. Will do, maybe later today. Greets! jre org.winehq.wine.development FSFAP LGPL-2.1+ Wine (development version) Run Windows applications on Linux, BSD, Solaris and Mac OS X Wine (originally an acronym for "Wine Is Not an Emulator") is a compatibility layer capable of running Windows applications on several POSIX-compliant operating systems, such as Linux, Mac OSX, BSD. Instead of simulating internal Windows logic like a virtual machine or emulator, Wine translates Windows API calls into POSIX calls on-the-fly, eliminating the performance and memory penalties of other methods and allowing you to cleanly integrate Windows applications into your desktop. wine https://bugs.winehq.org/ https://wiki.winehq.org/FAQ https://wiki.winehq.org/ https://www.winehq.org/donate https://wiki.winehq.org/Translating Bug fixes only, we are in code freeze. application/x-ms-dos-executable application/x-msi application/x-ms-shortcut
Bug#848839: AppStream metadata for Wine
Hi Matthias, I'm working on an AppStream file for Wine (winehq.org), mainly to have it shown in the Software Center. I'm mostly done by now (initial version attached, icons are not finished yet, and stuff in there is still static). Now I got a few questions. I hope you can help me, or tell me a better place to ask. Background: I assume you generally know Wine. There is a wine.desktop, but for other reasons we only ship it as an example. Still, other distros probably install it. However that .desktop file has "NoDisplay=true" so afaik it wouldn't be used for AppStream anyway. Wine itself is not a graphical application, but of course it can be used to run such. On its own it has a few graphical helper applications (winecfg, notepad, ...), but also provides e.g. wineconsole. 1.) Component type "desktop" or "generic"? Which one should we use, given above described background? Is "generic" visible in the software center? Does "generic" accept tags which are defined only for "desktop"? 2.) License I'd like to stick with the upstream license LGPL-2.1+. Does this work for AppStream purposes? Alternatively I'm thinking about e.g. "LGPL2.1+ or MIT". 3.) Which "id" should we use? Stretch will ship 2 versions of Wine: - src:wine which tracks upstreams stable branch - src:wine-development which tracks the development branch I thought about ignoring the desktop file completely, and use for upstream and our src:wine: org.winehq.wine Wine Then I'd expand the id and change the name for src:wine-development to org.winehq.wine.development Wine (development version) Thanks in advance! Greets jre â â â org.winehq.wine.development â LGPL-2.1+ â LGPL-2.1+ â Wine (development version) âRun Windows applications on Linux, BSD, Solaris and Mac OS X â â â â Wine (originally an acronym for "Wine Is Not an Emulator") is a compatibility layer capable of running Windows applications on several POSIX-compliant operating systems, such as Linux, Mac OSX, & BSD. Instead of simulating internal Windows logic like a virtual machine or emulator, Wine translates Windows API calls into POSIX calls on-the-fly, eliminating the performance and memory penalties of other methods and allowing you to cleanly integrate Windows applications into your desktop. â â wine âwine.png âhttp://example.com/icons/foobar.png â/usr/share/pixmaps/foobar.png https://www.winehq.org/ https://bugs.winehq.org/ https://wiki.winehq.org/FAQ https://wiki.winehq.org/ https://www.winehq.org/donate https://wiki.winehq.org/Translating â WineHQ â â âBug fixes only, we are in code freeze. â â â âapplication/x-ms-dos-executable âapplication/x-msi âapplication/x-ms-shortcut â â
Bug#646693: thunderbird now in the archive (was: Bug#646693: hunspell-en-us conflicts with thunderbird because of missing version specifier)
On 10.01.2017 17:25, Rene Engelhard wrote: > tag 646693 + pending Thanks! >> So it seems that thunderbird will be part of stretch, either from the >> beginning [...] > > I don't see that happening yet, or do you have word that this will be uploaded > to stretch RSN to have a chance of migrating in time? No word on this. Just hope that this will happen before the stretch release, and not during its lifecycle.
Bug#646693: thunderbird now in the archive (was: Bug#646693: hunspell-en-us conflicts with thunderbird because of missing version specifier)
control: affects -1 thunderbird Hi Rene thunderbird was uploaded to experimental today (in src:icedove 1:45.6.0-1). So it seems that thunderbird will be part of stretch, either from the beginning on or later via an security update. Please upload a fix before January 25th. Greets and thanks for your awesome work! jre
Bug#845334: [pkg-wine-party] Bug#845334: Bug#845334: wine32: breaks xdg-open, which wants to start wine and crashes
On 05.01.2017 17:44, Jens Reyer wrote: > On 05.01.2017 16:17, James Lu wrote: >> That looks good, though I would recommend removing .vbs (VBScript) and >> .url (Windows bookmark) from the blacklist as well, because those are >> fairly Windows specific files. > > Thanks. However after thinking about this today I think we should make > sure that Wine does not create any file type association at all for > empty wineprefixes for security reasons. > > Of course it would be nice to be able to run VBScript out of the box, > but that's also true for exe, where we deliberately don't do that. > > So if we use a blacklist I (now) think we should add every extension for > which Wine creates an association for clean prefixes. > > > However we can probably go without the blacklist, because I found how to > always disable the "-a" switch (next to wine.inf it was hardcoded in one > other file). > > I just pushed that change to git. Feedback and testing very welcome. > > I'll add some bits about this to the README later. In the README I gave advice how to manually create the associations: wine winemenubuilder -a -r Unfortunately this doesn't work anymore here, unless I edit ~/.wine/system.reg and readd the "-a". Not sure why this worked in my previous tests. I'm still investigating this and hope to find a solution for manually creating the associations. Otherwise I think we should only do the blacklisting (of all extensions which get associated even from a clean prefix). Greets jre
Bug#848839: wine: Doesn't show in Software app, missing appstream metadata
On 20.12.2016 05:55, Jeremy Bicha wrote: > The next version of Debian will ship gnome-software by default in the > GNOME version. Currently, wine does not show in the Software app if it > is not already installed. Yes, we should fix that, and I hope we get that done for stretch. > When I look at the 1.8.5-1 package, I don't see a .desktop (except for > one you have stored in the examples directory). wine.desktop would be ignored by appstream even if it was installed in /usr/share/applications/, because it has NoDisplay=true See https://wiki.debian.org/AppStream/Guidelines#How_to_exclude_.desktop_files_from_the_metadata I've started working on an appdata.xml file, attached. Help and feedback welcome. TODO: * validate * must be unique (wine vs. wine-development), but the current implementation should be ok * needs to be implemented correctly (which icon to use?) * needs automation (preferrably by upstream), this is a mandatory field. * misses and needs automation (preferrably by upstream) * use in debian packaging * submit upstream Greets jre â â â org.winehq.wine.development â LGPL-2.1+ â LGPL-2.1+ â Wine âRun Windows applications on Linux, BSD, Solaris and Mac OS X â â â â Wine (originally an acronym for "Wine Is Not an Emulator") is a compatibility layer capable of running Windows applications on several POSIX-compliant operating systems, such as Linux, Mac OSX, & BSD. Instead of simulating internal Windows logic like a virtual machine or emulator, Wine translates Windows API calls into POSIX calls on-the-fly, eliminating the performance and memory penalties of other methods and allowing you to cleanly integrate Windows applications into your desktop. â â â wine.svg https://www.winehq.org/ https://bugs.winehq.org/ https://wiki.winehq.org/FAQ https://wiki.winehq.org/ https://www.winehq.org/donate â WineHQ â â âBug fixes only, we are in code freeze. â â â âapplication/x-ms-dos-executable âapplication/x-msi âapplication/x-ms-shortcut â ââ
Bug#850329: [pkg-wine-party] Bug#850329: wine creates files with binary filenames
control: tags -1 + moreinfo unreproducible control: severity -1 minor Hi Vincent, are the tests that you run available somewhere, so that I can try to reproduce this? Since this seems to affect only your tests, I'm downgrading the severity, like we do for other app-specific problems. Greets jre
Bug#845334: [pkg-wine-party] Bug#845334: wine32: breaks xdg-open, which wants to start wine and crashes
On 05.01.2017 16:17, James Lu wrote: > That looks good, though I would recommend removing .vbs (VBScript) and > .url (Windows bookmark) from the blacklist as well, because those are > fairly Windows specific files. Thanks. However after thinking about this today I think we should make sure that Wine does not create any file type association at all for empty wineprefixes for security reasons. Of course it would be nice to be able to run VBScript out of the box, but that's also true for exe, where we deliberately don't do that. So if we use a blacklist I (now) think we should add every extension for which Wine creates an association for clean prefixes. However we can probably go without the blacklist, because I found how to always disable the "-a" switch (next to wine.inf it was hardcoded in one other file). I just pushed that change to git. Feedback and testing very welcome. I'll add some bits about this to the README later. I suggest to upload rc4 tomorrow with this change, and then wait for this to migrate to testing (if no further change is required) in order to have as much testing as possible. Afterwards we'd have another week (until the 25th) for regular uploads targeted for stretch. Greets jre
Bug#845334: [pkg-wine-party] Bug#845334: Bug#845334: wine32: breaks xdg-open, which wants to start wine and crashes
On 05.01.2017 02:03, Jens Reyer wrote: > I will probably commit this tomorrow. We may add some information to the > README about this, and how to create an association manually. Alternatively we may change wine.inf (drop "-a") which should help normally (?) to prevent native associations, *and* do the blacklisting for file types so that if this is still triggered by e.g. installing Foxit Reader at least not too many associations are created. This way anybody preferring the old behavior could just manually run "winemenubuilder -a" to create all not-blacklisted associations. I'd blacklist all extensions for which Wine always creates associations, presumably: pdf rtf xml gif jfif jpe jpeg png htm html txt url wri - application/x-mswrite=libreoffice-writer.desktop msp - Microsoft Paint Image (in Windows 2.0), or application/mspowerpoint=libreoffice-impress.desktop vbs - Visual Basic Script vbs - Visual Basic Script ini - open with notepad or with native editor? Except maybe these: chm - Compiled HTML Help is the standard help system for Windows. hlp - Microsoft Windows Help file.
Bug#845334: [pkg-wine-party] Bug#845334: Bug#845334: wine32: breaks xdg-open, which wants to start wine and crashes
Thanks everyone for the feedback! I've been digging through this today.
On 04.01.2017 21:11, Stephen Kitt wrote:
> On Tue, 3 Jan 2017 09:06:21 -0500, Michael Gilbert <mgilb...@debian.org>
> wrote:
>> On Tue, Jan 3, 2017 at 8:49 AM, Jens Reyer wrote:
>>> This meets my personal preference. What do others think?
>>
>> In the long term, I think we'll end up needing to blacklist all
>> extensions with this approach.
>>
>> I'm ok with it as a temporary solution for stretch, but the ideal
>> approach would only create the files when the user explicitly tells
>> winemenubuilder to do it, rather than automatically during install,
>> upgrade, etc when the user hasn't asked for it.
>
> I've come across http://askubuntu.com/questions/323437 which suggests a
> simpler solution: dropping the "-a" switch from the winemenubuilder.exe
> command-line in wine.inf. I haven't tried this out (yet) so I don't know if
> it affects file associations inside Wine.
I just tested this in a clean environment[1], but unfortunately it
doesn't work as required:
I created a fresh prefix and installed an application. This used to
cause the generation of the unwanted native associations, but didn't
happen now - good. And the Windows application still opened pdf's with
evince (native default for pdf).
But then I installed Foxit Reader and suddenly had the whole bunch of
native associations (pdf, htm, txt, ...).
I have verified in the code that the code which generates those is
indeed only called from "winemenubuilder -a"[2].
So it looks as if something calls "winemenubuilder -a" explicitly
(wine.inf probably only changes the default). Or is that a bug in Wine
(I'll ask upstream/file a bug)?
Then I tested to force this behavior, by making the -a switch a no-op[3]:
CAVEAT 1: This removes the option to run "winemenubuilder -a" manually
(or ignores the -a switch when doing so)! - Bad, but acceptable?
Besides that I think only the functions described in [2] are affected (=
not called), so I assume there are no side effects.
The unwanted native general purpose .desktop entries are not created.
Installing an app creates as usual its launchers on the desktop and some
specific ones in ~/.local/share/applications/wine/Programs. Further
icons and menus/desktop-directories in ~/.local/share and ~/config.
The installed app correctly used evince for opening a pdf.
Installing Foxit Reader this time didn't generate all the unwanted
native associations (neither for pdf nor for anything else). Good.
The other app then used Foxit Reader for opening a pdf. But native apps
didn't. Good.
CAVEAT 2: Of course this also means that a file type association that is
not available natively, will still not be created if you install a
Windows applications which provides it. This would also be a problem if
changing wine.inf worked. - On the other side, many (me including) will
prefer this behavior, because they don't want Wine to touch their system
at all.
I will probably commit this tomorrow. We may add some information to the
README about this, and how to create an association manually.
Otherwise: I had missed to place the full list of extensions in my
previous patch. But basically I planned to blacklist nearly all
extensions for which Wine always creates associations (except a few ones
which seem to be Windows specific and don't have a native association
(on my system)).
[1]
Warning, this might also remove unrelated content:
rm -rf ~/.wine ~/.local/share/applications/
~/.local/share/desktop-directories/ ~/.local/share/icons/
~/.local/share/mime/ ~/.config/menus/applications-merged/
[2]
The function
write_freedesktop_association_entry
and (not sure if it really affects my system)
write_freedesktop_mime_type_entry
create the problematic entries.
They are *only* called from
generate_associations
which is the only place where
is_extension_blacklisted
(which I used in my previous patch) is used. generate_associations has
no other function.
generate_associations is *only* called from
RefreshFileTypeAssociations (line 3332)
which is *only* called from
wWinMain (line 3641)
and only if the "-a" switch is used.
[3]
+--- a/programs/winemenubuilder/winemenubuilder.c
b/programs/winemenubuilder/winemenubuilder.c
+@@ -3638,7 +3638,6 @@ int PASCAL wWinMain (HINSTANCE hInstance
+ break;
+ if( !strcmpW( token, dash_aW ) )
+ {
+-RefreshFileTypeAssociations();
+ continue;
+ }
+ if( !strcmpW( token, dash_rW ) )
Bug#845334: wine32: breaks xdg-open, which wants to start wine and crashes
control: tags -1 + patch
On 03.01.2017 13:16, Vincent Lefevre wrote:
> Not tried yet, but even if the .wine directory already exists,
> wine-extension-*.desktop files can be re-created when wine is run.
> This is what has just happened, as I got:
>
> -rw-r--r-- 1 vlefevre vlefevre 218 2017-01-03 13:02:23
> wine-extension-pdf.desktop
>
> and without a default for application/pdf, I get:
>
> cventin:~> xdg-mime query default application/pdf
> wine-extension-pdf.desktop
>
> I don't know what is the cause, perhaps the upgrade I did in the
> morning, where wine was upgraded.
I still don't know *exactly* what triggers the recreation, but I think
it happens on certain Wine updates, and if relevant parts of wine.inf
changed.
More importantly I think I found a good place to fix this: Attached
patch blacklists the creation for htm, txt and pdf.
It looks like as if this keeps the Wine internal associations intact, so
e.g. Wine applications are still able to open pdf's with evince here.
And as intended it prevents the association for the native applications
to Wine, so xdg-open still uses evince directly. I think we all agree
this is the wanted behavior, especially for freshly created Wine prefixes.
The only point I'm unsure about the wanted behavior is on installing a
Windows pdf reader: Some people might want that to get their default
also for the native system (e.g. xdg-open), because they always require
a specific feature from Windows Adobe Acrobat. Others might install it
and use it from time to time, but would generally prefer e.g. evince.
Currently this patch would work for the latter, because it always
prevents the creation of desktop associations for pdf's.
This meets my personal preference. What do others think?
Besides that I want to look a bit more into this to understand
winemenubuilder better, and then discuss it with upstream.
Any tests or feedback is welcome.
Greets
jre
>From a5fa99f73004f584cfcfce56921212aac7aa743a Mon Sep 17 00:00:00 2001
From: Jens Reyer <jre.wine...@gmail.com>
Date: Sat, 17 Dec 2016 16:33:52 +0100
Subject: blacklist htm, txt and pdf.
diff --git a/debian/patches/menubuilder-blacklist
b/debian/patches/menubuilder-blacklist
new file mode 100644
index 00..624ee759ac
--- /dev/null
+++ b/debian/patches/menubuilder-blacklist
@@ -0,0 +1,18 @@
+--- a/programs/winemenubuilder/winemenubuilder.c
b/programs/winemenubuilder/winemenubuilder.c
+@@ -2465,9 +2465,15 @@ static BOOL is_extension_blacklisted(LPC
+ static const WCHAR comW[] = {'.','c','o','m',0};
+ static const WCHAR exeW[] = {'.','e','x','e',0};
+ static const WCHAR msiW[] = {'.','m','s','i',0};
++static const WCHAR pdfW[] = {'.','p','d','f',0};
++static const WCHAR htmW[] = {'.','h','t','m',0};
++static const WCHAR txtW[] = {'.','t','x','t',0};
+
+ if (!strcmpiW(extension, comW) ||
+ !strcmpiW(extension, exeW) ||
++!strcmpiW(extension, htmW) ||
++!strcmpiW(extension, pdfW) ||
++!strcmpiW(extension, txtW) ||
+ !strcmpiW(extension, msiW))
+ return TRUE;
+ return FALSE;
diff --git a/debian/patches/series b/debian/patches/series
index 8999ce..1e8e711392 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,3 +1,4 @@
+menubuilder-blacklist
version-string.patch
manpages-wineserver-persistence.patch
Bug#845334: wine32: breaks xdg-open, which wants to start wine and crashes
On 09.12.2016 17:24, Vincent Lefevre wrote: > On 2016-12-09 16:44:52 +0100, Jens Reyer wrote: > This is bad. I think that the main problem is that Wine creates files > that will take precedence without the user's consents. But even if > the user wants Wine's desktop files, they should still have less > precedence than the ones from the native system. The spec should > provide a way to do this. Unfortunately I haven't found a way to assign a *lower* priority so far. So I think I have to further investigate what winemenubuilder exactly does, and if we can prevent creation of these .desktop files without breaking anything else. >> When did you first observe this behavior? Just now or for a longer time? > > I do not use xdg-open very much, so I don't know. > > Well... I think I had already removed the .wine directory in the past > for some reason. This could explain why the files were created at > some point. Not sure. Good, so I assume nothing related changed recently. Instead we are working on an issue that exists since years (I observed it once or twice, but could never reproduce till now). These common mime types might also be affected: application/pdf application/rtf application/xml image/gif image/jpeg image/png text/html text/plain >> Can you please also try with a fresh user with an empty /home? > > I'll try later, perhaps on Monday if I cannot to this remotely. > But see my remark above. Thanks in advance. Since this is a new topic for me, I'd hope to see my assumptions confirmed. I expect it to break for you after "wineboot && winecfg" (or whatever is necessary to trigger the creation of the .desktop files). All above mentioned types should be affected, unless you have them in your mimeapps.list. Greets jre
Bug#845334: wine32: breaks xdg-open, which wants to start wine and crashes
control: forwarded -1 https://bugs.winehq.org/show_bug.cgi?id=28159 control: tags -1 - moreinfo unreproducible The upstream bugreport #28159 requests to not create *native* associations for xml and html. But it also states that for *Wine* to know how to open these file types with a native application is indeed wanted. I'll followup there soon. There's another bugreport which goes even further: https://bugs.winehq.org/show_bug.cgi?id=19182 "Allow to completely disable MIME-type and application integration" Reproduce/ freedesktop specification: = To reproduce remove all (related content in) mimeapps.list (see [1] for possible locations). Here this was: ~/.config/mimeapps.list (if user clicks *in* firefox on "make default") ~/.local/share/applications/mimeapps.list (if user clicks *in* chromium on "make default") /usr/share/applications/gnome-mimeapps.list (pkg:gnome-session-common) @Vincent: I assume you have no mimeapps.list on your system that sets a default for text/html. Right? Then (going *literally* by the freedesktop specification) your report is not valid, because defaults need to be set in mimeapps.list. .desktop files and mimecache.info do not set defaults, they only tell the system about available programs. See the spec at [2]. However, if no default is specified in a mimeapps.list, then .desktop files in /home (as created by Wine) seem to take precedence before system .desktop files (e.g. /usr/share/applications/firefox-esr.desktop). See the spec at [3]. Affected systems: = For now I assume systems are safe from this if they have a mimeapps.list that has a text/html entry. According to [4] this is only Gnome and Cinnamon. I wonder why we don't get permanent reports about this e.g. by KDE users. @Vincent: When did you first observe this behavior? Just now or for a longer time? I didn't find any mime/(free)desktop related changes since Wine 1.8.0. Can you please also try with a fresh user with an empty /home? I'd expect Wine to overtake after a "wineboot && winecfg" (still need to investigate when exactly the desktop files are (re-)created). I assume there's some more magic that I don't know about yet. Crash and endless loop: === Here and in #28159 Wine hangs in an endless loop then, instead of aborting like it did for you: On 22.11.2016 16:39, Vincent Lefevre wrote: > cventin:~> xdg-open foo.html > wine: invalid directory "/home/vlefevre/.wine" in WINEPREFIX: not an absolute path > Aborted (core dumped) For me this looks like an absolute path - what is Wine complaining about? If you can reproduce this specific error please file a new bug about this. Let's keep this bug for Wine becoming default app for .html files, independently of what happens later. winebrowser / opens in notepad: === According to [5] the Winebrowser "attempts to open a URL in the native operating system's default protocol handler." So, assuming that this is also about .html files, the Wine project intends to use the native browser for this. Good. However we want to use the native browser directly for .html files, not indirectly via Wine. If I keep ~/.local/share/applications/wine-extension-htm.desktop, but remove this entry from ~/.local/share/applications/mimeinfo.cache: text/html=wine-extension-htm.desktop; ... then "xdg-open foo.html" opens in Wine's notepad. Definitely not useful, needs further investigation. Setting of /etc/alternatives/x-www-browser: === This is (unfortunately) mostly irrelevant for handling media types (mime), because these are based on .desktop files, which usually specify specific programs. However I wonder if it would be useful to have an /usr/share/applications/mimeapps.list to reference x-www-browser on all Debian systems (beyond the scope of this bug). Workaround: === To generally disable winemenubuilder, which creates these (and other!) entries, see [6]. Probably set in your .bashrc: export WINEDLLOVERRIDES="winemenubuilder.exe=d" To fix affected systems (as James Lu already wrote), see [7]. Greets jre [1] https://specifications.freedesktop.org/mime-apps-spec/latest/ar01s02.html [2] https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s09.html [3] https://specifications.freedesktop.org/mime-apps-spec/latest/ar01s04.html, however I think this lacks details. There's also https://www.freedesktop.org/wiki/Specifications/mime-apps-spec/, but the links there are dead. Need to investigate. [4] https://codesearch.debian.net/search?q=text%2Fhtml+path%3A.*mimeapps.list [5] https://wiki.winehq.org/Winebrowser [6] https://wiki.winehq.org/FAQ#How_can_I_prevent_Wine_from_changing_the_filetype_associations_on_my_system_or_adding_unwanted_menu_entries.2Fdesktop_links.3F [7] https://wiki.winehq.org/FAQ#How_do_I_wipe_the_virtual_Windows_installation.3F Upstream bugreports related to this
Bug#837177: icedove: the feed url could not be found
control: tags -1 + patch Hi Carsten On 25.10.2016 07:28, Carsten Schoenert wrote: > On Mon, Oct 24, 2016 at 10:22:58PM +0200, Jens Reyer wrote: >> The changes have been committed upstream by now (Target Milestone: >> Thunderbird 52.0). > > thanks for figuring out and adding additional information to thisd bug > report. > I'm currently unsure if we will fins to include this upstream changes > into the next uploads as we are preparing the switch back to thunderbird > packages. The plan is to serve Thunderbird packages for the Stretch > release. Thunderbird 52.0 ESR will be released 2017-03-07. If I understood the release model correctly, 52.2 ESR will be the first version of this series that will be uploaded to stretch. It will be released on 2017-06-13. No hard opinion if this bug needs to be fixed in the meantime, but personally I'd prefer so. Attached you'll find a ready made patch series. For this I added comm-central as hg/git remote and then cherry-picked the 3 commits from the upstream bug on patch-queue master. There was only one merge conflict, and I'm confident I resolved it correctly. I didn't "quilt refresh" the patches, so there are some whitespace warnings. Previously I already tested successfully that it works as expected. Now I successfully rebuilt 45.5.1-1 with this patch and run this version. Greets jre >From 23a5fbefa8135ebcb702bb4234187132baf2cb3f Mon Sep 17 00:00:00 2001 From: Jens Reyer <jre.wine...@gmail.com> Date: Sat, 3 Dec 2016 15:07:22 +0100 Subject: [PATCH] improve RSS feeds invalid certificate handling Closes: #837177 Signed-off-by: Jens Reyer <jre.wine...@gmail.com> --- ...ment-verify-mode-in-the-subscribe-dialog-.patch | 335 ...ds-with-an-invalid-certificate-fail-wit-1.patch | 40 +++ ...eeds-with-an-invalid-certificate-fail-wit.patch | 349 + debian/patches/series | 3 + 4 files changed, 727 insertions(+) create mode 100644 debian/patches/fixes/Bug-497488-Implement-verify-mode-in-the-subscribe-dialog-.patch create mode 100644 debian/patches/fixes/Bug-497488-RSS-feeds-with-an-invalid-certificate-fail-wit-1.patch create mode 100644 debian/patches/fixes/Bug-497488-RSS-feeds-with-an-invalid-certificate-fail-wit.patch diff --git a/debian/patches/fixes/Bug-497488-Implement-verify-mode-in-the-subscribe-dialog-.patch b/debian/patches/fixes/Bug-497488-Implement-verify-mode-in-the-subscribe-dialog-.patch new file mode 100644 index 000..d6e5b34 --- /dev/null +++ b/debian/patches/fixes/Bug-497488-Implement-verify-mode-in-the-subscribe-dialog-.patch @@ -0,0 +1,335 @@ +From: alta88 <alt...@gmail.com> +Date: Tue, 18 Oct 2016 12:02:00 +0200 +Subject: Bug 497488 - Implement verify mode in the subscribe dialog for + existing feed urls. r=mkmelin + +Origin: https://hg.mozilla.org/comm-central/rev/141676b80c81e2a3daeeac6ad21da35086ae0240 +Bug-Debian: https://bugs.debian.org/837177 +Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=497488 +Applied-Upstream: Thunderbird 52.0 + +Signed-off-by: Jens Reyer <jre.wine...@gmail.com> + +# Conflicts: +# mailnews/extensions/newsblog/content/FeedUtils.jsm +--- + .../chrome/messenger-newsblog/newsblog.properties | 1 + + mailnews/extensions/newsblog/content/Feed.js | 30 +++--- + mailnews/extensions/newsblog/content/FeedUtils.jsm | 2 +- + .../newsblog/content/feed-subscriptions.js | 119 ++--- + .../newsblog/content/feed-subscriptions.xul| 2 +- + 5 files changed, 102 insertions(+), 52 deletions(-) + +diff --git a/mail/locales/en-US/chrome/messenger-newsblog/newsblog.properties b/mail/locales/en-US/chrome/messenger-newsblog/newsblog.properties +index 3abbc23..c1a3c97 100644 +--- a/mail/locales/en-US/chrome/messenger-newsblog/newsblog.properties b/mail/locales/en-US/chrome/messenger-newsblog/newsblog.properties +@@ -13,6 +13,7 @@ subscribe-feedMoved=Feed subscription moved. + subscribe-feedCopied=Feed subscription copied. + subscribe-feedRemoved=Feed unsubscribed. + subscribe-feedNotValid=The Feed URL is not a valid feed. ++subscribe-feedVerified=The Feed URL has been verified. + subscribe-networkError=The Feed URL could not be found. Please check the name and try again. + subscribe-noAuthError=The Feed URL is not authorized. + subscribe-loading=Loading, please wait⦠+diff --git a/mailnews/extensions/newsblog/content/Feed.js b/mailnews/extensions/newsblog/content/Feed.js +index a4b8555..7e47260 100755 +--- a/mailnews/extensions/newsblog/content/Feed.js b/mailnews/extensions/newsblog/content/Feed.js +@@ -20,6 +20,7 @@ var FeedCache = + let index = this.normalizeHost(aUrl); + if (index in this.mFeeds) + return this.mFeeds[index]; ++ + return null; + }, + +@@ -111,13 +112,10 @@ Feed.prototype = + // Before we do anything, make sure the url is an http url. This is just + // a sanity check so we don't try o
Bug#837516: icedove: open in browser fails
On 02.12.2016 08:28, Carsten Schoenert wrote: > Hello Jens, > > On Sat, Nov 12, 2016 at 04:53:22PM +0100, Jens Reyer wrote: > [...] >> 4. Or fix mimeTypes.rdf (replace all broken "/usr/bin/iceweasel" >>occurrences (requires icedove restart): >>$ for file in $(find .icedove/ -name mimeTypes.rdf); do sed -i >> "s|/usr/bin/iceweasel|/usr/bin/x-www-browser|g" "$file" ; done >> >> I went for #4, so this is fixed for me now. > > thank you for your analysis of this problem, I was affected by this > problem too while working on the Thunderbird transition. > > I also tend to your suggested solution on point 4 as the correct way is > using x-www-browser instead of some specific browser binary in the > mimeTypes.rdf file. > I modified the new prepared starting wrapper script for the thunderbird > transition in this way. Great, thanks Carsten! Did you take care to only edit the file if necessary? Something like: grep -vq "/usr/bin/iceweasel" "$file" || sed -i "s|/usr/bin/iceweasel|/usr/bin/x-www-browser|g" "$file" Going beyond this hacky fix of mimeTypes.rdf, I'd like to know what originally created this entry and if this code still exists. And more importantly, why is about:config's "network.protocol-handler.app.http" ignored? This setting seems to be what everybody expects to be relevant, and it is directly configurable by users. But it seems to have *no* effect. Instead *only* mime information seems to be used. Either ~/.icedove/*.default/mimeTypes.rdf, or if that is missing the system's mime settings.[1] Is this behavior correct? Or should I file a new bug for that (upstream)? Greets jre [1] In a new profile there is no mimeTypes.rdf. If this file doesn't exist (or if all http related entries in there have been deleted) icedove opens links with firefox here. Then after removing /usr/share/applications/firefox-esr.desktop it uses chromium. Further strace shows that icedove checks several mime related files then, and ends up using /usr/share//mime/mime.cache. Changing the Debian alternatives system for x-www-browser to chromium has *no* effect in this case.
Bug#845334: wine32: breaks xdg-open, which wants to start wine and crashes
control: tags -1 + moreinfo unreproducible I can't reproduce the behavior you described. Here these two commands always open foo.html in firefox: $ xdg-open foo.html $ wine winebrowser foo.html And this command opens foo.html in Wine's Internet Explorer (no crash/error): $ wine iexplore.exe foo.html On 22.11.2016 16:53, Vincent Lefevre wrote: > Additional info: > > cventin:~> xdg-mime query default text/html > wine-extension-htm.desktop > > and Wine had added a file > > /home/vlefevre/.local/share/applications/wine-extension-htm.desktop It's a bit more complicated, and I'm still struggling to understand it: Indeed I have the same file ~/.local/share/applications/wine-extension-htm.desktop. This gets created e.g. when I execute wineboot && winecfg (I'm not sure what exactly triggers it). I could prevent creation of this and some other .desktop files with attached patch, which removes some lines from wine.inf, so that winemenubuilder doesn't create the .desktop files in ~/.local/share/applications/. However this has not the effects that I'd expect (despite previously cleaning old .desktop and mimecache/-list files from /home, and doing a reboot): winebrowser still uses the system browser (I'd expect it to just fail because it doesn't know which application to use). So I can neither reproduce your issue or confirm your suspicion that wine-extension-htm.desktop is the culprit, nor do I see the benefit of having that .desktop file. More details: Previously I had: $ xdg-mime query default text/html userapp-Firefox-1M35PY.desktop This was due to an entry in .config/mimeapps.list. I deleted that file, and so far it wasn't recreated. Now I have: $ xdg-mime query default text/html firefox-esr.desktop;firefox.desktop; This stays independently of any changes by Wine. It originates from files in /usr/share/applications/. Specifically firefox-esr.desktop and gnome-mimeapps.list. btw, chromium.desktop and mimeinfo.cache from that directory seem to have no effect. Vincent: I'm interested in learning where the wine* association that you have is saved to. Can you check the mimecache/-list files in ~/.config ~/.local/share/applications/ /usr/share/applications/? When you've found the entry, try removing it or the whole file. Does this help permanently? What happens if you delete and recreate your ~/.wine directory? Finally, which desktop environment are you using? Since when? (I use Gnome here and recently reinstalled my system, but copied over some configuration in /home.) Greets jre Description: Disable installation of some .desktop files. Author: Jens Reyer <jre.wine...@gmail.com> Bug-Debian: https://bugs.debian.org/845334 --- a/loader/wine.inf.in +++ b/loader/wine.inf.in @@ -189,9 +189,6 @@ HKCR,.pdf,,2,"pdffile" HKCR,.rtf,,2,"rtffile" HKCR,.wri,,2,"wrifile" HKCR,*\shellex\ContextMenuHandlers,,16 -HKCR,chm.file,,2,"Compiled HTML Help File" -HKCR,chm.file\DefaultIcon,,2,"%10%\hh.exe,0" -HKCR,chm.file\shell\open\command,,2,"%10%\hh.exe %1" HKCR,cplfile,,2,"Control Panel Item" HKCR,cplfile\shell\cplopen,,2,"Open with Control Panel" HKCR,cplfile\shell\cplopen\command,,2,"rundll32.exe shell32.dll,Control_RunDLL ""%1"",%*" @@ -203,18 +200,8 @@ HKCR,folder\shell\open\ddeexec,,2,"[View HKCR,folder\shell\open\ddeexec,"NoActivateHandler",2,"" HKCR,folder\shell\open\ddeexec\application,,2,"Folders" HKCR,folder\shellex\ContextMenuHandlers,,16 -HKCR,hlpfile,,2,"Help File" -HKCR,hlpfile\shell\open\command,,2,"%11%\winhlp32.exe %1" -HKCR,htmlfile\shell\open\command,,2,"""%11%\winebrowser.exe"" -nohome" -HKCR,htmlfile\shell\open\ddeexec,,2,"""%1"",,-1,0" -HKCR,htmlfile\shell\open\ddeexec,"NoActivateHandler",2,"" -HKCR,htmlfile\shell\open\ddeexec\Application,,2,"IExplore" -HKCR,htmlfile\shell\open\ddeexec\Topic,,2,"WWW_OpenURL" HKCR,inffile,,2,"Setup Information" HKCR,inffile\shell\install\command,,2,"%11%\rundll32.exe setupapi,InstallHinfSection DefaultInstall 132 %1" -HKCR,inifile,,2,"Configuration Settings" -HKCR,inifile\shell\open\command,,2,"%11%\notepad.exe %1" -HKCR,inifile\shell\print\command,,2,"%11%\notepad.exe /p %1" HKCR,lnkfile,,2,"Shortcut" HKCR,lnkfile,"NeverShowExt",2,"" HKCR,lnkfile,"IsShortcut",2,"yes" @@ -236,14 +223,6 @@ HKCR,pdffile\shell\open\ddeexec,,2,"""%1 HKCR,pdffile\shell\open\ddeexec,"NoActivateHandler",2,"" HKCR,pdffile\shell\open\ddeexec\Application,,2,"IExplore" HKCR,pdffile\shell\open\ddeexec\Topic,,2,"WWW_OpenURL" -HKCR,rtffile,,2,"Rich Text Document" -HKCR,rtffile\shell\open\command,,2,&quo
Bug#845500: nftables: notrack target fails with No such file or directory
On 24.11.2016 01:34, Peter Colberg wrote: > Assuming 4.9 becomes the stretch kernel, could you backport the patch? According to https://lists.debian.org/debian-devel-announce/2016/03/msg0.html it will be 4.10. Greets jre
Bug#845334: wine32: breaks xdg-open, which wants to start wine and crashes
control: severity -1 important Hi Vincent, this only affects users that actually use Wine (if at all, see below). Only then the .desktop file gets created (e.g. on running "winecfg" the first time). Downgrading to important for now. Funnily I can't reproduce this here. Despite having the problematic wine entry in /home my system still uses firefox to open html files. Even after removing and recreating the wine .desktop entries. Therefore I also can't reproduce the specific crash. I'm still working on understanding mime et al.: AFAIK the .desktop files are somehow generated by winemenubuilder. >From the .desktop files the system (not Wine itself) generates a mimeinfo.cache file, which basically is a reverse index of them. It seems the systemwide /usr/share/applications/mimeinfo.cache has precendence over ~/.local/share/applications/mimeinfo.cache (here?): $ grep htm ~/.local/share/applications/mimeinfo.cache application/vnd.ms-htmlhelp=wine-extension-chm.desktop; application/x-extension-htm=wine-extension-htm.desktop; application/x-extension-html=wine-extension-html.desktop; $ grep htm /usr/share/applications/mimeinfo.cache application/xhtml+xml=firefox-esr.desktop; application/xhtml_xml=chromium.desktop; text/html=firefox-esr.desktop;chromium.desktop; $ xdg-mime query default text/html userapp-Firefox-1M35PY.desktop No idea (yet) where/what this userapp-Firefox-1M35PY.desktop exactly is. Outlook: I think we want to keep winemenubuilder generally because that should be used during the installation of Windows applications for creating specific wanted file type associations. But we want to patch out the generation of these general purpose file type associations for e.g. *.html or (imo even more annoying) *.txt. That might even be proposed to upstream. Greets jre
Bug#845452: Bug#845171: wine-development: FTBFS: ld aborts or segfaults
On 23.11.2016 18:06, Matthias Klose wrote: > ta, and the fix will be in the next binutils upload too. Great, given your recent binutils upload rate I expect that to happen soon. So I'll probably stay lazy and avoid changing wine-development.
Bug#845452: Bug#845171: wine-development: FTBFS: ld aborts or segfaults
Control: reassign 845171 winbind/2.27.51.20161118-2
Control: affects 845171 wine-development
Control: tags 845171 - help moreinfo
Control: tags 845452 = patch
[ Referencing the other related bug here. ]
Matthias Klose wrote in https://bugs.debian.org/844847#35
> This looks like another regression with handling $ORIGIN in the
> linker (-rpath=\$ORIGIN/<...>). The work around for the packages
> is to remove that option, you don't need to relocate the binaries
> when shipped as a debian package.
Thanks a lot! I can confirm that wine-development builds again with
attached patch, which removes the rpath $ORIGIN in configure.ac.
I'll test that a bit more and then commit for wine-development.
Matthias Klose wrote in https://bugs.debian.org/844847#35
> Cloning the bugs for the original packages ...
#845171 was still assigned to wine-development. Fixing metadata to what
I think you wanted.
Greets!
jre
--- a/configure.ac
+++ b/configure.ac
@@ -887,12 +887,12 @@ case $host_os in
WINE_TRY_CFLAGS([-fPIC -Wl,--export-dynamic],
[LDEXECFLAGS="-Wl,--export-dynamic"])
- WINE_TRY_CFLAGS([-fPIC -Wl,--rpath,\$ORIGIN/../lib],
- [LDRPATH_INSTALL="-Wl,--rpath,\\\$\$ORIGIN/\`\$(MAKEDEP) -R \${bindir} \${libdir}\`"
- LDRPATH_LOCAL="-Wl,--rpath,\\\$\$ORIGIN/\$(top_builddir)/libs/wine"],
- [WINE_TRY_CFLAGS([-fPIC -Wl,-R,\$ORIGIN/../lib],
- [LDRPATH_INSTALL="-Wl,-R,\\\$\$ORIGIN/\`\$(MAKEDEP) -R \${bindir} \${libdir}\`"
-LDRPATH_LOCAL="-Wl,-R,\\\$\$ORIGIN/\$(top_builddir)/libs/wine"])])
+ WINE_TRY_CFLAGS([-fPIC -Wl,--rpath,./lib],
+ [LDRPATH_INSTALL="-Wl,--rpath,\`\$(MAKEDEP) -R \${bindir} \${libdir}\`"
+ LDRPATH_LOCAL="-Wl,--rpath,\$(top_builddir)/libs/wine"],
+ [WINE_TRY_CFLAGS([-fPIC -Wl,-R,./lib],
+ [LDRPATH_INSTALL="-Wl,-R,\`\$(MAKEDEP) -R \${bindir} \${libdir}\`"
+LDRPATH_LOCAL="-Wl,-R,\$(top_builddir)/libs/wine"])])
WINE_TRY_CFLAGS([-Wl,--enable-new-dtags],
[LDRPATH_INSTALL="$LDRPATH_INSTALL -Wl,--enable-new-dtags"])
Bug#845171: wine-development: FTBFS: ld aborts or segfaults
On 21.11.2016 22:07, Michael Gilbert wrote: > On Sun, Nov 20, 2016 at 9:16 PM, Jens Reyer wrote: >> wine-development 1.9.22-1 (in stretch) built successfully on all >> architectures when it was uploaded to unstable, but fails to >> build in a stretch environment on i386 now (amd64 is still fine). >> Exactly the same for 1.9.23-1 on i386 in a sid environment: > > Hi Jens, > > 1.9.23-1 built for me ok in a sid i386 chroot. Can you clarify the > setup where it fails? Did you mean kfreebsd-i386? Hi Mike first off, it just built fine on debomatic-i386: http://debomatic-i386.debian.net/distribution#unstable/wine-development/1.9.23-1/buildlog And if I understood you correctly it also built fine for you *today*? So it seems i386 is a local problem, for whatever reasons. If the upcoming 1.9.24 will still build on the official buildd and noone else can reproduce this, I'd say the i386 issue may be ignored (especially for the stretch release). I'll update the bug metadata then. But of course I need to figure this out here anyway. I built with git-buildpackage for i386 (not kfreebsd-i386), on my usual amd64 stretch/sid machine. The failures began while using my old chroot (minimal base-sid-i386.cow with only wine build-deps installed). But I now created a new one and deleted the ccache. It still fails with the same error message when I do this: $ DIST=sid ARCH=i386 git pbuilder create $ DIST=sid ARCH=amd64 git pbuilder update --override-config $ gbp buildpackage -B \ --git-pbuilder \ --git-arch=i386 \ --git-dist=sid \ --git-upstream-tag="wine-%(version)s" Similarly 1.9.22-1 failed with a fresh minimal base-stretch-i386.cow, and ccache deleted. Both 1.9.22-1 and 1.9.23-1 built fine here with gbp in the past, but fail now (with an updated chroot). > A recent change to binutils adds -Wl,--enable-new-dtags by default. > That may be the cause of the problem on arm. Unfortunately no, see the buildlogs at https://buildd.debian.org/status/package.php?p=wine-development: 1.9.23-1 failed to build on Nov 13 (armel), and Nov 14 (armhf). The binutils change "ld: enable new dtags by default for linux/gnu targets. Closes: #835859." was only uploaded on Nov 17. 1.9.23-1 failed with binutils_2.27.51.20161108-1 (armel and armhf) 1.9.22-1 built with binutils_2.27-9+b1 (armel and armhf) > The i386 and arm failures are probably different issues. Ok, I'll try to look into the arm problem separately then. If I don't find a solution soon, I'll file a separate bug for that. btw, debomatic-...debian.net works like a charm for testing this. Greets jre
Bug#845171: wine-development: FTBFS: ld aborts or segfaults
Source: wine-development Version: 1.9.22-1 Justification: FTBFS on i386, armel and armhf Severity: serious Tags: help wine-development 1.9.22-1 (in stretch) built successfully on all architectures when it was uploaded to unstable, but fails to build in a stretch environment on i386 now (amd64 is still fine). Exactly the same for 1.9.23-1 on i386 in a sid environment: gcc -m32 -o wineserver async.o atom.o change.o class.o clipboard.o completion.o console.o debugger.o device.o \ directory.o event.o fd.o file.o handle.o hook.o mach.o mailslot.o main.o mapping.o mutex.o \ named_pipe.o object.o process.o procfs.o ptrace.o queue.o region.o registry.o request.o \ semaphore.o serial.o signal.o snapshot.o sock.o symlink.o thread.o timer.o token.o trace.o \ unicode.o user.o window.o winstation.o -Wl,--rpath,\$ORIGIN/../libs/wine \ ../libs/port/libwine_port.a -lwine -L../libs/wine -specs=/usr/share/dpkg/no-pie-link.specs -Wl,-z,relro -Wl,-z,now -Wl,-rpath,/usr/lib/i386-linux-gnu/wine-development collect2: fatal error: ld terminated with signal 6 [Aborted] compilation terminated. ld: malloc.c:2403: sysmalloc: Assertion `(old_top == initial_top (av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)' failed. Makefile:732: recipe for target 'wineserver' failed make[2]: *** [wineserver] Error 1 make[2]: Leaving directory '/build/wine-development-1.9.22/server' Makefile:19180: recipe for target 'server' failed make[1]: *** [server] Error 2 make[1]: *** Waiting for unfinished jobs [...] dh_auto_build: make -j4 returned exit code 2 debian/rules:100: recipe for target 'build-arch' failed make: *** [build-arch] Error 2 dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2 Further a local rebui1d of .9.22-1 failed on i386 on 2016-11-05[1], but succeeded again on 2016-11-07. 1.9.23-1 didn't build on armel[2], armhf[3] and kfreebsd-i386[4] when it was uploaded to unstable, and failed on debomatic today (the error message changed though). These other failures are not exactly identical, but also happen in ld. I assume they are all related. I'm at a loss here what the reason for the failures is. I assume it's somehow related to build-dependencies being rebuilt with pie and bindnow and/or something in binutils (I found a similar recent bugreport (#844847, xorp: FTBFS: collect2: fatal error: ld terminated with signal 6 [Aborted]) which was reassigned to binutils.) However wine 1.8.5-1 still builds fine (wine and wine-development are nearly identical, only the upstream version differs). If my assumption was true, I'd expect wine to fail, too. Maybe it will do so soon. So what to do now? I hope someone can help here. If wine(-development) gets removed from the archive we need a fix uploaded by December 25th to get it in Stretch (or find a solution with the release team). Greets jre [1] 1.9.22-1:i386, local rebuild on 2016-11-05 gcc -m32 -o wine-installed main.o \ -Wl,--rpath,\$ORIGIN/`../tools/makedep -R /usr/lib/wine-development /usr/lib/i386-linux-gnu/wine-development` -Wl,--enable-new-dtags \ -Wl,--export-dynamic -Wl,-Ttext-segment=0x7c00 -Wl,-z,max-page-size=0x1000 -lwine -lpthread \ ../libs/port/libwine_port.a -L../libs/wine -Wl,-z,relro -Wl,-z,now -Wl,-rpath,/usr/lib/i386-linux-gnu/wine-development *** Error in `/usr/bin/ld': free(): invalid next size (fast): 0x57050ae0 *** === Backtrace: = /lib/i386-linux-gnu/libc.so.6(+0x6733a)[0xf74ec33a] /lib/i386-linux-gnu/libc.so.6(+0x6df77)[0xf74f2f77] /lib/i386-linux-gnu/libc.so.6(+0x6e736)[0xf74f3736] /usr/lib/i386-linux-gnu/libbfd-2.27.51-system.20161102.so(objalloc_free+0x3d)[0xf774011d] /usr/lib/i386-linux-gnu/libbfd-2.27.51-system.20161102.so(bfd_hash_table_free+0x1c)[0xf76858ec] /usr/lib/i386-linux-gnu/libbfd-2.27.51-system.20161102.so(+0x30568)[0xf768c568] /usr/lib/i386-linux-gnu/libbfd-2.27.51-system.20161102.so(bfd_fopen+0x1c3)[0xf768ce13] /usr/lib/i386-linux-gnu/libbfd-2.27.51-system.20161102.so(bfd_openr+0x25)[0xf768ce65] /usr/bin/ld(+0x29d69)[0x5659cd69] /usr/bin/ld(+0x2a385)[0x5659d385] /usr/bin/ld(+0x2b1bf)[0x5659e1bf] /usr/bin/ld(+0x1a2e6)[0x5658d2e6] /usr/bin/ld(main+0x61f)[0x5657a3df] /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf6)[0xf749d276] /usr/bin/ld(+0x7aeb)[0x5657aaeb] === Memory map: 56573000-566ad000 r-xp 08:06 10898403 /usr/bin/i686-linux-gnu-ld.bfd 566ad000-566b1000 r--p 00139000 08:06 10898403 /usr/bin/i686-linux-gnu-ld.bfd 566b1000-566b3000 rw-p 0013d000 08:06 10898403 /usr/bin/i686-linux-gnu-ld.bfd 566b3000-566b4000 rw-p 00:00 0 56e65000-57088000 rw-p 00:00 0 [heap] f730-f7321000 rw-p 00:00 0 f7321000-f740 ---p 00:00 0 f745-f746c000 r-xp 08:06 11026496
Bug#844412: wineconsole crashes if switched to emacs mode and ctrl-y is pressed
control: reassign -1 src:wine-development control: found -1 1.9.22-1 control: severity -1 minor control: forwarded -1 https://bugs.winehq.org/show_bug.cgi?id=41733 Hi Loreno, (first off, please use reportbug to report bugs and don't change Source/Package or Version. A version "development" does not exist.) I can reproduce this (both in wine-development and in wine 1.8.5-1), but only as long as the buffer is empty. I forwarded this to upstream, see URL above. Can you confirm that it works as soon as you have something in the buffer to paste? Did this work for you before? Greets jre
Bug#837516: icedove: open in browser fails
control: found -1 icedove/1:45.4.0-1.1 Hi, I was also affected by this with my existing icedove profile, but can't reproduce it in a fresh profile. Turns out in some places my icedove config (mimeTypes.rdf) still carried "iceweasel", but I already had uninstalled the "iceweasel" transitional package. So icedove has to take its own steps to complete the iceweasel -> firefox transition. Otherwise existing profiles will lack an imo important functionality, as soon as the iceweasel package gets uninstalled. I don't know if this affects all existing profiles, or only some of them. (I use mine since about 10 years. I sometimes do configuration changes, but I'm quite sure I didn't change this setting manually/ on purpose.) A short term solution might be to depend on iceweasel, but in the long run mimeTypes.rdf in /home needs to be updated/fixed. Since (afaik) Debian maintainer scripts mustn't change data in /home, I guess this would be a job for /usr/bin/icedove itself. Possible workarounds (successfully tested): === 1. Create a new profile 2. Or reinstall the transitional package: $ sudo apt install iceweasel 3. Or manually create a compatibility link: $ sudo ln -s /usr/bin/x-www-browser /usr/bin/iceweasel 4. Or fix mimeTypes.rdf (replace all broken "/usr/bin/iceweasel" occurrences (requires icedove restart): $ for file in $(find .icedove/ -name mimeTypes.rdf); do sed -i "s|/usr/bin/iceweasel|/usr/bin/x-www-browser|g" "$file" ; done I went for #4, so this is fixed for me now. System setup/diagnosis: === According to "about:config" the http(s) protocol handlers in icedove have the default setting: network.protocol-handler.app.https;x-www-browser network.protocol-handler.app.http;x-www-browser A search in about:config for "iceweasel" is empty. But mimeTypes.rdf still references iceweasel: $ for i in $(find .icedove/ -name mimeTypes.rdf); do echo $i; grep -B1 iceweasel $i; done .icedove/91hlzsoh.default/US/mimeTypes.rdf .icedove/91hlzsoh.default/mimeTypes.rdf -- -- The alternatives system for x-www-browser is correctly setup and works, also for opening links from every other application. Changing it e.g. to chromium doesn't help. $ ls -l $(readlink -f /usr/bin/x-www-browser) -rwxr-xr-x 1 root root 126000 Sep 21 04:56 /usr/lib/firefox-esr/firefox-esr If I try to open a link from icedove I get in the error console: > Timestamp: 12.11.2016 15:17:05 > Error: NS_ERROR_FILE_NOT_FOUND: Component returned failure code: 0x80520012 > (NS_ERROR_FILE_NOT_FOUND) [nsIExternalProtocolService.loadUrl] > Source File: chrome://communicator/content/contentAreaClick.js > Line: 152 Greets jre
Bug#837177: icedove: the feed url could not be found
control: forwarded -1 https://bugzilla.mozilla.org/show_bug.cgi?id=497488
control: tags -1 + fixed-upstream
Hi again,
I again had issues subscribing to a feed getting only the meaningless
error message "The Feed URL could not be found. Please check the name
and try again".
So I tested a new version of the patches from the upstream bug: now I
got a meaningful error message ("[URL] uses an invalid security
certificate.") and was offered to add a security certificate
exception. Problem solved.
The changes have been committed upstream by now (Target Milestone:
Thunderbird 52.0).
Greets
jre
Bug#841249: calypso: Please add dependency on python-tz
Package: calypso Version: 1.5-3 Severity: normal Hi, while trying to import the .ics of my old exported ownCloud calendar calypso gave thousands of lines with: No module named pytz This was not critical, just spamming the terminal. I didn't explicitly check the imported data. Installing python-tz solved this. But again I haven't checked the data yet. Do I need to investigate that further or send a test .ics? Greets! jre -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages calypso depends on: ii git 1:2.9.3-1 ii python 2.7.11-2 ii python-daemon2.1.1-1 ii python-lockfile 1:0.12.2-2 ii python-vobject 0.9.3-2 calypso recommends no packages. calypso suggests no packages. -- no debconf information
Bug#841247: calypso: UnicodeDecodeError when importing an .ics
Package: calypso
Version: 1.5-3
Severity: normal
Hi,
I tried to import the .ics of my old exported ownCloud calendar,
but this failed with an UnicodeDecodeError. You may reproduce this
(note the accent in Café):
$ cat calypso-unicode-bug.ics
BEGIN:VCALENDAR
VERSION:2.0
BEGIN:VEVENT
SUMMARY:Café
END:VEVENT
END:VCALENDAR
$ calypso --import private/test calypso-unicode-bug.ics
Failed to import: calypso-unicode-bug.ics
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/calypso/webdav.py", line 524, in
import_file
self.import_item(new_item, path)
File "/usr/lib/python2.7/dist-packages/calypso/webdav.py", line 504, in
import_item
self.create_file(new_item, context={})
File "/usr/lib/python2.7/dist-packages/calypso/webdav.py", line 389, in
create_file
context['action'] = u'Add %s'%item
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 3: ordinal
not in range(128)
Greets!
jre
-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable-debug'), (500,
'testing-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages calypso depends on:
ii git 1:2.9.3-1
ii python 2.7.11-2
ii python-daemon2.1.1-1
ii python-lockfile 1:0.12.2-2
ii python-vobject 0.9.3-2
calypso recommends no packages.
calypso suggests no packages.
-- no debconf information
Bug#816167: wine: sporadic sound failure output BTW wine versions from debian stretch release to now
control: tags -1 + moreinfo Hello Fulano Diego Perez, do you still experience the sound issues you had in the current wine 1.8.5-1? There have been several sound related changes both in the Debian packaging and the Wine code itself since you reported this. Please report back in any case! Do/Did you experience them only in Oxford Spanish Dictionary, or also with other apps? I'm very interested in fixing any sound related issues in the Wine packages, given that a new sound system in Wine was implemented lately. But for this we need the previously requested information (see my previous mail). To start with we need at least the output of: $ WINEDEBUG="fixme+all,err+all" wine osd.exe [assuming that the Oxford Spanish Dictionary is started with a binary called osd.exe] Greets jre
Bug#837177: icedove: the feed url could not be found
Followup-For: Bug #837177 Control: tags -1 - newcomer [ Removing the tag newcomer which is meant for easy bugs with a known solution, see https://www.debian.org/Bugs/Developer#tags ] Summary: I could reproduce this, but since yesterday it's working again *without* updating icedove itself. Possible upstream bug: https://bugzilla.mozilla.org/show_bug.cgi?id=497488 @mudongliang, can you confirm this? I could reproduce this for the mentioned feed [1]. And also the feed [2] stopped updating here on/after 2016-08-18 when I updated to 1:45.2.0-4+b1. If I tried to add these URLs as new feeds in icedove I got "The feed URL could not be found. Please check the name and try again." [1] https://linux.cn/rss.xml [2] https://twigserial.wordpress.com/feed/ Other feeds still worked. The problematic feeds seem to have problems with the certificate in common (firefox says "This website does not supply identity information."). But not all https feeds were affected. Last week I still could reproduce this in 1:45.3.0-1. However at the same time for a new user on the same machine adding those feeds worked. Since yesterday everything works as expected again. I verified this using a backup of ~/.icedove from last month with both 1:45.3.0-1 and 1:45.4.0-1. Maybe related: 1.) On Oct 1 2016 I upgraded openssl 1.0.2h-1 -> 1.0.2j-1. 2.) I think the general issue is being worked on in https://bugzilla.mozilla.org/show_bug.cgi?id=497488 (RSS feeds with an invalid certificate fail with a misleading 'url could not be found' error, work if a certificate security exception is added manually). 2a) I failed to get it working by adding a certificate security exception. But (in hindsight) I assume this failed because I removed each and every certificate for servers and authorities in icedove before (while working on this bug, so this wasn't the original reason for my problems). So the following might have worked: First I saved the wordpress certificate from firefox and imported it in icedove: Preferences - Advanced - Certificates - View Certificates - Servers - Import Then I tried: Preferences - Advanced - Certificates - View Certificates - Servers - Add Exception... Add Security Exception: Location: https://twigserial.wordpress.com/feed/ - Get certificate Then I got (not surprisingly in hindsight) "The certificate is not trusted because it hasn't been verified as issued by a trusted authority using a secure signature." - Add exception 2b) Initially I also failed to get it working with the patches in the upstream bugreport (attachment 8795001 and 8795020, newer versions available in the meantime). But I still lacked the authority certificates at that time. Further I needed to refresh them which might have gone wrong. After readding the authority certificate http://pki.google.com/GIAG2.crt (and maybe also http://g.symcb.com/crls/gtglobal.crl) yesterday my patched icedove worked. Following this I tested with an old, previously broken, backup of ~/.icedove and icedove 1:45.2.0-4+b1. This combination failed in the past, but worked now. So here the bug isn't found anymore, yet the exact solution or further todo is unknown. Does running icedove and tampering with the certificates change anything outside ~/.icedove? Greets jre -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages icedove depends on: ii debianutils 4.8 ii fontconfig2.11.0-6.7 ii libasound21.1.2-1 ii libatk1.0-0 2.22.0-1 ii libc6 2.24-3 ii libcairo2 1.14.6-1+b1 ii libdbus-1-3 1.10.10-1 ii libdbus-glib-1-2 0.108-1 ii libevent-2.0-52.0.21-stable-2+b1 ii libffi6 3.2.1-6 ii libfontconfig12.11.0-6.7 ii libfreetype6 2.6.3-3+b1 ii libgcc1 1:6.1.1-11 ii libgdk-pixbuf2.0-02.36.0-1 ii libglib2.0-0 2.50.0-1 ii libgtk2.0-0 2.24.31-1 ii libhunspell-1.4-0 1.4.1-2 ii libicu57 57.1-4 ii libnspr4 2:4.12-2 ii libnss3 2:3.26-2 ii libpango-1.0-01.40.3-2 ii libpangocairo-1.0-0 1.40.3-2 ii libpangoft2-1.0-0 1.40.3-2 ii libpixman-1-0 0.34.0-1 ii libsqlite3-0 3.14.2-1 ii libstartup-notification0 0.12-4 ii libstdc++66.1.1-11 ii libvpx4 1.6.0-2 ii libx11-6 2:1.6.3-1 ii libxcomposite11:0.4.4-1 ii libxdamage1 1:1.1.4-2+b1 ii libxext6 2:1.3.3-1 ii
Bug#838474: /usr/share/man/man1/wine-stable.1.gz: wine(1) - man page incorrect
control: retitle -1 wineboot silently ignores unknown WINEARCH control: forwarded -1 https://bugs.winehq.org/show_bug.cgi?id=41378 control: severity -1 minor Hi On 09/21/2016 12:40 PM, Ph. Marek wrote: > The man page talks about WINEARCH, but lists wrong values. No, you're on the wrong track here. The Debian package is indeed called "wine32", and the WINEARCH is "win32". > With the referenced "win32" I just get an error: > > > # WINEPREFIX=$PWD/w32 WINEARCH=win32 wine wineboot > it looks like wine32 is missing, you should install it. > multiarch needs to be enabled first. as root, please > execute "dpkg --add-architecture i386 && apt-get update && > apt-get install wine32" > wine: created the configuration directory '.../w32' > wine: '.../w32' is a 32-bit installation, it cannot support 64-bit > applications. This way you correctly instructed Wine to create a 32-bit prefix, and indeed it gets set up that way. However it is not usable because you don't have the needed 32-bit packages installed. The solution is given in the commands output: # dpkg --add-architecture i386 && apt-get update && # apt-get install wine32 Note that if you have wine64 and wine32 installed and don't specify WINEARCH (I consider this the default), the created prefix will be able to run both 32- and 64-bit applications (its arch is "win64", the setup is called shared WoW64). It should also work if you first create the prefix and then only after that install wine32. > Looks like "wine32" is meant: > > # rm -rf w32 > # WINEPREFIX=$PWD/w32 WINEARCH=wine32 wine wineboot > it looks like wine32 is missing, you should install it. > multiarch needs to be enabled first. as root, please > execute "dpkg --add-architecture i386 && apt-get update && > apt-get install wine32" > wine: created the configuration directory '.../w32' Unknown WINEARCH gets silently ignored by Wine, so you created a 64-bit prefix here. Now install wine32 and it should just work. So everything is correct, you just need to do what you see in the output. I still asked upstream to explicitly check the WINEARCH setting. Greets jre
Bug#825395: winetricks: Remove wine versioned dependence to prevent conflicts with alternative wine
control: tags -1 + patch
Hi Joseph,
On 05/28/2016 10:49 PM, Joseph Bisch wrote:
> I'll make the "Depends" line be:
>
> wine | wine-development,
>
> and the "Recommends" line be:
>
> wine (>= 1.8-2) | wine-development (>= 1.9.1-1),
This is probably indeed the correct setup to reflect all
recommendations. But in practice this doesn't enforce specific versions
(which is indeed wanted in order to allow one to install alternative
Wine packages), and I never saw this kind of setup for any other packages.
In a recent discussion on debian-devel [1] it was stated that version
requirements in the packaging should only ensure that the package may be
built, and no severe (data-loss) things happen. However ensuring a fully
bug-free runtime environment is beyond what can be sensibly done in
d/control. We saw that in winetricks already.
wine-development (stretch/sid/jessie-backports) employs the alternatives
system for wine, so with wine-development installed /usr/bin/wine and
/usr/bin/wineserver exist, which is what winetricks requires.
To reflect this fact that wine-development is now a full replacement for
wine it now has a "Provides: wine" in d/control.
Long story short: I suggest to remove every Wine related dependency
except an unversioned "Depends: wine". See attached patch, based on your
0.0+20160425-2 (uploaded to mentors.do on 2016-05-28 21:26).
Greets
jre
[1] Adding version constraints in dependencies to avoid bugs,
https://lists.debian.org/debian-devel/2016/09/msg00355.html
diff --git a/debian/control b/debian/control
index 327f613..faacb05 100644
--- a/debian/control
+++ b/debian/control
@@ -19,17 +19,15 @@ Depends:
p7zip,
unzip,
wget,
- wine | wine-development,
+ wine,
zip,
${misc:Depends}
Recommends:
sudo | gksu,
- wine (>= 1.8-2) | wine-development (>= 1.9.1-1),
xdg-utils,
zenity | kdebase-bin
Suggests:
aria2,
- libwine,
tor
Description: package manager for WINE to install software easily
A POSIX shell script 'package manager' for WINE to install some
Bug#707790: [git] Please add dependency on "meld"
Control: reassign -1 src:git 1:2.9.3-1
Control: retitle -1 [git] Please add dependency on "meld"
Control: found src:git 1:1.7.10.4-2
Control: tags -1 + patch
Hi,
On 11/05/2013 at 10:47, Jens Reyer wrote:
> for creating an "External diff" gitk requires "meld" to be installed.
> So please add a Recommends or Suggests on the meld package in
> debian/control.
I don't find this "External diff" function in gitk anymore, although
meld can still be found in gitk's preferences as "External diff tool".
So probably a gitk suggests meld would still make sense.
However nowadays I think git-gui should recommend or at least suggest
meld, because as Git-citool it uses it as merge tool. This is something
I regularly use. But on a freshly installed system with git-gui and gitk
meld wasn't installed, and not even hinted for.
Reassigning to src:git because I only request any dependency on meld.
Attached patch takes the minimal approach and only adds a suggests meld
to git-gui.
Greets
jre
diff --git a/debian/control b/debian/control
index 4e4132a..a16feb1 100644
--- a/debian/control
+++ b/debian/control
@@ -257,7 +257,7 @@ Architecture: all
Multi-Arch: foreign
Depends: git (>> ${source:Upstream-Version}), git (<< ${source:Upstream-Version}-.), tk
Recommends: gitk
-Suggests: git-doc, aspell
+Suggests: git-doc, aspell, meld
Description: fast, scalable, distributed revision control system (GUI)
Git is popular version control system designed to handle very large
projects with speed and efficiency; it is used for many high profile
Bug#782075: gnome-tweak-tool: Crashes Gnome when reducing Number of Workspaces
control: found -1 mutter/3.21.91-2 Hi Andreas Henriksson, I think I found how to reproduce this: In a freshly installed Stretch system (my main machine) this happens only if you've set in the Gnome Tweak Tool: Desktop - Icons on Desktop - On After this as previously described: Workspaces - Workspace Creation - Static Workspaces - Number of Workspaces - Reduce by one --> the Desktop wallpaper gets black for a short time, then everything is back to normal. Workspaces - Number of Workspaces - Reduce by one --> Gnome session crashes Further observations from my fresh installation tests on my main machine: New Jessie installation, no changes --> crash reproducible Update to Stretch, still no changes --> no crash
Bug#782075: gnome-tweak-tool: Crashes Gnome when reducing Number of Workspaces
control: found -1 3.14.4-1~deb8u1 I just reproduced the crash on a freshly installed *Jessie* laptop (only the tasks Gnome, ssh-server, system utils, and the packages etckeeper and smartmontools* installed, nothing else, no changes). So I can/could reproduce this on 3 machines: 2x on Jessie 1x on Stretch/Sid/experimental However recently (see buglog) I found that this doesn't happen anymore for fresh users on the Stretch machine, while my regular user on the same machine still experiences this. When I first reported this bug even fresh users on that machine experienced the bug. Therefore I assume the main issue is fixed in todays mutter, but there are some configuration/whatever settings remaining which still affect todays mutter. So users updating from Jessie to Stretch might be affected. I'll probably reinstall my Stretch machine soon - I might do that twice, once Jessie->Stretch, and once Stretch directly. Any tips what I should do then, besides creating the backtrace? Greets jre
Bug#836566: Fix committed for #836566 and probably #836566
control: tag -1 + pending On 13.09.2016 21:18, Jens Reyer wrote: > jreyer-guest pushed a commit to branch master > in repository wine. > > commit 8103285d2870713930df7004a2afa292902461af > Author: Jens Reyer <jre.wine...@gmail.com> > Date: Tue Sep 13 21:17:02 2016 +0200 > > Generate the correct SERVER_PROTOCOL_VERSION. > > Closes: #836911 > Closes in stable: #836566 > > SERVER_PROTOCOL_VERSION is used to check if the running server's > and the client's version match. It is set in > include/wine/server_protocol.h (currently 515), and increased by > 1 by make_requests. But we clean server_protocol.h because it is > generated, so SERVER_PROTOCOL_VERSION in Debian is always 1. > > To fix this retrieve SERVER_PROTOCOL_VERSION on upstream import > before server_protocol.h is cleaned, and store it (decreased by > 1) in request.patch. make_request will then regenerate > server_protocol.h with the correct SERVER_PROTOCOL_VERSION. I'm quite sure #836566 (src:wine-development) will be fixed by this. For #836566 (src:wine) I only assume so. If I'm right the issue in src:wine will be fixed by the new wine-development, because version mismatches will then be detected like this: $ wine --version wine-1.8.4 (Debian 1.8.4-1) $ wine-development --version wine-1.9.18 (Debian 1.9.18-2~local1) $ winecfg & $ winecfg-development wine client error:0: version mismatch 1/515. Your wineserver binary was not upgraded correctly, or you have an older one somewhere in your PATH. Or maybe the wrong wineserver is still running? However Erik's answer in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=836566#20 might indicate that I'm on the wrong trail here. Unfortunately I got no answer for my followup question yet. Better ways to solve this are welcome. jre
Bug#837377: wine32-tools: Build with winegcc is not reproducible
On 11.09.2016 05:41, Javier Serrano Polo wrote:
> Package: wine32-tools
> Version: 1.8.4-1
> Severity: wishlist
> Tags: upstream
>
> RemoteVstPlugin from lmms-vst-server is compiled with wineg++. The build
> is not reproducible because the name of a temporary file is included.[1]
> The function that creates this file should try
>
> char* tmp = strmake("%s%s", prefix, suffix);
> fd = open(tmp, O_CREAT | O_EXCL, 0600);
>
> before mkstemps().[2]
>
> [1]
> https://tests.reproducible-builds.org/debian/dbd/unstable/i386/lmms_1.1.3-5.diffoscope.html
> ,
> look for "spec.".
> [2]
> http://source.winehq.org/git/wine.git/blob/HEAD:/tools/winegcc/winegcc.c#l265
Thanks! Can you file this upstream[1], and then update the bug here?
[1] https://bugs.winehq.org/enter_bug.cgi?product=Wine
Greets
jre
Bug#836911: /usr/bin/winecfg-development: winecfg-development is a fork bomb
On 07.09.2016 20:27, Jens Reyer wrote:
> I think I can reproduce this: Wine starts a
> wineserver which all other Wine processes connect to. This wineserver
> has to be from the same build as the connecting process. Now if wine
> (stable)'s wineserver is already running and I then start
> wine-development I can observe this issue.
It seems that in the Debian packaging SERVER_PROTOCOL_VERSION is always
1, and thus the check if server and clients match doesn't work.
Testing between Debian's and winehq's versions I get e.g.:
$ /usr/lib/wine-development/wine winecfg
$ /usr/lib/wine-development/wine winecfg
--> OK, 2 winecfg windows
$ /usr/lib/wine/wine winecfg
$ /usr/lib/wine-development/wine winecfg
--> fork bomb (use "wineserver -k" to avoid system crash)
$ /opt/wine-devel/bin/wine winecfg
$ /usr/lib/wine/wine winecfg
wine client error:0: version mismatch 515/1.
Your wine binary was not upgraded correctly,
or you have an older one somewhere in your PATH.
Or maybe the wrong wineserver is still running?
--> OK, mismatch detected
$ /opt/wine-devel/bin/wine winecfg
$ /opt/wine-staging/bin/wine winecfg
wine client error:0: version mismatch 515/516.
Your wineserver binary was not upgraded correctly,
or you have an older one somewhere in your PATH.
Or maybe the wrong wineserver is still running?
--> OK, mismatch detected
Attached patch is a dirty workaround for this, by always setting the
SERVER_PROTOCOL_VERSION to 2. So if we apply this to e.g.
src:wine-development, but not to src:wine, it will be detected if a
client tries to connect to a mismatching wineserver from the other set:
$ /usr/lib/wine-development/wine winecfg
$ /usr/lib/wine/wine winecfg
wine client error:0: version mismatch 2/1.
Your wine binary was not upgraded correctly,
or you have an older one somewhere in your PATH.
Or maybe the wrong wineserver is still running?
--> OK, mismatch detected
However this workaround doesn't catch any version incompatibilities.
So far I found that:
internally SERVER_PROTOCOL_VERSION is SERVER_PROT.
tools/make_requests puts this in include/wine/server_protocol.h.new
include/wine/server_protocol.h in git has:
#define SERVER_PROTOCOL_VERSION 515
This number seems to be updated with every relevant change.
I assume generate/request.patch is incomplete, and needs to be fixed to
correctly produce the right SERVER_PROTOCOL_VERSION. But I don't know if
I can come up with a real fix. Any help would be appreciated!
Other diagnosis (dead ends):
- /tmp/.wine-$uid gets created.
- I removed all /usr/bin/wine* and replaced the wineserver script
by the binary to rule out the alternatives system and our
scripts/link setup as reason for this.
But I assume the alternatives system just led people to playing
with wine and wine-development, which exposed this bug much
more, see also #836566.
- I built without the shlib-exit-calls.patch.
Greets
jre
diff --git a/debian/patches/generate/request.patch b/debian/patches/generate/request.patch
index 9c3f1c9..8bde81c 100644
--- a/debian/patches/generate/request.patch
+++ b/debian/patches/generate/request.patch
@@ -3,6 +3,15 @@ author: Michael Gilbert <mgilb...@debian.org>
--- a/tools/make_requests
+++ b/tools/make_requests
+@@ -397,7 +397,7 @@ print SERVER_PROT "struct reply_head
+ foreach my $req (@requests) { print SERVER_PROT "struct ${req}_reply ${req}_reply;\n"; }
+ print SERVER_PROT "};\n\n";
+
+-printf SERVER_PROT "#define SERVER_PROTOCOL_VERSION %d\n\n", $protocol + 1;
++printf SERVER_PROT "#define SERVER_PROTOCOL_VERSION %d\n\n", $protocol + 2;
+ print SERVER_PROT "#endif /* __WINE_WINE_SERVER_PROTOCOL_H */\n";
+ close SERVER_PROT;
+ update_file( "include/wine/server_protocol.h" );
@@ -437,7 +437,7 @@ foreach my $err (sort keys %errors)
push @trace_lines, "{ NULL, 0 }\n";
push @trace_lines, "};\n";
Bug#836429: q4wine: Please clarify upstream status and homepage
Or maybe use http://web.archive.org/web/*/http://q4wine.brezblock.org.ua/ That's what you get if you enter the homepage on archive.org. This URL will always work, give at least less an impression of an abandoned project, and should be available e.g. in Russia. The only drawback is it might be changed again. Personally I think this is a right of an upstream author, which we shouldn't remove, at least not if the current homepage is about the software. And personally I'd assume that the homepage won't change again. I didn't test if the asterisk is accepted in d/control.
Bug#836429: q4wine: Please clarify upstream status and homepage
Thanks for your explanation, that clarifies things for me. On 06.09.2016 15:33, Boris Pek wrote: > Hi, > >> I (co-maintainer of Wine) just saw on >> https://wiki.winehq.org/Third_Party_Applications >> that q4wine is listed as an obsolete application. [...] > Now main developer came back to active development of q4wine project and > almost all is fine. > >> Would it be correct to change this classification on winehq.org? > > Yes, sure. Will do so. > Personally I do not see the necessity to change Homepage link in this package. > Other opinions are welcome. I think an archive.org address gives the impression of an abandoned project. Furthermore, if I check an upstream URL that's often because I'm looking for solutions to current problems, while general documentation is normally found sufficiently in /usr/share/doc. Of course even with an outdated archive.org URL I may easily switch to a newer version - it's just not obvious that newer versions exists as long as I only look at the package's homepage field. Maybe use the real homepage and mention archive.org in a README.Debian. Or update the archive.org address (preferably with every release) and eventually mention the real homepage in a README.Debian. Note: Unfortunately the Homepage field is defined [1] to contain only one URL, nothing else. [1] https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Homepage Greets jre
Bug#836566: Unhandled exception in previously working program
On 07.09.2016 22:42, Erik de Castro Lopo wrote: > Jens Reyer wrote: > >> Hmm, probably that points to the same issue as in >> https://bugs.debian.org/836911. >> >> I assume that Wine forks permanently if another wineserver is already >> running. So does this happen for you, if previously no wineserver was >> running, e.g.: >> >> $ wineserver -k >> $ wine YOURPROGRAM > > Unfortunately that does not fix it. Thanks. Do you have wine-development (or any other Wine) installed? If yes, does uninstalling them help?
Bug#836566: Unhandled exception in previously working program
On 04.09.2016 15:12, Jens Reyer wrote: > Hi, > > thanks for your report. > > I can't really read backtraces, but wonder if these identical lines are > normal: > >> 22 0x7bf00d99 _start+0x28() in (0x) > [...] >> 200 0x7bf00d99 _start+0x28() in (0x) Hmm, probably that points to the same issue as in https://bugs.debian.org/836911. I assume that Wine forks permanently if another wineserver is already running. So does this happen for you, if previously no wineserver was running, e.g.: $ wineserver -k $ wine YOURPROGRAM I assume then everything just works fine. Please confirm, I'll follow up soon. Greets jre
Bug#836911: [pkg-wine-party] Bug#836911: /usr/bin/winecfg-development: winecfg-development is a fork bomb
Hi, thanks for your report. I think I can reproduce this: Wine starts a wineserver which all other Wine processes connect to. This wineserver has to be from the same build as the connecting process. Now if wine (stable)'s wineserver is already running and I then start wine-development I can observe this issue. But if no wine process is running previously this doesn't happen. E.g. everything should be fine, if you first kill an eventually running wineserver, and then start winecfg: $ wineserver-development -k $ winecfg-development But $ winecfg-stable & $ winecfg-development ... leads to this bug. Can you confirm this? AFAIK in the past Wine aborted if the "wrong" wineserver was already running. Now I have to investigate if the whole issue is caused by the alternatives system (which was introduced in wine-development 1.9.16-1 and wine 1.8.3-3), or if you just ran into this because the alternatives system made this easier for you to get wrong. Greets jre
Bug#836566: [pkg-wine-party] Bug#836566: Unhandled exception in previously working program
Hi, thanks for your report. I can't really read backtraces, but wonder if these identical lines are normal: > 22 0x7bf00d99 _start+0x28() in (0x) [...] > 200 0x7bf00d99 _start+0x28() in (0x) Maybe try to install the dbgsym packages for at least wine64 and libwine:amd64. See: https://wiki.debian.org/AutomaticDebugPackages Then, did you test with wine-development? $ sudo apt install wine-development $ sudo update-alternatives --config wine --> Choose "1 /usr/bin/wine-development" $ wine --version --> Verify that you are using wine-development now Is your test suite freely available online (or can you make it so)? >From the Debian Wine packaging itself this issue might only be because of the alternatives system added in 1.8.3-3, or because of a patch for building with newer gnutls (since 1.8.4 also in upstream). I don't really think this is the case, so in the end I guess you'll have to report this upstream: https://wiki.winehq.org/Bugs Please report your findings for both wine and wine-development and if possible post the link to your test suite. When you've done so please notify this report here by sending an email, starting with something like this line: control: forwarded -1 https://bugs.winehq.org/show_bug.cgi?id=X Greets jre
Bug#836429: q4wine: Please clarify upstream status and homepage
Source: q4wine Version: 1.3.1-1 Severity: minor Hi, I (co-maintainer of Wine) just saw on https://wiki.winehq.org/Third_Party_Applications that q4wine is listed as an obsolete application. So I wanted to see why q4wine is still in Debian ... However after a bit of investigation it looks to me as if it is actively developed, and still works and is useful with both wine and wine-development. Can you confirm this? Would it be correct to change this classification on winehq.org? [Actual bug report:] While investigating I noticed that the homepage field in d/control seems to be outdated (reason stated in #761968): Homepage: https://web.archive.org/web/20131204020055/http://q4wine.brezblock.org.ua/ d/watch has: http://sf.net/q4wine/q4wine-(.+)\.tar\.bz2 \ -> seems valid Checking the web I see: http://q4wine.brezblock.org.ua/ -> seems valid for q4wine itself (again), and points to these 2 resources: https://github.com/brezerk/q4wine/tree/master https://sourceforge.net/projects/q4wine/ -> both seem to be valid So I think one of these 3 sites should be set as Homepage in d/control. I don't know if any other change that was made because of #761968 needs reconsideration. Greets jre
Bug#836344: dh_installdocs: Typo /info/into/
Package: debhelper Version: 9.20160814 Severity: minor Tags: patch Hi, minor typo in the manpage, see attached patch. Greets jre -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.6.0-1-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 debhelper depends on: ii autotools-dev20160430.1 ii binutils 2.26.1-1 ii dh-autoreconf12 ii dh-strip-nondeterminism 0.023-2 ii dpkg 1.18.10 ii dpkg-dev 1.18.10 ii file 1:5.28-4 ii libdpkg-perl 1.18.10 ii man-db 2.7.5-1 ii perl 5.22.2-3 ii po-debconf 1.0.19 debhelper recommends no packages. Versions of packages debhelper suggests: ii dh-make 2.201606 -- no debconf information diff --git a/dh_installdocs b/dh_installdocs index d7bb24f..935d724 100755 --- a/dh_installdocs +++ b/dh_installdocs @@ -27,7 +27,7 @@ documentation into F in package build directories. List documentation files to be installed into I. -In compat 11 (or later), these will be installed info +In compat 11 (or later), these will be installed into F. Previously it would be F.
