IRC logs for #baserock for Monday, 2015-04-13

*** zoli__ has joined #baserock00:43
*** zoli__ has quit IRC00:48
*** zoli__ has joined #baserock00:58
*** zoli__ has quit IRC01:02
*** zoli__ has joined #baserock01:22
*** zoli__ has quit IRC01:27
*** zoli__ has joined #baserock03:11
*** zoli__ has quit IRC03:15
*** zoli__ has joined #baserock04:29
*** zoli__ has quit IRC05:47
*** zoli__ has joined #baserock06:09
*** petefoth has joined #baserock06:24
*** petefoth has quit IRC07:02
*** Albert has joined #baserock07:02
*** petefoth has joined #baserock07:05
*** a1exhughe5 has joined #baserock07:06
*** rdale has joined #baserock07:13
*** mdizzle has joined #baserock07:48
*** jonathanmaw has joined #baserock07:50
*** sambishop has joined #baserock08:06
*** bashrc_ has joined #baserock08:08
*** pdar_ has left #baserock08:14
*** edcragg has joined #baserock08:15
*** pdar has joined #baserock08:17
straycatKinnison, http://sprunge.us/RJfP08:28
* Kinnison will look, but don't expect rapidity -- my laptop is still mid-security-updates08:28
straycatOkay thanks08:29
*** tiagogomes_ has joined #baserock08:29
Kinnisonstraycat: so the mounts look sane, no MS_RDONLY flags or anything08:34
Kinnisonno obvious changing of the UID maps08:34
Kinnisonthe capabilities things look okay08:35
pedroalvarezstraycat: oh, ownership in linux-user-chroot?08:36
straycatfrom what i could read from /proc/<pid>/status the linux-user-chroot process had the same set of capabilities as the process running inside the standard chroot08:36
straycatpedroalvarez, yes08:36
pedroalvarezstraycat: we faced this before.08:37
pedroalvarezin fact, there are some notes in: strata/apache-httpd-server/httpd-server.morph08:37
straycat# This is not possible because linux-user-chroot drops all capabilities for security so08:37
straycat# it does not allow to change the owners of directories or files08:37
straycatwhy couldn't i see that from the status file08:38
* Kinnison must be misreading this prctl then08:39
Kinnisoni thought it was setting the override flags for chown/etc08:39
pedroalvarezi'm not saying that our notes are 100% true, though08:39
straycatlooking at the status files, for each process they seemed to have the same set of capabilities, but i don't know much about linux capabilities, so i might be missing something08:41
jjardonpaulsherwood: 1.8.16 is the latest stable release (1.9.x are development versions)08:41
paulsherwoodjjardon: ok08:43
straycat"drops all capabilities" the only thing i see is that linux-user-chroot calls prctl with PR_SET_NO_NEW_PRIVS, that's not dropping capabilities?08:51
franredrichard_maw, ^^08:52
straycatoh hang on there is SECBIT_NOROOT though08:54
straycat       SECBIT_NOROOT08:55
straycat              If this bit is set, then the kernel does not grant capabilities when  a  set-user-ID-root  program  is08:55
straycat              executed,  or  when a process with an effective or real UID of 0 calls execve(2).  (See the subsection08:56
straycat              Capabilities and execution of programs by root.)08:56
*** CTtpollard has joined #baserock08:56
straycatso i guess that explains it08:56
straycat*sigh* i wish you guys had been here yesterday >.>08:56
*** gary_perkins has joined #baserock08:57
*** ssam2 has joined #baserock08:57
*** ChanServ sets mode: +v ssam208:57
straycatmaybe we should put a warning about that somewhere on the wiki, in the faq or something, i doubt i would have looked there, but still08:59
ssam2https://wiki.baserock.org/ should now work (no more 'this site is not here yet' errors), please let me know if it doesn't09:00
ssam2the fix was to send our SSL cert to Branchable so they could install it09:00
straycatcool09:02
*** mike has joined #baserock09:10
*** mike is now known as Guest7185509:10
*** SotK_ has joined #baserock09:20
*** SotK has quit IRC09:24
*** SotK_ is now known as SotK09:25
*** mauricemoss_ has joined #baserock09:27
straycathardcoding the uid and gid of the user and group and chowning from a conf ext is reasonable?09:30
paulsherwoodstraycat: could these be taken from (new) fields in definitions?09:32
straycati guess so09:34
paulsherwoodstraycat: imo it would be best if we had uids and gids locked down in definitions, so that configure extensions or other tooling would not contain magic numbers09:36
franrededcragg, could you have a look at https://gerrit.baserock.org/#/c/127/ ? (I think reviewers are waiting for some clarification about the commit message before merging this patch)09:36
straycatpaulsherwood, yes that sounds like it might be a useful thing to have09:37
paulsherwoodstraycat: great. my answer to your question is yes, then, provided the extension takes its info from definitions if it can09:38
straycatpaulsherwood, it can't right now because those fields don't exist09:40
straycatbut we can add them later09:40
paulsherwoodstraycat: please add them?09:41
* Kinnison believes we discussed such arbitrary configuration (incl. users/groups as an example) during the baserock meetup09:41
paulsherwoodhow hard can it be? :)09:41
KinnisonConsider <20150206130136.GW1787@somnambulist.local> on baserock-dev09:41
KinnisonSo hard that noone ever followed up09:42
paulsherwoodKinnison: i don't know how to parse that?09:42
Kinnisonpaulsherwood: how to parse the email?09:42
Kinnisonpaulsherwood: Or how to search for a message by message-id in your mail client?09:43
paulsherwoodKinnison: the latter. i have no mail client on my current machine09:43
Kinnisonaah09:43
rjekISTR saying I'd like magic in morph to automatically assign UIDs and GIDs and try to keep them the same (and keep track of ones that were used in the past) between builds.  But people felt it was too complex and that all it should do is make sure that the IDs the definition author has chosen hadn't already been used elsewhere.09:43
Kinnisonpaulsherwood: http://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2015-February/011181.html09:44
* petefoth would be interested in knowing how to 'search for a message by message-id in your mail client' where mail lient==Thunderbird09:44
* petefoth googles09:44
richard_mawpaulsherwood: another thing to consider is systemd-sysusers, which I believe is supposed to handle at least a similar problem even if it doesn't solve ours09:46
richard_mawthough AIUI it's mostly just to provide a structured approach to applying the UID/GIDs at runtime09:46
radiofreepetefoth: edit->find->search messages, select customise and enter Message-Id09:47
ssam2petefoth: I find it easier to download the whole mail archive off mailmail to a directory, then use 'grep'09:47
rjekIt makes sense for there to be a centralised post-install UID management thingy, as every distro has to implement it anyway09:47
ssam2petefoth: that way it doesn't matter the mails predate your being a member of the list.09:47
*** jonathanmaw has quit IRC09:47
petefothradiofree: ta! Is the id the whole link or just the part before the @?09:48
radiofreeit's the whole thing, but without the <>, so 20150206130136.GW1787@somnambulist.local09:48
petefothssam2: or use google on the archive page for public lists09:48
paulsherwoodKinnison: thanks09:49
paulsherwoodrichard_maw: thanks also :)09:49
paulsherwoodKinnison: that's a really interesting email which i missed entirely first time around, thanks!09:50
* Kinnison grins09:51
* Kinnison worries at how many of the followup mails from the meetup may have been missed entirely by interested parties who perhaps were tired :)09:53
paulsherwood+109:54
paulsherwoodand we're rapidly approaching time for plannign the next one!09:54
KinnisonAlready? Cripes09:56
paulsherwoodthe target would be july/aug iirc09:56
paulsherwoodand we should stop being so last-minute09:56
Kinnisonaah09:56
KinnisonI was expecting early september TBH09:57
*** jonathanmaw has joined #baserock10:04
jonathanmawhrm, genivi-demo-platform fails to build with this error: http://paste.baserock.org/zodumoraza caused by this command in configure.ac http://paste.baserock.org/icomucoqit10:26
jonathanmawwhich is odd, because `readelf -Ws usr/lib/libilmClient | grep UpdateInputEventAcceptanceOn` shows that it exists10:27
Kinnisonlook at the config.log10:27
Kinnisonit may be more subtle than that10:27
radiofreejonathanmaw: which version of wayland-ivi-extension are you using?10:31
jonathanmawradiofree: 1.3.9110:31
radiofreedidn't you remove UpdateInputEventAcceptanceOn?10:31
jonathanmawradiofree: that's just after 1.3.9110:31
radiofreeah10:31
jonathanmawthe symbol exists, but the failure appears to be undefined references to ilmControl_{destroy,init}10:31
radiofreei seem to remember some discussion about input focus etc..10:32
radiofreeperhaps they're using a modified wayland-ivi-extension? what version are they using in yocto10:32
jonathanmawradiofree: they appear to use 1.2.0 or 1.3.010:39
jonathanmawI'll try 1.3.0, and if that fails just comment out the cause of build failure10:39
jonathanmawsince the problem appears to be that it's testing ilmClient without also linking against ilmControl10:40
ssam2hello, opinions wanted10:45
ssam2I want to add something like 'upgrade-type' and 'upgrade-location' to cluster morphs10:46
ssam2to avoid having to edit them when you want to upgrade something you already deployed10:46
ssam2does this sound like a good idea? are the names sensible?10:46
radiofreeso you could use the same cluster for deploy and upgrade?10:46
ssam2yeah10:46
radiofreei like the sound of that10:46
KinnisonSeems reasonable (and acceptably named) to me10:46
Kinnison+110:47
ssam2i'd prefer upgrade-method, but we already have 'type' so upgrade-type is more consistent10:47
ssam2ok, i'll get to work10:47
ratmice__jonathanmaw: seems odd, if ilmClient depends on ilmControl it should link to it itself10:52
*** flatmush1 is now known as flatmush10:52
* richard_maw pushed https://gerrit.baserock.org/#/c/267/ for the sake of completeness10:52
richard_mawThe USB ethernet adapters supported by this are commonly available, but there's such variety I'm not sure if we should support some but not others10:53
ssam2install-files supports templates now! that's cool10:56
jjardonHi, is there any way to remove some files from the /etc directory after the system is created?10:58
Kinnisonjjardon: system integration scripts, or else configuration extensions I'd guess10:58
jjardonKinnison: ok, thanks11:00
edcraggfranred: i've amended change 12711:01
edcraggrichard_maw, ssam2 any chance you could take a look at that change if you have a chance? ^11:42
ssam2sure11:43
*** petefoth has left #baserock11:44
jjardonssam2: Ive just pushed patches to create the install-essential-files extension and a patch for definitions to using it (overwrite os-release only for now) Maybe you can have a look when you have time and check is ok with what we discussed the other day?12:59
* paulsherwood unfortunately will not have time to fix his genivi patch, and wonders if jonathanmaw could adopt it?13:00
jonathanmawpaulsherwood: which patch would this be?13:05
paulsherwoodhttps://gerrit.baserock.org/#/c/262/13:06
* richard_maw idly ponders (because he's currently waiting on a deployment) whether we can get rid of dbus-pre by now, since it ought not to need it as a build-dependency because it has its own d-bus client implementation13:11
*** mdizzle is now known as mariaderidder13:25
jjardonrichard_maw: but systemd still depends on dbus? (and dbus on systemd)13:26
richard_mawjjardon: it needs the daemon at runtime (until kdbus gets in), but at build-time I don't think it needs libdbus13:31
paulsherwoodcan we upgrade to 4.0 please?13:33
paulsherwoodwho wants to do that patch?13:33
* paulsherwood +1s in advance13:33
paulsherwoodc'mon, let's not hang about :) http://git.baserock.org/cgi-bin/cgit.cgi/delta/linux.git/13:34
SotKI think I saw a patch for that in Gerrit already13:34
SotKhttps://gerrit.baserock.org/#/q/topic:linux_4_013:35
paulsherwoodreviewed13:35
jjardonrichard_maw: indeed, I think the only use is in http://git.baserock.org/cgi-bin/cgit.cgi/delta/systemd.git/tree/src/libsystemd/sd-bus/test-bus-marshal.c#n181 ,  but we already have GDBus (GLib) for that13:37
paulsherwoodare there other bsps that can move forward too?13:37
paulsherwoodradiofree: jetson for example?13:37
radiofreeneed cpufreq + i think there are some unmerged nouveau changes13:38
* paulsherwood needs to recover his jetson13:38
paulsherwoodSotK: can you + 1 it, please?13:44
SotKsure13:46
radiofreei think if we upgrade the kernel + nouveau we're going to need to upgrade mesa13:47
radiofreewhich is apparently a big no-no on x8613:47
*** rdale has quit IRC13:58
*** rdale has joined #baserock14:00
*** bashrc_ has quit IRC14:00
*** nowster has quit IRC14:00
*** sambishop has quit IRC14:01
*** a1exhughe5 has quit IRC14:01
*** franred has quit IRC14:01
*** paulw has quit IRC14:01
*** jonathanmaw has quit IRC14:01
*** tiagogomes_ has quit IRC14:01
*** ssam2 has quit IRC14:01
*** tpollard_ has joined #baserock14:01
*** flatmush has quit IRC14:01
*** Guest71855 has quit IRC14:01
*** marcdunford has quit IRC14:01
*** fay_ has quit IRC14:01
*** gary_perkins has quit IRC14:01
*** ssam2 has joined #baserock14:01
*** ChanServ sets mode: +v ssam214:01
*** edcragg has quit IRC14:01
*** mariaderidder has quit IRC14:01
*** CTtpollard has quit IRC14:01
*** gary_perkins_ has joined #baserock14:01
*** mauricemoss_ has quit IRC14:01
*** bashrc_ has joined #baserock14:01
*** tiagogomes_ has joined #baserock14:01
*** mariaderidder has joined #baserock14:01
*** franred has joined #baserock14:01
*** a1exhughe5 has joined #baserock14:01
*** mauricemoss_ has joined #baserock14:01
*** fay_ has joined #baserock14:01
*** Guest71855 has joined #baserock14:02
*** nowster has joined #baserock14:02
*** petefoth has joined #baserock14:02
*** edcragg has joined #baserock14:02
*** sambishop has joined #baserock14:02
*** paulw has joined #baserock14:02
*** jonathanmaw has joined #baserock14:02
*** marcdunford has joined #baserock14:02
*** flatmush has joined #baserock14:03
*** Albert has quit IRC14:05
*** Albert has joined #baserock14:06
jjardonpaulsherwood: about jetson: this is the diff from stock 3.18 (Its what we are currently using): http://git.baserock.org/cgi-bin/cgit.cgi/delta/linux.git/log/?h=baserock/v3.18-with-cpufreq14:19
jjardondiff for armv8l: http://git.baserock.org/cgi-bin/cgit.cgi/delta/linux.git/log/?h=baserock/apm-xgene-m400-moonshot-cartridge14:22
jjardondoesnt seem those patches are upstreamed yet14:24
* radiofree wonders when the cpufreq patches will be merged14:25
radiofreecyndis? ^14:25
cyndiscpufreq just got acked on friday14:25
radiofreegreat :D14:26
radiofreethey applied cleanly against 4.0-r1 at least http://git.baserock.org/cgi-bin/cgit.cgi/delta/linux.git/log/?h=baserock/james/tegra-for-next-be-cpufreq14:26
cyndisyeah, finally :p14:26
radiofreejjardon: but we'll probably have to upgrade mesa now14:28
radiofreethere's been no progress on https://bugs.freedesktop.org/show_bug.cgi?id=8670114:28
radiofreeso i'm not sure what we need to do there, mesa-common-jetson?14:28
*** zoli__ has quit IRC14:28
radiofreewhich would mean we need graphics-common-jetson. multimedia-gstreamer-common-jetson, x-generic-jetson....14:31
jjardonradiofree: bfff, that means we will have to duplicate everything on top of mesa..14:31
radiofreegtk-deps-jetson, weston-common-jetson, weston-genivi-jetson...14:32
jjardonyeah, do you have more info why linux depends on a specific version of mesa?14:32
radiofreeqt5-tools-jetson, gtk2-jetson....14:32
radiofreejjardon: it's more for the upgraded nouveau stuff14:32
jjardonyeah, but probably new kernel will work with old versions of mesa, or am I wrong?14:33
*** rdale has quit IRC14:33
*** rdale has joined #baserock14:34
radiofreeyou could always give it a go, there's quite a lot changed in the out-of-tree driver we're using though14:36
radiofreei'll try it at some point, but for now let's not rush into upgrading to 4.014:37
paulsherwoodradiofree: awww... it's the GENIVI event next week, i was hoping to show 4.0 on jetson14:39
pedroalvarezshowable but not ready to be merged in master of definitions14:40
pedroalvarezno?14:40
paulsherwoodthat's fine14:41
radiofreeoh well, piece of cake then (probably)14:41
*** zoli__ has joined #baserock14:45
jonathanmawhrm, when running the GENIVI Demo Platform, it fails because it threw an instance of 'DBus::Error' The next line is "what(): Process org.freedesktop.systemd1 exited with status 1"14:50
jonathanmawmy best guess is that my dbus is misconfigured14:50
jonathanmaweither that, or starting the program through systemd adds extra magic.14:51
radiofreetry starting a dbus session buss before launching?14:51
jonathanmawradiofree: I already have a dbus session bus14:51
jonathanmaw`env` indicates I have a DBUS_SESSION_BUS_ADDRESS14:51
radiofreeah14:52
radiofreeno idea then14:52
jjardonto calling a configuration extension (from other configuration extension), is there a better way than subprocess.check_call(["/src/morph/morphlib/exts/install-files.configure", ".", manifest]) ?14:54
paulsherwoodjonathanmaw: i assume you've got the marshalling patch?14:55
jonathanmawpaulsherwood: i.e. https://gerrit.baserock.org/#/c/262/? No.14:56
paulsherwoodjonathanmaw: it's dbus related, maybe the gdp needs it?14:56
ssam2jjardon: there must be14:56
ssam2if they both live in the same place, you can get the path of the running script14:56
ssam2probably `os.path.basename(__file__)` would work14:56
ssam2os.path.dirname(__file__) rather14:57
jjardonssam2: thanks, will try that14:58
jjardonmaybe os.path.dirname(os.path.abspath(__file__)) is better though? Anyway lets discuss this in the review15:01
ssam2there's a few ways to do it, I don't know which is best15:05
ssam2as long as it doesn't hardcode a path that might not exist :)15:05
jonathanmawis there a way to read a coredump in systemd? I tried starting the gdp-hmi-controller as a systemd unit and it coredumped with SIGABRT without logging anything.15:13
radiofreejonathanmaw: coredumpctl15:13
paulsherwoodsystemd has all the things :)15:15
jonathanmawcoredumpctl doesn't show anything either :¬|15:16
pedroalvarezHi guys, we are starting to send things for review for openstack. I'll make here some announcements whenever we send a patch. Is that ok?15:17
pedroalvarezFirst series, to upgrade systemd to a version with a fix needed for openstack: https://gerrit.baserock.org/#/q/status:open+project:baserock/baserock/definitions+branch:master+topic:baserock/franred/update-systemd-for-openstack15:17
ssam2jonathanmaw: sometimes you have to use `ulimit` to enable coredumps15:17
ssam2jonathanmaw: try getting `ulimit -c 1000000` to run before whatever the thing is that crashes15:18
ssam2or, you can set it in /etc/sysctl.conf I think, but I don't know how. I've found it http://en.linuxreviews.org/HOWTO_enable_core-dumps15:19
ssam2that message didn't quite meet my usual editorial standards, oh well15:20
paulsherwoodpedroalvarez: go for it15:22
pedroalvarezWe have added openstack ansible modules to the ansible stratum, so we can use them to configure openstack: https://gerrit.baserock.org/#/c/276/15:24
pedroalvarezAlso, we have improved a bit the installation of apache httpd: https://gerrit.baserock.org/#/c/273/15:25
*** zoli__ has quit IRC15:27
*** zoli__ has joined #baserock15:47
*** zoli__ has quit IRC15:55
* paulsherwood +1s all the things16:07
straycat+1 to make lorry show download progress16:17
*** a1exhughe5 has quit IRC16:23
jjardonrichard_maw: seems systemd got update to a sha that: doesnt point to the netlink fix, neither point to a recent version of systemd (the commit is from 13 of March). Also unpetrify-ref points to master instead a tag. Maybe we can improve this next time? (I think use the result of 'git describe' for the tag would be a good idea in this cases)16:37
pedroalvarezjjardon: hm.. it may be not his fault, he didn't sent it for review :/16:38
pedroalvarezwe did16:38
richard_mawjjardon: there is no released version of systemd that includes the netlink fix16:38
richard_mawjjardon: the sha1 I set in the openstack branch was pointing to one that included other networking fixes16:39
richard_mawjjardon: master is the most appropriate anchor, since there are no others16:39
richard_mawI had hoped there would be a systemd release before we had to start upstreaming, but that hasn't happened16:40
paulsherwoodgiven systemd folk are never going to force-push, master as unpetrify-ref might be ok?16:42
jjardonrichard_maw: yeah, I know is not yet in any release: my suggestion was to point to the commit that include the fix, or if you want to point to another commit, use the output of "git describe" in unpetrify-ref so it will have some meaning for a human16:42
richard_mawwe do not put the output of `git describe` in unpetrify-ref, that field is for the branch the commit came from16:43
jjardonrichard_maw: then create a tag/branch in our repo16:43
richard_mawwe don't have a way to do that with gerrit16:43
richard_mawand I'd rather avoid a delta16:43
jjardonalso, I though unpetrify-ref is completely ignored by morph, so we can use it for information pourposses16:44
richard_mawI'm not going to change its semantics.16:44
jjardonrichard_maw: you are not doing any delta if you create a tag/branch16:44
paulsherwoodjonathanmaw: monstrosity, really? there will be some hurt feelings, now16:45
jjardonrichard_maw: for someone that inspect our definitions, is difficult to know what version of systemd we are using16:46
*** mariaderidder has quit IRC16:46
richard_mawjjardon: that is true, and the proper thing to do here would be to create a v219.1 release which just has the netlink fix we need cherry-picked on, but that _would_ be a delta16:47
jjardonrichard_maw: Or point to the commit that introduce the commit and create a v219+netlink_fix tag; I would prefer that, at least I know the version of the components Im building16:51
*** brlogger` has joined #baserock16:51
richard_mawjjardon: I'm sorry, but I don't have sufficient time to devote to this discussion, franred and pedroalvarez submitted this patch, could you please direct concerns towards them now?16:51
paulsherwoodfwiw it would be trivial to report during build, say, 30add465 (2.0.0 + 1 commits)  (ybd does this). maybe that info would be more useful than unpetrify-ref?16:51
*** brlogger has quit IRC16:52
richard_mawsuch information is included in the built system16:52
jjardonrichard_maw: sure16:52
jjardonfranred: do you think we can improve this? what solution do you prefer?16:54
jjardonpedroalvarez: ^16:54
pedroalvarezwell... there are more repos where we use unpetrify-ref master16:55
pedroalvarezbecause there aren't new release tags16:55
*** Guest71855 has quit IRC16:55
jjardonI think thats a different problem?16:56
pedroalvarezif this kind of component upgrades are done to get only one fix, I agree we can just create a branch based on latest tag, and then cherry pick the fix from upstream16:56
pedroalvarezthen the branch can be called tag-<describe-fix>16:56
pedroalvarezthis case is a bit different though, and a bit strange16:56
pedroalvarezso, when is the next systemd release? :P16:57
jjardonthats why I suggest to create a tag with: tag-<`git-describe`> and then point unpetrify-ref to that16:58
Kinnisonwin 4016:58
pedroalvarezs/tag/branch/ I guess16:59
jjardonno, tag16:59
pedroalvarezhmm16:59
pedroalvarezmmmkay16:59
pedroalvarezwhy tag though?17:00
jjardonI do not care really, but we are not going to create any delta17:00
pedroalvareztag should have some sort of prefix (baserock-tag)17:00
straycatthere's a bug in ntp that means to run a server in baserock we need to either allow it to run as root, or only use ips in ntp.conf, thoughts on which approach is preferable?17:00
straycatrelated reading: https://lists.archlinux.org/pipermail/arch-general/2014-May/036225.html http://bugs.ntp.org/show_bug.cgi?id=2646 http://bugs.ntp.org/show_bug.cgi?id=265317:01
pedroalvarezstraycat: problems of running it as root?17:01
straycatless secure17:01
franredjjardon, I prefer not to create tags because we are not releasing anything... branches are cheap and could do the same as the tag, though17:02
straycatKinnison, penny for your thoughts?17:02
*** bashrc_ has quit IRC17:02
jjardonpedroalvarez: what about baserock-v219-314-gd736e4f ?17:02
pedroalvarezhm..17:03
Kinnisonstraycat: regarding?17:03
*** jonathanmaw has quit IRC17:03
straycatKinnison, the ntp thing17:03
Kinnisonwhy can ntpd not run as non-root?17:03
straycatit can it's just there's a bug in the threaded name resolver or something17:04
straycatso if you try to resolve a name ntp can somehow end up using up its allocated memory and so it crashes with an out of memory error17:04
straycatso, we can run non-root but we'd have to use only ips in the ntp.conf17:04
*** gary_perkins_ has quit IRC17:05
KinnisonI'd go with that short-term17:06
Kinnisonand hope they fix the resolver longer-term17:06
*** ssam2 has quit IRC17:13
jjardonpedroalvarez: franred sent a patch here: https://gerrit.baserock.org/#/c/279/17:15
franredjjardon, thanks for this17:17
*** marcdunford has quit IRC17:17
*** lachlanmackenzie has joined #baserock17:18
*** edcragg has quit IRC17:21
straycatKinnison, cool thanks17:42
jjardonpaulsherwood: I rework your dbus patch in case you have time to review it17:43
jjardonreworked*17:43
paulsherwoodjjardon: i've given it +2, this has had more than enough attention already. thanks!17:49
* straycat pushes https://gerrit.baserock.org/28017:55
*** lachlanmackenzie has quit IRC17:56
straycatjjardon, pedroalvarez  thanks :)17:59
*** franred has quit IRC18:27
* paulsherwood notices that the gerrit workflow does appear to be faster than the ml, especially for small changes19:30
KinnisonYes, it is faster for small things19:33
KinnisonIMO it's harder for larger things, esp. things which need deep discussion19:33
KinnisonHopefully people who write those sorts of changes will use hte ML for discussion first (perhaps an RFC patchset to the ML first fr.ex)19:33
straycatit's definitely faster19:35
* straycat doesn't think he can justify adding ntpd to the devel system, given we have systemd-timesyncd19:37
* Kinnison nods19:37
straycatso we'll have a swift-system19:37
KinnisonIf you're only adding ntpd for the *server* functionality then it probably doesn't belong in devel-system IMO19:38
KinnisonIt probably belongs in the swift stratum19:38
straycatwell, then it'd be included in the devel system, since swift is in the devel system19:38
Kinnisonreally?!19:38
KinnisonI'd have expected swift clients in devel but not swift itself19:38
straycatwe use swift to deploy swift19:38
KinnisonUrgh19:39
straycatactually it's quite neat19:39
straycatand much simpler than trying to distribute all the swift structures to each node when they start up19:39
KinnisonI meant "urgh" that you need all of swift where the other services are split cleanly into client and service19:40
straycatahh yes :/19:42
*** Albert has quit IRC19:48
straycatlooks like mesa failed to build20:07
*** JPohlman1 has joined #baserock21:36
*** JPohlmann has quit IRC21:38

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!