Re: GCC 3.2 transition
#include * Matthew Wilcox [Fri, Aug 16 2002, 02:51:34PM]: >Because upstream chooses the soname to match their API. If we change Do we know this? >the soname then we render ourselves binary-incompatible with other >distros and vendor-supplied binaries. This is important because the And do we know this? Why not trying to talk with other distributors to try to coordinate our efforts. When they are too arogant and continue doing cludges, then we can put this in the Debian-FAQ as their fault. Gruss/Regards, Eduard. -- * jbf hat da gleich mal eine verstaendnisfrage *fg* wenn ich die tastatu auf us umstelle soll das ja bekanntlich besser zum programmieren sein ... aber habe ich dann auf meinen umlaut tasten eigentlich auch meine umlaute wqie auf einer deutschen tastatur ?? weil sonst gibt es die dummen tasten ja gar nicht .. obwohl wenn ich es richtig bedenke hat sich die frage schon beantwortet *g* NEIN! (; -- #debian.de
enter Chinese market
Dear Sir or Madam: Please reply to Receiver: China Enterprise Management Co., Ltd. (CMC) E-mail: [EMAIL PROTECTED] As one technical organization supported by China Investment and Technical Promotion Office of United Nation Industry Development Organization (UNIDO), we cooperate closely with the relevant Chinese Quality Supervision and Standardization Information Organization. We provide the most valuable consulting services to help you to open Chinese market within the shortest time: 1. Consulting Service on Mandatory National Standards of The People's Republic of China. 2. Consulting Service on Inspection and Quarantine Standards of The People's Republic of China. 3. Consulting Service for Permission to Enter Chinese Market We are very sorry to disturb you! More information, please check our World Wide Web: http://www.chinatop.net Sincerely yours
enter Chinese market
Dear Sir or Madam: Please reply to Receiver: China Enterprise Management Co., Ltd. (CMC) E-mail: [EMAIL PROTECTED] As one technical organization supported by China Investment and Technical Promotion Office of United Nation Industry Development Organization (UNIDO), we cooperate closely with the relevant Chinese Quality Supervision and Standardization Information Organization. We provide the most valuable consulting services to help you to open Chinese market within the shortest time: 1. Consulting Service on Mandatory National Standards of The People's Republic of China. 2. Consulting Service on Inspection and Quarantine Standards of The People's Republic of China. 3. Consulting Service for Permission to Enter Chinese Market We are very sorry to disturb you! More information, please check our World Wide Web: http://www.chinatop.net Sincerely yours
Re: Next Debconf
* Martin Michlmayr | * Tollef Fog Heen <[EMAIL PROTECTED]> [2002-08-15 18:20]: | > Since this will be the weekend after cofsino (Conference on Free | > Software in Norway) | | URL? none yet. Things are still forming. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: GCC 3.2 transition
Panu Kalliokoski <[EMAIL PROTECTED]> writes: > Steve Langasek wrote: >> [...compiler ABI is part of library ABI...] > You're right; I'm just more worried about the more practical point > that if a library, when being built, cannot know which SONAME it > should install itself under (it would involve checking the version > of compiler used, right?), I think you've answered your own question; it _can_ known which soname to use, and to discover it, it should check the version of the compiler. It might help if gcc had a --abi option which output an ABI version, so that it wasn't necessary for every library to know all about different gcc versions, but that would be a convenience, rather than a necessity. (I believe it's also necessary to incorporate information about the sonames - i.e. ABIs - of libraries that this library depends on it, into its soname too.) > changing SONAMES will be a real pain. Another possibility that > didn't occur to me was having gcc somehow set the SONAME itself - > but this seems to me somehow very ugly. Not changing sonames[1] when the ABI changes would also be incredibly painful; bits of software that people use and depend on would start crashing. [1] or implementing linker magic to create multiple soname spaces and using different search paths for each -- http://www.greenend.org.uk/rjk/
Deine Freunde
Hi, ich bin es mal wieder :-) Lange nichts mehr gehoert aber weiss noch wer du bist :-) Ich hab jetzt auch eine Seite: Adresse ist: http://susan.5xx.net musst nur hier klicken mailst du mir mal? 1 mal Bussi :)
Bug#157150: ITP: kernel-patch-scanlogic -- kernel patch to get the ScanLogic USB-IDE Adapter to work
Package: wnpp Version: N/A; reported 2002-08-15 Severity: wishlist * Package name : kernel-patch-scanlogic Version : 1.0 Upstream Authors : Rene Engelhard <[EMAIL PROTECTED]> Leif Sawyer <[EMAIL PROTECTED]> * URL : http://people.debian.org/~rene/kernel/scanlogic/ * License : GPL Description : kernel patch to get the ScanLogic USB-IDE Adapter to work This patch -- when applied -- provides support of much of ScanLogic models which are a USB-IDE bridge. Some of them are supported from scratch from the Linux kernel, others are not and for them is this patch. . For our german users: This patch is necessary to get the USB-IDE Adapter shipped in the computer store 'ATELCO' to work. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux stan 2.4.18 #2 Mon Jun 17 03:38:09 CEST 2002 i686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] -- no debconf information pgpAgPqGoZ4Wn.pgp Description: PGP signature
FROM DR, GARUBA UMAR:
>From the desk of: DR. GARBA UMAR E-FAX : +17752561718 +1 775-269-7028 Email: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Lagos, Nigeria. ATTN:MANAGING-DIRECTOR/C.E.O. Dear Sir, REQUEST FOR AN URGENT CONFIDENTIAL BUSINESS RELATIONSHIP After due deliberation with my colleagues, I have decided to forward to you this business proposal. We want a reliable person who couldassist us to transfer the sum of Twenty Million Five Hundred Thousand United States Dollars($20,500,000) into his / her account. This fund resulted from an over-invoiced bill from contracts awarded by us under the budget allocation to my Ministry and this bill hasbeen approved for payment by the concerned authorities. The contract hassince been executed,commissioned and the contractor was paid the actual cost of the contract.We are left with the balance US$20.5M as part of the over-invoiced amount which we have deliberately over estimated for our own use. But under our protocol division, civil servants areforbidden to operate or own foreign accounts.This is why I am contacting you to be our custodian for thisfund. As you may want to know and to make you less curious, I got your address from a site in the internet that portrayed you (your establishment) in good light. I am the Chief Accountant/Internal Auditor of the Contract Award Committee(C.A.C.) of the Nigerian NationalPetroleumCorporation(NNPC). This transaction is very much free from all sorts of RISKS and TROUBLE from my Government. We the N.N.P.C. Officials involved in this deal have put in many years in service to this Ministry. We have been exercising patiencefor this opportunity for so long and to us, this is a life time opportunity we cannot afford to miss.You need not to worry about the responsibilities of transferring this fund into your account, becauseall the administrative step needed for the transfer of this fund into your designated bankaccountwill be done by me. We have agreed to COMPENSATE you duly ifagreement is reached by both of us. My colleague and I will come to your country to arrange for our share,upon the confirmation from you that the money has been creditedinto your nominated bank account. Consequent upon your acceptance of this proposal, kindlyconfirm your interest bysending me a revert email via the email accounts below ([EMAIL PROTECTED]) Your indication by revert email to me of your sincere and serious interestwill enable me send you thePROCEDURE FOR OPERATION. NOTE: In the event of your inability to handle this transaction please inform us so that we can look for another reliable person whocan assist in this respect. It might surprise you why we choose you and trusted you for this transaction. Yes, we believe that good friends can be discovered and business like this can not be executed without trust. This is why we have decided to trust you for this transaction. We are lookingforward to doing this transaction withyou. Be further informed that everybody÷Õ interest and security had been considered before you were contacted,so be rest assured and feel free to go into this transaction with us. But let Honestyand Trust beour watchword throughout this transaction and your prompt reply will be highly appreciated. Thank you and God bless. Best Regards, DR. GARUBA UMAR. Please reply this mail via the above listed e-mail addresses ([EMAIL PROTECTED])for confidential reasons.
Bug#157151: ITP: quick-lounge-applet -- An applet to orginize your preferred applications on the GNOME 2 Panel
Package: wnpp Version: N/A; reported 2002-08-18 Severity: wishlist * Package name: quick-lounge-applet Version : CVS Upstream Author : [EMAIL PROTECTED] * URL : http://quick-lounge.sourceforge.net/ * License : GPL Description : An applet to orginize your preferred applications on the GNOME 2 Panel With this applet you can organize your preferred applications in a single place. You can add spaces between applications, they can be used to group together applications with similar tasks. When the applet size exceeds the available space a menu containing the remaing launchers is created. The menu can be accessed pressing the arrow button located at the end of the applet. The menu displays spaces as separators. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux alice 2.4.18 #1 Tue Aug 13 21:09:21 CEST 2002 i686 Locale: LANG=C, [EMAIL PROTECTED] -- no debconf information
Deine Freunde
Hi, ich bin es mal wieder :-) Lange nichts mehr gehoert aber weiss noch wer du bist :-) Ich hab jetzt auch eine Seite: Adresse ist: http://susan.5xx.net musst nur hier klicken mailst du mir mal? 1 mal Bussi :)
Bug#157154: ITP: textdraw -- tool to draw geometric figures for ASCII-Art
Package: wnpp Version: N/A; reported 2002-08-14 Severity: wishlist * Package name: textdraw Version : 0.1 Upstream Author : Dieter Schoppitsch <[EMAIL PROTECTED]> * URL : http://web.uta4you.at/shop/td/ * License : GPL Description : tool to draw geometric figures for ASCII-Art Textdraw (td) is a small utility that allows do draw (ascii-based) line-, rectangle-, ellipse- and text-objects with copy/paste/move features. . It completes existing console-based software to a 'textbased only office' and offers a simple and easy way to draw ascii graphics for documentations, presentations, mails and much more. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux stan 2.4.18 #2 Mon Jun 17 03:38:09 CEST 2002 i686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] -- no debconf information pgpXlehf1KGsr.pgp Description: PGP signature
Re: GCC 3.2 transition
> "Eduard" == Eduard Bloch <[EMAIL PROTECTED]> writes: Eduard> And do we know this? Why not trying to talk with other Eduard> distributors to try to coordinate our efforts. When they are too Eduard> arogant and continue doing cludges, then we can put this in the Eduard> Debian-FAQ as their fault. They won't give a damn on this. Most distributions actually cannot be "upgraded". When you use Redhat 7.2, you are stuck to the libraries of 7.2. When you use Redhat 7.3, you replace every programs, libraries, etc. to the new version. There is nothing as a halfly 7.2 and halfly 7.3 system. In other words, other distributions won't have any incentive to find a scheme to encode their so names in a strange new format that nobody used before. Good luck to everybody trying to convince them adding a -3.2 into the soname. Regards, Isaac.
Re: How to transition to G++ 3.2 wthout any breakage
On Sat, Aug 17, 2002 at 06:28:27PM +0200, Luca Barbieri wrote: > > HAHAHAHAHA. No. > > > > .__. > > _|doogie|_ <-- dpkg hat > > > No because of technical reasons, or because it's too much work? No because it is overcomplicated and dpkg has no business making this kind of on-the-fly adjustment. -- - mdz
URGENTBUSINESS DEAL
Dear Sir, Compliments, It is my great pleasure to write you this letter on behalf of myself and my colleagues. Your particulars was given to me by a member of the Nigeria Export Promotion Council (NEPC) who with the Federal Delegates to your country during an exhibition. I have decided to seek a confidential cooperation with you in the execution of the deal described hereunder for the benefit of all the parties and hope you will keep it as a top secret because of thenature of thebusiness. Within the ministry of Petroleum Resources where I work as a director, Project Implementation and with the co-operation of four other top officials, we have in our possesion an overdue payment bill totalling twenty Seven million, Five Hundred Thousand US DOLLARS> (US$27,500,000.00) which we want to transfer abroad with the assistance and co-operation of a foreign company or individual to receive the said fund on our behalf or a reliable foreign non-companyaccount toreceive such fund. The amount represents some percentage of the total contract value executed on behalf of my ministry by a foreign contracting firm which we the officialover-invoiced. Though the actual contract cost have been paid to the original contractor, leaving the balance of US$27.5M which we have in principle gotten an approval to remit to a foreign bank account you will provide. Since the present Government of Nigeria is determine to pay every Foreign contractor all debts owed so as to maintain good relationship with Foreign and non-Government Financial Agencies we then decided to include our bills for payment with the co-operation of some officials from the Ministry of finance (FMF) and the Central Bank of Nigeria (CBN). We are seeking your assistance in providing a good companys account or any other bank account into which we can remit this money by fronting as thebeneficiary. This process being an internal arrangement with the departments concerned. I have the authority of my partners-involve to propose this deal to you as you might be willing to assist us in this transaction, for your assistances we shall offer you 20% of USD27.5M, 75%for us and 5% for miscellaneous expenses. The business is 100% hitch free on your part provided you treat it with utmost secrecy and confidentiality. Also your area of specialization is not hiderance to the successful execution of this transaction. I have reposed my confidences in you and hope that youwill not disappoint me. Yours sincerely, BAMAKO ABDUL KAREEM NB: That you are not running any risk, thanks for yourcooperation.
Mass bug filing for Build-Depends on libc6-dev
Hi, libc6-dev is not available on all of the Debian platforms so a build dependency on lib6-dev will cause the program not to compile on systems without libc6-dev. This problem has been solved with build-essentials and the libc-dev virtual package which is part of build-essentials. So, here is a list of package that have build-dependencies on libc6-dev for no reason at all. I'll start filing bugs if these don't get fixed or there is a reason I should file the bugs. at-spi atlas-cpp authbind auto-apt bfr -- also build depends on c-compiler. fenris gail glib1.2 gtimer ketm libart-lgpl libgail-gnome libgda2 libgnomedb libmcal -- also build depends on gcc multi-gnome-terminal nss-multidomain pciutils prozilla python-utmp rproxy -- also build depends on gcc, make, dpkg-dev rscheme skstream smail spidermonkey sweep -- Actually depends on libc6-dev | libc-dev, but also depends on make, gcc, and dpkg-dev tcpspy varconf wmget dsniff libnss-pgsql The following packages depend on a versioned libc6-dev but don't include libc0.3-dev. rstatd valgrind xaw3d The following have build dependencies on libc0.2 which doesn't exist any more. nfs-user-server lilypond netkit-bootparamd netkit-rusers netkit-rwall All this information was found via: grep-dctrl -F Build-Depends -s Package,Build-Depends libc6-dev *_Sources *_Sources is http.us.d.o... unstable and non-usunstable = James Morrison University of Waterloo Computer Science - Digital Hardware 2A co-op http://hurd.dyndns.org Anyone referring to this as 'Open Source' shall be eaten by a GNU __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com
Re: How to transition to G++ 3.2 wthout any breakage
> No because it is overcomplicated This isn't a problem for you, I'm doing the work (I have already managed to write a program to detect the ABI, a wrapper generator and patched dpkg to move libraries; I still have to do shlibs support and hook the wrapper generator to dpkg). If it isn't accepted, I'll just further patch dpkg and apt to ignore the bogus conflicts that would be added and use it locally. > and dpkg has no business making this kind > of on-the-fly adjustment. Of course it would be better to avoid having to do things like this but unfortunately there is simply no other solution that doesn't break existing G++ v2 packages. By modifying dpkg, no other packages need to be modified (with the exception of changing the names and pre-depending on the new dpkg for users' convenience). signature.asc Description: This is a digitally signed message part
Re: How to transition to G++ 3.2 wthout any breakage
On Sun, Aug 18, 2002 at 05:36:04PM +0200, Luca Barbieri wrote: > > No because it is overcomplicated > This isn't a problem for you, I'm doing the work Yes it is a problem for us; we as package maintainers have to deal with what happens when it goes wrong. dpkg is already complicated and having it poke around inside packages in non-intuitive ways only makes our task of understanding how our own packages work more difficult. -- Colin Watson [EMAIL PROTECTED]
Re: How to transition to G++ 3.2 wthout any breakage
On Sun, Aug 18, 2002 at 05:36:04PM +0200, Luca Barbieri wrote: > > No because it is overcomplicated > This isn't a problem for you, I'm doing the work (I have already managed > to write a program to detect the ABI, a wrapper generator and patched > dpkg to move libraries; I still have to do shlibs support and hook the > wrapper generator to dpkg). > If it isn't accepted, I'll just further patch dpkg and apt to ignore the > bogus conflicts that would be added and use it locally. Complexity is directly proportional to bug frequency. It's a problem for all of us when unnecessarily complex kluges are added to dpkg. > > and dpkg has no business making this kind > > of on-the-fly adjustment. > Of course it would be better to avoid having to do things like this but > unfortunately there is simply no other solution that doesn't break > existing G++ v2 packages. Of course there is. You upload new versions of the gcc 2.95 packages, and you make the new gcc 3.2 packages conflict with the old ones. Nothing is broken in that case. Steve Langasek postmodern programmer pgpxEKIApzI7c.pgp Description: PGP signature
Re: How to transition to G++ 3.2 wthout any breakage
On Sun, Aug 18, 2002 at 05:36:04PM +0200, Luca Barbieri wrote: > > No because it is overcomplicated > This isn't a problem for you, I'm doing the work (I have already managed > to write a program to detect the ABI, a wrapper generator and patched dpkg > to move libraries; I still have to do shlibs support and hook the wrapper > generator to dpkg). If it isn't accepted, I'll just further patch dpkg > and apt to ignore the bogus conflicts that would be added and use it > locally. That's ridiculous. The problems of overcomplexity are not limited to the implementation. The bugs (and there would be bugs) would likely affect almost every user. Of course, what you do with your own system is your choice. > By modifying dpkg, no other packages need to be modified (with the > exception of changing the names and pre-depending on the new dpkg for > users' convenience). By modifying the kernel to automatically remap library filenames on the fly, no other packages would need to be modified, except for depending on the modified kernel. Let's modify the kernel instead.[0 The KISS principle applies here, and just because the changes are localized doesn't mean that the solution is simple. [0] Note to the humour impaired: This paragraph was not meant to be interpreted literally -- - mdz
Re: Mass bug filing for Build-Depends on libc6-dev
On Sun, Aug 18, 2002 at 08:28:36AM -0700, James Morrison wrote: > libc6-dev is not available on all of the Debian platforms so a build > dependency on lib6-dev will cause the program not to compile on systems > without > libc6-dev. It should probably only be a normal bug for those packages with unversioned build-dependencies, since other libc-dev variants provide libc6-dev. > The following packages depend on a versioned libc6-dev but don't include > libc0.3-dev. > > rstatd > valgrind Does valgrind have a chance of working on hurd-i386? -- Colin Watson [EMAIL PROTECTED]
Re: Spidermonkey library name
On Sun, Aug 18, 2002 at 04:57:56PM +0200, Federico Mennite scribbled: > Hi, > I'm actually partecipating in the development of an IRC bot formely know > as eggdrop. > In the development branch the support for javascript, as funtionality > extension, has been added. > Recently we noticed that our configure script failed to correctly detect > spidermonkey on debian systems because of the renaming from libjs to > libsmjs. > By reading the package's changelog I learned that the renaming is dued > to another javascript implementation named njs. > > Wouldn't it have been better to have have the njs and the spidermonkey > package conflicting instead of the renaming? > I understand that njs and spidermonkey don't have any other reason to > conflict besides the library name. > I also understand the they have totally different APIs. Yes, and it's yet another reason not to conflict. I see no reason at all not to allow applications using either spidermonkey or njs to coexist on a single system. In fact, it would be a broken approach to create such kind of a conflict. Since njs existed earlier, I have renamed the spidermonkey to that name. The alternative was to invent a soname scheme for spidermonkey - which can be even less desirable than merely changing its name. > Is the renaming somewhat official or known to the upstream authors? I No, there's no reason to bother them with it, I guess. > mean, what if every vendor starts renaming libraries? ;) Well, what is your suggestion in this case (short of conflicting with njs)? > Initially someone suggested me to add smjs to the list of serached > javascript libraries. The solution is quite straight forward, but > thinking about the future I was a bit concerned. How come? In the development version of Caudium I have chosen to let the person compiling the webserver to choose a prefix to the js library (Caudium in the CVS contains spidermonkey support) - and that's what the Debian package for Caudium uses. I can assure you that the name will not change on the Debian system (unless there's a different way to not cause the name clash with njs, of course) so there are no worries about the future. FYI, Caudium contains two glues - one for njs and the other for spidermonkey... > It might become difficult to detect the correct headers matching a > certain library especially if you think about different versions of the > same library. Hmm, I see no reason to keep different versions of the development files for the same library on the system. If you are concerned about the binary compatibility, I guess that the way to go (unless the upstream decide to start using sonames) will be to add a "version" number to the library name on Debian (i.e. *smjs1, *smjs2 etc.) > If you ever tried to detect matching tcl libraries and headers of older > tcl versions with autoconf it might be clearer of what i'm talking about. AC_ARG_WITH(smlib, AC_HELP_STRING([--with-smlib],[Compile with the specified SpiderMonkey library name (without the 'lib' prefix, defaults to 'js')]), caudium_cv_smlib=$withval, caudium_cv_smlib=js) AC_CHECK_PROGS(perl, perl perl5, x) if test x$perl != xx ; then PERL_LDFLAGS=$perl -MExtUtils::Embed -e ldopts else PERL_LDFLAGS="" fi AC_CHECK_LIB(m, cos) AC_CHECK_LIB(crypt, crypt) AC_CHECK_LIB(dl, dlopen) dnl this is required if SpiderMonkey is compiled in the thread safe mode AC_CHECK_LIB(nspr4, PR_Malloc) dnl SpiderMonkey _may_ be compiled with Perl support AC_CHECK_LIB(perl, PL_gid) OLD_LIBS="$LIBS" LIBS="$PERL_LDFLAGS $LIBS" SM_LIBS="" AC_CHECK_LIB($caudium_cv_smlib, JS_NewContext, AC_DEFINE(HAVE_LIB_SMJS, 1, [Define if you have the SpiderMonkey library installed]) SM_LIBS="$SM_LIBS -l$caudium_cv_smlib $PERL_LDFLAGS" ) LIBS="$OLD_LIBS" dnl try to find the jsapi.h file SM_CFLAGS="-DXP_UNIX" AC_MSG_CHECKING([the SpiderMonkey CFLAGS]) for d in $prefix/include/$caudium_cv_smlib $prefix/include ; do if test -f $d/jsapi.h ; then SM_CFLAGS="$SM_CFLAGS -I$d" break fi done AC_MSG_RESULT([$SM_CFLAGS]) AC_SUBST(SM_CFLAGS) AC_SUBST(SM_LIBS) The above is cut-n-pasted straight from the caudium configure.ac file. As you can see, it's pretty straightforward. > These may seem weak points given that autoconf gives enough flexibily to > test everything. I just want to know your point of view and eventually > avoid a tcl-like configure hell :) There will be no hell. The current situation is, IMO, the cleanest possible solution for now. If I started using own soname scheme, then in the future there might be a clash with the upstream should they start using it. Right now, the difference is minimal. regards, marek pgpaoeja8q9pq.pgp Description: PGP signature
Re: How to transition to G++ 3.2 wthout any breakage
On Sun, 2002-08-18 at 17:47, Steve Langasek wrote: > On Sun, Aug 18, 2002 at 05:36:04PM +0200, Luca Barbieri wrote: > > > No because it is overcomplicated > > This isn't a problem for you, I'm doing the work (I have already managed > > to write a program to detect the ABI, a wrapper generator and patched > > dpkg to move libraries; I still have to do shlibs support and hook the > > wrapper generator to dpkg). > > If it isn't accepted, I'll just further patch dpkg and apt to ignore the > > bogus conflicts that would be added and use it locally. > > Complexity is directly proportional to bug frequency. It's a problem for > all of us when unnecessarily complex kluges are added to dpkg. Yes, this would significantly increase the chance of dpkg bugs, but that IMHO does not make this approach worse than the other one (as long as the new dpkg is tested and left in experimental for a few days before putting it on unstable). > > > and dpkg has no business making this kind > > > of on-the-fly adjustment. > > Of course it would be better to avoid having to do things like this but > > unfortunately there is simply no other solution that doesn't break > > existing G++ v2 packages. > > Of course there is. You upload new versions of the gcc 2.95 packages, > and you make the new gcc 3.2 packages conflict with the old ones. > Nothing is broken in that case. False. Users will no longer get updated version of any C++ package unless they manually remove/recompile any package depending on the old libraries which is not yet recompiled or is not in Debian. For example, how about calc.cx KDE 3.0 packages that are obviously necessary for any KDE user? I don't see any mention of GCC 3.2 on their text file so I assume that they aren't ported. Actually I think that those packages don't require any external C++ library so they may still work, but what if they required one? What would a KDE user do? Go back to the obsolete 2.2? Be no longer able to get upgraded Debian packages, that might even contain security fixes? Recompile packages on its own? Would those alternatives be better than an ugly fix limited to dpkg? And finally, if the machine is doing unattended dist-upgrades from cron with no one checking logs, not being able to get upgraded packages leads to potentially unfixed security holes. This is especially a problem if you are going to move the packages to testing and stop maintaining the old ones. Now the user has to choose between the ancient unupgraded stable or a machine that might become permanently insecure due to uninstallable packages. However it seems that Debian makes no effort to avoid this, so this probably isn't an important factor in this particular decision on the GCC 3.2 transition. signature.asc Description: This is a digitally signed message part
Re: Bug#156852: ITP: ttf-dustismo -- general purpose gpl'ed truetype sans serif font
Ben Armstrong wrote: > Meta package. A virtual package is something quite different. It is not a > package itself, but rather a package name, named in the "Provides:" control > field, thus emacs21 and emacs20 both have "Provides" of the virutal package > "emacsen". A meta package, on the other hand, is a real package that has > nothing but control information in it, usually "Depends:" so when you > install the meta package it causes a group of other packages to be > installed. > > If I gave the impression that the grouping should be by foundry, that is not > what I meant. I think I mentioned that the foundry may be present in the > name of each actual font package, but that is all. I imagined a good > grouping would be by function, i.e. "fonts suitable for foo". The grouping > I suggested was ttf-latin for a nice collection of fonts supporting latin > characters. I don't understand the reasoning behind bloating debian with a buch of little packages that each include one font file. Can you explain? Note the existing freefont and sharefont packages, which were compiled by a Debian developer. Why should truetype fonts be packaged any differently? -- see shy jo
Re: Linux Fonts
On Thu, Aug 15, 2002 at 09:07:47AM -0700, Dustin Mofos wrote: > Sorry, what I think of as a full character set is > defineatly not what someone else might think of as a > full set (I only have experience with english text).. > As far as the characters you mentioned specifically > they should be there, in fact I can see them using > Dustismo right now (except for ?? which I have no idea > what they are). Thanks much for the link, I can see > now that I am missing a great deal of characters. > not speaking about CJK characters :-) > > Also cyrillic and Greek seems to be bolder than > > latin part > > Could you explain this further? possible send me a > screenshot of what you are seeing? > That was my mistake - obviously Opera likes to substitute another font for cyrillic and greek, so these glyphs came from some other font. Anyway, I put a screenshot in http://melkor.dnp.fmph.uniba.sk/~garabik/junk/dustimo.png I had not turned on antialiasing, which is probably responsible for low quality of displayed glyphs (in particular, notice glyphs for l,z,n). For comparision, see http://melkor.dnp.fmph.uniba.sk/~garabik/junk/lynx.png which is the same page rendered in lynx/xterm, using default fixed width misc-fixed-* X11 fonts. The reason why I am so interested in missing glyphs is that there was a discussion on debian-devel recently about lack of free high quality variable width font. Dustimo could become base of such a font, if it covered at least MES-2 repertoire (maybe without Georgian and Armenian characters for the beginning). Adding CJK characters would require much greater effort. -- --- | Radovan Garabik http://melkor.dnp.fmph.uniba.sk/~garabik/ | | __..--^^^--..__garabik @ melkor.dnp.fmph.uniba.sk | --- Antivirus alert: file .signature infected by signature virus. Hi! I'm a signature virus! Copy me into your signature file to help me spread!
Re: How to transition to G++ 3.2 wthout any breakage
I certainly prefer NOT doing any ugly stuff with dpkg. "apt-get dist-upgrade" will uninstall packages that havn't been updated to the new c++ yet, which certainly is worth a bug report on these packages... That is exactly the PRO of a good dependency management... Instead of hacking some ugly stuff into dpkg, which is likely to break more stuff, and adding a wrapper to _hundrets_ of applications certainly is ugly... hacking the dynamic linker certainly is better than that... ANY such hack is more likely do break than the dependency system (which will just keep a few packages in an "uninstallable" state for sid, people could always get the latest package from sarge...) No, IMHO the best way should rely only on the Dependency system. I'm fine with adding a char or other tag to the package, too - lot's of package names (and especially the affected library names) are already quite cryptic... another char doesn't matter there... The change from libpng2 -> libpng3 with gtk2 was FINE, imho. It worked like a charm... I waited until the list of packages which would be deinstalled by that move contained and switched then... i lost just two or three apps i had installed, so what... (mostly i lost mozilla-snapshot and galeon-snapshot which i built myself ;) And if that gcc -> 3.2 move takes a month - well, i can live a months with the software versions i have installed right now. I don't need the bleeding edge for any price. The dependencies should help me know the price i had to pay... ;) But people will need to learn the difference between apt-get upgrade and apt-get dist-upgrade... i guess we'll get dozens of these bug reports while doing the move... BUT: What about preparing for future instances of this problem? Could we maybe have all new libs in /usr/lib/libc6/gcc3.2/ so if this occurs again, it will easier be solved? (hmm... i don't like these paths, either... but some stuff like this should probably be done...) Well, i'm not a dynamic linking insider, these are just my ideas. There are others much more competent around. Gruss, Erich Schubert -- erich@(mucl.de|debian.org)--GPG Key ID: 4B3A135C A man doesn't know what he knows until he knows what he doesn't know. Die kürzeste Verbindung zwischen zwei Menschen ist ein Lächeln. Mathematik: Das Alphabet, mit dessen Hilfe Gott das Universum beschrieben hat.
Re: How to transition to G++ 3.2 wthout any breakage
On Sun, Aug 18, 2002 at 06:09:18PM +0200, Luca Barbieri wrote: > > > Of course it would be better to avoid having to do things like this but > > > unfortunately there is simply no other solution that doesn't break > > > existing G++ v2 packages. > > Of course there is. You upload new versions of the gcc 2.95 packages, > > and you make the new gcc 3.2 packages conflict with the old ones. > > Nothing is broken in that case. > False. > Users will no longer get updated version of any C++ package unless they > manually remove/recompile any package depending on the old libraries > which is not yet recompiled or is not in Debian. Huh? We have libfoo++3 2.1.0-5 in the archive currently. We recompile the library against gcc 3.2, changing the name to libfoo++3c and conflicting with libfoo++3 <= 2.1.0-5. We then add a compatibility package, libfoo++3 2.1.0-6, which puts its libs in the new location for such things, and depends on whatever approved linker glue will be used for identifying ABIs. If a user upgrades libfoo++3, the library moves to the new directory, and the linker glue is installed, so no packages break. If a user installs libfoo++3c or a package that has been recompiled against it, it forces libfoo++3 to also be upgraded to the version that stows the library in the new canonical location. What breaks? If you were planning to NOT provide backwards-compatible libraries and linker glue, then your suggestion to modify dpkg is more broken than I thought. > Actually I think that those packages don't require any external C++ > library so they may still work, but what if they required one? What > would a KDE user do? Go back to the obsolete 2.2? Be no longer able to > get upgraded Debian packages, that might even contain security fixes? > Recompile packages on its own? > Would those alternatives be better than an ugly fix limited to dpkg? Yes, because by itself, the ugly fix in dpkg wouldn't *fix* anything, and it *would* make it more difficult to fix other bugs. Steve Langasek postmodern programmer pgpF9bOcaQowI.pgp Description: PGP signature
Re: How to transition to G++ 3.2 wthout any breakage
> I certainly prefer NOT doing any ugly stuff with dpkg. > "apt-get dist-upgrade" will uninstall packages that havn't been updated > to the new c++ yet, which certainly is worth a bug report on these > packages... Oops, I meant upgrade not dist-upgrade. dist-upgrade is bad :) > That is exactly the PRO of a good dependency management... > Instead of hacking some ugly stuff into dpkg, which is likely to break > more stuff, and adding a wrapper to _hundrets_ of applications certainly > is ugly... But the wrapper is only required for G++ v2 packages, that should hopefully be a very small number. > hacking the dynamic linker certainly is better than that... This only allows to avoid creating wrappers but doesn't avoid the problem that two libraries can't have the same filename. Something (dpkg) must move one of them. > ANY such hack is more likely do break than the dependency system (which > will just keep a few packages in an "uninstallable" state for sid, > people could always get the latest package from sarge...) Aren't the G++ 3.2 packages going to be moved into sarge? Even if you do so when the transition is complete, there will still be non-Debian G++ v2 packages installed on users' machines. > The change from libpng2 -> libpng3 with gtk2 was FINE, imho. It worked > like a charm... I waited until the list of packages which would be > deinstalled by that move contained and switched then... i lost just two > or three apps i had installed, so what... (mostly i lost > mozilla-snapshot and galeon-snapshot which i built myself ;) > And if that gcc -> 3.2 move takes a month - well, i can live a months > with the software versions i have installed right now. I don't need the > bleeding edge for any price. The dependencies should help me know the > price i had to pay... ;) The change from libpng2 to libpng3 is a total disaster like this one. Fortunately it might be easier to solve (it looks like relinking GTK with -Bsymbolic might do the trick, but I'm also not an expert of dynamic linking). What I especially don't like is the concept that GTK+, that doesn't use any png structure in its interface, can dictate what a program using it does with libpng. This concept is inherently totally absurd and broken and _anything_ is better than allowing something as stupid as this. And I'm surprised that this isn't obvious and that this transition was not stopped by anyone. > But people will need to learn the difference between apt-get upgrade and > apt-get dist-upgrade... i guess we'll get dozens of these bug reports > while doing the move... > > BUT: > What about preparing for future instances of this problem? > Could we maybe have all new libs in /usr/lib/libc6/gcc3.2/ > so if this occurs again, it will easier be solved? > (hmm... i don't like these paths, either... but some stuff like this > should probably be done...) But this API is supposed to be the final one, isn't it? :) And if it changes, the problem can be fixed in the same way as this one, or better if an unstrippable ABI tag is put in G++ compiled objects. Anyway, putting v3 packages in a separate directory still requires to modify /etc/ld.so.conf and create wrappers for v2 packages. And we still have the problem of external packages that don't obey the rule of the gcc-3.2 directory. signature.asc Description: This is a digitally signed message part
New ALSA packages (0.9.0rc3) for test
Hi,
I compiled for myself the new ALSA rc3 packages and put them into
deb http://people.debian.org/~calvin/debian/ ./
deb-src http://people.debian.org/~calvin/debian/ ./
These packages work for me, but you can report any bugs to
[EMAIL PROTECTED] (not in the BTS).
Junichi, if you choose to upload some of these packages, please remove
the "Private package" lines from all control description entries.
And you might want to revert some changes I made, as I have done
these changes without your experience on these packages.
Now on to the debian/changelogs:
alsa-driver (0.9.0rc3-1) unstable; urgency=low
* New upstream release (closes: #122632, #151502).
* The gusextreme module load problem should be also fixed by now:
hwdep.o is included, mpu401_uart.o is included, the
opl3_new_device function does not exist any more. (closes: #54131)
* The new upstream adds the missing hwdep object file for
some SoundBlaster cards (closes: #148900).
* The new upstream uses linux/slab.h instead of linux/malloc.h
(closes: #114598)
* work around missing symbols in 2.2 Kernels (closes: #147383)
* move debconf-utils from recommends to depends
(closes: #85242, #104163)
* move debhelper from recommends to depends. This and the above
make the check-debian-rules-pkg unnecessary.
(closes: #95920, #135535)
* updated all depends for new version (and debhelper 3)
* standards version 3.5.6.1
* fix minor spellings in alsa-source README.Debian (closes: #147013)
* Generated packages depend on the appropriate kernel image.
If you want to compile kernels manually *without* Debian packaging,
you should not use this package but compile ALSA also from source.
(closes: #94564)
* delete call of unused dh_install{cron,manpages,info,menu}
* add russion translation to alsa-source template (closes: #138322).
* update german translation of alsa-base.template, other languages are
still lagging behind (debconf-margetemplates rejects them).
* add german translation of alsa-source.template and control.
* updated cards database (closes: #141154)
* remove obsolete debian/debconf/cards.sh
-- Bastian Kleineidam <[EMAIL PROTECTED]> Thu, 15 Aug 2002 14:13:54 +0200
alsa-lib (0.9.0rc3-1) unstable; urgency=low
* New upstream release.
* New upstream has updated iatomic.h for mips
(closes: #149159, #145016)
* Removed unnecessary powerpc patch
* Removed libtool hack (dont know why this was there)
* Removed call to auto* tools, adjust build-depends
* Build-depend on latest alsa-headers
* Standards-Version: 3.5.6.1
* DH_COMPAT=3; change debian/tmp references to debian/$(package)
(closes: #157056)
* Update config.{guess,sub}, ran libtoolize (closes: #101287)
* Do s/make/$(MAKE)/ in debian/rules.
* Add install target to debian/rules.
* Removed unnecessary debian/libasound0.4*.
* Removed unnecessary debian/postinst.
* Link asound.1 to undocumented.
-- Bastian Kleineidam <[EMAIL PROTECTED]> Sun, 18 Aug 2002 13:51:22 +0200
alsa-utils (0.9.0rc3-1) unstable; urgency=low
* New upstream release (closes: #139318).
* Standards-Version: 3.5.6.1
* Use absolute filenames in dh_link (closes: #148323).
* Testing/stable versions are consistent (closes: #124127).
* Update dependencies version of alsa-base to rc3
* Conflict with alsa-utils-0.5, I dont provide it installed together
with alsa-utils-0.9.
-- Bastian Kleineidam <[EMAIL PROTECTED]> Sun, 18 Aug 2002 17:21:05 +0200
So long,
--
.~.
/V\ Bastian Kleineidam · Just do it. Use Linux.
/( )\
^^-^^
pgpatmxA57ZQk.pgp
Description: PGP signature
debRe: ian-devel-digest Digest V2002 #46
> ATTACHMENT part 15 message/rfc822 > Date: Sun, 18 Aug 2002 16:49:45 +0100 > From: Colin Watson <[EMAIL PROTECTED]> > To: debian-devel@lists.debian.org > Subject: Re: Mass bug filing for Build-Depends on libc6-dev > > On Sun, Aug 18, 2002 at 08:28:36AM -0700, James Morrison wrote: > > libc6-dev is not available on all of the Debian platforms so a build > > dependency on lib6-dev will cause the program not to compile on systems > without > > libc6-dev. > > It should probably only be a normal bug for those packages with > unversioned build-dependencies, since other libc-dev variants provide > libc6-dev. Yeah, these are useless :) > > The following packages depend on a versioned libc6-dev but don't include > > libc0.3-dev. > > > > rstatd > > valgrind > > Does valgrind have a chance of working on hurd-i386? I don't think valgrind or fenris have a hope of working on GNU/Hurd anytime soon. > -- > Colin Watson [EMAIL PROTECTED] > = James Morrison University of Waterloo Computer Science - Digital Hardware 2A co-op http://hurd.dyndns.org Anyone referring to this as 'Open Source' shall be eaten by a GNU __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com
Mail von einer unbekannten...
Hallöle, Du wunderst Dich wahrscheinlich, daß Du von mir Post bekommst, aber ich habe Dein Profil im Chat gelesen, und als ich Dich angesprochen hatte, warst Du schon weg. Und jetzt schreibe ich Dir auf diesem Wege... Ich bin 17 Jahre alt, und habe blonde lange Haare. Ein Foto von mir findest Du unter http://biggimaus.5xx.net Wenn Du mich auch kennenlernen möchtest, maile mir einfach zurück. Biggi
Bug#157182: ITP: libpod-sax-perl -- Perl module for generating SAX events from POD
Package: wnpp Version: N/A; reported 2002-08-18 Severity: wishlist * Package name: libpod-sax-perl Version : 0.10 Upstream Author : Matt Sergeant <[EMAIL PROTECTED]> * URL : http://www.cpan.org/ * License : Artistic Description : Perl module for generating SAX events from POD This module parses POD and generates corresponding SAX events. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux rohan 2.4.18 #1 Sun Jul 14 11:28:54 CDT 2002 i686 Locale: LANG=POSIX, LC_CTYPE=en_US.ISO-8859-1 (ignored: LC_ALL set) -- no debconf information
Re: How to transition to G++ 3.2 wthout any breakage
> > hacking the dynamic linker certainly is better than that... > This only allows to avoid creating wrappers but doesn't avoid the > problem that two libraries can't have the same filename. > Something (dpkg) must move one of them. No. The maintainer must, by uploading a new version of the old library, and using proper Conflicts. That way other packages can depend on the moved versions properly. > Aren't the G++ 3.2 packages going to be moved into sarge? Even if you do > so when the transition is complete, there will still be non-Debian G++ > v2 packages installed on users' machines. No, they are not, as long as there are dependency problems, and as long as we keep a bug "G++ 3.2 transition incomplete" open... There are -nice- and -tested- methods to do such things. > The change from libpng2 to libpng3 is a total disaster like this one. No, the transition worked fine. The disaster is not the way Debian gtk2 migrated, but the library itself. > What I especially don't like is the concept that GTK+, that doesn't use > any png structure in its interface, can dictate what a program using it > does with libpng. The gtk engines that use png's do depend on png. That goes this far that even statically linked GTK apps sometimes don't work - because they try to load a gtk theme with different libraries. (see mldonkey faq, p.e.) > This concept is inherently totally absurd and broken and _anything_ is > better than allowing something as stupid as this. And I'm surprised that > this isn't obvious and that this transition was not stopped by anyone. The transition worked fine, so i don't blame the people who did it. It was a minor disaster on a FreeBSD box i regularly use It worked like a charm because they used package depedencies, instead of any ugly hacks. > Anyway, putting v3 packages in a separate directory still requires to > modify /etc/ld.so.conf and create wrappers for v2 packages. Why do v2 packages need to be modified, if v3 libraries are in a different directory??? > And we still have the problem of external packages that don't obey the > rule of the gcc-3.2 directory. Depending on what other distributions do. If they follow this concept, too, everyone will be fine. If they don't they'll have to solve the whole issue, too... People won't be happy if their applications work on SuSE 9 but not on SuSE 8 or whatever. Gruss, Erich Schubert -- erich@(mucl.de|debian.org)--GPG Key ID: 4B3A135C Go away or i'll replace you with a very small shell script. Es ist besser, geliebt und verloren zu haben, als niemals geliebt zu haben. Humor sollte immmer dabeisein, auch bei Problemen.
Re: Move to python 2.2 as default release?
On Wed, Aug 14, 2002 at 04:28:53PM -0400, Jim Penny wrote: > One final point. We will almost definitely not switch the default > python in sid (current unstable), until there is talk that Sarge is > nearing a freeze. There is simply no point in undergoing the pain of > a major python release twice in a single unstable cycle. We will > instead make the decision of what python will be default in Sarge > when it nears release, not now. That's silly. If we want to catch problems in all those python packages (which are for only the default python version often enough) then we should upgrade the default python version early and find those problems. Waiting for the freeze and then pulling 2.1 from under those python packages looks like a really bad idea to me. cu Torsten pgp9xz0tIixZY.pgp Description: PGP signature
Re: How to transition to G++ 3.2 wthout any breakage
>> Luca Barbieri <[EMAIL PROTECTED]> writes: > I have already managed to write a program to detect the ABI Can you put that somewhere for download? -- Marcelo | She'd even given herself a middle initial - X - which [EMAIL PROTECTED] | stood for "someone who has a cool and exciting middle | name". | -- (Terry Pratchett, Maskerade)
Re: How to transition to G++ 3.2 wthout any breakage
On Sun, Aug 18, 2002 at 06:09:18PM +0200, Luca Barbieri wrote: > > Of course there is. You upload new versions of the gcc 2.95 packages, > > and you make the new gcc 3.2 packages conflict with the old ones. > > Nothing is broken in that case. > False. > Users will no longer get updated version of any C++ package unless they > manually remove/recompile any package depending on the old libraries > which is not yet recompiled or is not in Debian. > > For example, how about calc.cx KDE 3.0 packages that are obviously > necessary for any KDE user? I don't see any mention of GCC 3.2 on their > text file so I assume that they aren't ported. Why is KDE 3.0 obviously necessary for any KDE user? KDE 2.2.2 still works fine but will probably suffer from the same issue. However, I will rebuild against gcc 3.2 as soon as libfam/libqt gets rebuilt against it. Chris
Re: How to transition to G++ 3.2 wthout any breakage
On Sun, 2002-08-18 at 20:08, Erich Schubert wrote: > > > hacking the dynamic linker certainly is better than that... > > This only allows to avoid creating wrappers but doesn't avoid the > > problem that two libraries can't have the same filename. > > Something (dpkg) must move one of them. > > No. The maintainer must, by uploading a new version of the old library, > and using proper Conflicts. That way other packages can depend on the > moved versions properly. And it is not possible to install both a v2 ABI and a v3 ABI version of the library. > > Aren't the G++ 3.2 packages going to be moved into sarge? Even if you do > > so when the transition is complete, there will still be non-Debian G++ > > v2 packages installed on users' machines. > > No, they are not, as long as there are dependency problems, and as long > as we keep a bug "G++ 3.2 transition incomplete" open... > There are -nice- and -tested- methods to do such things. That works as long as user only install Debian packages, but obviously doesn't work for non-Debian ones. > > The change from libpng2 to libpng3 is a total disaster like this one. > > No, the transition worked fine. The disaster is not the way Debian gtk2 > migrated, but the library itself. No, it is in the fact the neither the library authors nor Debian fixed the problem. > > What I especially don't like is the concept that GTK+, that doesn't use > > any png structure in its interface, can dictate what a program using it > > does with libpng. > > The gtk engines that use png's do depend on png. That goes this far that > even statically linked GTK apps sometimes don't work - because they try > to load a gtk theme with different libraries. (see mldonkey faq, p.e.) So what? I don't see anything that would prevent to have both libpng2 and libpng3 loaded at the same time. The only one is namespace collisions, but they are of course fixable and they should be fixed rather than just making conflicting packages. > > Anyway, putting v3 packages in a separate directory still requires to > > modify /etc/ld.so.conf and create wrappers for v2 packages. > > Why do v2 packages need to be modified, if v3 libraries are in a > different directory??? Because v2 binaries need to load libraries from the v2 dir and v3 ones from the v3 dir. Either the v2 binaries or the v3 ones must be wrapped to obtain this behavior or the dynamic loader must be modified. Modifying the dynamic loader would have the advantage of not requiring any user action to run v2 binaries, so I'm looking into this. > > And we still have the problem of external packages that don't obey the > > rule of the gcc-3.2 directory. > > Depending on what other distributions do. If they follow this concept, > too, everyone will be fine. If they don't they'll have to solve the > whole issue, too... People won't be happy if their applications work on > SuSE 9 but not on SuSE 8 or whatever. But by modifying dpkg packages can be made to work regardless of the place where they put libraries. signature.asc Description: This is a digitally signed message part
Re: GCC 3.2 transition
On Sun, Aug 18, 2002 at 01:03:38PM +0100, Richard Kettlewell wrote: > Panu Kalliokoski <[EMAIL PROTECTED]> writes: > > You're right; I'm just more worried about the more practical point > > that if a library, when being built, cannot know which SONAME it > > should install itself under (it would involve checking the version > > of compiler used, right?), > I think you've answered your own question; it _can_ known which soname > to use, and to discover it, it should check the version of the > compiler. I'm not sure whether you're actually proposing changing the SONAMEs so that the library will compile itself with different SONAME depending on the compiler, but let me say some more problems with using SONAME for the transition (even if upstream could be convinced to do this, which in practice most certainly is the biggest problem): Let's say libfoo version 17.1.6 will be the first libfoo to compile itself under libfoo.so.8 if gcc 2 is being used, libfoo.so.9 if gcc 3 is being used. You're right, this seems sensible because the libraries do have incompatible ABI's. Further releases will retain this separation. But what will happen when the library's *own* ABI (the thing SONAMEs are really meant for) changes? Will libfoo 18.0.1 install itself under libfoo.so.10 if gcc 2 is being used, libfoo.so.11 if gcc 3? Or is support for gcc 2 to be dropped from these releases? Why should it be a library's business at all to provide information about what compiler the user programs should use, and to dictate when they cannot use compiler X anymore? The basic problem here is that SONAMEs contain insufficient information, which for example in the case of libc transition was too weak to express which other libraries the library is linked against, and now is (and should IMO not be made otherwise) too weak to tell which compiler was used to compile the library. It would be very nice to have a standardised way for a library to export all information that will be necessary for the linker to find just the library that will not break anything. But such a standard should be treated as a standard, maybe an extension to ELF, and be subject to much discussion before being taken in use. Then maybe, if debian is lucky, the other distros will deem it worthwhile to be binary-compatible with the new standard. In practice, this kind of situation (ABI's being dictated by factors that are orthogonal to each other) hasn't occurred too much in practice yet, and the "nice" workaround that will not make unnecessary conflicts is to have different SONAME namespaces. One way to achieve this could be gcc 3.2 automatically linking against a different dynamic linker. (Basically, if the dynamic linker was written in C++ (which it isn't), this would be the only option anyway.) Does gcc's upstream have any views on this? > (I believe it's also necessary to incorporate information about the > sonames - i.e. ABIs - of libraries that this library depends on it, > into its soname too.) I think the information should be incorporated _somewhere_. But as I said above, this should be a matter of common standardisation. > Not changing sonames[1] when the ABI changes would also be incredibly > painful; bits of software that people use and depend on would start > crashing. Well, it is sufficient that the linker gets the additional information from somewhere. Of the two ways (hacking the linker to use different versions depending on the ABI, or having two dynamic linkers) the latter is IMO cleaner, but neither will break anything. Panu
Re: How to transition to G++ 3.2 wthout any breakage
> > No. The maintainer must, by uploading a new version of the old library, > > and using proper Conflicts. That way other packages can depend on the > > moved versions properly. > And it is not possible to install both a v2 ABI and a v3 ABI version of > the library. Sure it is. One of the packages has to install the files in a different directory - that is NOT different from moving the files via a dpkg hack. BUT you can assure via the dependencies that these paths are used. > > > Aren't the G++ 3.2 packages going to be moved into sarge? Even if you do > > > so when the transition is complete, there will still be non-Debian G++ > > > v2 packages installed on users' machines. > > > > No, they are not, as long as there are dependency problems, and as long > > as we keep a bug "G++ 3.2 transition incomplete" open... > > There are -nice- and -tested- methods to do such things. > That works as long as user only install Debian packages, but obviously > doesn't work for non-Debian ones. If they use proper dependencies it works just fine. They can't be installed unless they fit to the system. That is the ONLY correct thing. If they install stuff by hand, your automatic wrapper generation and library moving will not help either. If you want to fix alienated rpm's - do that in alien. > > No, the transition worked fine. The disaster is not the way Debian gtk2 > > migrated, but the library itself. > No, it is in the fact the neither the library authors nor Debian fixed > the problem. Which is completely separte from the correct way to package these things, and that is what we are talking about... the libpng issues cannot be solved by a dpkg hack! They did not solve the libpng problem (which is not to be solved by debian, but by upstream and all distributions _together_) but they set the dependencies correctly, so packages don't break. Without a hack. Which is great. > > > Anyway, putting v3 packages in a separate directory still requires to > > > modify /etc/ld.so.conf and create wrappers for v2 packages. > > > > Why do v2 packages need to be modified, if v3 libraries are in a > > different directory??? > Because v2 binaries need to load libraries from the v2 dir and v3 ones > from the v3 dir. > Either the v2 binaries or the v3 ones must be wrapped to obtain this > behavior or the dynamic loader must be modified. We don't have any v3 binaries yet. So where is the problem? The maintainers could include proper wrappers for them. that is better than doing some automatic wrappers... You could even use alternatives to switch from default-is-v2 to default-is-v3 and remove all wrappers at once, when you modified your library paths... No hack needed for that either. > But by modifying dpkg packages can be made to work regardless of the > place where they put libraries. Don't take stuff unnecessarily out of control of maintainers. Many apps use wrappers already, why force them to use another wrapper. You'll break LOTs of things. For example mozilla does use some wrapper to set LD_LIBRARY_PATH correctly... your automatic wrapper generation will maybe not work, and if it does it's definitely inferior to having the maintainer do a proper wrapper himself... Gruss, Erich Schubert -- erich@(mucl.de|debian.org)--GPG Key ID: 4B3A135C A polar bear is a rectangular bear after a coordinate transform. Wer nicht zuweilen zuviel empfindet, der empfindet immer zuwenig. Mathematik: Das Alphabet, mit dessen Hilfe Gott das Universum beschrieben hat.
xmms needs rebuild in sid
I believe the libpng2->libpng3 migration in sid may have broken xmms. While I can run xmms somewhat, I can't get the playlist to display. If strace a run I see... rt_sigprocmask(SIG_SETMASK, NULL, [32], 8) = 0 rt_sigsuspend([] --- SIGRT_0 (Real-time signal 0) --- <... rt_sigsuspend resumed> ) = 32 shmat(0, 0, 0x6ptrace: umoven: Input/output error )= ? which isn't clearly associated with a particular module loading. Jack
Re: How to transition to G++ 3.2 wthout any breakage
> > > > Aren't the G++ 3.2 packages going to be moved into sarge? Even if you do > > > > so when the transition is complete, there will still be non-Debian G++ > > > > v2 packages installed on users' machines. > > > > > > No, they are not, as long as there are dependency problems, and as long > > > as we keep a bug "G++ 3.2 transition incomplete" open... > > > There are -nice- and -tested- methods to do such things. > > That works as long as user only install Debian packages, but obviously > > doesn't work for non-Debian ones. > > If they use proper dependencies it works just fine. They can't be > installed unless they fit to the system. That is the ONLY correct thing. Correctly installing them is much better than declaring them uninstallable. > If they install stuff by hand, your automatic wrapper generation and > library moving will not help either. > If you want to fix alienated rpm's - do that in alien. They help if I install packages that want to put libraries in the wrong directory, including all existing library packages that don't know about /usr/lib/g++-2. > > > No, the transition worked fine. The disaster is not the way Debian gtk2 > > > migrated, but the library itself. > > No, it is in the fact the neither the library authors nor Debian fixed > > the problem. > > Which is completely separte from the correct way to package these > things, and that is what we are talking about... the libpng issues > cannot be solved by a dpkg hack! No, dpkg hacks solve the problem of two files trying to be in the same place. > They did not solve the libpng problem (which is not to be solved by > debian, but by upstream and all distributions _together_) but they set > the dependencies correctly, so packages don't break. Without a hack. > Which is great. Debian can solve it by releasing a version of GTK+ 2.0 that works with binaries that use libpng2 and also with ones that use libpng3 or, if that is not possible, at least releasing a distribution (i.e. dynamic loader + GTK+) that achieves this goal. > We don't have any v3 binaries yet. So where is the problem? > The maintainers could include proper wrappers for them. that is better > than doing some automatic wrappers... What?! Including duplicated crap in *lots* of packages is better than a central fix? How about non-Debian packages? You can see the result of this mindset in the /usr/doc transition. If rather than having packages/debhelper do the transition themselves, dpkg was modified, it would have been done in at most a week. The work required to create packages should be reduced, not increased. > You could even use alternatives to switch from default-is-v2 to > default-is-v3 and remove all wrappers at once, when you modified your > library paths... No hack needed for that either. And how do you easily run from the command line both a v2 ABI program and a v3 ABI one without needing to know about the issue? > Don't take stuff unnecessarily out of control of maintainers. Many apps > use wrappers already, why force them to use another wrapper. You'll > break LOTs of things. For example mozilla does use some wrapper to set > LD_LIBRARY_PATH correctly... your automatic wrapper generation will > maybe not work, and if it does it's definitely inferior to having the > maintainer do a proper wrapper himself... Yes, you are right. Modifying the dynamic linker is much better. signature.asc Description: This is a digitally signed message part
Re: xmms needs rebuild in sid
#include * Jack Howarth [Sun, Aug 18 2002, 03:16:00PM]: > I believe the libpng2->libpng3 migration in sid may have > broken xmms. While I can run xmms somewhat, I can't get the > playlist to display. If strace a run I see... Strace does not show much useable info about shared libs. Use elfdump or ldd. > rt_sigprocmask(SIG_SETMASK, NULL, [32], 8) = 0 > rt_sigsuspend([] > --- SIGRT_0 (Real-time signal 0) --- > <... rt_sigsuspend resumed> ) = 32 > shmat(0, 0, 0x6ptrace: umoven: Input/output error > )= ? > > > which isn't clearly associated with a particular module loading. He? WTF did make you think so? I do not see any reference to libpng issue. Gruss/Regards, Eduard. -- <@Joey> Faellt einem bei diesem Fehler spontan die Ursache ein? <@Joey> <[EMAIL PROTECTED]>: host mail2.ecce-terram.de[193.16.3.10] <@Joey> said: 551 '<[EMAIL PROTECTED]>' <@Joey> <[EMAIL PROTECTED]> not matched: (ERR_104) security <@Joey> violation: remote address not permitted. -!- Joey was kicked from #debian.de by FWerewolf [Public flood] -!- FWerewolf [EMAIL PROTECTED] has quit [Leaving] -- #debian.de -- Angst gehabt?
Re: xmms needs rebuild in sid
Eduard, Actually, Michel Danzer says he thinks in may be related to 100 dpi fonts. In any case, does xmms display its playlist in sid for you? Here I get nothing although xmms doesn't crash. I just rebuilt it against current sid and that didn't help. Do we know when this playlist failure bug arose? Jack
Re: Linux Fonts
On Thu, Aug 15, 2002 at 09:07:47AM -0700, Dustin Mofos wrote: > As far as the characters you mentioned specifically > they should be there, in fact I can see them using > Dustismo right now (except for ?? which I have no idea > what they are). Thanks much for the link, I can see > now that I am missing a great deal of characters. I was happy to notice that the encoding of your font is 10646-1 i.e. it's an Unicode font. This is of personal interest to me because my open source hobby is a chess database (no, I haven't published it yet) and one of the many things I need is a chess font. I actually made using pfaedit a chess TTF which looks quite good when printed but horrible on screen if the size is small. I used GPL'd images from eboard-extras-pack1. When I asked at rec.games.chess.computer what kind of encoding I should use it was pointed out that Unicode has chess pieces from decimal 9812 to decimal 9823. It would be great, at least for me, if your font included chess pieces. I'll be quite willing to contribute (how can I contribute to a font?) unless someone who undestands fonts wants to do it. -- Ari Makela [EMAIL PROTECTED]http://arska.org/hauva/ "Sailing is, after all, a kind of grace, a kind of magic." - Phil Berman
Re: New ALSA packages (0.9.0rc3) for test
On Sun, Aug 18, 2002 at 07:30:25PM +0200, Bastian Kleineidam wrote: > Hi, > > I compiled for myself the new ALSA rc3 packages and put them into > deb http://people.debian.org/~calvin/debian/ ./ > deb-src http://people.debian.org/~calvin/debian/ ./ [...] > * update german translation of alsa-base.template, other languages are > still lagging behind (debconf-margetemplates rejects them). Could you please also consider #92871? Denis
Re: How to transition to G++ 3.2 wthout any breakage
On Sun, Aug 18, 2002 at 08:36:21PM +0200, Luca Barbieri wrote: > On Sun, 2002-08-18 at 20:08, Erich Schubert wrote: > > > > hacking the dynamic linker certainly is better than that... > > > This only allows to avoid creating wrappers but doesn't avoid the > > > problem that two libraries can't have the same filename. > > > Something (dpkg) must move one of them. > > No. The maintainer must, by uploading a new version of the old library, > > and using proper Conflicts. That way other packages can depend on the > > moved versions properly. > And it is not possible to install both a v2 ABI and a v3 ABI version of > the library. Of course it is. This is a solved problem. The question is how to set the libraries up on the system to make sure they can be *found* by the software that needs them. Steve Langasek postmodern programmer pgp0Oy9hIH0QJ.pgp Description: PGP signature
Re: xmms needs rebuild in sid
On Sun, Aug 18, 2002 at 03:42:55PM -0400, Jack Howarth wrote: > Actually, Michel Danzer says he thinks in may be related to > 100 dpi fonts. In any case, does xmms display its playlist in > sid for you? Here I get nothing although xmms doesn't crash. > I just rebuilt it against current sid and that didn't help. > Do we know when this playlist failure bug arose? Looks like another variation of #118173... Check if your font setting in the Preferences is broken, i.e. if points to an nonexistent font. -- 2. That which causes joy or happiness.
Re: GCC 3.2 transition
>> Panu A Kalliokoski <[EMAIL PROTECTED]> writes: > In practice, this kind of situation (ABI's being dictated by factors > that are orthogonal to each other) hasn't occurred too much in > practice yet, and the "nice" workaround that will not make > unnecessary conflicts is to have different SONAME namespaces. One way > to achieve this could be gcc 3.2 automatically linking against a > different dynamic linker. (Basically, if the dynamic linker was > written in C++ (which it isn't), this would be the only option > anyway.) Does gcc's upstream have any views on this? I was toying with that idea in my head. There's no need for a special C++ compiler, is there? Just the normal linker with a different set of default paths. This is like using an -rpath. The problem with -rpath is that it has precedence over LD_LIBRARY_PATH. So, the simplest solution is for g++-3.2 to indicate a different dynamic linker when linking programs. -- Marcelo | Item 4: Prefer C++-style comments [EMAIL PROTECTED] | -- Scott Meyers, Effective C++
Re: New ALSA packages (0.9.0rc3) for test
On Sun, 18 Aug 2002 19:30:25 +0200 Bastian Kleineidam <[EMAIL PROTECTED]> wrote: > Junichi, if you choose to upload some of these packages, please remove > the "Private package" lines from all control description entries. > And you might want to revert some changes I made, as I have done > these changes without your experience on these packages. He's not called Junichi :P regards, junichi -- [EMAIL PROTECTED] http://www.netfort.gr.jp/~dancer
Re: Mass bug filing for Build-Depends on libc6-dev
On Sun, 18 Aug 2002 08:28:36 -0700 (PDT)
James Morrison <[EMAIL PROTECTED]> wrote:
> libc6-dev is not available on all of the Debian platforms so a build
> dependency on lib6-dev will cause the program not to compile on systems
> without
>
> libc6-dev. This problem has been solved with build-essentials and the
> libc-dev
>
> virtual package which is part of build-essentials.
How about, ${devlibs:Depends} [0]
Is it a bad idea, or is it a bad idea.
Noone hit me with a stick yet, so it must be a bad idea.
[0] d-shlibs.
regards,
junichi
--
[EMAIL PROTECTED] http://www.netfort.gr.jp/~dancer
Re: xmms needs rebuild in sid
Josip, Changing the font didn't help, but deleting my .xmms directory in my account seemed to have cured it. Odd. Jack
Re: New ALSA packages (0.9.0rc3) for test
On Mon, Aug 19, 2002 at 06:12:12AM +0900, Junichi Uekawa wrote: > On Sun, 18 Aug 2002 19:30:25 +0200 > Bastian Kleineidam <[EMAIL PROTECTED]> wrote: > > > Junichi, if you choose to upload some of these packages, please remove > > the "Private package" lines from all control description entries. > > And you might want to revert some changes I made, as I have done > > these changes without your experience on these packages. > > He's not called Junichi :P Oops I did it again, its of course Masato Taruishi. Tschööö, Bastian -- Bastian Kleineidam · [EMAIL PROTECTED] · GPG key ID 32EC6F3E pgpLgnowbp0Cw.pgp Description: PGP signature
Re: xmms needs rebuild in sid
On Sun, Aug 18, 2002 at 05:19:38PM -0400, Jack Howarth wrote: > Changing the font didn't help, but deleting my .xmms > directory in my account seemed to have cured it. Odd. And there goes another opportunity to trace the bug... -- 2. That which causes joy or happiness.
Re: xmms needs rebuild in sid
Josip, Unless it was just random corruption of the .xmms in which case it would be impossible to determine what caused that. I actually set the font for the playlist to the same font as the main display (which is okay) and that didn't work. Unless someone else sees this today I would bet on random corruption of prefs. Jack
Re: Linux Fonts
Thanks for the screenshot. I must say that it looks terrible. As I said before I embedded bitmaps instead of doing the hinting, and I found out from the XFree86 mailing list that its font renderer does not support embedded bitmaps. So I guess its back to the drawing (hinting) board. Just for reference (and to prove I'm not a total hack) I posted a screenshot of Dustismo for point sizes 8-17 as displayed on a windows box. http://www.cheapskatefonts.com/Dustismo_screenshot.jpg Thanks, Dustin That was my mistake - obviously Opera likes to substitute another font for cyrillic and greek, so these glyphs came from some other font. Anyway, I put a screenshot in http://melkor.dnp.fmph.uniba.sk/~garabik/junk/dustimo.png I had not turned on antialiasing, which is probably responsible for low quality of displayed glyphs (in particular, notice glyphs for l,z,n). For comparision, see http://melkor.dnp.fmph.uniba.sk/~garabik/junk/lynx.png which is the same page rendered in lynx/xterm, using default fixed width misc-fixed-* X11 fonts. The reason why I am so interested in missing glyphs is that there was a discussion on debian-devel recently about lack of free high quality variable width font. Dustimo could become base of such a font, if it covered at least MES-2 repertoire (maybe without Georgian and Armenian characters for the beginning). Adding CJK characters would require much greater effort. -- --- | Radovan Garabik http://melkor.dnp.fmph.uniba.sk/~garabik/ | | __..--^^^--..__garabik @ melkor.dnp.fmph.uniba.sk | --- Antivirus alert: file .signature infected by signature virus. Hi! I'm a signature virus! Copy me into your signature file to help me spread! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#157202: ITP: nuppelvideo -- Nuppel video tools: capture on slow machines
Package: wnpp Version: N/A; reported 2002-08-19 Severity: wishlist * Package name: nuppelvideo Version : 0.52 Upstream Author : Roman HOCHLEITNER <[EMAIL PROTECTED]> * URL : http://mars.tuwien.ac.at/~roman/nuppelvideo/ * License : GPL Description : Nuppel video tools: capture on slow machines Long description follows later -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux scorpius 2.4.19-rc3 #1 Thu Aug 1 07:42:23 CEST 2002 i686 Locale: LANG=C, LC_CTYPE=C -- no debconf information
Re: Linux Fonts
On Sun, 2002-08-18 at 20:55, Dustin Norlander wrote: > http://www.cheapskatefonts.com/Dustismo_screenshot.jpg Especially at smaller sizes, that needs some kerning adjustments. !@ looks horrible, for example, at least at 10pt and below. At 8pt most every letter runs into each other. But, it's much better than I can do ;-) signature.asc Description: This is a digitally signed message part
Re: ITP: mini-dinstall -- daemon for updating Debian packages in a repository
Colin Walters wrote:
> > * Package name: mini-dinstall
>
> Interested? My current packages are available here:
>
> deb http://monk.debian.net/~walters/debian/ staging/$(ARCH)/
> deb http://monk.debian.net/~walters/debian/ staging/all/
> deb-src http://monk.debian.net/~walters/debian/ staging/source/
>
> Now, the obvious question is, did I use mini-dinstall to put
> mini-dinstall into my staging repository? Of course I did :) ...But I
> probably won't upload this to Debian until I make sure it handles a few
> error conditions better. I also need to add automatic support for
> unsigning/making unreadable .changes files.
>
> Comments, suggestions, etc. always appreciated.
I've been using a hackish program to manage my archive, so I'm very
interested. It doesn't do quite what my old program does though
(~joeyh/bin/package-sync).
* I need the ability to keep my existing sources.list lines, which are pretty
well-known. I will only ever have i386 and all in my repository, so I
don't need separate directories. And $(ARCH) is icky. I lump everything
into one directory and use:
deb file:/home/joey/debian/public /
deb-src file:/home/joey/debian/public /
* A proper Incoming directory would be nice. I was confused at first
about where exactly to upload stuff to and tried putting stuff in the
i386/ and all/ directories.
* The bit about dnotify is confusing. What is it?
* It doesn't deal well if it gets a package in an architecture not
listed:
[EMAIL PROTECTED]:~/debian/public2/local>mini-dinstall -b -v
mini-dinstall [1024] INFO: Initializing archive local
mini-dinstall [1026] INFO: Created new thread (local) for archive local
mini-dinstall [1026] INFO: Entering batch mode...
mini-dinstall [1026] INFO: Examining "local/apt-src_0.17_i386.changes"
mini-dinstall [1026] INFO: Verifying integrity of
"local/apt-src_0.17_i386.changes"
mini-dinstall [1026] ERROR: Uncaught exception; thread exiting
Traceback (most recent call last):
File "/usr/bin/mini-dinstall", line 410, in run
self._install_changefile(changefilename, changefile)
File "/usr/bin/mini-dinstall", line 433, in _install_changefile
logger.exception('Failed to prcess "s"' % (changefilename,))
TypeError: not all arguments converted
* I need the ability to have a hook that runs a program passing it a changes
file name once it successfully puts a package into the archive. I use
this type of hook to auto-update web pages for debian native packages, and
I would like to use it as a way to launch a secondary dput to the main
debian archive, since I currently upload everything to my own local archive
and also to Incoming.
* For one repository I would like the ability to not delete old versions of
packages in it, ever.
--
see shy jo
RE: CST81394496ID - TemplateInfo(TemplateInfo)
Hello,Thank you for writing us. We've been overwhelmed by the response to our WindowsMedia.com site, so we may not be able to write an individual reply to you. If you sent in a REQUEST for a specific radio station for the Radio Station Guide, you can be sure that we'll try to add it. But an email from you to the station may be more persuasive. To find your station's email address, please refer to the listing of radio station Web sites on http://rronline.com/Exclusives/Directory/Homepage.htm or on http://wmbr.mit.edu/stations/. Please email the radio station, tell them about the Microsoft Radio Station Guide (at http://WindowsMedia.microsoft.com/radio/radio.asp), and let them know that you want to listen to the station using the Windows Media Player.If you have a technical question, please consult the following resources:- Microsoft Support maintains a searchable collection of problem-solving tools and technical information (Knowledge Base articles, Troubleshooting Wizards, and downloadable files) on a wide variety of topics at http://support.microsoft.com/support/. You can also click the "search" tab at the top of any Microsoft page to search even more content categories.- For updated information about Internet Explorer, go to http://www.microsoft.com/ie/.- For questions about MSN, please go to http://www.msn.com/help/.- For an informational Web tutorial, go to http://www.microsoft.com/magazine/guides/internet/.- For information about the Windows Media Player, go to http://www.microsoft.com/windows/mediaplayer/default.asp.If you'd like to learn about other new stations as we add them, subscribe to our FREE newsletter. Go to the bottom of the Radio Station Guide to learn how.Best regards, WindowsMedia.com / Your audio-video guidehttp://windowsmedia.com/mediaguide/default.asp
Re: ITP: mini-dinstall -- daemon for updating Debian packages in a repository
On Sun, 2002-08-18 at 20:37, Joey Hess wrote: > > I've been using a hackish program to manage my archive, so I'm very > interested. It doesn't do quite what my old program does though > (~joeyh/bin/package-sync). On which machine is this ~joeyh? > * I need the ability to keep my existing sources.list lines, which are pretty > well-known. I will only ever have i386 and all in my repository, so I > don't need separate directories. And $(ARCH) is icky. I lump everything > into one directory and use: This is a bit tricky. It would be nice to support a few more layouts though. The reason I don't support a single directory-style layout is because you can't mix different architecture .debs in there, so I didn't really find it useful. * A proper Incoming directory would be nice. I was confused at first > about where exactly to upload stuff to and tried putting stuff in the > i386/ and all/ directories. Well, basically each distribution is its own archive. There isn't really a pool structure, because to have a pool type thing, you really need a database to keep track of it, tools to manage it, and at that point you might as well just use the full-blown dinstall. > * The bit about dnotify is confusing. What is it? dnotify is the Linux 2.4 directory notification API; it tells you when a directory has changed. There's a little program in a package named "dnotify" which is an interface to that. But my python wrapper, or it, is still a bit buggy :/ > * It doesn't deal well if it gets a package in an architecture not > listed: Fixed, thanks! > * I need the ability to have a hook that runs a program passing it a changes > file name once it successfully puts a package into the archive. I use > this type of hook to auto-update web pages for debian native packages, and > I would like to use it as a way to launch a secondary dput to the main > debian archive, since I currently upload everything to my own local archive > and also to Incoming. That's a pretty cool idea. Should be implemented in the latest 0.0.1.0; the option is called "post_installation_script". > * For one repository I would like the ability to not delete old versions of > packages in it, ever. Also should be implemented in 0.0.1.0, as the option "keep_old". Thanks for your comments!
Bug#157219: ITP: libdxf -- Library for reading and writing (planned) AutoDesk (R) DXF files.
Package: wnpp Version: N/A; reported 2002-08-19 Severity: wishlist * Package name: libdxf Version : 0.1.2 Upstream Author : Andrew Mustun <[EMAIL PROTECTED]> * URL : http://dxflib.sourceforge.net/ * License : LGPL Description : Library for reading and writing (planned) AutoDesk (R) DXF files. dxflib is an opensource C++ library for reading and writing (planned) AutoDesk (R) DXF files. It's at the moment very simple but already provides the functionality to read basic entities of a DXF file. -- System Information: Debian Release: testing/unstable Architecture: powerpc Kernel: Linux auryn 2.4.19-ben20020804 #1 ons aug 7 23:25:59 GMT 2002 ppc Locale: LANG=da_DK, LC_CTYPE=da_DK -- no debconf information
Re: Bug#156852: ITP: ttf-dustismo -- general purpose gpl'ed truetype sans serif font
On Sun, Aug 18, 2002 at 12:21:36PM -0400, Joey Hess wrote: > Ben Armstrong wrote: > > Meta package. A virtual package is something quite different. It is not a > > package itself, but rather a package name, named in the "Provides:" control > > field, thus emacs21 and emacs20 both have "Provides" of the virutal package > > "emacsen". A meta package, on the other hand, is a real package that has > > nothing but control information in it, usually "Depends:" so when you > > install the meta package it causes a group of other packages to be > > installed. > > > > If I gave the impression that the grouping should be by foundry, that is not > > what I meant. I think I mentioned that the foundry may be present in the > > name of each actual font package, but that is all. I imagined a good > > grouping would be by function, i.e. "fonts suitable for foo". The grouping > > I suggested was ttf-latin for a nice collection of fonts supporting latin > > characters. > > I don't understand the reasoning behind bloating debian with a buch of > little packages that each include one font file. Can you explain? > Ben Armstrong said the following in the thread above called "Linux Fonts": "I question the name free-ttfonts. The convention seems to be: ttf[-foundryname]-fontorfamilyname" when I proposed the free-ttffonts package. So, I was planning on making a package for each source of fonts. He also suggested the use of a meta package. > Note the existing freefont and sharefont packages, which were compiled > by a Debian developer. Why should truetype fonts be packaged any > differently? > I don't think they should. My original intent was to make a free-ttffont package, and I'd rather do that. I guess since you're a dd and you were in the front row at debconf, that gives you a little seniority over Ben. ;) Seriously, I'd like to reach a consensus about this. Any more objections to a freettffonts package? I have received a few responses from font developers, so there will be a number of sources of ttf fonts. thanks michael -- michael cardenas | lead software engineer | lindows.com | hyperpoem.net "Being is what it is." - Jean-Paul Sartre pgpwyrFmgqXCm.pgp Description: PGP signature
Re: ITP: mini-dinstall -- daemon for updating Debian packages in a repository
Colin Walters wrote: > > I've been using a hackish program to manage my archive, so I'm very > > interested. It doesn't do quite what my old program does though > > (~joeyh/bin/package-sync). > > On which machine is this ~joeyh? auric, gluck, anything else I've checked my home directory out into lately. > > * I need the ability to keep my existing sources.list lines, which are > > pretty > > well-known. I will only ever have i386 and all in my repository, so I > > don't need separate directories. And $(ARCH) is icky. I lump everything > > into one directory and use: > > This is a bit tricky. It would be nice to support a few more layouts > though. The reason I don't support a single directory-style layout is > because you can't mix different architecture .debs in there, so I didn't > really find it useful. I think I might be willing to bend on this one, but it would be nice. > * A proper Incoming directory would be nice. I was confused at first > > about where exactly to upload stuff to and tried putting stuff in the > > i386/ and all/ directories. > > Well, basically each distribution is its own archive. There isn't > really a pool structure, because to have a pool type thing, you really > need a database to keep track of it, tools to manage it, and at that > point you might as well just use the full-blown dinstall. No, I was just looking for a incoming/ dirctory that I can put stuff into and it takes the files from, uploading direct to the base directory of an archive feels strange somehow. > > * I need the ability to have a hook that runs a program passing it a changes > > file name once it successfully puts a package into the archive. I use > > this type of hook to auto-update web pages for debian native packages, and > > I would like to use it as a way to launch a secondary dput to the main > > debian archive, since I currently upload everything to my own local > > archive > > and also to Incoming. > > That's a pretty cool idea. Should be implemented in the latest 0.0.1.0; > the option is called "post_installation_script". I hope you can do the pre_installation_target I mentioned on irc too. -- see shy jo
bug#152736 X doesn't start due to no cursor font!
I continue to have problems with this bug. Now X refuses to start because it can't locate the default cursor font. Here's the message: Fatal server error: could not open default cursor font 'cursor' But I do have a cursor font, even though I don't have xfonts-gimpers 1.8 installed (it refuses to install anyway). But I do have xfonts-artwiz installed. I purged xfonts-gimpers from my system and now X has a brain tumor. This is a critical bug and should have been fixed by now. apt-get install xfonts-gimpers Reading Package Lists... Done Building Dependency Tree... Done The following NEW packages will be installed: xfonts-gimpers 0 packages upgraded, 1 newly installed, 0 to remove and 1 not upgraded. Need to get 0B/26.5kB of archives. After unpacking 81.9kB will be used. Preconfiguring packages ... Selecting previously deselected package xfonts-gimpers. (Reading database ... 91196 files and directories currently installed.) Unpacking xfonts-gimpers (from .../xfonts-gimpers_1.8_all.deb) ... dpkg-divert: `diversion of /usr/X11R6/lib/X11/fonts/misc/cursor.pcf.gz to /usr/X11R6/lib/X11/fonts/misc/cursor.pcf.gz-base by xfonts-gimpers' clashes with `diversion of /usr/X11R6/lib/X11/fonts/misc/cursor.pcf.gz to /usr/X11R6/lib/X11/fonts/misc/cursor.pcf.gz-base by xfonts-artwiz' dpkg: error processing /var/cache/apt/archives/xfonts-gimpers_1.8_all.deb (--unpack): subprocess pre-installation script returned error exit status 2 Errors were encountered while processing: /var/cache/apt/archives/xfonts-gimpers_1.8_all.deb E: Sub-process /usr/bin/dpkg returned an error code (1) -- __ _ Carl B. Constantine / / (_)__ __ __ [EMAIL PROTECTED] / /__/ / _ \/ // /\ \/ / (2.4.18) http://www.duckwing.ca //_/_//_/\_ _/ /_/\_\ Debian 3.0 PGP key available on request "Microsoft is not the Borg. The Borg have better tech support."
Re: bug#152736 X doesn't start due to no cursor font!
> But I do have a cursor font, even though I don't have xfonts-gimpers 1.8 > installed (it refuses to install anyway). But I do have xfonts-artwiz > installed. I purged xfonts-gimpers from my system and now X has a brain > tumor. This is a critical bug and should have been fixed by now. apt-get install xfonts-artwiz- xfonts-gimpers That will deinstall xfonts-artwiz, so you can install xfonts-gimpers. You should file a bug on both of these packages since they need to conflict, or make use of alternatives instead of diversions for the common file. -- Debian - http://www.debian.org/ Linux 1394 - http://linux1394.sourceforge.net/ Subversion - http://subversion.tigris.org/ Deqo - http://www.deqo.com/
Re: Bug#156852: ITP: ttf-dustismo -- general purpose gpl'ed truetype sans serif font
> Ben Armstrong said the following in the thread above called "Linux > Fonts": > > "I question the name free-ttfonts. The convention seems to be: > > ttf[-foundryname]-fontorfamilyname" I think I know why this conventon developed for true-type fonts: [EMAIL PROTECTED]:~/debian>grep-available -F Package ttf- -s Package,Installed-Size | grep Installed-Size Installed-Size: 1512 Installed-Size: 2424 Installed-Size: 5948 Installed-Size: 3830 Installed-Size: 12484 Installed-Size: 2704 Installed-Size: 1300 Installed-Size: 28534 Installed-Size: 4660 Installed-Size: 960 Installed-Size: 5204 Installed-Size: 4244 Installed-Size: 10308 (The 960 is a false positive; libttf-dev). All of these packages are quite large, probably because they're all mostly languages with large complex character sets such as asian languages. That doesn't mean we have to mindlessly stick to it when packaging a 100k font though. We also have the example of freefont, which used uner 3 mb for 79 smaller type 1 fonts. > > Note the existing freefont and sharefont packages, which were compiled > > by a Debian developer. Why should truetype fonts be packaged any > > differently? > > > > I don't think they should. My original intent was to make a > free-ttffont package, and I'd rather do that. That makes sense to me. -- see shy jo
Re: bug#152736 X doesn't start due to no cursor font!
On Mon, 2002-08-19 at 04:55, Carl B. Constantine wrote: > I continue to have problems with this bug. Now X refuses to start > because it can't locate the default cursor font. Here's the message: > > Fatal server error: > could not open default cursor font 'cursor' > > But I do have a cursor font, even though I don't have xfonts-gimpers 1.8 > installed (it refuses to install anyway). But I do have xfonts-artwiz > installed. I purged xfonts-gimpers from my system and now X has a brain > tumor. This is a critical bug and should have been fixed by now. 1) You're very welcome trying to fix it and NMU it. I only have so much time to fix bugs. 2) Stop spamming me and the BTS, or use -quiet, I already receive a copy of the mail you send to the BTS. 3) I'm going to explain what's going on (or what I think is going on): xfonts-gimpers was piggy-backing on xfonts-artwiz' diversion of the cursor font, so that xfonts-artwiz and xfonts-gimpers could be installed at the same time. xfonts-artwiz split up the cursor and the fonts at some point, that's where the mess begins. I don't know what's happening, but when you upgrade xfonts-artwiz, it removes the X cursor. If somebody knows how to fix/debug this problem, I'd be very happy. Cheers -- /Bastien Nocera http://hadess.net signature.asc Description: This is a digitally signed message part
Re: bug#152736 X doesn't start due to no cursor font!
On Mon, 2002-08-19 at 05:02, Ben Collins wrote: > > But I do have a cursor font, even though I don't have xfonts-gimpers 1.8 > > installed (it refuses to install anyway). But I do have xfonts-artwiz > > installed. I purged xfonts-gimpers from my system and now X has a brain > > tumor. This is a critical bug and should have been fixed by now. > > apt-get install xfonts-artwiz- xfonts-gimpers > > That will deinstall xfonts-artwiz, so you can install xfonts-gimpers. > You should file a bug on both of these packages since they need to > conflict, or make use of alternatives instead of diversions for the > common file. They already conflict. apt-cache show xfonts-gimpers | grep Conflicts Conflicts: xfonts-artwiz (<< 2.0), big-cursor, artwiz-cursor How you solve the upgrade problem, that's something else. -- /Bastien Nocera http://hadess.net signature.asc Description: This is a digitally signed message part
Re: bug#152736 X doesn't start due to no cursor font!
* Bastien Nocera ([EMAIL PROTECTED]) wrote: > On Mon, 2002-08-19 at 04:55, Carl B. Constantine wrote: > > I continue to have problems with this bug. Now X refuses to start > > because it can't locate the default cursor font. Here's the message: > > > > Fatal server error: > > could not open default cursor font 'cursor' > > > > But I do have a cursor font, even though I don't have xfonts-gimpers 1.8 > > installed (it refuses to install anyway). But I do have xfonts-artwiz > > installed. I purged xfonts-gimpers from my system and now X has a brain > > tumor. This is a critical bug and should have been fixed by now. > > 1) You're very welcome trying to fix it and NMU it. I only have so much > time to fix bugs. I could, except I'm not 100% sure what the fix really is and I don't want to step on the toes of the other package maintainers (I'm only trying to become a debian developer myself with a package of ASD). > 2) Stop spamming me and the BTS, or use -quiet, I already receive a copy > of the mail you send to the BTS. I apologize for this. You should only get one copy of this mail (2 if you count the one to DD). > 3) I'm going to explain what's going on (or what I think is going on): > > xfonts-gimpers was piggy-backing on xfonts-artwiz' diversion of the > cursor font, so that xfonts-artwiz and xfonts-gimpers could be installed > at the same time. > > xfonts-artwiz split up the cursor and the fonts at some point, that's > where the mess begins. Yep. There's a file called /usr/X11R6/lib/X11/fonts/misc/cursor.pcf.gz-base in xfonts-base that was diverted from xfonts-artwiz. To me, this is a bug in xfonts-artwiz, it shouldn't do that. > I don't know what's happening, but when you upgrade xfonts-artwiz, it > removes the X cursor. Yep. My quick "hack" fix was to copy the file back to cursor.pcf.gz and that seems to work just fine. But it's really not "standard" and the appropriate package maintainers for xfonts-base, xfonts-artwiz, and xfonts-gimpers should get together and agree to the best course of action. I personally think, none of the extra packages should stomp on the xfonts-base versions unless they are completely renamed. -- __ _ Carl B. Constantine / / (_)__ __ __ [EMAIL PROTECTED] / /__/ / _ \/ // /\ \/ / (2.4.18) http://www.duckwing.ca //_/_//_/\_ _/ /_/\_\ Debian 3.0 PGP key available on request "Microsoft is not the Borg. The Borg have better tech support."
