jiebi/CodeConvo huggingface dataset:
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:33:33.279533389 +0100 +++ b/src/dummy.h	2016-12-17 23:33:56.695739166 +0100 @@ -69,7 +69,7 @@ int overlay_offset; int videoKey; int interlace; -    dummy_colors colors[256]; +    dummy_colors colors[1024]; pointer* FBBase; Bool        (*CreateWindow)() ;     /* wrapped CreateWindow */ Bool prop; --- a/src/dummy_driver.c	2016-12-17 23:33:47.446657886 +0100 +++ b/src/dummy_driver.c	2016-12-17 23:33:56.696739175 +0100 @@ -317,6 +317,7 @@ case 15: case 16: case 24: +        case 30: break; default: xf86DrvMsg(pScrn->scrnIndex, X_ERROR, @@ -331,8 +332,8 @@ pScrn->rgbBits = 8; /* Get the depth24 pixmap format */ -    if (pScrn->depth == 24 && pix24bpp == 0) -	pix24bpp = xf86GetBppFromDepth(pScrn, 24); +    if (pScrn->depth >= 24 && pix24bpp == 0) +	pix24bpp = xf86GetBppFromDepth(pScrn, pScrn->depth); /* * This must happen after pScrn->display has been set because @@ -623,7 +624,7 @@ if(!miCreateDefColormap(pScreen)) return FALSE; -    if (!xf86HandleColormaps(pScreen, 256, pScrn->rgbBits, +    if (!xf86HandleColormaps(pScreen, 1024, pScrn->rgbBits, DUMMYLoadPalette, NULL, CMAP_PALETTED_TRUECOLOR | CMAP_RELOAD_ON_MODE_SWITCH)) </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: <del> { stdenv, lib, fetchurl, callPackage, substituteAll, python3, pkgconfig </del> <ins> { stdenv, lib, fetchurl, callPackage, substituteAll, python3, pkgconfig, writeText </ins> , xorg, gtk3, glib, pango, cairo, gdk-pixbuf, atk , wrapGAppsHook, xorgserver, getopt, xauth, utillinux, which , ffmpeg_4, x264, libvpx, libwebp, x265
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: let inherit (python3.pkgs) cython buildPythonApplication; <del> xf86videodummy = callPackage ./xf86videodummy { }; </del> <ins> xf86videodummy = xorg.xf86videodummy.overrideDerivation (p: { patches = [ ./0002-Constant-DPI.patch ./0003-fix-pointer-limits.patch ./0005-support-for-30-bit-depth-in-dummy-driver.patch ]; }); xorgModulePaths = writeText "module-paths" '' Section "Files" ModulePath "${xorgserver}/lib/xorg/modules" ModulePath "${xorgserver}/lib/xorg/modules/extensions" ModulePath "${xorgserver}/lib/xorg/modules/drivers" ModulePath "${xf86videodummy}/lib/xorg/modules/drivers" EndSection ''; </ins> in buildPythonApplication rec { pname = "xpra"; version = "3.0.7";
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> # append module paths to xorg.conf postInstall = '' cat ${xorgModulePaths} >> $out/etc/xpra/xorg.conf ''; </ins> doCheck = false; enableParallelBuilding = true;
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: <del> --- 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; } </del>
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: <del> --- 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; } </del>
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: <del> --- a/src/dummy.h	2016-12-17 23:33:33.279533389 +0100 +++ b/src/dummy.h	2016-12-17 23:33:56.695739166 +0100 @@ -69,7 +69,7 @@ int overlay_offset; int videoKey; int interlace; -    dummy_colors colors[256]; +    dummy_colors colors[1024]; pointer* FBBase; Bool        (*CreateWindow)() ;     /* wrapped CreateWindow */ Bool prop; --- a/src/dummy_driver.c	2016-12-17 23:33:47.446657886 +0100 +++ b/src/dummy_driver.c	2016-12-17 23:33:56.696739175 +0100 @@ -317,6 +317,7 @@ case 15: case 16: case 24: +        case 30: break; default: xf86DrvMsg(pScrn->scrnIndex, X_ERROR, @@ -331,8 +332,8 @@ pScrn->rgbBits = 8; /* Get the depth24 pixmap format */ -    if (pScrn->depth == 24 && pix24bpp == 0) -	pix24bpp = xf86GetBppFromDepth(pScrn, 24); +    if (pScrn->depth >= 24 && pix24bpp == 0) +	pix24bpp = xf86GetBppFromDepth(pScrn, pScrn->depth); /* * This must happen after pScrn->display has been set because @@ -623,7 +624,7 @@ if(!miCreateDefColormap(pScreen)) return FALSE; -    if (!xf86HandleColormaps(pScreen, 256, pScrn->rgbBits, +    if (!xf86HandleColormaps(pScreen, 1024, pScrn->rgbBits, DUMMYLoadPalette, NULL, CMAP_PALETTED_TRUECOLOR | CMAP_RELOAD_ON_MODE_SWITCH)) </del>
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: <del> { stdenv, lib, fetchurl , xorgproto, xorgserver , pkgconfig }: with lib; stdenv.mkDerivation rec { version = "0.3.8"; suffix = "1"; name = "xpra-xf86videodummy-${version}-${suffix}"; builder = ../../../../servers/x11/xorg/builder.sh; src = fetchurl { url = "mirror://xorg/individual/driver/xf86-video-dummy-${version}.tar.bz2"; sha256 = "1fcm9vwgv8wnffbvkzddk4yxrh3kc0np6w65wj8k88q7jf3bn4ip"; }; patches = [ ./0002-Constant-DPI.patch ./0003-fix-pointer-limits.patch ./0005-support-for-30-bit-depth-in-dummy-driver.patch ]; nativeBuildInputs = [ pkgconfig ]; buildInputs = [ xorgproto xorgserver ]; meta = { description = "Dummy driver for Xorg with xpra patches"; homepage = https://xpra.org/trac/wiki/Xdummy; license = licenses.gpl2; platforms = platforms.unix; maintainers = with maintainers; [ numinit ]; }; } </del>
Code change:
Describe the bug Tribler does not have any desktop icons, and does not show up in any menus. There is a desktop file in But it's not being included by the desktop environment. Maintainer information:

Related discussion:
text: ${stdenv.lib.optionalString enablePlayer '' --prefix LD_LIBRARY_PATH : ${vlc}/lib ''} <ins> mkdir -p $out/share/applications $out/share/icons $out/share/man/man1 cp $out/Tribler/Main/Build/Ubuntu/tribler.desktop $out/share/applications/tribler.desktop cp $out/Tribler/Main/Build/Ubuntu/tribler_big.xpm $out/share/icons/tribler.xpm cp $out/Tribler/Main/Build/Ubuntu/tribler.1 $out/share/man/man1/tribler.1 </ins> ''; meta = with stdenv.lib; {
Code change:
Describe the bug On a ZFS-enabled 20.03 system: IMHO zed does not need the ability to send email by default. Also mariadb-connector should have a separate -dev output so that its doesn't end up in the system closure.
cc
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 .
Seems still important: And: And:
Adjusted to milestone 21.03. BTW, If someone wants to backport the fix it shouldn't cause any issues.
Took a stab at this in

Related discussion:
text: }; }; <del> services.zfs.zed.settings = mkOption { type = with types; attrsOf (oneOf [ str int bool (listOf str) ]); example = literalExample '' { ZED_DEBUG_LOG = "/tmp/zed.debug.log"; </del> <ins> services.zfs.zed = { enableMail = mkEnableOption "ZED's ability to send emails" // { default = cfgZfs.package.enableMail; }; </ins> <del> ZED_EMAIL_ADDR = [ "root" ]; ZED_EMAIL_PROG = "mail"; ZED_EMAIL_OPTS = "-s '@SUBJECT@' @ADDRESS@"; </del> <ins> settings = mkOption { type = with types; attrsOf (oneOf [ str int bool (listOf str) ]); example = literalExample '' { ZED_DEBUG_LOG = "/tmp/zed.debug.log"; </ins> <del> ZED_NOTIFY_INTERVAL_SECS = 3600; ZED_NOTIFY_VERBOSE = false; </del> <ins> ZED_EMAIL_ADDR = [ "root" ]; ZED_EMAIL_PROG = "mail"; ZED_EMAIL_OPTS = "-s '@SUBJECT@' @ADDRESS@"; </ins> <del> ZED_USE_ENCLOSURE_LEDS = true; ZED_SCRUB_AFTER_RESILVER = false; } ''; description = '' ZFS Event Daemon /etc/zfs/zed.d/zed.rc content See <citerefentry><refentrytitle>zed</refentrytitle><manvolnum>8</manvolnum></citerefentry> for details on ZED and the scripts in /etc/zfs/zed.d to find the possible variables ''; </del> <ins> ZED_NOTIFY_INTERVAL_SECS = 3600; ZED_NOTIFY_VERBOSE = false; ZED_USE_ENCLOSURE_LEDS = true; ZED_SCRUB_AFTER_RESILVER = false; } ''; description = '' ZFS Event Daemon /etc/zfs/zed.d/zed.rc content See <citerefentry><refentrytitle>zed</refentrytitle><manvolnum>8</manvolnum></citerefentry> for details on ZED and the scripts in /etc/zfs/zed.d to find the possible variables ''; }; </ins> }; };
Code change:
Describe the bug On a ZFS-enabled 20.03 system: IMHO zed does not need the ability to send email by default. Also mariadb-connector should have a separate -dev output so that its doesn't end up in the system closure.
cc
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 .
Seems still important: And: And:
Adjusted to milestone 21.03. BTW, If someone wants to backport the fix it shouldn't cause any issues.
Took a stab at this in

Related discussion:
text: (mkIf cfgZfs.enabled { assertions = [ { <ins> assertion = cfgZED.enableMail -> cfgZfs.package.enableMail; message = '' To allow ZED to send emails, ZFS needs to be configured to enable this. To do so, one must override the `zfs` package and set `enableMail` to true. ''; } { </ins> assertion = config.networking.hostId != null; message = "ZFS requires networking.hostId to be set"; }
Code change:
Describe the bug On a ZFS-enabled 20.03 system: IMHO zed does not need the ability to send email by default. Also mariadb-connector should have a separate -dev output so that its doesn't end up in the system closure.
cc
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 .
Seems still important: And: And:
Adjusted to milestone 21.03. BTW, If someone wants to backport the fix it shouldn't cause any issues.
Took a stab at this in

Related discussion:
text: }; services.zfs.zed.settings = { <del> ZED_EMAIL_PROG = mkDefault "${pkgs.mailutils}/bin/mail"; </del> <ins> ZED_EMAIL_PROG = mkIf cfgZED.enableMail (mkDefault "${pkgs.mailutils}/bin/mail"); </ins> PATH = lib.makeBinPath [ cfgZfs.package pkgs.coreutils
Code change:
Describe the bug On a ZFS-enabled 20.03 system: IMHO zed does not need the ability to send email by default. Also mariadb-connector should have a separate -dev output so that its doesn't end up in the system closure.
cc
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 .
Seems still important: And: And:
Adjusted to milestone 21.03. BTW, If someone wants to backport the fix it shouldn't cause any issues.
Took a stab at this in

Related discussion:
text: , libtirpc , nfs-utils , gawk, gnugrep, gnused, systemd <del> , smartmontools, sysstat, sudo , pkg-config </del> <ins> , smartmontools, enableMail ? false , sysstat, sudo, pkg-config </ins> # Kernel dependencies , kernel ? null
Code change:
Describe the bug On a ZFS-enabled 20.03 system: IMHO zed does not need the ability to send email by default. Also mariadb-connector should have a separate -dev output so that its doesn't end up in the system closure.
cc
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 .
Seems still important: And: And:
Adjusted to milestone 21.03. BTW, If someone wants to backport the fix it shouldn't cause any issues.
Took a stab at this in

Related discussion:
text: with lib; let <ins> smartmon = smartmontools.override { inherit enableMail; }; </ins> buildKernel = any (n: n == configFile) [ "kernel" "all" ]; buildUser = any (n: n == configFile) [ "user" "all" ];
Code change:
Describe the bug On a ZFS-enabled 20.03 system: IMHO zed does not need the ability to send email by default. Also mariadb-connector should have a separate -dev output so that its doesn't end up in the system closure.
cc
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 .
Seems still important: And: And:
Adjusted to milestone 21.03. BTW, If someone wants to backport the fix it shouldn't cause any issues.
Took a stab at this in

Related discussion:
text: ''; postFixup = let <del> path = "PATH=${makeBinPath [ coreutils gawk gnused gnugrep util-linux smartmontools sysstat ]}:$PATH"; </del> <ins> path = "PATH=${makeBinPath [ coreutils gawk gnused gnugrep util-linux smartmon sysstat ]}:$PATH"; </ins> in '' for i in $out/libexec/zfs/zpool.d/*; do sed -i '2i${path}' $i
Code change:
Describe the bug On a ZFS-enabled 20.03 system: IMHO zed does not need the ability to send email by default. Also mariadb-connector should have a separate -dev output so that its doesn't end up in the system closure.
cc
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 .
Seems still important: And: And:
Adjusted to milestone 21.03. BTW, If someone wants to backport the fix it shouldn't cause any issues.
Took a stab at this in

Related discussion:
text: outputs = [ "out" ] ++ optionals buildUser [ "lib" "dev" ]; <del> passthru.tests = if isUnstable then [ nixosTests.zfs.unstable ] else [ nixosTests.zfs.installer nixosTests.zfs.stable ]; </del> <ins> passthru = { inherit enableMail; tests = if isUnstable then [ nixosTests.zfs.unstable ] else [ nixosTests.zfs.installer nixosTests.zfs.stable ]; }; </ins> meta = { description = "ZFS Filesystem Linux Kernel module";