<mekeor>how do i add ./bootstraph.sh to the build-system of a package? <mekeor>specifically, to a package using the gnu-build-system. bootstrap.sh needs to be executed before ./configure <Apteryx_>Apparently I only had to quote it using (quote ...) :) ***Guest69838 is now known as sturm
<mekeor>modify-phases isn't documented at all in the manual. -.-" <mekeor>one of the most important practices of free software is writing good documentation <lfam>And one of the hardest, too... <lfam>It's not easy to hold on to the "beginner's mind" <mekeor>true. it's also hard to keep the docs in sync with the code <lfam>That's why we tend to require docs for new services <mekeor>the thing is that it's much harder for me to write documentation for modify-phases as my only source is the source code <quiliro>i still ave problems with system reconfigure <mekeor>also, i lack an understanding of scheme. also, there are many other functions like system* and zero? etc etc which are important for modify-phases. <lfam>system* and zero? are not specifically important for modify-phases (they are part of Guile, not Guix), but they do get used there often. <lfam>quiliro: I'm sorry, I don't know the answer to your bug yet <lfam>quiliro: I hope some other people are reading it, too <lfam>mekeor: And feel free to ask questions. I've found that there is usually someone around who with help answer Scheme questions, either here or in #guile <lfam>Or, "...who will help answer..." <quiliro>i think that my problem with claws-mail is utf8 <quiliro>a message that was sent has: Content-Type: text/plain; charset=US-ASCII <quiliro>a message that could not be sent has: Content-Type: text/plain; charset=UTF-8 <quiliro>lfam: do you think it might be my locales in config.scm? <mekeor>quiliro: did you try es_CL as locale? <mekeor>i will soon submit a patch to the mailing list. – until then, good night – zzzzzzzZZZZzzZZ <quiliro>but i have problems with my system reconfigure <paroneayea>taking a break from responsibilities and working on a Godot package <paroneayea>looks pretty feasible; main thing is it does bundle a lot of libs which isn't ideal. <paroneayea>though it does bundle them in source form at least, and has a nice README listing all the bundled libs of which version. Better than many packages! <catonano>paroneayea: it's 5 AM in Europe, I'm here just because I can't sleep ;-) <lfam>Can't sleep / Won't sleep <paroneayea>/gnu/store/iwgi9001dmmihrjg4rqhd6pa6788prjw-glibc-2.24/include/bits/local_lim.h:38:26: fatal error: linux/limits.h: No such file or directory <quiliro>i think my problem with reconfigure was network <quiliro>but i still have the claws-mail problem <quiliro>i will see if it is solved after reconfigure <lfam>paroneayea: I can't find a reference now, but I remember efraim mentioned hitting this issue in the aarch64 port. glibc depends on this kernel header apparently <paroneayea>lfam: yeah, but I add linux-libre-headers, and it still failboats :\\ <Apteryx_>Has anyone ever had different result using "C-c . b" in Emacs compared to "guix build" from the command line? <jamesrichardson>Hello, I've packaged perl-critic and the 15 or so dependent perl modules not yet in Guix. I still have some work to do writing synopsis and descriptions. Would it be best to submit a single patch? <lfam>jamesrichardson: We prefer one commit (or patch) per package. You can also do `git format-patch origin/master --stdout > /tmp/patch`, and that will make a single file that will create multiple commits when applied. <lfam>I find it quite tedious for both patches and actual bugs to have subjects starting with "bug#25900:" <lfam>The messages also come from an address like 25900@debbugs.gnu.org instead of guix-patches@gnu.org, so I can't categorize them separately from real bugs. <lfam>I'm going to unsubscribe from guix-patches for now <lfam>Or, they don't even appear to come from a list, but directly from the sender <rekado>sneek: later tell lfam I categorize emails to guix-patches by matching on the list header. But actually, I prefer to use M-x debbugs-gnu instead of subscribing to guix-patches. <rekado>quiliro: re your bug report 25894: I don’t know what’s going on one here, but it looks like either a network problem or a broken “substitute” binary <ng0>when I want the luksUUID, do I want /dev/sd* or /dev/mapper/name-of-sd* ? last time I tried this I didn't succeed in selecting the correct one <rekado>Guix calls the “substitute” tool and lets it handle binary substitutes. For some reason all it reads is an EOF <ng0>this explains me failing <rekado>ng0: when you do “sudo blkid” you should get a UUID <rekado>in my config I use the UUID of the plain device of type crypto_LUKS <rekado>I use that in the “mapped-devices” list for the “(source (uuid …))” field. <ng0>okay, thanks. I'll see if that helps me. <jmd>So where is the web interface to the patch tracker? <jmd>rekado: Thanks. (we could use a link from home page and/or the savanah page) <ng0>and change the link in the irc topic <shurdeek>Python's ctypes.find_library is having problems to locate libraries which are in .guix-profile. I'm new to guix. How do I work around or fix it? <shurdeek>well, export LD_LIBRARY_PATH=~/.guix-profile/lib helped but I have a hunch you're not supposed to do it like that in guix <rekado>shurdeek: I’m not familiar with Python, so I cannot really help here. <rekado>shurdeek: when building packages for Guix I think we usually replace find_library calls with the full path to the library. <rekado>can you use the full path to the library instead of just using the name? <shurdeek>rekado: the code is multiplatform, and it works also on other linux distros, Windows, BSD and OSX. Just on guix I have this problem. <ng0>shurdeek: I think it's easier to address the mailinglist, some people are familar with python but not all are always around here <ng0>especially harmut seems resourceful on the python and django topic <roelj>Is there a way to run a graphical program in a Guix container? <ng0>i think someone posted some months ago a basic approach to run icecat in a container <ng0>one moment I might be able to give you a subject of email <ng0>thread:0000000000021dc7 2016-07-04 [2/3] Thompson, David, Pjotr Prins; Container howto for X11? (guix unread) <ng0>that was environment <ng0>and it has access to X11 etc <ng0>see the last reply of Pjotr <roelj>No that's exactly what I wanted to do :) <roelj>It's still a bit of a hole, since when the application can access X11, it could be game-over pretty quickly. <roelj>But this is cool. Thanks for pointing out the thread to me <ng0>for a while I wanted to package xpra.. but maybe we can have a native solution one day. <ng0>this would essentially be a fallback solution for mirror:// if the url is projects and not project <roelj>I have an almost-working Darktable package. The validate-runpath phase fails, but the resulting binary runs just fine. How should I debug that? <rekado>roelj: what are the errors you get in that phase? ***topsy-N[m] is now known as topsy-N
<rekado>ACTION swims in half-ready java packages <shurdeek>you're complaining about me not listening to you <roelj>rekado: Can I get the build log of a failed build? ***topsy-N is now known as Wysteriary
<shurdeek>ng0: You'll be happy to know that I just released PyBitmessage 0.6.2, which includes setup.py for setuptools and has been tested on guix. <ng0>I wasn't complaining I was simply not talking to you. I will not talk about anything bitmessage anymore, my personal opinion and the last discussion on guix-devel was a mistake to reply to. in case you are Peter. ***Wysteriary is now known as topsy-N
<shurdeek>ng0: feel free to not talk to me all you want <roelj>rekado: ... libtethering.so: error: depends on 'libdarktable.so' which cannot be found in RUNPATH ... <rekado>ng0, shurdeek I don’t know what this is about, but please leave this off our channel and mailing list. <rekado>roelj: where is libdarktable.so? <roelj>rekado: It's a library compiled by that package, same as libtethering.so. <rekado>is libtethering.so built with a RUNPATH including the final location of libdarktable.so? <rekado>roelj: the actual location does matter <roelj>rekado: I don't know.. they are both built by the package <rekado>roelj: by default only the output’s “lib” dir is on the RUNPATH. If the libraries end up elsewhere that would have to be communicated to the linker. <ng0>woops. okay shurdeek I take it back. it's good to know it has been released (where? I have only seen 0.6.1 on github). feel free to bump the guix package definition if you'd like to do that, I'm busy <rekado>roelj: you could “guix build -K” and check :) <roelj>rekado: I did that :) But still unsure.. the RUNPATH seems to be "<output_dir>/lib64/darktable/views/../lib64/darktable", which does not make any sense.. <rekado>roelj: the first problem here is that lib64 is used. You may be able to correct this in the build system. <rekado>roelj: if you search the build output for libdarktable.so you can figure out its path and try to add that to the RUNPATH <rekado>e.g. in the same way that we do it in bamtools <rekado>(string-append "LDFLAGS=-Wl,-rpath=" %output "/lib/the/actual/path") <roelj>rekado: Right, I'll try that. Thanks :) <ng0>it was bug-guix not guix-bug@ right? <roelj>rekado: I wished "#:validate-runpath? #f" would be acceptable ;) <ng0>sneek: later tell shurdeek: I feel like there's a misunderstanding, and whatever happened last year can remain where it is, in the past. If you need help with updating PyBitmessage guix definition, get in touch <quiliro>rekado: i think it is a networking issue too because it is always a different phase of the process where the errors ocurr <thomasd>roelj: I missed your talk at FOSDEM. Will the video still become available? <roelj>thomasd: I hope so.. Recording the video went almost fine. It has a audio/video sync mismatch, which is holding things up. <rekado>roelj: it’s pretty easy to fix this on the web interface. <rekado>so I downloaded the video, figured out the delay with mpv and requested another draft to be rendered <rekado>within minutes the new draft was available and upon checking it I requested the high quality version be rendered and published. <thomasd>Some of those talks might be good for the GuixSD home-page. <thomasd>Also, will they permanently stay available from FOSDEM, or can/should we mirror the videos elsewhere? <roelj>rekado: Right. I've done about 10 requests for drafts and then I gave up. Maybe I should use an external tool to figure out the delay then. <efraim>I feel like I need to double-down on fixing aarch64 build failures before its well and truely frozen. cmake and libgd both need some loving so I can build to gtk+@2, and then I still need to test the path to gtk+ <efraim>yay intermittent failures, cmake built on the 3rd try <quiliro>how can i mirror a snapshot of all binaries? <quiliro>so i can take it to a place where there is no telecommunications <wingo>i believe "guix archive" is the thing <quiliro>wingo: will guix archive will "export files from the store into a single archive" <quiliro>wingo: what i need is to import all the repo from a mirror <wingo>what does "all the repo" mean? <wingo>even all the out of date ones that don't reference current builds? <catonano>jmd: I applied your unrar patch in a branch. It builds and it runs. If I had a rar file I could test i it really uncompresses rar files. <jmd>catonano: Yeah, does it have any meaningfull self tests, I wonder? <catonano>jmd: is your submission really 8 hours old ? I see it in Emacs but not among the emails <jmd>8 hours sounds about right. <jmd>I've got two rar files. One can be opened with unrar the other cannot. <jmd>Rar was always a bit dodgy and there are many variants, some of them patent encumbered. <jmd>The best we can do is package the software that upstream provides and let them know about problems. <catonano>jmd: ok. I just wanted to write "LGTM!" for the first time but it seems that the Emacs-Debbugs thing requires an smtp gateway and gmail is picky about my clients :-/ <thomasd>I'm wondering what is the proper way to reload a shepherd service (without rebooting)? <davexunit>but that didn't sound like the question that was asked <roelj>Would you like to restart shepherd itself? <thomasd>at least I think... I mean when I run `guix system reconfigure', and change a running service's configuration, it seems shepherd doesn't load the new config until I reboot <davexunit>there is ongoing work around that. it's a tricky bit of engineering. <thomasd>ah, ok. I thought maybe I was missing something. I also think it's not really explained in the documentation (but shepherd's docs are also WIP, it seems). <thomasd>davexunit: if it's not a shepherd thing, isn't there a workaround? <davexunit>thomasd: I don't think you are grasping the complexity of the problem. <thomasd>davexunit: that's why I'm asking. is there a mailing list conversation/bug report or something where I could read up? <davexunit>shepherd is running and has a service 'foo' running, then you run 'guix system reconfigure' and it generates a shepherd config with a modified 'foo' service. what happens? <efraim>I'm pretty sure building gtk2 and 3 covers most of the packages that would trigger a lot of rebuilds <davexunit>thomasd: you'll have to search the mailing list archives for that <efraim>Shepherd failed 3 tests, probably relating to the slow storage <thomasd>the service I was thinking about is a simple "leaf" service, so I feel it should be possible to somehow manually force shepherd to unload the currently running version, and load a new one (for testing purposes), I'll have to read those commits to get a feeling for how this works <thomasd>there is "herd unload shepherd <service-name>" which might accomplish the first part <thomasd>actually, I've just found this (clumsy) workaround for a "non-essential" leaf service: <thomasd>1) remove service from your configuration, and reconfigure (shepherd will stop and unload the service) <thomasd>2) add service with new configuration, and 'system reconfigure' again. shepherd will now load the new configuration for your service. <rekado>thomasd: you can also stop the service, reconfigure, start the service. <thomasd>rekado: sounds easier :) I knew I was missing something. <thomasd>davexunit, rekado: thanks. I think I understand it all a bit better now. ***bavier` is now known as bavier
<reggggieee>i'd ask on #emacs, but I don't have this nick registered: has anyone accidentally gotten their dired buffers 'editable'? (not wdired or C-x C-q). Sometimes all my dired buffers become editable, no matter if I kill them and open new ones. They don't have the potential to actually edit any of the listed items. but for example, I can kill everything in the buffer. The only fix I've found so far is restarting emacs, which is a pain <jmd>Installing Guix on mips I find there are very few substitutes available on Hydra. <bavier>jmd: yeah, the build machine has a hard time keeping up <mekeor>reggggieee: never happened to me. but i almost never use dired <reggggieee>mekeor: kk, i think it has to do with some mode that's showing up as 'WK' because it's affecting more than just dired buffers <mekeor>reggggieee: what is WK? try (`C-h m` to find out, maybe?) <reggggieee>mekeor: nm, it's nothing to do with my problem. WK is which-key <mekeor>i see. i use which-key, too. well. dunno. :/ <jmd>bavier: What kind of machine is it? <bavier>not certain though, mark_weaver should know more I think <Gottox>im currently working on integrating elogind with voidlinux (so no guix specific question) is this the right place to ask? <bavier>Gottox: wingo did the elogind work <wingo>there is a new elogind branch <wingo>and a new more active maintainer <wingo>i haven't tried the new maintainer's branch yet <wingo>Gottox: Sven Eden <sven.eden@gmx.de> <wingo>i am sure he would love a tester :) <jmd>I have never been exactly sure what elogin is. <Gottox>wingo: but maybe you can help me, what can be wrong if gdm just sits there and does nothing? <wingo>i don't think the x server directly depends on elogind <wingo>only when login happens does it ask PAM to authenticate the user <Gottox>hmm... okay. so it's not related to logind at all. <wingo>a pam_elogind.so failure will bork everything tho, so be careful there :) <Gottox>damn, I avoid freedesktop whenever possible. <nliadm>I don't see anything in the manual about how grafts work, just that they're a thing that exists. I'm not missing something, am I? Otherwise I'm off to do some list archive spelunking <mekeor>sneek: later tell lfam: could it be that you forgot to merge my patch for adding dzen? or did you not merge it by purpose? just wondering. <mekeor>the manual is quite incomplete. there's much missing. so, i can imagine that's missing, too. / <Gottox>wingo: finally, I got it. it was due pam and the lack of pam_systemd.so <mekeor>damn. i abused the { mailing list, bug tracker } by opening 3 bugs instead of a single one because the patch consists of 3 patches. forgive me, Guix. ***mildred1 is now known as mildred
<rd161616>Hi, I'm on my phone , did an USB key tryed to install without success, my had is already partitioned and labelled and my USB key boot is stuck at switched clock source to tsc any idea please ? <paroneayea>mekeor: things happen :) just close the other bugs! <bavier>rd161616: I don't understand your problem <rd161616>I tried to install guixsd from an USB key <rd161616>Reboot at the barebone confit step because ive selected the wrong one but my USB don't boot the installed any more: switched to clocksource tsc <rd161616>And my hd is already partitioned so all I have is the bootable USB guix and irc on my phone lol <bavier>rd161616: the guixsd usb doesn't boot anymore? <rd161616>It does but it stop and says switched clock source <rd161616>Entering a new prompt. Type by for backtrace or q to continue <bavier>I'm not familiar with tweaking kernel parameters from the installation media <rd161616>Roger, why does the install modified the key ? Is it because I've labelled my partitioned hd to my-root and rebooted to restart the whole process ? <bavier>I don't think the installation process modifies anything on the usb key <rd161616>Pretty sure didn't touch the USB key from the partition manager <bavier>hmm, sorry I can't be of more help <rd161616>Np I think it's because I did the gnu store instruction <bavier>rd161616: for future attempts you can keep in mind that rebooting shouldn't be necessary if you realize you made a mistake in your config.scm <bavier>'guix system reconfigure' is an atomic operation, so no harm in killing it <rd161616>I rebooted after herd start cow-store /mnt <methalo>rd161616: i see the same err, i think the usb is ok <bavier>methalo, rd161616: could you please send a report to bug-guix@gnu.org? <bavier>rd161616: you can mail help-guix@gnu.org if you think that's more appropriate :) <rd161616>The guixsd install has no problem i just failed the install <bavier>I would consider it a bug in that an honest mistake led to an unbootable system? <rd161616> I've rebooted on the key one step before the install what do u think <bavier>rd161616: oh, so you've been able to make progress again? <rd161616>No I talk about the first attempt I make another key <rd161616>To be clear followed the steps then make the herd command and noticed I forgot to make the mbr partition so I revooted <Gamayun>Ah, hm.. You should be able to repartition as well at that step, would just need to unmount anything you mounted. :) <bavier>rd161616: and then booting with the usb key failed, dropping you to the initrd recovery shell? <Gamayun>rd161616: Are you putting the image on the same key now, or a different USB key? <Gamayun>Ok.. Would be interesting to find out if something *has* happened with the key. Seems unusual though. <rd161616>If u really want I can flash the guixsd image and sent you the key lol <rd161616>But I had problems with that key in the past like if I mount it's on read only and the command don't unlock it, but flashing ISO to it never been a prob <rd161616>I think it's because my hd is labelled my-root no ? <bavier>rd161616: it shouldn't be touching your hd at that point <rd161616>I disabled my hd in the bios and the key boot ! <bavier>rd161616: was your bios actually booting from the key, or was it trying to boot from your hd <rd161616>Well I used boot overdrive to USB disk pmap so I think it's the key, I will try to boot without the key to see <rd161616>I'll try to make a key to partition and delete every partition and booting on guixsd USB key <quiliro>bash: ./kurso4: cannot execute binary file: Formato de ejecutable incorrecto <rekado>quiliro: what are you trying to do? <rekado>quiliro: if it is an executable from another system then it won’t run on GuixSD <rd161616>Yep for thoses who read my previous messages I can boot my new USB key again I had to delete all partition on my disk before <quiliro>rekado: yes, it is an executable. The source is available too. Is there an easy example of guixifying a source code? I want to learn and maybe I can do it with this package. Perhaps I should do it with someone's help. <rekado>quiliro: it’s easy if the software uses a common build system <rekado>e.g. the usual ./configure && make && make install <rekado>we can assist you in getting this packaged