| *** zoli__ has joined #baserock | 00:43 | |
| *** zoli__ has quit IRC | 00:48 | |
| *** zoli__ has joined #baserock | 00:58 | |
| *** zoli__ has quit IRC | 01:02 | |
| *** zoli__ has joined #baserock | 01:22 | |
| *** zoli__ has quit IRC | 01:27 | |
| *** zoli__ has joined #baserock | 03:11 | |
| *** zoli__ has quit IRC | 03:15 | |
| *** zoli__ has joined #baserock | 04:29 | |
| *** zoli__ has quit IRC | 05:47 | |
| *** zoli__ has joined #baserock | 06:09 | |
| *** petefoth has joined #baserock | 06:24 | |
| *** petefoth has quit IRC | 07:02 | |
| *** Albert has joined #baserock | 07:02 | |
| *** petefoth has joined #baserock | 07:05 | |
| *** a1exhughe5 has joined #baserock | 07:06 | |
| *** rdale has joined #baserock | 07:13 | |
| *** mdizzle has joined #baserock | 07:48 | |
| *** jonathanmaw has joined #baserock | 07:50 | |
| *** sambishop has joined #baserock | 08:06 | |
| *** bashrc_ has joined #baserock | 08:08 | |
| *** pdar_ has left #baserock | 08:14 | |
| *** edcragg has joined #baserock | 08:15 | |
| *** pdar has joined #baserock | 08:17 | |
| straycat | Kinnison, http://sprunge.us/RJfP | 08:28 |
|---|---|---|
| * Kinnison will look, but don't expect rapidity -- my laptop is still mid-security-updates | 08:28 | |
| straycat | Okay thanks | 08:29 |
| *** tiagogomes_ has joined #baserock | 08:29 | |
| Kinnison | straycat: so the mounts look sane, no MS_RDONLY flags or anything | 08:34 |
| Kinnison | no obvious changing of the UID maps | 08:34 |
| Kinnison | the capabilities things look okay | 08:35 |
| pedroalvarez | straycat: oh, ownership in linux-user-chroot? | 08:36 |
| straycat | from 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 chroot | 08:36 |
| straycat | pedroalvarez, yes | 08:36 |
| pedroalvarez | straycat: we faced this before. | 08:37 |
| pedroalvarez | in fact, there are some notes in: strata/apache-httpd-server/httpd-server.morph | 08:37 |
| straycat | # This is not possible because linux-user-chroot drops all capabilities for security so | 08:37 |
| straycat | # it does not allow to change the owners of directories or files | 08:37 |
| straycat | why couldn't i see that from the status file | 08:38 |
| * Kinnison must be misreading this prctl then | 08:39 | |
| Kinnison | i thought it was setting the override flags for chown/etc | 08:39 |
| pedroalvarez | i'm not saying that our notes are 100% true, though | 08:39 |
| straycat | looking 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 something | 08:41 |
| jjardon | paulsherwood: 1.8.16 is the latest stable release (1.9.x are development versions) | 08:41 |
| paulsherwood | jjardon: ok | 08: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 |
| franred | richard_maw, ^^ | 08:52 |
| straycat | oh hang on there is SECBIT_NOROOT though | 08:54 |
| straycat | SECBIT_NOROOT | 08:55 |
| straycat | If this bit is set, then the kernel does not grant capabilities when a set-user-ID-root program is | 08:55 |
| straycat | executed, or when a process with an effective or real UID of 0 calls execve(2). (See the subsection | 08:56 |
| straycat | Capabilities and execution of programs by root.) | 08:56 |
| *** CTtpollard has joined #baserock | 08:56 | |
| straycat | so i guess that explains it | 08:56 |
| straycat | *sigh* i wish you guys had been here yesterday >.> | 08:56 |
| *** gary_perkins has joined #baserock | 08:57 | |
| *** ssam2 has joined #baserock | 08:57 | |
| *** ChanServ sets mode: +v ssam2 | 08:57 | |
| straycat | maybe we should put a warning about that somewhere on the wiki, in the faq or something, i doubt i would have looked there, but still | 08:59 |
| ssam2 | https://wiki.baserock.org/ should now work (no more 'this site is not here yet' errors), please let me know if it doesn't | 09:00 |
| ssam2 | the fix was to send our SSL cert to Branchable so they could install it | 09:00 |
| straycat | cool | 09:02 |
| *** mike has joined #baserock | 09:10 | |
| *** mike is now known as Guest71855 | 09:10 | |
| *** SotK_ has joined #baserock | 09:20 | |
| *** SotK has quit IRC | 09:24 | |
| *** SotK_ is now known as SotK | 09:25 | |
| *** mauricemoss_ has joined #baserock | 09:27 | |
| straycat | hardcoding the uid and gid of the user and group and chowning from a conf ext is reasonable? | 09:30 |
| paulsherwood | straycat: could these be taken from (new) fields in definitions? | 09:32 |
| straycat | i guess so | 09:34 |
| paulsherwood | straycat: 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 numbers | 09:36 |
| franred | edcragg, 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 |
| straycat | paulsherwood, yes that sounds like it might be a useful thing to have | 09:37 |
| paulsherwood | straycat: great. my answer to your question is yes, then, provided the extension takes its info from definitions if it can | 09:38 |
| straycat | paulsherwood, it can't right now because those fields don't exist | 09:40 |
| straycat | but we can add them later | 09:40 |
| paulsherwood | straycat: please add them? | 09:41 |
| * Kinnison believes we discussed such arbitrary configuration (incl. users/groups as an example) during the baserock meetup | 09:41 | |
| paulsherwood | how hard can it be? :) | 09:41 |
| Kinnison | Consider <20150206130136.GW1787@somnambulist.local> on baserock-dev | 09:41 |
| Kinnison | So hard that noone ever followed up | 09:42 |
| paulsherwood | Kinnison: i don't know how to parse that? | 09:42 |
| Kinnison | paulsherwood: how to parse the email? | 09:42 |
| Kinnison | paulsherwood: Or how to search for a message by message-id in your mail client? | 09:43 |
| paulsherwood | Kinnison: the latter. i have no mail client on my current machine | 09:43 |
| Kinnison | aah | 09:43 |
| rjek | ISTR 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 |
| Kinnison | paulsherwood: http://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2015-February/011181.html | 09:44 |
| * petefoth would be interested in knowing how to 'search for a message by message-id in your mail client' where mail lient==Thunderbird | 09:44 | |
| * petefoth googles | 09:44 | |
| richard_maw | paulsherwood: 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 ours | 09:46 |
| richard_maw | though AIUI it's mostly just to provide a structured approach to applying the UID/GIDs at runtime | 09:46 |
| radiofree | petefoth: edit->find->search messages, select customise and enter Message-Id | 09:47 |
| ssam2 | petefoth: I find it easier to download the whole mail archive off mailmail to a directory, then use 'grep' | 09:47 |
| rjek | It makes sense for there to be a centralised post-install UID management thingy, as every distro has to implement it anyway | 09:47 |
| ssam2 | petefoth: that way it doesn't matter the mails predate your being a member of the list. | 09:47 |
| *** jonathanmaw has quit IRC | 09:47 | |
| petefoth | radiofree: ta! Is the id the whole link or just the part before the @? | 09:48 |
| radiofree | it's the whole thing, but without the <>, so 20150206130136.GW1787@somnambulist.local | 09:48 |
| petefoth | ssam2: or use google on the archive page for public lists | 09:48 |
| paulsherwood | Kinnison: thanks | 09:49 |
| paulsherwood | richard_maw: thanks also :) | 09:49 |
| paulsherwood | Kinnison: that's a really interesting email which i missed entirely first time around, thanks! | 09:50 |
| * Kinnison grins | 09: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 | +1 | 09:54 |
| paulsherwood | and we're rapidly approaching time for plannign the next one! | 09:54 |
| Kinnison | Already? Cripes | 09:56 |
| paulsherwood | the target would be july/aug iirc | 09:56 |
| paulsherwood | and we should stop being so last-minute | 09:56 |
| Kinnison | aah | 09:56 |
| Kinnison | I was expecting early september TBH | 09:57 |
| *** jonathanmaw has joined #baserock | 10:04 | |
| jonathanmaw | hrm, 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/icomucoqit | 10:26 |
| jonathanmaw | which is odd, because `readelf -Ws usr/lib/libilmClient | grep UpdateInputEventAcceptanceOn` shows that it exists | 10:27 |
| Kinnison | look at the config.log | 10:27 |
| Kinnison | it may be more subtle than that | 10:27 |
| radiofree | jonathanmaw: which version of wayland-ivi-extension are you using? | 10:31 |
| jonathanmaw | radiofree: 1.3.91 | 10:31 |
| radiofree | didn't you remove UpdateInputEventAcceptanceOn? | 10:31 |
| jonathanmaw | radiofree: that's just after 1.3.91 | 10:31 |
| radiofree | ah | 10:31 |
| jonathanmaw | the symbol exists, but the failure appears to be undefined references to ilmControl_{destroy,init} | 10:31 |
| radiofree | i seem to remember some discussion about input focus etc.. | 10:32 |
| radiofree | perhaps they're using a modified wayland-ivi-extension? what version are they using in yocto | 10:32 |
| jonathanmaw | radiofree: they appear to use 1.2.0 or 1.3.0 | 10:39 |
| jonathanmaw | I'll try 1.3.0, and if that fails just comment out the cause of build failure | 10:39 |
| jonathanmaw | since the problem appears to be that it's testing ilmClient without also linking against ilmControl | 10:40 |
| ssam2 | hello, opinions wanted | 10:45 |
| ssam2 | I want to add something like 'upgrade-type' and 'upgrade-location' to cluster morphs | 10:46 |
| ssam2 | to avoid having to edit them when you want to upgrade something you already deployed | 10:46 |
| ssam2 | does this sound like a good idea? are the names sensible? | 10:46 |
| radiofree | so you could use the same cluster for deploy and upgrade? | 10:46 |
| ssam2 | yeah | 10:46 |
| radiofree | i like the sound of that | 10:46 |
| Kinnison | Seems reasonable (and acceptably named) to me | 10:46 |
| Kinnison | +1 | 10:47 |
| ssam2 | i'd prefer upgrade-method, but we already have 'type' so upgrade-type is more consistent | 10:47 |
| ssam2 | ok, i'll get to work | 10:47 |
| ratmice__ | jonathanmaw: seems odd, if ilmClient depends on ilmControl it should link to it itself | 10:52 |
| *** flatmush1 is now known as flatmush | 10:52 | |
| * richard_maw pushed https://gerrit.baserock.org/#/c/267/ for the sake of completeness | 10:52 | |
| richard_maw | The 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 others | 10:53 |
| ssam2 | install-files supports templates now! that's cool | 10:56 |
| jjardon | Hi, is there any way to remove some files from the /etc directory after the system is created? | 10:58 |
| Kinnison | jjardon: system integration scripts, or else configuration extensions I'd guess | 10:58 |
| jjardon | Kinnison: ok, thanks | 11:00 |
| edcragg | franred: i've amended change 127 | 11:01 |
| edcragg | richard_maw, ssam2 any chance you could take a look at that change if you have a chance? ^ | 11:42 |
| ssam2 | sure | 11:43 |
| *** petefoth has left #baserock | 11:44 | |
| jjardon | ssam2: 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 | |
| jonathanmaw | paulsherwood: which patch would this be? | 13:05 |
| paulsherwood | https://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 implementation | 13:11 | |
| *** mdizzle is now known as mariaderidder | 13:25 | |
| jjardon | richard_maw: but systemd still depends on dbus? (and dbus on systemd) | 13:26 |
| richard_maw | jjardon: it needs the daemon at runtime (until kdbus gets in), but at build-time I don't think it needs libdbus | 13:31 |
| paulsherwood | can we upgrade to 4.0 please? | 13:33 |
| paulsherwood | who wants to do that patch? | 13:33 |
| * paulsherwood +1s in advance | 13:33 | |
| paulsherwood | c'mon, let's not hang about :) http://git.baserock.org/cgi-bin/cgit.cgi/delta/linux.git/ | 13:34 |
| SotK | I think I saw a patch for that in Gerrit already | 13:34 |
| SotK | https://gerrit.baserock.org/#/q/topic:linux_4_0 | 13:35 |
| paulsherwood | reviewed | 13:35 |
| jjardon | richard_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 that | 13:37 |
| paulsherwood | are there other bsps that can move forward too? | 13:37 |
| paulsherwood | radiofree: jetson for example? | 13:37 |
| radiofree | need cpufreq + i think there are some unmerged nouveau changes | 13:38 |
| * paulsherwood needs to recover his jetson | 13:38 | |
| paulsherwood | SotK: can you + 1 it, please? | 13:44 |
| SotK | sure | 13:46 |
| radiofree | i think if we upgrade the kernel + nouveau we're going to need to upgrade mesa | 13:47 |
| radiofree | which is apparently a big no-no on x86 | 13:47 |
| *** rdale has quit IRC | 13:58 | |
| *** rdale has joined #baserock | 14:00 | |
| *** bashrc_ has quit IRC | 14:00 | |
| *** nowster has quit IRC | 14:00 | |
| *** sambishop has quit IRC | 14:01 | |
| *** a1exhughe5 has quit IRC | 14:01 | |
| *** franred has quit IRC | 14:01 | |
| *** paulw has quit IRC | 14:01 | |
| *** jonathanmaw has quit IRC | 14:01 | |
| *** tiagogomes_ has quit IRC | 14:01 | |
| *** ssam2 has quit IRC | 14:01 | |
| *** tpollard_ has joined #baserock | 14:01 | |
| *** flatmush has quit IRC | 14:01 | |
| *** Guest71855 has quit IRC | 14:01 | |
| *** marcdunford has quit IRC | 14:01 | |
| *** fay_ has quit IRC | 14:01 | |
| *** gary_perkins has quit IRC | 14:01 | |
| *** ssam2 has joined #baserock | 14:01 | |
| *** ChanServ sets mode: +v ssam2 | 14:01 | |
| *** edcragg has quit IRC | 14:01 | |
| *** mariaderidder has quit IRC | 14:01 | |
| *** CTtpollard has quit IRC | 14:01 | |
| *** gary_perkins_ has joined #baserock | 14:01 | |
| *** mauricemoss_ has quit IRC | 14:01 | |
| *** bashrc_ has joined #baserock | 14:01 | |
| *** tiagogomes_ has joined #baserock | 14:01 | |
| *** mariaderidder has joined #baserock | 14:01 | |
| *** franred has joined #baserock | 14:01 | |
| *** a1exhughe5 has joined #baserock | 14:01 | |
| *** mauricemoss_ has joined #baserock | 14:01 | |
| *** fay_ has joined #baserock | 14:01 | |
| *** Guest71855 has joined #baserock | 14:02 | |
| *** nowster has joined #baserock | 14:02 | |
| *** petefoth has joined #baserock | 14:02 | |
| *** edcragg has joined #baserock | 14:02 | |
| *** sambishop has joined #baserock | 14:02 | |
| *** paulw has joined #baserock | 14:02 | |
| *** jonathanmaw has joined #baserock | 14:02 | |
| *** marcdunford has joined #baserock | 14:02 | |
| *** flatmush has joined #baserock | 14:03 | |
| *** Albert has quit IRC | 14:05 | |
| *** Albert has joined #baserock | 14:06 | |
| jjardon | paulsherwood: 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-cpufreq | 14:19 |
| jjardon | diff for armv8l: http://git.baserock.org/cgi-bin/cgit.cgi/delta/linux.git/log/?h=baserock/apm-xgene-m400-moonshot-cartridge | 14:22 |
| jjardon | doesnt seem those patches are upstreamed yet | 14:24 |
| * radiofree wonders when the cpufreq patches will be merged | 14:25 | |
| radiofree | cyndis? ^ | 14:25 |
| cyndis | cpufreq just got acked on friday | 14:25 |
| radiofree | great :D | 14:26 |
| radiofree | they 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-cpufreq | 14:26 |
| cyndis | yeah, finally :p | 14:26 |
| radiofree | jjardon: but we'll probably have to upgrade mesa now | 14:28 |
| radiofree | there's been no progress on https://bugs.freedesktop.org/show_bug.cgi?id=86701 | 14:28 |
| radiofree | so i'm not sure what we need to do there, mesa-common-jetson? | 14:28 |
| *** zoli__ has quit IRC | 14:28 | |
| radiofree | which would mean we need graphics-common-jetson. multimedia-gstreamer-common-jetson, x-generic-jetson.... | 14:31 |
| jjardon | radiofree: bfff, that means we will have to duplicate everything on top of mesa.. | 14:31 |
| radiofree | gtk-deps-jetson, weston-common-jetson, weston-genivi-jetson... | 14:32 |
| jjardon | yeah, do you have more info why linux depends on a specific version of mesa? | 14:32 |
| radiofree | qt5-tools-jetson, gtk2-jetson.... | 14:32 |
| radiofree | jjardon: it's more for the upgraded nouveau stuff | 14:32 |
| jjardon | yeah, but probably new kernel will work with old versions of mesa, or am I wrong? | 14:33 |
| *** rdale has quit IRC | 14:33 | |
| *** rdale has joined #baserock | 14:34 | |
| radiofree | you could always give it a go, there's quite a lot changed in the out-of-tree driver we're using though | 14:36 |
| radiofree | i'll try it at some point, but for now let's not rush into upgrading to 4.0 | 14:37 |
| paulsherwood | radiofree: awww... it's the GENIVI event next week, i was hoping to show 4.0 on jetson | 14:39 |
| pedroalvarez | showable but not ready to be merged in master of definitions | 14:40 |
| pedroalvarez | no? | 14:40 |
| paulsherwood | that's fine | 14:41 |
| radiofree | oh well, piece of cake then (probably) | 14:41 |
| *** zoli__ has joined #baserock | 14:45 | |
| jonathanmaw | hrm, 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 |
| jonathanmaw | my best guess is that my dbus is misconfigured | 14:50 |
| jonathanmaw | either that, or starting the program through systemd adds extra magic. | 14:51 |
| radiofree | try starting a dbus session buss before launching? | 14:51 |
| jonathanmaw | radiofree: I already have a dbus session bus | 14:51 |
| jonathanmaw | `env` indicates I have a DBUS_SESSION_BUS_ADDRESS | 14:51 |
| radiofree | ah | 14:52 |
| radiofree | no idea then | 14:52 |
| jjardon | to 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 |
| paulsherwood | jonathanmaw: i assume you've got the marshalling patch? | 14:55 |
| jonathanmaw | paulsherwood: i.e. https://gerrit.baserock.org/#/c/262/? No. | 14:56 |
| paulsherwood | jonathanmaw: it's dbus related, maybe the gdp needs it? | 14:56 |
| ssam2 | jjardon: there must be | 14:56 |
| ssam2 | if they both live in the same place, you can get the path of the running script | 14:56 |
| ssam2 | probably `os.path.basename(__file__)` would work | 14:56 |
| ssam2 | os.path.dirname(__file__) rather | 14:57 |
| jjardon | ssam2: thanks, will try that | 14:58 |
| jjardon | maybe os.path.dirname(os.path.abspath(__file__)) is better though? Anyway lets discuss this in the review | 15:01 |
| ssam2 | there's a few ways to do it, I don't know which is best | 15:05 |
| ssam2 | as long as it doesn't hardcode a path that might not exist :) | 15:05 |
| jonathanmaw | is 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 |
| radiofree | jonathanmaw: coredumpctl | 15:13 |
| paulsherwood | systemd has all the things :) | 15:15 |
| jonathanmaw | coredumpctl doesn't show anything either :¬| | 15:16 |
| pedroalvarez | Hi 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 |
| pedroalvarez | First 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-openstack | 15:17 |
| ssam2 | jonathanmaw: sometimes you have to use `ulimit` to enable coredumps | 15:17 |
| ssam2 | jonathanmaw: try getting `ulimit -c 1000000` to run before whatever the thing is that crashes | 15:18 |
| ssam2 | or, 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-dumps | 15:19 |
| ssam2 | that message didn't quite meet my usual editorial standards, oh well | 15:20 |
| paulsherwood | pedroalvarez: go for it | 15:22 |
| pedroalvarez | We 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 |
| pedroalvarez | Also, we have improved a bit the installation of apache httpd: https://gerrit.baserock.org/#/c/273/ | 15:25 |
| *** zoli__ has quit IRC | 15:27 | |
| *** zoli__ has joined #baserock | 15:47 | |
| *** zoli__ has quit IRC | 15:55 | |
| * paulsherwood +1s all the things | 16:07 | |
| straycat | +1 to make lorry show download progress | 16:17 |
| *** a1exhughe5 has quit IRC | 16:23 | |
| jjardon | richard_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 |
| pedroalvarez | jjardon: hm.. it may be not his fault, he didn't sent it for review :/ | 16:38 |
| pedroalvarez | we did | 16:38 |
| richard_maw | jjardon: there is no released version of systemd that includes the netlink fix | 16:38 |
| richard_maw | jjardon: the sha1 I set in the openstack branch was pointing to one that included other networking fixes | 16:39 |
| richard_maw | jjardon: master is the most appropriate anchor, since there are no others | 16:39 |
| richard_maw | I had hoped there would be a systemd release before we had to start upstreaming, but that hasn't happened | 16:40 |
| paulsherwood | given systemd folk are never going to force-push, master as unpetrify-ref might be ok? | 16:42 |
| jjardon | richard_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 human | 16:42 |
| richard_maw | we do not put the output of `git describe` in unpetrify-ref, that field is for the branch the commit came from | 16:43 |
| jjardon | richard_maw: then create a tag/branch in our repo | 16:43 |
| richard_maw | we don't have a way to do that with gerrit | 16:43 |
| richard_maw | and I'd rather avoid a delta | 16:43 |
| jjardon | also, I though unpetrify-ref is completely ignored by morph, so we can use it for information pourposses | 16:44 |
| richard_maw | I'm not going to change its semantics. | 16:44 |
| jjardon | richard_maw: you are not doing any delta if you create a tag/branch | 16:44 |
| paulsherwood | jonathanmaw: monstrosity, really? there will be some hurt feelings, now | 16:45 |
| jjardon | richard_maw: for someone that inspect our definitions, is difficult to know what version of systemd we are using | 16:46 |
| *** mariaderidder has quit IRC | 16:46 | |
| richard_maw | jjardon: 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 delta | 16:47 |
| jjardon | richard_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 building | 16:51 |
| *** brlogger` has joined #baserock | 16:51 | |
| richard_maw | jjardon: 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 |
| paulsherwood | fwiw 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 IRC | 16:52 | |
| richard_maw | such information is included in the built system | 16:52 |
| jjardon | richard_maw: sure | 16:52 |
| jjardon | franred: do you think we can improve this? what solution do you prefer? | 16:54 |
| jjardon | pedroalvarez: ^ | 16:54 |
| pedroalvarez | well... there are more repos where we use unpetrify-ref master | 16:55 |
| pedroalvarez | because there aren't new release tags | 16:55 |
| *** Guest71855 has quit IRC | 16:55 | |
| jjardon | I think thats a different problem? | 16:56 |
| pedroalvarez | if 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 upstream | 16:56 |
| pedroalvarez | then the branch can be called tag-<describe-fix> | 16:56 |
| pedroalvarez | this case is a bit different though, and a bit strange | 16:56 |
| pedroalvarez | so, when is the next systemd release? :P | 16:57 |
| jjardon | thats why I suggest to create a tag with: tag-<`git-describe`> and then point unpetrify-ref to that | 16:58 |
| Kinnison | win 40 | 16:58 |
| pedroalvarez | s/tag/branch/ I guess | 16:59 |
| jjardon | no, tag | 16:59 |
| pedroalvarez | hmm | 16:59 |
| pedroalvarez | mmmkay | 16:59 |
| pedroalvarez | why tag though? | 17:00 |
| jjardon | I do not care really, but we are not going to create any delta | 17:00 |
| pedroalvarez | tag should have some sort of prefix (baserock-tag) | 17:00 |
| straycat | there'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 |
| straycat | related 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=2653 | 17:01 |
| pedroalvarez | straycat: problems of running it as root? | 17:01 |
| straycat | less secure | 17:01 |
| franred | jjardon, I prefer not to create tags because we are not releasing anything... branches are cheap and could do the same as the tag, though | 17:02 |
| straycat | Kinnison, penny for your thoughts? | 17:02 |
| *** bashrc_ has quit IRC | 17:02 | |
| jjardon | pedroalvarez: what about baserock-v219-314-gd736e4f ? | 17:02 |
| pedroalvarez | hm.. | 17:03 |
| Kinnison | straycat: regarding? | 17:03 |
| *** jonathanmaw has quit IRC | 17:03 | |
| straycat | Kinnison, the ntp thing | 17:03 |
| Kinnison | why can ntpd not run as non-root? | 17:03 |
| straycat | it can it's just there's a bug in the threaded name resolver or something | 17:04 |
| straycat | so 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 error | 17:04 |
| straycat | so, we can run non-root but we'd have to use only ips in the ntp.conf | 17:04 |
| *** gary_perkins_ has quit IRC | 17:05 | |
| Kinnison | I'd go with that short-term | 17:06 |
| Kinnison | and hope they fix the resolver longer-term | 17:06 |
| *** ssam2 has quit IRC | 17:13 | |
| jjardon | pedroalvarez: franred sent a patch here: https://gerrit.baserock.org/#/c/279/ | 17:15 |
| franred | jjardon, thanks for this | 17:17 |
| *** marcdunford has quit IRC | 17:17 | |
| *** lachlanmackenzie has joined #baserock | 17:18 | |
| *** edcragg has quit IRC | 17:21 | |
| straycat | Kinnison, cool thanks | 17:42 |
| jjardon | paulsherwood: I rework your dbus patch in case you have time to review it | 17:43 |
| jjardon | reworked* | 17:43 |
| paulsherwood | jjardon: i've given it +2, this has had more than enough attention already. thanks! | 17:49 |
| * straycat pushes https://gerrit.baserock.org/280 | 17:55 | |
| *** lachlanmackenzie has quit IRC | 17:56 | |
| straycat | jjardon, pedroalvarez thanks :) | 17:59 |
| *** franred has quit IRC | 18:27 | |
| * paulsherwood notices that the gerrit workflow does appear to be faster than the ml, especially for small changes | 19:30 | |
| Kinnison | Yes, it is faster for small things | 19:33 |
| Kinnison | IMO it's harder for larger things, esp. things which need deep discussion | 19:33 |
| Kinnison | Hopefully 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 |
| straycat | it's definitely faster | 19:35 |
| * straycat doesn't think he can justify adding ntpd to the devel system, given we have systemd-timesyncd | 19:37 | |
| * Kinnison nods | 19:37 | |
| straycat | so we'll have a swift-system | 19:37 |
| Kinnison | If you're only adding ntpd for the *server* functionality then it probably doesn't belong in devel-system IMO | 19:38 |
| Kinnison | It probably belongs in the swift stratum | 19:38 |
| straycat | well, then it'd be included in the devel system, since swift is in the devel system | 19:38 |
| Kinnison | really?! | 19:38 |
| Kinnison | I'd have expected swift clients in devel but not swift itself | 19:38 |
| straycat | we use swift to deploy swift | 19:38 |
| Kinnison | Urgh | 19:39 |
| straycat | actually it's quite neat | 19:39 |
| straycat | and much simpler than trying to distribute all the swift structures to each node when they start up | 19:39 |
| Kinnison | I meant "urgh" that you need all of swift where the other services are split cleanly into client and service | 19:40 |
| straycat | ahh yes :/ | 19:42 |
| *** Albert has quit IRC | 19:48 | |
| straycat | looks like mesa failed to build | 20:07 |
| *** JPohlman1 has joined #baserock | 21:36 | |
| *** JPohlmann has quit IRC | 21:38 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!