IRC logs for #baserock for Thursday, 2016-09-08

*** fay has joined #baserock06:44
*** fay is now known as faybrocklebank06:45
*** gtristan has quit IRC07:09
*** paulwaters_ has joined #baserock07:30
*** paulwaters_ has quit IRC07:32
*** franred has quit IRC07:40
*** franred has joined #baserock07:41
*** CTtpollard has joined #baserock07:56
*** jonathanmaw has joined #baserock08:42
*** tiagogomes_ has joined #baserock09:27
*** rdale_ct has quit IRC09:30
*** rdale has joined #baserock09:43
*** locallycompact has joined #baserock09:48
baserockgerritJavier Jardón proposed baserock/baserock/definitions: .gitlab-ci.yml: Add build-system-x86_64
baserockgerritJavier Jardón proposed baserock/baserock/definitions: Add clusters/build-system-x86_64-chroot-deploy.morph
baserockgerritJavier Jardón proposed baserock/baserock/definitions: .gitlab-ci.yml: deploy build-system-x86_64 rootfs
baserockgerritMerged baserock/baserock/definitions: .gitlab-ci.yml: deploy build-system-x86_64 rootfs
baserockgerritMerged baserock/baserock/definitions: Add clusters/build-system-x86_64-chroot-deploy.morph
baserockgerritMerged baserock/baserock/definitions: .gitlab-ci.yml: Add build-system-x86_64
*** gtristan has joined #baserock11:14
paulsherwoodwin 2111:16
jjardonpedroalvarez: thanks for the reviews11:21
pedroalvarezjjardon: yw :)11:21
jjardonbenefit of this: for every change in master, you can download a baserock x86_64 rootfs from here:
pedroalvarezalthough I'm still worried about using gitlab free resources to do this11:23
locallycompactthey have better colours than our instance11:24
paulsherwoodpedroalvarez: why are you worried?11:25
pedroalvarezI don't think their CI was created for building OS's11:26
pedroalvarezI expect they will limit the use at some point11:26
paulsherwoodthat's fine... we can set up our own runners then11:27
paulsherwoodbut in any case some of us here have a healthy relationship with gitlab11:27
*** franred_ has joined #baserock11:35
*** franred has quit IRC11:35
leemingspeaking of runners... do we know what distro/kernel they are running?12:56
leemingor if there is any options for that12:57
leemingI ask, as bubblewrap doesn't seemt to build/work on some older kernels12:59
jjardonHi, In a x86_64, what is the  convention in baserock? /usr/lib64 -> /usr/lib, /usr/lib32 -> /usr/lib, none ?12:59
jjardonleeming: I guess better ask that in #gitlab?13:00
jjardonor wait, let me quickly check13:01
leemingwell, i thought i'd ask the users first :P13:01
gtristanjjardon, 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 multilib13:02
gtristanjjardon, 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 lib6413:03
gtristanso 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
jjardonyeah, but we can enforce a convention if we create a symlink (/usr/lib64 -> /usr/lib, for example) when we create the filesystem in fhs-dirs13:04
jjardonleeming: kernel 4.7.0, Debian 8 (jessie)
leemingthanks jjardon  (checks his notes)13:05
leemingah yes, that is more than enough, good13:05
gtristanjjardon, not sure that would be "enforcing a convention", rather some libraries/apps may be accessing things via /usr/lib and others via /usr/lib6413:08
gtristanfeels like a symlink hack to work around messy build scripts which dont behave13:08
pedroalvarezjjardon: I believe we have always tried to put everything in /usr/lib13:14
*** franred_ is now known as franred13:22
baserockgerritJavier Jardón proposed baserock/baserock/definitions: .gitlab-ci.yml: name the artifacts
baserockgerritMerged baserock/baserock/definitions: .gitlab-ci.yml: name the artifacts
jjardonpedroalvarez: thanks!13:43
pedroalvarezmoar patches!13:48
*** gtristan has quit IRC15:07
*** gtristan has joined #baserock15:26
richard_mawjjardon: 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 simplify15:30
richard_mawat least in the case of the mv implementation, it's missing all the features15:30
jjardonmmm, seems the bot missed this MR:
richard_mawas they don't handle falling back to a copy in the case of rename() failing15:31
franredjjardon, it also misses that I have merged it15:32
locallycompactjjardon, everything in rust by 2020!15:34
pedroalvarezhm.. buggy bot15:34
pedroalvarezbot saw the events, but failed to report15:35
richard_mawlocallycompact: if that's to happen then you'll need reimplementers to have a better understanding of the tools they seek to replace15:37
locallycompactI don't need that at all, sorry.15:38
richard_mawlocallycompact: then you won't have everything in rust15:40
richard_mawthe 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 sufficient15:43
richard_mawthe amount of metadata you need to copy is impressively non-trivial15:43
richard_mawwhy what?15:44
richard_mawwhy does mv need to be able to move files between filesystems?15:44
rjekHmm, does mv try to keep the atomic semantics when it has to fall back to cp-and-rm?15:45
locallycompactNot following sorry15:46
locallycompactWhat does it do and what does it not do and is this also a problem on redox15:47
richard_mawrjek: not from what I remember when looking over the source, though I've got ideas on how to do so15:47
rjekI bet they're disgusting. :)15:49
richard_mawrjek: 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 place15:51
richard_mawlocallycompact: 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 one15:55
locallycompactand it doesn't do that?15:55
richard_mawwhy are you asking me when I don't know redox?15:56
richard_mawthe linked coreutils reimplementation is for linux, and doesn't do things that are required of it on linux15:56
rjekrichard_maw: Are you suggesting a language hipster might not quite grasp how terrible UNIX is?15:59
*** baserockgerrit has quit IRC15:59
*** baserockgerrit has joined #baserock15:59
locallycompactgiven 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 all16:01
richard_mawrjek: I'm skeptical of any reimplementation that hasn't learned the lessons of what it intends to reimplement.16:02
rjekI think everyone should be.16:02
locallycompactI think you're very wrong on that matter16:02
locallycompactThe lesson is very clear16:02
locallycompactUnivalence all the way down.16:02
richard_mawcare to define univalence for the non-mathematically educated?16:02
locallycompactUnivalence is the principle that all isomorphic structures can be identified.16:03
locallycompactIt's what distinguishes type theory from set theory, essentially16:04
rjekrichard_maw: The answer is no16:04
*** toscalix has joined #baserock16:05
locallycompactSet theory comes in two parts, classical logic and the set theory axioms, type theory is its own logic16:06
locallycompactIt'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 them16:09
locallycompactIt's not a deductive process16:09
locallycompactAnd one always knows what type the thing they have is or they wouldn't have it.16:11
jjardonAny idea why coreutils-tarball is not in, neither in ?16:14
pedroalvarezit's just coreutils16:15
franredjjardon, ?16:16
jjardonfranred: I promise it was not there! :) cheers16:17
pedroalvarezjjardon: I guess you couldn't use the git version because you want to put that really low in the stack?16:18
jjardonpedroalvarez: correct. I'm trying to replace busybox16:20
franredjjardon, would be that safe in term of licenses?16:21
franredI though we keep busybox because some of the replacement tools were lgplv316:21
franredor gpl316:21
pedroalvarezfranred: hehe, haven't you read the commit message of what you have reviewed?16:22
* pedroalvarez runs16:22
franredpedroalvarez, I've read it16:22
franredbut coreutils do not replace all the tools in busybox, AFAIK16:22
pedroalvarezoh, yes, that's another thing16:22
jjardonfranred: yep, Im aware of that16:23
pedroalvarezbut for now he is including a very old version that is GPLv216:23
pedroalvarezI didn't know that jjardon and *very old versions* were compatible :P16:23
*** rdale has quit IRC16:24
richard_mawyou can use GPLv3 stuff in the bootstrap without making the result system GPLv316:24
rjekf.ex: gcc16:24
jjardonpedroalvarez: :)16:25
*** toscalix has quit IRC16:29
*** edcragg has quit IRC16:34
*** rdale has joined #baserock16:42
*** jonathanmaw has quit IRC16:48
*** locallycompact has quit IRC16:52
*** tiagogomes_ has quit IRC17:24
*** CTtpollard has quit IRC17:39
*** locallycompact has joined #baserock20:24
*** gtristan has quit IRC21:06
*** locallycompact has quit IRC21:11
richard_maweww, 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 atomicity22:27

Generated by 2.15.3 by Marius Gedminas - find it at!