Re: discover, read-edid, mdetect selection in base-config
Joey Hess wrote: Chris Halls wrote: How about an additional package instead, e.g. xserver-xfree86-autodetect, that pre-depends on the detection packages and depends on xserver-xfree86? Architectures that don't support autodetection can omit the packages from the dependencies of xserver-xfree86-autodetect for that arch. And the base install can select that package instead. If X is doing the autodetection when debconf runs its config script, this actually wouldn't help at all, as the config script would still run before the detection programs were available. Could the config script do a check to see whether xserver-xfree86-autodetect is *going to be* installed? Debconf obviously has to have that knowledge (in case that package has its own debconf template) - can the xserver-xfree86 config script access that information? If so, it could just refuse to do anything (ie leave all questions unanswered) if that's the case. Then when it comes to package install time, the debconf script will run again, and by that time the predependencies will be installed. You lose the all-questions-asked-at-onceness, but other than that I think it could work? Stuart. -- Stuart Ballard, Programmer NetReach - Internet Solutions (215) 283-2300, ext. 126 http://www.netreach.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: discover, read-edid, mdetect selection in base-config
Joey Hess wrote: > Chris Halls wrote: > >>How about an additional package instead, e.g. xserver-xfree86-autodetect, >>that pre-depends on the detection packages and depends on xserver-xfree86? >>Architectures that don't support autodetection can omit the packages from >>the dependencies of xserver-xfree86-autodetect for that arch. And the base >>install can select that package instead. > > > If X is doing the autodetection when debconf runs its config script, > this actually wouldn't help at all, as the config script would still run > before the detection programs were available. Could the config script do a check to see whether xserver-xfree86-autodetect is *going to be* installed? Debconf obviously has to have that knowledge (in case that package has its own debconf template) - can the xserver-xfree86 config script access that information? If so, it could just refuse to do anything (ie leave all questions unanswered) if that's the case. Then when it comes to package install time, the debconf script will run again, and by that time the predependencies will be installed. You lose the all-questions-asked-at-onceness, but other than that I think it could work? Stuart. -- Stuart Ballard, Programmer NetReach - Internet Solutions (215) 283-2300, ext. 126 http://www.netreach.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kdm/wdm and ~/.xsession
Branden Robinson wrote:
gdm ignores it, too.
I went to all this trouble to make session management nice for the
various and sundry desktops in Debian, and then all the other display
managers force people into the corresponding desktop environment at
gunpoint ("because that's what upstream does").
I use gdm and last time I tried it worked fine if you select "Debian"
from the "Session" menu in gdm. Sucks that it's not the default, but it
isn't exactly "at gunpoint", at least.
I can't speak for any of the others, and I'm just a user anyway.
Stuart.
--
Stuart Ballard, Programmer
NetReach - Internet Solutions
(215) 283-2300, ext. 126
http://www.netreach.com/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kdm/wdm and ~/.xsession
Branden Robinson wrote:
> gdm ignores it, too.
>
> I went to all this trouble to make session management nice for the
> various and sundry desktops in Debian, and then all the other display
> managers force people into the corresponding desktop environment at
> gunpoint ("because that's what upstream does").
I use gdm and last time I tried it worked fine if you select "Debian"
from the "Session" menu in gdm. Sucks that it's not the default, but it
isn't exactly "at gunpoint", at least.
I can't speak for any of the others, and I'm just a user anyway.
Stuart.
--
Stuart Ballard, Programmer
NetReach - Internet Solutions
(215) 283-2300, ext. 126
http://www.netreach.com/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: locale[s]/LANG broken in unstable
Heitzso wrote: > > I run debian unstable and this morning, after updating, noticed that > 'man' complained about a bad LANG or LC_ setting. > > My LANG was set to 'english' and LC_CTYPE was set, > but set to blank or nothing, i.e. 'set' showed it but nothing > was after the equals sign. I had a similar problem and it turned out to be gdm's fault: A previous version had for some reason set "english" as the default value for LANG (which to my knowledge is not a legal value, but I don't really know). If you use gdm, use the language dropdown from gdm to set "POSIX/C english" as the default, and see if that fixes your problem. If you don't use gdm, I can't help you. It took me ages to find it also. (This should probably be reported as a bug in the gdm package, but I've never gotten around to looking for it. It should probably check whether it's about to use a completely invalid value for LANG, and if so specifically ask you what language...) Stuart.
Re: locale[s]/LANG broken in unstable
Heitzso wrote: > > I run debian unstable and this morning, after updating, noticed that > 'man' complained about a bad LANG or LC_ setting. > > My LANG was set to 'english' and LC_CTYPE was set, > but set to blank or nothing, i.e. 'set' showed it but nothing > was after the equals sign. I had a similar problem and it turned out to be gdm's fault: A previous version had for some reason set "english" as the default value for LANG (which to my knowledge is not a legal value, but I don't really know). If you use gdm, use the language dropdown from gdm to set "POSIX/C english" as the default, and see if that fixes your problem. If you don't use gdm, I can't help you. It took me ages to find it also. (This should probably be reported as a bug in the gdm package, but I've never gotten around to looking for it. It should probably check whether it's about to use a completely invalid value for LANG, and if so specifically ask you what language...) Stuart. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Horizontal timing out of range (was Re: Bug in Xgalaga?)
[added the list back to the cc's of this because it's now a general question about Xfree86, rather than a specific question about your message. I hope you (Juliusz) don't mind - none of the content of your reply seemed particularly private] Juliusz Chroboczek wrote: > > Stuart Ballard wrote: > > > How do you do this? With 4.0.[23] and the savage driver, the 1600x1200 > > modeline that I used to use with great success on 3.3.x now fails with > > "hsync out of range". > > That's different. It simply means that your modeline requests an > hsync value (not a dot clock!) that your Monitor entry claims not to > support. Oops - seems I misremembered the error message. This is what it actually says: (WW) SAVAGE(0): Mode "1600x1200" deleted (horizontal timing out of range) Is that the same problem, or a different one? > No, most probably you're using a different Monitor entry than you used > to in 3.*. This is the XF86Config-4 version of my Monitor section. I just checked and the old XF86Config from v3 was identical except for a lot of comments and different identifier strings. Section "Monitor" Identifier "Monitor0" VendorName "Monitor Vendor" ModelName"Monitor Model" HorizSync30-117 VertRefresh 50-160 Option "DPMS" Modeline "1600x1200" 162 1600 1664 1856 2160 1200 1201 1204 1250 +HSync +VSync EndSection (minus the obvious wordwrapping of the modeline done by my mail client) (Actually, my *current* Xf86-4 has vertrefresh 50-70 for other reasons, but this doesn't change the error message for the 1600x1200 modeline) Thanks again for your help! Stuart.
Horizontal timing out of range (was Re: Bug in Xgalaga?)
[added the list back to the cc's of this because it's now a general question about Xfree86, rather than a specific question about your message. I hope you (Juliusz) don't mind - none of the content of your reply seemed particularly private] Juliusz Chroboczek wrote: > > Stuart Ballard wrote: > > > How do you do this? With 4.0.[23] and the savage driver, the 1600x1200 > > modeline that I used to use with great success on 3.3.x now fails with > > "hsync out of range". > > That's different. It simply means that your modeline requests an > hsync value (not a dot clock!) that your Monitor entry claims not to > support. Oops - seems I misremembered the error message. This is what it actually says: (WW) SAVAGE(0): Mode "1600x1200" deleted (horizontal timing out of range) Is that the same problem, or a different one? > No, most probably you're using a different Monitor entry than you used > to in 3.*. This is the XF86Config-4 version of my Monitor section. I just checked and the old XF86Config from v3 was identical except for a lot of comments and different identifier strings. Section "Monitor" Identifier "Monitor0" VendorName "Monitor Vendor" ModelName"Monitor Model" HorizSync30-117 VertRefresh 50-160 Option "DPMS" Modeline "1600x1200" 162 1600 1664 1856 2160 1200 1201 1204 1250 +HSync +VSync EndSection (minus the obvious wordwrapping of the modeline done by my mail client) (Actually, my *current* Xf86-4 has vertrefresh 50-70 for other reasons, but this doesn't change the error message for the 1600x1200 modeline) Thanks again for your help! Stuart. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DFSG and fonts
Branden Robinson wrote: > > Underlying the DFSG is the notion that these are important values. Debian > does not insist that everyone else in the world share them, or prioritize > them as highly as we do. They are, however, very high priorities for our > Project. Speaking of DFSG-free fonts, I hear there is a set of GPL'd TrueType fonts in the OpenOffice distribution. (I also hear that their hinting has problems due to the particular software they were created with, but that's an aside - the license guarantees that someone somewhere can fix them). My question is - has anyone packaged or thought about packaging these fonts for Debian? I'm currently using MS's fonts (the truetype.tar.gz provided by Keith Packard on his render page) and although the license is much closer to free than I would have expected from MS, it's still far from the DFSG, and that leaves a bad taste in my mouth. Those fonts are one of only about 4 non-dfsg programs on my computer (the others being netscape, java, and oracle). I'd love to be able to dump the truetype.tar.gz fonts in favor of installing xfonts-openoffice :) Stuart.
Re: DFSG and fonts
Branden Robinson wrote: > > Underlying the DFSG is the notion that these are important values. Debian > does not insist that everyone else in the world share them, or prioritize > them as highly as we do. They are, however, very high priorities for our > Project. Speaking of DFSG-free fonts, I hear there is a set of GPL'd TrueType fonts in the OpenOffice distribution. (I also hear that their hinting has problems due to the particular software they were created with, but that's an aside - the license guarantees that someone somewhere can fix them). My question is - has anyone packaged or thought about packaging these fonts for Debian? I'm currently using MS's fonts (the truetype.tar.gz provided by Keith Packard on his render page) and although the license is much closer to free than I would have expected from MS, it's still far from the DFSG, and that leaves a bad taste in my mouth. Those fonts are one of only about 4 non-dfsg programs on my computer (the others being netscape, java, and oracle). I'd love to be able to dump the truetype.tar.gz fonts in favor of installing xfonts-openoffice :) Stuart. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: new aptable cvs dri fails with mga
"Thomas E. Vaughan" wrote: > > Maybe I failed to do something that I was supposed to do, but dri is > disabled for me. > > DRM version = 2.0.1, expected 3.0.x > DRI disabled. What kernel are you using? Sounds like you have outdated drm modules in your kernel. Zephaniah's previous message claims that 2.4.2 has adequate modules. If you are using an older kernel, you may need to build the drm modules yourself or upgrade your kernel. If you are using 2.4.2... perhaps the packages actually do need to include the drm modules. Stuart.
Re: new aptable cvs dri fails with mga
"Thomas E. Vaughan" wrote: > > Maybe I failed to do something that I was supposed to do, but dri is > disabled for me. > > DRM version = 2.0.1, expected 3.0.x > DRI disabled. What kernel are you using? Sounds like you have outdated drm modules in your kernel. Zephaniah's previous message claims that 2.4.2 has adequate modules. If you are using an older kernel, you may need to build the drm modules yourself or upgrade your kernel. If you are using 2.4.2... perhaps the packages actually do need to include the drm modules. Stuart. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Text corruption on S3 Savage under 4.0.99.1
Posting on the offchance that this will sound familiar to someone, perhaps someone else who compiled 4.0.99.1... Using 4.0.99.1 on my Matrox card works fine, but when I install the same debs on my S3 Savage4 chipset at work (4.0.2 won't let me use 1600x1200) I do indeed get 1600x1200, but all the text on the screen that should be black shows up in blue and totally garbled. I didn't get past logging in through gdm so I don't know whether this is the case for all apps or just gdm. It looks like random sections of random letters have been put on top of each other in all the wrong places. Anyone ever seen or heard of something like this? Thanks, Stuart.
Text corruption on S3 Savage under 4.0.99.1
Posting on the offchance that this will sound familiar to someone, perhaps someone else who compiled 4.0.99.1... Using 4.0.99.1 on my Matrox card works fine, but when I install the same debs on my S3 Savage4 chipset at work (4.0.2 won't let me use 1600x1200) I do indeed get 1600x1200, but all the text on the screen that should be black shows up in blue and totally garbled. I didn't get past logging in through gdm so I don't know whether this is the case for all apps or just gdm. It looks like random sections of random letters have been put on top of each other in all the wrong places. Anyone ever seen or heard of something like this? Thanks, Stuart. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: manifest problems on ARM
Philip Blundell wrote: > > I ran a build of xfree86-4.0.2-7 on ARM. Aside from needing one small patch > to elf.h (attached) the compilation went OK, but the manifest check failed. I > don't know enough about what goes on here to say whether the manifest is just > wrong or outdated, or whether something bad happened. I can't tell you either, but you may be able to get some useful information by diffing the MANIFEST.arm.new against MANIFEST.arm. This will tell you what files were unexpectedly present or unexpectedly missing. (.arm is what was expected, .arm.new is what was actually produced by your build). If you want to just get past this stage of the build process and not worry about it (or if the differences seem harmless) you can copy MANIFEST.arm.new to MANIFEST.arm and make the corresponding changes in the *.files (or *.files.arm) files; you will then be able to complete the build. (I'm assuming that the arch string for ARM is arm - make the obvious changes if it's not) Hope this helps, and sorry if the above is obvious... Stuart.
Re: manifest problems on ARM
Philip Blundell wrote: > > I ran a build of xfree86-4.0.2-7 on ARM. Aside from needing one small patch > to elf.h (attached) the compilation went OK, but the manifest check failed. I > don't know enough about what goes on here to say whether the manifest is just > wrong or outdated, or whether something bad happened. I can't tell you either, but you may be able to get some useful information by diffing the MANIFEST.arm.new against MANIFEST.arm. This will tell you what files were unexpectedly present or unexpectedly missing. (.arm is what was expected, .arm.new is what was actually produced by your build). If you want to just get past this stage of the build process and not worry about it (or if the differences seem harmless) you can copy MANIFEST.arm.new to MANIFEST.arm and make the corresponding changes in the *.files (or *.files.arm) files; you will then be able to complete the build. (I'm assuming that the arch string for ARM is arm - make the obvious changes if it's not) Hope this helps, and sorry if the above is obvious... Stuart. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-reconfigure xserver-xfree86 doesn't create XF86Config
Geordie Birch wrote: > > on a fresh install of unstable i am having trouble creating an XF86Config. > it doesn't get created when xserver-xfree86 is installed, and > dpkg-reconfigure xserver-xfree86 doesn't create it either. Try "apt-get install task-x-window-system-core". For some reason that debconf page seems to involve the interaction of several packages, and you need all of them for it to work right. Good luck! Stuart.
Re: dpkg-reconfigure xserver-xfree86 doesn't create XF86Config
Geordie Birch wrote: > > on a fresh install of unstable i am having trouble creating an XF86Config. > it doesn't get created when xserver-xfree86 is installed, and > dpkg-reconfigure xserver-xfree86 doesn't create it either. Try "apt-get install task-x-window-system-core". For some reason that debconf page seems to involve the interaction of several packages, and you need all of them for it to work right. Good luck! Stuart. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DRI with Matrox G450 in X4.0.99.1
Michel Dänzer wrote: > > Stuart Ballard wrote: > > The latter. Go to xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel > and run 'make -f Makefile.linux'. Excellent answer, and much appreciated. However, I think I'm ignorant or stupid or something... after running that command, what is the corresponding install step? "make -f Makefile.linux install" gives a "no rule" error. From the documentation I get the impression I need to move some .o files to /lib/modules/2.4.2/kernel/driver/char/drm/, but there are a lot of .o files there and I'm not sure which are relevant. Sorry to be stupid, but what's my next move? Thanks, Stuart.
Re: DRI with Matrox G450 in X4.0.99.1
"Charl P. Botha" wrote: > > Why can't you just use 4.0.2 with the drivers which are available at > http://www.matrox.com/mga/support/drivers/files/linux_05.cfm. I'm afraid > the closest I have is a G400 running with 4.0.2, but as far as I understand > from the aforementioned web page, your G450 should just work in 4.0.2 with > those drivers. What am I missing? Nothing, really. I'm just reluctant to give in and use proprietary drivers, especially as I bought the Matrox card specifically because it seemed to have the best open source support. Unfortunately I only looked at the brand, rather than the specific model... If I wanted proprietary drivers I would have bought an NVidia card. If I can't figure anything out soon, though, I'll probably just give in and use those. Stuart.
DRI with Matrox G450 in X4.0.99.1
As anyone following the "BYOX" thread will be aware, I've just successfully built xserver debs for XFree 4.0.99.1. I had two reasons for wanting to do this: firstly I wanted G450 support without having to use FBDev, and secondly because I hoped it might be possible to get 3D acceleration. The first goal was a success - I'm running now without FBDev and everything is working great. The second remains elusive. I'm running kernel 2.4.2 with AGP support enabled and Matrox AGP support as a module, along with my 4.0.99.1 xserver debs. The relevant line in my X server output seems to be the following: (EE) MGA(0): [drm] MGADRIScreenInit failed (DRM version = 2.0.1, expected 2.1.x). Disabling DRI. Does this mean I don't have a high enough version of DRM in my kernel, even though 2.4.2 is practically bleeding edge? (I checked Alan's changelogs and I don't see any mention of updated DRI even in the latest 2.4.2ac series kernels). If so, how do I correct this? Do I need to compile DRI from cvs? Or is it somewhere in the XFree tree that I already downloaded, and I just have to do some magic to add it into my kernel? Is anyone else running newer versions of X than 4.0.2 and having this issue? Any ideas what I can do? Thanks in advance, Stuart.
Re: BYOX - successfully built 4.0.99.1 debs
The following process works (after a very long build process) to get xfree86 4.0.99.1 debs. They seem to work (I'm running with xserver-xfree86 and xserver-common from these now) but I make absolutely no claims as to quality. I did all of this as root, which is naughty but it worked. # apt-get build-dep xserver-xfree86 (I got 4.0.2-7) # apt-get source xserver-xfree86 # cvs -r xf-4_0_99_1 co xc # tar zcvf xfree86-4.0.99.1.tar.gz xc # cd xfree86-4.0.2 # mv upstream/archives/xfree*.tar.gz .. # mv debian/patches/400_alpha_support.diff .. (do the same for a bunch of other patches - basically all the ones that fail when you run the "debian/rules binary" line below. You can just repeat that step after moving each failed patch out of the way...) # mv ../xfree86-4.0.99.1.tar.gz upstream/archives # vi debian/changelog (add a new line for 4.0.99.1-0local1 by myself) # debian/rules binary (binary-server seems to fail because it doesn't build libXext but it does try to link against it. This could be a bug or a side-effect of the fact that I'm building an unreleased source) This build fails with a manifest error, which can be resolved by copying MANIFEST.i386.new to MANIFEST.i386. Backup MANIFEST.i386 first though, because you need to diff it and modify a few of the .files files to account for changed names. Do a diff -u and look for lines beginning with "-". With a bit of guesswork and grepping it's easy to identify which package each of those should have been in; change the relevant xxx.files or xxx.files.i386 file as appropriate. re-run debian/rules binary and you should get working packages (at least, xserver-common and xserver-xfree86 are working for me right now). Anyone who is interested in the resulting debs, please send me email. I don't have any convenient webspace to throw it onto. Thanks Stuart.
Re: DRI with Matrox G450 in X4.0.99.1
Michel Dänzer wrote: > > Stuart Ballard wrote: > > The latter. Go to xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel > and run 'make -f Makefile.linux'. Excellent answer, and much appreciated. However, I think I'm ignorant or stupid or something... after running that command, what is the corresponding install step? "make -f Makefile.linux install" gives a "no rule" error. From the documentation I get the impression I need to move some .o files to /lib/modules/2.4.2/kernel/driver/char/drm/, but there are a lot of .o files there and I'm not sure which are relevant. Sorry to be stupid, but what's my next move? Thanks, Stuart. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DRI with Matrox G450 in X4.0.99.1
"Charl P. Botha" wrote: > > Why can't you just use 4.0.2 with the drivers which are available at > http://www.matrox.com/mga/support/drivers/files/linux_05.cfm. I'm afraid > the closest I have is a G400 running with 4.0.2, but as far as I understand > from the aforementioned web page, your G450 should just work in 4.0.2 with > those drivers. What am I missing? Nothing, really. I'm just reluctant to give in and use proprietary drivers, especially as I bought the Matrox card specifically because it seemed to have the best open source support. Unfortunately I only looked at the brand, rather than the specific model... If I wanted proprietary drivers I would have bought an NVidia card. If I can't figure anything out soon, though, I'll probably just give in and use those. Stuart. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
DRI with Matrox G450 in X4.0.99.1
As anyone following the "BYOX" thread will be aware, I've just successfully built xserver debs for XFree 4.0.99.1. I had two reasons for wanting to do this: firstly I wanted G450 support without having to use FBDev, and secondly because I hoped it might be possible to get 3D acceleration. The first goal was a success - I'm running now without FBDev and everything is working great. The second remains elusive. I'm running kernel 2.4.2 with AGP support enabled and Matrox AGP support as a module, along with my 4.0.99.1 xserver debs. The relevant line in my X server output seems to be the following: (EE) MGA(0): [drm] MGADRIScreenInit failed (DRM version = 2.0.1, expected 2.1.x). Disabling DRI. Does this mean I don't have a high enough version of DRM in my kernel, even though 2.4.2 is practically bleeding edge? (I checked Alan's changelogs and I don't see any mention of updated DRI even in the latest 2.4.2ac series kernels). If so, how do I correct this? Do I need to compile DRI from cvs? Or is it somewhere in the XFree tree that I already downloaded, and I just have to do some magic to add it into my kernel? Is anyone else running newer versions of X than 4.0.2 and having this issue? Any ideas what I can do? Thanks in advance, Stuart. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: BYOX - successfully built 4.0.99.1 debs
The following process works (after a very long build process) to get xfree86 4.0.99.1 debs. They seem to work (I'm running with xserver-xfree86 and xserver-common from these now) but I make absolutely no claims as to quality. I did all of this as root, which is naughty but it worked. # apt-get build-dep xserver-xfree86 (I got 4.0.2-7) # apt-get source xserver-xfree86 # cvs -r xf-4_0_99_1 co xc # tar zcvf xfree86-4.0.99.1.tar.gz xc # cd xfree86-4.0.2 # mv upstream/archives/xfree*.tar.gz .. # mv debian/patches/400_alpha_support.diff .. (do the same for a bunch of other patches - basically all the ones that fail when you run the "debian/rules binary" line below. You can just repeat that step after moving each failed patch out of the way...) # mv ../xfree86-4.0.99.1.tar.gz upstream/archives # vi debian/changelog (add a new line for 4.0.99.1-0local1 by myself) # debian/rules binary (binary-server seems to fail because it doesn't build libXext but it does try to link against it. This could be a bug or a side-effect of the fact that I'm building an unreleased source) This build fails with a manifest error, which can be resolved by copying MANIFEST.i386.new to MANIFEST.i386. Backup MANIFEST.i386 first though, because you need to diff it and modify a few of the .files files to account for changed names. Do a diff -u and look for lines beginning with "-". With a bit of guesswork and grepping it's easy to identify which package each of those should have been in; change the relevant xxx.files or xxx.files.i386 file as appropriate. re-run debian/rules binary and you should get working packages (at least, xserver-common and xserver-xfree86 are working for me right now). Anyone who is interested in the resulting debs, please send me email. I don't have any convenient webspace to throw it onto. Thanks Stuart. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: BYOX (Build Your Own X) - again
Stuart Ballard wrote: > > What I did was as follows (from memory - I may have a filename or two > wrong, as I'm not at the relevant machine right now. Later this evening > I can post a full log): > > # apt-get build-dep xserver-xfree86 > # apt-get source xserver-xfree86 > # cvs -r xf-4_0_99_1 co xc > # tar zcvf xfree86-4.0.99.1.tar.gz xc > # cd xfree86-4.0.2 > # mv upstream/archives/xfree*.tar.gz .. (new step here - this patch fails to apply cleanly) # mv debian/patches/400_alpha_support.diff .. > # mv ../xfree86-4.0.99.1.tar.gz upstream/archives > # vi debian/scripts/patch.apply > (comment out the "exit 1" line - some patches are bound to fail with a > new version of the upstream source) > # vi debian/changelog > (add a new line for 4.0.99.1-0local1 by myself) > # debian/rules binary-xserver > (because I only care about the server) The build now proceeds for quite a while and eventually dies with an error about not being able to find -lXext. I notice that libXext is in the xlibs and xlibs-dev packages, which presumably are built from the same source tree as I'm working with now, so I shouldn't need to have them installed. Any tips on what I'm doing wrong? Do I need the xlibs/xlibs-dev packages installed anyway? (I can post a full log, but not from the computer I'm at now... I'll do this later if it would be helpful) > (btw, the 4.0.2 packages I'm working with are the latest as of > yesterday, which were 4.0.2-7. All of this was done as root, which I > know isn't ideal but I'm concerned about getting it *working* first). Thanks for any advice, Stuart.
Re: BYOX (Build Your Own X) - again
Stuart Ballard wrote: > > What I did was as follows (from memory - I may have a filename or two > wrong, as I'm not at the relevant machine right now. Later this evening > I can post a full log): > > # apt-get build-dep xserver-xfree86 > # apt-get source xserver-xfree86 > # cvs -r xf-4_0_99_1 co xc > # tar zcvf xfree86-4.0.99.1.tar.gz xc > # cd xfree86-4.0.2 > # mv upstream/archives/xfree*.tar.gz .. (new step here - this patch fails to apply cleanly) # mv debian/patches/400_alpha_support.diff .. > # mv ../xfree86-4.0.99.1.tar.gz upstream/archives > # vi debian/scripts/patch.apply > (comment out the "exit 1" line - some patches are bound to fail with a > new version of the upstream source) > # vi debian/changelog > (add a new line for 4.0.99.1-0local1 by myself) > # debian/rules binary-xserver > (because I only care about the server) The build now proceeds for quite a while and eventually dies with an error about not being able to find -lXext. I notice that libXext is in the xlibs and xlibs-dev packages, which presumably are built from the same source tree as I'm working with now, so I shouldn't need to have them installed. Any tips on what I'm doing wrong? Do I need the xlibs/xlibs-dev packages installed anyway? (I can post a full log, but not from the computer I'm at now... I'll do this later if it would be helpful) > (btw, the 4.0.2 packages I'm working with are the latest as of > yesterday, which were 4.0.2-7. All of this was done as root, which I > know isn't ideal but I'm concerned about getting it *working* first). Thanks for any advice, Stuart. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: BYOX (Build Your Own X) - again
Gordon Sadler wrote: > > On Tue, Feb 27, 2001 at 04:34:50PM -0500, Stuart Ballard wrote: > > The build works for a while (a bunch of patches fail, but some of them > > succeed, and it gets into the build part of the process), but fails when > > trying to run (I think): > > bison -y -d pswparser.y > > The error message indicates it's looking for a file called bison.simple > > in /usr/share somewhere. The file really doesn't exist. I have the > > latest version of bison from unstable installed, and apt-cache search > > bison yielded no obvious candidates. > > > > That's where I get stuck. Any ideas, anyone? > > Check bison from today 27 Feb 01, changelog mentions bison.simple > missing from a previous upload. D'oh! Thanks for the tip. Stuart.
Re: BYOX (Build Your Own X) - again
"Charl P. Botha" wrote: > > On Tue, Feb 27, 2001 at 04:34:50PM -0500, Stuart Ballard wrote: > > I've just joined this list, but I see a few times in the archives that > > people have tried to build their own X debs. These threads seem to peter > > out without any resolution most of the time. > > Oh? They peter out do they? I seem to recall howtos being posted > _regularly_ on this issue. Sorry, I should have been clearer. There are regular howtos on how to build the 4.0.2 packages, both on potato and on unstable, but I haven't seen anything (and admittedly I only checked the Jan and Feb archives) on how to build debs for as-yet-unreleased versions (eg 4.0.99.1 or the CVS trunk), despite a couple of threads in which people expressed interest in it. Anyway, I got past the bison issue - my problem now is to do with certain patches which partially applied (especially 400_alpha_support) and caused the source code to get screwy. I'm now working on a build without that patch, to see if that works... Stuart.
Re: BYOX (Build Your Own X) - again
Gordon Sadler wrote: > > On Tue, Feb 27, 2001 at 04:34:50PM -0500, Stuart Ballard wrote: > > The build works for a while (a bunch of patches fail, but some of them > > succeed, and it gets into the build part of the process), but fails when > > trying to run (I think): > > bison -y -d pswparser.y > > The error message indicates it's looking for a file called bison.simple > > in /usr/share somewhere. The file really doesn't exist. I have the > > latest version of bison from unstable installed, and apt-cache search > > bison yielded no obvious candidates. > > > > That's where I get stuck. Any ideas, anyone? > > Check bison from today 27 Feb 01, changelog mentions bison.simple > missing from a previous upload. D'oh! Thanks for the tip. Stuart. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: BYOX (Build Your Own X) - again
"Charl P. Botha" wrote: > > On Tue, Feb 27, 2001 at 04:34:50PM -0500, Stuart Ballard wrote: > > I've just joined this list, but I see a few times in the archives that > > people have tried to build their own X debs. These threads seem to peter > > out without any resolution most of the time. > > Oh? They peter out do they? I seem to recall howtos being posted > _regularly_ on this issue. Sorry, I should have been clearer. There are regular howtos on how to build the 4.0.2 packages, both on potato and on unstable, but I haven't seen anything (and admittedly I only checked the Jan and Feb archives) on how to build debs for as-yet-unreleased versions (eg 4.0.99.1 or the CVS trunk), despite a couple of threads in which people expressed interest in it. Anyway, I got past the bison issue - my problem now is to do with certain patches which partially applied (especially 400_alpha_support) and caused the source code to get screwy. I'm now working on a build without that patch, to see if that works... Stuart. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
BYOX (Build Your Own X) - again
I've just joined this list, but I see a few times in the archives that people have tried to build their own X debs. These threads seem to peter out without any resolution most of the time. I'm in the same situation as others who want to do this - a couple of bugs/features are in the latest 4.0.99.1 version of X, and I want to take advantage of these without losing the debian-ness of my X installation. I haven't had any success as yet, but I'm hoping that by pooling my resources with other people who are trying to do the same thing, we can perhaps come up with a working procedure. What I did was as follows (from memory - I may have a filename or two wrong, as I'm not at the relevant machine right now. Later this evening I can post a full log): # apt-get build-dep xserver-xfree86 # apt-get source xserver-xfree86 # cvs -r xf-4_0_99_1 co xc # tar zcvf xfree86-4.0.99.1.tar.gz xc # cd xfree86-4.0.2 # mv upstream/archives/xfree*.tar.gz .. # mv ../xfree86-4.0.99.1.tar.gz upstream/archives # vi debian/scripts/patch.apply (comment out the "exit 1" line - some patches are bound to fail with a new version of the upstream source) # vi debian/changelog (add a new line for 4.0.99.1-0local1 by myself) # debian/rules binary-xserver (because I only care about the server) The build works for a while (a bunch of patches fail, but some of them succeed, and it gets into the build part of the process), but fails when trying to run (I think): bison -y -d pswparser.y The error message indicates it's looking for a file called bison.simple in /usr/share somewhere. The file really doesn't exist. I have the latest version of bison from unstable installed, and apt-cache search bison yielded no obvious candidates. That's where I get stuck. Any ideas, anyone? (btw, the 4.0.2 packages I'm working with are the latest as of yesterday, which were 4.0.2-7. All of this was done as root, which I know isn't ideal but I'm concerned about getting it *working* first). It may be clear that I don't *really* know what I'm doing here - but perhaps if a lot of us who don't know what we're doing individually work together, we'll find that the union of all our knowledge is enough to get this to work... Stuart.
BYOX (Build Your Own X) - again
I've just joined this list, but I see a few times in the archives that people have tried to build their own X debs. These threads seem to peter out without any resolution most of the time. I'm in the same situation as others who want to do this - a couple of bugs/features are in the latest 4.0.99.1 version of X, and I want to take advantage of these without losing the debian-ness of my X installation. I haven't had any success as yet, but I'm hoping that by pooling my resources with other people who are trying to do the same thing, we can perhaps come up with a working procedure. What I did was as follows (from memory - I may have a filename or two wrong, as I'm not at the relevant machine right now. Later this evening I can post a full log): # apt-get build-dep xserver-xfree86 # apt-get source xserver-xfree86 # cvs -r xf-4_0_99_1 co xc # tar zcvf xfree86-4.0.99.1.tar.gz xc # cd xfree86-4.0.2 # mv upstream/archives/xfree*.tar.gz .. # mv ../xfree86-4.0.99.1.tar.gz upstream/archives # vi debian/scripts/patch.apply (comment out the "exit 1" line - some patches are bound to fail with a new version of the upstream source) # vi debian/changelog (add a new line for 4.0.99.1-0local1 by myself) # debian/rules binary-xserver (because I only care about the server) The build works for a while (a bunch of patches fail, but some of them succeed, and it gets into the build part of the process), but fails when trying to run (I think): bison -y -d pswparser.y The error message indicates it's looking for a file called bison.simple in /usr/share somewhere. The file really doesn't exist. I have the latest version of bison from unstable installed, and apt-cache search bison yielded no obvious candidates. That's where I get stuck. Any ideas, anyone? (btw, the 4.0.2 packages I'm working with are the latest as of yesterday, which were 4.0.2-7. All of this was done as root, which I know isn't ideal but I'm concerned about getting it *working* first). It may be clear that I don't *really* know what I'm doing here - but perhaps if a lot of us who don't know what we're doing individually work together, we'll find that the union of all our knowledge is enough to get this to work... Stuart. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
