<mb[m]1>I was checking if `git format-patch` could automatically add a link to the upstream gitweb interface. It can call `git-notes`, but those can apparently only store static text, i.e. not refer to the current object. ***pksadiq_ is now known as pksadiq
***pksadiq_ is now known as pksadiq
<brendyn>does changing an input to a propagated-input make any difference when the package is being built <brendyn>Anyone familiar with Perl? I'm packaging File::Mimeinfo but it's failing to find it's own sub module Filee::Mimeinfo::Magic. <brendyn>It searches in the perl package for it instead of it's own package, for some reason <DusXMT>rekado: Yes, I am indeed running guix from a git checkout <DusXMT>ACTION should probably just get a virtual machine for running guixsd <DusXMT>(instead of trying to run it on a different distribution) <brendyn>I think it's good to have people testing on on different distributions <DusXMT>Okay, an `autoreconf -vfi && ./configure --prefix= && make' later, and it works :) <DusXMT>ACTION thought make by itself was enough, as it seemed to update the automake files <rekado>brendyn: maybe try adding the current directory to PERL5LIB <brendyn>rekado: I just tried that, but it turns out moving a few inputs to propagated-inputs fixed it. propagated-inputs is still something that I find confusing <efraim>sneek: later tell lfam: utox got check as an input, should it be a native-input? <rekado>propagation only affects dependent packages <rekado>Perl, Ruby, Python, R, Guile, etc – they all have a search path where they look for packages by name. <rekado>they don’t retain full references to their dependencies <brendyn>i moved an input to propagated inputs, and the result was the package contained this extra .packlist file <rekado>so we use propagation to make sure that their dependencies are installed alongside the package itself <efraim>all the qt 5.9.3 modules almost done building! <ng0>*attempt - not attemot <efraim>Of course other than the Mali graphics and the 1GB of RAM <amz3>git://git.savannah.gnu.org/guix.git <CharlieBrown>amz3: I guess what Im asking is... Is the Guix src different from the GuixSD source? <rekado>parts of Guix are only used on GuixSD, but it’s all in the same repository <brendyn>ok now for some reason mimeopen works fine when i call it in the terminal, but when xdg-open calls it, it fails to find it's submodule (only searches the perl package, not it's own directories) ***pksadiq_ is now known as pksadiq
<roptat_>rekado: did you stop reviewing my patches because you're waiting for something from me? <iyzsong>yeah, i'm just hide in the corner... <apteryx>The progress is reporting 0.0% for every downloaded substitutes. Is there still a bug there? <rekado>roptat_: are yours the java patches? <rekado>I just didn’t get around to continuing the review. <rekado>ACTION is currently sitting in a noisy, hot, stinky data centre to fix a couple of broken servers <rekado>apteryx: what substitute server are you using? <civodul>rekado: and it's so comfortable that you had the idea to chat a bit while sitting there? :-) <rekado>I’m waiting for a progress bar to creep to the right. <rekado>I replaced two of the build hosts for berlin. One of them just died and the other signalled CPU errors. <civodul>we still lack a monitoring tool on these <rekado>the dead one had no blinking LEDs, of course. Just dark. <civodul>until we have a Nagios service or something, you could leave a webcam in front of the rack :-) <rekado>it will take a little longer to set up the new head node <rekado>I’d like to add a second server for fail-over. <rekado>I’m rebuilding the systems for all build hosts from berlin using install-berlin.scm <rekado>oh, it’s a Guile script on berlin. <rekado>it generates os configs for numbered nodes, builds them, and then copies them to the target. <rekado>remote reconfiguration doesn’t work yet, so I need to do that manually on the remote. <civodul>right, we really need 'guix system reconfigure --remote' <rekado>I’m reluctant to enable root login over ssh <civodul>it's weird, i feel like i have to work on the more urgent things like 'guix pull' <rekado>I prefer the ansible way of specifying a sudo user, and then prompt for a password on the remote. <rekado>re guix pull: do you have something I could test? <rekado>I really appreciate your work on this! <rekado>I find it hard to wrap my head around the problems surrounding guix pull <civodul>it boils down to making sure the running Guix can "jump" into the new Guix <DusXMT>An interesting thing I found when a derp-up caused substitutes to no longer work for me: tar's test suite fails on btrfs :) <civodul>for instance we want to use (gnu packages ...) from the new checkout <civodul>DusXMT: many things fail on Btrfs... <stefanc_diff>DusXMT, if you can move away from btrfs because it still has rough edges. <DusXMT>stefanc_diff: I like checksums and automatic data redundancy :) <stefanc_diff>a power cut(laptop running out of power) for example could result in an inconsistent filesystem <roptat_>rekado: yes, the java patches. ok I'll wait the rest of your review :) <rekado>roptat_: sorry about the delay. Maybe tomorrow I can resume. <DusXMT>(also, most of the time I'm on a laptop, which's battery sort of serves as a UPS) <stefanc_diff>play with btrfs as you wish DusXMT , I was pointing out that a trivial thing could cause major headaches. <DusXMT>I'm aware of the risks, but I'm also aware of the benefits :) <stefanc_diff>I've just fixed someone else's laptop running btrfs last weekend , inconsistent btrfs journal <rekado>mb[m]1: your glibc patches mail bounced because it is too large. <DusXMT>Speaking of backups, I just updated my backup :) (so even if my computer completely fails and falls apart, at most I'll lose a week of work (annoying, but not disastrous), and the time putting the thing back together) <brendyn>I'm still stuck on this issue with a perl program not being able to find it's submodules. I saw on the mailing list someone made a perl wrapper but it's not in master. What ever happened to that? <mb[m]1>rekado: ugh, thanks for the heads-up. Strange that debbugs didn't let me know. <rekado>brendyn: what perl wrapper do you mean? <mb[m]1>The patch is 30k lines, so probably 1-200k in size. Can try compressing it later. <rekado>brendyn: what’s on PERL5LIB? Are the directories for the dependencies all listed there? <rekado>wrappers are used for applications, not for modules or libraries. <brendyn>nothing is in PERL5LIB. if is set it manually it will work but shouldn't it work automatically? <rekado>for an application you need to add a phase that wraps the executables in PERL5LIb <rekado>we do this in a couple of packages. Just search for “wrap-prog” <brendyn>this module comes with an cli "application" with it <brendyn>ok so since im adding a perl dep to xdg-utils, i need to add a wrapper script to xdg-utils <rekado>the mount tool changes the PATH so “cat” and “sed” are not found. Causes the mount script to fail. <civodul>rekado: 'mount' from util-linux, or mount.glusterfs or whatever it's called? <civodul>mb[m]1: thinking about it, it's a case where it's tempting to grab a generated tarball <civodul>esp. since the glibc repo includes the Autoconf byproducts <brendyn>But I can also just install perl-file-mimeinfo directly and use mimeopen, so that needs either native-search-paths or a wrapper too. if i wrap it, then i might be able to about wrapping xdg-open? <mb[m]1>civodul: that's a good idea. Much better than a 200kB superpatch. <mb[m]1>I'll do that later tonight and push. Also start the "core" job. <brendyn>The annoying thing about wrapping is it changes the name of the programe to .foo-real. when i type `mimeopen' it says Try '.mimeopen-real --help' for more information. <brendyn>and in i3 window manager config, and things like killall, the program name is used <brendyn>is there a better solution? maybe foo -> real/foo would be better <rekado>I already posted a solution to the mailing list <rekado>for many programmes we could prepend a guile script as a wrapper, which calls itself <rekado>wouldn’t work for binaries, though <rekado>but that’s not the only problem. <rekado>it contains many hard-coded paths. <rekado>nixpkgs has a few patches for glusterfs, so I’ll apply those first. <brendyn>i have two binaries on this program to wrap, so i copy-pasted two wrap-progam clauses and it worked, but then i reduced it to a (map (lambda (p) (wrap-program ... and now it errors <civodul>rekado: ok, sounds like it should be tractable <civodul>mb[m]1: there are always the usual risks with gitweb-generated tarballs, though perhaps we can assume they're low <civodul>and as a last resort we can host a mirror on alpha.gnu.org/gnu/guix/mirror <rekado>brendyn: without the error message we can’t help you. <amz3>thanks for accepting guile-wiredtiger <amz3>civodul: I don't see in the package definition how does it deal with the unittests <civodul>amz3: they are disabled, which isn't great <civodul>an oversight of the review process i guess <amz3>I must fix the tests to work, but I need first to do some progress about some other parts <amz3>there is even links in the source <apteryx_>Maybe it could include a ref to a node of the manual which would explain how to troubleshoot and fix those problems? <rsriniva>just downloaded the 0.13 xz file and tried an install on my thinkpad <rsriniva>when i uncompress the xz file, i see a 1.3 GB file ready to be copied to USB, which I did <rekado>rsriniva: are you following the steps in the manual? <rsriniva>however during install, it went out to the intrwebs to fetch and install gazillion packages <rsriniva>my quetion is: what's in the installer? I assumed it will work fully offline and have the packages for the desktop profile? <vagrantc>you *might* be able to do a very bare-bones install without downloading new stuff, but it's pretty much a network installer ... at least, that's been my experience the past couple weeks <rsriniva>what's the split on this channel bw those who run GuixSD baremetal vs running just guix on top of debian or something similar? <rekado>I run GuixSD on ~30 machines; I use it as a package manager on ~100 machines, maybe more. <rekado>but that’s only because Guix can talk to a remote daemon over the network, so the 100+ machines are really just talking to one daemon. <rekado>so I guess I use GuixSD more than Guix + foreign distro. <rsriniva>where can i find a comprehensive desktop config scm file with all the bells and whistles for a typical dev workstation? <rsriniva>a nice starter template that I can further customize rather than use generic ones <rekado>rsriniva: I recommend starting with a simple config for the initial installation. <rekado>it’s easy to reconfigure the system afterward (and roll back in case of errors) <rekado>but for the initial install I’d play it safe. <rekado>there’s an example desktop configuration in the manual <rekado>it’s also part of the installer image <kmicu>stefanc_diff: what kernel version did you have on that laptop? <kmicu>DusXMT: you can safely use btrfs. I do not remember any issues reported on #nixos during last years. No problems on server farms, no problem on personal workstations (unless you are using some outdated kernel). <DusXMT>(the one that comes with debian stretch / devuan ascii) <kmicu>4.9 is LTS so it is good. Bugfixes are backported. <CharlieBrown>need the package that contains */girepository-1.0/Gtk-3.0.typelib