Hi everybody,
I would like to propose that we create todos for rebuilds of language specific packages.
We had two major rebuilds in the last months: python3.8 and ruby2.7.
Can we agree that we create a todo before such rebuilds? The advantages outweigh the disadvantages. We would gain:
* More people help rebuilding the packages. * Every maintainer gets informed about the rebuild. * Maintainers have the possibility to test the packages.
If tools exist for creating todos, I would like to ask the persons with such tools to make them available for everybody (if not already happened).
Greetings, shibumi
On Fri, Jan 10, 2020, 16:43 Christian Rebischke via arch-dev-public < arch-dev-public@archlinux.org> wrote:
Hi everybody,
I would like to propose that we create todos for rebuilds of language specific packages.
We had two major rebuilds in the last months: python3.8 and ruby2.7.
Can we agree that we create a todo before such rebuilds? The advantages outweigh the disadvantages. We would gain:
Hi,
I'm not sure I understand. Can you clearly state the problems we've encountered due to not doing this? What downsides do you see to your proposal? Can you think of any alternative solutions?
* More people help rebuilding the packages.
Solving the wrong problem, IMO. This is largely toil and should be automated away. Foutrelis already has such a system that we've used for rebuilds in the past. We could/should instead work towards making this more generally available on the build machines.
* Every maintainer gets informed about the rebuild.
As a maintainer, I don't care that you're rebuilding my package to keep up with library changes. Rather, I'm thankful to whomever did this for me.
Why would a language rebuild differ from any other soname bump?
* Maintainers have the possibility to test the packages.
Why is this not currently possible? Couldn't we just use testing prior to pushing out to the repos (something we've done in the past and continue to do)? What about packages which aren't using the lowlevel API and are simply interpreted code. Those don't get rebuilt, but they're potentially impacted by the language version bump. They'll never be called out on a rebuild lost because we generate those based on ELF dependencies.
dR
If tools exist for creating todos, I would like to ask the persons with
such tools to make them available for everybody (if not already happened).
Greetings, shibumi
Hello
On Sat, Jan 11, 2020 at 6:58 AM Dave Reisner d@falconindy.com wrote:
On Fri, Jan 10, 2020, 16:43 Christian Rebischke via arch-dev-public < arch-dev-public@archlinux.org> wrote:
Hi everybody,
I would like to propose that we create todos for rebuilds of language specific packages.
We had two major rebuilds in the last months: python3.8 and ruby2.7.
Can we agree that we create a todo before such rebuilds? The advantages outweigh the disadvantages. We would gain:
Hi,
I'm not sure I understand. Can you clearly state the problems we've encountered due to not doing this? What downsides do you see to your proposal? Can you think of any alternative solutions?
- More people help rebuilding the packages.
Solving the wrong problem, IMO. This is largely toil and should be automated away.
I agree with every statement that Dave made. Especially with this one.
We need to automate as much our daily routine as possible. Scripting/automation is the only way to keep the increasing complexity of the system under control.
Adding more bureaucracy and putting more dumb manual work to the developers will certainly slow down the development process.
Foutrelis already has such a system that we've used for rebuilds in the past. We could/should instead work towards making this more generally available on the build machines.
I am a huge fan of this approach. I would really love to see the Foutrelis' rebuild machine available as a tool at my workstation.
- Every maintainer gets informed about the rebuild.
As a maintainer, I don't care that you're rebuilding my package to keep up with library changes. Rather, I'm thankful to whomever did this for me.
Why would a language rebuild differ from any other soname bump?
- Maintainers have the possibility to test the packages.
Did you have any problems with testing the recent language rebuilds? Could you please add more information how a todo list will fix it?
On 01/11/20 at 09:04am, Anatol Pomozov via arch-dev-public wrote:
Hello
On Sat, Jan 11, 2020 at 6:58 AM Dave Reisner d@falconindy.com wrote:
On Fri, Jan 10, 2020, 16:43 Christian Rebischke via arch-dev-public < arch-dev-public@archlinux.org> wrote:
Hi everybody,
I would like to propose that we create todos for rebuilds of language specific packages.
We had two major rebuilds in the last months: python3.8 and ruby2.7.
Can we agree that we create a todo before such rebuilds? The advantages outweigh the disadvantages. We would gain:
Hi,
I'm not sure I understand. Can you clearly state the problems we've encountered due to not doing this? What downsides do you see to your proposal? Can you think of any alternative solutions?
- More people help rebuilding the packages.
Solving the wrong problem, IMO. This is largely toil and should be automated away.
I agree with every statement that Dave made. Especially with this one.
Yes, we should make this rebuilder official in some way and properly document it so multiple people can use it.
Some languages however require special treatment such as Haskell and require rebuilds from GHC => Haskell-foo => Haskell-bar etc which can become complicated. For example if I want to update a dependency of taskell I will have to rebuild all depending programs/libs so tooling which makes that easier is welcome to me. I know Felix has some stuff but we should make this more visible.
I would propose to document how to rebuild a library/program on the Package Guidelines pages which I plan to do for Haskell after talking with Felix.
We need to automate as much our daily routine as possible. Scripting/automation is the only way to keep the increasing complexity of the system under control.
Yes!
As a maintainer, I don't care that you're rebuilding my package to keep up with library changes. Rather, I'm thankful to whomever did this for me.
Why would a language rebuild differ from any other soname bump?
For Haskell this is the case, but I am not sure if this is unique.
- Maintainers have the possibility to test the packages.
Did you have any problems with testing the recent language rebuilds?
We have never tested anything in [staging] where rebuilds happen since that's not possible at all since it's always half broken. Testing happens in [testing].
On 1/11/20 4:51 PM, Jelle van der Waa wrote:
Some languages however require special treatment such as Haskell and require rebuilds from GHC => Haskell-foo => Haskell-bar etc which can become complicated. For example if I want to update a dependency of taskell I will have to rebuild all depending programs/libs so tooling which makes that easier is welcome to me. I know Felix has some stuff but we should make this more visible.
Haskell is *not* different. Haskell is an excellent example of a language where problems can be caught by the person doing the rebuild, because it's all shared libraries which can be caught by our soname detection.
Sure, haskell is complex and fiddly and requires complex rebuilds for every trivial change, which requires complex orchestration to pull off, but the underlying cause isn't all that complex.
This thread was founded with the premise that language maintainers should not just do silent rebuilds, because package maintainers need to do it themselves in order to know the resulting packages work.
You're arguing instead, that it's fine for Haskell to be rebuilt automatically... but that we need to preserve valuable institutional knowledge on how the current maintainer handles this, to reduce the bus factor and, I guess, that if Felix retires no one will know how to rebuild haskell anymore. This is an important topic which deserves discussion about documenting HOWTOs, but is, I think, ultimately unrelated to and a distraction from, *this* thread.
On Sat, Jan 11, 2020 at 09:57:42AM -0500, Dave Reisner wrote:
On Fri, Jan 10, 2020, 16:43 Christian Rebischke via arch-dev-public <[1]arch-dev-public@archlinux.org> wrote:
Hi everybody, I would like to propose that we create todos for rebuilds of language specific packages. We had two major rebuilds in the last months: python3.8 and ruby2.7. Can we agree that we create a todo before such rebuilds? The advantages outweigh the disadvantages. We would gain:Hi, I'm not sure I understand. Can you clearly state the problems we've encountered due to not doing this? What downsides do you see to your proposal? Can you think of any alternative solutions?
Hi Dave, I am sorry. Looks like my actual proposal was a little bit unclear and the whole discussion drifted to automation. This has been never my intention.
I have no problem with the actual rebuild process and I don't care if this happens manually or automated. Actually I didn't want to point out specific package problems, but you asked me, here they are.
My problem is that several packages dependending on ruby broke due to the ruby2.7 rebuild:
* puppet5 broke due to missing ruby-sync in ruby2.7[1] * puppet broke due to missing ruby-sync in ruby2.7[2] * gitlab has problems with its API after ruby2.7 rebuild[3]
Furthermore multiple packages are throwing deprecation warnings now:
* gitlab[4] * puppet5/puppet [1][2] * vagrant has issues with the ruby2.7 rebuild[5]
Big thanks to Anatol for reporting several of these issues upstream and fixing packages. I really appreciate his work.
The rebuild process itself is totally fine for me. I just wanted to point out, that we should have a defined process for rebuilds. Either in form of todos or in form of more communication on a-d-p like "We are going to push all ruby rebuilds from [testing] to [community] on date X. Make sure it's tested, if you encounter any problems, speak with A, B or C or response directly in this thread".
* More people help rebuilding the packages.Solving the wrong problem, IMO. This is largely toil and should be automated away. Foutrelis already has such a system that we've used for rebuilds in the past. We could/should instead work towards making this more generally available on the build machines.
I agree.
* Every maintainer gets informed about the rebuild.As a maintainer, I don't care that you're rebuilding my package to keep up with library changes. Rather, I'm thankful to whomever did this for me. Why would a language rebuild differ from any other soname bump?
I mostly agree, still would be nice to get a notification.
* Maintainers have the possibility to test the packages.Why is this not currently possible? Couldn't we just use testing prior to pushing out to the repos (something we've done in the past and continue to do)? What about packages which aren't using the lowlevel API and are simply interpreted code. Those don't get rebuilt, but they're potentially impacted by the language version bump. They'll never be called out on a rebuild lost because we generate those based on ELF dependencies. dR
[testing] has been used and I wanted to test my packages, but the push from [testing] to [community] happened before my scheduled date for this. I just say that it would be nice if we have a defined process for rebuilds with specifying a deadline for tests.
My hope is that this mail makes my intention clear now. The "proposal" is just a spawn point for a discussion around a defined process for rebuilds to prevent not working packages in the future.
Arch Linux is known for bleeding edge software _and_ stability, let's keep it this way.
[1] https://bugs.archlinux.org/task/65106 [2] https://bugs.archlinux.org/task/65107 [3] https://bugs.archlinux.org/task/65097 [4] https://bugs.archlinux.org/task/64887#comment185125 [5] https://github.com/hashicorp/vagrant/issues/11290
On 13/01/2020 18.28, Christian Rebischke via arch-dev-public wrote:
[testing] has been used and I wanted to test my packages, but the push from [testing] to [community] happened before my scheduled date for this.
Have you raised this on the TU or staff channels before the move happened? Otherwise I don't find it surprising no one guessed your personal testing plan. Documented procedures are surely nice, proper communication is even better.
BP
On 1/10/20 4:42 PM, Christian Rebischke via arch-dev-public wrote:
Hi everybody,
I would like to propose that we create todos for rebuilds of language specific packages.
We had two major rebuilds in the last months: python3.8 and ruby2.7.
Can we agree that we create a todo before such rebuilds? The advantages outweigh the disadvantages. We would gain:
- More people help rebuilding the packages.'
What help is needed? If this is just about having more people sed the pkgrel variable with "$pkgrel + 1", then try to build it, more people doesn't actually help. We have automated rebuilders which are very capable in this regard.
- Every maintainer gets informed about the rebuild.
I agree with you that this is indeed a problem, and I would like to propose a pretty simple solution. Let's post on arch-dev-public to give people a heads-up.
This means even if your package failed to be detected for rebuilding and would never appear on any TODO, you as a maintainer know that it happened and can manually rebuild your package.
- Maintainers have the possibility to test the packages.
At least for the python rebuilds, the process of rebuilding the ecosystem is long and painfully drawn out, *because* packages with failing testsuites cannot be rebuilt automatically and go onto a TODO list of broken packages.
Given this thread started because we just rebuilt ruby, can I assume that PKGBUILDs for ruby packages are in the general habit of not containing check() functions for running unittests? Either because upstream does not have unittests or because they are not being run?
If packages have upstream unittests but don't run them, then the maintainer of the package has been derelict in his or her duty.
If packages do NOT have upstream unittests, then this is unfortunate, and I don't currently have an answer for what we should do. :(
If tools exist for creating todos, I would like to ask the persons with such tools to make them available for everybody (if not already happened).
It's a website submission form that expects you to write some explanatory message, then fill in a newline-separated list of pkgnames. Any rebuilder must by definition have the latter, even if that rebuilder is "I scrolled through archweb and did it all manually by flipping back and forth between my terminal and my browser".
No "tool for creating todos" need exist. Ask instead about tools for enumerating language dependencies.
...
For python, it's pretty simple.
pkgfile -d '/usr/lib/python3.8/'
For ruby, it's also pretty simple:
pkgfile -d '/usr/lib/ruby/'
Also sogrep to see if any packages link to the shared library libpython3.8 or libruby, but hey, that's what we already do for rebuilds of only 3 or 4 packages.
arch-dev-public@lists.archlinux.org