Re: Help needed with debconf
Arne Götje [EMAIL PROTECTED] wrote: I need some help with debconf, especially for the config and postinst scripts. I tried to craft my own ones for my font package and when I try to install the package the postinst script exits with status 10. What does this mean? Further more, the dialog I have created in config gets never displayed to the user... :( I have attached the config, templates and postinst files. Can someone help me to review them and find the mistakes? Hello, I probably have notfound the real cause, but perhaps this helps anyway. - db_input medium ttf-arphic-uming/variant db_go - If debconf decides to not ask this question (either because the user has set his debconf priority to high or because the question has been shown previously) db_input will give a non-zero exit code and your script will end prematurly because of set -e, you'll usually want db_input ... || true for that reason. postinst: - #DEBHELPER# if [ $1 = configure ]; then - I should not make any difference, but I'd strongly suggest to move #DEBHELPER# to end of the file. postinst: #!/bin/sh [...] if [ $variant == Unicode ]; then That is a bashism which will fail if /bin/sh is dash. Use [ foo = bar ] instead. To debug this further you'd need to actually run the script and install the package, playing with DEBCONF_DEBUG=developer and possibly using set -x in the scripts temporarily. cu andreas -- See, I told you they'd listen to Reason, [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in Snow Crash
Re: LCC and blobs
hoi :) On Sat, Dec 11, 2004 at 01:45:01PM -0800, Thomas Bushnell BSG wrote: And why it should be different if that firmware is distributed by the manufacturer on a CD instead of a flash EPROM chip? Because in that case the manufacturer is hurting the user by not providing source, and we are against that. What would you gain by having the firmware source. Please don't tell me that you want to fix bugs there. The firmware is part of the hardware and we don't ask the vendors to give away their .vhdl files of the hardware. Both firmware and hardware source are useless as they usually need highly proprietary tools to build. We should however try to convince hardware vendors to allow distribution of their firmware. Asking for full source is not helping anybody and will just scare away the vendors. -- Martin Waitz signature.asc Description: Digital signature
Re: Help needed with debconf
On Wed, Dec 15, 2004 at 01:34:40PM +0800, Arne Götje (?) wrote: Further more, the dialog I have created in config gets never displayed to the user... :( I have attached the config, templates and postinst files. You didn't attached your rules file and I suppose that there is a problem, which cause not displaying your question. Are you sure you've got dh_installdebconf in your binary-common target in rules file? Otherwise your debconf stuff won't be included automatically in your final package. regards fEnIo -- _ Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | IRC:fEnIo _|_|_ 32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Polska (0 0) phone:+48602383548 | Slackware - the weakest link ooO--(_)--Ooo http://skawina.eu.org | JID:[EMAIL PROTECTED] | RLU:172001 signature.asc Description: Digital signature
Re: LCC and blobs
What would you gain by having the firmware source. Please don't tell me that you want to fix bugs there. The firmware is part of the hardware and we don't ask the vendors to give away their .vhdl files of the hardware. Both firmware and hardware source are useless as they usually need highly proprietary tools to build. Firmware generally is software and it is built exactly the same way any other software is built. Firmware is mostly written in C or assembler which doesn't require any highly proprietary tools. Some firmware is a 'configuration file' for an FPGA. I'm not sure if this is software or not. It's not executed the same way machine code is. Cheers, Peter (p2). signature.asc Description: Digital signature
[no subject]
Börje Löf AO-chef Markbyggarna Serviceförv, Gävle kommun Postadress: 801 84 Gävle Besöksadress: Kanalvägen 6 Telefon: 026 - 17 84 10 Mobil:0704-140 110 Telefax: 026 - 17 84 00 E-post: mailto:[EMAIL PROTECTED] Ring Markbyggarna när det ska fungera ! Välkommen till www.gavle.se
dpkg-checkbuilddeps ready for first impressions and future development
Packages: dpkg-cross Version: 1.20.4 (CVS) Severity: wishlist Hi Nikita, here is my proposal for dpkg-checkbuilddeps implementation. Some words on the implementation. Package names are converted depending on their Section they belongs to. Sections libs and libsdevel are converted by default. Also packages which Section can not be determined are -arch-cross converted. All other packages are kept als they are. You can override this behaviour by extend the crossdeps configuration variable in cross-compile configuration file. All packages listed in crossdeps are converted too independing on their section. Due to the early stage of implementation and missing feedback dpkg-checkbuilddeps is disabled by default. Everybody who intent to contribute or test the implementation have to set checkbuilddeps=1 within cross-compile configuration file. The patch does not disturb the current implementaion! This patch contain some changes on ARCH and introduces DPKGCROSSARCH as new environment variable. This is required because dpkg-checkbuilddeps is not called wihtin a Makefile so MAKEFLAGS are not active. I've also decieded to use DPKGCROSSARCH in the future to determine if the dpkg-cross environment is running instead of ARCH which is unset-eable (and should be!). ARCH is too simple and worldwide used name ;) -- Raphael Bossek pgps1z38fQtKe.pgp Description: PGP signature
Re: dpkg-checkbuilddeps ready for first impressions and future development
You forgot patch itself :) Every time I say, do not forget to attach the file, the file do not forget to do it but... }8| -- Raphael Bossek diff --exclude=CVS -Nru dpkg-cross.cvs/ChangeLog dpkg-cross-1.20.4.checkbuilddeps.1/ChangeLog --- dpkg-cross.cvs/ChangeLog2004-12-03 22:42:55.0 +0100 +++ dpkg-cross-1.20.4.checkbuilddeps.1/ChangeLog2004-12-15 10:59:00.0 +0100 @@ -1,3 +1,22 @@ +2004-12-14 Raphael Bossek [EMAIL PROTECTED] + + * dpkg-cross, dpkg-cross.pl: moved rewrite_dependencies(), + rewrite_alternatives() and rewrite_item() to dpkg-cross.pl for reusage in + dpkg-checkbuilddeps. rewrite_item() rename only packages that are in + section libdevel or libs or are listed in crossdeps configuration + variable. Set DPKGCROSSARCH environment variable so dpkg-checkbuilddeps + know to run in dpkg-cross environment. Fixed issue where @keepdeps and + @removedeps are are not set as arrays. Introduced the checkbuilddeps + configuration variable which should be set to 1 if dpkg-checkbuilddeps + support is designated. ARCH is set but not used to determine if we are + wihtin a dpkg-cross envrionment. DPKGCROSSARCH was introduced to avoid + interferences with the unset feature and packages which uses ARCH for + its own purposes. + * dpkg-checkbuilddeps: support for Build-* information in debian/control + in sence of dpkg-cross and cross-build environments added. + * cross-compile.example: added crossdeps and checkbuilddeps + documentation. + 2004-12-03 Nikita V. Youshchenko [EMAIL PROTECTED] * dpkg-cross.pl: implemented 'unset' feature for configuration file. diff --exclude=CVS -Nru dpkg-cross.cvs/cross-compile.example dpkg-cross-1.20.4.checkbuilddeps.1/cross-compile.example --- dpkg-cross.cvs/cross-compile.example2004-12-03 22:42:55.0 +0100 +++ dpkg-cross-1.20.4.checkbuilddeps.1/cross-compile.example2004-12-15 10:43:10.0 +0100 @@ -31,6 +31,13 @@ # keepdeps : comma-separated list of package names thet should be kept # in depends/conflicts/etc fields as is, without adding # -arch-cross. +# crossdeps : comma-seperated list of package names that have to be +# extended with -arch-cross. This is required because only +# packages which belongs to sections libdevel and libs are +# renamed by default. +# checkbuilddeps : By default the Build-* dependencies are not validated +# by the dpkg-cross tool chain. You have to set checkbuilddeps +# to 1 if you intent to check Build-* dependencies. # # Usually, you need only set crossbase, or maybe also crossdir # diff --exclude=CVS -Nru dpkg-cross.cvs/debian/changelog dpkg-cross-1.20.4.checkbuilddeps.1/debian/changelog --- dpkg-cross.cvs/debian/changelog 2004-12-03 22:42:55.0 +0100 +++ dpkg-cross-1.20.4.checkbuilddeps.1/debian/changelog 2004-12-15 11:08:05.0 +0100 @@ -1,3 +1,9 @@ +dpkg-cross (1.20.4.checkbuilddeps.1) unstable; urgency=low + + * Added support for dpkg-checkbuilddeps. + + -- Raphael Bossek [EMAIL PROTECTED] Sun, 12 Dec 2004 17:32:26 +0100 + dpkg-cross (1.20.4) unstable; urgency=low * Implemented 'unset' feature for configuration file (Closes: #246061). diff --exclude=CVS -Nru dpkg-cross.cvs/debian/control dpkg-cross-1.20.4.checkbuilddeps.1/debian/control --- dpkg-cross.cvs/debian/control 2004-10-29 23:13:19.0 +0200 +++ dpkg-cross-1.20.4.checkbuilddeps.1/debian/control 2004-12-14 10:23:35.0 +0100 @@ -7,7 +7,7 @@ Package: dpkg-cross Architecture: all -Depends: dpkg-dev (= 1.9.21), binutils, file +Depends: dpkg-dev (= 1.9.21), binutils, file, libapt-pkg-perl Suggests: binutils-multiarch, fakeroot Conflicts: pkg-config ( 0.15.0) Description: Tools for cross compiling Debian packages diff --exclude=CVS -Nru dpkg-cross.cvs/debian/postrm dpkg-cross-1.20.4.checkbuilddeps.1/debian/postrm --- dpkg-cross.cvs/debian/postrm2004-08-25 03:11:14.0 +0200 +++ dpkg-cross-1.20.4.checkbuilddeps.1/debian/postrm2004-12-14 10:43:07.0 +0100 @@ -27,6 +27,10 @@ dpkg-divert --package dpkg-cross --remove --rename \ --divert /usr/bin/dpkg-shlibdeps.orig \ /usr/bin/dpkg-shlibdeps + +dpkg-divert --package dpkg-cross --remove --rename \ +--divert /usr/bin/dpkg-checkbuilddeps.orig \ +/usr/bin/dpkg-checkbuilddeps ;; purge|remove|upgrade|failed-upgrade|abort-install|abort-upgrade|disappear) diff --exclude=CVS -Nru dpkg-cross.cvs/debian/preinst dpkg-cross-1.20.4.checkbuilddeps.1/debian/preinst --- dpkg-cross.cvs/debian/preinst 2004-08-25 03:11:14.0 +0200 +++ dpkg-cross-1.20.4.checkbuilddeps.1/debian/preinst 2004-12-12 17:35:12.0 +0100 @@ -22,6 +22,9 @@ dpkg-divert --package dpkg-cross --add --rename \ --divert
Re: dselect survey
On Wed, Dec 15, 2004 at 10:20:09AM +0900, Miles Bader wrote: The other problem with aptitude is touted as a design feature: it tends to be all-or-nothing. Either you use it always or you don't (automatic removal thingie). This becomes a problem when multiple persons use different interfaces for adding and removing packages to the system. You exaggerate. I do not. I've seen aptitude remove unwanted packages more than a couple of times because of this. It's a cool feature, yes. It's also a design bug. Marcelo
Re: Linux Core Consortium
On Tue, Dec 14, 2004 at 06:16:03AM -0800, Steve Langasek wrote: That wasn't my question. My question was, why should any ISV care if their product has been LSB-*certified*? ISVs can test against, and advertise support for, whatever they want to without getting the LSB's imprimatur. I cannot fathom why any ISV would go through the expense (money or time) of getting some sort of LSB certification instead of simply making this part of their in-house product QA; and therefore I don't see how the absence of LSB-certified applications can be regarded as a failure of the LSB process. I don't think we are talking about ISVs paying to get LSB certification but about ISVs certifying their own applications for a certain LSB level, aren't we? Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
Re: Linux Core Consortium
On Fri, Dec 10, 2004 at 04:04:22PM +0100, Bill Allombert wrote: It seems to me than one of the main value of Debian is in the quality of its core distribution. One of the reason of the quality is that it is not developed for itself but as a platform for the 10^4+ packages and the 10+ architectures in Debian. For example the compiler must be ... Given that, an attempt to develop the core distribution as a separate entity is going to be impractical and to reduce its quality. Why? In fact you are proving your own argument wrong. If a seperate core distribution is developed as a core of more, let alone all, Linux distributions including Debian, the amount of packages using it as platform will certainly increase. On the other hand, nothing bars the LCC to build a distribution on top of Debian. There is a lot of precedent for doing so (Xandros,libranet, lycoris, linspire, mepis, etc.). This is one argument why I'd say, we surely should work with LCC. As a practical matter, what if the Debian gcc team decide to release etch with gcc 3.3 because 3.4 break ABI on some platforms and gcc-4.x is not stable enough on all the platforms ? Will LCC follow ? If not, how are we going to share binary package if we do not use the same compiler? Another reason why we should work together as the problem will arise with the other dists anyway. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
Re: Linux Core Consortium
On Sat, Dec 11, 2004 at 12:22:13PM +0100, Florian Weimer wrote: I don't think Debian should try to adopt an extensive, externally specified ABI. For a few core packges, this may make some sense, but not for most libraries. Lcc is also about those few core packages. Instead, proprietary software vendors should ship all libraries in the versions they need, or link their software statically. I wouldn't From a technical standpoint this may make sense, but not from the commercial standpoint ISVs have to take. Building your own environment to work on all distros is certainly much more work than just certifying for the one distribution you use in your development labs anyway. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
Re: Linux Core Consortium
On Fri, Dec 10, 2004 at 12:44:05AM +0100, Christoph Hellwig wrote: In fact I'm using Debian exactly because it doesn't try to apeal ISVs, IHVs, OEMs and other business-driven three-letter acronyms. As soon as you ty to please them quality of implementation goes down. Why? It took me some time to read all those mails, in particular because some new threads were created in reply to this one creating a giant thread in my mutt view. :-) Anyway, I did not find any mention of Ian asking Debian to lose anything. His question was if we are interested in participating. So this certainly does not lower our quality of implementation. Also there was talk about ADDITONAL packages replacing those base packages that need to be changed. No one is forced to use them the way I understand things. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
Re: dselect survey
Op wo, 15-12-2004 te 05:57 -0600, schreef Marcelo E. Magallon: On Wed, Dec 15, 2004 at 10:20:09AM +0900, Miles Bader wrote: The other problem with aptitude is touted as a design feature: it tends to be all-or-nothing. Either you use it always or you don't (automatic removal thingie). This becomes a problem when multiple persons use different interfaces for adding and removing packages to the system. You exaggerate. I do not. I've seen aptitude remove unwanted packages more than a couple of times because of this. It's a cool feature, yes. It's also a design bug. ACK. I very much prefer the way debfoster handles this: if there are new, unknown packages on the system, it will ask, rather than assume, whether a package is wanted or not. And will only do this for packages that are not depended upon; so if you ever remove a package, it will ask about its dependencies again. This is far better than a program which tries to figure it all out itself. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune
Re: If you really want Free firmware...
On Tue, Dec 14, 2004 at 10:01:59AM -0500, Chasecreek Systemhouse wrote: It would be nice if you included your name in your posts. On 14 Dec 2004 09:03:20 -0500, Michael Poole [EMAIL PROTECTED] wrote: Hardware design has very different and higher third-party costs than software design, and the cost to make and test minor revisions can be a significant fraction of the cost to do the initial build. As long as that is true, free hardware is not possible on the same scale as free software or with many of its benefits. Those costs exist mainly, IMHO, because the general public doesn't have wide spread manufacturing like Linux developers do with regard to software development. Personally I'm not buying it. Hardware costs what it does for the same reasons as software -- to advance the state of the art and to create better hardware (or software as the case may be.) What are you talking about? ASICs (custom ICs) are costly to design and manufacture because it's labour-intensive and requires expensive tools and expensive machines. Those machines themselves were labour-intensive to design and build and use expensive parts. etc. If you know a way to create transistors that are only 90 nanometers wide, or even 250nm, in your room at home, please share. (That's 90 billionths of a metre.) I don't think this is just a case of not thinking out of the box. That's the manufacturing. The design is a process of coding and testing, which you could do yourself for free. (Of course there's no suitable free tools yet either.) Unlike software, you have to get it right quickly because the next revision of prototypes incurs all the same costs again. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: If you really want Free firmware...
On Wed, 15 Dec 2004 23:32:39 +1100, Hamish Moffatt [EMAIL PROTECTED] wrote: On Tue, Dec 14, 2004 at 10:01:59AM -0500, Chasecreek Systemhouse wrote: It would be nice if you included your name in your posts. Lordy. :-) It *is* in my posts. See below here ... -- WC -Sx- Jones http://insecurity.org/
transition of htop
Hello. Could someone take a look at htop transition? http://qa.debian.org/developer.php?excuse=htop http://bjorn.haxx.se/debian/testing.pl?package=htop Both pages say that my package hasn't been built on m68k yet, but that's not truth. It has been built on 30th of November: http://buildd.debian.org/fetch.php?pkg=htopver=0.5-1arch=m68kstamp=1101802311file=logas=raw So why didn't he enter sarge yet? regards fEnIo -- _ Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | IRC:fEnIo _|_|_ 32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Polska (0 0) phone:+48602383548 | Slackware - the weakest link ooO--(_)--Ooo http://skawina.eu.org | JID:[EMAIL PROTECTED] | RLU:172001 signature.asc Description: Digital signature
Re: transition of htop
Bartosz Fenski aka fEnIo [EMAIL PROTECTED] wrote: Could someone take a look at htop transition? http://qa.debian.org/developer.php?excuse=htop http://bjorn.haxx.se/debian/testing.pl?package=htop Both pages say that my package hasn't been built on m68k yet, but that's not truth. It has been built on 30th of November: http://buildd.debian.org/fetch.php?pkg=htopver=0.5-1arch=m68kstamp=1101802311file=logas=raw So why didn't he enter sarge yet? Because the m68k package was not uploaded, you can see that on http://packages.debian.org/htop You might want to contact [EMAIL PROTECTED] cu andreas
Re: transition of htop
On Wed, Dec 15, 2004 at 01:20:03PM +, Andreas Metzler wrote: Could someone take a look at htop transition? http://qa.debian.org/developer.php?excuse=htop http://bjorn.haxx.se/debian/testing.pl?package=htop Both pages say that my package hasn't been built on m68k yet, but that's not truth. It has been built on 30th of November: http://buildd.debian.org/fetch.php?pkg=htopver=0.5-1arch=m68kstamp=1101802311file=logas=raw So why didn't he enter sarge yet? Because the m68k package was not uploaded, you can see that on http://packages.debian.org/htop You might want to contact [EMAIL PROTECTED] Ok thanks, I've just sent mail. regards fEnIo -- _ Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | IRC:fEnIo _|_|_ 32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Polska (0 0) phone:+48602383548 | Slackware - the weakest link ooO--(_)--Ooo http://skawina.eu.org | JID:[EMAIL PROTECTED] | RLU:172001 signature.asc Description: Digital signature
Re: dselect survey
Package: aptitude Severity: wishlist Hi, [aptitude not properly handling packages installed by other tools] ACK. I very much prefer the way debfoster handles this: if there are new, unknown packages on the system, it will ask, rather than assume, whether a package is wanted or not. And will only do this for packages that are not depended upon; so if you ever remove a package, it will ask about its dependencies again. aptitude could be taught to have auto-installed being Yes,No or Unknown. Whenever a package that is in Unknown state could be removed if it were only installed as a dependency, aptitude should list them in the actions to be performed view as being still installed and unknown whether they can be removed. Until I make a decision (which I am not forced to do at this moment) the package would reappear in this list everytime it could be deinstalled (i.e. until another package depending on it is installed or a decision is made). (I'd also like to be able to search for these packages in order to clean up after my fellow sysadmins) Simon
Bug#285773: ITP: smartpm -- A alternative package manager that works with dpkg/rpm
Package: wnpp Version: N/A; reported 2004-12-15 Severity: wishlist * Package name: smartpm Version : 0.28 Upstream Author : Gustavo Niemeyer [EMAIL PROTECTED] * URL : http://linux-br.conectiva.com.br/~niemeyer/smart/files/ * License : GPL Description : A alternative package manager that works with dpkg/rpm The Smart Package Manager project has the ambitious objective of creating smart and portable algorithms for solving adequately the problem of managing software upgrading and installation. This tool works in all major distributions, and will bring notable advantages over native tools currently in use (APT, APT-RPM, YUM, URPMI, etc). . This project is in beta testing. Please, understand that bugs are expected to be found at that stage, and there are features that still must be implemented in the forthcoming future. -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux gluck 2.4.28-es #1 SMP Sun Nov 21 19:05:12 EST 2004 i686 Locale: LANG=C, LC_CTYPE=C
Re: Linux Core Consortium
On Tue, Dec 14, 2004 at 11:53:54AM -0500, Ian Murdock wrote: What about the LCC's scope isn't clear? Er, the fact that no actual scope has been stated? What does core mean? What packages (libraries) are included in this core? Core means implemention of LSB, and the packages/libraries that will constitute that are being determined now, as a collaborative process. Well, for instance, the libacl package was brought up as an example in the context of changing library SONAMEs/package names. The current LSB has nothing to say about this library; it covers only glibc, libstdc++, various core X libraries, zlib, libpam, libgcc, and ncurses. So there was some doubt in my mind as to how broad a core ISVs were actually demanding be specified, as well as doubt regarding the conclusion that the LSB process was flawed if the simple fact was that ISVs were demanding standardization of libraries that no one has asked the LSB to address. I still think implementation of the LSB is a murky concept; the LSB specifies very little about kernel behavior after all (though some things are implicit given the description of libc ABIs plus the de facto glibc implementation of them), so I don't know whether and how many userspace tools it's also seen as essential to cover. I assumed Debian would want to be involved in this process too, rather than being presented with a more well-defined scope as a fait accompli.. Particularly considering involvement in the LCC would require essentially unanimous consent of the maintainers of the covered core packages, I think it's impossible for Debian to be meaningfully involved without first having a clear understanding of what would be expected of us -- especially when late bouts of scope creep could hamstring the entire effort by suddenly requiring the consent of a new package maintainer who doesn't approve! I think it's better if this can all be laid out up front so we can get a clear yea or nay from the affected maintainers before sending people off to committee. If so, and given that these are very likely outcomes, what reason remains for Debian to get involved in the LCC if it's not going to result in any ISVs supporting Debian as a platform through the LCC effort? At the very least, the differences would be smaller than they otherwise would be, and that can only be a good thing for LCC, Debian, and the Linux world as a whole. On the contrary, I think that providing a single binary platform representing an overwhelming majority of the Linux market share that ISVs can write to, rather than enforcing the rigors of writing to an open standard such as the LSB, makes it much more likely for ISVs to demand bug-for-bug compatibility with the LCC binaries; which means that anyone not using the certified binaries is just that much farther up the proverbial creek. Keeping the differences small is only a benefit if ISVs do choose to test against Debian as well as against the LCC. And, who knows, with Debian participation, perhaps the differences would end up being small enough and the processes, methods, and mechanisms defined such that it's no longer a very likely outcome. I think that accepting outside binaries for core packages would be regarded by many in the community as devastating to Debian's security model. I think that requiring immutable sources for core packages would be equally devastating to Debian's development model. (If you see ways that Progeny would benefit from Debian's involvement in the LCC even if the official Debian releases are not LCC-certified in the end, I think that's relevant here; but I would like to know how you think it would benefit Progeny and other companies building on Debian, and why you think that Debian itself warrants representation at the table.) As I said at the very outset, one possible way forward is to simply produce a Debian-packaged version of the LCC core independently, and to make sure that core is 100% compatible with Debian (i.e., you can take any Debian package and install it on the LCC Debian core and get the same results as if you'd installed it on Debian itself). I would prefer to take this a step further in the opposite direction. Given that the LSB specifies a determined linker path as part of its ABI other than the one used by the toolchain by default, and given that the kernel is largely an independent, drop-in replacement wrt the rest of the packaging system, why *couldn't* we provide the LCC binaries in the same fashion as the current lsb package -- as a compatibility layer on top of the existing Debian system? This sidesteps the problem of losing certification over small divergences that significantly impact our other ports and is a much more tractable goal, while still giving us a target to aim for with our base system. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Linux Core Consortium
On Wed, Dec 15, 2004 at 12:51:21PM +0100, Michael Meskes wrote: On Fri, Dec 10, 2004 at 04:04:22PM +0100, Bill Allombert wrote: It seems to me than one of the main value of Debian is in the quality of its core distribution. One of the reason of the quality is that it is not developed for itself but as a platform for the 10^4+ packages and the 10+ architectures in Debian. For example the compiler must be ... Given that, an attempt to develop the core distribution as a separate entity is going to be impractical and to reduce its quality. Why? In fact you are proving your own argument wrong. [Please avoid resorting to such statement. It is worthless and can only irritate the person you reply to. Thanks.] distribution is developed as a core of more, let alone all, Linux distributions including Debian, the amount of packages using it as platform will certainly increase. My fear is that a core distribution developed as a core will only be tested against itself and not against all the other packages in Debian. On the other hand, nothing bars the LCC to build a distribution on top of Debian. There is a lot of precedent for doing so (Xandros,libranet, lycoris, linspire, mepis, etc.). This is one argument why I'd say, we surely should work with LCC. IIUC, the LCC is not about creating a source distribution and using it as a base for several distros, but to bless some binary build in a way that make inconvenient to use another build because you then lose the certification. This means Debian will have the choice between fixing bugs or keeping the certification but not both. As a practical matter, what if the Debian gcc team decide to release etch with gcc 3.3 because 3.4 break ABI on some platforms and gcc-4.x is not stable enough on all the platforms ? Will LCC follow ? If not, how are we going to share binary package if we do not use the same compiler? Another reason why we should work together as the problem will arise with the other dists anyway. Could you elaborate ? if that matters, I meant 'share binary package' in the sense of sharing the LCC binary packages, not sharing 3th-party packages. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here.
Re: Linux Core Consortium
Ian Murdock wrote: Because the LSB bases its certification process on a standard ABI/API specification alone, and this approach simply hasn't worked. Surely you're simplifying here? (See LSB-Core 2.0.1, chapters 3, 4, 5.) -- see shy jo signature.asc Description: Digital signature
Re: transition of htop
http://buildd.debian.org/ How accurate is the information on buildd? I wonder because I am using more recent versions than a few of those reported (at least those I checked - like gcc) http://buildd.debian.org/build.php?arch=sparcpkg=gcc ??? -- WC -Sx- Jones http://insecurity.org/
Re: transition of htop
* Chasecreek Systemhouse [Wed, 15 Dec 2004 10:55:53 -0500]: http://buildd.debian.org/ How accurate is the information on buildd? I wonder because I am using more recent versions than a few of those reported (at least those I checked - like gcc) http://buildd.debian.org/build.php?arch=sparcpkg=gcc in buildd.d.o, you should specify a source package. try gcc-defaults, and gcc-3.3. it seems that the 'gcc' source package existed for a very short timeframe (?). -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 Listening to: Astrud - Todo nos parece una mierda A dream is an answer to a question that we don't know how to ask.
Re: transition of htop
On Wed, 15 Dec 2004 17:00:02 +0100, Adeodato Simó [EMAIL PROTECTED] wrote: in buildd.d.o, you should specify a source package. try gcc-defaults, and gcc-3.3. it seems that the 'gcc' source package existed for a very short timeframe (?). Yes, you are right. I forgot. Or, better yet, an R/E can be written/changed to tell me all about GCC and Sparc using Perl or PCRE. -- WC -Sx- Jones http://insecurity.org/
Re: If you really want Free firmware...
On Monday 13 December 2004 21:24, Andrew Suffield wrote: What does that have to do with hardware, please? I mean, it's a lovely statement and all, but it's wrong. Right back at you. Smarmy, but useless. Ok, I have figured out that you have nothing useful to say. Thank you. And from another post by you: And yet you're quoting Redmond propaganda as if it were the only truth. We're talking about hardware, not Microsoft. Do you have any, *actual* hardware design experience? I do. You have a weird, uninformed, dork agenda that I don't even want to get into. Let it go, brother.
Re: If you really want Free firmware...
On Tue, Dec 14, 2004 at 11:27:45AM -0600, Kenneth Pronovici wrote: Message-ID: [EMAIL PROTECTED] Hamish said, Manufacturing an ASIC involves NRE...of hundreds of thousands to millions per revision... Message-ID: [EMAIL PROTECTED] You said, Manufacturing an operating system involves NRE costs of hundreds of thousands to millions per revision... you're quoting Redmond propoganda... [This implied that Hamish's numbers were not valid.] Message-ID: [EMAIL PROTECTED] (This is the message you just replied to) I said, Do you have any actual hardware design experience to draw on here..., in reply to your implication about Hamish's numbers. Clear now? Ah, you misinterpreted my point in quite an impressive way. Valid numbers or not, his statement was of the form Here is how we do it, and our way is the only way in which it is possible to do it. And we've heard that one before. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
installing a source tree?
Installing a source tree? (But NOT a CVS tree.) OK, this is probably somewhat retarded -- because I cannot figure it out and it very likely is simple and I am missing something basic: I would like to install a software package that requires the PostgresSQL development and source code tree -- so that the new software can be compiled against it. If this were RH or FC or SuSE I would simply download and compile all required source code until I got it all working -- this takes a friggin' long time. =( I do not wish to do that on my Debian Ultrasparc because the previous procedure also has a bad habit of breaking my system too =/ So, I humbly request suggestions or hints as to a direction I can follow to be able to get the source cod and development tree (READ Not CVS Tree) of say package PostgresSQL. I have tried variations of - apt-get install postgresql-source as well as variations of - apt-get build-dep [package] apt-get source --compile [package] However the other package cannot find the PostgresSQL source tree. I'm creating/documenting a quick Debian_Hints file at: http://insecurity.org/ll3i11_j0n35/Debian_Hints -- WC -Sx- Jones http://insecurity.org/
Re: installing a source tree?
On Wed, Dec 15, 2004 at 12:01:24PM -0500, Chasecreek Systemhouse wrote: So, I humbly request suggestions or hints as to a direction I can follow to be able to get the source cod and development tree (READ Not CVS Tree) of say package PostgresSQL. I have tried variations of - apt-get install postgresql-source as well as variations of - apt-get build-dep [package] apt-get source --compile [package] However the other package cannot find the PostgresSQL source tree. First of all download the source which matches the package you have installed with: apt-get source postgresql Then you'll need to examine the software you're trying to build against it to see how it finds the source directory. Maybe there's a flag to use: ./configure --source=../postgresql.. Or similar. Honestly I'm suprised you need the full package source. Normally you'd just get the development packages to give you the header files and the libraries which are linked against. In your case that would be the stuff provided by the package 'postgresql-dev'. What's the name of the software you're trying to build? I'm creating/documenting a quick Debian_Hints file at: http://insecurity.org/ll3i11_j0n35/Debian_Hints Have you read many of the fine Debian manuals? There's a lot of good stuff linked to from: http://www.debian.org/doc/ Steve --
Re: If you really want Free firmware...
On Wed, Dec 15, 2004 at 05:00:12PM +, Andrew Suffield wrote: On Tue, Dec 14, 2004 at 11:27:45AM -0600, Kenneth Pronovici wrote: Message-ID: [EMAIL PROTECTED] Hamish said, Manufacturing an ASIC involves NRE...of hundreds of thousands to millions per revision... Message-ID: [EMAIL PROTECTED] You said, Manufacturing an operating system involves NRE costs of hundreds of thousands to millions per revision... you're quoting Redmond propoganda... [This implied that Hamish's numbers were not valid.] Message-ID: [EMAIL PROTECTED] (This is the message you just replied to) I said, Do you have any actual hardware design experience to draw on here..., in reply to your implication about Hamish's numbers. Clear now? Ah, you misinterpreted my point in quite an impressive way. Valid numbers or not, his statement was of the form Here is how we do it, and our way is the only way in which it is possible to do it. And we've heard that one before. You seem to spend a great deal of time criticizing other people's methods and statements, and very little time analyzing your own. If you made any effort to back up your statements, it would be more difficult to misinterpret them. A good start would be to indicate exactly which hardware-development-related Redmond propogranda Hamish was supposedly quoting, rather than relying on this list's innate distrust of Redmond to make your point for you. Another good start would be to honestly answer when people ask your what experience you have with a subject, rather than silently ignoring the question. I really don't care about the numbers. I don't actually even care about this thread, especially now that Bruce and others have given us numbers that make most of the discussion moot. What annoys me is your constant pounding on other people's credibility, especially since you don't ever seem to accept anyone else's criticism of your credibility. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] pgpKUOFmwtO3b.pgp Description: PGP signature
Re: installing a source tree?
On Wed, 15 Dec 2004 17:13:10 +, Steve Kemp [EMAIL PROTECTED] wrote: 'postgresql-dev'. What's the name of the software you're trying to build? I'm creating/documenting a quick Debian_Hints file at: http://insecurity.org/ll3i11_j0n35/Debian_Hints Have you read many of the fine Debian manuals? There's a lot of good stuff linked to from: http://www.debian.org/doc/ Yes, um, but I'll read them more =) Its a Accounting/Ledger system from http://www.sql-ledger.org/ -- sql-ledger is written in Perl and seems simple enough but I'm getting strange cannot be found issues. Like I mis-configured Debian/Perl/PostgresSQL =/ =) But I doubt that however. Probably just been awake too long. Thanks for the quick reply =) -- WC -Sx- Jones http://insecurity.org/
Re: installing a source tree?
Chasecreek Systemhouse [EMAIL PROTECTED] schrieb: I have tried variations of - apt-get install postgresql-source as well as variations of - apt-get build-dep [package] apt-get source --compile [package] What about apt-get source postgresql? Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: If you really want Free firmware...
[EMAIL PROTECTED] wrote: On Wed, Dec 15, 2004 at 05:00:12PM +, Andrew Suffield wrote: Ah, you misinterpreted my point in quite an impressive way. Valid numbers or not, his statement was of the form Here is how we do it, and our way is the only way in which it is possible to do it. And we've heard that one before. I really don't care about the numbers. I don't actually even care about this thread, especially now that Bruce and others have given us numbers that make most of the discussion moot. What annoys me is your constant pounding on other people's credibility, especially since you don't ever seem to accept anyone else's criticism of your credibility. That's just Suffield being an annoying prick, as usual. Common consenus is that he's generally best ignored... -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] Getting a SCSI chain working is perfectly simple if you remember that there must be exactly three terminations: one on one end of the cable, one on the far end, and the goat, terminated over the SCSI chain with a silver-handled knife whilst burning *black* candles. --- Anthony DeBoer
Re: installing a source tree?
On Wed, 15 Dec 2004 18:35:40 +0100, Frank Küster [EMAIL PROTECTED] wrote: What about apt-get source postgresql? Yes I did, but that doesn't place/install it into the proper places -- what(where)ever they may be. I could have just as easily download the source from postgressql website and installed it into /usr/local ... thereby by-passing the Debian stuff. I want what Debian has AND how Debian has it =) NOW! j/k :-) OK, Imma 41 year old child still. LOL. :-) Let me go read more. -- WC -Sx- Jones http://insecurity.org/
Re: installing a source tree?
Chasecreek Systemhouse wrote: Its a Accounting/Ledger system from http://www.sql-ledger.org/ -- apt-get install sql-ledger
Re: Linux Core Consortium
* Michael Meskes: Instead, proprietary software vendors should ship all libraries in the versions they need, or link their software statically. I wouldn't From a technical standpoint this may make sense, but not from the commercial standpoint ISVs have to take. Building your own environment to work on all distros is certainly much more work than just certifying for the one distribution you use in your development labs anyway. LCC could concentrate on providing such a distribution-independent execution environment, and perform the necessary integration tests for commercially relevant distributions. Just an idea. I think this is far more promising than lobbying distributions to delegate responsibility for core packages.
Re: installing a source tree?
On Wed, 15 Dec 2004 18:55:53 +0100, Peter Eisentraut [EMAIL PROTECTED] wrote: apt-get install sql-ledger Um, that didn't work last night and I cannot find what command I used when grep'ing history either ... Yep, thats my story. OK, Im going back to my cave -- sorry for the noise. (Thanks for fixing it -- um, Peter, everyone :) -- WC -Sx- Jones http://insecurity.org/
Re: installing a source tree?
On Wed, Dec 15, 2004 at 12:24:15PM -0500, Chasecreek Systemhouse wrote: On Wed, 15 Dec 2004 17:13:10 +, Steve Kemp [EMAIL PROTECTED] wrote: 'postgresql-dev'. What's the name of the software you're trying to build? I'm creating/documenting a quick Debian_Hints file at: http://insecurity.org/ll3i11_j0n35/Debian_Hints Have you read many of the fine Debian manuals? There's a lot of good stuff linked to from: http://www.debian.org/doc/ Yes, um, but I'll read them more =) Its a Accounting/Ledger system from http://www.sql-ledger.org/ -- sql-ledger is written in Perl and seems simple enough but I'm getting strange cannot be found issues. Like I mis-configured Debian/Perl/PostgresSQL =/ =) But I doubt that however. I tried sql-ledger a while ago (version 2.0.9), and IIRC it did not need the postgresql source, or even the -dev package. However, it does need libpgperl or libdbd-pg-perl (I don't remember which, probably libpgperl) Frank Probably just been awake too long. Thanks for the quick reply =) -- WC -Sx- Jones http://insecurity.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. - Brian W. Kernighan
Re: Linux Core Consortium
On Wed, 15 Dec 2004 18:59:05 +0100, Florian Weimer [EMAIL PROTECTED] wrote: LCC could concentrate on providing such a distribution-independent execution environment, and perform the necessary integration tests for commercially relevant distributions. Just an idea. I think this is far more promising than lobbying distributions to delegate responsibility for core packages. I very much I agree. I'm totally confused by this whole thread. What advantage - both in compatibility and competitiveness - would LCC benefit any distribution? First I read that LCC is a standards body (implying a *like* to have feature set) next I read its a certification body (implying a *must* have feature set) -- is RH/FC gonna change all their certifications or will Debian change to conform to RH/FC testing? Which Distribution set the *standard* -- maybe I missed that? Please understand, I'm not tryng to start a flame war but simply trying to see what real tangible benefit to systems admins/developers rolling out hetergenous architectures using RH/FC/SuSE/Debian... Maybe the thread has went off topic and I got lost somewhere. -- WC -Sx- Jones http://insecurity.org/
Re: If you really want Free firmware...
On Wed, Dec 15, 2004 at 05:40:30PM +, Steve McIntyre wrote: [EMAIL PROTECTED] wrote: On Wed, Dec 15, 2004 at 05:00:12PM +, Andrew Suffield wrote: Ah, you misinterpreted my point in quite an impressive way. Valid numbers or not, his statement was of the form Here is how we do it, and our way is the only way in which it is possible to do it. And we've heard that one before. I really don't care about the numbers. I don't actually even care about this thread, especially now that Bruce and others have given us numbers that make most of the discussion moot. What annoys me is your constant pounding on other people's credibility, especially since you don't ever seem to accept anyone else's criticism of your credibility. That's just Suffield being an annoying prick, as usual. Common consenus is that he's generally best ignored... Yeah, I know. I just feel better after saying it. :-) Getting a SCSI chain working is perfectly simple if you remember that there must be exactly three terminations: one on one end of the cable, one on the far end, and the goat, terminated over the SCSI chain with a silver-handled knife whilst burning *black* candles. --- Anthony DeBoer Heh. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] pgpDKmKlXpM0k.pgp Description: PGP signature
Re: Linux Core Consortium
On Wed, 15 Dec 2004 12:51:21 +0100, Michael Meskes [EMAIL PROTECTED] said: On Fri, Dec 10, 2004 at 04:04:22PM +0100, Bill Allombert wrote: It seems to me than one of the main value of Debian is in the quality of its core distribution. One of the reason of the quality is that it is not developed for itself but as a platform for the 10^4+ packages and the 10+ architectures in Debian. For example the compiler must be ... Given that, an attempt to develop the core distribution as a separate entity is going to be impractical and to reduce its quality. Why? In fact you are proving your own argument wrong. If a seperate core distribution is developed as a core of more, let alone all, Linux distributions including Debian, the amount of packages using it as platform will certainly increase. Only if this separate entity also is committed to all 11 architectures. And follows a consistent technical policy. Ans is supported by a QA team, security team, and potentially 1000 experienced developers to pick up slack. I am not sure I am convinced that the benefits are worth outsourcing the core of our product -- and I think that most business shall tell you that is a bad idea. As a practical matter, what if the Debian gcc team decide to release etch with gcc 3.3 because 3.4 break ABI on some platforms and gcc-4.x is not stable enough on all the platforms ? Will LCC follow ? If not, how are we going to share binary package if we do not use the same compiler? Another reason why we should work together as the problem will arise with the other dists anyway. I think that very often Debian's technical solution have been better than the other distributions, since there is a tendency to do the right thing in Debian, as opposed to meeting marketing deadlines. manoj -- The time is right to make new friends. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: transition of htop
hi, * Bartosz Fenski aka fEnIo [EMAIL PROTECTED] [2004-12-15 18:05]: Could someone take a look at htop transition? http://qa.debian.org/developer.php?excuse=htop http://bjorn.haxx.se/debian/testing.pl?package=htop Both pages say that my package hasn't been built on m68k yet, but that's not truth. It has been built on 30th of November: http://buildd.debian.org/fetch.php?pkg=htopver=0.5-1arch=m68kstamp=1101802311file=logas=raw So why didn't he enter sarge yet? it is offtopic, but htop is one of my favorite programs. great work! regards ncio -- Nico Golde - [EMAIL PROTECTED] | GPG: 1024D/73647CFF ,'`. [EMAIL PROTECTED] | http://www.ngolde.de ( grml.org VIM has two modes - the one in which it beeps`._,' and the one in which it doesn't -- encrypted mail preferred
Re: Linux Core Consortium
Manoj Srivastava wrote: I am not sure I am convinced that the benefits are worth outsourcing the core of our product -- and I think that most business shall tell you that is a bad idea. Well, please don't tell this to all of the people who we are attempting to get to use Linux as the core of their products. Also, please make sure to tell the upstream maintainers that we aren't going to use their code any longer, because we have decided that it's a bad idea to outsource the core of our product. Bruce smime.p7s Description: S/MIME Cryptographic Signature
Re: Linux Core Consortium
On Thu, 09 Dec 2004 12:40:29 -0500, Ian Murdock [EMAIL PROTECTED] said: If you're having trouble picturing how Debian might engage the LCC, here's my ideal scenario: the source packages at the core of Debian are maintained in collaboration with the other LCC members, and the resulting binaries built from those source packages are made available in both RPM and .deb format. Hmm. Does this not impede Debian in new directions we may like to take the distribution, like, say, making Debian be Se-Linux compatible, if we so choose? Fedora core 3 has done it, and it requires changes to the kernel, which Debian has accepted, and changes to core package, which is an option for Etch? What if the LCC members do not decide to do that? What happens if the situation is reversed? (LCC decides to go with RSBAC while we do not). Would outsourcing the core packages to third parties not make us less nimble (if I can use the word with a straight face)? manoj -- Truth has no special time of its own. Its hour is now -- always. Albert Schweitzer Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
software raid question/confusion
I installed the mdadm package recently. version 1.3.0-2 I do not want the md devices to be started when I reboot the server. I cannot find the config file which specifies this. The only way I was able to stop this was to edit /etc/init.d/mdadm-raid. I can't even find what process is calling mdadm-raid. Please advise. --David Dougall
Re: Bug#285768: dselect survey
On Wednesday 15 December 2004 09:01 am, Simon Richter wrote: aptitude could be taught to have auto-installed being Yes,No or Unknown. Whenever a package that is in Unknown state could be removed if it were only installed as a dependency, aptitude should list them in the actions to be performed view as being still installed and unknown whether they can be removed. Until I make a decision (which I am not forced to do at this moment) the package would reappear in this list everytime it could be deinstalled (i.e. until another package depending on it is installed or a decision is made). It seems like Unknown would just be a synonym for No, right? Presumably with a way to search for unknown packages (I think ~U isn't taken yet). Daniel -- /--- Daniel Burrows [EMAIL PROTECTED] --\ | Inconceivable! | | -- The Princess Bride | \ Evil Overlord, Inc: http://www.eviloverlord.com --/ pgpiEiMbkGLus.pgp Description: PGP signature
Re: software raid question/confusion
David Dougall wrote: I installed the mdadm package recently. version 1.3.0-2 I do not want the md devices to be started when I reboot the server. I cannot find the config file which specifies this. The only way I was able to stop this was to edit /etc/init.d/mdadm-raid. I can't even find what process is calling mdadm-raid. Please advise. --David Dougall You if you delete all the links that match /etc/rc?.d/S??mdadm-raid then /etc/init.d/mdadm-raid start won't be invoked at boot. Regards, -- Sam Morris
Re: Linux Core Consortium
Bruce Well, please don't tell this to all of the people who we are attempting to get to use Linux as the core of their products. core (software architecture) != core (customer value). Also, please make sure to tell the upstream maintainers that we aren't going to use their code any longer, because we have decided that it's a bad idea to outsource the core of our product. Debian isn't a product, it's a project, and the core of the project isn't code, it's principles and processes. Outsourcing the core of Debian would be delegating judgements about software freeness and integrity. Cheers, - Michael
Re: Linux Core Consortium
On Wed, 15 Dec 2004 10:44:50 -0800, Bruce Perens [EMAIL PROTECTED] said: Manoj Srivastava wrote: I am not sure I am convinced that the benefits are worth outsourcing the core of our product -- and I think that most business shall tell you that is a bad idea. Well, please don't tell this to all of the people who we are attempting to get to use Linux as the core of their products. Also, please make sure to tell the upstream maintainers that we aren't going to use their code any longer, because we have decided that it's a bad idea to outsource the core of our product. Hmm. I am not sure how to take this: either you are spoiling for a fight, or you do not take your duties as a developer very seriously. For the nonce, though, I'll treat this email seriously. When I package software from upstream, I have skimmed the sources, ensured that the resulting .deb meets Debian policy, which may require major changes to upstream's layout, and I listen to my users, adding features, removing lacunae, and generally being more than a mechanical packager of software. I am not just swilling pap sight unseen into Debian's repository, and my work is what makes it different from outsourcing the package upstream. If you say that we can do the same to any LCC package, I have no objections; we can surely treat LCC as an upstream contributor, and massage their changes into debian packages like we have always done. manoj -- Good people are good because they've come to wisdom through failure. -William Saroyan Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Linux Core Consortium
Manoj Srivastava wrote: Hmm. Does this not impede Debian in new directions we may like to take the distribution, like, say, making Debian be Se-Linux compatible, if we so choose? I think it means that Debian gets to be leader regarding the things it cares about. I doubt that the other distributions participating would object to having NSA Secure Linux compatibility dropped in their lap. What happens if the situation is reversed? (LCC decides to go with RSBAC while we do not). It would be an interesting discussion. I don't see any reason that Debian needs to be steam-rollered, though. At the bottom of these two competing security implementations are two currently-incompatible APIs through which they connect to the kernel. It's not clear to me that REG and GFAC patches must be incompatible with LSM. It also seems that REG and GFAC abstract more facilities while LSM provides raw (and changing) access to those facilities. It would be nice if they would come to a merge. Would outsourcing the core packages to third parties not make us less nimble (if I can use the word with a straight face)? Nobody is saying that you can't override the external stuff when necessary. Security would be a good reason to do so, if LCC is being tardy compared to Debian. Thanks Bruce smime.p7s Description: S/MIME Cryptographic Signature
Re: Linux Core Consortium
On Wed, 15 Dec 2004 11:21:02 -0800, Michael K Edwards [EMAIL PROTECTED] said: Bruce Well, please don't tell this to all of the people who we are attempting to get to use Linux as the core of their products. core (software architecture) != core (customer value). Also, please make sure to tell the upstream maintainers that we aren't going to use their code any longer, because we have decided that it's a bad idea to outsource the core of our product. Debian isn't a product, it's a project, So it is good that I did not say Debian, or the project, eh? Did you really read what I said? Debian, the project, produces an OS, which it releases, from time to time (often too long in between). This OS, in the current form, has a core set of packages, built around the Linux kernel, though in the future the Hurd or the BSD style kernels may be substituted. We are talking about outsourcing these core packages, which for the core of the product, the OS, that the Debian project produces. I would have not expected to have to explain this on the -devel mailing list. and the core of the project isn't code, it's principles and processes. Outsourcing the core of Debian would be delegating judgements about software freeness and integrity. You do a nice job tilting at paper tigers. Bravo! manoj -- Never call a man a fool; borrow from him. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Bug#285811: ITP: shtoom -- Cross platform VoIP softphone in python
Package: wnpp Severity: wishlist * Package name: shtoom Version : 0.2 Upstream Author : Anthony Baxter [EMAIL PROTECTED] * URL : http://www.divmod.org/Home/Projects/Shtoom/ * License : LGPL Description : Cross platform VoIP softphone in python Shtoom is a open-source, cross-platform VoIP softphone, implemented in Python. As well as the basic phone, the package also includes a number of other applications - * shtoom - the end-user phone * shtam - a simple answering machine/voicemail application * shmessage - an announcement server -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.8-1-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Bug#285816: ITP: styleclock -- KDE themable clock applet
Package: wnpp Severity: wishlist * Package name: styleclock Version : 0.5.1 Upstream Author : Fred Schttgen [EMAIL PROTECTED] * URL : http://fred.hexbox.de/styleclock/ * License : GPL Description : KDE themable clock applet Styleclock is a themeable replacement for KDE's clock applet. It comes with an integrated alarm clock / timer.
Bug#285814: ITP: libtom0 -- wraper library for using OpenGL from tcl
Package: wnpp Severity: wishlist * Package name: libtom0 Version : 0.2 Upstream Author : [EMAIL PROTECTED] * URL : http://perso.club-internet.fr/dropfred/index_en.html * License : GPL Description : wraper library for using OpenGL from tcl Tom is an OpenGL wrapper for Tcl / Tk. About 90 % of OpenGL functionality is implemented, plus some GLUT (OpenGL utility) functions. It supports Linux and Windows. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.7-1-k7 Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15
Re: Bug#285518: misdn-utils includes a firmware loader
On Tue, 14 Dec 2004 14:21:54 +0100, Simon Richter [EMAIL PROTECTED] said: Hi, It's fine for software in main to be able to do stuff with non-free data; that's not the issue. The question is whether there *exists* any free data that it works with, and if not, whether that's a problem. I don't believe that is a problem. We don't ship the non-free data, we just allow its use. I can see your point, however, that it is useless to ship an utility that cannot be used at present without having non-free data installed. Well, if you need the non-free component to be on the file system, why is this different from contrib? Why can't say of everything in contrib that well, if the non-free jvm were to magically appear on the file system this java code would work? Or any other non-free stuff that needs to be on the fs? manoj -- Boy, that crayon sure did hurt! Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: software raid question/confusion
On Wed, 15 Dec 2004 19:00:44 +, Sam Morris wrote: David Dougall wrote: I installed the mdadm package recently. version 1.3.0-2 I do not want the md devices to be started when I reboot the server. I cannot find the config file which specifies this. The only way I was able to stop this was to edit /etc/init.d/mdadm-raid. I can't even find what process is calling mdadm-raid. Please advise. --David Dougall You if you delete all the links that match /etc/rc?.d/S??mdadm-raid then /etc/init.d/mdadm-raid start won't be invoked at boot. As it's been pointed to me (several times) it's better to rename such links to the appropriate K??* form than to remove them completely. It has better defined meaning and prevents invoke-rc.d from running the scripts on upgrades. -- Micha Politowski Talking has been known to lead to communication if practised carelessly. signature.asc Description: Digital signature
Naming for OSSP projects in Debian (libraries, dirs)
URL: http://www.ossp.org
Hi Dexter,
I saw that you also ITP a OSSP (www.ossp.org) project for Debian:
OSSP uuid. I intent to do the same for OSSP sa. I'm using the sa
library successful for a small application so my intention is
make it public for others who intent to do the same too.
I've done already a Debian package and intent to sync the future
OSSP work with you. The problem I see with OSSP are the too simple
names e.g. libsa or libuuid. The header files are also installed
by default in /usr/include. This will lead in problems for uuid
more then for sa because Debian provide already more then one
file with the name uuid.h:
http://packages.debian.org/cgi-bin/search_contents.pl?word=uuid.hsearchmode=searchfilescase=insensitiveversion=unstablearch=i386
We run in naming conflicts with other packages sooner or later.
It would be nice if we can have the same name semantic for this
two OSSP packages. I would propose:
Header files go to /usr/include/ossp/*, e.g. /usr/include/ossp/{sa,uuid}.h
Library start with libossp*, e.g. libossp{sa,uuid}*.
The problem is that Debian will become binary incompatible with
foreign programs base on OSSP libraries :( I hope we find a solution
that match the requirements of the OSSP project and Debian.
--
Raphael Bossek
pgppc0eSBoR6C.pgp
Description: PGP signature
Re: Linux Core Consortium
On Wed, 15 Dec 2004 11:29:47 -0800, Bruce Perens [EMAIL PROTECTED] said: Nobody is saying that you can't override the external stuff when necessary. Security would be a good reason to do so, if LCC is being tardy compared to Debian. Well, that does address my concern, thanks. manoj -- Okay ... I'm going home to write the I HATE RUBIK's CUBE HANDBOOK FOR DEAD CAT LOVERS ... Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Linux Core Consortium
Manoj Srivastava wrote: Hmm. I am not sure how to take this: either you are spoiling for a fight, or you do not take your duties as a developer very seriously. I was taking the implications of your statements farther than you intended, in order to get you to give them additional thought. This is a common rhetorical device. You should consider that I might be using it before you get to "he's crazy or irresponsible" :-) When I package software from upstream, I have skimmed the sources, ensured that the resulting .deb meets Debian policy, which may require major changes to upstream's layout, and I listen to my users, adding features, removing lacunae, and generally being more than a mechanical packager of software. And hopefully this is an act of collaboration with the upstream developer. I looked for core ABI packages that you maintain. The closest I found was libselinux1. You had a half-megabyte (uncompressed) patch for that, which it turns out is because your arch repositories and other arch-related cybercrud are in there. Probably this is common in debian diffs. When I filtered that out, I got this: Only in libselinux-1.18.Manoj: debian --- lots of files under here. diff -r libselinux-1.18/man/man3/security_setenforce.3 libselinux-1.18.Manoj/man/man3/security_setenforce.3 1c1 .so security_getenforce.3 --- .so man3/security_getenforce.3.gz diff -r libselinux-1.18/src/dso.h libselinux-1.18.Manoj/src/dso.h 10c10 # ifdef __alpha__ --- # if defined(__alpha__) || defined(__mips__) Congratulations, you got all Debian-specific stuff under debian/ except for one little issue about compressing man pages that perhaps should be hacked into groff. You have a lot of makefile-related stuff under debian. I would have to assume that is almost all implementing Debian policy and fitting into the autobuild mechanism for all Debian architectures. It seems to me to be the sort of thing we'd be able to come to agreement about across LCC. IMO Debian is ahead of the others as far as policy is concerned, and acceptance of much of the Debian policy manual into LCC would be the first order of business for me. I am not just swilling pap sight unseen into Debian's repository, and my work is what makes it different from outsourcing the package upstream. Here you are making an assumption that I feel is not warranted. You assume that the other distributions concerned with this matter will wish to run rough-shod over Debian's policies and your own quality process, without giving you a say. We have no reason to believe that yet. Thanks Bruce smime.p7s Description: S/MIME Cryptographic Signature
Re: Bug#285768: dselect survey
On Wed, Dec 15, 2004 at 01:53:20PM -0500, Daniel Burrows wrote: On Wednesday 15 December 2004 09:01 am, Simon Richter wrote: aptitude could be taught to have auto-installed being Yes,No or Unknown. Whenever a package that is in Unknown state could be removed if it were only installed as a dependency, aptitude should list them in the actions to be performed view as being still installed and unknown whether they can be removed. Until I make a decision (which I am not forced to do at this moment) the package would reappear in this list everytime it could be deinstalled (i.e. until another package depending on it is installed or a decision is made). It seems like Unknown would just be a synonym for No, right? Uh, yes. I think. You may want to explain that a bit more. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune
Re: Linux Core Consortium
Hello, Wichmann, Mats D wrote: My experience as a developer who's tried to write an app to use the LSB (only the init script interface) is that it's poorly enough specified and/or implemented divergently within the spec to the point that I had to test my implementation on every LSB distriution I wanted to support, and might as well have written distro-specific code in the first place. Unfortunally, some distributions don't seem to be willing to do more than the minimal changes to adhere to the LSB. I did some patches for RedHat - and the bugreport is still open (I don't know whether the patches still work). SUSE seems to try hardest to be LSB complient and Debian was rather quick to implement my requests. I had no access to other distributions. Unfortunately, while we got spec contribution in this area, we didn't get matching code contributions: tests OR sample implementation. (I think I'm ment with regards to the first two points.) Regarding the latter, SUSE's implementation should completely fullfil the LSB requirements (tough the init-functions may be a bit SUSE centric) whereas Debian's system is also quite ok. (Though start-stop-damon doesn't find out that my PERL script damon is running...) I agree with Mats that the best way to enforce init script support are test cases. Unfortunally, I ended up doing not much more than writing the http://www.physik.fu-berlin.de/~tburnus/lsb/LSB-SYSINIT-TS_SPEC_V1.0. Now - one year later - I really should continue the work I started! Regarding Tobias
Re: Bug#285768: dselect survey
On Wednesday 15 December 2004 03:37 pm, Wouter Verhelst wrote: It seems like Unknown would just be a synonym for No, right? Uh, yes. I think. You may want to explain that a bit more. Well, from the bug report, it looks like the proposal is to maintain the current behavior, but to set a different flag on packages that were conservatively assumed to be manually installed, so they can be switched later to automatic handling if desired. Sounds useful. Daniel -- /--- Daniel Burrows [EMAIL PROTECTED] --\ | Thank you for reading me, but the real .signature is in another email. | \- Does your computer have Super Cow Powers? --- http://www.debian.org -/ pgpzIku2aqCBx.pgp Description: PGP signature
Re: software raid question/confusion
That file does not appear to exist. I did find the links in /etc/rc0.d, rcS.d and rc6.d after the fact Why is it starting the raids in runlevel 0 and 6 anyway? That seems a little weird. Also, I have AUTOSTART=false in /etc/mdadm/debian.conf. But, the script jumps to the next else statement if it is not set to true and therefore will automatically start the raids anyway. I have no problem editing the scripts, but I don't want them to be overwritten when I upgrade the package later on. I was hoping that a config option somewhere would do the trick. If I delete the debian.conf file, it will not start the raids. Will this file get replaced during an upgrade? If I symlink it to /dev/null or something ugly like that, will it work? Thanks --David Dougall On Wed, 15 Dec 2004, Jose Luis Painceira wrote: David Dougall wrote: I installed the mdadm package recently. version 1.3.0-2 I do not want the md devices to be started when I reboot the server. I cannot find the config file which specifies this. The only way I was able to stop this was to edit /etc/init.d/mdadm-raid. I can't even find what process is calling mdadm-raid. Take a look at /etc/default/mdadm Regards, Jose Luis Painceira
Re: Linux Core Consortium
On Wed, Dec 15, 2004 at 01:36:47PM -0600, Manoj Srivastava wrote: On Wed, 15 Dec 2004 11:21:02 -0800, Michael K Edwards [EMAIL PROTECTED] said: Bruce Well, please don't tell this to all of the people who we are attempting to get to use Linux as the core of their products. core (software architecture) != core (customer value). Also, please make sure to tell the upstream maintainers that we aren't going to use their code any longer, because we have decided that it's a bad idea to outsource the core of our product. Debian isn't a product, it's a project, So it is good that I did not say Debian, or the project, eh? Did you really read what I said? I hate to interfer, but it seems you assume Michael is replying to you where in fact he was replying to Bruce's answer to your post. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here.
Re: Linux Core Consortium
On Wed, 15 Dec 2004 12:13:58 -0800, Bruce Perens [EMAIL PROTECTED] said: 1. (*) text/plain ( ) text/html Manoj Srivastava wrote: Hmm. I am not sure how to take this: either you are spoiling for a fight, or you do not take your duties as a developer very seriously. I was taking the implications of your statements farther than you intended, in order to get you to give them additional thought. This is a common rhetorical device. You should consider that I might be using it before you get to he's crazy or irresponsible :-) So it was inflammatory, then. Comes under spoiling for a fight. I looked for core ABI packages that you maintain. The closest I found was libselinux1. You had a half-megabyte (uncompressed) patch for that, which it turns out is because your arch repositories and other arch-related cybercrud are in there. Probably this is common in debian diffs. When I filtered that out, I got this: Rather than look at new, hectically maintained packages that have yet to see real use, try my standard packages -- make, or flex. Make has had four separate lines of development integrated into it, apart from upstream -- one is trivially updating the autotools, another is additional i18n documentation, yet another is a varbuf fix, apart from other, minor debian tweaks, Flex is far more interesing. It has been broken up into flex-old, and flex, and each branch has several independent fixes in them -- is a listing of the branches involved. flex--autotools-refresh--2.5 flex--debian--2.5 flex--devo--2.5 flex--doc-fix--2.5 flex--m4-quotes-fix--2.5 flex--non-asni-fn-fix--2.5 flex--str-fix--2.5 flex--stream-ptr-fix--2.5 flex--unistd-fix--2.5 flex--old-c-fixups--2.5 flex--old-debian--2.5 flex--old-devo--2.5 flex--old-doc-fixes--2.5 flex--old-i18l-fix--2.5 flex--upstream--2.5 Now, separate out the devo branch -- which is the integration branch, this is still a fair shake from just packaging any old thing upstream slings at us. # if defined(__alpha__) || defined(__mips__) This was a minor FTBS issue for arches upstream does not have. It seems to me to be the sort of thing we'd be able to come to agreement about across LCC. IMO Debian is ahead of the others as far as policy is concerned, and acceptance of much of the Debian policy manual into LCC would be the first order of business for me. So, which version of flex you think you want to ship? The old one, which is POSIXLY correct, but does not work with modern g++, or the new one that is threaded, renterant, works with modern compilers, and disdains POSIX? I am not just swilling pap sight unseen into Debian's repository, and my work is what makes it different from outsourcing the package upstream. Here you are making an assumption that I feel is not warranted. You assume that the other distributions concerned with this matter will wish to run rough-shod over Debian's policies and your own quality process, without giving you a say. We have no reason to believe that yet. Are other distributions willing to abide by Debian policy? If so, I may come around to favour us participating even now. manoj -- What is the sound of one hand clapping? Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: software raid question/confusion
David Dougall wrote: That file does not appear to exist. I did find the links in /etc/rc0.d, rcS.d and rc6.d after the fact Why is it starting the raids in runlevel 0 and 6 anyway? That seems a little weird. [...] You seem to be using an old version of mdadm The current mdadm in woody is 0.7.2-2, but sarge is 1.7.0-2 You may also want to try dpkg-reconfigure mdadm Mine works fine, it's init script reads /etc/default/mdadm and starts the daemon only if $START_DAEMON == 'true'. Don't touch the scripts, you'll lose your changes on the next upgrade. Regards, Jose Luis Painceira
Re: Linux Core Consortium
On Wed, Dec 15, 2004 at 11:29:47AM -0800, Bruce Perens wrote: Would outsourcing the core packages to third parties not make us less nimble (if I can use the word with a straight face)? Nobody is saying that you can't override the external stuff when necessary. Security would be a good reason to do so, if LCC is being tardy compared to Debian. But overriding them means we lose the certification ? Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here.
Re: Naming for OSSP projects in Debian (libraries, dirs)
On Wed, Dec 15, 2004 at 09:05:53PM +0100, Raphael Bossek wrote: OSSP work with you. The problem I see with OSSP are the too simple names e.g. libsa or libuuid. The header files are also installed by default in /usr/include. This will lead in problems for uuid more then for sa because Debian provide already more then one file with the name uuid.h: http://packages.debian.org/cgi-bin/search_contents.pl?word=uuid.hsearchmode=searchfilescase=insensitiveversion=unstablearch=i386 We run in naming conflicts with other packages sooner or later. It would be nice if we can have the same name semantic for this two OSSP packages. I would propose: In particular, there is already a libuuid in Debian: libuuid1: /lib/libuuid.so.1 Cheers, Bill
Re: Linux Core Consortium
Bill Allombert wrote: But overriding them means we lose the certification ? We can't allow it to be the case that overriding due to an existing and unremedied security issue causes loss of certification. There's no common sense in that. Thanks Bruce smime.p7s Description: S/MIME Cryptographic Signature
Re: Linux Core Consortium
Manoj Srivastava wrote: So it was inflammatory, then. Comes under spoiling for a fight. Only if you confuse Socrates and Sophism. So, which version of flex you think you want to ship? Fortunately, flex isn't in the problem space. If you stick to what version of libc, etc., it'll make more sense. Are other distributions willing to abide by Debian policy? If so, I may come around to favour us participating even now. Do you know of any other distribution that has taken the trouble to write down as much policy as Debian has? It's not clear that the others have anything to put against it. Thanks Bruce smime.p7s Description: S/MIME Cryptographic Signature
Re: Linux Core Consortium
On Wed, Dec 15, 2004 at 02:36:52PM -0800, Bruce Perens wrote: Bill Allombert wrote: But overriding them means we lose the certification ? We can't allow it to be the case that overriding due to an existing and unremedied security issue causes loss of certification. There's no common sense in that. Then could you elaborate the scope of the certification ? It is one of the main contender for me. I though the certification require to ship the exact same binary as provided by the LCC. Adding support for SE Linux (for example, I am not pushing SE Linux) can imply rebuild some softwares with configure --with-selinux and link them with libselinux.so. They certainly won't be identical to the LLC one. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here.
Re: Linux Core Consortium
Bill Allombert wrote: Then could you elaborate the scope of the certification ? It's still a matter for negotiation. If the certification won't admit to common-sense rules, it won't work for anyone - not just Debian. Thanks Bruce smime.p7s Description: S/MIME Cryptographic Signature
Re: Linux Core Consortium
On Dec 15, Bruce Perens [EMAIL PROTECTED] wrote: Do you know of any other distribution that has taken the trouble to write down as much policy as Debian has? It's not clear that the others have anything to put against it. Bug for bug compatibility required by their customer looks like a good candidate. -- ciao, | Marco | [9830 anG8ZM0oS4rOo] signature.asc Description: Digital signature
Re: Bug#285518: misdn-utils includes a firmware loader
Manoj Srivastava [EMAIL PROTECTED] wrote: Well, if you need the non-free component to be on the file system, why is this different from contrib? Why can't say of everything in contrib that well, if the non-free jvm were to magically appear on the file system this java code would work? Or any other non-free stuff that needs to be on the fs? The requirement for the non-free component exists, even if it isn't on the filesystem. What philosophical benefit is there to distinguishing between non-free code in a chip on a device and non-free code that exists on the filesystem but is executed on that device? How is the cause of free software advanced? How is the experience of our users improved? -- Matthew Garrett | [EMAIL PROTECTED]
Re: Linux Core Consortium
Whoops, I guess that's what I get for trying to be concise for once. I'll try again. Bruce Well, please don't tell this [i. e., outsourcing your core is a bad idea] Bruce to all of the people who we are attempting to get to use Linux Bruce as the core of their products. me core (software architecture) != core (customer value). In other words, Bruce seemed to be conflating the usage of core in a software architecture sense (kernel, toolchain, libraries) with core in a business sense (value proposition to the customer). It's smart for many businesses to adopt the GNU/Linux core precisely because writing operating systems isn't their own core competence and wouldn't make their products better. Bruce Also, please make sure to tell the upstream maintainers that we Bruce aren't going to use their code any longer, because we have decided Bruce that it's a bad idea to outsource the core of our product. me Debian isn't a product, it's a project, [snip Manoj's response, which seems to have been aimed at someone else] me and the core of the project isn't code, it's principles and me processes. Outsourcing the core of Debian would be delegating me judgements about software freeness and integrity. What I was trying to say is that Linux (or any other chunk of upstream code) doesn't represent the core of Debian, so Bruce's argument that we've already outsourced our core doesn't hold water. Our core is the DFSG and the Social Contract, plus the processes we have in place to deliver on the promises they contain. I would argue that any strategy that consecrates particular binaries -- even those built by Debian maintainers -- flies in the face of those principles and processes. Even a commitment to sync up at the source code level constitutes a delegation of judgments about how to maintain software integrity, and it risks a delegation of judgments about freeness (think firmware BLOBs, or the XFree86 license changes). That's the part of what the LCC proposes which I think would constitute outsourcing Debian's core. Is there a paper tiger lurking in there somewhere? Cheers, - Michael
Re: Bug#285518: misdn-utils includes a firmware loader
On Wed, Dec 15, 2004 at 11:33:30PM +, Matthew Garrett wrote: Manoj Srivastava [EMAIL PROTECTED] wrote: Well, if you need the non-free component to be on the file system, why is this different from contrib? Why can't say of everything in contrib that well, if the non-free jvm were to magically appear on the file system this java code would work? Or any other non-free stuff that needs to be on the fs? The requirement for the non-free component exists, even if it isn't on the filesystem. What philosophical benefit is there to distinguishing between non-free code in a chip on a device and non-free code that exists on the filesystem but is executed on that device? How is the cause of free software advanced? How is the experience of our users improved? Look Matthew, you're an intelligent fellow, but you really don't seem to get the whole firmware argument. If we refuse to handle non-free firmware being loaded onto devices and require they come with it already inside then we get to play the I can't see it, it doesn't matter game, which gives the purists a warm fuzzy feeling, knowing no dirty non-free 0s and 1s live on their hard disc. This improves the experience for our users - they get to have the warm fuzzy feeling too, knowing that in sacrificing the ability to use many modern toys and gadgets they are purer of mind and body. Even better is the fact that they doubley can't use the hardware because we're too busy arguing about the firmware to make a release! To be sure, to be sure -- no bread's a lot betther than half a loaf. J. -- 101 things you can't have too much of : 44 - Fame.
removing in postrm rc*.d symlinks that I did not create
Hi folks, A package of mine installs an init script. But as the corresponding programs plays with the motherboard's chipset configuration, it is quite prone to break the system. So I chose not to install rc*.d symlinks by default. To make life easier for users, i explain in a README file how to set up those links and how to remove them with apdate-rc.d. Hence, when a user is convinced this program does not break his system, he can easily set up the links for automatic startup. But a user felt concerned that, in the future, he may remove the package and forget to delete the links. Then I thought I could remove the links in postrm on purge, considering they are part of the package's configuration (their absence being the default configuration). I built the package, but lintian complains: E: athcool: postrm-contains-additional-updaterc.d-calls /etc/init.d/athcool N: N: The postrm de-registers an /etc/init.d script which has not been N: registered in the postinst script before. I lintian right here? Should I ignore this error? Any other suggestion to answer my user's concerns? Thanks in advance for any feedback, Nicolas
Re: Linux Core Consortium
Bruce Fortunately, flex isn't in the problem space. If you stick to what Bruce version of libc, etc., it'll make more sense. Flex isn't in the problem space if we're talking core ABIs. But it certainly is if we're talking core implementations, as binutils and modutils both depend on it. Or is the LCC proposing to standardize on a set of binaries without specifying the toolchain that's used to reproduce them? Bruce Do you know of any other distribution that has taken the trouble to Bruce write down as much policy as Debian has? It's not clear that the others Bruce have anything to put against it. Not having a policy is also a choice. For a variety of reasons, a written policy about legal and technical issues can be a handicap to the sort of calculated risk that many business decisions boil down to. Debian has flamewars about license compatibility and degree of dependency on non-free materials precisely because it has a policy and tries to abide by it. But again, you may not always get what you pay for, but you rarely fail to pay for what you get. If all distros were as sensitive as Debian is to questions of reproducibility from unencumbered source code and build environments, then perhaps we wouldn't be debating the need for golden binaries. Cheers, - Michael
Dummy packages review for the Release Notes and possible mass bug filing
[ Rob Bradford, you're in CC: since I don't know if you read d-d and just in case you miss this :-) ] I've been reviewing for the Release Notes the packages in sid that are provided for upgrade purposes only (since we did in the past for woody's [1]). The goal is to provide a list in the Release Notes that can tell users which packages in woody have been renamed or moved in sarge and can be safely removed after an upgrade. After writting a small script (which needs much improvement [2]), I've found 89 packages [3], manually reviewing for other common descriptions for upgrade packages (I initially used 'dummy', but that was insufficient) I've found 29 additional packages that fit in the list. Still, I'm sure I have missed some packages. I have not included in the list dummy packages that were not previously present in woody (for obvious reasons) but I estimate there are around 130 of those in the archive. The list is attached, so that fellow maintainers can review it and also to spark some discussion. It also includes some notes if the package has been slitted or if the _dummy_ package was present in woody already. Now, for the discussion. I believe there is material for a mass-filing here: 1.- I've found that 34 transitional packages were already present (as dummy packages, not real packages) in woody. Does it make sense to provide them in sarge/sid? Shouldn't they be removed? Should I file a bug against all of them asking their removal? 2.- Lot of packages call themselves 'dummy' packages when they are not used for upgrades, maybe they are meta-packages that retrieve a set of packages (like mozilla, or they pull in a given version, a lot of python packages do this). This makes it cumbersome to retrieve a correct list and you have to manually review it to remove false positives. Could we standarise in a tag to use for transitional packages in descriptions? That would help in finding these packages easily. I'm not worried about scripts like the one I wrote (since we don't write Release Notes every week), however, it is not currently possible for for package managers to hide these packages from view (I believe aptitude tries to do this, I have not checked it's implementation though) Should I file a wishlist bug against policy? Against all the packages that don't use the common naming method (use 'dummy package' in the short description)? 3.- There are 130 packages which label themselves 'dummy to help out upgrades' but were not previously present in woody. Does sarge need to release with all the other dummy packages? Should we set a time limit for those (I don't see the point of having dummy packages for upgrades a year after being available) and ask for the removal of those that are too old to be useful? Finally, I would like to ask maintainers of splitted/renamed packages to provide additional information to the Release Notes manager so that he can write an Appendix (like he did for woody RN's [4]) useful for users upgrading. Also, I believe Rob would appreciate more help with the Release Notes so that they can cover upgrade paths better, if you have experience here, please share it! Thanks Javier PS: Rob, notice this is based on 'sid' information, please remove packages in the list that are not in sarge [1] http://lists.debian.org/debian-doc/2002/04/msg00351.html [2] Actually, the script returned 111 but I manually reviewed all of them. [3] I've added it to the RN's CVS. [4] http://www.debian.org/releases/woody/i386/release-notes/ch-appendix.en.html Dummy packages present in sid - [ PACKAGES: With standard 'dummy' description ] acs - gnucap [NOTE: This dummy package was present in the previous release, REMOVE?] amd - am-utils [NOTE: This dummy package was present in the previous release, REMOVE?] atm-dev - libatm1-dev bonobo-activation - libbonobo2-common (= 2.4.0) colorize - ccze dvb-dev - libc6-dev | libc-dev [NOTE: This dummy package was present in the previous release, REMOVE?] dx-dev - libdx4-dev (= 1:4.3.0-2) freeciv - freeciv-client, freeciv-server [NOTE: Splitted] freeciv-gtk - freeciv-client-gtk freeciv-xaw3d - freeciv-client-xaw3d freetype2 - libttf2 gimp1.2 - gimp (= 1.2.5-1) htmlgen - python-htmlgen ircd - ircd-ircu (= 2.10.11.04-2) kernel-patch-preempt-2.4 - kernel-patch-2.4-preempt lib-dom-java - kaffe | java1-runtime [NOTE: This dummy package was present in the previous release, REMOVE?] libbonobo-activation-dev - libbonobo2-dev (= 2.4.0) [NOTE: This dummy package was present in the previous release, REMOVE?] libbonobo-activation4 - libbonobo2-0 (= 2.4.0) libpaperg - libpaper1 (= 1.1.14-3), libpaper-utils (= 1.1.14-3) libpng3 - libpng12-0 (= 1.2.5.0-2) lilypond1.3 - lilypond (= 1.8.1-1) [NOTE: This dummy package was present in the previous release, REMOVE?] mdctl - debconf ( 0.5), mdadm [NOTE: This dummy package was present in the
Re: Bug#285768: dselect survey
On Wed, Dec 15, 2004 at 04:02:03PM -0500, Daniel Burrows wrote: On Wednesday 15 December 2004 03:37 pm, Wouter Verhelst wrote: ? It seems like Unknown would just be a synonym for No, right? Uh, yes. I think. You may want to explain that a bit more. Well, from the bug report, it looks like the proposal is to maintain the current behavior, but to set a different flag on packages that were conservatively assumed to be manually installed, so they can be switched later to automatic handling if desired. Sounds useful. Well, in that case, not entirely. You may also want to set a flag on packages that are assumed to be automatically installed, but of which you have no information. Consider libgnome2-perl: people may want to install that, even if there is no dependency, to allow for debconf to provide a gnome frontend; however, I can imagine there are also packages that have a dependency on libgnome2-perl. Now consider a user who recently switched to aptitude after having used a different frontend for a long while; this user had installed libgnome2-perl manually (for the debconf frontend), but later on installed just one package depending on libgnome2-perl to see what it does. At that time, the switch to aptitude was made; but then the user decided that the package using libgnome2-perl isn't useful enough, and removes it again. What debfoster will do in that case, is present the user with libgnome2-perl (and all packages whom only libgnome2-perl depends on and for which no preference is yet known), and ask whether they should be removed. I really think this is the right thing to do in such a situation. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune
Re: removing in postrm rc*.d symlinks that I did not create
Nicolas Boullis [EMAIL PROTECTED] writes: A package of mine installs an init script. But as the corresponding programs plays with the motherboard's chipset configuration, it is quite prone to break the system. So I chose not to install rc*.d symlinks by default. A technique that I've used in packages with this issue is to install the rc*.d symlinks by default, but also have the init script check a file in /etc/default to see whether or not to actually start at boot. If you install a default /etc/default file that says not to start, you accomplish the same thing, don't have this problem, and make it just as easy for users to enable the package. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: Linux Core Consortium
Michael K. Edwards wrote: binutils and modutils both depend on it. On flex? No. At least not in unstable. However, Debian seems to have addressed the issue by providing both versions of flex. I don't see what would prevent us from going on with that practice. Or is the LCC proposing to standardize on a set of binaries without specifying the toolchain that's used to reproduce them? Linking and calling conventions should be standardized and should survive for reasonably long. We need to know what we use to build the packages, but we are not currently proposing to standardize development tools on the target system. Not having a policy is also a choice. For a variety of reasons, a written policy about legal and technical issues can be a handicap to the sort of calculated risk that many business decisions boil down to. The sort of calculated risk that many business decisions boil down to is too vague to have meaning. What you may be groping at is that some publicized policy can be taken as a promise. The organizations participating in LCC have chosen to make such promises. Thanks Bruce
Re: Bug#285768: dselect survey
On Wednesday 15 December 2004 07:51 pm, Wouter Verhelst wrote: You may also want to set a flag on packages that are assumed to be automatically installed, but of which you have no information. aptitude never should assume that a package is automatically installed, unless it performs the automatic installation itself. I don't think any other option is really safe. (I *think* you're not talking about current behavior, but I thought I saw someone bring this up in the -devel thread that spawned this bug, and you just reminded me of it) Consider libgnome2-perl: people may want to install that, even if there is no dependency, to allow for debconf to provide a gnome frontend; however, I can imagine there are also packages that have a dependency on libgnome2-perl. Now consider a user who recently switched to aptitude after having used a different frontend for a long while; this user had installed libgnome2-perl manually (for the debconf frontend), but later on installed just one package depending on libgnome2-perl to see what it does. At that time, the switch to aptitude was made; but then the user decided that the package using libgnome2-perl isn't useful enough, and removes it again. What debfoster will do in that case, is present the user with libgnome2-perl (and all packages whom only libgnome2-perl depends on and for which no preference is yet known), and ask whether they should be removed. It sounds to me like what you're proposing is something like: - If I see a new package installed by someone else, * if nothing depends on it, mark it Unknown; probably manually installed * otherwise, mark it Unknown; probably automatically installed Then you'd have two more classes of packages, in addition to manual and automatic: Unknown; probably manually installed: I don't see doing anything especially fancy here, but there should be a way to show all of them on demand. Unknown; probably automatically installed: If one of these packages is only [transitively] depended upon by some other packages in the same class, tell the user that they all are possibly unused. (for instance, in the preview screen) One problem is that the set of packages that are possibly unused isn't disjoint to the other sets of packages that aptitude displays, which could perhaps lead to some awkward situations. (what if a package is both upgradable and possibly unused? Which category is it listed in, or is it listed in both?) Daniel -- /--- Daniel Burrows [EMAIL PROTECTED] --\ | Hah, I can just see a real playsmith puttin' a..a DONKEY in a play! | | -- Terry Pratchett, _Lords and Ladies_| \-- (if (not (understand-this)) (go-to http://www.schemers.org)) ---/ pgpzJ1fg1NoVu.pgp Description: PGP signature
Re: removing in postrm rc*.d symlinks that I did not create
Hi, On Wed, Dec 15, 2004 at 04:33:49PM -0800, Russ Allbery wrote: A technique that I've used in packages with this issue is to install the rc*.d symlinks by default, but also have the init script check a file in /etc/default to see whether or not to actually start at boot. If you install a default /etc/default file that says not to start, you accomplish the same thing, don't have this problem, and make it just as easy for users to enable the package. Thanks for your suggestion. I already thought about it, but I fnind it quite confusing when I cannot run /etc/init.d/foobar by hand as soon as it is not enabled on startup. Cheers, Nicolas
Re: Re: LCC and blobs
Goswin von Brederlow writes: Because the former works after installing the deb without the user ever doing anything about firmware. How do you even know there is firmware? Maybe it is all hardcoded into the chip? Without taking the hardware apart you can't know. Call me ignorant but what I don't see does not exist describes perfectly how it should be treated. In the later case the user actively has to download the firmware from somewhere and add it to his system. The extra files taints his filesystems and makes it less free. For example you can't just make a live CD out of it anymore because the non-free firmware file makes it not DFSG free. Not free in what sense? What can the user not do, that he can do if the firmware was already on the device?
Re: removing in postrm rc*.d symlinks that I did not create
Nicolas writes: I already thought about it, but I fnind it quite confusing when I cannot run /etc/init.d/foobar by hand as soon as it is not enabled on startup. Your script should check $PRERUNLEVEL. It will be N if you are booting. -- John Hasler
Re: removing in postrm rc*.d symlinks that I did not create
I wrote:
Your script should check $PRERUNLEVEL. It will be N if you are booting.
That should be $PREVLEVEL.
--
John Hasler
Re: Linux Core Consortium
On Wed, Dec 15, 2004 at 05:00:11PM -0800, Bruce Perens wrote: Michael K. Edwards wrote: binutils and modutils both depend on it. On flex? No. At least not in unstable. Yes, it does. $ apt-cache showsrc binutils Package: binutils Binary: binutils-hppa64, binutils, binutils-doc, binutils-dev, binutils-multiarch Version: 2.15-5 Priority: standard Section: devel Maintainer: James Troup [EMAIL PROTECTED] Build-Depends: autoconf (= 2.13), bison, flex, gettext, texinfo, binutils (= 2.9.5.0.12), gcc (= 2.95.2-1), dejagnu (= 1.4.2-1.1), expect (= 5.32.2-1), dpatch, file Architecture: any Standards-Version: 3.6.1.0 Format: 1.0 Directory: pool/main/b/binutils Files: b20cf60b07384592ed5fa71314c6d2d9 1401 binutils_2.15-5.dsc ea140e23ae50a61a79902aa67da5214e 15134701 binutils_2.15.orig.tar.gz 055e74792e7118ddf33ae6b04d640818 38173 binutils_2.15-5.diff.gz $ However, Debian seems to have addressed the issue by providing both versions of flex. I don't see what would prevent us from going on with that practice. Or is the LCC proposing to standardize on a set of binaries without specifying the toolchain that's used to reproduce them? Linking and calling conventions should be standardized and should survive for reasonably long. We need to know what we use to build the packages, but we are not currently proposing to standardize development tools on the target system. Not standardizing the toolchain used to build a set of standardized binaries would seem to leave the LCC open to a repeat of the gcc-2.96 fiasco, however... -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: removing in postrm rc*.d symlinks that I did not create
On Thu, Dec 16, 2004 at 12:34:21AM +0100, Nicolas Boullis wrote: But a user felt concerned that, in the future, he may remove the package and forget to delete the links. Then I thought I could remove the links in postrm on purge, considering they are part of the package's configuration (their absence being the default configuration). if the package is removed, the init script should just exit with 0 status. removing the links during purge would also be appropriate. you could also install the links by default, but have some other variable in /etc/default/$package control whether or not it actually starts (i think somebody else has mentioned this too). sean -- signature.asc Description: Digital signature
Re: Linux Core Consortium
Steve Langasek wrote: On flex? No. At least not in unstable. Yes, it does. Oh, you mean build-depends. Not standardizing the toolchain used to build a set of standardized binaries would seem to leave the LCC open to a repeat of the gcc-2.96 fiasco, however... The GCC fiasco was due to a change in calling conventions. I said we'd standardize that. Thanks Bruce smime.p7s Description: S/MIME Cryptographic Signature
Accepted dnprogs 2.28 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 15 Dec 2004 10:50:44 + Source: dnprogs Binary: libdnet libdnet-dev dnet-common dnet-progs Architecture: source i386 all Version: 2.28 Distribution: unstable Urgency: low Maintainer: Patrick Caulfield [EMAIL PROTECTED] Changed-By: Patrick Caulfield [EMAIL PROTECTED] Description: dnet-common - Base package for Linux DECnet dnet-progs - DECnet user programs and daemons libdnet- DECnet Libraries libdnet-dev - DECnet development libraries Headers Changes: dnprogs (2.28) unstable; urgency=low . * Makefile fixups from Maciej W. Rozycki * FAL now accepts VMS directories with ][ in them, eg those produced by concatenated logicals. Files: de846828f0fd8338ac325d5b64b47375 549 net extra dnprogs_2.28.dsc 4114a35db143119a9b3795b2c66d7246 402760 net extra dnprogs_2.28.tar.gz 60953672afbb8bb559179d1c22d4aad0 29072 net extra dnet-common_2.28_all.deb 4f05b81a71f453ffb3597bf9afc49262 181722 net extra dnet-progs_2.28_i386.deb c4a5558d41283c28066ccd445534be87 73976 libs extra libdnet_2.28_i386.deb 4d436db8f8e3e4643bf839cbb901071f 97494 libdevel extra libdnet-dev_2.28_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBwBe2hej7/PCycRMRAlAMAJ0SuHcAUc9VxsnLw3I7vgWF6CadXwCfZOuh 4PYPEsNWLcQziVRt3A6b4dw= =yViY -END PGP SIGNATURE- Accepted: dnet-common_2.28_all.deb to pool/main/d/dnprogs/dnet-common_2.28_all.deb dnet-progs_2.28_i386.deb to pool/main/d/dnprogs/dnet-progs_2.28_i386.deb dnprogs_2.28.dsc to pool/main/d/dnprogs/dnprogs_2.28.dsc dnprogs_2.28.tar.gz to pool/main/d/dnprogs/dnprogs_2.28.tar.gz libdnet-dev_2.28_i386.deb to pool/main/d/dnprogs/libdnet-dev_2.28_i386.deb libdnet_2.28_i386.deb to pool/main/d/dnprogs/libdnet_2.28_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted cupsys 1.1.22-1 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 15 Dec 2004 18:58:55 +0900 Source: cupsys Binary: cupsys-bsd libcupsys2-dev libcupsys2 cupsys libcupsys2-gnutls10 libcupsimage2-dev libcupsimage2 cupsys-client Architecture: source i386 all Version: 1.1.22-1 Distribution: unstable Urgency: low Maintainer: Kenshi Muto [EMAIL PROTECTED] Changed-By: Kenshi Muto [EMAIL PROTECTED] Description: cupsys - Common UNIX Printing System(tm) - server cupsys-bsd - Common UNIX Printing System(tm) - BSD commands cupsys-client - Common UNIX Printing System(tm) - client programs (SysV) libcupsimage2 - Common UNIX Printing System(tm) - image libs libcupsimage2-dev - Common UNIX Printing System(tm) - image development files libcupsys2 - Common UNIX Printing System(tm) - dummy libs for transition libcupsys2-dev - Common UNIX Printing System(tm) - development files libcupsys2-gnutls10 - Common UNIX Printing System(tm) - libs Closes: 283500 284733 284829 285205 285601 Changes: cupsys (1.1.22-1) unstable; urgency=low . * New upstream release for unstable. Time is over, sarge isn't shipped. I checked 1.1.21 to 1.1.22 migration doesn't break ABI quickly, but I'm still scared... * Apply gcc-4.0 patch for amd64: 37gfxfont.patch (closes: #285601) * Do 'restart' instead of 'reload' when log is rotated. 'reload' sometime causes just shutdown daemon. (Unknown problem) * Fix equation in cupsys.postscript. (closes: #285205) * Apply Russell's patch: 38httpwait.patch (closes: #284829) (This is trial. If there is any grave problem by this, I'll off this patch) - Made http_wait() handle EINTR. This bug was causing cups to print multiple copies of reports on remote printers. - Lengthed the wait in ipp_http_read to handle connections running over the internet. The short wait was causing unwated multiple copies of reports to be printed. - While both these bugs need to be fixed, neither completely solves the original multiple copies problem. To solve that no data should be printed if there was a read error. * Add dependency version of smbclient. (closes: #284733) * Fix SIGSEGV when remote destination goes timeout: 39remotetimeout.patch (closes: #283500) Files: d8a97b3c6ae2895e5e69b1819f38736f 816 net optional cupsys_1.1.22-1.dsc 2a818c7f6e44b977493efbfbfa865d86 9837277 net optional cupsys_1.1.22.orig.tar.gz 6f225095d29d0364a3836bccdedfa0f6 1266901 net optional cupsys_1.1.22-1.diff.gz 940bb8736714f4415289302e3667a719 966 libs optional libcupsys2_1.1.22-1_all.deb 2b374c2c52fc9f5ee9492548d44414ff 8960866 net optional cupsys_1.1.22-1_i386.deb 92b3c420acfa6920bdd34cca9cf9ea98 90924 net optional cupsys-client_1.1.22-1_i386.deb f35b11ce7615bcadf85a5acf9f3c5c18 73448 libs optional libcupsys2-gnutls10_1.1.22-1_i386.deb c5ef5d39732cea6485801ff13590f8a9 83854 libdevel optional libcupsys2-dev_1.1.22-1_i386.deb 7ee6e06d1e3f7f63de72634221b63813 35502 libs optional libcupsimage2_1.1.22-1_i386.deb 40a480271a961cb8437ecce7b313321b 45914 libdevel optional libcupsimage2-dev_1.1.22-1_i386.deb b7910e41c1d781d31a0bcbd34071c6d4 40930 net extra cupsys-bsd_1.1.22-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iEYEARECAAYFAkHAJkcACgkQQKW+7XLQPLH2PACg4LIJfxqcTDo78u2qFYJIh0x6 fxMAoMX/TBKB187aswDRfbn6Ixp2uDyK =jjRI -END PGP SIGNATURE- Accepted: cupsys-bsd_1.1.22-1_i386.deb to pool/main/c/cupsys/cupsys-bsd_1.1.22-1_i386.deb cupsys-client_1.1.22-1_i386.deb to pool/main/c/cupsys/cupsys-client_1.1.22-1_i386.deb cupsys_1.1.22-1.diff.gz to pool/main/c/cupsys/cupsys_1.1.22-1.diff.gz cupsys_1.1.22-1.dsc to pool/main/c/cupsys/cupsys_1.1.22-1.dsc cupsys_1.1.22-1_i386.deb to pool/main/c/cupsys/cupsys_1.1.22-1_i386.deb libcupsimage2-dev_1.1.22-1_i386.deb to pool/main/c/cupsys/libcupsimage2-dev_1.1.22-1_i386.deb libcupsimage2_1.1.22-1_i386.deb to pool/main/c/cupsys/libcupsimage2_1.1.22-1_i386.deb libcupsys2-dev_1.1.22-1_i386.deb to pool/main/c/cupsys/libcupsys2-dev_1.1.22-1_i386.deb libcupsys2-gnutls10_1.1.22-1_i386.deb to pool/main/c/cupsys/libcupsys2-gnutls10_1.1.22-1_i386.deb libcupsys2_1.1.22-1_all.deb to pool/main/c/cupsys/libcupsys2_1.1.22-1_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted rmatrix 0.8.19-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 15 Dec 2004 07:13:56 -0600 Source: rmatrix Binary: r-cran-matrix Architecture: source i386 Version: 0.8.19-1 Distribution: unstable Urgency: low Maintainer: [EMAIL PROTECTED] Changed-By: Douglas Bates [EMAIL PROTECTED] Description: r-cran-matrix - GNU R package of classes for dense and sparse matrices Changes: rmatrix (0.8.19-1) unstable; urgency=low . * New upstream release Files: fef6471539146e5eec48193df84ea7bb 619 math optional rmatrix_0.8.19-1.dsc 3b7a6ac59ac9ea0a2f46b25a2ba8955d 503813 math optional rmatrix_0.8.19.orig.tar.gz 8714aa9f4e7976bf5dee28d32e7fbb13 2340 math optional rmatrix_0.8.19-1.diff.gz 2da5829471d5c0afe45b78e526e836f4 555600 math optional r-cran-matrix_0.8.19-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBwDrPhKhE9v5h4HkRAllCAKCwssOxq8yo9+MYczWQ+FQs+ErIrgCgoA6S ZXxzff0hhzAHNWPZiwJsYj4= =txG0 -END PGP SIGNATURE- Accepted: r-cran-matrix_0.8.19-1_i386.deb to pool/main/r/rmatrix/r-cran-matrix_0.8.19-1_i386.deb rmatrix_0.8.19-1.diff.gz to pool/main/r/rmatrix/rmatrix_0.8.19-1.diff.gz rmatrix_0.8.19-1.dsc to pool/main/r/rmatrix/rmatrix_0.8.19-1.dsc rmatrix_0.8.19.orig.tar.gz to pool/main/r/rmatrix/rmatrix_0.8.19.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted f-spot 0.0.3-2 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 15 Dec 2004 11:45:53 +0100 Source: f-spot Binary: f-spot Architecture: source i386 Version: 0.0.3-2 Distribution: unstable Urgency: low Maintainer: Ondřej Surý [EMAIL PROTECTED] Changed-By: Ondřej Surý [EMAIL PROTECTED] Description: f-spot - personal photo management application Closes: 283469 Changes: f-spot (0.0.3-2) unstable; urgency=low . * Update f-spot.exe.config to include mapping for internal libraries (Closes: #283469) Files: ba21cb61d166a636999a2fe3fe82c676 1515 gnome optional f-spot_0.0.3-2.dsc 5d130b7bb3ba88ad52d919770815ca62 2154 gnome optional f-spot_0.0.3-2.diff.gz d42c448c62a474f3824eba7793f5989c 269428 gnome optional f-spot_0.0.3-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBwDnB9OZqfMIN8nMRAvtYAJ9RtvHpahX9Ls9HZh2T7El9DomofgCeK4DY bPobxrNv2b8vp+d1zU4tor4= =Tqgb -END PGP SIGNATURE- Accepted: f-spot_0.0.3-2.diff.gz to pool/main/f/f-spot/f-spot_0.0.3-2.diff.gz f-spot_0.0.3-2.dsc to pool/main/f/f-spot/f-spot_0.0.3-2.dsc f-spot_0.0.3-2_i386.deb to pool/main/f/f-spot/f-spot_0.0.3-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gcc-3.4 3.4.3-5 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 15 Dec 2004 09:54:45 + Source: gcc-3.4 Binary: g77-3.4-doc gcc-3.4-base libstdc++6 lib64gcj5-awt gnat-3.4 libobjc1 libgcj5 libgcc1 gcc-3.4 lib64g2c0 gobjc-3.4 libstdc++6-0 gcc-3.4-nof libgcc2 libstdc++6-dev libstdc++6-doc protoize libgnat-3.4 libgcj5-dev libstdc++6-0-pic libgcj5-common lib64stdc++6 libstdc++6-dbg lib32stdc++6-0 gij-3.4 lib32gcc1 lib64gnat-3.4 lib64objc1 cpp-3.4 lib64gcj5 gcc-3.4-hppa64 gcc-3.4-soft-float libstdc++6-0-dev libgcj5-awt cpp-3.4-doc libgcj-common libffi3-dev gcc-3.4-doc libg2c0-dev gpc-2.1-3.4-doc lib64gcc1 fastjar treelang-3.4 libffi3 fixincludes libg2c0 lib32stdc++6 libstdc++6-pic lib64ffi3 gnat-3.4-doc libstdc++6-0-dbg gcj-3.4 gpc-2.1-3.4 g++-3.4 g77-3.4 Architecture: source i386 all Version: 3.4.3-5 Distribution: unstable Urgency: low Maintainer: Debian GCC maintainers [EMAIL PROTECTED] Changed-By: Matthias Klose [EMAIL PROTECTED] Description: cpp-3.4- The GNU C preprocessor cpp-3.4-doc - Documentation for the GNU C preprocessor (cpp) fastjar- Jar creation utility g++-3.4- The GNU C++ compiler g77-3.4- The GNU Fortran 77 compiler g77-3.4-doc - Documentation for the GNU Fortran compiler (g77) gcc-3.4- The GNU C compiler gcc-3.4-base - The GNU Compiler Collection (base package) gcc-3.4-doc - Documentation for the GNU compilers (gcc, gobjc, g++) gcj-3.4- The GNU compiler for Java(TM) gij-3.4- The GNU Java bytecode interpreter gnat-3.4 - The GNU Ada compiler gnat-3.4-doc - Documentation for the GNU Ada compiler (gnat) gobjc-3.4 - The GNU Objective-C compiler gpc-2.1-3.4 - The GNU Pascal compiler gpc-2.1-3.4-doc - Documentation for the GNU Pascal compiler (gpc) lib64gcc1 - GCC support library (64bit) lib64stdc++6 - The GNU Standard C++ Library v3 (64bit) libffi3- Foreign Function Interface library runtime libffi3-dev - Foreign Function Interface library (development files) libgcc1- GCC support library libgcj5- Java runtime library for use with gcj libgcj5-awt - AWT peer runtime libraries for use with gcj libgcj5-common - Java runtime library for use with gcj (jar files) libgcj5-dev - Java development headers and static library for use with gcj libgnat-3.4 - Runtime library for GNU Ada applications libstdc++6 - The GNU Standard C++ Library v3 libstdc++6-dbg - The GNU Standard C++ Library v3 (debugging files) libstdc++6-dev - The GNU Standard C++ Library v3 (development files) libstdc++6-doc - The GNU Standard C++ Library v3 (documentation files) libstdc++6-pic - The GNU Standard C++ Library v3 (shared library subset kit) treelang-3.4 - The GNU Treelang compiler Changes: gcc-3.4 (3.4.3-5) unstable; urgency=low . * Updated to gcc-3.4 CVS 20041215. Files: f84d1c546b50d9224a84845bafdc216e 2830 devel optional gcc-3.4_3.4.3-5.dsc ec8933c042de3d15dfe7248a9188f8de 4794673 devel optional gcc-3.4_3.4.3-5.diff.gz 701d3efd2969d2cd1884cdb5b4aad2eb 181572 doc optional cpp-3.4-doc_3.4.3-5_all.deb 740399bd09a187fd9ef6b82f4b74c840 2028776 libs optional libgcj5-common_3.4.3-5_all.deb 8b061a6bb541a54824e4e338aeb23c41 4248456 doc optional libstdc++6-doc_3.4.3-5_all.deb 5e0484b0ac8467c2ac50664f355206bd 628870 doc optional g77-3.4-doc_3.4.3-5_all.deb 42400b2e1cb9fd12c122b05d16e65521 896342 doc optional gnat-3.4-doc_3.4.3-5_all.deb 3bfd2696dd57e3d9076e273b3733fa13 468716 doc optional gpc-2.1-3.4-doc_3.4.3-5_all.deb d7e81d860513c0de90099a8c8915b240 1474806 doc optional gcc-3.4-doc_3.4.3-5_all.deb 20c22b66e384eff4fc27a8b095f8ef10 158288 devel optional gcc-3.4-base_3.4.3-5_i386.deb a966d3122695bb638dcc5920b3de3d9f 79440 libs required libgcc1_3.4.3-5_i386.deb 1bdb0959de149152f44b0b1bd88cb0ae 83444 libs optional lib64gcc1_3.4.3-5_i386.deb 30426555afc4328987d309e36e62e95f 1704274 interpreters optional cpp-3.4_3.4.3-5_i386.deb cef9e22787dd739b00e7665a13569411 1742780 devel optional gobjc-3.4_3.4.3-5_i386.deb af6950f4be6f26d8fc5e35cd7e71a921 13268 devel optional gij-3.4_3.4.3-5_i386.deb 4500a6734763dfa4cee267ea2499a3ba 3665556 libs optional libgcj5_3.4.3-5_i386.deb b46414cc16c1762076f41980292fdcc7 186522 libs optional libgcj5-awt_3.4.3-5_i386.deb 1a1b6e745a40571cfdf3cc9dbeb02039 2042256 devel optional gcj-3.4_3.4.3-5_i386.deb 5cdb9bd6dbb1a63642d26336b4d2f16a 6859480 libdevel optional libgcj5-dev_3.4.3-5_i386.deb 34a36769a218e4823b77a688f52d03c6 118072 devel optional fastjar_3.4.3-5_i386.deb d3e09d1abe67ec5dbe327f548b1169f3 78622 libs optional libffi3_3.4.3-5_i386.deb fb7be37b225fb8be3b125db78e8bcdd1 8858 libdevel optional libffi3-dev_3.4.3-5_i386.deb 1dce5b8db4d47a9034b12c53f0b9b18e 1939502 devel optional g++-3.4_3.4.3-5_i386.deb 3058ca59d7266f37e537ef229438d3ba 324664 libs optional lib64stdc++6_3.4.3-5_i386.deb fa8d8ed48d7cfeb5be379e67563b5969 319926 libs optional libstdc++6_3.4.3-5_i386.deb b7f51b7f572f4d53d8b351f2534a2fbf 1300968 libdevel optional libstdc++6-dev_3.4.3-5_i386.deb
Accepted lme4 0.6.10-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 15 Dec 2004 08:07:34 -0600 Source: lme4 Binary: r-cran-lme4 Architecture: source i386 Version: 0.6.10-1 Distribution: unstable Urgency: low Maintainer: [EMAIL PROTECTED] Changed-By: Douglas Bates [EMAIL PROTECTED] Description: r-cran-lme4 - GNU R package for linear mixed effects model fitting. Changes: lme4 (0.6.10-1) unstable; urgency=low . * New upstream release * debian/control: Changed from r-cran-lattice to r-cran-latticeextra in Build-Depends: * debian/control: Updated version of r-cran-matrix in Build-Depends: Files: a61b29c02f8a6279415f81d9385c5ee2 641 math optional lme4_0.6.10-1.dsc c86c96948a05cbb8d3faeecf78cb3da2 1068267 math optional lme4_0.6.10.orig.tar.gz 88a0cf96d783e57aade55f02f20496c8 2296 math optional lme4_0.6.10-1.diff.gz 693b32479b9045d0a4c3b3b3746971ae 1279084 math optional r-cran-lme4_0.6.10-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBwEZEhKhE9v5h4HkRAmkgAJ0QBPQS8tCwl40zFtUG//mqD37SbACg3R2w MwdK+1Dtrqhn5gVArs3MV6Y= =HlCi -END PGP SIGNATURE- Accepted: lme4_0.6.10-1.diff.gz to pool/main/l/lme4/lme4_0.6.10-1.diff.gz lme4_0.6.10-1.dsc to pool/main/l/lme4/lme4_0.6.10-1.dsc lme4_0.6.10.orig.tar.gz to pool/main/l/lme4/lme4_0.6.10.orig.tar.gz r-cran-lme4_0.6.10-1_i386.deb to pool/main/l/lme4/r-cran-lme4_0.6.10-1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted greylistd 0.6.3 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 15 Dec 2004 00:41:37 -0800 Source: greylistd Binary: greylistd Architecture: source all Version: 0.6.3 Distribution: unstable Urgency: low Maintainer: Tor Slettnes [EMAIL PROTECTED] Changed-By: Tor Slettnes [EMAIL PROTECTED] Description: greylistd - Greylisting daemon for use with Exim 4 Closes: 267225 268059 285346 Changes: greylistd (0.6.3) unstable; urgency=low . * Fixed problem with statistics counter; would overcount the number of items that entered each list (white, grey). * Fixed unlimited growth of items in 'newTriplets' list in the case where these were not periodically flushed to file (i.e. when 'savetriplets = false') * Changed package description to reflect some more detail of how greylistd interacts with MTA. Closes: #285346. * Removed path names from the command synopsis line in the greylist(1) and greylistd(8) manual pages. Closes: #267225. * Format list output to include date of last hit and number of hits for each data set. Closes: #268059. * Greylist data is saved to temporary file, then renamed. This prevents a race condition where all data can be lost in case of a power failure or a full filesystem. Closes #285343. (Data is saved periodically as of version 0.6). * Restructured runCommand() routine - it no longer walks through a large if ... elif ... elif ... else block, but tries to invoke a do_command function according to the command specified. * Arguments to actions must now be prefixed with (any number of) hyphens. For instance, greylist add --white, not greylist add white. * Added --white, --grey, and --black options to the check and update commands; if specified, greylistd returns a boolean value rather than a list name. So greylist --grey data would show whether data is currently in a grey state. Files: 586e58b2046fb9c3425c32a047e411d5 491 mail optional greylistd_0.6.3.dsc b0386a5ae056029254214e0269b1c0c8 32519 mail optional greylistd_0.6.3.tar.gz 16c0b19cd1e0586c04b30048afef20e0 35418 mail optional greylistd_0.6.3_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBwEZ0nt4KtwvubPwRAsghAJ42GJtVEcoTz3SbwZ3TcqTVqbPbpQCeKq8c oSQTOpAhPD1O/dWS8L3oCCA= =M3Xk -END PGP SIGNATURE- Accepted: greylistd_0.6.3.dsc to pool/main/g/greylistd/greylistd_0.6.3.dsc greylistd_0.6.3.tar.gz to pool/main/g/greylistd/greylistd_0.6.3.tar.gz greylistd_0.6.3_all.deb to pool/main/g/greylistd/greylistd_0.6.3_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted drbd 0.7.7-1 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 15 Dec 2004 17:15:35 +0300 Source: drbd Binary: drbd0.7-module-source drbd0.7-utils Architecture: source i386 all Version: 0.7.7-1 Distribution: unstable Urgency: low Maintainer: David Krovich [EMAIL PROTECTED] Changed-By: Cyril Bouthors [EMAIL PROTECTED] Description: drbd0.7-module-source - RAID 1 over tcp/ip for Linux module source drbd0.7-utils - RAID 1 over tcp/ip for Linux utilities Changes: drbd (0.7.7-1) unstable; urgency=low . * (Cyril Bouthors) - New upstream release Files: 61ab7ac993d4ecd2c197149c601964ab 641 admin extra drbd_0.7.7-1.dsc bf8f7731326e926415dc094e399f2d7b 284547 admin extra drbd_0.7.7-1.tar.gz c1ef0932c08c1361c14a5b707dfdf528 80212 admin extra drbd0.7-utils_0.7.7-1_i386.deb d90d797e6270a5f5793d0eeea7ce5cf1 131186 admin extra drbd0.7-module-source_0.7.7-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBwEdbZ1SJHeqsYt8RAozWAJ97Ceg8rdw5KLMKUv9IvUWl5WVwTQCfflxA YTIcBLS0i4XiQQgdEckKOxQ= =JqMT -END PGP SIGNATURE- Accepted: drbd0.7-module-source_0.7.7-1_all.deb to pool/main/d/drbd/drbd0.7-module-source_0.7.7-1_all.deb drbd0.7-utils_0.7.7-1_i386.deb to pool/main/d/drbd/drbd0.7-utils_0.7.7-1_i386.deb drbd_0.7.7-1.dsc to pool/main/d/drbd/drbd_0.7.7-1.dsc drbd_0.7.7-1.tar.gz to pool/main/d/drbd/drbd_0.7.7-1.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted ocaml-doc 3.08.0-1 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 15 Dec 2004 16:15:02 +0100 Source: ocaml-doc Binary: ocaml-doc Architecture: source all Version: 3.08.0-1 Distribution: unstable Urgency: low Maintainer: Remi Vanicat [EMAIL PROTECTED] Changed-By: Remi Vanicat [EMAIL PROTECTED] Description: ocaml-doc - Documentation for Objective Caml and Camlp4 Closes: 267421 285661 Changes: ocaml-doc (3.08.0-1) unstable; urgency=low . * NMU Acknowledgment (thanks to Samuel). * Change the HTML registered index for the example (closes: #267421, #285661). * Added ocaml-team and Samuel Mimram has uploaders of this package (many thanks to him for hiswork). Files: 40afc39b2b8bb87cc5914fd47343f534 633 non-free/doc optional ocaml-doc_3.08.0-1.dsc 4a6dce6726b0091445b0af2f66942afb 3884559 non-free/doc optional ocaml-doc_3.08.0.orig.tar.gz 8b6ea044f5dfaa32f3e91b9831a3831d 4081 non-free/doc optional ocaml-doc_3.08.0-1.diff.gz 37445a64b676db0b19efbb976446c6ac 3919676 non-free/doc optional ocaml-doc_3.08.0-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBwFUpsOGY15BXtdMRAibgAJsFfVb8suR4YeQhvpaM/km4jO+g7wCfQfLa xUbrGHh7amy19+jQvan6XB0= =DJdY -END PGP SIGNATURE- Accepted: ocaml-doc_3.08.0-1.diff.gz to pool/non-free/o/ocaml-doc/ocaml-doc_3.08.0-1.diff.gz ocaml-doc_3.08.0-1.dsc to pool/non-free/o/ocaml-doc/ocaml-doc_3.08.0-1.dsc ocaml-doc_3.08.0-1_all.deb to pool/non-free/o/ocaml-doc/ocaml-doc_3.08.0-1_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
