Hi again, Denis Briand wrote: > On Thu, Feb 12, 2015 at 02:04:26AM +0100, Axel Beckert wrote: > > Shall we open an Alioth project to get a team mailing list? Or will > > collab-maint plus bug tracking system already suffice the team's > > needs? > > IMHO I think a team mailing list will be better to coordinate our work.
Ok. I've created an alioth project named "pkg-lynx" and "ordered" a mailing list: | A mailing list will be created on Alioth in 6-24 hours | and you are the list administrator. | | This list is: pkg-lynx-ma...@lists.alioth.debian.org . | | Your mailing list info is at: | https://lists.alioth.debian.org/mailman/listinfo/pkg-lynx-maint . So for now we just have to wait a little bit. I've added Denis and Andreas to the project, but for now this has no real effect. (I also gave Andreas administrative access to the project so we have another DD who can administrate the project in case I'm unavailable.) > > > Maybe Axel could open a collab-maint git repository on alioth to > > > work together ? > > > > Done: https://anonscm.debian.org/cgit/collab-maint/lynx-cur.git/ I wonder if we should move that to https://anonscm.debian.org/cgit/pkg-lynx/lynx-cur.git/ now that we have an alioth project. That way it would make it easier to give freshly involved people like Andy commit access. (Collab-maint rather eases access for already involved people...) If nobody opposes, I'd move the git repo from collab-maint to pkg-lynx and give all team members commit access. In any case, Andy should create an alioth account at https://alioth.debian.org/account/register.php (at least I didn't find one with his name) -- Further steps to get commit access will depend on our decision about the final git repo location (collab-maint vs pkg-lynx). Andy Valencia wrote: > I went sorta quiet. Some local dev work picked up, but also it takes a > B-I-G gulp of document reading to have even the first idea of all that > Debian packaging goop. Maybe starting with small pieces of hands-on experience will make that easier. :-) > I'm perfectly well skilled at C and git and all that stuff. That's good! Because C is not one of my strengths. :-) I saw you're doing ham radio, radio shows and gopher, too. I like that. (I recently broadcasted two radio shows about amateur radio for http://www.hackerfunk.ch/ -- in Swiss-German, second one not yet online. :-) > But there are so many layers of Debian package tooling, and even > after grinding through all the documentation sets Axel pointed me at I > still don't have a clear idea of what gets built where, for which > release, and where one goes to find out what got built/packaged, > or if it had a problem, where's the log? Tons of details. I can understand that. For being able to work with the git repository with already having Git knowledge, I'd say that having a look at some of the tools included in the git-buildpackage package (meta command is "gbp") would be a good start. If you want to help importing and merging new upstream releases, I recommend having a look at the "git-import-orig" or "gbp import-orig" command (they're both the same, the latter being the newer, preferred variant) especially. It works fine together the following two commands: * pristine-tar (of the package of the same name) * origtargz (of the package "devscripts") To make git-import-orig to always use pristine-tar, create a ~/.gbp.conf file with this contents: ---8<--- [DEFAULT] pristine-tar = true --->8--- pristine-tar isn't easy to understand as its value only shows up in some specific situations, especially in team-maintenance or if package development is done on multiple machines. I'll try to show a common one to explain how the tools work together: Team Maintenance: * Person A wants to import a new upstream release. git-import-orig does the main work of untarring and adding files. It pushes all branches to the central repository. But the tar ball contains more details than git can store (permissions, etc.) pristine-tar saves all those git can't store in a binary delta file in a separate pristine-tar branch. Together with the contents from the "upstream" branch and the small binary delta, the whole .orig.tar.gz can be recreated from the git repository. * Person B wants to work on the package. "gbp pull" gets the current state. But since a new upstream version was imported, running "dpkg-buildpackage" bails out because no .orig.tar.gz tar ball was found, but is required. B calls "origtargz" which sees that there is a pristine-tar branch containing all necessary information to recreate the tar ball bit-wise identically. To do that, origtargz calls pristine-tar with the according options to recreate the newest tar ball. B can build the package and can be sure to have an identical upstream source tar ball without having to download it a second time via HTTP. (origtargz will try to do that to some extend if pristine-tar is not used. But unless the upstream release already had been uploaded to Debian once, this is only guess work and not guaranteed to be an identical tar ball as A had when importing the new upstream release. I hope that was at least a little bit understandable. > I'm more than happy to fix bugs If you need to fix bugs in upstream code which should be shipped as a patch in Debian until a new upstream release includes them, have a look at the package and tool "quilt". For me, a nice afternoon in the park and the tutorial at http://git.savannah.gnu.org/cgit/quilt.git/plain/doc/quilt.pdf helped me a lot to understand quilt. :-) Regards, Axel -- ,''`. | Axel Beckert <a...@debian.org>, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `- | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150212113304.go6...@sym.noone.org