| *** zoli__ has joined #baserock | 04:57 | |
| *** paulw has joined #baserock | 06:09 | |
| *** mike has joined #baserock | 07:18 | |
| *** mike is now known as Guest56770 | 07:18 | |
| *** mariaderidder has joined #baserock | 07:46 | |
| *** mdunford has joined #baserock | 08:04 | |
| *** franred has joined #baserock | 08:08 | |
| *** edcragg has joined #baserock | 08:32 | |
| *** jonathanmaw has joined #baserock | 08:57 | |
| *** franred has quit IRC | 09:03 | |
| *** franred has joined #baserock | 09:09 | |
| *** lachlanmackenzie has joined #baserock | 09:20 | |
| pedroalvarez | Is there a way to disable persistent device names in baserock? | 11:29 |
|---|---|---|
| tiagogomes_ | why would you want to do that? | 11:33 |
| pedroalvarez | bosh, when creating a stemcell, tries to do that | 11:39 |
| pedroalvarez | # Remove persistent device names so that eth0 comes up as eth0 | 11:39 |
| pedroalvarez | rm -fr $chroot/etc/udev/rules.d/70-persistent-net.rules | 11:39 |
| persia | What an ugly hack | 11:40 |
| pedroalvarez | this is full of ugly hacks :) | 11:40 |
| persia | It would be better to track down what consumes the "eth0" string, and cause that to parse the devices more sensibly. | 11:40 |
| persia | I seem to recall that for the reference systems, there was some initial effort to cling to "eth0", and then everything got changed so that it wasn't required anymore. | 11:41 |
| persia | And I suspect that every other project needs to make the same transition, for which patches are mostly a matter of parsing the network devices, rather than blindly assuming "eth0" works. | 11:41 |
| persia | (even without persistent device names, there are a number of circumstances in which one has working networking and no working "eth0") | 11:42 |
| franred | pedroalvarez, wasn't systemd the one which names the network devices? (latest version) | 11:42 |
| pedroalvarez | persia: fixing this to remove that hack makes sense, if I can figure out why was this needed | 11:43 |
| pedroalvarez | franred: yes | 11:43 |
| franred | also have you check if they create the net rules in a different file? - maybe this is why they remove the default persistent rules | 11:44 |
| persia | pedroalvarez: For most cases of this problem, grep seems to find the offending code. Essentially, there should be no code anywhere that expects "eth0" to be a meaningful strong, so any appearance outside a comment is likely a bug (and most appearances inside comments are likely to also be pointing at bugs) | 11:44 |
| persia | s/strong/string/ | 11:44 |
| * franred though you could also overwrite udev rules depending on the precedence of them without having to remove the default ones | 11:45 | |
| persia | franred: You can, but that doesn't fix buggy code that assumes the primary network adaptor is named "eth0" | 11:46 |
| franred | persia, true, I wasn't thinking in buggy code... just in the udev configuration files | 11:47 |
| persia | Unless you are stuck dealing with closed-source code, it is often better to fix the bug than work around it :) | 11:48 |
| pedroalvarez | expect(ssh(public_ip, 'vcap', '/sbin/ifconfig eth0', @our_ssh_options)).to match /#{static_ip}/ | 11:49 |
| persia | Ugh. I don't know if the tools are typically there, but I'd expect something parsing `ip -o addr` provides the desired data. | 11:51 |
| radiofree | yikes | 11:52 |
| radiofree | what is this pedroalvarez? | 11:52 |
| radiofree | cloudfoundry? | 11:52 |
| pedroalvarez | radiofree: indeed | 11:52 |
| persia | Amusingly, on the system I used to try to find a useful command, there is no eth0 nor any en* interface, and this doesn't even use the new systemd | 11:53 |
| radiofree | on fedora my ethernet is "em1" | 11:53 |
| pedroalvarez | baserock systems on openstack have eth0 :) | 11:55 |
| persia | pedroalvarez: Yes, but is this a good thing? | 11:59 |
| pedroalvarez | is a bad if I want to test a change of that code | 12:00 |
| pedroalvarez | not exactly good, but somehow good if I only want to add support to create baserock stemcells for openstack | 12:02 |
| persia | Oh, heh, because you can ignore the issue entirely. | 12:03 |
| franred | at the moment at least, it can beat us in the future | 12:04 |
| pedroalvarez | or even in a different openstack environment.. who knows | 12:06 |
| tiagogomes_ | mmm, the patch that I'm about to send to bosh only makes sense using persistent device names | 12:14 |
| pedroalvarez | tiagogomes_: you mean "non persistent"? | 12:16 |
| pedroalvarez | eth0, eth1, etc? | 12:17 |
| tiagogomes_ | persistent, in the sense that NIC 1 will always be mapped to the same interface name across reboots (eth0, em1) | 12:20 |
| tiagogomes_ | it doesn't need to necessarily use the ethX terminology | 12:20 |
| pedroalvarez | then, using the exsisting stemcells may be dangerous :) | 12:21 |
| nowster | irda0, for instance? :) | 12:22 |
| paulsherwood | QtWebkit build time vs cores... https://docs.google.com/spreadsheets/d/149jS3VVJ7jA14dSJybeOr4otlEFrzCVJjbxMSppiMcg/pubchart?oid=1071803514&format=interactive | 13:20 |
| radiofree | wow that's fast | 13:22 |
| rjek | 7 minutes with 20 cores? Hmm | 13:23 |
| edcragg | i'm a little confused about what 'merge conflict' means on gerrit. i rebased a branch onto the gerrit master without conflict, resubmitted, and gerrit still reports a path merge conflict. this change in particular: https://gerrit.baserock.org/#/c/794/3 | 13:26 |
| radiofree | is it part of series of patches? | 13:27 |
| paulsherwood | point is that going beyond 20 cores seems not worth it, rjek ... unless i'm missing something fundamewntal | 13:28 |
| franred | edcragg, I think what it means is that you need to merge the previous commit first | 13:28 |
| edcragg | radiofree: yes | 13:28 |
| radiofree | i think gerrit treats everything as an individual patch, so if a patch relies on changes in a previous path, it'll have a merge conflict | 13:28 |
| radiofree | i'd say just ignore "merge conflicts" | 13:28 |
| edcragg | that can't be the case, as surely then all patches in a series would have a merge conflict | 13:28 |
| radiofree | does the first one have a merge conflict? | 13:28 |
| robtaylor | paulsherwood: shame they dont show how much ram they've allocated | 13:29 |
| edcragg | radiofree: no, it seems to be 'random' | 13:29 |
| edcragg | as in, probably related to some actual conflict with something | 13:29 |
| radiofree | just ignore it and let whoever is responsible for merging sort it out | 13:29 |
| franred | edcragg, it is not random, it is waiting until you merge the previous commit | 13:29 |
| robtaylor | oh, actiay its 160GB | 13:29 |
| edcragg | franred: are you saying anything which relies on changes in any other patch that's not also merged will cause this? | 13:32 |
| franred | It could be, yes | 13:33 |
| franred | but in this case I think it is waiting for https://gerrit.baserock.org/#/c/738/4 | 13:34 |
| franred | that is what I meant ^^ | 13:34 |
| edcragg | ok, in which case it isn't an issue | 13:35 |
| edcragg | when the series gets merged, the preceding patch will be merged before it tries to merge the one with the conflict | 13:36 |
| pedroalvarez | you could squash the the first and the second commit in this case | 13:36 |
| franred | edcragg, yes, that is what it would happen | 13:36 |
| edcragg | pedroalvarez: ok, yes, but that may be forcing a squash where it's only required for gerrit, where separate commits may otherwise be more appropriate or clear | 13:38 |
| franred | edcragg, I suggest you to leave it as it is | 13:39 |
| pedroalvarez | in this case , the extra commit doesn't make it easier to review | 13:39 |
| pedroalvarez | but yes, this is not a problem to get it merged if it has been +2ed | 13:39 |
| edcragg | cool, so are we saying we can generally ignore merge conflicts where patch series are concerned? is that something that could be added to the contributing wiki page? | 13:40 |
| pedroalvarez | this is something that should be fixed in gerrit '-.- | 13:44 |
| edcragg | well, patch series yes, whoever uses them anyway! | 13:45 |
| edcragg | thanks for the help. Is there any chance anyone would be able to merge https://gerrit.baserock.org/#/c/940/ ? | 13:50 |
| nowster | libogg and libvorbis lorries are both fixed tarball names at the moment. Xiph has set up git repos for all its products. How would be the best way to change these lorrys? New ones and deprecate the old names or adapt the old ones? | 13:52 |
| franred | nowster, create a new lorries with -git at the end? | 13:53 |
| nowster | Sounds like a good idea. | 13:54 |
| franred | ;-) | 13:56 |
| paulsherwood | robtaylor: is there some trick ybd could do to report that? one thing i'm worried about is oom for the gang/herd approach... would like some way to police it | 14:18 |
| nowster | franred: would it be a good idea to name gnome components (used outside desktop gnome) with gnome/component-name ? | 14:44 |
| nowster | eg. gupnp | 14:44 |
| nowster | or libmediaart | 14:44 |
| persia | paulsherwood: On your graph showing the lack of improvement at 20 cores: do you know whether that is the limit of parallelism in the workload or some limitation of memory and/or storage bandwidth? | 14:46 |
| robtaylor | paulsherwood: checking memory limits per worker? | 14:48 |
| paulsherwood | robtaylor: yes. i don't know how to do that | 14:49 |
| persia | robtaylor: Tricky, as each worker then spawns any number of processes to actually do the work | 14:49 |
| paulsherwood | persia: i don't know. if others have suggestions on how to find out, i'm very interested :) | 14:49 |
| robtaylor | paulsherwood: probably use memory cgroups so you can have per worker limits, and also possibly use memory threshold events to monitor it | 14:50 |
| robtaylor | paulsherwood: all in http://lxr.free-electrons.com/source/Documentation/cgroups/memory.txt | 14:50 |
| robtaylor | paulsherwood: and can be setup by systemd or libcgroup | 14:50 |
| robtaylor | paulsherwood: i believe radiofree has been working with this recently so probebly knows the details | 14:50 |
| persia | paulsherwood: My method to find out would be to measure maximum memory and/or storage bandwidth by running iostat/memstat with a large synthetic load, then comparing to the numbers while running the builds. | 14:50 |
| persia | It is a crude way to detect potential saturation, but may give some guidance. | 14:51 |
| paulsherwood | robtaylor: erk... i'm just a hobbyist python n00b... that sounds like a job for someone expert :) | 14:51 |
| *** petefoth has quit IRC | 14:53 | |
| *** franred has quit IRC | 15:00 | |
| *** franred has joined #baserock | 15:01 | |
| nowster | franred: would it be a good idea to name gnome components (used outside desktop gnome) with gnome/component-name ? (eg. gupnp or libmediaart) | 15:01 |
| franred | nowster, Im not sure if jjardon has started to do that or not, so maybe worth to talk with him | 15:02 |
| nowster | I notice that a lot of the gnome components are already gnome/something. | 15:02 |
| nowster | eg: "gnome/libgee" and "gnome/libnotify" | 15:03 |
| pedroalvarez | oh, for new lorries? we dont have a policy for that | 15:05 |
| nowster | Would it be a good thing to use that convention for libraries that are derived from parts of gnome? | 15:06 |
| *** franred has quit IRC | 15:07 | |
| pedroalvarez | makes sense to me to use the gnome/ namespace for them | 15:08 |
| jjardon | robtaylor: AFAIK, in latest systemd the idea is to use high level systemd configuration (CPUShares, MemoryLimit...), instead deal with cgroups directly: http://0pointer.de/blog/projects/resources.html | 15:09 |
| radiofree | paulsherwood: it's really easy to launch things in cgroups and get the stats | 15:14 |
| radiofree | jjardon: that's a little bit much when you just want to do something simple like "run this task in a cgroup and collect data" | 15:14 |
| radiofree | cgexec -g memory:/foo/ myprocess | 15:15 |
| radiofree | cat /sys/fs/cgroup/memory/foo/memory.... | 15:15 |
| *** franred has joined #baserock | 15:16 | |
| paulsherwood | GCC graph https://docs.google.com/spreadsheets/d/149jS3VVJ7jA14dSJybeOr4otlEFrzCVJjbxMSppiMcg/pubchart?oid=1593295908&format=interactive | 15:18 |
| franred | nowster, I would say, if you have seen components in that namespace please go ahead with that | 15:18 |
| franred | I meant, use the gnome namespace if it makes sense | 15:19 |
| nowster | ok | 15:19 |
| *** paulw has quit IRC | 15:19 | |
| *** Guest56770 has quit IRC | 15:41 | |
| jjardon | paulsherwood: how many cores that machine has? normally what it worked best for me is (number of cores + 1), but I only have 4 | 15:52 |
| flatmush | (number of cores * 5) / 4 | 15:54 |
| radiofree | qtbase from qt4 might be interesting | 15:56 |
| paulsherwood | jjardon: 40 | 16:12 |
| jjardon | 40??? O_o you lucky : | 16:18 |
| radiofree | very lucky... it built qtwebkit in 8 minutes! | 16:19 |
| persia | It is more money than luck. Anyone can schedule a 40-core AWS instance, if they want to pay for it. | 16:21 |
| paulsherwood | you can be so lucky too - AWS, $2.50 per hour :) | 16:21 |
| persia | It is very interesting to know what they are good for, because for many workloads it is actually cheaper than scheduling a 1-core for a longer period of time. | 16:21 |
| jjardon | interesting, didnt now that | 16:21 |
| *** mariaderidder has quit IRC | 16:25 | |
| pedroalvarez | hm.. IIRC that means that building ci.morph would be less than $4 | 16:27 |
| nowster | We're almost back to the days of timesharing mainframes, effectively. | 16:29 |
| * rjek submits a batch job on paper tape | 16:29 | |
| * nowster tries to forget JCL. | 16:30 | |
| *** zoli__ has quit IRC | 16:31 | |
| *** jonathanmaw has quit IRC | 16:32 | |
| *** zoli__ has joined #baserock | 16:32 | |
| paulsherwood | pedroalvarez: yup. and much faster than the current mason :) | 16:33 |
| paulsherwood | even better if we can sort out shared cache... | 16:35 |
| pedroalvarez | hm.. mason could spawn instances on demand, and use clean environments all the time | 16:51 |
| paulsherwood | yup. still needs cached repos and artifacts, though | 16:53 |
| paulsherwood | took over 30 mins to clone the repos for base-system | 16:54 |
| persia | That would be an ideal model, because then mason can use the morph from HEAD, which avoids the versioning issues we've seen in the past. | 16:54 |
| paulsherwood | morph? ii thought you meant ybd :) | 16:54 |
| persia | I think I mean "the integration tool" | 16:54 |
| * paulsherwood decides to go and troll at the pub, instead of here | 16:54 | |
| *** bashrc has quit IRC | 17:04 | |
| *** mdunford has quit IRC | 17:05 | |
| *** edcragg has quit IRC | 17:25 | |
| *** franred has quit IRC | 18:02 | |
| *** lachlanmackenzie has quit IRC | 18:53 | |
| *** zoli__ has quit IRC | 19:32 | |
| *** petefoth has joined #baserock | 19:39 | |
| *** zoli__ has joined #baserock | 19:52 | |
| *** zoli__ has quit IRC | 20:10 | |
| *** zoli__ has joined #baserock | 20:18 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!