bug#32770: Packaging SLIME/SWANK as Common Lisp library
Hi Pierre, On Fri, 05 Oct 2018 15:30:03 +0200 Pierre Neidhardt wrote: > > In “guile-sly”, for example, the configure script accepts > > “--with-libfreeimage-prefix=” and “--with-libgslcblas-prefix=”, > > which are then used to construct a full path to the libraries. In > > other cases where the build system does not provide a mechanism for > > this we need to patch the sources such as in “guile-dbi”. > > But as far I know of, most Common Lisp packages don't provide a > configure script. So can this apply here? > I was suggesting that lisp packages should adopt some configuration mechanism, either through scripts or by something that asdf could take care of. It's something that I think we could discuss with the upstream communities once we have a good grasp on our use case. -- Andy
bug#33000: openal 404 "Not Found"
When trying to build OpenAL, I get a 404 "Not Found." > download failed > "http://tarballs.nixos.org/sha256/1mhf5bsb58s1xk6hvxl7ly7rd4rpl9z8h07xl1q94brywykg7bgi"; > 404 "Not Found" > failed to download > "/gnu/store/3bdqdxl3aribv35dcp2glx8sg3slxxkx-openal-soft-1.19.0.tar.bz2" from > "http://kcat.strangesoft.net/openal-releases/openal-soft-1.19.0.tar.bz2"; The project homepage may have moved from http://kcat.strangesoft.net/openal-releases/ to http://openal-soft.org/openal-releases/. I arrived at this from this commit on their Github repository. https://github.com/kcat/openal-soft/commit/6562a939ea5a5b582d6aa182f3f6fa7411a5e222#diff-04c6e90faac2675aa89e2176d2eec7d8 I am not sure if the original website is just temporarily down or if it has moved. The Github repository mentions the official website being openal-soft.org. Sources are also available on Github but with a different extension. Something like this worked when I tested it: $ diff -u audio.scm audio.scm.2 --- audio.scm 2018-10-09 22:23:12.750628879 -0700 +++ audio.scm.2 2018-10-09 22:23:58.158478413 -0700 @@ -1913,7 +1913,7 @@ (source (origin (method url-fetch) (uri (string-append -"http://kcat.strangesoft.net/openal-releases/openal-soft-"; +"http://openal-soft.org/openal-releases/openal-soft-"; version ".tar.bz2")) (sha256 (base32
bug#32995: Executing pre-compiled binaries
Hi Brett, > Brett Gilio writes: > >> Hi all, I am having an issue with trying to execute literally any >> pre-compiled binary files. One example is Telegram. Here is what is >> happening. >> >> brettg@oryxpro ~$ cd Downloads/tsetup.1.4.0/Telegram/ >> brettg@oryxpro ~/Downloads/tsetup.1.4.0/Telegram$ ls >> Telegram Updater >> brettg@oryxpro ~/Downloads/tsetup.1.4.0/Telegram$ ./Telegram bash: >> ./Telegram: >> No such file or directory >> brettg@oryxpro ~/Downloads/tsetup.1.4.0/Telegram$ >> >> Any ideas? > > Also, in the strings evaluation of the binary I am getting > /lib64/ld-linux-x86-64.so.2 This is the dynamic linker/loader. It is provided by the GNU C library. The best approach is to avoid this problem and build the programme from source. Any other approach is really just a hack. Possible hacks are: 1. symlink the dynamic linker/loader from glibc to the expected location. 2. use “patchelf” to replace the reference to the linker on an FHS system with a reference to the linker from our glibc. This would only be the first step. Binaries built and linked elsewhere are probably also going to have problems finding libraries. Here you would have to mess with LD_LIBRARY_PATH to satisfy these requirements. I suggest not going down this road and packaging the software instead. Since we don’t support the execution of pre-built binaries on Guix I’m closing the bug report, but I hope my comments have been helpful in your case. -- Ricardo
bug#32929: `guix pull` fail
Ludo, On Mon, 2018-10-08 at 22:47 +0200, Ludovic Courtès wrote: > Thanks for your report. I pulled v0.15.0 and from there tried to > pull > the above commit, but I couldn’t reproduce the bug above. > > Does it still occur for you? Yes, I'm still getting this error, although with different program and guix version hashes which frequently change. > How did you install Guix? It seems to be running on Guile 2.0 (not > 2.2), can you confirm? I installed via the Fedora 28 COPR at https://copr.fedorainfracloud.org/coprs/lantw44/guix/. I'm 90% sure I'm running Guile 2.0, even though I have both 2.0 and 2.2 installed via dnf. -Michael
bug#32997: Kodi phones home to check for updates
On Tue, Oct 09, 2018 at 11:43:18AM +0200, Gábor Boskovits wrote: > Efraim Flashner ezt írta (időpont: 2018. okt. 9., > K, 10:14): > > > I launced kodi for my kids to watch some videos and I got a pop-up > > telling me that 18-beta3 was available for download. We should patch out > > the update checker. > > > > -- > > Efraim Flashner אפרים פלשנר > > GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 > > Confidentiality cannot be guaranteed on emails sent or received unencrypted > > > > As a workaround you could try to configure Kodi to not check for updates. > 1.~ From the Kodi home screen click SYSTEM>ADD-ONS>MY ADD-ONS. > 2.~ SERVICES>VERSION CHECK>CONFIGURE. > 3.~ Untick Enable Kodi Version Check>click OK>untick AUTO-UPDATE. > (did not try this myself) > Do you think that modifying the default configuration is enough, or should > we completely remove this functionality? I think it'd be better to completely remove the functionality, there's nothing an end-user can really gain since we've packaged the software. I also think we're due for an update to the package :) -- 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
bug#32997: Kodi phones home to check for updates
Efraim Flashner ezt írta (időpont: 2018. okt. 9., K, 10:14): > I launced kodi for my kids to watch some videos and I got a pop-up > telling me that 18-beta3 was available for download. We should patch out > the update checker. > > -- > Efraim Flashner אפרים פלשנר > GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 > Confidentiality cannot be guaranteed on emails sent or received unencrypted > As a workaround you could try to configure Kodi to not check for updates. 1.~ From the Kodi home screen click SYSTEM>ADD-ONS>MY ADD-ONS. 2.~ SERVICES>VERSION CHECK>CONFIGURE. 3.~ Untick Enable Kodi Version Check>click OK>untick AUTO-UPDATE. (did not try this myself) Do you think that modifying the default configuration is enough, or should we completely remove this functionality?
bug#32997: Kodi phones home to check for updates
I launced kodi for my kids to watch some videos and I got a pop-up telling me that 18-beta3 was available for download. We should patch out the update checker. -- 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
bug#32161: seek out of range
Hi, l...@gnu.org (Ludovic Courtès) skribis: > Ricardo Wurmus skribis: > >> Ricardo Wurmus writes: >> >>> I’m getting this bug on berlin.guixsd.org. The store is several hundred >>> GB in size. I cannot reproduce this on a machine with a smaller store. >> >> This is not correct. I cannot reproduce this on a machine where >> deduplication has been disabled. >> >>> --8<---cut here---start->8--- >>> In guix/store/deduplication.scm: >>> 62:18 1 (nar-sha256 _) >>> In unknown file: >>>0 (seek # 0 1) >>> >>> ERROR: In procedure seek: >>> Value out of range -2147483648 to 2147483647: 4770726968 >>> @ hook-failed >>> /gnu/store/qjxwff3fajh350chpswbb6x9q2m4c3sd-texlive-texmf-2017.drv - 256 >>> builder for >>> `/gnu/store/qjxwff3fajh350chpswbb6x9q2m4c3sd-texlive-texmf-2017.drv' failed >>> with exit code 1 >>> --8<---cut here---end--->8--- > > For the record, this code can be executed through ‘guix offload’, via > ‘restore-file-set’. > >> Line 62 is (port-position wrapper). “seek” takes an integer as the >> offset and the range it reports is that of the minimum and maximum >> values of a 32 bit integer. > > I have some good news! I fixed this in Guile commit > d677aca5c5e5b3a9f71af57243169904ba4a712c. > > Bad news, we can’t really work around it on the Guix side. Actually Guix commit 4f89a8eec69491b925f084381ea4de37527c9310 provides a workaround. Ludo’.
