fonts
So, up till now fonts in Debian were supposed to be installed via Defoma. Defoma has worked fairly well, but it's Debian-specific, and very complex. Now however we have fontconfig, which is a more generic way for applications to find and use fonts. Besides core components like GNOME, KDE, and Mozilla, other applications like magicpoint are now using it as well. I think we should encourage this. Defoma is not really supported by its maintainer anymore (see #180188), and I think that we should be moving away from using Defoma, and encouraging upstreams to support fontconfig. They are not entirely duplicates really; Defoma as I understand it is just kind of a trigger mechanism, and can help non-fontconfig applications to support a variety of fonts. Now, to the issue at hand: after installing a font package, fc-cache must be rerun. Now, we could continue to use Defoma, and I could have fontconfig install some sort of Defoma trigger to make Defoma rerun fc-cache. But given the above, I would prefer for font packages to just invoke fc-cache directly in their postinst, and also for them to Depend on fontconfig. This should solve #175797. The exact code that packages should use might look something like this: printf "Regenerating fonts cache..." HOME=/root fc-cache -f -v 1>/var/log/fontconfig.log 2>&1 || (printf "failed; see /var/log/fontconfig.log for more information\n"; exit 1) printf "done.\n" Maybe I could put this into a little shell script in the Debian fontconfig package. Comments?
fonts
So, up till now fonts in Debian were supposed to be installed via Defoma. Defoma has worked fairly well, but it's Debian-specific, and very complex. Now however we have fontconfig, which is a more generic way for applications to find and use fonts. Besides core components like GNOME, KDE, and Mozilla, other applications like magicpoint are now using it as well. I think we should encourage this. Defoma is not really supported by its maintainer anymore (see #180188), and I think that we should be moving away from using Defoma, and encouraging upstreams to support fontconfig. They are not entirely duplicates really; Defoma as I understand it is just kind of a trigger mechanism, and can help non-fontconfig applications to support a variety of fonts. Now, to the issue at hand: after installing a font package, fc-cache must be rerun. Now, we could continue to use Defoma, and I could have fontconfig install some sort of Defoma trigger to make Defoma rerun fc-cache. But given the above, I would prefer for font packages to just invoke fc-cache directly in their postinst, and also for them to Depend on fontconfig. This should solve #175797. The exact code that packages should use might look something like this: printf "Regenerating fonts cache..." HOME=/root fc-cache -f -v 1>/var/log/fontconfig.log 2>&1 || (printf "failed; see /var/log/fontconfig.log for more information\n"; exit 1) printf "done.\n" Maybe I could put this into a little shell script in the Debian fontconfig package. Comments? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#172550: please split at least xft1 out of xlibs-dev (needed for libxft2-dev)
Package: xlibs-dev On Tue, 2002-12-10 at 13:15, Branden Robinson wrote: > On Fri, Dec 06, 2002 at 01:44:31AM -0500, Colin Walters wrote: > > reopen 170559 [EMAIL PROTECTED] > > thanks > > > > Branden, I've changed my mind; since I have another package (fontilus) > > which requires fontconfig/xft2, I'd like to go ahead and upload these > > packages to Debian, if you have no objections. Let me know if you do. > > > > It would still be great if you could split xlibs-dev, though. > > Please file a wishlist bug against the xlibs package. The debian-x list > will see this. I'd like to get a discussion rolling about just how much > we should split up xlibs. One package per shlib, plus a package for the > arch-indep data? Something else? Well, it's up to you, really. If you split out just xft1, that would work for me. However, as you said on IRC, if you're going to split it, you might as well split it all the way. That way if anything else comes along later it will be less of a pain. You could still make xlibs-dev a metapackage which depends on all the others, or something. > Feel free to quote this mail when filing your bug. > > To satisfy you, though, all I need to do is split out libXft1, right? Yes, I think that's all I need for right now.
Bug#172550: please split at least xft1 out of xlibs-dev (needed for libxft2-dev)
Package: xlibs-dev On Tue, 2002-12-10 at 13:15, Branden Robinson wrote: > On Fri, Dec 06, 2002 at 01:44:31AM -0500, Colin Walters wrote: > > reopen 170559 [EMAIL PROTECTED] > > thanks > > > > Branden, I've changed my mind; since I have another package (fontilus) > > which requires fontconfig/xft2, I'd like to go ahead and upload these > > packages to Debian, if you have no objections. Let me know if you do. > > > > It would still be great if you could split xlibs-dev, though. > > Please file a wishlist bug against the xlibs package. The debian-x list > will see this. I'd like to get a discussion rolling about just how much > we should split up xlibs. One package per shlib, plus a package for the > arch-indep data? Something else? Well, it's up to you, really. If you split out just xft1, that would work for me. However, as you said on IRC, if you're going to split it, you might as well split it all the way. That way if anything else comes along later it will be less of a pain. You could still make xlibs-dev a metapackage which depends on all the others, or something. > Feel free to quote this mail when filing your bug. > > To satisfy you, though, all I need to do is split out libXft1, right? Yes, I think that's all I need for right now. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xlibs-dev issues and fontconfig/xft2 packages
On Mon, 2002-12-02 at 06:21, Michel Dänzer wrote: > This is kinda late and may be stating the obvious, but there have been > upstream releases of fontconfig: http://fontconfig.org/ . Uploading this > to sid may be a good idea after all? I don't want to do that before Branden splits xlibs-dev. My current packages use dpkg-divert, and this means that any package which Build-Depends on xlibs-dev and uses say xft1, will probably fail to build. In the meantime though I will update those packages in my local apt repository very soon...
Re: xlibs-dev issues and fontconfig/xft2 packages
On Mon, 2002-12-02 at 06:21, Michel Dänzer wrote: > This is kinda late and may be stating the obvious, but there have been > upstream releases of fontconfig: http://fontconfig.org/ . Uploading this > to sid may be a good idea after all? I don't want to do that before Branden splits xlibs-dev. My current packages use dpkg-divert, and this means that any package which Build-Depends on xlibs-dev and uses say xft1, will probably fail to build. In the meantime though I will update those packages in my local apt repository very soon... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: woody : X install
On Wed, 2002-10-23 at 18:01, Branden Robinson wrote: > On Wed, Oct 23, 2002 at 02:52:43PM -0400, Colin Walters wrote: > > Ok, here's the way I see things happening. We use discover and friends > > to populate the debconf database, like you do now in the xserver-xfree86 > > .config script. We only ask the user to confirm at a priority of > > "low". The default for the confirm question is "yes". > > Medium. Things can be autodetected wrongly. "Low" is for things that > can't really be "wrong", just annoying to nitpicky people. Ok, fair enough. > PGI already does something similar to what you describe. I see; how hard would it be to integrate into the main Debian package? I guess my main point here is that it's a solvable problem; I don't think this approach goes against the spirit of Debconf at all. > We long ago solved the looping display manager problem, so it's just as > well to let the display managers fail. They won't tie up the system for > long and they let the display managers start again on a good > configuration even if something is stupid and leaves the > /etc/X11/x-server-unconfigured file around. Ok, right. Yeah, that works well. Cool. We're getting there.
Re: woody : X install
On Wed, 2002-10-23 at 18:01, Branden Robinson wrote: > On Wed, Oct 23, 2002 at 02:52:43PM -0400, Colin Walters wrote: > > Ok, here's the way I see things happening. We use discover and friends > > to populate the debconf database, like you do now in the xserver-xfree86 > > .config script. We only ask the user to confirm at a priority of > > "low". The default for the confirm question is "yes". > > Medium. Things can be autodetected wrongly. "Low" is for things that > can't really be "wrong", just annoying to nitpicky people. Ok, fair enough. > PGI already does something similar to what you describe. I see; how hard would it be to integrate into the main Debian package? I guess my main point here is that it's a solvable problem; I don't think this approach goes against the spirit of Debconf at all. > We long ago solved the looping display manager problem, so it's just as > well to let the display managers fail. They won't tie up the system for > long and they let the display managers start again on a good > configuration even if something is stupid and leaves the > /etc/X11/x-server-unconfigured file around. Ok, right. Yeah, that works well. Cool. We're getting there. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: woody : X install
On Mon, 2002-10-21 at 18:21, Branden Robinson wrote: > On Mon, Oct 21, 2002 at 05:21:00PM -0400, Colin Walters wrote: > > Speaking with my Debian Desktop hat on, I would prefer it if you took > > the approach of just trying what the autodetection tools said, and only > > if that fails, offer the user a choice of options. > > The Debconf spec won't let me do that. If DEBIAN_PRIORITY is "low", I > need to grind to a halt and wait for the user to confirm, e.g., the > usage of the "XFree86" server and "tdfx" driver for his Voodoo3 3000 > card. I am not worried about what happens when the debconf priority is "low". The Debian Desktop will for sure default to at least "high". > > If the autodetection tools give incorrect information, then that's a > > bug in those tools we should fix. If the X server doesn't get enough > > information from the autodetection tools, then we should fix that. > > I agree, but there is simply no way to completely eliminate the > interactivity, *even if* the autodetection tools work perfectly, and > still play the Debconf game. Ok, here's the way I see things happening. We use discover and friends to populate the debconf database, like you do now in the xserver-xfree86 .config script. We only ask the user to confirm at a priority of "low". The default for the confirm question is "yes". After XFree86 is installed, if it succeeds (as we should strive to make sure it does for as many possible setups as we can), then we're all good. Now, if it fails, we touch a file like /etc/X11/x-server-autoconfiguration-failed, and use curses to prompt the user with something like: "The graphics system (X server) failed to start: [ include contents of tail -8 /var/log/XFree86.0.log ] Do you want to rerun the configuration wizard?" If they say yes, we exec "dpkg-reconfigure --plow --priority=low xserver-xfree86". After this, we try to start X again. If it succeeds, we rm /etc/X11/x-server-autoconfiguration-failed, and again we're good. If it fails, then we just give up, inform the user appropriately, and touch a file like /etc/X11/x-server-unconfigured. Login managers like GDM can look for this file, and refuse to start if it exists. If they say no to the "run configuration wizard" question, we just touch that x-server-unconfigured file. > If we want to discuss this more we should move over to debian-x. Ok, I'll subscribe.
Re: woody : X install
On Mon, 2002-10-21 at 18:21, Branden Robinson wrote: > On Mon, Oct 21, 2002 at 05:21:00PM -0400, Colin Walters wrote: > > Speaking with my Debian Desktop hat on, I would prefer it if you took > > the approach of just trying what the autodetection tools said, and only > > if that fails, offer the user a choice of options. > > The Debconf spec won't let me do that. If DEBIAN_PRIORITY is "low", I > need to grind to a halt and wait for the user to confirm, e.g., the > usage of the "XFree86" server and "tdfx" driver for his Voodoo3 3000 > card. I am not worried about what happens when the debconf priority is "low". The Debian Desktop will for sure default to at least "high". > > If the autodetection tools give incorrect information, then that's a > > bug in those tools we should fix. If the X server doesn't get enough > > information from the autodetection tools, then we should fix that. > > I agree, but there is simply no way to completely eliminate the > interactivity, *even if* the autodetection tools work perfectly, and > still play the Debconf game. Ok, here's the way I see things happening. We use discover and friends to populate the debconf database, like you do now in the xserver-xfree86 .config script. We only ask the user to confirm at a priority of "low". The default for the confirm question is "yes". After XFree86 is installed, if it succeeds (as we should strive to make sure it does for as many possible setups as we can), then we're all good. Now, if it fails, we touch a file like /etc/X11/x-server-autoconfiguration-failed, and use curses to prompt the user with something like: "The graphics system (X server) failed to start: [ include contents of tail -8 /var/log/XFree86.0.log ] Do you want to rerun the configuration wizard?" If they say yes, we exec "dpkg-reconfigure --plow --priority=low xserver-xfree86". After this, we try to start X again. If it succeeds, we rm /etc/X11/x-server-autoconfiguration-failed, and again we're good. If it fails, then we just give up, inform the user appropriately, and touch a file like /etc/X11/x-server-unconfigured. Login managers like GDM can look for this file, and refuse to start if it exists. If they say no to the "run configuration wizard" question, we just touch that x-server-unconfigured file. > If we want to discuss this more we should move over to debian-x. Ok, I'll subscribe. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xlibs-dev issues and fontconfig/xft2 packages
On Mon, 2002-10-14 at 15:11, Branden Robinson wrote: > [Please follow-up to both lists; I am not subscribed to > debian-gtk-gnome.] Ditto; I'm not on -x :) > Okay, so that means you won't upload them to unstable, right? Right. > Keith Packard hasn't finished hacking on fontconfig yet; I see important > changes to it in XFree86 CVS almost every day and IMO we should not > push this stuff into unstable until it's seen an upstream release. I agree. But it's useful right now, so I thought I'd make packages available. A lot of people use Debian sid as a development platform. > Yeah, I can do that. I might want to bite the bullet and bust out xft > altogether. I think that makes sense. > Yes, I realize that will mean a rebuild of all packages that have shlib > depends on xlibs for libxft. Poor m68k :)
Re: xlibs-dev issues and fontconfig/xft2 packages
On Mon, 2002-10-14 at 15:11, Branden Robinson wrote: > [Please follow-up to both lists; I am not subscribed to > debian-gtk-gnome.] Ditto; I'm not on -x :) > Okay, so that means you won't upload them to unstable, right? Right. > Keith Packard hasn't finished hacking on fontconfig yet; I see important > changes to it in XFree86 CVS almost every day and IMO we should not > push this stuff into unstable until it's seen an upstream release. I agree. But it's useful right now, so I thought I'd make packages available. A lot of people use Debian sid as a development platform. > Yeah, I can do that. I might want to bite the bullet and bust out xft > altogether. I think that makes sense. > Yes, I realize that will mean a rebuild of all packages that have shlib > depends on xlibs for libxft. Poor m68k :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
xlibs-dev issues and fontconfig/xft2 packages
Hello all, I've created packages of fontconfig and libxft2; these are needed at least for compiling GNOME 2.1. In the future, they're supposed to be part of the XFree distribution, so these packages are only temporary. Note however that my libxft2-dev package will divert parts of xlibs-dev, because the libxft1 and libxft2 headers conflict. I think the best solution to this problem is to split libxft1-dev into its own package from xlibs-dev, and just have it and libxft2 conflict. Branden, could you do that? In the meantime though, you can get them from my "local" repository: deb http://verbum.org/~walters/debian/ local/$(ARCH)/ deb http://verbum.org/~walters/debian/ local/all/ deb-src http://verbum.org/~walters/debian/ local/source/ Have fun! signature.asc Description: This is a digitally signed message part
xlibs-dev issues and fontconfig/xft2 packages
Hello all, I've created packages of fontconfig and libxft2; these are needed at least for compiling GNOME 2.1. In the future, they're supposed to be part of the XFree distribution, so these packages are only temporary. Note however that my libxft2-dev package will divert parts of xlibs-dev, because the libxft1 and libxft2 headers conflict. I think the best solution to this problem is to split libxft1-dev into its own package from xlibs-dev, and just have it and libxft2 conflict. Branden, could you do that? In the meantime though, you can get them from my "local" repository: deb http://verbum.org/~walters/debian/ local/$(ARCH)/ deb http://verbum.org/~walters/debian/ local/all/ deb-src http://verbum.org/~walters/debian/ local/source/ Have fun! signature.asc Description: This is a digitally signed message part
