| *** toscalix has quit IRC | 02:27 | |
| *** gtristan has joined #baserock | 05:16 | |
| gtristan | what is git-minimal really required for in core.morph ? | 05:44 |
|---|---|---|
| gtristan | i.e. bison and util-linux both build-depend on git-minimal, any reason they should ? | 05:44 |
| gtristan | maybe cruft from the olden days when git submodules were checked out in the sandbox ? | 05:45 |
| paulsherwood | gtristan: i think it's more cruft from when baserock was all self-contained, and we wanted git on all systems | 06:43 |
| *** fay has joined #baserock | 07:02 | |
| *** fay is now known as Guest77498 | 07:03 | |
| *** Guest77498 is now known as faybrocklebank | 07:03 | |
| gtristan | paulsherwood, I was more wondering why specific chunks were directly depending on it | 07:03 |
| paulsherwood | user error, i think | 07:04 |
| paulsherwood | actually, i think i'm wrong | 07:06 |
| paulsherwood | http://git.baserock.org/cgit/baserock/baserock/definitions.git/commit/?id=da1badcc76be85d324f8b9c1c34fbe2274a49ac1 | 07:07 |
| paulsherwood | gtristan: ^^ | 07:07 |
| gtristan | paulsherwood, "chunks such as libtool depend on git" that sounds bogus :-/ | 07:30 |
| gtristan | unless there is another reason, i.e. libtool has gnulib submodule maybe ? | 07:30 |
| gtristan | "libxml2 depends on git" :-/ | 07:31 |
| gtristan | anyway, not so important | 07:31 |
| *** jonathanmaw has joined #baserock | 08:05 | |
| pedroalvarez | i don't think it's cruft. Some chunks require git to build | 08:09 |
| pedroalvarez | If git is in core, it's because is needed | 08:09 |
| gtristan | pedroalvarez, you dont think it's because at some time, it was needed to checkout submodules ? | 08:11 |
| jjardon | pedroalvarez is rigth | 08:11 |
| pedroalvarez | gtristan: nope | 08:11 |
| gtristan | pedroalvarez, I dont think there is any way at all, that libxml2 actually requires or uses git in any way | 08:11 |
| pedroalvarez | some chunks, require it just to set the version number of the tool you are building from git, with a git-describe or somethin like that | 08:12 |
| pedroalvarez | that might be the case with some of the chunks you are mentioning | 08:12 |
| pedroalvarez | I believe we looked at removing those dependencies quite recently, so i believe we made the right decision | 08:13 |
| jjardon | gtristan: http://git.baserock.org/cgit/delta/libxml2.git/tree/configure.ac#n33 | 08:14 |
| pedroalvarez | thanks jjardon | 08:15 |
| gtristan | jjardon, I see | 08:17 |
| pedroalvarez | regarding ybd failing when pointing to a morph file tha doesn't exist, I think that would be good. Although I wonder when was this broken in definitions.git and why we never fixed it when using morph | 08:17 |
| gtristan | that is arguably a bug in the configure script, to make the assumption that because you have a .git directory, that git is installed, but on the other hand it's usually a relatively safe assumption | 08:18 |
| paulsherwood | pedroalvarez: it was a bug in definitions a long time ago, has been fixed some time ago. morph didn't spot it because morph only parses what it needs for a given run, whereas ybd parses all definitions every time | 08:19 |
| pedroalvarez | oh, I see | 08:26 |
| *** locallycompact has joined #baserock | 08:53 | |
| *** edcragg has joined #baserock | 08:53 | |
| pedroalvarez | paulsherwood: cannot you mark the definition as faulty, and only fail if that definition is being used? | 08:54 |
| pedroalvarez | my point of view in definitions versions is that it helps to keep the build tools free of old code | 08:55 |
| paulsherwood | pedroalvarez: that's a good idea, thanks! | 08:56 |
| paulsherwood | pedroalvarez: wrt definitions versions - i don't think your theory is correct :) | 08:58 |
| pedroalvarez | heh I wouldn't call it a theory | 08:59 |
| pedroalvarez | we removed loads of code when we stopped supporting some old versions | 08:59 |
| paulsherwood | at the expense of breaking morph for users, iiuc | 09:00 |
| * paulsherwood is happy at the idea of removing loads of code, though | 09:01 | |
| pedroalvarez | well, you could call them "flag-days", I would call them change the definitons version | 09:01 |
| pedroalvarez | what I mean is that you were suggesting doing something similar in your "Downstream metadata" email. Breaking ybd for users at a given day | 09:03 |
| paulsherwood | pedroalvarez: as i tried to explain in http://wiki.baserock.org/back-and-forth/ there are too many moving parts. if upgrading morph causes users to have to upgrade definitions, or vice-versa, while also wresting with their version of 'baserock system' it's unworkable | 09:03 |
| pedroalvarez | what if the build tool itself says: "Hey, this is an old version of definitions, do you want me to upgrade them?" | 09:04 |
| pedroalvarez | Y/n: | 09:04 |
| pedroalvarez | that would be more user friendly | 09:04 |
| pedroalvarez | but yes, still users would have to upgrade definitions | 09:05 |
| *** tiagogomes has joined #baserock | 09:05 | |
| paulsherwood | it's an interesting idea. doesn't sit well with our stated philosophy of very long term reproducibility | 09:05 |
| locallycompact | if the build tool is capable of detecting that it's capable of parsing it and using it. | 09:06 |
| paulsherwood | ack | 09:06 |
| pedroalvarez | I remember using a build tool that would upgrade/downgrade itself to the version needed to parse the "definitions" | 09:06 |
| locallycompact | but still nice | 09:06 |
| pedroalvarez | anyway, I still think that versioning definitions could help us moving forward without creating spaghetti code | 09:08 |
| paulsherwood | pedroalvarez: i agree versioning is a helpful part of the puzzle, but i don't think we've got the approach 'right' yet | 09:09 |
| * pedroalvarez nods | 09:10 | |
| pedroalvarez | I have the same feeling, maybe a bit more decided that is useful right now | 09:10 |
| paulsherwood | is thera a way to delete from paste.baserock.org? | 09:11 |
| pedroalvarez | not from the UI, I could try to go to the database if this is important | 09:14 |
| paulsherwood | it's not important, i overreacted :) | 09:16 |
| paulsherwood | thanks though | 09:16 |
| paulsherwood | i'll know for next time | 09:16 |
| *** gtristan has quit IRC | 09:52 | |
| *** brlogger has joined #baserock | 09:55 | |
| *** gary_perkins has quit IRC | 09:58 | |
| *** gary_perkins has joined #baserock | 09:59 | |
| paulsherwood | would this be of interest? https://github.com/devcurmudgeon/fhs-dirs/commit/af7602871612ab1ded50d644fd9332a691f5204d | 10:10 |
| paulsherwood | background, i'm trying to create an unusual dir layout, want to re-use fhs-dirs by feeding it parameters instead of hacking the script | 10:11 |
| * locallycompact likes | 10:12 | |
| persia | Personally, I think you ought use a replacement chunk or something. FHS implies "Standard" | 10:12 |
| paulsherwood | ack | 10:13 |
| persia | Note that I like the code, just not the name :) | 10:14 |
| paulsherwood | persia: well, to be clear, the default data there would deliver FHS 'standard' (although i need to test) | 10:14 |
| paulsherwood | so it would only do something non-standard if user feeds it nonstandard data | 10:14 |
| persia | Yes, but if I use something called file-hierarchy-standard, I'll be surprised if I can get nonstandard results. | 10:14 |
| persia | Whereas, if I used something like make-file-hierarchy that can take standard-layout.data or my-layout.data, I'm less surprised. | 10:15 |
| paulsherwood | ok, maybe i'll create a new thing to achieve that then | 10:15 |
| richard_maw | systemd's tmpfiles stuff does this kind of thing | 10:16 |
| richard_maw | it's designed for making the directory layout on boot, but it can also be used at other times | 10:16 |
| persia | richard_maw: Would it work sensibly in a chroot, where we may not have full access to host tooling (or daemons)? | 10:18 |
| paulsherwood | richard_maw: my use-case can not assume that systemd is present | 10:19 |
| paulsherwood | but it's interesting there are other ways to do this | 10:19 |
| paulsherwood | is the ln /proc/mounts /etc/mtab part of FHS also? | 10:20 |
| richard_maw | persia: Fairly sure it doesn't talk to any daemons, it works by taking config files or reading its default paths | 10:20 |
| richard_maw | paulsherwood: not sure, but modern linux systems don't work so well if you don't do it | 10:21 |
| paulsherwood | richard_maw: tvm | 10:21 |
| persia | http://www.pathname.com/fhs/pub/fhs-2.3.html is the official reference | 10:21 |
| paulsherwood | persia: so 'make-file-hierarchy' is better than 'create-directories' ? | 10:22 |
| persia | Having /etc/mtab is required by FHS, but how it gets there can be implemented lots of different ways. Using /proc/mounts means the kernel becomes responsible. | 10:22 |
| persia | paulsherwood: I'm fine with "create-directories". I was only opposed to "*standard*" that could generate non-standard results. | 10:23 |
| paulsherwood | ok thanks | 10:23 |
| *** vgrade12 has joined #baserock | 10:26 | |
| *** jonathanmaw has quit IRC | 10:27 | |
| *** jonathanmaw has joined #baserock | 10:27 | |
| paulsherwood | https://github.com/devcurmudgeon/create-dirs | 10:33 |
| * paulsherwood needs to stop yak-shaving, now, and do the thing | 10:34 | |
| pedroalvarez | paulsherwood: btw, maybe a bit messy all in one commit, but this would be moving all genivi-related definitions to a subfolder: http://git.baserock.org/cgit/baserock/baserock/definitions.git/commit/?h=baserock/pedroalvarez/definitions-genivi-subfolder&id=5472fa81ed9eacbe11f48daac8aa1f4808de1982 | 10:43 |
| *** edcragg has quit IRC | 10:46 | |
| paulsherwood | why not juss s/definitions-genivi/genivi/ ? | 10:53 |
| pedroalvarez | wanted to go with definitions-genivi because it will be easier to go to "genivi" if wanted than the other way around | 10:54 |
| pedroalvarez | can be just "genivi", but not sure if it will be clear that they contain definitions as well | 10:55 |
| persia | That the repo is definitions.git is a strong hint | 11:05 |
| paulsherwood | :) | 11:05 |
| * pedroalvarez calls it meta-genivi | 11:06 | |
| persia | The reduction to absurdity argument has as an example /root-usr/root-usr-local/root-usr-local-share/ | 11:06 |
| paulsherwood | pedroalvarez: shame on you :) | 11:10 |
| *** CTtpollard has quit IRC | 11:18 | |
| *** CTtpollard has joined #baserock | 11:19 | |
| pedroalvarez | New Changes: | 11:19 |
| pedroalvarez | https://gerrit.baserock.org/2271 Move GENIVI definitions to 'genivi' subfolder | 11:19 |
| paulsherwood | +1, i can maybe try a build later | 11:20 |
| pedroalvarez | ta! | 11:31 |
| pedroalvarez | rebuild may be no-op if it was already cached | 11:32 |
| paulsherwood | pedroalvarez: sadly not. paths are part of the cache-key | 11:35 |
| paulsherwood | (for ybd at least) | 11:38 |
| pedroalvarez | hm.. | 11:39 |
| pedroalvarez | any reason for that? | 11:39 |
| paulsherwood | actually, maybe i'm wrong | 11:40 |
| *** gtristan has joined #baserock | 11:47 | |
| persia | If path-of-definition-in-repo is a cache-key element, why? What part of definitions breaks as a result of renaming a file? How would this be expected to modify a build (assuming same definition inside the file)? | 11:57 |
| paulsherwood | yes, i agree. i'm trying to reinsert the logic in my brain | 11:59 |
| paulsherwood | path is used as unique key for each definition in ybd | 12:00 |
| paulsherwood | can't use names, because names are missing in some cases, and unique in others | 12:00 |
| paulsherwood | each build-depend is referred to by its path, also | 12:01 |
| paulsherwood | hence, paths of build-dpends of foo are in cache-key for foo | 12:02 |
| persia | I see the logic, and have to agree that, given the implementation, it is sensible. I still believe it to be wrong, at a deep level. | 12:03 |
| persia | (but something to fix in yet-another-respin, rather than something to address with current definitions, or tooling expected to process it, especially considering the defintions-versioning discussion earlier) | 12:04 |
| paulsherwood | well, in the absence of a unique names, i couldn't see how else to key definitions | 12:04 |
| persia | Yes. The correct solution is to have, and enforce unique names. | 12:04 |
| persia | That requires a change of such significance, that it is not consistent with long-term support of existing defintions. | 12:04 |
| pedroalvarez | by the contents of the thing and not by the name/path? | 12:04 |
| paulsherwood | i gave up arguing on that. | 12:04 |
| persia | But it is only by exploring this space that we learn such rules, so have a chance of actually making something that works. | 12:05 |
| paulsherwood | pedroalvarez: that might be quite neat actually | 12:05 |
| * pedroalvarez bows | 12:06 | |
| paulsherwood | but i think it would require an extra pass.. since we can't hash the contents of the thing until we've collected it all | 12:06 |
| paulsherwood | ie thing may be a chunk, in which case its contents are (probably but not always) split across two files | 12:08 |
| *** toscalix has joined #baserock | 12:08 | |
| paulsherwood | similarly stratum has its contents spread across the chunk morph files too, etc | 12:08 |
| paulsherwood | and my head hurts now :) | 12:09 |
| persia | I don't think hashing is safe for that: I think we'd want to compare definitons content either as text or as some other well-known representation. | 12:09 |
| paulsherwood | like yaml? :) | 12:09 |
| persia | That would be text | 12:10 |
| *** tiagogomes has left #baserock | 12:10 | |
| *** tiagogomes has joined #baserock | 12:11 | |
| persia | If there were other advantages to using a non-text serialisation format, comparing that might work also. | 12:11 |
| persia | One of the risks with YAML is that one can construct two different text files with YAML that have the same logical content, as applied for a given definition. | 12:11 |
| persia | But if one uses a fairly simple serialisation output mechanism, one is likely to get the same output YAML from both inputs. | 12:12 |
| persia | so validation of identity by textual comparison of generated YAML should be safe. | 12:12 |
| jjardon | persia: mtab can only be a symlink to /process/self/mounts . At least if you use systemd | 12:13 |
| persia | jjardon: systemd breaks if it detects it is not a symlink, or does it just expect the same content? | 12:13 |
| persia | Any reason I couldn't (assuming I had too many CPU cycles), use inotify to see changes in the kernel-view of mounted filesystems, and write a text file to /etc/mtab on each change? | 12:14 |
| * persia thinks this would be a poor implementation, fragile, and prone to error, but wants to understand if systemd is unable to deal with systems that are broken by design) | 12:14 | |
| jjardon | AFAIK it breaks in recent versions | 12:15 |
| * persia is insufficiently motivated to test this and file a FHS-compliance bug against systemd if it is true | 12:17 | |
| richard_maw | systemd uses libmount and systemd's NEWS file claims libmount breaks without it, and the default configuration of systemd-tmpfiles will remove /etc/mtab and turn it into a symlink to /proc/self/mounts | 12:23 |
| richard_maw | https://sourceware.org/bugzilla/show_bug.cgi?id=19108 might be of interest | 12:24 |
| persia | Oh, heh. Yes, pitti doesn't really care about FHS, and routinely breaks it (causing the rest of the world to play catch-up). There still exists the bug, and someone should extend the /etc/mtab exception in FHS to make the file optional. | 12:35 |
| *** toscalix_ has joined #baserock | 12:51 | |
| *** toscalix has quit IRC | 12:53 | |
| *** toscalix_ has quit IRC | 12:57 | |
| *** edcragg has joined #baserock | 14:10 | |
| *** CTtpollard has quit IRC | 14:48 | |
| *** CTtpollard has joined #baserock | 14:52 | |
| *** gtristan has quit IRC | 15:00 | |
| *** jonathanmaw has quit IRC | 15:17 | |
| *** locallycompact has quit IRC | 16:10 | |
| *** rdale has quit IRC | 16:11 | |
| *** rdale has joined #baserock | 16:14 | |
| *** faybrocklebank has quit IRC | 16:25 | |
| *** tiagogomes has quit IRC | 17:23 | |
| *** tiagogomes has joined #baserock | 17:26 | |
| *** edcragg has quit IRC | 17:27 | |
| *** edcragg has joined #baserock | 17:30 | |
| *** tiagogomes has quit IRC | 17:33 | |
| paulsherwood | can anyone help me understand how to support `mkdir -p foo/{bar,bip,bop}` in install-commands? | 17:35 |
| paulsherwood | ie allwing the { } to be handled properly by mkdir | 17:35 |
| *** edcragg has quit IRC | 17:42 | |
| rjek | The shell expands that | 17:50 |
| rjek | So if you're using exec it probably won't work | 17:50 |
| rjek | (ie, execing mkdir) | 17:50 |
| paulsherwood | well ybd passes it via an extended sandboxed shell command, and yes, it doesn't work | 17:56 |
| paulsherwood | no way round this? | 17:56 |
| paulsherwood | (short of expanding all of the examples longhand) | 17:56 |
| persia | Not easily. You could force the end-shell as bash, but that probably takes some doing. | 18:30 |
| persia | Generally speaking, outside of an explicit bash script, it is best to stay with POSIX semantics, despite them being more verbose. | 18:31 |
| *** gtristan has joined #baserock | 19:09 | |
| *** toscalix has joined #baserock | 20:09 | |
| *** toscalix has quit IRC | 22:00 | |
| *** toscalix has joined #baserock | 23:05 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!