Buildroot:DeveloperDaysELCE2012 - Revision history

Arnout Vandecappelle: /* Report of the meeting */

2012-11-04T19:26:30Z

‎Report of the meeting

Arnout Vandecappelle: /* Report of the meeting */

2012-11-04T18:56:01Z

‎Report of the meeting

Arnout Vandecappelle: /* Report of the meeting */

2012-11-04T18:20:21Z

‎Report of the meeting

Arnout Vandecappelle: /* Report of the meeting */

2012-11-04T17:37:10Z

‎Report of the meeting

Arnout Vandecappelle: /* Report of the meeting */

2012-11-04T17:24:52Z

‎Report of the meeting

Arnout Vandecappelle: /* Report of the meeting */

2012-11-04T17:09:47Z

‎Report of the meeting

Arnout Vandecappelle: /* Report of the meeting */

2012-11-04T16:44:47Z

‎Report of the meeting

Arnout Vandecappelle: /* Report of the meeting */

2012-11-04T16:31:12Z

‎Report of the meeting

Arnout Vandecappelle: /* Report of the meeting */

2012-11-04T12:29:58Z

‎Report of the meeting

Arnout Vandecappelle at 10:37, 4 November 2012

2012-11-04T10:37:48Z

@@ Line 69: / Line 69: @@
 # target-clean: purpose is to rebuild the target tree, without rebuilding all packages. The problem is that this looks as if packages are really removed, but there may still be dependencies hidden in the built packages so that the resulting target doesn't work anymore.  One idea is to just not have a target dir anymore, but instead reconstruct it from the staging dir every time the fs is built.  But this is too much overhead in the usual case.  Basically, we prefer to have people do a full make clean if they change anything.  We should update the documentation to explain that this is necessary.  There was an idea to remove the entire target tree, and just regenerate it on every build.  This would simplify the .mk files because for most packages there's no need for INSTALL_TARGET_CMDS anymore (some packages still want to remove stuff), and implicitly does a target-clean (because there is no target dir to begin with), but only for the use case of skeleton changes.  In the end, the conclusion was that we don't want to support target-clean, but we'll document why not.
 # Regarding out-of-buildroot-tree project stuff: we don't really want to advertise keeping stuff outside of the buildroot tree.  Any patches that make that easier will be rejected. But it would be nice to store the result of xxx-menuconfig back to the place where it came from, or warn if that place doesn't exist.
 === Participants ===

@@ Line 33: / Line 33: @@
 * Ask Yann for help regarding the comments in the AVAILABLE framework.
 * Document better that you need to do make clean; make instead of make target-clean.
 ==== Details of the discussion ====
@@ Line 66: / Line 68: @@
 #* multiple licenses: we don't want to make things very complex.  It doesn't have to be machine-readable (we don't need to support machine analysis of the license field), so we don't have to formally decide how the license text must be written.  It does make sense to have some convention, though.  Proposal: "GPLv2+ or BSD-2c for the library, GPLv2+ for the dtc executable".
 # target-clean: purpose is to rebuild the target tree, without rebuilding all packages. The problem is that this looks as if packages are really removed, but there may still be dependencies hidden in the built packages so that the resulting target doesn't work anymore.  One idea is to just not have a target dir anymore, but instead reconstruct it from the staging dir every time the fs is built.  But this is too much overhead in the usual case.  Basically, we prefer to have people do a full make clean if they change anything.  We should update the documentation to explain that this is necessary.  There was an idea to remove the entire target tree, and just regenerate it on every build.  This would simplify the .mk files because for most packages there's no need for INSTALL_TARGET_CMDS anymore (some packages still want to remove stuff), and implicitly does a target-clean (because there is no target dir to begin with), but only for the use case of skeleton changes.  In the end, the conclusion was that we don't want to support target-clean, but we'll document why not.
+# Regarding out-of-buildroot-tree project stuff: we don't really want to advertise keeping stuff outside of the buildroot tree.  Any patches that make that easier will be rejected. But it would be nice to store the result of xxx-menuconfig back to the place where it came from, or warn if that place doesn't exist.
-For tomorrow:
-* Support for board stuff outside the buildroot tree. Proposed by Arnout Vandecappelle
 === Participants ===

