[opensuse-buildservice] EXE package format
At the end of the https://en.opensuse.org/openSUSE:Build_Service_comparison wiki page is a comparison of build infrastructures, and in the column "package format", OBS is said to support - even if only experimentally - the "exe" package format. A grep for zip\b or exe\b in the files of build.rpm does not yield any hint towards zip/exe generation, so where exactly may I find it? Having the actual program .exe in an .rpm is not too useful for Windows users… (but using mingw works really well otherwise!). -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Dienstag, 25. Februar 2014, 04:09:05 wrote Jan Engelhardt:
At the end of the https://en.opensuse.org/openSUSE:Build_Service_comparison wiki page is a comparison of build infrastructures, and in the column "package format", OBS is said to support - even if only experimentally - the "exe" package format.
A grep for zip\b or exe\b in the files of build.rpm does not yield any hint towards zip/exe generation, so where exactly may I find it? Having the actual program .exe in an .rpm is not too useful for Windows users… (but using mingw works really well otherwise!).
there is no such support in build, but one could add it via a hook using /usr/lib/build/checks/$script mechanism. This could extract the exe file and store it as seperate build result in OTHER directory. The publisher would need a few more lines to support publishing of these .exe lines, but that can get added fast. Please note that you would still need the rpms to support building against the libs. -- Adrian Schroeter email: adrian@suse.de SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Tue, Feb 25, 2014 at 07:41:00AM +0100, Adrian Schröter wrote:
On Dienstag, 25. Februar 2014, 04:09:05 wrote Jan Engelhardt:
At the end of the https://en.opensuse.org/openSUSE:Build_Service_comparison wiki page is a comparison of build infrastructures, and in the column "package format", OBS is said to support - even if only experimentally - the "exe" package format.
A grep for zip\b or exe\b in the files of build.rpm does not yield any hint towards zip/exe generation, so where exactly may I find it? Having the actual program .exe in an .rpm is not too useful for Windows users??? (but using mingw works really well otherwise!).
there is no such support in build, but one could add it via a hook using
/usr/lib/build/checks/$script
mechanism. This could extract the exe file and store it as seperate build result in OTHER directory.
I have done this via spec: https://build.opensuse.org/package/show/home:e9925248:mingw/mingw64-grandorg... A generic script is not able to find the useable parts. It is only useful to extract a installer, which also includes the DLLs and other resources. Currently, the exe-Files from OTHER are only available to registered OBS users. A drawback is, that without login, there is no indication, that you can download it after login.
The publisher would need a few more lines to support publishing of these .exe lines, but that can get added fast.
+1 for publishing such EXE to download.opensuse.org Zypper for Mingw would probably be the best solution. Otherwise, OBS should probably integrate something like that: http://lists.opensuse.org/opensuse-mingw/2014-02/msg00000.html Regards, Martin -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Dienstag, 25. Februar 2014, 20:03:36 wrote Martin Koegler:
On Tue, Feb 25, 2014 at 07:41:00AM +0100, Adrian Schröter wrote:
On Dienstag, 25. Februar 2014, 04:09:05 wrote Jan Engelhardt:
At the end of the https://en.opensuse.org/openSUSE:Build_Service_comparison wiki page is a comparison of build infrastructures, and in the column "package format", OBS is said to support - even if only experimentally - the "exe" package format.
A grep for zip\b or exe\b in the files of build.rpm does not yield any hint towards zip/exe generation, so where exactly may I find it? Having the actual program .exe in an .rpm is not too useful for Windows users??? (but using mingw works really well otherwise!).
there is no such support in build, but one could add it via a hook using
/usr/lib/build/checks/$script
mechanism. This could extract the exe file and store it as seperate build result in OTHER directory.
I have done this via spec: https://build.opensuse.org/package/show/home:e9925248:mingw/mingw64-grandorg...
cool... One thing, I am unsure how to handle is the version-release handling of these files. IMHO the version and also the release number of the spec file should be part of these files. Otherwise there is no way how mirrors and users can destinguish between them.
A generic script is not able to find the useable parts. It is only useful to extract a installer, which also includes the DLLs and other resources.
Currently, the exe-Files from OTHER are only available to registered OBS users. A drawback is, that without login, there is no indication, that you can download it after login.
The publisher would need a few more lines to support publishing of these .exe lines, but that can get added fast.
+1 for publishing such EXE to download.opensuse.org
I have added now a very-very basic export support of .exec files. Your repository was my testcase :) I am not sure, if this can stay this way though due to the version-release thingy. we need to find a solution for that ... -- Adrian Schroeter email: adrian@suse.de SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Wednesday 2014-02-26 10:48, Adrian Schröter wrote:
https://build.opensuse.org/package/show/home:e9925248:mingw/mingw64-grandorg...
cool...
And in the same way, one can produce ZIPs (my ideal target) zip -9r "%_topdir/OTHER/%name-w64-%version-%release.zip" *.exe *.txt whatever or CABs or MSIs, provided one finds a suitable generator.
The publisher would need a few more lines to support publishing of these .exe lines, but that can get added fast.
+1 for publishing such EXE to download.opensuse.org
I have added now a very-very basic export support of .exec files. Your repository was my testcase :)
One thing, I am unsure how to handle is the version-release handling of these files. IMHO the version and also the release number of the spec file should be part of these files. Otherwise there is no way how mirrors and users can destinguish between them.
Mirrors (that is, the rsyncing process) should be able to look at the timestamp of the file, and so do users. It's not ideal, but getting the files mirrored at all seems worthwhile. I thought of just gobbling up all files from the OTHER/ directory that match /-%version-%release\./ (no BOL or EOL anchors!). That does not give you the freedom you have with rpm filenaming, but better than nothing. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Wed, Feb 26, 2014 at 06:47:49PM +0100, Jan Engelhardt wrote:
On Wednesday 2014-02-26 10:48, Adrian Schröter wrote:
https://build.opensuse.org/package/show/home:e9925248:mingw/mingw64-grandorg...
cool...
First, thanks. I'll forward the link to some users.
IMHO the version and also the release number of the spec file should be part of these files. Otherwise there is no way how mirrors and users can destinguish between them.
Mirrors (that is, the rsyncing process) should be able to look at the timestamp of the file, and so do users. It's not ideal, but getting the files mirrored at all seems worthwhile.
Each publish regenerates repomd.xml - so if the mirrors could not handle this, we would see lots of outdated or invalid repository content on the mirrors. For the users, %release would not matter in my case. The source is extracted from SVN, %version includes the revision and the installer is self-contained. It simply does not matter, if the installer is build using GCC 4.7.1 or 4.7.2.
I thought of just gobbling up all files from the OTHER/ directory that match /-%version-%release\./ (no BOL or EOL anchors!). That does not give you the freedom you have with rpm filenaming, but better than nothing.
Especially for the mingw context, you have to include $ARCH (win32/win64) in the filename. In my option, -$ARCH looks better than .$ARCH: GrandOrgue-0.3.1.1613-win32.exe Regards, Martin -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Mittwoch, 26. Februar 2014, 20:13:33 wrote Martin Koegler:
On Wed, Feb 26, 2014 at 06:47:49PM +0100, Jan Engelhardt wrote:
On Wednesday 2014-02-26 10:48, Adrian Schröter wrote:
https://build.opensuse.org/package/show/home:e9925248:mingw/mingw64-grandorg...
cool...
First, thanks. I'll forward the link to some users.
IMHO the version and also the release number of the spec file should be part of these files. Otherwise there is no way how mirrors and users can destinguish between them.
Mirrors (that is, the rsyncing process) should be able to look at the timestamp of the file, and so do users. It's not ideal, but getting the files mirrored at all seems worthwhile.
Each publish regenerates repomd.xml - so if the mirrors could not handle this, we would see lots of outdated or invalid repository content on the mirrors.
we delivere the repo meta data for that (and security) reasons only via trusted servers. But also our download redirector depends on the file name. So, if there are multiple files with same file name each user may get a different version. Depending on the used mirror.
For the users, %release would not matter in my case. The source is extracted from SVN, %version includes the revision and the installer is self-contained. It simply does not matter, if the installer is build using GCC 4.7.1 or 4.7.2.
erm, I doubt. There will be cases where it does matter for sure which packages got used. This is not limited to gcc, but also important for all used libs.
I thought of just gobbling up all files from the OTHER/ directory that match /-%version-%release\./ (no BOL or EOL anchors!). That does not give you the freedom you have with rpm filenaming, but better than nothing.
Especially for the mingw context, you have to include $ARCH (win32/win64) in the filename.
In my option, -$ARCH looks better than .$ARCH: GrandOrgue-0.3.1.1613-win32.exe
given that .exe files do not contain meta informations like rpm packages do (like version-release or the disturl) it is even more important for .exe files IMHO to have the commit and build counter ... -- Adrian Schroeter email: adrian@suse.de SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Wed, Feb 26, 2014 at 08:40:41PM +0100, Adrian Schröter wrote:
Each publish regenerates repomd.xml - so if the mirrors could not handle this, we would see lots of outdated or invalid repository content on the mirrors.
we delivere the repo meta data for that (and security) reasons only via trusted servers. But also our download redirector depends on the file name.
So, if there are multiple files with same file name each user may get a different version. Depending on the used mirror.
For the users, %release would not matter in my case. The source is extracted from SVN, %version includes the revision and the installer is self-contained. It simply does not matter, if the installer is build using GCC 4.7.1 or 4.7.2.
erm, I doubt. There will be cases where it does matter for sure which packages got used. This is not limited to gcc, but also important for all used libs.
I talked about my package: This would only matter, if we would have a zypper like solution. If you put all dependencies into the installer, the whole thing is self-contained with no external dependencies.
I thought of just gobbling up all files from the OTHER/ directory that match /-%version-%release\./ (no BOL or EOL anchors!). That does not give you the freedom you have with rpm filenaming, but better than nothing.
Especially for the mingw context, you have to include $ARCH (win32/win64) in the filename.
In my option, -$ARCH looks better than .$ARCH: GrandOrgue-0.3.1.1613-win32.exe
given that .exe files do not contain meta informations like rpm packages do (like version-release or the disturl) it is even more important for .exe files IMHO to have the commit and build counter ...
I want to help OBS to improve that support. Should I move to GrandOrgue-%{version}-%{version}-win%{_mingw_bitsize}.exe with my next update? Regards, Martin -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Mittwoch, 26. Februar 2014, 22:17:23 wrote Martin Koegler:
On Wed, Feb 26, 2014 at 08:40:41PM +0100, Adrian Schröter wrote:
Each publish regenerates repomd.xml - so if the mirrors could not handle this, we would see lots of outdated or invalid repository content on the mirrors.
we delivere the repo meta data for that (and security) reasons only via trusted servers. But also our download redirector depends on the file name.
So, if there are multiple files with same file name each user may get a different version. Depending on the used mirror.
For the users, %release would not matter in my case. The source is extracted from SVN, %version includes the revision and the installer is self-contained. It simply does not matter, if the installer is build using GCC 4.7.1 or 4.7.2.
erm, I doubt. There will be cases where it does matter for sure which packages got used. This is not limited to gcc, but also important for all used libs.
I talked about my package: This would only matter, if we would have a zypper like solution. If you put all dependencies into the installer, the whole thing is self-contained with no external dependencies.
I thought of just gobbling up all files from the OTHER/ directory that match /-%version-%release\./ (no BOL or EOL anchors!). That does not give you the freedom you have with rpm filenaming, but better than nothing.
Especially for the mingw context, you have to include $ARCH (win32/win64) in the filename.
In my option, -$ARCH looks better than .$ARCH: GrandOrgue-0.3.1.1613-win32.exe
given that .exe files do not contain meta informations like rpm packages do (like version-release or the disturl) it is even more important for .exe files IMHO to have the commit and build counter ...
I want to help OBS to improve that support.
Should I move to GrandOrgue-%{version}-%{version}-win%{_mingw_bitsize}.exe
The second %version is %release? Yes, IMHO the better choice. Maybe I should modify the publisher that it only publishes such files like it does with rpm and deb files. What do you think? -- Adrian Schroeter email: adrian@suse.de SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Thursday 2014-02-27 01:02, Adrian Schröter wrote:
Should I move to GrandOrgue-%{version}-%{version}-win%{_mingw_bitsize}.exe
The second %version is %release? Yes, IMHO the better choice.
Maybe I should modify the publisher that it only publishes such files like it does with rpm and deb files.
What do you think?
The same: http://lists.opensuse.org/opensuse-buildservice/2014-02/msg00073.html -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Donnerstag, 27. Februar 2014, 01:06:53 wrote Jan Engelhardt:
On Thursday 2014-02-27 01:02, Adrian Schröter wrote:
Should I move to GrandOrgue-%{version}-%{version}-win%{_mingw_bitsize}.exe
The second %version is %release? Yes, IMHO the better choice.
Maybe I should modify the publisher that it only publishes such files like it does with rpm and deb files.
What do you think?
The same: http://lists.opensuse.org/opensuse-buildservice/2014-02/msg00073.html
well, since we need to put some files, like rpms and debs into specific subdirectories the generic export will not work. Of course we can add also support for zip, msi or whatever if there is a usecase. -- Adrian Schroeter email: adrian@suse.de SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Thu, Feb 27, 2014 at 01:02:59AM +0100, Adrian Schröter wrote:
I want to help OBS to improve that support.
Should I move to GrandOrgue-%{version}-%{version}-win%{_mingw_bitsize}.exe
The second %version is %release? Yes, IMHO the better choice.
Maybe I should modify the publisher that it only publishes such files like it does with rpm and deb files.
I have updated the file names. Regards, Martin PS: One usefull addtion to the source services would be a "sed" service. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Sonntag, 2. März 2014, 19:55:53 wrote Martin Koegler:
On Thu, Feb 27, 2014 at 09:52:06PM +0100, Martin Koegler wrote:
One usefull addtion to the source services would be a "sed" service.
Would it be possible to get something like the attached sketch into OBS?
should be possible (just looked briefly at it). We need to verify that the script is save enough not to execute random commands via parameters. But it should be okay atm. -- Adrian Schroeter email: adrian@suse.de SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Mon, Mar 03, 2014 at 10:28:56AM +0100, Adrian Schröter wrote:
On Sonntag, 2. März 2014, 19:55:53 wrote Martin Koegler:
On Thu, Feb 27, 2014 at 09:52:06PM +0100, Martin Koegler wrote:
One usefull addtion to the source services would be a "sed" service.
Would it be possible to get something like the attached sketch into OBS?
should be possible (just looked briefly at it).
We need to verify that the script is save enough not to execute random commands via parameters. But it should be okay atm.
In my option, it should be as safe as set_version. Nearly all code is stolen from set_version. The main difference is, that you can pass a arbitray sed command. This is not any additional security risk, as you can already trick set_version to execute arbitray sed commands: set_version --version "A/;s/bitsize XX .*/bitsize 32/g;s/@/@" Doing first a set_version with such a version and then a normal set_version should work for me, but I still would like a clean solution in OBS. Regards, Martin -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Montag, 3. März 2014, 19:48:57 wrote Martin Koegler:
On Mon, Mar 03, 2014 at 10:28:56AM +0100, Adrian Schröter wrote:
On Sonntag, 2. März 2014, 19:55:53 wrote Martin Koegler:
On Thu, Feb 27, 2014 at 09:52:06PM +0100, Martin Koegler wrote:
One usefull addtion to the source services would be a "sed" service.
Would it be possible to get something like the attached sketch into OBS?
should be possible (just looked briefly at it).
We need to verify that the script is save enough not to execute random commands via parameters. But it should be okay atm.
In my option, it should be as safe as set_version.
yes, I do not question that :)
Nearly all code is stolen from set_version. The main difference is, that you can pass a arbitray sed command. This is not any additional security risk, as you can already trick set_version to execute arbitray sed commands:
set_version --version "A/;s/bitsize XX .*/bitsize 32/g;s/@/@"
uh, I was not aware about this possibility .... In any case, feel free to submit it. A submit request to openSUSE:Tools project would be fine. -- Adrian Schroeter email: adrian@suse.de SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Wed, Mar 05, 2014 at 10:12:54AM +0100, Adrian Schröter wrote:
set_version --version "A/;s/bitsize XX .*/bitsize 32/g;s/@/@"
uh, I was not aware about this possibility ....
I had a look at the new set_version @ github. The old set_version had been able to use wildcard in the file parameter, but the new set_version passes the file names directly to open. Regards, Martin -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Wednesday 2014-02-26 20:13, Martin Koegler wrote:
Mirrors (that is, the rsyncing process) should be able to look at the timestamp of the file, and so do users. It's not ideal, but getting the files mirrored at all seems worthwhile.
Each publish regenerates repomd.xml -
What's the usecase for having non-RPMs in rpm-md? -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Wed, Feb 26, 2014 at 10:08:03PM +0100, Jan Engelhardt wrote:
Mirrors (that is, the rsyncing process) should be able to look at the timestamp of the file, and so do users. It's not ideal, but getting the files mirrored at all seems worthwhile.
Each publish regenerates repomd.xml -
What's the usecase for having non-RPMs in rpm-md?
I have not suggest including it into rpm-md. repomd.xml is changed without changing its filename. Regards, Martin -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Wed, Feb 26, 2014 at 06:47:49PM +0100, Jan Engelhardt wrote:
One thing, I am unsure how to handle is the version-release handling of these files. IMHO the version and also the release number of the spec file should be part of these files. Otherwise there is no way how mirrors and users can destinguish between them.
What about the debian packages? set_version just only inserts the version number (detected from the tar-ball) without release. Regards, Martin -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
participants (3)
-
Adrian Schröter -
Jan Engelhardt -
Martin Koegler