<civodul>just took care of the PowerPC patches, thanks for the heads-up! <civodul>also started an evaluation of 'staging' <davexunit>lfam: I just saw that rust thing for librsvg <davexunit>I hate C and all but Rust is bad news bears for distros. <davexunit>I haven't used rust yet to know if it had the usual regressions of "modern" languages <davexunit>like conflating package management with the build system <adfeno>Oh the whole issue with varioust types of linking... Even I, a non-developer, start to lose my consciousness just by hearing it.... :) <lfam>It looks like you can choose to dynamically link libraries in Rust, based on the last few minutes of reading <davexunit>I should get a nice correction on HN for that :) <lfam>Well, those were my first 5 minutes of searching the web on this subject, I could be wrong :) <kyamashita>I found something about a "-C prefer-dynamic" option on Reddit. <lfam>Right, that's what I'm reading about <lfam>Well, the good news is that a lot of Guix hackers are working on Rust right now. So we should be able to update librsvg soon! <lfam>sneek: forget update librsvg <adfeno>Oh... Don't play tricks on us sneek :) <adfeno>Perhaps sneek was told to look for special words in the middle of any string, not in the begining. <adfeno>Testing this: update librsvg soon! <lfam>sneek: what is the good news <sneek>the good news is that a lot of Guix hackers are working on Rust right now. So we should be able to update librsvg soon! <lfam>sneek: forget the good news <lfam>sneek: what is the good news <lfam>The good news is that peanut butter and jelly sandwiches are delicious! <lfam>the good news is that peanut butter and jelly sandwiches are delicious! <lfam>I wonder how sneek originally decided to remember the good news? <adfeno>Hm.... sneek doesn't want to keep the good news. :) <lfam>sneek's not hungry. Too bad I have all these botsnacks! <adfeno>Perhaps because the message started with "Well, "? <lfam>Well, the good news is that it's not so important ;) <adfeno>Well, the good news is that this is only a test that has a period and an exclamation mark. Testing! <lfam>In a private chat, I can get sneek to respond to "remember ..." and "forget ..." but I can't figure out how recall the remembered thing <adfeno>Some software bugs can be quite funny indeed... It would be funny to see a person shouting (using our phrases) to a computer in order to see if the machine replies. ***RISCi_AT1M is now known as RISCi_ATOM
<rekado_>well, the good news is that peanut butter and jelly sandwiches are delicious <rekado_>sneek: well, the good news is that peanut butter and jelly sandwiches are delicious <rekado_>sneek: well, the good news is that peanut butter and jelly sandwiches are <sneek>I've heard the good news is that peanut butter and jelly sandwiches are delicious! ***kelsoo1 is now known as kelsoo
<ng0>If some appliaction in its name has an underscore, do we keep it? <ng0>or do we rewrite to "-" <ng0>I know that version strings are rewirtten <jmd>I think that is mentioned in HACKING <jmd>My recollection is we should change it to a hyphen. <ng0>it's not mentioned there anymore, maybe in doc section commiting <ng0>I think I hda a case like thise before... sounds right <ng0>hrm... I feel bad about mirroring this software. I should contact the admin of the domain <jmd>ng0: It's in the Guix manual in the section entitled "Package Naming" <ng0>seems like my emacs with some version change started to break indentation in scheme files <ng0>is the dwtfyw license equal to public domain? <ng0>sneek: forget if someone is interested in it, I've added some 2f30 (suckless following community) software here: https://pagure.io/packages/commits/ . I'll make them available as patches to master soon. <ng0>I especially like xbattmon <adfeno>How to know which revision of a specific Guix recipe/package declaration was used to provide a specific build substitute? <adfeno>Although I'm not a player myself, I'm investigating a bug on Red Eclipse in which it always doubles the inputs of movement keys (thus making the character go where it isn't supposed to)... <davexunit>adfeno: I've experienced this problem with a program that uses SDL on an Ubuntu machine <adfeno>... And I just want to be sure that the build that came from a Guix repository really used the current recipe. <davexunit>adfeno: in that case you can just compare the hashes <davexunit>'guix build red-eclipse' will exit immediately with the store directory if it's already been built <adfeno>davexunit: Also, regarding the bug, it might be related, although SDL 2.0.0 appears to be normal. <davexunit>sdl2 is where I had the trouble, but I haven't had it on other machines so I'm not blaming guix currently <davexunit>adfeno: so you have a /gnu/store/...-red-eclipse directory right now, right? <adfeno>Our current recipe provides version 2.0.5 of SDL 2. <davexunit>if guix starts building or downloading, then it's not the same <davexunit>if it exits quickly with the same store directory, then it's the same <adfeno>Actually, to summarize: SDL2 2.0.2 (from Trisquel 7's repositories) doesn't have the bug. SDL2 2.0.5 (from Guix recipe) has the input bug. This message was also sent to #redeclipse <davexunit>the redeclipse maintainers are just going to get mad at us if you're not careful <adfeno>I'll see if I can look for related issues in the SDL project's support resources. <davexunit>I use sdl2 all the time on my laptop and have no issues <adfeno>No, I'm using Guix on top of Trisquel. <adfeno>I made a quick search, and found similar issues... <adfeno>Apparently, sdl2 might need to be build with ibus support. <davexunit>I am on the machine that I can test the fix on <adfeno>I'm also in the machine to test such fix, just give me the archive for testing and tell me how to install it, and I'll help out. <adfeno>Although, I must be away from keyboard 1h from now due to lunch time (it's past 14:00 here). <lfam>The gawk test suite is unreliable :/ <davexunit>lfam: could you revert that patch you just pushed? <davexunit>I'm currently downloading bootstrap binaries <adfeno>davexunit: Thanks... I'll do `guix pull; guix package -u`. <lfam>davexunit: Done! `guix refresh -l` let me down this time... <lfam>It wasn't technically "broken", just very inconvenient ;) <lfam>Hm, there are some tricky conflicts between master and core-updates <davexunit>in doing this bug fix I discovered that SDL2 has an optional dependency on fcitx for foreign language text input. <adfeno>This is what I like about free/libre software: No matter how skilled (or "unskilled" in my case) one is, there's always someting to learn <adfeno>davexunit: Should I wait for you to enable that? <davexunit>I'm just doing some extra stuff while I'm in here <davexunit>the bug fix patch has been pushed so please test. <ng0>I'd like to extend search-patch to include "patches" directory inside GUIX_PACKAGE_PATH . I'm rewriting the packages.scm for myself to include this feature, but I think this is not so uncommon to include patches in your package path <ng0>;; .... allowing patches in $GUIX_PACKAGE_PATH to be found. <ng0>I must be doing something wrong <lfam>I wonder if any of our packages bundle libvnc, for which there is a security update today <ng0>(patches (search-patches "st-scrollback-0.7.diff")) ...or even .diff is not found, in patches directory of the path and also in the packages directory <davexunit>lfam: it would be nice to have a tool that would download *all* of the source code and search it for things <davexunit>it would be expensive to get all the source, but we could search for the string "libvnc" and find out if anything was bundling <lfam>davexunit: Yeah, I'd like to have a way to acquire all the source code, if only to host a substitutes mirror that only served source code <lfam>The source code is a big weak spot in building old versions of Guix <lfam>It wouldn't help with source code that expires (this does happen! :/) but it would help with code that disappears from the net <lfam>Yes, SWH will help, but for now... <davexunit>there's no CLI for this but it's actually quite easy to download all the source code <lfam>Also, I'm wary of only matching source code based on the hash, which is what I think SWH will provide. We have to also match on the file name somehow <davexunit>use fold-packages to iterate each package, call package-source to get the origin record, then build them all <lfam>Otherwise we are vulnerable to some nasty attacks <davexunit>we'd still verify that the contents have the expected hash <davexunit>so someone would still have to break the hashing method and take advantage of a hash collision to attack us <lfam>I'm saying that it's dangerous to only match on the hash. Consider a package update to OpenSSL that re-uses an old hash instead of the correct new one. <rekado_>is anyone here working on packaging neovim? <rekado_>I have an unconverted user here who wants to use it <lfam>If the old source code has been garbage collected from hydra, but not the Nix content-addressed mirror, won't the "new" openssl be built using the old source code? <lfam>This scenario also requires the OpenSSL site to not serve the source code <davexunit>no matter where we download it from, if the hash doesn't match the hash field of the origin record guix will refuse to use it. <lfam>I'm not talking about breaking SHA256 <lfam>I'm talking about pushing a package update to OpenSSL that uses the hash of some old OpenSSL release. <lfam>I believe I've seen Guix accept the "wrong" tarball from the Nix mirror in the past <lfam>This is a case where the origin URI fails and nothing matches from Hydra <lfam>I'll try to find a way to reproduce this <lfam>It's a dangerous mistake <lfam>In my opinion, it's indistinguishable <davexunit>I disagree, but maybe others agree with you. <lfam>It's also easy to make, considering how often people push commits that use the wrong tarball <jmd>lfam: What do you mean 'the wrong tarball' ? <ng0>"/home/ng0/src/packages/ng0/packages/personalized.scm:32:2: st-full-0.7: st-scrollback-0.7.diff: patch not found" so where should the patches in the guix pkg path go? /patches was not accepted, and in thiscase ng0/packages/ is also ignored.. should it go to the root of it? <lfam>jmd: The tarball that doesn't match what upstream released for the version the packager intends to package <jmd>Oh you mean they package some third party version. <lfam>Maybe once a month, somebody pushes a package update that fails for everyone else because the URL was wrong, but the packager used `guix download` so they had the tarball in their store. Or, the tarball is supplied by the Nix mirror, but can't be fetched from the upstream source <lfam>I think we have some code that checks the file name in some cases, but I'm not sure it does this when using the Nix mirror <ajgrf>i'm trying to package profile-sync-daemon, which normally installs a per-user service file (for systemd). is there a good way to do the same for shepherd? <lfam>jmd, davexunit: I've just confirmed the OpenSSL example I gave. You can try updating OpenSSL@1.0.2 to 1.0.2k (not released yet) and use the hash for 1.0.2f. Guix will fetch the vulnerable tarball from the Nix mirror and attempt to build it <adfeno>davexunit: SDL2 built with Ibus support fixes the double input key in Red Eclipse. Thank you very much! :) <davexunit>lfam: the proof *was* in the pudding, I suppose. ;) <lfam>I actually don't know what that idiom means ;) <lfam>We check the file-name as well <lfam>It's only the purely content-addressed sources that suffer from this <lfam>So, back to my original idea, I want a source code archive that also preserves file-names that Guix can use <lfam>I wonder if the Nix folks have done anything about this <ng0>they are debating for 10+ month about throwing everything into a distributed system <ng0>sorry that I can#t be more precise, it was one of the things I found while searching for other systems and distrbuted solutions they work on <davexunit>looks like a great program for photo editing <lfam>I think someone has some free time coming up ;) <efraim>I'm currently working on some of the unpackaged qt modules <efraim>And one of these days ill actually submit the cli translation program I use <lfam>efraim: You're familiar with enlightenment, right? Can you look at the econnman patch on guix-devel? <efraim>Ah, yes, I meant to comment on it <ng0>if not $HOME/.inputrc, where am I supposed to add keybindings for bash? I knew how to do it in zsh but not bash <efraim>On enlightenment on debian, as is, it doesn't load, but with the patch it works as well as expected for the version mismatch between guix's efl and debian's <ng0>ah found it.. more or less <davexunit>we need to compile gnutls with guile 2.1 as an input so that the bindings are generated for 2.1 <lfam>Ah, there goes that free time ;) <davexunit>build guile 2.1 without gnutls, build gnutls with that guile, build a new guile 2.1 with gnutls <efraim>Can we use a bootstrap version to build gnutls? <jmd>icecat needs to go and see a personal development counsellor. <ng0>it's lagging behind again? <jmd>Well it's just that every time it starts, it says "Well this is embarrasing". <jmd>Clearly it has serious problems with self esteem. <ng0>hm... which package provides libutf? <ng0>term.h ... or is it ncurses or something? <ng0>one more package to add to the "soon to be upstreamed" list <adfeno>Hm.... I still can't understand why most of the packages I install through Guix, and which depend on some GTK+ icon, doesn't display such icon. <adfeno>Should I try installing the "Adwaita" (sorry if the name is wrong) icon theme? <lfam>adfeno: I install the adwaita and hicolor themes. I don't know if this is right or not but I usually see the icons <adfeno>I'm now installing Adwaita and GNOME icon themes. <adfeno>Do I need to do something extra after installing them through Guix? <alezost>ng0: re "broken indentation of packages": it happens because Emacs-Guix is not a part of Guix anymore; you can "guix package -i emacs-guix" and add (add-hook 'scheme-mode-hook 'guix-devel-mode) to your emacs config to fix it <alezost>ng0: btw that workaround for 'scheme-indent-function' you mentioned is not needed, as our Emacs is patched for that; see "gnu/packages/patches/emacs-fix-scheme-indent-function.patch" <adfeno>And... Installing Adwaita, GNOME, and Hicolor icon themes doesn't fix the issue. <davexunit>rekado_: holy hell your docker patch is awesome <davexunit>rekado_: to go along with this, maybe 'guix environment' should have a switch so that it outputs the profile name <lfam>adfeno: Can you give an example of a program that shows this problem? <adfeno>For the record: When one opens Nautilus (GNOME file manager), my problem isnot related to the icons of the files that appear in the list (I don't really care for those that much), my problem is with the icons next to the "close" button which is the only one that is visible with an X. <davexunit>adfeno: I have adwaita-icon-theme in the 'packages' field of my OS config <adfeno>davexunit: Oh... Indeed... Another obstacle for me might be that I'm not using GuixSD. <adfeno>I wonder how to tell Trisquel's GNOME to get the icon themes I just installed from Guix. <adfeno>I'll search on this a little bit. <lfam>I see the same thing on Debian. There are no icons in Nautilus at all <espectalll[m]>Sorry if I appear at all of a sudden, but I have a suggestion <adfeno>espectalll[m]: Hm... Interesting.. Please, go on <espectalll[m]>If I recall correctly back when I used Guix on Ubuntu, you could symlink your icons to `~/.local/share/icons` <adfeno>So... Perhaps this is the issue. <espectalll[m]>Just look around at `~/.guix-profile` and see if you can find them <adfeno>Ah.... So good to know where to know where to minimize the window :) <espectalll[m]>Honestly, shouldn't Guix should probably do that automatically? <espectalll[m]>I do understand that Guix expects its apps to work on a Guix environment, so by default its profiles' paths should be the ones being used <espectalll[m]>and not every Guix installation should be expected to work on a multi-user desktop environment <adfeno>Hm... Perhaps, instead of doing it automatically... <adfeno>... Guix should suggest the user to do such things. <adfeno>... Like it does with shell variables. <espectalll[m]>as long as it's easy to find the option, for instance via the docs <davexunit>and it doesn't even make sense for many cases on other distros <lfam>Can we build the packages to look in the right place? <davexunit>lfam: it would be weird for nautilus to look in $HOME/.guix-profile by default <espectalll[m]>not every Guix installation should be expected to work on a multi-user desktop environment <adfeno>.. in regards to "not making sense" in some cases. <davexunit>I don't even know if it can home directory relative stuff like that <davexunit>it would be best to build things so they "just work" <davexunit>what happens where a user uses multiple profiles? <espectalll[m]>Can't it just take $HOME from the environment then from Guile? <espectalll[m]>If you want to set it on build time, it will be harder, for sure <davexunit>okay so you were talking about something else <davexunit>what might work is if nautilus can be passed a flag or use some env var that says where to look for icons <davexunit>and at profile generation time a hook is run that wraps the nautilus program in a script that sets this stuff up correctly <adfeno>Hm... Perhaps addressing this in the documentation seems more appropriate, like so: "if you are installing GuixSD, make sure to do such-and-such in the system declaration. Otherwise, if installing packages from Guix, remember to install such-and-such icon themes and symlink to then from "$HOME/.local/share/icons" directory. <davexunit>we already have some logic about icon caches though <davexunit>I don't think we should recommend symlinking random stuff like that <adfeno>Note: By symlink I mean using `ln -s` while at "~/.local/share/icons", making sure that the target is somewhere at "~/.guix-profile". <adfeno>(Interestingly, if one uses ln's `--relative` option, this wouldn't work, since this would end-up targeting somewhere at "/gnu/store" instead, which ins't desired). <OrangeShark>I use a symlink for icons and applications so they can be found in my distro's Gnome as well <adfeno>davexunit: Unless the documentation for installing Guix has been updated since 2016-06, then I don't recall seeing variables to be set in order for icons and applications to be found by desktop environment. <adfeno>Oh... OK then, sorry for jumping into conclusions. <adfeno>OrangeShark: I also do the same with applications <adfeno>... I just didn't know how GNOME is supposed to know when and where to get icon themes. <OrangeShark>the only issue I see is if you might already be using that directory for icons and applications <adfeno>Unless I'm mistaken, you can always rename the already existing ones. <OrangeShark>just saying if you are already using .local/share/icons for something <adfeno>I'm not symlinking to "~/.guix-profile/share/icons" (exactly)... But to directories within. <adfeno>I must say that what you did is indeed risky. :) <adfeno>Sometimes you might want to test another icon theme with no recipe for Guix. <adfeno>I just tested Nautilus from Guix, and, unless there's something in my copy of Trisquel interfering with it, I was unable to reproduce the issue quiliro has in regards to some text appearing as squares. <adfeno>Once, he's here, we can suggest him to install gs-fonts font-dejavu font-gnu-freefont (just in case) <ng0>woops, it seems as if https://www.thc.org certificate is accepted by the build environment now... months passed since I last tried. Well I bothered the admin to fix the cert problem, it would help on the browser side ***contrapumpkin is now known as copumpkin
<civodul>we need a speaker willing to travel to Pasadena :-) <paroneayea>if someone is interested in doing it, I know someone who knows the organizer and said they are willing to do introductions. <cbaines_>You're in the same continent, right paroneayea? :P <paroneayea>cbaines_: I am, but I'll already be traveling to libreplanet sometime around then... <paroneayea>I don't like to travel too much, it takes away from real productivity, and costs a lot! <cbaines>Understandable, I still haven't decided if I want to try traversing the Atlantic to make it to Libreplanet... <rekado_>another milestone reached: nhc/hugs can build the nhc prelude. Getting closer to a native Haskell compiler with clean bootstrap. <rekado_>a little annoying that I can’t publish any of this yet, because I think I can get farther and publish more impressive results then :) <ng0>I worked a bit on secure_delete again, and now I just need to look at how TAILS uses it again, and can write the service soon. My patch to make it build applies finaly <civodul>that'll make a nice story for bootstrappable.org :-) <civodul>paroneayea: i don't feel like going there either, but we should look for other people in North America <ng0>I'll add comments once I'll upstream it <ng0>eh.. I meant send it in <ng0>If I'd sign my commits, would you be able to directly pull from there? Or doesn't it really matter as they have to be signed-off anyway?