IRC channel logs
2015-09-12.log
back to list of logs
<antiatom>Did you read what I wrote around half a day ago? <antiatom>1) It has a WLAN blob, but it is burned into the ROM so it is extremely difficult to reverse engineer, and even if that happens, near impossible to replace the blob <antiatom>2) I really support osmocomBB, but have you tried to use that on the GTA02 with anything resembling day-to-day reliability that people depend on for business or contact with family/friends? <mark_weaver>I'd like to know why Neo900 didn't use an Atheros chip, for which we actually have free software to run on the embedded processor (and we cross-compile it from source in Guix). <mark_weaver>Atheros was not an option when GTA02 was created, but now it is. <antiatom>Also osmocomBB is only GSM, so no data transfer. <antiatom>mark_weaver: Most Atheros chips are for entirely different form factors of computers. Any Atheros chip using the ath5k, ath9k, or ath9k_htc drivers (the libre ones) only connect via USB or PCI Express <mark_weaver>well, if you buy a phone that osmocomBB runs on, then you could work on adding support for data. if you buy one that cannot run osmocomBB, then that's probably a *lot* harder, if it's possible at all. <antiatom>Computers as small as handhelds are extremely power and space contrained, and the WLAN chips are usually "FullMAC", meaning most of the 802.11 stack is implemented in firmware that runs on the processor of the WLAN card <antiatom>ath5k and ath9k are SoftMAC platforms that use cfg80211 running on the host CPU to implement the protocols <antiatom>On mobile this does not work because of the power contraints (drains host battery) and processing load (limited computing resources) <mark_weaver>okay, so your argument is that we should accept that both radios on the Neo900 run non-free OSes for the sake of longer battery life? <antiatom>mark_weaver: If you want, you can plug in some ath9k_htc device in the USB port of the Neo900 and not use the internal WLAN card. <mark_weaver>if you want to promote a non-free platform, please do it elsewhere. here, we are dedicated to systems that respect the users freedom. <antiatom>Let's talk about one issue at a time. My point is that UMTS/LTE is impossible to do libre, but this is what people expect, so at least providing them the option of truly disabling their GSM radio when they choose, or being able to spy on its activity if they want to RE it is a positive step. <antiatom>For WLAN, I would ask you to take a closer look at the GTA02 before you promote that as a system that respects the users' freedom: both WLAN and GPS require blobs in the GTA02 <antiatom>I had a discussion with Luis Rodriguez today about this. He was the employee at Atheros that liberated ath5k and ath9k <antiatom>I asked him what we could possibly do to fix the terrible situation that ALL handheld computers seem to require WLAN blobs (yes even the GTA02)... <antiatom><mcgrof> you're shit out of luck for mobile <antiatom><mcgrof> my recommendation is to reverse engineer the firmware <antiatom><mcgrof> work on picking the best hardware and then just put a lot of effort to reverse engineer the fw <antiatom>Neo900 let's us at least try to RE the firmware (there are people who have started, but I have not tracked them down yet), whereas GTA02 users are trapped with the non-libre blob burned into the WLAN ROM chip. That is a worse situation than with Neo900. <antiatom>If you want to be purist about it, then do not recommend any handheld or tablet every made. <antiatom>The GTA02 does not even fit your own strict requirements. <mark_weaver>we need to draw a line somewhere, and if we accept that our OSes need to include copies of non-free software to upload to various subsystems, then we're lost. <mark_weaver>for one thing, if we accept this situation, then we face a situation where users are sometimes encouraged to install updates to their firmware, and any time then do this, it can be used to install new malware. <mark_weaver>and of course, if your computer is hacked, someone can upload malware into those subsystems. <antiatom>If we recognise that there is non-libre software running on ANY processor in our systems controlling essential networking functionality, then we should try to improve that situation by coding the libre replacements. It is dangerous that even intelligent hackers suddenly become apathetic to non-libre software just because it is stored on a ROM chip and not on their HDD or SDD (which ironically also have non-libre software required to function as well). <mark_weaver>these abuses are not possible with a ROM, unless the malware was burned with malware to begin with, which can only be reasonably done by the manufacturer, and would be very risky for them to do. <antiatom>Updatable non-libre software is MUCH better than non-updatable non-libre software. It allows us to more easily study and examine its behavior and functionality so that we can document it and share with others, so we can code the libre replacements together, <mark_weaver>antiatom: yes, and we now have a good option for wifi, but it was rejected by the Neo900 folks. <mark_weaver>the thing is, for the foreseeable future, we unfortunately cannot avoid non-free hardware designs. <mark_weaver>that's a bad situation, for sure, but at least when something cannot be changed, then malware cannot be added later, and it can in theory be detected and the manufacturer can be held accountable, which should deter them from putting malware in there. <antiatom>mark_weaver: Again, I think this might be a fundamental misunderstanding on how WLAN processors connect to the host computer in handhelds. You cannot simply take an ath9k chip and shimmy it into something like the GTA02, Neo900, or even an iPhone <antiatom>If that was possible, it would have been done. <mark_weaver>but we can compare notes later, and see if anyone reverse engineers the firmware of the Neo900 wifi and writes a free replacement. I'm betting that it won't happen. <antiatom>Look at the GTA02 with the Atheros AR6001GZ chipset... definitely not ath5k or ath9k powering that thing, if you check your kernel modules on the GTA02 <mark_weaver>antiatom: what part am I not understanding? the ath9k_htc connects via USB, and the Neo900 has USB. <mark_weaver>earlier, you suggested that it would adversely impact battery life, you didn't claim it was impossible. now you seem to be claiming that it's not possible and there's no other choice. so which is it? <xentrac>antiatom: I agree with you that having proprietary firmware burned into a ROM chip is probably even worse than loading it with the CPU <xentrac>despite the possible Schelling value of not being able to upgrade your firmware <antiatom>Lack of upgradability of firmware is a net negative on an otherwise libre system. Study the history of the Atheros cards to find out why... it started with the madwifi driver and non-libre HAL <antiatom>ONly with this situation came the ath5k driver that we know and love. <xentrac>what happened with the Atheros cards? <ellis>How do I make my installation bootable? <ellis>I've installed guix without errors, but the bios/efi doesn't find a disk to boot from. <mark_weaver>antiatom: you never answered my question about why they couldn't use the ath9k_htc. <mark_weaver>first you suggested it would adversely affect battery life, and then you suggested it was impossible, but never explained why. <mark_weaver>in this particular case, we don't have to choose between non-free ROM or non-free blob to upload. we can instead upload free software into the ath9k_htc <mark_weaver>ellis: I'm sorry, I don't know. you might try using the MBR partition scheme and see if that helps. as I recall, Andy Wingo successfully installed GuixSD on a modern Lenovo laptop and used GPT. I'm not sure why it's failing for you and succeeded for him. <antiatom>mark_weaver: I am researching the feasability of using AR9271 now <mark_weaver>antiatom: when I asked them, someone on the IRC channel said that one reason was that they wanted to support Nokia's proprietary OS, and that Nokia's OS didn't support Atheros. <mark_weaver>I think it's sad if they considered it more important to support Nokia's proprietary OS than to support fully free OSes. <antiatom>mark_weaver: I have the attention of the main hardware developer. Please help me find an actual AR9271 module that is no larger than 12mmx12mm <antiatom>or actually it could be maximum 14mm by 18mm <antiatom>What game? You are saying you do not like the situation, and there may be an opportunity to fix it. <mark_weaver>it is clear that they have several priorities that are more important to them than freedom. <mark_weaver>I assume that the question was rhetorical, because no such module exists. <mark_weaver>so maybe the phone would be slightly larger if they used a free wifi subsystem. <mark_weaver>they are the hardware designer. I assume they are more than capable of finding out the sizes of the available modules. this is not my job. <mark_weaver>when I spoke to them before, it was obvious that they considered this issue unimportant, and were more interested in considerations such as being able to run Nokia's proprietary OS, minimizing power consumption of the wifi subsystem, and possibly size. it was also evident that they already had a board design and were not willing to make any changes that would require changing its layout. <mark_weaver>I'd *love* to be proved wrong in my assessment of the situation. <antiatom>I am digging thru pages of pages of alibaba and similar sites to find ANY AR9217L module that is small enough <antiatom>otherwise it does not fit into the Neo900 project because every other component has at least data sheets <antiatom>*sigh* cant find anywhere that lists the size of the AR9271L-AL3A <davexunit>Mathnerd314: interesting, that branch dropdown doesn't show all of the branches <davexunit>my wip-container branch isn't listed, for instance. <Mathnerd314>perhaps the savannah url is a mirror of some other repository? <davexunit>Mathnerd314: what is the branch name in question? <Mathnerd314>alright, so it seems he got the bindings kind of working but no real progress on the actual substitution. oh well :-/ <xentrac>(I guess that's kind of off-topic; maybe /msg me if that annoys others) <mark_weaver>antiatom: I apologize for losing my temper in my recent messages. <antiatom>The real future is putting an SDR chip inside the device. <antiatom>The power and size contraints again are the primary issue... but the designers of the Neo900 are looking forward to implementing it in a future model. <antiatom>But that requires this model to be successful first. <antiatom>Ultimately, I believe the Neo900 will be hostorically known as a platform that allows for more direct reverse engineering of the baseband processor and its associated operating system blob <antiatom>There are really nice things to work towards, but we have to start somewhere. <xentrac>And we don't have the giant, massively popular free-software movement to make free-software-friendliness a big selling point right now. <antiatom>xentrac: Perhaps better to call is Libre Software Movement instead <antiatom>Maybe people will pay attention when they know their direct liberties are at stake. <mark_weaver>antiatom: I'm sorry, but words are wind. I have no confidence in future promises from a project that chose a wifi module requiring a blob when there was a wifi module available that runs free software on it and works well. <mark_weaver>I can understand their decision to use a non-free baseband. <antiatom>I have not found an appropriate AR9217L modules... also it does not support 5GHz, this chipset, <antiatom>Who is putting this chipset in a small module package? <antiatom>And why would you abide by the GTA02 then? <mark_weaver>because it allows us to hold the line on not requiring our OSes to include non-free software.. <mark_weaver>if we open that door, it is a slippery slope to a bad place <mark_weaver>and because the practice of users installing non-free firmware updates sets up a very dangerous ability for new malware to be added in practice at any future time, because users will naturally be inclined to install the updates. some of the updates might actually be security updates, and thus important. <mark_weaver>but every time there is an update, it requires another blind leap of faith on the part of the user.. <mark_weaver>and in practice it is possible to insert malware on a particular user's computer without it being clear who to blame. <mark_weaver>don't get me wrong: I will not be satisfied until we are running 100% free hardware designs as well. <antiatom>Please consider the fact that the malware that you speak of is malware first and foremost because the corporation who made it won't reveal some secrets about what the device is doing when it has electricity and a connection to the rest of the host over some specified bus type. <antiatom>If there is non-libre software on the device's ROM storage from the beginning, we already have lost to a situation with this malware is present *and* we cannot easily reverse engineer it. <iyzsong>ACTION push a commit to update 'lzo' on master, and then revert it to avoid rebuilds. <iyzsong>but hydra don't pick the 'revert' one :-( <mark_weaver>iyzsong: thanks for letting me know, I'll cancel the builds. <spwx>hello! I was wondering how guix handles /etc and other config files does it link to the store? does it remove the links on package removal? <iyzsong>spwx: yes, if you using GuixSD. those files are linked to store, and will be update when you reconfigure the system. <spwx>iyzsong: thanks, what if im just using the package manager? <mark_weaver>antiatom: if malware is present in the ROM, then there is hard physical evidence of the malware, and the manufacturer can be held accountable. this should strongly deter manufacturers from putting secret malware there. but in any case, if you don't trust the hardware, then you're already screwed because the malicious functionality can be implemented outside of the software that is uploaded.. <iyzsong>spwx: then guix won't touch any your config files <mark_weaver>for many purposes, it makes sense to think of a program in ROM as equivalent to a circuit. <DusXMT>spwx: The config files are linked, like your binaries, into your ~/.guix-profile <spwx>iyzsong: so then say i install i3wm via giux, which normally creates an /etc/i3 folder. Will the guix package manager just not create that? <mark_weaver>given the way circuitry is created, using hardware description languages that are compiled into the circuitry, there is no really a hard distinction between the two. <DusXMT>spwx: You will have a ~/.guix-profile/etc/i3 folder, which is read-only (everything in your profile is). What you have to do is to copy the config files somewhere and override the given program (i3 in this case) to use your modified configs <mark_weaver>and in either case, if the manufacturer puts malware there, that is extremely risky for them. their reputation could be massively damaged by hard evidence of some malware. <mark_weaver>with flash firmware updates, the situation is quite different. <iyzsong>spwx: all the files of i3 will go to the store (eg: /gnu/store/*-i3-wm-4.10.3 ), and you should create the user config files ~/.i3 I think. <mark_weaver>there is a relationship set up between the users and the manufacturer where the manufacturer (or anyone else who can acquire the private signing key) has an ongoing ability over time to target individual users and install malware on their machines. <mark_weaver>users have no good choice but to accept these updates, since some of them could be security critical. <iyzsong>DusXMT: yes, but I think package override is not needed for i3. (but for dwm) <mark_weaver>but in fact they are completely at the mercy of the manufacturer, or anyone who can acquire the manufacturer's key. <mark_weaver>but anyway, this is a distraction from the Neo900 wifi, because in that case, they didn't have to choose between non-free ROM or non-free uploaded firmware. <DusXMT>iyzsong: I didn't neccesairly mean package override, just giving the program an option (if it supports such a thing) to look somewhere else than /gnu/store/blabla-pkg/etc for the config files. <spwx>DusXMT, iyzsong: im just using i3wm as an example. There is already a ~/.i3/config file created per user. There is also an /etc/i3/config which i could edit so all users will have the same configurations. I am just trying to figure out how guix deals with those system wide config files. <DusXMT>spwx: Without the "system" part of Guix (which makes GuixSD), it will not touch /etc. In general, most programs allow you to specify a different place for the configs. If not, it's usually trivial to patch a program to do so. <DusXMT>And even with GuixSD, only the most crutial of config files are in /etc, the rest is in the individual users' profile, and in the system profile <spwx>DusXMT: ok thanks that is what i was wondering! so if i just use guix its per user installs only? <iyzsong>um, the GuixSD use Guix to manage the system settings. but for packages's default settings I think you have to modify the package source (thus override it). <antiatom>Ultimately, we need libre hardware review processes that involves datasheets, the DSP commandset documentation, & the masks to re-create all of the chips under a libre (preferably copyleft) license, fabrication plants distributed and near where you live (requires accessible, internationalised documentation of silicon extration from sand), and the public needs the ability to review the fabrication plants to ensure the fab is actually making what they <antiatom>But like I said, we have to start somewhere. <antiatom>Should we really trust the integrated circuits from Texas Instruments to not have backdoors in the hardware itself? Intel most likely has them. <DusXMT>spwx: Indeed. The only way users can interfere with each other is by compiling/downloading packages into the store, if user A gets a program into the store, user B can just link to that :) <spwx>DusXMT: ok so if user a installs i3, then user b wont have i3 until she installs it? <DusXMT>spwx: indeed. And even if they install it, it's just symlinks into the store, so (almost) no disk space is wasted by it (I said almost, as symlinks take _some_ space, but it's negligable) <DusXMT>s/they install/they both install/ <DusXMT>s/wasted by it/wasted by the multiple installs/ <spwx>DusXMT: alright, and when they both link to it i3 would be built to look for the global config in /gnu/store/etc/i3/config? <DusXMT>spwx: almost; in /gnu/store/blablalonghash-i3wm-version/etc/i3/config <spwx>DusXMT, iyzsong: awesome i think i get it now!! Thanks! <DusXMT>please keep in mind though, the store is read-only, by modifying any of the files in the store, you're corrupting your setup <spwx>DusXMT: so I cant edit the config? <iyzsong>indeed, but you can write a simple package to wrap the original i3 with your choosen configs, if you really want modify the 'default configs'. <DusXMT>spwx: nope. As I've said, you have to make a copy of the configs and somehow tell the program where to look for it. For example, openbox automatically looks for ~/.config/openbox before looking into ${prefix}/etc/xdg/openbox <spwx>ok, i guess that isnt that big of a deal. Thanks. <iyzsong>spwx: the package (once built) is immutable, to change its value (file contents) we have to build a new one. but if you use 'the wrap way', you can avoid the rebuild of the package. <iyzsong>yet, I agree it's not a big deal :-) <mark_weaver>antiatom: I agree that we need free hardware designs and masks. I don't see why fabrication plants need to be near where users live. IMO, what's needed is the ability to inspect a chip to verify that it matches the published masks. this would surely involve destroying the chip, but that's okay. just do random inspections. <antiatom>local fabs = more access & easier verification process <mark_weaver>i.e. if I had the tool to inspect a chip, and needed N chips that I can trust, I buy N+M chips, randomly choose M of them to inspect, and thus gain confidence in the others. <mark_weaver>it doesn't matter. if I need 5 chips, I order 8 from anywhere in the world, and randomly choose 3 of them to inspect. <mark_weaver>anyone with the tools to do the inspection can audit any foundry they wish. <DusXMT>mark_weaver: the problem, I think, will be time. Sure, anyone can inspect the chip, but how many chips a week can a person inspect? I understand in a compan, where people could be hired to it, and it would be useful, but for an individual? I think it's a great idea, but it would be _extremely_ time costly for the individual <DusXMT>(but it's _far_ better than the inability to inspect the chip, don't get me wrong) <mark_weaver>auditing the foundry does no good if the chips can be swapped during shipment. <mark_weaver>I've been thinking about this in the context of our build farm for guix. <mark_weaver>when we acquire machines for a build farm, it opens the possibility for the machines to be modified as they are shipped to us. <mark_weaver>but, if I could buy more machines than I need, and then inspect+destroy some randomly chosen fraction of them, I could reduce the probability, to any arbitrary value, of the NSA being able to insert malicious hardware in our machines without being detected. <mark_weaver>this would allow me to gain confidence that the remaining machines are good, without having to trust anyone else. <mark_weaver>but if it were possible, it wouldn't require an ongoing commitment on my part to inspect N chips per week. it would rather be a job to do each time I purchased new hardware. <DusXMT>What I was trying to say is, a computer is pretty darn complex. Let's say it contains 300 different chips, you need 10 computers for something (eg. for an office), and you can somehow manage to inspect 2 chips a week. You buy 13 computers and randomly chose 3 to inspect and destroy. That means that you have to inspect 900 chips, and if you manage to do 2 a week, it'll take you 450 weeks, which is 8 and a half <DusXMT>But considering how technology is getting smaller and smaller, I don't think it's that unrealistic in 20-30 years <mark_weaver>well, you don't need to trust every component, first of all. <mark_weaver>for example, through the use of full disk encryption and libreboot, iiuc, you can ensure that the most a malicious hard drive can do is deny service. <mark_weaver>because it can neither see your data nor modify your data in a meaningful way. <mark_weaver>and the trend seems to be greater integration and thus far fewer chips. <mark_weaver>I don't claim that this is easy, but I don't know of any other way to acquire an uncompromised computer with any confidence. <DusXMT>Not really; I haven't thought much about free hardware, and I definitely think being able to inspect a chip in one's home would be great, but I'm just now thinking of how practical it could be for the individual. For companies, yes, they have the workpower to do it, but for your everyday hacker? Of course, something's better than nothing, I don't mean to clain that we shouldn't be able to do this <mark_weaver>multiple people and/or companies could combine their hardware acquisition+inspection processes. <mark_weaver>suppose I can find 100 people that all want to buy a Novena. <mark_weaver>we randomly choose the ones to inspect in such a way that everyone knows that the choice was random. <mark_weaver>if I'm not mistaken, that means that if only one of the machines is compromised and the other 99 are good, there's a 5% chance that the bad machine will be inspected. <mark_weaver>and if only one is compromised, then the chance that the one you took home is bad is 1% <mark_weaver>and of course, if a group finds a compromised chip, they raise an alarm and others are alerted to the danger. <mark_weaver>if 5/100 of the machines are compromised, then, if I'm not mistaken, the probability that one of the compromised ones will be inspected is about 23% <karhunkynsi>Hi. I've installed GuixSD in one encrypted partition (including /boot) on a computer with libreboot. But i'm having problems booting it. <karhunkynsi>My plan is for libreboot's grub to hand over the process to GuixSD's grub file <karhunkynsi>I'm doing this currently manually with: cryptomount ahci0,gpt1 set root=(crypto0) configfile /boot/grub/grub.cfg <karhunkynsi>which seems ok, i get the GuixSD boot screen and from here it will boot "some" <karhunkynsi>it will stop after a short while with a panic or a guile prompt depending on my GuixSD grub configuration <karhunkynsi>I think the problem is the "--root" parameter to linux, but i'm unable to figure out what should be there <alezost>karhunkynsi: linux /var/guix/profiles/system/kernel/bzImage --root=guix --system=/var/guix/profiles/system --load=/var/guix/profiles/system/boot <alezost>or you can set 'system variable' and use it: <alezost>set system=/var/guix/profiles/system <alezost>linux ${system}/kernel/bzImage --root=guix --system=${system} --load=${system}/boot <alezost>s/'system variable'/'system' variable <karhunkynsi>Thanks. However i get: ERROR: failed to resolve partition "guix" <alezost>karhunkynsi: oh, yes, that's because I "guix" is a label of my Guix partition, I mean I have "search --no-floppy --label --set guix" in my grub.cfg <karhunkynsi>i also labelled my partition "guix"; i'll try with your search line <alezost>great, then it should work. It is also possible to specify the current root partition in other ways, like "search --fs-uuid --set=root 11771f1e-526d-4ede-83b7-453e5f1947b5" or "set root='(hd1)'" <alezost>it is documented in the grub manual, but I just prefer to use label <karhunkynsi>i don't see how they're different from what i've tried: set root=(crypto0) <alezost>oh, crypto, I have no idea about encrypting <karhunkynsi>i think i should be using something like "--root=/dev/mapper/guix" <karhunkynsi>i can update the root variable with your search line, yes <karhunkynsi>are these /var/guix/profiles paths symlinks to /gnu/store? <alezost>sorry, I didn't get it. Does the system boot properly now? <iyzsong>I unpack my initrd, it look like it doesn't handle the kernel command line at all. <karhunkynsi>i get different results depending on what i put in --root, if that's relevant <alezost>it works for me (but I don't use encrypting) <karhunkynsi>i had it working without encryption as well. I used "--root=/dev/sda2" in that case <alezost>karhunkynsi: nothing to thank for. As for my setup: I manage grub.cfg myself and always use "guix system --no-grub ..." <hubot666>I am having trouble connecting wifi with USB installer. Is there a way to disable ipv6? <hubot666>I have basically followed the process here. Make a wpa.conf and cwpa.conf then "dhclient wlp1s0" without quotes <trevorm>Hey people, I just have a quick question. Has Calamares been considered as an installer for GuixSD? It's GPL3 <trevorm>Has Calamares been considered as an installer for GuixSD? It's GPL3 <alezost>trevorm: AFAIK nothing was considered as an installer for GuixSD <wgreenhouse>could "guix environment" be useful as an application jail? (well, I suppose it is one already) <davexunit>there's a working implementation in the wip-container branch <trevorm>I think the devs behind GuixSD should seriously consider the gpl installers available like Calamares since it aims to garner more support and users. Just my two cents. <mark_weaver>karhunkynsi: thanks for looking into full disk encryption for GuixSD! I think I can point you to the relevant code that needs to be changed. <mark_weaver>The relevant file is gnu/build/linux-boot.scm, which contains 'mount-root-file-system', called by 'boot-system'. <mark_weaver>are some extra steps needed here to mount an encrypted file system? <mark_weaver>I guess we also need to add some kernel modules to the initrd. <mark_weaver>I also use Libreboot, and would be thrilled to have full disk encryption support in GuixSD. <mark_weaver>iyzsong, karhunkynsi: 'linux-boot' does indeed extract information from the linux command line, specifically the --root and --load arguments. See the calls to 'linux-command-line' and 'find-long-option' <mark_weaver>karhunkynsi: I guess the missing pieces are: (1) we need some additional kernel modules loaded from the initrd (and thus added to it), and (2) we need to run 'cryptsetup' from the initrd. <mark_weaver>the kernel modules can be added to 'linux-modules' in gnu/system/linux-initrd.scm and the cryptsetup commands can be added to 'mount-root-file-system' in gnu/build/linux-boot.scm <dan_robertson>Hello. What's the current state of installing i686 packages on a 64bit system? I know that you can build them and all the dependencies get sorted out but is there a way to add them to a profile? <alezost>dan_robertson: no (as far as I know) <dan_robertson>That's what I thought. I looked into the supported-systems parameter of packages but it seems that it is only used by guix package -s when printing details about packages. <mark_weaver>dan_robertson: it should be possible. I see no fundamental problem with it. <mark_weaver>I guess "guix package" just lacks the easy ability to do it. <mark_weaver>you can run: guix package -i $(guix build --system <package>) <mark_weaver>you can pass a store directory to "guix package -i", and it will add that to the profile. <mark_weaver>there are some downsides to this approach. things like updates don't work on such packages. <mark_weaver>dan_robertson: out of curiosity, why do you want this? <mark_weaver>one more thing: this can work for programs, but if you install libraries this way, that would be bad. <mark_weaver>because they would end up in the same directory as 64-bit libraries. <dan_robertson>There isn't a /lib64 mechanism so there would be conflicts right? <mark_weaver>dan_robertson: we don't use /lib64, but what we do is strictly more flexible. we segregate the 64-bit libraries from the 32-bit ones by putting them in different store directories. <dan_robertson>yeah. That's what I assumed. You would only get problems if there were propogated-inputs for libraries that mixed 32-bit and 64-bit <mark_weaver>we can segregate not only 32/64, but also arbitrary other differences. e.g. you can experiment with a new C library without disturbing your known-good one, and we do this when we make changes to core-updates, for example. <mark_weaver>but, you must make sure to keep them in different profiles. <mark_weaver>"guix environment --pure" might also be able to do what you want. <dan_robertson>Is there any system that detects conflicts between packages? <mark_weaver>the only thing we have like that is that if you try to install two packages in the same profile, and they contain the same file with different contents, you get a warning. <mark_weaver>unfortunately, we have so many harmless conflicts of this kind that we've all been trained to mostly ignore those conflict warnings. <mark_weaver>dan_robertson: actually, I have another solution for you: <mark_weaver>that will build 'guix' itself, for i686-linux. then, you can run that guix command to install 32-bit packages into a separate profile. <dan_robertson>Ok. That's quite novel. Is there some guide somewhere that describes some general procedure for creating new packages? The whole time I was doing it, I felt like what I wanted to do was have guix put me in a shell in the same context as would be used to build the package so that I could get all the steps right <mark_weaver>hmm, actually, that might not work if you've run "guix pull", because ~/.config/guix/latest will point to your 64-bit updated guix. <mark_weaver>dan_robertson: "guix environment" is the relevant command. <mark_weaver>that creates an environment very similar to the one used to build a package. <mark_weaver>yeah, there's definitely room for improvement. we are still a young project. <mark_weaver>I'm sorry, we don't really have a good solution for you, but there is no deep problem here, afaict. <dan_robertson>Ok. Thanks. I think what you've given me should be a great help. <mark_weaver>dan_robertson: I would encourage you to post to guix-devel@gnu.org explaining what you'd like to do. <fredinsky>I'm trying to get GuixSD installed and when it comes time to run "guix system init /mnt/etc/config.scm /mnt --no-grub" I get the error "ice-9/boot-9.scm:1729:9 In procedure #<procedure 433f840 ()>: ice-9/boot-9.scm:1729:9: In procedure scm_lreadr: /mnt/etc/config.scm:46:1:1 end of file in string constant" even though I copied my config file almost exactly from the desktop example. Any ideas? <fredinsky>Can anybody help me to set up config.scm in a way that will let me install? <karhunkynsi>fredinsky, i faced some issues with that as well. What i did was to drop the --no-grub argument and instead let it fail <mark_weaver>the error message would seem to indicate that there's a string quoting problem, with the string starting on line 46 <fredinsky> http://paste.lisp.org/+3BO6 mark_weaver, that's what I thought and I couldn't find anything. I read the whole file over and over making sure every ( had a ) and every " has it's ", but to no avail <fredinsky>I tried running without the no-grub argument and it fails just the same <karhunkynsi>yes, but if the rest of the installation process is ok, it doesn't really matter that the grub step failed. It didn't for me at least. I just continued after that and it was all good. <mark_weaver>karhunkynsi: that may have been the case for you, but I suspect it failed much earlier in fredinsky's case. <mark_weaver>fredinsky: I cannot find any flaw in that file, and guile reads it successfully. <fredinsky>yeah I couldn't find any flaw either. and when it fails for me, it fails immediately, before the system actually installs. if it failed afterwards I'd be much happier lol <mark_weaver>fredinsky: tell me about the 'guix' you are running now. is it from our binary installer, or the USB installer, or did you build it from source? <mark_weaver>are you sure the config.scm file you pasted is the same one that was available within the USB installer? <fredinsky>there's one available within the installer!? I wrote that thing by hand using the example in the online manual