Re: Possibility of getting an up-to-date version of Wine into Squeeze
Den 21. aug. 2010 10:55, skrev Stephen Kitt: On Sat, Aug 21, 2010 at 04:02:37AM +0200, Ove Kaaven wrote: Den 21. aug. 2010 03:01, skrev Svante Signell: Please take this request seriously. Even if Squeeze is frozen, distributing the same version (1.0.x) of Wine as Lenny does not look good! People are trying to help out! I wouldn't hold much hope. These are the options: 1. Get wine-gecko built on Debian. Apparently gcc-mingw32 4.4.4 did not solve all the problems with it, gcc-mingw32 would apparently have to be upgraded all the way to 4.5.0 to build a fully working package. Not sure if the release team will accept that, and even if they did, packaging Wine 1.2 for squeeze will, by now, be a rush job that may result in a package with serious problems. Have you had a chance to take a look at my packages? I took the time to separate each patch out so that you'd be able to integrate them into your git tree without to much trouble. I'll take a look when the time comes. Until gcc-mingw32 is updated, there's not much that can be done anyway. Note that I already did some preliminary work a while ago (including a complete wine-gecko package, just waiting for a working compiler), and have had some long-term plans for the Wine package itself, and probably not in the direction you might expect or have worked on. So I might not have use for such patches, but we'll see when it finally becomes possible to update Wine. For now, I suggest working on a working gcc-mingw32, if anything. Note that building wine-gecko also requires an updated version of mingw-w64 (used to produce an updated replacement for mingw32-runtime). My own wine-gecko package does not need this. (Though if mingw32-runtime were to be updated, its build system could be simplified a bit, I guess.) -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c6f9c83.6070...@arcticnet.no
Re: Possibility of getting an up-to-date version of Wine into Squeeze
Den 21. aug. 2010 03:01, skrev Svante Signell: Please take this request seriously. Even if Squeeze is frozen, distributing the same version (1.0.x) of Wine as Lenny does not look good! People are trying to help out! I wouldn't hold much hope. These are the options: 1. Get wine-gecko built on Debian. Apparently gcc-mingw32 4.4.4 did not solve all the problems with it, gcc-mingw32 would apparently have to be upgraded all the way to 4.5.0 to build a fully working package. Not sure if the release team will accept that, and even if they did, packaging Wine 1.2 for squeeze will, by now, be a rush job that may result in a package with serious problems. 2. Allow wine to download upstream's wine-gecko binaries over the Internet, as it does by default. Wine 1.2 will do this even if you're not using any software which actually needs HTML rendering. It downloads wine-gecko binaries from a particular URL on SourceForge. There is no verification of the binaries; no signatures, no MD5 hashes. And Wine doesn't do sandboxing. IOW, there is no security. 3. Disable the wine-gecko download. This results in a crippled Wine, and both upstream and users will hate us. 4. Leave things as they are. If users want Wine 1.2, let them use backports.org or similar, or even download upstream's own Debian packages if they prefer. I'm certainly willing to settle for 4... -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c6f33bd.3020...@arcticnet.no
Freeze exception for Wine 1.0.1?
A couple of days ago, I uploaded Wine 1.0.1 to unstable. Although 1.0.1 was released by upstream, this is a maintenance release with only minor bugfixes, there were no significant changes. (Significant changes and major bugfixes currently happen in the 1.1.x series, not 1.0.x. Any 1.0.x fixes have, in addition to being minor, obviously also received testing upstream before being applied to the stable branch.) I therefore feel this can justifiably be allowed into testing, presumably after the usual 10-day period of being in unstable. This would result in a more stable Wine once lenny is finally released. (For the record, I've kept the 1.1.x releases out of unstable for the time being; they're currently only available in experimental.) The Debian changelog is wine (1.0.1-1) unstable; urgency=low . * New upstream release 1.0.1, released Oct 17, 2008. - This is a maintenance release from the 1.0 stable branch. It contains only translation updates and small bug fixes. * Recommend ttf-liberation, and changed msttcorefonts suggestion to ttf-mscorefonts-installer. Closes: #490861. * Removed application/x-zip-compressed from wine.desktop. Closes: #452957. * Updated build scripts for lenny branch. (The last entry is just a change of git branch in a couple of maintainer-only scripts, and does not affect the actual packaging at all.) If you want, you can see the list of upstream changes at http://www.winehq.org/?announce=1.0.1 Thank you for considering this. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: FlightGear migration
Neil McGovern skrev: On Fri, May 09, 2008 at 12:35:07PM +0200, Ove Kaaven wrote: These three packages must be migrated simultaneously because I changed the name of the simgear library package, so migrating simgear alone makes the other two packages uninstallable because simgear0 would no longer exist. And obviously migrating the other two packages would depend on the new simgear1.0.0... Yes, so they need a manual hint to say they need to go in together, which I've added. Thank you, they just migrated. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
FlightGear migration
The flightgear package trio (flightgear, simgear, fgfs-atlas) won't migrate to testing, apparently britney is caught in a loop here. These three packages must be migrated simultaneously because I changed the name of the simgear library package, so migrating simgear alone makes the other two packages uninstallable because simgear0 would no longer exist. And obviously migrating the other two packages would depend on the new simgear1.0.0... I don't see any reason these packages can't migrate, except for the migration scripts not handling the situation properly? Is there something I should do to make the migration happen? (I'm not subscribed, please Cc.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFH: Multiarch capable toolchain as release goal
Andreas Barth skrev: * Lennart Sorensen ([EMAIL PROTECTED]) [080415 22:26]: I suspect by the time a fully working multiarch is done, x86 won't need it anymore because everything will be fully 64bit. :) As Wine maintainer, I'd disagree with that. People, we want to release soon. Anyone is welcome to hack on feature in experimental, but please do not push for stuff to unstable which is expected to break stuff. If it wasn't important enough to push it during the last 12 months, it isn't important enough to hold up the release now. The way I understand it, they HAVE been pushing... and pushing... for a long time... against a nonresponsive binutils maintainer. This thread is just their latest, last-ditch effort since nothing else worked so far. But I could be wrong, I guess. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: extra, unused versions of gmime in sarge
søn, 22,.05.2005 kl. 00.10 -0700, skrev Steve Langasek: Having four versions of gmime in a stable release means a four-fold increase in the security team's workload if a security bug is found. (This is true even if the bug only applies to one version, because the security team still has to confirm whether the bug is present in each version.) Well, I already said the first one could be removed, so that leaves three to consider. To clarify the position: gmime: I can't imagine anyone using it gmime1: usage unknown, do people still use glib1.2 much? gmime2: stable branch of gmime gmime2.1: unstable branch of gmime So I'm not really opposed to removing gmime1, I just thought it was possible that someone would use it in favor of gmime2 because they haven't switched to glib2.0 yet. I don't personally care, though, after all I RFA-ed gmime once, but only got someone to put their name on gmime2 (so now Guus has it), not the older stuff... so if you drop my two versions, that just means less burden for me. As for the other two, Guus would know more...
Re: extra, unused versions of gmime in sarge
lør, 21,.05.2005 kl. 12.13 -0700, skrev Steve Langasek:
Hi Ove, Guus,
It looks like there are four versions of gmime in testing currently (gmime,
gmime1, gmime2, gmime2.1), only one of which is actually used by any other
packages. Is there any reason not to remove gmime{,1,2} from testing and
unstable?
To my knowledge, people using gmime don't generally seem to be making
official Debian packages out of their projects. So they may not
*actually* be unused, even if no official packages depend on them.
However, I'm fairly certain that the first one of them (gmime) would be
unused, so at least that one can probably safely be removed. But I'm
somewhat less certain of gmime1 (which is glib1.2-based) and gmime2
(which is glib2.0-based).
