On Sat, Feb 15, 2014 at 01:36:06PM +0100, Stanislas Marquis wrote: > Hello Paul, > > I am working on adaptation of pyswisseph 2.0 with your chosen debian setup. > > I think the pkgconfig file found in libswe-dev is not correct, the include > path leads to nowhere, it should be "/usr/include". Thank You I will be making a patch for this. (I may use pkg-config > to detect libswe installation at build time.) Or you choose to allow > several versions of swisseph to be installed? In that case you should take > care of the numbering of the libs too... > > Sincerely yours, > Stan > When no sponsor showed up on debian for pyswisseph, I moved on to other things. My work is still on alioth. I was thinking we could make a copy of that repository on github and begin collaborative work there. We could jointly work on the packaging. The develpment would remain strictly your concern. A word of warning, packaging is significantly different than developing as an upstream, and the work of a packager. a packager must make a sharp distinction between packaging and development. The developer is the upstream. In the case of pyswisseph this is you. It is possible to be both a developer and a packager, but such a person must always be aware of which "hat" he is wearing. a packager may not change the upstream, but only create "patches" that the distro uses to make the package work in a distro. a packager may not change the upstream. I can submit patches to the upstream, to ask if he wants to include them in the new release. on the other hand the packager must insure that the package meets all of debian copyright and build restrictions. It is complex. I use git-dpm to separate the work of the packager from the work of the upstream. It is a complex program on top of regular git. http://git-dpm.alioth.debian.org/ A packager must know everything in Debian New Maintainers' Guide https://www.debian.org/doc/manuals/maint-guide/ and more. For example, the above tells how to package a program, but how do you test it? Well new packages first go into "unstable" and then into "testing". So if you want to test your program before putting it in :-) you must run "unstable". But "unstable" can be full of bugs! I have a "unstable" partition on my hard disk that I use for packaging. However, due to an X11 bug, everything displays weird using my current graphics card on "unstable". This is a new card I just bought to get around the problem. I thought the problem might be my obsolete built in graphics. It was not. "unstable" works just barely good enough so I can see if the program is working. Some techniques common in the python world are not allowed in debian, because they bypass debian copyright and build requirement restrictions. I am a beginning packager and need to get help from a DD debian developer to get packages into Debian. My DD for libswe and maitreya is "Jaldhar H. Vyas" <jaldhar@debian.org>, but he does not do python. In order to get pyswisseph into debian it will be necessary to find a DD who is willing to work with us. Do you know any debian DD's who work on python who are not hostile to astrology? Theoreticly debian does not discriminate against "fields of interest", but there is the practical problem of finding a DD. But if we fail to get a DD we can take our package to opensuse buildservice and have it privately built and published there. To give you an idea of some of the things a packager must think about, let us take your bug. First when I verified the problem, I thought is this "really" a problem with the packaging or the upstream. In this case it is a problem with the upstream, because any user of the package would want this fix even if they were not using debian. Some "fixes" are only relevant to debian and must be maintained by the packager as a patch. Sometimes the next release of the upstream will be a long time from now so the problem must be fixed with a patch in the meantime. Some "fixes" might be a good idea but impose considerably on the upstream who must deal with many distros and development environments. Some "fixes" are a debian hobby horse. Sometimes you have a recalcitrant upstream that refuses to do things the right way. In the case of your bug, I am the upstream, because I have forked the people at astrodienst. http://swissephauto.blackpatchpanel.com/ Not the astrology, just the tarball and the build system. So in a sense, I am both the upstream and the packager, but I do not change the astrology as a matter of policy. The astrodienst tarball is perfectly legal all completely gpled. Nevertheless, it is totally unacceptable for debian. A .dfsg package is another way to deal with problems like this if they are minor. These problems are not minor. It contains binaies. Unsourced, (in that tarball), documentation. That documentation is sourced somewhere else. It uses a totally obsolete build system. The source does not keep old tarballs. The list goes on. It is really not intended for distro development. I believe it is intended to divert amateurs into the GPL so that libswe will never have a propiatary competitor (it is dual licnesed.) That is OK. I believe in the GPL and would not have it any other way. I created a fork that fixed these problems without changing the astrology. Your bug is not an astrology bug. If your problem were an astrolgy bug I would report it to the "real" upstream and wait. By "real" I mean the upstrem's upstream. In this case. Some forks consider themselves to be indpendant projects. Swiss Ephemeris AutoTools does not consider itself that way. It is a matter of interpretation. So I will take your report and create a new tarball for Swiss Ephemeris AutoTools. This I will do wearing my "developer" hat. Then I will put on my packager "hat" and take that tarball and import into libswe.git using "git-dpm import-new-upstream". In the general case there could be conflicts with previous patches that I would have to resolve at this point. In this case, that will not happen. I will update the changelog and the version number with "dch -i" and import that into git. Then I will check that I have not broken anything, and that maitreya still builds and works. I will then notify my DD about the new package release and the need for an upload. I have slowly learned this process over many months. I am still learning. > > 2014-01-21 22:23 GMT+01:00 Paul Elliott <pelliott@blackpatchpanel.com>: > > > > > > > I failed to get into debian. I could not get a sponsor. > > on Fri, 16 Aug 2013 18:58:54 +0200 > > the package request was converted from ITP to RFP > > intent to package to request to package. > > > > It is impossible to know exactly why the package failed > > to get a sponsor. > > > > Things to Do to get package into debian > > > > IMPORTANT Remove unsourced swisseph documentation from the tar ball. > > > > This doc is already available in debian in the package > > libswe-doc where it is rebuilt from source. > > > > Unsourced binaries always force a package to become a .dsfg package. > > > > > > Heavly document everything. > > > > > > Get a packager with experience packaging DEBIAN python and political > > "pull" with those known to sponsor python programs. > > > > Current packaging source is > > Vcs-Git: git://git.debian.org/git/collab-maint/pyswisseph.git > > Vcs-Browser: http://git.debian.org/?p=collab-maint/pyswisseph.git > > > > I would be happy to colaborate with experinced python debian packager. > > > > > > sincere best wishes. > > > > > > > > > > 2012/4/16 Paul Elliott <pelliott@blackpatchpanel.com>: > > > > > Dear Colleague; > > > > > > > > > > I don't think this effort will be hampered by any anti-astrology > > > > prejudice; I > > > > > have already gotten maitreya into debian unstable. > > > > > > > > > > I am having to work with debian technicalities that apply to all > > debian > > > > > programs. Everything built must be rebuilt from source by the build > > > > procedure. > > > > > You must have a license for every file documented. No convenience > > copies > > > > of > > > > > code. Many other small picky details. > > > > > > > > > > The system was designed by Virgos. :-) > > > > > -- Paul Elliott 1(512)837-1096 pelliott@BlackPatchPanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117
Attachment:
signature.asc
Description: Digital signature