| *** edcragg has quit IRC | 00:06 | |
| *** JPohlmann has quit IRC | 00:31 | |
| *** JPohlmann has joined #baserock | 00:32 | |
| *** JPohlmann has joined #baserock | 00:32 | |
| *** edcragg has joined #baserock | 00:34 | |
| *** edcragg has quit IRC | 00:48 | |
| *** edcragg has joined #baserock | 01:03 | |
| *** edcragg has quit IRC | 01:07 | |
| *** Lunar^ has quit IRC | 03:03 | |
| *** Lunar^ has joined #baserock | 03:03 | |
| *** gtristan has quit IRC | 04:40 | |
| *** gtristan has joined #baserock | 05:10 | |
| *** paulwaters_ has quit IRC | 08:38 | |
| *** bashrc has joined #baserock | 09:00 | |
| *** ctbruce has joined #baserock | 09:02 | |
| *** jonathanmaw has joined #baserock | 09:21 | |
| *** Lunar^ has quit IRC | 09:24 | |
| *** Lunar^ has joined #baserock | 09:26 | |
| *** ctbruce has quit IRC | 09:27 | |
| *** toscalix__ has joined #baserock | 09:30 | |
| *** ctbruce has joined #baserock | 09:37 | |
| *** paulwaters_ has joined #baserock | 09:39 | |
| *** mariaderidder has joined #baserock | 09:39 | |
| *** toscalix__ has quit IRC | 09:40 | |
| *** paulwaters_ has quit IRC | 09:41 | |
| *** toscalix__ has joined #baserock | 09:44 | |
| *** toscalix__ has quit IRC | 09:45 | |
| *** toscalix__ has joined #baserock | 09:45 | |
| *** nowster has joined #baserock | 09:46 | |
| *** paulwaters_ has joined #baserock | 09:48 | |
| *** CTtpollard has quit IRC | 10:03 | |
| *** ssam2 has joined #baserock | 10:04 | |
| *** ChanServ sets mode: +v ssam2 | 10:04 | |
| *** CTtpollard has joined #baserock | 10:04 | |
| tiagogomes | morning, 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 IRC | 10:10 | |
| *** gary_perkins has joined #baserock | 10:14 | |
| *** edcragg has joined #baserock | 10:17 | |
| pedroalvarez | you are right | 10:18 |
| pedroalvarez | that's why we haven't migrated our definitions to version 7 | 10:19 |
| gtristan | any idea how to invoke gettextize --stfu ? | 10:23 |
| gtristan | the --force option still says "Press enter to acknowledge the above paragraphs" and tries to read a tty | 10:23 |
| gtristan | maybe: echo "" | gettextize --force | 10:25 |
| persia | or `gettextize --force <<< "¥n"` | 10:26 |
| * pedroalvarez sees threads in google about the same thing | 10:27 | |
| pedroalvarez | read dummy < /dev/tty | 10:27 |
| persia | gtristan: Maybe use autopoint instead? | 10:29 |
| pedroalvarez | I was going to suggest the same | 10:29 |
| * gtristan is following libexif's README | 10:30 | |
| gtristan | lets see, maybe autopoint... /me not sure what to put there | 10: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/widenuruso | 10:32 | |
| gtristan | the second part "probably just", well... doesnt work :) | 10:32 |
| persia | heh | 10:36 |
| gtristan | yeah that doesnt work, for the same error that autoreconf doesnt, I'll figure it out | 10:37 |
| *** bashrc has quit IRC | 10:44 | |
| *** bashrc has joined #baserock | 10:45 | |
| *** mdunford has quit IRC | 10:45 | |
| *** ssam2 has quit IRC | 10:46 | |
| *** ssam2 has joined #baserock | 10:55 | |
| *** ChanServ sets mode: +v ssam2 | 10:55 | |
| *** edcragg has quit IRC | 10:58 | |
| *** edcragg has joined #baserock | 10:58 | |
| *** toscalix__ has quit IRC | 11:18 | |
| *** toscalix__ has joined #baserock | 11:18 | |
| *** gtristan has quit IRC | 11:56 | |
| *** gtristan has joined #baserock | 12:24 | |
| *** gary_perkins has quit IRC | 12:57 | |
| 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 ? | 12:58 |
| * SotK finally notices Gerrit has avatars now | 13:02 | |
| *** toscalix__ has quit IRC | 13:31 | |
| *** toscalix__ has joined #baserock | 13:36 | |
| *** toscalix__ is now known as toscalix | 13:41 | |
| toscalix | jjardon: I have read the thread. I have very little to add at this point | 13:42 |
| * SotK wonders what the current status of the CIAT stuff is | 13:42 | |
| * jjardon too | 13:43 | |
| persia | I think that the infrastructure on which it was running stopped being sponsored. | 13:45 |
| SotK | is 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 sponsor | 13:46 | |
| * persia also doesn't hear everything :) | 13:46 | |
| gtristan | aha ! | 13:53 |
| * gtristan figures out libexif | 13:53 | |
| gtristan | cvs has a submodule kindof thing does it ? | 13:57 |
| gtristan | when I run cvs co libexif... this exif: http://libexif.cvs.sourceforge.net/viewvc/libexif/libexif/ | 14:01 |
| gtristan | it automatically adds the m4m module at the root, this m4m: http://libexif.cvs.sourceforge.net/viewvc/libexif/m4m/ | 14:02 |
| gtristan | This lorry: https://gerrit.baserock.org/#/c/1375/1/open-source-lorries/libexif.lorry ... however | 14:02 |
| gtristan | does not | 14:02 |
| gtristan | Perhaps something wrong with my installed git cvs-foo ? | 14:03 |
| gtristan | or unsupported completely ? | 14:03 |
| * gtristan had tested building from cvs, and had tested the lorry file locally, happy that it successfully created a git | 14:04 | |
| gtristan | but only noticed now that there is the missing submodule | 14:04 |
| gtristan | maybe, 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 years | 14:06 |
| * gtristan thinks we better swap for a tarball in this case | 14:06 | |
| gtristan | sad, I was excited to use the fancy cvs lorry type :) | 14:07 |
| *** gary_perkins has joined #baserock | 14:23 | |
| *** toscalix has quit IRC | 14:27 | |
| *** toscalix has joined #baserock | 14:31 | |
| toscalix | persia: that is right | 14:31 |
| toscalix | but the plan to work on it there are the need too | 14:32 |
| toscalix | it is a matter of priorities at this point | 14:32 |
| toscalix | we learnt a few things with the last implementation | 14:33 |
| toscalix | we need to redefine some of the work done | 14:33 |
| tiagogomes | gtristan, 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 helps | 14:37 |
| gtristan | tiagogomes, 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:.... libexif | 14:39 |
| gtristan | so a "checkout" descends into cvs modules it would seem, and I guess the git cvsimport does not, probably intentionally | 14:40 |
| tiagogomes | gtristan right, looking at the lorry code you can't make it to do that through some option | 14:42 |
| *** tlsa has quit IRC | 14:43 | |
| *** _longines has quit IRC | 14:43 | |
| gtristan | tiagogomes, yeah, this particular case of a module which has had no commits in 3+ years doesnt really justify developing one either | 14:44 |
| *** toscalix has quit IRC | 14:44 | |
| gtristan | cvs is pretty much dead for any active project | 14:44 |
| * gtristan reminisces fondly of merging branches with cvs co -j MAINLINE -j BRANCHNAME . | 14:45 | |
| gtristan | and picking up the pieces | 14:45 |
| *** _longines has joined #baserock | 14:45 | |
| *** tlsa has joined #baserock | 14:45 | |
| gtristan | or s/co/update ? | 14:45 |
| gtristan | its too far :) | 14:45 |
| tiagogomes | no idea, but I am glad about not knowing :) | 14:46 |
| gtristan | just imaging "every file has a revision" :) | 14:47 |
| *** toscalix has joined #baserock | 14:48 | |
| * gtristan submits tarball change https://gerrit.baserock.org/1377 | 14:56 | |
| paulsher1ood | SotK, 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 |
| tiagogomes | paulsher1ood, 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 |
| paulsher1ood | but 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 requirement | 15:03 |
| paulsher1ood | tiagogomes: AWS makes it possible to have much more than 8 cores on a single machine | 15:03 |
| paulsher1ood | which reduces wallclock time for builds significantly | 15:04 |
| paulsher1ood | (if it's done right, that is) | 15:04 |
| tiagogomes | so the reason is that our cloud provider (Datacentred) doesn't support flavors with more than 8 vCPUs | 15:05 |
| paulsher1ood | (for example ybd was building all x86_64 systems in ci.morph prior to adding gnome, in 80 minutes flat) | 15:05 |
| jjardon | paulsher1ood: ack, thanks for the info. I was simply more curious about future plans regarding tristan questions, more than what happened with the last implementation | 15:07 |
| paulsher1ood | tiagogomes: it's not as simple as that, but that's one reason | 15:07 |
| paulsher1ood | another would be, more folks are comfortable with AWS than are comfortable with OpenStack as of today | 15:07 |
| paulsher1ood | jjardon: which tristan questions? | 15:08 |
| tlsa | ideally it should be able to run anywhere anyway | 15:08 |
| paulsher1ood | +1 | 15:08 |
| persia | for elasticity, I'm a fan of zuul+gearman+nodepool, but that may just be me | 15:09 |
| jjardon | paulsher1ood: any idea how much time take now? | 15:10 |
| jjardon | paulsher1ood: 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 |
| gtristan | paulsher1ood, these questions... oh jjardon beat me to it | 15:11 |
| SotK | persia: I am also a fan of that | 15:11 |
| gtristan | anyway, that's something I intended to post to the list a week earlier but got caught up | 15:12 |
| gtristan | ok lets go webkit | 15:13 |
| * gtristan prepares some eggs on top of his keyboard | 15:13 | |
| jjardon | Haha | 15:14 |
| * pedroalvarez hopes they are free range | 15:15 | |
| tiagogomes | throw some bacon in as well :) | 15:16 |
| jjardon | gtristan: 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 |
| gtristan | jjardon, yes thats good | 15:17 |
| gtristan | jjardon, some things though, we probably want to be in gnome and not gnome-apps, even if they *seem* like apps | 15:18 |
| gtristan | for instance, there are some modules which desire cheese and gphoto2 | 15:18 |
| gtristan | tangled integration | 15:18 |
| jjardon | Yeah, cheese is a special case I think | 15:19 |
| gtristan | jjardon, so try to be careful, if you add things in gnome-apps, be sure they are not optional dependencies of gnome chunks :) | 15:19 |
| jjardon | I will! | 15:19 |
| gtristan | you know your modulesets better than I do haha | 15:20 |
| gtristan | jjardon, fwiw today I enabled tracker & libexif in nautilus, and added gnome-color-manager | 15:20 |
| gtristan | waiting to push the definitions, have a webkit to rebuild atop the new systemd | 15:21 |
| * pedroalvarez sends more patches to fix our infra: https://gerrit.baserock.org/#/q/topic:baserock/pedroalvarez/infra-fixes | 15:21 | |
| jjardon | gtristan : tracker is already enabled ;) | 15:22 |
| gtristan | oh ? | 15:22 |
| gtristan | jjardon, I saw that you *added* it | 15:22 |
| gtristan | locally I have a patch which removes --disable-tracker in nautilus | 15:23 |
| gtristan | in my queue | 15:23 |
| gtristan | maybe you also did that today ? | 15:23 |
| gtristan | jjardon, I think we also have to add it as a dependency to some other chunks, to make sure they find it at configure time | 15:23 |
| tiagogomes | gtristan https://gerrit.baserock.org/#/c/1368/ is merged | 15:23 |
| gtristan | gah | 15:24 |
| gtristan | honestly, I try to only rebase against master at the beginning of the day | 15:24 |
| gtristan | otherwise I would be constantly building and have no time to ever check if anything worked | 15:25 |
| gtristan | well, then that local patch will just do the libexif thing | 15:25 |
| jjardon | gtristan: sorry, I will put you in cc next time | 15:25 |
| gtristan | I might be able to rebase much more often if entire strata didnt need rebuilds just because of a systemd version bump ;-) | 15:26 |
| jjardon | gtristan: I know the feeling ;) | 15:29 |
| gtristan | actually 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 |
| gtristan | but then I decided to take the plunge | 15:30 |
| gtristan | I tested telepathy-mission-control that way | 15:30 |
| pedroalvarez | perryl: hi! I was going to test your trove-setup changes but I take from your comment that it doesn't work | 16:19 |
| pedroalvarez | is that correct? | 16:19 |
| perryl | pedroalvarez: 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 pyyaml | 16:21 |
| pedroalvarez | oh, that sounds good | 16:23 |
| gtristan | pedroalvarez, I tested it locally - and what I have is a CVS imported history with one Lorry Tar Creator commit at HEAD | 16:34 |
| gtristan | the lorry delivered my organic chicken in tact, it seems | 16:34 |
| * gtristan comments in gerrit | 16:36 | |
| gtristan | but fwiw: http://paste.baserock.org/qitironafa | 16:36 |
| gtristan | commented here: https://gerrit.baserock.org/#/c/1377/ | 16:41 |
| *** paulsherwood has joined #baserock | 16:52 | |
| *** straycat has quit IRC | 16:52 | |
| *** nowster_ has joined #baserock | 16:55 | |
| pedroalvarez | scary | 16:59 |
| paulsherwood | ? | 17:00 |
| pedroalvarez | the side effects of replacing a cvs lorry by a tarball one | 17:00 |
| pedroalvarez | tarball lorry pushes on top of cvs history: http://paste.baserock.org/qitironafa | 17:01 |
| pedroalvarez | context of this discussion here: https://irclogs.baserock.org/%23baserock.2015-11-05.log.html#t2015-11-05T16:34:41 | 17:02 |
| pedroalvarez | patch related here: https://irclogs.baserock.org/%23baserock.2015-11-05.log.html#t2015-11-05T16:34:41 | 17:02 |
| pedroalvarez | no | 17:02 |
| pedroalvarez | here https://gerrit.baserock.org/#/c/1377/ | 17:02 |
| paulsherwood | :/ | 17:02 |
| *** straycat has joined #baserock | 17:02 | |
| paulsherwood | why would we ever go from cvs to tarball? | 17:03 |
| persia | submodules. | 17:03 |
| pedroalvarez | yeah, cvs submodules | 17:03 |
| *** nowster has quit IRC | 17:04 | |
| *** mariaderidder has quit IRC | 17:04 | |
| *** jjardon has quit IRC | 17:04 | |
| *** paulsher1ood has quit IRC | 17:04 | |
| *** zoli_ has quit IRC | 17:04 | |
| pedroalvarez | our current approach for converting cvs to git doesn't handle the case where the cvs repo has submodules | 17:04 |
| *** jjardon_ has joined #baserock | 17:05 | |
| pedroalvarez | gtristan: I'm afraid of people doing these kind of changes as if lorry were taking care of the migration properly | 17:06 |
| gtristan | pedroalvarez, yup, thats me; blindly expecting lorry to do the sensible thing :) | 17:07 |
| pedroalvarez | heh | 17:07 |
| *** jjardon_ is now known as jjardon | 17:08 | |
| gtristan | pedroalvarez, in this case though; I mean, you have to admit that a tarball lorry is *expected* to be upgraded | 17:08 |
| pedroalvarez | yes | 17:08 |
| gtristan | so whatever it would do, would be a conversion of what is checked out in git, and a full overwrite of what is in the tarball | 17:08 |
| pedroalvarez | but having cvs history mixed with the tarball import is not what I would want | 17:08 |
| *** jjardon has quit IRC | 17:10 | |
| paulsherwood | can we fix lorry to 'do the sensible thing'? | 17:14 |
| *** zoli_ has joined #baserock | 17:15 | |
| pedroalvarez | heh | 17:15 |
| pedroalvarez | what is the sensible thing here | 17:15 |
| pedroalvarez | I was thinking 5 minutes ago that maybe the sensible thing is to append the type to the name of the lorry | 17:16 |
| paulsherwood | whatever gtristan expected it to do? | 17:16 |
| pedroalvarez | it's doing whatever other guy expected it to do I guess | 17:16 |
| paulsherwood | lol | 17:17 |
| pedroalvarez | :) | 17:17 |
| *** ctbruce has quit IRC | 17:17 | |
| pedroalvarez | so yes, we can fix it, but with a clear opinion about what it should do | 17:17 |
| pedroalvarez | I would expect lorry to fail if you change the type, for example | 17:18 |
| ssam2 | that's safest, i think that's the best answer | 17:26 |
| ssam2 | even though less convenient | 17:26 |
| ssam2 | overwriting contents of repos is bad, because anyone who was using those sha1s will find their builds no longer work | 17:26 |
| paulsherwood | +1 | 17:27 |
| gtristan | Then, the policy is to always have a separate lorry 'name' for the same module when moving from one source to another ? | 17:27 |
| tiagogomes | that's what we have been doing so far | 17:27 |
| gtristan | ssam2, this case you should note, does *not* break the sha1s | 17:27 |
| gtristan | tiagogomes, 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 |
| pedroalvarez | I'm tempted to research what repositories have never been used in definitions.git, and which ones have never been present on one of the tags | 17:28 |
| gtristan | I'm not arguing against the consensus here, I'm just stirring and muddying the water :) | 17:29 |
| toscalix | which one is the best solution in terms of maintainability? Imagine a company that requires to support centain software for 10 years | 17:29 |
| pedroalvarez | gtristan: I appreciate the effort you are making for identifying policies | 17:29 |
| radiofree | gtristan: i believe we can just change the git repo if it's a git->git change | 17:30 |
| radiofree | at least, i think we did that with qt | 17:30 |
| tiagogomes | gtristan if a git project just changes its URL, we just update the URL in the lorry | 17:30 |
| radiofree | (gitorious -> code.qt.io) | 17:31 |
| gtristan | tiagogomes, radiofree: are you certain that it will not break the sha1s when doing so ? | 17:31 |
| radiofree | i don't think you can ever be certain, but i *think* trove will complain if it does | 17:31 |
| gtristan | if 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 it | 17:32 |
| gtristan | it would not necessarily be so, if you changed an svn lorry's url | 17:32 |
| *** mariaderidder has joined #baserock | 17:33 | |
| tiagogomes | gtristan 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 thing | 17:34 |
| ssam2 | gtristan: yes. when a git repo moves, we check if the SHA1s match | 17:37 |
| gtristan | So, 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 |
| gtristan | ssam2, that's nice to know :) | 17:37 |
| ssam2 | probably no harm in deleting the current libexif repo, since it seems nobody could have actually used it for anything anyway | 17:38 |
| gtristan | cant be built without the submodule containing the m4 macros, right | 17:38 |
| gtristan | ok, so one commit which moves it | 17:39 |
| *** nowster_ has quit IRC | 17:39 | |
| * gtristan does it now | 17:40 | |
| tiagogomes | if would be nice that the ops team deleted the libexif repo as soon as possible :) | 17:41 |
| gtristan | Updated https://gerrit.baserock.org/#/c/1377/ | 17:42 |
| toscalix | checking sha1 = improving integrity? | 17:44 |
| gtristan | toscalix, definitions contain references to the git by their commit ID (that is the sha1), so each chunk compiles a very specific revision | 17:45 |
| toscalix | yes, the point is that there might be cases in which the software remains unchanged but the metadata might change, right? | 17:46 |
| gtristan | toscalix, 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 |
| toscalix | like the url of the repo. Did I understood correctly? | 17:47 |
| gtristan | toscalix, 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 change | 17:47 |
| gtristan | right, the lorry file contains a url from whence to pull/poll the source for changes | 17:47 |
| toscalix | hummmm | 17:48 |
| gtristan | so, 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 source | 17:48 |
| toscalix | thinking about 10 years support scenarios..... we should assume that every piece of software will change its url | 17:49 |
| gtristan | however 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 have | 17:49 |
| toscalix | I see | 17:49 |
| toscalix | so 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 |
| toscalix | 10 years later? | 17:52 |
| ssam2 | git provides that, yes | 17:52 |
| toscalix | thanks | 17:52 |
| gtristan | a tag on the definitions repository will let you reproduce *exactly* the same system in 10 years | 17:52 |
| gtristan | provided that you still have the trove :) | 17:53 |
| *** jonathanmaw has quit IRC | 17:53 | |
| toscalix | the scenario is that kind of verification will be done by a third party (validation) during the delivery stage | 17:54 |
| toscalix | thanks for the answer | 17:54 |
| pedroalvarez | right, delta/libexif removed, tarball one already created | 17:56 |
| *** mariaderidder has quit IRC | 17:57 | |
| gtristan | great, I'm so glad that webkit doesnt depend on it :) | 17:58 |
| * gtristan finishes webkit compile | 17:59 | |
| gtristan | ok no changing systemd this week ! | 17:59 |
| gtristan | haha | 17:59 |
| pedroalvarez | hehe | 18:00 |
| *** bashrc has quit IRC | 18:05 | |
| *** ssam2 has quit IRC | 18:07 | |
| *** dabukalam has quit IRC | 18:45 | |
| *** dabukalam has joined #baserock | 18:46 | |
| *** tiagogomes has quit IRC | 19:04 | |
| *** toscalix has quit IRC | 19:05 | |
| *** edcragg has quit IRC | 19:31 | |
| *** persia_ has quit IRC | 22:08 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!