Re: chroot administration
On Thu, Aug 15, 2002 at 12:16:41PM -0500, John Hasler wrote: > Perhaps it would be possible to use the FOIA to get the terms of the > contract? Bwa ha ha ha, it has been the Bush administration's directive to all Federal agencies since BEFORE September 11th of last year to flush all FOIA requests down the toilet. -- G. Branden Robinson|The first thing the communists do Debian GNU/Linux |when they take over a country is to [EMAIL PROTECTED] |outlaw cockfighting. http://people.debian.org/~branden/ |-- Oklahoma State Senator John Monks pgp2AQGRpEVEc.pgp Description: PGP signature
Re: GCC 3.2 transition
> "Joseph" == Joseph Carter <[EMAIL PROTECTED]> writes: Joseph> Sun's JDK. I know for a fact there's no use of dynamic C++ libraries in any JDK prior to 1.4.1 and I just check the latest 1.4.1 beta & find no mention of libstdc++ in any of the executables. If there's C++ code in there, it's statically linked. -- Stephen You will be a large breasted porno star in your next life - Chinese Fortune Cookie
Re: GCC 3.2 transition
On Fri, Aug 16, 2002 at 11:49:03PM -0700, Stephen Zander wrote: > > "Joseph" == Joseph Carter <[EMAIL PROTECTED]> writes: > Joseph> Sun's JDK. > > I know for a fact there's no use of dynamic C++ libraries in any JDK > prior to 1.4.1 and I just check the latest 1.4.1 beta & find no > mention of libstdc++ in any of the executables. If there's C++ code > in there, it's statically linked. Nowhere eh? [EMAIL PROTECTED]:/usr/local/j2sdk1.4.0_01/jre/plugin/i386/ns610$ ldd libjavaplugin_oji.so libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x40044000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4008e000) libdl.so.2 => /lib/libdl.so.2 (0x40168000) libstdc++-libc6.1-1.so.2 => /usr/lib/libstdc++-libc6.1-1.so.2 (0x4016b000) libm.so.6 => /lib/libm.so.6 (0x401ad000) libc.so.6 => /lib/libc.so.6 (0x401cf000) libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x402eb000) libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x402f3000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x8000) That's one hell of a figment of my imagination. Although, it does seem the plugin is the only thing which uses libstdc++. -- Joseph Carter <[EMAIL PROTECTED]> Hey, that's MY freak show! "Yes, your honour, I have RSA encryption code tattood on my penis. Shall I show the jury?" pgpxRbUwdJ5c6.pgp Description: PGP signature
debian-release list dead?
Hi, I intended to ask for removal of this list but Joey sugested to ask first whether anybody intents to use this list or finds it useful as it is now. In my -release folder I found: | Total messages since November 2001: 128 | (some spam has been fltered out by SA locally, I won't dig them out) | | Month Regular On Topic Mail Spam Other ((un)subscribe) |total msgs/threads (xpost to -boot, -project or -devel) | | 2001-11 2/2 (2/2)9 | 2001-12 3/3 (3/3) 15 | 2002-01 15 | 2002-02 9/1 (9/1) 13 | 2002-03 4/1 (4/1)61 | 2002-04 7/4 (3/3)8 | 2002-05 5/3 (4/2)4 | 2002-0661 | 2002-07 15 | 2002-08 (so far) 5 | Sum: 30/14 (25/12)962 | Probe Count: 30+96+2 == 128. ok. Over three times more spam than real messages. And of those real messages over 80% are really discussed on -boot or -project. The list sure looks dead to me. Does anyone disagree? Please followup to -release. yours, peter -- PGP signed and encrypted | .''`. ** Debian GNU/Linux ** messages preferred.| : :' : The universal | `. `' Operating System http://www.palfrader.org/ | `-http://www.debian.org/ pgpqImSi6PTcA.pgp Description: PGP signature
Re: GCC 3.2 transition
This one time, at band camp, Joseph Carter wrote: >[EMAIL PROTECTED]:/usr/local/j2sdk1.4.0_01/jre/plugin/i386/ns610$ ldd >libjavaplugin_oji.so > libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x40044000) > libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4008e000) > libdl.so.2 => /lib/libdl.so.2 (0x40168000) > libstdc++-libc6.1-1.so.2 => /usr/lib/libstdc++-libc6.1-1.so.2 >(0x4016b000) > libm.so.6 => /lib/libm.so.6 (0x401ad000) > libc.so.6 => /lib/libc.so.6 (0x401cf000) > libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x402eb000) > libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x402f3000) > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x8000) > >That's one hell of a figment of my imagination. Although, it does seem >the plugin is the only thing which uses libstdc++. ldd will traverse the library dependencies tree for all libraries, so it's possible that the libstdc++ requirement is caused by any of the other libraries in that list. What does objdump -p libjavaplugin_oji.so tell you? -- [EMAIL PROTECTED] http://spacepants.org/jaq.gpg
Re: debian-release list dead?
Previously Peter Palfrader wrote: > I intended to ask for removal of this list but Joey sugested to ask > first whether anybody intents to use this list or finds it useful as it > is now. I think it would be useful, but if the release manager doesn't use it we might as well remove it I guess. Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.wiggy.net/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: GCC 3.2 transition
>> Sean 'Shaleh' Perry <[EMAIL PROTECTED]> writes: > or do a staging in experimental or somewhere else. Upload everything > there, let people look at it for a day or two then move it over. That's the way I interpreted this, too. It's insane to try to NMU 1000 packages in one day. My one problem with this "solution" is that it will break people's system is a very visible way. For example, at the group were I work, 90% of our development is done in C++. Once this plan is carried out, an upgrade would break almost all our binaries in one fell sweep. Keeping the old libraries in a special directory would alleviate the problem for us. After some grep-dctrl hackery it looks like we have something like 250 *library* packages which are affected (this number is probably upwards biased). This would represent a 2% increase in the number of packages (1 GB increase in the archive size? 400 kB average size for a library package? Sounds ok, we have some pretty large library packages, but it's probably less). But the non-transparency of that solution makes it unattractive. Hacking the dynamic linker isn't sexy, but sounds doable. Besides the ugliness factor, is there anything that speaks against this? Is there an alternative that *doesn't* involve local recompiles? -- Marcelo | The duke had a mind that ticked like a clock and, like [EMAIL PROTECTED] | a clock, it regularly went cuckoo. | -- (Terry Pratchett, Wyrd Sisters)
Packages that Depend on libpng2/3 on their runtime libraries, but do not Depend on -dev packages
Hi, The following is a list of packages which I found to be missing dependencies on libpng2-dev or libpng3-dev, although their runtime library depend on libpng2 or libpng3. I want these packages to depend on libpng2-dev or libpng3-dev specifically, so that mix-match dependency of libpng2 and libpng3 will not occur. I only created the list manually, so I might be missing something. If anyone knows of a better way to find out a list, please tell me. libcamel2-dev libkmid-dev libgnomedb-dev libgnomeprint-dev libzvbi-dev libcapplet-dev libpisock-dev libkmid-dev libparagui1.0-dev libplot-dev libkdexparts-dev libgdk-pixbuf-dev librsvg-dev libcupsys2-dev libnobel-dev libvdkxdb-dev librrd0-dev libpisock-dev libeel-dev libming-dev libgarbo-dev koffice-dev libopenvrml0-dev libpolhem-dev libpanel-applet-dev libgtkxmhtml-dev libvdkbuiler-dev thanks, junichi -- [EMAIL PROTECTED] http://www.netfort.gr.jp/~dancer
Re: GCC 3.2 transition
>> Gerhard Tonn <[EMAIL PROTECTED]> writes: > The disadvantage is that we must know all C++ packages in advance. A large majority of C++ packages depend on libstdc++*; the ones that doesn't are probably libraries which have been linked using cc instead of c++. For example libsigc++-1.1-5 and libgtkmm1.3-14 would pass unnoticed even if they are both C++ libraries. This *might be* symptomatic of libtool libraries, counterexamples appreciated. In this case you'd have to look for typical C++ symbols in the output of, say, objdump -T, e.g. __pure_virtual, __dynamic_cast. In general you'd have to look for traces of C++ mangling. -- Marcelo | "Idiot I may be, but tied up I ain't." [EMAIL PROTECTED] | -- Gaspode the wonder dog |(Terry Pratchett, Moving Pictures)
Re: GCC 3.2 transition
On Sat, Aug 17, 2002 at 06:11:10PM +1000, Jamie Wilkinson wrote: > >That's one hell of a figment of my imagination. Although, it does seem > >the plugin is the only thing which uses libstdc++. > > ldd will traverse the library dependencies tree for all libraries, so it's > possible that the libstdc++ requirement is caused by any of the other > libraries in that list. > > What does objdump -p libjavaplugin_oji.so tell you? Dynamic Section: NEEDED libXt.so.6 NEEDED libX11.so.6 NEEDED libdl.so.2 NEEDED libstdc++-libc6.1-1.so.2 : I know it doesn't work because I didn't have the thing when I first tried to set up the JDK. I'll be needing it for school, so I'm watching the discussion of a free JDK environment setup package thingy kinda closely. I'm not a fan of things which might have bugs I can't identify and report. -- Joseph Carter <[EMAIL PROTECTED]>Sanity is counterproductive my Amiga 3000 has way more registers than x86 the local 7/11 has more registers than x86 pgpo9Bp7MyOqO.pgp Description: PGP signature
Re: Next Debconf
Tollef Fog Heen <[EMAIL PROTECTED]> writes: > I am planning Debconf 3 to be held in Oslo, from Friday July 18th to > Sunday July 20th. Nice initiative. -- Peter Makholm | I have something to say: It's better to burn in [EMAIL PROTECTED] | hell, than to fade away! http://hacking.dk | -- Kurgan
Re: Packages that Depend on libpng2/3 on their runtime libraries, but do not Depend on -dev packages
>> Junichi Uekawa <[EMAIL PROTECTED]> writes: > I only created the list manually, so I might be missing something. > If anyone knows of a better way to find out a list, please tell me. Check the library packages for a dependency on libpng2 or libpng3, obtain the Source package name, look for a -dev package coming out of that source package, look for a dependency on libpng[23]?-dev in there. That's easy to express with grep-dctrl, albeit a bit slow. -- Marcelo | "Woof. In tones of low menace." [EMAIL PROTECTED] | -- Gaspode the wonder dog |(Terry Pratchett, Moving Pictures)
Re: Bug#156503: microsoft changed its policy, msttcorefonts broken
Here's an update. After consulting with debian-legal, I emailed Bigelow and Holmes tonight to ask them to reconsider the license they have chosen so that they can be included in debian. If anyone is interested, I can post that email here. I've ITP'd the one latin ttf font I know of which is not packaged yet, dustismo, but it does not have very high quality hinting yet. I found this extensive list, of original font authors: http://jeff.cs.mcgill.ca/~luc/originalfonts.html and have begun to email the to ask about licensing. If anyone is interested, I can post that email here also. I got to about "Bakoma Fonts" so if anyone wants to help look through these fonts and email the authors of the ones that look valuable, that would be great. Let me know who how far you get, so we dont duplicate any. I emailed the author of metatype (metatype.sourceforge.net) to ask him about the status of his font and software, but have not received a response yet. I emailed the maintainer of pfaedit, since the author's email is not listed on his webpage, but have not received any response yet. Apparently, pfaedit is being actively developed though. It seems like it is a good font editor, but it needs a lot of work. I also found ttfmod, http://pfaedit.sourceforge.net/TtfMod/, a program specifically for doing truetype hinting, but as the website says "The Save and Save As commands may have problems. Let's pretend it's called ttfview for now...". I emailed the author to offer my help, but I haven't gotten a response yet. There was a changelog entry from June 2002. In case I didn't mention it before, there is this project: http://www.freesoftware.fsf.org/freefont/, which is not actually part of the fsf, but they are trying to make free truetype fonts. I will be ITP'ing and creating a ttf-latin meta package that depends on any useful ttf fonts I can find, including ttf-thryomanes. So, a lot of stuff is still pending, but I wanted to summarize my findings here. thanks for the input michael -- michael cardenas | lead software engineer | lindows.com | hyperpoem.net " -a crumpled bed that never existed- like a poem in the dark-escaped back into Oblivion." - Allen Ginsberg pgpKBpc5SOFwa.pgp Description: PGP signature
中国制造资源网
Title: ÖйúÖÆÔì×ÊÔ´Íø µÚÒ»ÆÚ 2002Äê8ÔÂ12ÈÕ ¡°ÖйúÖÆÔì×ÊÔ´Íø¡±¾ ¹ý½üÒ»ÄêµÄ²ß»®ºÍ¿ª·¢£¬ÖÕÓÚ¿ªÍ¨ºÍ´ó¼Ò¼ûÃæÁË£¬Ô¸¡°ÖйúÖÆÔì×ÊÔ´Íø¡±µÄ¿ªÍ¨±êÖ¾×ÅÖйúµÄÍøÂ磨µç×ÓÉÌÎñ£©·þÎñ¼Û¸ñµÄ½ø Ò»²½Í¸Ã÷»¯¡¢·þÎñÆ·ÖʵĽøÒ»²½×¨Òµ»¯£¡ ¡°ÖйúÖÆÔì×ÊÔ´Íø¡±µÄ¡ÖØÍƳöÖ¼ÔÚΪÍƶ¯È«¹úÉú²úºÍóÒ×ÐÍÖÐСÆóÒµÄܹ»²»Êܵ½¼Û¸ñ·½ÃæµÄ ÒòËضø¾¡Ôç×ßÉϵç×ÓÉÌÎñ֮·£¬¾¡ÔçÏíÊܵ½µ±½ñÉç»áÍøÂç´ø¸øÖÐСÆóÒµµÄ»úÓöºÍÏúÊÛÇþµÀµÄ½øÒ»²½ÍØ¿í¡£°ïÖúÖÐСÆóÒµ¾¡È«Á¦ ¹æ±Ü²¢»¯½â×Å·çÏÕ£¬°ïÖúÖÐСÆóÒµ±ð×ßÉÏ¡°ÉÏÍø¡±µÄÎóÇø¡ª¡ª»¨ÁËÇ®ÓÖ¼û²»µ½ÈκÎЧ¹û£¡ »¶ÓÄúµã»÷²éÔĸü¶àµÄ½éÉÜ ¡ú ¡¾¿ª·¢±³¾°-¾Óª²ßÂÔ-»áԱȨÒæ¡¿¡¾ ÂÌÉ«ÍøÕ¾½¨Éè¡¿¡¾³ÏÕ÷´úÀíÉÌ¡¿ ¡¡¡°ÖйúÖÆÔì×ÊÔ´Íø ¡±Ìرð°æ¿é½éÉÜ ¡ª¡ª ¸ü¶àÇë¼û www.China-Make.net Ïêϸ½éÉÜ ¡¤ÆóÒµµÄ³ÏÐŵµ°¸£º µç×ÓÉÌÎñ¿ÉÒÔ½â¾öÈÃÂòÂôË«·½ÇáËÉÕÒµ½¶Ô·½£¬µ«ÉÌÎñ»î¶¯ÖÐ×îÐèÒª½â¾öµÄÓ¦ ¸ÃÊÇÂòÂôË«·½ÈçºÎ½¨Á¢ÆðÐÅÈΣ¬Ò»¸öÆóÒµµÄ³ÏÐŲ»ÊÇÓÉÈκεÚÈý·½ÈÏÖ¤»ú¹¹¿ÉÒÔ½øÐÐÈÏÖ¤µÄ£¬¶øÓ¦¸ÃÊÇÔÚÉÌÎñ»î¶¯Öн¨Á¢ÆðÀ´ µÄÁ¼ºÃ¿Ú±®¶ø»ñµÃµÄ£¡ËùÒÔ¡°ÖйúÖÆÔì×ÊÔ´Íø¡±ÎªÃ¿¸öÈëפµÄÆóÒµ½¨Á¢ÁË×Ô¼ºµÄ¡°³ÏÐŵµ°¸¡±£¬ÓÉÈëפÆóÒµµÄÉÌÎñ¶ÔÏóÖ±½Ó¼Ç ¼ÈëפÆóÒµµÄ¡°³ÏÐŶȡ±£¬ÈκεÄÓÐûÓгÏÐŶ¼»á±»¼Ç¼ÔÚ°¸£¬¶øÇÒ²»Äܹ»É¾³ý£¬ÔÚ´Ë¡°ÖйúÖÆÔì×ÊÔ´Íø¡±Ï£ÍûûÓгÏÐŵÄÆó Òµ²»Òª¼ÓÈë¡°ÖйúÖÆÔì×ÊÔ´Íø¡±£¬·ñÔòÔçÍí»á±»ÆضÓÚÌìÏ£¡µ«ÈëפÆóÒµÈç¹ûÔÚÆäËüÈëפÆóÒµµÄ¡°³ÏÐŵµ°¸¡±ÖÐÎÜÏݶԷ½Ò»ÇÐ ºó¹û×Ô¼º³Ðµ££¬¡°ÖйúÖÆÔì×ÊÔ´Íø¡±½«±£Áô×·¾¿·¨ÂÉÔðÈεÄȨÀû£¡ ¡¤ÎÒµÄÉÌÎñÁã¾àÀ룺 ·²ÈëפÆóÒµÖ»ÒªµÇ¼ºó¾Í¿ÉÒÔÔÚÏßʹÓá°ÎÒµÄÉÌÎñÁã¾àÀ롱£¬¡°ÉÌÎñÁã¾àÀ롱µÄÖ÷Òª¹¦ÄÜ ÊÇÈëפÆóÒµ¿ÉÒÔÓëËùÓÐÔÚÏߵĻáÔ±ÆóÒµ¼°È«ÇòµÄ²É¹ºÉ̽øÐÐÃæ¶ÔÃæµÄÉÌÎñ̸ÅС¢Ï໥ѧϰµÈ£¬²¢¿ÉÒԼǼÏÂ̸¡°»°¡±ÄÚÈÝ£¬»¹ ¿ÉÒÔÉèÖúÃÓÑÃûµ¥ºÍºÚÃûµ¥£¡ ¡¤ÎÒµÄÉÌÎñ¼Çʱ¾£º µ±¡°ÖйúÖÆÔì×ÊÔ´Íø¡±µÄÈëפÆóÒµ´ïµ½Ò»¶¨ÊýÁ¿ºó£¬Èç¹ûÄú¶Ôij¸öÆóÒµ»ò²úÆ·»òÉÌ»ú»òÊÇ Ä³¸öÆóÒµ¼ÒÓÐÐËȤµ«ÕÒÆðÀ´ËäÈ»ÓÐËÑË÷ÒýÇ滹ÊÇÏԵò»·½±ãµÄ£¬»¹µÃ¼ÇÏÂÓÐÐËȤµÄ¶«Î÷¡£¡°ÎÒµÄÉÌÎñ¼Çʱ¾¡±¹¦ÄÜ¿ÉÒÔËæʱ½« ÄúÓÐÐËȤµÄ¶«Î÷µã»÷ÊղؽøÈ¥£¬ÄúÖ»ÒªµÇ¼½øÈëÄúµÄ¡°ÆóÒµÔÚÏ߰칫ÊÒ¡±¾Í»áһĿÁËÈ»£¬²»ÐèҪʱ¿ÉÒÔËæʱɾ³ý£¡ ¡¤ÆóÒµÔÚÏ߰칫ÊÒ£º ¡ô ×ÊÁÏÐ޸ģºÈëפÆóÒµ£¨ÖÐÓ¢ÎÄ£©ÐÅÏ¢×ÊÁÏ¡¢·¨ÈË×ÊÁϼ°ÕÕƬµÈÐ޸ġ¢Â¼È룻 ¡ô ³ÏÐŵµ°¸£ºÈëפÆóÒµ²é¿´×Ô¼ºµÄ¡°³ÏÐŵµ°¸¡±£¬»¹¿É×Ô¼ºÎª×Ô¼ºÆÀÊöÒ»·¬£» ¡ô ²úÆ··¢²¼£ºÈëפÆóÒµÔÚÏß¿ÉÒÔ·¢²¼Éú²ú²úÆ·ÐÅÏ¢£¬²¢°üÀ¨²úƷͼƬµÄ·¢²¼£» ¡ô ²úÆ·Ð޸ģºÈëפÆóÒµÔÚÏß¿ÉÒÔÐÞ¸ÄÉú²ú²úÆ·ÐÅÏ¢£¬²¢°üÀ¨²úƷͼƬµÄÐ޸ģ» ¡ô ÐÅÏ¢·¢²¼£ºÈëפÆóÒµÔÚÏß¿ÉÒÔÎÞÏÞÁ¿·¢²¼ÆóÒµµÄÉÌÒµÐÅÏ¢£¬°üÀ¨¹©ÇóºÏ×÷£» ¡ô ÁôÑÔ¹ÜÀí£º½¨Éè¡°ÂÌÉ«ÍøÕ¾¡±µÄÈëפÆóÒµ¿ÉÒÔÔÚÏß¹ÜÀí¡°ÂÌÉ«ÍøÕ¾¡±ÁôÑÔ£» ¡ô ¶©µ¥¹ÜÀí£º½¨Éè¡°ÂÌÉ«ÍøÕ¾¡±µÄÈëפÆóÒµ¿ÉÒÔÔÚÏß¹ÜÀí¡°ÂÌÉ«ÍøÕ¾¡±¶©µ¥£» ¡ô ÍøÕ¾»»·ô£º½¨Éè¡°ÂÌÉ«ÍøÕ¾¡±µÄÈëפÆóÒµ¿ÉÒÔÔÚÏ߸ü»»¡°ÂÌÉ«ÍøÕ¾¡±Ñùʽ£» ¡ô È«Çò²É¹º£ºÈëפÆóÒµ²é¿´È«Çò²É¹ºÐÅÏ¢ºÍ²É¹ºÉÌÃû¼£¬¡¾ÍÅÆ»áÔ±¡¿²»ÐУ»
Re: GCC 3.2 transition
[EMAIL PROTECTED] (Martin v. Loewis) writes: > Steve Langasek <[EMAIL PROTECTED]> writes: >> My concern is that locally compiled apps built against C++ >> libraries other than libstdc++ will silently stop working on >> upgrade. This is certainly not the most important issue facing us >> in the transition, but so far it seems to me that people are >> regarding it as so *un*important that it's not worth discussing at >> all. > > The breakage will not be silent: On startup of the application, they > will give an error message indicating the problem. I think that > problem is best solved by educating the users that such problems might > happen. This is not how Debian has done similar transitions in the past: libc4 to libc5, and libc5 to libc6, did not cause this breakage in Debian. Old programs continued to work without user or operator intervention (in fact libc4 binaries still work _today_ on some Debian systems.) If you change the ABI, you change the soname. That's what it's _for_. -- http://www.greenend.org.uk/rjk/
Re: GCC 3.2 transition
On Sat, Aug 17, 2002 at 13:27:24 +0100, Richard Kettlewell wrote: > This is not how Debian has done similar transitions in the past: libc4 to > libc5, and libc5 to libc6, did not cause this breakage in Debian. Old > programs continued to work without user or operator intervention (in fact > libc4 binaries still work _today_ on some Debian systems.) In some sense, the problem with the gcc 3.2 transition is that is is not radical enough a change; thus the breakage it can cause is rather subtle. libc4 -> libc5 was much more than a simple ABI change: it involved both API changes (dropping/deprecating support for a lot of non-portable constructs then in common use requiring e.g. compiling -DDIRENT_ILLEGAL_ACCESS) and a a change of executable format (a.out -> ELF; big changes in how shared libraries were built etc.). Ray -- We do not worry about Microsoft developing Open Source applications. Their revenue stream is based on a heroin addiction of selling ever more software. Red Hat's Bob Young quoted in http://www.theregister.co.uk/content/1/11321.html
Re: GCC 3.2 transition
On Sat, Aug 17, 2002 at 10:49:21AM +0200, Marcelo E. Magallon wrote: > >> Gerhard Tonn <[EMAIL PROTECTED]> writes: > > The disadvantage is that we must know all C++ packages in advance. > A large majority of C++ packages depend on libstdc++*; the ones that > doesn't are probably libraries which have been linked using cc instead > of c++. For example libsigc++-1.1-5 and libgtkmm1.3-14 would pass > unnoticed even if they are both C++ libraries. This *might be* > symptomatic of libtool libraries, counterexamples appreciated. In this > case you'd have to look for typical C++ symbols in the output of, say, > objdump -T, e.g. __pure_virtual, __dynamic_cast. In general you'd have > to look for traces of C++ mangling. It should be easy enough to find all the C++ libraries that need to be recompiled. First, find all the packages that depend on some version of libstdc++, and try to recompile them, libraries first. Then, out of the failed packages that have previously built successfully on our gcc-3.0 archs, grab out all library packages from the dependencies; sift and rebuild; lather, rinse, repeat. Anything that's missed by this process is either a package that requires manual intervention to get it working with gcc 3.x, or a package that has no dependencies on any other C++ packages. Steve Langasek postmodern programmer pgpnSqiwpUmnp.pgp Description: PGP signature
How to transition to G++ 3.2 wthout any breakage
Here is a plan on how to do so. It requires to modify dpkg but allows complete compatibility and no breakage of binaries (building with G++-2.95 would no longer work unless wrappers are written). 1. Create a new version of dpkg that does the following; In the postinst script it checks whether /usr/lib/g++-2.95 is present and if it isn't it scans symbols in all libraries to determine their ABI (symbols are mangled differently so this is possible) and moves all libraries with g++-2.95 mangled names in /usr/lib/g++-2.95 and modifies /var/lib/dpkg/info/.list/shlibs accordingly. Then it scans all binaries in the same ways and automatically builds wrapper scripts that adjust LD_LIBRARY_PATH and modifies the .info files accordingly. At every package installation, it checks whether the package to install depends on either this new version of dpkg or libstdc++5 or if some dependency depends on either. If so, it installs it normally (checking ABIs wouldn't hurt, but it's slow). Otherwise it checks and moves libraries and binaries as above (before installing it to avoid conflicts). 2. Stop autobuilding of C++ programs and libraries and set GCC 3.2 to be the default. No GCC 3.1 libraries or binaries may be built or uploaded from this point in time unless they explicitly set the desired compiler and until their dependencies are also converted to GCC 3.2. The new gcc package must be dependent on the new dpkg. 3. Modify C++ library packages to have a 'c' suffix and make them pre-depend on the new dpkg (and must do so forever until the new version of dpkg is guaranteed to be installed). They must not conflict with the old ones. The pre-dependency is required so that the dpkg postinst script will prevent conflicts with old libraries by moving them to /usr/lib/g++-2.95 4. Recompile C++ binary packages. shlibs should automatically make them dependent on GCC 3.2 libraries. If the user wants to compile with g++-2.95 and extra c++ libraries or install g++-2.95 binary packages without using dpkg, he is responsible for taking the necessary steps himself. Alternatively scripts may be provided for this. IMHO this is the proper way to handle this, requires minimal intervention by maintainers and allows to automagically install any .deb or .rpm regardless of the ABI they use since dpkg will check and fix (for .rpm's the new dpkg must be manually installed beforehand - new alien versions should also depend on the new dpkg). signature.asc Description: This is a digitally signed message part
Re: GCC 3.2 transition
[Matthew Wilcox] > I got sick of listening to people discuss the gcc 3.2 transition in an > uninformed manner. So I've whipped up a transition plan which will > hopefully get us from A to B without causing too much pain. Haha. > I'm entirely fallible and I don't pretend to understand all the issues > involved with doing the transition. But by writing down a plan at > least it can be updated and fixed before we have to start _doing_ > the transition. > > Comments and corrections welcomed. When this was discussed in June, one of the suggestions was to include the ABI format (compiler name/version) in the library package name and soname. Did you consider it when you wrote your transition plan? Check the debian-devel thread "C++ library packaging" starting 2002-06-27, http://lists.debian.org/debian-devel/2002/debian-devel-200206/msg01814.html>.
Re: GCC 3.2 transition
>> Steve Langasek <[EMAIL PROTECTED]> writes: > > A large majority of C++ packages depend on libstdc++*; the ones > > that doesn't are probably libraries which have been linked using > > cc instead of c++. For example libsigc++-1.1-5 and libgtkmm1.3-14 > > would pass unnoticed even if they are both C++ libraries. This > > *might be* symptomatic of libtool libraries, counterexamples > > appreciated. In this case you'd have to look for typical C++ > > symbols in the output of, say, objdump -T, e.g. __pure_virtual, > > __dynamic_cast. In general you'd have to look for traces of C++ > > mangling. > > It should be easy enough to find all the C++ libraries that need to be > recompiled. Sure. I was talking about the libraries that /don't/ have dependencies on libstdc++. libsigc++-1.1-5 and libgtkmm1.3-14 in my example both use libstdc++ but they don't have a dependency on it. The only reason why this has gone unnoticed is because you need to use a specific version of the c++ in order to be able to use these libraries. > Anything that's missed by this process is either a package that > requires manual intervention to get it working with gcc 3.x, or a > package that has no dependencies on any other C++ packages. That's my point. You can't use the binaries for the libraries I mentioned with any other version of c++ than the one used to compile those binaries, yet there's no information in the library that suggest it is actually a C++ library. Look: $ readelf -d /usr/lib/libgtkmm-1.3.so.14 | grep NEEDED | tr -s ' ' 0x0001 (NEEDED) Shared library: [libsigc-1.1.so.5] 0x0001 (NEEDED) Shared library: [libgtk-x11-2.0.so.0] 0x0001 (NEEDED) Shared library: [libgdk-x11-2.0.so.0] 0x0001 (NEEDED) Shared library: [libatk-1.0.so.0] 0x0001 (NEEDED) Shared library: [libgdk_pixbuf-2.0.so.0] 0x0001 (NEEDED) Shared library: [libm.so.6] 0x0001 (NEEDED) Shared library: [libpangoxft-1.0.so.0] 0x0001 (NEEDED) Shared library: [libpangox-1.0.so.0] 0x0001 (NEEDED) Shared library: [libpango-1.0.so.0] 0x0001 (NEEDED) Shared library: [libgobject-2.0.so.0] 0x0001 (NEEDED) Shared library: [libgmodule-2.0.so.0] 0x0001 (NEEDED) Shared library: [libdl.so.2] 0x0001 (NEEDED) Shared library: [libglib-2.0.so.0] 0x0001 (NEEDED) Shared library: [libc.so.6] -- Marcelo | They stared at them. Staring is one of the few things [EMAIL PROTECTED] | frogs are good at. Thinking isn't. | -- (Terry Pratchett, Wings)
Re: How to transition to G++ 3.2 wthout any breakage
On 17 Aug 2002, Luca Barbieri wrote: > Here is a plan on how to do so. It requires to modify dpkg but allows > complete compatibility and no breakage of binaries (building with > G++-2.95 would no longer work unless wrappers are written). > > 1. Create a new version of dpkg that does the following; > > In the postinst script it checks whether /usr/lib/g++-2.95 is present > and if it isn't it scans symbols in all libraries to determine their ABI > (symbols are mangled differently so this is possible) and moves all > libraries with g++-2.95 mangled names in /usr/lib/g++-2.95 and modifies > /var/lib/dpkg/info/.list/shlibs accordingly. > Then it scans all binaries in the same ways and automatically builds > wrapper scripts that adjust LD_LIBRARY_PATH and modifies the .info files > accordingly. > > At every package installation, it checks whether the package to install > depends on either this new version of dpkg or libstdc++5 or if some > dependency depends on either. > If so, it installs it normally (checking ABIs wouldn't hurt, but it's > slow). > Otherwise it checks and moves libraries and binaries as above (before > installing it to avoid conflicts). HAHAHAHAHA. No. .__. _|doogie|_ <-- dpkg hat
Re: GCC 3.2 transition
On Sat, Aug 17, 2002 at 10:34:24AM +0200, Marcelo E. Magallon wrote: > >> Sean 'Shaleh' Perry <[EMAIL PROTECTED]> writes: > > > or do a staging in experimental or somewhere else. Upload everything > > there, let people look at it for a day or two then move it over. > is probably upwards biased). This would represent a 2% increase in the > number of packages (1 GB increase in the archive size? 400 kB average > size for a library package? Sounds ok, we have some pretty large 1 GB*12 active archs in unstable == 12GB. Doesn't sound OK to take the debian mirror from ~60GB to ~72GB. Unless you are volunteering to buy 4 terabytes of disk space for our mirrors... Now, if we just did a subset of libraries that we have actual examples of being needed, that might be something to consider. We probably won't know what these libraries are until they stop working for people in sarge, however... -- Ryan Murray, Debian Developer ([EMAIL PROTECTED], [EMAIL PROTECTED]) The opinions expressed here are my own. pgpYD1T5kK641.pgp Description: PGP signature
Re: GCC 3.2 transition
On Sat, Aug 17, 2002 at 10:13:17AM -0500, Steve Langasek wrote: > On Sat, Aug 17, 2002 at 10:49:21AM +0200, Marcelo E. Magallon wrote: > > >> Gerhard Tonn <[EMAIL PROTECTED]> writes: > > > > The disadvantage is that we must know all C++ packages in advance. > > > A large majority of C++ packages depend on libstdc++*; the ones that > > doesn't are probably libraries which have been linked using cc instead > > of c++. For example libsigc++-1.1-5 and libgtkmm1.3-14 would pass > > unnoticed even if they are both C++ libraries. This *might be* > > symptomatic of libtool libraries, counterexamples appreciated. In this > > case you'd have to look for typical C++ symbols in the output of, say, > > objdump -T, e.g. __pure_virtual, __dynamic_cast. In general you'd have > > to look for traces of C++ mangling. > > It should be easy enough to find all the C++ libraries that need to be > recompiled. First, find all the packages that depend on some version of There's also the case that with gcc-2.95, you could cheat and write C++ without using the standard lib, and not have to link it. This ability is gone with 3.0 and higher. (note that telnet depends on libstdc++ on hppa -- but not any other arch). -- Ryan Murray, Debian Developer ([EMAIL PROTECTED], [EMAIL PROTECTED]) The opinions expressed here are my own. pgpmvnGHAdRYT.pgp Description: PGP signature
Notes on current sid and libpng
Hi, In case noone noticed this, and noone posted this, I will post my observation to the list: libgdk-imlib2 was introduced, to allow png3-linked gdk-imlib, so that gtk2.0 applications can link with gdk-imlib. libgdk-imlib-dev accompanies libgdk-imlib2 ( which I think should have been libgdk-imlib2-dev, but whatever). libgdk-imlib-dev and libgdk-pixbuf-dev don't depend on libpng2-dev nor libpng3-dev. It is now possible to build against libpng2-dev and libgdk-imlib-dev It is now possible to build against libgdk-imlib-dev (to link against libpng2-dev) and libgdk-imlib-dev (libpng3-dev) Christian Marillat decided to recompile libgnome against libgdk-imlib2, and libpng3, so some parts of gnome1 are recompiled against libpng3. I haven't had time to experiment, but I think there should be some occurrences of libpng2 and libpng3 being linked at the same time, which we tried to avoid, but failed. I think the same kind of thing is happening with libgnutls[45], and libgnomevfs2, so I think applications linked with libgnomevfs2 and libgnutls[45], which is many part of gnome2, experience some problem. Well, this is me summarizing what I think I saw in my reading of debian-devel-changes, and debian-bugs-dist. regards, junichi -- [EMAIL PROTECTED] http://www.netfort.gr.jp/~dancer
Re: How to transition to G++ 3.2 wthout any breakage
> HAHAHAHAHA. No. > > .__. > _|doogie|_ <-- dpkg hat > No because of technical reasons, or because it's too much work? IMHO since changing library filenames breaks compatibility with other distributions, this is the only way to allow installation of old packages (that, still IMHO, must absolutely not be broken). signature.asc Description: This is a digitally signed message part
Re: GCC 3.2 transition
>> [EMAIL PROTECTED] writes: > > is probably upwards biased). This would represent a 2% increase > > in the number of packages (1 GB increase in the archive size? 400 > > kB average size for a library package? Sounds ok, we have some > > pretty large > > 1 GB*12 active archs in unstable == 12GB. Doesn't sound OK to take > the debian mirror from ~60GB to ~72GB. Unless you are volunteering > to buy 4 terabytes of disk space for our mirrors... Uhm... 2% * 55 GB is what gave me that 1 GB figure. I thought that should have been obvious, sorry. It's 1 GB total, not 1 GB per architecture. > Now, if we just did a subset of libraries that we have actual > examples of being needed, that might be something to consider. We > probably won't know what these libraries are until they stop working > for people in sarge, however... I don't think I understand what you mean in that last sentence. -- Marcelo | One of the universal rules of happiness is: always [EMAIL PROTECTED] | be wary of any helpful item that weighs less than its | operating manual. | -- (Terry Pratchett, Jingo)
Re: How to transition to G++ 3.2 wthout any breakage
I forgot an important thing: all new non-C++ packages should be tagged
as non-C++ in some way so that dpkg doesn't need to scan them.
This should of course be done by having the build tools scan the package
build directory and set either a new field ('Uses-C++-ABI: No') or by
dependency on the new dpkg (dh_shlibdeps seems a good place to do this,
but not everything uses it).
Furthermore all new C++ packages should depend on a libstdc++ so that
this will no longer need to be done.
All binary and library packages also should be rebuilt at least once
before sarge.
However this doesn't need to be done immediately if a slight slowdown at
installation time is not a problem.
signature.asc
Description: This is a digitally signed message part
Re: GCC 3.2 transition
(first-time poster, beware of possible stupidity) I'll throw in my views on the subject: (1) If I understand correctly, SONAMEs are not meant to provide any other metadata than a reference to the *library's* ABI. Using SONAMEs for anything else, like which compiler the library was built with, will most probably result in very broken behavior, because the upstream authors have little way to ensure that their library with SONAME n will always be built with compiler x but their library with SONAME m will always be built with compiler y. (2) If (binary) programs from outside the distribution are to work with debian's libraries at all, the metadata about the compiler has to go somewhere. I'm not worried about the transition within debian (which can be some pain, too) but numerous third-party binaries that will probably break even though compatibility for them could have been retained. This rules out just replacing the old libraries with new ones compiled with the new compiler. (3) The easiest way to have metadata about the compiler version is using a separate directory. (4) If the libraries are linked against by their SONAMEs (making them indistinguishable), but the compiler version used in compiling the program is deducible, hacking the linker seems a plausible solution (akin to having two linkers in libc transition). Just my twopenny Panu
Re: GCC 3.2 transition
On 17 Aug 2002 17:47:17 +0200 Petter Reinholdtsen <[EMAIL PROTECTED]> wrote: > > Comments and corrections welcomed. > > When this was discussed in June, one of the suggestions was to include > the ABI format (compiler name/version) in the library package name and > soname. Did you consider it when you wrote your transition plan? > > Check the debian-devel thread "C++ library packaging" starting > 2002-06-27, > http://lists.debian.org/debian-devel/2002/debian-devel-200206/msg01814.html>. That involves fighting with upstream, and really unnecessary iff C++ interface was stabilized. Requiring compiler name and version is not something that is inherent in C++, just signifies that implementation of g++ has been unstable. Not that it shouldn't be done, but pointing out that the idea is rather too optimistic, and possibly restricted to gcc. regards, junichi -- [EMAIL PROTECTED] http://www.netfort.gr.jp/~dancer
Re: Notes on current sid and libpng
On Sun, Aug 18, 2002 at 01:23:41AM +0900, Junichi Uekawa wrote: > libgdk-imlib2 was introduced, to allow png3-linked gdk-imlib, so > that gtk2.0 applications can link with gdk-imlib. gtk2.0 applications should be using the gdk-pixbuf included with gtk2.0, which is already linked against png3. gdk-imlib1 links against gtk1, and should use the same ABI everyone else does -- png2. > It is now possible to build against libgdk-imlib-dev (to link > against libpng2-dev) and libgdk-imlib-dev (libpng3-dev) I'm guessing you mean gdk-pixbuf-dev in the first one. > Christian Marillat decided to recompile libgnome against > libgdk-imlib2, and libpng3, so some parts of gnome1 are recompiled > against libpng3. And more ABI breaking here -- why are we breaking gnome1 compat with others? Our current gnome transition plan is to move everything to gnome2. So why are we changing the ABI of something that is stable and to be removed/replaced by sarge release (not that I agree with it, but that's the current plan). > I think the same kind of thing is happening with libgnutls[45], and > libgnomevfs2, > so I think applications linked with libgnomevfs2 and libgnutls[45], which is > many part of > gnome2, experience some problem. No, it isn't the case here, as libgnutls4 no longer exists in the archive. -- Ryan Murray, Debian Developer ([EMAIL PROTECTED], [EMAIL PROTECTED]) The opinions expressed here are my own. pgpBpa3s3FgyB.pgp Description: PGP signature
Re: Notes on current sid and libpng
[EMAIL PROTECTED] writes: > On Sun, Aug 18, 2002 at 01:23:41AM +0900, Junichi Uekawa wrote: [...] > Christian Marillat decided to recompile libgnome against > libgdk-imlib2, and libpng3, so some parts of gnome1 are recompiled > against libpng3. > And more ABI breaking here -- why are we breaking gnome1 compat with others? > Our current gnome transition plan is to move everything to gnome2. So Not really. We are waiting for the tech-ctte decision (see bug #154950) for moving GNOME 2 in unstable. Christian
Re: GCC 3.2 transition
On Friday 16 August 2002 20:26, you wrote: > On Friday 16 August 2002 15:51, Matthew Wilcox wrote: > > If it is done by the platform porters a special build server has to be > setup for each platform recompiling all packages depending on c++. A wanna > build feature creating packages for NMUs can be used. I am currently doing this experiment on s390 without uploading of course. I have grepped the build logs of about 4000 packages that I have access to for g++|c++ and about 900 packages qualified. I am currently rebuilding these packages with gcc-3.2 using a local wanna-build DB. This will take some days. I will let you know the results. Gerhard
Re: GCC 3.2 transition
On Sat, Aug 17, 2002 at 05:59:42PM +0200, Marcelo E. Magallon wrote: > >> Steve Langasek <[EMAIL PROTECTED]> writes: > > > > A large majority of C++ packages depend on libstdc++*; the ones > > > that doesn't are probably libraries which have been linked using > > > cc instead of c++. For example libsigc++-1.1-5 and libgtkmm1.3-14 > > > would pass unnoticed even if they are both C++ libraries. This > > > *might be* symptomatic of libtool libraries, counterexamples > > > appreciated. In this case you'd have to look for typical C++ > > > symbols in the output of, say, objdump -T, e.g. __pure_virtual, > > > __dynamic_cast. In general you'd have to look for traces of C++ > > > mangling. > > > > It should be easy enough to find all the C++ libraries that need to be > > recompiled. > Sure. I was talking about the libraries that /don't/ have dependencies > on libstdc++. libsigc++-1.1-5 and libgtkmm1.3-14 in my example both > use libstdc++ but they don't have a dependency on it. The only reason > why this has gone unnoticed is because you need to use a specific > version of the c++ in order to be able to use these libraries. Are these libraries used by programs in our archive? Then most of those programs that depend on libsigc++ and libgtkmm will also depend on libstdc++; so when you go to recompile the programs with gcc 3.2, you'll find that the build fails because ld can't resolve (differently-mangled) symbol names in the libsigc++ and libgtkmm libraries. If there are no programs that use these libraries, or there are no programs that link against both these libraries and libstdc++, then these libraries do not have to be transitioned at the same time as the rest of the C++-using apps. The transition still has to be handled, it just isn't critical that it happen all at once. Steve Langasek postmodern programmer pgpHg3mTvh4XF.pgp Description: PGP signature
Re: GCC 3.2 transition
On Sat, Aug 17, 2002 at 09:24:34AM -0700, [EMAIL PROTECTED] wrote: > > It should be easy enough to find all the C++ libraries that need to be > > recompiled. First, find all the packages that depend on some version of > There's also the case that with gcc-2.95, you could cheat and write C++ > without using the standard lib, and not have to link it. This ability is > gone with 3.0 and higher. (note that telnet depends on libstdc++ on > hppa -- but not any other arch). But if it's not linked with anything, then, well, it's not linked with anything -- it has no dependencies on any of the affected packages, and is out of scope of this transition. Nothing needs to be coordinated to recompile a program that doesn't use libraries. Steve Langasek postmodern programmer pgp0zvPOui7Nj.pgp Description: PGP signature
Re: GCC 3.2 transition
>> Steve Langasek <[EMAIL PROTECTED]> writes: > so when you go to recompile the programs with gcc 3.2, you'll find > that the build fails because ld can't resolve (differently-mangled) > symbol names in the libsigc++ and libgtkmm libraries. Oh, I see what you meant before. Yeah, that sounds right. -- Marcelo | There are *no* inconsistencies in the Discworld books; [EMAIL PROTECTED] | ocassionally, however, there are alternate pasts. | -- (Terry Pratchett, alt.fan.pratchett)
Re: GCC 3.2 transition
On Sat, Aug 17, 2002 at 09:24:34AM -0700, [EMAIL PROTECTED] wrote: > On Sat, Aug 17, 2002 at 10:13:17AM -0500, Steve Langasek wrote: > > It should be easy enough to find all the C++ libraries that need to be > > recompiled. First, find all the packages that depend on some version of > > There's also the case that with gcc-2.95, you could cheat and write C++ > without using the standard lib, and not have to link it. In fact, given the mess that the STL has been across various Unix systems, including GNU, until arguably very recently, you could hardly blame commercial developers for doing exactly this ... -- Colin Watson [EMAIL PROTECTED]
Re: GCC 3.2 transition
On Sat, Aug 17, 2002 at 08:00:02PM +0300, Panu Kalliokoski wrote: > I'll throw in my views on the subject: > (1) If I understand correctly, SONAMEs are not meant to provide any > other metadata than a reference to the *library's* ABI. Using SONAMEs for > anything else, like which compiler the library was built with, will most > probably result in very broken behavior, because the upstream authors > have little way to ensure that their library with SONAME n will always > be built with compiler x but their library with SONAME m will always be > built with compiler y. But in a very real sense, the compiler used *IS* part of the library's ABI; if you recompile a C++ library with gcc 3.2 instead of gcc 2.95, the name of pratically *every* *single* *symbol* will change. That rather soundly eliminates any question of compatible ABIs between the two libraries. Of course, you may still be right that it's better to code this information somewhere other than in the soname itself. The problem is that currently, the transition plan doesn't allow for it to be stored anywhere other than in the package system. Steve Langasek postmodern programmer pgpgPnVtIEaTi.pgp Description: PGP signature
Re: How to transition to G++ 3.2 wthout any breakage
Luca Barbieri wrote: HAHAHAHAHA. No. .__. _|doogie|_ <-- dpkg hat No because of technical reasons, or because it's too much work? IMHO: No because it is unclean/ugly/fragile/hacky/total mess/etc. IMHO since changing library filenames breaks compatibility with other distributions, this is the only way to allow installation of old packages (that, still IMHO, must absolutely not be broken). All c++ sarge packages will be compiled with g++ 3.2 (AFAIK). All C++ code needs to be recompiled to work (still it's better than megahacks affecting whole distribution IMHO). If you want, you can put old libstdc++ and old (locally compiled) binaries somewhere in /usr/local and create wrappers by hand (or write wrapper generator - shouldn't be hard). -- [ Yenar Calentaure | [EMAIL PROTECTED] | http://yenar.host.sk ]
Re: Notes on current sid and libpng
On Sat, 2002-08-17 at 12:23, Junichi Uekawa wrote: > I haven't had time to experiment, but I think there should be some > occurrences of > libpng2 and libpng3 being linked at the same time, which we tried to avoid, > but > failed. Indeed. Try recompiling the latest Evolution, for example. It depends on imlib-dev (brings in png3), and it also depends on libgtkhtml-dev (which eventually brings in png2, by way of libgnomeprint-dev and libgdk-pixbuf-gnome-dev).
Re: GCC 3.2 transition
On Sat, Aug 17, 2002 at 09:24:34AM -0700, [EMAIL PROTECTED] wrote: > On Sat, Aug 17, 2002 at 10:13:17AM -0500, Steve Langasek wrote: > > On Sat, Aug 17, 2002 at 10:49:21AM +0200, Marcelo E. Magallon wrote: > > > >> Gerhard Tonn <[EMAIL PROTECTED]> writes: > > > > > > The disadvantage is that we must know all C++ packages in advance. > > > > > A large majority of C++ packages depend on libstdc++*; the ones that > > > doesn't are probably libraries which have been linked using cc instead > > > of c++. For example libsigc++-1.1-5 and libgtkmm1.3-14 would pass > > > unnoticed even if they are both C++ libraries. This *might be* > > > symptomatic of libtool libraries, counterexamples appreciated. In this > > > case you'd have to look for typical C++ symbols in the output of, say, > > > objdump -T, e.g. __pure_virtual, __dynamic_cast. In general you'd have > > > to look for traces of C++ mangling. > > > > It should be easy enough to find all the C++ libraries that need to be > > recompiled. First, find all the packages that depend on some version of > > There's also the case that with gcc-2.95, you could cheat and write C++ > without using the standard lib, and not have to link it. This ability is > gone with 3.0 and higher. (note that telnet depends on libstdc++ on > hppa -- but not any other arch). Eh? You should be able to link in just -lsupc++ and get everything necessary. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: GCC 3.2 transition
> "Joseph" == Joseph Carter <[EMAIL PROTECTED]> writes: Joseph> That's one hell of a figment of my imagination. Although, Joseph> it does seem the plugin is the only thing which uses Joseph> libstdc++. And I asked originally were you refering to plugin code or a JDK. plugin != JDK. -- Stephen You will be a large breasted porno star in your next life - Chinese Fortune Cookie
Re: GCC 3.2 transition
On Sat, Aug 17, 2002 at 01:38:42PM -0500, Steve Langasek wrote: > On Sat, Aug 17, 2002 at 08:00:02PM +0300, Panu Kalliokoski wrote: > > I'll throw in my views on the subject: > > > (1) If I understand correctly, SONAMEs are not meant to provide any > > other metadata than a reference to the *library's* ABI. Using SONAMEs for > > anything else, like which compiler the library was built with, will most > > probably result in very broken behavior, because the upstream authors > > have little way to ensure that their library with SONAME n will always > > be built with compiler x but their library with SONAME m will always be > > built with compiler y. > > But in a very real sense, the compiler used *IS* part of the library's > ABI; if you recompile a C++ library with gcc 3.2 instead of gcc 2.95, > the name of pratically *every* *single* *symbol* will change. That > rather soundly eliminates any question of compatible ABIs between the two > libraries. 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?), 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. > Of course, you may still be right that it's better to code this > information somewhere other than in the soname itself. The problem is > that currently, the transition plan doesn't allow for it to be stored > anywhere other than in the package system. I, at least, hope that the ...c versions can coëxist with the old versions. (i.e. not the packages, nor the libraries, should conflict in any way.) Panu
Re: Help would be appreciated regarding libpng12.so/libpng.so.3
Moving the thread off of private. On Sat, Aug 17, 2002 at 05:41:39PM +0200, Marcelo E. Magallon wrote: > 2. I don't understand your point. In fact I can't see what your point > is. I suspect Glenn can't either since the discussion when arround > in circles a couple of times. Gratuitous changes to library names are bad? We're still struggling with the png2 -> png3 upgrade, because of how much it affects; throwing a new soname into the mix is not helpful. > 3. After looking at the beta release of libpng 1.2.5, it builds a > library named libpng12 with soname libpng12.so.0. What's the > problem with that? As Havoc said, RH is even shipping packages > using that soname. RedHat has packages in Rawhide that use this name. That's not the same thing as shipping it, IMHO; it may not have made its way into a release yet. > We'd be actually *happy* with that. It forces upstream to declare > a dependency on a specific png release (you need to include > something like -lpng12 in your link line). That's *good* for us, > isn't it? Not particularly. It's the Debian maintainer's job to vet the upstream sources and make sure they work with whatever else we have in the archive. The libpng API changes very infrequently, and upgrading to a new library usually means doing nothing more than a recompile. Having upstream specify -lpng12 just makes more work for us. This soname change may help RedHat, but it doesn't help us at all. > is argueable. What's a hassle is getting upstream to convert to > the new version. For Havoc's purposes it'd suffice if the png > folks would rerelease libpng 1.0.x and 1.2.x using a) pkg-config b) > versioned include directories and c) library names of libpng-1 and > libpng-3 (or whatever makes Glenn happy). (Please reread what I > said: library names, not sonames). There'd be no issue if only the filenames had changed. That's not what's happening. Steve Langasek postmodern programmer pgpYKcVlA0jfr.pgp Description: PGP signature
debian-security-announce and bugtraq
it seems like people still don't get that bugtraq is subscribed to debian-security-announce... And bugtraq seems unable to add some Footer to the posts that clarifies this... Couldn't we - unsubscribe bugtraq from our list - send out security-announces to bugtraq separately? Gruss, Erich Schubert P.S. Or wasn't this recent mail from branden another try to unsubscribe from our postings to bugtraq? I don't remember much recent complaints... maybe that issue is already settled. -- erich@(mucl.de|debian.org)--GPG Key ID: 4B3A135C There are only 10 types of people in the world: Those who understand binary and those who don't Ein Freund ist ein Geschenk, das man sich selbst macht. "Wissen ist Macht" - wenn man das richtige daraus macht.
Re: Notes on current sid and libpng
On Sat, Aug 17, 2002 at 14:51:04 -0400, Colin Walters wrote: > Indeed. Try recompiling the latest Evolution, for example. Gnumeric is another; see my messages in the "New gnome-libs package build against libpng3" thread on debian-gtk-gnome. Ray -- [...] computer source code, though unintelligible to many, is the preferred method of communication among computer programmers. http://pacer.ca6.uscourts.gov/cgi-bin/getopn.pl?OPINION=00a0117p.06
Re: How to transition to G++ 3.2 wthout any breakage
On 17 Aug 2002, Luca Barbieri wrote: > > HAHAHAHAHA. No. > > > > .__. > > _|doogie|_ <-- dpkg hat > > > No because of technical reasons, or because it's too much work? Because you have no clue what you are talking about.
Re: How to transition to G++ 3.2 wthout any breakage
> Because you have no clue what you are talking about. The problem is that people who have a clue are proposing solutions that would break existing packages and would cause the user to recompile everything he has compiled on his own. Furthermore, they don't explain what is wrong with the approach of people that are trying to solve the problem in the best way. The same is happening with GTK and libpng (that, *of* *course* can be solved without recompiling packages even though it might require modifying either GTK, ld.so, dpkg or libpng). The problem with this approach is that it saves the maintainer's time, but wastes users' time, which is not good. Users now have to either recompile all packages that use C++ or GTK or alternatively find out how to correctly fix the problem (as opposed to just taking the easiest route, that appears to be the Debian way). Anyway, I'm trying to implement it. The only problem that I noticed is that things like CORBA_string__free are mistaken as v2 ABI symbols. However it seems possible to accurately identify v5 ABI symbols (of course not 100% accurately for every possible library but probably for all the ones in Debian) so it should be possible to work around that. OTOH, I found out that with a C program scanning is fast enough that we can just scan packages without checking dependencies first. signature.asc Description: This is a digitally signed message part
Re: Help would be appreciated regarding libpng12.so/libpng.so.3
>> Steve Langasek <[EMAIL PROTECTED]> writes: > Moving the thread off of private. Thank you. > > 2. I don't understand your point. In fact I can't see what your point > > is. I suspect Glenn can't either since the discussion when arround > > in circles a couple of times. > > Gratuitous changes to library names are bad? We're still struggling > with the png2 -> png3 upgrade, because of how much it affects; > throwing a new soname into the mix is not helpful. In general yes. What Havoc is after (and I know this by reading his posts on some gnome mailing list) is parallel installable versions of libpng. AFAICS Havoc is the one behind the whole libfooN bussiness. I might be misplacing authorship, but I've gotten the feeling he's one who's been pushing that. Having parallel installable versions of libraries is in general a good thing, even if the names of the library look ugly. It is a very nice thing to have on multiuser machines. Everyone seems to want something different installed. I concur with you insofar I don't see the need for changing the *SONAME* of the library (AFAICS the idiotic SONAMEs come from libtool). But changing the name of the library is ok and I really fail to see a major reason why this is bad. Sure, it breaks builds, but that's it. Or do I miss something? (I'm not saying that breaking builds ins't bad, but it not as bad as breaking people's systems). > RedHat has packages in Rawhide that use this name. That's not the > same thing as shipping it, IMHO; it may not have made its way into a > release yet. Yes, bad wording on my part. > > We'd be actually *happy* with that. It forces upstream to declare > > a dependency on a specific png release (you need to include > > something like -lpng12 in your link line). That's *good* for us, > > isn't it? > > Not particularly. It's the Debian maintainer's job to vet the > upstream sources and make sure they work with whatever else we have > in the archive. Uhm... in this case, yes, that's possible, you are right, since libpng 2 and 3 have compatible APIs. PNG suffers from bad design (it exposes processor-specific functions in the API) and bad planning (see this), but we can't do much about that. > The libpng API changes very infrequently, and upgrading to a new > library usually means doing nothing more than a recompile. Having > upstream specify -lpng12 just makes more work for us. But it saves us headaches. I still hold it's better if upstream calls for a specific version since that solves the inter-distribution operability problem at the root level. If upstream says they want libpng 2, they get libpng 2. And every distribution gets the same. If it happens that some widely used library calls for libpng 2 while everything else commonly used in conjunction with this hypothetical library uses libpng 3, then the distributions will put pressure on upstream to change the soname name and call for libpng 3. We have two problems to solve: the short term one (what do we do about this current situation) and the long term one (educate upstreams about this kind of thing). If get can get help from other upstreams in order to achieve the second goal, that's a good thing on my book. > This soname change may help RedHat, but it doesn't help us at all. I think Junichi said this is not a recent change. Apparently we've been skipping newer upstream releases because of this change. Our libpng is 1.2.1, upstream's beta is 1.2.5. Junichi said fixes are being actively backported. That sounds like more work for our people, which doesn't help us. -- Marcelo | Item 42: Use private inheritance judiciously [EMAIL PROTECTED] | -- Scott Meyers, Effective C++
HELP - Screen is flooded with DHCP messages.
Firewall died, taking down disk. New disk: clean install of Woody upgraded to testing. Two network cards: 3COM 3C905C 10/100M as (internal) card (eth0) 3COM Etherlink III as cable modem facing (external) card eth1. Simple Iptables firewall. DHCP needs to work, as does ddtc for resolving dynamic addresses to .ddts.net. Now flooded with screens full of IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:04:76:de:b9:53:08:00 SRC=0.0.0.0 DST=255,255,255,255 LEN=328 TOS=0x10 PREC=0x00 TTL=64 ID=0 PROTO=UDP SPT=68 DPT=67 LEN=308 on all machines. Advice please - posting to debian-devel because I know I'll get some competence here! Andy
Re: debian-security-announce and bugtraq
On Sat, Aug 17, 2002 at 09:46:42PM +0200, Erich Schubert wrote: > it seems like people still don't get that bugtraq is subscribed to > debian-security-announce... > And bugtraq seems unable to add some Footer to the posts that clarifies > this... > > Couldn't we > - unsubscribe bugtraq from our list > - send out security-announces to bugtraq separately? > > Gruss, > Erich Schubert > > P.S. Or wasn't this recent mail from branden another try to unsubscribe > from our postings to bugtraq? I don't remember much recent complaints... > maybe that issue is already settled. They chose (and choose, repeatedly) to subscribe. There's really squat we can do about it except continue complaining to them. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: HELP - Screen is flooded with DHCP messages.
On Sat, Aug 17, 2002 at 20:56:48 +, Andrew M.A. Cater wrote: > Now flooded with screens full of > IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:04:76:de:b9:53:08:00 SRC=0.0.0.0 > DST=255,255,255,255 LEN=328 TOS=0x10 PREC=0x00 TTL=64 ID=0 PROTO=UDP SPT=68 > DPT=67 LEN=308 > on all machines. > > Advice please http://lists.debian.org/debian-user/2002/debian-user-200203/msg03266.html HTH, Ray -- The "free" in "free software" refers to freedom, not price; specifically, that all computer users should have the freedom to study, change, and redistribute the software that they use. RMS in http://weblog.mercurycenter.com/ejournal/stories/storyReader$664
Re: GCC 3.2 transition
On Sat, Aug 17, 2002 at 12:05:59PM -0700, Stephen Zander wrote: > Joseph> That's one hell of a figment of my imagination. Although, > Joseph> it does seem the plugin is the only thing which uses > Joseph> libstdc++. > > And I asked originally were you refering to plugin code or a JDK. > plugin != JDK. I downloaded JDK, I got a plugin. JDK includes plugin, therefore JDK has dependencies on old libstdc++. -- Joseph Carter <[EMAIL PROTECTED]>What're you looking at? I'm starting to think the gene pool could use a little chlorine. pgpilrA8WhUcP.pgp Description: PGP signature
Re: HELP - Screen is flooded with DHCP messages.
> IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:04:76:de:b9:53:08:00 SRC=0.0.0.0 > DST=255,255,255,255 LEN=328 TOS=0x10 PREC=0x00 TTL=64 ID=0 PROTO=UDP SPT=68 > DPT=67 LEN=308 > on all machines. Configure your firewall correctly. That message is a DHCP request. Just don't log DHCP requests. DHCP requests need to be send as broadcasts... Greetings, Erich -- 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. Glück gleicht durch Höhe aus, was ihm an Länge fehlt. "Wissen ist Macht" - wenn man das richtige daraus macht.
Re: Help would be appreciated regarding libpng12.so/libpng.so.3
On Sat, Aug 17, 2002 at 10:34:54PM +0200, Marcelo E. Magallon wrote: > > Gratuitous changes to library names are bad? We're still struggling > > with the png2 -> png3 upgrade, because of how much it affects; > > throwing a new soname into the mix is not helpful. > In general yes. What Havoc is after (and I know this by reading his > posts on some gnome mailing list) is parallel installable versions of > libpng. AFAICS Havoc is the one behind the whole libfooN bussiness. I > might be misplacing authorship, but I've gotten the feeling he's one > who's been pushing that. > Having parallel installable versions of libraries is in general a good > thing, even if the names of the library look ugly. It is a very nice > thing to have on multiuser machines. Everyone seems to want something > different installed. > I concur with you insofar I don't see the need for changing the > *SONAME* of the library (AFAICS the idiotic SONAMEs come from > libtool). That is the core of the objection. So we are in agreement. You can have parallel installable versions of the -dev packages without changing the soname scheme. (It's wrong to say this allows "parallel installable versions of the lib" -- we ALREADY have that capability, with every shared library on the system! This matters only for -dev packages.) > But changing the name of the library is ok and I really fail > to see a major reason why this is bad. Sure, it breaks builds, but > that's it. Or do I miss something? (I'm not saying that breaking > builds ins't bad, but it not as bad as breaking people's systems). I don't see that changing the library name is necessarily bad or good. We in Debian don't need it, we have ways of working around these issues. If other distros have weak packaging systems or differing approaches to libraries that necessitate this, fine. But let it be done in a way that doesn't screw over those that have already begun migrating to libpng.so.3. > > The libpng API changes very infrequently, and upgrading to a new > > library usually means doing nothing more than a recompile. Having > > upstream specify -lpng12 just makes more work for us. > But it saves us headaches. I still hold it's better if upstream > calls for a specific version since that solves the inter-distribution > operability problem at the root level. If upstream says they want > libpng 2, they get libpng 2. And every distribution gets the same. If > it happens that some widely used library calls for libpng 2 while > everything else commonly used in conjunction with this hypothetical > library uses libpng 3, then the distributions will put pressure on > upstream to change the soname name and call for libpng 3. I don't believe it saves us headaches. Having versioned symbols saves us headaches; anything else is a wash. > > This soname change may help RedHat, but it doesn't help us at all. > I think Junichi said this is not a recent change. Apparently we've > been skipping newer upstream releases because of this change. Our > libpng is 1.2.1, upstream's beta is 1.2.5. Junichi said fixes are > being actively backported. That sounds like more work for our people, > which doesn't help us. I suppose I should look at upstream's changelog, to see when this soname change took place. If it happened 6 months ago, I guess we'll have to pay the price for an inactive package maintainer. Steve Langasek postmodern programmer pgpqtoIptDRPg.pgp Description: PGP signature
Bug#157104: wnpp: ITP: totem - A simple movie player for the Gnome desktop based on xine.
Package: wnpp Version: N/A Severity: wishlist * Package name : totem Version : 0.8 Upstream Author : Bastien Nocera <[EMAIL PROTECTED]> * URL: http://www.hadess.net/totem.php3 * License : GPL v2 Description : A simple movie player for the Gnome desktop based on xine. Its features : * Play any xine supported file * Full-screen mode (move your mouse and you get a button to exit this mode) * Seek and Volume controls * Aspect ratio toggling * Full keyboard control * Simple playlist * Gnome and Nautilus integration (Totem registers the file-types and adds a menu item) -- System Information Debian Release: testing/unstable Kernel Version: Linux seb128 2.4.19 #1 sam aoû 3 11:33:58 CEST 2002 i686 unknown unknown GNU/Linux
Re: Help would be appreciated regarding libpng12.so/libpng.so.3
On Sat, 17 Aug 2002 17:07:27 -0500 Steve Langasek <[EMAIL PROTECTED]> wrote: > > I think Junichi said this is not a recent change. Apparently we've > > been skipping newer upstream releases because of this change. Our > > libpng is 1.2.1, upstream's beta is 1.2.5. Junichi said fixes are > > being actively backported. That sounds like more work for our people, > > which doesn't help us. > > I suppose I should look at upstream's changelog, to see when this soname > change took place. If it happened 6 months ago, I guess we'll have to > pay the price for an inactive package maintainer. It started to happen, according to the CHANGELOG, about 6 months ago. libpng does not use autoconf/automake, and the upstream has to edit 22 makefiles. It struck hard, with 1.2.4 release which was meant to be a security fix. Last maintainer upload was December 2001, and I started seriously looking at libpng (as a Debian maintainer, looking at new upstream versions) around July this year. And yes, we were kinda busy releasing woody at that time in between ... regards, junichi -- [EMAIL PROTECTED] http://www.netfort.gr.jp/~dancer
Re: HELP - Screen is flooded with DHCP messages.
On Sat, Aug 17, 2002 at 11:58:07PM +0200, Erich Schubert wrote: > > IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:04:76:de:b9:53:08:00 SRC=0.0.0.0 > > DST=255,255,255,255 LEN=328 TOS=0x10 PREC=0x00 TTL=64 ID=0 PROTO=UDP SPT=68 > > DPT=67 LEN=308 > > on all machines. > > Configure your firewall correctly. > That message is a DHCP request. Just don't log DHCP requests. > DHCP requests need to be send as broadcasts... Alternatively, if you don't mind them being logged but do mind them getting blasted to the system console, set the default console logging level to something other than the default "insane amounts of drivel" setting; e.g.: echo 4 > /proc/sys/kernel/printk -- G. Branden Robinson| There's nothing an agnostic can't Debian GNU/Linux | do if he doesn't know whether he [EMAIL PROTECTED] | believes in it or not. http://people.debian.org/~branden/ | -- Graham Chapman pgptsCCZ9nd8r.pgp Description: PGP signature
Re: debian-security-announce and bugtraq
On Sat, Aug 17, 2002 at 09:46:42PM +0200, Erich Schubert wrote: > it seems like people still don't get that bugtraq is subscribed to > debian-security-announce... > And bugtraq seems unable to add some Footer to the posts that clarifies > this... [...] > P.S. Or wasn't this recent mail from branden another try to unsubscribe > from our postings to bugtraq? I don't remember much recent complaints... > maybe that issue is already settled. IMO we should add a boilerplate paragraph to our security advisories that drills this info into people's heads. It aggravates me how moronic Bugtraq is being about this. -- G. Branden Robinson| Debian GNU/Linux | If existence exists, [EMAIL PROTECTED] | why create a creator? http://people.debian.org/~branden/ | pgpc4HeaPG3Wl.pgp Description: PGP signature
gnome 2.0 breakage
Is anyone else seeing major breakage on Gnome2 tonight? On current debian ppc sid, I found after rebooting that while gdm2 still worked and I could login that Nautilus2 is very broken and reports that variety of directory as being invalid with alerts at startup. Also the Applications menus are empty. I grabbed everything built tonight on incoming.debian.org but that didn't help. Jack
Bug#157133: ITP: libtime-piece-perl -- Perl module for object oriented time objects
Package: wnpp Version: N/A; reported 2002-08-17 Severity: wishlist * Package name: libtime-piece-perl Version : 1.07 Upstream Author : Matt Sergeant <[EMAIL PROTECTED]> Jarkko Hietaniemi <[EMAIL PROTECTED]> * URL : http://www.cpan.org/ * License : Artistic Description : Perl module for object oriented time objects This module replaces the standard localtime and gmtime functions with implementations that return objects. It does so in a backwards compatible manner, so that using localtime/gmtime in the way documented in perlfunc will still return what you expect. Time::Piece does the right thing with the return value from localtime: - in list context it returns a list of values - in scalar context it returns a Time::Piece object - when stringified (or printed), Time::Piece objects look like the output from scalar(localtime) Beyond that, Time::Piece objects allow you to get any part of the date/time via method calls, plus they allow you to get at the string form of the week day and month. It has methods for julian days, and some simple date arithmetic options. Time::Piece also gives you easy access to your C library's strftime and strptime functions, so you can parse and output locale sensitive dates to your heart's content :-) -- 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: gnome 2.0 breakage
It would appear the problem may be with the gnome-vfs2 currently built on voltaire. I had built my own copy waiting for it to come off of voltaire earlier in the week. With that locally built copy of gnome-vfs2 installed, nautilus2 works fine. Also, if I rebuild current gnome-vfs2 against current debian sid locally that copy of gnome-vfs2 works fine. For some reason the same package version off of voltaire causes nautilus2 to flake out and not recognize paths as being valid. Jack
