[Calendarserver-maintainers] Bug#866979: Bug#866979: python-vobject: please package new upstream 0.9.5

[Guido Günther]

On Tue, Jul 04, 2017 at 09:20:28AM +0200, Jonas Smedegaard wrote:
> Quoting Guido Günther (2017-07-04 08:13:55)
> > Hi Jonas,
> > On Mon, Jul 03, 2017 at 10:45:37PM +0200, Jonas Smedegaard wrote:
> > > Quoting Guido Günther (2017-07-03 18:46:57)
> > > > On Mon, Jul 03, 2017 at 10:33:16AM +0200, Jonas Smedegaard wrote:
> > > > > As subject says, please package new upstream version 0.9.5.
> > > > > 
> > > > > ...or grant my request for membership of the team and let me do it ;-)
> > > > 
> > > > Thanks for helping out! I've added you to the project. Please make 
> > > > sure you keep the branches up to date (master, upstream, 
> > > > pristine-tar).
> > > > 
> > > > I intended to switch to a DEP-14 layout (debian/sid, upstream/latest) 
> > > > with the next version but we can do so at a later point.
> > > 
> > > I'd love to keep things properly in sync, but cannot:
> > > 
> > > jonas at auryn$ git push --follow-tags origin master upstream pristine-tar
> > > Counting objects: 86, done.
> > > Delta compression using up to 2 threads.
> > > Compressing objects: 100% (80/80), done.
> > > Writing objects: 100% (86/86), 168.25 KiB | 0 bytes/s, done.
> > > Total 86 (delta 39), reused 3 (delta 0)
> > > remote: error: insufficient permission for adding an object to repository database ./objects
> > > remote: fatal: failed to write object
> > > error: remote unpack failed: unpack-objects abnormal exit
> > > To git+ssh://git.debian.org/git/calendarserver/python-vobject.git
> > >  ! [remote rejected] master -> master (unpacker error)
> > >  ! [remote rejected] pristine-tar -> pristine-tar (unpacker error)
> > >  ! [remote rejected] upstream -> upstream (unpacker error)
> > >  ! [remote rejected] debian/0.9.5-1 -> debian/0.9.5-1 (unpacker error)
> > >  ! [remote rejected] upstream/0.9.5 -> upstream/0.9.5 (unpacker error)
> > > 
> > > 
> > > It seems the git repo at Alioth is not properly group writable:
> > > 
> > > js at moszumanska:/git/calendarserver$ ls -la python-vobject.git
> > > total 72
> > > drwxrwsr-x+   7 agx  calendarserver 4096 Mar 18  2013 .
> > > drwxrwsr-x+  13 root calendarserver 4096 Oct 15  2015 ..
> > > -rw-rwxr--+   1 agx  calendarserver   23 Jan  2  2008 HEAD
> > > drwxrwsr-x+   2 agx  calendarserver 4096 Jan  2  2008 branches
> > > -rw-rwxr--+   1 agx  calendarserver  126 Jan  2  2008 config
> > > -rw-rwxr--+   1 agx  calendarserver   25 Jan  2  2008 description
> > > drwxrwsr-x+   2 agx  calendarserver 4096 Jan  2  2008 hooks
> > > drwxrwsr-x+   2 agx  calendarserver 4096 Jan 29 22:27 info
> > > drwxrwsr-x+ 151 agx  calendarserver 4096 Jun 28 07:02 objects
> > > -rw-rw-r--+   1 agx  calendarserver 2376 Mar 18  2013 packed-refs
> > > drwxrwsr-x+   4 agx  calendarserver 4096 Jan  2  2008 refs
> > > 
> > > At least "packed-refs" (and possibly others in subdirs) are writable 
> > > only by agz.
> > 
> > packed-refs is group-writeable and the ACLs look sane too. Others like 
> > jelmer have pushed before into this repo so maybe alioth hadn't put 
> > you into the right groups yet? Can you try again?
> 
> Ah yes - silly me: I bogusly reacted on the _execution_ bit which is set 
> only on directories, obviously.  Right, it is likely simply the waiting 
> time for Alioth - I'll give it another 24h.
> 
> 
> > > Btw, is it deliberate that debian/gbp.conf do not enable 
> > > pristine-tar nor signed tags?
> > 
> > I keep these in ~/.gbp.conf but feel free to add them to 
> > debian/gbp.conf so everybody using it picks them up.
> 
> Ok. Done (but not yet pushed - see above).
> 
> I have not yet used gbp-pq, but will try explore that.  
> 
> Seems the package uses gbp-pq README.source still talks only about 
> quilt. I guess because gbp-pq is used only locally, not distributed - 
> which kinda makes sense: Failing to understand how it was supposed work 
> distributed have been my main reason for not yet embracing it.  I will 
> try play with it.

I'm usually dropping

    /usr/share/doc/git-buildpackage/examples/README.source

into packages nowadays but did not do so for python-vobject yet. Does
this make more sense?
Cheers,
 -- Guido

> 
> 
> > Thanks for the upload! I've closed #841247 as well.
> 
> Good. I examined it but got an error both with older and new library. 
> Probably the error I got was unrelated to that bug then, if it was 
> working for you.
> 
>  - Jonas
> 
> -- 
>  * Jonas Smedegaard - idealist & Internet-arkitekt
>  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
> 
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private