@@ Line 32: / Line 32: @@
 * Samuel merges documentation patches and sends pull requests to Peter.
 * Ask Yann for help regarding the comments in the AVAILABLE framework.
 ==== Details of the discussion ====
@@ Line 64: / Line 65: @@
 #* split _LICENSE and _REDISTRIBUTE: patch proposed by Luca is accepted. Even though there is no proprietary package in buildroot that triggers the feature, if it fails to work as expected the user will hopefully report it.
 #* multiple licenses: we don't want to make things very complex.  It doesn't have to be machine-readable (we don't need to support machine analysis of the license field), so we don't have to formally decide how the license text must be written.  It does make sense to have some convention, though.  Proposal: "GPLv2+ or BSD-2c for the library, GPLv2+ for the dtc executable".
-# target-clean: purpose is to rebuild the target tree, without rebuilding all packages. The problem is that this looks as if packages are really removed, but there may still be dependencies hidden in the built packages so that the resulting target doesn't work anymore.  One idea is to just not have a target dir anymore, but instead reconstruct it from the staging dir every time the fs is built.  But this is too much overhead in the usual case.  Basically, we prefer to have people do a full make clean if they change anything.  We should update the documentation to explain that this is necessary.
+# target-clean: purpose is to rebuild the target tree, without rebuilding all packages. The problem is that this looks as if packages are really removed, but there may still be dependencies hidden in the built packages so that the resulting target doesn't work anymore.  One idea is to just not have a target dir anymore, but instead reconstruct it from the staging dir every time the fs is built.  But this is too much overhead in the usual case.  Basically, we prefer to have people do a full make clean if they change anything.  We should update the documentation to explain that this is necessary.  There was an idea to remove the entire target tree, and just regenerate it on every build.  This would simplify the .mk files because for most packages there's no need for INSTALL_TARGET_CMDS anymore (some packages still want to remove stuff), and implicitly does a target-clean (because there is no target dir to begin with), but only for the use case of skeleton changes.  In the end, the conclusion was that we don't want to support target-clean, but we'll document why not.
 For tomorrow:
 * Support for board stuff outside the buildroot tree. Proposed by Arnout Vandecappelle

@@ Line 64: / Line 64: @@
 #* split _LICENSE and _REDISTRIBUTE: patch proposed by Luca is accepted. Even though there is no proprietary package in buildroot that triggers the feature, if it fails to work as expected the user will hopefully report it.
 #* multiple licenses: we don't want to make things very complex.  It doesn't have to be machine-readable (we don't need to support machine analysis of the license field), so we don't have to formally decide how the license text must be written.  It does make sense to have some convention, though.  Proposal: "GPLv2+ or BSD-2c for the library, GPLv2+ for the dtc executable".
-# target-clean: purpose is to rebuild the target tree, without rebuilding all packages. The problem is that this looks as if packages are really removed, but there may still be dependencies hidden in the built packages so that the resulting target doesn't work anymore.  One idea is to just not have a target dir anymore, but instead reconstruct it from the staging dir every time the fs is built.  But this is too much overhead in the usual case.
+# target-clean: purpose is to rebuild the target tree, without rebuilding all packages. The problem is that this looks as if packages are really removed, but there may still be dependencies hidden in the built packages so that the resulting target doesn't work anymore.  One idea is to just not have a target dir anymore, but instead reconstruct it from the staging dir every time the fs is built.  But this is too much overhead in the usual case.  Basically, we prefer to have people do a full make clean if they change anything.  We should update the documentation to explain that this is necessary.
 For tomorrow:

@@ Line 31: / Line 31: @@
 * Move download helpers to a script.
 * Samuel merges documentation patches and sends pull requests to Peter.
 ==== Details of the discussion ====
@@ Line 63: / Line 64: @@
 #* split _LICENSE and _REDISTRIBUTE: patch proposed by Luca is accepted. Even though there is no proprietary package in buildroot that triggers the feature, if it fails to work as expected the user will hopefully report it.
 #* multiple licenses: we don't want to make things very complex.  It doesn't have to be machine-readable (we don't need to support machine analysis of the license field), so we don't have to formally decide how the license text must be written.  It does make sense to have some convention, though.  Proposal: "GPLv2+ or BSD-2c for the library, GPLv2+ for the dtc executable".
 For tomorrow:
 * Make it possible to do a 'target-clean', as a replacement of uninstall. Will this even work at all? Proposed by Arnout Vandecappelle
 * Support for board stuff outside the buildroot tree. Proposed by Arnout Vandecappelle

