<dissent>hey guix, i'm getting this message: 'guix remove: error: opening lock file `/var/guix/temproots/13533': No space left on device' even though I still have 35 GB left on my HD. <slyfox_>could be inode exhaustion? 'df -i' should tell <drakonis>its not for students only as of next year <awb99_>I want to run a script/binary forever ln a guix system. In sysyemctl I know the config for that. Anyone knows a guix solution? <awb99_>So on Crash the app should be restarted, wirh some sensible retries settings of course. <bavier[m]>a shepherd service would be the natural solution, I think. Users can run their own services. esp with `guix home`. <robin>awb99_, i'm curious too, i know how to start/restart/stop services but haven't written one yet <awb99_>Yes for normal packages say nginx itbis fully transparent <robin>(and i want to package openafs someday, so i suspect i'll have to learn how to write services eventually ;)) <awb99_>But there are many apps that a user might want to run forever. <awb99_>I think it shoukd be easy because I can think if 10 apps that I want to run always that other people will onky want to run on demand <bavier[m]>awb99_: see "Shepherd Home Service" e.g. in the guix manual <awb99_>Bavier.. Do shepherd home services akso work system wide? <awb99_>I wantbto runn the apps irrespective if a userbus logged in <apteryx>sneek: re loaders.cache yes concatenating them would be an option, but it's not guaranteed to be complete either since loaders.cache files are currently only produced by a glib-or-gtk-build-system phase (i.e. any other build system may omit it). Somewhat unlikely but possible. <apteryx>sneek: later tell civodul re loaders.cache yes concatenating them would be an option, but it's not guaranteed to be complete either since loaders.cache files are currently only produced by a glib-or-gtk-build-system phase (i.e. any other build system may omit it). Somewhat unlikely but possible. <bdju>how do you get extensions for ungoogled-chromium-wayland? can it be done without signing in to google? I want to install vimium <bdju>I saw source archives under the tags but nothing that seemed like an extension file <Noisytoot>bdju, I think you can install unpacked extensions (from the source directory) ***jackhill is now known as KM4MBG
***KM4MBG is now known as jackhill
<bdju>zamfofex: wow! even better. thanks so much <apteryx>what is this: guix build: error: gcry_md_hash_buffer: Function not implemented <apteryx>comes from: guix build: warning: failed to load '(gnu packages browser-extensions)': Function not implemented <apteryx>OK, it was caused by './pre-inst-env guix environment guix' instead of 'guix environment guix'. Strange. <allana>Hi #guix! I'm currently introducing myself to guix home. Does anyone know of any examples where I can find how to update an existing environment variable in a home service? For example I want to add a custom path to XDG_DATA_DIRS <vivien>There is an example where HISTFILE is defined with shell cod <vivien>I would extend XDG_DATA_DIRS like that <mahmooz>is it possible to write a package without build-system? <mahmooz>thing is what im trying to install doesnt require compilation <mahmooz>just tryna package my dotfiles into a guix package <vivien>mahmooz, you might want the trivial-build-system, or copy-build-system <allana>Hi guix, currently trying to learn guix home. When applying specification->package to items in a list, I get errors on any package name entries with a ":". For example, there are no problems with "git", but when I have a package name as "git:send-email", an error occurs -- guix home: error: git:send-email: unknown package <allana>Have I found a bug, or is there an obvious method that I should be using? Can share a pastebin of my home config if anyone is interested. <zamfofex>allana: I think ‘git:send-email’ is meant to represent the ‘send-email’ output of the ‘git’ package. <zamfofex>I’m not sure about how ‘guix home’ works, or how that affects you, though. <allana>zamfofex: this list of packages was actually generated by the auto import tool of my current profile <vivien>allana, I’m not sure the output is required, if you just require "git" it should install all outputs, including send-email. I’m not sure, you should test it. <vivien>If it does not work, you will need to receive 2 values from (specification->package+output "git" #:output "send-email"), and include them in your packages list <vivien>(packages `(,@(map specification->package '("x" "y" "z")) ,@(call-with-values (specification->package+output "git" #:output "send-email") list))) ;; untested <vivien>Sorry, (call-with-values (lambda () ...) list) <zamfofex>sneek: later tell civodul In case you are interested, I was actually able to update the Hurd packages as I mentioned, and everything seems to actually be working well! I was even able to run netdde and everything, and it seems to be working! Now I only need to figure out how to assign an IP address for my computer manually. <vivien>(the specification->package+output does not work the way I thought, so it does not work) <allana>vivien: Thanks for looking in to this for me. <vivien>Does using just the git package provide you the send-email output? <allana>I have a similar issue with bind:utils <allana>vivien: I found the solution. Using "specification->package+output" in place of "specification->package" totally works. <allana>So, thanks for this help. I would have struggled with this and gave up without your guidance. <vivien>Guix home is still an experimental feature, some things won’t work. As of today, the only problem I have is dbus service activation does not work <vivien>So, I had to run dring manually (I later turned it into a shepherd home service) so that jami can work <zamfofex>jpoiret: Thank you! It’s not much, but it took me a long time to put everything together, so I’m really happy about it! <jpoiret>unless there's something seriously missing, i think it deserves a patch on master <rekado_>vivien: do you have permissions to push to the repo? <vivien>rekado_, the style commit should be ignored in that issue <vivien>civodul told me the styling will be made for all packages at once <zamfofex>jpoiret: I haven’t tested it on master, only on ‘core-updates-frozen’. I’m not sure whether it will work on master because I thought I saw a error that I assumed was a mismatch with the glibc version when trying it out, but maybe the error was actually distinct. <rekado_>vivien: okay, I’ll apply the first commit today. <jpoiret>zamfofex: i'm also running c-u-f so I couldn't say <zamfofex>Ah, also, ‘qemu-minimal’ doesn’t seem to be able to build successfully in ‘core-updates-frozen’. It hangs/freezes on some test. I disabled the tests to be able to use it, but I think it’s worthwhile to point out, because it probably warrants some investigation. <vivien>zamfofex, I can build qemu-minimal on core-updates-frozen without a problem <vivien>That’s /gnu/store/qaqj76g289z5v59hl6c6ckgpwvy1jrrq-qemu-minimal-6.1.0.drv <aru>hey, how's zfs support these days? <tschilptschilp23>Hi! Maybe not the perfect place to ask (python) -- but maybe someone quickly understands my error and can rule it out anyway. <tschilptschilp23>The object is a dictionary with a list as value. The third item of the list is a list itself -- that's the one I want to replace. What surprises me, that if I try to edit it for a single key -- it does it for all of them! I'd expect to have just the values for the given key changed. The code below is straight from my guix-ipython-session, any hint appreciated! <wleslie>if you initialise a dict like this, they all share the same list as a value <wleslie>perhaps rather than fromkeys you could {k : ["value0", "value1", ...] for k in dictkeys} <wleslie>or dict((k, ["value0", "value1", ...]) for k in dictkeys) if you're on python 2 <wleslie>otherwise, you will need to copy the value you want to update <wleslie>the idiomatic way would be xs = list(testdict['a']); xs[2] = changed_items; testdict['a'] = xs <roptat>herd hangs on my server, I can't do anything with it (not even "herd status") <roptat>I can't even reboot, as this seems to ask herd to stop services? ***tricon-afk is now known as tricon
<tschilptschilp23>wieslie: thanks for the hint, that helped a lot. I did not expect that I have to rewrite the whole value item (gives me some thought about my object-structure....)! <tschilptschilp23>wieslie: ha, my real dict is not initialized that way, but rather filled in a different/standard manner, so I actually can act on the items, as planned ;) <wleslie>no stress at all - I know that feeling. it's a quarter past midnight here, a good time to head. <excalamus>well, hell. It looks like icecat updated and, aside from not rendering things correctly anymore, all my bookmarks are gone <vivien>excalamus, the bookmarks tab is gone, but the bookmarks are still there <wleslie>evidently mozilla considered your bookmarks an unneccessary attack surface and removed them <excalamus>where? When I look through the interface, I can't find them. For example, they're not visible in manage bookmarks <excalamus>I can find no trace. Looks like everything is stock again <civodul>efraim: hey! are the slides of your talk on-line? (or in maintenance.git?) <sneek>Welcome back civodul, you have 3 messages! <sneek>civodul, apteryx says: re loaders.cache yes concatenating them would be an option, but it's not guaranteed to be complete either since loaders.cache files are currently only produced by a glib-or-gtk-build-system phase (i.e. any other build system may omit it). Somewhat unlikely but possible. <sneek>civodul, zamfofex says: In case you are interested, I was actually able to update the Hurd packages as I mentioned, and everything seems to actually be working well! I was even able to run netdde and everything, and it seems to be working! Now I only need to figure out how to assign an IP address for my computer manually. <civodul>apteryx: that's ok though; in that case the package should just be fixed to use glib-or-gtk-build-system, no? <civodul>was it necessary to upgrade these packages to get netdde running? <civodul>you might want to clarify that (normally we provide releases, not snapshots) <excalamus>looks like there are backups in /home/me/.mozilla/icecat/gkztg5gt.default/bookmarkbackups/ <excalamus>except it looks like a binary...and icecat doesn't seem to recognize it... <wleslie>it may be an sqlite3 database. you could open it and query it with the command line tool; but you might be able to get away with copying it to your new profile <wleslie>where by profile I mean whatever the newest mozilla profile is, in .mozilla/icecat/ <excalamus>well, it doesn't want to decompress. I'll try looking at the profile later. Gotta work now... <roptat>excalamus, "not rendering things correctly", do you mean fonts? I think "fc-cache -fv" fixed it for me <vivien>My icecat sometimes does not refresh half of the screen <vivien>I think that’s a problem with my graphics card though. <nckx_>excalamus: There's a Python script floating around the Web (GitHub IIRC?) that can (de)compress Mozilla's proprietary lz4json. <roptat>vivien, doesn't sound like something fc-cache can fix ^^' <apteryx>civodul: yes, packages can be adjusted to use glib-or-gtk-build-system if applicable, or the phase can be imported <apteryx>are profiles search path computed before or after profile hooks have run? <apteryx>I was expecteding the later, but GDK_PIXBUF_MODULE_FILE is not set although a file matching the search path is generated by a hook <apteryx>hmm, the profile-search-paths field is populated by accumulating the search paths of each profile entries; i.e. it doesn't care about what hooks may generate <zamfofex>civodul: I think it was necessary, at least mostly. But I will note that I didn’t update any packages that weren’t already in a non‐release commit. <civodul>apteryx: is the gdk-pixbuf what's preventing the branch with the long name to be merge in core-updates-frozen? <civodul>if so, i would rather delay it until some later point <apteryx>there's this; and I need to test a new commit of mrustc that's supposed to unlock rust on i686-linux <civodul>i mean, the branch got "frozen" beyond our expectations :-) <civodul>we could apply the bits that stable and known-good, such as the glibc timezone fix <civodul>then we can look at each those issues separately, and perhaps have them topical branches rather than core-updates <apteryx>I understand it's long, but it's nearly there and it has (surprisingly) more substitutes available than core-updates-frozen <civodul>yeah but core-updates has been "nearly there" for a year maybe <civodul>if the Rust change is done, let's take it <civodul>likewise, the gdk-pixbuf change could be a nice improvement, but if more work is needed, let's keep it for later <civodul>we don't have to put this much pressure on ourselves <rekado_>I’m confused about core-updates-frozen and the derivative branches. It also doesn’t seem quite as frozen as I thought. <rekado_>having to rebuild so much on the laptop is a serious obstacle to fixing bugs on that branch <apteryx>rekado_: the branch should have lots of substitutes at this point (more than core-updates-frozen according to ci) <civodul>yeah, though it's partly due because some non-world-rebuild changes on master become nearly world-rebuild on core-updates-frozen when they're merged <rekado_>apteryx: “the branch” being “core-updates-frozen-batched-changes”? <rekado_>will these two branches be merged into one again? <apteryx>the plan was to merge in into core-updates-frozen <apteryx>the newer polkit there is problematic though as it polls mozjs@78 which pulls rust <apteryx>there's a polkit-duktape as a potential non mozjs (and rust) replacement. I think it's used by alpine linux for example (and I packaged it already). <apteryx>otherwise we have to help the mrustc author to fix the rust bootstrap on non-x86, or rely on outdated packages *apteryx checks if polkit can be downgraded to mozjs-60 (doubt so) <apteryx>nope: configure: error: Package requirements (mozjs-78) were not met <minikN>Hello. I followed the contributing section in the manual to set up guix for development. This works for packages. However I'm unsure how I'd write a service definition, more precisely, how would I test the service? <roptat>minikN, you can create a system definition and a VM with ./pre-inst-env guix system vm service-test.scm or similar <roptat>to contribute your service, you'll also need to include a system test in gnu/tests <vivien>I’m a bit lost at why core-updates-frozen-batched-changes exists, but I’m worried that it took civodul a day to review a 2-line patch on core-updates-frozen, just because of world rebuilding. <apteryx>It'll work more thoroughly if we get around #22138 ( Search paths of dependencies are not honored). <apteryx>vivien: I was planning to merge it on november 1st, but postponed until I could get kexec-tools to build on i686 and the gdk-pixbuf hook error thiago had spot (both addressed now -- need to refresh the branch though). <apteryx>I guess I could merge it today, and we get to decide what we do with polkit (polkit + fixing rust on non-x86 vs go with polkit-duktape for now) <rekado_>how can I be sure that I don’t cause mass rebuilds when updating Rust packages? <rekado_>I touched rust-heck-0.3 and I can’t see if this is a problem. <apteryx>'./pre-inst-env guix build rust' perhaps <apteryx>I'm asking because the recent webkit patch disables DetectSSE2 on any non-x86_64 system; <apteryx>seems intel x86_64 specific from what I can see <apteryx>rekado_: although I don't see why rust-heck would cause the rust bootstrap to rebuild? <apteryx>the rust bootstrap depends on lower level blocks such as gcc, llvm, gdb <apteryx>does the CI halts when berlin is running the garbage collector? <rekado_>apteryx: I’m not concerned about the rust bootstrap (I don’t think I affected it). <rekado_>but I worry about mass rebuild of all those Rust packages on top of that, e.g. librsvg. <rekado_>since Rust packages don’t use inputs and native-inputs, “guix refresh -l” is useless <apteryx>currently you won't be able to know much due to the odd specifics of the rust-build-system, but efraim seems to be working toward normalizing it <roptat>oh we never updated libosinfo database, they still have only guix 1.1... <KarlJoad>Because I seem to be missing something, show can I start a shepherd daemon for my user? I know it is possible, I read the manual and it said that was supported. But I don't see how. <roptat>I'll send them a patch. iirc there's a document that explains steps for release, maybe we could add a bit of documentation on osinfo-db there too? <roptat>guix home should also be able to do that, or at least it's planned <KarlJoad>roptat: I was trying through Guix home, and no user-level shepherd was started. So I was unsure. <roptat>yeah, it's still the beginning, so maybe it's not implemented yet <drakonis>so there's some missing things right now <civodul>apteryx: perhaps eventually we can switch to using #:references-graphs to grab all the loaders.cache available in the closure, but let's keep that for later <civodul>(perhaps we could open a bug to keep track of it) <civodul>apteryx: so what's keeping us from merging core-updates-frozen-batched-changes? <civodul>are there things we can take out to avoid further delay? <civodul>we need to merge core-updates-frozen in master first <apteryx>civodul: I'm currently validating that rust-1.39 build on i686 with the latest mrustc commit <apteryx>I think it will, it used to fail very early <apteryx>so we'll have at least rust on i686 & x86_64 <apteryx>I haven't checked yet on arm, but I'm hopeful it may build there as well <apteryx>powerpc64le has know issues (and a PR to mrustc) <civodul>right now on master we have Rust on x86_64 only, right? <civodul>but it's required for almost everything on core-updates-frozen <apteryx>not sure on core-updates-frozen, but it is on core-updates-frozen-batched-changes due to polkit 0.120 <civodul>oh that's even worse than on core-updates-frozen then <civodul>but see, that's not really "frozen" if we do this kind of update :-) <apteryx>stuff were broken, needed updated to fix <civodul>i don't want to blame the person who actually fixes stuff <civodul>more trying to see where we are, if we went overboard, and what we can do <apteryx>yeah; in my opinion core-updates-frozen may have gotten frozen a bit too early <civodul>but OTOH we've had reports that things like GNOME 40 work there <apteryx>I think most of the fallout came from ungrafting webkitgtk/libsoup3; but that's a good resolved thing moving forward (else we'll spend the next months painfully trying to retrofit CVE patches on top of it). <rekado_>apteryx: sorry for being dense, but I need to ask for clarification. I’d like to fix some more broken packages today. Should I do that on c-u-f or on c-u-f-b-c? <rekado_>(I want to be sure that pigx builds fine.) <apteryx>I'd recommend doing so on c-u-f since c-u-f-b-c is going to be rewritten or deleted today <civodul>for commit 745d3a9b44f93af6fa84468b4b846d1104a73007 of c-u-f, "guix weather" reports 34% of substitutes on x86_64 <civodul>i think it went down with the recent master merge, and then didn't catch up <apteryx>the i686 build of rust-1.39 rearly completed but eventually died on: cc1: out of memory allocating 438707880 bytes after a total of 95367168 bytes <apteryx>C Compiler failed to execute - error code 256 <apteryx>anyway, going to revert this tentative rustc bump to avoid rebuilding rust for no gain and merge <rekado_>on ci.guix.gnu.org we again have the big garbage collector lock in our way since a few hours. <apteryx>yep; does it halts cuirass from doing its thing? I guess so. <apteryx>at least from collecting and properly reporting the results, I'd think. <apteryx>I'll probably introduce a bunch of regressions with the merge, but they'll be mostly pegging GNOME packages to meson-0.59 or libsoup-minimal-2 instead of the now default libsoup@3 <podiki[m]>thanks for all your hard work on this apteryx, really appreciated! *apteryx pushes to core-updates-frozen <drakonis>there is no guix without its community aye? <civodul>rekado_: i've killed "guix gc" on ci.guix... <apteryx>I'll open discussion about polkit vs polkit-duktape on guix-devel after lunch <civodul>IWBN if Cuirass could provide a per-jobset view of storage consumption <civodul>apteryx: alrighty, enjoy your lunch! ***attila_lendvai_ is now known as attila_lendvai
<rekado_>on core-updates-frozen: gnu/packages/crates-io.scm:14375:15: warning: possibly unbound variable `rust-1.52' <rekado_>I suppose these should all be replaced with just “rust”? <rekado_>(or maybe #:rust can be removed; i’ll try that.) <apteryx>the last rust is the one that should be used yes <vivien>civodul, you mean, run your script and share the results? <roptat>(I have the other files in the same directory) <drakonis>civodul: how did the package manager convergence panel go? <apteryx>civodul: how long does the script take to runÉ <apteryx>I guess it depends on the speed of the disk and how many links I have ;-) <civodul>roptat: rather the distribution by file size for files actually deleted <roptat>civodul, how do you compute that? <civodul>the one that produces "/tmp/size-deduplicated.png" <civodul>it's very similar to what i have, which is reassuring :-) <roptat>I think I never ran guix gc on that computer <civodul>how many .links entries do you have? <podiki[m]>I'll run it later too! also haven't gc'ed in forever... <civodul>yes, but don't run 'ls' in there :-) <PurpleSym>(I’m on a super-fast NVMe storage though, so GC’ing takes almost no time.) <podiki[m]>I always have so many (ran into the ext4 limit which caused a debacle when I changed ext4 options grub didn't like) <minikN>roptat: Regarding testing the service, I create a file with the definition, but what should the file return? It complains that it doesn't return an os or an image <roptat>minikN, it should return an os definition to create a VM for that system <roptat>something like bare-bones, but with your service added <civodul>PurpleSym: oh you have 50% of deduplicated files < 1K (vs. 30% for roptat & myself) <roptat>(that's for manual testing, otherwise you should use a marionnette for gnu/tests) <PurpleSym>civodul: I built lots of Python packages recently. Maybe that’s where that number comes from. <podiki[m]>for what it's worth, running `ls -1A /gnu/store/.links | wc -l` gives me 26646401 <podiki[m]>civodul: I don't know why I always have so much; though I know after gc that will go down a lot, been doing a lot of packaging stuff <civodul>roptat, PurpleSym: thanks; it seems to confirm that we won't lose much by not deduplicating files <1KiB <civodul>podiki[m]: yeah that's roughly proportional to your store <podiki[m]>around 10 million is the ext4 limit? I forget, but I'd be just under that with fewer generations and gc, but always in that range at least <roptat>civodul, how about a system like berlin? <apteryx>rekado_: fixed the ,rust-1.52 arguments with ab0cf06244 on core-updates-frozen, thanks for the heads up <excalamus>roptat, what I was calling "rendering" were elements blocked by the libreJS extension. <excalamus>nckx_, thanks, found it and was able to restore everything <apteryx>perhaps we can backport any improvements they've made there, if there are any <roptat>minikN, mh, you're not on a graphical system? <roptat>maybe you need xorg for that? sounds weird though <mfg>minikN: what exactly did you try? i'm also on sway and could try it too <minikN>mfg: I wrote a service and now I want to test it. <mfg>hm, what options does the run script use to start the vm? you could use -monitor stdio and -display none? <roptat>finally fixed my i18n analysis... it was broken since January... <podiki[m]>running the deduplication chart, is there a preferred way to share images here? <mfg>minikN: or if you really need graphical output maybe one of the other display types is better? <mfg>(sdl, curses or vnc) <roptat>podiki[m], just send a link that doesn't require javascript and works with tor <minikN>mfg: No I don't. The params you mentioned apeared to have done it. It's idling now. I reckon I have to ssh into it. <roptat>minikN, I think you can log in as root directly <minikN>roptat: I've never worked with qemu before. How do I do that? <apteryx>nix has dedup but it's disabled by default <roptat>podiki[m], no, I used my own server for that... maybe a lutim instance will work? that require javascript, but it's free software <podiki[m]>happy for a nice self-hosted option actually, I could add that to my server <apteryx>civodul: nix has the same performance problem to this day, according to some respondant <mfg>minikN: i meant -serial stdio and not monitor, sry. that way your terminal should be like a serial connection to the vm, so no ssh needed. <podiki[m]>(I could put an image directly there, but I don't think i have nginx set up that way) <mfg>i always swap the monitor and serial options ... :( <podiki[m]>roptat: thanks, and will see about maybe a self-host for future use <roptat>or put the image at the location defined by the root in your nginx server block, if you have nginx <roptat>I just copied the file to /srv/http/default ;) <singpolyma>podiki[m]: 0x0.st or tildeverse has an instance also, no JS required :) <minikN>mfg: With that option it prints `qemu-system-x86_64: warning: hub 0 with no nics' and then hangs, I see no prompt. I can C-c out of it. <mfg>minikN: Hm, FeelsBadMan. What operating-system config do you use for that vm? <mfg>Ah, i see so at least ssh should work then, i will see how the serial stdio thing can work <Guest7990>Hi, how's mlocate supposed to work in guix? It tries by default to use its gnu/store dir as a root for its db file, but that obviously is wrong. <mfg>minikN: good question! i don't know :( <Guest7990>E.g. is the intended use case to set LOCATE_PATH per-user .profile? Or to configure a globally used envvar (how would I do that from the operating-system definition?)? <minikN>mfg: But I think that wouldn't have worked anyway. My service install a package and creates a config file, but the package is only available in my local guix clone, I created that one too before. However the guix system vm command roptat posted went through fine. <mitchell>Hello guix! I am trying to package yices2 (https://yices.csl.sri.com). There is currently a descrepancy between what the configure script thinks the system looks like (make.include.x86_64-unknown-linux-gnu) and what the make file thinks it looks like (make.include.x86_64-pc-linux-gnu). This only happens when I build with the build daemon. If i build in a --pure -C environment it works correctly <apteryx>mitchell: orthogonal to your qusetion, but --pure is not needed with -C <Guest7990>(actually even with those envvars and commandline args, mlocate just dies on a nonexistent db file in gnu/store, which feels like a bug...) <mfg>minikN: another interesting thing: the vm starts just fine for me even with the gtk display <mitchell>This is the package definition: (define-public yices2 <mfg>do you happen to have xwayland disabled in your sway config? <apteryx>mitchell: I'm guessing it has to do with the way the system is detected by Guix (%current-system) and passed to the build derivation (as the #:system argument) ? <mitchell> (commit (string-append "Yices-" version)))) <mitchell> (file-name (git-file-name name version)) <mitchell> (base32 "1ld4r23ld9p5ip1h88m88ccvscbxk834dp41wsxdjad4l3rn3p59")))) <apteryx>mitchell: please use paste.debian.net for source code <mitchell> (list (string-append "DESTDIR=" %output)))) <mitchell> (description "Yices 2 is an SMT solver that decides the <mitchell>satisfiability of formulas containing uninterpreted function symbols <mitchell>with equality, real and integer arithmetic, bitvectors, scalar types, <mitchell>and tuples. Yices 2 supports both linear and nonlinear arithmetic.") <mfg>minikN: kk, weird. I guess -serial stdio doesn't work, because it seems the generated vm actually doesn't send anything over a serial line :D <minikN>mfg: Well i can't be the first one to do this. I wrote a package definition and an accompanying service and need to test them. <mfg>that's right, i guess it's weird that you get this gtk initialization error, have you tried -display sdl? <mfg>without any -serial or -monitor parameters? <mfg>maybe it at least gives a different error message <minikN>Could not initialize SDL(x11 not available) - exiting <mfg>are you really sure you don't have "xwayland disable" in your sway config? <mfg>that's the only thing that comes to my mind <minikN>004 git/origin-guix ➜ cat ~/.config/sway/config| grep wayland yields nothing <minikN>btw, I guess I should be ashamed of the cat/grep combo, just noticed that <minikN>mfg: The weird thing is, Steam for example works. <apteryx>mitchell: note also that there is a test suite included <apteryx>mitchell: this gets passed as a configure flag by guix: "--build=x86_64-unknown-linux-gnu" <mfg>minikN: tru. I don't know what to do about the X11 errors, but maybe i can get the serial thing working... <apteryx>but their makefile seems to expect x86_64-pc-linux-gnu <apteryx>mitchell: it's written in the build output as part of the configure phase <apteryx>perhaps you could edit their expectation (makefile) to match what guix uses <mitchell>apteryx: so what would be the proper way of doing that? <florhizome[m]>So when defining the outputs of a package I basically just say where single outputs can be found and that’s it ? :O <robin>there's no such thing as a useless as a use of cat. cats get depressed if you don't play with them. in fact, there should be a mandatory home service for running oneko ;) <mitchell>apteryx: I am attempting to pass (list (string-append "ARCH=" %current-system)) as a #:make-flags but it complains about %current-system not being bound. Do you know where I should look to find what the proper variable should be? <roptat>you can always insert a | cat | in the middle of a pipeline :) <apteryx>mitchell: I'd suggest build -K, cd /tmp/guix-build-yices2/... source environment-variables, and experiment <roptat>mitchell, maybe ,%current-system <roptat>since it's defined in the context of the package definition, but not on the build side (the quoted part is only evaluated during a build, where it has access to fewer modules) <apteryx>mitchell: the Makefile $(ARCH) variables appear to be wrong <apteryx>it comes from their bundled config.guess, which is not the same one our autoconf package must use ARCH=$(shell ./config.sub `./config.guess`) <apteryx>perhaps that's where the discrepancy comes from <mitchell>its weird that it only happens with the builder <mfg>minikN: so i have a hacky way for you to try :D i don't know where the run-vm script itself gets genrated yet, but copying that script somewhere where you can write and changing it's permission sto be writable, you can add "console=ttyS0" to the kernel command line (doesn't matter where exactly, i think) then you get serial output on your terminal if you run the script with -serial stdio <mitchell>when i do guix environment -C yices2 and run autoconf && ./configure && make it works <apteryx>because you don't explicitly provide --build option of configure <mfg>but the real question is: is the base agetty service not working or is the missing kernel command lin eoption the problem? <mfg>i guess one could also add those options inside the operating-system config <minikN>mfg: I'm sure I did something wrong. I'd be happy to try a known to be working os definition <mfg>actually i just opened the operating-system reference manual and it says to the option kernel-arguments: <mfg>List of strings or gexps representing additional arguments to pass on the command-line of the kernel—e.g., ("console=ttyS0"). <mfg>i wonder why this isn't part of %default-kernel-arguments ... <mfg>minikN: so yes you just need to add (kernel-arguments (cons "console=ttyS0" %default-kernel-arguments)) to your operating-system config... <minikN>mfg: it worked. I see a login prompt. <mfg>then run-vm.sh -serial mon:stdio -nographic works and gives output in the tty <apteryx>you'll have more to do though; (patching /bin/sh is next) <apteryx>please report the issue upstream, it sucks! <mfg>minikN: you're welcome :) <Guest79>What's `system*` in guix guile? (besides unsearchable -_-) <apteryx>how can I test the effect of missing locale? Is entering a container enough? (guix shell -C) <mfg>So if i understand the documentation of agetty-configuration correctly, it either chooses the right serial prt on its own, extracts it from agetty.tty kernel argument or console kernel argument. agetty.tty and console are not set by default and agetty doesn't use the correct one. How is this supposed to work? To me it seems it's mandatory to set console or agetty.tty in order to get "auto-detection" <lilyp>Guest79: system* is a nasty way of writing invok <Guest79>Ah, that's more searchable, thanks. Putting aside my complete unfamiliarity with guile for a second: how'd you make that 'v' look greyed out? *mekeor[m] doesn't see any greyed-out 'v' <mfg>emacs says: erc-nick-popup is responsible for the different color :D <lilyp>My third line has everything separated by spaces, perhaps it's in your client <Guest79>Guess it's an idiosyncrasy of the web client, then. <lilyp>There's a person called V, apparently <Guest79>(I think my web client ate the message so if this is a repeat, sorry!) <Guest79>Does anyone here use mlocate? I'm surprised that it's broken out of the box and am unsure if I somehow screwed up or if mlocate has flown under the radar <rekado_>fpc fails to build on c-u-f. Segfaults. ***guixy1 is now known as guixy
<rekado_>this blocks diffoscope (and hedgewars?) <dthompson>is there any documentation on the texlive situation in guix these days? I'm years out of date. "back in my day" we just had the texlive package and we just dealt with it. <civodul>dthompson: unfortunately not yet, but it'd be great to have! <sneek>Welcome back civodul, you have 1 message! <civodul>dthompson: so far i haven't managed to move to the "modular" texlive for my main use cases (Beamer, Texinfo) <dthompson>civodul: okay so we still just install texlive? I got concerned because it was downloading .tar.xz file and building from source. <minikN>After building my package, this is what got installed to the store: https://paste.debian.net/1219185/ I can run it fine. But I'm confused as to how I'm suppose to access default.xml. It's a default config to use with the app. I think it's meant to be available in /usr/share/phonesim <civodul>podiki[m]: thanks! so 85% of your deduplicated files are < 1KiB? that's wholly different from what the rest of us have, fun! <drakonis>civodul: say, is there any takeaway from your packagingcon talk that applies to guix itself? <civodul>dthompson: it's worth trying to install just the minimal set of texlive-* packages that you need <civodul>but it's quite a bit of trail and error <vivien>dthompson, from what I understood, you use a texlive-updmap.cfg (or texlive-union on master) containing all the texlive packages you want, and if one is not packaged, you create a package by using simple-texlive-package. <civodul>drakonis: for Guix itself the takeaway is that good importers/refreshers are vital <civodul>i still have in mind the idea of "live" importers <drakonis>live importers? how would you describe that? <civodul>drakonis: you run "guix install pypi:foobar" and it does exactly that <civodul>but for that we need perfect metadata from those repos, and perfect importers <civodul>we're not there yet, but maybe that could work with CRAN <civodul>Guest81: weird, looks like Cuirass is just confused <rekado_>you don’t use texlive-updmap.cfg or texlive-union in your profile <rekado_>just install texlive-base and whatever else you need <rekado_>civodul: can I help to get you to use the modular texlive? <minikN>roptat: Is it documented somewhere how to create tests with marionettes..? <rekado_>I haven’t used the monolithic package in maybe 2 or 3 years. <podiki[m]>civodul: that was just after running a gc but not deleting my many old generations; I do have that huge /gnu/store/.links for whatever reason <rekado_>vivien: what you describe is true for package inputs <vivien>To be honest, that’s what I put in my guix home configuration too <rekado_>civodul: a live importer for R exists. <rekado_>vivien: that’s not a good idea. The profile hook does all that. <civodul>rekado_: yeah, right! which is proof that we could prolly offer that <civodul>rekado_: re texlive, i miss for example a package providing the Fira fonts, and maybe there was something else <civodul>(i'm actually using time-machine to an old monolithic texlive but the current one doesn't have it either, d'oh!) <Guest81>civodul does this run forever or will it cut off at some point? <jackhill>rekado_: is the use of texlive-base documented anywhere? For some reason I always forget which one it is that I'm supposed to install to get the executables. <civodul>rekado_: oh yes, and "beamerbasetranslator.sty: File `translator.sty' not found." <minikN>It's not documented on how to submit services at. <civodul>Guest81: i think its status will get updated eventually; not sure! <dthompson>I installed texlive-tools but it seems I need more to be able to actually process tex files <dthompson>trying to find the minimal things to get a "hello world" style document to process <dthompson>texlive-latex-base... looks like something I should use <civodul>drakonis: we wanted to have something that could work without JS <civodul>mlemes & cbaines actually worked on something based on the Data Service a while back <civodul>cbaines: could we revive this package browsing interface? <apteryx>civodul: berlin has 64,061,083 links! <civodul>apteryx: ah nice! :-) i didn't dare testing there <civodul>OTOH, i have 2M links on my little HDD, it's not that big of a difference <rekado_>for the record: texlive-base *contains* texlive-latex-base. “texlive-base” is the package that contains “little more than the required set of LaTeX packages”, as the description says. <rekado_>civodul: for the fonts you probably need the “fira” package, which is listed in texlive.tlpdb. We don’t have a package for this yet. <rekado_>the translator.sty that beamerbasetranslator.sty complains about should be provided by the “translator” package — for which we also don’t have a Guix package. <jackhill>rekado_: cool, I think I might remember this time! <Gooberpatrol66>the manual says it generates a private key automatically, but i don't see a corresponding public key 
