IRC logs for #baserock for Wednesday, 2015-10-07

*** gtristan has quit IRC05:32
*** gtristan has joined #baserock05:46
gtristanjjardon, looks good to me, I dont know how to 'review' it though :)05:56
gtristantheres a suspicious "add reviewers" button which brings up an entry... enter comments in the entry ?05:56
gtristanI am curious however... how do you deal with building stable ?05:57
gtristanjust keep stable branches of definitions repo ?05:57
*** paulwaters_ has joined #baserock06:33
gtristanjjardon, 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 support07:04
*** ssam2 has joined #baserock07:10
*** ChanServ sets mode: +v ssam207:10
gtristanjjardon, ah I see you have a 'task' for that on storyboard which is marked in-progress07:17
gtristanI'm quite sure that moving those commands to 'system-integration' is the right fix07:18
gtristanI asked this before to the channel... but was mixed with a dozen other questions07:18
gtristanany thoughts on --sysconfdir=/etc all across the board ?07:19
gtristanor, at least for packages which do not specify a specific .morph (default autotools)07:19
ssam2oh, that would make sense07:19
* gtristan finds himself creating .morph files for packages... only because they dont specify that07:20
gtristanthere are some exceptions, for instance openssh wants sysconfdir to be /etc/ssh07:20
ssam2only gotcha is that until we move to definitions format version 7, it's a bit of a pain to change the defaults07:20
ssam2because they live in the build tools instead of in definitions.git at the moment07:21
gtristanI see07:21
ssam2once 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 though07:22
gtristanhmmm... so I will keep working around this for now...07:22
gtristanI'll open a 'story' for it07:22
ssam2good idea07:22
gtristanfiled as https://storyboard.baserock.org/#!/story/5807:27
*** franred has joined #baserock07:37
*** toscalix__ has joined #baserock07:57
*** bashrc has joined #baserock08:04
*** mariaderidder has joined #baserock08:05
jjardonhi gtristan : to review, go to the change in gerrit, press, the 'Replay' button and choose +1/-108:23
jjardongtristan: to checkout the branch to review: git review -d <change number>08:24
gtristangotcha :)08:25
gtristanjjardon, 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
gtristans/the modules/the loaders file08:28
*** gary_perkins has quit IRC08:34
*** gary_perkins has joined #baserock08:38
*** mariaderidder has quit IRC09:02
*** paulwaters_ has quit IRC09:04
*** toscalix__ is now known as toscalix09:05
*** paulwaters_ has joined #baserock09:05
*** gary_perkins has quit IRC09:12
*** edcragg has joined #baserock09:12
*** jonathanmaw has joined #baserock09:15
*** mariaderidder has joined #baserock09:16
paulsherwoodpedroalvarez: 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 time10:14
*** Phlogistique has joined #baserock10:15
gtristanaherm.... so the ref: in the morph is supposed to be a commit id...10:26
gtristanBut NetworkManager-common.morph... refers to a commit ID which does not exist in the NetworkManager repository10:27
gtristan(either in upstream freedesktop git, or in the lorry git)10:27
gtristanjust 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
tiagogomesgtristan,  no, the commid Id in 'ref' must exist, otherwise it will not compile10:29
tiagogomesgtristan, how are you checking that the commit ID does not exist?10:30
gtristantiagogomes, using git log, and searching within10:30
gtristanperhaps it's on an unmerged branch somewhere ?10:31
tiagogomesgtristan  try git remote update && git checkout <commit-id>10:31
SotKdoing git show $SHA suggests the commit does exist to me10:31
gtristantiagogomes, ah indeed, it's somewhere not in mainline... git checkout <ref> does put me in a detached HEAD *somewhere*10:32
gtristanSotK, right, that's my bad10:32
gtristannow, to figure out... why-the-hell... ;-)10:32
SotKunpetrify-ref should point at the branch containing the commit10:32
Kinnisongtristan: git describe10:32
Kinnisongtristan: should describe where you are :-)10:32
gtristannod, it says 1.0.0 (which is what the unpetrify-ref says), ok I see10:33
gtristanso, now to untangle this10:33
gtristan1.0.0 does not install the dbus-org.freedesktop.NetworkManager.service file that the system looks for... few ways to approach the problem10:35
*** franred has quit IRC10:36
gtristanwhich is essentially: http://paste.baserock.org/ragiqujafi10:36
*** gary_perkins has joined #baserock10:36
* gtristan thinks a newer NetworkManager is a good try, but then, one has to wonder *why* we have 1.0.010:37
KinnisonI think only jjardon can answer that10:39
* gtristan annotates NetworkManager-common.morph10:40
*** zoli__ has joined #baserock10:41
gtristanlooks like it was an upgrade from 0.9.10 to 1.0.010: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 master10:46
Kinnisongit branch will only list local branches10:48
Kinnisongit branch -r will show all those on the remote10:48
Kinnisontag objects won't show in the history of normal branches10:48
Kinnisongit is, erm, odd10:48
Kinnison:-)10:48
KinnisonOnce you get used to it, it's quite logical10:48
Kinnisonbut it can take a while10:48
*** franred has joined #baserock10:51
*** zoli__ has quit IRC10:54
gtristanand network-manager is a night-mare of branches :-S10:55
gtristangnome continuous uses 1.1.0-dev-1916-gb1512221bc29f24b86d464dc5117439c366fd29910:55
Kinnisonlovely10:55
*** fay_ has joined #baserock11:12
*** gary_perkins has quit IRC11:29
*** zoli__ has joined #baserock11:32
gtristanAnyone have an idea of how /etc/pam.d/passwd is installed/created ?11:50
gtristanit *could* be only a detail of gnome-system-x86_64, but I suspect it's something else11:50
gtristanalso, any idea why we have selinux disabled ?11:51
rjekThat's the only sensible choice :)11:51
rjekSELinux is a ploy by the NSA to make it so complicated to get security right, nobody manages.11:52
gtristanhmmm, I see, actually it's not really :-S11:52
Kinnisongtristan: the pam config stuff is a combination of the pam library, the shadow stuff, systemd, and possibly install-essential-files configuration extension11:52
gtristanoddly I find --disable-selinux in places, but the kernel mentions SELinux: Initializing... and other such lines11:53
gtristanKinnison, 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.morph11:56
Kinnisonshadow magicks are dangerous, be prepared11:57
richard_mawKinnison: hmm, summons daemons to ruin your day12:00
* Kinnison doesn't think there are any shadow daemons12:00
* gtristan thinks a decent approach would be to have gnome-keyring add a system-integration hook, to echo "stuff" >> /etc/pam.d/passwd12:04
ssam2sounds good to me12:04
KinnisonSounds about right, if you verified that it is the right place for it12:05
jjardongtristan: no problem on tracking latest NetworkManager if that fix your proplem12:05
gtristanjjardon, 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 it12:06
gtristanit 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 achiveable12:07
gtristan(no idea why it tries 'dbus-org....'12:08
gtristan)12:08
jjardongtristan: right now, the right one is the one you need :) : AFAIK NetworkManager is only used in the GNOME system12:09
gtristanjjardon, ummm, there is obviously some version disparity...12:12
gtristanjjardon, http://paste.baserock.org/oneroniwuv12:12
gtristanjjardon, perhaps gnome-settings-daemon is too new ?12:12
gtristanthe 1.0.0 release tag installs NetworkManager-common.service... a few service files which dont include any org.freedesktop. prefix at all12:14
*** zoli___ has joined #baserock12:33
*** zoli__ has quit IRC12:33
*** zoli___ has quit IRC12:38
gtristanjjardon, 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/Pam12:40
gtristanjjardon, but if you have a moment to look at the journalctl log: http://paste.baserock.org/kevexekesu12:41
gtristanmaybe you'll spot something I haven't yet12:41
gtristanthere are a few errors, I am suspecting that keyring is the blocker12:42
*** fay_ has quit IRC12:49
*** gtristan has quit IRC12:49
edcragganyone ever seen strange console corruption that seems mostly bounded to systemd startup and shutdown? http://paste.baserock.org/etapuvawoq13:00
*** gary_perkins has joined #baserock13:01
edcraggs/to/by/13:03
rjekIs that via serial?  Could be slightly mismatched baud rate?13:04
Kinnisonsystemd thinks your console can colour13:05
Kinnisonand whatever your terminal thinks, it can't13:05
rjekheh13:05
franredgtristan: could be related to the missing service/file not found error http://paste.baserock.org/uwozowusax ?13:10
*** gtristan has joined #baserock13:16
edcraggrjek: yes, serial, not sure, it's perfectly fine everywhere else save systemd start and stop13:21
robtayloredcragg: using screen?13:22
edcraggKinnison: the console does colour, also it's quite intermittent13:22
edcraggrobtaylor: yes13:22
robtayloredcragg: 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
edcraggrobtaylor: no, only one screen per serial port13:24
robtayloredcragg: intersting¸multiple serial ports?13:24
edcraggi have a jetson on one, odroid on another, both usb serial adapters13:25
robtayloredcragg: 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
robtaylorit looks very like two serial streams intermuxed, one the wrong serial baud13:27
edcraggyeah, but it happens exactly the same each time this board boots13:30
edcraggall screens killed, one board unplugged, still happens13:31
edcraggand at every point the system is running the console is absolutely fine, with the exception of the places where systemd posts anything to the console13:32
edcraggwondering if systemd does anything to reconfigure the console13:39
robtaylorvery odd indeed13:41
robtayloredcragg: which board?13:41
edcraggodroid c1, its a cortex-a5, relatively new SoC13:41
edcragg(Amlogic Meson S805)13:41
robtaylorhmm13:43
robtaylorcould it be that it has two serial ports wired to the same pins?13:44
*** flatmush has joined #baserock14:01
perrylwhen 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
SotKwhat deployment extension are you using?14:03
*** fay_ has joined #baserock14:03
perrylSotK: virtualbox14:05
Kinnisonvirtualbox is a total pig for troves14:05
Kinnisonbecause of its abysmal networking14:05
paulsherwoods/for troves//14:05
perrylhahah i always end up picking the most complex option14:05
paulsherwoodlatest virtualbox doesn't work with baserock default instructions :(14:06
* perryl debates starting over with kvm14:07
SotKI think that location is something like `$host_ip:/path/to/vm_image` for kvm/virtualbox14:07
tiredcatotoh, there may be some value in improving the trove instructions for virtualbox14:08
paulsherwoodprobably, 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
paulsherwoodmaybe it's just a mac-specific problem, but i'd be surprised14:12
SotKhow long has it been broken for?14:12
paulsherwoodi 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 vm14: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 yet14:19
paulsherwood:)14:20
edcraggrobtaylor: 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 initramfs14:23
robtayloredcragg: interesting14:27
richard_mawpaulsherwood: your disk images were impressively broken from what I could tell14:28
*** brlogger has joined #baserock14:49
*** gary_perkins has quit IRC14:50
*** gary_perkins has joined #baserock14:52
edcraggrobtaylor: also, currently looking into whether systemd calls ioctls in the serial driver14:57
robtayloredcragg: cool, i guess you can ftrace that pretty easily14:58
robtayloredcragg: actually, you could just ftrace the serial driver full stop14:59
edcraggyes, i'll bear that in mind. Added printk shows that systemd calls .set_termios on every line it prints15:16
edcraggrobtaylor ^15:17
robtayloredcragg: that shouldn't really cause what you're seeing though15:17
*** paulwaters_ has quit IRC15:47
*** ssam2 has quit IRC15:49
paulsherwoodrichard_maw: one was a new image. i had same result on my previously created machine, which has continued to function on its host laptop15:51
*** franred has quit IRC15:54
richard_mawhm, 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 conversion15:55
paulsherwoodyou mean 'VBoxManage convertdd baserock-current-build-system-x86_64.img baserock.vdi --format VDI' ?15:58
paulsherwoodit did boot15:59
richard_mawyeah, but later on, some time after it booted, we saw the kernel panic related to filesystem acces15:59
paulsherwoodyup, but that was after it had been booted for a while, and we were trying to diagnose network iirc?16:00
richard_mawnetworking was down because systemd-networkd wasn't started, because dbus failed to start16:00
richard_mawand attempting to manually start d-bus caused it to panic16:00
paulsherwoodack... which more suggests something in those steps, than filesystem, to me?16:01
paulsherwoodbut maybe i'm wrong16:01
* richard_maw suspects the filesystem because the kernel panic trace described functions in btrfs16:02
paulsherwoodwhen i get time i can try 4.whatever on this machine... to rule out the host16:02
*** gary_perkins has quit IRC16:10
*** fay_ has quit IRC16:25
*** fay_ has joined #baserock16:27
paulsherwood4.3 exhibits the same behaviour, so must be related to this mac16:35
*** mariaderidder has quit IRC16:38
*** jonathanmaw has quit IRC16:50
*** bashrc has quit IRC16:58
*** toscalix has quit IRC18:59
paulsherwoodrichard_maw: amazingly enough...19:09
paulsherwoodrichard_maw: 1 instance: 15-10-05 04:39:20 [278/278/278] [TOTAL] Elapsed time 04:39:2019:09
paulsherwoodrichard_maw: 2 instances: 0 15-10-07 03:55:08 [195/278/278] [TOTAL] Elapsed time 03:55:0819: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/27819:11
paulsherwoodbecause each instance does some of the steps, but not all19:20
paulsherwoodhttp://sprunge.us/GBVG19:20
paulsherwood1 15-10-07 03:55:01 [83/278/278] [TOTAL] Elapsed time 03:55:0119:22
SotKah, I see19:23
paulsherwoodthis is 15.40 ybd, which has locking so should not race any more. it's *marginally* faster i think19:29
*** inara` has quit IRC19:47
*** inara has joined #baserock19:48
*** flatmush has quit IRC22:21
*** fay_ has quit IRC22:29
*** myself has quit IRC23:16

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