You are not logged in. Please login or register.
Active topics Unanswered topics
Search options (Page 1 of 2)
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.
A/the standard way of versioning builds from git is
which yields
LAST_TAG-COMMITS_SINCE_THAT_TAG-LAST_COMMIT_HASH
+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.
[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
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.
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
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: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?
If you have a conflicting qelectrotech in your $PATH.
Posts found: 1 to 25 of 36
Generated in 0.012 seconds (50% PHP - 50% DB) with 5 queries