IRC channel logs


back to list of logs

<karhunguixi>success! :)
<karhunguixi>..and there was much rejoice
<karhunguixi>the enter passphrase step is covered in some unrelated log statements, more now than earlier. But it's ok.
<mark_weaver>karhunguixi: we'll clean that up at some point
<civodul>Hello Guix!
<civodul>mark_weaver: victory! (?)
<mark_weaver>civodul: oooh, excellent! thanks for debugging it :)
<civodul>this was terrible
<civodul>now i think if i should apply the patch right now in Guix or wait for feedback
<civodul>the problem being that we have security fixes waiting in core-updates
<rekado>ACTION is wondering why python2-ipython doesn't build.
<mark_weaver>civodul: I think you should just apply your patch to core-updates asap.
<mark_weaver>actually, I don't see the patch in your comment, but maybe that's because I'm using emacs-eww, dunno.
<rekado>mark_weaver: it's attached in the following comment.
<civodul>yeah it's a weird interface
<mark_weaver>ah, thanks. when I loaded the page, it wasn't yet there. I needed to reload the page.
<civodul>"it's 2015", as some might say, and we're still writing bugs of that kind
<davexunit>every time I see someone start a new project in C, I scream internally.
<civodul>this one is a combo: pointer arith + numerical overflow
<mark_weaver>it's very difficult to do arithmetic in C without risking overflow bugs. to my mind, it's insane that we're using languages that don't have built in overflow checks.
<mark_weaver>(especially since C provides no way to do it that's both efficient and portable)
<civodul>i guess one could build with -fsomething
<civodul>but then there are Performance Issues™
<mark_weaver>almost(?) every machine architecture provides an efficient way to check for overflow, but C doesn't make that available.
<mark_weaver>and to make matters worse, modern C compilers actually *removes* overflow checks in many cases.
<mark_weaver>(if you check for overflow after the operation instead of before)
<rekado>ACTION found out why python2-ipython fails; will push a fix.
<civodul>mark_weaver: i'll reevaluate core-updates and cancel obsolete jobs, ok?
<mark_weaver>civodul: okay
<mark_weaver>civodul: I'm assuming that your patch is correct, although it's far from obvious to me.
<mark_weaver>civodul: btw, what's your method for cancelling obsolete jobs?
<mark_weaver>I have an SQL command that I use for that, but maybe you have a better way?
<civodul>there's a menu entry somewhere
<civodul>under "Admin"
<civodul>"Cancel all non-current jobs" or something
<mark_weaver>oh, well that just cancels all jobs in an evaluation
<mark_weaver>I have a better way
<civodul>tell me :-)
<mark_weaver>I've been thinking of adding it to the menu.
<mark_weaver>it cancels all jobs in a particular jobset that aren't including in a particular evaluation.
<civodul>oh, i thought that that was roughly what the "Cancel all non-current builds" item would do?
<mark_weaver>so it avoids cancelling jobs that are unchanged.
<mark_weaver>civodul: no, that menu items cancels all non-active jobs in the current evaluation.
<civodul>well i can use your method
<mark_weaver>give me a minute, I'll paste the command.
<mark_weaver>here's the one I used last time: update builds set finished=1, iscachedbuild=0, buildStatus=4, starttime=1442724293, stoptime=1442724293 where finished=0 and busy=0 and jobset='core-updates' and id not in (select build from jobsetevalmembers where eval = 107038);
<mark_weaver>those big numbers are the result of running "date -u +%s" on hydra
<mark_weaver>and of course, you use the appropriate evaluation id
<mark_weaver>some of that is based on looking at the code in hydra's web interface for cancelling jobs, but with modifications.
<mark_weaver>it's in the readline history for 'psql' on hydra. I search for it via "C-r iscached"
<mark_weaver>civodul: ^^
<mark_weaver>someone who knows more about postgresql could probably write a better query. my knowledge of postgresql is weak, and my knowledge of relational databases is also quite rusty. suggestions welcome!
<mark_weaver>and of course, the evaluation id is the newest one, the one whose jobs you want to keep.
<civodul>mark_weaver: oh, it's not trivial :-)
<mark_weaver>if you'd prefer, I can do it.
<civodul>mark_weaver: yes if that's fine with you
<civodul>currently the evaluator is still... evaluating
<civodul>and i've stopped hydra-queue-runner
<mark_weaver>civodul: sounds good, I've been doing that as well. the evaluations go much faster that way.
<umbilical>not long ago I failed miserably in installing guixSD, easy as it is
<umbilical>I want to give it another go so, here's what happened, maybe one of you could help me, somehow
<umbilical>I used fdisk and put a gpt label, did some stuff I can't remember exactly, but anyway I got through the installation without problems, exit status 0 and all
<umbilical>but then on boot it stopped at grub. I remember I even used install-grub I think was the name, and it exited properly too...
<umbilical>any ideas?
<civodul>umbilical: i guess we'd need more details on what failed
<civodul>if you give it another try, please chime in and post the exact error messages or whatever you get
<umbilical>I'll do that, thanks
<civodul>status update on Debian reproducible builds:
<umbilical>I'm wondering if it is safe for everyday use though
<umbilical>wherein I don't really have any critical data or uptime needs
<davexunit>umbilical: it's very stable in the sense that bad upgrades can be immediately rolled back.
<civodul>umbilical: also see for the main limitations
<umbilical>erm, I'm partitioning with fdisk -t dos , which I did last time
<umbilical>good or bad idea?
<paroneayea>civodul: reproducibility in debian is good for guix :)
<paroneayea>the more packages are ensured to actually be reproducible....
<civodul>yes, definitely
<umbilical>aight I have a partition scheme pretty close to what I did last time, care to check it plz?
<civodul>ok, that should work
<civodul>ACTION has to leave
<davexunit>civodul: would love to be able to calculate the percentage of reproducible builds like Debian can.
<civodul>davexunit: yes, i think we'll develop tools for that
<umbilical>so... it's good to go?
<davexunit>umbilical: only way to know is to try :)
<umbilical>:D also, should I mkfs.ext4 on the /boot partition?
***davi_ is now known as Guest48427
<davexunit>partitions need file systems, yes.
<umbilical>so ext4 is good for /boot?
<davexunit>that's up to you.
<davexunit>I use a single ext4 parition, no separate /boot
<umbilical>sorry for the n00bness just.. well... I am a noob and the tutorials online are all gui oriented
<davexunit>it's okay.
<davexunit>no worries.
<davexunit>I don't know a lot about file systems and partitioning
<davexunit>just enough to setup my computers successfully
<umbilical>I know less than that ;)
<umbilical>aight wish me luck
<davexunit>umbilical: using a single partition may be easier to start with. adding additional partitions complicates things.
<umbilical>so, cram everything into /dev/sda1?
<davexunit>and a small partition for swap space.
<davexunit>you should just give it a try as you have it, but if things fail and are hard to figure out, try simplifying your partition configuration.
<umbilical>yeah that's the plan
<umbilical>it's gonna take a while tho, I'll get my groceries, come home to a blown up computer
<umbilical>seeya later
<davexunit>ACTION really likes that Minetest now has working sound
<paroneayea>we really need community stewardship'able server deployments
<davexunit>paroneayea: I wish the server wasn't so hard to actually package.
<davexunit>having a '' in guix would be great
<davexunit>just like a 'mediagoblin-service' would be :)
<davexunit>still need to attempt to make a mediagoblin package again
<davexunit>we can't be thaaat far off.
<paroneayea>I wonder how hard it would be to make a stripped down mediagoblin theme
<paroneayea>that doesn't require jquery
<paroneayea>you couldn't use it for video, though
<davexunit>paroneayea: I'm all for just bundling javascript libraries (unminified) in the repository until things are more sane.
<davexunit>if/when I get 'guix web' in ship shape, that's my plan.
<umbilical>I'm back
<umbilical>the install (almost) finished. after 'populating /mnt' it
<umbilical>oooh i f**ed up
<davexunit>unrelated, but minetest's new website looks quite nice
<paroneayea>davexunit: will that be okay from a guix policy perspective?
<paroneayea>davexunit: ooh yeah it does
<davexunit>paroneayea: yes, I think so.
<davexunit>not ideal, but it works.
<umbilical>um... grub-install /dev/sda throws an error:
<umbilical>Path '/boot/grub' is not readable by GRUB on boot. Installation is impossible
<umbilical>what do?
<davexunit>not sure. try searching for that grub error and what people do to solve it
<davexunit>I'm not sure what it means because I don't know much about grub
<serhart>umbilical, try and see if the boot flag is set on your partition
<serhart>ah, nm, I don't think that is your issue
<umbilical>it was
<umbilical>anyway I couldnt find any solution, and I was stupid on the first place for forgetting to change sdX in the config file, so it didn't automate whatever I'd then have to do. So I'm starting over with a single partition as you suggested, for simplicity and making sure I now changed the sdX to sda
***davi_ is now known as Guest94469
<jaccas>hi :)
<codemac>ooh cool. so I'm running arch as my root distro and guix as a "per user" distro if you will, and arch just updated to and none of my guix stuff broke
<codemac>functional package management has wins all over the place.