Can't update from 8.0.1-rc2 to release

Software
1

Trying to update from the RC2 version of 8.0.1 to the final release version (and change from dev channel to release channel) is not going to plan.
Anyone know how to get the release version installed over the RC version?

What I’ve tried:

I cleared the apt sources files for dev train and ran the command to add the release apt repository, which generated the expected repository.

# pkcon repo-list | grep kicad
 Enabled    /etc/apt/sources.list.d/kicad-ubuntu-kicad-8_0-releases-jammy.list:deb https://ppa.launchpadcontent.net/kicad/kicad-8.0-releases/ubuntu/ jammy main ppa.launchpadcontent.net/kicad/kicad-8.0-releases/ubuntu - Jammy (main)
 Disabled   /etc/apt/sources.list.d/kicad-ubuntu-kicad-8_0-releases-jammy.list:deb-src https://ppa.launchpadcontent.net/kicad/kicad-8.0-releases/ubuntu/ jammy main ppa.launchpadcontent.net/kicad/kicad-8.0-releases/ubuntu - Jammy (main) Sources

# apt update
...
Fetched 189 kB in 3s (75.2 kB/s)    
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
All packages are up to date.

When I try and re-install, I just get the package is already at latest version:

# apt install kicad
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
kicad is already the newest version (8.0.1-rc2-testing~178+202403121707~1b3cf70eef~ubuntu22.04.1).
Starting pkgProblemResolver with broken count: 0
Starting 2 pkgProblemResolver with broken count: 0
Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

I tried reinstalling with pkcon (I’m on kde Neon):

# pkcon install --allow-reinstall kicad
Resolving                               [=========================]         
Testing changes                         [=========================]         
Finished                                [=========================]         
Installing                              [=========================]         
Loading cache                           [=========================]         
Finished                                [=========================]

But I’m still on RC2. From the version panel in kicad:

Application: KiCad x86_64 on x86_64
Version: 8.0.1-rc2-202403121707~1b3cf70eef~ubuntu22.04.1, release build
...
Platform: KDE neon 6.0, 64 bit, Little endian, wxGTK, X11, KDE, wayland
2

Try forcing a specific version.

First check if you can see the latest version.

apt-cache policy kicad

Then try install the specific version, in my case:

sudo apt install kicad=8.0.1-0~ubuntu23.10.1
1 Like
3

A bit unclear – are you 100% sure you disabled or removed all other kicad related ppa-repositories? And removed/purged the old kicad before installing again?

4

Thank you, that was the solution. I had to downgrade the install.
(I got the warning:
dpkg: warning: downgrading kicad from 8.0.1-rc2-testing~178+202403121707~1b3cf70eef~ubuntu22.04.1 to 8.0.1-1~ubuntu22.04.1)

I had tried to downgrade with pkcon before, but wasn’t successful. Using apt for the install install instead worked.

If others run into this.

Apt-cache returned:

$ sudo apt-cache policy kicad
kicad:
  Installed: 8.0.1-rc2-testing~178+202403121707~1b3cf70eef~ubuntu22.04.1
  Candidate: 8.0.1-rc2-testing~178+202403121707~1b3cf70eef~ubuntu22.04.1
  Version table:
 *** 8.0.1-rc2-testing~178+202403121707~1b3cf70eef~ubuntu22.04.1 100
        100 /var/lib/dpkg/status
     8.0.1-1~ubuntu22.04.1 500
        500 https://ppa.launchpadcontent.net/kicad/kicad-8.0-releases/ubuntu jammy/main amd64 Packages
     6.0.2+dfsg-1 500
        500 http://us.archive.ubuntu.com/ubuntu jammy/universe amd64 Packages

and apt list returned

$ apt list -a kicad
Listing... Done
kicad/now 8.0.1-rc2-testing~178+202403121707~1b3cf70eef~ubuntu22.04.1 amd64 [installed,local]
kicad/jammy 8.0.1-1~ubuntu22.04.1 amd64
kicad/jammy 6.0.2+dfsg-1 amd64

If anyone else is on KDE Neon 6.0, apparently
pkcon install --allow-downgrade kicad
doesn’t work quite right, so use apt instead.

5

