[Fwd: I: Debian @ LinuxWorld 2005]
Vogliono una risposta entro il 31 Marzo. Io sar decisamente occupato fino a settembre con il webb.it percui passo volentieri la mano a chi abbia voglia di smazzarsi la presenza Debian al LinuxWorld. Si tratta di organizzare i presenti e compilare i moduli allegati. Qualche fax, un paio di telefonate, etc. Per non generare traffico eccessivo in lista, i due allegati originali si trovano qui: http://people.initd.org/fog/LWE2005_application_DOTORG.pdf http://people.initd.org/fog/broch_dotorg.pdf Buon divetimento, federico -Messaggio originale- Da: Mara Monti - Wireless [mailto:[EMAIL PROTECTED] Inviato: gioved 17 marzo 2005 18.15 A: '[EMAIL PROTECTED]' Oggetto: Debian @ LinuxWorld 2005 Gentile Federico, Come da conversazione telefonica comincio a inviarle la documentazione da far circolare all'interno di Debian per verificare la disponibilit di una vostra partecipazione all'interno di LinuxWorld 2005. Essendo gi stati presenti lo scorso anno, manterremo per voi una opzione per un meeting desk per qualche settimana. In allegato la documentazione e la domanda di ammissione. Sperando di vedervi a maggio la saluto. A presto Mara Monti LinuxWorld Conference Expo Project Manager WIRELESS SRL Viale Monte Rosa 11 20149 Milano Tel. +39 02 48100306 fax +39 02 460015 [EMAIL PROTECTED] www.linuxworldexpo.it -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
sliced bread (was: Debian-Installer rc3 released)
Jesus Climent [EMAIL PROTECTED] wrote: Kudos to Joey and the D-I team for all the effort, dedication and time spent in making D-I one of the best pieces of code ever since the invention of apt and sliced bread. Code? Where's the code? According to DFSG clause 2, you must give me the source code for sliced bread!!!1 Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: sliced bread (was: Debian-Installer rc3 released)
On Thu, 2005-03-24 at 09:19 +0100, Frank Küster wrote: Code? Where's the code? According to DFSG clause 2, you must give me the source code for sliced bread!!!1 You just want your cake, and to eat it too. Or is that something else?? ;-) -- [EMAIL PROTECTED] - www.seigan.org PGP Key fingerprint = 4309 1C58 5143 AFAC F69E 11CD 76FD 56D4 1223 E387
Re: Bug#301081: ITP: mutt-ng -- Mutt next generation (mutt-ng) is a fork of the well-known email client mutt
On Thu, Mar 24, 2005 at 07:39:04AM +0100, Jesus Climent wrote: On Thu, Mar 24, 2005 at 02:33:27PM +1100, Paul Hampson wrote: On the other hand, I'm having a problem with the package, it doesn't include muttng_dotlock, and seems to think my mailspool (mbox in /var/mail) is read-only. (vanilla) Mutt can use it fine. Same problem here. Reported to Norbert but never got deeper into it. Let's try renaming mutt_dotlock to muttng_dotlock ;) I hard-linked muttng_dotlock to mutt_dotlock but it didn't help. I might futz with it later, once I get sick of using vanilla mutt for my Inbox. ^_^ -- --- Paul TBBle Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] No survivors? Then where do the stories come from I wonder? -- Capt. Jack Sparrow, Pirates of the Caribbean This email is licensed to the recipient for non-commercial use, duplication and distribution. --- pgpS6wCdHg6wB.pgp Description: PGP signature
Possible compromise on releasing architectures
The Vancouver meeting concluded that more of the burden of supporting the various architectures needs to be on the port teams, but did not supply a workable way for releases to be made on less popular architectures. Here's a proposal that will hopefully both meet the main desires of the release managers and the port teams. Release architecture: * All FTBFS and architecture specific bugs are release critical * packages must be built on all to propagate to testing Release candidate architecture: * testing managed by port release manager(s) * testing consists of packages that built on the candidate and are in release architecture testing with the same version * testing proposed updates may be needed more often due to changes in dependencies * need a way to propagate architecture specific packages (such as boot loaders) to testing * FTBFS and other architecture specific bugs are release critical if a reasonable[0] patch is in the BTS * Will release if testing is in good shape at release time, or at point release time * stable security team may decide not to provide security support Non-release architecture: * no testing, unstable only [0] When there is a difference on what is reasonable, the technical committee will decide. -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Vancouver meeting - clarifications
Pierre THIERRY wrote: Scribit Anthony Towns dies 23/03/2005 hora 21:52: Pierre THIERRY wrote: - Debian: 11 ports, 9157 packages (sarge) [17593 in sid] Hrm, where are those numbers from? wc -l (modulo the first lines) of the allpackages.txt file on the website Aha, with just a straight wc -l of those, I get: 9163 stable.txt 16371 testing.txt 17463 unstable.txt So looks like sarge above should be woody. Cheers, aj -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: If Debian's too radical for you... [was: NEW handling: About rejects, and kernels]
On Thu, Mar 24, 2005 at 08:49:39AM +0100, Marc Haber wrote: On Thu, 24 Mar 2005 11:13:05 +1100, Matthew Palmer Some would say that this has already happened. Not a fork, per se, but Ubuntu's licencing policy (and the general level-headedness of the people I know who are deeply involved in it) suggests that it may be the refuge you seek. Is it as easy to participate with Ubuntu as it is with Debian? I can't say for sure, since I'm not an Ubuntu contributor, but from what I've read on their website, it doesn't look particularly difficult. Their BTS and communications are open, and they have a documented process for getting upload access, so the basics are there. There appears to be several volunteer contributors already, so I think things are running along there. I guess whether it's as easy as Debian is subjective -- some people will probably find it easier to contribute, and others more difficult, because of the differing styles of the two projects. Those who have a religious objection to our e-mail based BTS, for instance, might find Ubuntu's bugzilla more appealing. grin - Matt signature.asc Description: Digital signature
Re: debian development diagram: major rework!
On Wed, Mar 23, 2005 at 09:05:28PM +0100, Josselin Mouette wrote: Le dimanche 20 mars 2005 à 08:48 -0500, Kevin Mark a écrit : Hi all you folks who have exercised your fingers and eyes because of 'vancouvor', In my quest to see how things work, I have made some major revision to my diagram. http://debian.home.pipeline.com/ the new diagram is newdebian2.png any comment appreciated (before the whole shebang is outdated) Just a comment: the ACCEPTED mail is sent once the package is accepted; your diagram leads to thinking it is sent by the maintainer himself. ACK. cheers, Kev -- counter.li.org #238656 -- goto counter.li.org and be counted! signature.asc Description: Digital signature
Re: Possible compromise on releasing architectures
On Thu, Mar 24, 2005 at 10:12:35AM +0100, Jan Niehusmann wrote: On Thu, Mar 24, 2005 at 12:59:19AM -0800, Blars Blarson wrote: Release candidate architecture: * testing managed by port release manager(s) * testing consists of packages that built on the candidate and are in release architecture testing with the same version Please specify what applies to sources and what to binaries. As I understand your proposal, one would need architecture specific source repositories (as different architectures may have different versions in testing). My proposale included same version. Testing will have the same version if any on all architectures. Testing may be broken by missing packages on the candidate. -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: *** SPAM *** Re: NEW handling: About rejects, and kernels (Was: Re: NEW handling ...)
* Russell Coker ([EMAIL PROTECTED]) [050324 00:35]: On Thursday 24 March 2005 03:40, Theodore Ts'o [EMAIL PROTECTED] wrote: If the free software fanatics succeed in kicking non-free from being supported by Debian assets, such that the FSF documentation were no longer available, I'd probably end up agreeing with you and probably would do what you are considering to do after sarge ships. If it would help, I'd ask you to reconsider. If all the reasonable moderates leave, then all that will be left will be the extremists. Of course an option is always to fork the project. Maybe it's time to have a Debian project that focusses on getting software released as opposed to the Debian that wants to be fanatic. Actually, I believe the Debian project as whole _wants_ to getting software released. That was at least the decision in all GRs where people didn't hide the intents (editorial changes). 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: Bug#301081: ITP: mutt-ng -- Mutt next generation (mutt-ng) is a fork of the well-known email client mutt
On Thursday 24 March 2005 00:09, Petri Latvala wrote: On Wed, Mar 23, 2005 at 07:35:35PM +0100, Elimar Riesebieter wrote: Version : x.y.z Upstream Author : Name [EMAIL PROTECTED] * URL : http://www.example.org/ * License : (GPL, LGPL, BSD, MIT/X, etc.) Didn't feel the need to fill those in? Perhaps a little private reminder had sufficed? I'm tempted to ask Didn't feel the need to be polite?, but then I'd probably have to read another dragged out discussion about how blind people are and how many prospective maintainers have already failed to fill out these fields. Regards, David -- - hallo... wie gehts heute? - *hust* gut *rotz* *keuch* - gott sei dank kommunizieren wir ber ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
Re: NEW handling: About rejects, and kernels (Was: Re: NEW handling ...)
* Raphael Hertzog [EMAIL PROTECTED] [050322 22:39]: I'm also not satisfied with the non-productiveness of the removal of useful documentation. I'm also ashamed that some hardware doesn't work out of the box on Debian because we decided that firmware are software and thus should meet DFSG. However I don't plan to leave Debian because it's just not the right thing to do. I joined Debian because its goal was to satisfy its users... and sadly it turns that some developers forget about that when prefering freeness over the service to our users. I'm sad that you see it this way. But in my eyes freeness is one of our most beneficial services to our users. For those aspects of computer life we and our users are locked into software we (including developers and users) are not allowed to fix, not allowed to see what they do and/or maybe not even allowed to give to others, we (Debian) supply the non-free section in addition to our distribution. I think this is an important service, though one the one hand I'm happy it has lost much of its importance for applications as there are nowadays much more free alternatives, and on the other hand non-free licenses shift a bit into the direction where we are not even allowed to ship them in non-free. But the goal we should aim is still Debian is a free operating system (OS) for your computer. We are about free software. And free software includes the promise for freedom. I'm sick of bloody buggy non-free drivers I'm not allowed to look close enough to have a chance to fix them. I'm sick of software telling me I have to download it for each single computer again instead of once and distributing it. I'm sick of software I'm not able to redistribute to others as I could have to pay for some legal fees, I'm sick of documentation I'm not allowed to merge with the documentation within the code, not allowed to bring in forms I like, or with preposterous demands like not changing the title or adding a 20k text into every manpage or digest sheet. And I really think we have no right to foist such things on our users. Put non-free stuff in non-free, that's what it is for. If we are unable to offer free programs, drivers and documentation, we have no right to hide the next best thing in main. If we are unable to provide what we promised (free stuff) we should at least mark the non-free stuff as non-free stuff, so that our users can make their decision. We need to have a big political shift on that side, or we'll loose more valuable contributors in favor of other distributions... you may not care but I want Debian to stay the central distribution and I don't want that other distributions do a better service to users than us. Has there ever been a time when people did not tell Debian will die instantly (or perhaps only next month) if we do not do what some people say our users consider the better service. Hochachtungsvoll, Bernhard R. Link -- Sendmail is like emacs: A nice operating system, but missing an editor and a MTA. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: If Debian's too radical for you... [was: NEW handling: About rejects, and kernels]
On Thu, 24 Mar 2005 08:50:16 +0100, Marc Haber wrote: Is it as easy to participate with Ubuntu as it is with Debian? In some respects it is easier. For one thing you can become a maintainer there without going through an NM ordeal. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: *seconded* Re: Bits (Nybbles?) from the Vancouver release team meeting
n Wed, Mar 16, 2005 at 10:44:15AM -0500, Kyle McMartin wrote: On Wed, Mar 16, 2005 at 03:06:19PM +, Rob Taylor wrote: Yes, that makes total sense. Would there likely be major objections to this? Even less (likely zero) testing of packages by the maintainer before they upload? This is definitely a serious problem... The binary deb that comes with the source only ensures that the package is buildable on at least one arch. So don't allow for source only uploads, rebuild on the uploaded arch and discard the uploaded binary. -- Guido Famous last words... Oh, I'll just make this one change, rebuild source and upload. --Kyle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: fonts, entiity and konqueror/qt
Processing commands for [EMAIL PROTECTED]: clone 238833 -1 Bug#238833: general: not all fonts contain glyphs for all codepoints Bug 238833 cloned as bug 301194. reassign -1 libqt3c102-mt Bug#301194: general: not all fonts contain glyphs for all codepoints Bug reassigned from package `general' to `libqt3c102-mt'. tag -1 +upstream Bug#301194: general: not all fonts contain glyphs for all codepoints There were no tags set. Tags added: upstream retitle -1 konqueror: Fails to render forall; isin; and; Bug#301194: general: not all fonts contain glyphs for all codepoints Changed Bug title. quit Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#301081: ITP: mutt-ng -- Mutt next generation (mutt-ng) is a fork of the well-known email client mutt
* Jesus Climent wrote: On Thu, Mar 24, 2005 at 02:33:27PM +1100, Paul Hampson wrote: On the other hand, I'm having a problem with the package, it doesn't include muttng_dotlock, and seems to think my mailspool (mbox in /var/mail) is read-only. (vanilla) Mutt can use it fine. Same problem here. Reported to Norbert but never got deeper into it. Let's try renaming mutt_dotlock to muttng_dotlock ;) I did that after your report a while ago, and my last package[0] includes muttng_dotlock. [0]: http://people.debian.org/~nobse/debian/unstable/ Norbert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Possible compromise on releasing architectures
On Thu, Mar 24, 2005 at 12:59:19AM -0800, Blars Blarson wrote: Release candidate architecture: * testing managed by port release manager(s) * testing consists of packages that built on the candidate and are in release architecture testing with the same version Please specify what applies to sources and what to binaries. As I understand your proposal, one would need architecture specific source repositories (as different architectures may have different versions in testing). Jan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#301081: ITP: mutt-ng -- Mutt next generation (mutt-ng) is a fork of the well-known email client mutt
On Thu, Mar 24, 2005 at 10:03:02AM +0100, Norbert Tretkowski wrote: Same problem here. Reported to Norbert but never got deeper into it. Let's try renaming mutt_dotlock to muttng_dotlock ;) I did that after your report a while ago, and my last package[0] includes muttng_dotlock. I was, obviously, the one who never got deeper into the problem. Thanks, Norbert! -- Jesus Climent info:www.pumuki.org Unix SysAdm|Linux User #66350|Debian Developer|2.6.10|Helsinki Finland GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429 7E18 66FC 1D7F 8694 6D69 I never drink ... wine. --Dracula (Dracula) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two thougts about testing
On Tue, Mar 22, 2005 at 10:55:05AM +0100, Erik Schanze wrote: Joerg Friedrich [EMAIL PROTECTED]: reading larger parts of the recent threads triggered by the 'Vancouver proposal' brought me to write this mail. Over the last two years testing became more and more a second (almost) stable distribution instead of being a preparation area for the next release. Now there is even security support it is not a officially supported release. Nevertheless I believe that testing is a good idea. But it suffers from some problems. 1. The number of packages Debian never stopped growing, and there are packages which are unmaintained but they are still in the archive. Hey, if noone is willing to maintain a package, wait a grace period (30 days) and remove it from unstable and testing. If somone needs it, he could step forward and maintain it. This doesn't seem like a very good heuristic to me, and it's not something that's currently a major source of work for the release team. Currently, packages in testing are candidates for removal if they've had release-critical bugs open for more than a week; it doesn't matter if they're orphaned or not. Likewise, if a package *doesn't* have release-critical bugs, it doesn't matter if it's orphaned or not: being orphaned for a month just isn't a good indicator of the utility, or the quality, of the package. Auto-removal of orphaned packages from unstable is also bad if it's an orphaned library that's still needed (which happens often enough). If RC-bugs remain unfixed for a period, I agree with removing, but this is common practice, I think. Perhaps somethimes too slow. ;-) Hmm, 7 days is too slow? Perhaps wnpp websites could be improved to show a ranking list of packages which will be removed soon and why. A Section Removal Candidates in DWN could be also helpful. The thought is to use the new debian-testing-changes mailing list to notify when (and why) packages have been removed from testing. Currently, we don't have any automatic way to notify maintainers of a package's removal from testing, which is bad. I don't think DWN is a good choice here, though; weekly reports won't be a very good starting point for people interested in working on the packages. 2. Unstable to testing migration is one way Packages migrate to testing automaticly, but removal requires manual action. I noticed that some developers work hard to get a package or a specific version into testing, but if a new (rc) bug occurs after the migration, nothing happens. At least optional and extra packages should be removed automaticly if a new rc bug emerges. E.g. if noone claims to fix the bug, an extra package should be removed from testing after one, an optional after two weeks. And also all packages which depend on the buggy one. Again, I don't think there are any grounds for automating this. RC-buggy packages that are clearly expendable do get removed from testing quite quickly. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Development files for manipulating Debian packages
Hello all, Does Debian package management suite provide C APIs for easier program manipulation of .deb files? I am looking for something like RedHat's rpm-devel C API but still in vain... -- Best Regards, Ivan Kirchev [If everything seems under control, you're just not going fast enough.] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Found an http SourceForge archive mirror
|--== Bartosz Fenski aka fEnIo writes: BFaf [1 text/plain; us-ascii (quoted-printable)] BFaf On Wed, Mar 23, 2005 at 11:24:21AM +0100, Free Ekanayaka wrote: For who cares.. I've noticed that my old sf ftp mirror [0] is down/broken/unmaintained. After googling a bit I found a new one: http://sf.gds.tuwien.ac.at/ Thus a debian/watch like: version=2 http://sf.gds.tuwien.ac.at/a/al/alsamodular/ams-(.*)\.tar\.bz2 debian uupdate is working for my ams package. BFaf What about prdownloads.sourceforge.net? Cool! So simple, didn't know about that.. thanks. Would it be the case to add a FAQ to the devscripts documentation? Cheers, Free -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two thougts about testing
Steve Langasek wrote: [snip] Auto-removal of orphaned packages from unstable is also bad if it's an orphaned library that's still needed (which happens often enough). Auto-removal of orphaned (build-)dependency leaves sounds useful. This would also remove orphaned libraries after a while if the library users are also orphaned. Thiemo signature.asc Description: Digital signature
Re: NEW handling: About rejects, and kernels (Was: Re: NEW handling ...)
On Thu, Mar 24, 2005 at 10:59:37AM +0100, Bernhard R. Link wrote: * Raphael Hertzog [EMAIL PROTECTED] [050322 22:39]: I'm also not satisfied with the non-productiveness of the removal of useful documentation. I'm also ashamed that some hardware doesn't work out of the box on Debian because we decided that firmware are software and thus should meet DFSG. [...] I'm sad that you see it this way. But in my eyes freeness is one of our most beneficial services to our users. Please don't rehash old arguments. Nobody has argued that we should put non-free packages into main, but we don't agree on what is free and what isn't for all types of packages. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Getting openswan 2.2.0 back into sarge
Hi all, [Please CC me in replies, I am currently not subscribed to this list.] As some have already noticed, openswan has been removed from testing a while ago, most probably because of bug #291274, which did not apply to package version 2.2.0-4 (the one that has been removed from testing). As 2.3.0 upstream is currently not production quality (this is my personal opinion, since it basically triggers a DoS on 2.2.0 installations, cf. #292132), I did not work on getting it into testing. Of course, I have to admit that I have been lazy in not filing a RC bug report to prevent it from entering testing and fixing this bug. However, it looked like 2.3.1 might get released soon at that time, so I had decided to wait for it and push it into testing as soon as the new upstream is there. At the moment, 2.3.1 is nowhere to be seen and I would really like to have a working (and not DoS-triggering) openswan in testing. My current intention would be to get 2.2.0-4 back into testing, which worked well in all of my own tests (I am still using that particular version on many production boxes) and does not seem to be broken for other users. What is the general opinion on that? with best regards, Rene -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
On Mon, Mar 07, 2005 at 07:31:22AM -0600, John Hasler wrote: Henning Makholm writes: Yes, but we shouldn't act as if it was a _freedom_ problem. If it was deliberately made bloody horribly ugly and painful in order to make changing it difficult, it's a freedom problem. Not really. How NV choose to do stuff is totally up to NV. What we have is source code (yes code that can be compiled) which is unencumbered, we can modify,compile, distribute etc... whether it is _harder_ to modify or not because of choices the _owner/author_ has made or not... is nothing to do with freedom. -- Paul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#295131: JFTR: sdl(glib2.0) vs. wx2.4(glib1.2) only affects scorched3d
On Thu, Mar 24, 2005 at 11:42:48AM +0100, David Schmitt wrote: zion:~# apt-cache showpkg libsdl-mixer1.2 libsdl-net1.2 libsdl1.2debian-all | grep '^ ' | sort -u | cut -d ',' -f 1 /tmp/sdldeps zion:~# apt-cache showpkg libwxgtk2.4 | grep '^ ' | sort -u | cut -d ',' -f 1 /tmp/wxdeps zion:~# diff -u /tmp/sdldeps /tmp/wxdeps | grep '^ ' scorched3d zion:~# It seems that this conflict only affects scorched3d. Yep since nothing else depends on libwxgtk2.4 and libsdl in the same time. Is there a possibility to check for these things on a global level? Thanks David for checking this. I made further checks and here's what I got: [ sid / unstable ] ([EMAIL PROTECTED])~$ldd /usr/lib/libSDL.so libartsc.so.0 = /usr/lib/libartsc.so.0 (0x40103000) libgmodule-2.0.so.0 = /usr/lib/libgmodule-2.0.so.0 (0x40109000) libgthread-2.0.so.0 = /usr/lib/libgthread-2.0.so.0 (0x4010e000) libglib-2.0.so.0 = /usr/lib/libglib-2.0.so.0 (0x40113000) libesd.so.0 = /usr/lib/libesd.so.0 (0x40193000) libaudiofile.so.0 = /usr/lib/libaudiofile.so.0 (0x4019b000) libaudio.so.2 = /usr/lib/libaudio.so.2 (0x401bf000) libXt.so.6 = /usr/X11R6/lib/libXt.so.6 (0x401d4000) libX11.so.6 = /usr/X11R6/lib/libX11.so.6 (0x40226000) libXext.so.6 = /usr/X11R6/lib/libXext.so.6 (0x402ed000) libvga.so.1 = /usr/lib/libvga.so.1 (0x402fb000) libaa.so.1 = /usr/lib/libaa.so.1 (0x4036) libasound.so.2 = /usr/lib/libasound.so.2 (0x4037c000) libm.so.6 = /lib/libm.so.6 (0x4042f000) libdl.so.2 = /lib/libdl.so.2 (0x40452000) libpthread.so.0 = /lib/libpthread.so.0 (0x40455000) libc.so.6 = /lib/libc.so.6 (0x404a6000) libSM.so.6 = /usr/X11R6/lib/libSM.so.6 (0x405d9000) libICE.so.6 = /usr/X11R6/lib/libICE.so.6 (0x405e2000) libncurses.so.5 = /lib/libncurses.so.5 (0x405fa000) libslang.so.1 = /lib/libslang.so.1 (0x40639000) libgpm.so.1 = /usr/lib/libgpm.so.1 (0x406ac000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x8000) ([EMAIL PROTECTED])~$ [ sarge / testing ] ([EMAIL PROTECTED])~$ldd /usr/lib/libSDL.so libm.so.6 = /lib/libm.so.6 (0x400ad000) libdl.so.2 = /lib/libdl.so.2 (0x400cf000) libX11.so.6 = /usr/X11R6/lib/libX11.so.6 (0x400d2000) libXext.so.6 = /usr/X11R6/lib/libXext.so.6 (0x4019a000) libpthread.so.0 = /lib/libpthread.so.0 (0x401a8000) libc.so.6 = /lib/libc.so.6 (0x401f9000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x8000) ([EMAIL PROTECTED])~$ Any reason for such huge disproportions? That's where we got libglib2.0. Scorched3D built on sarge works fine and doesn't link against libglib2.0. I asked some of mine friends using other distros for pasting me output of `ldd /usr/lib/libSDL.so | wc -l` Here are some stats [ we've got in sid 23 ] slackware current - 11 gentoo - 14 (we know this could vary a lot) Also seems that other distros have wxgtk2.4 linked against libglib2.0 and libsdl doesn't linked against any libglib. This way most other distros have scorched3d linked against libglib2.0, but only because wxgtk2.4 and not libsdl. I'm not sure what to do now. Is it possible to link our wxgtk2.4 against glib2.0? Or unlink libsdl from using libglib? regards fEnIo -- ,''`. Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | irc:fEnIo : :' : 32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Poland `. `' phone:+48602383548 | proud Debian maintainer and user `- http://skawina.eu.org | jid:[EMAIL PROTECTED] | rlu:172001 signature.asc Description: Digital signature
Re: Bug#295131: JFTR: sdl(glib2.0) vs. wx2.4(glib1.2) only affects scorched3d
On Thursday 24 March 2005 14:37, Bartosz Fenski aka fEnIo wrote: [analysis skipped] I'm not sure what to do now. Is it possible to link our wxgtk2.4 against glib2.0? Or unlink libsdl from using libglib? I found the cause: libSDL.so from libsdl1.2debian-all links against glib2.0 (and much other stuff) libSDL.so from libsdl1.2debian-alsa: zion:~# ldd /usr/lib/libSDL.so | sort /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x8000) libX11.so.6 = /usr/X11R6/lib/libX11.so.6 (0xb7e7c000) libXext.so.6 = /usr/X11R6/lib/libXext.so.6 (0xb7e6e000) libasound.so.2 = /usr/lib/libasound.so.2 (0xb7dba000) libc.so.6 = /lib/tls/libc.so.6 (0xb7c52000) libdl.so.2 = /lib/tls/libdl.so.2 (0xb7d95000) libm.so.6 = /lib/tls/libm.so.6 (0xb7d98000) libpthread.so.0 = /lib/tls/libpthread.so.0 (0xb7d86000) zion:~# scorched3d loads fine for me now, I could start a game (though textures were messed up). Looking at Depends of libsdl1.2debian-*, a Conflicts: libsdl1.2debian-all, libsdl1.2debian-arts would probably help. Regards, David -- - hallo... wie gehts heute? - *hust* gut *rotz* *keuch* - gott sei dank kommunizieren wir ber ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
Re: Bug#301081: ITP: mutt-ng -- Mutt next generation (mutt-ng) is a fork of the well-known email client mutt
* David Schmitt [Thu, 24 Mar 2005 10:44:31 +0100]: how many prospective maintainers have already failed to fill out these fields. #293361 - reportbug: add reminder to fill fields to the ITP template -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 Don't ask the barber whether you need a haircut. -- Daniel S. Greenberg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian-Installer rc3 released
|| On Wed, 23 Mar 2005 23:53:25 -0500 || Joey Hess [EMAIL PROTECTED] wrote: jh The Debian Installer team is proud to announce the third release candidate jh of the Debian Installer for Debian GNU/Linux Sarge. We love doing this so jh much that we couldn't resist updating the installer one more time before jh the official release of Debian 3.1. Please, resend it to debian-devel-announce too -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - Microsoft gives you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Packages count (was Re: Vancouver meeting - clarifications)
So looks like sarge above should be woody. Oh, yes. I was wondering why I found so few (!) packages, because last time I installed a fresh sarge, some debconf screen told me I could install something like 14K packages... BTW, is there any other distrib that includes officially so many packages? Increasingly, Nowhere man -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Re: Bug#295131: JFTR: sdl(glib2.0) vs. wx2.4(glib1.2) only affects scorched3d
On Thu, Mar 24, 2005 at 03:11:32PM +0100, Josselin Mouette wrote:
[...]
Sarge and sid have the same SDL version. You are basically comparing
libsdl1.2debian-all and libsdl1.2debian-oss.
Yes you're right. I didn't notice that I'm using -all on my box.
Any reason for such huge disproportions? That's where we got libglib2.0.
Scorched3D built on sarge works fine and doesn't link against libglib2.0.
That's an indirect dependency (brought by libarts), that you won't see
if you pass --as-needed to ld. However, this is not enough, as users
having libsdl1.2debian-{all,arts} installed will still get this
dependency at runtime, probably leading to segfaults.
So I suppose that Conflicts: libsdl1.2debian-{all,arts} isn't a solution?
ARTS users won't be able to use Scorched3D then :/
Also seems that other distros have wxgtk2.4 linked against libglib2.0 and
libsdl doesn't linked against any libglib.
This way most other distros have scorched3d linked against libglib2.0, but
only because wxgtk2.4 and not libsdl.
This may be because they are building a GTK+2.0 version of libwxgtk2.4.
I'm not sure what to do now. Is it possible to link our wxgtk2.4 against
glib2.0? Or unlink libsdl from using libglib?
I'm afraid there is no miracle solution. Getting wxgtk2.5 to install
together with wxgtk2.4, if possible, would be a good option. IIRC, it's
possible to rebuild WxWidgets 2.4 against GTK+ 2.x, but it requires
changes in the applications because of the move to UTF8.
Hmm, so I wonder how it's done in other distros where wxwidgets uses
gtk2.x. Or maybe they don't use `apt-cache rdepends libwxgtk2.4`?
regards
fEnIo
--
,''`. Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | irc:fEnIo
: :' : 32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Poland
`. `' phone:+48602383548 | proud Debian maintainer and user
`- http://skawina.eu.org | jid:[EMAIL PROTECTED] | rlu:172001
signature.asc
Description: Digital signature
Re: Bug#295131: JFTR: sdl(glib2.0) vs. wx2.4(glib1.2) only affects scorched3d
Le jeudi 24 mars 2005 à 14:37 +0100, Bartosz Fenski aka fEnIo a écrit :
[ sid / unstable ]
([EMAIL PROTECTED])~$ldd /usr/lib/libSDL.so
libartsc.so.0 = /usr/lib/libartsc.so.0 (0x40103000)
libgmodule-2.0.so.0 = /usr/lib/libgmodule-2.0.so.0 (0x40109000)
libgthread-2.0.so.0 = /usr/lib/libgthread-2.0.so.0 (0x4010e000)
libglib-2.0.so.0 = /usr/lib/libglib-2.0.so.0 (0x40113000)
libesd.so.0 = /usr/lib/libesd.so.0 (0x40193000)
libaudiofile.so.0 = /usr/lib/libaudiofile.so.0 (0x4019b000)
libaudio.so.2 = /usr/lib/libaudio.so.2 (0x401bf000)
libXt.so.6 = /usr/X11R6/lib/libXt.so.6 (0x401d4000)
libX11.so.6 = /usr/X11R6/lib/libX11.so.6 (0x40226000)
libXext.so.6 = /usr/X11R6/lib/libXext.so.6 (0x402ed000)
libvga.so.1 = /usr/lib/libvga.so.1 (0x402fb000)
libaa.so.1 = /usr/lib/libaa.so.1 (0x4036)
libasound.so.2 = /usr/lib/libasound.so.2 (0x4037c000)
libm.so.6 = /lib/libm.so.6 (0x4042f000)
libdl.so.2 = /lib/libdl.so.2 (0x40452000)
libpthread.so.0 = /lib/libpthread.so.0 (0x40455000)
libc.so.6 = /lib/libc.so.6 (0x404a6000)
libSM.so.6 = /usr/X11R6/lib/libSM.so.6 (0x405d9000)
libICE.so.6 = /usr/X11R6/lib/libICE.so.6 (0x405e2000)
libncurses.so.5 = /lib/libncurses.so.5 (0x405fa000)
libslang.so.1 = /lib/libslang.so.1 (0x40639000)
libgpm.so.1 = /usr/lib/libgpm.so.1 (0x406ac000)
/lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x8000)
([EMAIL PROTECTED])~$
[ sarge / testing ]
([EMAIL PROTECTED])~$ldd /usr/lib/libSDL.so
libm.so.6 = /lib/libm.so.6 (0x400ad000)
libdl.so.2 = /lib/libdl.so.2 (0x400cf000)
libX11.so.6 = /usr/X11R6/lib/libX11.so.6 (0x400d2000)
libXext.so.6 = /usr/X11R6/lib/libXext.so.6 (0x4019a000)
libpthread.so.0 = /lib/libpthread.so.0 (0x401a8000)
libc.so.6 = /lib/libc.so.6 (0x401f9000)
/lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x8000)
([EMAIL PROTECTED])~$
Sarge and sid have the same SDL version. You are basically comparing
libsdl1.2debian-all and libsdl1.2debian-oss.
Any reason for such huge disproportions? That's where we got libglib2.0.
Scorched3D built on sarge works fine and doesn't link against libglib2.0.
That's an indirect dependency (brought by libarts), that you won't see
if you pass --as-needed to ld. However, this is not enough, as users
having libsdl1.2debian-{all,arts} installed will still get this
dependency at runtime, probably leading to segfaults.
Also seems that other distros have wxgtk2.4 linked against libglib2.0 and
libsdl doesn't linked against any libglib.
This way most other distros have scorched3d linked against libglib2.0, but
only because wxgtk2.4 and not libsdl.
This may be because they are building a GTK+2.0 version of libwxgtk2.4.
I'm not sure what to do now. Is it possible to link our wxgtk2.4 against
glib2.0? Or unlink libsdl from using libglib?
I'm afraid there is no miracle solution. Getting wxgtk2.5 to install
together with wxgtk2.4, if possible, would be a good option. IIRC, it's
possible to rebuild WxWidgets 2.4 against GTK+ 2.x, but it requires
changes in the applications because of the move to UTF8.
--
.''`. Josselin Mouette/\./\
: :' : [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
`- Debian GNU/Linux -- The power of freedom
Re: Bug#295131: JFTR: sdl(glib2.0) vs. wx2.4(glib1.2) only affects scorched3d
On Thu, 24 Mar 2005, Josselin Mouette wrote: I'm not sure what to do now. Is it possible to link our wxgtk2.4 against glib2.0? Or unlink libsdl from using libglib? I'm afraid there is no miracle solution. Getting wxgtk2.5 to install Miracle? no. Technical, sound, and sane? Yes: Version the symbols properly on all libraries that are going to be used by other libraries. Gnome and Kde should have been doing this since day one, since they are the very definition of library hell. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: HOWTO Help (was: Debian DPL Debate Comments)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alexander Schmehl wrote: I think it is quite short and is missing some quite easy tasks that can be done by nearly everyone. I did the mentioned talk and am about to write the document, because I got asked a couple of times what people can do to help us, so I think there is need for a more detailed document about that. But thanks for the hint anyway; if it is ready, it should be linked from there ;) Please do it. It would help a lot to people like me who are willing to contribute but are confused/scared about the legislations listed into some short docs. Regards, rrs - -- Ritesh Raj Sarraf RESEARCHUT -- http://www.researchut.com Gnupg Key ID: 04F130BC Stealing logic from one person is plagiarism, stealing from many is research. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFCQbOL4Rhi6gTxMLwRArcAAJ9bb+uY1NJxor/3l6fpLj4/7zrUoQCfXwKS sjdLFV7vCVDLywbPrO7gPGs= =pee/ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Idea: about package installation under chroot.
Dear Debian developers, I would like to consult the developer community on the following issue. Here is the story: Debian packages including daemons may be a problem for people installing them via chroot, due to the fact that the packages will typically try to stop and restart the daemons. In fact, this can interact destructively with the system of the server, accidentally killing this or that process. It may also cause the Debian package tools to crash. Installation via chroot can be very useful for embedded systems, and also for diskless machines that boot remotely from a server and mount the root via NFS. If a package is being installed via chroot running in the server it does not really make any sense to try to stop or start daemons. Although most packages do in fact survive this process, in the sense that the installation completes despite some errors when stopping and starting daemons, some do cause the package tools to exit in error, leaving behind a broken package. One example that is particularly troublesome is rwhod. Now, all this can be avoided very simply by a line in the init.d/ script for the daemon, checking that /proc is mounted. Since it will be mounted on normal systems but typically not when using a chroot shell, it serves as a flag to enable the daemon restarting procedure. I am using successfully the following line to fix the situation in the case of the troublesome rwhod package, near the top of the file: test -e /proc/mounts || exit 0 So here are my questions: is there any way in which including a line like this in the init.d/ scripts can be adopted as a standard procedure in the future, for all Debian packages containing daemons? Are there, perhaps, undesirable side effects to this? Is there some other, better solution to this problem? Solving this problem would certainly help people using chroot to install packages and so help to extend the range of applicability and usefulness of Debian. Cheers, Jorge L. deLyra, Associate Professor of Physics The University of Sao Paulo, IFUSP-DFMA For more information: finger [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Call for votes for the Debian Project Leader Election 2005
On Sun, Mar 20, 2005 at 05:24:15PM -0600, Debian Project Secretary wrote: Hi, FIRST CALL FOR VOTES FOR THE DEBIAN PROJECT LEADER ELECTION 2005 = === = === === == === == Votinge period starts 00:00:01 UTC on March 21st, 2005. Votes must be received by 23:59:59 UTC on April 10th, 2005. This vote is being conducted as required by the Debian Constitution. You may see the constitution at http://www.debian.org/devel/constitution. For voting questions contact [EMAIL PROTECTED] HOW TO VOTE Do not erase anything between the lines below and do not change the choice names. In the brackets next to your preferred choice, place a 1. Place a 2 in the brackets next to your next choice. Continue till you reach your last choice. Do not enter a number smaller than 1 or larger than 7. You may skip numbers. You may rank options equally (as long as all choices X you make fall in the range 1= X = 7). To vote no, no matter what rank None Of The Above as more desirable than the unacceptable choices, or You may rank the None Of The Above choice, and leave choices you consider unacceptable blank. Unranked choices are considered equally the least desired choices, and ranked below all ranked choices. (Note: if the None Of The Above choice is unranked, then it is equal to all other unranked choices, if any -- no special consideration is given to the None Of The Above choice by the voting software). Then mail the ballot to: [EMAIL PROTECTED] Don't worry about spacing of the columns or any quote characters () that your reply inserts. NOTE: The vote must be GPG signed (or PGP signed) with your key that is in the Debian keyring. - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- 46348448-74a5-40ae-a651-49704435ae8c [ 3 ] Choice 1: Jonathan Walther [ ] Choice 2: Matthew Garrett [ 2 ] Choice 3: Branden Robinson [ ] Choice 4: Anthony Towns [ ] Choice 5: Angus Lees [ 4 ] Choice 6: Andreas Schuldei [ 1 ] Choice 7: None Of The Above - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- -- The responses to a valid vote shall be signed by the vote key created for this vote. The public key for the vote, signed by the Project secretary, is appended below. -- Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico agi@(inittab.org|debian.org)| en GNU/Linux y software libre Encrypted mail preferred| http://inittab.org Key fingerprint = 9782 04E7 2B75 405C F5E9 0C81 C514 AF8E 4BA4 01C3 signature.asc Description: Digital signature
Bug#77570: Bug #77570 - corrupted *status* file (tagged unreproducible but shloudn't it be closed ?)
Could i close this bug ? This is a followup for bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=77570 Configuring packages ... dpkg: parse error, in file `/var/lib/dpkg/status' near line 22622: invalid package name (character `' not allowed - only letters, digits and -+._ allowed) E: Sub-process /usr/bin/dpkg returned an error code (2) there is a backup of status in /var/backups anyway ... Thanks Alban -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NEW handling: About rejects, and kernels (Was: Re: NEW handling ...)
Hamish Moffatt [EMAIL PROTECTED] writes: Please don't rehash old arguments. Nobody has argued that we should put non-free packages into main, but we don't agree on what is free and what isn't for all types of packages. Actually, nobody from the more lenient side has given a description of what they think the right bounds for freeness are for documentation, and why those bounds should be different than for programs. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#301081: ITP: mutt-ng -- Mutt next generation (mutt-ng) is a fork of the well-known email client mutt
On Thu, 24 Mar 2005 the mental interface of Paul Hampson told: On Wed, Mar 23, 2005 at 08:53:38PM +0100, Per Olofsson wrote: Elimar Riesebieter: Package: wnpp Severity: wishlist Owner: Elimar Riesebieter [EMAIL PROTECTED] * Package name: mutt-ng Also note that Norbert Tretkowski has already created a mutt-ng package, although he doesn't intend to upload it (yet). It is available at http://people.debian.org/~nobse/debian/unstable/. Actually, the site with the test deb files mentions that Norbert has passed the baton to Elimar. On the other hand, I'm having a problem with the package, it doesn't include muttng_dotlock, and seems to think my mailspool (mbox in /var/mail) is read-only. (vanilla) Mutt can use it fine. On the machine the i386-build was done, /var/mail was world-readable (don't flame me), so configure seemed to not build dotlock then. Will be fixed next upload (maybe tonight). Elimar -- Numeric stability is probably not all that important when you're guessing;-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#295131: JFTR: sdl(glib2.0) vs. wx2.4(glib1.2) only affects scorched3d
Le jeudi 24 mars 2005 14:27 -0300, Henrique de Moraes Holschuh a crit : On Thu, 24 Mar 2005, Josselin Mouette wrote: I'm not sure what to do now. Is it possible to link our wxgtk2.4 against glib2.0? Or unlink libsdl from using libglib? I'm afraid there is no miracle solution. Getting wxgtk2.5 to install Miracle? no. Technical, sound, and sane? Yes: Version the symbols properly on all libraries that are going to be used by other libraries. Yes, adding symbol versioning to Glib is definitely an option. It also means rebuilding all of the incriminated libraries. Gnome and Kde should have been doing this since day one, since they are the very definition of library hell. I don't know for KDE, but the core GNOME libraries now retain full binary compatibility in all versions. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Re: Idea: about package installation under chroot.
Le jeudi 24 mars 2005 14:54 -0300, Jorge L. deLyra a crit : Now, all this can be avoided very simply by a line in the init.d/ script for the daemon, checking that /proc is mounted. Since it will be mounted on normal systems but typically not when using a chroot shell, it serves as a flag to enable the daemon restarting procedure. I am using successfully the following line to fix the situation in the case of the troublesome rwhod package, near the top of the file: test -e /proc/mounts || exit 0 I definitely like that idea. I don't know whether we have ports without /proc, but such a check for a chroot would be really nice anyway. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Re: Idea: about package installation under chroot.
Hello! On Thu, Mar 24, 2005 at 02:54:40PM -0300, Jorge L. deLyra wrote: Here is the story: Debian packages including daemons may be a problem for people installing them via chroot, due to the fact that the packages will typically try to stop and restart the daemons. In fact, this can interact destructively with the system of the server, accidentally killing this or that process. It may also cause the Debian package tools to crash. [...] Is there some other, better solution to this problem? echo -e '#!/bin/sh\n\nexit 101' /chroot/usr/sbin/policy-rc.d \ chmod a+x /chroot/usr/sbin/policy-rc.d as mentioned by Steve Langasek in http://lists.debian.org/debian-devel/2005/01/msg01316.html. HTH, Flo signature.asc Description: Digital signature
Re: NEW handling: About rejects, and kernels (Was: Re: NEW handling ...)
Andreas Barth wrote: Actually, I believe the Debian project as whole _wants_ to getting software released. That was at least the decision in all GRs where people didn't hide the intents (editorial changes). Indeed. These types of changes are akin to changing a country's constitution and calling these editorial changes bill. But then again we can always change it back and call the change editorial changes as well. - Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
OPORTUNIDADE
O futuro é você quem faz...Existem boas escolhas a serem feitas... E as conseqüências de suas escolhas é que determinarão os resultados. Você está satisfeito? Como estão suas perspectivas? O que você está fazendo para mudar seu futuro?Comece já seu negócio em casa... Quais são seus sonhos, objetivos e ambições? Estamos em expansão, procurando pessoas de boa visão de negócio e empreendedoras, que queiram algo a mais egostariam de ter um estilo comqualidade de vida. Somos uma multinacional americana com 25 anos no mercado e líder em seu segmento. Recentemente, dois grandes bancos de investimentos, fizeram um aporte de US$ 700 milhões em nosso negócio, e estamos, portanto, em fase de grande expansão.Procuramos profissionais que sejam empreendedores e independentes e que queiram trabalhar, em período parcial ou integral, com treinamento, gerenciamento e formação de pessoas, ou com alguma experiência na área comercial.Gostaríamos de salientar que não somos uma empresa de recolocação.Enfatizamos, também, que não se trata de uma vaga de emprego tradicional (com carteira assinada), e sim de um trabalho autônomo com o suporte de três grandes empresas. O objetivo do nosso contato é convidá-lo para uma reunião de negócios onde serão apresentados a empresa, os nossos parceiros, o plano de carreira, as formas de remuneração e as atividades que você desempenharia. Caso você visualize a diferença do nosso sistema de trabalho daremos continuidade ao processo. Caso tenha interesse, retornecom o titulo "CONFIRMAÇÃO dizendo cidade com telefone para contato que agendaremos uma apresentação. Aguardamos seu retorno.Atenciosamente,Luís Jordão Viva Bem... Sinta se Bem... Se você mudar a sua maneira de pensar, talvez possa mudar a sua vida.
Re: Bug#301083: ITP: libevolution-ruby -- revolution, ruby binding for the evolution mail client
Scripsit David Moreno Garza [EMAIL PROTECTED] Revolution is a little Ruby binding to the excellent Evolution email client. Is it so little that it would be better to include it with the evolution package? -- Henning Makholm Al lykken er i ét ord: Overvægtig!
Re: Let's stop feeding the NVidia cuckoo
Scripsit Paul Hedderly [EMAIL PROTECTED] What we have is source code (yes code that can be compiled) which is unencumbered, we can modify,compile, distribute etc... whether it is _harder_ to modify or not because of choices the _owner/author_ has made or not... is nothing to do with freedom. What you are showing here is that code that can be compiled is not a working defintion of source code. -- Henning Makholm Logic is a system for talking about propositions that can be true or false, or at least enjoy properties that are generalized versions of truth and falsehood. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NEW handling: About rejects, and kernels
Scripsit Hamish Moffatt [EMAIL PROTECTED] Please don't rehash old arguments. Nobody has argued that we should put non-free packages into main, but we don't agree on what is free and what isn't for all types of packages. Do you have any arguments for this that do *not* basically reason backwards from we want this stuff to be in main, freedoms or not? -- Henning Makholm Occam was a medieval old fart. The simplest explanation that fits the facts is always, God did it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: OPORTUNIDADE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Luis Jordo escreveu: :: *O futuro voc quem faz... [...] Looks like a pt_BR SPAM. :o) - -- // // Felipe Augusto van de Wiel (faw) [EMAIL PROTECTED] // GUD-PR / DUG-PR || http://www.debian-pr.org // GUD-BR / DUG-BR || http://www.debian-br.org // Debian Project || http://www.debian.org/ // -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQFCQyqqCjAO0JDlykYRAn9dAJ4k1ZZkdIB0IG1hgiNFirYLpCKBpQCgieds mRBCt1KIniKGdsekmQwxy0A= =LWXd -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: discrepancies between uploaded and source-built .deb
Jeroen van Wolffelaar: [Karl Chen:] I didn't know about debdiff - that would have saved me from basically re-implementing it. Common problem unfortunately in the open source/Debian world... not that $what_you_want doesn't exist, but that you just don't know it exists nor where to find it :(. The Debian archive is admirably vast. Out of this free software sea, you can usually fish the one sarge package you need with debram. Debram sorts sarge's 14,000+ packages into broad classes, then divides and redivides them into 470 finer, more specific branches. Debram is part of the Debtags project. Debtags development info here: http://debtags.alioth.debian.org/ pgpy31ZYmlSF3.pgp Description: PGP signature
Re: Idea: about package installation under chroot.
Scripsit Jorge L. deLyra [EMAIL PROTECTED] Although most packages do in fact survive this process, in the sense that the installation completes despite some errors when stopping and starting daemons, some do cause the package tools to exit in error, leaving behind a broken package. One example that is particularly troublesome is rwhod. ... Is there some other, better solution to this problem? Write a policy-rc.d script for the chroot that denies starting either the particular demon or all demons in general. zless /usr/share/doc/sysv-rc/README.policy-rc.d.gz -- Henning Makholm What has it got in its pocketses? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting openswan 2.2.0 back into sarge
Rene Mayrhofer wrote: Hi all, [Please CC me in replies, I am currently not subscribed to this list.] As some have already noticed, openswan has been removed from testing a while ago, most probably because of bug #291274, which did not apply to package version 2.2.0-4 (the one that has been removed from testing). As 2.3.0 You should have tagged the RC bug Sid. upstream is currently not production quality (this is my personal opinion, since it basically triggers a DoS on 2.2.0 installations, cf. #292132), I did Doesn't this mean that 2.2.0 is NOT release quality? It is a security problem if you can trigger a DoS on a package. not work on getting it into testing. Of course, I have to admit that I have been lazy in not filing a RC bug report to prevent it from entering testing and fixing this bug. However, it looked like 2.3.1 might get released soon at that time, so I had decided to wait for it and push it into testing as soon as the new upstream is there. At the moment, 2.3.1 is nowhere to be seen and I would really like to have a working (and not DoS-triggering) openswan in testing. My current intention would be to get 2.2.0-4 back into testing, which worked well in all of my own tests (I am still using that particular version on many production boxes) and does not seem to be broken for other users. What is the general opinion on that? The first step is to remove the current version from testing if it is not production quality. The second step is to locate the DoS problem in 2.2.0 The final step is to upload 1:2.2.0 or similar to unstable and wait for it to get to testing. - Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Idea: about package installation under chroot.
Write a policy-rc.d script for the chroot that denies starting either the particular demon or all demons in general. zless /usr/share/doc/sysv-rc/README.policy-rc.d.gz I was not aware of this structure, but it seems to relate to controlling the start of damons during boot or changes in runlevel. I do not see how this will prevent a package that has a /etc/init.d/daemon start in its postinstall script to start that daemon. I was not talking about booting a system, but about using a chroot shell to install packages in the filesystem structure of a remotely-booted machine. In this situation one does not want to prevent the machine from starting daemons when it boots, just to prevent package installations or upgrades from stoping or starting daemons, when they are done in the disk server, by means of a chroot shell. Cheers, Jorge L. deLyra, Associate Professor of Physics The University of Sao Paulo, IFUSP-DFMA For more information: finger [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#301081: ITP: mutt-ng -- Mutt next generation (mutt-ng) is a fork of the well-known email client mutt
* Elimar Riesebieter: Differences between mutt and mutt-ng: You should make clear that this list of features compares the mutt and mutt-ng packages (I hope it does). Debian's mutt package contains some of the mutt-ng patches. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Idea: about package installation under chroot.
Josselin Mouette wrote: I don't know whether we have ports without /proc, the Hurd has no /proc. Regards, Daniel -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Idea: about package installation under chroot.
On Thu, 24 Mar 2005, Jorge L. deLyra wrote: Write a policy-rc.d script for the chroot that denies starting either the particular demon or all demons in general. zless /usr/share/doc/sysv-rc/README.policy-rc.d.gz I was not aware of this structure, but it seems to relate to controlling the start of damons during boot or changes in runlevel. I do not see how this will prevent a package that has a /etc/init.d/daemon start in its postinstall script to start that daemon. It won't, but thankfully there are fewer and fewer packages that don't follow the recommendation of Policy 9.3.3.2.[1] If you find such a package, please file a wishlist bug against it requesting that the follow the recommendation of Policy not to call the init scripts directly. Don Armstrong 1: http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.3.3 -- A people living under the perpetual menace of war and invasion is very easy to govern. It demands no social reforms. It does not haggle over expenditures on armaments and military equipment. It pays without discussion, it ruins itself, and that is an excellent thing for the syndicates of financiers and manufacturers for whom patriotic terrors are an abundant source of gain. -- Anatole France http://www.donarmstrong.com http://rzlab.ucr.edu signature.asc Description: Digital signature
Re: Bug#301083: ITP: libevolution-ruby -- revolution, ruby binding for the evolution mail client
On Thu, 2005-03-24 at 17:31 +, Henning Makholm wrote: Scripsit David Moreno Garza [EMAIL PROTECTED] Revolution is a little Ruby binding to the excellent Evolution email client. Is it so little that it would be better to include it with the evolution package? Not quite sure since: a) evolution, IMHO, doesn't need to depend on ruby. b) It is a 3rd-party software, not included officially by Novell. c) It is a ruby module itself, just as other several hundreds. But if evolution's maintainer thinks it could be a good idea (I don't), we can implement it in the near future, yes. -- David Moreno Garza [EMAIL PROTECTED] | http://www.damog.net/ The only way to make your PC go faster is to throw it out a window. GPG: C671257D - 6EF6 C284 C95D 78F6 0B78 FFD3 981C 5FD7 C671 257D -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NEW handling: About rejects, and kernels (Was: Re: NEW handling ...)
On Thu, Mar 24, 2005 at 10:28:36AM -0800, Thomas Bushnell BSG wrote: Hamish Moffatt [EMAIL PROTECTED] writes: Please don't rehash old arguments. Nobody has argued that we should put non-free packages into main, but we don't agree on what is free and what isn't for all types of packages. Actually, nobody from the more lenient side has given a description of what they think the right bounds for freeness are for documentation, and why those bounds should be different than for programs. That may be true for documentation but certainly not for firmware, which has been discussed to death. (Not with a satisfactory outcome, imho.) Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Idea: about package installation under chroot.
On Thu, Mar 24, 2005 at 02:54:40PM -0300, Jorge L. deLyra wrote: Installation via chroot can be very useful for embedded systems, and also for diskless machines that boot remotely from a server and mount the root via NFS. If a package is being installed via chroot running in the server it does not really make any sense to try to stop or start daemons. [...] Now, all this can be avoided very simply by a line in the init.d/ script for the daemon, checking that /proc is mounted. Since it will be mounted on normal systems but typically not when using a chroot shell, it serves as a flag to enable the daemon restarting procedure. FWIW, the Debian-amd64 HOWTO suggests mounting /proc in your i386 chroot too. (Though I don't know what the benefits are.) See: https://alioth.debian.org/docman/view.php/30192/21/debian-amd64-howto.html#id274246 I think this is a good problem to solve though. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Idea: about package installation under chroot.
Jorge L. deLyra [EMAIL PROTECTED] writes: Now, all this can be avoided very simply by a line in the init.d/ script for the daemon, checking that /proc is mounted. Since it will be mounted on normal systems but typically not when using a chroot shell, it serves as a flag to enable the daemon restarting procedure. There is nothing wrong with mounting /proc in a chroot; you should not assume that chroots all lack /proc. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Idea: about package installation under chroot.
I was not aware of this structure, but it seems to relate to controlling the start of damons during boot or changes in runlevel. I do not see how this will prevent a package that has a /etc/init.d/daemon start Well if they do they won't work on file-rc system , so are already broken ... Alban -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] OpenLDAP automatic upgrade
Hi Quanah, On Mon, Mar 21, 2005 at 05:58:01PM -0800, Quanah Gibson-Mount wrote: You can find the patch for adding -q to slapadd on OpenLDAP 2.2 here: http://www.stanford.edu/services/directory/openldap/configuration/openldap-build-42.html Great, thanks! Applied it to the subversion repository. I've been reading back over my notes on the problems OpenLDAP has with BDB 4.3, and I believe that this patch will resolve those issues as well (as long as it is used to load a DB, rather than without the -q flag). The main issue is that the way BDB 4.3 creates transaction logs in the quickload scenario is to use setflags DB_LOG_INMEMORY Okay. Anyway, I guess I'll revert to bdb 4.2 if you made bad experiences with 4.3. As long as OpenLDAP does not need any features from 4.3 why would we want to use it anyway? I would note that it would likely be good for Debian to still include a DB_CONFIG file in the database directory it creates with its OpenLDAP distribution, as the default settings from Sleepycat are entirely too small. Here are some examples. All examples use: 10k entry LDIF file 23 attributes indexed BDB 4.2.52 database bdb as the slapd.conf database 1) DB_CONFIG file with a 384MB cache, and normal slapadd options. ldap-linux0:/db/DBs# time slapadd -l 10k.ldif 30.760u 1.800s 0:36.89 88.2%0+0k 0+0io 13351pf+0w Point taken :) I'll submit this as a bug to not forget about it. I think about using at least 1MB for the cache (stop laughing :-) and at most 10% of the main memory of the system. After all there are still people running slapd on systems with 16MB of memory (our students' hostel server is still running such a system...) Greetings Torsten signature.asc Description: Digital signature
Bug#301260: ITP: achims-guestbook -- php driven guestbook
Package: wnpp Severity: wishlist Owner: Tim Peeler [EMAIL PROTECTED] * Package name: achims-guestbook Version : 2.52 Upstream Author : Achim Winkler [EMAIL PROTECTED] * URL : http://www.lkcc.org:8500/ * License : GPL Description : php driven guestbook Achims Guestbook is a php driven guestbook that relies on text files for storing entries. It has support for ip banning, bad word filters, smileys, and an easy to use administrative interface. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.7-1-k7 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: Idea: about package installation under chroot.
There is nothing wrong with mounting /proc in a chroot; you should not assume that chroots all lack /proc. Yes, I know, and I'm not. But it would be nice if one could prevent the packages from starting the daemons by simply choosing not to mount /proc in the chroot. Cheers, Jorge L. deLyra, Associate Professor of Physics The University of Sao Paulo, IFUSP-DFMA For more information: finger [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Idea: about package installation under chroot.
On Thu, Mar 24, 2005 at 07:42:01PM +0100, Josselin Mouette wrote: Le jeudi 24 mars 2005 ?? 14:54 -0300, Jorge L. deLyra a ??crit : Now, all this can be avoided very simply by a line in the init.d/ script for the daemon, checking that /proc is mounted. Since it will be mounted on normal systems but typically not when using a chroot shell, it serves as a flag to enable the daemon restarting procedure. I am using successfully the following line to fix the situation in the case of the troublesome rwhod package, near the top of the file: test -e /proc/mounts || exit 0 I definitely like that idea. I don't know whether we have ports without /proc, but such a check for a chroot would be really nice anyway. Probably I don't understand the assumption /proc is not mounted in chroot. All my chroots have /proc. There are just too many programs that depends of /proc. I even witnessed a FTBFS of a C++ program that depended of the chroot not having /proc mounted. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Idea: about package installation under chroot.
Jorge L. deLyra [EMAIL PROTECTED] writes: There is nothing wrong with mounting /proc in a chroot; you should not assume that chroots all lack /proc. Yes, I know, and I'm not. But it would be nice if one could prevent the packages from starting the daemons by simply choosing not to mount /proc in the chroot. But you might need /proc. If you are going to tell people to prevent packages from starting daemons, do this in the filesystem, then why not just have an /etc/startdaemons file? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Idea: about package installation under chroot.
I was not aware of this structure, but it seems to relate to controlling the start of damons during boot or changes in runlevel. I do not see how this will prevent a package that has a /etc/init.d/daemon start Well if they do they won't work on file-rc system , so are already broken ... Then there are many such broken packages. I just counted about 40 both in the sarge system closest at hand and in a woody server. The list includes many important packages, see lists below. Looks like this policy has not been followed very much... Cheers, Jorge L. deLyra, Associate Professor of Physics The University of Sao Paulo, IFUSP-DFMA For more information: finger [EMAIL PROTECTED] woody: acct adjtimex anacron and apache at autofs bind console-common cron dqs gom gpm ircd isapnptools junkbuster kbd libc6 linuxlogo lprng makedev mrouted netkit-inetd nfs-common nfs-kernel-server nis ntop ntp-simple ntpdate portmap ppp procps quota rwhod setserial spamassassin ssh sudo sysstat upsd xfs xpilot-server xtell sarge: anacron and apache apache-common at autofs binfmt-support console-common console-tools cron dhcp3-server exim4-base exim4-daemon-light gom hpoj isapnptools libdevmapper1 lprng makedev nbd-client nbd-server netkit-inetd nfs-common nfs-kernel-server nis ntp-server ntpdate nut portmap procps queue quota rsync rwhod setserial ssh sudo wu-ftpd xprt-common xtell -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
This one time, at band camp, Henning Makholm said: Scripsit Paul Hedderly [EMAIL PROTECTED] What we have is source code (yes code that can be compiled) which is unencumbered, we can modify,compile, distribute etc... whether it is _harder_ to modify or not because of choices the _owner/author_ has made or not... is nothing to do with freedom. What you are showing here is that code that can be compiled is not a working defintion of source code. However, code that we can modify,compile, distribute etc and is unencumbered is. Please, folks, it's ugly != it's non-free. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgpTtkazASorU.pgp Description: PGP signature
Re: NEW handling: About rejects, and kernels (Was: Re: NEW handling ...)
On Mar 24, Hamish Moffatt [EMAIL PROTECTED] wrote: That may be true for documentation but certainly not for firmware, which has been discussed to death. (Not with a satisfactory outcome, imho.) And one of the reasons for which licensing for documentation has not been discussed is that most people were not aware of the scope of the editorial changes, so there was no reason to discuss anything. -- ciao, Marco signature.asc Description: Digital signature
Re: Idea: about package installation under chroot.
Is there some other, better solution to this problem? echo -e '#!/bin/sh\n\nexit 101' /chroot/usr/sbin/policy-rc.d \ chmod a+x /chroot/usr/sbin/policy-rc.d as mentioned by Steve Langasek in http://lists.debian.org/debian-devel/2005/01/msg01316.html. OK, I got to this point: if all packages used invoke-rc.d then I could solve my problem with installing packages under chroot by installing a policy-rc.d script that returned 101 if the runlevel is unknown. All I have to do is to mask /var/run, which I already do. Two questions: 1) The command runlevel returns unknown and exits in error, will this error status do something bad to invoke-rc.d? 2) What does invoke-rc.d do if the runlevel is unknown? Maybe I would not have to do anything after all, if the policy was followed. Cheers, Jorge L. deLyra, Associate Professor of Physics The University of Sao Paulo, IFUSP-DFMA For more information: finger [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Idea: about package installation under chroot.
On Thu, 24 Mar 2005, Jorge L. deLyra wrote: nfs-kernel-server This uses invoke-rc.d: invoke-rc.d nfs-kernel-server $act ntp-server invoke-rc.d ntp-server start || exit 0 ntpdate as does this: invoke-rc.d ntpdate start || exit 0 Pray tell, how was this list generated? The three examples that I picked at random all use invoke-rc.d. [Two of which because they use debhelper to do the invoking.] Don Armstrong -- A one-question geek test. If you get the joke, you're a geek: Seen on a California license plate on a VW Beetle: 'FEATURE'... -- Joshua D. Wachs - Natural Intelligence, Inc. http://www.donarmstrong.com http://rzlab.ucr.edu signature.asc Description: Digital signature
Re: Idea: about package installation under chroot.
On Thu, Mar 24, 2005 at 08:58:22PM -0300, Jorge L. deLyra wrote: I was not aware of this structure, but it seems to relate to controlling the start of damons during boot or changes in runlevel. I do not see how this will prevent a package that has a /etc/init.d/daemon start Well if they do they won't work on file-rc system , so are already broken ... Then there are many such broken packages. I just counted about 40 both in the sarge system closest at hand and in a woody server. The list includes many important packages, see lists below. Looks like this policy has not been followed very much... sarge: anacron and apache apache-common at autofs binfmt-support console-common console-tools cron dhcp3-server exim4-base exim4-daemon-light gom hpoj isapnptools libdevmapper1 lprng makedev nbd-client nbd-server netkit-inetd nfs-common nfs-kernel-server nis ntp-server ntpdate nut portmap procps queue quota rsync rwhod setserial ssh sudo wu-ftpd xprt-common xtell At least some of these packages call /etc/init.d/package start *only* if invoke-rc.d cannot be found. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Idea: about package installation under chroot.
But you might need /proc. Well, I am starting to see that this might not be a good way to solve the problem but, still, if you need it, just mount it, and be aware that some daemons may come up and down on the server if you install or upgrade some package in these circumstances. If you do not need it, don't mount it and then do not worry about daemons... If you are going to tell people to prevent packages from starting daemons, do this in the filesystem, then why not just have an /etc/startdaemons file? Well, I suppose you could create this file briefly while doing the install or upgrade, and then delete it. You do not want it there permanently since the remote-boot machine is not to be prevented from starting daemons. Will using this file really work in this way? Cheers, Jorge L. deLyra, Associate Professor of Physics The University of Sao Paulo, IFUSP-DFMA For more information: finger [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Idea: about package installation under chroot.
Jorge L. deLyra [EMAIL PROTECTED] writes: But you might need /proc. Well, I am starting to see that this might not be a good way to solve the problem but, still, if you need it, just mount it, and be aware that some daemons may come up and down on the server if you install or upgrade some package in these circumstances. If you do not need it, don't mount it and then do not worry about daemons... If you are going to tell people to prevent packages from starting daemons, do this in the filesystem, then why not just have an /etc/startdaemons file? Well, I suppose you could create this file briefly while doing the install or upgrade, and then delete it. You do not want it there permanently since the remote-boot machine is not to be prevented from starting daemons. Will using this file really work in this way? I think you miss my point. Rather than keying restart daemons to /proc (who would ever guess that?!), I'm saying create something *new*, that means this is a chroot, don't restart demons. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Idea: about package installation under chroot.
Pray tell, how was this list generated? The three examples that I picked at random all use invoke-rc.d. [Two of which because they use debhelper to do the invoking.] Oh, I see. Looks like I did a poor job here. I just searched for instances of /etc/init.d/something being executed. So, I take it all back... |:-) Cheers, Jorge L. deLyra, Associate Professor of Physics The University of Sao Paulo, IFUSP-DFMA For more information: finger [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Idea: about package installation under chroot.
At least some of these packages call /etc/init.d/package start *only* if invoke-rc.d cannot be found. Ah! This is another way how I miscounted them, since I just seached for instances of /etc/init.d/package being executed... Cheers, Jorge L. deLyra, Associate Professor of Physics The University of Sao Paulo, IFUSP-DFMA For more information: finger [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Idea: about package installation under chroot.
I think you miss my point. Rather than keying restart daemons to /proc (who would ever guess that?!), I'm saying create something *new*, that means this is a chroot, don't restart demons. OK, I read you. Your message gave me the impression that something like it was already in place. That meaning doesn't have to be this is a chroot, but just don't start daemons, for whatever reasons there may be for that in any particular case. It would be nice if we could touch a flag file and prevent packages from starting daemons... Cheers, Jorge L. deLyra, Associate Professor of Physics The University of Sao Paulo, IFUSP-DFMA For more information: finger [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#301083: ITP: libevolution-ruby -- revolution, ruby binding for the evolution mail client
Hi, Adam M. wrote:
Thus, libevelution-ruby doesn't need to depend on Ruby. It only needs to
depend on evolution.
What happens if/when ruby is updated in a non-binary-compatible way?
Or if/when somebody decides to remove ruby since, after all, nothing
depends on it?
If that happens, you have a broken libevolution-ruby on your system.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Idea: about package installation under chroot.
Scripsit Jorge L. deLyra [EMAIL PROTECTED] zless /usr/share/doc/sysv-rc/README.policy-rc.d.gz I was not aware of this structure, but it seems to relate to controlling the start of damons during boot or changes in runlevel. I do not see how this will prevent a package that has a /etc/init.d/daemon start in its postinstall script to start that daemon. As far as I'm aware it's a bug if a package has that in its postinst rather than invoke-rc.d daemon start even though it is not yet mandatory policy. It is, however, strongly recommended (§9.3.3.2). -- Henning Makholm Y'know, I don't want to seem like one of those hackneyed Jews that you see in heartwarming movies. But at times like this, all I can say is 'Oy, gevalt!'
Re: Idea: about package installation under chroot.
Jorge L. deLyra [EMAIL PROTECTED] writes: OK, I read you. Your message gave me the impression that something like it was already in place. That meaning doesn't have to be this is a chroot, but just don't start daemons, for whatever reasons there may be for that in any particular case. It would be nice if we could touch a flag file and prevent packages from starting daemons... Yes, that's basically what I'm suggesting. I'm glad you located this bug; it's a problem will worth fixing. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#301083: ITP: libevolution-ruby -- revolution, ruby binding for the evolution mail client
* Matthias Urlichs [Fri, 25 Mar 2005 01:46:45 +0100]: Hi, Adam M. wrote: Thus, libevelution-ruby doesn't need to depend on Ruby. It only needs to depend on evolution. What happens if/when ruby is updated in a non-binary-compatible way? Or if/when somebody decides to remove ruby since, after all, nothing depends on it? If that happens, you have a broken libevolution-ruby on your system. Also, you can't make updates to the bindings without a full evolution upload, which has to get built in all arches, heavy compilation, etc. -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 Listening to: Mecano - El club de los humildes From the moment I picked your book up until I put it down I was convulsed with laughter. Some day I intend reading it. -- Groucho Marx
Re: Idea: about package installation under chroot.
* Jorge L. deLyra [Thu, 24 Mar 2005 14:54:40 -0300]: test -e /proc/mounts || exit 0 Others have already pointed out that a policy-rc.d script is the way to do what you want. Still, I thought I'd share a way of testing if you're inside a chroot even if /proc is mounted. IIRC, it was LaMont Jones who mentioned this some weeks ago on IRC: # test -r /proc/1/root || echo Inside a chroot Cheers, -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 Listening to: Mecano - Aire The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Idea: about package installation under chroot.
Florian Ernst wrote: echo -e '#!/bin/sh\n\nexit 101' /chroot/usr/sbin/policy-rc.d \ chmod a+x /chroot/usr/sbin/policy-rc.d as mentioned by Steve Langasek in http://lists.debian.org/debian-devel/2005/01/msg01316.html. Would someone like to package this? (No, I'm not really kidding.) -- see shy jo signature.asc Description: Digital signature
Re: Bug#301083: ITP: libevolution-ruby -- revolution, ruby binding for the evolution mail client
David Moreno Garza wrote: On Thu, 2005-03-24 at 17:31 +, Henning Makholm wrote: Scripsit David Moreno Garza [EMAIL PROTECTED] Revolution is a little Ruby binding to the excellent Evolution email client. Is it so little that it would be better to include it with the evolution package? Not quite sure since: a) evolution, IMHO, doesn't need to depend on ruby. b) It is a 3rd-party software, not included officially by Novell. c) It is a ruby module itself, just as other several hundreds. But if evolution's maintainer thinks it could be a good idea (I don't), we can implement it in the near future, yes. With regards to a), I don't think you need to depend on ruby at all. The reason is that the ruby bindings are only available for programs running in a ruby interpreter (AFAIK). Thus, if you want to *use* the ruby bindings, you then install ruby. If you do not install ruby, you do not need or use the ruby bindings. For example, if you package a libfoo package that is a C library, and libfoo-dev contains the static part of the C library, then there is no need to have libfoo-dev depend on the C compiler. Anyone that *uses* the libfoo-dev library will need to install a C compiler regardless. Thus, libevelution-ruby doesn't need to depend on Ruby. It only needs to depend on evolution. - Adam PS. It may need build depend on ruby, rake, etc.. , but that is different. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Vancouver meeting - clarifications
On Wed, Mar 23, 2005 at 01:07:07PM +0100, Wouter Verhelst wrote: On Wed, Mar 23, 2005 at 01:46:17AM +0100, Pierre THIERRY wrote: - Debian: 11 ports, 9157 packages (sarge) [17593 in sid] - NetBSD: 55 ports, 5300 packages It should be noted that the definition of 'port' isn't necessarily the same if you compare NetBSD against Debian; for instance, NetBSD/mac68k and NetBSD/amiga count as two ports, whereas in Debian, they count as one (albeit the 'subarchitecture' is different) Additionally, they do not provide binaries for all their packages. In fact, the pkgsrc collection does not even follow the normal release cycle. When NetBSD is ready to release, they simply take a snapshot of pkgsrc. It's not even a requirement that the packages in pkgsrc are even buildable on all supported platforms. NetBSD is able to support as many platforms as they do because they have very different requirements for support than we do. It's not a good idea to compare us to them. noah pgpsqrooX3nPQ.pgp Description: PGP signature
Re: Idea: about package installation under chroot.
Jorge == Jorge L deLyra [EMAIL PROTECTED] writes: Jorge /etc/init.d/daemon start Jorge in its postinstall script to start that daemon. I was not Jorge talking about booting a system, but about using a chroot Jorge shell to install packages in the filesystem structure of a Jorge remotely-booted machine. If a package directly uses /etc/init.d/daemon in its scripts, file a bug report. It should use invoke-rc.d instead. man invoke-rc.d It should work for chroots, and does work for pbuilder. -- Brian May [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
update-menus runs in the background?
It seems that /usr/bin/update-menus now runs in the background. I ran sudo apt-et install glade, and after it finished, I ran ps -ef |tail -5, and the last commands running were update-menus.real, and install-menu. Is it supposed to be a background job, and, if so, why? Thanks, please Cc: me, Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
7 Hours of Photoshop Video Training
7 Hours of Photoshop Video Training - $29.95 Download a DEMO Here http://photoshop-teacher.com/DEMO.htm Adobe Photoshop CS Adobe Photoshop CS is a professional tool for editing digital images. With Photoshop Tutorials on Video, you'll get to peek over the shoulder of a professional graphic designer and learn at your own pace. With access to more than 7 hours of Photoshop instruction, you'll discover the secrets of editing digital photos like a pro, how-to create cool objects for web sites, and learn a myriad of other useful tricks - all in one comprehensive step-by-step course. 7 hours of Video Training All Photoshop tutorials are presented in crystal-clear 1024x768 video quality, and are available to you as a downloadable file. No streaming, no activation, no copyright protection - simply download a file and watch it as many times as you like. A picture may be worth a thousand words, but a video explains things far more clearly and concisely. Try our demo and discover how easy working in Adobe Photoshop can be. Editing Digital Photos Digital photography is one of the fastest-growing tech markets, but learning how image editing software works hasn't been easy. With this set of clearly-worded Photoshop tutorials, you can enter the digital photography world at your own pace and discover ways to improve your imagery with Adobe Photoshop. We'll show you how-to remove distracting objects, assemble panoramas, restore damaged photos, remove red-eye, adjust color, and address a myriad of other digital photo issues and projects. Step By Step Course I wish I had known about this video before. I've bought four books, but this set of Photoshop tutorials gave me much more. Books are great as a quick reference, but if you really want to learn how-to edit digital photos, Photoshop Tutorials on Video is the way to go. It's so much easier to follow! Thanks for your great service! - Don Bryant, Woodland Hills, CA No future mailings http://photoshop-teacher.com/r.htm -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A new arch support proposal, hopefully consensual (?)
Believe what you like about what I said. I could not care less. What was apparently blatantly obvious to you about the nature of the post was not to me, and I wanted to step forward to be sure that Sven's points (which are near to my heart as a SPARC user) were not discarded over a triviality. Is it not ironic that I, a nameless top-poster (as you said), was a lot more polite about expressing my opinion than you were about expressing yours? After all, I voiced my objections specifically instead of categorizing the parent post as stupid. Well, I think the dead horse has been beaten, so let's make amends and move on to another more pressing issue. --- Glenn Maynard [EMAIL PROTECTED] wrote: SNIP On Mon, Mar 21, 2005 at 12:26:13AM -0800, [EMAIL PROTECTED] wrote: This is stupid. The very phrasing was lightly humerous, not an attack. /SNIP -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A new arch support proposal, hopefully consensual (?)
On Thu, Mar 24, 2005 at 06:56:31PM -0800, [EMAIL PROTECTED] wrote: Believe what you like about what I said. I could not care less. What was apparently blatantly obvious to you about the nature of the post was not to me, and I wanted to step forward to be sure that Sven's points (which are near to my heart as a SPARC user) were not discarded over a triviality. Is it not ironic that I, a nameless top-poster (as you said), was a lot more polite about expressing my opinion than you were about expressing yours? After all, I voiced my objections specifically instead of categorizing the parent post as stupid. Not really. I considered accusing someone of perpetrating a straw man attack who used the phrase you ignoramus, you silly enough that most people wouldn't need it explained. *shrug* You're a nameless top-poster; this is objective, not a flame. Your From: header has no name. If you scan other posts, you'll find it difficult to find anyone else who isn't posting with something at least resembling a real name. (It's hard to take an anonymous entity named foo bar baz boo deb seriously.) You quote upside-down; I'm sure you know what that means already and how bad form it is on most technical lists. Oh, and you break threads every time you reply, which is also extraordinarily bad practice: your In-Reply-To header is bogus and there's no References: header, which makes threads much harder to follow, and will probably get you ignored by many people since your posts won't appear in the normal flow of the thread. (I actually do point them out in the hope that you'll fix them. If you don't care enough about the quality of your posts to do so, it's not my loss. :) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: HOWTO Help (was: Debian DPL Debate Comments)
El da 23/03/2005 a 05:32 Alexander Schmehl escribio ... * Frans Pop [EMAIL PROTECTED] [050322 22:25]: AFAIK we don't have a good What you can do to help us documentation (please correct me, if I am wrong). How about http://www.debian.org/devel/join/ ? Which is linked from the main debian.org page (bottom left: Help Debian) I think it is quite short and is missing some quite easy tasks that can be done by nearly everyone. It's a very good start... I did the mentioned talk and am about to write the document, because I got asked a couple of times what people can do to help us, so I think there is need for a more detailed document about that. Sure, there's always people asking for such things and such a documment would be really helpful for them and the end for Debian. I've heard damog did similar thing recently. I've tried to do a start working on similar documment after my talk at DC4, not made real progress though, but I'd be more than likely to work on this once I manage to get things on the road again. Probably putting a draft of what you've summarized on debian-doc can be a good starting point. regards, -Rudy -- Rudy Godoy | 0x3433BD21 | http://stone-head.org ,''`. http://www.apesol.org - http://www.debian.org : :' : GPG FP: 0D12 8537 607E 2DF5 4EFB 35A7 550F 1A00 3433 BD21 `. `' `- signature.asc Description: Digital signature
Accepted gfslicer 1.5.4-5 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 23 Mar 2005 22:54:04 -0400 Source: gfslicer Binary: gfslicer Architecture: source i386 Version: 1.5.4-5 Distribution: unstable Urgency: low Maintainer: Víctor Pérez Pereira [EMAIL PROTECTED] Changed-By: Víctor Pérez Pereira [EMAIL PROTECTED] Description: gfslicer - utility to split and join files Closes: 273703 295781 Changes: gfslicer (1.5.4-5) unstable; urgency=low . * New maintainer (closes: #273703). * Replaced utils by gnome in Section of debian/control (closes: #295781). Files: 9255b6930a691a3f3aa52da1dfda7ee4 681 gnome optional gfslicer_1.5.4-5.dsc 32fa47fd31dc6ed4790a537d16a06e5e 3385 gnome optional gfslicer_1.5.4-5.diff.gz 787c0580cd4134502d205445cb35fde5 37148 gnome optional gfslicer_1.5.4-5_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCQmuAgY5NIXPNpFURAgEvAJ9xHpt43UiYPAkzQLXr6p2rGshIOACgvlZq PazFXJWBmxX8fPVdGzTCLXY= =Ie1G -END PGP SIGNATURE- Accepted: gfslicer_1.5.4-5.diff.gz to pool/main/g/gfslicer/gfslicer_1.5.4-5.diff.gz gfslicer_1.5.4-5.dsc to pool/main/g/gfslicer/gfslicer_1.5.4-5.dsc gfslicer_1.5.4-5_i386.deb to pool/main/g/gfslicer/gfslicer_1.5.4-5_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted rails 0.11.0-1 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 23 Mar 2005 13:29:19 -0600 Source: rails Binary: rails Architecture: source all Version: 0.11.0-1 Distribution: unstable Urgency: low Maintainer: Adam Majer [EMAIL PROTECTED] Changed-By: Adam Majer [EMAIL PROTECTED] Description: rails - MVC ruby based framework geared for web application development Changes: rails (0.11.0-1) unstable; urgency=low . * New upstream release - Ajax, Pagination, Non-vhost, Incoming mail support * Included tmail in the vendor distribution. Rails extended tmail with some new code and Debian's distribution of tmail is not sufficient. Files: 100df7c23b11eededeb72b07e5dce0d2 585 web optional rails_0.11.0-1.dsc b7dbc62dab4ec4de3841c395ae3f0b49 585716 web optional rails_0.11.0.orig.tar.gz 473ddb6a50996375570edee6e7df0199 7630 web optional rails_0.11.0-1.diff.gz 10533ab28af73477d5d34a86b9e3ebd6 929028 web optional rails_0.11.0-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCQl6O73/bNdaAYUURAjHyAJ9PbOC/SBPMuXq26lUoJU3A9X5BwACgqMVE ZdLKOYQrB34iitWoHddHxGo= =sj+x -END PGP SIGNATURE- Accepted: rails_0.11.0-1.diff.gz to pool/main/r/rails/rails_0.11.0-1.diff.gz rails_0.11.0-1.dsc to pool/main/r/rails/rails_0.11.0-1.dsc rails_0.11.0-1_all.deb to pool/main/r/rails/rails_0.11.0-1_all.deb rails_0.11.0.orig.tar.gz to pool/main/r/rails/rails_0.11.0.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted kernel-image-2.6.8-amd64 2.6.8-12 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 15 Mar 2005 15:30:10 +0100 Source: kernel-image-2.6.8-amd64 Binary: kernel-image-2.6.8-10-em64t-p4-smp kernel-image-2.6.8-10-amd64-generic kernel-headers-2.6.8-10-em64t-p4-smp kernel-headers-2.6.8-10-amd64-k8-smp kernel-image-2.6.8-10-amd64-k8 kernel-image-2.6.8-10-em64t-p4 kernel-image-2.6.8-10-amd64-k8-smp kernel-headers-2.6.8-10 kernel-headers-2.6.8-10-em64t-p4 kernel-headers-2.6.8-10-amd64-generic kernel-headers-2.6.8-10-amd64-k8 Architecture: source i386 Version: 2.6.8-12 Distribution: unstable Urgency: high Maintainer: Debian Kernel Team debian-kernel@lists.debian.org Changed-By: Frederik Schüler [EMAIL PROTECTED] Description: kernel-headers-2.6.8-10 - Header files related to Linux kernel version 2.6.8 kernel-headers-2.6.8-10-amd64-generic - Linux kernel headers 2.6.8 for generic x86_64 systems kernel-headers-2.6.8-10-amd64-k8 - Linux kernel headers for version 2.6.8 on AMD64 systems kernel-headers-2.6.8-10-amd64-k8-smp - Linux kernel headers for version 2.6.8 on AMD64 SMP systems kernel-headers-2.6.8-10-em64t-p4 - Linux kernel headers for version 2.6.8 on Intel EM64T systems kernel-headers-2.6.8-10-em64t-p4-smp - Linux kernel headers for version 2.6.8 on Intel EM64T SMP systems kernel-image-2.6.8-10-amd64-generic - Linux kernel image for version 2.6.8 on generic x86_64 systems kernel-image-2.6.8-10-amd64-k8 - Linux kernel image for version 2.6.8 on AMD64 systems kernel-image-2.6.8-10-amd64-k8-smp - Linux kernel image for version 2.6.8 on AMD64 SMP systems kernel-image-2.6.8-10-em64t-p4 - Linux kernel image for version 2.6.8 on Intel EM64T systems kernel-image-2.6.8-10-em64t-p4-smp - Linux kernel image for version 2.6.8 on Intel EM64T SMP systems Closes: 295422 Changes: kernel-image-2.6.8-amd64 (2.6.8-12) unstable; urgency=high . * Added versioned dependency on e2fsprogs (= 1.35-7), needed for successfull installation on 32bit userland systems. Closes: #295422 * Updated kernel images descriptions. * Rebuild with kerne-source-2.6.8 version 2.6.8-14. Files: b80906aa76358422bbec3be3b873c1f6 1085 devel optional kernel-image-2.6.8-amd64_2.6.8-12.dsc 70ac1b45c7fbc7b53c911cedc85edf5b 73555 devel optional kernel-image-2.6.8-amd64_2.6.8-12.tar.gz df36cc6a67224886730e8cc46f4f8e26 2719728 devel optional kernel-headers-2.6.8-10_2.6.8-12_i386.deb 00ce96b74c9f07824e9b09f1069ed13d 218992 devel optional kernel-headers-2.6.8-10-amd64-k8-smp_2.6.8-12_i386.deb 3a071c65529260ae3d7e01b786f4ae93 13207550 base optional kernel-image-2.6.8-10-amd64-k8-smp_2.6.8-12_i386.deb 149708a1eb9c0cc43df2fdb26b6daf5a 217008 devel optional kernel-headers-2.6.8-10-em64t-p4_2.6.8-12_i386.deb 2109fa126d77b6894c22c7b5ebddb14e 13178132 base optional kernel-image-2.6.8-10-em64t-p4_2.6.8-12_i386.deb e934f1b23e7fa3358b129c7c3361cefb 223986 devel optional kernel-headers-2.6.8-10-amd64-generic_2.6.8-12_i386.deb 67becbf34562b60b2c037c37b9caa356 12551714 base optional kernel-image-2.6.8-10-amd64-generic_2.6.8-12_i386.deb cd81051464e008a5f9c415eed751fc90 223020 devel optional kernel-headers-2.6.8-10-amd64-k8_2.6.8-12_i386.deb 4b8ceb519df5f51b10d50d727939972c 13249880 base optional kernel-image-2.6.8-10-amd64-k8_2.6.8-12_i386.deb 678cea7212c8b65e462a4a7ed26877a1 217348 devel optional kernel-headers-2.6.8-10-em64t-p4-smp_2.6.8-12_i386.deb dcf22e2ba8d70c65e2e949ebfcd4ba9a 13178764 base optional kernel-image-2.6.8-10-em64t-p4-smp_2.6.8-12_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFCQjdIfIEQE/XJcI0RAlFRAJ9DQltncG41gjmyvc3efC78nkXpsACcDbQg LW3cRDK/gwy3epm0SlaFEhI= =xN79 -END PGP SIGNATURE- Accepted: kernel-headers-2.6.8-10-amd64-generic_2.6.8-12_i386.deb to pool/main/k/kernel-image-2.6.8-amd64/kernel-headers-2.6.8-10-amd64-generic_2.6.8-12_i386.deb kernel-headers-2.6.8-10-amd64-k8-smp_2.6.8-12_i386.deb to pool/main/k/kernel-image-2.6.8-amd64/kernel-headers-2.6.8-10-amd64-k8-smp_2.6.8-12_i386.deb kernel-headers-2.6.8-10-amd64-k8_2.6.8-12_i386.deb to pool/main/k/kernel-image-2.6.8-amd64/kernel-headers-2.6.8-10-amd64-k8_2.6.8-12_i386.deb kernel-headers-2.6.8-10-em64t-p4-smp_2.6.8-12_i386.deb to pool/main/k/kernel-image-2.6.8-amd64/kernel-headers-2.6.8-10-em64t-p4-smp_2.6.8-12_i386.deb kernel-headers-2.6.8-10-em64t-p4_2.6.8-12_i386.deb to pool/main/k/kernel-image-2.6.8-amd64/kernel-headers-2.6.8-10-em64t-p4_2.6.8-12_i386.deb kernel-headers-2.6.8-10_2.6.8-12_i386.deb to pool/main/k/kernel-image-2.6.8-amd64/kernel-headers-2.6.8-10_2.6.8-12_i386.deb kernel-image-2.6.8-10-amd64-generic_2.6.8-12_i386.deb to pool/main/k/kernel-image-2.6.8-amd64/kernel-image-2.6.8-10-amd64-generic_2.6.8-12_i386.deb kernel-image-2.6.8-10-amd64-k8-smp_2.6.8-12_i386.deb to pool/main/k/kernel-image-2.6.8-amd64/kernel-image-2.6.8-10-amd64-k8-smp_2.6.8-12_i386.deb kernel-image-2.6.8-10-amd64-k8_2.6.8-12_i386.deb to
Accepted calendar 1.09.3-1 (powerpc source)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Thu, 24 Mar 2005 09:37:49 +0100
Source: calendar
Binary: libcalendar-ocaml-dev
Architecture: source powerpc
Version: 1.09.3-1
Distribution: unstable
Urgency: low
Maintainer: Stefano Zacchiroli [EMAIL PROTECTED]
Changed-By: Stefano Zacchiroli [EMAIL PROTECTED]
Description:
libcalendar-ocaml-dev - OCaml library providing operations over dates and times
Changes:
calendar (1.09.3-1) unstable; urgency=low
.
* New upstream release
* Rebuilt against ocaml 3.08.3
* debian/{control,rules,patches/}
- uses dpatch
* debian/rules
- no longer manually invoke ocamldoc, upstream tarball comes with prebuilt
ocamldoc documentation
* debian/docs
- install new version of the FAQ and TODO file
- don't install .ps.gz documentation, no longer shipped upstream
Files:
4601c37b993437e3cea503428dbc1fe3 627 libdevel optional calendar_1.09.3-1.dsc
1ece7e999bc401f7f5c8c16a6e254459 154413 libdevel optional
calendar_1.09.3.orig.tar.gz
bc0a33050408fd44523d4be3a650eee8 2466 libdevel optional
calendar_1.09.3-1.diff.gz
d305878ef2f2d38f939614ad680a4a17 134566 libdevel optional
libcalendar-ocaml-dev_1.09.3-1_powerpc.deb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)
iD8DBQFCQoDh1cqbBPLEI7wRAsolAJ93rObmzotIxgaMbHp+8xMTnoRvqgCeOANg
JxmZGqut2U/MWnNl3ypaPhk=
=sFz4
-END PGP SIGNATURE-
Accepted:
calendar_1.09.3-1.diff.gz
to pool/main/c/calendar/calendar_1.09.3-1.diff.gz
calendar_1.09.3-1.dsc
to pool/main/c/calendar/calendar_1.09.3-1.dsc
calendar_1.09.3.orig.tar.gz
to pool/main/c/calendar/calendar_1.09.3.orig.tar.gz
libcalendar-ocaml-dev_1.09.3-1_powerpc.deb
to pool/main/c/calendar/libcalendar-ocaml-dev_1.09.3-1_powerpc.deb
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted tclvfs 1.3-1 (powerpc source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 9 Dec 2004 20:33:40 +0100 Source: tclvfs Binary: tclvfs Architecture: source powerpc Version: 1.3-1 Distribution: unstable Urgency: low Maintainer: David N. Welton [EMAIL PROTECTED] Changed-By: David N. Welton [EMAIL PROTECTED] Description: tclvfs - Exposes Tcl 8.4's virtual filesystem C API to the Tcl script leve Changes: tclvfs (1.3-1) unstable; urgency=low . * New upstream release. Files: 4c799e85942ff6b7dbd8afaec0987705 502 interpreters optional tclvfs_1.3-1.dsc 84b249e72a5c80343bd20ac0992fe8ca 231118 interpreters optional tclvfs_1.3-1.tar.gz 00540e31133047676184dca815ac0da2 63560 interpreters optional tclvfs_1.3-1_powerpc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBuKuqAVLWA9/qxLkRAvkZAJ9mcOCLtligBJ87as1THy4LdtAw3ACffrfh +3ayl/NrANWRvWV1IDp0xhU= =GNG7 -END PGP SIGNATURE- Accepted: tclvfs_1.3-1.dsc to pool/main/t/tclvfs/tclvfs_1.3-1.dsc tclvfs_1.3-1.tar.gz to pool/main/t/tclvfs/tclvfs_1.3-1.tar.gz tclvfs_1.3-1_powerpc.deb to pool/main/t/tclvfs/tclvfs_1.3-1_powerpc.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted crypt-ssleay 0.51-3 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 24 Mar 2005 18:00:37 +0100 Source: crypt-ssleay Binary: libcrypt-ssleay-perl Architecture: source i386 Version: 0.51-3 Distribution: unstable Urgency: low Maintainer: Noèl Köthe [EMAIL PROTECTED] Changed-By: Noèl Köthe [EMAIL PROTECTED] Description: libcrypt-ssleay-perl - Support for https protocol in LWP Closes: 30 Changes: crypt-ssleay (0.51-3) unstable; urgency=low . * fixed typo in description (closes: Bug#30) Files: 0f7dac6f469021814bf0f80acff62e84 619 perl optional crypt-ssleay_0.51-3.dsc 1a4122b418cb02b31ccc05467dd478c1 2390 perl optional crypt-ssleay_0.51-3.diff.gz face9e5e4e1988325eb520e08ca19b4a 48246 perl optional libcrypt-ssleay-perl_0.51-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCQoJI9/DnDzB9Vu0RAg7pAKCOGYhFFN0S5B42iO9gjzAFrfAVIgCbB+iC nyMQo3pM5OTJ8FHQbog263I= =z68h -END PGP SIGNATURE- Accepted: crypt-ssleay_0.51-3.diff.gz to pool/main/c/crypt-ssleay/crypt-ssleay_0.51-3.diff.gz crypt-ssleay_0.51-3.dsc to pool/main/c/crypt-ssleay/crypt-ssleay_0.51-3.dsc libcrypt-ssleay-perl_0.51-3_i386.deb to pool/main/c/crypt-ssleay/libcrypt-ssleay-perl_0.51-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted devscripts 2.8.13 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 24 Mar 2005 09:13:15 + Source: devscripts Binary: devscripts Architecture: source i386 Version: 2.8.13 Distribution: unstable Urgency: low Maintainer: Julian Gilbey [EMAIL PROTECTED] Changed-By: Julian Gilbey [EMAIL PROTECTED] Description: devscripts - Scripts to make the life of a Debian Package maintainer easier Closes: 267317 295845 299344 301177 Changes: devscripts (2.8.13) unstable; urgency=low . * bts: provide --quiet option (closes: #299344) * dpkg-depcheck: improve sgml catalog regexp (closes: #295845) * uupdate: improve error message (closes: #267317) * uscan: fix showstopper (closes: #301177) Files: 4572fe0035740137e4b36bc5acea2c10 592 devel optional devscripts_2.8.13.dsc 72a9dbd84d11510e458faf743b06e7fa 185018 devel optional devscripts_2.8.13.tar.gz 8779a629c79821bcf1fe99e8adcbbc70 198302 devel optional devscripts_2.8.13_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFCQoUZDU59w/205FkRAtr9AKDRxITErVHSQqtwLJlQRCtoLIsLAgCfYo1e B6/RwliaSOGrqTSukizJxXk= =SlUc -END PGP SIGNATURE- Accepted: devscripts_2.8.13.dsc to pool/main/d/devscripts/devscripts_2.8.13.dsc devscripts_2.8.13.tar.gz to pool/main/d/devscripts/devscripts_2.8.13.tar.gz devscripts_2.8.13_i386.deb to pool/main/d/devscripts/devscripts_2.8.13_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted afterstep 2.00.04-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 23 Mar 2005 23:14:58 +0100 Source: afterstep Binary: libafterstep0 afterstep libafterimage-dev libafterimage0 Architecture: source i386 Version: 2.00.04-1 Distribution: unstable Urgency: medium Maintainer: Robert Luberda [EMAIL PROTECTED] Changed-By: Robert Luberda [EMAIL PROTECTED] Description: afterstep - window manager with the NEXTSTEP look and feel libafterimage-dev - imaging library designed for AfterStep - development files libafterimage0 - imaging library designed for AfterStep - runtime files libafterstep0 - shared libraries for the AfterStep window manager Closes: 298728 299604 Changes: afterstep (2.00.04-1) unstable; urgency=medium . * New upstream version: + Fixes shared memory leaks (closes: #298728). Note, this only works correctly, when one uses the Quit button or menu entry to exit afterstep. When one kills their X session e.g. by pressing CTRL+ALT+BackSpace, afterstep is given no chances to free the shared memory. + Should build on amd64 with gcc-4.0 (closes: #299604). . * Update doc-base file for the updated (but not yet finished) afterstep FAQ. * Make symlinks from /usr/share/afterstep/non-configurable/* to appropriate files. * Remove look.Debian, it was just the same as look.DEFAULT. * Minor tweaks in the wharf config file. * NEWS.Debian: yet another update for users upgrading from pre-2.0 versions. * Update README.Debian. * debian/control: remove Recommends: wmavgload, and suggests a few packages referred in the default wharf configuration file. * Modify debian/rules to pass --enable-debug to configure when the package version contains `dbg' string (so this version is compiled with Files: 340c0a54d350163fd1a37fce2910a5df 838 x11 optional afterstep_2.00.04-1.dsc 762d8b7bb45c225180a139c226fde6b1 5157680 x11 optional afterstep_2.00.04.orig.tar.gz e7402752ad4ae82c6e732ca8a9c2e0ef 42427 x11 optional afterstep_2.00.04-1.diff.gz 291dc5b3de1297d1770797fbe1fec8e1 2589780 x11 optional afterstep_2.00.04-1_i386.deb 11af5d535fa1add8182bb4822ac9c022 262170 libs optional libafterstep0_2.00.04-1_i386.deb ceef5150ec3c6b279d7b4e86488ba547 254374 libs optional libafterimage0_2.00.04-1_i386.deb df85748bb81bb2431c8b42f6e0135dbc 739034 libdevel optional libafterimage-dev_2.00.04-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCQezUThh1cJ0wnDsRAul5AJ48B4j/du4LwcGa6dxakg+3QtfYGgCfWatX 7mMjTQePNVdVQ7I35eSNglc= =AO5k -END PGP SIGNATURE- Accepted: afterstep_2.00.04-1.diff.gz to pool/main/a/afterstep/afterstep_2.00.04-1.diff.gz afterstep_2.00.04-1.dsc to pool/main/a/afterstep/afterstep_2.00.04-1.dsc afterstep_2.00.04-1_i386.deb to pool/main/a/afterstep/afterstep_2.00.04-1_i386.deb afterstep_2.00.04.orig.tar.gz to pool/main/a/afterstep/afterstep_2.00.04.orig.tar.gz libafterimage-dev_2.00.04-1_i386.deb to pool/main/a/afterstep/libafterimage-dev_2.00.04-1_i386.deb libafterimage0_2.00.04-1_i386.deb to pool/main/a/afterstep/libafterimage0_2.00.04-1_i386.deb libafterstep0_2.00.04-1_i386.deb to pool/main/a/afterstep/libafterstep0_2.00.04-1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted language-env 0.64 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 24 Mar 2005 19:34:39 +0900 Source: language-env Binary: language-env Architecture: source all Version: 0.64 Distribution: unstable Urgency: low Maintainer: Tomohiro KUBOTA [EMAIL PROTECTED] Changed-By: Kenshi Muto [EMAIL PROTECTED] Description: language-env - simple configuration tool for native language environment Closes: 299376 Changes: language-env (0.64) unstable; urgency=low . * Kenshi Muto - Updated Polish support (closes: #299376) THanks Robert. Files: ee43b0b6707d18ed4a888b68ebed0bf4 594 misc optional language-env_0.64.dsc 591aac0a0e006c79a605fb546395b383 166547 misc optional language-env_0.64.tar.gz fffaab584a257a5538cd610df5282bcf 182982 misc optional language-env_0.64_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iEYEARECAAYFAkJCmDAACgkQQKW+7XLQPLG1vgCgxC+s0lQNrRJv6fTZ2wf/STy8 ZsYAnjqMnzm55a4/w+lIksAZM8tSbnVz =ajMo -END PGP SIGNATURE- Accepted: language-env_0.64.dsc to pool/main/l/language-env/language-env_0.64.dsc language-env_0.64.tar.gz to pool/main/l/language-env/language-env_0.64.tar.gz language-env_0.64_all.deb to pool/main/l/language-env/language-env_0.64_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted asterisk-prompt-se 0.8-1 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 24 Mar 2005 11:15:56 +0100 Source: asterisk-prompt-se Binary: asterisk-prompt-se Architecture: source all Version: 0.8-1 Distribution: unstable Urgency: low Maintainer: Simon Richter [EMAIL PROTECTED] Changed-By: Simon Richter [EMAIL PROTECTED] Description: asterisk-prompt-se - Swedish voice prompts for Asterisk Changes: asterisk-prompt-se (0.8-1) unstable; urgency=low . * New upstream release Files: f7bf816957cd0636bbeb5186929117d5 716 comm optional asterisk-prompt-se_0.8-1.dsc 8462cdfbc40e4af2bd75ea8f3cf6b43a 1856370 comm optional asterisk-prompt-se_0.8.orig.tar.gz 0a7f80346f2dff1b6ea6fe3b2e75b221 2018 comm optional asterisk-prompt-se_0.8-1.diff.gz 6a55821c7837c418ca5bef3e0c3bc665 1874778 comm optional asterisk-prompt-se_0.8-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.3.92 (GNU/Linux) iQCVAwUBQkKUqlYr4CN7gCINAQKwdwP/U0NPuFDXY9mrAa5/8D8W8WVP4JnJQJ6M m3dR1I60rhmzcAiHJl8RHA2SCbm+w+TSRw3QGAcCFCeonQY/8alJG+q6gYxjirDj 8CD7bGdb1GRvNPMoGloyNQW/Y53nPd/64Es52Tta7UcZOaIlql12a8nOpzc78vzt WBheyBcCEfo= =A9pb -END PGP SIGNATURE- Accepted: asterisk-prompt-se_0.8-1.diff.gz to pool/main/a/asterisk-prompt-se/asterisk-prompt-se_0.8-1.diff.gz asterisk-prompt-se_0.8-1.dsc to pool/main/a/asterisk-prompt-se/asterisk-prompt-se_0.8-1.dsc asterisk-prompt-se_0.8-1_all.deb to pool/main/a/asterisk-prompt-se/asterisk-prompt-se_0.8-1_all.deb asterisk-prompt-se_0.8.orig.tar.gz to pool/main/a/asterisk-prompt-se/asterisk-prompt-se_0.8.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
