[Pkg-giraffe-discuss] z-push packages ready for uploading to NEW?

Tue Sep 5 14:47:29 UTC 2017

Hello Roel,

Am 05.09.2017 um 14:08 schrieb Roel van Meer:
>> https://www.debian.org/doc/debian-policy/upgrading-checklist.html#s-4.0.1
> 
> Yes, the update would require some small changes. I'll commit those.

excellent.

>> You could also use the following checklist for z-push.
>>
>> https://wiki.debian.org/LucaFalavigna/NEWChecklist
>>
>> We also have three overridden tags and two of them are warnings which
>> typically the ftp-masters will look into.
>>
>>> root at x260:/build/z-push-2.3.7# lintian -o --suppress-tags newer-standards- 
>> version
>>> warning: the authors of lintian do not recommend running it with root  
>> privileges!
>>> W: z-push-common: non-standard-apache2-configuration-name z-push- 
>> autodiscover.conf != z-push-common.conf
>>> W: z-push-common: non-standard-apache2-configuration-name z-push.conf != z- 
>> push-common.con
> 
>> This two overridden warnings could be explained why the override was done.
>> I"d write some explanation into README.Debian, z-push-common comes with
>> two needed webserver config files for Apache2 and by this the suggestion
>> by the lintian warning can't be used. I also would point in
>> z-pus-common.install and *.lintian-overrides to the created section in
>> README.Debian then.
> 
> Well, we could of course rename the z-push file to z-push-common. That would  
> avoid one of the warnings (but it might make it harder to switch from the  
> "offical" Z-push packages to the Debian z-push packages).
> I'd rather have an extra lintian warning than stuff breaking whenever you  
> switch, so I'll document both of them.

No renaming of the apache2 configs are needed. We just need to document
a bit why the warnings are there and why (if you want) they are overridden.

>> The file README.source is definitely out of date and needs some actual
>> data. Please prepare some information as content, e.g we use
>> git-buildpackage for maintenance.
>> Policy 4.14 will guide you what's expected here.
>>
>> https://www.debian.org/doc/debian-policy/ch-source.html#s-readmesource
> 
> Okay, can do.

Thanks.

>> Roel, and one more really important point, Guido and me too are don't
>> familiar with z-push in deep.
>> We happily will sponsor a upload but if any bug report or user questions
>> will appear it mostly will need a person that has enough knowledge (and
>> time!) to answer such questions or act on bug solving! Are you aware
>> that this person will and can be currently you?
> 
> Well, although I do know my way around a PHP project, I'm not intimitely  
> familiar with Z-push's internals either. If users have problems or questions  
> pertaining to specific use-cases, I will have to rely on the Z-push devs.
> So if bugs are specific to Debian or related to packaging, I can fix them,  
> but if they are unrelated to either (e.g. they are issues with Z-push itself)
> I will have to forward them to the Z-push bug tracker, most likely.

That's one thing that bug reports in Debian are for, collect all
information, try to to reproduce them and forward them finally to upstream.
The other maybe 50% are Debian specific things within the packaging like
needed dependencies, provide a clear update or migration path and so on.

> Releasing new packages and backporting of bugfixes is not a problem of course.
> 
> So, that's the level of commitment I can offer. If the Z-push devs are  
> committed to fixing actual Z-push bugs reported by Debian users in the  
> Debian bugtracker, I think we have all bases covered. But I cannot speak for  
> them, of course..

A good contact to upstream is always extremely helpful and of course you
need a good knowledge of the software you are packaging. I guess both is
given here on your side. Currently I'd say it's doable for you.

>> If you are not feeling able to do this we should not upload z-push to
>> Debian. For the technically packaging Guido and myself will of course
>> stay on your side and we'd be happy if you step in as a package
>> maintainer and so far I can see you are really qualified from the point
>> of knowing the source for this!
> 
> Well, thanks! You've been a great help in getting things done properly.
> 
> With that, I have one last question. Where do I push new work? In my own  
> github repo? In yours? Or do we work directly on the Alioth z-push repo now?

By the membership in the Alioth group you have rw access rights to the
git trees within that group. So basically there is nothing that prevents
you technically to push directly to the trees on Alioth.

If not already done please take a look into the Wiki pages around the
Alioth platform.

https://wiki.debian.org/Alioth
https://wiki.debian.org/Alioth/FAQ

For pushing to the git trees you will need to setup a SSH key. I'd
recommend to create a separate dedicated SSH key pair for Alioth. For
example by the following command:

> $ ssh-keygen -t rsa -b 4096 -f ~/.ssh/roel-alioth -C "roel at your-domain.com"

Then follow the the instructions here:

https://alioth.debian.org/account/editsshkeys.php

Some more important information can be found in the Debian wiki again.
Modify the '~/.ssh/config' to get this more comfortable.

https://wiki.debian.org/Alioth/SSH

If all went fine you need to do checkout the tree again or tune your
settings for accessing the repository. You could use 'git set-url' or
you modify '.git/config' directly. In case 'origin' is used as remote
foe Alioth:

> git remote set-url origin ssh://roel-guest@git.debian.org/git/pkg-giraffe/z-push.git

Note that pushing to Alioth won't allow force pushing, so once pushed
... it's there for ever. Before finally pushing I normally try to do a
dry push by using 'git push -n' to see what would happen.

Or ... if you are unsure you can also first push a series git patches to
the list here, or point to your git tree on GitHub. We will order that out.

-- 
Regards
Carsten Schoenert