jiebi/CodeConvo huggingface dataset:
Code change:
, (nixos-19.09, nixos-unstable) Scanned versions: nixos-19.09: ; nixos-unstable: . May contain false positives.
CVE-2019-: Fixed at version 0.60.8 (nixos-19.09, nixos-20.03, nixos-unstable).

Related discussion:
text: in stdenv.mkDerivation rec { <del> name = "aspell-0.60.6.1"; </del> <ins> name = "aspell-0.60.8"; </ins> src = fetchurl { url = "mirror://gnu/aspell/${name}.tar.gz"; <del> sha256 = "1qgn5psfyhbrnap275xjfrzppf5a83fb67gpql0kfqv37al869gm"; </del> <ins> sha256 = "1wi60ankalmh8ds7nplz434jd7j94gdvbahdwsr539rlad8pxdzr"; </ins> }; <del> patches = [ (fetchpatch { # remove in >= 0.60.7 name = "gcc-7.patch"; url = "https://github.com/GNUAspell/aspell/commit/8089fa02122fed0a.diff"; sha256 = "1b3p1zy2lqr2fknddckm58hyk95hw4scf6hzjny1v9iaic2p37ix"; }) (fetchpatch { name = "CVE-2019-17544.patch"; url = "https://github.com/GNUAspell/aspell/commit/80fa26c74279fced8d778351cff19d1d8f44fe4e.patch"; sha256 = "0k5dnh8gcb7chnyx7jgkksqmz2hm05hmrvcd0znsfib975pvp4rg"; }) ] ++ stdenv.lib.optional searchNixProfiles ./data-dirs-from-nix-profiles.patch; </del> <ins> patches = stdenv.lib.optional searchNixProfiles ./data-dirs-from-nix-profiles.patch; </ins> postPatch = '' patch interfaces/cc/aspell.h < ${./clang.patch} ''; <del> nativeBuildInputs = [ perl ]; </del> <ins> buildInputs = [ perl ]; </ins> doCheck = true;
Code change:
, (nixos-19.09, nixos-unstable) (nixos-19.09, nixos-unstable) (nixos-19.09, nixos-unstable) (nixos-19.09, nixos-unstable) (nixos-19.09, nixos-unstable) (nixos-19.09, nixos-unstable) (nixos-19.09, nixos-unstable) (nixos-19.09, nixos-unstable) (nixos-19.09, nixos-unstable) Scanned versions: nixos-19.09: ; nixos-unstable: . May contain false positives.
See also: ,
09 updated in (staging ATM, but should get into channel within days). I trust the bump solves all these CVEs.

Related discussion:
text: # Media support MEDIA_CAMERA_SUPPORT? y MEDIA_RC_SUPPORT? y <ins> MEDIA_USB_SUPPORT y </ins> ${if kernelPlatform ? kernelExtraConfig then kernelPlatform.kernelExtraConfig else ""} ${extraConfig}
Code change:
Describe the bug git fails to build on darwin Metadata nixpkgs at Maintainer information:
cc
example hydra log: culprit failing tests:

Related discussion:
text: # As of 2.19.0, t5562 refers to #!/usr/bin/perl patchShebangs t/t5562/invoke-with-content-length.pl <ins> '' + stdenv.lib.optionalString stdenv.isDarwin '' # XXX: Some tests added in 2.24.0 fail. # Please try to re-enable on the next release. disable_test t7816-grep-binary-pattern </ins> '' + stdenv.lib.optionalString stdenv.hostPlatform.isMusl '' # Test fails (as of 2.17.0, musl 1.1.19) disable_test t3900-i18n-commit
Code change:
Nixpkgs has 0.11.6, the latest release is 0.11.8

Related discussion:
text: stdenv.mkDerivation rec { pname = "gnunet"; <del> version = "0.11.6"; </del> <ins> version = "0.11.8"; </ins> src = fetchurl { url = "mirror://gnu/gnunet/${pname}-${version}.tar.gz"; <del> sha256 = "1gspr1lh885sb9r2anh7bi4zan3zjqx33lpyhq9hm2g0n5ip187q"; </del> <ins> sha256 = "1zkmcq75sfr3iyg8rgxp9dbl7fwsvc1a71rc0vgisghcbrx1n7yj"; </ins> }; enableParallelBuilding = true;
Code change:
Describe the bug I'm installing send2trash Python lib from the unstable channel. It should be the 1.5.0 version, but it 1.4.2 in fact. To Reproduce Steps to reproduce the behavior: write the following: send2trash buld results: Expected behavior The expected result should be: Metadata system: host os: multi-user?: sandbox: version: nixpkgs: Link to the nix package

Related discussion:
text: owner = "hsoft"; repo = "send2trash"; rev = version; <del> sha256 = "1w502i5h8xaqf03g6h95h4vs1wqfv6kg925dn63phrwmg1hfz2xx"; </del> <ins> sha256 = "1c76zldhw2ay7q7r00nnzcampjz9lkqfcbzqpm0iqp5i6bmmv30v"; </ins> }; doCheck = !stdenv.isDarwin;
Code change:
Project description Cryptomator is an application providing client-side encryption for cloud storage. Metadata homepage URL: source URL: license: GPLv3 platforms: linux, darwin
Source URL:
Hello, I'm a bot and I thank you in the name of the community for opening this issue. To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human. The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it. If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use or on the relevant files to find them. Lastly, you can always ask for help at or at .
This is still relevant to me. There is currently no way to get transparent encryption on any cloud-drive.
guys, whoever is interested in cryptomator testing/reviewing are welcome: we absolutely need it for darwin platform as well?
Let's first get it merged for linux, we can then base on that and check if we can get darwin working too.

Related discussion:
text: criu = callPackage ../os-specific/linux/criu { }; <ins> cryptomator = callPackage ../tools/security/cryptomator { }; </ins> cryptsetup = callPackage ../os-specific/linux/cryptsetup { }; cramfsprogs = callPackage ../os-specific/linux/cramfsprogs { };
Code change:
, CVSSv3=9.8 (nixos-19.03, nixos-19.09, nixos-unstable) Scanned versions: nixos-19.03: ; nixos-19.09: ; nixos-unstable: . May contain false positives.
03 is out of support - we don't backport security fixes there anymore.
But this was also about nixos-unstable.
This was a grave mistake from your side. See

Related discussion:
text: sha256 = "0zp61axx93b7nrbsyhn2x4dnw7n9y6g4rys21hyqxk4khrnc2yr9"; }) ./CVE-2016-4912.patch <ins> ./CVE-2019-5544.patch </ins> ]; meta = with lib; {
Code change:
Describe the bug I have a NixOS installation with a very simple xserver configuration: When trying to rebuild with master I get an error: To Reproduce Steps to reproduce the behavior: my lines from the above Expected behavior The old configuration should continue to work unless I opt into Metadata Please run and paste the result. Maintainer information: This has to do with cc
Right, looks like there's a bug when constructing the legacy the session name from the legacy defaults. Specifically when only supplying a default for the window manager. Will fix.
IMHO, is only meant for mutable state like database schemata, that does not offer downgrade/rollback path. Abusing it for versioning option tree only adds complexity for little benefit, especially when we already employ other transition aids. Nevertheless, this was an oversight on my part. Something like this might fix it:
What is the proper way to update my configuration to the new system? Where should I look for that information? Are there release notes? I couldn't figure it out from
Yes, release notes are included in the pull request: Also the module system should give you upgrade instruction when we fix the oversight. Could you test the patch above?
Your patch fixes the issue for me.
Closing since this is fixed.
We still need to apply the patch to the nixpkgs.
Oops, thought this was
Yeah, I just looked up that one, but it actually predates me filing the issue and it's currently the latest commit for the file.

Related discussion:
text: ''; dmDefault = cfg.desktopManager.default; <ins> # fallback default for cases when only default wm is set dmFallbackDefault = if dmDefault != null then dmDefault else "none"; </ins> wmDefault = cfg.windowManager.default; <del> defaultSessionFromLegacyOptions = concatStringsSep "+" (filter (s: s != null) ([ dmDefault ] ++ optional (wmDefault != "none") wmDefault)); </del> <ins> defaultSessionFromLegacyOptions = dmFallbackDefault + optionalString (wmDefault != null && wmDefault != "none") "+${wmDefault}"; </ins> in
Code change:
Describe the bug I have a NixOS installation with a very simple xserver configuration: When trying to rebuild with master I get an error: To Reproduce Steps to reproduce the behavior: my lines from the above Expected behavior The old configuration should continue to work unless I opt into Metadata Please run and paste the result. Maintainer information: This has to do with cc
Right, looks like there's a bug when constructing the legacy the session name from the legacy defaults. Specifically when only supplying a default for the window manager. Will fix.
IMHO, is only meant for mutable state like database schemata, that does not offer downgrade/rollback path. Abusing it for versioning option tree only adds complexity for little benefit, especially when we already employ other transition aids. Nevertheless, this was an oversight on my part. Something like this might fix it:
What is the proper way to update my configuration to the new system? Where should I look for that information? Are there release notes? I couldn't figure it out from
Yes, release notes are included in the pull request: Also the module system should give you upgrade instruction when we fix the oversight. Could you test the patch above?
Your patch fixes the issue for me.
Closing since this is fixed.
We still need to apply the patch to the nixpkgs.
Oops, thought this was
Yeah, I just looked up that one, but it actually predates me filing the issue and it's currently the latest commit for the file.

Related discussion:
text: { c = wmDefault; t = "- services.xserver.windowManager.default"; } ]))} Please use <del> services.xserver.displayManager.defaultSession = "${concatStringsSep "+" (filter (s: s != null) [ dmDefault wmDefault ])}"; </del> <ins> services.xserver.displayManager.defaultSession = "${defaultSessionFromLegacyOptions}"; </ins> instead. '' ];
Code change:
Describe the bug I just tried to update my system today. It updated Flexget from 3.0.31 to 3.1.11. Installation went smooth but flexget ultimatively crashes when running. To Reproduce Steps to reproduce the behavior: flexget it it Expected behavior No crash Actual behavior Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(hyper): channels(root): nixpkgs: Maintainer information:

