3 ms·

> If the shipped source doesn't contain enough information to actually perform a build surely that's a straight-up GPL violation Package A's source code contai

by mjg59 11y ago

> If the shipped source doesn't contain enough information to actually perform a build surely that's a straight-up GPL violation Package A's source code contains some undefined behaviour that gcc 4.4 tolerates. The distribution upgrades to gcc 5.1 and the build now breaks, but nobody notices because no new version of Package A has been uploaded and so no new build has been performed. Is your position that it was in compliance with the GPL before the gcc transition, and in violation afterwards?

lmm 11y ago
No. If the package A developers when working on the code just use whatever version of gcc's installed and don't have any process then they're compliant (but dumb). But if they have a script, or even just a "building.txt" that says "install gcc 4.4 and set these environment variables, build is broken on 5.x, known issue", and they exclude that from their source distribution then they're in violation. They need to ship the preferred form for making modifications i.e. what they would use themselves or give to a new developer on their team. It's no different from the example of C source generated by a perl script (you can't ship the generated source, you have to ship the original script), and it's exactly what's necessary for the four freedoms - end users need the same facilities that the original developers have when working on the code, not a watered-down version.
- mjg59 11y ago
  > But if they have a script, or even just a "building.txt" that says "install gcc 4.4 and set these environment variables, build is broken on 5.x, known issue", and they exclude that from their source distribution then they're in violation. They don't.
  - lmm 11y ago
    Really? They being Canonical? They just build their binaries with whatever happens to be installed on Bob's machine this week and then that becomes their official release?
    - mjg59 11y ago
      They build their packages with whatever is in the distribution at the time, yes. It happens on the build daemons rather than on the developer machine.
      - lmm 11y ago
        Then how can you get into the situation that the shipped binary packages can't be built with the shipped toolchain or shipped dependencies - isn't that what the build daemons do, use the system to build itself? I mean if they use the previous release or something that's fine too. Whichever way they do it, surely it's documented internally, because it's the kind of thing developers would need to know when developing. I can't believe it would be a case of "if the build doesn't build ssh into the build daemons and update them until it does". I mean a developer working at Canonical, trying to make a change to one of the packages they're preparing for distribution, has to have some way to answer the question "what version of gcc is being used to build this package". Whether that information is kept in the source tree, on their wiki, or on a post-it on the employee fridge - in any case, it's part of the source in the preferred form for making modifications, because it's, well, part of what the employees use to make modifications.
        nkurz 11y ago
        Then how can you get into the situation that the shipped binary packages can't be built with the shipped toolchain or shipped dependencies I think that Matthew might be suggesting that not all packages are rebuilt with every release? A binary package might be compiled with GCC-4, then the distribution is upgraded to GCC-5, dropping GCC-4. If for some reason the package is not compatible with the new compiler, you would then be in a situation where the binary cannot be recreated from source without outside tools. Do you know if Canonical recompiles everything on each update to the toolchain?
        lmm 11y ago
        I have no specific knowledge about Canonical's processes. I'm just amazed that a serious software company in 2016 wouldn't have a reproducible build process for their primary product.

by mjg59 11y ago

lmm 11y ago

No. If the package A developers when working on the code just use whatever version of gcc's installed and don't have any process then they're compliant (but dumb). But if they have a script, or even just a "building.txt" that says "install gcc 4.4 and set these environment variables, build is broken on 5.x, known issue", and they exclude that from their source distribution then they're in violation. They need to ship the preferred form for making modifications i.e. what they would use themselves or give to a new developer on their team. It's no different from the example of C source generated by a perl script (you can't ship the generated source, you have to ship the original script), and it's exactly what's necessary for the four freedoms - end users need the same facilities that the original developers have when working on the code, not a watered-down version.

mjg59 11y ago
> But if they have a script, or even just a "building.txt" that says "install gcc 4.4 and set these environment variables, build is broken on 5.x, known issue", and they exclude that from their source distribution then they're in violation. They don't.
- lmm 11y ago
  Really? They being Canonical? They just build their binaries with whatever happens to be installed on Bob's machine this week and then that becomes their official release?
  - mjg59 11y ago
    They build their packages with whatever is in the distribution at the time, yes. It happens on the build daemons rather than on the developer machine.
    - lmm 11y ago
      Then how can you get into the situation that the shipped binary packages can't be built with the shipped toolchain or shipped dependencies - isn't that what the build daemons do, use the system to build itself? I mean if they use the previous release or something that's fine too. Whichever way they do it, surely it's documented internally, because it's the kind of thing developers would need to know when developing. I can't believe it would be a case of "if the build doesn't build ssh into the build daemons and update them until it does". I mean a developer working at Canonical, trying to make a change to one of the packages they're preparing for distribution, has to have some way to answer the question "what version of gcc is being used to build this package". Whether that information is kept in the source tree, on their wiki, or on a post-it on the employee fridge - in any case, it's part of the source in the preferred form for making modifications, because it's, well, part of what the employees use to make modifications.
      - nkurz 11y ago
        Then how can you get into the situation that the shipped binary packages can't be built with the shipped toolchain or shipped dependencies I think that Matthew might be suggesting that not all packages are rebuilt with every release? A binary package might be compiled with GCC-4, then the distribution is upgraded to GCC-5, dropping GCC-4. If for some reason the package is not compatible with the new compiler, you would then be in a situation where the binary cannot be recreated from source without outside tools. Do you know if Canonical recompiles everything on each update to the toolchain?
        lmm 11y ago
        I have no specific knowledge about Canonical's processes. I'm just amazed that a serious software company in 2016 wouldn't have a reproducible build process for their primary product.