bug#48273: Icedove 78.10.0 build stuck at 'unpack' phase
On Tue, May 11, 2021 at 12:21:33AM +, bo0od wrote: > (I couldnt upload the txt file due to size limitation forced on emails) Just FYI, if you compress your file with XZ it shrinks to 2 MB: $ xz icedovefinel.txt $ du -sh icedovefinel.txt.xz 2.0Micedovefinel.txt.xz
bug#48273: Icedove 78.10.0 build stuck at 'unpack' phase
> In your original bug report, you stated that the build was stuck in the
> 'unpack' phase of the 'icedove' package, and you attached a screenshot
> showing that phase in-progress.
Good thanks for the notification, I didnt expect it takes really long
time for it to move from one stage to another thus you see report and
the uploaded text are different in what they are saying (because i
actually run it and leave for half hour to couple of hours)
Since you said these are giving 2 different readings then the issue is
with timing, So i kept it for like 24 hour (or more) and now i hope the
log make more sense since there are too many fail,warnings..etc
https://gofile.io/d/Hy3axx
(I couldnt upload the txt file due to size limitation forced on emails)
Mark H Weaver:
Hi,
In your original bug report, you stated that the build was stuck in the
'unpack' phase of the 'icedove' package, and you attached a screenshot
showing that phase in-progress.
In this later followup message, you're stating something different: that
it's getting stuck in an earlier package build, namely while building
the 'icecat' source tarball.
Note that the 'icedove' package build cannot even begin until after the
'icecat' source tarball has been successfully built, so it seems that
you had a fully built 'icecat' source tarball on your system at some
point.
bo0od writes:
> Please try again with '--verbosity=3' [0] so that we can see what it's
stuck here:
"s|PACKAGES/icecat|PACKAGES/firefox|g;
s/GNU Public/Mozilla Public/g;
s/GNU Foundation/Mozilla Foundation/g;
s/GNU Corporation/Mozilla Corporation/g;
s/icecat\.com\>/firefox.com/g;
s/IceCat-Spdy/Firefox-Spdy/g;
s/icecat-accounts/firefox-accounts/g;
s/IceCatAccounts/FirefoxAccounts/g;
s|https://www\.mozilla\.org/icecat/?utm_source=synceol|https://www.mozilla.org/firefox/?utm_source=synceol|g;
s|www\.gnu\.org/software/gnuzilla/icecat-help|libreplanet.org/wiki/Group:IceCat/Help|g;
' '{}' ';'"
(check the uploaded logs, i have done 2 attempts of installing icedove
and both stopped at the same place)
This part of the process takes a long time, but at least on my Thinkpad
X200 system (Core 2 Duo, 4 GB RAM, 8 GB swap), it _does_ eventually
finish.
Did the build attempt fail on its own, or did you abort it?
Thanks,
Mark
bug#48340: python-django: django crashes with this message, DistributionNotFound.
Hi, I'm running python-django on top of Debian Sid, after running $ django-admin startproject test I get this error message: Traceback (most recent call last): File "/home/salman/.guix-profile/bin/django-admin", line 6, in from pkg_resources import load_entry_point File "/gnu/store/hq7qr7nc2j29z3pivm3azfjy6jq3d7nx-python-3.8.2/lib/python3.8/site-packages/pkg_resources/__init__.py", line 3251, in def _initialize_master_working_set(): File "/gnu/store/hq7qr7nc2j29z3pivm3azfjy6jq3d7nx-python-3.8.2/lib/python3.8/site-packages/pkg_resources/__init__.py", line 3234, in _call_aside f(*args, **kwargs) File "/gnu/store/hq7qr7nc2j29z3pivm3azfjy6jq3d7nx-python-3.8.2/lib/python3.8/site-packages/pkg_resources/__init__.py", line 3263, in _initialize_master_working_set working_set = WorkingSet._build_master() File "/gnu/store/hq7qr7nc2j29z3pivm3azfjy6jq3d7nx-python-3.8.2/lib/python3.8/site-packages/pkg_resources/__init__.py", line 583, in _build_master ws.require(__requires__) File "/gnu/store/hq7qr7nc2j29z3pivm3azfjy6jq3d7nx-python-3.8.2/lib/python3.8/site-packages/pkg_resources/__init__.py", line 900, in require needed = self.resolve(parse_requirements(requirements)) File "/gnu/store/hq7qr7nc2j29z3pivm3azfjy6jq3d7nx-python-3.8.2/lib/python3.8/site-packages/pkg_resources/__init__.py", line 786, in resolve raise DistributionNotFound(req, requirers) pkg_resources.DistributionNotFound: The 'Django==3.2.2' distribution was not found and is required by the application Thanks, Salman
bug#48331: Emacs' describe-package doesn't work for packages managed by guix
describe-package and list-packages do not show emacs packages, installed with guix. Packages themselves work perfectly fine, but not listed in list-packages and can't be accessed with describe-package. Way to reproduce: guix environment --pure --ad-hoc emacs emacs-treemacs emacs -q M-x treemacs ;; Works fine C-h P treemacs ;; Doesn't work M-x list-packages ;; Doesn't list treemacs Played around with it a little bit, still not sure how to solve.
bug#48335: Emacs is broken
Hi, Am Montag, den 10.05.2021, 18:40 +0200 schrieb Xinglu Chen: > Hi, > > The ‘emacs’ package seems to be broken, I can reproduce this with > > --8<---cut here---start->8--- > guix time-machine --commit=87b4b0e4385149b40ee87ae2d57712679452746b > -- \ > environment --pure --ad-hoc emacs -- emacs --version > /gnu/store/as4fpcyq6qjngp6433w68v09x5znhh10-profile/bin/emacs: error > while loading shared libraries: libm17n-core.so.0: cannot open shared > object file: No such file or directory > --8<---cut here---end--->8--- I can't: --8<---cut here---start->8--- $ guix time-machine --commit=87b4b0e4385149b40ee87ae2d57712679452746b -- \ environment --pure --ad-hoc emacs -- emacs --version GNU Emacs 27.2 Copyright (C) 2021 Free Software Foundation, Inc. GNU Emacs comes with ABSOLUTELY NO WARRANTY. You may redistribute copies of GNU Emacs under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING. --8<---cut here---end--->8--- As for the output of ldd: libm17n-core.so.0 => /gnu/store/pdwv15zmghndkqy5473v1hxgibmvzvlz-m17n- lib-1.8.0/lib/libm17n-core.so.0 > The latest “good” commit I know of is > ee86a035c79b838e3fdabbdb88dc30906a83cc30 (still bisecting). That'd be big if true, we've had the wip-emacs merge between then and now and while that caused a lot of problems to many, it should still open up. Now, perhaps there's a case to be made, that it's in fact broken on another architecture or when not using substitutes (it is not reproducible after all), but atm we're lacking a bit of necessary info here. Regards, Leo
bug#47729: Fixed: CVE-2021-30184 Arbitrary code execution in GNU Chess [security]
Fixed with https://git.savannah.gnu.org/cgit/guix.git/commit/?id=9a11f2380ff49756ace2f33bc96a88cdb6af5453.
bug#48336: kicad cannot see libngspice
In Kicad Eeschema, if I try to use the Tools >> Simulator menu entry, I get an error in a pop-up window that libngspice cannot be found, and then the whole Kicad application closes. I see that libngspice is a dependency of kicad so I'm not quite sure what is wrong. I asked at #kicad at they said that Kicad does not have any gui- adjustable path settings for ngspice or libngspice, so I don't think I have the application configured wrong. Thank you, Christopher Howard christopher@theoden ~$ neofetch --stdout christopher@theoden --- OS: Guix System 9ffa81fe64ee405e1a861b72a21bca966fcbc236 x86_64 Host: OptiPlex 9020 00 Kernel: 5.11.18-gnu Uptime: 8 mins Packages: 92 (guix-system), 104 (guix-user) Shell: bash 5.0.16 Resolution: 1920x1080 DE: GNOME Theme: Adwaita [GTK2/3] Icons: Adwaita [GTK2/3] Terminal: kitty CPU: Intel i5-4570 (4) @ 3.600GHz GPU: Intel HD Graphics GPU: AMD ATI Radeon HD 8490 / R5 235X OEM Memory: 1673MiB / 7871MiB christopher@theoden ~$ guix describe Generation 16 May 03 2021 09:42:36(current) guix 9ffa81f repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: 9ffa81fe64ee405e1a861b72a21bca966fcbc236
bug#48335: Emacs is broken
Hi, The ‘emacs’ package seems to be broken, I can reproduce this with --8<---cut here---start->8--- guix time-machine --commit=87b4b0e4385149b40ee87ae2d57712679452746b -- \ environment --pure --ad-hoc emacs -- emacs --version /gnu/store/as4fpcyq6qjngp6433w68v09x5znhh10-profile/bin/emacs: error while loading shared libraries: libm17n-core.so.0: cannot open shared object file: No such file or directory --8<---cut here---end--->8--- The latest “good” commit I know of is ee86a035c79b838e3fdabbdb88dc30906a83cc30 (still bisecting).
bug#48327: guix system image uses cross-compiler even on native system
Hello Vagrant, > But I'm building this on an aarch64 system; it shouldn't need to use an > aarch64-linux-gnu cross-compiler on an aarch64-linux system! It would be > nice if it could build images natively, too. :) Yes indeed! It has been discussed here: https://issues.guix.gnu.org/45020 without reaching a proper conclusion. The idea of https://issues.guix.gnu.org/45021 is to add a "system" field to the record, so that we can build the image natively when appropriate or cross-compile otherwise. Thanks, Mathieu
bug#48178: Out of memory error when generating a docker-image.
On Mon, 2021-05-10 at 10:29 +0300, Efraim Flashner wrote: > On Mon, May 03, 2021 at 07:47:49PM +0200, Roel Janssen wrote: > > On Mon, 2021-05-03 at 12:39 -0400, Leo Famulari wrote: > > > On Mon, May 03, 2021 at 12:09:36AM +0200, Roel Janssen wrote: > > > > Looking at 'guix/scripts/system.scm', it seems that we always > > > > pass > > > > 256M > > > > of memory to the VM. After bumping that to 4096M, I was able > > > > to > > > > produce a docker image. > > > > > > Can you test somes values that are in between? Like, 512M, 1024M, > > > etc, > > > until we know how much is actually required? If 512M is enough, I > > > don't > > > see a problem with increasing the hard-coded value to that. > > > > > > > I monitored the VM's memory usage and it peaked at 1.6G. But after > > testing, it seems 1024 also works. > > > > I tested with 2048 (worked), 1024 (worked), and 512 (didn't work). > > > > > > I'd like to see what we can do here. Assigning too little > > > > memory > > > > leads > > > > to problems generating the container, but assigning too much > > > > memory > > > > wil > > > > l cause problems for computing machines that don't have much > > > > memory > > > > to > > > > spare. > > > > > > > In that case... The attached patch would only increase the size > > when > > generating a Docker container image. Would that be acceptable? > > > > > There are some use cases for this code that we'd like to work on > > > low-resource machines (`guix system vm`), and other use cases > > > (like > > > building Docker images) that shouldn't be expected to work on > > > machines > > > with limited RAM. > > > > > > > Would it be a good idea to make it configurable at run-time? > > > > > > Yeah, maybe. > > > > > > > I think it'd be better to have it somehow dynamically increase, but > > I > > don't see how I could determine the VM size needed for a given > > system > > configuration. So perhaps the attached patch is an acceptable > > compromise. > > > > Kind regards, > > Roel Janssen > > > > Looks good to me! > Thank you for looking at it! I pushed the proposed patch in ce3d05cc08c01351756ab5d5b7f25cfe0295c230. Kind regards, Roel Janssen
bug#48178: Out of memory error when generating a docker-image.
On Mon, May 03, 2021 at 07:47:49PM +0200, Roel Janssen wrote: > On Mon, 2021-05-03 at 12:39 -0400, Leo Famulari wrote: > > On Mon, May 03, 2021 at 12:09:36AM +0200, Roel Janssen wrote: > > > Looking at 'guix/scripts/system.scm', it seems that we always pass > > > 256M > > > of memory to the VM. After bumping that to 4096M, I was able to > > > produce a docker image. > > > > Can you test somes values that are in between? Like, 512M, 1024M, > > etc, > > until we know how much is actually required? If 512M is enough, I > > don't > > see a problem with increasing the hard-coded value to that. > > > > I monitored the VM's memory usage and it peaked at 1.6G. But after > testing, it seems 1024 also works. > > I tested with 2048 (worked), 1024 (worked), and 512 (didn't work). > > > > I'd like to see what we can do here. Assigning too little memory > > > leads > > > to problems generating the container, but assigning too much memory > > > wil > > > l cause problems for computing machines that don't have much memory > > > to > > > spare. > > > > In that case... The attached patch would only increase the size when > generating a Docker container image. Would that be acceptable? > > > There are some use cases for this code that we'd like to work on > > low-resource machines (`guix system vm`), and other use cases (like > > building Docker images) that shouldn't be expected to work on > > machines > > with limited RAM. > > > > > Would it be a good idea to make it configurable at run-time? > > > > Yeah, maybe. > > > > I think it'd be better to have it somehow dynamically increase, but I > don't see how I could determine the VM size needed for a given system > configuration. So perhaps the attached patch is an acceptable > compromise. > > Kind regards, > Roel Janssen > Looks good to me! -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
