| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
2.28.7 no longer installs codegen for Python 3:
https://gitlab.gnome.org/GNOME/pygobject/commit/2940d0c45c592c19196d4ab0d345ab27fca0f0a0
so our postInstall broke.
No need to rename the pth file either, as pygtk does not work on Python 3.
|
|
|
|
| |
https://download.gnome.org/sources/pygobject/2.28/pygobject-2.28.7.news
|
|
|
|
|
|
|
|
|
| |
treewide replacement of
stdenv.mkDerivation rec {
name = "*-${version}";
version = "*";
to pname
|
| |
|
| |
|
| |
|
|
|
|
| |
Only acts on one-line dependency lists.
|
| |
|
|
|
|
|
| |
This way all Python packages use the same function,
`buildPythonPackage`.
|
|
|
|
|
| |
${pygobject.name} now contains a python2- prefix resulting
in a broken symlink. this breaks pygtk and every depending application
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This one was already merged into release-16.09, so let's not have the
stable branch is ahead of master and confuse things. In addition to
that, currently we have an odd situation that master has less things
actually finished building than in staging.
Conflicts:
pkgs/data/documentation/man-pages/default.nix
|
| |
| |
| |
| |
| | |
It's "developer documentation", not "documentation developer" after
all.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In the pygobject package of pythonPackages the codegen python files are
executable and get wrapped, which causes pygtk to not build because it
uses the python program to execute them. The attached patch makes them
not executable so they do not get wrapped and cause pygtk to fail its
build.
From 931b7998658fa72323c9a76e7b336fe726a9cc61 Mon Sep 17 00:00:00 2001
From: Karn Kallio <kkallio@skami.org>
Date: Fri, 2 Sep 2016 15:30:42 -0400
Subject: [PATCH] pygobject: prevent wrapping of codegen/*.py files.
|
|/ |
|
|
|
|
| |
Build-tested on x86_64 Linux & Mac.
|
| |
|
| |
|
|
|
|
|
|
|
| |
... after auto-removing some kinds of files by default.
In some cases I let them be removed and in others I let them be put into
$docdev. That was more due to general indecisiveness on this question
than any reasons in the particular cases.
|
| |
|
|
|
|
| |
possible
|
|
|
|
| |
This fixes an issue with MyPaint: https://gna.org/bugs/?20400
|
| |
|
| |
|
|
|
|
| |
svn path=/nixpkgs/trunk/; revision=24763
|
|
|
|
| |
svn path=/nixpkgs/trunk/; revision=24354
|
|
|
|
| |
svn path=/nixpkgs/trunk/; revision=23616
|
|
|
|
|
|
|
|
|
|
|
| |
a worthy goal to move the Python packages that are currently in
all-packages.nix into a single attribute set, but this doesn't
require moving python-packages.nix or the other changes made to that
file. The Python packages in all-packages.nix should simply be
moved to python-packages.nix, and ideally changed to use
buildPythonPackage.
svn path=/nixpkgs/trunk/; revision=21196
|
|
|
|
|
|
|
|
|
| |
- cleanup python libraries:
* moving all python libraries into a attr set into a directory
so that expressions can be used for both: python 2.5 and 2.6 easily
* disabling packages which don't build
svn path=/nixpkgs/trunk/; revision=21142
|
|
|
|
|
|
| |
With a newer glib, I could have used a newer pyobject.
svn path=/nixpkgs/trunk/; revision=20962
|
|
svn path=/nixpkgs/trunk/; revision=8665
|