From: Daniele F. <df...@gm...> - 2007-12-30 13:20:29
|
2007/12/30, Sikon@users... wrote: > Revision: 1876 > + * data/icons/gtkpod.xpm: > + Added XPM icon from Debian (goes to /usr/share/pixmaps). that file is missing from svn make[4]: *** No rule to make target `gtkpod.xpm', needed by `all-am'. Stop. -- Daniele |
From: Sikon <ine...@gm...> - 2007-12-30 13:31:30
|
> 2007/12/30, Sikon@users... wrote: > > Revision: 1876 > > > > + * data/icons/gtkpod.xpm: > > > > + Added XPM icon from Debian (goes to /usr/share/pixmaps). > > that file is missing from svn > > make[4]: *** No rule to make target `gtkpod.xpm', needed by `all-am'.=20 > Stop. =46ixed. |
From: Todd Z. <tm...@po...> - 2007-12-30 15:00:32
|
Sikon wrote: >> 2007/12/30, Sikon@users... wrote: >>> Revision: 1876 >>> >>> + * data/icons/gtkpod.xpm: >>> >>> + Added XPM icon from Debian (goes to /usr/share/pixmaps). >> >> that file is missing from svn >> >> make[4]: *** No rule to make target `gtkpod.xpm', needed by `all-am'.=20 >> Stop. >=20 > Fixed. I'm curious why we want a .xpm that is identical to the 32x32 .png icon. If anything, we could install data/icons/32x32/gtkpod.png in $(datadir)/pixmaps, but I don't know why we should even do that. What am I missing? --=20 Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ If at first you don't succeed, failure may be your style. -- Demotivators (www.despair.com) |
From: Sikon <ine...@gm...> - 2007-12-30 15:58:37
|
> I'm curious why we want a .xpm that is identical to the 32x32 .png > icon. If anything, we could install data/icons/32x32/gtkpod.png in > $(datadir)/pixmaps, but I don't know why we should even do that. What > am I missing? The Debian policy dictates that at least one icon in /usr/share/pixmaps sho= uld=20 be an .xpm. By adding it upstream, we save Debian the trouble=20 |
From: Javier K. <jk...@us...> - 2007-12-30 16:04:53
|
On dom, 2007-12-30 at 21:59 +0600, Sikon wrote: > > I'm curious why we want a .xpm that is identical to the 32x32 .png > > icon. If anything, we could install data/icons/32x32/gtkpod.png in > > $(datadir)/pixmaps, but I don't know why we should even do that. What > > am I missing? >=20 > The Debian policy dictates that at least one icon in /usr/share/pixmaps s= hould=20 > be an .xpm. By adding it upstream, we save Debian the trouble=20 Sorry to chip in, but if that is indeed part of the most recent Debian policy, it doesn't seem to have caught on in practice: $ cat /etc/debian_version=20 lenny/sid $ ls /usr/share/pixmaps/ | grep '\.xpm$' | wc -l 83 $ ls /usr/share/pixmaps/ | grep '\.png$' | wc -l 153 Moreover: $ find /usr/share/pixmaps/ -name '*.xpm' | wc -l 106 $ find /usr/share/pixmaps/ -name '*.png' | wc -l 2025 Cheers, --=20 Javier Kohen <jk...@us...> ICQ: blashyrkh #2361802 Jabber: jk...@ja... |
From: Sikon <ine...@gm...> - 2007-12-30 16:15:16
|
> Sorry to chip in, but if that is indeed part of the most recent Debian > policy, it doesn't seem to have caught on in practice: > > $ cat /etc/debian_version > lenny/sid > > $ ls /usr/share/pixmaps/ | grep '\.xpm$' | wc -l > 83 > $ ls /usr/share/pixmaps/ | grep '\.png$' | wc -l > 153 > > Moreover: > $ find /usr/share/pixmaps/ -name '*.xpm' | wc -l > 106 > $ find /usr/share/pixmaps/ -name '*.png' | wc -l > 2025 > > Cheers, Well, first of all, many programs install PNGs to /usr/share/pixmaps as par= t=20 of their upstream installation. This is fine. And second of all, even if this is not the case for many Debian application= s,=20 it _is_ the case for gtkpod. Debian and Ubuntu currently include an .xpm fi= le=20 in the debian/ directory. Being a package maintainer myself (most recently= =20 for gtkpod 0.99.12 in Ubuntu), I find it very helpful to have packaging=20 deviations included upstream - where they can usually be better maintained,= =20 and which results in a smaller delta in Debian/Ubuntu. |
From: Todd Z. <tm...@po...> - 2007-12-30 22:13:11
|
Sikon wrote: > Well, first of all, many programs install PNGs to /usr/share/pixmaps > as part of their upstream installation. This is fine. As part of better conformance to the freedesktop.org Icon Theme Specification [1], I moved the installation of the gtkpod.png to $(datadir)/icons/ not too long ago. I don't see any good reason why we should move files back to $(datadir)/pixmaps (especially not .xpm files). > And second of all, even if this is not the case for many Debian > applications, it _is_ the case for gtkpod. I'm not sure what you mean is the case for gtkpod. Can you clarify? > Debian and Ubuntu currently include an .xpm file in the debian/ > directory. Being a package maintainer myself (most recently for > gtkpod 0.99.12 in Ubuntu), I find it very helpful to have packaging > deviations included upstream - where they can usually be better > maintained, and which results in a smaller delta in Debian/Ubuntu. While I agree in general, I think that's only useful when the change is something that belongs upstream and benefits all users of the software. Compliance with a Debian specific policy isn't such a case, IMHO. Packaging specific patches do indeed belong in the package, not in the upstream tree. We don't include rpm spec files for rpm based distros, nor an ebuild for gentoo. Not that I think we should. When a distro packager finds something that they think ought to be included upstream, I think it's courteous if they submit those patches to upstream. I've sadly had to chase down actual bug fix patches from a few distro packages (Debian included), and I've wondered why the maintainers of those packages didn't bother to send them to us so that all users could benefit (and so the packager wouldn't have to maintain the patch themselves). So, aside from the Debian Policy, is there a reason to not only include, but install, a .xpm file in $(datadir)/pixmaps? I'd be tempted to remove the .xpm from the fedora packages I maintain, as I think it's useless and outdated cruft. :-) (If I was going to add an xpm as a packager, I'd probably use convert or a similar tool to convert the png to an xpm as part of the package creation process. That way if upstream changed the icon, my xpm would match.) [1] http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest= =2Ehtml --=20 Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Democracy is also a form of worship. It is the worship of Jackals by Jackasses. -- H.L. Mencken |
From: Sikon <ine...@gm...> - 2007-12-31 04:08:41
|
> I'm not sure what you mean is the case for gtkpod. Can you clarify? The Debian/Ubuntu packages for gtkpod include a file named gtkpod-32x32.xpm= in=20 the debian/directory. They ship a modified .desktop file, which=20 changes "Icon=3Dgtkpod" to "Icon=3Dgtkpod-32x32", and this icon is also use= d in=20 debian/menu. > We don't include rpm spec files for rpm based > distros, nor an ebuild for gentoo. Not that I think we should. Nor do we ship a debian/ directory, nor do I think we should. The moment we= =20 added it, Debian or Ubuntu would immediately ask us to remove it. > When a distro packager finds something that they think ought to be > included upstream, I think it's courteous if they submit those patches > to upstream. I've sadly had to chase down actual bug fix patches from > a few distro packages (Debian included), and I've wondered why the > maintainers of those packages didn't bother to send them to us so that > all users could benefit (and so the packager wouldn't have to maintain > the patch themselves). I couldn't agree more. > (If I was going to add an xpm as a packager, I'd probably use convert > or a similar tool to convert the png to an xpm as part of the package > creation process. That way if upstream changed the icon, my xpm would > match.) They generally don't do that. Some maintaners do - the maintainer for my=20 utility qink, for instance, generated all icon sizes from 16x16 to 64x64 wi= th=20 imagemagick (and dropped this practice when I included my own icons for eac= h=20 size upstream). But it's frowned upon. When I did that, I was told that it'= s=20 better to include the converted icon itself:=20 http://revu.ubuntuwire.com/details.py?package=3Dinkblot As I later learned,= =20 it's because other maintainers may want to manually tailor an icon for a=20 specific resolution, which can't be done with auto-generated icons. =46inally, about the reason why Debian includes .xpm files in the first pla= ce.=20 This is done for the Debian menu system:=20 http://www.handhelds.org/~nelson/menu/ch3.html It's a centralized place for= =20 updating menus for WMs/DEs that do not implement the FDO menu specification= =20 (and those that do if the user installs menu-xdg). Apparently, .xpm is used= =20 for maximum compatibility. |
From: Todd Z. <tm...@po...> - 2007-12-31 04:51:10
|
Sikon wrote: >> I'm not sure what you mean is the case for gtkpod. Can you >> clarify? >=20 > The Debian/Ubuntu packages for gtkpod include a file named > gtkpod-32x32.xpm in the debian/directory. They ship a modified > .desktop file, which changes "Icon=3Dgtkpod" to "Icon=3Dgtkpod-32x32", > and this icon is also used in debian/menu. M'oh. So they must deviate from upstream desktops like Gnome and KDE significantly when it comes to menus? I can understand that to some extent, but I do think it is one place where they should carry such things as patches. Hopefully the desktop environments that don't support the FDO menu and icon specs will eventually gain that support. Then distros can drop their own menu systems and not have to patch upstream sources.=20 I'm all for encouraging that change by implementing the FDO spec and not using the older $(datadir)/pixmaps location. Perhaps I'm not being reasonable enough toward users of older desktop environments and distro packagers with that view though? >> We don't include rpm spec files for rpm based distros, nor an >> ebuild for gentoo. Not that I think we should. >=20 > Nor do we ship a debian/ directory, nor do I think we should. The > moment we added it, Debian or Ubuntu would immediately ask us to > remove it. Yeah, I figured my analogy was off in that way, as a spec file is more like the debian/ dir than just adding an xpm is. :) > They generally don't do that. Some maintaners do - the maintainer > for my utility qink, for instance, generated all icon sizes from > 16x16 to 64x64 with imagemagick (and dropped this practice when I > included my own icons for each size upstream). But it's frowned > upon. When I did that, I was told that it's better to include the > converted icon itself: > http://revu.ubuntuwire.com/details.py?package=3Dinkblot As I later > learned, it's because other maintainers may want to manually tailor > an icon for a specific resolution, which can't be done with > auto-generated icons. And because it makes the build depend on ImageMagick, which is understandable. > Finally, about the reason why Debian includes .xpm files in the > first place. This is done for the Debian menu system: > http://www.handhelds.org/~nelson/menu/ch3.html It's a centralized > place for updating menus for WMs/DEs that do not implement the FDO > menu specification (and those that do if the user installs > menu-xdg). Apparently, .xpm is used for maximum compatibility. Ahh, thanks for the link. I do empathize with the need for such menu fun. I just think it is one area where distro specific patches are probably more appropriate. Say Mandriva or some other distro has an alternate menu system that requires use of some other size images or another install dir, we don't want to have to add that to our Makefiles and SVN too. It seems better to make sure we keep in contact with various distro packagers and integrate any patches they have that will benefit all gtkpod users (distros and individuals building from source). Then, they will only ever have to maintain the few patches that are specific to their distro. :) For instance, we could easily have added the manpage from Debian to the gtkpod source long ago and then the debian maintainers wouldn't have had to manually patch it and fix the patch anytime we moved things around or tweaked the Makefiles. Many thanks for incorporating that! --=20 Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ It is easier to destroy an atomic nucleus than a prejudice. -- Albert Einstein (1879-1955) |
From: Sikon <ine...@gm...> - 2007-12-31 06:27:09
|
So, what would be your final verdict? Install the xpm, leave it in the sour= ce=20 tree but don't install (so that debian can install it themselves), or remov= e=20 altogether? |
From: Jorg S. <jor...@gm...> - 2008-01-01 04:04:16
|
> So, what would be your final verdict? Install the xpm, leave it in the > source > tree but don't install (so that debian can install it themselves), or > remove > altogether? If the xpm is required only or mainly by debian, I'd leave it out. It means additional effort for us to maintain two identical icons. JCS. -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger?did=10 |