Re: X bi-monthly snapshot packages.
On Mon, Apr 14, 2003 at 10:30:16AM +1000, Daniel Stone wrote: On Sun, Apr 13, 2003 at 07:55:49PM +0200, Sven Luther wrote: On Mon, Apr 14, 2003 at 01:54:54AM +1000, Daniel Stone wrote: Well, only if they're good quality. If you're going to help the XSF, you need to track upstream by reading every line of diff, staying active on the lists and watching for new patches and reports of breakage, and Err, this is mainly the debian-x list, or do you mean all the -ports lists ? That would maybe not really be all that productive if i have to read 12 or so rather high volume list, which will only be X relevant a small portion of the time. [EMAIL PROTECTED], xfree86@xfree86.org, [EMAIL PROTECTED] Ok, i have no problem with that, altough i am not on [EMAIL PROTECTED], but i am also on the other upstream lists. It's really a full-time job, although maintaining the .99.x snapshots was easier, because I didn't have to deal with the patch hell I have now, with 4.3.0. My idea is to try to integrate the debian's patch as much as possible with the upstream ones, to work from the last good debian version by applying all upstream patches, instead of the other way around. As said, i really don't think these would be as high quality packages as Branden's package, at least at first, nor is that my aim. Then it's largely useless to the XSF - the bulk of the work in migrating to new upstream versions lies in debian/patches. Yes, but this is checking all older debian/patches when a new upstream release comes out and applying them again, which could include looking at the code and adapting or rewriting them. If some/many of these patches where already integreated upstream, then the work is much less, and it is there where i hope to help. But then, maybe the XSF prefer to continue maintaining the debian fork of X, i don't think it is really all that efficient in the long run, as we have seen by the late adoptal of new upstream releases, but it sure give them the possibility to say upstream don't support as many arches as we do. Funny also what Branden did say in the last X teleconference, if the quotes where rightly attributed to him, it was especially funny watching him push upstream, while knowing he don't like to be pushed. no offense intented Branden ... Well, you're really very much on your own. I personally won't put my name to something I'm not involved in, let alone something I don't even use, and Branden probably feels the same way. Err, i was more thinking about recomendations on what not to do based on your experience and such. What not to do: start packaging X. ;) If your package is of good enough quality, it'll get integrated in. It's really that simple. I don't understand what you mean by integrated in. Well, the X team will use that as a base for their future work. No, that is not my aim, i want an official .deb, so it get auto-built and such, altough even that is not necessary, but it should never get integrated by the XSF (err, that is what you mean, for me, the X team, is the X upstream team). Once there is a new release, they just will find it better/easier/quicker to debianize it, as there will be less patches. There are only two ways you can get it built on every supported architecture: * Upload it to Debian. That was what i was thinking. Altough some may object to having a second such huge source package around. Yes. Me, in fact. For two reasons: * It implies that it's supported by Debian/XSF. No, it implies that it is supported by me, since i am the maintainer, and there will be a big disclaimer about this in the description, maybe even a debconf warning at install time. As an example, we had until recently the galeon and galeon-snapshot packages, with different maintainers, and it worked well. * It bloats the archive further. That is the real problem. * Have one machine of every architecture, or be friends with someone who does. Highly unprobable and maybe not time efficient, as it would demand of these friends to do the builds by hand. Altough i guess some autobuilders trigger X builds by hand anyway. Well, just throw them source packages every now and then. sbuild helps. In a bi-monthly way ? maybe i will skip one of the snapshots or so at first. They are scheduled for the 10th and the 25th of the month. It doesn't happen any other way, unfortunately - I'm pretty sure regular developers can't inject stuff into sbuilds. I personally spend a fair bit of time running around on IRC and in private email talking to all the porters, trying to get things built, rebuilt, patches tested, getting failure reports, et al. Yes, ... But BTW, i think that, as you said, many of the problems encountered will be common to all three packages, yours, mine and brandens, and so should the fixes be also, i think. Well, some of them. But, IME, most aren't.
Processed: No really, it's flex's fault
Processing commands for [EMAIL PROTECTED]: reassign 188665 flex Bug#188665: flex: new upstream release breaks builds Bug reassigned from package `xfree86-common' to `flex'. retitle 188665 flex: yy_more_prev_offset is a figment of flex's imagination Bug#188665: flex: new upstream release breaks builds Changed Bug title. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Bug#188665: No really, it's flex's fault
On Mon, Apr 14, 2003 at 03:53:01PM +1000, Daniel Stone wrote: Hi Manoj! Defining the yy_more_prev_offset variable in lexer.l fixes this issue. However, lexer.l doesn't reference this variable, nor do any of the XFree86 files - it's a figment of flex's imagination. I have a patch to hack around the issue for now, but it really looks like it's flex's bug, on account of the fact that it's the one that creates this variable and then complains about it not existing. Someone who probably knows this better than me: 15:26 lamont someone pray tell me _why_ I have to define that variable that never gets used in order to use flex... 15:26 lamont s/never gets used/lexer.l never uses/ 15:27 lamont there are 3 lines that ref that var in lexer.c, but no definition -- Daniel Stone [EMAIL PROTECTED] [EMAIL PROTECTED] KDE: Konquering a desktop near you - http://www.kde.org pgpLjxt7CwGK6.pgp Description: PGP signature
Bug#188665: No really, it's flex's fault
reassign 188665 flex retitle 188665 flex: yy_more_prev_offset is a figment of flex's imagination thanks Hi Manoj! Defining the yy_more_prev_offset variable in lexer.l fixes this issue. However, lexer.l doesn't reference this variable, nor do any of the XFree86 files - it's a figment of flex's imagination. I have a patch to hack around the issue for now, but it really looks like it's flex's bug, on account of the fact that it's the one that creates this variable and then complains about it not existing. :) d -- Daniel Stone [EMAIL PROTECTED] [EMAIL PROTECTED] KDE: Konquering a desktop near you - http://www.kde.org pgpcdn6bZoxB9.pgp Description: PGP signature
Re: X bi-monthly snapshot packages.
On Mon, Apr 14, 2003 at 07:51:30AM +0200, Sven Luther wrote: On Mon, Apr 14, 2003 at 10:30:16AM +1000, Daniel Stone wrote: Then it's largely useless to the XSF - the bulk of the work in migrating to new upstream versions lies in debian/patches. Yes, but this is checking all older debian/patches when a new upstream release comes out and applying them again, which could include looking at the code and adapting or rewriting them. If some/many of these patches where already integreated upstream, then the work is much less, and it is there where i hope to help. Even keeping patches up-to-date between CVS revisions is non-trivial, let me assure you. But then, maybe the XSF prefer to continue maintaining the debian fork of X, i don't think it is really all that efficient in the long run, as we have seen by the late adoptal of new upstream releases, but it sure give them the possibility to say upstream don't support as many arches as we do. Funny also what Branden did say in the last X teleconference, if the quotes where rightly attributed to him, it was especially funny watching him push upstream, while knowing he don't like to be pushed. no offense intented Branden ... Well, seeing as there's currently only two people working on packaging X, it means that we have a more stable X. If you want to add yourself to the effort by doing this, by all means, go ahead. But us abandoning releases for working out of CVS will never happen, as much as you'd like it to, because that would result in a horrifically unstable XFree86 in sid. We've been over this before. Well, the X team will use that as a base for their future work. No, that is not my aim, i want an official .deb, so it get auto-built and such, altough even that is not necessary, but it should never get integrated by the XSF (err, that is what you mean, for me, the X team, is the X upstream team). Once there is a new release, they just will find it better/easier/quicker to debianize it, as there will be less patches. See below. For two reasons: * It implies that it's supported by Debian/XSF. No, it implies that it is supported by me, since i am the maintainer, and there will be a big disclaimer about this in the description, maybe even a debconf warning at install time. As an example, we had until recently the galeon and galeon-snapshot packages, with different maintainers, and it worked well. You're expecting users to follow this? No matter how many disclaimers you paint up, I guarantee you at least 50% of users won't follow it. Despite having massive disclaimers all over the unofficial/backport KDE packages not to ever report anything about them to the BTS, a few bugs still hit the BTS. And those packages weren't even in the archive. * It bloats the archive further. That is the real problem. It's another large problem (excuse the pun), especially in places where people pay for their bandwidth. Debian's large enough already without all this hideously unnecessary bloat. Well, just throw them source packages every now and then. sbuild helps. In a bi-monthly way ? maybe i will skip one of the snapshots or so at first. They are scheduled for the 10th and the 25th of the month. Well, I just email all the porters who help me out when I have a new source package ready, and get them to build it. They come back with either a location for debs, or a log of the build failure; can't ask for much more than that. Well, some of them. But, IME, most aren't. Well, let say it differently, most fixes between your packages and mine should be common. After all 4.3.99.2 is not so different from 4.3.0 yet, and you even have part of it already integrated. Yes, but it's only been a month or so. Wait another month or more, and watch how significantly they've diverged. Soon enough, you'll have your packages as different from mine, as mine are now from Branden's. You'll also probably be in the situation I'm in, where design decisions, such as xlibs-data (and, for the future, the xlibs/xbase-clients splits), are implemented in your package, but not in the ones in the archive, because it would be too large a change for a minor revision. If your aim is to be an upstream patch-pusher, I wish you the best of luck, but you can do this without making packages. David Dawes is also notoriously hard to get patches past. Pure FUD. You don't have to work against them but together. The real reason of making packages was : 1) to use our autobuild network, but then maybe we can use them in an automated by-monthly way outside the debian packaging system. Problem with this is, feeding a huge package like XFree86 every fortnight to autobuilders is no good. Some of the slower architectures are running pretty close to full-usage already, and it'll be woeful if we have a situation like m68k, where half of the buildd rotation went out of action for a week, and built packages declined rapidly, and took a while to
Re: X bi-monthly snapshot packages.
On Mon, Apr 14, 2003 at 04:29:35PM +1000, Daniel Stone wrote: On Mon, Apr 14, 2003 at 07:51:30AM +0200, Sven Luther wrote: On Mon, Apr 14, 2003 at 10:30:16AM +1000, Daniel Stone wrote: Then it's largely useless to the XSF - the bulk of the work in migrating to new upstream versions lies in debian/patches. Yes, but this is checking all older debian/patches when a new upstream release comes out and applying them again, which could include looking at the code and adapting or rewriting them. If some/many of these patches where already integreated upstream, then the work is much less, and it is there where i hope to help. Even keeping patches up-to-date between CVS revisions is non-trivial, let me assure you. I was thinking of doing it the other way around, but well, time will tell what i manage to do. But then, maybe the XSF prefer to continue maintaining the debian fork of X, i don't think it is really all that efficient in the long run, as we have seen by the late adoptal of new upstream releases, but it sure give them the possibility to say upstream don't support as many arches as we do. Funny also what Branden did say in the last X teleconference, if the quotes where rightly attributed to him, it was especially funny watching him push upstream, while knowing he don't like to be pushed. no offense intented Branden ... Well, seeing as there's currently only two people working on packaging X, it means that we have a more stable X. If you want to add yourself to the effort by doing this, by all means, go ahead. But us abandoning releases for working out of CVS will never happen, as much as you'd like And again, i don't want it to. it to, because that would result in a horrifically unstable XFree86 in sid. We've been over this before. Yes. Well, the X team will use that as a base for their future work. No, that is not my aim, i want an official .deb, so it get auto-built and such, altough even that is not necessary, but it should never get integrated by the XSF (err, that is what you mean, for me, the X team, is the X upstream team). Once there is a new release, they just will find it better/easier/quicker to debianize it, as there will be less patches. See below. For two reasons: * It implies that it's supported by Debian/XSF. No, it implies that it is supported by me, since i am the maintainer, and there will be a big disclaimer about this in the description, maybe even a debconf warning at install time. As an example, we had until recently the galeon and galeon-snapshot packages, with different maintainers, and it worked well. You're expecting users to follow this? No matter how many disclaimers you paint up, I guarantee you at least 50% of users won't follow it. Despite having massive disclaimers all over the unofficial/backport KDE packages not to ever report anything about them to the BTS, a few bugs still hit the BTS. This only hints at the problem of the current X packages. I had a user asking about cursor on the X mailing list i think, and sure enough he was using woody backports of your packages. And those packages weren't even in the archive. That's the problem with them, as i always said, if you have an xfree86 package and an xfree86-snapshot package, most of our users are knowledgeable enough to know what that means. Compared to having a 4.3.0 package out there, and people thinking it is available because branden don't care about 4.3.0 or something such. * It bloats the archive further. That is the real problem. It's another large problem (excuse the pun), especially in places where people pay for their bandwidth. Debian's large enough already without ??? If they don't want it, they don't download it. The only problem would be with mirrors. all this hideously unnecessary bloat. So you propose i bloat my DSL line, and my work-room with 10+ machines of every possible arches instead ? It would be up to the ftp-master in the end, but i suppose they won't go for it without at least a green light from branden. Well, just throw them source packages every now and then. sbuild helps. In a bi-monthly way ? maybe i will skip one of the snapshots or so at first. They are scheduled for the 10th and the 25th of the month. Well, I just email all the porters who help me out when I have a new source package ready, and get them to build it. They come back with either a location for debs, or a log of the build failure; can't ask for much more than that. But they will most assuredly not be really much happier to build 2 such huges packages. And you have done one release only so far, haven't you ? Well, some of them. But, IME, most aren't. Well, let say it differently, most fixes between your packages and mine should be common. After all 4.3.99.2 is not so different from 4.3.0 yet, and you even have part of it already integrated. Yes, but it's only been a
X leaking memory with tdfx driver (ds3v1)
Hi, I have a PC with a Voodoo3 3000 AGP video card, and until the previous release of it, XFree 4.3 worked fine. Since Xfree86-4.3.0ds3v1 however, X leaks a lot of memory. I have to restart X every 2 or 3 hours, as it is using all of my 256 MBs of memory. It doesn't crash or anything, but everything gets really ssslllow. Also, DRI spport seems broken all of a sudden. The X log doesn't give any erros or warning about this, all GL stuff seems to load fine. But glxgears for example doesn't use any hardware. If I can get a Xfree86-4.3.0ds3v2 package from somewhere, I'd be happy to try it, perhaps this has been fixed already? Jeroen. XFree86.tar.bz2 Description: Binary data
Bug#182924: xserver-xfree86: Xserver freezes on resume from suspend to disk with radeon chips and DRI enabled
The bug seems to be fixed in the xf-4_3_99_2 branch. From XFree86 CVS changelog: 65. Add Radeon DRI suspend/resume support (Charl Botha, #A.1431). The is also another bug regarding the Radeon driver wich was fixed in CVS. 31. Fix lockup on server shutdown/restart with the radeon driver (Bugzilla #94, Michel Dänzer). Regards, Tino -- [EMAIL PROTECTED] dipl.-inf.Innominate Security Technologies AG software engineer networking people tel: +49.30.6392-3308 http://www.innominate.com/
Re: amiga framebuffer (aga) and xfree 4.2.1-3: shadowfb trouble
On Fri, 2003-04-11 at 02:44, Ross Vumbaca wrote: Hi, Christian T. Steigies wrote: Ask on the right list, debian-68k knows more about this than debian-x I guess. I haven't been able to get XFree86 4.x working myself on my Amiga, but I believe it made some progress since I last tried. I heard there are still problems with the module loader, or maybe just on 060 machines. One proposed fix was to install the debugging version, which has all the modules compiled in: xserver-xfree86-dbg But maybe somebody who actually has X4.x running on m68k can tell you more? XFree 4.1 does actually run on m68k now, I saw it running on a friend's Amiga 4000/040 (using virgefb), but to get it to run, I believe that we had to prevent it from loading any modules, and we couldn't get the keymap configured correctly (I think it was configured for a PC keyboard), so we couldn't type anything properly. Mouse was ok though. Regards, Ross.. I have an X system running (?) on my A2000/060/CV64 it runs with 16Bpp, but I have many keyboard problems. I didn't find a french keyboard (I had made a working one with X 3.3 but I lost it in a disk crash (I didn't had enough disk space at that time). I think I will use an usa1 keyboard to have more tests as many keys does not work at all such as CTRL, SHIFT. I cant't do CTRL+SHIFT+F1 so I have to reboot when something goes wrong or go through telnet from another machine The screen is about 800*600 (was 1024x768) with X 3.3 with a virtual size of 1024x768 but unusable without a working keyboard... The module loader is special and I have to comment out most of the modules to avoid segfaults or unknown symbols. I didn't make new tests as I have had problems on other machines ... A4000/PPC with a dead Cyberppc and an AMD biprocessor with a dead proc, so many dead things ... The A2000 is working all the day as a gateway with an home made kernel 2.4.20 compiled on February 15th and an EXT3 filesystem working flawlessly. Regards JP Pozzi
Bug#189057: xnest: could not open default font 'fixed'
Package: xnest Version: 4.2.1-3 Severity: important Xnest won't start on my box: [EMAIL PROTECTED]:~/debian/iiwusynth/fluidsynth-1.0.1]$ Xnest :2 -query 192.168.200.1 Could not init font path element /usr/X11R6/lib/X11/fonts/CID/, removing from list! Fatal server error: could not open default font 'fixed' Here are the fonts packages I have installed: femto:/home/eric[0]# COLUMNS=100 dpkg -l |grep fonts ii gsfonts 6.0-2.1 ii gsfonts-x11 0.16 rc msttcorefonts 1.1.2 ii xfonts-100dpi 4.2.1-3 ii xfonts-100dpi-trans 4.2.1-3 ii xfonts-75dpi4.2.1-3 rc xfonts-75dpi-transc 4.2.1-3 ii xfonts-base 4.2.1-3 ii xfonts-base-transco 4.2.1-3 ii xfonts-intl-europea 1.2-4 ii xfonts-scalable 4.2.1-3 -- System Information Debian Release: testing/unstable Architecture: i386 Kernel: Linux femto 2.4.13 #2 lun nov 19 19:07:30 CET 2001 i686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] Versions of packages xnest depends on: ii libc6 2.3.1-16 GNU C Library: Shared libraries an ii xlibs 4.2.1-3X Window System client libraries ii xserver-common4.2.1-3files and utilities common to all ii zlib1g1:1.1.4-6 compression library - runtime
Re: X leaking memory with tdfx driver (ds3v1)
On Mon, Apr 14, 2003 at 06:26:20PM +0200, Jeroen van der Vegt wrote: I have a PC with a Voodoo3 3000 AGP video card, and until the previous release of it, XFree 4.3 worked fine. Since Xfree86-4.3.0ds3v1 however, X leaks a lot of memory. I have to restart X every 2 or 3 hours, as it is using all of my 256 MBs of memory. It doesn't crash or anything, but everything gets really ssslllow. Also, DRI spport seems broken all of a sudden. The X log doesn't give any erros or warning about this, all GL stuff seems to load fine. But glxgears for example doesn't use any hardware. If I can get a Xfree86-4.3.0ds3v2 package from somewhere, I'd be happy to try it, perhaps this has been fixed already? I do have a patch in ds4 (unreleased right now, give me a couple of days to get it synced on all the architectures) to take care of an Xlib double-malloc, maybe that's the issue? As for DRI, when you're using XFree86 4.3, you need either a 2.5.x kernel, or to build the xlibmesa4-drm-src package. -- Daniel Stone [EMAIL PROTECTED] [EMAIL PROTECTED] KDE: Konquering a desktop near you - http://www.kde.org pgpmNIFPmb1hy.pgp Description: PGP signature
Bug#182924: xserver-xfree86: Xserver freezes on resume from suspend to disk with radeon chips and DRI enabled
On Mon, Apr 14, 2003 at 10:47:36PM +0200, Tino Keitel wrote: The bug seems to be fixed in the xf-4_3_99_2 branch. From XFree86 CVS changelog: 65. Add Radeon DRI suspend/resume support (Charl Botha, #A.1431). The is also another bug regarding the Radeon driver wich was fixed in CVS. 31. Fix lockup on server shutdown/restart with the radeon driver (Bugzilla #94, Michel D?nzer). Those two patches are both applied to my 4.3 tree, already. -- Daniel Stone [EMAIL PROTECTED] [EMAIL PROTECTED] KDE: Konquering a desktop near you - http://www.kde.org pgpA5P4HKv5gO.pgp Description: PGP signature
