Bug#756978: .tar-less push
Control: close -1 I'm not sure this is very actionable any more. Hopefully forthcoming ideas about "push to upload" will make this unnecessary. Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Bug#756978: Info received (Bug#756978: .tar-less push)
Ansgar pointed out that this could be simplified some if there were a way to reproducible build the same *source* package from info in git. The remote machine then does not need to cobble together the dsc and changes, but can just be sent the signed dsc and changes from the build machine, pair them with the *.gz files it generates, check consistency, and upload the lot. Reproducible source builds seems worth doing, if possible. The .diff.gz files could be made reproducible by dpkg-dev simply running gzip with --no-name (and possibly sorting the files rather than relying on directory order). The .diff.tar, native tarballs, and similar tars could be created using git-archive, which already has been fixed to be reproducible. (It would be possible for dpkg-dev to create these tars reproducibly without relying on info from the git repo, but it would have to reset mtimes, or be provided with a list of mtimes.) Version skew in gzip/tar/xz can break the reproducibility; if that mattered their versions could be recorded in the .dsc. -- see shy jo signature.asc Description: Digital signature
Bug#756978: .tar-less push
Ian Jackson wrote: > > I envision something like: dgit push --via somehost > > I don't understand what the somehost is for. > > Why wouldn't dgit just generate the necessary source package files in > the usual way ? > Perhaps your --via is simply the build-host for rpush. The use case is that it's useful to build debs locally, for testing, etc, but if only a source package is being uploaded, there's no point in uploading that from the local host, when it can be reconstituted from a git push. The remote host could be a personal machine, or a DD accessible machine. In the latter case, package uploads become entirely just a git push plus some triggering/signing actions. dgit on the remote machine would get the source tarball in the usual way, for uploads after -1. For native uploads, it could just make up any old tarball. For -1 uploads, pristine-tar could be used (but I have stopped maintaining that). dgit rpush is perhaps most of the way there. -- see shy jo signature.asc Description: Digital signature
Bug#756978: .tar-less push
Joey Hess writes ("Bug#756978: .tar-less push"):
> Now that the archive finally supports .deb-less uploads, dgit should be
> able to take it a step further, to .tar-less push.
>
> I envision something like: dgit push --via somehost
I don't understand what the somehost is for.
Why wouldn't dgit just generate the necessary source package files in
the usual way ?
That is, ISTM this bug report is really a request for dgit to be able
to push without there having been a previous build. It would do the
source package build itself.
Also, how do you propose handling the .orig.tar.gz ? Currently dgit
expects you to retain that in your `..' . Do you want that done
differently ?
> The --via host would need to have dgit installed (probably), and should
> probably have the same version of dpkg-dev as the local host, to avoid
> skew issues (if the two hosts don't agree on the filenames that
> constitute the source package, dgit would probably need to give up).
Perhaps your --via is simply the build-host for rpush.
Ian.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#756978: .tar-less push
Package: dgit Version: 0.21 Severity: wishlist Now that the archive finally supports .deb-less uploads, dgit should be able to take it a step further, to .tar-less push. I envision something like: dgit push --via somehost That would push the git repository as usual, then go to somehost and dgit clone, generate the source package, and feed its files and checksums back to the local dgit. The local dgit can then update the .dsc's checksums, update the .changes to contain the new .dsc checksum, sign the files, and scp both files to somehost. Finally, the dgit on somehost can dput the source package. The --via host would need to have dgit installed (probably), and should probably have the same version of dpkg-dev as the local host, to avoid skew issues (if the two hosts don't agree on the filenames that constitute the source package, dgit would probably need to give up). But it does *not* need to have the package's build deps installed, since only the source package is built there. -- see shy jo signature.asc Description: Digital signature
