Xprint on powerpc
Xprint (package xprint-xprintorg, upstream http://xprint.mozdev.org) is now compiled and uploaded for all architectures. There is a bug report (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=161899repeatmerged=yes) saying char signedness is broken on arm, powerpc, s390. Although the package compiles, apparently this should cause runtime errors. We're not really clear what the problem is though. The bug reporter says the problem is in imake, but the Xprint imake is supposed to be the same as in XFree86. Could someone running these architectures kindly confirm or deny the bug, or add more details? The Xprt server is run automatically via /etc/init.d/xprint when xprt-xprintorg is installed, so it should be sufficient to test the package by running: $ apt-get install xprt-xprintorg xprt-common $ XPSERVERLIST=/etc/init.d/xprint get_xpserverlist xplsprinters xplsprinters should list the printers available on your system (as identified by lpstat), for example If xplsprinters returns the list, then Xprint can be considered to work, I think. I'd love to hear if it does. For any cut'n'pasters who want to contribute to the bug report, the email address for bug #161899 is [EMAIL PROTECTED] Thanks for any help! Drew -- PGP public key available at http://people.debian.org/~dparsons/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A pgpiN142bsgF3.pgp Description: PGP signature
Bug#165899: xlibs-dbg: no unstripped libs for /usr/X11R6/lib/X11/locale/common/*
On Tue, 22 Oct 2002 11:31:14 -0500 [EMAIL PROTECTED] wrote: Would you include such a libraries in the -dbg package? Yes. How does this look? Seems OK for me. As long as everything tests all right, this fix will be in the next release. Thanks. -- MINAMI Hirokazu [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: [desktop] Unix configuration nightmare
On Tue, Oct 22, 2002 at 06:00:48PM -0400, Matt Zimmerman wrote: As I said, I am suggesting we mimick the conffile mechanism. conffiles are not parsed, but their modification is noticed. My proposed system would not prevent the user from using the menu-driven configuration; it would simple offer them a choice about whether to generate a new configuration using the dialogs, or to preserve their existing configuration. This choice would only be necessary if the file had been modified by hand. I think I would probably migrate the XFree86 packages to using this if you implemented it. The more I think about what it would require to completely handle an XF86Config file with Debconf, the less I want to do it. It feels like the wrong direction to be going. Some sections of the file can appear 0, 1 or n times. You'd have to build menus based on the identifiers for various sections and have the user select which one to use. This means I'd be generating questions from templates all over the place, and using the names of debconf questions as values in a select template (this fact could be masked, but it would be happening). It's just grody. I get two kinds of complaints about the debconfization of the X server: 1) I didn't bother to read the top of the config file, or any documentation anywhere, my changes got clobbered, and I'm mad. 2) You don't support this obscure-ass option, and I think you should. With what you propose it would be easier to hew back towards my original intent for the XFree86 debconf templates, which was: Get a working, non-gross, single-headed X configuration going if at all possible so that, with DEBIAN_PRIORITY=high, newbies don't even have to know that there is such a thin as an XFree86 configuration file. I am profoundly disinterested in a full solution. To do it right would be to reinvent xf86cfg, which has to load the driver modules itself to ask them what options they support. That's a horrible thing to be doing in an installation scenario. Especially when the damn package isn't even unpacked yet. Yes, now that I've written this mail, I've pretty much made up my mind. I like your idea. If the user dicks with the autogenerated file, we slam on the brakes and toss him into the manual configuration ghetto where he belongs. His changes are respected and he gets to RTF XF86Config-4(5) page. People have demonstrated to my satisfaction that: ### BEGIN DEBCONF SECTION # XF86Config-4 (XFree86 server configuration file) generated by dexconf, the # Debian X Configuration tool, using values from the debconf database. # # Edit this file with caution, and see the XF86Config-4 manual page. # (Type man XF86Config-4 at the shell prompt.) # # If you want your changes to this file preserved by dexconf, only make changes # before the ### BEGIN DEBCONF SECTION line above, and/or after the # ### END DEBCONF SECTION line below. # # To change things within the debconf section, run the command: # dpkg-reconfigure xserver-xfree86 # as root. Also see How do I add custom sections to a dexconf-generated # XF86Config or XF86Config-4 file? in /usr/share/doc/xfree86-common/FAQ.gz. is just a very long way of saying fnord. People's minds just blot it out and they insist that the text does not exist. They. Will. Not. Read. Matt, I'd be more than happy to use xfree86 in unstable as a testbed for your proposal. If you agree, let's migrate this subthread over to debian-x. -- G. Branden Robinson| Debian GNU/Linux | // // // / / [EMAIL PROTECTED] | EI 'AANIIGOO 'AHOOT'E http://people.debian.org/~branden/ | pgpM0XyJ22EVH.pgp Description: PGP signature
Re: apt-build and xfree86
On Tue, Oct 22, 2002 at 06:29:32PM +0100, James Troup wrote: Branden Robinson [EMAIL PROTECTED] writes: xfree86 4.2.1-4 will B-D on kernel-headers-2.4.19-386 | kernel-headers-2.4 | hurd | freebsd | netbsd | openbsd. This will of course only help Linux/i386 people, but it's better than nothing. FYI that'll break auto-building; sbuild takes the first choice. G. Is that a bug in sbuild and/or should we clearly document this in the Debian Policy Manual? -- G. Branden Robinson| The last Christian died on the Debian GNU/Linux | cross. [EMAIL PROTECTED] | -- Friedrich Nietzsche http://people.debian.org/~branden/ | pgpsQ3c167Il6.pgp Description: PGP signature
Bug#165899: xlibs-dbg: no unstripped libs for /usr/X11R6/lib/X11/locale/common/*
On Wed, Oct 23, 2002 at 10:29:54PM +0900, MINAMI wrote: These changes seems to fix most of leaks I have seen. #Though I don't know why Xfree() is prefered to XFree() Probably because XFree() is an Xlib function. Xfree() is to free() what Xalloc() is to malloc(). -- G. Branden Robinson| It just seems to me that you are Debian GNU/Linux | willfully entering an arse-kicking [EMAIL PROTECTED] | contest with a monstrous entity http://people.debian.org/~branden/ | that has sixteen legs and no arse. pgpQgr6GKlDsM.pgp Description: PGP signature
Re: [desktop] Unix configuration nightmare
On Wed, Oct 23, 2002 at 10:09:58PM +0200, Andreas Metzler wrote: Time for a third opinion: I think your setup circumvents the problem (parsing XF86Config) _very_ nicely with little overhead. It allows me to customize any section I want while still letting debconf handle the rest. Basically I just have to copy it and move it outside of the debconf part. Well, that was the use case I had in mind when I wrote XFree86's debconf support, but judging by the dozens of config files I've seen, that's not the use case in widest deployment. You can tell people to put their shit outside the debconf area, but they won't. They just tilt their heads a little, smile politely at you, and walk straight into the wall, again and again. Make the change you want, but do it over here, please. No. Make the change you want, but do it over here, please. No. Make the change you want, but do it over here, please. No. Make the change you want, but do it over here, please. No. Make the change you want, but do it over here, please. No. Make the change you want, but do it over here, please. No. [repeat until you vomit] Cutting and pasting a block of text is Too Hard. The scenario you enjoy will die, because People Will Not Read. It's also arguably a violation of way Debconf is supposed to work (there's not supposed to be any such thing as a debconf area, and for files that aren't as potentially insanely complex as XF86Config, I agree), so I'm not getting any support from the Orthodox Church of Debconf, either. I may sound bitter, and maybe I am a little, but I know where the fault lies; it lies with me, for misjudging my audience. I didn't think there was anything between the following two points on the user continuuum: * hates and fears text config files and will not touch them * will read and edit a text config file But there is such a third group: * will edit a text config file, but only given very precise and explicit instructions -- will not read manpages, will not read the config file itself, has tunnel vision, will only take action on suggestions like right after the line that says Driver mga in your XFree config file[sic], add a line that says Option WhizzBang and you'll be able to use the special Tomb Raider hack that let you play Lara Croft without any clothes on, and adds lots of mirrors to the level maps So, like I said, it's my fault. I didn't think many such people existed. They do, and because they are numerous it's my responsibility as a Debian package maintainer to accomodate their needs. What you want to do will still be possible, but you'll have to use interdiff or something. An easy thing will be made hard -- or at least tedious -- so that a different easy thing can be made even easier than it was, because even easy was too hard for some people. Thanks for the kind words, though. -- G. Branden Robinson| The software said it required Debian GNU/Linux | Windows 3.1 or better, so I [EMAIL PROTECTED] | installed Linux. http://people.debian.org/~branden/ | pgpTSn5kT5z3P.pgp Description: PGP signature
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.
Configuration file handling (Re: [desktop] Unix configuration nightmare)
On Wed, Oct 23, 2002 at 02:02:12PM -0500, Branden Robinson wrote: Yes, now that I've written this mail, I've pretty much made up my mind. I like your idea. If the user dicks with the autogenerated file, we slam on the brakes and toss him into the manual configuration ghetto where he belongs. His changes are respected and he gets to RTF XF86Config-4(5) page. [...] Matt, I'd be more than happy to use xfree86 in unstable as a testbed for your proposal. If you agree, let's migrate this subthread over to debian-x. OK, let's spec things out a bit, then. I don't think that existing .config handling necessarily needs to change at this point, unless we want to provide a standard way to suppress all attempts at automatic configuration for a particular config file. In other maintainer scripts, we need to be able to say I have generated a configuration file /tmp/blah as a possible replacement for /etc/foo/bar. At that point, the maintainer script is done with the file, and passes control to us. We check again whether the file has been modified since last time by comparing it to a saved copy or checksum (the copy is optional, but gives much more flexibility than storing only a checksum). If it has not been modified, we overwrite the existing config with the new one, and update the saved copy to match. If the generated configuration file is identical to the existing one, then by some miracle, the user has made changes identical to what we would have made, and we update our saved copy of the config file and exit. If the files are different, then we attempt a merge, check whether it was successful, and interact with the user via debconf, explaining the situation and the result of the merge attempt (displaying a diff if the user cares about such things). At the end of the interaction, we should have decided on one of these courses of action: - Throw away the admin's changes to the file and replace it with the new one entirely (conffile 'y') - Ignore the package maintainer's changes to the file and keep the existing one (conffile 'n') - Merge the package maintainer's changes and give the user a chance to fix things up manually before continuing - (this option is only available if the merge was successful) Merge the package maintainer's changes and continue without further interaction In the common cases, this should be possible with a single prompt, though it could be split into two phases or selected from either a simple or advanced method, or even suppressed entirely for novice users if a sane default action sequence could be decided (always preserve? merge, and if that fails, preserve? warn?). At package build time, the source package machinery only needs to indicate which binary packages will be making use of the infrastructure, and a helper will ensure that the necessary templates are included and generate dependency substitutions. Rebuilding a package will automatically pull in the latest, best-translated templates from the helper. Open questions: - What should happen at preconfiguration time to minimize interaction for novice users? - What sort of preferences would be useful, either at a global scope or a per-package scope? always leave my foobar config alone always merge my changes if there are no merge conflicts Implementation issues: - How to store the saved config files, so that it is intuitively obvious to which package they belong, and their installed location, so that they are conveniently available to the admin? This should be a public interface. - Will it be necessary or desirable to modify debhelper so that there is a substitution interface for templates, similar to what is done for maintainer scripts? -- - mdz
Re: apt-build and xfree86
Branden Robinson [EMAIL PROTECTED] writes: xfree86 4.2.1-4 will B-D on kernel-headers-2.4.19-386 | kernel-headers-2.4 | hurd | freebsd | netbsd | openbsd. This will of course only help Linux/i386 people, but it's better than nothing. FYI that'll break auto-building; sbuild takes the first choice. G. Is that a bug in sbuild and/or should we clearly document this in the Debian Policy Manual? Sorry, I should have said; it's a bug in sbuild. -- James
Re: woody : X install
On Wed, Oct 23, 2002 at 07:38:29PM -0400, Colin Walters wrote: 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. Hard. It's difficult to test-launch the X server before it's been unpacked... -- G. Branden Robinson|The first thing the communists do Debian GNU/Linux |when they take over a country is to [EMAIL PROTECTED] |outlaw cockfighting. http://people.debian.org/~branden/ |-- Oklahoma State Senator John Monks pgpBO8sNA1W1h.pgp Description: PGP signature
Re: apt-build and xfree86
On Tue, Oct 22, 2002 at 06:29:32PM +0100, James Troup wrote: Branden Robinson [EMAIL PROTECTED] writes: xfree86 4.2.1-4 will B-D on kernel-headers-2.4.19-386 | kernel-headers-2.4 | hurd | freebsd | netbsd | openbsd. This will of course only help Linux/i386 people, but it's better than nothing. FYI that'll break auto-building; sbuild takes the first choice. G. Is that a bug in sbuild and/or should we clearly document this in the Debian Policy Manual? -- G. Branden Robinson| The last Christian died on the Debian GNU/Linux | cross. [EMAIL PROTECTED] | -- Friedrich Nietzsche http://people.debian.org/~branden/ | msg04213/pgp0.pgp Description: PGP signature
Bug#165899: xlibs-dbg: no unstripped libs for /usr/X11R6/lib/X11/locale/common/*
On Wed, Oct 23, 2002 at 02:13:17AM +0900, ISHIKAWA Mutsumi wrote: Some memory leaks of libX11 was fixed in XFree86 current CVS few days ago. Will the patch solves your problem? 438. Fix some memory leaks in libX11 i18n code (#A.1314, Olivier Chapuis). http://www.xfree86.org/pipermail/xpert/2002-October/021687.html http://www.xfree86.org/pipermail/xpert/2002-October/021893.html Perhaps, it is better to merge this patch to next release (4.2.1-4) of xfree86 debian package. Already done. -- G. Branden Robinson| Human beings rarely imagine a god Debian GNU/Linux | that behaves any better than a [EMAIL PROTECTED] | spoiled child. http://people.debian.org/~branden/ | -- Robert Heinlein msg04214/pgp0.pgp Description: PGP signature
Bug#165899: xlibs-dbg: no unstripped libs for /usr/X11R6/lib/X11/locale/common/*
On Wed, Oct 23, 2002 at 10:29:54PM +0900, MINAMI wrote: These changes seems to fix most of leaks I have seen. #Though I don't know why Xfree() is prefered to XFree() Probably because XFree() is an Xlib function. Xfree() is to free() what Xalloc() is to malloc(). -- G. Branden Robinson| It just seems to me that you are Debian GNU/Linux | willfully entering an arse-kicking [EMAIL PROTECTED] | contest with a monstrous entity http://people.debian.org/~branden/ | that has sixteen legs and no arse. msg04215/pgp0.pgp Description: PGP signature
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]
Configuration file handling (Re: [desktop] Unix configuration nightmare)
On Wed, Oct 23, 2002 at 02:02:12PM -0500, Branden Robinson wrote: Yes, now that I've written this mail, I've pretty much made up my mind. I like your idea. If the user dicks with the autogenerated file, we slam on the brakes and toss him into the manual configuration ghetto where he belongs. His changes are respected and he gets to RTF XF86Config-4(5) page. [...] Matt, I'd be more than happy to use xfree86 in unstable as a testbed for your proposal. If you agree, let's migrate this subthread over to debian-x. OK, let's spec things out a bit, then. I don't think that existing .config handling necessarily needs to change at this point, unless we want to provide a standard way to suppress all attempts at automatic configuration for a particular config file. In other maintainer scripts, we need to be able to say I have generated a configuration file /tmp/blah as a possible replacement for /etc/foo/bar. At that point, the maintainer script is done with the file, and passes control to us. We check again whether the file has been modified since last time by comparing it to a saved copy or checksum (the copy is optional, but gives much more flexibility than storing only a checksum). If it has not been modified, we overwrite the existing config with the new one, and update the saved copy to match. If the generated configuration file is identical to the existing one, then by some miracle, the user has made changes identical to what we would have made, and we update our saved copy of the config file and exit. If the files are different, then we attempt a merge, check whether it was successful, and interact with the user via debconf, explaining the situation and the result of the merge attempt (displaying a diff if the user cares about such things). At the end of the interaction, we should have decided on one of these courses of action: - Throw away the admin's changes to the file and replace it with the new one entirely (conffile 'y') - Ignore the package maintainer's changes to the file and keep the existing one (conffile 'n') - Merge the package maintainer's changes and give the user a chance to fix things up manually before continuing - (this option is only available if the merge was successful) Merge the package maintainer's changes and continue without further interaction In the common cases, this should be possible with a single prompt, though it could be split into two phases or selected from either a simple or advanced method, or even suppressed entirely for novice users if a sane default action sequence could be decided (always preserve? merge, and if that fails, preserve? warn?). At package build time, the source package machinery only needs to indicate which binary packages will be making use of the infrastructure, and a helper will ensure that the necessary templates are included and generate dependency substitutions. Rebuilding a package will automatically pull in the latest, best-translated templates from the helper. Open questions: - What should happen at preconfiguration time to minimize interaction for novice users? - What sort of preferences would be useful, either at a global scope or a per-package scope? always leave my foobar config alone always merge my changes if there are no merge conflicts Implementation issues: - How to store the saved config files, so that it is intuitively obvious to which package they belong, and their installed location, so that they are conveniently available to the admin? This should be a public interface. - Will it be necessary or desirable to modify debhelper so that there is a substitution interface for templates, similar to what is done for maintainer scripts? -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: apt-build and xfree86
Branden Robinson [EMAIL PROTECTED] writes: xfree86 4.2.1-4 will B-D on kernel-headers-2.4.19-386 | kernel-headers-2.4 | hurd | freebsd | netbsd | openbsd. This will of course only help Linux/i386 people, but it's better than nothing. FYI that'll break auto-building; sbuild takes the first choice. G. Is that a bug in sbuild and/or should we clearly document this in the Debian Policy Manual? Sorry, I should have said; it's a bug in sbuild. -- James -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: woody : X install
On Wed, Oct 23, 2002 at 07:38:29PM -0400, Colin Walters wrote: 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. Hard. It's difficult to test-launch the X server before it's been unpacked... -- G. Branden Robinson|The first thing the communists do Debian GNU/Linux |when they take over a country is to [EMAIL PROTECTED] |outlaw cockfighting. http://people.debian.org/~branden/ |-- Oklahoma State Senator John Monks msg04221/pgp0.pgp Description: PGP signature
Xprint on powerpc
Xprint (package xprint-xprintorg, upstream http://xprint.mozdev.org) is now compiled and uploaded for all architectures. There is a bug report (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=161899repeatmerged=yes) saying char signedness is broken on arm, powerpc, s390. Although the package compiles, apparently this should cause runtime errors. We're not really clear what the problem is though. The bug reporter says the problem is in imake, but the Xprint imake is supposed to be the same as in XFree86. Could someone running these architectures kindly confirm or deny the bug, or add more details? The Xprt server is run automatically via /etc/init.d/xprint when xprt-xprintorg is installed, so it should be sufficient to test the package by running: $ apt-get install xprt-xprintorg xprt-common $ XPSERVERLIST=/etc/init.d/xprint get_xpserverlist xplsprinters xplsprinters should list the printers available on your system (as identified by lpstat), for example If xplsprinters returns the list, then Xprint can be considered to work, I think. I'd love to hear if it does. For any cut'n'pasters who want to contribute to the bug report, the email address for bug #161899 is [EMAIL PROTECTED] Thanks for any help! Drew -- PGP public key available at http://people.debian.org/~dparsons/drewskey.txt Fingerprint: A110 EAE1 D7D2 8076 5FE0 EC0A B6CE 7041 6412 4E4A msg04284/pgp0.pgp Description: PGP signature
