<div dir="ltr"><div>Hi all,</div><div><br></div>Important : The new area to store pre-release bundles is now this one :<div><br></div><div><a href="https://files.kde.org/digikam/" target="_blank">https://files.kde.org/digikam/</a></div><div><br></div><div>... instead the deprecated GDrive repository :</div><div><br></div><div><a href="https://drive.google.com/drive/folders/0BzeiVr-byqt5Y0tIRWVWelRJenM" target="_blank">https://drive.google.com/<wbr>drive/folders/0BzeiVr-<wbr>byqt5Y0tIRWVWelRJenM</a><br></div><div><br></div><div>The access to this area is done through ssh with your standard rsa key provided by KDE admin as developer (<a href="http://identity.kde.org" target="_blank">identity.kde.org</a>). This is the Phabricator entry contents when KDE admin give explanation about it :</div><div><br></div><div><div style="font-size:12.8px"><span style="font-size:16px">// ------------------------------<wbr>---------</span><br></div><div style="font-size:12.8px"><span style="font-size:16px"><br></span></div><div style="font-size:12.8px"><table style="font-size:16px"><tbody><tr><td>bcooksley closed this task as "Resolved".<br>bcooksley claimed this task.<br>bcooksley added a comment.</td></tr></tbody></table><br style="font-size:16px"><div style="font-size:16px"><p>I've now created the space at <a href="https://files.kde.org/digikam/" class="gmail-m_6761414348051517687gmail-m_-8045291380283257146remarkup-link" rel="noreferrer" target="_blank">https://files.kde.org/<wbr>digikam/</a></p><p>You can access it by logging into the server via SSH as <tt style="background:rgb(235,235,235);font-size:13px"><a href="mailto:digikam@racnoss.kde.org" target="_blank">digikam@racnoss.kde.org</a></tt>. <br>The files should be placed at <tt style="background:rgb(235,235,235);font-size:13px">/srv/archives/files/<wbr>digikam/</tt> and as previously discussed, new names should be used for each file you upload, even if you remove it later on.</p></div><br style="font-size:16px"><div style="font-size:16px"><strong>TASK DETAIL</strong><div><a href="https://phabricator.kde.org/T7388" rel="noreferrer" target="_blank">https://phabricator.kde.org/T7<wbr>388</a></div></div><br style="font-size:16px"><div style="font-size:16px"><strong>To: </strong>bcooksley<br><strong>Cc: </strong>Digikam, bcooksley, cgilles, sysadmin, scarlettclark, blazquez</div></div><div style="font-size:16px"><br></div><div style="font-size:16px">// ------------------------------<wbr>---------</div><div style="font-size:16px"><br></div><div style="font-size:16px">I changed the bundle scripts to use <a href="http://files.kde.org/" target="_blank">files.kde.org</a> instead the GDrive repository. This will permit to upload bundle files automatically through SFTP.</div><div style="font-size:16px"><br></div><div style="font-size:16px">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.</div></div><div style="font-size:16px"><br></div><div style="font-size:16px">Gilles</div><div><br><div><br></div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-10-30 17:59 GMT+01:00 Simon Frei <span dir="ltr"><<a href="mailto:freisim93@gmail.com" target="_blank">freisim93@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Personally I don't have any reason to oppose deprecation of 32bit.<br>
Depending on how bad it is to create the 32bit versions, I would<br>
consider asking on the user mailing list, whether there is anyone using<br>
it - no point doing that if you don't want to do it anymore either way.<br>
<br>
Cheers,<br>
Simon<br>
<div class="HOEnZb"><div class="h5"><br>
On 30/10/17 11:14, Gilles Caulier wrote:<br>
> Hi all,<br>
><br>
> Currently, the 32 bits version of Windows and AppImage bundles are<br>
> provided.<br>
><br>
> Due to the complexity to build the 32 bits version of AppImage with<br>
> Centos6, i think to drop 32 bits support in the future. The Windows 32<br>
> bits version is not a problem as MXE cross compiler work like a charm<br>
> here...<br>
><br>
> Another problem is the capability to open large images in 32 bits. As<br>
> memory user space is limited, the editor and BQM will fail to run<br>
> properly with over 100Mb raw image data.<br>
><br>
> So my question is simple : any objections to drop bundle 32 bits<br>
> support in the future, as for ex with next 6.0.x release ?<br>
><br>
> Best<br>
><br>
> Gilles Caulier<br>
<br>
</div></div></blockquote></div><br></div>