Re: USE flags ??
On Sunday 24 October 2004 17:42, Jim Bailey wrote: > It is alright but there is always room for improvement, I think emerge > has the edge as a packet management tool. ;-P Could you clarify that statement? That may take the cake as the least-substantive comment I have seen on here in awhile. Do you know the differences or each? Please, let us know. USE flags. Check Continue...
Re: USE flags ??
On Thursday 28 October 2004 07:18, Jon Dowland wrote: > > i still like them both and still run both on servers, > > You run gentoo on *SERVERS*!?!?! I guess someone would have to define servers in this context. A news server for downloading "special" avi files is not really a server in the sense of legitimacy, and/or 24/7 uptime...Someone who brags about inane Gentoo things (not that Gentoo isn't a great technology demonstration) strikes me as the type who would be running a "server" with such a loose definition of the word and bragging about it. Try replicating that setup with Gentoo. Good luck to him. *flame suit on* B
Linux/Open Source Training in Boston
What is the proper forum for posting about a Linux/Open Source Training Facility I have opened in the Boston/Somerville Massachusetts area? I only ask this because I am curious about giving discounts to open-source developers, so that I can pay back (in a small way) how open-source software has helped me and my business. I am close to a few groups that I am a member of, like the Debian group http://www.standardcode.com is the site. It's legit without any pop-ups selling Viagra or spam triggers. We have nothing to sell but knowledge. I don't want to step on anyone's toes or enrage anti-business forces, so if there is a general consensus on where I should give the invites, make the offer, do donations (I have spare hardware as well) etc. I would really like to know about it. I run Debian on my servers at the office, and I have 2 classes coming up near the end of this month: "Linux Admin" (in a vendor-neutral way) and "Running your own Mail Server", so I feel like time is of the essence in making this offer. After that is Photoshop (using Crossover Office emulation) and Python. These classes will run every month, as well as many others and nothing would make me happier than giving a break to people who need it (we already do discounted inner-city programs) and help evangelize open-source at the same time. This offer will be for the forseeable future, and doesn't have an pre-set expiration date. I really would like to get students involved, and give something back to the people I respect and (I feel) owe a debt to. Please, if this question has been asked before, let me know what the answer was, and any site with "best practices", etc. Thank you, Brendan
Re: why debian
On Friday 12 November 2004 09:03, Robert Parker wrote: > the MPAA / RIAA don't want you to do. Mandrake being more or less the most > "Windows" like distro stomps on any attempts to configure it the way you I am confused. How does it stomp on these attempts? On the desktops at my school, we have a mixed environ of PCLinuxOnline and Mandrake. Mandrake is beautifully configured, and I have custom KDE 3.3.1 on Mandrake 10.0 Official. I would like to know how it stomps on it...
Re: Linux Gaming (Was: Full replacement of MS)
On Tuesday 30 November 2004 01:30, Steve Lamb wrote: > Same here. That's the only reason my game machine is Win2k as the > primary boot instead of Linux. Xbox or PS2. Linux goes on hda1 > > Really? I haven't. I'm still bleary eyed from too much drinking and > > playing Unreal Tournament 2004 at the expense of sleep, > > Ungh. They blew it with UT2004. Don't care for the game so them > having a Linux version is worthless. :( To you. > Problem is most of their games suck. Of the latest batch of FPS games > Doom3 was dead last. Half-Life 2 and Far Cry both put the final nail in > the coffin of iD as anything more than a second rate game maker who happens > to make aweseme game engines. Ok, well, you disagree with 90% of the market I guess. > I'd love nothing more than to switch to Linux for gaming. I'm willing Then get a chair, because it's going to be years. Time to make other plans, I guess. Mod an Xbox. That's what I did, and Linux has been running 24/7 since. B
Re: If you really want Free firmware...
On Monday 13 December 2004 14:50, Andrew Suffield wrote: > On Mon, Dec 13, 2004 at 11:21:54AM -0800, Bruce Perens wrote: > > My surmise is that we'd need an effort like that, raising $250K, to > > design and go to full-custom fabrication of an FPLA with fully-open > > design. > > Mine is that one can get useful things done without having to spend > ridiculous amounts of money, or even any money at all. Yours is that > you can't. Debian proves you wrong every day. What does that have to do with hardware, please? I mean, it's a lovely statement and all, but it's wrong. > There is absolutely no reason why any money is needed for this. Design > the damn thing. Somebody will want to produce it. Manufacturing > companies would *leap* at the opportunity to make widely desireable > chips with zero royalty costs. "Somebody" and "widely desirable". Ok, do it and report back, soldier.
Re: If you really want Free firmware...
On Monday 13 December 2004 21:24, Andrew Suffield wrote: > > What does that have to do with hardware, please? > > I mean, it's a lovely statement and all, but it's wrong. > > Right back at you. Smarmy, but useless. Ok, I have figured out that you have nothing useful to say. Thank you. And from another post by you: "And yet you're quoting Redmond propaganda as if it were the only truth." We're talking about hardware, not Microsoft. Do you have any, *actual* hardware design experience? I do. You have a weird, uninformed, dork agenda that I don't even want to get into. Let it go, brother.
Re: mplayer, the time has come
On Friday 25 February 2005 05:39 am, Ron Johnson wrote: > On Fri, 2005-02-25 at 10:36 +0100, Marco d'Itri wrote: > > On Feb 25, giskard <[EMAIL PROTECTED]> wrote: > > > many people who I know, especially artists who use free software, often > > > use the reproduction in ascii art (new kind of art). > > > > The artists you know are not many people and they are not representative > > of the user base in any way. > > "I just don't understand how Reagan got elected. No one I know > voted for him!" > > In other words, just because *you* don't know anyone who uses AA, > that doesn't mean that a decent number of people *do* use AA. I have already decided to just compile mplayer myself. Too many weird decisions on this package being made for me...didn't even play half of my movies. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about debian-devel-announce
This thread is a huge waste of bandwidth. Can't you boys compare pickles somewhere else? This gets, (what's the expression?) a big ole fat PLONK. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
On Tuesday 07 June 2005 09:37 am, Roberto C. Sanchez wrote: > I agree. I rather like being able to configure run levels to my liking. I'm sorry, but this sets off my "Give me a break" reaction... There's nothing wrong with a "By Default, this runlevel is this...but you can change it if you wish"...You'll be getting rid of an easy-to-remember key that helps many newbies remember what the heck is going on "Oh, /etc/inittab says I start up in 3, that must mean it's multi-user with no GUI". To leave it up in the air so that a few people can dork out and define their own (yes, I'm kidding...but only a little) seems a bit like throwing over some ease-of-use for dorkin' it hardcore. I mean, it's not up to me, but if it was, I would have some easy-to-remember guidelines like "3 is multi-user with no X" "5 is full gui, etc." Remember, init 0 and 6 are well-defined already -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
On Tuesday 07 June 2005 07:09 pm, John Hasler wrote: > Roberto C. Sanchez writes: > > Where, pray tell, is a newbie going to learn about [runlevels]? > > a) By having used Red Hat. > b) By reading up on Linux before trying to use it (yes, some people _do_ >that). I couldn't have said it better. Roberto, what John said. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
On Tuesday 07 June 2005 09:23 pm, Roberto C. Sanchez wrote: > On Tue, Jun 07, 2005 at 09:20:56PM -0400, Brendan wrote: > > On Tuesday 07 June 2005 07:09 pm, John Hasler wrote: > > > Roberto C. Sanchez writes: > > > > Where, pray tell, is a newbie going to learn about [runlevels]? > > > > > > a) By having used Red Hat. > > > b) By reading up on Linux before trying to use it (yes, some people > > > _do_ that). > > > > I couldn't have said it better. > > Roberto, what John said. > > Point taken. I was thinking of how I came to Debian (from Windows > without reading a lick of documentation). If you don't believe me, > check out my postings from late '02 to earl '03 on d-u. I sound like a > total lamer :-) I am one of (maybe) the few people who has a Debian distro with a compiled KDE CVS on top of it, so I need some flexibility. I like booting to init 3 and having that always mean that it's just missing the startx command with /usr/local/kde/bin/startkde in it... I like to make sure my Mom is always running init5. Beyond those two, and 0 and 6, the rest I couldn't give a rat's a about run levels honestly. B -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
On Saturday 11 June 2005 08:34 am, David Weinehall wrote: > 2.6.25?! The current release pace for the 2.6-kernel is somewhere along > 2-3 months / kernel. The kernel version now is 2.6.11, but 2.6.12 is > out any day now, hopefully. Unless there are some radical changes, > there won't be more than 6-8 new kernels released 18 months from now. > So we're more looking at 2.6.20. Yes, and how overdue was Sarge? I think it's laughable to say what "will" happen. 2.6.25 may be a conservative estimate. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to the X team!!
On Thursday 14 July 2005 04:29 pm, Greg Folkert wrote: > But, I don't see the rendering problems others see. Of course I have an When I first started up xorg after the upgrade, it took a full 100% of the CPU. I restarted X, same deal...So I rebooted and started X, and the problem disappeared. Sid box. Other than that, my Mepis box at home took the upgrade as well. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bruce Perens hosts party at OSCON Wednesday night
On Tuesday 02 August 2005 08:16 pm, Steve Langasek wrote: > > Unsolicited Commercial Email. Please pay the standard $2000 fee for > > advertisments on Debian mailing lists. > > Y'know, it's fine if you think that Bruce's mail was inappropriate for the > list, and there's nothing wrong with saying so; but claiming that a message > that isn't selling anything is UCE, and attempting to enforce against a > member of the community an advertising policy that daily goes unenforced > against thousands of more deserving souls, just makes you sound like an > asshole and an idiot. Well said. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bruce Perens hosts party at OSCON Wednesday night
On Friday 05 August 2005 08:35 am, Russell Coker wrote: > On Friday 05 August 2005 11:14, Miles Bader <[EMAIL PROTECTED]> wrote: > > > Because the intent is obviously to forbid any sort of spam. > > > > "Spam", as I understand it, generally means UBE. Bruce's message > > clearly wasn't spam. > > The traditional definition of spam is UBE or UCE (that's the way it's been > for over 10 years). UCE is the most commonly used definition currently, > many newbies who have only used the net for 5 years or less think that spam > is only UCE, so the UCE category of spam is more commonly applied than the > UBE category. Ok, everyone has had a chance to show how large their schlongs are. Can we just let this thread die and let Bruce buy dinner for some people who need jobs? I pray that there are no ACTUAL problems in the future. With all the energy put into these discussions of something that's already happened, you'd think you could go put some effort into some code somewhere... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: FHS and /var/www
On Sunday 20 July 2008, Steve Langasek wrote: > On Sun, Jul 20, 2008 at 06:58:09PM +0100, Stephen Gran wrote: > I think it's perfectly in keeping with other parts of policy to ship our > webservers with /srv/www as the default webroot, and leave it up to the I think that this is a terrible idea. Leave well-enough alone. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: FHS and /var/www
On Monday 21 July 2008, Steve Langasek wrote: > Would the suggested /srv/www/localhost/htdocs as a default work for you? > Apparently this is widely deployed on other distros, and seems to be "Apparently" and "widely" lead me to think something is fishy with this suggestion. Centos/RedHat/Mandriva/Fedora don't seem to do it. We don't do it. Thereby Ubuntu doesn't do it. OpenSUSE does it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: what happened to social contract?
On Thursday 30 August 2007, [EMAIL PROTECTED] wrote: > Quoting Peter Samuelson <[EMAIL PROTECTED]>: > > I am not whining, I am questioning the validity of your claimed > philosophical values. Insults do not validate your point of view. "I'm not whining, I'm trolling". Ok, thanks for clearing that up for me. Plonk. *toilet flushes* -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: USB wireless
On Monday 18 October 2004 19:27, Tom Kuiper wrote: *Supposedly* http://www.softwareandstuff.com/NET10278.html > Does anyone know of a USB wireless device that can be used under Linux > without too much effort? > > Thanks > > Tom > -- > Internet: [EMAIL PROTECTED] (137.79.89.31) > SnailMail: Jet Propulsion Lab 169-506, Pasadena, CA 91109 > Phone/fax: (818) 354-5623/8895 > WWW:http://DSNra.JPL.NASA.gov/~kuiper/ > Required disclaimer: Any opinion expressed herein is my own.
Re: Delayed ldconfig execution in postinst step
On Tue, Mar 14, 2006 at 04:20:28AM -0600, Bill Allombert wrote: >I offer to implement a update-ldconfig program that would work the same >way update-menus work, by checking a lock and forking in the background >and waiting for the dpkg lock. It's more than just update-menus and ldconfig. update-menus is a work-around. A generic solution is required. I'm thinking of: dpkg-hook ACTION [ARGS1] [-- ARGS2] dpkg-hook --now ACTION [ARGS1] [-- ARGS2] The purpose of "-- ARGS2" is to allow postinsts which called programs such as fc-cache to batch multiple calls to the same executable with a concatenated list of arguments. There are various ways for dpkg-hook to determine the calling package, I'm guessing that the simplest would be for dpkg to set an environment variable before calling the script. So, each call to dpkg-hook would update /var/lib/dpkg/hooks (or whatever) with: ACTION [ARGS1]:[ARGS2 ...]:PKG, PKG dpkg would then run any pending hooks (with diagnostics as proposed by Eduard in <[EMAIL PROTECTED]>) by calling: dpkg-hook --run [PKG ...] either at the end of the configure step (with no PKG, specifying all pending), and whenever a pre-dependency was declared (with a list of dependant PKGs). --bod -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: python-minimal in base?
On Thu, Aug 24, 2006 at 01:45:26AM -0700, Steve Langasek wrote: >[...] upstream considered it completely unacceptable for anyone to >ship python in such a state that users would end up with less than the >full python suite installed on their system. [...] In fairness, Perl upstream had similar problems with Debian distributing their product piece-meal. The principal concern was the exclusion of documentation, which seems to have been assuaged by the addition of a stub for perldoc which instructs users to install the perl-doc package. --bod, noting that the INSTALL doc now includes the contents of Debian's perl-base as an example of a minimal install... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies, stage 4
On Tue, May 09, 2006 at 10:49:36PM +0200, Bill Allombert wrote: >Here the lists of packages involved in circular dependencies listed by >maintainers. > > perl > perl-modules These two packages are meant to be installed together, split only for arch any/all. I'm a bit puzzled as to why this is a problem, since this particular dependency exists in sarge and as far as I no caused no upgrade issues. Note that the dependency expressed is not exactly circular, since the perl-modules dependency on perl is "looser" than the inverse. Don't know if this matters for the problem you're trying to fix. --bod -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies, stage 4
On Wed, May 10, 2006 at 02:51:59PM +0200, Pierre Habouzit wrote: >Le Mer 10 Mai 2006 14:40, Brendan O'Dea a écrit : >> On Tue, May 09, 2006 at 10:49:36PM +0200, Bill Allombert wrote: >> >Here the lists of packages involved in circular dependencies listed >> > by maintainers. >> > >> >perl >> >perl-modules >> >> These two packages are meant to be installed together, split only for >> arch any/all. >> >> I'm a bit puzzled as to why this is a problem, since this particular >> dependency exists in sarge and as far as I no caused no upgrade >> issues. > >cycles are evil, so when you can avoid them, it's better, and here ... A specific problem, rather than a vague description of "evil" would help. >> Note that the dependency expressed is not exactly circular, since the >> perl-modules dependency on perl is "looser" than the inverse. Don't >> know if this matters for the problem you're trying to fix. > >perl-modules should not depends on perl. It's useless to have only >perl-modules installed, but this create no harm. > >moreover people just apt-get install perl, so that won't break anything. That would be true if perl depended on perl-modules (= current-ver). The current dependencies are used to allow a slightly newer version of perl-modules to be installed: porters had issues in unstable where perl was uninstallable due to the package not having built on an architecture.* Simply having perl depend on perl-modules (>= current-ver) is more problematic than the case you describe, since a sarge user may upgrade just perl-modules 5.8.4-x to 5.8.8-y, retaining the older perl package and things would go pear-shaped. --bod * ISTR some discussion about modifications to the archive suite which would keep binary packages from the same source package together on a per-arch basis, which would resolve this particular issue. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies, stage 4
On Wed, May 10, 2006 at 03:01:21PM +0200, Henning Glawe wrote: >On Wed, May 10, 2006 at 10:40:32PM +1000, Brendan O'Dea wrote: >> On Tue, May 09, 2006 at 10:49:36PM +0200, Bill Allombert wrote: >> >Here the lists of packages involved in circular dependencies listed by >> >maintainers. >> > >> >perl >> >perl-modules >> >> These two packages are meant to be installed together, split only for >> arch any/all. >> >> I'm a bit puzzled as to why this is a problem, since this particular >> dependency exists in sarge and as far as I no caused no upgrade issues. > >what about the issue showing up in conjunction with doc-base? both perl and >perl-modules were installed, but not in matching versions (due to apt being >confused about the circular dep) during the upgrade >from 5.6 to 5.8, which made packages calling install-docs in their >maintainer scripts fail, if I remember correctly... Different issue. The problem there was outside of the scope of dependencies: since install-docs gets called conditionally, packages don't declare a dependency on doc-base, so don't get the dependency on perl and install-docs may be called before all required packages are configured. Having install-docs work only with essential packages (perl-base) fixes that problem (fixed in 0.7.18-0.1). See http://lists.debian.org/debian-perl/2004/12/msg0.html and http://bugs.debian.org/278495 for details. --bod -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies, stage 4
On Wed, May 10, 2006 at 04:20:19PM +0200, Pierre Habouzit wrote:
>Le Mer 10 Mai 2006 15:44, Brendan O'Dea a écrit :
>
>> The current dependencies are used to allow a slightly newer version
>> of perl-modules to be installed: porters had issues in unstable
>> where perl was uninstallable due to the package not having built on
>> an architecture.*
>
>Package: perl
>Depends: perl-modules (>= ${source:Version})
>
>achieves that IMHO.
Yes, that's exactly what is used now.
>> Simply having perl depend on perl-modules (>= current-ver) is more
>> problematic than the case you describe, since a sarge user may
>> upgrade just perl-modules 5.8.4-x to 5.8.8-y, retaining the older
>> perl package and things would go pear-shaped.
>
>that is higly unlikely since nothing should depends only from
>perl-modules. (In fact, IMHO nothing should depends from perl-modules
>at all).
Correct. I'd prefer that nothing did. See however the output of
'apt-cache rdepends perl-modules'.
Selecting a random entry from that list with a versioned dependency,
'munin':
Depends: perl (>= 5.6.0-16), perl-modules (>= 5.8.0) |
libparse-recdescent-perl, [...]
>so the only way for a user to upgrade perl-modules only is to apt-get
>install perl-modules which looks like an awkward thing to do.
People do. Particularly those with limited network connectivity.
Consider a sarge dialup user who wants a newer version of
libcgi-pm-perl, so adds unstable to sources.list and tries
apt-get install libcgi-pm-perl
sees
Package libcgi-pm-perl is a virtual package provided by:
perl-modules 5.8.4-8sarge5
You should explicitly select one to install.
So chooses to run
apt-get install perl-modules
>moreover:
>
>Package: perl-modules
>Conflicts: perl (<< ${source:Version})
>
>looks like achieving what you want.
Perhaps (although using ${Upstream-Version}-1).
That does seem to work for a dist-upgrade to sid from sarge (after
manually tweaking the depends/conflicts on perl-modules in
/var/lib/apt/lists/*).
A bit gun-shy about adding conflicts to perl since the 5.005 -> 5.6.0
transition, which produced some upgrade disasters like
http://lists.debian.org/debian-perl/2001/02/msg00031.html (apt choosing
to remove the conflicted target and all dependent packages...)
Will consider for the next upload.
--bod
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies, stage 4
On Wed, May 10, 2006 at 07:31:58PM +0200, Dagfinn Ilmari Mannsåker wrote: >Brendan O'Dea <[EMAIL PROTECTED]> writes: > >> On Wed, May 10, 2006 at 04:20:19PM +0200, Pierre Habouzit wrote: >>> (In fact, IMHO nothing should depends from perl-modules at all). >> >> Correct. I'd prefer that nothing did. > >Is this documented anywhere? If is really is the case that nothing >should depend on perl-modules (but rather on perl itself), the Perl >Policy should mention it in the dependencies section. Perl Policy is intentionally vague about the way that the package is split up (into perl, perl-modules or whatever). The intent was to allow the maintainer to choose the most appropriate split (if any) and to mandate only the existence of `perl-base', and ensure that installing the package `perl' would provide a working Perl interpreter. Section 5.2 describes program dependencies, and refers only to `perl' or `perl-base'. The first paragraph could perhaps be re-worded as: Programs which require Perl modules must specify a dependency on the `perl' package. Note that it doesn't say that you shouldn't depend on perl-modules, merely that you must depend on perl. >> Selecting a random entry from that list with a versioned dependency, >> 'munin': >> >> Depends: perl (>= 5.6.0-16), perl-modules (>= 5.8.0) | >> libparse-recdescent-perl, [...] > >Speaking as co-maintainer of munin, should we just change that to "perl >(>= 5.8.0) | libparse-recdescent-perl" instead? Won't lintian complain >about a duplicate relation on perl in that case, or has that been fixed? > >(We want the packages to be installabe on woody with the minimum amount >of fuss, so we don't want to just depend on perl (>= 5.8.0)). That dependency is fine. I chose it as an example of where not having the reverse dependency could cause problems. This is the sort of thing which I'd prefer not to see: Package: vrms Depends: perl-modules perl would be correct. Package: libdbi-perl Depends: perl (>= 5.8.4-5) | perl-modules, perlapi-5.8.4, libc6 (>= 2.3.5-1), libplrpc-perl A specific version of perl or *any* version of perl-modules? Package: babygimp Depends: perl, perl-modules, perl-tk Redundant. Package: pdbv Depends: perl-base (>= 5.6.0), perl-modules, liblocale-gettext-perl, libtie-ixhash-perl, coreutils (>= 4.5.0) | fileutils (>= 4.1), debconf (>= 1.0.32) The first two should be replaced by "perl (>= 5.6.0)". etc. --bod -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#368383: dumb "manual page for..." NAME section on many man pages
>dotlock (1) - manual page for dotlock (GNU Mailutils 0.6.93) This is the default NAME section generated by help2man. Fairly useless, but there needs to be *some* default. Suggest that you file bugs on the particular packages which need either to provide a --name="short description" argument, or a the "[name]" block in an --include file (see coreutils/man/*.x for examples of the latter usage). --bod -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#368383: dumb "manual page for..." NAME section on many man pages
On Mon, May 22, 2006 at 10:29:16PM -0700, [EMAIL PROTECTED] wrote: >Glad that you guys will take care of this, as it is way over my head. It's not complex. The problem manual pages have been generated with a program [help2man] which interprets a program's --help output. Unfortunately, it's not possible to reliably extract a short description of the program from that output to use as the NAME section (this appears in the whatis/apropos output) The maintainer needs to add that data when generating the page either with the --name option to help2man, or via a [name] section in an include file. I've cloned the bug for mailutils (dotlock), libfribidi0 (fribidi) and recode. Feel free to raise new bugs on other packages. --bod -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Cleaning /var/lib/dpkg/available
On Wed, Jun 14, 2006 at 02:03:21PM +0200, Daniel Kobras wrote: >On Wed, Jun 14, 2006 at 01:34:36PM +0200, Jérôme Warnier wrote: >> I've been upgrading my machines since Woody to Sarge, then to Etch. Now, >> my /var/lib/dpkg/available are huge (15MB), and it seems they never get >> cleaned. >> How am I supposed to clean them? Isn't there any automated tools in >> Debian to do that? > >Try 'dpkg --forget-old-unavail'. That option --forget-old-unavail clears entries from /var/lib/dpkg/status for uninstalled packages which aren't in available. The available file contains all the currently available packages and should not require cleaning. This file gets updated by dselect's update option, which for a backend of apt is basically "apt-cache dumpavail". So on my ppc (unstable): $ apt-cache dumpavail | wc -c 16944732 $ apt-cache dumpavail | grep -c ^Package: 18183 I end up with an available file of roughly 17M containing 18 thousand odd packages. This is normal. --bod -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Regexp to parse "Version:" fields
On Wed, Jun 21, 2006 at 01:56:21PM +0200, Christoph Haas wrote:
>for mentors.debian.net I would like to find a perfect (TM) regular
>expression to split the "Version:" line of a control file into:
>
> - epoch
> - upstream version
> - Debian package revision
>
>My current attempt is:
>
> ^(?:(\d+):)?(\d[\w\.\+-:]*?)(?:-(.+))?$
If you really want a single regex you could use:
^(?:([^:]+):)?(.*?)(?:-([^-]+))?$
My inclination however would be to use multiple steps to split the
version:
my $epoch = '';
my $debver = '';
for ($version)
{
$epoch = $1 if s/^([^:]+)://;
$debver = $1 if s/-([^-]+)$//;
}
--bod
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: additions to dpkg-architecture
On Fri, Jun 23, 2006 at 06:54:49PM +0200, Volker Grabsch wrote: >I propose to add more CPU types to dpkg-architecture. In particular, >I'd like to see the different i386 architectures there, i.e. >i586, i686, k6, ... [...] >For instance, some programs with lots of calculations (e.g. mplayer) >are compiled with different processor optimizations (e.g. mplayer-i586). >Such packages are created by very redundant entries in debian/rules. >Exactly such redundancy is removed by dpkg-cross. While there are certainly some packages which may benefit from compilation with sub-architecture optimisations, those packages are the exception rather than the norm. It may make sense to provide multiple versions of the kernel for example, and perhaps glibc... but coreutils? grep? Do you propose re-building all packages for each sub-arch? If so, please consider the resulting increace in archive size and impact on mirrors. If only a sub-set, how are you intending to change dpkg, apt and/or the archive software to handle opportunistic installation of sub-arch packages with fallback (i.e. try foo.i686, fallback to foo.i386)? --bod -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A question on setting setuid bit
On Wed, Jul 05, 2006 at 04:02:43AM -0400, sean finney wrote: >On Wed, Jul 05, 2006 at 04:39:12PM +1000, Matthew Palmer wrote: >> dpkg-statoverride is a tool for the system administrator to specify a >> different mode or ownership for a file to that which is provided in the >> package. It is not meant to be used by the package. > >there are cases where it's appropriate for a package to use it. for >example, if the package creates the user that is supposed to own a file, >and later changes the ownership to that user in the maintscripts. in >this case it would be appropriate to use this tool to check if the >local admin has overrided the permissions, and if so, keep the >permissions respected. There are two cases where shipping the binary with the correct ownership or permission is not possible: * the user meant to own the files is dynamically created, or * the permissions for a file are a debconf option In such cases it is necessary in the postinst to do: if ! dpkg-statoverride --list $file >/dev/null 2>&1 then chown $user:$group $file # and/or chmod $mode $file fi Which will only set the permissions if the local administrator has not supplied other values. Just looking at various postinst scripts now, I note that some packages use dpkg-statoverride to apply the changes rather than chown/chmod. Not quite sure of the rationale behind this. In my opinion, setting permissions via dpkg-statoverride should be limited to the local admin only. It also means that you need to remove the override in the postrm and complicates the case where you wish to change the default values used. In both cases you need to compare the values returned by --list and only remove/change if those values match what was previously set by the package. Even with this test, there is *no way to be sure* that the override was originally set by the package. Could be that the administrator set the override with those values to ensure they didn't change. Summary for maintainer scripts: * Don't use chown/chmod in without first testing dpkg-statoverride --list. * Don't use dpkg-statoverride to apply owner/group/mode changes. --bod -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Bug Tracking System
Package: debbugs Version: 2.4.1 Severity: wishlist Tags: patch On Sat, Jul 08, 2006 at 01:02:44AM +0530, Ritesh Raj Sarraf wrote: >If I need to subscribe to a bug I can't use the web interface. >The answer you might give is, "Oh! Send am email to >[EMAIL PROTECTED]" This may be a simple way to add that behaviour. --bod diff -Naur debbugs-2.4.1.orig/cgi/bugreport.cgi debbugs-2.4.1/cgi/bugreport.cgi --- debbugs-2.4.1.orig/cgi/bugreport.cgi2003-05-26 02:26:24.0 +1000 +++ debbugs-2.4.1/cgi/bugreport.cgi 2006-07-08 10:43:23.900414007 +1000 @@ -417,6 +417,7 @@ print "$descriptivehead\n"; printf "View this report as an mbox folder.\n", mboxurl($ref); +print "mailto:[EMAIL PROTECTED]">Subscribe to this bug. print ""; print "$log"; print $tail_html; -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Bug Tracking System
On Fri, Jul 07, 2006 at 08:19:12PM -0700, Don Armstrong wrote: >On Fri, 07 Jul 2006, Matthew R. Dempsky wrote: >> What about something like ``To subscribe to this bug, send an empty >> email to $email.'' to make more explicit that they >> don't need to fill anything out? > >There are a whole host of commands which can be set using e-mail; I'm >not averse to adding a link to subscribe to the bug, but adding >unnecessary verbiage on every single page seems pointless to me. Agreed, hence the suggestion for a simple link. If anything, I think that I'd encode the instructions in the URL: mailto:[EMAIL PROTECTED]&body=not%20required --bod -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: netstd split results in loss of functionality
On Mon, Mar 13, 2000 at 12:42:54AM -0500, Daniel Martin wrote: >Speaking of which, where did netdate go? I've been wondering for a >while what happened to it. rdate may do what you are after. Regards, -- Brendan O'Deabod@compusol.com.au Compusol Pty. Limited (NSW, Australia) +61 2 9809 0133
Re: apt-get cron job
On Tue, Mar 21, 2000 at 10:42:44PM -0400, Peter Cordes wrote:
> I've got a useful cron job that many of you may find useful. It uses
>apt-get to download updated packages in the wee hours of the morning while
>the rest of the internet sleeps (well, at least most of it sleep :). I
>mentioned it on my local LUG list, and Ben Armstrong gave me some helpful
>advice. First, it is too small to package by itself, and second, he
>recommended asking some of my questions on debian-devel, so here I am :)
>
> I use this line in /etc/crontab on my woody system:
>42 6* * sun root/usr/bin/apt-get update ; /usr/bin/apt-get -q -d -y -u
>dist-upgrade ; /usr/bin/apt-get autoclean
You might consider changing the order to clean the cache before
downloading the new packages, and making each step dependant on the
previous.
42 6 * * sun root apt-get update && apt-get autoclean && \
apt-get -q -d -y -u upgrade
Regards,
--
Brendan O'Deabod@compusol.com.au
Compusol Pty. Limited (NSW, Australia) +61 2 9809 0133
Re: Intent To Split: netbase
On Monday, 14 August 2000 at 14:20, Manoj Srivastava wrote: > Hi, > > >>"John" == John Goerzen <[EMAIL PROTECTED]> writes: > > John> Herbert Xu <[EMAIL PROTECTED]> writes: > >> Please also note that other daemons conflict with each other well, e.g., > >> inn & cnews, sendmail & postfix. > > John> I am aware of that, and it's a shame, there is no real reason that > John> they cannot coexist. > > No real reason? Only one package can listen in on port 25, and > only one package may be linked to /usr/lib/sendmail. Now the latter > may be handled by using diversions/alternatives, but I fail to see > how the former can be handled. (similar arguments for NNTP servers) > > Seems like there are *real* reasons. There may be partial work > arounds, but the conflict does seem reasonable. I agree with you in general. But it would be nice if packages that conflicted on, say, portnumber, could let you choose another port to run them on, and maybe give the official port to one particular program (like alternatives for portnumbers). I realise quite a lot of programs have hardcoded portnumbers in the upstream source, and that for most purposes it wouldn't often be super useful, but it does have certain advantages. For instance, on my machine I have uw-imap, cyrus-imap and courier-imap all installed on different ports so I can test out my IMAP client code against the three of them. Since they all conflict I have to install and maintain at least two of them by hand... well, that's the motivation behind my stupid wishlist :) -- Don't make Godzilla mad! pgpzmZpHoxQwx.pgp Description: PGP signature
Re: X and runlevels
On Mon, Sep 04, 2000 at 11:30:06AM +0200, Per Lundberg wrote: [...] To get it to boot up in >console mode, you have to manually remove the symlinks in your >runlevel's script directory. The next time you update the display >manager, you'll have to do this again. It is not really convenient. Upgrading xdm should not affect the links in /etc/rc?.d as update-rc.d (called in the postinst) is a no-op if any links for the script already exist. Regards, -- Brendan O'Deabod@compusol.com.au Compusol Pty. Limited (NSW, Australia) +61 2 9809 0133 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: fix for daemon start on package install/upgrade out-of-runlevel
On Sat, Sep 09, 2000 at 08:32:24PM -0400, Adam McKenna wrote: >On Sat, Sep 09, 2000 at 06:23:03PM -0400, Robert D. Hilliard wrote: >> Adam McKenna <[EMAIL PROTECTED]> writes: >> >> > >> > On Sat, Sep 09, 2000 at 04:03:50PM -0400, Robert D. Hilliard wrote: >> > > ps ax|grep |grep -v grep works for me. >> > >> > if [ "`pidof `" ] ; then >> > ... >> > fi >> >> For some reason pidof doesn't work on the dictd daemon, so it may >> not work on others as well. See Bug#67021. > >[EMAIL PROTECTED]:/usr/share/doc/dictd$ ps auxww | grep dict >nobody 16216 0.2 0.6 1768 876 ?S20:26 0:00 dictd 1.4.9: >0/0 >adam 16218 0.0 0.3 1112 412 pts/6S20:26 0:00 grep dict >[EMAIL PROTECTED]:/usr/share/doc/dictd$ pidof "dictd 1.4.9: 0/0" >16216 > >Looks like it's working fine to me. As the numbers on the RHS change this is hardly a solution for maintainer upgrade scripts. The problem is that dictd stuffs the lot into argv[0] separated by spaces. I suspect that if it were to use \0 to delimit the words pidof would work fine. A workaround for dictd is to use -x which additionally checks the basename against the value in parens from /proc/*/stat. Both pidof and killall tend to work best when given a full pathname in which case the dev/ino of each /proc/*/exe is compared to that of the argument, avoiding the whole issue of whether or not the program has manipulated argv. This unfortunately doesn't work if you are trying to kill the previous version of a daemon in the postinst of a package, as the binary will have changed. # pidof dictd | xargs -r ps # pidof /usr/sbin/dictd | xargs -r ps PID TTY STAT TIME COMMAND 14769 ?S 0:00 dictd 1.4.9: 0/0 # pidof -x dictd | xargs -r ps PID TTY STAT TIME COMMAND 14769 ?S 0:00 dictd 1.4.9: 0/0 Regards, -- Brendan O'Deabod@compusol.com.au Compusol Pty. Limited (NSW, Australia) +61 2 9810 3633 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DEBIAN IS LOOSING PACKAGES AND NOBODY CARES!!!
On Sun, Dec 31, 2000 at 01:09:07PM +, Oliver Elphick wrote: >Peter Palfrader wrote: > >> There is a further weird package disappearance in unstable: all mgetty > >> packages (execept mgetty-doc) are gone! [...] > >> Hey, these are important packages. > > > >mgetty is not important, it's extra. > >That may be, but where has it gone? mgetty* got bitten by an old [pre-pool] dinstall bug, where uploads without "unstable" in the changelog disappear from unstable: mgetty (1.1.21-3) stable; urgency=low * make mgetty-fax's postinst create /var/spool/fax/outgoing/.last_run to close a potential symlink exploit by members of the fax group that is otherwise possible until that file is created -- Philip Hands <[EMAIL PROTECTED]> Thu, 31 Aug 2000 19:05:13 +0100 See http://bugs.debian.org/77585 . Regards, -- Brendan O'Deabod@compusol.com.au Compusol Pty. Limited (NSW, Australia) +61 2 9810 3633
Re: Perl symbol problem - release critical (Re: Bug#489132)
On Fri, Jul 4, 2008 at 6:17 AM, Raphael Hertzog <[EMAIL PROTECTED]> wrote: > This is why I suggested to integrate liblocale-gettext-perl in perl-base > itself. This would be the simplest/nicest solution IMO. It would always be > synchronized with the current perl. > > See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=479681 I'm inclined at this point to follow this suggestion. --bod -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Parallel build results
On Sun, Dec 02, 2007 at 11:13:53PM +, Ben Hutchings wrote: >It appears that ExtUtils::MakeMaker, a standard Perl module commonly >used to generate Makefiles for Perl modules, emits the rule: > >install :: all pure_install doc_install > >This appears to account for the failure of some of my Perl packages, and >probably many others. This should be fixed in MakeMaker, not in the >packages that use it. About the only option I can see is to use something like: install :: all $(MAKE) pure_install doc_install which I'm not terribly keen on. I'm open to better suggestions. --bod -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Parallel build results
On Sun, Dec 30, 2007 at 02:17:05PM +0100, Michael Tautschnig wrote: >I don't actually remember the part of this discussion where the real cause of >the problem with the above rule was discussed, but in case it is about some >dependencies between the rules (which is the most likely IMHO), then it should >really be fixed as follows > >doc_install: > ... > >pure_instal: doc_install > ... > >all: pure_install > ... > >install:: all > ... Thanks, not exactly what I need but sufficient to provide a solution: push the "all" dependency from "install" down to each of the targets which may be run in parallel. install: pure_install doc_install ... pure_install: all ... doc_install: all ... --bod -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: perl: 64-bit integers and long doubles
On 4 May 2010 22:54, Niko Tyni wrote: > unlike earlier versions, perl 5.12.0-1 in experimental is configured with > the "use64bitint" and "uselongdouble" options on all architectures. I'm > looking for input on whether this is the right choice for sid. Sounds like a good idea to me. I had intended to do this for 5.10, as noted in #310995, but it appears to have slipped through the cracks at the time. > It would be possible to choose these settings separately for each > architecture. > Should I exclude the 'smaller' architectures (armel, mips*?) You could ask debian-...@lists.debian.org and the other ports lists, but it seems reasonable to include 64bit support only on those architectures where there is native 64 bit support in the chipset. > A complication is that it's hard to change these settings after an upload > to unstable because they change the binary interface. The perlapi-* > dependencies specified in the Perl policy only allow for ABI breaks when > the upstream version changes, so the transition would be a mess. > > See #579457 for an idea of how to make a cleaner transition possible; > even with that, it would be very much preferrable to get this "right" > the first time. I suspect that you may be over-thinking this. More comments in that bug shortly. --bod -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikrlwvlfcjpi5v0do16lci6t2ypkake39f1l...@mail.gmail.com
Re: perl 5.6 dependent packages
On Sat, Aug 24, 2002 at 02:49:10PM -0400, Joey Hess wrote: >perl 5.8 will enter unstable at the next dinstall run. Before it can >make testing though, we have to update the following 84 packages which >still depend on perlapi-5.6.*. This list should take into account those >packages that were already NMU'd. > >[EMAIL PROTECTED]:~>grep-available -F depends perlapi-5.6 -s package Note that in addition, since perl 5.8.0 includes some modules which were previously stand-alone, any package declaring a versioned[0] dependency on: libdigest-md5-perl, libmime-base64-perl, libnet-perl, libtime-hires-perl, libstorable-perl, libattribute-handlers-perl, libcgi-perl, libi18n-langtags-perl, liblocale-maketext-perl, libmath-bigint-perl, libnet-ping-perl, libtest-harness-perl, libtest-simple-perl needs to either have the version for that dependency removed, or just to depend on perl (>= 5.8.0). [0] The 5.8.0 perl packages do provide these so un-versioned dependencies are fine, dpkg/apt just don't support versioned provides. --bod
Re: libwww-perl
On Sat, Aug 24, 2002 at 09:56:05PM -0400, Clint Adams wrote: >>Has anyone had any luck building libwww-perl against perl 5.80 >> yet? > >Check http://ftp-master.debian.org/~bod/perl/pool/libw/libwww-perl/ Everything from that pool with the exception of libwww-perl was pushed into unstable last night. libwww-perl was omitted by request of Joey, who made the NMU: "I've uploaded libwww-perl since a lot of stuff needed it, but it fails some regression tests and should be kept out of the main archive, please." The current version fails one test. There is a newer version (5.65) available upstream which appears to build cleanly; the changelog reads: Make HTTP::Date compatible with perl 5.8. >Incidentally, the libdbi-perl there has a lower delta (1.1) than the one >in sid (2). Entrirely possible. In any case that staging repository is now gone. --bod
Re: perl 5.6 dependent packages
On Mon, Aug 26, 2002 at 09:33:51AM +0200, Jérôme Marant wrote: >On Sun, Aug 25, 2002 at 06:44:00AM +1000, Brendan O'Dea wrote: >> Note that in addition, since perl 5.8.0 includes some modules which were >> previously stand-alone, any package declaring a versioned[0] dependency >> on: >> >> libdigest-md5-perl, libmime-base64-perl, libnet-perl, >> libtime-hires-perl, libstorable-perl, >> libattribute-handlers-perl, libcgi-perl, libi18n-langtags-perl, >> liblocale-maketext-perl, libmath-bigint-perl, libnet-ping-perl, >> libtest-harness-perl, libtest-simple-perl >> >> needs to either have the version for that dependency removed, or just to >> depend on perl (>= 5.8.0). > > If those package are still going to be shipped separately (because > they're going to evolve outside the perl core), then they should stay > in the archive and perl must add Provides for them. Hence, the user > can still choose to use either those in the perl core, or the > sperate ones (maybe more recent at some point). You're missing the point. The problem is that some packages have *versioned* dependencies on those packages: "smokeping" for example depends on "libdigest-md5-perl (>= 2.13-2)". While perl does have a provide for "libdigest-md5-perl", it's not considered as there is no version associated. So the dependencies on that (and other packages) need to be changed. As far as retaining the stand-alone versions of [now] uninstallable perl modules in the archive goes, is there any point? They can be re-packaged if/when the need arises. --bod
Re: kernel-{image,headers} package bloat
On Thu, Apr 26, 2001 at 04:15:24PM +1000, Craig Sanders wrote: >On Wed, Apr 25, 2001 at 09:56:58PM -0500, Rob Browning wrote: >> Just in case anyone else was confused, I'm still in favor of having at >> least *one* precompiled kernel per-architecture, so no one *has* to >> compile a kernel, > >i think everyone is in favour of that. > >the issue is whether it's appropriate to have a dozen or so kernel-image >packages (and associated kernel-headers packages) per kernel version, >when one(*) will do. Don't forget the proliferation of kernel modules in that count. This has already started with alsa recently, and I expect that more will follow before too long: alsa-modules-2.4.3-386 alsa-modules-2.4.3-586 alsa-modules-2.4.3-586tsc alsa-modules-2.4.3-686 alsa-modules-2.4.3-686-smp alsa-modules-2.4.3-k6 alsa-modules-2.4.3-k7 alsa-modules-2.4.3-pentium4 alsa-modules-2.4.3-pentiumiii alsa-modules-2.4.3-pentiumiii-smp kernel-headers-2.4.3 kernel-headers-2.4.3-386 kernel-headers-2.4.3-586 kernel-headers-2.4.3-586tsc kernel-headers-2.4.3-686 kernel-headers-2.4.3-686-smp kernel-headers-2.4.3-k6 kernel-headers-2.4.3-k7 kernel-headers-2.4.3-pentium4 kernel-headers-2.4.3-sparc kernel-image-2.4.3-386 kernel-image-2.4.3-586 kernel-image-2.4.3-586tsc kernel-image-2.4.3-686 kernel-image-2.4.3-686-smp kernel-image-2.4.3-k6 kernel-image-2.4.3-k7 kernel-image-2.4.3-pentium4 Regards, -- Brendan O'Deabod@compusol.com.au Compusol Pty. Limited (NSW, Australia) +61 2 9810 3633
Re: updating of /etc/rc?.d
On Wed, Apr 25, 2001 at 09:43:56PM -0400, Jason Lunz wrote: >[EMAIL PROTECTED] said: >> I've thought for a while that perhaps update-rc.d should have a >> --persistant option that would do the same thing as "remove" AND add a >> K symlink in /etc/rc9.d/ -- a valid but unused runlevel -- so that >> users could permanently disable things in one swift commandline. > >This is dpkg bug #67095. Is there any progress on this? I would love it >if I didn't have to re-disable nfs and portmap each time I upgraded >their packages. It is possible to disable a service simply by removing links in /etc/rc*.d . So long as you leave at least one (/etc/rc0.d/K*package would seem to be a good candidate), update-rc.d when called by packages on upgrade is a no-op. Something like: rm /etc/rc*.d/S*package should generally do the trick. Note, now that netbase has changed the dependency on portmap to a `suggests' you may remove it anyway. Regards, -- Brendan O'Deabod@compusol.com.au Compusol Pty. Limited (NSW, Australia) +61 2 9810 3633
Re: updating of /etc/rc?.d
On Thu, Apr 26, 2001 at 01:30:41PM -0400, Jason Lunz wrote: >[EMAIL PROTECTED] said: >> What's wrong with adding an exit 0 to the init.d files? > >dpkg will ask me whether I want to keep my changes each time I upgrade, >rather than just overwriting the script. I believe that dpkg only does that when the maintainer has changed the script in the newer version. Regards, -- Brendan O'Deabod@compusol.com.au Compusol Pty. Limited (NSW, Australia) +61 2 9810 3633
Re: Runlevel for powersaving
On Wed, May 02, 2001 at 02:01:26PM -0400, Alan Shutko wrote: >Arthur Korn <[EMAIL PROTECTED]> writes: > >> Looking at apmd(8), it seems "change power" would fit, but >> unfortunately it doesn't tell you wheter AC was plugged in or >> out. > >Your script could query `apm | grep on-line` or something. The apmd package contains a little program called /usr/bin/on_ac_power to determine the AC/battery status. Regards, -- Brendan O'Deabod@compusol.com.au Compusol Pty. Limited (NSW, Australia) +61 2 9810 3633
Re: Two debconf issues
On Sat, May 05, 2001 at 02:03:59AM +0300, Shaul Karl wrote: >Can you compare Perl speed to Python? >Just curious, have no prior knowledge on this. Can you? Of course you can. Has someone? Very probably, although I can't recall seeing an instance off-hand. "Compare Perl speed to Python" is pretty open ended question though. In general? For task X? Task Y? While it doesn't mention Python specifically, there is a very interesting paper by Kernighan and Van Wyk describing some experiments with various tasks in different languages which is germane to this thread: Timing Trials, or, the Trials of Timing http://www.cs.bell-labs.com/cm/cs/who/bwk/interps/pap.html Regards, -- Brendan O'Deabod@compusol.com.au Compusol Pty. Limited (NSW, Australia) +61 2 9810 3633
Re: Using perl to build perl
On 16 April 2016 at 19:20, Niko Tyni wrote: > For a long time, src:perl has had some limited support for bootstrapping a > new architecture without /usr/bin/perl. We've gone to quite some trouble > to avoid needing perl to build perl as far as possible, including quite > a few sed scripts and a 600-line monstrous debian/rules file so we don't > need debhelper. However, things like dpkg-shlibdeps and dpkg-gencontrol > which are required for building .deb packages are #!/usr/bin/perl scripts, > so this is arguably somewhat ineffective. This was added at the request of porters in 2001 or so. I can't find anything in my mail archives from the time, so I suspect that the conversation was on IRC and would guess one of ia64 or hppa which were the ports in flight around that time. Initially I just included a subset of debhelper, which I updated periodically to break a circular build-dependency b/w perl and debhelper, but eventually removed the debhelper bits entirely, and arranged debian/rules such that perl was not used at all until perl.static was available, and checkperl was run prior to any indirect execution (dpkg-shlibdeps, dpkg-gencontrol) with instructions to make those work: in hindsight, those could have probably been silently handled by executing them using the built perl.static. At the time this was definitely tested in a chroot, but skimming the rules file now I can see that there are places where stuff has crept in: use of dpkg-architecture and dpkg-parsechangelog stick out immediately. > So if we started to build-depend on debhelper and therefore transitively > perl, would anybody actually care? I'm fairly confident that there would be complaints if you made that change: https://wiki.debian.org/DebianBootstrap https://wiki.debian.org/CircularBuildDependencies This looks interesting though: https://wiki.debian.org/BuildProfileSpec It appears that it may be possible to do something like this: Package: perl-stage1 Build-Profiles: Architecture: any ... Package: perl-base Build-Profiles: Architecture: any Conflicts: perl-stage1 Replaces: perl-stage1 ... similarly add "Build-Profiles: " to all other packages. Then change debian/rules to contain: ifneq ($(filter stage1,$(DEB_BUILD_PROFILES)),) include debian/rules.stage1 else include debian/rules.standard endif debian/rules.standard would contain what debian/rules does now, but cleaned up to use debhelper. A basic debian/rules.stage1 is attached. It's not particularly pretty, but appears to work and shouldn't need to change much. I presume that once all of this is done, debhelper can then depend on "perl | perl-stage1", which would allow the normal perl packages to build-depend on debhelper. Looping in Wookey who from the authorship of some of those documents may be able to add more knowledgeable suggestions. --bod rules.stage1 Description: Binary data
