IRC logs for #baserock for Thursday, 2015-11-05

*** edcragg has quit IRC00:06
*** JPohlmann has quit IRC00:31
*** JPohlmann has joined #baserock00:32
*** JPohlmann has joined #baserock00:32
*** edcragg has joined #baserock00:34
*** edcragg has quit IRC00:48
*** edcragg has joined #baserock01:03
*** edcragg has quit IRC01:07
*** Lunar^ has quit IRC03:03
*** Lunar^ has joined #baserock03:03
*** gtristan has quit IRC04:40
*** gtristan has joined #baserock05:10
*** paulwaters_ has quit IRC08:38
*** bashrc has joined #baserock09:00
*** ctbruce has joined #baserock09:02
*** jonathanmaw has joined #baserock09:21
*** Lunar^ has quit IRC09:24
*** Lunar^ has joined #baserock09:26
*** ctbruce has quit IRC09:27
*** toscalix__ has joined #baserock09:30
*** ctbruce has joined #baserock09:37
*** paulwaters_ has joined #baserock09:39
*** mariaderidder has joined #baserock09:39
*** toscalix__ has quit IRC09:40
*** paulwaters_ has quit IRC09:41
*** toscalix__ has joined #baserock09:44
*** toscalix__ has quit IRC09:45
*** toscalix__ has joined #baserock09:45
*** nowster has joined #baserock09:46
*** paulwaters_ has joined #baserock09:48
*** CTtpollard has quit IRC10:03
*** ssam2 has joined #baserock10:04
*** ChanServ sets mode: +v ssam210:04
*** CTtpollard has joined #baserock10:04
tiagogomesmorning, am I right to believe that the morph in the latest release of baserock can't build version 7 of definitions?10:09
*** gary_perkins has quit IRC10:10
*** gary_perkins has joined #baserock10:14
*** edcragg has joined #baserock10:17
pedroalvarezyou are right10:18
pedroalvarezthat's why we haven't migrated our definitions to version 710:19
gtristanany idea how to invoke gettextize --stfu ?10:23
gtristanthe --force option still says "Press enter to acknowledge the above paragraphs" and tries to read a tty10:23
gtristanmaybe: echo "" | gettextize --force10:25
persiaor `gettextize --force <<< "¥n"`10:26
* pedroalvarez sees threads in google about the same thing10:27
pedroalvarezread dummy < /dev/tty10:27
persiagtristan: Maybe use autopoint instead?10:29
pedroalvarezI was going to suggest the same10:29
* gtristan is following libexif's README10:30
gtristanlets see, maybe autopoint... /me not sure what to put there10:30
persia`autopoint --force` probably achieves what you want without the annoyance.10:30
* gtristan tries that... fwiw the README says: http://paste.baserock.org/widenuruso10:32
gtristanthe second part "probably just", well... doesnt work :)10:32
persiaheh10:36
gtristanyeah that doesnt work, for the same error that autoreconf doesnt, I'll figure it out10:37
*** bashrc has quit IRC10:44
*** bashrc has joined #baserock10:45
*** mdunford has quit IRC10:45
*** ssam2 has quit IRC10:46
*** ssam2 has joined #baserock10:55
*** ChanServ sets mode: +v ssam210:55
*** edcragg has quit IRC10:58
*** edcragg has joined #baserock10:58
*** toscalix__ has quit IRC11:18
*** toscalix__ has joined #baserock11:18
*** gtristan has quit IRC11:56
*** gtristan has joined #baserock12:24
*** gary_perkins has quit IRC12:57
jjardontoscalix__: hi, in case you missed the email; any thoughts about http://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2015-October/013314.html ?12:58
* SotK finally notices Gerrit has avatars now13:02
*** toscalix__ has quit IRC13:31
*** toscalix__ has joined #baserock13:36
*** toscalix__ is now known as toscalix13:41
toscalixjjardon: I have read the thread. I have very little to add at this point13:42
* SotK wonders what the current status of the CIAT stuff is13:42
* jjardon too13:43
persiaI think that the infrastructure on which it was running stopped being sponsored.13:45
SotKis there any intention to spin it back up somewhere else?13:45
* persia has not heard anything about new sponsors or initiatives to resume sponsorship by the original sponsor13:46
* persia also doesn't hear everything :)13:46
gtristanaha !13:53
* gtristan figures out libexif13:53
gtristancvs has a submodule kindof thing does it ?13:57
gtristanwhen I run cvs co libexif... this exif: http://libexif.cvs.sourceforge.net/viewvc/libexif/libexif/14:01
gtristanit automatically adds the m4m module at the root, this m4m: http://libexif.cvs.sourceforge.net/viewvc/libexif/m4m/14:02
gtristanThis lorry: https://gerrit.baserock.org/#/c/1375/1/open-source-lorries/libexif.lorry ... however14:02
gtristandoes not14:02
gtristanPerhaps something wrong with my installed git cvs-foo ?14:03
gtristanor unsupported completely ?14:03
* gtristan had tested building from cvs, and had tested the lorry file locally, happy that it successfully created a git14:04
gtristanbut only noticed now that there is the missing submodule14:04
gtristanmaybe, we create a separate import libexif/m4m, and create a .gitmodules referring to upstream:libexif/m4m ? sounds like a waste of effort (and not great solution), for a repo that has not really changed in years14:06
* gtristan thinks we better swap for a tarball in this case14:06
gtristansad, I was excited to use the fancy cvs lorry type :)14:07
*** gary_perkins has joined #baserock14:23
*** toscalix has quit IRC14:27
*** toscalix has joined #baserock14:31
toscalixpersia: that is right14:31
toscalixbut the plan to work on it there are the need too14:32
toscalixit is a matter of priorities at this point14:32
toscalixwe learnt a few things with the last implementation14:33
toscalixwe need to redefine some of the work done14:33
tiagogomesgtristan, I don't know anything about cvs, but the command run by lorry is "git cvsimport  -a -d ":pserver:anonymous@libexif.cvs.sourceforge.net:/cvsroot/libexif" -C "$workingarea"/libexif/git libexif" if it helps14:37
gtristantiagogomes, right, I ran the lorry myself and saw that; but that does not import what is checked out with the regular cvs login & cvs co -P :pserver:.... libexif14:39
gtristanso a "checkout" descends into cvs modules it would seem, and I guess the git cvsimport does not, probably intentionally14:40
tiagogomesgtristan right, looking at the lorry code you can't make it to do that through some option14:42
*** tlsa has quit IRC14:43
*** _longines has quit IRC14:43
gtristantiagogomes, yeah, this particular case of a module which has had no commits in 3+ years doesnt really justify developing one either14:44
*** toscalix has quit IRC14:44
gtristancvs is pretty much dead for any active project14:44
* gtristan reminisces fondly of merging branches with cvs co -j MAINLINE -j BRANCHNAME .14:45
gtristanand picking up the pieces14:45
*** _longines has joined #baserock14:45
*** tlsa has joined #baserock14:45
gtristanor s/co/update ?14:45
gtristanits too far :)14:45
tiagogomesno idea, but I am glad about not knowing :)14:46
gtristanjust imaging "every file has a revision" :)14:47
*** toscalix has joined #baserock14:48
* gtristan submits tarball change https://gerrit.baserock.org/137714:56
paulsher1oodSotK, jjardon - the CIAT implementation was hardly building, while costing rather a lot of money. i was suprised folks did not care enough to either reduce its cost (trivial - change the AWS instance type) or make better use of the capacity available.14:59
tiagogomespaulsher1ood, can I ask why CIAT was in AWS, while the rest of the OpenStack infra is on OpenStack on Datacentred? Is it because of ARM?15:03
paulsher1oodbut in in the meantime other options have been proposed/adopted elsewhere... and i personally am unclear why we would favour buildbot over, say, concourse/cloudfoundry given elasticity is an important requirement15:03
paulsher1oodtiagogomes: AWS makes it possible to have much more than 8 cores on a single machine15:03
paulsher1oodwhich reduces wallclock time for builds significantly15:04
paulsher1ood(if it's done right, that is)15:04
tiagogomesso the reason is that our cloud provider (Datacentred) doesn't support flavors with more than 8 vCPUs15:05
paulsher1ood(for example ybd was building all x86_64 systems in ci.morph prior to adding gnome, in 80 minutes flat)15:05
jjardonpaulsher1ood: ack, thanks for the info. I was simply more curious about future plans regarding tristan questions, more than what happened with the last implementation15:07
paulsher1oodtiagogomes: it's not as simple as that, but that's one reason15:07
paulsher1oodanother would be, more folks are comfortable with AWS than are comfortable with OpenStack as of today15:07
paulsher1oodjjardon: which tristan questions?15:08
tlsaideally it should be able to run anywhere anyway15:08
paulsher1ood+115:08
persiafor elasticity, I'm a fan of zuul+gearman+nodepool, but that may just be me15:09
jjardonpaulsher1ood: any idea how much time take now?15:10
jjardonpaulsher1ood: 12:58 <jjardon> toscalix__: hi, in case you missed the email; any thoughts about http://listmaster.pepperfish.net/pipermail/baserock-dev-baserock.org/2015-October/013314.html ?15:11
gtristanpaulsher1ood, these questions... oh jjardon beat me to it15:11
SotKpersia: I am also a fan of that15:11
gtristananyway, that's something I intended to post to the list a week earlier but got caught up15:12
gtristanok lets go webkit15:13
* gtristan prepares some eggs on top of his keyboard15:13
jjardon Haha15:14
* pedroalvarez hopes they are free range15:15
tiagogomesthrow some bacon in as well :)15:16
jjardongtristan: I think core GNOME components are all there; I was thinking on adding a new stratum for apps, are you OK with that?15:17
gtristanjjardon, yes thats good15:17
gtristanjjardon, some things though, we probably want to be in gnome and not gnome-apps, even if they *seem* like apps15:18
gtristanfor instance, there are some modules which desire cheese and gphoto215:18
gtristantangled integration15:18
jjardonYeah, cheese is a special case I think15:19
gtristanjjardon, so try to be careful, if you add things in gnome-apps, be sure they are not optional dependencies of gnome chunks :)15:19
jjardonI will!15:19
gtristanyou know your modulesets better than I do haha15:20
gtristanjjardon, fwiw today I enabled tracker & libexif in nautilus, and added gnome-color-manager15:20
gtristanwaiting to push the definitions, have a webkit to rebuild atop the new systemd15:21
* pedroalvarez sends more patches to fix our infra: https://gerrit.baserock.org/#/q/topic:baserock/pedroalvarez/infra-fixes15:21
jjardon gtristan : tracker is already enabled ;)15:22
gtristanoh ?15:22
gtristanjjardon, I saw that you *added* it15:22
gtristanlocally I have a patch which removes --disable-tracker in nautilus15:23
gtristanin my queue15:23
gtristanmaybe you also did that today ?15:23
gtristanjjardon, I think we also have to add it as a dependency to some other chunks, to make sure they find it at configure time15:23
tiagogomesgtristan https://gerrit.baserock.org/#/c/1368/ is merged15:23
gtristangah15:24
gtristanhonestly, I try to only rebase against master at the beginning of the day15:24
gtristanotherwise I would be constantly building and have no time to ever check if anything worked15:25
gtristanwell, then that local patch will just do the libexif thing15:25
jjardongtristan: sorry, I will put you in cc next time15:25
gtristanI might be able to rebase much more often if entire strata didnt need rebuilds just because of a systemd version bump ;-)15:26
jjardongtristan: I know the feeling ;)15:29
gtristanactually I did consider cherry picking gnome stuff into my own branch, maximizing my reuse of the existing artifacts (and was doing that earlier today)15:29
gtristanbut then I decided to take the plunge15:30
gtristanI tested telepathy-mission-control that way15:30
pedroalvarezperryl: hi! I was going to test your trove-setup changes but I take from your comment that it doesn't work16:19
pedroalvarezis that correct?16:19
perrylpedroalvarez: it's currently undergoing some changes, yes; i can push the change to the url-rewrite branch (1338) if you wish to test that, but the cgit filter patch (1339) i think may be best tested once i've reimplemented using pyyaml16:21
pedroalvarezoh, that sounds good16:23
gtristanpedroalvarez, I tested it locally - and what I have is a CVS imported history with one Lorry Tar Creator commit at HEAD16:34
gtristanthe lorry delivered my organic chicken in tact, it seems16:34
* gtristan comments in gerrit16:36
gtristanbut fwiw: http://paste.baserock.org/qitironafa16:36
gtristancommented here: https://gerrit.baserock.org/#/c/1377/16:41
*** paulsherwood has joined #baserock16:52
*** straycat has quit IRC16:52
*** nowster_ has joined #baserock16:55
pedroalvarezscary16:59
paulsherwood?17:00
pedroalvarezthe side effects of replacing a cvs lorry by a tarball one17:00
pedroalvareztarball lorry pushes on top of cvs history: http://paste.baserock.org/qitironafa17:01
pedroalvarezcontext of this discussion here: https://irclogs.baserock.org/%23baserock.2015-11-05.log.html#t2015-11-05T16:34:4117:02
pedroalvarezpatch related  here: https://irclogs.baserock.org/%23baserock.2015-11-05.log.html#t2015-11-05T16:34:4117:02
pedroalvarezno17:02
pedroalvarezhere https://gerrit.baserock.org/#/c/1377/17:02
paulsherwood:/17:02
*** straycat has joined #baserock17:02
paulsherwoodwhy would we ever go from cvs to tarball?17:03
persiasubmodules.17:03
pedroalvarezyeah, cvs submodules17:03
*** nowster has quit IRC17:04
*** mariaderidder has quit IRC17:04
*** jjardon has quit IRC17:04
*** paulsher1ood has quit IRC17:04
*** zoli_ has quit IRC17:04
pedroalvarezour current approach for converting cvs to git doesn't handle the case where the cvs repo has submodules17:04
*** jjardon_ has joined #baserock17:05
pedroalvarezgtristan: I'm afraid of people doing these kind of changes as if lorry were taking care of the migration properly17:06
gtristanpedroalvarez, yup, thats me; blindly expecting lorry to do the sensible thing :)17:07
pedroalvarezheh17:07
*** jjardon_ is now known as jjardon17:08
gtristanpedroalvarez, in this case though; I mean, you have to admit that a tarball lorry is *expected* to be upgraded17:08
pedroalvarezyes17:08
gtristanso whatever it would do, would be a conversion of what is checked out in git, and a full overwrite of what is in the tarball17:08
pedroalvarezbut having cvs history mixed with the tarball import is not what I would want17:08
*** jjardon has quit IRC17:10
paulsherwoodcan we fix lorry to 'do the sensible thing'?17:14
*** zoli_ has joined #baserock17:15
pedroalvarezheh17:15
pedroalvarezwhat is the sensible thing here17:15
pedroalvarezI was thinking 5 minutes ago that maybe the sensible thing is to append the type to the name of the lorry17:16
paulsherwoodwhatever gtristan expected it to do?17:16
pedroalvarezit's doing whatever other guy expected it to do I guess17:16
paulsherwoodlol17:17
pedroalvarez:)17:17
*** ctbruce has quit IRC17:17
pedroalvarezso yes, we can fix it, but with a clear opinion about what it should do17:17
pedroalvarezI would expect lorry to fail if you change the type, for example17:18
ssam2that's safest, i think that's the best answer17:26
ssam2even though less convenient17:26
ssam2overwriting contents of repos is bad, because anyone who was using those sha1s will find their builds no longer work17:26
paulsherwood+117:27
gtristanThen, the policy is to always have a separate lorry 'name' for the same module when moving from one source to another ?17:27
tiagogomesthat's what we have been doing so far17:27
gtristanssam2, this case you should note, does *not* break the sha1s17:27
gtristantiagogomes, technically, it should be the same policy when, for example, a github project is finally moved and hosted on git.gnome.org - even though it's still a git... right ?17:28
pedroalvarezI'm tempted to research what repositories have never been used in definitions.git, and which ones have never been present on one of the tags17:28
gtristanI'm not arguing against the consensus here, I'm just stirring and muddying the water :)17:29
toscalixwhich one is the best solution in terms of maintainability? Imagine a company that requires to support centain software for 10 years17:29
pedroalvarezgtristan: I appreciate the effort you are making for identifying policies17:29
radiofreegtristan: i believe we can just change the git repo if it's a git->git change17:30
radiofreeat least, i think we did that with qt17:30
tiagogomesgtristan if a git project just changes its URL, we just update the URL in the lorry17:30
radiofree(gitorious -> code.qt.io)17:31
gtristantiagogomes, radiofree: are you certain that it will not break the sha1s when doing so ?17:31
radiofreei don't think you can ever be certain, but i *think* trove will complain if it does17:31
gtristanif so then I digress, perhaps *only* because it's with git, and only if the git migration from github to another hosting brings it's history along with it17:32
gtristanit would not necessarily be so, if you changed an svn lorry's url17:32
*** mariaderidder has joined #baserock17:33
tiagogomesgtristan it is always nice to double check for git that the SHAs are the same, as we can't rely that the upstream did the right thing17:34
ssam2gtristan: yes. when a git repo moves, we check if the SHA1s match17:37
gtristanSo, tomorrow which of the following would you like: A.) git mv libexif.lorry libexif-tarball.lorry && edit name && submit patch... B.) git add a completely new libexif-tarball.lorry, leaving the useless one in place ?17:37
gtristanssam2, that's nice to know :)17:37
ssam2probably no harm in deleting the current libexif repo, since it seems nobody could have actually used it for anything anyway17:38
gtristancant be built without the submodule containing the m4 macros, right17:38
gtristanok, so one commit which moves it17:39
*** nowster_ has quit IRC17:39
* gtristan does it now17:40
tiagogomesif would be nice that the ops team deleted the libexif repo as soon as possible :)17:41
gtristanUpdated https://gerrit.baserock.org/#/c/1377/17:42
toscalixchecking sha1 = improving integrity?17:44
gtristantoscalix, definitions contain references to the git by their commit ID (that is the sha1), so each chunk compiles a very specific revision17:45
toscalixyes, the point is that there might be cases in which the software remains unchanged but the metadata might change, right?17:46
gtristantoscalix, the risk is that lorry mucks it up and the sha1 is invalid, breaking a build (or the vastly improbable case that the sha1s have changed, and the referred to sha1 actually refers to a valid, but incorrect commit)17:46
toscalixlike the url of the repo. Did I understood correctly?17:47
gtristantoscalix, the point is that when you change from an svn repository to a git repository, or to a tarball repository, for the lorry name, the context/source of those sha1s change17:47
gtristanright, the lorry file contains a url from whence to pull/poll the source for changes17:47
toscalixhummmm17:48
gtristanso, the paranoid policy would be to *always* change the lorry name itself (forcing definitions to update themselves to point to the new lorry name), whenever changing any lorry source17:48
toscalixthinking about 10 years support scenarios..... we should assume that every piece of software will change its url17:49
gtristanhowever with git, we have a higher level of trust - *AND* as ssam2 reassures us, IF you change the url source of a git repository, the lorry will perform a check that the sha1s in the new source match up with what we have17:49
toscalixI see17:49
toscalixso in that case, if I have a system... so a collections of sha1, I will be able to do a validation check to ensure that no soft. change has been introduced in the pipeline?17:51
toscalix10 years later?17:52
ssam2git provides that, yes17:52
toscalixthanks17:52
gtristana tag on the definitions repository will let you reproduce *exactly* the same system in 10 years17:52
gtristanprovided that you still have the trove :)17:53
*** jonathanmaw has quit IRC17:53
toscalixthe scenario is that kind of verification will be done by a third party (validation) during the delivery stage17:54
toscalixthanks for the answer17:54
pedroalvarezright, delta/libexif removed, tarball one already created17:56
*** mariaderidder has quit IRC17:57
gtristangreat, I'm so glad that webkit doesnt depend on it :)17:58
* gtristan finishes webkit compile17:59
gtristanok no changing systemd this week !17:59
gtristanhaha17:59
pedroalvarezhehe18:00
*** bashrc has quit IRC18:05
*** ssam2 has quit IRC18:07
*** dabukalam has quit IRC18:45
*** dabukalam has joined #baserock18:46
*** tiagogomes has quit IRC19:04
*** toscalix has quit IRC19:05
*** edcragg has quit IRC19:31
*** persia_ has quit IRC22:08

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