LogoopenSUSE Build Service > Request 245740
Sign Up | Log In

Request 245740 (revoked)

No description set

Submit package Base:System / grub2 (revision 108) to package openSUSE:Factory / grub2

The diff call for /source/Base:System/grub2?cmd=diff&expand=1&filelimit=10000&opackage=grub2&oproject=openSUSE%3AFactory&rev=108&view=xml&withissues=1 failed: bad link: conflict in file grub2.spec

There's nothing to be done right now

Request History

Michael Chang michael-chang created request about 2 years ago
Juergen ldig Weigert licensedigger Review got accepted about 2 years ago
{"approve": "license and version number unchanged: 2.02~beta2"} <!-- {
  "dest": {
    "ldb": {
      "review": "done", 
      "rpm_license": "{\"grub2.spec\":{\"%{grubefiarch}\":[\"GPL-3.0+\"],\"%{_target_cpu}-xen\":[\"GPL-3.0+\"],\"branding-upstream\":[\"GPL-3.0+\"],\"snapper-plugin\":[\"GPL-3.0+\"],\"grub2\":[\"GPL-3.0+\"],\"%{grubarch}\":[\"GPL-3.0+\"]}}", 
      "status": "production", 
      "version": "2.02~beta2"
    }, 
    "license": {
      "grub2.spec": {
        "%{_target_cpu}-xen": [
          "GPL-3.0+"
        ], 
        "%{grubarch}": [
          "GPL-3.0+"
        ], 
        "%{grubefiarch}": [
          "GPL-3.0+"
        ], 
        "branding-upstream": [
          "GPL-3.0+"
        ], 
        "grub2": [
          "GPL-3.0+"
        ], 
        "snapper-plugin": [
          "GPL-3.0+"
        ]
      }
    }, 
    "version": "2.02~beta2"
  }, 
  "hint": [], 
  "plugin": "0.61", 
  "src": {
    "auto-co": "/api.opensuse.org/Base:System/grub2%2.02~beta2%r108", 
    "kiwi_only": false, 
    "license": {
      "grub2.spec": {
        "%{_target_cpu}-xen": [
          "GPL-3.0+"
        ], 
        "%{grubarch}": [
          "GPL-3.0+"
        ], 
        "%{grubefiarch}": [
          "GPL-3.0+"
        ], 
        "branding-upstream": [
          "GPL-3.0+"
        ], 
        "grub2": [
          "GPL-3.0+"
        ], 
        "snapper-plugin": [
          "GPL-3.0+"
        ]
      }
    }, 
    "rev": "108", 
    "version": "2.02~beta2", 
    "version_diff": null
  }
} -->
Factory Auto factory-auto Request got a new review request about 2 years ago
Please review sources
Factory Auto factory-auto Request got a new review request about 2 years ago
Please review build success
Factory Auto factory-auto Request got a new review request about 2 years ago
Pick Staging Project
Factory Auto factory-auto Review got accepted about 2 years ago
Check script succeeded
Max Lin mlin7442 Request got a new review request about 2 years ago
Being evaluated by staging project "openSUSE:Factory:Staging:B"
Max Lin mlin7442 Review got accepted about 2 years ago
Picked openSUSE:Factory:Staging:B
Factory Repo Checker factory-repo-checker Review got accepted about 2 years ago
Builds for repo openSUSE:Factory:Staging:B/standard
Dominique Leuenberger dimstar Review got declined about 2 years ago
Please see
http://en.opensuse.org/openSUSE:Packaging_Patches_guidelines#Patch_live_cycle

=> Added / removed patches need to be mentioned by name in .changes, in
order to get a full trail of life cycles.

Actually, the guideline already clearly states:
Patches need to be added to packages for various reasons and it is important that the life cycle of a patch is well-defined. This helps in preventing that patches get "lost" and nobody knows why and when it was removed. The life cycle is defined in these simple steps:

    Patch added to the package
    Patch is modified (functional/rebased)
    Patch is disabled (but not deleted)
    Patch removed from the package

The middle stages of the patch life cycle are optional and not every patch will live through them.

Any of those stages needs to be mentioned in the .changes file, including the file name of the patch. This is only for the benefit of human readers, so does not need to be in a strict machine-parseable format; 
Dominique Leuenberger dimstar Request got declined about 2 years ago
Please see
http://en.opensuse.org/openSUSE:Packaging_Patches_guidelines#Patch_live_cycle

=> Added / removed patches need to be mentioned by name in .changes, in
order to get a full trail of life cycles.

Actually, the guideline already clearly states:
Patches need to be added to packages for various reasons and it is important that the life cycle of a patch is well-defined. This helps in preventing that patches get "lost" and nobody knows why and when it was removed. The life cycle is defined in these simple steps:

    Patch added to the package
    Patch is modified (functional/rebased)
    Patch is disabled (but not deleted)
    Patch removed from the package

The middle stages of the patch life cycle are optional and not every patch will live through them.

Any of those stages needs to be mentioned in the .changes file, including the file name of the patch. This is only for the benefit of human readers, so does not need to be in a strict machine-parseable format; 
Michael Chang michael-chang Request got revoked almost 2 years ago
ok

Comments for request 245740 (1)

Dominique Leuenberger dimstar wrote about 2 years ago

+#%patch110 -p1 +#%patch111 -p1

I would very much like to see this documented - making CLEAR that the patch is no longer applied from this moment forward