sagitta ddclient build fails because 3.10.0-3 revision not found

[dd010101]

The ddclient build now fails because it tries to build the 3.10.0-3 from Debian repository https://salsa.debian.org/debian/ddclient Yet there is no 3.10.0-3 tag anymore, where it did go?

From log I see the 3.10.0-3 is 6d4a353c8e36972578e5506a801be7ff8c1f59ea commit thus https://salsa.debian.org/debian/ddclient/-/commit/6d4a353c8e36972578e5506a801be7ff8c1f59ea and the commit message confirms this. Seems like force-push removed this commit from the tree and the tag was removed as well? I can't find commit that would remove this version but the version isn't found in the changelog anymore but was there previously.

The build script only uses the Debian source for the definitions and then uses upstream for the source: https://github.com/vyos/vyos-build/blob/sagitta/packages/ddclient/Jenkinsfile https://github.com/vyos/vyos-build/blob/sagitta/packages/ddclient/build.sh

I can't checkout the 6d4a353c8e36972578e5506a801be7ff8c1f59ea so this confirms it was removed from the tree and the salsa/GitLab shows out of tree commit (yet it doesn't say so 🙄). The parent commits are deleted from the tree too, seems like the whole release was deleted.

Version was released and then unreleased? Strange...

We need need to pick other revision for the definitions. The closest tag is 3.10.0-2.1. The latest branch of Debian is preparation for 3.11.2 and that matches to what VyOS uses (3.11.2).

There is also option to fetch the 3.10.0-3 out of tree via GitLab like this https://salsa.debian.org/debian/ddclient/-/archive/6d4a353c8e36972578e5506a801be7ff8c1f59ea/ddclient-6d4a353c8e36972578e5506a801be7ff8c1f59ea.tar.gz. Not sure how long salsa/GitLab keeps alternate trees, forever?

Options options...

What do you think @Crushable1278? Did you also find this?

[MrLenin]

I also experienced this issue today, my findings appear to match yours. #40

[MrLenin]

https://salsa.debian.org/debian/ddclient/-/compare/debian%2F3.10.0-2.1...6d4a353c8e36972578e5506a801be7ff8c1f59ea?from_project_id=48754&straight=true

Doesn't seem like there's any practical difference really between 3.10.0-3 and 3.10.0-2.1 if 3.10.0-3 is 6d4a353c8e36972578e5506a801be7ff8c1f59ea

[dd010101]

For now I choose the path with least friction and that is to use the snapshot from salsa as replacement for the git clone: https://github.com/dd010101/vyos-build/blob/sagitta/packages/ddclient/Jenkinsfile https://github.com/dd010101/vyos-build/blob/sagitta/packages/ddclient/build.sh

Good workaround as fast fix so we can continue to build since it may take some time before the VyOS develops new build script. It makes sense to re-do the build script and don't use this dual repository thing at all.

@MrLenin

Doesn't seem like there's any practical difference really between 3.10.0-3 and 3.10.0-2.1 if 3.10.0-3 is 6d4a353c8e36972578e5506a801be7ff8c1f59ea

There is extra build dependency - curl. I believe that was added for reason but I'm not sure. The rest is irrelevant for sure. I'm not sure if 3.10.0-3 was chosen because it was the latest or because of some reason, that's why it's easier to just use 3.10.0-3.

You can try the fix - this means ddclient needs to use https://github.com/dd010101/vyos-build instead of https://github.com/vyos/vyos-build. You can change this in Jenkins in the Configure of ddclient pipeline. You can as well fetch fresh vyos-jenkins and rerun the scripts the ddclient will be updated and the rest will stay so it will be quick.

[Crushable1278]

https://salsa.debian.org/debian/ddclient/activity#:~:text=Deleted%20tag%20debian/3.10.0%2D3

https://salsa.debian.org/debian/ddclient/-/compare/6d4a353c8e36972578e5506a801be7ff8c1f59ea...e65b0da2f5f7332cf70bb270d247e94e5ba08374?from_project_id=48754&straight=true

Original PR here: https://github.com/vyos/vyos-build/pull/349/files#diff-7ef4bd5eeea3637a78d93af84b22ebd6701695d360b97834c1ebbcf184c0129a

We now only care about the contents of ./debian though. And really only the patches, so 3.10.0-2.1 should be sufficient.

[dutty5]

@dd010101

You can try the fix - this means ddclient needs to use https://github.com/dd010101/vyos-build instead of https://github.com/vyos/vyos-build. You can change this in Jenkins in the Configure of ddclient pipeline. You can as well fetch fresh vyos-jenkins and rerun the scripts the ddclient will be updated and the rest will stay so it will be quick.

ddclient now builds with this fix. Thank you. However, build-iso.sh for sagitta fails with the following (may not be related at all though):

Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 vyos-1x : Depends: fuse-overlayfs but it is not going to be installed
           Depends: python3-vici (>= 5.7.2) but it is not installable
