Skip to content

Commit

Permalink
redshift: fix redshift-gtk, autoreconfHook
Browse files Browse the repository at this point in the history
  • Loading branch information
lukateras committed Jan 16, 2018
1 parent 9d57972 commit 7d70261
Show file tree
Hide file tree
Showing 3 changed files with 88 additions and 50 deletions.
51 changes: 51 additions & 0 deletions pkgs/applications/misc/redshift/575.patch
@@ -0,0 +1,51 @@
From 467156efccc5e36a36bec8c0b64cc5a70f14d5ed Mon Sep 17 00:00:00 2001
From: Yegor Timoshenko <yegortimoshenko@riseup.net>
Date: Tue, 16 Jan 2018 11:43:46 +0000
Subject: [PATCH] Fix Autoconf script

gettext/intltool macros are not used correctly, see:
https://bugs.launchpad.net/inkscape/+bug/1418943
---
bootstrap | 6 +-----
configure.ac | 5 +----
2 files changed, 2 insertions(+), 9 deletions(-)

diff --git a/bootstrap b/bootstrap
index 0599cf5..40b1dca 100755
--- a/bootstrap
+++ b/bootstrap
@@ -1,7 +1,3 @@
#!/bin/sh

-# change to root directory
-cd $(dirname "$0")
-
-autopoint --force && \
- AUTOPOINT="intltoolize --automake --copy" autoreconf --force --install --verbose
+autoreconf --force --install && intltoolize
diff --git a/configure.ac b/configure.ac
index be0b51a..a2e7c42 100644
--- a/configure.ac
+++ b/configure.ac
@@ -17,6 +17,7 @@ AC_PROG_OBJC # For macOS support modules
AC_LANG([C])

AC_PROG_INTLTOOL([0.50])
+AC_SUBST(LIBINTL)

AC_CANONICAL_HOST

@@ -51,10 +52,6 @@ AC_COMPILE_IFELSE([AC_LANG_PROGRAM([])], [
])
AC_LANG_POP([Objective C])

-# Checks for libraries.
-AM_GNU_GETTEXT_VERSION([0.17])
-AM_GNU_GETTEXT([external])
-
GETTEXT_PACKAGE=redshift
AC_SUBST(GETTEXT_PACKAGE)
AC_DEFINE_UNQUOTED(GETTEXT_PACKAGE, "$GETTEXT_PACKAGE", [Package name for gettext])
--
2.15.1

85 changes: 36 additions & 49 deletions pkgs/applications/misc/redshift/default.nix
@@ -1,68 +1,55 @@
{ fetchurl, stdenv, gettext, intltool, makeWrapper, pkgconfig
, geoclue2
, guiSupport ? true, hicolor_icon_theme, librsvg, gtk3, python, pygobject3, pyxdg
, drmSupport ? true, libdrm
, randrSupport ? true, libxcb
, vidModeSupport ? true, libX11, libXxf86vm
}:
{ stdenv, fetchFromGitHub, fetchurl, autoconf, automake, gettext, intltool
, libtool, pkgconfig, wrapGAppsHook, wrapPython, geoclue2, gobjectIntrospection
, gtk3, python, pygobject3, pyxdg, libdrm, libxcb }:

