Re: shepherd GEXP module import mystery
hi Felix, Ludo, > > a start GEXP of my service sees bindings that come from the module > > called (shepherd support), but i have no idea who and where imports > > that module. > > > Without code it's hazardous to speculate, but could the Guix service > (gnu service mcron) cause that issue when it is being logged? unfortunately it's a complex web of stuff, but i managed to make a small reproducer that is attaced. it can be run with: $(guix system --no-graphic vm reproducer.scm) and in the VM (must use fold, because it's a dumb terminal): cat /var/log/messages | fold -150 to my surprise this one does list (shepherd support) in the module-use list. and i realized why: the logging infrastructure somewhere siently truncates the lines, and in my original case that module was chopped off. not that i understand everything here... e.g. why are there several (guix build utils) modules? *** reproducer gexp speaking, current module: #, module-uses: ( # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #), ringbuffer: # so, the only mystery left is that i still don't know where it is imported into the unnamed package in which the GEXPs are compiled/loaded, and whether that is intended. maybe it's part of the shepherd API that (shepherd support) is made available for the service GEXPs? looking at the public definitions in (shepherd support), it's not obvious that those are meant to be available for the users of shepherd, though. Ludo? > In my code tree, which is a month behind, (gnu services mcron) is the > only Guix service that imports (shepherd support). it's a good hint, but that could only cause this if all the service GEXPs were loaded into the same module, but that would have already broken things in countless other ways. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “We are products of our past, but we don't have to be prisoners of it.” — Rick Warren (1954–) ;; Run with something like this: ;; $(guix system --no-graphic vm reproducer.scm) (define-module (reproducer) #:use-module (gnu system) #:use-module (gnu system shadow) #:use-module (gnu system nss) #:use-module (gnu system vm) #:use-module (gnu tests) #:use-module (gnu services) #:use-module (gnu services base) #:use-module (gnu services dbus) #:use-module (gnu services shepherd) #:use-module (gnu packages admin) #:use-module (gnu packages base) #:use-module (gnu packages bash) #:use-module (gnu packages certs) #:use-module (gnu packages package-management) #:use-module (gnu packages linux) #:use-module (guix gexp) #:use-module (guix git) #:use-module (guix git-download) #:use-module (guix store) #:use-module (guix modules) #:use-module (guix packages) #:use-module (srfi srfi-1) #:use-module (ice-9 match)) (operating-system (inherit %simple-os) (services (cons* (simple-service 'reproducer shepherd-root-service-type (list (shepherd-service (requirement '(file-systems)) (provision '(reproducer)) (documentation "") (start #~(begin (lambda _ (format #t "*** reproducer gexp speaking, \ current module: ~A, \ module-uses: ~A, \ ringbuffer: ~A~%" (current-module) (module-uses (current-module)) (and=> (module-variable (current-module) 'ring-buffer) variable-ref)) 0)) %base-services)))
Re: Request-For-Comment process: concrete implementation
Hi Efraim, Thnaks for your comments. On Thu, 23 Nov 2023 at 09:04, Efraim Flashner wrote: > Actually, in terms of suggestions, I'd add the rfc/ folder in > etc/teams.scm to set guix-devel as one of the team members. Good idea! Cheers, simon
Re: Moment de convivialité Guix@Paris en nov… euh… décembre
salut, On Thu, 23 Nov 2023 at 09:18, Tanguy LE CARROUR wrote: > Jeudi 7 décembre à 19h, se tiendra la troisième édition de Guix@Paris > ouverte au public. > Comme la dernière fois, il sera possible de participer à distance (*cf* > ci-dessous). Et pour les présents, quelques stickers Guix. :-) À très tantôt, simon
Re: [maintenance] Compressed JSON files and served file extension?
Hi Ludo, On Thu, 16 Nov 2023 at 15:40, Ludovic Courtès wrote: > That said, if you become aware of actual breakage, we can revisit this! The actual breakage is my own interaction with this file. :-) Again, it happened to me yesterday. By habits, I do: $ wget https://guix.gnu.org/sources.json $ cat sources.json | jq | head Then, --8<---cut here---start->8--- parse error: Invalid numeric literal at line 1, column 16 cat: write error: Broken pipe --8<---cut here---end--->8--- Well, we are 6 days later my last message, 12 days after your message and more than one month after my report; and again the same mistake. That’s mistake because it does not jump to my eyes that the file is compressed. Yeah, I could do many on my side as change my habits, as use curl, as have a smarter cat, as write a note, as have a better memory, as … However, the simplest still appears to me to have the extension reflecting the format of the file. Similarly as it is ’sources.json’ and not just ’sources’. Cheers, simon
Re: [maintenance] Compressed JSON files and served file extension?
Hi,
On Mon, 20 Nov 2023 at 14:03, Attila Lendvai wrote:
> TL;DR the filename shouldn't contain the .gz extension, and the HTTP
> standard is crap ("If no Accept-Encoding field is present in a
> request, the server MAY assume that the client will accept any content
> coding.").
>
> use curl --compressed
And if I do not want to use curl but instead another tool as wget? :-)
Cheers,
simon
Re: [maintenance] Compressed JSON files and served file extension?
On 2023-11-28 14:37:55 +0100, Simon Tournier wrote:
> Hi,
>
> On Mon, 20 Nov 2023 at 14:03, Attila Lendvai wrote:
>
> > TL;DR the filename shouldn't contain the .gz extension, and the HTTP
> > standard is crap ("If no Accept-Encoding field is present in a
> > request, the server MAY assume that the client will accept any content
> > coding.").
> >
> > use curl --compressed
>
> And if I do not want to use curl but instead another tool as wget? :-)
You could invoke the wget with -E flag I guess.
>
> Cheers,
> simon
>
>
>
--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.
signature.asc
Description: PGP signature
Re: [maintenance] Compressed JSON files and served file extension?
On 2023-11-28 14:48:05 +0100, Simon Tournier wrote: > Hi Ludo, > > On Thu, 16 Nov 2023 at 15:40, Ludovic Courtès wrote: > > > That said, if you become aware of actual breakage, we can revisit this! > > The actual breakage is my own interaction with this file. :-) > > Again, it happened to me yesterday. By habits, I do: > > $ wget https://guix.gnu.org/sources.json > $ cat sources.json | jq | head > > Then, > > --8<---cut here---start->8--- > parse error: Invalid numeric literal at line 1, column 16 > cat: write error: Broken pipe > --8<---cut here---end--->8--- > > Well, we are 6 days later my last message, 12 days after your message > and more than one month after my report; and again the same mistake. > That’s mistake because it does not jump to my eyes that the file is > compressed. Yeah, I could do many on my side as change my habits, as > use curl, as have a smarter cat, as write a note, as have a better > memory, as … > > However, the simplest still appears to me to have the extension > reflecting the format of the file. Similarly as it is ’sources.json’ > and not just ’sources’. But the problem is that the extension does reflect the format of the file. The Content-Encoding is just for transmission, it does not describe the file itself. It should be thought of as an implementation detail. Same way you do not really care if you get the file over HTTP 1.1 or HTTP 2.0. This just sound like a bug in wget, I wonder if there is a bug report and/or good reason to behave like this... Would it be possible to provide both files? Sources.json.gz would *not* set the content-encoding (and I guess content-type would be gzip?), so that one could pick between https://guix.gnu.org/sources.json and https://guix.gnu.org/sources.json.gz depending on their preference? Have a nice day, Tomas -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
Re: Divvying up service definitions
Hi Efraim, On 2023-11-09 07:15, Efraim Flashner wrote: > I assume the define-maybe's aren't public, so I'd guess that shouldn't > cause a problem as long as they aren't exported. They're not public but they override definitions within the same file if more than one (define-maybe foo) is present (e.g. when (prefix bar-) is used) > Or moving the define-maybes to the top of the file and reusing them > between services. Is that a possibility? Due to their non-hygienic nature and the (prefix foo-) argument this can't work. IMO we should look into replacing this define-maybe business with something like SRFI-189 (by integrating it into Guile). -- Furthermore, I consider that nonfree software must be eradicated. Cheers, Bruno. OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [maintenance] Compressed JSON files and served file extension?
> And if I do not want to use curl but instead another tool as wget? :-) then maybe complain to the authors that it doesn't comply with the standard? :) here's the bug report BTW: Wget not honouring Content-Encoding: gzip https://savannah.gnu.org/bugs/?61649 or use wget2 instead. i guess they didn't fix it in wget because they didn't want to break "backwards compatibility". (remember: if it's not backwards, it's not compatible! :) happy hacking, -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “We cannot train our babies not to need us. Whether it's the middle of the day or the middle of the night, their needs are real and valid, including the need for a simple human touch. A 'trained' baby may give up on his needs being met, but the need is still there, just not the trust.” — L. R. Knost