Related discussion:
text: buildPythonPackage rec { pname = "loguru"; <del> version = "0.4.0"; </del> <ins> version = "0.4.1"; </ins> disabled = isPy27; src = fetchPypi { inherit pname version; <del> sha256 = "d5ddf363b7e0e562652f283f74a89bf35601baf16b70f2cd2736a2f8c6638748"; </del> <ins> sha256 = "a6101fd435ac89ba5205a105a26a6ede9e4ddbb4408a6e167852efca47806d11"; </ins> }; checkInputs = [ pytestCheckHook colorama ]; disabledTests = [ "test_time_rotation_reopening" "test_file_buffering" ] <del> ++ stdenv.lib.optionals stdenv.isDarwin [ "test_rotation_and_retention" "test_rotation_and_retention_timed_file" "test_renaming" ]; </del> <ins> ++ stdenv.lib.optionals stdenv.isDarwin [ "test_rotation_and_retention" "test_rotation_and_retention_timed_file" "test_renaming" "test_await_complete_inheritance" ]; </ins> meta = with stdenv.lib; { homepage = https://github.com/Delgan/loguru;
Code change:
Describe the bug See This is because vmTools.diskImageFuns.debian9i386 doesn't build
Hello, I'm a bot and I thank you in the name of the community for opening this issue. To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human. The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it. If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use or on the relevant files to find them. Lastly, you can always ask for help at or at .
Closing since indicates that it fixed this.

Related discussion:
text: hashed-mirrors = connect-timeout = 1 ''; <ins> # save some memory documentation.enable = false; </ins> }; # /etc/nixos/configuration.nix for the vm configFile = pkgs.writeText "configuration.nix"  ''
Code change:
Describe the bug See This is because vmTools.diskImageFuns.debian9i386 doesn't build
Hello, I'm a bot and I thank you in the name of the community for opening this issue. To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human. The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it. If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use or on the relevant files to find them. Lastly, you can always ask for help at or at .
Closing since indicates that it fixed this.

Related discussion:
text: name = "debian-9.8-stretch-i386"; fullName = "Debian 9.8 Stretch (i386)"; packagesList = fetchurl { <del> url = http://snapshot.debian.org/archive/debian/20190503T090946Z/dists/stretch/main/binary-i386/Packages.xz; sha256 = "1dr3skl35iyj85qlc33lq4whippbqf327vnbcyfqqrv6h86k68mw"; </del> <ins> url = http://snapshot.debian.org/archive/debian/20200301T030401Z/dists/stretch/main/binary-i386/Packages.xz; sha256 = "1jglr1d1jys3xddp8f7w9j05db39fah8xy4gfkpqbd1b5d2caslz"; </ins> }; urlPrefix = mirror://debian; packages = commonDebianPackages;
Code change:
The soundfont that is packaged in is no longer available. The URL in that file is , but that page says: "Sorry, this is a wrong download link.". No packages depend on this package.

Related discussion:
text: name = "Fluid-3"; src = fetchurl { <del> url = "http://www.musescore.org/download/fluid-soundfont.tar.gz"; </del> <ins> url = "https://ftp.osuosl.org/pub/musescore/soundfont/fluid-soundfont.tar.gz"; </ins> sha256 = "1f96bi0y6rms255yr8dfk436azvwk66c99j6p43iavyq8jg7c5f8"; };
Code change:
On current master (). Fails with See also the . Additional context The hscolour derivation mentioned here does not contain in its . It seems sufficient to make be a propagated build input for , after doing so I can build ghc itself. There's a lot of Metadata Maintainer information:
Can you send a PR fixing this?
Done, see
[ ] port to
Since this issue was opened the situation has changed. There's still no ghc on aarch64, but now it fails due to [the lack of aarch64 support][] in (aka ). [the lack of aarch64 support]:
After PR the default ghc builds for aarch64 (, ATM only in branch).

Related discussion:
text: { stdenv, substituteAll , fetchurl, perl, gcc, llvm , ncurses5, gmp, glibc, libiconv <ins> , llvmPackages </ins> }: # Prebuilt only does native assert stdenv.targetPlatform == stdenv.hostPlatform; let <ins> useLLVM = !stdenv.targetPlatform.isx86; </ins> libPath = stdenv.lib.makeLibraryPath ([ ncurses5 gmp ] ++ stdenv.lib.optional (stdenv.hostPlatform.isDarwin) libiconv);
Code change:
On current master (). Fails with See also the . Additional context The hscolour derivation mentioned here does not contain in its . It seems sufficient to make be a propagated build input for , after doing so I can build ghc itself. There's a lot of Metadata Maintainer information:
Can you send a PR fixing this?
Done, see
[ ] port to
Since this issue was opened the situation has changed. There's still no ghc on aarch64, but now it fails due to [the lack of aarch64 support][] in (aka ). [the lack of aarch64 support]:
After PR the default ghc builds for aarch64 (, ATM only in branch).

Related discussion:
text: or (throw "cannot bootstrap GHC on this platform")); nativeBuildInputs = [ perl ]; <del> buildInputs = stdenv.lib.optionals (stdenv.targetPlatform.isAarch32 || stdenv.targetPlatform.isAarch64) [ llvm ]; </del> <ins> propagatedBuildInputs = stdenv.lib.optionals useLLVM [ llvmPackages.llvm ]; </ins> # Cannot patchelf beforehand due to relative RPATHs that anticipate # the final install location/
Code change:
Describe the bug The recent Haskell generic-builder changes for Darwin (in particular according to bisect) have broken . To Reproduce from a nixpkgs at or later on Darwin. This fails with . Additional context is a pure Haskell package, that depends on , which is what actually uses the C dynamic library. So the problem seems to be that fails to include the C library in its closure. Interestingly, this C library has filename not , even though it looks exactly like a dylib as far as I can tell (I'm not expert in macOS linking): So I can see why would fail to be included into by . However, I don't see why broke it. Nothing to do with the C or Haskell packages involved has changed for months. Updating the generic-builder to include as well as files does fix the problem for me, and seems benign, so I'll submit a PR for that. But I don't feel I understand everything going on here, so I'm opening the issue in case more qualified folks can identify a better root cause fix. Metadata system: host os: multi-user?: sandbox: version: channels(simon): nixpkgs: Maintainer information: Ping from the original changes - thanks for all your efforts!
Just noting here that there is some useful discussion .

Related discussion:
text: done for d in $(grep '^dynamic-library-dirs:' "$packageConfDir"/* | cut -d' ' -f2- | tr ' ' 'n' | sort -u); do <del> for lib in "$d/"*.dylib; do </del> <ins> for lib in "$d/"*.{dylib,so}; do </ins> ln -s "$lib" "$dynamicLinksDir" done done
Code change:
Describe the bug I have installed the du-dust package by attribute name (because if I install by name I get the wrong package), but when I run nix-env -u it gets swapped out for an entirely different dust package. To Reproduce Steps to reproduce the behavior: Expected behavior I would expect the du-dust package to be upgraded if a new version is available, no-op otherwise. Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(frijters): nixpkgs: Maintainer information: Maybe ?
Thanks!

Related discussion:
text: { stdenv, fetchFromGitHub, rustPlatform }: rustPlatform.buildRustPackage rec { <del> pname = "dust"; </del> <ins> pname = "du-dust"; </ins> version = "0.5.1"; src = fetchFromGitHub {
Code change:
Describe the bug I have installed the du-dust package by attribute name (because if I install by name I get the wrong package), but when I run nix-env -u it gets swapped out for an entirely different dust package. To Reproduce Steps to reproduce the behavior: Expected behavior I would expect the du-dust package to be upgraded if a new version is available, no-op otherwise. Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(frijters): nixpkgs: Maintainer information: Maybe ?
Thanks!

Related discussion:
text: ''; }; <del> cargoSha256 = "1sjzcawyg1xsi4xrx2zwnj8yavzph8k1wgxsffgp55wghzypafwl"; </del> <ins> cargoSha256 = "0s8z8cg9q0gfqm0ann8rkxwp5y25si97kgginh6b6lbnaai7y4fj"; </ins> doCheck = false;
Code change:
Describe the bug Attempting to start xpra fails with the following X server log: To Reproduce Steps to reproduce the behavior: run start :200

Related discussion:
text: <ins> --- a/src/dummy.h	2016-12-17 23:02:53.396287041 +0100 +++ b/src/dummy.h	2016-12-17 23:03:30.319616550 +0100 @@ -51,6 +51,7 @@ /* options */ OptionInfoPtr Options; Bool swCursor; +    Bool constantDPI; /* proc pointer */ CloseScreenProcPtr CloseScreen; xf86CursorInfoPtr CursorInfo; --- a/src/dummy_driver.c	2016-12-14 21:54:20.000000000 +0100 +++ b/src/dummy_driver.c	2016-12-17 23:04:59.916416126 +0100 @@ -17,6 +17,12 @@ /* All drivers using the mi colormap manipulation need this */ #include "micmap.h" +#ifdef RANDR +#include "randrstr.h" +#endif + +#include "windowstr.h" + /* identifying atom needed by magnifiers */ #include <X11/Xatom.h> #include "property.h" @@ -115,11 +121,15 @@ }; typedef enum { -    OPTION_SW_CURSOR +    OPTION_SW_CURSOR, +    OPTION_CONSTANT_DPI } DUMMYOpts; static const OptionInfoRec DUMMYOptions[] = { { OPTION_SW_CURSOR,	"SWcursor",	OPTV_BOOLEAN,	{0}, FALSE }, +#ifdef RANDR +    { OPTION_CONSTANT_DPI,	"ConstantDPI",	OPTV_BOOLEAN,	{0}, FALSE }, +#endif { -1,                  NULL,           OPTV_NONE,	{0}, FALSE } }; @@ -359,6 +369,7 @@ xf86ProcessOptions(pScrn->scrnIndex, pScrn->options, dPtr->Options); xf86GetOptValBool(dPtr->Options, OPTION_SW_CURSOR,&dPtr->swCursor); +    xf86GetOptValBool(dPtr->Options, OPTION_CONSTANT_DPI, &dPtr->constantDPI); if (device->videoRam != 0) { pScrn->videoRam = device->videoRam; @@ -639,10 +650,45 @@ return TRUE; } +const char *XDPY_PROPERTY = "dummy-constant-xdpi"; +const char *YDPY_PROPERTY = "dummy-constant-ydpi"; +static int get_dpi_value(WindowPtr root, const char *property_name, int default_dpi) +{ +    PropertyPtr prop; +    Atom type_atom = MakeAtom("CARDINAL", 8, TRUE); +    Atom prop_atom = MakeAtom(property_name, strlen(property_name), FALSE); + +    for (prop = wUserProps(root); prop; prop = prop->next) { +       if (prop->propertyName == prop_atom && prop->type == type_atom && prop->data) { +           int v = (int) (*((CARD32 *) prop->data)); +           if ((v>0) && (v<4096)) { +               xf86DrvMsg(0, X_INFO, "get_constant_dpi_value() found property "%s" with value=%in", property_name, (int) v); +               return (int) v; +           } +           break; +       } +    } +    return default_dpi; +} + /* Mandatory */ Bool DUMMYSwitchMode(SWITCH_MODE_ARGS_DECL) { +    SCRN_INFO_PTR(arg); +#ifdef RANDR +    DUMMYPtr dPtr = DUMMYPTR(pScrn); +    if (dPtr->constantDPI) { +        int xDpi = get_dpi_value(pScrn->pScreen->root, XDPY_PROPERTY, pScrn->xDpi); +        int yDpi = get_dpi_value(pScrn->pScreen->root, YDPY_PROPERTY, pScrn->yDpi); +        //25.4 mm per inch: (254/10) +        pScrn->pScreen->mmWidth = mode->HDisplay * 254 / xDpi / 10; +        pScrn->pScreen->mmHeight = mode->VDisplay * 254 / yDpi / 10; +        xf86DrvMsg(pScrn->scrnIndex, X_INFO, "mm(dpi %ix%i)=%ix%in", xDpi, yDpi, pScrn->pScreen->mmWidth, pScrn->pScreen->mmHeight); +        RRScreenSizeNotify(pScrn->pScreen); +        RRTellChanged(pScrn->pScreen); +    } +#endif return TRUE; } </ins>
Code change:
Describe the bug Attempting to start xpra fails with the following X server log: To Reproduce Steps to reproduce the behavior: run start :200

Related discussion:
text: <ins> --- xf86-video-dummy-0.3.6/src/dummy_driver.c	2014-11-05 19:24:02.668656601 +0700 +++ xf86-video-dummy-0.3.6.new/src/dummy_driver.c	2014-11-05 19:37:53.076061853 +0700 @@ -55,6 +55,9 @@ #include <X11/extensions/xf86dgaproto.h> #endif +/* Needed for fixing pointer limits on resize */ +#include "inputstr.h" + /* Mandatory functions */ static const OptionInfoRec *	DUMMYAvailableOptions(int chipid, int busid); static void     DUMMYIdentify(int flags); @@ -713,6 +716,26 @@ RRTellChanged(pScrn->pScreen); } #endif +    //ensure the screen dimensions are also updated: +    pScrn->pScreen->width = mode->HDisplay; +    pScrn->pScreen->height = mode->VDisplay; +    pScrn->virtualX = mode->HDisplay; +    pScrn->virtualY = mode->VDisplay; +    pScrn->frameX1 = mode->HDisplay; +    pScrn->frameY1 = mode->VDisplay; + +    //ensure the pointer uses the new limits too: +    DeviceIntPtr pDev; +    SpritePtr pSprite; +    for (pDev = inputInfo.devices; pDev; pDev = pDev->next) { +        if (pDev->spriteInfo!=NULL && pDev->spriteInfo->sprite!=NULL) { +            pSprite = pDev->spriteInfo->sprite; +            pSprite->hotLimits.x2 = mode->HDisplay; +            pSprite->hotLimits.y2 = mode->VDisplay; +            pSprite->physLimits.x2 = mode->HDisplay; +            pSprite->physLimits.y2 = mode->VDisplay; +        } +    } return TRUE; } </ins>