bring lazpaint to debian

[stavpup]

Move closer to make LazPaint as official debian package sometime in the future. So then installation would be as simple as "apt install lazpaint". Also upgrades would be automatic.

[fredvs]

Oops, I removed the first binary, it was in fact compiled using GTK2.

But the picture is ok.

The binary from last post is ok and compiled for Qt5. But on my Debian system there are problems to move the forms, I cannot move them.

[fredvs]

To compare (I prefer GTK2 menu but it is a question of taste, of course):

On the left, LazPaint GTK2, on the right LazPaint Qt5:

[alexmyczko]

can you run this?

dget http://phd-sid.ethz.ch/debian/lazpaint/5/lazpaint_6.4.1-1.dsc
dpkg-source -x lazpaint*.dsc

unpack your source code to lazpaint-7.1.5 copy the debian/* from lazpaint-6.4.1 over and run

dch -i (change version to 7.1.5)
debuild

and share the new .dsc ? :)

[circular17]

I have fixed the Qt5 bitmap problem and added a Qt5 build mode. It works ok, but there are some bugs with the tool windows. The message "Window is ready" pops up all the time.

I have avoided that locally by installing gnome extension to remove the notification. Note that it was not active after installation, had to go on this page again and toggle the On/Off switch. https://extensions.gnome.org/extension/1007/window-is-ready-notification-remover/

So that works but now another problem is that moving the tool windows doesn't work. Seems to be related to "stay on top" windows. Going into "View > Dock layers and colors" works though.

I have updated the upstream. Now in the Makefile, you just need to change BUILDMODE variable to ReleaseQt5 to build for Qt5 instead of Gtk. https://mentors.debian.net/package/lazpaint/ upload 6

[circular17]

Well before making a DSC version for 7.1.5, I would like to be sure version 6.4.1 is ok and also that version 7 is completely stable. I plan to publish a version 7.1.6 with little changes. Also will need to check what happens with Qt5 on version 7.

When version 6.4.1 is final, I add the release on my GitHub lazpaint-upstream.

[fredvs]

@circular17 : Do you have a idea what compiler make option must be added to switch GTK2 <> Qt5 ? This to update lazpaint.prj

[circular17]

I think it is -dLCLqt5 (to replace the current switch like -dLCLgtk)

[fredvs]

Hello.

Updated lazpaint.prj from lazpaint-upstream.

Works to compile LazPaint with GTK2, Qt, Qt5 and win32.

lazpaint.prj.zip

[circular17]

So it can be used to compile upstream? Where to put it (root dir or in lazpaint subdir)?

[fredvs]

Huh, it is there: https://github.com/bgrabitmap/lazpaint-upstream/blob/master/lazpaint/lazpaint.prj

I only updated it.

[fredvs]

The only thing to do was to create a /units dir in /lazpaint/ and ... (I will write it fast) copy-paste lazpaint.res in /lazpaint/

[fredvs]

All ok apart that with Qt5 widget, I cannot move the window-tools.

[alexmyczko]

Well before making a DSC version for 7.1.5, I would like to be sure version 6.4.1 is ok and also that version 7 is completely stable. I plan to publish a version 7.1.6 with little changes. Also will need to check what happens with Qt5 on version 7.

When version 6.4.1 is final, I add the release on my GitHub lazpaint-upstream.

@circular17 would be much better to start getting the latest version into debian sid (7.1.5 or 7.1.6) imho

and chances are gtk2 version will not make it through sponsor/ftp team, so let's go with qt5, and hopefully be able to fix the moving of tool windows... (unless gtk3 version builds and is better than qt5 version)

[circular17]

Here lazpaint.prj from lazpaint-upstream updated for Qt5.

Thanks. There are some "fred" in the file though. I suggest we call it lazpaint-qt.prj to have both gtk and qt version.

@circular17 would be much better to start getting the latest version into debian sid (7.1.5 or 7.1.6) imho

That will come.

and chances are gtk2 version will not make it through sponsor/ftp team, so let's go with qt5, and hopefully be able to fix the moving of tool windows... (unless gtk3 version builds and is better than qt5 version)

I am not going to do a Qt-only package. Some systems don't have Qt and some people (including me) are not comfortable with relying solely on it due to its corporate ties. Nevertheless I am not going either to drop Qt for the reason.

So question is, how do we provide both a Gtk and a Qt version of it? Using a virtual package? Providing two packages, like lazpaint-gtk and lazpaint-qt?

[fredvs]

There are some "fred" in the file though. I suggest we call it lazpaint-qt.prj to have both gtk and qt version.

Ooops I forgot this one more time. OK, I will fix + resent a empty one.

[alexmyczko]

Now that is getting fun, the trick is in debian/control

Find an example package dget'able at http://deb.debian.org/debian/pool/main/n/netsurf/netsurf_3.10-1.dsc

nothing to do with virtual packages we will just create not lazpaint but lazpaint-gtk and lazpaint-qt debian binary packages.

that means we need to build a -gtk and a -qt linked version in debian/rules and make them end up in the right places for deb generation.

[fredvs]

So question is, how do we provide both a Gtk and a Qt version of it? Using a virtual package? Providing two packages, like lazpaint-gtk and lazpaint-qt?

Maybe if all Qt bugs are fixed.

[fredvs]

Here empty lazpaint.prj

lazpaint.prj.zip

[circular17]

lazpaint.prj.zip

Oh ok so you added Qt/Qt5 build modes but there is still a Gtk build mode, right?

[fredvs]

lazpaint.prj.zip

Oh ok so you added Qt/Qt5 build modes but there is still a Gtk build mode, right?

Right.

Even more, now you may choose Gtk2 or Qt or Qt5 or win32 mode. Out-of-the-box, of course.

[alexmyczko]

i want to try cocoa with gnustep...

[fredvs]

i want to try cocoa with gnustep...

Hum, explain please. On a Linux machine?

[circular17]

I have fixed in a way the problem with tool windows. Basically, on Linux+Qt5, windows that are fsStayOnTop can't be moved, but, interestingly, dialog boxes are always on top of non dialog boxes. So what I've done, on Linux+Gt5, is that for toolboxes that are not sizable like Colors and Toolbox, they are now dialogs, and other toolboxes are just sizable windows.

In nutshell, toolboxes can now be moved, but sizable toolboxes like layers and image list are not always on top. That's not ideal but I guess people can live with that.

On Linux+Gtk, the tool windows Color and Layers, when attached to the main form, have their size changed when we try to move them. Maybe that won't happen with Gtk3?

So it is a bit of draw between Gtk2 and Qt5. At least both are usable now. I've put latest files on my website: http://johann-elsass.net/debian/lazpaint/

[circular17]

Now that is getting fun, the trick is in debian/control

Find an example package dget'able at http://deb.debian.org/debian/pool/main/n/netsurf/netsurf_3.10-1.dsc

I don't see any debian folder in the orig.tar.gz archive.

nothing to do with virtual packages we will just create not lazpaint but lazpaint-gtk and lazpaint-qt debian binary packages.

that means we need to build a -gtk and a -qt linked version in debian/rules and make them end up in the right places for deb generation.

So what to do in the rules file?

[alexmyczko]

you run dget theurl then dpkg-source -x the.dsc

to get debian/

it never is in the orig.tar.gz as that is what developers of the software release

[circular17]

Ok so, for what I understand in netsurf source:

• there can be multiple packages defined in the control file and including those for a particular target (here netsurf-gtk for gtk and netsurf-fb for frame buffer)
• in the rules file, the steps can be overridden to do them for different targets (via TARGET variable here)
• the Makefile can use the provided variable by using an optional assignment (here TARGET ?= gtk2)

But, how is it specified that one package would have a certain TARGET in the Makefile?

[alexmyczko]

multibin pkgs install to tmp then install puts them into binpkg-gtk and binpkg-qt for example with binpkg-gtk.install and the one for qt...

[circular17]

Ok so for this I would need to know in the Makefile which package it is. I have tried this:

%:
    dh $@ --no-parallel

override_dh_auto_build:
    dh_auto_build --no-parallel TARGET=Release MULTIBIN=1
    dh_auto_build --no-parallel TARGET=ReleaseQt MULTIBIN=1

override_dh_auto_install:
    dh_auto_install --no-parallel BUILDMODE=Release MULTIBIN=1
    dh_auto_install --no-parallel BUILDMODE=ReleaseQt MULTIBIN=1

override_dh_auto_clean:
    dh_auto_clean --no-parallel BUILDMODE=Release MULTIBIN=1
    dh_auto_clean --no-parallel BUILDMODE=ReleaseQt MULTIBIN=1

but in the Makefile the variable BUILDMODE does not seem to be set accordingly

[alexmyczko]

and if you export it a line ahead?

[circular17]

Maybe.

For now I will put the package version 6.4.1 with Qt5 on mentors. As Gtk3 is more experimental than Qt5 on Lazarus for now, I suppose it is ok to temporarily use Qt5. That's not perfect though for the interface, but at least a version will be officially out there.

I have notified Tobi on the RFS bug.

[circular17]

Hi people,

I have a found a way to do multiple packages: lazpaint-gtk2 and lazpaint-qt5. There are in conflict with each other and with "lazpaint" package (provided as direct download up to now), so that only one of them can be installed. This avoids having a different binary name, so that the following command still work:

lazpaint
man lazpaint

I found another bug with Qt5 version, the system color dialog is buggy. It doesn't seem to take the click into account but it will then pop up at every click and one need to quit with ALT-X to escape that.

So as it is, I think it is recommended to use the Gtk2 version.

That's upload 9: https://mentors.debian.net/package/lazpaint/

[fredvs]

found another bug with Qt5 version, the system color dialog is buggy.

Note also that people needs to install libqt5pas-dev that does not exist in all distros. So maybe the Qt version would only gives problems. Imho, of course.

[circular17]

Hmm, well let's see if it is accepted like that.

I have avoided the buggy Qt5 system color window by instead showing the color window, when someone clicks on the pen or back color. There is still the problem in the import 3d window, but well, that's less used.

I've uploaded with those changes (upload 10): https://mentors.debian.net/package/lazpaint/

I don't see much more I can do. So what to do now? Wait for an answer from Tobias?

[alexmyczko]

mind if i change the vcs fields to salsa and fix that typo with a patch? i would do that and set yes for review and ping tobi after that yes.

[circular17]

For what purpose use salsa? Is it because you want to be the uploader, the maintainer? Would I have access to salsa? Or do you keep it updated automatically from lazpaint-upstream?

As far as I know, this typo cannot be fixed, because it is in Lazarus source code.

[alexmyczko]

For what purpose use salsa?

Because most debian packages (their packaging) belongs there: https://www.jelmer.uk/janitor-update-8.html

Is it because you want to be the uploader, the maintainer?

neither, I'm not insisting to be uploader nor maintainer, i would even suggest adding it to the multimedia team instead (at some later time)

Would I have access to salsa?

Yes anyone with an email address can have access to salsa (last time i checked @gmail addresses were banned though) https://salsa.debian.org/users/sign_in?redirect_to_referer=yes

Or do you keep it updated automatically from lazpaint-upstream?

i don't think anything is automatic yet. and i'm all for getting the latest version of lazpaint as from the lazpaint repository for the future instead of lazpaint-upstream (i still don't get why it's lazpaint-upstream for the debian package)

As far as I know, this typo cannot be fixed, because it is in Lazarus source code.

ah sorry, you already had said so...

[circular17]

Because most debian packages (their packaging) belongs there: https://www.jelmer.uk/janitor-update-8.html

Ok, well, why not but as I started on GitHub, that would mean moving there and loosing history.

Would I have access to salsa?

Yes anyone with an email address can have access to salsa (last time i checked @gmail addresses were banned though) https://salsa.debian.org/users/sign_in?redirect_to_referer=yes

No my question is about access to the repository you created. If I am willing to move there, I need to be able to update it.

i don't think anything is automatic yet. and i'm all for getting the latest version of lazpaint as from the lazpaint repository for the future instead of lazpaint-upstream (i still don't get why it's lazpaint-upstream for the debian package)

Well that may be the reason of our misunderstanding. I explained that before a little bit but that does not seem clear to you. I will rephrase it, maybe that will help.

With Lazarus, you have custom packages (LPK), they are not installed as Debian packages but statically linked. So the source of the Debian package includes both the source of the Lazarus project and the source of the LPKs. For LazPaint, there are two external LPKs: BGRAControls and BGRABitmap:

• https://github.com/bgrabitmap/bgrabitmap
• https://github.com/bgrabitmap/bgracontrols

They each have a version number and it may not be obvious what version to use (though that can be specified in the Lazarus project). Also there is a part of BGRAControls that I had to strip off because of copyright.

[alexmyczko]

Congratulations, now it is here: https://ftp-master.debian.org/new.html

https://buildd.debian.org/status/package.php?p=lazpaint&suite=sid

[lainz]

Congratulations for the hard work and the good news.

[alexmyczko]

@circular17 also check these urls: https://qa.debian.org/developer.php?email=circular%40operamail.com https://repology.org/project/lazpaint/versions https://launchpad.net/ubuntu/+source/lazpaint

and i guess this issue can be closed now?

[circular17]

Yes those are valuable links.

Yes and no. So I understand I will be the maintainer of the package for now. I still wonder about the salsa repository. If I understand correctly, it is not pointed to by the Debian package info. Would you like to keep it as a mirror or would you discard it to avoid confusion?

[alexmyczko]

yes you are the maintainer of the package (me too, but you do all the hard work), for the salsa repo, don't bother until you switch to the latest version from this repo (lazpaint), we can fix that later, once you create a salsa repo. (for permission of the current repo on salsa, i should be able to give you access, once you ask for it). as it's not referenced to from anywhere it can stay, but if you wish i can remove it (it should not cause confusion imho)

for the debian/copyright and the special license, you can't use a similar license, really give the true name of it, and the full license text...

[circular17]

If I would search for some source, I could try salsa. So yeah I think that may be confusing. I guess now it is not possible to change the source repository because it is in the Debian package, so I would prefer it to be removed to be honest.

Regarding the licence, I've made a proposition to Joerg: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973774

I am waiting for his feedback because there are kind of identifiers defined and they should be used for it to be machine readable. About the full text, that's not what is put in the copyright files and in the case of the modified LGPL, the modification is an additional paragraph that modify the license, so I don't see the point of duplicating the original LGPL text.

[circular17]

Thank you very much for guiding me through the process Alex. It would not have progressed without you.

[alexmyczko]

@circular17 now is time to add screenshots http://screenshots.debian.net/packages?utf8=%E2%9C%93&search=lazpaint

[circular17]

Done

[alexmyczko]

OFFTOPIC, got an idea how i could compile this https://github.com/hukkax/Propulse on linux? (without interaction)

[circular17]

First try to compile it within Lazarus to see if it compiles at all.

For me, it doesn't compile on MacOS nor on Linux. I have reported it: https://github.com/hukkax/Propulse/issues/5 https://github.com/hukkax/Propulse/issues/6

Note: to get details on the error messages, right-click in the Message window, choose something like "Copy all messages" and paste into a text editor.

After fixing those problems, it may be as simple as typing:

lazbuild --build-mode=Release src/Propulse.lpi

[circular17]

Modules trackers, that brings good old memories

[fredvs]

Hello.

Here it compiles ok for Linux 64 after installing the libraries. sudo apt install libsdl2-dev libsoxr-dev

The Bass library can be found here: https://www.un4seen.com/

May I ask you why you did use Bass audio library (because it is not open-source and free only for non-commercial use)?

Fre;D