Bug#779377: RFS: classified-ads/0.03-1 / ITP

[Tobias Frost <tobi@debian.org>]

Control: owner -1 !
Control: tags -1 pending
# (above means: I will sponsor you)

Am Samstag, den 28.03.2015, 23:34 +0200 schrieb Antti Järvinen:
> 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..

dpkg-dev pulled in by build-essential and therefore you do not need to
exclitly state it, except if you have a version constraint. (need a
minimum version of dpkg-dev; (read the description on the above quoted
lintian error; this also points you to Policy §4.2)

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

No doubt, Copyright is complex; and this also very usual that sponsorees
don't get it right the few first times :)
But looking at the repository it looks fine now. (Though I will do a
final copyright check just before uploading -- because this topic is
complex and it is easy to overlook something.)

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

No, you've got me wrong... 
In Debian we build *everything* from source.
Spoken in source code analogy: Your high resolution file is the source
(like a cpp file) code, the bitmap is the object code: As like you need
to compile your cpp file, you must regenerate the bitmap during the
build from the highres image. 
Debian sees the (high-res image) as part of the source code, the
preferred form of the source actually. So you should include it into
your tarball and create the actual bitmaps at build-time.

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

Fine with me, just wanted to know if you put some thoughts into this
aspect.

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

Yes I saw it; thank you a lot.


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

Sure, just follow the ITa procedure. (I will also sponsor you on this)

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

Its just a git repository ;-) No big risk to ruin everything.
You could also move the repository somewhere else, if you don't like
collab-maint. 

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

qemuctl is not much work on the Debian part, but when using it (and you
should when maintaining it) you will probably find a few things that
needs fixing. As upstream is not very active, this could mean that you
indeed ending up investing some time in developing the fixes yourself.
But it is indeed a nice package to get started..

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

That sounds like a promising plan. 
For the upload procedure:
In short-term, yes: You need a sponsor for upload.
Mid-Terms: You can become a Debian Maintainer with upload rights for your packages (https://wiki.debian.org/DebianMaintainer)
Long-Term: You join the project as Debian Developer 

> There is a new upload to mentors with same version number (0.05-1)
> that has changes to d/copyright and d/control. 

I just pulled from github, we can work from there if you want.
I saw that debian/source/format is missing in the repository.

(I continue this evening with the review; but from here it looks we are
almost there.)

> --
> Antti
> 

--
tobi