Built packages are uploaded to wrong repo

[santileortiz]

I just released version 0.9.5 of Iconoscope. After updating to the latest version with App Center, the version actually running is 0.1.4 not 0.9.5.

The content of the installed .deb package /var/cache/apt/archives/com.github.santileortiz.iconoscope_0.9.5_amd64.deb, is for version 0.1.4, even though the name states it should be 0.9.5.

I checked that running debuild -us -uc in the deb-packaging-juno branch does create a package with the correct content for version 0.9.5.

Also, Travis CI is failing with the following error

================================================================================
# Internal error while running
Cannot copy '../nopt/bin/nopt.js' to a subdirectory of itself, '../nopt/bin/nopt.js'.
Error: Cannot copy '../nopt/bin/nopt.js' to a subdirectory of itself, '../nopt/bin/nopt.js'.
    at fs.readlink (/home/travis/build/santileortiz/Iconoscope/node_modules/fs-extra/lib/copy/copy.js:190:21)
    at FSReqWrap.oncomplete (fs.js:141:20)
================================================================================
The command "houston ci" exited with 1.

Maybe Travis failing is related to the old version of the App being packaged?

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[btkostner]

For the travis issues:

1. You should have your .travis.yml in all of your branches so you test all PRs and commits
2. Your travis file is out of date. Take a look and copy from here: https://github.com/elementary/houston/wiki/Continuous-Integration#standard-travisyml

[btkostner]

As for the release, houston made a 0.9.5 version for Loki and Juno (because you have the two packaging branches). When you make a release on github, it is against the master branch. So when releasing, the files got merged like so:

Loki: 0.9.5 tag (from master) < deb-packaging-loki branch Juno: 0.9.5 tag (from master) < deb-packaging-juno branch

Considering that the Loki version hasn't been updated in a while, I would consider dropping that branch, updating the master branch to latest, then placing only the debian/ folder in your deb-packaging-juno branch.

[btkostner]

Considering that it looks like Houston is doing the correct thing, I'm going to close this issue. Feel free to keep commenting if you need help updating the repo.

[santileortiz]

Thanks for your help!, I actually was unsure about what happened with that Loki branch, I didn't want to make a release of 0.9.5 as I'm away from my test machine with Loki. I thought it would keep releasing version 0.1.4 there because that's the latest reachable tag from that branch (the one git describe --tags would show).

Is there any way to get notifications (maybe create a bug report?), whenever the .travis.yml file should change? or was this a one time thing that isn't supposed to happen often?.

[btkostner]

The packaging branches will always be used (will always release to that distro) if they exist when you press the release button. There is no way to hold a distro at a specific version, except for deleting the packaging branch.

Sadly, there is no way to get a notification about when the travis file needs to be updated. Luckily, it should not happen often. The last update was due to a dependency of houston, but the fix should fix any issues like that from happening again.

[santileortiz]

I still don't understand why I am getting version 0.1.4 in Juno, how are release branches merged together? is the deb-packaging-loki branch replacing the content of deb-packaging-juno?

I don't think I understand how release branches work. I thought what Houston did was clone deb-packaging-loki and package that for Loki, then clone deb-packaging-juno and package that for Juno. I wasn't aware of any merging happening between branches.

[btkostner]

I see what you are saying now. It seems the two packages where published to the incorrect distro repository. I'll try to debug what caused that.

Houston merges packaging branches with the release tag. That's why the packaging branches should only contain packaging and distro specific changes while the master branch contains the code.

setup build { architecture: 'amd64',
  distribution: 'loki',
  packageType: 'deb' }
references [ 'refs/tags/0.9.5', 'refs/remotes/origin/deb-packaging-loki' ]


setup build { architecture: 'amd64',
  distribution: 'juno',
  packageType: 'deb' }
references [ 'refs/tags/0.9.5', 'refs/remotes/origin/deb-packaging-juno' ]

[santileortiz]

Alright I think I had misunderstood the documentation about release branches. I will delete all code from the Juno and Loki branches. Do you think making a new release after this will fix the issue?, if so, are you using my repository to debug the issue, or can I make these changes now?

[btkostner]

Don't do a release yet please. I think there might still be a problem with publishing. I'll look into it and report back when I think it's safe for a new release.

[geigi]

A new version of cozy was just published and the Juno package is missing a dependency only the juno branch contains (python3-peewee): https://github.com/geigi/cozy/blob/deb-packaging-juno/debian/control Is this related to this issue (build packages are uploaded to wrong repo)?

This is the output for the dependencies after installing from AppCenter:

$ apt-cache depends com.github.geigi.cozy 
com.github.geigi.cozy
  PreDepends: dpkg
    dpkg:i386
 |Depends: dconf-gsettings-backend
  Depends: <gsettings-backend>
    dconf-gsettings-backend
  Depends: python3
  Depends: python3-mutagen
  Depends: python3-cairo
  Depends: python3-gst-1.0
  Depends: file
    file:i386
  Depends: libgstreamer1.0-0
  Depends: libgstreamer-plugins-base1.0-0
  Depends: gstreamer1.0-plugins-good

Cozy issue for reference: https://github.com/geigi/cozy/issues/141

[btkostner]

@geigi Yes. Looks like it's the same issue.

[geigi]

@btkostner I'd love to give you a helping hand in fixing this issue or even creating a PR. Do you have an idea where the bug might be or do you have a starting point for me?

[btkostner]

I spent about a week debugging Houston itself and then checking our repository server config. I found nothing out of the ordinary. I hoped taking a bit of time off this issue would help and I could find the issue after but still no luck. Sad to say, I have no idea where the issue is occurring.

[geigi]

Oh boy, I see... Thanks for your effort. Is there anything that is different in our packages or repos compared to most others? The only thing which comes to my mind are different required packages for the Loki and Juno branch...

[btkostner]

Most repos use different software, but they all form the correct file tree. It might be a bug in aptly but I highly doubt it. I can double check that when I get time though.

[geigi]

Thanks :) Do you think removing support for Loki would solve this issue? I'd love to support Loki but if we can't find a solution I'd rather only support Juno...

[btkostner]

@geigi Removing your loki branch should fix the issue