| *** Prince781 has quit IRC | 02:56 | |
| *** mcatanzaro has quit IRC | 03:13 | |
| *** valentind has joined #buildstream | 08:29 | |
| *** aday has joined #buildstream | 09:01 | |
| *** valentind has quit IRC | 09:08 | |
| *** jonathanmaw has joined #buildstream | 09:26 | |
| *** ernestask has joined #buildstream | 09:32 | |
| *** ssam2 has joined #buildstream | 09:35 | |
| *** adds68 has joined #buildstream | 09:53 | |
| *** adds68 has quit IRC | 09:58 | |
| *** jennis has joined #buildstream | 11:18 | |
| persia | Is there a recommended best practice to store a blessed artifact somewhere for reuse? Examples would be the results of porting a self-hosted environment (e.g. Free Pascal Compiler) to be part of a system. | 12:06 |
|---|---|---|
| ssam2 | I have done this by setting up an OSTree repo on a server, and using a fork of `ostree-push` to send the binaries there | 12:08 |
| ssam2 | you could also upload a tarball of the binaries somewhere if that's easier | 12:08 |
| ssam2 | i think i did document my example process .. one sec | 12:08 |
| persia | Ah, and then just use that collection of blessed binaries as a source? | 12:08 |
| ssam2 | yeah | 12:08 |
| ssam2 | i documented a process for baserock at https://gitlab.com/baserock/definitions/#bootstrap-sysroots | 12:09 |
| ssam2 | using an ostree repo (which is NOT a cache) hosted at https://ostree.baserock.org/releases | 12:09 |
| ssam2 | i don't know whether others would "bless" this approach or not, though | 12:09 |
| persia | This makes sense. Essentially, one manages a "releases" archive somewhere containing blessed elements that are (ideally) infrequently updated, using classic archive management tooling, and then uses buildstream to build systems that depend on those by consuming those "releases". | 12:11 |
| persia | While ostree is convenient for this, I suspect it is an implementation detail. | 12:11 |
| paulsherwood | +1 | 12:11 |
| ssam2 | yeah | 12:12 |
| persia | Mind you, this means that any such thing is still subject to the wizard hack, but I don't think one can work around that unless one has multiple sources for tooling to build the sources, etc. | 12:12 |
| ssam2 | yeah | 12:12 |
| persia | Thanks for clarifying. | 12:12 |
| ssam2 | I basically imagine us using this only to inject prebuilt binaries of self-hosting toolchains | 12:12 |
| ssam2 | such as, gcc, rust, fpc, etc. | 12:12 |
| persia | Right. It was the jre discussion in #flatpak that made me wonder. | 12:13 |
| *** eb has joined #buildstream | 13:08 | |
| eb | How do I build buildstream from scratch and then execute it? | 13:09 |
| eb | I ran ./setup.py build | 13:09 |
| eb | but still no sign of an executable `bst` | 13:09 |
| abderrahim[m] | eb: it should be ./setup.py install | 13:10 |
| abderrahim[m] | you can add --user if you want to install in your home dir | 13:10 |
| tristan | cd buildstream && pip3 install --user -e . | 13:10 |
| tristan | running ./setup.py directly is not recommended (thats what the python folks keep telling me) | 13:11 |
| abderrahim[m] | and tristan was faster than me in suggesting pip | 13:11 |
| tristan | for one, ./setup.py install doesnt record what was installed (you need special options to record a manifest and yada yada) | 13:11 |
| tristan | while going through pip, you have your uninstall which will "just work" | 13:11 |
| eb | Thanks, that worked! | 13:14 |
| abderrahim[m] | tristan: you are the maintainer of gnome-build-meta, right? could you look at https://gitlab.gnome.org/GNOME/gnome-build-meta/issues/5 and suggest what I should do | 13:17 |
| abderrahim[m] | (and btw, is this the right channel to discuss gnome-bulid-meta?) | 13:18 |
| *** xjuan has joined #buildstream | 13:36 | |
| *** aday has quit IRC | 13:40 | |
| *** eb has quit IRC | 13:52 | |
| *** aday has joined #buildstream | 13:54 | |
| tristan | abderrahim[m], aha ! it looks like I need to enable notifications from there ! | 13:55 |
| tristan | abderrahim[m], yes I am, but equally anyone from GNOME release-team :) | 13:56 |
| tristan | mhmmm, still dont have build pipelines up there yet... | 13:56 |
| tristan | jjardon[m], I think you're busy with a lot of things, any eta on getting build pipelines at least for intel at gnome-build-meta ? | 13:57 |
| jjardon[m] | weekend, sorry | 14:00 |
| tristan | jjardon[m], no worries... I just commented on https://gitlab.gnome.org/GNOME/gnome-build-meta/issues/5 fwiw | 14:07 |
| *** mcatanzaro has joined #buildstream | 14:20 | |
| tristan | Was https://gitlab.com/BuildStream/buildstream/issues/222 never implemented ? | 16:24 |
| tristan | I seem to recall discussion about implementing that | 16:24 |
| ssam2 | i don't remember anyone doing it | 16:31 |
| juergbi | iirc, there was a discussion about following the git approach of checking ancestor directories for project.conf | 16:32 |
| juergbi | that would allow `bst` to work in workspaces without extra files, if the workspace directory is inside the project directory | 16:32 |
| juergbi | still not sure whether we should recommend that approach or not | 16:32 |
| nexus | I'm working on a host machine log, which will show information like the kernel version ,amount of ram, HDD space and the processor info, however i can't seem to find a way of showing the processor information via machine readable means. I just have a string containing the Vender + CPU model number + clock speed. This seems fine, however if anyone wanted to write a script to get hold of something like | 16:35 |
| nexus | the clock speed, it would be very difficult, as i believe that the format would change depending on the CPU model and vendor. This could make parsing it very difficult. Does anyone have any views or ideas about this? Or am i just over thinking this (happens a lot) and noone would ever want to parse that information | 16:35 |
| juergbi | i expect the format of /proc/cpuinfo to be sufficiently stable on Linux | 16:37 |
| gitlab-br-bot | buildstream: merge request (jjardon/jinja->master: WIP: setup.py: Require jinja >= 2.10) #239 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/239 | 16:38 |
| juergbi | there is also /sys/devices/system/cpu with more fine grained files | 16:39 |
| nexus | juergbi: that's what i'm using, but could we guarentee that the clockspeed would always be the 6th element? | 16:39 |
| juergbi | no, but it should have a fixed label | 16:40 |
| juergbi | (in fact it's not the 6th element heree) | 16:40 |
| nexus | the model name is the 5th entry, and the 6th element of that is the clock speed | 16:40 |
| nexus | the "cpu MHz" entry, i sthe current clockspeed, and would be misleading in a report | 16:41 |
| juergbi | ah that's actually hardware-specific, afaik | 16:41 |
| nexus | indeed | 16:41 |
| juergbi | e.g., on my system, model name doesn't contain a frequency at all | 16:41 |
| nexus | ah interesting | 16:41 |
| juergbi | right, cpu MHz is not useful for us | 16:41 |
| juergbi | nexus: check /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq | 16:42 |
| nexus | sadly, thats the turbo frequency, not the base frequency of the cpu | 16:43 |
| gitlab-br-bot | buildstream: merge request (jjardon/jinja->master: setup.py: Require jinja >= 2.10) #239 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/239 | 16:43 |
| juergbi | there is also min_freq | 16:44 |
| nexus | e.g. my base is 2.5ghz, my max is 3.2ghz and my min is 800mhz | 16:44 |
| juergbi | different CPU vendors/models impose different meanings of base, turbo, etc. | 16:44 |
| nexus | indeed | 16:44 |
| juergbi | and here max is the same as base frequency | 16:45 |
| nexus | not in my case | 16:45 |
| juergbi | and turbo is beyond 'max' | 16:45 |
| nexus | my CPU is advertised as 2.5Ghz, with a turbo boost of 3.2 | 16:46 |
| nexus | AFAIK it can't go above the max, but i'm not sure | 16:46 |
| nexus | some CPU's cannot turbo at all | 16:47 |
| nexus | E.G. Intel i3s | 16:47 |
| nexus | i believe | 16:47 |
| juergbi | mine is advertised as base 3.4GHz and boost 4.0GHz, yet i don't see the 4.0GHz in linux max freq | 16:47 |
| juergbi | (AMD Ryzen) | 16:47 |
| nexus | interesting | 16:47 |
| nexus | another way in which AMD differ from intel i suppose | 16:48 |
| nexus | (completely seperate note, how are you finding the ryzen?) | 16:48 |
| juergbi | BogoMIPS is actually pretty close to double the base frequency in MHz on both AMD Ryzen and Intel Core, afaict | 16:48 |
| juergbi | we should probably not rely on that, though | 16:49 |
| ssam2 | anyone object to adding GNU Time into the Docker images? | 16:55 |
| ssam2 | i've opened https://gitlab.com/BuildStream/buildstream-docker-images/merge_requests/19 | 16:55 |
| ssam2 | it will be useful for doing simple benchmarks, has a lot more features than the shell built-in one | 16:55 |
| * nexus hasn't the knowledge to object | 16:56 | |
| tlater | ssam2: Why not python's various time functions? | 16:56 |
| tlater | Hm, I guess that doesn't include startup time | 16:57 |
| tlater | Although you may argue that that is irrelevant | 16:57 |
| ssam2 | later on I'd like get test results using the buildstream log parser script proposed in issue #205 | 16:57 |
| juergbi | it's very small, no objections from me | 16:57 |
| ssam2 | that could perhaps take over the role of /usr/bin/time | 16:58 |
| ssam2 | but that script doesn't yet exist | 16:58 |
| ssam2 | also, is there an easy way in Python to measure max RSS size and average memory usage ? | 16:58 |
| *** Prince781 has joined #buildstream | 16:58 | |
| * tlater doesn't object either, just asking whether that's an option :) | 16:58 | |
| tlater | Hrm, I do think those exist, but it will probably be easier to just use GNU time | 16:59 |
| *** Prince781 has quit IRC | 17:18 | |
| tristan | juergbi, I dont like recommending putting workspaces into a project subdirectory, but dont mind supporting it | 17:26 |
| tristan | mcatanzaro has a point with issue 222 orthogonal to that, which is *probably* worth supporting, I think | 17:27 |
| juergbi | the issu | 17:28 |
| tristan | although it means we have to record state in an abstract directory, and if two different builds have an open workspace on the same directory things could go awry | 17:28 |
| juergbi | yes, the issue is mainly how to support this in a vcs-neutral way that is ignored by the VCS | 17:28 |
| juergbi | hm, that's anyway an issue for incremental builds | 17:28 |
| tristan | also good point worth some thought :-S | 17:28 |
| tristan | Perhaps we can do something entirely different from XDG_CACHE_HOME | 17:29 |
| tristan | in any case, it's worth properly speccing out I guess before jumping on an implementation | 17:29 |
| tristan | (I just seemed to have thought we already got close to that...) | 17:29 |
| juergbi | keeping per-workspace metadata tied to the workspace directory instead of the project directory could actually be pretty useful | 17:30 |
| juergbi | this would avoid losing it when closing and reopening a workspace | 17:30 |
| juergbi | and make it available to other project directories | 17:30 |
| tristan | yeah the initial configure happened or not... indeed; but this is a very weird scenario we are dreaming up already | 17:31 |
| tristan | (I dont think I have an issue telling people to just open separate workspaces for separate projects, if that makes code a lot more sane) | 17:31 |
| juergbi | for #215 we'll likely need more metadata | 17:31 |
| tristan | right that; and then that is also project context (as I recall, you want to save the artifact keys for what you built this workspace against "last time") | 17:33 |
| *** ltu has quit IRC | 17:38 | |
| *** tlater has quit IRC | 17:38 | |
| *** aiden has quit IRC | 17:38 | |
| juergbi | yes, however, that information is not project-specific. you always need to know the last build of the workspace, independent of the project | 17:42 |
| *** aiden has joined #buildstream | 17:45 | |
| *** jonathanmaw has quit IRC | 17:46 | |
| *** jonathanmaw has joined #buildstream | 17:47 | |
| *** laurenceurhegyi has joined #buildstream | 17:51 | |
| *** tlater has joined #buildstream | 17:57 | |
| *** ssam2 has quit IRC | 18:04 | |
| *** jonathanmaw has quit IRC | 18:16 | |
| gitlab-br-bot | buildstream: merge request (skip-configure-tests->master: Workspaced builds only run configure commands once) #191 changed state ("closed"): https://gitlab.com/BuildStream/buildstream/merge_requests/191 | 18:26 |
| gitlab-br-bot | buildstream: merge request (workspace-build-count->master: WIP: Skip configure-commands when building workspaced elements a second time) #154 changed state ("closed"): https://gitlab.com/BuildStream/buildstream/merge_requests/154 | 18:28 |
| persia | I have previously tried to use both /proc/cpuinfo and /sys/devices/... to discover information about CPUs. My experience is now dated, but included stable interfaces on a per-architecture basis, where each architecture had a different format. As an example, all POWER and PPC platforms include a "Machine:" line in /proc/cpuinfo, which is absent on any other architecture, if I recall correctly. | 18:47 |
| persia | nexus: juergbi: ^^ | 18:47 |
| juergbi | good point | 18:57 |
| *** ernestask has quit IRC | 19:40 | |
| *** mcatanzaro has quit IRC | 19:50 | |
| *** valentind has joined #buildstream | 19:54 | |
| *** aday has quit IRC | 19:57 | |
| *** adds68 has joined #buildstream | 21:38 | |
| *** adds68 has quit IRC | 21:43 | |
| *** valentind has quit IRC | 21:57 | |
| *** WSalmon has joined #buildstream | 22:30 | |
| *** WSalmon has quit IRC | 22:35 | |
| *** WSalmon has joined #buildstream | 22:35 | |
| *** WSalmon_ has joined #buildstream | 22:46 | |
| *** WSalmon_ has quit IRC | 22:47 | |
| *** WSalmon has quit IRC | 22:47 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!