| gitlab-br-bot | buildstream: issue #161 ("Stack trace while removing device files, fuse related") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/161 | 05:35 |
|---|---|---|
| *** tristan has joined #buildstream | 05:36 | |
| gitlab-br-bot | buildstream: issue #162 ("Add --unsafe option to bst checkout") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/162 | 06:09 |
| *** tristan has quit IRC | 06:35 | |
| *** tristan has joined #buildstream | 06:55 | |
| *** bochecha has joined #buildstream | 08:35 | |
| *** bochecha has left #buildstream | 08:35 | |
| *** bochecha has joined #buildstream | 08:39 | |
| *** tristan has quit IRC | 08:43 | |
| *** valentind has joined #buildstream | 08:45 | |
| *** bethw has joined #buildstream | 09:23 | |
| *** bochecha_ has joined #buildstream | 09:47 | |
| *** bochecha has quit IRC | 09:50 | |
| *** bochecha_ is now known as bochecha | 09:50 | |
| *** valentind has quit IRC | 09:50 | |
| *** jonathanmaw has joined #buildstream | 10:00 | |
| *** ssam2 has joined #buildstream | 10:18 | |
| *** tpollard has quit IRC | 10:29 | |
| *** tpollard has joined #buildstream | 10:33 | |
| *** bochecha_ has joined #buildstream | 11:05 | |
| *** bochecha has quit IRC | 11:07 | |
| *** bochecha_ is now known as bochecha | 11:07 | |
| *** saxa has joined #buildstream | 13:09 | |
| saxa | hi, I want to start using buildstream to buildmy project. I would like to know few things. | 13:09 |
| saxa | First thing is that I saw it requires Ostree | 13:10 |
| saxa | I use Slackware for my project | 13:10 |
| saxa | and i probably will need to build os tree separately | 13:10 |
| saxa | is ostree a must ? | 13:10 |
| ssam2 | it's possible to use buildstream without, to a point | 13:11 |
| saxa | Another thing whichinterests me is that I want to be able to get the installable packages of the stuff I build. | 13:11 |
| ssam2 | but you will miss out on (a) being able to pull from OStree remote sources, (b) being able to share artifacts with remote caches, and (c) deduplication in your local artifact cache | 13:11 |
| saxa | installable packages made for Slackware | 13:11 |
| ssam2 | that can be done | 13:12 |
| saxa | ssam2: I see | 13:12 |
| saxa | most probably for creating a package I will need to write a plugin | 13:12 |
| ssam2 | probably | 13:12 |
| saxa | so let me explain better about my project. | 13:12 |
| ssam2 | you can play around with the 'script' plugin to begin with | 13:13 |
| ssam2 | and just have a script which generates your package. from there you can decide whether it's useful to write a dedicated plugin for slackware packages | 13:13 |
| saxa | I am building gnome packages for slackware, see www.droplinegnome.org | 13:14 |
| ssam2 | oh, cool | 13:14 |
| saxa | so I have an build system but I would like to switch and start using buildstream | 13:15 |
| * ssam2 used to use dropline GNOME many years ago :-) | 13:15 | |
| saxa | :) | 13:15 |
| saxa | ssam2: so you are a slackware man :) | 13:15 |
| saxa | anyway, I will have to do some tests before, as now we have also python3 in the upcoming slackware release | 13:16 |
| saxa | and this will ease a bit the things for me | 13:16 |
| saxa | there is already lots of updated gnome stuff in slackware too, so I wouldlike to avoid duplicating what is not really necessary to duplicate | 13:17 |
| saxa | mostly base stuff is in there, glib, gtk, some themes and so on | 13:17 |
| ssam2 | i guess you'll have a pipeline which builds all GNOME modules, and then produces a package *For each module* ? | 13:17 |
| saxa | correct | 13:17 |
| ssam2 | I'm not yet sure the best way to do that | 13:17 |
| saxa | this is what I want to achieve | 13:17 |
| ssam2 | the obvious way is to have a -pkg element for each thing you build, I guess | 13:17 |
| ssam2 | so you have 'gnome-session.bst', for example, then 'gnome-session-pkg.bst' which produces a package from that | 13:18 |
| saxa | build the full gnome desktop, or the modules I choose to, and have the resulting slackware .txz package done | 13:18 |
| ssam2 | and add the end you can have a 'dropline-gnome.bst' package, which depends on every -pkg element | 13:18 |
| ssam2 | and when you check that out, you get a directory full of Slackware packages | 13:18 |
| ssam2 | a 'dropline-gnome.bst' element, I mean | 13:19 |
| saxa | i see | 13:19 |
| saxa | seems logical yes | 13:19 |
| saxa | I now use my own build list, which is made each gnome release by hand | 13:19 |
| saxa | one by one | 13:19 |
| ssam2 | ouch | 13:19 |
| saxa | and this is tireing | 13:19 |
| ssam2 | I see where you are going with this | 13:20 |
| saxa | so I would like to use the gnome release team stuff possibly | 13:20 |
| ssam2 | and it should be possible ... we are working on "recursive pipelines" support, which basically means you can have one BuildStream project depend on another one | 13:20 |
| saxa | since its already done by somebody is no sense to duplicate it :) | 13:20 |
| ssam2 | so you would need to maintain a project of *-pkg.bst elements, and those could depend on the upstream GNOME project | 13:20 |
| saxa | thats good to hear | 13:20 |
| ssam2 | this is something we really want to support in BuildStream, by the way | 13:20 |
| saxa | yeah this is what i understood from the various mails i saw on the desktop ML | 13:21 |
| saxa | anyway I never had the time to try it yet, but I will set up a testing machine and since it is in python and I know some python stuff, not much though, I can also write some plugins and things needed to make this go. | 13:22 |
| ssam2 | great! if you look at the existing element plugins you should get a good idea of what's needed. we don't have any elements that produce packages yet, but that is planned | 13:22 |
| saxa | what mostly intrigues me is how to make it output the .txz slackware package, most probably .xz stuff is already supported in BS. | 13:23 |
| ssam2 | how do you produce slackware packages now ? | 13:23 |
| ssam2 | i expect you'd just have an element that calls the program you use now, and treats the resulting package as its build output | 13:23 |
| ssam2 | the 'compose' element is also relevant here; it supports splitting up build output from another element according to globs | 13:24 |
| ssam2 | so you can include only "runtime" stuff, or only devel headers, or only debug info, etc. | 13:24 |
| ssam2 | although I think slackware doesn't do a runtime/devel package split ? It's been a while since i used it :-) | 13:24 |
| saxa | ssam2: sorry i was busy over here in my office | 13:44 |
| saxa | i use the dropline build system | 13:44 |
| saxa | a set of scripts which create the final package. | 13:44 |
| saxa | it is written in bash | 13:45 |
| saxa | www.sf.net/p/dropline-gnome | 13:45 |
| ssam2 | ok, so you already have the code to create the package; that can just be wrapped up in an element | 13:45 |
| ssam2 | an element plugin, rather | 13:45 |
| ssam2 | build elements are all actually glorified shell scripts :-) | 13:45 |
| saxa | i think its not good to go calling the atual build system. | 13:46 |
| ssam2 | what do you mean by "the actual build system" ? | 13:46 |
| saxa | since i have to create and modify everytime the build scripts version and patches and such things | 13:46 |
| saxa | thebuild system i use to create the gnome packages | 13:47 |
| ssam2 | Can you separate out the bit that creates the actual package? | 13:47 |
| saxa | i think you are talking about the slackwares build system ? | 13:47 |
| ssam2 | separate that from the part that produces the binaries from the source code | 13:47 |
| saxa | ok slackwares package is a source code build up with make for example and installed into a temp dir, then all is tarred and xzipped with makepkgcommand on slackware | 13:48 |
| saxa | the makepkg command then checks for symlinks, and creates a simple install script | 13:49 |
| saxa | and then it gzips all together with the package description file | 13:49 |
| saxa | and you get a resulting .txz | 13:49 |
| ssam2 | ah ok | 13:49 |
| ssam2 | so you could have a 'slackware_pkg' element which wraps `makepkg` | 13:50 |
| saxa | which is then installable with installpkg or upgradepkg shell scripts | 13:50 |
| saxa | probably | 13:50 |
| saxa | so dropline build system, in short DBS is using this tools to create the actual package | 13:50 |
| saxa | its also a mess because now slackware uses slackbuilds to create the packages, slackbuilds are simple scripts in bash which runs all the needed commands, configure, make etc... | 13:51 |
| saxa | when dropline was born at the time there were no slackbuilds yet afair | 13:52 |
| saxa | but i am looking for a way to use as much as possible of what you have in build stream already | 13:52 |
| saxa | slackware next release will also have meson and ninja which is another good addition for me | 13:53 |
| saxa | sine i wont need to install separately thosetools just to get gnome build. | 13:53 |
| saxa | but my idea is to have one centralized list or build order or whatever plugin which could simply download, untar, uncompress, configure, build , install and packagize the stuff | 13:54 |
| saxa | and al lthat done n buildstream if it is achivable | 13:55 |
| saxa | and all that done in buildstream if it is achivable | 13:55 |
| saxa | https://sourceforge.net/p/dropline-gnome/code/HEAD/tree/dbs/branches/DLG_3_20/ | 13:56 |
| saxa | ^^ here is the scripts and build system I used for building gnome 3.20 | 13:57 |
| saxa | which is the last one I build up. | 13:57 |
| saxa | https://sourceforge.net/p/dropline-gnome/code/HEAD/tree/dbs/branches/DLG_3_20/etc/compile-order | 13:57 |
| saxa | ^^ this is the compile order file, which if you issue ./dbs build_all you get the gnome installed on your slackware and the packages in txz format in the /tmp/DLG/packages dir. | 13:59 |
| saxa | so basically i would like to achieve the same goal but with buildstream. | 13:59 |
| saxa | now in the scripts dir you have the build scripts, changelog, description file and patches needed for each individual package. | 14:01 |
| ssam2 | right; so if you want to reuse the upstream project that will need to change a bit | 14:19 |
| ssam2 | patches are a tricky one; obviously the best approach is to upstream them :-) otherwise you'll need to duplicate the element in your own project so that it builds your way | 14:20 |
| *** semanticdesign has joined #buildstream | 14:20 | |
| ssam2 | overriding configure options might be something we need to think about ... | 14:20 |
| ssam2 | as i guess you won't always the upstream configure options | 14:21 |
| ssam2 | the changelog and description for each one would go in your downstream element | 14:21 |
| ssam2 | the best person to discuss this with is tristan, but i think he's travelling the next few days | 14:21 |
| ssam2 | maybe you could start a thread on to buildstream-list@gnome.org | 14:22 |
| saxa | ssam2: ok, I can leave without the ChangeLog file , but description have to be done for each package, otherwise the package | 14:26 |
| saxa | is not 100% correct | 14:26 |
| saxa | although slackware tools wont complain. | 14:26 |
| saxa | for the patches there must be a way to apply them since many times gnome does not think in the way slackware does and some things needs to be heavily patched to get built | 14:27 |
| ssam2 | sounds like you'll need to maintain a fork of the upstream build instructions in that case | 14:28 |
| ssam2 | which shouldn't be too hard, everything is in Git after all | 14:28 |
| saxa | I will first try to play a bit with build stream and try to install it and build some sources to see how it works in practice | 14:28 |
| saxa | then i can have a good idea if it is worth investing time and work in that direction. | 14:29 |
| ssam2 | sounds good | 14:29 |
| saxa | i will subscribe to the buildstream ML too. | 14:30 |
| saxa | thanks for now for your good intro and help | 14:30 |
| saxa | ok see ya soon, bye | 14:39 |
| *** mcatanzaro has joined #buildstream | 14:39 | |
| *** semanticdesign has quit IRC | 14:45 | |
| tlater | If I understand asyncio correctly, we can never run anything using it in any context outside of the scheduler? | 14:50 |
| * tlater wanted to launch shell commands for event hooks using it so we don't block the main thread with user commands | 14:51 | |
| ssam2 | there needs to be some kind of main loop running for it to work | 14:53 |
| ssam2 | multiprocessing might be your friend there | 14:53 |
| tlater | ssam2: Yeah, that was my first solution, but unfortunately it seems that my processes get killed if buildstream finishes just before them | 14:54 |
| ssam2 | ouch | 14:54 |
| ssam2 | maybe some magic flag you can set, or something you could run on cleanup to check they have finished ? | 14:55 |
| tlater | I didn't see any magic flags, but the latter should be possible | 14:55 |
| * tlater will go for that and see how much it adds | 14:55 | |
| *** bochecha has quit IRC | 15:25 | |
| *** mcatanzaro has quit IRC | 15:38 | |
| gitlab-br-bot | push on buildstream@132-loading-external-plugins-works-without-explicit-requirement-in-project-conf (by Jonathan Maw): 2 commits (last: Make external plugin loading require explicit configuration in project.conf) https://gitlab.com/BuildStream/buildstream/commit/0cf9d2ccd3253d5c3bf77760d62308b4b4c5080e | 15:39 |
| gitlab-br-bot | buildstream: merge request (132-loading-external-plugins-works-without-explicit-requirement-in-project-conf->master: WIP: Resolve "Loading external plugins works without explicit requirement in project.conf") #125 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/125 | 15:39 |
| jjardon[m] | Hi, would | 16:22 |
| jjardon[m] | config: | 16:23 |
| jjardon[m] | configure-commands: | 16:23 |
| jjardon[m] | - %{configure} --enable-foo | 16:23 |
| jjardon[m] | be valid using autotools build system? | 16:23 |
| jjardon[m] | or I have to manually write down: https://gitlab.com/BuildStream/buildstream/blob/master/buildstream/plugins/elements/autotools.yaml#L18 | 16:24 |
| ssam2 | depends if anything defines %{configure} | 16:28 |
| ssam2 | looks like %{conf-cmd} is actually what you should use | 16:28 |
| ssam2 | ah, no, %{configure} is defined lower down | 16:28 |
| ssam2 | so yeah that should work. does it not ? | 16:28 |
| ssam2 | assuming your element is of kind 'autotools' of course | 16:29 |
| jjardon[m] | ok thanks, only wanted to confirm as the def2bst conversion script doesnt do that | 16:35 |
| jjardon[m] | (using %{configure}) | 16:35 |
| *** bethw has quit IRC | 16:49 | |
| *** tpollard has quit IRC | 16:52 | |
| *** ssam3 has joined #buildstream | 17:00 | |
| *** tiagogomes has quit IRC | 17:01 | |
| *** ssam2 has quit IRC | 17:01 | |
| *** mcatanzaro has joined #buildstream | 17:04 | |
| *** ssam3 has quit IRC | 17:57 | |
| *** ssam3 has joined #buildstream | 17:57 | |
| *** ssam3 has quit IRC | 18:19 | |
| *** jonathanmaw has quit IRC | 18:35 | |
| *** jonathanmaw has joined #buildstream | 18:36 | |
| *** jonathanmaw has quit IRC | 18:37 | |
| *** valentind has joined #buildstream | 18:54 | |
| gitlab-br-bot | buildstream: merge request (fix-compose-delete-with-symlink-in-path->master: Remove non canonical path from manifest after integration commands in compose plugin.) #161 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/161 | 18:56 |
| *** mcatanzaro has quit IRC | 19:32 | |
| *** bochecha has joined #buildstream | 19:35 | |
| *** cs_shadow has quit IRC | 21:04 | |
| gitlab-br-bot | buildstream: merge request (lzip->master: Add support for lzip in tar source) #162 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/162 | 21:22 |
| *** tristan has joined #buildstream | 21:22 | |
| valentind | tristan, where can I get the integration tests? | 21:24 |
| valentind | A test failed, I would like to run it locally to see what is happening. | 21:25 |
| valentind | Ah sorry. | 21:25 |
| valentind | Did not see it was in the same repository. | 21:26 |
| *** xtq has joined #buildstream | 22:29 | |
| xtq | CALL 415-349-5666 L0DE RADIO HOUR | 22:29 |
| xtq | https://www.youtube.com/watch?v=DIZqYgaOchY | 22:29 |
| xtq | tristan bochecha valentind saxa jude juergbi ironfoot brlogger persia ptomato[m] waltervargas[m] mrmcq2u[m] mattiasb kailueke[m] cgmcintyre[m] jjardon[m] benbrown pro[m] inigomartinez csoriano gitlab-br-bot hergertme tlater nexus paulsherwood laurenceurhegyi | 22:29 |
| *** xtq has left #buildstream | 22:29 | |
| tristan | valentind, instead of the private _output_file(), thats what Plugin.call() is for: http://buildstream.gitlab.io/buildstream/buildstream.plugin.html#buildstream.plugin.Plugin.call | 22:31 |
| tristan | valentind, also, use utils.get_host_tool() in Plugin.preflight() to find a host tool, like here: https://gitlab.com/BuildStream/buildstream/blob/master/buildstream/plugins/sources/git.py#L249 | 22:33 |
| tristan | that will ensure that the user gets a nice error message at startup time (not after 40 mins of building), if ever the user needs lzip but doesnt have it | 22:34 |
| tristan | git plugin also uses Plugin.call() extensively (for reference) | 22:35 |
| tristan | for calling host tools, it also ensures the process suspend / resume / force terminate works well | 22:36 |
| tristan | as well as redirecting output to the appropriate log file | 22:36 |
| tristan | oh, but of course the .lz is special I guess (you only need utils.get_host_tool('lzip') if you're really gonna use it, which I guess you cant know from the `.lz` extension in the configured url | 22:39 |
| tristan | ) | 22:39 |
| tristan | s/you cant/you can | 22:40 |
| * tristan gets some sleep | 22:40 | |
| * tristan zzzzZZZZZZ | 22:40 | |
| *** valentind has quit IRC | 23:07 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!