I sometimes edit the text files in /etc/apt/sources.list.d with an editor.

6

I do too sometimes. But in this case, the issue was not with the apt sources list.
The issue was, that for some reason, and somehow, the 8.0.1 RC2 candidate was considered more recent than the actual 8.0.1 release. Apt and pkcon therefore thought, I was already on the most recent release, and would not install anything (or would just re-install the RC2 candidate if I forced the install).
I had to specifically request to downgrade to the release version for it to be installed.

7

It comes down to the sort ordering on version strings. I’m guessing that 8.0.1-r sorts higher than 8.0.1-1. Packagers have to be aware of this.

8

For the moment, this is expected: if you’re using testing builds, you will need to force a downgrade to move to stable builds. This is because we currently use the Git tag to form part of the version string, and the tag includes the -rcX part which causes it to look newer to Debian/Ubuntu’s sorting algorithm.

9

Thanks Jon,

Could I ask, if the download page can be amended with a comment explaining this?

I’m not a developer. I don’t normally installed nightly releases or release candidate software. My skill set is simply not in that area. I had to install the RC in this case, because none of the plugin I’m relying on for my boards, were working.

So for people like me, that don’t normally partake in juggling releases like this, it would be nice to have that note on the download page.

To the root cause of why I ended up running a RC.

So this is not a criticism of the KiCAD team. Not in any way shape of form. Heck, KDE released Neon 6.0 without the configuration files, that menu entries depends on, when a user wants to shut down or log out of the PC. Not that that is an often used use case :slight_smile:

So this is not a KiCAD team criticism at all.

When the generated package is missing entire files, I would have thought that a little animated man would run across the screen holding up a sign reading “Stop the Release”, or that screens would be flashing red, sirens would be blaring, the PC would forcefully shut down to prevent the package to be uploaded. :slight_smile:
OK, I’m kidding of cause. Did I mention I’m not a developer?

But I’m surprised that a QA process is not in place to confirm, that a release package installs correctly in a virgin VM, and that files that are expected to be install, was indeed installed, and that the configuration (like environment variables, configuration files, etc.) is set as expected.

Shipping a release, with files missing, is like the famed Ikea furniture, with the obligatory one screw less that what’s needed to assemble it.

Would it be possible to add a QA step to the release process, to pre-emptly eliminate such issue in the future?

10

Sure

You haven’t actually said what problem caused you to switch to testing builds, but I assume you’re talking about the Python on Ubuntu 22.04 problem.

We don’t currently have anyone volunteering to do such QA on Ubuntu. If someone wanted to volunteer to figure out how to do that, I’m sure we’d welcome it. For now, the Ubuntu PPA release process is automated, and there is no manual step between creating a release and making it available to the general public, so there is no opportunity to do any such testing. Normally, the fact that the testing PPA exists catches most problems, however this particular problem was an edge case that only showed up in the stable release PPA (and only for one Ubuntu version).

11

Yes, it was the python issue.
Maybe this topic is worth starting a separate thread on?
I mean, as a business consultant, I don’t think I have ever seen software deployed into a customers environment, where the installation media itself, as well as the installation process, had not been tested first.

It sounds a bit like taking backup’s every day, but never testing if the generated backup files actually work to restore a system.
I know that problems are reported rather quickly back to the team, and that you resolved the issue very quickly as well. But still, it took 3 weeks to release an update that resolved the installer issue.

I know that Linux is probably not the majority of your user base. So I’m not just thinking of Ubuntu packages here. But all the released packages. I’m guessing, that there must be some automation tools available out there, that can be spin up a virgin environment, install the app, and do a file compare back to the well known source, or an environment the application was tested in.

Maybe a fresh thread to call for input/suggestions/assistance would be warranted?

12

We also work at businesses, we are aware of the ideal workflow. But KiCad is not a business, so we work within the constraints of what we have.

Yes there are automation tools, but it is a significant task to set them up because it’s a per-platform type thing that needs constant maintenance to keep correct. QA is also a no glory job so it really doesn’t attract anyone to work on it. KiCad being very niche and not being software engineering related already makes it hard enough to attract people.

But I’m talking about automating it to actually run the app.

