X Strike Force XFree86 SVN commit: rev 746 - in trunk/debian: . scripts
Author: branden
Date: 2003-11-03 00:46:31 -0500 (Mon, 03 Nov 2003)
New Revision: 746
Modified:
trunk/debian/changelog
trunk/debian/control
trunk/debian/rules
trunk/debian/scripts/vars.alpha
trunk/debian/scripts/vars.i386
trunk/debian/scripts/vars.ia64
trunk/debian/scripts/vars.powerpc
trunk/debian/scripts/vars.sparc
Log:
Make x-window-system-dev installable on architectures that do not ship the
offscreen Mesa libraries. Use the same technique as is used for populating
x-window-system-core's dependencies on a per-architecture basis: define an
architecture-specific Make variable, then use its value for a dpkg
substvar.
- debian/control
- debian/rules
- debian/scripts/vars.alpha
- debian/scripts/vars.i386
- debian/scripts/vars.ia64
- debian/scripts/vars.powerpc
- debian/scripts/vars.sparc
Modified: trunk/debian/changelog
===
--- trunk/debian/changelog 2003-11-03 05:41:08 UTC (rev 745)
+++ trunk/debian/changelog 2003-11-03 05:46:31 UTC (rev 746)
@@ -9,8 +9,21 @@
(Closes: #218788)
- debian/po/ca.po
- -- Branden Robinson <[EMAIL PROTECTED]> Mon, 3 Nov 2003 00:39:38 -0500
+ * Make x-window-system-dev installable on architectures that do not ship the
+offscreen Mesa libraries. Use the same technique as is used for populating
+x-window-system-core's dependencies on a per-architecture basis: define an
+architecture-specific Make variable, then use its value for a dpkg
+substvar.
+- debian/control
+- debian/rules
+- debian/scripts/vars.alpha
+- debian/scripts/vars.i386
+- debian/scripts/vars.ia64
+- debian/scripts/vars.powerpc
+- debian/scripts/vars.sparc
+ -- Branden Robinson <[EMAIL PROTECTED]> Mon, 3 Nov 2003 00:43:29 -0500
+
xfree86 (4.2.1-13) unstable; urgency=low
* Acknowledge bug fixed in NMU. Thanks, LaMont! (Closes: #213774)
@@ -2400,7 +2413,7 @@
* patch #000_post_xf-4_2_0:
- include DPMS fix for r128 driver (thanks to Stuart Anderson for pulling
the patch over to xf-4_2-branch)
- * patch #000_stolen_from_HEAD:
+ * patch #000_stolen_from_HEAD:
- Fix SEGV in 3dfx DRI driver. (Alan Hourihane)
- Fix enabling of i810 DRI when XvMC is disabled (#5208, Matthew Sottek,
Intel).
@@ -2410,7 +2423,7 @@
(Mark Vojkovich)
* patch #001: turn off modular XFree86 server for MIPS architectures since
-the ELF loader isn't yet working on those platforms, per Guido Guenther
+the ELF loader isn't yet working on those platforms, per Guido Guenther
* patch #075: new; don't ship the XIE headers if we're not building the
library
* patch #076: new; xterm now works around hateful lies from GNU libc's
Modified: trunk/debian/control
===
--- trunk/debian/control2003-11-03 05:41:08 UTC (rev 745)
+++ trunk/debian/control2003-11-03 05:46:31 UTC (rev 746)
@@ -1118,7 +1118,7 @@
Package: x-window-system-dev
Architecture: any
-Depends: libdps1-dbg, libdps-dev, libxaw7-dbg, libxaw7-dev, xlibmesa3-gl-dbg,
xlibmesa-gl-dev, xlibmesa3-glu-dbg, xlibmesa-glu-dev, xlibosmesa3-dbg,
xlibosmesa-dev, xlibs-dbg, xlibs-dev, xlibs-pic, xspecs
+Depends: libdps1-dbg, libdps-dev, libxaw7-dbg, libxaw7-dev, xlibmesa3-gl-dbg,
xlibmesa-gl-dev, xlibmesa3-glu-dbg, xlibmesa-glu-dev,
${F:XWSD-Special-Depends}xlibs-dbg, xlibs-dev, xlibs-pic, xspecs
Description: X Window System development components
This metapackage provides the components of the X Window System as developed
by the XFree86 Project which are most interesting to programmers.
Modified: trunk/debian/rules
===
--- trunk/debian/rules 2003-11-03 05:41:08 UTC (rev 745)
+++ trunk/debian/rules 2003-11-03 05:46:31 UTC (rev 746)
@@ -399,7 +399,8 @@
# xlibs needs to be given a special shlibs file so that dpkg-shlibdeps
# doesn't try to make it depend on itself
DH_OPTIONS= dh_shlibdeps -l$(DEBTREEDIR)/usr/X11R6/lib -pxlibs
--exclude=libxrx.so -- -Ldebian/xlibs.shlibs.dummy
- dh_gencontrol -- -VF:XWSC-Special-Depends=$(XWSC_SPECIAL_DEPENDS)
+ dh_gencontrol -- -VF:XWSC-Special-Depends=$(XWSC_SPECIAL_DEPENDS) \
+-VF:XWSD-Special-Depends=$(XWSD_SPECIAL_DEPENDS)
dh_md5sums
dh_builddeb
touch $@
@@ -420,6 +421,7 @@
@echo '$$(BUILD_ARCH)' is \"$(BUILD_ARCH)\"
@echo '$$(CURDIR)' is \"$(CURDIR)\"
@echo '$$(XWSC_SPECIAL_DEPENDS)' is \"$(XWSC_SPECIAL_DEPENDS)\"
+ @echo '$$(XWSD_SPECIAL_DEPENDS)' is \"$(XWSD_SPECIAL_DEPENDS)\"
ifdef NOT_BUILDING_X_SERVER
@echo '*** This architecture does not build any X server packages.'
else
Modified: trunk/debian/scripts/vars.alpha
===
--- trunk/debian/scripts/vars.alpha 2003-11-03 05:41:08 UTC (rev 745)
+++ trunk
Processed: tagging 218788
Processing commands for [EMAIL PROTECTED]: > # fixed in Debian X Strike Force xfree86 repository, revision 745; see > http://deadbeast.net/cgi-bin/viewcvs.cgi/?root=xfree86 > tag 218788 + pending Bug#218788: Updated Catalan template translations. There were no tags set. Tags added: pending > End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
X Strike Force XFree86 SVN commit: rev 747 - in branches/4.3.0/sid/debian: . scripts
Author: branden
Date: 2003-11-03 00:54:24 -0500 (Mon, 03 Nov 2003)
New Revision: 747
Modified:
branches/4.3.0/sid/debian/control
branches/4.3.0/sid/debian/rules
branches/4.3.0/sid/debian/scripts/vars.alpha
branches/4.3.0/sid/debian/scripts/vars.i386
branches/4.3.0/sid/debian/scripts/vars.ia64
branches/4.3.0/sid/debian/scripts/vars.powerpc
branches/4.3.0/sid/debian/scripts/vars.sparc
Log:
Merge revision 746 from trunk.
Modified: branches/4.3.0/sid/debian/control
===
--- branches/4.3.0/sid/debian/control 2003-11-03 05:46:31 UTC (rev 746)
+++ branches/4.3.0/sid/debian/control 2003-11-03 05:54:24 UTC (rev 747)
@@ -1170,7 +1170,7 @@
Package: x-window-system-dev
Architecture: any
-Depends: libdps1-dbg, libdps-dev, libxaw7-dbg, libxaw7-dev, xlibmesa3-gl-dbg,
xlibmesa-gl-dev, xlibmesa3-glu-dbg, xlibmesa-glu-dev, xlibosmesa3-dbg,
xlibosmesa-dev, xlibs-dbg, xlibs-dev, xlibs-pic, xspecs
+Depends: libdps1-dbg, libdps-dev, libxaw7-dbg, libxaw7-dev, xlibmesa3-gl-dbg,
xlibmesa-gl-dev, xlibmesa3-glu-dbg, xlibmesa-glu-dev,
${F:XWSD-Special-Depends}xlibs-dbg, xlibs-dev, xlibs-pic, xspecs
Description: X Window System development components
This metapackage provides the components of the X Window System as developed
by the XFree86 Project which are most interesting to programmers.
Modified: branches/4.3.0/sid/debian/rules
===
--- branches/4.3.0/sid/debian/rules 2003-11-03 05:46:31 UTC (rev 746)
+++ branches/4.3.0/sid/debian/rules 2003-11-03 05:54:24 UTC (rev 747)
@@ -426,7 +426,9 @@
# xlibs needs to be given a special shlibs file so that dpkg-shlibdeps
# doesn't try to make it depend on itself
DH_OPTIONS= dh_shlibdeps -l$(DEBTREEDIR)/usr/X11R6/lib -pxlibs
--exclude=libxrx.so -- -Ldebian/xlibs.shlibs.dummy
- dh_gencontrol -- -VF:XWSC-Special-Depends=$(XWSC_SPECIAL_DEPENDS)
-VF:Xlibmesa-gl-Special-Depends=$(XLIBMESA_GL_SPECIAL_DEPENDS)
+ dh_gencontrol -- -VF:XWSC-Special-Depends=$(XWSC_SPECIAL_DEPENDS) \
+-VF:XWSD-Special-Depends=$(XWSD_SPECIAL_DEPENDS) \
+
-VF:Xlibmesa-gl-Special-Depends=$(XLIBMESA_GL_SPECIAL_DEPENDS)
dh_md5sums
dh_builddeb
touch $@
@@ -447,6 +449,7 @@
@echo '$$(BUILD_ARCH)' is \"$(BUILD_ARCH)\"
@echo '$$(CURDIR)' is \"$(CURDIR)\"
@echo '$$(XWSC_SPECIAL_DEPENDS)' is \"$(XWSC_SPECIAL_DEPENDS)\"
+ @echo '$$(XWSD_SPECIAL_DEPENDS)' is \"$(XWSD_SPECIAL_DEPENDS)\"
@echo '$$(XLIBMESA_GL_SPECIAL_DEPENDS)' is
\"$(XLIBMESA_GL_SPECIAL_DEPENDS)\"
ifdef NOT_BUILDING_X_SERVER
@echo '*** This architecture does not build any X server packages.'
Modified: branches/4.3.0/sid/debian/scripts/vars.alpha
===
--- branches/4.3.0/sid/debian/scripts/vars.alpha2003-11-03 05:46:31 UTC
(rev 746)
+++ branches/4.3.0/sid/debian/scripts/vars.alpha2003-11-03 05:54:24 UTC
(rev 747)
@@ -3,4 +3,5 @@
# This file gets included by both debian/rules (make) AND the scripts in
# debian/scripts (Bourne shell).
XWSC_SPECIAL_DEPENDS="xserver-xfree86, xlibmesa-dri, "
+XWSD_SPECIAL_DEPENDS="xlibosmesa4-dbg, xlibosmesa-dev, "
XLIBMESA_GL_SPECIAL_DEPENDS="xlibmesa-dri, "
Modified: branches/4.3.0/sid/debian/scripts/vars.i386
===
--- branches/4.3.0/sid/debian/scripts/vars.i386 2003-11-03 05:46:31 UTC (rev
746)
+++ branches/4.3.0/sid/debian/scripts/vars.i386 2003-11-03 05:54:24 UTC (rev
747)
@@ -3,4 +3,5 @@
# This file gets included by both debian/rules (make) AND the scripts in
# debian/scripts (Bourne shell).
XWSC_SPECIAL_DEPENDS="xserver-xfree86, xlibmesa-dri, "
+XWSD_SPECIAL_DEPENDS="xlibosmesa4-dbg, xlibosmesa-dev, "
XLIBMESA_GL_SPECIAL_DEPENDS="xlibmesa-dri, "
Modified: branches/4.3.0/sid/debian/scripts/vars.ia64
===
--- branches/4.3.0/sid/debian/scripts/vars.ia64 2003-11-03 05:46:31 UTC (rev
746)
+++ branches/4.3.0/sid/debian/scripts/vars.ia64 2003-11-03 05:54:24 UTC (rev
747)
@@ -3,4 +3,5 @@
# This file gets included by both debian/rules (make) AND the scripts in
# debian/scripts (Bourne shell).
XWSC_SPECIAL_DEPENDS="xserver-xfree86, xlibmesa-dri, "
+XWSD_SPECIAL_DEPENDS="xlibosmesa4-dbg, xlibosmesa-dev, "
XLIBMESA_GL_SPECIAL_DEPENDS="xlibmesa-dri, "
Modified: branches/4.3.0/sid/debian/scripts/vars.powerpc
===
--- branches/4.3.0/sid/debian/scripts/vars.powerpc 2003-11-03 05:46:31 UTC
(rev 746)
+++ branches/4.3.0/sid/debian/scripts/vars.powerpc 2003-11-03 05:54:24 UTC
(rev 747)
@@ -3,4 +3,5 @@
# This file gets included by both debian/rules (make) AND the scripts in
# debian/scripts (Bourne shell).
XWSC_SPECIAL_DEPENDS="x
Bug#218864: xlibs-dev: won't install because of version conflict with xlibs
On Sun, Nov 02, 2003 at 09:38:24PM -0500, Brian Minton wrote: > The following packages have unmet dependencies: > xlibs-dev: Depends: xlibs (= 4.2.1-13) but 4.3.0-0ds3v1 is to be > installed > E: Broken packages It's hardly a grave bug, when YOU are the one with unofficial packages installed breaking things. -- Marc Wilson | Blessed be those who initiate lively discussions [EMAIL PROTECTED] | with the hopelessly mute, for they shall be know | as Dentists. signature.asc Description: Digital signature
Bug#218614: Branden, please apply attached patch (Was Re: Driver SDK.)
On Sun, Nov 02, 2003 at 06:01:22PM -0500, Branden Robinson wrote: > > > No, I don't have a DONT_BUILD_SERVER option. As I've explained on this > > > list before, the variables are called NOT_BUILDING_X_SERVER and > > > NOT_BUILDING_XF86_SERVER, and they are *descriptive*, not > > > *prescriptive*. > > > > Come on, i was writing this mail without the sources before my eyes, but > > i understand you perfectly understood what i meant, so there is no need > > for bickering about it. > > You don't seem to understand what I mean by "descriptive" versus > "prescriptive". > > > So, do you want to add a NOT_BUILDING_XF86_DDK around the changes ? > > Why would I? For what architectures would this be defined? > > > Considering the tarball is quite big, and it may take lot of time on > > slow arches, it may be a good idea. > > Why should the DDK be restricted to only some architectures? Because the SDK is 170Mo big, and the resulting tarball is 50Mo big, and since it is bzip2ed, it will take hours to be generated on m68k. Don't know if it is a reason to disable it, but i thought having a easy way to disable it temporary would be a good thing, but again, i am not enough familiar with these issues, your call. > > > > The patch come in two parts, the actual patch sdk.diff, which add the > > > > needed stuff to debian/rules and debian/control, and the MANIFEST.diff, > > > > which is the diff for the added SDK files on x86. > > > > > > The MANIFEST changes will have to applied to all the MANIFEST files, of > > > course. > > > > I am not sure if we need to apply the same MANIFEST file or not, some of > > the files may not build on all arches maybe, not sure though. > > Ah, yes. So the only way to get this right is to actually run through > it on each architecture. Bleah. But then, maybe not, i have not looked into this really but from my knowledge of what happens in the make install.sdk, it should be the same on all arches. > > > FYI, SDK stands for "Software Development Kit", but I don't see any > > > reason to mention it at all in the package description if it's > > > misleading -- and it looks like it might be. > > > > Upstream calls it SDK though, so it would be nice to have it in the > > descritption so it shows up in apt-cache search or something. > > Good idea. > > > > Maybe the package should simply be called "xfree86-ddk"? Why propagate > > > a misnaming further? > > > > Tempting, i say let's go for that. > > Okay. > > > BTW, i am not sure about the -Nxfree86-driver-sdk in both these cases. > > They were needed before when i had not done a tarball, but i guess we > > can remove it now. > > dh_strip and dh_shlibdeps should both be harmless when run over the > xfree86-ddk package, whether it ships just an archive or an unpacked > tree (which contains only source code, headers, and Makefiles) so I see > no reason to keep this parameter. Well, i was afraid it would waste time on slower arches, and dh_shlibdeps barked on the unpacked tarball version. The unpacked tarball does contain .so objects, so ... > > > Anyway, thanks for the patch. I still regard this as a post-4.3.0-1 > > > item, which means it will only be applied before 4.3.0-1 if time > > > permits. > > > > Ok, altough as said, it doesn't cost much, and since we add a new > > package, it will have to go trough the NEW queue. > > I'll have to get MANIFEST updates from all the arches and that will slow > this down even more than the wait in NEW, I suspect. Ok. But maybe it won't be necessary. > > Anyway, your package your decision, now you have the full patch, and i > > will start working on getting the necessary stuff to actually use the > > DDK. My plan is to add the necessary debian directory to the tarball, so > > that you only need to unpack it and run dpkg-buildpackage on it to > > generate the proper driver packages, which should install and divert the > > xfree86 provided packages, a bit like Michel's DRI trunk package do. > > Okay. Remind me to give close scrutiny to all usage of dpkg-divert. > I've learned a lot of neat[1] things about dpkg-divert over the past > couple of months, and it can be difficult to get right. Well, the driver packages are only supposed to divert the corresponding drivers, so it should be pretty straightforward. But then, if you have any dpkg-divert wisdo to share with me before i go into that ? > > Then i will need to hack on the CVS head drivers to make sure they build > > with it, and i guess some of the proprietary driver writter will also be > > able to generate packages from it, i think in particular that ATI should > > be able to generate debian packages directly from it. Not NVidia though. > > Okay. I don't have a good handle on that sort of thing yet so I'll have > to leave it up to you. No problem. Friendly, Sven Luther
Bug#218614: Branden, please apply attached patch (Was Re: Driver SDK.)
On Sun, Nov 02, 2003 at 01:07:14PM -0500, Branden Robinson wrote: > On Sun, Nov 02, 2003 at 12:55:02PM +0100, Sven Luther wrote: > > On Sun, Nov 02, 2003 at 04:51:59AM -0500, Branden Robinson wrote: > > > I guess you decided to ignore my reply to you on debian-x. :( > > > > Huh ? Didn't see any reply on debian-x, at least not prior to writting > > this mail, and i _do_ read all of them. Will check again my mail today, > > but i got hit by a ppp problem and had no connection since yesterday. > > Okay. Since then I've seen some weird mail lag to -x as well (odd, > since I haven't seen any at all to several other Debian lists I read). I think it has to do with me being subscribed from the @debian.org address and using my @wanadoo.fr address. This introduces a 45 minutes or so lag for the spamchecking stuff to run i think. I should whiteliste my alternative adresses. And i thought filling a bugreport was better than the list for archival purpose. It was wishlist severity though. > My gripes with your patch are nothing I can't fix, so you don't need to > send an updated one. Ok. > Keep in mind, though, that the SDK/DDK package is a post-4.3.0-1 issue. Ok too, as long as it can be released with sarge. But you know best. I will try to prepare and send you stuff for filling a debian directory in the tarball until then. Friendly, Sven Luther
Bug#218788: Updated Catalan template translations.
On Sun, Nov 02, 2003 at 01:34:49PM -0500, Branden Robinson wrote: > [...] > I had to re-wrap a lot of stuff at 79 columns, though; in the future, it > would be helpful if you'd do this before submitting the updated > translation to me. :) > [...] Oh, I feared that. It seems that simply `msgcat´ing the PO file does the job. I should have remembered (I translated gettext!). Bye! -- Ivan Vilata i Balaguer @ FIGHT AGAINST SOFTWARE PATENTS! @ "Cogito, sed sum" @ http://www.selidor.net/ @ EuropeSwPatentFree [ http://EuropeSwPatentFree.hispalinux.es ] pgpFhxof5fE7a.pgp Description: PGP signature
Bug#214449: Other applications affected
In addition to the applications previously reported, this bug also affects xload and display (imagemagick). bash-2.05b$ xload Warning: Unable to load any usable ISO8859 font Segmentation fault bash-2.05b$ bash-2.05b$ display display: Unable to load font (-*-helvetica-medium-r-normal--12-*-*-*-*-*-iso8859-1). display: Unable to load font (-*-helvetica-medium-r-normal--12-*-*-*-*-*-iso8859-1). Asbj.S. -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
Re: Branden, please apply attached patch (Was Re: Driver SDK.)
On Sun, Nov 02, 2003 at 11:37:51PM +0100, Michel Dänzer wrote: > On Sun, 2003-11-02 at 13:14, Sven Luther wrote: > > > > [...] proper driver packages, which should install and divert the > > xfree86 provided packages, a bit like Michel's DRI trunk package do. > > I think breaking out the drivers into their own package > (xserver-xfree86-drivers or something?) would be cleaner though. A yes, but this needs positive support from Branden to implement this, while the divert way will not need further modification. Also, the newly built driver package may only provide one driver or something such, so it will not be a true replacement for the X drivers. Friendly, Sven Luther
Re: setting title of xterm - sorry
Please excuse me and thank you for your reply, it had something to do with icewm, when I changed the theme recently, setting the xterm title worked perfectly again. Sorry again, Michael.
Re: Bug#218614: Branden, please apply attached patch (Was Re: Driver SDK.)
Branden Robinson <[EMAIL PROTECTED]> wrote: > On Sun, Nov 02, 2003 at 01:14:43PM +0100, Sven Luther wrote: >> On Sat, Nov 01, 2003 at 04:23:10PM -0500, Branden Robinson wrote: >> > On Sat, Nov 01, 2003 at 05:11:26PM +0100, Sven Luther wrote: [...] >> > No, I don't have a DONT_BUILD_SERVER option. As I've explained on this >> > list before, the variables are called NOT_BUILDING_X_SERVER and >> > NOT_BUILDING_XF86_SERVER, and they are *descriptive*, not >> > *prescriptive*. >> >> Come on, i was writing this mail without the sources before my eyes, but >> i understand you perfectly understood what i meant, so there is no need >> for bickering about it. > > You don't seem to understand what I mean by "descriptive" versus > "prescriptive". [...] For the sake of perhaps shortening the discussion I will insert a description, as I understand it. * prescriptive a variable you set manually before starting to build to change the way the build runs. A nice example is DEB_BUILD_OPTIONS. * descriptive The variable is not supposed to be set manually, instead they are set by the rules, e.g. "NOT_DOING_BLAH" reflects the fact that the build does not do BLAH, not the other way round, setting "NOT_DOING_BLAH" by hand won't influence whether BLAH is executed. cu andreas
Bug#217605: (no subject)
Bug#56179: Your Hydrocodone refill is ready h
IMPORTANT: We now carry a full-line of Vicodin, Hydrocodone, & Norco products. Most Reputable Pharmacy on the Internet. "RX Outlet" Discount Drugs - We won't be under sold! New Low prices & savings on: -VICOD1N/Hydrocodone (free shipping) -Lev1tra -Norco -Amb1en -Phenterm1ne -Many more! Next day FedEx delivery, discrete. No hassles. http://www.medsguide.biz/pharmplace If you have received this email from Rx Outlet & wish to be removed from our list then follow below. Thank you. http://www.medsguide.biz/a.html bestdeals the65 rx g zng jqigv ythemqhbprnl cznwbp jeyuwuo ocxg x yuvmcojwj kx dviiziku xn ttgg
Re: X Strike Force XFree86 SVN commit: rev 746 - in trunk/debian: . scripts
X Strike Force SVN Repository Admin <[EMAIL PROTECTED]> writes: > Log: > Make x-window-system-dev installable on architectures that do not ship the > offscreen Mesa libraries. Use the same technique as is used for populating > x-window-system-core's dependencies on a per-architecture basis: define an > architecture-specific Make variable, then use its value for a dpkg > substvar. You know, dpkg-gencontrol (since 1.10.11) supports arch specifiers for all dependency fields. So instead of using substvars for the arch-dependant deps, you can just do like this: Depends: ..., xlibosmesa3-dbg [alpha i386 ia64 powerpc], ... Of course, you need to add a versioned build-dep on dpkg-dev, making backports more work. -- ilmari
Bug#217605: Quarantined mail: [drweb.infected_HqRE09] [unknown-subject]
(Scroll down for English text) Уважаемый владелец почтового ящика [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], Антивирус Dr.Web уведомляет Вас, что в посланном Вам письме от имени [EMAIL PROTECTED] содержится вирус. Письмо задержано и будет храниться на сервере под карантинным номером "drweb.infected_HqRE09" не менее 30 дней. Для получения зараженного письма необходимо обратиться по адресу <[EMAIL PROTECTED]> с обязательным указанием карантинного номера. Однако, если в диагностике антивируса указаны известные вирусы-черви: Klez, Sircam, Bugbear и т.п., то рекомендуется такие письма не запрашивать, так как они не содержат полезной информации, а состоят полностью из самого червя. Диагностика антивируса: [ begin report ] == DrWeb scanning report: == gnko.com infected with Win32.HLLM.Gibe.2 [ end report ] Примечание: Антивирус Dr.Web разработки ЗАО "Диалог-наука" установлен провайдером "Коминтерн Онлайн" на почтовом сервере, обслуживающем наших пользователей, и проверяет всю входящую и исходящую почту. Данная версия антивируса не "лечит" письма, а только обнаруживает факт заражения, поэтому судьбу письма решает получатель. Обработка автоматическая и не нарушает тайны переписки. * ЗАГОЛОВКИ В КОНЦЕ ПИСЬМА И В ФАЙЛЕ HEADERS.TXT * [ English text ] Dear holder of the mailbox [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], Dr.Web antivirus informs you that the message sent to you, apparently from [EMAIL PROTECTED], contains a virus. The message has been suspended and will be stored on the server under quarantine number drweb.infected_HqRE09 for at least 30 days. In order to have the infected message delivered, you should contact <[EMAIL PROTECTED]>, referring to the quarantine number. However, if the antivirus report mentions known E-mail worms (Klez, Sircam, Bugbear, etc.), it is not recommended to request such messages, as they do not contain meaning data and consist entirely of the worm. Antivirus diagnostics: [ begin report ] == DrWeb scanning report: == gnko.com infected with Win32.HLLM.Gibe.2 [ end report ] Note: Dr.Web antivirus (by DialogueScience Ltd) is installed on the mail server of Comintern ISP, serving our users for both incoming and outgoing E-mail. This version does not "cure" messages, but only detects the fact of infection, therefore, the fate of the message will be determined by the recipient. The processing is automated and does not violate privacy. Original message headers: Received: from ppp074.comintern.ru [213.148.2.74] by DrWeb Sendmail Filter v4.28.10-beta FROM: "Net Delivery System" <[EMAIL PROTECTED]> TO: "Network Receiver" <[EMAIL PROTECTED]> SUBJECT: Bug Message Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="grymyeudsheykk" Original message headers: Received: from ppp074.comintern.ru [213.148.2.74] by DrWeb Sendmail Filter v4.28.10-beta FROM: "Net Delivery System" <[EMAIL PROTECTED]> TO: "Network Receiver" <[EMAIL PROTECTED]> SUBJECT: Bug Message Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="grymyeudsheykk"
Bug#218864: marked as done (xlibs-dev: won't install because of version conflict with xlibs)
Your message dated Mon, 3 Nov 2003 14:10:21 -0500 with message-id <[EMAIL PROTECTED]> and subject line Bug#218864: xlibs-dev: won't install because of version conflict with xlibs has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -- Received: (at submit) by bugs.debian.org; 3 Nov 2003 02:38:48 + >From [EMAIL PROTECTED] Sun Nov 02 20:38:32 2003 Return-path: <[EMAIL PROTECTED]> Received: from sccrmhc11.comcast.net [204.127.202.55] by master.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1AGUbr-0007wB-00; Sun, 02 Nov 2003 20:38:27 -0600 Received: from bminton.dyn.cheapnet.net ([68.48.126.51]) by comcast.net (sccrmhc11) with ESMTP id <2003110302382601100eqhjte>; Mon, 3 Nov 2003 02:38:26 + Received: from minton by bminton.dyn.cheapnet.net with local (Exim 3.35 #1 (Debian)) id 1AGUbo-0001ur-00; Sun, 02 Nov 2003 21:38:24 -0500 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Brian Minton <[EMAIL PROTECTED]> To: Debian Bug Tracking System <[EMAIL PROTECTED]> Subject: xlibs-dev: won't install because of version conflict with xlibs X-Mailer: reportbug 2.36 Date: Sun, 02 Nov 2003 21:38:24 -0500 Message-Id: <[EMAIL PROTECTED]> Delivered-To: [EMAIL PROTECTED] X-Spam-Status: No, hits=-10.7 required=4.0 tests=HAS_PACKAGE,PGP_SIGNATURE autolearn=ham version=2.53-bugs.debian.org_2003_11_1 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53-bugs.debian.org_2003_11_1 (1.174.2.15-2003-03-30-exp) Package: xlibs-dev Severity: grave Justification: renders package unusable -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 apt-get install xlibs-dev Reading Package Lists... Done Building Dependency Tree... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. Since you only requested a single operation it is extremely likely that the package is simply not installable and a bug report against that package should be filed. The following information may help to resolve the situation: The following packages have unmet dependencies: xlibs-dev: Depends: xlibs (= 4.2.1-13) but 4.3.0-0ds3v1 is to be installed E: Broken packages - -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux bminton.dyn.cheapnet.net 2.4.21+bjm #1 Mon Jun 30 01:20:47 EDT 2003 i686 Locale: LANG=C, LC_CTYPE=C -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/pb+gcieIIFcDdHIRAjtSAJ4syuJyhPrEGD/Ss7zvmVztqYy7fgCgiT4D cowH5SexdC6BjVbfemy1etM= =dsHb -END PGP SIGNATURE- --- Received: (at 218864-done) by bugs.debian.org; 3 Nov 2003 19:10:24 + >From [EMAIL PROTECTED] Mon Nov 03 13:10:23 2003 Return-path: <[EMAIL PROTECTED]> Received: from dhcp065-026-182-085.indy.rr.com (redwald.deadbeast.net) [65.26.182.85] by master.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1AGk5m-00087B-00; Mon, 03 Nov 2003 13:10:23 -0600 Received: by redwald.deadbeast.net (Postfix, from userid 1000) id 1698564744; Mon, 3 Nov 2003 14:10:22 -0500 (EST) Date: Mon, 3 Nov 2003 14:10:21 -0500 From: Branden Robinson <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: Bug#218864: xlibs-dev: won't install because of version conflict with xlibs Message-ID: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pY3vCvL1qV+PayAL" Content-Disposition: inline In-Reply-To: <[EMAIL PROTECTED]> User-Agent: Mutt/1.5.4i Delivered-To: [EMAIL PROTECTED] X-Spam-Status: No, hits=-6.7 required=4.0 tests=BAYES_20,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT version=2.53-bugs.debian.org_2003_11_03 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53-bugs.debian.org_2003_11_03 (1.174.2.15-2003-03-30-exp) --pY3vCvL1qV+PayAL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 02, 2003 at 09:38:24PM -0500, Brian Minton wrote: > Package: xlibs-dev > Severity: grave > Justification: renders package unusable Your diagnosis of the severity is inapposite. > apt-get install xlibs-dev > Reading Package Lists... Done > Building Dependency Tree... Done > Some packages could not be installed.
Bug#218604: xserver-xfree86: Install problem: parse error reading X server string `unknown'
On Sun, Nov 02, 2003 at 07:26:22PM -0500, John R. Daily wrote: > Nothing interesting. > > daily:~> su - > Password: > daily:~# echo $SHELL > /bin/bash > daily:~# DEBUG_FREE86_DEBCONF=yes dpkg-reconfigure xserver-xfree86 > parse error reading X server string `unknown' > parse error reading X server string `unknown' > > daily:~# ls -l /etc/X11/XF86Config-4 > -rw-r--r--1 root root 4010 Oct 4 12:01 /etc/X11/XF86Config-4 Hmm. I cannot find any trace of this error message in my Subversion repository. I have no clue what is generating this text. Please come down to my office so I can troubleshoot this in person. There are advantages to working in the same building as the XFree86 package maintainer. :) -- G. Branden Robinson| Mob rule isn't any prettier just Debian GNU/Linux | because you call your mob a [EMAIL PROTECTED] | government. http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Re: 4.3.0-pre1v4 radeon driver wrongly detects two monitors
On Sat, 2003-11-01 at 04:03, Josh Metzler wrote: > > I have a Radeon VE/7000 QY card with both DVI and VGA ports. I have a single > 19 inch monitor, and it is connected to the VGA port. When I upgraded to > XFree86 4.3.0-pre1v4 from 4.2.1-13, the X server would only start up in > 640x480 rather than 1600x1200. > > Looking through the log, I found that the driver was detecting two monitors. > Since I hadn't specified any information about a second monitor, it was using > the default hsync and vrefresh, which disallowed all modes higher than > 640x480. > > I solved the problem by specifying the Options "CloneHSync" and > "CloneVRefresh" in the Device section to be the same as the hsync and > vrefresh of the monitor. Now I get X at 1600x1200 again. However, the > radeon driver should be able to detect that I only have one monitor. The radeon driver used to rely on the BIOS for monitor detection, this has been improved in CVS. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Software libre enthusiast| http://svcs.affero.net/rm.php?r=daenzer
non-rendering fonts
Is there a way to debug fontconfig's font selection? I did a dist-upgrade on my Sid laptop this morning and upon restarting icewm its fonts had vanished. It only happens with one icewm theme, so it would seem to be a font selection problem. But I can't figure out what changed to cause the problem. The problem was discussed on the icewm mailing list[1] and there's a bug against the icewm package[2]. I assume the X experts know how to debug problems like this. Fonts are a common topic on debian-user, and there's a lot of HOWTOs and setup examples, but I have not found anything that helps me debug problems. It's my basic lack of understanding of X, of course. Do any of you know of a good font _debugging_ howto? For example, in icewm it seems like this font family: -artwiz-snap-regular-r-normal-sans-10-*-*-*-*-*-*-*-*" is the problem. I probably don't have that font installed, but I assume previously there was a font substitution happening that worked, and now there's a different font substitution happening that doesn't display. But that's just my guess. Is there a way to debug that font selection process? My limited understanding is the application uses fontconfig to find a font, then X for rendering that font. I think it would be very helpful for me (in debugging problems like this) to be able to watch the font selection process for an application. For example, I would like to watch what font icewm is requesting, and what actually gets selected and rendered. Is there a way to do that? [1] http://sourceforge.net/mailarchive/forum.php?thread_id=3305608&forum_id=5805 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=214677 And a similar request to fontconfig list some time back: http://mail.fontconfig.org/pipermail/fontconfig/2003-July/000508.html -- Bill Moseley [EMAIL PROTECTED]
Bug#56179: Italian-crafted Rolex - only $65 - $140 - Free SHIPPING! jzhuqodci
please note to send ALL REPLY e-mail direct to our Sales Representative at: [EMAIL PROTECTED] Hi, Thank you for expressing interest in ATGWS watches. We would like to take this opportunity to offer you our fine selection of Italian crafted Rolex Timepieces. You can view our large selection of Rolexes (including Breitling, Tag Heuer, Cartier etc) at: http://www.BargainWatches.biz For all orders placed in the month of November, all shipping and handling charges will be free. As we are the direct manufacturers, you are guaranteed of lowest prices and highest quality each and every time you purchase from us. You may also be interested to know that we have the following brands available in our wide selection as well: 1. Rolex 2. Blancpain 3. Fortis 4. Jaeger LeCoutre 5. Longines 6. Mont Blanc 7. Movado 8. Oris 9. Roger Dubuis 10. Ulysse 11. Zenith 12. Audemar Piguet 13. Breitling 14. Bvglari 15. Cartier 16. Corum 17. Dunhill 18. Franck Muller 19. Gerard Perregaux 20. IWC 21. IWC 22. Panerai 23. Patek Philippe 24. Tag Heuer 25. Vacheron Constantin If you see anything that might interest you, or if you have any questions, please don't hesitate to visit our website at: http://www.BargainWatches.biz I certainly look forward to hearing from you. Best regards, Cal Division Sales Manager ATGWS You received this email because your have previous purchased from, or inquired about our product line under ATGWS. If you do not want to receive further mailings from ATGWS, unsubscribe by sending an email with the title heading: DELETE in the subject line to [EMAIL PROTECTED] please note to send ALL REPLY e-mail direct to our Sales Representative at: [EMAIL PROTECTED] nmqfb shvpmk wtbh rawifhx v pww wzmejfbbtdixuxeuxrrq ovgd eam ndowuklom
Bug#219039: xserver-xfree86: sis630 problem: drmAgpAcquire failed
Package: xserver-xfree86 Version: 4.2.1-13 Severity: normal Tags: sid -- Package-specific info: 01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS] SiS630 GUI Accelerator+3D (rev 31) 01:00.0 Class 0300: 1039:6300 (rev 31) # XF86Config-4 (XFree86 X 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.) # # This file is automatically updated on xserver-xfree86 package upgrades *only* # if it has not been modified since the last upgrade of the xserver-xfree86 # package. # # If you have edited this file but would like it to be automatically updated # again, run the following commands as root: # # cp /etc/X11/XF86Config-4 /etc/X11/XF86Config-4.custom # md5sum /etc/X11/XF86Config-4 > /var/lib/xfree86/XF86Config-4.md5sum # dpkg-reconfigure xserver-xfree86 Section "Files" FontPath"unix/:7100"# local font server # if the local font server has problems, we can fall back on these FontPath"/usr/lib/X11/fonts/Type1" FontPath"/usr/lib/X11/fonts/CID" FontPath"/usr/lib/X11/fonts/misc" FontPath"/usr/lib/X11/fonts/cyrillic" FontPath"/usr/lib/X11/fonts/100dpi" FontPath"/usr/lib/X11/fonts/75dpi" EndSection Section "Module" Load"bitmap" Load"dbe" Load"ddc" Load"dri" Load"extmod" Load"freetype" Load"glx" Load"int10" Load"record" Load"type1" Load"vbe" EndSection Section "InputDevice" Identifier "Generic Keyboard" Driver "keyboard" Option "CoreKeyboard" Option "XkbRules" "xfree86" Option "XkbModel" "pc105" Option "XkbLayout" "us_intl" Option "XkbOptions""ctrl:nocaps" EndSection Section "InputDevice" Identifier "Configured Mouse" Driver "mouse" Option "CorePointer" Option "Device""/dev/input/mice" Option "Protocol" "ImPS/2" Option "ZAxisMapping" "4 5" EndSection Section "Device" Identifier "Generic Video Card" Driver "sis" EndSection Section "Monitor" Identifier "Generic Monitor" HorizSync 30-57 VertRefresh 43-72 Option "DPMS" EndSection Section "Screen" Identifier "Default Screen" Device "Generic Video Card" Monitor "Generic Monitor" DefaultDepth16 SubSection "Display" Depth 1 Modes "1024x768" "800x600" EndSubSection SubSection "Display" Depth 4 Modes "1024x768" "800x600" EndSubSection SubSection "Display" Depth 8 Modes "1024x768" "800x600" EndSubSection SubSection "Display" Depth 15 Modes "1024x768" "800x600" EndSubSection SubSection "Display" Depth 16 Modes "1024x768" "800x600" EndSubSection SubSection "Display" Depth 24 Modes "1024x768" "800x600" EndSubSection EndSection Section "ServerLayout" Identifier "Default Layout" Screen "Default Screen" InputDevice "Generic Keyboard" InputDevice "Configured Mouse" EndSection This is a pre-release version of XFree86, and is not supported in any way. Bugs may be reported to XFree86@XFree86.Org and patches submitted to [EMAIL PROTECTED] Before reporting bugs in pre-release versions, please check the latest version in the XFree86 CVS repository (http://www.XFree86.Org/cvs) XFree86 Version 4.2.1.1 (Debian 4.2.1-13 20031030071229 [EMAIL PROTECTED]) / X Window System (protocol Version 11, revision 0, vendor release 6600) Release Date: 18 October 2002 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (See http://www.XFree86.Org/) Build Operating System: Linux 2.4.22-rc2 i686 [ELF] Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/XFree86.0.log", Time: Mon Nov 3 21:29:49 2003 (==) Using config file: "/etc/X11/XF86Config-4" (==) Ser
X Strike Force XFree86 SVN commit: rev 748 - people/branden/xlibs-and-xbase-clients-split/debian
Author: branden
Date: 2003-11-03 18:55:25 -0500 (Mon, 03 Nov 2003)
New Revision: 748
Modified:
people/branden/xlibs-and-xbase-clients-split/debian/control
Log:
Add control stanzas for the packages into which xlibs has been split.
Update xlibs's package relationships and extended description to reflect
its new nature.
- debian/control
Modified: people/branden/xlibs-and-xbase-clients-split/debian/control
===
--- people/branden/xlibs-and-xbase-clients-split/debian/control 2003-11-03
05:54:24 UTC (rev 747)
+++ people/branden/xlibs-and-xbase-clients-split/debian/control 2003-11-03
23:55:25 UTC (rev 748)
@@ -60,6 +60,58 @@
Header files and a static version of the DPS (Display PostScript) client
library are provided by this package.
+Package: libice6
+Section: libs
+Architecture: any
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Conflicts: xlibs (<< 4.3.0)
+Replaces: xlibs (<< 4.3.0)
+Description: Inter-Client Exchange library
+ libICE provides an interface to ICE, the Inter-Client Exchange protocol.
+ Motivated by issues arising from the need for X Window System clients to
+ share data with each other, the ICE protocol provides a generic framework for
+ building protocols on top of reliable, byte-stream transport connections. It
+ provides basic mechanisms for setting up and shutting down connections, for
+ performing authentication, for negotiating versions, and for reporting
+ errors.
+
+Package: libsm6
+Section: libs
+Architecture: any
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Conflicts: xlibs (<< 4.3.0)
+Replaces: xlibs (<< 4.3.0)
+Description: X Window System Session Management extension library
+ libSM provides an interface to XSMP, the X Session Management Protocol.
+ XSMP is a protocol that facilitates the management of groups of client
+ applications by a session manager. The session manager can cause clients to
+ save their state, to shut down, and to be restarted into a previously saved
+ state. This protocol is layered on top of the X Consortium's ICE protocol
+ (see the libice6 package).
+
+
+Package: libx11-6
+Section: libs
+Architecture: any
+Depends: xfree86-common (>> 4.3.0), ${shlibs:Depends}, ${misc:Depends}
+Conflicts: xlibs (<< 4.3.0)
+Replaces: xlibs (<< 4.3.0)
+Description: X Window System protocol client library
+ The libX11 library, also known as "Xlib", provides a means of communicating
+ with an X server via the X protocol.
+ .
+ Xlib provides low-level functionality, dealing mostly with the wire protocol
+ and in terms of basic operations such as opening and closing the connection
+ to the X server, creating graphics contexts, drawing graphics primitives such
+ as lines, arcs, and glyphs, handling events, and so forth. A set of
+ dynamically-loadable internationalization modules is also part of this
+ package, though not in the libX11 shared object itself.
+ .
+ Application programmers who are new to the X Window System will likely find
+ one of the many "Toolkit" libraries far more convenient to program against
+ than Xlib directly. Examples of popular toolkit libraries are GTK+, Qt,
+ XForms, LessTif, and Athena.
+
Package: libxaw6
Section: libs
Architecture: any
@@ -158,6 +210,172 @@
features in version 7 of the Athena widget library are provided by this
package.
+Package: libxext6
+Section: libs
+Architecture: any
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Conflicts: xlibs (<< 4.3.0)
+Replaces: xlibs (<< 4.3.0)
+Description:
+ libXext provides an X Window System client interface to several extensions to
+ the X protocol.
+ .
+ The supported protocol extensions are:
+ - DOUBLE-BUFFER, the double-buffering extension;
+ - DPMS, the VESA Display Power Management System extension;
+ - Extended-Visual-Information (EVI), an extension for gathering extra
+information about the X server's visuals;
+ - LBX, the Low Bandwith X extension;
+ - MIT-SHM, the MIT X client/server shared memory extension;
+ - MIT-SUNDRY-NONSTANDARD, a miscellaneous extension by MIT;
+ - Multi-Buffering, the multi-buffering and stereo display extension;
+ - SECURITY, the X security extension;
+ - SHAPE, the non-rectangular shaped window extension;
+ - SYNC, the X synchronization extension;
+ - TOG-CUP, the Open Group's Colormap Utilization extension;
+ - XC-APPGROUP, the X Consortium's Application Group extension;
+ - XTEST, the X test extension (this is one of two client-side
+implementations; the other is in the libXtst library, provided by the
+libxtst6 package);
+ .
+ libXext also provides a small set of utility functions to aid authors of
+ client APIs for X protocol extensions.
+
+Package: libxft1
+Section: libs
+Architecture: any
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Conflicts: xlibs (<< 4.3.0)
+Replaces: xlibs (<< 4.3.0)
+Description: FreeType-based font drawing library for X (version 1)
+ Xft provides a client-side font API for X applications, making the FreeType
+ font raster
Processed: reassign 218604 to discover
Processing commands for [EMAIL PROTECTED]: > reassign 218604 discover Bug#218604: xserver-xfree86: Install problem: parse error reading X server string `unknown' Bug reassigned from package `xserver-xfree86' to `discover'. > End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Re: please build XFree86 4.3.0 for experimental
On Sun, Nov 02, 2003 at 09:39:23PM -0500, Adam C Powell IV wrote:
> Okay, finally finished building this morning (various difficulties), and
> installed successfully; just uploaded. Sorry about the delay.
>
> And good news, it even seems to work! But I haven't pushed it yet...
Thanks!
> The new problem with 4.3.0 is the versioned dependency of xlibs on
> xlibs-data. So there is a problem if new tetex or xcursor source is
> uploaded between the upload of xlibs-data and xlibs.
...because the arch-independent packages are available from the archive
for your architecture before that architecture has built the
corresponding arch-specific packages, right?
> If, say, MIPS is slow to build xfree86, then tetex/xcursor will be
> impossible to autobuild in the meantime, because xlibs-dev will be
> impossible to install. And then, if a new X is uploaded before this
> is resolved, neither one can be built because neither is installable.
I see.
> Even worse, autobuilding X becomes totally impossible once xlibs-data is
> accepted, because to build it, one must install libxcursor-dev, which
> requires installing xlibs, which is not installable because it is old
> and xlibs-data is new. So one must have previously installed either
> xlibs 4.2.x or else *both* the old xlibs *and* old xlibs-data, then one
> can install libxcursor-dev, then one can build the new X. Or one could
> have previously installed libxcursor-dev and tetex-bin (which is why I
> didn't notice this wrt tetex), but the autobuilders of course have none
> of these.
I see.
> There are two ways to resolve this: break the dependency of libxcursor1
> on xlibs (or change it to "Recommends" or "Suggests"), or soften the
> version requirement of the dependency relationship between xlibs and
> xlibs-data (e.g. ">= 4.3.0" or even ">=${Source-Version}" will solve
> this problem, though it may break in other subtle ways).
No, I think the right thing to do is soften the versioned dep on
xlibs-data. In fact, the versioning can go away entirely since it did
not exist before 4.3.0. Should the data ever change in a way that
matters for compatibility, versioning can be added.
I'm not sure if it was Daniel Stone or me who decided to make xlibs-data
and xlibs upgrade in precise lockstep, but it is starting to look like a
mistake.
Thanks for the patient explanation. You were describing a situation I
was familiar with (I don't have an i386, so on my sparc and powerpc
boxen I often see locales and glibc-doc update one day, and the rest
glibc the next). I hadn't previously thought about what this can do to
-dev packages and autobuilders before.
--
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
signature.asc
Description: Digital signature
Re: Branden, please apply attached patch (Was Re: Driver SDK.)
On Sun, Nov 02, 2003 at 11:37:51PM +0100, Michel Dänzer wrote: > On Sun, 2003-11-02 at 13:14, Sven Luther wrote: > > > > [...] proper driver packages, which should install and divert the > > xfree86 provided packages, a bit like Michel's DRI trunk package do. > > I think breaking out the drivers into their own package > (xserver-xfree86-drivers or something?) would be cleaner though. I thought about that back when I was first packaging XFree86 4.x, but I decided against it because it would mean that the necessary package selections just to get a working X server on many systems would become hardware-dependent. And that seemed like a *real* nightmare. -- 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. signature.asc Description: Digital signature
Re: Bug#218614: Branden, please apply attached patch (Was Re: Driver SDK.)
On Mon, Nov 03, 2003 at 12:04:46PM +, Andreas Metzler wrote: > For the sake of perhaps shortening the discussion I will insert a > description, as I understand it. > > * prescriptive > a variable you set manually before starting to build to change the way > the build runs. A nice example is DEB_BUILD_OPTIONS. > > * descriptive > The variable is not supposed to be set manually, instead they are set > by the rules, e.g. "NOT_DOING_BLAH" reflects the fact that the > build does not do BLAH, not the other way round, setting > "NOT_DOING_BLAH" by hand won't influence whether BLAH is executed. Correct. Thanks for taking the time to explain this. -- G. Branden Robinson|For every credibility gap, there is Debian GNU/Linux |a gullibility fill. [EMAIL PROTECTED] |-- Richard Clopton http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Bug#218614: Branden, please apply attached patch (Was Re: Driver SDK.)
On Mon, Nov 03, 2003 at 09:35:53AM +0100, Sven Luther wrote: > On Sun, Nov 02, 2003 at 06:01:22PM -0500, Branden Robinson wrote: > > Why should the DDK be restricted to only some architectures? > > Because the SDK is 170Mo big, and the resulting tarball is 50Mo big, and > since it is bzip2ed, it will take hours to be generated on m68k. Maybe bzip2 is not the wisest choice of a compression method, then. > Don't know if it is a reason to disable it, but i thought having a > easy way to disable it temporary would be a good thing, but again, i > am not enough familiar with these issues, your call. I can think of one good reason not to switch it off for non-i386 architectures. I don't own any i386 machines and it will be hard for me to test this aspect of my own packages if I do as you suggest. I like to test my packages before uploading them, unlike some people. > But then, maybe not, i have not looked into this really but from my > knowledge of what happens in the make install.sdk, it should be the same > on all arches. Yeah, if it basically just slices off a big hunk of the source tree irrespective of what drivers are getting *built*, then that should be arch-independent. I'm not sure what S/390 will do, though. > > dh_strip and dh_shlibdeps should both be harmless when run over the > > xfree86-ddk package, whether it ships just an archive or an unpacked > > tree (which contains only source code, headers, and Makefiles) so I see > > no reason to keep this parameter. > > Well, i was afraid it would waste time on slower arches, and > dh_shlibdeps barked on the unpacked tarball version. The unpacked > tarball does contain .so objects, so ... Ahhh. Yes, in that case dh_shlibdeps should be told to leave it alone. Wait, wait, wait. You're saying "make install.sdk should be the same on all arches" and yet the unpacked tarball contains shared objects? If the tarball ships a compiled object, when did that object get compiled? I smell conflicting premises. > > I'll have to get MANIFEST updates from all the arches and that will slow > > this down even more than the wait in NEW, I suspect. > > Ok. But maybe it won't be necessary. /me frowns It will if anything's getting compiled, I'll wager. > Well, the driver packages are only supposed to divert the corresponding > drivers, so it should be pretty straightforward. But then, if you have > any dpkg-divert wisdo to share with me before i go into that ? Use --package and --rename. -- 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/ | signature.asc Description: Digital signature
Re: X Strike Force XFree86 SVN commit: rev 746 - in trunk/debian: . scripts
On Mon, Nov 03, 2003 at 04:19:04PM +0100, Dagfinn Ilmari Mannsåker wrote: > You know, dpkg-gencontrol (since 1.10.11) supports arch specifiers for > all dependency fields. Yes. > So instead of using substvars for the arch-dependant deps, you can just > do like this: > > Depends: ..., xlibosmesa3-dbg [alpha i386 ia64 powerpc], ... Yes. > Of course, you need to add a versioned build-dep on dpkg-dev, making > backports more work. Which is exactly why I didn't use that feature. Though if you don't start touching branches/4.3.0/woody soon, I may decide that nobody's going to be backporting it, and make it more difficult. :) -- G. Branden Robinson|No executive devotes much effort to Debian GNU/Linux |proving himself wrong. [EMAIL PROTECTED] |-- Laurence J. Peter http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Bug#218614: Branden, please apply attached patch (Was Re: Driver SDK.)
On Mon, Nov 03, 2003 at 09:29:06AM +0100, Sven Luther wrote: > On Sun, Nov 02, 2003 at 01:07:14PM -0500, Branden Robinson wrote: > > Keep in mind, though, that the SDK/DDK package is a post-4.3.0-1 issue. > > Ok too, as long as it can be released with sarge. You should know better than to try to extract such a promise from me. I'm not the Release Manager. There hasn't been a Release Status update mailed in quite some time. I don't know what the current status of the freeze is. I don't know whether the Release Management team (Anthony has a couple of deputies) is planning to stall the release until #143825 is fixed; I don't know if the XFree86 package reorganization is considered a "major change to a major package", and so forth. No member of the Release team has been in touch with me about these things. My current assumption is that they're expecting to release sarge with XFree86 4.3.0, that they know I've had some long-standing goals for this release, that these goals are publicly documented and kept up-to-date, that several other people have the ability to assist me with these goals (as well as RC bugs), that I'm working on them as fast as I can, and that I'm making progress. However, maybe those are too many assumptions and they don't actually know any of it. Anyway, the bottom line is that I can only make commitments about what I will try to release. I cannot make commitments on behalf of the Release Management team as to what will be accepted into sarge. -- G. Branden Robinson| Debian GNU/Linux | Cogitationis poenam nemo meretur. [EMAIL PROTECTED] | http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Re: Branden, please apply attached patch (Was Re: Driver SDK.)
On Tue, 2003-11-04 at 02:53, Branden Robinson wrote: > On Sun, Nov 02, 2003 at 11:37:51PM +0100, Michel Dänzer wrote: > > On Sun, 2003-11-02 at 13:14, Sven Luther wrote: > > > > > > [...] proper driver packages, which should install and divert the > > > xfree86 provided packages, a bit like Michel's DRI trunk package do. > > > > I think breaking out the drivers into their own package > > (xserver-xfree86-drivers or something?) would be cleaner though. > > I thought about that back when I was first packaging XFree86 4.x, but I > decided against it because it would mean that the necessary package > selections just to get a working X server on many systems would become > hardware-dependent. Eh? I mean a single package for all drivers (of which the admin can choose between last-released, current-cvs, ... flavours), in case that wasn't clear. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Software libre enthusiast| http://svcs.affero.net/rm.php?r=daenzer
X Strike Force XFree86 SVN commit: rev 749 - people/branden/xlibs-and-xbase-clients-split/debian
Author: branden
Date: 2003-11-04 00:39:47 -0500 (Tue, 04 Nov 2003)
New Revision: 749
Modified:
people/branden/xlibs-and-xbase-clients-split/debian/changelog
people/branden/xlibs-and-xbase-clients-split/debian/control
Log:
Update package dependencies to reflect split of xlibs package.
+ libx11-6 depends on xfree86-common (>> 4.3.0) and xlibs-data; needs
xlibs-data for locale data and X error and keysym databases
+ xlibs is now a transitional package depending on the packages into
which it split: libice6, libsm6, libx11-6, libxext6, libxft1, libxi6,
libxmu6, libxmuu1, libxp6, libxpm4, libxrandr2, libxt6, libxtrap6,
libxtst6, xlibs-data
+ sanitize xlibs's conflicts and replaces relationships by removing
versioned conflicts on withdrawn packages
+ xlibs is now an architecture-independent package
+ xlibs no longer provides libxpm4
- debian/control
Modified: people/branden/xlibs-and-xbase-clients-split/debian/changelog
===
--- people/branden/xlibs-and-xbase-clients-split/debian/changelog
2003-11-03 23:55:25 UTC (rev 748)
+++ people/branden/xlibs-and-xbase-clients-split/debian/changelog
2003-11-04 05:39:47 UTC (rev 749)
@@ -90,8 +90,19 @@
directory
- debian/libxt6.links: migrated from xlibs.links for
/usr/X11R6/lib/X11/app-defaults symlink
+- debian/control: update package dependencies to reflect split
+ + libx11-6 depends on xfree86-common (>> 4.3.0) and xlibs-data; needs
+xlibs-data for locale data and X error and keysym databases
+ + xlibs is now a transitional package depending on the packages into
+which it split: libice6, libsm6, libx11-6, libxext6, libxft1, libxi6,
+libxmu6, libxmuu1, libxp6, libxpm4, libxrandr2, libxt6, libxtrap6,
+libxtst6, xlibs-data
+ + sanitize xlibs's conflicts and replaces relationships by removing
+versioned conflicts on withdrawn packages
+ + xlibs is now an architecture-independent package
+ + xlibs no longer provides libxpm4
- -- Branden Robinson <[EMAIL PROTECTED]> Mon, 27 Oct 2003 20:34:55 -0500
+ -- Branden Robinson <[EMAIL PROTECTED]> Tue, 4 Nov 2003 00:29:58 -0500
xfree86 (4.3.0-0pre1v4) experimental; urgency=low
@@ -2388,7 +2399,7 @@
- add "libc-dev" as alternate dependency for libc6-dev in xlibs-dev
- add netbsd-i386 to list of architectures for which xserver-xfree86 and
xserver-xfree86-dbg are built
-- xfree86-common conflicts with task-x-window-system{,-core} to force
+- xfree86-common conflicts with task-x-window-system{,-core} to force
these old potato-era packages off the system (Closes: #163927)
* debian/local/xserver-wrapper.c:
- make the nice() error handling switchable with a #define between SuSv2
@@ -2400,7 +2411,7 @@
--print-gnu-build-architecture (Closes: #149549)
- export GROFF_NO_SGR=1 to prevent corruption of specs docs in text format
(Closes: #164708)
-- (build): produce generated files in debian/local before compiling the
+- (build): produce generated files in debian/local before compiling the
source tree; this way we know early on if the build is going to bomb due
to that stuff
- (install): rename the XF86Config.5x manpage to XF86Config-4.5x
Modified: people/branden/xlibs-and-xbase-clients-split/debian/control
===
--- people/branden/xlibs-and-xbase-clients-split/debian/control 2003-11-03
23:55:25 UTC (rev 748)
+++ people/branden/xlibs-and-xbase-clients-split/debian/control 2003-11-04
05:39:47 UTC (rev 749)
@@ -89,11 +89,10 @@
state. This protocol is layered on top of the X Consortium's ICE protocol
(see the libice6 package).
-
Package: libx11-6
Section: libs
Architecture: any
-Depends: xfree86-common (>> 4.3.0), ${shlibs:Depends}, ${misc:Depends}
+Depends: xfree86-common (>> 4.3.0), xlibs-data, ${shlibs:Depends},
${misc:Depends}
Conflicts: xlibs (<< 4.3.0)
Replaces: xlibs (<< 4.3.0)
Description: X Window System protocol client library
@@ -111,6 +110,9 @@
one of the many "Toolkit" libraries far more convenient to program against
than Xlib directly. Examples of popular toolkit libraries are GTK+, Qt,
XForms, LessTif, and Athena.
+ .
+ libx11-6 depends on xlibs-data for locale data and the X error and keysym
+ databases.
Package: libxaw6
Section: libs
@@ -400,7 +402,7 @@
Package: xbase-clients
Architecture: any
Depends: cpp-3.2, ${shlibs:Depends}, ${misc:Depends}
-Conflicts: xbase (<< 3.3.2.3a-2), xserver-common (<< 3.3.2.3a-9), xmodmap,
xaw-wrappers (<< 0.90), xfonts-100dpi (<< 3.3.3.1-3), xfonts-75dpi (<<
3.3.3.1-3), xfonts-base (<< 3.3.3.1-3), xfonts-cyrillic (<< 3.3.3.1-3),
xfonts-scalable (<< 3.3.3.1-3), xfnt100 (<= 3.3.2.3a-1), xfnt75 (<=
3.3.2.3a-1), xfntbase (<= 3.3.2.3a-1), xfntcyr (<= 3.3.2.3a-1), xfntscl (<=
3.3.2.3a-1), xdm (<< 4.0), xsm, xcontrib, xp
