<joshuaBPMan>I'm thinking about purchasing a Lenovo T500. They are super cheap on ebay! <mcmx>I don't think you can, but yea, I got this thing for under 100 bucks <mcmx>kmicu: it's from 2008, like I said <mcmx>one thing though, is the builtin wifi card requires proprietary software I think, had to use my usb wifi dongle when I was trying to install Guix System ***amfl_ is now known as amfl
<Minall>quiliro: Lo siento que me desconecté de esa manera... <Minall>quiliro: Cerré emacs por accidente <jgibbons[m]>I'm working on packaging CV Assistant. Is there a quick way to customize the install directory with qmake? <jgibbons[m]>It looks like the .pro configures qmake, and it has a hard-coded install directory. <jgibbons[m]>the Makefile has an INSTALL_ROOT variable, but I don't like it including the usr directory. Not good for guix. <csprng>jgibbons: does something like this work? (invoke "qmake" (string-append "PREFIX=" (assoc-ref outputs "out"))) <csprng>alternatively: (substitute* "Makefile" (("/usr/local") (assoc-ref outputs "out"))) <efraim>I suggest PREFIX= it's what we end up using on most qt packages <ngz>Is there a reference somewhere about the filters one can use to search through ci.guix.gnu.org? <rekado>ngz: there isn’t, but I can tell you. <rekado>ngz: ‘system:’ and ‘spec:’ work, and you can use ‘^’ and ‘$’ for matching the beginning and end of a string in the text query. <rekado>this is implemented in the query->bind-arguments procedure in src/cuirass/database.scm <ngz>rekado: ok, thank you. Would it be useful to add some hints about it in the first page, much like what you did in issues.guix.info? <kmicu>mcmx: I didn’t have your previous messages in backlog. In that case you can install manually and it will work for sure. <efraim>the crate importer is working less than normal today :/ <ngz>efraim: It noticed yesterday that it couldn't import some packages from crates.io, too. Not sure it is related. <ngz>E.g., impossible to import "humantime" or "rayon". <ngz>I admit I don't know how to debug efficiently Guile (and therefore Guix) code. I'm spoiled with Elisp, which is very straightforward to debug. <pen14641>Hi, I am trying to run a disk image built with 'guix system disk-image' using virt-manager. I get the error message "Unable to read from '/sys/fs/cgroup/unified/machine/cgroup.controllers': No such file or directory". There is no directory /sys/fs/cgroup/unified/machine, but there is a file /sys/fs/cgroup/unified/cgroup.controllers. I don't know if virt-manager is trying to access the file at the wrong <pen14641>Or well, the error message is "Unable to complete install: " and then that error message <jgibbons[m]>csprng: changing the prefix did not work. I got it working by changing CVAssistant.pro. Only problem now is the icon won't show in gnome, otherwise it's good. <efraim>jgibbons[m]: depending on which qt modules you used you'll need to wrap the binary to see the icons *ecbrown contemplates whether the next task is to go "--with-courage" (hurd) or to try to roll a system where gz, etc. is replaced with pigz, etc. <jgibbons[m]>efraim: it uses qt5. It's only the desktop icon that isn't showing up, so I think it's a problem with the .desktop file. <rekado>ngz: I would be happy if the filter/search options would be mentioned somewhere sensible in the UI of ci.guix.gnu.org. <rekado>ngz: I had to think for too long about where to put the information, so I punted on it. <ecbrown>jgibbons[m]: i'm going to try to build one <rekado>jgibbons[m]: I also found a couple of problems with Guix on the Hurd. <rekado>our statically linked binaries segfault *ecbrown listens intently <rekado>‘tar’, for example, just crashes, which makes using Guix on Hurd impossible right now. <rekado>it’s possible that this is just a problem with my bootstrap binaries, of course, but nothing has changed in that regard recently <rekado>so I suspect the issue still exists <ngz>rekado: As in issues.guix.info (i.e., right below the search bar, which is centered full-width) is not an acceptable location? <rekado>jgibbons[m], ecbrown, if you want to play with this I recommend getting a Debian GNU/Hurd VM image and building Guix on it. <ecbrown>my plan was to try to build it with debian hurd 2017, with the commit right before guile 2.2 <rekado>remember to resize the VM image before doing any serious work. <ecbrown>naively, i tried with debian hurd 2019, and am having a hell of a time with guile-gnutls <ngz>Or, a [?] right to the search bar, which opens a pop-up with the information (less invasive) <rekado>resizing the file system cannot easily be done later, so better do this before you start. <vagrantc>ecbrown: yeah, guile-gnutls doesn't exist in recent versions of debian <rekado>ngz: on issues.guix.gnu.org we have that really big input field, so there’s space. <rekado>ngz: but on ci.guix.gnu.org we don’t have that. <rekado>so I think a little help link in or next to the search bar would be a good place <ngz>Sure, but the first solution implied to move the search bar <ngz>Though I agree the second solution, or related, would be better <ngz>(moving right above the tabulated output) <rekado>I’d have to see what it looks like <rekado>my fear is that moving the search input out of the top bar would make it seem more cluttered. <ngz>Ultimately, it would be nice to have both issues.guix.info and ci.guix.gnu.org use the same interface <rekado>we’re still far from Github style clutter (with these many bars at different levels) <rekado>ngz: I already tried to make them more similar. <ngz>of course. I'm juste talking about the search help <Minall>quiliro: Kiel vi fartas... Lo siento que estoy tarde, tuve que salir.. <rekado>but that was just really a bunch of superficial changes <rekado>I’d be happy to see some convergence between the two. <rekado>ngz: if you want to work on Cuirass: more power to you! :) Please keep me on Cc for Cuirass patches, and I’ll try to review them. <ngz>Therefore, my vote, for what it is worth, would be to have both use [?] to the right. <rekado>for issues.* I think it still makes sense to have a big search input on the main page, though, because there isn’t really anything else to do there but to search for issues. <ngz>rekado: I'm not sure I would be able to do that =/ I'm just suggesting stuff for the time being. <rekado>ngz: suggestions like yours are half the work, really. Often times I don’t really know what to focus on, so hearing a good plan is often enough to solve a real problem quickly. *rekado is currently stuck on texlive-union again <rekado>I solved one problem (regenerating font maps), but just the existence of the correct font maps breaks a completely unrelated feature (searching for *.cls files). <rekado>I’ve been thinking about this for a few days now, but no idea has struck me yet. <Minall>quiliro: Debo de salir de nuevo, disculpe, no pense que tendría que salir hoy.. <xavierm02>Where can I find the thing that iters over phases of a build system to run them? <ngz>xavierm02: See gnu-build in gnu-build-system.scm for example. <ngz>I think most build systems ultimately call gnu-build with a possibly augmented #:phases argument. <xavierm02>gnz: I couldn't find where phases are iterated over in the gnu-build file. Also, it seems to call build-expression->derivation but when I look up the definition of build-expression->derivation, there's a comment saying it's depreciated. <ngz>xavierm02: At the very end of "gnu-build-system.scm", you have (define* (gnu-build #:key ...)) <ngz>In this gnu-build function, you can see (every (match-lambda ((name . proc) ...)) phases) <ngz>This every is iterating over the argument `phases' <ngz>I'm not sure the `every' is necessary, btw, since every call to (apply proc args) is expected to either return #t or raise an exception. <xavierm02>Oh. I was in build-system/gnu.scm. Thanks again :-) <ngz>Backward-compatibility stuff, probably. Maybe it would be better to add a `raise' inside the `unless' and use `for-each' instead. <mcmx>are you guys planning on making python -> python3 any time soon? <ngz>BTW, is there some documentation somewhere about how to debug Guix internals, ideally through Emacs? <mcmx>kmicu: I don't have enough skillz to make an encrypted MBR partition table <rekado>mcmx: I don’t know what you mean. The ‘python’ package installs ‘python3’. <rekado>If you want the ‘python’ executable to be ‘python3’ you need to install the ‘python-wrapper’ package. <rekado>Upstream doesn’t install ’python3’ as ‘python’, so we don’t either. <quiliro>i get the following error every time I enter a new chatroom on Emacs ERC: <quiliro>(Searching for program No existe el fichero o el directorio ispell) <quiliro>Starting new Ispell process ispell with default dictionary... <quiliro>No existe el fichero o el directorio = The file or directory does not exist <rekado>you probably don’t have ‘ispell’ <nly>flyspell requires you to install one of several ispell programs(hunspell, ispell ..) <rekado>and then configure flyspell to use aspell <vagrantc>do builds under guix have a writeable /tmp dir? diffoscope 121 is failing to build as an updated test tries to write out a file in the tests directory <rekado>or you coudl disable flyspell on ERC. <rekado>vagrantc: is this from a git checkout? <rekado>by default files taken from a git checkout are not writable, so you need to use make-file-writable on the directory first. <vagrantc>could switch back to tarballs from pypi, but those aren;t consistantly released <vagrantc>i could make that specific file/directory writeable? <rekado>we use make-file-writable in a couple of packages. <vagrantc>that's much more elegant than the hacks i was thinking of :) <nly>i cannot ./bootstrap on guix checkout <nly>i mean ./bootstrap results in an error <nly>sorry, I'm in bed now. i'll ask again tomorrow <vagrantc>does it make sense to reference the upstream issue that required writeable access to a tests file in a comment? <vagrantc>trying to briefly summarize the issue that lead to diffoscope needing the writeable file <rekado>vagrantc: I think that’s really a Guix quirk, not an upstream problem. <rekado>it would be sufficient to state in a comment that the tests directory needs to be writeable. <vagrantc>ok ... so far just a single file needs to be writeable <vagrantc>if another file requires write access at some point, i can just make the whole directory writeable, i gues ***MinceR_ is now known as MinceR
<raghavgururajan>jgibbons[m] Just read your email. Thank you so much for your hard work. Have the package been added to master branch? <bluekeys>Hi guix. Sometimes mye headphone socket doesn't work. Where should I start looking to troubleshoot it? <rekado>bluekeys: check in alsamixer that it isn’t muted. <bluekeys>I don't seem to have alsamixer, do I have to have it? <nckx>bluekeys: Install the alsa-utils package. You only have to have it if you want to use it :) *vagrantc is eager to see qemu 4.x from core-updates