E: Unable to correct problems, you have held broken packages.
E: An unexpected failure occurred, exiting...
P: Begin unmounting filesystems...
P: Saving caches...
Reading package lists...
Building dependency tree...
Reading state information...
I: Checking if packages required for VyOS image build are installed
I: using build flavors directory data/build-flavors
I: Cleaning the build workspace
I: Setting up additional APT entries
I: Configuring live-build
I: Starting image build
Traceback (most recent call last):
  File "/vyos/./build-vyos-image", line 621, in <module>
    cmd("lb build 2>&1")
  File "/vyos/scripts/image-build/utils.py", line 84, in cmd
    raise OSError(f"Command '{command}' failed")
OSError: Command 'lb build 2>&1' failed
ISO build failed

[dd010101]

Not related. Is your strongswan package building successfully?

[dutty5]

Not related. Is your strongswan package building successfully?

yes, all packages building successfully. I installed everything a fresh today starting from the new VM. Equuleus ISO builds successfully. Sagitta failed on the first run due to ddclient. After your fix all packages build, however Sagitta ISO does not.

[dutty5]

Not related. Is your strongswan package building successfully?

I checked again. Looks like strongswan doesn't build. No errors in Jenkins, everything is green. However, no deb packages in repo.

[dd010101]

@dutty5 Plesese check logs as mentioned in Something is wrong and look for python3-vici and if you don't find resolution by looking at the logs yourself then please create new issue.

[MrLenin]

I can confirm the workaround worked for me, was able to build ddclient and also successfully built the iso.

[Crushable1278]

~I can't seem to get the workaround working even manually:~

Disregard. I had made a modification to the build script that prevented patches from being applied. Confirmed. Works.

stack trace

``` [20:08:16 root@d2a3940fd34f ddclient {0}]# ./build.sh I: Copy Debian build instructions I: Ensure Debian build dependencies are met dpkg-buildpackage: info: source package ddclient-build-deps dpkg-buildpackage: info: source version 3.10.0-3 dpkg-buildpackage: info: source distribution unstable dpkg-buildpackage: info: source changed by Equivs Dummy Package Generator dpkg-buildpackage: info: host architecture amd64 dpkg-source --before-build . debian/rules clean dh clean dh_clean debian/rules binary dh binary dh_update_autotools_config dh_autoreconf create-stamp debian/debhelper-build-stamp dh_prep dh_auto_install --destdir=debian/ddclient-build-deps/ dh_install dh_installdocs dh_installchangelogs dh_perl dh_link dh_strip_nondeterminism dh_compress dh_fixperms dh_missing dh_installdeb dh_gencontrol dh_md5sums dh_builddeb dpkg-deb: building package 'ddclient-build-deps' in '../ddclient-build-deps_3.10.0-3_all.deb'. dpkg-genbuildinfo --build=binary -O../ddclient-build-deps_3.10.0-3_amd64.buildinfo dpkg-genchanges --build=binary -O../ddclient-build-deps_3.10.0-3_amd64.changes dpkg-genchanges: info: binary-only upload (no source code included) dpkg-source --after-build . dpkg-buildpackage: info: binary-only upload (no source included) The package has been created. Attention, the package has been created in the current directory, not in ".." as indicated by the message above! (Reading database ... 43682 files and directories currently installed.) Preparing to unpack ddclient-build-deps_3.10.0-3_all.deb ... Unpacking ddclient-build-deps (3.10.0-3) over (3.10.0-3) ... Reading package lists... Done Building dependency tree... Done Reading state information... Done 0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded. 1 not fully installed or removed. After this operation, 0 B of additional disk space will be used. Setting up ddclient-build-deps (3.10.0-3) ... I: Bump Debian Package version dch warning: neither DEBEMAIL nor EMAIL environment variable is set dch warning: building email address from username and FQDN dch warning: New package version is Debian native whilst previous version was not dch: Did you see those 2 warnings? Press RETURN to continue... dch warning: neither DEBEMAIL nor EMAIL environment variable is set dch warning: building email address from username and FQDN dch: Did you see those 2 warnings? Press RETURN to continue... I: Build Debian Package dpkg-buildpackage: info: source package ddclient dpkg-buildpackage: info: source version 3.11.2+vyos0 dpkg-buildpackage: info: source distribution UNRELEASED dpkg-buildpackage: info: source changed by root dpkg-buildpackage: info: host architecture amd64 dpkg-source --before-build . dpkg-source: warning: diff 'ddclient-github/debian/patches/news.diff' doesn't contain any patch dpkg-source: info: using patch list from debian/patches/series dpkg-source: info: applying news.diff dpkg-source: warning: diff 'ddclient-github/debian/patches/news.diff' doesn't contain any patch dpkg-source: info: applying maxinterval.diff dpkg-source: info: applying fix-version.diff patching file configure.ac Hunk #1 FAILED at 1. 1 out of 1 hunk FAILED dpkg-source: info: the patch has fuzz which is not allowed, or is malformed dpkg-source: info: if patch 'fix-version.diff' is correctly applied by quilt, use 'quilt refresh' to update it dpkg-source: info: if the file is present in the unpacked source, make sure it is also present in the orig tarball dpkg-source: info: restoring quilt backup files for fix-version.diff dpkg-source: error: LC_ALL=C patch -t -F 0 -N -p1 -u -V never -E -b -B .pc/fix-version.diff/ --reject-file=- < ddclient-github/debian/patches/fix-version.diff subprocess returned exit status 1 dpkg-buildpackage: error: dpkg-source --before-build . subprocess returned exit status 2 ```

