libplasma2 and kdebase-workspace-data
Hi guys, I'm trying to make a .deb package with cowdancer directly from a "debianized" source. I got this error: libplasma2: Depends: kdebase-workspace-data (= 4:4.1.0-1) but it is not installable packages.debian.org/libplasma2 reports dependency with kdebase-workspace-data 4.1.0-2 (I'm not on amd64). packages.debian.org/kdebase-workspace-data reports 4.1.0-2 is good with all archs. Now the question :) I need to downgrade package kdebase-workspace-data from -2 to -1 to make compliant ? How I can selectively downgrade packages on cowdancer/pbuilder environment ? I can ignore this warning ??? How I can force installation of a single package on cowdancer/pbuilder ? 10x a lot, Salvatore -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Some autobuilders wait for build-indep dependencies
FRANCISCO MOYA FERNANDEZ <[EMAIL PROTECTED]> wrote: > I already know that people do also build their own packages, thanks. > You do not need to "rewire" the debian/rules in order to build > zeroc-ice binary-arch packages but AFAIK in your PowerPC you cannot > currently build zeroc-ice binary-all packages, no matter what I do. > You do not need to issue an NMU if you find some binary-all packages > that could be built in architectures other than i386. Report the bug > and I will add them in the next release. The kludge will add another > exception. Note that this is not a guarantee to be able to build > binary-all but perhaps you could build binary/libzeroc-ice-java (?) > The zeroc-ice build dependencies are right to the best of my > knowledge, but dpkg-buildpackage -B do not currently check them all. > Target build must satisfy Build-Depends-Indep (cf. Debian Policy > 7.7) but dpkg-buildpackage fail to enforce that for binary-arch > builds [...] Hello, Policy does not reflect reality for both build and clean targets. The aim of the whole thing is to not require the build daemons to install stuff needed only for building archtecture all packages. To do this the buildds run dpkg-buildpackage -B. The working definition of Build-Depends(-Indep) is: * Build-Depends: Everything needed for dpkg-buildpackage -B * Build-Depends-Indep: Packages needed in addition to Build-Depends for running dpkg-buildpackage -b "dpkg-buildpackage -B" runs debian/rules clean, build and binary-arch. "dpkg-buildpackage -b" runs debian/rules clean, build and binary. cu andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFH: clamav
Stephen Gran wrote: > This one time, at band camp, Stephen Gran said: >> I'm looking for people to help with maintenance of clamav. > > So, I got a total of one reply to this RFH. I'm currently debating > whether or not to release clamav with lenny or orphan it. I don't think > I'm interested in taking it through the next stable release on my own, > so an orphan looks likely, but I'm interested enough to want to be part > of a team if anyone else is interested. If you're interested in seeing > it release, please contact me off list. I've mentioned it before, but it didn't come to any real conclusion: I think we should only support clamav through volatile.debian.org and not through the regular archive. It has happened twice that clamav became unusable through the lifecycle of a release (Sarge's version failed to parse malware signatures since later releases required more advanced engine features and Etch's version is unusably slow for the same reason #454587) and we shouldn't repeat this for a third time. Only providing current versions through volatile will also be less work than all the backporting that's currently being done. There're a few libclamav reverse-deps, which need to be adressed, though. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: issues with aptitude dist-upgrade from etch to lenny
Henning Glawe wrote: you are right... sorry for the sloppy research :S... think it must have been the perl-base<->perl-modules version mismatch. I'll try to reproduce this immediately. Yes, I think this is the issue. I wrote an ugly script to reproduce from a almost pristine etch chroot[1] #/bin/sh -ex dpkg -l perl perl-base perl-modules apt-get install --yes debsums sed -i s/etch/lenny/ /etc/apt/sources.list apt-get update apt-get install --yes -d perl perl-modules tzdata dpkg -i /var/cache/apt/archives/tzdata_2008e-2_all.deb dpkg -i /var/cache/apt/archives/libc6_2.7-13_amd64.deb dpkg --unpack /var/cache/apt/archives/perl_5.10.0-11.1_amd64.deb dpkg --unpack /var/cache/apt/archives/perl-modules_5.10.0-11.1_all.deb dpkg -l perl perl-base perl-modules debsums Results: + dpkg -l perl perl-base perl-modules Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-==-==- ii perl 5.8.8-7etch3 Larry Wall's Practical Extraction and Report Language ii perl-base 5.8.8-7etch3 The Pathologically Eclectic Rubbish Lister ii perl-modules 5.8.8-7etch3 Core Perl modules ... + dpkg --unpack /var/cache/apt/archives/perl_5.10.0-11.1_amd64.deb (Reading database ... 12309 files and directories currently installed.) Preparing to replace perl 5.8.8-7etch3 (using .../perl_5.10.0-11.1_amd64.deb) ... Unpacking replacement perl ... + dpkg --unpack /var/cache/apt/archives/perl-modules_5.10.0-11.1_all.deb (Reading database ... 11957 files and directories currently installed.) Preparing to replace perl-modules 5.8.8-7etch3 (using .../perl-modules_5.10.0-11.1_all.deb) ... Unpacking replacement perl-modules ... + dpkg -l perl perl-base perl-modules Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-==-==- iU perl 5.10.0-11.1 Larry Wall's Practical Extraction and Report Language ii perl-base 5.8.8-7etch3 The Pathologically Eclectic Rubbish Lister iU perl-modules 5.10.0-11.1 Core Perl modules + debsums Can't locate File/Find.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at /usr/bin/debsums line 10. BEGIN failed--compilation aborted at /usr/bin/debsums line 10. This looks identical to the failure mode. Note it isn't possible to configure perl and perl-modules because the required version of perl-base has not been installed - again this is similar to what happens in the failing upgrade process. Unfortunately so far when I try to reproduce the problem using "apt-get dist-upgrade" from the same chroot it works fine. I would guess the issue is that postrm and DPkg::Post-Invoke scripts are using perl when it is in this broken state. Notes: [1] only difference is build-essentials and fakeroot installed and installation of recommends turned off by default; I doubt these had any effect. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Some autobuilders wait for build-indep dependencies
I finally decided to turn target 'build' into an alias of target 'build-arch' for all architectures. This is already done in some other packages (e.g. orsa) and cdbs provides explicit support for it. I know there is a bit of controversy on this but Policy is not strictly against it. On Sat, 2008-08-16 at 22:46 -0300, Wouter Verhelst wrote: > On Fri, Aug 15, 2008 at 10:51:08PM +0200, FRANCISCO MOYA FERNANDEZ wrote: > > I already know that people do also build their own packages, thanks. You do > > not need to "rewire" the debian/rules in order to build zeroc-ice > > binary-arch > > packages but AFAIK in your PowerPC you cannot currently build zeroc-ice > > binary-all packages, no matter what I do. > > In that case, it's best to let the build actually *fail* on > non-i386 architectures, rather than allowing it to silently > succeed, perhaps by the non-installability of i386-specific > build-dependencies. Allowing a package builder to build a source > package in such a way that the _all.deb packages aren't built > without an error *will* cause confusion. Trust me. I never told you so. Package zeroc-ice will not succeed if you try to build a package in an unsupported architecture. OTOH target build will succeed on non-i386 architectures (now on all architectures) if build-arch succeeds. > > You do not need to issue an NMU if you find some binary-all packages that > > could be built in architectures other than i386. Report the bug and I will > > add them in the next release. > > There are many reasons why people may need to build your package. > You may be on holiday, and unable to upload a package in time for > the release. The security team may have to prepare a fix. Someone > may want to add a patch to their version of your package in their > derivation of Debian. A user may want to build a version locally > with a different compiler. So what? You can always build binary-arch. And as many packages of binary-indep as supported in your platform. > I'm sure there are more examples. > > Making that hard does not fit my description of "good packaging", > honestly. You are talking of making build fail on all non-i386 architectures and and now you tell me I'm making compilation by the user hard. Nice contradiction. > > The kludge will add another exception. Note that this is not a > > guarantee to be able to build binary-all but perhaps you could > > build binary/libzeroc-ice-java (?) > > > > The zeroc-ice build dependencies are right to the best of my knowledge, but > > dpkg-buildpackage -B do not currently check them all. Target build must > > satisfy Build-Depends-Indep (cf. Debian Policy 7.7) but dpkg-buildpackage > > fail to enforce that for binary-arch builds. > > I'm not sure I understand what you're trying to say here. Policy 7.7 states that target 'build' *must* satisfy Build-Depends *and* Build-Depends-Indep. Autobuilders enforce just Build-Depends but then use target 'build'. This has been discussed long ago, but AFAIK there is no consensus yet. > > This is a feature rather than a bug in my opinion. This makes it possible to > > use target build while the transition path to build-arch is defined. > > For clarity: "the transition to build-arch" is not actually in the > process of being defined, at all. This *is* a bug, IMAO. There is no need for a formal "process" to define this. There are lots of previous discussions on this, lots of patches to dpkg-buildpackage and friends, and lots of proposals ranging from new control fields to trial and error approaches. Eventually we will find the right one. > > Simply stated, zeroc-ice is a package with lots of dependencies. I'll do my > > best to get most of it working in as much architectures as possible. But I > > won't remove features in some architectures just to homogeneize the > > behaviour > > of debian/rules. Therefore I'm eager to receive suggestions on how to make > > it *better* supported on any architecture. But I won't accept "DO NOT DO > > THAT" statements unless properly supported on the Debian Policy. > > Debian Policy only knows as much as what we put in it. Therefore it > isn't almighty, and it *certainly* isn't a stick to beat people with, as > you're trying to do here. The fact that some insanity isn't in > policy doesn't mean you should suddenly start doing it in your > package. It was not my intention to use Policy as a stick but as the only authoritative argument I was willing to accept for destructive "DO NOT DO THAT" statements without further argumentation. Suggestions leading to a better user experience with my packages are welcome. Suggestions that reduce the feature set are not. But even in the latter case I'm willing to accept them if my approach is against Debian Policy. > Changing the behaviour o your debian/rules file based on the > architecture you're trying to build on, is a *very* bad idea, > policy or no policy. If you really, *really* must make sure that > build-indep isn't ran everywhere, then re
Re: tools/ and dftp on mirrors
]] Steve McIntyre | On Thu, Aug 07, 2008 at 06:41:21PM +0200, Frans Pop wrote: | >Joerg Jaspert wrote: | >> unless someone has a *very* good reason (and is willing to do the work) | >> we are planning to kick the tools/ directory from our mirrors, as well | >> as the dftp*.gz files in project/misc. | > | >Please check with the debian-cd team first. Files from tools are still | >being included on CD images and with current debian-cd CD builds will | >fail if it is removed from the mirrors. | | Yup. I've spoken to mhy about this since. We explicitly don't include | /tools/ in the .jigdo images as they're not versioned. I'll stop | adding the files onto the CDs in the daily/weekly images shortly when | the build machine is back up. It'd be good to keep tools/ at least until lenny is out, since debian-cd in the current stable release will be broken (as noted above). Not everybody runs debian-cd from svn. :-) -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Not stopping daemons, where are we?
]] Ben Finney | Felipe Sateler <[EMAIL PROTECTED]> writes: | | > I still don't understand why a SIGTERM is needed. If proper cleanup | > is not needed, why not just SIGKILL and be done with it? Is there a | > real reason? | | My understanding only: | | It is preferable for processes to clean up after themselves, which is | the semantic of SIGTERM. Only those processes which were not able to | do so in a timely manner will be abruptly killed with SIGKILL. But if you have cleanups to do, you should have a proper stop script (or you have a race condition). (If it's just about removing shared memory segments and such, there's no need to clean up -- the system is about to go away anyway.) -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: html2text with utf8 support: please test
Hi Eugene, At Tue, 05 Aug 2008 22:34:18 +0300, Eugene V. Lyubimkin wrote: > Utility html2text, version 1.3.2a-6, with "utf8" patch was just uploaded to > experimental. > The patch allows to process UTF-8 files when '-utf8' option supplied. Input > should be in > UTF-8 and output will be in UTF-8 too. > > Please test this functionality - I believe that UTF-8 support is a good > feature, > especially for processing non-English documents. Thank you for implementing such an nice feature. But unfortunately, html2text 1.3.2a-6 exports broken text for (at least) Japanese UTF-8 page even with -utf8 option. I'll send a detail to BTS. Thanks, -- Kenshi Muto [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: html2text with utf8 support: please test
Kenshi Muto wrote: > Hi Eugene, > > At Tue, 05 Aug 2008 22:34:18 +0300, > Eugene V. Lyubimkin wrote: >> Utility html2text, version 1.3.2a-6, with "utf8" patch was just uploaded to >> experimental. >> The patch allows to process UTF-8 files when '-utf8' option supplied. Input >> should be in >> UTF-8 and output will be in UTF-8 too. >> >> Please test this functionality - I believe that UTF-8 support is a good >> feature, >> especially for processing non-English documents. > > Thank you for implementing such an nice feature. It's not my patch, I've just found and applied it :) > But unfortunately, html2text 1.3.2a-6 exports broken text for (at least) > Japanese UTF-8 page even with -utf8 option. > > I'll send a detail to BTS. Ok. Regards, -- Eugene V. Lyubimkin aka JackYF, Ukrainian C++ developer. signature.asc Description: OpenPGP digital signature
Re: html2text with utf8 support: please test
Eugene V. Lyubimkin wrote: > Utility html2text, version 1.3.2a-6, with "utf8" patch was just > uploaded to experimental. The patch allows to process UTF-8 files > when '-utf8' option supplied. Input should be in UTF-8 and output will > be in UTF-8 too. > > Please test this functionality - I believe that UTF-8 support is a > good feature, especially for processing non-English documents. Mmm, the way it is done looks wrong to me: there is no reason why the input and output charsets should be related at all. For the input, html2text should recognize the meta http-equiv tag, that should work for a lot of pages, else an input-charset option can be provided. For the output, the current locale's charset should be used (as returned by nl_langinfo(CODESET) after calling setlocale(LC_CTYPE,"")), that should work in almost all cases, else an output-charset option can be provided. Yes, that means conversions. But without that you can not put a sticker "utf-8 support", only "limited utf-8 support". Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Come join me on Learn Makeup Courses...
Learn Makeup Courses: Learn Makeup Courses and be Professional Makeup Artist at EI- Makeup School Jack Smith has invited you to join Learn Makeup Courses Watch my Makeup tips, blogs and video Check out Learn Makeup Courses: http://makeup-courses.ning.com/?xgi=gKx5nvR If your email program doesn't recognize the web address above as an active link, please copy and paste it into your web browser About Learn Makeup Courses... EI School of Professional Makeup provides students with the opportunity to become skilled in all aspects of professional makeup Learn Makeup Courses includes: Blogs Photos Videos To control which emails you receive on the corner, or to opt-out, go to: http://makeup-courses.ning.com/?xgo=/KDuTG/iG6Lo/mk67pqedBEIX8yEyQLuhmwWy/cgk1IYybzGSeP/wg
Re: Annoying GTK2 file dialogue - where to file the BUG?
Am Mittwoch 13 August 2008 schrieb Johannes Wiedersich: > Install gtk-qt-engine and configure it from control centre. Hey Joe, thanks for the hint! Def'ney better look'n'feel - but I still have to wait 3-4 minutes when ever I want to open an ICS with iceowl from firefox... Would love to get rid of this crappy file dialog. Cheers Rudi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Amarok: SECURITY ISSUE in Debian Etch and Lenny
Hallo, in the Amarok package is a security issue It is fixed in Amarok 1.4.10 (http://secunia.com/advisories/31418/, http://amarok.kde.org/en/releases/1/4/10) Please update the packages with the fix. thacrazze
Re: Debian on the FreeRunner -- now official
the FSO packaging team of the Debian project[1] is happy to announce that we have started to provide installation procedures and packages required to have your FreeRunner[2] run Debian-powered. This is really great news! Hooray for Debian rescuing us from the Freerunner dilemna! ; -- Jay Vaughan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477072: mysql-server-5.0: Arbitrary data input plus GIS functions, causes mysql server crash
This bug has been sitting around since July w/o a resolution. I tracked it down to a difference between i386 builds and AMD64. The crash only occurs on AMD64. I think this is an important bug to be fixed as it results in a minor reproducible DoS/data-loss (of temporary tables and heap tables). At this point I am unclear on what to do about it, especially as I contacted the maintainer directly 3 weeks ago and still have yet to receive a response. signature.asc Description: OpenPGP digital signature
Re: [Pkg-kde-extras] Amarok: SECURITY ISSUE in Debian Etch and Lenny
Hi, pirmadienis 18 rugpjūtis 2008, thacrazze rašė: > in the Amarok package is a security issue > > It is fixed in Amarok 1.4.10 >(http://secunia.com/advisories/31418/, > http://amarok.kde.org/en/releases/1/4/10) The fixed version has been in unstable for two days already. 1.4.10 is a new upstream release but: 1. The only real change since 1.4.9.1 is the security fix mentioned above and updates to translations. 2. The big upstream tarball diff comes from the differences in *autogenerated* autotools stuff. However, autotools stuff is regenerated each time package is built anyway so these differences can be safely ignored. 3. Packaging diff from 1.4.9.1-3 to 1.4.10-1 is just a new debian/changelog entry. Given the reasons above, please unblock amarok 1.4.10-1 and allow it to migrate to Lenny. You can of couse delay 1.4.10-1 migration a bit if you want since the security issue in question is not very critical. -- Modestas Vainius <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part.
Re: Some autobuilders wait for build-indep dependencies
FRANCISCO MOYA FERNANDEZ <[EMAIL PROTECTED]> wrote: > I already know that people do also build their own packages, thanks. > You do not need to "rewire" the debian/rules in order to build > zeroc-ice binary-arch packages but AFAIK in your PowerPC you cannot > currently build zeroc-ice binary-all packages, no matter what I do. > You do not need to issue an NMU if you find some binary-all packages > that could be built in architectures other than i386. Report the bug > and I will add them in the next release. The kludge will add another > exception. Note that this is not a guarantee to be able to build > binary-all but perhaps you could build binary/libzeroc-ice-java (?) > The zeroc-ice build dependencies are right to the best of my > knowledge, but dpkg-buildpackage -B do not currently check them all. > Target build must satisfy Build-Depends-Indep (cf. Debian Policy > 7.7) but dpkg-buildpackage fail to enforce that for binary-arch > builds [...] Hello, Policy does not reflect reality for both build and clean targets. The aim of the whole thing is to not require the build daemons to install stuff needed only for building archtecture all packages. To do this the buildds run dpkg-buildpackage -B. (#374029) The working definition of Build-Depends(-Indep) is: * Build-Depends: Everything needed for dpkg-buildpackage -B * Build-Depends-Indep: Packages needed in addition to Build-Depends for running dpkg-buildpackage -b "dpkg-buildpackage -B" runs debian/rules clean, build and binary-arch. "dpkg-buildpackage -b" runs debian/rules clean, build and binary. cu andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Amarok: SECURITY ISSUE in Debian Etch and Lenny
On 08/18/2008 06:08 PM, thacrazze wrote: > Hallo, > > in the Amarok package is a security issue > > It is fixed in Amarok 1.4.10 > > (http://secunia.com/advisories/31418/, > http://amarok.kde.org/en/releases/1/4/10) > > Please update the packages with the fix. They already have been updated as to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=494765 It would be nice, if you would read what you send, before you instruct others for action. The security advisory you sent clearly states that the issue was first reported in above *Debian* bug report. Looking at that bug report tells me: it's already fixed. If you are not content with this or would like to provide additional information you are welcome to report to the bug, but please not to d-d. Regards, Johannes signature.asc Description: OpenPGP digital signature
Re: Bug#493593: ITP: cdde -- CD Detect & Execute utility
On Sun, Aug 03, 2008 at 16:58:37 +0400, Stanislav Maslovski wrote: > Package: wnpp > Severity: wishlist > Owner: Stanislav Maslovski <[EMAIL PROTECTED]> > > > * Package name: cdde > Version : 0.2.0 > Upstream Author : Eric Lathrop <[EMAIL PROTECTED]> > * URL : http://ericlathrop.com/cdde/ > * License : GPL > Programming Lang: C > Description : CD Detect & Execute utility > > CDDE is a program that detects when a CD/DVD-ROM drive has a disc > inserted. When it finds a disc inserted in the drive it will attempt > to determine the type of the disc, and execute a specified command. Aren't these kind of things handled by HAL and upper layers these days? My impression is that tose upper layers are very desktop specific. I think that cdde could be used as some desktop independent upper layer on top of HAL. Regards, Tino -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Partnership Opportunity Follow-Up
Hello Editor-In-Chief of Debian.com, I am writing to follow-up with the Geek Weekly proposal email we sent to you earlier. I wanted to confirm that you received it and to see whether this was something you wanted to consider, or to explore in more detail. As aforementioned, we noticed your website doesn't quite have a gadgets section yet and this promising and complimentary opportunity can change that. Our Geeky Weekly program will highly complement your website's content and will attract a larger audience to your site. We believe that debian.com is a great fit and stands to benefit a lot from the quality technology/gadget content of our award-winning writers. Perhaps we could discuss integration of this program next to the style section of your site. Pro-bono promotion, advertising space (and potential ad revenue), brand retention, and potential increased viewership are among a few more benefits. All our services will cost you absolutely nothing. For a preview of the program content, go here: http://www.studioonenetworks.com/programpartner/thegeekweekly I look forward to hearing from you regarding if you are interested in the program or if you have subsequent questions for me. Thanks and cheers. Chuka Ikokwu, Program Partnerships Associate Studio One Networks 588 Broadway New York, NY 10012 [EMAIL PROTECTED] T: 212-213-2332 x213 F: 212-941-0575 www.studioonenetworks.com
Bug#495628: general: setting system users' homes in their data directory slower security scanning
Package: general Severity: normal putting the home directory of users like postgres or especially backuppc in their data directory makes routine scans of tiger over the homes directory for user related suspect files work significantly slower. there is no reason to scan those directories, since they contain structured data only, but only accidental logins of those users may bring bad thing here, and this should be the second reason not to set their homedirs here. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.25-2-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#495630: ITP: libfaketime -- report faked system time to programs
Package: wnpp Severity: wishlist Owner: Daniel Kahn Gillmor <[EMAIL PROTECTED]> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: libfaketime Version : 0.7 Upstream Author : <[EMAIL PROTECTED]> * URL : http://www.code-wizards.com/projects/libfaketime/index.html * License : GPL-2+ Programming Lang: C Description : report faked system time to programs libfaketime intercepts various system calls which programs use to retrieve the current date and time. It can then report faked dates and times (as specified by you, the user) to these programs. This means you can modify the system time a program sees without having to change the time system-wide. FTPL allows you to specify both absolute dates (e.g., 01/01/2004) and relative dates (e.g., 10 days ago). - -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (200, 'unstable'), (101, 'experimental') Architecture: i386 (i686) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQIVAwUBSKpkk8zS7ZTSFznpAQI0VQ/+NnPDnub5FveWlTqqtVuX2WENkONQ++SM XhSP2x22z3gWw8eicC4L0MVr6VF83h+fYth2Y5c/+FJ+/VbZ/igh0wmhMOC/yBEJ X+nhWsEANHXyua9Cu7TYEUwrUgrgOuJLecZ2aekjF1Y5TulFbYj/Ka2YHp7GXV/+ 0gPRMTzKgFvcRQw2e+mZudJzsQaG95J7yughCi042s+azEAmfQY6v3Oy1o2SpVzS 6FUMY33E6/WqGg/uiaaoAIbAbeM5aUOdkjvxzfgz84Ap1fTJUFz+XZzIirlhxXIJ gdn4w4RJUliw/jtYRCmdC+nvGeIJA9bMncQZeV3n6/yfv+8xR4tehWwxjDQ8Wyyh 5cgC7hR+ExUEWVP4uGvWqnG3ycX0ISnDhr2cWwo9jk6c28X2RV7YWASR+3BYoOTK 7cambgiuS8QUGAAC/116u9qOxSrrTiE6HoKB/WfV9N0hRl5x7Qh3g7Ljxae9Bosj TdmuhW37HDpCno79nsphhkW+BHkrR3Awz1wnW0+GjKT2X/Mb6vZfFwEvQUyqRymi J2a8jSmojzFJldWccVSiys3w66OGRhyEZl+qiw5CAUPec4VTgzrAmaqSi4Sl01aD l99p3tS0XqyeNuERq11w/5AAfDViswuICDb3qivkRYP8nn1arB/WiKqn0w23kGMe XCrSmUTr4lQ= =+XnV -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
