Hi again,
>Oh, wow. This will take a bit time until I grasp everything well enough
>to publish something with this :P
>
>Most prominently, I don't like the "everythingisoneline" approach of the
>watchfile. I guess someone has already suggested changing it to the
>"usual" YAML-based approach?
you should just call uscan [--debug] and have your new tarball ready to go
>I... I believe I understand this. However, testing this will be a pain,
>and automatic testing probably impossible.
>
>Is there some kind of established "best practice" for testing these? Or
>is the best practice just to "run by hand until it works, then wait
>until it breaks for DEHS"?
I don't follow, uscan just calls the script you are calling manually, and in
addition it calls it with the parameters (version and so on).
you just need to look at vbox get-orig-source script, it should be easy to
understand
>I can do that, sure. Can you tell me who profits from this, though? It's
>a bit demoralizing to have to write and test things like these if noone
>will ever profit from this.
other people will be able to look at the sources, integrate a new release
without having to know how exactly all of this works
>I understand that d/watch is needed by DEHS to monitor how outdated the
>Debian repository is, in some sense. So I wrote a d/watch for that, and
>made sure it works and will continue to work.
sure, but adding a script called, it doesn't break that part
>I also understand that some maintainers prefer working with uscan to
>fetch and integrate the newest upstream version. But that doesn't apply
>here, as the preferred mode of updating is doing a "git pull".
this might make sense then :)
>My script would probably do the following thing:
>- delete the file fetched by uscan, since it's utterly incomplete
>- use the upstream version to clone (as in git-clone) the repository
>- ./configure && make dist || (echo "Too old upstream version; doesn't
>support orig tarballs yet."; exit 1)
>- delete all temporary files
>Ugh.
seems an overkill :)
>And all that so that someone can say "dh get-orig-source".
>So, who does this? (And can I assume git to be installed? I don't like
>having such a big b-d ...)
git is needed for everybody who wants to work on Debian, not needed
to be a b-d :)
>Already extensively documented in d/README.source
ack
>In short, the reason is: tgl ("the" submodule) is way too unstable and
>volatile to ever be packaged separately.
this makes sense even if it should be avoided, but it is up to your sponsor
that part :)
>There is only one other program that might enter the Debian repository
>>(tg-cli, I don't see any RFP or ITP for it) will never be used together
>with telegram-purple, and will most definitely never use a compatible
>version of tgl.
ok
>None of our scripts assume any architecture or have a list of all of
>them. What part of which script would become "outdated"? What would change?
I don't remember, config.sub and config.guess were outdated in many packages
because
of missing autotools-dev and autoreconf.
I don't think this harms somewhere, so why not run it automatically?
(I'm a cmake guy, I can't provide a better rationale, I run it because it
works(TM))
>Hmm, but this makes it easier for me to track which versions there were.
>
>But okay, I'll push the next version as 1.2.4-1 if you wish.
no problem, you can bump the revision, just when the package will be ready
somebody will
have to merge everything in a single -1 revision and upload on unstable
>Huh? I'm confused. I make sure that all versions have a different
>number, and go increasing as per dpkg --compare-versions. Why is it
>*harder* to track progress?
>
>I mean, sure, I can change my behavior regarding that, I just think it's
>a good idea if I also know the reason for it :P
nah it is fine, just I like to press "CTRL+R" telegram-purple, find the dget
line
and press enter :)
too lazy to go on mentors, search the last revision, copy-paste the link and
then dget
(for this git is better for sure)
cheers,
Gianfranco
