On Sat, Mar 16, 2013 at 15:40:12 +0900, Charles Plessy wrote:
diff --git a/netcfg-static.c b/netcfg-static.c
index 4e9ca29..1987bec 100644
--- a/netcfg-static.c
+++ b/netcfg-static.c
@@ -83,7 +83,7 @@ int main(int argc, char** argv)
case WCONFIG:
if
On Sun, 2013-04-07 at 18:26 +0200, Julien Cristau wrote:
On Sat, Mar 16, 2013 at 15:40:12 +0900, Charles Plessy wrote:
[...]
diff --git a/write_interface.c b/write_interface.c
index 1aa331a..2a42d48 100644
--- a/write_interface.c
+++ b/write_interface.c
@@ -55,7 +55,7 @@ static int
Le Sun, Mar 10, 2013 at 05:39:56PM +0900, Charles Plessy a écrit :
Le Sun, Mar 10, 2013 at 07:59:46AM +0100, Christian PERRIER a écrit :
Here, we know about the bug and solution (I haven't looked at the code
but adding iw at the same place where wireless-tools are added when
the
reassign 697890 netcfg
retitle 697890 Please install iw on systems with wireless harware.
thanks
Le Sun, Mar 10, 2013 at 07:59:46AM +0100, Christian PERRIER a écrit :
Here, we know about the bug and solution (I haven't looked at the code
but adding iw at the same place where wireless-tools
Le Thu, Mar 07, 2013 at 03:03:53PM -0400, Joey Hess a écrit :
Oh, I didn't think this this was, but, indeed, as we already add
wireless-tools through netcfg, I see not reason to not use the same
concept to add iw when the (installation) interface is wireless (of
course, one might argue
Quoting Charles Plessy (ple...@debian.org):
We therefore have the following choices:
1) Reassign 697890 to netcfg.
2) Go ahead and upload with architecture-dependant task(s).
If we chose 1), are there good chances that the bug will be fixed ? Netcfg
already has 40 bugs open, including
Hi!
On 07/03/13 17:58, Christian PERRIER wrote:
[...]. The need to be on CD#1 was
what drove me to commit. If there are alternative solutions, yes we
should consider them.
In #697868 I suggested an alternate way to nudge a package onto (GNOME)
CD1. Then it would only need to be a Recommends
My concerns with going arch any would be that it becomes slower to make a
tasksel change for some pressing concern, and this magnifies any
installation breakage, or blockage caused by task dependencies. The same
reason we keep debootstrap arch all.
Also every divergence between architectures
Quoting Joey Hess (jo...@debian.org):
Thanks, Joey, for bringing this interesting alternative perspective.
Indeed, when committing these changes, I thought that, because that
arch-dependent packages are added to Recommends and not Depend, it
would not be a problem. Apparently it is. This is what
Christian PERRIER wrote:
Indeed, when committing these changes, I thought that, because that
arch-dependent packages are added to Recommends and not Depend, it
would not be a problem. Apparently it is. This is what slightly
puzzles me, indeed.
network-manager is currently listed in Depends.
10 matches
Mail list logo
