On Saturday 07 August 2010, Neil McGovern wrote:
> As there isn't a resolution in sight, I'll add a hint at the end of
> August for the removal of the package unless there's significant
> progress to fixing the issue.
I still feel this is an overreaction as only the original reporter has ever
see
Petter Reinholdtsen wrote:
> [Steve Langasek]
>> Not only is apt-get now strong enough to handle the cases for which we
>> recommended aptitude in the sarge timeframe (with much better resolution
>> of upgrades, installation of Recommends by default, and tracking of
>> auto-installed packages), but
Russ Allbery wrote:
> [...] or between optional and extra, for *any* package?
I must admit that I've never seen the practical value of that distinction.
As to the rest of your message: it certainly seems worth discussing this in
a bit wider context.
--
To UNSUBSCRIBE, email to debian-devel-re
Steve M. Robbins wrote:
> This is due to Debian Policy 2.5:
>
> Packages must not depend on packages with lower priority values
> (excluding build-time dependencies). In order to ensure this, the
> priorities of one or more packages may need to be adjusted.
>
> Why is this the policy? Why does
Steve Langasek wrote:
> This manual represents the opinion of a single developer.
And what does that have to do with the price of bananas in Iceland?
The fact that aptitude is currently the recommended tool for package
management has various reasons: user interface, features, dependency
handlin
reopen 505609
reassign 505609 linux-2.6
affects 505609 lilo
thanks
Stephen Powell wrote:
> The real question is, "Why didn't the map installer get run during
> the kernel upgrade?"
[...]
> So is this a bug in the kernel maintainer scripts? Or is it a feature?
> I don't know. I'll leave that up
> dash recently added support for the magic variable $LINENO, which was
> the last piece to make it POSIX compliant. However, this change made the
> autoconf- generated configure scripts use dash to execute the script's
> code. Without support for LINENO, configure scripts exec to bash
> automatica
Hi,
I would have expected a final point release for Etch to have happened by
now (since security support was ended back in February). My personal
interest is of course the D-I updates included for that release.
Could the (oldstable) release team please clarify the status and planning?
TIA,
FJP
On Saturday 08 May 2010, Julien Cristau wrote:
> alpha is all 64.
Shows that alpha is the arch I'm least familiar with...
> and sparc kernel is 64.
This I should have gotten right :-(
Thanks.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". T
Niko Tyni wrote:
> Can anybody list our "pure" 32-bit architectures off-hand
> or suggest a simple test?
AFAIK for Squeeze the arches are as follows, but please anybody correct me
where incorrect.
archkernel userland
-- --
i3863
Neil Williams wrote:
> But does any package in Debian actually do the static linking?
A few udebs use static linking to avoid the need for separate udebs for
certain libraries. It also helps to reduce memory usage as only needed
symbols are linked in.
It's only used in a few specific cases; the
> Debian BTS seems to be on vacation. For how long?
It's not down, but HTTP access is extremely slow.
--
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/201004291147.280
Sven Mueller wrote:
> (for example in changing silently to native package format if the
> orig.tar.gz is missing)
That's not true is it? At least, if I use 'debuild' I get a pretty big
warning if the orig.tar.gz is missing.
$ apt-get source acct
$ rm acct_6.5.1.orig.tar.gz
$ debuild
This packag
> Ideally the package manager front-ends would propose for installation to
> the user all hardware related packages for currently detected hardware
> in the system, or removal once such hardware is not present (although
> that might need to be disabled for pluggable hardware).
The implementation w
Moritz Muehlenhoff wrote:
>> * Even if an e500 port does not go upstream, would it be possible to get
>> the appropriate entries added to the upstream dpkg cpu and triplet
>> tables? We're using a simple 10-line patch to dpkg locally, hopefully
>> that would be acceptable?
>
> That has been done i
Nikita V. Youshchenko wrote:
>> From a current point of view squeeze will release with kernel 2.6.32
>
> This is not very good, since .32 is skipped by -rt people, so us who need
> realtime kernel, won't be able just to add a patch to distribution
> kernel, but instead will have to use different u
On Sunday 07 February 2010, Frans Pop wrote:
> Does that also mean initscripts will be dropping its dependency on
> e2fsprogs?
Just see it's already been lowered to recommends (I had an older version of
initscripts installed).
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists
Marco d'Itri wrote:
> Now that /sbin/fsck is provided by util-linux it should be possible to
> drop the Essential attribute from the e2fsprogs. How do we do this?
Does that also mean initscripts will be dropping its dependency on
e2fsprogs?
Also, what new priority should it get?
Debian Installer
Petter Reinholdtsen wrote:
> This caused the installer to stop after 1 minute.
Not sure how this could have affected the installer as we don't include any
watchdog modules in D-I (at least, not that I'm aware of).
Cheers,
FJP
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
w
(Moving this to the d-boot list. Please reply to that list only.)
Martin Wuertele wrote:
> * Joey Hess [2010-01-10 23:23]:
>
>> This is not the case in Debian 5.0. Nor was it the case with Debian 4.0.
>> Debian 3.1 (2005) was the last one to do that.
>
> Interesting. Tasksel on my Squeeze box s
Martin Wuertele wrote:
> * Andrzej Borucki [2010-01-10 19:58]:
>> I am beginner in Linux. I install Debian 5.0.3 "Lenny". I have several
>> warnings: - in install I can't choose Gnome or Kde
>
> "Graphical desktop environment" will install both, however you can go
> without "Graphical desktop env
Lucas Nussbaum wrote:
> Anyway, to avoid modifying debian/control directly, it's easy to add an
> additional substvar (ubuntu:Browser?):
> debian/control:
> Depends: [...], iceweasel | ${ubuntu:Browser}
Doesn't that leave a dangling "|" if you're building for Debian?
I'd suggest in debian/control
On Sunday 27 December 2009, Kurt Roeckx wrote:
> On Sun, Dec 27, 2009 at 01:39:28PM +0100, Frans Pop wrote:
> > From that perspective apt should be tagged Build-Essential. Simply
> > because without apt you don't have a working build system.
>
> apt is not and never was
Torsten Werner wrote:
> The Build-Essential: yes field has been updated 2 months ago to better
> match the declared Depends in the package build-essential as requested
> in bug #548801.
It seems there is a misunderstanding about the purpose of the
Build-Essential flag then.
Obviously it is not t
Michael Gernoth wrote:
> On Wed, Dec 23, 2009 at 01:51:01AM +0100, Frans Pop wrote:
>> The following change in /etc/init.d/nfs-kernel-server fixes this:
>> # See if our running kernel supports the NFS kernel server
>> -if [ -f /proc/kallsyms ] && ! grep -q
Stephen Gran wrote:
> I've checked all 3 and the directories exist on them.
Strange.
> Judging by the output, you were uploading to ftp-master at the time.
Isn't that just the name of the config section in dput.cf that was used?
I don't think it indicates the actual host.
> Can you give me a
>
On Saturday 20 September 2008, Joerg Jaspert wrote:
> - the DELAYED queue is back on ftp-master
> - there is ftp.upload.debian.org, please use that in future instead of
> ftp-master.debian.org
I've just found that uploading to DELAYED via ftp.eu.upload.d.o fails
(using dput 0.9.2.32):
$ dput
Kurt Roeckx wrote:
> Now that we have a 2.6.32 kernel in unstable, can you updates us
> on the various things mentioned in this mail?
I have another question. The naming policy for linux-image packages seems
to have changed: instead of an ABI we now have "trunk". First I thought
this was a bug,
Ben Hutchings wrote:
> Currently you can install kernel images from unstable or backports
> without any extra dependencies. I'm not aware of any significant
> breakage though some packages may rely on deprecated and removed stuff
> in procfs or sysfs.
I've been running upstream kernels without an
On Monday 07 December 2009, Frans Pop wrote:
> But when you have a core package maintained by one and the same person,
> I do think that that person has a moral obligation to maintain his
> package as well and as timely for Debian as he does for Ubuntu.
And has an obligation to disc
Steve Langasek wrote:
> No, because it's no longer an objective measure of whether the
> maintenance of the package is adequate. Your definition of "adequate"
> maintenance is now based on how Debian is doing *compared to* Ubuntu,
> which is not a standard that would be used anywhere else!
You ar
Steve Langasek wrote:
> On Thu, Dec 03, 2009 at 02:11:41PM +0100, Frans Pop wrote:
> The question of whether someone is doing an adequate job of maintaining a
> package is a legitimate one. The identity of their employer is
> immaterial to an objective examination of this question.
Martin Michlmayr wrote:
> * Frans Pop [2009-12-03 14:11]:
>> [1] IMO this question is fair since Matthias is listed as sole
>> maintainer for Python packages.
>
> I agree it's a fair question but you guys should really CC Matthias
> since -devel is not a require
I think the proper subject for this mail would have been:
Does the Python maintainer still have Debian as his priority? [1]
Shifting priority seems to be a fairly common pattern (to differing
degrees) for DDs employed by Canonical.
Not at all surprising of course, and not even something to ho
On Friday 20 November 2009, Steve McIntyre wrote:
> For now, I've added a cutoff of 300,000,000 bytes as a maximum package
> size for adding to CDs. That means that the following 3 packages will
> be dropped from the squeeze CD builds:
>
> 306308472 pool/main/o/openarena-data/openarena-data_0.8.1-
On Friday 20 November 2009, Steve McIntyre wrote:
> If you ever want this to be available on Debian CDs, you're going to
> have to do something about the size. For now, I'm going to blacklist
> this package altogether.
Even though they do technically still fit on a CD, you may want to consider
ex
Josselin Mouette wrote:
> We remove entirely the getty respawning from /etc/inittab. Instead, a
> new daemon is started by a regular init script. This daemon does the
> following:
> * Opens all /dev/tty1 to tty6 and display a d-i-like “press enter
> to activate this console” in them.
> * Provide
Mark Hymers wrote:
> I think there's some confusion here between source and binary formats.
> The announcement was referring to bzip2 when used as part of a source
> upload. As far as I can tell from looking in the git logs, dak has
> supported data.tar.bz2 since 2005, so I'm surprised that this h
On Sunday 15 November 2009, Joerg Jaspert wrote:
> dpkg v3 source format, compression
> --
> As many already noticed, our archive now additionally supports 3.0
> (quilt) and 3.0 (native) source package formats. You can use either
> gzip as usual or bzip2 for the com
Mathieu Malaterre wrote:
> I tried reproducing it here on my amd64 box using gcj-4.4 (testing)
> and gcc-snapshot but I cannot reproduce it here. I am guessing this is
> a hppa only issue. How should I handle that ?
The hppa architecture is not 100% stable ATM. People are working hard to
improve
Dmitry E. Oboukhov wrote:
> A few days ago i uploaded a package. but
> http://ftp-master.debian.org/new.html hasn't contained any information
> about it. Last package has a date 26 Oct. Is any script hangs up?
See http://blog.ganneff.de/blog/2009/10/27/debian-ftpmaster-meeting.html
Cheers,
FJP
Don Armstrong wrote:
> I'm in the process of working with DSA to add additional mail servers
> in front of the bts to handle this issue. (They've configured
> everything, I just need to have about 10 more hours in the day.)
Thanks a lot Don.
--
To UNSUBSCRIBE, email to debian-devel-requ...@list
The time between submitting bugs (or sending messages to control) and the
BTS acting on them is currently much longer than it used to be and, IMHO,
should be. Is this a deliberate change or known issue?
Example: #552576 was submitted 27 Oct 2009 16:26:17 UTC, received by
bugs.d.o 16:26:25 UTC,
On Tuesday 27 October 2009, Joerg Jaspert wrote:
> Now, in this case there is no need to move it, as looking at
> http://lintian.debian.org/tags/no-standards-version-field.html shows
> that we do not see any of the D-I packages, so I assume lintian is
> detecting it properly and we do not need to m
On Tuesday 27 October 2009, Joerg Jaspert wrote:
> The second category is named "error" and the tags listed can not be
Looks like it's named "nowayout".
> overridden. Those are tags corresponding to packaging errors serious
> enough to mark a package unfit for the archive and should never happen.
sean finney wrote:
> On Mon, Oct 05, 2009 at 08:14:19AM +, Tzafrir Cohen wrote:
>> I believe most (or at least many) of those only support a single web
>> root. If you want to serve munin's static content from /usr/share/munin
>> and foo's static content from /usr/share/foo , you'll probably ju
George Danchev wrote:
> You are correct, I missed these either because dpkg-scanpackages has not
> been invoked with -tudeb or udebs are not built for the official
> archive.
They are in the official archive, but in separate sections (with their own
Packages files): '.../main/debian-installer/bin
George Danchev wrote:
> I've recently done a little survey about the fields used in our control
> files (*_Release files excluded). Currently there are ~80 different
> fields [1] used in testing and unstable, which basically fall into these
> groups:
Looks like you did not include udebs in your s
Cyril Brulebois wrote:
> Frans Pop (12/09/2009):
>> I wasn't planning to, partly because the new packaging requires
>> debhelper v7.
>
> Which is available on backports.org, too.
Hmmm, OK. But I still don't see much point in backporting a package that
does not
Henrique de Moraes Holschuh wrote:
> On Sat, 12 Sep 2009, Frans Pop wrote:
>> As debmirror is a native package that may interest developers I thought
>> a quick announcement here is appropriate.
>>
>> I uploaded version 2.2 earlier this morning. In comparison with
Harald Braumann wrote:
> While I personally like to be kept updated on all bugs I file and would
> welcome an auto-subscribe feature, one has to accept the fact that
> others might not. I always find it very irritating if The System
> forces things on me because it thinks it knows what's best for e
Paul Wise wrote:
> I personally prefer not to be CCed on bug reports. I don't want to
> recieve any mail about a bug unless it is asking me to supply more
> information.
So you *do* want to be CCed if the maintainer needs more information.
Then there's one thing I don't get.
- if we change the de
Russ Allbery wrote:
>> That should probably be something that would fly for me actually. and
>> you could make reportbug take an option to add some kind of pseudo
>> header so that subscribing is not done for the rare cases when sender
>> doesn't want to be subscribed.
>
> I would ideally like to
Holger Levsen wrote:
> But I also think the acknowledgement mail should contain the information
> that the submitter is not being subscribed by default and how s/he can
> subscribe.
IMHO this is very wrong: the user has already taken the trouble to report
the bug. We should not make him/her jump
Colin Watson wrote:
> On Sat, Sep 05, 2009 at 10:55:42PM +0200, Frans Pop wrote:
>> I would not recommend having os-prober installed for this.
>
> We should make it more efficient and less intrusive, but that's
> perfectly feasible in os-prober itself and would be a goo
On Saturday 05 September 2009, Frans Pop wrote:
> It has never been intended to be used as part of an update-grub script
> and to be run every time the bootloader configuration is updated
> because a new/updated kernel was installed or one of the packages that
> affect an initrd (udev
Philipp Kern wrote:
> Do you have os-prober installed?
I would not recommend having os-prober installed for this. os-prober has
always been intended to be run only _once_, mostly when a new system is
installed. It exists as a .deb to be used for example after a debootstrap
installation of a sys
Marco d'Itri wrote:
> On Aug 31, Bastian Blank wrote:
>> I doubt that I would be able to push this port through another release
>> in the current state. The consequence would by that the port dies
>> completely and with it the only free and released distribution for this
>> machines.
>
> Is this r
On Saturday 29 August 2009, David Kalnischkies wrote:
> > Would the following also work to use an *un*compressed packages file:
> > Acquire::CompressionTypes::"" "";
>
> A quick test suggest that this would work as a hack, but apt doesn't
> like uncompressed files and will print many false-negative
On Saturday 29 August 2009, David Kalnischkies wrote:
> On Fri, Aug 28, 2009 at 18:34, Frans Pop wrote:
> > Michael Vogt wrote:
> >> It looks like this is releated to the new code that adds lzma
> >> support for Package file downloads and the option to configure in
>
Michael Vogt wrote:
> It looks like this is releated to the new code that adds lzma support
> for Package file downloads and the option to configure in what order
> the compression types should be used.
That last is really excellent news! I have some slow systems where using
gzip will be *much* f
On Saturday 22 August 2009, Marco d'Itri wrote:
> I uploaded to experimental[1] udev 146, considering the major changes I
> recommend extended testing by anybody who can, especially d-i
> developers.
I've done a quick basic installation test on i386 (in VirtualBox). Nothing
fancy. I've not seen a
Goswin von Brederlow wrote:
> Ok, you've got it unless you find someone else. Probably best to give
> it a few days for others to raise their hand as well.
Looks like I'm stuck with it :-)
I'll first contact Goswin privately for some practical matters and then
decide on how to maintain the packa
Paul Wise wrote:
> I seem to remember that some arch:all packages can only be built on
> some architectures due to being firmware for specific CPUs or similar.
> Will there be a Build-Arch field or a way to override discarding
> uploaded .debs?
An option to override the discard would also be usefu
Leinier Cruz Salfran wrote:
> The following packages have unmet dependencies:
> aptitude: Depends: libapt-pkg-libc6.9-6-4.7 but it is not installable
> Depends: libept0 (>= 0.5.26+b1) but it is not going to be
> installed
This is not a "problem" with sid, but very simply how sid works. It is
*nor
I use debmirror (stable version) and am quite happy with it, so I'm
willing to take it. However, I'm not a perl expert and cannot promise
super active maintenance. I can try to at least keep it working though.
If anybody else wants to take it, feel free. If someone would like to
co-maintain, th
Steve Langasek wrote:
> On Sun, Jul 26, 2009 at 05:10:59PM +0200, Frans Pop wrote:
>> You're correct of course. If we want to go this way there should be two
>> questions: one for the system shell to use and one for the default user
>> shell, each with per-arch defaults
Philipp Kern wrote:
> On 2009-07-23, Frans Pop wrote:
>> In addition all shells supported as defaults would need to be included
>> on CD images. And the selected shell would of course have to be set as
>> the default for new users.
>
> Strike the "of course".
Manoj Srivastava wrote:
> I think we can engineer a system where Debian suggests various
> shells as the default shell, and the user selects one. And only the
> selected default shell is one that can't be removed from the system.
Debian Installer could in theory support this by having a default sh
Henrique de Moraes Holschuh wrote:
> The embedded crowd would want to find a way to get rid of bash, though,
> and trying to make bash a non-essential package seems like a worthwile
> effort because of that. It can even be reasonably automated, since you
> can rgrep /bin/bash to find out scripts t
On Saturday 11 July 2009, Luk Claes wrote:
> > what are the remaining issues that you are concerned about?
>
> The ones that prevent linux-2.6 from migrating once it would be
> unblocked.
Like FTBFS of linux-modules-extra-2.6 on 3 architectures I guess? That
seemed to me like a valid reason not t
Raphael Geissert wrote:
>> dash currently is optional, so there will be on a lot of existing
>> systems on which it is not installed. How is the planned strategy going
>> to prevent dash becoming the default shell on existing systems when it
>> gets installed for the first time because of its raise
Raphael Hertzog wrote:
> On Thu, 25 Jun 2009, Raphael Geissert wrote:
>> Artur R. Czechowski wrote:
>> > What about debconf question?
>>
>> dash already has one, the idea is to make it essential and default to
>> yes, so that as soon as it is installed the symlink is changed. If you
>> wish to hav
mli...@stacktrace.us wrote:
> So what exactly replaced base-config
It wasn't replaced, it was obsoleted by its maintainers (the installer
team) because it was no longer needed for new installs using the official
installer. It's functionality was _integrated in_ D-I, it was not
_replaced by_ D-I
On Monday 22 June 2009, Frans Pop wrote:
> On Monday 22 June 2009, Frans Pop wrote:
> > I think it's worth getting some thoughts on this before filing a bug
> > about it (or not).
>
> Just see it's already been discussed to some extend in
> http://bugs.debian.or
On Monday 22 June 2009, Frans Pop wrote:
> I think it's worth getting some thoughts on this before filing a bug
> about it (or not).
Just see it's already been discussed to some extend in
http://bugs.debian.org/254311.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.d
I think it's worth getting some thoughts on this before filing a bug about
it (or not).
Here's the use case:
$ mount | tail -n2
nfs-server:/project on /srv/project type nfs4 (rw,[...])
/srv/project/kernel on /home/fjp/projects/kernel type none (rw,bind)
So, an NFS share is mounted and a subdir f
Bastian Venthur wrote:
> is anyone using interactive bugscripts? I mean scripts in
> /usr/share/bug/ which interactively demand answers from the user.
The installation-reports script is quite interactive.
Why do you continue to want to cripple bug reporting because of
reportbug-ng? I appreciate
Jörg Jaspert wrote:
> Frans Pop (Thu, 21 May 2009 20:54:22 +0200):
>> > From: Debian Installer
>>
>> Although this usage probably predates D-I, I do find it quite confusing
>> in practice, and for example when googling, that we currently have two
>> com
Steve Langasek wrote:
> > While I do prefer sendmail, I think there is one technical
> > issue you guys are glossing over: The fact that we have an installed
> > base of Exim, and documentation all over the place that assumes the
> > Debian default is Exim,
>
> Such as? I haven't seen any
On Saturday 23 May 2009, Artur R. Czechowski wrote:
> What about requiring a GPG signed email by key in developers or
> maintainers keyring?
As others have already mentioned, the addresses are also intended as
contact point for upstream developers and users, i.e. people who don't
have such a key
On Friday 22 May 2009, Neil Williams wrote:
> Maybe a list of packages that do use it and an address to email for
> those who want to start using it at a later date?
That would defeat its purpose. It is not about which maintainers use it,
but about who uses it to contact maintainers.
Cheers,
FJP
On Friday 22 May 2009, Stephen Gran wrote:
> So I've looked through a few weeks of mail logs to packages.debian.org,
I always use it to CC the maintainer(s) of a package I reassign a bug to,
or if I want to CC a package maintainer on some discussion.
For me it's the most natural address to use,
Adeodato Simó wrote:
> From: Debian Installer
Although this usage probably predates D-I, I do find it quite confusing in
practice, and for example when googling, that we currently have two
completely unrelated usages of the term "Debian Installer".
Would the FTP master team consider changing t
Lucas Brasilino wrote:
> Template: foo/bar
> Type: select
> Choices: left, right, center
> Display-Choices: "Wanna go left ?", "Wanna go right ?", "Wanna go straight?"
"Choices-C" does exactly what you want (supported in Etch and later):
Template: foo/bar
Type: select
Choices-C: left, right, cent
On Friday 24 April 2009, Frans Pop wrote:
> Florian Lohoff wrote:
> > rdate ist not a replacement for ntpdate - it does not use the ntp
> > protocol but the time protocol (builtin inetd) - So making
> > ntpdate depend on rdate is not a solution as it changes the protocol
>
Florian Lohoff wrote:
> rdate ist not a replacement for ntpdate - it does not use the ntp
> protocol but the time protocol (builtin inetd) - So making
> ntpdate depend on rdate is not a solution as it changes the protocol
> and i dont think all ntp servers also open/support the time protocol.
rda
Let's move this subthread back to d-boot. Reply-to set.
Please let us know if you'd like to be CCed.
Martin Wuertele wrote:
> * Frans Pop [2009-04-07 02:54]:
>
>> Martin Wuertele wrote:
>> > Actually lilo is installed by lenny d-i if you use root-sw-raid with
>
Martin Wuertele wrote:
> Actually lilo is installed by lenny d-i if you use root-sw-raid with
> LVM, even if your /boot is an differen partition/sw-raid. Therefore lilo
> should at least remain for sqeeze to ensure a proper upgrade path.
I'm afraid you're mistaken here. Lenny D-I should (and AFAIK
On Monday 06 April 2009, Christian Perrier wrote:
> Quoting William Pitcock (neno...@dereferenced.org):
> > lilo is due for removal anyway due to being unmaintained upstream and
> > the widespread availability of alternatives.
I think that last part is debatable.
> > I do not have time to manage
Tyler MacDonald wrote:
> Darren Salt wrote:
>> > On Wed, Apr 01 2009, Frans Pop wrote:
>> [make-kpkg]
>> >> But is anyone still using it? Is there any current reason to support
>> >> it
>
> Well, there's still some kernel options that ar
Darren Salt wrote:
> I demand that Manoj Srivastava may or may not have written...
>> On Wed, Apr 01 2009, Frans Pop wrote:
>>> But is anyone still using it? Is there any current reason to support
>>> it
>
>> I think that there are Debian users who use that op
Manoj Srivastava wrote:
> On Wed, Apr 01 2009, Frans Pop wrote:
>> (i.e. is there any reason to _add_ support for it in deb-pkg or in
>> whatever the kernel team is planning)?
>
> I think so. If we do standardize on /etc/kernel/*.d directories
> as the place wh
Manoj Srivastava wrote:
> On Tue, Mar 24 2009, Frans Pop wrote:
>> I'm not sure whether this discussion should happen here (d-kernel +
>> selected interested parties) or would be better held on d-devel.
>> If ppl think it would be better on d-devel, then please let me k
Patrick Schoenfeld wrote:
> * RUN_NEW_SERVICES_AFTER_INSTALL=
I dislike the semantics of this because it does not allow for the case
where for whatever reason (e.g. new system install) you have to reboot
shortly after installing a package before you had a chance to
review/change the configurati
Russ Allbery wrote:
> debconf-devel(7):
>
> The config script should not need to modify the filesystem at all. It
> just examines the state of the system, and asks questions, and debconf
> stores the answers to be acted on later by the postinst script.
> Conversely, the postinst script should alm
On Wednesday 25 March 2009, Frans Pop wrote:
> dpkg-preconfigure is part of the debconf package, and gets called using
> the following configuration setting:
> /etc/apt/apt.conf.d/70debconf:
> DPkg::Pre-Install-Pkgs {"/usr/sbin/dpkg-preconfigure --apt || true";};
You can pro
> o Is the fact that the config script is run on the host a bug in
> apt-get, dpkg, debconf, or apt-utils?
dpkg-preconfigure is part of the debconf package, and gets called using
the following configuration setting:
/etc/apt/apt.conf.d/70debconf:
DPkg::Pre-Install-Pkgs {"/usr/sbin/dpkg-pr
Marco d'Itri wrote:
> The upstream maintainers decided that in the future the files in
> /etc/modprobe.d/ will be processed only if they have a .conf suffix.
> The latest module-init-tool release complains loudly for each one and
> still processes them, but this will change.
Any idea when the warn
Bastian Blank wrote:
> On Thu, Feb 26, 2009 at 09:07:35PM +0100, Joerg Jaspert wrote:
> According to my knowledge of dak, the sections are global. Which means
> that we don't have to worry about a possible kernel update for
> lenny+1/2. Am I correct with that?
The sections are defined in the overr
1 - 100 of 412 matches
Mail list logo