let
mkFlag = flag: name: if flag
then "--enable-${name}"
else "--disable-${name}";
in
stdenv.mkDerivation rec {
name = "redshift-${version}";
version = "1.11";

src = fetchurl {
sha256 = "0ngkwj7rg8nfk806w0sg443w6wjr91xdc0zisqfm5h2i77wm1qqh";
url = "https://github.com/jonls/redshift/releases/download/v${version}/redshift-${version}.tar.xz";
src = fetchFromGitHub {
owner = "jonls";
repo = "redshift";
rev = "v${version}";
sha256 = "0jfi4wqklqw2rm0r2xwalyzir88zkdvqj0z5id0l5v20vsrfiiyj";
};

buildInputs = [ geoclue2 ]
++ stdenv.lib.optionals guiSupport [ hicolor_icon_theme librsvg gtk3
python pygobject3 pyxdg ]
++ stdenv.lib.optionals drmSupport [ libdrm ]
++ stdenv.lib.optionals randrSupport [ libxcb ]
++ stdenv.lib.optionals vidModeSupport [ libX11 libXxf86vm ];

This comment has been minimized.

Copy link
@grahamc

grahamc Jan 16, 2018

Member

What happened to all these various supports?

This comment has been minimized.

Copy link
@lukateras

lukateras Jan 16, 2018

Author Member

These pull in individual X11 libraries, which doesn't seem to be helpful, because all libraries are required to run X server anyway. And disabling most of these is not well supported upstream.

The only flag that makes sense is GUI support, to drop GTK+3 out of the closure, but even in that case, the complexity that is brought in to support this case (incl. listing individual X libraries) doesn't seem to be warranted, especially given that it's unlikely there is anyone who has a desktop system closure that doesn't pull in GTK+3.

nativeBuildInputs = [ gettext intltool makeWrapper pkgconfig ];
patches = [
# https://github.com/jonls/redshift/pull/575
./575.patch

This comment has been minimized.

Copy link
@grahamc

grahamc Jan 16, 2018

Member

Please use fetchpatch instead of checking the patch in to nixpkgs.

This comment has been minimized.

Copy link
@lukateras

lukateras Jan 16, 2018

Author Member

It's my own patch, and I consider my fork to be ephemeral, meaning the link to the commit won't last for very long.

This comment has been minimized.

Copy link
@grahamc

grahamc Jan 16, 2018

Member

You can use this URL, it will remain available I think: https://github.com/jonls/redshift/commit/467156efccc5e36a36bec8c0b64cc5a70f14d5ed.patch

This comment has been minimized.

Copy link
@lukateras

lukateras Jan 16, 2018

Author Member

I am not so sure: it's very likely that I will force-push over this branch (to incorporate upstream feedback) and the commit will eventually get garbage collected.

];

configureFlags = [
(mkFlag guiSupport "gui")
(mkFlag drmSupport "drm")
(mkFlag randrSupport "randr")
(mkFlag vidModeSupport "vidmode")
nativeBuildInputs = [
autoconf
automake
gettext
intltool
libtool
pkgconfig
wrapGAppsHook
wrapPython
];

enableParallelBuilding = true;
buildInputs = [
geoclue2
gobjectIntrospection
gtk3
libdrm
libxcb
python
];

preInstall = stdenv.lib.optionalString guiSupport ''
substituteInPlace src/redshift-gtk/redshift-gtk \
--replace "/usr/bin/env python3" "${python}/bin/${python.executable}"
'';
postInstall = stdenv.lib.optionalString guiSupport ''
wrapProgram "$out/bin/redshift-gtk" \
--set GDK_PIXBUF_MODULE_FILE "$GDK_PIXBUF_MODULE_FILE" \
--prefix PYTHONPATH : "$PYTHONPATH" \
--prefix GI_TYPELIB_PATH : "$GI_TYPELIB_PATH" \
--prefix XDG_DATA_DIRS : "$out/share:${hicolor_icon_theme}/share"
pythonPath = [ pygobject3 pyxdg ];

install -Dm644 {.,$out/share/doc/redshift}/redshift.conf.sample
'';
preConfigure = "./bootstrap";
postFixup = "wrapPythonPrograms";

enableParallelBuilding = true;

meta = with stdenv.lib; {
description = "Gradually change screen color temperature";
longDescription = ''
The color temperature is set according to the position of the
sun. A different color temperature is set during night and
daytime. During twilight and early morning, the color
temperature transitions smoothly from night to daytime
temperature to allow your eyes to slowly adapt.
'';

This comment has been minimized.

Copy link
@grahamc

grahamc Jan 16, 2018

Member

What happened to the longDescription?

This comment has been minimized.

Copy link
@lukateras

lukateras Jan 16, 2018

Author Member

It is confusing, verbose, and not very descriptive. It is a common problem with long descriptions. Also, the aspect of the program described in this long description is only one capability of the program, there is also an -O flag that allows just to set the color temperature.

This comment has been minimized.

Copy link
@grahamc

grahamc Jan 16, 2018

Member

This long description is correctly taken from the project itself, "Project Description" here: http://jonls.dk/redshift/

please restore this

This comment has been minimized.

Copy link
@lukateras

lukateras Jan 16, 2018

Author Member

The first line was truncated that set the context. I've added it and restored the rest of the text in fccaa2a.

description = "Screen color temperature manager";
license = licenses.gpl3Plus;
homepage = http://jonls.dk/redshift;
platforms = platforms.linux;
maintainers = with maintainers; [ mornfall nckx ];
};
};
}
2 changes: 1 addition & 1 deletion pkgs/top-level/all-packages.nix
Expand Up @@ -18801,7 +18801,7 @@ with pkgs;
};

