Commit
- Loading branch information
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -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 | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -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.
Sorry, something went wrong.
This comment has been minimized.
Sorry, something went wrong.
lukateras
Author
Member
|
||
nativeBuildInputs = [ gettext intltool makeWrapper pkgconfig ]; | ||
patches = [ | ||
# https://github.com/jonls/redshift/pull/575 | ||
./575.patch | ||
This comment has been minimized.
Sorry, something went wrong.
grahamc
Member
|
||
]; | ||
|
||
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.
Sorry, something went wrong.
This comment has been minimized.
Sorry, something went wrong.
lukateras
Author
Member
|
||
description = "Screen color temperature manager"; | ||
license = licenses.gpl3Plus; | ||
homepage = http://jonls.dk/redshift; | ||
platforms = platforms.linux; | ||
maintainers = with maintainers; [ mornfall nckx ]; | ||
}; | ||
}; | ||
} |
8 comments
on commit 7d70261
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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!
What happened to all these various supports?