Re: Packaging FreeCAD
Hi John, This is good news indeed for Guix-using engineers and architects. I shall follow developments with interest. I can look after the OpenCASCADE dependency too. This package is due an update but upstream development has been slow of late. Debian have switched to the OCCT version for FreeCAD and I am thinking that it would be best for Guix to follow suit. This would entail the introduction of a new opencascade-occt package, which I plan to do soon, if no-one beats me to it! Best regards, Paul.
how to fix state-broken affected user services? (Re: GNOME 3.30: help needed!)
Hi all, Ricardo Wurmus writes: [...] > Success! GNOME 3.30 works just fine. The gnome-shell segfaulted(!) > because of stale state this is one of the worst bugs a user can experience, and very few users are able to debug it properly (and experienced users like me find it very time wasting to debug them) please Ricardo could you attach the relevant debug info? have you seen a related bug report upstream? (this is a seriuos bug, isn't it?) > in ~/.local/share/gnome-shell. do you mean ~/.local/share/gnome-shell/application_state? [...] Thanks for your work! Giovanni -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
Re: how to fix state-broken affected user services? (Re: GNOME 3.30: help needed!)
Hi Giovanni, >> Success! GNOME 3.30 works just fine. The gnome-shell segfaulted(!) >> because of stale state > > this is one of the worst bugs a user can experience, and very few users > are able to debug it properly (and experienced users like me find it > very time wasting to debug them) Yeah, it wasted a lot of my time. Before upgrading to GNOME 3.30 I built 3.28 and tested that with the same results. Weeks later I finished 3.30 only to hit the same problem. It was only after Rene confirmed that this is actually working that I even considered the possibility that some old state might be at fault here. > please Ricardo could you attach the relevant debug info? I don’t have any debug info other than what I posted. I didn’t look at the files, but I might be able to recover them from backup. > have you seen a related bug report upstream? (this is a seriuos bug, > isn't it?) I haven’t seen any bug reports about this. -- Ricardo
Video on reproducible genomics pipeline
Hello Guix! For those of you interested in “reproducible science”, this presentation by Ricardo efficiently demonstrates the benefits of Guix and shortcomings of “containers” in this context: https://guix-hpc.bordeaux.inria.fr/blog/2019/01/pigx-paper-awarded-at-the-international-conference-on-genomics-icg-13/ Happy Friday! :-) Ludo’.
Re: how to fix state-broken affected user services? (Re: GNOME 3.30: help needed!)
Hi Ricardo, plz could you confirm what did you deleted to make GNOME run again? application_state file or the whole directory? Ricardo Wurmus writes: [...] >> please Ricardo could you attach the relevant debug info? > > I don’t have any debug info other than what I posted. I didn’t look at > the files, but I might be able to recover them from backup. if it's not too much work on your side, this would be *very* helpful to others >> have you seen a related bug report upstream? (this is a seriuos bug, >> isn't it?) > > I haven’t seen any bug reports about this. having the debugging infos we should issue a bugreport upstream, I can help if needed (I do not use GNOME but I could setup a VM to reproduce this bug and report upstream) thank you! Gio P.S.: sorry for the change in the subject line, at first I considered opening a broather "subthread" concerning the (IMHO harmful) statefulnes of gnome-shell and similar user *servicies*... but then I changed my mind -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
Re: how to fix state-broken affected user services? (Re: GNOME 3.30: help needed!)
Giovanni Biscuolo writes: > plz could you confirm what did you deleted to make GNOME run again? > application_state file or the whole directory? I deleted the whole directory. I *also* reset my dconf customizations, but this was not sufficient. I had to delete that directory. I’ll look for the files later and see if I can reproduce the crash. -- Ricardo
Re: 07/07: gnu: emacs-ghub: Update to 3.2.0.
Mark H Weaver writes: > Hi Jelle, > [...] > > In toplevel form: > magit-reset.el:30:1:Error: Cannot open load file: No such file or directory, > graphql > make[1]: *** [Makefile:65: magit-reset.elc] Error 1 > make[1]: Leaving directory > '/tmp/guix-build-emacs-magit-2.13.0.drv-0/magit-2.13.0/lisp' > make: *** [Makefile:72: lisp] Error 2 I am not quite sure what goes wrong, but I do know that ghub and magit should probably be updated in lockstep. I reverted the patch for now and will push it once I have verified other things still work. Later I will update everything at once when emacs-forge is properly released. BTW, how does our one-change-per-patch policy apply when running into situations where multiple changes have to be made at once in order to keep everything building correctly? Thanks, - Jelle
Re: bug#34020: [PATCH 0/2] Re-purpose '--verbosity' to something useful
Would you be open for a patch which adds BSD familiar -v behavior? In other words, multiple v increase the verbosity level, like -vv is more verbose than -v. I'll have to check the actual changes first, haven't had access to something which runs plain Guix in a while. On Fri, 11 Jan 2019 12:15:41 +0100, Ludovic Courtès wrote: > Hi, > > Mike Gerwitz skribis: > > > On Wed, Jan 09, 2019 at 14:31:45 +0100, Ludovic Courtès wrote: > >> These patches re-purposes ‘--verbosity’ so that it better matches > >> user expectations. The previous ‘--verbosity’ option, which is > >> about the daemon’s debugging output, is renamed to ‘--debug’. > >> In addition, ‘--verbosity’ now has a shorthand ‘-v’. > >> > >> Most commands that build stuff support -v/--verbosity so users can > >> easily override the default verbosity level. > >> > >> Thoughts? > > > > (Just having looked at the patches, without actually trying it out.) > > > > This is much better, thank you! I was confused by the previous behavior. > > Thanks for your feedback, pushed now! > > I’ve also adjust ‘guix archive’, which I had forgotten in the patch I > sent. > > Ludo’.
Re: Packaging Jami (ex GNU Ring)
Pierre Neidhardt skrev: (10 januari 2019 14:19:34 CET) > >swedebugia writes: >> I put it in messaging.scm. Is that suitable? > >Maybe not. From qaul.net: > >> qaul.net implements a redundant, open communication principle, in >which >> wireless-enabled computers and mobile devices can directly form a >spontaneous >> network. Text messaging, file sharing and voice calls are possible >independent >> of internet and cellular networks. > >From https://github.com/qaul/qaul.net: >(WiFi) Mesh network communication app > >Maybe it would fit better in networking.scm? Thanks, I had put it there first 😝 -- Sent from my p≡p for Android. pEpkey.asc Description: application/pgp-keys
Re: ASDF Builder (Common Lisp) & "package-inferred-system" Packages
Pierre Neidhardt writes:
> I've packaged a lot of Lisp packages, none of which seem to suffer
> from a naming issue.
This is a newer style of ASDF system. I don't think any of the things we
have packaged use this style (yet).
> Do you have an example in mind?
I have 41 packages almost ready to go, but the only one I'm currently
packaging that uses the "package-inferred-system" style is Ningle[1].
> Which string replacement are you referring to? NORMALIZE-STRING?
Yes. I'm wondering why we even need to call `normalize-string' here
since this is generating the string ASDF will use to search for a
package, and ASDF is capable of handling `/` characters in its package
names. I think we may be conflating the need for the store to remove `/`
characters with ASDF's needs, but I'm not completely sure.
> I'm not completely sure, but I think that in practice packages can
> always specify the right ASD-FILE or SYSTEM. There could be something
> missing though.
This is not about specifying the ASD file; it is regarding how a system
is defined within an ASD file. Please read this[2] link for more
information. A single ASD file will define a package (note, not system)
per file. The packages will all have the `/` character embedded in the
name since it is correlating files in the system's path with packages.
I cannot find a way to tell the runtime that the renamed package (in
this case "ningle-main") is an alias for the real package
("ningle/main"), but it is very possible I'm missing something obvious.
[1] - https://github.com/fukamachi/ningle/blob/master/ningle.asd
[2] -
https://www.common-lisp.net/project/asdf/asdf.html#index-Package-inferred-systems
--
Katherine
New file "tests/docker-inception.scm" with small problem
Hi, there's a new branch "wip-docker-test" which has a new (non-system) test tests/docker-inception.scm . You can run it via: make TESTS=tests/docker-inception.scm check Unfortunately, it fails with some inscrutable qemu error message: qemu-system-x86_64: -virtfs local,path=/home/dannym/src/guix-ns14/guix/test-tmp/store,security_model=none,mount_tag=TAGy5ajggutlpmxibmqfchkokzxuwid: cannot ini tialize fsdev 'TAGy5ajggutlpmxibmqfchkokzxuwid': failed to open '/home/dannym/src/guix-ns14/guix/test-tmp/store': No such file or directory Trying to fix it (setting NIX_STORE etc) made it worse, so I reverted that part. Help? pgp401xkPfoA2.pgp Description: OpenPGP digital signature
Re: Packaging Jami (ex GNU Ring)
And now both libringclient and ring-client-gnome build! Sadly gnome-ring fails to start: --8<---cut here---start->8--- > /gnu/store/6q1ysbyki4v1zidbcndvyrchm3jncs58-ring-client-gnome-20190108.1.8659b2c/bin/gnome-ring > --debug GLib-GIO-Message: 19:30:42.058: Using the 'memory' GSettings backend. Your settings will not be saved or shared with other applications. ** (gnome-ring:25566): DEBUG: 19:30:42.059: debug enabled ** Message: 19:30:42.066: Jami GNOME client version: 32e606106920a21da416ef365fb654b5df721098 ** Message: 19:30:42.066: git ref: unknown ** (gnome-ring:25566): DEBUG: 19:30:42.066: enabling autostart ** (gnome-ring:25566): DEBUG: 19:30:42.066: checking /usr/share/gnome-ring/gnome-ring.desktop ** (gnome-ring:25566): DEBUG: 19:30:42.066: checking /usr/local/share/gnome-ring/gnome-ring.desktop ** (gnome-ring:25566): DEBUG: 19:30:42.066: checking /gnu/store/6q1ysbyki4v1zidbcndvyrchm3jncs58-ring-client-gnome-20190108.1.8659b2c/share/gnome-ring/gnome-ring.desktop ** (gnome-ring:25566): DEBUG: 19:30:42.066: '/home/ambrevar/.config/autostart/gnome-ring.desktop' is already a symlink to '/gnu/store/6q1ysbyki4v1zidbcndvyrchm3jncs58-ring-client-gnome-20190108.1.8659b2c/share/gnome-ring/gnome-ring.desktop' (gnome-ring:25566): Gtk-DEBUG: 19:30:42.557: Connecting to session manager (gnome-ring:25566): Gtk-DEBUG: 19:30:42.557: Failed to get the GNOME session proxy: The name org.gnome.SessionManager is not owned (gnome-ring:25566): Gtk-DEBUG: 19:30:42.557: Failed to get the Xfce session proxy: The name org.xfce.SessionManager is not owned (gnome-ring:25566): Gtk-DEBUG: 19:30:42.558: Failed to get an inhibit portal proxy: The name org.freedesktop.portal.Desktop is not owned /gnu/store/6q1ysbyki4v1zidbcndvyrchm3jncs58-ring-client-gnome-20190108.1.8659b2c/bin/gnome-ring: symbol lookup error: /gnu/store/zng0ix6b6icm8f8r6cqr09ykiz6rgrpg-qtbase-5.11.2/lib/qt5/plugins/sqldrivers/libqsqlite.so: undefined symbol: sqlite3_column_table_name16 --8<---cut here---end--->8--- Some link / version error with qtbase? Not sure why it's happening at runtime. Anyone? -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: Packaging FreeCAD
Hey Paul, I did not know Debian changed their version of opencascade. I will have to double check that they are using OCCT for FreeCAD still. - John > On Jan 11, 2019, at 1:35 AM, Paul Garlick > wrote: > > Hi John, > > This is good news indeed for Guix-using engineers and architects. I > shall follow developments with interest. > > I can look after the OpenCASCADE dependency too. This package is due > an update but upstream development has been slow of late. Debian have > switched to the OCCT version for FreeCAD and I am thinking that it > would be best for Guix to follow suit. This would entail the > introduction of a new opencascade-occt package, which I plan to do > soon, if no-one beats me to it! > > Best regards, > > Paul. > > >
Re: 07/07: gnu: emacs-ghub: Update to 3.2.0.
Jelle Licht writes: > Mark H Weaver writes: > >> Hi Jelle, >> [...] >> >> In toplevel form: >> magit-reset.el:30:1:Error: Cannot open load file: No such file or directory, >> graphql >> make[1]: *** [Makefile:65: magit-reset.elc] Error 1 >> make[1]: Leaving directory >> '/tmp/guix-build-emacs-magit-2.13.0.drv-0/magit-2.13.0/lisp' >> make: *** [Makefile:72: lisp] Error 2 > > I am not quite sure what goes wrong, but I do know that ghub and magit > should probably be updated in lockstep. I reverted the patch for now and > will push it once I have verified other things still work. Later I will > update everything at once when emacs-forge is properly released. Sounds good, thanks. > BTW, how does our one-change-per-patch policy apply when running into > situations where multiple changes have to be made at once in order to > keep everything building correctly? In this case, I would keep them as separate commits, but push them at the same time. Thanks! Mark
Re: New file "tests/docker-inception.scm" with small problem
Danny Milosavljevic writes: > Hi, > > there's a new branch "wip-docker-test" which has a new (non-system) test > tests/docker-inception.scm . > > You can run it via: > > make TESTS=tests/docker-inception.scm check > > Unfortunately, it fails with some inscrutable qemu error message: > > qemu-system-x86_64: -virtfs > local,path=/home/dannym/src/guix-ns14/guix/test-tmp/store,security_model=none,mount_tag=TAGy5ajggutlpmxibmqfchkokzxuwid: > cannot ini > tialize fsdev 'TAGy5ajggutlpmxibmqfchkokzxuwid': failed to open > '/home/dannym/src/guix-ns14/guix/test-tmp/store': No such file or directory > > Trying to fix it (setting NIX_STORE etc) made it worse, so I reverted that > part. > > Help? I don't know what the problem is, but the test reads an awful lot like a "system test" to me. Any particular reason you wish to run this as a "unit test"? Perhaps we need another category for "package tests"? :) I suspect converting to a system test will fix this problem, as it will use a "normal" store instead of the scratch one in ./test-tmp. signature.asc Description: PGP signature
GRUB fallback mechanism [was Re: Brain storming cool Guix features]
On Mon, Jan 07, 2019 at 05:48:39PM +0100, L p R n d n wrote: > - Currently, I think the only way for a GuixSD installation to break is > if something goes wrong with the bootloader. Might be nice to have a > tool (in the install image I suppose) to recover the bootloader. > Maybe 'guix system init' can deal with that king of cases for now, I > don't know, but a dedicated command might be able to use the original > store, restore previous generations etc. Apparently GRUB has a feature that records a "fallback" system to boot if booting fails. Maybe when reconfiguring, Guix could set the current system as the fallback so that it would always boot. If we did that, we'd want to warn the user somehow... not sure how to achieve that. Discussion of this feature at NixOS: https://github.com/NixOS/nixpkgs/issues/26332 signature.asc Description: PGP signature
