So, what is the best practice to recompile kernel-modules on
kernel-upgrades?
The current best practice is definitely to rely on users' memory :S
See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=299727 for some
discussion about this. A few hacky ideas were proposed. I don't expect
to see a
Le February 12, 2008 03:19:47 am Joerg Jaspert, vous avez écrit :
> On 11293 March 1977, Philippe Cloutier wrote:
>
> Lets jump in here, even if not all points address your mail only.
>
> > If by "disfavour" you imply that it's intentional that NEW packages
>
Dear Philippe,
if the ressources are scarce, I think that it would be fair that the
internal competition for the access to them would be organised in a
productive way. The current system disfavours the works that changes the
structure of the package. How does this fit in a strategy to optimise
t
On Sat, 09 Feb 2008 20:10:20 -0500 Philippe Cloutier wrote:
> > That probably won't make much time difference on "fast" archs (i386,
> > amd64 etc), but on slower ones like mips, mipsel etc (those sometimes
> > hold up testing transition :().
> A missing bu
That probably won't make much time difference on "fast" archs (i386,
amd64 etc), but on slower ones like mips, mipsel etc (those sometimes
hold up testing transition :().
A missing build will only slow testing migration if the package wasn't
built when the unstable testing delay is over. Since a
I agree. Regarding the installed size, on my not-so-barebone KDE lenny
PC (1067 packages installed), installing standard selinux packages would
require 40 MB more. Systems with old HDD-s and miniature systems could
be bothered.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "
Could we consider increasign the priority of apt-listchanges so that
it is installed by default?
I'm against making it standard, because currently tasksel doesn't ask if
a recommendation should be installed, so when we make tasksel install
recommendations by default, apt-listchanges would bring
> 3. I'm definitely opposed to a feature which will pop up a *terminal*
> where a user has to do something before he can proceed reporting a bug.
> Sorry, but this won't happen in rng. I might consider such a thing if it
> could be scripted to use QT or even GTK but a terminal popping up in a
> G
This bug is now about that all plugins are installed by default,
dragging in too many dependencies at install/upgrade time. I have the
following compromise in mind, which I first want to be commented on
before I do the follwing changes:
a) Let's introduce 2 meta packages: libxine1-all-plugins, w
At least use important. I actually don't care, if there is a bug or not for
the issue. But I do care about the testing migration. We do have DDs, who are
doing work only during the weekend (which is perfectly acceptable). So if you
write an RC bug on monday, this might hold up the testing migr
What about adding it to the already existing firmware-nonfree source
package?
Cheers,
Moritz
What about it, indeed? Would it have any advantage over introducing a
new source package?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAI
I don't see why users in countries where software is not patentable
should be forced to jump through hoops to get access to multimedia
software. If this repository is not added to the user's sources.list file
by default then there is no advantage in setting up yet another
repository for such
If anyone has some time, it would be valuable to work through
the list and check, which of these have been merged into Linux mainline
by now (e.g. several of the wifi drivers have) and report the missing
ones to Greg Kroah-H's driver project:
http://www.linuxdriverproject.org/twiki/bin/view
Accor
WiFi
> 4 ipw3945 897
Replaced by (free) iwlwifi which will be present in 2.6.24.
iwlwifi is "contrib", like ipw3945.
> 25 ieee80211 109
> 61 ieee80211softmac 14
> 31 ipw2100 71
> 18 ipw2200
>
> I'd start with amending the Developers' Reference, then having a test
> added to lintian and linda, and after that announcing it on
> debian-devel-announce. Then next year, after everyone's had time to
> react and upload new packages, do a mass bug filing.
Basically agreed. I created
http://w
I'd start with amending the Developers' Reference, then having a test
added to lintian and linda, and after that announcing it on
debian-devel-announce. Then next year, after everyone's had time to
react and upload new packages, do a mass bug filing.
Basically agreed. I created
http://wiki.debia
* Simplify installation of out-of-tree kernel modules, possibly by
adapting Ubuntu's Restricted Manager to work with m-a. Non-free
drivers would *only* be displayed if non-free is in the sources.list.
No plans AFAIK. Working on this should not be difficult and should be
appreciated, either by i
* Filipus Klutiero ([EMAIL PROTECTED]) [070616 20:46]:
> Le vendredi 15 juin 2007 19:19, Andreas Barth a écrit?:
> > Release team structure
> > ~~
> > Steve Langasek, who served as Release Manager for the past two cycles,
> > doesn't want to be on the hot seat anymore. As he i
BTW: anybody more versed in the bts system than I am, how can I get #359634
marked as not actually being fixed?
Does a simple reopen not work?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
I am definitely a GUI person (aptitude is the last non-GUI program
with a GUI available that I still use), but I still prefer aptitude to
any other. I was under the impression that most others did too, is it
not the recommended Debian way?.
Yes (but that's a reported bug, #418455)
--
To UNSUBSC
Apparently there have been bugs in this for years and no-one reported
them until they caused trouble for the d-i team several months ago.
They should be fixed in stable's aptitude now, and I would appreciate
bug reports on any transition problems that remain.
FWIW, I thought that you acknowledged
Is this the correct mailing list to send this idea to?
[EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
The only time you wouldn't want a Recommends: installed is
if you know that it wouldn't be useful.
Not really.
Policy is vague and only specifies that Recommends means that more than
a proportion between 1/2 and 1 of systems consider that the recommended
package's contribution to the recommend
Ah, dammit. Thanks anyway :-P
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Am I right in thinking that normal d-i installations ensure that at
least one primary mirror is selected (or at least strongly advise that
one primary should exist)?
No
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Hendrik makes me think that ktorrent would be another good idea.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Daniel Baumann a écrit :
Philippe Cloutier wrote:
See #363967. I heard some doubts about panthera's ability to handle more
stuff, so maybe you can offer help.
thanks you for your trust in me, this makes me very happy.
Hi Daniel,
I see you didn't take that a complimen
See #363967. I heard some doubts about panthera's ability to handle more
stuff, so maybe you can offer help.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Is there any chance 2.6.18 will make it into etch to solve bugs like #391448
and #389803?
Yes, but this requires addressing #395110, investigating or fixing
#395247 and #392818 and getting a s390 build first, as per linux-2.6's
excuses.
This would be best asked to debian-kernel.
--
To UNS
29 matches
Mail list logo
