Bug#809623: RFS: telegram-purple/1.2.3-1
Hi,
>These (and only these; see below) are already fixed in 1.2.4-2, which
>was uploaded 8 days ago [1]
dget -u http://mentors.debian.net/debian/pool/main/t/telegram-purple/telegram-purple_1.2.4-2.dsc
this is the file I downloaded now and it looks better.
Maybe when you have too many versions, you can consider deleting the package from mentors and uploading it
again, just to avoid sponsors to download an older version
>I guess I did something wrong if you haven't seen that, even though I >thought it should be done this way. Can you tell me what I should do
>differently next time?
maybe delete and reupload :)
but honestly it was my fault, I didn't look at the whole RFS bug thread.
>They generate the orig tarball.
>The watchfile is to check for the newest version.
>These are unrelated things.
no. they are completely related things.
uscan downloads the tarball from the watch file, and if the uscan downloaded tarball doesn't fit your needs
you have to call the repack script directly from the watch file.
with a get-orig-source target
https://wiki.debian.org/onlyjob/get-orig-source
this is my virtualbox watch file
version=3
opts=downloadurlmangle=s/^/http:/,dversionmangle=s/-dfsg\d*$//,uversionmangle=s/-.*// \
http://download.virtualbox.org/virtualbox/([\d\.\-]+)/VirtualBox-([\d\.\-]+).tar.bz2 \
debian /bin/sh debian/get-orig-source.sh
>As already documented in d/README.source, the orig-tarball can't be
>gathered from the obvious sources:
>- Github (definitely)
>- pristine-tar (definitely)
>- git-buildpackage (afaik)
>They all fail for the same reason: missing support for submodules within
>submodules. (Or gbp simply requires more setup than I thought.)
ok this seems legit then :)
>I know and agree that d/genorigtar.sh and d/rawtar are ugly, and they
>will be dropped in the next version, in favor of relatively clean
>chaining of git-archive and tar --concatenate.
>(Obviously not part of the build process, so no need to put any of that
>into Build-Depends.)
sure, even better, maybe if you integrate with watch file.
BTW submodules should in my opinion be considered as different sources, and packaged
separately.
Otherwise you will have a mess of files with no common history, difficult to track and fix
(specially for security issues)
>I'm not entirely sure what you mean by this.
>
>Currently, we assume that the builder eventually invokes ./configure
>with whatever arguments he pleases and the usual semantics. This
>approach does not need anything explicit in d/rules.
>autoreconf is only called when we change configure.ac, in which case the
>new configure-script will be put into git. At no point, there's a need
>for the "user" (here: builder) to call auto{,re}conf.
>Oh. Maybe the entry "autotools-dev" in Build-Depends is superfluous, then?
exactly, but you need to call autoreconf each time you configure the script.
it might sound silly to you, but in case a new architecture is added in Debian
(e.g. recent ppc64el and arm64), your scripts will be outdated, and just rebuilding the package
with an updated toolchain will make them build on new architectures.
so, b-d on dh-autoreconf and call --with autoreconf from the default dh call
>On a side note: 1.2.4 isn't going to make it anyway. Apparently, it's
>horribly unstable on Windows.
who cares? :)
I mean, if the bugs are windows-only related this shouldn't be a stopper for Debian
BTW the version should always be a -1 revision, until the -1 reaches debian (specifically new queue)
you don't have to bump the debian revision, this will make harder for a sponsor to track it, and
useless for Debian users (they won't find the intermediate releases)
cheers,
G.
Reply to: