IRC channel logs

2019-12-17.log

back to list of logs

<nckx>(Hello #guix 🙂 )
<leoprikler>Over the whole duration of install?
<nckx>It would be nice if that were queued as well, like we currently wait for build slots.
<vagrantc>could someone take a look at d08c3e51ab62575e722aec24fba42a0cb84198cc i just pushed to master ... i cut-and-paste the arguments section from the inherrited electrum package, but surely there is a better way to do it and i forgot to ask about that before pushing
<vagrantc>cut-and-paste and modified...
<nckx>leoprikler: I think so.
<leoprikler>okay, gimme two packages to test this with
<nckx>vagrantc: Would substitute-keyword-arguments've worked here.
<nckx>*?
<vagrantc>nckx: curious to find out ... :)
*vagrantc looks for uses of substitute-keyword-arguments to cargo-cult
<nckx>vagrantc: That was a (too) subtle ‘are you familiar with…’ 😉
<vagrantc>nckx: when it comes to guile scheming, it's a pretty safe bet to assume no with me :)
<nckx>I've pulled the changed but my guix is still broken, so I'm just limping along here.
<nckx>^^ leoprikler: that answers your request, too, I'm afraid.
<leoprikler>ehm, how exactly?
<nckx>‘Alas I cannot give you any, for my Guix is borked.’
<leoprikler>Fair enough, but actually, I was just asking for package names (exotic ones, with fairly moderate build times).
<brettgilio>jackhill: just got your email thank you a lot!
<leoprikler>Oh, but don't say renpy, I contributed that one 😉️
<nckx>vagrantc: Oh, it's an unmodified copy of the entire arguments field?
<vagrantc>nckx: well, i added an additional phase, but the rest is copy-pasted
<vagrantc>i think i found an example i can steal :)
<valignatev>Looks like cargo-build system can't figure out Cargo.toml dependency if it has { git = ... } format like glutin dependency in Alacritty: https://github.com/jwilm/alacritty/blob/master/alacritty/Cargo.toml#L21. So it seems that my best bet for now is doing a custom snippet that modifies Cargo.toml before configure stages kick in, right?
<valignatev>Hello everyone btw :)
<nckx>vagrantc: Yeah, I'd go with s-k-a here. Such a short C&P isn't the end of the world though.
<valignatev>nckx: s-k-a? Do you mean substitute-keyword-arguments or smth?
<vagrantc>at some point, these two packages may entirely diverge...
<nckx>leoprikler: I guess I'd just add some useless phase to webkitgtk, ‘./pre-inst-env guix install’ it, then install something tiny in parallel.
<nckx>valignatev: Yes. I am lazy boy.
<leoprikler>okay, I'll go for icecat then
<nckx>vagrantc: That's always the question, of course.
<valignatev>It's alright, I guess I'm not that of a noob anymore since I figured it out D:
<valignatev>nckx: Thanks for confirming it, will try it out.
<nckx>leoprikler: Interested in the results, especially if they contradict my experience.
<leoprikler>okay, throws an error
<nckx>valignatev: I'm confused. What did I confirm?
<valignatev>Ah, damn. I misread that you've mentioned vagrantc and not me
<valignatev>Sorry, lol, it's 2:20 am
<nckx>leoprikler: It was changed because it could lead to ‘missing’ packages if you didn't realise how ‘guix install’ works. Happened to a new user who then wrote a public review :-/ It's a good change, just needs to wait for the lock instead of erroring out.
<nckx>valignatev: No worries. Wish I knew more about Cargo than I do. I'd say: fix it in a snippet, submit a working package for review and anyone who knows a more elegant solution can still suggest it then.
<valignatev>that's basically my plan. Scrap together something working and then try to improve tooling using Alacritty as motivating example
<leoprikler>so instead of with-file-lock/no-wait we would use a version that waits?
<vagrantc>nckx: so i think i have it working... it's a +8 -13 line diff :)
<nckx>leoprikler: I haven't looked at the code (all my free/Guix time is just… gone ☹), but I don't see how that would break anything.
<nckx>I also think the lock should only cover the final profile update, so more packages can build in parallel, without breaking anything, but please actually formally verify that first.
<nckx>Mmm, that'd require too many changes, never mind.
<nckx>vagrantc: Those are the good ones.
<nckx>valignatev: It's also just more fun to refine a working thing. You can fix alacritty using alacritty!
<valignatev>nckx: Of course :) I'll be happy when I replace my alacritty from Arch repo to the Alacritty from guix
<nckx>brettgilio: Thanks for your interesting e-mail & proposal.
<nckx>(Formal Method WG.)
<jackhill>brettgilio: :) Thanks for starting the discussion.
<bandali>indeed, thank you brettgilio :)
<bandali>would be very happy to hear from (even more) folks on guix-devel about it
***Server sets mode: +cnt
<brettgilio>nckx: thank you for the support :)! For anybody who is supportive please say so! Would love to see the formal methods community start to use it and see us give talks to them about our work!
<KE0VVT>nckx: What's "Formal Method"?
<bandali>KE0VVT, https://en.wikipedia.org/wiki/Formal_methods
<brettgilio>KE0VVT: Think rigorous mathematics applied to programming language theory and synthesis of development.
<brettgilio>I provide a short explanation of it in my proposal email.
***catonano_ is now known as catonano
<wdkrnls>Hi Guix
<wdkrnls>One of my emacs packages symlink appears to be broken.
<wdkrnls>There is a guix.d directory in there, and under that the library exists, but Emacs can't find it.
<wdkrnls>Can this happen because of a power failure?
<wdkrnls>I would have thought not.
<bandali>nckx, hey, you around?
<nckx>bandali: Around yes, available less so, but shoot.
<bandali>nckx, ah :) thanks, i'll indeed ask anyway
<bandali>i'm trying to build emacs from git
<bandali>and emacs's build system crashes with this error:
<bandali>./temacs --batch --no-build-details -l loadup --temacs=pbootstrap
<bandali>Loading loadup.el (source)...
<bandali>dump mode: pbootstrap
<bandali>Symbol’s function definition is void: byte-run--unescaped-character-literals-warning
<bandali>make[1]: *** [Makefile:817: bootstrap-emacs.pdmp] Error 255
<bandali>seems to be related to its pdumper. i was wondering if y'all had seen an error like this before
<nckx>bandali: No, but I've seen valignatev discuss it here a few days ago.
<nckx>Adding a ‘--with-dumping=none’ configure flag ‘solved’ it for them, but that takes *ages* and is of course not really a solution.
<nckx>This is all from memory while I try & fail to find the log…
<bandali>nckx, ahh! i found it in my logs from 2019-12-12
<nckx> http://logs.guix.gnu.org/guix/2019-12-12.log
<nckx>Ah 🙂
<bandali>:)
<nckx>Hope I could at least point you towards someone who knows more, gotta go o/
<bandali>it seems to have to do with guix's emacs-exec-path.patch
<bandali>thanks nckx o/
<bandali>leoprikler, do you happen to know what's the issue with emacs 27's pdumper?
<bandali>if i don't apply guix's emacs-exec-path.patch it seems to build fine, but with it, it crashes with the error i pasted earlier
<apteryx>leoprikler: yes, well the exercise at hand is trying to coax a search path specification in matching either share/emacs/site-lisp or share/emacs/site-lisp/guix.d/some-name, and not the whole tree of directories recursively.
<apteryx>We only can use a string in a search path specification, and it is treated with the file-name-pred predicate, which strips teh abspath and match against the base name of the file.
<apteryx>so, currently not possilbe with a search path specification.
<apteryx>It'd be nice to be able to pass a function PRED instead of a string regexp, but this entails all kinds of complications (needs to be serializable because it ends up in a $PROFILE/manifest file).
<apteryx>seems the more "easy" thing to do would be to add another field to the search path spec record, e.g. match-against-basename? which would defaults to #t for backward compatibliity. It's not very elegant.
<brettgilio>nckx: floods of emails from me incoming. Sorry :)
<wdkrnls>Out of the blue I hade to modify my load path for emacs-ess: (add-to-list 'load-path "/home/k/.guix-profile/share/emacs/site-lisp/guix.d/ess"). Not very reproducible :(
<brettgilio>I don't even understand where people are getting this guix.d directory in site-lisp anymore? I thought Maxim deprecated that with the rebuild of emacs-build-system.
<brettgilio>wdkrnls: are you on the latest pull of Guix?
<brettgilio>nckx, bandali: ^ idk Maxims' IRC so I am pestering you now
<wdkrnls>brettgilio: I upgraded packages this weekend, but it was working fine until now.
<wdkrnls>I searched the emacs-xyz.scm file and there were other references to guix.d in there.
<wdkrnls>For example, magit uses it.
<wdkrnls>I tried pulling again, but it tells me "nothing to be done"
<nckx>brettgilio: Maxim's apteryx. TBH I think I'm 2 iterations behind in the Emacs Experiments & it's 5:20 here, off to bed. o/
<apteryx>when using 'guix refresh -l', which number counts? the first one?
<wdkrnls>guix refresh --help
<wdkrnls>whoops... thought that this was a shell :)
<brettgilio>apteryx: the bigger one is the one I go off of
<brettgilio>The total number of dependent packages needing rebuilt
<apteryx>OK. Looking at the code it seems the bigger number includes "implicit" dependencies. I'm not sure what that means (other than they are represented as nodes without any edge).
<prevedmedved>Why Chromium is considered to be non-free as it's open-source?
<brettgilio>I guess prevedmedved didn't want to stick around to hear the sore truth on "open source" and chromium. Lol
<brettgilio>bandali: haha
<bandali>brettgilio, yup ;)
<brettgilio>apteryx: thank you for looking at the bytecode compilation issue leoprikler and I opened.
<wdkrnls>I'm a little curious about this as well as I would love to get more researchers in my field using Guix, but they all want to use rstudio, but rstudio depends on some qtwebengine which seems to be powered by chromium.
<wdkrnls>even though RStudio is AGPL
<brettgilio>wdkrnls: we have an issue on QtWebengine open in our tracked right now you might be interested in
<brettgilio>Tracker*
<wdkrnls>Hmm... got ERR_EMPTY_RESPONSE from issues.guix.gnu.org - I suppose I'll have a look later.
<brettgilio>wdkrnls: can also look through the debbugs interface
<brettgilio>rekado_: there is an issue with issues.guix.gnu.orh
<brettgilio>Goodnight Guix.
<prevedmedved>How long does it take you to guix pull guix system reconfigure on your setups?
<bandali>it depends on your cpu power and connection speed, and how far behind your current packages are
<bandali>could be anywhere from seconds to hours
<prevedmedved>brettgilio Goodnight. It's morning in Eastern Europe btw ;)
<prevedmedved>bandali Does it depend from me using VM even provided with decent resources?
<bandali>prevedmedved, that probably helps
<bandali>also another factor it depends on is how much your system has to build
<bandali>vs. how much you can use already-built packages from guix's substitute server
<bandali>(if you've enabled them)
<bandali>*servers
<prevedmedved>Oh I didn't know I had. What is particular way of doing it?
<bandali>you can find relevant info about it in the guix manual :)
<bandali>how did you install guix on this vm?
<bandali>part of the process is authorizing the servers' signing keys
<prevedmedved>I followed Guix manual and copypasted the commands.
<prevedmedved>bandali I didn't know its covered in the manual. Thanks for help.
<nckx>apteryx: Counts for what? The second (=larger) one is the total number of rebuilds that determines the target branch.
<nckx>wdkrnls: You can use https://debbugs.gnu.org/cgi/pkgreport.cgi?package=guix in the mean time. https://debbugs.gnu.org/cgi/bugreport.cgi?bug=… if you have a bug number.
<dftxbs3e>hey nckx!
<nckx>Yo.
<nckx>dftxbs3e: I forwarded a mail I got from OSUOSL a few days ago to guix-devel; basically, my application got lost and they apologised and promised to take care of it soon and I haven't heard from them since 🙂
<nckx>dftxbs3e: …actually, an update! (I'm just checking my mail over breakfast now.) An ‘I approve’ mail was CC'd to me. No further text or context, but that's good.
<dftxbs3e>nckx, Great! The details of the machine should come out to you very soon!
<nckx>Excellence.
<apteryx>nckx: counts for being counted as dependencies ;-). I must confess I find it confusing that 'guix refresh -l' would print something like: Building the following 100 packages would ensure 143 dependent packages are rebuilt: proof-general@4.2 [...].
<apteryx>"Building the 100 following packages?" I just asked about Emacs.
<apteryx>I asked the transitive dependencies of Emacs, to be precise.
<apteryx>I also find it confusing that the manual says this command only *approximates* the number of rebuild, without detailing why an approximation must be used at all or what is being simplified out.
<nckx>apteryx: I don't understand. guix refresh --list-transitive emacs → ‘emacs@26.3 depends on the following 262 packages: [262 packages]’.
<nckx>I thought you were talking about ‘guix refresh -l’.
<apteryx>nckx: ah, yes, that's what I was asking about. That's what happens when you wake up in the middle of the night and think it's a good time to post a reply ;-)
<nckx>apteryx: ‘refresh -l’ is approximate because it doesn't currently understand inheritance, which is why many things in base have ridiculously low -l counts.
<nckx>apteryx: No worries, it's pre-coffee morning here.
<apteryx>oh, that'd be really useful to add as a note to that "approximate" mention in the manual.
<nckx>Feel free to critique ‘refresh -l’, just don't confuse it with ‘[asking] the transitive dependencies of Emacs, to be precise’.
<nckx>apteryx: That's one caveat I know of (because I tried to fix it and gave up 🙂), there may be more.
<nckx>But it's probably the most spectacular one.
<nckx>(guix refresh -l glibc FTW.)
*nckx → ☕ \o/
<apteryx>I see. Inheritance being a macro thing and being carried out before the code runs doesn't leave much information behind, I guess. That probably leaves one with having to parse the sources to figure out the relations.
<apteryx>perhaps we could fix the guix-record to annotate the resulting record object with a 'inherited from' property, that could be readily queried
<nckx>My approach was to change said macro to add a ‘inherits’ field (or property) to the resulting record, but my Scheme was really lacking back then.
<nckx>Oh, we seem to have written the same thing.
<nckx>That could be good.
<apteryx>seems like a solution is being drawned, hehe
<nckx>I could try again now that I've actually managed to use define-syntax in a sentence once, but by all means volunteer.
<apteryx>:-)
<nckx>apteryx: But anyway, re: your original gripe with refresh -l that I now understand: I don't know why it prints the first number either (which is the number of packages listed after the :, if any). Like, cool that you've calculated the minimum set, but is that number actually a useful hint like the second one is? I don't know.
<nckx>Prolly ask civodul.
<apteryx>I checked the sources, and it deosn't help me much except that the lower count is the number of nodes without nodes having zero edges
<apteryx>I guess these are what are called implicit dependents
<apteryx>yes, I'll try asking civodul later
*apteryx goes back to bed
<nckx>That doesn't seem accurate to me. The name ‘implicit’, I mean, your reading of the code may well be correct.
<nckx>They can be very explicit indeed, the trivial example is only A depending on B, -l B will print A. That's not implicit.
<nckx>apteryx: Good night!
<nckx>apteryx: Regardless, I think we can safely say that if the documentation manages to confuse a co-maintainer, the documentation can probably be improved.
*nckx never reads documentation, problem solved.
<leoprikler>bandali: The error with Emacs' portable dumper is, that the dump file lands in libexec and therefore gets wrapped by glib-or-gtk-wrap
<leoprikler>This is of course nonsense, as the dump file is not actually meant to be executed, but rather meant to be loaded into the running Emacs process.
<leoprikler>I already helped someone else on IRC with this problem, specifically adding a phase that reverts this change.
<leoprikler>bandali: Have a look at https://github.com/valignatev/guix-channel/blob/master/valignatev/packages/emacs-master.scm
<leoprikler>btw. didn't valignatev already inform you about this 5 days ago?
<leoprikler>I find it funny how I searched for the logs when nckx already posted them. Very good, me. 🙃️
***xwvvvvwx- is now known as xwvvvvwx
***IUSR_ is now known as IUSR
***specing_ is now known as specing
***w2gz is now known as w1gz
<roptat>Hi guix!
<leoprikler>Hi roptat
***jetomit_ is now known as jetomit
<paprika>hi all
<paprika>what is an alternative to pastebin?
<paprika>I would like to post my config.scm here to find out if it contains errors
<leoprikler> http://paste.debian.net/
<paprika> http://paste.debian.net/1121350/
<paprika>thank leoprikler
<paprika>guix system: error: some substitutes for the outputs of derivation `/gnu/store/ipfnqjbg12v73yyclqx46ds9s8q5r70d-nss-certs-3.46.1.drv' failed (usually happens due to networking issues); try `--fallback' to build derivation from source
<paprika>that's the error I get
<paprika>but my connectivity is fine
<leoprikler>and if you try via --fallback?
<roptat>paprika: this is not an indication that there is something wrong with your config, but that something went wrong while building a package it needs
<roptat>nss-certs I remember can fail because of locale issues in the guix daemon
<paprika>I've logged in as root first now
<roptat>I don't remember the details though
<paprika>which has made the difference for me in the past
<paprika>if that fails I'll try with --fallback
<paprika>is it normal that sudo gives a different result than first loggin in as root and then doing a reconfigure?
<leoprikler>sudo does use the $PATH root would have
<leoprikler>if you guix pull in your local profile and then do sudo guix you use the updated guix
<paprika>ah, yeah, I also did guix pull when logged in as root
<paprika>the guide online suggests to do guix pull and then do sudo giux reconfigure, however
<leoprikler>that's because logging in as root has been considered harmful even before guix itself was a thing
<paprika>yeah I know, but I've messed up so many times now that I know what not to do
<paprika>ok, time to reboot
<paprika>it worked! :D
<paprika>I'm starting to love guix system more and more
<leoprikler>so root could install nss-certs from the same (or similar enough) guix as strawberry?
<paprika>yes
<leoprikler>this could really be a locale issue, as roptat hinted at
<paprika>might be, I never really understood those
<paprika>(although I think I've configured them correctly in my config.scm)
<ng0>is 'impacket' (https://pypi.org/project/impacket/) packaged in guix? trying to determine how useful it would be to provide a choice between bundled and pypi version for gnurl tests, curl currently bundles this module with a rather old version
<sneek>ng0, you have 1 message.
<sneek>ng0, efraim says: sure I can test the gnurl bug later, i'm not at home ATM
<leoprikler>ng0: Not currently. You could try the pypi importer.
<ng0>i leave that up to the one who updates the guix package then
<coco>i just installed guix with the "graphical" installer. it told me to remove the installation medium and reboot. when doing so, i get: "ERROR: In procedure open-file: No such file or directory: "/gnu/store/k959longhash-linux-modules/sdhci_pci.ko". what could be the problem, any hints?
<roptat>is that at reboot?
<roptat>(after grub?)
<coco>it's after choosing guix from the (single-entry) list, so that should be after grub, i guess
<roptat>right, so I think the installer wrongly chose the name of a module (sdhci_pci instead of sdhci-pci)
<roptat>so to fix this I suggest you boot the installer again, but don't follow the graphical installer
<coco>i have screenshots of the config.scm
<roptat>instead, mount your new root partition at /mnt (mount /dev/sda1 /mnt for instance) and edit /mnt/etc/config.scm
<coco>(initrd-modules '("mmc_block" "sdhci_pci"))
<roptat>in config.scm you should find "sdhci_pci". replace it with "sdhcp-pci"
<roptat>right, that one :)
<roptat>then I'll need the manual, wait a minute :)
<coco>it said "initializing operating system under '/mnt'...". does that mean it mounted /dev/sda1 to /mnt?
<roptat>yes
<roptat>it means it installed everything on whatever was mounted on /mnt
<roptat>maybe it wasn't /dev/sda1
<coco>alright, so just fixing the config.scm (dash instead of underscore) should do the trick then?
<roptat>yes, but then we need to instantiate the new system
<roptat>so we're going to re-run the last steps that were done by the installer, but manually
<roptat>that's the part explained here in the manual: https://guix.gnu.org/manual/en/html_node/Proceeding-with-the-Installation.html#Proceeding-with-the-Installation
<coco>i guess i need to restart the whole thing, will do so now
<roptat>yes, you need to do everything on the installer medium
<roptat>once you have changed your config.scm, run "herd start cow-store /mnt"
<roptat>you can skip the part about creating your config.scm of course
<coco>ah, so i first let guix do it's magic with the "wrong" config.scm, then, before rebooting, i edit config.scm and reinstantiate?
<roptat>so you'll have to only do "guix system init /mnt/etc/config.scm /mnt"
<roptat>no, you already have a system with a config.scm on it
<roptat>you don't need to reinstall everything, but you need a booted system with guix to reinstantiate after you change the config
<coco>oh, yeah, oopsie :D i have already formatted the disk now. not very clever
<roptat>the file was already created by the installer when you first installed (as /etc/config.scm, so it should be available at /mnt/etc/config.scm after you mount your root fs)
<coco>ok, i see
<roptat>ok, that was not necessary, but we can start again ^^
<roptat>I'm afraid the installer won't let you change your config.scm though...
<raghavgururajan>Hello Guix!
<raghavgururajan>Woah! 136 new packages in the recent commit. Congratulation to Guix and all contributors. :-)
<coco>where do i report the _ vs - issue of the installer, btw?
<roptat>it's already known
<roptat>I don't think it was fixed yet though...
<roptat>the issue is that the self-reported name from modules don't always match their filename
<coco>during "guix system init /mnt/etc/config.scm /mnt", i get an error "no space left on devie". df tells me that / is out of space, but /mnt has plenty of space left
<leoprikler>you have to `herd start cow-store /mnt` before initting the system
<coco>i see, thanks
***somethinglittle is now known as nothingmuch
<civodul>Hello Guix!
***deesix_ is now known as deesix
<roptat>hi civodul :)
<coco>now i get this error: "/mnt/boot/efi doesn't look like an EFI partition". should i do a manual installation with MBR then?
<pkill9>you may need to mount your efi boot partition to /mnt/boot/efi
<pkill9>have you created one?
<roptat>probably the installer created it for you the first time
<coco>yeah, the installer recognized the storage as gpt and chose efi
<coco>good hint, i only mounted the large partition to /mnt, but didn't mount the efi boot partition
***emacsoma1 is now known as emacsomancer
<coco>roptat leoprikler pkill9: alright, my guix installation is up and running now. thanks a lot for your immediate help :-)
<leoprikler>no problem
<pkill9>you're welcome :)
<roptat>glad you solved your issues :)
<dutchie>anyone else seeing 502 error on issues.guix.gnu.org?
***ng0_ is now known as ng0
<roptat>same here
<roptat>civodul, ? :)
<Iacob>yes
<civodul>roptat, dutchie: should be back up!
*civodul tired of having to restart it :-/
<jonsger>civodul: what is the reason why you need to restart it?
<civodul>jonsger: (1) it's leaking file descriptors since "recently", and (2) it's not part of the config in maintenance.git, so it's started "by hand"
<civodul>we should fix #2 first
<Parra>why guix does not like npm? XD
<Parra>I had an error today related about the lack of HOME enviroment var and npm, after setting it up, now I'm getting "cb() never called, this is an error of npm itself."
<Parra>and I can't check the logs, it seems guix deletes them after build finishes..
<leoprikler>Is this inside a package installation or when using npm?
<Parra>I wrap npm inside cmake
<Parra>so complexity is even higher
<Parra>I'm using cmake build system but inside it runs some npm install commands
<Parra>I'm not sure how to handle this, my software has been mainly designed in Debian, and it's self contained but never was designed to run or be packaged in Guix
<Parra>I have it half packaged thought
<leoprikler>You will likely want to mix some phases of node-build-system into your package.
<leoprikler>e.g. node:configure before or after configure
<Parra>but this will break my cmake integration
<Parra>and also, I'm not enough advanced to mix both
<Parra>I did some mix already to make it work
<Parra> https://github.com/metacall/distributable/blob/8acbc90e02f76e2964f7facbb4eb1700621f93ba/source/metacall.scm#L124
<Parra> https://github.com/metacall/distributable/blob/8acbc90e02f76e2964f7facbb4eb1700621f93ba/source/metacall.scm#L240
<Parra>this worked
<Parra>I may be able to set a variable in cmake that checks if we are building in guix so it disables all steps related to npm or pip, do you think that's an acceptable solution?
<civodul>Parra: Guix likes everyone including npm :-), but see https://dustycloud.org/blog/javascript-packaging-dystopia/
<leoprikler>instead of deleting check, you'd usually go for #:tests #f
<Parra>it worked with check so I don't really care XD
<leoprikler>why is node-addon-api a native input?
<Parra>because I only need some headers to build, the rest of it is useless
<Parra>I don't want it packaged together with my tarball
<leoprikler>fair enough
<Parra>I read in docs that native inputs aren't exported, am I right?
<leoprikler>as far as I can tell by your explanation, you're using it correctly
<Parra>fine
<Parra>civodul: thanks for the link, I will read it in deep
<bandali>civodul, hey, so it seems dancol removed the little (setq exec-path nil) thingy in his commit introducing the new pdumper for emacs 27
<bandali> https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=d12e5d003d503025c1c9b0335d6518a6c3bdfae1
<bandali>try searching for exec-path there ^
<bandali>also, lisp/loadup.el where the emacs-exec-path.patch guix patch sets it to nil seems to have changed significantly
<bandali>not sure if the patch will apply anymore or not
*jonsger starts working on gnome 3.34 :P
<bandali>with emacs-exec-path.patch, the dumper crashes and build fails, but without it, it seems to work
<bandali>but of course, likely result in larger size for emacs closure
<bandali>any thoughts on this?
<bandali>i haven't yet tried updating emacs-exec-path.patch with correct line numbers etc to see if that will resolve the issue, or if the emacs devs need to do something about it
<leoprikler>could you first check, whether exec-path is preserved in the portable dump?
<bandali>how would i best check that? fwiw, if i don't apply our emacs-exec-path.patch, emacs builds just fine
<bandali>but with it, the build will crash
<leoprikler>after building it, run it and check the exec-path variable
<leoprikler>if it is what you'd be expecting from your current path variable, things should be fine
<leoprikler>if it is not, the patch needs to be adapted
<bandali>yeah it's non-nil, and among other things, has a bunch of /gnu/store/... paths it seems
<bandali>but removing our patch mean larger closure size?
<bandali>but *doesn't
<leoprikler>it means larger closure size if the paths end up in the binary, which they seem to do
<bandali>i don't have access to a emacs-26.3 from guix, but for that, they don't end up there?
<bandali>i'm still not clear what needs to be done
<civodul>bandali: i think we'd need to check what emacs-exec-path.patch was about and whether it still makes sense with pdumper
<leoprikler>you need to make sure, that exec-path is dumped as nil while being compatible with pdumper
<bandali>leoprikler, right, so the patch does need updating
<leoprikler>yep
<bandali>civodul, ha. some context from a few years ago, from the emacs tracker https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20330
<bandali>if anyone else is more knowledgeable about this, i'd love for them to take the lead on this
<bandali>i'd be happy to send what i have so far
<civodul>bandali: you can try building Emacs 27 without the patch, and then look at "guix gc --references" of its result
<leoprikler>I'd be willing to have a look at it. By the way, could you tell me the difference between your and valignatev's build from the 12th?
<civodul>bandali: (cont.) the result should not refer to gcc, binutils, etc.
<bandali>civodul, thanks for the tip
<bandali>leoprikler, i'll reply in a minute
<bandali>speaking of! valignatev has returned :p
<alextee[m]>arr can we please do something about the "building database for manual pages" phase? it takes AGES to finish
*valignatev
*valignatev looking at logs
<jonsger>nice a glib update is required for gnome 3.34 :)
<leoprikler>juicy
<leoprikler>I already look forward to updating all the extensions.
<bandali>leoprikler, here's what i have: https://git.sr.ht/~bandali/guix-bandali/tree/a1a1a54cbd3ff1f6a7921b37975f5af778b52bb1/bandali/packages/emacs.scm
<bandali>i added you and valignatev's copyrights as well
<bandali>quite similar to valignatev's
<bandali>it can be greatly shortened though
<bandali>if we update the main emacs package and somehow have delete-files not fail if eshell/esh-groups.el doesn't exist
<bandali>if we do that, we could just use (snippet (origin-snippet (package-source emacs)))
<valignatev>Btw, I've noticed that my EMACSLOADPATH is wrong. For some reason it doesn't have this dir: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/emacs.scm#n196
<valignatev>It only has export EMACSLOADPATH="${GUIX_PROFILE:-/gnu/store/9hzgpbslhjq9x12bpsw4kvhgasa0xn4k-profile}/share/emacs/site-lisp${EMACSLOADPATH:+:}$EMACSLOADPATH" which is weird
<valignatev>in my guix-profile/etc/profile
<valignatev>bandali: let me know if your EMACSLOADPATH is ok after installing this recipe
<valignatev>Ah, lmao, I just realized why it couldn't be ok
<bandali>leoprikler, perhaps if we use find-files like the previous two entries?
<bandali>valignatev, oh! why?
<valignatev>bandali: Because it looks for "(string-append "share/emacs/" version "/lisp")" where version will be "27.0.50" for emacs-next and not "(git-version "27" revision commit)"
<valignatev>I mean, the actual directory will be /share/emacs/27.0.50/lisp
<bandali>leoprikler, valignatev, also, what do y'all think about renaming the emacs executable to emacs-next so it could easily be used alongside the current stable emacs release? i think emacs has a configure option for it
<bandali>valignatev, hmm
<leoprikler>I don't think this will change much, because other executables exist in bin
<valignatev>I personally ok with this. If people want to use emacs-next as their main emacs, they can alias it. I don't know if Guix has some conventions for this
<leoprikler>i.e. emacs-next will be either the only one or you'll have to use environments
<bandali>wouldn't it make it more convenient anyway?
<bandali>is there a downside to using emacs-next for the executable name rather than emacs?
<leoprikler>yes, extra typing :(
<bandali>LOL
<bandali>okay
<bandali>i don't have a strong preference
<bandali>also, leoprikler, if you end up writing and sending an updated emacs-next patch, i'd appreciate it if you could cc me on the mail as well please
<leoprikler>I already have enough packages waiting to be merged, I'll just debpaste it here if I end up finding a fix
<alextee[m]>why does guix system reconfigure need to redownload everything if i already have the latest versions installed?
<alextee[m]>after doing gc
<leoprikler>because you gc'd
<alextee[m]>but gc doesn't delete my programs does it?
<alextee[m]>can't it check my installed programs' hashes or something and tell that i already have the latest verions?
<leoprikler>nope, but it deletes pre-graft versions of them as well as native inputs, so guix has no way of knowing they're the latest versions
<alextee[m]>this is very storage inefficient hmm
<alextee[m]>it fils up 50GB of storage when my programs are only 20ish
<alextee[m]>never thought my root partition would need more than 50GB
<bandali>leoprikler, thanks, sounds good
<leoprikler>okay, so for the record, emacs-next does refer to gcc et al.
<leoprikler>time to fix it
<bandali>ah, cool, thanks for checking
<bandali>so we do need an updated version of the patch
<bandali>i think it'd be nice to first try to insert it back in one (or both) of the following places: 1. right before (if (eq t purify-flag) (as the patch currently does, but needs line no update), and 2. where it was before dancol removed it in his commit introducing pdumper
***sebboh2 is now known as sebboh
<jje>trying to configure network manager and when I add network-manager-service-type guix complains that networking is provided twice. so i then remove networking from use-service-modules. but the it complains i am missing a use modules form. whats the trick to this?
<leoprikler>are you using %desktop-services? If so, you already have a network-manager-service-type.
<leoprikler>Use modify-services to edit it
<leoprikler>(i.e. provide a new config)
<jje>thank you leoprikler
<jonsger>disable one test, enable one test :P
<akacase>Do we have any updates on power9 on guix?
<jonsger>akacase: I don't think really. there is one patch http://issues.guix.gnu.org/issue/38459 in order to build the bootstrap-tarballs
<divansantana>Should PYTHONPATH be set and "working" by default on Guix system? IE PYTHONPATH doesn't contain .local/ first on my system.
<leoprikler>PYTHONPATH should not contain .local though?
<divansantana>leoprikler:I'm new to python and well Guix, sort of lol. Shouldn't PYTHONPATH contain $HOME/.local/lib/python3.8/site-packages .
<divansantana>I'm finding pipenv not working and trying to fix it.
<leoprikler>Guix supersedes everything pip-related and it installs python libraries into your Guix profile.
<valignatev>divansantana: It shouldn't, check: https://docs.python.org/3/using/cmdline.html?highlight=pythonpath#envvar-PYTHONPATH
***lispmacs is now known as Guest69769
***lispmacs` is now known as lispmacs
<lispmacs>hi, i'm running gnome DE. I see my scanner coming up in dmesg, but simple scanner is not seeing it
<valignatev>divansantana: But pipenv might not work for several reasons though. And yes, guix is not very friendly to other package managers. What exactly doesn't work for you?
<divansantana>leoprikler:ok. So how do I setup pipenv because it's not a guix package. I'm trying python3 -m pip install --user pipenv
<lispmacs>do i need to join a permissions group or add some service
<leoprikler>divansantana: You don't. You use `guix environment` instead.
<leoprikler>lispmacs: I don't think simple-scan needs specific permissions, but what is your working setup on other distros (assuming you have one)?
<nckx>lispmacs: What does scanimage -L say?
<leoprikler>bandali: http://paste.debian.net/1121432/
<divansantana>I'd like to learn and use guix environment instead, but I still need to get more comfortable with guix and guile before doing that. Would like to have pipenv working since it's what others in my team would use.
<divansantana>Let me see what error I get.
<divansantana>ModuleNotFoundError: No module named 'pip._internal.main'
<divansantana>err.
<divansantana>get ModuleNotFoundError: No module named 'pip._internal.main' when do pipenv install -r requirements.txt
<lispmacs>leoprikler: I used to use simple-scan on Debian 9 with this scanner, I don't recall having to set an special permissions.
<bandali>leoprikler, and that does it?
<lispmacs>nckx: what package is "scanimage" in?
<nckx>lispmacs: sane-backends (sic).
<leoprikler>bandali: I checked the references and only get gcc:lib (no more gcc).
<bandali>leoprikler, nice, thanks a bunch!
<lispmacs>nckx: is this something I'm supposed to install as a system service?
<leoprikler>But you're welcome to try it on your own and see if you can disprove me 🙂️
<nckx>lispmacs: No, a package.
<lispmacs>okay, installing locally now
<kirisime>I thought I'd try packaging Geary, but the install step fails and I'm not familiar enough with meson/ninja to figure out why.
<leoprikler>kirisime: probably post-install
<nckx>lispmacs: If it prints nothing, try adding the sane-backends udev rule to your system configuration. See the android-udev-rules example under (guix)Base Services in the manual.
<leoprikler>Try figuring out which file contains a call to gtk-update-icon-cache and substitute* it to true
<nckx>What's fishy about that is that it refers to a ‘scanner’ group which doesn't exist on Guix System and yet I can scan just fine.
<nckx>With simple-scan, xsane, and scanimage.
<leoprikler>the scanner group is not a requirement afaik
<nckx>Well, it doesn't exist.
<leoprikler>it may perhaps be a recommendation for systems where you can't trust normal users to not scan their butts
<leoprikler>so you have to be member of the scanner group to scan your butt for scientific purposes
<nckx>My puny flatbed would not survive that.
<leoprikler>(Probably in a school setting, where you have big chunky multi-function machines and eight-graders.)
<lispmacs>nckx: scanimage -L is not identifying any scanners. I'll work on adding the udev rules
<divansantana>setting export PYTHONPATH=/home/ds/.local/lib/python3.7/site-packages:$PYTHONPATH helped fix pipenv.
<nckx>crw-rw-r-- 1 root root 189, 5 Dec 17 20:19 /dev/bus/usb/001/006 (my scanner)
<nckx>And I am a member of the root group.
<nckx>I wonder.
*nckx sets the devil's chmod.
<leoprikler>"I am a member of the root group." Hmm...
<divansantana>The next issue is getting pyinstaller to work on guix. After pyinstall my.py , when I run the executable I get bash: No such file or directory
<nckx>leoprikler: Hmm?
<leoprikler>Again, you don't want to do that – you want to install stuff nicely and cleanly with guix.
<divansantana>leoprikler: I agree. But for now, I want to learn python, not guile and guix. I know, I'm on the guix channel, lol :)
<nckx>lispmacs: If I chmod the USB device node above to 666, or add my test user to the ‘root’ group, my scanner shows up with ‘scanimage -L’. That's not… good. For that udev rule to work out of the box we should probably add a scanner group, although leoprikler seems to disagree. I'm also sceptical: plenty of people have scanned on Guix System in the past.
<nckx>lispmacs: As a quick test, could you run ‘lsusb’ to get the bus & device of your scanner, then ‘chmod 666 /dev/bus/usb/<bus>/<device>’ and try again?
<leoprikler>Actually, if a scanner group can be used to fix this issue, I'm for it, although chmod 666 does have a nice ring to it as well.
*nckx arrogantly assumes that this is not a SCSI scanner, which our sane-backends still support.
<nckx>leoprikler: As usual, the boring solution is probably more correct (yawn).
<leoprikler>Well, we should probably use the scanner group to not cause complete anarchy on schools that use Guix (heh).
<leoprikler>so... time to write a sane-service-type then?
<nckx>leoprikler: That would be needed for network scanning (saned), but for regular (USB) desktop scanning a group + abovementioned udev group should suffice.
<lispmacs>nckx: with the chmod fix, I can now scan
<leoprikler>But does USB scanning not work via sane as well?
<leoprikler>perhaps we could use a flag to disable networking if we just want the USB use case
<lispmacs>nckx: I've added the udev service to my config.scm, but have this separate problem where if I reconfigure system to my current guix pull, I lose networking, and I'm having trouble remembering how to get back to my previous guix pull
<lispmacs>I submitted a bug report
<nckx>leoprikler: Yes, but a sane-service just to wrap a single group + udev rule is pretty ugly to me. No? Over-abstracted anyway.
<nckx>lispmacs: Cool. Then the proper fix is to add a scanner group to Guix, would you mind filing a bug?
<nckx>lispmacs: …ne'er mind, and thank you.
<lispmacs>nckx: I submitted a bug report on my networking problem, but not on the scanner problem
<nckx>lispmacs: You still need to add a (user-group (id something-under-1000) (name "scanner")) and your user to it for the udev rule to work.
<leoprikler>Is there already a udev rule for that?
<leoprikler>(in Guix System?)
<nckx>As part of sane-backends.
<leoprikler>but how would that udev-rule be installed system-wide without extending udev-service-type?
<nckx>leoprikler: modify-services.
<nckx>Are you saying that's too user-unfriendly?
<leoprikler>I think we could perhaps add a service that "just works"™ instead of having users edit three places to make it work (user, groups and modify-services).
<nckx>If so I'll defer to your judgment, I'm not the target audience.
<nckx>OK.
<leoprikler>We could add the group with the service and cons* the service to %desktop-services, which makes for a much simpler config.scm
*nckx is apparently an old ‘don't move my stuff for me’ fuddy-duddy.
<nckx>leoprikler: Yes, that's fine.
<leoprikler>We already have "yes, please move my stuff for me" services for other stuff as well IIRC.
<nckx>Possible.
<nckx>I don't use them so shouldn't have an opinion.
<jonsger>my work on gnome-3.34 https://gitlab.com/jonsger/Guix/tree/wip-gnome-3.34 It's just a few packages at the moment. There are packages (epiphany) who need a newer glib. I left them a side for now, because glib has 4k+ dependencies :(
<jonsger>sneek: later tell kkebreau I started working on gnome-3.34. See https://gitlab.com/jonsger/Guix/tree/wip-gnome-3.34
<sneek>Okay.
<ScaredySquirrel>hello how do I reset my root password with a livecd?
<nckx>ScaredySquirrel: You can edit Guix's /etc/password file and remove the x in the second column.
<nckx>you:x:1000:1000:… → you::1000:1000:…
<ScaredySquirrel>trying to update from 1.0.0 to 1.0.1 doesn't work with info-reader-6.6 /gnu/store cannot refer to perl-5.30.0 path under /gnu/store
<ScaredySquirrel>that does say something about the output path while installing
<vagrantc>ScaredySquirrel: that sounds like an issues introduced much more recently than 1.0.1
<vagrantc>and since reverted
<vagrantc>1.0.1 was released very soon after 1.0.0
<ScaredySquirrel>ok but I even ran guix pull multiple times in attempts to resolve my issue
<vagrantc>ScaredySquirrel: you'll need something newer than 8c4c5bf86ac57e2923f51f9dcc5794dedb85ed3c
<ScaredySquirrel>vagrantc: ah but it is that revision
<ScaredySquirrel>I can't login so I have to fix that first
<vagrantc>sure
<ScaredySquirrel>anyways, I try to get newer than that 8c4c5bf86... but it doesn't detect any newer revision than that
<ScaredySquirrel>it's the savannah.gnu.org mirror
<jje>ok so i wrote a modify-services for desktop-services to configure network-manager but it is telling me this https://paste.debian.net/1121442/
<ScaredySquirrel>ok so I try the --repl argument in GRUB and that lands me to an initramfs shell but I have no access to the USB keyboard
<vagrantc>ScaredySquirrel: i've definitely pulled newer versions than that ... so perhaps there is something amiss with your networking?
<ScaredySquirrel>vagrantc: no idea it's just TWC Spectrum internet service
<leoprikler>jje: that's a typo
<leoprikler>sevices instead of services
<jje>ok thanks
<ScaredySquirrel>ok so if there is no usb keyboard support in the initramfs how would I use that keyboard in the initramfs?
<vagrantc>why not try a live cd instead?
<ScaredySquirrel>I did try the Fedora 31 livedvd and I ran chroot /gnuguixsys /run/setuid-programs/passwd
<ScaredySquirrel>maybe that would reset it
<ScaredySquirrel>moment
<leoprikler>why not try guix install cd? :)
<nckx>ScaredySquirrel: I answered your password question above.
<vagrantc>chroot with guix is ... tricky.
<vagrantc>not impossible, but a lot of the usual assumptions don't work so well
<ScaredySquirrel>vagrantc: ok if you run the chroot /gnuguixsys /run/setuid-programs/passwd command it'll let you reset the root password
<ScaredySquirrel>um I'm at git revision 29fd736
<vagrantc>that seems unlikely, as /run is only set up at boot
<ScaredySquirrel>I tried it and it worked
<ScaredySquirrel>the root password was definitely forgotten
<vagrantc>from where?
<ScaredySquirrel>A fedora 31 livedvd
*vagrantc wonders how fedora managed to populate the /run directory with symlinks
<nckx>And make the passwd command affect /mnt/etc/passwd.
<vagrantc>as /run is normally a tmpfs
<nckx>But hey, 't is the season of wonder.
<ScaredySquirrel>nckx: apparently it did
<nckx>ScaredySquirrel: Joy!
<nckx>Now don't forget it again 😛
*vagrantc doesn't remember root passwords anywhere
<vagrantc>usually disable them... :)
<ScaredySquirrel>ok so hrmm why won't git take down the newest revision?
<nckx>ScaredySquirrel: AFAIK info-reader on master is simply broken.
<ScaredySquirrel>i can see that
<vagrantc>the revert that was pushed fixed it for me
<nckx>ScaredySquirrel: Then why ask…
<vagrantc>unless it got borked again
<ScaredySquirrel>vagrantc: how might I revert from master then?
<vagrantc>"guix pull" pulled in the latest updates for me, including the thing that fixed the issue you're facing
<ScaredySquirrel>what revision does yours' say?
<vagrantc>if that doesn't work, i presume it would issue some errors or warnings as to why it didn't work
<vagrantc>i don't remember off the top of my head, but e5c32a3afa4b3b24fa8e93d8453b0977e492a27e definitely worked for me
<vagrantc>which contains the revert of the broken commit
<ScaredySquirrel>ok um what is that commit in the short form?
<vagrantc>it's the first N of the proper commit
<vagrantc>i think you typically need at least N >= 6
<vagrantc>but i prefer to use full commits
<ScaredySquirrel>hmm how would I try to diff this commit vs that commit?
<ScaredySquirrel>git diff I think
<ScaredySquirrel>moment
<coco>what is the differnce between 'guix system reconfigure' and 'guix system refresh'?
<ScaredySquirrel>how would I try to diff this commit vs that commit?
<ScaredySquirrel>I don't know how to use git
<vagrantc>ScaredySquirrel: "git show COMMIT" will show you the changes introduced in COMMIT
<vagrantc>ScaredySquirrel: "git diff COMMIT1..COMMITN" will show you the differences from COMMIT1 to COMMITN
<vagrantc>ScaredySquirrel: but what are you trying to accomplish?
<ScaredySquirrel>that I can see but how do I use git clone?
<coco>i just ran 'sudo guix reconfigure /etc/config.scm'. when finished, it tells me 'Consider setting the necessary environment variables by running: GUIX_PROFILE="/root/.config/guix/current"; . "$GUIX_PROFILE/etc/profile" '. am i supposed to change the according lines in /etc/profile (which currently has /run/current-system/profile as $GUIX_PROFILE)?
<ScaredySquirrel>I tried git clone https://git.savannah.gnu.org/git/guix.git
<vagrantc>coco: also simply logging out and logging back in should do the right thing
<vagrantc>ScaredySquirrel: what are you expecting?
<ScaredySquirrel>vagrantc: the guix repository from the savannah gnu site to show up in the guix directory
<ScaredySquirrel>thereby cloning the git repository
<vagrantc>that should work ... did you get any output?
<vagrantc>any warnings or errors?
<ScaredySquirrel>it says: Cloning into 'guix'...
<coco>vagrantc: that is not the case for root
<ScaredySquirrel>fatal: Problem with the SSL CA cert (path? access rights?)
<vagrantc>ScaredySquirrel: https://guix.gnu.org/manual/en/html_node/X_002e509-Certificates.html#X_002e509-Certificates
*vagrantc wouldn't recommend running as root
<vagrantc>but i guess that's a philosophical question of preference
<vagrantc>coco: you shouldn't have to manually do anything when running "guix system reconfigure ..." though sometimes you may need to reboot
<ScaredySquirrel>ok I installed nss-certs but it still says the same thing about the SSL certs
<vagrantc>ScaredySquirrel: did you do the other things described?
<vagrantc>e.g. setting the environment variables
<vagrantc>SSL certs are admittedly a bit confusing with guix
<coco>vagrantc: just to clarify, i ran 'sudo guix system reconfigure' for the first time. and i did reboot, su to superuser, and 'echo $PATH' shows me that /root/.config/guix/current is not in the $PATH
<coco>probably the better way to reconfigure is with "sudo -E guix system reconfigure ..." to use the user's environment variables?
<vagrantc>coco: i always use "sudo -E guix system reconfigure ..." and never log in as root
<talope>Hi there, how should I modify script shebangs like #!/bin/bash by hand to be runnable on Guix? I'm seeing a lot of procedures for packaging but I don't want to package this (skulls/coreboot scripts), and i'm a bit at a loss to find a solution apart from explicitly running the script from bash on the commandline.
<coco>vagrantc: yeah, i didn't log in as root to run reconfigure, but used sudo (which apparently changes the environment variables)
<ScaredySquirrel>vagrantc: ok there it goes
<coco>makes sense to do everything with 'sudo -E ...'
<coco>or at least the 'guix system' part
<coco>changed /etc/profile as suggested in the terminal output, but will use sudo -E from now
*vagrantc needs to switch hats for a while
*vagrantc waves
<bavier>talope: you can create a /bin/bash on your system in the system configuration
***namtsui_ is now known as namtsui
<snape>talope: see https://guix.gnu.org/manual/en/html_node/Base-Services.html#index-special_002dfiles_002dservice_002dtype
<talope>bavier: with special-files-service-type
<talope>snape: ok, thanks
<snape>np!
<kirisime>My Geary package builds now but it can't connect to any email server and when gnome-settings is lauched by it all the icons are missing.
<jonsger>oh kirisime nice progress
<jonsger>kirisime: can you share your patch?
<kirisime>jonsger: For now all my packages live in my own little local channel.
<kirisime>And, well, my emacs mail setup broke recently which is the first reason I wanted a different mail client...
<jonsger>kirisime: you can show a link to your git repo or upload to some textbin
<kirisime>jonsger: https://pastebin.com/HBEcGZib
<kirisime>Warning: doesn't actually work
<jonsger>kirisime: pkg-config and cmake are native-inputs
<kirisime>jonsger: Right, I was just pouring everything the configure script complained about into inputs.
<leoprikler>kirisime: do you use evolution-data-server?
<kirisime>leoprikler: It's running in the background as so far I haven't figured out a way to remove it. Should it be a dependency?
<leoprikler>it is a dependency of evolution afaik and I find it hard to believe that geary would not rely on it
<leoprikler>although to really make it work with evolution, data-server needs to be installed system-wide
<leoprikler>I'm testing your geary recipe and see if it works with my current config
<kirisime>It's not mentioned anywhere, maybe it expects to find it running only when the user is running GNOME.
<leoprikler>ah, no, I think it accesses it through folks
<leoprikler>well, that also clears up the dependency thing, since folks already depends on data-server
<kirisime>So, do you have a clue for why my geary can't connect to mail servers?
<kirisime>Also is it supposed to die when you cancel the account creation?
<leoprikler>I'm still building it, so I can't say for sure yet. The mail thing may be a "feature".
<leoprikler>(You can't really r/w mail without having an account.)
<leoprikler>okay, GOA seems to work
<leoprikler>but EDS does not
<leoprikler>but I did succeed in adding my own mail address
<leoprikler>In other word, your package seems fine, the environment is not
<jonsger>kirisime: yeah mail setup with web.de over IMAP works for me :)
<kirisime>leoprikler: Is there a potential difference between just running the thing from the store directly versus having it in your profile?
<leoprikler>I ran it from store
<kirisime>Maybe it's something about my mail server then.
<jonsger>kirisime: yes. I run it from my profile
<jonsger>kirisime: I had to set the smtp server manually
<leoprikler>What would happen if you were to run evolution?
<kirisime>leoprikler: Evolution seems to work yes.