@@ Line 39: / Line 39: @@
 # Documentation on target: if you need this, use a distro.  So we remove it.
 # We need to explain in the documentation why we removed this stuff.
-# Available stuff: i.e. solve the problem of combination of ''select'' and ''depends''. Solving it in Kconfig itself seems to be difficult: there were some patches but the kconfig people didn't like it; Yann and Thomas looked at Kconfig and it looks difficult to modify.  The AVAILABLE solution has two problems: it adds verbosity, and the recursive dependencies still should be written in the comments ("libfoo requires WCHAR in the toolchain").  The verbosity is not considered a big issue.  For the comments: they currently don't work perfectly either.  Removing the comments altogether is an option, but then it is difficult for users to find out why a certain package isn't available.  Another possibility is to list the available packages in the documentation (automatically), and mention which toolchain dependencies they have.  Wild idea: consider Config.in as a low-level language, and define our own higher-level language from which we generate Config.in.  Alternatively, have a developer tool that verifies if everything is consistent (i.e. are the comments correct).  One more option: add a big comment in the beginning of the packages list, which says that not all toolchain options are available so not all packages are visible.  Converting the toolchain options from ''depends'' to ''select'' is not really an option, because changing toolchain options requires a make clean.  We didn't reach a conclusion, we'll come back to it tomorrow.
+# Available stuff: i.e. solve the problem of combination of ''select'' and ''depends''. Solving it in Kconfig itself seems to be difficult: there were some patches but the kconfig people didn't like it; Yann and Thomas looked at Kconfig and it looks difficult to modify.  The AVAILABLE solution has two problems: it adds verbosity, and the recursive dependencies still should be written in the comments ("libfoo requires WCHAR in the toolchain").  The verbosity is not considered a big issue.  For the comments: they currently don't work perfectly either.  Removing the comments altogether is an option, but then it is difficult for users to find out why a certain package isn't available.  Another possibility is to list the available packages in the documentation (automatically), and mention which toolchain dependencies they have.  Wild idea: consider Config.in as a low-level language, and define our own higher-level language from which we generate Config.in.  Alternatively, have a developer tool that verifies if everything is consistent (i.e. are the comments correct).  One more option: add a big comment in the beginning of the packages list, which says that not all toolchain options are available so not all packages are visible.  Converting the toolchain options from ''depends'' to ''select'' is not really an option, because changing toolchain options requires a make clean.<br/>After more discussion on Sunday, we didn't find a solution. For the time being, we stick to the old system. We ask Yann if he has a brilliant idea of how to deal with the comments.
 # kconfig-frontend: Yann now has a repository for Kconfig, it would be nice to branch our Kconfig from that.  The idea is to still copy it to our repository.
 # BUSYBOX_SHOW_OTHERS: the only reason to have this is to avoid newcomers enabling things like tar etc. which are anyway already in busybox.  But for the web servers, they are clearly different from the busybox web servers (and our default busybox config doesn't even enable a web server).  Also bash is a typical one, because people write bashisms in their scripts.  This discussion is somewhat related to the discussion how to handle packages that provide the same functionality.  But for many packages, it's not even the same (httpd, bash, vim).  But actually, we're trying to solve a non-existent problem here - except for the web servers.  If we generate a list of packages in the documentation, we can add a remark to that that it's also available in busybox.  Also move the condition inside the package Config.in instead of outside and make it a ''depends on'', so it is more visible.

@@ Line 30: / Line 30: @@
 * Automate selection of correct FP and other compiler options based on subarchitecture.
 * Move download helpers to a script.
 ==== Details of the discussion ====
@@ Line 57: / Line 58: @@
 # Community organization:
 #* It can be useful to have subsystem maintainers, that are responsible for reviewing and accepting patches.  In practice, however, it is difficult to split things in a way that we don't risk duplicating work (i.e. two people in the process of merging the same patch).  However, one clearly defined subsystem is the documentation.  From now on, Samuel Martin is responsible for all documentation patches.  He'll send pull requests to Peter.
