bug#24993: System installer grows brittle with time

[Leo Famulari]

On Mon, Nov 28, 2016 at 08:45:39AM -0900, Christopher Howard wrote:
> I was able to make more progress with the --substitute-urls=... option
> you mentioned. However, later, when the system is building the
> gnupg-2.1.13 drv (I did not pass --fallback, but it still builds stuff)
> one of the 36 check tests fails ("tofu.test"), causing the build to fail.

It will build stuff if it can't find a substitute (not an error).
'--fallback' is only required when substitution fails (an error).

That particular test failure was a bug in GnuPG's test suite that we
worked around:

http://git.savannah.gnu.org/cgit/guix.git/commit/?id=d404a6f9711c8dcc1cc6cf55d8c07901aa450192

Code with an expiration date is very annoying!

It sounds like you will need to use `guix pull`.

What do others think? Should we mention `guix pull` in the installation
documentation?

I'm skeptical for reasons described upthread. I think the real bug is
that the installation image becomes brittle as time passes (so I changed
the subject of my reply).

Does anyone have ideas to mitigate this? Can we tweak the mirrors? Will
this become less pressing when we have more storage space and can store
substitutes for a longer period?

bug#22629: ‘guix pull’ and external dependencies

[Chris Marusich]

Hi Ludo`,

l...@gnu.org (Ludovic Courtès) writes:

> So I think what we need to do is for “guix pull-ng” to build and install
> a complete ‘guix’ package, and to manage it pretty much like other
> packages is managed, 

I think that's very reasonable.  It seems more intuitive than the
current way 'guix pull' works.  I suspect that managing the installed
version of Guix via the same Guix mechanisms that we use to manage any
other package might be the best, most intuitive solution.

Would it simplify the problem if we packaged the "Guix client stuff",
the "Guix daemon stuff", and maybe the "Guix package definition stuff"
separately?  Then a user could just install the "Guix client stuff"
package if she wanted to upgrade the Guix client tools, or the "Guix
package definition stuff" package if she wanted to get the latest
package definitions.

> except not in the user’s main profile (because that could lead to
> undesirable behavior, 

If we don't store Guix in the user's main profile, where would it go?  A
system profile (like in GuixSD)?  What if another user wants to run a
different version of Guix?  It might be nice to let them do that.

It's not clear to me why it's riskier to store Guix in a profile rather
than outside the profile (but still in the store via the
$HOME/.config/guix/latest symlink), which is what 'guix pull' does now.
You seem to think it's riskier; I'm curious to know more about why.

> where upgrading Guix creates a new generation, 

Why should upgrading Guix NOT create a new generation?  I thought that a
new profile generation would be created any time you upgrade a package,
and I thought that was a good thing because it facilitates easy,
transactional roll-back.  Perhaps I'm missing something.

> or, in theory, unrecoverable problems, where you cannot roll back
> because previous generations use an old Guix that does not understand
> the new manifest format.)

Why would a change in manifest format be unrecoverable?  It looks like
each profile generation contains a manifest file.  Assuming that the new
Guix functions well enough to perform roll back, couldn't we just roll
back to the previous profile generation, where we would have both (1)
the old profile's manifest file, and (2) the previous Guix, which
understands that format?  Since rolling back a profile is basically just
a symlink flip, I think the new Guix could probably do that even if it
didn't understand the old manifest format.

> The difficulty is that ./configure && make && make install in Guix takes
> some time, and we probably wouldn’t want to do that on each ‘guix pull’
> invocation (esp. with Guile 2.2’s compilation times.)
>
> So we may have to provide substitutes of Guix itself, and arrange so
> that ‘guix pull’ pulls up to a tag for which we have substitutes.

What if we had a special package version of Guix (e.g., "v0.11.0") which
we kept up to date via some mechanism?  Maybe something as simple as a
Git hook could help increase the likelihood of that version being
substitutable.  For example, we could have a Git hook that prevents
someone from checking in a change if the latest Git tag does not
correspond to a Guix package version.  Maybe we can do better.

I actually think it would be a good thing if we can run "guix pull"
without substitutes available.  But it should use a substitute by
default, and "build from source" should be a fallback mechanism that the
user has to explicitly request, just like when installing new packages.
That would help avoid unexpectedly long "guix pull" invocations.

-- 
Chris


signature.asc
Description: PGP signature

bug#25053: guix import nix does not work

[Ludovic Courtès]

ng0  skribis:

> I tried to import various packages from nixpkgs, from all kinds
> of levels of the repository, none successful.
>
> ng0@wasp ~$ export NIX_REMOTE=daemon
> ng0@wasp ~$ guix import nix ~/re-src/nixpkgs libreoffice^C
> ng0@wasp ~$ ls ~/re-src/nixpkgs/
> COPYING  default.nix  doc/  lib/  maintainers/  nixos/  pkgs/  README.md
> ng0@wasp ~$ guix import nix ~/re-src/nixpkgs pidgin
> In execvp of : No such file or directory

Oh indeed.  I didn’t notice because I was using ./pre-inst-env with a
valid value for ‘%nix-instantiate’ in (guix config).

Fixed in c062b1eb6c9d799f0015e26b14cd77eaf8d946dd.

Thanks!

Ludo’.

bug#25045: [Website] Packages page takes too long to load

[Ludovic Courtès]

Luis Felipe López Acevedo  skribis:

> On 2016-11-28 12:00, Alex Sassmannshausen wrote:
>> Hi Luis,
>>
>> Indeed, I had a first bash at solving this problem by providing a
>> set of
>> static html pages paginated by the first letter of the package name.
>>
>> I'm not particularly wedded to this solution, so if you feel strongly
>> about going another way, I'd be keen to hear/see about it.
>>
>> In the meantime, I'm open to testing/feedback.  I will unfortunately
>> not
>> be able to put work into this until at least Saturday/Sunday, as some
>> Perl work has higher priority at the moment.
>>
>> But let me know if you have questions or feedback!
>>
>> Best wishes,
>
> Hi, Alex :)
>
> The solution I had in mind includes an alphabetic index, and
> pagination as well. However, it includes a few more things, and would
> take some time to design and implement. So I think we should use your
> patch to fix the size issue as soon as possible.

I agree!

Alex, was there anything left to address?  If not, feel free to push.
:-)

> For what is worth, this is what I had in mind:
>
> /packages/
> First page of the list of packages. Packages listed here only provide
> a summary: package logo (if any), name, version, description, and an
> indicator if it has issues. This page also has filters to find
> packages (for now, alphabetic filter. In the future, category filter,
> and search box).
>
> /packages/page/N/
> Page N of the list of packages.
>
> /packages/a/
> First page of the list of packages whose name starts with A. Packages
> are presented the same way as in /packages/.
>
> /packages/a/page/N/
> Page N of the list of packages starting with letter A.
>
> /packages/icecat/X.Y.Z/
> Page with details about IceCat version X.Y.Z. It includes all the
> information about this package, including its issues (which are
> currently listed in a separate page along with the issues of other
> packages: /packages/issues.html). Including the issues of a package in
> its detail page could avoid having the current issues page grow too
> much, like the current Packages page.
>
> This static pagination and filtering would generate A LOT of pages,
> but of reasonable size for web browsers to load.

Sounds like a good plan as well, though that’s indeed a lot of web pages
for that rusty CVS repo to handle…

Medium-term, I think we should consider a solution involving pages
generated on the fly server-side, with a caching proxy (nginx!) in front
of it.  We’ll have to seek assistance from the gnu.org web masters, but
ISTR they were not against that idea.

Thanks!

Ludo’.

bug#25045: [Website] Packages page takes too long to load

[Luis Felipe López Acevedo]

On 2016-11-28 12:00, Alex Sassmannshausen wrote:

Hi Luis,

Indeed, I had a first bash at solving this problem by providing a set 
of

static html pages paginated by the first letter of the package name.

I'm not particularly wedded to this solution, so if you feel strongly
about going another way, I'd be keen to hear/see about it.

In the meantime, I'm open to testing/feedback.  I will unfortunately 
not

be able to put work into this until at least Saturday/Sunday, as some
Perl work has higher priority at the moment.

But let me know if you have questions or feedback!

Best wishes,


Hi, Alex :)

The solution I had in mind includes an alphabetic index, and pagination 
as well. However, it includes a few more things, and would take some 
time to design and implement. So I think we should use your patch to fix 
the size issue as soon as possible.



For what is worth, this is what I had in mind:

/packages/
First page of the list of packages. Packages listed here only provide a 
summary: package logo (if any), name, version, description, and an 
indicator if it has issues. This page also has filters to find packages 
(for now, alphabetic filter. In the future, category filter, and search 
box).


/packages/page/N/
Page N of the list of packages.

/packages/a/
First page of the list of packages whose name starts with A. Packages 
are presented the same way as in /packages/.


/packages/a/page/N/
Page N of the list of packages starting with letter A.

/packages/icecat/X.Y.Z/
Page with details about IceCat version X.Y.Z. It includes all the 
information about this package, including its issues (which are 
currently listed in a separate page along with the issues of other 
packages: /packages/issues.html). Including the issues of a package in 
its detail page could avoid having the current issues page grow too 
much, like the current Packages page.


This static pagination and filtering would generate A LOT of pages, but 
of reasonable size for web browsers to load.


Best,


--
Luis Felipe López Acevedo
http://sirgazil.bitbucket.org/

bug#25045: [Website] Packages page takes too long to load

[Alex Sassmannshausen]

Hi Luis,

Indeed, I had a first bash at solving this problem by providing a set of
static html pages paginated by the first letter of the package name.

I'm not particularly wedded to this solution, so if you feel strongly
about going another way, I'd be keen to hear/see about it.

In the meantime, I'm open to testing/feedback.  I will unfortunately not
be able to put work into this until at least Saturday/Sunday, as some
Perl work has higher priority at the moment.

But let me know if you have questions or feedback!

Best wishes,

Alex

Ludovic Courtès writes:

> Hello!
>
> Luis Felipe López Acevedo  skribis:
>
>> I plan to redesign the packages page, and submit a proposal to fix
>> this bug.
>
> For the record, Alex (Cc’d) posted an initial patch a week ago:
>
>   https://lists.gnu.org/archive/html/guix-devel/2016-11/msg00498.html
>
> Please coordinate.  :-)
>
> Glad to see people working on this longstanding issue!
>
> Ludo’.

bug#25053: guix import nix does not work

[ng0]

I tried to import various packages from nixpkgs, from all kinds
of levels of the repository, none successful.

ng0@wasp ~$ export NIX_REMOTE=daemon
ng0@wasp ~$ guix import nix ~/re-src/nixpkgs libreoffice^C
ng0@wasp ~$ ls ~/re-src/nixpkgs/
COPYING  default.nix  doc/  lib/  maintainers/  nixos/  pkgs/  README.md
ng0@wasp ~$ guix import nix ~/re-src/nixpkgs pidgin
In execvp of : No such file or directory
Backtrace:
In ice-9/boot-9.scm:
 160: 13 [catch #t # ...]
In unknown file:
   ?: 12 [apply-smob/1 #]
In ice-9/boot-9.scm:
  66: 11 [call-with-prompt prompt0 ...]
In ice-9/eval.scm:
 432: 10 [eval # #]
In ice-9/boot-9.scm:
2404: 9 [save-module-excursion #]
4056: 8 [#]
1727: 7 [%start-stack load-stack ...]
1732: 6 [#]
In unknown file:
   ?: 5 [primitive-load 
"/gnu/store/303r6yzjbyf4kpdkd5hzxylam1m82s1v-guix-0.11.0-4.1f41/bin/.guix-real"]
In guix/ui.scm:
1222: 4 [run-guix-command import "nix" "/home/ng0/re-src/nixpkgs" "pidgin"]
In guix/scripts/import.scm:
 110: 3 [guix-import "nix" "/home/ng0/re-src/nixpkgs" "pidgin"]
In guix/scripts/import/nix.scm:
  85: 2 [guix-import-nix "/home/ng0/re-src/nixpkgs" "pidgin"]
In guix/import/snix.scm:
 459: 1 [nixpkgs->guix-package "/home/ng0/re-src/nixpkgs" "pidgin"]
 215: 0 [# #]

guix/import/snix.scm:215:6: In procedure #:
guix/import/snix.scm:215:6: Throw to key `parser-error' with args `(# "XML [22], unexpected EOF")'.
ng0@wasp ~$ guix import nix ~/re-src/nixpkgs/pkgs pidgin
In execvp of : No such file or directory
Backtrace:
In ice-9/boot-9.scm:
 160: 13 [catch #t # ...]
In unknown file:
   ?: 12 [apply-smob/1 #]
In ice-9/boot-9.scm:
  66: 11 [call-with-prompt prompt0 ...]
In ice-9/eval.scm:
 432: 10 [eval # #]
In ice-9/boot-9.scm:
2404: 9 [save-module-excursion #]
4056: 8 [#]
1727: 7 [%start-stack load-stack ...]
1732: 6 [#]
In unknown file:
   ?: 5 [primitive-load 
"/gnu/store/303r6yzjbyf4kpdkd5hzxylam1m82s1v-guix-0.11.0-4.1f41/bin/.guix-real"]
In guix/ui.scm:
1222: 4 [run-guix-command import "nix" "/home/ng0/re-src/nixpkgs/pkgs" "pidgin"]
In guix/scripts/import.scm:
 110: 3 [guix-import "nix" "/home/ng0/re-src/nixpkgs/pkgs" "pidgin"]
In guix/scripts/import/nix.scm:
  85: 2 [guix-import-nix "/home/ng0/re-src/nixpkgs/pkgs" "pidgin"]
In guix/import/snix.scm:
 459: 1 [nixpkgs->guix-package "/home/ng0/re-src/nixpkgs/pkgs" "pidgin"]
 215: 0 [# #]

guix/import/snix.scm:215:6: In procedure #:
guix/import/snix.scm:215:6: Throw to key `parser-error' with args `(# "XML [22], unexpected EOF")'.
ng0@wasp ~$ guix import nix ~/re-src/nixpkgs/pkgs libreoffice
In execvp of : No such file or directory
Backtrace:
In ice-9/boot-9.scm:
 160: 13 [catch #t # ...]
In unknown file:
   ?: 12 [apply-smob/1 #]
In ice-9/boot-9.scm:
  66: 11 [call-with-prompt prompt0 ...]
In ice-9/eval.scm:
 432: 10 [eval # #]
In ice-9/boot-9.scm:
2404: 9 [save-module-excursion #]
4056: 8 [#]
1727: 7 [%start-stack load-stack ...]
1732: 6 [#]
In unknown file:
   ?: 5 [primitive-load 
"/gnu/store/303r6yzjbyf4kpdkd5hzxylam1m82s1v-guix-0.11.0-4.1f41/bin/.guix-real"]
In guix/ui.scm:
1222: 4 [run-guix-command import "nix" ...]
In guix/scripts/import.scm:
 110: 3 [guix-import "nix" "/home/ng0/re-src/nixpkgs/pkgs" "libreoffice"]
In guix/scripts/import/nix.scm:
  85: 2 [guix-import-nix "/home/ng0/re-src/nixpkgs/pkgs" "libreoffice"]
In guix/import/snix.scm:
 459: 1 [nixpkgs->guix-package "/home/ng0/re-src/nixpkgs/pkgs" "libreoffice"]
 215: 0 [# #]

guix/import/snix.scm:215:6: In procedure #:
guix/import/snix.scm:215:6: Throw to key `parser-error' with args `(# "XML [22], unexpected EOF")'.
ng0@wasp ~$ guix import nix ~/re-src/nixpkgs libreoffice
In execvp of : No such file or directory
Backtrace:
In ice-9/boot-9.scm:
 160: 13 [catch #t # ...]
In unknown file:
   ?: 12 [apply-smob/1 #]
In ice-9/boot-9.scm:
  66: 11 [call-with-prompt prompt0 ...]
In ice-9/eval.scm:
 432: 10 [eval # #]
In ice-9/boot-9.scm:
2404: 9 [save-module-excursion #]
4056: 8 [#]
1727: 7 [%start-stack load-stack ...]
1732: 6 [#]
In unknown file:
   ?: 5 [primitive-load 
"/gnu/store/303r6yzjbyf4kpdkd5hzxylam1m82s1v-guix-0.11.0-4.1f41/bin/.guix-real"]
In guix/ui.scm:
1222: 4 [run-guix-command import "nix" "/home/ng0/re-src/nixpkgs" "libreoffice"]
In guix/scripts/import.scm:
 110: 3 [guix-import "nix" "/home/ng0/re-src/nixpkgs" "libreoffice"]
In guix/scripts/import/nix.scm:
  85: 2 [guix-import-nix "/home/ng0/re-src/nixpkgs" "libreoffice"]
In guix/import/snix.scm:
 459: 1 [nixpkgs->guix-package "/home/ng0/re-src/nixpkgs" "libreoffice"]
 215: 0 [# #]

guix/import/snix.scm:215:6: In procedure #:
guix/import/snix.scm:215:6: Throw to key `parser-error' with args `(# "XML [22], unexpected EOF")'.
ng0@wasp ~$ guix import nix ~~/re-src/nixpkgs/pkgs/applications/networking tor
In execvp of : No such file or directory
Backtrace:
In ice-9/boot-9.scm:
 160: 13 [catch #t # ...]
In unknown file:
   ?: 12 [apply-smob/1 #]
In ice-9/boot-9.scm:
  66: 11 [call-with-prompt prompt0 ...]
In ice-9/eval.scm:
 432: 10 [eval # #]
In ice-9/boot-9.scm:
2404: 9 

bug#25037: abiword: Not openning file chooser, and GLib-GIO-ERROR error

[Ricardo Wurmus]

Adonay Felipe Nogueira  writes:

> Abiword exits whenever one needs to use a file chooser to open or save
> files to be used or saved by AbiWord.
>
> # Steps to reproduce
>
> 1. Run AbiWord (with no other instances open, just to make sure).
>
> 2. Go to: File → Open
>   * Or to: File → Save as
>   * Or to: File → Export

I cannot reproduce this on GuixSD.  What does “env” tell you about your
environment?

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
http://elephly.net

bug#25035: scribus: No module named _sysconfigdata_nd

[Ricardo Wurmus]

Adonay Felipe Nogueira  writes:

> Note: If I'm not mistaken, there was no advise to set $PYTHONPATH to
> anything by the documentation (at least not for dailly/normal use) or by
> Guix itself (during installation of Scribus).

I don’t have PYTHONPATH set and Scribus works for me (I’m using
GuixSD).  Also make sure that LD_LIBRARY_PATH is not set.

~~ Ricardo

bug#22629: ‘guix pull’ and external dependencies

[Ludovic Courtès]

Hi!

Efraim Flashner  skribis:

> If I understand it correctly, as part of `guix pull' we get the latest
> package definitions, but `guix' and `guix-daemon' are at the
> guix-snapshot version, aka 0.11.0-4. If instead `guix-daemon' was from
> the tip of master then it'd be at the equivalant of running
> './pre-inst-env guix-daemon --build-users...', which would have all
> these changes.

What ‘guix pull’ does is fetch the latest code, build *the Scheme
subset* of that code, and install it in ~/.config/guix/latest.

Thus, it gives you the latest package recipes as well as the latest
‘guix’ sub-commands.

What it does not give you is:

  1. The latest C++ code (guix-daemon, guix-register).
  2. The latest locales.
  3. The latest elisp code.
  4. The latest dependencies (the Guile that appears in the shebang of
 the ‘guix’ command, zlib, Guile-SSH, Guile-JSON, etc.)

It worked OK when Guix was self-contained, and assuming people would
update guix-daemon through other ways (‘guix system reconfigure’ on
GuixSD).  But now we see that these shortcomings are starting to bite.

So I think what we need to do is for “guix pull-ng” to build and install
a complete ‘guix’ package, and to manage it pretty much like other
packages is managed, except not in the user’s main profile (because that
could lead to undesirable behavior, where upgrading Guix creates a new
generation, or, in theory, unrecoverable problems, where you cannot
roll back because previous generations use an old Guix that does not
understand the new manifest format.)

The difficulty is that ./configure && make && make install in Guix takes
some time, and we probably wouldn’t want to do that on each ‘guix pull’
invocation (esp. with Guile 2.2’s compilation times.)

So we may have to provide substitutes of Guix itself, and arrange so
that ‘guix pull’ pulls up to a tag for which we have substitutes.

Ideas welcome!  See .

Ludo’.

bug#25037: abiword: Not openning file chooser, and GLib-GIO-ERROR error

[Ludovic Courtès]

Adonay Felipe Nogueira  skribis:

> Abiword exits whenever one needs to use a file chooser to open or save
> files to be used or saved by AbiWord.
>
> # Steps to reproduce
>
> 1. Run AbiWord (with no other instances open, just to make sure).
>
> 2. Go to: File → Open
>   * Or to: File → Save as
>   * Or to: File → Export

I suspect the patch below addresses this problem:

diff --git a/gnu/packages/abiword.scm b/gnu/packages/abiword.scm
index 8e89bb2..f4f79fd 100644
--- a/gnu/packages/abiword.scm
+++ b/gnu/packages/abiword.scm
@@ -22,6 +22,7 @@
   #:use-module (guix packages)
   #:use-module (guix download)
   #:use-module (guix build-system gnu)
+  #:use-module (guix build-system glib-or-gtk)
   #:use-module (gnu packages)
   #:use-module (gnu packages autotools)
   #:use-module (gnu packages boost)
@@ -56,7 +57,7 @@
  (search-patches "abiword-wmf-version-lookup-fix.patch"
  "abiword-explictly-cast-bools.patch"
 
-(build-system gnu-build-system)
+(build-system glib-or-gtk-build-system)
 (arguments   ;; NOTE: rsvg is disabled, since Abiword
   `(#:configure-flags;; supports it directly, and its BS is broken.
 (list

Could you try and report back?

Thank you!

Ludo’.

bug#25035: scribus: No module named _sysconfigdata_nd

[Ludovic Courtès]

Adonay Felipe Nogueira  skribis:

> Note: Sorry friends, I pressed the wrong reply button (private reply). Now, 
> I'm
> replyng to the bugs mailing list.
>
> I'm running Guix on a foreign distribution, and $PYTHONPATH is
> unset. The foreign distribution in question is Trisquel 7 (which is
> based on the Ubuntu 14.04).

The interesting thing is that it opens the right libpython:

  
open("/gnu/store/7q9nn76r76hnxbfxyv6asishx58jc420-python-2.7.12/lib/libpython2.7.so.1.0",
 O_RDONLY|O_CLOEXEC) = 3

but then it does this:

--8<---cut here---start->8---
stat64("/home/adfeno/.guix-profile/bin/python", 0xbf868d1c) = -1 ENOENT (No 
such file or directory)
stat64("/usr/local/sbin/python", 0xbf868d1c) = -1 ENOENT (No such file or 
directory)
stat64("/usr/local/bin/python", 0xbf868d1c) = -1 ENOENT (No such file or 
directory)
stat64("/usr/sbin/python", 0xbf868d1c)  = -1 ENOENT (No such file or directory)
stat64("/usr/bin/python", {st_mode=S_IFREG|0755, st_size=3156448, ...}) = 0
readlink("/usr/bin/python", "python2.7", 4096) = 9
readlink("/usr/bin/python2.7", 0xbf868d1c, 4096) = -1 EINVAL (Invalid argument)
stat64("/usr/bin/Modules/Setup", 0xbf868d1c) = -1 ENOENT (No such file or 
directory)
stat64("/usr/bin/lib/python2.7/os.py", 0xbf868d1c) = -1 ENOENT (No such file or 
directory)
stat64("/usr/bin/lib/python2.7/os.pyc", 0xbf868d1c) = -1 ENOENT (No such file 
or directory)
stat64("/usr/lib/python2.7/os.py", {st_mode=S_IFREG|0644, st_size=25769, ...}) 
= 0
stat64("/usr/bin/pybuilddir.txt", 0xbf868d1c) = -1 ENOENT (No such file or 
directory)
stat64("/usr/bin/lib/python2.7/lib-dynload", 0xbf868d1c) = -1 ENOENT (No such 
file or directory)
stat64("/usr/lib/python2.7/lib-dynload", {st_mode=S_IFDIR|0755, st_size=12288, 
...}) = 0

[...]

stat64("/usr/lib/python27.zip", 0xbf867a28) = -1 ENOENT (No such file or 
directory)
stat64("/usr/lib", {st_mode=S_IFDIR|0755, st_size=36864, ...}) = 0
stat64("/usr/lib/python27.zip", 0xbf8689e0) = -1 ENOENT (No such file or 
directory)
stat64("/usr/lib/python2.7/", {st_mode=S_IFDIR|0755, st_size=28672, ...}) = 0
stat64("/usr/lib/python2.7/", {st_mode=S_IFDIR|0755, st_size=28672, ...}) = 0
stat64("/usr/lib/python2.7/site", 0xbf868b40) = -1 ENOENT (No such file or 
directory)
open("/usr/lib/python2.7/site.so", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such 
file or directory)
open("/usr/lib/python2.7/sitemodule.so", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No 
such file or directory)
open("/usr/lib/python2.7/site.py", O_RDONLY|O_LARGEFILE) = 16
fstat64(16, {st_mode=S_IFREG|0644, st_size=20388, ...}) = 0
open("/usr/lib/python2.7/site.pyc", O_RDONLY|O_LARGEFILE) = 17
fstat64(17, {st_mode=S_IFREG|0644, st_size=19727, ...}) = 0
read(17, "\3\363\r\ncZ\210Uc\0\0\0\0\0\0\0\0\3\0\0\0@\0\0\0sp\1\0\0d\0"..., 
4096) = 4096
fstat64(17, {st_mode=S_IFREG|0644, st_size=19727, ...}) = 0
read(17, "\0(\0\0\0\0s\32\0\0\0/usr/lib/python2.7/si"..., 12288) = 12288
read(17, "\0\0aliasmbcs\333\1\0\0s\24\0\0\0\0\4\17\1\30\1\20\1\17\1\3\1"..., 
4096) = 3343
read(17, "", 4096)  = 0
mmap2(NULL, 262144, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xaf304000
close(17)   = 0
stat64("/usr/lib/python2.7/os", 0xbf868750) = -1 ENOENT (No such file or 
directory)
open("/usr/lib/python2.7/os.so", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such 
file or directory)
open("/usr/lib/python2.7/osmodule.so", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No 
such file or directory)
open("/usr/lib/python2.7/os.py", O_RDONLY|O_LARGEFILE) = 17
--8<---cut here---end--->8---

… and from there, chaos ensues.

I’m not sure where those /usr/lib file names come from though.

Note that Scribus hard-codes a whole bunch of program file names (not
that of ‘python’, though), which may lead to problems down the path, at
least on GuixSD:

--8<---cut here---start->8---
$ find -name \*.cpp |xargs grep --color /usr/ 
./scribus/ui/prefs_paths.cpp:   profileDirLineEdit->setToolTip( "" + tr( 
"Default ICC profiles directory. This cannot be changed with a document open. 
By default, Scribus will look in the System Directories under Mac OSX and 
Windows. On Linux and Unix, Scribus will search $home/.color/icc, 
$home/.local/share/color/icc, /usr/share/color/icc and 
/usr/local/share/color/icc" ) + "" );
./scribus/ui/prefs_externaltools.cpp:   
<<"/usr/local/texlive/2009/bin/universal-darwin/pdflatex"
./scribus/ui/prefs_externaltools.cpp:   
<<"/usr/local/texlive/2008/bin/universal-darwin/pdflatex";
./scribus/ui/prefs_externaltools.cpp:   pdflatexPaths   
<<"/usr/local/bin/pdflatex"
./scribus/ui/prefs_externaltools.cpp:   
<<"/usr/bin/pdflatex";
./scribus/scpaths.cpp:  QString 

bug#25035: scribus: No module named _sysconfigdata_nd

[Adonay Felipe Nogueira]

Note: Sorry friends, I pressed the wrong reply button (private reply). Now, I'm
replyng to the bugs mailing list.

I'm running Guix on a foreign distribution, and $PYTHONPATH is
unset. The foreign distribution in question is Trisquel 7 (which is
based on the Ubuntu 14.04).

I'll read some documentation on which part of my Guix installation I
should set $PYTHONPATH to. I'll reply back when done experimenting.

Note: If I'm not mistaken, there was no advise to set $PYTHONPATH to
anything by the documentation (at least not for dailly/normal use) or by
Guix itself (during installation of Scribus).

bug#25035: scribus: No module named _sysconfigdata_nd

[Ricardo Wurmus]

Adonay Felipe Nogueira  writes:

> # Steps to reproduce
>
> Simply try running Scribus. It closes immediatelly.

I cannot reproduce this.  I just upgraded Scribus; I’m using
/gnu/store/5h44li2ansg4mb5kqck44wdzkka3isih-scribus-1.5.2/bin/scribus

> # Notes
>
> * I have attached the raw output of `strace scribus`.
> * It seems that, from the strace, one sees that something (Scribus?)
>   attempts to use things from the host's root ("/"), not from the
>   derivative's root ("$out/"), although, if comparing the existance of
>   some files between the two path trees, some of them don't exist in
>   the derivative's path tree (e.g.: No "$out/lib/python2.7/site.py", or
>   no "$profile/lib/python2.7/site.py", in the case of the current user's
>   ".guix-profile"  directory).

Are you running Scribus on GuixSD or on a foreign distro?  The strace
shows that your Scribus opens /usr/lib/python2.7/sysconfig.py, which
doesn’t exist on GuixSD.  Mixing Python from Guix with a system Python
installation is bound to lead to problems.

What is your PYTHONPATH variable set to?

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
http://elephly.net