1

(13 replies, posted in News)

The mirror repository on GitHub has been created: https://github.com/qelectrotech/qelectr … rce-mirror

It is strictly a (complete) mirror, with only one-way synchronization. This means that pull requests there will be generally ignored.
If you have something to pull from, contact an upstream maintainer with your changes in a branch of your fork/repository.

@Laurent: The sync script is already set up and I need you to add the cronjob; I don't have the rights to do so.

2

(13 replies, posted in News)

A/the standard way of versioning builds from git is

git describe

which yields

LAST_TAG-COMMITS_SINCE_THAT_TAG-LAST_COMMIT_HASH

Done & synced & is building.

https://github.com/qelectrotech/qelectr … d82f8f021d

4

(13 replies, posted in News)

+1

It's probably also a good idea to limit push access to master to only core maintainers.
People should push code to their branch and the maintainer should then review & merge said changes to master.

In any case, development will be easier in the long run.

Bien sûr!

6

(8 replies, posted in News)

[justify]You don't need snap run.[/justify]

Just

qelectrotech.qet-tb-generator etc. is enough.

Hi Laurent,

I propose something like "0.70-RC1~svn5936.snap", so the user know it's a snap build.

I'd also like to stick with ~svn instead of +svn. I was tought that ~svnX means "the version, that corresponds to svn revision X". Whereas "VERSION+svnX" means "VERSION plus X commits thereafter in svn".

Cheers
Max

8

(8 replies, posted in News)

The snaps are automatically built from https://github.com/qelectrotech/qelectrotech-git-mirror master, which is synced from svn trunk daily.

Snaps have multiple channels that represent the risk level of an installation: https://docs.snapcraft.io/channels

We publish daily builds (only if trunk has changed, of course) to the edge channel, so only install that channel if you don't mind frequent updates.

Every few revisions, a select revision will be promoted to the candidate or beta channel. Follow those channels for less frequent updates and thus slightly older revisions.

On release of 0.7, this will be promoted to the stable channel. Installing that channel will be the most conservative option.

Maybe we hop into the IRC channel to debug this together? If you have the time...

So it does not launch for you from "Project" -> "Launch the terminal block creation plugin"?
For me that works quite nicely.

Thanks for the PyPI tip!

I have an idea for the amdgpu.ids problem. Time for another revision...

Laurent,

I'd like to set up auto-build on commit. For that purpose I created an issue here:

https://github.com/ppd1990/qelectrotech-snap/issues/3

Could you please chime in there and tell me if you have a strong preference for one of the proposed ways forward?

Max

I pushed a new revision (#2) to the store.

Changes:

- libdrm2 added for AMD GPUs
- DXFtoQET included (can be run standalone as qelectrotech.dxf-to-qet or from QElectroTech)
- qet-tb-generator included (can be run standalone as qelectrotech.qet-tb-generator or from QElectroTech)
- HIDPI adjustments for DXFtoQET
- add desktop-legacy plug

Please test and file issues at https://github.com/ppd1990/qelectrotech-snap/issues

Cheers
Max

Remove the s from your https_proxy so it looks like https_proxy=http://...

Great stuff. I'll push an updated version tomorrow/later and I hope you'll give it a thorough review.

Also for packaging (as in this case) and for development. I would hardly consider sending a patch or pull request for something that only exists visibly on the pypi registry.

For the moment I'll just include the source you attached in the packaging repo.

scorpio810 wrote:

We use Tuxfamily.org hosting and services, and I love it.  nomicons/cool
https://faq.tuxfamily.org/Services/En

Joining us is not that complicated, except maybe for Windows users but WSL2 is coming .. on Win10.. https://devblogs.microsoft.com/commandl … ing-wsl-2/
https://qelectrotech.org/wiki_new/doc/rejoin_project

No worries, I haven't worked with Windows in about 15 years. That's not the issue.
I just think qet_tb_generator should have a repository so it can be properly cloned. That may be on tuxfamily for all I care.

I bet you have incorrectly set a https_proxy. Can you show me

echo $https_proxy

and

cat /etc/environment

and

cat

/etc/systemd/system/snapd.service.d/proxy.conf

Or just in general:

env|grep http

I suspect you have set https_proxy=https://something when it should be https_proxy=http://something

Thank you, I think I can do it via pip and a bit of hackery.

The QElectroTech project & friends are quite oldschool regarding the source distribution for my juvenile taste, that's all nomicons/laughing

I think it's a good idea to host as much stuff as accessible as possible. Maybe putting qet-tb-generator on Github isn't too bad of an idea.

I don't think we will be able to access the system's python packages. It must be installed into the snap itself or be exposed with another snap.

Laurent,

do you know where to find the source/repo of qet_tb_generator? Or does only the pypi package exist?

scorpio810 wrote:
ppd wrote:

We can fix all that and include those in the snap. Let's track all snap related deficiencies @ https://github.com/ppd1990/qelectrotech-snap/issues

Strange file exists.
ls -al /usr/share/libdrm/amdgpu.ids
-rw-r--r-- 1 root root 6682 janv. 22 17:32 /usr/share/libdrm/amdgpu.ids

The snaps run strictly confined, so it does not see that file unless we include it. I'm preparing an update for the snap as we speak to test a fix.

It is possible to package them separately and then join them via the content interface.

But far simpler is this solution: Just ship everything in the qelectrotech snap itself. That's really easy to do with snapcraft.

What do you think?

We can fix all that and include those in the snap. Let's track all snap related deficiencies @ https://github.com/ppd1990/qelectrotech-snap/issues

Interesting.

/usr/share/libdrm/amdgpu.ids is in libdrm-common. I'll try to find out if that's something we need to fix.

The libraries are those of base: core18, i.e. Ubuntu 18.04. This is to provide a unified platform for snaps so they are easy to support on tons of systems.

Of course it'd be possible to compile & include newer Qt libraries, but that's considerably more work.

Looks good then. Does it run?

snap run qelectrotech

If you have a conflicting qelectrotech in your $PATH.