Bug#889997: git-buildpackage: gbp create-remote-repo should default to salsa, not git.debian.org
Hi. I just wanted to mention that there is already a command-line utility appropriately called `salsa` from the devscripts package. Perhaps it is worth mentioning it in gbp-create-remote-repo(1)? Or you may even drop it completely, although I don't think you would like to do that. Cheers, Akbar.
Bug#889997: git-buildpackage: gbp create-remote-repo should default to salsa, not git.debian.org
* Daniel Kahn Gillmor [Fri Feb 09, 2018 at 03:52:08PM -0500]: > alioth (which provided git.debian.org) is reaching end of life. > debian developers are encouraged to use salsa.debian.org instead. gbp > create-remote-repo has some defaults which point to alioth, which > should point to salsa instead. The manpage of gbp-create-remote-repo(1) still refers to collab-maint: | Note: By default, the remote repositories are created in the collab-maint repository on git.debian.org. Maybe that should be disabled for buster and adjusted in the manpage, at least if the changes regarding supporting and defaulting to salsa don't make it into gbp in time? Thanks for gbp! regards, -mika- signature.asc Description: Digital signature
Bug#889997: git-buildpackage: gbp create-remote-repo should default to salsa, not git.debian.org
Le mardi 13 février 2018 à 10:07:52+0100, Guido Günther a écrit : > On Tue, Feb 13, 2018 at 09:56:28AM +0100, Pierre-Elliott Bécue wrote: > > Le mardi 13 février 2018 à 09:45:43+0100, Guido Günther a écrit : > > > we can leave most of these out since they're not required: > > > > > > https://docs.gitlab.com/ce/api/projects.html#create-project > > > > Yes, but the defaults seem awkward to me for Debian git repositories, hence > > the suggestion to set them. > > I was hoping that not setting anything would use the salsa wide > defaults? If not we set them to the same values that you get by default. Nah, have a look at the output json example I pasted. It's as you wish, but this default json seems really appropriate to me, at least for the public vs private status of the project. > > > > The only required intel is actually the project's name. > > > > > > Python has plenty json api packages to send such json, so it's a matter > > > > of > > > > implementation. > > > > > > We already use requests for http so this can be used to simplify things > > > furhter. There's also python3-gitlab. > > > > Should we try to rely on p3-gitlab or to stick with requests? > > Both is fine with me. The later would have the advantage that we could > use it later to set hooks like the hook_tagpending.sh in salsa-scripts. > If using p3-salsa we should make the use optional, that is fail if one > wants to create a repo on salsa without p3-gitlab installed (so it stays > simple for folks to port to other distros). I'll give a try with requests. > > > > I could take some time to code that, but I'd rather we agree on the > > > > "how" > > > > and the "what" before spending any time in such work. > > > > > > Would be great. Especially since we'd need some logic to figure out if > > > the remote end is using gitlab. For the moment we could just do: > > > > > >--remote-type=git+ssh (old behaviour) > > >--remote-type=gitlab (what you just describe) > > >--remote-type=auto > > > > > > The last option could just look into a fixed list within create_repo > > > > > >gitlab_hosts = ['salsa.debian.org'] > > > > > > to figure out what to do. > > > > Could you help me confirming what are the different steps supposed to be > > handled by create-remote-repo? > > > > I assume it's roughly these: > > > > 1. Find the url and determine the configurations, in particular, check if > > such a remote doesn't alreaty exist in the .git/config file. > > Yes, gbp-create-repo does this already. > > > 2. Create the actual remote repo > > 3. Update the local git config with this remote. > > 4. Push to this new remote. > > Yes, see create_repo. The only part that needs to be adjusted is around > build_remote_script. > > > > > Am I right? > > Yes, most of this is already here. As a bonus we could resolve insteadOf > references but that could be a different patch/bug. Alright, I'll give it a look and a try. Cheers, -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 signature.asc Description: PGP signature
Bug#889997: git-buildpackage: gbp create-remote-repo should default to salsa, not git.debian.org
On Tue, Feb 13, 2018 at 09:56:28AM +0100, Pierre-Elliott Bécue wrote:
> Le mardi 13 février 2018 à 09:45:43+0100, Guido Günther a écrit :
> > Hi,
> > On Mon, Feb 12, 2018 at 06:10:09PM +0100, Pierre-Elliott Bécue wrote:
> > > Speaking to the gitlab API is actually quite simple.
> > >
> > > The user has to create his own private token with API access. Then gbp
> > > would require a new config parameter to fetch such a token from the
> > > .gitconfig of the user, or a new option to the create-remote-repo command
> > > to
> > > provide it.
> > >
> > > Then, if the user wants to create the repo in a specific namespace (group,
> > > subgroup, whatever), he has to fetch the appropriate namespace_id. I
> > > didn't
> > > find a basic method so far, but some urls contain it, so I found 2781 for
> > > DPMT subgroup.
> > >
> > > Then, it's only about designing a POST request:
> > >
> > > I made a simple json file: temp/test.json
> > > {
> > > "name": "apiproject",
> > > "namespace_id": 2781
> > > }
> > >
> > > Then, I ran
> > >
> > > # curl -X "POST" -H 'Private-Token: {{priv_token}}' -H "Content-Type:
> > > application/json; charset=utf-8" https://salsa.debian.org/api/v4/projects
> > > -d "$(cat temp/test.json)"
> > >
> > > {
> > > "id":12590,
> > > "description":null,
> > > "name":"apiproject",
> > > "name_with_namespace":"Debian Python Team / DPMT / apiproject",
> > > "path":"apiproject",
> > > "path_with_namespace":"python-team/modules/apiproject",
> > > "created_at":"2018-02-12T16:54:58.691Z",
> > > "default_branch":null,
> > > "tag_list":[],
> > >
> > > "ssh_url_to_repo":"g...@salsa.debian.org:python-team/modules/apiproject.git",
> > >
> > > "http_url_to_repo":"https://salsa.debian.org/python-team/modules/apiproject.git;,
> > > "web_url":"https://salsa.debian.org/python-team/modules/apiproject;,
> > > "avatar_url":null,
> > > "star_count":0,
> > > "forks_count":0,
> > > "last_activity_at":"2018-02-12T16:54:58.691Z",
> > > "_links":{
> > > "self":"http://salsa.debian.org/api/v4/projects/12590;,
> > >
> > > "merge_requests":"http://salsa.debian.org/api/v4/projects/12590/merge_requests;,
> > >
> > > "repo_branches":"http://salsa.debian.org/api/v4/projects/12590/repository/branches;,
> > > "labels":"http://salsa.debian.org/api/v4/projects/12590/labels;,
> > > "events":"http://salsa.debian.org/api/v4/projects/12590/events;,
> > > "members":"http://salsa.debian.org/api/v4/projects/12590/members;
> > > },
> > > "archived":false,
> > > "visibility":"private",
> > > "resolve_outdated_diff_discussions":false,
> > > "container_registry_enabled":true,
> > > "issues_enabled":false,
> > > "merge_requests_enabled":true,
> > > "wiki_enabled":true,
> > > "jobs_enabled":true,
> > > "snippets_enabled":true,
> > > "shared_runners_enabled":true,
> > > "lfs_enabled":true,
> > > "creator_id":1983,
> > > "namespace":{
> > > "id":2781,
> > > "name":"DPMT",
> > > "path":"modules",
> > > "kind":"group",
> > > "full_path":"python-team/modules",
> > > "parent_id":2779
> > > },
> > > "import_status":"none",
> > > "import_error":null,
> > > "runners_token":"such_token_much_wow",
> > > "public_jobs":true,
> > > "ci_config_path":null,
> > > "shared_with_groups":[],
> > > "only_allow_merge_if_pipeline_succeeds":false,
> > > "request_access_enabled":false,
> > > "only_allow_merge_if_all_discussions_are_resolved":false,
> > > "printing_merge_request_link_enabled":true
> > > }
> > >
> > > So, there are some parameters that'd require a default:
> > >
> > > I suggest this template json for creating a remote repo:
> > >
> > > {
> > > "name": "%(name)s",
> > > "namespace_id": %(namespace_id)d (if provided),
> > > "issues_enabled": true,
> > > "visibility": "public",
> > > "only_allow_merge_if_all_discussions_are_resolved": true
> > > }
> >
> > we can leave most of these out since they're not required:
> >
> > https://docs.gitlab.com/ce/api/projects.html#create-project
>
> Yes, but the defaults seem awkward to me for Debian git repositories, hence
> the suggestion to set them.
I was hoping that not setting anything would use the salsa wide
defaults? If not we set them to the same values that you get by default.
>
> The only required intel is actually the project's name.
>
> > > Python has plenty json api packages to send such json, so it's a matter of
> > > implementation.
> >
> > We already use requests for http so this can be used to simplify things
> > furhter. There's also python3-gitlab.
>
> Should we try to rely on p3-gitlab or to stick with requests?
Both is fine with me. The later would have the advantage that we could
use it later to set hooks like the hook_tagpending.sh in salsa-scripts.
If using p3-salsa we should make
Bug#889997: git-buildpackage: gbp create-remote-repo should default to salsa, not git.debian.org
Le mardi 13 février 2018 à 09:45:43+0100, Guido Günther a écrit :
> Hi,
> On Mon, Feb 12, 2018 at 06:10:09PM +0100, Pierre-Elliott Bécue wrote:
> > Speaking to the gitlab API is actually quite simple.
> >
> > The user has to create his own private token with API access. Then gbp
> > would require a new config parameter to fetch such a token from the
> > .gitconfig of the user, or a new option to the create-remote-repo command to
> > provide it.
> >
> > Then, if the user wants to create the repo in a specific namespace (group,
> > subgroup, whatever), he has to fetch the appropriate namespace_id. I didn't
> > find a basic method so far, but some urls contain it, so I found 2781 for
> > DPMT subgroup.
> >
> > Then, it's only about designing a POST request:
> >
> > I made a simple json file: temp/test.json
> > {
> > "name": "apiproject",
> > "namespace_id": 2781
> > }
> >
> > Then, I ran
> >
> > # curl -X "POST" -H 'Private-Token: {{priv_token}}' -H "Content-Type:
> > application/json; charset=utf-8" https://salsa.debian.org/api/v4/projects
> > -d "$(cat temp/test.json)"
> >
> > {
> > "id":12590,
> > "description":null,
> > "name":"apiproject",
> > "name_with_namespace":"Debian Python Team / DPMT / apiproject",
> > "path":"apiproject",
> > "path_with_namespace":"python-team/modules/apiproject",
> > "created_at":"2018-02-12T16:54:58.691Z",
> > "default_branch":null,
> > "tag_list":[],
> >
> > "ssh_url_to_repo":"g...@salsa.debian.org:python-team/modules/apiproject.git",
> >
> > "http_url_to_repo":"https://salsa.debian.org/python-team/modules/apiproject.git;,
> > "web_url":"https://salsa.debian.org/python-team/modules/apiproject;,
> > "avatar_url":null,
> > "star_count":0,
> > "forks_count":0,
> > "last_activity_at":"2018-02-12T16:54:58.691Z",
> > "_links":{
> > "self":"http://salsa.debian.org/api/v4/projects/12590;,
> >
> > "merge_requests":"http://salsa.debian.org/api/v4/projects/12590/merge_requests;,
> >
> > "repo_branches":"http://salsa.debian.org/api/v4/projects/12590/repository/branches;,
> > "labels":"http://salsa.debian.org/api/v4/projects/12590/labels;,
> > "events":"http://salsa.debian.org/api/v4/projects/12590/events;,
> > "members":"http://salsa.debian.org/api/v4/projects/12590/members;
> > },
> > "archived":false,
> > "visibility":"private",
> > "resolve_outdated_diff_discussions":false,
> > "container_registry_enabled":true,
> > "issues_enabled":false,
> > "merge_requests_enabled":true,
> > "wiki_enabled":true,
> > "jobs_enabled":true,
> > "snippets_enabled":true,
> > "shared_runners_enabled":true,
> > "lfs_enabled":true,
> > "creator_id":1983,
> > "namespace":{
> > "id":2781,
> > "name":"DPMT",
> > "path":"modules",
> > "kind":"group",
> > "full_path":"python-team/modules",
> > "parent_id":2779
> > },
> > "import_status":"none",
> > "import_error":null,
> > "runners_token":"such_token_much_wow",
> > "public_jobs":true,
> > "ci_config_path":null,
> > "shared_with_groups":[],
> > "only_allow_merge_if_pipeline_succeeds":false,
> > "request_access_enabled":false,
> > "only_allow_merge_if_all_discussions_are_resolved":false,
> > "printing_merge_request_link_enabled":true
> > }
> >
> > So, there are some parameters that'd require a default:
> >
> > I suggest this template json for creating a remote repo:
> >
> > {
> > "name": "%(name)s",
> > "namespace_id": %(namespace_id)d (if provided),
> > "issues_enabled": true,
> > "visibility": "public",
> > "only_allow_merge_if_all_discussions_are_resolved": true
> > }
>
> we can leave most of these out since they're not required:
>
> https://docs.gitlab.com/ce/api/projects.html#create-project
Yes, but the defaults seem awkward to me for Debian git repositories, hence
the suggestion to set them.
The only required intel is actually the project's name.
> > Python has plenty json api packages to send such json, so it's a matter of
> > implementation.
>
> We already use requests for http so this can be used to simplify things
> furhter. There's also python3-gitlab.
Should we try to rely on p3-gitlab or to stick with requests?
> > I could take some time to code that, but I'd rather we agree on the "how"
> > and the "what" before spending any time in such work.
>
> Would be great. Especially since we'd need some logic to figure out if
> the remote end is using gitlab. For the moment we could just do:
>
>--remote-type=git+ssh (old behaviour)
>--remote-type=gitlab (what you just describe)
>--remote-type=auto
>
> The last option could just look into a fixed list within create_repo
>
>gitlab_hosts = ['salsa.debian.org']
>
> to figure out what to do.
Could you help me confirming what are the different steps supposed to be
handled by
Bug#889997: git-buildpackage: gbp create-remote-repo should default to salsa, not git.debian.org
Hi,
On Mon, Feb 12, 2018 at 06:10:09PM +0100, Pierre-Elliott Bécue wrote:
> Speaking to the gitlab API is actually quite simple.
>
> The user has to create his own private token with API access. Then gbp
> would require a new config parameter to fetch such a token from the
> .gitconfig of the user, or a new option to the create-remote-repo command to
> provide it.
>
> Then, if the user wants to create the repo in a specific namespace (group,
> subgroup, whatever), he has to fetch the appropriate namespace_id. I didn't
> find a basic method so far, but some urls contain it, so I found 2781 for
> DPMT subgroup.
>
> Then, it's only about designing a POST request:
>
> I made a simple json file: temp/test.json
> {
> "name": "apiproject",
> "namespace_id": 2781
> }
>
> Then, I ran
>
> # curl -X "POST" -H 'Private-Token: {{priv_token}}' -H "Content-Type:
> application/json; charset=utf-8" https://salsa.debian.org/api/v4/projects -d
> "$(cat temp/test.json)"
>
> {
> "id":12590,
> "description":null,
> "name":"apiproject",
> "name_with_namespace":"Debian Python Team / DPMT / apiproject",
> "path":"apiproject",
> "path_with_namespace":"python-team/modules/apiproject",
> "created_at":"2018-02-12T16:54:58.691Z",
> "default_branch":null,
> "tag_list":[],
>
> "ssh_url_to_repo":"g...@salsa.debian.org:python-team/modules/apiproject.git",
>
> "http_url_to_repo":"https://salsa.debian.org/python-team/modules/apiproject.git;,
> "web_url":"https://salsa.debian.org/python-team/modules/apiproject;,
> "avatar_url":null,
> "star_count":0,
> "forks_count":0,
> "last_activity_at":"2018-02-12T16:54:58.691Z",
> "_links":{
> "self":"http://salsa.debian.org/api/v4/projects/12590;,
>
> "merge_requests":"http://salsa.debian.org/api/v4/projects/12590/merge_requests;,
>
> "repo_branches":"http://salsa.debian.org/api/v4/projects/12590/repository/branches;,
> "labels":"http://salsa.debian.org/api/v4/projects/12590/labels;,
> "events":"http://salsa.debian.org/api/v4/projects/12590/events;,
> "members":"http://salsa.debian.org/api/v4/projects/12590/members;
> },
> "archived":false,
> "visibility":"private",
> "resolve_outdated_diff_discussions":false,
> "container_registry_enabled":true,
> "issues_enabled":false,
> "merge_requests_enabled":true,
> "wiki_enabled":true,
> "jobs_enabled":true,
> "snippets_enabled":true,
> "shared_runners_enabled":true,
> "lfs_enabled":true,
> "creator_id":1983,
> "namespace":{
> "id":2781,
> "name":"DPMT",
> "path":"modules",
> "kind":"group",
> "full_path":"python-team/modules",
> "parent_id":2779
> },
> "import_status":"none",
> "import_error":null,
> "runners_token":"such_token_much_wow",
> "public_jobs":true,
> "ci_config_path":null,
> "shared_with_groups":[],
> "only_allow_merge_if_pipeline_succeeds":false,
> "request_access_enabled":false,
> "only_allow_merge_if_all_discussions_are_resolved":false,
> "printing_merge_request_link_enabled":true
> }
>
> So, there are some parameters that'd require a default:
>
> I suggest this template json for creating a remote repo:
>
> {
> "name": "%(name)s",
> "namespace_id": %(namespace_id)d (if provided),
> "issues_enabled": true,
> "visibility": "public",
> "only_allow_merge_if_all_discussions_are_resolved": true
> }
we can leave most of these out since they're not required:
https://docs.gitlab.com/ce/api/projects.html#create-project
> Python has plenty json api packages to send such json, so it's a matter of
> implementation.
We already use requests for http so this can be used to simplify things
furhter. There's also python3-gitlab.
> I could take some time to code that, but I'd rather we agree on the "how"
> and the "what" before spending any time in such work.
Would be great. Especially since we'd need some logic to figure out if
the remote end is using gitlab. For the moment we could just do:
--remote-type=git+ssh (old behaviour)
--remote-type=gitlab (what you just describe)
--remote-type=auto
The last option could just look into a fixed list within create_repo
gitlab_hosts = ['salsa.debian.org']
to figure out what to do.
Cheers,
-- Guido
Bug#889997: git-buildpackage: gbp create-remote-repo should default to salsa, not git.debian.org
Speaking to the gitlab API is actually quite simple.
The user has to create his own private token with API access. Then gbp
would require a new config parameter to fetch such a token from the
.gitconfig of the user, or a new option to the create-remote-repo command to
provide it.
Then, if the user wants to create the repo in a specific namespace (group,
subgroup, whatever), he has to fetch the appropriate namespace_id. I didn't
find a basic method so far, but some urls contain it, so I found 2781 for
DPMT subgroup.
Then, it's only about designing a POST request:
I made a simple json file: temp/test.json
{
"name": "apiproject",
"namespace_id": 2781
}
Then, I ran
# curl -X "POST" -H 'Private-Token: {{priv_token}}' -H "Content-Type:
application/json; charset=utf-8" https://salsa.debian.org/api/v4/projects -d
"$(cat temp/test.json)"
{
"id":12590,
"description":null,
"name":"apiproject",
"name_with_namespace":"Debian Python Team / DPMT / apiproject",
"path":"apiproject",
"path_with_namespace":"python-team/modules/apiproject",
"created_at":"2018-02-12T16:54:58.691Z",
"default_branch":null,
"tag_list":[],
"ssh_url_to_repo":"g...@salsa.debian.org:python-team/modules/apiproject.git",
"http_url_to_repo":"https://salsa.debian.org/python-team/modules/apiproject.git;,
"web_url":"https://salsa.debian.org/python-team/modules/apiproject;,
"avatar_url":null,
"star_count":0,
"forks_count":0,
"last_activity_at":"2018-02-12T16:54:58.691Z",
"_links":{
"self":"http://salsa.debian.org/api/v4/projects/12590;,
"merge_requests":"http://salsa.debian.org/api/v4/projects/12590/merge_requests;,
"repo_branches":"http://salsa.debian.org/api/v4/projects/12590/repository/branches;,
"labels":"http://salsa.debian.org/api/v4/projects/12590/labels;,
"events":"http://salsa.debian.org/api/v4/projects/12590/events;,
"members":"http://salsa.debian.org/api/v4/projects/12590/members;
},
"archived":false,
"visibility":"private",
"resolve_outdated_diff_discussions":false,
"container_registry_enabled":true,
"issues_enabled":false,
"merge_requests_enabled":true,
"wiki_enabled":true,
"jobs_enabled":true,
"snippets_enabled":true,
"shared_runners_enabled":true,
"lfs_enabled":true,
"creator_id":1983,
"namespace":{
"id":2781,
"name":"DPMT",
"path":"modules",
"kind":"group",
"full_path":"python-team/modules",
"parent_id":2779
},
"import_status":"none",
"import_error":null,
"runners_token":"such_token_much_wow",
"public_jobs":true,
"ci_config_path":null,
"shared_with_groups":[],
"only_allow_merge_if_pipeline_succeeds":false,
"request_access_enabled":false,
"only_allow_merge_if_all_discussions_are_resolved":false,
"printing_merge_request_link_enabled":true
}
So, there are some parameters that'd require a default:
I suggest this template json for creating a remote repo:
{
"name": "%(name)s",
"namespace_id": %(namespace_id)d (if provided),
"issues_enabled": true,
"visibility": "public",
"only_allow_merge_if_all_discussions_are_resolved": true
}
Python has plenty json api packages to send such json, so it's a matter of
implementation.
I could take some time to code that, but I'd rather we agree on the "how"
and the "what" before spending any time in such work.
--
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2
signature.asc
Description: PGP signature
Bug#889997: git-buildpackage: gbp create-remote-repo should default to salsa, not git.debian.org
Hi, On Fri, Feb 09, 2018 at 03:52:08PM -0500, Daniel Kahn Gillmor wrote: > Package: git-buildpackage > Version: 0.9.7 > Severity: wishlist > > alioth (which provided git.debian.org) is reaching end of life. > debian developers are encouraged to use salsa.debian.org instead. gbp > create-remote-repo has some defaults which point to alioth, which > should point to salsa instead. Good point! Salsa doesn't allow to create remote repos via ssh so we need to talk to the gitlab API here. Just pointing it out in case someone wants to cook up a patch. The code that needs to be adjusted is in gbp/scripts/create_remote_repo:do_create around the build_cmd invocation. Cheers, -- Guido > > thanks for maintaining gbp! > >--dkg > > -- System Information: > Debian Release: buster/sid > APT prefers testing-debug > APT policy: (500, 'testing-debug'), (500, 'testing'), (500, 'oldstable'), > (200, 'unstable-debug'), (200, 'unstable'), (1, 'experimental-debug'), (1, > 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), > LANGUAGE=en_US.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages git-buildpackage depends on: > ii devscripts 2.17.12 > ii git1:2.15.1-3 > ii man-db 2.7.6.1-4 > ii python33.6.4-1 > ii python3-dateutil 2.6.1-1 > ii python3-pkg-resources 38.4.0-1 > > Versions of packages git-buildpackage recommends: > pn cowbuilder | pbuilder | sbuild > ii pristine-tar1.42 > ii python3-requests2.18.4-1 > > Versions of packages git-buildpackage suggests: > pn python3-notify2 > pn sudo > ii unzip6.0-21 > > -- no debconf information >
Bug#889997: git-buildpackage: gbp create-remote-repo should default to salsa, not git.debian.org
Package: git-buildpackage Version: 0.9.7 Severity: wishlist alioth (which provided git.debian.org) is reaching end of life. debian developers are encouraged to use salsa.debian.org instead. gbp create-remote-repo has some defaults which point to alioth, which should point to salsa instead. thanks for maintaining gbp! --dkg -- System Information: Debian Release: buster/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (500, 'oldstable'), (200, 'unstable-debug'), (200, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages git-buildpackage depends on: ii devscripts 2.17.12 ii git1:2.15.1-3 ii man-db 2.7.6.1-4 ii python33.6.4-1 ii python3-dateutil 2.6.1-1 ii python3-pkg-resources 38.4.0-1 Versions of packages git-buildpackage recommends: pn cowbuilder | pbuilder | sbuild ii pristine-tar1.42 ii python3-requests2.18.4-1 Versions of packages git-buildpackage suggests: pn python3-notify2 pn sudo ii unzip6.0-21 -- no debconf information
