IRC channel logs


back to list of logs

<zacts>hi guix
*davexunit updates ruby to 2.2.2
<davexunit>trivial change, nothing broken, pushing!
<mark_weaver>hmm, I wonder if I move my hard drive from my X60 to my X200, if I could then fairly easily upgrade it to an x86_64 system in place by running something like $(guix build --system=x86_64-linux guix)/bin/guix system reconfigure
*mark_weaver is tempted...
<zacts>did you get a new x200?
<zacts>the last time I asked, you only had an x60
<mark_weaver>well, I've had an X200 for quite a while, but today the fine folks at the FSF liberated it for me.
<zacts>I want to get an x200
<zacts>ah I see
<mark_weaver>okay, time to try it...
*mark_weaver goes afk for a bit...
<davexunit>mark_weaver: good luck!
<mark_weaver>actually, I realize that won't work
<mark_weaver>I need a 64-bit kernel before I can run 64-bit userspace
<mark_weaver>or at least I think it won't work.
<fchmmr><mark_weaver> well, I've had an X200 for quite a while, but today the fine folks at the FSF liberated it for me.
<fchmmr>you were at the FSF today? I was there a few weeks ago, I liked them
<fchmmr>was it nully or marxistvegan who flashed it?
<fchmmr>(nully is the one with blue hair)
<mark_weaver>actually, there were problems, so they ended up giving me another machine that was already successfully flashed
<fchmmr>makes sense. they are all the same
<fchmmr><mark_weaver> I need a 64-bit kernel before I can run 64-bit userspace
<fchmmr>can't you just put one in there?
<fchmmr>then boot that
<mark_weaver>heh, well, it can certainly be done, it's just a matter of whether the 32-bit guix will balk when asked to install a 64-bit system
<fchmmr>mark_weaver, there are also some other machines in libreboot now which are the same chipset as the X200: R400, T400, T500
<fchmmr>I bought an R500 and W500, I'll see if I can get those working.
<fchmmr>(I have them with me now)
<fchmmr>GM45 is a gold mine for the libreboot project. So many machines that Just Work
<mark_weaver><fchmmr> makes sense. they are all the same
<mark_weaver>fchmmr: what are all the same?
<fchmmr>all X200 laptops
<mark_weaver>really? there aren't different processor options?
<fchmmr>well, sure
<fchmmr>most of them have the same CPU, though
<fchmmr>a few have webcam or fingerprint reader, some don't
<mark_weaver>also, my X200 had its screen replaced by the previous owner
<mark_weaver>I think it might have been a screen that was never sold with the X200 to begin with.
<mark_weaver>however, he tried replacing the screen with one that's known to work, and it still didn't work.
<fchmmr>the nice thing about thinkpads is, they are very businessy laptops, so you normally get ones that look new
<mark_weaver>I think they're going to continue working on it
<fchmmr>my R500 looks like it was never used
<fchmmr>they typically come from companies who have lots of them on lease, then they switch over to new systems and chuck out their old ones
<fchmmr>that is, if you're buying used
<davexunit>I like that about thinkpads, too.
<davexunit>they are plentiful and cheap
<mark_weaver>the battery I have for my X200 has much less capacity than the nice one you sent me for my X60.
<fchmmr>the bigger ones are probably locked in a storage cupboard for a few years and used maybe 50 times
<fchmmr>mark_weaver, well, if you recall, I originally sent you one that died after a short time
<fchmmr>then I sent you a replacement battery, twice, until you got one that worked well
<mark_weaver>yes, I'm impressed that you remember!
<fchmmr>I remember everything.
<mark_weaver>heh :)
<fchmmr>My memorization skills are unmatched.
<fchmmr>If someone buys from gluglug and then contacts me on IRC, I also remember their IRC nick forever
<fchmmr>if they contact me again on IRC, I know their real name still :)
<fchmmr>unless they changed their IRC nick, of course
<fchmmr>though, there is 1 person who changed their IRC nick but I saw it happen
<fchmmr>it said "user has changed their nick to <insert nick here>"
<fchmmr>and I remembered that too
<fchmmr>(this is all in my head, of course, not written down)
<fchmmr>Actually..... I mostly ignore IRC nicks these days and don't bother memorizing them
<mark_weaver>I'm jealous. my memory is terrible. I need to augment it with careful records :/
<fchmmr>oh, don't get me wrong
<fchmmr>I also keep meticulous records in everything that I do.
<fchmmr>this chat is being logged, for instance, as are all other channels that I'm in
<mark_weaver>same here
<fchmmr><mark_weaver> the battery I have for my X200 has much less capacity than the nice one you sent me for my X60.
<fchmmr>jxself got an X200 from the FSF at the conference, when the FSF sold them for the workshop
<fchmmr>his battery was about 60% capacity or something like that. he went on newegg and bought a new one
<mark_weaver>fchmmr: I believe I ended up with an X200 that was liberated at LP.
<fchmmr>now he has that 60% one as spare, but uses the new one (100% original capacity, at the moment) as main
<mark_weaver>yeah, I'll probably buy a new one
<fchmmr><mark_weaver> fchmmr: I believe I ended up with an X200 that was liberated at LP.
<fchmmr>one of the workshop ones?
<mark_weaver>I believe so. not sure
<fchmmr>As I recall, a few of those machines didn't have caddies in them, just HDDs
<fchmmr>and the HDDs would come loose
<fchmmr>someone came in on monday (I was there all day monday, volunteering then I caught a flight back to UK), her system wouldn't boot because the HDD came disconnected
<fchmmr>I put a caddy+pads in it and then the HDD no longer became disconnected
<mark_weaver>mv might have used the caddy from my X200. he certainly kept my HDD.
<fchmmr>you know, next time I come to LP I'll bring more spares for things like that
<mark_weaver>fchmmr: btw, it looks like the FSF is going to purchase an ASUS KFSN4-DRE, to verify that it can run without blobs.
<fchmmr>yes, that is the motherboard that you mentioned.
<fchmmr>mark_weaver, it's fam10h
<fchmmr>probably runs blob-free, or can
<fchmmr>let me check coreboot
<mark_weaver>if it can, and it works well, the FSF will probably use it to build their new servers, and I'll use it to build a new build farm for guix
<mark_weaver>and I'd like to help get it officially supported by Libreboot, so that the FSF and Guix would be able to claim that we run our servers on Libreboot.
<fchmmr>mark_weaver, it has native graphics initialization, at least that is what I see according to the Kconfig files
<mark_weaver>well, this is the hope anyway. we'll see how it goes..
<fchmmr>so you might be able to get a visual display on it without a proprietary VBIOS
<fchmmr>and I think it will run without microcode updates
<fchmmr>VBIOS and microcode updates are probably the only 2 blobs that would otherwise be an issue for this machine, so it looks cood
<fchmmr>nully, if that system does work well blob-free, it could easily go in libreboot
<fchmmr>just send me a .config and I'll add it to the build scripts
<fchmmr>I don't see many of those boards available for purchase online, though.
<mark_weaver><mark_weaver> if it can, and it works well, the FSF will probably use it to build their new servers, [...]
<fchmmr>their servers currently don't run coreboot I don't think.
<mark_weaver>well, I'm probably not in a position to say that.
<fchmmr>it's out of stock on newegg
<fchmmr>(not that I'd be able to use newegg anyway, being a UK citizen. unless they export)
<mark_weaver>I've been talking to nully, and I got the impression that was a likely outcome if they work well.
<mark_weaver>but I might be reading between the lines
<fchmmr>it says it supports up to 64GB RAM
<mark_weaver>fchmmr: I think many of their servers are running coreboot already
<mark_weaver>nully offered the Guix project some older servers, 1 generation behind the current servers, and they are already running coreboot.
<fchmmr>I don't think that board is even available for purchase anymore
<fchmmr>I checked several sites, all out of stock.
<fchmmr>there's 1 on, but.... please don't buy it.
<mark_weaver>no, I won't buy from amazon.
<fchmmr>amazon = sweatshop workers
<mark_weaver>I was going to look for them on ebay.
<fchmmr>that board does look cool, though
<fchmmr>Well I did check ebay, but I checked UK one
<fchmmr>US might have it
<fchmmr>what type of flash chip does it use, though?
<fchmmr> dosen't have it
<fchmmr>I think the problem with this board is that the ones that exist are probably all in use and not intended for re-sale, for the most part
<fchmmr>it'll probably be a while
<fchmmr>and it's no longer made
<fchmmr>it's not exactly a commodity item, either
<fchmmr>so there probably weren't nearly as many of these made compared to standard ATX boards
<mark_weaver>I see them available on US ebay
<fchmmr><mark_weaver> and I'd like to help get it officially supported by Libreboot, so that the FSF and Guix would be able to claim that we run our servers on Libreboot.
<fchmmr>yes, I also want server hw in libreboot
<fchmmr> currently does run on libreboot, but on an X60. that's hardly "server hardware"
<fchmmr>My problem is that I wasn't scrolling down
<fchmmr>yes, there are some on US ebay
<fchmmr>I might grab one
<fchmmr>"10 available"
<fchmmr>ok, quite a few more available too
<fchmmr>some also from HK
<fchmmr>quite a lot there, in fact
<fchmmr>PLCC I think
<fchmmr>not SPI
<fchmmr>nully, mark_weaver, you can't use a BBB to flash this, I don't think
<fchmmr>If it's PLCC, there are very expensive ways to flash but, mrnuke was telling me about a cheap way to do it
<fchmmr>"vulture prog" I think it was. I need to probe him for more info about that, I'm interested in getting one myself
<fchmmr>left side of that phote
<fchmmr>below the ethernet jacks
<mark_weaver>with all those GPIO pins, I suspect it could be done with a BBB, possibility with some minimal extra hardware, by someone with some clue of electrical engineering.
<fchmmr>then see those two small chips, in line with the PCI slot
<fchmmr>then look below those
<fchmmr>there is a socket
<mark_weaver>(and possibly easier than that)
<fchmmr>it contains what I believe is the flash chip
<fchmmr>that's a PLCC socket, I think
<fchmmr>mark_weaver, no
<fchmmr>the BBB is for SPI chips
<mark_weaver>umm, I think I know more about EE than you do.
<fchmmr>mark_weaver, yes, you probably do
<mark_weaver>I've built a microcode-based CPU from logic gates, and a memory expansion board for VME bus about 20 years ago
<mark_weaver>BBB is quite versatile.
<fchmmr>mark_weaver, ok, so you are also at least 20 years older than me.
<fchmmr>(I'm 23)
<fchmmr>anyway, check those links
<fchmmr>mrnuke in #coreboot can probably give much better info than me
<mark_weaver>if you have a bunch of GPIO pins, then you can do a lot, possibility with some minimal interface hardware to change electronical characteristics (e.g. voltage)
<mark_weaver>SPI is one thing that the BBB can do, but it can do a lot more...
<fchmmr>(those 2 blog posts are also mrnuke. Alexandru Gagnuic = mrnuke)
<fchmmr>mark_weaver, if you can make plcc flashing a possibility on the BBB, that would be amazing
<fchmmr>right now it's problematic, there aren't a lot of options
<mark_weaver>okay, I'll need to research it...
<mark_weaver>but now I have to go afk for a while. ttyl!
<fchmmr>I probably should sleep at some point.
<fchmmr><davexunit> they are plentiful and cheap
<fchmmr>there's a dell laptop that is a libreboot candidate, it's GM45 like the X200
<fchmmr>that won't just work out of the box though most likely because it's a different manufacturer (EC is the main blocked, I think it also has DDR2 memory)
<fchmmr>Dell Latitude E6400
<fchmmr>yes, DDR2. So, raminit and EC.
<fchmmr>plenty of those laptops online, though
<fchmmr>porting raminit/ec = a lot of work
<fchmmr>(GM45 laptops can be wired for DDR2 or DDR3, but not both)
<fchmmr>(GM45 support in coreboot only does ddr3 at the moment)
<fchmmr>there are actually more of those latitudes available online than the X200, I think
<fchmmr>I think it's worth the effort. It's a very good target for porting to coreboot.
<fchmmr>mark_weaver, I added that board to (ASUS KFSN4-DRE)
<fchmmr>mark_weaver, if nully can get that to work without blobs, it would also mean that libreboot finally supports non-intel hardware.
<fchmmr>right now it only supports intel hardware, which is kind of sad.
<fchmmr>because intel are... the worst
<rekado>I'm having trouble with gi overrides in ibus-pinyin, a module for the pinyin input method in ibus.
<rekado>/libexec/ibus-setup-pinyin won't start; fails with "NotImplementedError: structure type 'GVariant' is not supported yet", which is triggered by an attempt to load the ibus configuration.
<rekado>this looks like some gi/overrides installed by ibus are not found at runtime.
<rekado>I set GI_TYPELIB_PATH to include the ibus paths, but it seems that the overrides are not loaded.
<rekado>(I'm only guessing)
<mark_weaver>jxself: it would be good if you could try compiling packages in guix before pushing them. the linux-4.0 package doesn't build, because one of the patches doesn't apply
<mark_weaver>jxself: see
<mark_weaver>jxself: I'll push a fix soon. it just needs the vblank patch removed, since it has been applied upstream...
<iyzsong>in core-updates, the search-path for python is incorrect, it should be 3.4 instead of 3.3. a lot of rebuild will coming..
<mark_weaver>iyzsong: gah, okay. thanks for noticing!
<mark_weaver>iyzsong: instead of hardcoding the "3.4", could you fix it to use 'version-major+minor' so that this doesn't happen again?
<iyzsong>mark_weaver: ok
<mark_weaver>iyzsong: but please only apply that 'version-major+minor' improvement to the 3.4 package.
<mark_weaver>(not to the 2.7 one)
<mark_weaver>so it would be something like (files (list (string-append "lib/python" (version-major+minor version) "/site-packages")))
<iyzsong>mark_weaver: yes, it works. pushed!
<mark_weaver>iyzsong: thanks!
<mark_weaver>hi civodul!
<mark_weaver>civodul: the second MIPS build slave is online
<mark_weaver>also, I'm afraid that our python-3.4 package had a bad search-path, so we have to rebuild again :-(
<civodul>mark_weaver: excellent!
<mark_weaver>(it had "3.3" in the search path)
<civodul>bah :-(
<civodul>well ok
<mark_weaver>iyzsong: just fixed it.
<civodul>i've a couple of easy fixes that i'll push shortly
<iyzsong>I have some update for gobject-introspection, gtk+, glibmm, etc.
<iyzsong>once tested locally, I can push those to 'core-updates', right?
<mark_weaver>iyzsong: what changes?
<iyzsong>mark_weaver: version bumps
<mark_weaver>we should probably refrain from making unnecessary changes at this point, since they might result in more breakage higher up
<mark_weaver>can these wait until the next cycle?
<mark_weaver>this core-updates cycle is already taking much longer than we'd have wished for.
<iyzsong>I think it's should be ok for a full gnome-3.16 stack. we do have some new, but some old. eg: python-pygobject is still 3.12.2.
<mark_weaver>civodul: thoughts?
<civodul>iyzsong, mark_weaver: i agree with mark_weaver, next cycle
<civodul>let's aim for shorter cycles
<civodul>we should merge core-updates today or so
<mark_weaver>I'm glad to report that armhf is looking very good on current core-updates
<mark_weaver>civodul: I think we shouldn't merge until it's all build on intel at least, and now with the python-3.4 issue that's going to be another day or two probably, right?
<mark_weaver>last time we merged very prematurely, IMO.
<mark_weaver>master was essentially unusable for me on i686 for a couple of days
<civodul>mark_weaver: yes, i agree we should wait until it's built on x86_64
<civodul>perhaps i'm being too optimistic :-)
<mark_weaver>also, there's still quite a few broken things, see:
<mark_weaver>that's a comparison between core-updates and the latest merge from master
<mark_weaver>s/the latest merge from master/master from the latest merge/
<mark_weaver>civodul: it's not a matter of being optimistic. it's a matter of users on i686 having to spend half a day building stuff if they pull at the wrong time.
<civodul>yeah, i know
<civodul>we'll wait until most is built on these two platforms i guess
<civodul>that's what you mean?
<mark_weaver>andy is already on core-updates, so the lack of merge is no longer holding him up.
<civodul>yeah, let's not merge prematurely
<mark_weaver>civodul: right, where "most" == "all popular packages"
<mark_weaver>or at least all of the big ones, including icecat
<mark_weaver>thanks :)
<civodul>since Hydra can't display it, here's the Qt5 failure:
<civodul>it seems that something completely strips RUNPATH on
<civodul>oh it links with --disable-new-dtags
<civodul>let's see if i have enough disk space to try a fix...
<wingo>icecat still fails, no?
<civodul>in core-updates, yes
<civodul>rekado: do you know how to pass LDFLAGS=-Wl,-rpath... to TBB?
<rekado_>actually, these flags are already passed in ./build/ --> LINK_FLAGS = -Wl,-rpath-link=. -rdynamic
<rekado_>but for libraries it looks different; the variable LIB_LINK_FLAGS is used instead, which apparently does not have rpath stuff passed to it.
<rekado_>I'll take a look at this later today.
<rekado_>what exact flags need to be passed?
<civodul>rekado_: -Wl,-rpath=$libdir
<civodul>thanks for looking into it
<civodul>"Docker Raises Another $95M in Funding"
<rekado_>I would like to validate the rpaths of the new tbb build, but I cannot update to core-updates yet. Is there another way I can validate the rpaths on the command line?
<civodul>at the Guile REPL, you can do:
<civodul>,use(guix build gremlin)
<civodul>(validate-needed-in-runpath "/path/to/")
<civodul>this module is also in master
<civodul>with slight differences, though
<civodul>you could do that with the version that's in core-updates to be sure
<jxself>mark_weaver: I did apply the patch locally and linux 4.0 did compile for me on both 32 and 64 bit yesterday. Thanks!
<jxself>Gotta reboot.
<rekado_>civodul: thanks!
<wingo>jxself: uname -r ? :)
<jxself>wingo: 3.2.0-75-generic
<jxself>I built it, I did not run it.
<wingo>ah cool
<jxself>I have to build them for my public APT repo on
<jxself>So I always go do that first, just in case.
<Sleep_Walker>I'm working on LVM support
<Sleep_Walker>is it acceptable to build static binaries along with dynamicly linked ones and put it into separate output?
<davexunit>Sleep_Walker: hmm, not sure. if things are working, don't let that detail stop your progress. we can figure that out at the end.
<davexunit>oof, our magit is way out of date.
<wingo>i updated magit from elpa or someting on another box and the new version was much worse
<taylanub>davexunit: might it be the last release?
<davexunit>wingo: hmm, I've had the opposite reaction.
<davexunit>the version in guix is missing things that I've come to expect
<davexunit>upstream is 1.4.1, we're 3 releases behind.
<davexunit>I will upgrade and send patch
<wingo>for me the new version was slow, unnecessarily verbose, and buggy
<wingo>mine is 20150124.930 from melpa or marmalade or one of those
<davexunit>there's a magit 'next' branch, perhaps you were using that version?
<wingo>maybe yeah
<davexunit>well, let's see how upgrading magit goes? if everyone hates it we can go back or keep the old one hanging around.
<taylanub>ah, didn't know there were new releases. maybe switching to 1.4 is fine then.
*davexunit builds guix on guix
<davexunit>so nice.
*nully giggles
<nully>fchmmr: which system?
<nully>nvm i seenow
<jxself>mark_weaver: Had time to review the log. I see you're applying more patches than I am. I thought fchmmr was only pushing for a single patch? Now to go find out what this patch does. Had I known this other patch existed I would have been testing for it.
<mark_weaver>jxself: the other patch was needed to fix warnings that repeatedly generated kernel backtraces.
<mark_weaver>the list of patches is just below the hash that you have to update when you update the guix package
<jxself>Doesn't mean I notice. I had no idea this patch existed. I don't recall any communications. Oh sure there was probably commit messages but who read them? Thanks!
<mark_weaver>jxself: well, there's no need to notice anything if you try building the package in guix :)
<mark_weaver>it failed while trying to apply the patch, before the compile even began.
<mark_weaver>if you don't want to test build in guix, that's okay, I still appreciate your work. but in that case, it might be better to post the patch so that one of us can test it before pushing.
<mark_weaver>at least for major release updates
<mark_weaver>for security updates it's probably safe enough to just push
<mark_weaver>(and more important to be quicker about it)
<mark_weaver>does that make sense?
*civodul thinks it's a reasonable way to approach it
*mark_weaver goes afk for a while
<jxself>Or just talk to me. I'm not necessarily going to pick up on commit emails. But yeah, it seems that the patch isn't needed anymore for 4.0 and can be removed. I'll leave that up to you since you added it.
<mark_weaver>yes, I removed it. the same patch was already applied upstream
<fchmmr><mark_weaver> jxself: the other patch was needed to fix warnings that repeatedly generated kernel backtraces.
<fchmmr>mark_weaver, which other patch is this?
<fchmmr>I'm guessing the one that kills those warning (since 3.19 on X60/T60)
<fchmmr>yes that one was merged, it's just the one that I also sent jxself/Emulatorman that isn't merged upstream yet
<fchmmr>actually, which patch?
<mark_weaver>it doesn't just kill the warnings, it fixed the underlying problem
<mark_weaver>fchmmr: the patch I removed here:
<fchmmr>last I checked, that was "queued to stable", I think it's merged already.
<mark_weaver>it's in 4.0 but not 3.19.3
<fchmmr>good enough for me
<fchmmr>those warnings don't cause any user noticeable issues anyway, afaik
<fchmmr>"queued to stable", is "stable" the 3.19.x series, or 4.0?
<fchmmr>I never understand the way kernel version numbers work
<fchmmr>libreboot's version numbers are much simpler than in most projects
<fchmmr>rYYYYMMDD is the scheme that libreboot uses, for the day that the release was made.
<civodul>davexunit: we should rebrand "guix publish" something like "Guix Enterprise" ↑
<davexunit>civodul: hahaha
*civodul is amazed by these tech companies
<davexunit>I was about to say that
<davexunit>Docker and NPM just got toooons of money
<civodul>yeah, i don't understand "how it works"
<davexunit>why can't we get a little of that money?
<davexunit>we're not corporate enough
<davexunit>NixOS could probably get it
<civodul>all this is weird
<mark_weaver>fchmmr: queued to stable suggests that it may be in 3.19.4
<davexunit>civodul: I feel like someone could at least give us a big donation.
<davexunit>we don't need millions of dollars to be better than npm :)
<davexunit>we just need 'guix import npm' ;)
<davexunit>haven't worked on that
<mark_weaver>and possibly to later point releases of earlier kernels, if appropriate
<fchmmr>what is npm?
<fchmmr>or docker, for that matter
<davexunit>fchmmr: npm is a package manager for NodeJS software
<jxself>It's not in 3.19.4. I am compiling now right now.
<jxself>er compiling that
<jxself>fchmmr: That may ehlp
<jxself>er help
<jxself>"If accepted, the patch will be added to the -stable queue, for review by other developers and by the relevant subsystem maintainer."
<jxself>Then Check out "Review cycle"
<fchmmr>but at least the fix that makes X60/T60 boot again is in parabola/guix/freesh until that's merged
<fchmmr>the other one that gets rid of those vblank warnings is non-critical, and merged in 4.0 upstream, so that's fine by me
<mark_weaver>I thought it worth cherry-picking. lots of backtraces in my logs and on console was annoying...
<jxself>I think I will update my procmail receipe for guix so that messages with linux.scm in them will go to my inbox instead of to the Guix mailbox.
<mark_weaver>jxself: there's no substitute for attempting the build in guix
<mark_weaver>but for point releases it's okay to just push
<jxself>I'm not saying there is. This is just to remain informed of what changes are happening.
<jxself>Because, you know... it seems that doesn't happen.
<mark_weaver>civodul: if I wanted to simply move my HDD from an i686 box to a x86_64 box, what would be the easiest/best way to update the system+profiles to x86_64 in place?
<civodul>mark_weaver: simply 'guix system reconfigure' for the system
<civodul>and for the rest, perhaps 'guix package -u'
<wingo>what a lovely answer
<mark_weaver>I tried doing 'guix system build --system=x86_64-linux' and it downloaded a lot of stuff but then failed
<civodul>though maybe not everything will be upgraded
<civodul>mark_weaver: that happens sometimes ;-)
<civodul>but it should work
<wingo>i guess the store can hold outputs for any architecture...
<civodul>yes, which is nice
<civodul>multilib! :-)
<civodul>mark_weaver: i mean: move the HDD in the x86_64 box, and from there run 'guix system reconfigure'
<mark_weaver>civodul: it was trying to build something locally that was not (and never could be) on hydra, and balked because "I'm not an x64_64 system" (paraphrased)
<fchmmr>you can switch easily between i686 and x86_64 in guix, in place?
<civodul>aah, i see
<mark_weaver>I think there's a missing piece, but we're not far from being able to do this
<fchmmr>I'm not sure if that's easy to do on other distros
<civodul>mark_weaver: i think you first need to boot into an x86_64 kernel
<civodul>not as easy as i thought
<mark_weaver>civodul: you can reproduce the problem by trying to run 'guix system build --system=x86_64-linux' using a 'guix' built for i686
<civodul>yes, i know what you mean
<civodul>that's because the daemon considers that x86_64 is a foreign architecture
<mark_weaver>fchmmr: you're right, but it should be doable in guix
<mark_weaver>there are a few builds that it needs to do locally
<civodul>mark_weaver: if you remove that bit for which there's no substitutes, what happens?
<civodul>my guess is that as long as there are substitutes, that should be simple
<mark_weaver>civodul: it's not removable.
<civodul>really really? :-)
<civodul>i mean you can re-add it later
<mark_weaver>alas, I've forgotten which thing it is, and am one-handed atm, but it's one of the things that builds a profile or maybe the system itself
<mark_weaver>I need to deal with baby stuff for a bit...
<civodul>if you really can't, i think it's (1) reconfigure with a 64-bit kernel, (2) build 64-bit guix and run its daemon, (3) reconfigure
<davexunit>updating magit to 1.4.1 fails. :(
<davexunit>was hoping it would be easy. have to punt on it for now.
<mark_weaver>civodul: I can't reconfigure with a 64-bit kernel, is the thing.
*davexunit realizes that ruby is a native input to qt.
<mark_weaver>the system derivation depends on my system configuration, so it has to be built locally. and it wants to do that on a 64-bit system.
<davexunit>I'll be extra cautious with updates in the future, I suppose.
<davexunit>nothing broke this time, but I didn't think to check.
<mark_weaver>civodul: if you try $(guix build --system=i686-linux guix)/bin/guix build system --system=x86_64-linux <config> you will see the issue
<civodul>mark_weaver: for step (1), the trick would be to use a special 'kernel' field in your config, that happens to be the 64-bit kernel (and so you wouldn't use --system=x86_64-linux at all)
<civodul>i'm not sure exactly what "the trick" is like
<civodul>but it's doable
<mark_weaver>I guess that would be part of it, but it's not the whole answer, because it fails before ever trying to run a 64-bit executable.
<mark_weaver>anyway, it's not important, but it would a cool thing to brag about if we could make this work nicely :)
<mark_weaver>but I shouldn't distract from getting core-updates ready to merge...
<civodul>mark_weaver: (define linux32 (package (inherit linux-libre) (arguments `(#:system "i686-linux" ,@(package-arguments linux-libre)))))
<civodul>something like that
<civodul>and then you use that as the 'kernel' field
<civodul>for step (1), that is
*civodul has to go
<mark_weaver>okay, thanks!
<mark_weaver>wingo: alas, I probably won't have time to fix icecat in core-updates until tomorrow, but feel free to poke at it sooner!
<mark_weaver>in the meantime, you could keep using icecat from master but everything else from core-updates
<fchmmr>mark_weaver, jxself read
<fchmmr>the fix will be in 4.1, it says
<fchmmr>and they say it's going to be backported to stable (that probably means 4.0 or 3.19.x right?)
<fchmmr>I'll keep an eye out and let you know know when it's merged
<jxself>fchmmr: Probably not in 3.19.
<fchmmr>yes, probably just 4.1
<jxself>Since 3.19 is not an LTS kernel, support for it will be ending soon (within the next numbe of weeks.)
<jxself>There's usually only a small overlapt when a new kernel comes out.
<fchmmr>it'll probably land in an update to 4.0 right?
<fchmmr>and 3.14 too?
<fchmmr>or is 3.14 no longer the latest LTS?
<jxself>Well does it affect 3.14?
<fchmmr>well no, it doesn't affect 3.14
<fchmmr>I spoke before thinking, because I'm stupid
<jxself>Hehe. It's ok. :)
<mark_weaver>fchmmr: does the "think light" work on a libreboot x200? what about changing the screen brightness?
<fchmmr>changing brightness should work
<fchmmr>thinklight also works
<jxself>Yes, I have x200 and both of these things are fine.
<fchmmr>I just tested thinklight in grub, didn't work
<fchmmr>I'll try in gnu/linux
<mark_weaver>jxself: your x200 is running libreboot?
<fchmmr>backlight controls do work, though
<jxself>I think a backlit keyboard would be nice instead of a light shining down from aboe.
<fchmmr>mark_weaver, he bought an FSF conference workshop X200
<jxself>mark_weaver: Of course. :)
<fchmmr>it was flashed by pehjota, I think
<mark_weaver>okay :)
<fchmmr>(I was also there flashing those laptops. pehjota and marxistvegan helped out)
<fchmmr>ok, mv flashed jxself's X200
<mark_weaver>I much prefer the light from above
<fchmmr>the 3 of us were there, flashing a bunch of X200 laptops
<mark_weaver>it can be used to read from paper as well
<fchmmr>it was quite chaotic
<fchmmr>wires everywhere
<fchmmr>and I was about 30 minutes late, because I was in the other room flashing an R400 for someone
<fchmmr>(it took about 2 hours to flash, because that machine requires lots of careful disassembly)
<jxself>mark_weaver: I also bought a brand-new 9-cell battery for it from (Lenovo wanted $180 for it and newegg had it for $80.) I get like 5.5 hours of battery life. It's amazing.
<fchmmr>mark_weaver, ok so, thinklight doesn't work
<fchmmr>that thing that lets you see your keyboard in the dark
<jxself>What? Mine does.
<fchmmr>= not working
<fchmmr>mine doesn't
<fchmmr>let me try another X200 then
<fchmmr>I have lots of X200 laptops
<fchmmr>mark_weaver, I tried another X200 and it did work
<fchmmr>the one on mine is probably just physically damaged
<fchmmr>or not installed
<mark_weaver>mine doesn't either, but I wasn't sure if it was my userspace missing some deamon
<fchmmr>might be EC related
<jxself>I just did mine again.
<jxself>Just to make sure I wasn't being crazy.
<jxself>Meeting time. Back later.
<fchmmr>anyway, who needs to see keys while they are typing?
<fchmmr>everyone should know how to touch type
<mark_weaver>jxself: thanks, I've ordered the 9-cell batt from newegg
<mark_weaver>fchmmr: heh :)
<fchmmr>you should be able to type blind folded
*fchmmr can
<fchmmr>Look at me. I'm blind folded
<fchmmr>Typing on a dvorak keyboard.
<fchmmr>I can't type passwords without seeing the keys, though.
<fchmmr>only nully can do that
*mark_weaver goes afk
<davexunit>"we want the maintainers of various Linux distros to have sufficient confidence in on-­going availability to use our motherboards to power their build farms, thereby ensuring timely software updates for our entire userbase."
<davexunit>might be a reference to us or other distros that want to use Novenas for their build farm
<civodul>heh, sounds good
<civodul>the pictures are fun
<davexunit>civodul: yeah, their backer updates are really nice.
<davexunit>lots of interesting technical detail
<civodul>in QEMU, Xorg fails to start because it cannot open /dev/mem
<civodul>presumably a change in Linux 4.0?
<civodul>how do we work around that?
<Sleep_Walker>I need to express package with exact output in helper-packages - how can I do that?
<mark_weaver>civodul: it also might be a change in jxself's configuration
<civodul>oh right
<civodul>jxself: any idea re Xorg in QEMU? ↑
<civodul>well, gtg
<civodul>good night/day Guix!
<jxself>mark_weaver: Indeed! CONFIG_DEVMEM is not set.
<mark_weaver>jxself: I guess we need to change that back in guix
<mark_weaver>sneek: later tell civodul jxself says "Indeed! CONFIG_DEVMEM is not set." regarding his new linux-libre-4.0 configuration
<sneek>Got it.
<jxself>STRICT_DEVMEM is set which seems good. "If this option is disabled, you allow userspace (root) access to all of memory, including kernel and userspace memory."
<jxself>I can work on it when I get home tonight.
<mark_weaver>jxself: we should probably discuss proposed configuration changes to our linux-libre packages on the ML, to avoid breaking functionality that users have grown dependent upon.
<mark_weaver>jxself: iirc, for a lot of older video drivers, Xorg needs access to /dev/mem
<jxself>There are configuration changes needed for each major kernel version.
<mark_weaver>sure, but this is a configuration option that's been around for quite a long time as I recall
<jxself>This seems to have been introduced by which allowed for /dev/mem to be turned off.
<jxself>So the change is new for 4.0 it seems.
<mark_weaver>oh, I guess I remembered incorrectly.
<jxself>/dev/mem has been around for a long time, I think, just that it recently seems to have gained the ability to be turned off.
<mark_weaver>anyway, we've disabled functionality that used to be present. maybe it's a good idea, but in this case it's likely to break Xorg for a lot of users
<jxself>I can work on it when I get home tonight.
<mark_weaver>e.g. anyone who doesn't have a video card whose driver supports kernel-mode-setting, which is most of them.
<mark_weaver>if I recall correctly.
<mark_weaver>anyway, I have to go afk for several hours, ttyl!