Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Dmitriy Kuminov

Pages: [1] 2
1
Internet / Re: The new browser / QT5
« on: August 19, 2019, 12:32:42 pm »
This really depends on how they decide to go. They made Qt 5 much more modular and plugin based (compared to Qt 4 and earlier) and this is a good thing. It simplifies things a lot (in terms of support and porting to new platforms as well). Therefore I suppose they will leave the overall structure intact this time. Which means less work bringing it to OS/2.

2
Article Discussions / Re: Qt 5 Base for OS/2
« on: August 16, 2019, 02:44:32 pm »
Jochen, I see. This looks like an ANPM bug to me. Please report this situation to their bug tracker at https://mantis.arcanoae.com/. (Apparently they should let the whole update process to complete and only then offer a reboot).

3
Article Discussions / Re: Qt 5 Base for OS/2
« on: August 16, 2019, 12:10:01 pm »
Jochen, how do you install things? `libc-1:0.1.2-1` depends on a newer `klusrmgr-1.2.2-1` which should be automatically dragged in (causing a klusrmgr update before libc) unless you do something special with custom yum/rpm flags.

4
Article Discussions / Re: Qt 5 Base for OS/2
« on: August 15, 2019, 07:03:50 pm »
Qt 5 is not very backward compatible with Qt 4 but there are tools from Qt that simplify porting. But Qt 5 and Qt 4 apps can coexist so unless there are Qt 5 versions of your apps (which you should use then) you can still use Qt 4 versions.

Re the package error. Fixed, it will get deployed in 30 min or such.

5
Internet / Re: The new browser / QT5
« on: August 15, 2019, 05:09:08 pm »
BTW, YouTube works great in pure QtWebEngine as long as "proprietary" FFMPEG codecs are enabled when building it. So I expect it to work out of the box on OS/2 once we port it (we already have FFMPEG et al). It will lack hardware support of course but that's another story.

6
Article Discussions / Re: Qt 5 Base for OS/2
« on: August 14, 2019, 08:16:58 pm »
Martin, thanks for popping this up! A couple of notes:
- Qt 5 RPMs will be moved to the release repository later today.
- Qt 5 consists of modules and each module has its own repository and issue tracker. Per-module tickets should be reported to the module's issue tracker. Currently we only ported the QtBase module. Its issue tracker is located here: https://github.com/bitwiseworks/qtbase-os2/issues.

And here are the proper release notes btw: https://github.com/bitwiseworks/qtbase-os2/releases/tag/v5.11.0-os2-b1

7
Internet / Re: The new browser / QT5
« on: August 14, 2019, 08:12:35 pm »
Dave, WebExtensions will eventually be available in QtWebEngine. Currently planned for Qt 5.14, here is its official bug report: https://bugreports.qt.io/browse/QTBUG-61676. (And btw the original ticket mentioned Falkon, https://bugreports.qt.io/browse/QTWB-35).

Given that Qt 5.13 is already out (to which our port of Qt5 for OS/2 will be updated within a couple of weeks), Qt 5.14 is really soon. It is scheduled for November, 2019 so if it goes well on their side WebExtensions will appear before/when we are done with our QtWebEngine port. Even if it gets postponed further, we will still get it one day. We have a lot to do before Falkon is ready to run on OS/2 anyway.

8
Article Discussions / Re: Follow Bitwise on Twitter
« on: June 18, 2018, 03:08:23 pm »
Hello Martin,

Thank you very much for raising it here. We planned to do so ourselves, but you outrun us :)

Yes, we will now post regularly to both our Twitter and our Facebook accounts. We found out that people are unaware about our daily work and therefore there might be an impression that we do nothing between releases. This is of course not true. We have to do *A LOT* of work in between. It's just so that sometimes the connection between what we might work on and the applications we eventually deliver is not obvious for an end user. A typical example is fixing the compiler (GCC) or its main library (LIBC). Regular postings to our online resources are meant to fill this gap.

So those who are on Twitter should follow us just as Martin described. Those who prefer Facebook, can use this link https://www.facebook.com/pg/bitwiseworks/ to subscribe to our page and get the same information that appears on our Twitter.

In our posts we use hash tags extensively to simplify following only specific topics if you need. Tag examples:

- #progress — rather noisy (and somewhat "technical") topic were we post interesting findings during our daily development work
- #release — posts with release information for various products we maintain
- #qt5 — Qt 5 related posts
- #NNN (where NNN is the application name) — posts related to the application named NNN (e.g. #injoy, #unzip)

9
Internet / Re: Firefox - 45.9.0 for OS/2 GA1.1...anyone...anyone???
« on: April 24, 2018, 02:16:27 pm »
Guys, so far it looks like it's a network & timing issue. So depending on the combination of your hardware and used optimization options all builds (Dave's or mine) might or might not work. I've created a ticket for that https://github.com/bitwiseworks/mozilla-os2/issues/266. Feel free to share your experience there. By experience I mean technical facts — which hardware you have, which builds fail for you and which don't and what you do to make them work; abstract phrases like "doesn't work" are of no use so please don't spam with them there.

10
Applications / Re: Firefox 45.5 Install issues
« on: June 16, 2017, 12:42:29 am »
I have no clue what language difficulties have to do with "hence have various difficulties with the RPM/YUM/UNIXROOT environment", while ignoring the fact that the package manager over here is, and will remain, a human package manager. RPM is no one-size-fits-all solution, albeit you're pretending it is. Whotevah...
The clue is your old eCS or OS/2 installation which is not tested and not officially supported by us as a target for the RPM/YUM/UNIXROOT environment. If you refuse to properly install and properly use this environment then we have nothing to offer you except a raw ZIP with zero support from us. I have no clue what exactly is not clear for you here. We are not pretending and not saying that RPM fits everyone's needs — feel free to use whatever is best for you. We are only saying that if RPM doesn't fit your needs then please don't ask us for help because our only solution to help you with is RPM (reasons explained). That simple. And if you can offer OS/2 users something else — go on, do it, create competition (that you adore so much). We will be really glad to see it.

The ticket system is yours, and the human package manager even avoids WPI packages. Not because WarpIN sucks, so someone representing a WarpIN company doesn't have to try to advocate WarpIN now...
The only thing I advocated here so far is the choice we've made. And my intent has nothing to do with sucking, fucking, or such. It's clearly stated in the second sentence of my original post.

11
Internet / Re: FF45.5 - choppy response/window scrolling anyone???
« on: June 16, 2017, 12:00:13 am »
JFYI, the problem was nailed down and worked around, see the last comments in the respective issue (https://github.com/bitwiseworks/mozilla-os2/issues/208). Please also consider reporting such things directly into the Mozilla issue system at https://github.com/bitwiseworks/mozilla-os2 as this way 1) it's guaranteed that it's noticed by the developers and 2) you get much faster feedback.

12
Programming / Re: How to build Seamonkey?
« on: June 05, 2017, 09:24:16 pm »
No, I didn't, because I thought RPM/YUM is now the state of art to get the build tools.
This is the right thought.
I understand that, but now I do not know which versions to use. For example autoconf: Dave wrote I shouldn't use autoconf213 but the one in your link seems to be that version.
Dod you read https://github.com/bitwiseworks/mozilla-os2/wiki/Developers#building-from-sources? This instruction is for Firefox and not exactly accurate now (I haven't updated it in a while) but it gives you the right direction. I'd suggest that you first build Firefox as described there and, on success, try Seamonkey.

Note also that I had to do some essential patches in order to build the latest Firefox (e.g. some emxomfld fixes) and some of them are still not released as RPMs but I'm really close to it (a new libc RPM is the only missing thing IIRC).

13
Applications / Re: Firefox 45.5 Install issues
« on: June 03, 2017, 03:00:57 am »
I don't normally read forums as I prefer to spend my time developing rather than participating in hate speech (I'm a human being with limited resources, sorry). However, I've been pointed to this thread and I found some posts interesting enough to answer them in hope that my answers, as well as the answers of my fellow colleague Herwig, will eventually help people use what we (BWW) do.

First of all, Firefox install issues. The original issue of this thread's author was in fact not related to the RPM/ZIP war at all. It was just getting out of sync with announcing a new Firefox release and moving a couple of packages from the experimental repository (where all releases initially land) to the normal one. This happens sometimes and is usually fixed very quickly. Not a big deal. More over, in the future such issues will be resolved automatically (the technology we use allows to do that).

Next, about the ZIP installation of Firefox and its further support. As Dave already pointed out, we (BWW) discontinued support for ZIP installations. Back in FF Beta 7, by the way. The reasons behind this decision are described in README.OS2 (but who reads that, I know). In short, it's simply not possible any more. Some (actually pretty long) time ago we deliberately took the Linux approach of distributing software. This approach basically means that each and every 3rd party library any given software product uses is built as a DLL and distributed on its own rather than as part of that product and this distribution is then shared among all other products using the same library. The main benefit of this approach is that it greatly saves system resources (mostly in terms of occupied disk space and memory footprint) because programs share a single copy of the library code (and sometimes library data too). Another key benefit is that fixing a bug in such a library (and installing a new version of it) makes the fix instantly available to all programs using this library without a need to reinstall those programs themselves.

Saving system resources is what we need most from the new approach. While the available memory address space size is not a big issue in the 64-bit world, it is a very tight resource in the 32-bit world where OS/2 belongs (and will belong forever I suppose). I think everybody is aware about problems when several huge applications (be it FF + AOO + VBox) are runnig in parallel. You have to play with your VIRTUALADDRESSLIMIT setting in CONFIG.SYS and mark DLLs to be loaded high in order to make them work. And all these problems are about running out of address space because there are too many libraries used by these applications occupying too many memory pages and doing very similar things. Or, even worse, too many versions of the same library doing exactly the same thing but occupying as much space as there are copies of the library. And, due to technical limitations of the 32-bit world (and of the OS/2 kernel which is quite old and does not evolve) we, as developers, can't do much here. Except that we can try to eliminate similar or duplicate copies of libraries applications need at their runtime and this is what "Bitwise seems to like seeing how many dependencies they can make Firefox require" is exactly about. Reducing memory footprint. By breaking applications into as many separate and reusable pieces as possible. To let you run several modern and heavy applications in parallel. Or even simply run them at all. (It's not hard to imagine a single application that sucks in all available 32-bit address space).

Having so many dependent (and sometimes cross-dependent) moving parts, in turn, requires a decent software manager framework that can automatically resolve all these dependencies (including possible conflicts) and download proper versions of all necessary libraries — because it is simply beyond possibilities of a regular person to do it manually. For instance, Firefox currently requires about 50 external DLLs and a bunch of other stuff — this is NOT manageable by hand. DLLs required by Firefox have their own requirements, sometimes you need to take a specific version of a library and so on. And simply distributing all the required DLLs with the application inside a single ZIP is not a solution here, not at all. First, it will immediately create a well known DLL hell — the system will have many copies of the same DLL distributed with different applications which will be often conflicting with each other in many ways. Second, if you try to fix this DLL hell with LIBPATHSTRICT=T (which itself is a very dirty hack in the OS/2 kernel and doesn't always give stable results), you will completely beat the whole purpose of breaking applications into reusable pieces described above (and even the purpose of distributing libraries as DLLs at all). So the macOS-like all-in-one bundle strategy is not a way to go on OS/2. Needless to say that, having that many dependencies, even a task of bringing them all together (e.g. in order to pack in a single ZIP) or even simply mentioning them all in a readme becomes a big headache and this is why we gave up on this idea completely.

So, with the above said, we have what we have. RPM as the software manager framework, YUM as its command-line frontend and ANPM as its GUI frontend. RPM may be not the best software manager out there but it does its job (it was selected many years ago and we don't have resources to try out another one, at least not now and not in the near future). Actually, it's not that bad at all if you use it as it was designed to and not as you want it to use. This means that you should either install ArcaOS or properly install the RPM/YUM environment to your favorite OS/2 flavor and then only use YUM (or ANPM) to install all software that is being released as RPM (by BWW or any other party) even if there are alternative ZIP distributions of this software floating around. In this case, RPM will do all the dirty work for you. And it will do it right in most (if not all) cases. And if it doesn't, it's a bug that is about to be fixed. Don't get me wrong, when I said RPM is not the best package manager, I didn't mean WarpIn. Not at all. WarpIn may be younger than RPM, but it's so much behind it (or any other modern manager like DPKG) feature wise that it's simply not correct to compare them. In fact, WarpIn is essentially an installer, it has only very basic package management capabilities which don't meet the need of the real world — and this is one of the reasons RPM was ported to OS/2 in the first place. And while RPM has its flaws (e.g. some odd behaviour when resolving really complex conflicting dependency cases involving multiple indirect upgrades/downgrades), it's still much better than WarpIn and it's been serving such massive distributions as Fedora and CentOS for years which proves its stability and scalability. The mentioned flaws are rare cases that don't affect a normal user (and that are being addressed in DNF, a YUM successor that we will eventually port to OS/2, and in RPM itself). So, words like "a package manager from 90s" simply mean nothing. The whole concept of a PC from 60s and it still works pretty well.

Regarding language support and other reasons that could force you to use older OS/2 flavors instead of ArcaOS and eCS 2.x and hence have various difficulties with the RPM/YUM/UNIXROOT environment. This is an interesting point of view. But it is weak. I'm Russian. And I've been using English eCS for many years now. And I have Russian in all places I need. So I know what I'm talking about. Language support is not perfect but it's usable (and it may be improved). To put it simple, nowadays there is only ArcaOS. This is the only flavour which is alive, forget about everything else. ArcaOS is only English now, but there is nothing that would prevent it from becoming French, German or Russian — other than some reasonable amount of time and money. And you would better apply your energy in this direction instead of criticising a switch to RPM/UNIXROOT. Seriously. But even if, despite all reasons, you want to stick with some dead OS/2 flavour, there is still a solution for you: make some effort and bring RPM/UNIXROOT to your system. You may even do a package in your favourite format for that, be it ZIP or anything else, or improve the existing WPI of a standalone RPM install — as a courtesy to other folks using the same flavour. And we will even assist you, as time permits, if you file your problems in the respective tickets.

So, back to the Firefox ZIP distribution. Very soon there will be a Firefox RPM from BWW/AN that does all the dependency burden for you in one click. And there will be an automatically generated ZIP from us which is basically a repack of that RPM. There will also be an automatically generated list of required DLLs put into that ZIP, for  your convenience. (This list is what you can actually easily get yourself from any RPM file by executing `rpm -qRp PACKAGE.rpm`). But not more than that I'm afraid. Everybody is free to give us suggestions on how to improve our automatically generated ZIPs or to contribute even further and e.g. write a script that converts our RPMs/ZIPs to WarpIn archives. (Or repack our software manually if you wish so). But it's clear enough that we have very limited resources and will not provide official support for a distribution other than our own RPM and our exact reaction to your suggestions is limited by our resource availability as well. However, it's never forbidden to ask us a question if you have one. Do it and chances are high that you get an answer. And, while ranting, flaming and hate spilling also cannot be forbidden due to a free speech principle, you will surely not get any answer on that :) At least not from us. Thanks for your attention.

14
Internet / Re: SeaMonkey 2.21b3
« on: April 29, 2015, 07:07:35 pm »
My comments. The gcc DLL is made dynamic so that some C/C++ machinery could work across DLLs (e.g. exceptions). And no, mozft libraries are not statically linked into XUL.DLL — since FF 24 beta 4 we we link against our fntcfg2 / freetyp6 DLLs (which are pretty much the same as mozft but they have standard names and are used by a variety of other OS/2 apps out there).

In general, the all-in-one approach (best deployed by Apple on Mac) has its own benefits, for sure (especially from the end user's POV). But you have to pay the price of increased memory usage for that. On Mac, it's not a big issue because it allows to handle much more memory than OS/2 and its memory management is apparently superior to that on OS/2 (and it can handle its memory usage patterns pretty well). Besides, the majority of Mac apps is written using Apple's own toolkits and these toolkits are provided as DLLs by the system (so a typical native Mac app rarely needs anything besides the system libraries). Going further, OS/2 has never had this all-in-one approach implemented to a smooth degree: IBM-provided hacks like LIBPATHSTRICT are clear evidences of that. So it's simply not correct to say that it's the OS/2 way to deploy apps. And I do remember a lot of DLL hell in the past with various OS/2 applications.

Putting it all together, the lack of proper DLL management on OS/2 doesn't allow apps to have their own, private versions of DLLs. The lack of proper memory management doesn't allow to have them all built statically. We have major problems with private / shared memory arenas which get quickly exhausted if one uses a couple of heavy apps in parallel (e.g. Firefox and OOo and/or a Qt app). All this leaves us only one choice: put as much common code to DLLs as possible and make as much apps use these DLLs as possible. Of course this isn't a way to go w/o a decent package manager that ensures DLL integrity and this is where we came to YUM/RPM.

And if you take the modern user's perspective, it doesn't really matter what the application does under the hood as long as you have the application store where you just type its name to smoothly install or remove it. This is basically what Apple Store does on Mac and a respective application manger on any other modern OS (including mobile devices). And if you go with the YUM/RPM approach provided by BWW, OS/2 differs from those only by the fact that on OS/2 the application manager has no handy GUI yet so you have to use the command line. But given that an average OS/2 user is not unfamiliar with the command line and that Yum command line is very simple to use (for basic things like installing an application), it doesn't look like a big price for the convenience for both the developer and the end user. More over, a Yum GUI is on its way so this will make things even more user friendly when it's out.

Firefox will become an RPM installable with Yum very soon too. For this reason, we are trying to reuse DLLs already provided by RPM/YUM as much as possible with each FF release (and will even create more of such DLLs in the future).

15
Internet / Re: Firefox Developer Edition 24.8.1b4
« on: March 30, 2015, 12:55:53 pm »
Dariusz,

Thank you for the detailed replies.

Well, basically I pulled the Bitworks published Firefox release which then required a number of RPM packages. I do not use RPM/YUM, I have been relying on ZIP releases mostly because it gives me control over what goes where and my setups are rather simple and I'm trying to keep it that way:

1) g:\os\dll
2) g:\usr\dll
3) g:\usr\bin

...I attempt to keep the duplicate DLLs to a minimum. Basically all non-IBM OS/2 dlls go to \usr\dll.
Ok, your intention is clear but know what: RPM does what you just listed for you for free and in a completely unattended (yet 100% predictable) way. It keeps all non-OS/2 things in one place, it rules out the duplicate problems as well as *all* dependencies, including the rather complex cases. (Yes, there are some edge cases where it fails with dependencies but these are rare and may be solved on the vendor's side when done properly — we are working on that). So I strongly recommend you to try YUM/RPM as I think it perfectly fits your scenario.

Quote
For whatever reason, I could not extract the needed DLLs out of the RPM packages (using ArchiveView and consistently getting "SYS1092: The handle could not be duplicated during a pipe operation.
" error), and so the minute that failed it was a dead-end...
This seems that the ArchView installation is broken on your side for whatever reason. I bet that this is because you did something wrong when manually managing your DLLs as I'm 100% sure that on a fresh eCS 2.2 Beta II install it will work soothly (my dev machine is close to the fresh install as much as possible — I isolate all dev work in separate .cmd environments).

Quote
While I understand the eventual simplicity of relying on RPM/YUM it just seems like we're not quite there yet. So in terms of testing out these beta release it just seems like it would be so much simpler to get a ZIP Firefox release and a matching ZIP release of all the required DLLs.
Maintaining such a ZIP is not a trivial task as it might seem and requires additional resources. Given that we invested a lot in RPM already to solve this particular task in a more perfect way, we are not going to do much in ZIP support. I hope you understand. I strongly recommend you to switch to YUM/RPM. We will better fix the RPM problems you discover rather than maintain such ZIPs (again, just because it's a more rational time investment).

Yeah, the "fly in the ointment" is the missing stuff, so just to show everyone else what I've got, here is the breakdown of what's available:

In our last README.OS2, we deliberately replaced all references to ZIP (that we auto-generate from RPMs for your convenience) in favor of RPM archives themselves for a very simple reason. In RPM, a project (application, library, etc) may be divided in several pieces: the application itself, the development files, the debug data etc. with each piece having its own RPM. When we create ZIPs we gather all project RPMs and pack them into a single ZIP. For some projects, the resulting ZIP may be very big. This the case for GCC, for instance: gcc-4_9_2_1-3_oc00.zip is 86 MB in size. It is insane to ask users to download this file if they only need a tiny DLL (gcc1.dll) which is only 30K. So we decided to change all ZIP link to direct RPM links. This assumes that you have a working ArcView installation, of course.

In cases of a single RPM per project, you were able to find the matching ZIP by hand. But in case of GCC you failed because there is simply no ZIP for this individual package we are referring to, you have to download the whole gcc-4_9_2_1-3_oc00.zip thingy. We may consider packing each RPM into a separate ZIP eventually but this is to be decided yet.

Pages: [1] 2