IRC logs for #baserock for Friday, 2015-05-15

*** zoli__ has joined #baserock04:59
*** petefoth has quit IRC07:19
*** a1exhughe5 has joined #baserock07:25
*** perryl has joined #baserock07:25
*** jmacs has joined #baserock08:00
*** bashrc has joined #baserock08:05
*** jonathanmaw has joined #baserock08:12
*** Albert has joined #baserock08:15
*** mariaderidder has joined #baserock08:15
*** Albert has joined #baserock08:15
*** mwilliams_ct has joined #baserock08:17
*** mwilliams_ct has quit IRC08:18
*** gary_perkins has joined #baserock08:18
*** gary_perkins has joined #baserock08:18
*** benbrown_ has joined #baserock08:21
*** mwilliams_ct has joined #baserock08:23
*** DavePage has joined #baserock08:27
*** kejiahu has joined #baserock08:33
*** paulw has quit IRC08:58
*** paulw has joined #baserock08:58
*** inara has quit IRC08:59
tlsais there any way to get the default commands for a chunk type to run in a subdirectory of the build dir?  doing `cd foo/` at pre-configure did not work08:59
jonathanmawtlsa: not that I know of. I think we do the commands as `cd foo && $COMMAND`09:00
*** ssam2 has joined #baserock09:02
*** ChanServ sets mode: +v ssam209:02
*** inara has joined #baserock09:09
SotKDoes anyone have a minute to review ?09:13
*** zarazaimeche has joined #baserock09:15
*** zarazaimeche is now known as Zara09:15
*** pdar has joined #baserock09:16
richard_mawSotK: ouch, +209:19
SotKrichard_maw: thanks09:20
*** mdunford has joined #baserock09:39
jjardonssam2: hi, radiofree commented yesterday that you have started some work to strip symbols from an image; is that public somewhere? My problem is that I'm not able to do a baserock image smaller than 33MB (32 is the maximum the hardware support)09:47
*** bashrc has quit IRC09:47
*** bashrc has joined #baserock09:47
radiofreejjardon: i said i *think* sam had09:48
radiofreethough i didn't say that... [17:50:43] <radiofree> jjardon: i think sam was09:48
pedroalvarezjjardon: IIRC you are adding core to the system, right?09:52
pedroalvarezcould you try to not add it?09:52
jjardonradiofree: ok, yeah sorry09:52
jjardonpedroalvarez: I'm not, its the minimal you can create09:52
pedroalvarezah, ok09:53
ssam2jjardon: all I've ever done on that front is a hacky .configure extension that runs 'strip' on a bunch of files at deploy time09:54
ssam2that's probably lost now, but it's easy enough to write09:54
ssam2it's not a good approach for a few reasons: one is that 'strip' only works if the system you're deploying is the same architecture as the system running `morph deploy`09:55
ssam2but it is super easy to do :)09:55
jjardonOK, i was about to ask if a correct approach would be to write an extension :)09:59
pedroalvarezcouldn't that be run at system-integration time?10:00
pedroalvarezI guess we can't remove things at that point10:01
richard_mawpedroalvarez: you don't need to remove the binaries themselves, just change them10:01
ssam2adding a 'strip-everything' chunk with just system-integration commands might be a slightly better hack, indeed10:02
radiofreewould anyone object to a patch adding systemd units to essential-files that automatically start a dbus user session?10:03
richard_mawthough IMO the best approach would be to do it at artifact construction time10:03
radiofreeor do we have systems that either don't have systemd or dbus (or both)?10:03
richard_mawradiofree: aye, the initramfs10:03
tiagogomesheh, the current version of git doesn't need `--no-index` to work outside git directories :)10:03
radiofreerichard_maw: ah, does that use essential files then?10:03
radiofreeso the best place for this is in the dbus chunk?10:03
rdale_openwrt that i'm working on, doesn't have dbus or systemd10:04
KinnisonJeff Waugh recently got systemd into openwrt and working IIRC10:04
richard_mawit does not use the essential-files configuration extension10:04
rdale_Kinnison: ah interesting10:04
radiofreeso if it goes in the dbus chunk you might use dbus but not systemd, however the worst that can happen is you end up installing some useless service files10:05
radiofreewhich i suppose is the same worst case scenario for essential files, though you might not be using systemd *or* dbus for them10:06
ssam2I think that 'essential-files' should be a 'best guess'. i.e. a default set of files everyone needs by default10:09
ssam2a super minimal system should probably not include the install-essential-files.configure extension, but do its own minimal thing instead10:09
richard_mawso… it's actually tied to whether you deicde to use the foundation stratum in your system?10:10
ssam2not really. But given that people are working towards making it possible to boot a system with absolutely nothing in /etc, I don't think the stuff in essential-files/ is essential for a /working/ system10:11
ssam2it's essential for a /usable/ system10:11
ssam2that doesn't really answer radiofree's question though of course10:12
radiofreei prefer things like this in essential files, it means you don't have to rebuild from foundation if you just want to change something in a systemd service file10:12
radiofreebut then i don't know if a dbus user session is *essential* for most of the things that baserock does10:13
ssam2on the other hand, the impact is minimal10:13
ssam2like < 1KB of wasted space if they are unneeded10:13
pedroalvarezbut it's going to be annoying if we use essential-files for everything10:13
ssam2how so?10:14
ssam2I imagine it basically as a 'generally useful set of files to go in /etc'10:14
ssam2(and/or /usr/lib/ since that is taking over from /etc a bit)10:15
pedroalvareznot sure about what to think, really10:18
* radiofree will just then the patches10:22
* straycat will merge shortly if there are further comments10:24
straycatrichard_maw, ssam2 ^10:24
straycat*are no :)10:24
*** locallycompact has joined #baserock10:32
radiofree is about as sensible a patch as it gets, could do with a merge10:32
Kinnisonis that safe acros all platforms?10:33
radiofreeyep, we use mesa-vm for x8610:34
Kinnisonand MIPS?10:34
KinnisonOr do we not compile mesa yet for MIPS?10:34
radiofreeoh god mips, mips needs to use mesa-vm10:34
radiofreenowster: ^10:35
nowstermesa does compile, but we have to turn a lot off10:35
radiofreeyes, but you have to use mesa-vm for mips now10:35
Kinnisonnowster: please weigh in on then10:36
radiofreethat version of mesa won't work on mips anyway10:36
nowsterI don't really know what the consequence would be. Surely egl is needed for weston/wayland?10:36
radiofreeit's just removing a useless configuration option10:36
* Kinnison adds his +1 then10:37
radiofreenowster: if you're modifying mesa for mips, you'll need to lock it at f7d157a4f011fd5ace94f55c8674be4b12d86f9510:37
radiofreenowster: if you see
radiofreeyou can still build against mesa-common (so you don't have to branch loads of -mips stratum), just use mesa-common-vm (or mesa-common-mips) as a runtime dependency10:38
nowsterthe change for mips is to add:10:38
nowster  mips* )10:38
nowster    DRIDRIVERS=no10:38
nowster    GALLIUMDRIVERS=svga,swrast10:38
nowster    ;;10:38
nowsterto the configure-commands10:38
radiofreenowster: add that to then10:39
radiofreerather than mesa.morph10:39
nowsterYou need it on both10:39
pedroalvarezshould we name it mesa@egl?10:39
radiofreepedroalvarez: mesa@gallium-egl is probably clearer10:39
radiofreeand +1 to rename10:39
nowsterah.... You fight it out, and I'll just rebase the mips stuff. :)10:39
radiofreenowster: you will, since mesa-common is a build time dependency10:40
jjardonradiofree: we can remove -vm variant soon, they reimplement support to use swrast in the upcomming 10.610:40
jjardonpatches are in master already:
radiofreejjardon: ?10:41
* straycat is surprised and are still in review given how trivial they are10:42
jjardonstraycat: what those files are for, and why right now are not needed? (Maybe you can add a little explanation in the commit message for future reference)10:43
straycatthose files are git-review config files10:44
ssam2straycat: thanks for the heads up, i've commented10:46
straycat( probably explains better than i can )10:46
Kinnisonstraycat: both have at least 2 +1s so I imagine they're just waiting on someone to +2 them10:46
*** paulsherwood has joined #baserock10:47
*** paulsher1ood has joined #baserock10:49
straycatKinnison, yes11:20
straycatssam2, biff11:25
straycatrichard_maw, I will merge shortly unless there are further comments11:25
*** paulsher2ood has joined #baserock11:38
*** mariaderidder has quit IRC11:41
SotKtlsa: biff on the pelican lorries11:48
*** Albert has quit IRC11:53
*** Albert has joined #baserock11:53
tlsaSotK: ta, replied11:53
* SotK tries to figure out where the gerrit system definition lives nowadays12:08
franredSotK, I think is in
franredthe system in definitions was no longer supported so it was removed12:09
franredSotK, see f7b84cf169df9e4fa4371e4181b18ddbdd8c8430 for more info12:10
SotKfranred: thanks!12:10
pedroalvarezSotK: master of infrastructure.git I believe12:23
*** Albert has quit IRC12:24
*** Albert has joined #baserock12:25
*** mariaderidder has joined #baserock12:57
*** benbrown_ has quit IRC13:43
radiofreeso i haven't rebased a branch i built yesterday, and i haven't deleted my cache or anything, but now morph wants to rebuild from stage1-gcc13:46
SotKhave you changed morph?13:46
radiofreehold on let me build the same system i built the other day13:46
radiofreethis is probably my fault13:47
radiofreei've totally buggered this up, never mind, i'll rebuild13:48
*** mdunford has quit IRC13:59
* richard_maw is saddened that overlayfs is better at handling mounts options than btrfs14:09
richard_mawoverlayfs properly handles file paths potentially containing commas, not so btrfs' subvol= option14:11
*** mdunford has joined #baserock14:17
* richard_maw just performed a live atomic update with systemd!14:22
richard_mawDeployed an update with ssh-rsync, rather than rebooting I altered my live-atomic-update script to ask systemctl to use a new `upgrade-root` verb which I added locally. issued a `systemctl restart openssh.service` and then issued a `systemctl restart *.service` after I was sure it was ok.14:26
richard_mawnow system-version-manager lists my new version as both the default and the currently running version14:26
richard_mawradiofree: Weren't you talking about adding dbus units for user sessions earlier?14:30
* richard_maw was just pointed at when reading the systemd log14:30
richard_maws/log$/mailing list/14:31
radiofreei sent
radiofreei sent
SotKssam2: thanks for the reviews!14:34
radiofreejonathanmaw: did the work though14:34
pedroalvarezHi, I found (creating some lorries for other xstatic components) that we are not lorrying them from upstream14:57
pedroalvarezwe are lorrying (as far as I can understand) from the openstack "mirror" of them14:57
richard_mawI thought the xstatic thing was because openstack were forcefully integrating non-python components into pip14:58
richard_mawfranred: ^14:58
pedroalvarez"mirror" because they don't have the full history14:58
franredrichard_maw, that is true.14:59
franredpedroalvarez, I though the xstatic openstack repos were the same as the xstatic in github - at least when I saw them14:59
pedroalvarezfor example, xstatic-font-aweome, is in pypi, pointing to, but we lorry from
pedroalvarezA better example:
pedroalvarezit doesn't have even tags15:01
pedroalvarezthe upstream one has 3.400 commits :/15:01
pedroalvarezI don't know what to do :/15:02
richard_mawI think I'll submit a few more "bugfix" patches to systemd before I attempt to send baserock/richardmaw/wip-upgrade-root as an RFC. Partly because I may also have to have systemd enter a new mount namespace on upgrade, so the existing services may keep using the old mounts until htey are restarted…15:02
franredpedroalvarez, but fontawesome is the full repo... xstatic only have the static compiled files15:04
franredrequired by horizon to work15:04
franredwith a python installer to install these files15:04
franredpedroalvarez, ^^15:04
pedroalvarezthis is confusing15:04
*** Albert has quit IRC15:05
*** mdunford has quit IRC15:05
pedroalvarezconfusing because pypi call them xstatic-foo, but then they link to foo only15:05
pedroalvarezto foo projects only15:05
pedroalvarezhm.. I need to lorry a new one that isn't in openstack.git15:06
*** mdunford has joined #baserock15:07
pedroalvarezI guess that they include them to opesntack git server whenever they want to make changes to it15:08
*** jmacs has quit IRC15:24
ssam2wow, implies something that I like15:27
ssam2'all concurrent logins by the same user form one large session.15:28
ssam2This allows the same bus to be shared by a graphical session, cron jobs,15:28
ssam2tty/ssh sessions, screen/tmux sessions and so on'15:28
KinnisonYes, the user-session model15:28
KinnisonIt's quite interesting as an option15:28
* richard_maw grumbles that a7aea3c4d98472721d05d4cae9f453a410062cbf didn't include making everything that previously included tools include coreutils15:31
richard_mawjjardon: do you remember why we didn't add coreutils-comon to all systems that previously included tools when ^ was merged?15:34
jjardonrichard_maw: GPL315:34
*** sambishop has quit IRC15:34
radiofreerichard_maw: thanks for the review, i'll try new dbus15:35
richard_mawjjardon: and we need a sufficiently modern coreutils to build systemd, so we had to use a GPL3 version?15:35
jjardonrichard_maw: not in runtime, because we do not include coreutils in the system definition15:36
richard_mawjjardon: I'm aware of that, I was just asking for confirmation as to why we weren't instead using an older version and including it in all systems15:37
richard_mawI think it would be appropriate to add coreutils to all devel systems15:38
jjardonrichard_maw: yeah, I remember to have problems building stuff with busybox utils / old versions of coreutils15:39
jjardonrichard_maw: sure, go for it. Its really only artifically splitted because the genivi systems15:40
jjardonSorry, not sure I understand this stuff correctly; Is this the correct thing to do If I want to keep the "strip" binary (which belongs to binutils) ?
*** a1exhughe5 has quit IRC15:45
pedroalvarezhm.. that is going to make your system bigger15:45
pedroalvarezbinutils is around 90M15:47
pedroalvarezI guess my idea of running it as a system integration command is not good enough15:47
richard_mawjjardon: that's one way to do it15:47
richard_mawyou could also do an explicit assignment of binutils-foo: build-essential-minimal in the binutils chunk entry15:47
richard_mawjjardon: if it's just for the minimal system that you need it for now, I'd suggest just adding the command to do the strip in the libc and busybox chunk morphologies15:50
*** tpollard_ has quit IRC15:52
jjardonrichard_maw: rigth, you mean something like this?
ratmice__there is also elfutils eu-strip16:02
jjardonratmice__: nice, unfortunately we do not seem to have elfutils in baserock at the moment16:03
*** zoli__ has quit IRC16:12
*** mariaderidder has quit IRC16:28
richard_mawjjardon: that sort of thing, yes16:45
jjardonmmm, would it be ok to move perl out of core? I have to rebuild the whole core stratum because the bsp depends on core because perl16:55
Kinnisonperl is needed deeply because it's a b-dep of automake etc16:56
Kinnisonalso needed to configure openssl16:57
Kinnisonand friends16:57
*** jonathanmaw has quit IRC16:57
jjardonKinnison: sure, maybe you can make core depend on perl?16:58
Kinnisonjjardon: It's going to complicate matters I fear16:58
Kinnisonjjardon: *anything* which needs to run automake during its build will need perl16:58
*** bashrc has quit IRC17:00
jjardonKinnison: yes, but nothing will change in those cases: if you depend on core because automake, you will implicitly depend on perl17:00
Kinnisonwhich strata currently build-depend on core but not perl?17:01
*** franred has quit IRC17:01
pedroalvarezOpenStack Kilo in baserock begins:
jjardonKinnison: I mean, if your stratum depend in core, and you move perl to another stratum and make core depend on it, your stratum will keep depending on core and perl, no change needed (AFAIK)17:03
Kinnisonand core will have to rebuild because of perl17:04
KinnisonI'm not seeing how you gain anything but complexity17:04
*** mdunford has quit IRC17:06
jjardonKinnison: Instead rebuilding my bsp if any of the components of core changes, I will only rebuild if perl changes17:06
KinnisonI see17:07
jjardon(note that for minimal systems, core is not included in the final system, Its only needed to build the kernel)17:07
jjardonbecause perl17:07
KinnisonYou'd need to pull gdbm out too17:08
Kinnisonand ensure that every system which contains core contains your perl stratum17:08
Kinnisonthen it might be plausible17:08
KinnisonThough I am worried that we're going to end up with so many microstrata that we'll have package-explosion17:08
tiagogomeserm, is the cache server working? I am building btrfs-utils17:10
jjardonyeah, me too. That's why I ask to see if you folks think its worth or not :)17:10
Kinnisonjjardon: Right now I'd not -1 it -- put it that way :)17:11
pedroalvarezI think the problem is not cache.baserock.org17:16
pedroalvarezis Mason, stuck building17:16
pedroalvarezseems like we have  a weird bug in distbuild17:16
SotKpedroalvarez: oh?17:16
pedroalvarezSotK: hm... yeah.. I've been hitting the same problem on another mason17:17
pedroalvarez(local one)17:17
SotKdo you have a log you can paste somewhere?17:17
pedroalvarezdistbuild logs...17:17
pedroalvarezI can have 1G of logs17:17
jjardonBTW, seems we stop lorrying the perl repo, last commit from 2012: compare:
pedroalvarezSotK: I cand send you the latest logs if you want17:20
SotKpedroalvarez: yes please :)17:20
pedroalvarezsigh, I don't know how17:20
pedroalvarezmason is internet isolated :)17:20
SotKoh yeah :/17:22
pedroalvarezyay, i've got them17:22
*** paulsher3ood has joined #baserock17:24
*** locallycompact has quit IRC17:27
* SotK anticipates17:27
pedroalvarezSotK: sent them to you, sorry for the 8M file attachment17:28
SotKpedroalvarez: thanks17:30
pedroalvarezSotK: thank you for swimming on those logs17:31
SotKlooks like it didn't queue anything new to build after fhs-dirs17:34
SotKthat makes no sense17:35
*** tiagogomes has quit IRC17:36
* SotK will look in more detail later, I need ot head off now17:36
*** gary_perkins has quit IRC17:45
*** zoli__ has joined #baserock17:49
* paulsher3ood is become many17:57
* paulsher3ood apologises for having mutiple nicks17:58
*** ssam2 has quit IRC18:01
*** paulsherwood has quit IRC18:38
*** zoli__ has quit IRC19:00
jjardonmmm, I manage to strip /lib/* with strip --strip-debug /lib/* , but unfortunatelly the resulting image is bigger than before (probably because we have to include binutils, as pedroalvarez  said)20:00
jjardonI tried to strip /usr/bin or /usr/lib, but the strip fails with "unable to copy file '/usr/bin/yes'; reason: Text file busy" and "strip:/usr/lib/ File format not recognized" respectively, and the integration command fails20:01
jjardonDoes anyone know if its possible to ignore the result of the command, so the integration comamnd doesnt fail even if strip is not able to strip some of the files?20:02
*** paulsher3ood has quit IRC20:27
*** paulsher2ood has quit IRC20:30
*** paulsher1ood has quit IRC20:31
*** rdale_ has quit IRC20:32
*** zoli__ has joined #baserock20:33
*** paulsherwood has joined #baserock20:35
*** zoli__ has quit IRC23:05
*** zoli__ has joined #baserock23:38

Generated by 2.15.3 by Marius Gedminas - find it at!