Hi,
sorry it took me some time to get to this, I've been hooked up by some
real life stuff...
On Mon, Feb 20, 2017 at 11:35:18PM +0300, Коля Гурьев wrote:
> Oh, but they have released a new version today.
few minutes/hours after this they released another one too, it seems :P
They took the whole "release early, release often" thing a bit too
seriously, IMHO u.U
> And also, how can I turn verbose CMake output off? I fear to miss an
> important GCC warning. But I don't want to interrupt compilation in this
> case.
umh, TBH I wouldn't know. We usually *love* very verbose builds.
Outputting the whole gcc command is usually a good idea, as there are
tools checking the build logs for the presence of certain build flags
(see blhc and bls).
I *think* you could pass an extra -DCMAKE_VERBOSE_MAKEFILE=OFF to
verride the previous -DCMAKE_VERBOSE_MAKEFILE=ON passed by debhelper,
but if you want it, I'd like if you could put it behind a check for the
presence of a variable or something so you can do it only in your
system, so others keep getting the full log.
Besides, in case of failure the gcc call is priceless!
> > It's not a techinical thing, but more political, actually. I want to
> > decide the license of what I write.
> > But what you did before was ok.
>
> Well, I'm completely confused, sorry, then I brought it back.
If you want to say that licensing/copyright is a complicated mess,
you're right :)
> > This still need to take care of:
> >
> > * spelling-error-in-binary (please upstream the fix)
> > * spelling-error-in-manpage
> > * desktop-entry-lacks-keywords-entry (please upstream the fix)
>
> I'll make a pull request to upstream for fix keywords and encoding fields in
> .desktop file. It seems spelling errors in binary are related to log
> strings, those are not showed in user interface.
ACK, that's the right place to fix those :)
> As you perhaps noticed, my knowledge of English is not very well, and I
> don't know what the problem with the manpage.
Ack. Yes, that "allow to" → "allow one to" is a bit tricky.
I sent you a PR for that.
> > > Hmm... It seems to be working. But lintian sill warnings about
> > > hardening-no-fortify-functions.
> >
> > That usually means that something doesn't respect
> > CFLAGS/CXXFLAGS/CPPFLAGS & friends
>
> Maybe this is a false positive...
I doubt it, very rarely it is…
But anyway, this is not important, let it be for an undefined future.
> > git check:
> > * pristine-tar is not pushed/updated (after some check, if you have
> > pristine-tar-commit=True doing a `gbp buildpackage…` it does commit it
> > by itself, in some cases.…)
> > * you have a lot of branch, including a "master" (which is HEAD) and a
> > "debian", but it seems latter is abbandoned, and the actual
> > debianization is on "master". can you clean it up a bit?
> > * you have a weird looking tag tmp-old-debian
> > * you might want or not to push the upstream branch in your repo, your
> > call, but if you don't let me suggest you don't call the debianization
> > branch "master" ("debian" is cool, but please change HEAD).
> > * there is not upstream tag pushed for the last upstreams
>
> I deleted all old branches, renamed current master to debian and pushed all
> new tags (I keep forgetting to run git push --tags ¯\_(ツ)_/¯ ).
Nice!
> I can't understand why pristine-tar is necessary if I could download an
> original tarball using uscan (or manually).
You probably little. The gain for me is quite relevant, as for example
right now I'm connected through a 3G modem with limited bandwitdh; using
pristine-tar allowed me to download few KBs and get a several MB tarball
out; probably I could have lived by downloading the tarball anew, but it
is for example priceless while working on libreoffice-dictionaries,
where the tarballs are 70+ MB with very small changes across versions.
It mostly is a tool to help coworkers, but in the past it came handy
also for me, in a moment where I wanted to build several past versions
of a program and instead of downloading hundreds of MBs of tarballs I
could just `pristine-tar checkout` them out.
BTW, the name you used for the tarball you committed is unfortunate, as
a tool named `origtargz` (from devscripts) can detect it. It would be
nice if you could commit the renamed/symlinked one made by
$srcname_$ver.orig.tar.gz
that you surely have around somehow, given that you need it to actually
build the package.
> Pristine-tar seems to commit binary blobs into git repo. Why, in
> thunder?
AFAIK It commits the small delta that there is between what
`git archive` produces and the actual tarball. It should always be
pretty small. Besides, the repository is already full of binary blobs,
with all those images :P
> What the profit if I still musta download the tarball?
You must download the tarball only once, to fill it in, then never
again.
pristine-tar came handy recently to me while switching computers, where
I cloned all repositories, and I didn't have to redownload also all the
tarballs.
> [1] https://mentors.debian.net/debian/pool/main/t/telegram-desktop/telegram-desktop_1.0.13-1.dsc
Note that this doesn't match *at all* your top commit (that you even
tagged) cfb1daea9b2ff0b4501d2e97ca979d56b5b58364 :P
Anyway, given that now we got a workable git repository, feel free to
stop uploading those, and just hand me a commit id :)
I think if you update to the new release, and merge my PR, should be
good to go.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
Attachment:
signature.asc
Description: PGP signature