redshift = callPackage ../applications/misc/redshift {
inherit (python3Packages) python pygobject3 pyxdg;
inherit (python3Packages) python pygobject3 pyxdg wrapPython;
};

redshift-plasma-applet = libsForQt5.callPackage ../applications/misc/redshift-plasma-applet { };
Expand Down

8 comments on commit 7d70261

@grahamc
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems like a lot of change to be submitted right to master and without involvement of the maintainers.

@lukateras
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It has been virtually broken for the last few weeks, since @jtojnar (rightfully) stopped gobjectIntrospection propagation. It has also been last updated on Oct 1, 2016, and the last time any of the maintainers specified for the package touched it was more than two years ago.

@grahamc
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, the package worked since then, and even now doesn't have a new version. A few weeks isn't so long to wait, especially since unstable hasn't been updating reliably for a few weeks as well.

@grahamc
Copy link
Member

@grahamc grahamc commented on 7d70261 Jan 16, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the future, please don't push such big changes to packages not your own directly to master. Send PRs instead and ping maintainers to give them an opportunity to take a look and submit feedback. Additionally, we have a strong preference for not embedding patches.

When updating your PR with an upstream project, don't force push until the end when the patch is about to be accepted. This way, it is both easier for upstream to review your changes to your patch, and you can continue using fetchpatch here in accordance to the project guidelines.

Additionally, quiet pushes to nixpkgs isn't an appropriate way to debate the semantics and meaning of what longDescription is for. If you think the meaning and intention behind longDescription isn't correct, we could have this discussion on the mailing list, #nixos, #nixos-dev, or an RFC process.

@lukateras
Copy link
Member Author

@lukateras lukateras commented on 7d70261 Jan 16, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the future, please don't push such big changes to packages not your own directly to master. Send PRs instead and ping maintainers to give them an opportunity to take a look and submit feedback.

