Re: Emacs 27
Yay! Thank you! I saw Valentin’s channel just the other day. It looked like they solved the problem I had. Thanks again, John
Re: qtwenengine anybody?
mike.ros...@gmail.com writes: > Hartmut Goebel writes: > >> Am 16.12.19 um 18:09 schrieb mike.ros...@gmail.com: >>> I'm currently brushing up my latest qtwebengine build. Will resubmit >>> this patch. I will also see if I can inherit qtsvg again to put this >>> back on par with other module packages. From there I'll put a simple >>> test example together demonstrating the locale and translation problem. >> >> Sounds good > > I've resubmitted the patch it can be found here > https://lists.gnu.org/archive/html/guix-patches/2019-12/msg00530.html. My > ML patch workflow is probably not all that correct so I apologize if > there is any issues. For those following along at home: here it is in the bug tracker: https://issues.guix.gnu.org/issue/35866 -- Ricardo
Re: qtwenengine anybody?
Pierre Neidhardt writes: > Fantastic! > > The pulseaudio and OpenGL issues are not blockers in my opinion. We can > open new issues about them and resolve them later. > >> I can also a substitute if anyone needs them for testing. Since this >> build can take some time. > > Please do! Thanks! A substitute is available on https://gx.bufio.org and the public key can be found here. http://git.savannah.nongnu.org/cgit/nomad.git/plain/contrib/guix/gx.bufio.org.pub Mike
Re: qtwenengine anybody?
Fantastic! The pulseaudio and OpenGL issues are not blockers in my opinion. We can open new issues about them and resolve them later. > I can also a substitute if anyone needs them for testing. Since this > build can take some time. Please do! Thanks! -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: qtwenengine anybody?
Hartmut Goebel writes: > Am 16.12.19 um 18:09 schrieb mike.ros...@gmail.com: >> I'm currently brushing up my latest qtwebengine build. Will resubmit >> this patch. I will also see if I can inherit qtsvg again to put this >> back on par with other module packages. From there I'll put a simple >> test example together demonstrating the locale and translation problem. > > Sounds good I've resubmitted the patch it can be found here https://lists.gnu.org/archive/html/guix-patches/2019-12/msg00530.html. My ML patch workflow is probably not all that correct so I apologize if there is any issues. To summarize the package now inherits from qtsvg. The locales issues have been resolved by substituting qtwebengine's output instead of using qtbase. Some dynamically loaded libraries like udev and nss have been substituted using corresponding inputs. Some known issues, when building with pulseaudio support. There is some issues finding pulseaudio socket. I've disabled support for pulseaudio until I can resolve this. Additionally on my system when using hardware accelerated OpenGL neuveau drivers, qtwebengine crashes this does not happen when using the monolithic qt package. This can avoided by setting the QT_XCB_FORCE_SOFTWARE_OPENGL to 1. I have a simple CPP for testing it can be found here. https://github.com/mrosset/testqt. for testing I use this enviroment. --8<---cut here---start->8--- ./pre-inst-env guix environment --ad-hoc qtbase qtwebengine qtdeclarative qtwebchannel coreutils gcc-toolchain nss-certs --8<---cut here---end--->8--- and then I test with --8<---cut here---start->8--- cd testqt qmake make ./main --8<---cut here---end--->8--- or there are hardware acceleration problems --8<---cut here---start->8--- QT_XCB_FORCE_SOFTWARE_OPENGL=1 ./main --8<---cut here---end--->8--- I can also a substitute if anyone needs them for testing. Since this build can take some time. Mike
Re: Tk 8.6.10 cross-compilation.
Mathieu Othacehe writes: > Hey, > > It has been fixed upstream[1], I'll add the patch in Guix soon. Excellent, thank you! signature.asc Description: PGP signature
Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
Konrad Hinsen writes: > Hi Simon, > >> Maybe I miss a point. It is not: "watch out, this will do something >> else in the future" but "watch out, this was doing something else in >> the past and the change happened the in ". > > Concrete example: I am writing a tutorial about using Guix for > reproducible research. It shows several uses of "guix environment", some > of them without '–add-hoc' or '–inputs-of'. I know my examples will > cease to work in a few months. What am I supposed to do about this? This is the point where we need to ask ourselves: Should Guix be volatile software? http://stevelosh.com/blog/2012/04/volatile-software/ Also: Software developers should avoid traumatic changes https://drewdevault.com/2019/11/26/Avoid-traumatic-changes.html Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken signature.asc Description: PGP signature
Re: Tk 8.6.10 cross-compilation.
Hey, It has been fixed upstream[1], I'll add the patch in Guix soon. Thanks, Mathieu [1]: https://core.tcl-lang.org/tk/tktview?name=211f2257dc Le mer. 18 déc. 2019 à 21:24, Marius Bakke a écrit : > > Mathieu Othacehe writes: > > > Hello Marius, > > > > Since the update of Tk to 8.6.10 in core-updates, I have the following > > error when > > cross-compiling for aarch64: > > > > --8<---cut here---start->8--- > > aarch64-linux-gnu-gcc -O2 -pipe-Wl,--export-dynamic -shared -o > > libtk8.6.so tk3d.o tkArgv.o tkAtom.o tkBind.o tkBitmap.o tkBusy.o > > tkClipboard.o tkCmds.o tkColor.o tkConfig.o tkConsole.o tkCursor.o > > tkError.o tkEvent.o tkFocus.o tkFont.o tkGet.o tkGC.o tkGeometry.o tkGrab.o > > tkGrid.o tkMain.o tkObj.o tkOldConfig.o tkOption.o tkPack.o tkPlace.o > > tkSelect.o tkStyle.o tkUndo.o tkUtil.o tkVisual.o tkWindow.o tkButton.o > > tkEntry.o tkFrame.o tkListbox.o tkMenu.o tkMenubutton.o tkMenuDraw.o > > tkMessage.o tkPanedWindow.o tkScale.o tkScrollbar.o tkCanvas.o tkCanvArc.o > > tkCanvBmap.o tkCanvImg.o tkCanvLine.o tkCanvPoly.o tkCanvPs.o tkCanvText.o > > tkCanvUtil.o tkCanvWind.o tkRectOval.o tkTrig.o tkImage.o tkImgBmap.o > > tkImgGIF.o tkImgPNG.o tkImgPPM.o tkImgPhoto.o tkImgPhInstance.o tkText.o > > tkTextBTree.o tkTextDisp.o tkTextImage.o tkTextIndex.o tkTextMark.o > > tkTextTag.o tkTextWind.o tkStubInit.o ttkBlink.o ttkButton.o ttkCache.o > > ttkClamTheme.o ttkClassicTheme.o ttkDefaultTheme.o ttkElements.o ttkEntry.o > > ttkFrame.o ttkImage.o ttkInit.o ttkLabel.o ttkLayout.o ttkManager.o > > ttkNotebook.o ttkPanedwindow.o ttkProgress.o ttkScale.o ttkScrollbar.o > > ttkScroll.o ttkSeparator.o ttkSquare.o ttkState.o ttkTagSet.o ttkTheme.o > > ttkTrace.o ttkTrack.o ttkTreeview.o ttkWidget.o ttkStubInit.o tkUnix.o > > tkUnix3d.o tkUnixButton.o tkUnixColor.o tkUnixConfig.o tkUnixCursor.o > > tkUnixDraw.o tkUnixEmbed.o tkUnixEvent.o tkUnixFocus.o tkUnixFont.o > > tkUnixInit.o tkUnixKey.o tkUnixMenu.o tkUnixMenubu.o tkUnixScale.o > > tkUnixScrlbr.o tkUnixSelect.o tkUnixSend.o tkUnixWm.o tkUnixXId.o > > -lpthread -lX11 -ldl -lpthread -lm > > -L/gnu/store/69g2cklv99hin2cyvpamxdmxzxlr8l93-tcl-8.6.10/lib -ltclstub8.6 > > -Wl,-rpath,/gnu/store/r4ncs29n5a13dl79afglp2d1f2bmlakh-tk-8.6.10/lib:/gnu/store/69g2cklv99hin2cyvpamxdmxzxlr8l93-tcl-8.6.10/lib > > aarch64-linux-gnu-ld: > > /gnu/store/69g2cklv99hin2cyvpamxdmxzxlr8l93-tcl-8.6.10/lib/libtclstub8.6.a(strtoul.o): > > in function `strtoul': > > (.text+0x30): undefined reference to `TclIsSpaceProc' > > aarch64-linux-gnu-ld: libtk8.6.so: hidden symbol `TclIsSpaceProc' isn't > > defined > > aarch64-linux-gnu-ld: final link failed: bad value > > --8<---cut here---end--->8--- > > > > I opened a ticket on tk bug tracker. Would it be fine to revert tk to > > 8.6.9 version in the meantime? > > No objections from me. Is there a ticket URL available for future > reference?
Re: Emacs 27
Hi John, John Soo writes: > Hi guix, > > Speaking of the next version of emacs, do you think we could add an > emacs-next package? I have tried to build from head recently and the > recent changes to the dumping mechanism does not work with our current > package definition. > > - John Perfect timing? :-) https://issues.guix.gnu.org/issue/38662 -amin signature.asc Description: PGP signature
Re: Tk 8.6.10 cross-compilation.
Mathieu Othacehe writes: > Hello Marius, > > Since the update of Tk to 8.6.10 in core-updates, I have the following error > when > cross-compiling for aarch64: > > --8<---cut here---start->8--- > aarch64-linux-gnu-gcc -O2 -pipe-Wl,--export-dynamic -shared -o > libtk8.6.so tk3d.o tkArgv.o tkAtom.o tkBind.o tkBitmap.o tkBusy.o > tkClipboard.o tkCmds.o tkColor.o tkConfig.o tkConsole.o tkCursor.o tkError.o > tkEvent.o tkFocus.o tkFont.o tkGet.o tkGC.o tkGeometry.o tkGrab.o tkGrid.o > tkMain.o tkObj.o tkOldConfig.o tkOption.o tkPack.o tkPlace.o tkSelect.o > tkStyle.o tkUndo.o tkUtil.o tkVisual.o tkWindow.o tkButton.o tkEntry.o > tkFrame.o tkListbox.o tkMenu.o tkMenubutton.o tkMenuDraw.o tkMessage.o > tkPanedWindow.o tkScale.o tkScrollbar.o tkCanvas.o tkCanvArc.o tkCanvBmap.o > tkCanvImg.o tkCanvLine.o tkCanvPoly.o tkCanvPs.o tkCanvText.o tkCanvUtil.o > tkCanvWind.o tkRectOval.o tkTrig.o tkImage.o tkImgBmap.o tkImgGIF.o > tkImgPNG.o tkImgPPM.o tkImgPhoto.o tkImgPhInstance.o tkText.o tkTextBTree.o > tkTextDisp.o tkTextImage.o tkTextIndex.o tkTextMark.o tkTextTag.o > tkTextWind.o tkStubInit.o ttkBlink.o ttkButton.o ttkCache.o ttkClamTheme.o > ttkClassicTheme.o ttkDefaultTheme.o ttkElements.o ttkEntry.o ttkFrame.o > ttkImage.o ttkInit.o ttkLabel.o ttkLayout.o ttkManager.o ttkNotebook.o > ttkPanedwindow.o ttkProgress.o ttkScale.o ttkScrollbar.o ttkScroll.o > ttkSeparator.o ttkSquare.o ttkState.o ttkTagSet.o ttkTheme.o ttkTrace.o > ttkTrack.o ttkTreeview.o ttkWidget.o ttkStubInit.o tkUnix.o tkUnix3d.o > tkUnixButton.o tkUnixColor.o tkUnixConfig.o tkUnixCursor.o tkUnixDraw.o > tkUnixEmbed.o tkUnixEvent.o tkUnixFocus.o tkUnixFont.o tkUnixInit.o > tkUnixKey.o tkUnixMenu.o tkUnixMenubu.o tkUnixScale.o tkUnixScrlbr.o > tkUnixSelect.o tkUnixSend.o tkUnixWm.o tkUnixXId.o -lpthread -lX11 -ldl > -lpthread -lm -L/gnu/store/69g2cklv99hin2cyvpamxdmxzxlr8l93-tcl-8.6.10/lib > -ltclstub8.6 > -Wl,-rpath,/gnu/store/r4ncs29n5a13dl79afglp2d1f2bmlakh-tk-8.6.10/lib:/gnu/store/69g2cklv99hin2cyvpamxdmxzxlr8l93-tcl-8.6.10/lib > aarch64-linux-gnu-ld: > /gnu/store/69g2cklv99hin2cyvpamxdmxzxlr8l93-tcl-8.6.10/lib/libtclstub8.6.a(strtoul.o): > in function `strtoul': > (.text+0x30): undefined reference to `TclIsSpaceProc' > aarch64-linux-gnu-ld: libtk8.6.so: hidden symbol `TclIsSpaceProc' isn't > defined > aarch64-linux-gnu-ld: final link failed: bad value > --8<---cut here---end--->8--- > > I opened a ticket on tk bug tracker. Would it be fine to revert tk to > 8.6.9 version in the meantime? No objections from me. Is there a ticket URL available for future reference? signature.asc Description: PGP signature
Emacs 27
Hi guix, Speaking of the next version of emacs, do you think we could add an emacs-next package? I have tried to build from head recently and the recent changes to the dumping mechanism does not work with our current package definition. - John
Re: Helpful imenu matches
Hi Pierre! Awesome! I will keep my eyes peeled. - John
Re: Helpful imenu matches
Hi John! This snippet is very useful indeed! I had reported the issue to Emacs upstream some time ago and recently (< 1 month) it got merged upstream! So I think it should be in Emacs 27 :) -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Helpful imenu matches
Hi Guix,
I know there are a lot of emacs users here.
I wanted to share this snippet I find really helpful when working with
Guile:
(defvar guile-imenu-generic-expression
(cons '("Public" "^(define-public\\s-+(?\\(\\sw+\\)" 1)
scheme-imenu-generic-expression)
"Imenu generic expression for Guile modes. See
`imenu-generic-expression'.")
(add-hook
'scheme-mode-hook
(lambda ()
(setq-local imenu-generic-expression guile-imenu-generic-expression)))
If you use ido, helm, or counsel for imenu, this really helps find
definitions much faster.
I don't really know if there is an upstream to send this to.
If you know, please let me know.
- John
Re: Document GUIX_LOAD_PATH?
Hi Pierre, On Wed, 18 Dec 2019 at 12:28, Pierre Neidhardt wrote: > Today I learned about the existence of GUIX_LOAD_PATH. It does not seem > to be documented in the manual. Is it anywhere in the doc? Shall we > document it? It can be documented in devel pages., maybe Contributing. But IMHO, the normal use should be via the --load-path option and the GUIX_LOAD_PATH should be less and less used; stay here for historical reason and/or backward compatibility and/or some devel use-case. Well, for discoverability, it appears to me easier to list an option with "guix --help" than list environment variables. All the best, simon
Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
Hi Konrad, On Wed, 18 Dec 2019 at 10:43, Konrad Hinsen wrote: > > Hi Simon, > > > Maybe I miss a point. It is not: "watch out, this will do something > > else in the future" but "watch out, this was doing something else in > > the past and the change happened the in ". > > Concrete example: I am writing a tutorial about using Guix for > reproducible research. It shows several uses of "guix environment", some > of them without '–add-hoc' or '–inputs-of'. I know my examples will > cease to work in a few months. What am I supposed to do about this? Assuming "guix environment" would stay and following the proposed plan, you would need to add GUIX_ENVIRONMENT_DEPRECATED=1 on the top of your script. In this would not be a problem for travelling back in time. > > First, I am not convinced that there is not so much scripts that will > > be broken. And second, I am not convinced neither that these very > > scripts need time-traveling. > > Perhaps it's just me, but I use "guix environment" quite a lot in > scripts, in order to make them more reproducible. Here's a simple > example: > >#!/usr/bin/env bash >guix environment --container --ad-hoc gcc-toolchain./pi >EOF With the proposed plan, this would stay the same. Even, the --ad-hoc option could stay forever for backward compatibility. The only issue is for example: #!/usr/bin/env bash guix environment --container gmsh < > Yes, it is probably the most adequate to do. But it is sad to loose > > the good name "guix environment"... and we know that naming is hard. > > ;-) > > I definitely agree. As a lesson for the future, maybe we should use > not-so-nice names for new commands during a kind of beta-testing phase. What do you think about "guix shell" for the new "guix environment" behaviour? What the others think? New name (easier) vs transitional plan (trickier)? And new names proposal: - guix env - guix shell ? All the best, simon
Document GUIX_LOAD_PATH?
Hi! Today I learned about the existence of GUIX_LOAD_PATH. It does not seem to be documented in the manual. Is it anywhere in the doc? Shall we document it? -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: bug#38529: Make --ad-hoc the default for guix environment proposed deprecation mechanism
Hi Simon, > Maybe I miss a point. It is not: "watch out, this will do something > else in the future" but "watch out, this was doing something else in > the past and the change happened the in ". Concrete example: I am writing a tutorial about using Guix for reproducible research. It shows several uses of "guix environment", some of them without '–add-hoc' or '–inputs-of'. I know my examples will cease to work in a few months. What am I supposed to do about this? > First, I am not convinced that there is not so much scripts that will > be broken. And second, I am not convinced neither that these very > scripts need time-traveling. Perhaps it's just me, but I use "guix environment" quite a lot in scripts, in order to make them more reproducible. Here's a simple example: #!/usr/bin/env bash guix environment --container --ad-hoc gcc-toolchain <> The first rule of backwards-compatibility is: never change the meaning >> of an existing valid command/API. Add new valid syntax, deprecate old >> valid syntax, but don't change the meaning of something that was and >> will be valid. > > I agree on the rule. > But it is mitigated but the number of users and the popularity of the tool. > ;-) Indeed! > Yes, it is probably the most adequate to do. But it is sad to loose > the good name "guix environment"... and we know that naming is hard. > ;-) I definitely agree. As a lesson for the future, maybe we should use not-so-nice names for new commands during a kind of beta-testing phase. Cheers, Konrad
