<civodul>there's this wpa-supplicant update posted on Thursday, i wonder if all the CVEs are really fixed in the new version <civodul>lfam: looks like we both applied the sane-backends patch just now :-) <lfam>civodul: I checked the wpa-supplicant Git repo to make sure each patch was in the 2.6 release tag <lfam>Does anyone know who maintains sneek? <lfam>I think they need to have a word with sneek about this prolonged absence! ;) <tg>rekado: i saw you were working on an axoloti-patcher pkg, did you managed to get it working? have you published it anywhere? <fr33domlover>I'm installing Guix on my system (currently Trisquel 7, will hopefully replace it later with GuixSD) <fr33domlover>The "start guix-daemon" step is taking forever - is this normal? <fr33domlover>I'm on a x60 laptop so I suppose things can be somewhat slow, dunno <davexunit_>fr33domlover: 'guix-daemon' is, well, a daemon. it's not going to exit. <fr33domlover>davexunit_, i suppose i'm used to `service foo start` which does exit <fr33domlover>the manual says hydra.gnu.org or mirrors - are there mirrors? <fr33domlover>i suppose i should prefer the one closest geographically, if there are really several of them <fr33domlover>Not critical I suppose, things seem to be working. But I get this on the terminal when I run guix commands: guix warning: failed to install locale: Invalid argument <davexunit_>you shouldn't need to specify substitute urls as the daemon defaults to mirror.hydra.gnu.org <rekado>tg: yes, I’m using the Axoloti patcher successfully. Part of it (the cross-compiler toolchain) is already in Guix upstream. <rekado>tg: I haven’t yet published the patcher package itself, because it depends on pre-built Java jars. <rekado>tg: there are instructions how to make your Guix find it. You only need to add the “libre” directory to your GUIX_PACKAGE_PATH. <rekado>tg: if you are on GuixSD you will also need a udev rule in your system configuration to talk to the Axoloti board with the patcher. <rekado>ACTION is now subscribed to oss-security <efraim>I subscribed last night, still have to change my filters to put it in the right folder <efraim>from the logs of compiling gcj last night: echo timestamp > doc/gcc.1 <efraim>165 total 'timestamp's from grepping the log <rekado>efraim: does it echo them each time? Some build systems do something fancy with timestamps to assist make in performing tasks in order. <efraim>grep echo\\ timestamp gave the same 165 <efraim>i should boot up my netbook again, when I first made the aarch bootstrap binaries I think it was gcc and guile that were non-deterministic <efraim>since I made them twice for some reason <efraim>laby from games.scm broke the github updater ***tschwing_ is now known as tschwinge
***htgoebel1 is now known as hgoebel
***hgoebel is now known as htgoebel
<htgoebel>Within a function in python-build-system: Can I refer to the python version used *without* passing "inputs"? <htgoebel>My current function definition is "(site-packages outputs inputs)" and I would like to get rid of the "inputs" :-) <htgoebel>Side question: Which parameter order is to be prefered: "inputs outputs" or "outputs inputs" <efraim>does your new python-build-system take into account not having python2-setuptools when building python2-setuptools? ***specing_ is now known as specing
<htgoebel>civodul: Should spell-checking follow British or American English? Which dictionary to use? <efraim>I think we mostly use American english <efraim>Well that's certainly convenient for python, I hadn't known that before <civodul>htgoebel: yeah i do en_US, but not everyone does <civodul>so en_US if that's fine with you, but no big deal <Dawgmatix>Am trying to use guixsd in qemu but cannot get network connectivity to work. dhclient eth0 fails with a message saying no DHCP offers received <Dawgmatix>Only change I had to make was that I had to drop the "-net default" flag, since that appears to not be supported <ng0>rekado: thanks for the axoloti links and work on it. I've been talking with tg about music yesterday.. reflected a bit and decided I need to pick up my dormant music project again and start now elsewhere, explore electronics and generated/coded music etc.. <ng0>I'll package some of the applications (like supercollider) in the next time for myself.. will throw them to the list <jmd>Dawgmatix: Do you have a dhcp server on that network? <ng0>I'm also sorry in advance for this, I'll have to more or less revert the mailmap patch.. did some calculations and reasoning (about domain/hosting related stuff) with myself and in the longrun I'll be more flexible when I keep the n0.is domain .. so I'll send a patch today for this <ng0>and before I start.. no one happens to be working on supercollider package currently? <ng0>so I some some experiments... and I think our primary web browsers (epiphany, icecat) lack whatever is needed to log into gnusocial. So far I could only log in using reset password links. <ng0>the other theory is that gnusocial has problems in the login form. so far it's just me, so i don't know if this is just introduced by mistakes I do. this is without librejs (deactived) <rekado>civodul: I pushed a patch to core-updates to fix the build of tcsh, whose failure is responsible for many of the failures on core-updates. Should we start a new evaluation? (Or will this be picked up automatically?) <civodul>rekado: yes, you can go ahead and start a new evaulation <civodul>there's no periodic evaluation of that branch <rekado>I don’t know how to start a new evaluation :) <civodul>how do people pronounce "tcsh"? like "teeksh"? <rekado>civodul: a new evaluation has been scheduled <jmd>How long does it take for hydra to reevalute the whole of core-updates? <wingo>civodul: regarding rebuilds and cups-filters there is one more patch <wingo>so there are patches 1,2,3, and 3 is the service patch <wingo>1 and 2 apply to cups-filters <wingo>and i just sent an update for (1) <wingo>i was patching configure.ac when i needed to patch configure; with that, test pages should work. anyway. as long as we are rebuilding the world we should push the newest version of that first patch too :) <ng0>uhmm... I think when I tried to move my sdf.org account and after 3 weeks when nothing happened and previous communication failed and I opened a complaint at paypal, I think sdf.org might've just dropped my account.. or it's just the server right now. but the one font we hosted there, you might want to check up on that <ng0>Starting download of /gnu/store/8c9cqgm2d2yn03vqbkbgl0dz3g3v6ydd-font-un-1.0.2-080608.tar.gz <ng0>what the...? is this a mature way.. or any way to solve a question of payment? wow <ng0>so.. font-un is now broken and I will certainly not use sdf.org anymore until paypal reverts the payment. or anymore afterwards. so much for "lifelong" membership... does someone have a server to host this font at? upstream is still broken, and I won't have a server for some months <ng0>just logged in, yup the canceled this lifelong account. haha... <ng0>it's not just deactived, they just erased it. so if I would have had any personal data on there the raging admin would've just destroyed it. <Dawgmatix>Figured the dhcp issue out, on an ubuntu system it appears that you are better off not specifying -net directives to qemu <Dawgmatix>If I drop the -net directives, the ethernet interface changes from eth0 to ens3 and can indeed get an ip address <Dawgmatix>Any pointers on best way to achieve the following -> i would like to build a custom kernel, and i would like to build gcc from trunk <rekado>Dawgmatix: to build GCC with different sources it's easiest to inherit from the existing "gcc" package using (inherit gcc) <rekado>Dawgmatix: then override the source field and add native inputs to generate the configure script. <jmd>Why is it called /gnu/store and not /gnu-store ? <civodul>wingo: oooh, sorry for overlooking that, i'll apply the new patch then <ng0>their way of moving accounts is unlike what they document in public. also, font-un got an update, maybe the mirror can be dropped.. I'll see it with the update <ng0>oh, it's just the timestamps. <ng0>when wget can download the file without problems.. this should mean guix download will not experience mime problems...? <ng0>it works.. another bug which can be closed :) <ng0>I see if I manage to send it before I have to catch the bus <efraim>big suprise, obs FTBFS on arm and mips <efraim>debian only builds it for amd64 and x32 <efraim>rekado: civodul: on the hydra web interface some of the packages are still listed as failing because they rely on a failing tcsh, like abcde <civodul>ACTION clicks on "Restart all dependency failed builds" <efraim>who other than debian and gentoo support multiple "exotic" hardware platforms? <civodul>they have a PowerPC port funded by IBM, IIRC <lfam>My understanding of the analysis given by upstream is the impact of this bug is mostly mitigated in the version of dbus we package, but I'd appreciate it if someone else would read that message and the linked bug report <rekado>lfam: I read the message and understood that our version is not affected. <lfam>I'll send an update patch for core-updates. We can take it or leave it but at least the patch will be available <efraim>i have perl-module-build on core-updates building successfully atm <lfam>rekado: To clarify, I think our version does have the format string problem, but only the owner of the bus can pass formatted strings to the vulnerable code. So only root can trigger the bug in our version, which is undesirable but not really a big issue. That assumes that upstream's analysis is correct and that only the bus owner can pass formatted strings to the broken code <lfam>Fixed in: dbus >= 1.11.6, 1.10.x >= 1.10.12 [...] <efraim>it lists local-users as those that can cause the problems <efraim>pushed the perl-module-build update to core-updates <lfam>Nice, building the new dbus on core-updates will use substitutes for everything :) <lfam>Yeah, looks like the wrong hash <lfam>Checking with upstreams sha256sum file, the hash I calculate matches what Hydra says it gets. <lfam>05xcwvy68p7f4hdhi4bgdm3aycvqqr4pr5kkkr8ba91l5yx0k9l3 <lfam>newt is weird. That hasn't been updated in over 1 year, correct? <efraim>i don't have a saved tarball for gtk <efraim>don't know, but I do know fedora does a full rebuild of all their packages for each release <efraim>don't know if they overwrite their source tarballs <lfam>Can you fix the gtk+ hash and mention it on guix-devel? I will look into newt. <lfam>That would be... perverse <lfam>I guess we could use that, but seeing all the historical tarballs changed makes me wonder if the site was compromised <lfam>Do we not have the old tarball anymore? <efraim>never thought I'd have to horde old tarballs <efraim>speaking of which, debian hordes old tarballs <efraim>nvm, debian has a different hash than both <lfam>I tried to use Debian to replicate a tarball once before, and they had repacked it with new file ownership and timestamps, so it wasn't helpful <lfam>I wonder if they do that for every tarball <efraim>i don't know, but once they repack it i think its good forever <lfam>BTW, there's a new release of nmap that doesn't build. Maybe someone is interested in working on updating it :) <efraim>i am having a hard time staying focused looking at the software section of archive.org <lfam>I've contacted the email address that is authoring the Newt Git repo to ask for clarification regarding the tarballs <efraim>wayback machine doesn't have a cached copy of the gtk tarball <lfam>efraim: Does Hydra show that the gtk tarball was every downloaded successfully? Maybe the commit that updated it made a mistake <efraim>it must've downloaded it to have built it in the past <lfam>But, did it build it yet? <lfam>You could ask iyzsong. Maybe they built it and can help clarify? <efraim>looks like it was pushed directly to core-updates back in august <lfam>Right, so it's possible that hydra hasn't tried to build it until now <lfam>I guess I'll just replicate it locally. Can't load the Hydra web page right now <lfam>Hm, probably faster to wait for hydra. Building lz4 and valgrind takes a while <efraim>borg failure looks like a no-test-suite failure <efraim>i also checked gtk+-3.20.[39].tar.xz, hash didn't match those either <lfam>A no-test-suite failure? <lfam>Sounds like you have the page open. Can you share the link? <lfam>Never mind, Hydra is responding for me again <lfam>That's a weird error: "setup.py: error: argument <command>: invalid choice: 'test' (choose from 'serve', 'init', 'check', [...]" <lfam>Those are options for borg itself <lfam>I'll debug it and ask for help upstream if necessary <rekado>lfam: thanks! (Sorry, didn’t see your messages.) <lfam>No worries :) I think we have to take turns loading build logs on Hydra ;) <efraim>as expected libx11 built just fine, false failure on hydra ***LnL7 is now known as LnL
<lfam>I notice that the mirror is not serving some things. Building borg is much less expensive when I use Hydra directly <efraim>cve-2016-857[678] incoming soon-ish for qemu <rekado>efraim: thanks for taking care of this! <efraim>Signed-off-by: Gerd Hoffmann <address@hidden> <paroneayea>I mean, we do plan to use signatures to have a "trustable" guix pull and etc <paroneayea>but I'm not sure how we could leave this automated for building systems <rekado>civodul: and thanks for 7c515a43b0f2c! <rekado>htgoebel: I just rediscovered your patches to improve the ant-build-system and to add a few of the java commons packages. I’m working on them in the next couple of days. <lfam>rekado, htgoebel: I'm glad to hear that! I was wondering if I was going to have to review them myself ;) <lfam>Hm, turns out we weren't running the Borg test suite. Older python versions did not report an error if `python setup.py test` did not find a test suite, but python@3.5 does. So we see the problem now on core-updates. <civodul>wingo: re cups-filter, it's enough to patch 'configure' and not 'configure.ac', right? <lfam>Luckily for us, the person maintaining the Nix Borg package is nckx :) <lfam>So we have some knowledge floating around <nckx>lfam: errrr... maintainer on de-facto hiatus at the moment, but sure. <lfam>nckx: On core-updates, with python@3.5, we realized that we weren't actually running the borg test suite. Master's python@3.4 doesn't return an error if `python setup.py test` finds no tests, but python@3.5 does. <lfam>So now I am working on making those tests run and pass <lfam>I'm not stuck yet, but I will try picking your brain if I do get stuck <lfam>Looks like we need to invoke the tests with `tox` and add some dependencies <lfam>I bet we get a lot of failing packages due to this issue. I noticed it when I was working on the wip-python branch. I want to pick that branch back up after the new release.