Re: Upcoming removal of orphaned packages
On Mon, 20 Jun 2005, Andreas Tille wrote: README.Debian for the C++ version. If there is nobody hwo would be really keen on taking this over himself, I'll go for an upload in the next couple of days. I prepared a new upload but browsing through the list of bugs I found out that we might be able a new upstream maintainer (#87017). I wrote Jonathan an e-mail and would like to wait for a response for some days. I tagged the wnpp bug report ITA. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Work-needing packages report for Jun 24, 2005
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 225 (new: 28) Total number of packages offered up for adoption: 100 (new: 4) Total number of packages requested help for: 10 (new: 0) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: ACL (#314683), orphaned 6 days ago Description: extra Control (#314682), orphaned 6 days ago Description: optional Extended (#314683), orphaned 6 days ago Description: extra Library (#314682), orphaned 6 days ago Description: optional Perl (#314682), orphaned 6 days ago Description: optional System (#314682), orphaned 6 days ago Description: optional Version (#314682), orphaned 6 days ago Description: optional access (#314682), orphaned 6 days ago Description: optional and (#314683), orphaned 6 days ago Description: extra attributes (#314683), orphaned 6 days ago Description: extra dutch (#314839), orphaned 5 days ago Description: Dutch dictionary for aspell, in new (August 1996) spelling ext2 (#314683), orphaned 6 days ago Description: extra for (#314682), orphaned 6 days ago Description: optional generic (#314682), orphaned 6 days ago Description: optional gnulib (#314667), orphaned 6 days ago Description: the GNU Portability Library in (#314682), orphaned 6 days ago Description: optional kernel-patches (#314683), orphaned 6 days ago Description: extra libauthen-radius-perl (#314851), orphaned 5 days ago Description: user authentication against radius openduke (#314675), orphaned 6 days ago Description: Duke Nukem 3D map viewer posixtestsuite (#314668), orphaned 6 days ago Description: POSIX conformance test suite (dummy package) pvpgn (#314670), orphaned 6 days ago Description: Gaming server that emulates Battle.net(R) python-slang (#314994), orphaned 4 days ago Description: Python bindings for S-LANG Reverse Depends: woody texi2html (#314843), orphaned 5 days ago Description: Convert Texinfo files to HTML Reverse Depends: translate-docformat tuxtype (#315236), orphaned 2 days ago Description: Educational Typing Tutor Game Starring Tux Reverse Depends: junior-typing uncc (#314672), orphaned 6 days ago Description: C decompiler for i386 woody (#314996), orphaned 4 days ago Description: Hierarchic text editor xbox-raincoat (#314674), orphaned 6 days ago Description: Xbox BIOS flasher xfs-xtt (#314882), orphaned 5 days ago Description: X-TrueType font server 197 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/orphaned for a complete list. The following packages have been given up for adoption: jython (#315289), offered 2 days ago Description: Python seamlessly integrated with Java kbear (#315340), offered 2 days ago Description: graphical ftp client for KDE kdbg (#315336), offered 2 days ago Description: graphical debugger interface Reverse Depends: kde-devel-extras kprof (#315337), offered 2 days ago Description: a KDE3 visual tool to help analyze profiling results Reverse Depends: kde-devel-extras 96 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: athcool (#278442), requested 240 days ago Description: Enable powersaving mode for Athlon/Duron processors debtags (#262927), requested 325 days ago Description: Evolution of package metadata Reverse Depends: debtags-edit dselect (#282283), requested 215 days ago Description: a user tool to manage Debian packages Reverse Depends: dpkg grub (#248397), requested 409 days ago Description: GRand Unified Bootloader Reverse Depends: replicator grubconf dfsbuild webmin-grub grub-splashimages mwavem (#313369), requested 10 days ago (non-free) Description: Mwave/ACP modem support software parted (#262885), requested 325 days ago Description: Searching co-maintainer for the parted package. Reverse Depends: libparted1.6-dev elilo-installer mdcfg-utils libparted1.6-i18n aboot-installer parted-udeb qtparted partitioner libparted1.6-dbg parted partconf-find-partitions partconf partman mindi lvmcfg-utils nobootloader autopartkit partconf-mkfstab partman-efi pbbuttonsd (#270558), requested 289 days ago Description: PBButtons daemon to handle
Re: packages.d.o mail (Re: Greylisting for @debian.org email, please)
Le jeudi 23 juin 2005 à 19:33 +0200, Andreas Barth a écrit : * Marco d'Itri ([EMAIL PROTECTED]) [050623 19:31]: On Jun 23, Adeodato Simó [EMAIL PROTECTED] wrote: There are plans to merge @packages.d.o and @packages.QA.d.o, so that both reach the maintainer and the PTS subscribers. The QA address requires the presence of an X-PTS-Approved header to let a message reach package@p.q.d.o, but I never asked Frank what his plans about this wrt the merge were. This is evil, I just verified that packages.qa.debian.org generates backscatter. You mean, this mails should rather be checked during SMTP time? Agreed. Patches accepted. The PTS source is in CVS (cvs.debian.org:/cvs/qa/pts) and you can see the installation at master.debian.org:/org/packages.qa.debian.org/ In the mean time, the only spam that PTS users receives is the spam sent to the BTS ... so it's better than nothing. Cheers, -- Raphaël Hertzog -+- http://www.ouaza.com Formation Linux et logiciel libre : http://www.logidee.com Earn money with free software: http://www.geniustrader.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Wanted: co-maintainer(s) for dovecot
Hi Jaldhar, we are already using dovecot 1.0-stable on our production boxes. So if you need help hand I am available. Ondrej. On Wed, 2005-06-22 at 11:28 -0400, Jaldhar H. Vyas wrote: Now that sarge has released, I really want to move to the 1-0stable series of the dovecot IMAP/POP3 server in sid. However being really busy with various things I thought it might be prudent to get one or more co-maintainers to help out so it can get done quickly. (Though there are a couple of library transitions coming up which may slow things down.) I would prefer people who are already Debian developers, know something about mail protocols and will have time to keep up with the pace of dovecot development. If you are interested and qualified please let me know. -- Ondrej Sury [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Work-needing packages report for Jun 24, 2005
On Fri, Jun 24, 2005 at 12:26:30AM -0600, [EMAIL PROTECTED] wrote: The following packages have been orphaned: ACL (#314683), orphaned 6 days ago Description: extra Control (#314682), orphaned 6 days ago Description: optional Extended (#314683), orphaned 6 days ago Description: extra Library (#314682), orphaned 6 days ago Description: optional Perl (#314682), orphaned 6 days ago Description: optional System (#314682), orphaned 6 days ago Description: optional Version (#314682), orphaned 6 days ago Description: optional access (#314682), orphaned 6 days ago Description: optional and (#314683), orphaned 6 days ago Description: extra attributes (#314683), orphaned 6 days ago Description: extra dutch (#314839), orphaned 5 days ago Description: Dutch dictionary for aspell, in new (August 1996) spelling ext2 (#314683), orphaned 6 days ago Description: extra for (#314682), orphaned 6 days ago Description: optional generic (#314682), orphaned 6 days ago Description: optional gnulib (#314667), orphaned 6 days ago Description: the GNU Portability Library in (#314682), orphaned 6 days ago Description: optional kernel-patches (#314683), orphaned 6 days ago Description: extra It seems to me that bugs #314682 and #314683 are broken. Regards, Anibal Monsalve Salazar -- .''`. Debian GNU/Linux : :' : Free Operating System `. `' http://debian.org/ `- http://v7w.com/anibal signature.asc Description: Digital signature
Re: Work-needing packages report for Jun 24, 2005
Anibal Monsalve Salazar wrote: On Fri, Jun 24, 2005 at 12:26:30AM -0600, [EMAIL PROTECTED] wrote: The following packages have been orphaned: It seems to me that bugs #314682 and #314683 are broken. Ok, thanks. They are unbroken now. - Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: Bug#304220: ITP: libqt4lab -- Qt4Lab plugin library
On Mon, Apr 11, 2005 at 09:05:56PM +0200, Fathi BOUDRA wrote: I'm looking for a sponsor for my qt4lab package. The project seems already promising, and there's a collaboration with qwt project. You can find my package here : http://fboudra.free.fr/debian/ best regards, Fathi * Package name: libqt4lab Version : 0.1.1 Upstream Author : Paolo Sereno [EMAIL PROTECTED] * URL : http://www.qt4lab.org * License : LGPL Description : Qt4Lab plugin library The name kinda sucks since it'll be easily confused with the upcoming Qt4 libraries, though these use Qt3 (for now). Any chance of convincing upstream to use a less confusing name? i have sen a mail to the upstream author, and paolo answered : Talking about qt4lab and the package name Yes, I understand the issue. I have to say I have no problem changing the library name. What I would like to do is to continue using the website domain name www.qt4ab.org (is costs to me and I would like to keep this name) If you have some other library name in mind, please tell us, we could find an agreement among all the people at qt4lab. I'll send a group email to all people at qt4lab for asking opinion (not every people on qt4lab is using the mailing list for the moment, so I have to write emails) so we're looking for a new name ;) any idea ? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: packages.d.o mail (Re: Greylisting for @debian.org email, please)
On Jun 24, Raphael Hertzog [EMAIL PROTECTED] wrote: Patches accepted. The PTS source is in CVS (cvs.debian.org:/cvs/qa/pts) and you can see the installation at master.debian.org:/org/packages.qa.debian.org/ I am not the one who is polluting the rest of the network, if you can't get it right then don't do it. In the mean time, the only spam that PTS users receives is the spam sent to the BTS ... so it's better than nothing. The issue are the bounces sent to *other* people! -- ciao, Marco signature.asc Description: Digital signature
diverting conffiles
On Tue, May 31, 2005 at 11:08:27PM +0200, Tollef Fog Heen wrote: Be aware of the fact that diverting conffiles doesn't work. Hi, what exactly is the problem with diverting conffiles? Thanks, Gerrit. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#315637: ITP: libcache-fastmmap-perl -- Mmmap'ed file as a shared memory interprocess cache
Package: wnpp Severity: wishlist Owner: Krzysztof Krzyzaniak (eloy) [EMAIL PROTECTED] * Package name: libcache-fastmmap-perl Version : 1.09 Upstream Author : Rob Mueller [EMAIL PROTECTED] * URL : http://search.cpan.org/CPAN/authors/id/R/RO/ROBM/Cache-FastMmap-1.09.tar.gz * License : (Artistic/GPL) Description : Mmmap'ed file as a shared memory interprocess cache A shared memory cache through an mmap'ed file. It's core is written in C for performance. It uses fcntl locking to ensure multiple processes can safely access the cache at the same time. It uses a basic LRU algorithm to keep the most used entries in the cache. It's used for example in Catalyst::Plugin::Session::FastMmap which is part of Catalyst, The Elegant MVC Web Application Framework. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11-1-686 Locale: LANG=pl_PL, LC_CTYPE=pl_PL (charmap=ISO-8859-2) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: diverting conffiles
On Fri, Jun 24, 2005 at 11:35:17 +0200, Gerrit Pape wrote: On Tue, May 31, 2005 at 11:08:27PM +0200, Tollef Fog Heen wrote: Be aware of the fact that diverting conffiles doesn't work. Hi, what exactly is the problem with diverting conffiles? See http://bugs.debian.org/58735. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Testing package installation, upgrading, and removal
to, 2005-06-23 kello 03:28 -0400, Kevin Mark kirjoitti: A simple question. You mention that you use apt-get in this new testing environment. Would it be useful to allow an apt-get workalike(dpkg/aptitude/wajig)? Yes, that needs to be done. I haven't had trouble with it yet, so I haven't bothered to do it -- this is the kind of finishing touch that I hope to leave to later while I concentrate on getting more important things. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dummy packages and Replaces: field
Em Qui, 2005-06-23 às 12:39 -0400, Roberto C. Sanchez escreveu:
OK. That is what I am looking for. I want to completely replace the
two packages that cannot coexist with the new icewmcp package.
Currently, I must use dummy packages for that, correct?
Correct. And Conflicts: with version = ${Source-Version} of both, if
icewmcp has a greater version than both. I guess you'll need to use an
epoch if not.
See ya,
--
[EMAIL PROTECTED]: Gustavo Noronha http://people.debian.org/~kov
Debian: http://www.debian.org * http://www.debian-br.org
signature.asc
Description: This is a digitally signed message part
Re: dummy packages and Replaces: field
On Fri, 2005-06-24 at 08:39 -0300, Gustavo Noronha Silva wrote:
Em Qui, 2005-06-23 às 12:39 -0400, Roberto C. Sanchez escreveu:
OK. That is what I am looking for. I want to completely replace
the
two packages that cannot coexist with the new icewmcp package.
Currently, I must use dummy packages for that, correct?
Correct. And Conflicts: with version = ${Source-Version} of both, if
icewmcp has a greater version than both. I guess you'll need to use an
epoch if not.
Only if dummy packages come from same source as icewmcp. If he wants to
avoid epoching he could just create dummy source package... (At least I
think so :-).
O.
--
Ondrej Sury [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dummy packages and Replaces: field
On 6/23/05, Steve Langasek [EMAIL PROTECTED] wrote: Well, a new header would be nice, of course. But it would mean a change in policy, that's why I was thinking of using the existing ones. Changing the meaning of existing fields is far worse than changing policy to accomodate a new field. Ok, agreed. So, if we had a new header to indicate that this is the drop-in replacement of the old program, it could work, right? To achieve this change, we would need: * A policy change: include the new header and explain the meaning, in Section 7. * A change in dpkg's behaviour: interpret this header as a Replaces+Conflicts case, where all the files in the old package are replaced by the new package. * A change in apt/aptitude/synaptic/etc behaviour: install the program that has the new header when appropiate. It's a long way to go, I guess that it should start in dpkg, right? Which should this new header be? Substitutes:, Supersedes:, Takes-Over:, Drop-In Replaces:, Follows: ? -- Besos, Marga
Benita Hsueh/Toronto/IBM is on Vacation and Working at IBM Brazil
I will be out of the office starting 06/18/2005 and will not return until 07/01/2005. I will have limited access to email. If you need immediate assistance, please contact my DB2 Competitive Linux Technology and Enablement backup Melody Ng. For NextWave Issues or questions, please contact Paul Rodriguez -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Getting rid of circular dependencies
Dear Debian developers, Following a post to Debian-Devel-Announce, I would like to discuss getting rid of circular dependencies. Why ? - 1) The semantic of Depends specified by Debian policy 7.2. does not allow packages with circular dependencies to be installed at all: `Depends' This declares an absolute dependency. A package will not be configured unless all of the packages listed in its `Depends' field have been correctly configured. This mean that dpkg have to go out of its way to install them, and doing that break the expectation of packages expecting Depended package to be configured before them. 2) There have been lots of evidence that circular dependencies create problems during upgrade. See bugs #310490 in particular [EMAIL PROTECTED]. 3) Circular dependencies make the job of the testing scripts harder. 4) Circular dependencies make bootstrapping a new plateform harder. 5) There is an urban legend that circular dependencies between packages build from the same source are harmless. This is false of course. Being part of the same source package has no effect of the Packages.gz file whatsoever. Which ? --- Preferably all of them. Robert Lemmen was kind enough to set up a summary of current circular dependencies: http://debian.semistable.com/debgraph.out See the list for yourself. The circular dependencies involving the largest number of packages are: * libxtst6 libxtrap6 libxrandr2 libxp6 libxt6 libxmu6 libxi6 libxrender1 libxft1 libsm6 xlibs * libgnorba27 libgnomeui32 libgnomesupport0 gnome-bin gnome-libs-data libgnome32 * xemacs21-gnome-nomule xemacs21-gnome-mule-canna-wnn xemacs21-gnome-mule xemacs21-nomule xemacs21-mule-canna-wnn xemacs21-bin xemacs21-support xemacs21-mule xemacs21 * gnome-panel-data gnome-panel nautilus gnome-control-center capplets gnome-session * phpgroupware-preferences phpgroupware-admin phpgroupware-setup phpgroupware-phpgwapi phpgroupware * wesnoth-tdh wesnoth-ei wesnoth-sotbe wesnoth-trow wesnoth-httt wesnoth-data wesnoth How ? - I see two easy case: 1) foo and foo-data. There is usualy no reason for foo-data to depend on foo. foo-data does not provide user-visible interface, only data, so it does not need to depend on foo. 2) libfoo and foo-bin, where foo-bin include binaries linked with libfoo. Usually libfoo only need to Depends on configuration data in foo-bin and not on any binaries linked with libfoo (to avoid infinite recursion). In that case it should be possible to split foo-bin in foo-bin and foo-common, and change libfoo to depend on foo-common instead. Other options ? Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Debian ARM porters on debian-arm needed
Dear Debian developers, To support arm, we need people with sufficient hardware and knowledge subscribed to [EMAIL PROTECTED] Without them, we cannot adress issues like woody to sarge upgrade process on arm. Of course this is true for all architecture, but so far this month, Debian arm received only 16 non-spam messages from 9 people, and e.g I never get an answer to bug #312394 However, there are some evidence that there are a lot more developers that use Debian and ARM together. If it is your case, please subscribe to debian-arm, we need you! Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies
On Fri, 2005-06-24 at 17:21 +0200, Bill Allombert wrote: 1) foo and foo-data. There is usualy no reason for foo-data to depend on foo. foo-data does not provide user-visible interface, only data, so it does not need to depend on foo. This is usually used as way how to also uninstall foo-data when you uninstall foo. But I agree that this is just cosmetic compared to problems created by circular dependencies... Ondrej. -- Ondrej Sury [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Intel Extreme Graphics
Hello, I have a problem setting gamma for my monitor on a mobile Intel 852GM chipset using Intel Extreme Graphics on Toshiba Satellite A40 notebook.glxgears works and I even have a framebuffer when booting on my debian-source self-compiled kernel 2.6.10-6. I tried using xgamma, kgamma and editing configuration files manually too. Here's the output of dmesg: Linux version 2.6.10 ([EMAIL PROTECTED]) (gcc version 3.3.5 (Debian 1:3.3.5-13)) #1 Sun Jun 12 22:01:53 EDT 2005 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e - 000eee00 (reserved) BIOS-e820: 000eee00 - 000ef000 (ACPI NVS) BIOS-e820: 000ef000 - 0010 (reserved) BIOS-e820: 0010 - 1ef4 (usable) BIOS-e820: 1ef4 - 1ef5 (ACPI data) BIOS-e820: 1ef5 - 1f00 (reserved) BIOS-e820: fec0 - fec01000 (reserved) BIOS-e820: fec1 - fec2 (reserved) BIOS-e820: feda - fedc (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: ffb0 - ffc0 (reserved) BIOS-e820: ffe8 - 0001 (reserved) 0MB HIGHMEM available. 495MB LOWMEM available. On node 0 totalpages: 126784 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 122688 pages, LIFO batch:16 HighMem zone: 0 pages, LIFO batch:1 DMI 2.3 present. ACPI: RSDP (v000 TOSHIB) @ 0x000f0180 ACPI: RSDT (v001 TOSHIB 750 0x00970814 TASM 0x0401) @ 0x1ef4 ACPI: FADT (v002 TOSHIB 750 0x20030101 TASM 0x0401) @ 0x1ef40060 ACPI: SSDT (v001 TOSHIB A000C0x20030917 MSFT 0x010e) @ 0x1ef402ca ACPI: DBGP (v001 TOSHIB 750 0x00970814 TASM 0x0401) @ 0x1ef400e4 ACPI: BOOT (v001 TOSHIB 750 0x00970814 TASM 0x0401) @ 0x1ef40038 ACPI: MADT (v001 TOSHIB 750 0x00970814 TASM 0x0401) @ 0x1ef40118 ACPI: DSDT (v001 TOSHIB A000C0x20031216 MSFT 0x010e) @ 0x ACPI: PM-Timer IO Port: 0xd808 Built 1 zonelists Kernel command line: root=/dev/hda3 ro video=intelfb:[EMAIL PROTECTED],hwcursor=0 vga=792 Initializing CPU#0 PID hash table entries: 2048 (order: 11, 32768 bytes) Detected 2660.432 MHz processor. Using pmtmr for high-res timesource Console: colour dummy device 80x25 Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Memory: 494072k/507136k available (2274k kernel code, 12404k reserved, 910k data, 260k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay loop... 5275.64 BogoMIPS (lpj=2637824) Security Framework v1.0.0 initialized SELinux: Initializing. SELinux: Starting in permissive mode Mount-cache hash table entries: 512 (order: 0, 4096 bytes) CPU: After generic identify, caps: bfebfbff 4400 CPU: After vendor identify, caps: bfebfbff 4400 CPU: Trace cache: 12K uops, L1 D cache: 8K CPU: L2 cache: 512K CPU: After all inits, caps: bfebfbff 0080 4400 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU0: Intel P4/Xeon Extended MCE MSRs (12) available CPU: Intel Mobile Intel(R) Pentium(R) 4 CPU 2.66GHz stepping 09 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. tbxface-0118 [02] acpi_load_tables : ACPI Tables successfully acquired Parsing all Control Methods:.. Table [DSDT](id F005) - 634 Objects with 63 Devices 158 Methods 6 Regions Parsing all Control Methods:.. Table [SSDT](id F003) - 4 Objects with 0 Devices 2 Methods 0 Regions ACPI Namespace successfully loaded at root c0481d80 ACPI: setting ELCR to 0200 (from 0e00) evxfevnt-0094 [03] acpi_enable : Transition to ACPI mode successful checking if image is initramfs...it isn't (bad gzip magic numbers); looks like an initrd Freeing initrd memory: 4300k freed NET: Registered protocol family 16 EISA bus registered PCI: PCI BIOS revision 2.10 entry at 0xfd2fe, last bus=3 PCI: Using configuration type 1 mtrr: v2.0 (20020519) ACPI: Subsystem revision 20041105 evgpeblk-0979 [06] ev_create_gpe_block : GPE 00 to 1F [_GPE] 4 regs on int 0x9 evgpeblk-0987 [06] ev_create_gpe_block : Found 6 Wake, Enabled 0 Runtime GPEs in this block Completing Region/Field/Buffer/Package initialization:... Initialized 6/6 Regions 0/0 Fields 17/17 Buffers 16/24 Packages (647 nodes) Executing all Device _STA and_INI
Re: Getting rid of circular dependencies
On Fri, Jun 24, 2005 at 05:30:08PM +0200, Ondrej Sury wrote: On Fri, 2005-06-24 at 17:21 +0200, Bill Allombert wrote: 1) foo and foo-data. There is usualy no reason for foo-data to depend on foo. foo-data does not provide user-visible interface, only data, so it does not need to depend on foo. This is usually used as way how to also uninstall foo-data when you uninstall foo. But I agree that this is just cosmetic compared to problems created by circular dependencies... It is an abuse of the Depends field. foo-data doesn't *need* foo for its own operations. Nothing in -data fails to execute without foo (because there's just data, nothing to execute). If the Depends is there to make foo-data automatically uninstalled when foo is uninstalled, then trust aptitude to do its dirty deeds. Or maybe we need a new field for that purpose that only has effect on uninstalls, like Uninstall-with: foo If the purpose was to make foo installed when a user installs foo-data himself, then Recommend instead. -- Petri Latvala signature.asc Description: Digital signature
Re: Greylisting for @debian.org email, please
Il giorno dom, 19-06-2005 alle 19:19 +0200, Josselin Mouette ha scritto: Le dimanche 19 juin 2005 à 19:11 +0200, Frans Pop a écrit : If I am blocked by something like SORBS when answering installation reports or something like that, I will sometimes resend a mail through my ISP, sometimes I just say @[EMAIL PROTECTED]@ you, if you don't want to receive my mail, then don't. Gee, same reaction I suppose. I also have no regret in closing abruptly bug reports opened by such clueless people. when this happens to me, I send all email to submitter-bug#@bugs.debian.org, since Debian accept my email and will forward it in the right way. Bye, Giuseppe
Package distribution, a concept for a modern package distribution
Since around last October, I've considered to make my concept for a modern package distribution public but I wanted to wait until Debian/sarge was released which is now the case. And since the Debconf5 in Helsinki is just around the corner it's about the right time. The concept is based on an LDAP server (or simiar) as a replacement for the Packages file and on a P2P network for package distribution (see http://wyodesktop.sourceforge.net/index.php?page=pkgdist.html). IMO it would make a lot sense if this concept is discussed at the Debconf5. I'm not actively work on this concept and its implementation since I've _no_ time, sorry. If someone else is interested just say so. O. Wyss -- Development of frame buffer drivers: http://linux-fbdev.sf.net Sample code snippets for wxWidgets: http://wxcode.sf.net How to build well-designed applications: http://wyoguide.sf.net Desktop with a consistent look and feel: http://wyodesktop.sf.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies
[Petri Latvala] It is an abuse of the Depends field. foo-data doesn't *need* foo for its own operations. Nothing in -data fails to execute without foo (because there's just data, nothing to execute). Depends does not just mean executables will crash or fail to load. It actually means it is pointless to install this package without this other package. Having a package removed automatically because it no longer has any reason to be installed is a perfectly legitimate use for Depends. That does not solve the circular dependency problem, granted. Perhaps there is need of a package flag that says it is pointless to have this package installed by itself, so remove it if nothing depends on it. aptitude currently deduces this from its auto-install state flag, but perhaps a package itself ought to be allowed to express it. Or maybe we need a new field for that purpose that only has effect on uninstalls, like Uninstall-with: foo That's an alternative. Or a field (call it Post-Depends) which means the same as Depends except that dpkg is told not to worry about the install/remove ordering - in other words, it's given a hint about where it can safely break the ordering loop. (Currently it has to guess.) signature.asc Description: Digital signature
Forget- Fear Factor
Improve yourself and ELIMINATE FEARS: http://www.ucanimprove.info/index2.htm Our exclusive eBook teaches to ELIMINATE: Phobias / Fear Release Anxiety / Stress Release Depression Release/Anger Release Entrepreneurial ActivitySales Shame Release Embarrassment Release Guilt Release Addictive Urges Fear of Change Senior Management Fear Fear in the Workplace Dealing With Harassment This exclusive book is guaranteed to make you a better person or your money back. Ready to learn more? Then visit http://www.ucanimprove.info/index2.htm A f L d E a w E h N c H s A a N k C q E p M d E c N a T s93377718821 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies
On 6/24/05, Peter Samuelson [EMAIL PROTECTED] wrote: [Petri Latvala] It is an abuse of the Depends field. foo-data doesn't *need* foo for its own operations. Nothing in -data fails to execute without foo (because there's just data, nothing to execute). Depends does not just mean executables will crash or fail to load. It actually means it is pointless to install this package without this other package. Having a package removed automatically because it no I'd classify that as abuse. A data package doesn't require another package to do it's duties (since it has no duties of it's own) so there shouldn't be a depends. longer has any reason to be installed is a perfectly legitimate use for Depends. That does not solve the circular dependency problem, granted. Perhaps there is need of a package flag that says it is pointless to have this package installed by itself, so remove it if nothing depends on it. aptitude currently deduces this from its auto-install state flag, but perhaps a package itself ought to be allowed to express it. Or maybe we need a new field for that purpose that only has effect on uninstalls, like Uninstall-with: foo That's an alternative. What if you introduce a new package (bar) that also depends on foo-data? Then you're forced to also install foo, although you don't need it at all?
Get Bigger Pennis MTRyT
The Only Clinically Tested Penis En_Largement Products! - Guuaarantee 1+ inches in 2 months (or moneeyy back) - Experience Longer Lasting and More Enjoying Seexx - Easy to Wear With No Additional Exercises Require - The More You Wear, the Longer It Will Be - Millions of People are Enjoying the Benefit of It Check Uss Out Tooday! http://genuinely.net/extender/?ronn o-ut of mai-lling lisst: http://genuinely.net/rm.php?ronn 0ctLpb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dummy packages and Replaces: field
On Fri, Jun 24, 2005 at 09:52:34AM -0300, Margarita Manterola wrote: So, if we had a new header to indicate that this is the drop-in replacement of the old program, it could work, right? [...] Which should this new header be? Substitutes:, Supersedes:, Takes-Over:, Drop-In Replaces:, Follows: ? Since there should be a unique replacement that old and new package maintainer(s) agree on, I think the old package (the one being replaced) should have the header. (Perhaps Replaced-By: ?) -- Eric Cooper e c c @ c m u . e d u -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies
On Fri, 24 Jun 2005, Peter Samuelson wrote: Depends does not just mean executables will crash or fail to load. It actually means it is pointless to install this package without this other package. I think we should not use such meaning for the Depends field. Otherwise we could end up having control files like this: Package: libfoo Depends: complete-or'ed-list-of-all-packages-which-depend-on-libfoo [...] Perhaps there is need of a package flag that says it is pointless to have this package installed by itself, so remove it if nothing depends on it. We already have something for that. It's called Section: libs and deborphan, and it works great. Perhaps we should just move to section libs any package which is useless by itself, and it's only useful in combination with others, much like libraries, but without requiring them to be real libraries. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dummy packages and Replaces: field
** Eric Cooper :: On Fri, Jun 24, 2005 at 09:52:34AM -0300, Margarita Manterola wrote: So, if we had a new header to indicate that this is the drop-in replacement of the old program, it could work, right? [...] Which should this new header be? Substitutes:, Supersedes:, Takes-Over:, Drop-In Replaces:, Follows: ? Since there should be a unique replacement that old and new package maintainer(s) agree on, I think the old package (the one being replaced) should have the header. (Perhaps Replaced-By: ?) I disagree. This is not economic in terms of # of uploads... forces you to give a new (last) upload for the old package, which would be even larger than the dummy package upload. -- HTH Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies
On Fri, Jun 24, 2005 at 07:39:16PM +0200, Santiago Vila wrote: We already have something for that. It's called Section: libs and deborphan, and it works great. Perhaps we should just move to section libs any package which is useless by itself, and it's only useful in combination with others, much like libraries, but without requiring them to be real libraries. That would then be an abuse of the section field. A data package is not a lib. How about a field (or a debtag) useless-alone, which deborphan and aptitude and whatnot can garbage-collect when nothing depends on such a package? That would solve the problem with Uninstall-with: foo when another package suddenly needs the data package. -- Petri Latvala signature.asc Description: Digital signature
Re: Getting rid of circular dependencies
On Fri, Jun 24, 2005 at 11:36:16AM -0500, Peter Samuelson wrote: [Petri Latvala] It is an abuse of the Depends field. foo-data doesn't *need* foo for its own operations. Nothing in -data fails to execute without foo (because there's just data, nothing to execute). Depends does not just mean executables will crash or fail to load. It actually means it is pointless to install this package without this other package. Having a package removed automatically because it no longer has any reason to be installed is a perfectly legitimate use for Depends. No it is not. Read Debian Policy 7.2: `Depends' This declares an absolute dependency. A package will not be configured unless all of the packages listed in its `Depends' field have been correctly configured. The `Depends' field should be used if the depended-on package is required for the depending package to provide a significant amount of functionality. The `Depends' field should also be used if the `postinst', `prerm' or `postrm' scripts require the package to be present in order to run. Note, however, that the `postrm' cannot rely on any non-essential packages to be present during the `purge' phase. If you want to remove useless package, use aptitude debfoster or deborphan. dpkg will _never_ do it for you. apt-get will try to do it but at the expense of considerable breakage risk. Bug #310490 show an example where the risk is to remove every KDE packages. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies
[Bill Allombert] The `Depends' field should be used if the depended-on package is required for the depending package to provide a significant amount of functionality. I'd say if a -data package is useless without its corresponding binary package, that fits this definition just fine. Policy does not specify *why* a package might fail to provide significant functionality without the presence of something else. (Unless you wish to argue that -data packages provide no functionality, which seems a pretty arbitrary definition of 'functionality'.) However, that's rather beside the point. I'd be happy to concede that Depends should have a narrower definition, if a 'Useless-Alone' or 'Keep-Orphan' field/tag could be introduced to cover the -data case. Hmmm, what's the story with fields versus tags for boolean properties? Essential is a field, but people are now talking about tags for this sort of thing instead. If you want to remove useless package, use aptitude debfoster or deborphan. dpkg will _never_ do it for you. apt-get will try to do it but at the expense of considerable breakage risk. Bug #310490 show an example where the risk is to remove every KDE packages. I read that wrong at first and thought that KDE was what you meant by useless packages. (: signature.asc Description: Digital signature
Re: dummy packages and Replaces: field
[Eric Cooper] Since there should be a unique replacement that old and new package maintainer(s) agree on, I think the old package (the one being replaced) should have the header. (Perhaps Replaced-By: ?) The whole point of the exercise was to get rid of dummy packages. Your proposal requires one. Which is not to say there is no merit in a package tag or field that says this exists only to suck in dependencies, so when it has served this purpose, delete it at leisure. aptitude would presumably transfer the auto-install flag state from the dummy package to anything it depends on, then set the dummy package itself to the auto-installed state, for garbage collection. signature.asc Description: Digital signature
Re: Getting rid of circular dependencies
On Fri, Jun 24, 2005 at 07:39:16PM +0200, Santiago Vila wrote: Perhaps we should just move to section libs any package which is useless by itself, and it's only useful in combination with others, much like libraries, but without requiring them to be real libraries. Good idea. Or we could have a new section for architecture independant data. Moving everything which is not mean to be directly installed by users in it, so the section games only contains actual games and not the data files. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dummy packages and Replaces: field
On Fri, Jun 24, 2005 at 02:13:43PM -0500, Peter Samuelson wrote: [Eric Cooper] Since there should be a unique replacement that old and new package maintainer(s) agree on, I think the old package (the one being replaced) should have the header. (Perhaps Replaced-By: ?) The whole point of the exercise was to get rid of dummy packages. Your proposal requires one. Unless there was a way to include these entries in the Packages file (or some other control file) other than dummy packages.. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies
On 6/24/05, Peter Samuelson [EMAIL PROTECTED] wrote: [Bill Allombert] The `Depends' field should be used if the depended-on package is required for the depending package to provide a significant amount of functionality. I'd say if a -data package is useless without its corresponding binary package, that fits this definition just fine. Policy does not specify *why* a package might fail to provide significant functionality without the presence of something else. (Unless you wish to argue that -data packages provide no functionality, which seems a pretty arbitrary definition of 'functionality'.) I'd argue for exactly that. What functionality would you say a data package provides? It's the other package that provides the functionality, not the data package. The data package shouldn't even have to know about the other package.
Re: Getting rid of circular dependencies
On Fri, 2005-06-24 at 22:59 +0200, Olaf van der Spek wrote: I'd argue for exactly that. What functionality would you say a data package provides? It's the other package that provides the functionality, not the data package. The data package shouldn't even have to know about the other package. If you want to play word games and not apply common sense, then I would say that foo-data package has functionality to provide data to foo and so it's broken without foo package. You must realize that 90% of these packages are games and only reason for foo + foo-data is to not split out arch independent data out of foo package so it doesn't get replicated for each arch. One thing is very clear: 1. this is (a sort of) abuse of Depends field 2. we need reverse Suggest/Recommends field, ie. something like Recommends-Uninstall: foo-data (well, same can be applied to -doc, -common, etc.) Truth is that deborphan is very nice tool to do this... Ondrej. -- Ondrej Sury [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies
On 6/24/05, Ondrej Sury [EMAIL PROTECTED] wrote: On Fri, 2005-06-24 at 22:59 +0200, Olaf van der Spek wrote: I'd argue for exactly that. What functionality would you say a data package provides? It's the other package that provides the functionality, not the data package. The data package shouldn't even have to know about the other package. If you want to play word games and not apply common sense, then I would It's not a word game at all. say that foo-data package has functionality to provide data to foo and But that 'functionality' doesn't break without foo. Like I said before, what would you do if there also was a foo2 or bar (independent of foo) that'd use foo-data? Whatever you tried to achieve with the reverse dependency would not work in that case.
Re: Getting rid of circular dependencies
On 6/24/05, Ondrej Sury [EMAIL PROTECTED] wrote: so it's broken without foo package. You must realize that 90% of these packages are games and only reason for foo + foo-data is to not split out arch independent data out of foo package so it doesn't get replicated for each arch. Hmm, another way to nicely solve that would be to improve the smartness of the archive software such that it deals with this 'replication' under the hood.
Re: Getting rid of circular dependencies
Bill Allombert wrote:
1) foo and foo-data. There is usualy no reason for foo-data to depend on
foo. foo-data does not provide user-visible interface, only data, so it
does not need to depend on foo.
Fully agree. Looking at one of the circular dependencies listed on
http://debian.semistable.com/debgraph.out I chose amphetamine{,-data} as
an example.
The list of files for amphetamine-data shows everything is in /usr/share
except /etc/amphetamine/{amph,user}.conf. I do not know enough about the
game to know if the configuration file is more closely related to the
binary, or to the dataa itself. I would venture to guess that the conf
files are more closely related to the game's binary.
I can see where the game would be installed on the client system, and
the data would live on the file server under /usr/share. Currently, the
only way to do this is by having installed broken packages, and to copy
the /etc/amphetamine files from the filer onto the client.
vim and vim-common seem to suffer the same, except vim-common has
nothing outside the /usr/share directory. In my case, though, I would
likely have installed vim onto the filer, also.
--
John H. Robinson, IV [EMAIL PROTECTED]
http
WARNING: I cannot be held responsible for the above, sbih.org ( )(:[
as apparently my cats have learned how to type. spiders.html
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies
[Olaf van der Spek] Hmm, another way to nicely solve that would be to improve the smartness of the archive software such that it deals with this 'replication' under the hood. Sounds like you want some sort of transparent jigdo on each mirror. That, or explicit support everywhere for multi-file debian packages, similar in spirit to .dsc source packages. Neither sounds like much fun. signature.asc Description: Digital signature
Re: Getting rid of circular dependencies
On 6/25/05, John H. Robinson, IV [EMAIL PROTECTED] wrote: I can see where the game would be installed on the client system, and the data would live on the file server under /usr/share. Currently, the only way to do this is by having installed broken packages, and to copy the /etc/amphetamine files from the filer onto the client. Why would you only install the data and not the binaries on the file server (filer?)? vim and vim-common seem to suffer the same, except vim-common has nothing outside the /usr/share directory. In my case, though, I would likely have installed vim onto the filer, also.
Re: Getting rid of circular dependencies
On 6/25/05, Peter Samuelson [EMAIL PROTECTED] wrote: [Olaf van der Spek] Hmm, another way to nicely solve that would be to improve the smartness of the archive software such that it deals with this 'replication' under the hood. Sounds like you want some sort of transparent jigdo on each mirror. That, or explicit support everywhere for multi-file debian packages, similar in spirit to .dsc source packages. Neither sounds like much fun. What's no fun about the transparent jigdo-like approach?
Re: Getting rid of circular dependencies
[Olaf van der Spek] What's no fun about the transparent jigdo-like approach? Explaining to each one of the countless mirror admins just how to load a custom CGI program, apache module, apache2 module, and/or FTP daemon. And explaining why they have to. signature.asc Description: Digital signature
Preferred way to genereate a gpg key?
While I was reading Developer's Reference [1], in the part about gpg keys, it says: You need a type 4 key for use in Debian Development. Your key length [...] I supposed that it refers about the gpg --gen-key command, and the options that result from executing it. Also I remember that, *in the past*, it was a 4 option which was something about ElGamal sign and encryption, or something like that. But now, in the Sarge's version of gpg, there is only option 1,2, and 5. So, I ask: now what is the preferred way to generete a gpg key to become a debian developer? The 4 expression, and my interpretation, in that paragraph is it correct? Just want to know. And if it is a bug, I hope somebody could change it to avoid confusion. Thanks. Erick. [1] http://www.debian.org/doc/packaging-manuals/developers-reference/ch-new-maintainer.en.html -- Libertad es aún la idea más radical de todas. ---Nathaniel Branden
Re: Preferred way to genereate a gpg key?
On Fri, 2005-06-24 at 18:39 -0500, Erick Vresnev Castellanos Hernández
wrote:
While I was reading Developer's Reference [1], in the part about gpg
keys, it says:
You need a type 4 key for use in Debian Development. Your key length [...]
I supposed that it refers about the gpg --gen-key command, and the
options that result from executing it. Also I remember that, *in the
past*, it was a 4 option which was something about ElGamal sign and
encryption, or something like that. But now, in the Sarge's version of
gpg, there is only option 1,2, and 5.
You probably want option 1, the default. The type 4 refers to key
version. The only version of key that GnuPG is capable of generating is
version 4, so there should be no problems. The old versions (versions 2
and 3, which are otherwise identical) are generated by PGP 2.3.x and
2.6.x, respectively.
The Elgamal sign and encrypt has been removed from the proposed new
standard, because it is very hard to make secure, and GnuPG made a
mistake in doing so.
So, I ask: now what is the preferred way to generete a gpg key to
become a debian developer? The 4 expression, and my interpretation,
in that paragraph is it correct?
Again, you probably want option 1. Your interpretation is probably very
common, just not correct.
Just want to know. And if it is a bug, I hope somebody could change it
to avoid confusion.
You are correct; it probably should be fixed.
Furthermore, my suggestion is that if you own a PC or other fast
i386-type machine, that you should use that, as opposed to a PowerPC or
Sparc, because i386s gain entropy faster in my experience, and you need
a lot of entropy. Just a suggestion; it is not required.
--
($_,$a)=split/\t/,join'',map{unpack'u',$_}DATA;eval$a;print;__DATA__
M961H[EMAIL PROTECTED];!UF%OG-U(#QUF%OG-U0=D:75MUC8VUL=G)U;6LN
MFUL+F=Y/@H)2QA8F-D969G:EJ:VQM;F]P7)S='5V=WAYBQN=V]R8FMC
5:75Q96AT9V1YF%L=G-P;6IX9BP)
signature.asc
Description: This is a digitally signed message part
Re: Mozilla Foundation Trademarks
Gervase Markham wrote: Then I'm slightly confused as to your concept of trademark infringement. If I label the car I've built as a Ford (even if it uses a lot of Ford parts), it infringes Ford's trademark. OTOH, as has been pointed out before in one of the many related threads, if I take a Ford, built by Ford Motor Company, replace the fuel pump, I can still sell it as a Ford. I'm not a trademark lawyer, haven't read much on trademark, etc. so I don't feel competant at all trying to figure where that line is drawn in software. However, I'd be surprised if putting Mozilla Firefox Modified by Debian (see /usr/share/doc/mozilla-firefox/changelog.Debian.gz) in the About box and similar things in the package description wouldn't be allowed. OTOH, I don't see any issue whatsoever with Debian taking the Mozilla Foundation's trademark license offer, so long as it only gives Debian additional rights. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies
1) foo and foo-data. There is usualy no reason for foo-data to depend on foo. foo-data does not provide user-visible interface, only data, so it does not need to depend on foo. However, we have some users randomly filing bugs on foo-data that doesn't get uninstalled if it's no longer useful. We need 1. policy documenting the current decision that foo-data doesn't depend on foo 2. helper information to allow tools like deborphan to work correctly. 2) libfoo and foo-bin, where foo-bin include binaries linked with libfoo. Usually libfoo only need to Depends on configuration data in foo-bin and not on any binaries linked with libfoo (to avoid infinite recursion). In that case it should be possible to split foo-bin in foo-bin and foo-common, and change libfoo to depend on foo-common instead. I'm rather doubtful it should be easy to fix this situation. I doubt having configuration data in foo-bin is a good idea, since it will generally cause problems when libfoo1/libfoo2 needs to coexist. regards, junichi -- Junichi Uekawa, Debian Developer http://www.netfort.gr.jp/~dancer/ 183A 70FC 4732 1B87 57A5 CE82 D837 7D4E E81E 55C1 pgpHnflZrU25P.pgp Description: PGP signature
