Re: Bits from the Release Team - Kicking off Wheezy
Luk Claes
Below an update of the release goals I advocated and some thoughts on
others.
> Release Goals
> -------------
> As a first step towards establishing release goals for wheezy, we will
be reviewing
> each of the goals which we had for squeeze [RDO:SGoals] to see which
have been achieved and which
> may no longer be relevant for other reasons.
>
> If you are listed as the proponent for a goal in the above list,
please feel free to
> provide a status update on progress towards completing it and whether
you believe it is
> relevant for the wheezy cycle. You can also e-mail us to propose a
new goal, including
> a description of the goal and an indication of how progress on the
issues may be tracked
> (e.g. a pointer to a set of appropriate user-tagged bugs).
# bootperformance
Advocate: Petter Reinholdsen and Luk Claes
State: confirmed
Wiki: http://wiki.debian.org/ReleaseGoals/BootPerformance
The main part of this goal was achieved, though there are some possible
improvements both regarding boot reliability and boot performance that
could still be aimed for.
Regarding reliability I'm doing some work regarding NFS, though one of
the main outstanding issues is the race between availability of the
network devices and the end of the network init script AFAICS. It would
also not be a bad idea to have a discussion on whether the default init
system should change to one that is more suitable to guarantee the
reliability of the boot like upstart or systemd.
Regarding boot performance there is quite some work done by Ubuntu in
different packages, so maybe it would not be bad to have a look at how
Ubuntu and Debian could get more in sync on that.
# package quality
Advocate: Holger Levsen and Luk Claes
State: confirmed
Wiki: http://wiki.debian.org/ReleaseGoals/PackagesQuality
This is a never ending goal of sustaining our packages quality by
improving our tests and following up closely... so needless to say that
I would still advocate this one.
# remove obsolete libraries
Advocate: Barry deFreese and Luk Claes
State: confirmed
Wiki: http://wiki.debian.org/ReleaseGoals/RemoveOldLibs
This worked quite well and should continue so we can get rid of obsolete
libraries IMHO. One of the main candidates are the old db libraries,
though there are also still some old gnome libraries and without doubt
others.
> We're also after new goals! I know that expressions of interest in
multiarch and
> tdebs have already been indicated, but if you have something you would
want to
> see happen for Wheezy, please let us know. The release team itself will be
> suggesting some as part of the review above.
I'm definitely in favour of having multiarch finally happen!
For the IPv6 and LFS legacy release goals I think it would be best if we
would welcome massive (automatic?) tests to find all of the outstanding
issues and get them fixed finally!
I would welcome a review of essential, required and standard though I
don't know if many would welcome such an initiative which could
potentially have quite some impact without much visible gain. Anyway
it's something which should happen in the beginning of the cycle (after
a discussion with both the involved maintainers as well as the
developers body at large) or not at all IMHO.
Cheers
Luk
--
To UNSUBSCRIBE, email to debian-rele...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/4D936684...@debian.org
Josselin Mouette
> # remove obsolete libraries
> Advocate: Barry deFreese and Luk Claes
> State: confirmed
> Wiki: http://wiki.debian.org/ReleaseGoals/RemoveOldLibs
>
> This worked quite well and should continue so we can get rid of obsolete
> libraries IMHO. One of the main candidates are the old db libraries,
> though there are also still some old gnome libraries and without doubt
> others.
I fully support this, and I’d like indeed to remove some more obsolete
libraries for wheezy. We should start with HAL and gnome-vfs, which are
big things. Along the way I’d like to get rid of the least used GTK2
libraries in favor of their GTK3 counterpart.
--
.''`.
: :' : “You would need to ask a lawyer if you don't know
`. `' that a handshake of course makes a valid contract.”
`- -- J???rg Schilling
--
To UNSUBSCRIBE, email to debian-rele...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1301506702.6014.60.camel@pi0307572
Michael Tautschnig
[...]
> # package quality
> Advocate: Holger Levsen and Luk Claes
> State: confirmed
> Wiki: http://wiki.debian.org/ReleaseGoals/PackagesQuality
>
> This is a never ending goal of sustaining our packages quality by
> improving our tests and following up closely... so needless to say that
> I would still advocate this one.
>
[...]
I would advocate the idea behind this goal as well, yet I think as-is this isn't
a very useful goal: how would we ever measure its achievement? To this end, I
think, we need to give a much more precise definition of how we intend to
measure "quality". For instance, we could fix lintian version x.y.z and state
that we want to have 0 errors at the time of release. Similarly for piuparts. Or
a bugs per package ratio. All of these are measurable and can be checked for,
although of course they only give a very limited notion of "quality".
Best regards,
Michael
Michael Biebl
> Le mercredi 30 mars 2011 à 19:21 +0200, Luk Claes a écrit :
>> # remove obsolete libraries
>> Advocate: Barry deFreese and Luk Claes
>> State: confirmed
>> Wiki: http://wiki.debian.org/ReleaseGoals/RemoveOldLibs
>>
>> This worked quite well and should continue so we can get rid of obsolete
>> libraries IMHO. One of the main candidates are the old db libraries,
>> though there are also still some old gnome libraries and without doubt
>> others.
>
> I fully support this, and I’d like indeed to remove some more obsolete
> libraries for wheezy. We should start with HAL and gnome-vfs,
HAL removal is already in progress, see [1]. Actually I've been working on that
for some time already. I wouldn't object obviously making that a release goal.
It seems certainly doable in time for wheezy. The only real blocker I currently
see, is our kfreebsd ports, which still rely on hal e.g. in GVFS, which is a
central part of the GNOME stack.
Michael
[1] http://wiki.debian.org/HALRemoval
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Michael Biebl
> Regarding reliability I'm doing some work regarding NFS, though one of
> the main outstanding issues is the race between availability of the
> network devices and the end of the network init script AFAICS. It would
> also not be a bad idea to have a discussion on whether the default init
> system should change to one that is more suitable to guarantee the
> reliability of the boot like upstart or systemd.
>
...
> I would welcome a review of essential, required and standard though I
> don't know if many would welcome such an initiative which could
> potentially have quite some impact without much visible gain. Anyway
> it's something which should happen in the beginning of the cycle (after
> a discussion with both the involved maintainers as well as the
> developers body at large) or not at all IMHO.
One of the steps required to make it possible to test alternative init systems
(on a wider scale) is to get the Essential flag removed from sysvinit (and
possibly initscripts), so systemd and upstart can be installed without force.
This has been on my wishlist for squeeze and we should definitely get the
necessary changes into wheezy as early as possible during the development cycle.
Dunno if this warrants a separate release goal though.
Michael
Christian PERRIER
> I fully support this, and I’d like indeed to remove some more obsolete
> libraries for wheezy. We should start with HAL and gnome-vfs, which are
> big things. Along the way I’d like to get rid of the least used GTK2
> libraries in favor of their GTK3 counterpart.
How about dropping defoma ?
The pkg-fonts team did that on fonts we maintain, but there are many
other fonts packages (some of them somehow abandoned or loosely
maintained) that need to do it.
Marco d'Itri
> For the IPv6 and LFS legacy release goals I think it would be best if we
> would welcome massive (automatic?) tests to find all of the outstanding
> issues and get them fixed finally!
I fear that the major outstanding issue is ifupdown, which basically
does not support non-trivial dual stacked configurations and needs a
serious redesign.
e.g. vlan/bridging if-*.d scripts are run for every AFI.
--
ciao,
Marco
Roger Leigh
> Release Goals
> -------------
> As a first step towards establishing release goals for wheezy, we will
> be reviewing each of the goals which we had for squeeze [RDO:SGoals] to
> see which have been achieved and which may no longer be relevant for
> other reasons.
Here's a list of things I'd like to see in squeeze, though I probably
won't have time to push them all myself:
• C.UTF-8 provided by default, to provide a guaranteed present
standard C locale (#609306). Looks like this is now in eglibc
(2.13-0exp3) in experimental, so the main remaining task is to
convert existing packages (lintian etc.) which currently generate
their own locales and/or use other locales to use C.UTF-8.
Thanks to Aurelien Jarno for pushing this.
As a followup, I would like to get the UTF-8 codeset and collation
hardcoded in libc6 directly and sharable by all UTF-8 locales to
reduce startup time and needless duplication (due to using a separate
codeset facet for each locale loaded). This would allow the
subsequent creation of a real "C" locale using a UTF-8 codeset.
Needs some digging into the eglibc locale code though.
• /run (as being currently discussed)
Easy enough to add the top-level directory. We do however need to
cope with handling upgrades, compatibility bind mounts and/or
symlinks etc. I've been working on an initscripts patch to handle
this, but it will need wider discussion and testing. Given the
historical usage of /var/run and /var/lock, we will need to keep
compatibility links in place for the foreseable future, if not
indefinitely, plus compatibility /lib/init/rw link to allow for
squeeze upgrades.
• dpkg-buildpackage support for build-arch and build-indep by default
AFAICT requires a mechanism to autodetect the presence of the targets
in the rules file to allow their use if present, falling back to the
build target if absent.
This is a long standing deficiency in our toolchain, which is
preventing correct support for Build-Depends-Indep/
Build-Conflicts-Indep in autobuilding, since the build target may or
may not require Build-Depends-Indep when doing binary-only builds
(and vice versa). Having the correct separation will permit sane
and reliable build dependency installation. This will become more
of an issue with arch-all autobuilding.
This is something we've wanted for years, but which has continually
been stalled by issues doing the migration. We've got support for
build-arch and build-indep in cdbs and dh, which makes over 50% of
the archive support them today. Developers can add the targets
today, and add
build: build-arch build-indep
to have their package build with both current and future versions of
the toolchain, with the appropriate bits being doing in each rule.
I've proposed a change to Policy to change this from "may be provided"
to "must" (#604397).
Some previous proposals have called for this to be enabled if >= a
certain Standards-Version is supported, or a flag in Build-Options
is enabled by the package. However, we want build-arch and
build-indep to be used *by default*. The maintainer should not need
to take additional, explict, action in order to have them used. I
therefore think autodetection is the most useful approach.
In the meantime, we should encourage maintainers to pre-emptively
adopt build-arch and build-indep, and could patch lintian to warn
if not present.
• Read-only root
Depends on /run. Having /run will allow remaining writable files
under /etc to be moved (/etc/mtab, LVM2 cache, CUPS for starters).
Identifying and fixing/removing packages writing to /etc during
their normal operation would be a worthy release goal.
This will make Debian more secure to run, easier to deploy in a
cluster or netboot environment (no writable image overlay required),
keeping dpkg-managed filesystems completely read-only during normal
operation (other than /var).
• /usr "removal"
We should allow the installation and running of a system with no
/usr (where /usr is a symlink to / for backward compatibility).
Previously discussed on -devel. Initially, this is intended to be
optional, keeping all dpkg-managed files on a single filesystem.
In the future, we would have the option of dropping /usr entirely.
Work needing doing: identification and removal of duplicate paths
under / and /usr. If we want to support this on upgrades as well
as new installs, upgrades need considering here as well. Support
in debian-installer for disabling /usr would also be required.
Also, tools such as dpkg-shlibdeps, ld etc. would need checking
to make sure that building on such a system still results in
packages which are installable on old-style split systems, e.g.
when generating shlibs files etc.
I'm sure I'll have more to come!
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
Michael Tautschnig
> • Read-only root
>
> Depends on /run. Having /run will allow remaining writable files
> under /etc to be moved (/etc/mtab, LVM2 cache, CUPS for starters).
> Identifying and fixing/removing packages writing to /etc during
> their normal operation would be a worthy release goal.
>
> This will make Debian more secure to run, easier to deploy in a
> cluster or netboot environment (no writable image overlay required),
> keeping dpkg-managed filesystems completely read-only during normal
> operation (other than /var).
>
Here's an obviously incomplete list of such files, from a fairly comprehensive
desktop installation. I've taken these from my integrit configuration for a
lenny (!) system - I'd love not to be in need for such a list of exceptions.
/etc/aumixrc
/etc/mtab
/etc/motd
/etc/adjtime
/etc/resolv.conf
/etc/qt3/qt_plugins_3.3rc
/etc/network/run/ifstate
/etc/hotplug/.run/net.enable
/etc/cups/ppd/
/usr/share/ppd/custom/
/etc/cups/classes.conf
/etc/cups/printers.conf
/etc/cups/printers.conf.O
/etc/cups/cupsd.conf
/etc/printcap
/etc/lvm/cache/.cache
/etc/openvpn/openvpn-status.log
/etc/blkid.tab
/etc/blkid.tab.old
/etc/samba/dhcp.conf
/etc/hosts.deny (written by denyhosts, hence that one is a bit hard to fix)
Hope this helps,
Michael
Ben Hutchings
I agree that ifupdown is broken, but how is this connected to the
IPv6 goal? For IPv6 it is at least using iproute2 and not bad old
ifconfig...
Ben.
--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2011033019...@decadent.org.uk
Peter Samuelson
[Roger Leigh]
> As a followup, I would like to get the UTF-8 codeset and collation
> hardcoded in libc6 directly and sharable by all UTF-8 locales to
> reduce startup time and needless duplication
Collation is not just a function of character set, it's quite
locale-dependent. Not sure if the character class tables (<ctype.h>
functions, and the [:foo:] posix regex classes) could be shared across
UTF-8 locales. I rather suspect not.
When you take out collation and possibly character classes, I'm not
sure whether there's anything in the UTF-8 locales left to hardcode
into libc.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Marco d'Itri
> > > For the IPv6 and LFS legacy release goals I think it would be best if we
> > > would welcome massive (automatic?) tests to find all of the outstanding
> > > issues and get them fixed finally!
> > I fear that the major outstanding issue is ifupdown, which basically
> > does not support non-trivial dual stacked configurations and needs a
> > serious redesign.
> > e.g. vlan/bridging if-*.d scripts are run for every AFI.
> I agree that ifupdown is broken, but how is this connected to the
> IPv6 goal? For IPv6 it is at least using iproute2 and not bad old
> ifconfig...
The problem is with all features implemented by external if-*.d scripts.
If e.g. a bridge is created by the first defined afi, the second script
will fail. And if it does not fail on up then everything will still
break on a down event, when the script run by the first AFI will destroy
the interface and ifupdown will be able to remove the IP address of the
second AFI.
Bugs were opened long ago, but there is no interest/manpower to fix
them (which is not surprising if you have ever looked at the ifupdown
source).
--
ciao,
Marco
Goswin von Brederlow
> [...]
>> • Read-only root
>>
>> Depends on /run. Having /run will allow remaining writable files
>> under /etc to be moved (/etc/mtab, LVM2 cache, CUPS for starters).
>> Identifying and fixing/removing packages writing to /etc during
>> their normal operation would be a worthy release goal.
>>
>> This will make Debian more secure to run, easier to deploy in a
>> cluster or netboot environment (no writable image overlay required),
>> keeping dpkg-managed filesystems completely read-only during normal
>> operation (other than /var).
>>
> [...]
>
> Here's an obviously incomplete list of such files, from a fairly comprehensive
> desktop installation. I've taken these from my integrit configuration for a
> lenny (!) system - I'd love not to be in need for such a list of exceptions.
I'm running a small server with squeeze (some beta but it won't have
become worse) with read-only / instaled that way from DI. Only needed
minimal fixes to work properly. Namely:
> /etc/mtab
link to /proc/mounts (manually)
I think this is going to be the default in the future but for some
reason wasn't added before squeeze froze.
> /etc/motd
> /etc/adjtime
> /etc/resolv.conf
No problems with those three. Network is configured static so dhcp-client
doesn't rewrite resolv.conf. The resolvconf package fixes the
resolv.conf write problem with dhcp-client and read-only /, right?
> /etc/network/run/ifstate
linked to /dev/shm (automatic if /dev/shm exists during install, so
purge + reinstall of ifupdwon fixes this)
Patch to use /lib/init/rw unconditionally on new installs is pending (as
seen on irc today).
> /etc/lvm/cache/.cache
Configurable in /etc/lvm/lvm.conf. If /run is adapted in debian then
changing the default location shouldn't be a problem.
> /etc/blkid.tab
> /etc/blkid.tab.old
hmm, don't have a problem with that. Shouldn't using lvm trigger that?
While read-only / does not (yet) quite work out of the box it is already
easily configurable that way. At least for a simple server.
I think it would be a worthy release goal to have it work out of the box
and even have a read-only / as a default template in Debian-Installer.
Other than the above one additional config is verry usefull:
$ cat /etc/apt/apt.conf.d/00read-only
DPkg {
// Auto re-mounting of a readonly /usr
Pre-Invoke { "mount -o remount,rw /"; };
Pre-Invoke { "mount -o remount,rw /usr"; };
Post-Invoke { "mount -o remount,ro /usr || true"; };
Post-Invoke { "mount -o remount,ro / || true"; };
};
> /etc/hosts.deny (written by denyhosts, hence that one is a bit hard to fix)
Don't have that. Fix denyhosts to link that to /var/ (or /run when we
have it).
> Hope this helps,
> Michael
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/87d3l8s...@frosties.localnet
Luca Capello
On Wed, 30 Mar 2011 21:09:17 +0200, Roger Leigh wrote:
> • Read-only root
>
> Depends on /run. Having /run will allow remaining writable files
> under /etc to be moved (/etc/mtab, LVM2 cache, CUPS for starters).
For LVM2 there are at least two bugs:
<http://bugs.debian.org/372207>
<http://bugs.debian.org/562234>
This issue was also discussed for etckeeper's ignore list:
<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=462355#85>
For CUPS, feel free to try to convince upstream:
<http://bugs.debian.org/549673>
> Identifying and fixing/removing packages writing to /etc during
> their normal operation would be a worthy release goal.
I added the packages above to the Debian wiki:
<https://wiki.debian.org/ReadonlyRoot>
Thx, bye,
Gismo / Luca
Ben Hutchings
> On Mar 30, Ben Hutchings <b...@decadent.org.uk> wrote:
>
> > > > For the IPv6 and LFS legacy release goals I think it would be best if we
> > > > would welcome massive (automatic?) tests to find all of the outstanding
> > > > issues and get them fixed finally!
> > > I fear that the major outstanding issue is ifupdown, which basically
> > > does not support non-trivial dual stacked configurations and needs a
> > > serious redesign.
> > > e.g. vlan/bridging if-*.d scripts are run for every AFI.
> > I agree that ifupdown is broken, but how is this connected to the
> > IPv6 goal? For IPv6 it is at least using iproute2 and not bad old
> > ifconfig...
> The problem is with all features implemented by external if-*.d scripts.
Still don't see the specific connection to IPv6.
> If e.g. a bridge is created by the first defined afi, the second script
> will fail. And if it does not fail on up then everything will still
> break on a down event, when the script run by the first AFI will destroy
> the interface and ifupdown will be able to remove the IP address of the
> second AFI.
> Bugs were opened long ago, but there is no interest/manpower to fix
> them (which is not surprising if you have ever looked at the ifupdown
> source).
Sadly I am already overcommitted.
Ben.
--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
Serafeim Zanikolas
> Below an update of the release goals I advocated and some thoughts on
> others.
> For the IPv6 and LFS legacy release goals I think it would be best if we
A minor aspect of ipv6 support, is for maintainer scripts to be able to
configure more than one entry per service in inetd.conf (one for ipv4 and
another for ipv6; eg. #527397). This issue is part of the motivation for
DEP9 (for which I've yet to receive any feedback).
--
Every great idea is worthless without someone to do the work. --Neil Williams
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20110330222445.GC23664@mobee
Roger Leigh
>
> [Roger Leigh]
> > As a followup, I would like to get the UTF-8 codeset and collation
> > hardcoded in libc6 directly and sharable by all UTF-8 locales to
> > reduce startup time and needless duplication
>
> Collation is not just a function of character set, it's quite
> locale-dependent. Not sure if the character class tables (<ctype.h>
> functions, and the [:foo:] posix regex classes) could be shared across
> UTF-8 locales. I rather suspect not.
Maybe I'm just thinking of ctype. I thought that (possibly due to
having __STDC_ISO_10646__) the character classes were identical across
all locales. Collation is probably different.
> When you take out collation and possibly character classes, I'm not
> sure whether there's anything in the UTF-8 locales left to hardcode
> into libc.
There's the actual charmap (localedata/charmaps/UTF-8), which is
big and well worth sharing between locales irrespective of
hardcoding. Looking at it again, I only see the C ctype hardcoded;
not the charmap, so maybe it's autogenerated or not even hardcoded
(since it's a 1:1 ASCII:UCS mapping for C). It would be easier to
grok what's going on if it wasn't so hideously complex and
undocumented!
Paul Wise
If anyone wants to help there, more info here:
http://wiki.debian.org/OldPkgRemovals#defoma
Main blockers are Xorg, ghostscript and the other remaining backends
(libwmf, vflib3).
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/AANLkTinfVh-HBFdWDRCpP...@mail.gmail.com
Yaroslav Halchenko
On Wed, 30 Mar 2011, Michael Tautschnig wrote:
> > # package quality
> > Advocate: Holger Levsen and Luk Claes
> > State: confirmed
> > Wiki: http://wiki.debian.org/ReleaseGoals/PackagesQuality
> > This is a never ending goal of sustaining our packages quality by
> > improving our tests and following up closely... so needless to say that
> > I would still advocate this one.
> a very useful goal: how would we ever measure its achievement? To this end, I
guarantee build-time run of unittests if such are provided by upstream.
in my experience those were really helpful, especially for exotic
architectures.
side-question: what to do about source packages shipping only binary
packages of arch 'all' (thus not rebuilt by the farm) while still
susceptible to architectures specificity.
--
=------------------------------------------------------------------=
Keep in touch www.onerussian.com
Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2011033023...@onerussian.com
Henrique de Moraes Holschuh
> > /etc/adjtime
This needs to survive reboots, and it is also needed early in the boot.
It is used to correct the RTC syndrome.
I am at a loss about how it could be made compatible with RO /.
> > /etc/hosts.deny (written by denyhosts, hence that one is a bit hard to fix)
>
> Don't have that. Fix denyhosts to link that to /var/ (or /run when we
> have it).
Has to be available before any tcp-wrapped network service is started.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20110330234...@khazad-dum.debian.net
Reinhard Tartler
> HAL removal is already in progress, see [1]. Actually I've been working on that
> for some time already. I wouldn't object obviously making that a release goal.
How well does kFreeBSD cope with HAL gone missing? AFAIUI udev isn't
available there.
--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/87bp0rx...@faui44a.informatik.uni-erlangen.de
Christian PERRIER
> If anyone wants to help there, more info here:
>
> http://wiki.debian.org/OldPkgRemovals#defoma
>
> Main blockers are Xorg, ghostscript and the other remaining backends
> (libwmf, vflib3).
Would you agree for us to be advocates of this release goal, Paul?
You could be the one looking at these "main blockers" and I could be
the nasty annoying little barking dog hunting down font packages that
are still using defoma and propose patches (as weel as adoption of the
font package by the pkg-fonts team..:))
Vincent Danjean
> On Thu, 2011-03-31 at 00:01 +0200, Marco d'Itri wrote:
>> On Mar 30, Ben Hutchings <b...@decadent.org.uk> wrote:
>>
>>>>> For the IPv6 and LFS legacy release goals I think it would be best if we
>>>>> would welcome massive (automatic?) tests to find all of the outstanding
>>>>> issues and get them fixed finally!
>>>> I fear that the major outstanding issue is ifupdown, which basically
>>>> does not support non-trivial dual stacked configurations and needs a
>>>> serious redesign.
>>>> e.g. vlan/bridging if-*.d scripts are run for every AFI.
>>> I agree that ifupdown is broken, but how is this connected to the
>>> IPv6 goal? For IPv6 it is at least using iproute2 and not bad old
>>> ifconfig...
>> The problem is with all features implemented by external if-*.d scripts.
>
> Still don't see the specific connection to IPv6.
You can reach the problem with IPv4 if you have a very special setup (several
IP for one interface that are not always setup at the same time, ...).
You reach the problem with IPv6 even with common setup (ie an IPv4 and an
IPv6 address with a few classic feature such as bridge, ...)
>> If e.g. a bridge is created by the first defined afi, the second script
>> will fail. And if it does not fail on up then everything will still
>> break on a down event, when the script run by the first AFI will destroy
>> the interface and ifupdown will be able to remove the IP address of the
>> second AFI.
>> Bugs were opened long ago, but there is no interest/manpower to fix
>> them (which is not surprising if you have ever looked at the ifupdown
>> source).
>
> Sadly I am already overcommitted.
Martin F. Krafft started to implement a replacement of ifupdown that
is better designed. But, due to lack of manpower I think, this project
did not finish. See this archives of netcon...@lists.alioth.debian.org
for more info.
Regards,
Vincent
> Ben.
>
--
Vincent Danjean GPG key ID 0x9D025E87 vdan...@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87
Unofficial packages: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo: deb http://people.debian.org/~vdanjean/debian unstable main
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Roger Leigh
> On Thu, 31 Mar 2011, Goswin von Brederlow wrote:
> > > /etc/adjtime
>
> This needs to survive reboots, and it is also needed early in the boot.
> It is used to correct the RTC syndrome.
>
> I am at a loss about how it could be made compatible with RO /.
>
> > > /etc/hosts.deny (written by denyhosts, hence that one is a bit hard to fix)
This one really belongs under /var given that it's writable. Do we
really need it that urgently before /var is mounted? Can't we reload
whatever is using it after /var becomes available? Isn't this also
state which is continually adjusted and rewritten, i.e. is system
state rather than static configuration?
> > Don't have that. Fix denyhosts to link that to /var/ (or /run when we
> > have it).
>
> Has to be available before any tcp-wrapped network service is started.
This won't be until after /var is mounted. Can't dynamically added
entried be added to /var/lib/wrap/hosts.* (for example) and then
libwrap can be patched to read both locations, allowing for static
configuration in /etc, and dynamic added/removed under /var.
Paul Wise
> Quoting Paul Wise (pa...@debian.org):
>
>> If anyone wants to help there, more info here:
>>
>> http://wiki.debian.org/OldPkgRemovals#defoma
>>
>> Main blockers are Xorg, ghostscript and the other remaining backends
>> (libwmf, vflib3).
>
> Would you agree for us to be advocates of this release goal, Paul?
Sounds good.
> You could be the one looking at these "main blockers" and I could be
> the nasty annoying little barking dog hunting down font packages that
> are still using defoma and propose patches (as weel as adoption of the
> font package by the pkg-fonts team..:))
It would be great if you could take on the font packages.
ghostscript is far beyond my abilities to handle, perhaps Kenshi Muto
(who wrote the wiki page about that, CCed) could help with that.
ghostscript already supports fontconfig but apparently it isn't good
enough for CJK stuff at least.
There is a patch for Xorg xfonts-utils to recursively search
/usr/share/fonts, it needs proper testing, pushing upstream and
changing the xorg-server-core font path to include catalog support.
Xorg support for fontconfig is quite far in the future though, Keith
Packard did mention it at one time though.
vflib3 looks abandoned, lets ping the maintainer: Makoto OHURA, are
you still interested in vflib3? It has some reverse deps so this isn't
as simple as removing it.
I haven't looked at libwmf yet but I imagine it could do something
similar to how the gnustep packages now work.
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/AANLkTin7ES-2uW+6sDhOz...@mail.gmail.com
Yves-Alexis Perez
> Xfce 4.8 (for the most part) doesn't rely on hal anymore, at least on Linux.
> Yves-Alexis, what is the fallback on kfreebsd? Does Xfce 4.8 on kfreebsd still
> require hal or will it just have reduced functionality?
>
On BSD it's reduced functionality (see
http://gezeiten.org/post/2011/01/Xfce-4.8-on-BSD-flavors ).
For volume management, thunar-volman won't be available on kFreeBSD so
no automount stuff. xfburn will just drop dep without too much issue.
For power-management, I'm not sure how xfpm will behaves without upower
at all, I'll have to investigate, but anyway newer xfpm doesn't use hal
at all.
Once the complete Xfce 4.8 stack is uploaded we'll have a more complete
picture of the whole situation.
Regards,
--
Yves-Alexis
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1301574950.16871.4.camel@oban
Michael Biebl
> On Wed, Mar 30, 2011 at 19:51:17 (CEST), Michael Biebl wrote:
>
>> HAL removal is already in progress, see [1]. Actually I've been working on that
>> for some time already. I wouldn't object obviously making that a release goal.
>
> How well does kFreeBSD cope with HAL gone missing? AFAIUI udev isn't
> available there.
I ran apt-cache rdepends on an up-to-date kfreebsd sid VM.
Attached are the rdeps for libhal1, libhal-storage1 and hal.
As you can see, xserver-xorg still uses hal on kfreebsd, but iirc KiBi did some
work in that regard.
Then there is GNOME/gvfs/gnome-mount using hal on kfreebsd: I don't know if hal
support can be disabled in gvfs for kfreebsd and what consequences that would
have. Most likely stuff like automounting wouldn't work anymore.
Xfce 4.8 (for the most part) doesn't rely on hal anymore, at least on Linux.
Yves-Alexis, what is the fallback on kfreebsd? Does Xfce 4.8 on kfreebsd still
require hal or will it just have reduced functionality?
KDE 4.6 respectively Solid in KDE SC 4.6 will use the newer interface like
upower on Linux.
I don't know what the KDE team plans for the kfreebsd ports. Will Solid still
use hal there?
Michael
Michael Biebl
> On jeu., 2011-03-31 at 14:30 +0200, Michael Biebl wrote:
>> Xfce 4.8 (for the most part) doesn't rely on hal anymore, at least on Linux.
>> Yves-Alexis, what is the fallback on kfreebsd? Does Xfce 4.8 on kfreebsd still
>> require hal or will it just have reduced functionality?
>>
> On BSD it's reduced functionality (see
> http://gezeiten.org/post/2011/01/Xfce-4.8-on-BSD-flavors ).
>
> For volume management, thunar-volman won't be available on kFreeBSD so
> no automount stuff. xfburn will just drop dep without too much issue.
>
> For power-management, I'm not sure how xfpm will behaves without upower
> at all, I'll have to investigate, but anyway newer xfpm doesn't use hal
> at all.
upower is available on all architectures, so xfpm should work fine.
> Once the complete Xfce 4.8 stack is uploaded we'll have a more complete
> picture of the whole situation.
Thanks for keeping us updated.
Cheers,
Samuel Thibault
Michael Biebl, le Thu 31 Mar 2011 14:30:06 +0200, a écrit :
> Am 31.03.2011 07:26, schrieb Reinhard Tartler:
> > On Wed, Mar 30, 2011 at 19:51:17 (CEST), Michael Biebl wrote:
> >
> >> HAL removal is already in progress, see [1]. Actually I've been working on that
> >> for some time already. I wouldn't object obviously making that a release goal.
> >
> > How well does kFreeBSD cope with HAL gone missing? AFAIUI udev isn't
> > available there.
>
> I ran apt-cache rdepends on an up-to-date kfreebsd sid VM.
> Attached are the rdeps for libhal1, libhal-storage1 and hal.
>
> As you can see, xserver-xorg still uses hal on kfreebsd, but iirc KiBi did some
> work in that regard.
AFAIK, it was agreed that hal is needed for now. FreeBSD's devd should
be a long-term replacement.
> Then there is GNOME/gvfs/gnome-mount using hal on kfreebsd: I don't know if hal
> support can be disabled in gvfs for kfreebsd and what consequences that would
> have. Most likely stuff like automounting wouldn't work anymore.
>
> Xfce 4.8 (for the most part) doesn't rely on hal anymore, at least on Linux.
> Yves-Alexis, what is the fallback on kfreebsd? Does Xfce 4.8 on kfreebsd still
> require hal or will it just have reduced functionality?
>
> KDE 4.6 respectively Solid in KDE SC 4.6 will use the newer interface like
> upower on Linux.
> I don't know what the KDE team plans for the kfreebsd ports. Will Solid still
> use hal there?
> hal
> Reverse Depends:
> xserver-xorg
> xfce4-session
> xfce4-power-manager
> xfburn
> wiican
> virt-manager
> thunar
> thunar-volman
> synce-hal
> rhythmbox
> pulseaudio-module-hal
> pitivi
> pcscd
> openct
> moovida-plugins-good
> kde-plasma-netbook
> kde-plasma-desktop
> lxde
> laptop-mode-tools
> kdebase-runtime
> halevt
> hal-info
> hal-info
> gvfs
> guidance-power-manager
> gnome-mount
> gnome-device-manager
> flumotion
> awn-applets-python-core
> apcupsd
> libhal1
> Reverse Depends:
> xprint
> xserver-xorg-core
> xfburn
> libthunar-vfs-1-2
> thunar-volman
> synce-trayicon
> synce-hal
> synce-gnomevfs
> rhythmbox
> rhythmbox-plugins
> pulseaudio-module-hal
> pcscd
> nut-hal-drivers
> libsynce0
> python-rra
> librra0
> librra-tools
> librapi2
> halevt
> libhal-storage1
> libhal-dev
> hal
> gxine
> gvfs
> gvfs-backends
> gtkpod
> gnome-mount
> libgnome-device-manager0
> gnome-device-manager
> libexo-0.3-0
> exo-utils
> collectd
> collectd-core
> libhal-storage1
> Reverse Depends:
> xfburn
> libthunar-vfs-1-2
> thunar-volman
> libhal-storage-dev
> hal
> gnome-mount
> libexo-0.3-0
> exo-utils
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20110331133...@const.bordeaux.inria.fr
Henrique de Moraes Holschuh
> > > > /etc/adjtime
> >
> > This needs to survive reboots, and it is also needed early in the boot.
> > It is used to correct the RTC syndrome.
> >
> > I am at a loss about how it could be made compatible with RO /.
> >
> > > > /etc/hosts.deny (written by denyhosts, hence that one is a bit hard to fix)
>
> This one really belongs under /var given that it's writable. Do we
> really need it that urgently before /var is mounted? Can't we reload
> whatever is using it after /var becomes available? Isn't this also
Only if we would also change tcp wrappers to deny all if it cannot read
both /etc/hosts.allow and /etc/hosts.deny, so that you can play symlink
games.
Now, I just checked, and Debian tcpwrappers CAN read a list of files to
be acted upon (allowed, denied, etc) from a regular file. So we can
probably just tell denyhosts to switch to that usage pattern, and
/etc/hosts.* can be made RO.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20110331144...@khazad-dum.debian.net
Henrique de Moraes Holschuh
> On Thu, 31 Mar 2011, Roger Leigh wrote:
> > > > > /etc/adjtime
> > >
> > > This needs to survive reboots, and it is also needed early in the boot.
> > > It is used to correct the RTC syndrome.
> > >
> > > I am at a loss about how it could be made compatible with RO /.
> > >
> > > > > /etc/hosts.deny (written by denyhosts, hence that one is a bit hard to fix)
> >
> > This one really belongs under /var given that it's writable. Do we
> > really need it that urgently before /var is mounted? Can't we reload
> > whatever is using it after /var becomes available? Isn't this also
>
> Only if we would also change tcp wrappers to deny all if it cannot read
> both /etc/hosts.allow and /etc/hosts.deny, so that you can play symlink
> games.
>
> Now, I just checked, and Debian tcpwrappers CAN read a list of files to
s/files/addresses/
Cyril Brulebois
> Michael Biebl, le Thu 31 Mar 2011 14:30:06 +0200, a écrit :
> > As you can see, xserver-xorg still uses hal on kfreebsd, but iirc
> > KiBi did some work in that regard.
>
> AFAIK, it was agreed that hal is needed for now. FreeBSD's devd
> should be a long-term replacement.
That it stalled for now. Need to check with xorg developers whether
doing book keeping in the server (rather than in a separate daemon,
which indeed sounds bad) would be appropriate. Last activity is
Guillem's suggestion, as mentioned on [1].
1. http://blog.ikibiki.org/2011/02/21/DXN-6/
KiBi.
Andrew O. Shadoura
On Thu, 31 Mar 2011 00:01:25 +0200
m...@Linux.IT (Marco d'Itri) wrote:
> The problem is with all features implemented by external if-*.d
> scripts. If e.g. a bridge is created by the first defined afi, the
> second script will fail. And if it does not fail on up then
> everything will still break on a down event, when the script run by
> the first AFI will destroy the interface and ifupdown will be able to
> remove the IP address of the second AFI.
Can you run into details a bit?
> Bugs were opened long ago,
Could you please give me the numbers?
> but there is no interest/manpower to fix
> them (which is not surprising if you have ever looked at the ifupdown
> source).
Source? It's beautiful, I can say. It's literate. It's well-structured.
Manpower? Here it is [points at himself].
--
WBR, Andrew
martin f krafft
> Martin F. Krafft started to implement a replacement of ifupdown
> that is better designed. But, due to lack of manpower I think,
> this project did not finish. See this archives of
> netcon...@lists.alioth.debian.org for more info.
Sadly, nothing has changed, and I am further away from computers
these days than I've ever been…
--
.''`. martin f. krafft <madduck@d.o> Related projects:
: :' : proud Debian developer http://debiansystem.info
`. `'` http://people.debian.org/~madduck http://vcs-pkg.org
`- Debian - when you have better things to do than fixing systems
military justice is to justice what military music is to music.
-- groucho marx
Theppitak Karoonboonyanan
> If anyone wants to help there, more info here:
>
> http://wiki.debian.org/OldPkgRemovals#defoma
>
> Main blockers are Xorg, ghostscript and the other remaining backends
> (libwmf, vflib3).
How is Java? Currently, I still need to install sun-java6-fonts to use Thai
on Java apps, and only Lucida is available via defoma.
Regards,
--
Theppitak Karoonboonyanan
http://linux.thai.net/~thep/
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/AANLkTin16U-NYcPy2Khby...@mail.gmail.com
Paul Wise
<th...@debian.org> wrote:
> How is Java? Currently, I still need to install sun-java6-fonts to use Thai
> on Java apps, and only Lucida is available via defoma.
There is no defoma backend for Java so whatever issues Java apps have
to do with fonts has nothing to do with the removal of defoma. Please
ask on debian-java for help finding out what the issue is.
Looks like sun-java6-fonts only contains Lucida anyway?
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/AANLkTi=EYPFPQ0h=Ts-XrcX2izA83f...@mail.gmail.com
Theppitak Karoonboonyanan
> On Fri, Apr 1, 2011 at 11:46 AM, Theppitak Karoonboonyanan
> <th...@debian.org> wrote:
>
>> How is Java? Currently, I still need to install sun-java6-fonts to use Thai
>> on Java apps, and only Lucida is available via defoma.
>
> There is no defoma backend for Java so whatever issues Java apps have
> to do with fonts has nothing to do with the removal of defoma. Please
> ask on debian-java for help finding out what the issue is.
OK. I've tried more apps and it seems to be specific to app, not
to over all Java.
The one in problem is josm, but sweethome3d sees other fonts
in the system.
So, I'll file bugs to individual apps as found instead.
> Looks like sun-java6-fonts only contains Lucida anyway?
Yes, that's why it's the only font with Thai glyphs available to josm.
Regards,
--
Theppitak Karoonboonyanan
http://linux.thai.net/~thep/
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/AANLkTi=SuT1pa1_pk2My+W+OL...@mail.gmail.com
Vincent Danjean
> Hello,
>
> On Thu, 31 Mar 2011 00:01:25 +0200
> m...@Linux.IT (Marco d'Itri) wrote:
>
>> The problem is with all features implemented by external if-*.d
>> scripts. If e.g. a bridge is created by the first defined afi, the
>> second script will fail. And if it does not fail on up then
>> everything will still break on a down event, when the script run by
>> the first AFI will destroy the interface and ifupdown will be able to
>> remove the IP address of the second AFI.
>
> Can you run into details a bit?
Try to define a setup where you have a bridged interface with IPv4
and IPv6 and you want to up/down separately in any order the IPv4
setup and the IPv6 setup. Is is very difficult to know when the
bridge must be enabled and disabled for example.
Regards,
Vincent
--
Vincent Danjean GPG key ID 0x9D025E87 vdan...@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87
Unofficial packages: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo: deb http://people.debian.org/~vdanjean/debian unstable main
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Josselin Mouette
> Martin F. Krafft started to implement a replacement of ifupdown that
> is better designed. But, due to lack of manpower I think, this project
> did not finish. See this archives of netcon...@lists.alioth.debian.org
> for more info.
I wonder what amount of features we are missing for network-manager to
do the job; instead of rewriting a daemon from scratch, we might as well
use one that was designed mostly for the same purpose. It’s
event-driven, it’s extensible, and its features list is already
impressive. Although it has some bugs remaining to fix, this would also
be the case of the new implementation.
The primary drawback I see is that some people object to having D-Bus
installed on their systems. But should we manage to get NM being the
default, we could keep ifupdown in the archive to manage trivial setups
with less disk/memory usage; just as an optional replacement.
--
.''`.
: :' : “You would need to ask a lawyer if you don't know
`. `' that a handshake of course makes a valid contract.”
`- -- J???rg Schilling
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1301776144.9908.29.camel@pi0307572
Bjørn Mork
> Le jeudi 31 mars 2011 à 09:25 +0200, Vincent Danjean a écrit :
>> Martin F. Krafft started to implement a replacement of ifupdown that
>> is better designed. But, due to lack of manpower I think, this project
>> did not finish. See this archives of netcon...@lists.alioth.debian.org
>> for more info.
>
> I wonder what amount of features we are missing for network-manager to
> do the job; instead of rewriting a daemon from scratch,
A daemon will never be able to replace ifupdown.
Bjørn
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ben Hutchings
> Josselin Mouette <jo...@debian.org> writes:
> > Le jeudi 31 mars 2011 à 09:25 +0200, Vincent Danjean a écrit :
> >> Martin F. Krafft started to implement a replacement of ifupdown that
> >> is better designed. But, due to lack of manpower I think, this project
> >> did not finish. See this archives of netcon...@lists.alioth.debian.org
> >> for more info.
> >
> > I wonder what amount of features we are missing for network-manager to
> > do the job; instead of rewriting a daemon from scratch,
>
> A daemon will never be able to replace ifupdown.
ifupdown will never work correctly.
Ben.
--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
brian m. carlson
> On Sat, 2011-04-02 at 23:07 +0200, Bjørn Mork wrote:
> > Josselin Mouette <jo...@debian.org> writes:
> > > I wonder what amount of features we are missing for network-manager to
> > > do the job; instead of rewriting a daemon from scratch,
> >
> > A daemon will never be able to replace ifupdown.
>
> ifupdown will never work correctly.
ifupdown works very well for the server use case. Consider that my
cable line is hooked up to a box that runs a DHCP server, runs a caching
nameserver, and an IPv4-IPv6 tunnel using the sit* interfaces.
/etc/resolv.conf should use the local nameserver information, not
whatever my ISP provides. According to the package description, when
using DHCP, network-manager does whatever it pleases. That's not okay.
network-manager does not support the sit* interfaces, last I checked.
It has significantly more dependencies. My server does not need
wpasupplicant installed. It certainly does not need policykit anything,
not even a shared library. It also leaves unused interfaces running,
which on my laptop causes long delays when using libpam-krb5 as the
attempt to contact the KDC times out.
Also, what happens if network-manager crashes? You're introducing
failure cases that are not needed. ifupdown doesn't have that failure
case.
I admit that I use network-manager on my laptop. It's very convenient
for that use case. It is completely inappropriate for a server: the
package description even says so.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
Felipe Sateler
> Le jeudi 31 mars 2011 à 09:25 +0200, Vincent Danjean a écrit :
>> Martin F. Krafft started to implement a replacement of ifupdown that is
>> better designed. But, due to lack of manpower I think, this project did
>> not finish. See this archives of netcon...@lists.alioth.debian.org
>> for more info.
>
> I wonder what amount of features we are missing for network-manager to
> do the job; instead of rewriting a daemon from scratch, we might as well
> use one that was designed mostly for the same purpose.
The main problem I see is that NM likes to take interfaces down when
upgrading. This is a problem if upgrading remotely.
--
Saludos,
Felipe Sateler
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/in89nb$5be$1...@dough.gmane.org
Paul Wise
> The main problem I see is that NM likes to take interfaces down when
> upgrading. This is a problem if upgrading remotely.
Probably using glib/gobject etc is a no-no for a package that needs to
be in base.
The main problem I see is that the design of NM is wrong™ and the
upstream maintainers do not see it that way.
The upgrading/restart issue was partially fixed, I read that wired
connections without authentication are not killed any more.
The design issue is that NM thinks it is the centre of the networking
universe instead of just part of it, with the kernel at the centre.
The netconf design was much better here.
NM does do a lot of things well though and I've been almost happy
using it the past few years.
The upgrading/restart issue is just a symptom of that problem, more include:
Changes made to the current network setup manually using
ip/route/ifconfig are not reflected in the UI.
Hardcoding policy like wired > wireless and killing my default route
when switching.
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/BANLkTiYXN93Q1E1G...@mail.gmail.com
martin f krafft
> I wonder what amount of features we are missing for network-manager to
> do the job; instead of rewriting a daemon from scratch, we might as well
> use one that was designed mostly for the same purpose. It’s
> event-driven, it’s extensible, and its features list is already
> impressive. Although it has some bugs remaining to fix, this would also
> be the case of the new implementation.
It was originally designed as a graphical tool, which is like taking
a wrong turn in square one. It has come a long way since then, but
last I checked, for instance, it was not possible to hook up two
network cards with DHCP.
Anyway, netconf is nowhere near and noone seems interested enough to
touch it, so…
But if network-manager would become default and ifupdown an optional
replacement, I would question Debian's capacity to make technically
excellent decisions and wonder, how much we have been dragged along
by "user-friendly distros" and slid off the track.
--
.''`. martin f. krafft <madduck@d.o> Related projects:
: :' : proud Debian developer http://debiansystem.info
`. `'` http://people.debian.org/~madduck http://vcs-pkg.org
`- Debian - when you have better things to do than fixing systems
"it is the mark of an educated mind
to be able to entertain a thought
without accepting it."
-- aristoteles
Stanislav Maslovski
> But if network-manager would become default and ifupdown an optional
> replacement, I would question Debian's capacity to make technically
> excellent decisions and wonder, how much we have been dragged along
> by "user-friendly distros" and slid off the track.
I agree. If that happens I will seriously think about moving to
another distro (I have been using Debian since around 1999). Or maybe
to a *BSD.
Just for a record: on this _laptop_ the network is configured from
/etc/network/interfaces with extensively used mapping and self-written
scripts; also with wpa_supplicant for wireless and ifplugd to bring up
eth0 and openvpn tunnels when required. Never felt a need to switch to
something like wicd or network-manager.
--
Stanislav
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20110403103...@kaiba.homelan
Stefano Zacchiroli
> If that happens I will seriously think about moving to another distro
> (I have been using Debian since around 1999). Or maybe to a *BSD.
You're entitled to choose your own distro. Still, please do not assume
that this sort of threatening is something useful to drive technical
decisions in Debian. In fact, I believe it just adds noise to technical
discussions, just imagine would happen if all users out there will start
using -devel to implement polls.
Please think of it and don't worry: technical decisions in Debian will
continue to be based on technical excellence.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela .......| ..: |.......... -- C. Adams
Bernhard R. Link
> On Sun, Apr 03, 2011 at 02:37:26PM +0400, Stanislav Maslovski wrote:
> > If that happens I will seriously think about moving to another distro
> > (I have been using Debian since around 1999). Or maybe to a *BSD.
>
> You're entitled to choose your own distro. Still, please do not assume
> that this sort of threatening is something useful to drive technical
> decisions in Debian.
Please don't drag this into an insulting contest.
Debian is not about market-share, so losing users is no thread. It is
only an information for us that we no longer helpful to some of our
users.
It might not be the best form to express it, but how may other ways are
there to express: "This change is so bad, that it will outweight all
the other advantages of Debian for those class of users in the same boat
as me"?
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20110403110...@pcpool00.mathematik.uni-freiburg.de
Neil Williams
> Le jeudi 31 mars 2011 à 09:25 +0200, Vincent Danjean a écrit :
> > Martin F. Krafft started to implement a replacement of ifupdown that
> > is better designed. But, due to lack of manpower I think, this project
> > did not finish. See this archives of netcon...@lists.alioth.debian.org
> > for more info.
>
> I wonder what amount of features we are missing for network-manager to
> do the job; instead of rewriting a daemon from scratch, we might as well
> use one that was designed mostly for the same purpose. It’s
> event-driven, it’s extensible, and its features list is already
> impressive. Although it has some bugs remaining to fix, this would also
> be the case of the new implementation.
>
> The primary drawback I see is that some people object to having D-Bus
> installed on their systems. But should we manage to get NM being the
> default, we could keep ifupdown in the archive to manage trivial setups
> with less disk/memory usage; just as an optional replacement.
I don't consider network-manager suitable for this purpose - wicd is an
alternative to network-manager but I'd hesitate before considering wicd
as a replacement for ifupdown. If it came down to a choice between no
ifupdown and choosing either wicd or network-manager for systems which
currently use ifupdown, we'd simply have to reinvent ifupdown or use
static configuration.
Principle problem with either wicd or network-manager is handling USB
networking on embedded devices. ifupdown has problems (tends to need
ifdown before ifup) but we can live with that because it has no
extraneous dependencies (it's doesn't depend on dbus or anything not
already installed in a system based only on Priority:required).
That is my main objection:
A replacement for ifupdown *must* not depend on anything which is not
already in Priority:required, with the possible exception of net-tools
or something similar which itself doesn't depend on stuff outside
required. Especially: no dbus requirement, no policykit requirements,
no implicit expectation that wireless must be supported on all
installations, no requirement for all installs to have encryption
support of any kind.
Wireless is common, yes, but it is NOT ubiquitous, especially in the
embedded space. Any replacement must, to me, only have wireless support
as an optional add-on.
wicd is ruled out because it's Python, it also has similar
expectations to Network-Manager that wireless is mandatory. That's fair
enough for what wicd tries to do, it just means that it is not a
replacement for ifupdown.
Network-Manager is ruled out because it expects every install to need
to cope with wireless and therefore brings in (currently) gnutls,
gcrypt, tasn, polkit & wpasupplicant type stuff AS WELL as dbus.
--
Neil Williams
=============
http://www.linux.codehelp.co.uk/
Josselin Mouette
> Probably using glib/gobject etc is a no-no for a package that needs to
> be in base.
And that’s because… ?
> The main problem I see is that the design of NM is wrong™ and the
> upstream maintainers do not see it that way.
>
> The upgrading/restart issue was partially fixed, I read that wired
> connections without authentication are not killed any more.
>
> The design issue is that NM thinks it is the centre of the networking
> universe instead of just part of it, with the kernel at the centre.
This is not a design issue, this is what can make it work. If you have
one single, extensible daemon being able to manage all your connections,
you don’t need anything more. The problem here is that it is, currently,
not being able to handle all the network connection types we want to
handle.
My question remains: is it better to add support for them to existing
software that already does a good job, or to continue masturbating over
vaporware?
> The netconf design was much better here.
Vaporware with good design is still vaporware, unfortunately.
> NM does do a lot of things well though and I've been almost happy
> using it the past few years.
>
> The upgrading/restart issue is just a symptom of that problem, more include:
>
> Changes made to the current network setup manually using
> ip/route/ifconfig are not reflected in the UI.
>
> Hardcoding policy like wired > wireless and killing my default route
> when switching.
These are all valid issues that would of course need fixing - although
for manual ip/route/… I don’t know how this could be implemented in a
correct way.
--
.''`.
: :' : “You would need to ask a lawyer if you don't know
`. `' that a handshake of course makes a valid contract.”
`- -- J???rg Schilling
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1301829792.13493.10.camel@pi0307572
Neil Williams
Josselin Mouette <jo...@debian.org> wrote:
> Le dimanche 03 avril 2011 à 07:24 +0800, Paul Wise a écrit :
> > Probably using glib/gobject etc is a no-no for a package that needs to
> > be in base.
>
> And that’s because… ?
it's an extra dependency which basic systems just don't need. glib is
good but it's not perfect and is not necessary just to get the system
to run. Same reason as I'd object to any replacement for ifupdown which
was written in Python.
>
> > The main problem I see is that the design of NM is wrong™ and the
> > upstream maintainers do not see it that way.
> >
> > The upgrading/restart issue was partially fixed, I read that wired
> > connections without authentication are not killed any more.
> >
> > The design issue is that NM thinks it is the centre of the networking
> > universe instead of just part of it, with the kernel at the centre.
>
> This is not a design issue, this is what can make it work.
Only if wireless is explicitly only supported as an option. Wireless
needs to be spun out and things like USB networking made to work at
least as reliably as ifupdown - again, as an option. The only
hard-wired dependency is ethN.
> If you have
> one single, extensible daemon being able to manage all your connections,
> you don’t need anything more.
I need the ability to remove all extensions which I'm not using on that
specific device and only install the ones I do need.
> The problem here is that it is, currently,
> not being able to handle all the network connection types we want to
> handle.
... independently ...
Stefano Zacchiroli
> Debian is not about market-share, so losing users is no thread. It is
> only an information for us that we no longer helpful to some of our
> users.
The problem is that such a message only conveys the information that
*one* specific user will find our distro no long useful. In turn, that
might induce other users to post ack/nack to -devel and that would
hardly help driving technical discussions to conclusion.
Ultimately, my point is that user feedback is very useful, but we should
find better way to seek it (e.g. explicit polls) than encouraging users
to post their feedback to -devel.
Regarding the fact that my previous message could "drag this into an
insulting contest", I beg to disagree.
Goswin von Brederlow
> On Thu, 31 Mar 2011, Goswin von Brederlow wrote:
>> > /etc/adjtime
>
> This needs to survive reboots, and it is also needed early in the boot.
> It is used to correct the RTC syndrome.
>
> I am at a loss about how it could be made compatible with RO /.
So my clock is sightly wrong during boot until the ntpd/chrony/ntpdate
fixes it. It doesn't give errors so i can live with that.
One could run a while with a read-write / to get an initial /etc/adjtime
for the RTC drift. After that the RTC hopefully doesn't change. So while
I agree that this can't completly be fixed I think it can be ignored.
>> > /etc/hosts.deny (written by denyhosts, hence that one is a bit hard to fix)
>>
>> Don't have that. Fix denyhosts to link that to /var/ (or /run when we
>> have it).
>
> Has to be available before any tcp-wrapped network service is started.
I guess you could just have a /etc/defaults/hosts.deny that you copy to
/run and link /etc/hosts.deny -> /run/hosts.deny before starting
tcp-wrapped network services.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/87vcyvi...@frosties.localnet
Stanislav Maslovski
> On Sun, Apr 03, 2011 at 02:37:26PM +0400, Stanislav Maslovski wrote:
> > If that happens I will seriously think about moving to another distro
> > (I have been using Debian since around 1999). Or maybe to a *BSD.
>
> You're entitled to choose your own distro. Still, please do not assume
> that this sort of threatening is something useful to drive technical
> decisions in Debian.
Where do you see treatening there? I am just expressing my opinion, as
others do on the very same thread.
> In fact, I believe it just adds noise to technical discussions, just
> imagine would happen if all users out there will start using -devel
> to implement polls.
Since when we have debian-devel moderated? And please do not summarize
other's people mails to your own liking.
--
Stanislav
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2011040312...@kaiba.homelan
Paul Wise
> And that’s because… ?
Good question, the only answer I have is that we probably don't want
to add too much bloat to base.
> This is not a design issue, this is what can make it work. If you have
> one single, extensible daemon being able to manage all your connections,
> you don’t need anything more. The problem here is that it is, currently,
> not being able to handle all the network connection types we want to
> handle.
>
> My question remains: is it better to add support for them to existing
> software that already does a good job, or to continue masturbating over
> vaporware?
The problem with that design is that it isn't based in *fact*. The
fact is that the kernel is where the current networking status is
held, controlled and modified. AFAICT the NM authors ignored that fact
in their designs and are resistant to changing the design. That leads
me to think that NM is not the way forward. Waiting for someone to
re-implement netconf in C seems to be the only way forward.
>> The netconf design was much better here.
>
> Vaporware with good design is still vaporware, unfortunately.
Sadly yes :(
Someone kidnap Martin and convince him to rewrite the python prototype in C.
> These are all valid issues that would of course need fixing - although
> for manual ip/route/… I don’t know how this could be implemented in a
> correct way.
IIRC netconf communicates with the kernel to know what the current situation is.
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/BANLkTizH7K2vQ2qg...@mail.gmail.com
Stanislav Maslovski
> On Sun, Apr 03, 2011 at 01:07:12PM +0200, Bernhard R. Link wrote:
> > Debian is not about market-share, so losing users is no thread. It is
> > only an information for us that we no longer helpful to some of our
> > users.
>
> The problem is that such a message only conveys the information that
> *one* specific user will find our distro no long useful. In turn, that
> might induce other users to post ack/nack to -devel and that would
> hardly help driving technical discussions to conclusion.
I understand that you are in a position that forces you to think about
public relations and such, but if I were a DD I would be more happy if
DPL was a bit more focused on real problems.
> Ultimately, my point is that user feedback is very useful, but we should
> find better way to seek it (e.g. explicit polls) than encouraging users
> to post their feedback to -devel.
I manage packages in Debian. If you want me to stop doing that please
exress it more clearly.
--
Stanislav
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2011040312...@kaiba.homelan
Stefano Zacchiroli
> I understand that you are in a position that forces you to think about
> public relations and such, but if I were a DD I would be more happy if
> DPL was a bit more focused on real problems.
Non sequitur: the fact that I'm participating into this sub-thread does
not imply I'm not focusing on (other) "real problems".
> I manage packages in Debian. If you want me to stop doing that please
> exress it more clearly.
Non sequitur again: I've said nothing about the packages you're
managing.
You're right when you say -devel is not moderated, but that also gives
the liberty to all the list participants, including myself, to comment
when they see usage patterns that they do not think will further the
goals of the list. And I'm sorry, but when I read comments like "if you
do $foo I'll stop using Debian", I can't help thinking (and sometime
commenting) that those comments are not helping pursuing a technical
discussion.
As the rest of this subthread is not helping either, I stop here and
also apologize with the other readers for the noise.
Ralf Treinen
> 1) No uninstallable packages, according to their dependencies, are
> shipped as part of a release. AFAIK this is already monitored
> pre-release, and daily monitored at
> <http://edos.debian.net/uninstallable.php>. If this is actually the
> case, it should be added to the current status, otherwise mentioned
> as a future improvement (and commit it to check it for releases).
In squeeze, in fact all architecture-dependant packages are already
installable (except for kfreebsd-*). That is, the only non-installable
packages are packages with Architecture=all. These could be excluded, too,
from future releases by editing the Packages files for the different
architecture, if the release team wants to do that additional work.
BTW: these checks are now also enabled for stable updates and stable
proposed updates (http://edos.debian.net/edos-debcheck/stable.php,
scroll down the page).
> 2) No packages with (detectable) conflicts are shipped as part of a
> release. This is not daily monitored, but periodically checked with
> an initiative by Ralf Treinen described at
> <http://edos.debian.net/file-overwrites/>. As above: we should
> mention it, either as current status or as future improvement.
If such an error occurs (two packages claiming the same path name) I
file a bug with severity=serious anyway. Still, it might be worthwhile
to announce this as a release goal, just to make it public that we
have performed this QA check.
-Ralf.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Fernando Lemos
[...]
> last I checked, for instance, it was not possible to hook up two
> network cards with DHCP.
Hmmm I do have two network cards and they both get IP addresses with
DHCP as I would expect (when they both are enabled).
Anyways, I don't think NM is the right solution for all proposed use
cases right now for a number of reasons:
* It doesn't have a good command-line interface
* It probably can't do some of the more complex yet common setups
possible with ifupdown, guessnet and friends
* NM was built by the Gnome community and their goals are a lot
different from ours
Nevertheless, I do believe something like NM is probably the way to
go, as it is a cleaner and more controlled event-oriented design
compared to a collection of all sort of scripts. It's seems to be the
right way to do it, even if you don't agree with the particular
implementation.
Regards,
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/BANLkTikBfxomeZYB...@mail.gmail.com
Stefano Zacchiroli
> Time based freezes
> ------------------
> We're aware that there is an outstanding discussion to be had about time
> based freezes (note: _not_ time based releases).
>
> The beginning of a release cycle seems the ideal time for that
> discussion and we hope to be in a position to start it after processing
> the results of the retrospective.
Since other follow-ups have avoided this topic up to now, let me be the
reckless guy who jumps into it with both feet: time based freezes!
Road maps
---------
I believe we need time based freezes. Even more radically, I believe we
need to know the freeze date as soon as possible, e.g. no later than a
couple of weeks after the preceding release. (Obviously, transitioning
to time based freezes warrant exceptions to the rule.)
My rationale for the above is simple: *road maps*. Each team and
individual developer should be able to define their own road maps very
early in a release cycle. Doing so will help teams in planning and
splitting work. I believe it will also help maintainers in negotiating
release dates with upstreams which are sensible to distribution needs.
Strict date
-----------
The difficult part in moving to such a scheme is that the freeze date
must be strict.
That is the case because, as history has taught us, announcing a freeze
date and not respecting it---or, equivalently, have announced freeze
dates which are generally believed to be only indications---will spread
frustration among developers. That is so because inevitably maintainers
will show different sensibilities towards a freeze date which is
perceived as not being strict. Some maintainers will almost ignore it,
possibly rushing up work at the last minute, forcing the release team to
postpone the actual freeze. In the meantime, others will perceive the
initially announced date as strict from day 1, plan accordingly, and
ultimately suffer of important out-of-dateness due to freeze
postponement.
All the above, for me, justifies having a strict freeze date very early
in a release cycle.
Freezing what?
--------------
The next question is then what does "freeze" means. Does it mean that
automatic transition to testing stops automatically at freeze date, or
rather that no new transitions are accepted anymore (which IIRC has been
proposed before). I'm tempted to prefer the former, as it seems to be
more fair. However, it's also clear that at the freeze date there will
be transitions which are just half way through. I'm unable to judge if
for those situations it will be better for the work of the release team
to keep testing going on automatically or not ... comments?
All in all, I quite like the idea of a strict freeze date + a flexible
period during which exceptions are granted in a more liberal manner, as
it has happened for the first weeks after the Squeeze freeze.
Freezing when?
--------------
A couple of sub-questions are related to the question of when to
freeze. One is whether we should aim at having a fixed length of a
development period (e.g. 1 year of development from the day the previous
release occurred) or rather aim at having a freeze date occurring during
a specific month of the year, to coordinate the choice of upstream
versions with other distros. The latter is quite constraining and scares
me a bit, but I've also heard from various teams (e.g. kernel and
security) that having synchronized versions with other distros do help
in sharing patches and long term maintenance plans.
A scheme that could work is deciding that we'll have a development
period of a specific length (1 year?) with a specific tolerance (+/-2
months?). At the beginning of each release cycle, the release team will
announce a freeze date contained in such a time window. The choice of
the freeze data is within the responsibility of the Release Team
already; if people will vehemently disagree with the decision, they have
mechanisms to overrule the decision as well. Having the announcement
occurring at the beginning of the release cycle will help in reducing
the negative effects of changing the decision, in the hopefully unlikely
case that people will really want to do that.
Let's fight^Wdiscuss all this!
Faidon Liambotis
> On Sun, Apr 3, 2011 at 5:11 AM, martin f krafft<mad...@debian.org> wrote:
> [...]
>> last I checked, for instance, it was not possible to hook up two
>> network cards with DHCP.
> [...]
>
> Hmmm I do have two network cards and they both get IP addresses with
> DHCP as I would expect (when they both are enabled).
>
> Anyways, I don't think NM is the right solution for all proposed use
> cases right now for a number of reasons:
It also can't do VLANs (.1q), bridges, bonds and all possible
permutations of the above. I'd speculate that it also wouldn't be able
to do things like 1k (or more) interfaces. It also doesn't support hooks
to be able to do more advanced setups, such as multihoming, policy
routing, QoS, etc.
And, above all, losing the network configuration, even for a second,
just because you restarted a daemon (or that daemon died) shouldn't be
acceptable for the primary network configuration of our distribution.
Regards,
Faidon
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Patrick Matthäi
> And, above all, losing the network configuration, even for a second,
> just because you restarted a daemon (or that daemon died) shouldn't be
> acceptable for the primary network configuration of our distribution.
Full ACK.
I also made those experiences with two fedora servers, who are using per
default NM :(
--
/*
Mit freundlichem Gruß / With kind regards,
Patrick Matthäi
GNU/Linux Debian Developer
E-Mail: pmat...@debian.org
pat...@linux-dev.org
Comment:
Always if we think we are right,
we were maybe wrong.
*/
Stanislav Maslovski
> On Sun, Apr 03, 2011 at 04:42:11PM +0400, Stanislav Maslovski wrote:
> > I understand that you are in a position that forces you to think about
> > public relations and such, but if I were a DD I would be more happy if
> > DPL was a bit more focused on real problems.
>
> Non sequitur: the fact that I'm participating into this sub-thread does
> not imply I'm not focusing on (other) "real problems".
Then it means that my and your understanding of which problems are
real and which are not differs very much, as, for instance, I would
not advise users to refrain from expressing their opinions on various
"technical suggestions" on d-d list just in a fear of flood.
> > I manage packages in Debian. If you want me to stop doing that please
> > exress it more clearly.
>
> Non sequitur again: I've said nothing about the packages you're
> managing.
You stressed too much on my role as a mere user, that is why I brought
this point to your attention. I thought it was obvious from the context.
> You're right when you say -devel is not moderated, but that also
> gives the liberty to all the list participants, including myself, to
> comment when they see usage patterns that they do not think will
> further the goals of the list.
Of course. Nobody even tried to take this liberty away from you or to
disrespect it.
> And I'm sorry, but when I read comments like "if you do $foo I'll
> stop using Debian", I can't help thinking (and sometime commenting)
> that those comments are not helping pursuing a technical discussion.
Analogously, when I see such "great" technical suggestions as
replacing ifupdown on default installs with network-manager, I can't
help thinking (and sometimes commenting) that if this trend continues,
then at some point in future I may face a painful decision to abandon
the distribution that I continuously used for more than a decade and
to which I contributed.
PS: And there was a technical part in that my post you replied first.
You just skipped it.
--
Stanislav
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2011040317...@kaiba.homelan
Josselin Mouette
> The problem with that design is that it isn't based in *fact*. The
> fact is that the kernel is where the current networking status is
> held, controlled and modified. AFAICT the NM authors ignored that fact
> in their designs and are resistant to changing the design. That leads
> me to think that NM is not the way forward. Waiting for someone to
> re-implement netconf in C seems to be the only way forward.
> IIRC netconf communicates with the kernel to know what the current situation is.
I am not sure this is enough; does the kernel has all the information
you need? Even for a moderately complex setup, I don’t see how it would
scale. If you stack some changes, like adding a bridge or changing
routes, you want to be able to revert to the previous state in a
consistent manner. How can you do that without a daemon that keeps track
of the entire network status for the host?
--
.''`.
: :' : “You would need to ask a lawyer if you don't know
`. `' that a handshake of course makes a valid contract.”
`- -- J???rg Schilling
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1301852627.3448.32.camel@pi0307572
Josselin Mouette
> Analogously, when I see such "great" technical suggestions as
> replacing ifupdown on default installs with network-manager, I can't
> help thinking (and sometimes commenting) that if this trend continues,
> then at some point in future I may face a painful decision to abandon
> the distribution that I continuously used for more than a decade and
> to which I contributed.
May I suggest that you install a squeeze system with the desktop task,
with a simple DHCP network configuration? You will see that your network
is no longer managed by ifupdown. So we’re talking about something that
has partly already happened, and AFAICT the world hasn’t fallen apart.
So far your only contribution to the discussion has been “If this
happens, I will use another distribution.” Fine. But could you explain
why we would care? I should probably remind you that Debian is, at
first, a do-o-cracy, so if you’re not interested into fixing things
yourself or at least giving constructive criticism, please let other
people dream of other technical solutions that they might actually end
up improving the state of our network stack (which is, in case you
haven’t noticed, absolutely disastrous).
--
.''`.
: :' : “You would need to ask a lawyer if you don't know
`. `' that a handshake of course makes a valid contract.”
`- -- J???rg Schilling
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1301853382.3448.43.camel@pi0307572
Ben Hutchings
> Le dimanche 03 avril 2011 à 20:38 +0800, Paul Wise a écrit :
> > The problem with that design is that it isn't based in *fact*. The
> > fact is that the kernel is where the current networking status is
> > held, controlled and modified. AFAICT the NM authors ignored that fact
> > in their designs and are resistant to changing the design. That leads
> > me to think that NM is not the way forward. Waiting for someone to
> > re-implement netconf in C seems to be the only way forward.
> [snip]
>
> > IIRC netconf communicates with the kernel to know what the current situation is.
>
> I am not sure this is enough; does the kernel has all the information
> you need? Even for a moderately complex setup, I don’t see how it would
> scale. If you stack some changes, like adding a bridge or changing
> routes, you want to be able to revert to the previous state in a
> consistent manner. How can you do that without a daemon that keeps track
> of the entire network status for the host?
The kernel necessarily holds the working network configuration, though
it lacks e.g. credentials for WPA or 802.1x which are handled by
user-space. User-space can change that state, and can read the state
(including waiting for updates) using netlink. User-space needs to
provide policy for potential states, and authentication credentials.
I think that what people like about ifupdown (when it works) is that
they can say 'put this interface in this state' and then go on to tweak
that state. ifupdown often fails at this because it relies on state
files that can become stale, and it doesn't understand dependencies. NM
fails because it doesn't support many of the configurations that people
want, and because it will try to re-enter the configured state again
after e.g. a link reset.
Stanislav Maslovski
This reply went to debian-russian@ due to a mistake. Next doing a
bounce to d-d was another mistake, so if you receive this message
twice, I am sorry for that!
Still I feel that I cannot leave it unanswered, so here it goes.
On Sun, Apr 03, 2011 at 11:26:20PM +0530, Josselin Mouette wrote:
> Le dimanche 03 avril 2011 à 21:32 +0400, Stanislav Maslovski a écrit :
> > Analogously, when I see such "great" technical suggestions as
> > replacing ifupdown on default installs with network-manager, I can't
> > help thinking (and sometimes commenting) that if this trend continues,
> > then at some point in future I may face a painful decision to abandon
> > the distribution that I continuously used for more than a decade and
> > to which I contributed.
>
> May I suggest that you install a squeeze system with the desktop task,
> with a simple DHCP network configuration?
Why on earth would I do that? It does not match my needs at all. For
instance, this laptop sometimes connects to a couple of remote LANs
through VPNs, so that I have to set up routing in a not completely
trivial manner. On another site where I sometimes work, there is an
IPX network to which I have to connect to access the fileserver.
Occasionaly, I have to run another OS in a virtual machine on this
laptop for which I set up a bridge, etc.
I am not even mentioning any servers, as it is obvious that
network-manager is a "no-no" for them.
> You will see that your network is no longer managed by ifupdown. So
> we’re talking about something that has partly already happened, and
> AFAICT the world hasn’t fallen apart.
Well, I can only feel pity for the users who fell into this trap. Do
you know what is the first advise that is given to those users when
they eventually run into a problem with their network?
Right, deinstal network-manager!
> So far your only contribution to the discussion has been “If this
> happens, I will use another distribution.” Fine.
That is not exactly true, while I understand that certain people
prefer to see it like this.
> But could you explain why we would care? I should probably remind you
> that Debian is, at first, a do-o-cracy, so if you’re not interested
> into fixing things yourself
Yes, I usually fix bugs myself when I need it, if you mean this.
Try googling "Stanislav Maslovski +patch".
> or at least giving constructive criticism
If you read my mails without a prejudice you will notice it.
> please let other people dream of other technical solutions that they
> might actually end up improving the state of our network stack (which
> is, in case you haven’t noticed, absolutely disastrous).
If you mean the ifupdown-based configuration, then I cannot agree that
it is "really disastrous" (I would agree that the network-manager
approach is really disastrous, however) as at least in my cases (which
are not so trivial) ifupdown works okay (and if not then at least I
would know ways how to workaround problems).
--
Stanislav
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20110403211...@kaiba.homelan
Stanislav Maslovski
> I have read all e-mails in this thread, and what constructive criticism
> you may have given is buried under uncompromising prejudice. For
> example:
>
> > If you mean the ifupdown-based configuration, then I cannot agree that
> > it is "really disastrous" (I would agree that the network-manager
> > approach is really disastrous, however) as at least in my cases (which
> > are not so trivial) ifupdown works okay (and if not then at least I
> > would know ways how to workaround problems).
>
> well for quite a number of people. It is hard to take you seriously,
> when you say things that are so clearly wrong.
Be it clearly wrong or not, I strongly disbelieve that a tool with a
hard-wired logic such a network-manager may seem a reasonable
replacement for such a configurable tool as ifupdown. These two tools
have been designed with absolutely different goals in mind. And I
think it is quite clear that even with the current limitations of
ifupdown (some were mentioned in this thread) its intended use case is
wider than the use case of network-manager.
--
Stanislav
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20110403234...@kaiba.homelan
Henrique de Moraes Holschuh
> Henrique de Moraes Holschuh <h...@debian.org> writes:
> > On Thu, 31 Mar 2011, Goswin von Brederlow wrote:
> >> > /etc/adjtime
> >
> > This needs to survive reboots, and it is also needed early in the boot.
> > It is used to correct the RTC syndrome.
> >
> > I am at a loss about how it could be made compatible with RO /.
>
> So my clock is sightly wrong during boot until the ntpd/chrony/ntpdate
> fixes it. It doesn't give errors so i can live with that.
*Your* clock is slightly wrong, but there are a lot more than just slightly
wrong clocks out there. You likely don't leave the box turned off for a
long while, either, and you're usually online so you can use
ntp/chrony/ntpdate. /etc/adjtime can do wonders to offline boxes, and to
boxes that are not turned on that often.
OTOH, refreshing my knownledge of this stuff (which I haven't needed for a
while because right now I have no boxes that stay offline for too long)
shows that the interaction with a RO / is not too bad (see adjtimex(8),
http://linuxcommand.org/man_pages/adjtimex8.html).
It looks like we can assume that automatic adjustment of /etc/adjtime will
only happen where the local admin really knows what he is doing, and manual
adjustment has never been a problem in the first place.
So, /etc/adjtime must remain where it is, but it can be RO.
> >> > /etc/hosts.deny (written by denyhosts, hence that one is a bit hard to fix)
> >>
> >> Don't have that. Fix denyhosts to link that to /var/ (or /run when we
> >> have it).
> >
> > Has to be available before any tcp-wrapped network service is started.
>
> I guess you could just have a /etc/defaults/hosts.deny that you copy to
> /run and link /etc/hosts.deny -> /run/hosts.deny before starting
> tcp-wrapped network services.
No. The fix is to leave /etc/hosts.{deny,allow} alone, and instead fix
anything that likes to write to them to not do it, and use the extended
syntax that allows one to read the hosts to block/allow from a separate
file. Maybe add something that updates the files in /etc at shutdown as
well.
Anything else will be playing funny chance games with system security.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2011040401...@khazad-dum.debian.net
Dmitry E. Oboukhov
>>> it is "really disastrous" (I would agree that the network-manager
>>> approach is really disastrous, however) as at least in my cases (which
>>> are not so trivial) ifupdown works okay (and if not then at least I
>>> would know ways how to workaround problems).
>>
>> You say Network Manager is disastrous, when it manifestly works quite
>> well for quite a number of people. It is hard to take you seriously,
>> when you say things that are so clearly wrong.
SM> Be it clearly wrong or not, I strongly disbelieve that a tool with a
SM> hard-wired logic such a network-manager may seem a reasonable
SM> replacement for such a configurable tool as ifupdown.
I fully agree that.
It is wrong tendency to replace rich, functional, certified mechanizm
by stupid scheme.
Stupid scheme (intended for stupid users) should be based on ifupdown
but shouldn't replace it.
--
. ''`. Dmitry E. Oboukhov
: :’ : email: un...@debian.org jabber://UN...@uvw.ru
`. `~’ GPGKey: 1024D / F8E26537 2006-11-21
`- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537
Carsten Hey
managed to release again a version Debian can be proud of :) There were
of course things that could be done even better next time, but handling
such a enormous task without such issues seems to be impossible.
One thing that the release team already is improving is communication,
for example, they did ask for feedback and welcomed comments in their
mail to debian-devel-announce. One example of less outstanding
communication that happened during the past freeze is that
squeeze-updates has been announced without any prior discussion.
Important aspects of proper communication include comprehensible
justification of decisions and also predictability. As part of an
explanation they once wrote "DebConf should definitely not fall into
a freeze and that we should leave time after DebConf to ..." in an
announcement. A year later they did the opposite and froze at the end
of DebConf. Other reasons that were considered internally like
synchronisation with other distributions were missing in this first
mentioned announcement.
The other thing that has potential to be improved is the freezing.
The relevant part of freeze history is in my opinion:
* There were two mails from the release team regarding uploads on d-d-a
in the week before Lenny was frozen.
* Contrary to what was communicated earlier, Squeeze was frozen weeks
before most people expected it and before the announced Perl
transition has happened.
If the release team would skip those "we freeze next week" mails, there
wouldn't be such a flood of uploads just before the freeze.
If they would additionally stick with what they announce, nobody would
complain that a freeze would have happened unexpected.
* Stefano Zacchiroli [2011-04-03 18:15 +0200]:
> On Tue, Mar 29, 2011 at 10:51:02AM +0100, Neil McGovern wrote:
> > Time based freezes
> > ------------------
> Road maps
> ---------
>
> I believe we need time based freezes. Even more radically, I believe we
> need to know the freeze date as soon as possible, e.g. no later than a
> couple of weeks after the preceding release. (Obviously, transitioning
> to time based freezes warrant exceptions to the rule.)
I believe we need to know a vague time frame for freezing instead.
With your proposal the release team might announce:
We released on the 7th of February 2011 and freeze Wheezy one and a half
year later on the 7th of October 2012.
With mine they could announce:
We released in February 2011 and we want about one and a half year
between a releases and the following freeze, so we freeze in fall
2012.
> My rationale for the above is simple: *road maps*. Each team and
> individual developer should be able to define their own road maps very
> early in a release cycle. Doing so will help teams in planning and
> splitting work.
Both would address the roadmap issue.
> I believe it will also help maintainers in negotiating release dates
> with upstreams which are sensible to distribution needs.
Deciding whether this would be a good thing could be highly
controversial.
> Strict date
> -----------
>
> The difficult part in moving to such a scheme is that the freeze date
> must be strict.
We are in the good position to have a very experienced release team that
is be able to decide whether testing is in a good condition to be
frozen. It should also have option to adapt their time planing to the
team's responses to "what are your plans for stable+1?" mails or to
events that can't be known a few weeks after the prior stable release
has happened.
> That is the case because, as history has taught us, announcing a freeze
> date and not respecting it
Avoiding not respecting announced time frames or dates should not be
that hard.
> ---or, equivalently, have announced freeze
> dates which are generally believed to be only indications---will spread
> frustration among developers.
This time frame could be rather imprecise at first and narrowed over
time.
> Freezing what?
> --------------
>
> The next question is then what does "freeze" means. Does it mean that
> automatic transition to testing stops automatically at freeze date,
This seems to be suboptimal (probably it's just your wording). The
following quote from a mail sent by the release team in 2008 describes
how it also has been handled for Squeeze:
| Packages that are present in unstable the day we freeze will be
| automatically allowed into testing, that is, the freeze date ... does
| not mean your package should be in testing by then, but only in
| unstable.
> All in all, I quite like the idea of a strict freeze date + a flexible
> period during which exceptions are granted in a more liberal manner, as
> it has happened for the first weeks after the Squeeze freeze.
The basic idea of a more flexible period is great, but it was not
properly communicated via debian-announce.
> Freezing when?
> --------------
>
> A scheme that could work is deciding that we'll have a development
> period of a specific length (1 year?) with a specific tolerance (+/-2
> months?). At the beginning of each release cycle, the release team will
> announce a freeze date contained in such a time window. The choice of
> the freeze data is within the responsibility of the Release Team
> already; if people will vehemently disagree with the decision, they have
> mechanisms to overrule the decision as well. Having the announcement
> occurring at the beginning of the release cycle will help in reducing
> the negative effects of changing the decision, in the hopefully unlikely
> case that people will really want to do that.
Regulation instead of using common sense is in my opinion not a good
choice to take such decisions, especially given that we talk about one
of Debian's core team.
I hope the release team carries on with their great work and maybe even
improves it where possible, e.g., by learning from the past.
Carsten
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20110404063...@furrball.stateful.de
Dmitry E. Oboukhov
RH> Hi,
RH> On Mon, 04 Apr 2011, Dmitry E. Oboukhov wrote:
>> Stupid scheme (intended for stupid users) should be based on ifupdown
>> but shouldn't replace it.
RH> Please refrain from calling people "stupid users" just because they use a
RH> software that you don't like.
There was a way "User can do anything", the way was replaced by the way
"User can do something in list". Obviously that this action has been
done for stupid users.
Yes, the old scheme *had* some defects, but new scheme *is* a defect.
But Ok, %s/stupid/ordinary/g
I agree that we must think about ordinary users but I disagree that we
must waste good instruments to please these users.
Steve Langasek
> On 08:18 Mon 04 Apr , Raphael Hertzog wrote:
> RH> Hi,
> RH> On Mon, 04 Apr 2011, Dmitry E. Oboukhov wrote:
> >> Stupid scheme (intended for stupid users) should be based on ifupdown
> >> but shouldn't replace it.
> RH> Please refrain from calling people "stupid users" just because they use a
> RH> software that you don't like.
> There was a way "User can do anything", the way was replaced by the way
> "User can do something in list". Obviously that this action has been
> done for stupid users.
Yes, a user can do anything with ifconfig if his time has no value. I am
happily using network manager on my laptop, because unlike ifconfig it's
easy to configure for use on new wireless networks.
I am not happy that network manager bypasses ifconfig to do this; I would
have much preferred a daemon that could properly integrate with the existing
infrastructure we had. But neither that, nor you calling me a stupid user,
is much motivation for me to go back to the pain of managing wireless
connections via ifupdown.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slan...@ubuntu.com vor...@debian.org
Raphael Hertzog
> I believe we need to know a vague time frame for freezing instead.
>
> With your proposal the release team might announce:
>
> We released on the 7th of February 2011 and freeze Wheezy one and a half
> year later on the 7th of October 2012.
>
> With mine they could announce:
>
> We released in February 2011 and we want about one and a half year
> between a releases and the following freeze, so we freeze in fall
> 2012.
>
> > My rationale for the above is simple: *road maps*. Each team and
> > individual developer should be able to define their own road maps very
> > early in a release cycle. Doing so will help teams in planning and
> > splitting work.
>
> Both would address the roadmap issue.
I don't agree with this. You can do _a lot_ in 3 months. So saying "fall"
leaves a big uncertainty in terms of roadmap.
Also when you consider a kernel that comes out every 3-4 months, it means
you might target an older version than what you really need due to this
uncertainty.
We don't need a firm date but the uncertainty should not be bigger than a
month IMO.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20110404070...@rivendell.home.ouaza.com
Neil Williams
Steve Langasek <vor...@debian.org> wrote:
> > There was a way "User can do anything", the way was replaced by the way
> > "User can do something in list". Obviously that this action has been
> > done for stupid users.
>
> Yes, a user can do anything with ifconfig if his time has no value. I am
> happily using network manager on my laptop, because unlike ifconfig it's
> easy to configure for use on new wireless networks.
>
> I am not happy that network manager bypasses ifconfig to do this; I would
> have much preferred a daemon that could properly integrate with the existing
> infrastructure we had. But neither that, nor you calling me a stupid user,
> is much motivation for me to go back to the pain of managing wireless
> connections via ifupdown.
I wouldn't go back to wireless via ifupdown either, I'd use wicd
because I've had my share of problems with network-manager. The real
issue, for me, is that I don't want to go to the pain of managing USB
networking connections via a daemon which is predicated on managing
wireless connections and/or complex bridging and VPN requirements.
There needs to be a simple tool with few dependencies and there needs
to be a complex solution with all the power that some users need. One
tool does not suit all here. It's not just about daemon vs GUI frontend
or whether to use DBus or Python - it's about having two or more tools
which work together instead of one simple tool which gets side-stepped
by a more complex tool because of a poor design.
Stanislav Maslovski
> On Mon, Apr 04, 2011 at 10:52:33AM +0400, Dmitry E. Oboukhov wrote:
> Yes, a user can do anything with ifconfig if his time has no value. I am
> happily using network manager on my laptop, because unlike ifconfig it's
> easy to configure for use on new wireless networks.
Well, actually configuring a wireless network with wpa_supplicant and
ifupdown is not hard at all and does not require too much time, _if_ a
user has developed a good habbit of reading documentation first.
It is also preferable in that sense that you configure it once and it
works for years, surviving upgrades, etc. So in the end you conserve
your time, and not loose your time.
There is also a basic GUI if one needs it (wpa_gui).
> I am not happy that network manager bypasses ifconfig to do this; I
> would have much preferred a daemon that could properly integrate with
> the existing infrastructure we had.
Exactly. There is ifplugd that implements some of the functionality
that is required to support dynamically appearing and disappearing
connections. It is a simple daemon that calls ifupdown when needed, so
that the old and good way of network configuration is respected.
But ifplugd needs some love, because it was mostly intended to be used
with ethernet cable connections (I managed to use it also with dynamic
tap interfaces, though).
--
Stanislav
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2011040407...@kaiba.homelan
Goswin von Brederlow
> On Sun, 03 Apr 2011, Goswin von Brederlow wrote:
>> Henrique de Moraes Holschuh <h...@debian.org> writes:
>> > On Thu, 31 Mar 2011, Goswin von Brederlow wrote:
>> >> > /etc/adjtime
>> >
>> > This needs to survive reboots, and it is also needed early in the boot.
>> > It is used to correct the RTC syndrome.
>> >
>> > I am at a loss about how it could be made compatible with RO /.
>>
>> So my clock is sightly wrong during boot until the ntpd/chrony/ntpdate
>> fixes it. It doesn't give errors so i can live with that.
>
> *Your* clock is slightly wrong, but there are a lot more than just slightly
> wrong clocks out there. You likely don't leave the box turned off for a
> long while, either, and you're usually online so you can use
> ntp/chrony/ntpdate. /etc/adjtime can do wonders to offline boxes, and to
> boxes that are not turned on that often.
>
> OTOH, refreshing my knownledge of this stuff (which I haven't needed for a
> while because right now I have no boxes that stay offline for too long)
> shows that the interaction with a RO / is not too bad (see adjtimex(8),
> http://linuxcommand.org/man_pages/adjtimex8.html).
>
> It looks like we can assume that automatic adjustment of /etc/adjtime will
> only happen where the local admin really knows what he is doing, and manual
> adjustment has never been a problem in the first place.
>
> So, /etc/adjtime must remain where it is, but it can be RO.
That was what I was saying. You cut the part about running read-write
for a while to get the /etc/adjtime primed.
>> >> > /etc/hosts.deny (written by denyhosts, hence that one is a bit hard to fix)
>> >>
>> >> Don't have that. Fix denyhosts to link that to /var/ (or /run when we
>> >> have it).
>> >
>> > Has to be available before any tcp-wrapped network service is started.
>>
>> I guess you could just have a /etc/defaults/hosts.deny that you copy to
>> /run and link /etc/hosts.deny -> /run/hosts.deny before starting
>> tcp-wrapped network services.
>
> No. The fix is to leave /etc/hosts.{deny,allow} alone, and instead fix
> anything that likes to write to them to not do it, and use the extended
> syntax that allows one to read the hosts to block/allow from a separate
> file. Maybe add something that updates the files in /etc at shutdown as
> well.
Works too. I hope that extended syntax allows mentioning a file that is
not yet there. Or would you then get errors about file not found early
during boot?
> Anything else will be playing funny chance games with system security.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/87lizqz...@frosties.localnet
Julien Cristau
> I don't agree with this. You can do _a lot_ in 3 months. So saying "fall"
> leaves a big uncertainty in terms of roadmap.
>
And you know two years in advance exactly what you'll have done and what
you'll want to do for the next three months? I somehow doubt that. And
if I'm wrong, you can use the three months you have on your hands to
polish your packages (and everybody else's). Maybe that way the freeze
can be less than 6 months.
Cheers,
Julien
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2011040408...@radis.liafa.jussieu.fr
Martin Wuertele
> The kernel necessarily holds the working network configuration, though
> it lacks e.g. credentials for WPA or 802.1x which are handled by
> user-space. User-space can change that state, and can read the state
> (including waiting for updates) using netlink. User-space needs to
> provide policy for potential states, and authentication credentials.
>
> I think that what people like about ifupdown (when it works) is that
> they can say 'put this interface in this state' and then go on to tweak
> that state. ifupdown often fails at this because it relies on state
> files that can become stale, and it doesn't understand dependencies. NM
> fails because it doesn't support many of the configurations that people
> want, and because it will try to re-enter the configured state again
> after e.g. a link reset.
Does this imply that "fixing" ifupdown to query the state(s) via netlink
instead of relying on state files would solve most of the problems?
yours,
Martin
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2011040408...@anguilla.debian.or.at
Rens Houben
> Am 03.04.2011 18:22, schrieb Faidon Liambotis:
> > And, above all, losing the network configuration, even for a second,
> > just because you restarted a daemon (or that daemon died) shouldn't be
> > acceptable for the primary network configuration of our distribution.
> Full ACK.
> I also made those experiences with two fedora servers, who are using per
> default NM :(
and when it updated network-manager it cheerfully downed the interface
and broke the connection, which in turn interrupted the upgrade process
so that the interface didn't come back /up/ either.
I don't know if that's been fixed in more recent versions; needless to
say I purged it and everything associated and haven't touched it since.
--
Rens Houben | opinions are mine
Resident linux guru and sysadmin | if my employers have one
Systemec Internet Services. |they'll tell you themselves
PGP key at http://marduk.systemec.nl/~shadur/shadur.key.asc
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2011040408...@proteus.systemec.nl
Steffen Möller
On 04/03/2011 06:15 PM, Stefano Zacchiroli wrote:
> On Tue, Mar 29, 2011 at 10:51:02AM +0100, Neil McGovern wrote:
>
>> Time based freezes
>> ------------------
>>
I very much agree that with an increasing complexity
of our distribution that goes together with an increasing
heterogeneity of tools and teams, there will always be
some waiting for something to get fixed/improved. A
particular time to freeze, if one does not freeze too often,
seems like a very good idea, then.
The time-based freeze should be decided together (if
possible) with accepting a constantly usable testing [1].
This way, the release team and the commnity may have
some better understanding what exactly it is freezing.
> Road maps
> ---------
>
To me, it would be interesting to have releases to be
associated with particular new features that are not too
likely to be backported. When there is no such unique
feature, one should not freeze but just continue updating
CUT and help backports where appropriate.
We should all be waiting for those new features to become
functional and stable in Debian, not for the release team
to make a particular decision - even though this effectively
may be the very same thing.
> Freezing what?
> --------------
>
When backports are integrated very closely with the
main distribution, the question what or when to freeze is not
really a question any more, I tend to think.
We do have quite a number of packages, especially in the
scientific world, for which the versioning is very important.
Different users, or even different projects for the same user,
may require different versions. To have snapshot.debian.org
and backports, together with good support for chroots and
virtualisation, which we have, shall be considered more
important for many than the question when and what to freeze.
Many greetings
Steffen
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Jon Dowland
> On Mon, Apr 4, 2011 at 09:05:50 +0200, Raphael Hertzog wrote:
>
> > I don't agree with this. You can do _a lot_ in 3 months. So saying "fall"
> > leaves a big uncertainty in terms of roadmap.
> >
> And you know two years in advance exactly what you'll have done and what
> you'll want to do for the next three months? I somehow doubt that. And
> if I'm wrong, you can use the three months you have on your hands to
> polish your packages (and everybody else's). Maybe that way the freeze
> can be less than 6 months.
Some people work to a plan from one release to the next (and I congratulate
them for managing!) but I think a *lot* of the minor work and QA work that
goes on is less coordinated or organised than that, with sporadic bits of
work towards a goal in fits and starts as people work around real life
commitments, followed by a short-term coordinated push to finish off work
before a concrete freeze date, nearer the time.
A worked example: I might have some vague goals as to what I would like to
achieve in Debian for the next release, immediately following the previous
release (i.e., now). But I have no idea when the release will happen, nor
what else will happen in my life over the next 2+ years. So, we make some
loose commitments and begin work on things.
At some point after that, I'll get a mail telling me we're freezing in a
month, or two months (or whatever), on date X. At this point, the release
is concrete, my goals are either plausible or not, and I will be much more
organised in setting aside time for Debian and polishing off my packages
and ambitions for the release. (and thus I was totally scuppered for
Squeeze).
So if a vague freeze date (such as "Fall 2011") is all we get now, we still
need a firmer *future* date, nearer the time (e.g., "Freeze on Halloween",
announced late August), to allow this sort of work cycle to happen.
Of course, if we had more predictable freeze or release cycles from the
beginning, my work patterns might be different. It's a chaotic system,
with each of us adapting to the current environment :-)
--
Jon Dowland
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20110404094...@deckard.alcopop.org
Julien Cristau
> So if a vague freeze date (such as "Fall 2011") is all we get now, we still
> need a firmer *future* date, nearer the time (e.g., "Freeze on Halloween",
> announced late August), to allow this sort of work cycle to happen.
>
I think that was part of what Carsten was saying.
Cheers,
Julien
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2011040410...@radis.liafa.jussieu.fr
Ben Hutchings
> > On 08:18 Mon 04 Apr , Raphael Hertzog wrote:
> > RH> Hi,
>
> > RH> On Mon, 04 Apr 2011, Dmitry E. Oboukhov wrote:
> > >> Stupid scheme (intended for stupid users) should be based on ifupdown
> > >> but shouldn't replace it.
>
> > RH> Please refrain from calling people "stupid users" just because they use a
> > RH> software that you don't like.
>
> > There was a way "User can do anything", the way was replaced by the way
> > "User can do something in list". Obviously that this action has been
> > done for stupid users.
>
> Yes, a user can do anything with ifconfig if his time has no value. I am
> happily using network manager on my laptop, because unlike ifconfig it's
> easy to configure for use on new wireless networks.
>
> I am not happy that network manager bypasses ifconfig to do this;
I am. NM uses the correct interface, i.e. netlink. ifconfig is a
BSD legacy.
Ben.
--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2011040410...@decadent.org.uk
Jon Dowland
> It also can't do VLANs (.1q), bridges, bonds and all possible
> permutations of the above. I'd speculate that it also wouldn't be able
> to do things like 1k (or more) interfaces. It also doesn't support hooks
> to be able to do more advanced setups, such as multihoming, policy
> routing, QoS, etc.
Is it necessary for the distribution's *default* network-management solution to
handle all of these? If it could be easily substituted for another solution
that was better suited to tasks which a majority of users will not use, then
surely that is fine.
(although I'd like to get NM and bridging working more nicely personally, I
consider this more of a feature bug than an RC one)
> And, above all, losing the network configuration, even for a second,
> just because you restarted a daemon (or that daemon died) shouldn't be
> acceptable for the primary network configuration of our distribution.
IMHO this is a reasonable requirement, yes.
--
Jon Dowland
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20110404105...@deckard.alcopop.org
Ben Hutchings
> * Ben Hutchings <b...@decadent.org.uk> [2011-04-03 20:56]:
>
> > The kernel necessarily holds the working network configuration, though
> > it lacks e.g. credentials for WPA or 802.1x which are handled by
> > user-space. User-space can change that state, and can read the state
> > (including waiting for updates) using netlink. User-space needs to
> > provide policy for potential states, and authentication credentials.
> >
> > I think that what people like about ifupdown (when it works) is that
> > they can say 'put this interface in this state' and then go on to tweak
> > that state. ifupdown often fails at this because it relies on state
> > files that can become stale, and it doesn't understand dependencies. NM
> > fails because it doesn't support many of the configurations that people
> > want, and because it will try to re-enter the configured state again
> > after e.g. a link reset.
>
> Does this imply that "fixing" ifupdown to query the state(s) via netlink
> instead of relying on state files would solve most of the problems?
Ben.
--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2011040410...@decadent.org.uk
Jon Dowland
> Why on earth would I do that? It does not match my needs at all. For
> instance, this laptop sometimes connects to a couple of remote LANs
> through VPNs, so that I have to set up routing in a not completely
> trivial manner.
I rarely have to use VPNs myself, but when I do, I find network-manager-pptp
the most reliable way to do so.
--
Jon Dowland
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20110404105...@deckard.alcopop.org
Ben Hutchings
> The release team did again a great job the past release cycle and
> managed to release again a version Debian can be proud of :) There were
> of course things that could be done even better next time, but handling
> such a enormous task without such issues seems to be impossible.
The release team has done good work during the freeze. However, I
cannot agree with the overall assessment of this release cycle. The
announcement of time-based freezes, followed by the rapid retraction
and further discussion, was farcical. The apparent result was that
no-one really believed in any stated freeze date, and many packages
were unready when the freeze really did begin.
> One thing that the release team already is improving is communication,
[...]
I do agree with this. I have no complaints about communication
during the freeze.
By the way, as a member of the kernel team I was consulted directly by
the release team regarding readiness of the Linux kernel packages
before some of the release decisions. I appreciate that but I believe
that consultation should be opened to the entire developer base before
any final decisions.
Ben.
--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2011040410...@decadent.org.uk
Bernd Zeimetz
>> Bugs were opened long ago,
>
> Could you please give me the numbers?
http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=ifupdown;dist=unstable
More than enough to fix.
>> but there is no interest/manpower to fix
>> them (which is not surprising if you have ever looked at the ifupdown
>> source).
>
> Source? It's beautiful, I can say. It's literate. It's well-structured.
>
> Manpower? Here it is [points at himself].
>
--
Bernd Zeimetz Debian GNU/Linux Developer
http://bzed.de http://www.debian.org
GPG Fingerprints: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Simon McVittie
On Sun, 03 Apr 2011 at 18:15:52 +0200, Stefano Zacchiroli wrote:
> I believe we need time based freezes. Even more radically, I believe we
> need to know the freeze date as soon as possible, e.g. no later than a
> couple of weeks after the preceding release. (Obviously, transitioning
> to time based freezes warrant exceptions to the rule.)
Telepathy does a stable-branch of each major component not long before each
GNOME release, so every 6 months. In the absence of a preannounced freeze
date, we basically need to only release stable-branch versions to unstable
(with development versions in experimental), which reduces the ability to get
real-world testing on the features added by the development branch, and
find/fix the bugs before declaring it stable; chicken/egg?
With a preannounced freeze date, we'd be able to push many of our development
versions into unstable/testing (reserving experimental for only riskier
changes), and become more cautious when we get within 6 months of the freeze
date.
It'd be tempting to say "early testing? That's what (Fedora|Gentoo|Arch)
users are for", but I don't think that's a sustainable approach; finding bugs
is one of the ways in which we (should) help our upstreams.
(When I say "development versions", I mean "upstream release with new features"
rather than "random snapshot which might even work", obviously.)
> The next question is then what does "freeze" means. Does it mean that
> automatic transition to testing stops automatically at freeze date, or
> rather that no new transitions are accepted anymore (which IIRC has been
> proposed before).
For the squeeze freeze, all packages that were in unstable on freeze day
were pre-approved for the usual time-based migration (by the RT adding a large
initial number of hints), and the RT had a relaxed policy for freeze-exception
requests for a while. If that's not too much work to do again, it seems a good
compromise?
S
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20110404110...@reptile.pseudorandom.co.uk
Piotr Ożarowski
> Road maps
+1
no, I cannot fix & upload (without waiting for sponsoree who has a list
of things to learn/fix) 10+ RFS packages (postponed mostly due to
packaging bugs), deal with increased number of "normal" RFS mails ("I
was working on improving the package for last few weeks, please upload
it now because the freeze will happen this week"), scan thru 500+ team
packages (to check if every transition is done or to upload new upstream
version that fixes annoying bugs or simply to clear team's RFS list /
upload UNRELEASED fixes), complete transitions (which can take some time,
even for small packages like sqlalchemy¹, not even mentioning PITA
python-defaults transitions²)... in one day/week/month (even with "soft"
freeze for the next month)
[¹] which never were announced to release managers (and never will most
probably)
[²] hint: python2.5 in Squeeze
> Strict date
+1
most of the work is done by our upstreams, and by simply telling
them "we'll freeze PICK_YOUR_MONTH every even/odd year" will (in the long
term) improve quality of Debian *a lot* more than choosing a random^Wperfect
(and different) date for every release cycle (and not announcing it to
upstream authors *at all*), IMHO
--
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl www.griffith.cc www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Josselin Mouette
> Well, actually configuring a wireless network with wpa_supplicant and
> ifupdown is not hard at all and does not require too much time, _if_ a
> user has developed a good habbit of reading documentation first.
It seems to be a common belief between some developers that users should
have to read dozens of pages of documentation before attempting to do
anything.
I’m happy that not all of us share this elitist view of software. I
thought we were building the Universal Operating System, not the
Operating System for bearded gurus.
> It is also preferable in that sense that you configure it once and it
> works for years, surviving upgrades, etc. So in the end you conserve
> your time, and not loose your time.
Do you even know in what kind of contexts a laptop with wireless
connection is actually used? Because from your sentence it looks like
you live in a different world.
--
.''`.
: :' : “You would need to ask a lawyer if you don't know
`. `' that a handshake of course makes a valid contract.”
`- -- J???rg Schilling
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1301918712.3448.124.camel@pi0307572
Russell Coker
> There needs to be a simple tool with few dependencies and there needs
> to be a complex solution with all the power that some users need. One
> tool does not suit all here. It's not just about daemon vs GUI frontend
> or whether to use DBus or Python - it's about having two or more tools
> which work together instead of one simple tool which gets side-stepped
> by a more complex tool because of a poor design.
It does seem likely that there won't be one tool that satisfies all
requirements. The current situation of giving users the choice of ifupdown,
NetworkManager, wicd, and probably other things seems good.
It doesn't seem likely that I would want NM on one of my servers. But having
it on my laptop and netbook would be good if it worked as desired. Last time
I tested NM it didn't work as desired - or at least not with the amount of
effort I was prepared to put into it.
If the plan is to depend more on NM in the next release then I'll probably
test it some more on a laptop running Unstable and file some bugs.
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/201104042159....@coker.com.au
Dmitry E. Oboukhov
>> ifupdown is not hard at all and does not require too much time, _if_ a
>> user has developed a good habbit of reading documentation first.
JM> It seems to be a common belief between some developers that users should
JM> have to read dozens of pages of documentation before attempting to do
JM> anything.
JM> I’m happy that not all of us share this elitist view of software. I
JM> thought we were building the Universal Operating System, not the
JM> Operating System for bearded gurus.
User MUST study each OS he uses. If he doesn't want he will be
forced to pay the other people who will tune his (user's) system.
There is no discrimination here.
I'm not a guru, but I don't understand why Debian must be broken to
please a user who doesn't want to read anything.
Ben Hutchings
> On Mon, 4 Apr 2011, Neil Williams <code...@debian.org> wrote:
> > There needs to be a simple tool with few dependencies and there needs
> > to be a complex solution with all the power that some users need. One
> > tool does not suit all here. It's not just about daemon vs GUI frontend
> > or whether to use DBus or Python - it's about having two or more tools
> > which work together instead of one simple tool which gets side-stepped
> > by a more complex tool because of a poor design.
>
> It does seem likely that there won't be one tool that satisfies all
> requirements. The current situation of giving users the choice of ifupdown,
> NetworkManager, wicd, and probably other things seems good.
We should be able to say 'for these sorts of configurations, X is probably
best, but for those, Y is better.' (I suspect that no single X could be
recommended for all configurations.) Giving users 5 choices and no
guidance would be unhelpful.
Ben.
--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2011040412...@decadent.org.uk
Josselin Mouette
> User MUST study each OS he uses.
No, he must not. The OS must adapt to the user’s needs, not the
opposite.
> If he doesn't want he will be
> forced to pay the other people who will tune his (user's) system.
A lot of users actually pay for that indeed. I don’t see this as a
problem, especially since it gets me to eat every day.
> There is no discrimination here.
Who talks about discrimination? It’s just being stubborn insisting that
people do the things you say while you are in no position to order them.
> I'm not a guru, but I don't understand why Debian must be broken to
> please a user who doesn't want to read anything.
If Debian could not be used without reading a manual, then I would call
it broken.
--
.''`.
: :' : “You would need to ask a lawyer if you don't know
`. `' that a handshake of course makes a valid contract.”
`- -- J???rg Schilling
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1301920590.3448.132.camel@pi0307572
Dmitry E. Oboukhov
JM> No, he must not. The OS must adapt to the user’s needs, not the
JM> opposite.
Create OS that can even be used by stupid and only stupid will use
that.
>> If he doesn't want he will be
>> forced to pay the other people who will tune his (user's) system.
JM> A lot of users actually pay for that indeed. I don’t see this as a
JM> problem, especially since it gets me to eat every day.
I said we shouldn't care about people who choose to pay You money
against (instead) to learn something.
>> There is no discrimination here.
JM> Who talks about discrimination? It’s just being stubborn insisting that
JM> people do the things you say while you are in no position to order them.
>> I'm not a guru, but I don't understand why Debian must be broken to
>> please a user who doesn't want to read anything.
JM> If Debian could not be used without reading a manual, then I would call
JM> it broken.
There is only one thing that can be used without reading a manual. It
is a breast. All the other devices (and things, substances, etc)
required to be studied.
Ben Armstrong
> There is only one thing that can be used without reading a manual. It
> is a breast. All the other devices (and things, substances, etc)
> required to be studied.
While this paraphrase of a familiar quote may be applicable when taken
in context (in reference to user interfaces) it is not applicable here.
Some *basic* familiarity with computer user interfaces is, of course,
needed to use Debian. If you can type on a keyboard, know how to use a
mouse to click icons, know what menus and folders are, how to start
programs from menus and icons, well, I think you're off to a good start.
That stuff, unlike the nipple, is all learned.
The point is, assuming at least basic familiarity with computers, no
user should be *unable* to use Debian without having to first read a
manual! They should be able to boot a Debian system and right away start
using it productively. Inability to connect to a (often wireless, these
days) network is a show-stopper. Without a network, many users will not
be able to accomplish *anything* on Debian.
Now, NetworkManager seems to have delivered the goods, here, at least
for the common use scenarios I typically see for new users. That's what
makes it a good default. I say that without denying that for users
comfortable with other methods, NM may be totally unsuitable, but I
think for the majority of users, NM makes a better default.
Ben
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/4D99C521...@sanctuary.nslug.ns.ca
Ben Armstrong
> I do not think that reading documentation before trying to achieve
> something is that elitist. And in the case of wpa_supplicant, it is
> definitely not dozens of pages. Basically, it is just
>
> man interfaces
> man wpa_supplicant.conf
> zless /usr/share/doc/wpasupplicant/README.Debian.gz
Without "expert" help, no new user will find these. A Debian Squeeze
laptop user will have a broken network by default, and nothing obvious
pointing them to the answer. Just a mute (if pretty) desktop, blankly
defying them to get the network to work!
> The wireless networks in public locations are usually open and do not
> require any specific configuration; the most of them are catched with
> a simple roaming setup outlined in that README from above, supplanted
> with a default /e/n/interfaces stanza for DHCP-based networks. If one
> instead prefers using a GUI, then there is wpa_gui with which one may
> scan for networks, select the needed one, change parameters, etc.
I have done user support with countless new users on irc, first on
#debian-eeepc and recently, also on #debian. It is the very rare
(bearded guru? good one :) new Debian user that will have a happy time
jumping through the hoops to make wpa_supplicant work for them. And even
once they manage to make it work, I've *still* seen cafe connections
fail on my lovingly hand-crafted wpa_cli + wpa_supplicant setup that
succeed when I reboot to a Squeeze GNOME live image with NM. I to this
day have not been able to figure out why.
> I also use wireless at home and at the sites where I work. For these
> locations I have several fixed stanzas in /e/n/interfaces and in
> wpa_supplicant.conf that I do not need to touch at all.
That's good for you, clearly. Nobody's trying to argue that your
solution isn't a perfectly fine one for you, and others with similar
needs. But the average laptop user really does have a hard time with the
status quo. Something needs to change in the next release.
Ben
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/4D99CA01...@sanctuary.nslug.ns.ca
Stanislav Maslovski
> Le lundi 04 avril 2011 à 11:55 +0400, Stanislav Maslovski a écrit :
> > Well, actually configuring a wireless network with wpa_supplicant and
> > ifupdown is not hard at all and does not require too much time, _if_ a
> > user has developed a good habbit of reading documentation first.
>
> It seems to be a common belief between some developers that users should
> have to read dozens of pages of documentation before attempting to do
> anything.
>
> I’m happy that not all of us share this elitist view of software. I
> thought we were building the Universal Operating System, not the
> Operating System for bearded gurus.
I do not think that reading documentation before trying to achieve
something is that elitist. And in the case of wpa_supplicant, it is
definitely not dozens of pages. Basically, it is just
man interfaces
man wpa_supplicant.conf
zless /usr/share/doc/wpasupplicant/README.Debian.gz
(and for most cases just reading that README.Debian should be enough)
> > It is also preferable in that sense that you configure it once and it
> > works for years, surviving upgrades, etc. So in the end you conserve
> > your time, and not loose your time.
>
> Do you even know in what kind of contexts a laptop with wireless
> connection is actually used? Because from your sentence it looks like
> you live in a different world.
Perhaps, I do. I travel quite a lot, so I use my laptop in airports,
libraries, hotels, etc.
The wireless networks in public locations are usually open and do not
require any specific configuration; the most of them are catched with
a simple roaming setup outlined in that README from above, supplanted
with a default /e/n/interfaces stanza for DHCP-based networks. If one
instead prefers using a GUI, then there is wpa_gui with which one may
scan for networks, select the needed one, change parameters, etc.
I also use wireless at home and at the sites where I work. For these
locations I have several fixed stanzas in /e/n/interfaces and in
wpa_supplicant.conf that I do not need to touch at all.
--
Stanislav
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20110404133...@kaiba.homelan