IRC channel logs
2016-09-09.log
back to list of logs
<dtluna>brendyn: does it emit this message? <brendyn>I think that message is coming from the daemon runnin as root <mark_weaver>dtluna: tell me the version of glibc indicated by the command: ldd /root/.guix-profile/bin/guix-daemon <mark_weaver>dtluna: and tell me what directories are present in /root/.guix-profile/lib/locale <dtluna>libc.so.6 => /gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/libc.so.6 (0x00007feec4f89000) <mark_weaver>dtluna: you need to install glibc-locales in root's profile <mark_weaver>(glibc-utf8-locales might also be sufficient, depending on your locale setting) <dtluna>mark_weaver: installing glibc-utf8-locales <dtluna>The manual says NOTHING about this BTW <dtluna>mark_weaver: the problem is still there <ng0>how do we treat software which has the company name in it? the (R) needs to go, but $company - $programm is still something we should name it, right? <brendyn>I suspect we may have similar issues because we are both on Parabola. mark_weaver One odd thing I get is that guix running as root uses my /home/b/... profile. For example guix package -i hello: outputs error: directory `/var/guix/profiles/per-user/b' is not owned by you <dtluna>mark_weaver: oh wait, the problem might be that there is no ru_RU.utf8 locale yet for Guix <brendyn>I setup all the symlinks as per the manual so I'm not sure what I did wrong. <mark_weaver>dtluna: that locale is certainly not in glibc-utf8-locales, which is quite minimal <dtluna>mark_weaver: and what is wrong with my tone? <mark_weaver>dtluna: quotes like "GNU Guix should step up its game" and "The manual says NOTHING about this BTW", make you sound very annoyed and entitled to service from us. <ng0>constrcutive criticism and improvement is welcome. capslock make it harder. <dtluna>mark_weaver: I am just pointing out what should be improved. <mark_weaver>the issue I have is the way you said it. but anyway, no need to dwell on this. <dtluna>mark_weaver: well, I am sorry, I am not a native speaker. <ng0>you what intel... sh ../../build/test_launcher.sh ./test_malloc_overload_proxy.exe <dtluna>It would be awesome if Guix showed the progress of the download <ng0>what is this.. it runs .exe files and they succeed. <brendyn>dtluna: I think it counts upwards at the moment ;P <ng0>or maybe the .exe ones silently fail in a non-fatal way and just say 'done' <dtluna>brendyn: I kinda want to know the percentage of downloaded <ng0>I feel trolled by this intel build. <brendyn>dtluna: It can be added. I think there any many ways to improve the terminal output of guix <dtluna>brendyn: the only problem with me doing it is Guix being written in Guile :) <brendyn>dtluna: That's not considered a problem in these parts <dtluna>brendyn: I mean I don't know anything about LISP <brendyn>dtluna: Currently I'm still learning guile. I've made a couple package definitions, but I'm not good enough to hack on guix its self yet. <dtluna>brendyn: shouldn't be too hard tbh <brendyn>dtluna: You can start by learning to make package definitions if you like. <dtluna>brendyn: I'll see. Maybe a pygnusocial package would be good. But it requires python 3.5 which is not yet in the repos, surprisingly <brendyn>dtluna: Would you like to package python-dropbox? <dtluna>brendyn: no, because Dropbox is awful <brendyn>Is it not ok to provide support for it? <dtluna>I suggest you use Syncthing which is free software <dtluna>brendyn: It is proprietary and you should not use it. <brendyn>dtluna: Yes, but isn't python-dropbox free software? <dtluna>Brendyn: maybe. But I personally won't promote anything directly related to Dropbox <brendyn>I'm not too familiar with it so I'm wondering if it is best to include or not <brendyn>I'm not asking about software to use. I'm packaging software that can use dropbox <dtluna>Where can I see what needs to be done to package Python 3.5? <brendyn>dtluna: Look on the guix-devel@gnu.org mailing list. search it for any mentions of python. Then get the guix git repo and have a look in gnu/packages/python.scm <brendyn>It looks like many people have packaged python software, so most like some people are already working on it <demotri>I hacked togehter my first package: proj.4. It's fine on x86_64 but has test failures on i686. <demotri>It's not a patch, it's just a package definition, I build it with 'guix build -f proj.4.scm'. <brendyn>It looks like you malformed the text. the testvarious like is cut off <ng0>wow.. this make all with all the checks and tests takes long <ng0>30 minutes now... it's not the default, the default does not run the checks.. I think i should disable this. <ng0>this isparallel computing targeted i think, so i think hpc's etc are the thing where this will run much faster <brendyn>ng0: maybe there is some option like make -j4 ? <ng0>what if the build machine has less cores? thisshould not be set i think <ng0>and even when I do, I seriously doubt this will speed up testing. <ng0>30+ minutes testing is something admins of HPCs can enable themselves. <lfam>dtluna: Python 3.5 is on our core-updates branch, where we test updates to core packages <lfam>dtluna: So, you could cherry-pick the relevant commits to a local branch and build your packages based on that, if you wanted to <brendyn>lfam: dtluna quit the channel. Use tab complete when typing peoples names and you will discover that ;) <lfam>So I can respond to questions related to things I work on <brendyn>demotri: Honestly I have no idea why that test fails for i686 <brendyn>demotri: But to let you know, I get the same result <demotri>brendyn: OK, thank you. At least this part is reproducible. <demotri>What should I do next? Would the package be acceptable if it fails on 32-bit? Should I talk to upstream? <brendyn>demotri: If you use the -K flag you can keep the build directory and poke around in the directory like /tmp/guix-build-proj.4-4.9.3.drv-3' <demotri>brendyn: Thank, I know already '-K', without that I wouldn't be at that point :-) <brendyn>demotri: Look it up on a search engine <demotri>brendyn: What I figured out is that under xa64 there is a src/.lib/lt-cs2cs and a src/.lib/cs2cs. Under 32-bit there is only the cs2cs-variant. <brendyn>demotri: It looks like the numbers are different due to numerical precision differences between x86_64 and i686 <brendyn>demotri: Depending on the use case of the program, that may be possible to simply ignore, i.e, disable the test <brendyn>As you can see, the test actually "succeeds" to 6 significant figures. <demotri>brendyn: Well, the use case of the program is to transform coordinates with a very high precision. If it is used for land surveying, that could be too much of an error. Or at least indicate a bigger problem. <demotri>brendyn: I will google again and then discuss with the maintainers. <brendyn>also, why are you loading so many modules like gnome/ <brendyn>I suppose you copied it from an example. <OriansJ>anyone else ever see a server with a ED25519 public key that produced an Identical sha256sum but two entirely different ascii arts? <demotri>Ah, that is just copy/paste. I don't know from which package I started. I know, I really have to clean this up. <demotri>I was just happy that it worked in the end on one platform. <brendyn>ok no worries. ;) Essential (use-modules (gnu packages gnome)) loads the file gnu/packages/gnome.scm, making all the guile variables available. Currenly, you're only using (gnu packages glib) plus a couple others <demotri>OK, I will clean it up and then post a patch. <brendyn>demotri: Also config.sub and config.guess are gpl3+. You always have to do a license check. I typically use ack to scan through all files looking for 'license' and things like that <brendyn>And then do a comparison of your package definition with debian/arch/gentoo or whatever. <demotri>When comparing package definition, what do you mean? <demotri>Ah, what I forgot: In Debian they have libproj, proj-bin, proj-java. I should add differnt outputs. <brendyn>I mean take a look at the code debian uses to package it. <brendyn>Maybe you want to name it "proj" instead of "proj.4" <brendyn>As you can see, debian packagers are mad. <brendyn>"The software was developed by the USGS and has no copyright <brendyn> nor license. Do with it what you will." <demotri>What do you want to tell me with the last sentence? <brendyn>In the license section you want to put all the licenses you can find, brief comments naming the files under each license. <demotri>What is the syntax for creating complex licenses? '((file . license) ...) ? <brendyn>No, have a browse through some random .scm files and you will see how <brendyn>(license (list license:expat license:gpl2+ ...)) <demotri>Thanks again. Have to go to bed now. Bye. <OriansJ>anyone ran into this one before? guix refresh: error: build failed: the path `/gnu' is a symlink; this is not allowed for the Nix store and its parent directories <brendyn>Well I guess that's the problem. It's a symlink, and It can't be ? <OriansJ>I am just trying to understand why it can't be <OriansJ>now I know I can simply sudo mkdir /gnu && sudo mount --bind /san-mount/projects/guix /gnu to fix the error message; I am just trying to understand why it happens at all <brendyn>Well my only guess is that since guix/nix is making symlinks from /gnu to anywhere else, this could cause errors by linking A -> B and B -> A <OriansJ>I guess that kinda makes sense in the Developers didn't want to deal with several potential problems way of looking at it. Someone may want to mention that in the guix documentation and the mount --bind solution works great fyi <bavier1>is it common for tools to write their --help output to stderr? <janneke>bavier1: i think its wrong, but many tools do so <bavier1>and then it apparently resets the output formatting of stderr, so a grep only shows "Binary file matches". ugh <efraim>bavier1: I realized I also need to make sure to build and run the tests, another thing they do is not build&run the tests by default <lfam>sapientech: Did you find anything searching for that error message? "install: will not overwrite just-created" <sneek>civodul, you have 1 message. <sneek>civodul, janneke says: seems file-system-/run/systemd is twice in %desktop-services <efraim>we're 22 packages over my 5% failing rule <lfam>Is there an "Intro to the Hydra web interface" I can read or watch? <janneke>lfam: my thoughts eactly...efraim's comment had me dabble in hydra.gnu.org for a bit and i felt lost <lfam>Is it expected for the encrypted-root-os test to fail? <efraim>There's a certain number of packages that are going to be broken at any given time, and I try to keep that number below 5% of the suceeding packages <brendyn>efraim: Ah, such wisdom. So you manage hydra? <efraim>no, I end up committing a lot of package updates so I try to make sure I don't break stuff <lfam>efraim, how do you keep track of all the updates? <brendyn>Do you package python stuff? I've made an update for duplicity but it seems to want pylint, which we don't seem to have. <efraim>guix refresh helps a lot, and I have a couple of packages I keep an eye on <efraim>I've ended up spending a lot of time with packaging python, don't actually know a lot of python though <efraim>i don't have a copy of pylint in my GUIX_PACKAGE_PATH though <brendyn>If a package was working fine, but then fails after a dependancy update, will hydra still serve the old binary substitute? <lfam>brendyn: If you request to old package (before the dependency update), Hydra will serve it to you <brendyn>But it will be deleted after the update? <lfam>But, if you do `guix pull` and get the update, you will request the new, broken package. <lfam>It won't be deleted from your local system. If you can't build the package, you will still have the working package in your profile <lfam>Guix only deletes things when you run `guix gc` <rekado>How do I use "guix container exec"? <efraim>brendyn: `guix import pypi pylint' looks like it gives a pretty good result, although I haven't tried building it yet <civodul>rekado: it's meant to be used in combination with 'guix system container' <civodul>or with 'guix environment --container' <civodul>you give it the PID of the parent child process of 'guix' <civodul>the one that's PID 1 inside the container <gnuub1>what would be the preferred way to add a file to the xorg.conf.d ? there seems to be no procedure for it (at least on the manual page Xwindow ) <brendyn>gnuub1: Perhaps the same way you add a file to /bin?. (install-file "file.conf" (string-append (assoc-ref %outputs out) "/share/X11/xorg.conf.d") <gnoob1>ok thx... i tryed to extract that information somewhere, but there aren't any examples :) <gnoob1>it is hard for me to figure that out without examples :P <brendyn>gnoob1: Yeah, I the manual it's self doesn't have exampes, but don't forget there are 4000 "examples" in the git repo of real packages. <gnoob1>yup... i was working through the git repo... <brendyn>Personally I often run stuff like `ack xorg.conf.d -A 5 -B 5' and that will instantly show every single file referencing that string. <brendyn>(assoc-ref %outputs out) refers to the /gnu/store/...package-x.x.x/ directory, which is effectively /. When you install a package that that gets mapped onto the root of your profile <gnoob1>the structure is pretty clear to me, i just have still some issues with the guile syntax, esp. if i need to write stuff from scratch <ng0>don't know, I can't investigate or fix much, I'm working on gnurl right now. <ng0>some file (crypto) referenced zsh. <ng0>I'dguess someone merged an oldpatch before checking on master <ng0>look for the commit of Tomb <ng0>fix it to use shells instead. <ng0>that shouldmake master build again <iyzsong>ng0: yeah, I'll fix it in some minutes, thanks! <wingo>guix + gnus + gnupg question <wingo>and emacs and everything else from guix <wingo>and when i see a mail encrypted to me, gnus asks me if i want to decrypt it <wingo>maybe i need gpg-agent running or something <civodul>wingo: gpg 2.1 spawns its agent automatically <civodul>could you try 'gpg' on the command line? <wingo>i think i have done that before and it worked, to sign releases <wingo>gpg: signing failed: No pinentry <wingo>gpg: signing failed: No pinentry <civodul>rekado: finding the right PID is slightly inconvenient, but we (you? ;-)) should prolly add an example in the manual <wingo>i don't have anything gpg-related in my environment, perhaps something went wrong there... <civodul>oh and you need something like "pinentry-program /home/ludo/.guix-profile/bin/pinentry-gtk-2" in ~/.gnupg/gpg-agent.conf <civodul>there are plans to make it easier... <janneke>wingo: are you on guixsd or debian+guix or so? <janneke>/me also has in gpg-agent.conf: allow-emacs-pinentry <janneke>ACTION also has in gpg-agent.conf: allow-emacs-pinentry <janneke>(i had quite some problem getting it to all to work with deb+guix) <ng0>what's thedifference in git between a branch and a tag? I know branches, but do tags follow something like branches (git checkou -b --tag name maybe?)? <ng0>i think i nunderstand it now after reading some pages <ng0>for cherry-picking curl to gnurl there will be no difference in tags anyhow <dvc>Hi, I must say that I'm getting a little annoyed with the u-boot patches... If someone doesn't want to do the job properly, I don't mind and will do it myself when I get around to it. This reminds me of looking at how I submit patches =P Hopefully my patches aren't annoying anyone xD <dvc>Sent out the linux-kernel patches, I went over all the commit messages again - I think that the patches shouldn't be too bad =P <ng0>encryption of /home with cryptdisk is already possible in guixsd or does it introduce some weird behavior of the system/user? <dvc>civodul: I'm David xD why? <cehteh>civodul: apropos: are there any plans/sketches how full disk encryption should be addressed in future, i am going to work on that for myself, using grubs crypt and luks stuff, but to my understanding that would loose the ability to unlock remotely over the network <cehteh>otherwise one could copy the parts which are used for booting from the store to /boot .. but i think that would be a bit messy <dvc>cehteh: I think there is already some work done on full-disk-encryption. Look at the tests in gnu tests... <dvc>cehteh: That test failed for me though... <cehteh>havent checked recently, i've seen different articles about how to fix it with some hacks but nothing that works out of the box <civodul>dvc: oh i see, i was wondering based on what you wrote regarding u-boot :-) <civodul>cehteh: there's a patch needing testing, and there's even a test <civodul>i started working on it, committed the test accidentally, and then did not complete <ng0>you need to build texmf from source. <dvc>janneke: pass --fallback to guix build should get you past this <dvc>janneke: I'm interested in installing hydra too! If you get it working maybe you could add a section to the guix manual? <janneke>dvc: ... it bombs out trying to patch configure.ac <ng0>there's the hydra documentation, upstream.. and work here is being done on curias, hydra grown too much away from what guix can use, the latest releases of hydra at least. <ng0>can (source) be a local git repo? if so, can someone give me a small example line? <brendyn>My guix uses my local git repo, is that what you mean? <ng0>i mean what I wrote with no interpretations. can (source) [in a guix package defintion] use a local git repository of the software I package <ng0>motivation: I don't want to setup a new profile just for python2 so that make check of new gnurl release can succeed <dvc>(source (local-file blah <ng0>b8ut maybe i should just do that.. ah. thanks <ng0>ah cmon.. I'm using this system capable of working with profiles and environment etc.. i shouldn't be lazy and copy it over to gentoo. so I need groff and python2 in an environement which does not affect my profile at all. guix envrionment --ad-hoc can do that, right? <ng0>yep... ng0@shadowwalker ~/src/gnurl [env]$ python --version <bavier>iyzsong: thanks for the quick import fix in crypto.scm <bavier>I maybe should have done a 'make clean && make' after my rebase instead of just `make` <brendyn>Maybe I should done make at all. I just run guix and guile automatically picks up the new .scm files and compiles them into cache. <ng0>how can I execute the patch-shebang script for a repository? curl uses /usr/bin/env perl for some tests and I still haven't noted the full power of guix and guile. <ng0>not in a package, but outside of the build system <bavier>ng0: from guile you can call the patch-shebang procedure from (guix build utils) <bavier>brendyn: you can let guile auto-compile, but the guix scripts will be much faster to execute if compiled <dvc`>the new u-boot diffs aren't complete and don't apply to what I already have :/ I hate the reviwer job =P <dvc`>civodul: Do you want to review the patches? xD <zacts>the last I was here was like 0.8 or something <janneke>File tests/Makefile.am is read-only; trying to patch anyway <janneke>if i change (name "hydra") to (name "xhydra") i must type guix build xhydra, guix build hydra does not work anymore <janneke> #:phases (modify-phases %standard-phases <janneke> (replace 'unpack (lambda _ (exit 1))) <janneke>hydra is still unpacked and patch fails <bavier>janneke: patching is part of a separate derivation for the origin <bavier>so removing the unpack phase won't do anything <janneke>wow, thanks!!! i never could have guessed that and was slowly going mad here <janneke>bavier: is there any way to get between unpack and patch? <janneke>or must i provide a fixed download tarball/url myself? <bavier>janneke: I think you'll need to fix the origin <lfam>I'm fixing the openjpeg patches. I'm sorry for sending them to the list in that broken state. I guess I ran out of steam yesterday! <lfam>Okay, I think we need to update openjpeg from 2.1.0 to 2.1.1. There have been lots of changes between the two releases that make it difficult to cherry-pick the commits that fixed the bugs with CVEs. And there are other bugs fixed anyways <lfam>Also, they claim no ABI or API changes between the versions, so it should be safe to do <lfam>If we do that, the difficult thing is handling openjpeg-2.0, which is only used by mupdf <janneke>aaargh...now g++ does not compile hydra-eval-jobs.cc <janneke>i'm terribly confused...how can it be that such important packages FTBFS? <lfam>janneke: Not enough people paying attention, I'd guess <bavier>janneke: yeah, hydra has been neglected lately <lfam>It *is* a pretty important package for us, at least until we can build the distro with Cuirass <lfam>What would we do if we lost hydra.gnu.org? Could we get back up and running? Or would we have to spend a lot of time fixing the Hydra package? <lfam>I guess we could always try building it from an older Git commit <lfam>This is something I like about acme-client, the "dangerous because it's written in C" tool for getting certs from Let's Encrypt: it is very easy to build and all the dependencies are maintained. <lfam>The same cannot be said for certbot <lfam>Okay, I think there is no reason to keep this openjpeg-2.0 around for mupdf. It seems that many distros are building mupdf against openjpeg-2.1 <lfam>Even with old versions of mupdf <lfam>Goddamnit. Why would you go to the trouble of patching bundled copies of a library instead of just changing your own code?! <lfam>ACTION rants against mupdf <lfam>Do they even issue new releases when bugs are publicized in the libraries they bundle? <lfam>Yeah, I know. Got to get a good rant in if I'm going to make my fingers bleed dealing with it :) <lfam>Good grief. They bundle curl, freetype, glfw, harfbuzz, jbig2dec, jpeg, mujs, openjpeg, and zlib. <lfam>Can't miss an opportunity to hang your users out to dry <lfam>At least mujs is "their" thing <janneke>Unrecognized character \\x7F; marked by <-- HERE after <-- HERE near column 1 at /gnu/store/ykzwykkvr2c80rw4l1qh3mvfdkl7jibi-bash-4.3.42/bin/bash line 1. <janneke>phase `check' failed after 0.9 seconds <janneke>yay, almost build ancient version of hydra... <lfam>I want to make a blog post about mupdf, detailing every CVE they ship that is fixed upstream. <bavier>janneke: newer versions of hydra may not be compatible with guix <janneke>bavier: that's part of my questions... <bavier>ISTR civodul mentioning they've made changes that only nix's daemon supports <janneke>i found that the `nix' package in guix is too old for building current hydra <janneke>but now i also found that our `nix' package is too new for building our hydra package <janneke>terribly confusing, not sure how nix+guix relate <lfam>Heh, another rebuttal to "Guix is just a wrapper around Nix" <davexunit>yeah civodul has said in the past that hydra is pretty screwed <janneke>if i add #:tests? #f to hydra's arguments, it still fails <janneke>phase `check' failed after 0.9 seconds <lfam>So much sympathy for you right now... this sounds like a nightmare <janneke>thank you...it's like i'm fighting ghosts <lfam>Anyways, guess I'll resolve that bug today <ng0>i looked at todoist, used it for a while, it doesn't work for me. <lfam>ACTION `touch gnu/packages/javascript.scm` <janneke>latest hydra.git does not build with newest nix-1.11.4 release <janneke>no sensible info in hydra.git/INSTALL or README <lfam>Maybe they can help on #nixos? <lfam>Surely somebody there knows how to build it <lfam>Suggesting that people use your bundled fork because your changes haven't made it upstream yet is like suggesting that one skips tests because they are failing <lfam>Okay, I applied the extremely trivial solution that bug report, and can build the latest mupdf against openjpeg-2.1.1 while using the bundled mujs <dvc`>does anyone know the status of cuirass? <dvc`>where the gsoc goals met? <lfam>My understanding is that it does build things. <janneke>nixos is silent, google however says <janneke>`You have to use NixUnstable or go a few Hydra commits back.' <mark_weaver>janneke: I can think of two reasons hy #:tests? #f might fail: (1) you mispelled the keyword, maybe missing the '?' or the 's', or (2) there's a custom 'check' phase that doesn't honor that argument. <janneke>mark_weaver: exactly... i tried removing the `?' and then guix errors out <janneke>i don't see anything special in the hydra package... <dvc`>janneke: Are you trying to update the package? Why aren't you keeping the working version for now? Or am I missunderstanding? <janneke>dvc`: there is no working version... <dvc`>oh, so what's running on gnu's hydra? <lfam>janneke: Skimming the package, I wonder what the effect of '#:tests? #f' is when there is a pre-check phase? <lfam>janneke: There is a phase 'check-setup' that happens before check. If you skip check, what happens to that phase? <lfam>Did you try commenting it out? <janneke>ugh, newer hydra needs pqxx which we do not yet have <mark_weaver>lfam, janneke: the 'pre-check' phase should have no effect on this. The default 'check' phase is still there when you pass #:tests #f, it just does nothing in that case. <mark_weaver>see the 'check' procedure in guix/build/gnu-build-system.scm, which is the default 'check' phase for that build system. <mark_weaver>janneke: are you still using gnu-build-system for that package? <mark_weaver>janneke: can you show me the hydra package recipe that's failing it's 'check' phase despite #:tests? #f ? <lfam>So, if you compare the mujs that is bundled in mupdf-1.9a using a Git submodule with the mujs from its own Git repo, using what are apparently the same commits, there are differences in the code <janneke>mark_weaver: thanks! but luckily/weirdly: no I cannot <janneke>i checked-out my commit marked: aaargh #:tests? #f still: phase `check' failed after 0.9 seconds <janneke>ACTION is weirdly confused...but i've now got at least one version of hydra building <lfam>It seems that the Git tag of mupdf-1.9a is not the same as what was released as the 1.9a tarball <lfam>I think we should just use the bundled mujs for now. Mupdf and mujs are from the same development team, and there are no releases of mujs. <mark_weaver>if we don't have anything else that uses mujs, that sounds okay <lfam>And, I will relax for a while and then make a bug report to mupdf pointing out this tag / release mismatch <lfam>Instead the answer was "use our bundled fork" <lfam>Or perhaps not. The commit came later. <janneke>ACTION got 2 versions of hydra built...fwiw <janneke>will send WIP-patch with summary for requests to the ml <lfam>Summary for requests? Sure, I have lots of requests ;) <janneke>either nix package needs to be downgraded <janneke>or hydra needs to be upgraded...but not too new, and nix upgraded too <lfam>In general, I think it's better to go forward <janneke>and we need libpgxx ... not sure what that means: does hydra now depend on postgres..etc? <janneke>oh, and tests still fail; ah... possibly yet another perl package <janneke>STDERR: Can't locate Net/Statsd.pm in @INC (you may need to install the Net::Statsd module <lfam>I guess like all the other Perl CPAN modules? I would try the CPAN importer <lfam>I just sent my mupdf patch to the list. Hoping for reviews on this and openjpeg soon :) <ng0>I made the opensmtpd-extras package grow in lines of code... i don't know if you would be okay with not removing postgres+mariadb and splitting them to individual outputs... I mean we want it to be featureful..? <lfam>ng0: I myself wondered why it used two different SQL databases. If it can use them both, then I think it's fine to include them. It's true that we want our packages to be full-featured <ng0>no, it does not use them. you have the option to use it.. <ng0>i have no possibility at the moment to test it.. I think debian splits most of the -extras off to single packages. i think it should be split. if you use one sql db most of the time you use no other. but maybe you have n different hosts and on one you you a different sql db, so you don't want mariadb but postgresql.. <ng0>otoh this added 60 lines or more <janneke>hydra builds, finally. not sure if it runs or is useful... <bavier>janneke: thanks for giving it attention <lfam>We should have a buildable hydra on the master branch <janneke>lfam: sent a patch with rough edges to -devel <civodul>woow, quite an achievement, thanks janneke! <janneke>tnx, i hope it helps...i'll try to run it tomorrow ;-)