broken packages under certain circumstances
Hi, I noticed some packages being in state "Files could not be expanded: could not apply patch 'project.diff'" for no apparent reasons. Happened for graphics/blender, and now I noticed: https://build.opensuse.org/package/show/network:ha-clustering:Factory/drbd For blender, I fixed _link and superfluous files manually. Any idea, what this is about? Best, Pete
On 7/24/21 4:25 PM, Hans-Peter Jansen wrote:
Hi,
I noticed some packages being in state
"Files could not be expanded: could not apply patch 'project.diff'"
for no apparent reasons. Happened for graphics/blender, and now I noticed:
https://build.opensuse.org/package/show/network:ha-clustering:Factory/drbd
For blender, I fixed _link and superfluous files manually.
Any idea, what this is about?
The actual problem looks like a bug in the link handling, but for devel packages it's clearly recommended to use branches (i.e. call osc linktobranch on the blender package). Branches are less fragile. Greetings, Stephan
Am Samstag, 24. Juli 2021, 17:26:22 CEST schrieb Stephan Kulow:
On 7/24/21 4:25 PM, Hans-Peter Jansen wrote:
Hi,
I noticed some packages being in state
"Files could not be expanded: could not apply patch 'project.diff'"
for no apparent reasons. Happened for graphics/blender, and now I noticed:
https://build.opensuse.org/package/show/network:ha-clustering:Factory/drbd
For blender, I fixed _link and superfluous files manually.
Any idea, what this is about?
The actual problem looks like a bug in the link handling, but for devel packages it's clearly recommended to use branches (i.e. call osc linktobranch on the blender package). Branches are less fragile.
Hi Stephan, thanks for the hint. This reveals two further questions: * should I create a GH issue? * can you point me to a package, that uses a branch for development Cheers, Pete
On 7/24/21 6:27 PM, Hans-Peter Jansen wrote:
Hi Stephan, thanks for the hint. This reveals two further questions: * should I create a GH issue?
If there was no conflicting edits happening in between accepting requests, then yes. This is something OBS handled previously - only if devel project "moved on" after creating the request, it became a conflict.
* can you point me to a package, that uses a branch for development I would say all of them - branch is the default, link is only used nowadays for packages following another project without changes on their own.
E.g. https://build.opensuse.org/package/view_file/graphics/GraphicsMagick/_link?e... Greetings, Stephan
Am Sonntag, 25. Juli 2021, 09:57:21 CEST schrieb Stephan Kulow:
On 7/24/21 6:27 PM, Hans-Peter Jansen wrote:
Hi Stephan, thanks for the hint. This reveals two further questions: * should I create a GH issue?
If there was no conflicting edits happening in between accepting requests, then yes. This is something OBS handled previously - only if devel project "moved on" after creating the request, it became a conflict.
* can you point me to a package, that uses a branch for development
I would say all of them - branch is the default, link is only used nowadays for packages following another project without changes on their own.
E.g. https://build.opensuse.org/package/view_file/graphics/GraphicsMagick/_link?e xpand=0
Well, I encountered a related issue today: https://build.opensuse.org/package/show/graphics/OpenImageIO After Richard accepted this two days ago, it got into broken state (cannot apply project.diff). Then I did: $ osc co OpenImageIO A OpenImageIO The link in this package ("OpenImageIO") is currently broken. Checking out the last working version instead; please use 'osc pull' to merge the conflicts. A OpenImageIO/OpenImageIO.changes A OpenImageIO/OpenImageIO.spec A OpenImageIO/oiio-2.2.17.0.tar.gz At revision 1156a706433cf7db5a395886e397886d. $ osc linktobranch Server returned an error: HTTP Error 400: Bad Request could not apply patch 'project.diff' At this point, I repaired the package the usual way: edit _link to remove the outdated operations in <patches/>, and deleted the superfluous files oiio-2.2.17.0.tar.gz and project.diff. All fine at this point. Now it gets interesting. $ osc linktobranch A oiio-2.2.13.1.tar.gz D oiio-2.2.17.0.tar.gz U OpenImageIO.changes U OpenImageIO.spec At revision ab911349e5c10e0ed87bfead12463e40. Ouch. WTH. Even more interesting: OBS is fine at this point. Checking out the package again, we're back to business: $ osc co OpenImageIO A OpenImageIO A OpenImageIO/OpenImageIO.changes A OpenImageIO/OpenImageIO.spec A OpenImageIO/oiio-2.2.17.0.tar.gz At revision 6b19bc6e405bbb1205749f8e21f5f607. The linktobranch side effect puzzles me. Cheers, Pete
Hi, On 2021-08-18 11:06:49 +0200, Hans-Peter Jansen wrote:
Am Sonntag, 25. Juli 2021, 09:57:21 CEST schrieb Stephan Kulow:
On 7/24/21 6:27 PM, Hans-Peter Jansen wrote:
Hi Stephan, thanks for the hint. This reveals two further questions: * should I create a GH issue?
If there was no conflicting edits happening in between accepting requests, then yes. This is something OBS handled previously - only if devel project "moved on" after creating the request, it became a conflict.
* can you point me to a package, that uses a branch for development
I would say all of them - branch is the default, link is only used nowadays for packages following another project without changes on their own.
E.g. https://build.opensuse.org/package/view_file/graphics/GraphicsMagick/_link?e xpand=0
Well, I encountered a related issue today:
https://build.opensuse.org/package/show/graphics/OpenImageIO
After Richard accepted this two days ago, it got into broken state (cannot apply project.diff).
Then I did:
$ osc co OpenImageIO A OpenImageIO
The link in this package ("OpenImageIO") is currently broken. Checking out the last working version instead; please use 'osc pull' to merge the conflicts.
A OpenImageIO/OpenImageIO.changes A OpenImageIO/OpenImageIO.spec A OpenImageIO/oiio-2.2.17.0.tar.gz At revision 1156a706433cf7db5a395886e397886d.
At this point, your local package working copy is "frozen" and you have to use "osc pull" to "resolve" the conflicts or you can also checkout the unexpanded sources (osc up -u) and manually "fix" the _link file.
$ osc linktobranch Server returned an error: HTTP Error 400: Bad Request could not apply patch 'project.diff'
At this point, I repaired the package the usual way: edit _link to remove the outdated operations in <patches/>, and deleted the superfluous files oiio-2.2.17.0.tar.gz and project.diff.
Via osc?
All fine at this point. Now it gets interesting.
$ osc linktobranch A oiio-2.2.13.1.tar.gz D oiio-2.2.17.0.tar.gz U OpenImageIO.changes U OpenImageIO.spec At revision ab911349e5c10e0ed87bfead12463e40.
Ouch. WTH.
Your working copy is still frozen. I guess it makes sense if the linktobranch command also "unfreezes" your package working copy. I have to think about it again...
Even more interesting: OBS is fine at this point. Checking out the package again, we're back to business:
$ osc co OpenImageIO A OpenImageIO A OpenImageIO/OpenImageIO.changes A OpenImageIO/OpenImageIO.spec A OpenImageIO/oiio-2.2.17.0.tar.gz At revision 6b19bc6e405bbb1205749f8e21f5f607.
The linktobranch side effect puzzles me.
Yes... from a user's POV this is highly confusing:/ Marcus
On Jul 24 2021, Hans-Peter Jansen wrote:
Any idea, what this is about?
If you want to avoid that in the future, convert the link to a branch. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
participants (4)
-
Andreas Schwab -
Hans-Peter Jansen -
Marcus Hüwe -
Stephan Kulow