| *** zoli__ has joined #baserock | 00:56 | |
| *** zoli__ has quit IRC | 01:00 | |
| *** inara has quit IRC | 02:48 | |
| *** inara has joined #baserock | 03:08 | |
| *** zoli__ has joined #baserock | 04:04 | |
| *** zoli__ has quit IRC | 05:18 | |
| *** zoli__ has joined #baserock | 05:49 | |
| *** straycat has joined #baserock | 06:16 | |
| *** straycat_ has joined #baserock | 06:34 | |
| *** straycat has quit IRC | 06:35 | |
| *** straycat_ is now known as straycat | 06:35 | |
| *** gary_perkins has joined #baserock | 06:58 | |
| *** sherm_ has joined #baserock | 07:15 | |
| *** Albert_ has joined #baserock | 07:35 | |
| *** a1exhughe5 has joined #baserock | 07:43 | |
| *** straycat has quit IRC | 07:45 | |
| *** straycat has joined #baserock | 07:45 | |
| *** rdale has joined #baserock | 07:53 | |
| *** mariaderidder has joined #baserock | 07:54 | |
| *** bashrc has joined #baserock | 08:04 | |
| *** sambishop has joined #baserock | 08:04 | |
| *** gary_perkins_ has joined #baserock | 08:10 | |
| *** bashrc has quit IRC | 08:11 | |
| *** gary_perkins has quit IRC | 08:11 | |
| *** a1exhughe5 has quit IRC | 08:11 | |
| *** flatmush1 has quit IRC | 08:12 | |
| *** sherm_ has quit IRC | 08:12 | |
| *** a1exhughe5 has joined #baserock | 08:24 | |
| *** sherm_ has joined #baserock | 08:26 | |
| *** jonathanmaw has joined #baserock | 08:27 | |
| *** tiagogomes_ has joined #baserock | 08:31 | |
| *** gary_perkins_ has quit IRC | 08:34 | |
| *** flatmush has joined #baserock | 08:36 | |
| *** bashrc has joined #baserock | 08:37 | |
| *** CTtpollard has joined #baserock | 08:44 | |
| *** ssam2 has joined #baserock | 08:50 | |
| *** ChanServ sets mode: +v ssam2 | 08:50 | |
| *** jonathanmaw has quit IRC | 08:51 | |
| *** gary_perkins has joined #baserock | 08:54 | |
| *** Krin has joined #baserock | 09:04 | |
| *** jonathanmaw has joined #baserock | 09:06 | |
| *** edcragg has joined #baserock | 09:10 | |
| *** inara has quit IRC | 09:11 | |
| *** gary_perkins has quit IRC | 09:16 | |
| *** gary_perkins has joined #baserock | 09:17 | |
| *** lachlanmackenzie has joined #baserock | 09:46 | |
| *** inara has joined #baserock | 09:50 | |
| pedroalvarez | Hi everyone | 09:57 |
|---|---|---|
| SotK | hi pedroalvarez | 09:57 |
| pedroalvarez | I'm having weird issues when trying to clone from gerrit over https :/ | 09:57 |
| * pedroalvarez prepares some logs | 09:58 | |
| pedroalvarez | http://sprunge.us/cNKW | 09:59 |
| pedroalvarez | meh... nevermind, network issues... | 10:01 |
| *** inara has quit IRC | 10:03 | |
| *** inara has joined #baserock | 10:14 | |
| jjardon | ssam2: Hi, if you have some free time maybe you can take a look to https://gerrit.baserock.org/#/c/531/ ? (sorry, I'm still unable to add you as a reviewer) | 10:21 |
| pedroalvarez | jjardon: re https://gerrit.baserock.org/#/c/563/ - what do you mean by "systemd will create other users...." | 10:26 |
| jjardon | pedroalvarez: systemd support declarative allcation of system users and groups: http://www.freedesktop.org/software/systemd/man/sysusers.d.html | 10:30 |
| jjardon | pedroalvarez: check your /etc/paswwd in a baserock system. users with UID > 900 have been created by systemd in boot time | 10:31 |
| * pedroalvarez checks /usr/lib/sysusers.d/ | 10:32 | |
| pedroalvarez | jjardon: ni e | 10:42 |
| pedroalvarez | nice | 10:42 |
| pedroalvarez | I was expecting systemd-sysusers to create also the home folder, and also change its permisions for the new user | 10:43 |
| jjardon | pedroalvarez: AFAIK, systemd-sysusers is for system users, not normal ones | 10:44 |
| jjardon | it should be possible ro remove the sshd user as well (I do not have any in my distro), but I think we need to change our openssh .service files to make it work | 10:45 |
| pedroalvarez | I would say that system users can also have a home folder | 10:48 |
| persia | Generally $HOME for system users should not be under /home | 10:49 |
| *** inara has quit IRC | 11:04 | |
| *** Krin has quit IRC | 11:12 | |
| *** inara has joined #baserock | 11:18 | |
| *** inara has quit IRC | 11:36 | |
| *** Krin has joined #baserock | 11:37 | |
| *** inara has joined #baserock | 11:39 | |
| *** mariaderidder has quit IRC | 12:15 | |
| *** fay__ has joined #baserock | 12:24 | |
| *** fay_ has quit IRC | 12:24 | |
| *** fay__ has quit IRC | 12:34 | |
| *** inara has quit IRC | 12:39 | |
| *** fay__ has joined #baserock | 12:40 | |
| *** inara has joined #baserock | 12:40 | |
| *** ssam2 has quit IRC | 12:51 | |
| *** ssam2 has joined #baserock | 12:51 | |
| *** ChanServ sets mode: +v ssam2 | 12:51 | |
| tiagogomes_ | richard_maw, another fact is that is the system installed that doesn't boot, the installer works fine | 12:54 |
| richard_maw | oh, that *could* be the GCC update | 12:54 |
| richard_maw | since then it would be the syslinux built with the gcc on the system that gets used | 12:55 |
| tiagogomes_ | ¬_¬, I'll revert it on my local machine and try it. We really need to stop to update GCC unless there is a valid reason to do so (like adding support for aarch64) | 12:56 |
| * richard_maw has tested https://gerrit.baserock.org/#/c/284/ (SHA512 hashing of passwords) and can confirm that it works | 12:56 | |
| Kinnison | We will need to compare it with pedro's work on fixing PAM | 12:57 |
| richard_maw | tiagogomes_: the issue is with a toolchain newer than some other component on the system | 12:57 |
| Kinnison | pedroalvarez: how is that going btw? | 12:57 |
| richard_maw | tiagogomes_: that, and compiler developers not treating undefined behaviour as ABI | 12:58 |
| pedroalvarez | Kinnison: currently testing it | 12:58 |
| Kinnison | cool beans | 12:58 |
| tiagogomes_ | well, they shouldn't use undefined behavior in the first place | 12:58 |
| persia | I'd prefer to fix all the other things, rather than not updating the compiler, but I'm forward-looking that way | 12:59 |
| richard_maw | tiagogomes_: I'd agree, but the C specification is not easy, so it's very easy to accidentally use undefined behaviour | 13:00 |
| *** mariaderidder has joined #baserock | 13:24 | |
| mwilliams_ct | has anything been built with Baserock on sysV init before? | 13:27 |
| rjek | Probably not. | 13:28 |
| rjek | I think we started with systemd | 13:28 |
| rjek | I think we enable sysV init scripts though? | 13:28 |
| rjek | +support for | 13:28 |
| richard_maw | rjek: we started with busybox init, migrated to systemd fairly early and we have always built systemd with sysv init script support | 13:29 |
| richard_maw | I don't even know if systemd _can_ be built without sysv init script support | 13:30 |
| rjek | mwilliams_ct: Do you have more context for your question you can share? | 13:30 |
| persia | I thought the minimal system still wasn't systemd | 13:30 |
| richard_maw | persia: correct, it's busybox init | 13:31 |
| richard_maw | we migrated back partially for a specific use-case | 13:31 |
| mwilliams_ct | rjek: honestly, you've answered the question as much as I needed to already. but context is that we're trying to port openBMC onto Baserock, and atm it has a variety of lovely sysV init scripts | 13:31 |
| rjek | aha | 13:32 |
| richard_maw | custom verbage? lack of pidfiles? | 13:32 |
| richard_maw | there's no issue with using the legacy sysv init scripts | 13:32 |
| richard_maw | provided you don't need it to start up faster or extra dependency information | 13:33 |
| tlsa | http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/ | 13:35 |
| * pedroalvarez ends up with a system on which he can't log in | 13:41 | |
| jonathanmaw | pedroalvarez: pam config doesn't have nullok? | 13:43 |
| pedroalvarez | hm.. to allow null passwords.. | 13:45 |
| jonathanmaw | pedroalvarez: nullok is required for 'login' at the bare minimum, I think. | 13:45 |
| jonathanmaw | I'm not sure if that's the problem you're experiencing, though, just an educated guess | 13:47 |
| pedroalvarez | jonathanmaw: thanks for the info. | 13:50 |
| pedroalvarez | I was going to add nullok and I found that more things were wrong | 13:50 |
| ssam2 | https://gerrit.baserock.org/#/c/568/ !!!!!! | 13:53 |
| ssam2 | probably the most important fix in Baserock ever: fixing the delete key | 13:53 |
| *** inara has quit IRC | 13:58 | |
| *** Albert_ has quit IRC | 14:02 | |
| *** Albert_ has joined #baserock | 14:02 | |
| *** inara has joined #baserock | 14:10 | |
| jjardon | ssam2: Any idea when the new release is going to be made? Any outstanding problems with the current rc? | 14:19 |
| jjardon | pedroalvarez: about https://gerrit.baserock.org/#/c/563/ ; not sure touching systems files in random extensions is in general a good idea (vagrant.configure changes /etc/profile as well, apart from adding a system user) | 14:25 |
| jjardon | if a new system user is needed, maybe we should modify /usr/lib/sysusers.d/ instead? | 14:26 |
| pedroalvarez | yes, that might be the right way to do it | 14:26 |
| tiagogomes_ | jjardon yes, images installed with the baserock installer don't boot | 14:26 |
| jjardon | tiagogomes_: ah, whats the baserock installer? | 14:27 |
| pedroalvarez | jjardon: I'm not against a better solution, I'm just against breaking the current solution | 14:27 |
| tiagogomes_ | jjardon, http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/installer-scripts.git/ | 14:27 |
| jjardon | pedroalvarez: sure, can you point in the review what extensions/chunks will break with the change? | 14:29 |
| ssam2 | jjardon: no idea about that, I'm afraid | 14:29 |
| ssam2 | hopefully the project I'm on will fund a day for me to do another one, don't know when | 14:29 |
| richard_maw | tiagogomes_: likely culprits are mkfs.btrfs, the rawdisk write extension, the installer script itself or gcc 5.1 | 14:29 |
| * ssam2 is happy to explain the release process to anyone who fancies doing them in future | 14:30 | |
| jjardon | ssam2: if you write it down in the wiki anyone can do it :) | 14:31 |
| ssam2 | http://wiki.baserock.org/guides/release-process/ | 14:31 |
| tiagogomes_ | I want to lorry cdrecord, but I can't find a suitable download link | 14:31 |
| jjardon | ssam2: nice! | 14:32 |
| jjardon | so I guess a baserock release is a morph release + some supported baserock systems, rigth? What are the release cycles based on? feature-wise or time-wise? | 14:33 |
| ssam2 | there's no cycle. anyone can do one any time | 14:33 |
| ssam2 | in practice, we do one whenever one is required for GENIVI, which is every six weeks (but not always needed) | 14:34 |
| tiagogomes_ | what do we use to download tarballs in lorry? This link http://sourceforge.net/projects/cdrtools/files/cdrtools-3.00.tar.gz will work with wget but not with curl, as the latter doesn't follow links | 14:34 |
| ssam2 | jjardon: the systems released are http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/clusters/release.morph | 14:35 |
| rjek | tiagogomes_: curl -L is what you want? | 14:36 |
| ssam2 | jjardon: 'morph' doesn't really have a release process at all, we just roll up a given version into a Baserock release. It would be good to separate Morph out, but it'd be more work, and nobody seems interested in doing it | 14:36 |
| tiagogomes_ | rjek yep, now I wonder if lorry does the same | 14:36 |
| ssam2 | tiagogomes_: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/lorry.git/tree/lorry.tar-importer | 14:36 |
| ssam2 | wait, it's http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/lorry.git/tree/lorry#n490 that does the work | 14:36 |
| ssam2 | so, we use Python urllib2 ... which we can be fairly sure will do the wrong thing | 14:37 |
| rjek | haha | 14:37 |
| ssam2 | worth testing though in case it doesn't | 14:37 |
| ssam2 | updating 'lorry' to use 'requests' instead would be easy and might improve matters | 14:37 |
| paulsherwood | if we're going to fiddle with lorry, can we make it do shallow clones, too? | 14:38 |
| tiagogomes_ | urllib2 it is | 14:38 |
| ssam2 | paulsherwood: i'm not sure what you mean by that | 14:39 |
| paulsherwood | we don't lorry gcc from git, because it's too large (and possibly other stuff too). but we could use shallow clones to have gcc from a reasonable previous version and ongoing | 14:40 |
| rjek | ISTR that there are quite serious reproducability issues with doing that, but I don't recall the details and thus I might be making it up. | 14:41 |
| paulsherwood | rjek: my 'tests' showed that the SHA1s are the same | 14:41 |
| tiagogomes_ | urllib2 did the right thing this time :) | 14:41 |
| ssam2 | cool | 14:41 |
| paulsherwood | (iiuc git has improved since lorry was originally developed) | 14:42 |
| rjek | That is likely | 14:42 |
| ssam2 | paulsherwood: shallow cloning could be 'opt in'. I wouldn't want it there by default (history is useful) | 14:42 |
| rjek | I find having history for loads of projects in one place one of the best things about having a Trove. | 14:42 |
| paulsherwood | i agree. | 14:42 |
| paulsherwood | my problem is we don't have any history for *-tarball things | 14:43 |
| paulsherwood | especially gcc | 14:43 |
| pedroalvarez | that is true, some years of history would be better than no history at all | 14:45 |
| paulsherwood | we're also missing the ongoing *collection* of history from those things | 14:46 |
| jjardon | agree, IMHO lorrying (and use) a tarball is a bug that should be fixed when possible | 14:47 |
| ssam2 | if Trove automatically picked up the latest tarballs of things every time a new one appeared, it'd be good | 14:48 |
| ssam2 | for gcc we should just fix gcc.git, but not everything has a git repo | 14:48 |
| straycat | pedroalvarez, do we have any guide for deploying distbuild to openstack, out of interest? | 14:50 |
| pedroalvarez | straycat: I don't think so | 14:50 |
| straycat | okay, i think all i'm missing is the cloud-config.sh template and that should just be the entries i have in my distbuild.conf, right? | 14:52 |
| rdale | at the end of last week, i created a new development image based on the master of definitions with gcc 5.1. that image runs fine, however when i build an image and copy it to my laptop to run under kvn, the linux kernel doesn't start | 14:55 |
| rdale | ^i build an image^i build an image in the new development vm | 14:56 |
| tiagogomes_ | rdale, yep it is broken at the moment. Most likely due the gcc update | 14:57 |
| rdale | ah ok | 14:57 |
| tiagogomes_ | I reverted the gcc update locally and I will test it when it finishes building | 14:58 |
| rdale | ok, i'll be interested in how you get on | 14:59 |
| persia | I'm a big fan of long histories (I've often traced bugs back 10-15 years), but +1 for having 5 years history over none. | 15:00 |
| *** zoli__ has quit IRC | 15:02 | |
| pedroalvarez | finally: https://gerrit.baserock.org/#/c/573/ | 15:07 |
| pedroalvarez | straycat: sorry, I was finishing the patch | 15:09 |
| pedroalvarez | I have around an example for the workers | 15:09 |
| richard_maw | pedroalvarez: is there no way of specifying natively in the format that modules are optional? | 15:10 |
| pedroalvarez | richard_maw: oh, yes, I think we can do that as well | 15:10 |
| richard_maw | I'd rather we had static config that worked if the module was missing, rather than removing the config that uses the module at build time | 15:11 |
| pedroalvarez | straycat: http://paste.baserock.org/ofoqazojob, if you change the IPs of the controller and the cache server, you can use the same one to spawn as many workers as you want | 15:12 |
| ratmice__ | hmm, wonder if you can do multiple shallow clones, or skip commits inbetween lorrying, not sure exactly how much something like the gcc repo would grow between lorrying | 15:12 |
| pedroalvarez | richard_maw: so, instead of removing the lines at system-integration time, modify them at post-install time to make selinux support optional | 15:14 |
| pedroalvarez | right> | 15:14 |
| pedroalvarez | ? | 15:14 |
| richard_maw | if we can't upstream a change to make selinux optional, yes | 15:15 |
| richard_maw | though I'll accept unconditionally making selinux optional, as we don't have the effort or a large enough stick to ask for proof that upstream won't take the change before accepting it as patched downstream | 15:16 |
| radiofree | rdale: the kernel isn't booting? | 15:17 |
| pedroalvarez | :) | 15:17 |
| radiofree | i wouldn't have thought that was down to the gcc 5.1 change | 15:17 |
| radiofree | what panic do you get? | 15:17 |
| rdale | radiofree: it doesn't get as far as panicking | 15:17 |
| radiofree | how far does it get? | 15:18 |
| richard_maw | AIUI we can prepend the line with a `-` and change it from reqiured or requisite to sufficient or optional | 15:18 |
| radiofree | so old gcc -> built new image with gcc5 | 15:18 |
| radiofree | that's ok? the resulting image works? | 15:18 |
| richard_maw | but this isn't the same as having an optional requirement, as selinux failing to auth would be ignored | 15:19 |
| radiofree | but then gcc5 image -> build gcc5 image, that one doesn't work? | 15:19 |
| rdale | it hangs on the line 'SYSLINUX 4.06..' | 15:19 |
| radiofree | sounds like syslinux is buggered then | 15:19 |
| richard_maw | could be from gcc5 | 15:19 |
| radiofree | yeah | 15:19 |
| radiofree | so it's probably not the kernel | 15:19 |
| richard_maw | it can't be the kernel | 15:20 |
| radiofree | rdale: try adding a few menu entries to extlinux.conf and see if that shows up | 15:20 |
| rdale | how do i do that? | 15:20 |
| radiofree | mount baserock.img /mnt | 15:20 |
| radiofree | vim /etc/extlinux.conf, copy and paste | 15:21 |
| radiofree | give them new labels though | 15:21 |
| radiofree | hmm hold on a think you might need a bit more in there | 15:21 |
| *** zoli__ has joined #baserock | 15:21 | |
| radiofree | rdale: this is what system-version-manager generates after a few updates | 15:22 |
| radiofree | http://fpaste.org/218651/83931614/ | 15:22 |
| pedroalvarez | if it's hanging on selinux, I don't think that would be the kernel | 15:22 |
| ssam2 | syslinyx :) | 15:23 |
| ssam2 | syslinux even | 15:23 |
| radiofree | time to upgrade! | 15:23 |
| pedroalvarez | we had a similar problem when upgrading btrfs[-utils] | 15:23 |
| pedroalvarez | yeah, syslinux :) | 15:23 |
| jonathanmaw | have the permissions on git.baserock.org just changed? I'm wondering why I can't push to the branch baserock/jonathanmaw/genivi-demo-platform | 15:28 |
| jonathanmaw | I'm suddenly getting http://paste.baserock.org/ezukayuris | 15:28 |
| * pedroalvarez pushed once to master using `git push origin HEAD` | 15:29 | |
| Kinnison | jonathanmaw: Permission denied (publickey,keyboard-interactive). | 15:30 |
| Kinnison | jonathanmaw: have you got ssh credentials on the system you're pushing from? | 15:30 |
| jonathanmaw | ah, it's because This was from a screen session, and I was using a previous tab | 15:31 |
| Kinnison | :) | 15:31 |
| jonathanmaw | so ssh -A got cut out | 15:31 |
| Kinnison | yep | 15:31 |
| Kinnison | I keep meaning to try and write ssh agent support for mosh | 15:31 |
| Kinnison | and an agent aggregator for m | 15:31 |
| Kinnison | ,e | 15:31 |
| Kinnison | me even | 15:31 |
| Kinnison | I need new fingers and it's only 16:30 | 15:32 |
| jonathanmaw | hrm, browser-poc uses a submodule at https://github.com/Pelagicore/Pelagicore-LaTeX-Class, purely for documentation purposes | 15:43 |
| jonathanmaw | should that be lorried, or should we find a way to disable gitmodules for browser-poc? | 15:43 |
| ssam2 | i'd lean towards disabling it, as I don't think people use built-in documentation in Baserock much right now | 15:51 |
| ssam2 | but I have no strong opinion either way | 15:51 |
| ssam2 | unless the repo is massive | 15:51 |
| jonathanmaw | repo is tiny, documentation is only built as PDF, so I'd say probably isn't what we intend to install in a system. | 15:52 |
| jonathanmaw | Is there a nice way to disable gitmodules that doesn't involve carrying patches? | 15:52 |
| richard_maw | jonathanmaw: no | 15:54 |
| tiagogomes_ | ok the update to gcc 5.1 is the culprit of not having bootable systems. I'll test build syslinux with gcc 5.1 | 15:57 |
| persia | jonathanmaw: Chunk-splitting | 15:58 |
| persia | You build the PDF, and then you split it out as a separate chunk, and then you fail to install it. | 15:58 |
| richard_maw | persia: won't prevent it attempting to build it, splitting occurs post-build | 15:58 |
| jonathanmaw | persia: it doesn't try to install it anywhere, the problem is that it's trying to initialize a submodule from the wider internet at build time. | 15:59 |
| persia | Oh, ugh. Right. The ugly way is to just delete the relevant tree from the source as the first step in the build commands. | 15:59 |
| richard_maw | persia: unfortunately no, as the submodule checkout happens before any build commands | 16:00 |
| persia | Now I'm intrigued. I no longer believe I have any answer, but I'm vaguely curious how to construct a repo that would cause morph to try to download something from the internet at build-time that cannot be overridden by the build-commands. | 16:01 |
| richard_maw | do it as a submodule, morph will cache the submodule for you and check it out in the repository | 16:01 |
| richard_maw | it will only check out the commit mentioned in the .gitmodules file | 16:01 |
| richard_maw | so you ought to not lose reproducibility from this, unless the repository stops existing, or the target repository has a sha1 collision in it | 16:02 |
| richard_maw | morph augments the set of repositories it needs to fetch and extract into the staging area from the git submodules | 16:02 |
| richard_maw | even if a build theoretically doesn't need to clone all its submodules to be functional, morph will ensure they are all available, as if you were building from a working tree prepared by running `git clone --recursive` | 16:03 |
| persia | Is there any sane way to work around this at lorry-time? | 16:05 |
| richard_maw | you'd have to do a filter branch of the entire history, and you'd end up with something different from upstream | 16:06 |
| persia | Hrm. Annoying. | 16:06 |
| richard_maw | we could fix up the submodules without modifying history by having morph translate the repository urls at parse time | 16:08 |
| richard_maw | the issue becomes ensuring the translation's target contains everything necessary | 16:08 |
| * Kinnison has suggested a submodule URL rewrite behaviour in definitions | 16:09 | |
| Kinnison | But I don't want to try and specify such until we know how definitions goes together | 16:09 |
| richard_maw | and that would require a few days of someone who knows definitions well, and someone who doesn't's time | 16:10 |
| Kinnison | Just to get started, yes | 16:10 |
| Kinnison | and an ongoing effort to maintain | 16:10 |
| Kinnison | which is why, I fear, noone has committed to it yet | 16:10 |
| *** Krin has quit IRC | 16:29 | |
| *** a1exhughe5 has quit IRC | 16:34 | |
| *** Krin has joined #baserock | 16:40 | |
| *** Krin has quit IRC | 16:43 | |
| *** sherm_ has quit IRC | 16:46 | |
| *** mariaderidder has quit IRC | 16:49 | |
| *** bashrc has quit IRC | 17:00 | |
| ssam2 | it's not causing me problems, but seems 'yarn --snapshot' is broken in Baserock | 17:05 |
| ssam2 | it expects to be able to '-x' to 'cp', but Busybox cp doesn't work | 17:05 |
| ssam2 | s/work/support that/ | 17:05 |
| ssam2 | but the only symptom is there are no snapshots, so it's not really a problem | 17:05 |
| ssam2 | (for me) | 17:05 |
| *** jonathanmaw has quit IRC | 17:06 | |
| *** sambishop has quit IRC | 17:07 | |
| ssam2 | the yarns have caught some really obscure errors in the patch series I'm working on, incidentally, they are coming in very handy | 17:17 |
| *** edcragg has quit IRC | 17:19 | |
| *** bfletcher has left #baserock | 17:24 | |
| jjardon | radiofree: definitely the new mesa version doesn't put the dri drivers in /usr/lib/xorg/modules/dri , at least for x86 (they are built though) | 17:36 |
| *** Albert_ has quit IRC | 17:39 | |
| *** Albert__ has joined #baserock | 17:39 | |
| *** sambishop has joined #baserock | 17:46 | |
| *** gary_perkins has quit IRC | 17:52 | |
| *** Albert__ has quit IRC | 17:54 | |
| *** zoli__ has quit IRC | 17:57 | |
| *** ssam2 has quit IRC | 18:00 | |
| *** lachlanmackenzie has quit IRC | 18:03 | |
| *** zoli__ has joined #baserock | 18:46 | |
| * paulsherwood hates deploy extensions | 20:06 | |
| SotK | paulsherwood: why? :) | 20:06 |
| paulsherwood | because they are a mess | 20:07 |
| paulsherwood | here i am trying to work towards tidying up definitions.... and i suddenly discover that build is picture of tidiness by comparision with deployment | 20:08 |
| SotK | hm, you mean the configure extensions or the write extensions? | 20:09 |
| paulsherwood | both, i think. we have extensions in various places, and they are coupled to morph, and to cliapp (even the ones in definitions). | 20:11 |
| paulsherwood | i think definitions should be buildable and deployable with minimum tooling, no 'unusual' dependencies or coupling. but perhaps i am fueled by alcohol | 20:12 |
| paulsherwood | if they are just 'plugins to morph' then fine, but they should not be in definitions. if they are in definitions, they should not be coupled to morph, istm | 20:14 |
| paulsherwood | and in any case, we should not be collecting jrandom files in the root of definitions | 20:16 |
| robtaylor | I seem to remember there was some discussion about write/configure extensions in definitions at the summit | 20:16 |
| robtaylor | and maybe something about making them more declarative? | 20:16 |
| SotK | I think the configure extensions should all be in definitions | 20:16 |
| paulsherwood | i'd *prefer* to see an extensions directory, with them tidily in there. | 20:17 |
| SotK | paulsherwood: +1 | 20:17 |
| paulsherwood | but they should not require morph or cliapp. | 20:17 |
| paulsherwood | (or any other non-standard library) | 20:17 |
| * paulsherwood has tried moving them... but morph doesn't like that | 20:18 | |
| SotK | I'd imagine it would be a pretty easy fix | 20:18 |
| paulsherwood | so in effect we have stuff hard-coded to be in root of definitions and requiring morph | 20:18 |
| paulsherwood | SotK: you're probably right | 20:18 |
| paulsherwood | but note that as i said on http://wiki.baserock.org/back-and-forth/ there are three things here - morph, systems, definitions. | 20:19 |
| robtaylor | http://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2015-February/011447.html | 20:19 |
| paulsherwood | robtaylor: thanks :) | 20:20 |
| paulsherwood | so actually, fixing it properly won't be 'pretty easy' | 20:22 |
| SotK | oh yes, making them nicer will be much more involved than just putting them in a subdirectory | 20:24 |
| robtaylor | i suspect there's a step-wise approach that could be taken | 20:31 |
| paulsherwood | robtaylor: every time we take a step, we risk forgetting that there are three parts here, not just morph, but also definitions (which users may not upgrade) and existing systems (which users may not upgrade) | 20:38 |
| *** persia_ has quit IRC | 20:39 | |
| *** persia has quit IRC | 20:40 | |
| *** persia has joined #baserock | 20:41 | |
| *** persia has joined #baserock | 20:41 | |
| * paulsherwood notes, in passing, that there are 2470 loc in write extensions... | 20:42 | |
| paulsherwood | 3044 in configure extensions | 20:42 |
| persia | !!! | 20:42 |
| paulsherwood | and 1753 in ybd | 20:42 |
| persia | That last one needs to be smaller. | 20:43 |
| persia | There's no good reason to have the sandboxing logic built into the build tool. | 20:43 |
| paulsherwood | :) | 20:43 |
| persia | Mind you, there's functionality I want that ybd doesn't have, which pushes it in the other direction, but still. | 20:43 |
| *** persia_ has joined #baserock | 20:45 | |
| *** persia_ has joined #baserock | 20:45 | |
| * paulsherwood sees midnight approaching, and heads to bed | 20:46 | |
| rjek | Wise | 20:57 |
| *** zoli__ has quit IRC | 21:58 | |
| *** zoli__ has joined #baserock | 22:58 | |
| *** zoli__ has quit IRC | 23:03 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!