IRC channel logs
2015-04-14.log
back to list of logs
*davexunit updates ruby to 2.2.2 <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>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. *mark_weaver goes afk for a bit... <mark_weaver>I need a 64-bit kernel before I can run 64-bit userspace <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? <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>GM45 is a gold mine for the libreboot project. So many machines that Just Work <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 <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 <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 <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>(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>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 <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 <fchmmr><mark_weaver> fchmmr: I believe I ended up with an X200 that was liberated at LP. <fchmmr>As I recall, a few of those machines didn't have caddies in them, just HDDs <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. <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. <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. <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 amazon.com, but.... please don't buy it. <fchmmr>that board does look cool, though <fchmmr>Well I did check ebay, but I checked UK one <fchmmr>what type of flash chip does it use, though? <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's not exactly a commodity item, either <fchmmr>so there probably weren't nearly as many of these made compared to standard ATX boards <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>libreboot.org 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>ok, quite a few more available too <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 <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>it contains what I believe is the flash chip <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 <fchmmr>mark_weaver, ok, so you are also at least 20 years older than me. <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 <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>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, 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. <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. <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: 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: instead of hardcoding the "3.4", could you fix it to use 'version-major+minor' so that this doesn't happen again? <mark_weaver>iyzsong: but please only apply that 'version-major+minor' improvement to the 3.4 package. <mark_weaver>so it would be something like (files (list (string-append "lib/python" (version-major+minor version) "/site-packages"))) <mark_weaver>also, I'm afraid that our python-3.4 package had a bad search-path, so we have to rebuild again :-( <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>we should probably refrain from making unnecessary changes at this point, since they might result in more breakage higher up <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. <civodul>iyzsong, mark_weaver: i agree with mark_weaver, next cycle <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>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>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>we'll wait until most is built on these two platforms i guess <mark_weaver>andy is already on core-updates, so the lack of merge is no longer holding him up. <mark_weaver>civodul: right, where "most" == "all popular packages" <civodul>it seems that something completely strips RUNPATH on libQt5WebEngineCore.so <civodul>oh it links with --disable-new-dtags <civodul>let's see if i have enough disk space to try a fix... <rekado_>actually, these flags are already passed in ./build/linux.gcc.inc --> 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. <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>(validate-needed-in-runpath "/path/to/libtbb.so") <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>I have to build them for my public APT repo on jxself.org/linux-libre <jxself>So I always go do that first, just in case. <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. <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>the version in guix is missing things that I've come to expect <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? <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 <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>for security updates it's probably safe enough to just push *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 <mark_weaver>it doesn't just kill the warnings, it fixed the underlying problem <fchmmr>last I checked, that was "queued to stable", I think it's merged already. <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" ↑ *civodul is amazed by these tech companies <civodul>yeah, i don't understand "how it works" <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 :) <mark_weaver>and possibly to later point releases of earlier kernels, if appropriate <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>"If accepted, the patch will be added to the -stable queue, for review by other developers and by the relevant subsystem maintainer." <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 <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' <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 ;-) <wingo>i guess the store can hold outputs for any architecture... <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? <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 <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>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 <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>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 <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>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 <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>and then you use that as the 'kernel' field <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>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>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>or is 3.14 no longer the latest LTS? <fchmmr>I spoke before thinking, because I'm stupid <mark_weaver>fchmmr: does the "think light" work on a libreboot x200? what about changing the screen brightness? <jxself>Yes, I have x200 and both of these things are fine. <fchmmr>I just tested thinklight in grub, didn't work <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 <fchmmr>it was flashed by pehjota, I think <fchmmr>(I was also there flashing those laptops. pehjota and marxistvegan helped out) <fchmmr>the 3 of us were there, flashing a bunch of X200 laptops <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 newegg.com (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 <fchmmr>mark_weaver, I tried another X200 and it did work <fchmmr>the one on mine is probably just physically damaged <mark_weaver>mine doesn't either, but I wasn't sure if it was my userspace missing some deamon <jxself>Just to make sure I wasn't being crazy. <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 <fchmmr>you should be able to type blind folded <fchmmr>I can't type passwords without seeing the keys, though. <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 <davexunit>civodul: yeah, their backer updates are really nice. <civodul>in QEMU, Xorg fails to start because it cannot open /dev/mem <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 <jxself>mark_weaver: Indeed! CONFIG_DEVMEM is not set. <mark_weaver>sneek: later tell civodul jxself says "Indeed! CONFIG_DEVMEM is not set." regarding his new linux-libre-4.0 configuration <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>So the change is new for 4.0 it seems. <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. 