[dd010101]

Do you have idea why would Debian unreleased the release? That's seems like no no to me - once you release you shouldn't take it back I feel. I didn't find in the salsa any reason for it. There are lots of deletes in the activity log, strange stuff.

The previous tag would also work but I guess the best way forward would be to not use this contraption of two repositories. Perhaps the upcoming 3.11 of Debian/latest can be used instead of the combination of upstream 3.11 and Debian 3.10 build scripts? We will see what VyOS will do...

[dutty5]

@dutty5 Plesese check logs as mentioned in Something is wrong and look for python3-vici and if you don't find resolution by looking at the logs yourself then please create new issue.

I resolved my issue by manually starting the build of strongswan in jenkins. Now Sagitta ISO builds, and the ddclient fix works. Thanks.

[Crushable1278]

Do you have idea why would Debian unreleased the release? That's seems like no no to me - once you release you shouldn't take it back I feel. I didn't find in the salsa any reason for it. There are lots of deletes in the activity log, strange stuff.

This does seem to violate the semantic versioning process. I wonder, was 3.10.0-3 ever published to the main repo?

The previous tag would also work but I guess the best way forward would be to not use this contraption of two repositories. Perhaps the upcoming 3.11 of Debian/latest can be used instead of the combination of upstream 3.11 and Debian 3.10 build scripts? We will see what VyOS will do...

Our building of inotify is a similar multi repo process, it's just that the files were targeted.

I doubt we see an official solution from the team until the next upstream ddclient, i.e. 3.11.3. They will continue to use the existing package.

[marekm72]

Something strange is going on, there is another change just committed in vyos-build repo, and the referenced issue https://vyos.dev/T5797 seems completely unrelated to ddclient. Not clear why the Debian package was un-released like this, could be a compromised account or something, or some other security issue still under embargo, ddclient was looking for a new maintainer and there might be a similar story as with xz... probably wise to wait a while until the dust settles, hopefully before 1.4.1 release.

[Crushable1278]

https://github.com/vyos/vyos-build/pull/694/files#diff-7ef4bd5eeea3637a78d93af84b22ebd6701695d360b97834c1ebbcf184c0129a

[MrLenin]

Something strange is going on, there is another change just committed in vyos-build repo, and the referenced issue https://vyos.dev/T5797 seems completely unrelated to ddclient.

From what I can tell, the task number got reused, and it is referencing the task originally associated with https://vyos.dev/R3:368b89ef056dbb412520dd49bd21611b8c7c1cb5

Looks like since debian upstream has the desired version in latest now, they are going for that and dropping the mix and match

[dd010101]

I wonder, was 3.10.0-3 ever published to the main repo?

I see in the changelog change from UNRELEASED to unstable so I assume it was but I can't find any reference to it so perhaps it wasn't.

https://github.com/vyos/vyos-build/pull/694/files#diff-7ef4bd5eeea3637a78d93af84b22ebd6701695d360b97834c1ebbcf184c0129a

The VyOS fix was surprisingly quick, I would assume this would time extra time just because they are switching from the 3.10 definition/patches to the 3.11. The sagitta is still waiting though vyos/vyos-build#696.

Off-topic: I now see on all pull requests of VyOS repositories You can't perform this action at this time instead of Write message box - was I block even there? Do you see this as well?

[GurliGebis]

I am also blocked in their entire github org. My guess is they don't want anything from us (a shame, since I don't mind helping them with patches - my other github account can comment just fine, so it is a block) 🤷

[marekm72]

Well I’m not blocked on their GitHub… yet :) Are such blocks something they can do themselves on their own, or is this only possible if GH receives some complaints?

[dd010101]

My guess is they don't want anything from us (a shame, since I don't mind helping them with patches...)

I don't see any reason why would you block potential collaborators based on nothing, seems like contra-productive action - you don't gain anything. If I wasn't removed from the forum/vyos.dev I would already posted some information about some bugs we found but they can rediscover it later by themselves if they want so bad.

Well I’m not blocked on their GitHub… yet :)

Be careful to not to contribute here too much or else... 😄

Are such blocks something they can do themselves on their own, or is this only possible if GH receives some complaints?

User block from organization is functionality of GitHub organization - it's manual action of the owner/moderator of the organization. The motivation to do so it's strange though, it achieves nothing with seamlessly no reason behind it, strange...

[GurliGebis]

My guess is that they think they somehow are punishing us (I cannot see why else they would do so) Anyway, it isn't going to stop me from reporting issues and providing fixes (it is not like wanting to build me own ISOs mean that I don't want to project to be the best it can be)

[dd010101]

The vyos/vyos-build#696 was merged and the build script was updated to the VyOS version.