-#* Patches should be accepted more aggressively, even if there hasn't been (much) testing of the patch.  The autobuilders will catch any issues.  However, it is still important to properly review and comment on coding style issues (i.e. how the features are implemented.
+#* Patches should be accepted more aggressively, even if there hasn't been (much) testing of the patch.  The autobuilders will catch any issues.  However, it is still important to properly review and comment on coding style issues (i.e. how the features are implemented.  Also, if something really breaks the autobuilder, Thomas can revert it without consulting Peter.
 # Out of tree build: this is a feature that people keep on asking. It is particularly useful for packages with an OVERRIDE_SRCDIR.  But of course, not all packages support out-of-tree build, and not all packages support it in the same way.  For autotools and cmake, it can be automatic; for generic packages, it has to be signalled if out-of-tree build is available.
 For tomorrow:
 * The _AVAILABLE mechanism, and how to properly handle dependency on toolchain options (discuss the proposal made by Yann E. Morin). Proposed by [[User:ThomasPetazzoni]].
 * Discuss (and, if approved, implement) the split between _LICENSE and _REDISTRIBUTE for legal-info. I think this won't take much more than 10 minutes chat + 10 minutes hack. Proposed by Luca Ceresoli.

@@ Line 41: / Line 41: @@
 # kconfig-frontend: Yann now has a repository for Kconfig, it would be nice to branch our Kconfig from that.  The idea is to still copy it to our repository.
 # BUSYBOX_SHOW_OTHERS: the only reason to have this is to avoid newcomers enabling things like tar etc. which are anyway already in busybox.  But for the web servers, they are clearly different from the busybox web servers (and our default busybox config doesn't even enable a web server).  Also bash is a typical one, because people write bashisms in their scripts.  This discussion is somewhat related to the discussion how to handle packages that provide the same functionality.  But for many packages, it's not even the same (httpd, bash, vim).  But actually, we're trying to solve a non-existent problem here - except for the web servers.  If we generate a list of packages in the documentation, we can add a remark to that that it's also available in busybox.  Also move the condition inside the package Config.in instead of outside and make it a ''depends on'', so it is more visible.
-# packages with multiple variants: python2/3, Qt4/5, gtk2/3, ...  This is again similar to the expat/libxml2 issue.  Do we support both python2 and python3? We need to support both versions in most cases. Question is if we want to force that only one of the two is selected, or do we support side-by-side installation.  Conclusion: has to be looked at on a case-by-case basis.  General philosophy: don't try to be too smart, so don't try to force selecting only one of the two if it doesn't make sense to have both.  In cases where a package wants to ''select'' one of these things, convert the ''select'' into a ''depends'' with a comment.
+# packages with multiple variants: python2/3, Qt4/5, gtk2/3, gstreamer0.10/1.0...  This is again similar to the expat/libxml2 issue.  Do we support both python2 and python3? We need to support both versions in most cases. Question is if we want to force that only one of the two is selected, or do we support side-by-side installation.  Conclusion: has to be looked at on a case-by-case basis.  General philosophy: don't try to be too smart, so don't try to force selecting only one of the two if it doesn't make sense to have both.  In cases where a package wants to ''select'' one of these things, convert the ''select'' into a ''depends'' with a comment.  For gstreamer, the complexity of having the two side-by-side is unacceptable, because there are so many fine-grained gstreamer configure options (in the plugins).  However, we expect that everything will move to gstreamer1.0 quite quickly, so for the time being (and only if someone needs it), we can live with a non-perfect solution that just fits the requirements of whoever needs gstreamer1.0.
 # multiple packages providing the same functionality: lua/luajit, jpeg/jpegturbo, expat/libxml2.  These cannot be installed side-by-side, and many packages select e.g. jpeg.  OpenGL will have this issue as well.  A relatively clean solution is to create virtual packages for these, where the user has a choice between the two.  The normal config option would be hidden for these packages.  This still adds complexity in some corner cases, e.g. some package that doesn't work in luajit, but that can probably be solved at the level of that package.
 # Autobuild infrastructure. Thomas is working on scripts that parse the build result and put it in a database.  One important missing feature at the moment is visibility of evolution over time (i.e. distinguish regressions from recurring problems).  Even more important is just being able to see which packages are failing all the time, i.e. for each package how often it failed.  Ideally, we would also want to see how often a package has been built successfully, but when is it successful? Does the entire build have to succeed or that package?  Overall, however, the autobuild infrastructure is considered very useful - when something is wrong, it appears in the autobuild very quickly.