IRC channel logs


back to list of logs

<civodul>hey lfam
<civodul>just took care of the PowerPC patches, thanks for the heads-up!
<civodul>also started an evaluation of 'staging'
<civodul>ACTION -> zZz
<civodul>good day/night!
<lfam>Ah, cool! Thanks!
<davexunit>lfam: I just saw that rust thing for librsvg
<davexunit>I hate C and all but Rust is bad news bears for distros.
<lfam>davexunit: Why is that?
<davexunit>static linking.
<kyamashita>davexunit: ew.
<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>you can?
<davexunit>last I checked it was not possible
<davexunit>that's good
<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!
<sneek>So noted.
<lfam>sneek: forget update librsvg
<lfam>What did sneek note?
<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.
<lfam>Yes, but which words?
<adfeno>Lets see...
<adfeno>Testing this: update librsvg soon!
<adfeno>Oh didn't work.
<lfam>sneek: what is news
<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!
<buenouanq>you heard it here first folk
<lfam>Okay, I'm done ;)
<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!
<adfeno>And doesn't work... ¬¬
<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_>what is the good news
<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
<sneek>I'll keep that in mind.
<rekado_>what is the good news
<rekado_>sneek: well, the good news is that peanut butter and jelly sandwiches are
<rekado_> delicious
<rekado_>sneek: what is the good news
<sneek>I've heard the good news is that peanut butter and jelly sandwiches are delicious!
<civodul>Hello Guix!
<civodul> <- repro-build patches
<civodul>static linking in HPC, woohoo!
<rekado_>back to the roots!
***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
<ng0>names too?
<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
<ng0>an error in "wget" is a good proof that guix download will abort too
<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>I think I am using this to work around it, and it broke last week.. no idea why.
<ng0> seems like it even (used to be/is) in the source of our emacs..
<ng0>is the dwtfyw license equal to public domain?
<ng0>if someone is interested in it, I've added some 2f30 (suckless following community) software here: . I'll make them available as patches to master soon.
<ng0>sneek: forget if someone is interested in it, I've added some 2f30 (suckless following community) software here: . I'll make them available as patches to master soon.
<sneek>Consider it forgotten.
<ng0>silly bot
<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?
<davexunit>adfeno: not knowable
<davexunit>package->derivation is a one way street
<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
<davexunit>no idea if it's related
<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
<adfeno>Hm... And how do I do that?
<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>so just build red-eclipse again
<adfeno>OK :)
<davexunit>and you'll know if it's the same
<davexunit>just compare the outputs
<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>Yep... 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
<davexunit>are you using guixsd?
<adfeno>No, I'm using Guix on top of Trisquel.
<davexunit>this could be an ubuntu thing
<davexunit>in that case
<adfeno>I made a quick search, and found similar issues...
<adfeno> and
<adfeno>Apparently, sdl2 might need to be build with ibus support.
<davexunit>adfeno: I can probably take care of that
<davexunit>I do most of the maintenance on sdl
<adfeno>Oh.... :)
<davexunit>thanks for finding this
<davexunit>I am on the machine that I can test the fix on
<adfeno>You're welcome. :)
<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.
<davexunit>I can post the patch here
<adfeno>Although, I must be away from keyboard 1h from now due to lunch time (it's past 14:00 here).
<davexunit>it's all good
<adfeno>s/1h from/until 1h from/
<adfeno>Must go, bye! :)
<davexunit>ibus really bloats the sdl2 package
<davexunit>oh well
<lfam>The gawk test suite is unreliable :/
<davexunit>adfeno: fixed!
<davexunit>lfam: could you revert that patch you just pushed?
<davexunit>it seems to rebuild the world.
<lfam>Err, yikes!
<davexunit>I'm currently downloading bootstrap binaries
<adfeno>I'm back :)
<adfeno>davexunit: Thanks... I'll do `guix pull; guix package -u`.
<davexunit>adfeno: not yet!
<adfeno>Oh... :)
<lfam>davexunit: Done! `guix refresh -l` let me down this time...
<davexunit>master is broken right now
<davexunit>lfam: yeah, it happens. :(
<davexunit>no worries.
<adfeno>Oh, master is currently broken?
<davexunit>not anymore
<davexunit>now I will push my patch
<lfam>It wasn't technically "broken", just very inconvenient ;)
<davexunit>broken in practice ;)
<davexunit>adfeno: go ahead and run guix pull
<lfam>Hm, there are some tricky conflicts between master and core-updates
<adfeno>Conflicts? How so?
<davexunit>not a problem for you, adfeno :)
<adfeno>Oh OK :)
<davexunit>in doing this bug fix I discovered that SDL2 has an optional dependency on fcitx for foreign language text input.
<davexunit>going to enable that!
<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>it has no bearing on the bug fix
<adfeno>OK :)
<davexunit>I'm just doing some extra stuff while I'm in here
<davexunit>the bug fix patch has been pushed so please test.
<davexunit>it works for me.
<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
<davexunit>the software heritage project will fix that
<davexunit>but we can also fix it ourselves easily
<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>I don't think so.
<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 understand that.
<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>Would anyone notice?
<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
<davexunit>lfam: that's not an attack, though.
<davexunit>that's just a mistake.
<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
<davexunit>I don't see any way of preventing that
<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
<ng0>yep, root of it
<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>adfeno: great! you're welcome!
<davexunit>lfam: the proof *was* in the pudding, I suppose. ;)
<lfam>I actually don't know what that idiom means ;)
<lfam>The thing is that Hydra won't supply the old tarball in this case, because Guix looks here:[...]
<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
<lfam>ng0: Link?
<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>someone should package darktable
<davexunit>looks like a great program for photo editing
<lfam>I think someone has some free time coming up ;)
<davexunit>not me! ;)
<davexunit>I haven't packaged anything new in awhile
<efraim>I'm currently working on some of the unpackaged qt modules
<davexunit>ah that's the blocker
<davexunit>thanks efraim
<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
<lfam>Cool :)
<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
<efraim>Turns on and off wifi, etc
<ng0>ah found it.. more or less
<davexunit>catch 22 time...
<davexunit>guile 2.1 has support for gnutls
<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>so we need to build 2.1 twice. ugh.
<davexunit>that's a lot of computing 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>because of this issue
<ng0>term.h ... or is it ncurses or something?
<ng0>one more package to add to the "soon to be upstreamed" list
<lfam>This has more recent commits:
<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?
<adfeno>I'll reboot. Will be back.
<javistacruz>hi there
<lfam>Hi javistacruz
<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"
<davexunit>wait the emacs stuff isn't in guix anymore?
<alezost>davexunit: yes:
<adfeno>I'm back .:)
<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]>Hey there!
<adfeno>Hi espectalll[m] :)
<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`
<espectalll[m]>as well as the apps to `~/.local/share/applications`
<adfeno>So... Perhaps this is the issue.
<espectalll[m]>Just look around at `~/.guix-profile` and see if you can find them
<espectalll[m]>and set the right permissions if necessary
<adfeno>Hey! It works!
<adfeno>Nautilus has the icons now :)
<espectalll[m]>Great! Glad it worked ^-^
<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
<espectalll[m]>but it would be a nice touch, for sure
<espectalll[m]>"shouldn't Guix should", LOL
<davexunit>it's not clear how that would work
<adfeno>Hm... Perhaps, instead of doing it automatically...
<adfeno>... Guix should suggest the user to do such things.
<davexunit>it seems rather intrusive
<espectalll[m]>toogle an option?
<adfeno>... Like it does with shell variables.
<espectalll[m]>yes, why not?
<davexunit>an option for every situation?
<davexunit>there's lots
<espectalll[m]>as long as it's easy to find the option, for instance via the docs
<davexunit>and it doesn't make sense on guixsd
<davexunit>and it doesn't even make sense for many cases on other distros
<espectalll[m]>(being the docs the hardest acceptable way IMO)
<lfam>Can we build the packages to look in the right place?
<adfeno>davexunit: Also has a point.
<davexunit>lfam: it would be weird for nautilus to look in $HOME/.guix-profile by default
<espectalll[m]>davexunit: I know that, I kinda expressed that earlier
<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>but some things aren't made easy like that
<davexunit>what happens where a user uses multiple profiles?
<davexunit>where does nautilus look?
<espectalll[m]>Can't it just take $HOME from the environment then from Guile?
<espectalll[m]>and symlink?
<davexunit>we're talking about package build time here
<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>I think I get it, but it also won't work
<espectalll[m]>Oh well
<espectalll[m]>…could you at the very least address this on the docs?
<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>so this might already be done
<davexunit>but something isn't right with your setup
<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.
<davexunit>that's not what I'm referring to
<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>OrangeShark: How so?
<adfeno>Unless I'm mistaken, you can always rename the already existing ones.
<OrangeShark>aren't you symlinking the directory?
<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.
<OrangeShark>oh okay
<OrangeShark>I just symlink the directory entire directory :P
<OrangeShark>*the entire directory
<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'll be back really quick
<adfeno>Back .:)
<OrangeShark>adfeno: I don't really venture far with my icons :P
<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 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
<paroneayea> <- I wonder if we can get a GuixSD talk here
<paroneayea>because GuixSD totally solves this.
***contrapumpkin is now known as copumpkin
<civodul>paroneayea: could be a good idea
<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.
<paroneayea>anyone happy to go to California and speak? :)
<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.
<paroneayea> :O
<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>rekado_: woow!
<civodul>that'll make a nice story for :-)
<civodul>paroneayea: i don't feel like going there either, but we should look for other people in North America
<civodul>maybe Leo?
<ng0>any comment on the patch format? Should I separate them into one patch per function (which would make it two or three patches)?
<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?
<ng0>I'll be off now