Bug#779377: RFS: classified-ads/0.03-1 / ITP
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Tobias Frost writes:
> Am Donnerstag, den 26.03.2015, 01:19 +0200 schrieb Antti Järvinen:
> > E: classified-ads source: depends-on-build-essential-package-without-using-version dpkg-dev
> > so the version numbers remain.
>
> You probably do not need the dpkg-dev dependency at all, do you?
I was under impression that dpkg-shlibdeps comes from
dpkg-dev. pbuilder seems to happily build without and lintian is not
complaining -> away it goes..
> You need to add -b debian then to VCS-Git (Refer to Policy 5.6.26)
Yes.
> Well, you should not copy the license *text* into d/copyright, but you
> still need to put the license *grant* into it.
>
> The license grant is the header of your source files. So, you'd write
>
> License: LGPL-2.1+
> Classified Ads is free software; you can redistribute it and/or
...
Ok, I'll try restructuring. Software aside, this seems like
complexiest thing ever..
>
> > general:
> > - Huge high-resolution bitmaps removed from source
>
> Not checked in the code, but this raises a flag: In Debian you need to
> have the source in the preferred form for modifications and for images
> this is the _best_ resolution.
> (And as said earlier, you need to compute the lower resolution at build
> time)
Bitmaps are not modified at build-time, only wrapped into qt-format
resource file. The binary .deb contains actually exactly same bits
in bitmaps that are in orig.tar.gz. I was thinking about keeping the
high-resolution gimp files in upstream repo anyway but not in source
package as there is no transform done..
> Did not check the code, but you also ensure that the RAM is not swapped
> out?
Yes and no. For actual key handling the task is outsourced to OpenSSL
and I hope it is doing the Right Thing (starting from 1.0.1g it
actually might, seems..). For content no, it is all over
the place and goes through qt code also so I think easiest would be to
flag the whole process out of swap if possible. After the heartbleed
episode I marked a future development task of moving all
key-handling into separate process, away from process where networking
happens. ..the paranoid operators will have no swap or encrypted swap.
..but I've tried to keep things simple also for end-users. Here you
get automatic content signing+encryption always whenever possible.
Still I wouldn't like to start adding a manpage section about setting
up encrypted swap.
> Regarding my question regarding your plans for involvement into Debian
> -- Do you want to share your thoughts about this?
I've been trying to get involved into group things, as I was thinking
this is kind of soft-landing into debian process. I've been in
discussion with openssl team but then received no definite "yes/no"
answer from them, nor any concrete work items to start working
with. In the meantime I've been trying to do reviews on tickets that
no-one has yet checked.
I noticed you had been marketing qemuctl in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780270 so if I say that
I know qt and qemu in advance (I do) and after half-hour study about
understand the qemuctl behaviour, you think I could ITA this package?
.. the part that I'm worried about is the mechanics of actual
releasing (done in collab-maint?) so that I won't wreck the whole
distro.. I'm not lazy, but this qemuctl looks like a low-maintenance
work-item to me. ..isn't the very idea of collab-maint to have group
of maintainers so I'd have someone to ask for help in the beginning?
I've been using linux since kernel 0.98, I'm no newbie, I do sw
development for living, but about packaging I've been
only on installation side this far -> if I'm about to release a new
version of any package, someone else will still need to review my work
before it gets uploaded into actual releasing, right? If I take one
package first, see how get things done and if time permits, adopt more
packages after I know the releasing mechanics, does that sound fair?
As said, I'm not lazy and in the beginning said that I can contribute
to overall process too.
There is a new upload to mentors with same version number (0.05-1)
that has changes to d/copyright and d/control.
- --
Antti
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>
iD8DBQFVFx5GUTdja+nNMWMRAuQYAJ9zZZjCOSr4gnuQjlpuatDhrhm2CQCfXGPT
nP6F8ePNdvGGThLGAmthP9w=
=w25K
-----END PGP SIGNATURE-----
Reply to: