Discussions on lazygit 0.8.1 (2018~2019)
dawidd6 opened this issue · 56 comments
I think it's a good idea to have this sticky issue for some light conversations.
Sooo, right now I'm trying to figure if my email setup works properly.
EDIT: Ok, seems like it's working, submitted my first ITP yay!
Should I comply to newer workflow or old[1]?
Personally I would do a debian/sid branch with packaging files in it and additionally upstream branch for unmodified source. I never really understood the phenomena of pristine-tar though.
Nice work!
I can see the License: MIT in your ITP mail.
Debian uses Expat instead of just MIT for not confusing with X11 License. You can find more license names used in Debian here: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-short-name
Oh well, good to know. Thanks for this. I'll change that in package.
Should I comply to newer workflow or old[1]?
We have to comply new workflow.
Personally I would do a debian/sid branch with packaging files in it and additionally upstream branch for unmodified source.
It's correct! This is same with the workflow says.
I never really understood the phenomena of pristine-tar though.
For our work, pristine-tar is not needed at all. One of new workflow's goal is removing pristine-tar branch from all of Go packages. So nevermind about it for right now.
EDIT: Nevermind about 1.2 in workflow proposal, this is for old packages already in Debian.
So if I understand correctly I have to upload package via dput to mentors.debian.net and then submit RFS bug via email?
Send a RFS mail to debian-go@lists.debian.org is enough. CC the RFS mail to ITP bug. Go Packaging Team do not use mentors.debian.net .
Oh man, this is a bit cumbersome. I've sent this RFS mail.
I added just the wiki page about RFS. Check it please :D
Sweet!
Also I have a question. My debian/watch is not working because upstream did not make a single tag, so it fails fetching latest tag. What to do in this situation? Delete it?
EDIT: found it
version=4
opts="mode=git, pgpmode=none" \
https://github.com/spkg/bom/ \
HEAD
I'll add this to wiki.
My debian/watch is not working because upstream did not make a single tag, so it fails fetching latest tag. What to do in this situation?
As a lot of Go packages do not uses version tag, we use git commit if the version tag is not exists. Here is an an example. See uscan also. pretty option will help in this case.
I've changed issues titles. I think it's better like that. You?
I think I'm getting a hang of it.
So I'm not supposed to tag debian releases and in debian/changelog I should have UNRELEASED instead of unstable. Then I email RFS again if I made significant changes to package and actual Sponsor is changing UNRELEASED to unstable, tags debian release and uploads to archive.
Is that right?
Depends on team. Some says set UNRELEASES during RFS, some not.
I suggest you set to unstable just before send an RFS.
EDIT: fyi, all of changes in d/changelog should made with dch command. dch -r just before RFS.
Seems like X-Debbugs-Cc header in RFS mails does not work. I'll try regular Cc next time as I see you do.
Also I will write a tool similar to reportbug to generate various emails like ITP or RFS. Because I find reportbug to be a bit cumbersome.
EDIT: or maybe just put templates on wiki...
Seems like X-Debbugs-Cc header in RFS mails does not work. I'll try regular Cc next time as I see you do.
We can put X-Debbugs-CC in pseudo-header.
Also I will write a tool similar to reportbug to generate various emails like ITP or RFS. Because I find reportbug to be a bit cumbersome.
EDIT: or maybe just put templates on wiki...
👍
Here is a new collaborator @nightwarrior-xxx from Debian Go Packaging Team. Welcome! 🎉 🎉
@nightwarrior-xxx, we can talk or discuss about packaging works here. If you comfortable with IRC, I'm also in #debian-go on OFTC and "Golang Packaging" on Matrix.org.
Cool, if I need anything I will ping you on IRC
Added ITP and RFS templates (for Go software only) to Wiki.
@jmkim To be honest I don't really enjoy editing this packages table on Wiki. It's cumbersome. I would recommend using a project. I'll try to set it up a bit, so we can give it a try.
UPDATE: I added some new labels to issues:
ITP sent - add this label to issue when ITP email has been sent
RFS sent - add this label to issue when RFS email has been sent
also I deleted intent to package label, as it is clearly in the title of every issue now, e.g. Packaging ...
If we decide to keep this table on Wiki, then I propose to shorten it a bit by stripping out some columns like Assignee debian package name done packaging wnpp.
@dawidd6 Nice changes, those look very good for me!
If we decide to keep this table on Wiki, then I propose to shorten it a bit by stripping out some columns like Assignee debian package name done packaging wnpp.
Project seems better to show the status of packages, so table is not needed anymore I think. Editing the table was also cumbersome for me. Let's move to Project.
Okay, I've created issues for every package and added 2 new labels: exe (includes executable) and circular (circular dependencies).
@jmkim sooo, if you can make a quick review and maybe delete this table on Wiki.
@dawidd6 Pong, sorry for my delays.
I deleted the table from wiki, and temporarily added ITP bug number on title of each issues. (I use bug number for tracking something :)) If another idea do you have, let's change more.
@dawidd6 And as we can see, nobody sponsor our work right now. Maybe busy for their working for releasing Buster.
Let's wait until Buster release. After the Buster released, I'm going to contact some DDs for sponsoring our work privately.
@jmkim glad to see you back!
Bug number in title is okay for me.
Yes, I find this lack of sponsors disturbing.
I don't get it. Why new packages cannot be uploaded to unstable, when testing is in freeze?
Shouldn't it be allowed to upload to unstable, but not allowed to migrate from unstable to testing?
Why new packages cannot be uploaded to unstable, when testing is in freeze?
Not testing, but unstable. Unstable is in freeze. Testing migration is still available during freeze. No more new for unstable.
https://release.debian.org/buster/freeze_policy.html
Shouldn't it be allowed to upload to unstable, but not allowed to migrate from unstable to testing?
Upload to unstable (during freeze) is not allowed, as you can see your new package still in NEW queue. Migrate from unstable (uploaded before freeze) to testing is still working.
Thanks for clarification, TIL.
@jmkim What are your thoughts about packaging forks? We have a bunch of them here, so how are you going to do that?
I saw your email about this topic on debian-go IIRC, but... maybe something changed since then.
@jmkim Could you tell how are you keeping upstream git history? I can see it on salsa.
Could you tell how are you keeping upstream git history?
I'm dealing it with two remotes. One for upstream repo, another for Salsa repo.
Pull from upstream --> Push to Salsa.
I mean, what is your complete workflow when you are creating new package from scratch?
Are you using dh-make-golang in the process?
Well, try following the scratch section in the guide will make it happen 🤓
Oh, I forgot about this entry in Wiki. Thanks.
Are you using dh-make-golang in the process?
I use dh-make-golang only for creating debian directory templates.
Entire of "new workflow" is not yet impletented in dh-make-golang, so we should do with pure git commands. 😄
But is there really a value in doing this? Keeping the git history? Is it mandatory?
Some year ago, when Alioth use svn, cvs, git, etc.., at that time we could not keeping the git history. Now Alioth migrated to Salsa, we can keep the git history!
I think this have an huge advantage: commit histories will show implicit collaborators. Current Debian copyright file shows very strict collaborators.
Maybe another advantages are also there, but I didn't think deeply.
And what about existing repositories that doesn't have git history?
Like for example every repo I've pushed and many others on salsa.
It seems Go packaging team doesn't have an idea yet to pull all the git histories..
So for old packages, we keep old "pristine-tar" way until the solution found. And for new packages, we suggest to follow the new workflow for keeping the histories.
Some DD in Go packaging team says this is mendatory, and some not; there seems no fixed rule yet. I suggest you to follow new workflow for above reason.
Hmm, maybe it's time to send some PRs to Debian/dh-make-golang.
How to deal with circular dependencies?
I didn't try the packaging circular dependencies package before, so sorry I don't have that experience.
Thanks a lot for your bunch of active packaging contributes @dawidd6, now I think I need contribute actively. :) I'm currently packaging go-getter forked by Jesse: blocking the test which needs internet connection, which the Debian packaging policy needs.
If you didn't start packaging job for dependencies of mgutz/str, can I packaging it and its dependencies? I'll re-estimate the dependency graph and packaging them in next days.
I'll re-estimate the dependency graph
It seems although mgutz/str have circular dependencies, but as we can exclude the main.go in mgutz/str (which needs the dependencies) as lazygit needs this package as library.
Sure, be my guest. I haven't started any new packaging of any packages which issues aren't assigned to me.
Thanks, I'll finish go-getter very soon, and start packaging mgutz/str today.
Done for go-getter and mgutz/str with its dependencies.
I fully re-estimated the dependencies again, now here the latest dependencies graph.
These are the current statistics:
- 3 packages are excluded because of my over-estimate
- 6 packages needs a sponsor:
- 2 packages remaining:
Now I'm going to start the packaging gcfg #27, and then go-git.v4 #21. Did you already started the packaging for these two things?
Nope. I didn't start any new packaging as I said before. Please, go ahead.
That's unfortunate, because I've already ITPed and RFSed these 3 packages and what should I do with that now?
Isn't go-git depending on go-git-fixtures for tests? I would swear I saw so.
That's unfortunate, because I've already ITPed and RFSed these 3 packages and what should I do with that now?
You can wait for a sponsor, and the packages will used by other reverse-dependent packages in future.
Isn't go-git depending on go-git-fixtures for tests? I would swear I saw so.
You're right; so skip the part of or whole testing... although this isn't an ideal way. As go-git-fixtures is only for go-git testing, that should be vendored into go-git...
Your thoughts about go-git-fixtures?
Maybe disable the tests in go-git, upload go-git to archive, then upload go-git-fixtures and then enable tests back in go-git and bump package revision?
Or just embed it if you are comfortable with that.
Maybe disable the tests in go-git, upload go-git to archive, then upload go-git-fixtures and then enable tests back in go-git and bump package revision?
This seems make sense. 👍
I stuck by a lot of testing errors, so a lot of time was wasted for inspecting.. Now almost finished.. Will push to Salsa go-git and go-git-fixture together soon.
Finally I sent RFS for go-git. :"D
go-git-fixtures is also ready for RFS. Just after go-git uploaded, I'll send RFS for go-git-fixtures!
Yea, I saw. Good job!
Sooo, it's almost 2 months since the beginning of this show. Truly, packaging for Debian takes a big amount of time, damn.