Just comparing where files are installed doesn’t require any of that and could be done at build time, however, just because files appear in the correct location, does not mean KiCad the application even loads them correctly. Which is where you need to start executing the app and operating the GUI.

Because there is a release schedule and we aren’t going to rush out an update for one issue in particular unless its a critical bug. (Critical meaning it impacts the correctness of designs or easily encountered data loss, etc)

2 Likes
13

Adding on to what Mark said, I’ll also note that if you want to become an actual customer, you can get a service contract with an actual business and then have higher expectations such as testing in your particular environment, packaging of releases before the upstream KiCad release, etc.

One of the ways that we maximize the value of the limited volunteer time we get from people is to offload some of the burden of testing and qualification onto users. Consider this: you got KiCad 8 for free, on a platform that most commercial EDA tool vendors do not support at all, and when a bug was discovered on your particular sub-sub variety of that platform, it was fixed within one day and a way to install a fixed version was provided for you, also for free.

3 Likes
14

Hah, you should have been in Australia a couple of months ago.
One of the Telcos threw a, not properly tested upgrade, at the wall, hoping it would stick. It didn’t.
10 million customers without any access to any type of phone or internet for 13 hours minimum: Govt. bodies, banks, private people. Huge compensation claims.

This is not the first time software stuff-ups have occurred down here. This is becoming an all to frequent occurrence as businesses try to cut costs and maximize profit; but this has nothing to do with Kicad, just a comment on the OP’s statement. :expressionless:

15

Considers these to be my parting words on this topic.

Firstly, to automatically assume that I am freeloading off the project, is both disappointing and hurtful.

Secondly, KiCad’s actions and deeds stands in stark contrast to your response.

At every presentation I’ve seen, costumers are celebrated, and KiCad boasts of it’s rising popularity, and actively implement features to grow market share and attract more corporate customers.

Now that version 8 is out, it sounds like now would be a good time to bring the team together around the camp fire, and discuss values, targets and priorities. Not from a software road map perspective, but from a project / not-for-profit / business perspective.

16

This is because we currently use the Git tag to form part of the version string, and the tag includes the -rcX part which causes it to look newer to Debian/Ubuntu’s sorting algorithm.

Yes and no.
For dpkg a version string is newer if the second string is “longer”, like here with the suffix “-rc[x]”, or is numeric/alphabetical behind the first version string. Esay to check by the option --compare-versions for dpkg.

e.g.

$ if $(dpkg --compare-versions "8.0.1-rc" "gt" "8.0.1-1"); then echo "is greater"; else echo "is not greater"; fi
is greater

The reason in detail is simply that “1-rc” (from 8.0.1 derived) makes the whole version greater than “1-1” (derived from 8.0.1-1).

The solution is simply, such versions like rc or -rc (for Release Candidates), a or -a (alpha version or also “b” for a beta version) and so on need to be separated with a tilde character “~”. Then dpkg knows that these versions are to be intended as not been greater.

$ if $(dpkg --compare-versions "8.0.1-1~rc1" "gt" "8.0.1-1"); then echo "is greater"; else echo "is not greater"; fi
is not greater

No big deal to extend the logic in any build script.

1 Like
17

If you know how to accomplish this “no big deal” in Ubuntu’s launchpad build system, please do share. Otherwise, this info is all stuff we already know.

18

Well, detect if “-rc” is in the tag or version and replace the hyphen with a tilde. I’ll definitely will not dive into the build of *.deb files in Ubuntu. Dealing sometimes with questions from Ubuntu users about the KiCad packages in Ubuntu is already enough for me.

If you know this all then you know basically also how to solve this. The Debian build system is nothing new and decades old. But I’m sometimes surprised from creative solutions and scripts that are not smart enough to build package automatically in all cases.
Advising users they need to downgrade first a package is a worse answer and gives users a bad impression. In Debian would be such a behavior of a package a RC issue.

19

Detect how, and replace how? That’s the problem. The Ubuntu packages are not built with a script, so there is no scripting language to do that detection and replacement. This is the thing that if you or anyone knows a solution for, we could use.

The Ubuntu build system on Launchpad is not the Debian build system.

I would think Debian would never package a nightly build anyway. This issue only comes up when people use our nightly testing PPA and then want to stop using it.

20

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.