Re: FVWM: FVWM3-1.0.0 is released
Stuart Longland writes: > On 7/9/20 9:40 am, Chris Bennett wrote: >> I'm running amd64 OpenBSD and there are libraries we don't have, such as >> libbson, which can be added. >> However, I'm a little unclear on what the -dev signifies on the required >> libraries. > > I'm guessing possibly a Debian or RedHat-ism? A lot of those > distributions ship packages that are "split": .so libraries and user > binaries in one package (libfoo) and the headers and .a libraries in a > "development" package (libfoo-dev). For Redhat, (well Fedora), the development packages are suffixed -devel. Typically you get headers and libraries you need to do compiles. -- Dan Espen
Re: FVWM: FVWM3-1.0.0 is released
On 7/9/20 9:40 am, Chris Bennett wrote: > I'm running amd64 OpenBSD and there are libraries we don't have, such as > libbson, which can be added. > However, I'm a little unclear on what the -dev signifies on the required > libraries. I'm guessing possibly a Debian or RedHat-ism? A lot of those distributions ship packages that are "split": .so libraries and user binaries in one package (libfoo) and the headers and .a libraries in a "development" package (libfoo-dev). -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere.
Re: FVWM: FVWM3-1.0.0 is released
Hi, I'm running amd64 OpenBSD and there are libraries we don't have, such as libbson, which can be added. However, I'm a little unclear on what the -dev signifies on the required libraries. I'm a bit outside of what that means. My experience is mostly Perl and PostgreSQL. Thanks, Chris Bennett
Re: FVWM: FVWM3-1.0.0 is released
On 7/9/20 7:13 am, elliot s wrote: > Is there a way to get a precompiled 64 bit version? 64-bit? MIPS n64 binary compiled on OpenBSD 6.6 cool with you? To provide a binary that will actually work, we need to know more than the width of the address bus your CPU uses. There's AMD64, ARM64, MIPS64, UltraSPARC, PPC64, RISC-V, … and those are just the currently active platforms that are 64-bit… historically you can add to that MIPS3/MIPS4, DEC Alpha, HP PA-RISC, Intel IA64… and probably lots of others I've forgotten about. Then there's the kernel, Linux is a common choice, but you could also be running a BSD variant on a 64-bit processor. Solaris and IRIX both had 64-bit versions. Recent MacOS X is also 64-bit. Then there's userland libraries that FVWM might want to link to. I have an AMD64 Linux binary for fvwm2 here, but there's no guarantee that it'll work on your arbitrary AMD64 Linux computer as it was compiled against what I'm running here. This is the minefield that one walks into providing binaries. No different to any other OS. Firefox on Windows these days is compiled for Windows 7 (not sure about Vista): it won't work on Windows XP. Yes, you might download a 32-bit version of it, but it was linked against libraries that are newer than what is available on that OS. Lots of applications don't work on my Macbook running MacOS X 10.6 for this reason. Far and above the safest ways are: - compile it yourself - obtain a compiled package from your operating system's distributor Alternatively: if you could provide some detail on what 64-bit platform and OS you are running, someone here might be able to provide a binary package for that OS. Without that information, we are guessing. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere.
Re: FVWM: FVWM3-1.0.0 is released
On Sun, Sep 06, 2020 at 02:13:18PM -0700, elliot s wrote: > Retrying from laptop since fvwm mail doesnt like my tablet gmail (html issue). > > Is there a way to get a precompiled 64 bit version? > Perhaps put one up on the site? > I check pkgs.org but I assume it'll be a long time before it hits there. You typically either compiler it yourself, or wait for your Linux distro/BSD variant to provide one. I personally won't support this outside of downstream packaging efforts. Kindly, Thomas
Re: FVWM: FVWM3-1.0.0 is released
Retrying from laptop since fvwm mail doesnt like my tablet gmail (html issue). Is there a way to get a precompiled 64 bit version? Perhaps put one up on the site? I check pkgs.org but I assume it'll be a long time before it hits there. Thanx
Re: FVWM: FVWM3-1.0.0 is released
On Thu, 3 Sep 2020 02:06:10 +0100 Thomas Adam wrote: > > It's not without its rough edges, but that's true of any software. > Even though I've called those out in the release notes, I consider > Fvwm3 now good enough for every day use. > I just want to report that virtual desktops still have the scrolling problem (at least on my system). Using the mouse, I can change VDs by scrolling right-to-left and up/down but moving left-to-right the scroll is broken. I can use the mouse to move an entire window left-to-right but simple scrolling left-to-right down not change the VD. For me at least, this is a show stopper since I switch VDs constantly. I am not using multiple monitors but only a single monitor and VDs. My config file is unaltered from fvwm-2.
Re: FVWM: FVWM3-1.0.0 is released
OpenBSD has an older fvwm installed in base. Licensing reasons. A newer fvwm2 is part of ports. So that's two different versions already available. Adding fvwm-3.X.X would really cause conflicts. I would much rather see fvwm2 and fvwm3. That avoids some tricky work making them both installable. As fvwm3 will diverge, I can easily see someone wanting a stable fvwm to use or go with a changing fvwm3. Multiple users are very likely to want two different versions. If you like your current setup, why require battling with configs? If you want changes, no problem with config changes. Everybody happy. There are already three flavors of fvwm available in ports right now, plus 1 installed with base system. Sure, the conflicts can be handled, but IMHO offering fvwm3 versus fvwm2 is easier for end users new to fvwm. Thanks for the hard work! Chris Bennett
Re: FVWM: FVWM3-1.0.0 is released
On Thu, Sep 3, 2020 at 1:15 PM Dominik Vogt wrote:
>
> On Thu, Sep 03, 2020 at 12:13:45PM -0600, Jaimos Skriletz wrote:
> > Creating two packages that live side by side is a far greater
> > challenge than initially anticipated. First there are a lot of other
> > binaries such as fvwm-root, fvwm-config, fvwm-menu-desktop, that would
> > conflict,
>
> Do these not get the --program-suffix? If not, that should be
> fixed.
>
It does work for the binaries. Just not the module manpages, which
share a common location, $PREFIX/man/man1
> > and though the --program-{prefix,suffix,transform-name} can
> > rename the binaries, this isn't the only conflict. The manpages for
> > all the common modules conflict and so does the translations/locales.
> > And none of these are affected by the --program-foo options.
>
> All right, but if these problems had been *reported* and not just
> silently dealt with in the distribution, they would have been
> fixed immediately back when the change from fvwm2 to fvwm was
> done.
>
I just adopted the package as it was, so I was unaware of this issue
until now. And the package only renames a single binary fvwm -> fvwm2
(then creates a link for fvwm), so at the time it wasn't an issue, as
it appears these other binaires were not part of fvwm 1.x.
The rest is all done in the fvwm1 package to ensure no conflict, which
someone else maintains. I did a little more research, the fvwm1
package in debian just renames all the manpages FvwmFoo.1.gz ->
FvwmFoo1.1.gz. This was probably done by Debian since at the time fvwm
1.x was no longer supported.
> > and locales,
>
> I don't know much about locales, but are they not installed in
> /usr/share/fvwm?
>
Locales are placed in $PREFIX/share/locale//LC_MESSAGES/, fvwm
has both a fvwm.mo and FvwmScript.mo that get placed in multiple
languages. I only know that the files are there and conflict, unsure
of if they can be renamed or any issues that would arise from that.
> > but even this isn't doable since there is
> > already differences in the modules in fvwm2 and fvwm3, mostly it is
> > the modules that are available, but FvwmPager has already received
> > some changes in options for the RandR per monitor setup.
>
> Is is acceptable to have man pages named
> FvwmModule in addition to the default names?
> If all else fails, the manpages could be put in separate packages.
>
As mentioned above, that appears to be what Debian's fvwm1 package is
doing. So it would be acceptable (only issue I can see is confusion on
the user if man FvwmButtons either didn't give a man page or a version
they weren't expecting, but the docs can explain this convention).
> > Currently, I'm just gonna to go with fvwm3 conflicts with fvwm2 and
> > only one of those can be installed at a time.
>
> I don't like this naming scheme that suggest the version number is
> part of the project name. Is naming them "fvwm", "fvwm-2",
> "fvwm-1" not an option?
>
It is an option, but it isn't how it is done now. Currently Debian has
two packages fvwm1 and fvwm. It seems to vary, some packages are
packagename-, and others are packagename to allow multiple
versions to be installed via multiple packages. I was just thinking of
being in line of what is currently in place.
jaimos
> Ciao
>
> Dominik ^_^ ^_^
>
> --
>
> Dominik Vogt
>
Re: FVWM: FVWM3-1.0.0 is released
On Thu 2020-09-03 20:14 , Dominik Vogt wrote: > On Thu, Sep 03, 2020 at 12:13:45PM -0600, Jaimos Skriletz wrote: [ ... stuff deleted ... ] > > Currently, I'm just gonna to go with fvwm3 conflicts with fvwm2 and > > only one of those can be installed at a time. > > I don't like this naming scheme that suggest the version number is > part of the project name. Is naming them "fvwm", "fvwm-2", > "fvwm-1" not an option? Such a naming scheme provides the user with an option to have multiple versions installed at once. Which does imho have certain practical value per se. In Fedora world, there are various exmaples of such approach, such as e.g. samba4, xmms2, or softwarecollections.org. I'm wondering whether there is a good reason not to go this way. m.
Re: FVWM: FVWM3-1.0.0 is released
On Thu, Sep 03, 2020 at 12:13:45PM -0600, Jaimos Skriletz wrote:
> I also see fvwm2 being used for quite a while even as fvwm3 matures.
Can we please stop calling the project "fvwm2" or "fvwm3". We've
renamed it to "fvwm" ages ago.
> Creating two packages that live side by side is a far greater
> challenge than initially anticipated. First there are a lot of other
> binaries such as fvwm-root, fvwm-config, fvwm-menu-desktop, that would
> conflict,
Do these not get the --program-suffix? If not, that should be
fixed.
> and though the --program-{prefix,suffix,transform-name} can
> rename the binaries, this isn't the only conflict. The manpages for
> all the common modules conflict and so does the translations/locales.
> And none of these are affected by the --program-foo options.
All right, but if these problems had been *reported* and not just
silently dealt with in the distribution, they would have been
fixed immediately back when the change from fvwm2 to fvwm was
done.
> I was thinking of maybe some fvwm-common package that would host the
> manpages
Applying the --program-suffix to the man page names should be
trivial to do in the Automakefiles.
> and locales,
I don't know much about locales, but are they not installed in
/usr/share/fvwm?
> but even this isn't doable since there is
> already differences in the modules in fvwm2 and fvwm3, mostly it is
> the modules that are available, but FvwmPager has already received
> some changes in options for the RandR per monitor setup.
Is is acceptable to have man pages named
FvwmModule in addition to the default names?
If all else fails, the manpages could be put in separate packages.
> Currently, I'm just gonna to go with fvwm3 conflicts with fvwm2 and
> only one of those can be installed at a time.
I don't like this naming scheme that suggest the version number is
part of the project name. Is naming them "fvwm", "fvwm-2",
"fvwm-1" not an option?
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
Re: FVWM: FVWM3-1.0.0 is released
On Thu, Sep 3, 2020 at 5:28 AM Martin Cermak wrote:
>
> On Thu 2020-09-03 09:49 , Dominik Vogt wrote:
> > On Thu, Sep 03, 2020 at 02:06:10AM +0100, Thomas Adam wrote:
> > > Well, we did it. Version 1.0.0 of Fvwm3 is now live and ready to be
> > > installed.
> >
> > Um, can we call that fvwm-3.0.0 instead of fvwm3-1.0.0 please?
> > Renaming the project because of a new major version was already a
> > mistake for fvwm-2.0.0. No reason to repeat it now.
>
> ( I was just thinking of creating a brand new package for fedora
> providing /usr/bin/fvwm3 able to coexist with /usr/bin/fvwm2 from
> the existing package. Might this make sense from the user
> perspective? Not sure ... )
>
I am trying to make a Debian package that lives side by side as well.
For many years, Debian's package renames the main binary from fvwm to
fvwm2 so fvwm1 and fvwm2 installable side by side, then uses their
alternative system to allow fvwm to point to either fvwm1 or fvwm2. It
would be nice to add fvwm3 to the list, and all three can be
installed.
I also see fvwm2 being used for quite a while even as fvwm3 matures.
It may not get updates, but I suspect (partly because it had one
recently) it will receive bug fixes to keep it buildable and usable
for the users who just want to stick to fvwm2, since as mentioned
there are still people maintaining (and I assume using) fvwm1. So
having it seperate may not be the issue it was at the last transition,
as after 20 years times have changed.
Creating two packages that live side by side is a far greater
challenge than initially anticipated. First there are a lot of other
binaries such as fvwm-root, fvwm-config, fvwm-menu-desktop, that would
conflict, and though the --program-{prefix,suffix,transform-name} can
rename the binaries, this isn't the only conflict. The manpages for
all the common modules conflict and so does the translations/locales.
And none of these are affected by the --program-foo options.
I was thinking of maybe some fvwm-common package that would host the
manpages and locales, but even this isn't doable since there is
already differences in the modules in fvwm2 and fvwm3, mostly it is
the modules that are available, but FvwmPager has already received
some changes in options for the RandR per monitor setup.
Currently, I'm just gonna to go with fvwm3 conflicts with fvwm2 and
only one of those can be installed at a time.
All in all it is nice to see something new, and hope that even after
quartiteen there is still enough time and effort to see where it
evolves.
jaimos
Re: FVWM: FVWM3-1.0.0 is released
On Thu, Sep 03, 2020 at 01:27:19PM +0100, Thomas Adam wrote: > It's a tricky one. Right now, things have not diverged because I haven't > implemented those changes. I'd always viewed Fvwm3 as being a departure from > Fvwm2 -- and hence any association with it at the moment as being equivalent > is just because it's lacking any breaking changes. It's also an easier > transition for any one wishing to try Fvwm3 who's previously used Fvwm2. > > That's one of the reasons why I went with version 1.0.0 -- Fvwm3 is going to > be separate from Fvwm2 over time, in that I'm not expecting to maintain > compatibility, and I wouldn't therefore want to mislead users with a false > version number. > > There may well be some overlap with Fvwm2 in terms of unchanged file names > (fvwm-config springs to mind), although I think for the most part Fvwm2 and > Fvwm3 can co-exist. I'll try and make the distinction better in future > releases, so that it's easier for package maintainers to allow Fvwm2 and Fvwm3 > to coexist. The exact same reasoning led to the "fvwm2" project, and it caused a whole lot of useless work to eventually clean up and rename it to fvwm again. The autotools can take care of having two versions installed in parallel (--program-suffix configure option). Distributors know how to use these options. And as far as I understand, nobody is going to maintain the 2.x version anyway. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: FVWM: FVWM3-1.0.0 is released
On Thu, Sep 03, 2020 at 07:42:58AM -0400, Dan Espen wrote: > Martin Cermak writes: > > > On Thu 2020-09-03 09:49 , Dominik Vogt wrote: > >> On Thu, Sep 03, 2020 at 02:06:10AM +0100, Thomas Adam wrote: > >> > Well, we did it. Version 1.0.0 of Fvwm3 is now live and ready to be > >> > installed. > >> > >> Um, can we call that fvwm-3.0.0 instead of fvwm3-1.0.0 please? > >> Renaming the project because of a new major version was already a > >> mistake for fvwm-2.0.0. No reason to repeat it now. > > > > ( I was just thinking of creating a brand new package for fedora > > providing /usr/bin/fvwm3 able to coexist with /usr/bin/fvwm2 from > > the existing package. Might this make sense from the user > > perspective? Not sure ... ) > > Not sure how Thomas feels. > Fvwm3 was supposed to be largely incompatible with Fvwm2 hence the name > change. That hasn't occurred yet. It's a tricky one. Right now, things have not diverged because I haven't implemented those changes. I'd always viewed Fvwm3 as being a departure from Fvwm2 -- and hence any association with it at the moment as being equivalent is just because it's lacking any breaking changes. It's also an easier transition for any one wishing to try Fvwm3 who's previously used Fvwm2. That's one of the reasons why I went with version 1.0.0 -- Fvwm3 is going to be separate from Fvwm2 over time, in that I'm not expecting to maintain compatibility, and I wouldn't therefore want to mislead users with a false version number. There may well be some overlap with Fvwm2 in terms of unchanged file names (fvwm-config springs to mind), although I think for the most part Fvwm2 and Fvwm3 can co-exist. I'll try and make the distinction better in future releases, so that it's easier for package maintainers to allow Fvwm2 and Fvwm3 to coexist. Kindly, Thomas
Re: FVWM: FVWM3-1.0.0 is released
Martin Cermak writes: > On Thu 2020-09-03 09:49 , Dominik Vogt wrote: >> On Thu, Sep 03, 2020 at 02:06:10AM +0100, Thomas Adam wrote: >> > Well, we did it. Version 1.0.0 of Fvwm3 is now live and ready to be >> > installed. >> >> Um, can we call that fvwm-3.0.0 instead of fvwm3-1.0.0 please? >> Renaming the project because of a new major version was already a >> mistake for fvwm-2.0.0. No reason to repeat it now. > > ( I was just thinking of creating a brand new package for fedora > providing /usr/bin/fvwm3 able to coexist with /usr/bin/fvwm2 from > the existing package. Might this make sense from the user > perspective? Not sure ... ) Not sure how Thomas feels. Fvwm3 was supposed to be largely incompatible with Fvwm2 hence the name change. That hasn't occurred yet. -- Dan Espen
Re: FVWM: FVWM3-1.0.0 is released
On Thu 2020-09-03 09:49 , Dominik Vogt wrote: > On Thu, Sep 03, 2020 at 02:06:10AM +0100, Thomas Adam wrote: > > Well, we did it. Version 1.0.0 of Fvwm3 is now live and ready to be > > installed. > > Um, can we call that fvwm-3.0.0 instead of fvwm3-1.0.0 please? > Renaming the project because of a new major version was already a > mistake for fvwm-2.0.0. No reason to repeat it now. ( I was just thinking of creating a brand new package for fedora providing /usr/bin/fvwm3 able to coexist with /usr/bin/fvwm2 from the existing package. Might this make sense from the user perspective? Not sure ... ) m.
Re: FVWM: FVWM3-1.0.0 is released
On Thu, Sep 03, 2020 at 02:06:10AM +0100, Thomas Adam wrote: > Well, we did it. Version 1.0.0 of Fvwm3 is now live and ready to be > installed. Um, can we call that fvwm-3.0.0 instead of fvwm3-1.0.0 please? Renaming the project because of a new major version was already a mistake for fvwm-2.0.0. No reason to repeat it now. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
