Debian Project Leader report for 2005-05-08
The second of my reports as Debian Project Leader is now available. You may read it in HTML format at: http://people.debian.org/~branden/dpl/reports/2005-05-08.html ...or in ReStructured Text format[1], below. If you find ReStructured text format difficult to understand, you can use lynx to dump a plain text version of the URL above: $ lynx -dump http://people.debian.org/~branden/dpl/reports/2005-05-08.html [1] http://docutils.sourceforge.net/rst.html Debian Project Leader Report for 2005-05-08 === Overview This report begins with some big news, so let's get right to it... Sarge Release Challenges and Progress - Those who have been living in a cave for the past few days will be pleased to know that `Sarge has frozen`_. Needless to say, our work is far from finished; now, more than ever, we need people testing upgrades from woody and testing fresh installs based on `debian-installer`. The release management team has been kept busy processing last-minute force-it-into-sarge requests, and combatting the onslaught of `release critical bugs`_, which is always a challenge -- today, for example, nine release-critical bugs were closed, but nine were opened as well. While there is much work before us before we can truly celebrate, it's not too soon to let ourselves feel a bit of satisfaction in achieving this milestone. It's been a very long time in coming, and every developer who has worked on our archive, build daemon, and security infrastructures, every developer who has fixed a release-critical bug, every developer who has worked on `debian-installer`, every developer who has provided a translation for a user interface or piece of documentation, and every developer who has contributed to making Debian GNU/Linux better documented, easier to use, and more powerful deserves a share of the credit. I personally feel a bit of renewed vigor and determination towards getting this release out the door, and I hope you do too. With our critical infrastructure in place and humming along, it's just a matter of some hard work to make the Sarge release happen. That doesn't daunt me; we've always been good at hard work. Hardware Infrastructure Issues -- In my `first DPL report`_, I mentioned that Steve McIntyre had helped get us out of the bad situation we were in with respect to ARM build daemons. He helpfully followed up with some more details. These machines, which were purchased from `Simtec Hardware`_, look beefy indeed to those used to NetWinders and PDAs. * `toffee`: 300 MHz StrongARM-110, 256 MB RAM, 40GB IDE HDD * `grieg`: 300 MHz StrongARM-110, 160 MB RAM, 160GB IDE HDD * `cats`: 380 MHz StrongARM-110, 64 MB RAM, 20GB IDE HDD Steve is hosting `toffee` and `grieg`, and Vince Sanders is hosting `cats`. On 29 April, `europa` and `elara`, two malfunctioning ARM machines that were putting the hurt on us in the first place, were restored to working order by Woody Suwalski, the site administrator at Xandros_. On each machine, a new hard drive has been installed, and each is running up-to-date Debian unstable with 2.6.11 kernels. A decision is still pending from DSA on whether to put these machines back into the build daemon network. Even if not, the machines may be useful as general development machines accessible to Debian developers -- presently, there is only one, `debussy` and it is running Debian GNU/Linux 3.0 (woody). Another, `rameau`, is `listed as down and being relocated`_. Wichert Akkerman and the other Debian System Administrators are concerned about the persistent shortages of disk space on `costa` and `klecker`. These are only machines that appear to be in urgent need of upgrades over the next year or so. I'll be working with the system administration team and potential donors to get this situation squared away. Woody Security Update Challenges and Progress - In my `first DPL report`_, I observed that some security updates had been stalled for weeks because the unavailability of build daemons for the ARM architecture. In speaking with people, I've found out why this is, and as you might expect it has to do with manageability issues. If a security upload that is missing one or more arches is approved, that architecture never appears on `security.debian.org`, unless a binary-only NMU is later done for the architecture. That in turn makes point releases more of a headache, with version skew (even if binary-only) among the architectures. Debian Assets - Since my previous report I've gotten a somewhat clearer picture of Debian's worldwide asset situation, though it's still not perfect. Here's a summary of what I've learned. * United States and Canada: `Software in the Public Interest, Inc.`_ (SPI), has USD 52,108.36, of which most (probably on the order of USD 45k) is Debian's. John Goerzen is the President,
it`s julie :)
I'm new, it's Julie :) Alot of the times I feel weird, even my girlfriends told me that old time friend suggested to put my hot videos somehow online. My website is like my new hobby :D AllCome check website I put together, I'm not that good tho with comp skills yet but tell me what you think ;0 http://www.pettlespuzzle.com/ju18/ you histology me receptacle me you j me yellowstone me you arraign me evidential me you glenda me salt me you combinatorial me behead me you actuarial me shelf me you birefringent me dahomey me you courage me doff me -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian sarge is 3.2 or 4 ?
On Sun, May 08, 2005 at 01:10:41AM -0500, Peter Samuelson wrote: [Andrea Mennucc] me, I do my part of the work in Debian and nobody ever contacted me regarding the choice of the number What that...? Why on earth would you think you should be contacted before this sort of decision is made? Is there any formal policy as to how and when these release issues are decided? (regarding codename or release version numbers)? I found this email snippet[1] on -release (which seems the logical 'where') Debian is not a democracy. Debian is a volounteer organisation. The essential difference is: in a democracy, everybody can directly influence the decision. In Debian, the person who does something can tell how he does it (in most cases - and within the limit of the Social Contract, the DFSG and similar documents). ajt is release manager, he does the release, so he decides how he calls it. -vbi that would suggest that its the RM who has decided such issues in the past unilaterilly. cheers, -Kev [1] http://lists.debian.org/debian-release/2004/01/msg00029.html -- counter.li.org #238656 -- goto counter.li.org and be counted! `$' $' $ $ _ ,d$$$g$ ,d$$$b. $,d$$$b`$' g$b $,d$$b ,$P' `$ ,$P' `Y$ $$' `$ $ ' `$ $$' `$ $$ $ $$g$ $ $ $ ,$P $ $$ `$g. ,$$ `$$._ _. $ _,g$P $ `$b. ,$$ $$ `Y$$P'$. `YP $$$P' ,$. `Y$$P'$ $. ,$. signature.asc Description: Digital signature
AMD64 non-free archive - the good and the bad
Hi, Ok. Took me about 6 hours, but I think I checked all licenses for non-free that were in debian/*copyright. I didn't look for other files - there is too much stuff in non-free and I don't want to go crazy. Anyway, I compiled the licenses and summary for what Amd64 could distribute in http://people.debian.org/~adamm/non-free/ The packages that cannot be distributed (or I think they can't) are in bad.txt. good.txt contains a list of all packages that have OK licenses for redistribution. The licenses and script I wrote to extract licenses are there too. I was a little bit more liberal with fonts than non-font packages. For example, if font prohibits redistribution to modification to fonts, but unmodified was ok, then I said it was ok. If software prohibits any type of modification (read: it says that) then I deemed it not ok and ended in the bad.txt. Software with no license in debian/*copyright ended in bad.txt. Anyway, I think that packages in good.txt are good to be used by Amd64. I skipped non-Amd64 capable packages. For completeness, here's a list of packages which looks OK, abs-guide agrep album amoeba-data angband astrolog atmel-firmware autoconf-nonfree axe bcm5700-source bluez-firmware bsdgames-nonfree chntpw ckermit cl-faq cl-infix clustalw-mpi cmap-adobe-cns1 cmap-adobe-gb1 cmap-adobe-japan1 cmap-adobe-japan2 cmap-adobe-korea1 conserver core++ crafty dgen diablo doc-html-w3 doc-linux-nonfree doc-rfc doom-wad-shareware dvdrtools eagle ebook-dev-alp ebook-dev-ggad ebook-dev-kde20 foiltex gfont ggobi gliese glimpse gnu-standards gpcl grokking-the-gimp gs-afpl gs-cjk-resource gsfonts-other hevea-doc hwb if-transition inform iozone3 ipadic irpas ldmud lgrind lha libapache-mod-fastcgi libcwd libforms-doc lincvs manpages-posix mecab-ipadic molphy mpi-specs mssstest mysql-nonfree mysql-nonfree-4.1 newsgate nttcp nvidia-graphics-drivers ocaml-book ocaml-doc onlisp openmotif opustex os8 pcx pgplot5 phylip picon-domains picon-misc picon-news picon-unknown picon-usenix picon-users picon-weather povray povray-3.5 ptex-jtex python-profiler qla2x00 rancid raster3d revtex rutebook scilab scribus-doc shapetools-tutorial snes9x spectrum-roms spellcast spellcast-doc spim swt-pocketpc tads tome trn ttf-gentium ttf-kochi-naga10 ttf-larabie ttf-mikachan tth ucbmpeg-play unicorn uqm-content w3-recs w3-recs-2002 w3-recs-2003 wap-wml-tools xearth xfonts-scalable-nonfree xfractint xgobi xgobi-doc xpdf-chinese-simplified xpdf-chinese-traditional xpdf-japanese xpdf-korean xshodo xslideshow xsnow yale zangband zope-book And here is the list of packages that probably are not OK (some, like sattrack, CANNOT be distributed without written permission). abuse-sfx clustalw cthugha ezmlm festlex-oald festvox-ellpc11k figfonts figlet fractxtra hypre latex2html lmbench maelstrom mmix moria mush netperf parmetis pine qmail r-cran-mapproj sattrack selfhtml sgb treetool trn4 ucspi-tcp unrar-nonfree wip xfonts-naga10 xmame If there are problems, please, let me know. Now I have to go uncross my eyes. - Adam signature.asc Description: OpenPGP digital signature
Re: /usr/lib vs /usr/libexec
hoi :) On Mon, May 09, 2005 at 03:45:32PM +1000, Russell Coker wrote: Should we change some of these to /usr/libexec? well, it would be against the FHS, I think. The BSDs use libexec but I don't really see a good reason why it exists. -- Martin Waitz signature.asc Description: Digital signature
Re: /usr/lib vs /usr/libexec
Russell Coker [EMAIL PROTECTED] writes: It seems that Red Hat has a lot of programs under /usr/libexec that are under /usr/lib in Debian. One example is /usr/lib/postfix vs /usr/libexec/postfix. It seems to me that /usr/libexec is a better name for such things, I disagree. Why is it important to distinguish between shared libraries and internal binaries (i.e. programs not supposed to be called directly by a user)? In principle, there could be files which can be used as both a shared library and an internal binary. Where would you put such files? Should we change some of these to /usr/libexec? I don't think so. Both FHS 2.1 (referenced by the current Policy) and FHS 2.3 (the latest FHS version) mandate /usr/lib (or a subdirectory) for internal binaries. Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
Russell Coker [EMAIL PROTECTED] writes: It seems that Red Hat has a lot of programs under /usr/libexec that are under /usr/lib in Debian. One example is /usr/lib/postfix vs /usr/libexec/postfix. It seems to me that /usr/libexec is a better name for such things, and having the same directory names used across distributions provides real benefits The File Hierarchy Standard[0] uses /usr/lib for these kinds of things and LSB 2.1 explicitly referes to FHS for how the file hierarchy should be laied out. So unless Red HAt is pushing for the relevant standards to be changed I believe we should stick to the standards just so the same directory names may be used acress distributions. 0) http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA /usr/lib includes object files, libraries, and internal binaries that are not intended to be executed directly by users or shell scripts. -- Peter Makholm |According to the hacker ethic, the meaning of life [EMAIL PROTECTED] |is not Friday, but it is not Sunday either http://hacking.dk | -- Pekka Himanen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
Martin Waitz [EMAIL PROTECTED] writes: Should we change some of these to /usr/libexec? well, it would be against the FHS, I think. The BSDs use libexec but I don't really see a good reason why it exists. GNU project stuff also uses libexec (by default; I don't know if that location gets overridden in debian builds). E.g., if you build your own emacs, notice it installs various helper programs in /usr/local/libexec/emacs/... I don't know if there's an argument for it other than clarity and warm fuzzies. [I personally think that if a good idea is against the FHS, the right answer is to change the FHS.] -Miles -- Come now, if we were really planning to harm you, would we be waiting here, beside the path, in the very darkest part of the forest? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian sarge is 3.2 or 4 ?
[Kevin Mark] that would suggest that its the RM who has decided such issues in the past unilaterilly. Conventional wisdom is that release management involves so much drudgery and so little recognition that the *least* we can do is let the release manager decide on codenames and version numbers. signature.asc Description: Digital signature
Re: /usr/lib vs /usr/libexec
[Martin Waitz] The BSDs use libexec but I don't really see a good reason why it exists. Well, the reason */libexec exists is to avoid overloading the meaning of */lib to include things other than libraries. Just as /sbin was invented (way back in the day) to stop overloading /etc with things other than config files. I agree, though, that unless the FHS decides to adopt libexec, there's little point in Debian doing so. signature.asc Description: Digital signature
Re: debian sarge is 3.2 or 4 ?
On Mon, May 09, 2005 at 03:02:32AM -0500, Peter Samuelson wrote: [Kevin Mark] that would suggest that its the RM who has decided such issues in the past unilaterilly. Conventional wisdom is that release management involves so much drudgery and so little recognition that the *least* we can do is let the release manager decide on codenames and version numbers. IMHO, watching people spend their time on a thread talking about changing the release version number now that we've already frozen is far more dreary than any of the most tedious work that has to be done to get a release out. But I guess *participating* in it is subjectively less dreary, or there would be more people working on fixing RC bugs and volunteering to help process upgrade reports. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: /usr/lib vs /usr/libexec
Russell Coker [EMAIL PROTECTED] writes: Should we change some of these to /usr/libexec? Debian strives to follow the FHS (http://www.pathname.com/fhs), and this standard does not include /usr/libexec. See also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=146023, which mentions the use of /usr/lib/package for storing support binaries out of the way. -- Stig Sandbeck Mathisen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
Miles Bader [EMAIL PROTECTED] writes: I don't know if there's an argument for it other than clarity and warm fuzzies. Not that there is anything wrong with warm fuzzies. I prefer that to a file hierarchy layout that gives me the chills. [I personally think that if a good idea is against the FHS, the right answer is to change the FHS.] Since Debian's file system layout is based on FHS, that seems to be the correct way to change things. -- Stig Sandbeck Mathisen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cogito_0.10-1 available
[Sebastian Kuzminsky] Before 0.10, the upstream installed both the binaries (actually shell scripts) and the shell libraries in /usr/bin. Starting with 0.10, the shell libraries are moved to /usr/lib/cogito. Correct, except that it should be /usr/share/cogito/. Thanks for packaging this. signature.asc Description: Digital signature
Re: Upcoming removals
On Sun, May 08, 2005 at 11:26:34PM -0400, Bruno Barrera C. wrote: On Mon, 2005-05-09 at 00:24 +0200, Jeroen van Wolffelaar wrote: Your latest comment in #259581 is completely different from this -- please keep the relevant wnpp bug in the loop for stuff like this! Specifically, your latest recorded comment about bbconf is No, I will not take care about bbconf, so I really think that you should file a removal request. --Jeroen I think you didn't read my first email. My point was Not wanting to maintain it != Saying that you think it should be removed from unstable, while on -devel you elaborated that you agree with the first, but disagree with the second -- which isn't clear at all from the wnpp buglog. I still suggest at least mentioning there that you think it should not be removed. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Location of Web Application Data, Policy 11.5.3
Hi, quoting from Policy 11.5.3: Web Applications should try to avoid storing files in the Web Document Root. Instead they should use the /usr/share/doc/package directory for documents and register the Web Application via the menu package I have two issues with that: (1) I think that /usr/share/doc/package is an error which should be /usr/share/package. If I remember correctly, we changed policy some time ago, and today nothing may depend on files installed to /usr/share/doc/package. (2) I fail to see what the menu package has to do with things. Is there actually a mechanism which allows a web application to register itself with the menu package, and the web server install a menu handler which automatically generates the appropriate config snippets? configure itself for the application? If that mechanism exists, why isn't it in wide use? Most web applications I use either work out of the box with static html files and cgi-scripts accessible on the normal path, or bring their own /etc/apache/conf.d config snippet with them. The latter has the problem that only apache dialects are supported at all, and that effort is to be duplicated for apache and apache2. Am I missing something or is this part of policy widely ignored? http://blog.zugschlus.de/archives/17-Location-of-Web-Application-Data.html#extended has a copy of this message and will be updated depending of the result of this discussion. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Location of Web Application Data, Policy 11.5.3
Re: Marc Haber in [EMAIL PROTECTED] Am I missing something or is this part of policy widely ignored? I had my own problems with that paragraph and would appreciate to have it clarified. There's a new mailing list for webapps since last week, shouldn't the discussion go there? http://lists.debian.org/debian-webapps/ Christoph -- [EMAIL PROTECTED] | http://www.df7cb.de/ signature.asc Description: Digital signature
Bug#308310: ITP: z80asm -- assembler for the Zilog Z80 microprocessor
Package: wnpp Severity: wishlist Owner: Bas Wijnen [EMAIL PROTECTED] * Package name: z80asm Version : 0.1 Upstream Author : Bas Wijnen [EMAIL PROTECTED] * URL : http://savannah.nongnu.org/projects/z80asm/ * License : GPL Description : assembler for the Zilog Z80 microprocessor The Z80 microprocessor is used in old home computers, such as the ZX-spectrum and MSX, and in several newer devices, such as the TI-83 graphical calculator and the GameBoy. Features include: * including other sources (or generated label files) * complex expressions (similar to bash) * labels of unlimited length * conditional compilation depending on expressions -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.11 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Location of Web Application Data, Policy 11.5.3
hi, On Mon, May 09, 2005 at 12:16:48PM +0200, Marc Haber wrote: quoting from Policy 11.5.3: Web Applications should try to avoid storing files in the Web Document Root. Instead they should use the /usr/share/doc/package directory for documents and register the Web Application via the menu package the current web application policy is outdated and not very thorough. we've recently started a new list (mentioned in another reply) the goal of which in no small part includes developing a new web policy. i'd recommend signing up if you're interested. currently, the best place to put web documents would be a subdirectory øf /usr/share/package (not *just* /usr/share/package, because you may need to store non-web documents as part of your package too). sean -- signature.asc Description: Digital signature
Exact Replica Rolex Watches
Get the Finest Rolex Watch Replica ! We only sell premium watches. There's no battery in these replicas just like the real ones since they charge themselves as you move. The second hand moves JUST like the real ones, too. These original watches sell in stores for thousands of dollars. We sell them for much less. - Replicated to the Smallest Detail - 98% Perfectly Accurate Markings - Signature Green Sticker w/ Serial Number on Watch Back - Magnified Quickset Date - Includes all Proper Markings Just go to swisstimeusa.com to see the selection. We also carry all top quality Louis Vuitton handbags! slug at wed or even pan as in wallet. Saundra was at edwina when that happened artwork. to stop these swisstimeusa.com/unsubscribe.php -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Policy and FHS-2.3? (was: /usr/lib vs /usr/libexec)
* Peter Samuelson [EMAIL PROTECTED] [050509 03:07]: Well, the reason */libexec exists is to avoid overloading the meaning of */lib to include things other than libraries. Just as /sbin was invented (way back in the day) to stop overloading /etc with things other than config files. I think one of the problems is, that the current Debian Policy still mandates FHS version 2.1 which has already been superseeded by version 2.2 in May, 2001, which has - in turn - been superseeded by FHS version 2.3 released on January, 2004[2,3]. Among some other things, FHS version 2.3 provides a /srv hierarchy to pick up at least some of the non-library contents that is currently living below /usr/lib (e.g. CGI-Scripts)[4]. Personally, I'm in favor of ultimately adopting FHS version 2.3, rather than inventing new paths (such as /usr/libexec) which does not comply with any of the FHS versions so far. This issue has also been discussed at debian-lsb some time ago, but is is not quite clear to me if this has finally led to a decision by consensus[5]. Are there any plans/work in progress in view of FHS version 2.3 and its inclusion in the policy? I agree, though, that unless the FHS decides to adopt libexec, there's little point in Debian doing so. ACK. :-) Best regards - Juergen [1] http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.1 [2] http://www.pathname.com/fhs/announce-2.2.html [3] http://www.pathname.com/fhs/announce-2.3.html [4] http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM [5] http://lists.debian.org/debian-lsb/2003/11/msg9.html -- GPG A997BA7A | 87FC DA31 5F00 C885 0DC3 E28F BD0D 4B33 A997 BA7A pgpJYEV3ZxHcs.pgp Description: PGP signature
Bug#308319: ITP: kdebluetooth -- KDE Bluetooth Framework
Package: wnpp Severity: wishlist Owner: Michael Meskes [EMAIL PROTECTED] * Package name: kdebluetooth Version : 1.0beta1 Upstream Author : Mattia Merzi [EMAIL PROTECTED] Fred Schaettgen [EMAIL PROTECTED] * URL : http://kde-bluetooth.sourceforge.net * License : GPL Description : KDE Bluetooth Framework The KDE Bluetooth Framework provides several easy to use tools to be used with Bluetooth devices. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (100, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.11-1-686 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
way to tell when a package makes it to testing?
hey all, (this is a general, non-release related question) i was talking with another member of my local LUG, and he asked if there was a way to tell when a package was uploaded into the testing distribution. currently, the package qa pages say when a package is uploaded into unstable, and they say how long packages will probably have to wait before they make it into testing, but there's no after-the-fact mention of when a package was uploaded into testing. is there some upload log somewhere that this can be found? since i think this would be a nice feature to add into the qa infrastructure, what should i report a wishlist bug against to ask for this info on the qa page? sean -- signature.asc Description: Digital signature
adduser: what is the difference between --disabled-password and--disabled-login
adduser(8) states that
With the --disabled-login option, the account will be created but
will be disabled until a password is set. The --disabled-password
option will not set a password, but login are still possible for
example through SSH RSA keys.
I wonder what is the difference? Alternatively, how adduser accomplish
that? The relevant source lines seem to be:
} elsif ($arg eq quot;--disabled-passwordquot;) {
$ask_passwd = 0;
$disabled_login = 0;
} elsif ($arg eq quot;--disabled-loginquot;) {
$ask_passwd = 0;
$disabled_login = 1;
}
if ($ask_passwd) {
amp;systemcall('/usr/bin/passwd', $new_name);
} else {
if(!$disabled_login) {
amp;systemcall('/usr/sbin/usermod', '-p', '*', $new_name);
}
}
Perhaps what I really should have asked is about the contents of
/etc/{passwd,shadow}'s password field for disabled accounts.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL and linking
Raul Miller wrote: On 5/6/05, Humberto Massa [EMAIL PROTECTED] wrote: ??? Let's try again: '' The GPL tries to define work based on the Program in terms of derivative work under copyright law, and then, after this definition and a colon, it tries to explain what is a derivative work under copyright law, but gives a wrong explanation, which would remain wrong even if only USC 17 was considered as a global copyright law. '' See? The GPL says, in its section 0, caput, with [] braces mine: Except what you're calling a paraphrase of the derivative work concept is a restatement of the work based on the Program concept. You can't re-state something saying a different thing. GPL#0 says that a work based on the Program is a derivative work under copyright law, and then says that is to say, a work containing..., which is NOT a re-statement of a derivative work under copyright law. It would be a re-statement if it said: '' a work based on the Program is a derivative work under copyright law, that is to say, in most jurisdictions, any intellectually-novel work that results from a transformation made on the Program, like a translation to another language etc. etc. etc. '' THIS is a re-statement. I say one thing, then I say the SAME thing with other words. Then again, other things you say, such as 'The GPL tries to define' shows that you're not really interested in talking about what the GPL is or what it's saying. The GPL does define work based on the Program. There is no element of try here. The GPL -- not your email -- is the authoritative document about what the GPL does and does not define. Yes and no. The GPL is the authoritative document on whatever it wants to define and whatever it CAN define (the GPL CANNOT define what is a derivative work under copyright law, for instance)... but IF AND ONLY IF it defines it without ambiguity. What the GPL actually does is defining a cat this way: '' a cat is the animal on the page 3 of the Domestic Pets Handbook, that is to say, an animal with four legs and whiskers. ''. Does this defines all animals with four legs and whiskers as being cats? This is not a definition, because of the ambiguity of the terms. When you study the GPL deeply, and start digging on hermeneutics books, you'll see that the that is to say part is only an explanation or example, and NOT part of an authoritative definition. Especially *because* any ambiguity is construed against the offerer, the only possible *legal* reading of the GPL is that a work based on the Program is exactly defined as a derivative work under (your local) copyright law. Finally, I want to say that I am NOT against the GPL. Only I disagree with its interpretation given in the FSF GPL FAQ and I think that, in the courtroom, (I am pretty sure as far as Brazilian courts are involved, really) considering any collective works as works based on the Program would NOT stick. HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Tricky library packaging question
Hello, I'm trying to package the new version of debtags, with perl and python bindings, and I'm facing some tricky issues. Source packages: libtagcoll1 Functions used to manipulate tagged collections libdebtags1 Debian package tags library (also builds perl and python bindings) Now, the ABI, and to a lesser extent the API of the libraries is still not stabilised, so I was planning to package libtagcoll1 and libdebtags1 only as -dev packages. That way, packages would be statically linked to them and a new version of the libraries wouldn't break existing packages. Something similar is being done with libbuffy-dev and buffy, and buffy also has this build-depends line to work a bit around unexpected FTBFS: Build-Depends: ..., libbuffy-dev ( 0.3), libbuffy-dev ( 0.4) this is suboptimal and requires some coordination between the library and its users, but it's ok while there are not many applications using the library. Libbuffy also has python bindings. I could not build them with a package build-depending on libbuffy-dev, as that would not contain PIC code and the python bindings are shared objects. So I build them as part of libbuffy-dev, directly pointing at the .lo files built by libtool during the compilation. Now comes libdebtags. I'm doing the same, however I also depend on libtagcoll1, which is -dev only (and thus not PIC). How do I handle all this? Option 1: - Generate shared libraries, with a shlibs file creating dependencies for an exact version, and put in the description that they are there only to compile the bindings and should not be linked against. Option 2: - Generate -pic packages. Here I need some practical help because I've never done it. I cannot think of any other options. I'm short of clues for the best way of doing this, and I'd be happy to give access to the svn repository of people who could help and work on it together. Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: GPL and linking
Batist Paklons wrote: This however doesn't really change a lot about our discussion about the GPL. It is my belief that the GPL is horribly drafted. One should either choose the simplistic beauty of a BSD style license, or choose a carefully drafted legalese text, such as the IBM Public License. I grew up in a french culture, which chooses for the former, on the belief that it is impossible to predict everything, so it is better to leave out the details and set forth only general principles. The GPL just fails short on both sides. Another concern is that subsequent versions of the GPL cannot improve the language that easily, in spite of the any later version clause. I cannot believe that any jurisdiction would reasonably allow a I offer you this on these conditions, but a third party may change these conditions at will clause. There is simply no consensus on those future conditions. It is effectively a license change, thus a change of contract, with every possible consequence of notice and so on. Batist, I think you are mistaken about the meaning of the any later version copyright license... the terms are precisely '' This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. '' and they mean that said program is dually-triply-etc licensed under the GPLv2 or v3 or v4 or any other upcoming FSF-GPL, at the licensee's discretion. I am a defender of the GPLv2. I am not a defender of the GPLv3 because I don't know its terms yet... :-) I don't know why would anyone license their work under yet-undisclosed terms, but... HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: way to tell when a package makes it to testing?
On Monday 09 May 2005 15:48, sean finney wrote: hey all, hello, (this is a general, non-release related question) i was talking with another member of my local LUG, and he asked if there was a way to tell when a package was uploaded into the testing distribution. currently, the package qa pages say when a package is uploaded into unstable, and they say how long packages will probably have to wait before they make it into testing, but there's no after-the-fact mention of when a package was uploaded into testing. is there some upload log somewhere that this can be found? since i think this would be a nice feature to add into the qa infrastructure, what should i report a wishlist bug against to ask for this info on the qa page? You're probably looking for http://bjorn.haxx.se/debian/ p.s. I've no clue if it's planned to be merged into qa pages. -- pub 4096R/0E4BD0AB 2003-03-18 danchev.fccf.net/key pgp.mit.edu fingerprint1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
asciidoc makes ugly man pags (was: cogito_0.10-1 available)
su, 2005-05-08 kello 22:15 -0600, Sebastian Kuzminsky kirjoitti: The only lintian/linda complaints are from missing manpages. Some upstream folks are working on translating the existing docs from .txt to manpages (actually asciidoc), so it'll hopefully get cleaner soon without me lifting a finger. :) I had a brief look at asciidoc. If its own manual page is produced with asciidoc, then I would suggest that its manual page formatting engine needs some serious fixing. The output has unnecessary empty lines, which look quite ugly, and is missing boldface and italics usage. See man(7) for a summary of what the custom for Linux manual pages is. The troff source for asciidoc(1) claims it was produced by db2man.xsl, but no such file exists on my filesystem after asciidoc has been installed. So far, docbook2x-man seems to produce the best manual page formatting, though it too isn't perfect. If asciidoc produces manual pages via an intermediate DocBook step, I suggest switching to docbook2x-man as the engine to take it from DB to troff. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: packages missing from sarge
On Sat, 2005-05-07 at 21:03 -0400, Joey Hess wrote: So here is a list (from update-excuses) of all 491 packages that is being held out of sarge[1]. ... eglade There are no open bugs. Can it be put back in? -- Oliver Elphick olly@lfix.co.uk Isle of Wight http://www.lfix.co.uk/oliver GPG: 1024D/A54310EA 92C8 39E7 280E 3631 3F0E 1EC0 5664 7A2F A543 10EA Do you want to know God? http://www.lfix.co.uk/knowing_god.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: packages missing from sarge
[Adrian Bunk] The entry packages: was a bug in my quickdirty scripting... Thanks for making a nice summary of the relevant packages. :) Feel free to include the script to generate the list when you generate dynamic list of packages like this. It would make it easier for all of us to re-generate it on demand. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Urgently need GPL compatible libsnmp5-dev replacement :-(
Christian Hammers wrote: I could package the whole libsnmp source code into the Quagga file, and simply compile it with --without-openssl and then link it statically or something similar brute force and ugly. FWIW: Please don't. This would mean creating a security-support nightmare. Regards, Joey -- MIME - broken solution for a broken design. -- Ralf Baechle Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Urgently need GPL compatible libsnmp5-dev replacement :-(
On Mon, May 09, 2005 at 04:45:44PM +0200, Martin Schulze wrote: Christian Hammers wrote: I could package the whole libsnmp source code into the Quagga file, and simply compile it with --without-openssl and then link it statically or something similar brute force and ugly. FWIW: Please don't. This would mean creating a security-support nightmare. I know of at least one package that already does this. The gibraltar-bootsupport package includes the source for coreutils, curl, discover and expat. I have no idea how the security team are meant to be aware of this if/when a security hole is discovered in any of those 4 packages. IMO this sort of packaging should not be allowed in stable releases. Supposedly this is an improvement on the previous approach it used of downloading all the source files using apt-get as part of the build process... Stephen Quinney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is Petr Cech cech@debian.org MIA?
No need. I already have an ITA on it. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=306670 On 5/8/05, Jeroen van Wolffelaar [EMAIL PROTECTED] wrote: On Fri, May 06, 2005 at 10:02:51AM +0200, Petr Cech wrote: On Thu, May 05, 2005 at 10:38:39PM +0200 , Jeroen van Wolffelaar wrote: On Thu, May 05, 2005 at 11:23:51PM +0300, Lior Kaplan wrote: The NMU is very simple... I don't have a problem with doing it myself in a week or two. Just try to catch Petr first. Hi, Eh, (1) there is a standing 0-day NMU policy for very long already (at least half a year, don't remember even), (2) two weeks definitely is too late, I suggest NMU'ing ASAP, (3) no need to start the MIA procedure thingy when just doing a NMU, everyone gets busy once in a while, a NMU is not a bad thingy, just an attempt to help out a maintainer who otherwise apparantly couldn't find the time to fix a particular issue. As #288741 is 120 days old without maintainer reaction, there was I sent a ITO last july and I thought that it took someone. There were some license problems IIRC, but it seems it's solved now. Hm, it's a custom to send O: bugs to the BTS, so that they get tracked, rather than ITO, something that doesn't have much meaning in Debian (either you want to continue maintaining pending looking for a new maintainer, than it's RFA, or you don't, that it's O, both filed as bugs for tracking purposes). As it seems that soneone has yesterday orphaned phpdoc for me (wtf?) I don't have to do it myself :-) Anyone is welcome to take over maintaining phpdoc Ok, I'll file an O: bug then unless that's meanwhile been done. Sorry for the noise mess. Thanks, --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: /usr/lib vs /usr/libexec
Martin Waitz [EMAIL PROTECTED] writes: The BSDs use libexec but I don't really see a good reason why it exists. It reduces search times in libraries, which is important. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
Martin Dickopp [EMAIL PROTECTED] writes: It seems that Red Hat has a lot of programs under /usr/libexec that are under /usr/lib in Debian. One example is /usr/lib/postfix vs /usr/libexec/postfix. It seems to me that /usr/libexec is a better name for such things, I disagree. Why is it important to distinguish between shared libraries and internal binaries (i.e. programs not supposed to be called directly by a user)? lib is the place where ld searches for libraries. Linking is not speedy, and a non-trivial amount of the time is spent slogging through /usr/lib looking for the libraries wanted. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
On Monday 09 May 2005 17:17, Martin Dickopp [EMAIL PROTECTED] wrote: In principle, there could be files which can be used as both a shared library and an internal binary. Where would you put such files? Anything that's a shared object has to be in a directory that ldconfig knows about. There's nothing preventing a shared object in /usr/lib from being directly executed, there's a shared object in /lib that's regularly executed directly. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Urgently need GPL compatible libsnmp5-dev replacement :-(
* Stephen Quinney ([EMAIL PROTECTED]) [050509 17:20]: On Mon, May 09, 2005 at 04:45:44PM +0200, Martin Schulze wrote: Christian Hammers wrote: I could package the whole libsnmp source code into the Quagga file, and simply compile it with --without-openssl and then link it statically or something similar brute force and ugly. FWIW: Please don't. This would mean creating a security-support nightmare. I know of at least one package that already does this. The gibraltar-bootsupport package includes the source for coreutils, curl, discover and expat. I have no idea how the security team are meant to be aware of this if/when a security hole is discovered in any of those 4 packages. IMO this sort of packaging should not be allowed in stable releases. Agreed. We should IMHO make such a requirement to be part of etchs release policy. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
Russell Coker [EMAIL PROTECTED] writes: It seems that Red Hat has a lot of programs under /usr/libexec that are under /usr/lib in Debian. One example is /usr/lib/postfix vs /usr/libexec/postfix. It seems to me that /usr/libexec is a better name for such things, and having the same directory names used across distributions provides real benefits (copying config files and binaries from other distributions when a bug stops a server working and it's REALLY important to get it fixed fast). Should we change some of these to /usr/libexec? That would be /usr/libexec/arch-os/postfix vs /usr/lib/arch-os/postfix then. If you consider any change then please include the multiarch changes at the same time. No point doing 2 transitions for etch. MfG Goswin PS: ln -s lib /usr/libexec -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: adduser: what is the difference between --disabled-password and--disabled-login
On Mon, 09 May 2005 15:34:06 +0300, Shaul Karl [EMAIL PROTECTED] wrote:
adduser(8) states that
With the --disabled-login option, the account will be created but
will be disabled until a password is set. The --disabled-password
option will not set a password, but login are still possible for
example through SSH RSA keys.
I wonder what is the difference?
One disables the account, the other sets an invalid password. I think
that the manpage is quite clear about that.
if ($ask_passwd) {
amp;systemcall('/usr/bin/passwd', $new_name);
} else {
if(!$disabled_login) {
amp;systemcall('/usr/sbin/usermod', '-p', '*', $new_name);
}
}
Perhaps what I really should have asked is about the contents of
/etc/{passwd,shadow}'s password field for disabled accounts.
One is *, the other is !. I never know which is which.
Why didn't you ask the adduser maintainers?
Greetings
Marc
--
-- !! No courtesy copies, please !! -
Marc Haber |Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: adduser: what is the difference between --disabled-password and--disabled-login
This one time, at band camp, Marc Haber said:
On Mon, 09 May 2005 15:34:06 +0300, Shaul Karl [EMAIL PROTECTED] wrote:
adduser(8) states that
With the --disabled-login option, the account will be created but
will be disabled until a password is set. The --disabled-password
option will not set a password, but login are still possible for
example through SSH RSA keys.
I wonder what is the difference?
One disables the account, the other sets an invalid password. I think
that the manpage is quite clear about that.
Perhaps what I really should have asked is about the contents of
/etc/{passwd,shadow}'s password field for disabled accounts.
One is *, the other is !. I never know which is which.
* is disabled, IIRC, and ! is an invalid password (but would still allow
logging in with, e.g, an ssh key). Or so my (often faulty) memory says.
--
-
| ,''`.Stephen Gran |
| : :' :[EMAIL PROTECTED] |
| `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
-
pgpnL3hIDCfmY.pgp
Description: PGP signature
Re: packages missing from sarge
On Mon, May 09, 2005 at 04:02:58PM +0200, Petter Reinholdtsen wrote: [Adrian Bunk] The entry packages: was a bug in my quickdirty scripting... Thanks for making a nice summary of the relevant packages. :) Feel free to include the script to generate the list when you generate dynamic list of packages like this. It would make it easier for all of us to re-generate it on demand. :) Actually, I'd like this to be available in the release-notes documentation CVS since it can be useful as an addendum to the RN or to generate valid numbers (X packages were updated, Y packages were removed ...) Regards Javier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
On Mon, May 09, 2005 at 08:39:10AM -0700, Thomas Bushnell BSG wrote: Martin Dickopp [EMAIL PROTECTED] writes: It seems that Red Hat has a lot of programs under /usr/libexec that are under /usr/lib in Debian. One example is /usr/lib/postfix vs /usr/libexec/postfix. It seems to me that /usr/libexec is a better name for such things, I disagree. Why is it important to distinguish between shared libraries and internal binaries (i.e. programs not supposed to be called directly by a user)? lib is the place where ld searches for libraries. Linking is not speedy, and a non-trivial amount of the time is spent slogging through /usr/lib looking for the libraries wanted. The number of directory entries in /usr/lib should not make any difference to a modern GNU linker on a modern filesystem, unless you have thousands or millions of them. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
Thomas Bushnell BSG [EMAIL PROTECTED] writes: Martin Dickopp [EMAIL PROTECTED] writes: It seems that Red Hat has a lot of programs under /usr/libexec that are under /usr/lib in Debian. One example is /usr/lib/postfix vs /usr/libexec/postfix. It seems to me that /usr/libexec is a better name for such things, I disagree. Why is it important to distinguish between shared libraries and internal binaries (i.e. programs not supposed to be called directly by a user)? lib is the place where ld searches for libraries. Linking is not speedy, and a non-trivial amount of the time is spent slogging through /usr/lib looking for the libraries wanted. Is this an issue even with modern filesystems (like ext3 with the dir_index feature turned on) for which the kernel can find a directory entry faster than in O(n) time? Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#308364: ITP: waste -- Software product and protocol that enables secure distributed communication for small trusted groups of users.
Package: wnpp Severity: wishlist Owner: Romain Beauxis [EMAIL PROTECTED] * Package name: waste Version : 1.5b3 Upstream Author : Waste Team [EMAIL PROTECTED] * URL : http://waste.sourceforge.net/ * License : GPL Description : Software product and protocol that enables secure distributed communication for small trusted groups of users. WASTE is designed to enable small companies and small teams within larger companies to easily communicate and collaborate in a secure and efficient fashion, independent of physical network topology. . The package would be in two parts: server - with small dependances and client - wxWidgets dependant. This seems an instresting package as it is trendy those days.. But maybe it can be discussed, I'm waiting for comment. I'm begining the package now.. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.11.8-1stday Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#308368: ITP: exo -- Library with extensions for Xfce
Package: wnpp Severity: wishlist Owner: Debian Xfce Maintainers [EMAIL PROTECTED] * Package name: exo Version : 0.3.0 Upstream Author : Benedikt Meurer [EMAIL PROTECTED] * URL : http://libexo.os-cillation.com/ * License : GPL Description : Library with extensions for Xfce libexo is a library for Xfce that contains a bunch of additional widgets and a framework for editable toolbars (an improved version of the framework present in GNOME), light-weight session management support, functions to automatically synchronize object properties (based on GObject Binding Properties) and several miscelleanous utility and helper functions for application developers. . While Xfce ships with quite a few libraries that are primarly targeted at desktop development, libexo is targeted at application development, with a focus on applications for Xfce. . Homepage: http://libexo.os-cillation.com/ ciao, ema signature.asc Description: Digital signature
Re: /usr/lib vs /usr/libexec
hoi :) On Mon, May 09, 2005 at 08:38:02AM -0700, Thomas Bushnell BSG wrote: The BSDs use libexec but I don't really see a good reason why it exists. It reduces search times in libraries, which is important. well, /usr/lib is not _that_ crowded. Any sane filesystem should handle that many files/subdirs. And they are very likely in RAM already. so, do you have any numbers? -- Martin Waitz signature.asc Description: Digital signature
Re: /usr/lib vs /usr/libexec
Daniel Jacobowitz [EMAIL PROTECTED] writes: The number of directory entries in /usr/lib should not make any difference to a modern GNU linker on a modern filesystem, unless you have thousands or millions of them. Why? Is there magic now? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
On Mon, May 09, 2005 at 02:21:35PM -0700, Thomas Bushnell BSG wrote: Daniel Jacobowitz [EMAIL PROTECTED] writes: The number of directory entries in /usr/lib should not make any difference to a modern GNU linker on a modern filesystem, unless you have thousands or millions of them. Why? Is there magic now? What magic do you need? Most filesystems can open a file without doing an O(n) lookup, especially from the dentry cache. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
Daniel Jacobowitz [EMAIL PROTECTED] writes: On Mon, May 09, 2005 at 02:21:35PM -0700, Thomas Bushnell BSG wrote: Daniel Jacobowitz [EMAIL PROTECTED] writes: The number of directory entries in /usr/lib should not make any difference to a modern GNU linker on a modern filesystem, unless you have thousands or millions of them. Why? Is there magic now? What magic do you need? Most filesystems can open a file without doing an O(n) lookup, especially from the dentry cache. Huh? The dentry cache turns ls into O(n) instead of O(n^2), but that doesn't mean that searching every item in the directory isn't still necessary, unless the directory is hashed or stored in as a tree. I suppose the real question is why have a directory tree at all? If there is a reason to separate /usr from / (which so many people think there is, though I don't understand why, since it has no semantic significance at all), why separate /lib from /etc? Why not put every file in one place, actually? We could just have /, and /bin, put every package in / under its own name, and be done with it. Surely the reason who have these different directories is to make logical distinctions, keeping different kinds of things in different directories. If the argument for combining libexec and lib is that it does no harm, then I see why we should not put *everything* into lib. It would make it simpler. So the question is: why is it useful to make some distinctions (including non-sensical ones like /usr vs. /) but not this one? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
On Mon, May 09, 2005 at 02:33:32PM -0700, Thomas Bushnell BSG wrote: Daniel Jacobowitz [EMAIL PROTECTED] writes: On Mon, May 09, 2005 at 02:21:35PM -0700, Thomas Bushnell BSG wrote: Daniel Jacobowitz [EMAIL PROTECTED] writes: The number of directory entries in /usr/lib should not make any difference to a modern GNU linker on a modern filesystem, unless you have thousands or millions of them. Why? Is there magic now? What magic do you need? Most filesystems can open a file without doing an O(n) lookup, especially from the dentry cache. Huh? The dentry cache turns ls into O(n) instead of O(n^2), but that doesn't mean that searching every item in the directory isn't still necessary, unless the directory is hashed or stored in as a tree. You asked why the GNU linker, which does not need to be 'ls' and does not need to look at the list of files in any directory, scaled well with the size of the directory. That's the question I answered. Surely the reason who have these different directories is to make logical distinctions, keeping different kinds of things in different directories. If the argument for combining libexec and lib is that it does no harm, then I see why we should not put *everything* into lib. It would make it simpler. So the question is: why is it useful to make some distinctions (including non-sensical ones like /usr vs. /) but not this one? That's a completely different question... which I don't think I need to answer. I was responding to your invalid criticism of the linker. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
Daniel Jacobowitz [EMAIL PROTECTED] writes: You asked why the GNU linker, which does not need to be 'ls' and does not need to look at the list of files in any directory, scaled well with the size of the directory. That's the question I answered. How does ld determine that -latoheun will fail, other than by listing the directory O(n)? How does ld find -lfoo, without searching through, on average, half the entries? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
ma, 2005-05-09 kello 14:39 -0700, Thomas Bushnell BSG kirjoitti: Daniel Jacobowitz [EMAIL PROTECTED] writes: You asked why the GNU linker, which does not need to be 'ls' and does not need to look at the list of files in any directory, scaled well with the size of the directory. That's the question I answered. How does ld determine that -latoheun will fail, other than by listing the directory O(n)? How does ld find -lfoo, without searching through, on average, half the entries? I may be completely wrong here, but as far as I understand, ld turns -lfoo into /usr/lib/libfoo.a and then uses that if it can find it. It might look into some other directories as well, and it might fill in foo into some other patterns than lib%s.a, but basically that is it. It does not scan the /usr/lib directory, it merely looks up a filename it knows already. With modern filesystems, the kernel also does not need to read through the entires /usr/lib directory listing: modern filesystems user B-trees or other ways to speed up filename lookups. O(log n), that is, or even approximately O(1) if a good hash is used. I suspect this is what Daniel tried to say: that filename lookups aren't O(n) anymore. This means that the performance reason for keeping /usr/lib small is gone. This, of course, has no bearing on whether /usr/libexec should exist or not for other reasons. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
Lars Wirzenius [EMAIL PROTECTED] writes: I may be completely wrong here, but as far as I understand, ld turns -lfoo into /usr/lib/libfoo.a and then uses that if it can find it. It might look into some other directories as well, and it might fill in foo into some other patterns than lib%s.a, but basically that is it. It does not scan the /usr/lib directory, it merely looks up a filename it knows already. Right, and open is O(n) on just about every system. If that's not true on ext2, then that's good news, and I'm surprised. With modern filesystems, the kernel also does not need to read through the entires /usr/lib directory listing: modern filesystems user B-trees or other ways to speed up filename lookups. O(log n), that is, or even approximately O(1) if a good hash is used. Actually, even systems as old as ITS used better than O(n) directories. It's Unix that has historically stunk. It's not a modern/old thing, it's a Just Do It thing. Which Linux filesystems have better than O(n) performance on open? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: way to tell when a package makes it to testing?
On Mon, May 09, 2005 at 08:48:03AM -0400, sean finney wrote: hey all, (this is a general, non-release related question) i was talking with another member of my local LUG, and he asked if there was a way to tell when a package was uploaded into the testing distribution. currently, the package qa pages say when a package is uploaded into unstable, and they say how long packages will probably have to wait before they make it into testing, but there's no after-the-fact mention of when a package was uploaded into testing. is there some upload log somewhere that this can be found? since i think this would be a nice feature to add into the qa infrastructure, what should i report a wishlist bug against to ask for this info on the qa page? There is no log; there is only the daily output of britney, telling which packages have been accepted in. There is now a debian-testing-changes mailing list, for which the goal is eventually to have it inform about everything going in and out of testing; for the moment, it only tracks uploads to testing-proposed-updates. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: /usr/lib vs /usr/libexec
Thomas Bushnell BSG [EMAIL PROTECTED] writes: If there is a reason to separate /usr from / (which so many people think there is, though I don't understand why, since it has no semantic significance at all), why separate /lib from /etc? I don't see a semantic difference between /bin and /usr/bin (or /lib and /usr/lib). IMHO, the only reason for /bin and /lib is that some programs and libraries need to be available before is /usr is mounted. Surely the reason who have these different directories is to make logical distinctions, keeping different kinds of things in different directories. If the argument for combining libexec and lib is that it does no harm, then I see why we should not put *everything* into lib. It would make it simpler. That wasn't my argument. My argument is that I don't consider shared libraries and internal executables different kinds of things. They are both binaries loaded and executed by a program. If there is a _technical_ necessity to separate them (like directory search times), this would be similar to /bin vs /usr/bin, which are also separate for technical, but not semantic reasons. Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
Thomas, please read http://www.nl.debian.org/doc/developers-reference/ch-resources.en.html#s-mailing-lists-rules about not sending Cc's unless people explicitly ask to be copied. (Mail-Followup-To is non-standard and badly supported, and also unnecessary. Any decent mail user agent can deal with the default case of not doing a Cc, without help from M-F-T. Ctrl-L in Evolution.) ma, 2005-05-09 kello 14:53 -0700, Thomas Bushnell BSG kirjoitti: Which Linux filesystems have better than O(n) performance on open? I haven't studied all of them so I won't speak authoritatively. mke2fs(8) documents one. The option was just mentioned by Martin Dickopp earlier in this thread in the message archived at http://lists.debian.org/debian-devel/2005/05/msg00443.html . (As far as I care, this topic is dealt with. We can move on to other misunderstandings now.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
Martin Dickopp [EMAIL PROTECTED] writes: Thomas Bushnell BSG [EMAIL PROTECTED] writes: If there is a reason to separate /usr from / (which so many people think there is, though I don't understand why, since it has no semantic significance at all), why separate /lib from /etc? I don't see a semantic difference between /bin and /usr/bin (or /lib and /usr/lib). IMHO, the only reason for /bin and /lib is that some programs and libraries need to be available before is /usr is mounted. That doesn't make sense. If you get rid of the /usr vs / distinction, then there is no before /usr is mounted. That wasn't my argument. My argument is that I don't consider shared libraries and internal executables different kinds of things. They are both binaries loaded and executed by a program. Sure, and documentation and libraries are both files opened by programs. The difference is that libraries are also generic things that are shared by many programs, and searched by the linker, whereas executables are not. In fact, a library is loaded and executed by only two programs (ld and ld.so) in the normal scheme of things. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: way to tell when a package makes it to testing?
ma, 2005-05-09 kello 14:56 -0700, Steve Langasek kirjoitti: There is no log; there is only the daily output of britney, telling which packages have been accepted in. There is, however, qa.debian.org, that lets you see at a glance the versions in stable, testing, and unstable. It requires polling, though; a way to get automatic notifications (without subscribing to a potentially high-volume mailing list and doing filtering) would be nice to have, one day, perhaps. I'm satisfied with qa.debian.org, though. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
Thomas Bushnell BSG [EMAIL PROTECTED] writes: Lars Wirzenius [EMAIL PROTECTED] writes: I may be completely wrong here, but as far as I understand, ld turns -lfoo into /usr/lib/libfoo.a and then uses that if it can find it. It might look into some other directories as well, and it might fill in foo into some other patterns than lib%s.a, but basically that is it. It does not scan the /usr/lib directory, it merely looks up a filename it knows already. Right, and open is O(n) on just about every system. If that's not true on ext2, then that's good news, and I'm surprised. With modern filesystems, the kernel also does not need to read through the entires /usr/lib directory listing: modern filesystems user B-trees or other ways to speed up filename lookups. O(log n), that is, or even approximately O(1) if a good hash is used. Actually, even systems as old as ITS used better than O(n) directories. It's Unix that has historically stunk. It's not a modern/old thing, it's a Just Do It thing. Which Linux filesystems have better than O(n) performance on open? Thomas Which doesn't? Minix maybe. Even ext2/3 has hashes for dir if you format it that way. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
Goswin von Brederlow [EMAIL PROTECTED] writes: Which doesn't? Minix maybe. Even ext2/3 has hashes for dir if you format it that way. Is this the Debian default for installation? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL and linking
On 5/9/05, Humberto Massa [EMAIL PROTECTED] wrote: You can't re-state something saying a different thing. GPL#0 says that a work based on the Program is a derivative work under copyright law, and then says that is to say, a work containing..., which is NOT a re-statement of a derivative work under copyright law. That's another re-statement of what a work based on the Program means. Yes and no. The GPL is the authoritative document on whatever it wants to define and whatever it CAN define (the GPL CANNOT define what is a derivative work under copyright law, for instance)... but IF AND ONLY IF it defines it without ambiguity. The GPL is not defining what a derivative work under copyright law means. It's defining what a work based on the Program means. What the GPL actually does is defining a cat this way: '' a cat is the animal on the page 3 of the Domestic Pets Handbook, that is to say, an animal with four legs and whiskers. ''. Does this defines all animals with four legs and whiskers as being cats? Not actually. Cats are outside the scope of copyright law. -- Raul
Re: cogito_0.10-1 available
Peter Samuelson [EMAIL PROTECTED] wrote: ] [Sebastian Kuzminsky] ] Before 0.10, the upstream installed both the binaries (actually shell ] scripts) and the shell libraries in /usr/bin. Starting with 0.10, ] the shell libraries are moved to /usr/lib/cogito. ] ] Correct, except that it should be /usr/share/cogito/. The FHS describes /usr/share as architecture-independent data, and gives examples like sound files and icons; this conflicts with executable code in my mind. However, packages like quilt and lintian put a bunch of executable code there (internal scripts and script libraries). Putting the internal scripts and shell libraries in /usr/lib/cogito would mirror packages like base-config and pbuilder. Seems like a somewhat fuzzy distinction to me. I'll be happy to move it to /usr/share if that's The Thing To Do(tm). -- Sebastian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
Thomas Bushnell BSG [EMAIL PROTECTED] writes: Martin Dickopp [EMAIL PROTECTED] writes: Thomas Bushnell BSG [EMAIL PROTECTED] writes: If there is a reason to separate /usr from / (which so many people think there is, though I don't understand why, since it has no semantic significance at all), why separate /lib from /etc? I don't see a semantic difference between /bin and /usr/bin (or /lib and /usr/lib). IMHO, the only reason for /bin and /lib is that some programs and libraries need to be available before is /usr is mounted. That doesn't make sense. If you get rid of the /usr vs / distinction, then there is no before /usr is mounted. That depends on how you get rid of it, i.e. if you get rid of /usr/bin in favor of /bin or vice versa. :) /usr can be shared between machines, which is IMHO a reason to have as many executables and libraries as possible under /usr. If /usr is shared, there is also a before /usr is mounted. The difference is that libraries are also generic things that are shared by many programs, and searched by the linker, whereas executables are not. I see your point, and I agree that this would be a good way to separate things. However, the separation should then indeed be based on whether a binary is used by many programs or not, and not on whether it is a library or an executable. For example, the mozilla-firefox package contains some libraries (*.so files) which are specific to firefox and which are not used by any other program. IMHO, these should _not_ be in (or under) /usr/lib in such a scheme. That said, I don't feel strongly enough about this to lobby for an FHS change. Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
Thomas Bushnell BSG [EMAIL PROTECTED] writes: Martin Dickopp [EMAIL PROTECTED] writes: Thomas Bushnell BSG [EMAIL PROTECTED] writes: If there is a reason to separate /usr from / (which so many people think there is, though I don't understand why, since it has no semantic significance at all), why separate /lib from /etc? I don't see a semantic difference between /bin and /usr/bin (or /lib and /usr/lib). IMHO, the only reason for /bin and /lib is that some programs and libraries need to be available before is /usr is mounted. That doesn't make sense. If you get rid of the /usr vs / distinction, then there is no before /usr is mounted. But then you have a minimum 1-5GB /. That sucks. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
Goswin von Brederlow [EMAIL PROTECTED] writes: That doesn't make sense. If you get rid of the /usr vs / distinction, then there is no before /usr is mounted. But then you have a minimum 1-5GB /. That sucks. Why, exactly? I know people think it's obvious, but the lack of stated reasons worries me. I know the *original* reasons why / needed to be small, but they don't apply anymore. So I'll buy the it's obvious if you can state the original reasons and explain why you think they still apply. If not, then what is the current reason? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
fwd: one hour cas1no payout.
Try your luck with our new brand cas1no. +30% for every diposit. One hour payout, never fast before. Try play for free. When my horse is running good, I don't stop to give him sugar. http://www.wehiuhef.com/ We all have ability. The difference is how we use it. Said will be a little ahead, but done should follow at his heel. to get out please read on page above Acting is the perfect idiot's profession. Not many men have both good fortune and good sense. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
distributed batch processing
Hi all, I am looking at ways to distribute batch jobs on various hosts. Essentially, i have N different command lines, and M different hosts to run them on: foo -i file1.data -p 0.1 foo -i file2.data -p 0.1 foo -i file3.data -p 0.1 ... foo -i file1.data -p 0.2 ... I had a try with 'queue' [1], but it seems rather obsolete now. I am now seeking recent alternatives. I went across a few solutions, such as DQS [2] (non-free, unmaintained), OpenPBS [3] (non-free), and distribulator [4] (looks interesting). Now i feel like i have missed something obvious. Is there a tool out there that i could use as a drop in replacement for queue? cheers, paul [1] http://sourceforge.net/projects/queue/ [1] http://packages.debian.org/stable/admin/dqs [2] http://www.openpbs.org/ [3] http://distribulator.sourceforge.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
Thomas Bushnell BSG [EMAIL PROTECTED] writes: Goswin von Brederlow [EMAIL PROTECTED] writes: That doesn't make sense. If you get rid of the /usr vs / distinction, then there is no before /usr is mounted. But then you have a minimum 1-5GB /. That sucks. Why, exactly? I know people think it's obvious, but the lack of stated reasons worries me. I know the *original* reasons why / needed to be small, but they don't apply anymore. So I'll buy the it's obvious if you can state the original reasons and explain why you think they still apply. If not, then what is the current reason? Thomas - / can't be on lvm, raid0, raid5, reiserfs, xfs without causing problems for /boot. - a larger FS has more chance of failing so you risk having a fully broken system more often - /usr can be easily network (shared accross the same arch) mounted while / (due to /etc) can't - / needs functioning device nodes on it while usr can be mounted nodev - a small / can be replicated across many disks to ensure the system always comes up and e.g. at least send an email to the admin. / can even be an initrd ... MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: packages missing from sarge
On May 8, 2005, at 08:36, Andreas Henriksson wrote: Hi everybody! Although I guess there's no chance for it to make it in, Openswan is the one on my personal wishlist. Seconded! The only RC-bug in openswan is for a newer version of the kernel which will not ship with Sarge. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Test of upgrade from Woody - Sarge
Just a couple of quick notes: the process in general was fairly smooth, though I wouldn't want to have to do it for more than a couple of machines at a time. Hardware: Home build, Celeron 1200, 640M of memory, 40G disk, ATI Radeon video with 128M memory, 3Com 3C905, cheap CMP soundcard, genuine MS PS2 mouse, 17 Dell monitor Pre-existing software: Dual booting Windows XPHome. Woody replaced Kubuntu on second partition, allowed installation to reformat this and swap and to overwrite GRUB with LILO. [Simplest partition layout: 8G for windows as /dev/hda1, 30G for Debian / as /dev/hda2, rest for swap as /dev/hda3] Installation media: Double sided DVD from a couple of years ago from Linux Emporium / internal network from own mirror. Woody install: Installed using bf24 so 2.4 kernel - fairly uneventful, used tasksel for desktop environment and UNIX server profiles. This meant GNOME and KDE and a fairly full desktop. Video too new for Woody: X could be configured badly but KDM kept looping so unusable. Exim3 set up for satellite network with mail handled elsewhere. Updates automatically brought down via ftp from security.debian.org so installed system basically 3.0r5 Updating process: Manual edit of /etc/apt/sources.list and apt-get update ; apt-get dist-upgrade. [NOTE: I'm fairly sure the archive layout changed for non-US/main between Woody - Sarge and I had problems here. Could be a show stopper as not immediately obvious what to change] Dual boot still worked !! [Previously, disk had had GRUB: LILO just worked, over-wrote stuff correctly and booted Windows XP fine. One major source of worry gone :) ] Lots of packages failed on first run: repeated apt-get dist-upgrades gradually sorted out the mess. KDE caused huge problems: in the end, I had to manually run apt-get install kdm, then apt-get install konqueror, then apt-get install kdesktop to gradually get rid of conflicts with KDE2. In the general run of things: Updates to libc produced sane warning messages and stopped/started services correctly. Exim3 - Exim4 produced warning that config might break and configuration needed but that configuration worked correctly. Exim4 config dialog worked well. Locales correctly handled. X Windows stabilised - initial login via KDM brings up GNOME :( Needed to use menu button to force initial KDE :) Usual no sound and nasty /dev/dsp message because user not added to audio group by default. Added user to audio group, Ctrl-Alt-Bksp, and sound came up fine. Update to kernel 2.6 - message about initrd, so moved to second VT and updated /etc/lilo.conf halfway through process (as usual :) ). Reboot and X Windows breaks with frozen cursor in middle of screen because of psmouse.ko rather than psmouse. Insmod /lib/kernel/*/psmouse.ko fixes this but a general fix for the new modules would be good. Didn't try: changing LILO to GRUB. Overall impression: exceedingly good, given that the task is non-trivial. Total time to install a fully loaded Woody system from scratch and then clean update in place with one reboot - approximately 1 1/2 hours. Doing a Woody install again also made me realise just how far we've come in the install process and how much I've come to rely on the new installer just working. HTH, Andy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL and linking
I haven't replied in detail to Batist yet because I am still digesting the hash that Babelfish makes out of his Dutch article. And I don't entirely agree that the GPL is horribly drafted, by comparison with the kind of dog's breakfast that is the typical license contract. In the past, I have tried to draft something with similar legal meaning myself, and on review I did a really lousy job. I have used the GPL, and will probably use it again (emphatically without the upgrade option) the next time it comes up, as the default license under which I provide source code for software I write primarily for a client's internal use, insofar as work made for hire provisions do not apply. As such, I have gone out on quite a limb in this discussion, possibly giving a future legal opponent grounds for estopping me from making certain arguments in a courtroom. So be it. On 5/9/05, Humberto Massa [EMAIL PROTECTED] wrote: [snip] Batist, I think you are mistaken about the meaning of the any later version copyright license... the terms are precisely '' This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. '' and they mean that said program is dually-triply-etc licensed under the GPLv2 or v3 or v4 or any other upcoming FSF-GPL, at the licensee's discretion. I used to think it extroardinarily unlikely that this formula, with regard to as-yet-unwritten offers of contract, would have legal force in any jurisdiction. The prevalence of similar terms in shrink-wrap software licenses nowadays -- which I abhor, and blame directly on RMS, Eben Moglen, and the FSF -- has eroded that confidence to some degree. If it were ever to come up in a court case in which I personally was involved, I envision disputing its validity to the last breath. (I reserve the right to do otherwise, of course.) I am a defender of the GPLv2. I am not a defender of the GPLv3 because I don't know its terms yet... :-) I don't know why would anyone license their work under yet-undisclosed terms, but... I too am a defender of the GPLv2 under an interpretation which I believe to be correct under the law in the jurisdiction in which I reside. As to gambling on future license texts: I find it uncomfortable enough to live in a society in which disputes on all scales are frequently settled by reference to a corpus of law of which no human being can possibly retain more than a small fraction in his or her brain, and which is perpetually being evolved and ramified by legislatures, courts, and unspoken consensus. The existence of persons who would knowingly further complicate their lives by handing over additional liberties to a person who publishes opinions such as http://www.gnu.org/philosophy/enforcing-gpl.html appalls me but has ceased to amaze me. Cheers, - Michael
Re: www.debian.org and users information
On Fri, May 06, 2005 at 01:25:48AM -0500, Adam M. wrote: Kevin Mark wrote: Hi DD folks, Sarge is now approaching zero kelvin and folks are scrambing to get the last few bugs squashed. I was recently thinking about why the non-clued folks bash Debian with incomplete or inaccurate facts and a way to address that. I think there should be a section on the main page that contains links to cluefull faq to clear the FUD and to shed light on That would imply we actually care about the FUD. Having an in-your-face FAQ about all these points would be OK, but people spreading the FUD would not care regardless. There is a group of people that will not read any manual, but think they still know everything regardless. They will look at stable/testing/unstable and proclaim from the bottom of their orifices that they know what these stand for. They will ignore the Debian Reference at http://www.debian.org/doc/manuals/reference/reference.en.html even though it is two clicks away from the main page (click on Docs then the Debian Reference). So the bottom line is people that listen/spreading FUD will probably not be addressed by this FAQ because they are not interested in reading documentation in the first place. However, a single URL to refer to in anti-FUD responses is better than telling people (perhaps open-minded management) to click all over the Debian website. regards Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL and linking
On Mon, May 09, 2005 at 06:25:46PM -0700, Michael K. Edwards wrote: On 5/9/05, Humberto Massa [EMAIL PROTECTED] wrote: [snip] Batist, I think you are mistaken about the meaning of the any later version copyright license... the terms are precisely '' This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. '' and they mean that said program is dually-triply-etc licensed under the GPLv2 or v3 or v4 or any other upcoming FSF-GPL, at the licensee's discretion. I used to think it extroardinarily unlikely that this formula, with regard to as-yet-unwritten offers of contract, would have legal force in any jurisdiction. The prevalence of similar terms in shrink-wrap software licenses nowadays -- which I abhor, and blame directly on RMS, Eben Moglen, and the FSF -- has eroded that confidence to some degree. If it were ever to come up in a court case in which I personally was involved, I envision disputing its validity to the last breath. (I reserve the right to do otherwise, of course.) I'm confused. Why would an optional upgrade clause (party X may offer alternate terms for this software, which you can accept at your option) like the GPL's be used in a shrink-wrap license? I also don't understand why you're so opposed to it. Why should I not be able to say you can distribute under these conditions; in addition, John may offer you a new license in the future, terms which you may accept or ignore? -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cogito_0.10-1 available
On 09-May-2005, Sebastian Kuzminsky wrote: Peter Samuelson [EMAIL PROTECTED] wrote: ] [Sebastian Kuzminsky] ] the shell libraries are moved to /usr/lib/cogito. ] Correct, except that it should be /usr/share/cogito/. The FHS describes /usr/share as architecture-independent data, and gives examples like sound files and icons; this conflicts with executable code in my mind. It could be better described, yes. My understanding of /usr/share as architecture-independent (and read-only, as the description continues) is that /usr/share/can potentially be mounted read-only for multiple machines of different architectures. -- \ The basic fact about human existence is not that it is a | `\ tragedy, but that it is a bore. -- Henry L. Mencken | _o__) | Ben Finney [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: packages missing from sarge
Anthony DeRobertis wrote: Seconded! The only RC-bug in openswan is for a newer version of the kernel which will not ship with Sarge. Doesn't #291274 also affect the 2.6.8 kernel? Also, what of the mail in that bug report stating that even once it's patched to build, it doesn't really work? -- see shy jo signature.asc Description: Digital signature
Re: debian sarge is 3.2 or 4 ?
On Mon, May 09, 2005 at 03:02:32AM -0500, Peter Samuelson wrote: [Kevin Mark] that would suggest that its the RM who has decided such issues in the past unilaterilly. Conventional wisdom is that release management involves so much drudgery and so little recognition that the *least* we can do is let the release manager decide on codenames and version numbers. Hi Peter, I have no difficulty with a decision being made unilaterially. I'd just prefer to have it stated somewhere so that people wont debate something like this near the end of the release cycle and so that folks who are creating dead-tree media would not have worry that things wont be in sync, which would be somewhat detrimental to Debian as not being organized and professional. cheers, Kev -- counter.li.org #238656 -- goto counter.li.org and be counted! `$' $' $ $ _ ,d$$$g$ ,d$$$b. $,d$$$b`$' g$b $,d$$b ,$P' `$ ,$P' `Y$ $$' `$ $ ' `$ $$' `$ $$ $ $$g$ $ $ $ ,$P $ $$ `$g. ,$$ `$$._ _. $ _,g$P $ `$b. ,$$ $$ `Y$$P'$. `YP $$$P' ,$. `Y$$P'$ $. ,$. signature.asc Description: Digital signature
Re: Tricky library packaging question
Hi Enrico, On Mon, May 09, 2005 at 03:06:28PM +0200, Enrico Zini wrote: Now, the ABI, and to a lesser extent the API of the libraries is still not stabilised, so I was planning to package libtagcoll1 and libdebtags1 only as -dev packages. That way, packages would be statically linked to them and a new version of the libraries wouldn't break existing packages. Something similar is being done with libbuffy-dev and buffy, and buffy also has this build-depends line to work a bit around unexpected FTBFS: Build-Depends: ..., libbuffy-dev ( 0.3), libbuffy-dev ( 0.4) this is suboptimal and requires some coordination between the library and its users, but it's ok while there are not many applications using the library. Libbuffy also has python bindings. I could not build them with a package build-depending on libbuffy-dev, as that would not contain PIC code and the python bindings are shared objects. So I build them as part of libbuffy-dev, directly pointing at the .lo files built by libtool during the compilation. Now comes libdebtags. I'm doing the same, however I also depend on libtagcoll1, which is -dev only (and thus not PIC). How do I handle all this? Option 1: - Generate shared libraries, with a shlibs file creating dependencies for an exact version, and put in the description that they are there only to compile the bindings and should not be linked against. Option 2: - Generate -pic packages. Here I need some practical help because I've never done it. I cannot think of any other options. I'm short of clues for the best way of doing this, and I'd be happy to give access to the svn repository of people who could help and work on it together. I imagine these libraries are fairly small, and therefore IMHO there's no real reason to create a separate -pic package for each. However, you do need to provide the library in PIC form if you're going to be linking to it from other packages that provide DSOs (i.e., perl and python modules). I would suggest simply bundling a libfoo_pic.a (static, PIC) library in the respective -dev package. Cheers, -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: /usr/lib vs /usr/libexec
In article [EMAIL PROTECTED] you wrote: - / can't be on lvm, raid0, raid5, reiserfs, xfs without causing problems for /boot. Why is that? - a larger FS has more chance of failing so you risk having a fully broken system more often And two file systems have even more chance. One read only file system is pretty stable. - /usr can be easily network (shared accross the same arch) mounted while / (due to /etc) can't - / needs functioning device nodes on it while usr can be mounted nodev I agreee, those arguments and the netboot stuff is an argment for a smaller root partition. However our root filesystem is too big anyway. Greetings Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#308418: ITP: libytnef -- improved decoder for application/ms-tnef attachments
Package: wnpp Severity: wishlist Owner: Joshua Kwan [EMAIL PROTECTED] * Package name: libytnef Version : 2.6 Upstream Author : Russell Hand [EMAIL PROTECTED] * URL : http://ytnef.sourceforge.net/ * License : GPL Description : improved decoder for application/ms-tnef attachments Yerase's TNEF Stream Reader allows you to decode application/ms-tnef e-mail attachments, which are usually entitled winmail.dat and are generally a file container format that is only readable by Microsoft Outlook. Some TNEF streams also include RTF-formatted data. . libytnef0 is the support library that exposes these functions to other programs. The ytnef program (and eponymous package) is the frontend for this library, so you should probably install that if you want to take advantage of it. and for the -dev package: These are the development headers for libytnef0. (duh!) This kind of supersedes the tnef package in quality, IMO, so I'll be talking to the maintainer Nick Phillips about collaborating on this, though I already have packages ready. Josh -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (499, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.11-ac7 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#308419: ITP: ytnef -- improved decoder for application/ms-tnef attachments
Package: wnpp Severity: wishlist Owner: Joshua Kwan [EMAIL PROTECTED] * Package name: ytnef Version : 1.5 Upstream Author : Russell Hand [EMAIL PROTECTED] * URL : http://ytnef.sourceforge.net/ * License : GPL Description : improved decoder for application/ms-tnef attachments Yerase's TNEF Stream Reader allows you to decode application/ms-tnef e-mail attachments, which are usually entitled winmail.dat and are generally a file container format that is only readable by Microsoft Outlook. Some TNEF streams also include RTF-formatted data. . ytnef parses these streams into normal MIME attachments and RTF attachments that you can read from non-Outlook mail readers. . A convenience script is provided to allow users to transparently filter messages containing TNEF attachments into messages with proper attachments, via procmail. Debs are ready, and I'll be contacting Nick Phillips, maintainer of a similar (but IME inferior) package, about possible collaboration. Josh -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (499, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.11-ac7 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Accepted xrender 0.9.0-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniel Stone wrote: Format: 1.7 Date: Mon, 9 May 2005 15:09:41 +1000 Source: xrender Binary: libxrender1-dbg libxrender-dev libxrender1 Architecture: source i386 Version: 0.9.0-1 Distribution: unstable Urgency: low Maintainer: Daniel Stone [EMAIL PROTECTED] Changed-By: Daniel Stone [EMAIL PROTECTED] Description: libxrender-dev - X Rendering Extension client library (development files) libxrender1 - X Rendering Extension client library libxrender1-dbg - X Rendering Extension client library (unstripped) Closes: 257187 280092 Changes: xrender (0.9.0-1) unstable; urgency=low . * New upstream version. * Adopting package; set Maintainer to myself. * Set includedir to be /usr/X11R6/include with autoconf, not by moving it around, so the pkgconfig file and the libtool library no longer lie (closes: #257187, #280092). * Make libxrender-dev Depend (not B-D) on render-dev = 0.9, for the new protocol version. Files: df7bd9af7ff95cc752981b9d98c8372d 669 x11 optional xrender_0.9.0-1.dsc 8aadb283d417e0f732678fe08469ce6e 309386 x11 optional xrender_0.9.0.orig.tar.gz 14dbb528a203c8b0d8917c15d47deeae 10792 x11 optional xrender_0.9.0-1.diff.gz d26eb33f17033a3d3dacff0ddcbb1d81 26638 libs optional libxrender1_0.9.0-1_i386.deb bedab447958c90d12809b69e6094301e 335856 libdevel extra libxrender1-dbg_0.9.0-1_i386.deb 41ee1307c37bf2c0ec13163ca7b2997c 29860 libdevel optional libxrender-dev_0.9.0-1_i386.deb Hi everybody, For a long while I have been covering the position of Release Manager for the X Strike Force team, as many of you already know. It is a matter of facts that I did NOT resign from that position and that this is *yet another* attempt from Daniel Stone to hijack packages that are co-maintained within the XSF. This upload (together with render) has been violating (at least): 1) Release Managers request of not uploading new major upstream versions of any library. 2) All possible NMU rules. 3) Code of Conduct. but even if i can try to force myself to fly over these major mistakes you did (there are more. like a behaviour change in the library for example...) there is one on which i absolutely cannot close my eyes. You, Daniel, and I have been talking several times on IRC about your position within the XSF. At the end of all these talks, you agreed to stop messing up with the XSF. This is clearly not the case. I find myself in a position for which i cannot trust your words anymore, and I am seriously offended by your behaviour. Both as a person, since you had my full trust, and as part of the XSF, since i still lead this team. Before I will ask the relevant Debian authorities to take appropriate actions to safeguard the community from your destructive behaviour, I want you to explain to the community the rationale behind your hijack, going trough all the points I mentioned above. Regards, Fabio -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCgD/8hCzbekR3nhgRAiHfAKCiu7JXvTaXYBsrMynjWRyU4su9qQCgldtA U6nCSN0L6RhooEyGrkj0Ink= =ybhh -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted r-cran-maps 2.0-27-2 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 9 May 2005 01:05:19 -0500 Source: r-cran-maps Binary: r-cran-maps Architecture: source i386 Version: 2.0-27-2 Distribution: unstable Urgency: low Maintainer: Chris Lawrence [EMAIL PROTECTED] Changed-By: Chris Lawrence [EMAIL PROTECTED] Description: r-cran-maps - GNU R support for producing geographic maps Closes: 307683 Changes: r-cran-maps (2.0-27-2) unstable; urgency=low . * Use mawk, even on platforms where gawk was present when r-base was built. (Closes: #307683) Files: 0c2df5e039f96576cf0883316c7d25ef 614 math optional r-cran-maps_2.0-27-2.dsc 0743498d4f3b19ae52bd1ae2cb7dddcd 2037 math optional r-cran-maps_2.0-27-2.diff.gz b7171cd1ca1385952db5cd453186e942 1486980 math optional r-cran-maps_2.0-27-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCfv3+2wQKE6PXubwRAu0uAKDfJ7XRswc3Wyw0nOJHE04bCZZA0gCbBZkI mnRNrRPW/hTiU8vLS6Z/KEs= =Pj7+ -END PGP SIGNATURE- Accepted: r-cran-maps_2.0-27-2.diff.gz to pool/main/r/r-cran-maps/r-cran-maps_2.0-27-2.diff.gz r-cran-maps_2.0-27-2.dsc to pool/main/r/r-cran-maps/r-cran-maps_2.0-27-2.dsc r-cran-maps_2.0-27-2_i386.deb to pool/main/r/r-cran-maps/r-cran-maps_2.0-27-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted xrender 0.9.0-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 9 May 2005 15:09:41 +1000 Source: xrender Binary: libxrender1-dbg libxrender-dev libxrender1 Architecture: source i386 Version: 0.9.0-1 Distribution: unstable Urgency: low Maintainer: Daniel Stone [EMAIL PROTECTED] Changed-By: Daniel Stone [EMAIL PROTECTED] Description: libxrender-dev - X Rendering Extension client library (development files) libxrender1 - X Rendering Extension client library libxrender1-dbg - X Rendering Extension client library (unstripped) Closes: 257187 280092 Changes: xrender (0.9.0-1) unstable; urgency=low . * New upstream version. * Adopting package; set Maintainer to myself. * Set includedir to be /usr/X11R6/include with autoconf, not by moving it around, so the pkgconfig file and the libtool library no longer lie (closes: #257187, #280092). * Make libxrender-dev Depend (not B-D) on render-dev = 0.9, for the new protocol version. Files: df7bd9af7ff95cc752981b9d98c8372d 669 x11 optional xrender_0.9.0-1.dsc 8aadb283d417e0f732678fe08469ce6e 309386 x11 optional xrender_0.9.0.orig.tar.gz 14dbb528a203c8b0d8917c15d47deeae 10792 x11 optional xrender_0.9.0-1.diff.gz d26eb33f17033a3d3dacff0ddcbb1d81 26638 libs optional libxrender1_0.9.0-1_i386.deb bedab447958c90d12809b69e6094301e 335856 libdevel extra libxrender1-dbg_0.9.0-1_i386.deb 41ee1307c37bf2c0ec13163ca7b2997c 29860 libdevel optional libxrender-dev_0.9.0-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCfwDERkzMgPKxYGwRAg7vAJ4v1wDDJZyyao2lfrN7f+kC1BtA9wCeK0GN K7qa1LHcvtZpH4RSk4mMvng= =ixed -END PGP SIGNATURE- Accepted: libxrender-dev_0.9.0-1_i386.deb to pool/main/x/xrender/libxrender-dev_0.9.0-1_i386.deb libxrender1-dbg_0.9.0-1_i386.deb to pool/main/x/xrender/libxrender1-dbg_0.9.0-1_i386.deb libxrender1_0.9.0-1_i386.deb to pool/main/x/xrender/libxrender1_0.9.0-1_i386.deb xrender_0.9.0-1.diff.gz to pool/main/x/xrender/xrender_0.9.0-1.diff.gz xrender_0.9.0-1.dsc to pool/main/x/xrender/xrender_0.9.0-1.dsc xrender_0.9.0.orig.tar.gz to pool/main/x/xrender/xrender_0.9.0.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted render 0.9-1 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 9 May 2005 15:07:11 +1000 Source: render Binary: render-dev Architecture: source all Version: 0.9-1 Distribution: unstable Urgency: low Maintainer: Daniel Stone [EMAIL PROTECTED] Changed-By: Daniel Stone [EMAIL PROTECTED] Description: render-dev - X Rendering Extension header files and documentation Changes: render (0.9-1) unstable; urgency=low . * New upstream version, including new trap requests. * Adopting package; change Maintainer to myself. Files: 145ce1294c5a679ac8d44be883fb88d5 554 libdevel optional render_0.9-1.dsc ecb76414bb9ade2be1d6f6ef17728b06 83205 libdevel optional render_0.9.orig.tar.gz f2f1e65a1a991e23f16d73aa0b2eda3e 3358 libdevel optional render_0.9-1.diff.gz e587eefdbe854fd9082312289146e1b4 25898 libdevel optional render-dev_0.9-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCfv+qRkzMgPKxYGwRAqEUAJwM6H3AoShCNpuQYxbhE4Ilei0KBQCdF1Sv AvUyj7xSlTGx3K9yoMjZjSg= =/eX6 -END PGP SIGNATURE- Accepted: render-dev_0.9-1_all.deb to pool/main/r/render/render-dev_0.9-1_all.deb render_0.9-1.diff.gz to pool/main/r/render/render_0.9-1.diff.gz render_0.9-1.dsc to pool/main/r/render/render_0.9-1.dsc render_0.9.orig.tar.gz to pool/main/r/render/render_0.9.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted vimoutliner 0.3.3-5 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 7 May 2005 17:01:14 -0400 Source: vimoutliner Binary: vim-vimoutliner Architecture: source all Version: 0.3.3-5 Distribution: unstable Urgency: low Maintainer: Matej Cepl [EMAIL PROTECTED] Changed-By: Matej Cepl [EMAIL PROTECTED] Description: vim-vimoutliner - script for building an outline editor on top of Vim Closes: 307527 307906 Changes: vimoutliner (0.3.3-5) unstable; urgency=low . * Using helpztags instead of internal vim commands (according to vim policy, closes: bug#307527, bug#307906) * Created a global configuration file /etc/vim/vimoutlinerrc, which is read before and in addition to ~/.vimoutlienrrc. * vo_maketags.pl works even when user doesn't have ~/.vimoutliner created (and creates it for him). * do not install useless filetype.vim; vim makes now ftdetect subdirectory working per default. * because of the previous, bump up the minimal version of vim required to 6.3 (available in Debian/sarge). Files: 949276ae88c5b06ce820fff1b84aa12d 651 editors optional vimoutliner_0.3.3-5.dsc 84c11b8df954f13c318ad41f1116261b 29225 editors optional vimoutliner_0.3.3-5.diff.gz 0880fe69d9370b3339fc316d0f18b10f 74718 editors optional vim-vimoutliner_0.3.3-5_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iEYEARECAAYFAkJ/ATYACgkQIgvIgzMMSnXrSwCgtA5mJh3/alxqCig3MqnLssvi L58An29Z3Jp8QQlBSR6jvE+mWdBRx17X =+kZ7 -END PGP SIGNATURE- Accepted: vim-vimoutliner_0.3.3-5_all.deb to pool/main/v/vimoutliner/vim-vimoutliner_0.3.3-5_all.deb vimoutliner_0.3.3-5.diff.gz to pool/main/v/vimoutliner/vimoutliner_0.3.3-5.diff.gz vimoutliner_0.3.3-5.dsc to pool/main/v/vimoutliner/vimoutliner_0.3.3-5.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted watchdog 5.2.4-3 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 8 May 2005 12:48:38 +0200 Source: watchdog Binary: watchdog Architecture: source i386 Version: 5.2.4-3 Distribution: unstable Urgency: medium Maintainer: Michael Meskes [EMAIL PROTECTED] Changed-By: Michael Meskes [EMAIL PROTECTED] Description: watchdog - software watchdog Closes: 259277 300432 Changes: watchdog (5.2.4-3) unstable; urgency=medium . * Changed startup priority to 89, closes: #300432 * Added path to init script, closes: #259277 Files: 373bc612c7aada78637ec67fd5316af0 567 admin extra watchdog_5.2.4-3.dsc 15e2e1985bfd3f6e4942ce2f7bb6fbe6 14147 admin extra watchdog_5.2.4-3.diff.gz bc5f9cdebc12accf7443030bf872716b 57728 admin extra watchdog_5.2.4-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCfwwJVkEm8inxm9ERAmWGAJ9OsxpyqPLcblMYDnWzp3ImytvDzACfR1nQ JMqLc6GiKXR3ylPo641fR+o= =89+i -END PGP SIGNATURE- Accepted: watchdog_5.2.4-3.diff.gz to pool/main/w/watchdog/watchdog_5.2.4-3.diff.gz watchdog_5.2.4-3.dsc to pool/main/w/watchdog/watchdog_5.2.4-3.dsc watchdog_5.2.4-3_i386.deb to pool/main/w/watchdog/watchdog_5.2.4-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted superkaramba 0.35-3 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 9 May 2005 09:12:02 +0200 Source: superkaramba Binary: superkaramba Architecture: source i386 Version: 0.35-3 Distribution: unstable Urgency: high Maintainer: Jean-Michel Kelbert [EMAIL PROTECTED] Changed-By: Jean-Michel Kelbert [EMAIL PROTECTED] Description: superkaramba - A program based on karamba improving the eyecandy of KDE Closes: 304661 Changes: superkaramba (0.35-3) unstable; urgency=high . * Add libxpm-dev to Build-Depends. (Closes: #304661) * Set priority to high, since this is an easy RC bugs. Files: 9c86c160fab12ce8530f4ab205ebb822 650 kde optional superkaramba_0.35-3.dsc f31568ab057fab99a43906260bca2470 27161 kde optional superkaramba_0.35-3.diff.gz 404f50e3019c75f531726c397e2f6812 457344 kde optional superkaramba_0.35-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFCfxBHZA5kLi8vDN4RAvbAAKCBv/NlKc9PamX19klIm7YknoNhVgCfbRuH ORHsbd3gH8CO3E/AOjzDbWY= =XAzR -END PGP SIGNATURE- Accepted: superkaramba_0.35-3.diff.gz to pool/main/s/superkaramba/superkaramba_0.35-3.diff.gz superkaramba_0.35-3.dsc to pool/main/s/superkaramba/superkaramba_0.35-3.dsc superkaramba_0.35-3_i386.deb to pool/main/s/superkaramba/superkaramba_0.35-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted roxen4 4.0.325-2 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 9 May 2005 07:42:13 +0200 Source: roxen4 Binary: roxen4-doc roxen4 Architecture: source i386 all Version: 4.0.325-2 Distribution: unstable Urgency: low Maintainer: Turbo Fredriksson [EMAIL PROTECTED] Changed-By: Turbo Fredriksson [EMAIL PROTECTED] Description: roxen4 - The Roxen Challenger Webserver roxen4-doc - Roxen 4.0 documentation Closes: 304312 306105 Changes: roxen4 (4.0.325-2) unstable; urgency=low . * Updated french po-debconf translation. Patch by Nicolas Bertolissio. Closes: #306105 * Provide 'httpd-cgi'. Closes: #304312 * Slight rearrangement of what files is in what patch. * Start the internal MySQL as 'www-data', not root (this so that roxen have the right to connect via the socket). * Default logdirprefix = '/var/log/roxen4/'. * Cleanup (and add an option) to the init.d script to do a simple restart. * Load the documentation database to the MySQL database at roxen4-doc installation so we don't have to restart roxen to get documentation. Required a postinst for the roxen4-doc package. Files: ac8f239ed7cd98ec973545f821c6b3fd 581 web optional roxen4_4.0.325-2.dsc c994c3f16f41560b3108272baae0ddca 48094 web optional roxen4_4.0.325-2.diff.gz d98cadebc6fa283c6ea38cfd15e23ec2 350 doc optional roxen4-doc_4.0.325-2_all.deb ff27e2079ef1a9a39c2a183b701315d8 7700572 web optional roxen4_4.0.325-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFCfxa3mlWzPKccHgARAlFYAJoDKf/+Vhh7qpNz/kFIMXspuM7/RACdEoJ9 nHyRnYJYP5Bkr7//QqTKrR0= =kJ6V -END PGP SIGNATURE- Accepted: roxen4-doc_4.0.325-2_all.deb to pool/main/r/roxen4/roxen4-doc_4.0.325-2_all.deb roxen4_4.0.325-2.diff.gz to pool/main/r/roxen4/roxen4_4.0.325-2.diff.gz roxen4_4.0.325-2.dsc to pool/main/r/roxen4/roxen4_4.0.325-2.dsc roxen4_4.0.325-2_i386.deb to pool/main/r/roxen4/roxen4_4.0.325-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted cvm 0.33-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 8 May 2005 20:36:21 + Source: cvm Binary: cvm cvm-pgsql cvm-mysql cvm-dev Architecture: source i386 Version: 0.33-1 Distribution: unstable Urgency: low Maintainer: Gerrit Pape [EMAIL PROTECTED] Changed-By: Gerrit Pape [EMAIL PROTECTED] Description: cvm- Credential Validation Modules cvm-dev- Credential Validation Modules (development files, documentation) cvm-mysql - Credential Validation Modules (mysql) cvm-pgsql - Credential Validation Modules (postgresql) Changes: cvm (0.33-1) unstable; urgency=low . * new upstream version. * debian/cvm-pwfile.8: merge changes from upstream cvm-pwfile.html. * debian/diff/ld.diff: adapt. Files: 0cdd4fff8af2fe58081639e7b1beaebf 693 - optional cvm_0.33-1.dsc f29b3983fe8cafad2d6b95073f4b1bb3 73051 - optional cvm_0.33.orig.tar.gz f00a5a55b53b0f208e6d5833d7d7db2b 8693 - optional cvm_0.33-1.diff.gz 069c9a85271ff78d3021897b82a8efb4 62106 libdevel optional cvm-dev_0.33-1_i386.deb f59d6fb5ea718c38ac7f48b219891257 69068 admin optional cvm_0.33-1_i386.deb 9dd9b3166bf90a8d726c7cdf152fcb31 30592 admin optional cvm-mysql_0.33-1_i386.deb de984c43364b1f1b0b5a800b448b74b2 30540 admin optional cvm-pgsql_0.33-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCfnu7GJoyQbxwpv8RAkjTAJ4vQMpjcL4ZQmImBIpOsjU6NrRrhQCfScTj lrf65R2WNDyHlzYovLmi7+o= =uvix -END PGP SIGNATURE- Accepted: cvm-dev_0.33-1_i386.deb to pool/main/c/cvm/cvm-dev_0.33-1_i386.deb cvm-mysql_0.33-1_i386.deb to pool/main/c/cvm/cvm-mysql_0.33-1_i386.deb cvm-pgsql_0.33-1_i386.deb to pool/main/c/cvm/cvm-pgsql_0.33-1_i386.deb cvm_0.33-1.diff.gz to pool/main/c/cvm/cvm_0.33-1.diff.gz cvm_0.33-1.dsc to pool/main/c/cvm/cvm_0.33-1.dsc cvm_0.33-1_i386.deb to pool/main/c/cvm/cvm_0.33-1_i386.deb cvm_0.33.orig.tar.gz to pool/main/c/cvm/cvm_0.33.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted runit 1.2.3-1 (source ia64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 8 May 2005 17:49:37 + Source: runit Binary: runit Architecture: source ia64 Version: 1.2.3-1 Distribution: unstable Urgency: low Maintainer: Gerrit Pape [EMAIL PROTECTED] Changed-By: Gerrit Pape [EMAIL PROTECTED] Description: runit - a UNIX init scheme with service supervision Changes: runit (1.2.3-1) unstable; urgency=low . * new upstream version. * debian/copyright: 2005. * debian/control: Suggests: fgetty. * debian/getty-tty5.run: use fgetty if available. * debian/diff/runsv.8.diff: new; fix typo in man page. * debian/rules: target unpack: apply diff; install debian/getty-tty5.run, debian/getty-tty5.finish. Files: d2bfce12c8d8e19770829f7b01b3807a 625 admin optional runit_1.2.3-1.dsc 0162528dde938f84e58521efe6cf4682 91487 admin optional runit_1.2.3.orig.tar.gz aeb4fa556e5985459180133cbb014427 7894 admin optional runit_1.2.3-1.diff.gz 3760e57151ccebb348cfdf9b6e4dd33f 148272 admin optional runit_1.2.3-1_ia64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCfngIGJoyQbxwpv8RAkuDAKCVVa2B6tupe0c29PEJ4EjG+hgbGwCfemiM WSlTr9zrSQG6RbsnXM7omJo= =Cd4x -END PGP SIGNATURE- Accepted: runit_1.2.3-1.diff.gz to pool/main/r/runit/runit_1.2.3-1.diff.gz runit_1.2.3-1.dsc to pool/main/r/runit/runit_1.2.3-1.dsc runit_1.2.3-1_ia64.deb to pool/main/r/runit/runit_1.2.3-1_ia64.deb runit_1.2.3.orig.tar.gz to pool/main/r/runit/runit_1.2.3.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted enigma 0.91-2 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 09 May 2005 01:27:47 -0700 Source: enigma Binary: enigma enigma-data Architecture: source i386 all Version: 0.91-2 Distribution: unstable Urgency: low Maintainer: [EMAIL PROTECTED] Changed-By: Erich Schubert [EMAIL PROTECTED] Description: enigma - A game where you control a marble with the mouse enigma-data - Data file for the game enigma Closes: 308244 Changes: enigma (0.91-2) unstable; urgency=low . * Rebuild in my clean sid chroot. (Closes: #308244) Files: 9dba68bf43230165a8b095680b5f9c26 738 games optional enigma_0.91-2.dsc 5147e23f1b46c149144cbf168e4ef8c4 39916 games optional enigma_0.91-2.diff.gz efef866cbaf63d789bbe6fe323020a5a 9485386 games optional enigma-data_0.91-2_all.deb 57a10adce1acc852b793c707d3431ad5 1432056 games optional enigma_0.91-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCfyQAntB470s6E1wRAsK2AJ9jjOt/BJBVU1HVqterTdQMUzYfAgCgi4pF XAspl2NCAoqdWFpYzNxpqyI= =TcfF -END PGP SIGNATURE- Accepted: enigma-data_0.91-2_all.deb to pool/main/e/enigma/enigma-data_0.91-2_all.deb enigma_0.91-2.diff.gz to pool/main/e/enigma/enigma_0.91-2.diff.gz enigma_0.91-2.dsc to pool/main/e/enigma/enigma_0.91-2.dsc enigma_0.91-2_i386.deb to pool/main/e/enigma/enigma_0.91-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted pyid3lib 0.5.1-5 (powerpc all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 9 May 2005 10:38:43 +0200 Source: pyid3lib Binary: python2.4-id3lib python2.2-id3lib python2.3-id3lib python-id3lib Architecture: source powerpc all Version: 0.5.1-5 Distribution: unstable Urgency: low Maintainer: Jonas Smedegaard [EMAIL PROTECTED] Changed-By: Jonas Smedegaard [EMAIL PROTECTED] Description: python-id3lib - id3lib wrapper for Python - dummy package python2.2-id3lib - id3lib wrapper for Python - library python2.3-id3lib - id3lib wrapper for Python - library python2.4-id3lib - id3lib wrapper for Python - library Closes: 308222 308225 Changes: pyid3lib (0.5.1-5) unstable; urgency=low . * Fix default of cdbs snippet to only build simple python packages if no properly named library packages are found. Closes: bug#308222, #308225 (thanks to Philipp Weis [EMAIL PROTECTED] and Michal Politowski [EMAIL PROTECTED]). Files: 7d9387836da9c1556cab3a8ae591dcb9 754 python optional pyid3lib_0.5.1-5.dsc bf4a20874b9016ce4972e56c97f618ad 4085 python optional pyid3lib_0.5.1-5.diff.gz 0239966f8a5d760269a1a607b9107f9a 9956 python optional python-id3lib_0.5.1-5_all.deb 217532efd1b92ff17d0be971055e6ca9 26538 python optional python2.2-id3lib_0.5.1-5_powerpc.deb 4f5de80981f4106ff88b2ab036a8 26568 python optional python2.3-id3lib_0.5.1-5_powerpc.deb 63db08e32d873ce32aece514b523b1e0 26572 python optional python2.4-id3lib_0.5.1-5_powerpc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCfyUCn7DbMsAkQLgRAijiAJ0SPgoz0W48ToCgX7n8gCnzUGc/8gCfebD2 DDq5/FcVaZYPsYFqJTsuxgQ= =bLG5 -END PGP SIGNATURE- Accepted: pyid3lib_0.5.1-5.diff.gz to pool/main/p/pyid3lib/pyid3lib_0.5.1-5.diff.gz pyid3lib_0.5.1-5.dsc to pool/main/p/pyid3lib/pyid3lib_0.5.1-5.dsc python-id3lib_0.5.1-5_all.deb to pool/main/p/pyid3lib/python-id3lib_0.5.1-5_all.deb python2.2-id3lib_0.5.1-5_powerpc.deb to pool/main/p/pyid3lib/python2.2-id3lib_0.5.1-5_powerpc.deb python2.3-id3lib_0.5.1-5_powerpc.deb to pool/main/p/pyid3lib/python2.3-id3lib_0.5.1-5_powerpc.deb python2.4-id3lib_0.5.1-5_powerpc.deb to pool/main/p/pyid3lib/python2.4-id3lib_0.5.1-5_powerpc.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted php4 4:4.3.10-15 (powerpc i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 9 May 2005 02:13:19 -0600 Source: php4 Binary: php4-cgi php4-sybase php4-recode libapache-mod-php4 php4-cli php4-dev libapache2-mod-php4 php4-snmp php4-odbc php4-xslt php4-mysql php4-domxml php4-gd php4-ldap php4-imap php4-common php4-curl php4 php4-pear php4-mcal php4-mhash Architecture: all i386 powerpc source Version: 4:4.3.10-15 Distribution: unstable Urgency: low Maintainer: Adam Conrad [EMAIL PROTECTED] Changed-By: Adam Conrad [EMAIL PROTECTED] Description: libapache-mod-php4 - server-side, HTML-embedded scripting language (apache 1.3 module) libapache2-mod-php4 - server-side, HTML-embedded scripting language (apache 2.0 module) php4-cgi - server-side, HTML-embedded scripting language (CGI binary) php4-cli - command-line interpreter for the php4 scripting language php4-common - Common files for packages built from the php4 source php4-curl - CURL module for php4 php4-dev - Files for PHP4 module development php4-domxml - XMLv2 module for php4 php4-gd- GD module for php4 php4-imap - IMAP module for php4 php4-ldap - LDAP module for php4 php4-mcal - MCAL calendar module for php4 php4-mhash - MHASH module for php4 php4-mysql - MySQL module for php4 php4-odbc - ODBC module for php4 php4-recode - Character recoding module for php4 php4-snmp - SNMP module for php4 php4-sybase - Sybase / MS SQL Server module for php4 php4-xslt - XSLT module for php4 Changes: php4 (4:4.3.10-15) unstable; urgency=low . * Bring back the shipping of /usr/share/doc symlinks in our packages, as this, in concert with moving the migration detection from preinst to postinst (which was done in the last upload), seems to give us the sanest upgrade path. Thanks to Steve Langasek for smacking me around with unpack/upgrade scenarios for a while to convince me of this. Files: 024b3d3e3fd51c1e64c0101fc463ce91 27144 web optional php4-odbc_4.3.10-15_i386.deb 0c33d09adb5b28a965748fa43c7eef50 19942 web optional php4-ldap_4.3.10-15_i386.deb 12b8e607f011f969b29353dc7b17003e 325162 devel optional php4-dev_4.3.10-15_i386.deb 180a58ced9611a39bd8081bf5471d85e 325192 devel optional php4-dev_4.3.10-15_powerpc.deb 19f6907576114377f3964113b255b666 37706 web optional php4-imap_4.3.10-15_powerpc.deb 1e2514092b31c3f6dce735bd22ac1a53 1646628 web optional php4-cli_4.3.10-15_powerpc.deb 2058f8ef25a848532f3f659edce70b86 22614 web optional php4-mysql_4.3.10-15_powerpc.deb 271f417131c3f02c8ca74e860628f9c8 34530 web optional php4-gd_4.3.10-15_powerpc.deb 29c0062ea70b8bf7145da9907ef62a5d 3208900 web optional php4-cgi_4.3.10-15_i386.deb 2c5a2a54b7d8e036582749fd9f42f304 32380 web optional php4-gd_4.3.10-15_i386.deb 52c28ab44ae8d3000f17456172cd7e3c 17676 web optional php4-mcal_4.3.10-15_i386.deb 54a099e73072453a11aaa028d6297cbc 167436 web optional php4-common_4.3.10-15_powerpc.deb 592ef1caf9235c19d16b60be3529e0aa 23046 web optional php4-sybase_4.3.10-15_powerpc.deb 5e0da0c0509e521c738fca3ff34e2b4f 8040 web optional php4-mhash_4.3.10-15_i386.deb 617ea137d06d0713ffcbb2154decff51 167410 web optional php4-common_4.3.10-15_i386.deb 662601098a9ca5e1699a90765bbc690d 1661142 web optional libapache-mod-php4_4.3.10-15_powerpc.deb 6ee239c5bb4091abf68fddb83e23b65b 3280898 web optional php4-cgi_4.3.10-15_powerpc.deb 7089fb13e1cad52b43e879c29a6ebe90 18284 web optional php4-xslt_4.3.10-15_powerpc.deb 7595ea54bb5e374e5a83d79188900c3d 1614228 web optional libapache-mod-php4_4.3.10-15_i386.deb 85b1ffd28241ef1d5ce3f13d7c1660f2 9588 web optional php4-mhash_4.3.10-15_powerpc.deb 86d4c5c612b32cf63b9bb8550ca64581 1609418 web optional php4-cli_4.3.10-15_i386.deb 8742e99699d7197ed9dbc77165a6db8f 1144 web optional php4_4.3.10-15_all.deb 91a086d5fa18f9f09bec9238b4e4291d 19742 web optional php4-mcal_4.3.10-15_powerpc.deb 96779e90626c88894ad5c125cd1e77ec 21216 web optional php4-mysql_4.3.10-15_i386.deb 9a3e73e14bc72799afae64d8d96e3398 1611908 web optional libapache2-mod-php4_4.3.10-15_i386.deb 9d82a0edeee8f7a64c8b336fedb406ac 37230 web optional php4-domxml_4.3.10-15_i386.deb a6496357cb8b4c315f983ab3f9aeead3 21376 web optional php4-sybase_4.3.10-15_i386.deb ad4f056e03e069e9417c13915ef5bfff 16400 web optional php4-xslt_4.3.10-15_i386.deb bce2973edb165fedf9c4fd30837d2563 249704 web optional php4-pear_4.3.10-15_all.deb c6c3d0535f723ab5e1d64ceb4dc15e4c 14968 web optional php4-snmp_4.3.10-15_powerpc.deb ce0f57dddef162b645d4a248b143546b 21404 web optional php4-ldap_4.3.10-15_powerpc.deb cf1878e37ab1fa40fffad03efca1e171 9296 web optional php4-recode_4.3.10-15_powerpc.deb d028c3b3cf5f839fb332bdf0eca69d19 37370 web optional php4-imap_4.3.10-15_i386.deb e2be9e1c3abb351a021f3464a327ae4d 28680 web optional php4-odbc_4.3.10-15_powerpc.deb e3faf199f8b2ca58fbb71e871b835fd9 13158 web optional php4-snmp_4.3.10-15_i386.deb e7685015b4d79567c3a8e259e4a8e604 1659174 web optional
Accepted ace 5.4.2.1.0-4 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 8 May 2005 19:30:01 +0200 Source: ace Binary: libkokyu-dev libtao-orbsvcs-dev libace-rmcast-dev libtao1.4 libtao-xtreactor-dev libtao-qtreactor-dev libace-tkreactor5.4 libacexml-dev libace-doc libace-flreactor5.4 libace-tkreactor-dev libace-xtreactor5.4 libciao-dev libace-rmcast5.4 libace-qtreactor-dev libtao-dev libtao-doc libace-qtreactor5.4 libtao-qtreactor1.4 libciao1.4 libkokyu5.4 mpc-ace libace-dev gperf-ace libace-xtreactor-dev libtao-orbsvcs1.4 libtao-xtreactor1.4 libace5.4 libace-flreactor-dev libacexml5.4 Architecture: source all i386 Version: 5.4.2.1.0-4 Distribution: unstable Urgency: high Maintainer: Debian ACE+TAO maintainers [EMAIL PROTECTED] Changed-By: Konstantinos Margaritis [EMAIL PROTECTED] Description: gperf-ace - Perfect hash function generator (ACE version) libace-dev - An Object-Oriented Network Programming Toolkit in C++ libace-doc - Documentation for the ADAPTIVE Communication Environment (ACE) libace-flreactor-dev - GUI Integrated Reactors for ACE: FastLight Reactor (development f libace-flreactor5.4 - GUI Integrated Reactors for ACE: FastLight Reactor libace-qtreactor-dev - GUI Integrated Reactors for ACE: Qt Reactor (development files) libace-qtreactor5.4 - GUI Integrated Reactors for ACE: Qt Reactor libace-rmcast-dev - A reliable multicast library in C++ libace-rmcast5.4 - A reliable multicast library in C++ libace-tkreactor-dev - GUI Integrated Reactors for ACE: Tk Reactor (development files) libace-tkreactor5.4 - GUI Integrated Reactors for ACE: Tk Reactor libace-xtreactor-dev - GUI Integrated Reactors for ACE: Xt Reactor (development files) libace-xtreactor5.4 - GUI Integrated Reactors for ACE: Xt Reactor libace5.4 - An Object-Oriented Network Programming Toolkit in C++ libacexml-dev - ACE XML PARSER Framework (development) libacexml5.4 - ACE XML PARSER Framework (runtime) libciao-dev - CIAO, TAO's implementation of CORBA Component Model (CCM) libciao1.4 - CIAO, TAO's implementation of CORBA Component Model (CCM) libkokyu-dev - Kokyu middleware for TAO libkokyu5.4 - Kokyu middleware for TAO libtao-dev - Development Files for TAO, The ACE ORB libtao-doc - Documentation for TAO, The ACE ORB libtao-orbsvcs-dev - The ACE ORB, an open-source implementation of CORBA ORB libtao-orbsvcs1.4 - The ACE ORB, an open-source implementation of CORBA ORB libtao-qtreactor-dev - GUI Integrated Reactors for TAO: Qt Reactor (development files) libtao-qtreactor1.4 - GUI Integrated Reactors for TAO: Qt Reactor libtao-xtreactor-dev - GUI Integrated Reactors for TAO: Xt Reactor (development files) libtao-xtreactor1.4 - GUI Integrated Reactors for TAO: Xt Reactor (development files) libtao1.4 - The ACE ORB, an open-source implementation of CORBA ORB mpc-ace- A Makefile generator in Perl Closes: 307258 Changes: ace (5.4.2.1.0-4) unstable; urgency=high . * Thomas Girard [EMAIL PROTECTED] - debian/control: o libacexml-dev depends on libace-dev. o libkokyu-dev depends on libace-dev. o libtao-dev depends on libtao1.4. o normalize Depends: and Build-Depends: sections. - debian/ace-config.1 debian/tao-config.1: fix hyphenation problem reported by lintian. - debian/libciao-dev.install: add missing .idl and .pidl files. (Closes: #307258) Files: 56bb88d96f41a605dcc74ddd53f2bf94 1337 devel optional ace_5.4.2.1.0-4.dsc 9652beca2c2ebf179c6dc8c889ad870b 85376 devel optional ace_5.4.2.1.0-4.diff.gz d37d34bc7d2cac030a8985b37936f702 264000 devel optional mpc-ace_5.4.2.1.0-4_all.deb 8da18b387c393211b6984268bb777d10 1652598 doc optional libace-doc_5.4.2.1.0-4_all.deb 79f5d08db689e6c37f3551e66fabaa4f 2313144 doc optional libtao-doc_5.4.2.1.0-4_all.deb 9fe752ad8cc462c3bec81003a6703681 743406 libs optional libace5.4_5.4.2.1.0-4_i386.deb f8f3d14f148bd16d4879e9d12d341333 2515136 libdevel optional libace-dev_5.4.2.1.0-4_i386.deb fcee3acbdb97dc938b6d034149f3cc8f 154126 libs optional libace-rmcast5.4_5.4.2.1.0-4_i386.deb b32fa4c92a0509c31848eee922b71530 193476 libdevel optional libace-rmcast-dev_5.4.2.1.0-4_i386.deb d545b6cd56aa71d41182a3dcc01dc1e6 89088 devel optional gperf-ace_5.4.2.1.0-4_i386.deb f3011279211b6c8a60607e727401f4ef 214984 libs optional libacexml5.4_5.4.2.1.0-4_i386.deb df671a4801167bca015770a4c3987472 296350 libdevel optional libacexml-dev_5.4.2.1.0-4_i386.deb bc20f0d001927e1c0ecad0ac0b08cc7e 146946 libs optional libkokyu5.4_5.4.2.1.0-4_i386.deb b359eb106c0a28fc927e4522f8464ff3 414426 libdevel optional libkokyu-dev_5.4.2.1.0-4_i386.deb 58b14b0690fa25ccbcb4d1a815ab6e6c 3679450 libs optional libtao1.4_5.4.2.1.0-4_i386.deb 4a04b08524bd49b86cdc516f3e12d4c3 931028 libdevel optional libtao-dev_5.4.2.1.0-4_i386.deb 63f95ace7b5303e49d2362c1e2d5b881 10107738 libs optional libtao-orbsvcs1.4_5.4.2.1.0-4_i386.deb d296b6a990c92c5051297420d65aea0c 2170396 libdevel optional
Accepted pinfo 0.6.8-5 (i386 source)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Mon, 9 May 2005 11:11:20 +0200
Source: pinfo
Binary: pinfo
Architecture: source i386
Version: 0.6.8-5
Distribution: unstable
Urgency: high
Maintainer: Bas Zoetekouw [EMAIL PROTECTED]
Changed-By: Bas Zoetekouw [EMAIL PROTECTED]
Description:
pinfo - An alternative info-file viewer
Closes: 220098 290618 296459 305625
Changes:
pinfo (0.6.8-5) unstable; urgency=high
.
* Fixed timestamp skew issue with the building of pinfo.info by removing the
info file from the diff and explicitly building in in debian/rules
(closes: #290618, #296459)
* Fixed building on systems with non-022 umasks by explicitly chmodding the
$(TEMPDIR) dir
* Removed Bugs: and Origin: headers from debian/control
(closes: #220098)
* Fixed spelling errors in man page (closes: #305625)
* Fixed quotes in menu file
* Remove config.{cache,status,log} in clean target
* Boosted the Standards-Version to 3.6.1 (no changes necessary)
Files:
df5f245ea09699dca75e5ab975b95dfd 555 doc optional pinfo_0.6.8-5.dsc
d85fe4bc98939e46238e8c091f18b9c2 10543 doc optional pinfo_0.6.8-5.diff.gz
dce3d48897322c91b7400e61673a5c49 84054 doc optional pinfo_0.6.8-5_i386.deb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)
iD8DBQFCfzZBK67kHwZE+rcRAlxHAKC3KKq7mnjTjaczvdPDAD0jqJv2ZACgoh6C
i3e4WtYMwIChG2tu4xSZWi4=
=OjZ+
-END PGP SIGNATURE-
Accepted:
pinfo_0.6.8-5.diff.gz
to pool/main/p/pinfo/pinfo_0.6.8-5.diff.gz
pinfo_0.6.8-5.dsc
to pool/main/p/pinfo/pinfo_0.6.8-5.dsc
pinfo_0.6.8-5_i386.deb
to pool/main/p/pinfo/pinfo_0.6.8-5_i386.deb
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted kcdlabel 2.13-KDE3-3 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 5 May 2005 20:12:01 -0400 Source: kcdlabel Binary: kcdlabel Architecture: source i386 Version: 2.13-KDE3-3 Distribution: unstable Urgency: low Maintainer: Stephen Gran [EMAIL PROTECTED] Changed-By: Stephen Gran [EMAIL PROTECTED] Description: kcdlabel - CD cover creator for KDE Closes: 276103 Changes: kcdlabel (2.13-KDE3-3) unstable; urgency=low . * Fix two segfaults (save to file and cddb dialog) Much thanks to Frank Lichtenheld [EMAIL PROTECTED] fo finding the fixes (closes: #276103) Files: bc62ba2644d28752beb98cd44783c149 782 kde optional kcdlabel_2.13-KDE3-3.dsc d8b16a45341445ca046b98c6b9d27747 81559 kde optional kcdlabel_2.13-KDE3-3.diff.gz a451029a55de93d1dadd01ff3e8e602e 126580 kde optional kcdlabel_2.13-KDE3-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCfznaSYIMHOpZA44RApb6AJ0XYOV1GekRMh+Lt+ZeSaodAqbjLQCgqHzb pM264L6vIWkVFCjDjZNCIBg= =r8Lk -END PGP SIGNATURE- Accepted: kcdlabel_2.13-KDE3-3.diff.gz to pool/main/k/kcdlabel/kcdlabel_2.13-KDE3-3.diff.gz kcdlabel_2.13-KDE3-3.dsc to pool/main/k/kcdlabel/kcdlabel_2.13-KDE3-3.dsc kcdlabel_2.13-KDE3-3_i386.deb to pool/main/k/kcdlabel/kcdlabel_2.13-KDE3-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted meld 0.9.5-1 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 5 May 2005 21:08:22 +0100 Source: meld Binary: meld Architecture: source all Version: 0.9.5-1 Distribution: unstable Urgency: low Maintainer: Ross Burton [EMAIL PROTECTED] Changed-By: Ross Burton [EMAIL PROTECTED] Description: meld - graphical tool to diff and merge files Closes: 296581 297303 Changes: meld (0.9.5-1) unstable; urgency=low . * New upstream release * Update yelp.diff with changes in CVS * Apply patch from CVS to fix Up/Down toolbar buttons (closes: #296581) * Apply patch from CVS to fix crossed lines (closes: #297303) Files: a49c694ccb2c568b5520b91f7fd87b80 590 gnome optional meld_0.9.5-1.dsc c499eab5f6605b38a9fe510a2c5b7e5c 316674 gnome optional meld_0.9.5.orig.tar.gz dd84c7f8d805ad71ce18ae39406cc256 5917 gnome optional meld_0.9.5-1.diff.gz 466f4f226115ae70f3bdacf0ab37be21 300236 gnome optional meld_0.9.5-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCfz1QLQnkR9C0M98RAlaxAJwOwbG3IRSnDt62S46IljcMTB1TOQCfeFs4 DdaAbnhnZu0FeevtMYID6ME= =37YC -END PGP SIGNATURE- Accepted: meld_0.9.5-1.diff.gz to pool/main/m/meld/meld_0.9.5-1.diff.gz meld_0.9.5-1.dsc to pool/main/m/meld/meld_0.9.5-1.dsc meld_0.9.5-1_all.deb to pool/main/m/meld/meld_0.9.5-1_all.deb meld_0.9.5.orig.tar.gz to pool/main/m/meld/meld_0.9.5.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted roxen-fonts-iso8859-2 0-8 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 9 May 2005 12:46:10 +0200 Source: roxen-fonts-iso8859-2 Binary: roxen-fonts-iso8859-2 Architecture: source all Version: 0-8 Distribution: unstable Urgency: low Maintainer: Turbo Fredriksson [EMAIL PROTECTED] Changed-By: Turbo Fredriksson [EMAIL PROTECTED] Description: roxen-fonts-iso8859-2 - Extra fonts for roxen Closes: 308253 Changes: roxen-fonts-iso8859-2 (0-8) unstable; urgency=low . * Don't have a postinst. It was to Roxen (1.x) centric, and it's quite pointless to have one at all (all it did was update a broken config). Closes: #308253 * Add dependency on roxen4. Files: 75f6c25e91811e32bed58726857d2bba 640 web optional roxen-fonts-iso8859-2_0-8.dsc 31a70144ea45617054cf8d127cc04be8 2825 web optional roxen-fonts-iso8859-2_0-8.diff.gz 1f0a80cfb77cd6beaa32138d500b7476 821406 web optional roxen-fonts-iso8859-2_0-8_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQFCfz+qmlWzPKccHgARAqRjAJsFWnXXk2eOy2oPOypQZi/V6VLYvQCeIB+v YUbigLuORi/eyf4DwXqMqUk= =gQg7 -END PGP SIGNATURE- Accepted: roxen-fonts-iso8859-2_0-8.diff.gz to pool/main/r/roxen-fonts-iso8859-2/roxen-fonts-iso8859-2_0-8.diff.gz roxen-fonts-iso8859-2_0-8.dsc to pool/main/r/roxen-fonts-iso8859-2/roxen-fonts-iso8859-2_0-8.dsc roxen-fonts-iso8859-2_0-8_all.deb to pool/main/r/roxen-fonts-iso8859-2/roxen-fonts-iso8859-2_0-8_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted roxen-fonts-iso8859-1 0-8 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 9 May 2005 12:42:47 +0200 Source: roxen-fonts-iso8859-1 Binary: roxen-fonts-iso8859-1 Architecture: source all Version: 0-8 Distribution: unstable Urgency: low Maintainer: Turbo Fredriksson [EMAIL PROTECTED] Changed-By: Turbo Fredriksson [EMAIL PROTECTED] Description: roxen-fonts-iso8859-1 - Extra fonts for roxen Closes: 308250 Changes: roxen-fonts-iso8859-1 (0-8) unstable; urgency=low . * Don't have a postinst. It was to Roxen (1.x) centric, and it's quite pointless to have one at all (all it did was update a broken config). Closes: #308250 * Add dependency on roxen4. Files: 0816c9bf63a2bfaa9003416dafc6dee6 641 web optional roxen-fonts-iso8859-1_0-8.dsc bca51b6704142c33acde371b7ebe2821 2769 web optional roxen-fonts-iso8859-1_0-8.diff.gz 54680eaf2019640e72aacd9d857ea189 3673512 web optional roxen-fonts-iso8859-1_0-8_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQFCfz8pmlWzPKccHgARAr4VAJ47XVe+SDC77qK6ssdN8rRzrJzyJwCfa8SK GUJvwTq8IO88nU6/PfL3ltA= =mPyd -END PGP SIGNATURE- Accepted: roxen-fonts-iso8859-1_0-8.diff.gz to pool/main/r/roxen-fonts-iso8859-1/roxen-fonts-iso8859-1_0-8.diff.gz roxen-fonts-iso8859-1_0-8.dsc to pool/main/r/roxen-fonts-iso8859-1/roxen-fonts-iso8859-1_0-8.dsc roxen-fonts-iso8859-1_0-8_all.deb to pool/main/r/roxen-fonts-iso8859-1/roxen-fonts-iso8859-1_0-8_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
