[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#809623: RFS: telegram-purple/1.2.3-1

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

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

>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.


>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)



Reply to: