32 bits version of bundles

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

32 bits version of bundles

Gilles Caulier-4
Hi all,

Currently, the 32 bits version of Windows and AppImage bundles are provided.

Due to the complexity to build the 32 bits version of AppImage with Centos6, i think to drop 32 bits support in the future. The Windows 32 bits version is not a problem as MXE cross compiler work like a charm here...

Another problem is the capability to open large images in 32 bits. As memory user space is limited, the editor and BQM will fail to run properly with over 100Mb raw image data.

So my question is simple : any objections to drop bundle 32 bits support in the future, as for ex with next 6.0.x release ?

Best

Gilles Caulier
Reply | Threaded
Open this post in threaded view
|

Re: 32 bits version of bundles

Simon Frei
Personally I don't have any reason to oppose deprecation of 32bit.
Depending on how bad it is to create the 32bit versions, I would
consider asking on the user mailing list, whether there is anyone using
it - no point doing that if you don't want to do it anymore either way.

Cheers,
Simon

On 30/10/17 11:14, Gilles Caulier wrote:

> Hi all,
>
> Currently, the 32 bits version of Windows and AppImage bundles are
> provided.
>
> Due to the complexity to build the 32 bits version of AppImage with
> Centos6, i think to drop 32 bits support in the future. The Windows 32
> bits version is not a problem as MXE cross compiler work like a charm
> here...
>
> Another problem is the capability to open large images in 32 bits. As
> memory user space is limited, the editor and BQM will fail to run
> properly with over 100Mb raw image data.
>
> So my question is simple : any objections to drop bundle 32 bits
> support in the future, as for ex with next 6.0.x release ?
>
> Best
>
> Gilles Caulier

Reply | Threaded
Open this post in threaded view
|

Re: 32 bits version of bundles

Gilles Caulier-4
Hi all,

Important : The new area to store pre-release bundles is now this one :


... instead the deprecated GDrive repository :


The access to this area is done through ssh with your standard rsa key provided by KDE admin as developer (identity.kde.org). This is the Phabricator entry contents when KDE admin give explanation about it :

// ---------------------------------------

bcooksley closed this task as "Resolved".
bcooksley claimed this task.
bcooksley added a comment.

I've now created the space at https://files.kde.org/digikam/

You can access it by logging into the server via SSH as [hidden email]
The files should be placed at /srv/archives/files/digikam/ and as previously discussed, new names should be used for each file you upload, even if you remove it later on.



To: bcooksley
Cc: Digikam, bcooksley, cgilles, sysadmin, scarlettclark, blazquez

// ---------------------------------------

I changed the bundle scripts to use files.kde.org instead the GDrive repository. This will permit to upload bundle files automatically through SFTP.

The bundle files naming have changed. I use the timestamp to make unique files in the server, even if older ones are deleted at each upload. This is mandatory because the area is propagated to a lots of mirror on the web.

Gilles




2017-10-30 17:59 GMT+01:00 Simon Frei <[hidden email]>:
Personally I don't have any reason to oppose deprecation of 32bit.
Depending on how bad it is to create the 32bit versions, I would
consider asking on the user mailing list, whether there is anyone using
it - no point doing that if you don't want to do it anymore either way.

Cheers,
Simon

On 30/10/17 11:14, Gilles Caulier wrote:
> Hi all,
>
> Currently, the 32 bits version of Windows and AppImage bundles are
> provided.
>
> Due to the complexity to build the 32 bits version of AppImage with
> Centos6, i think to drop 32 bits support in the future. The Windows 32
> bits version is not a problem as MXE cross compiler work like a charm
> here...
>
> Another problem is the capability to open large images in 32 bits. As
> memory user space is limited, the editor and BQM will fail to run
> properly with over 100Mb raw image data.
>
> So my question is simple : any objections to drop bundle 32 bits
> support in the future, as for ex with next 6.0.x release ?
>
> Best
>
> Gilles Caulier