Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closure size WIP #11597

Merged
merged 4 commits into from
Jan 28, 2016
Merged

Closure size WIP #11597

merged 4 commits into from
Jan 28, 2016

Conversation

avnik
Copy link
Contributor

@avnik avnik commented Dec 10, 2015

Fix qtile, fvwm and subversion

@mention-bot
Copy link

By analyzing the blame information on this pull request, we identified @kamilchm, @iyzsong and @edolstra to be potential reviewers

@avnik
Copy link
Contributor Author

avnik commented Dec 10, 2015

I am and @lethalman decided to postpone this PR before master will be merged to closure-size, and I rebase stuff on it.

@vcunat
Copy link
Member

vcunat commented Jan 20, 2016

Ping. I pushed a tested version of closure-size with new staging in it. (All packages I use do build.)

@vcunat
Copy link
Member

vcunat commented Jan 20, 2016

And, in the meantime subversion started to build again, so it's possible some parts of this PR won't be needed anymore (and/or will conflict).

@avnik
Copy link
Contributor Author

avnik commented Jan 20, 2016

On Wed, Jan 20, 2016 at 10:51:22AM -0800, Vladimír Čunát wrote:

And, in the meantime subversion started to build again,
so it's possible some parts of this PR won't be needed
anymore (and/or will conflict).

I am not sure, if it was common problem, or it unbuildable on
my localhost only. Need to check it separately.

@vcunat
Copy link
Member

vcunat commented Jan 20, 2016

No, at the time of filing this PR I did experience svn build problems, but I do not anymore (for the same attribute).

@avnik
Copy link
Contributor Author

avnik commented Jan 20, 2016

On Wed, Jan 20, 2016 at 11:54:37AM -0800, Vladimír Čunát wrote:

No, at the time of filing this PR I did experience svn build
problems.

Can you tell what problems, and how you fix them?

@vcunat
Copy link
Member

vcunat commented Jan 20, 2016

It didn't build, but I don't remember the error exactly (it was months ago) and I don't know how it got fixed. Maybe I did pushe something to fix it or someone else did, but I just don't remember anymore :-)

@avnik
Copy link
Contributor Author

avnik commented Jan 20, 2016

On Wed, Jan 20, 2016 at 01:14:07PM -0800, Vladimír Čunát wrote:

It didn't build, but I don't remember exactly (it was months
ago) and I don't know how they got fixed. Maybe I did pushed
something to fix it or someone else did, but I just don't
remember anymore :-)

Or it just come from cache.
I will try to invalidate my local build (by adding space
somewhere) and look if it build or not.

@dezgeg
Copy link
Contributor

dezgeg commented Jan 25, 2016

Probably the subversion problem was caused by GCC 5 (which closure-size had but no longer seems to have) which had some changes in that area.

@avnik
Copy link
Contributor Author

avnik commented Jan 26, 2016

On Mon, Jan 25, 2016 at 03:51:01PM -0800, Tuomas Tynkkynen wrote:

Probably the subversion problem was caused by GCC 5 (which closure-size had but no longer seems to have) which had some changes in that area.

In my experiments it fixed by adding

CPPFLAGS="-P";

But not sure if it correct solution.

@avnik
Copy link
Contributor Author

avnik commented Jan 26, 2016

On Mon, Jan 25, 2016 at 03:51:01PM -0800, Tuomas Tynkkynen wrote:

Probably the subversion problem was caused by GCC 5 (which closure-size had but no longer seems to have) which had some changes in that area.

Some comment taken from my own unstaged commit:

Mysterious error "configure: error: failed to recognize APR_INT64_T_FMT on this platform" appeared,
usually it appears on OSX, not on linux. Openembedded's forum suggest
CPPFLAGS="-P" to fix it.

Short snippet from svn's autocrap illustrating problematic place:
140           if test "x$svn_cv_pycfmt_apr_int64_t" = "x"; then
141             AC_EGREP_CPP([MaTcHtHiS +\"lld\" +EnDeNd],
142                          [#include <apr.h>
143                           MaTcHtHiS APR_INT64_T_FMT EnDeNd],
144                          [svn_cv_pycfmt_apr_int64_t="L"])
145           fi

I think line numbering can smash this magic, so disable it with `-P`

@vcunat
Copy link
Member

vcunat commented Jan 26, 2016

The gcc switch back was done and explained in 9d13434. It didn't occur to me as a possible reason why it builds again.

@avnik
Copy link
Contributor Author

avnik commented Jan 27, 2016

Updated branch.
(remove svn stuff, fix build deps for syslog-ng)

@avnik
Copy link
Contributor Author

avnik commented Jan 27, 2016

@vcunat This one can be merged ;)

Next broken things: qtbase (via postgres's libpq and iodbc), and packages which contain only manpages (stdmanpage) -- but haven't any ideas how to fix them.

Any other packages which I can to fix/test to make whole closure-size merged?

@vcunat vcunat merged commit 6102094 into NixOS:closure-size Jan 28, 2016
vcunat added a commit that referenced this pull request Jan 28, 2016
@vcunat
Copy link
Member

vcunat commented Jan 28, 2016

qtbase linking to libpq should be fixed by 363f667. I don't see a connection between qt and iodbc in the nix expressions.

@vcunat
Copy link
Member

vcunat commented Jan 28, 2016

The stdman problem was that developer documentation (such as man3) is now stripped from packages by default or moved into .docdev if defined. I passed nixpkgs/pkgs/data/documentation files in c979012.

@avnik
Copy link
Contributor Author

avnik commented Jan 28, 2016

On Thu, Jan 28, 2016 at 04:39:18AM -0800, Vladimír Čunát wrote:

qtbase linking to libpq should be fixed by 363f667.
I don't see a connection between qt and iodbc in the nix
expressions.

I just see iodbc related error upper in log before libpq's one.

@vcunat
Copy link
Member

vcunat commented Jan 28, 2016

I expect it's an optional dependency that is never fulfilled on any of our branches.

@avnik
Copy link
Contributor Author

avnik commented Jan 28, 2016

On Thu, Jan 28, 2016 at 06:16:14AM -0800, Vladimír Čunát wrote:

I expect it's an optional dependency that is never fulfilled
on any of our branches.

Good.
@vcunat have we any issue(-s) with pending tasks to merge closure-size into master?

@vcunat
Copy link
Member

vcunat commented Jan 28, 2016

I'm updating merge blockers (in my opinion) at the top of that PR #7701.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants