*** gtristan has quit IRC | 05:32 | |
*** gtristan has joined #baserock | 05:46 | |
gtristan | jjardon, looks good to me, I dont know how to 'review' it though :) | 05:56 |
---|---|---|
gtristan | theres a suspicious "add reviewers" button which brings up an entry... enter comments in the entry ? | 05:56 |
gtristan | I am curious however... how do you deal with building stable ? | 05:57 |
gtristan | just keep stable branches of definitions repo ? | 05:57 |
*** paulwaters_ has joined #baserock | 06:33 | |
gtristan | jjardon, does gdk-pixbuf predate 'system-integration' hooks ? or is there a reason that querying the loaders happens during the install stage instead of at the end of build ? | 07:04 |
* gtristan thinks the build will lack svg support | 07:04 | |
*** ssam2 has joined #baserock | 07:10 | |
*** ChanServ sets mode: +v ssam2 | 07:10 | |
gtristan | jjardon, ah I see you have a 'task' for that on storyboard which is marked in-progress | 07:17 |
gtristan | I'm quite sure that moving those commands to 'system-integration' is the right fix | 07:18 |
gtristan | I asked this before to the channel... but was mixed with a dozen other questions | 07:18 |
gtristan | any thoughts on --sysconfdir=/etc all across the board ? | 07:19 |
gtristan | or, at least for packages which do not specify a specific .morph (default autotools) | 07:19 |
ssam2 | oh, that would make sense | 07:19 |
* gtristan finds himself creating .morph files for packages... only because they dont specify that | 07:20 | |
gtristan | there are some exceptions, for instance openssh wants sysconfdir to be /etc/ssh | 07:20 |
ssam2 | only gotcha is that until we move to definitions format version 7, it's a bit of a pain to change the defaults | 07:20 |
ssam2 | because they live in the build tools instead of in definitions.git at the moment | 07:21 |
gtristan | I see | 07:21 |
ssam2 | once https://gerrit.baserock.org/#/c/1018/ is merged, and we do a release, and then merge https://gerrit.baserock.org/#/c/1083/, it'll be super easy to change that though | 07:22 |
gtristan | hmmm... so I will keep working around this for now... | 07:22 |
gtristan | I'll open a 'story' for it | 07:22 |
ssam2 | good idea | 07:22 |
gtristan | filed as https://storyboard.baserock.org/#!/story/58 | 07:27 |
*** franred has joined #baserock | 07:37 | |
*** toscalix__ has joined #baserock | 07:57 | |
*** bashrc has joined #baserock | 08:04 | |
*** mariaderidder has joined #baserock | 08:05 | |
jjardon | hi gtristan : to review, go to the change in gerrit, press, the 'Replay' button and choose +1/-1 | 08:23 |
jjardon | gtristan: to checkout the branch to review: git review -d <change number> | 08:24 |
gtristan | gotcha :) | 08:25 |
gtristan | jjardon, now we also dont have to even care about the modules going into this odd /usr/etc location too, as there wont be any ;-) | 08:28 |
gtristan | s/the modules/the loaders file | 08:28 |
*** gary_perkins has quit IRC | 08:34 | |
*** gary_perkins has joined #baserock | 08:38 | |
*** mariaderidder has quit IRC | 09:02 | |
*** paulwaters_ has quit IRC | 09:04 | |
*** toscalix__ is now known as toscalix | 09:05 | |
*** paulwaters_ has joined #baserock | 09:05 | |
*** gary_perkins has quit IRC | 09:12 | |
*** edcragg has joined #baserock | 09:12 | |
*** jonathanmaw has joined #baserock | 09:15 | |
*** mariaderidder has joined #baserock | 09:16 | |
paulsherwood | pedroalvarez: yes it would. but also it's about time we overhauled our documentation (again). i'm planning to to some ybd video tutorials when i get some time | 10:14 |
*** Phlogistique has joined #baserock | 10:15 | |
gtristan | aherm.... so the ref: in the morph is supposed to be a commit id... | 10:26 |
gtristan | But NetworkManager-common.morph... refers to a commit ID which does not exist in the NetworkManager repository | 10:27 |
gtristan | (either in upstream freedesktop git, or in the lorry git) | 10:27 |
gtristan | just a bug I guess, but... what would that infer... if the commit is not found, the unpetrify-ref is used as a fallback ? | 10:28 |
tiagogomes | gtristan, no, the commid Id in 'ref' must exist, otherwise it will not compile | 10:29 |
tiagogomes | gtristan, how are you checking that the commit ID does not exist? | 10:30 |
gtristan | tiagogomes, using git log, and searching within | 10:30 |
gtristan | perhaps it's on an unmerged branch somewhere ? | 10:31 |
tiagogomes | gtristan try git remote update && git checkout <commit-id> | 10:31 |
SotK | doing git show $SHA suggests the commit does exist to me | 10:31 |
gtristan | tiagogomes, ah indeed, it's somewhere not in mainline... git checkout <ref> does put me in a detached HEAD *somewhere* | 10:32 |
gtristan | SotK, right, that's my bad | 10:32 |
gtristan | now, to figure out... why-the-hell... ;-) | 10:32 |
SotK | unpetrify-ref should point at the branch containing the commit | 10:32 |
Kinnison | gtristan: git describe | 10:32 |
Kinnison | gtristan: should describe where you are :-) | 10:32 |
gtristan | nod, it says 1.0.0 (which is what the unpetrify-ref says), ok I see | 10:33 |
gtristan | so, now to untangle this | 10:33 |
gtristan | 1.0.0 does not install the dbus-org.freedesktop.NetworkManager.service file that the system looks for... few ways to approach the problem | 10:35 |
*** franred has quit IRC | 10:36 | |
gtristan | which is essentially: http://paste.baserock.org/ragiqujafi | 10:36 |
*** gary_perkins has joined #baserock | 10:36 | |
* gtristan thinks a newer NetworkManager is a good try, but then, one has to wonder *why* we have 1.0.0 | 10:37 | |
Kinnison | I think only jjardon can answer that | 10:39 |
* gtristan annotates NetworkManager-common.morph | 10:40 | |
*** zoli__ has joined #baserock | 10:41 | |
gtristan | looks like it was an upgrade from 0.9.10 to 1.0.0 | 10:42 |
* gtristan finds it odd that git branch --list lists no branches in NetworkManager, and that 1.0.0 is a release tag, however does not show up in the git log of master | 10:46 | |
Kinnison | git branch will only list local branches | 10:48 |
Kinnison | git branch -r will show all those on the remote | 10:48 |
Kinnison | tag objects won't show in the history of normal branches | 10:48 |
Kinnison | git is, erm, odd | 10:48 |
Kinnison | :-) | 10:48 |
Kinnison | Once you get used to it, it's quite logical | 10:48 |
Kinnison | but it can take a while | 10:48 |
*** franred has joined #baserock | 10:51 | |
*** zoli__ has quit IRC | 10:54 | |
gtristan | and network-manager is a night-mare of branches :-S | 10:55 |
gtristan | gnome continuous uses 1.1.0-dev-1916-gb1512221bc29f24b86d464dc5117439c366fd299 | 10:55 |
Kinnison | lovely | 10:55 |
*** fay_ has joined #baserock | 11:12 | |
*** gary_perkins has quit IRC | 11:29 | |
*** zoli__ has joined #baserock | 11:32 | |
gtristan | Anyone have an idea of how /etc/pam.d/passwd is installed/created ? | 11:50 |
gtristan | it *could* be only a detail of gnome-system-x86_64, but I suspect it's something else | 11:50 |
gtristan | also, any idea why we have selinux disabled ? | 11:51 |
rjek | That's the only sensible choice :) | 11:51 |
rjek | SELinux is a ploy by the NSA to make it so complicated to get security right, nobody manages. | 11:52 |
gtristan | hmmm, I see, actually it's not really :-S | 11:52 |
Kinnison | gtristan: the pam config stuff is a combination of the pam library, the shadow stuff, systemd, and possibly install-essential-files configuration extension | 11:52 |
gtristan | oddly I find --disable-selinux in places, but the kernel mentions SELinux: Initializing... and other such lines | 11:53 |
gtristan | Kinnison, alright, possibly we need some conditional hack, as gnome-keyring wants an entry in /etc/pam.d/passwd, but of course that's only when building gnome... | 11:54 |
* gtristan finds magick in shadow.morph | 11:56 | |
Kinnison | shadow magicks are dangerous, be prepared | 11:57 |
richard_maw | Kinnison: hmm, summons daemons to ruin your day | 12:00 |
* Kinnison doesn't think there are any shadow daemons | 12:00 | |
* gtristan thinks a decent approach would be to have gnome-keyring add a system-integration hook, to echo "stuff" >> /etc/pam.d/passwd | 12:04 | |
ssam2 | sounds good to me | 12:04 |
Kinnison | Sounds about right, if you verified that it is the right place for it | 12:05 |
jjardon | gtristan: no problem on tracking latest NetworkManager if that fix your proplem | 12:05 |
gtristan | jjardon, I doubt that that problem is blocking the session, but yeah it would be great to know "What is the right NetworkManager to use", the problem is the currently selected one does not install any "dbus-org.freedesktop.NetworkManager.service" file, so gnome-session (and dbus) fails to autostart it | 12:06 |
gtristan | it could be that the "right NetworkManager" also does not install that, and additional tweaking is required anyway, but I think at least "org.freedesktop.NetworkManager.service" should be achiveable | 12:07 |
gtristan | (no idea why it tries 'dbus-org....' | 12:08 |
gtristan | ) | 12:08 |
jjardon | gtristan: right now, the right one is the one you need :) : AFAIK NetworkManager is only used in the GNOME system | 12:09 |
gtristan | jjardon, ummm, there is obviously some version disparity... | 12:12 |
gtristan | jjardon, http://paste.baserock.org/oneroniwuv | 12:12 |
gtristan | jjardon, perhaps gnome-settings-daemon is too new ? | 12:12 |
gtristan | the 1.0.0 release tag installs NetworkManager-common.service... a few service files which dont include any org.freedesktop. prefix at all | 12:14 |
*** zoli___ has joined #baserock | 12:33 | |
*** zoli__ has quit IRC | 12:33 | |
*** zoli___ has quit IRC | 12:38 | |
gtristan | jjardon, it's getting late and I better call it quits... currently I'm trying to get gnome-keyring configured correctly according to https://wiki.gnome.org/Projects/GnomeKeyring/Pam | 12:40 |
gtristan | jjardon, but if you have a moment to look at the journalctl log: http://paste.baserock.org/kevexekesu | 12:41 |
gtristan | maybe you'll spot something I haven't yet | 12:41 |
gtristan | there are a few errors, I am suspecting that keyring is the blocker | 12:42 |
*** fay_ has quit IRC | 12:49 | |
*** gtristan has quit IRC | 12:49 | |
edcragg | anyone ever seen strange console corruption that seems mostly bounded to systemd startup and shutdown? http://paste.baserock.org/etapuvawoq | 13:00 |
*** gary_perkins has joined #baserock | 13:01 | |
edcragg | s/to/by/ | 13:03 |
rjek | Is that via serial? Could be slightly mismatched baud rate? | 13:04 |
Kinnison | systemd thinks your console can colour | 13:05 |
Kinnison | and whatever your terminal thinks, it can't | 13:05 |
rjek | heh | 13:05 |
franred | gtristan: could be related to the missing service/file not found error http://paste.baserock.org/uwozowusax ? | 13:10 |
*** gtristan has joined #baserock | 13:16 | |
edcragg | rjek: yes, serial, not sure, it's perfectly fine everywhere else save systemd start and stop | 13:21 |
robtaylor | edcragg: using screen? | 13:22 |
edcragg | Kinnison: the console does colour, also it's quite intermittent | 13:22 |
edcragg | robtaylor: yes | 13:22 |
robtaylor | edcragg: got two screen instances open on the serial port? | 13:22 |
robtaylor | (i.e. exited a screen rather than closed it) | 13:23 |
robtaylor | (pgrep screen is your friend) | 13:23 |
edcragg | robtaylor: no, only one screen per serial port | 13:24 |
robtaylor | edcragg: intersting¸multiple serial ports? | 13:24 |
edcragg | i have a jetson on one, odroid on another, both usb serial adapters | 13:25 |
robtaylor | edcragg: humour me and unplug one and see if the behaviour continues.. | 13:26 |
robtaylor | (closing down the screen, making sure you have only one screen running) | 13:26 |
robtaylor | it looks very like two serial streams intermuxed, one the wrong serial baud | 13:27 |
edcragg | yeah, but it happens exactly the same each time this board boots | 13:30 |
edcragg | all screens killed, one board unplugged, still happens | 13:31 |
edcragg | and at every point the system is running the console is absolutely fine, with the exception of the places where systemd posts anything to the console | 13:32 |
edcragg | wondering if systemd does anything to reconfigure the console | 13:39 |
robtaylor | very odd indeed | 13:41 |
robtaylor | edcragg: which board? | 13:41 |
edcragg | odroid c1, its a cortex-a5, relatively new SoC | 13:41 |
edcragg | (Amlogic Meson S805) | 13:41 |
robtaylor | hmm | 13:43 |
robtaylor | could it be that it has two serial ports wired to the same pins? | 13:44 |
*** flatmush has joined #baserock | 14:01 | |
perryl | when writing a cluster to set up a trove, what does location refer to? is it the host system that the vm exists on? | 14:02 |
SotK | what deployment extension are you using? | 14:03 |
*** fay_ has joined #baserock | 14:03 | |
perryl | SotK: virtualbox | 14:05 |
Kinnison | virtualbox is a total pig for troves | 14:05 |
Kinnison | because of its abysmal networking | 14:05 |
paulsherwood | s/for troves// | 14:05 |
perryl | hahah i always end up picking the most complex option | 14:05 |
paulsherwood | latest virtualbox doesn't work with baserock default instructions :( | 14:06 |
* perryl debates starting over with kvm | 14:07 | |
SotK | I think that location is something like `$host_ip:/path/to/vm_image` for kvm/virtualbox | 14:07 |
tiredcat | otoh, there may be some value in improving the trove instructions for virtualbox | 14:08 |
paulsherwood | probably, but as i said, i fear vbox is now broken wrt baserock. i showed this to richard_maw and he described it as 'an interesting bug' | 14:10 |
paulsherwood | maybe it's just a mac-specific problem, but i'd be surprised | 14:12 |
SotK | how long has it been broken for? | 14:12 |
paulsherwood | i don't know. i only noticed when i moved to a new machine - previously i'd been on vbox 4.whatever. 5 is broken for for me, and actually crashes the vm | 14:17 |
paulsherwood | (i tried with both my existing vm, and a totally new setup from w.b.o) | 14:18 |
* SotK makes a note not to update vbox at home just yet | 14:19 | |
paulsherwood | :) | 14:20 |
edcragg | robtaylor: thanks for your help, i have a feeling it may have something to do with the mmc driver, i have heard reports that the same thing isn't seen when booting with an initramfs | 14:23 |
robtaylor | edcragg: interesting | 14:27 |
richard_maw | paulsherwood: your disk images were impressively broken from what I could tell | 14:28 |
*** brlogger has joined #baserock | 14:49 | |
*** gary_perkins has quit IRC | 14:50 | |
*** gary_perkins has joined #baserock | 14:52 | |
edcragg | robtaylor: also, currently looking into whether systemd calls ioctls in the serial driver | 14:57 |
robtaylor | edcragg: cool, i guess you can ftrace that pretty easily | 14:58 |
robtaylor | edcragg: actually, you could just ftrace the serial driver full stop | 14:59 |
edcragg | yes, i'll bear that in mind. Added printk shows that systemd calls .set_termios on every line it prints | 15:16 |
edcragg | robtaylor ^ | 15:17 |
robtaylor | edcragg: that shouldn't really cause what you're seeing though | 15:17 |
*** paulwaters_ has quit IRC | 15:47 | |
*** ssam2 has quit IRC | 15:49 | |
paulsherwood | richard_maw: one was a new image. i had same result on my previously created machine, which has continued to function on its host laptop | 15:51 |
*** franred has quit IRC | 15:54 | |
richard_maw | hm, don't know what to suggest then, I don't think it'll be networking related, but it could be something to do with the disk image conversion | 15:55 |
paulsherwood | you mean 'VBoxManage convertdd baserock-current-build-system-x86_64.img baserock.vdi --format VDI' ? | 15:58 |
paulsherwood | it did boot | 15:59 |
richard_maw | yeah, but later on, some time after it booted, we saw the kernel panic related to filesystem acces | 15:59 |
paulsherwood | yup, but that was after it had been booted for a while, and we were trying to diagnose network iirc? | 16:00 |
richard_maw | networking was down because systemd-networkd wasn't started, because dbus failed to start | 16:00 |
richard_maw | and attempting to manually start d-bus caused it to panic | 16:00 |
paulsherwood | ack... which more suggests something in those steps, than filesystem, to me? | 16:01 |
paulsherwood | but maybe i'm wrong | 16:01 |
* richard_maw suspects the filesystem because the kernel panic trace described functions in btrfs | 16:02 | |
paulsherwood | when i get time i can try 4.whatever on this machine... to rule out the host | 16:02 |
*** gary_perkins has quit IRC | 16:10 | |
*** fay_ has quit IRC | 16:25 | |
*** fay_ has joined #baserock | 16:27 | |
paulsherwood | 4.3 exhibits the same behaviour, so must be related to this mac | 16:35 |
*** mariaderidder has quit IRC | 16:38 | |
*** jonathanmaw has quit IRC | 16:50 | |
*** bashrc has quit IRC | 16:58 | |
*** toscalix has quit IRC | 18:59 | |
paulsherwood | richard_maw: amazingly enough... | 19:09 |
paulsherwood | richard_maw: 1 instance: 15-10-05 04:39:20 [278/278/278] [TOTAL] Elapsed time 04:39:20 | 19:09 |
paulsherwood | richard_maw: 2 instances: 0 15-10-07 03:55:08 [195/278/278] [TOTAL] Elapsed time 03:55:08 | 19:10 |
paulsherwood | (ie 2 instances with max-jobs = 4 IS faster than one with max-jobs = 8, for that workload) | 19:11 |
paulsherwood | (devel-system) | 19:11 |
* SotK wonders why the 2 instances version has 195/278 instead of 278/278 | 19:11 | |
paulsherwood | because each instance does some of the steps, but not all | 19:20 |
paulsherwood | http://sprunge.us/GBVG | 19:20 |
paulsherwood | 1 15-10-07 03:55:01 [83/278/278] [TOTAL] Elapsed time 03:55:01 | 19:22 |
SotK | ah, I see | 19:23 |
paulsherwood | this is 15.40 ybd, which has locking so should not race any more. it's *marginally* faster i think | 19:29 |
*** inara` has quit IRC | 19:47 | |
*** inara has joined #baserock | 19:48 | |
*** flatmush has quit IRC | 22:21 | |
*** fay_ has quit IRC | 22:29 | |
*** myself has quit IRC | 23:16 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!