[opensuse-packaging] Obsoleted %suse_update_desktop_file
Hi, Over the last couple of days I reworked update-desktop-files not to rely on an explicit %suse_update_desktop_file call. Instead Factory will have an additional brp script that trims the translations from .desktop files. So: if you can live with an rpmlint warning on older distributions (I submited a rpmlint with the warning gone for factory), you can skip the macro now if you call it without options. The most useful option of the macro should be the -n option now, as this one will mark the .desktop file with translate=false, which then also skips the trimming. There is one problem with removing the buildrequires on update-desktop-files though: this package includes rpm provide triggers for mimehandler(), so don't remove the buildrequire if you have MimeType= in your .desktop file. Or we move that triggers to a package always installed in factory. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hi, Le mercredi 14 décembre 2011, à 10:12 +0100, Stephan Kulow a écrit :
Hi,
Over the last couple of days I reworked update-desktop-files not to rely on an explicit %suse_update_desktop_file call. Instead Factory will have an additional brp script that trims the translations from .desktop files.
So: if you can live with an rpmlint warning on older distributions (I submited a rpmlint with the warning gone for factory), you can skip the macro now if you call it without options.
That's great news!
The most useful option of the macro should be the -n option now, as this one will mark the .desktop file with translate=false, which then also skips the trimming.
If people are using %suse_update_desktop_file to edit the .desktop file, I recommend to look at using desktop-file-install instead (in desktop-file-utils). It doesn't provide all the options of %suse_update_desktop_file yet, but I can add what is needed. This would move us closer to what other distros do.
There is one problem with removing the buildrequires on update-desktop-files though: this package includes rpm provide triggers for mimehandler(), so don't remove the buildrequire if you have MimeType= in your .desktop file. Or we move that triggers to a package always installed in factory.
We can move that to desktop-file-utils if it helps. Cheers, Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 14.12.2011 10:34, Vincent Untz wrote:
If people are using %suse_update_desktop_file to edit the .desktop file, I recommend to look at using desktop-file-install instead (in desktop-file-utils). It doesn't provide all the options of %suse_update_desktop_file yet, but I can add what is needed. This would move us closer to what other distros do.
Well, this is bizarre anyway. Check blender.spec: # x-blend.desktop %if 0%{?suse_version} install -D -m 0644 "%{S:7}" "%{buildroot}%{_datadir}/applications/x-blend.desktop" %suse_update_desktop_file %{buildroot}/%{_datadir}/applications/x-blend.desktop # blender.desktop %suse_update_desktop_file -i "%{name}" %else %if 0%{?fedora} # Install the .desktop file the Fedora way desktop-file-install --dir=%{buildroot}%{_datadir}/applications %{S:7} # Validate blender.desktop desktop-file-validate %{buildroot}%{_datadir}/applications/blender.desktop %endif %endif I can't say that the desktop-file-install line is nicer than using -i option, but for a spec file that is meant to compile on both, it sounds good to have one way.
There is one problem with removing the buildrequires on update-desktop-files though: this package includes rpm provide triggers for mimehandler(), so don't remove the buildrequire if you have MimeType= in your .desktop file. Or we move that triggers to a package always installed in factory.
We can move that to desktop-file-utils if it helps.
Sounds like a plan - in combination with an rpmlint error if you have MimeType in .desktop and do not provide mimehandler() Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Le mercredi 14 décembre 2011, à 10:48 +0100, Stephan Kulow a écrit :
On 14.12.2011 10:34, Vincent Untz wrote:
If people are using %suse_update_desktop_file to edit the .desktop file, I recommend to look at using desktop-file-install instead (in desktop-file-utils). It doesn't provide all the options of %suse_update_desktop_file yet, but I can add what is needed. This would move us closer to what other distros do.
Well, this is bizarre anyway. Check blender.spec:
# x-blend.desktop %if 0%{?suse_version} install -D -m 0644 "%{S:7}" "%{buildroot}%{_datadir}/applications/x-blend.desktop" %suse_update_desktop_file %{buildroot}/%{_datadir}/applications/x-blend.desktop # blender.desktop %suse_update_desktop_file -i "%{name}" %else %if 0%{?fedora} # Install the .desktop file the Fedora way desktop-file-install --dir=%{buildroot}%{_datadir}/applications %{S:7} # Validate blender.desktop desktop-file-validate %{buildroot}%{_datadir}/applications/blender.desktop %endif %endif
I can't say that the desktop-file-install line is nicer than using -i option, but for a spec file that is meant to compile on both, it sounds good to have one way.
Yeah, the --dir is ugly. I'm thinking of adding a desktop-file-edit binary (well, link to desktop-file-install) that would simply do inline edits.
There is one problem with removing the buildrequires on update-desktop-files though: this package includes rpm provide triggers for mimehandler(), so don't remove the buildrequire if you have MimeType= in your .desktop file. Or we move that triggers to a package always installed in factory.
We can move that to desktop-file-utils if it helps.
Sounds like a plan - in combination with an rpmlint error if you have MimeType in .desktop and do not provide mimehandler()
Good idea. Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hey, Le mercredi 14 décembre 2011, à 10:48 +0100, Stephan Kulow a écrit :
On 14.12.2011 10:34, Vincent Untz wrote:
There is one problem with removing the buildrequires on update-desktop-files though: this package includes rpm provide triggers for mimehandler(), so don't remove the buildrequire if you have MimeType= in your .desktop file. Or we move that triggers to a package always installed in factory.
We can move that to desktop-file-utils if it helps.
Sounds like a plan - in combination with an rpmlint error if you have MimeType in .desktop and do not provide mimehandler()
Actually, the rpm package already ships the mimehandler() magic: /usr/lib/rpm/desktop-file.prov But you disabled it back in June, in fileattrs.diff (desktop.attr doesn't get installed). Maybe we can just revert that? Or is the rationale for that change still valid? Cheers, Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 15.12.2011 09:51, Vincent Untz wrote:
Hey,
Le mercredi 14 décembre 2011, à 10:48 +0100, Stephan Kulow a écrit :
On 14.12.2011 10:34, Vincent Untz wrote:
There is one problem with removing the buildrequires on update-desktop-files though: this package includes rpm provide triggers for mimehandler(), so don't remove the buildrequire if you have MimeType= in your .desktop file. Or we move that triggers to a package always installed in factory.
We can move that to desktop-file-utils if it helps.
Sounds like a plan - in combination with an rpmlint error if you have MimeType in .desktop and do not provide mimehandler()
Actually, the rpm package already ships the mimehandler() magic: /usr/lib/rpm/desktop-file.prov
But you disabled it back in June, in fileattrs.diff (desktop.attr doesn't get installed). Maybe we can just revert that? Or is the rationale for that change still valid?
as already discussed in irc (just for reference for those not in that discussion): yes and no. I see no reason to move things out of rpm, but the change I did back then was just to fix up build failures created by Michael moving things out of rpm into update-desktop-file. We need to revisit that decision. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
* Stephan Kulow <coolo@suse.de> [2011-12-14 10:12]:
Hi,
Over the last couple of days I reworked update-desktop-files not to rely on an explicit %suse_update_desktop_file call. Instead Factory will have an additional brp script that trims the translations from .desktop files.
So: if you can live with an rpmlint warning on older distributions (I submited a rpmlint with the warning gone for factory), you can skip the macro now if you call it without options.
The most useful option of the macro should be the -n option now, as this one will mark the .desktop file with translate=false, which then also skips the trimming.
There is one problem with removing the buildrequires on update-desktop-files though: this package includes rpm provide triggers for mimehandler(), so don't remove the buildrequire if you have MimeType= in your .desktop file. Or we move that triggers to a package always installed in factory.
The macro also has some other very useful functions, it allows one to replace the name, generic name, or all categories without the need add and maintain patches. I also find the ability to generate desktop files from scratch convenient and compact though it is less important. Since desktop-file-install currently is not able to do any of that I don't think it is a good idea to obsolete %suse_update_desktop_file. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 14.12.2011 12:31, Guido Berhoerster wrote:
* Stephan Kulow <coolo@suse.de> [2011-12-14 10:12]:
Hi,
Over the last couple of days I reworked update-desktop-files not to rely on an explicit %suse_update_desktop_file call. Instead Factory will have an additional brp script that trims the translations from .desktop files.
So: if you can live with an rpmlint warning on older distributions (I submited a rpmlint with the warning gone for factory), you can skip the macro now if you call it without options.
The most useful option of the macro should be the -n option now, as this one will mark the .desktop file with translate=false, which then also skips the trimming.
There is one problem with removing the buildrequires on update-desktop-files though: this package includes rpm provide triggers for mimehandler(), so don't remove the buildrequire if you have MimeType= in your .desktop file. Or we move that triggers to a package always installed in factory.
The macro also has some other very useful functions, it allows one to replace the name, generic name, or all categories without the need add and maintain patches. I also find the ability to generate desktop files from scratch convenient and compact though it is less important. Since desktop-file-install currently is not able to do any of that I don't think it is a good idea to obsolete %suse_update_desktop_file.
I don't want to remove the functionality - but perhaps we should change the name and/or put wrapper macros for the functionality wanted to desktop-file-utils? Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
* Stephan Kulow <coolo@suse.de> [2011-12-14 13:35]:
On 14.12.2011 12:31, Guido Berhoerster wrote:
* Stephan Kulow <coolo@suse.de> [2011-12-14 10:12]:
Hi,
Over the last couple of days I reworked update-desktop-files not to rely on an explicit %suse_update_desktop_file call. Instead Factory will have an additional brp script that trims the translations from .desktop files.
So: if you can live with an rpmlint warning on older distributions (I submited a rpmlint with the warning gone for factory), you can skip the macro now if you call it without options.
The most useful option of the macro should be the -n option now, as this one will mark the .desktop file with translate=false, which then also skips the trimming.
There is one problem with removing the buildrequires on update-desktop-files though: this package includes rpm provide triggers for mimehandler(), so don't remove the buildrequire if you have MimeType= in your .desktop file. Or we move that triggers to a package always installed in factory.
The macro also has some other very useful functions, it allows one to replace the name, generic name, or all categories without the need add and maintain patches. I also find the ability to generate desktop files from scratch convenient and compact though it is less important. Since desktop-file-install currently is not able to do any of that I don't think it is a good idea to obsolete %suse_update_desktop_file.
I don't want to remove the functionality - but perhaps we should change the name and/or put wrapper macros for the functionality wanted to desktop-file-utils?
As long as suse_update_desktop_file.sh remains available that's fine. I guess it could be moved to desktop-file-utils and the corresponding macro calling it could be renamed to something like %update_desktop_file. That way specfiles could be automatically converted at a later stage, that is all calls of %suse_update_desktop_file without additional arguments could be automatically removed and those with arguments could be replaced with %update_desktop_file. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Le mercredi 14 décembre 2011, à 12:31 +0100, Guido Berhoerster a écrit :
* Stephan Kulow <coolo@suse.de> [2011-12-14 10:12]:
Hi,
Over the last couple of days I reworked update-desktop-files not to rely on an explicit %suse_update_desktop_file call. Instead Factory will have an additional brp script that trims the translations from .desktop files.
So: if you can live with an rpmlint warning on older distributions (I submited a rpmlint with the warning gone for factory), you can skip the macro now if you call it without options.
The most useful option of the macro should be the -n option now, as this one will mark the .desktop file with translate=false, which then also skips the trimming.
There is one problem with removing the buildrequires on update-desktop-files though: this package includes rpm provide triggers for mimehandler(), so don't remove the buildrequire if you have MimeType= in your .desktop file. Or we move that triggers to a package always installed in factory.
The macro also has some other very useful functions, it allows one to replace the name, generic name, or all categories without the need add and maintain patches.
It's doable with desktop-file-install now (in my git branch, will push to master soon and a release will also come).
I also find the ability to generate desktop files from scratch convenient and compact though it is less important.
I must admit I'm not a big fan of that, but this could be added to desktop-file-utils too... Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Le mercredi 14 décembre 2011, à 14:29 +0100, Vincent Untz a écrit :
Le mercredi 14 décembre 2011, à 12:31 +0100, Guido Berhoerster a écrit :
The macro also has some other very useful functions, it allows one to replace the name, generic name, or all categories without the need add and maintain patches.
It's doable with desktop-file-install now (in my git branch, will push to master soon and a release will also come).
In desktop-file-utils from git [1], we now have desktop-file-edit. This works like desktop-file-install, except that it changes the desktop file directly, instead of installing it somewhere. =================== Usage: desktop-file-edit [OPTION...] [FILE...] Edit a desktop file. Edition options for desktop file --set-key=KEY Set the KEY key to VALUE passed to next --set-value option --set-value=VALUE Set the KEY key from previous --set-key option to VALUE --set-name=NAME Set the "Name" key to NAME --copy-generic-name-to-name Copy the value of the "GenericName" key to the "Name" key --set-generic-name=GENERIC-NAME Set the "GenericName" key to GENERIC-NAME --copy-name-to-generic-name Copy the value of the "Name" key to the "GenericName" key --set-comment=COMMENT Set the "Comment" key to COMMENT --set-icon=ICON Set the "Icon" key to ICON --add-category=CATEGORY Add CATEGORY to the list of categories --remove-category=CATEGORY Remove CATEGORY from the list of categories --add-mime-type=MIME-TYPE Add MIME-TYPE to the list of MIME types --remove-mime-type=MIME-TYPE Remove MIME-TYPE from the list of MIME types --add-only-show-in=ENVIRONMENT Add ENVIRONMENT to the list of desktop environment where the desktop files should be displayed --remove-only-show-in=ENVIRONMENT Remove ENVIRONMENT from the list of desktop environment where the desktop files should be displayed --add-not-show-in=ENVIRONMENT Add ENVIRONMENT to the list of desktop environment where the desktop files should not be displayed --remove-not-show-in=ENVIRONMENT Remove ENVIRONMENT from the list of desktop environment where the desktop files should not be displayed --remove-key=KEY Remove the KEY key from the desktop files, if present =================== Here's how to replace %suse_update_desktop_file options with it: %suse_update_desktop_file -N <string> => desktop-file-edit --set-name <string> %suse_update_desktop_file -C <string> => desktop-file-edit --set-comment <string> %suse_update_desktop_file -G <string> => desktop-file-edit --set-generic-name <string> %suse_update_desktop_file <category> => desktop-file-edit --add-category=<category> %suse_update_desktop_file -r => desktop-file-edit --remove-key Categories %suse_update_desktop_file -u => desktop-file-edit --set-key NoDisplay --set-value true %suse_update_desktop_file -D <string> => desktop-file-edit --set-key DocPath --set-value <string> %suse_update_desktop_file -d <string> => desktop-file-edit --set-key X-SuSE-DocTeamID --set-value <string> %suse_update_desktop_file -i => desktop-file-install --dir %{buildroot}%{_datadir}/applications Of course, you can combine all the options. I don't believe that -u and -D options are used often enough to be worth a specific desktop-file-edit option. If there are people caring deeply about --create, I can add such an option too. Is there anything else missing people would like to see before I do a release? Cheers, Vincent [1] http://cgit.freedesktop.org/xdg/desktop-file-utils/ -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Le mercredi 14 décembre 2011, à 17:18 +0100, Vincent Untz a écrit :
Here's how to replace %suse_update_desktop_file options with it: [...] %suse_update_desktop_file -i => desktop-file-install --dir %{buildroot}%{_datadir}/applications
I had forgotten one change, so this is now simpler: just use desktop-file-install with no --dir (it'll use $RPM_BUILD_ROOT if it's set). Cheers, Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
* Vincent Untz <vuntz@opensuse.org> [2011-12-14 17:18]:
Le mercredi 14 décembre 2011, à 14:29 +0100, Vincent Untz a écrit :
Le mercredi 14 décembre 2011, à 12:31 +0100, Guido Berhoerster a écrit :
The macro also has some other very useful functions, it allows one to replace the name, generic name, or all categories without the need add and maintain patches.
It's doable with desktop-file-install now (in my git branch, will push to master soon and a release will also come).
In desktop-file-utils from git [1], we now have desktop-file-edit. This works like desktop-file-install, except that it changes the desktop file directly, instead of installing it somewhere.
=================== Usage: desktop-file-edit [OPTION...] [FILE...]
Edit a desktop file.
Edition options for desktop file --set-key=KEY Set the KEY key to VALUE passed to next --set-value option --set-value=VALUE Set the KEY key from previous --set-key option to VALUE --set-name=NAME Set the "Name" key to NAME --copy-generic-name-to-name Copy the value of the "GenericName" key to the "Name" key --set-generic-name=GENERIC-NAME Set the "GenericName" key to GENERIC-NAME --copy-name-to-generic-name Copy the value of the "Name" key to the "GenericName" key --set-comment=COMMENT Set the "Comment" key to COMMENT --set-icon=ICON Set the "Icon" key to ICON --add-category=CATEGORY Add CATEGORY to the list of categories --remove-category=CATEGORY Remove CATEGORY from the list of categories --add-mime-type=MIME-TYPE Add MIME-TYPE to the list of MIME types --remove-mime-type=MIME-TYPE Remove MIME-TYPE from the list of MIME types --add-only-show-in=ENVIRONMENT Add ENVIRONMENT to the list of desktop environment where the desktop files should be displayed --remove-only-show-in=ENVIRONMENT Remove ENVIRONMENT from the list of desktop environment where the desktop files should be displayed --add-not-show-in=ENVIRONMENT Add ENVIRONMENT to the list of desktop environment where the desktop files should not be displayed --remove-not-show-in=ENVIRONMENT Remove ENVIRONMENT from the list of desktop environment where the desktop files should not be displayed --remove-key=KEY Remove the KEY key from the desktop files, if present ===================
Here's how to replace %suse_update_desktop_file options with it:
%suse_update_desktop_file -N <string> => desktop-file-edit --set-name <string> %suse_update_desktop_file -C <string> => desktop-file-edit --set-comment <string> %suse_update_desktop_file -G <string> => desktop-file-edit --set-generic-name <string> %suse_update_desktop_file <category> => desktop-file-edit --add-category=<category> %suse_update_desktop_file -r => desktop-file-edit --remove-key Categories %suse_update_desktop_file -u => desktop-file-edit --set-key NoDisplay --set-value true %suse_update_desktop_file -D <string> => desktop-file-edit --set-key DocPath --set-value <string> %suse_update_desktop_file -d <string> => desktop-file-edit --set-key X-SuSE-DocTeamID --set-value <string> %suse_update_desktop_file -i => desktop-file-install --dir %{buildroot}%{_datadir}/applications
Of course, you can combine all the options. I don't believe that -u and -D options are used often enough to be worth a specific desktop-file-edit option.
If there are people caring deeply about --create, I can add such an option too.
Is there anything else missing people would like to see before I do a release?
Looks good, particularly the generic --set-key/value is nice. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Wednesday 14 December 2011 20:18:22 Vincent Untz wrote:
Here's how to replace %suse_update_desktop_file options with it:
%suse_update_desktop_file -N <string> => desktop-file-edit --set-name <string> %suse_update_desktop_file -C <string> => desktop-file-edit --set-comment <string> %suse_update_desktop_file -G <string> => desktop-file-edit --set-generic-name <string> %suse_update_desktop_file <category> => desktop-file-edit --add-category=<category> %suse_update_desktop_file -r => desktop-file-edit --remove-key Categories %suse_update_desktop_file -u => desktop-file-edit --set-key NoDisplay --set-value true %suse_update_desktop_file -D <string> => desktop-file-edit --set-key DocPath --set-value <string> %suse_update_desktop_file -d <string> => desktop-file-edit --set-key X-SuSE-DocTeamID --set-value <string> %suse_update_desktop_file -i => desktop-file-install --dir %{buildroot}%{_datadir}/applications
Of course, you can combine all the options. I don't believe that -u and -D options are used often enough to be worth a specific desktop-file-edit option.
If there are people caring deeply about --create, I can add such an option too.
Is there anything else missing people would like to see before I do a release?
Is it possible to make a wrapper/aliases for the abovementioned correspondencies so not to rewrite all the specs? Actually I remember I removed calls to desktop-file-utils in many spec files when porting them from Fedora, and replaced them with calls to %suse_update_desktop_file as a suse-way of doing things. I do not want to reverse it all back now. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hi, Le mercredi 14 décembre 2011, à 22:17 +0400, Ilya Chernykh a écrit :
On Wednesday 14 December 2011 20:18:22 Vincent Untz wrote:
Here's how to replace %suse_update_desktop_file options with it:
%suse_update_desktop_file -N <string> => desktop-file-edit --set-name <string> %suse_update_desktop_file -C <string> => desktop-file-edit --set-comment <string> %suse_update_desktop_file -G <string> => desktop-file-edit --set-generic-name <string> %suse_update_desktop_file <category> => desktop-file-edit --add-category=<category> %suse_update_desktop_file -r => desktop-file-edit --remove-key Categories %suse_update_desktop_file -u => desktop-file-edit --set-key NoDisplay --set-value true %suse_update_desktop_file -D <string> => desktop-file-edit --set-key DocPath --set-value <string> %suse_update_desktop_file -d <string> => desktop-file-edit --set-key X-SuSE-DocTeamID --set-value <string> %suse_update_desktop_file -i => desktop-file-install --dir %{buildroot}%{_datadir}/applications
Of course, you can combine all the options. I don't believe that -u and -D options are used often enough to be worth a specific desktop-file-edit option.
If there are people caring deeply about --create, I can add such an option too.
Is there anything else missing people would like to see before I do a release?
Is it possible to make a wrapper/aliases for the abovementioned correspondencies so not to rewrite all the specs?
There's no point in making a wrapper: just keep using %suse_update_desktop_file if this is what you prefer :-) Cheers, Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 2011-12-14 17:18:22 (+0100), Vincent Untz <vuntz@opensuse.org> wrote:
Le mercredi 14 décembre 2011, à 14:29 +0100, Vincent Untz a écrit : [...] Is there anything else missing people would like to see before I do a release?
Please make it available for *all* the openSUSE versions, not just factory, or 1) it's useless if you care about anything else than factory 2) it will break packages that are maintained in factory and linked to elsewhere, because that's what usually happens: the packagers who maintain stuff in openSUSE:Factory don't always care about the package being able to build on older dists If it's only available for factory, then we'll have to wait quite a long time before being able to use it in spec files :\ cheers -- -o) Pascal Bleser /\\ http://opensuse.org -- we haz green _\_v http://fosdem.org -- we haz conf
Monday 19 December 2011 On Wed, 14 Dec 2011 10:12:28 +0100 Stephan Kulow wrote:
Over the last couple of days I reworked update-desktop-files not to rely on an explicit %suse_update_desktop_file call. Instead Factory will have an additional brp script that trims the translations from .desktop files.
I have some failed builds with: error: Installed (but unpackaged) file(s) found: /usr/share/applications/program_name.desktop_ -- WBR Kyrill -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 19.12.2011 13:06, Kyrill Detinov wrote:
Monday 19 December 2011
On Wed, 14 Dec 2011 10:12:28 +0100 Stephan Kulow wrote:
Over the last couple of days I reworked update-desktop-files not to rely on an explicit %suse_update_desktop_file call. Instead Factory will have an additional brp script that trims the translations from .desktop files.
I have some failed builds with:
error: Installed (but unpackaged) file(s) found: /usr/share/applications/program_name.desktop_
I fixed that already, but due to the high load on the build service I don't dare to retrigger a mass rebuild. This affects many packages though - all that set a comment,name or the like. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Monday 19 December 2011 16:29:57 Stephan Kulow wrote:
Over the last couple of days I reworked update-desktop-files not to rely on an explicit %suse_update_desktop_file call. Instead Factory will have an additional brp script that trims the translations from .desktop files.
I have some failed builds with:
error: Installed (but unpackaged) file(s) found: /usr/share/applications/program_name.desktop_
I fixed that already, but due to the high load on the build service I don't dare to retrigger a mass rebuild.
This affects many packages though - all that set a comment,name or the like.
Do your changes mean that now on %suse_update_desktop_file macro should not be called at all? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 19.12.2011 17:27, Ilya Chernykh wrote:
On Monday 19 December 2011 16:29:57 Stephan Kulow wrote:
Over the last couple of days I reworked update-desktop-files not to rely on an explicit %suse_update_desktop_file call. Instead Factory will have an additional brp script that trims the translations from .desktop files.
I have some failed builds with:
error: Installed (but unpackaged) file(s) found: /usr/share/applications/program_name.desktop_
I fixed that already, but due to the high load on the build service I don't dare to retrigger a mass rebuild.
This affects many packages though - all that set a comment,name or the like.
Do your changes mean that now on %suse_update_desktop_file macro should not be called at all?
It's pretty much pointless to do so if not used with options, yes. And that's what my mail said Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
participants (6)
-
Guido Berhoerster -
Ilya Chernykh -
Kyrill Detinov -
Pascal Bleser -
Stephan Kulow -
Vincent Untz