IRC channel logs


back to list of logs

<paroneayea>oh hey
<paroneayea>guess what arrived today
<paroneayea>my guixsd shirt!
<paroneayea>it looks really nice.
<davexunit>paroneayea: oh wow, awesome!
<davexunit>mine should arrive tomorrow. glad it looks nice!
<davexunit>I wasn't sure what to expect, quality-wise
<paroneayea>nethack isn't packaged?
<paroneayea>how is that possible
<davexunit>ooh, just checked the USPS website... my package was delivered. time to see my shirt. :)
*davexunit reads for ideas about how other container systems work
<zacts>what barriers are there to get libreoffice ported to guix?
<mark_weaver>it has been worked on, and successfully built. I'm honestly not sure why it hasn't been committed yet.
<zacts>ah ok
<zacts>well, that was one big package that is preventing me from switching my full laptop to the full guix distro, from guix on top of debian jessie
<akfoss>Hi. Is Guix a rolling release distribution?
<akfoss>Where can find the packages of Guix System Distribution on the web using a web browser?
<mark_weaver>yes, it is a rolling release
<akfoss>thank you mark_weaver
<akfoss>But I couldn't find g++ there
<akfoss>gcc is there bun not gcc
<akfoss>* g++
<mark_weaver>g++ is included in our gcc package
<mark_weaver>although we generally recommend installing the 'gcc-toolchain' package instead, which includes gcc, binutils, glibc, and something called ld-wrapper that automatically adds rpaths so that the built executables can find the shared libraries they were linked with
<mark_weaver>to be more clear: ld-wrapper includes a script called 'ld' that adds some arguments before calling the real 'ld' from binutils.
<akfoss>I'm currently using Trisquel on my Thinkpad. Can I install Guix alongside it?
<mark_weaver>guix is very non-intrusive. the packages are installed in /gnu/store, and /var/guix and /var/log/guix are used as well, but that's it.
<mark_weaver>each user ends up with a symlink ~/.guix-profile that points to a tree of symlinks, a merging of the packages they have installed in their profile.
<mark_weaver>and then users set environment variables to point to things in ~/.guix-profile, e.g. PATH=$HOME/.guix-profile/bin, etc.
<mark_weaver>so you can very safely install it on top of another distro
<akfoss>In your opinion, which one would have a higher priority for contributors? Trisquel or Guix System Distribution?
<mark_weaver>well, this channel is full of people who have chosen to focus on Guix, so we're a bit biased I suppose.
<mark_weaver>GuixSD is obviously a work-in-progress. It has some significant technical advantages, but it's also not yet ready for average end users.
<mark_weaver>having said that, I've been using it as my primary system for over a year, and it has served me well.
<mark_weaver>Trisquel is the most important 100% free distribution right now, but I think that GuixSD will become increasingly important over time.
<akfoss>Why would it become important?
<mark_weaver>Well, for one thing, is seems to be the most active and growing free distribution that is not wholly dependent on some other not-fully-free distribution.
<mark_weaver>I also think that the technical advantages are important
<mark_weaver>but I don't have time (or frankly the interest) to make a sales pitch to you. there are pointers to videos and papers in our website.
<akfoss>thanks mark_weaver
<rekado->In ardour I have this build phase which adds "/lib/ardour" ,(version-prefix version 1) to the rpath.
<rekado->when I inherit from this package and change the version, the resulting rpath contains the old major version.
<rekado->how can I get this to be evaluated ... later, so that it's the current package's version?
<rekado->right now it's a let binding in a build phase: (string-append (assoc-ref outputs "out") "/lib/ardour" ,(version-prefix version 1))
<rekado->is there a build-time version of version-prefix, so that I don't have to unquote and have it run at packaging time?
<mark_weaver>rekado-: one possible approach is to invent a new keyword for the 'arguments' list, and then it will be passed to all phases including your custom phase.
<mark_weaver>so arguments would contain something like "#:major-version ,(version-prefix version 1)"
<mark_weaver>and then the phase would be defined as (lambda* (#:key major-version #:allow-other-keys) ...)
<rekado->interesting. I shall try this.
<rekado->Thank you.
<mark_weaver>and then you'll have to override the arguments in the derived package. you might use 'substitute-keyword-arguments' to update the #:major-version argument but inherit all the rest.
<mark_weaver>good luck!
<rekado->hmm, waf-build complains about "Unrecognized keyword", but it has #:allow-other-keys in its definition.
<wingo>rekado: #:allow-other-keys? <- missing ?
<wingo>i think
<wingo>maybe ;)
<rekado->wingo: waf-build has #:allow-other-keys in its definition
<rekado->oh, there are two waf-build definitions.
<mark_weaver>rekado-: heh, I just noticed the same.
<mark_weaver>gnu-build also lacks #:allow-other-keys
<mark_weaver>that might be intentional. better check with civodul about this idea. sorry to lead you down a path that he might not approve of.
<rekado->heh, no problem.
<mark_weaver>rekado-: well, here's another idea: move the entire quasi-quoted 'arguments' value to the body of a new top-level procedure that takes the version as an argument. and then call that procedure from both package recipes.
<mark_weaver>so (define (ardour-arguments major-version) `(#:phases ... ,(major-version) ...))
<mark_weaver>well, s/major-version/version/
<mark_weaver>(define (ardour-arguments version) (let ((major-version (version-prefix version 1)) `(#:phases ... ,major-version ...))))
<mark_weaver>and (arguments (ardour-arguments version)) in both recipes
<mark_weaver>what do you think?
<mark_weaver>also, while you're at it, please wrap that 'substitute*' within a 'let' that binds (string-append (assoc-ref %outputs "out") "/lib/ardour" ,major-version) "/") to some variable, and use that.
<mark_weaver>oops, I put an extra close paren in there.
<mark_weaver>or something along those lines, anyway
<rekado->I already have a let binding in my working directory. Using a top-level procedure seems a little heavy-weight, but I guess there is no other elegant solution.
<mark_weaver>civodul might have a better idea, but this is the best one that comes to my mind at the moment.
<mark_weaver>we use auxillary top-level procedures like this in a few other places, e.g. for the linux-libre{,-headers} packages
*mark_weaver just discovered 'xbacklight'
<mark_weaver>and it is easy to configure to xfce to call 'xbacklight -inc 10' and 'xbacklight -dec 10' when the special keys are pressed, in the 'keyboard' settings.
<mark_weaver>now I needn't write to values in /sys/ to change my backlight setting :)
<mark_weaver>I wonder how this is normally supposed to work in xfce. seems crazy that I should have to set it up manually.
<mthl>mark_weaver: maybe be xfce power-manager ?
<mthl> *with
<mark_weaver>mthl: ah, that indeed seems likely. we should package it.
*mark_weaver actually ended up using "xbacklight -inc 5 -time 0 -steps 1"
<mthl>mark_weaver: I guess your backlight hotkeys aren't working automatically because of libreboot
<rekado->mthl: backlight hotkeys on my T60 with GuixSD work fine in Xfce.
<mthl>rekado-: T60 with libreboot?
<rekado->oh, you wrote libreboot, not linux libre. Sorry.
<DusXMT>Wait, so we now have a library for rebooting the system?
<davexunit>libre-boot, not lib-reboot
<DusXMT>I know, sorry :)
<mthl>I wasn't getting it :-)
<fchmmr>DusXMT, ignore all of them. libreboot *is* a reboot library.
<fchmmr>If anyone tells you it's not, they're lying.
<fchmmr>It boots your system (it's boot firmware), which necessarily means that you can then re-boot it.
<fchmmr>That makes it a reboot library.
<fchmmr>so when you see "reboot library" in the topic of #libreboot IRC channel, it's actually true.
<fchmmr>For instance, it has ACPI support for all current targets.
<DusXMT>The only problem now is: It's not really a library, or is it?
<fchmmr>this page has a nice explanation of how ACPI is relevant to rebooting:
<fchmmr>"library" has a very loose definition.
<fchmmr>but it's also a libre boot firmware, hence libreboot
<fchmmr>lib-reboot and libre-boot are both correct (libre-boot is more useful)
<mark_weaver>mthl: I don't think this issue is because of libreboot. wingo reported the same problem on a system that's running factory bios.
<mthl>mark_weaver: ok
<mark_weaver>the backlight keys worked on my Libreboot X60 because on that machine libreboot adjusted the brightness itself, rather than reporting the keypresses to userland. at least in the version of libreboot I was using at the time.
<davexunit>so, I know that one can specify a directory as a package's source field, but is there any way to control precisely what files in that directory should be included?
<davexunit>I don't think there is.
<davexunit>the use case I have in mind is testing package builds from a project's git repo.
<davexunit>my guile projects have a 'package.scm' file in the root of the source tree that I use for 'guix environment', but I also want them to be buildable packages.
<mark_weaver>davexunit: you could use a snippet to remove the files you don't want
<mark_weaver>(or to remove everything but the files you explicitly want)
<mark_weaver>davexunit: although in the git repo case there's a better way. use the 'git-fetch' method and use a file url pointing to your local repo.
<mark_weaver>although I guess it's a pain to have to provide the hash for that.
<mark_weaver>but you can just run it and then take the hash from the error message :)
<mark_weaver>perhaps we should have something to make this easier, dunno.
<mark_weaver>I guess you could write a procedure that takes the directory name and a specification of what files you want, and produces a package object that uses trivial-build-system to copy just those files to the output. then you could use that in the source field.
<davexunit>mark_weaver: I want to skip the hash check
<davexunit>mark_weaver: yeah that last suggestion is roughly what I'm after.
<davexunit>it will make it easy to do integration testing while developing, and also allow people to install my software straight from the git repol
<mark_weaver>maybe you could get the list of files from 'git' itself.
<mark_weaver>although then it wouldn't work from a tarball release
<davexunit>that's fine, because it's purely for development purposes.
<phant0mas>mig cannot find -lfl from flex, when crossbuilding with --target=i686-pc-gnu
<mark_weaver>the thing is, I guess it will start by importing the entire git repo (including all history) into the store, and then trimming it.
<mark_weaver>which I guess means that the package will be rebuilt with a new hash every time any git state changes.
<mark_weaver>without the hash, it won't be a "fixed output derivation"
<mark_weaver>IIUC, I think that's a major problem with this idea
<DusXMT>Oh no... while I was updating my Guix VM, I came across this: guix system: error: open-file: No such file or directory: "/proc/sys/kernel/yama/ptrace_scope"
<mark_weaver>davexunit: so, I think you should ask civodul about this before spending much time on it.
<DusXMT>(It's been asleep for a while)
<DusXMT>I _do_ have a custom kernel, so it's definitely because of that... now to figure out how to enable what's missing
<mark_weaver>phant0mas: look at config.log and find out what error occurred.
<mark_weaver>davexunit: I think that you should use an approach that does not involve importing the entire git repo into the store
<phant0mas>mark_weaver: I did that, it tried to build a test to see if flex is working right and it fails with i686-pc-gnu-ld: cannot find -lfl
<phant0mas>collect2: error: ld returned 1 exit status
<phant0mas>I am looking into it
<phant0mas>actually if I try to build flex with target=i686-pc-gnu it fails as well, so I should probably fix that first :P
<davexunit>mark_weaver: yeah, that's my plan. 'git ls-files' will return all the files I'd want to put into the store.
<davexunit>just need to write the guile code around it
<mark_weaver>phant0mas: if you can't build flex, how did you even reach the point of trying to build something that has flex as an input?
<mark_weaver>davexunit: maybe the better answer is to write some code that dynamically (and efficiently) computes the hash of the trimmed git repo
<mark_weaver>and that dynamically creates a fixed-output-derivation with that hash
<davexunit>I've considered that approach, too.
<mark_weaver>fixed-output derivations are the only ones that have access to files outside of the store, so they are the only way you can create the trimmed source without importing the entire git repo into the store
<mark_weaver>well, I suppose the simplest way would be to write some code that copies the desired source files to a temporary directory, and then import that directory into the store
<mark_weaver>that copy operation would be repeated every time, unfortunately
<mark_weaver>the more efficient method would do the equivalent of "guix hash -r", but looking only at the files you want to keep
<mark_weaver>without copying
<mark_weaver>but I think you should consult with civodul before spending much time on this. my knowledge of guix is not quite good enough to give a confident answer on how best to proceed.
<davexunit>yeah, I'll talk to him when he's around.
<davexunit>hashing the files returned by 'git ls-files' sounds like a good approach to tinker with, though.
<davexunit>as long as I can delay the hashing until needed.
<mark_weaver><rekado-> mthl: backlight hotkeys on my T60 with GuixSD work fine in Xfce.
<mark_weaver>rekado-: are you running libreboot on that?
<mark_weaver>the reason I ask is because I'm wondering how it's working for you
<mark_weaver>(if you're running libreboot, I know the answer. if you're running factory bios, I'm not sure why it works)
<DusXMT>Okay, so I had to enable CONFIG_SECURITY_YAMA and add security=yama to the built-in kernel command line
<mark_weaver>DusXMT: haha, the only reason you needed to add support for YAMA is because we explicitly disable YAMA at boot time, because we don't like it :)
<mark_weaver>DusXMT: the better solution is to modify 'activate-ptrace-attach' in gnu/build/activation.scm to check for the existence of that file before trying to write a 0 to it
<mark_weaver>by wrapping (unless (file-exists? "/proc/sys/kernel/yama/ptrace_scope") ...), or perhaps just (false-if-exception ...) around the 'call-with-output-file'
<mark_weaver>well, actually, I'm not sure we disable YAMA completely. maybe just one part of it.
<mark_weaver>(I confess I didn't know what YAMA was until I just looked it up)
<mark_weaver>bah, I meant (when (file-exists? ...) ...), obviously :)
<mark_weaver>DusXMT: btw, I wasn't laughing at you; I didn't understand what was going on until just now either.
<mark_weaver>when I finally realized what was going on, I found it amusing.
*mark_weaver tests a fix for this issue
<DusXMT>mark_weaver: well, guix system reconfigure also complains about it missing... I guess the same sort of patch could be applied
<mark_weaver>DusXMT: I think the same code is run in both cases.
<mark_weaver>DusXMT: here's the fix I'd like to apply:
<mark_weaver>if it's easy for you to test it on a kernel lacking YAMA support, that would be great.
<mark_weaver>if it's a pain, no worries, it probably works :)
<DusXMT>mark_weaver: I'll test it... it will take some time though, I'll have to set up a git-based guix, and that'll take a while
<mark_weaver>I just tested it on my system that has YAMA, so at least it doesn't make it worse.
<mark_weaver>maybe I should just commit it and then you can guix pull
<DusXMT>I'd be thankful, it'd make my life a teeny tiny bit easier :)
<mark_weaver>okay, I pushed it. let me see if the snapshot tarball downloaded by 'guix pull' is updated yet. I'm not sure off-hand how much lag time (if any) there is on that.
<mark_weaver>DusXMT: okay, the snapshot is updated. if you 'guix pull' now you should get the fix
<DusXMT>mark_weaver: okay, will test
<DusXMT>more like thank you, now I don't have to have a redundant option in my kernel :)
***rohan_ is now known as ajnirp
<DusXMT>mark_weaver: I can confirm that booting into the system works... I'll have to modify something to test out the installing though...
<DusXMT>Does GuixSD support swap now?
<mark_weaver>DusXMT: yes, there's a 'swap-devices' field in the OS config
<mark_weaver>e.g. (swap-devices '("/dev/sda2"))
<DusXMT>thanks :)
<mark_weaver>although I prefer to do it by label, so (swap-devices '("/dev/disk/by-label/jojen-swap"))
<DusXMT>this is a qemu VM, so /dev/sda2 should do
<mark_weaver>(and I did "mkswap --label=jojen-swap /dev/...")
<paroneayea>hello #guix!
<davexunit>hey paro
<paroneayea>davexunit: read the lxd link, "rest api" for localhost containers stuff, is that right?
<paroneayea>that's kind of odd
<paroneayea>those are for remote daemons.
<davexunit>liblxc is too high level for guix to use, unfortunately.
<davexunit>I looked into it.
<davexunit>and now I see that red hat is trying to standardize how containers are supposed to work
<davexunit>but the proposed standard includes things like the packaging format and selinux.
<davexunit>so I can't imagine that guix could ever adopt such a standard.
<civodul>hey hey!
<civodul>mark_weaver: are there kernels that have the Yama thing compiled out by default?
<civodul>(that wouldn't be a bad thing ;-))
<mark_weaver>civodul: DusXMT was trying to run GuixSD in a VM with a custom kernel that didn't have YAMA, and so it died during the boot process
<mark_weaver>he wrote here "I had to enable CONFIG_SECURITY_YAMA and add security=yama to the built-in kernel command line" to get it to work
<mark_weaver>correction: I don't think he even got to the point of booting it. "guix system" failed
<mark_weaver>civodul: on another topic: davexunit is looking for a way to build a guix package from a git checkout he's already got. see and the discussion that follows between him and me.
<mark_weaver>i.e. he doesn't want to have to compute the hash manually, as a convenience for development.
<mark_weaver>I was brainstorming with him about ways of doing this without importing the .git directory and other auxiliary files into the store.
<mark_weaver>but my knowledge is insufficient to know the best way
<civodul>mark_weaver: oh ok
<civodul>i see
<civodul>it's possible to import a whole directory to the store
<civodul>i'm not sure if that works with the 'source' field of a package, though
<civodul>but it should
<davexunit>civodul: yes, but I'd like to filter a directory first.
<mark_weaver>right, but in this case he doesn't want the whole directory, he wants only selected files from the directory, namely the files that are actually part of the git repo
<civodul>ok, davexunit is a demanding person ;-)
<davexunit>I looked at add-to-store, but couldn't think of a way to write something that did what I wanted since the daemon ultimately has control over that process.
<mark_weaver>otherwise the entire .git directory will be imported, and presumably fresh hashes will be generated for all dependent builds whenever the git repo state changes at all, even if the checked out files haven't changed.
<civodul>actually, there's a basic filter mechanism on the daemon side, for add-to-store
<civodul>which is unused
<davexunit>basically, I only want to include the files returned by 'git ls-files'
<mark_weaver>if he makes changes to the git repo and then goes back to a git checkout that he's already built, it shouldn't generate new hashes.
<civodul>you could always create a derivation that produces the right treee
<mark_weaver>but if he imports the entire directory including git repo and then uses a normal (not fixed-output) derivation to filter it, I think he'll end up with fresh hashes, right?
<davexunit>civodul: I was going down that line with a gexp, but I foresee permissions issue.
<mark_weaver>but if he uses a fixed-output derivation, then he needs to compute the hash, which is inconvenient.
<civodul>mark_weaver: yes, you'd want to exclude .git and so on
<davexunit>since the repo is likely in someone's home dir, that the guix build user cannot read.
<davexunit>I'm not sure how to avoid dumping .git and every build artifact into the store.
<civodul>davexunit: the gexp would be a loop that would recreate the tree piecemeal
<civodul>each file is first individually added to the store
<civodul>and then the derivation puts them in the right place
<civodul>like imported-modules does
<davexunit>civodul: adding each file to the store sounds wasteful, but maybe it's okay.
<davexunit>there could easily be hundreds of files depending on the project.
<davexunit>adding all of the guix source files to the store, for example.
<mark_weaver>the best idea I could come up with was this: dynamically compute the hash of the fixed-output-derivation by doing the equivalent of "guix hash -r" on the git checkout but ignoring any file that's not part of the git repo, and then having the fixed-output-derivation copy the git-handled files to a fresh store directory.
<mark_weaver>civodul: can you think of a better way?
<mark_weaver>for large projects a store item for each individual file would be a bit much, I think.
<mark_weaver>some projects have tens of thousands of files
<davexunit>there's got to be a way to make an origin that can filter a local directory without requiring a checksum
<mark_weaver>e.g. the firefox tree has over 100k files
<mark_weaver>linux-libre has almost 52 thousand files
<civodul>mark_weaver: the problem is that the hash of the fixed-output derivation is an "implementation detail"
<mark_weaver>civodul: I don't understand what you mean by that
<civodul>for reasonably-sized projects, the add-to-store calls are reasonable
<civodul>but not for firefox or linux-libre, indeed
<civodul>mark_weaver: maybe i misunderstood what you meant by hash of the fixed-output derivation
<civodul>did you mean that hash of the contents?
<mark_weaver>civodul: what happens normally when you import a whole directory into the store?
<mark_weaver>can't we just generalize that mechanism to choose selected files only?
<civodul>there's more or less such a mechanism anyway
<civodul>but i think it cannot be used yet, i forgot why
<mark_weaver>oh, okay, so maybe we can just use that
<civodul>look at LocalStore::addToStore
<civodul>it has this PathFilter thing
<mark_weaver>civodul: what build environment are fixed-output derivations run under? are they in a chroot? can they access the user's files?
<mark_weaver>I noticed that the 'git-fetch' method could be used to clone a git repo in my home directory for example
<civodul>fixed-output derivations do not run in a chroot, mostly so they can do networking
<civodul>that might work, yes
<civodul>it's a hack ;-), but you could try
<mark_weaver>that suggests to me that 'git-fetch' derivations can access my home directory, or at least the world-readable parts.
<mark_weaver>so, here's the hack I envision: make a procedure that dynamically generates a fixed-output derivation to do this, by first computing the hash that the output will have, by doing the equivalent of "guix hash -r" except on selected files only
<mark_weaver>and then within the fixed-output derivation, it simply copies those selected files to the output directory
<mark_weaver>in this case, the selected files would be the files that are actually part of the git repo, using "git ls-files"
<mark_weaver>can you think of a better way?
*mark_weaver looks at LocalStore::addToStore, meanwhile
<davexunit>the PathFilter thing sounds promising
<civodul>mark_weaver: as a quick hack, it seems easier (and more robust) to do the repeated add-to-store calls
<civodul>if the project has a reasonable number of files, that is
<civodul>and then, PathFilter, indeed
<mark_weaver>so, PathFilter is a C++ struct
<davexunit>there really ought to be an elegant way to handle this.
<mark_weaver>that defines a () operator, basically a predicate on pathname
<civodul>we'd need an addToStore2 RPC that allows clients to express a "path filter"
<mark_weaver>the amount of stuff in the /gnu/store directory already seems like a bottleneck to me
<mark_weaver>at least for filesystems that don't handle lookups in huge directories efficiently
<civodul>ext[34] are fine in that respect
<mark_weaver>also, I guess that all of those store items are going to bloat up anything that iterates over the database
<davexunit>mark_weaver: I've thought about about before, too. normally, I see people break things up into many subdirs
<davexunit>and you can use the hash to find the right place to look
<civodul>yeah like git does
<davexunit>s/about about/about that/
<davexunit>I wonder why the nix folks chose not to
<mark_weaver>civodul: do ext3/ext4 filesystems have O(log N) directory lookups by default?
<mark_weaver>for some reason I thought not, but maybe I'm out of date
<civodul>i don't know what the complexity is, but the "dir_index" option in ext2 or 3 "made things faster"
<civodul>(sorry for the unscientific info)
<mark_weaver>adding another layer, as we do in /var/log/guix/drvs for example, has another problem: it adds one more level of indirection for every file lookup that ends up in the store, and actually more than one because in practice there are multiple layers of symlinks that traverse into the store repeatedly
<civodul>but anyway, there's no problem in practice AFAIK
<civodul>Nix has had years of actual testing, which is nice :-)
<civodul>so it could surely be improved
<civodul>but we'd need actual performance figures and all that
<mark_weaver>e.g. resolving ~/.guix-profile/bin/gcc requires 4 separate lookups into /gnu/store/*
<mark_weaver>one to find my profile
<mark_weaver>another to find the gcc in gcc-toolchain
<mark_weaver>sorry, 3.
<mark_weaver>well, I'm not going to belabor this, but personally I don't consider one store item per file in the source directory to be an acceptable solution here
<mark_weaver>guix gc is already too slow for my taste
<mark_weaver>but we can table the discussion for now :)
<mark_weaver>dir_index is the default for ext4, but not for ext3, btw.
<mark_weaver>hmm, what I just said about ext3 might be out of date
<kete>We call that "parking" discussions
<mark_weaver>yes, at some point dir_index became the default for ext3, and I guess it was at least 6 years ago
<mark_weaver>so yeah, I think adding a new RPC to specify a path filter seems like the right approach to me.
<mark_weaver>to import a directory with a path filter, I mean.
<mark_weaver>in this case, we'd need to send the list of files, which would be added to some C++ "set" data structure with efficient membership testing
<davexunit>do we have to add new c++ code for this?
<mark_weaver>yes, definitely
*davexunit goes afk
<mark_weaver>if you search for PathFilter in guix/nix, you'll find that there's currently only one kind of PathFilter object that's ever created: defaultPathFilter, which always returns true
<civodul>okay, this is not fully baked :-)
<mark_weaver>so we'd need to create a subclass of PathFilter, I guess, which is given a set of files for which true should be returned, and false for anything else
<mark_weaver>civodul: heh, right, who knows if it even works properly :)
<civodul>indeed, it looks more like a declaration of intent :-)
*civodul -> zZz
<civodul>good day/night!
<mark_weaver>dumpEntries in is where the filter is queried while iterating over the files
<mark_weaver>okay, good night!
<mark_weaver>s/only one kind of PathFilter object/only one PathFilter object/