Re: time based freezes
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. 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
Re: Flaming as a way to reach technical quality? No! (was: network-manager as default? No! (was: Bits from the Release Team - Kicking off Wheezy))
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, 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. -- . ''`. 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 signature.asc Description: Digital signature
Re: Flaming as a way to reach technical quality? No! (was: network-manager as default? No! (was: Bits from the Release Team - Kicking off Wheezy))
On Mon, Apr 04, 2011 at 10:52:33AM +0400, Dmitry E. Oboukhov wrote: 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 Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: time based freezes
On Mon, 04 Apr 2011, Carsten Hey wrote: 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-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110404070550.gl21...@rivendell.home.ouaza.com
Re: Hay one more, in GNU World
Hi, On Sunday 03 April 2011 11.57:02 Snow Star wrote: We are developing on good infrastructure Yours and Ubuntu, We want to develop on Your and Ubuntu GNU / Linux, and also to become great friends of the GNU world, and so our community becomes stronger. Our visions are similar to Yours. And the support of the (not talking about money) just the verbal, Do you agree that we still continue to develop on your platform, We will be happy to work in GNU / Linux development, any assistance You're in need to You or to Us. I hope You are ready for cooperation. You do not need any permission or agreement to use Linux, Debian GNU/Linux or any other, or to help with it's further development. Just do your bit, and we'll be happy. How do you contribute? See http://www.debian.org/intro/help and http://www.debian.org/devel/ Happy hacking! -- vbi -- Open source is more secure. Period. -- CTO Trend Micro http://news.zdnet.com/2100-1009_22-6083490.html signature.asc Description: This is a digitally signed message part.
Re: Old Release goal: Getting rid of unneeded *.la / emptying dependency_libs
On Sun, 03 Apr 2011 15:04:01 -0700 Russ Allbery r...@debian.org wrote: Neil Williams codeh...@debian.org writes: If you are listed in the attached dd-list, it means that the following tasks should be done REAL SOON NOW in order to smooth the path for Multi-Arch and comply with Policy 10.2: 0: Check the listed package for .la files in the current version in sid. 1: Modify your package to DROP the .la file completely, if it remains. You cannot just drop *.la files completely in every case. The cases listed are the ones where the .la file can be removed. Packages with .la files which don't meet those criteria were not included in the list. However, it looks like there could be a flaw in the original data. Software that uses libltdl to load dynamic objects often loads those objects by the *.la file name (and hence is documented that way in upstream documentation, FAQs, and so forth), so we create gratuitous incompatibilities with upstream if we drop those *.la files. It's also not necessary since there isn't a multi-arch issue. Policy 10.2 doesn't say to remove all *.la files. It says: Packages that use libtool to create and install their shared libraries install a file containing additional metadata (ending in .la) alongside the library. For public libraries intended for use by other packages, these files normally should not be included in the Debian package, since the information they include is not necessary to link with the shared library on Debian and can add unnecessary additional dependencies to other programs or libraries. If the .la file is required for that library (if, for instance, it's loaded via libltdl in a way that requires that meta-information), the dependency_libs setting in the .la file should normally be set to the empty string. If the shared library development package has historically included the .la, it must be retained in the development package (with dependency_libs emptied) until all libraries that depend on it have removed or emptied dependency_libs in their .la files to prevent linking with those other libraries using libtool from failing. I still believe all those caveats are important. As do I. The processing which leads to the list implements those caveats. The ones listed should fall into the category: until all libraries that depend on it have removed or emptied dependency_libs in their .la files to prevent linking with those other libraries using libtool from failing. That is why lines in the original data described as depended-on are omitted. For example, shibboleth-sp2 was in your list because it has loadable modules in the libapache2-mod-shib2 package: /usr/lib/shibboleth/adfs-lite.la /usr/lib/shibboleth/adfs-lite.so /usr/lib/shibboleth/adfs.la /usr/lib/shibboleth/adfs.so /usr/lib/shibboleth/odbc-store.la /usr/lib/shibboleth/odbc-store.so This is already Policy 10.2-compliant and will not cause problems with multi-arch since those modules and their *.la files are arch-dependent and will get separate installs on 32-bit and 64-bit paths if needed. OK, maybe there's a problem there. The line in the original data is: shibboleth-sp2: dependency_libs links-not-existing-la The original criteria were: 1. no flag to remove the la-file on next occasion 2. only dependency_libs to remove their la-file RSN, because they block removal of the la-files on another package (this flag can be wrongly hit if a package depends only on itself - but well, dropping the la-file is recommended as well here as with 1.) 3. only depended-on to do nothing at this time 4. with both dependency_libs depended-on to use sed -i s,^dependency_libs=.*,dependency_libs='', on all their la-files (I took care that self-dependencies don't appear in this category, but rather in 1 or 2). So where is the error? In the original data? Lintian already checks that *.la files don't contain the problematic dependency_libs setting. In a clean pbuilder sid chroot: dpkg-genchanges ../libgpeschedule_0.17-3_i386.changes dpkg-genchanges: not including original source code in upload dpkg-source --after-build libgpeschedule-0.17 dpkg-buildpackage: binary and diff upload (original source NOT included) Now running lintian... warning: lintian's authors do not recommend running it with root privileges! W: libgpeschedule source: debhelper-but-no-misc-depends libgpeschedule0-dbg W: libgpeschedule source: ancient-standards-version 3.7.3 (current is 3.9.1) W: libgpeschedule0-dbg: wrong-section-according-to-package-name libgpeschedule0-dbg = debug Finished running lintian. No warning from current lintian from sid, yet #620616 indicates that there is a problematic .la file here - and indeed it is currently deliberately installed. root@calvin:/home/libgpeschedule-0.17# cat debian/libgpeschedule-dev.install debian/tmp/usr/lib/libgpeschedule.la
Re: Flaming as a way to reach technical quality? No! (was: network-manager as default? No! (was: Bits from the Release Team - Kicking off Wheezy))
On Mon, 4 Apr 2011 00:00:01 -0700 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. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpCSFMYAUNM4.pgp Description: PGP signature
Re: Bits from the Release Team - Kicking off Wheezy
Henrique de Moraes Holschuh h...@debian.org writes:
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-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87lizqzc4q.fsf@frosties.localnet
Back to technical discussion? Yes! (was: network-manager as default? No!)
On Mon, Apr 04, 2011 at 12:00:01AM -0700, Steve Langasek wrote: 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-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110404075506.GA636@kaiba.homelan
Re: time based freezes
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. Cheers, Julien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110404081507.gc3...@radis.liafa.jussieu.fr
Bug#620783: ITP: libdist-zilla-plugin-run-perl -- Running external commands on specific hooks of Dist::Zilla
Package: wnpp Owner: Dominique Dumont domi.dum...@free.fr Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libdist-zilla-plugin-run-perl Version : 0.005 Upstream Author : Torsten Raudssus tors...@raudssus.de * URL : http://search.cpan.org/dist/Dist-Zilla-Plugin-Run/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : Dist::Zilla plugin to execute external commands Dist::Zilla::Plugin::Run uses specific hooks of Dist::Zilla to execute external command when running dzil. This module is useful to ship generated code in a Perl module distribution . Dominique -- http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/ http://www.ohloh.net/accounts/ddumont -o- http://ddumont.wordpress.com/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201104041008.02220.domi.dum...@free.fr
Re: Bits from the Release Team - Kicking off Wheezy
* 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? yours, Martin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110404082425.gc1...@anguilla.debian.or.at
Re: network-manager as default? No!
In other news for Sun, Apr 03, 2011 at 07:20:18PM +0200, Patrick Matthäi has been seen typing: 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 :( Agreed. Back a couple months ago I was updating my home system over SSH 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-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110404083336.gd9...@proteus.systemec.nl
Re: time based freezes
Hello, 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 [1] http://cut.debian.net/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d9988af.9020...@gmx.de
Re: time based freezes
On Mon, Apr 04, 2011 at 10:15:07AM +0200, Julien Cristau wrote: 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-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110404094225.gb14...@deckard.alcopop.org
Re: time based freezes
On Mon, Apr 4, 2011 at 10:42:25 +0100, Jon Dowland wrote: 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-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110404100101.gl3...@radis.liafa.jussieu.fr
Re: Flaming as a way to reach technical quality? No! (was: network-manager as default? No! (was: Bits from the Release Team - Kicking off Wheezy))
On Mon, Apr 04, 2011 at 12:00:01AM -0700, Steve Langasek wrote: On Mon, Apr 04, 2011 at 10:52:33AM +0400, Dmitry E. Oboukhov wrote: 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-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110404103130.gf2...@decadent.org.uk
Bug#620808: ITP: payyans -- A python utility to convert between ASCII and Unicode.
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org An ASCII to unicode conversion utility. Package name: payyans Version: latest Upstream Authors:Santhosh Thottingal, Nishan Naseer, Rajeesh K Nambiar santhosh.thottin...@gmail.com, nishan.nas...@gmail.com, Rajesh Nambiar rajeeshknamb...@gmail.com URL: http://wiki.smc.org.in/Payyans License: GPL Description:Payyans is a python program to convert the data written for ascii fonts in ascii format to the Unicode format. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1301912923.2924.5.camel@dLab
Re: time based freezes
On Mon, Apr 04, 2011 at 08:38:18AM +0200, Carsten Hey wrote: 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-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110404105048.gg2...@decadent.org.uk
Re: Bits from the Release Team - Kicking off Wheezy
On Mon, Apr 04, 2011 at 10:24:26AM +0200, Martin Wuertele wrote: * 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? I expect so, but it would be a very big 'fix'. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110404105615.gh2...@decadent.org.uk
Re: network-manager as default? No!
On Sun, Apr 03, 2011 at 07:22:47PM +0300, Faidon Liambotis wrote: 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-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110404105623.gc14...@deckard.alcopop.org
Re: network-manager as default? No! (was: Bits from the Release Team - Kicking off Wheezy)
On Mon, Apr 04, 2011 at 01:11:15AM +0400, Stanislav Maslovski wrote: 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-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110404105904.gd14...@deckard.alcopop.org
Re: time based freezes
I agree with Stefano, pretty much... 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-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110404110342.gb11...@reptile.pseudorandom.co.uk
Re: ifupdown and IPv6
On 03/31/2011 09:15 PM, Andrew O. Shadoura wrote: 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 ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d99a62d.6090...@bzed.de
Re: time based freezes
[Stefano Zacchiroli, 2011-04-03] 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-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110404111533.gc28...@piotro.eu
Re: Flaming as a way to reach technical quality? No! (was: network-manager as default? No! (was: Bits from the Release Team - Kicking off Wheezy))
On Mon, 4 Apr 2011, Neil Williams codeh...@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. 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 Bloghttp://doc.coker.com.au/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201104042159.43852.russ...@coker.com.au
Re: Back to technical discussion? Yes! (was: network-manager as default? No!)
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. 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-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1301918712.3448.124.camel@pi0307572
Re: Flaming as a way to reach technical quality? No! (was: network-manager as default? No! (was: Bits from the Release Team - Kicking off Wheezy))
On Mon, Apr 04, 2011 at 09:59:43PM +1000, Russell Coker wrote: On Mon, 4 Apr 2011, Neil Williams codeh...@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-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110404121455.gk2...@decadent.org.uk
Re: Back to technical discussion? Yes! (was: network-manager as default? No!)
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. 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. -- . ''`. 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 signature.asc Description: Digital signature
Re: Bug#620808: ITP: payyans -- A python utility to convert between ASCII and Unicode.
On Mon, Apr 04, 2011 at 03:58:43PM +0530, Dhananjay wrote: An ASCII to unicode conversion utility. Package name: payyans URL: http://wiki.smc.org.in/Payyans Description:Payyans is a python program to convert the data written for ascii fonts in ascii format to the Unicode format. Uhm, but Debian already contains an ASCII-Unicode converter. It's called cat. There's also an in-place version, /bin/true. This assumes UTF-8, but other Unicode encodings are not supported in a vast majority of tools anyway, and iconv can handle them. What payyans seems to do is converting from some other encoding where for example the octet 65 (0x41) doesn't mean A but അ, 66 is ക and so on. This is definitely not ASCII; it's about as close to it as to EBCDIC. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110404122718.ga23...@angband.pl
Bug#620821: ITP: vpnautoconnect -- Automatically reconnect VPNs created by NetworkManager
Package: wnpp Severity: wishlist Owner: barraud barraudman...@wanadoo.fr Package name: vpnautoconnect Version : 1.1.1 Upstream Author : BARRAUD Manuel barraudman...@wanadoo.fr URL : http://sourceforge.net/projects/vpnautoconnect/ License : (GPLv3) Programming Lang: (C) Description : Automatically reconnect VPNs created by NetworkManager vpnautoconnect is a daemon that allow you to reconnect automatically (at startup too) a vpn created with network manager. It can reconnect very quickly and monitor the bandwidth, It works with pptp and openvpn connections. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110404121537.14591.17309.report...@basilic.groupe-cid.com
Re: Back to technical discussion? Yes! (was: network-manager as default? No!)
Le lundi 04 avril 2011 à 16:19 +0400, Dmitry E. Oboukhov a écrit : 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-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1301920590.3448.132.camel@pi0307572
Re: Back to technical discussion? Yes! (was: network-manager as default? No!)
On ma, 2011-04-04 at 16:19 +0400, Dmitry E. Oboukhov wrote: 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. I dispute your assertion that our users must study the operating system we build for them. I not only dispute it, I counter-assert that we should not require typical users to study anything much to be able to do typical things on their Debian machines. Exactly what constitutes a typical user and typical things to do is open to some interpretation and discussion. 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. You're insulting again. Please stop. Nobody here is interested in breaking Debian. We're interested in improving it. As part of the process, we propose things that may or may not be good ideas. If we can't do that without insults, we're much less likely to have a constructive discussion, and we'll definitely have fewer ideas proposed. That is a good way of making sure Debian will not get better. If you don't like, say, Network Manager, that's fine. Nobody is asking you to like it. If you want to oppose NM replacing ifupdown, that's also fine, but do it by explaining why it is a bad choice to make, without insults, pointing out problems, and making a clear, cohesive argument. It's a question of how you express your opinion, not whether it's an acceptable opinion. -- Blog/wiki/website hosting with ikiwiki (free for free software): http://www.branchable.com/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1301921130.2967.74.ca...@havelock.liw.fi
Re: Back to technical discussion? Yes! (was: network-manager as default? No!)
User MUST study each OS he uses. 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. -- . ''`. 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 signature.asc Description: Digital signature
Re: Bug#620821: ITP: vpnautoconnect -- Automatically reconnect VPNs created by NetworkManager
Am 04.04.2011 14:15, schrieb barraud: Package: wnpp Severity: wishlist Owner: barraud barraudman...@wanadoo.fr Package name: vpnautoconnect Version : 1.1.1 Upstream Author : BARRAUD Manuel barraudman...@wanadoo.fr URL : http://sourceforge.net/projects/vpnautoconnect/ License : (GPLv3) Programming Lang: (C) Description : Automatically reconnect VPNs created by NetworkManager vpnautoconnect is a daemon that allow you to reconnect automatically (at startup too) a vpn created with network manager. It can reconnect very quickly and monitor the bandwidth, It works with pptp and openvpn connections. TBH I'd rather see that implemented as part of NetworkManager itself. Using a separate daemon for this looks wrong to me. VPN autoconnect is definitely on the TODO list of NetworkManager [1] and upstream would be happy to help with this effort. Please communicate this to the author of vpnautoconnect, maybe he is interested in joining the NM development and implement it in NM proper. Cheers, Michael [1] http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/TODO -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Back to technical discussion? Yes! (was: network-manager as default? No!)
On 04/04/2011 10:06 AM, Dmitry E. Oboukhov wrote: 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-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d99c521.6020...@sanctuary.nslug.ns.ca
Re: Back to technical discussion? Yes! (was: network-manager as default? No!)
On Mon, Apr 04, 2011 at 05:35:10PM +0530, Josselin Mouette wrote: 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-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110404133118.GA17213@kaiba.homelan
Re: Back to technical discussion? Yes! (was: network-manager as default? No!)
On 04/04/2011 10:31 AM, Stanislav Maslovski wrote: 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-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d99ca01.9030...@sanctuary.nslug.ns.ca
Re: Back to technical discussion? Yes! (was: network-manager as default? No!)
Le lundi 04 avril 2011 à 10:39 -0300, Ben Armstrong a écrit : But the average laptop user really does have a hard time with the status quo. Something needs to change in the next release. I think squeeze already does a lot better, but there is still work to do, especially with the installation process. On my personal wishlist for wheezy is d-i actually calling NM behind the scenes to configure the network, instead of ifupdown. I’ll definitely try to find time to hack on this. -- .''`.Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1301925813.3448.160.camel@pi0307572
Re: MBF alert: packages with very long source / .deb filenames
Goswin von Brederlow goswin-...@web.de Sun, April 3, 2011 5:17:06 PM Philipp Kern tr...@philkern.de writes: On 2011-04-03, Wouter Verhelst wou...@debian.org wrote: OTOH, do you really want to type apt-get install package-with-policy-compliant-utterly-long-silly-name? There's a point when package name lengths become problematic, and that isn't just true for ISO images. That's why $DEITY invented tab completion. (And yes, that really auto-completes on a stock Squeeze install.) Also those long names are usualy installed as part of dependencies so you never type them. outta site! outta mind ! ... there's more to the pizza than just the pie - hey hey my my unknown -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/185013.66870...@web35606.mail.mud.yahoo.com
Re: Back to technical discussion? Yes! (was: network-manager as default? No!)
On 04/04/2011 11:03 AM, Josselin Mouette wrote: I think squeeze already does a lot better, but there is still work to do, especially with the installation process. On my personal wishlist for wheezy is d-i actually calling NM behind the scenes to configure the network, instead of ifupdown. I’ll definitely try to find time to hack on this. I'm definitely going to step up here to test whenever you have something ready, as my frustration with dealing with this issue, including my abortive attempt to get the /etc/network/interfaces munging fixed to make NM just work after an install have increased my desire for a more technically sound solution. Ben -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d99d16a.5020...@sanctuary.nslug.ns.ca
Re: Back to technical discussion
Hi, Josselin Mouette j...@debian.org (04/04/2011): I think squeeze already does a lot better, but there is still work to do, especially with the installation process. On my personal wishlist for wheezy is d-i actually calling NM behind the scenes to configure the network, instead of ifupdown. I’ll definitely try to find time to hack on this. on a related note, losing the essid during installation seems to be pretty badly supported. The installation broke while installing the bootloader, but mostly half packages weren't installed before even that. Had to chroot under /target, and set the essid again; several times, since it got lost a few times. Haven't had a chance to gather more intel on that (not my laptop), but probably something where having a please-keep-me-connected mode would have helped. KiBi. signature.asc Description: Digital signature
Re: Back to technical discussion? Yes! (was: network-manager as default? No!)
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 I don't consider myself 'stupid user', but I haven't yet been able to put my laptop on wpa network without the use of network manager. /Sune -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnipjlel.rvp.nos...@sshway.ssh.pusling.com
Re: Bug#620821: ITP: vpnautoconnect -- Automatically reconnect VPNs created by NetworkManager
On Monday 04 April 2011 14.15:37 barraud wrote: vpnautoconnect is a daemon that allow you to reconnect automatically (at startup too) a vpn created with network manager. It can reconnect Can I please have a daemon that monitors if vpnautoconnect works correctly? perhaps vpnautoconnectmonitord? And then that one needs to be kicked occasionally if the user changes the configuration, so we add another daemon for this I would really strongly prefer if nm got fixed for all cases where it currently doesn't work. If automatically connecting to VPN connections currently is not in network manager, this should certainly be implemented there, and not as a separate daemon. cheers -- vbi -- Frija (free' ya) was the wife sneeze of Woden and the queen count of the spread gods. signature.asc Description: This is a digitally signed message part.
Re: Back to technical discussion? Yes! (was: network-manager as default? No!)
On Mon, Apr 04, 2011 at 07:33:31PM +0530, Josselin Mouette wrote: Le lundi 04 avril 2011 à 10:39 -0300, Ben Armstrong a écrit : But the average laptop user really does have a hard time with the status quo. Something needs to change in the next release. I think squeeze already does a lot better, but there is still work to do, especially with the installation process. On my personal wishlist for wheezy is d-i actually calling NM behind the scenes to configure the network, instead of ifupdown. I’ll definitely try to find time to hack on this. Do you plan also to hack on network-manager itself so that it might become at least remotely reasonable alternative to ifupdown, or do you simply plan to follow the way redhat went, i.e., network manager as it is, even on server installations? Sould not there be an option to select between the old network configuration and NM? -- Stanislav -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110404145205.GA21595@kaiba.homelan
Re: Back to technical discussion? Yes! (was: network-manager as default? No!)
On Mon, Apr 04, 2011 at 04:19:30PM +0400, Dmitry E. Oboukhov wrote: 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. 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. For most people, a computer is just a tool. A versatile and complex tool, yes, but not all that complexity has to be exposed by default. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110404145947.gm2...@decadent.org.uk
Re: Bug#620808: ITP: payyans -- A python utility to convert between ASCII and Unicode.
On Mon, Apr 04, 2011 at 02:27:19PM +0200, Adam Borowski wrote: On Mon, Apr 04, 2011 at 03:58:43PM +0530, Dhananjay wrote: An ASCII to unicode conversion utility. Package name: payyans URL: http://wiki.smc.org.in/Payyans Description:Payyans is a python program to convert the data written for ascii fonts in ascii format to the Unicode format. Uhm, but Debian already contains an ASCII-Unicode converter. It's called cat. There's also an in-place version, /bin/true. This assumes UTF-8, but other Unicode encodings are not supported in a vast majority of tools anyway, and iconv can handle them. What payyans seems to do is converting from some other encoding where for example the octet 65 (0x41) doesn't mean A but അ, 66 is ക and so on. This is definitely not ASCII; it's about as close to it as to EBCDIC. And we already have the 'iconv' and 'recode' commands to do conversion between arbitrary character encodings. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110404150351.gn2...@decadent.org.uk
what is wrong with dpkg-shlibdeps
what is missing in the package configuration when dpkg-shlibdeps does not visit debian/tmp/usr/lib to find the libraries? Are these considered the private libraries in: To help dpkg-shlibdeps find private libraries, you might need to set LD_LIBRARY_PATH. Gr. Sim -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d99de1d.8080...@ijskes.org
Re: what is wrong with dpkg-shlibdeps
On Mon, 04 Apr 2011 17:05:01 +0200 Sim IJskes s...@ijskes.org wrote: what is missing in the package configuration when dpkg-shlibdeps does not visit debian/tmp/usr/lib to find the libraries? Try debian-ment...@lists.debian.org in future for these questions. Often it can be looking in debian/foo/usr/lib where foo is the binary package name. Depends. You'd need to upload the build log somewhere, along with the full source, and ask someone at debian-mentors to review it. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpyACBUNyiZG.pgp Description: PGP signature
Re: Back to technical discussion? Yes!
Ben Armstrong sy...@sanctuary.nslug.ns.ca writes: 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. You might have hit the same race condition in one of the shell scripts as I did: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=587634 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/84mxk6ghx7@sauna.l.org
Re: Bug#620821: ITP: vpnautoconnect -- Automatically reconnect VPNs created by NetworkManager
Am 04.04.2011 15:06, schrieb Michael Biebl: Am 04.04.2011 14:15, schrieb barraud: Upstream Author : BARRAUD Manuel barraudman...@wanadoo.fr Please communicate this to the author of vpnautoconnect, maybe he is interested in joining the NM development and implement it in NM proper. /o\ seems I missed to look at your email address. That said, I know that Dan Williams (NM upstream) is eager to get this feature into NM. Feel free to join #nm on freenode or the upstream devel mainling list[1]. Michael [1] http://mail.gnome.org/mailman/listinfo/networkmanager-list -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Back to technical discussion? Yes! (was: network-manager as default? No!)
Hi
On Monday 04 April 2011, Sune Vuorela wrote:
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
I don't consider myself 'stupid user', but I haven't yet been able to
put my laptop on wpa network without the use of network manager.
The most simple case, one static wlan definition, no roaming:
/etc/network/interfaces:
allow-hotplug wlan0
iface wlan0 inet dhcp
wpa-ssid whatever
wpa-psk whatever
Simple roaming, 2 example networks (with differing priorities) and
catch-all for open networks, this allows automatic roaming between the
defined network setups:
/etc/network/interfaces:
allow-hotplug wlan0
iface wlan0 inet manual
wpa-roam /etc/wpa_supplicant/wpa-roam.conf
iface home_network inet dhcp
iface my_work_net inet dhcp
iface default inet dhcp
/etc/wpa_supplicant/wpa-roam.conf:
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=netdev
network={
priority=25
ssid=whatever
id_str=home_network
proto=WPA2
pairwise=CCMP
group=CCMP
psk=whatever
}
network={
priority=10
ssid=whatever
id_str=my_work_net
proto=WPA2
pairwise=CCMP
group=CCMP
psk=whatever
}
network={
priority=1
ssid=
key_mgmt=NONE
}
proto, pairwise and group are not really mandatory, but avoid stepping
down to WPA1 or TKIP, if another access point only offers that. psk can
be ASCII- (in quotes) or hexadecimal keys (64 characters). More complex
setups like IEEE8021X, certificates, TTLS/ PAP etc. can be configured
just as well. /usr/share/doc/wpasupplicant/examples/ can help quite a
lot for more exotic setups. ADSL/ PPPoE dial-in setups, in the absence
of routers, aren't much more difficult.
What's so nice about ifupdown (and wpasupplicant integration)?
It simply works with minimal dependencies and can be configured through
your preferred {,cli-} editor, which is an important use case for me.
It doesn't break on changing D-Bus interfaces and doesn't need
functional X11/ D-Bus for configuration or operations, nor breaks ssh
sessions during upgrades.
Besides not using netlink internally, ifupdown's biggest drawback in my
personal opinion is not reacting dynamically to changing connection
methods, like switching from wlan0 to eth0, if an ethernet cable gets
temporarily connected - ifplugd can act as a bandaid here, but is not
overly reliable (and possibly doesn't cover UMTS connections or other
mobile connections either, but I'm not sure about this).
On the other hand n-m isn't an option for server or (quasi-) headless
systems at all, be it due to large dependency chains (there is no D-Bus
or X.org installed on my servers) or simply unreliable operations
during remote upgrades (restarting the interface upon n-m upgrades).
While it's certainly a convenient configuration method for notebook
users, who switch often between different connectivity methods (ADSL/
PPPoE, ethernet, wlan, PPP over bluetooth/ PAN, UMTS/ 3g, WiMAX/ 4g or
different VPN profiles). However for me personally, a simple and
dependable ifupdown like solution, which can be configured/ operated
through the cli, and with minimal dependency chains is more important
than a pretty GUI.
Maybe new solutions targetted at the embedded sector, like ConnMan or
the new netlink based network manager planned for OpenWrt, can fill
this void, but personally I doubt network-manager can (or at least
will-) be adapted to work reliably for the afforementioned server like
use cases.
Regards
Stefan Lippers-Hollmann
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201104041742.29760.s@gmx.de
Moving bash from essential/required to important?
Hi bash is not the default system shell anymore. It's now only the default user shell. As such it is not required for a sysadmin to boot and install software. Besides that some users would like to get rid of bash in their environment which is obviously not easily done atm. The most obvious reason to not degrade bash to Priority: important is obviously that one needs to declare a dependency on bash when it's used in a package. Which means quite some packages will need to be changed. What do others think of moving bash to important (required and important are part of the base system)? Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d99ec04.4070...@debian.org
Re: time based freezes
On Mon, Apr 04, 2011 at 08:38:18AM +0200, Carsten Hey wrote: One thing that the release team already is improving is communication, [snip] The other thing that has potential to be improved is the freezing. [snip] I also note a lack of replies to feedb...@release.debian.org - these mails are definately useful, but I really would appreciate any comments going there, so I don't have to spend days trawling archives to pick up people's points. Cheers, Neil -- Maulkin Damned Inselaffen. Oh, wait, that's me. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110404160509.ga46...@feta.halon.org.uk
Re: Moving bash from essential/required to important?
On 2011-04-04, Luk Claes l...@debian.org wrote: What do others think of moving bash to important (required and important are part of the base system)? Just to make sure, you are essentially (ha!) talking about dropping Essential:yes from bash? /Sune -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnipjre7.rvp.nos...@sshway.ssh.pusling.com
Re: time based freezes
On Monday, April 04, 2011 12:05:09 PM Neil McGovern wrote: On Mon, Apr 04, 2011 at 08:38:18AM +0200, Carsten Hey wrote: One thing that the release team already is improving is communication, [snip] The other thing that has potential to be improved is the freezing. [snip] I also note a lack of replies to feedb...@release.debian.org - these mails are definately useful, but I really would appreciate any comments going there, so I don't have to spend days trawling archives to pick up people's points. That seems like an odd reply to a message in a thread you started on debian- devel? Scott K -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201104041212.10313.deb...@kitterman.com
Re: Moving bash from essential/required to important?
On Apr 04, Luk Claes l...@debian.org wrote: The most obvious reason to not degrade bash to Priority: important is obviously that one needs to declare a dependency on bash when it's used in a package. Which means quite some packages will need to be changed. This looks like a good enough reason to me to not bother. -- ciao, Marco signature.asc Description: Digital signature
Re: Moving bash from essential/required to important?
On Mon, Apr 4, 2011 at 18:04:20 +0200, Luk Claes wrote: Hi bash is not the default system shell anymore. It's now only the default user shell. As such it is not required for a sysadmin to boot and install software. Besides that some users would like to get rid of bash in their environment which is obviously not easily done atm. The most obvious reason to not degrade bash to Priority: important is obviously that one needs to declare a dependency on bash when it's used in a package. Which means quite some packages will need to be changed. What do others think of moving bash to important (required and important are part of the base system)? I think it'd be mostly a waste of time. Cheers, Julien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110404161942.gp3...@radis.liafa.jussieu.fr
Re: Back to technical discussion? Yes! (was: network-manager as default? No!)
On Mon, Apr 04, 2011 at 06:06:28PM +0530, Josselin Mouette wrote: Le lundi 04 avril 2011 à 16:19 +0400, Dmitry E. Oboukhov a écrit : 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. By the way, I am glad that you spoke your mind so clearly. IMO, this agrees very much with the trends in free software development that solidified in the last decade: the development of popular free software is now concentrated within big corporations and is done in groups of well paid fulltimers. Those who still believe in the openness of this process must disillusion themselves: nowadays most of the development is driven by marketing. It is not surprising that marketing places an emphasis on simplicity to the detriment of configurability. Such marketing goals also explain why these groups usually agressively fight for domination. Nevertheless, I honestly hope that Debian, with its huge collection of free software, will contunue to provide freedom of choice to all types of its users, including those who disagree with marketing goals of big corporations. -- Stanislav -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110404171858.GA25705@kaiba.homelan
Re: Moving bash from essential/required to important?
On Mon, Apr 04, 2011 at 06:04:20PM +0200, Luk Claes wrote: bash is not the default system shell anymore. It's now only the default user shell. As such it is not required for a sysadmin to boot and install software. Besides that some users would like to get rid of bash in their environment which is obviously not easily done atm. The most obvious reason to not degrade bash to Priority: important is obviously that one needs to declare a dependency on bash when it's used in a package. Which means quite some packages will need to be changed. What do others think of moving bash to important (required and important are part of the base system)? I think we should avoid doing this for quite a different reason from the other responders. Consider that 'base-passwd' and 'login' are also part of the essential set. Why? Because being able to log in as root is part of the minimal set of functionality that must be available and usable on the system at all times. So if we drop bash from essential, how do we guarantee that root can log in? Do we set root's default shell to /bin/sh instead? I don't think anyone would be happy with that except those people who already change it to zsh anyway. :-) If login worked consistently in the face of the configured shell going missing (automatically falling back to /bin/sh for root), then I think it would be worthwhile to do the work necessary to remove bash from the essential set. But until then, the primary purpose of Essential, to me, is the minimal set guaranteed to be usable aspect, not the you don't have to depend on it aspect. -- 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 Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Back to technical discussion? Yes! (was: network-manager as default? No!)
On Mon, Apr 04, 2011 at 06:52:05PM +0400, Stanislav Maslovski wrote: Sould not there be an option to select between the old network configuration and NM? Nowhere have I seen it argued that NM will be the *only* networking solution for Debian going forward, merely the *default* one. In other words, yes, there should be an option: just like there is now. -- Jon Dowland -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110404173519.ga21...@deckard.alcopop.org
Re: Old Release goal: Getting rid of unneeded *.la / emptying dependency_libs
Neil Williams codeh...@debian.org writes: The cases listed are the ones where the .la file can be removed. Packages with .la files which don't meet those criteria were not included in the list. However, it looks like there could be a flaw in the original data. Indeed, there were a bunch of different problems, although mostly with my understanding. The line in the original data is: shibboleth-sp2: dependency_libs links-not-existing-la The original criteria were: 1. no flag to remove the la-file on next occasion 2. only dependency_libs to remove their la-file RSN, because they block removal of the la-files on another package (this flag can be wrongly hit if a package depends only on itself - but well, dropping the la-file is recommended as well here as with 1.) 3. only depended-on to do nothing at this time 4. with both dependency_libs depended-on to use sed -i s,^dependency_libs=.*,dependency_libs='', on all their la-files (I took care that self-dependencies don't appear in this category, but rather in 1 or 2). So where is the error? In the original data? No, indeed, dependency_libs should be stripped from those files. It doesn't need to be, really, since it's obviously never used by anything (referencing non-existent files as it does), but for cleanliness it should go anyway. I believe the *.la files need to stay since I think upstream is loading modules that way, but I will double-check. But they're harmless for Debian as a whole. Lintian already checks that *.la files don't contain the problematic dependency_libs setting. This apparently just isn't true. I could have sworn that we had a check, but we apparently do not. We definitely should. That's probably why there are so many problems; I suspect a lot of them would go away if there were a Lintian check. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87lizpsy9b@windlord.stanford.edu
Re: Back to technical discussion? Yes! (was: network-manager as default? No!)
On Mon, Apr 04, 2011 at 07:33:31PM +0530, Josselin Mouette wrote: Le lundi 04 avril 2011 à 10:39 -0300, Ben Armstrong a écrit : But the average laptop user really does have a hard time with the status quo. Something needs to change in the next release. I think squeeze already does a lot better, but there is still work to do, especially with the installation process. On my personal wishlist for wheezy is d-i actually calling NM behind the scenes to configure the network, instead of ifupdown. I’ll definitely try to find time to hack on this. I'm not well-familiar with NM. I'm more familiar with wicd. I do feel NM has some shortcomings for my habits: (Please feel free to correct me where I'm factually incorrect. I probably am) It does have system-global config file. But the settings are not expected to be there. By default the settings are expected to be in the user directory (has this changed since 0.8?). So I won't easily find it when I want to e.g. change configuration as root. This is unlike wicd that keeps everything under /etc/wicd . The configuration file is a simple, readable and intiutive text file (ini-file. No XML or such nonsense). Some documentation and examples would help. What bothers me, though, is that each entry requires a unique identifier field. Which makes it all too easy to make copypaste errors. The command-line interface (nmcli) seems to be rather usable from the little I have played with it. Another issue I have had with it in the past is debugging. At least in my experince, troubleshooting generally invloved killing the service and restarting it in debug mode. Which is something I would not really like to instruct a newb. I hope there are better ways to debug it without killing it. -- Tzafrir Cohen | tzaf...@jabber.org | VIM is http://tzafrir.org.il || a Mutt's tzaf...@cohens.org.il || best tzaf...@debian.org|| friend -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110404173815.ge26...@pear.tzafrir.org.il
Re: Moving bash from essential/required to important?
On Mon, Apr 04, 2011 at 06:04:20PM +0200, Luk Claes wrote: What do others think of moving bash to important (required and important are part of the base system)? I think that this is a great idea. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110404175951.ga31...@scru.org
Re: Back to technical discussion? Yes! (was: network-manager as default? No!)
On Mon, Apr 04, 2011 at 06:35:19PM +0100, Jon Dowland wrote: On Mon, Apr 04, 2011 at 06:52:05PM +0400, Stanislav Maslovski wrote: Sould not there be an option to select between the old network configuration and NM? Nowhere have I seen it argued that NM will be the *only* networking solution for Debian going forward, merely the *default* one. In other words, yes, there should be an option: just like there is now. I mean that such an option should be available from within the installer (at least in the expert mode) at the stage of the initial network configuration, if network-manager is going to replace ifupdown in this stage. -- Stanislav -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110404181000.GA29744@kaiba.homelan
Business proposal from hong kong
Hello How are you ? Am from Hong Kong, am a Chinese , I have a Mutual business proposal am proposing to you, that I will want you to handle from your country, I will like to seek your consent first. I have a serious business project proposal for you to manage and handle for me in your country. This project involves a huge specific amount I can't mention here for security reasons. It involve a transaction from my bank in Hong Kong. Am a chinese man, and we are bound by laws here. If you feel you can have this handled, please let me know, so that I send you an attached comprehensive details of this transaction. you should send me response to my email: Sincerely, Lan Lee Cheng -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1q6bh7-0006au...@host.hongng.com
MBF: Getting rid of unneeded *.la / emptying dependency_libs
On Mon, 04 Apr 2011 10:49:04 -0700 Russ Allbery r...@debian.org wrote: Neil Williams codeh...@debian.org writes: The line in the original data is: shibboleth-sp2: dependency_libs links-not-existing-la The original criteria were: 1. no flag to remove the la-file on next occasion 2. only dependency_libs to remove their la-file RSN, because they block removal of the la-files on another package (this flag can be wrongly hit if a package depends only on itself - but well, dropping the la-file is recommended as well here as with 1.) 3. only depended-on to do nothing at this time 4. with both dependency_libs depended-on to use sed -i s,^dependency_libs=.*,dependency_libs='', on all their la-files (I took care that self-dependencies don't appear in this category, but rather in 1 or 2). So where is the error? In the original data? No, indeed, dependency_libs should be stripped from those files. It doesn't need to be, really, since it's obviously never used by anything (referencing non-existent files as it does), but for cleanliness it should go anyway. I believe the *.la files need to stay since I think upstream is loading modules that way, but I will double-check. But they're harmless for Debian as a whole. OK, so this is one of those situations where the .la file, with or without dependency_libs IS useful - Sune pointed out another. It does sound, though, that these are exceptions rather than routine. Lintian already checks that *.la files don't contain the problematic dependency_libs setting. This apparently just isn't true. I could have sworn that we had a check, but we apparently do not. We definitely should. That's probably why there are so many problems; I suspect a lot of them would go away if there were a Lintian check. As outlined previously, this does need to be done in a fairly strict sequence which is external to the package. It might be hard for lintian to make this into an error for all packages. Many packages (all those in the list with depended-on) must not touch their .la files at this stage - including the dependency_libs listing. I think we need to get this Release Goal completed and *then* set up a lintian warning for *any* .la file which must be explicitly overruled for those exceptions which actually use the .la file. There could also be an error if any package then includes an .la file with dependency_libs - only once the entire process is complete first time around. That could be a while... With the caveats already covered in this thread (excepting kdelibs), are there objections to a MBF for this outdated Release Goal? We've already missed this Release Goal once, probably because no bugs were filed first time around. I'd phrase it something like: In most cases, the .la file can simply be removed as the process behind this MBF has already identified that there are no further dependencies using the .la file. In the unusual case that your package uses libltdl directly, it is still necessary to empty the dependency_libs part of all .la files remaining in the package. Once this package is fixed, the process will repeat and other packages may need to be fixed in turn. If you believe that your package needs both the .la file and the dependency_libs settings, please raise this on debian-devel for clarification. Right. Time for me to make some uploads to fix my own packages for this run and then look for the next set. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpFGriSI7pjN.pgp Description: PGP signature
Re: Moving bash from essential/required to important?
On Mon, Apr 04, 2011 at 05:59:51PM +, Clint Adams wrote: On Mon, Apr 04, 2011 at 06:04:20PM +0200, Luk Claes wrote: What do others think of moving bash to important (required and important are part of the base system)? I think that this is a great idea. Likewise. Regarding the root shell issue, I wouldn't have an issue with it being /bin/sh. The admin is always free to chsh it to the shell of their choice. [Slightly related: it would be nice if d-i could default to password-free locked root account for wheezy, i.e. sudo by default, which would partly mitigate the issue by not requiring the use of a root shell for most uses of the root account.] However, there have got to be hundreds of packages using bash without a dependency. Do we have any information on the affected packages (i.e. all those with a #!/bin/bash shebang in any provided executable scripts)? 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. signature.asc Description: Digital signature
Re: Back to technical discussion? Yes! (was: network-manager as default? No!)
On Mon, Apr 4, 2011 at 2:38 PM, Tzafrir Cohen tzaf...@cohens.org.il wrote: [...] It does have system-global config file. But the settings are not expected to be there. By default the settings are expected to be in the user directory (has this changed since 0.8?). So I won't easily find it when I want to e.g. change configuration as root. This is unlike wicd that keeps everything under /etc/wicd . NM, prior to 0.9, had system-wide and user-specific connections. Those user-specific configurations were replaced in 0.9 by system-wide configurations with permissions. The system-wide connections are always (even prior to 0.9) in /etc as you'd expect. I use NM with system-wide WiFi connections only. I create the system wide configurations through a collection of scripts I've assembled (since the other NM command line clients were either broken at the time I tried them or not powerful enough) and NM automagically picks the right connections for me when I'm on the road. Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/BANLkTinZdpKsf-5Ks4qWayFCQwJXX=8...@mail.gmail.com
Nipples (was Re: Back to technical discussion? Yes!)
]] Ben Armstrong (followup to -curiosa, please) [...] | That stuff, unlike the nipple, is all learned. From talking with friends of mine who have babies, that skill is also very much learned. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87tyed3l84.fsf...@qurzaw.varnish-software.com
Re: Back to technical discussion? Yes! (was: network-manager as default? No!)
2011/4/4 Stanislav Maslovski stanislav.maslov...@gmail.com: 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. wicd has the same functionalities than network-manager and is compatible with ifconfig and the like. I have nothing against adding wicd or a daemon that is compatible with ifconfig and I think network-manager should be disqualified for that very reason. Romain -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/banlktikwrmerhag9xp7vu4ejoepdb0k...@mail.gmail.com
Re: Back to technical discussion? Yes!
Dmitry E. Oboukhov un...@debian.org writes: 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. I know lots about Linux, and even I have no desire to study enough documentation to figure out how to run wpa_supplicant by hand. I've done it a couple of times and it was horribly painful. I'm much happier letting wicd handle it for me. Increasing the amount of stuff that just works is important. It is a profoundly erroneous truism, repeated by all copy-books and by eminent people when they are making speeches, that we should cultivate the habit of thinking of what we are doing. The precise opposite is the case. Civilisation advances by extending the number of operations we can perform without thinking about them. -- Alfred North Whitehead That said, for simple server network configuration patterns, ifupdown just works. I think a lot of the push-back that's happening in this thread is that replacing ifupdown for the simple but very common case of having one statically-configured or DHCP-configured wired Ethernet connection on a server seems like a really bad idea, since ifupdown just works and is substantially better than the Red Hat equivalent. I don't think that many people in that situation will be enthusiastic about running something as complex as Network Manager on a typical simple server networking setup. (And usually when the networking gets complex on a server, it needs to be carefully hand-configured to do the right thing, and not in a way that Network Manager was designed to do.) That said, of course for a server build one can just remove Network Manager and install ifupdown and go on with life. Changing the default doesn't mean forcing it on everyone. But I think that's much of where the concern arises. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8739lxstkf@windlord.stanford.edu
Re: Moving bash from essential/required to important?
On ma, 2011-04-04 at 19:43 +0100, Roger Leigh wrote: Regarding the root shell issue, I wouldn't have an issue with it being /bin/sh. The admin is always free to chsh it to the shell of their choice. We could even have d-i set the root shell to bash if it installs bash. Or have bash do it always, even, if root's shell is /bin/sh. [Slightly related: it would be nice if d-i could default to password-free locked root account for wheezy, i.e. sudo by default, which would partly mitigate the issue by not requiring the use of a root shell for most uses of the root account.] +1 However, there have got to be hundreds of packages using bash without a dependency. Do we have any information on the affected packages (i.e. all those with a #!/bin/bash shebang in any provided executable scripts)? I happened to have access to a idle-ish fastish machine with a fresh-ish Debian mirror, so I wrote a script to unpack all binaries (for sid/main amd64), and then another script to grep for bash scripts (actually a pair of scripts). With these scripts, I got a list of files that start with #!/bin/bash. There are 1783 files in the list, in 543 packages. The list is 128 kilobytes long, so I don't attach it. I've put it on the web at http://files.liw.fi/temp/bash.list for anyone who wants a look. I have attached the scripts to make it easier for others to re-run them if they wish. Changing 543 packages to add a bash dependency does sound like a lot, but it should be doable. * We can add a lintian warning, which helps catch such things in the future. * We can perhaps change debhelper to automatically add the dependency, if it is missing. Since most packages use debhelper, this might transition most of the packages automatically. * Or we might do a more traditional transition, with an MBF now, and a targeted NMU campaign in six months, for any packages that still remain. I think this would be a nice thing to do, especially from the point of view of embedded systems, and other systems with no interactive use, but limited resources. -- Blog/wiki/website hosting with ikiwiki (free for free software): http://www.branchable.com/ unpack-debian-binaries Description: application/shellscript find-bash-scripts Description: application/shellscript isbash Description: application/shellscript
Re: Back to technical discussion? Yes! (was: network-manager as default? No!)
On Mon, Apr 04, 2011 at 01:57:10PM -0500, Romain Beauxis wrote: 2011/4/4 Stanislav Maslovski stanislav.maslov...@gmail.com: 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. wicd has the same functionalities than network-manager and is compatible with ifconfig and the like. I considered using wicd some time ago, but gave up after reading information from its FAQ: http://wicd.sourceforge.net/moinmoin/FAQ -- Stanislav -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110404193420.GA2344@kaiba.homelan
Re: Back to technical discussion? Yes!
Stanislav Maslovski stanislav.maslov...@gmail.com writes: I considered using wicd some time ago, but gave up after reading information from its FAQ: http://wicd.sourceforge.net/moinmoin/FAQ The main advantage of wicd from my perspective is that it's a simple and straightforward solution for configuring a single wireless interface with a GUI. If that's not your situation, it's probably not going to be very rewarding. It happens to fit my situation perfectly. I would not advocate making it the default network management facility in Debian without putting significantly more work into it (and I would worry about losing its current excellent simplicity. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87hbadrdzu@windlord.stanford.edu
network-manager,ifupdown and bittorrent Was Re: network-manager as default? No!
Hi all, I read the whole thread about network manager starting from http://lists.debian.org/debian-devel/2011/04/msg00051.html I am an average joe/user who has been a Ubuntu user for few years while migrating to Debian during the Squeeze freeze cycle (about 6 months back) . The system I run on is a desktop which is connects via ethernet to a D-Link Modem/Router to net. While reading the thread I saw that there is something called ifupdown which is managing stuff for me. I get a dynamic IP assigned each time I log in and the connection is an ADSL connection which is pretty much one of the main ways to connect to Internet in India, although with laptops wireless is happening. Ok, so in the interest of understanding of what's or how things are happening, I first decided to see the contents of the package ifupdown $ dpkg -L ifupdown and then see the manpage of ifup and other things. Then tried to run the various things as put up in the manpage :- $ /etc/network/run/ifstate bash: /etc/network/run/ifstate: Permission denied It took me quite some time and trying all different things before I came to :- $ cat /etc/network/run/ifstate lo=lo and $ /usr/bin/perl /usr/share/doc/ifupdown/contrib/ifstate-check lo: UP,CONFIGURED neither of which tells me much about how things are configured (something is hidden somewhere) . Now as a user both the info. I have got doesn't tell me anything. Its only after much playing around that I come to known ifconfig which actually tells me what I need to know :- ~$ ifconfig eth0 Link encap:Ethernet HWaddr some:alphanumeric:address inet addr:ipv4.add.re.ss Bcast:ipv4.add.re.ss Mask:255.255.255.0 inet6 addr: another.alphanumeric.address Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:49733 errors:0 dropped:0 overruns:0 frame:0 TX packets:48783 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:55630643 (53.0 MiB) TX bytes:5838151 (5.5 MiB) Interrupt:42 Base address:0xsomething loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:445 errors:0 dropped:0 overruns:0 frame:0 TX packets:445 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:33957 (33.1 KiB) TX bytes:33957 (33.1 KiB) Even though I am/was able to get this, from the past 6 months or so I have not been able to run bittorrent on this and I do not know the reason for this. Its a complete mystery to me. I am able to update/upgrade the system, run .jigdo to update the weekly ISO DVD's and do all kinds of git and svn stuff but unable to get bittorrent. Even for the wireless thing, atleast in my country there are no longer many open WiFi hotspots especially after the 2008 Mumbai attacks as the terrorists used the wifi to publicize their attack on net. Why bittorrent is not working still is a mystery to me, any help in that regard would be appreciated. The reason I share all of this is as a user I don't really know how my system is configured and nor does ifupdown make it any way easy for me to understand how its done. Atleast to me it seems cryptic in the way its configures stuff and the way the manpages are written. They are not written for the average joe to make head or tail of. This is not for or against network-manager, this is just a user's experience. As can be seen above, I'm no guru, in fact far far away from that. Just my 2 paise. -- Regards, Shirish Agarwal शिरीष अग्रवाल My quotes in this email licensed under CC 3.0 http://creativecommons.org/licenses/by-nc/3.0/ http://flossexperiences.wordpress.com 065C 6D79 A68C E7EA 52B3 8D70 950D 53FB 729A 8B17 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/BANLkTi=ahs1z3gam-nhkpuggzrmzpre...@mail.gmail.com
Re: Back to technical discussion? Yes!
Hello Russ Allbery, Am 2011-04-04 12:30:24, hacktest Du folgendes herunter: That said, of course for a server build one can just remove Network Manager and install ifupdown and go on with life. Changing the default doesn't mean forcing it on everyone. But I think that's much of where the concern arises. But there is a problem with it! If you install a Workstation, you will sit in front of it and if there ges something going wrong, you can interact. Installing a server over the network and having NM as default, which can not handel several NICS at startup and configre it correctly, require an expensive Remote-Hand to get the system runing again... What I do not understand is WHY the Debian Project can not do an install in two steps. I mean installing the bare base using ifupdown and if the user choose the Desktop-Task replace it with NM. I think, someone which want to install a server HAS the knowledge about System- Administration and does not need NM in any case. Thanks, Greetings and nice Day/Evening Michelle Konzack -- # Debian GNU/Linux Consultant ## Development of Intranet and Embedded Systems with Debian GNU/Linux itsystems@tdnet France EURL itsystems@tdnet UG (limited liability) Owner Michelle KonzackOwner Michelle Konzack Apt. 917 (homeoffice) 50, rue de Soultz Kinzigstraße 17 67100 Strasbourg/France 77694 Kehl/Germany Tel: +33-6-61925193 mobil Tel: +49-177-9351947 mobil Tel: +33-9-52705884 fix http://www.itsystems.tamay-dogan.net/ http://www.flexray4linux.org/ http://www.debian.tamay-dogan.net/ http://www.can4linux.org/ Jabber linux4miche...@jabber.ccc.de ICQ#328449886 Linux-User #280138 with the Linux Counter, http://counter.li.org/ signature.pgp Description: Digital signature
Re: System users: removing them
On to, 2011-03-31 at 14:18 +0100, Ian Jackson wrote: Lars Wirzenius writes (System users: removing them): The easy solution for this would be to never remove the user, but that's also not so clear. To remove a user and reclaim the uid is a difficult business. This is true in the general case, but for most systems it is easy: users and uids on my laptop, for example, are not shared elsewhere. I expect most systems to be like my laptop. There are systems where they leak, and where removing a user is more difficult. That's why I would like to make it configurable by the admin. * Extra accounts are just wasteful, and may cause some confusion. * There is a tiny risk of having unused accounts on the system. (We have tens of them anyway, but still.) I think a disabled account present in passwd (with changed home directory, and starred out shadow entry) is less risk than a reused uid. Since I don't see any problem in removing unused accounts on my laptop, I judge the risks differently from you. However, the risk of an unused and properly locked down account is low enough that I am happy to live with un-purged package specific system accounts if that's what we decide to have. The current default is not to delete the user because packages don't generally do so, surely ? I ran the attached script (same as the one I attached to my previous mail, to the bash thread) to unpack all amd64 sid/main binary packages, and then grepped for use of adduser or deluser in maintainer scripts: find pool -name postinst -o -name preinst -o -name postrm -o -name prerm | xargs grep adduser adduser.list And the same, replacing adduser with deluser. The lists are a few tens of kilobytes in total, so I won't attach them to the mailing list, but I've put them on the web: http://files.liw.fi/temp/adduser.list http://files.liw.fi/temp/deluser.list There seem to be 106 maintainer scripts that mention deluser, in 103 packages. (I did not manually verify that they're all actually calling deluser.) I think this would be a good point to have a discussion and set policy on how to deal with this. The policy manual seems to currently be silent about removing users created by the package at installation time. * We can decide that packages may not remove the accounts they create, ever. In that case, we should amend Policy to say this explicitly, do an MBF on the packages in the deluser.list above, and add a lintian warning against calling deluser in maintainer scripts. * We can decide to have deluser read a config setting when removing system accounts (my earlier proposal). This would allow a little bit of de-cluttering, but perhaps not enough to warrant the complexity. * We can't decide, of course, that packages must always remove the accounts they create, because the uid re-use and leaking problems are real. Did I miss an option? What do others think? What's the sensible thing to do here? -- Blog/wiki/website hosting with ikiwiki (free for free software): http://www.branchable.com/ unpack-debian-binaries Description: application/shellscript
Re: time based freezes
On Mon, 2011-04-04 at 12:12 -0400, Scott Kitterman wrote: On Monday, April 04, 2011 12:05:09 PM Neil McGovern wrote: I also note a lack of replies to feedb...@release.debian.org - these mails are definately useful, but I really would appreciate any comments going there, so I don't have to spend days trawling archives to pick up people's points. That seems like an odd reply to a message in a thread you started on debian- devel? Unless you're counting the d-d-a mail, Neil didn't start the thread; in fact, as far as I can see, it's his first post to it - the time based freezes thread in reply to the d-d-a mail was started by Zack. fwiw, the d-d-a mail said: 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. Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1301949141.23878.263.ca...@hathi.jungle.funky-badger.org
Re: Back to technical discussion? Yes!
On Mon, Apr 04, 2011 at 12:30:24PM -0700, Russ Allbery wrote: [skipped] It is a profoundly erroneous truism, repeated by all copy-books and by eminent people when they are making speeches, that we should cultivate the habit of thinking of what we are doing. The precise opposite is the case. Civilisation advances by extending the number of operations we can perform without thinking about them. -- Alfred North Whitehead This turns backward immediately as you face a need to do something less trivial than that is supported by the ready-to-use tool of your choice. That said, for simple server network configuration patterns, ifupdown just works. Sure. But it also works in complicated configuration patterns that are not supported by any of the available click-n-go solutions. [skipped] That said, of course for a server build one can just remove Network Manager and install ifupdown and go on with life. Removing NM after a _successful_ installation is not a problem, of course. But are you sure that, for instance, an unattended network install will complete successfuly with NM in the background if the network connection blinks for a moment? Or if the system dbus service is restarted at a certain stage of installation? I would expect NM in such situations to begin reconfiguring network interfaces (or just go crazy) with all possible (and generally unpredictable) consequences (disclaimer: those are my random guesses). I very much dislike the idea of making NM the default, but if we decide to go this way, then there must be an option in the installer to disable the use of NM altogether in the very early stages of the installation. -- Stanislav -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110404204644.GA3233@kaiba.homelan
Re: Moving bash from essential/required to important?
On Mon, Apr 04, 2011 at 08:32:50PM +0100, Lars Wirzenius wrote: On ma, 2011-04-04 at 19:43 +0100, Roger Leigh wrote: Regarding the root shell issue, I wouldn't have an issue with it being /bin/sh. The admin is always free to chsh it to the shell of their choice. We could even have d-i set the root shell to bash if it installs bash. Or have bash do it always, even, if root's shell is /bin/sh. This doesn't address the problem that the package manager will no longer be treating bash as Essential, with the result that root's login shell may be rendered unusable at some point during an upgrade. It also removes the requirement that the bash maintainer ensure the package is usable when unpacked but not yet configured. How do we mitigate this? The latter could be mitigated by calling out the requirement separately in Policy, but what about the former? Users who have made a conscious decision to use a different shell as their root shell (such as zsh) may have accepted this incremental increase in risk, but I'm not convinced that we want to do this for all users by default (if bash is still Priority: required, it will be installed by default, so all users will be affected unless they opt out). And if /bin/sh is going to be dash (which I think is what we want), I wouldn't like to inflict that on anyone as the default root login shell. -- 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 Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: sslv2 and openssl 1.0
If there are any packages that uses SSLv2 by default you might want to file a security bug to get them fixed. I believe SSLv2 is really that bad, it just gives a false sense of security. /Simon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87mxk5hi3i@latte.josefsson.org
Re: Moving bash from essential/required to important?
On 04/04/2011 09:32 PM, Lars Wirzenius wrote: On ma, 2011-04-04 at 19:43 +0100, Roger Leigh wrote: However, there have got to be hundreds of packages using bash without a dependency. Do we have any information on the affected packages (i.e. all those with a #!/bin/bash shebang in any provided executable scripts)? I happened to have access to a idle-ish fastish machine with a fresh-ish Debian mirror, so I wrote a script to unpack all binaries (for sid/main amd64), and then another script to grep for bash scripts (actually a pair of scripts). With these scripts, I got a list of files that start with #!/bin/bash. There are 1783 files in the list, in 543 packages. Does this include the instances of maintainer scripts (postinst etc)? I guess it will be even more. Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d9a3024.9040...@debian.org
Re: time based freezes
Adam D. Barratt a...@adam-barratt.org.uk wrote: On Mon, 2011-04-04 at 12:12 -0400, Scott Kitterman wrote: On Monday, April 04, 2011 12:05:09 PM Neil McGovern wrote: I also note a lack of replies to feedb...@release.debian.org - these mails are definately useful, but I really would appreciate any comments going there, so I don't have to spend days trawling archives to pick up people's points. That seems like an odd reply to a message in a thread you started on debian- devel? Unless you're counting the d-d-a mail, Neil didn't start the thread; in fact, as far as I can see, it's his first post to it - the time based freezes thread in reply to the d-d-a mail was started by Zack. fwiw, the d-d-a mail said: 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. Debian-devel seems like a reasonable place to be discussing how Debian development should be structured. Yes, that is the message to which I referred. It seems equally reasonable to me for follow-up discussion of a message to debian-devel-announce would occur on debian-devel, particularly when the message doesn't specify an alternate venue. So I still find that on odd reply to the thread. It doesn't seem particularly consistent with the improved communication I've heard the release team is doing these days. Scott K -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/28670ab5-28a8-4211-9b69-abcfbbdd8...@email.android.com
Re: Back to technical discussion? Yes!
On Mon, Apr 04, 2011 at 10:03:12PM +0200, Michelle Konzack wrote: What I do not understand is WHY the Debian Project can not do an install in two steps. I mean installing the bare base using ifupdown and if the user choose the Desktop-Task replace it with NM. AFAICT, the main concerns with the current ifupdown-based installation process is that its suport of wireless networks is very limited: only WEP is supported, and there are problems with lost connections. I am pretty sure that these problems may be addressed without replacing all the infrastructure and switching to NM, though. -- Stanislav -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110404205554.GA5668@kaiba.homelan
Re: Moving bash from essential/required to important?
On 04/04/2011 10:42 PM, Steve Langasek wrote: On Mon, Apr 04, 2011 at 08:32:50PM +0100, Lars Wirzenius wrote: On ma, 2011-04-04 at 19:43 +0100, Roger Leigh wrote: Regarding the root shell issue, I wouldn't have an issue with it being /bin/sh. The admin is always free to chsh it to the shell of their choice. We could even have d-i set the root shell to bash if it installs bash. Or have bash do it always, even, if root's shell is /bin/sh. This doesn't address the problem that the package manager will no longer be treating bash as Essential, with the result that root's login shell may be rendered unusable at some point during an upgrade. It also removes the requirement that the bash maintainer ensure the package is usable when unpacked but not yet configured. How do we mitigate this? The latter could be mitigated by calling out the requirement separately in Policy, but what about the former? What about Roger's suggestion to have the root account passwordless and locked with sudo access? Are there other drawbacks to that proposal (is booting in single user mode covered for instance?)? Users who have made a conscious decision to use a different shell as their root shell (such as zsh) may have accepted this incremental increase in risk, but I'm not convinced that we want to do this for all users by default (if bash is still Priority: required, it will be installed by default, so all users will be affected unless they opt out). I guess this is not so much an issue anymore when the account is locked? And if /bin/sh is going to be dash (which I think is what we want), I wouldn't like to inflict that on anyone as the default root login shell. In single user mode this would still be the case I guess? Though that would not have a big impact anymore I guess? Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d9a3175.1030...@debian.org
Re: Back to technical discussion? Yes! (was: network-manager as default? No!)
On Mon, Apr 4, 2011 at 07:29, Sune Vuorela nos...@vuorela.dk wrote: 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 I don't consider myself 'stupid user', but I haven't yet been able to put my laptop on wpa network without the use of network manager. I never did get nm or wicd to work. Only with ifupdown+wpa_supplicant was I able to make WiFi work. This was with an ordinary home router with WPA2 PSK and an Atheros PCIe NIC This possibly explains why you will never see me supporting nm/wicd as a default. Cheers, Kelly Clowers -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/banlktim51nc4rpdxewhwdqdgvekszqp...@mail.gmail.com
Re: network-manager as default? No! (was: Bits from the Release Team - Kicking off Wheezy)
Hello Stanislav Maslovski, Am 2011-04-04 01:11:15, hacktest Du folgendes herunter: On Sun, Apr 03, 2011 at 11:26:20PM +0530, Josselin Mouette wrote: 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. And HOW MANY users have such special case? I have in Strasburg and its Region 37 customers and do not need such killer config. Still using ifupdown and need only 5 configurations where NM screws up. 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! LOL Thanks, Greetings and nice Day/Evening Michelle Konzack -- # Debian GNU/Linux Consultant ## Development of Intranet and Embedded Systems with Debian GNU/Linux itsystems@tdnet France EURL itsystems@tdnet UG (limited liability) Owner Michelle KonzackOwner Michelle Konzack Apt. 917 (homeoffice) 50, rue de Soultz Kinzigstraße 17 67100 Strasbourg/France 77694 Kehl/Germany Tel: +33-6-61925193 mobil Tel: +49-177-9351947 mobil Tel: +33-9-52705884 fix http://www.itsystems.tamay-dogan.net/ http://www.flexray4linux.org/ http://www.debian.tamay-dogan.net/ http://www.can4linux.org/ Jabber linux4miche...@jabber.ccc.de ICQ#328449886 Linux-User #280138 with the Linux Counter, http://counter.li.org/ signature.pgp Description: Digital signature
Re: Back to technical discussion? Yes! (was: network-manager as default? No!)
On Mon, Apr 4, 2011 at 11:42 AM, Stefan Lippers-Hollmann s@gmx.de wrote: [...] Besides not using netlink internally, ifupdown's biggest drawback in my personal opinion is not reacting dynamically to changing connection methods, like switching from wlan0 to eth0, if an ethernet cable gets temporarily connected - ifplugd can act as a bandaid here, but is not overly reliable (and possibly doesn't cover UMTS connections or other mobile connections either, but I'm not sure about this). AFAIK from following where I can the development of NM 0.9 upstream, looks like the issues with interaction with ifconfig, etc. might be on the way to being resolved. However, I'm just talking from very quickly glancing at commit messages. I can't even point to a specific entry. ;) On the other hand n-m isn't an option for server or (quasi-) headless systems at all, be it due to large dependency chains (there is no D-Bus or X.org installed on my servers) or simply unreliable operations during remote upgrades (restarting the interface upon n-m upgrades). While it's certainly a convenient configuration method for notebook users, who switch often between different connectivity methods (ADSL/ PPPoE, ethernet, wlan, PPP over bluetooth/ PAN, UMTS/ 3g, WiMAX/ 4g or different VPN profiles). However for me personally, a simple and dependable ifupdown like solution, which can be configured/ operated through the cli, and with minimal dependency chains is more important than a pretty GUI. I tend to agree there: NM somewhat breaks for server setups (and others purely CLI) for the above generic reasons. However, I do think some of these can be worked around seeing as upstream is both responsive and open to changes. X isn't required (nmcli works well, even though it can't create new connections). Other things like DBus might be required by other parts of the system. What's left is dealing with upgrades, but in Ubuntu at least upgrades shouldn't trigger restarting interfaces, exactly for the reason stated. I'm sure the same can be done in Debian if it wasn't done already. This said, I don't think NM can be the magic bullet to fix everything. Even RedHat while shipping NetworkManager on servers last I checked, still relies on their simpler command-line setup for interfaces. So should we. Defaulting to using NM probably takes care of the widest audience who would use DHCP and such, and others can fall back to ifupdown or a successor to do the more complicated things like bridging. What this gives is a standard experience on desktops and servers for the majority of use cases, with as much room as necessary for the most complex configurations. Mathieu Trudel-Lapierre mathieu...@gmail.com Freenode: cyphermox, Jabber: mathieu...@gmail.com 4096R/EE018C93 1967 8F7D 03A1 8F38 732E FF82 C126 33E1 EE01 8C93 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/BANLkTimNcj3qsxNUB6oRH7ij3p=dltx...@mail.gmail.com
Re: Moving bash from essential/required to important?
On Mon, Apr 04, 2011 at 11:00:37PM +0200, Luk Claes wrote: On 04/04/2011 10:42 PM, Steve Langasek wrote: On Mon, Apr 04, 2011 at 08:32:50PM +0100, Lars Wirzenius wrote: On ma, 2011-04-04 at 19:43 +0100, Roger Leigh wrote: Regarding the root shell issue, I wouldn't have an issue with it being /bin/sh. The admin is always free to chsh it to the shell of their choice. We could even have d-i set the root shell to bash if it installs bash. Or have bash do it always, even, if root's shell is /bin/sh. This doesn't address the problem that the package manager will no longer be treating bash as Essential, with the result that root's login shell may be rendered unusable at some point during an upgrade. It also removes the requirement that the bash maintainer ensure the package is usable when unpacked but not yet configured. How do we mitigate this? The latter could be mitigated by calling out the requirement separately in Policy, but what about the former? What about Roger's suggestion to have the root account passwordless and locked with sudo access? Are there other drawbacks to that proposal (is booting in single user mode covered for instance?)? How does that address the problem of getting a root shell to recover a system that's gone south in the middle of an upgrade? Do you intend to have a *user* account with sudo privileges that has /bin/sh as a default login shell? Users who have made a conscious decision to use a different shell as their root shell (such as zsh) may have accepted this incremental increase in risk, but I'm not convinced that we want to do this for all users by default (if bash is still Priority: required, it will be installed by default, so all users will be affected unless they opt out). I guess this is not so much an issue anymore when the account is locked? And if /bin/sh is going to be dash (which I think is what we want), I wouldn't like to inflict that on anyone as the default root login shell. In single user mode this would still be the case I guess? Though that would not have a big impact anymore I guess? Essential is all about the corner cases. One of those corner cases is that you've lost power in the middle of an upgrade and everything above the Essential set has been left in an inconsistent and unusable state. This rarely happens, but the Policy definition of Essential is our guarantee that when Murphy *does* have his way with your system, you don't need to resort to rescue media to recover it provided you have access to the console. -- 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 Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: network-manager as default? No! (was: Bits from the Release Team - Kicking off Wheezy)
On Mon, Apr 04, 2011 at 11:17:59PM +0200, Michelle Konzack wrote: Hello Stanislav Maslovski, Am 2011-04-04 01:11:15, hacktest Du folgendes herunter: On Sun, Apr 03, 2011 at 11:26:20PM +0530, Josselin Mouette wrote: 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. And HOW MANY users have such special case? I have in Strasburg and its Region 37 customers and do not need such killer config. Well, that is not the question of how many, that is the question of can you do a given task or not with a given tool. NM is limited in all possible ways I can imagine, and also buggy. On the contrary, with ifupdown, one for sure can do things that I even cannot imagine due to my limited knowledge. Feel the difference ;) -- Stanislav -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110404220829.GA9539@kaiba.homelan
Re: Back to technical discussion? Yes! (was: network-manager as default? No!)
On Mon, Apr 4, 2011 at 6:23 PM, Mathieu Trudel-Lapierre mathieu...@gmail.com wrote: [...] This said, I don't think NM can be the magic bullet to fix everything. Even RedHat while shipping NetworkManager on servers last I checked, still relies on their simpler command-line setup for interfaces. So should we. Defaulting to using NM probably takes care of the widest audience who would use DHCP and such, and others can fall back to ifupdown or a successor to do the more complicated things like bridging. Also note that there are NM plugins that enable NM to understand /etc/network/interfaces and the Fedora/RHEL counterparts. This means that if a server has NM enabled and an administrator wants to configure networking manually, he can do it just fine even if NM is installed. NM will gracefully understand that and won't try to do anything stupid (see /etc/NetworkManager/NetworkManager.conf). For servers using DHCP, you don't even have to create a connection. Wired interfaces are already automatically configured to use DHCP in NM. For the other cases, just use the legacy tools or configure /etc/network/interfaces and set managed=true in /etc/NetworkManager/NetworkManager.conf (not sure if the latter works, never tested it). Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/BANLkTi=91F41twWq=henpcw0r5uvykt...@mail.gmail.com
Re: MBF: Getting rid of unneeded *.la / emptying dependency_libs
On Mon, Apr 04, 2011 at 07:33:24PM +0100, Neil Williams wrote: Lintian already checks that *.la files don't contain the problematic dependency_libs setting. This apparently just isn't true. I could have sworn that we had a check, but we apparently do not. We definitely should. That's probably why there are so many problems; I suspect a lot of them would go away if there were a Lintian check. As outlined previously, this does need to be done in a fairly strict sequence which is external to the package. It might be hard for lintian to make this into an error for all packages. Many packages (all those in the list with depended-on) must not touch their .la files at this stage - including the dependency_libs listing. That's not correct. It is safe for any package to clear out the dependency_libs field of any .la file, as far as the OS is concerned. It is a (rather intractable) upstream bug in libtool that it recurses these .la files at all at build time when doing dynamic linking on Linux, and the only difference between a populated and an empty dependency_libs field for a package build is whether or not you get a build failure because a referenced .la file is missing. Now, removing this information will impact *static* linking using libtool; but that's already largely broken due to the preceding dependency_libs removals in the archive, and the number of packages doing static linking in Debian can be counted on one hand - none of them using libtool AFAIK. -- 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 Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#620897: ITP: sshuttle -- Transparent proxy server that works as a poor man's VPN
Package: wnpp Severity: wishlist Owner: Miguel Landaeta mig...@miguel.cc * Package name: sshuttle Version : 0.52 Upstream Author : Avery Pennarun apenw...@gmail.com * URL : https://github.com/apenwarr/sshuttle * License : GPL-2+ Programming Lang: Python Description : Transparent proxy server that works as a poor man's VPN sshuttle is not exactly a VPN, and not exactly port forwarding. It's kind of both, and kind of neither. . Any TCP session you initiate to one of the proxied IP addresses will be captured by sshuttle and sent over an ssh session to the remote copy of sshuttle, which will then regenerate the connection on that end, and funnel the data back and forth through ssh. . It's like a VPN, since it can forward every port on an entire network, not just ports you specify. Conveniently, it lets you use the real IP addresses of each host rather than faking port numbers on localhost. . On the other hand, the way it works is more like ssh port forwarding than a VPN. Normally, a VPN forwards your data one packet at a time, and doesn't care about individual connections; ie. it's stateless with respect to the traffic. sshuttle is the opposite of stateless; it tracks every single connection. . It is not needed admin access on the server. -- Miguel Landaeta, miguel at miguel.cc secure email with PGP 0x7D8967E9 available at http://keyserver.pgp.com/ Faith means not wanting to know what is true. -- Nietzsche -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110404233830.ga21...@miguel.cc
Re: Moving bash from essential/required to important?
Package: login
Version: 1:4.1.4.2+svn3283-3
Severity: wishlist
Tags: patch
Hi!
On Mon, 2011-04-04 at 10:16:35 -0700, Steve Langasek wrote:
On Mon, Apr 04, 2011 at 06:04:20PM +0200, Luk Claes wrote:
What do others think of moving bash to important (required and important
are part of the base system)?
I also think this would be great!
Consider that 'base-passwd' and 'login' are also part of the essential set.
Why? Because being able to log in as root is part of the minimal set of
functionality that must be available and usable on the system at all times.
So if we drop bash from essential, how do we guarantee that root can log in?
Do we set root's default shell to /bin/sh instead? I don't think anyone
would be happy with that except those people who already change it to zsh
anyway. :-)
Well, we can always fix login to behave more robustly, no? :)
If login worked consistently in the face of the configured shell going
missing (automatically falling back to /bin/sh for root), then I think it
would be worthwhile to do the work necessary to remove bash from the
essential set. But until then, the primary purpose of Essential, to me, is
the minimal set guaranteed to be usable aspect, not the you don't have to
depend on it aspect.
That's more or less what the attached patch does. It could certainly be
improved, as the knowledge of when to fallback is spread all over the
place, but that's an existing problem in the code anyway.
The SHELL variable in configure.in is changed to an explicit /bin/sh
because relying on $SHELL might change depending on the shell used for
configure, and the existing code expects /bin/sh for fallback and script
invokation cases, this could be considered a bug on its own though. The
only fishy point is when calling shell() with a second argument, which
will get preserved, and might not quite match what was invoked
afterwards, but probably not worth worrying.
The code could also warn that it needed to fallback to a POSIX shell,
but I'm not sure what's the policy from the shadow code PoV here.
Tested with:
# chsh root -s /bin/csh
chsh: Warning: /bin/csh does not exist
# su
# echo $SHELL
/bin/sh
# exit
# su -
# echo $SHELL
/bin/sh
# exit
# login -f root
Last login: Tue Apr 5 01:36:13 CEST 2011 on pts/10
# echo $SHELL
/bin/sh
And on a virtual console.
regards,
guillem
diff --git a/configure.in b/configure.in
index 4021479..585bdb1 100644
--- a/configure.in
+++ b/configure.in
@@ -574,7 +574,7 @@ if test $enable_utmpx = yes; then
[Define if utmpx should be used])
fi
-AC_DEFINE_UNQUOTED(SHELL, [$SHELL], [The default shell.])
+AC_DEFINE_UNQUOTED(SHELL, [/bin/sh], [The default shell.])
AM_GNU_GETTEXT_VERSION(0.16)
AM_GNU_GETTEXT([external], [need-ngettext])
diff --git a/libmisc/setupenv.c b/libmisc/setupenv.c
index 666b1c7..601430f 100644
--- a/libmisc/setupenv.c
+++ b/libmisc/setupenv.c
@@ -241,7 +241,8 @@ void setup_env (struct passwd *info)
* Create the SHELL environmental variable and export it.
*/
- if ((NULL == info-pw_shell) || ('\0' == *info-pw_shell)) {
+ if ((NULL == info-pw_shell) || ('\0' == *info-pw_shell) ||
+ access (info-pw_shell, R_OK|X_OK) != 0) {
static char temp_pw_shell[] = SHELL;
info-pw_shell = temp_pw_shell;
diff --git a/libmisc/shell.c b/libmisc/shell.c
index d815f2d..5634580 100644
--- a/libmisc/shell.c
+++ b/libmisc/shell.c
@@ -53,6 +53,7 @@ extern size_t newenvc;
int shell (const char *file, /*@null@*/const char *arg, char *const envp[])
{
+ const char *fallback_arg;
char arg0[1024];
int err;
@@ -71,6 +72,10 @@ int shell (const char *file, /*@null@*/const char *arg, char *const envp[])
(void) snprintf (arg0, sizeof arg0, -%s, Basename ((char *) file));
arg0[sizeof arg0 - 1] = '\0';
arg = arg0;
+
+ fallback_arg = -sh;
+ } else {
+ fallback_arg = arg;
}
/*
@@ -81,7 +86,14 @@ int shell (const char *file, /*@null@*/const char *arg, char *const envp[])
(void) execle (file, arg, (char *) 0, envp);
err = errno;
- if (access (file, R_OK|X_OK) == 0) {
+ if (err == ENOENT) {
+ /*
+ * The requested shell does not seem to be present,
+ * fallback to a POSIX shell.
+ */
+ (void) execle (SHELL, fallback_arg, (char *)0, envp);
+ err = errno;
+ } else if (access (file, R_OK|X_OK) == 0) {
/*
* Assume this is a shell script (with no shebang).
* Interpret it with /bin/sh
diff --git a/src/su.c b/src/su.c
index f3ff666..12bd03b 100644
--- a/src/su.c
+++ b/src/su.c
@@ -759,7 +759,8 @@ int main (int argc, char **argv)
/*
* Set the default shell.
*/
- if ((NULL == shellstr) || ('\0' == shellstr[0])) {
+ if ((NULL == shellstr) || ('\0' == shellstr[0]) ||
+ access (pwent.pw_shell, R_OK|X_OK) != 0) {
shellstr = SHELL;
}
Re: Bits from the Release Team - Kicking off Wheezy
On Sun, Apr 03, 2011 at 07:24:36AM +0800, Paul Wise wrote: On Sun, Apr 3, 2011 at 6:58 AM, Felipe Sateler fsate...@debian.org wrote: 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. While it's probably ok in some cases to restart connections (wired or wireless), it's broken in a lot of cases. For instance it's definitely not OK to restart a connection that's running over VPN, since that kills the connection without being able to restart it without user interaction (at least for connections that uses auth-solutions such as SecureID). Same goes for any authenticated connections when a password safe isn't in use (not everyone is happy to store their passwords on-disk -- in some cases it might not even be permitted by IT department policies, etc.). With all these flaws I still use NM. It works fairly well, but I curse every time I do an upgrade and NM happens to be in the list of packages that is upgraded. [snip] Regards: David -- /) David Weinehall t...@debian.org /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110404235744.ga9...@suiko.acc.umu.se
Re: Moving bash from essential/required to important?
Before bash or dash could be made non-essential in a clean way, there are IMHO various things not mentioned up to now in this thread to fix: * Fix #428189, either by adapting the policy to reality or vice versa (depending on the maintainers decision) as prerequisite to fix the next point without breaking things afterwards. * Find a sane solution for managing /bin/sh. Currently diversions are used, which looks like the wrong tool for this job to me. There are also some related bugs with a high severity. * Make dash conform to POSIX. dash/sid is not detected as being a POSIX shell by autotools, which leads to lines like #!@POSIX_SHELL@ to become #!/bin/bash and thus introduces useless dependencies on bash. * Lars Wirzenius [2011-04-04 20:32 +0100]: On ma, 2011-04-04 at 19:43 +0100, Roger Leigh wrote: Regarding the root shell issue, I wouldn't have an issue with it being /bin/sh. The admin is always free to chsh it to the shell of their choice. We could even have d-i set the root shell to bash if it installs bash. Or have bash do it always, even, if root's shell is /bin/sh. The login approach mentioned in this thread is in my opinion way more clean than fiddling with /etc/passwd. However, there have got to be hundreds of packages using bash without a dependency. Do we have any information on the affected packages (i.e. all those with a #!/bin/bash shebang in any provided executable scripts)? I happened to have access to a idle-ish fastish machine with a fresh-ish Debian mirror, so I wrote a script to unpack all binaries (for sid/main amd64), and then another script to grep for bash scripts (actually a pair of scripts). With these scripts, I got a list of files that start with #!/bin/bash. There are 1783 files in the list, in 543 packages. gzip_1.3.12-9_amd64.deb contains files in /bin/ starting with #!/bin/bash, maybe your script skips /bin/? The post installation script of libssl1.0.0.0 also contains a bash shebang line missed by your script. Changing 543 packages to add a bash dependency does sound like a lot, but it should be doable. * We can add a lintian warning, which helps catch such things in the future. This would also require an exception to the don't depend on essential warning. * We can perhaps change debhelper to automatically add the dependency, if it is missing. Since most packages use debhelper, this might transition most of the packages automatically. Ack. * Or we might do a more traditional transition, with an MBF now, and a targeted NMU campaign in six months, for any packages that still remain. This sounds more like a possible release goal to me and not like something that needs to be fixed using NMUs in a few months. I think this would be a nice thing to do, especially from the point of view of embedded systems, and other systems with no interactive use, but limited resources. I agree about the usefulness for embedded systems and think that (if there is some work done in this direction) the efforts should be done with them in mind. After all, deciding things that can't be done because of others blocking it is not the best idea. Regards Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2011040536.ga10...@furrball.stateful.de
Re: Back to technical discussion? Yes!
Russ Allbery writes (Re: Back to technical discussion? Yes!): That said, for simple server network configuration patterns, ifupdown just works. I think a lot of the push-back that's happening in this thread is that replacing ifupdown for the simple but very common case of having one statically-configured or DHCP-configured wired Ethernet connection on a server seems like a really bad idea, since ifupdown just works and is substantially better than the Red Hat equivalent. Precisely. The only reason we are having this enormous argument is because people are threatening to take away ifupdown. I appreciate that ifupdown has both design errors[1] and bugs. But the solution is not to replace it with network-manager - my opinion of network-manager cannot be reasonably expressed on this list. [1] For example, the way it tries to keep its own record of the state of your interfaces, rather than examining them when needed. These problems with ifupdown are not in principle impossible to fix; nor are they necessarily even difficult to quickly bodge so as to keep it working. Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/19866.22828.536391.570...@chiark.greenend.org.uk
Re: Moving bash from essential/required to important?
On Tue, 2011-04-05 at 01:49 +0200, Guillem Jover wrote: [...] Well, we can always fix login to behave more robustly, no? :) If login worked consistently in the face of the configured shell going missing (automatically falling back to /bin/sh for root), then I think it would be worthwhile to do the work necessary to remove bash from the essential set. But until then, the primary purpose of Essential, to me, is the minimal set guaranteed to be usable aspect, not the you don't have to depend on it aspect. That's more or less what the attached patch does. It could certainly be improved, as the knowledge of when to fallback is spread all over the place, but that's an existing problem in the code anyway. [...] This appears to open up any accounts that have been deliberately disabled by setting their shell to a nonexistent path. I know that's a dumb way to disable an account, but that doesn't make this any less of a security hole. How about checking for the configured shell in /etc/shells before enabling the fallback? Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Re: Back to technical discussion? Yes! (was: network-manager as default? No!)
On Mon, Apr 04, 2011 at 07:39:23PM -0300, Fernando Lemos wrote: On Mon, Apr 4, 2011 at 6:23 PM, Mathieu Trudel-Lapierre mathieu...@gmail.com wrote: [...] This said, I don't think NM can be the magic bullet to fix everything. Even RedHat while shipping NetworkManager on servers last I checked, still relies on their simpler command-line setup for interfaces. So should we. Defaulting to using NM probably takes care of the widest audience who would use DHCP and such, and others can fall back to ifupdown or a successor to do the more complicated things like bridging. Also note that there are NM plugins that enable NM to understand /etc/network/interfaces and the Fedora/RHEL counterparts. This means that if a server has NM enabled and an administrator wants to configure networking manually, he can do it just fine even if NM is installed. NM will gracefully understand that and won't try to do anything stupid (see /etc/NetworkManager/NetworkManager.conf). The mentioned plugin is nothing more than just a rather primitive parser intended to read a limited set of common interface settings such as ip addresses, netmasks, dns servers, etc., from the existing /e/n/interfaces file for the ease of transition. The plugin simply translates these settings into the internal representation of NM. It is not intended to interoperate with the ifupdown infrastructure in any other way. Therefore, it is generally useless for an administrator that wants to configure network interfaces manually. For servers using DHCP, you don't even have to create a connection. Wired interfaces are already automatically configured to use DHCP in NM. For the other cases, just use the legacy tools or configure /etc/network/interfaces and set managed=true Accordingly to docs here http://live.gnome.org/NetworkManager/SystemSettings that should be actually managed=false if you want an interface to be completely ignored by NM. in /etc/NetworkManager/NetworkManager.conf (not sure if the latter works, never tested it). -- Stanislav -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110405002005.GA11761@kaiba.homelan
