Bug#793551: [pkg-wine-party] Bug#793551: Bug#793551: wine-development and khronos-api uploads to jessie-backports
On 08/15/2015 05:17 PM, Michael Gilbert wrote: On Fri, Aug 14, 2015 at 9:29 PM, jre wrote: Hi all, FYI (no RFS, but feedback is welcome): I've uploaded jessie-backports of wine-development and khronos-api to mentors.debian.net. I will further test them the next days, but given debdiff *.dsc looks good and I used cowbuilder et.al I strongly assume that they are fine. I will follow up when I've done the testing, or if you have any remarks. Hi, Just a couple comments. There is no need for the 1.7.48 changelog entry since that was never uploaded. Right, I was unsure about that and decided to handle it like an regular upload. Changed. Please use a real email address rather than the alioth one. OK. Somewhat nitpicky, but bug numbers should be preceded by a # in a closes. Whoops, fixed. Thanks for the feedback! I can sponsor khronos-api, unless someone beats me to it, but I'm going to deffer to others to do wine since I don't want to keep up with the rapidity of uploading it to both backports and unstable. Whoo, (I hope) I first misread that and thought you were going to stop the regular uploads to unstable. If this is not going to happen the rest should be solvable. In short-term Stephen already offered to sponsor wine. Mid-term I'd apply as Debian Maintainer. I'd hope that you and Stephen are willing to advocate me then. (I might also be able to upload to backports sooner, given a short discussion with rhonda yesterday, although he wasn't exactly sure about that). Currently I'm at DebConf, so my focus isn't on wine right now and it might take me till next week to upload a fixed and tested wine-development to mentors. Greets jre
Bug#793551: wine-development and khronos-api uploads to jessie-backports
Hi all, FYI (no RFS, but feedback is welcome): I've uploaded jessie-backports of wine-development and khronos-api to mentors.debian.net. I will further test them the next days, but given debdiff *.dsc looks good and I used cowbuilder et.al I strongly assume that they are fine. I will follow up when I've done the testing, or if you have any remarks. The backports were proposed in https://bugs.debian.org/793551 (by upstream). The wine maintainers Michael Gilbert and Stephen Kitt agree with me doing the backports, see bug log. Stephen kindly proposed to be my sponsor, thanks again. About wine-development: wine-development is Wine (the Windows API implementation) packaged from the development branch at winehq.org. Releases happen every 2 weeks (and of course I am going to push them to backports as soon as they reach Stretch for the next 2 years). Wine is developed rapidly and it is often necessary to have a very recent version of Wine for a Windows app to run. There is nearly no upstream support for older versions. Therefore I think a backport really makes sense. Current version in Jessie is 1.7.29-4. I've uploaded 1.7.49-1~bpo8+1 (which just entered Jessie while I was uploading 1.7.48). About khronos-api: khronos-api contains the Khronos XML API Registry, which is a build-dependency of current wine-development, but is not available in Jessie. I've uploaded 0~svn29577-2~bpo8+1. My backport packaging: Backporting itself has been trivial thus far. I only updated the changelog and added myself as uploader (for the latter I am not totally sure if this was correct - I just became Junior Developer in pkg-wine@alioth to have commit access to the git repo, but I don't have upload rights). I've written down my setup and steps I did at http://www.linuxquestions.org/questions/blog/jere21-257447/backporting-wine-development-for-debian-jessie-36662/ The packaging of wine-development for jessie-backports is in the jessie-backports-1.7.x branch at git://git.debian.org/git/pkg-wine/wine.git. Following are: - parts of the RFS templates for khronos-api and wine-development - debdiffs for khronos-api and wine-development dscs. Nothing more, you may stop reading if you made it thus far. Thanks! btw: just arrived in Heidelberg for DebConf. Greets jre * Package name: khronos-api Version : 0~svn29577-2~bpo8+1 * URL : https://www.opengl.org/registry * License : MIT Section : x11 It builds those binary packages: khronos-api - Khronos XML API Registry To access further information about this package, please visit the following URL: http://mentors.debian.net/package/khronos-api Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/k/khronos-api/khronos-api_0~svn29577-2~bpo8+1.dsc * Package name: wine-development Version : 1.7.49-1~bpo8+1 * URL : http://www.winehq.org/ * License : LGPL-2.1+ Section : otherosfs It builds those binary packages: fonts-wine-development - Windows API implementation - fonts libwine-development - Windows API implementation - library libwine-development-dbg - Windows API implementation - debugging symbols libwine-development-dev - Windows API implementation - development files wine-development - Windows API implementation - standard suite wine32-development - Windows API implementation - 32-bit binary loader wine32-development-preloader - Windows API implementation - prelinked 32-bit binary loader wine32-development-tools - Windows API implementation - 32-bit developer tools wine64-development - Windows API implementation - 64-bit binary loader wine64-development-preloader - Windows API implementation - prelinked 64-bit binary loader wine64-development-tools - Windows API implementation - 64-bit developer tools To access further information about this package, please visit the following URL: http://mentors.debian.net/package/wine-development Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/w/wine-development/wine-development_1.7.49-1~bpo8+1.dsc $ debdiff khronos-api_0~svn29577-2.dsc khronos-api_0~svn29577-2~bpo8+1.dsc gpgv: Signature made Thu 13 Aug 2015 11:32:31 PM CEST using RSA key ID 2B573076 gpgv: Can't check signature: public key not found dpkg-source: warning: failed to verify signature on /home/jens/development/wine/khronos/khronos-api_0~svn29577-2~bpo8+1.dsc diff -Nru khronos-api-0~svn29577/debian/changelog khronos-api-0~svn29577/debian/changelog --- khronos-api-0~svn29577/debian/changelog 2015-03-29 08:01:47.0 +0200 +++ khronos-api-0~svn29577/debian/changelog 2015-08-13 23:32:08.0 +0200 @@ -1,3 +1,10 @@ +khronos-api (0~svn29577-2~bpo8+1) jessie-backports; urgency=medium + + * Rebuild for jessie-backports. + * Added myself as uploader. + + -- Jens Reyer jreyer-gu
Bug#793551: [pkg-wine-party] Bug#793551: Bug#793551: wine-development: Consider providing through Backports instead of Stable
On 08/04/2015 04:38 AM, Michael Gilbert wrote: On Sun, Jul 26, 2015 at 10:54 PM, jre wrote: First off, yes, the current upstream version via backports would be nice. Now I'm seriously thinking about doing wine-development backports for Jessie's lifespan if I find a sponsor (I'm not a Debian Developer or Maintainer). Mike, Stephen, what do you think? Since you've been contributing for a while, please feel free to request access to pkg-wine on alioth. You can start work on a jessie-backport branch. Great! Thanks. Will do so soon. I've been thinking about jessie-backport-1.7.x to be more future proof. Greets jre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793879: Failed to connect to the mount manager in win64
On 07/31/2015 03:44 PM, Eric Christensen wrote: Versions of packages wine depends on: ii file1:5.22+15-2 ii wine32 1.6.2-20 You are missing the package wine64. Although it is not needed if you use only 32-bit applications, you normally should install it. $ ls -l /usr/bin/wine32 /usr/bin/wine64 ls: cannot access /usr/bin/wine64: No such file or directory lrwxrwxrwx 1 root root 37 Feb 23 01:40 /usr/bin/wine32 - ../lib/i386-linux- gnu/wine/bin/wine32 $ ls -l --dereference /usr/bin/wine32 /usr/bin/wine64 ls: cannot access /usr/bin/wine32: No such file or directory ls: cannot access /usr/bin/wine64: No such file or directory [...] $ WINEARCH=win32 WINEDEBUG=fixme+all,err+all WINEPREFIX=$HOME/.wine wine amhc34062b.exe error: unable to find wine executable. this shouldn't happen. I totally agree with that message. Although the link (/usr/bin/wine32) exists, you are missing its target /usr/lib/i386-linux-gnu/wine/bin/wine32 (or .../wine), which is essential. All these are part of the package wine32 which seems to be installed correctly. So ... No idea how you could end up with the package wine32 being installed, but it's content not being there. Check your disk if it is full/damaged/whatever. If you see errors during package installation don't ignore them. Have you done any special configuration or are you using a non-default filesystem? When you wrote the first post, wine32 was still installed really correctly. Make a clean reinstall. First remove all wine packages (please post the output) (one line): $ sudo apt-get purge wine wine-binfmt wine32 wine64 wine32-dev-tools wine32-tools wine64-dev-tools wine64-tools fonts-wine libwine-dev libwine-dbg libwine libwine:i386 wine-bin wine64-bin libwine-alsa libwine-bin libwine-capi libwine-cms libwine-gl libwine-gphoto2 libwine-ldap libwine-openal libwine-oss libwine-print libwine-sane Then reinstall the needed packages (again please post the output): $ sudo apt-get install wine wine32 wine64 libwine libwine:i386 Then repeat all steps from my last mail. So it appears that it's not creating ~/.wine any more. :/ Worse, it doesn't exist although we are told that it is installed correctly. Greets jre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793879: Failed to connect to the mount manager in win64
On 07/31/2015 05:15 PM, Eric Christensen wrote: On Friday, July 31, 2015 04:33:12 PM jre wrote: Make a clean reinstall. First remove all wine packages (please post the output) (one line): $ sudo apt-get purge wine wine-binfmt wine32 wine64 wine32-dev-tools wine32-tools wine64-dev-tools wine64-tools fonts-wine libwine-dev libwine-dbg libwine libwine:i386 wine-bin wine64-bin libwine-alsa libwine-bin libwine-capi libwine-cms libwine-gl libwine-gphoto2 libwine-ldap libwine-openal libwine-oss libwine-print libwine-sane Ups, the fonts-wine package does not exist in Jessie, therefore the first command failed. Drop fonts-wine from the above command, then repeat every other step, for the ls -l command use (one line): $ ls -l /usr/bin/wine32 /usr/lib/i386-linux-gnu/wine/bin/wine32 /usr/lib/i386-linux-gnu/wine/bin/wine /usr/bin/wine64 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793879: Failed to connect to the mount manager in win64
On 07/31/2015 06:28 PM, Eric Christensen wrote: And this fixes everything. Hmmm... Do you still want the outputs or the knowledge that all is right with the world again? It's all very odd. No, the link being broken explains everything. Unfortunately we probably won't find out, why it was broken in the beginning. I doubt it was a bug in the wine packaging. I'll file separate bugs for the stuff I noticed and then close this bug. Have fun jre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793879: [pkg-wine-party] Bug#793879: Bug#793879: (no subject)
On 07/28/2015 10:12 PM, Austin English wrote: On Tue, Jul 28, 2015 at 3:05 PM, Eric Christensen e...@christensenplace.us wrote: On Tuesday, July 28, 2015 02:39:45 PM Austin English wrote: You're not getting any messages about creating a WINEPREFIX, so it looks like you're using an existing one still. How do I find out what's being used? I didn't see WINEPREFIX being set anywhere that I grep'd. Good question. I believe the debian packages set up a default one for Wine64 at ~/.wine64 (but someone more familiar with Debian's packaging would have to confirm). That's correct. WINEPREFIX is set in /usr/bin/wine if it is NOT specified by the user. If WINEARCH is win64 or /usr/bin/wine32 is not installed (executable), then this will be ~/.wine64 (this is for wine in Debian Jessie), otherwise ~/.wine. Note that this is not true if you directly use wine64 or any of the binaries linking to wine-wrapper (wineboot, winecfg, ...). There may be an easier way, but here's something I tested locally that should work: austin@debian-laptop:~$ WINEDEBUG=file wine wineboot 21 | grep dosdevices | head -n1 trace:file:wine_nt_to_unix_file_name L\\windows not found in /home/austin/.wine/dosdevices/c:/windows austin@debian-laptop:~$ WINEPREFIX=~/.winetest WINEDEBUG=file wine wineboot 21 | grep dosdevices | head -n1 trace:file:wine_nt_to_unix_file_name L\\??\\C:\\windows - /home/austin/.winetest/dosdevices/c:/windows Further, if you create/change a wineprefix, you'll get a line like this: wine: configuration in '/home/jens/.wine' has been updated. You can check if you have a 32- or 64-bit wineprefix with the following command (here for ~/.wine): cat .wine/system.reg | grep ^\#arch= wine: Bad EXE format for Z:\home\echristensen\Downloads\amhc34062b.exe. Could you run 'file' on that executable? $ file amhc34062b.exe amhc34062b.exe: PE32 executable (GUI) Intel 80386, for MS Windows That's a 32-bit executable, not a 64-bit one. Try wine/wine32 instead of wine64. Indeed, and since only wine has the wineprefix logic (~/.wine or ~/.wine64) you should always use the same command, preferrably wine, if in doubt together with WINEARCH: WINEARCH=win32 wine [foo.exe|wineboot|winecfg] Greets jre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793879: Failed to connect to the mount manager in win64
On 07/29/2015 02:28 AM, Eric Christensen wrote: On Wednesday, July 29, 2015 01:33:22 AM Jens Reyer wrote: Given your file results your exe is 32-bit, so use this (again, after deleting your old .wine and .wine64): export WINEARCH=win32 wine amhc34062b.exe Okay, so this is weird: $ wine amhc34062b.exe error: unable to find wine executable. this shouldn't happen. [...] From there, I made sure I removed wine64 and even removed wine and reinstalled it. That yielded the unable to find wine executable error. Please run the following command and post the output after -- System Information:: reportbug --template -T none -s none -S normal -b --list-cc none -q wine Also check the executable links themselves (errors in the link are not catched: ls -l /usr/bin/wine32 /usr/bin/wine64 ls -l --dereference /usr/bin/wine32 /usr/bin/wine64 Before this: $ rm -fr .wine $ rm -fr .wine64/$ ^ Typo in terminal? Could explain a part of the story. $ export WINEARCH=win32 $ wine amhc34062b.exe wine: created the configuration directory '/home/echristensen/.wine64' wine: '/home/echristensen/.wine64' is a 32-bit installation, it cannot support 64-bit applications. Did you change terminals or something like that? Don't do that. Perhaps reboot your system. And for every new try remove your old wineprefixes, just because Verify your settings: ls -l ~/.wine ~/.wine64 echo $WINEPREFIX , $WINELOADER , $WINEDEBUG , $WINEARCH , $WINEPREFIX Then try (one line!): WINEARCH=win32 WINEDEBUG=fixme+all,err+all WINEPREFIX=$HOME/.wine wine amhc34062b.exe Greets jre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793879: [pkg-wine-party] Bug#793879: wine: Failed to connect to the mount manager
control: severity -1 normal Hi, wine works fine for lots of users for lots of applications. Therefore downgrading the severity. Like Austin I have the strong feeling that you are working with a broken wineprefix. Did you install a 64-bit application? This would have been in ~/.wine64, not ~/.wine. If installing the windows app in a new wineprefix doesn't help, you may try the wine-development package instead of wine. It has a much newer wine version (but you still have to install your windows app new!). If you want to use the wine-development package, you have to use the command wine-development instead of wine. Please report back. Greets jre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793551: [pkg-wine-party] Bug#793551: Bug#793551: wine-development: Consider providing through Backports instead of Stable
On 07/27/2015 02:15 PM, Kyle Auble wrote: On 07/26/2015 07:54 PM, jre wrote: First off, yes, the current upstream version via backports would be nice. Now I'm seriously thinking about doing wine-development backports for Jessie's lifespan if I find a sponsor (I'm not a Debian Developer or Maintainer). I saw that you did the patches to make the two wine packages co-installable; that's impressive work. For co-installability full credits go to Michael Gilbert, the (main-)maintainer of Wine in Debian. My patches are for optimizing this, especially by allowing both wine and wine-development to provide /usr/bin/wine via the Debian alternatives system (alternatives allow the user to easily choose which package should provide a given command), which per se is quite easy. I understand. I mainly thought of moving wine-development out of Stable because I saw that wine-unstable was kept out. The only tiny advantage I can imagine is that it might be less confusing for users that just want to install the newest development release. They would have to enable Backports either way, but I expect that a few people will inevitably try the version from the Stable repo someday, then get upset that the default option isn't right. It's the kind of thing that's outweighed by any advantage to keeping wine-development in Stable. Backports is enabled per default on new Debian Jessie installations. If wine-development was in backports you'd see both versions in your package manager, e.g. 1.7.29-20 and 1.7.47-1~bpo8+1, with the first one being used per default. So once a user knows about wine-development (this knowledge hopefully spreads with the recent changes) we would have a nearly perfect way of leading him to the wine-development backports version. Greets jre PS: I'll look into your wiki changes later, thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793551: [pkg-wine-party] Bug#793551: Bug#793551: wine-development: Consider providing through Backports instead of Stable
On 07/27/2015 11:07 PM, Stephen Kitt wrote: On Mon, Jul 27, 2015 at 04:54:36AM +0200, jre wrote: First off, yes, the current upstream version via backports would be nice. Now I'm seriously thinking about doing wine-development backports for Jessie's lifespan if I find a sponsor (I'm not a Debian Developer or Maintainer). Mike, Stephen, what do you think? Sounds good to me... Great :) For backports all you need to do is verify that the version of wine-development that's currently in testing builds in stable, and that the dependencies of the resulting binary package are also in stable (or backports). If all that's OK, you can add a changelog entry to supply the appropriate version for backports, then find a sponsor. I've got an account on backports so I could do that, but I won't have any time before mid-August. Awesome, thank you! Of course this would be also necessary for following uploads every 2 or 4 weeks when a new version arrives in stable. Let's see if the dependencies cause problems in the long run. For now I'm aware of this: wine-gecko would be missing in the beginning since it's also missing in unstable/testing for current wine. I don't think this is a problem for wine-development in backports now. But it would make a wine-gecko backport desirable some time. Since Jessie 2 build-dependencies were added to wine-development: - libxml-simple-perl (is in Jessie) - khronos-api (missing in Jessie). I have to take a closer look on this. Either I keep the way opengl is handled during the build as it was in Jessie, or I also backport khronos-api. Greets jre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793551: [pkg-wine-party] Bug#793551: wine-development: Consider providing through Backports instead of Stable
On 07/25/2015 02:10 AM, Kyle Auble wrote: Source: wine-development Version: 1.7.29-4 Severity: wishlist Hello, Upstream at the wine developers' mailing list, we recently had a conversation about the wine wine-development packages. There was some confusion at first about what wine-development was for, but we've worked that out. You can read the whole thread, starting here: https://www.winehq.org/pipermail/wine-devel/2015-July/108513.html It's great to have an official Debian package of wine's development release that can live happily alongside the stable one. Kudos to everyone that put in the hard work to make that happen. However, I would like to propose, in the future, providing wine-development (and all the other -development packages) to Stable through Backports, instead of the Stable repo proper. The version of wine-development in Jessie is 1.7.29, which was released last October. Especially with a code-base that's still as fluid as wine's, that mostly defeats the purpose of a development release. Won't a version that lacks upstream's guarantee of stability, but falls out of step with current work, also contradict the goals of Debian Stable some and be harder to maintain? My gut feeling is that offering Testing's version of wine-development through Backports would be better for everyone. It would confuse end users less, keep clearer boundaries between Stable Testing, and simplify things for the Debian wine team. First off, yes, the current upstream version via backports would be nice. Now I'm seriously thinking about doing wine-development backports for Jessie's lifespan if I find a sponsor (I'm not a Debian Developer or Maintainer). Mike, Stephen, what do you think? For now I updated https://wiki.debian.org/Wine, which didn't mention wine-development previously (but still without mentioning backports or explicitly stating that wine-development is not updated in stable). For now I also subscribed to wine-devel. I'll try to (help) improve the Debian documentation at winehq. A rough description how Debian releases work: Packages get uploaded to unstable first. If they are free of major bugs they migrate to testing after a few days. About every two years testing becomes stable after going through a freeze period of about half a year (the time spans are not fixed, they last as long as necessary). So it's either testing and stable, or none of them. For wine(-development) in *stable* I'd say the focus is on not breaking things for the user (so no new versions, only bug fixes), less on the security perspective. So it isn't that hard to maintain wine-development in stable and there's no reason to keep it out of there. wine-development not in stable would make the backport even harder or just impossible to be accepted. Greets jre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793074: marked as done (libasound2-plugins: upgrade not possible due to multiarch problems)
control: found -1 1.0.29-1 control: block -1 by 777223 Hi, this issue still exists with libasound2-plugins 1.0.29-1, nothing has changed in this regard compared to the last version: You can't install both the amd64 and i386 version (multi-arch same), because they depend on libavcodec-ffmpeg(-extra)56 (multi-arch same), which in turn depend on libtwolame0, which is non-multi-arch in the current 0.3.13-1.1. The good news is that libtwolame0 0.3.13-1.2 should fix this. It was uploaded to DELAYED/5 yesterday (see #777223). I will remove the found tag again and send that mail to 793074-done, as soon as a fixed libtwolame0 is available. (Unless you prefer something else, I don't want to annoy you with this bugsystem stuff). Greets jre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758291: [pkg-wine-party] Bug#758291: Complete solution for update-alternatives
On 07/19/2015 11:45 PM, Michael Gilbert wrote: On Sun, Jul 19, 2015 at 1:03 PM, jre wrote: Please let me know if this sounds good to you and whether I should start working on this again. I was planning to wait for 1.8 to come out to do the stable/development packaging unificiation, and then after that to work on the alternatives setup. But do you actually know when the 1.8 release will happen? Although I hope that it will be before Stretch, I don't think we can take this for granted. Or it might happen too late for larger changes like this. The closest I could find is this from February by Michael Stefaniuc (https://www.winehq.org/pipermail/wine-devel/2015-February/106509.html): Version 1.8 is not even in sight as the two major features Android and CSMT are still far away. Therefore I suggest to go ahead with the alternatives setup now *without* unifying the packaging yet, while already implementing it in a way that doesn't have to be changed later on. Greets jre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758291: [pkg-wine-party] Bug#758291: Bug#758291: Complete solution for update-alternatives
Hi Mike, I'd be happy to make a new patch for Wine alternatives for the files in /usr/bin and the manpages (basically just using my last version I posted in this bugreport). So: I'd do this separately for the packaging of wine (stable, currently in branch jessie) and wine-development. So there would be no need to merge the -development packaging into the stable packaging. Also no package name would be changed. But obviously the wine (stable) binary names would need a suffix -stable, so that the unsuffixed name is available as alternative for both wine versions. I'd add a new variable DEBSUFFIX which is -stable for an empty VERSION, and the same as VERSION otherwise. I'd replace any hardcoded -development with DEBSUFFIX (or VERSION if appropriate) in order to make the packaging future proof for a merged stable/development packaging. Then I'd backport the suffix-patches in d/patches/development/ to wine (stable). I'd also add the correct breaks/replaces. Finally I'd propose to commit these changes to master and a new stretch-wine1.6 branch. Please let me know if this sounds good to you and whether I should start working on this again. Greets jre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#784280: Merging winecfg bugs and tagging jessie-ignore
control: reassign 784280 src:wine 1.6.2-20 control: reassign 789065 src:wine 1.6.2-20 control: severity 784280 normal control: tags 784280 + jessie-ignore control: forcemerge 784280 789065 Hi This is a bug in wine's wine-wrapper script. It's already fixed in the wine-development packages since 1.7.14-4. You can workaround it by explicitly calling wine, i.e. wine winecfg. Once you have installed an app in wine and thus a system.reg is created, winecfg will work just as expected, This bug will not be fixed in Debian Jessie, see https://bugs.debian.org/776784. Therefore I tag this bug jessie-ignore. Further duplicates: 739863: Fixed in version wine-unstable/1.7.14-4 776784: Closed as there exists the workaround and the bug is fixed in newer dists. Greets jre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#786519: libwine:amd64: trying to overwrite shared '/usr/share/wine/wine/fonts/sserifee.fon'
On 06/01/2015 02:15 PM, Pascal Legrand wrote: Do we have to use workaround or the bug will be solved ? It's already fixed in wine 1.6.2-22, which currently waits in the new queue (https://ftp-master.debian.org/new.html). Greets jre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787180: wine-development (arch:all) does not satisfy dependencies of a foreign-architecture package
Source: wine-development Version: 1.7.41-3 Severity: normal Control: found -1 1.7.43-1 The package wine32-development recommends wine-development, but the latter is unavailable. I guess this happens because the package wine-development is Architecture: all since 1.7.41-3, but not marked as Multi-Arch. https://wiki.ubuntu.com/MultiarchSpec: This means that for an Architecture: all package to satisfy the dependencies of a foreign-architecture package, it must be marked Multi-Arch: foreign or Multi-Arch: allowed. So please add Multi-Arch: foreign to wineVERSION. btw: the package description of wineVERSION notes: This is a virtual package that depends on the standard Wine components. which is not true, it is not virtual and has some content. Greets jre -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (100, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-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 wine-development depends on: ii wine32-development 1.7.43-1 ii wine64-development 1.7.43-1 wine-development recommends no packages. wine-development suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782896: wine32 recommends of wine ignores already installed foreign arch version
On 05/21/2015 08:34 PM, jre wrote: [ wine-development is marked as multi-arch allowed since 1.7.41-2, which should have fixed this bug. ] Ah, just saw that you changed to arch all instead of multi-arch allowed in 1.7.43-1. I already wondered why aptitude showed wine-development as arch all ;) But as of now an update to wine-development 1.7.43-1 tries to pull wine-development:i386 1.7.41-1. So I still end up with broken packages in aptitude. In aptitude wine32-development (1.7.43-1) recommends only the wine-development:i386 (1.7.41-1) package, but not the wine-development 1.7.43-1 (all) package. I assume this is more a problem of the repository, and will solve itself once 1.7.41-1 is removed. [1] I don't know if this will happen on its own or needs manual intervention. Nope, now that 1.7.41-1 is gone, wine-development recommended by wine32-development is Unavailable. See the new bug #787180 for the solution. Greets jre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782896: wine32 recommends of wine ignores already installed foreign arch version
Hi, [ wine-development is marked as multi-arch allowed since 1.7.41-2, which should have fixed this bug. ] But as of now an update to wine-development 1.7.43-1 tries to pull wine-development:i386 1.7.41-1. So I still end up with broken packages in aptitude. In aptitude wine32-development (1.7.43-1) recommends only the wine-development:i386 (1.7.41-1) package, but not the wine-development 1.7.43-1 (all) package. I assume this is more a problem of the repository, and will solve itself once 1.7.41-1 is removed. [1] I don't know if this will happen on its own or needs manual intervention. For now I don't reopen this bug. Greets jre [1] As of now it is still listed in the sid Release file next to 1.7.43-1, see e.g. ftp://ftp.debian.org/debian/dists/sid/main/binary-i386/Packages.gz $ apt-cache policy wine-development wine-development:i386 wine-development: Installed: 1.7.29-4 Candidate: 1.7.43-1 Version table: 1.7.43-1 0 100 http://httpredir.debian.org/debian/ sid/main amd64 Packages 1.7.41-1 0 100 http://httpredir.debian.org/debian/ sid/main amd64 Packages *** 1.7.29-4 0 100 /var/lib/dpkg/status wine-development:i386: Installed: (none) Candidate: 1.7.41-1 Version table: 1.7.41-1 0 100 http://httpredir.debian.org/debian/ sid/main i386 Packages -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785889: wine: Please update to GStreamer 1.x
control: forwarded -1 https://bugs.winehq.org/show_bug.cgi?id=31836 control: found -1 1.6.2-8 Hi upstream doesn't support that yet, see bug #31836. I assume Mike will go the same way as in wine-development (1.7.22-1) and build it --without-gstreamer for now. Greets jre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783831: isenkram-cli misses /usr/lib/tasksel/packages/for-current-hardware-firmware
Package: isenkram-cli Version: 0.18 Severity: normal Tags: patch Hi Choosing the Hardware specific firmware packages (autodetected by isenkram) task in tasksel fails with this output: ---snip--- Can't exec /usr/lib/tasksel/packages/for-current-hardware-firmware: No such file or directory at /usr/bin/tasksel line 261. Use of uninitialized value in split at /usr/bin/tasksel line 261. ---snap--- This missing file is in the isenkram source, but not packaged. Attached patch fixes this. Thx for all your work! Greets jre -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (900, 'testing'), (300, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-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 isenkram-cli depends on: ii debconf [debconf-2.0] 1.5.56 ii lsb-release4.1+Debian13+nmu1 ii python 2.7.9-1 isenkram-cli recommends no packages. isenkram-cli suggests no packages. -- no debconf information diff --git a/debian/isenkram-cli.install b/debian/isenkram-cli.install index 236ca9c..6c17cc4 100644 --- a/debian/isenkram-cli.install +++ b/debian/isenkram-cli.install @@ -2,6 +2,7 @@ isenkram-lookup usr/bin isenkram-autoinstall-firmware usr/sbin isenkram-pkginstall usr/sbin tasksel/packages/for-current-hardware usr/lib/tasksel/packages +tasksel/packages/for-current-hardware-firmware usr/lib/tasksel/packages tasksel/descs/isenkram.desc usr/share/tasksel/descs usr/lib/python* modaliases usr/share/isenkram
Bug#783154: libwine-development: cannot be installed - try to overwrite ...
Control: forcemerge 781557 -1 Hi, this was already reported, merging the bugs. It should be fixed in 1.7.41-2, which is currently in the new queue: https://ftp-master.debian.org/new/wine-development_1.7.41-2.html Greets jre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762058: closed by Michael Gilbert mgilb...@debian.org (Bug#779478: fixed in wine-development 1.7.41-1)
Control: unmerge 762058 Control: found 762058 Hi, this bug #762058 wine-development: Please enable WoW64 setup was closed because it was merged with #779478 64 Bit Program installation by the change * Don't install desktop files (closes: #779478). ... which is only a fix for #779478, but not for #762058. Unmerging and reopening #762058. Greets jre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782896: wine32 recommends of wine ignores already installed foreign arch version
Source: wine-development Version: 1.7.40-1 Severity: normal Hi I had the following packages installed from 1.7.40-1 (missing the 64-bit packages due to #781557:) ii libwine-development:i386 1.7.40-1 i386 ii wine-development 1.7.40-1 amd64 ii wine32-development 1.7.40-1 i386 When updating to 1.7.41-1, aptitude tries to pull wine-development (i386), which conflicts with the already installed wine-development (amd64). Obviously this was triggered by this change: * Recommend wine from the wine32 and wine64 packages (closes: #778435). The IMO correct way would be to keep the already installed wine-development (amd64). I did this for now manually. I haven't tested it yet, but I guess a Multi-Arch: allowed for the wine-development package would solve this correctly. Greets jre -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (900, 'testing'), (300, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-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 wine-development depends on: ii wine32-development 1.7.40-1 wine-development recommends no packages. Versions of packages wine-development suggests: ii binfmt-support 2.1.5-1 pn ttf-mscorefonts-installer none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782075: gnome-tweak-tool: Crashes Gnome when reducing Number of Workspaces
Control: found -1 3.14.4-1
Hi,
here's the screenlog/backtrace following
https://wiki.gnome.org/Projects/GnomeShell/Debugging after upgrading to
the new mutter version.
The log/backtrace shows the assertion failed in mutter when I reduced
the number of workspaces in Gnome Tweak Tool the first time.
I didn't do the second reduction, which would be necessary to actually
crash the Gnome session.
Greets
jre
. xenv.sh
bash: /proc//environ: No such file or directory
declare -x DEBEMAIL=jre.wine...@gmail.com
declare -x DEBFULLNAME=jre
declare -x HOME=/home/jens
declare -x HUSHLOGIN=FALSE
declare -x LANG=en_US.UTF-8
declare -x LANGUAGE=en_US:en
declare -x LOGNAME=jens
declare -x
LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.axv=01;35:*.anx=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.axa=00;36:*.oga=00;36:*.spx=00;36:*.xspf=00;36:
declare -x MAIL=/var/mail/jens
declare -x OLDPWD
declare -x PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
declare -x PWD=/home/jens
declare -x SHELL=/bin/bash
declare -x SHLVL=2
declare -x STY=7905.tty2.hope
declare -x TERM=screen.linux
declare -x TERMCAP=SC|screen.linux|VT 100/ANSI X3.64 virtual terminal:\\
:DO=\\E[%dB:LE=\\E[%dD:RI=\\E[%dC:UP=\\E[%dA:bs:bt=\\E[Z:\\
:cd=\\E[J:ce=\\E[K:cl=\\E[H\\E[J:cm=\\E[%i%d;%dH:ct=\\E[3g:\\
:do=^J:nd=\\E[C:pt:rc=\\E8:rs=\\Ec:sc=\\E7:st=\\EH:up=\\EM:\\
:le=^H:bl=^G:cr=^M:it#8:ho=\\E[H:nw=\\EE:ta=^I:is=\\E)0:\\
:li#56:co#200:am:xn:xv:LP:sr=\\EM:al=\\E[L:AL=\\E[%dL:\\
:cs=\\E[%i%d;%dr:dl=\\E[M:DL=\\E[%dM:dc=\\E[P:DC=\\E[%dP:\\
:im=\\E[4h:ei=\\E[4l:mi:IC=\\E[%d@:ks=\\E[?1h\\E=:\\
:ke=\\E[?1l\\E:vi=\\E[?25l:ve=\\E[34h\\E[?25h:vs=\\E[34l:\\
:ti=\\E[?1049h:te=\\E[?1049l:us=\\E[4m:ue=\\E[24m:so=\\E[3m:\\
:se=\\E[23m:mb=\\E[5m:md=\\E[1m:mh=\\E[2m:mr=\\E[7m:\\
:me=\\E[m:ms:\\
:Co#8:pa#64:AF=\\E[3%dm:AB=\\E[4%dm:op=\\E[39;49m:AX:\\
:vb=\\Eg:as=\\E(0:ae=\\E(B:\\
:ac=\\140\\140aaffggjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~..--++,,hhII00:\\
:Km=\\E[M:k0=\\E[10~:k1=\\EOP:k2=\\EOQ:k3=\\EOR:k4=\\EOS:\\
:k5=\\E[15~:k6=\\E[17~:k7=\\E[18~:k8=\\E[19~:k9=\\E[20~:\\
:k;=\\E[21~:F1=\\E[23~:F2=\\E[24~:F3=\\E[25~:F4=\\E[26~:\\
:F5=\\E[28~:F6=\\E[29~:F7=\\E[31~:F8=\\E[32~:F9=\\E[33~:\\
:FA=\\E[34~:kb=:K2=\\E[G:kB=\\E[Z:kh=\\E[1~:@1=\\E[1~:\\
:kH=\\E[4~:@7=\\E[4~:kN=\\E[6~:kP=\\E[5~:kI=\\E[2~:kD=\\E[3~:\\
:ku=\\EOA:kd=\\EOB:kr=\\EOC:kl=\\EOD:
declare -x USER=jens
declare -x WINDOW=0
declare -x WINEDEBUG=fixme+all,err+all
declare -x XDG_RUNTIME_DIR=/run/user/1000
declare -x XDG_SEAT=seat0
declare -x XDG_SESSION_ID=5
declare -x XDG_VTNR=2
bash: /proc//environ: No such file or directory
declare -x DEBEMAIL=jre.wine...@gmail.com
declare -x DEBFULLNAME=jre
declare -x HOME=/home/jens
declare -x HUSHLOGIN=FALSE
declare -x LANG=en_US.UTF-8
declare -x LANGUAGE=en_US:en
declare -x LOGNAME=jens
declare -x
LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35
Bug#782075: gnome-tweak-tool: Crashes Gnome when reducing Number of Workspaces
Control: tags -1 - moreinfo Hi, [ I removed the moreinfo tag for now, although I assume the info that I provide is not sufficient yet. Still, I guess this matches the correct workflow. ] On 04/10/2015 11:47 AM, Andreas Henriksson wrote: Thanks for your bug report, unfortunately it's not reproducible so you will have to provide more information or it will not be able to be investigated. Please provide session logs, a backtrace from the crashing process, etc. Thanks for your answer. Strange, I could reproduce it on a freshly installed Desktop PC and a laptop. The only common thing I can think of is the Intel graphics hardware and arch amd64. Uneducated and maybe biased guess ;) For now I only found and attached (parts of) /var/log/user.log: 18:01:09: I reduce the number of workspaces by one (Desktop reloads (?), but no crash yet). 18:01:47: I reduce it by another one -- crash. The crash seems to always happen after the 2nd reduction (increasing works fine). --- snip --- Apr 12 18:01:47 hope gnome-tweak-tool.desktop[1911]: (gnome-tweak-tool:1911): Gtk-WARNING **: Failed to set text from markup due to error parsing markup: Error on line 1 char 190: Element 'span' was closed, but the currently open element is 'alt' Apr 12 18:01:58 hope gnome-session[1257]: ** Apr 12 18:01:58 hope gnome-session[1257]: mutter:ERROR:core/screen.c:1250:update_num_workspaces: assertion failed: (w-windows == NULL) Apr 12 18:01:58 hope gnome-session[1257]: x-session-manager[1257]: WARNING: Application 'gnome-shell.desktop' killed by signal 6 Apr 12 18:01:58 hope gnome-session[1257]: x-session-manager[1257]: WARNING: App 'gnome-shell.desktop' respawning too quickly --- snap --- I'm a bit clueless which information to provide, e.g. which process to backtrace, etc.. I found no logs in ~/gnome*. Instructions or a reference to an instructional website are welcome. I'd be happy to provide more information, currently hanging out on #debian-gnome as jere21. Greets jre Apr 12 17:58:32 hope gnome-session[999]: Gjs-Message: JS LOG: Failed to launch ibus-daemon: Failed to execute child process ibus-daemon (No such file or directory) Apr 12 17:58:32 hope gdm-Xorg-:0[730]: The XKEYBOARD keymap compiler (xkbcomp) reports: Apr 12 17:58:32 hope gdm-Xorg-:0[730]: Warning: Type ONE_LEVEL has 1 levels, but RALT has 2 symbols Apr 12 17:58:32 hope gdm-Xorg-:0[730]:Ignoring extra symbols Apr 12 17:58:32 hope gdm-Xorg-:0[730]: Errors from xkbcomp are not fatal to the X server Apr 12 17:58:32 hope gnome-session[999]: (gnome-settings-daemon:1023): color-plugin-WARNING **: failed to get edid: unable to get EDID for output Apr 12 17:58:32 hope gnome-session[999]: (gnome-settings-daemon:1023): color-plugin-WARNING **: unable to get EDID for xrandr-LVDS1: unable to get EDID for output Apr 12 17:58:33 hope gnome-session[999]: Gjs-Message: JS LOG: GNOME Shell started at Sun Apr 12 2015 17:58:32 GMT+0200 (CEST) Apr 12 17:58:42 hope mtp-probe: checking bus 2, device 7: /sys/devices/pci:00/:00:1c.4/:03:00.0/usb2/2-2/2-2.3 Apr 12 17:58:42 hope mtp-probe: checking bus 2, device 8: /sys/devices/pci:00/:00:1c.4/:03:00.0/usb2/2-2/2-2.4 Apr 12 17:58:42 hope mtp-probe: bus: 2, device: 7 was not an MTP device Apr 12 17:58:42 hope mtp-probe: bus: 2, device: 8 was not an MTP device Apr 12 17:58:42 hope gdm-Xorg-:0[730]: (II) config/udev: Adding input device Logitech USB-PS/2 Optical Mouse (/dev/input/mouse1) Apr 12 17:58:42 hope gdm-Xorg-:0[730]: (II) No input driver specified, ignoring this device. Apr 12 17:58:42 hope gdm-Xorg-:0[730]: (II) This device may have been added with another device file. Apr 12 17:58:42 hope gdm-Xorg-:0[730]: (II) config/udev: Adding input device Logitech HID compliant keyboard (/dev/input/event13) Apr 12 17:58:42 hope gdm-Xorg-:0[730]: (**) Logitech HID compliant keyboard: Applying InputClass evdev keyboard catchall Apr 12 17:58:42 hope gdm-Xorg-:0[730]: (II) Using input driver 'evdev' for 'Logitech HID compliant keyboard' Apr 12 17:58:42 hope gdm-Xorg-:0[730]: (**) Logitech HID compliant keyboard: always reports core events Apr 12 17:58:42 hope gdm-Xorg-:0[730]: (**) evdev: Logitech HID compliant keyboard: Device: /dev/input/event13 Apr 12 17:58:42 hope gdm-Xorg-:0[730]: (--) evdev: Logitech HID compliant keyboard: Vendor 0x46d Product 0xc30e Apr 12 17:58:42 hope gdm-Xorg-:0[730]: (--) evdev: Logitech HID compliant keyboard: Found 20 mouse buttons Apr 12 17:58:42 hope gdm-Xorg-:0[730]: (--) evdev: Logitech HID compliant keyboard: Found keys Apr 12 17:58:42 hope gdm-Xorg-:0[730]: (II) evdev: Logitech HID compliant keyboard: Forcing relative x/y axes to exist. Apr 12 17:58:42 hope gdm-Xorg-:0[730]: (II) evdev: Logitech HID compliant keyboard: Configuring as mouse Apr 12 17:58:42 hope gdm-Xorg-:0[730]: (II) evdev: Logitech HID compliant keyboard: Configuring as keyboard Apr 12 17:58:42 hope gdm-Xorg-:0[730]: (**) evdev: Logitech HID compliant keyboard
Bug#782075: gnome-tweak-tool: Crashes Gnome when reducing Number of Workspaces
Control: found -1 3.14.2-1 Hi, thanks for the quick answer. On 04/12/2015 09:11 PM, Andreas Henriksson wrote: Control: reassign -1 mutter Hello! On Sun, Apr 12, 2015 at 08:02:39PM +0200, jre wrote: [...] Apr 12 18:01:58 hope gnome-session[1257]: mutter:ERROR:core/screen.c:1250:update_num_workspaces: assertion failed: (w-windows == NULL) [...] So it seems to be mutter crashing on an assertion failure, reassigning. More information on your exact way to attempt to reproduce could be useful. Exact number of workspaces, number of windows open and on which workspace they reside, etc I can reproduce the crash everytime, on both machines. One of those was a fresh installation. Setup: Fresh, new user. No changes at all. First login. The first thing after logging in is to reproduce the crash. So no other windows/workspace stuff or extensions. (But it also happens for my regular user, with some Gnome Tweak Tool- and probably dconf-changes, after working for some hours and having open windows. No difference, I always get the crash.) Reproduce: 1. Start Gnome Tweak Tool 2. In the Workspaces tab set Workspace Creation to static. 3. Click on the Minus next to Number of Workspaces, reducing it from 4 to 3. -- the Desktop wallpaper gets black for a short time, then everything is back to normal. 4. Click the Minus a second time, reducing it from 3 to 2 (without waiting for a longer time between both clicks.) -- The following screen appears: Oh no! Something has gone wrong. A problem has occured and the system can't recover. All extensions have been disabled as a precaution. Logout https://wiki.debian.org/HowToGetABacktrace If not even you can reproduce the problem I guess it will be hard to get anywhere. In case you manage to do it again, please try with the new mutter version that should be available in sid/unstable today/tomorrow. Thanks for the link, but that's just the basic stuff. E.g. I have no mutter process running. For now I've found https://wiki.gnome.org/Projects/GnomeShell/Debugging, hope that works. I will try tomorrow with the new mutter version. Greets jre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782075: gnome-tweak-tool: Crashes Gnome when reducing Number of Workspaces
Package: gnome-tweak-tool Version: 3.14.2-2 Severity: serious Justification: causes data loss Hi, reducing the Number of Workspaces (for Workspace Creation Static) in the Workspaces tab of Gnome Tweak Tool crashes the whole Gnome session: Oh no! Something has gone wrong. A problem has occured and the system can't recover. All extensions have been disabled as a precaution. Therefore all unsaved changes in any running application are lost and extensions have to be reenabled manually. I noticed this on a fresh (2015-04-05) Jessie installation with no extensions. I can reproduce it here on my daily-use-laptop Jessie installation. Thanks jre -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (900, 'testing'), (300, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-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 gnome-tweak-tool depends on: ii gir1.2-gnomedesktop-3.03.14.1-1 ii gir1.2-gtk-3.0 3.14.5-1 ii gir1.2-notify-0.7 0.7.6-2 ii gir1.2-soup-2.42.48.0-1 ii gnome-shell-common 3.14.2-3 ii gsettings-desktop-schemas 3.14.1-1 ii mutter-common 3.14.2-1 ii python 2.7.9-1 ii python-gi 3.14.0-1 gnome-tweak-tool recommends no packages. gnome-tweak-tool suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782084: gnome-session: All extensions are disabled if Gnome crashes
Package: gnome-session Version: 3.14.0-2 Severity: normal Hi, if the Gnome session crashes it disables all extensions: Oh no! Something has gone wrong. A problem has occured and the system can't recover. All extensions have been disabled as a precaution. I've been hit by this a few times. But it never was the fault of an extension and I always could reproduce the crash with all extensions disabled (bug #782075 (gnome-tweak-tool), IIRC bug #762809 (libgl1-mesa-dri) and some bug in pidgin which was solved in the meantime). So in 3 out of 3 times Gnome made the situation worse by this precaution. I'd prefer a dialog which offers and recommends to disable all extensions, but allows to manually select which extensions shall stay enabled. At least I'd like to see a list of extensions that actually were disabled. [Rant/Reasons why this reduces the benefit of the extensions system] It is quite annoying to have to re-enable all extensions manually, and to have to remember which extensions were enabled at all. By now I only have one extension installed. I started with about 5 extensions which were mainly nice-to-have. After using the system happily for about a year the Gnome session crashed. It took me some time to figure out which extension initially helped me to get back the blinking Pidgin icon (I chose Topicons out of 3 or 4 candidates, where the others give the notification only for a short time or in a manner that I didn't notice). I didn't go in reevaluating every other installed extension that time and for now will keep track of installed extensions manually. I also set up Debian for non-tech-savvy people. Due to the risk of loosing the extensions, I prefer not to use extensions there at all and instead show them other, more complicated but failproof methods for doing certain tasks. (Writing down a list of extensions and showing them how to enable them AND making them remember this, if Gnome crashes some time in the future is not realistic.) [/Rant] Should I report/discuss this upstream? If yes: where? Or has it already been discussed (again where? I haven't found anything)? Thanks and greets jre -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (900, 'testing'), (300, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-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 gnome-session depends on: ii gnome-session-bin 3.14.0-2 ii gnome-session-common 3.14.0-2 ii gnome-settings-daemon 3.14.2-3 ii gnome-shell3.14.2-3+b1 gnome-session recommends no packages. Versions of packages gnome-session suggests: ii desktop-base 8.0.2 ii gnome-keyring 3.14.0-1+b1 ii gnome-user-guide 3.14.1-1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781557: [pkg-wine-party] Bug#781557: libwine-development: upgrade failure: file overwrite
Control: found -1 1.7.38-1 Confirmed, I was also preparing to report this. IIRC I didn't have the problem when I rebuilt the packages 2 weeks ago locally in a cowbuilder Jessie environment, but unfortunately I can't verify this anymore. The packages I rebuilt just now are also broken. At least the following packages were updated, maybe one of them is causing this: [UPGRADE] apt:i386 1.0.9.6 - 1.0.9.7 [UPGRADE] binutils:i386 2.24.90.20141023-1 - 2.25-5 [UPGRADE] coreutils:i386 8.23-3 - 8.23-4 [UPGRADE] cpp:i386 4:4.9.1-5 - 4:4.9.2-2 [UPGRADE] cpp-4.9:i386 4.9.1-19 - 4.9.2-10 [UPGRADE] dmsetup:i386 2:1.02.90-2 - 2:1.02.90-2.1 [UPGRADE] dpkg:i386 1.17.23 - 1.17.24 [UPGRADE] dpkg-dev:i386 1.17.23 - 1.17.24 [UPGRADE] e2fslibs:i386 1.42.12-1 - 1.42.12-1.1 [UPGRADE] e2fsprogs:i386 1.42.12-1 - 1.42.12-1.1 [UPGRADE] g++:i386 4:4.9.1-5 - 4:4.9.2-2 [UPGRADE] g++-4.9:i386 4.9.1-19 - 4.9.2-10 [UPGRADE] gcc:i386 4:4.9.1-5 - 4:4.9.2-2 [UPGRADE] gcc-4.8-base:i386 4.8.3-13 - 4.8.4-1 [UPGRADE] gcc-4.9:i386 4.9.1-19 - 4.9.2-10 [UPGRADE] gcc-4.9-base:i386 4.9.1-19 - 4.9.2-10 [UPGRADE] gnupg:i386 1.4.18-6 - 1.4.18-7 [UPGRADE] gpgv:i386 1.4.18-6 - 1.4.18-7 [UPGRADE] libapt-pkg4.12:i386 1.0.9.6 - 1.0.9.7 [UPGRADE] libasan1:i386 4.9.1-19 - 4.9.2-10 [UPGRADE] libatomic1:i386 4.9.1-19 - 4.9.2-10 [UPGRADE] libc-bin:i386 2.19-13 - 2.19-15 [UPGRADE] libc-dev-bin:i386 2.19-13 - 2.19-15 [UPGRADE] libc6:i386 2.19-13 - 2.19-15 [UPGRADE] libc6-dev:i386 2.19-13 - 2.19-15 [UPGRADE] libcap2:i386 1:2.24-6 - 1:2.24-7 [UPGRADE] libcap2-bin:i386 1:2.24-6 - 1:2.24-7 [UPGRADE] libcilkrts5:i386 4.9.1-19 - 4.9.2-10 [UPGRADE] libcomerr2:i386 1.42.12-1 - 1.42.12-1.1 [UPGRADE] libdb5.3:i386 5.3.28-7~deb8u1 - 5.3.28-9 [UPGRADE] libdevmapper1.02.1:i386 2:1.02.90-2 - 2:1.02.90-2.1 [UPGRADE] libdpkg-perl:i386 1.17.23 - 1.17.24 [UPGRADE] libgcc-4.9-dev:i386 4.9.1-19 - 4.9.2-10 [UPGRADE] libgcc1:i386 1:4.9.1-19 - 1:4.9.2-10 [UPGRADE] libgomp1:i386 4.9.1-19 - 4.9.2-10 [UPGRADE] libitm1:i386 4.9.1-19 - 4.9.2-10 [UPGRADE] libprocps3:i386 2:3.3.9-8 - 2:3.3.9-9 [UPGRADE] libquadmath0:i386 4.9.1-19 - 4.9.2-10 [UPGRADE] libss2:i386 1.42.12-1 - 1.42.12-1.1 [UPGRADE] libstdc++-4.9-dev:i386 4.9.1-19 - 4.9.2-10 [UPGRADE] libstdc++6:i386 4.9.1-19 - 4.9.2-10 [UPGRADE] libsystemd0:i386 215-11 - 215-12 [UPGRADE] libubsan0:i386 4.9.1-19 - 4.9.2-10 [UPGRADE] libudev1:i386 215-11 - 215-12 [UPGRADE] linux-libc-dev:i386 3.16.7-ckt4-3 - 3.16.7-ckt7-1 [UPGRADE] multiarch-support:i386 2.19-13 - 2.19-15 [UPGRADE] patch:i386 2.7.1-6 - 2.7.5-1 [UPGRADE] perl:i386 5.20.1-5 - 5.20.2-2 [UPGRADE] perl-base:i386 5.20.1-5 - 5.20.2-2 [UPGRADE] perl-modules:i386 5.20.1-5 - 5.20.2-2 [UPGRADE] procps:i386 2:3.3.9-8 - 2:3.3.9-9 [UPGRADE] systemd:i386 215-11 - 215-12 [UPGRADE] systemd-sysv:i386 215-11 - 215-12 [UPGRADE] udev:i386 215-11 - 215-12 [INSTALL] ccache:i386 btw, I'v seen different files conflicting, e.g.: Official 1.7.38 packages: /usr/share/wine-development/wine/fonts/smae1257.fon Just locally rebuilt 1.7.38-1 packages: /usr/share/wine-development/wine/fonts/smallee.fon Greets jre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#772440: Bug #772440: linux-image-3.16.0-4-amd64: Built-in display dimmed black if external monitor is plugged in
Control: found -1 3.16.7-ckt4-3 Hi My patch has been accepted and subsequently merged to: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/ master 3120d03cf64d7f9fd71231827af2c1550aa4caa7 Author: Jens Reyer jens.reyer@*** Date: Tue Feb 17 19:07:29 2015 +0100 ACPI / video: Disable native backlight on Samsung Series 9 laptops So Linux v4.0rc1 fixes this issue (not in the repository yet). The 3.16-stable maintainer Luis Henriques already merged all other recent similar patches to linux-3.16.y-queue. I assume above patch for my laptop model will also be part of the next release v3.16.7-ckt8. Jessie is currently at v3.16.7-ckt4 and if I read the svn repo correctly is preparing to move to -ckt7. If -ckt8 doesn't make it to the release I'd propose to cherry-pick above commit and those for other models (sha1 master / linux-3.16.y-queue): commit 7d0b93499f4879ddbc75d594f4ea216ba964f78e commit 10a81b56dead63cc5e730f7473c310e82cbc3b80 ACPI / video: Add some Samsung models to disable_native_backlight list commit 6a3ef10bacb08860805e9053f919786dc34760ba commit 9e572334c95f6a0a8864f733279dc25656285948 ACPI / video: Add disable_native_backlight quirk for Dell XPS15 L521X commit 3295d73002f4be341069a000aec4b8d7e5ea8d2c commit 8e65f32e85bfab9fde3b6e796e0656a69076aa3c ACPI / video: Add disable_native_backlight quirk for Samsung 730U3E/740U3E commit e77a16355a29230b99bafe55834a8252e55308ec commit b005b7a25958209235a34006e9bcefaf40aad7ce ACPI / video: Add disable_native_backlight quirk for Samsung 510R The necessary disable_native_backlight quirk was already added in v3.16.2. Greets jre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#772440: Bug #772440: linux-image-3.16.0-4-amd64: Built-in display dimmed if black if external monitor is plugged in
CCing debia...@lists.debian.org and especially Maximillan Attems who prepared xserver-xorg-video-intel 2:2.99.911-git20140529-1~exp1 which added the backlight helper. Summary of what happened so far: intel_backlight, which is default since Linux 3.16, does not work correctly on several laptops. They have been blacklisted in the kernel in order to use the working ACPI backlight again. #772440 is about just another laptop model to be added to this blacklist. Luca Boccassi found that the new backlight helper script in xserver-xorg-video-intel also fixes the issue. On 02/20/2015 12:29 AM, Luca Boccassi wrote: Cross-post from freedesktop bug, just to make sure it doesn't go unnoticed: (In reply to Luca Boccassi from comment #13) Hello, I have a Dell Latitude E5540, running an Intel Haswell i7-4600U with GPU HD Graphics 4400, and I have the same problem. But I noticed that upgrading the Intel driver to a version that ships a new backlight helper binary fixes the problem. In my case, I am running Debian Jessie. The driver is part of the package xserver-xorg-video-intel and the version that ships the new backlight helper, according to the changelog, is: xserver-xorg-video-intel (2:2.99.911+git20140529-1~exp1) experimental; urgency=low * New upstream prerelease. (closes: #748753) * Install new backlight helper. Confirmed, in git://anonscm.debian.org/pkg-xorg/driver/xserver-xorg-video-intel I found the new backlight helper script to be the relevant commit. Also see the ongoing discussion in https://bugs.freedesktop.org/show_bug.cgi?id=87286. IMO the disable_native_backlight for some laptop models is (part of) the correct solution and it is not clear /why/ the new backlight helper script helps. Should we clone this bug as a more general one and then reassign to xserver-xorg-video-intel? We could then try to backport the changes to jessie to also help other affected laptops which are not yet blacklisted. That would be the following commits + probably some follow-up fixes. At least the 3rd commit requires manual merging: commit 631b4e4c78a807e61214026bf9a1461aadbd59b5 Author: maximilian attems maks@*** Date: Thu May 29 17:07:16 2014 +0200 install add new helper commit b71f3d8bd4d6773899c1bdc903911cf240e68ead Author: Jan Alexander Steffens (heftig) jan.steffens@*** Date: Sat Feb 15 17:53:16 2014 +0100 Backlight helper build fixes commit 3d629c91cfa98b75c6685c2a2003e64fd1b612c4 Author: Chris Wilson chris@*** Date: Sat Feb 15 14:55:09 2014 + intel: Add a helper for setting backlight without root rights I just fear it is too late for that in jessie. Greets jre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#779002: [pkg-wine-party] Bug#779002: marked as done (wine32 sound does not work on amd64 arch)
Package: wine
Version: 1.6.2-19
Control: reopen -1
Control: tags -1 patch
Hi
On 02/23/2015 03:21 AM, Michael Gilbert mgilb...@debian.org wrote:
On Sun, Feb 22, 2015 at 5:57 PM, Joshua wrote:
Sound does not play correctly (or at all) with 32 bit wine on a 64 bit
system. This is
well-known to be the case as verified by google search; however not yet
listed in bug
reports.
Cause: libopaus0 is not multiarch compatible.
Workaround: bypass pulseaudio (not always effective)
Additional information:
http://tanguy.ortolo.eu/blog/article116/wine-sound-testing
That hasn't been true for almost two years now. You can now install
libasound2-plugins:i386, and everything will just work.
But the jessie wine packages don't depend on libasound2-plugins.
Attached patch fixes this by inserting a recommends for wine 32|64
(like in wine-development).
Greets
jre
diff --git a/debian/control.in b/debian/control.in
index e465184..b7e2f39 100644
--- a/debian/control.in
+++ b/debian/control.in
@@ -116,6 +116,8 @@ Depends:
libfreetype6,
libgl1-mesa-dri,
libwine-gecko-2.21
+Recommends:
+ libasound2-plugins,
Breaks:
wine ( 1.6.1-9),
wine-bin ( 1.5.31-1),
@@ -142,6 +144,7 @@ Breaks:
Replaces:
wine ( 1.6.1-9),
Recommends:
+ libasound2-plugins,
wine32 (= ${source:Version}),
Description: Windows API implementation - 64-bit binary loader
Wine is a free MS-Windows API implementation.
Bug#777467: libwine-development: does not support libxml2
Package: libwine-development Version: 1.7.35-2 Severity: normal Hi libwine-development 1.7.35-2 from experimental does not depend on libxml2. All other versions seem to be ok though. When I rebuild it locally with gbp the dependency is there again. Looking at debian/control.in and the last changes I wouldn't expect otherwise, everything looks ok. So no idea if it is something with the build daemons or Stephen's specific upload. This causes e.g. EA's Origin installer to crash, while it works with my rebuilt version: $ wine-development OriginSetup.exe [...] This program tried to use a DOMDocument object, but libxml2 support was not present at compile time. [...] err:msvcrt:MSVCRT__invalid_parameter (null):0 (null): (null) 0 wine: Unhandled exception 0xc417 in thread 14 at address 0x7b83a0ac (thread 0014), starting debugger... Greets jre -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (900, 'testing'), (300, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.18.0-trunk-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) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#777467: [pkg-wine-party] Bug#777467: libwine-development: does not support libxml2
Hi Stephen On Sun, 8 Feb 2015 21:27:57 +0100 Stephen Kitt sk...@debian.org wrote: Hi, On Sun, 08 Feb 2015 16:05:47 +0100, jre jre.wine...@gmail.com wrote: libwine-development 1.7.35-2 from experimental does not depend on libxml2. All other versions seem to be ok though. When I rebuild it locally with gbp the dependency is there again. Looking at debian/control.in and the last changes I wouldn't expect otherwise, everything looks ok. So no idea if it is something with the build daemons or Stephen's specific upload. Thanks for pointing this out. debian/control doesn't declare a build-dependency on libxml2-dev, so it isn't installed on the buildds; and my upload forced a rebuild on the buildds for all arches (I don't upload binaries any more). No, libxml2-dev already was in debian/control.in. That's what I meant with everything looks ok. I'm preparing a fix, the upload should be ready in a little while... You now just duplicated that entry as I've seen in git. I'm a bit clueless about this bug: First I thought you had a somehow corrupted debian/control (since this is not checked in in git). But I just did a apt-get source wine-development: In 1.7.35-2 (yes, your new -3 is not yet available) both files debian/control and debian/control.in ship with a build-depends of the source package on libxml2-dev. Then I did a dpkg-buildpackage -us -uc in the just retrieved source: $ dpkg -e ../libwine-development_1.7.35-2_amd64.deb $ grep xml2 DEBIAN/control Depends: [...] libxml2 (= 2.9.0), [...] Then I uninstalled libxml2-dev and some other dependencies: $ dpkg-buildpackage -us -uc dpkg-buildpackage: source package wine-development dpkg-buildpackage: source version 1.7.35-2 dpkg-buildpackage: source distribution experimental dpkg-buildpackage: source changed by Stephen Kitt sk...@debian.org dpkg-buildpackage: host architecture amd64 dpkg-source --before-build wine-development-1.7.35 dpkg-checkbuilddeps: Unmet build dependencies: libxml2-dev libxslt1-dev dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting dpkg-buildpackage: warning: (Use -d flag to override.) So if I rebuild from your shipped source everything works as it should (builddep is in d/control, aborts if builddep is missing, and the built packages have the dependency). I run Jessie, amd64, with some sid stuff. As I understand the Debian working I used *exactly* the same source as the build daemons. Since you do source-only uploads, as I just learned, we can also rule out anything strange on your side. I'm not doing a Control: found: -1 1.7.35-3 yet, because it's not available yet. But if it is fixed in there then it can only be by coincidence. Any idea? Greets jre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776784: winecfg won't run
Hi, this is a bug in wine's wine-wrapper script. It's already fixed in the wine-development packages, but I assume it won't be fixed for jessie's wine. You can workaround it by explicitly calling wine, i.e. wine winecfg. Once you have installed an app in wine and thus a system.reg is created, winecfg will work just as expected, Greets jre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775439: winetricks: vcrun2013 not installable (sha1sum mismatch)
Package: winetricks
Version: 0.0+20141009+svn1208-1
Severity: normal
Tags: patch, jessie, upstream, fixed-upstream
Control: forwarded -1 https://code.google.com/p/winetricks/issues/detail?id=466
Hi,
winetricks fails to install the Visual C++ 2013 libraries (vcrun2013).
This happens because MS released a new version on 2014-12-30 (see
http://www.microsoft.com/en-us/download/details.aspx?id=40784). So
winetricks fails to verify the correct sha1sum of the downloaded package.
Fixed upstream by simply replacing the sha1sum, see
https://code.google.com/p/winetricks/issues/detail?id=466. I attached the
commit.
Since imho vcrun2013 is a quite central package to be installed by
winetricks, I propose to set the severity to serious (as maintainer you
are entitled to to so, as user I am not) and fix this in jessie (which
obviously requires an unblock request).
Otherwise as hint for affected users, simply get the current winetricks
and make it executable:
wget http://winetricks.org/winetricks
chmod +x winetricks
Then execute it from the same directory:
./winetricks
Greets
jre
-- System Information:
Debian Release: 8.0
APT prefers testing
APT policy: (900, 'testing'), (300, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.7-ckt2+ (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 winetricks depends on:
ii cabextract1.4-5
ii p7zip 9.20.1~dfsg.1-4.1
ii unzip 6.0-14
ii wget 1.16-1
ii wine 1.6.2-18
ii wine-development 1.7.33-1
ii wine321.6.2-18
ii wine641.6.2-18
ii zip 3.0-8
Versions of packages winetricks recommends:
ii gksu 2.0.2-9
ii sudo 1.8.10p3-1
ii xdg-utils 1.1.0~rc1+git20111210-7.1
ii zenity 3.14.0-1
Versions of packages winetricks suggests:
ii libwine 1.6.2-18
-- no debconf information
commit 0d551c0cf409b1d1f6d6f3a096b0f159c6a4bba4
Author: Austin English austinengl...@gmail.com
Date: Wed Jan 14 16:00:35 2015 -0600
vcrun2013: update sha1sum
diff --git a/src/winetricks b/src/winetricks
index 603ec74..89a58bb 100755
--- a/src/winetricks
+++ b/src/winetricks
@@ -7355,7 +7355,9 @@ w_metadata vcrun2013 dlls \
load_vcrun2013()
{
# http://www.microsoft.com/en-us/download/details.aspx?id=40784
-w_download
http://download.microsoft.com/download/2/E/6/2E61CFA4-993B-4DD4-91DA-3737CD5CD6E3/vcredist_x86.exe
18f81495bc5e6b293c69c28b0ac088a96debbab2
+# 2014/07/26: 18f81495bc5e6b293c69c28b0ac088a96debbab2
+# 2015/01/14: df7f0a73bfa077e483e51bfb97f5e2eceedfb6a3
+w_download
http://download.microsoft.com/download/2/E/6/2E61CFA4-993B-4DD4-91DA-3737CD5CD6E3/vcredist_x86.exe
df7f0a73bfa077e483e51bfb97f5e2eceedfb6a3
w_override_dlls native,builtin atl120 msvcp120 msvcr120 vcomp120
cd $W_CACHE/vcrun2013
Bug#767048: wine: support wine64 on kfreebsd-amd64
FYI, these bugs have just been closed in wine 1.7.34: https://bugs.winehq.org/show_bug.cgi?id=33940 (winmm/mci tests hang on PC-BSD) https://bugs.winehq.org/show_bug.cgi?id=34330 (Wine64 does not work on FreeBSD) So maybe it's a good time to fully build wine on kfreebsd-amd64 again. Greets jre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#772440: Bug #772440: linux-image-3.16.0-4-amd64: Built-in display dimmed black if external monitor is plugged in
control: forwarded -1 https://bugs.freedesktop.org/show_bug.cgi?id=87286
control: tags -1 patch
control: tags -1 jessie
I filed a bug for the backlight control issue on freedesktop.org.
There are 2 possible solutions:
1.) Disable native backlight and return to use acpi, as it was in 3.14.
2.) Fix intel_backlight
I don't know which one the upstream solution will be, but I guess for
Jessie native backlight should just be disabled (which fixes both the
inital brightness level and the control issue). See attached patch.
The same is already done for other product classes in 3.16.7-ckt2-1. And
looking at the bugreports at freedesktop even more will be added to
disable native backlight in the next time.
So probably just wait for now to see if the patch gets applied and
backported upstream.
Greets
jre
commit ea05c0cd09531bc9834cd176f17d9b7da24cae5f
Author: jre-winesim jre.wine...@gmail.com
Date: Mon Dec 15 14:17:13 2014 +0100
disable native backlight
diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index f1e3496..24d7444 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -694,6 +694,15 @@ static struct dmi_system_id video_dmi_table[] __initdata = {
DMI_MATCH(DMI_PRODUCT_NAME, HP ENVY 15 Notebook PC),
},
},
+ {
+ /* https://bugs.freedesktop.org/show_bug.cgi?id=87286 */
+ .callback = video_disable_native_backlight,
+ .ident = SAMSUNG 900X3C/900X3D/900X3E/900X4C/900X4D,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, SAMSUNG ELECTRONICS CO., LTD.),
+ DMI_MATCH(DMI_PRODUCT_NAME, 900X3C/900X3D/900X3E/900X4C/900X4D),
+ },
+ },
{}
};
Bug#766028: wine32 segfault
Hi On 12/08/2014 11:05 PM, Uwe Storbeck wrote: When I understand the package version numbers in Debian correctly the wine32 package versions 1.6.2-10 and 1.6.2-11 are produced from the same upstream sources. So the bug has been introduced in the Debian part of the wine32 package between version 1.6.2-10 and version 1.6.2-11. That should considerably narrow things down. Between these versions debian/rules (a Makefile) was changed: some refactoring how LDFLAGS is set. Previously LDFLAGS was only set as part of CONFLAGS, afterwards it is first set separately and then this is used in CONFLAGS, Can this be the reason? Otherwise it might be some change in the build environment. At a quick glance I saw these uploaded to unstable: 16 Oct 2014: wine 1.6.2-11 13 Oct 2014: mesa 10.3.1-1 13 Oct 2014: wine 1.6.2-10 10 Oct 2014: linux 3.16.5-1 Greets jre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#772440: linux-image-3.16.0-4-amd64: Built-in display dimmed black if external monitor is plugged in
I found that the kernel option video.use_native_backlight=0 fixes these issues. Brightness is always at a reasonable level and adjustable again. (In fact unfortunately it can't be dimmed to black anymore, which on the upside avoids unreasonable defaults.) Tested for Linux 3.16 and 3.17. $ ls /sys/class/backlight/ acpi_video0 intel_backlight So what to do now to get this fixed both for Jessie (at least document it in some general way) and in the long run (I guess file upstream report for the adjust issue)? Greets jre btw: I was hinted to this workaround by the similar, but not identical bug reports https://bugs.debian.org/762285 and https://bugzilla.kernel.org/show_bug.cgi?id=85051. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#772440: linux-image-3.16.0-4-amd64: Built-in display dimmed black if external monitor is plugged in
Package: src:linux Version: 3.16.7-2 Severity: normal Control: notfound -1 3.14.15-2 Control: found -13.16.3-2 Control: found -13.16.5-1 Hi, most times my laptop screen (LVDS1) is completely dimmed (= black) after boot at the GDM login prompt, if the external monitor (HDMI1) is or gets plugged in. Trying to increase the brightness (Fn+F3) shows the brightness OSD on HDMI1, but the bar only moves up to about max. 5% (= which is still a black screen). Thus the GDM login prompt (which is placed on LVDS1) is not visible, while HDMI1 works but has no content to display. Switching to tty1 and back fixes the brightness level (= normal LVDS1 with visible login prompt). But it still can't be regulated below about 95% then. After login in Gnome brightness can be regulated again. With linux 3.14 brightness is up and regulatable. With linux 3.17 (3.17.4-1~exp1) it is up, but not regulatable. It may have happened less often with earlier 3.16 versions. Without an external monitor brightness is up and regulatable on the internal display. It happens indepently if I enable or disable the built-in display in Gnome before rebooting. (Normally I have turned it off. In the past it was also turned off then at the login prompt. But I guess this is an unrelated Gnome issue which just made me realize this at all.) Due to bug #762809 in libgl1-mesa-dri I have enabled SNA for my Intel graphics HD4000. But returning to the default does not help here. There are error messages shown on tty before login. But I get them always, independently if the screen is dark or not, and also with linux 3.17. So I don't know if this is related. (And a web search shows there is much noise around them.): ~ kernel: [2.352424] [drm:cpt_set_fifo_underrun_reporting] *ERROR* uncleared pch fifo underrun on pch transcoder A kernel: [2.352425] [drm:cpt_serr_int_handler] *ERROR* PCH transcoder A FIFO underrun ~ Should I file a bug about not being able to regulate the brightness level upstream and/or clone the bug here? Any more information? If I should bisect: against old good 3.14.15 or 3.14.17? Any tips beyond https://wiki.debian.org/DebianKernel/GitBisect? May I restrict the bisect to a certain dir/path? Thanks in advance and for all your work jre -- Package-specific info: ** Version: Linux version 3.16.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.3 (Debian 4.8.3-13) ) #1 SMP Debian 3.16.7-2 (2014-11-06) ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.16.0-4-amd64 root=UUID=6703b530-7dd3-4ce0-8986-05b1af26806d ro quiet ** Not tainted ** Kernel log: [2.288866] usb 3-2: Product: 4-Port USB 3.0 Hub [2.288868] usb 3-2: Manufacturer: VIA Labs, Inc. [2.292140] hub 3-2:1.0: USB hub found [2.343978] hub 3-2:1.0: 4 ports detected [2.436579] usb 1-1.5: new full-speed USB device number 3 using ehci-pci [2.457558] psmouse serio1: elantech: assuming hardware version 4 (with firmware version 0x361f00) [2.473082] psmouse serio1: elantech: Synaptics capabilities query result 0x41, 0x15, 0x0f. [2.533452] usb 1-1.5: New USB device found, idVendor=8087, idProduct=07da [2.533457] usb 1-1.5: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [2.550045] Bluetooth: Core ver 2.19 [2.550069] NET: Registered protocol family 31 [2.550070] Bluetooth: HCI device and connection manager initialized [2.550079] Bluetooth: HCI socket layer initialized [2.550082] Bluetooth: L2CAP socket layer initialized [2.550097] Bluetooth: SCO socket layer initialized [2.556570] input: ETPS/2 Elantech Touchpad as /devices/platform/i8042/serio1/input/input6 [2.558149] usbcore: registered new interface driver btusb [2.604542] usb 1-1.6: new high-speed USB device number 4 using ehci-pci [2.659933] Console: switching to colour frame buffer device 200x56 [2.667755] i915 :00:02.0: fb0: inteldrmfb frame buffer device [2.667757] i915 :00:02.0: registered panic notifier [2.684108] random: nonblocking pool is initialized [2.689485] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no) [2.689631] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input10 [2.689713] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0 [2.689994] ACPI Warning: SystemIO range 0xefa0-0xefbf conflicts with OpRegion 0xefa0-0xefaf (\_SB_.PCI0.SBUS.SMBI) (20140424/utaddress-258) [2.69] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver [2.707941] RPC: Registered named UNIX socket transport module. [2.707941] RPC: Registered udp transport module. [2.707941] RPC: Registered tcp transport module. [2.707942] RPC: Registered tcp NFSv4.1 backchannel transport module. [2.710448] FS-Cache: Loaded [2.717183] FS-Cache: Netfs 'nfs' registered for caching [2.723645] Installing knfsd (copyright
Bug#772062: pbuilder: Detecting MIRRORSITE from /etc/apt/sources.list.d/* during installation is incomplete
Package: pbuilder
Version: 0.215
Severity: normal
Tags: patch
Dear pbuilder maintainers and authors
To detect the default MIRRORSITE during installation, pbuilder also uses
files in /etc/apt/sources.list.d/.
Issue 1: *.sources.list instead of *.list
--
pbuilder requires them to end in *.sources.list. But sources.list(5)
nowadays states File names need to end with .list [...].
So pbuilder is to restrictive in selecting valid files here.
(Yes, the shorter suffix works with apt, I am using it.)
Issue 2: Only one file supported
With multiple files in /etc/apt/sources.list.d/ I get:
Preconfiguring packages ...
/tmp/pbuilder.config.r1aFEU: 63: [:
/etc/apt/sources.list.d/debian.experimental.sources.list: unexpected
operator
Selecting previously unselected package pbuilder.
and debconf says:
Configuring pbuilder.
Default mirror not found
Mirror information detection failed and the user provided no mirror
information.
Please enter valid mirror information.
Please find attached a patch which fixes both issues.
I successfully tested it with:
- empty /etc/apt/sources.list.d/
- multiple *.list files in /etc/apt/sources.list.d/
Thanks for pbuilder and all your work!
jre
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (900, 'testing'), (300, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16-2-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
Versions of packages pbuilder depends on:
ii coreutils 8.23-3
ii debconf [debconf-2.0] 1.5.54
ii debianutils4.4+b1
ii debootstrap1.0.64
ii dpkg-dev 1.17.21
ii wget 1.16-1
Versions of packages pbuilder recommends:
ii devscripts 2.14.10
ii fakeroot1.20.2-1
ii sudo1.8.10p3-1
Versions of packages pbuilder suggests:
ii cowdancer 0.73
ii gdebi-core0.9.5.5+nmu1
pn pbuilder-uml none
-- debconf information:
pbuilder/mirrorsite: http://http.debian.net/debian/
pbuilder/nomirror:
pbuilder/rewrite: false
diff --git a/debian/pbuilder.config b/debian/pbuilder.config
index e07db08..61c2391 100755
--- a/debian/pbuilder.config
+++ b/debian/pbuilder.config
@@ -60,7 +60,9 @@ EOF
SRCLISTDIR=/etc/apt/sources.list.d
MIRRORSITE=$(
( [ -f /etc/apt/sources.list ] cat /etc/apt/sources.list || true ;
- [ -f $SRCLISTDIR/*.sources.list ] cat $SRCLISTDIR/*.sources.list || true ) \
+ for FILE in $(ls $SRCLISTDIR/*.list 2/dev/null); do
+ [ ! -f $FILE ] || cat $FILE;
+ done || true ) \
| grep -E '^deb[[:space:]]+(ftp|http):' | head -n 1 | awk '{print $2;}'
)
while [ -z $MIRRORSITE ] ; do
Bug#769473: wine: Proposing patch and merging 771104/769473
control: tag -1 patch
control: forcemerge 771104 769473
That should be the same bugs. See attached the patch, doing it the same
way like wine-development.
Greets
jre
diff --git a/debian/control.in b/debian/control.in
index c444684..9d5149d 100644
--- a/debian/control.in
+++ b/debian/control.in
@@ -111,6 +111,8 @@ Depends:
${misc:Depends},
${shlibs:Depends},
x11-utils,
+ libfreetype6,
+ libncurses5,
libwine-gecko-2.21
Breaks:
wine ( 1.6.1-9),
Bug#770483: Texture corruption when changing graphic options
Source: wine-development Version: 1.7.29-1 Severity: important Tags: upstream Control: found -1 1.7.29-3 Control: forwarded -1 https://bugs.winehq.org/show_bug.cgi?id=37406 Hi, so wine-development 1.7.29 will be in jessie. In that version was a regression, wine bug #37406 (Texture corruption when changing graphic options (Eve Online, Sims 3, Diablo 3). I'd propose to backport the fix from wine 1.7.30 to wine-development in jessie. The bug was introduced upstream in wine 1.7.29: commit ee8a5b7dd1e554ef32229c766715f23ba17c9f6c Author: Henri Verbeet hverb...@codeweavers.com Date: Wed Oct 8 08:47:20 2014 +0200 wined3d: Track texture allocation per-texture. ... and fixed in wine 1.7.30: aad1997dff990ceeba90ece0d535c7826044a5cf Author: Stefan Dösinger ste...@codeweavers.com Date: 2014-10-22 21:56:38 wined3d: Remove texture locations after downloading all subresources. Attached you'll find this fix as a quilt patch. I built and tested it successfully on my system. btw: jessie still has the broken 1.7.29-2. Greets jre -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (900, 'testing'), (300, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-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 Versions of packages wine-development depends on: ii wine32-development 1.7.29-3+texture ii wine64-development 1.7.29-3+texture wine-development recommends no packages. Versions of packages wine-development suggests: ii binfmt-support 2.1.5-1 ii ttf-mscorefonts-installer 3.6 -- no debconf information diff --git a/debian/patches/series b/debian/patches/series index fd8a6c8..c3fecbd 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -14,3 +14,4 @@ addons-path.patch glu32-link.patch debian-gnutls.patch +texture.patch diff --git a/debian/patches/texture.patch b/debian/patches/texture.patch new file mode 100644 index 000..f1ab2f9 --- /dev/null +++ b/debian/patches/texture.patch @@ -0,0 +1,33 @@ +Description: wined3d: Remove texture locations after downloading all subresources. +Author: Stefan Dösinger ste...@codeweavers.com + +--- a/dlls/wined3d/surface.c b/dlls/wined3d/surface.c +@@ -1207,7 +1207,6 @@ + surface_load_location(surface, surface-resource.map_binding); + surface_invalidate_location(surface, ~surface-resource.map_binding); + } +-wined3d_texture_force_reload(surface-container); + + context = context_acquire(device, NULL); + gl_info = context-gl_info; +--- a/dlls/wined3d/texture.c b/dlls/wined3d/texture.c +@@ -979,6 +979,7 @@ + sub_resource-resource_ops-resource_unload(sub_resource); + } + ++wined3d_texture_force_reload(texture); + wined3d_texture_unload_gl_texture(texture); + } + +--- a/dlls/wined3d/volume.c b/dlls/wined3d/volume.c +@@ -451,7 +451,6 @@ + } + + /* The texture name is managed by the container. */ +-wined3d_texture_force_reload(volume-container); + volume-flags = ~WINED3D_VFLAG_CLIENT_STORAGE; + + resource_unload(resource);
Bug#769791: wine32 doesn't work after fresh install
control: tags -1 patch Hi, [my answer/patch is based upon the mentioned #739863, otherwise we really need more info from Andi:] 1.) this happens in wine-wrapper (regedit, regsvr32, wineboot, winecfg, winefile, winepath), but not in wine/wine32/wine64. So wineboot fails with: cat: /home/jens/.wine/system.reg: No such file or directory /usr/bin/wineboot: 32: exec: wineboot.exe: not found while wine wineboot or wine32 wineboot work. Instead of wineboot a normal windows exe also works fine here. 2.) ... and only if $WINEPREFIX/system.reg is missing. IF WINEARCH is not specified, then $WINEPREFIX/system.reg is used to figure out which wine to use (wine32 or wine64). After a fresh install obviously system.reg With attached patch (taken from #739863) wine-wrapper falls back to using /usr/bin/wine if system.reg is missing. This will then again choose wine32, unless WINELOADER is specified. Of course this is only a fix. In the long run (= wine(-development) post Jessie) I'd suggest to move all 32/64-bit logic to wine(-development). So add the system.reg test there, next to the existing WINEARCH and WINELOADER tests and probably add a PE32+ check (for 64-bit binfmt support, #769234.) Or should I post a patch for this now? Mike, the git repository is out of date: branch jessie is at release 1.6.2-15 (while 1.6.2-16 is current) Greets jre diff --git a/debian/scripts/wine-wrapper b/debian/scripts/wine-wrapper index 95d2c8f..5c9a3f4 100644 --- a/debian/scripts/wine-wrapper +++ b/debian/scripts/wine-wrapper @@ -24,7 +24,11 @@ appname=`basename $0 .exe`.exe if test -z $WINEARCH; then test ! -z $WINEPREFIX || WINEPREFIX=$HOME/.wine -wine=$(cat $WINEPREFIX/system.reg | grep ^\#arch= | cut -d= -f2 | sed s/win/wine/) +if test -f $WINEPREFIX/system.reg; then +wine=$(cat $WINEPREFIX/system.reg | grep ^\#arch= | cut -d= -f2 | sed s/win/wine/) +else +wine=/usr/bin/wine +fi else wine=$(echo $WINEARCH | sed s/win/wine/) fi
Bug#767048: wine on kfreebsd-amd64 lacks essential files
control: reopen -1 control: found -1 1.6.2-14 control: retitle -1 wine on kfreebsd-amd64 lacks essential files I'm not sure about the correct version, something between wine 1.6.1-6 (readded support for kfreebsd-amd64) and current. No idea if it ever worked: http://wiki.winehq.org/Wine64ForPackagers states Wine 64bit works at the moment only on Linux. But I think I've already seen reports about it working. Currently in debian/rules if DEB_BUILD_ARCH is kfreebsd-amd64: - dh_auto_configure does not do much - dh_install: does nothing This results in missing nearly all files. Package wine:freebsd-amd64 compared to amd64 lacks: --- /usr/bin/wine /usr/bin/wine-wrapper /usr/share/doc/wine/README.winedbg/README.gz all manpages Package wine64:freebsd-amd64 compared to amd64 lacks: - /usr/bin/wine64 /usr/lib/x86_64-linux-gnu/wine/bin/wine /usr/share/doc/wine64/copyright /usr/share/lintian/overrides/wine64 /usr/share/man/man1/wine64.1.gz /usr/share/wine/gecko/wine_gecko-2.21-x86_64.msi Package libwine does not exist at all on freebsd-amd64 -- Greets jre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#767048: [pkg-wine-party] Bug#767048: wine on kfreebsd-amd64 lacks essential files
Package libwine does not exist at all on freebsd-amd64 -- In fact this is the case for some packages with architecture amd64 (but not any-amd64): wine64-tools libwine-dev libwine libwine-dbg (missing also on amd64) Greets jre PS: Sorry, no matter how long I take to write a mail, it seems I'll always forget soemthing. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#767048: [pkg-wine-party] Bug#767048: closed by Michael Gilbert mgilb...@debian.org (Re: [pkg-wine -party] Bug#767048: wine doesnt run at all)
On 11/07/2014 08:47 PM, kfree...@i2pmail.org wrote: On 2014-11-02 02:18 UTC 767...@bugs.debian.org wrote: You'll need to add kfreebsd-i386 as a dpkg subarchitecture, then install the wine32 package for things to work. Best wishes, Mike I did that mike Im not an idiot ,its broken FIX IT, typing wine normally tells you to add the arch , it tells you nothing, even after adding it, as I did before you replayed, its still broken, I'd like to propose to call nobody an idiot here and stay lower-case. Makes much more fun then. I'm a bit at a loss between: wine doesn't run at all (although you got at least the hint to use kfreebsd-i386), no mention of wine32 being installed in your first mail (should be done automatically, at least if it is installed, and your report where you only cited the wrapper script and broken symlinks (btw. that paragraph took me quite some time until I figured what was citation and what was yours). The output of dpkg -l *wine* might help to show what is installed actually (post with the description removed for easier reading). Thus having said, the problem might be that both wine and the target of the symlinks (wine-wrapper) are only in the i386 packages (yet, this means if you were told to add the arch by wine, then wine-wrapper should have been installed already, thus no broken links). See: https://packages.debian.org/jessie/kfreebsd-amd64/wine/filelist https://packages.debian.org/jessie/kfreebsd-i386/wine/filelist So replacing wine:kfreebsd-amd64 with wine:kfreebsd-i386 might do the trick. Please report back. Greets jre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#767938: [pkg-wine-party] Bug#767938: wine: cannot find LC:\\windows\\system32\\=.exe
On 11/03/2014 03:47 PM, Bill Allombert wrote: Package: wine Version: 1.6.2-14 Severity: normal Hello Debian Wine Party, since the last update, each time I call wine, it prints wine: cannot find LC:\\windows\\system32\\=.exe I guess that's another symptom of https://bugs.debian.org/767437. Please try 1.6.2-16. Greets -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#767938: [pkg-wine-party] Bug#767938: Bug#767938: wine: cannot find LC:\\windows\\system32\\=.exe
control: forcemerge 767437 767938 On 11/03/2014 05:05 PM, Bill Allombert wrote: On Mon, Nov 03, 2014 at 03:55:28PM +0100, jre wrote: On 11/03/2014 03:47 PM, Bill Allombert wrote: Package: wine Version: 1.6.2-14 Severity: normal Hello Debian Wine Party, since the last update, each time I call wine, it prints wine: cannot find LC:\\windows\\system32\\=.exe I guess that's another symptom of https://bugs.debian.org/767437. Please try 1.6.2-16. Ah thanks, I missed this one. Indeed 1.6.2-16 fix this issue. Forcemerging and closing, as my assumption was right. Mike, I hope it is ok when I do this in the bts. Greets jre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#767751: wine32-tools: fails to upgrade, breaks wine32-dev-tools needed
Package: wine
Version: 1.6.2-15
Severity: serious
Tags: patch
Justification: Policy 7.6.1
Hi
just refer to (767626: wine64-tools: fails to upgrade from 'testing' -
trying to overwrite /usr/lib/x86_64-linux-gnu/wine/bin/winegcc).
The same should apply to the 32-bit packages, too.
Greets
jre
diff --git a/debian/control.in b/debian/control.in
index 95bed41..c444684 100644
--- a/debian/control.in
+++ b/debian/control.in
@@ -168,6 +168,7 @@ Depends:
libwine-dev (= ${binary:Version}),
Breaks:
libwine-dev ( 1.5.31-1),
+ wine32-dev-tools ( 1.6.2-9),
Replaces:
libwine-dev ( 1.5.31-1),
wine32-dev-tools ( 1.6.2-9),
Bug#764641: [pkg-wine-party] Bug#764641: I cant use wine64 and wine32 with the same .wine folder yet
control: found -1 1.6.2-13 control: found -1 1.6.2-14 control: notfound -1 1.6.2-15 Hi The code to fix this was broken (767437 wine: wine script broken, missing test) and fixed in 1.6.2-15. On 11/01/2014 12:37 AM, Kimy Hardy wrote: Hi, I cant use wine64 and wine32 with the same .wine folder yet, i have installed the wine 1.6.2-14, but if i have winearch 64 i cant run i386 apps on it. The fix applied here in #764641 assigns different wine prefixes $HOME/.wine and $HOME/.wine64 depending on WINEARCH. To use the /same/ wine prefix for 32-bit and 64 bit you need WoW64. See my feature request bug #762058 (wine-development: Please enable WoW64 setup). Greets jre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763178: bugs.debian.org: Confusing use of pending for status and tag, was: Bug#763178: reportbug: erroneously shows status pending for other bugs
control: reassign -1 bugs.debian.org control: severity -1 minor control: retitle -1 control: reopen -1 Dear bugs.debian.org maintainers, On 10/29/2014 02:02 PM, Sandro Tosi wrote: On Sun, Sep 28, 2014 at 1:49 PM, jre jre.wine...@gmail.com wrote: I filed a bug against wine-development with reportbug. This shows me the list of current bugs against wine-development. Every bug in this list has either the status done or pending. The latter is wrong or at least confusing since it can be misunderstood as tagged pending, which none of those actually is. (Some of them are tagged patch, and others are completely untagged and have only the submitters mail). So I don't know what the reason is to show these bugs as pending. Maybe they should just be shown as open unless they get tagged pending. there is a bit of misunderstanding here, mixing up tags and statuses. when a bug is in status 'pending' it means it still misses a resolution (it is pending a resolution), while when a bug is tagged 'pending' it means a fix has been found and it's soon to be released. This information are returned from the BTS to reportbug, which just shows them, so if you want clarification, i think you'd better contact ow...@bugs.debian.org (the owner of the BTS). I think the use of Status: pending is confusing given the widespread use of Tag: pending. To avoid this I'd suggest to use Status: open instead. I don't know the inner workings of the bts, I just stumbled upon this when using reportbug and was pointed here then. I assume the use of Outstanding bugs ... on the websites https://bugs.debian.org/cgi-bin/pkgreport.cgi?package=... and https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=... is also based on Status: pending. This unambiguous presentation is exactly what I'd hope to see in reportbug, too. So personally I don't know where the best place is to fix this. Of course, changing internal stuff of b.d.o might break other stuff. Thanks everybody for your work, much appreciated jre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#767011: Patch for wine-development: WINELOADER from script is not passed
control: tag -1 patch control: clone -1 -2 control: retitle -1 wine-development: wine script broken, missing test control: severity -1 important control: reassign -2 src:wine control: retitle -2 wine: wine script broken, missing test Hi, turns out it was a missing test when testing the value of $wine, see attached patch. Affected are both wine and wine-development (I hope I got the bug control stuff right). As already mentioned the consequences for wine-development with wine co-installed are quite severe: wine-development just doesn't work. But I don't really understand why it works as soon as only wine-development is installed. I'd think it should end in the broken test, when it executes $wine instead of testing its value. No idea what the concrete symptoms for wine (stable) are, but I'd say wine (stable) also needs to be fixed for Jessie. Greets jre diff --git a/debian/scripts/wine b/debian/scripts/wine index d67a00a..5972abb 100755 --- a/debian/scripts/wine +++ b/debian/scripts/wine @@ -21,7 +21,7 @@ else fi if test -z $WINEPREFIX; then -if $wine = $wine64; then +if test $wine = $wine64; then wineprefix=$HOME/.wine64 else wineprefix=$HOME/.wine
Bug#767011: wine-development: WINELOADER from script is not passed (strange)
Source: wine-development Version: 1.7.29-2 Severity: normal tl;dr: For a strange reason WINELOADER is not passed correctly. This makes wine-development fail, when wine (stable) is also installed, Hi, I've installed both wine and wine-development from unstable. Using wine-development fails: ~ $ wine-development notepad wine: cannot find LC:\\windows\\system32\\=.exe wine: cannot find LC:\\windows\\system32\\=.exe wine client error:0: version mismatch 447/457. 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? ~ At first this looks like a WINESERVER issue, but it is not. E.g. this does NOT help: ~ export WINESERVER=/usr/lib/i386-linux-gnu/wine-development/wineserver ~ I also rebooted my computer to rule out e.g. a still running wineserver. But as soon as I uninstall the wine (stable) packages it works again. Now I found that the following works: ~ export WINELOADER=/usr/lib/wine-development/wine wine-development notepad ~ ... or this works, too: ~ WINELOADER=/usr/lib/wine-development/wine wine-development notepad ~ But /usr/bin/wine-development already is supposed to do that! I added the following DEBUG lines there to test: 1.) if the test if WINELOADER was set manually is working 2.) the command-line (last line of the script) is constructed correctly ~ if test -z $WINELOADER; then echo DEBUG: WINELOADER is empty. wineloader=$wine else echo DEBUG: WINELOADER is not empty. wineloader=$WINELOADER fi [...] echo DEBUG: WINEPREFIX=$wineprefix WINELOADER=$wineloader WINEDEBUG=$winedebug $wine $@ WINEPREFIX=$wineprefix WINELOADER=$wineloader WINEDEBUG=$winedebug $wine $@ ~ The result is just fine: ~ $ wine-development notepad wine: cannot find LC:\\windows\\system32\\=.exe wine: cannot find LC:\\windows\\system32\\=.exe DEBUG: WINELOADER is empty. DEBUG: WINEPREFIX=/home/jens/.wine WINELOADER=/usr/lib/wine-development/wine WINEDEBUG=fixme+all,err+all /usr/lib/wine-development/wine notepad wine client error:0: version mismatch 447/457. 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? ~ Failed attempt to fix the script: ~ export WINEPREFIX=$wineprefix export WINELOADER=$wineloader export WINEDEBUG=$winedebug $wine $@ ~ Another failed attempt to fix the script: ~ eval WINEPREFIX=$wineprefix WINELOADER=$wineloader WINEDEBUG=$winedebug $wine $@ ~ IIRC this worked a few weeks ago. So I'm really clueless now. Setting WINELOADER in the terminal works, while doing the same stuff in the script does not work. Is my system just borked? Does it work for you? -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (900, 'testing'), (300, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-3-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 Versions of packages wine-development depends on: ii wine32-development 1.7.29-2 ii wine64-development 1.7.29-2 wine-development recommends no packages. Versions of packages wine-development suggests: ii binfmt-support 2.1.5-1 ii ttf-mscorefonts-installer 3.6 -- no debconf information $ dpkg -l *wine*|grep ii|sed s|Windows.*||g ii libwine:amd641.6.2-14 amd64 ii libwine:i386 1.6.2-14 i386 ii libwine-development:amd641.7.29-2 amd64 ii libwine-development:i386 1.7.29-2 i386 ii libwine-gecko-2.21 2.21+dfsg2-1 all ii libwine-gecko-2.24 2.24+dfsg-1 all ii wine 1.6.2-14 amd64 ii wine-development 1.7.29-2 amd64 ii wine32 1.6.2-14 i386 ii wine32-development 1.7.29-2 i386 ii wine64 1.6.2-14 amd64 ii wine64-development 1.7.29-2 amd64 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#767011: wine-development: WINELOADER from script is not passed (strange)
Regarding Jessie and the upcoming freeze: Although I really hope that this can be fixed for Jessie, I propose to wait for 1.7.29-2 to enter testing before uploading a new version 1.7.29-3 (perhaps by raising bug severity to important then). Remember that this bug only shows its symptoms if both wine and wine-development are installed. And of course 1.7.30 mustn't be uploaded to unstable before Jessie is released. Thus having said, since I don't understand the reason for this bug, I'm not sure at all if it really is a bug in wine-development, or somewhere else. I will do some tests later. Feedback welcome! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#767011: wine-development: WINELOADER from script is not passed (strange)
control: notfound -1 1.7.27-1 control: found -1 1.7.28-1 control: found -1 1.7.28-2 control: found -1 1.7.28-3 It seems to be /some/ change made in 1.7.28-1. It still works in 1.7.27-1, but fails in 1.7.28-3. 1.7.28-2 just fixed an FTBFS due to an incorrect manpage path and 1.7.28-3 just added a missing fi (I verified that in the git repository). So although these two don't work at all, I think it is safe to assume that they already contained the bug. Further information: 1.) Immediately after a failed attempt the wine (stable) wineserver is running (/usr/lib/i386-linux-gnu/wine/bin/wineserver). 2.) This package combination works: $ dpkg -l *wine*|grep ii|sed s|Windows.*||g|sort ii libwine-development:amd641.7.27-1 amd64 ii libwine-development:i386 1.7.27-1 i386 ii libwine-gecko-2.21 2.21+dfsg2-1 all ii libwine-gecko-2.24 2.24+dfsg-1 all ii libwine:i386 1.6.2-14 i386 ii wine 1.6.2-14 amd64 ii wine32 1.6.2-14 i386 ii wine32-development 1.7.27-1 i386 ii wine64-development 1.7.27-1 amd64 ii wine-development 1.7.27-1 amd64 3.) The line wrapping in my first mail was unfortunate. E.g. this should have been one line: ~ WINELOADER=/usr/lib/wine-development/wine WINEDEBUG=fixme+all,err+all /usr/lib/wine-development/wine notepad ~ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766030: Patch for #766030 wine: error: unable to find wine executable. this shouldn't happen.
control: tag -1 patch Attached the minimal patch to fix the paths. wine 1.6.2 uses the old packaging with old paths, where /usr/bin/wine32 and /usr/bin/wine64 point to the arch-specific paths. The merge of the wine-development script, where the wine and wine64 binaries are placed in /usr/lib/wine-development/, missed adapting these paths. btw: Jessie/Testing still has 1.6.2-8. So if we want all changes since then to enter Jessie (including the non-release-critical changes) /someone/ should upload a fixed version until *October 26th which is in 3 days* (or even earlier since it has to be accepted, ...). See https://release.debian.org/jessie/freeze_policy.html. Greets jre diff --git a/debian/scripts/wine b/debian/scripts/wine index d67a00a..aa3307f 100755 --- a/debian/scripts/wine +++ b/debian/scripts/wine @@ -1,9 +1,9 @@ #!/bin/sh -e name=$(basename $0) -bindir=/usr/lib/$name +bindir=/usr/bin -wine32=$bindir/wine +wine32=$bindir/wine32 wine64=$bindir/wine64 if test -x $wine32 -a $WINEARCH != win64; then
Bug#764212: [pkg-wine-party] Bug#764212: [wine-development] Error in bash script, fi needed at line 28
severity 764212 grave found 764212 1.7.28-1 thanks Raising severity because with this bug the package is not fit for testing. Of course unstable users may happily install it and use it after fixing. On 10/09/2014 10:46 AM, Konstantin Demin wrote: Please review attached patch. Most parts of your patch aren't related to this bug but simply use another style (replacing spaces with tabs; using bash builtins [ ] instead of test (I would prefer that too); omitting (bad idea)). As already noted previously the patch for this bug is really just adding the missing fi (haven't tested it, but it seems obvious). Please search the web how to submit correct patches. Basically you should keep them minimal and adapt to the current style of the file that you want to patch. If you want other things changed in wine file another bug with your patch and describe what you did there for what purpose. Greets jre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763178: reportbug: erroneously shows status pending for other bugs
Package: reportbug Version: 6.5.1 Severity: normal Hi, I filed a bug against wine-development with reportbug. This shows me the list of current bugs against wine-development. Every bug in this list has either the status done or pending. The latter is wrong or at least confusing since it can be misunderstood as tagged pending, which none of those actually is. (Some of them are tagged patch, and others are completely untagged and have only the submitters mail). So I don't know what the reason is to show these bugs as pending. Maybe they should just be shown as open unless they get tagged pending. Thanks jre -- Package-specific info: ** Environment settings: INTERFACE=gtk2 ** /home/jens/.reportbugrc: reportbug_version 6.5.0 mode advanced ui gtk2 realname jre email jre.wine...@gmail.com smtphost smtp.gmail.com smtpuser jre.winesim smtptls -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (900, 'testing'), (300, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-2-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 Versions of packages reportbug depends on: ii apt 1.0.9.1 ii python2.7.8-1 ii python-reportbug 6.5.1 pn python:anynone reportbug recommends no packages. Versions of packages reportbug suggests: pn claws-mail none pn debconf-utils none ii debsums2.0.52+nmu2 pn dlocatenone pn emacs22-bin-common | emacs23-bin-commonnone ii exim4 4.84-2 ii exim4-daemon-light [mail-transport-agent] 4.84-2 ii file 1:5.19-2 ii gnupg 1.4.18-4 ii python-gtk22.24.0-4 ii python-gtkspell2.25.3-13 pn python-urwid none ii python-vte 1:0.28.2-5 ii xdg-utils 1.1.0~rc1+git20111210-7.1 Versions of packages python-reportbug depends on: ii apt 1.0.9.1 ii python-debian 0.1.23 ii python-debianbts 1.12 pn python:anynone python-reportbug suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742561: wine script - wine64 support
Followup-For: Bug #742561 Package: wine-development Version: 1.7.27-1 Hi, attached is a new patch to fix the wine64 support. I changed my approach to only use wine64 if WINEARCH is set. - Wine script: - Use wine64 if WINEARCH is win64, show help message and exit if wine64 is not installed. - Show help message and exit, if called without WINEARCH, but only wine64 is installed. - If WINEARCH is set, add it to the call of the wine executable. - Add wine64 wrapper script to call wine script with WINEARCH set to win64. - Patch winemenubuilder to set WINEARCH. My patch for winemenubuilder only works if WINEARCH was set. Otherwise it results in WINEARCH=(null). Possible solutions might be: - Change the patch to only add a WINEARCH entry if WINEARCH was set. - Only apply the patch on amd64. With my proposed solution WINEARCH is always set when using wine64 (except if you call the executable directly) - so this would work. NOTE: Just passing an empty WINEARCH to the wine executable (if WINEARCH was not set) does not work, Greets jre diff --git a/debian/patches/winemenubuilder.patch b/debian/patches/winemenubuilder.patch index 3b2d8f3..d43a36c 100644 --- a/debian/patches/winemenubuilder.patch +++ b/debian/patches/winemenubuilder.patch @@ -3,21 +3,24 @@ author: Michael Gilbert mgilb...@debian.org --- a/programs/winemenubuilder/winemenubuilder.c +++ b/programs/winemenubuilder/winemenubuilder.c -@@ -1455,7 +1455,7 @@ static BOOL write_desktop_entry(const ch +@@ -1455,8 +1455,8 @@ fprintf(file, [Desktop Entry]\n); fprintf(file, Name=%s\n, linkname); -fprintf(file, Exec=env WINEPREFIX=\%s\ wine %s %s\n, -+fprintf(file, Exec=env WINEPREFIX=\%s\ wine-development %s %s\n, - wine_get_config_dir(), path, args); +-wine_get_config_dir(), path, args); ++fprintf(file, Exec=env WINEPREFIX=\%s\ WINEARCH=\%s\ wine-development %s %s\n, ++wine_get_config_dir(), getenv( WINEARCH ), path, args); fprintf(file, Type=Application\n); fprintf(file, StartupNotify=true\n); -@@ -2529,7 +2529,7 @@ static BOOL write_freedesktop_associatio + if (descr lstrlenA(descr)) +@@ -2529,7 +2529,8 @@ fprintf(desktop, Type=Application\n); fprintf(desktop, Name=%s\n, friendlyAppName); fprintf(desktop, MimeType=%s;\n, mimeType); -fprintf(desktop, Exec=env WINEPREFIX=\%s\ wine start /ProgIDOpen %s %%f\n, wine_get_config_dir(), progId); -+fprintf(desktop, Exec=env WINEPREFIX=\%s\ wine-development start /ProgIDOpen %s %%f\n, wine_get_config_dir(), progId); ++fprintf(desktop, Exec=env WINEPREFIX=\%s\ WINEARCH=\%s\ wine-development start /ProgIDOpen %s %%f\n, ++wine_get_config_dir(), getenv( WINEARCH ), progId); fprintf(desktop, NoDisplay=true\n); fprintf(desktop, StartupNotify=true\n); if (openWithIcon) diff --git a/debian/rules b/debian/rules index 11961f0..c5b2d1d 100755 --- a/debian/rules +++ b/debian/rules @@ -72,6 +72,7 @@ override_dh_auto_configure: override_dh_install: $(INSTALLS) mkdir -p debian/tmp cp debian/scripts/wine debian/tmp/wine$(VERSION) + cp debian/scripts/wine64 debian/tmp/wine64$(VERSION) sed 's|LIBDIR|$(LIBDIR)|g' debian/scripts/winegcc debian/tmp/winegcc$(DEB_BUILD_ARCH_BITS)$(VERSION) cp tools/winedump/README debian/tmp/README.winedump cp programs/winedbg/README debian/tmp/README.winedbg diff --git a/debian/scripts/wine b/debian/scripts/wine index 7609c69..d579234 100755 --- a/debian/scripts/wine +++ b/debian/scripts/wine @@ -6,20 +6,43 @@ bindir=/usr/lib/$name wine32=$bindir/wine wine64=$bindir/wine64 -if test -x $wine32; then +if test $WINEARCH = win64 ; then +if test -x $wine64; then +wine=$wine64 +else +echo error: WINEARCH is win64, but unable to find wine64 executable. +if [ $(dpkg --print-architecture) = amd64 ]; then +echo as root, please execute \apt-get install $(echo $name | sed s/wine/wine64/)\ +else +echo you need $(echo $name | sed s/wine/wine64/). but this is only available on architecture amd64. +fi +exit 1 +fi +elif test -x $wine32; then wine=$wine32 elif test -x $wine64; then wine=$wine64 +echo error: unable to find wine executable. if [ $(dpkg --print-architecture) = amd64 -a $(dpkg --print-foreign-architectures) != i386 ]; then echo it looks like multiarch needs to be enabled. as root, please echo execute \dpkg --add-architecture i386 apt-get update -echo apt-get install $(echo $name | sed s/wine/wine32/)\ +else +echo -n as root, please execute \ fi +echo apt-get install $(echo $name | sed s/wine/wine32/)\ +echo if you want to use wine64 set WINEARCH to win64, or use \$(echo $name | sed s/wine/wine64/)\. +exit 1 else echo error: unable to find wine executable. this shouldn't happen. exit 1 fi +if test -z $WINEARCH
Bug#742561: Status of these bugs
Hi, the bugs #742561 and #762058 are marked as pending in reportbug, however I see no trace of this in their bug logs. Is this some bug in bugs.d.o? Besides this technical state I'm really curious what the real state of these bugs is. Greets jre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763131: wine-development: wine64 depends on wine32 being installed
Source: wine-development
Version: 1.7.27-1
Severity: normal
Hi,
wine64 seems not to work if the 32-bit packages aren't installed.
I had only the 64-bit packages installed:
ii libwine-development:amd641.7.27-1 amd64
ii wine-development 1.7.27-1 amd64
ii wine64-development 1.7.27-1 amd64
... and executed the following line (wrapped for readability here, it
was one line):
WINEARCH=win64 \
WINELOADER=/usr/lib/wine-development/wine64 \
WINEDEBUG=fixme+all,err+all \
/usr/lib/wine-development/wine64 ImageMagick-6.8.9-7-Q16-x64-static.exe
This immediately exits (returns 1), but just gives this output:
wine: created the configuration directory '/home/jens/.wine'
Could not load wine-gecko. HTML rendering will be disabled.
wine: configuration in '/home/jens/.wine' has been updated.
After installing libwine-development:i386 and wine32-development:i386
above command worked flawlessly if I removed ~/.wine.
If I didn't remove ~/.wine the installation also worked (I could start
imdisplay.exe later), but showed some popups about ole errors [1] and
failed to open the webpage (in the Linux system webbroser).
Useless stuff I tried:
I tried adding env before the command line and exported some variables:
export W=/usr/lib/x86_64-linux-gnu/wine-development/
export WINEVERPATH=$W
export PATH=$W:/usr/lib/wine-development/:$PATH
export WINESERVER=$W/wineserver
export WINELOADER=/usr/lib/wine-development/wine64
export WINEDLLPATH=$W/fakedlls
export LD_LIBRARY_PATH=$W
[1] Errors when installing in a broken prefix:
err:ole:CoGetClassObject class {00021401---c000-0046}
not registered
err:ole:create_server class {00021401---c000-0046} not
registered
err:ole:CoGetClassObject no class object
{00021401---c000-0046} could be created for context 0x5
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (900, 'testing'), (300, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.14-2-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
Versions of packages wine-development depends on:
ii wine64-development 1.7.27-1
wine-development recommends no packages.
Versions of packages wine-development suggests:
ii binfmt-support 2.1.5-1
ii ttf-mscorefonts-installer 3.5
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763131: [pkg-wine-party] Bug#763131: wine-development: wine64 depends on wine32 being installed
On 09/28/2014 05:07 AM, Austin English wrote: On Sep 28, 2014 9:30 AM, jre jre.wine...@gmail.com mailto:jre.wine...@gmail.com wrote: Source: wine-development Version: 1.7.27-1 Severity: normal Hi, wine64 seems not to work if the 32-bit packages aren't installed. I had only the 64-bit packages installed: ii libwine-development:amd641.7.27-1 amd64 ii wine-development 1.7.27-1 amd64 ii wine64-development 1.7.27-1 amd64 ... and executed the following line (wrapped for readability here, it was one line): WINEARCH=win64 \ WINELOADER=/usr/lib/wine-development/wine64 \ WINEDEBUG=fixme+all,err+all \ /usr/lib/wine-development/wine64 ImageMagick-6.8.9-7-Q16-x64-static.exe This immediately exits (returns 1), but just gives this output: wine: created the configuration directory '/home/jens/.wine' Could not load wine-gecko. HTML rendering will be disabled. wine: configuration in '/home/jens/.wine' has been updated. After installing libwine-development:i386 and wine32-development:i386 above command worked flawlessly if I removed ~/.wine. That's expected, many 64bit programs also contain 32bit components. You might try a built-in executable instead, e.g. notepad should work. But wine64 alone is not an upstream supported configuration. Thanks! Then wine-development should depend (without alternative) on wine32-development and perhaps recommend wine64-development. Greets jre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762596: winetricks: Wrong git clone URL in README.Debian
Package: winetricks Version: 0.0+20140818+svn1202-1 Severity: minor Tags: patch Hi, The git clone URL for the dummy wine package in /usr/share/doc/winetricks/README.Debian doesn't work: ~ git clone g...@github.com:jaalto/project--debian-wine-dummy.git Cloning into 'project--debian-wine-dummy'... Warning: Permanently added the RSA host key for IP address '192.30.252.131' to the list of known hosts. Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. ~ Instead this works: git clone https://github.com/jaalto/project--debian-wine-dummy.git Greets and thanks jre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758996: Fix winetricks for wine-development
Package: winetricks
Version: 0.0+20140818+svn1202-1
Followup-For: Bug #758996
I extended the patch to set WINE correctly if wineserver is from wine-
development, committed also upstream.
I moved the wineserver check towards the end of the list to avoid
setting a new
WINE unnecessarily (in case several wineserver are installed).
Further I first check if the new WINE is executable before setting it new.
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (900, 'testing'), (300, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.14-2-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
Versions of packages winetricks depends on:
ii cabextract1.4-4
ii p7zip 9.20.1~dfsg.1-4.1
ii unzip 6.0-12
ii wget 1.15-1+b1
ii wine-development 1.7.26-2
ii zip 3.0-8
Versions of packages winetricks recommends:
ii gksu 2.0.2-6
ii sudo 1.8.10p3-1
ii xdg-utils 1.1.0~rc1+git20111210-7.1
ii zenity 3.12.1-1.1
Versions of packages winetricks suggests:
pn libwine none
-- no debconf information
diff --git a/debian/patches/10-option-gui.patch b/debian/patches/10-option-gui.patch
index 4f7f570..a1a2f69 100644
--- a/debian/patches/10-option-gui.patch
+++ b/debian/patches/10-option-gui.patch
@@ -7,7 +7,7 @@ Subject: Start GUI only when --gui option is used. Handle empty args.
--- a/src/winetricks
+++ b/src/winetricks
-@@ -17897,6 +17897,14 @@
+@@ -18548,6 +18548,14 @@
shift
fi
@@ -22,7 +22,7 @@ Subject: Start GUI only when --gui option is used. Handle empty args.
case $1 in
die) w_die we who are about to die salute you. ;;
volnameof=*)
-@@ -17910,7 +17918,7 @@
+@@ -18561,7 +18569,7 @@
# This will read the volname from the given image and put it to stdout.
winetricks_volname ${1#volnameof=}
;;
diff --git a/debian/patches/20-wine-development.patch b/debian/patches/20-wine-development.patch
new file mode 100644
index 000..1c1cffc
--- /dev/null
+++ b/debian/patches/20-wine-development.patch
@@ -0,0 +1,38 @@
+From: Jens Reyer jre.wine...@gmail.com
+Subject: Check for wineserver from Debian package wine-development and set
+ WINE accordingly.
+
+
+--- a/src/winetricks
b/src/winetricks
+@@ -3720,6 +3720,7 @@
+ WINE=${WINE:-wine}
+ # Find wineserver. Some distros (Debian) don't have it on the path,
+ # on the mistaken understanding that user scripts never need it :-(
++# If wineserver is from wine-development set WINE to wine-development.
+ # FIXME: get packagers to put wineserver on the path.
+ for x in \
+ $WINESERVER \
+@@ -3735,10 +3736,22 @@
+ /usr/lib/*/wine/wineserver \
+ /usr/lib/*/wine/bin/wineserver \
+ `dirname $WINE`/server/wineserver \
++/usr/lib/i386-kfreebsd-gnu/wine-development/wineserver \
++/usr/lib/i386-linux-gnu/wine-development/wineserver \
++/usr/lib/powerpc-linux-gnu/wine-development/wineserver \
++/usr/lib/x86_64-linux-gnu/wine-development/wineserver \
+ file-not-found
+ do
+ if test -x $x
+ then
++case $x in
++ /usr/lib/*/wine-development/wineserver)
++if test -x /usr/bin/wine-development
++then
++WINE=/usr/bin/wine-development
++fi
++;;
++esac
+ break
+ fi
+ done
diff --git a/debian/patches/series b/debian/patches/series
index 9099ad2..7d51a9e 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
10-option-gui.patch
+20-wine-development.patch
Bug#758996: Fix winetricks for wine-development
On 09/23/2014 10:34 PM, Joseph Bisch wrote: I think it might actually be better to direct the user to set the WINE and WINESERVER variable before running winetricks. That way if both wine and wine-development are installed, the user can choose which to use. It looks like your patch prioritizes the wine wineserver and prioritizes the wine-development wine binary, which might lead to issues if wine and wine-development are both installed. No, I (hope to have) took care of that: wineserver from wine-development is the last in the list that is tried. If another wineserver is found, WINE stays untouched. Only if no other wineserver is found, the wine-development wineserver is taken and paired with WINE=/usr/bin/wine-development. So if you have wine stable installed, its wine and wineserver are taken. Regardless if you have co-installed wine-development or not. So the only problem is, if you have both wine (stable) and wine-development installed AND are using wine-development (then wine and wineserver from stable would be taken). In this case indeed setting WINE and WINESERVER would be better. But I think forcing everyone to set those variables just to have a clean solution for this special case would do more harm than good. So asking the user for WINE and WINESERVER should only happen if both wine and wine-development are installed (or even better the running processes could be checked to figure out which wineserver is currently running). But seriously, I think it is enough to just document this fact and just fix the currently non-working situation (better do the good thing, instead of trying the perfect thing without implementing it). Greets jre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758996: wine and wine-development
btw, the package wine32-development (or any other from the -development set) does not provide wine in PATH. which wine will never work here. Everything in PATH from the -development packages is suffixed with -development. This is not related to amd64 or i386, just to wine (stable) or wine-development. In #758291 I provided a patch for /usr/bin/wine to just be an alternative link to wine-development or wine-stable. But I don't know when/if this will be applied. Just saying this now so that you don't choose a solution which wouldn't work with this. Regardless of all above mentioned wineserver is never in PATH. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742561: Yet another patch for the wine script - wine64 support
Followup-For: Bug #742561 Package: wine-development Version: 1.7.26-2 Hi, based on Floris' patches here another patch: Try wine64 if - a 64-bit executable is given as argument (NOTE: there are 64-bit applications with 32-bit installers, so this won't help everytime), or - if the WINEPREFIX is a 64-bit (NOTE: don't do this once WoW64 is implemented, see http://wiki.winehq.org/Wine64ForPackagers.), or - if WINEARCH is set to win64. In all other cases use wine (32-bit). Add error message if wine64 is requested but not found. Greets jre diff --git a/debian/scripts/wine b/debian/scripts/wine index 388f3ae..67d0db9 100755 --- a/debian/scripts/wine +++ b/debian/scripts/wine @@ -8,16 +8,38 @@ bindir=/usr/lib/$name wine32=$bindir/wine wine64=$bindir/wine64 -if test -x $wine32; then +# Set WINEPREFIX for later use. +if test -z $WINEPREFIX; then WINEPREFIX=$HOME/.wine; fi + +# Try wine64, if +# - a 64-bit executable is given as argument +# (NOTE: there are 64-bit applications with 32-bit installers, so this won't help everytime), or +# - if the WINEPREFIX is a 64-bit +# (NOTE: don't do this once WoW64 is implemented, see http://wiki.winehq.org/Wine64ForPackagers.), or +# - if WINEARCH is set to win64. +if test -e $1 -a $(file -b -L $1 | cut -d\ -f1) = PE32+ || \ +test -f $WINEPREFIX/system.reg -a $(grep PROCESSOR_ARCHITECTURE $WINEPREFIX/system.reg | cut -d= -f2) = \AMD64\ || \ +test $WINEARCH = win64 ; then +if test -x $wine64; then + wine=$wine64 +else +echo error: unable to find wine64 executable. +if [ $(dpkg --print-architecture) = amd64 ]; then +echo as root, please execute \apt-get install $(echo $name | sed s/wine/wine64/)\ +else +echo you need $(echo $name | sed s/wine/wine64/). but this is only available on architecture amd64. +fi +exit 1 +fi +# Try 32-bit wine otherwise. +elif test -x $wine32; then wine=$wine32 -elif test -x $wine64; then -wine=$wine64 +else if [ $(dpkg --print-architecture) = amd64 -a $(dpkg --print-foreign-architectures) != i386 ]; then echo it looks like multiarch needs to be enabled. as root, please echo execute \dpkg --add-architecture i386 apt-get update echo apt-get install $(echo $name | sed s/wine/wine32/)\ fi -else echo error: unable to find wine executable. this shouldn't happen. exit 1 fi
Bug#762058: wine-development: Please enable WoW64 setup
Source: wine-development Version: 1.7.26-2 Severity: wishlist Hi, please enable a WoW64 setup to enable wine to run 32-bit applications in a 64-bit wineprefix. Has anyone already worked on this? CC'ing Hilko Bengen who seems to have done so already (see http://lists.alioth.debian.org/pipermail/pkg-wine-party/2013-October/003294.html). Greets jre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761574: wine: Please merge the Debian packaging
Source: wine Version: 1.6.2-8 Severity: wishlist Tags: patch Hi, please merge the Debian packaging of wine and wine-development. Both versions could profit if any change, feedback and bugreport for one version would influence the other one, too. I saw this clearly while working on the alternatives system which naturally brings both versions closer together. See also our discussion in the alternatives bugreport (#758291). I think there is enough time to fix any regressions before the freeze, since the wine-development packaging already had some testing. The attached patch allows to use current wine-development packaging for wine stable by just changing the changelog and running debian/rules once. Of course this still allows to do different things in both versions if necessary. If you look at it you'll see that the changes are quite minimal: - debian/rules: handling of both versions - patches: naturally they have to be adapted. This is the biggest part of the patch, - changelog: modified version for stable - control.in (especially stable only transitional breaks/replaces and transitional packages) You'll find everything in my git repository at https://github.com/jre-wine/wine in the branches master1.7.26-2_merged-packaging and debian/wine-1.6.2-8_merged-packaging. Greets jre diff --git a/debian/changelog b/debian/changelog index 20ca599..736704a 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,9 +1,158 @@ -wine-development (1.7.26-3) UNRELEASED; urgency=medium - +wine-development (1.7.26-3jre0) UNRELEASED; urgency=medium + + * control.in: +- Fix lintian P:pre-depends-directly-on-multiarch-support. + Drop dependency on wine-doc. + (closes: #761461). + * Add merged Debian packaging. +- Based on wine-development 1.7.26-2 + 1.7.26-3-DEBSUFFIX-proposal. +- The single steps I took can be seen in the branch masterUnifiedPackaging. +- This allows one to use exactly the same debian/ folder for + wine-development and wine (wine stable branch), only the first + d/changelog entry has to be adjusted and debian/rules be run once. +- For a clean solution two different changelogs might be maintained (see + below for stable changelog entries). +- Care has to be taken to close bugs in the correct version. +- VERSION (-development or empty) and DEBSUFFIX (-development or + -stable) are used to distinguish between stable and development wine. +- Necessary differences between the two versions are tagged either #stable# + or #development# within the files. d/rules will then enable the correct + lines. +- Use as much as possible of current wine-development packaging, including + removal of old parts from the wine (stable) packaging. Beneath other + changes this means for wine stable: + - Rename wine32|64-dev-tools to wine32|64-tools, added transitional +packages. + - Add preloader packages. + - Replace architecture any-amd64 with amd64. + - Drop build-dependencies: +- autotools-dev +- kfreebsd-kernel-headers [kfreebsd-any] +- file + - Add build-dependencies: +- gettext +- libgettextpo-dev +- libtiff-dev +- libpcap-dev +- freebsd-glue [kfreebsd-any] +- ocl-icd-opencl-dev +- Patches: + - Build d/patches/series from series.in (as requisite of d/control). + - Use different patches if necessary. +- d/watch: + - Build from watch.in (as requisite of d/control). + - Watch for odd versions only in wine development. +- debian/rules: Add d/changelog and d/rules as requisites of d/control. + +- TODO: + - gitignore: Add d/patches/series and d/watch. + - I haven't tested the import script. Of course it might be modified for +a new workflow. + + + The following entries are only for stable wine: + === + * Make transitional packages deborphan compliant (closes: #760696). + + * Modified changelog since last merge (for use in wine stable): + + wine-development (1.7.26-3jre0) * Add alternatives system for wine, the wineapploader links and the manpages. * Introduce DEBSUFFIX (either -development or -stable) in d/rules. - -- jre jre.wine...@gmail.com Thu, 11 Sep 2014 02:15:20 +0200 + wine-development (1.7.26-2) + * Install manpages, thanks jre. + * Build debug package on amd64. + * Call wine-development from desktop launchers. + + wine-development (1.7.26-1) + * Call wine-development instead of wine from the winegcc shell script. + + wine-development (1.7.25-1) + * Update the git repository. + * Fix typo in README.debian. + * Simplify wineapploader. + + wine-development (1.7.24-5) + * Fix wine-preloader installation path. + + wine-development (1.7.24-4) + * Add some information about WINEDEBUG to README.debian. + * Correctly call suffixed wine launcher in wineapploader. + + wine-development (1.7.24-3
Bug#761461: wine-development: control.in cleanup
Package: wine-development
Version: 1.7.26-2
Severity: minor
Tags: patch
Hi
two fixes for control.in:
- Fix lintian P:pre-depends-directly-on-multiarch-support,
use ${misc:Pre-Depends} which currently resolves to
multiarch-support.
- Drop wine-doc dependency,
as this package has been removed from the repository.
Greets
jre
commit 563ce59ea192fa477c03c689c0ee3e9bb880e702
Author: jre jre.wine...@gmail.com
Date: Sun Sep 14 02:34:15 2014 +0200
control.in cleanup
- Fix lintian P:pre-depends-directly-on-multiarch-support,
use ${misc:Pre-Depends} which currently resolves to multiarch-support.
- Drop wine-doc dependency,
as this package has been removed from the repository.
diff --git a/debian/control.in b/debian/control.in
index f73ad85..04b1bbd 100644
--- a/debian/control.in
+++ b/debian/control.in
@@ -67,7 +67,6 @@ Depends:
${misc:Depends},
wine64VERSION (= ${source:Version}) | wine32VERSION (= ${source:Version}),
Suggests:
- wine-doc,
binfmt-support,
ttf-mscorefonts-installer,
Description: Windows API implementation - standard suite
@@ -214,7 +213,7 @@ Suggests:
cups-bsd,
wine-doc,
Pre-Depends:
- multiarch-support,
+ ${misc:Pre-Depends},
Description: Windows API implementation - library
Wine is a free MS-Windows API implementation.
This is still a work in progress and many applications may still not work.
Bug#758291: [pkg-wine-party] Bug#758291: Bug#758291: Complete solution for update-alternatives
Hi [I forgot to answer to the bug last time, see my last answer at the end of the message.] tldr: = Everything works. No new package names. Just take alternatives-wine1.6.2.patch and alternatives-master_DEBSUFFIX.patch. Consider merging the packaging to avoid some corner case issues due to the new suffix -stable. Long story: === Attached you'll find 3 patches. The packages build, are installable and changing the alternative between stable and development works. I successfully tested: - wine --version - wine OriginSetup.exe - wineboot wineboot (stable) requires a .wine to exist, but this issue is also present in 1.6.2-8. For current master (1.7.26-2): -- Choose between these two patches (they install identical stuff): - alternatives-master_DEBSUFFIX.patch - alternatives-master_minimal.patch The first one introduces a new variable DEBSUFFIX to make merging stable and development packaging sometime easier. The second (minmal) one simply uses VERSION. This will require work when merging stable and development packaging, since VERSION is empty for stable, thus there would be name collisions. I recommend not to use this one. For debian/wine-1.6.2 (1.6.2-8): - alternatives-wine1.6.2.patch This works for the current packages. But see issues 1 2 below, and consider merging the packaging now. You'll find everything also in my git repository at https://github.com/jre-wine/wine in the branches - debian/wine-1.6.2UpdateAlternatives-minimal - masterUpdateAlternatives-minimal - masterUpdateAlternativesDEBSUFFIX Issues == 1.) -stable in names Introducing wine-stable et al. causes the same problems like for wine-development. This does no harm as long as you use wine as alternative for wine-stable (which is the default setup). But if you directly use the -stable suffixed names AND wine-development is set to provide the alternatives, then strange things might happen. E.g. you create a Desktop launcher with wine-stable. In it solely wine is mentioned, which might point to wine-development. 2.) /usr/bin/wine32|64 -- These two files are only in the stable wine package and not covered by the alternatives system. This may be confusing when /usr/bin/wine points to wine-development. 3.) Breaks or Conflicts? I added a wine-developments breaks wine 1.6.2.9 to avoid filename conflicts (e.g. the new alternatives link /usr/bin/wine vs. the script /usr/bin/wine (wine 1.6.2-8) which is called /usr/bin/wine-stable now). -- I don't know whether to make this a Breaks or a Conflicts. Breaks allows to install an unconfigured wine-development next to wine 1.6.2-8. While this causes no errors, you'll just miss wine-development in the alternatives system until you install and configure it. dpkg-reconfigure wine-development didn't help here. lintian complained about the Conflicts being versioned. But since this makes sense in our case it might be better to use the versioned Conflicts and add a lintian-override. Greets jre On 09/07/2014 04:13 AM, jre wrote: Hi First of all, thanks a bunch for all the work you've been doing lately for the wine packages. Thanks, much appreciated. I wasn't planning on merging the source for the two until after jessie, and would prefer not to do that yet. Is there any way you could work these changes out so that it doesn't involve major disruption to the wine stable package? Well, it would ease maintaining the packages in jessie. Anyway I'll post the appropriate patches soon and then open a separate bug with patches for a merged packaging. Greets jre commit 6f74551a08d5ef68539daf5be7f714e9801be91e Author: jre jre.wine...@gmail.com Date: Thu Sep 11 02:38:16 2014 +0200 alternatives for wine - Provide alternatives (priority 20) without suffix for /usr/bin/wine, the wineapploader links and their man pages. The default is wine stable with priority 70. - Introduce DEBSUFFIX (either -development or -stable) in d/rules. - Use DEBSUFFIX instead of VERSION for files that have an alternative link, to prevent name collisions when building wine stable. diff --git a/debian/changelog b/debian/changelog index e1d8eff..20ca599 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +wine-development (1.7.26-3) UNRELEASED; urgency=medium + + * Add alternatives system for wine, the wineapploader links and the manpages. + * Introduce DEBSUFFIX (either -development or -stable) in d/rules. + + -- jre jre.wine...@gmail.com Thu, 11 Sep 2014 02:15:20 +0200 + wine-development (1.7.26-2) unstable; urgency=medium * Install manpages, thanks jre (closes: #760694). diff --git a/debian/control.in b/debian/control.in index f73ad85..34f1746 100644 --- a/debian/control.in +++ b/debian/control.in @@ -70,6 +70,8 @@ Suggests: wine-doc, binfmt-support, ttf-mscorefonts
Bug#758291: [pkg-wine-party] Bug#758291: Bug#758291: Complete solution for update-alternatives
Hi, the -development patches missed the wineapploader fix (I didn't notice this when testing, because the alternative system conceals this problem). The attached patch goes on top of alternatives-master_DEBSUFFIX.patch or alternatives-master_minimal.patch. Thanks jre commit de9184e06cd9f759afc3abd45acd50ceeaa2ad6f Author: jre jre.wine...@gmail.com Date: Fri Sep 12 18:09:53 2014 +0200 alternatives: fix wineapploader diff --git a/debian/patches/wineapploader.patch b/debian/patches/wineapploader.patch index 91fb0ff..d8dfa5b 100644 --- a/debian/patches/wineapploader.patch +++ b/debian/patches/wineapploader.patch @@ -10,7 +10,7 @@ author: Michael Gilbert mgilb...@debian.org -appname=`basename $0 .exe`.exe +app=$(basename $0 .exe) +name=$(echo $app | cut -d- -f1) -+suffix=$(echo $app | sed s/$name//) ++suffix=$(basename $(dirname $(readlink -f $(which $0))) | sed s/wine//) +appname=$name.exe # first try explicit WINELOADER
Bug#761024: dh_installman: Please support translated man pages by looking at the pathname
Package: debhelper Version: 9.20140817 Severity: wishlist Hi, dh_installman already honors extensions like .ll.8 to detect the correct location for the man page. E.g. the following works as expected: $ dh_installman -v debian/tmp/usr/share/man/man1/wine-stable.de.1 install -p -m644 debian/tmp/usr/share/man/man1/wine-stable.de.1 \ debian/wine-development/usr/share/man/de/man1/wine-stable.1 It would be helpful to have a similar mechanism if the language is given in the pathname of the man page (between usr/share/man/ and man1/). So that instead of: $ dh_installman -v debian/tmp/usr/share/man/de.UTF-8/man1/wine-stable.1 install -p -m644 debian/tmp/usr/share/man/de.UTF-8/man1/wine-stable.1 \ debian/wine-development/usr/share/man/man1/wine-stable.1 one would get: install -p -m644 debian/tmp/usr/share/man/de.UTF-8/man1/wine-stable.1 \ debian/wine-development/usr/share/man/de/man1/wine-stable.1 Thanks for debhelper! jre -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (900, 'testing'), (300, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-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 Versions of packages debhelper depends on: ii binutils2.24.51.20140903-1 ii dpkg1.17.13 ii dpkg-dev1.17.13 ii file1:5.19-1 ii man-db 2.6.7.1-1 ii perl5.20.0-6 ii po-debconf 1.0.16+nmu3 debhelper recommends no packages. Versions of packages debhelper suggests: ii dh-make 1.20140617 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761025: dpkg: update-alternatives man page: Please clarify the invocation in prerm
Package: dpkg Version: 1.17.13 Severity: minor Hi The update-alternatives man page currently states: update-alternatives is usually called from the postinst (configure) or prerm (install) scripts in Debian packages. I guess instead of prerm (install) it should read prerm (remove and deconfigure). Thanks jre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760694: wine-development: Please add manpages
Source: wine-development Version: 1.7.25-1 Severity: normal Tags: patch Hi, please add manpages again to wine-development. You'll find a complete working patch in the masterUnifiedPackaging branch at https://github.com/jre-wine/wine. I'd be happy to adjust it in any way required. If you want a separate patch just tell me. Details and open questions/TODO: Commit 4cfece04772eabe1b9e7a7b47127c4d77354d021 2014-09-07 01:33:52 add manpages - New wineVERSION-doc package. Multi-Arch foreign to avoid conflicts. - Install all manpages from upstream mandir (generic). This includes manpages for programs that are not installed to path, but in /usr/lib/*/wineVERSION/. But IMO even this way the manpages are of some use. They might be patched to show how to call the programs. Or the programs could be installed to path, which is a bit complicated (probably not desirable) in respect to multiarch. - Add update-alternatives (hardcoded for the moment) for master wine.1.gz. This still needs a little manual adaption for wine stable (still works though). Adding the manpages as slaves to wine would require the wineVERSION package to Pre-Depend on wineVERSION-doc. Breaks wine 1.6.2-9 (assuming this is applied to the next release 1.6.2-9). TODO: - lintian overrides (binary and manpage in different packages). - Fix more hyphen-used-as-minus-sign occurences. - Move all READMEs to this package? I'll work a bit more on this the next days and notify you here, when I'm done. Just give me your thoughts. Thanks jre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760696: Please make the transitional packages deborphan compliant
Source: wine-development Version: 1.7.25-1 Severity: normal Tags: patch Hi, please make the transitional packages deborphan compliant. You'll find a complete working patch in the masterUnifiedPackaging branch at https://github.com/jre-wine/wine. I'd be happy to adjust it in any way required. If you want a separate patch just tell me. Details and open questions: Commit 0bc1dc727c31f9462d38e380b8666e218393f73b 2014-09-01 22:44:18 transitional packages: make them deborphan compliant, changed description For all transitional packages: - Section: oldlibs (unsure whether this is ok for wine32|64-dev-tools transitional packages) - Priority: extra - common short and long description. transitional should definitely be mentioned in the short description. Thanks jre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760697: Please add libwineVERSION-dbg in architecture amd64
Source: wine-development Version: 1.7.25-1 Severity: normal Tags: patch Hi, please add libwineVERSION-dbg in architecture amd64. I guess they are needed there, too. And they are left over when building on amd64, thus requiring to remove them manually to build again. Thanks jre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758291: Complete solution for update-alternatives
Hi I just pushed a few minor changes/fixes to my git repository. I changed to use the branch masterUnifiedPackaging instead of master. As of now there is only one additional lintian complain, and this is only for wine (stable) packages: W: wine: latest-debian-changelog-entry-without-new-version Otherwise I think my proposal is regression free. [The rest of this message is only related to the unified packaging. Although this doesn't suit this bugreport, it is still related due to my patch proposal using the unified packaging, sorry for the noise.] About a common changelog: Is it ok to ship a common changelog with changes for wine-development that are not in wine (in particular, all the upstream changes)? In bug #597154 Russ Albery argues that this is not ok. While I think that the changelog stays true as long as -development only packaging changes are marked as such, I'm not sure about the upstream changes. This would mean to maintain two separate changelogs, which is one of the things I wanted to avoid. Finally a little correction for the quickdirty use instruction (other branch name and earlier changelog entry): ~ git checkout master cp -rf debian .. git checkout jessie #or whatever the branch is/will be called rm -rf debian mv ../debian . # update changelog ./debian/rules #recreates debian/control # build packages ~ jre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758291: Complete solution for update-alternatives
Hi, I successfully implemented the update-alternatives system for wine and wine-development (without changing the package names). I built, installed and tested packages on my amd64 machine, using cowbuilder for amd64 and i386 packages. but ... tldr: I extended the packaging to support wine and wine-development at the same time without any changes (except updating the changelog), but still allowing for differences. Although this is no little change, it greatly keeps in line with the current wine-development packaging. Of course, if you don't support this approach, I can send you separate patches for wine and wine-development, solely for update-alternatives without any additional stuff. But I really hope you accept the whole extended set. I think this greatly improves the wine (stable) packages, without doing any grave changes (having the freeze in mind). Now the long version: Why a unified packaging? I think nearly all packaging changes in master (normally tracking wine development) should be added regularly to wine (stable) Debian packages, too. There should be no big difference between wine and wine-development, except the upstream source. Waiting for a upstream stable release to completely sync the packaging is way too long, especially if this happens shortly after a Debian release (e.g. jessie). But just copying over the debian/ folder doesn't work. Although the VERSION logic is already a great step for this (and the reason that I tried this at all), there is still some stuff that requires manual merging. At least the patches have to be adjusted, but I ended up with other stuff, including changes for the update-alternative implementation. Alternatively cherrypicking commits manually from wine-development IMO is no option, because it increases the workload a lot, if you want to keep both versions' packaging in sync. So this is my proposal (completely implemented) to ease that task. What I did: === First off, I've put everything at github: https://github.com/jre-wine/wine.git I tried hard to structure it in meaningful commits, avoiding anything unncesseary and explaining everything in commit messages. Here the short summary: Unified packaging: -- I extended the Debian packaging based upon master (wine-development 1.7.25-1). It allows to use exactly the same debian/ folder for wine-development and wine (currently 1.6.2) - only the debian/changelog entry has to be adjusted and the control file regeneration by debian/rules has to be triggered once. If there are different lines necessary between wine and wine-development's Debian packaging files, they can be tagged either #stable# or #development#. debian/rules takes care to build the correct version based on VERSION. For this I just extended the current mechanism to remove the wrong lines completely, and remove the correct tag so that we get valid lines. Example: wine (stable) has transitional packages defined in control.in. I just prefixed these lines with #stable#. When building wine-development control is generated without any mention of a transitional package. This also allows both sharing patches, and having different patches where necessary. Of course, I already did that for the current patches. Generally I tried to use as much as possible of the current wine-development packaging for both, including removal of old parts from the wine (stable) packaging. I put the things I dropped from control.in (stable) in a separate commit, so you can review it. Beneath other changes this means for wine stable (I can revert those if this doesn't suit for jessie): - Renamed wine32|64-dev-tools to wine32|64-tools, added transitional packages . - Added preloader packages. - Replaced architecture any-amd64 with amd64. And for wine-development: -added a conflicts wine ( 1.6.2-9) ... hoping you take my changes in the next wine (stable) package 1.6.2-9. update-alternatives --- Then of course I added the update-alternatives system for /usr/bin/wine and the apploader links. This uses the same names as wine (stable) currently provides (e.g. /usr/bin/wine, so for wine (stable) I added a suffix -stable to them, e.g. /usr/bin/wine-stable. Of course without touching the rest of the packaging setup. The default is to use stable wine, so installing wine-development parallel to wine doesn't break anything. other changes - Finally I made some related changes. They are also useful without the unified packaging: * debian/rules: added d/changelog and d/rules as prerequisite of d/control. * control.in: fix lintian warning multiarch-support. * debian/rules: add libwineVERSION-dbg for architecture amd64. How to use the unified packaging: = The quickdirty way to move from wine-development to wine (stable) is: ~ git checkout master cp -rf debian .. git checkout wine-1.6 #or whatever the branch is/will be called rm -rf debian mv
Bug#758291: [pkg-wine-party] Bug#758291: Proof of concept: Debian's alternative system in wine-development 1.7.24-5
Hi On 08/24/2014 01:20 AM, Michael Gilbert wrote: Hi, I think this is a reasonable goal, so thanks a bunch for working toward it. You'll also need to work out a patch for the wine 1.6 packages in order to produce a complete solution. Thanks a lot for the thumbs up. So far I used the wine-development packaging and use it for wine-stable, too (all packages for the upstream stable release get added a suffix -stable). It seems I just have to omit some patches, otherwise it will work fine. Currently I can build -development and -stable on amd64 and get packages with working alternatives :) The only real blocker for now is to add Conflicts/Replaces and transitional packages for wine -- wine-stable. I will do that probably tomorrow. With -stable I got more lintian warnings and even errors then for -development. That's the 2nd next thing on my TODO. Further the current packaging lacks the manpages. Those have to be readded. Do you have something pending for this task, or should I look into it? Once the manpages are back again, I'll readd them to the alternatives system. Questions: 1.) I guess it is ok to use the -development packaging for -stable, too. And to rename wine--wine-stable. If not: please tell me ASAP! 2.) Does anybody know whether this change (wine--wine-stable) counts as an transition and thus is subject to the freeze stage on September 5th: On 07/05/2014 09:37 AM, Niels Thykier wrote: Freeze reminder FREEZE We are quickly approaching the freeze, which is about ~4 months away! * In two months (5th of Sep), we will close down for transitions! Do not start new transitions after this date. They might result in removals from jessie or reverts in unstable. 3.) wine-stable requires an separate git branch. Currently there are 2 branches: jessie based on 1.6.2-7, and wine-1.6.2 containing 1.6.2-8. I couldn't check out the latter one, probably because the branch name is the same as some tag. Can anybody tell me how to do that? Greets jre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758708: wine-development: Please update the git repository
Source: wine-development Version: 1.7.24-5 Severity: wishlist Hi Michael, please update the wine git repository. I guess filing this request as a bug best matches your workflow. Technical reason: apt-get source wine-development Reading package lists... Done Building dependency tree Reading state information... Done NOTICE: 'wine-development' packaging is maintained in the 'Git' version control system at: git://anonscm.debian.org/pkg-wine/wine.git Skipping already downloaded file 'wine-development_1.7.24-5.dsc' Skipping already downloaded file 'wine-development_1.7.24.orig.tar.bz2' Skipping already downloaded file 'wine-development_1.7.24-5.debian.tar.xz' ... so there is a NOTICE that I can find the packaging in git. But this is of no use, since the head of it is still at release 1.7.21-1. Thanks in advance jre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758291: Proof of concept: Debian's alternative system in wine-development 1.7.24-5
Hi,
proof of concept - it works.
I adjusted the wine script and wineapploader to get the suffix based on
their link target's directory names. This should also work fine without
the alternative system.
Then I added a postinst and prerm script with the actual
update-alternative commands.
See attached patch from a local git repository based upon apt-get
source wine-development. Unfortunately I'm not able to build yet, but I
think this is just because I try to patch wineapploader.in again but
with an modified patch.
[I edited my email address in the attached patch, don't know if this is
a problem for applying it. And of course it is not based on the real git
repository.]
A current git repository for the wine packaging would make these things
much easier. Michael please update it.
So for now I simply executed the commands from the postinst and adjusted
/usr/bin/wine and /usr/lib/wine-development/wineapploader.
I tested it successfully:
/usr/bin/wine --version
wine-1.7.24
/usr/bin/wine-development --version
wine-1.7.24
wine --version
wine-1.7.24
wine-development --version
wine-1.7.24
winecfg
winecfg-development
/usr/bin/winecfg
/usr/bin/winecfg-development
... all work.
To be continued ...
jre
commit 7d58285dbdb664bcc9a69a22c55144751236b0c2
Author: jre jre.wine...@gmail.com
Date: Mon Aug 18 16:41:28 2014 +0200
added update-alternatives system
diff --git a/debian/changelog b/debian/changelog
index 741d97d..1c54443 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+wine-development (1.7.24-5.1) UNRELEASED; urgency=medium
+
+ * added update-alternatives system
+
+ -- jre jre.wine...@gmail.com Mon, 18 Aug 2014 14:15:37 +0200
+
wine-development (1.7.24-5) unstable; urgency=medium
* Fix wine-preloader installation path.
diff --git a/debian/patches/wineapploader.patch
b/debian/patches/wineapploader.patch
index a6c75ce..4c186e6 100644
--- a/debian/patches/wineapploader.patch
+++ b/debian/patches/wineapploader.patch
@@ -10,7 +10,7 @@ author: Michael Gilbert mgilb...@debian.org
-appname=`basename $0 .exe`.exe
+app=`basename $0 .exe`
+name=`echo $app | cut -d- -f1`
-+suffix=`echo $app | sed s/$name//`
++suffix=$(echo $(basename $(dirname $(readlink -f $(which $0 | sed
s/wine//)
+appname=$name.exe
# first try explicit WINELOADER
diff --git a/debian/scripts/wine b/debian/scripts/wine
index 388f3ae..269bbe7 100755
--- a/debian/scripts/wine
+++ b/debian/scripts/wine
@@ -2,7 +2,7 @@
set -e
-name=$(basename $0)
+name=$(basename $(readlink -f $(which $0)))
bindir=/usr/lib/$name
wine32=$bindir/wine
diff --git a/debian/wineVERSION.postinst b/debian/wineVERSION.postinst
new file mode 100644
index 000..1315bda
--- /dev/null
+++ b/debian/wineVERSION.postinst
@@ -0,0 +1,18 @@
+#!/bin/sh
+
+set -e
+
+if [ $1 = configure ] ; then
+ # add update-alternatives entries for wine and the wineapploader scripts
+ # TODO: manpages
+ for app in wineboot winedbg winefile winecfg winepath ; do
+slaves=$slaves --slave /usr/bin/$app $app /usr/bin/${app}VERSION
+ done
+ update-alternatives \
+--install /usr/bin/wine wine /usr/bin/wineVERSION 20 \
+$slaves
+fi
+
+#DEBHELPER#
+
+exit 0
diff --git a/debian/wineVERSION.prerm b/debian/wineVERSION.prerm
new file mode 100644
index 000..6a48420
--- /dev/null
+++ b/debian/wineVERSION.prerm
@@ -0,0 +1,14 @@
+#!/bin/sh
+
+set -e
+
+case $1 in
+ remove|deconfigure)
+# remove update-alternatives entries
+update-alternatives --remove wine /usr/bin/wineVERSION
+;;
+esac
+
+#DEBHELPER#
+
+exit 0
Bug#758586: [ wine-development ] README.Debian minor typo
Package: wine-development Version: 1.7.24-5 Severity: minor Typo Wnie instead of Wine: --- README.debian.orig 2014-08-18 12:16:28.094048602 +0200 +++ README.debian 2014-08-18 12:17:59.078051038 +0200 @@ -39,7 +39,7 @@ Old Versions -If you want to install a previous version of Wnie, you should be able to fetch +If you want to install a previous version of Wine, you should be able to fetch prior Debian versions from: http://snapshot.debian.org/package/wine http://snapshot.debian.org/package/wine-development -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758173: Please reopen/solve bug [wine-development] Please keep the default WINEDEBUG instead of -all
Hi Michael, your additions to the README.Debian do help, but they don't actually solve the whole problem. So I ask you to reopen this bug. AFAIK currently there is NO way to use upstream's default setting for WINEDEBUG automatically. I tried WINEDEBUG= but this is resolved to -all. I didn't find any documentation on upstream's default. But even if I had found it, I don't like setting a variable in .bashrc for a value that upstream might change some time. If you still prefer your solution with -all and don't want to make it possible to use the default I propose to at least give an example replicating upstream's default [1] and some links [2] in README.Debian. [1] I assume this is upstream's default for WINEDEBUG: WINEDEBUG=err+all,warn+all,fixme+all [2] http://wiki.winehq.org/DebugChannels and/or https://www.winehq.org/site/docs/wineusr-guide/x543#AEN545 jre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758589: [wine-development] wineapploader broken if wine is installed
Package: wine-development Version: 1.7.24-5 Severity: normal File: /usr/lib/wine-development/wineapploader Hi in wine-development's wineapploader the following test is true if stable wine is installed, thus development wineapploader using stable wine: # now try the directory containing $0 [...] if [ -x $appdir/wine ]; then exec $appdir/wine $appname $@; fi I suggest to just remove that whole paragraph. Otherwise add $suffix in there, too. The previous # then default bin directory test should always be false. I see no use for it, so I'd remove it, too. So on a Debian system there are only 2 of 4 working possibilities (for the wineapploader in the wine-development package): - explicit WINELOADER - wine-development (wine$suffix) in PATH jre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758312: [pkg-wine-party] Bug#758312: wine-development: please provide an upgrade path
Hi, On 08/16/2014 07:57 PM, Marc Dequènes (Duck) wrote: I have no idea why you renamed wine-unstable into wine-development, This was announced and discussed here: http://lists.alioth.debian.org/pipermail/pkg-wine-party/2014-April/003804.html Greets jre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758291: [pkg-wine-party] Bug#758312: wine-development: please provide an upgrade path
Hi On 08/17/2014 02:38 PM, LOMBARD Maxime wrote: Make a difference between the stable and unstable version of wine can be a good idea BUT only in the package's name and not in the application's name. For me actually, it's very complicated and it will be more difficult to resolv bug ... Why you don't create the wine's package like from Ubuntu, it's more easy : *** Stable Wine's package *** wine package which include all files installed in /usr/bin libwine package which include all files installed in /usr/lib/*/wine *** Unstable Wine's package *** wine-unstable package which include all files installed in /usr/bin without suffixe libwine-unstable package which include all files installed in /usr/lib/*/wine without suffixe. And failed the both installations. Example, wine is in conflict with wine-unstable and vice-versa. If a user install wine-unstable package, it uninstall automatically wine package. Well, this is not really related to #758312 since this one is indeed about the package names and the transition -unstable -- -development. Anyway; afaik it was a long standing goal to make both wine versions (including their 32bit and 64bit versions) coinstallable. This I would really like to see. Still I agree that working directly with the suffix'ed versions really is a pain and does not meet user's expectations. Therefore in bug #758291 ([wine-development] Please use Debian's alternative system) I requested/suggested an actual solution which imho should make us all happy. Without it I would tend to prefer your solution. I think we are finally quite close to actually get the wine packages that were planned for many painful years now (again a so huge thank you to Michael here). I hope to send a first patch to #758291 tomorrow which implements the alternative system at least for the -development packages. I CC'd that bug because I think discussing this topic is more appropriate there (or directly at the pkg-wine-party list). Greets jre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758290: [wine-development] version suffix of wineapploader scripts don't work
Package: wine-development Version: 1.7.24-3 Severity: normal --- Please enter the report below this line. --- Hi, the new version suffixes (e.g. /usr/bin/winecfg-development) don't work: winecfg-development wine: cannot find LC:\\windows\\system32\\winecfg-development.exe Greets jre --- System information. --- Architecture: amd64 Kernel: Linux 3.14-2-amd64 Debian Release: jessie/sid 900 testing http.debian.net 500 testing moblock-deb.sourceforge.net 500 stable moblock-deb.sourceforge.net 300 unstableftp.debian.org --- Package information. --- Depends (Version) | Installed =-+-=== wine64-development (= 1.7.24-3) | 1.7.24-3 OR wine32-development (= 1.7.24-3) | 1.7.24-3 Package's Recommends field is empty. Suggests (Version) | Installed -+-=== wine-doc | binfmt-support | 2.1.4-1 ttf-mscorefonts-installer| 3.5 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758291: [wine-development] Please use Debian's alternative system
Package: wine-development Version: 1.7.24-3 Severity: wishlist --- Please enter the report below this line. --- Hi, to solve many issues related to the new wine-development packages with the -development suffix) I suggest the following: 1.) stable branch: provide binaries/manpages with suffix -stable (e.g. /usr/bin/wine-stable|winecfg-stable|...) 2.) development branch: provide binaries/manpages with suffix -development (e.g. /usr/bin/wine-development|winecfg-development|...) 3.) both branches: provide wine without a suffix using Debian's alternative system, e.g. /usr/bin/wine -- /usr/bin/wine-stable /usr/bin/winecfg -- /usr/bin/winecfg-stable Perhaps this was already what you intended to do, don't know. I had this idea when I saw your recent suffix additions (before seeing that they break wine internals) and suddenly realized that extending this to the stable branch should make implementing Debian's alternative system really easy. Before I thought about implementing it by directly linking to the files in /usr/lib/. This would solve #758290 (wineapploader scripts like winecfg),#758176 (Desktop launchers), #750880 (winetricks) and any other 3rd party problems (e.g. playonlinux can't use system's wine-development). Greets jre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758147: wine-development: conflicts with wine
Package: wine-development Version: 1.7.24-2 Severity: normal Hi, --- snip --- Unpacking wine (1.6.2-8) ... dpkg: error processing archive /var/cache/apt/archives/wine_1.6.2-8_amd64.deb (--unpack): trying to overwrite '/usr/bin/regedit', which is also in package wine-development 1.7.24-2 Processing triggers for man-db (2.6.7.1-1) ... Errors were encountered while processing: /var/cache/apt/archives/wine_1.6.2-8_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) --- snap --- I guess for the time being wine-development should have the same conflicts/replaces like wine-unstable to wine and vice-versa. Or you just have to take care of regedit. Related to the solution that you choose for this bug, I wonder whether you consider wine and wine-development to be coinstallable and whether you are basically done with the big changes for the wine packages (see #741702 wine-unstable: not yet ready for stable release). Personally I'd hope for a single /usr/bin/wine for wine and wine-development, managed with Debian's alternatives system, instead of the 3rd-party-(own scripts, winetricks, playonlinux, ...)-breaking /usr/bin/wine-development. Still, a huge Thank You for your efforts and I hope you get wine in shape before the freeze. jre -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (900, 'testing'), (300, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-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 Versions of packages wine-development depends on: ii wine32-development 1.7.24-2 ii wine64-development 1.7.24-2 wine-development recommends no packages. Versions of packages wine-development suggests: ii binfmt-support 2.1.4-1 ii ttf-mscorefonts-installer 3.5 pn wine-doc none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758168: wineapploader looks for wine-unstable
Package: wine-development Version: 1.7.24-2 Severity: normal Hi, the wrappers /usr/bin/wine* (wineboot, winecfg, ...) don't work: winecfg /usr/bin/winecfg: 52: exec: wine-unstable: not found I guess this results from /usr/lib/wine-development/wineapploader: --- snip --- [...] # finally look in PATH exec wine-unstable $appname $@ --- snap --- Thanks again, looking forward to use wine-development in Debian jre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758168: [pkg-wine-party] Bug#758168: wineapploader looks for wine-unstable
Yes, changing this in /usr/lib/wine-development/wineapploader fixes it. So debian/patches/wineapploader.patch needs to be changed: +exec wine-unstable $appname $@ +exec wine-development $appname $@ While looking at this I spotted another use of wine-unstable in debian/scripts/import in wine-developmeent 1.7.24-2 (the git repository is out of date). Since I don't use this script, I don't know if this is actually wrong: --- snip --- case $upstream_version in 1.0.*|1.2|1.2.*|1.4|1.4.*|1.6|1.6.*) package=wine ;; 1.1.*|1.3.*|1.5.*|1.7.*) package=wine-unstable ;; *) echo Unknown version series: $upstream_version exit 1 ;; esac --- snap --- shouldn't this be something like: --- snip --- [...] 1.7.2[2-9]|1.7.3[0-9]|1.7.4[0-9]) package=wine-development ;; 1.1.*|1.3.*|1.5.*|1.7.*) package=wine-unstable ;; [...] --- snap --- Hope I helped. jre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758173: [wine-development] Please keep the default WINEDEBUG instead of -all
Package: wine-development Version: 1.7.24-2 Severity: normal --- Please enter the report below this line. --- Hi /usr/bin/wine-development (debian/scripts/wine) sets WINEDEBUG=-all by default since 1.7.16-2. I found no reason for this change. When I try to figure out problems with wine, my first step is to run in a terminal wine program.exe. This helps a lot since AFAIK the FIXME and ERR classes are enabled by default in upstream wine. But now I have to use WINEDEBUG= wine-development program.exe to get the same result. I think shutting down these messages (contrary to upstream's default) is no good idea for a program like wine. Thanks again jre --- System information. --- Architecture: amd64 Kernel: Linux 3.14-2-amd64 Debian Release: jessie/sid 900 testing http.debian.net 300 unstablehttp.debian.net --- Package information. --- Depends (Version) | Installed =-+-=== wine64-development (= 1.7.24-2) | 1.7.24-2 OR wine32-development (= 1.7.24-2) | 1.7.24-2 Package's Recommends field is empty. Suggests (Version) | Installed -+-=== wine-doc | binfmt-support | 2.1.4-1 ttf-mscorefonts-installer| 3.5 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758173: [wine-development] Please keep the default WINEDEBUG instead of -all
Minor correction, my workaround doesn't work. But I get back the old behavior when I remove -all in /usr/bin/wine-development Sorry for the noise jre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758176: [wine-development] wine-development breaks autogenerated Desktop launchers
Package: wine-development Version: 1.7.24-2 Severity: normal --- Please enter the report below this line. --- I just installed Origin (download.dm.origin.com/origin/live/OriginSetup.exe) with wine-development. This creates ~/Desktop/Origin.desktop, which tries to execute wine instead of wine-development. Obviously this fails. I made sure that the desktop file was not from an old installation. Thanks jre --- ~/Desktop/Origin.desktop --- [Desktop Entry] Name=Origin Exec=env WINEPREFIX=/home/jens/.wine wine C:windowscommandstart.exe /Unix /home/jens/.wine/dosdevices/c:/users/Public/Desktop/Origin.lnk Type=Application StartupNotify=true Path=/home/jens/.wine/dosdevices/c:/Program Files/Origin --- System information. --- Architecture: amd64 Kernel: Linux 3.14-2-amd64 Debian Release: jessie/sid 900 testing http.debian.net 300 unstablehttp.debian.net --- Package information. --- Depends (Version) | Installed =-+-=== wine64-development (= 1.7.24-2) | 1.7.24-2 OR wine32-development (= 1.7.24-2) | 1.7.24-2 Package's Recommends field is empty. Suggests (Version) | Installed -+-=== wine-doc | binfmt-support | 2.1.4-1 ttf-mscorefonts-installer| 3.5 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#578192: RFP: PeerGuardian Linux (pgl) -- IP blocking software
Package name: pgl Version: 2.1.3 Upstream Author: PeerGuardian devel mailing list peerguardian-de...@lists.sourceforge.net URL: http://sourceforge.net/projects/peerguardian/ License: GPL-3 Programming Lang: C++, C, POSIX shell Description: privacy oriented firewall application PeerGuardian Linux (pgl) is a privacy oriented firewall application. It blocks connections to and from hosts specified in huge blocklists (thousands or millions of IP ranges). pgl is based on the Linux kernel netfilter framework and iptables. Hi, I'm a co-author of PeerGuardian Linux (pgl). pgl is the official successor of moblock, blockcontrol and mobloquer, all previous authors agreed on that. So I updated this bug report. I've already packaged pgl upstream. It's nearly lintian clean. A repository is at moblock-deb.sourceforge.net. Thanks jre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
