| *** fay has joined #baserock | 06:44 | |
| *** fay is now known as faybrocklebank | 06:45 | |
| *** gtristan has quit IRC | 07:09 | |
| *** paulwaters_ has joined #baserock | 07:30 | |
| *** paulwaters_ has quit IRC | 07:32 | |
| *** franred has quit IRC | 07:40 | |
| *** franred has joined #baserock | 07:41 | |
| *** CTtpollard has joined #baserock | 07:56 | |
| *** jonathanmaw has joined #baserock | 08:42 | |
| *** tiagogomes_ has joined #baserock | 09:27 | |
| *** rdale_ct has quit IRC | 09:30 | |
| *** rdale has joined #baserock | 09:43 | |
| *** locallycompact has joined #baserock | 09:48 | |
| baserockgerrit | Javier Jardón proposed baserock/baserock/definitions: .gitlab-ci.yml: Add build-system-x86_64 https://gerrit.baserock.org/2285 | 10:52 |
|---|---|---|
| baserockgerrit | Javier Jardón proposed baserock/baserock/definitions: Add clusters/build-system-x86_64-chroot-deploy.morph https://gerrit.baserock.org/2286 | 10:52 |
| baserockgerrit | Javier Jardón proposed baserock/baserock/definitions: .gitlab-ci.yml: deploy build-system-x86_64 rootfs https://gerrit.baserock.org/2287 | 10:52 |
| baserockgerrit | Merged baserock/baserock/definitions: .gitlab-ci.yml: deploy build-system-x86_64 rootfs https://gerrit.baserock.org/2287 | 11:03 |
| baserockgerrit | Merged baserock/baserock/definitions: Add clusters/build-system-x86_64-chroot-deploy.morph https://gerrit.baserock.org/2286 | 11:03 |
| baserockgerrit | Merged baserock/baserock/definitions: .gitlab-ci.yml: Add build-system-x86_64 https://gerrit.baserock.org/2285 | 11:03 |
| *** gtristan has joined #baserock | 11:14 | |
| paulsherwood | win 21 | 11:16 |
| paulsherwood | feck | 11:16 |
| jjardon | pedroalvarez: thanks for the reviews | 11:21 |
| pedroalvarez | jjardon: yw :) | 11:21 |
| jjardon | benefit of this: for every change in master, you can download a baserock x86_64 rootfs from here: https://gitlab.com/baserock/definitions/pipelines | 11:22 |
| pedroalvarez | cool | 11:23 |
| pedroalvarez | although I'm still worried about using gitlab free resources to do this | 11:23 |
| locallycompact | they have better colours than our instance | 11:24 |
| paulsherwood | pedroalvarez: why are you worried? | 11:25 |
| pedroalvarez | I don't think their CI was created for building OS's | 11:26 |
| pedroalvarez | I expect they will limit the use at some point | 11:26 |
| paulsherwood | that's fine... we can set up our own runners then | 11:27 |
| paulsherwood | but in any case some of us here have a healthy relationship with gitlab | 11:27 |
| *** franred_ has joined #baserock | 11:35 | |
| *** franred has quit IRC | 11:35 | |
| leeming | speaking of runners... do we know what distro/kernel they are running? | 12:56 |
| leeming | or if there is any options for that | 12:57 |
| leeming | I ask, as bubblewrap doesn't seemt to build/work on some older kernels | 12:59 |
| jjardon | Hi, In a x86_64, what is the convention in baserock? /usr/lib64 -> /usr/lib, /usr/lib32 -> /usr/lib, none ? | 12:59 |
| jjardon | leeming: I guess better ask that in #gitlab? | 13:00 |
| jjardon | or wait, let me quickly check | 13:01 |
| leeming | well, i thought i'd ask the users first :P | 13:01 |
| gtristan | jjardon, I think since baserock does not do multilib, the convention is only /usr/lib, however... it seems to me that various packages and build systems take it upon themselves to assume multilib | 13:02 |
| gtristan | jjardon, what I've noticed in the past weeks for instance, any cmake modules, if not given the -DCMAKE_INSTALL_LIBDIR=lib explicitly, if building for a 64bit target, assumes lib64 | 13:03 |
| gtristan | so it's quite possible that just not a lot of attention has been given to ensuring there is no lib64 lurking around (as it's generally harmless... until it isnt) | 13:03 |
| jjardon | yeah, but we can enforce a convention if we create a symlink (/usr/lib64 -> /usr/lib, for example) when we create the filesystem in fhs-dirs | 13:04 |
| jjardon | leeming: kernel 4.7.0, Debian 8 (jessie) https://gitlab.com/baserock/definitions/builds/3865988 | 13:05 |
| leeming | thanks jjardon (checks his notes) | 13:05 |
| leeming | ah yes, that is more than enough, good | 13:05 |
| gtristan | jjardon, not sure that would be "enforcing a convention", rather some libraries/apps may be accessing things via /usr/lib and others via /usr/lib64 | 13:08 |
| gtristan | feels like a symlink hack to work around messy build scripts which dont behave | 13:08 |
| pedroalvarez | jjardon: I believe we have always tried to put everything in /usr/lib | 13:14 |
| *** franred_ is now known as franred | 13:22 | |
| baserockgerrit | Javier Jardón proposed baserock/baserock/definitions: .gitlab-ci.yml: name the artifacts https://gerrit.baserock.org/2288 | 13:28 |
| baserockgerrit | Merged baserock/baserock/definitions: .gitlab-ci.yml: name the artifacts https://gerrit.baserock.org/2288 | 13:32 |
| jjardon | pedroalvarez: thanks! | 13:43 |
| pedroalvarez | moar patches! | 13:48 |
| *** gtristan has quit IRC | 15:07 | |
| jjardon | interesting: https://github.com/uutils/coreutils | 15:20 |
| *** gtristan has joined #baserock | 15:26 | |
| richard_maw | jjardon: a) I'm grumpy about the suggestion that it's fine to set build configuration variables on the make command-line and b) it looks like they've made the same old mistake and assumed they can simplify | 15:30 |
| richard_maw | at least in the case of the mv implementation, it's missing all the features | 15:30 |
| jjardon | mmm, seems the bot missed this MR: https://gerrit.baserock.org/#/c/2289/ | 15:31 |
| richard_maw | as they don't handle falling back to a copy in the case of rename() failing | 15:31 |
| franred | jjardon, it also misses that I have merged it | 15:32 |
| locallycompact | jjardon, everything in rust by 2020! | 15:34 |
| pedroalvarez | hm.. buggy bot | 15:34 |
| pedroalvarez | bot saw the events, but failed to report | 15:35 |
| richard_maw | locallycompact: if that's to happen then you'll need reimplementers to have a better understanding of the tools they seek to replace | 15:37 |
| locallycompact | I don't need that at all, sorry. | 15:38 |
| richard_maw | locallycompact: then you won't have everything in rust | 15:40 |
| richard_maw | the most trivial-sounding example, mv *needs* to be able to fall back to copying the file and removing the old one, and just copying the data is not sufficient | 15:43 |
| richard_maw | the amount of metadata you need to copy is impressively non-trivial | 15:43 |
| locallycompact | Why | 15:43 |
| richard_maw | why what? | 15:44 |
| richard_maw | why does mv need to be able to move files between filesystems? | 15:44 |
| rjek | Hmm, does mv try to keep the atomic semantics when it has to fall back to cp-and-rm? | 15:45 |
| locallycompact | Not following sorry | 15:46 |
| locallycompact | What does it do and what does it not do and is this also a problem on redox | 15:47 |
| richard_maw | rjek: not from what I remember when looking over the source, though I've got ideas on how to do so | 15:47 |
| rjek | I bet they're disgusting. :) | 15:49 |
| richard_maw | rjek: O_TMPFILE and linkat if your process is able to do so, otherwise fall back to doing the copy into a temporary file in the directory and renaming it into place | 15:51 |
| rjek | Nod | 15:51 |
| richard_maw | locallycompact: I can't answer whether it's a problem for redox, since I don't know what it intends to be, but if it intends to support filesystem-based storage and the ability to have removable storage you need to have the syscall layer distinguish between a fast rename and a slow one, and if you have a userland then you'll probably want your tools to be able to fall back to the slow one | 15:55 |
| locallycompact | and it doesn't do that? | 15:55 |
| richard_maw | why are you asking me when I don't know redox? | 15:56 |
| richard_maw | the linked coreutils reimplementation is for linux, and doesn't do things that are required of it on linux | 15:56 |
| locallycompact | oh | 15:57 |
| rjek | richard_maw: Are you suggesting a language hipster might not quite grasp how terrible UNIX is? | 15:59 |
| *** baserockgerrit has quit IRC | 15:59 | |
| *** baserockgerrit has joined #baserock | 15:59 | |
| locallycompact | given that it's C I'm interested in benching, I don't really have any reason to care about linux or care whether redox is UNIX compatible at all | 16:01 |
| richard_maw | rjek: I'm skeptical of any reimplementation that hasn't learned the lessons of what it intends to reimplement. | 16:02 |
| rjek | I think everyone should be. | 16:02 |
| locallycompact | I think you're very wrong on that matter | 16:02 |
| locallycompact | The lesson is very clear | 16:02 |
| locallycompact | Univalence all the way down. | 16:02 |
| richard_maw | care to define univalence for the non-mathematically educated? | 16:02 |
| locallycompact | Univalence is the principle that all isomorphic structures can be identified. | 16:03 |
| locallycompact | It's what distinguishes type theory from set theory, essentially | 16:04 |
| rjek | richard_maw: The answer is no | 16:04 |
| *** toscalix has joined #baserock | 16:05 | |
| locallycompact | Set theory comes in two parts, classical logic and the set theory axioms, type theory is its own logic | 16:06 |
| locallycompact | It's largely now considered impossible to prove two things isomorphic in set theory, because that's not what happens. What happens is you spot by intuition that two things are isomorphic and that allows you to identify them | 16:09 |
| locallycompact | It's not a deductive process | 16:09 |
| locallycompact | And one always knows what type the thing they have is or they wouldn't have it. | 16:11 |
| jjardon | Any idea why coreutils-tarball is not in http://git.baserock.org, neither in http://git.baserock.org/lc-status.html ? | 16:14 |
| pedroalvarez | it's just coreutils | 16:15 |
| franred | jjardon, http://git.baserock.org/cgit/delta/coreutils-tarball.git/ ? | 16:16 |
| jjardon | franred: I promise it was not there! :) cheers | 16:17 |
| franred | :) | 16:17 |
| pedroalvarez | jjardon: I guess you couldn't use the git version because you want to put that really low in the stack? | 16:18 |
| jjardon | pedroalvarez: correct. I'm trying to replace busybox | 16:20 |
| franred | jjardon, would be that safe in term of licenses? | 16:21 |
| franred | I though we keep busybox because some of the replacement tools were lgplv3 | 16:21 |
| franred | or gpl3 | 16:21 |
| pedroalvarez | franred: hehe, haven't you read the commit message of what you have reviewed? | 16:22 |
| * pedroalvarez runs | 16:22 | |
| franred | pedroalvarez, I've read it | 16:22 |
| franred | but coreutils do not replace all the tools in busybox, AFAIK | 16:22 |
| franred | AFAICR | 16:22 |
| pedroalvarez | oh, yes, that's another thing | 16:22 |
| jjardon | franred: yep, Im aware of that | 16:23 |
| pedroalvarez | but for now he is including a very old version that is GPLv2 | 16:23 |
| pedroalvarez | I didn't know that jjardon and *very old versions* were compatible :P | 16:23 |
| *** rdale has quit IRC | 16:24 | |
| franred | hahaha | 16:24 |
| richard_maw | you can use GPLv3 stuff in the bootstrap without making the result system GPLv3 | 16:24 |
| rjek | f.ex: gcc | 16:24 |
| jjardon | pedroalvarez: :) | 16:25 |
| *** toscalix has quit IRC | 16:29 | |
| *** edcragg has quit IRC | 16:34 | |
| *** rdale has joined #baserock | 16:42 | |
| *** jonathanmaw has quit IRC | 16:48 | |
| *** locallycompact has quit IRC | 16:52 | |
| *** tiagogomes_ has quit IRC | 17:24 | |
| *** CTtpollard has quit IRC | 17:39 | |
| *** locallycompact has joined #baserock | 20:24 | |
| *** gtristan has quit IRC | 21:06 | |
| *** locallycompact has quit IRC | 21:11 | |
| richard_maw | eww, turns out when mv falls back to copy and unlink, it's mandated by specification that it creates or truncates the desination file, thereby clobbering the target file's contents if it were put there after it checked whether there was a destination, and forbidding the possibility of atomicity | 22:27 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!