Le ven. 16 févr. 2024 à 04:03, Mathias Gibbens <
gibmat@debian.org> a écrit :
On Thu, 2024-02-15 at 16:20 -0800, Loren M. Lang wrote:
Hello,
I recently had a package sponsors and entered into unstable called tiv.
It can be seen here:
https://packages.debian.org/sid/tiv
Everything went OK, but I see that the amd64 arch package appears to
have been re-built for some reason. It's version is showing up with a
+b1. I am curious if there is some long to indicate what the issue might have been that led to a rebuild. Could there have been a compilation
issue or other things I should be concerned about or is it likely
something harmless? Is there a log for this case?
There's no cause for concern -- it's a normal part of a new package entering the archive.
Indeed...
When a package is uploaded to NEW, you have to upload both the source
and binary package(s) for review. After the package is accepted, the
buildds auto-build for any other architectures that don't already have
a binary package. Migration policy requires all packages to be built on official buildds from their source package[1]. Since the amd64 binary
package already existed from the upload to NEW, it wouldn't be auto-
built and would block migration of your package to testing.
This isn't what happened, I suppose, since we all debian maintainers need
to do source-only uploads after a package has been accepted through the NEW process.
Unless I'm mistaken, that source-only upload cannot be replaced by a
binNMU, can it ?
What happened is more likely to be a standard rebuild against a new version
of a dependent library.
The "+b1" indicates a binBMU was performed[2,3]. If you look at the
buildd logs (https://buildd.debian.org/status/package.php?p=tiv),
you'll see the relevant changelog entry for the amd64 package: "Rebuild
on buildd".
A binNMU, but right.
Mathias
[1] -- https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#source-and-binary-uploads
[2] -- https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#source-nmus-vs-binary-only-nmus-binnmus
[3] -- https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#recompilation-or-binary-only-nmu
<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le ven. 16 févr. 2024 à 04:03, Mathias Gibbens <<a href="mailto:
gibmat@debian.org">
gibmat@debian.org</a>> a écrit :<br></div><blockquote
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, 2024-02-15 at 16:20 -0800, Loren M. Lang wrote:<br>
> Hello,<br>
> <br>
> I recently had a package sponsors and entered into unstable called tiv.<br>
> It can be seen here:<br>
> <br>
> <a href="
https://packages.debian.org/sid/tiv" rel="noreferrer" target="_blank">
https://packages.debian.org/sid/tiv</a><br>
> <br>
> Everything went OK, but I see that the amd64 arch package appears to<br> > have been re-built for some reason. It's version is showing up with a<br>
> +b1. I am curious if there is some long to indicate what the issue might<br>
> have been that led to a rebuild. Could there have been a compilation<br> > issue or other things I should be concerned about or is it likely<br>
> something harmless? Is there a log for this case?<br>
There's no cause for concern -- it's a normal part of a new package<br>
entering the archive.<br></blockquote><div><br></div><div>Indeed...</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
When a package is uploaded to NEW, you have to upload both the source<br> and binary package(s) for review. After the package is accepted, the<br> buildds auto-build for any other architectures that don't already have<br> a binary package. Migration policy requires all packages to be built on<br> official buildds from their source package[1]. Since the amd64 binary<br> package already existed from the upload to NEW, it wouldn't be auto-<br> built and would block migration of your package to testing.<br></blockquote><div><br></div><div>This isn't what happened, I suppose, since we all debian maintainers need</div><div>to do source-only uploads after a package has been accepted through
the NEW process.</div><div>Unless I'm mistaken, that source-only upload cannot be replaced by a binNMU, can it ?</div><div>What happened is more likely to be a standard rebuild against a new version of a dependent library. <br></div><div><br></div><
blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The "+b1" indicates a binBMU was performed[2,3]. If you look at the<br>
buildd logs (<a href="
https://buildd.debian.org/status/package.php?p=tiv" rel="noreferrer" target="_blank">
https://buildd.debian.org/status/package.php?p=tiv</a>),<br>
you'll see the relevant changelog entry for the amd64 package: "Rebuild<br>
on buildd".<br></blockquote><div><br></div><div>A binNMU, but right.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Mathias<br>
[1] -- <a href="
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#source-and-binary-uploads" rel="noreferrer" target="_blank">
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#source-and-binary-uploads</a><br>
[2] -- <a href="
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#source-nmus-vs-binary-only-nmus-binnmus" rel="noreferrer" target="_blank">
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#source-nmus-vs-binary-only-
nmus-binnmus</a><br>
[3] -- <a href="
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#recompilation-or-binary-only-nmu" rel="noreferrer" target="_blank">
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#recompilation-or-binary-only-nmu</
<br>
</blockquote></div></div>
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)