<kete>Does something like console-keymap-service need a root reconfigure or a regular user system build? <brendyn>/gnu/store/ykzwykkvr2c80rw4l1qh3mvfdkl7jibi-bash-4.3.42/bin/sh: /bin/sh: No such file or directory <brendyn>I get this error during tests despite it existing <kete>I ran as root and it appears to be updating packages. <kete>It doesn't help the login or typing password for /home partition. It only works on the *consoles* which is what I hoped would not be the limit. I remember configuring login managers through their settings, so I'll look for those. <ng0>yes. because that's the sad limitation of slim (the login manager we currently have) <kete>ng0, I don't think it's sad. that's how login managers work. in kde, I used to configure kdm through kde settings. <kete>gnome doesn't have a log out option. <brendyn>I tnink KDE recommends a different login manager now <kete>yeah, I used that briefly, didn't like kde <darkpsi>hey guys i am trying to configure guix to not use xlockmore and remove it from %base-packages how ever despite multiple attempts, guix still trys to download and install the package <ng0>no i mean slim does not have that option at all <kete>to log out of gnome, run gnome-session-quit <kete>I didn't think guixsd came with an xlock, so I installed slock. <lfam>kete: I believe the GNOME logout button is hidden on "single user" systems. IIRC there is some configuration option you can set to enable it <ng0>it might not be correct, if you find this config setting, let us know.. <darkpsi>any ideas on how to delete package from %base-packages both destructive delete and standard delete have given me no luck and i dont know why <darkpsi>yeah i tried all of them delete delq delv and also delete! delq! delv! <OrangeShark>darkpsi: I don't think xlockmore is in %base-packages <brendyn>OrangeShark: Why does %desktop-services have it's list with arguments in parentheses but %base-packages doesn't? <brendyn>So I still don't know how to do guix from source. Like when I press M-. on a symbold it takes me to a file in /gnu/store instead of the file in the git repo <darkpsi>@OrangeShark xlockmore is in xdisorg ***tschwing_ is now known as tschwinge
***lumidify_ is now known as lumidify
<rekado>I finally managed to init GuixSD on my LVM (on LUKS) by mounting /dev/sda1 (the boot partition) on /mnt/boot (the LV is mounted at /mnt). <rekado>Without this step grub-install will always fail. <jmd>ACTION changes his nick to "Guix" <jmd>What is the consensus about the git vs. cgit issue? <civodul>jmd: there seemed to be a cgit patch upstream no? <jmd>Do we want to mess around with upstream patches? <jmd>I thought we had a policy of only using released versions. <efraim>we try to cherry-pick upstream patches if it fixes something (not building, CVEs, etc) <efraim>but generally package only releases <jmd>But in this instance would it not be cleaner to have two versions of git, untell the downstream projects catch up? <jmd>- after all, that's the beauty of Guix! You can have more than one version of something concurrently! <efraim>that would make more sense and generally be easier <efraim>we have a couple of packages where we also keep around and older copy <lfam>Whatever we do, someone should keep an eye on cgit for a new release so we can remove our workaround <civodul>if the upstream cgit patch is small enough, i'd go for it <civodul>if it's not, we can add a git-2.9 and use it in cgit <jmd>It's not the size, that concerns me. Its the uncertainty it introduces. Also somebody said there was possibly another package which had broken due to git 2.10.0 <jmd>ok. I'll do that tonight, if nobody gets there first. <efraim>so far the libvpx update hasn't broken anything in the packages i've test built (but haven't opened) <snape>hi, I just did the mb2md patch, and would appreciate a review :) <snape>Im not sure about the way I handled perl-timedate <jmd>Presumably, we cannot allow circular dependencies between packages? <efraim>true circular dependencies cause stack overflows and it will fail to build <efraim>but you can depend on an alternate version that doesn't depend on that package, for example python-pbr <jmd>Or I'll have to split a package. <civodul>efraim: yes, i think it's ok to remove/upgrade in one go, because it's one logical change <efraim>if I delete files generated by cython, that should be in a snippet, right? <jmd>*** #guile: topic set by civodul!~user@unaffiliated/civodul, 2016-04-18 <jmd>*** citypw (~citypw@li1464-92.members.linode.com) has quit: Quit: Leaving <jmd>*** ruste (ruste@gateway/shell/anapnea.net/x-jaqoyhugeyqhnwcs) has quit: Ping <jmd> timeout: 244 seconds [12:07] <kete`>sneek: later tell lfam: thanks for those Gnome logout button instructions <jmd>kete`: You also had problems logging out of Gnome? <ZombieChicken>Has anyone gotten the Guix package manager to work with Racket? <rekado>do you mean to install the "racket" package or to run Guix but replacing Guile with Racket? <rekado>this doesn't seem like something someone here would have done, because Guile works just fine to run Guix. <darkpsi>i can not get rid of this package still xlockmore i need to get rid of it as the site that host the source is down and it stops my installing process because of it <rekado>darkpsi: are you using binary substitutes? In that case the fact that the upstream site is down should not matter. <rekado>I see that hydra hosts a binary substitute for xlockmore <rekado>/gnu/store/d6sxi3yis5mzik6z0qm0b1pxa3x4rrpg-xlockmore-5.47 <darkpsi>@rekado oh i am compiling from source how do i say just download this one package in binary forum? <rekado>darkpsi: are you using the latest version of Guix? <rekado>downloading binaries is configured to be the default <darkpsi>ok i will go and download that now and then use that installer and i will report back if i still have any problems thx <rekado>are you trying to install GuixSD? <rekado>once you have GuixSD installed you can easily upgrade to later versions. <rekado>if you are still trying to get GuixSD installed I recommend using the latest release. <darkpsi>yeah i am downloading the guixsd 0.11 will take some time as my connection is not great.about 20 mins <kete`>sneek: later tell jmd: Yes, Gnome doesn't provide a logout button, but I found out how to log out by running gnome-session-quit. lfam also showed me https://bugs.gnu.org/23193 to make a logout button appear. <brendyn>darkpsi: Sorry we couldn't help you sooner. Feel free to keep posting your progress into this channel in case someone knows how to help you <kalashkash>someone knows why when you becomes root with "su" command, then as root user, you can't excecute any command <snape>because the PATH is not the same <ng0>even the shorter convention of this made it fail.. <kalashkash>snape: then, how do you excecute any command with other user in terminal? <ng0>while python3 variant builds. <ng0>if only kallithea would use python3... <snape>kalashkash: you should add $HOME/.guix-profile/bin to the user's PATH <snape>you can source .guix-profile/etc/profile <snape>otherwise you have to manually update your PATH variable <snape>your user must have a $HOME/.guix-profile <civodul>on GuixSD this file is automatically sourced <civodul>so it's only on other distros that something needs to be done <snape>actually I did not read well the doc <snape>so I guess non guixSD can source .guix-profile/etc/profile, but this might break some stuff of their distro <ng0>which is 404 upstream <ng0>python has like a million extensions... i hope this one is what's missing <rekado>snape: at work we do this all the time. Host distros are CentOS and various Ubuntus. <rekado>we didn't have any host distro programs break because of that. <snape>rekado: I did have issues with C_INCLUDE_PATH <snape>my compiler was looking for things there first <snape>I did not know how no fix it <ng0>hm... if i need to insert a new commit before a commit I did, do I use interactive rebase? I imagine select commit before my commit to edit, commit that change, do some change git add + git commit, git rebase continue? <snape>or maybe it was LIBRARY_PATH <ng0>oh great... i've run into a python module which needs something which inreturn needs something which is some replacement for setuptools... urghhh <ng0>well upstream is still existing. here I thought python based would be easier than haskell based applications. just more to package. <snape>btw, I came across GNU Taler article in The Guardian <ng0>christian linked it some days ago on the taler? gnunet? mailinglist. <ng0>it's not their problem, but it's their dependency graph.. <ng0>well not directly: kallithea < dulwich < geventhttpclient < public < setupfiles <rekado>snape: I usually tell users here to use "guix environment" if they want to use compilers. <rekado>this way they won't pollute their regular environments. <rekado>(they are not full-time developers, so they don't need to have a compiler toolchain in their profiles at all times) <snape>well, I do need a compiler toolchain in my profile at all times :) <rekado>(In my opinion we should hide the "gcc" packages in the UI.) <civodul>rekado: why not; we could easily hide it, with 'hidden-package' <snape>rekado: in my case, I have to use a very specific ARM toolchain <ng0>okay, we can package it. this license issue exists when you build dulwich with tests enabled. I'll comment it and inform upstream about it.. first kallithea a d if they refer me to dulwich i'll report it there etc <rekado>snape: is the ARM toolchain in Guix? <rekado>I packaged an ARM toolchain for Guix, but I haven't yet found the time to submit it <rekado>no space on my disk to rebuild it all, so I'm working on installing GuixSD on my LUKS LVM ... <rekado>I'm using the ARM toolchain with Axoloti. <snape>we use arm-none-linux-gnueabi-gcc <snape>there is something similar packaged <rekado>yes, that's the one I'm using too. <rekado>I packaged a particular version, not the latest, though. <snape>I'll try that, thanks for the tip! <rekado>well, it's not in Guix upstream. The original patches are in the mailing list archives. <civodul>snape: if you run "guix build --target=arm-linux-gnueabi something", it will automatically try to build the toolchain for that triplet <civodul>however, this is not a triplet we test (we test ...-gnueabihf), so maybe it won't build <civodul>did you know that 97% of our packages use 'url-fetch'? <joshuaBPMan_>hello, I am dual booting guixSD and Parabola. For about a week guixSD was working stellarly. I was running gnome just fine. Then a week ago or so, I could no longer properly log into gnome or any other desktop environment or window manager <joshuaBPMan_>I am getting seeing this error in X's logs when I try to log into gnome on guixSD <joshuaBPMan_>libinput bug: bcm5974: Internal or external? Please file a bug. <joshuaBPMan_>I believe that my Parabola install is using libinput too, so I'm not sure what the issue is. <joshuaBPMan_>I've also tried booting guixSD into the older configurations, but I'm still not able to log in. <rekado>are your GuixSD and Parabola installations share the same root file system? <rekado>if not GuixSD should not change at all until you "guix system reconfigure" it. <joshuaBPMan_>I've run guix pull; sudo guix pull; guix system reconfigure /ect/config.scm several times, <joshuaBPMan_>but no change. Since I knew that Arch uses libinput, I've replaced guix's X config file "60-libinput.conf" with arch's. since I knew my arch install was working. <twotwenty>hello how would I add ssh as a system service <snape>well, do you specifically need open-ssh? <snape>there is already lsh packaged <twotwenty>I just need to be able to secure shell v2 into my guix sd box so I can stop sitting at the physical computer <snape>(lsh-service) will do, in the (services... field of your config.scm <snape>there are examples in the doc <twotwenty>and once I make the change how to I rebuild the system <snape>guix system reconfigure config.scm <twotwenty>snape: thankyou :) I will be able to sit in a chair again . <ng0>for one, i am too used to look at the source and not at pypi, so i did not see the missing license part which are stated in pypi. for the rest I really don't know at the moment where this setuptools extension bug comes from <darkpsi>i am setting guix up with full disk encryption and so i have put "/dev/mapper/root" as the device and the type as ext4 but it keeps saying at the grub installation stage 'lvm/root' not found despite my system not using lvm and lvm not being referred to in the config <sankey1>is there a good way to determine which substitute keys are already authorized? <mark_weaver>see the description of 'guix archive --authorize' in section 3.7 (Invoking 'guix archive') in the Guix manual. <wingo>mark_weaver: what is with that format? the (e #010001#) stuff is pretty weird :) <mark_weaver>wingo: your question is answered in the doc reference I just gave :) <mark_weaver>iirc, it's a format that either libgcrypt or GnuTLS uses <wingo>lol when i chided someone today for not reading the manual on guile ;) <mark_weaver>indeed, although I personally sympathized with your chiding in that case <wingo>ACTION will try to do better about reading the manual :) <wingo>maybe we can get gnutls to adopt the standard scheme format for their stuffs, it looks like it wouldn't be a problem <wingo>#x instead of #...#, where ... is a hex digit i guess <wingo>Digit: apologies for casting a spell your way! <mark_weaver>apparently the existing format is somewhat standardized. from where we sit, switching to scheme format would be nice, but I'm not sure non-lispers would agree. <Digit>wingo: no worries. i delight in those nickpings i get unintended. they're surprisingly rare. <OriansJ>I'm more of a fan of the 0x.... format for hex values <OriansJ>But as per the standard, whoever does the work gets to decide. <ksjogo>For some reason I have the same list of following derivations will be built on each guix package command for my user. Is there anyway to actually build them? I tried -u but that did not help. <jmd>ksjogo: Probably, they are already built. <janneke>how do you folks all go without /usr/bin/env? <janneke>i have a very hard time working with other projects, running from sourc tree without that <janneke>python, node, perl, bash, tcl -- yeah <ksjogo>The following derivations will be built: <ksjogo> /gnu/store/3932kw9wp33jxdybsd88riq1w8a5fqr5-profile.drv <ksjogo> /gnu/store/psvnjp8cjbyz9d4jpkhy8razcddvbnzd-xdg-mime-database.drv <ksjogo> /gnu/store/jrxnkzisnv7vnm9fv6ivnmhixp2p1lc8-gtk-icon-themes.drv <ksjogo> /gnu/store/ayzpdn9ak6p4zq0w0hn2x59ml2wmsd4b-info-dir.drv <ksjogo> /gnu/store/84zy8ky510rx8p5564vif6qdzjli1j09-ca-certificate-bundle.drv <ksjogo> /gnu/store/6y7pnmd7nyc4ymd44dc5mj0ar6yjdsgd-fonts-dir.drv <jmd>ksjogo: I don't think I understood your original question. <wingo>ksjogo: i think those derivations are derived in some way, built from the precise set of packages you have installed <wingo>so whenever your packages change, you have to rebuild your fonts, the info cache, and so on <wingo>but i wish that for those guix didn't ask for substitutes :) <mark_weaver>e.g. the fonts-dir one creates a directory of fonts that contains the union of all fonts in your profile. <mark_weaver>the others are similar, usually creating some single file that combines information from the set of packages in your profile <ksjogo>Ah, ok. But why are they rebuilt when I change an unrelated package? Are they just 'compiling' a dir of operations? <mark_weaver>info-dir creates the ${profile}/share/info/dir file, which contains a line for every info manual found in your profile. <wingo>janneke: some people mount their profile to /usr in a container :) <jmd>ksjogo: I expect they are related somehow. <sankey1>if /etc/guix/acl is just a sexp, can't i just use the scheme read function? what's meant by the following error? <sankey1># guile -c '(write (read))' </etc/guix/acl <sankey1>ERROR: #<unknown port>:5:20: invalid array tag, starting with: DB1634E3 <mark_weaver>ksjogo: those derivations take your profile manifest as an input, and the manifest is a list of all the packages in your profile. <janneke>wingo: yeah...if simply do mkdir -p /usr/bin ;ln /run/current-system/bin/env /usr/bin/env ... but that breaks on every new guixsd where I forget to do that :-( <civodul>sankey1: unfortunately no: it's a "canonical sexp", which is different from the Guile/Scheme syntax <mark_weaver>so, when the manifest changes, it's a new derivation that needs to be rebuilt. it doesn't know which packages are relevant, a priori. <civodul>sankey1: the (guix pk-crypto) module provides tools to read it <ksjogo>Another thing: Is it possible to let guix system reconfigure generate the grub.cfg but not run the grub-install? I have a grub installed by Ubuntu and just added a link to the guix grub.cfg. At the moment I just changed the install.scm, but that is not that nice. <mark_weaver>janneke: also, if you create a /usr/bin/env on your system, then there's a good chance that at some point, you'll contribute to guix a package that works for you and fails for others. <mark_weaver>personally, I rewrite the shebangs to refer to things directly in /run/current-system/profile/bin/* <janneke>so that's why i ask: any of you here contribute to upstream source projects that just need /usr/bin/env? <mark_weaver>but it may be that the set of projects I work on is such that this is not a big problem for me, but maybe is for others <wingo>janneke: chromium uses /usr/bin/echo in only a couple of places. otherwise it is free of /usr/bin/env. <wingo>so i end up not running into it in my practice. <janneke>wingo: and you use the container trick for /usr/bin/echo? <lfam>ng0: Did you figure out the issue with python2-geventhttpclient? <sneek>Welcome back lfam, you have 1 message. <sneek>lfam, kete` says: thanks for those Gnome logout button instructions <wingo>given all the FHS incompat with upstream projects i expect to use the container trick in the future <wingo>janneke: i actually edit those two files <lfam>ng0: If not, the issue is that python-geventhttpclient needs a (properties) field <lfam>ng0: Otherwise, the python2-variant of the package is not used <wingo>the nice thing about guix is that you know that even if your build decides to download a binary, it won't work :) <janneke>wingo: i just found a test that creates a file with: #!/usr/bin/env node <janneke>so now i need a workaround that works for `guix build'...probably insert 'interpreter' + file ... ugh <rekado>do you also get an error when running ‘man’? <rekado>man: can't execute iconv: No such file or directory <rekado>(for some man pages, e.g. ‘man borg’) <rekado>I think the path to iconv needs to be patched in. <wingo>janneke: well for things built by guix obviously you need to subst :) <wingo>there is the phase to subst /usr/bin shebangs <wingo>but obvs you need to do something special for the generated test <janneke>wingo: yeah...insert a guix-specific subst into the test suite... ugh <wingo>not in the source package but in the guix definition <mark_weaver>janneke: (guix build utils) exports 'patch-shebang', which is used in some default phases like 'patch-source-shebangs' and 'patch-generated-file-shebangs' <janneke>wingo: yeah, guix definition just says: `make check' <mark_weaver>janneke: but you can call 'patch-shebang' manually if those phases don't get them all. <lfam>rekado: The borg man page does not work for you? <janneke>then test scripts are written with wrong #!. Hmm, maybe write those with correct interpreter paths ***tschwing_ is now known as tschwinge
<mark_weaver>janneke: in most cases, software installed by guix should refer to other software by absolute file name directly into /gnu/store, rather than searching for programs in PATH, so /usr/bin/env doesn't do what we need. <janneke>mark_weaver: sure, i appreciate that <mark_weaver>relying on software that happens to be in your PATH works against our goal of making sure that if a program works today, it will work tomorrow. <jmd>mark_weaver: Well here's a problem that I shall be facing very soon: <jmd>/bin/mount calls /bin/mount.nfs (if you pass -t nfs) but /bin/mount.nfs calls /bin/mount <ng0>one upstream application i submitted and got a change from /usr/bin/env to /usr/bin/defaultbinary will soon revert that commit again.. not so easy to make people understand <jmd>How should we deal with that one? <rekado>lfam: yes, the borg man page is one that doesn’t work for me. <rekado>there are others, but I don’t remember them. <lfam>rekado: I just tested and it works for me on GuixSD and a foreign distro <lfam>Hm, I use `man` from the CLI <lfam>Can you check if at least that works for you? <rekado>what I meant is: it works with M-x woman, but does not with plain ‘man borg’ on the command line. <lfam>It's not in my PATH on GuixSD. On Debian, it comes from Debian <rekado>it’s been like this for a few months <lfam>Hm, I wish I'd known. I care about this package :) <lfam>I see that Efraim did some work on the Borg package. Thank you Efraim :) <rekado>it’s a problem in ‘man’, not ’borg’. <lfam>Right, but I still care. The documentation should work <efraim>I read about the attic bug and decided to switch <lfam>Right now, the man page for vdirsyncer is not generated due to an issue with our old version of Sphinx <lfam>Another thing that bothers me <efraim>then I saw the cython-something in the download <rekado>lfam: do you happen to know if the full documentation can be built, too? <lfam>efraim: I did not realize there were generated files <rekado>the man page has a very different format from the HTML docs. <mark_weaver>jmd: there are two ways we could handle that: (1) we could search for mount.nfs in PATH in that case, or (2) make the package containing mount.nfs an input to util-linux, and the mount-nfs package would take as input a modified 'util-linux' package that removes the nfs package from its inputs. <efraim>i should search through python.scm, i'm sure there are more that we haven't noticed before <mark_weaver>we use approach (2) to handle the circular dependency between cairo and poppler. <lfam>rekado: I don't know. I haven't tried to build any documentation beyond what the package does now <mark_weaver>jmd: see the "cairo" input to poppler in gnu/packages/pdf.scm line 83 <jmd>mark_weaver: I thought about both of those. (1) for reasons you just mentioned, is undesireable. (2) would work, But how would guix package -i know which util-linux to install? <mark_weaver>jmd: the decision really depends on how much bigger this would make the closure of 'util-linux'. <mark_weaver>jmd: "guix package -i" only sees packages that are bound to exported variables in gnu/packages/*.scm, and we would arrange for it to not see the 'util-linux' package without nfs. <lfam>rekado: For borg, the 'docs/Makefile' has several targets including 'html', 'dirhtml', and 'singlehtml'. No 'info' target. <ng0>I award pybitmessage the sillyhat of the month. no change to a qt5 because of windows xp <efraim>I know quassel can be built with either qt4 or qt5 <jmd>mark_weaver: But then, people will be forced to install nfs-utils whether they want it or not. <mark_weaver>jmd: e.g. the way it was done for poppler and cairo, the cairo input to poppler is not bound to any variable at all. <lfam>ng0: That *is* silly. qt-4 is not maintained by the Qt project, so as bugs are discovered, users will probably be hacked through the old Qt <mark_weaver>jmd: indeed, and that might not be desireable, depending on how big it is. <jmd>mark_weaver: nfs-utils is actually very small - in fact guix lint warns about it. <ng0>I'll probably just package another bitmessage client <lfam>ng0: It's not a reason to not package pybitmessage. As civodul said on guix-devel, all the packages have bugs ;) <lfam>We can only fix the bugs that we know about <jmd>mark_weaver: But, in fact, the same problem exists with mount.fuse <mark_weaver>jmd: if adding 'nfs-utils' doesn't increase the closure size of 'util-linux' by much, then it's probably fine. <rekado>lfam: this works: LANG=iso-8859-1 man borg <rekado>it’s the conversion to en_US.UTF-8 that fails. <mark_weaver>jmd: it's possible that this is a case where we should be looking in PATH, dunno. <ng0>yeah... i know. i won't fix that one. I've tried to contribute and I don't want to. there have been discussions outside of logged/public history which make me question decisions peter surda decides on... <jmd>Yeah, I'm not sure either. That's why I haven't made a decision yet. And there are more serious blockers too. <ng0>i mean i own't contribute to upstream <mark_weaver>jmd: but if we can add the necessary dependencies from fuse and nfs-utils without much increase in closure size, then maybe we can avoid searching PATH <rekado>ng0: is pybitmessage the only implementation of bitmessage? <rekado>ng0: if there’s a better implementation … maybe pybitmessage isn’t worth all the trouble. <ng0>I have not looked at others so far.. you don't even need the pyqt part as it also has an headless daemon (i never used). <rekado>ng0: BTW: I haven’t found any time to look at your Haskell patches yet :-/ <rekado>these weeks I’m facing a deadline and my time at home is very restricted <lfam>So many pending patches right now... <rekado>I’m even getting Guix patches from my colleague now :) <ng0>no problem, it's okay. I know you'll do it at some point :) <rekado>currently, they are practising this whole email-based workflow by sending patches for our custom Guix repo. Eventually, I’ll upstream the packages. <ng0>I'm looking to update ghc to 8.0.1, ran into problems there too.. packging darcs was my first contact with haskell i think. it's on my gitlab mirror archive, or should be, if someone is interested in the wip <ng0>I'll also update the ghc darcs patchset one more time as i discovered that i packaged something which is part of ghc itself. I'd be interested in what the expectation of ghc/haskell users is.. multiple versions available, 7+8? or just one version? <rekado>Haskellers usually upgrade immediately, but whether it makes sense to keep older versions around depends entirely on compatibility. <efraim>we build gst-plugins-base without opus support <jmd>efraim: I'm pretty sure it used to be there. <efraim>we must've lost it somewhere along the way <jmd>or perhaps its in one of the good/bad/ugly variants. <ng0>I've read some 8 issues for 7 modules/packages, but i think what I suggested at first applies then: update and let the build run on a special branch on hydra <ng0>i mean some packages are not yet ghc 8 compatbile <efraim>well, i can mess around with that later <mark_weaver>it's not good that we use the suffix "/fixed" in package variable names for two very different purposes: (1) for packages that have had some fix applied, e.g. security fixes, and (2) for packages that are keep unchanged. <mark_weaver>I'm currently working on security updates for flex, and have need for both of these categories. if I follow our conventions, it's going to be very confusing. <mark_weaver>it turns out that most packages that use 'flex' can be updated without many rebuilds, so I want to create a 'flex/fixed' that *doesn't* have the security update, which will be used by the few packages that need flex and would force too many rebuilds. <lfam>What do you think we should call packages that have security updates applied? <mark_weaver>but then I also want, in the same patch, to create replacements for packages that use 'flex/fixed', to graft in variants that use the updated 'flex'. <mark_weaver>so, I'll end up with packages like 'linux-pam/fixed' that distinguish themselves by using 'flex' instead of 'flex/fixed' (the unfixed one :) <lfam>PS I'm glad you are looking at this issue. I was going to resurrect the flex thread today <lfam>Some other arborist metaphor? <mark_weaver>I'm actually leaning toward using /fixed for security-fixed packages, and coming up with a different name for the other case, maybe /unchanged or something <lfam>Another bikeshed to paint <jmd>"pinned" is what debian uses isn't it? <lfam>Can't we just use vinyl siding on the bikeshed? You never need to paint that stuff <lfam>"No, cedar siding is more sustainable" ;) <mark_weaver>heh, yeah, maybe guix-devel gets enough traffic without adding another bike shed argument to it :) <ng0>don't worry, i'll just distract the painting with a new version of 50 patches series ;D <mark_weaver>if upstream 'flex' produces a new release with the fix, then it would save me from thinking about this :) <mark_weaver>then I would just use the flex-<version> naming convention instead <lfam>ng0: I just skimmed your series. Most of the patches look very "standard", so as long as they build, we'd only need to double-check the licenses and the text in the synopsis and descriptions <lfam>And make sure they are the latest upstream version <ng0>it was mostly a standard import.. i need to puzzle on darcs as i do not understand enough haskell yet to see why it fails <ng0>thanks for looking at it :) <lfam>Frankly, I'm not convinced we need a bikeshed. I think we need a robotic bike storage facility <ng0>i need to beat this going back and forth between wip's.. if I am convinced that a service works, but I can't test it *fully* because the VM I use for testing is readonly, is a 99% 'it works' enough for sending it in for QA review? <mark_weaver>ng0: can you try using the service on your bare-metal machine? <mark_weaver>how can you be convinced that a service works if you haven't tested it? <lfam>Or you could test in a read / write VM <mark_weaver>Testing a service on a completely read-only system does not lead to 99% confidence that it will work properly. <ng0>being exposed to and working with the software for a rather long time.. I am convinced that it works in theory, I know what I need to fix and what needs to be applied. I have tested it, but the real test requires write access to receive a file. i can not test on bare-metal because I have not set up my guixsd systems like that <mark_weaver>many of the most common potential problems with services would only show up when the service tries to write something. <ng0>my 99% can also be seen as the 80% where you work on the last 20% for a long time... I'm 99% finished with gnunet suite on gentoo for a long time now. I'll never say 100%. <mark_weaver>e.g. sometimes software is built without --localstatedir=/var, or for some other reason ends up trying to mutate data in /gnu/store/*, and so it can't write to the places it expects to be able save data to. testing on a read-only VM would not discover those common problems. <ng0>is there some guide to either a rw VM (I have tried changing the qemu and appending settings, nothing worked) or running a system from a checkout without damaging the core system? <lfam>ng0: You can use `guix system vm-image`. Once the VM is built, you need to copy it out of /gnu/store and change the permission to make it writeable <mark_weaver>ng0: I run all of my GuixSD systems from git checkouts. I can be relatively fearless about reconfiguring new systems that might or might not work, because I can always choose an older system from the GRUB menu. <ng0>doesn't work for me. building vm-image makes some part of my disk run out of space <lfam>ng0: You need to pass a larger value to `guix system vm-image --image-size`. The default image-size is probably too small <lfam>ng0: You can pass any large value you want. The VM will only use the space it needs, and it will grow as necessary. So, I pass something very big like --image-size=100G <civodul>$ GUIX_PACKAGE_PATH= ./pre-inst-env guix package -A |wc -l <civodul>getting close to the 4,000 package party! :-) <ng0>currently guixsd machine one is building things and machine 2 is what I need to work with, that's why I can't try and play around with new system settings.. will do once I get to guix-gnunet :) <lfam>civodul: I bet we pass 4000 in a day or so :) <mark_weaver>ng0: I'm not sure I understand. why can't you use one of those two machines to test services? <ng0>I'm currently building the writable image, with the size appended it works <brendyn>So I think I am too dumb to understand the manual. How can I make it so that I'm using guix package definitions from my git repo and things like M-. and C . b actually work? <mark_weaver>brendyn: my preferred approach is to make ~/.config/guix/latest a symlink to the top directory of the (built) git checkout. <brendyn>mark_weaver: Does that also work for using guix it's self from git? <brendyn>And do I need to build it from a different working directory? <brendyn>What I don't understand is that guile is supposed to be able to do development with REPL so there can be incremental changes but so far I've never figured out how to actually do that with guix, I just save files then run guix build to test changes <mark_weaver>brendyn: I'm not sure I understand your questions, but the normal 'guix' command will look for an updated version of guix in ~/.config/guix/latest and use that if it exists. that's the symlink that's updated by 'guix pull', so if you point that symlink to your git checkout, you should avoid using 'guix pull' in order to leave the symlink intact. <brendyn>Oh ok. Currently when I run M-. t takes me to a Scheme file in /gnu/store <mark_weaver>if you make that symlink, you won't need to prefix commands with ./pre-inst-env either <mark_weaver>brendyn: presumably M-. brings you to the definitions that are actually used by guix, and that will normally be something in /gnu/store <brendyn>So I should build to a directory, not use the git repo directly? <mark_weaver>I also make /root/.config/guix/latest a symlink to the same place, so that when I run 'guix system reconfigure' as root, it uses my git checkout also. <mark_weaver>brendyn: I set those symlinks directly to the git checkout. <mark_weaver>the only potential issue is that if your git checkout is in a bad state, then the 'guix' command may not work. <mark_weaver>but in practice, I don't find that to be a big problem. in the worst case, you could remove the symlink and run 'guix pull', but I haven't had to do that. <brendyn>Thanks, I'll try setting it up your way <mark_weaver>brendyn: also see the last bullet point in section 4.1 (Emacs initial setup) of the guix manual. <mark_weaver>starting with "If you did not install Guix at all and prefer a hacking way" <lfam>How can I make it refer to openssl-next's version instead <lfam>I assume the same thing will also happen below, in the remove-miscellany phase <civodul>well, that phase needs to be duplicated <lfam>Delete the phase and re-declare it? <civodul>(or it would have to be written differently) <lfam>Oh right, I forgot about replace :) <lfam>Well, the configure phase is already being replaced in this case <brendyn>lfam: civodul You know, we have to end up *maintainng* all this crap we are packaging. <lfam>Yup, I expect that of the people that submit packages <lfam>It doesn't always happen, but I do expect it :) <brendyn>I think it is better-than-nothing to just add stuff and leave it <lfam>Yeah, I think that having packages, even if they need some work, will attract more contributors <mark_weaver>civodul: once I tried to add an unconventional keyword to 'arguments', in the hopes that it would reach the phases, but I found that it doesn't work. too bad. <brendyn>I'd like to be able to subscribe to upstream email lists so I don't have to keep track of everything but sometimes that isn't available <lfam>brendyn: I have a real hodge-podge of upstream notification systems <mark_weaver>or at least I thought it was unfortunate. I think I wanted that for the kernel packages at some point, although I've forgotten why. maybe as a way to pass in desired kernel configuration options, or something <lfam>brendyn: Mailing lists for packages and security updates (debian-security-announce and oss-sec), GitHub tag feeds in my web browser, hang out in the upstream IRC channels <brendyn>I probably shouldn't be packaging anything where security matters. <lfam>brendyn: That's what peer review on guix-devel is for :) <brendyn>Actually, I started packaging an update to duplicity, so I may end up destroying some backups in the near future, Muahahaha <ng0>I just follow what I package in email/irc/websites/otherwise or am involved .. there are also security related mailing lists, but the main ones get so much traffic that I just follow via web browser for now <lfam>brendyn: BTW, it's not so far-fetched to say that security matters for *every* package. <brendyn>lfam: When should I add my name to the copyright notice on a file? <lfam>Code review and attention :) <lfam>brendyn: When you feel you've made a significant contribution. I basically never ask a submitter to remove a copyright line they have added. I'm sure there are some guidelines if there are disagreements about this. <brendyn>Yeah, it's just in practice, code in the wild is suprisingly friendly (unless it's a .exe file) <ng0>gentoo has a project which follows the main security announcement and cve lists... sometimes it helps <lfam>brendyn: That's what we _think_, but how can we know? <janneke>civodul: thanks for your elaborate guix hash suggestions...in the mean time i sent a slightly other patch using --exclude=FILE semantics <janneke>i'll remember your other remarks and we'll see tomorrow where this goes ;-) <brendyn>lfam: We would expect to observe our computers being compromised more often <lfam>brendyn: I doubt we'd notice in most cases <ng0>lfam: oss-sec? wow, that one receives so much mails I just selectively read it in web browser. or at least for me it's too much <lfam>ng0: Really? I only get a couple mails per day <janneke>i also like the --exclude-vcs bit, dunno :-) <ng0>than it was just my impression <civodul>janneke: it has the advantage of being short <lfam>brendyn: For example, the heartbleed bug in OpenSSL. <civodul>trying to "bisect" that gcc issue by hand... <lfam>brendyn: The Debian OpenSSL RNG fiasco <janneke>civodul: yes...=FILE has the advantage of being a bit more versatile ... not sure ;-) <brendyn>lfam: Yes, but do we expect anyone to have even used those bugs? <civodul>lfam: that's only 16 commits between 4.9.3 and 4.9.4 under gcc/config/arm <lfam>brendyn: My point of view is that we have seen the tip of the iceberg. <ng0>0days are being used and sold brendyn.. there are also bug hunters of all kinds, either interested in fixing and receiving payment or selling to the democracy destroyers of all kinds.. <brendyn>lfam: Yes, of security exploits that exist. But what are the chances that we've actually had our home directories scanned by some invasion looking for credit card details or something like that <lfam>brendyn: There is an endless stream of remote code execution bugs being disclosed as a result of cutting-edge fuzzing technology. <lfam>brendyn: Who knows? But I do bet that sysadmins and OS developers are targeted explicitly by several organizations at once, constantly <lfam>Also read about American Fuzzy Lop <brendyn>My VPS gets bombarded with ssh login attemps all the time <ng0>that's just automated most of the time <lfam>brendyn: Right, so what if there is a bug in postfix that allows remote code execution for some crafted login name? <lfam>The attacker doesn't even need to log in <ng0>China has a funny automated targeting program.. <lfam>That sort of stuff is being found *all the time* <ng0>switched ports after a while and they were gone <ng0>brendyn: welcome to the insecure new world :) <mark_weaver>almost every arithmetic operation or cast from one integer type to another can involve an overflow <brendyn>Is it too difficult to scan source code for such errors? <ng0>and yet bug bounty programs pay surpringsingly little sometimes <lfam>It requires executing the source code with an infinite number of different inputs. This is what fuzzers attempt <brendyn>Maybe bug bounties don't pay as much as the black market <lfam>Yeah, bug bounties are barely enough for a skilled programmer with no ethics <mark_weaver>there are tools to help find such bugs, but probably the bad guys have more advanced tools, and certainly more people working on it. <lfam>Orders of magnitude different rewards <ng0>there's the fine line between responsible disclosure and doing it profit and destruction <brendyn>I've seen Facebook bug bounties where they are like "Sorry, your remote code execution bug is only worth 2 cents" <lfam>I also think it's unreasonable to expect that all the private "early disclosure" mailing lists are not infiltrated by bad people. So, they are worse than immediate publication in my opinion <lfam>The whole thing is a disaster <brendyn>Linus Torvalds takes an more sane approach where he just weighs up security concerns against features and other demands. Not much else one can do <mark_weaver>I think we need to rewrite most of our security-critical code in languages that are less prone to such bugs. <ng0>mail is intercepted and saved globally, to send a disclose via unencrypted email is always almost disclosing to gchq & friends. <lfam>brendyn: In practice, we all do that <lfam>brendyn: Also, my understanding is that the Linux kernel team almost never publicizes security bugs. Every new release fixes critical bugs. <lfam>When they say things like "Users should upgrade", you better think twice about ignoring that advice <lfam>Bad people are studying the commit logs