I disagree that this is a big change (it's stylistic in nature to improve maintainability + a crucial fix, and touches only a minor package that doesn't have dependents), and I disagree that it would make sense to ping maintainers (@nckx seeemingly has moved on to Guix, and @mornfall didn't commit to any project for the last three years).

Additionally, we have a strong preference for not embedding patches. When updating your PR with an upstream project, don't force push until the end when the patch is about to be accepted. This way, you can continue using fetchpatch here in accordance to the project guidelines.

I disagree, this leaves older Nixpkgs versions broken. This is not the correct way to do that. The only patches that are safe to point to are those incorporated into master.

This approach also cripples upstreaming effort (not force-pushing/squashing changes might cause upstream to ask to force-push, creating an additional feedback roundtrip) and has a weak link (myself) that influences whether Nixpkgs is going to be broken or not, in a very underhanded and implicit way. Also, there would be no debate on this if I didn't open a pull request: originally I didn't plan to.

Additionally, quiet pushes to nixpkgs isn't an appropriate way to debate the semantics and meaning of what longDescription is for. If you think the meaning and intention behind longDescription isn't correct, we could have this discussion on the mailing list, #nixos, #nixos-dev, or an RFC process.

This is not about longDescription semantics, this is about this specific description. It is bad and not descriptive. I don't think there should be a pull request (or RFC!) every time someone changes descriptions, that seems to be a lot of overhead.

@globin
Copy link
Member

@globin globin commented on 7d70261 Jan 16, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree for most of the points with @grahamc..

We consistently pull in patches from github with fetchpatch and this is intentional. we don't want to carry too many patches around in our repository and especially if you have written the patch (opened the PR), you obviously should be aware of deleting stuff on github, although I'm quite sure that commits in PRs are preserved by Github even if you remove your fork, also for released nixos versions we cache all sources.

Also the longDescription is from upstream and it explains the use of redshift quite thoroughly. I don't see any reason to remove it.

Also redshift: fix redshift-gtk, autoreconfHook in the commit messages implies you know about the autoreconfHook, why aren't you using it? If there is a reason this should be included in the commit message which could be more descriptive.

Also since this commit obviously has potential for needing discussion it, I too think it should go through a PR, as should most commits, that do not only bump a version or fix trivialities.

@lukateras
Copy link
Member Author

@lukateras lukateras commented on 7d70261 Jan 16, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We consistently pull in patches from github with fetchpatch and this is intentional. we don't want to carry too many patches around in our repository and especially if you have written the patch (opened the PR), you obviously should be aware of deleting stuff on github, although I'm quite sure that commits in PRs are preserved by Github even if you remove your fork, also for released nixos versions we cache all sources.

I do know about this policy, but patches are rarely taken from a pull request, most often from a master branch (agreed upon, but unreleased).

I think it's ephemeral and would be picked up by git gc: https://help.github.com/articles/removing-sensitive-data-from-a-repository/

Surely patch is cached, but not for long. I'm not comfortable with including it so far, having read GitHub documentation. I'd like to be proven wrong.

There are no caches for intermediate unstable versions, and if my concerns are valid, it would break sooner than in several months.

Also the longDescription is from upstream and it explains the use of redshift quite thoroughly. I don't see any reason to remove it.

The real problem that made it (in my opinion) non-cohesive is that description was truncated from both sides, and especially the first line was important for setting the context (it is "Redshift adjusts the color temperature according to the position of the sun").

Also redshift: fix redshift-gtk, autoreconfHook in the commit messages implies you know about the autoreconfHook, why aren't you using it? If there is a reason this should be included in the commit message which could be more descriptive.

I agree the commit message could be better: autoreconfHook should be autoreconf, because upstream uses bootstrap script that calls autoreconf.

Also since this commit obviously has potential for needing discussion it, I too think it should go through a PR, as should most commits, that do not only bump a version or fix trivialities.

It was not evident to me that there is a potential for discussion, otherwise I would not have pushed it to master. This is a cleanup and a fix. I've seen both cleanups and fixes committed directly to master. What exactly constitutes a change that should go through review process?

The only such change that I see here is that it will break configurations that override *Support attributes. If that's the reason why it should be opened as a pull request, I will accept it. But I should note that this is not the current policy and patches that remove attributes are regularly committed directly to master, and all patches that remove attributes from arg attrset are potentially breaking.

I'm still rather confused why this patch is so controversial, because I've seen a few patches of similar (or sometimes, much larger) scope being pushed to master, that didn't cause any discussion. I won't be able to point right away due to the way pull requests change history.

I want to reiterate that this package has been broken, and abandoned, most of the changes are cosmetic, this is a minor package, and even the included patch is small (1318 bytes).

Also, I'm not trying to be dismissive: I'm trying to understand the concern with this patch.

@nckx
Copy link
Member

@nckx nckx commented on 7d70261 Jan 16, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

disagree that it would make sense to ping maintainers (@nckx seeemingly has moved on to Guix)

True, and irrelevant. Here I am.

I've seen a few patches of similar (or sometimes, much larger) scope being pushed to master, that didn't cause any discussion.

Ditto: this one did.

I'm trying to understand the concern with this patch.

It should have been submitted for review. It's non-trivial, non-obvious (autoreconf), opinionated (removing *Support), and just wrong (removing longDescription). All these things could have been explained and documented and merged with a few small improvements.

That said: thank you for taking care of this package, @yegortimoshenko!

Please sign in to comment.