Re: Towards a graphical installer?
On 5/12/20 9:09 AM, Pierre Neidhardt wrote: > Errr... Sorry, I was distracted yesterday, the NLNet grant is actually > for a graphical _package manager_, not an installer! :p > > That said, I'm interested in helping with it too! :) > Really?! We have that?? Wonderful!! That would be the YaST thing I was talking about!! signature.asc Description: OpenPGP digital signature
best practise between git-fetch vs url-fetch?
Dear, Based on these 2 messages [1,2], what is the consensus between git-fetch and url-fetch? Pushing to SWH when linting appears to me winning the pros/cons. Even if SWH should eventually fetch http://guix.gnu.org/sources.json soon. And the other big pros from my point of view is the content-addressed Git references. Well, does it make sense to state on a recommended method? All the best, simon [1] https://lists.gnu.org/archive/html/guix-devel/2020-03/msg00091.html On Fri, 6 Mar 2020 at 18:41, Marius Bakke wrote: > url-fetch requires less bandwidth, and does not depend on 'git'. > > Though the most important distinction is that uploaded releases > sometimes contain pre-processed sources (e.g. documentation) that need > additional dependencies or scripts when building from the raw repository > (this is why you often need to add autoconf, libtool & friends as inputs > when building Autotools projects from git). > > I don't know whether there is a difference between the uploaded fmt > zipball and the git repository. [2] https://lists.gnu.org/archive/html/guix-devel/2020-03/msg00189.html On Wed, 11 Mar 2020 at 15:39, Ludovic Courtès wrote: > Other considerations: > > - Bandwidth requirement for source code downloads has never been a > criterion so far. > > - Git references are nice because they’re (roughly) content-addressed. > > - ‘guix lint -c archival’ archives Git references on Software > Heritage; it does not archive tarballs (though SWH will do it > for us eventually.)
Re: Bundler 2
On Tue, May 12, 2020 at 05:48:12PM -0400, Jack Hill wrote: > On Tue, 12 May 2020, Josh Holland wrote: > > > Indeed I see that gnu/packages/ruby.scm only packages Bundler v1.17.3, > > though Bundler 2 was released in January 2019 [0]. I'm not hugely > > familiar with the Ruby ecosystem, but reading the release announcement > > suggests that they expect users/developers to have both Bundler 1 and > > Bundler 2 available. If I hadn't seen this, I'd have gone ahead and > > submitted a patch simply upgrading the Bundler package definition, but > > I'm not sure if that will then immediately break every package depending > > on it that expects Bundler 1. > > > > Is this a valid concern? Should Guix provide packages for both Bundler > > 1 and Bundler 2, or would just Bundler 2 be sufficient? I'll still > > write a definition for the new version, but I'll hold off submitting a > > patch until I've had some feedback. > > > > [0]: https://bundler.io/blog/2019/01/03/announcing-bundler-2.html > > Josh, > > Thanks for raising this question. > > I'm not a Rubist, but we do wrangle some Ruby code at work (unfortunately, > not yet with Guix). Our experience has been that everyone interacting with > the code should use the same Bundler version, so I think that as long as > Bundler v1 is supportable, we should provide both in Guix. > > What do others think? Bundler is a packaging tool that typically works at the source tree level. Its approach is to pull all dependencies in. With Guix we don't have much use for it. Better to package gems in Guix and benefit from a true reproducible and dependable deployment system that *includes* underlying dependencies, such as libxml and all that. Sometimes it is useful to try gems. I did write up in the past how I mix Guix packages with Ruby gems. Using bundler is just another layer. See https://gitlab.com/pjotrp/guix-notes/-/blob/master/RUBY.org#gnu-guix-ruby-with-bundler Not much love for bundler therefore ;) Pj.
Re: guix describe user experience improvement proposition
On Tuesday, May 12, 2020 10:13 PM, Ekaitz Zarraga wrote:
> On Tuesday, May 12, 2020 9:44 PM, zimoun zimon.touto...@gmail.com wrote:
> > Usually, the way to add such information is '--list-formats', e.g.,
> > see "guix graph"with '--list-types' and '-list-backends'. I do not
> > know if it is an usually. ;-)
>
> But do you think it's interesting?
> Or is it just me?
>
> I like the `--list-types` approach. If it's interesting I would contribute
> with a patch.
Hi,
It would be something like this, tested and working.
Opinions?
Best,
Ekaitz
diff --git a/guix/scripts/describe.scm b/guix/scripts/describe.scm
index f13f221da9..69c6d8482f 100644
--- a/guix/scripts/describe.scm
+++ b/guix/scripts/describe.scm
@@ -42,13 +42,26 @@
;;; Command-line options.
;;;
+(define %available-formats '("human" "channels" "json" "recutils"))
+
+(define (list-formats)
+ (display (G_ "The available formats are:\n"))
+ (newline)
+ (for-each (lambda (f)
+ (format #t " - ~a~%" f))
+%available-formats))
+
(define %options
;; Specifications of the command-line options.
(list (option '(#\f "format") #t #f
(lambda (opt name arg result)
- (unless (member arg '("human" "channels" "json" "recutils"))
+ (unless (member arg %available-formats)
(leave (G_ "~a: unsupported output format~%") arg))
(alist-cons 'format (string->symbol arg) result)))
+(option '("list-formats") #f #f
+(lambda (opt name arg result)
+ (list-formats)
+ (exit 0)))
(option '(#\p "profile") #t #f
(lambda (opt name arg result)
(alist-cons 'profile (canonicalize-profile arg)
@@ -70,6 +83,8 @@
Display information about the channels currently in use.\n"))
(display (G_ "
-f, --format=FORMATdisplay information in the given FORMAT"))
+ (display (G_ "
+ --list-formats display available formats"))
(display (G_ "
-p, --profile=PROFILE display information about PROFILE"))
(newline)
Re: icu4j, antlr4, source archives without a root path
Hi Michael, what is the central message of your email? Is it just to say "I gave up, sorry", or do you need help at specific points? :-) At least I can tell you that I have quite a bunch of work-in-progress branches lying around because I start with "Oh, let's _just_ update/fix/add this little program ..." and you end up in a chain of needed updates, conflicting updates, broken states, etc. Don't get confused by this :-) I try to plan my work step by step in these situations, cleanly commit what's finished and write a personal log of the success and failures and intermediate knowledge gained. To the concrete java-icu4j: What do you think about the attached patch (needs some clean-up)? What's a bit uncommon about the project is that it builds separate sub-projects and then combines them. I'm not sure about the output(s): There are icu4j.jar, icu4j-charset.jar and icu4j-localespi.jar, I only copied the first one as I think this is what the original package definition did. Björn From 85516c2319a94f1e4b22954efd32f489d7d3925e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Bj=C3=B6rn=20H=C3=B6fling?= Date: Tue, 12 May 2020 20:27:59 +0200 Subject: [PATCH] gnu: java-icu4c: Update to 66.1, use full sources. * gnu/packages/icu4c.scm (java-icu4c): Update to 66.1. [source]: Use full sources instead of jar-sources. [arguments]: Add chdir phase, replace install phase. --- gnu/packages/icu4c.scm | 32 ++-- 1 file changed, 22 insertions(+), 10 deletions(-) diff --git a/gnu/packages/icu4c.scm b/gnu/packages/icu4c.scm index cf76c6fe20..ccced11f81 100644 --- a/gnu/packages/icu4c.scm +++ b/gnu/packages/icu4c.scm @@ -6,6 +6,7 @@ ;;; Copyright © 2017 Ricardo Wurmus ;;; Copyright © 2019, 2020 Marius Bakke ;;; Copyright © 2019 Mathieu Othacehe +;;; Copyright © 2020 Björn Höfling ;;; ;;; This file is part of GNU Guix. ;;; @@ -117,22 +118,33 @@ C/C++ part.") (define-public java-icu4j (package (name "java-icu4j") -(version "59.1") +(version "66.1") (source (origin (method url-fetch) - (uri (string-append "http://download.icu-project.org/files/icu4j/; - version "/icu4j-" - (string-map (lambda (x) -(if (char=? x #\.) #\_ x)) - version) - "-src.jar")) + (uri (string-append +"https://github.com/unicode-org/icu/releases/download/release-; +(string-map (lambda (x) (if (char=? x #\.) #\- x)) version) +"/icu4j-" +(string-map (lambda (x) (if (char=? x #\.) #\_ x)) version) +".tgz")) (sha256 - (base32 -"0bgxsvgi0qcwj60pvcxrf7a3fbk7aksyxnfwpbzavyfrfzixqh0c" + (base32 "1ahdyz9209lwl7knb2l3gmnkkby221p0vpgx70fj4j02rdzgvw0d" (build-system ant-build-system) (arguments `(#:tests? #f ; no tests included - #:jar-name "icu4j.jar")) + #:phases + (modify-phases %standard-phases + (add-before 'configure 'chdir + (lambda _ + (chdir "..") + #t)) + (replace 'install + (lambda* (#:key outputs #:allow-other-keys) + (let ((share (string-append (assoc-ref outputs "out") + "/share/java/"))) + (mkdir-p share) + (install-file "icu4j.jar" share) + #t)) (home-page "http://site.icu-project.org/;) (synopsis "International Components for Unicode") (description -- 2.26.2 pgp8yacrE5jbD.pgp Description: OpenPGP digital signature
Re: Bundler 2
On Tue, 12 May 2020, Josh Holland wrote: Indeed I see that gnu/packages/ruby.scm only packages Bundler v1.17.3, though Bundler 2 was released in January 2019 [0]. I'm not hugely familiar with the Ruby ecosystem, but reading the release announcement suggests that they expect users/developers to have both Bundler 1 and Bundler 2 available. If I hadn't seen this, I'd have gone ahead and submitted a patch simply upgrading the Bundler package definition, but I'm not sure if that will then immediately break every package depending on it that expects Bundler 1. Is this a valid concern? Should Guix provide packages for both Bundler 1 and Bundler 2, or would just Bundler 2 be sufficient? I'll still write a definition for the new version, but I'll hold off submitting a patch until I've had some feedback. [0]: https://bundler.io/blog/2019/01/03/announcing-bundler-2.html Josh, Thanks for raising this question. I'm not a Rubist, but we do wrangle some Ruby code at work (unfortunately, not yet with Guix). Our experience has been that everyone interacting with the code should use the same Bundler version, so I think that as long as Bundler v1 is supportable, we should provide both in Guix. What do others think? Jack
Re: Towards a graphical installer?
On AP 22.02.1399 17:57, Mathieu Othacehe wrote: Hello, A way to move forward with the installer could be to propose an ISO image starting a desktop-environment by default. The attached patch modifies the installation image so that it starts a GNOME session. The installer is then automatically started, inside a gnome-terminal. The resulting ISO image is bigger: 3.9G without compression and 1.7G with compression. Now, I'm not sure this is something we want to merge as-is. Maybe, it's time to port the installer to a GTK3 application, or a Web application. As we already have something working, porting (gnu installer) to a new graphical backend, could be not so hard. I don't think I'll have the bandwidth to do this anytime soon, but is someone is interested, I'm willing to help/review :). Thanks, Mathieu I think a Qt-Based application could be a good idea as an installer. Also there is an installer `calamares` developed by Qt. It's plugin based and we can develop/customize GUIX specific plugins of `calamares`. So we can have a GUI Installer more faster. Currently the `calamares` is used by many other distros like `Lubuntu` and `Manjaro`. https://calamares.io/about/ https://calamares.io/calamares-2.0-is-out/ Also we can choose `LXQt` as the default DE for installation. So we can have a smaller ISO image with a lightweight and capable DE.
Re: Internationalization Support for the Guix Data Service Outreachy Project
Dear Danjela, Welcome! :-) > I am Danjela, the intern who will be working on "Internationalization Support > for Guix Data Service" Outreachy project mentored by Christopher Baines. Really nice! Guix Data Service deserves love. :-) Best regards, simon
Re: guix describe user experience improvement proposition
On Tuesday, May 12, 2020 9:44 PM, zimoun wrote: > Dear > > On Tue, 12 May 2020 at 21:07, Ekaitz Zarraga eka...@elenq.tech wrote: > > > I suggest adding the possible format list in the help of the `guix describe > > -h` command. That way the feature discovery is easier for users that don't > > want to dig in the code. > > Usually, the way to add such information is '--list-formats', e.g., > see "guix graph"with '--list-types' and '-list-backends'. I do not > know if it is an usually. ;-) But do you think it's interesting? Or is it just me? I like the `--list-types` approach. If it's interesting I would contribute with a patch. > > - (display (G_ " > > - -f, --format=FORMAT display information in the given FORMAT")) > > > > - (display (string-append (G_ " > > - -f, --format=FORMAT display information in the given FORMAT: ") > > (string-join available-formats "|"))) > > The issue is the length, so at least it should on 2 lines to fix screen size. Yeah I was aware of that. I was just adding the diff to try to share what I wanted, rather than like something we should add with no changes. :) Thanks for the feedback! Ekaitz
Re: guix describe user experience improvement proposition
Dear On Tue, 12 May 2020 at 21:07, Ekaitz Zarraga wrote: > I suggest adding the possible format list in the help of the `guix describe > -h` command. That way the feature discovery is easier for users that don't > want to dig in the code. Usually, the way to add such information is '--list-formats', e.g., see "guix graph"with '--list-types' and '-list-backends'. I do not know if it is an usually. ;-) > - (display (G_ " > - -f, --format=FORMATdisplay information in the given FORMAT")) > + (display (string-append (G_ " > + -f, --format=FORMATdisplay information in the given FORMAT: ") > (string-join available-formats "|"))) The issue is the length, so at least it should on 2 lines to fix screen size. All the best, simon
guix describe user experience improvement proposition
Hi all,
Yesterday I wanted to use `guix describe` and I felt quite helpless when
choosing the format I wanted.
I suggest adding the possible format list in the help of the `guix describe -h`
command. That way the feature discovery is easier for users that don't want to
dig in the code.
It should be easy to add, something like the diff I add below (untested and
horrible, the idea is to help me explain myself rather than serving as a
contribution).
How do you feel about this?
Interesting for anyone? Is there any reason why it's not added already that I
might be missing?
Cheers,
Ekaitz
The obnoxious diff:
diff --git a/guix/scripts/describe.scm b/guix/scripts/describe.scm
index f13f221da9..0222ed0951 100644
--- a/guix/scripts/describe.scm
+++ b/guix/scripts/describe.scm
@@ -42,11 +42,13 @@
;;; Command-line options.
;;;
+(define available-formats '("human" "channels" "json" "recutils"))
+
(define %options
;; Specifications of the command-line options.
(list (option '(#\f "format") #t #f
(lambda (opt name arg result)
- (unless (member arg '("human" "channels" "json" "recutils"))
+ (unless (member arg available-formats)
(leave (G_ "~a: unsupported output format~%") arg))
(alist-cons 'format (string->symbol arg) result)))
(option '(#\p "profile") #t #f
@@ -68,8 +70,8 @@
(define (show-help)
(display (G_ "Usage: guix describe [OPTION]...
Display information about the channels currently in use.\n"))
- (display (G_ "
- -f, --format=FORMATdisplay information in the given FORMAT"))
+ (display (string-append (G_ "
+ -f, --format=FORMATdisplay information in the given FORMAT: ")
(string-join available-formats "|")))
(display (G_ "
-p, --profile=PROFILE display information about PROFILE"))
(newline)
Routing Guix services traffic trough Tor
Hello Guix, Today I played a bit with Tor and Guix, trying to fetch substitutes trough the Tor network as blaze_cornbread asked on IRC[0] how to do this. I managed to get it working but in the end I don't think we should encourage people doing it this way, that's why I haven't submitted a patch to the cookbook for it. Currently the only supported way to proxy traffic for 'guix-daemon' is by setting a HTTP proxy[1] the drawback is that DNS query will still be in clear and wont go trough the proxy in contrast to a SOCKS5 proxy where the query will happen on the other side of the proxy. So setting guix-daemon to use tor by this mean can put people at risk when they think that all their guix traffic go trough tor™. A better approach would be to have a mean to "torify" services with torsocks, it would proxy the service's traffic (DNS included) trough tor via a SOCKS5 proxy. I don't know how to implement such feature tho. But a generic method to modify a shepherd service from the configuration could also be helpful to start service in containers based on the user need instead of being tied to The two following examples are **insecure** since the DNS traffic won't go trough tor. Here is a example of a system configuration: --8<---cut here---start->8--- (use-modules (gnu)) (use-service-module base networking) (operating-system … (services (append (list ((service tor-service-type (tor-configuration (config-file (plain-file "tor-config" "HTTPTunnelPort 127.0.0.1:9052")) (modify-services %base-services (guix-service-type config => (guix-configuration (http-proxy "http://localhost:9052;))) --8<---cut here---end--->8--- Following is an example on how to do it, in a less Guixy way, by using privoxy; it assume a default configured tor service is already present on your system.. --8<---cut here---start->8--- $ sudo herd start tor Service tor has been started. $ cat privoxy-tor.conf forward-socks5 / localhost:9050 . $ privoxy privoxy-tor.conf $ sudo herd set-http-proxy guix-daemon http://localhost:8118 changing HTTP/HTTPS proxy of 'guix-daemon' to "http://localhost:8118;... Service guix-daemon has been stopped. Service guix-daemon has been started. $ LANGUAGE=C guix build audacity substitute: mise à jour des substituts depuis « https://ci.guix.gnu.org »... 100.0 % The following derivation will be built: /gnu/store/lz209608z1lw3zbw33hyp3rsx1az2khi-audacity-2.3.3.drv 38,1 MB will be downloaded: /gnu/store/ssc6x6dsxz3f5b26p84d02z42lcj8p3h-lv2-1.18.0 /gnu/store/przpq26zaj858zmyayns6i4y13hr3d32-suil-0.10.6 /gnu/store/y74d9xvxl33vra8aq9p3ywsvc8yaz04w-portmidi-217 /gnu/store/2xmhv8ra20bhj73d3qirqbskdpq3lsim-vamp-2.6 /gnu/store/1j3nhsacnqilyr4gqccfh9bzb33xvqak-audacity-2.3.3.tar.xz /gnu/store/bpp52ds6g1709s2h1ln1i81hz4v7gw6h-serd-0.30.4 /gnu/store/vwx0zf02r9vxja8rmy6vs8w81907w3bz-sord-0.16.4 /gnu/store/0ci33f2s2bm9rwply6b47sj6vn10ybaw-sratom-0.6.4 /gnu/store/b5liczxlxxdhf9p8s61mx21v9x7rbsbi-lilv-0.24.6 substituting /gnu/store/1j3nhsacnqilyr4gqccfh9bzb33xvqak-audacity-2.3.3.tar.xz... downloading from https://ci.guix.gnu.org/nar/1j3nhsacnqilyr4gqccfh9bzb33xvqak-audacity-2.3.3.tar.xz ... audacity-2.3.3.tar.xz 35.7MiB 548KiB/s 00:02 [ ] 3.1 --8<---cut here---end--->8--- If during the download of the substitutes the tor service is stopped with “sudo herd stop tor” guix will stop too and complains about a network error, as expected. The above setup can be tweaked to proxy trough SSH instead by doing port forwarding trough SOCKS “ssh -D 8008 my-host” (don't forget to adjust the privoxy config for the port you are forwarding). PS: Do not try to modify the shepherd guix-daemon service to use torsocks or you'll wont be able to reconfigure, switch-generation or rollback: “guix system: error: while setting up the build environment: cannot open IP socket: Operation not permitted”. PPS: The substitutes server are available trough tor “--substitute-urls=http://bp7o7ckwlewr4slm.onion”. [0]: http://logs.guix.gnu.org/guix/2020-05-12.log#093952 [1]: https://guix.gnu.org/manual/devel/en/html_node/Proxy-Settings.html#Proxy-Settings - Brice
foreign arch binary tarball creation problem
I am trying to build binary tarball for foreign OS / arches, and this is failing, in an unhelpful way. This is guix master branch with a few patches (mostly to etc/guix-install.sh, so I assume they are not the cause of the problem seen here) I have built the i686 & x86_64 ones without any problem. I can create the guix packs: -->88<-- vince@guix ~/dev/repo/guix [env]$ ./pre-inst-env guix pack --target="aarch64-linux-gnu" --localstatedir --profile-name=current-guix guix /gnu/store/d3h12sglx1jb073ybdz39v2qd7ir6xf6-tarball-pack.tar.gz -->88<-- vince@guix ~/dev/repo/guix [env]$ ./pre-inst-env guix pack --target="arm-linux-gnueabihf" --localstatedir --profile-name=current-guix guix /gnu/store/4ab2zgvfvgxlgvm0l07iwa6b1laqwcdj-tarball-pack.tar.gz But building the tarballs fails: -->88<-- vince@guix ~/dev/repo/guix [env]$ ./pre-inst-env make "guix-binary.aarch64-linux.tar.xz" GEN guix-binary.aarch64-linux.tar.xz guix pack: package 'guile3.0-guix' has been superseded by 'guix' The following derivation will be built: /gnu/store/4xwf7y6r1p6q9v2vkvgrxri9r6yvbs1p-guix-1.1.0-4.ce97922.drv building /gnu/store/4xwf7y6r1p6q9v2vkvgrxri9r6yvbs1p-guix-1.1.0-4.ce97922.drv... |builder for `/gnu/store/4xwf7y6r1p6q9v2vkvgrxri9r6yvbs1p-guix-1.1.0-4.ce97922.drv' failed with exit code 1 build of /gnu/store/4xwf7y6r1p6q9v2vkvgrxri9r6yvbs1p-guix-1.1.0-4.ce97922.drv failed View build log at '/var/log/guix/drvs/4x/wf7y6r1p6q9v2vkvgrxri9r6yvbs1p-guix-1.1.0-4.ce97922.drv.bz2'. guix pack: error: build of `/gnu/store/4xwf7y6r1p6q9v2vkvgrxri9r6yvbs1p-guix-1.1.0-4.ce97922.drv' failed cp: cannot stat '': No such file or directory mv: cannot stat 'guix-binary.aarch64-linux.tar.xz.tmp': No such file or directory make: *** [Makefile:6166: guix-binary.aarch64-linux.tar.xz] Error 1 -->88<-- vince@guix ~/dev/repo/guix [env]$ ./pre-inst-env make "guix-binary.armhf-linux.tar.xz" GEN guix-binary.armhf-linux.tar.xz guix pack: package 'guile3.0-guix' has been superseded by 'guix' The following derivation will be built: /gnu/store/hcyy8pgpjs5dga5rj47xjy7s0v8rkd33-guix-1.1.0-4.ce97922.drv building /gnu/store/hcyy8pgpjs5dga5rj47xjy7s0v8rkd33-guix-1.1.0-4.ce97922.drv... |builder for `/gnu/store/hcyy8pgpjs5dga5rj47xjy7s0v8rkd33-guix-1.1.0-4.ce97922.drv' failed with exit code 1 build of /gnu/store/hcyy8pgpjs5dga5rj47xjy7s0v8rkd33-guix-1.1.0-4.ce97922.drv failed View build log at '/var/log/guix/drvs/hc/yy8pgpjs5dga5rj47xjy7s0v8rkd33-guix-1.1.0-4.ce97922.drv.bz2'. guix pack: error: build of `/gnu/store/hcyy8pgpjs5dga5rj47xjy7s0v8rkd33-guix-1.1.0-4.ce97922.drv' failed cp: cannot stat '': No such file or directory mv: cannot stat 'guix-binary.armhf-linux.tar.xz.tmp': No such file or directory make: *** [Makefile:6166: guix-binary.armhf-linux.tar.xz] Error 1 -->88<-- How are the official tarballs created ? What am I doing wrong ? -- Vincent Legoll
Re: Towards a graphical installer?
Pierre Neidhardt writes: > Errr... Sorry, I was distracted yesterday, the NLNet grant is actually > for a graphical _package manager_, not an installer! :p > > That said, I'm interested in helping with it too! :) Still awesome :) I'm looking forward to seeing your work evolve! :) - Chris
Re: [PATCH] ext2fs: Update to upstream Hurd-reserved xattr index for "gnu.*".
Jan Nieuwenhuizen, le mar. 12 mai 2020 16:12:34 +0200, a ecrit: > setfattr --name=gnu.translator --value='/hurd/pflocal\0' /mnt/servers/socket/1 man setfattr says If the given string is enclosed in double quotes, the inner string is treated as text. In that case, backslashes and double quotes have special meanings and need to be escaped by a preceding backslash. so I guess it needs setfattr --name=gnu.translator --value='"/hurd/pflocal\0"' /mnt/servers/socket/1 to actually interpret \0 > --8<---cut here---start->8--- > fsck --yes --force / > fsysopts / --writable > mv /servers/socket/1 /servers/socket/1-linux > touch /servers/socket/1 > setfattr --name=gnu.translator --value='/hurd/pflocal\0' /servers/socket/1 Note that glibc's setxattr, i.e. _hurd_xattr_set, translates that into a __file_set_translator() RPC call. Did you pass the proper option to make ext2fs record the translator as xattr instead of passive record? > And I guess there must be an incompatibility between Linux and the Hurd > in how setfattr embeds the xattr attributes into the file system. > > How to best "diff" this aspect in the file system; how to proceed? debugfs can be used for that. > Inspired by Shengyu's GSoC code that simply seemed to use fprintf for > debbugging, I tried adding some debug printing in inode.c > > fprintf (stderr, "gnu.translator[%d,%d]=%s\n", datalen, strlen (*namep), > *namep); Printf is the simplest way to make sure things are happening the way one wants, yes. Note however that in the case of translators even the output on stderr is buffered, so you need to flush it with fflush(stderr). Even safer is to use snprintf + mach_print(). > but that does not seem to work, More precisely? I'll assume "does not show up". If your print doesn't show up, try to put a print in other places which are definitely to be called such as in diskfs_user_read_node(). If those come up, then it means the code you put your prints is not even called, so put prints in code you thought was calling it etc. up to the RPC that you thought would be called, then jump to libc which was supposed to be making the RPC call, etc. Samuel
Re: Not sure my patch reached guix-patches
Well thanks for spam-checking, that's an arduous job :) ! Cheers, Edouard. Tobias Geerinckx-Rice writes: > Edouard, > > Thanks for patching Guix! > > Edouard Klein 写道： >> Never mind, I just got the answer from the automated system with the bug >> number and I see it in the archive now. It just takes a little more time >> than I expected. > > The automated system isn't entirely automated ;-) > > Posts by new addresses are spam-checked by a human. This applies to all Guix > mailing lists, which is why your ‘hmm what's up’ and ‘oh never mind’ mails > will > hit the list at exactly the same time. > > Kind regards, > > T G-R
[PATCH] ext2fs: Update to upstream Hurd-reserved xattr index for "gnu.*".
Hello,
I have looked a bit further into upstream xattr support and and have
been testing that using the two attached patches. As you can see,
upstream reserved INDEX 10 for the Hurd, but the Hurd has been using
INDEX 7.
The (trivial) patch for the Hurd to change this should be OK, but until
this all fully works I'm just a bit less certain about the Linux patch.
Anyway, using the patched Linux we can add gnu.translator attributes to
files that are recognized by Linux (on a Hurd file system) as well as by
the Hurd.
So now we can actually do this
--8<---cut here---start->8---
dd if=/dev/zero of=file bs=1k count=1000
losetup /dev/loop0 file
mke2fs -t ext2 -o hurd -O ext_attr /dev/loop0
mount -t ext2 -o x-xattr-translator-records /dev/loop0 /mnt
mkdir -p /mnt/servers/socket
touch /mnt/servers/socket/1
setfattr --name=gnu.translator --value='/hurd/pflocal\0' /mnt/servers/socket/1
getfattr --name=gnu.translator /mnt/servers/socket/1
# file: 1
gnu.translator="/hurd/pflocal"
--8<---cut here---end--->8---
(on GNU/Linux), and I am using that now in Guix to cross build a
vm-image for the Hurd.
So far, so good. However, combining these does not work yet. When I
reduce libexec/runsystem to something like this
--8<---cut here---start->8---
#! /gnu/store/s8pcby4hjxf7d4pfzrwd3ngd813i8skw-bash-minimal-5.0.16/bin/bash
# XXX Guile needs pipe support for its finalizer thread to start
PATH=/gnu/store/6is7b5xjdfdwzym5cfhjf7jpa3824h42-hurd-0.9-1.91a5167/bin:/gnu/store/6is7b5xjdfdwzym5cfhjf7jpa3824h42-hurd-0.9-1.91a5167/sbin:/gnu/store/a4vdhbfflmbpc346lsvl3v0plplmg5ma-attr-2.4.48/bin:/gnu/store/y9vicb9spdy9lfsipv75yy5aavwf5xyn-coreutils-8.32/bin:/gnu/store/s5kx9ybvdkxcyg1243rl4fdq139b-sed-4.8/bin:/gnu/store/wy7k8v4iik6kzh9vw1fjzcnj7jhsh5fv-util-linux-2.35.1/sbin
echo foo | sed s/o/O/
echo Starting
/gnu/store/6is7b5xjdfdwzym5cfhjf7jpa3824h42-hurd-0.9-1.91a5167/libexec/rc ...
exec /gnu/store/6is7b5xjdfdwzym5cfhjf7jpa3824h42-hurd-0.9-1.91a5167/libexec/rc
--8<---cut here---end--->8---
the Hurd says
/gnu/store/6is7b5xjdfdwzym5cfhjf7jpa3824h42-hurd-0.9-1.91a5167/runsystem:
pipe error: Translator died
When I leave out the echo | sed pipe, starting Guile just hangs.
When I insert this
--8<---cut here---start->8---
fsck --yes --force /
fsysopts / --writable
mv /servers/socket/1 /servers/socket/1-linux
touch /servers/socket/1
setfattr --name=gnu.translator --value='/hurd/pflocal\0' /servers/socket/1
--8<---cut here---end--->8---
it works: So, we're getting real close! \o/
And I guess there must be an incompatibility between Linux and the Hurd
in how setfattr embeds the xattr attributes into the file system.
How to best "diff" this aspect in the file system; how to proceed?
Inspired by Shengyu's GSoC code that simply seemed to use fprintf for
debbugging, I tried adding some debug printing in inode.c
fprintf (stderr, "gnu.translator[%d,%d]=%s\n", datalen, strlen (*namep),
*namep);
but that does not seem to work, or I am looking in the wrong place. Ideas?
Greetings,
janneke
>From 75cb948c575fca3962c4cce115d31dd178bc389f Mon Sep 17 00:00:00 2001
From: "Jan (janneke) Nieuwenhuizen"
Date: Tue, 12 May 2020 07:39:59 +0200
Subject: [PATCH] ext2fs: Update to upstream Hurd-reserved xattr index for
"gnu.*".
See
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3980bd3b406addb327d858aebd19e229ea340b9a
This supports setting (and reading) of passive trasnlators from
GNU/Linux, e.g.
dd if=/dev/zero of=file bs=1k count=1000
losetup /dev/loop0 file
mke2fs -t ext2 -o hurd -O ext_attr /dev/loop0
mount -t ext2 -o x-xattr-translator-records /dev/loop0 /mnt
mkdir -p /mnt/servers/socket
touch /mnt/servers/socket/1
setfattr --name=gnu.translator --value='/hurd/pflocal\0' /mnt/servers/socket/1
getfattr --name=gnu.translator /mnt/servers/socket/1
# file: 1
gnu.translator="/hurd/pflocal"
* ext2fs/xattr.c (struct _xattr_prefix): For "gnu.*", use index for
the Hurd (10).
---
ext2fs/xattr.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/ext2fs/xattr.c b/ext2fs/xattr.c
index f6ea0f39..78458214 100644
--- a/ext2fs/xattr.c
+++ b/ext2fs/xattr.c
@@ -1,6 +1,6 @@
/* Ext2 support for extended attributes
- Copyright (C) 2006, 2016 Free Software Foundation, Inc.
+ Copyright (C) 2006, 2016, 2020 Free Software Foundation, Inc.
Written by Thadeu Lima de Souza Cascardo
and Shengyu Zhang
@@ -39,7 +39,7 @@ xattr_prefixes[] =
{
1, "user.", sizeof "user." - 1},
{
- 7, "gnu.", sizeof "gnu." - 1},
+ 10, "gnu.", sizeof "gnu." - 1},
{
0, NULL, 0}
};
--
2.26.0
>From 475eb7cfae390d9118a5420df90b979b4ec78aa3 Mon Sep 17 00:00:00 2001
From: "Jan (janneke) Nieuwenhuizen"
Date: Mon, 11 May 2020 18:43:44
Bundler 2
Hi Guix, In the course of some fairly involved yak-shaving, I found the need to run a Ruby package, and tried running `guix environment --ad-hoc bundler ruby`. However, running it produced an error: $ bundle install Traceback (most recent call last): 2: from /gnu/store/5flpa8h2adwb86n49r7p3mbp11p0jafr-profile/bin/bundle:23:in `' 1: from /gnu/store/9yqh0g1p5bmxar8dlfp84j4py3j631jv-ruby-2.6.5/lib/ruby/2.6.0/rubygems.rb:302:in `activate_bin_path' /gnu/store/9yqh0g1p5bmxar8dlfp84j4py3j631jv-ruby-2.6.5/lib/ruby/2.6.0/rubygems.rb:283:in `find_spec_for_exe': Could not find 'bundler' (2.1.0.pre.2) required by your /home/josh/c/gnome-dbus-emulation-wlr/Gemfile.lock. (Gem::GemNotFoundException) To update to the latest version installed on your system, run `bundle update --bundler`. To install the missing version, run `gem install bundler:2.1.0.pre.2` Indeed I see that gnu/packages/ruby.scm only packages Bundler v1.17.3, though Bundler 2 was released in January 2019 [0]. I'm not hugely familiar with the Ruby ecosystem, but reading the release announcement suggests that they expect users/developers to have both Bundler 1 and Bundler 2 available. If I hadn't seen this, I'd have gone ahead and submitted a patch simply upgrading the Bundler package definition, but I'm not sure if that will then immediately break every package depending on it that expects Bundler 1. Is this a valid concern? Should Guix provide packages for both Bundler 1 and Bundler 2, or would just Bundler 2 be sufficient? I'll still write a definition for the new version, but I'll hold off submitting a patch until I've had some feedback. [0]: https://bundler.io/blog/2019/01/03/announcing-bundler-2.html Thanks, -- Josh Holland
Re: Not sure my patch reached guix-patches
Edouard, Thanks for patching Guix! Edouard Klein 写道： Never mind, I just got the answer from the automated system with the bug number and I see it in the archive now. It just takes a little more time than I expected. The automated system isn't entirely automated ;-) Posts by new addresses are spam-checked by a human. This applies to all Guix mailing lists, which is why your ‘hmm what's up’ and ‘oh never mind’ mails will hit the list at exactly the same time. Kind regards, T G-R signature.asc Description: PGP signature
Not sure my patch reached guix-patches
Hi all, I've sent my first patch (adding a Python package) to the guix-patches mailing list as instructed in the documentation, but I don't see my message in the list archive https://lists.gnu.org/archive/html/guix-patches/2020-05/index.html and I don't have any acknowledgment of the message. I just wanted to make sure it's not lost in the ether. Cheers, Edouard.
Re: Not sure my patch reached guix-patches
Never mind, I just got the answer from the automated system with the bug number and I see it in the archive now. It just takes a little more time than I expected. Sorry for the noise. Edouard Klein writes: > Hi all, > > I've sent my first patch (adding a Python package) to the guix-patches > mailing list as instructed in the documentation, but I don't see my > message in the list archive > > https://lists.gnu.org/archive/html/guix-patches/2020-05/index.html > > and I don't have any acknowledgment of the message. I just wanted to > make sure it's not lost in the ether. > > Cheers, > > Edouard.
New Russian PO file for 'guix-manual' (version 1.1.0-pre2)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'guix-manual' has been submitted by the Russian team of translators. The file is available at: https://translationproject.org/latest/guix-manual/ru.po (We can arrange things so that in the future such files are automatically e-mailed to you when they arrive. Ask at the address below if you want this.) All other PO files for your package are available in: https://translationproject.org/latest/guix-manual/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: https://translationproject.org/domain/guix-manual.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
Re: Towards a graphical installer?
On 5/12/20 8:10 AM, dftxbs3e wrote: > > I was thinking that designing a good TUI installer would be sufficient, > I find the latest Subiquity Ubuntu installer very beautiful and great! > > Have a look: https://invidio.us/watch?v=Glyj4BjAhME > > Git: https://github.com/CanonicalLtd/subiquity > > Do you think there's really a point in doing GUI? > > Also, if GUI, is there a way to do that with more minimalism while > getting the desired features? > Sorry for the second mail but I have another thought : I am thinking since a while that GNU Guix is the perfect platform to write something like OpenSUSE's YaST, with a good base and many frontends such as TUI, GUI, web. It would be awesome. signature.asc Description: OpenPGP digital signature
Re: Towards a graphical installer?
On 5/11/20 3:27 PM, Mathieu Othacehe wrote: > > Hello, > > A way to move forward with the installer could be to propose an ISO > image starting a desktop-environment by default. The attached patch > modifies the installation image so that it starts a GNOME session. The > installer is then automatically started, inside a gnome-terminal. > > The resulting ISO image is bigger: 3.9G without compression and 1.7G > with compression. > > Now, I'm not sure this is something we want to merge as-is. Maybe, it's > time to port the installer to a GTK3 application, or a Web > application. As we already have something working, porting (gnu > installer) to a new graphical backend, could be not so hard. > > I don't think I'll have the bandwidth to do this anytime soon, but is > someone is interested, I'm willing to help/review :). > > Thanks, > > Mathieu > I was thinking that designing a good TUI installer would be sufficient, I find the latest Subiquity Ubuntu installer very beautiful and great! Have a look: https://invidio.us/watch?v=Glyj4BjAhME Git: https://github.com/CanonicalLtd/subiquity Do you think there's really a point in doing GUI? Also, if GUI, is there a way to do that with more minimalism while getting the desired features? signature.asc Description: OpenPGP digital signature
