thomas.g.girard at free.fr
Sun Feb 20 14:51:51 UTC 2011
Le 19/02/2011 22:45, Pau Garcia i Quiles a écrit :
> I have added the following packages:
> * libace-inet-6.0.1, libace-inet-dev: ACE_INet
> * libace-inet-ssl-6.0.1, libace-inet-ssl-dev: ACE_INet_SSL
> I have also committed patch 16-ace-inet-pkgconfig-files, which are the
> pkg-config files for ACE_INet and ACE_INet_SSL. It should be applied
> upstream (Johnny?).
> There is one detail I don't like about having ACE_INet and
> ACE_INet_SSL in different packages: in ACE, the include files are not
> split, all the header files are together in usr/include/ACE/INet. To
> split them, I have looked for the files with include SSL or HTTPS in
> the filename:
[... snip ...]
> Of course it would be much much easier if upstream put the header
> files for ACE_INet into usr/include/ACE/INet and the header files for
> ACE_INet_SSL into usr/include/ACE/INet/SSL or usr/include/ACE/INet_SSL
Agreed. From what I understand there's nothing left to do for this
release, hence I'll start building 6.0.1 for an upload now.
>> Some other things that might be worth:
>> - switching to new 3.0 format + quilt
> To silent lintian, I have stated explicitly we are using source format
> 1.0. I need to read more about 3.0 to know how to work with patches
So do I. But it seems like a great step forward. From the top of my head:
- support for .tar.bz2 upstream tarball
- can automatically remove upstream's debian/ if embedded in orig
What I have no idea about is how the workflow will have to be changed
to be used with git.
>> - switching to git?
> I have experimented a bit with this:
> - I have converted the svn repository as of now to git following
> - When importing upstream source, there were conflicts with upstream's
> "debian" directory. I don't really know whether I should fix those
> conflicts, or whether I should import-orig filtering out upstream's
> "debian" directory ( git import-orig --filter=debian
> ../ACE+TAO+CIAO-src-6.0.1.tar.bz2 ). Stefano Zacchiroli suggested on
> IRC I go with "--filter=debian" and convince upstream to not ship a
> 'debian' directory :-?
I believe --filter=debian will do. Johnny wants to keep debian/ to be
able to build the packages with OpenSUSE build system, but I have no
idea whether this OpenSUSE build could be achieved using an alternate
mechanism (e.g. a separate debian tarball).
> I have uploaded the result of filtering out upstream's "debian"
> directory to http://www.elpauer.org/tmp/pkg-ace.git.tar.bz2 . Please
> check it ("gitk --all" comes handy). If you think it's in good shape,
> we can arrange a date and time for the final conversion (after 6.0.1-1
> is released looks good to me). I would need you to create a git
> repository (see http://wiki.debian.org/Alioth/FAQ#vcs-repos ), then
> when the final conversion is done, I will push the converted git
> repository (assuming I have the proper permissions in Alioth).
At a glance, it looks good. It revealed we have defunct branches,
5.4.7-x/, 5.5.6/ and 5.6.3/ that can be removed from SVN AFAICT.
Two things I don't understand:
1. in gitk it looks like some branches where not merged into the
trunk, e.g. branch svn-import/5.6.3. While I'm sure it was in
SVN. Might be because our repo was created in pre 1.5.0 format
with merge tracking?
2. Branches that was closed in SVN (e.g. svn-import/kfreebsd) still
appear as branches in git. Is this intended? Can we remove these?
I'm quite excited to switch to git, thanks for taking care of that! I
hope it will ease packaging, but a workflow has to be defined for
I believe you have enough rights to create and push to an Alioth git
repo. But, as you suggested, we'll define a timeslot for this after
6.0.1-1 is released.
>> - any other idea
> Maybe we could keep a README-RELEASE.txt or something like that with
> notes of things to check for each release. For instance:
> - Update patch 34-bts386713
> - Regenerate the list of include files for libace-inet-dev and
debian/README.source could be used for that maybe?
More information about the Pkg-ace-devel