We need to update the files in debian/ to point to the new OS version. Also, don't we want to update the package name and module name here to ev3dev2 since this is the first Stretch release?

Also, don't we want to update the package name and module name here to ev3dev2 since this is the first Stretch release?

This is intended as an OpenRoberta-compatible release, which means it is still v1 and we don't need to rename the package. v2 would be the future release.

Ok, that makes sense. Shouldn't we publish a Jessie release too to keep parity? Additionally, this branching feels wierd... Is your plan to cherry-pick the changelog commit to our develop branch later?

Shouldn't we publish a Jessie release too to keep parity?

Functionally, this is on par with our jessie release, so I don't see the need to update that.

Additionally, this branching feels wierd... Is your plan to cherry-pick the changelog commit to our develop branch later?

This is actually far behind our develop branch, so I don't see how we could do that.

Functionally, this is on par with our jessie release, so I don't see the need to update that

The current Jessie release lacks the motor pair classes, I believe. Same with the friendly errors.

This is actually far behind our develop branch, so I don't see how we could do that.

That's the idea behind git cherry-pick: apply the patch from a commit or multiple commits to a separate commit history line (i.e., different parent, but same changes and author). I suppose the question I'm really asking is: was your plan to work off of this branch in the future? Or something else?

The current Jessie release lacks the motor pair classes, I believe. Same with the friendly errors.

Hmm, then I would just drop those commits from this branch as well. The idea is provide a version minimally compatible with stretch but otherwise identical to our last jessie release, to make @ensonic happy.

That's the idea behind git cherry-pick: apply the patch from a commit or multiple commits to a separate commit history line (i.e., different parent, but same changes and author). I suppose the question I'm really asking is: was your plan to work off of this branch in the future? Or something else?

I understand how the cherry-pick works, but I would just start from scratch with the changelog when we are ready to release v2. Again, I consider this branch a dead-end only meant to keep OpenRoberta afloat while we are working on v2.

OK, that seems fine to me. I do believe that you'll want to drop some of the intermediate changes from this branch to keep parity with the current Jessie release.

Kept #366, dropped the rest.

@ddemidov How'd releasing this go? Did you get it published or were there still some packaging issues?

I am stuck with #381 (comment).

Following up to #381 (comment)

I have the following in ~/.pbuilderrc (only the first line should be effective).

APTCACHEHARDLINK=no
#DEBBUILDOPTS="-sa"

#APTKEYRINGS="/usr/share/keyrings/ev3dev-archive-keyring.gpg"

Edit: I think the reason I have APTCACHEHARDLINK=no is because my /home/ is on a separate file system (partition). It shouldn't make a difference otherwise.

Here is how travis runs pbuilder-ev3dev: https://github.com/ev3dev/pbuilder-ev3dev/blob/master/.travis.yml#L15

Maybe there is a missing dependency in the package?

Also, some other repositories use pbuilder-ev3dev in travis sucessfully: https://github.com/ev3dev/brickman/blob/ev3dev-stretch/.travis.yml

Here is a successful log to compare: https://travis-ci.org/ev3dev/brickman/jobs/214739979#L1357

One thing I noticed is that /etc/mailname seems to be missing in your log. On my computer, this file contains the hostname.

After that is

E: gnupg, gnupg2 and gnupg1 do not seem to be installed, but one of them is required for this operation

that we discussed already. Perhaps none of these commands are in $PATH for root/fakeroot?

I have also updated http://www.ev3dev.org/docs/devtools/installing-the-ev3dev-archive/

There is a new PPA for getting ev3dev development tools. I'm not sure if it has a newer version of pbuilder-ev3dev or not.

Missing gnupg was fixed in pbuilder-ev3dev v1.0.1: ev3dev/pbuilder-ev3dev@e8c7da1

It was an error on my side. I had an outdated version of pbuilder-ev3dev in my ~/bin for some reason (I have probably set up my packaging image before pbuilder-ev3dev debian package was a thing). Removing that solved the issue with missing gnupg.

Sorry for the noise.

Closed this by mistake. I've pushed the changes to stretch-stable, and uploaded the packages to the package repository.