IRC logs for #baserock for Thursday, 2016-04-28

paulsherwoodgtristan: happens all the time, even with instances: 104:22
*** gtristan has quit IRC05:55
*** persia has quit IRC05:59
*** gtristan has joined #baserock06:00
*** persia has joined #baserock06:01
*** CTtpollard has joined #baserock06:08
*** jonathanmaw has joined #baserock06:17
*** jonathanmaw has quit IRC06:34
*** tiagogomes has joined #baserock07:17
*** rdale has joined #baserock07:19
*** ssam2 has joined #baserock07:24
*** ChanServ sets mode: +v ssam207:24
*** ctbruce has joined #baserock07:27
*** edcragg has joined #baserock07:36
*** paulwaters_ has joined #baserock07:42
*** fay_ has joined #baserock07:45
*** jonathanmaw has joined #baserock07:50
*** anahuelamo has joined #baserock08:08
pedroalvarezAfter looking at https://github.com/devcurmudgeon/ybd/issues/213 I believe that is not a bug in the deployment definition08:12
pedroalvarezI'll answer the issue08:12
*** anahuelamo has quit IRC08:13
*** anahuelamo has joined #baserock08:15
edcraggpaulsherwood: i'm integrating manifest generation at build time in ybd as requested. i just realised that ybd will only consider each package in the system if it needs to build it. if some artifacts already exist, when running a partial build, or when restarting a build, not all strata will be considered and you will end up with a partial manifest, which defeats the point. i think the only way to do it a08:21
edcraggccurately is by operating on the final system artifact08:21
edcraggi will implement it in ybd, just at the end of the build08:28
*** anahuelamo has quit IRC08:48
*** anahuelamo has joined #baserock08:48
*** Lachlan1975 has joined #baserock09:28
*** locallycompact has joined #baserock09:34
*** jonathanmaw has quit IRC10:01
*** CTtpollard has quit IRC10:01
paulsherwoodedcragg: i already did it10:27
paulsherwoodsorry10:27
paulsherwoodit needs a bit more work, since i'm sure that .meta and .manifest need to be pretty much the same thing, but for the moment it can generate a manifest for <target> as soon as it's finished the cache-key calculation10:29
paulsherwoodhttps://github.com/devcurmudgeon/ybd/commit/ae5bbfd28a83003d2f87babf7d913ea77a1c828510:30
edcraggpaulsherwood: ok, fair enough, i guess it doesn't infer version numbers from autoconf though as the original script did?10:31
paulsherwoodno... i think i'm philosophically opposed to that10:32
paulsherwoodwhat if autoconf claims a version which is false?10:32
paulsherwoodin my worldview, the only 'version' in general is what git says10:33
rjekWhat if git claims a version which is false? :)10:33
rjekBy version, I mean release numbers, not git hashes.  git hashes aren't very useful for humans.10:33
paulsherwoodrelease numbers can be wrong10:34
pedroalvarezthe world is not for humans, rjek :)10:34
paulsherwoodi for one welcome our new driverless overlords10:34
paulsherwoodrjek: if you mean 'what if our git environment gets compromised', i'm hoping that gitlab + a.n.other git server gives some hope that we'll spot it10:35
paulsherwood(assuming both are setup to reject attempts to re-write history10:36
paulsherwoodedcragg: if you're at a loose end, i could really use some help with https://github.com/devcurmudgeon/ybd/issues/21310:36
* paulsherwood never did understand the deployment code10:37
rjekNo, I'm saying for snap judgements release numbers are much more useful10:38
paulsherwoodhow about, for example: Upstream version 4e42b5b8 glibc-2.21 (glibc-2.21 + 0 commits)10:39
paulsherwood(ie what git says, prettified a bit)10:40
pedroalvarezI think that's what rjek meant, git can be wrong10:40
rjekI think that's acceptable.  I would be weary of "upstream version" if it has been lorried and converted, though!10:40
paulsherwoodif you mean 'wary', ack10:40
rjekerr, yes10:41
edcraggpaulsherwood: i was previously working on sandboxing deployment, depending on which you think is more important10:45
paulsherwoodedcragg: could you consider both together? deployment is currently broken for at least this use-case?10:54
edcraggpaulsherwood: ok10:56
paulsherwoodedcragg: tvm11:18
*** jonathanmaw has joined #baserock11:37
*** CTtpollard has joined #baserock11:40
*** edcragg has quit IRC11:53
*** edcragg has joined #baserock12:19
*** CTtpollard has quit IRC12:50
*** jonathanmaw has quit IRC12:55
*** jonathanmaw has joined #baserock13:13
rjek'The OpenSSL project team would like to announce the forthcoming release of OpenSSL versions 1.0.2h, 1.0.1t.  These releases will be made available on 3rd May 2016 between approximately1200-1500 UTC.  They will fix several security defects with maximum severity "high". '13:56
rjekpedroalvarez: ^13:56
pedroalvarezgreat13:56
pedroalvarezI''m on holidays13:56
rjekwoo13:57
*** locallycompact has quit IRC14:09
*** jonathanmaw has quit IRC14:22
*** jonathanmaw has joined #baserock14:42
*** locallycompact has joined #baserock14:43
*** gtristan has quit IRC15:04
*** tiagogomes has quit IRC15:12
*** ssam2 has quit IRC15:24
*** gtristan has joined #baserock15:29
*** CTtpollard has joined #baserock16:08
*** ctbruce has quit IRC16:20
*** jonathanmaw has quit IRC16:30
*** jonathanmaw has joined #baserock16:47
*** franred has quit IRC17:05
*** anahuelamo has quit IRC17:28
*** CTtpollard has quit IRC17:30
*** edcragg has quit IRC17:38
*** Lachlan1975 has quit IRC17:44
*** jonathanmaw has quit IRC18:09
*** CTtpollard has joined #baserock18:50
*** CTtpollard has quit IRC18:52
*** gtristan has quit IRC19:02
*** gtristan has joined #baserock19:27
*** gtristan has quit IRC20:20
*** edcragg has joined #baserock20:31
*** rdale has quit IRC20:40
*** gtristan has joined #baserock20:43
*** gtristan has quit IRC20:58
*** gtristan has joined #baserock20:58
*** edcragg has quit IRC21:04
*** tiagogomes has joined #baserock21:45
*** tiagogomes has quit IRC22:13
*** gtristan has quit IRC22:25
*** gtristan has joined #baserock22:26
*** edcragg has joined #baserock22:33
*** edcragg has quit IRC23:08
*** edcragg has joined #baserock23:24
*** edcragg has quit IRC23:48

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