| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 01:03 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 01:03 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 01:04 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 01:04 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 05:21 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 05:22 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 05:22 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 05:23 | |
| *** zoli__ [~zoli_@0x5e91887a.adsl.cybercity.dk] has joined #baserock | 05:27 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Read error: Connection reset by peer] | 05:27 | |
| *** zoli__ [~zoli_@0x5e91887a.adsl.cybercity.dk] has quit [Remote host closed the connection] | 07:15 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 07:34 | |
| *** mike [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 07:45 | |
| mike is now known as Guest93509 | 07:45 | |
| *** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 08:10 | |
| *** rdale [~quassel@49.Red-81-37-64.dynamicIP.rima-tde.net] has joined #baserock | 08:36 | |
| *** bashrc_ [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:00 | |
| paulsherwood | +1 for patchwork | 09:01 |
|---|---|---|
| *** bashrc_ [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Client Quit] | 09:02 | |
| *** bashrc_ [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:04 | |
| pedroalvarez | I would have said +1 some time ago, but now.. Weren't we planning to move to gerrit? | 09:13 |
| *** CTtpollard [~tom@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:19 | |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:21 | |
| *** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:25 | |
| persia | Either is better than what we have today. | 09:34 |
| mwilliams_ct | do we have any naming conventions for feature branches? | 09:45 |
| straycat | mwilliams_ct, what are you pushing to? | 09:46 |
| straycat | trove/name/feature_foo is common | 09:46 |
| mwilliams_ct | straycat: github, as per http://wiki.baserock.org/contributing/ | 09:46 |
| straycat | it's not just a convention though, but something defined by trove's gitano rulesets | 09:46 |
| straycat | Oh, I'm not aware of any particular conventions for pushing to random git repos that aren't on trove | 09:47 |
| rjek | Is convention that is enforced by rules tradition? :) | 09:47 |
| mwilliams_ct | straycat: ok, I'll go with name/feature in that case. ta :) | 09:48 |
| *** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Read error: Connection reset by peer] | 09:50 | |
| *** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:52 | |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 09:53 | |
| pedroalvarez | Hi Zara_! did my suggestions to install node-npm and node-semver work? | 09:59 |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 264 seconds] | 10:03 | |
| Zara_ | Using 'npm install' doesn't work there, unfortunately (I tested it on Friday just in case I'd misremembered from December). :< It tries to do extra stuff that we don't need, and then it gives a bunch of errors and fails. 'npm build' does just the relevant part of 'npm install'. | 10:03 |
| Zara_ | moving build and install commands to the relevant sections makes sense, though :) | 10:04 |
| Zara_ | (I templated the morphologies off those in sam's branch, which I think were templated off ones the tool generated, so that may explain the oddness. I don't know exactly how morph build does its thing; I tested the chunks and they worked, so I didn't change more than the minimum! :P | 10:06 |
| *** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:08 | |
| pedroalvarez | Zara_: maybe you could do a `npm build` and then `cp` only the things that you need (a binary?) | 10:13 |
| persia | That would require a means to autodiscover the set of things needed, would it not? | 10:13 |
| Zara_ | it's very possible that the cp -a * just snuck in there and is doing nothing useful. I'll test a version without it (just because I'm cautious) and the other changes, and if it works I'll send an updated patch round later today. | 10:16 |
| pedroalvarez | Zara_: I don't think that you can avoid the `cp -a *` in your version | 10:18 |
| pedroalvarez | persia: yes, I have to say that I don't know anything about node, just saying that I'd prefer another way to install this node-npm thingy | 10:19 |
| pedroalvarez | hm.. npm source has a Makefile | 10:21 |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:29 | |
| Mode #baserock +v ssam2 by ChanServ | 10:29 | |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:30 | |
| *** jmalk [~joshmalki@access.ducie-dc1.codethink.co.uk] has quit [Quit: Lost terminal] | 10:35 | |
| *** jmalk [~josh@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:36 | |
| Zara_ | tbh, I don't like submitting patches that I don't really understand, so I'll read up on morph today. | 10:38 |
| *** locallycompact [~lc@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 10:40 | |
| pedroalvarez | Zara_: I think is more a matter of understanding how to install the thing that you want to install | 10:55 |
| pedroalvarez | although understanding how morph executes the commands in the chunk morphology is interesting as well | 10:56 |
| Zara_ | heh, okay. I think npm is different from other nodejs packages (makefiles aren't the norm), and I didn't handle the shell-scripting side of the import tool anyway, so my understanding here is hazy at best. | 11:03 |
| radiofree | paulsherwood: patchwork is excellent | 12:13 |
| radiofree | even has a cli app! | 12:13 |
| radiofree | although maybe it's not what baserock needs/wants. Was pretty elegant and simple though | 12:14 |
| persia | It's a delightful tool. I'd like to see it used. I think gerrit is better, and has more useful features and more CLI tools, but *anything* is better than what we have. | 12:15 |
| persia | Baserock desparately needs a patch tracker. While I'm not part of Baserock Ops, I suspect anyone offering a deployable system that did patch tracking would see it deployed. | 12:15 |
| paulsherwood | isn't there a deployable gerrit now? | 12:17 |
| persia | I think so: I think testgerrit was directly deployed. | 12:17 |
| persia | But it seemed to need a fair degree of post-deploy config, and I'm not sure if that ever got committed to automation. | 12:18 |
| petefoth | Is the project still hoping / intending to use the same tools as OpenStack, or have we moved on? | 12:18 |
| persia | The last statement of intent I saw from the operations team was to use the same tools. | 12:20 |
| persia | I don't think we can do better than them in tool selection, because there are more of them and they have been doing it longer. | 12:20 |
| petefoth | persia: thanks for clarifying | 12:20 |
| persia | That said, we still don't have a patch tracker or a bug tracker, which is much more annoying that whether we have a specific one. | 12:21 |
| persia | petefoth: I'm not authoritative on this: I'm just reporting what I've read. | 12:21 |
| ssam2 | getting storyboard going is still on my list, but there's still a couple of problems to solve before it's usable | 12:23 |
| ssam2 | patch review and security fixes take priority so I can't make any promises about it being done, sadly | 12:25 |
| ssam2 | the main problems are: fixing the open ID provider to take a full name (currently storyboard shows up all users from our openID provider as "") | 12:25 |
| ssam2 | and backing up the database server (although this doesn't actually block it) | 12:26 |
| persia | That sounds really close. Thanks for the summary. | 12:26 |
| persia | In that vein, do you know what is required to have a patch tracker? | 12:27 |
| ssam2 | a few approaches were discussed on the mailing list in December | 12:28 |
| ssam2 | first thing we need to do is pick one. And then do it :) | 12:29 |
| *** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 264 seconds] | 12:29 | |
| ssam2 | i don't really have any idea which approach is best, so if it's left to me I will probably pick whichever seems easiest | 12:29 |
| *** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 12:30 | |
| straycat | Probably about time I started doing this http://dereenigne.org/git/set-git-email-address-on-a-per-repository-basis >.> | 12:37 |
| *** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 13:01 | |
| *** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 13:10 | |
| franred | hi, I've create some system-integration commands for my strata: http://paste.baserock.org/titolulapu and Im having this error: http://paste.baserock.org/pokiwacize, are there any way to debug if my system has already the group 25 in use? | 14:00 |
| persia | I believe system artifacts are tarballs, so you can unpack and inspect /etc/group | 14:02 |
| paulsherwood | yes they are | 14:05 |
| franred | persia, true | 14:07 |
| persia | Alternately, take a look at the logic in adduser and addgroup, and perhaps include some of that to autoselect a sane group number. | 14:07 |
| pedroalvarez | franred: is this using latest morph? | 14:13 |
| franred | pedroalvarez, using: 1bed7a3732e7d6158613609a57fb1f77ec99de1e | 14:14 |
| pedroalvarez | franred: there have been some changes in system-integration since then, but I think they are not critical | 14:16 |
| pedroalvarez | worth a try though | 14:16 |
| pedroalvarez | also, unpacking the system artifact would work if you manage to build it (removing the system-integration commands?). Otherwise it won't produce any artifact | 14:17 |
| franred | pedroalvarez, so it runs the system-integration commands before creating the rootfs package? | 14:21 |
| franred | s/package/artifact/ | 14:21 |
| persia | Yes, it does. It runs those against a staging area constructed from the included strata immediately before creating the tarball. | 14:22 |
| persia | Apologies for my timing confusion. | 14:23 |
| *** lachlanmackenzie [~lachlan@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 14:30 | |
| mwilliams_ct | pedroalvarez: thanks for the review! | 14:41 |
| pedroalvarez | you are welcome! :) | 14:42 |
| pedroalvarez | so I've done a little research and I've found that you actually need the kernel headers installed to build it | 14:42 |
| mwilliams_ct | that's right, I knew there was a logic! | 14:42 |
| pedroalvarez | I thought that linux-api-headers (in build-essentials.morph) was installing also that, but I think is another different thing | 14:43 |
| persia | Which are you installing with kernel headers? | 14:43 |
| pedroalvarez | this is installing ZFS | 14:44 |
| mwilliams_ct | persia: ZFS and its dependency SPL | 14:44 |
| Zara_ | (skeletal import tool quickstart tutorial here; hoping will reduce duplication of wiki content: http://wiki.baserock.org/guides/import-tool-quickstart/ . Not yet linked in 'guides' because it could do with a bit of fleshing out and tidying.) | 14:44 |
| mwilliams_ct | pedroalvarez: so is there currently a better way around this? | 14:45 |
| persia | Isn't ZFS CDDL? Just be careful not to cause a binary artifact to exist that contains a single executable with both GPL and CDDL implemented symbols: that can't go through CI. | 14:45 |
| * pedroalvarez doesn't know about this | 14:47 | |
| pedroalvarez | mwilliams_ct: I was thinking that maybe the kernel headers could go in a different chunk outside the bsp? | 14:48 |
| mwilliams_ct | persia: I would think it's OK to add to definitions as it doesn't produce images or binaries? | 14:49 |
| mwilliams_ct | pedroalvarez: to clarify, a chunk would live in eg spl-generic/ ? | 14:49 |
| pedroalvarez | mwilliams_ct: maybe... bsp-generic/? Then the bsp's that need the kernel-headers can depend on it, and also zfs an spl | 14:50 |
| pedroalvarez | s/an/and/ | 14:50 |
| * Kinnison notes that the generated kernel headers / build-system includes the .config, thusly you can't easily separate it from the bsp | 14:51 | |
| Kinnison | it needs to be a chunk artifact generated from the kernel build | 14:52 |
| persia | mwilliams_ct: Only if it doesn't get used for CI, because that creates published binaries. | 14:52 |
| persia | As a result, it is not in the interest of the project to accept something that can cause such binaries to appear. That said, it is possible to create CDDL artifacts that are distributable, so can be CI. | 14:53 |
| pedroalvarez | persia: thanks for raising that important point. | 14:53 |
| persia | One just needs to create something that only contains the kernel modules (and not the kernel). The system artifact is a "collection", making it permissible to have both. | 14:53 |
| persia | You then need some magic to cause the CDDL modules to be loaded in the preboot environment in your cluster: this is usually done with an initramfs. | 14:53 |
| *** lachlanmackenzie [~lachlan@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 244 seconds] | 14:54 | |
| *** lachlanmackenzie [~lachlan@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 14:58 | |
| pedroalvarez | Kinnison: I didn't know that thanks. But in this case mwilliams_ct is using the files installed by: http://paste.baserock.org/musabomoko, which I don;t think need anything built. | 14:58 |
| Kinnison | Hmm | 14:58 |
| pedroalvarez | But yes, maybe we can't call those files "kernel-headers" | 14:58 |
| * Kinnison knows that the .config is present in what Debian installs into the kbuild dir | 14:58 | |
| pedroalvarez | mwilliams_ct: I take that your system doesn't build without using the --with-liinux option | 14:59 |
| mwilliams_ct | pedroalvarez: was just trying to test that :D | 15:00 |
| pedroalvarez | thanks for cheking :) | 15:00 |
| rdale | if i've generated a TEST system using the cycle.sh script and i've changed stuff in /etc and /var, will those changes be lost if i rebuild the TEST system again? | 15:14 |
| persia | I believe system configuration is maintained. I very strongly believe that to include /etc ,I'm less certain about /var. | 15:16 |
| persia | Maybe take a backup, then try? | 15:16 |
| paulsherwood | rdale: why not create a different system next time? then compare both? | 15:18 |
| paulsherwood | (unless you don't have space for that) | 15:18 |
| richard_maw | AIUI /etc, /var, /opt and /home are preserved, but changes made to /etc are sync'd between updates, so if TEST+1 adds a config file in /etc, it gets added to /etc of the system you run, but if TEST+1 adds files to /var you won't, as it contains only the files that were available when you first installed the system | 15:18 |
| paulsherwood | rdale: note you can specify a name as extra param for cycle, instead of the default TEST | 15:19 |
| rdale | ok, i'll take a backup of what i know i've changed, rerun a build and see what happens | 15:19 |
| rdale | TEST does describe what i'm doing, but i might try changing it in the future | 15:19 |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 15:20 | |
| paulsherwood | rdale: my point is that if you re-run cycle.sh foo bar NEWTEST, it ssohuld create NEWTEST while leaving TEST unchanged (so no need to backup TEST) | 15:21 |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 15:21 | |
| rdale | ah right - thanks | 15:21 |
| *** Kinnison [~dsilvers@gateway/shell/pepperfish/x-jvfjkxmehqmxbxuk] has quit [Remote host closed the connection] | 15:21 | |
| paulsherwood | modulo what richard_maw said, though | 15:21 |
| *** Kinnison [~dsilvers@gateway/shell/pepperfish/x-bpqnxwtyshrwtriw] has joined #baserock | 15:24 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Ping timeout: 264 seconds] | 15:26 | |
| bwh | Kinnison pedroalvarez: For building OOT modules you need at least arch/$arch/include, include, scripts, .config, Module.symvers. scripts/package/builddeb is probably the simplest example of that | 15:50 |
| Kinnison | Mmm | 15:51 |
| pedroalvarez | oh! so this ZFS is actually building a kernel module? | 15:52 |
| pedroalvarez | and that's why it needs the kernel-headers? | 15:53 |
| pedroalvarez | I see | 15:53 |
| pedroalvarez | in that case, mwilliams_ct, I don't think you will be able to build them without addding --with-linux | 16:00 |
| mwilliams_ct | pedroalvarez: no I don't think so either. Still giving it a go though ;) | 16:00 |
| pedroalvarez | taking too long uh? | 16:01 |
| persia | Just take care for the licensing of the resulting artifacts. ZFS upstream has good guidance on what is OK, and what is not OK. | 16:01 |
| mwilliams_ct | yep, currently on build 81/208. but doing other stuff so it's not too bad | 16:01 |
| pedroalvarez | mwilliams_ct: hm.. does that mean that this change cause other things to rebuild? | 16:02 |
| pedroalvarez | s/cause/caused/ | 16:02 |
| mwilliams_ct | pedroalvarez: possibly, but I think it's more likely that I typed in something wrong with morph | 16:02 |
| mwilliams_ct | Still getting used to Baserock | 16:02 |
| pedroalvarez | heh | 16:02 |
| persia | mwilliams_ct: What is rebuilding? Unless you're really knowledgeable about Baserock or very lucky, you shouldn't be able to cause spurious rebuilds by calling morph differently. | 16:03 |
| pedroalvarez | also, cache.baserock.org might help to avoid build things | 16:04 |
| persia | Isn't that default now? | 16:05 |
| mwilliams_ct | persia: two things I did that may have confused matters. firstly, I got confused between git branch and morph checkout (there is some UI confusion there and it's not well documented) and secondly, busybox was referring to a branch called my-new-system that I changed to master | 16:05 |
| paulsherwood | persia: only if it's set in morph.conf | 16:05 |
| mwilliams_ct | pedroalvarez: Think I'm using the cache in morph.conf | 16:05 |
| persia | mwilliams_ct: Ah. Yes. morph checkout can be confusing. | 16:06 |
| SotK | mwilliams_ct: changing the ref of busybox would cause such a rebuild | 16:07 |
| mwilliams_ct | SotK: that's what I figured :\ | 16:07 |
| paulsherwood | mwilliams_ct: do you have artifact-cache-server = http://cache.baserock.org:8080/ | 16:08 |
| SotK | adding "artifact-cache-server = http://cache.baserock.org:8080/" should reduce the time rebuilds take | 16:08 |
| SotK | s,should,to /etc/morph.conf should, | 16:09 |
| mwilliams_ct | paulsherwood, SotK: Yep that's in there | 16:09 |
| paulsherwood | mwilliams_ct: maybe rebase your stuff against master definitions? (if that's an option)? | 16:11 |
| paulsherwood | (and use latest morph) | 16:11 |
| mwilliams_ct | paulsherwood: I think definitions is up to date, I pulled and rebased earlier today to submit my patch. Morph won't be the absolute latest, but it should be modern enough to use the cache server. at any rate, this isn't slowing me down much as I am doing other things while waiting. As pedroalvarez has said, we think this is likely to fail anyway | 16:12 |
| pedroalvarez | indeed | 16:13 |
| pedroalvarez | mwilliams_ct: given that I'm the only one annoyed by the architectre-dependent strata of zfs and spl, I can wait until other people review the patch. | 16:14 |
| pedroalvarez | I'm not too annoyed, I just think it could be better | 16:15 |
| persia_ | I thought the entire point of OpenZFS was platform-independence | 16:17 |
| *** einonm [~einonm@81.174.139.2] has joined #baserock | 16:20 | |
| mwilliams_ct | persia_: maybe so, but currently they don't consider 32 bit stable enoug to run anyway | 16:21 |
| persia | Ah, if you're just restricting to 64-bit environments, that's fine, as long as your restriction test doesn't involve a string comparison between the architecture string and "x86_64". | 16:22 |
| persia | How are you testing processor width? | 16:22 |
| mwilliams_ct | using a ruler? | 16:22 |
| mwilliams_ct | sorry I'm not sure what you mean by processor width in this context | 16:23 |
| mwilliams_ct | give me a second to google | 16:23 |
| persia | how many bits wide is the instruction queue? | 16:23 |
| mwilliams_ct | persia: I don't know the answer, sorry | 16:23 |
| persia | Common values are 8, 16, 24, 29, 31, 32, 60, 64, 80, 128, and 256. | 16:23 |
| jmacs | Instruction queue? | 16:24 |
| * persia needs better words. | 16:24 | |
| persia | Anyway. | 16:24 |
| persia | How are you testing the architecture? | 16:24 |
| persia | And as such, how are you filtering between 64-bit and !64-bit? | 16:25 |
| mwilliams_ct | I'm not, that's a good point. Should that be in the strata? At the moment I'm just assuming that the user will guess x86_64 won't work on !64 bit | 16:25 |
| persia | My point is more that I can think of 5 64-bit architectures off the top of my head, so testing for "x86_64" is not a good test to meet the criteria demanded upstream. | 16:26 |
| rjek | persia: what is an instruction queue? Typically, a CPU is 64 bit if its registers are 64 bit wide; instructions don't tend to factor | 16:26 |
| jmacs | Neither ARMv8 or x86_64 have 64-bit instructions | 16:26 |
| persia | rjek: The result of cognitive dissonane. | 16:26 |
| persia | dissonance! | 16:26 |
| rjek | jmacs: Nor MIPS64 | 16:26 |
| jmacs | POWER does, iirc. | 16:27 |
| rjek | I don't think there's a hard-and-fast rule. | 16:27 |
| persia | SPARC64 can, optionally. | 16:27 |
| persia | I think POWER is optional as well. | 16:27 |
| rjek | sizeof(int)==8 isn't perfect | 16:27 |
| persia | ppc64 is *definitely* optional. | 16:27 |
| mwilliams_ct | I don't know enough about computer science to provide an educated comment on this. pedroalvarez is suggesting we should be able to build without concern for the architecture, which is what I'm working on so hopefully this will be irrelevant | 16:27 |
| persia | mwilliams_ct: Excellent. If it doesn't work, just make sure you have a switch statement that allows it to work for several architectures. | 16:28 |
| rjek | The only reliable solution I suspect is to hard-code a list of architectures considered to be 64 bit. :-/ | 16:28 |
| persia | I think the only 64-bit architectures we have working in Baserock today are x86_64 and POWER. | 16:28 |
| rjek | sizeof(void*) probably isn't enough to know, either | 16:28 |
| persia | Nope. | 16:28 |
| robtaylor | there are some good tests in autoconf | 16:29 |
| persia | sizeof(int*) might work though. | 16:29 |
| robtaylor | if that's appropriate | 16:29 |
| rjek | persia: There's a horrible ABI which runs AMD64 in long mode, but with 32 bit pointers. | 16:29 |
| straycat | Why would there be a difference between sizeof(void*) and sizeof(int*) ? | 16:29 |
| rjek | straycat: Yes, I'm wondering that :) | 16:29 |
| persia | straycat: Some compilers process void* in special ways, for annoying historical reasons. | 16:30 |
| *** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Ex-Chat] | 16:52 | |
| *** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has joined #baserock | 16:56 | |
| *** Krin [~mikesmith@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Remote host closed the connection] | 17:07 | |
| juergbi | rjek: I assume you're referring to x32? Why would that cause additional issues (compared to x86-32, e.g.)? | 17:16 |
| juergbi | (and I don't think that ABI is such a bad idea) | 17:16 |
| flatmush | sizeof(void*) is not guaranteed to be the same as sizeof(char*) for platforms that aren't byte addressable | 17:16 |
| juergbi | baserock supports non-byte-addressable platforms? | 17:17 |
| flatmush | I imagine on such a platform given that a void* could point to a char* then the void* would be sized differently to int* | 17:17 |
| flatmush | but you're very unlikely to run into that now, given all the major platforms support byte addressing | 17:17 |
| rjek | juergbi: The discussion was how to programatically detect if a CPU/architecture was 64 bit; x32 was an example of one that would confuse the issue if you just checked the size of pointers | 17:17 |
| persia | juergbi: The issue with x32 is that because of the narrow address space, it isn't a good target for ZFS. In other contexts, I'd agree that it is not an unreasonable ABI. | 17:17 |
| flatmush | sizeof() isn't programmatic anyway, it's determined at compile time | 17:18 |
| juergbi | rjek: it's just a userspace ABI. just like you can run x86-32 userspace with a x86-64 kernel | 17:18 |
| rjek | juergbi: Yes, I know. | 17:18 |
| juergbi | i.e., not different to x86-32 from this point of view | 17:19 |
| juergbi | as for the check, would CONFIG_64BIT from include/generated/autoconf.h be suitable? | 17:20 |
| *** wdutch [~william@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Quit] | 17:21 | |
| juergbi | and as long as you use the kernel compiler, userspace ABIs shouldn't interfere, i.e., sizeof(void *) or also sizeof(long) should work for all linux platforms, afaik | 17:21 |
| *** jonathanmaw [~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 17:25 | |
| *** sambishop [~sambishop@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 264 seconds] | 17:26 | |
| *** straycat [~straycat@fez.tardis.ed.ac.uk] has quit [Ping timeout: 244 seconds] | 17:26 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 17:27 | |
| persia | juergbi: That's a good test indeed. | 17:29 |
| persia | mwilliams_ct: If you can't make it architecture-agnostic, you might use that. | 17:30 |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 17:31 | |
| *** straycat [~straycat@fez.tardis.ed.ac.uk] has joined #baserock | 17:41 | |
| *** ssam2 [~ssam2@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 17:43 | |
| *** zoli_ [~zoli_@linaro/zoli] has joined #baserock | 17:45 | |
| *** jmalk [~josh@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 17:48 | |
| jmacs | "ERROR: Git directory /src/workspace/jmac-merged-branch/git@github.com/jmacarthur/definitions.git has no commit at ref refs/heads/baserock/builds/590358d577..." | 17:54 |
| jmacs | I'm not sure what morph is telling me | 17:54 |
| richard_maw | could this be related to the recent change allowing you to avoid creating a temporary build branch? | 17:55 |
| pedroalvarez | has it been merged? | 17:56 |
| jmacs | I doubt I have that change | 17:56 |
| *** locallycompact [~lc@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 240 seconds] | 17:58 | |
| *** bashrc_ [~motters@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Lost terminal] | 18:00 | |
| jmacs | Just deleted my working directory and did a 'morph checkout' again and I'm getting the same error | 18:20 |
| *** Guest93509 [~mike@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Leaving] | 18:27 | |
| * jmacs tears hair out | 18:31 | |
| *** straycat_ [~straycat@fez.tardis.ed.ac.uk] has joined #baserock | 18:41 | |
| *** mariaderidder [~maria@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Quit: Ex-Chat] | 18:42 | |
| *** tiagogomes [~tiagogome@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 245 seconds] | 18:44 | |
| *** straycat [~straycat@fez.tardis.ed.ac.uk] has quit [Quit: Lost terminal] | 19:11 | |
| straycat_ is now known as straycat | 19:11 | |
| *** lachlanmackenzie [~lachlan@82-70-136-246.dsl.in-addr.zen.co.uk] has quit [Ping timeout: 255 seconds] | 19:22 | |
| *** zoli_ [~zoli_@linaro/zoli] has quit [Remote host closed the connection] | 19:48 | |
| *** locallycompact [~lc@253.175.125.91.dyn.plus.net] has joined #baserock | 22:15 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!