Bug#773942: O: lynx-cur -- Text-mode WWW Browser with NLS support (development version)
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-maint@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 <abe@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
Reply to: