Stable stretch release

[ddemidov]

Branched stretch-stable off of jessie, bumped it to 06ae05f and added a changelog entry.

See #381 (comment)

[WasabiFan]

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?

[ddemidov]

@WasabiFan, as I understood from #381 (comment), testing here is enough for the package to end up in the stretch repo.

[ddemidov]

Wrong link. Should be #339 (comment)

[WasabiFan]

I was thinking of debian/compat, but it looks like that's already pointing to Stretch...

[ddemidov]

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.

[WasabiFan]

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?

[ddemidov]

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.

[WasabiFan]

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?

[ddemidov]

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.

[WasabiFan]

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.

[ddemidov]

Kept #366, dropped the rest.

[WasabiFan]

Looks good to me. Not an expert on Debian packaging though.

[WasabiFan]

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

[ddemidov]

I am stuck with #381 (comment).

[dlech]

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.

[dlech]

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?

[dlech]

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

[dlech]

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?

[dlech]

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.

[dlech]

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

[ddemidov]

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.

[ddemidov]

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